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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3НФ (Третя Нормальна Форма)

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

Визначення 5. Відношення знаходиться в третій нормальній формі (3НФ) тоді і тільки тоді, коли відношення знаходиться в 2НФ і всі неключові атрибути взаємно незалежні.

Відношення СОТРУДНикІ_ОТДЕЛИ не знаходиться в 3НФ, оскільки є функціональна залежність неключових атрибутів (залежність номера телефону від номера відділу):

Н_ВІД ТЕЛ

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

Відношення СПІВРОБІТНИКИ_ВІДДІЛИ декомпозуємо на два відношення - СПІВРОБІТНИКИ, ВІДДІЛИ.

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

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

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

Н_СПІВ ПРІЗВ

Н_СПІВ Н_ВІД

Н_СПІВ ТЕЛ

Н_СПІВ | ПРІЗВ | Н_ВІД

1 | Іванов | 1

2 | Петров | 1

3 | Сидоров | 2

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

Відношення ВІДДІЛИ (Н_ВІД, ТЕЛ):

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

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

Н_ВІД ТЕЛ

Н_ВІД | ТЕЛ

1 | 11-22-33

2 | 33-22-11

Таблиця 6 Відношення ВІДДІЛИ

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

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

Алгоритм нормалізації (приведення до 3НФ)

Отже, алгоритм нормалізації (тобто алгоритм приведення відносин до 3НФ) описується таким чином.

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

Крок 2 (Приведення до 2НФ). Якщо в деяких відносинах знайдена залежність атрибутів від частини складного ключа, то проводимо декомпозицію цих відносин на