Normalisierung von Datenbanken

Relationale Datenbanken sollten auch über Relationen, das heißt Beziehungen zwischen Tabellen verfügen. Nur so lassen sich auch große Datenmengen verwalten, ohne redundante Daten zu erzeugen. Der Weg von einer Gesamtdatenmenge, die in der Regel Redundanzen enthält, zu einer redundanzfreien Form, wird als Normalisierung bezeichnet.

Die Normalisierung verfolgt mehrere Ziele:

• Redundanzen sollen vermieden werden, um Speicherplatz zu sparen.

• Anomalien also Widersprüchlichkeiten in der Datenbank sollen verhindert werden.

• Der Wartungsaufwand soll verringert und die Konsistenz gewährleistet werden.

Problemfall Redundanzen

Redundante Daten, also Daten, die entweder in mehreren Tabellen gleichzeitig gespeichert sind oder innerhalb einer Tabelle mehrfach vorkommen, verursachen nicht nur bei der Wartbarkeit der Daten große Probleme. Sie erhöhen ganz erheblich die Datenmenge, weil eben überflüssiger Weise gleiche Daten mehrfach gespeichert werden müssen. Die folgende Abbildung verdeutlicht das.

Hier werden Daten einer Sportveranstaltung eines Sportvereins gespeichert. Für jede Veranstaltung können dabei beliebig viele Teilnehmer definiert werden.

Doppelte und inkonsistente Daten

Das Problem dabei ist, dass für jeden Teilnehmer nicht nur dessen Daten gespeichert sind, sondern auch die der ganzen Veranstaltung, wie Richter, Termin, Ort oder Meldeschluss.

Auch bei der Wartung bereiten diese Redundanzen natürlich erheblichen Aufwand. Nehmen Sie an, für die Veranstaltung ändert sich der Name des Richters. Dann müssen Sie diese Änderung nicht nur in einem Datensatz vornehmen, sondern in mehreren, womöglich in mehreren hundert.

Tritt dabei ein Fehler auf oder vergessen Sie, einen Datensatz zu ändern, entstehen dabei inkonsistente Daten. Das heißt, die Daten in mehreren Datensätzen widersprechen sich. Sie können dann unter Umständen nicht mehr ermitteln, welche Daten die falschen und welche die richtigen sind.

Normalisierung

Die Normalisierung dient dazu, eine Datenbank mit Redundanzen schrittweise in eine so genannte Normalform zu überführen. Es gibt fünf Normalformen, die schrittweise aufeinander aufbauen.

Bei relationalen Datenbanken ist allerdings oft schon bei der dritten Normalform ein Punkt erreicht, an dem durch die Normalisierung mehr Daten zur Gewährleistung der Verknüpfungen geschaffen werden, als durch Redundanzen vermieden werden. Zudem verlangsamen zu viele kleine Tabellen mit vielen Verknüpfungen die Abfrage und Verarbeitung von Daten.

Daher wird in relationalen Datenbanken die Normalisierung in der Regel nur bis zur dritten Normalform durchgeführt. Ausgangspunkt für das nachfolgende Beispiel ist die folgende Tabelle, in der wieder die Daten für eine Prüfung eines Sportvereins gespeichert sind. Die Teilnehmer und die dazu gehörenden Hunde werden nacheinander durch das Zeichen „/“ getrennt in den Feldern Teilnehmer und Hunde gespeichert.

Die erste Normalform

Eine Datenbank befindet sich dann in der ersten Normalform, wenn keine Spalte in sinnvolle Teile untergliedert werden kann und in den Spalten nicht mehrere Unterdatensätze gespeichert werden.

Aus diesem Grund verletzt die vorliegende Tabelle die erste Normalform in mehrfacher Hinsicht:

• Die Spalte Veranstalter speichert neben dem Namen auch die Nummer des Vereins

• Die Spalte Termin_Richter speichert neben dem Termin auch den Namen und die Nummer des Richters

• Die Spalten Teilnehmer und Hunde speichern jeweils zwei Datensätze, die wiederum aus mehreren Feldern bestehen.

Um die Tabelle in die erste Normalform zu überführen, müssen Sie diese Fehler also beheben und die separaten Felder für die Vereinsnummer, den Richter und die Richternummer ergänzen. Außerdem müssen Sie für Teilnehmer und Hunde ebenfalls separate Felder erstellen.

In der ersten Normalform sind die Redundanzen noch nicht entfernt. Dafür können die Daten aber nun besser sortiert und gewartet werden. Auf alle benötigten Daten können Sie einzeln zugreifen.

Die zweite Normalform

Die zweite Normalform ist erfüllt, wenn alle Felder, die nicht Primärschlüssel sind, vom gesamten Primärschlüssel abhängig sind. In der Praxis sind also die Daten einer Tabelle so aufzuteilen, dass alle Felder vom Primärschlüssel der Tabelle abhängig sind.

Möchten Sie die Daten in die zweite Normalform überführen, müssen Sie sie also auf so viele Tabellen aufteilen, dass Redundanzen entfallen und alle Feldwerte durch einen Primärschlüssel eindeutig identifiziert werden können. Für das Beispiel bedeutet dies, dass hierdurch vier Tabellen entstehen:

• Daten zur Prüfung

• Daten zum Richter

• Daten zu den Hunden

• Daten zu den Teilnehmern

In der Praxis müssen diese Daten dann natürlich wieder zusammengefügt werden, um Teilnehmer, Hunde und Richter einer Prüfung zuzuordnen. Dazu definieren Sie Beziehungen zwischen den Tabellen und nehmen in einer fünften Tabelle die Zuordnungen vor.

Die dritte Normalform

Die dritte Normalform liegt dann vor, wenn sich die Daten in der zweiten Normalform befinden und es zusätzlich keine Felder gibt, die von anderen Feldern als dem Primärschlüssel abhängen.

Ob die Daten davon abhängen ist allerdings keine reine Definitionsfrage, sondern auch eine Frage der Interpretation der Daten. Bezogen auf das Beispiel bedeutet dies bei Betrachtung der Tabelle tabTeilnehmer folgendes:

Die Tabelle speichert Teilnehmerdaten. Das sind neben den persönlichen Daten wie der Anschrift auch eine Teilnehmernummer im Feld TN_Nr, die dem Vereinsmitglied vom übergeordneten Verband zugeteilt wurde. Einerseits könnte diese Nummer als Primärschlüssel dienen, weil Sie das Mitglied eindeutig identifiziert. Andererseits ist diese Nummer eventuell auch nicht vorhanden.

Damit ist sie von der Person abhängig und kann nicht als Primärschlüssel dienen. Beide alternativen Bedeutungen des Feldwertes wirken sich darauf aus, wie Sie die Datenbank in die dritte Normalform überführen.

Überführen in die dritte Normalform

Unter der Annahme, dass nur Mitglieder Prüfungsteilnehmer sein können, könnte die Datenbank in die dritte Normalform überführt werden, indem das Feld ID entfällt und statt dessen das Feld TN_Nr zum Primärschlüssel wird. Dann würden alle anderen Felder vom Primärschlüssel abhängig sein.

Müssen Prüfungsteilnehmer nicht zwingend Mitglied sein, so haben manche keine Teilnehmernummer. Dann ist das Feld TN_Nr abhängig vom Teilnehmer, der durch das Feld ID identifiziert sind. Wenn Sie bei dieser Annahme die Datenbank in die dritte Normalform überführen, müssen Sie die Tabelle teilen und über die ID verknüpfen. Damit wären alle Daten nun vom Primärschlüssel der Tabelle abhängig.

Daten interpretieren

Fraglich ist in diesem Fall, ob die Daten wie die Anschrift nicht als abhängig von Vor- und Nachname angesehen werden können. Dafür spricht sicherlich, dass jeder Kombination aus Vor- und Nachname eine Adresse zugeordnet werden kann.

Dagegen spricht allerdings, dass Vor- und Nachname eine Person nicht eindeutig kennzeichnen, dazu müsste mindestens noch ein Geburtsdatum kommen. Schließlich kann es in zwei Orten und sogar in einem Ort zwei Franz Müller geben. Die haben dann in der Regel unterschiedliche Anschriften.

Würde man die Anschrift als abhängig von Namen ansehen, läge hier ein logischer Fehler vor, der inkonsistente Daten zur Folge hätte. Insofern sollte man die Adresse als abhängig von der ID sehen, die hier den Teilnehmer eindeutig kennzeichnet.

Fazit

Sie können schon hier sehen, dass auch Interpretationsfragen darüber entscheiden, ob eine Datenbank in der dritten Normalform vorliegt. Ist das nicht der Fall, stellt sich darüber hinaus die Frage, ob die Überführung in die dritte Normalform notwendig ist, um eine Datenbank mit maximaler Performance zu erhalten.

Oft ist dazu eine Datenbank in der zweiten Normalform wesentlich besser geeignet, weil hier weniger kleine Tabellen und weniger Beziehungen erforderlich sind, die in Abfragen und Berichten sowie beim Speichern der Daten die für unnötige Performanceverluste bringen.