<\/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. <\/p>\n
Die Beispiele dieses Artikels finden Sie in der Datenbank 2006_Normalisierung.accdb<\/b>.<\/p>\nAusgangssituation<\/h2>\n
Im ersten Teil der Artikelreihe haben wir die erste Normalform betrachtet, die besagt, dass jedes Feld atomare Informationen enthalten soll. Dabei haben wir Daten zweier Felder, die Straße und Hausnummer sowie PLZ und Ort enthielten, auf jeweils zwei neue Felder aufgeteilt.<\/p>\n
Die neue Tabelle enthält Projekt- und Kundendaten und sieht wie in Bild 1 aus. An dieser Stelle setzen wir die Normalisierung fort und schauen uns die zweite Normalform an.<\/p>\n
Bild 1: Zu normalisierende Daten<\/p>\n Die Definition auf Wikipedia für die zweite Normalform lautet:<\/p>\n „Eine Relation ist genau dann in der zweiten Normalform, wenn die erste Normalform vorliegt und kein Nichtprimärattribut (Attribut, das nicht Teil eines Schlüsselkandidaten ist) funktional von einer echten Teilmenge eines Schlüsselkandidaten abhängt.“<\/p>\n Bezogen auf die Tabelle tblProjekteKunden <\/b>bedeutet dies Folgendes: Die Tabelle besitzt prinzipiell einen aus den beiden Feldern Projektnummer <\/b>und Kundennummer<\/b> zusammengesetzten Primärschlüssel. Eine Teilmenge wäre also eines der beiden Felder Projektnummer <\/b>und Kundennummer<\/b>. Und es gibt Felder, die von Projektnummer <\/b>abhängig sind (Projektbezeichnung<\/b>, Projektstart<\/b>) und Felder, die von Kundennummer <\/b>abhängig sind (die übrigen Felder).<\/p>\n Unsere Tabelle ist also nicht in der zweiten Normalform. Das wäre nur der Fall, wenn alle Nicht-Primärschlüsselfelder von den zum Primärschlüssel zusammengesetzten Feldern abhängig wären. Das ist etwa in einer Bestellpositionen-Tabelle der Fall, die einen aus den beiden Feldern BestellungID <\/b>und ArtikelID <\/b>zusammengesetzten Primärschlüssel enthält – dort sind alle weiteren Felder von diesem Primärschlüssel abhängig.<\/p>\n Schauen wir uns die Tabelle tblProjekteUndKunden <\/b>nochmal genauer an. Der erste, vierte und siebte Datensatz enthalten Projekte mit dem gleichen Kunden. Legen Sie hier nun für ein neues Projekt mit diesem Kunden die Firma Test-Firma <\/b>statt Testfirma <\/b>an, finden Sie bei einer Suche nach Testfirma <\/b>nicht mehr alle Projekte zu diesem Kunden.<\/p>\n Die redundanten Daten führen leicht zu Inkonsistenzen, und das wollen wir vermeiden.<\/p>\n Diese wollen wir nun so aufteilen, dass die Projekte und die Kunden in je einer eigenen Tabelle namens tblProjekte <\/b>und tblKunden <\/b>landen. Beide Tabellen benötigen ein eigenes Primärschlüsselfeld. Die Daten dafür liegen uns bereits vor: Die Tabelle tblProjekte <\/b>verwendet das Feld Projektnummer <\/b>als Primärschlüsselfeld, die Tabelle tblKunden <\/b>das Feld Kundennummer<\/b>.<\/p>\n Danach müssen wir allerdings noch die Zuordnung zwischen den Kunden und Projekten sicherstellen. Weisen wir ein Projekt einem Kunden zu oder einen Kunden einem Projekt Letzteres ist der Fall, und damit wissen wir, dass wir der Tabelle tblProjekte <\/b>ein Fremdschlüsselfeld hinzufügen müssen, mit dem wir den Eintrag der Tabelle tblKunden <\/b>festlegen, für den das Projekt durchgeführt werden soll.<\/p>\n Die Tabelle tblProjekteUndKunden <\/b>wollen wir nun wie in Bild 2 auf die beiden Tabellen tblProjekte <\/b>und tblKunden <\/b>aufteilen. Dazu erstellen wir die beiden Zieltabellen, wobei wir die Felder Projektnummer <\/b>und Kundennummer <\/b>gleich durch die in diesem Magazin üblichen Bezeichnungen ProjektID <\/b>und KundeID <\/b>ändern. Die beiden Primärschlüsselfelder müssen Sie direkt als Autowert festlegen, da sich dies nicht mehr einstellen lässt, wenn Sie einmal Daten in die Tabelle geschrieben haben.<\/p>\n Bild 2: Aufteilung der Tabelle tblProjekteUndKunden<\/p>\n Der Tabelle tblProjekte <\/b>fügen wir außerdem gleich das Fremdschlüsselfeld KundeID <\/b>mit dem Datentyp Zahl <\/b>hinzu.<\/p>\n Nun benötigen wir noch halbwegs automatische Möglichkeiten, um die Daten der Tabellen aufzuteilen. Dies erledigen wir in zwei Schritten:<\/p>\n Den ersten Schritt erledigen wir mit einer Anfügeabfrage. Dazu erstellen Sie eine neue Abfrage und ändern den Abfragetyp über den Ribbon-Eintrag Entwurf|Abfragetyp|Anfügen<\/b>. Nun erscheint der Dialog Anfügen<\/b>, mit dem Sie die Zieltabelle auswählen, hier tblKunden <\/b>(siehe Bild 3).<\/p>\n Bild 3: Auswählen der Zieltabelle für die Anfügeabfrage<\/p>\n Danach bearbeiten Sie den Entwurf der neuen Anfügeabfrage. Fügen Sie die Tabelle tblProjekteUndKunden <\/b>zum Entwurf hinzu und ziehen Sie die Felder für die Kunden in das Entwurfsraster. Access ordnet Felder gleichen Namens automatisch zu, sodass wir nur noch das Feld KundeID <\/b>als Ziel für das Feld Kundennummer<\/b> auswählen müssen (siehe Bild 4).<\/p>\n Bild 4: Anfügeabfrage zum Füllen der Tabelle tblKunden<\/p>\n Danach betätigen Sie den Ribbon-Eintrag Ent-wurf|Er-geb-nis-se|Aus-füh-ren<\/b>, um die Anfügeabfrage zu starten. Die nun erscheinende Meldung besagt, dass nicht alle Einträge zur Zieltabelle hinzugefügt werden konnten. Das ist logisch, denn die Tabelle tblProjekteUndKunden <\/b>enthält den Datensatz mit der Kundennummer 123 <\/b>mehrfach.<\/p>\n In diesem Fall ist es also in Ordnung, dass nicht alle Einträge kopiert werden. Das Ergebnis sehen Sie in Bild 5.<\/p>\n Bild 5: Die gefüllte neue Tabelle tblKunden<\/p>\n Zum Übertragen der Projektdaten aus der Tabelle tblProjekteUndKunden <\/b>in die Tabelle tblProjekte <\/b>legen wir wiederum eine Anfügeabfrage an. Diesmal verwenden wir die Tabelle tblProjekte <\/b>als Zieltabelle.<\/p>\n Danach fügen wir die Tabelle tblProjekteUndKunden <\/b>zum Entwurf hinzu und ziehen diesmal die Felder Projektnummer<\/b>, Projektbezeichnung<\/b>, Projektstart <\/b>und Kundennummer <\/b>in das Entwurfsraster. Auch hier erkennt Access wieder zwei Zuordnungen, aber für Projektnummer und Kundennummer müssen wir selbst Hand anlegen. Das Feld Projektnummer <\/b>soll auf dem Primärschlüsselfeld ProjektID <\/b>der Zieltabelle abgebildet werden. Und mit Kundennummer <\/b>erhalten wir praktischerweise bereits die Werte für das Fremdschlüsselfeld KundeID<\/b> (siehe Bild 6).<\/p>\n Bild 6: Anfügeabfrage zum Füllen der Tabelle tblProjekte<\/p>\n Da es für die Projekte nur eindeutige Daten gibt, sollte das Anfügen diesmal ohne Probleme erfolgen. Wir führen die Anfügeabfrage aus und erhalten das Ergebnis aus Bild 7.<\/p>\n Bild 7: Die gefüllte Tabelle tblProjekte<\/p>\n Nun fehlt nur noch eine Beziehung zwischen den beiden Tabellen tblProjekte <\/b>und tblKunden<\/b>. Diese fügen wir über das Beziehungen<\/b>-Fenster hinzu, das wir mit dem Ribbon-Eintrag Datenbanktools|Beziehungen <\/b>öffnen.<\/p>\n Fügen Sie die beiden Tabellen tblProjekte <\/b>und tblKunden <\/b>zum Beziehungen-Fenster hinzu und ziehen Sie dann das Fremdschlüsselfeld KundeID<\/b> der Tabelle tblProjekte <\/b>auf das Primärschlüsselfeld KundeID <\/b>der Tabelle tblKunden<\/b>.<\/p>\n Klicken Sie doppelt auf den Beziehungspfeil und markieren Sie im nun erscheinenden Dialog Beziehungen bearbeiten <\/b>die Option Mit referentieller Integrität<\/b> (siehe Bild 8). Die Löschweitergabe aktivieren wir für diese Beziehung nicht, weil Kunden, denen bereits ein Projekt zugewiesen wurde, nicht mehr gelöscht werden sollen.<\/p>\n Bild 8: Herstellen einer Beziehung zwischen den Tabellen tblProjekte und tblKunden<\/p>\n Die Tabelle tblProjekteUndKunden<\/b> beherbergt noch ein nicht normalisiertes Feld, das wir in die Tabelle tblKunden <\/b>übertragen haben. Es enthält die Anrede des Kunden. In diesem Feld landen Daten wie Herr<\/b>, Frau <\/b>oder Firma<\/b>. Wenn nur diese drei Einträge vorgesehen sind, befinden sich eine Menge redundanter Daten in diesem Feld. Das ist wieder kein Problem, wenn niemand auf die Idee kommt, statt Herr einmal Herrn in das Feld einzutragen. Suchen Sie dann über die Anrede nach männlichen oder weiblichen Kunden oder nach Firmenkunden und geben beispielsweise den Suchbegriff Herr <\/b>ein, finden Sie wieder nicht alle gewünschten Datensätze.<\/p>\n Wir verwenden für diesen Schritt eine Kopie der Tabelle tblKunden <\/b>mit dem Namen tblKundenMitAnredeID<\/b>.<\/p>\n Auch hier bietet sich eine Normalisierung an, indem wir für die Anrede eine neue Tabelle erstellen. Diese soll nur drei Datensätze mit den Werten Herr<\/b>, Frau <\/b>und Firma <\/b>aufnehmen. Außerdem erhält diese Tabelle ein Primärschlüsselfeld namens AnredeID <\/b>und wird unter dem Namen tblAnreden <\/b>gespeichert (siehe Bild 9).<\/p>\n Bild 9: Tabelle mit Anreden<\/p>\n Aus der Tabelle tblKundenMitAnredeID <\/b>entfernen wir das Feld Anrede <\/b>und fügen ein neues Fremdschlüsselfeld namens AnredeID <\/b>hinzu.<\/p>\n Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>![\"Zu](\"..\/tl_files\/images\/pic_503_001.png\")
<\/a><\/p>\nDie zweite Normalform<\/h2>\n
Praktische Aspekte der zweiten Normalform<\/h2>\n
Aufteilung der Tabelle tblProjekteUndKunden<\/h2>\n
<\/a><\/p>\n\n
Kundentabelle füllen<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nProjekttabelle füllen<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nNormalisierung für Lookupdaten<\/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