Implementieren einer Eins-zu-Null- oder Eins-Beziehung in SQL

Angenommen, ich entwerfe eine Datenbank für ein Szenario, in dem eine Eins-zu-Null-oder-Eins-Beziehung (1-0..1) besteht. Beispielsweise:

• Es gibt eine Reihe von Benutzern , und einige Benutzer können auch Kunden sein .

Also habe ich die beiden entsprechenden Tabellen erstellt usersund customers, aber ...

… Wie lässt sich diese Situation auf einer bestimmten SQL-Plattform am besten darstellen und implementieren? Ich habe zwei mögliche Lösungen in Betracht gezogen:

1. Fügen Sie in der usersTabelle die customerSpalte hinzu, auf die entweder ein FOREIGN KEY-Verweis customersoder eine NULLMarkierung verweisen kann .

2. Fügen Sie in die customersTabelle eine userSpalte (mit einer UNIQUEEinschränkung festgelegt) ein, die auf die usersTabelle verweist .

Ich habe bereits in einigen Foren eine ähnliche Frage gestellt, aber die Antwort lautete im Grunde "was auch immer Sie brauchen", "was auch immer Sie für zweckmäßig halten". Ich mag diese Art von Antwort nicht. Ich möchte stattdessen ein ernstes Stück DB-Theorie, eine fundierte Antwort. Wo kann ich über 1-0..1 Beziehungen lesen?

Ich möchte ein ernstes Stück DB-Theorie

Die moderne relationale Theorie lehnt Nullen ab , was Ihre Option 1 sofort ungültig zu machen scheint. Dieser Strohmann kann jedoch beseitigt werden, indem die Standardnull durch einen Standardwert ersetzt wird, z. B. ein "Dummy" -Kunde , der ausschließlich zur expliziten Modellierung des "ist kein Kunde" erstellt wurde. Korrespondenz.

Ich denke, Ihre Option 2 ist theoretisch am fundiertesten, da die Beziehungen im Gegensatz zur modifizierten Option 1 in der sechsten Normalform (6NF) vorliegen können, wobei es sich um eine Projektionsverbindungs-Normalform und die höchste erreichbare Normalform handelt.

Ich habe auch von einer Entwurfsregel gehört, die besagt, dass eine Beziehung WEDER eine Entität ODER die Beziehung zwischen Entitäten modellieren sollte, aber niemals beide, was mir vernünftig erscheint. Auch dies würde Option 2 begünstigen. Ich habe jedoch vor vielen Jahren von dieser Faustregel gehört, erinnere mich nicht, wo und kann keine ernsthafte theoretische Grundlage bieten (außer 6NF, wie oben erwähnt).

Sie haben teilweise die richtige Antwort erhalten. Die eigentliche Antwort kommt von Ihrem Datenmodell und wie es normalisiert wurde. Ein Schlüssel ist, wie Sie zur Beziehung gelangen:

• Die customersTabelle besteht aus einer Reihe von Feldern, die für die usersTabelle berücksichtigt wurden und zum Kundenkonzept gehören. Sie sind null, sofern der Benutzer nicht auch Kunde ist (Untertyp des Benutzers). In diesem Fall customerserbt die Tabelle den Primärschlüssel von der usersTabelle. (Es können mehrere Untertypen verwendet werden, die sich möglicherweise überschneiden oder nicht.)

• Die customersTabelle besteht aus einer Reihe von Feldern, die sich auf das Kundenkonzept beziehen, jedoch nicht unbedingt auf das Benutzerkonzept. Der Kunde ist ein starker Tisch und nicht vom Benutzerkonzept abhängig. (Das Entfernen der usersTabelle würde das Design der Kundentabelle nicht wesentlich beeinflussen.) In diesem Fall erhält die Kundentabelle einen eigenen Primärschlüssel.

Was Sie haben, ist ein Sonderfall einer optionalen Eins-zu-Viele-Beziehung, bei der die Obergrenze 1 ist. Betrachten Sie es von beiden Seiten: Wäre es möglich, dass ein Benutzer mehrere Kunden hat oder ein Kunde mehrere Benutzer hat? In diesem Fall müssen Sie Ihre Daten neu gestalten.

Das Hinzufügen des user-idFremdschlüssels zur customersTabelle kann als bessere Wahl angesehen werden, da die Beziehung von Eins zu Viele (Obergrenze 1) korrekt zugeordnet wird und ein nullbares Feld vermieden wird. Um die Obergrenze durchzusetzen, muss der Fremdschlüsselindex eindeutig sein. Dies geschieht automatisch, wenn der Primärschlüssel der ist user-id.

Durch Hinzufügen des customer-idoptionalen Fremdschlüssels zur usersTabelle wird die Obergrenze von 1 in der Beziehung erzwungen, die Abhängigkeit wird jedoch umgekehrt.

Haben Sie einen etwas komplexeren, aber flexibleren Ansatz in Betracht gezogen? Die übergeordnete Tabelle ist "Person" (oder "Entität", je nachdem, wie komplex Sie sein möchten). Dann haben die Kundentabelle und die Benutzertabelle jeweils eine FK zur Personentabelle. Die Personentabelle enthält persönliche Daten, während die Kunden- und Benutzertabellen nur Attribute enthalten, die einem Benutzer oder Kunden zugeordnet sind. Oft werden Adressen (E-Mail und Post), Telefonnummern usw. auch in separaten Tabellen mit Zuordnungstabellen dargestellt, um viele-zu-viele Situationen zu ermöglichen. Dies ist ein relativ verbreitetes Modell, das Sie auf einer Reihe von Referenzseiten finden.