it-swarm.com.de

Noch immer verwirrt über identifizierende und nicht identifizierende Beziehungen

Ich habe also gelesen, was Beziehungen zwischen Datenbanken und nicht identifizierenden Elementen in meinem Datenbankdesign betrifft, und einige der Antworten auf SO scheinen mir zu widersprechen. Hier sind die zwei Fragen, die ich mir anschaue:

  1. Was ist der Unterschied zwischen identifizierenden und nichtidentifizierenden Beziehungen
  2. Probleme bei der Entscheidung über die Identifizierung oder Nichtidentifizierung einer Beziehung

Bei der Beantwortung der wichtigsten Antworten aus jeder Frage bekomme ich zwei verschiedene Vorstellungen davon, was eine identifizierende Beziehung ist.

In der Antwort der ersten Frage heißt es, dass eine identifizierende Beziehung "eine Situation beschreibt, in der das Vorhandensein einer Zeile in der untergeordneten Tabelle von einer Zeile in der übergeordneten Tabelle abhängt". Ein Beispiel dafür ist: "Ein Autor kann viele Bücher schreiben (1-zu-n-Beziehung), aber ein Buch kann nicht ohne einen Autor existieren." Das macht für mich Sinn.

Wenn ich jedoch die Antwort auf Frage zwei lese, werde ich verwirrt, wenn es heißt: "Wenn ein Kind sein Elternteil identifiziert, handelt es sich um eine identifizierende Beziehung." Die Antwort gibt dann Beispiele wie Sozialversicherungsnummer (Identifizieren einer Person), eine Adresse jedoch nicht (da viele Menschen an einer Adresse wohnen können). Für mich klingt dies eher nach einem Fall der Entscheidung zwischen Primärschlüssel und Nicht-Primärschlüssel.

Mein eigenes Bauchgefühl (und weitere Untersuchungen auf anderen Websites) deuten darauf hin, dass die erste Frage und ihre Antwort richtig sind. Ich wollte es jedoch überprüfen, bevor ich fortfuhr, da ich nichts Falsches lernen möchte, da ich daran arbeite, das Datenbankdesign zu verstehen. Danke im Voraus.

69
JasCav

Die technische Definition einer identifizierenden Beziehung ist, dass der Fremdschlüssel eines Kindes Teil seines Primärschlüssels ist.

CREATE TABLE AuthoredBook (
  author_id INT NOT NULL,
  book_id INT NOT NULL,
  PRIMARY KEY (author_id, book_id),
  FOREIGN KEY (author_id) REFERENCES Authors(author_id),
  FOREIGN KEY (book_id) REFERENCES Books(book_id)
);

Sehen? book_id ist ein Fremdschlüssel, aber auch eine der Spalten im Primärschlüssel. Diese Tabelle hat also eine identifizierende Beziehung zu der referenzierten Tabelle Books. Ebenso hat es eine identifizierende Beziehung zu Authors.

Ein Kommentar zu einem YouTube-Video hat eine identifizierende Beziehung zum jeweiligen Video. Der video_id sollte Teil des Primärschlüssels der Comments-Tabelle sein.

CREATE TABLE Comments (
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  PRIMARY KEY (video_id, user_id, comment_dt),
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

Es ist möglicherweise schwer zu verstehen, da es heutzutage so üblich ist, anstelle eines zusammengesetzten Primärschlüssels nur einen seriellen Ersatzschlüssel zu verwenden:

CREATE TABLE Comments (
  comment_id SERIAL PRIMARY KEY,
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

Dies kann Fälle verdecken, in denen die Tabellen eine identifizierende Beziehung haben.

Ich würde nicht betrachten, dass SSN eine identifizierende Beziehung darstellt. Einige Leute existieren, haben aber keine SSN. Andere Personen können sich anmelden, um ein neues SSN zu erhalten. Das SSN ist also eigentlich nur ein Attribut und nicht Teil des Primärschlüssels der Person.


Re Kommentar von @Niels:

Wenn wir also anstelle eines zusammengesetzten Primärschlüssels einen Ersatzschlüssel verwenden, gibt es keinen nennenswerten Unterschied zwischen der Verwendung von identifizierenden oder nicht identifizierenden Beziehungen.

Das nehme ich an. Ich zögere, ja zu sagen, weil wir die logische Beziehung zwischen den Tabellen nicht mit einem Ersatzschlüssel geändert haben. Das heißt, Sie können immer noch keinen Kommentar abgeben, ohne auf ein vorhandenes Video zu verweisen. Das heißt aber nur, dass video_id NICHT NULL sein muss. Und der logische Aspekt ist für mich wirklich der Punkt, Beziehungen zu identifizieren.

Aber es gibt auch einen physischen Aspekt, Beziehungen zu identifizieren. Und das ist die Tatsache, dass die Fremdschlüsselspalte Teil des Primärschlüssels ist (der Primärschlüssel ist nicht notwendigerweise ein zusammengesetzter Schlüssel; es könnte sich um eine einzelne Spalte handeln, die sowohl der Primärschlüssel von Comments als auch der Fremdschlüssel der Videos-Tabelle ist , aber das bedeutet, dass Sie nur einen Kommentar pro Video speichern können.

Das Identifizieren von Beziehungen scheint nur für das Entity-Relationship-Diagramm wichtig zu sein. Dies kommt in GUI-Datenmodellierungswerkzeugen zum Tragen.

142
Bill Karwin

"da ich nichts falsch lernen will".

Nun, wenn Sie das wirklich meinen, dann können Sie aufhören, sich um ER-Fachwörter und Terminologie zu sorgen. Es ist ungenau, verwirrt, verwirrend, überhaupt nicht allgemein vereinbart und zum größten Teil irrelevant.

ER ist eine Reihe von Rechtecken und geraden Linien, die auf einem Blatt Papier gezeichnet sind. ER ist bewusst als Mittel zur informellen Modellierung gedacht. Als solches ist es ein wertvoller erster Schritt beim Datenbankdesign, aber es ist auch genau das: ein erster Schritt.

Nie wird ein ER-Diagramm der Genauigkeit, Genauigkeit und Vollständigkeit eines in D formell ausgeschriebenen Datenbankentwurfs so nahe kommen.

17
Erwin Smout

Identifizierende/nicht identifizierende Beziehungen sind Konzepte der ER-Modellierung. Eine Beziehung ist eine identifizierende, wenn sie durch einen Fremdschlüssel dargestellt wird, der Teil des Primärschlüssels der referenzierenden Tabelle ist. Dies ist in der relationalen Modellierung in der Regel von sehr geringer Bedeutung, da Primärschlüssel im relationalen Modell und in SQL-Datenbanken keine besondere Bedeutung oder Funktion haben wie in einem ER-Modell.

Angenommen, Ihre Tabelle erzwingt zwei Kandidatenschlüssel, A und B. Angenommen, A ist auch ein Fremdschlüssel in dieser Tabelle. Die auf diese Weise dargestellte Beziehung gilt als "identifizierend", wenn A als "Primärschlüssel" bezeichnet wird, nicht aber, wenn B der Primärschlüssel ist. Dabei sind Form, Funktion und Bedeutung der Tabelle jeweils identisch! Deshalb halte ich das Identifizieren/Nicht-Identifizieren nicht für sehr wichtig.

10
nvogel

Ich glaube, dass nur der Unterschied zwischen einer identifizierenden und einer nicht identifizierenden Beziehung in der Nichtigkeitsfähigkeit des Fremdschlüssels liegt. Wenn ein FK nicht NULL sein kann, ist die Beziehung, die es darstellt, eine Identifikation (das Kind kann nicht ohne Eltern existieren), andernfalls ist es keine Identifikation.

9
Pankaj Jha

teil des Problems ist hier die Verwirrung der Terminologie. identifizierende Beziehungen sind hilfreich, um lange Verknüpfungspfade zu vermeiden. 

Die beste Definition, die ich gesehen habe, ist "eine identifizierende Beziehung beinhaltet die PK des Elternteils in der Kind-PK. Mit anderen Worten schließt die PK des Kindes den FK zum Elternteil sowie die" tatsächliche "PK des Kindes ein. 

5
gnackenson

Ja, geh mit dem ersten, aber ich glaube nicht, dass das zweite dem ersten widerspricht. Es ist nur ein bisschen verwirrend formuliert ..

AKTUALISIEREN:

Nur geprüft - die Antwort der zweiten Frage ist in einigen Annahmen falsch. Buchautor muss nicht unbedingt eine 1: n-Relation sein, da es m: n sein könnte. In relationalen Datenbanken, die Schnitttabelle für diese m: n-Beziehung erstellen, werden Beziehungen zwischen Schnitttabelle und diesen beiden anderen Tabellen ermittelt.

1
marianboda

eine identifizierende Beziehung gibt eine bis viele optionale Beziehung aus, wenn eine Eltern-Kind-Beziehung definiert werden muss. Außerdem gibt es eine bis nur eine Beziehung von Kind zu Eltern-Fluss. Da der Primärschlüssel der Elterneinheit der Primärschlüssel der Kindeinheit ist, Die untergeordnete Entitätsinstanz identifiziert die übergeordnete Entität Instanz. Sie wird in einem Diagramm durch eine durchgehende Linie dargestellt.

für das Vorhandensein einer untergeordneten Entitätsinstanz sollte es eine übergeordnete Entitätsinstanz geben, aber jede Entitätsinstanz in der untergeordneten Entität kann mit vielen Entitätsinstanzen der übergeordneten Entität verknüpft sein. Dies ist der Grund, warum der Primärschlüssel von Die übergeordnete Entität ist zwar der Fremdschlüssel der untergeordneten Entität, aber die untergeordnete Entität nimmt nicht den Primärschlüssel der übergeordneten Entität als Primärschlüssel an. Sie wird ihren eigenen Primärschlüssel haben .. _. Viele bis viele Relationen sind im realen Er-Diagramm nicht vorhanden . also muss es gelöst werden

1
kumar

Eine identifizierende Beziehung ist in der Tat ein ERD-Konzept, da dies die Domäne der konzeptuellen Modellierung ist, die unser Verständnis des "Universums des Diskurses" modelliert. Es ist eine Eltern-Kind-Beziehung, bei der wir die Tatsache modellieren, dass die Identität jedes untergeordneten Objekts (zumindest teilweise) durch die Identität des übergeordneten Objekts festgelegt/bestimmt wird. Es ist daher zwingend und unveränderlich. 

Ein reales Beispiel ist die permanente Herausforderung, Menschen zu identifizieren. Die eindeutige Identität einer Person kann (teilweise) durch ihre Beziehung zu ihrer geborenen Mutter und ihrem Vater definiert werden. Wenn bekannt, sind dies unveränderliche Tatsachen. Daher ist die Beziehung zwischen dem geburten Elternteil und dem Kind eine identifizierende Beziehung, indem es (unveränderlich) zur Definition der Identität des Kindes beiträgt.

Diese Eigenschaften und die Verwendung relationaler Dbms-Konstrukte führen dazu, dass der PK des Kindes ein zusammengesetzter Schlüssel ist, der über FK den PK des Elternteils enthält. Als PK ist die Identität des Kindes obligatorisch und unveränderlich (es kann sich nicht ändern). Eine "Änderung" in einem PK instanziiert tatsächlich ein neues Objekt. Daher darf die PK nicht geändert werden. Die Unveränderlichkeit einer PK sollte ebenfalls eingeschränkt sein. DB-Einschränkungen können verwendet werden, um diese Qualität von PKs zu implementieren.

0
Russell Searle