Betrachten Sie eine Datenbank mit den Tabellen Produkte und Mitarbeiter. Es gibt eine neue Anforderung, aktuelle Produktmanager zu modellieren, da sie der einzige Mitarbeiter sind, der für ein Produkt verantwortlich ist. Einige Produkte sind einfach oder ausgereift genug, um keinen Produktmanager zu benötigen. Das heißt, jedes Produkt kann null oder einen Produktmanager haben.
Ansatz 1: Ändern Sie die Tabelle Product , um eine neue NULL fähige Spalte product_manager_employee_ID hinzuzufügen, sodass ein Produkt ohne Produktmanager durch den Wert NULL modelliert wird.
Ansatz 2: Erstellen Sie eine neue Tabelle ProductManagers mit nicht NULL fähigen Spalten product_ID und employee_ID mit einer eindeutigen Einschränkung für product_ID , so dass ein Produkt ohne Produktmanager von der Fehlen einer Zeile in dieser Tabelle.
Es gibt andere Ansätze, aber diese beiden scheinen mir am häufigsten zu begegnen.
Unter der Annahme, dass beide legitime Design-Entscheidungen sind (wie ich geneigt bin zu glauben) und nur verschiedene Stile repräsentieren, haben sie Namen? Ich bevorzuge Ansatz 2 und finde es schwierig, den Unterschied im Stil zu jemandem zu vermitteln, der Ansatz 1 bevorzugt, ohne ein tatsächliches Beispiel zu verwenden (wie ich es hier getan habe!) Ich wäre nett, wenn ich sagen könnte: "Ich bevorzuge die Neigung-zu-6NF (oder was auch immer) Stil selbst. "
Unter der Annahme, dass einer dieser Ansätze tatsächlich ein Anti-Pattern ist (da ich vermute, dass dies für Ansatz 1 der Fall sein kann, indem eine Beziehung zwischen zwei Entitäten als Attribut einer dieser Entitäten modelliert wird), hat dieses Anti-Pattern a Name?
Nun, der erste ist nichts anderes als eine Eins-zu-viele-Beziehung (ein Mitarbeiter zu vielen Produkten). Dies wird manchmal als O: M-Beziehung bezeichnet (null zu viele), weil es optional ist (nicht jedes Produkt hat einen Produktmanager). Auch ist nicht jeder Mitarbeiter ein Produktmanager, also ist es auch auf der anderen Seite optional.
Die zweite ist eine Join-Tabelle, die normalerweise für eine Viele-zu-Viele-Beziehung verwendet wird. Aber da eine Seite nur eins zu eins ist (jedes Produkt ist nur einmal in der Tabelle), ist es wirklich nur eine verschachtelte Eins-zu-Viele-Beziehung.
Persönlich bevorzuge ich den ersten, aber keiner ist falsch (oder schlecht).
Der zweite würde aus zwei Gründen verwendet werden, die in den Sinn kommen.
Es sieht für mich wie das zwei verschiedene Verhalten des Modells aus. Im ersten Beispiel können Sie einen Produktmanager pro Produkt haben und ein Mitarbeiter kann Produktmanager für mehr als ein Produkt sein (eins zu viele). Die zweite scheint mehr als einen Produktmanager pro Produkt zuzulassen (viele zu viele). Dies würde darauf hindeuten, dass die beiden Lösungen in verschiedenen Situationen gleichermaßen gültig sind und welche Sie von der Geschäftsregel abhängig machen würden.
Es gibt einen Fehler in der ersten Annäherung. Stellen Sie sich eine Sekunde vor, dass sich die Geschäftsanforderungen geändert haben und Sie nun in der Lage sein müssen, 2 Product Manager auf ein Produkt zu setzen. Was wirst du machen? Hinzufügen einer weiteren Spalte zur Tabelle Produkt? Jawohl. Dies verstößt offensichtlich gegen 1NF.
Eine weitere Möglichkeit, die der zweite Ansatz bietet, ist die Möglichkeit, einige Attribute für einen bestimmten Produktmanager zu speichern. & lt; - & gt; Produktbeziehung. Wenn Sie beispielsweise zwei Produktmanager für ein Produkt haben, können Sie eines davon als primären ... Oder, zum Beispiel, ein Mitarbeiter kann eine Telefonnummer haben, aber als Produktmanager kann er / sie eine andere Telefonnummer haben ... Das geht dann auch in die spezielle Tabelle.
Ansatz 1)
Ansatz 2)
Wie oft müssen Sie die Tabellen verknüpfen?
Wie viele andere Abfragen verwenden die Produkttabelle?
Wie viele Datensätze in der Produkttabelle?
In dem speziellen Fall, den Sie geben, denke ich, dass die Hauptmotivation für zwei Tabellen darin besteht, Nullen für fehlende Daten zu vermeiden, und so würde ich die beiden Ansätze charakterisieren.
Es gibt eine Diskussion über die Vor- und Nachteile auf Wikipedia .
Ich bin mir ziemlich sicher, dass er die Relationstheorie definiert, so dass nur die Lösung mit mehreren Tabellen "gültig" ist. Zum Beispiel könnten Sie den Single-Table-Ansatz "schlecht typisiert" aufrufen (da der Typ von Null unklar - siehe Zitat auf S.4).
Tags und Links sql design-patterns database-design anti-patterns