В отношении ключом является идентификатор заказа, а город доставки однозначно определяет тариф: какое условие показывает нарушение третьей нормальной формы?
Нарушение третьей нормальной формы показывает нетривиальная функциональная зависимость город доставки → тариф, если город не является суперключом, а тариф не входит ни в один кандидатный ключ. В данном случае возникает транзитивная зависимость: идентификатор заказа → город доставки → тариф.
Нормализация реляционных данных появилась как способ уменьшить избыточность и предотвратить аномалии вставки, обновления и удаления. Третья нормальная форма стала практическим компромиссом: она устраняет зависимости неключевых атрибутов от других неключевых атрибутов, но обычно не требует настолько сильной декомпозиции, как более строгая форма Бойса—Кодда.
Если хранить тариф вместе с каждым заказом, один и тот же тариф будет повторяться во множестве строк. При изменении тарифа часть заказов может остаться со старым значением, а удаление последнего заказа города способно удалить единственную информацию о его тарифе.
Проблема определяется не самим повторением значений, а функциональными зависимостями. Если значение города однозначно определяет тариф, то тариф логически зависит не от заказа, а от города.
Формальное условие третьей нормальной формы таково: для каждой нетривиальной функциональной зависимости X → A должно выполняться хотя бы одно из условий — X является суперключом либо A является ключевым атрибутом, то есть входит в некоторый кандидатный ключ.
В рассматриваемом отношении идентификатор заказа — ключ, поэтому он определяет город. Но город сам по себе не идентифицирует заказ, то есть не является суперключом. Тариф также не является частью ключа. Поэтому зависимость город → тариф нарушает третью нормальную форму.
Обычно отношение декомпозируют на два: сведения о заказе хранят с идентификатором заказа и городом, а соответствие города тарифу — отдельно. Тогда тариф изменяется в одном месте, а соединение по городу восстанавливает нужную информацию.
Такое разбиение должно быть проверено на соединение без потерь и, по возможности, на сохранение функциональных зависимостей. Более высокая нормальная форма может устранить дополнительные аномалии, но иногда приводит к большему числу таблиц и более сложным запросам.
В системе доставки в таблице заказов хранились идентификатор заказа, город и тариф. После изменения тарифа для города часть новых заказов получала новое значение, а старые строки сохраняли прежнее.
Рассматривались два варианта. Можно было оставить данные в одной таблице и поддерживать согласованность триггерами или прикладным кодом, но это увеличивало число точек отказа. Можно было вынести тарифы в отдельное отношение с городом в роли ключа; этот вариант добавлял соединение, зато устранял дублирование и делал правило однозначным на уровне структуры данных.
Был выбран второй вариант. В результате изменение тарифа стало одной операцией, а заказы перестали содержать независимые копии одного и того же справочного значения.
Нет. Повторение само по себе не доказывает нарушение. Нужно установить функциональную зависимость и проверить роли атрибутов: определяющий набор не должен быть суперключом, а зависимый атрибут — ключевым. Повторяющиеся значения могут быть полностью допустимы, например при связи «один ко многим», где один идентификатор родителя встречается в нескольких дочерних строках.
Вторая нормальная форма запрещает зависимость неключевого атрибута от части составного кандидатного ключа. Третья нормальная форма дополнительно устраняет зависимости неключевых атрибутов от других неключевых атрибутов.
Если ключ заказа составной и тариф зависит только от одного его компонента, это пример нарушения второй формы. В рассматриваемом случае ключ простой, а тариф зависит через город, поэтому основной признак — транзитивная зависимость и нарушение третьей формы.
Нет. Третья нормальная форма не гарантирует устранение всех избыточностей, если существуют более сложные зависимости или несколько независимых составных фактов. В частности, отношение может соответствовать третьей нормальной форме, но нарушать форму Бойса—Кодда.
Кроме того, декомпозиция должна сохранять корректность соединения и не создавать ложные комбинации строк. Поэтому нормализацию проверяют не только по названию нормальной формы, но и по функциональным зависимостям, ограничениям целостности и фактическим сценариям запросов.