Друга Нормальна Форма
Щоб зрозуміти другу нормальну форму, ми повинні ввести поняття складеного первинного ключа: ключ, який складається з двох або більше атрибутів у таблиці. Мета складеного ключа - однозначно ідентифікувати кожен рядок у таблиці на основі значень декількох стовпців. Як ми вже згадували в попередньому розділі, атрибути, які складають складений первинний ключ, називаються атрибутами ключа.
Приклад
Наприклад, таблиця "Employee-Department": припустимо, у нас є таблиця "Employee" (Працівник) зі стовпцями EmployeeID та DepartmentID. Оскільки кожен працівник може працювати лише в одному відділі, а в кожному відділі може бути кілька працівників, ми можемо використовувати складений ключ, що складається з обох стовпців, як первинний ключ таблиці.
Правила другої нормальної форми:
-
Вимагає першої нормальної форми.
-
Усі неключові атрибути (тобто стовпці, які не є частиною первинного ключа) є повністю залежними від первинного ключа.
Щоб зрозуміти другу умову, важливо зрозуміти, що мається на увазі під "повною залежністю". Стовпець є повністю залежним від первинного ключа, якщо він залежить від усього первинного ключа, а не тільки від його частини.
У нашому прикладі таблиця відповідає першій нормальній формі з композитним ключем, створеним з EmployeeID та DepartmentID. Однак вона не відповідає другій нормальній формі: хоча зарплата залежить від ідентифікатора працівника та ідентифікатора відділу, роль керівника відділу повністю залежить від ідентифікатора відділу і не змінюється через ідентифікацію працівника.
Атрибути Name та Surname залежать від EmployeeID. Тому їх слід розмістити в окремій таблиці. Таким чином, деякі атрибути залежать лише від частини композитного ключа.
Ця структура може призвести до аномалії зміни: наприклад, якщо ми видалимо другий рядок, ми ненавмисно втратимо інформацію про керівника відділу, оскільки інші рядки не мають цього конкретного ідентифікатора відділу.
Нормалізація
Давай нормалізуємо за допомогою другої нормальної форми:
Оновлена база даних гарантує, що жодні атрибути не залежать лише від частини композитного ключа: таблиця відповідає другій нормальній формі, забезпечуючи збереження важливої інформації, навіть якщо рядки з початкової таблиці видаляються.
Примітка
Таблиця в першій нормальній формі без композитного ключа за замовчуванням задовольняє вимоги другої нормальної форми.
Дякуємо за ваш відгук!
Запитати АІ
Запитати АІ
Запитайте про що завгодно або спробуйте одне із запропонованих запитань, щоб почати наш чат
Can you explain what a modification anomaly is in more detail?
How do you know if a table is already in the second normal form?
Can you give another example of a table that violates the second normal form?
Чудово!
Completion показник покращився до 8.33Друга Нормальна Форма
Свайпніть щоб показати меню
Щоб зрозуміти другу нормальну форму, ми повинні ввести поняття складеного первинного ключа: ключ, який складається з двох або більше атрибутів у таблиці. Мета складеного ключа - однозначно ідентифікувати кожен рядок у таблиці на основі значень декількох стовпців. Як ми вже згадували в попередньому розділі, атрибути, які складають складений первинний ключ, називаються атрибутами ключа.
Приклад
Наприклад, таблиця "Employee-Department": припустимо, у нас є таблиця "Employee" (Працівник) зі стовпцями EmployeeID та DepartmentID. Оскільки кожен працівник може працювати лише в одному відділі, а в кожному відділі може бути кілька працівників, ми можемо використовувати складений ключ, що складається з обох стовпців, як первинний ключ таблиці.
Правила другої нормальної форми:
-
Вимагає першої нормальної форми.
-
Усі неключові атрибути (тобто стовпці, які не є частиною первинного ключа) є повністю залежними від первинного ключа.
Щоб зрозуміти другу умову, важливо зрозуміти, що мається на увазі під "повною залежністю". Стовпець є повністю залежним від первинного ключа, якщо він залежить від усього первинного ключа, а не тільки від його частини.
У нашому прикладі таблиця відповідає першій нормальній формі з композитним ключем, створеним з EmployeeID та DepartmentID. Однак вона не відповідає другій нормальній формі: хоча зарплата залежить від ідентифікатора працівника та ідентифікатора відділу, роль керівника відділу повністю залежить від ідентифікатора відділу і не змінюється через ідентифікацію працівника.
Атрибути Name та Surname залежать від EmployeeID. Тому їх слід розмістити в окремій таблиці. Таким чином, деякі атрибути залежать лише від частини композитного ключа.
Ця структура може призвести до аномалії зміни: наприклад, якщо ми видалимо другий рядок, ми ненавмисно втратимо інформацію про керівника відділу, оскільки інші рядки не мають цього конкретного ідентифікатора відділу.
Нормалізація
Давай нормалізуємо за допомогою другої нормальної форми:
Оновлена база даних гарантує, що жодні атрибути не залежать лише від частини композитного ключа: таблиця відповідає другій нормальній формі, забезпечуючи збереження важливої інформації, навіть якщо рядки з початкової таблиці видаляються.
Примітка
Таблиця в першій нормальній формі без композитного ключа за замовчуванням задовольняє вимоги другої нормальної форми.
Дякуємо за ваш відгук!
