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

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

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

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

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

Транзитивная зависимость
Транзитивная зависимость - это косвенная функциональная зависимость, в которой 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.

Ответ 5

Я просто собрал сообщение, в котором говорится, почему транзитивные зависимости обычно представляют собой плохую идею: http://www.essentialsql.com/get-ready-to-learn-sql-11-database-third-normal-form-explained-in-simple-english/