📊 Продвинутые нормальные формы в реляционных базах данных
Если 1NF, 2NF и 3NF (разобрали в этом посте) помогают избежать дублирования данных и аномалий обновления, то 4NF, 5NF и 6NF направлены на устранение более сложных зависимостей и оптимизацию структуры данных.
Давайте разберёмся, зачем они нужны и когда их применять.
4️⃣ Четвёртая нормальная форма (4NF) — применяется для устранения многозначных зависимостей, где столбец с первичным ключом имеет связь «один-ко-многим» со столбцом, который не является ключом. Эта форма устраняет некорректные отношения «многие-ко-многим».
Требование:
1. Таблица уже в 3NF
2. Нет многозначных зависимостей
❌ Плохо (не 4NF):
Представим, что один преподаватель может вести несколько предметов и работать в нескольких аудиториях.
teacher_id subject classroom
1 SQL 101
1 Python 101
1 SQL 102
1 Python 102
Преподаватель 1 ведёт несколько предметов и работает в нескольких аудиториях. Предмет и аудитория независимы, но при этом создают дублирование данных.
✔️ Хорошо (4NF):
Разбиваем таблицу на две:
Преподаватель — Предмет:
teacher_id subject
1 SQL
1 Python
Преподаватель — Аудитория:
teacher_id classroom
1 101
1 102
Теперь предмет и аудитория хранятся отдельно, убирая многозначную зависимость.
5️⃣ Пятая нормальная форма (5NF) — разделяет таблицы на более малые таблицы для устранения избыточности данных. Разбиение идёт до тех пор, пока нельзя будет воссоздать оригинальную таблицу путём объединения малых таблиц.
Требование:
1. Таблица уже в 4NF.
2. Нет соединительных (join) зависимостей — данные не должны разлагаться на более мелкие части без потери информации.
❌ Плохо (не 5NF):
project_id employee_id role
1 100 Разработчик
1 101 Тестировщик
2 100 Разработчик
2 102 Аналитик
Каждый проект связан с сотрудником и его ролью, но возможны дублирования.
✔️ Хорошо (5NF):
Разделяем на три таблицы
Проекты:
project_id
1
2
Сотрудники:
employee_id
100
101
102
Связь проектов и сотрудников через роли в новой стаблице:
project_id employee_id role
1 100 Разработчик
1 101 Тестировщик
2 100 Разработчик
2 102 Аналитик
Теперь данные связаны через таблицы без лишнего дублирования.
6️⃣ Шестая нормальная форма (6NF) — Каждое ограничение в связях между таблицами должно зависеть только от ключей и доменов, т.е допустимых значений столбцов. 6NF предотвращает недопустимые данные, устанавливая ограничения на уровне отношений, а не отдельных таблиц или столбцов.
Требование:
1. Таблица уже в 5NF.
2. Разделение на атомарные отношения (каждое изменение данных должно касаться только одной сущности).
Важно: 6NF встречается редко и полезна в хранилищах данных и системах, требующих историчности данных. По своему опыту скажу, что она скорее теоретическая и направлена на устранение всех возможных избыточностей.
Пример:
Допустим, нам нужно хранить историю изменения зарплаты сотрудников.
❌ Плохо (не 6NF):
employee_id salary dep date
1 5000 IT 2024-01-01
1 5500 IT 2024-03-01
1 5500 HR 2024-05-01
Изменение отдела ведёт к дублированию зарплаты, что может привести к несогласованности данных.
✔️Хорошо (6NF):
Разделяем данные на независимые отношения:
История зарплаты
employee_id salary date
1 5000 2024-01-01
1 5500 2024-03-01
История департаментов
employee_id dep date
1 IT 2024-01-01
1 HR 2024-05-01
Теперь изменения хранятся отдельно и позволяют вести историю без дублирования.
💡Вывод
Продвинутые нормальные формы помогают устранить избыточные зависимости и дублирование, улучшая целостность данных.
4NF – исключает многозначные зависимости.
5NF – убирает дубли через разбиение отношений.
6NF – делает данные полностью атомарными, что полезно для историчности.
#Реляционные_базы_данных #Оптимизация_SQL #Нормализация
📱 Подписаться на канал | Курс автора по SQL DDL
Если 1NF, 2NF и 3NF (разобрали в этом посте) помогают избежать дублирования данных и аномалий обновления, то 4NF, 5NF и 6NF направлены на устранение более сложных зависимостей и оптимизацию структуры данных.
Давайте разберёмся, зачем они нужны и когда их применять.
4️⃣ Четвёртая нормальная форма (4NF) — применяется для устранения многозначных зависимостей, где столбец с первичным ключом имеет связь «один-ко-многим» со столбцом, который не является ключом. Эта форма устраняет некорректные отношения «многие-ко-многим».
Требование:
1. Таблица уже в 3NF
2. Нет многозначных зависимостей
❌ Плохо (не 4NF):
Представим, что один преподаватель может вести несколько предметов и работать в нескольких аудиториях.
teacher_id subject classroom
1 SQL 101
1 Python 101
1 SQL 102
1 Python 102
Преподаватель 1 ведёт несколько предметов и работает в нескольких аудиториях. Предмет и аудитория независимы, но при этом создают дублирование данных.
✔️ Хорошо (4NF):
Разбиваем таблицу на две:
Преподаватель — Предмет:
teacher_id subject
1 SQL
1 Python
Преподаватель — Аудитория:
teacher_id classroom
1 101
1 102
Теперь предмет и аудитория хранятся отдельно, убирая многозначную зависимость.
5️⃣ Пятая нормальная форма (5NF) — разделяет таблицы на более малые таблицы для устранения избыточности данных. Разбиение идёт до тех пор, пока нельзя будет воссоздать оригинальную таблицу путём объединения малых таблиц.
Требование:
1. Таблица уже в 4NF.
2. Нет соединительных (join) зависимостей — данные не должны разлагаться на более мелкие части без потери информации.
❌ Плохо (не 5NF):
project_id employee_id role
1 100 Разработчик
1 101 Тестировщик
2 100 Разработчик
2 102 Аналитик
Каждый проект связан с сотрудником и его ролью, но возможны дублирования.
✔️ Хорошо (5NF):
Разделяем на три таблицы
Проекты:
project_id
1
2
Сотрудники:
employee_id
100
101
102
Связь проектов и сотрудников через роли в новой стаблице:
project_id employee_id role
1 100 Разработчик
1 101 Тестировщик
2 100 Разработчик
2 102 Аналитик
Теперь данные связаны через таблицы без лишнего дублирования.
6️⃣ Шестая нормальная форма (6NF) — Каждое ограничение в связях между таблицами должно зависеть только от ключей и доменов, т.е допустимых значений столбцов. 6NF предотвращает недопустимые данные, устанавливая ограничения на уровне отношений, а не отдельных таблиц или столбцов.
Требование:
1. Таблица уже в 5NF.
2. Разделение на атомарные отношения (каждое изменение данных должно касаться только одной сущности).
Важно: 6NF встречается редко и полезна в хранилищах данных и системах, требующих историчности данных. По своему опыту скажу, что она скорее теоретическая и направлена на устранение всех возможных избыточностей.
Пример:
Допустим, нам нужно хранить историю изменения зарплаты сотрудников.
❌ Плохо (не 6NF):
employee_id salary dep date
1 5000 IT 2024-01-01
1 5500 IT 2024-03-01
1 5500 HR 2024-05-01
Изменение отдела ведёт к дублированию зарплаты, что может привести к несогласованности данных.
✔️Хорошо (6NF):
Разделяем данные на независимые отношения:
История зарплаты
employee_id salary date
1 5000 2024-01-01
1 5500 2024-03-01
История департаментов
employee_id dep date
1 IT 2024-01-01
1 HR 2024-05-01
Теперь изменения хранятся отдельно и позволяют вести историю без дублирования.
💡Вывод
Продвинутые нормальные формы помогают устранить избыточные зависимости и дублирование, улучшая целостность данных.
4NF – исключает многозначные зависимости.
5NF – убирает дубли через разбиение отношений.
6NF – делает данные полностью атомарными, что полезно для историчности.
#Реляционные_базы_данных #Оптимизация_SQL #Нормализация
📱 Подписаться на канал | Курс автора по SQL DDL