Різновиди нормальних форм. Перша нормальна форма
Поняття першої нормальної форми вже обговорювалося в лекції про реляційне моделювання даних. Перша нормальна форма (1НФ) - це звичайне відношення. Відповідно до нашого визначення відношень, будь-яке відношення автоматично вже знаходиться в 1НФ[1]. Нагадаємо коротко властивості відношень (це і будуть властивості 1НФ):
· У відношенні немає однакових кортежів.
· Кортежі не упорядковані.
· Атрибути не упорядковані і різняться за найменуванням.
· Усі значення атрибутів атомарні.
Тим неменш, найчастіше 1NF визначають так: відношення знаходиться в 1NF тоді і тільки тоді, коли усі атрибути, що входять у нього, є атомарними (неподільними).
Приведення до першої нормальної форми означає приведення представлення даних до суупності універсальних відношень. Очевидно, що, виходячи з визначення відношення, це означає «атомаризацію» атрибутів, яка необхідна у першу чергу для для багатозначних атрибутів. Приклад такої процедури (розбиття багатозначного атрибуту на 2 інших, що несуть ту саму інформацію), наведено нижче.
Відношення R1:
| Таб_номер | ПІБ | Оклад | Офіс | Телефон | Діти | ||
| Ім'я | Вік | ||||||
| Іванов І.І. | 6-16 | С | |||||
| Ж | |||||||
| В | |||||||
| Петрук К.М. | 6-16 | Т | |||||
| Сидоров О.Б. | 3-06 | Ж | |||||
| В | |||||||
Відношення R2 (1NF):
| Таб_номер | Ім'я_дитини | Вік дитини | ПІБ | Оклад | Офіс | Телефон |
| С | Іванов І.І. | 6-16 | ||||
| Ж | Іванов І.І. | 6-16 | ||||
| В | Іванов І.І. | 6-16 | ||||
| Т | Петрук К.М. | 6-16 | ||||
| Ж | Сидоров О.Б. | 3-06 | ||||
| В | Сидоров О.Б. | 3-06 |
Відношення R2
|
|
|
Первинний ключ:
Таб_ном, Ім'я дитини;
Функціональні залежності:
Таб_номер ->ПІБ;
Таб_номер -> Оклад;
Таб_номер ->Офіс;
Офіс ->Телефон;
Таб_номер, Ім'я_дитини-> Вік_дитини.
Атрибути ПІБ, Оклад, Офіс не знаходяться в повній функціональній залежності від ключа, оскільки функціонально залежать від частини ключа (Таб_номер). Наслідком цього є:
· дублювання інформації;
· відсутність можливості занести кортеж зі співробітником без дітей (ключ не може містити невизначеного значення);
· при видаленні кортежу втрачаємо не тільки інформацію про дитину співробітника, але, можливо, про місце роботи співробітника, телефон офісу і т.д.);
· при переведенні співробітника в інший офіс ми змушені модифікувати всі кортежі, що описують цього співробітника, інакше одержимо неузгоджений результат.
Процедуру покрокової нормалізації відношення в процесі проектування реляційної БД м розглянемо детальніше на наступному прикладі.
Основний приклад
|
|
|
Розглянемо як предметну область певну організацію, що виконує певні проекти. Модель предметної області опишемо наступним неформальним текстом:
1. Співробітники організації виконують проекти.
2. Проекти складаються з кількох завдань.
3. Кожен співробітник може брати участь в одному чи кількох проектах, чи тимчасово не брати участь ні в яких проектах.
4. Над кожним проектом може працювати кілька співробітників, чи тимчасово проект може бути припинений, тоді над ним не працює жоден співробітник.
5. Над кожним завданням у проекті працює рівно один співробітник.
6. Кожний співробітник числиться в одному відділі.
7. Кожний співробітник має телефон, що знаходиться у відділі співробітника.
У ході додаткового уточнення того, які дані необхідно враховувати, з'ясувалося наступне:
1. Про кожного співробітника необхідно зберігати табельний номер і прізвище. Табельний номер є унікальним для кожного співробітника.
2. Кожний відділ має унікальний номер.
3. Кожний проект має номер і найменування. Номер проекту є унікальним.
4. Кожна робота з проекту має номер, унікальний у межах проекту. Роботи в різних проектах можуть мати однакові номери.
У ході логічного моделювання на першому кроці запропоновано зберігати дані в одному відношенні, що має наступні атрибути:
|
|
|
СПІВРОБІТНИКИ_ВІДДІЛИ_ПРОЕКТИ (Н_СПІВРОБ, ПРІЗ, Н_ВІД, ТІЛ, Н_ПРО, ПРОЕКТ, Н_ЗАВДАН)
де
Н_СПІВРОБ - табельний номер співробітника
ПРІЗ - прізвище співробітника
Н_ВІД - номер відділу, у якому числиться співробітник
ТЕЛ - телефон співробітника
Н_ПРО - номер проекту, над яким працює співробітник
ПРОЕКТ - найменування проекту, над яким працює співробітник
Н_ЗАВДАН - номер завдання, над яким працює співробітник
Оскільки кожний співробітник у кожному проекті виконує рівно одне завдання, то як потенційний ключ відношення необхідно взяти пару атрибутів { Н_СПІВРОБ, Н_ПРО }.
У сучасний момент стан предметної області відбивається наступними фактами:
· Співробітник Іванов, що працює в 1 відділі, виконує в першому проекті "Космос" завдання 1 і в другому проекті "Клімат" завдання 1.
· Співробітник Петров, що працює в 1 відділі, виконує в першому проекті "Космос" завдання 2.
· Співробітник Ситник, працюючий у 2 відділі, виконує в першому проекті "Космос" завдання 3 і в другому проекті "Клімат" завдання 2.
Цей стан відбивається в таблиці (курсивом виділені ключові атрибути):
|
|
|
| Н_СПІВРОБ | ПРІЗ | Н_ВІД | ТЕЛ | Н_ПРО | ПРОЕКТ | Н_ЗАВДАН |
| 1 | Іванов | 11-22-33 | 1 | Космос | ||
| 1 | Іванов | 11-22-33 | 2 | Клімат | ||
| 2 | Петров | 11-22-33 | 1 | Космос | ||
| 3 | Ситник | 33-22-11 | 1 | Космос | ||
| 3 | Ситник | 33-22-11 | 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. Нехай R - відношення. Множина атрибутів Y функціонально залежна від множини атрибутів X (X функціонально визначає Y) тоді і тільки тоді, коли для будь-якого стану відношення R для будь-яких кортежів з того, что випливає, що (тобто у всіх кортежах, що мають однакові значення атрибутів X, значення атрибутів Y також збігаються в будь-якому стані відношення R). Символічно функціональна залежність записується
X -> Y.
Множина атрибутів X називається детермінантом функціональної залежності, а множина атрибутів Y називається залежною частиною.
Зауваження. Якщо атрибути X становлять потенційний ключ відношення R, то будь-який атрибут відношення R функціонально залежить від X.
Приклад 1. У відношенні СПІВРОБІТНИКИ_ВІДДІЛИ_ПРОЕКТИ можна привести наступні приклади функціональних залежностей:
Залежність атрибутів від ключа відношення:
Дата добавления: 2016-01-05; просмотров: 19; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!