Was sind identifying und non-identifying relationships?
Hallo,
ich beziehe mich auf den Archiv-Artikel, der ja unglücklicherweise als einer der vordersten in Google erscheint:
/t/non-identifying-relationship/2590343
Ich füge den Text mal hier neu ein:
„Der Unterschied ist der, daß in der non-identifying relationship die Datensätze in beiden Tabellen unabhängig voneinander existieren können (Beispiel: Schüler und Kurse einer Schuldatenbank: Sowohl die Schüler als auch die Kurse beinhalten vollständige Informationen; die Verknüpfung erfolgt z.B. über eine dritte Tabelle Kursbesuche), d.h. deren Primärschlüssel nicht bei der jeweils anderen Tabelle als Fremdschlüssel erscheinen.“
Die Erklärung ist einfach nur falsch. Es kommt nicht darauf an wie die beiden verküpften Tabellen zueinander stehen bzw. deren Entitäten. Das spielt gar keine Rolle.
Sancho betrachtet hier einen m:n-Spezialfall über eine sog. „join table“. Diese werden im relationalen Modell zu zwei 1:n Beziehungen (wie man weiß). Man kann eine solche „join table“ mit identifying *oder* non-identifying relationships realisieren:
Wenn man die foreign keys der beiden verknüpften Tabellen in der „join table“ auch als primary keys verwendet, dann sind die FK’s der „join table“ eben identifying, also identifizierend. Wenn man nur einen der FK’s im PK verwendet, dann ist eben nur der die eine relationship identifying.
Man kann aber auch einen künstlichen Schlüssel (simple ID) in der „join table“ einführen und die FK’s werden nur als Referenzen verwendet, aber nicht gleichzeitig als primary key. Das sind dann eben beide non-identifying relationships.
Identifying relationships sind also lediglich FK-PK-Überlagerungen!
„Anders die identifying relationship: dort beziht sich eine Tabelle auf eine Elterntabelle, ohne welche die Einträge keinen Sinn ergeben würden. Beispiel: Bestellung - Bestellposition; die Bestellpositionen beziehen sich immer auf eine Bestellung. Technisch erscheint der Primärschlüssel der Bestellung als Fremdschlüssel in der Tabelle Bestellposition.“
Der allgemeine Gebrauch von Eltern-Kind-Tabelle ist schon mal ungenau. Man sollte besser von referenzierter und referenzierender Tabelle sprechen. Das scheint eine schlechte Angewohnheit gerade auch von den MySQL/InnoDB Leuten zu sein, aber auch vielen anderen. Eltern-Kind bezieht sich normalerweise auf Baumstrukturen (Objekte, nicht Klassen usw.), da man bei einer relationship, also einem FK nicht automatisch von einer solchen ausgehen kann, nur weil die eine Tabelle die andere referenziert. Mit FK’s werden alle möglichen Beziehungstypen realisiert, Vererbung, Assoziation, Aggregation und Composition. Die Kardinalität (1:1, 1:n, m:n) ist dabei ebenfalls unerheblich.
Um zum Thema zurückzukommen: Wenn man die Bestellpositionen mit einem natürlichen Schlüssel implementiert, also PK auf die Bestellnummer (FK zu Tabelle Bestellungen) *und* eine einfache laufende Position (1, 2, 3, …) hinzufügt, dann haben wir eine identifying relationship zu Bestellungen, da dieser Teil des PK’s von Bestellposition ist.
Dasselbe können wir als non-identifying relationship implementieren, indem wir für die Bestellpositionen wieder eine dumme ID einführen und den FK zu Bestellungen nicht als PK verwenden sondern nur als Zuordnung zur Bestellung. Der FK wäre dann eben non-identifying.
Am besten Ihr holt Euch mal MySQL Workbench, da könnt ihr das tatsächlich auch ausprobieren. Die gestrichelten Linien sind dort non-identifying, die durchgezogenen identifying. Am besten ihr erstellt ein m:n relationship (per default ohne künstlichen Schlüssel, ist auch nicht nötig). Verändert diese Tabelle durch Einführung einer ID und lasst die FK’s nur referenzieren, also nicht als PK verwenden, dann werdet ihr sehen wie sich die durchgezogenen Linien zu gestrichelten verändern.
"
HTH
Sancho"
Ja hat insofern geholfen als dass es mich motiviert hat das Thema mal gründlichst aufzurollen und zu korrigieren…
Karsten
snip
Der allgemeine Gebrauch von Eltern-Kind-Tabelle ist schon mal
ungenau. Man sollte besser von referenzierter und
referenzierender Tabelle sprechen. Das scheint eine schlechte
Angewohnheit gerade auch von den MySQL/InnoDB Leuten zu sein,
aber auch vielen anderen. Eltern-Kind bezieht sich
normalerweise auf Baumstrukturen (Objekte, nicht Klassen
usw.), da man bei einer relationship, also einem FK nicht
automatisch von einer solchen ausgehen kann, nur weil die eine
Tabelle die andere referenziert. Mit FK’s werden alle
möglichen Beziehungstypen realisiert, Vererbung, Assoziation,
Aggregation und Composition. Die Kardinalität (1:1, 1:n, m:n)
ist dabei ebenfalls unerheblich.
Nachtrag:
Wenn man z.B. eine 1:1 relationship betrachtet, dann kann man das ja lösen, indem man die eine Tabelle die andere referenzieren lässt oder umgekehrt. Aber heißt das dann automatisch nur weil die andere Tabelle nun die eine referenziert, dass die Elterntabelle plötzlich die Kindtabelle wird und die Kindtabelle die Elterntabelle? Das ist einfach nur Unsinn.
Karsten
Moin, Karsten,
bei der identifying relationship besteht der Schlüssel des Child aus dem Schlüssel des Parent plus einer Ergänzung, bei der non-identifying ist der Child-Schlüssel unabhängig vom Parent-Schlüssel, dieser wird im Child als Nichtschlüsselattribut mitgeführt.
Gruß Ralf