Что не так с транзитивной зависимостью?

У меня есть некоторые транзитивные зависимости в моей конструкции базы данных. Я сказал начальству, что это может вызвать ошибки. Мне трудно найти ресурсы, которые расскажут мне, как эти зависимости будут вызывать ошибки. Какие проблемы они вызовут?

Я не оспариваю этот факт, просто хочу узнать, какие проблемы они могут вызвать.

Изменить для более подробной информации:

Из Википедии:

Транзитивная зависимость
Транзитивная зависимость - это косвенная функциональная зависимость, в которой X → Z только в силу X → Y и Y → Z.

Ответы

Ответ 1

Я объясню на примере:

-------------------------------------------------------------------
|  Course  |    Field     |   Instructor   |  Instructor Phone    |
-------------------------------------------------------------------
|  English |  Languages   |  John Doe      |     0123456789       |
|  French  |  Languages   |  John Doe      |     0123456789       |
|  Drawing |  Art         |  Alan Smith    |     9856321158       |
|  PHP     |  Programming |  Camella Ford  |     2225558887       |
|  C++     |  Programming |  Camella Ford  |     2225558887       |
-------------------------------------------------------------------
  • Если у вас есть Course, вы можете легко получить его Instructor так Course ->Instructor.
  • Если у вас есть Instructor, вы не можете получить его Course, поскольку он может преподавать разные курсы.
  • Если у вас есть Instructor, вы можете легко получить его Phone так Instructor->Phone.

Это означает, что если у вас есть Course, тогда вы можете получить Instructor Phone, что означает Course ->Instructor Phone (т.е. транзитивная зависимость)

Теперь для проблем:

  • Если вы удалите курсы French и English, вы также удалите своего инструктора John Doe, и его номер телефона будет потерян навсегда.
  • Невозможно добавить новую Instructor в вашу базу данных, если вы сначала не добавите Course, или вы можете дублировать данные в Instructors table, что еще хуже.
  • Если Instructor John Doe изменяет свой номер телефона, вам необходимо будет обновить все Курсы, которые он преподает с новой информацией, которая может быть очень подвержена ошибкам.
  • Вы не можете удалить инструктора из своей базы данных, если вы не удалите все курсы, которые он преподает, или установите все его поля в null.
  • Что делать, если вы решите сохранить дату рождения своих инструкторов? Вам нужно будет добавить поле Birth Date в таблицу Courses. Это даже звучит логично? Зачем хранить информацию инструктора в таблице курсов в первую очередь.

Ответ 2

Один из способов выразить 3NF:

Все атрибуты должны зависеть от ключа, всего ключа и всего лишь ключа.

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

Давайте сломаем это:

  • По определению для функциональной зависимости X- > Y- > Z также быть транзитивным, X < -Y должен не.
  • Если Y является ключом, X < -Y будет содержать, поэтому Y не может быть ключом. (Сноска1)
  • Так как Y не является ключом, любой заданный Y может быть повторен в нескольких строках.
  • Y- > Z означает, что все строки, содержащие один и тот же Y, также должны содержать тот же Z. (FOOTNOTE2)
  • Повторение одного и того же (Y, Z) кортежа в нескольких строках не вносит никакой полезной информации в систему. Это избыточно.

Короче говоря, поскольку Y не является ключом и Y- > Z, мы нарушили 3NF.

Избытки приводят к аномалиям модификации (например, обновление некоторых, но не всех Zs, "связанных" с тем же Y, по сути, искажает данные, поскольку вы уже не знаете, какая копия правильная). Обычно это разрешается путем разбиения исходной таблицы на две таблицы: одну, содержащую {X, Y} и другую другую, содержащую {Y, Z}. Таким образом, Y может быть ключом во второй таблице, а Z не повторяется.

С другой стороны, если X < -Y действительно имеет место (т.е. X- > Y- > Z не является транзитивным), то мы можем сохранить одну таблицу, где оба X и Y являются ключами. Z не будет излишне повторяться в этом сценарии.

(FOOTNOTE1) Ключ - это (минимальный) набор атрибутов, которые функционально определяют все атрибуты в отношении. Обоснование. Если K является ключом, не может быть нескольких строк с одинаковым значением K, поэтому любое заданное значение K всегда связано с одним значением любого другого атрибута (при условии 1NF). По определению (см. FOOTNOTE2), "быть связанным с одним" - это то же самое, что "быть в функциональной зависимости".

(FOOTNOTE2) По определению, Y- > Z, если и только если каждое значение Y связано с одним значением Z.

Пример:

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

MESSAGE                         USER    EMAIL
-------                         ----    -----
Hello.                          Jon     [email protected]
Hi, how are you?                Rob     [email protected]
Doing fine, thanks for asking.  Jon     [email protected]

(На самом деле это были бы MESSAGE_ID s, но давайте здесь все упростим.)

Теперь, что произойдет, если Джон решит изменить свое электронное письмо, скажем, "[email protected]"? Нам нужно будет обновить и строк Jon. Если мы обновляем только один, тогда мы имеем следующую ситуацию...

MESSAGE                         USER    EMAIL
-------                         ----    -----
Hello.                          Jon     [email protected]
Hi, how are you?                Rob     [email protected]
Doing fine, thanks for asking.  Jon     [email protected]

... и мы больше не знаем, какой из почтовых сообщений Jon правильный. Мы по существу потеряли данные!

Ситуация особенно плохая, поскольку не существует декларативного ограничения, которое мы могли бы использовать для принуждения СУБД к обеспечению выполнения обоих обновлений для нас. Клиентский код будет иметь ошибки и, вероятно, написан без особого учета сложных взаимодействий, которые могут произойти в параллельной среде.

Однако, если вы разделите таблицу...

MESSAGE                         USER
-------                         ----
Hello.                          Jon 
Hi, how are you?                Rob 
Doing fine, thanks for asking.  Jon 

USER    EMAIL
----    -----
Jon     [email protected]
Rob     [email protected]

... теперь есть только одна строка, которая знает о почте Джона, поэтому двусмысленность невозможна.

Кстати, все это можно рассматривать как просто другое выражение принципа DRY.

Ответ 3

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

Ответ 4

Взгляните на эту ссылку:

http://en.wikipedia.org/wiki/Transitive_dependency

Используя пример, что произойдет, если я уточню национальность Жюля Верна на одном ряду, но не на другом? Гражданство автора определяется только автором, а не комбинацией книги и автора. Таким образом, с примером структуры данных, я мог бы потенциально спросить базу данных о гражданстве Жюля Верна. Если я выполнил следующую команду SQL

SELECT TOP 1 author_nationality Из книг ГДЕ автор = 'Жюль Верн'

Я мог бы получить другой ответ в зависимости от того, как база данных выбирает TOP 1.