Anomalien und deren Vermeidung durch Normalisierung eines Relationenschemas

Anomalien und deren Vermeidung durch Normalisierung eines Relationenschemas

https://bildung.social/deck/@oerinformatik/114413571248181322

https://oer-informatik.de/normalisierung

Normalisierung, Relationenmodell, Normalformen, Redundanz, Anomalien, Funktionale Abhängigkeit, Transitive Abhängigkeit, Denormalisierung, Datenbankentwurf

tl/dr; (ca. 29 min Lesezeit): Bei einem schlechten Design einer Datenbank werden Informationen mehrfach gespeichert (Redundanz) – und es ergeben sich schnell Inkonsistenzen beim Einfügen, Aktualisieren und Löschen von Daten – die „Anomalien“. Eine Best-Practice-Sammlung, um dies durch Design zu verhindern, stellen die Normalformen dar. Dieser Artikel beschreibt die erste (1NF, Atomarität), zweite (2NF, Unabhängigkeit der Attribute von Teilschlüsseln) und dritte (3NF, Unabhängigkeit von Nichtschlüsselattributen) Normalform und die Schritte, wie man ein Relationenschema entsprechend umwandelt. Außerdem zeigt er, wie Du aus einer nicht normalisierten Tabelle direkt ein Relationenmodell in der 3NF entwickelst und wann man bewusst von den Normalformen abweicht [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Dieser Artikel baut auf der Kann-Liste des Artikels Der logische Datenbankentwurf mit dem Relationenmodell auf. Zum Üben gibt es Übungsaufgaben. Hier klicken, um Kann-Liste ein- oder auszublenden

Als Modellierungs-Grundlagen kann ich nach Durchlesen des Artikels…

• … den Begriff Redundanz erklären und an einem konkreten Beispiel aus einer Tabelle beschreiben.

• … Einfüge-, Änderungs- und Löschanomalien unterscheiden und jeweils an einem konkreten Beispiel aus einer Tabelle erläutern.

• … beschreiben, wie inkonsistente Daten (z. B. abweichende Schreibweisen) entstehen und welche Folgen sie für Auswertungen haben.

• … die Definition der 1NF, 2NF und 3NF nennen – sowohl mit Fachbegriffen wie auch trivial.

• … die Schritte nennen, die zur Umwandlung in die jeweilige Normalform nötig sind.

• … an Hand eines gegebenen Relationenschemas die aktuell vorliegende Normalform erkennen.

• … ein gegebenes Relationenschema in eine geforderte Normalform bringen.

• … eine Tabelle mit Listen und zusammengesetzten Werten in die 1NF bringen, alle Attributwerte eintragen und aus den vorhandenen Attributen einen zusammengesetzten Primärschlüssel bilden.

• … aus einer nicht normalisierten Tabelle direkt ein Relationenmodell in der 3NF erstellen – mit sinnvollen Tabellennamen, Primär- und Fremdschlüsseln und Beziehungen mit Kardinalitäten.

• … begründen, warum eine gegebene Tabelle nicht der 3NF entspricht, und sie korrigieren.

• … beschreiben, welche Probleme entstehen, wenn eine ausgelagerte Tabelle (z. B. eine Wertetabelle) wieder in die Ausgangstabelle zurückgeführt wird.

• … die Definitionen der Normalformen auch in englischer Sprache verstehen.

• … den Zweck der Normalisierung erläutern, die Probleme nennen, die eine Normalisierung bis zur 3NF verhindert, und die Bedeutung der 3NF für relationale Datenbanken erklären.

• … typische Kennzeichen eines relationalen Datenmodells nennen.

• … ein bestehendes Relationenmodell um neue Sachverhalte erweitern, ohne die 3NF zu verletzen.

• … Daten aus einer Liste oder CSV-Datei bereinigen und normalisiert in Tabellen übernehmen.

Darüber hinaus kann ich als Modellierungs-Expertenwissen…

• … erklären, was transitive Abhängigkeit ist.

• … voll funktionale Abhängigkeit erklären sowie funktionale und transitive Abhängigkeit jeweils an einem eigenen Beispiel erläutern.

• … begründen, warum Werte zum Zeitpunkt eines Vorgangs (z. B. der Preis zum Bestellzeitpunkt) keine Redundanz sind.

• … Gründe für eine bewusste Denormalisierung nennen, ihre Folgen abschätzen und kriteriengeleitet entscheiden, welche Verstöße gegen die Normalisierung ich im Datenmodell akzeptiere.

Ausgangspunkt

Wir betrachten folgende Relation:

bestellte_artikel(BestellNr (PK), Artikel (PK), KundenNr, Vorname, Nachname, BestellDatum, Anzahl, Einzelpreis)

Mit beispielhaft folgenden Einträgen (Tupel):

KundenNr	Vorname	Nachname	BestellNr	BestellDatum	Artikel	Anzahl	Einzelpreis
789	Max	Meier	007	17.8.2020	878: CPU i7 7430	2	123,80€
789	Max	Meier	007	17.8.2020	879: Mainboard Asus z67	1	227,95€

Wenn wir mit Relationen wie diesen arbeiten, können im Verlauf der Datenanpassung eine Reihe von Problemen auftreten, die wir in drei Kategorien eingliedern können:

• Einfüge-,

• Änderungs- und

• Löschanomalien.

Redundanz und Inkonsistenz

Die Ursache aller drei Anomalien ist Redundanz: Dieselbe Information ist mehrfach gespeichert. In der Beispielrelation stehen Kundennummer und Name von Max Meier sowie das Datum der Bestellung 007 in jeder Bestellposition – bei einer Bestellung mit zehn Artikeln also zehnmal. Redundanz kostet Speicherplatz, vor allem aber gefährdet sie die Konsistenz (Widerspruchsfreiheit) der Daten: Wird eine Kopie geändert und eine andere nicht, widersprechen sich die Datensätze. Welche Angabe dann stimmt, lässt sich aus den Daten allein nicht mehr entscheiden.

Typische Spuren solcher Inkonsistenzen in gewachsenen Tabellen sind abweichende Schreibweisen derselben Sache („Bäcker GmbH“, „Baecker GmbH“), unterschiedliche Adressformate („Hauptstr. 7“, „Hauptstraße 7“) oder verschiedene Preise für denselben Artikel. Auswertungen (z. B. Umsatz je Kunde) werden dadurch falsch, weil die Varianten wie verschiedene Kunden behandelt werden.

Nicht jede Wiederholung ist Redundanz: Ein Fremdschlüssel wie die KundenNr in jeder Bestellung ist nötig, um Datensätze zu verknüpfen. Redundant ist eine Information, wenn sie sich aus anderen gespeicherten Daten ableiten lässt – der Name eines Kunden etwa aus seiner Kundennummer.

Anomalien

Einfügeanomalie

Eine Einfüge-(Insertion)-Anomalie liegt vor, wenn neue Einträge (Tupel = Entitäten/Objekte/Tabellenzeilen) in ein Relationenschema nicht vorgenommen werden können, da nicht alle (Teil-)Schlüsselattribute gesetzt werden können. Die gewünschten Operationen können nicht durchgeführt werden und das Relationenschema kann nicht die Tupel enthalten, die es enthalten soll.

Wenn wir beispielsweise in unsere Beispiel-Relation einen neuen Artikel aufnehmen wollen, so ist dies in der derzeitigen Form nicht möglich, solange dieser nicht in einem Bestellvorgang genutzt wird und eine BestellNr vorliegt.

Oft wird die Einfügeanomalie auch so beschrieben: Ein neuer Sachverhalt lässt sich nur mit leeren Feldern speichern. Soll etwa ein neuer Kunde erfasst werden, der noch nichts bestellt hat, bleiben alle Bestellattribute leer (NULL). Ist eines davon Teil des Primärschlüssels, ist das Einfügen sogar unmöglich, denn Schlüsselattribute dürfen nicht leer sein.

KundenNr	Vorname	Nachname	BestellNr	BestellDatum	Artikel	Anzahl	Einzelpreis
789	Max	Meier	007	17.8.2020	878: CPU i7 7430	2	123,80€
			??? !!!		901: HDD WD Red Label		157,95€

Änderungsanomalie

Von einer Änderungs-(Update)-Anomalie spricht man, wenn in einem Relationenschema in mehreren Tupeln redundante Informationen stehen, bei einem Änderungsvorgang aber nicht alle betroffenen Attribute/Tupel angepasst werden. Es entsteht ein inkonsistentes Relationenschema, das ggf. fehlerhafte oder nicht eindeutige Informationen enthält.

Beispiel:

Der Kunde Max Meier hat mitgeteilt, dass er sich wie der bayerische Maier schreibt. Die Information wurde jedoch nicht in jedem Tupel (Zeile) angepasst – jetzt widersprechen sich die Datensätze. Wer später auswertet oder einen Brief verschickt, weiß nicht mehr, welche Schreibweise gilt:

KundenNr	Vorname	Nachname	BestellNr	BestellDatum	Artikel	Anzahl	Einzelpreis
789	Max	Maier	007	17.8.2020	878: CPU i7 7430	2	123,80€
789	Max	!!! Meier !!!	007	17.8.2020	879: Mainboard Asus z67	1	227,95€

Löschanomalie

Von einer Lösch-(Delete)-Anomalie spricht man, wenn in einem Relationenschema mehr Daten gelöscht werden, als ursprünglich intendiert.

Wenn in unserem Beispiel die Bestellung 007 von Max Meier gelöscht wird, ist auch die Information über die Artikel und ihre Einzelpreise verloren – sofern sie nicht bei einer anderen Bestellung noch auftauchen. Ebenso sind die Informationen über Max Meier selbst verloren, sofern sie nicht anderweitig auftauchen.

Anomalien im Überblick

Anomalie	Was passiert?	Wie verhindert die Normalisierung das?
Einfügeanomalie	Eine neue Information lässt sich nicht oder nur mit leeren Feldern speichern.	Jeder Sachverhalt (Kunde, Artikel, Bestellung) erhält eine eigene Tabelle und kann unabhängig angelegt werden.
Änderungsanomalie	Eine Information steht mehrfach; wird nicht jede Kopie geändert, entstehen Widersprüche.	Jede Information steht genau einmal; geändert wird genau ein Datensatz.
Löschanomalie	Beim Löschen gehen weitere, nur dort gespeicherte Informationen verloren.	Gelöscht wird nur der Datensatz des betroffenen Sachverhalts; die übrigen Daten liegen in eigenen Tabellen.

Normalisierung von Datenbanken

Um zu verhindern, dass Anomalien auftreten, muss ein Relationenschema in der Struktur bestimmten Regeln folgen. Schrittweise werden die Strukturen eliminiert, die Probleme verursachen könnten. Dieser Prozess nennt sich Normalisierung und erfolgt in mehreren Schritten, den Normalformen.

Wir betrachten folgendes Relationenschema:

KundenNr	Vorname	Nachname	Telefon	BestellNr	BestellDatum	Artikel	Anzahl	Einzelpreis
789	Max	Meier	0521 / 1234-0	007	17.8.2020	878: CPU i7 7430	2	123,80€
789	Max	Meier	0521 / 1234-0	007	17.8.2020	879: Mainboard Asus z67	1	227,95€
123	Stefan	Schmidt	0521 / 567-0, 0163 / 4567	013	19.8.2020	901: HDD WD Red Label	4	157,95€
123	Stefan	Schmidt	0521 / 567-0, 0163 / 4567	013	19.8.2020	879: Mainboard Asus z67	1	227,95€

Wozu normalisieren? Zweck und funktionale Abhängigkeit

Die Normalisierung hat ein Ziel: Jede Information wird genau einmal gespeichert. Daraus folgt alles Weitere:

• Es gibt keine Einfüge-, Änderungs- und Löschanomalien.

• Die Daten bleiben konsistent, weil eine Änderung nur an einer Stelle vorgenommen wird.

• Die Struktur ist übersichtlich und erweiterbar: Neue Sachverhalte werden als neue Tabelle ergänzt, statt bestehende Tabellen umzubauen.

• Speicherplatz wird gespart (heute meist der kleinste Vorteil).

Für Datenbanken, in denen laufend Daten erfasst und geändert werden, gilt die 3NF als Standard: Sie verhindert die typischen Anomalien, ohne das Modell unnötig zu zerlegen. Höhere Normalformen werden in der Praxis selten gebraucht.

Die Normalformen beruhen auf dem Begriff der funktionalen Abhängigkeit:

• Ein Attribut B ist funktional abhängig von A (geschrieben A → B), wenn zu jedem Wert von A genau ein Wert von B gehört. Beispiel: Aus der KundenNr 789 folgt eindeutig der Nachname „Meier“: KundenNr → Nachname.

• Voll funktional abhängig ist B von einem zusammengesetzten Schlüssel, wenn B vom ganzen Schlüssel abhängt, nicht schon von einem Teil. Beispiel: Die Anzahl hängt von BestellNr und Artikel ab; der Einzelpreis dagegen schon allein vom Artikel – er ist nur teilweise abhängig und verletzt deshalb die 2NF.

• Transitiv abhängig ist B vom Primärschlüssel, wenn B über ein anderes Nichtschlüsselattribut A vom Schlüssel abhängt: Schlüssel → A → B. Beispiel: KundenNr → PLZ und PLZ → Ort, also hängt Ort transitiv von der KundenNr ab. Die 3NF verbietet solche Abhängigkeiten.

Ein relationales Datenmodell erkennst Du an diesen Kennzeichen: Die Daten stehen in Tabellen (Relationen) mit eindeutigem Namen, jede Zeile ist ein Datensatz, jede Spalte ein Attribut mit festem Datentyp; jede Tabelle hat einen Primärschlüssel; Beziehungen werden über Fremdschlüssel hergestellt und mit Kardinalitäten (1:1, 1:n, m:n über Zwischentabellen) beschrieben. Mehr dazu im Artikel Der logische Datenbankentwurf mit dem Relationenmodell.

Die erste Normalform (1NF)

Definition

Ein Relationenschema ist in erster Normalform, wenn alle Attribute des Schemas elementar sind.

Klartext

Attribute müssen elementar, also einwertig, atomar, unteilbar sein:

• keine Listen als Attribut

• keine Mengen als Attribut

• keine Relationen als Attribut

Prozess der Normalisierung für die 1. Normalform:

1. Attribute mit Listen / Mengen / Relationen identifizieren

2. Attribute mit Listen (also mehreren gleichwertigen Attributen) in mehrere Tupel (Zeilen) aufteilen

3. Attribute mit Mengen/Relationen (also Attribute mit mehreren unterschiedlichen teilbaren Werten) in mehrere neue Attribute aufteilen.

4. Überprüfen, ob die bisherigen Primärschlüssel noch hinreichend sind – ggf. neue zusammengesetzte Primärschlüssel bilden. Der Schlüssel wird möglichst aus vorhandenen Attributen gebildet. Im fertigen Modell sollte er minimal sein (kein Teil darf sich aus den anderen Teilen ergeben); im Zwischenschritt der 1NF ist das oft noch nicht der Fall – die 2NF und 3NF lösen solche Abhängigkeiten auf.

An einem Beispiel

1. Identifikation der Mengen und Listen: fett gesetzt sind Listen, kursiv Mengen.

Relationenschema, das nicht in der ersten Normalform ist: Listen (fett) und Mengen (kursiv) in den Attributen

KundenNr	Vorname	Nachname	Telefon	BestellNr	BestellDatum	Artikel	Anzahl	Einzelpreis
789	Max	Meier	0521 / 1234-0	007	17.8.2020	878: CPU i7 7430	2	123,80€
789	Max	Meier	0521 / 1234-0	007	17.8.2020	879: Mainboard Asus z67	1	227,95€
123	Stefan	Schmidt	0521 / 567-0, 0163 / 4567	013	19.8.2020	901: HDD WD Red Label	4	157,95€
123	Stefan	Schmidt	0521 / 567-0, 0163 / 4567	013	19.8.2020	879: Mainboard Asus z67	1	227,95€

2. Attribute mit Listen (fett) in Zeilen aufteilen und neuen zusammengesetzten Primärschlüssel bilden. Da Telefon für sich genommen nicht als Teilschlüssel funktionieren muss, werden KundenNr und Telefon als Schlüssel ergänzt: (Artikel, BestellNr, KundenNr, Telefon)

KundenNr	Vorname	Nachname	Telefon	BestellNr	BestellDatum	Artikel	Anzahl	Einzelpreis
789	Max	Meier	0521 / 1234-0	007	17.8.2020	878: CPU i7 7430	2	123,80€
789	Max	Meier	0521 / 1234-0	007	17.8.2020	879: Mainboard Asus z67	1	227,95€
123	Stefan	Schmidt	0521 / 567-0	013	19.8.2020	901: HDD WD Red Label	4	157,95€
123	Stefan	Schmidt	0163 / 4567	013	19.8.2020	901: HDD WD Red Label	4	157,95€
123	Stefan	Schmidt	0521 / 567-0	013	19.8.2020	879: Mainboard Asus z67	1	227,95€
123	Stefan	Schmidt	0163 / 4567	013	19.8.2020	879: Mainboard Asus z67	1	227,95€

Mehrwertige Attribute, die unabhängig vom Rest der Zeile sind – wie die Telefonnummern eines Kunden –, vervielfachen beim Aufteilen in Zeilen alle übrigen Daten (aus vier Zeilen werden sechs). Man kann sie deshalb auch sofort in eine eigene Relation telefon(KundenNr, Telefon) auslagern; spätestens bei der 2NF landen sie ohnehin dort.

3. Attribute mit Mengen (kursiv) in mehrere Attribute aufteilen und ggf. neuen Primärschlüssel bilden (ArtikelNr, BestellNr, KundenNr, Telefon)

Beachte: Dieser Schlüssel ist im Zwischenschritt der 1NF noch nicht minimal. Die KundenNr ergibt sich bereits aus der BestellNr (BestellNr → KundenNr), der Schlüssel (ArtikelNr, BestellNr, Telefon) würde also genügen. Das ist in der 1NF noch kein Fehler: Die Schritte zur 2NF und 3NF lösen solche Abhängigkeiten auf, die KundenNr landet am Ende als Fremdschlüssel in der Relation bestellungen.

Die zweite Normalform (2NF)

Definition

Ein Relationenschema ist in zweiter Normalform, wenn es

• in erster Normalform ist und

• jedes Nichtschlüsselattribut voll funktional von jedem Schlüsselkandidaten abhängt (und nicht nur von einem Teilschlüssel).

Klartext

Bei zusammengesetzten Primärschlüsseln hängt jedes Attribut, das kein Schlüssel ist, vom gesamten Primärschlüssel ab, und nicht nur von einzelnen Teilschlüsseln.

Prozess der Normalisierung für die 2. Normalform:

1. Zusammengesetzter Primärschlüssel? (falls nein: 2. NF liegt vor)

2. Folgen aus Teilschlüsselattributen weitere Attribute? (falls nein: 2. NF liegt vor)

3. Bildung einer neuen Relation aus dem Teilschlüsselattribut (dann neuer Primärschlüssel) und allen von diesem abhängigen Nichtschlüsselattributen.

4. Löschen der ausgelagerten Nichtschlüsselattribute in der Ausgangsrelation (Ausgelagerte Teilschlüssel bleiben als Fremdschlüssel in der Ausgangsrelation).

5. Bildung neuer Relationen wiederholen, bis alle Nichtschlüsselattribute vom gesamten Schlüssel funktional abhängig sind.

An einem Beispiel

Ergebnis der 1. Normalform war das folgende Relationenschema:

bestellte_artikel(KundenNr (PK), Vorname, Nachname, Telefon (PK), BestellNr (PK), BestellDatum, ArtikelNr (PK), ArtikelName, Anzahl, Einzelpreis)

1. Haben wir einen zusammengesetzten Primärschlüssel?

Ja. Der zusammengesetzte Primärschlüssel ist: (KundenNr, Telefon, BestellNr, ArtikelNr)

2. Folgen aus Teilschlüsselattributen weitere Attribute?

Eine ganze Reihe (die kursive Zeile der Tabelle nennt, wovon das Attribut abhängt):

Abhängigkeit nur von ArtikelNr: ArtikelName, Einzelpreis

Abhängigkeit nur von BestellNr: BestellDatum und KundenNr. Die KundenNr gehört zwar zum Schlüssel aus der 1NF, ergibt sich aber aus der BestellNr – der Schlüssel war also noch nicht minimal (siehe oben). Sie wandert deshalb als Fremdschlüssel in die Relation bestellungen.

Abhängigkeit nur von KundenNr: Vorname, Nachname

Abhängigkeit nur von BestellNr und ArtikelNr (ohne KundenNr und Telefon): Anzahl. Auch das ist nur ein Teil des Schlüssels; die Anzahl bleibt deshalb mit diesem Teilschlüssel in der Ausgangsrelation bestellte_artikel.

Es ergeben sich also folgende neuen Relationen:

artikel(ArtikelNr (PK), ArtikelName, Einzelpreis)

bestellungen(BestellNr (PK), BestellDatum, ↑KundenNr↑ (FK))

Kundentelefonnummern(Telefon (PK), KundenNr (PK), Vorname, Nachname)

Hier müsste nochmals überprüft werden, ob weiterhin Abhängigkeiten vorliegen:

Vorname und Nachname hängen nur von Kundennummer ab, müssten also weiterhin ausgelagert werden:

Kunden(KundenNr (PK), Vorname, Nachname)

Telefon(↑KundenNr↑ (PK,FK), Telefon (PK))

(Unter der Annahme, dass mehrere Kunden dieselbe Telefonnummer haben könnten, verbleibt die KundenNr hier als Teilschlüsselattribut.)

sowie die Ausgangsrelation ohne die entsprechenden Attribute:

bestellte_artikel(↑BestellNr↑ (PK, FK), ↑ArtikelNr↑ (PK, FK), Anzahl)

Am Ende der 2NF besteht das Beispiel also aus den Relationen artikel, bestellungen, kunden, telefon und bestellte_artikel. Beachte: Wenn sich Artikelpreise ändern können, muss in bestellte_artikel zusätzlich der Preis zum Bestellzeitpunkt gespeichert werden – das ist keine Redundanz, sondern eine eigene Information (siehe Bewusst gegen die Normalform).

Die dritte Normalform (3NF)

Definition

Ein Relationenschema ist in dritter Normalform (3NF), wenn es

• in zweiter Normalform ist und

• kein Nichtschlüsselattribut transitiv von einem Schlüssel abhängt

Klartext

Aus keinem Nichtschlüsselattribut folgt ein anderes Nichtschlüsselattribut.

Prozess der Normalisierung für die 3. Normalform:

1. Folgen aus einem Nichtschlüsselattribut weitere (Nichtschlüssel-)Attribute? (falls nein: 3. NF liegt vor)

2. Bildung einer neuen Relation aus diesem Nichtschlüsselattribut (dann neuer Primärschlüssel) und allen von diesem abhängigen Attributen.

3. Nichtschlüsselattribut bleibt als Fremdschlüssel in der Ausgangsrelation, ausgelagerte Attribute werden gelöscht.

4. Bildung neuer Relationen wiederholen, bis keine Nichtschlüsselattribute von anderen Nichtschlüsselattributen funktional abhängig sind.

An einem Beispiel:

Beispielsweise könnte für Kunden erfasst werden, ob die Einzelpreise brutto oder netto ausgewiesen werden – und dies in Abhängigkeit von der Kundenart – etwa so:

Kunden(KundenNr (PK), Vorname, Nachname, Kundenart, BruttoNetto)

Es liegt eine Abhängigkeit zwischen zwei Nichtschlüsselattributen Kundenart und BruttoNetto vor. Die abhängigen Attribute müssen in eine neue Relation überführt werden, wobei das Attribut, von dem die anderen abhängen, als Fremdschlüssel in der Ausgangsrelation verbleibt.

Die neue Relation wäre hier:

kundenart(Kundenart (PK), BruttoNetto)

Die Ausgangsrelation würde um die abhängigen Attribute gekürzt und die neue Fremdschlüsselkennzeichnung eingefügt:

kunden(KundenNr(PK), Vorname, Nachname, ↑Kundenart↑ (FK))

Ein zweites Beispiel: Postleitzahl und Ort

Häufig steckt eine transitive Abhängigkeit in Adressen. Angenommen, die Kundentabelle wird um die Anschrift ergänzt:

kunden(KundenNr (PK), Vorname, Nachname, Strasse_HausNr, PLZ, Ort, ↑Kundenart↑ (FK))

Der Ort ergibt sich aus der Postleitzahl (PLZ → Ort), hängt also nur über die PLZ – transitiv – von der KundenNr ab. Streng genommen müsste eine Relation postleitzahl(<u>PLZ</u> (PK), Ort) ausgelagert werden. In der Praxis (und in vielen Aufgaben ausdrücklich erlaubt) bleiben PLZ und Ort oft zusammen in der Tabelle, denn die Abhängigkeit gilt nicht streng: Es gibt Postleitzahlen, die für mehrere Orte gelten. Wichtig ist, dass Du die Abhängigkeit erkennst und Deine Entscheidung begründen kannst.

Begründen, warum eine Tabelle nicht in 3NF ist

Die Normalformen bauen aufeinander auf. Eine Begründung prüft deshalb von unten nach oben:

1. Gibt es zusammengesetzte oder mehrfache Werte in einer Zelle? Dann ist schon die 1NF verletzt – und damit auch die 3NF. Beispiel: lieferant(LieferantNr, Name, Adresse) mit Adresse = "Mindener Straße 12, 32049 Herford": Straße, PLZ und Ort stecken in einem Attribut.

2. Hängt bei einem zusammengesetzten Schlüssel ein Attribut nur von einem Teil des Schlüssels ab? Dann ist die 2NF verletzt.

3. Bestimmt ein Nichtschlüsselattribut ein anderes (z. B. PLZ → Ort, Kundenart → BruttoNetto)? Dann ist die 3NF verletzt.

Nenne in der Begründung immer das konkrete Attribut und die Abhängigkeit, nicht nur die Regel.

Die Normalformen auf Englisch

In englischsprachigen Dokumentationen und Werkzeugen begegnen Dir die Normalformen so:

Normalform	Englische Formulierung	Bedeutung
1NF	Every attribute contains only atomic (indivisible) values; there are no repeating groups.	Keine Listen, keine zusammengesetzten Werte in einer Zelle.
2NF	The table is in 1NF and every non-key attribute is fully functionally dependent on the whole primary key.	Kein Attribut hängt nur von einem Teil des Schlüssels ab.
3NF	The table is in 2NF and no non-key attribute is transitively dependent on the primary key.	Kein Nichtschlüsselattribut hängt von einem anderen Nichtschlüsselattribut ab.

Als Merksatz für 2NF und 3NF zusammen ist ein Wortspiel bekannt, das sinngemäß auf William Kent (1983) zurückgeht: „Every non-key attribute must provide a fact about the key, the whole key, and nothing but the key.“

In einem Schritt zur 3NF: von der Tabelle zum Relationenmodell

Häufig sollst Du eine nicht normalisierte Tabelle (eine Liste aus einer Tabellenkalkulation, einen Beleg) direkt in ein Relationenmodell der 3NF überführen, ohne die Zwischenschritte aufzuschreiben. Gedanklich laufen dieselben Schritte ab:

1. Sachverhalte finden: Welche Dinge beschreibt die Tabelle (Kunde, Bestellung, Artikel …)? Jeder Sachverhalt wird eine Tabelle mit sinnvollem Namen.

2. Attribute zuordnen und atomar machen: Zusammengesetzte Werte (Name, Anschrift, Kontaktdaten) in einzelne Attribute zerlegen, jedes Attribut der Tabelle zuordnen, von deren Schlüssel es abhängt.

3. Schlüssel bestimmen: Primärschlüssel möglichst aus vorhandenen Daten bilden (z. B. Kundennummer). Fehlt ein geeigneter Kandidat, einen künstlichen Schlüssel ergänzen. Wiederholt sich ein Vorgang (z. B. mehrere Besuche desselben Gastes), gehört der Zeitpunkt zum Schlüssel – oder es wird eine künstliche Nummer vergeben.

4. m:n-Beziehungen auflösen: Zwischen zwei Sachverhalten, die sich gegenseitig mehrfach zugeordnet sind (Bestellung – Artikel), entsteht eine Zwischentabelle mit zusammengesetztem Primärschlüssel aus den beiden Fremdschlüsseln. Attribute, die erst durch die Kombination bestimmt sind (Anzahl, Preis je Lieferant, Bewertung), gehören in diese Zwischentabelle.

5. Fremdschlüssel und Beziehungen: Bei 1:n-Beziehungen wandert der Primärschlüssel der 1-Seite als Fremdschlüssel in die n-Seite. Beziehungen als Linien zwischen den Tabellen einzeichnen und die Kardinalitäten (1, n) daran schreiben.

6. Kontrolle: Lässt sich die Ausgangstabelle per JOIN wieder vollständig herstellen? Steht jede Information nur einmal? Gibt es transitive Abhängigkeiten?

Für das Beispiel dieses Artikels ergibt sich (mit der Kundenart aus der 3NF) folgendes Relationenmodell:

Typische Fehler beim direkten Überführen sind: vergessene Zwischentabelle bei m:n-Beziehungen, Fremdschlüssel auf der falschen Seite einer 1:n-Beziehung, ein Primärschlüssel, der wiederholte Vorgänge nicht unterscheiden kann, Beziehungsattribute (Menge, Preis) in der falschen Tabelle und fehlende Kardinalitäten.

Bewusst gegen die Normalform: Denormalisierung

Die 3NF ist der Normalfall für Datenbanken, in denen laufend geändert wird. Es gibt aber gute Gründe, bewusst abzuweichen – dann sollte die Abweichung begründet und dokumentiert sein:

• Werte zum Zeitpunkt eines Vorgangs: Der Preis in einer Bestellposition, der Stundensatz auf einem Auftrag oder die Anschrift auf einer Rechnung müssen so erhalten bleiben, wie sie damals galten. Das ist keine Redundanz, sondern eine eigene Information – sie gehört in die Tabelle des Vorgangs.

• Lesegeschwindigkeit: Für Auswertungen (Berichte, Data Warehouse) werden Daten oft absichtlich zusammengeführt gespeichert, damit Abfragen ohne viele JOINs auskommen. Diese Daten werden meist nur gelesen und regelmäßig neu erzeugt.

• Kleine, stabile Abhängigkeiten: PLZ und Ort in einer Tabelle sind üblich (siehe oben).

Wer dagegen eine ausgelagerte Tabelle ohne Not zurückführt – etwa die Bezeichnung einer Kategorie wieder in jeden Datensatz schreibt, um sich einen JOIN zu sparen –, holt sich die Redundanz und damit die Änderungsanomalie zurück: Ändert sich die Bezeichnung, müssen alle Datensätze angepasst werden, und neue Kategorien lassen sich erst anlegen, wenn sie benutzt werden.

Ein bestehendes Modell erweitern

Oft wird kein Modell neu entworfen, sondern ein vorhandenes ergänzt: Eine neue Kundengruppe mit Rabattsatz, eine Kennung für Ladestationen, ein weiteres Merkmal. Damit die 3NF erhalten bleibt, gehst Du so vor:

1. Sachverhalt bestimmen: Beschreibt die neue Information eine bereits vorhandene Tabelle (dann neues Attribut) oder etwas Eigenes mit eigenen Eigenschaften (dann neue Tabelle)? Die Kundengruppe hat eine Bezeichnung und einen Rabattsatz – also eine eigene Tabelle kundengruppe.

2. Abhängigkeiten prüfen: Hängt das neue Attribut nur vom Primärschlüssel ab? Würde der Rabattsatz in der Tabelle kunde stehen, hinge er von der Kundengruppe ab – eine transitive Abhängigkeit.

3. Beziehung und Kardinalität festlegen: Aus der Anforderung („Jeder Kunde gehört genau einer Kundengruppe an, eine Gruppe hat viele Kunden“) folgt 1:n; der Fremdschlüssel kundengruppe_id wandert in kunde. Bei 1:1 („Ein Kunde besitzt genau eine Kennung“) reicht oft ein zusätzliches Attribut mit UNIQUE; bei m:n entsteht eine Zwischentabelle.

4. Kennzeichnen: Primär- und Fremdschlüssel markieren, Kardinalitäten an die Beziehungslinien schreiben, bestehende Tabellen nur so weit ändern wie nötig.

Daten aus Listen und CSV-Dateien übernehmen

Sollen Daten aus einer Tabellenkalkulation oder einer CSV-Datei in normalisierte Tabellen übernommen werden, kommt vor dem Normalisieren das Bereinigen: Schreibweisen vereinheitlichen (Bäcker/Baecker), Duplikate zusammenführen, zusammengesetzte Felder zerlegen (Name, Anschrift), Formate angleichen (Datum, Dezimalzeichen) und fehlende oder unplausible Werte klären. Erst dann lassen sich die Sachverhalte sauber trennen und die Schlüssel bilden. Wie man Altdaten prüft und importiert, beschreibt der Artikel Datenqualität und Datenimport.

Leitfragen

1. Welche Gründe sprechen für die Normalisierung einer Datenbank? Antwort

Normalisierung vermeidet Redundanz, also mehrfach gespeicherte Informationen, und damit Inkonsistenzen sowie Einfüge-, Änderungs- und Löschanomalien: Jede Information steht genau einmal, jeder Sachverhalt hat eine eigene Tabelle und kann unabhängig angelegt, geändert und gelöscht werden. Siehe Abschnitt „Redundanz und Inkonsistenz“ und Abschnitt „Anomalien im Überblick“.

2. Welche Gründe können gegen die Normalisierung einer Datenbank sprechen (an einem Beispiel erklärt)? Antwort

Bewusst abweichen kannst Du etwa für schnelle Auswertungen: In Berichten oder einem Data Warehouse werden Daten absichtlich zusammengeführt gespeichert, damit Abfragen ohne viele JOINs auskommen – sie werden meist nur gelesen und regelmäßig neu erzeugt. Auch kleine, stabile Abhängigkeiten wie PLZ und Ort bleiben oft in einer Tabelle, weil die Abhängigkeit nicht streng gilt. Die Abweichung sollte begründet und dokumentiert sein, siehe Abschnitt „Bewusst gegen die Normalform: Denormalisierung“.

3. Wie lauten die ersten drei Normalformen – kurz in eigenen Worten erklärt? Antwort

1NF: Alle Attribute sind atomar, also keine Listen, Mengen oder zusammengesetzten Werte in einer Zelle. 2NF: 1NF und jedes Nichtschlüsselattribut hängt vom gesamten (zusammengesetzten) Primärschlüssel ab, nicht nur von einem Teil. 3NF: 2NF und aus keinem Nichtschlüsselattribut folgt ein anderes Nichtschlüsselattribut. Siehe Abschnitt „Normalisierung von Datenbanken“.

4. Welche Schritte sind jeweils erforderlich, damit Relationenschemas den einzelnen Normalformen genügen? Antwort

1NF: Listen in mehrere Zeilen, zusammengesetzte Werte in mehrere Attribute aufteilen und den Primärschlüssel prüfen bzw. neu zusammensetzen. 2NF: Attribute, die nur von einem Teilschlüssel abhängen, mit diesem Teilschlüssel als neuem Primärschlüssel in eine eigene Relation auslagern; der Teilschlüssel bleibt als Fremdschlüssel zurück. 3NF: Attribute, die von einem Nichtschlüsselattribut abhängen, mit diesem in eine neue Relation auslagern; es bleibt als Fremdschlüssel in der Ausgangsrelation. Siehe Abschnitt „Prozess der Normalisierung für die 1. Normalform:“, Abschnitt „Prozess der Normalisierung für die 2. Normalform:“ und Abschnitt „Prozess der Normalisierung für die 3. Normalform:“.

5. Worin unterscheidet sich die 2NF von der 3NF? Antwort

Die 2NF betrachtet Abhängigkeiten von einem Teil des Schlüssels und ist daher nur bei zusammengesetzten Primärschlüsseln relevant. Die 3NF betrachtet Abhängigkeiten zwischen Nichtschlüsselattributen (transitive Abhängigkeit), etwa Kundenart → BruttoNetto oder PLZ → Ort. Siehe Abschnitt „Die zweite Normalform (2NF)“ und Abschnitt „Die dritte Normalform (3NF)“.

6. Was versteht man unter Redundanz, und warum führt sie zu inkonsistenten Daten? Antwort

Redundanz heißt, dass dieselbe Information mehrfach gespeichert ist, z. B. der Kundenname in jeder Bestellposition. Wird nur eine Kopie geändert, widersprechen sich die Datensätze, und aus den Daten allein lässt sich nicht mehr entscheiden, welche Angabe stimmt – Auswertungen werden falsch. Ein Fremdschlüssel ist dagegen keine Redundanz, siehe Abschnitt „Redundanz und Inkonsistenz“.

7. Wie lassen sich Einfüge-, Änderungs- und Löschanomalie jeweils an einem Beispiel erklären? Antwort

Einfügeanomalie: Ein neuer Artikel lässt sich nicht speichern, solange er in keiner Bestellung vorkommt, weil die BestellNr als Teilschlüssel fehlt. Änderungsanomalie: Die neue Schreibweise „Maier“ wird nicht in allen Zeilen angepasst, die Daten widersprechen sich. Löschanomalie: Wird die Bestellung 007 gelöscht, gehen auch die Daten zu Kunde und Artikeln verloren. Siehe Abschnitt „Einfügeanomalie“, Abschnitt „Änderungsanomalie“ und Abschnitt „Löschanomalie“.

8. Woran erkennst Du, dass eine Tabelle nicht in der 3NF ist, und wie begründest Du das? Antwort

Du prüfst von unten nach oben: Gibt es mehrwertige oder zusammengesetzte Werte in einer Zelle, ist schon die 1NF verletzt; hängt ein Attribut nur von einem Teil des Schlüssels ab, die 2NF; bestimmt ein Nichtschlüsselattribut ein anderes (z. B. PLZ → Ort), die 3NF. In der Begründung nennst Du immer das konkrete Attribut und die Abhängigkeit, nicht nur die Regel, siehe Abschnitt „Begründen, warum eine Tabelle nicht in 3NF ist“.

9. Wie gehst Du vor, um aus einer nicht normalisierten Tabelle direkt ein Relationenmodell in der 3NF zu erstellen? Antwort

Du findest die Sachverhalte (je eine Tabelle mit sinnvollem Namen), zerlegst zusammengesetzte Werte und ordnest die Attribute zu, bestimmst Primärschlüssel, löst m:n-Beziehungen über Zwischentabellen auf, setzt bei 1:n-Beziehungen den Fremdschlüssel auf die n-Seite und zeichnest Beziehungen mit Kardinalitäten ein. Zum Schluss kontrollierst Du, ob sich die Ausgangstabelle per JOIN wiederherstellen lässt und jede Information nur einmal steht, siehe Abschnitt „In einem Schritt zur 3NF: von der Tabelle zum Relationenmodell“.

10. Warum ist der Preis zum Bestellzeitpunkt in einer Bestellposition keine Redundanz? Antwort

Der Preis zum Bestellzeitpunkt ist eine eigene Information über den Vorgang: Er muss so erhalten bleiben, wie er damals galt, auch wenn sich der aktuelle Artikelpreis später ändert. Er lässt sich also nicht aus dem Artikel ableiten und gehört in die Tabelle des Vorgangs, z. B. bestellte_artikel, siehe Abschnitt „Bewusst gegen die Normalform: Denormalisierung“.

Links und weitere Informationen

• Übungsaufgaben zu Normalisierung und Anomalien

• Der logische Datenbankentwurf mit dem Relationenmodell und Übungsaufgaben zum Relationenmodell

• Lernsituation Let’s Meet: Beispiellösung zur Normalisierung

• SQL: Abfragen über mehrere Tabellen (JOIN) – so werden normalisierte Tabellen wieder zusammengeführt

• William Kent: A Simple Guide to Five Normal Forms in Relational Database Theory. Communications of the ACM 26(2), 1983

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Anomalien und deren Vermeidung durch Normalisierung eines Relationenschemas” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/normalisierung veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/db-design/datenbankentwurf. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]