Relationale Datenmodelle

Was ist Normalisierung in Datenbanken?

Normalformen, Database Normalization

Normalisierung ist das schrittweise Umbauen eines relationalen Datenmodells, bei dem jede Information genau einmal gespeichert wird, damit beim Einfügen, Ändern und Löschen keine widersprüchlichen Daten entstehen können.

Steht der Firmenname in vier Tabellen, ist er nach dem nächsten Umzug in dreien falsch. Normalisierung ist die Antwort auf genau dieses Problem im Datenmodell.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Ziel: Jede Information genau einmal speichern
Übliche Tiefe: Dritte Normalform
Geht auf: Edgar F. Codd und das Relationenmodell
Gegenstück: Bewusste Denormalisierung für Auswertungen

Die ersten drei Normalformen

Die erste Normalform verlangt, dass in jeder Spalte ein einzelner Wert steht. Eine Spalte Telefonnummern mit drei kommagetrennten Nummern verletzt sie, weil du nach einer einzelnen Nummer nicht vernünftig suchen und keine davon einzeln löschen kannst. Die Nummern gehören in eine eigene Tabelle mit einer Zeile je Nummer.

Die zweite Normalform betrifft nur Tabellen mit zusammengesetztem Schlüssel. Jedes Nicht-Schlüsselfeld muss vom ganzen Schlüssel abhängen, nicht nur von einem Teil. In einer Tabelle Bestellposition mit dem Schlüssel aus Bestellnummer und Artikelnummer hängt die Artikelbezeichnung nur am Artikel, sie gehört also in die Artikeltabelle.

Die dritte Normalform verbietet Abhängigkeiten zwischen Nicht-Schlüsselfeldern. Stehen in der Kundentabelle Postleitzahl und Ort, hängt der Ort an der Postleitzahl und nicht am Kunden. Wer den Ort einer Postleitzahl ändert, müsste sonst jede betroffene Kundenzeile anfassen.

Was du dir damit ersparst

Die drei klassischen Anomalien sind der eigentliche Grund für den Aufwand. Die Änderungsanomalie: Eine Adresse steht an fünf Stellen, vier werden aktualisiert. Die Einfügeanomalie: Ein neuer Artikel lässt sich nicht anlegen, weil es noch keine Bestellung dazu gibt. Die Löschanomalie: Mit der letzten Bestellung verschwindet auch der Artikel aus dem System.

Ein normalisiertes Modell macht solche Widersprüche unmöglich, statt sie durch Anwendungscode zu verhindern. Das ist der Unterschied zwischen einer Regel, die gilt, und einer Regel, die jemand beim nächsten Import vergisst.

Denormalisierung als bewusste Entscheidung

Normalisierte Modelle brauchen Joins, und viele Joins können in Auswertungen teuer werden. Deshalb wird in Berichts- und Analysedatenbanken gezielt zurückgebaut, etwa im Sternschema mit einer breiten Faktentabelle und flachen Dimensionen. Spaltenorientierte Systeme wie ClickHouse rechnen sogar damit.

Wichtig ist die Richtung: erst normalisieren, dann begründet denormalisieren. Wer umgekehrt anfängt, hat weder die Regeln noch die Geschwindigkeit. Und jede duplizierte Spalte braucht einen benannten Mechanismus, der sie aktuell hält, sei es ein Trigger, ein Job oder ein Update im selben Vorgang.

Ein Sonderfall ist die absichtliche Kopie: Der Preis auf einer Rechnung ist keine Redundanz, sondern der Wert zum Zeitpunkt des Verkaufs. Er darf sich nicht ändern, wenn der Artikelpreis steigt.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Normalisierung und was oft damit gleichgesetzt wird

Normalisierung gegen Denormalisierung

Denormalisierung ist der geplante Rückbau eines normalisierten Modells zugunsten der Lesegeschwindigkeit. Sie ist etwas anderes als ein Modell, das nie normalisiert wurde: Beim Rückbau ist bekannt, welche Regel dabei aufgegeben wird.

Normalisierung gegen Indizierung

Ein Index beschleunigt Zugriffe, ohne das Modell zu ändern. Viele vermeintliche Normalisierungsprobleme sind in Wahrheit fehlende Indizes auf den Fremdschlüsselspalten.

Normalisierung gegen Boyce-Codd-Normalform

Die BCNF verschärft die dritte Normalform für Fälle mit mehreren überlappenden Schlüsselkandidaten. Im Alltag reicht die dritte Normalform fast immer, die BCNF wird nur bei ungewöhnlichen Schlüsselstrukturen relevant.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Die Rechnung kommt nicht beim Modellieren, sondern beim ersten Umzug

Der übliche Einstieg in das Problem ist eine gewachsene Tabelle aus einer Excel-Liste: Kundenname, Straße und Ansprechpartner stehen in jeder einzelnen Bestellzeile. Solange sich nichts ändert, fällt das nicht auf. Beim ersten Adresswechsel musst du entscheiden, welche der vielen tausend Zeilen die Wahrheit tragen, und spätestens dann zeigt sich, dass derselbe Kunde dort längst in drei Schreibweisen steht.

Der zweite Ort, an dem es kippt, ist die Auswertung. Wenn gezählt wird, wie viele Kunden aus Bayern kommen, zählt jede Schreibvariante als eigener Kunde. Die Zahl ist nicht falsch berechnet, sie beruht nur auf einem Modell, das denselben Sachverhalt mehrfach kennt, ohne zu wissen, welcher Eintrag gilt.

Übertreiben lässt sich das genauso. Wer jede Eigenschaft in eine eigene Tabelle auslagert, braucht für eine simple Übersicht acht Verknüpfungen und wundert sich über die Antwortzeit. Viele Teams halten deshalb den operativen Bestand in der dritten Normalform und stellen für Berichte bewusst flache Strukturen daneben, die aus diesem Bestand neu erzeugt werden.

Normalisierung lernen

Wie du ein bestehendes Modell prüfst und Schritt für Schritt umbaust, ohne den laufenden Betrieb zu stören, zeigen die Kurse zu Datenbankdesign .

Wie sich Modell und Ausführungsplan in einem konkreten System verhalten, siehst du in den Kursen zur Oracle-Datenbank .

Wissen prüfen

Sitzt Normalisierung schon?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Wissenstest SQL Grundlagen QuizTeste dein Wissen zu SELECT, JOIN, WHERE, GROUP BY und den wichtigsten SQL-Befehlen. Quiz starten Wissenstest PostgreSQL Grundlagen QuizTeste dein Wissen zu Abfragen, Joins, Indizes, Transaktionen, MVCC und dem Lesen von EXPLAIN. Quiz starten

Kurse, die Normalisierung behandeln

Häufige Fragen

Reicht die dritte Normalform aus?

Für Anwendungsdatenbanken in aller Regel ja. Höhere Normalformen greifen Fälle auf, die in üblichen Modellen selten vorkommen. Der Merksatz lautet: Jedes Nicht-Schlüsselfeld hängt vom Schlüssel, vom ganzen Schlüssel und von nichts als dem Schlüssel.

Macht Normalisierung meine Datenbank langsam?

Beim Schreiben eher schneller, weil weniger Zeilen geändert werden müssen. Beim Lesen kostet sie Joins, und die sind auf indizierten Schlüsseln meist billig. Teuer wird es erst bei sehr breiten Auswertungen, und dafür gibt es getrennte Modelle.

Gilt das auch für dokumentenorientierte Datenbanken?

Die Regeln stammen aus dem relationalen Modell, das Problem bleibt aber. Dort bettest du bewusst ein, was zusammen gelesen wird, und referenzierst, was sich unabhängig ändert. Wer eine Kundenadresse in tausend Bestelldokumente kopiert, hat dieselbe Änderungsanomalie.

Persönlich für dich da