<\/p>\n
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.<\/p>\n
Die Beispiele dieses Artikels finden Sie in der Datenbank 2101_Normalisierung.accdb<\/b>.<\/p>\nDie dritte Normalform<\/h2>\n
Die dritte Normalform setzt erstens voraus, dass sich das Datenmodell in der ersten und der zweiten Normalform befindet.<\/p>\n
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.<\/p>\n
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 <\/b>unterzubringen.<\/p>\n
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.<\/p>\n
Also suchen wir uns ein anderes Beispiel. Eines wäre beispielsweise eine Tabelle, welche neben grundlegenden Kundendaten die folgenden Felder enthält:<\/p>\n
Da es zu jeder BIC<\/b> genau eine Bank gibt, ist das Feld Bankbezeichnung <\/b>transitiv vom Feld BIC <\/b>abhängig. <\/p>\nBeispiel Artikeltabelle<\/h2>\n
Ein anderes Beispiel ist eine Artikeltabelle mit den folgenden Feldern:<\/p>\n
Der Ansprechpartner kann nicht direkt dem Artikel zugeordnet werden, sondern dem Hersteller. Daher ist das Feld Ansprechpartner <\/b>transitiv vom Feld Hersteller <\/b>abhängig.<\/p>\n
Das letzte Beispiel, das wir uns dann auch in der Praxis ansehen, bietet eine Tabelle mit den folgenden Feldern:<\/p>\n
Hier ist offensichtlich, dass die Felder Firma <\/b>und Ansprechpartner <\/b>zum Feld KundeID <\/b>gehören, also nicht direkt vom Primärschlüsselfeld BestellID <\/b>abhängen.<\/p>\n
Die Gefahr, die hier besteht, sind Inkonsistenzen bezüglich der Felder KundeID<\/b>, Firma <\/b>und Ansprechpartner<\/b>. 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 <\/b>und 4 <\/b>im Feld BestellungID<\/b>.<\/p>\n
Bild 1: Zu normalisierende Daten<\/p>\n Wenn sich jemand bei der Eingabe der Daten beispielsweise wie in Bild 2 im Feld Firma <\/b>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.<\/p>\n Bild 2: Inkonsistente Werte im Feld Firma<\/p>\n 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.<\/p>\n 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.<\/p>\n In unserem Beispiel mit der Tabelle tblBestellungen <\/b>bedeutet dies, dass wir eine neue Tabelle namens tblKunden<\/b> erstellen, welche die folgenden Felder aufnimmt:<\/p>\n Danach legen wir eine Beziehung zwischen dem Feld KundeID <\/b>der Tabelle tblBestellungen <\/b>und tblKunden <\/b>an, bei der wir über das Feld KundeID <\/b>aus tblBestellungen <\/b>angeben, welcher Kundendatensatz aus tblKunden <\/b>zu dieser Bestellung gehört.<\/p>\n Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>![\"Zu](\"..\/tl_files\/images\/pic_512_001.png\")
<\/a><\/p>\n<\/a><\/p>\nDritte Normalform herbeiführen<\/h2>\n
\n
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t