Если допустимость каждой тройки «поставщик — деталь — проект» полностью определяется тремя попарными связями, какую нормализационную проблему выявляет хранение троек в одной таблице?
Это признак нарушения пятой нормальной формы, также называемой нормальной формой проекций-соединений. Если тройка полностью выводится из трёх попарных связей, хранение её целиком дублирует информацию и может порождать аномалии вставки, изменения и удаления.
В таком случае исходную таблицу обычно декомпозируют на связи «поставщик — деталь», «поставщик — проект» и «проект — деталь». Но это корректно только при подтверждённом бизнес-правиле: любая комбинация допустимых пар действительно образует допустимую тройку.
Ранние этапы нормализации в основном устраняли избыточность, связанную с функциональными зависимостями: например, когда один атрибут определяется ключом или часть составного ключа определяет неключевой атрибут.
Позже стало понятно, что даже отсутствие таких зависимостей не исключает избыточность, возникающую из связи нескольких независимых отношений. Для таких случаев используется концепция зависимости соединения и пятая нормальная форма.
Пусть таблица хранит факт участия поставщика в проекте с поставкой определённой детали. Если этот факт всегда следует из трёх отдельных утверждений о попарных связях, одна и та же информация хранится многократно — по одной строке на каждую допустимую комбинацию.
Это создаёт риски:
Однако механическое разбиение опасно. Если допустимость тройки зависит не только от попарных связей, соединение трёх таблиц создаст ложные комбинации.
Проверяют, выполняется ли для исходного отношения зависимость соединения:
R = проекция на «поставщик — деталь» ⋈ проекция на «поставщик — проект» ⋈ проекция на «проект — деталь».
Если равенство верно для всех допустимых данных, исходную таблицу можно заменить тремя таблицами попарных связей. При этом каждая связь обычно получает составной первичный ключ из двух идентификаторов, а внешние ключи обеспечивают ссылочную целостность.
Минимальный пример структуры:
Исходные тройки получают соединением этих отношений. Первичные ключи не позволяют повторять одну и ту же пару, а внешние ключи не дают создать связь со ссылкой на несуществующую сущность.
Главное ограничение — декомпозиция сохраняет только ту семантику, которая действительно выражается попарными отношениями. Если поставщик может поставлять деталь для одного проекта, но не для другого, несмотря на наличие всех трёх пар, нужны либо исходная тройка, либо отдельное отношение исключений/разрешений.
Таким образом, 5НФ не означает «всегда разбивать таблицу на бинарные связи». Она требует устранить избыточность, обусловленную нетривиальной зависимостью соединения, когда декомпозиция является семантически точной.
В системе закупок хранили тройки «поставщик — деталь — проект». Анализ правил показал, что поставщик отдельно аккредитован для проекта, отдельно имеет право поставлять деталь, а проект допускает эту деталь. Любая тройка, удовлетворяющая всем трём условиям, считалась разрешённой.
Рассматривались три варианта. Оставить одну тройную таблицу было проще для чтения, но данные дублировались. Разбить её только на две таблицы нельзя: это потеряло бы часть правил. Добавить три попарные таблицы и получать тройки соединением было сложнее для запросов, но устраняло дублирование.
Выбрали третий вариант: три отношения с составными первичными ключами и внешними ключами на справочники поставщиков, деталей и проектов. В результате изменение аккредитации поставщика выполнялось в одной таблице, а новые тройки не требовали массовой вставки производных строк.
Перед миграцией отдельно проверили, что существующие тройки совпадают с результатом соединения трёх проекций. Если бы проверка не прошла, это означало бы, что тройная связь содержит самостоятельную бизнес-семантику и её нельзя безопасно заменить попарными отношениями.
Всегда ли наличие трёх попарных связей означает допустимость тройки?
Нет. Это должно быть отдельным бизнес-правилом, а не предположением разработчика. Если допустимость зависит от конкретной комбинации всех трёх сущностей, попарная декомпозиция создаст ложные строки при соединении.
Например, поставщик может работать с деталью и проектом по отдельности, но не иметь разрешения поставлять эту деталь именно в этот проект. Такой факт нельзя выразить только тремя бинарными отношениями без дополнительной модели.
Чем эта проблема отличается от нарушения второй или третьей нормальной формы?
При нарушении второй или третьей нормальной формы избыточность обычно объясняется функциональной зависимостью: атрибут определяется всем ключом, частью ключа или другим неключевым атрибутом.
В рассматриваемом случае отдельный атрибут может вообще не зависеть от другого атрибута функционально. Избыточность возникает потому, что всё отношение восстанавливается соединением нескольких проекций. Поэтому для анализа нужна зависимость соединения, а не только функциональные зависимости.
Почему нельзя считать декомпозицию корректной только потому, что соединение возвращает исходные строки на текущих данных?
Текущий набор данных может случайно не содержать комбинаций, которые станут ложными после следующей вставки. Корректность должна следовать из бизнес-правила и ограничений схемы, а не из одного снимка данных.
Нужно доказать, что допустимые попарные связи действительно независимы и что их комбинация полностью определяет допустимость тройки. Если база не способна выразить это правило одними ключами и внешними ключами, потребуется дополнительное ограничение, триггер или сохранение тройного отношения.