Im sogenannten Normalisierungsprozess werden schrittweise einfachere Relationen in einer Datenbank erzeugt, um Redundanz zu vermeiden. Das bedeutet, dass wenn eine Datenbank vollständig normalisiert wurde, so muss bereits ein einzelner Verlust eines Datenbestandes zu einem Informationsverlust führen. Dies verhindert Mutationsanomalien und verringert den verwendeten Speicherplatz.
Eine Tabelle liegt in der ersten Normalform vor, wenn jeder Attributwert eine atomare, nicht weiter unterteilbare Dateneinheit ist und die Attribute nur
einfach Werte enthalten, also keine Listen, Mengen oder Wiederholungsgruppen.
Allerdings gibt es noch immer Redundanz, denn es gibt noch immer sich wiederholende Werte.
Eine Tabelle liegt in der zweiten Normalform vor, wenn sie in der 1NF ist und alle Nichtschlüsselattribute voll funktional vom Primärschlüssel abhängen.
Das heißt: Jedes Nichtschlüsselattribut ist aus dem Primärschlüssel ableitbar und nicht bereits von Teilen einer Attributkombination. Dafür müssen Merkmale,
die von einem solchen Teilschlüssel abhängig sind, mit diesem Teilschlüssel in eine eigene Tabelle zusammengefasst werden.
Allerdings lassen sich hier noch immer über einige Umwege funktionale Abhängigkeiten finden.
Eine Tabelle liegt in der dritten Normalform vor, wenn sie in der 2NF ist und jedes Schlüsselattribut nicht transitiv vom Primärschlüssel abhängig ist. Transitiv bedeutet, wenn über irgendeinen Umweg ein Attribut funktional von einem anderen abhängig ist. Das heißt, alle Attribute sind nur von ihrem (zusammengesetzten) Primärschlüssel abhängig und sind sonst unabhängig.
Hier ist ein Beispiel, wie eine Datenbank normalisiert wird. Es handelt sich um ein Fahrradgeschäft, das seine Kundendaten sichern möchte. Hier ist die Tabelle in der 0NF:
Knr | Name | Str | Ort | RahmenNr | Marke | Versicherung | VersicherungsOrt | ReparaturDatum | Diagnose |
---|---|---|---|---|---|---|---|---|---|
100 | Tim | Hofweg 6 | Ber | 123 432 |
Diamant Winora |
Allianz Signal |
Köln Mainz |
12.12.99 15.12.99 |
Platten Ölverlust |
101 | Moe | Klupf 5 | Ber | 690 | Kettler | Allianz | Köln | 14.12.99 | Schleicher |
Die erste Normalform zieht die Wiederholungsgruppen in einzelne Einträge:
Knr | Name | Str | Ort | RahmenNr | Marke | Versicherung | VersicherungsOrt | ReparaturDatum | Diagnose |
---|---|---|---|---|---|---|---|---|---|
100 | Tim | Hofweg 6 | Ber | 123 432 |
Diamant Winora |
Allianz Signal |
Köln Mainz |
12.12.99 15.12.99 |
Platten Ölverlust |
101 | Moe | Klupf 5 | Ber | 690 | Kettler | Allianz | Köln | 14.12.99 | Schleicher |
Die 2NF teilt die Attribute dann in unterschiedliche Tabellen auf, um Redundanz zu vermeiden:
Fahrräder:
RahmenNr | Knr | Marke | Versicherung | VersicherungsOrt |
---|---|---|---|---|
123 | 100 | Diamant | Allianz | Köln |
432 | 100 | Kettler | Allianz | Köln |
690 | 101 | Winora | Signal | Mainz |
Kunden:
Knr | Name | Straße | Ort |
---|---|---|---|
100 | Meyer | Hofweg 6 | Berlin |
101 | Müller | Klupf 5 | Berlin |
Reparaturen:
RahmenNr | ReparaturDatum | Diagnose |
---|---|---|
123 | 12.12.99 | Platten |
432 | 15.12.99 | Ölverlust |
690 | 14.12.99 | Schleicher |
Jedoch gibt es noch immer transitive Abhängigkeiten:
Rahmennummer → Versicherung → Ort der Versicherung
Diese werden nun in der 3NF behoben. Die Tabellen Kunden und Reparaturen bleiben unverändert, jedoch werden die Versicherungen aus den Fahrrädern rausgeholt:
Fahrräder:
RahmenNr | Knr | Marke | Versicherung |
---|---|---|---|
123 | 100 | Diamant | Allianz |
432 | 100 | Kettler | Allianz |
690 | 101 | Winora | Signal |
Versicherungen:
Versicherung | Ort der Versicherung |
---|---|
Allianz | Köln |
Signal | Mainz |
Diese Seite entspricht noch nicht den Ansprüchen, die wir für diese Website haben.
Grund: Erklären: was ist eine Redundanz (13/14 6.3.1) & Datenkonsistenz (heißt keine widersprüchlichen Daten)
Falls du eine Idee hast, wie man dieses Problem beheben könnte, kontaktiere uns bitte über den Link Hilf mit!
in der grauen Footer-Leiste unten.