Третья нормальная форма (3НФ): транзитивные зависимости

Третья нормальная форма (3НФ) - это уровень нормализации реляционной таблицы, на котором из неё убраны транзитивные зависимости неключевых атрибутов от ключа. На практике это значит: ни одно неключевое поле не должно зависеть от другого неключевого поля, а только от ключа целиком. Звучит абстрактно, но именно нарушение 3НФ рождает дублирование данных и аномалии обновления, из-за которых одна и та же фирма в базе вдруг оказывается с двумя разными ИНН. Ниже разберём, чем 3НФ отличается от 2НФ, как пошагово найти транзитивную зависимость и как декомпозировать таблицу. Если нужно проверить конкретную схему - соберите запрос в форме ниже и получите разбор.

Что такое нормализация и зачем нужны нормальные формы

Нормализация - это процесс приведения таблиц базы данных к виду, при котором каждый факт хранится ровно в одном месте. Нормальные формы образуют лестницу: 1НФ, 2НФ, 3НФ, БКНФ и далее. Каждая следующая форма требует выполнения всех предыдущих и добавляет одно новое ограничение на структуру функциональных зависимостей.

Цель - не «красота схемы», а устранение трёх классов аномалий: вставки (нельзя добавить факт без избыточных данных), удаления (удаляя строку, теряешь не связанный с ней факт) и обновления (один факт хранится в нескольких строках, и их легко рассинхронизировать). Подробнее о всей лестнице форм - в разборе нормализации баз данных и нормальных форм. Здесь сфокусируемся именно на третьей ступени.

Рассчитать для своей задачи

Функциональная зависимость: язык нормализации

Чтобы говорить о 3НФ строго, нужен один термин - функциональная зависимость. Запись $X \rightarrow Y$ читается как «X определяет Y»: для любых двух строк, у которых совпадают значения атрибутов $X$, обязательно совпадают и значения $Y$. Например, $\text{Номер\_паспорта} \rightarrow \text{ФИО}$: один паспорт принадлежит одному человеку.

Атрибут называют ключевым, если он входит хотя бы в один потенциальный ключ таблицы, и неключевым в противном случае. Вся нормализация - это про то, чтобы все неключевые атрибуты зависели от ключа «правильным» образом:

$$K \rightarrow A_1, \quad K \rightarrow A_2, \quad \dots, \quad K \rightarrow A_n$$

где $K$ - потенциальный ключ, а $A_i$ - неключевые атрибуты. 3НФ запрещает «обходные пути», когда зависимость от ключа идёт не напрямую, а через другой неключевой атрибут.

Определение третьей нормальной формы

Таблица находится в 3НФ, если выполнены два условия:

1. Она уже находится во второй нормальной форме (2НФ).
2. Ни один неключевой атрибут не зависит транзитивно от потенциального ключа - то есть нет цепочки вида «ключ → неключевой атрибут → другой неключевой атрибут».

Формально транзитивная зависимость - это ситуация, когда существуют $K \rightarrow A$ и $A \rightarrow B$, где $A$ и $B$ неключевые, и при этом $A \not\rightarrow K$ (то есть $A$ сам не является ключом). Тогда $K \rightarrow B$ выполняется не напрямую, а транзитивно - через $A$. Именно такие цепочки 3НФ и устраняет.

Эквивалентная формулировка Кодда и Бойса: для каждой нетривиальной зависимости $X \rightarrow A$ либо $X$ - суперключ, либо $A$ - ключевой атрибут (входит в какой-то ключ). Эта формулировка удобна, когда ключей несколько.

Чем 3НФ отличается от 2НФ

2НФ и 3НФ часто путают, потому что обе борются с зависимостями неключевых атрибутов. Разница в том, от чего именно зависит лишний атрибут:

• 2НФ убирает частичную зависимость: когда неключевой атрибут зависит не от всего составного ключа, а только от его части. Эта проблема возникает только при составном ключе.
• 3НФ убирает транзитивную зависимость: когда неключевой атрибут зависит от другого неключевого атрибута. Эта проблема возникает даже при простом (одноатрибутном) ключе.

Рассчитать для своей задачи

Поэтому проверка идёт по порядку: сначала добиваемся 2НФ (нет частичных зависимостей), потом 3НФ (нет транзитивных). Перепрыгнуть нельзя: 3НФ по определению включает требование 2НФ.

Классический пример нарушения 3НФ

Возьмём таблицу Сотрудники с простым ключом Таб_номер:

Ключ - Таб_номер. Частичных зависимостей нет (ключ простой), значит 2НФ выполнена. Но есть цепочка:

$$\text{Таб\_номер} \rightarrow \text{Отдел} \rightarrow \text{Адрес\_отдела}$$

Атрибут Адрес_отдела зависит от Отдел, а Отдел - неключевой. Это транзитивная зависимость, и она порождает аномалии:

• Обновления: переехал отдел маркетинга - придётся править адрес в каждой строке его сотрудников; пропустишь одну - база противоречива.
• Удаления: уволили единственного логиста - вместе со строкой исчезнет факт «у логистики адрес корп. А».
• Вставки: новый отдел без сотрудников вписать некуда.

Как декомпозировать таблицу до 3НФ

Решение - разбить таблицу так, чтобы транзитивно зависимый «хвост» переехал в отдельную таблицу. Выносим пару Отдел → Адрес_отдела:

Таблица Сотрудники:

Таблица Отделы:

Теперь Отдел в первой таблице - внешний ключ к Отделы. Адрес каждого отдела хранится ровно один раз; переезд правится в одной строке. Обе таблицы в 3НФ: в Сотрудники все атрибуты зависят прямо от Таб_номер, в Отделы - прямо от Отдел.

Декомпозиция без потерь и сохранение зависимостей

Разбивая таблицу, важно не разрушить информацию. Хорошая декомпозиция обладает двумя свойствами:

• Без потерь соединения (lossless join): естественное соединение полученных таблиц в точности восстанавливает исходную, без лишних «призрачных» строк. Это гарантировано, если таблицы пересекаются по атрибуту, который является ключом хотя бы в одной из них (в примере выше - Отдел).
• С сохранением зависимостей (dependency-preserving): все исходные функциональные зависимости можно проверить, не выполняя соединение. Алгоритм синтеза в 3НФ всегда даёт декомпозицию с обоими свойствами - это его важное преимущество перед БКНФ, где сохранение зависимостей не всегда достижимо.

Именно поэтому 3НФ часто считают «золотой серединой»: она убирает большинство аномалий и при этом гарантированно сохраняет зависимости, чего не обещает более строгая БКНФ.

Когда 3НФ выполнена, а БКНФ - нет

3НФ - не последняя ступень. Бойса-Кодда нормальная форма (БКНФ) строже: она требует, чтобы детерминантом ($X$) любой нетривиальной зависимости был суперключ - без поблажки «или $A$ ключевой». Различие проявляется в таблицах с несколькими перекрывающимися составными ключами.

Классический случай: таблица Запись(Студент, Предмет, Преподаватель), где каждый преподаватель ведёт один предмет, а студент по предмету закреплён за одним преподавателем. Здесь $\text{Преподаватель} \rightarrow \text{Предмет}$, но Преподаватель не суперключ. Зато Предмет - ключевой атрибут, поэтому 3НФ формально выполнена, а БКНФ - нет. На практике 3НФ покрывает подавляющее большинство схем, и переход к БКНФ нужен редко.

Частые ошибки

• Проверять 3НФ, пропустив 2НФ. 3НФ по определению требует 2НФ. Если в таблице есть частичная зависимость от части составного ключа, говорить о 3НФ рано - сначала уберите частичные.
• Считать транзитивной зависимость через ключевой атрибут. Если промежуточный атрибут $A$ сам является потенциальным ключом, цепочка $K \rightarrow A \rightarrow B$ не нарушает 3НФ - это норма, а не транзитивная зависимость.
• Путать вычисляемые поля с транзитивной зависимостью. Поле Сумма = Цена × Кол-во - производное, его обычно вообще не хранят. Это вопрос денормализации ради скорости, а не нарушения 3НФ.
• Разбивать таблицу с потерей соединения. Декомпозиция, после которой JOIN порождает лишние строки, хуже исходной избыточности. Делите по атрибуту, который является ключом в одной из частей.
• Нормализовать «до упора» на любой схеме. Иногда контролируемая денормализация оправдана для производительности чтения. 3НФ - цель по умолчанию, но не догма для всех таблиц.

FAQ

Чем 3НФ отличается от 2НФ простыми словами? 2НФ убирает зависимость неключевого атрибута от части составного ключа (частичную), 3НФ - зависимость одного неключевого атрибута от другого неключевого (транзитивную). 2НФ актуальна только при составном ключе, 3НФ - и при простом тоже.

Как найти транзитивную зависимость в таблице? Выпишите все функциональные зависимости. Ищите цепочку, где ключ определяет неключевой атрибут $A$, а тот, в свою очередь, определяет ещё один неключевой атрибут $B$, причём $A$ сам не является ключом. Эта пара $A \rightarrow B$ и есть транзитивная зависимость - её выносят в отдельную таблицу.

Обязательно ли всегда приводить базу к 3НФ? В большинстве проектных схем 3НФ - разумная цель по умолчанию: она устраняет основные аномалии. Но для отчётных и аналитических хранилищ иногда сознательно денормализуют данные ради скорости чтения, принимая контролируемую избыточность.

Коротко

Третья нормальная форма (3НФ) требует, чтобы таблица была в 2НФ и не содержала транзитивных зависимостей: ни один неключевой атрибут не должен зависеть от другого неключевого. Нарушение даёт аномалии вставки, удаления и обновления. Лечится декомпозицией: транзитивно зависимая пара «неключевой → неключевой» выносится в отдельную таблицу, связь восстанавливается внешним ключом. Декомпозиция в 3НФ всегда возможна без потерь соединения и с сохранением зависимостей - поэтому 3НФ считают рабочим стандартом нормализации, а более строгую БКНФ применяют редко.