У реляційному дизайні баз даних існує концепція нормалізації бази даних або просто її нормалізація, яка є процесом організації стовпців (атрибутів) і таблиць (відносин) для зменшення надмірності даних та поліпшення цілісності даних. (як написано у Вікіпедії ).
Оскільки більшість статей є дещо технічними, і тому їх важче зрозуміти, я прошу когось написати простіше зрозуміле пояснення на основі прикладів того, що означають 1NF, 2NF, 3NF, навіть 3,5NF (Boyce-Codd).
Відповіді:
1NF - це найосновніша нормальна форма - кожна комірка таблиці повинна містити лише одну інформацію, і не може бути жодних повторних рядків.
2NF і 3NF - це залежність від первинного ключа. Нагадаємо, первинний ключ може складатися з декількох стовпців. Як сказав у відповідь Кріс:
Дані залежать від ключа [1NF], всього ключа [2NF] і нічого, крім ключа [3NF] (тому допоможіть мені Codd ).
Скажімо, у вас є таблиця з курсами, які проходять у певному семестрі, і у вас є такі дані:
|-----Primary Key----| uh oh |
V
CourseID | SemesterID | #Places | Course Name |
------------------------------------------------|
IT101 | 2009-1 | 100 | Programming |
IT101 | 2009-2 | 100 | Programming |
IT102 | 2009-1 | 200 | Databases |
IT102 | 2010-1 | 150 | Databases |
IT103 | 2009-2 | 120 | Web Design |
Це не в 2NF , оскільки четвертий стовпець не спирається на весь ключ - а лише на його частину. Назва курсу залежить від ідентифікатора курсу, але не має нічого спільного з тим, в якому семестрі він береться. Таким чином, як ви бачите, у нас є дублююча інформація - кілька рядків говорять про те, що IT101 програмує, а IT102 - це бази даних. Отже, ми це виправляємо, переміщуючи назву курсу в іншу таблицю, де CourseID є ЦІЛЬКИМ ключем
Primary Key |
CourseID | Course Name |
---------------------------|
IT101 | Programming |
IT102 | Databases |
IT103 | Web Design |
Без надмірності!
Гаразд, скажімо, ми також додаємо в RDBMS прізвище викладача курсу та деякі деталі про них:
|-----Primary Key----| uh oh |
V
Course | Semester | #Places | TeacherID | TeacherName |
---------------------------------------------------------------|
IT101 | 2009-1 | 100 | 332 | Mr Jones |
IT101 | 2009-2 | 100 | 332 | Mr Jones |
IT102 | 2009-1 | 200 | 495 | Mr Bentley |
IT102 | 2010-1 | 150 | 332 | Mr Jones |
IT103 | 2009-2 | 120 | 242 | Mrs Smith |
Тепер, сподіваємось, повинно бути очевидним, що TeacherName залежить від TeacherID - так це не в 3NF . Щоб виправити це, ми робимо так само, як це робили в 2NF - виймаємо поле TeacherName з цієї таблиці і ставимо його у власному, у якому ключ TeacherID.
Primary Key |
TeacherID | TeacherName |
---------------------------|
332 | Mr Jones |
495 | Mr Bentley |
242 | Mrs Smith |
Без надмірності !!
Важливо пам’ятати, що якщо чогось немає в 1NF, він також не в 2NF або 3NF. Отже, кожна додаткова нормальна форма вимагає всього, що мали нижчі нормальні форми, плюс деякі додаткові умови, які всі повинні бути виконані.
Я ніколи не мав гарної пам’яті для точного формулювання, але в моєму класі баз даних я думаю, що професор завжди говорив щось на кшталт:
Дані залежать від ключа [1NF], всього ключа [2NF] і нічого, крім ключа [3NF].
The data depends on the key [1NF], nothing but the key [3NF]? Будь ласка, не плутайте нас, оскільки 1 відповідальна відповідь не уточнює відповідь, але бентежить відвідувачів!
Ось швидка, правда кажучи, підстрижена відповідь, але у реченні:
1NF: Ваша таблиця організована як не упорядкований набір даних, і немає стовпців, що повторюються.
2NF: Ви не повторюєте дані в одному стовпчику таблиці через інший стовпець.
3NF: Кожен стовпець вашої таблиці стосується лише ключа вашої таблиці - у вас не було б стовпця в таблиці, який описує інший стовпець у вашій таблиці, який не є ключем.
Детальніше дивіться у wikipedia ...
1NF: Лише одне значення на стовпець
2NF: Усі стовпці не первинного ключа в таблиці повинні залежати від всього первинного ключа.
3NF: Усі стовпці не первинного ключа в таблиці повинні Прямо залежати від всього первинного ключа.
Я написав статтю більш детально тут