1 | Космос | 3
3 | Сидоров | 2 | 33-22-11 | 2 | Климат | 2
Таблиця 1 Відношення СПІВРОБІТНИКИ_ВІДДІЛИ_ПРОЕКТИ
Аномалії оновлення
Навіть одного погляду на таблицю відношення СПІВРОБІТНИКИ_ВІДДІЛИ_ПРОЕКТИ достатньо, щоб побачити, що дані збережуться в ній з великою надлишковістю. В багатьох рядках повторюються прізвища співробітників, номери телефонів, найменування проектів. Крім того, в даному відношенні збережуться разом незалежні один від одного дані - і дані про співробітників, і про відділи, і про проекти, і про роботи за проектами. Поки ніяких дій з відношенням не проводиться, це не страшно. Але як тільки полягання предметної області змінюється, то, при спробах відповідним чином змінити полягання бази даних, виникає велика кількість проблем.
Історично ці проблеми одержали назву аномалії оновлення. Спроби дати строге поняття аномалії в базі даних не є цілком задовільними [51, 7]. В даних роботах аномалії визначені як суперечність між моделлю предметної області і фізичною моделлю даних, підтримуваних засобами конкретної СУБД. "Аномалії виникають у тому випадку, коли наші знання про предметну область виявляються, з якихось причин, невимовними в схемі БД або що входять в суперечність з нею" [7]. Ми дотримуємося іншої точки зору, що полягає в тому, що аномалій в значенні визначень згаданих авторів немає, а є або неадекватність моделі даних предметної області, або деякі додаткові труднощі в реалізації обмежень предметної області засобами СУБД. Більш глибоке обговорення проблеми строгого визначення поняття аномалій виходить за межі даної роботи.
Таким чином, ми дотримуватимемося інтуїтивного поняття аномалії як неадекватності моделі даних предметної області, (що говорить насправді про те, що логічна модель даних просто невірна!) або як необхідності додаткових зусиль для реалізації всіх обмежень визначених в предметній області (додатковий програмний код у вигляді трігерів або ззбережених процедур).
Оскільки аномалії проявляють себе при виконанні операцій, що змінюють полягання бази даних, то розрізняють наступні види аномалій:
Аномалії вставки (INSERT)
Аномалії оновлення (UPDATE)
Аномалії видалення (DELETE)
Відносно СПІВРОБІТНИКИ_ВІДДІЛИ_ПРОЕКТИ можна привести приклади наступних аномалій:
Аномалії вставки (INSERT)
У відношення СПІВРОБІТНИКИ_ВІДДІЛИ_ПРОЕКТИ не можна вставити дані про співробітника, який поки не бере участь ні в одному проекті. Дійсно, якщо, наприклад, в другому відділі з'являється новий співробітник, скажімо, Хутровиків, і він поки не бере участь ні в одному проекті, то ми повинні вставити у відношення кортеж (4, Хутровиків, 2, 33-22-11, null, null, null). Це зробити неможливо, оскільки атрибут Н_ПРО (номер проекту) входить до складу потенційного ключа, і, отже, не може містити null-значень.
Точно також не можна вставити дані про проект, над яким поки не працює жоден співробітник.
Причина аномалії - зберігання в одному відношенні різнорідної інформації (і про співробітників, і про проекти, і про роботи за проектом).
Висновок - логічна модель даних неадекватна моделі предметної області. База даних, заснована на такій моделі, працюватиме неправильно.
Аномалії оновлення (UPDATE)
Прізвища співробітників, найменування проектів, номери телефонів повторюються в багатьох кортежах відношення. Тому якщо співробітник міняє прізвище, або проект міняє найменування, або міняється номер телефону, то такі зміни необхідно одночасно виконати у всіх місцях, де це прізвище, найменування або номер телефону зустрічаються, інакше відношення стане некоректним (наприклад, один і той же проект в різних кортежах називатиметься по-різному). Таким чином, оновлення бази даних однією дією реалізувати неможливо. Для підтримки відношення в цілісному стані необхідно написати трігер, який при оновленні одного запису коректно виправляв би дані і в інших місцях.
Причина аномалії - надмірність даних, також породжена тим, що в одному відношенні збережеться різнорідна інформація.
Висновок - збільшується складність розробки бази даних. База даних, заснована на такій моделі, працюватиме правильно тільки за наявності додаткового програмного коду у вигляді трігерів.
Аномалії видалення (DELETE)
При видаленні деяких даних може відбутися втрата іншої інформації. Наприклад, якщо закрити проект "Космос" і видалити всі рядки, в яких він зустрічається, то будуть втрачені всі дані про співробітника Петрове. Якщо видалити співробітника Сидорова, то буде втрачена інформація про те, що у відділі номер 2 знаходиться телефон 33-22-11. Якщо за проектом тимчасово припинені роботи, то при видаленні даних про роботи за цим проектом будуть видалені і дані про самий проект (найменування проекту). При цьому якщо був співробітник, який працював тільки над цим проектом, то будуть втрачені і дані про цього співробітника.
Причина аномалії - зберігання в одному відношенні різнорідної інформації (і про співробітників, і про проекти, і про роботи за проектом).
Висновок - логічна модель даних неадекватна моделі предметної області. База даних, заснована на такій моделі, працюватиме неправильно.
Функціональні залежності
Відношення СПІВРОБІТНИКИ_ВІДДІЛИ_ПРОЕКТИ знаходиться в 1НФ, при цьому, як було показано вище, логічна модель даних не адекватна моделі предметної області. Таким чином, першої нормальної форми недостатньо для правильного моделювання даних.
Визначення функціональної залежності
Для усунення вказаних аномалій (а насправді для правильного проектування моделі даних!) застосовується метод нормалізації відносин. Нормалізація заснована на понятті функціональної залежності атрибутів відношення.
Визначення 1. Хай - відношення. Безліч атрибутів функціонально залежно від безлічі атрибутів ( функціонально визначає ) тоді і тільки тоді, коли для будь-якого полягання відношення для будь-яких кортежів з того, що слідує що (тобто у всіх кортежах, що мають однакові значення атрибутів , значення атрибутів також співпадають в будь-якому поляганні відносини ). Символічно функціональна залежність записується
.
Безліч атрибутів називається детермінантом функціональної залежності, а безліч атрибутів називається залежною частиною.
Зауваження. Якщо атрибути складають потенційний ключ відношення , то будь-який атрибут відношення функціонально залежить від .
Приклад 1. Відносно СПІВРОБІТНИКИ_ВІДДІЛИ_ПРОЕКТИ можна привести наступні приклади функціональних