Normalformen
| Der Aufbau relationaler Datenbanken, ersichtlich in den Inhalten ihrer Tabellen und deren Beziehungen untereinander, zielt in erster Linie auf die Vermeidung von Redundanzen ab. Sogenannte Normalformen können als Gesetze zur Konstruktion von Tabellen betrachtet werden, deren Einhaltung zur weitgehenden Vermeidung von Redundanzen führen. Die Normalformen sind Gegenstand des folgenden Lernschrittes. |
Der Sinn der Normalisierung
Bei der Aufgabe, eine Datenbank anzulegen, wird man mit mehreren Fragen konfrontiert.
- Wie viele Tabellen sind sinnvoll?
- Was soll darin dargestellt werden?
- Wie viele Spalten sollen in welcher Tabelle angelegt werden?
Die Antwort auf diese Fragen gibt mitunter die sogenannte Normalisierung. Mit Hilfe der Regeln der Normalisierung wird es möglich, das Datenbankmodell ideal zu strukturieren. Dadurch werden Redundanzen vermieden: Diese erfordern nämlich nicht nur einen größeren Speicherbedarf, sondern führen auch zu einer erhöhten Fehleranfälligkeit, beispielsweise bei Wartungstätigkeiten. Sollen Daten, die an mehr als einem Speicherort vorhanden sind, geändert werden, müssen diese Änderungen an allen Speicherorten auf exakt die gleiche Art und Weise vorgenommen werden. So ist beispielsweise die Änderung einer Kundenandresse wesentlich einfacher, wenn die betreffenden Daten nur in der Tabelle Kunde gespeichert sind und nicht auch noch an anderen Orten innerhalb der Datenbank.
Normalisieren der Tabellen
Bei der Überführung der Objektklassen in Tabellen sind diese daraufhin zu prüfen, ob sie Abhängigkeiten der Felder untereinander bzw. Redundanzen aufweisen. Normalisiert wird, indem man schrittweise überprüft, ob die gebildeten Tabellen den Bedingungen der Normalformen entsprechen. Im Verlauf dieses Normalisierungsprozesses kommt es zu einer Reduzierung der Redundanzen, parallel dazu jedoch auch zu einer Vermehrung der Anzahl der Tabellen. Immer dann, wenn Redundanzen entdeckt werden, führt dies zur Bildung neuer Tabellen, die über die Schlüsselfelder miteinander verbunden werden (siehe Beziehungen in Datenbanken). Die Anpassung der Tabellen an die Normalformen dient auch der mengentheoretischen Grundlage von SQL. Die Anwendung von drei Normalformen wird aus Gründen des Antwortzeitverhaltens der Datenbank empfohlen. Die Datenbanktheorie unterscheidet zwar weitere Normalformen, diese werden aber in der Praxis nur selten angewendet.
Erste Normalform: Entfernen von Wiederholgruppen
Jedes Feld darf im Datensatz nur einmal vorkommen. Gibt es mehrere Felder vom gleichen Typ, so müssen diese in einer eigenen Tabelle gespeichert werden.
Die Überführung der Objektklasse Auftrag in eine Tabelle könnte der verbalen Beschreibung des Geschäftsmodells entsprechend „Jeder Auftrag kann mehrere Bücher enthalten, die jeweils in beliebiger Menge geordert werden können“ bzw. in Anlehnung an das ER-Diagramm folgende Struktur aufweisen:
- Auftrag (Nr, Kundennummer, Datum, Positionsnummer, Buchnummer, Menge, Positionsnummer, Buchnummer, Menge, ...)
Da ein Auftrag in der Regel mehrere unterschiedliche Bücher in unterschiedlichen Mengen enthält, kommen die Felder Buchnummer und Menge mehrfach vor, was der ersten Normalform widerspricht. Die Konsequenz daraus ist die Auslagerung der Wiederholgruppen in eine eigene Tabelle Auftragspos (abgeleitet von Auftragsposition) und die Verbindung der Tabellen über entsprechende Schlüsselfelder.
Das Feld Nr in der Tabelle Auftrag (Auftrag.Nr) ist das Schlüsselfeld der Tabelle Auftrag und wird daher mit dem Feld Auftragsnummer der Tabelle Auftragsposition verbunden. Die Namen der beiden Felder unterscheiden sich zwar, aber der Inhalt ist in beiden Fällen ident. Hier zeigt sich eine unvermeidbare Redundanz in relationalen Datenbanken, weshalb man auch von kontrollierter Redundanz und nicht von redundanzfrei spricht.
Für die Erfüllung der im Geschäftsmodell beschriebenen Aufgaben (z. B. Rechnungslegung) sind detaillierte Daten über die Bücher (z. B. der Preis) erforderlich. Wie auch aus dem ER-Diagramm ersichtlich ist, gibt es eine Verbindung zwischen der Tabelle Auftrag und der Tabelle Buch über die neu gebildete Tabelle Auftragspos. Die Notwendigkeit zur Neubildung einer Tabelle zwischen Auftrag und Buch ist auch aus ihrer m:n-Beziehung ableitbar.
Die Auftragspos.Nr der Tabelle Auftragspos ist als Primärschlüssel nicht zu gebrauchen, sie dient lediglich der Kennzeichnung der einzelnen Auftragspositionen eines Auftrages, z. B. zum Zwecke der Reihung auf Lieferscheinen oder Rechnungen. Der Primärschlüssel der Tabelle Auftragspos setzt sich vielmehr aus den Feldern Auftragspos.Auftragsnummer und Auftragspos.Buchnummer zusammen. Es handelt sich um einen Kombinationsschlüssel. Auch dieses Auftreten von Kombinationsschlüsseln ist für die normalformengerechte Auflösung von m:n-Beziehungen typisch.
Zweite Normalform: Entfernen von Attributen, die nur von einigen der identifizierenden Attribute abhängen
Zu den Bedingungen der 1. Normalform gilt zusätzlich: In Relationen mit einem Kombinationsschlüssel muss jedes Feld vom gesamten Kombinationsschlüssel abhängen. Felder, die nur von einem Teil des Schlüssels abhängen, werden mit diesem als Schlüssel in einer eigenen Relation gespeichert.
Die Tabelle Auftragspos besitzt einen Kombinationsschlüssel, wie in der Abbildung zuvor ersichtlich ist. Da aber der Entwurf der vorliegenden Datenbank mit der Erstellung eines ER-Diagramms begonnen hat, befinden sich in dieser Tabelle keine Felder, die der 2. Normalform widersprechen. Es können jedoch in Frage kommende Erweiterungen der gegenständlichen Tabelle als Erläuterung am Beispiel herangezogen werden.
Geht man z. B. davon aus, dass nicht alle Positionen eines Auftrags sofort geliefert werden können und sind Teillieferungen geplant, so wäre das Datum der Auslieferung (wohlgemerkt der gesamten bestellten Menge, keine Teilmengen) ein Feld, welches die Bedingung der 2. Normalform erfüllte.
Für den Fall, dass Preisnachlässe in Form von Rabatten gewährt werden, könnte ein weiteres Feld mit der Bezeichnung Rabatt angefügt werden. Diese Art der Gewährung von Rabatten bedeutet, dass der Preisnachlass einmalig und nur für ein bestimmtes Produkt gewährt wird. Ebenso könnte ein Feld Rabatt der Tabelle Buch, der Tabelle Kunde oder der Tabelle Auftrag angefügt werden, ohne die Normalformen zu verletzen. Die Bedeutung der alternativen Platzierung ist jedoch sehr unterschiedlich. Das Feld Rabatt in der Tabelle Kunde bewirkt, dass alle Einkäufe des jeweiligen Kunden mit einem Preisnachlass versehen werden, während das besagte Feld in der Tabelle Buch Preisnachlässe für alle Kunden nach sich zieht.
Diese Variationsmöglichkeiten zeigen deutlich, dass die formale Korrektheit einer relationalen Datenbank nicht ohne das zugrundeliegende Geschäftsmodell bzw. deren Prozesse überprüft werden kann.
Dritte Normalform: Vermeidung von transitiven Abhängigkeiten
Zu den Bedingungen der 2. Normalform gilt zusätzlich: Felder, die nicht Teil des Schlüssels sind, dürfen nicht untereinander abhängig sein; ist dies der Fall, so müssen diese in einer eigenen Relation gespeichert werden.
Gemäß dem angestellten ER-Diagramm fehlen dem Datenmodell noch die entsprechenden Tabellen für die Kunden und Verlage. Beide enthalten Felder für die Adresse, nämlich Plz, Ort und Straße (Letzteres enthält auch die Hausnummer).
Berücksichtigt man die Zustellbezirke der Post, so kann festgestellt werden, dass jeder Postleitzahl eindeutig ein Zustellbezirk (zur zeitweiligen Verwirrung auch "Ort" genannt) zugeordnet werden kann. Das Feld Ort hängt demnach vom Feld Plz ab und muss ausgelagert werden. Die ohne Berücksichtigung der 3. Normalform also falsch konstruierte Tabellen wären:
- Verlag (Kurzbezeichnung, Name, Kundennummer, Strasse, Plz, Ort)
- Kunde (Nr, Vorname, Nachname, Strasse, Plz, Ort)
Adressen werden des Feldes Ort entledigt und es entsteht eine neue Tabelle mit der Bezeichnung PLZ und den Spalten Plz, Ort und Region.
Das endgültige, den Normalformen 1 bis 3 unterworfene Datenmodell zeigt folgende Struktur:
Literatur
Quellen
R. Elmasri, S. B. Navathe: Grundlagen von Datenbanksystemen. Ausgabe Grundstudium. Pearson Studium 2005
Weiterführende Links
Zitiervorschlag
Mittendorfer in Höller, Informationsverarbeitung, Normalformen (mussswiki.idb.edu/ivwiki)