Додаток Б. Послідовні нормальні форми та вимоги до них
Мета нормалізації відношень – якісне проектування бази даних, що включає, перш за все, відсутність збиткових неключових даних.
Якщо для підвищення якості проектування бази даних потрібно здійснити нормалізацію на більш високому рівні, то провадиться декомпозиція невідповідної таблиці (Таблиця розбивається на дві чи три таблиці). На кожному наступному щабелі нормалізації таблиці відповідають усім вимогам попередніх щабелів.
Щабелі нормалізації приведемо у вигляді наступної таблиці:
Таблиця Б.1.
Нормалізація відношень реляційних баз даних
| Щабелі нормалізації | Обмеження | Примітка |
| Таблиця приведена до 1-ї нормалізованої форми (1NF) | Усі атрибути таблиці –прості (атомарні, неподільні) | Поле ПІБ можна розглядати як подільне або як атомарне залежно від вимог задачі до даних про співробітників. |
| Таблиця приведена до 2-ї нормалізованої форми (2NF) | ¨ Таблиця знаходиться у 1NF: ¨ Усі її неключові елементи функціонально з’язані з первинним ключем | Якщо неключовий елемент залежить від складного ключа, який не вказано в таблиці, то така Таблиця не відповідає умовам 2NF |
| Таблиця приведена до 3-ї нормалізованої форми (1NF) | ¨ Таблиця знаходиться у 2NF: ¨ Усі її неключовий елементи нетранзитивно залежить від первинного ключа | Якщо у відношенні є атрибути А, В, С, такі, що: атрибут С залежить від атрибута В, і атрибут В залежить від атрибута А, то атрибут С транзитивно залежить від атрибута А |
| Таблиця приведена до нормалізованої форми Бойса-Кодда (NFБК) | ¨ Таблиця знаходиться у 3NF: ¨ Будь-яка функціональна залежність між полями зводиться до повної функціональної залежності від можливого ключа | |
| Таблиця приведена до 4-ї нормалізованої форми (1NF) | ¨ Таблиця знаходиться у NFБК; ¨ Відсутні багатозначні залежності, які не є функціональними | Якщо немає функціональних залежностей, то усі поля – ключові. |
| Таблиця приведена до 5-ї нормалізованої форми (5NF) | Будь-яка залежність по з’єднанню визначається ключами | Залежність по з’єднанню дозволяє розбити відношення на три і більше Таблиць. |
Охарактеризуємо якість проектування бази дани, що відповідає прикладу , див. Додаток А.
Зауважимо, що завжди потрібно виважено відноситись до структури бази даних, зваживши на задачі, для вирішення яких, дані зберігаються у базі даних.
Фактично Таблиця 2 (Несправності) не відповідає 1NF Атрибут Контролер може бути подільним, але можна вважати, що ініціали не відділяються і не вибираються із інших атрибутів, окрім поля Контролер. Тому можна вважати, що усі таблиці приведені до першої нориальної форми (1NF).
Структурабази даних представлено схемою 1, див Рис Б.1.
Рис Б.1. Початкова база даних прикладу додатка А.
Нехай за умовою задачі поле Довідка повинно зберігати дату тестування. Тоді у структурі таблиці Результати тестування потрібно вказати тип даних Дата/время. Деталізуючи умови проведення тестувань авто (згідно даних Таблиць), слід зазначити, що тестування організовані таким чином, що кожна несправність тестується певним контролером і оплата за тестування залежить від рівня кваліфікації спеціаліста - контролера. Допускається, що один контролер може проводити тестування різних несправностей за різною оплатою.
Виходячи з такого аналізу та розглядаючи таблицю Довідник несправностей зазначаємо:
¨ Для вказаної таблиці ключовим полем є поле Код_несправності, усі інші поля - неключові. Поля Назва несправності та Контролер функціонально залежать від ключа. Але поле Ціна тестування залежить не тільки від ключа але і від умов контракту того чи іншого контролера. Зазначимо, що головним недоліками вказаної структури бази даних, є те, що:
¨ потрібно повторювати прізвище контролера;
¨ у разі зміни штатного розкладу потрібно вносити зміни у таблицю Довідник несправностей.
 |
Отже якість проектування бази даних низька, хоча для ряду найпростіших задач така структура може бути умовно прийнятною, але небажаною, бо “термін життя” такої бази дуже малий. Аналізуючи структуру бази даних, зазначимо, для того, щоб зробити зміни у структурі бази даних та введення даних у таблиці більш зручними (підвищити якість проектування) можна виконати декомпозицію таблиці Довідник несправностей, замінивши її на дві, див. Рис. Б.2.
Рис. Б.2. Декомпозиція таблиці Довідник даних
Більш зручна робота при зміні та введені даних досягається лише тоді, коли поле Контролер є полем зі списком.
Технологія створення поля зі списком нескладна і сприяє забезпеченню умов цілосності даних, та до деякої міри автоматизує процес створення структури бази даних. Якщо записів у Таблицях бази даних мало і їх обсяги не впливають на швидкодію роботи з даними, то схему, представлену на Рис. Б.2. можна прийняти, знаючи обмеження і недосконалість розробленої схеми даних . Така недосконалість проектування бази даних полягає у тому, що таблиця Довідник несправностей має неключове поле Ціна тестування, значення якого залежить не тільки від коду несправності але і від поля Контролер. Це означає, що якщо ми контролера можемо обирати зі списку, то поле Ціна тестування повністю корегується вручну. Хоча його теж можна вводити як поле зі списком, причому список цін зберігається у окремому стовпчику, а не в таблиці.
Вкажемо спосіб, коли із поля зі списком, який зберігається у таблиці Контролер можна обирати код, а в таблиці фіксуємо відповідні прізвище та ініціали із поля Пр. У таких випадках зв’язування Таблиць відбувається за полем Код контролера, але першим у стовпчиках підстановки обирається поле Пр, для якого значення властивості Подпись єКонтролер.
Щоб якість проектування була більш високою, потрібно підвищити щабель нормалізації. Для цього вводимо у розгляд ще один об’єкт предметної області – Контракт. Цей об’єкт інформаційно може бути представлений таблицею, яка має у своєму складі поля
¨ Код контракта
¨ Код контролера
¨ Код несправності
Тоді у таблиці Довідник несправностей проводяться наступні декомпозиційні дії: таблицю Довідник несправностей замінюємо наступними трьома Таблицями:
| Таблиця | Структура таблиці | Властивості атрибутів |
| Довідник несправностей | Код несправності | Первинний ключ |
| Назва несправності | Текстове поле, неключовий атрибут | |
| Код контракта | Первинний ключ | |
| Контракти | Код контракта | Первинний ключ |
| Код несправності | Зовнішній ключ | |
| Код контролера | Зовнішній ключ | |
| Ціна тестування | Числове поле. Неключовий атрибут | |
| Контролер | Код контролера | Первинний ключ |
| Пр (Прізвище та ініціали контролера) | Текстове поле, Неключовий атрибут |
Таким чином, при умові, що для тестування кожної несправності заключається новий контракт (виконавець підписує контракт на кожен вид тестування окремо) структура бази даних складається із 5-ти Таблиць.
Але такий проект не є досконалим, незручно працювати з контрактами. Проводимо аналіз далі. Якщо в одному контракті фіксувати усі несправності, які проводить контролер, то таблицю Контракт потрібно декомпозувати на дві- Контракти та Умови контракту. В таблицю Контракти включити атрибути- код контракта, Код контролера, дата контракта. У таблицю Умови контракта включити поля- Код контрака, Код несправності, Ціна. Встановлюємо ключі та властивості полів. Записуємо концептуальну модель та будуємо наступний варіант схеми даних. Доводимо таблиці до найбільш високого із можливих рівнів нормалізації.
Увага!!! Проектуючи базу даних, необхідно відразу продумувати структуру бази даних з найбільш високим рівнем нормалізації відношень. Мета даного додатку проілюструвати як підвищується якість проектування бази даних на стадії розробки логічної моделі даних та можливості мови для створення та, у разі необхідност, модифікаціїіснуючої структури бази даних.