Нормальные формы 1NF / 2NF / 3NF: чем отличаются

Условие

Какие условия должны быть выполнены для соответствия таблицы 1NF, 2NF и 3NF? В какой нормальной форме устраняются транзитивные зависимости?

Решение

1NF — атомарность

Все значения атомарны, в одной колонке нет списков/массивов/JSON. Тип данных в колонке единый. Нет дублирующихся строк.

Анти-пример (нарушение 1NF):

Решение: вынести в отдельную таблицу client_phones(client_id, phone).

2NF — полная функциональная зависимость

Таблица в 1NF, и каждый неключевой атрибут зависит от всего составного ключа целиком, а не от его части.

Анти-пример: ключ (order_id, product_id), атрибут product_name зависит только от product_id.

Решение: вынести product_name в отдельную таблицу products.

3NF — нет транзитивных зависимостей

Таблица в 2NF, и неключевые атрибуты не зависят друг от друга — только напрямую от ключа.

Анти-пример:

client_city транзитивно зависит от order_id через client_id. Решение: вынести client_city в clients.

Итог

Зачем нормализация

• Минимизирует избыточность (данные не дублируются).
• Уменьшает риск аномалий при INSERT/UPDATE/DELETE (нельзя обновить только часть копий).
• Повышает целостность.

Когда денормализуют

В DWH/витринах сознательно идут на денормализацию (звезда/снежинка), чтобы избежать большого числа JOIN'ов и ускорить чтение.

Подводные камни

1. 2NF осмысленна только при составном ключе. Если PK из одной колонки — 1NF автоматически = 2NF.
2. 3NF не = BCNF. BCNF строже: убирает зависимости и от ключей-кандидатов. На практике их различие проявляется редко.
3. «Атомарность» в 1NF — спорный термин. Дата 2024-01-15 атомарна, хотя содержит год/месяц/день.
4. Чрезмерная нормализация → много JOIN, медленные запросы. В аналитике сознательно денормализуют.

Эталонный ответ

1NF: атомарность. 2NF: 1NF + полная зависимость от составного ключа. 3NF: 2NF + отсутствие транзитивных зависимостей. Транзитивные зависимости устраняются именно в 3NF.