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

Ответ 1

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

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

Ответ 2

Верьте или нет, дублирование столбцов по таблицам само по себе не нарушает теоретической нормальной формы. За исключением нормальной формы домена/ключа (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) также должны существовать в rn (где" r" - таблица). Что наиболее важно для рассматриваемого вопроса, многозначная зависимость применяется только к одной таблице.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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