Erstellung und Normalisierung eines Datenmodells in einer relationalen Datenbank wie Access
Normalisierung ist eine Entwurfstechnik, die dazu dient,
Tabellen auf mehrfach gespeicherte Daten (Redundanzen), Konsistenz und Korrektheit zu überprüfen.
Normalisierung ist also die Überführung des Datenmodells in einen bestimmten
Zustand. Dieser Zustand wird durch die Nummer der so genannten Normalform unterschieden.
Meistens genügt das Erreichen der dritten Normalform, um Redundanz und Inkonsistenzen
vorzubeugen und dadurch die Wartung der enthaltenen Daten zu vereinfachen.
Die Möglichkeit, Redundanzen und Inkonsistenzen zu vermeiden, ist eine der Haupteigenschaften
von relationalen Datenbanksystemen.
Beispiele für das Umwandeln nicht normalisierter Tabellen in die jeweilige Normalform:
Die erste Normalform
Ein Relationstyp ist in der 1. Normalform, wenn alle Attribute maximal einen Wert haben. Am Kreuzpunkt einer Spalte mit einer Reihe darf also maximal ein Datenwert stehen.
Das Nichtvorhandensein von Daten ist zulässig. Wiederholungsgruppen sind nicht erlaubt.
Die erste Normalform fordert also, dass jede in einem Feld gespeicherte Information atomar
ist und nicht mehr in weitere Informationen unterteilt werden kann. Dadurch erreicht
man, dass die enthaltenen Werte einfach abgefragt oder sortiert werden können.
Beispiele für nicht atomare Informationen sind Vorname und Nachname oder Straße, Hausnummer, PLZ und Ort.
Wenn eine Tabelle ein Feld mit der Bezeichnung Name enthält und dieses sowohl den Vor- und den Nachnamen (in dieser Reihenfolge)
wiedergibt, kann man beispielsweise nur schwer nach dem Nachnamen sortieren. Vor- und der Nachname sind daher unbedingt
in zwei Feldern zu speichern.
| Nicht normalisierte Tabelle | Normalisierte Tabelle |
|
|
Die zweite Normalform
Ein Relationstyp ist in der 2. Normalform, wenn er in der 1. Normalform ist und jedes Attribut vom gesamten Primärschlüssel abhängt.
Relationstypen, die in der 1. Normalform sind, sind automatisch in der 2. Normalform, wenn ihr Primärschlüssel nicht zusammengesetzt ist.
Die zweite Normalform besagt also, dass alle Felder einer Tabelle vom Primärschlüssel beziehungsweise
vom ganzen Primärschlüssel abhängig sein müssen.
Wenn man beispielsweise Kunden und Lieferanten in einer Tabelle verwaltet, ist jeder
Datensatz der Tabelle durch die Kombination der Felder Kunde_ID und Lieferant_ID
eindeutig identifizierbar.
Wenn man die Felder der Tabelle auf ihre Abhängigkeit vom Primärschlüssel untersucht,
stellt man schnell fest, dass nicht alle vom ganzen, also zusammengesetzten Primärschlüssel,
abhängen. Die Kundendaten sind zwar vom Primärschlüsselfeld Kunde_ID abhängig,
aber nicht vom Feld Lieferant_ID.
Dadurch kann derselbe Kunde mehrmals in der Tabelle auftreten. Dieser Zustand heißt Redundanz.
Unter diesen Bedingungen ist die Konsistenz der Daten gefährdet.
Sobald man Informationen zu einem Kunden nur in einem der Datensätze ändert, ist die Konsistenz dahin und die Integrität der Daten verloren.
Die Gefahr von Redundanzen und Inkonsistenzen lässt sich beheben, indem man die
Daten so auf mehrere Tabellen aufteilt, dass alle Felder der Tabellen vom jeweiligen
Primärschlüsselfeld beziehungsweise vom aus mehreren Feldern zusammengesetzten
Primärschlüssel abhängen. Im diesem Beispiel gibt es zwei Primärschlüssel Kunde_ID und Lieferant_ID,
die beide abhängige Felder aufweisen. Die Notwendigkeit einer zweiten Tabelle ist offensichtlich.
Tabellen mit ausschliesslich vom Primärschlüsseln abhängigen Feldern:
Beziehung zwischen den Tabellen tbl_Kunde und tbl_Lieferanten
Die dritte Normalform
Die 3. Normalform ist erfüllt, wenn die 2. Normalform erfüllt ist und die Nicht-Schlüssel-Attribute funktional unabhängig voneinander sind.
Folglich: Die dritte Normalform sorgt dafür, dass es keine transitiven Abhängigkeiten innerhalb einer Tabelle gibt.
Alle Nicht-Schlüssel-Felder müssen direkt vom Primärschlüssel der Tabelle abhängig sein. Oder andersherum: Es darf kein Feld geben, das Detailinformationen
über ein anderes Feld enthält. Um sicherzugehen, dass eine Tabelle der dritten Normalform entspricht, prüft man, ob die Daten aller Felder mit Ausnahme des Primärschlüssels
einzeln geändert werden können, ohne dass ein weiteres Feld in dieser Tabelle davon betroffen ist.
Ein Beispiel: Die Tabelle Projekt_Projektleiter enthält neben dem Primärschlüsselfeld einige Felder, die von diesem abhängig sind.
Im Falle des Feldes Projektleiter besteht allerdings nur eine indirekte Abhängigkeit, da der Projektleiter zunächst vom Feld Projekt abhängt.
Tabelle nicht in der dritten Normalform
Lösung: Das Projekt samt Projektleiter wird in eine eigene Tabelle ausquartiert.
Das Ergebnis sieht wie im Datenmodell unten aus:
Tabelle in der dritten Normalform
Die vierte Normalform
Die 4. Normalform ist erfüllt, wenn die 3. Normalform erfüllt ist und wenn keine paarweise auftretenden mehrwertigen Abhängigkeiten vorhanden sind.
Sind A, B und C Attribute eines Relationstypes, so ist C mehrwertig abhängig von A, falls für jeden Wert von A
für alle Werte von B, die zusammen mit diesem Wert von A auftreten, jeweils die gleiche Wertemenge von C auftreten muß.
Für verschiedene Werte von A können unterschiedliche Wertemengen von C auftreten.
Bei Verstoß gegen die 4. Normalform können "Gruppeninkonsistenzen" auftreten.
Die fünfte Normalform
Ein Relationstyp ist in der 5. Normalform, wenn er in der 4. Normalform ist und er sich unter keinen
Umständen durch Kombination einfacherer Relationstypen mit unterschiedlichen Schlüsseln bilden läßt.
Denormalisierung der Tabellen
Im Prinzip kann man die Tabellen, die man nach den fünf Normalisierungen erhalten hat, 1:1 in der Datenbank verwenden.
Es ist jedoch zu prüfen, ob man in der Normalisierungswut die Tabellen nicht zu sehr auseinandergerissen hat.
Tabellen, die denselben Primärschlüssel haben, können ohne weiteres zusammengelegt werden, ohne gegen eine Normalisierungsformen zu verstoßen.
Nur bei umfangreichen Datenbeständen mit hohen Zugriffszahlen empfiehlt es sich, aus Performancegründen
eine gewisse Denormalisierung herzustellen.
Access Tipps →
Office Tipps →
Startseite →
