Нормальная форма Бойса-Кодда

Нормальная форма Бойса-Кодда (BCNF) вводит дополнительное ограничение по сравнению с третьей нормальной формой (3NF). Это означает ограничение на функциональные зависимости между атрибутами в отношении. BCNF тесно связана с понятием ключей и детерминант в реляционной модели данных.

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

Отношение может быть в третьей нормальной форме, но не соответствовать BCNF, если в нем присутствуют составные ключи, состоящие из нескольких атрибутов, которые пересекаются по одному общему атрибуту, и при этом возникают функциональные зависимости, нарушающие условие BCNF. Такие ситуации встречаются редко в практике. При отсутствии подобных пересечений 3NF и BCNF оказываются эквивалентными.

Принцип работы нормальной формы Бойса-Кодда

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

Механика: при проектировании базы данных проверяют все функциональные зависимости. Для каждого X → Y проверяют, является ли X суперключом. Если нет – отношение разлагают. Разложение проводится по алгоритму:

1. Выделяют функциональную зависимость с левым атрибутом, не являющимся суперключом.
2. Отношение разбивается на два: первое содержит X и Y (основные атрибуты зависимости), второе – исходное отношение за вычетом Y с добавлением X.
3. Процесс повторяют для новых отношений, пока все отношения не удовлетворят BCNF.

Следствие: в результате получается набор отношений без избыточностей, обеспечивается устранение аномалий изменения данных.

Типичные ошибки и ограничения применения BCNF

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

Кроме того, надмножество ограничений BCNF может привести к чрезмерному дроблению таблиц, что ухудшает производительность операций выборки. Это связано с необходимостью слияния данных из нескольких таблиц через соединения (join-операции).

Граничное условие: если в отношении присутствуют только ключевые зависимости, или все функциональные зависимости имеют ключевую левой часть, BCNF совпадает с 3NF. Разница проявляется при наличии перекрывающихся составных ключей и функциональных зависимостей между ними.

Пример нарушения BCNF и последствия

Рассмотрим отношение «Оплата за работу» с ключом Номер_Работника. В нем определены функциональные зависимости:

• Номер_Работника → Стаж
• Номер_Работника → Оплата
• Стаж → Оплата

Последняя зависимость нарушает BCNF, поскольку атрибут Стаж, не являясь ключом, определяет Оплату.

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

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

Разложение таблиц по BCNF на практике

Для исправления вышеописанных аномалий отношение «Оплата за работу» раскладывают на две таблицы:

• «Работник 1» — содержит атрибуты с ключом Номер_Работника и нецелевые атрибуты (Стаж удалён).
• «Работник 2» — содержит атрибуты Стаж (ключ) и Премиальные.

Такое разбиение устраняет недопустимые функциональные зависимости с неключевыми детерминантами. В итоге обе таблицы соответствуют BCNF.

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

Сравнение BCNF и альтернативных нормальных форм

3NF допускает функциональные зависимости, где левая часть не является суперключом, если правый атрибут составной частью ключа или неключевой и не транзитивно зависит. Это снижает требования по сравнению с BCNF.

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

Во многих практических случаях базы данных проектируют чтобы достигать 3NF, как компромисс между избыточностью и сложностью. BCNF применяют для устранения редких но технически серьезных нарушений.

Типичные причины несоответствия BCNF и рекомендации

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

Если отношение не удовлетворяет BCNF, рекомендуется выполнить следующее:

• Определить функциональную зависимость с детерминантом, который не является суперключом.
• Провести разбиение отношения на две части, перенеся зависимые атрибуты и копию детерминанта в новое отношение.
• Повторить анализ для новых отношений.

Необходимо учитывать, что общее число разложенных таблиц может увеличиться на 20-30% в зависимости от объема функциональных зависимостей.

Матрица выбора нормальной формы для проектирования

В таблице представлены условия выбора между 3NF и BCNF с указанием преимуществ и недостатков.

Выбор нормальной формы зависит от приоритетов проекта. BCNF дает максимальную степень нормализации, но требует расчета и контроля функциональных зависимостей и возможно усложняет архитектуру. 3NF часто оказывается достаточной, особенно при отсутствии сложных ключей.