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.

Die Normalisierung wird hier an folgendem Beispiel aufgezeigt:

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

Erste Normalform

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

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

Ein Verstoß gegen die erste Normalform liegt vor, wenn der Primärschlüssel nicht eindeutig ist oder wenn sich Attribute weiter zerlegen lassen.

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.