Vom ER-Modell zum Datenbankschema

Das ist kein Strohmann - es ist die Form, die eine Tabellenkalkulation hat, und mit einer Tabellenkalkulation fangen die meisten Schemata an. Es lohnt sich, genau zu benennen, was daran falsch ist, denn "sie ist nicht normalisiert" erklärt nichts:

Was folgt, ist Datenbankschema-Modellierung im ganz gewöhnlichen Sinn: entscheiden, welche Tabellen es gibt, welche Spalte eine Zeile identifiziert und wo eine Tatsache wohnen darf. Es ist der Schritt zwischen einem ER-Diagramm und DDL, das eine Datenbank annimmt, und er lohnt sich auf Papier, weil jede dieser Entscheidungen teuer rückgängig zu machen ist, sobald Daten in der Tabelle stehen.

1. Sie können keinen Kunden speichern, der nichts bestellt hat. Der Kunde existiert nur als Spalten auf einer Bestellung.
2. Eine E-Mail zu korrigieren heißt, jede Zeile zu ändern, auf der dieser Kunde vorkommt - und eine übersehene Zeile lässt die Datenbank zwei verschiedene Antworten halten.
3. Die letzte Bestellung zu löschen löscht den Kunden. Information verschwindet als Nebenwirkung von etwas Unverwandtem.
4. product_names enthält eine Liste. Ab jetzt zerlegt jede Abfrage, die ein einzelnes Produkt braucht, eine Zeichenkette, und kein Index kann helfen.
5. total kann den Positionen widersprechen, deren Summe es sein soll.

Diese fünf haben Namen - Einfüge-, Änderungs- und Löschanomalie, eine Wiederholungsgruppe und ein abgeleiteter Wert - und Normalisierung ist schlicht das Verfahren, das sie beseitigt.

Alles Weitere hängt davon ab, also kommt es vor den Tabellen. Ein Primärschlüssel muss eindeutig sein, nie null und sich nie ändern. Die dritte Bedingung ist die, die die meisten Kandidaten ausscheidet.

Es gibt sechs Normalformen und Sie brauchen drei. Jede ist eine einzige Frage an eine Tabelle, und die Antwort "nein" sagt Ihnen, welche Spalte wohin gehört.

Schicken Sie die flache Tabelle hindurch. 1NF spaltet product_names und quantities in eine order_lines-Tabelle auf, eine Zeile je Produkt. 2NF bemerkt, dass Name und Preis eines Produkts nur am Produkt hängen, also erscheint products. 3NF bemerkt, dass Kundenname und E-Mail am Kunden hängen statt an der Bestellung, also erscheint customers. Vier Tabellen, also genau das Titeldiagramm - und kein Schritt verlangte ein Urteil, nur die Frage.

Die Spalte total in der flachen Tabelle ist ein anderes Problem als die übrigen vier: sie steht nicht am falschen Ort, sie ist redundant. Sie lässt sich aus den Bestellpositionen berechnen, kann ihnen also widersprechen - und wird es irgendwann.

Drei legitime Antworten, nach Vorzug geordnet: in der Abfrage berechnen; in einer Sicht berechnen; speichern und die Datenbank pflegen lassen - eine generierte Spalte, eine materialisierte Sicht oder ein Trigger. Nicht legitim ist, sie zu speichern und darauf zu bauen, dass Anwendungscode ans Aktualisieren denkt; das ist die Variante, die Rechnungen erzeugt, die nicht aufgehen.

Ein ER-Modell kann einen Obertyp mit Untertypen ausdrücken; eine relationale Datenbank hat kein solches Konstrukt, also muss das physische Modell eines von drei Layouts wählen. Alle drei sind weit verbreitet und die Wahl ist ein echter Tausch.

Eine grobe Regel: wenige Untertypen mit überwiegend gemeinsamen Spalten sprechen für eine Tabelle; viele Untertypen mit auseinanderlaufenden Spalten und echten Bedingungen sprechen für Tabelle je Untertyp; und Untertypen, die nie zusammen abgefragt werden, sprechen für getrennte Tabellen. Das Klassendiagramm derselben Domäne hat die Vererbung meist gewählt, ohne irgendetwas davon zu betrachten - und genau deshalb dürfen die beiden Modelle hier voneinander abweichen.

Ein logisches ER-Modell bildet sich fast mechanisch auf DDL ab, was der Lohn dafür ist, es ordentlich gezeichnet zu haben:

Zwei Dinge, die das Diagramm nicht sagt und das DDL entscheiden muss: was beim Löschen passiert (CASCADE bei einer identifizierenden Beziehung, RESTRICT bei fast allem anderen) und welche Spalten über die Schlüssel hinaus Indizes bekommen. Beides sind Entscheidungen über Verhalten und Last, nicht über das Modell, und beides schreibt man besser neben das Schema, als es später im Log langsamer Abfragen zu entdecken.

1. Über den Punkt der Nützlichkeit hinaus normalisieren. 3NF ist das Ziel für ein transaktionales Schema. Eine Tabelle zu spalten, weil sich eine Spalte vielleicht eines Tages wiederholt, bringt nichts und kostet für immer einen Join.
2. Keine Fremdschlüssel, "wegen der Performance". Der Preis ist ein Indexzugriff beim Schreiben; der Nutzen ist, dass verwaiste Zeilen unmöglich werden. Fast nie der richtige Tausch.
3. Nullbare Spalten als Ersatz für eine fehlende Tabelle. Sechs Spalten, die nur für eine Art von Zeile gefüllt sind, sind ein Untertyp, der eine eigene Tabelle will.
4. status als freier Text. Schränken Sie ihn ein - eine Check-Bedingung, ein Enum oder eine Nachschlagetabelle - sonst enthält er binnen eines Jahres shipped, Shipped und SHIPPED.
5. Zeitstempel ohne Zeitzone. Genau einmal richtig, in einem Büro, bis der erste Server umzieht.
6. Das nach der ersten Migration zurückgelassene Diagramm. Ein Schemadiagramm, das der Datenbank widerspricht, ist schlimmer als keines, weil die Leute ihm glauben.

Wenn die Kardinalitätssymbole in den Diagrammen oben Entschlüsselung brauchen: sie sind in der Krähenfuß-Notation behandelt; die Form des Modells selbst steht in den ER-Diagrammen.