Нормальные формы и устранение аномалий

Содержание

1. 1. Проблема аномалий в реляционных базах данных3
2. 2. Функциональные зависимости и декомпозиция отношений6
3. 3. Иерархия нормальных форм: от первой до третьей8
4. 4. Практическая нормализация и ограничения метода10

1. Проблема аномалий в реляционных базах данных

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

О том, как несовершенная структура вредит делу, системно написал Уильям Кент в работе 1983 года «A Simple Guide to Five Normal Forms in Relational Database Theory». Он выделил три классических вида аномалий, и все они растут из одного корня, избыточности. Когда один и тот же факт, скажем название отдела или цена товара, повторяется в десятках записей, база данных раздувается. В учебнике Кристофера Дейта «Введение в системы баз данных» есть простой пример: таблица сотрудников с названием их отдела. Если в отделе работает 200 человек, название отдела хранится 200 раз. Прямой ущерб дисковому пространству очевиден, но настоящая беда глубже. Избыточность порождает риск рассинхронизации: один оператор запишет «Бухгалтерия», другой, с опечаткой, «Бухгалтерия» (с мягким знаком на конце). Система не заметит противоречия, ведь формально это просто разные строки.

Аномалия вставки появляется, когда для добавления нового факта приходится заполнять поля, которые к нему не относятся. Допустим, у нас есть таблица, где одновременно хранятся и преподаватели, и их кафедры. Чтобы открыть новую кафедру, на которой пока нет ни одного преподавателя, придётся вставить строку с пустыми значениями для сотрудника. Либо, что хуже, использовать фиктивные данные вроде «NULL» или

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

Аномалия обновления, это обратная сторона избыточности. Если преподаватель переходит с одной кафедры на другую, нужно найти каждую строку, где он упоминается, и изменить их все. Пропустишь хотя бы одну, и база данных начнёт противоречить сама себе: в одной таблице человек числится на кафедре математики, в другой, на кафедре информатики. В 1990-х годах, когда базы данных активно внедрялись в банковской сфере, именно такие ошибки приводили к расхождениям в отчётности. Чем больше строк, тем серьёзнее проблема: обновление превращается не в один запрос, а в серию операций, которые обязаны выполниться атомарно. Если что-то пойдёт не так, система застрянет в промежуточном, несогласованном состоянии.

Аномалия удаления самая коварная, потому что она ведёт к безвозвратной потере информации. Вернёмся к таблице преподавателей и кафедр. Последний преподаватель увольняется, строка удаляется. А вместе с ней исчезают название кафедры, её телефон, номер аудитории. Данные, которые характеризуют кафедру как самостоятельную сущность и к преподавателю отношения не имеют, уничтожаются. Теоретически их можно восстановить из резервной копии, но резервные копии на каждый чих никто не делает.

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

дефекты. Но об этом, в следующих главах.

2. Функциональные зависимости и декомпозиция отношений

Фундаментом анализа избыточности служит понятие функциональной зависимости. Формально оно записывается как X → Y и читается так: множество атрибутов X однозначно определяет множество атрибутов Y. Иными словами, если в отношении две строки совпадают по значениям X, они обязаны совпадать и по значениям Y. Детерминантом при этом называют левую часть зависимости, то есть тот набор атрибутов, который служит «ключом» для определения других. Это не абстрактное умозаключение, а строгое ограничение целостности, которое выполняется для любого допустимого состояния базы данных.

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

Устранить такую несогласованность позволяет декомпозиция. Исходное отношение разбивается на два или более меньших отношений таким образом, чтобы каждая нежелательная зависимость оказалась изолирована в отдельной таблице. Например, если атрибут Y зависит от неключевого атрибута X, логично вынести пару (X, Y) в самостоятельное отношение, а в исходной таблице оставить только ссылку на X. Это разрывает порочный круг повторения данных, поскольку каждое значение детерминанта теперь хранится ровно один раз.

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

Критерий обратимости формулируется через функциональные зависимости. Чтобы декомпозиция отношения R на R1 и R2 была соединением без потерь, пересечение их атрибутов должно быть детерминантом хотя бы для одного из этих отношений. Иными словами, общий атрибут обязан выступать ключом в R1 или в R2. Это условие, впервые строго доказанное в рамках реляционной теории, дает простой практический тест: достаточно проверить, выполняются ли нужные зависимости на пересечении схем. Если да, соединение гарантированно вернет исходное отношение без искажений. Такой подход превращает декомпозицию из интуитивной операции в проверяемую процедуру, где корректность обеспечивается формальным аппаратом функциональных зависимостей, а не удачей проектировщика.

3. Иерархия нормальных форм: от первой до третьей

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

Первая нормальная форма, или 1НФ, требует, чтобы каждый атрибут в отношении был атомарным. То есть в ячейке таблицы должно храниться ровно одно значение, а не список или набор. Например, хранение нескольких телефонных номеров в одном поле через запятую нарушает атомарность. То же касается повторяющихся групп, когда в одной строке фиксируются несколько значений одного типа (скажем, три столбца для трех номеров телефонов). Кодд в своей работе 1970 года «A Relational Model of Data for Large Shared Data Banks» прямо указывал, что домены должны содержать только неделимые значения. Соблюдение 1НФ гарантирует, что каждая строка описывает ровно один факт, а любое обращение к конкретному значению не требует парсинга строки.

Дальше идет вторая нормальная форма. Её условие касается отношений с составным первичным ключом, то есть ключом из двух и более атрибутов. 2НФ требует, чтобы каждый неключевой атрибут зависел от всего составного ключа целиком, а не от какой-то его части. Предположим, отношение описывает оценки студентов по курсам. Ключом будет пара «студент + курс». Если добавить атрибут «телефон студента», он зависит только от студента, а не от пары. Это частичная зависимость. Она приводит к тому, что телефон студента дублируется в каждой строке с его оценками, а при смене номера придется обновлять все записи. Устраняется проблема выносом данных о студенте в отдельное отношение, где ключом будет сам студент.

Третья нормальная форма работает с транзитивными зависимостями. Неключевой атрибут не должен зависеть от другого неключевого атрибута. Формально это выглядит так: если A это первичный ключ, B неключевой атрибут, а C ещё один неключевой атрибут, то зависимость A → B → C недопустима. Например, в таблице сотрудников с ключом «табельный номер» есть атрибуты «отдел» и «руководитель отдела». Руководитель зависит от отдела, а не от сотрудника. При смене руководителя придётся править все строки сотрудников этого отдела, а сам руководитель будет повторяться многократно. Решение в том, чтобы выделить отдел с его руководителем в отдельную таблицу. 2НФ автоматически соблюдается в 3НФ, а 1НФ является базисом для обеих.

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

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

4. Практическая нормализация и ограничения метода

К третьей нормальной форме схему почти всегда можно довести вручную. Но в 1974 году Рэймонд Бойс и Эдгар Кодд описали редкий случай, когда таблица соответствует 3НФ, однако всё равно порождает аномалии. Проблема в том, что третья нормальная форма игнорирует зависимости, где детерминант не является ключом, а сам атрибут при этом неключевой. Так появилась нормальная форма Бойса-Кодда (BCNF). Её требование жёстче: каждый детерминант обязан быть потенциальным ключом. Иными словами, если X → Y и Y не входит в состав ключа, то X должен сам по себе быть кандидатом в ключи. На практике это означает полное исключение избыточности, связанной с функциональными зависимостями. Классический пример с преподавателями и дисциплинами (профессор ведёт только один предмет, а предмет могут вести несколько профессоров) ломает 3НФ, но спокойно проходит проверку BCNF.

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

Здесь и начинается главное ограничение метода. Чрезмерная нормализация превращает базу данных в витрину с сотней мелких таблиц. Запрос на чтение, который в неразделённой схеме выполнялся бы одним сканированием, теперь требует пяти-шести соединений (JOIN). А соединения стоят дорого: они нагружают процессор, потребляют память и растягивают

время ответа. Для транзакционных систем с высокой частотой чтения это критично. Показателен пример интернет-магазинов: корзина заказов, полностью нормализованная до BCNF, превращается в семь таблиц, и каждая страница каталога собирается через десятки операций объединения. При нагрузке в тысячу запросов в секунду такие запросы ложат даже мощные серверы.

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

Наконец, нормализация не отвечает на вопрос, какие данные вообще стоит хранить. Метод работает только с уже заданным набором атрибутов и зависимостей, но не проверяет, отражают ли они реальный мир. Семантику данных, бизнес-правила, смысл понятий, допустимые диапазоны значений нормальные формы не учитывают. Схема может быть в BCNF и при этом бесполезной, если проектировщик неправильно понял предметную область. Требования приложений тоже остаются за скобками: нормализованная модель не подскажет, какие запросы будут частыми, а какие редкими. Это значит, что нормализация лишь один из инструментов проектирования, а не универсальный рецепт. Грамотный проектировщик сначала строит логическую модель по правилам нормальных форм, а затем адаптирует её под физическую реализацию, отступая от теории там, где это оправдано измеримой выгодой.