Коли ми говоримо про аналіз бази даних на відповідність нормальним формам, маємо на увазі вивчення структури таблиць, їхніх взаємозв'язків і залежностей між атрибутами. Основна ціль аналізу — знайти порушення нормалізації та оцінити їхній вплив на продуктивність, цілісність і зручність роботи з даними.
Простіше кажучи, це як аудит бухгалтерії: ти перевіряєш, щоб гроші не валялися як попало, а були чітко розподілені по потрібних статтях витрат.
Практичний підхід до аналізу бази даних
У будь-якій базі даних ми починаємо з того, що ставимо три принципових питання, які відповідають трьом нормальним формам.
Припустимо, у нас є база даних складу з таблицею такої структури:
| product_id | product_name | supplier_name | supplier_phone | stock_quantity |
|---|---|---|---|---|
| 1 | Цвяхи | StroiKomplekt | +12301112233 | 150 |
| 2 | Шурупи | KrepezhPro | +12306667788 | 200 |
| 3 | Гайки | StroiKomplekt | +12301112233 | 100 |
Як перевірити цю таблицю на відповідність нормальним формам?
Нагадаю, таблиця у 1NF, якщо:
- Кожна клітинка містить одне значення.
- У таблиці немає повторюваних стовпців для одного й того ж типу даних.
У нашому прикладі порушень 1NF немає: кожна клітинка містить атомарне значення. Це означає, що таблиця приведена до 1NF. Ура! Можна рухатись далі.
Таблиця у 2NF, якщо:
- Вона знаходиться у 1NF.
- Всі неключові атрибути залежать тільки від усього первинного ключа (а не від його частини).
У цій таблиці видно, що supplier_name і supplier_phone залежать тільки від product_id — первинного ключа. Але тут є дублювання даних: для одного й того ж постачальника ми зберігаємо його ім'я та телефон у кількох рядках.
Щоб привести таблицю до 2NF, можемо розділити її на дві таблиці:
Таблиця Products:
| product_id | product_name | supplier_id | stock_quantity |
|---|---|---|---|
| 1 | Цвяхи | 1 | 150 |
| 2 | Шурупи | 2 | 200 |
| 3 | Гайки | 1 | 100 |
Таблиця Suppliers:
| supplier_id | supplier_name | supplier_phone |
|---|---|---|
| 1 | StroiKomplekt | +78901112233 |
| 2 | KrepezhPro | +78906667788 |
Тепер кожен постачальник представлений один раз, і зв'язок між таблицями реалізовано через зовнішній ключ supplier_id.
Таблиця у 3NF, якщо:
- Вона знаходиться у 2NF.
- Всі неключові атрибути залежать тільки від первинного ключа, а не від інших неключових атрибутів.
У випадку нормалізованих таблиць Products і Suppliers ми не бачимо жодних транзитивних залежностей. Це означає, що таблиці приведені до 3NF.
Практичне завдання
Допустимо, у нас є початкова таблиця "Університет"
| student_id | student_name | course_name | professor_name | professor_email |
|---|---|---|---|---|
| 101 | Otto Lin | Математика | Peter Pen | pen@university.com |
| 102 | Anna Song | Фізика | Alex Sid | sid@university.com |
| 103 | Otto Lin | Фізика | Alex Sid | sid@university.com |
- Перевір таблицю на відповідність нормальним формам.
- Приведи її до 1NF, 2NF і 3NF, якщо це потрібно.
Рішення
КРОК 1: Перевірка на 1NF
Таблиця вже у 1NF: кожна клітинка містить одне значення.
КРОК 2: Перевірка на 2NF
Таблиця порушує 2NF: інформація про викладачів (ім'я та email) повторюється. Можемо винести її в окрему таблицю:
Таблиця Students:
| student_id | student_name |
|---|---|
| 101 | Otto Lin |
| 102 | Anna Song |
Таблиця Courses:
| course_id | course_name | professor_id |
|---|---|---|
| 1 | Математика | 1 |
| 2 | Фізика | 2 |
Таблиця Professors:
| professor_id | professor_name | professor_email |
|---|---|---|
| 1 | Peter Pen | pen@university.com |
| 2 | Alex Sid | sid@university.com |
Таблиця Enrollments:
| enrollment_id | student_id | course_id |
|---|---|---|
| 1 | 101 | 1 |
| 2 | 102 | 2 |
| 3 | 103 | 2 |
КРОК 3: Перевірка на 3NF
У новій структурі відсутні транзитивні залежності. Таблиці відповідають 3NF.
Практичні поради
- Не женись за ідеалом без потреби. Іноді зайва нормалізація ускладнює запити.
- Підходь до аналізу як детектив. Шукай дублікати, зайві залежності та інші "аномалії".
- Не забувай про продуктивність. Нормалізація — це баланс між чистотою даних і швидкістю їх обробки.
Тепер, коли ти вмієш знаходити проблеми в базі даних і вирішувати їх, ти зможеш чесно провести "ревізію" бази будь-якого розміру. Пам'ятай: хороша база даних — це не тільки функціональний, а й красивий (або нормалізований) проєкт.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ