Ziel dieser Regel ist es, eine Tabelle auf die notwendigen Felder zu reduzieren und damit Anomalien zu vermeiden. Die Regel besagt: Die Felder der Tabelle beschreiben unteilbare Elemente, und ein Wert darf nicht mehrfach in einem Satz auftreten. Ist dies nicht erfüllt, sind die Felder in eine weitere Tabelle zu verlagern. Das Ganze soll an einem kleinen Beispiel demonstriert werden. Abb. 2.2 enthält die Struktur einer Tabelle mit Kundendaten.
Die Identifizierung der einzelnen Datensätze der Tabelle erfolgt über den Schlüssel Kunden-Nr., der in diesem Fall eindeutig ist. Neben den verschiedenen Feldern mit Kundendaten gibt es je zwei Felder mit den Namen und Telefonnummern der Ansprechpartner beim Kunden. Die Überlegung beim Entwurf war klar: Benennt mir der Kunde einen Ansprechpartner und einen Vertreter, müssen beide Informationen in die Tabelle mit aufgenommen werden.
Sehen wir uns einmal an, was diese an sich gute Idee für Probleme aufwirft. Gehen wir davon aus, dass der überwiegende Anteil Ihrer Kunden nur einen Ansprechpartner benennt. Dann müssen Sie zumindest dafür sorgen, dass die Tabelle leere Werte für die Felder mit dem zweiten Ansprechpartner akzeptiert. Gleichzeitig verschwenden Sie durch diese leeren Felder aber viel Platz in der Datenbank (haben alle Kunden nur einen Ansprechpartner, hätte ein Feld gereicht). Noch größere Probleme gibt es, falls ein Kunde auf drei oder mehr Ansprechpartnern besteht. Dann müssten Sie die Tabelle um weitere Felder erweitern.
Es kann ja nun sein, dass dies nicht sonderlich stört (Platz haben Sie genug). Dann sollten Sie sich aber über die folgende Anomalie klar werden: Der Kunde teilt Ihnen mit, dass ab sofort nur noch ein Ansprechpartner im Hause existiert. Sie müssen nun den Eintrag mit dem zweiten Ansprechpartner aus der Datenbank entfernen. Dies geschieht in der Regel, indem das Feld mit dem Wert gesucht und dann der zugehörige Satz gelöscht wird. Dies bringt aber gewichtige Probleme: Nicht nur der Name des ersten Ansprechpartners ist weg, sondern Sie löschen auch die kompletten Kundendaten. Liegen Aufträge für den Kunden vor, ist die ganze Datenbank plötzlich inkonsistent, da Liefer- und Rechnungsanschrift etc. nicht mehr existieren.
Hinweis: Sie könnten zwar den Inhalt des Felds mit dem zweiten Ansprechpartner auf Null setzen. Dies löst aber nicht den Fall, wenn mehrere Ansprechpartner vorhanden sind. Die Speicherung der Ansprechpartner in einer Tabelle Kunden führt auf jeden Fall zu einer Anomalie. Weiterhin kann es Anomalien beim Einfügen von Daten geben. Nehmen wir als Beispiel den Fall, dass der Vertrieb einen Ansprechpartner bei einem potenziellen Kunden gefunden hat. Dieser soll nun in die Kundenliste eingetragen werden, damit er Werbematerial erhält. Solange aber nichts bestellt wurde, weigert sich die Rechnungsprüfung, eine Kundennummer zuzuweisen (man möchte schließlich "`Karteileichen"' vermeiden). Jetzt können Sie diesen Ansprechpartner nicht in die Kundenliste eintragen. Ein Verzicht auf die Kundennummer ist nicht möglich, da dieses Feld als eindeutiger Schlüssel dient. Entweder wird der Kunde nicht gefunden, oder es gibt schnell mehrere Einträge für die fehlende Kundennummer.
Es gibt aber eine Lösung für das Problem: Sie müssen die Tabelle lediglich in die erste Normalform überführen. Die Felder mit den Ansprechpartnern sind zwar separat in der Tabelle gespeichert, es handelt sich bei den Einträgen aber um den gleichen logischen Wert. Demnach sind die Bedingungen der ersten Normalform verletzt. Die Lösung besteht darin, die Felder in eine getrennte Tabelle auszulagern. Die neue Struktur entspricht dann der Darstellung aus Abb. 2.3.
In der Tabelle Kunden finden sich nur noch Informationen, die eindeutig sind. Die Daten über den Ansprechpartner finden Sie dagegen in einer zweiten Tabelle mit dem Namen Ansprechpartner. Hier können Sie keinen oder beliebig viele Einträge für den Kunden eingeben. Wird ein Eintrag gelöscht, hat dies keine Auswirkungen auf die Daten der Tabelle Kunden. Selbst das Problem der fehlenden Kundennummer ließe sich in der Tabelle Ansprechpartner lösen, indem Sie ein weiteres Schlüsselfeld einführen.
Tipp: Es gibt durchaus aber Fälle, wo der Verzicht auf eine Normalisierung günstiger sein kann. Nehmen wir an, die Verwaltung von Kundendaten für Brillen soll auf eine Datenbank abgebildet werden. Neben dem Kundennamen wird für jede Brille die Stärke des linken und rechten Brillenglases gespeichert. Sie könnten dies natürlich gemäß obigem Beispiel in zwei Tabellen tun, denn die Stärke des Glases ist eine logische Größe. Eine Tabelle enthält die Kundennummer, Zusatzdaten und eine eindeutige Fertigungsnummer. In der zweiten Tabelle finden Sie unter dieser Fertigungsnummer die Einträge für die Glasstärke. Üblicherweise besitzen Brillen aber immer zwei Gläser, d.h. Sie müssen immer zwei Werte eintragen. Mit einer normalisierten Tabelle könnten Sie zwar auch drei Werte eingeben, aber ein solcher Fall ist doch eher unwahrscheinlich ... Hier bietet es sich an, innerhalb eines Datensatzes zwei Felder für die Stärke des linken und rechten Brillenglases einzuführen. Dann sparen Sie sich eine zweite Tabelle, und die Verwaltung der Daten wird einfacher.