Wciąż zdezorientowany w kwestii identyfikacji a Nieidentyfikowania relacji

Question

Wciąż zdezorientowany w kwestii identyfikacji a Nieidentyfikowania relacji

Więc, czytałem się na identyfikacji vs. nieidentyfikujących relacji w moim projekcie bazy danych, a liczba odpowiedzi na SO wydaje mi się sprzeczne. Oto dwa pytania, na które patrzę:

Patrząc na najlepsze odpowiedzi z każdego pytania, wydaje mi się, że mam dwa różne pomysły o tym, czym jest związek rozpoznawczy.

Odpowiedź na pierwsze pytanie mówi, że relacja identyfikująca " opisuje sytuację, w której istnienie wiersza w tabeli potomnej zależy od wiersza w tabeli nadrzędnej."Przykładem tego jest," autor może napisać wiele książek (relacja 1-do-n), ale książka nie może istnieć bez autora."To ma dla mnie sens.

Jednak, kiedy czytam odpowiedź na pytanie drugie, jestem zdezorientowany, jak to mówi, " jeśli dziecko identyfikuje swojego rodzica, jest to związek identyfikujący."Odpowiedź następnie podaje przykłady, takie jak Numer ubezpieczenia społecznego (jest identyfikacją osoby), ale adres nie jest (ponieważ wiele osób może mieszkać pod adresem). Dla mnie brzmi to bardziej jak przypadek decyzji między kluczem podstawowym a kluczem Nie-podstawowym.

Moje własne przeczucie (i dodatkowe badania na innych stronach) wskazuje na pierwsze pytanie i jego odpowiedź jest poprawna. Chciałem jednak zweryfikować zanim kontynuowałem, ponieważ nie chcę nauczyć się czegoś złego, ponieważ pracuję nad zrozumieniem projektowania baz danych. Z góry dzięki.

67

database database-design relational-database relationship

Author: Community, 2010-05-12

Source

7 answers

"ponieważ nie chcę nauczyć się czegoś złego".

Welll, jeśli naprawdę tak myślisz, to możesz przestać martwić się żargonem i terminologią. Jest nieprecyzyjna, zdezorientowana, myląca, w ogóle nie uzgodniona i w większości nieistotna.

ER to zbiór prostokątów i prostych linii narysowanych na kartce papieru. ER jest celowo przeznaczony do Nieformalnego modelowania. Jako taki, jest to cenny pierwszy krok w projektowaniu baz danych, ale jest to również po prostu to: pierwszy krok.

Nigdy diagram ER nie może zbliżyć się do dokładności, dokładności i kompletności projektu bazy danych formalnie zapisanego w D.

17

Author: Erwin Smout,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-11 23:25:00

Relacje identyfikujące / nieidentyfikujące są pojęciami w modelowaniu ER - relacja będąca identyfikacją, jeśli jest reprezentowana przez klucz obcy, który jest częścią klucza głównego TABELI odniesienia. Jest to zwykle bardzo małe znaczenie w modelowaniu relacyjnym, ponieważ klucze podstawowe w modelu relacyjnym i w bazach danych SQL nie mają specjalnego znaczenia ani funkcji, jak mają one miejsce w Modelu ER.

Na przykład, załóżmy, że Twoja tabela wymusza dwa klucze kandydata, A I B. Załóżmy, że A jest również kluczem obcym w tej tabeli. Tak przedstawiona relacja jest uważana za" identyfikującą", jeśli A jest oznaczony jako klucz "podstawowy", ale nie identyfikuje się, jeśli B jest kluczem podstawowym. Jednak forma, funkcja i znaczenie tabeli są identyczne w każdym przypadku! Dlatego moim zdaniem pojęcie identyfikujące / nieidentyfikujące nie jest tak naprawdę bardzo ważne.

10

Author: sqlvogel,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-11 22:13:42

Uważam, że jedyną różnicą między relacją identyfikującą i nieidentyfikującą jest nieważność klucza obcego. Jeśli FK nie może być NULL, relacja, którą reprezentuje, jest identyfikująca (dziecko nie może istnieć bez rodzica), w przeciwnym razie nie jest identyfikująca.

9

Author: Pankaj Jha,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-12-23 11:37:30

Częścią problemu jest tutaj pomieszanie terminologii. identyfikacja relacji jest przydatna do unikania długich ścieżek łączenia.

Najlepsza definicja jaką widziałem to " związek identyfikujący obejmuje PK jako rodzica w PK dziecka. Innymi słowy PK dziecka obejmuje FK rodzica, jak również "rzeczywiste" PK dziecka.

5

Author: gnackenson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-09-02 13:17:57

Tak, idź z pierwszym, ale nie sądzę, że drugi przeczy pierwszemu. To tylko sformułowanie trochę mylące..

UPDATE:

Właśnie sprawdziłem - odpowiedź na drugie pytanie jest błędna w niektórych założeniach,.. book-author niekoniecznie jest relacją 1:n, ponieważ może to być m: n. w relacyjnych bazach danych tworzy się tabelę przecięcia dla tej relacji m: n, A otrzymujemy relacje między tabelą przecięcia a pozostałymi 2 tabelami..

1

Author: marianboda,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-11 21:34:52

Identyfikacja relacji daje jeden do wielu opcjonalnych relacji, gdy musimy zdefiniować rodzic do dziecka relationship.in dodatek daje jeden do tylko jeden związek z przepływu dziecka do rodzica.ponieważ klucz podstawowy jednostki nadrzędnej będzie częścią klucza podstawowego jednostki podrzędnej, instancja jednostki podrzędnej zidentyfikuje jednostkę nadrzędną instance.it jest reprezentowany przez linię stałą na diagramie er.

Gdzie jako nieidentyfikujący związek będzie wiele do wielu relacji.Za istnienie instancja podmiotu podrzędnego powinna mieć instancję podmiotu nadrzędnego, ale każda instancja podmiotu podrzędnego może być powiązana z wieloma instancjami podmiotu nadrzędnego.jest to powód, dla którego klucz podstawowy jednostki dominującej jest również kluczem obcym jednostki potomnej, ale jednostka potomna nie przyjmie klucza podstawowego jednostki dominującej jako jej podstawowego key.it będzie miał swój własny klucz podstawowy. wiele do wielu relacji nie istnieje w rzeczywistym świecie er diagram. więc trzeba to rozwiązać

1

Author: kumar,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-12-18 00:15:05

score 141 · Accepted Answer

Techniczna definicja związku identyfikującego jest taka, że klucz obcy dziecka jest częścią klucza podstawowego.

CREATE TABLE AuthoredBook (
  author_id INT NOT NULL,
  book_id INT NOT NULL,
  PRIMARY KEY (author_id, book_id),
  FOREIGN KEY (author_id) REFERENCES Authors(author_id),
  FOREIGN KEY (book_id) REFERENCES Books(book_id)
);

Widzisz? book_id jest kluczem obcym, ale jest również jedną z kolumn w kluczu głównym. Tak więc ta tabela ma związek identyfikujący z tabelą odniesienia Books. Podobnie ma związek identyfikujący z Authors.

Komentarz do filmu na YouTube ma związek identyfikujący z danym filmem. Na video_id powinien być częścią klucz główny tabeli {[7] }.

CREATE TABLE Comments (
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  PRIMARY KEY (video_id, user_id, comment_dt),
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

Może być trudno to zrozumieć, ponieważ w dzisiejszych czasach powszechną praktyką jest używanie tylko klucza seryjnego zastępczego zamiast złożonego klucza głównego:

CREATE TABLE Comments (
  comment_id SERIAL PRIMARY KEY,
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

Może to zaciemniać przypadki, w których tabele mają związek identyfikujący.

Ja bymnie uważał SSN za reprezentację związku identyfikującego. Niektórzy ludzie istnieją, ale nie mają SSN. Inne osoby mogą złożyć wniosek, aby uzyskać nowy SSN. Więc SSN jest naprawdę tylko atrybut, nie jest częścią klucza głównego danej osoby.

Re komentarz od @ Niels:

Więc jeśli użyjemy klucza zastępczego zamiast złożonego klucza podstawowego, nie ma znaczącej różnicy między używaniem identyfikującego lub nieidentyfikującego związku ?

Chyba tak. Waham się powiedzieć tak, ponieważ nie zmieniliśmy logicznej relacji między tabelami za pomocą klucza zastępczego. Oznacza to, że nadal nie możesz zrobić komentarza bez odniesienia się do istniejące wideo. Ale to oznacza, że video_id nie musi być NULL. A aspekt logiczny jest dla mnie naprawdę sensem identyfikacji związków. Ale jest też fizyczny aspekt identyfikacji związków. I to jest fakt, że kolumna klucza obcego jest częścią klucza podstawowego (klucz podstawowy niekoniecznie jest kluczem złożonym, może to być pojedyncza kolumna, która jest zarówno kluczem głównym komentarzy, jak i kluczem obcym do tabeli filmów, ale oznaczałoby to, że może przechowywać tylko jeden komentarz na wideo).

Identyfikacja relacji wydaje się być ważna tylko ze względu na diagramowanie relacji entity-relation, co pojawia się w narzędziach do modelowania danych GUI.