Normalisierung

Die Normalisierung von relationalen Datenbank-Schemata dient dazu, Redundanzen und Anomalien (Einfüge-Anomalie, Änderungs-Anomalie, Lösch-Anomalie) zu vermeiden.

Die Normalisierung ist ein technisches Verfahren, mit dem Datenbank-Schemata in einen "guten" Zustand gebracht werden können. Datenbank-Schemata, die aus einer guten Entity-Relationship-Modellierung hervorgegangen sind, sollten keiner Normalisierung mehr bedürfen.

Erklärvideos

• Normalisierung

Fachbegriffe

Redundanz, Inkonsistenz, Anomalie, funktionale Abhängigkeit, 1. Normalform, 2. Normalform, 3. Normalform, atomar, Primärschlüssel

Funktionale Abhängigkeit

Für die Normalisierung ist der Begriff der "funktionalen Abhängigkeit" absolut zentral.

Definition:

B ist "funktional abhängig" von A, wenn B durch A eindeutig bestimmt wird.
Man schreibt dann: A → B

Man kann es auch so formulieren: Wenn ich A kenne, dann kenne ich direkt auch B.

Beispiele:

• Die Mutter ist "funktional abhängig" vom Kind.
  Denn wenn ich das Kind kenne, dann kenne ich direkt auch die Mutter.
  Es gilt also: Kind → Mutter.
• Das Kind ist nicht "funktional abhängig" von der Mutter!
  Denn wenn ich die Mutter kenne, dann kenne ich nicht direkt auch das Kind - die Mutter könnte mehrere Kinder haben!
  Es gilt also nicht : Mutter → Kind.

Beispiel für Normalisierung

Die Normalisierung wird hier an folgendem Beispiel mit zwei Tabellen aufgezeigt:

• Kurs(id, bezeichnung, schuljahr, halbjahr, lehrer-kuerzel und -name)
• Leistung(↑kurs_id, schueler_id, name, vorname, note)

Die beiden Tabellen sind wie folgt mit Daten gefüllt:

Kurs id bezeichnung schuljahr halbjahr lehrer-kuerzel und -name 13 M-LK 201415 1 RIE Riemann 14 D-LK 201415 1 CEL Celan 17 IF-LK 201415 1 GAT Gates

Leistung kurs_id schueler_id name vorname note 17 37 Stein Max 2 13 37 Stein Max 2 17 45 Müller Hanna 1 14 45 Müller Hanna 3

Die Beispieldaten zeigen, dass die Tabelle Leistung Redundanzen enthält und es deswegen zu Anomalien kommen kann.

Die Normalisierung in drei Schritten beseitigt die Redundanzen und die Gefahr von Anomalien.

Erste Normalform

Eine Tabelle befindet sich in der ersten Normalform, wenn alle Attribute atomar vorliegen und ein eindeutiger Primärschlüssel angegeben ist.

Ein Verstoß gegen die erste Normalform liegt vor...

• wenn der Primärschlüssel nicht eindeutig ist

• wenn Attribute nicht atomar sind, d.h. sich weiter zerlegen lassen.

In beiderlei Hinsicht liegt ein Verstoß gegen die erste Normalform vor!

Der Primärschlüssel der Tabelle leistung ist nicht eindeutig.
Das sieht man z.B. daran, dass der Wert 17 zweimal bei ↑kurs_id erscheint. Um den Primärschlüssel eindeutig zu machen, muss man schueler_id zusätzlich zum Primärschlüssel machen:
Die Kombination aus ↑kurs_id und schueler_id ist eindeutig, denn jeder Schüler kann jeden Kurs nur einmal belegen.

Atomar heißt, dass sich ein Attribut nicht in weitere Attribute unterteilen lässt.

Wann muss man Attribute aufspalten?

• Wenn man nach einem Teil des Attributes sinnvoll suchen kann.
• Wenn das Attribut in einem Webformular zwei (oder mehr) Formularfelder hätte.

Im Beispiel ist das Attribut lehrer-kuerzel und -name nicht atomar; es lässt sich zerlegen in lehrer-kuerzel und lehrer-name.

Das Schema in 1. Normalform lautet:

• Kurs(id, bezeichnung, schuljahr, halbjahr, lehrer_kuerzel, lehrer_name)
• Leistung(↑kurs_id, schueler_id, name, vorname, note)

Zweite Normalform

Eine Tabelle befindet sich in der zweiten Normalform, wenn die erste Normalform erfüllt ist und jedes nicht dem Primärschlüssel angehörige Attribut zwar vom Primärschlüssel, aber nicht von Teilen des Primärschlüssels abhängt.

Ein Verstoß gegen die zweite Normalform liegt also vor, wenn es ein Attribut (oder mehrere Attribute) gibt, die nur von einem Teil des Primärschlüssels abhängen.

Das heißt: Eine Tabelle mit einem Primärschlüssel aus nur einem Attribut ist automatisch in zweiter Normalform.

Im Beispiel ist die Tabelle Kurs auf jeden Fall in zweiter Normalform, denn ihr Primärschlüssel besteht aus nur einem Attribut.

In der Tabelle Leistung dagegen hängen name und vorname nur von schueler_id ab; d.h. hier liegt ein Verstoß gegen die 2. Normalform vor.

Der Verstoß lässt sich beheben, indem man die Attribute, die gegen die 2. Normalform verstoßen, in eine eigene Tabelle auslagert.

Das Schema in 2. Normalform lautet:

• Kurs(id, bezeichnung, schuljahr, halbjahr, lehrer_kuerzel, lehrer_name)
• Leistung(↑kurs_id, ↑schueler_id, note)
• Schueler(schueler_id, name, vorname)

Dritte Normalform

Eine Tabelle befindet sich in der dritten Normalform, wenn die erste und zweite Normalform erfüllt sind und alle Nicht-Schlüssel-Attribute nicht voneinander abhängen.

Ein Verstoß gegen die dritte Normalform liegt also vor, wenn es ein Attribut gibt, das von einem Nicht-Schlüssel-Attribut abhängt.

Im Beispiel liegt in der Tabelle Kurs ein Verstoß gegen die 3. Normalform vor. Denn lehrer_name hängt von lehrer_kuerzel ab.

Der Verstoß lässt sich beheben, indem man das Attribut, das gegen die 3. Normalform verstößt (=lehrer_name), in eine eigene Tabelle auslagert. Auch das Attribut, von dem lehrer_name abhängt (=lehrer_kuerzel) wird dorthin ausgelagert und wird dort Primärschlüssel. In der Tabelle Kurs bleibt ↑lehrer_kuerzel als Fremdschlüssel.

Das Schema in 3. Normalform lautet:

• Lehrer(lehrer_kuerzel, lehrer_name)
• Kurs(id, bezeichnung, schuljahr, halbjahr, ↑lehrer_kuerzel)
• Leistung(↑kurs_id, ↑schueler_id, note)
• Schueler(schueler_id, name, vorname)

Anmerkungen

• Aus Gründen der Einheitlichkeit wäre es besser, schueler_id in der Tabelle Schueler in id umzubenennen.
• lehrer_kuerzel als Primärschlüssel für die Tabelle Lehrer ist nur bedingt geeignet. An großen Schulen (z.B. auch am SIBI) müssen Kürzel von Lehrern, die schon in Pension sind, wieder verwendet werden. (KG z.B. hatte früher Herr Krings). Das heißt: Besser wäre eine id als Primärschlüssel.