Сколько уровней нормализации существует

Что проверяют

Помните ли вы нормальные формы по смыслу, а не по счёту, и понимаете ли, где нормализацию разумно останавливать. Заодно смотрят, отличаете ли вы теорию от практики: в продуктовой базе и в аналитической витрине уместны разные ответы.

Как отвечать

Формально описанных форм больше, чем обычно называют: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, плюс редкие шестая и доменно-ключевая. На практике доходят до третьей с половиной и останавливаются. Коротко по существу:

• 1NF: значения атомарны, нет повторяющихся групп и списков внутри одной ячейки;
• 2NF: имеет смысл только при составном ключе, неключевые атрибуты зависят от всего ключа, а не от его части;
• 3NF: нет транзитивных зависимостей, неключевой атрибут не определяется другим неключевым;
• BCNF: любой детерминант является суперключом, это усиление третьей формы;
• 4NF и 5NF: многозначные зависимости и зависимости соединения, встречаются редко.

Сильный ответ добавляет, что третья форма не догма. В витринах и отчётах денормализуют осознанно ради скорости чтения, в PostgreSQL слабо структурированные атрибуты уезжают в jsonb. Цену назовите сами: дублирование требует, чтобы кто-то держал копии согласованными, обычно триггером или пересчётом по расписанию.

Где спотыкаются

Называют BCNF четвёртой формой или вставляют её в нумерацию как отдельную ступень. Это усиленная третья, а не следующая по счёту, и ошибка сразу показывает, что формы учили списком, а не по определениям.

Второе: применяют вторую форму к таблице с одиночным первичным ключом. Частичной зависимости от части ключа там не бывает по построению, так что рассуждение про неё лишнее.

Третье: нормализуют до упора и получают запрос с десятком соединений. Для python-сервиса на ORM это особенно заметно: ленивые связи превращаются в проблему N+1, и лечится она не денормализацией, а select_related или joinedload.