it-swarm.com.de

Was ist der Unterschied zwischen identifizierenden und nicht identifizierenden Beziehungen?

Ich konnte die Unterschiede nicht vollständig erfassen. Können Sie beide Konzepte beschreiben und Beispiele aus der Praxis verwenden?

765
Loc Nguyen
  • Eine identifizierende Beziehung ist, wenn das Vorhandensein einer Zeile in einer untergeordneten Tabelle von einer Zeile in einer übergeordneten Tabelle abhängt. Dies kann verwirrend sein, da es heutzutage üblich ist, einen Pseudoschlüssel für eine untergeordnete Tabelle zu erstellen, aber den Fremdschlüssel nicht zum übergeordneten Teil des Primärschlüssels des untergeordneten Schlüssels macht . Formal besteht der "richtige" Weg darin, den Fremdschlüssel zum Primärschlüssel des Kindes zu machen. Aber die logische Beziehung ist, dass das Kind ohne das Elternteil nicht existieren kann.

    Beispiel: Ein Person hat eine oder mehrere Telefonnummern. Wenn sie nur eine Telefonnummer hätten, könnten wir sie einfach in einer Spalte von Person speichern. Da wir mehrere Telefonnummern unterstützen möchten, erstellen wir eine zweite Tabelle PhoneNumbers, deren Primärschlüssel den person_id enthält, der auf die Tabelle Person verweist.

    Wir können uns die Telefonnummer (n) als einer Person zugehörig vorstellen, obwohl sie als Attribute einer separaten Tabelle modelliert sind. Dies ist ein starker Hinweis darauf, dass dies eine identifizierende Beziehung ist (auch wenn wir person_id nicht wörtlich in den Primärschlüssel von PhoneNumbers aufnehmen).

  • Eine nicht identifizierende Beziehung liegt vor, wenn die Primärschlüsselattribute des übergeordneten Elements nicht zu Primärschlüsselattributen werden dürfen Des kindes. Ein gutes Beispiel hierfür ist eine Nachschlagetabelle, z. B. ein Fremdschlüssel in Person.state, der auf den Primärschlüssel von States.state verweist. Person ist eine untergeordnete Tabelle in Bezug auf States. Eine Zeile in Person wird jedoch nicht durch das Attribut state identifiziert. Das heißt state ist nicht Teil des Primärschlüssels von Person.

    Eine nicht identifizierende Beziehung kann optional oder obligatorisch sein Fremdschlüsselspalte erlaubt NULL bzw. verbietet NULL.


Siehe auch meine Antwort auf Immer noch verwirrt über identifizierende und nicht identifizierende Beziehungen

1011
Bill Karwin

Es gibt eine andere Erklärung aus der realen Welt:

Ein Buch gehört einem Eigentümer, und ein Eigentümer kann mehrere Bücher besitzen. Das Buch kann jedoch auch ohne den Eigentümer existieren, und der Eigentümer kann von einem Eigentümer zum anderen wechseln. Die Beziehung zwischen einem Buch und einem Eigentümer ist eine nicht identifizierende Beziehung.

Ein Buch wird jedoch von einem Autor geschrieben, und der Autor könnte mehrere Bücher geschrieben haben. Das Buch muss jedoch von einem Autor geschrieben werden - es kann nicht ohne einen Autor existieren. Daher ist die Beziehung zwischen dem Buch und dem Autor eine identifizierende Beziehung.

863
user287724

Bills Antwort ist richtig, aber es ist schockierend zu sehen , dass unter allen anderen Antworten niemand den wichtigsten Aspekt hervorhebt.

Es wird immer wieder gesagt, dass das Kind in einer identifizierenden Beziehung ohne das Elternteil nicht existieren kann. (z. B. ser287724 ). Dies ist wahr, aber es geht völlig daneben. Es würde ausreichen, wenn der Fremdschlüssel ungleich Null wäre, um dies zu erreichen. Es muss nicht Teil des Primärschlüssels sein.

Also hier ist der wahre Grund:

Der Zweck einer identifizierenden Beziehung ist, dass der Fremdschlüssel NIEMALS ÄNDERN kann , weil er Teil des Primärschlüssels ist ... daher identifizieren !!!

24
Daniel Dinnyes

Eine identifizierende Beziehung gibt an, dass ein untergeordnetes Objekt ohne das übergeordnete Objekt nicht vorhanden sein kann

Nicht identifizierende Beziehungen spezifizieren eine regelmäßige Zuordnung zwischen Objekten, 1: 1 oder 1: n Kardinalität.

Nicht identifizierende Beziehungen können als optional angegeben werden, wenn kein übergeordnetes Element erforderlich ist, oder als obligatorisch, wenn ein übergeordnetes Element erforderlich ist, indem die Kardinalität der übergeordneten Tabelle festgelegt wird.

24
CMS

Hier ist eine gute Beschreibung:

Beziehungen zwischen zwei Entitäten können als "identifizierend" oder "nicht identifizierend" klassifiziert werden. Identifizierende Beziehungen bestehen, wenn der Primärschlüssel der übergeordneten Entität im Primärschlüssel der untergeordneten Entität enthalten ist. Andererseits besteht eine nicht identifizierende Beziehung, wenn der Primärschlüssel der übergeordneten Entität in der untergeordneten Entität enthalten ist, jedoch nicht als Teil des Primärschlüssels der untergeordneten Entität. Darüber hinaus können nicht identifizierende Beziehungen weiter als "obligatorisch" oder "nicht obligatorisch" klassifiziert werden. Eine obligatorische nicht identifizierende Beziehung liegt vor, wenn der Wert in der untergeordneten Tabelle nicht null sein kann. Andererseits besteht eine nicht obligatorische nicht identifizierende Beziehung, wenn der Wert in der untergeordneten Tabelle null sein kann.

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

Hier ist ein einfaches Beispiel für eine identifizierende Beziehung:

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

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

Hier ist eine entsprechende nicht identifizierende Beziehung:

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

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

Antwort von user287724 gibt das folgende Beispiel für die Beziehung zwischen Buch und Autor:

Ein Buch wird jedoch von einem Autor geschrieben, und der Autor könnte mehrere Bücher geschrieben haben. Aber das Buch muss von einem Autor geschrieben werden, es kann nicht ohne einen Autor existieren. Daher ist die Beziehung zwischen dem Buch und dem Autor eine identifizierende Beziehung.

Dies ist ein sehr verwirrendes Beispiel und ist definitiv kein gültiges Beispiel für einen identifying relationship.

Ja, ein book kann nicht ohne mindestens ein author geschrieben werden, aber der author (Fremdschlüssel) des book ist NOT IDENTIFYING = das book in der books Tabelle!

Sie können die Zeile author (FK) aus der Zeile book entfernen und die Buchzeile dennoch durch ein anderes Feld identifizieren (ISBN, ID, ... usw.). ABER NICHT der Autor des Buches !!

Ich denke, ein gültiges Beispiel für einen identifying relationship wäre die Beziehung zwischen (Produkttabelle) und einer (spezifischen Produktdetailtabelle) 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

In diesem Beispiel wird der Product_ID in der printers_details -Tabelle als FK-Verweis auf die products.id -Tabelle und AUCH ein PK in der printers_details -Tabelle betrachtet ist eine identifizierende Beziehung, da Product_ID (FK) in der Druckertabelle IS IDENTIFYING die Zeile in der untergeordneten Tabelle, wir können den product_id aus der untergeordneten Tabelle nicht entfernen, weil Wir können die Zeile nicht mehr identifizieren, da wir den Primärschlüssel verloren haben

Wenn Sie es in 2 Zeilen setzen möchten:

eine identifizierende Beziehung ist die Beziehung, in der die FK in der untergeordneten Tabelle als PK (oder Bezeichner) in der untergeordneten Tabelle betrachtet wird, während weiterhin auf die übergeordnete Tabelle verwiesen wird

Ein anderes Beispiel kann sein, wenn Sie 3 Tabellen (Importe - Produkte - Länder) in einer Import- und Exportdatenbank für einige Länder haben

Die import Tabelle ist das Kind, das diese Felder hat (der product_id (FK), der country_id (FK), die Menge der Importe, der Preis, die importierten Einheiten, die Art und Weise des Transports (Luft, See)) we may use the (product_id, thecountry_id`) um jede Zeile der Importe zu identifizieren "wenn sie alle im selben Jahr" hier können die beiden Spalten zusammen einen Primärschlüssel in der Kindertabelle bilden ( importiert) und verweist auch auf die übergeordneten Tabellen.

Bitte, ich bin froh, dass ich endlich das Konzept von identifying relationship und non identifying relationship verstehe. Bitte sagen Sie mir nicht, dass ich mich mit all diesen Abstimmungen für ein völlig ungültiges Beispiel irre

Ja logischerweise kann ein Buch nicht ohne einen Autor geschrieben werden, aber ein Buch kann ohne den Autor identifiziert werden. Tatsächlich kann es nicht mit dem Autor identifiziert werden!

Sie können den Autor zu 100% aus der Buchreihe entfernen und das Buch trotzdem identifizieren!.

10
Accountant م

Nicht identifizierende Beziehung

Eine nicht identifizierende Beziehung bedeutet, dass ein Kind mit einem Elternteil verwandt ist, aber durch ein eigenes Kind identifiziert werden kann.

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

Die Beziehung zwischen ACCOUNT und PERSON ist nicht identifizierbar.

Identifizierende Beziehung

Eine identifizierende Beziehung bedeutet, dass der Elternteil benötigt wird, um dem Kind Identität zu verleihen. Das Kind existiert nur wegen des Elternteils.

Dies bedeutet, dass der Fremdschlüssel auch ein Primärschlüssel ist.

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

Die Beziehung zwischen ITEM_LANG und ITEM ist identifizierend. Und auch zwischen ITEM_LANG und LANGUAGE.

7
Skarllot

Wenn Sie der Meinung sind, dass das untergeordnete Element gelöscht werden sollte, wenn das übergeordnete Element gelöscht wird, handelt es sich um eine identifizierende Beziehung.

Wenn das untergeordnete Element beibehalten werden soll, obwohl das übergeordnete Element gelöscht wurde, handelt es sich um eine nicht identifizierende Beziehung.

Als Beispiel habe ich eine Trainingsdatenbank mit Auszubildenden, Trainings, Diplomen und Trainingseinheiten:

  • auszubildende haben eine identifizierende Beziehung zu Trainingseinheiten
  • trainings haben eine identifizierende Beziehung zu Trainingseinheiten
  • auszubildende haben jedoch eine nicht identifizierende Beziehung zu Diplomen

Nur Schulungen sollten gelöscht werden, wenn einer der zugehörigen Auszubildenden, Schulungen oder Diplome gelöscht wird.

3
Daishi

Die identifizierende Beziehung bedeutet, dass die untergeordnete Entität vollständig von der Existenz der übergeordneten Entität abhängig ist. Beispiel Kontotabelle Personentabelle und Personenkonto. Die Personenkontotabelle wird nur durch das Vorhandensein von Konto- und Personentabelle identifiziert.

Die nicht identifizierende Beziehung bedeutet, dass die untergeordnete Tabelle nicht durch die Existenz der übergeordneten Tabelle identifiziert wird. Beispiel: Es gibt eine Tabelle als Kontotyp und eine Konto.Kontotyp-Tabelle wird nicht durch die Existenz der Kontentabelle identifiziert.

3
chanchal dixit

Identifizieren Sie Attribute, die von Eltern zu Kindern migriert wurden ?1 das kind?

  • Wenn ja : die Identifizierungsabhängigkeit besteht, ist die Beziehung identifizierend und die untergeordnete Entität "schwach".
  • Wenn nicht : Die Identifizierungsabhängigkeit existiert nicht, ist die Beziehung nicht identifizierend und die untergeordnete Entität "stark".

Man beachte, dass Identifizierungsabhängigkeit Existenzabhängigkeit impliziert, aber nicht umgekehrt. Jede Nicht-NULL-FK bedeutet, dass ein Kind ohne Elternteil nicht existieren kann, aber das allein macht die Beziehung nicht identifizierend.

Weitere Informationen hierzu (und zu einigen Beispielen) finden Sie im Abschnitt "Identifizieren von Beziehungen" im ERwin Methods Guide .

P.S. Mir ist klar, dass ich (extrem) spät dran bin, aber ich glaube, dass andere Antworten entweder nicht ganz zutreffend sind (indem ich sie als existenzabhängig anstatt als identifikationsabhängig definiere) oder irgendwie mäanderförmig. Hoffentlich sorgt diese Antwort für mehr Klarheit ...


1 Die FK des Kindes ist Teil des PRIMARY KEY oder der (nicht NULL) UNIQUE-Einschränkung des Kindes.

2

Wie im folgenden Link ausführlich erläutert, entspricht eine identifizierende Beziehung in etwa einer schwachen Entitätstypbeziehung zu ihrem übergeordneten Element im ER-Konzeptmodell. CADs im UML-Stil für die Datenmodellierung verwenden keine ER-Symbole oder -Konzepte, und es gibt folgende Arten von Beziehungen: identifizierend, nicht identifizierend und nicht spezifisch.

Identifizierende Beziehungen sind Eltern/Kind-Beziehungen, bei denen das Kind eine Art schwache Entität ist (selbst im traditionellen ER-Modell die so genannte identifizierende Beziehung), die keinen echten Primärschlüssel durch ihre eigenen Attribute besitzt und daher nicht eindeutig durch ihre eigenen identifiziert werden kann . Jeder Zugriff auf die untergeordnete Tabelle auf der Grundlage des physischen Modells ist (semantisch eingeschlossen) vom Primärschlüssel des Elternteils abhängig, der sich in einen Teil oder eine Summe des Primärschlüssels des Kindes (der auch ein Fremdschlüssel ist) umwandelt, was im Allgemeinen zu einem zusammengesetzten Schlüssel führt auf der kinderseite. Die eventuell vorhandenen Schlüssel des Kindes selbst sind nur Pseudo- oder Teilschlüssel, die nicht ausreichen, um eine Instanz dieses Entitätstyps oder Entitätssatzes ohne die PK des Elternteils zu identifizieren.

Nicht identifizierende Beziehungen sind die gewöhnlichen (teilweisen oder vollständigen) Beziehungen von vollständig unabhängigen Entitätsmengen, deren Instanzen nicht davon abhängen, dass die Primärschlüssel der jeweils anderen eindeutig identifiziert werden, obwohl sie möglicherweise Fremdschlüssel für teilweise oder vollständige Beziehungen benötigen, dies jedoch nicht als Primärschlüssel des Kindes. Das Kind hat einen eigenen Primärschlüssel. Die übergeordnete IDEM. Beides unabhängig. Abhängig von der Kardinalität der Beziehung geht die PK von einer als FK zur anderen (N-Seite) und kann, wenn partiell, null sein, wenn total, muss sie nicht null sein. Aber in einer solchen Beziehung wird die FK niemals auch die PK des Kindes sein, wie es bei einer identifizierenden Beziehung der Fall ist.

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

1
Daniel Pinheiro

Ein gutes Beispiel ist die Auftragsabwicklung. Eine Bestellung von einem Kunden hat normalerweise eine Bestellnummer, die die Bestellung identifiziert, einige Daten, die einmal pro Bestellung auftreten, wie das Bestelldatum und die Kunden-ID, und eine Reihe von Werbebuchungen. Jede Werbebuchung enthält eine Artikelnummer, die eine Werbebuchung innerhalb einer Bestellung, ein bestelltes Produkt, die Menge dieses Produkts, den Preis des Produkts und den Betrag für die Werbebuchung identifiziert, die durch Multiplizieren der Menge mit berechnet werden kann Preis.

Die Nummer, die eine Werbebuchung identifiziert, identifiziert sie nur im Kontext eines einzelnen Auftrags. Die erste Position in jeder Bestellung ist die Positionsnummer "1". Die vollständige Identität einer Position ist die Positionsnummer zusammen mit der Bestellnummer, zu der sie gehört.

Die übergeordnete untergeordnete Beziehung zwischen Aufträgen und Werbebuchungen ist daher eine identifizierende Beziehung. Ein eng verwandtes Konzept in der ER-Modellierung trägt den Namen "Subentität", wobei die Position eine Subentität der Reihenfolge ist. In der Regel besteht für eine Unterentität eine obligatorische Kind-Eltern-Identitätsbeziehung zu der Entität, der sie untergeordnet ist.

Im klassischen Datenbankdesign wäre der Primärschlüssel der LineItems-Tabelle (OrderNumber, ItemNumber). Einige der heutigen Designer würden einem Element eine separate ItemID zuweisen, die als Primärschlüssel dient und vom DBMS automatisch inkrementiert wird. Ich empfehle in diesem Fall klassisches Design.

1
Walter Mitty

Nehmen wir an, wir haben diese Tabellen:

user
--------
id
name


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

die Beziehung zwischen diesen beiden Tabellen identifiziert die Beziehung. Da Kommentare nur ihrem Besitzer gehören können, nicht anderen Benutzern. zum Beispiel. Jeder Benutzer hat einen eigenen Kommentar. Wenn der Benutzer gelöscht wird, sollten auch die Kommentare dieses Benutzers gelöscht werden.

0

Eine identifizierende Beziehung besteht zwischen zwei starken Einheiten. Eine nicht identifizierende Beziehung ist möglicherweise nicht immer eine Beziehung zwischen einer starken und einer schwachen Entität. Es kann vorkommen, dass ein Kind selbst einen Primärschlüssel hat, die Existenz seiner Entität jedoch von seiner übergeordneten Entität abhängt.

Beispiel: Eine Beziehung zwischen einem Verkäufer und einem Buch, in dem ein Buch von einem Verkäufer verkauft wird, kann bestehen, wenn der Verkäufer möglicherweise einen eigenen Primärschlüssel hat, seine Entität jedoch nur erstellt wird, wenn ein Buch verkauft wird

Referenz basierend auf Bill Karwin

0
sp1rs