После разбиения отношения функциональное ограничение стало невозможно проверить в одной таблице: какое свойство декомпозиции утрачено?
Утрачена сохранность функциональных зависимостей. Декомпозиция сохраняет зависимости, если каждую исходную функциональную зависимость можно проверить по отдельным полученным отношениям, не восстанавливая исходную таблицу соединением.
Это свойство независимо от декомпозиции без потерь: таблицы могут корректно восстанавливаться соединением, но при этом часть ограничений станет неудобно или невозможно контролировать локально.
Нормализация появилась как способ уменьшить избыточность данных и предотвратить аномалии вставки, обновления и удаления. Для этого исходное отношение разбивают на несколько отношений, но при разбиении важно не только сохранить исходные данные, но и не потерять смысловые ограничения.
Поэтому при проектировании оценивают как минимум два свойства: соединение без потерь, гарантирующее восстановление исходных фактов, и сохранность зависимостей, позволяющую проверять правила над отдельными таблицами.
Пусть в исходном отношении выполняются зависимости A → B и B → C. Это означает: значение A однозначно определяет B, а значение B однозначно определяет C.
Если отношение разбить на R1(A, B) и R2(A, C), зависимость A → B можно проверять в R1. Но зависимость B → C нельзя проверить по одной из этих таблиц: атрибуты B и C находятся в разных отношениях.
Для проверки потребуется соединять таблицы, а затем контролировать результат. Это усложняет ограничения, может ухудшить производительность и повышает риск того, что некорректные данные появятся при конкурентных изменениях.
Формально декомпозиция сохраняет множество функциональных зависимостей F, если замыкание зависимостей, проецированных на полученные отношения, логически влечёт все зависимости из F.
Практически это означает следующее: каждое правило исходной схемы должно быть выражено через атрибуты хотя бы одной полученной таблицы либо выводиться из правил, которые уже проверяются локально. Если для проверки зависимости обязательно соединять несколько таблиц, она обычно не считается сохранённой.
Сохранность зависимостей не гарантирует отсутствие ложных комбинаций при соединении. За это отвечает другое свойство — декомпозиция без потерь. И наоборот, декомпозиция без потерь может не сохранять все функциональные зависимости.
В SQL функциональные зависимости часто выражают через PRIMARY KEY, UNIQUE, FOREIGN KEY и другие ограничения. Однако наличие подходящего ограничения зависит от конкретной зависимости: не всякое бизнес-правило представимо одним стандартным ограничением таблицы.
Типичный компромисс связан с нормальными формами. Более строгая нормализация, например до BCNF, может устранить избыточность, но привести к утрате сохранности некоторых зависимостей. Схемы в третьей нормальной форме часто выбирают именно потому, что они обеспечивают декомпозицию без потерь и сохранность зависимостей, хотя не всегда достигают BCNF.
В исходной сущности заказа выполняются зависимости НомерЗаказа → Клиент и Клиент → Менеджер. Проектировщик создал таблицы Заказ(НомерЗаказа, Клиент) и Заказ(НомерЗаказа, Менеджер). Связь между клиентом и менеджером больше не проверяется в одной таблице, поэтому правило Клиент → Менеджер утрачено как локально проверяемая зависимость.
Вариант с периодическим соединением таблиц прост в реализации, но допускает временно или постоянно противоречивые данные и требует дополнительного контроля. Вариант с триггерами может проверять правило, однако усложняет сопровождение и требует аккуратного учёта конкурентных транзакций.
Более подходящее решение — выделить связь в отдельную таблицу КлиентМенеджер(Клиент, Менеджер) с ограничением уникальности по Клиенту, а в заказе хранить ссылку на клиента. Тогда зависимость Клиент → Менеджер проверяется непосредственно в одной таблице, уменьшается дублирование, а изменения назначения менеджера не требуют массового обновления заказов.
1. Означает ли сохранность функциональных зависимостей, что декомпозиция выполнена без потерь?
Нет. Это разные свойства. Сохранность зависимостей отвечает на вопрос, можно ли проверять ограничения по отдельным отношениям. Декомпозиция без потерь отвечает на вопрос, восстанавливается ли исходное отношение соединением без потери строк и появления ложных комбинаций.
2. Можно ли считать зависимость сохранённой, если её проверяет триггер после соединения таблиц?
В строгом смысле реляционной декомпозиции — обычно нет: зависимость не следует из ограничений отдельных отношений и требует внешнего механизма. Триггер может обеспечить требуемое бизнес-поведение в конкретной СУБД, но это уже процедурная реализация контроля, а не сохранность зависимости самой схемой.
3. Всегда ли следует предпочитать декомпозицию, сохраняющую больше зависимостей?
Нет. Нужно одновременно учитывать отсутствие избыточности, декомпозицию без потерь, стоимость запросов и удобство ограничений. Иногда сохранение зависимости требует оставить контролируемую избыточность или отказаться от более строгой нормальной формы, если это даёт существенные практические преимущества.