<\/p>\n
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.<\/p>\n
Die Beispiele dieses Artikels finden Sie in der Datenbank 2005_Normalisierung.accdb<\/b>.<\/p>\nAusgangssituation<\/h2>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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 <\/b>suchen, aber diese Firmenbezeichnung in der Excel-Tabelle einmal mit & <\/b>und einmal mit und <\/b>geschrieben haben (Schmidt GmbH und Co. KG<\/b>).<\/p>\n
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 <\/b>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 <\/b>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<\/b>. 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).<\/p>\n
Auch hier kommt es zu Problemen, wenn alle Produkte einer Kategorie aufgelistet werden sollen.<\/p>\n
Dies verhindern wir, indem wir die Normalformen der relationalen Entwurfstheorie verwenden und die Tabellen „normalisieren“, sodass Redundanzen und Inkonsistenzen ausgeschlossen werden.<\/p>\n
Außerdem stellen wir auch Fälle vor, in denen man in der Regel nicht normalisiert, obwohl die Theorie dies eigentlich vorsieht.<\/p>\n
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 <\/b>enthält zwei Informationen – den Straßennamen und die Hausnummer. Das Feld PLZOrt <\/b>ist ähnlich aufgebaut, denn es enthält die PLZ und den Ort des Kunden. <\/p>\n
Bild 1: Formular-Entwurf unseres Beispielformulars<\/p>\n 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 <\/b>importiert haben.<\/p>\n Die erste Normalform lautet:<\/p>\n „Jedes Attribut der Relation muss einen atomaren Wertebereich haben, und die Relation muss frei von Wiederholungsgruppen sein.“<\/p>\n 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 <\/b>und PLZOrt<\/b>. Das Feld Strasse <\/b>können wir in die Felder Strasse <\/b>und Hausnummer <\/b>aufteilen. Die Daten des Feldes PLZOrt <\/b>landen in den Feldern PLZ <\/b>und Ort<\/b>.<\/p>\n 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.<\/p>\n 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.<\/p>\n Wir wollen sowohl bei PLZ und Ort als auch bei Strasse und Hausnummer zeigen, wie Sie die Daten normalisieren können.<\/p>\n Für ein Feld erledigen wir das in den folgenden Schritten:<\/p>\n Den ersten Schritt erledigen wir im Entwurf der Tabelle tblProjekteUndKunden<\/b>. Das Feld Strasse <\/b>enthält hier die beiden Informationen Straße und Hausnummer. Da wir zwei neue Felder namens Strasse <\/b>und Hausnummer <\/b>generieren wollen, benennen wir zunächst das bestehende Feld Strasse<\/b> in StrasseHausnummer <\/b>um und legen dann die beiden neuen Felder an:<\/p>\n Für das Feld PLZOrt <\/b>fügen wir die beiden folgenden Felder hinzu:<\/p>\n Das Ergebnis sehen Sie in Bild 2.<\/p>\n Bild 2: Aufteilen von Feldern mit nicht atomaren Daten<\/p>\n Die Felder können wir auf zwei Arten aufteilen:<\/p>\n Wir stellen beiden Methoden vor. Welche Sie verwenden, hängt primär von den persönlichen Vorlieben und Fähigkeiten ab. Die Performance dürfte bei Verwendung einer UPDATE<\/b>-Abfrage besser sein. Ob die Performance eine Rolle spielt, hängt wiederum davon ab, wie oft die Adressen normalisiert werden. Wenn Sie dies einmalig beim Migrieren eines Adress-Stamms beim Erstellen einer neuen Anwendung erledigen, spielt die Performance keine Rolle. Wenn Sie jedoch regelmäßig viele Daten damit bearbeiten, wählen Sie die performantere Variante.<\/p>\n Einen weiteren Einfluss auf die Entscheidung für eine Abfrage oder VBA-Code hat die Qualität der Daten. Wenn diese sehr viele Sonderfälle enthält, können Sie diese einfacher per VBA behandeln, weil eine Abfrage für einen solchen Fall schnell unübersichtlich und somit wartungsunfreundlich wird.<\/p>\n Zum Aufteilen von PLZ und Ort per Abfrage erstellen Sie eine Auswahlabfrage, mit der wir zunächst das gewünschte Ergebnis generieren (siehe Bild 3).<\/p>\n Bild 3: Aufteilen von Feldern mit nicht atomaren Daten per Abfrage im Entwurf<\/p>\n Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>![\"Formular-Entwurf](\"..\/tl_files\/images\/pic_498_001.png\")
<\/a><\/p>\n\n
\n
\n
<\/a><\/p>\nAufteilen nicht atomarer Felder<\/h2>\n
\n
Felder per Abfrage atomisieren<\/h2>\n
<\/a><\/p>\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