6. Друга нормальна форма. Приведення моделі бд до другої нормальної форми.

Дуже часто первинний ключ відношення включає кілька атрибутів (у такому випадку його називають складеним), як це є в наших прикладах «Діти» та «Співробітники». При цьому залежність інших атрибутів від ключа молжет бути як повною, так і неповною. Як було сказано ранеее, визначення повної функціональної залежності таке (див. пункт «Функциональні залежності):  неключовий атрибут функціонально повно залежить від складеного ключа, якщо він функціонально залежить від усього ключа в цілому, але не знаходиться у функціональній залежності від якого-небудь із атрибутів, що входять у нього.

Визначення 3. Відношення R знаходиться в другій нормальній формі (2НФ) тоді і тільки тоді, коли відношення знаходиться в 1НФ і не має неключових атрибутів, що залежать від частини складеного ключа. (Неключовий атрибут - це атрибут, що не входить до складу ніякого потенційного ключа). Іншими словами, відношення знаходиться в 2NF, якщо воно знаходиться в 1NF і кожен неключовий атрибут функціонально повно залежить від первинного ключа.

Зауваження. Якщо потенційний ключ відношення є простим, то відношення автоматично знаходиться в 2НФ.

Приклад:

Нехай є відношення ПОСТАЧАННЯ (N_ПОСТАЧАЛЬНИКА, ТОВАР, ЦІНА).  Постачальник може поставляти різні товари, а той самий товар може поставлятися різними постачальниками. Тоді ключ відношення - "N_постачальника + товар". Нехай усі постачальники поставляють товар по одній і тій самій ціні. Тоді маємо наступні функціональні залежності:

• N_постачальника, товар -> ціна

• товар -> ціна

Неповна функціональна залежність атрибута "ціна" від ключа приводить до наступного аномалії: при зміні ціни товару необхідний повний перегляд відношення для того, щоб змінити всі записи про його постачальників. Дана аномалія є наслідком того факту, що в одній структурі даних об'єднані два семантичних факти. Наступне розкладання дає відношення в 2НФ:

• ПОСТАЧАННЯ (N_ПОСТАЧАЛЬНИКА, ТОВАР)

• ЦІНА_ТОВАРУ (ТОВАР, ЦІНА)

 

Для того, щоб усунути залежність атрибутів від частини складеного ключа, потрібно зробити декомпозицію відношення на кілька відношень. При цьому ті атрибути, що залежать від частини складеного ключа, виносяться в окреме відношення.

 

            З точки зору процедур реляційної алгебри, для реалізації цієї декомпозиції з метою приведення відношення до 2NF необхідно:

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

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

Приведення до другої нормальної форми відношення “Діти” наведене нижче.

Відношення R2 (1NF):

Таб_номер	Ім'я_дитини	Вік дитини	ПІБ	Оклад	Офіс	Телефон
211	С	10	Іванов І.І.	200	12	6-16
211	Ж	7	Іванов І.І.	200	12	6-16
211	В	3	Іванов І.І.	200	12	6-16
358	Т	5	Петрук К.М.	300	12	6-16
360	Ж	8	Сидоров О.Б.	250	5	3-06
360	В	6	Сидоров О.Б.	250	5	3-06

Приведення відношення R2 (1NF) до 1NF:

 

Відношення R3 (2NF):

Таб_номер	Ім'я_дитини	Вік дитини
211	С	10
211	Ж	7
211	В	3
358	Т	5
360	Ж	8
360	В	6

Відношення R4 (2NF):

Таб_номер	ПІБ	Оклад	Офіс	Телефон
211	Іванов І.І.	200	12	6-16
211	Іванов І.І.	200	12	6-16
211	Іванов І.І.	200	12	6-16
358	Петрук К.М.	300	12	6-16
360	Сидоров О.Б.	250	5	3-06
360	Сидоров О.Б.	250	5	3-06

Відмічені аномалії усунуто.

Тим не менш, наявність транзитивної залежності

Таб_номер->Офіс;

Офіс ->Телефон

породжує аномалії наступного характеру:

• має місце дублювання інформації про телефон для співробітників одного офісу;

• існує проблема надмірності, оскільки зміна телефону офісу спричиняє необхідність пошуку і зміни номерів усіх співробітників цього офісу;

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

 

Базовий приклад. Відношення СПІВРОБІТНИКИ_ВІДДІЛИ_ПРОЕКТИ також не знаходиться в 2НФ, тому що є атрибути, що залежать від частини складеного ключа:

Залежність атрибутів, що характеризують співробітника від табельного номера співробітника є залежністю від частини складеного ключа:

Н_СПІВРОБ -> ПРІЗ

Н_СПІВРОБ -> Н_ВІД

Н_СПІВРОБ -> ТЇВ

Залежність найменування проекту від номера проекту є залежністю від частини складеного ключа:

Н_ПРО -> ПРОЕКТ

Щоб усунути залежність атрибутів від частини складеного ключа (привести відношення до другої нормальної форми), відношення СПІВРОБІТНИКИ_ВІДДІЛИ_ПРОЕКТИдекомпонуємо на три відношення - СПІВРОБІТНИКИ_ВІДДІЛИ, ПРОЕКТИ, ЗАВДАННЯ.

Відношення СПІВРОБІТНИКИ_ВІДДІЛИ (Н_СПІВРОБ, ПРІЗ, Н_ВІД, ТЕЛ):

   Функціональні залежності:

   Залежність атрибутів, що характеризують співробітника від табельного номера співробітника:

Н_СПІВРОБ -> ПРІЗ

Н_СПІВРОБ -> Н_ВІД

Н_СПІВРОБ -> ТЕЛ

   Залежність номера телефону від номера відділу:

Н_ВІД -> ТЕЛ

Н_СПІВРОБ	ПРІЗ	Н_ВІД	ТЕЛ
1	Иванов	1	11-22-33
2	Петров	1	11-22-33
3	Ситник	2	33-22-11

Таблиця 2 Відношення СПІВРОБІТНИКИ_ВІДДІЛИ

Відношення ПРОЕКТИ (Н_ПРО, ПРОЕКТ):

   Функціональні залежності:

Н_ПРО -> ПРОЕКТ

Н_ПРО	ПРОЕКТ
1	Космос
2	Климат

Таблица 3 Отношение ПРОЕКТЫ

Відношення ЗАВДАННЯ (Н_СПІВРОБ, Н_ПРО, Н_ЗАВДАН):

   Функціональні залежності:

{Н_СПІВРОБ, Н_ПРО} -> Н_ЗАВДАН

Н_СПІВРОБ	Н_ПРО	Н_ЗАВДАН
1	1	1
1	2	1
2	1	2
3	1	3
3	2	2

Таблиця 4 Відношення ЗАВДАННЯ

 

Аналіз декомпонованих відношень

Відношення, отримані в результаті декомпозиції, знаходяться в 2НФ. Дійсно, відношення СПІВРОБІТНИКИ_ВІДДІЛИ і ПРОЕКТИ мають прості ключі, отже автоматично знаходяться в 2НФ, відношення ЗАВДАННЯ має складений ключ, але єдиний неключовий атрибут Н_ЗАВДАН функціонально залежить від усього ключа {Н_СПІВРОБ, Н_ПРО}.

Частина аномалій оновлення усунута. Так, дані про співробітників і проекти тепер зберігаються в різних відношеннях, тому з появою співробітників, що не беруть участі у жодному проекті просто додаються кортежі у відношення СПІВРОБІТНИКИ_ВІДДІЛИ. Точно так само, з появою проекту, над яким не працює жоден співробітник, просто вставляється кортеж у відношення ПРОЕКТИ.

Прізвища співробітників і найменування проектів тепер зберігаються без надмірності. Якщо співробітник змінить прізвище чи проект змінить найменування, то таке відновлення буде зроблено в одному місці.

Якщо по проектові тимчасово припинені роботи, але потрібно, щоб сам проект зберігся, то для цього проекту видаляються відповідні кортежі у відношенні ЗАВДАННЯ, а дані про сам проект і дані про співробітників, що брали участі у проекті, залишаються у відношеннях ПРОЕКТИ і СПІВРОБІТНИКИ_ВІДДІЛИ.

Проте, частина аномалій розв'язати не удалося.

 Аномалії вставки, що залишилися, (INSERT)

У відношення СПІВРОБІТНИКИ_ВІДДІЛИ не можна вставити кортеж (4, Пушняк, 1, 33-22-11), тому що при цьому вийде, що два співробітники з 1-го відділу (Іванов і Пушняк) мають різні номери телефонів, а це суперечить моделі предметної області. У цій ситуації можна запропонувати два рішення, у залежності від того, що реально відбулося в предметній області. Інший номер телефону може бути введений по двох причинах - помилково людиною, що вводить дані про нового співробітника, чи тому, що номер у відділі дійсно змінився. Тоді можна написати тригер, який при вставці запису про співробітника перевіряє, чи збігається телефон із уже наявним телефоном в іншого співробітника цього ж відділу. Якщо номери відрізняються, то система повинна поставити запитання, чи залишити старий номер у відділі чи замінити його новим. Якщо потрібно залишити старий номер (новий номер уведений помилково), то кортеж з даними про нового співробітника буде вставлений, але номер телефону буде в нього буде той, котрий уже є у відділі (у даному випадку, 11-22-33). Якщо ж номер у відділі дійсно змінився, то кортеж буде вставлений з новим номером, і одночасно будуть змінені номери телефонів у всіх співробітників цього ж відділу. І в тому, і в іншому випадку не обійтися без розробки громіздкого тригера.

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

Висновок - збільшується складність розробки бази даних. База даних, заснована на такій моделі, буде працювати правильно тільки при наявності додаткового програмного коду у вигляді тригерів.

Аномалії оновлення, що залишилися, (UPDATE)

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

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

Висновок - збільшується складність розробки бази даних. База даних, заснована на такій моделі, буде працювати правильно тільки при наявності додаткового програмного коду у вигляді тригерів.

 Аномалії видалення, що залишилися, (DELETE)

При видаленні деяких даних як і раніше, може відбутися втрата іншої інформації. Наприклад, якщо видалити співробітника Ситника, то буде втрачена інформація про те, що у відділі номер 2 знаходиться телефон 33-22-11.

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

Висновок - логічна модель даних неадекватна моделі предметної області. База даних, заснована на такій моделі, буде працювати неправильно.

            Відмітимо, що при переході до другої нормальної форми відносини стали майже адекватними предметній області. Залишилися також труднощі в розробці бази даних, пов'язані з необхідністю написання тригерів, що підтримують цілісність бази даних. Ці труднощі тепер пов'язані тільки з одним відношенням СПІВРОБІТНИКИ_ВІДДІЛИ.