Datenbank Normalisierung
Mit den Methoden der Normalisierung ist es möglich, ein redundanzfreies relationales Modell aus einer Objektsammlung zu erstellen. Hält man diese Regeln ein, ist eine spätere Erweiterung der Datenbank ohne Schwierigkeiten möglich. Welche Normalformen es gib, erfährst du in diesem Beitrag.
Zielsetzung der Normalisierung ist, das jedes Datenfeld nur einmal vorhanden ist. Dadurch werden Redundanzen beseitigt und die Datenkonsistenz bleibt erhalten. Auch sollen alle Abhängigkeiten zwischen den Spalten einer Tabelle beseitigt werden um eine einfache Erweiterung der Datenbank jederzeit gewährleisten zu können.
1. Normalform
Die erste Normalform besagt, dass jede Tabelle eine feste Breite besitzt. Jeder Datensatz hat somit die gleiche Anzahl an Attributen. Zudem muss jedes Attribut atomar, also allein stehend, sein. Dieser Zustand wird erreicht, in dem man den Datensatz in mehrere Tabellen aufteilt bzw. dupliziert.
Jedes Datenfeld darf nur einen Wert enthalten. Anschrift: „Dresdner Str. 15 01574 Nirgendsdorf“ ist also laut Definition unzulässig und muss in Strasse, Hausnummer. PLZ und Ort aufgeteilt werden um die erste Normalform herzustellen.
2. Normalform
Bevor man sich der zweiten Normalform widmet muss die erste erfüllt sein, dies ist Bedingung!
Jede Tabelle enthält nur Daten eines Themengebiets. Sollte dies nicht der Fall sein, müssen die Daten wie in der ersten Normalform weiter aufgeteilt werden.
Jeder Datensatz ist durch einen Primärschlüssel eindeutig identifizierbar. Es muss also für jede Tabelle ein Attribut gefunden werden, dass einmalig ist. Beispiel wäre eine Kundennummer oder eine ISBN-Nummer. Sollte es keine redundanzfreien Werte geben muss eine künstliche Spalte erstellt werden. Beliebt ist in diesem Zusammenhang eine ID-Spalte.
3. Normalform
Es muss erst die vorangegangene zweite Normalform erfüllt sein bevor die dritte in Kraft treten kann.
Alle Datenfelder dürfen nur vom Primärschlüssel abhängen. Es darf daher keine so genannten transitiven (kettenartige) Abhängigkeiten geben. Eine transitive Abhängigkeit besteht immer dann, wenn ein Attribut über ein anderes Attribut (also nicht direkt) vom Primärschlüssel abhängig ist.
Falsche Normalisierung
Sollten die Normalisierungsschritte nicht richtig oder in der richtigen Reihenfolge ausgeführt worden sein, kann es zu Mutationsanomalien kommen. An folgendem Beispiel sind die drei üblichsten Anomalien veranschaulicht:
| ArtNr | Bezeichnung | Kategorie |
| 1 | Pizza Salami | Pizza |
| 2 | Pizza Bolognese | Pizza |
| 3 | Käsecracker | Snacks |
Änderungs-Anomalie:
Beim ändern der Kategorie „Pizza“ in „Steinofenpizza“ könnte vergessen werden die Bezeichnung bei allen betroffenen Artikeln umzuschreiben. Bzw. könnten Schreibfehler auftreten und so zu Verwirrung und Datendurcheinander führen.
Löschanomalie:
Wenn angenommener Weise die “Käsecracker” der letzte Artikel in der Kategorie “Snacks” wären und man jenen Artikel löscht würde im gleichen Zug die Kategorie verschwinden. Es ist in unserem Beispiel also nicht möglich den Artikel zu Löschen ohne die Kategorie zu vernichten.
Einfügeanomalie:
Im Beispiel oben ist es nicht Möglich eine Kategorie hinzuzufügen ohne einen Artikel einzufügen.
Lösung für Einfügeanomalie:
In diesem Fall müsste es eine separate Tabelle “Kategorie” geben, deren Primärschlüssel als Fremdschlüssel in der Tabelle “Artikel“ auftaucht.
|
|
||||||||||||||||||||||||