Normalisierung, Teil 3: Die dritte Normalform

Der Entwurf eines Datenmodells und der 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. In diesem Teil ist die dritte Normalform an der Reihe.

Beispieldatenbank

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

Die dritte Normalform

Die dritte Normalform setzt erstens voraus, dass sich das Datenmodell in der ersten und der zweiten Normalform befindet.

Die dritte Normalform sorgt außerdem dafür, dass es keine transitiven Abhängigkeiten innerhalb einer Tabelle gibt. Alle Nichtschlüsselfelder 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üfen Sie, ob Sie die Daten aller Felder mit Ausnahme des Primärschlüssels einzeln ändern können, ohne dass ein weiteres Feld in dieser Tabelle davon betroffen ist.

Am Ende des vorherigen Teils dieser Artikelreihe haben wir bereits das Beispiel von PLZ und Ort aufgegriffen. Oberflächlich betrachtet ist das ein gutes Beispiel für eine transitive Abhängigkeit: Normalerweise sollte man davon ausgehen, dass zu jeder PLZ genau ein Ort gehört. Daher könnte es Probleme bringen, beide Felder beispielsweise in einer Tabelle namens tblKunden unterzubringen.

Sobald Sie einmal versehentlich die PLZ ändern, aber nicht den Ort an diese PLZ anpassen, haben Sie zwei verschiedene Postleitzahlen für den gleichen Ort. Dummerweise macht uns die Praxis an dieser Stelle ohnehin einen Strich durch die Rechnung, denn es gibt bereits Postleitzahlen, die mehr als einem Ort zugewiesen sind.

Beispiel BIC und Bankbezeichnung

Also suchen wir uns ein anderes Beispiel. Eines wäre beispielsweise eine Tabelle, welche neben grundlegenden Kundendaten die folgenden Felder enthält:

• BIC
• Bankbezeichnung

Da es zu jeder BIC genau eine Bank gibt, ist das Feld Bankbezeichnung transitiv vom Feld BIC abhängig.

Beispiel Artikeltabelle

Ein anderes Beispiel ist eine Artikeltabelle mit den folgenden Feldern:

• ArtikelID
• Artikelbezeichnung
• Einzelpreis
• Hersteller
• Ansprechpartner

Der Ansprechpartner kann nicht direkt dem Artikel zugeordnet werden, sondern dem Hersteller. Daher ist das Feld Ansprechpartner transitiv vom Feld Hersteller abhängig.

Das letzte Beispiel, das wir uns dann auch in der Praxis ansehen, bietet eine Tabelle mit den folgenden Feldern:

• BestellID (Primärschlüsselfeld)
• Bestelldatum
• KundeID
• Firma
• Ansprechpartner

Hier ist offensichtlich, dass die Felder Firma und Ansprechpartner zum Feld KundeID gehören, also nicht direkt vom Primärschlüsselfeld BestellID abhängen.

Die Gefahr, die hier besteht, sind Inkonsistenzen bezüglich der Felder KundeID, Firma und Ansprechpartner. Wie Bild 1 zeigt, kann es durchaus vorkommen, dass mehrere Bestellungen für den gleichen Kunden vorgesehen sind – hier bei den Datensätzen mit den Werten 1 und 4 im Feld BestellungID.

Bild 1: Zu normalisierende Daten

Wenn sich jemand bei der Eingabe der Daten beispielsweise wie in Bild 2 im Feld Firma vertippt, gibt es zwei Bestellungen an den gleichen Kunden, der aber keinen identischen Firmennamen hat. Sucht man nun nach allen Bestellungen eines Kunden über den Firmennamen, findet man nicht mehr alle Bestellungen dieses Kunden.

Bild 2: Inkonsistente Werte im Feld Firma

Dritte Normalform herbeiführen

Die dritte Normalform führen wir herbei, indem wir eine neue Tabelle erstellen, in die wir das Nichtschlüsselfeld und die davon abhängigen Felder einfügen. Das Nichtschlüsselfeld wird in der neuen Tabelle zum Primärschlüsselfeld.

In der vorherigen Tabelle wird das Nichtschlüsselfeld zum Fremdschlüsselfeld, über das eine Beziehung zu den Datensätzen der neuen Tabelle hergestellt wird. Die vom Nichtschlüsselfeld abhängigen Felder in der ursprünglichen Tabelle werden nach dem Auslagern der Daten in die neue Tabelle gelöscht.

In unserem Beispiel mit der Tabelle tblBestellungen bedeutet dies, dass wir eine neue Tabelle namens tblKunden erstellen, welche die folgenden Felder aufnimmt:

• KundeID (Primärschlüsselfeld)
• Firma
• Ansprechpartner

Danach legen wir eine Beziehung zwischen dem Feld KundeID der Tabelle tblBestellungen und tblKunden an, bei der wir über das Feld KundeID aus tblBestellungen angeben, welcher Kundendatensatz aus tblKunden zu dieser Bestellung gehört.

Username or Email

Passwort

Angemeldet bleiben