4.4.Елементи теорії нормалізації

Основна ідея нормалізації-розбити великий “не добре” спроектований зв'язок на кілька “добре спроектованих” зв'язків.У результаті нормалізації склад атрибутів відношень БД має відповідати таким вимогам:

• між атрибутами мають виключатися небажані функціональні залежності;

• групування атрибутів не повинно мати збиткового дублювання даних;

• забезпечувати обробку і поновлення атрибутів без ускладнень.

До значень “недоброго проектування” можна зарахувати: введення, вилучення та аномалії оновлення.Хороший проект БД:

Клієнт (ім'я,адреса,номер телефону)

Резерви (назва, адреса,номер,дата)

Рейс (номер,дата,час)

Для побудови хорошого проекту БД необхідно:

• мінімізувати аномалії (надмірність);

• ввести / вилучити аномалії;

• забезпечити оновлення аномалій;

• забезпечити чіткий синтаксис/ семантику.

• дотримуватись правил цілісності,зокрема:

•  цілісності об'єкта (всі об'єкти унікальні, не може бути ніяких нульових проводок у первинному ключі);

•  цілісності відносин (зовнішній ключ має бути або нульовим, або відповідати розміру первинного ключа у зв'язаній таблиці).

Аномалії введення / вилучення. Що буде, якщо ми вилучимо запис про такого клієнта, який вже зробив попереднє замовлення на рейс? Яким повинно бути рішення?

Аномалії оновлення. Що буде, якщо змінюється адреса клієнта в БД Клієнт? Яким повинно бути рішення?

Апарат нормалізації був розроблений американським вченим Е.Ф.Коддом. Кодд виділив три нормальні форми (скорочена назва 1НФ, 2НФ, 3НФ). Найдосконаліша з них – 3НФ. Тепер уже відомі і визначені 4 НФ,5НФ.

Нормалізація відношень виконується за кілька кроків (рис.4.5.).

1-й крок (перша ітерація).-зведення відношень до 1НФ.

Відношення в 1НФ мають відповідати таким вимогам:

• усі атрибути відношення мають бути атомарними (неподільними);

• усі рядки таблиці мають бути однакової структури, тобто мати одну й ту саму кількість атрибутів з іменами, що відповідно збігаються;

• імена стовпців мають бути різними, а значення однорідними (мати однаковий формат);

• порядок рядків у таблиці несуттєвий.

Кожне відношення БД містить структурну (задається схемою відношення) і семантичну (функціональні зв'язки між атрибутами) інформацію.

Приклад. Заробітна плата є атомарним атрибутом.Перелік авторів не є атомарним атрибутом.Попередня інформація про заробітну плату не є атомарною.

2-й крок (друга ітерація). Виявляються ключі- атрибути та аналізуються відповідні залежності з метою вилучення неповних функціональних залежностей.

Означення 1. Атрибут Б функціонально залежить від А у відношенні R тоді, коли в кожний момент часу одному і тому самому значенню А відповідає не більш ніж одне значення Б. Функціональній залежності відповідає відношення 1:1 між атрибутами.

Приклад. ПРОДУКТ (Код продукту, Назва, Кінцева обробка, Приміщення, Ціна).

Код продукту Назва, Кінцева обробка, Приміщення, Ціна. Назва, Кінцева обробка, Приміщення Код продукту.

Не можемо мати два продукти з одинаковою назвою, які кінцево обробляються та використовуються в одному приміщенні.

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

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

Основна ідея декомпозиції- розкласти на частини великий “недобре спроектований зв'язок” на декілька малих “добре спроектованих” зв'язків так, щоб

• зберегти властивість розкладення (декомпозиції) без втрат при об'єднанні;

• зберегти залежності (без втрати функціональних залежностей).

Приклад. Візьмемо відношення КЛІЄНТ (Код клієнта, Ім'я, Адреса, № рахунку, Тип, Залишок).

Якщо ми розіб'ємо його на два:

ПОКУПЕЦЬ (Код клієнта, Ім'я, Адреса)

РАХУНОК (Номер рахунку, Тип, Залишок),

то ми втрачаємо інформацію. Однак, якщо КЛІЄНТ розкласти на: