Ich bin auf ein Datenbankdesignproblem gestoßen, das nicht in meiner Liga liegt, und mein DBA-Guru ist auf Feuerübungen.
Im Wesentlichen habe ich eine Tabelle mit dem folgenden Primärschlüssel (PK der Kürze halber):
child_id integer
parent_id integer
date datetimechild_idund parent_idsind Fremdschlüssel für Entitätstabellen. Die "untergeordnete" Tabelle selbst enthält auch einen Fremdschlüssel für die "übergeordnete" Tabelle, und siehe da, jeder child_idverweist immer auf den gleichen Wert, parent_idwie in der obigen Tabelle erwartet. Es stellt sich heraus, dass es einen zusätzlichen Code gibt, der die beiden synchron hält.
Was diesen überbegeisterten Normalisierungsanfänger dazu bringt, zu sagen: "Ich sollte stattdessen die Redundanz entfernen!"
Ich zerlege mich in folgendes:
Table_1 PK:
child_id integer
date datetime
Table_2 PK:
parent_id integer
date datetime
Table_3: (already exists)
child_id integer PRIMARY KEY
parent_id integer FOREIGN KEYUnd siehe da, wenn ich diese Leute auf natürliche Weise zusammenbringe, stelle ich den ursprünglichen Tisch wieder her. Es ist mein Verständnis, das diesen 5NF ausmacht.
Jetzt ist mir jedoch klar, dass es eine versteckte Geschäftsregel gibt.
Normalerweise müssen die mit einem bestimmten child_idDatum verknüpften Daten eine Teilmenge der mit dem entsprechenden Datum verknüpften Daten sein parent_id. Sie können sehen, dass die erste Tabelle diese Regel erzwingt.
Meine Zerlegung erzwingt die Regel nicht, da Sie Tabelle 1 frei hinzufügen können, bis die Daten zu groß werden.
Was mich hierher führt, mit folgenden Fragen:
Ist diese Zersetzung 5NF? Ich würde zwar sagen, dass es Einfügeanomalien zulässt, aber es scheint auch dem Wiki-Beispiel zu folgen, das selbst dieser Anleitung folgt . Der Satz (Hervorhebung von mir) "Wir können alle wahren Tatsachen aus einer normalisierten Form rekonstruieren, die aus drei getrennten Datensatztypen besteht" gibt mir eine besondere Pause, da
Table_1die natürliche Verbindung sie immer noch ignoriert , egal wie viel Müll ich hineinpumpe.Angenommen, ich mag diese Zerlegung nicht (ich nicht). Ich erkenne frei an, dass die praktische Lösung darin besteht, die Tabelle und den Code so zu belassen, wie sie sind. Aber gibt es theoretisch eine Möglichkeit, Einschränkungen so zu zerlegen und / oder hinzuzufügen, dass ich mich von der ersten Tabelle entferne und meine Geschäftsregeln behalte?