Grundlagen der Normalisierung
Inhaltsverzeichnis
Was ist Normalisierung?
Nachdem E. F. Codd die Grundlagen relationaler Datenbanken geschaffen hatte, hat er sich mit der Vermeidung redundanter Daten im Relationenmodell beschäftigt, der Normalisierung. Aus diesen Überlegungen heraus entstanden Vorgaben für bestimmte Einschränkungen auf Tabellen, die in den so genannten Normalformen beschrieben sind (und natürlich auch den Kriterien für relationale Datenbanksysteme genügen).
Die Normalisierung ist eine weitere Technik zur Erstellung relationaler Datenbanken bzw. eine Möglichkeit zur Überprüfung des aus einem ER-Diagramm gewonnenen Relationenschemas. Bei einem sauberen Entwurf nach dem ER-Modell und Anwendung der Abbildungsregeln zur Überführung in das Relationenmodell befinden sich die erzeugten Relationen häufig schon in der 3. Normalform. Da aber beim Entwurf des semantischen Datenmodells die Attribute nicht systematisch daraufhin untersucht werden, ob sie nur elementare Werte enthalten und ob nicht unerwünschte funktionale Abhängigkeiten zwischen ihnen bestehen, sind die Normalformen nicht immer automatisch erfüllt. Es ist deshalb zweckmäßig, mit Hilfe der Normalformregeln zu überprüfen, ob die Relationen den Normalformen genügen.
Tabellen (Relationen) sollten letzlich so geplant werden, dass
- logische Widersprüche (Inkonsistenzen, Anomalien) in der Datenbasis und
- Datenredundanz (Mehrfachspeicherung gleicher Daten) vermieden sowie
- eine höchstmögliche Flexibilität und schneller Zugriff gewährleistet werden.
Durch die Normalisierung teilt man Tabellen in weitere Tabellen auf, um redundante Daten zu vermeiden. Die Aufteilung muss dabei verlustfrei sein, d.h. ein späteres Zusammensetzen der geteilten Tabelle über Fremd- und Primärschlüssel muss wieder zur ursprünglichen Tabelle führen, ohne dass dabei Informationen verloren gehen. Die Normalisierung wird in der Regel nach dem Erstellen des Relationenmodells verwendet, um dieses Modell noch einmal zu überprüfen. Die Normalisierung geht generell in zwei Schritten vor: Zunächst werden Wiederholgruppen entfernt und danach redundant gespeicherte Daten. Bevor wir uns im Einzelnen mit den Normalformen auseinandersetzen, müssen wir die Begriffe der funktionalen, der vollen funktionalen und der transitiven Abhängigkeit verstehen.
Funktionale Abhängigkeit von Attributen
Getränk
Bezeichnung Farbe Kaffee schwarz Coca-Cola schwarz Wasser --- Milch weiß
Zwischen den beiden Attributen Bezeichnung und Farbe des Objekttyps Getränk existiert eine Abhängigkeit in der Form, dass man auf Grund der Bezeichnung des Getränks eindeutig sagen kann, wie der Wert des Attributes Farbe ist. So weiß man, dass ein Getränk mit der Bezeichnung Kaffee für das Attribut Farbe den Wert schwarz haben muss. Umgekehrt ist diese Schlussfolgerung jedoch nicht möglich. Wenn man weiß, welche Farbe ein Getränk hat, kann man daraus nicht bestimmen, wie die Bezeichnung des Getränks ist. Es liegt hier also die gleiche Abhängigkeit vor, wie bei Primärschlüsseln. Der Wert des Primärschlüssels bestimmt eindeutig den Wert der anderen Attribute, in diesem Fall den Wert des Attributes Farbe. E. F. Codd schreibt in diesem Zusammenhang in Anlehnung an die Mathematik von funktionaler Abhängigkeit, da eine mathematische Funktion immer den gleichen Ausgabewert bei gleichen Eingabewerten liefert.
Die Funktion y = 2x liefert z.B. für den Wert x = 3 immer den Ausgabewert 6 für die Variable y. Für jede beliebige Zahl, die man für die Variable x einsetzt, ergibt sich also ein ganz bestimmter Wert für y. Man kann sagen, dass der Wert y abhängig ist vom Wert x bzw. x bestimmt y. Mathematisch spricht man auch von Determinante und schreibt: x → y.
Analog schreibt man also für die besprochene funktionale Abhängigkeit der Attribute Bezeichnung und Farbe:
Bezeichnung → Farbe
Das Attribut Farbe ist also funktional abhängig vom Attribut Bezeichnung.
Volle funktionale Abhängigkeit von Attributen
Unser Objekttyp Getränk erhält ein weiteres Attribut Geschmack und es werden diesmal die beiden Attribute Bezeichnung und Geschmack als Primärschlüssel festgelegt.
Getränk
Bezeichnung Geschmack Farbe Kaffee bitter schwarz Coca-Cola süß schwarz Wasser neutral --- Milch neutral weiß
Das Attribut Farbe ist weiterhin funktional abhängig vom Primärschlüssel. Wenn die Bezeichnung und der Geschmack eines Getränkes bekannt sind, dann ergibt sich daraus eindeutig die Farbe des Getränks. Wir können also schreiben:
Bezeichnung, Geschmack → Farbe
Betrachtet man die Abhängigkeiten zwischen Geschmack und Farbe, so stellt man fest, dass keine funktionale Abhängigkeit zwischen diesen beiden Attributen existiert. Ist der Geschmack eines Getränkes bekannt, so kann nicht eindeutig auf die Farbe geschlossen werden. Andererseits gilt nach wie vor für die Attribute Bezeichnung und Farbe, dass aufgrund der Bezeichnung eindeutig auf die Farbe geschlossen werden kann. In diesem Fall ist Farbe zwar funktional abhängig von dem zusammengesetzten Primärschlüssel Bezeichnung und Geschmack, auf das Attribut Geschmack kann jedoch verzichtet werden, um das Attribut Farbe eindeutig zu bestimmen.
Man spricht von voller funktionaler Abhängigkeit, wenn jedes Nichtschlüssel-Attribut nur durch den gesamten Primärschlüssel eindeutig bestimmt werden kann. In unserem Beispiel ist das nicht der Fall, da die Farbe auch dann eindeutig bestimmt werden kann, wenn das Attribut Geschmack nicht bekannt ist.
Die Forderung nach voller funktionaler Abhängigkeit steht in unmittelbarem Zusammenhang mit der Forderung nach einem minimalen Primärschlüssel.
Transitive Abhängigkeit von Attributen
Fahrzeug
Bezeichnung Typ Räder PS Käfer PKW 4 45 Hanomag II LKW 4 220 Vespa Light Motorroller 2 4 Suzuki GX Motorrad 2 150 Ford Focus PKW 4 65
In dieser gegebenen Relation Fahrzeug ist erkennbar, dass abhängig vom Primärschlüssel bestimmt werden kann, welchen Wert die anderen Attribute haben müssen. So bestimmt z.B. der Wert Vespa, dass es sich beim Fahrzeugtyp um einen Motorroller handelt, der 2 Räder und 4 PS haben muss. Da der Primärschlüssel aus nur einem Attribut besteht, müssen demnach auch alle Nichtschlüssel-Attribute voll funktional abhängig vom Primärschlüssel sein. Volle funktionale Abhängigkeit kann ja nur dann auftreten, wenn der Primärschlüssel aus zusammengesetzten Attributen besteht.
Untersucht man die Tabelle auf eventuell andere funktionale Abhängigkeiten, so erkennt man, dass, wenn der Fahrzeugtyp bekannt ist, man daraus die Anzahl der Räder ableiten kann. Das Attribut Räder scheint also voll funktional abhängig zu sein vom Fahrzeugtyp. Man spricht hier von einer transitiven Abhängigkeit, da folgende Schlussfolgerung gezogen werden kann: Wenn eine Vespa ein Motorroller ist und jeder Motorroller zwei Räder hat, dann hat auch die Vespa zwei Räder. Oder allgemeiner: Wenn A den Wert von B bestimmt und B den Wert von C bestimmt, dann bestimmt auch A den Wert von C.
Fassen wir noch einmal zusammen:
|
