Ich habe die Unterschiede noch nicht ganz begriffen. Können Sie beide Konzepte beschreiben und Beispiele aus der Praxis anführen?
Eine identifizierende Beziehung ist, wenn die Existenz einer Zeile in einer untergeordneten Tabelle von einer Zeile in einer übergeordneten Tabelle abhängt. Dies mag verwirrend sein, weil es heutzutage üblich ist, einen Pseudoschlüssel für eine untergeordnete Tabelle zu erstellen, aber no den Fremdschlüssel zum übergeordneten Schlüssel zu einem Teil des Primärschlüssels des untergeordneten Schlüssels machen. Formal gesehen ist es der "richtige" Weg, den Fremdschlüssel zum Teil des Primärschlüssels des Kindes zu machen. Die logische Beziehung ist jedoch, dass das Kind nicht ohne das Elternteil existieren kann.
Beispiel: A Person hat eine oder mehrere Telefonnummern. Hätten sie nur eine Telefonnummer, könnten wir sie einfach in einer Spalte von Person . Da wir mehrere Telefonnummern unterstützen wollen, erstellen wir eine zweite Tabelle PhoneNumbers , dessen Primärschlüssel die person_id mit Verweis auf die Person Tisch.
Wir können uns die Telefonnummer(n) als zu einer Person gehörig vorstellen, auch wenn sie als Attribute einer separaten Tabelle modelliert sind. Dies ist ein starker Hinweis darauf, dass es sich um eine identifizierende Beziehung handelt (auch wenn wir nicht wörtlich die person_id im Primärschlüssel von PhoneNumbers ).
A nicht identifizierende Beziehung ist, wenn die Primärschlüsselattribute der übergeordneten darf nicht werden zu Primärschlüsselattributen des Kindes. Ein gutes Beispiel hierfür ist eine Nachschlagetabelle, wie z.B. ein Fremdschlüssel auf Person.state referenziert den Primärschlüssel von States.state . Person ist eine untergeordnete Tabelle in Bezug auf States . Aber ein Streit in Person wird nicht durch seine state zuordnen. D.h. state ist nicht Teil des Primärschlüssels von Person .
Eine nicht identifizierende Beziehung kann sein optional o obligatorisch , was bedeutet, dass die Fremdschlüsselspalte NULL zulässt bzw. NULL verbietet.
Siehe auch meine Antwort auf Immer noch verwirrt über identifizierende vs. nicht-identifizierende Beziehungen
+1: Bill, "es ist heutzutage gängige Praxis, einen Pseudoschlüssel für eine untergeordnete Tabelle zu erstellen, aber den Fremdschlüssel zur übergeordneten Tabelle nicht zum Primärschlüssel der untergeordneten Tabelle zu machen" - irgendwelche Links, warum das so ist? Google lässt mich im Stich.
@hobodave: Das ist das Argument "Konvention vor Konfiguration". Einige Denkansätze sind, dass jede Tabelle ihren Primärschlüssel für einen einspaltigen Pseudoschlüssel namens id die ihre Werte automatisch generiert. Anwendungsframeworks wie Rails haben dies als Voreinstellung populär gemacht. Sie behandeln natürliche Schlüssel und mehrspaltige Schlüssel als abweichend von ihren Konventionen, die bei der Verwendung von "Legacy"-Datenbanken erforderlich sind. Viele andere Frameworks sind diesem Beispiel gefolgt.
Es scheint, als würde die "richtige" Konstruktion von Identifizierungsbeziehungen zu unerträglich großen Primärschlüsseln führen, z. B. Gebäude hat Etage hat Zimmer hat Bett. Der PK für Bett wäre (bed_id, floor_id, room_id, building_id). Seltsamerweise habe ich das in der Praxis noch nie gesehen und auch noch nie gehört, dass es als Möglichkeit vorgeschlagen wurde, etwas zu tun. Das sind eine Menge redundanter Daten in der PK.
Es gibt eine weitere 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 aber auch ohne den Besitzer existieren, und der Besitz kann von einem Besitzer 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. 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.
Eine gute Erklärung, aber ich glaube, es ist auch lehrreich, das Beispiel ein wenig zu erweitern. Ein Buch hat eine Anzahl von Seiten. Es kann nicht ohne Seiten existieren, und daher könnten wir zu dem Schluss kommen, dass die Beziehung zwischen einem Buch und der Anzahl seiner Seiten auch eine identifizierende Beziehung ist. Aber wird das Attribut "Anzahl der Seiten" Teil eines Identifikationsschemas (Schlüssel) für das Buch sein? Wahrscheinlich nicht. Der Begriff "identifizierende Beziehung" ist normalerweise für Beziehungen reserviert, die Identifizierung Eigenschaften - prime Attribute in relationalen Begriffen.
Was passiert, wenn das Buch von mehr als einem Autor geschrieben wurde? Die Beziehung wird nicht mehr als M:N-Typ identifiziert, warum?
Diese realen Beispiele sind nutzlos. Wenn Sie erkennen, wie Sie Tabellen in ER erstellen und wie die Datenintegrität gewährleistet wird, können Sie diese Beispiele wegwerfen. Wenn Sie eine starke Beziehung zwischen zwei Entitäten erstellen, sind Sie gezwungen, einen Primärschlüssel in der Tabelle der Entität in Kombination mit einem PK der anderen Entität zu erstellen. Wenn Ihr Modell zulässt, dass das gleiche Buch mehrere Autoren haben kann, dann ist es in Ordnung, eine starke Beziehung zu erstellen. Wenn Ihr Modell jedoch nur 1 Autor für 1 Buch zulässt, können Sie diese Einschränkung nicht durch eine starke Beziehung erreichen, da PK(Book.id, Book.person_id) .
Bills Antwort richtig ist, aber es ist schockierend zu sehen dass unter all den anderen Antworten niemand auf den wichtigsten Aspekt hinweist.
Es ist immer wieder gesagt worden, dass in einer identifizierenden Beziehung das Kind nicht ohne den Elternteil existieren kann. (z.B.. Benutzer287724 ). Das ist zwar richtig, geht aber völlig am Thema vorbei. Es würde reichen, wenn der Fremdschlüssel Nicht-Null um dies zu erreichen. Er muss nicht Teil des Primärschlüssels sein.
Hier ist also der wahre Grund:
Der Zweck einer identifizierenden Beziehung ist, dass der Fremdschlüssel kann sich NIE ÄNDERN , da er Teil des Primärschlüssels ist... daher identifizierend!!!
+1 für "Es würde ausreichen, dass der Fremdschlüssel nicht null ist, um dies zu erreichen." Es sollte ausreichen, aber leider nicht, wenn es um etwas wie Entity Framework geht, das nicht richtig funktioniert, es sei denn, Sie verwenden eine identifizierende Beziehung, aber dann verliert das "Id"-Feld einer Entität seine Einzigartigkeit, da es nur ein Teil eines zusammengesetzten Schlüssels ist.
Eine identifizierende Beziehung legt fest, dass ein untergeordnetes Objekt nicht ohne das übergeordnete Objekt existieren kann
Nicht-identifizierende Beziehungen geben eine regelmäßige Assoziation an zwischen Objekten, 1:1 oder 1:n Kardinalität.
Nicht-identifizierende Beziehungen können als optional angegeben werden, wenn ein Elternteil nicht oder obligatorisch, wenn ein Elternteil erforderlich ist, indem man die Kardinalität der übergeordneten Tabelle...
Das klingt eher nach einer Beschreibung der totalen Beteiligung an einer Beziehung als nach einer identifizierenden Beziehung.
Ich bin mit den oben genannten Definitionen nicht einverstanden. Sie können ein Objekt haben, das von seiner übergeordneten Zeile abhängt, und Sie möchten, dass dieses Objekt nur mit einer übergeordneten Zeile verknüpft wird. A House tiene Wall s. Wenn du ein Haus entfernst, hast du keine Wände mehr. Aber eine Wand gehört nur zu einem Haus. Eine starke Beziehung wird also nicht funktionieren: PK(Wall.id, House.id) ermöglicht es Ihnen, in das Modell die gleiche Wand zu einem anderen Haus einzufügen.
Der Grund dafür, dass die House_Wall Tabelle ist die Kennzeichnung einer Mauer innerhalb eines Hauses. Es ist die identifizierende Beziehung. Die Tabelle Haus_Wand ist wie PK(House.id, wall_number), FK(Wall.id) . Die wall_number ist eine Sequenz in einem Haus und ohne House.id nicht eindeutig. Wenn Sie modellieren wollen wie PK(Wall.id, House.id) und Wall.id muss eindeutig sein, dann reicht es aus, House.id in der Tabelle Wall als FK zu haben. Es wird nur versucht, verschiedene Dinge zu modellieren.
Hier ist eine gute Beschreibung:
Beziehungen zwischen zwei Entitäten können entweder als "identifizierend" oder als "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. Eine nicht-identifizierende Beziehung liegt hingegen vor, wenn der Primärschlüssel der übergeordneten Entität zwar in der untergeordneten Entität enthalten ist, aber 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 besteht, 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
NameHier ist eine entsprechende nicht-identifizierende Beziehung:
Parent
------
ID (PK)
Name
Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name
Ihre Antwort steht im Widerspruch zu der von Bill Karwin gegebenen, und zwar in Bezug auf den Unterschied, ob der Fremdschlüssel "nicht" oder "nicht" Teil des Primärschlüssels in der Child-Zeile sein muss.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
2 Stimmen
Gute Frage, das Rad muss nicht neu erfunden werden: Peter Chen. Das Entity-Relationship-Modell, Auf dem Weg zu einer einheitlichen Sicht auf Daten, 1976 § 2.3.2: " Wenn Beziehungen zur Identifizierung der Entitäten verwendet werden, sprechen wir von einer schwachen Entitätsbeziehung. Wenn keine Beziehungen zur Identifizierung der Entitäten verwendet werden, sprechen wir von einer regulären Entitätsbeziehung. ". Die Frage der OP läuft auf Folgendes hinaus: Was sind schwache/regelmäßige Entitätsbeziehungen? .