Für die Nutzung und Wartung eines relationalen Datenbanksystems (DBS) sind sauber strukturierte Daten von Vorteil.
Denn bei der Nutzung können Schwächen, also Anomalien auftreten, die es zu verhindern gilt. Das wären zum Beispiel
- Die Einfügeanomalie tritt auf, wenn es aufgrund von fehlenden Attributwerten nicht möglich ist, neue Daten in die Tabelle einzufügen.
- Die Änderungsanomalie tritt auf, wenn Änderungen an einem Attributwert in einer Zeile zu Inkonsistenzen in anderen Zeilen führen.
- Die Löschungsanomalie tritt auf, wenn das Löschen von Daten in einer Tabelle versehentlich auch andere, relevante Daten löscht oder wenn das Löschen von Daten zu einer fehlenden Information führt.
Um die oben genannten Anomalien zu verhindern, wird der Normalisierungsprozess eingesetzt.
Normalisierung der 1. Normalform
Eine Relation ist in der 1. Normalform, wenn jeder Wert in jeder Spalte des Tabellenentwurfs atomar ist, d.h. keine mehrwertigen Attribute enthält. Es dürfen also keine Spalten mit mehreren Werten in einer Zeile vorhanden sein.
Normalisierung der 2. Normalform
Eine Relation ist in der 2. Normalform, wenn sie bereits in der 1. Normalform ist und kein Teil der Primärschlüssel-Funktionsabhängigkeit von einer Teilmenge der Attribute abhängt. Das bedeutet, dass jede Nichtschlüssel-Spalte von der gesamten Primärschlüssel abhängt, nicht von einem Teil davon.
Normalisierung der 3. Normalform
Eine Relation ist in der 3. Normalform, wenn sie bereits in der 2. Normalform ist und keine transitive Abhängigkeiten existieren. Das bedeutet, dass eine Nichtschlüsselspalte nicht von einer anderen Nichtschlüsselspalte abhängen kann, sondern nur von der Primärschlüsselspalte.
Die Normalformen sind wichtig, um Datenredundanz und -inkonsistenzen zu vermeiden und die Datenkonsistenz und -integrität sicherzustellen.
Beispiel zur Normalisierung
Angenommen, wir haben eine Tabelle „Studenten“ mit den folgenden Spalten:
- Matrikelnummer (Primärschlüssel)
- Name
- Geburtsdatum
- Studienfach
- Modul1-Name
- Modul1-Note
- Modul2-Name
- Modul2-Note
- Modul3-Name
- Modul3-Note
Diese Tabelle ist nicht in der 1. Normalform, da die Spalten „Modul1-Name“, „Modul1-Note“, „Modul2-Name“, „Modul2-Note“, „Modul3-Name“ und „Modul3-Note“ mehrwertige Attribute enthalten. Wir können die Tabelle in zwei separate Tabellen aufteilen: eine für die Studenteninformationen und eine für die Modulinformationen.
- Tabelle „Studenten“ (Primärschlüssel: Matrikelnummer)
- Matrikelnummer (Primärschlüssel)
- Name
- Geburtsdatum
- Studienfach
- Tabelle „Module“ (Primärschlüssel: Modul-ID, Fremdschlüssel: Matrikelnummer)
- Modul-ID (Primärschlüssel)
- Matrikelnummer (Fremdschlüssel)
- Modul-Name
- Modul-Note
Jetzt befindet sich die Tabelle „Studenten“ in der 1. Normalform, da alle Spalten atomar sind. Die Tabelle „Module“ ist in der 2. Normalform, da alle Nichtschlüsselspalten von der gesamten Primärschlüssel-Spalte „Modul-ID“ abhängig sind.
Die Tabelle „Module“ ist jedoch noch nicht in der 3. Normalform, da die Spalte „Modul-Name“ und „Modul-Note“ von der Teilmenge der Spalte „Modul-ID“ und „Matrikelnummer“ abhängen, anstatt von der gesamten Primärschlüsselspalte „Modul-ID“ abhängig zu sein. Wir können die Tabelle erneut aufteilen:
- Tabelle „Module“ (Primärschlüssel: Modul-ID, Fremdschlüssel: Matrikelnummer)
- Modul-ID (Primärschlüssel)
- Modul-Name
- Tabelle „Noten“ (Primärschlüssel: Modul-ID, Matrikelnummer)
- Modul-ID (Primärschlüssel, Fremdschlüssel)
- Matrikelnummer (Primärschlüssel, Fremdschlüssel)
- Modul-Note
Jetzt hängen alle Nichtschlüsselspalten von der gesamten Primärschlüssel-Spalte „Modul-ID, Matrikelnummer“ ab, und die Tabelle „Module“ und „Noten“ befinden sich in der 3. Normalform.