Какое правило нормализации это нарушает?

Верьте или нет, дублирование столбцов через таблицы не нарушает никакой теоретической нормальной формы само по себе. За исключением нормальной формы домена/ключа (DKNF), нормальные формы определяются в терминах отдельных, а не нескольких таблиц. DKNF определяется в терминах ограничений, которых нет в общем случае. Таким образом, если есть нарушение нормальной формы:

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

рассмотрим нормальных форм, используя краткие определения из Википедии статья:

таблица точно представляет отношение и не имеет повторяющихся групп.

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

ни один атрибут non-prime в таблице функционально не зависит от правильного подмножества любого ключа-кандидата.

здесь важным термином для изучения является "функциональная зависимость". По сути, функциональная зависимость - это когда вы проецируете отношение к двум столбцам X и Y и заканчиваете функцией X → Y. вы не можете иметь функциональную зависимость между двумя (или более) таблицами^*. Кроме того, ключи-кандидаты не могут охватывать несколько таблиц.

каждый атрибут non-prime непереходно зависит от каждого ключа-кандидата в таблица.

Транзитивная зависимость определяется в терминах функциональной зависимости: транзитивная зависимость-это зависимость, где X → Z только потому, что X → Y и Y → Z. X, Y и Z должны быть в одной таблице, потому что это функциональные зависимости.

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

многозначных зависимостей немного сложнее, но это может быть иллюстрируется примером:" всякий раз,когда кортежи (a,b,c) и (a,d, e) существуют в r,кортежи (a,b,e) и (a,d, c) также должны существовать в r "(где" r " - таблица). Самое главное, что многозначная зависимость применима только к одной таблице.

в каждой нетривиальной присоединиться зависимостей в таблице подразумевается superkeys таблицы.

в таблице присоединиться к зависимости если его можно выразить как естественное соединение таблиц. Однако эти другие таблицы не обязательно должны существовать в базе данных. Если таблица T₁₁ в Примере была зависимость соединения, она все равно будет иметь одну, даже если вы удалили таблицу T₁₀

таблица не имеет нетривиальных зависимостей соединения вообще (со ссылкой на обобщенный оператор соединения).

то же самое рассуждение для 5NF.

каждая нетривиальная функциональная зависимость в таблице является либо зависимостью атрибута элементарного ключа, либо зависимостью от суперклея.

то же самое рассуждение для 2NF.

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

то же самое рассуждение для 2NF.

каждое ограничение в таблице является логическим следствием ограничений домена таблицы и ключевых ограничений.

Если T₁₁ имеет ограничение, которое зависит от T₁₀, то это либо ключевое ограничение, либо более сложное ограничение, которое все еще относится к T₁₀. Последний случай не является общим случаем, упомянутым в вопросе. Другими словами, хотя могут быть определенные схемы с повторяющимися столбцами, которые нарушают DKNF, это в общем, неправда. Кроме того, это ограничение (а не обычная форма), которое определено с точки зрения нескольких таблиц и ограничения (а не дублирования столбцов), которое вызывает нарушение DKNF.

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

Если этот все еще не убеждает вас, рассмотрим схему KM.'s комментарий намекает на, где T₁₁ представляет собой историю (или версионную) версию T₁₀. Первичный ключ T₁₁ состоит из столбцов первичного ключа, общих с T₁₀ плюс дополнительный столбец (столбец дата/версия). Это Т₁₁ имеет различные ключи-кандидаты делает всю разницу между аномалией и аномалией свободной, нормализованной дизайн.

^*кто-то может подумать, что вы можете использовать соединения для создания зависимости между двумя таблицами. Хотя соединение может создать таблицу с зависимостью, зависимость существует в этой таблице, а не между компонентами соединения. В рассматриваемом случае это опять же означает, что одна из таблиц будет объединенной таблицей и будет страдать от самой зависимости, независимо от другой таблицы в базе данных.

возможно, правило избежания избыточных данных? (то есть же данные в двух таблицах)

Если 10 из 11 столбцов одинаковы, почему это не может быть только одна таблица, где 11-й столбец остается пустым (вместе с возможным 12-м столбцом для обозначения того, какой тип данных он есть, т. е. в какой таблице он был бы изначально)?

Это зависит от того, что в таблицах.

Если никакие записи не связаны друг с другом (например, если одна таблица просто заархивирована, но удалена из первой таблицы), вы не нарушаете никаких правил.

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

наличие двух идентичных или почти идентичных отношений само по себе не является нарушением какой-либо из обычных нормальных форм. Outis очень доступно объяснил почему. Это вполне может быть нарушением принцип ортогонального проектирования однако, что является еще одним аспектом теории проектирования реляционных баз данных.

Если все 10 столбцов являются частью вашего ключа, то вторая нормальная форма: устранение избыточных данных. В частности, это подпадает под дилемму "Несуррогат против суррогатных первичных ключей" - честно говоря, я не помню ни одного из этих двух вариантов "нарушения" 2NF, но суррогатный ключ определенно ближе к духу 2NF

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