Бази даних �та інформаційні системи

Проектування реляційної бази даних

на основі ER-діаграми

Концептуальне та логічне проектування РМД

​

Лекція 5,6

Лекції 6, 7, 8, 9

План лекції

Вступ. Етапи проєктування РМД

1. Концептуальне проектування
2. Логічне проектування
3. Фізичне проектування

Висновок

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

2

Мета лекції:

1. Розглянути крок за кроком концептуальний і логічний етапи проєктування РБД;
2. Розглянути приклади розроблення схеми БД

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

3

Вступ

Підхід до проектування БД:

НИСХОДЯЧИЙ

​

Базова методологія:

ПОБУДОВА ER-ДІАГРАМИ

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

4

Етапи проектування бази даних (низхідний підхід)�

Процес проектування бази даних складається з трьох основних етапів:

• концептуальне проєктування;
• логічне проєктування;
• фізичне проєктування.

Концептуальне (інфологічне) проектування БД

Концептуальне проектування бази даних - процес створення інформаційної моделі ПрО (концептуальної), яка не залежить від будь-яких фізичних аспектів її представлення

Зміст: Включає в себе визначення типів найважливіших сутностей та існуючих між ними зв'язків, атрибутів.

Опис:

• Концептуальна модель даних створюється на основі інформації, записаної в специфікаціях вимог користувачів.
• Концептуальне проєктування бази даних абсолютно не залежить від таких подробиць її реалізації:
• типу обраної цільової СУБД,
• використовуваних мов програмування,
• обраної моделі організації даних,
• типу обраної обчислювальної платформи, а також від будь-яких інших особливостей фізичної реалізації.
• Під час розроблення концептуальну модель даних постійно тестують і перевіряють на відповідність вимогам користувачів.

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

5

Логічне (даталогічне) проектуванняБД

Логічне проєктування бази даних - процес створення моделі ПрО на основі обраної моделі організації даних, але без урахування типу цільової СУБД та інших фізичних аспектів реалізації.

Опис:

• Концептуальна модель даних, створена на попередньому етапі, уточнюється і перетворюється на логічну модель даних.
• Логічна модель даних враховує особливості обраної моделі організації даних у цільовій СУБД (наприклад, реляційна модель).
• На цьому етапі вже має бути відомо, яку СУБД буде використано як цільову - реляційну, мережеву, ієрархічну або об'єктно-орієнтовану.
• Ігноруються всі інші характеристики обраної СУБД, наприклад, будь-які особливості фізичної організації її структур зберігання даних і побудови індексів.
• У процесі розроблення логічна модель даних постійно тестується і перевіряється на відповідність вимогам користувачів до даних і забезпечення підтримки всіх необхідних користувачам транзакцій.
• Для перевірки правильності логічної моделі даних використовується метод нормалізації
• Створена логічна модель даних є джерелом інформації для етапу фізичного проектування
• Логічна модель даних відіграє також важливу роль на етапі експлуатації та супроводу вже готової системи.

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

6

Фізичне проектування бази даних

Фізичне проектування бази даних - опис способу фізичної реалізації логічної моделі бази даних

Опис:

• на цьому етапі розглядають створення відносин, організацію файлів та індексів, призначених для забезпечення ефективного доступу до даних, а також усі пов'язані з цим обмеження цілісності та засоби захисту.

У разі РМД :

• створення набору реляційних таблиць і обмежень для них на основі інформації, представленої в логічній моделі даних;
• визначення конкретних структур зберігання даних і методів доступу до них (організація файлів, індексів), що забезпечують оптимальну продуктивність СУБД;
• розробка засобів захисту створюваної системи.

Зауваження!

• На етапах концептуального і логічного проєктування вирішується питання "ЩО РОБИТИ", а на етапі фізичного проєктування - "ЯК РОБИТИ".
• Етапи виконуються послідовно, оскільки зрозуміти, що треба зробити, слід перш, ніж вирішити, як це зробити.
• Етапи вимагають абсолютно різних навичок і досвіду, тому вимагають залучення фахівців різного профілю.

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

7

Послідовність дій �під час концептуального проєктування

Цей етап включає створення і перевірку локальної концептуальної моделі даних для окремих користувачів:

​

• Визначення типів сутностей
• Визначення типів зв'язків
• Визначення атрибутів і зв'язування їх із типами сутностей і зв'язків
• Визначення потенційних і вибір первинних ключів
• Перевірка на надмірність (видалення надлишкових зв'язків)
• Перевірка відповідності моделі вимогам користувацьких транзакцій (перевірка на достатність);

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

8

Послідовність дій під час логічного проектування

Цей етап включає такі кроки

1. Створення та перевірка локальної логічної моделі даних для окремих користувачів

1.1 Виключення особливостей, несумісних із РМ:

- перетворення зв'язків типу M:N за рахунок додавання нової сутності;

- перетворення складних зв'язків (не бінарних) на сутності;

- аналіз і перетворення рекурсивних зв'язків M:N;

- перетворення зв'язків, що мають атрибути, на сутності;

- видалення множинних атрибутів за рахунок додавання нової сутності;

1.2 Додатковий аналіз:

- повторна перевірка зв'язків типу 1:1;

- аналіз рекурсивних зв'язків 1:1, 1:M;

- аналіз зв'язків супер клас/підклас;

- перевірка моделі за допомогою правил нормалізації на відповідність вимогам 3-ї нормальної форми;

- повторна перевірка на надмірність (видалення надлишкових зв'язків);

- повторна перевірка відповідності відносин вимогам користувацьких транзакцій (перевірка на достатність);

1.3 Визначення набору відношень виходячи зі структури логічної моделі даних;

1.4 Відображення всіх вимог підсумкової ER-діаграми логічної моделі в документації;

1.5 Узгодження локальної логічної моделі даних з користувачем (замовником).

2. Створення та перевірка глобальної логічної моделі даних

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

9

Логічне проектування. Перетворення зв'язків типу M:N і зв'язків з атрибутами

Початкова модель:

​

​

​

​

Перетворена модель (варіант 1):���

​

​

Розкриття схеми:

Газета (ІН_газети, Назва_газети, Адреса_газети)

Об'єкт (ІН_об’єкту, Адреса_об’єкту)

Оголошення (ІН_газети(FК), ІН_об’єкту(FК), Дата)

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

10

Проблема: присутній зв'язок типу M:N або зв'язок з атрибутами

Розв'язання проблеми:

• створення проміжної сутності;
• зв'язок типу M:N замінюється двома зв'язками типу 1:М, що встановлюються від старих сутностей до новоствореної сутності.

Приклад 1: БП:

1. Оголошення про Об'єкт нерухомості може публікуватися в різних Газетах, причому багато разів в одній і тій самій газеті, але в іншу дату.

2. У Газеті публікуються оголошення про об'єкти нерухомості, але деякі газети не публікують інформацію про продаж об'єктів нерухомості.

Логічне проектування. Перетворення зв'язків типу M:N і зв'язків з атрибутами

Початкова модель:

​

​

​

​

Перетворена модель (варіант 2):���

​

​

Розкриття схеми:

Газета (ІН_газети, Назва_газети, Адреса_газети)

Об'єкт (ІН_об‘єкту, Адреса_об’єкту)

Оголошення (ІН_оголошення, ІН_газети(FK)(not Null), ІН_об’єкту(FK) (not Null), Дата)

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

11

Проблема: присутній зв'язок типу M:N або зв'язок з атрибутами

Розв'язання проблеми:

• створення проміжної сутності;
• зв'язок типу M:N замінюється двома зв'язками типу 1:М, що встановлюються від старих сутностей до новоствореної сутності.

Приклад 1: БП:

1. Оголошення про Об'єкт нерухомості може публікуватися в різних Газетах, причому багато разів в одній і тій самій газеті, але в іншу дату.

2. У Газеті публікуються оголошення про об'єкти нерухомості, але деякі газети не публікують інформацію про продаж об'єктів нерухомості.

Логічне проєктування. Перетворення складних зв'язків

Проблема: присутній складний зв'язок

Складний зв'язок - зв'язок між трьома і більше типами сутностей.

Розв'язання проблеми:

• створення проміжної сутності;
• введення нових зв'язків від старих сутностей до новоствореної

Приклад 2.1:(БП: об'єкти не перепродаються, в угоді бере участь 1 або 0 менеджер, 1 покупець, 1 об'єкт)

Початкова модель:

​

​

​

Перетворена модель:���

​

​

Розкриття схеми:

Покупець (ІН_покуп)

Об'єкт (ІН_об'єкт)

Менеджер (ІН_мен)

Угода (ІН_покуп(FК)(not Null), ІН_об'єкт(FК), ІН_мен (FК))

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

12

Логічне проектування. �Перетворення складних зв'язків з атрибутами. Міграція атрибутів

Приклад 2.2 : (БП: об'єкти перепродаються, в угоді бере участь 1 або 0 менеджер, 1 покупець, 1 об'єкт)

Початкова модель:

​

​

​

​

Перетворена модель:���

​

​

​

Розкриття схеми:

Покупець (ІН_покуп)

Об'єкт (ІН_об'єкт)

Менеджер (ІН_мен)

Угода (ІНугода, ІН_покуп(FК) (not Null), ІН_об'єкт(FК) (not Null), ІН_мен (FК))

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

13

Логічне проектування. �Перетворення складних зв'язків з атрибутами. Міграція атрибутів

Приклад 2.3: (БП: об'єкти перепродаються не частіше ніж 1 раз на добу, в угоді бере участь 1 або 0 менеджер, 1 покупець, 1 об'єкт, фіксується дата угоди)

Початкова модель:

​

​

​

​

Перетворена модель:

Варіант а:���

​

​

​

​

Розкриття схеми:

​

а) Угода (ІН_покуп(FК) (not Null), ІН_об'єкт(FК), ІН_мен (FК), Дата)

​

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

14

Логічне проектування. �Перетворення складних зв'язків з атрибутами. Міграція атрибутів

Приклад 2.3: (БП: об'єкти перепродаються, в угоді бере участь 1 менеджер, фіксується дата угоди)

Початкова модель:

​

​

​

​

Перетворена модель:�Варіант б:��

​

​

​

​

Розкриття схеми:

​

б) Угода (ІН_угода, ІН_покуп(FК) (not Null), ІН_об'єкт(FК) (not Null), ІН_мен(FК), Дата)

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

15

Логічне проектування. �Перетворення багатозначних атрибутів

Проблема: присутній багатозначний атрибут

Багатозначний атрибут - атрибут, що зберігає кілька значень, які відповідають одному екземпляру сутності

Розв'язання проблеми:

• створення нової сутності; Початкова модель:
• введення нових зв'язків від старої сутностей до нової

Приклад 3.1:

БП:

1.Телефонний номер належить тільки 1 відділенню

2. У відділення може бути більше одного номера

​

Перетворена модель:���

​

​

​

Розкриття схеми:

Відділення (Номер_відд, Назва_відд)

Телефон (Номер_телефону, Номер_відд (FК) (not Null))

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

16

Логічне проектування. �Перетворення багатозначних атрибутів

Проблема: присутній багатозначний атрибут

Багатозначний атрибут - атрибут, що зберігає кілька значень, які відповідають одному екземпляру сутності

Розв'язання проблеми:

• створення нової сутності; Початкова модель:
• введення нових зв'язків від старої сутностей до нової

Приклад 3.1:

БП:

1.Телефонний номер належить тільки 1 відділенню

2. У відділення може бути більше одного номера

​

Перетворена модель:���

​

​

​

Розкриття схеми:

Відділення (Номер_відд, Назва_відд, Телефон1, Телефон2, Телефон3)

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

17

Телефон3

Телефон2

Телефон1

Логічне проектування. �Перетворення багатозначних атрибутів

Приклад 3.2а:

БП:

1.Телефонний номер може належати кільком відділенням

2. У відділення може бути більше одного номера Початкова модель:

3. Існує перелік телефонних номерів,

що належать усьому підприємству. Номери з цього

списки закріплюються за відділеннями. Можуть існувати

номери, які наразі не використовуються.

Перетворена модель:

Крок 1.�

​

​

​

Крок2.��

​

Розкриття схеми:

Відділення (Номер_відд, Назва_відд)

Приналежність_телефону (Номер_телефону (FК), Номер_відд (FК))

Телефон (Номер_телефону)

​

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

18

Логічне проектування. �Перетворення багатозначних атрибутів

Приклад 3.2б:

​

БП:

1. телефонний номер може належати кільком співробітникам

2. У співробітника може бути більше одного номера або не бути телефону взагалі

Початкова модель:

3. Перелік телефонних номерів, що належать

співробітникам не зберігається.

​

Перетворена модель:���

​

​

​

Розкриття схеми:

Відділення (Номер_співробітника, ПІБ)

Телефон (Номер_телефону, Номер_сотр (FК))

​

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

19

Логічне проєктування. Аналіз рекурсивних зв'язків

Рекурсивний зв'язок:

• 1:1, з повною участю з боку дочірньої компанії
• 1:M з повною участю з боку М

Приклад 4.1 БП:�1.Усі співробітники мають консультантів

2. У співробітника може бути тільки один консультант

3. Консультант може консультувати X Співробітників (0:1 або 0:М)

Початкова модель: Співробітник (1:М, з повною участю)

​

​

​

​

​

​

​

​

Розкриття схеми:

Співробітник (Номер_співробітника, ПІБ, Посада, Зарплата, Адреса, Телефон, Консультант(FК) (not Null))

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

20

Логічне проєктування. Аналіз рекурсивних зв'язків

Рекурсивний зв'язок: Початкова модель:

• 1:1, з частковою участю з боку дочірньої компанії
• 1:M з частковою участю з боку М

Приклад 4.2 БП:�1. Не кожен співробітник має

Консультанта (част. участь з боку дочірньої компанії)

2. у співробітника може бути тільки

один консультант.

3. Консультант може консультувати X співробітників (0:1 або 0:М).

Перетворена модель:�

�

​

​

​

​

​

​

​

Розкриття схеми:

Співробітник (Номер_сотр, ПІБ)

Консультація (Консультований(FК), Консультант(FК) (not Null))

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

21

Логічне проєктування. Аналіз рекурсивних зв'язків

Перетворена модель:�

�

​

​

​

Розкриття схеми:

Співробітник (Номер_сотр, ПІБ)

Консультація (Консультований(FК), Консультант(FК) (not Null))

Співробітник Консультація (1:1, з частковою участю Співробітників в обох зв'язках)

​

​

​

�

​

Консультація (1:М, з частковою участю Співробітників в обох зв'язках)

​

​

​

�

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

22

Логічне проєктування. Аналіз рекурсивних зв'язків

Рекурсивний зв'язок: Початкова модель:

• M:N

Приклад 4.3 БП:�1. У співробітника може бути більше

одного консультанта.

2. Консультант може

консультувати кількох співробітників.

Перетворена модель:�

�

​

​

Співробітник Консультація (M:N)

​

Розкриття схеми:

Співробітник (Номер_сотр, ПІБ)

Консультація (Консультований(FК), Консультант(FК))

​

​

​

�

​

​

​

�

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

23

Логічне проєктування. Повторна перевірка зв'язків 1:1

дописати

�

​

​

​

�

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

24

Логічне проектування. Перевірка на надмірність зв'язків

​

• Слід прагнути створювати мінімальні моделі
• За наявності декількох зв'язків між сутностями, необхідно перевірити модель на надмірність.

Приклад 5.1

БП:

1. Розглядається тільки поточний шлюб між чоловіком і жінкою
2. Враховуються всі наявні діти

Запитання: Хто є мамою і татом дитини?

​

​

�

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

25

Логічне проектування. Перевірка на надмірність зв'язків

Приклад 5.2

БП:

1. Розглядається всі шлюби між чоловіком і жінкою
2. Враховуються всі наявні діти
3. Одна й та сама пара може повторно укладати шлюб

Запитання: Хто є мамою і татом дитини?

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

26

Логічне проектування. Перевірка на надмірність зв'язків

Приклад 5.3

БП:

1. Розглядається всі шлюби між чоловіком і жінкою
2. Враховуються всі наявні діти
3. Одна й та сама пара може повторно укладати шлюб

Запитання: Хто є мамою і татом дитини?

Чи в шлюбі народжена дитина і якому?

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

27

Бере участь у шлюбі

Шлюб

M

M

Логічне проектування. �Перевірка відношень із використанням засобів нормалізації�(оглядово)

Нормалізація - процес перевірки та реорганізації сутностей і атрибутів з метою задоволення вимог до реляційної моделі даних.

У результаті проведення нормалізації має бути створено структуру даних, за якої інформація про кожен факт зберігається тільки в одному місці, і розв'язано проблеми модифікації даних (аномалії оновлення).

Процес нормалізації зводиться до послідовного приведення структури даних до нормальних форм - формалізованих вимог до організації даних.

Відомі шість нормальних форм:

• перша нормальна форма (1НФ);
• друга нормальна форма (2НФ);
• третя нормальна форма (3НФ);
• нормальна форма Бойса - Кодда (посилена 3НФ);
• четверта нормальна форма (4НФ);
• п'ята нормальна форма (5НФ).

На практиці зазвичай обмежуються приведенням даних до третьої нормальної форми.

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

28

Логічне проектування. �Перевірка відношень із використанням засобів нормалізації�(оглядово)

Нормальні форми засновані на понятті функціональної залежності (ФЗ).

Функціональна залежність (ФЗ).

Атрибут В сутності Е функціонально залежить від атрибута А сутності Е тоді й тільки тоді, коли кожне значення атрибута А однозначно визначає одне значення атрибута В.

Повна функціональна залежність.

Атрибут В сутності Е повністю функціонально залежить від низки атрибутів А сутності Е тоді і тільки тоді, коли В функціонально залежить від А і не залежить від жодного підряду А.

​

Приклад ФЗ

Співробітник (СпівробітникІН, ПІБ, Посада, Оклад)

​

ФЗ1: СпівробітникІН → ПІБ, Посада, Оклад

ФЗ2: Посада → Оклад

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

29

Логічне проектування. �Перевірка відношень із використанням засобів нормалізації�(оглядово)

Перша нормальна форма (1НФ). Сутність перебуває в 1НФ тоді й тільки тоді, коли всі атрибути містять атомарні значення, тобто не повинно зустрічатися кількох значень атрибута для одного екземпляра або складних значень, за частиною яких планується пошук інформації.

Приклад 6. БП: У відділення може бути більше одного телефону, телефон належить тільки одному відділенню

​

​

Для приведення сутності до 1НФ випливає :

1) розділити складні атрибути на атомарні;

Відділення (Номер_відд, Назва_відд, Місто, Вулиця, Будинок_фіс, ?)

2) створити нову сутність, перенести в неї всі "багатозначні" атрибути, установити зв'язок від колишньої сутності до нової (PК колишньої сутності стане зовнішнім ключем (FK) для нової сутності), вибрати РК з наявних атрибутів (або створити сурогатний);

Неправильно!: Відділення (Номер_відд, Назва_відд, Місто, Вулиця, Будинок_офіс, Тел1, Тел2, Тел3)

Правильно! : Відділення (Номер_відд, Назва_відд, Місто, Вулиця, Будинок_офіс)

Телефон (Телефон, Номер_відд (ВК))

​

​

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

30

Логічне проектування. �Перевірка відношень із використанням засобів нормалізації�(оглядово)

Друга нормальна форма (2НФ). Сутність перебуває у 2НФ, якщо вона перебуває в 1НФ і кожен неключовий атрибут повністю функціонально залежить від первинного ключа (не повинно бути залежності від частини ключа). Друга нормальна форма має сенс тільки для сутностей, що мають складений первинний ключ.

Описи предметної області можна оформити у вигляді таких БП:

1. Кожним проєктом послідовно може керувати кілька співробітників із фіксуванням Дати початку і Дати завершення керівництва;
2. Співробітник може керувати багатьма проєктами, але кожним проєктом - тільки один раз (один проміжок часу).

Керівництво (ПроектІН, СпівробітникІН, ДатаПочатку, ДатаЗавершення, ПІБ, Посада)

ФЗ1: ПроектІН, СпівробітникІН → ДатаПочатку, ДатаЗавершення (ПФЗ)

ФЗ2: СпівробітникІН → ПІБ, Посада (ЧФЗ)

Тоді для приведення сутності до 2НФ випливає:

• виділити атрибути, які залежать тільки від частини первинного ключа, створити нову сутність;
• помістити атрибути, що залежать від частини ключа, у їхню власну (нову) сутність разом з атрибутом, від якого вони залежать;
• використовувати атрибут, що визначає цю залежність, як первинний ключ нової сутності;
• встановити ідентифікуючий зв'язок від нової сутності до колишньої сутності

​

Керівництво (ПроектІН, СпівробітникІН (ВК), ДатаПочатку, ДатаЗавершення)

Співробітник (СпівробітникІН, ПІБ, Посада)

​

​

​

​

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

31

Логічне проектування. �Перевірка відношень із використанням засобів нормалізації�(оглядово)

​

2НФ дає змогу уникнути таких аномалій під час виконання операцій:

• Оновлення (UPDATE). Мало б місце дублювання даних про співробітника, якщо він керує кількома проектами. Якщо дані про співробітника змінювалися б, необхідно було міняти кілька записів (за кількістю ведених проєктів).
• Вставка (INSERT). Неможливо було б ввести дані про співробітника, якщо він на цей момент не керував проєктами.
• Видалення (DELETE). Якщо співробітник тимчасово припиняв би керівництво проєктами, дані про нього втрачалися.

​

​

​

​

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

32

Логічне проектування. �Перевірка відношень із використанням засобів нормалізації�(оглядово)

Третя нормальна форма (3НФ). Сутність перебуває в 3НФ формі, якщо вона перебуває в другій нормальній формі й жоден неключовий атрибут не залежить від іншого неключового атрибута (виключається транзитивна залежність, тобто не повинно бути взаємозалежності між неключовими атрибутами).

Приклад 7

БП: Оклад співробітника залежить від його посади.

Співробітник (СпівробітникІН, ПІБ, Посада, Оклад)

ФЗ1: СпівробітникІН → ПІБ, Посада, Оклад

ФЗ2: Посада → Оклад (ТФЗ)

Для приведення сутності до 3НФ випливає:

• створити нову сутність і перенести в неї атрибути з однією і тією ж залежністю від неключового атрибута;
• використовувати атрибут, що визначає цю залежність, як первинний ключ нової сутності;
• встановити неідентифікуючий зв'язок від нової сутності до старої.

​

Співробітник (СпівробітникІН, ПІБ, ПосадаНазва (ВК))

Посада (ПосадаНазва, Оклад)

​

​

​

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

33

Логічне проектування. �Перевірка відношень із використанням засобів нормалізації�(оглядово)

Третя нормальна форма також дає змогу уникнути низки аномалій, які виникали б без приведення до 3НФ:

• Оновлення (UPDATE). Мало б місце дублювання даних про оклад, якщо однакову посаду обіймають кілька співробітників. Якщо оклад відповідної посади змінювався, необхідно було б змінювати кілька записів (за кількістю співробітників на одній посаді).
• Вставка (INSERT). Неможливо було б ввести дані про оклад, що відповідає посаді, якщо наразі немає співробітника, який обіймає цю посаду.
• Видалення (DELETE). У разі видалення з таблиці співробітника, який обіймає унікальну посаду, дані про оклад губилися б.

​

​

​

​

​

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

34

Предметна область "Результат навчання"

БП:

• Одну дисципліну може викладати багато викладачів. Викладач може викладати багато дисциплін. Однак викладачі не можуть викладати будь-яку дисципліну, вони мають свою спеціалізацію.
• Дисципліни, що мають однакову назву, але різну кількість годин, вважаються різними дисциплінами. Однакові дисципліни (збігається назва і кількість годин) для різних студентів можуть викладати різні викладачі.
• На кафедрі працює багато викладачів, кожен викладач закріплений за однією кафедрою.
• Викладач може мати більше одного номера телефону, деякі викладачі можуть мати однаковий телефонний номер.
• Викладач обіймає тільки одну посаду.
• Оклад викладача визначається його посадою.
• Студентська група складається більш ніж з одного студента, кожен студент закріплений за однією групою.

Організація навчального процесу:

• Різні студенти однієї групи можуть вивчати різні дисципліни.
• Після вивчення дисципліни студент отримує підсумковий бал (оцінку на іспиті). Фіксується дата отримання підсумкового бала. Підсумковий бал з дисципліни може бути отримано в різні дати (тобто іспит викладачеві можна здавати в будь-який день сесії).
• Підсумковий бал виставляє викладач, який викладав студенту цю дисципліну. Якщо студент отримав незадовільний бал, він може перездати дисципліну тільки викладачеві, який читає таку саму дисципліну.

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

35

Предметна область "Результат навчання"

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

36

Приклад. Предметна область В-03 "Відомості про проєкти 1" (складн.1)

​

​

​

​

​

​

​

​

​

​

Рисунок -Дан фрагмент документа "Відомості про проекти 1"

​

БП: 1. На проєкті може працювати багато виконавців, але має працювати хоча б 1 виконавець

2. Виконавець бере участь у кількох проєктах, але тимчасово може не брати участь у проєктах

3. Замовник може замовляти більше 1 проєкту, у проєкту тільки 1 замовник

4. У виконавця тільки 1 посада, яка не залежить від проєкту

5. Бюджет проєкту призначається замовником і не залежить від кількості та кваліфікації виконавців

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

37

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

38

Приклад. Предметна область В-09 "Відомості про проєкти 2" (складн.2)

Варіант1

БП:1 Наше підприємство може виконувати одночасно кілька проєктів, номер проєкту унікальний у рамках усього підприємства

2 Співробітники можуть одночасно працювати на декількох проектах.

3а.Оплата залежить від конкретної роботи

4.У проекту може бути тільки один замовник, замовник може замовляти багато проектів

5 У проєкту зазвичай кілька етапів (як мінімум 1).

6а. Номер етапу унікальний тільки в рамках проєкту

Рисунок -Дан фрагмент документа "Відомості про проекти 2"

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

39

Приклад. Предметна область В-09 "Відомості про проєкти 2"

Варіант2

БП:1 Наше підприємство може виконувати одночасно кілька проєктів, номер проєкту унікальний у межах усього підприємства

2 Співробітники можуть одночасно працювати на кількох проєктах.

3б. Оплата залежить від посади виконавця

4.У проекту може бути тільки один замовник, замовник може замовляти багато проектів

5 У проєкту зазвичай кілька етапів (як мінімум 1).

6б. Номер етапу унікальний у межах усього підприємства

Рисунок -Дан фрагмент документа "Відомості про проекти 2"

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

40

Приклад. Предметна галузь В-02 "Друк літератури та розподіл по бібліотеках міста" (складн.1,5)

Варіант1

БП:1.У Бібліотеці знаходяться безліч Видань.

2.Одне Видання може перебувати в декількох Бібліотеках.

3. В одного Видання може бути більше одного Автора.

4. Деякі Видання можуть бути відсутні в Бібліотеках міста.

5а. Видання видається в 1 Видавництві, у Видавництві багато Видань.

Рисунок -Даний фрагмент документа "Друк літератури і розподіл. по бібліотеках міста"

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

41

Приклад. Предметна область В-02 "Друк літератури та розподіл по бібліотеках міста"

(складн.2,5)

БП (Варіант 2):

1.У Бібліотеці знаходяться безліч Видань.

2.Одне Видання може перебувати в декількох Бібліотеках.

3. В одного матеріалу (рукопису) може бути більше одного Автора. Автор може писати більше одного матеріалу (рукопису).

4. Деякі Видання можуть бути відсутні в Бібліотеках міста.

5б. Матеріал (рукопис) може перевидаватися (не частіше ніж 1 раз на рік), може перевидаватися в різних видавництвах.

Рисунок -Даний фрагмент документа "Друк літератури і розподіл по бібліотеках міста"

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

42

Приклад. Предметна область В-01 "Облік автомобілів, зданих в оренду" (складн.1)

Варіант 1.

БП:

1. У власника може бути більше одного автомобіля

2. Автомобіль належить одному постійному власнику

3. Номер кузова автомобіля унікальний

4. Орендар може орендувати конкретний автомобіль в одну дату тільки один раз, але може взяти в ту саму дату інший автомобіль.

5. Орендна плата визначається в момент здачі автомобіля в оренду (не постійна)

Рисунок -Дан фрагмент документа "Облік автомобілів, зданих в оренду"

Варіант 2.

БП:

1. У власника може бути більше одного автомобіля

2. Автомобіль належить одному постійному власнику

3. Номер кузова автомобіля унікальний

4. Орендар може в одну дату брати в оренду тільки 1 автомобіль

5. Орендна плата автомобіля постійна

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

43

Приклад. В-06. Дано фрагмент документа "Агентство нерухомості" (складн.1)

БП (варіант А):

1. У разі повторного продажу об'єкт нерухомості реєструється заново, тобто присвоюється новий номер.
2. Об'єкт нерухомості належить тільки одному власнику-продавцю.
3. Одному власнику можуть належати багато об'єктів.
4. В угоді може бути тільки один покупець.
5. Один покупець може здійснювати багато угод.

БП (варіант Б):

1. Під час повторного продажу об'єкт нерухомості заново не реєструють, а беруть інформацію про нього з БД, тобто використовують старий номер (такі характеристики, як адреса, вид фонду, площа, не змінюються).
2. В один момент часу Об'єкт нерухомості належить тільки одному власнику-продавцю, тобто Об'єкт нерухомості при повторному продажу має вже іншого одного власника.
3. Одному власнику можуть належати багато об'єктів.
4. В угоді може бути тільки один покупець.
5. Один покупець може здійснювати багато угод.

Рисунок -Дан фрагмент документа "Агентство нерухомості"

�В-05 ПЗ "Навчальний процес на 2019/2020"

БП:

1. Навчальний план охоплює всі групи
2. Викладач може нічого не викладати у 2019/2020 році
3. Дисципліна може не читатися у 2019/2020 році
4. Кожна група закріплюється за факультетом, на факультеті багато груп.
5. На вивчення однієї і тієї самої дисципліни різним групам може виділятися різна кількість годин. Дисципліни, що мають однакову назву, але різну кількість годин, вважаються різними дисциплінами.
6. Кожен викладач закріплений за кафедрою
7. Навантаження викладача залежить від групи та дисципліни

​

​

​

​

​

​

Дод. ПЗ "План дипломного проектування на 2019/2020"

БП: 8. Студенти 4,5 курсів крім вивчення планових дисциплін займаються написанням дипломної роботи одного з типів: бакалаврська робота, дипломна робота спеціаліста, робота магістра

9. За кожним студентом 4,5 курсу (бакалавром, спеціалістом, магістром) закріплюють керівника (викладача), а також тему дипломної роботи і призначають підприємство (Базу практики) для проходження переддипломної практики, студент може проходити практику на будь-якій Базі практики.

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

44

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

45

Приклад. В-06. Дано фрагмент документа "Чемпіонат з автоперегонів Формула-1" (складн.2)

​

БП:

1. У команді м.б. тільки кілька Гонщиків, Гонщик може бути тільки в одній команді

2. У команди може бути кілька постійних Спонсорів, Спонсор спонсорує тільки 1 Команду.

3 Траса характеризується протяжністю і розташовується тільки в одній Країні, у країні можуть розташовуватися кілька Трас.

4. Кількість кіл залежить від конкретного змагання (перегонів), яке характеризується датою та трасою проведення.

5. Кожне змагання (перегони) проходить тільки на одній трасі. На одній трасі може проходити багато змагань

6а. В одну дату на трасі проходить тільки 1 змагання

бб. В одну дату на трасі може проходити багато змагань

Рисунок -Даний фрагмент документа "Чемпіонат з автоперегонів Формула-1"