Початкове відношення: .

Ключ: - складний.

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

- залежність всіх атрибутів від ключа відношення.

- залежність деяких атрибутів від частини складного ключа.

Декомпозірованниє відносини:

- залишок від початкового відношення. Ключ .

- атрибути, винесені з початкового відношення разом з частиною складного ключа. Ключ .

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

Початкове відношення: .

Ключ: .

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

- залежність всіх атрибутів від ключа відношення.

- залежність деяких неключових атрибутів інших неключових атрибутів.

Декомпозірованниє відносини:

- залишок від початкового відношення. Ключ .

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

Зауваження. На практиці, при створенні логічної моделі даних, як правило, не слідують прямо приведеному алгоритму нормалізації. Досвідчені розробники звичайно відразу будують відносини в 3НФ. Крім того, основним засобом розробки логічних моделей даних є різні варіанти ER-діаграм. Особливість цих діаграм в тому, що вони відразу дозволяють створювати відносини в 3НФ. Проте, приведений алгоритм важливий з двох причин. По-перше, цей алгоритм показує, які проблеми виникають при розробці слабо нормалізованих відносин. По-друге, як правило, модель предметної області не буває ніколи правильно розроблена з першого кроку. Експерти предметної області можуть забути про що-небудь згадати, розробник може неправильно зрозуміти експерта, під час розробки можуть змінитися правила, прийняті в предметній області, і т.д. Все це може привести до появи нових залежностей, які були відсутні в первинній моделі предметної області. Тут якраз і необхідно використовувати алгоритм нормалізації хоча б для того, щоб переконатися, що відносини залишилися в 3НФ і логічна модель не погіршилася.

Аналіз критеріїв для нормалізованих і ненормалізованих моделей даних

Порівняння нормалізованих і ненормалізованих моделей

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

Критерій | Відношення слабо нормалізовані
(1НФ, 2НФ) | Відношення сильно нормалізовані

(3НФ)

Адекватність бази даних предметній області | ГІРШЕ (-) | КРАЩЕ (+)

Легкість розробки і супроводу бази даних | СКЛАДНІШЕ (-) | ЛЕГШЕ (+)

Швидкість виконання вставки, обновлення, видалення | ПОВІЛЬНІШЕ (-) | ШВИДШЕ (+)

Швидкість виконання вибірки даних | ШВИДШЕ (+) | ПОВІЛЬНІШЕ (-)

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

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

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

OLTP і OLAP-системи

Можна виділити деякі класи систем, для яких більше підходять сильно або слабо нормалізовані моделі даних.

Сильно нормалізовані моделі даних добре підходять для так званих OLTP-додатків (On-Line Transaction Processing (OLTP) - оперативна обробка транзакцій). Типовими прикладами OLTP-додатків є системи складського обліку, системи замовлень квитків, банківські системи, що виконують операції по перекладу грошей, і т.п. Основна функція подібних систем полягає у виконанні великої кількості коротких транзакцій. Самі транзакції виглядають відносно просто, наприклад, "зняти суму грошей з рахунку А, додати цю суму на рахунок В". Проблема полягає в тому, що, по-перше, транзакцій дуже багато, по-друге, виконуються вони одночасно (до системи може бути підключено декілька тисяч одночасно працюючих користувачів), по-третє, при виникненні помилки, транзакція повинна цілком відкататися і повернути систему до полягання, яке було до початку транзакції (не повинно бути ситуації, коли гроші зняті з рахунку А, але не поступили на рахунок В). Практично всі запити до бази даних в OLTP-додатках складаються з команд вставки, оновлення, видалення. Запити на вибірку в основному призначені для надання користувачам можливості вибору з різних довідників. Велика частина запитів, таким чином, відома наперед ще на етапі проектування системи. Таким чином, критичним для OLTP-додатків є швидкість і надійність виконання коротких операцій оновлення даних. Чим вище рівень нормалізації даних в OLTP-додатку, тим воно, як правило, швидше і надійніше. Відступи від цього правила можуть відбуватися тоді, коли вже на етапі розробки відомі деякі часто виникаючі запити, що вимагають з'єднання відносин і від швидкості виконання яких істотно залежить робота додатків. В цьому випадку можна пожертвувати нормалізацією для прискорення виконання подібних запитів.

Іншим типом додатків є так звані OLAP-додатки (On-Line Analitical Processing (OLAP) - оперативна аналітична обробка даних). Це узагальнений термін, що характеризує принципи побудови систем підтримки ухвалення рішень (Decision Support System - DSS), сховищ даних (Data Warehouse), систем інтелектуального аналізу даних (Data Mining). Такі системи призначені для знаходження залежностей між даними (наприклад, можна спробувати визначити, який зв'язаний об'єм продажів товарів з характеристиками потенційних покупців), для проведення аналізу "що якщо.". OLAP-додатки оперують з великими масивами даних, вже накопиченими в OLTP-додатках, узятими їх електронних таблиць або з