3.3 Проєктування нормалізованих відношень

Нормалізація це покроковий процес організації даних в базі даних. Він включає створення таблиць та встановлення відносин між цими таблицями відповідно до правил, призначеними для захисту даних і забезпечення більшої гнучкості бази даних за рахунок виключення надмірності і неузгодженості залежності [10].

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

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

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

• Уникнення повторень груп (категорії даних, що можуть зустрічатись різну кількість раз в різних записах) правильно визначаючи неключові атрибути.

• Атомарність: кожен атрибут повинен мати лише одне значення, а не множину значень.

Друга нормальна форма (2НФ, 2NF) – нормальна форма, що використовується для нормалізації баз даних. 2НФ первісно була визначена 1971 року Едгаром Коддом. Щоб перебувати в другій нормальній формі, таблиця, що перебуває в першій нормальній формі, має відповідати додатковим критеріям. А саме: 1НФ таблиця перебуватиме в 2НФ тоді й лише тоді, коли для будь-якого потенційного ключа K і будь-якого атрибута A, який не є частиною потенційного ключа, A залежить саме від цілого потенційного ключа, а не від його частини.

• Тобто, 1НФ таблиця перебуває в 2НФ тоді й тільки тоді, коли всі її неключові атрибути функціонально залежні від потенційного ключа в цілому.

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

Третя нормальна форма (3НФ) – нормальна форма використовна в нормалізації баз даних. 3НФ первісно була визначена 1971 року Едгаром Коддом. За Коддом таблиця знаходиться в 3НФ тоді й лише тоді, коли виконуються наступні умови:

• Відношення R (таблиця) знаходиться в 2НФ

• Кожен неключовий атрибут відношення R нетранзитивно (безпосередньо) залежить від кожного потенційного ключа в R.

Попередньо отримані відношення знаходяться у 1НФ, 2НФ і 3НФ і мають такий вигляд:

• Готель (<ID_Готелю>, Назва_готелю, Кількість_зірок, Кількість_вільних_місць, Адреса_готелю);

• Відвідувач (<ID_Відвідувача>, ПІБ_відвідувача, Телефон_відвідувача, Пошта_відвідувача, Місто_проживання);

• Працівник (<ID_Працівника>, ПІБ_працівника, Робочий_час, Телефон_працівника);

• Оплата (<ID_Оплати>, Вид_оплати, Сума_оплати, Відсоток_знижки);

• Скарга (<ID_Скарги>, Зміст_скарги).

3.4 Отримання попередніх відношень за методом «Суть – зв’язок»

Звернемо увагу на такі характеристики, як тип зв’язку та клас належності, які визначимо попереднім відношенням на основі зв’язків, що були використані для побудови ER-моделі предметної області «Готель».

Зв’язок Відвідувач – Оплата має тип зв’язку 1:1, клас належності обов’язковий для обох сутей, гарантується однократне появлення кожного значення сутей в будь-якому екземплярі відношень і використовується правило 1.

Відвідувач – Скарга має тип зв'язку 1:N і клас належності суті Скарга є обов’язковим, тому використаємо правило 4.

Зв’язок Працівник – Готель має тип зв’язку N:1 і клас належності n-зв’язної суті є необов'язковими, тому використовуємо правило 5.

Зв’язок Відвідувач – Готель має тип зв'язку N:1 і клас належності суті Відвідувач є необов’язковим, тому використаємо правило 5.

ПРАВИЛО 1. Якщо ступінь бінарних зв'язків 1:1 і клас належності обов'язковий для обох сутей, гарантується однократне появлення кожного значення сутей в будь-якому екземплярі відношень. Тобто, у відношенні ніколи не буде ні порожньої інформації, ні груп надлишкових даних, що повторюються [11].

ПРАВИЛО 4. Якщо ступінь бінарного зв'язку 1:N, і клас належ­ності n-зв'язної суті є обов'язковим, то досить використати по одному відношенню на кожну суть, при умові, що ключ кожної суті служить як первинний ключ для відповідного відношення. Додатково, ключ 1-зв'язаної суті повинен бути добавлений як атрибут у відношення, що відводиться n- зв’язній суті.

ПРАВИЛО 5. Якщо ступінь бінарного зв'язку 1:N і клас належності n-зв’язної суті є необов'язковими, то необхідне формування трьох відношень: по одному для кожної суті, причому ключ кожної суті служить як первинний ключ для відповідного відношення, і одного відношення для зв’язку. Зв’язок повинен мати серед своїх атрибутів ключ суті кожної з зв’язних сутей.

На основі цих правил, атрибутів з універсального відношення та ER-моделі предметної області було створено попередні відношення, що наведено в таблиці 3.3.

Таблиця 3.3 – Попередні відношення для предметної області «Готель»

Ім’я зв’язку	Правило	Попередні відношення	Додаткові атрибути
Робить	1	R1 (ID_Оплати)	Вид_оплати, Сума_оплати, Відсоток_знижки
		*R2 (ID_Відвідувача)	ПІБ_відвідувача, Телефон_відвідувача, Пошта_відвідувача, Місто_проживання, ID_Оплати

Продовження таблиці 3.3

Залишає	4	*R3 (ID_Відвідувача)	ПІБ_відвідувача, Телефон_відвідувача, Пошта_відвідувача, Місто_проживання, ID_Оплати
		R4 (ID_Скарги)	Зміст_скарги, ID_Відвідувача
Проживає	5	R5 (ID_Відвідувача)	ПІБ_відвідувача, Телефон_відвідувача, Пошта_відвідувача, Місто_проживання, ID_Оплати
		*R6 (ID_Готелю)	Назва_готелю, Кількість_зірок, Кількість_вільних_місць, Адреса_готелю
		R7 (ID_Готелю, ID_Відвідувача)	Для організації зв’язків
Працює	5	R8 (ID_Працівника)	ПІБ_працівника, Робочий_час, Телефон_працівника
		R9 (ID_Готелю)	Назва_готелю, Кількість_зірок, Кількість_вільних_місць, Адреса_готелю
		R10 (ID_Працівника, ID_Готелю)	Для організації зв’язків

Після опрацювання даних з таблиці 3.3 залишаються наступні відношення:

R2 (<ID_Оплати>, Вид_оплати, Сума_оплати, Відсоток_знижки);

R4 (<ID_Скарги>, Зміст_скарги, ID_Відвідувача);

R5 (<ID_Відвідувача>, ПІБ_відвідувача, Телефон_відвідувача, Пошта_відвідувача, Місто_проживання, ID_Оплати);

R7 (<ID_Готелю, ID_Відвідувача>);

R8 (<ID_Працівника>, ПІБ_працівника, Робочий_час, Телефон_працівника);

R9 (<ID_Готелю>, Назва_готелю, Кількість_зірок, Кількість_вільних_місць, Адреса_готелю);

R10 (<ID_Працівника, ID_Готелю>).