Co jest nie tak z zależnością przechodnią?

Jednym ze sposobów wyrażenia 3NF jest:

Wszystkie atrybuty powinny zależeć od klucza, całego klucza i nic poza kluczem.

Zależność przechodnia X - > Y - > Z narusza tę zasadę, prowadząc do redundancji danych i potencjalnych anomalii modyfikacji.

Wyjaśnijmy to sobie:

1. z definicji, dla funkcjonalnej zależności X->Y->Z, aby również być transitive, Xnie trzymać.
2. If y was klucz, X(PRZYPIS1)
3. ponieważ Y nie jest kluczem, każdy dany Y może być powtórzony w wielu wierszach.
4. Y - > Z oznacza, że wszystkie wiersze posiadające to samo Y muszą również posiadać to samo Z. (PRZYPIS2)
5. powtarzanie krotki tej samej krotki (Y, Z) w kilku wierszach nie wnosi żadnych użytecznych informacji do systemu. Jest to zbędne .

W skrócie, ponieważ Y nie jest kluczem, A Y - > Z, mamy naruszył 3NF.

Redundancje prowadzą do anomalii modyfikacji (np. aktualizacja niektórych , ale nie wszystkich Zs "podłączonych" do tego samego Y zasadniczo psuje dane, ponieważ nie wiesz już, która kopia jest poprawna). Jest to zazwyczaj rozwiązywane przez podział oryginalnej tabeli na dwie tabele, jedna zawierająca {X, Y} i druga zawierająca {Y, Z}, W ten sposób, Y może być kluczem w drugiej tabeli, a Z nie jest powtarzany.

Z drugiej strony, jeśli X Y - > Z nie jest przechodni), wtedy możemy zachować jedną tabelę, gdzie zarówno X jak i Y są kluczami. Z nie będzie niepotrzebnie powtarzany w tym scenariuszu.

(PRZYPIS1) klucz jest (minimalnym) zestawem atrybutów, które funkcjonalnie określają wszystkie atrybuty w relacji. Uzasadnienie: jeśli K jest kluczem, nie może być wiele wierszy o tej samej wartości K, więc każda dana wartość K jest zawsze powiązana z dokładnie jedną wartością każdego innego atrybutu (zakładając 1NF). Z definicji (patrz PRZYPIS2), "bycie kojarzonym z jednym" to to samo, co "bycie w zależności funkcjonalnej".

(Przypisy 2) Z definicji , Y - > Z wtedy i tylko wtedy, gdy każda wartość Y jest związana dokładnie z jedną wartością Z.

Przykład:

Zakładając, że każda wiadomość ma dokładnie jednego autora i każdy autor ma dokładnie jeden główny e-mail, próba reprezentowania wiadomości i użytkowników w tej samej tabeli prowadziłaby do powtórzenia e-maile:

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

(w rzeczywistości byłyby to MESSAGE_IDs, ale zachowajmy tutaj prostotę.)

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

...i nie wiemy już, który z e-maili Jona jest poprawny. W zasadzie straciliśmy dane!

Sytuacja jest szczególnie zła, ponieważ tam nie jest ograniczeniem deklaratywnym, którego moglibyśmy użyć, aby zmusić DBMS do wymuszenia obu aktualizacji dla nas. Kod klienta będzie miał błędy i prawdopodobnie został napisany bez większego uwzględnienia złożonych interakcji, które mogą się zdarzyć w środowisku współbieżnym.

Jednakże, jeśli podzielisz stół...

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

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

...jest teraz tylko jeden wiersz, który wie o e-mailu Jona, więc dwuznaczność jest niemożliwa.

BTW, wszystko to można postrzegać jako kolejne wyrażenie suchego zasada .

Jeśli w Twojej tabeli istnieją zależności przechodnie, to nie jest ona zgodna z 3NF; więc istnieje duże prawdopodobieństwo, że w Twojej tabeli znajdują się nadmiarowe dane. Sprawdź to , aby wyjaśnić tę koncepcję.

Spójrz na ten link:

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

Na przykładzie, co by się stało, gdybym zaktualizował narodowość Juliusza Verne ' a w jednym rzędzie, a nie w drugim? Narodowość autora określa sam autor, a nie kombinacja książki i autora. Więc z przykładową strukturą danych, mógłbym potencjalnie zapytać bazę danych o narodowość Juliusza Verne ' a. Jeśli uruchomiłem następujące polecenie SQL

WYBIERZ TOP 1 autor_nationality z książek WHERE author= 'Jules Verne'

Mogę uzyskać inną odpowiedź w zależności od tego, jak Baza Danych wybiera TOP 1.

Właśnie stworzyłem post, w którym wyjaśniam, dlaczego zależności przechodnie są ogólnie złym pomysłem: http://www.essentialsql.com/get-ready-to-learn-sql-11-database-third-normal-form-explained-in-simple-english/