Normalisierung auf die dritte Normalform und die Entscheidung, wann denormalisiert wird

Worum es geht

Die zitierte Beschreibung von Microsoft nennt die drei klassischen Regeln. Erste Normalform: sich wiederholende Gruppen beseitigen (keine Spalten phone1, phone2, phone3; eine Zeile je Wert in einer eigenen Tabelle mit einem Schlüssel). Zweite Normalform: Wertemengen, die für mehrere Datensätze gelten, in eine eigene Tabelle verschieben, verknüpft über einen Fremdschlüssel. Dritte Normalform: Felder beseitigen, die nicht vom Schlüssel abhängen. Die übliche Kurzformel lautet, dass jede Nichtschlüsselspalte vom Schlüssel abhängt, vom ganzen Schlüssel und von nichts als dem Schlüssel. Dieselbe Quelle hält fest, dass die dritte Normalform für die meisten Anwendungen als die höchste notwendige Stufe gilt.

Warum es wichtig ist

Ein an zwei Stellen gespeicherter Fakt driftet auseinander: Eine auf jede Bestellung kopierte Kundenadresse ist nach einem Umzug der Kundschaft falsch, sofern nicht jede Kopie aktualisiert wird. Normalisierte Tabellen machen jeden Fakt an einer einzigen Stelle aktualisierbar und lassen die Datenbank die Konsistenz über Fremdschlüssel durchsetzen. Der Preis dafür sind Joins beim Lesen und eine Form, die für Berichte weniger bequem ist.

So wird es angewendet

• Zuerst Entitäten und Beziehungen modellieren; jeder Tabelle einen stabilen Primärschlüssel geben und jeden Fakt dort speichern, wo er ausschliesslich von diesem Schlüssel abhängt.
• Spalten mit numerischen Suffixen, kommagetrennte Listen in einer Spalte und «Typ»-Spalten, die die Bedeutung benachbarter Spalten ändern, sind die üblichen Verstösse gegen die erste Normalform; sie in Zeilen extrahieren.
• Nur bei einem nachgewiesenen Leseproblem denormalisieren: ein Zähler, eine gecachte Summe, ein kopierter Anzeigename. Die Kopie als abgeleitet benennen (cached_total, denormalised_customer_name) und dokumentieren, was sie pflegt.
• Die normalisierten Daten als massgebliche Quelle behalten; ein Job, der abgeleitete Spalten daraus neu berechnet und Abweichungen meldet, ist der Test, dass die Denormalisierung weiterhin korrekt ist.
• Snapshots sind keine Denormalisierung: Eine Rechnungszeile muss Preis und Beschreibung so behalten, wie sie zum Verkaufszeitpunkt waren, selbst wenn sich die Produktzeile später ändert.

Stolpersteine

Referenzdaten übernormalisieren in Einspaltentabellen, die Joins hinzufügen, ohne irgendetwas zu schützen. Eine JSON-Spalte als Ausweg aus der Modellierung behandeln. Denormalisieren, bevor ein Abfrageplan zeigt, dass der Join das Problem ist. Historie (Snapshots, die sich nicht ändern dürfen) mit abgeleiteten Kopien (die ihrer Quelle folgen müssen) verwechseln.