Первая, вторая и третья нормальные формы

Содержание

1. 1. Нормализация: зачем и когда3
2. 2. Первая нормальная форма: атомарность5
3. 3. Вторая и третья нормальные формы7
4. 4. Практическая значимость нормальных форм9

1. Нормализация: зачем и когда

Проектирование базы данных редко начинается с чистого листа. Обычно схема вырастает из потребностей конкретного приложения, и это естественный путь. Но у такого подхода есть обратная сторона. Данные, которые хранятся так, как их удобно вводить, со временем начинают противоречить сами себе. Нормализация предлагает другой путь. Это процесс проектирования схемы, который сознательно устраняет избыточность и аномалии ещё до того, как они превратятся в ошибки.

Избыточность выглядит безобидно, пока её мало. Один лишний столбец с названием отдела в таблице сотрудников не мешает работать. Но когда таких столбцов десятки, а строк миллионы, цена дублирования становится очевидной. Расходуется память, замедляются запросы, а главное, возникает риск рассинхронизации. Если название отдела изменилось, его нужно обновить в каждой строке, где оно встречается. Пропустил одну строку, и в базе уже два разных названия одного и того же отдела. Кто из них прав, система не знает.

Именно здесь проявляются аномалии, о которых говорят в контексте нормализации. Аномалия вставки возникает, когда вы не можете добавить данные, не добавив что-то ещё. Скажем, вы хотите зарегистрировать новый отдел, в котором пока нет ни одного сотрудника. Если отдел хранится только в таблице сотрудников, такая вставка невозможна: запись без сотрудника не имеет смысла. Аномалия обновления, как в примере с названием отдела, заставляет изменять одни и те же данные во многих местах. Аномалия удаления действует в обратную сторону. Удаляя последнего сотрудника отдела, вы теряете информацию о самом отделе. Данные испаряются вместе со строкой, которая их случайно содержала.

Нормальные формы решают эти проблемы не по отдельности, а по нарастающей. Это последовательные уровни требований к структуре таблиц. Каждый

следующий уровень снимает определённый класс недостатков, оставляя предыдущие требования в силе. Схема, которая прошла все три уровня, хранит каждый факт ровно в одном месте. Эта идея, один факт в одном месте, лежит в основе всего подхода.

Исторически нормализация появилась не как абстрактная теория, а как ответ на практическую проблему. В 1970 году Эдгар Кодд, работавший в IBM, опубликовал статью, в которой описал реляционную модель данных. До неё базы строились на иерархических и сетевых структурах, где навигация по связям была частью программирования. Кодд предложил рассматривать данные как простые таблицы, а связи между ними устанавливать на основе значений, а не указателей. В той же работе он впервые сформулировал понятие нормальной формы, причём сразу первой, второй и третьей. Реляционная модель дала язык описания, а нормальные формы стали правилами гигиены для этого языка.

Кодд не изобретал нормализацию как нечто внешнее по отношению к своей модели. Она была её неотъемлемой частью, способом гарантировать, что таблицы действительно отражают реальные сущности, а не случайные срезы данных. Его идеи быстро вышли за пределы IBM и легли в основу теории реляционных баз данных, которая до сих пор преподаётся в университетах. Сегодня нормальные формы воспринимаются как базовая грамотность проектировщика, но в начале семидесятых это был радикальный шаг. Вместо того чтобы подстраивать структуру хранения под запросы, Кодд предложил подстраивать структуру под природу самих данных.

2. Первая нормальная форма: атомарность

Первая нормальная форма была определена Эдгаром Коддом ещё в 1970 году. Её требование к каждой таблице реляционной базы данных сводится к одному: каждое поле должно хранить только одно значение. Это значение должно быть атомарным, то есть неделимым в контексте решаемой задачи. Впрочем, атомарность, понятие относительное. Телефонный номер, записанный как «+7 (495) 123-45-67», для системы учёта клиентов является единым целым. А вот для сервиса международных звонков его пришлось бы разбить на код страны, код города и сам номер.

Нарушением 1НФ считается наличие многозначных полей или повторяющихся групп. Классический пример, таблица сотрудников, где в ячейке «Телефон» перечислены через запятую рабочий, домашний и мобильный номера. Такой формат делает запросы крайне неудобными. Чтобы найти сотрудника по конкретному номеру, придётся применять нетривиальные строковые функции для поиска подстроки, что и медленно, и чревато ошибками. Аналогичная проблема возникает, если в таблице заказов хранить несколько товаров в одном поле или завести отдельные колонки «Товар1», «Товар2», «Товар3». Второй вариант, кстати, хуже. Он ограничивает количество позиций в заказе и требует изменения структуры таблицы при расширении ассортимента.

Процесс приведения к первой нормальной форме обычно сводится к двум основным приёмам. Первый, вынести повторяющиеся данные в отдельную таблицу и связать её с исходной через внешний ключ. Второй, если повторяющаяся группа невелика и жёстко ограничена, её можно развернуть в отдельные строки. В примере с телефонами сотрудников это означает следующее: вместо одной записи на человека с тремя номерами в одной ячейке мы создаём три строки в таблице «Телефоны», каждая с идентификатором сотрудника и одним номером. Кодд в своих ранних работах настаивал именно на таком подходе. Любое пересечение

строки и столбца должно содержать ровно одно значение из допустимого домена, и никак иначе.

Важно понимать, что 1НФ, лишь отправная точка, а не панацея. Она является базовым требованием для любой реляционной базы данных, и без неё дальнейшая нормализация просто бессмысленна. Однако сама по себе первая нормальная форма не избавляет от избыточности данных. Таблица, где в каждом заказе повторяется полное название поставщика и его адрес, вполне удовлетворяет требованию атомарности: каждое поле содержит одно значение. Но при изменении адреса поставщика придётся обновлять все строки с его заказами, а это прямой путь к аномалиям обновления. Устранить такие проблемы призваны вторая и третья нормальные формы, о которых речь пойдёт дальше. Пока же стоит запомнить: 1НФ, это фундамент, но только фундамент. На нём одном здание корректной базы данных не построить.

3. Вторая и третья нормальные формы

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

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

Классический пример есть в книге Кристофера Дейта «Введение в системы баз данных». Возьмём таблицу «Заказы» с атрибутами: номер заказа, код товара, название товара, цена товара и поставщик. Первичный ключ здесь составной: номер заказа плюс код товара. Название товара, его цена и поставщик зависят только от кода товара. Номер заказа на них не влияет. Это частичная зависимость. Последствия понятны: если товар заказывают десять раз, его название и поставщик повторяются десять раз. Избыточность очевидна, а при изменении цены придётся править все строки с этим товаром.

Решение стандартное, декомпозиция. Исходную таблицу разбивают на две. В первой хранится информация о заказе (номер заказа, код товара), во второй, о товаре (код товара, название, цена, поставщик). Связь между ними идёт через код товара. Теперь каждый факт о товаре существует в единственном экземпляре.

Но даже во второй нормальной форме остаются скрытые слабые места. Третья нормальная форма (3НФ) требует, чтобы таблица

находилась в 2НФ и не содержала транзитивных зависимостей. Транзитивная зависимость возникает, когда неключевой атрибут зависит от другого неключевого атрибута. Проще говоря, через промежуточный столбец можно добраться до данных, которые напрямую с ключом не связаны.

Снова обратимся к таблице товаров. Пусть в ней есть код товара, название, поставщик и город поставщика. Код товара определяет поставщика, а поставщик определяет город. Получается цепочка: ключ → поставщик → город. Город не зависит от ключа напрямую, он зависит от поставщика. Это транзитивная зависимость. Она опять порождает избыточность: если один поставщик поставляет пять товаров, его город записан пять раз.

Исправление снова требует декомпозиции. Выделяем отдельную таблицу «Поставщики» с полями: код поставщика, название, город. Таблица «Товары» теперь хранит только код товара, название и код поставщика. В итоге информация о городе хранится ровно один раз для каждого поставщика.

Определение 3НФ, которое Эдгар Кодд дал в 1971 году, гласит: таблица находится в третьей нормальной форме, если она в 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Иными словами, любой неключевой атрибут должен зависеть только от ключа и ни от чего больше.

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

4. Практическая значимость нормальных форм

Нормальные формы решают проблемы проектирования, это факт. Но практическая ценность нормализации измеряется конкретными последствиями для работы с данными. Разбиение таблиц до третьей формы напрямую снижает избыточность. Когда информация о поставщике хранится в одном месте, а не повторяется в каждой строке заказа, объём базы сокращается. Главное, исчезает почва для расхождений.

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

Это свойство напрямую влияет на целостность. Устранение аномалий вставки и удаления означает, что вы не сможете случайно потерять информацию о товаре, удалив последний заказ, в котором он упоминался. Система становится устойчивее к ошибкам оператора и сбоям приложения. Целостность данных это не абстрактный идеал, а гарантия того, что отчёты по продажам и бухгалтерские выписки сойдутся. Поэтому большинство корпоративных систем проектируются с расчётом минимум на третью нормальную форму.

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

Но у этой медали есть обратная сторона. Чем глубже нормализация, тем больше таблиц участвует в одном запросе. Для получения сводки по заказам с именами клиентов и названиями товаров системе приходится выполнять несколько соединений (JOIN). Каждое соединение это вычислительная операция, которая на больших объёмах данных может занимать миллисекунды. В сумме эти миллисекунды превращаются в заметные задержки. Особенно остро проблема стоит в системах с высокой нагрузкой на чтение, например, в интернет-магазинах, где каталог просматривают тысячи пользователей одновременно.

Здесь возникает классический конфликт. Абсолютно нормализованная база гарантирует консистентность, но может не уложиться в требования по скорости ответа. Поэтому на практике инженеры сознательно отступают от канонов. Денормализация (частичный возврат к избыточности) используется для оптимизации самых частых и тяжёлых запросов. Например, можно добавить в таблицу заказов поле с именем клиента, продублировав его из справочника. Это нарушает третью нормальную форму, но избавляет от одного соединения при каждой загрузке страницы.

Выбор между нормализацией и денормализацией это всегда компромисс, который зависит от сценария использования. В системах, где критична скорость записи и частота обновлений (банковские транзакции, логистика), приоритет отдают нормальным формам, чтобы избежать ошибок при параллельных изменениях. В аналитических хранилищах, где данные обновляются раз в сутки, а читаются постоянно, денормализация почти всегда оправдана. Классический пример, схема «звезда» в OLAP-кубах, где таблицы фактов намеренно содержат избыточные описания измерений.

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

сначала схема доводится до 3НФ, а затем осознанно упрощается в конкретных местах под конкретные задачи. Такой подход позволяет сохранить целостность данных там, где она нужна, и ускорить работу там, где это важнее. Именно эта осознанность, а не слепое следование правилам, отличает грамотную архитектуру базы данных.