Jaka jest różnica między relacjami identyfikującymi a nieidentyfikującymi?

Nie byłem w stanie w pełni zrozumieć różnic. Czy potrafisz opisać obie koncepcje i wykorzystać przykłady ze świata rzeczywistego?

• Związek identyfikacji jest, gdy istnienie wiersza w tabeli podrzędnej zależy od wiersza w tabeli macierzystego. Może to być mylące, ponieważ obecnie powszechną praktyką jest tworzenie pseudoklucza dla tabeli podrzędnej, ale nie tworzenie klucza obcego do nadrzędnej części klucza podstawowego dziecka. Formalnie „właściwym” sposobem na to jest uczynienie klucza obcego częścią klucza podstawowego dziecka. Ale logiczny związek polega na tym, że dziecko nie może istnieć bez rodzica.

  Przykład: A Personma jeden lub więcej numerów telefonów. Gdyby mieli tylko jeden numer telefonu, moglibyśmy po prostu zapisać go w kolumnie Person. Ponieważ chcemy obsługiwać wiele numerów telefonów, tworzymy drugą tabelę PhoneNumbers, której klucz podstawowy obejmuje person_idodwołanie się do Persontabeli.

  Możemy uważać numery telefonów za należące do danej osoby, nawet jeśli są one modelowane jako atrybuty oddzielnej tabeli. Jest to silna wskazówka, że ​​jest to związek identyfikujący (nawet jeśli dosłownie nie włączamy person_idklucza podstawowego PhoneNumbers).

• Związek bez identyfikacji jest, gdy klucz podstawowy atrybuty rodzica nie musi stać się kluczem podstawowym atrybuty dziecka. Dobrym przykładem tego jest tablica odnośników, na przykład klucz obcy przy Person.stateodwoływaniu się do klucza podstawowego States.state. Personjest stołem dziecięcym w odniesieniu do States. Ale wiersz w Personnie jest identyfikowany przez jego stateatrybut. Tj. stateNie jest częścią klucza podstawowego Person.

  Relacja nieidentyfikująca może być opcjonalna lub obowiązkowa , co oznacza, że ​​kolumna z kluczem obcym pozwala odpowiednio na NULL lub nie zezwala na NULL.

Zobacz także moją odpowiedź na „ Wciąż zdezorientowany na temat relacji identyfikujących i nieidentyfikujących”

Istnieje inne wytłumaczenie ze świata rzeczywistego:

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 własność może się zmieniać od jednego właściciela do drugiego. Relacja między książką a właścicielem jest relacją nieidentyfikującą.

Książka została jednak napisana przez autora i 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ą.

Odpowiedź Billa jest poprawna, ale szokujące jest, że wśród wszystkich pozostałych odpowiedzi nikt nie wskazuje na najbardziej znaczący aspekt.

Mówi się w kółko, że w związku identyfikującym dziecko nie może istnieć bez rodzica. (np. użytkownik 287724 ). To prawda, ale całkowicie mija się z celem. Wystarczyłoby, aby klucz obcy był różny od zera, aby to osiągnąć. Nie musi być częścią klucza podstawowego.

Oto prawdziwy powód:

Relacja identyfikująca ma na celu NIGDY NIE ZMIENIĆ klucza obcego , ponieważ jest on częścią klucza podstawowego ... dlatego identyfikuje !!!

Relacja identyfikująca określa, że ​​obiekt podrzędny nie może istnieć bez obiektu nadrzędnego

Nieidentyfikujące relacje określają regularne powiązanie między obiektami, liczebność 1: 1 lub 1: n.

Relacje nieidentyfikujące można określić jako opcjonalne, gdy rodzic nie jest wymagany lub obowiązkowy, gdy rodzic jest wymagany, ustawiając liczność tabeli nadrzędnej ...

Oto dobry opis:

Relacje między dwoma podmiotami można zaklasyfikować jako „identyfikujące” lub „nieidentyfikujące”. Relacje identyfikacyjne istnieją, gdy klucz podstawowy encji nadrzędnej jest zawarty w kluczu encji encji podrzędnej. Z drugiej strony relacja nieidentyfikująca istnieje, gdy klucz podstawowy encji nadrzędnej jest zawarty w encji podrzędnej, ale nie jako część klucza podstawowego encji podrzędnej. Ponadto relacje nieidentyfikujące można dodatkowo zaklasyfikować jako „obowiązkowe” lub „nieobowiązkowe”. Obowiązkowa nieidentyfikująca relacja istnieje, gdy wartość w tabeli potomnej nie może być pusta. Z drugiej strony istnieje nieobowiązkowa relacja nieidentyfikująca, gdy wartość w tabeli potomnej może być pusta.

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

Oto prosty przykład relacji identyfikującej:

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

odpowiedź user287724 podaje następujący przykład relacji między książką a autorem:

Książka została jednak napisana przez autora, a autor mógł napisać wiele książek. Ale książka musi zostać napisana przez autora, bez niej nie może istnieć. 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, booknie mogą być pisane bez co najmniej jednego author, ale author(to klucz obcy) z bookjest bez wskazywaniabook w bookstabeli!

Można usunąć author(FK) z bookrzędu i nadal można zidentyfikować wiersz książki za pośrednictwem innego pola ( ISBN, ID, etc ...), ale nie autor książki !!

Myślę, że poprawnym przykładem identifying relationshipmoże być związek między (tabelą produktów) a (tabelą szczegółowych informacji o produkcie)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_IDw printers_detailstabeli uważa się, że FK odwołuje się do products.idtabeli, a także PK w printers_detailstabeli, jest to relacja identyfikująca, ponieważ Product_ID(FK) w tabeli drukarek IDENTYFIKUJE wiersz wewnątrz tabeli potomnej , nie możemy usunąć product_idz tabeli podrzędnej, ponieważ nie możemy zidentyfikować wiersz dłużej, ponieważ straciliśmy to klucz podstawowy

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

relacja identyfikująca jest relacją, gdy FK w tabeli podrzędnej jest uważany za PK (lub identyfikator) w tabeli podrzędnej, podczas gdy nadal odwołuje się do tabeli nadrzędnej

Innym przykładem może być sytuacja, gdy masz 3 tabele (import - produkty - kraje) w imporcie i eksporcie dla bazy danych niektórych krajów

importStół jest dziecko, które ma te pola (The product_id(FK), The country_id(FK), ilość przywozu, ceny, jednostki importowane, sposobu transportu (lotniczy, morski)) we may use the (product_id , thecountry_id`) do identyfikacji każdego wiersz importu „jeśli wszystkie w tym samym roku” tutaj obie kolumny mogą razem skomponować klucz podstawowy w tabeli potomnej (import), a także odwołać się do tabel nadrzędnych.

Proszę, cieszę się, że w końcu zrozumiałem koncepcję identifying relationshipi non identifying relationship, więc proszę nie mówcie, że się mylę z tymi wszystkimi głosowaniami na zupełnie nieważny przykład

Tak logicznie, książki nie można napisać bez autora, ale książki można zidentyfikować bez autora. W rzeczywistości nie można jej zidentyfikować z autorem!

Możesz w 100% usunąć autora z wiersza książki i nadal możesz zidentyfikować książkę! .

Relacja nieidentyfikująca

Nieidentyfikujący związek oznacza, że ​​dziecko jest spokrewnione z rodzicem, ale można je zidentyfikować samodzielnie.

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

Związek między KONTO a OSOBĄ nie jest identyfikujący.

Identyfikacja relacji

Relacja identyfikująca oznacza, że ​​rodzic jest potrzebny do nadania tożsamości dziecku. Dziecko istnieje wyłącznie z powodu rodzica.

Oznacza to, że klucz obcy jest również kluczem podstawowym.

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

Związek między ITEM_LANG a ITEM jest identyfikujący. A także między ITEM_LANG i LANGUAGE.

Jeśli uważasz, że element potomny powinien zostać usunięty po usunięciu elementu nadrzędnego, oznacza to relację identyfikującą.

Jeśli element podrzędny powinien zostać zachowany nawet po usunięciu elementu nadrzędnego, jest to relacja nieidentyfikująca.

Jako przykład mam bazę danych szkoleń ze stażystami, szkoleniami, dyplomami i sesjami szkoleniowymi:

• stażyści mają identyfikujący związek z sesjami szkoleniowymi
• szkolenia mają związek identyfikacyjny z treningami
• ale stażyści mają nieidentyfikujący związek z dyplomami

Tylko sesje szkoleniowe powinny być usuwane, jeśli jeden z powiązanych stażystów, szkoleń lub dyplomów zostanie usunięty.

Relacja identyfikująca oznacza, że ​​byt podrzędny jest całkowicie zależny od istnienia bytu nadrzędnego. Przykładowa tabela osób i tabela osób. Tabela osób jest identyfikowana tylko przez istnienie konta i tabeli osób.

Nieidentyfikująca relacja oznacza, że ​​tabela potomna nie jest identyfikowana przez istnienie przykładu tabeli nadrzędnej, w której istnieje tabela jako typ konta i konto. Tabela typu konta nie jest identyfikowana z istnieniem tabeli konta.

Jak dobrze wyjaśniono w poniższym linku, relacja identyfikująca jest trochę jak relacja typu słabej jednostki do jej rodzica w modelu koncepcyjnym ER. Modele CAD w stylu UML do modelowania danych nie używają symboli ani pojęć ER, a rodzajem relacji są: identyfikacja, brak identyfikacji i niespecyficzny.

Te identyfikujące to relacje rodzic / dziecko, w których dziecko jest rodzajem słabej istoty (nawet w tradycyjnym modelu ER nazywane jest relacją identyfikującą), która nie ma prawdziwego klucza podstawowego według własnych atrybutów i dlatego nie może być jednoznacznie zidentyfikowana . Każdy dostęp do tabeli podrzędnej w modelu fizycznym będzie zależny (włącznie semantycznie) od klucza podstawowego rodzica, który zamienia się w część lub całość klucza podstawowego dziecka (również będącego kluczem obcym), generalnie skutkując kluczem złożonym po stronie dziecka. Ewentualne istniejące klucze samego dziecka są tylko pseudo lub częściowymi kluczami, niewystarczającymi do zidentyfikowania jakiegokolwiek wystąpienia tego typu jednostki lub zestawu jednostek, bez PK rodzica.

Relacje nieidentyfikujące to zwykłe relacje (częściowe lub całkowite) całkowicie niezależnych zestawów encji, których instancje nie zależą od identyfikujących się kluczy podstawowych, chociaż mogą potrzebować kluczy obcych do relacji częściowych lub całkowitych, ale nie jako podstawowy klucz dziecka. Dziecko ma własny klucz podstawowy. Idem nadrzędny. Oba niezależnie. W zależności od liczności relacji PK jednego przechodzi jako FK na drugi (strona N), a jeśli częściowe, może być zerowe, jeśli całkowite, nie może być zerowe. Ale w takim związku FK nigdy nie będzie również PK dziecka, tak jak w przypadku związku identyfikującego.

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

Czy atrybuty migrowane z rodzica na dziecko pomagają zidentyfikować ¹ dziecko?

• Jeśli tak : zależność identyfikacji istnieje, związek jest identyfikujący, a jednostka potomna jest „słaba”.
• Jeśli nie : zależność identyfikacyjna nie istnieje, związek nie jest identyfikujący, a jednostka potomna „silna”.

Zauważ, że zależność od identyfikacji oznacza zależność od istnienia, ale nie na odwrót. Każdy FK inny niż NULL oznacza, że ​​dziecko nie może istnieć bez rodzica, ale samo to nie czyni związku identyfikującym.

Aby uzyskać więcej informacji na ten temat (i kilka przykładów), zapoznaj się z sekcją „Identyfikacja relacji” w przewodniku metod ERwin .

PS Zdaję sobie sprawę, że jestem (wyjątkowo) spóźniony na imprezę, ale czuję, że inne odpowiedzi albo nie są do końca dokładne (definiując je jako zależność od istnienia zamiast zależności od tożsamości), albo nieco meandrujące. Mam nadzieję, że ta odpowiedź zapewni większą jasność ...

¹ FK dziecka jest częścią ograniczenia PODSTAWOWEGO KLUCZA dziecka lub (nie-NULL) ograniczenia UNIKALNEGO.

Dobry przykład pochodzi z przetwarzania zamówień. Zamówienie od klienta zazwyczaj ma numer zamówienia, który identyfikuje zamówienie, niektóre dane, które pojawiają się raz na zamówienie, takie jak data zamówienia i identyfikator klienta oraz szereg elementów zamówienia. 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, którą można obliczyć, mnożąc ilość przez Cena £.

Liczba identyfikująca element zamówienia identyfikuje go tylko w kontekście pojedynczego zamówienia. Pierwszy element zamówienia w każdym zamówieniu ma numer „1”. Pełna tożsamość elementu zamówienia to numer elementu wraz z numerem zamówienia, którego jest on częścią.

Relacja nadrzędna podrzędna między zamówieniami a elementami zamówienia jest zatem relacją identyfikującą. Ściśle powiązaną koncepcją w modelowaniu ER jest nazwa „subentity”, gdzie element zamówienia jest subtelnością zamówienia. Zazwyczaj podobieństwo ma obowiązkowy związek tożsamości dziecko-rodzic z bytem, ​​któremu podlega.

W klasycznym projekcie bazy danych kluczem podstawowym tabeli LineItems byłby (OrderNumber, ItemNumber). Niektórzy z dzisiejszych projektantów nadaliby elementowi osobny identyfikator przedmiotu, który służy jako klucz podstawowy i jest automatycznie zwiększany przez DBMS. W tym przypadku polecam klasyczny design.

Powiedzmy, że mamy te tabele:

user
--------
id
name


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

związek między tymi dwiema tabelami pozwoli zidentyfikować związek. Ponieważ komentarze mogą należeć tylko do 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.

Relacja identyfikująca występuje między dwoma silnymi bytami. Nieidentyfikujący związek nie zawsze może być związkiem między silnym bytem a słabym bytem. Może istnieć sytuacja, w której dziecko ma klucz podstawowy, ale istnienie jego bytu może zależeć od jego bytu nadrzędnego.

Na przykład: relacja między sprzedawcą a książką, w której sprzedawca sprzedaje książkę, może istnieć, gdy sprzedawca może mieć swój własny klucz podstawowy, ale jej jednostka jest tworzona tylko podczas sprzedaży książki

Referencje na podstawie Billa Karwina