Probleme der Entscheidung über die Identifizierung oder nicht-identifizierende Beziehung

Question

Ich habe diese Frage zu lesen: Was ist der Unterschied zwischen Identifizierung und nicht-identifizierende Beziehungen?

Aber ich bin immer noch nicht sicher ... Was ich habe, ist drei Tabellen.

1. Benutzer
2. Objekte
3. Bilder

Ein Benutzer kann viele Objekte besitzt und auch viele Bilder pro einzelnem Objekt veröffentlichen kann. Mein Bauchgefühl sagt mir, das ist eine identifizierende Beziehung, weil ich in den Objekten Tabelle, die die Benutzer-ID benötigen, und ich werde die objectID in den Bildern Tabellen muß ...

Oder bin ich falsch? Die Erläuterungen im anderen Thema beschränken sich auf die theoretische Erklärung der Art und Weise der Datenbank interpretiert nach ist es bereits codiert worden sind, nicht, wie die Objekte im wirklichen Leben verbunden. Ich bin ein bisschen verwirrt, wie die Entscheidung zu treffen im Vergleich zu Nicht-Identifizierung zu identifizieren, wenn darüber nachzudenken, wie ich werde die Datenbank erstellen.

Answer 1

Beide klingen wie Beziehungen zu mir zu identifizieren. Wenn Sie die Bedingungen gehört eine Eins-zu-eins oder eins-zu-viele und viele-zu-viele, one-to-Beziehungen sind Identifizierung Beziehungen und < strong> many-to-many-Beziehungen sind nicht-Identifizierung Beziehungen .

• Wenn das Kind seiner Eltern identifiziert, es ist eine Identifizierung Beziehung. In dem Link, den Sie gegeben haben, wenn Sie eine Telefonnummer haben, wissen Sie, wem es gehört (es gehört nur eins).

• Wenn das Kind nicht seine Eltern nicht identifizieren, es ist eine nicht-identifizierende Beziehung. In der Verbindung, erwähnt es Staaten. Denken Sie an einem Zustand als eine Zeile in einer Tabelle, die Stimmung. "Happy" nicht identifiziert eine bestimmte Person, aber viele Menschen.

Bearbeiten : Weitere Beispiele aus der Praxis:

• Eine physikalische Adresse ist eine nicht-identifizierende Beziehung, weil viele Menschen an einer Adresse befinden können. Auf der anderen Seite, ist eine E-Mail-Adresse (in der Regel betrachtet) eine identifizierende Beziehung.
• A Social Security Number ist eine identifizierende Beziehung, weil es nur zu einer Person gehört
• Kommentare auf Youtube Videos identifizieren Beziehungen, weil sie nur zu einem Video gehören.
• Ein Original eines Gemälde hat nur einen Besitzer (Identifizierung), während viele Menschen Reprints des Gemäldes besitzen können (nicht identifiziert).

Answer 2

Ich denke, dass ein einfacher Weg, um es sichtbar zu machen ist, sich zu fragen, ob das Kind aufnehmen, ohne die Eltern existieren kann. Zum Beispiel erfordert eine Auftragsposition einen Auftragskopf zu existieren. Somit muss eine Auftragsposition das Kennzeichen Auftragskopf als Teil seiner Schlüssel und daher ist dies ein Beispiel für eine Identifizierung Beziehung.
Auf der anderen Seite, Telefonnummern können ohne Besitz einer Person bestehen, obwohl eine Person mehrere Telefonnummern haben. In diesem Fall ist die Person, die Telefonnummer besitzt, ist eine nicht-Schlüssel oder nicht-identifizierende Beziehung, da die Telefonnummern unabhängig von dem Eigentümer Person existieren können (daher kann die Telefonnummer Eigentümer Person null sein, während in der Position Beispiel Auftragszeilen die Kennung Auftragskopf kann nicht null sein.

Answer 3

  

NickC Said: Eins-zu-Beziehungen identifizieren Beziehungen und viele-zu-viele-Beziehungen sind nicht-identifizierende Beziehungen

Die Erklärung scheint mir völlig falsch. Sie können haben:

• Ono-to-One Nicht-Identifizierung Beziehungen
• One-to-Many Nicht identifizieren Beziehungen
• One-to-One identifizieren Beziehungen
• One-to-Many identifizieren Beziehungen
• Many-to-Many identifizieren Beziehungen

Imagine haben Sie die folgenden Tabellen: customer, products und feedback. Alle von ihnen sind auf dem customer_id basiert, die auf der cutomer Tabelle existiert. Also, von NickC Definition sollte es nicht vorhanden ist, jede Art von Many-to-Many Identifizierung von Beziehungen, aber in meinem Beispiel kann man deutlich sehen, dass: Eine Bewertung kann besteht nur, wenn die relevant Produkt vorhanden ist und vom Kunden gekauft worden, so Kunde, Produkte und Feedback sollten sein identifizieren .

Sie können einen Blick auf MySQL-Handbuch und erklärt, wie Fremdschlüssel auf MySQL Workbench als auch hinzuzufügen.

Answer 4

Mahdi, Ihre Instinkte sind richtig. Dies ist eine doppelte Frage und diese Aufwärts gestimmt Antwort ist nicht richtig oder vollständig ist. Schauen Sie sich die beiden Top-Antworten hier: Differenz zwischen Identifizieren nicht-identifizierende

Die Identifizierung vs Nicht-Identifizierung hat nichts mit Identität zu tun. Einfach fragen kann sich das Kind aufnehmen, ohne die Eltern gibt es? Wenn die Antwort ja ist, die es ist nicht zu identifizieren.

Die Kernfrage, ob der Primärschlüssel des Kindes die Fremdschlüssel der Eltern enthält. In der nicht-identifizierende Beziehung kann das Kind die Primärschlüssel (PK) sind nicht mit dem Fremdschlüssel (FK).

Stellen Sie sich diese Frage

• Kann das Kind Datensatz vorhanden sind, ohne den übergeordneten Datensatz?

Wenn das Kind ohne Eltern existieren kann, dann ist die Beziehung nicht zu identifizieren. (Danke MontrealDevOne es deutliche Angabe)

One-to-one Identifizierung Beziehung

Sozialversicherungsnummern passen gut in dieser Kategorie. Lassen Sie sich zum Beispiel vorstellen, dass Sozialversicherungsnummern nicht aus einer Person bestehen können (vielleicht in Wirklichkeit sie können, aber nicht in unserer Datenbank) Die person_id würde die PK für die Mensch Tabelle, einschließlich Spalten wie zum Beispiel eine Name sein und Adresse . (Lass es einfach halten). Die social_security_number Tabelle würde die ssn Spalte und die person_id Spalte als Fremdschlüssel. Da diese FK kann als PK verwendet werden, die social_security_number Tabelle ist eine identifizierende Beziehung.

One-to-one nicht-identifizierende Beziehung

Bei einem großen Bürokomplex können Sie ein Büro Tabelle, die die Zimmernummern von Boden und Gebäudenummer mit einem PK enthält, und einen separaten Mitarbeiter Tabelle. Die Mitarbeitertabelle (Kind) eine FK, die die ist office_id Spalte von Büro Tabelle PK. Während jeder Mitarbeiter nur ein Büro und (für dieses Beispiel) nur jedes Büro hat einen Mitarbeiter ist dies ein nicht-identifizierende Beziehung seit Büros ohne Mitarbeiter existieren können, und Mitarbeiter können Büros oder Arbeiten auf dem Gebiet ändern.

One-to-many-Beziehungen

One-to-many-Beziehungen können, indem er die gleiche Frage leicht kategorisiert werden.

Many-to-many-Beziehungen

Viele-zu-viele Beziehungen sind immer Beziehungen zu identifizieren. Dies kann unlogisch erscheinen, aber mit mir tragen. Nehmen Sie zwei Tabellen libary und Bücher , jede Bibliothek viele Bücher hat, und eine Kopie von jedem Buch gibt es in vielen Bibliotheken.

Hier ist, was macht es und Identifizierung Beziehung: Um dies zu implementieren, müssen Sie eine Verknüpfung Tabelle mit zwei Spalten, die die Primärschlüssel jeder Tabelle sind. Rufen Sie die library_id Spalte und die ISBN Spalte. Diese neue Verknüpfungstabelle hat keinen separaten Primärschlüssel, aber warten Sie! Die Fremdschlüssel zu einem mehrspaltigen Primärschlüssel für die Verknüpfungstabelle, da doppelte Datensätze in der Verknüpfungstabelle bedeutungslos wäre. Die Links kann nicht mit aus den Eltern vorhanden sind; Daher ist dies eine Identifizierungs Beziehung. Ich weiß, igitt nicht wahr?

Die meiste Zeit die Art der Beziehung keine Rolle spielt.

Alles, was gesagt, in der Regel müssen Sie keine Sorge über die Sie haben. Nur ordnen Sie die richtigen Primär- und Fremdschlüssel zu jeder Tabelle und die Beziehung selbst entdecken.

EDIT: NicoleC , lese ich die Antwort verknüpft und es mit meinem nicht einverstanden ist. Ich nehme seinen Punkt überSSN und stimmen zu, dass ein schlechtes Beispiel ist. Ich werde versuchen, es ein weiteres deutlicheres Beispiel ausdenken. beginnen jedoch, wenn wir die Analogien immer brechen realen Analogien bei der Definition einer Datenbank Beziehung zu verwenden. Es spielt keine Rolle, ob ein SSN eine Person identifiziert, es darauf ankommt, ob Sie es als Fremdschlüssel verwendet wird.