Wat is het verschil tussen identificerende en niet-identificerende relaties?

Ik heb de verschillen niet volledig kunnen vatten. Kun je beide concepten beschrijven en voorbeelden uit de echte wereld gebruiken?

Antwoord 1, autoriteit 100%

• Een identificerende relatieis wanneer het bestaan van een rij in een onderliggende tabel afhankelijk is van een rij in een bovenliggende tabel. Dit kan verwarrend zijn, omdat het tegenwoordig gebruikelijk is om een pseudokey voor een onderliggende tabel te maken, maar nietom de refererende sleutel tot het bovenliggende deel van de primaire sleutel van het kind te maken. Formeel is de “juiste” manier om dit te doen, de externe sleutel onderdeel te maken van de primaire sleutel van het kind. Maar de logische relatie is dat het kind niet kan bestaan zonder de ouder.

  Voorbeeld: een Personheeft een of meer telefoonnummers. Als ze maar één telefoonnummer hadden, konden we het gewoon opslaan in een kolom van Person. Omdat we meerdere telefoonnummers willen ondersteunen, maken we een tweede tabel PhoneNumbers, waarvan de primaire sleutel de person_idbevat die verwijst naar de tabel Person.

  We kunnen de telefoonnummer(s) beschouwen als behorend tot een persoon, ook al zijn ze gemodelleerd als attributen van een aparte tabel. Dit is een sterke aanwijzing dat dit een identificerende relatie is (zelfs als we person_idniet letterlijk opnemen in de primaire sleutel van PhoneNumbers).

• A Niet-identificerende relatie is wanneer de primaire kernkenmerken van de ouder niet mogen primaire sleutelattributen van het kind worden. Een goed voorbeeld hiervan is een opzoektabel, zoals een buitenlandse sleutel op Person.stateverwijzen naar de primaire sleutel van States.state. Personis een kindertabel met betrekking tot States. Maar een rij in Personwordt niet geïdentificeerd door zijn stateattribuut. D.w.z. statemaakt geen deel uit van de primaire sleutel van Person.

  Een niet-identificerende relatie kan optioneel zijn of verplicht , wat betekent dat de kolom buitenlandse sleutelkolut nietig mogelijk maakt of respectievelijk nul wordt.

Zie ook mijn antwoord op nog steeds in de war over identificatie versus niet-identificerende relaties

2, Autoriteit 84%

Er is een andere uitleg van de echte wereld:

Een boek behoort tot een eigenaar en een eigenaar kan meerdere boeken bezitten. Maar het boek kan ook bestaan ​​zonder de eigenaar, en het eigendom ervan kan van de ene eigenaar naar de andere veranderen. De relatie tussen een boek en een eigenaar is een niet-identificerende relatie.

Een boek is echter geschreven door een auteur en de auteur heeft meerdere boeken geschreven. Maar het boek moet door een auteur worden geschreven – het kan niet bestaan ​​zonder een auteur. Daarom is de relatie tussen het boek en de auteur een identificerende relatie.

3, Autoriteit 4%

Bill’s antwoord is correct,
Maar het is schokkend om te zien die onder alle andere antwoorden niemand op het meest significante aspect wijst.

Er is steeds weer gezegd dat in een identificerende relatie het kind niet kan bestaan ​​zonder de ouder. (b.v. user287724 ). Dit is waar, maar mist volledig het punt. Het zou genoeg zijn voor de buitenlandse sleutel om niet-null te zijn om dit te bereiken. Het hoeft niet deel uit te maken van de primaire sleutel.

Dus hier is de echte reden:

Het doel van een identificerende relatie is dat de buitenlandse sleutel nooit kan veranderen, omdat het deel uitmaakt van de primaire sleutel … Daarom identificeren !!!

4, Autoriteit 2%

Een identificerende relatie specificeert dat een kinderobject dat niet kan
bestaan ​​zonder het ouderobject

Niet-identificerende relaties Specificeert een gewone associatie
tussen objecten, 1: 1 of 1: n-cardinaliteit.

Niet-identificerende relaties kunnen worden opgegeven als optioneel wanneer een ouder dat niet is
vereist of verplicht waar een ouder vereist is door de
Parent Table Cardinality …

5

Hier is een goede beschrijving:

Relaties tussen twee entiteiten kunnen worden geclassificeerd als ‘identificerend’ of ‘niet-identificerend’. Identificerende relaties bestaan wanneer de primaire sleutel van de bovenliggende entiteit is opgenomen in de primaire sleutel van de onderliggende entiteit. Aan de andere kant bestaat er een niet-identificerende relatie wanneer de primaire sleutel van de bovenliggende entiteit is opgenomen in de onderliggende entiteit, maar niet als onderdeel van de primaire sleutel van de onderliggende entiteit. Bovendien kunnen niet-identificerende relaties verder worden geclassificeerd als “verplicht” of “niet-verplicht”. Er is sprake van een verplichte niet-identificerende relatie wanneer de waarde in de onderliggende tabel niet null kan zijn. Aan de andere kant bestaat er een niet-verplichte niet-identificerende relatie wanneer de waarde in de onderliggende tabel null kan zijn.

http://www.sqlteam.com/article/database- ontwerp-en-modellering-fundamentals

Hier is een eenvoudig voorbeeld van een identificerende relatie:

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

Hier is een corresponderende niet-identificerende relatie:

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

Antwoord 6

Niet-identificerende relatie

Een niet-identificerende relatie betekent dat een kind verwant is aan de ouder, maar door zijn eigen ouder kan worden geïdentificeerd.

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

De relatie tussen ACCOUNT en PERSOON is niet-identificeerbaar.

Identificatie van een relatie

Een identificerende relatie betekent dat de ouder nodig is om identiteit aan het kind te geven. Het kind bestaat alleen vanwege de ouder.

Dit betekent dat de externe sleutel ook een primaire sleutel is.

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

De relatie tussen ITEM_LANG en ITEM is identificerend. En ook tussen ITEM_LANG en LANGUAGE.

Antwoord 7

Als u van mening bent dat het onderliggende item moet worden verwijderd wanneer het bovenliggende item wordt verwijderd, dan is het een identificerende relatie.

Als het onderliggende item moet worden bewaard, ook al is het bovenliggende item verwijderd, dan is het een niet-identificerende relatie.

Als voorbeeld heb ik een trainingsdatabase met stagiaires, trainingen, diploma’s en trainingssessies :

• trainees hebben een identificerende relatie met trainingssessies
• trainingen hebben een identificerende relatie met trainingssessies
• maar stagiairs hebben een niet-identificerende relatie met diploma’s

Alleen trainingssessies moeten worden verwijderd als een van de gerelateerde stagiaires, trainingen of diploma’s wordt verwijderd.

Antwoord 8

De identificerende relatie betekent dat de onderliggende entiteit volledig afhankelijk is van het bestaan van de bovenliggende entiteit.
Voorbeeld accounttabel persoonstabel en persoonsaccount.De persoonsaccounttabel wordt alleen geïdentificeerd door het bestaan van account- en persoonstabel.

De niet-identificerende relatie betekent dat de onderliggende tabel niet wordt geïdentificeerd door het bestaan van de bovenliggende tabel
er is bijvoorbeeld een tabel als accounttype en account.accounttype tabel wordt niet geïdentificeerd met het bestaan van accounttabel.

Antwoord 9

Zoals goed uitgelegd in de onderstaande link, lijkt een identificerende relatie enigszins op een zwakke entiteitstyperelatie met zijn bovenliggende in het ER-conceptuele model. CAD’s in UML-stijl voor gegevensmodellering gebruiken geen ER-symbolen of -concepten, en het soort relaties is: identificerend, niet-identificerend en niet-specifiek.

Identificerende zijn relaties ouder/kind waarbij het kind een soort zwakke entiteit is (zelfs in het traditionele ER-model wordt dit identificerende relatie genoemd), die geen echte primaire sleutel heeft door zijn eigen kenmerken en daarom niet uniek kan worden geïdentificeerd door zijn eigen. Elke toegang tot de onderliggende tabel, op het fysieke model, is afhankelijk (inclusief semantisch) van de primaire sleutel van de ouder, die verandert in een deel of het geheel van de primaire sleutel van het kind (ook een externe sleutel), wat doorgaans resulteert in een samengestelde sleutel aan de kinderkant. De eventuele bestaande sleutels van het kind zelf zijn slechts pseudo- of gedeeltelijke sleutels, niet voldoende om een instantie van dat type entiteit of entiteitenset te identificeren, zonder de PK van de ouder.

Niet-identificerende relaties zijn de gewone relaties (gedeeltelijk of totaal) van volledig onafhankelijke entiteitensets, waarvan de instanties niet afhankelijk zijn van elkaars primaire sleutels om uniek te worden geïdentificeerd, hoewel ze mogelijk externe sleutels nodig hebben voor gedeeltelijke of totale relaties , maar niet als de primaire sleutel van het kind. Het kind heeft zijn eigen primaire sleutel. Het ouderidee. Beide zelfstandig. Afhankelijk van de kardinaliteit van de relatie, gaat de PK van de ene als een FK naar de andere (N-kant), en als deze gedeeltelijk is, kan deze nul zijn, als deze totaal is, mag deze niet nul zijn. Maar bij een relatie als deze zal de FK nooit ook de PK van het kind zijn, zoals bij een identificerende relatie het geval is.

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

Antwoord 10

Helpen kenmerken die van ouder naar kind zijn gemigreerd identificeren¹het kind?

• Indien ja: de identificatie-afhankelijkheid bestaat, de relatie is identificerend en de onderliggende entiteit is “zwak”.
• Als niet: de identificatie-afhankelijkheid niet bestaat, is de relatie niet-identificerend en is de onderliggende entiteit “sterk”.

Merk op dat identificatie-afhankelijkheid existentie-afhankelijkheid impliceert, maar niet andersom. Elke niet-NULL FK betekent dat een kind niet kan bestaan zonder ouder, maar dat alleen maakt de relatie niet identificerend.

Kijk voor meer informatie hierover (en enkele voorbeelden) naar het gedeelte ‘Relaties identificeren’ van de ERwin-methodengids.

P.S. Ik besef dat ik (extreem) laat op het feest ben, maar ik heb het gevoel dat andere antwoorden ofwel niet helemaal juist zijn (definitie in termen van bestaansafhankelijkheid in plaats van identificatie-afhankelijkheid), of enigszins kronkelig. Hopelijk geeft dit antwoord meer duidelijkheid…

¹De FK van het kind maakt deel uit van de PRIMARY KEY of (niet-NULL) UNIEKE beperking van het kind.

Antwoord 11

Een goed voorbeeld is de orderverwerking. Een bestelling van een klant heeft doorgaans een bestelnummer dat de bestelling identificeert, enkele gegevens die eenmaal per bestelling voorkomen, zoals de besteldatum en de klant-ID, en een reeks regelitems. Elk regelitem bevat een itemnummer dat een regelitem in een bestelling, een besteld product, de hoeveelheid van dat product, de prijs van het product en het bedrag voor het regelitem identificeert, dat kan worden berekend door de hoeveelheid te vermenigvuldigen met de prijs.

Het nummer dat een regelitem identificeert, identificeert het alleen in de context van een enkele bestelling. Het eerste regelitem in elke bestelling is itemnummer “1”. De volledige identiteit van een regelitem is het itemnummer samen met het ordernummer waarvan het onderdeel uitmaakt.

De parent-childrelatie tussen orders en regelitems is daarom een identificerende relatie. Een nauw verwant concept in ER-modellering heet “subentiteit”, waarbij regelitem een subentiteit van orde is. Doorgaans heeft een subentiteit een verplichte identificatierelatie tussen onderliggende en bovenliggende entiteiten ten opzichte van de entiteit waaraan deze ondergeschikt is.

In klassiek databaseontwerp zou de primaire sleutel van de LineItems-tabel zijn (OrderNumber, ItemNumber). Sommige hedendaagse ontwerpers zouden een item een aparte ItemID geven, die als primaire sleutel dient en automatisch wordt verhoogd door het DBMS. Ik raad in dit geval klassiek design aan.

12

Laten we zeggen dat we die tabellen hebben:

user
--------
id
name
comments
------------
comment_id
user_id
text

Relatie tussen die twee tabellen zullen een relatie identificeren. Omdat, reacties alleen kunnen behoren tot de eigenaar, geen andere gebruikers. bijvoorbeeld. Elke gebruiker heeft eigen commentaar en wanneer de gebruiker wordt verwijderd, moeten de opmerkingen van deze gebruiker ook worden verwijderd.

13

Een identificerende relatie is tussen twee sterke entiteiten. Een niet-identificerende relatie is misschien niet altijd een relatie tussen een sterke entiteit en een zwakke entiteit. Er kan een situatie bestaan ​​waar een kind zelf een primaire sleutel heeft, maar het bestaan ​​van zijn entiteit kan afhangen van zijn ouderlijke entiteit.

Bijvoorbeeld: een relatie tussen een verkoper en een boek waar een boek wordt verkocht door een verkoper kan bestaan ​​waar de verkoper mogelijk een eigen primaire sleutel heeft, maar de entiteit wordt alleen gemaakt wanneer een boek wordt verkocht

Referentie op basis van Bill Karwin