Normalisierung, Teil 1: Die erste Normalform

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

Der Entwurf eines Datenmodells und den darin enthaltenen Tabellen und Beziehungen erfordert vor allem eines: Das Berücksichtigen der Normalformen. Dies sind Regeln, mit denen Sie die benötigten Felder auf verschiedene Tabellen aufteilen. Dabei ist das Ziel, redundante Daten auszuschließen und Inkonsistenzen zu verhindern. Diese Artikelreihe beschreibt die wichtigsten Normalformen und wie Sie diese in der Praxis anwenden. Im ersten Teil schauen wir uns die erste Normalform an, mit der wir dafür sorgen, dass jedes Feld atomare Informationen enthält.

Beispieldatenbank

Die Beispiele dieses Artikels finden Sie in der Datenbank 2005_Normalisierung.accdb.

Ausgangssituation

Daten werden nicht nur in den Tabellen von Datenbankanwendungen gespeichert, sondern auch an vielen anderen Orten – in Excel-Tabellen, Textdateien, XML-Dateien und so weiter.

Dabei können Daten redundant gespeichert werden. Ein Beispiel sind die Informationen über Kunden und Projekte. Angenommen, Sie speichern die Projekte in einer Excel-Tabelle und tragen darin gleichzeitig noch die Kundendaten ein. Dann landet ein Projekt mit dem dazugehörigen Kunden in einer einzigen Zeile. Diese enthält Projektdaten wie Projektnummer, Projektbezeichnung und Projektstart, aber auch Kundendaten wie Kundennummer, Kundenanschrift, Ansprechpartner et cetera.

Nun legen Sie weitere Projekte mit Kundendaten in dieser Tabelle an. Irgendwann führen Sie ein zweites Projekt für einen Kunden durch. Hier beginnen die Probleme: Sie haben dann zwei Zeilen in der Tabelle, welche die gleichen Kundendaten enthalten.

Wenn der Kunde Ihnen nun eine Adressänderung mitteilt, führen Sie die notwendige Änderung auch in der Tabelle mit den Projekt- und Kundendaten durch. Allerdings müssen Sie die Änderungen direkt in allen Zeilen durchführen, die Projekte für diesen Kunden enthalten. Tritt dabei nun ein Fehler auf, erhalten Sie eine Inkonsistenz. Diese wirkt sich im schlimmsten Fall so aus, dass Sie nach allen Projekten eines Kunden suchen und diese nicht mehr finden. Das kann passieren, wenn Sie beispielsweise nach dem Kundennamen Schmidt GmbH & Co. KG suchen, aber diese Firmenbezeichnung in der Excel-Tabelle einmal mit & und einmal mit und geschrieben haben (Schmidt GmbH und Co. KG).

Solche Inkonsistenzen und Redundanzen können überall auftauchen, wo sich redundante Daten befinden. Ein anderes Beispiel sind Lookup-Daten: Normalerweise würden Sie etwa die Kategorien von Produkten in einer eigenen Tabelle namens tblKategorien speichern und in der Produkte-Tabelle ein Fremdschlüsselfeld verwenden, um die Kategorie des Produkts festzulegen. Alternativ und vermeintlich vereinfachend könnte man auch einfach ein Feld namens Kategorie zur Produkte-Tabelle hinzufügen. In dieses trägt man dann direkt die Kategoriebezeichnungen ein. Hat man mehrere Produkte der gleichen Kategorie, enthält die Tabelle bereits redundante Daten im Feld Kategorie. Dann dauert es nicht mehr lange, bis ein Benutzer einem Produkt eine bereits vorhandene Kategorie zuweist, aber diese anders bezeichnet (zum Beispiel, indem er einmal Singular und einmal Plural verwendet).

Auch hier kommt es zu Problemen, wenn alle Produkte einer Kategorie aufgelistet werden sollen.

Dies verhindern wir, indem wir die Normalformen der relationalen Entwurfstheorie verwenden und die Tabellen “normalisieren”, sodass Redundanzen und Inkonsistenzen ausgeschlossen werden.

Außerdem stellen wir auch Fälle vor, in denen man in der Regel nicht normalisiert, obwohl die Theorie dies eigentlich vorsieht.

Die erste Normalform: Atomare Felder

Zum Herstellen der ersten Normalform schauen wir uns die Tabelle mit Projekten und Kunden an, die wir weiter oben bereits beschrieben haben. Diese sieht mit ein paar Beispieldaten wie in Bild 1 aus. Das Feld Strasse enthält zwei Informationen – den Straßennamen und die Hausnummer. Das Feld PLZOrt ist ähnlich aufgebaut, denn es enthält die PLZ und den Ort des Kunden.

Bild 1: Formular-Entwurf unseres Beispielformulars

Der Einfachheit halber arbeiten wir dabei nicht mit einer Excel-Tabelle, wie oben beschrieben, sondern gehen davon aus, dass wir die Daten direkt in eine Access-Tabelle namens ProjekteUndKunden importiert haben.

Die erste Normalform lautet:

“Jedes Attribut der Relation muss einen atomaren Wertebereich haben, und die Relation muss frei von Wiederholungsgruppen sein.”

Das bedeutet, dass es kein Feld geben darf, dass nicht noch in weitere Felder aufgeteilt werden könnte. Das ist gleich bei zwei Feldern der Fall, nämlich bei Strasse und PLZOrt. Das Feld Strasse können wir in die Felder Strasse und Hausnummer aufteilen. Die Daten des Feldes PLZOrt landen in den Feldern PLZ und Ort.

Die zweitere Maßnahme ist gängig – PLZ und Ort tauchen immer in zwei Feldern auf. Bei Straße und Hausnummer sind sich die Datenbankentwickler offensichtlich noch nicht einig. Hier gibt es zwar Datenbanken, welche zwei Felder für diese Daten verwenden, aber auch viele Anwendungen, in denen Straße und Hausnummer noch in einem Feld verarbeitet werden.

Die gleiche Beobachtung ergibt sich, wenn Sie die gängigen Online-Anwendungen betrachten: Auch hier wird mal nach Straße und Hausnummer in einem Feld gefragt, mal sollen die Daten in zwei getrennte Felder eingegeben werden.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo