Верьте или нет, дублирование столбцов в таблицах само по себе не нарушает теоретически нормальную форму. За исключением нормальной формы домена / ключа (DKNF), нормальные формы определяются в виде отдельных, а не множественных таблиц. DKNF определяется в терминах ограничений, которых в общем случае нет. Таким образом, если есть нарушение нормальной формы:
- оно должно быть определенным для одной из таблиц и существует независимо от наличия обеих таблиц (то есть таблица будет по-прежнему нарушать нормальную форму, даже если вы удалили другую таблицу), или
- отношение имеет ограничение, которое нарушает DKNF, что означает, что это не пример общего случая, изложенного в вопросе, а более конкретный случай. Нарушение создает не повторяющиеся столбцы, а дополнительное ограничение на дополнительный столбец.
Рассмотрим нормальные формы , используя краткие определения из статьи в Википедии:
- 1NF
-
Таблица достоверно представляет отношение и не имеет повторяющихся групп.
Это довольно прямо. Термин «повторяющиеся группы» имеет несколько значений в теории, но ни одно из них не имеет ничего общего с дублирующимися столбцами или данными.
- 2НФ
-
Никакой непростой атрибут в таблице функционально не зависит от правильного подмножества любого ключа-кандидата.
Здесь важным термином для изучения является «функциональная зависимость». По сути, функциональная зависимость - это то, где вы проецируете отношение к двум столбцам, X и Y, и получаете функцию X & rarr; Y. У вас не может быть функциональной зависимости между двумя (или более) таблицами *. Кроме того, ключи-кандидаты не могут занимать несколько таблиц.
- 3NF
-
Каждый непростой атрибут не транзитивно зависит от каждого ключа-кандидата в таблице.
Транзитивная зависимость определяется в терминах функциональной зависимости: транзитивная зависимость - это зависимость, где X & rarr; Z только потому, что X & rarr; Y и Y & rarr; Z. X, Y и Z должны быть в одной таблице, потому что это функциональные зависимости.
- 4НФ
-
Каждая нетривиальная многозначная зависимость в таблице является зависимостью от суперключа.
Многозначная зависимость немного сложнее, но ее можно проиллюстрировать на примере: «всякий раз, когда кортежи (a, b, c) и (a, d, e) существуют в r, кортежи (a, b, e) и (a, d, c) также должны существовать в r "(где" r "- таблица). Что наиболее важно для рассматриваемого вопроса, многозначная зависимость применяется только к одной таблице.
- 5NF
-
Каждая нетривиальная зависимость соединения в таблице подразумевается суперключами таблицы.
Таблица имеет зависимость соединения , если она может быть выражена как естественное соединение других таблиц. Эти другие таблицы, однако, не должны существовать в базе данных. Если таблица T 11 в этом примере имеет зависимость соединения, она все равно будет иметь ее, даже если вы удалили таблицу T 10
- 6NF (C. Дата)
-
В таблице вообще нет нетривиальных зависимостей соединения (со ссылкой на оператор обобщенного соединения).
Те же рассуждения для 5NF.
- Элементарный ключ Нормальная форма (EKNF)
-
Каждая нетривиальная функциональная зависимость в таблице является либо зависимостью атрибута элементарного ключа, либо зависимостью от суперключа.
То же самое для 2NF.
- Нормальная форма Бойса-Кодда (BCNF)
-
Каждая нетривиальная функциональная зависимость в таблице - это зависимость от суперключа.
То же самое для 2NF.
- Нормальная форма домена / ключа (DKNF)
Каждое ограничение таблицы является логическим следствием ограничений таблицы и ключей таблицы.
Если T 11 имеет ограничение, которое зависит от T 10 , то это либо ключевое ограничение, либо более сложное ограничение, которое все еще ссылается на T 10, Последний случай не является общим случаем, упомянутым в вопросе. Другими словами, хотя могут быть определенные схемы с дублирующимися столбцами, которые нарушают DKNF, в целом это не так. Кроме того, именно ограничение (не нормальная форма) определяется в терминах нескольких таблиц, а ограничение (не дублирование столбца) вызывает нарушение DKNF.
<Ч />
Цель нормализации включает предотвращение аномалий. Однако нормализация не завершена, поскольку она не гарантирует, что реляционная база данных будет полностью свободна от аномалий. Это один случай, когда практика расходится с теорией.
Если это по-прежнему вас не убеждает, рассмотрите подсказку к комментарию схемы KM., Где T 11 представляет историческую (или версионную) версию T 10 . Первичный ключ T 11 состоит из столбцов первичного ключа, которые хранятся вместе с T 10 , плюс дополнительный столбец (столбец даты / версии). То, что T 11 имеет разные ключи-кандидаты, делает различие между склонной к аномалиям и свободной от аномалий нормализованной конструкцией.
* Кто-то может подумать, что вы можете использовать объединения для создания зависимости между двумя таблицами. В то время как объединение может создать таблицу с зависимостью, зависимость существует для этой таблицы, а не между компонентами объединения. В данном случае это снова означает, что одна из таблиц будет объединенной таблицей и будет зависеть от самой зависимости независимо от другой таблицы в базе данных.