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