Jaka jest różnica między identyfikacją a nieidentyfikacją relacji?

Jest inne wyjaśnienie ze świata realnego:

Książka należy do właściciela, a właściciel może posiadać wiele książek. Ale książka może istnieć również bez właściciela, a jej własność może się zmieniać z jednego właściciela na drugiego. Relacja między książką a właścicielem jest relacją nieidentyfikującą.

Książka jest jednak napisana przez autora, a autor mógł napisać wiele książek. Ale książka musi być napisana przez autora - nie może istnieć bez autor. Dlatego relacja między książką a autorem jest relacją identyfikującą.

ODPOWIEDŹ Billa jest poprawna, ale to jest szokujące widzieć że wśród wszystkich innych odpowiedzi nikt nie wskazuje na najważniejszy aspekt.

W kółko mówi się, że w związku identyfikującym dziecko nie może istnieć bez rodzica. (np. user287724). To prawda, ale zupełnie nie trafia w sedno. Aby to osiągnąć, wystarczy, aby klucz obcy był non-null. Nie musi być częścią podstawowej klucz.

Oto prawdziwy powód:

Celem identyfikacji relacji jest to, że klucz obcy nigdy nie może się zmienić , ponieważ jest częścią klucza głównego... dlatego Identyfikacja!!!

Relacja identyfikująca określa, że obiekt potomny nie może exist without the parent object

Nieidentyfikujące związki określają regularny związek pomiędzy obiektami, 1:1 lub 1: n.

Nieidentyfikujące relacje można określić jako opcjonalne, gdy rodzic nie jest wymagane lub obowiązkowe, jeżeli rodzic jest wymagany przez ustawienie karta rodzica...

Oto dobry opis:

Relacje między dwoma podmiotami mogą być klasyfikowane jako "identyfikujące"lub " nieidentyfikujące". Identyfikowanie relacji istnieje, gdy klucz podstawowy jednostki dominującej jest zawarty w kluczu podstawowym jednostki potomnej. Z drugiej strony, relacja nieidentyfikująca istnieje, gdy klucz podstawowy jednostki dominującej jest zawarty w jednostce potomnej, ale nie jako część klucza podstawowego jednostki potomnej. Ponadto nie identyfikujące relacje mogą być dalej klasyfikowane jako "obowiązkowe" lub "nieobowiązkowe". Obowiązkowa nieidentyfikująca relacja istnieje, gdy wartość w tabeli podrzędnej nie może być null. Z drugiej strony, nieobowiązkowa nieidentyfikująca relacja istnieje, gdy wartość w tabeli potomnej może być null.

Http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

Oto prosty przykład identyfikacji relacji:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

Oto odpowiedni związek nieidentyfikujący: {]}

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name

W odpowiedzi User287724 podano następujący przykład relacji książki i autora:

[27]}książka jest jednak napisana przez autora, a autor mógł napisać wiele książek. Ale książka musi być napisana przez autora nie może istnieć bez autora. Dlatego relacja między książką a autorem jest relacją identyfikującą.

Jest to bardzo mylący przykład i zdecydowanie nie jest prawidłowym przykładem dla identifying relationship.

Tak, book nie można zapisać bez przynajmniej jednego author, ale author (to klucz obcy) book jest nie identyfikując {2]} w books tabeli!

Możesz usunąć author (FK) z wiersza book i nadal możesz zidentyfikować wiersz księgi za pomocą innego pola (ISBN, ID, ...etc), ale nie autor książki!!

Myślę, że ważnym przykładem an identifying relationship byłaby relacja między (tabela produktów) i a (specyficzna tabela szczegółów produktu) 1:1

products table
+------+---------------+-------+--------+
|id(PK)|Name           |type   |amount  |
+------+---------------+-------+--------+
|0     |hp-laser-510   |printer|1000    |
+------+---------------+-------+--------+
|1     |viewsonic-10   |screen |900     |
+------+---------------+-------+--------+
|2     |canon-laser-100|printer|200     |
+------+---------------+-------+--------+

printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color    |papers|
+--------------+------------+---------+---------+------+
|0             |hp          |CE210    |BLACK    |300   |
+--------------+------------+---------+---------+------+
|2             |canon       |MKJ5     |COLOR    |900   |
+--------------+------------+---------+---------+------+
* please note this is not real data

W tym przykładzie Product_ID w tabeli printers_details jest uważany za FK odwołuje się do tabeli products.id, a również do PK w tabeli printers_details, jest to relacja identyfikująca, ponieważ Product_ID(FK) w tabeli drukarek identyfikuje wiersz wewnątrz tabeli potomnej, nie możemy usunąć product_id z tabeli potomnej, ponieważ nie możemy zidentyfikować wiersz już nie, bo zgubiliśmy klucz główny

Jeśli chcesz umieścić go w 2 linie:

Związek rozpoznawczy to związek, gdy FK w tabela potomna jest uważana za PK (lub identyfikator) w tabeli potomnej, podczas gdy nadal odwołuje się do tabeli nadrzędnej

Na przykład, jeśli w bazie danych krajów znajdują się 3 tabele (import - products - countries), import i eksport dla niektórych krajów (import-products-countries).]}

Tabela import jest potomkiem, który ma te pola (product_id (FK), country_id (FK), wielkość importu , price , the units imported, the way of transport(air, sea)) we may use the ( product_id , the country_id`) aby zidentyfikować każdy wiersz importu "if they all in the same year" tutaj obie kolumny mogą tworzyć razem klucz główny w tabeli potomnej (import), a także odwoływać się do tabel nadrzędnych.

Nieidentyfikujący związek

PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

Relacja między kontem a osobą jest nieidentyfikująca.

Identyfikacja relacji

Związek identyfikujący oznacza, że rodzic jest potrzebny do nadania tożsamości dziecku. Dziecko istnieje wyłącznie dzięki rodzicowi.

Oznacza to, że klucz obcy jest kluczem podstawowym też.

ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

Relacja między ITEM_LANG i ITEM jest identyfikująca. I między ITEM_LANG i język też.

Jeśli uważasz, że element potomny powinien zostać usunięty po usunięciu rodzica, to jest to relacja identyfikująca.

Jeśli element potomny ma być zachowany mimo usunięcia rodzica, to jest to nieidentyfikujący relatio.

Jako przykład mam bazę szkoleń z stażystami, szkoleniami, dyplomami i sesjami treningowymi:

• stażyści mają identyczny związek z sesjami treningowymi
• treningi mają związek z sesjami treningowymi
• ale stażyści mają nieidentyfikujący związek z dyplomami

Tylko sesje szkoleniowe powinny zostać usunięte, jeśli jeden z powiązanych stażystów, szkoleń lub Dyplomu został usunięty.

Identyfikacja oznacza, że podmiot potomny jest całkowicie zależny od istnienia podmiotu macierzystego. Przykładowa tabela konta person table i personaccount.Tabela kont osobistych jest identyfikowana tylko przez istnienie konta i tabeli osobowej.

Relacja nieidentyfikująca oznacza, że tabela potomna nie jest identyfikowana przez istnienie tabeli nadrzędnej przykład istnieje tabela jako accounttype i account.tabela typu accounttype nie jest utożsamiana z istnieniem konta stolik.

Dobry przykład pochodzi z przetwarzania zamówień. Zamówienie od klienta zazwyczaj zawiera numer zamówienia, który identyfikuje zamówienie, niektóre dane, które występują raz na zamówienie, takie jak data zamówienia i identyfikator klienta, oraz serię pozycji liniowych. Każda pozycja zawiera numer pozycji, który identyfikuje pozycję w zamówieniu, zamówiony produkt, ilość tego produktu, cenę produktu i kwotę dla pozycji w zamówieniu, które można obliczyć przez pomnożenie ilości przez price.

Liczba identyfikująca element wiersza identyfikuje go tylko w kontekście pojedynczego zamówienia. Pierwszą pozycją w każdym zamówieniu jest pozycja numer "1". Kompletną tożsamością pozycji liniowej jest numer pozycji wraz z numerem porządkowym, którego jest częścią.

Relacja nadrzędna między zleceniami a pozycjami liniowymi jest więc relacją identyfikującą. Blisko spokrewnione pojęcie w modelowaniu ER nosi nazwę "subentyty", gdzie element liniowy jest subentytą spokój. Zazwyczaj podtytuł ma obowiązkową relację identyfikującą dziecko-rodzic z podmiotem, któremu jest podporządkowany.

W klasycznym projektowaniu bazy danych kluczem podstawowym tabeli LineItems będzie (OrderNumber, ItemNumber). Niektórzy dzisiejsi projektanci nadaliby elementowi osobny identyfikator ItemID, który służy jako klucz podstawowy i jest autoincrementowany przez DBMS. Polecam w tym przypadku klasyczny design.

Jak dobrze wyjaśniono w poniższym linku, relacja identyfikująca jest nieco podobna do słabej relacji typu entity do swojego rodzica w modelu koncepcyjnym ER. Cady w stylu UML do modelowania danych nie używają symboli lub pojęć ER, a Rodzaj relacji to: identyfikujący, nieidentyfikujący i niespecyficzny.

Identyfikujące są relacjami rodzic/dziecko, gdzie dziecko jest rodzajem słabego bytu (nawet w tradycyjnym Modelu ER nazywa się to relacją identyfikującą), która nie ma rzeczywistego klucz podstawowy według własnych atrybutów i dlatego nie może być identyfikowany jednoznacznie przez własne. Każdy dostęp do tabeli Potomków, w modelu fizycznym, będzie zależny (w tym semantycznie) od klucza głównego rodzica, który zamienia się w część lub całość klucza podstawowego dziecka (również będącego kluczem obcym), co na ogół skutkuje kluczem złożonym po stronie potomka. Ewentualne istniejące klucze samego dziecka są tylko pseudo lub częściowymi kluczami, nie wystarczającymi do zidentyfikowania jakiegokolwiek wystąpienia tego typu Entity lub Entity Set, bez PK rodzica.

Nieidentyfikująca relacja to zwykłe relacje (częściowe lub całkowite), całkowicie niezależnych zestawów jednostek, których instancje nie zależą od kluczy podstawowych innych, aby być jednoznacznie zidentyfikowane, chociaż mogą potrzebować kluczy obcych dla częściowych lub całkowitych relacji, ale nie jako klucz podstawowy dziecka. Dziecko ma swój własny klucz podstawowy. Idem rodzica. Oba niezależnie. W zależności od rodzaju związku, PK jednego przechodzi jako FK do drugiego (N strony), a jeśli częściowe, może być null, jeśli całkowite, nie może być null. Ale w takim związku FK nigdy nie będzie również PK dziecka, jak w przypadku związku identyfikującego.

Http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships

Czy atrybuty migrowane z rodzica do pomocy dla dzieci identyfikują¹ Dziecko?

• Jeśli tak : zależność identyfikacyjna istnieje, związek identyfikuje się, a podmiot potomny jest "słaby".
• Jeśli nie : zależność identyfikacyjna nie istnieje, związek jest nieidentyfikujący, a podmiot potomny "silny".

Zauważ, że identyfikacja-zależność oznacza istnienie-zależność, ale nie odwrotnie. Każdy non-NULL FK oznacza, że dziecko nie może istnieć bez rodzica, ale to samo nie powoduje identyfikacji związku.

Aby dowiedzieć się więcej na ten temat (i kilka przykładów), zajrzyj do sekcji "identyfikowanie relacji" w ERwin Methods Guide.

P. S. zdaję sobie sprawę ,że jestem (bardzo) spóźniony na imprezę, ale czuję, że inne odpowiedzi są albo nie do końca dokładne (definiując je w kategoriach istnienia-zależności zamiast identyfikacji-zależności), albo nieco meandrujące. Mam nadzieję, że ta odpowiedź zapewnia większą jasność...

¹ FK dziecka jest częścią klucza podstawowego dziecka lub (non-NULL) unikalnego ograniczenia.

Uzupełnienie ODPOWIEDŹ Daniela Dinnyesa :

W przypadku nieidentyfikującej relacji nie można mieć dwukrotnie tej samej kolumny klucza głównego (powiedzmy "ID") o tej samej wartości.

Jednak, przy relacji identifyinig, możesz mieć tę samą wartość pokazaną dwa razy dla kolumny "ID" , o ile ma ona inną wartość klucza obcego "otherColumn_ID", ponieważ klucz podstawowy jest kombinacją obu kolumn.

Zauważ, że nie ma znaczenia czy FK jest "non-null" czy nie! ;-)

Powiedzmy, że mamy te tabele:

user
--------
id
name


comments
------------
comment_id
user_id
text

Relacja między tymi dwoma tabelami będzie identyfikowała relację. Ponieważ tylko komentarze mogą należeć do jego właściciela, a nie innych użytkowników. na przykład. Każdy użytkownik ma swój komentarz, a gdy użytkownik zostanie usunięty, komentarze tego użytkownika również powinny zostać usunięte.

Identyfikacja relacji jest między dwoma silnymi bytami. Nieidentyfikujący związek nie zawsze może być relacją między silnym podmiotem a słabym podmiotem. Może istnieć sytuacja, w której dziecko ma klucz podstawowy, ale istnienie jego jednostki może zależeć od jego jednostki dominującej.

Na przykład: relacja między Sprzedawcą a książką, w której książka jest sprzedawana przez Sprzedawcę, może istnieć, gdy sprzedawca może mieć swój własny klucz podstawowy, ale jego podmiot jest tworzony tylko wtedy, gdy książka jest sprzedawana

Odniesienie na podstawie Billa Karwina