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?

• Eine identifizierende Beziehung liegt vor, 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 Pseudokey für eine untergeordnete Tabelle zu erstellen , den Fremdschlüssel jedoch nicht zum übergeordneten Teil des Primärschlüssels des Kindes zu machen. Formal ist der "richtige" Weg, dies zu tun, den Fremdschlüssel zum Primärschlüssel des Kindes zu machen. Die logische Beziehung ist jedoch, dass das Kind ohne das Elternteil nicht existieren kann.

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

  Wir können uns die Telefonnummer (n) als zu einer Person gehörend vorstellen, obwohl 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 sie nicht buchstäblich person_idin den Primärschlüssel von aufnehmen PhoneNumbers).

• Eine nicht identifizierende Beziehung liegt vor, wenn die Primärschlüsselattribute des übergeordneten Elements nicht zu Primärschlüsselattributen des untergeordneten Elements werden dürfen. Ein gutes Beispiel hierfür ist eine Nachschlagetabelle, z. B. ein Fremdschlüssel zum Person.stateVerweisen auf den Primärschlüssel von States.state. Personist eine untergeordnete Tabelle in Bezug auf States. Eine Zeile in Personwird jedoch nicht durch ihr stateAttribut identifiziert . Dh stateist nicht Teil des Primärschlüssels von Person.

  Eine nicht identifizierende Beziehung kann optional oder obligatorisch sein. Dies bedeutet, dass die Fremdschlüsselspalte NULL zulässt oder NULL nicht zulässt.

Siehe auch meine Antwort auf Immer noch verwirrt über das Identifizieren und Nicht-Identifizieren von Beziehungen

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

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

Ein Buch wurde jedoch von einem Autor geschrieben, und der Autor hätte mehrere Bücher schreiben können. 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.

Bills Antwort ist richtig, aber es ist schockierend zu sehen, dass unter all den anderen Antworten niemand auf den wichtigsten Aspekt hinweist.

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

Also hier ist der wahre Grund:

Der Zweck einer identifizierenden Beziehung besteht darin, dass sich der Fremdschlüssel NIE ÄNDERN kann , da er Teil des Primärschlüssels ist ... daher identifizierend !!!

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

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

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

Hier ist eine gute Beschreibung:

Beziehungen zwischen zwei Entitäten können entweder als "identifizierend" oder als "nicht identifizierend" klassifiziert werden. Identifizierende Beziehungen liegen vor, wenn der Primärschlüssel der übergeordneten Entität im Primärschlüssel der untergeordneten Entität enthalten ist. Andererseits liegt eine nicht identifizierende Beziehung vor, 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 entweder "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
Name

Hier ist eine entsprechende nicht identifizierende Beziehung:

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

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

Die Antwort von user287724 enthält das folgende Beispiel für die Beziehung zwischen Buch und Autor:

Ein Buch wurde jedoch von einem Autor geschrieben, und der Autor hätte mehrere Bücher schreiben können. 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 definitiv kein gültiges Beispiel für eine identifying relationship.

Ja, bookkann nicht ohne mindestens einen geschrieben werden author, aber der author(es ist Fremdschlüssel) der bookist NICHT ERKENNEN die bookin der booksTabelle!

Sie können die entfernen author(FK) aus der bookReihe und immer noch das Buch Zeile von einem anderen Feld identifizieren kann ( ISBN, ID, ... etc), aber nicht der Autor des Buchs !!

Ich denke, ein gültiges Beispiel für a identifying relationshipwäre die Beziehung zwischen (Produkttabelle) und a (spezifische 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 Product_IDin der printers_detailsTabelle davon ausgegangen, dass ein FK auf die products.idTabelle verweist und AUCH ein PK in der printers_detailsTabelle. Dies ist eine identifizierende Beziehung, da der Product_ID(FK) in der Druckertabelle die Zeile in der untergeordneten Tabelle identifiziert , die wir nicht entfernen können die product_idaus der untergeordneten Tabelle, weil wir die Zeile nicht mehr identifizieren können, weil wir ihren 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 Kennung) 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 Exportdatei für eine Länderdatenbank haben

Die importTabelle ist das Kind, das diese Felder (die product_id(FK), die country_id(FK), die Menge der Importe, den Preis, die importierten Einheiten, die Transportart (Luft, Meer)) we may use the (product_id , thecountry_id`) hat, um sie zu identifizieren Zeile der Importe "wenn sie alle im selben Jahr sind" hier können die beiden Spalten zusammen einen Primärschlüssel in der untergeordneten Tabelle (Importe) zusammenstellen und dort auch auf übergeordnete Tabellen verweisen.

Bitte ich bin froh, dass ich endlich das Konzept des identifying relationshipund verstehe non identifying relationship, also sag mir bitte nicht, dass ich mit all diesen Abstimmungen für ein völlig ungültiges Beispiel falsch liege

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 Buchzeile entfernen und trotzdem das Buch identifizieren! .

Nicht identifizierende Beziehung

Eine nicht identifizierende Beziehung bedeutet, dass ein Kind mit dem Elternteil verwandt ist, aber durch seine eigene identifiziert werden kann.

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

Die Beziehung zwischen ACCOUNT und PERSON ist nicht identifizierbar.

Beziehung identifizieren

Eine identifizierende Beziehung bedeutet, dass der Elternteil benötigt wird, um dem Kind Identität zu geben. 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.

Wenn Sie der Meinung sind, dass das untergeordnete Element beim Löschen des übergeordneten Elements gelöscht werden sollte, 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 Schulungsdatenbank mit Auszubildenden, Schulungen, Diplomen und Schulungen:

• Die Auszubildenden haben eine identifizierende Beziehung zu Schulungen
• Schulungen haben eine identifizierende Beziehung zu Schulungen
• Die Auszubildenden 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.

Die identifizierende Beziehung bedeutet, dass die untergeordnete Entität vollständig von der Existenz der übergeordneten Entität abhängt. Beispiel für eine Kontotabelle Personentabelle und Personenkonto. Die Personenkontotabelle wird nur durch das Vorhandensein eines Kontos und einer Personentabelle identifiziert.

Die nicht identifizierende Beziehung bedeutet, dass die untergeordnete Tabelle nicht durch das Vorhandensein der übergeordneten Tabelle identifiziert wird. Beispiel: Es gibt eine Tabelle als Kontotyp und die Tabelle account.accounttype wird nicht mit der Existenz der Kontotabelle identifiziert.

Wie im folgenden Link ausführlich erläutert, ähnelt eine identifizierende Beziehung in gewisser Weise 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. Die Art der Beziehungen ist: Identifizieren, Nicht-Identifizieren und Nicht-Spezifisch.

Identifizierende Beziehungen sind Eltern / Kind-Beziehungen, bei denen das Kind eine Art schwache Entität ist (selbst beim traditionellen ER-Modell wird es als identifizierende Beziehung bezeichnet), die keinen echten Primärschlüssel durch ihre eigenen Attribute hat und daher nicht eindeutig durch ihre eigenen identifiziert werden kann . Jeder Zugriff auf die untergeordnete Tabelle im physischen Modell hängt (einschließlich semantisch) vom Primärschlüssel des Elternteils ab, der sich in einen Teil oder die Gesamtheit des Primärschlüssels des Kindes (auch ein Fremdschlüssel) verwandelt, 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 Beziehungen (teilweise oder vollständig) vollständig unabhängiger Entitätssätze, deren Instanzen nicht davon abhängen, dass die Primärschlüssel der anderen eindeutig identifiziert werden, obwohl sie möglicherweise Fremdschlüssel für teilweise oder vollständige Beziehungen benötigen, jedoch nicht als Primärschlüssel des Kindes. Das Kind hat einen eigenen Primärschlüssel. Das übergeordnete IDEM. Beides unabhängig voneinander. Abhängig von der Kardinalität der Beziehung geht die PK von einer als FK zur anderen (N-Seite) und kann, wenn sie partiell ist, null sein, wenn sie total ist, darf sie nicht null sein. In einer solchen Beziehung wird die FK jedoch niemals auch die PK des Kindes sein, wie dies der Fall ist, wenn eine identifizierende Beziehung der Fall ist.

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

Helfen von Eltern zu Kind migrierte Attribute dabei , ¹ das Kind zu identifizieren ?

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

Beachten Sie, dass Identifikationsabhängigkeit Existenzabhängigkeit impliziert, aber nicht umgekehrt. Jeder Nicht-NULL-FK bedeutet, dass ein Kind ohne Eltern nicht existieren kann, aber das allein macht die Beziehung nicht identifizierbar.

Weitere Informationen hierzu (und einige Beispiele) finden Sie im Abschnitt "Identifizieren von Beziehungen" des ERwin-Methodenhandbuchs .

PS Mir ist klar, dass ich (extrem) zu spät zur Party komme, aber ich bin der Meinung, dass andere Antworten entweder nicht ganz richtig sind (Definition als Existenzabhängigkeit statt Identifikationsabhängigkeit) oder sich etwas schlängeln. Hoffentlich bietet diese Antwort mehr Klarheit ...

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

Ein gutes Beispiel ist die Auftragsabwicklung. Eine Bestellung eines Kunden hat normalerweise eine Bestellnummer, die die Bestellung identifiziert, einige Daten, die einmal pro Bestellung auftreten, wie das Bestelldatum und die Kunden-ID, sowie 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, der durch Multiplikation der Menge mit dem berechnet werden kann Preis.

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

Die übergeordnete untergeordnete Beziehung zwischen Bestellungen und Werbebuchungen ist daher eine identifizierende Beziehung. Ein eng verwandtes Konzept in der ER-Modellierung trägt den Namen "Subentität", wobei die Werbebuchung eine Subentität der Ordnung ist. In der Regel hat 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 Artikel eine separate ItemID geben, die als Primärschlüssel dient und vom DBMS automatisch inkrementiert wird. In diesem Fall empfehle ich klassisches Design.

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. Weil Kommentare nur seinem 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.

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 eine Situation geben, in der ein Kind selbst einen Primärschlüssel hat, die Existenz seiner Entität jedoch von seiner übergeordneten Entität abhängen kann.

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