Принципи третьої нормальної форми (3NF)

Третя нормальна форма (3NF) — це крок до ще більшого порядку в наших даних. Коротко, таблиця знаходиться у 3NF, якщо:

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

Іншими словами, 3NF вимагає, щоб всі дані в таблиці були напряму пов’язані з її первинним ключем і не залежали від інших неключових атрибутів.

Транзитивна залежність виникає, якщо атрибут А залежить від атрибута В, а атрибут В залежить від атрибута С, що створює ланцюжок залежностей А → В → С. Наприклад, «Співробітник» залежить від «Відділу», а «Відділ» залежить від «Розташування». Виходить, що «Співробітник» транзитивно залежить від «Розташування».

Приклад порушення 3NF

Уявімо, що у нас є таблиця employees, яка зберігає дані про співробітників:

Тут:

• employee_id — первинний ключ.
• department і department_manager — неключові атрибути.

На перший погляд все виглядає ок, але якщо придивитися, то видно проблему: department_manager залежить не від employee_id, а від department. Таким чином, виникає транзитивна залежність: employee_id → department → department_manager.

Проблеми, які можуть виникнути

Якщо ми змінимо ім’я директора департаменту («Фінанси»), доведеться оновлювати всі рядки, де вказаний цей департамент. Якщо випадково забути оновити якийсь рядок, дані стануть неузгодженими. Це головний біль, якого можна уникнути.

Приведення таблиці до 3NF

Щоб прибрати транзитивні залежності, розділимо таблицю на дві: одна буде зберігати дані про співробітників, а інша — про департаменти.

Таблиця employees

Таблиця departments

Тепер все структуровано, і кожна таблиця займається своїм:

1. Таблиця employees зберігає дані про співробітників.
2. Таблиця departments зберігає дані про департаменти та їх менеджерів.

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

Як визначити, що таблиця порушує 3NF?

Щоб зрозуміти, що таблиця порушує 3NF, перевір:

1. Чи є в таблиці транзитивні залежності? Наприклад, атрибут A залежить від атрибута B, який залежить від атрибута C.
2. Чи всі неключові атрибути напряму залежать від первинного ключа? Якщо щось залежить від іншого неключового атрибута, то таблиця не у 3NF.

Практичний приклад: магазин

Розглянемо таблицю sales, яка містить дані про продажі:

Тут явно видно надлишковість: інформація про ціну товару повторюється для кожного продажу. Якщо ціна зміниться, дані одразу стають неузгодженими.

Щоб прибрати порушення 3NF, розділимо таблицю на дві:

1. Таблиця sales буде зберігати відомості про продажі.
2. Таблиця products — дані про товари та їх ціни.

Таблиця sales

Таблиця products

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

Практичне завдання

Ось тобі задачка: у тебе є таблиця students_courses такого вигляду:

Розділи таблицю так, щоб вона відповідала 3NF. Підказка: треба створити три таблиці (students, courses, teachers) і правильно їх зв’язати.

Чому важливо дотримуватись 3NF?

Чому взагалі варто заморочуватись з третьою нормальною формою (3NF)? Бо вона реально спрощує життя. Коли таблиці приведені до 3NF, дані стають акуратнішими — жодного зайвого дублювання, а значить, менше шансів щось випадково зламати. Оновлення проходять швидше й простіше, бо все зберігається в одному місці, а не копіпаститься по всіх рядках.

До того ж структура бази стає гнучкішою. Хочеш додати нове поле чи змінити старе — не треба перекроювати всю систему.

Але, як і в будь-якій хорошій історії, є нюанс: занадто завзята нормалізація може вилитись у купу дрібних таблиць і складні запити з купою JOIN’ів. Іноді це дійсно може гальмувати. Тому головне — відчуття міри. Де треба — нормалізуй, а де простіше залишити трохи надлишковості — не бійся.

Далі будемо розбиратись глибше: навчимось правильно будувати зв’язки між таблицями і створювати бази, які і зручні, і надійні. Вперед, до крутого дизайну бази даних!