Normalisierung, Teil 3: Die dritte Normalform

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

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.

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