Зміст:
Визначення - Що означає Третя нормальна форма (3NF)?
Третя нормальна форма (3NF) - це третій крок у нормалізації бази даних, і він ґрунтується на першій та другій нормальних формах, 1NF та 2NF.
3NF зазначає, що всі посилання стовпців у посилаються на дані, які не залежать від первинного ключа, повинні бути видалені. Іншим способом цього є те, що для посилання на іншу таблицю повинні використовуватися лише стовпці із зовнішнім ключем, а жодна інша колонка з батьківської таблиці не повинна існувати у посилальній таблиці.
Техопедія пояснює третю нормальну форму (3NF)
Розглянемо базу даних банку, яка містить дві таблиці: CUSTOMER_MASTER для зберігання реквізитів клієнта та ACCOUNT_MASTER для зберігання реквізитів про банківські рахунки, включаючи, який клієнт має, який рахунок. У цьому випадку повинен бути спосіб зв'язати дві таблиці, щоб прив’язати рахунок до клієнта, який є його власником. Спосіб зробити це через зовнішній ключ. Це стовпець таблиці ACCOUNT_MASTER, який вказує на посилання на відповідний стовпець (який називається первинним ключем) у батьківській таблиці CUSTOMER_MASTER або посилається на нього. Назвемо цей стовпець CustID.
Припустимо, що замовник Ендрю Сміт створює обліковий запис у таблиці CUSTOMER_MASTER разом із CustID 20454. Містер Сміт зберігає ощадний рахунок з номером S-200802-005, реквізити якого зберігаються в таблиці ACCOUNT_MASTER. Це означає, що в таблиці ACCOUNT_MASTER буде стовпець під назвою CustID, який не є оригінальним фрагментом даних. Натомість воно також має значення 20454, яке просто посилається на той самий идентификатор CustID у таблиці CUSTOMER_MASTER.
Тепер 3NF вказує, що в нашій таблиці ACCOUNT_MASTER єдиною інформацією, яку ми маємо про клієнта, повинен бути GuardID (20454) як зовнішній ключ, і він посилається на та визначає клієнта, якому належить цей самий CustID у таблиці CUSTOMER_MASTER (Ендрю Сміт ). Ніякі інші дані про нашого замовника (наприклад, ім'я, дата народження, стать та ін.) Не повинні зберігатися в таблиці ACCOUNT_MASTER або взагалі будь-якій іншій таблиці, оскільки всі ці дані про нього вже зберігаються у CUSTOMER_MASTER. Таким чином, єдиними даними клієнта, що зберігаються поза таблицею CUSTOMER_MASTER, є GuardID. Це виплачує прекрасні дивіденди, забезпечуючи відсутність дублювання даних, що, в свою чергу, робить запити набагато ефективнішими та зменшує обсяг необхідного сховища.
