Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 1/2003.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Professionelle Datenmodellierung mit Access

André Minhorst, Duisburg

Grundlage für die Entwicklung einer professionellen Datenbankanwendung ist eine entsprechende Modellierung des Datenmodells. Die Musterlösungen und Beispieldatenbanken von Access im Unternehmen versuchen, dieser Voraussetzung zu entsprechen. Im vorliegenden Beitrag erfahren Sie nicht nur, welche Grundlagen hinter der Datenmodellierung professioneller Datenbanken stehen, sondern lernen auch die wichtigsten Begriffe im Zusammenhang mit relationalen Datenbanken, referentieller Integrität und Beziehungen zwischen Tabellen kennen.

Einleitung

Eifrige Leser von Access im Unternehmen haben die vorgestellten Musterlösungen und Beispiele nicht kommentarlos hingenommen, sondern auch den dazugehörenden Beitrag gelesen und nachvollzogen.

Da die theoretischen Hintergründe für die jeweilige Gestaltung des zugrunde liegenden Datenmodells nicht in jedem Beitrag komplett aufgeführt werden können, sollen die Grundlagen für professionelle Datenmodellierung an dieser Stelle einmal umfassend vorgestellt werden.

Im vorliegenden Beitrag lernen Sie die ersten drei Normalformen kennen, die dem ersten, provisorischen Entwurf eines Datenmodells den richtigen Kick geben, und Sie erfahren die Grundlagen für die unterschiedlichen Beziehungstypen und finden eine Erklärung der wichtigsten Begriffe der Datenmodellierung wie Master- und Detailtabelle oder Primär- und Fremdschlüssel.

Beispieldatenbank

Die Nordwind-Datenbank, die zu jeder der hier besprochenen Access-Versionen gehört und standardmäßig installiert wird, bietet Beispiele für alle gebräuchlichen Arten von Beziehungen. Daher gelten die Beispiele des vorliegenden Beitrags für das Datenmodell - also die Tabellen und Beziehungen - dieser Datenbank.

Hinweis

Falls Sie nicht wissen, wo Sie die Nordwind-Datenbank finden sollen, lassen Sie sich vom Windows Explorer helfen und suchen Sie im Office-Ordner nach der Datei Nordwind.mdb.

Normalisierung -
Grundlage professioneller
Datenmodellierung

‚Warum gibt überhaupt Beziehungen?’ Das fragt sichso mancher Anwender, der alle für seine Arbeit wichtigen Daten in einer einzigen Tabelle speichert. Alles auf einen Blick - was will man denn noch mehr?

Hinweis

Die folgenden Kapitel beschreiben die theoretischen Grundlagen für den Entwurf des Datenmodells einer relationalen Datenbank. Deren Umsetzung setzt voraus, dass Sie sich bereits mit dem Erstellen von Tabellen sowie der Definition von Beziehungen auskennen. (

Davon abgesehen, dass sich Datenmodelle komplexer Anwendungen bestimmt nicht übersichtlich in einer einzigen Tabelle darstellen lassen, führt die oft praktizierte Unart, völlig unterschiedliche Daten in einer einzigen Tabelle unterzubringen, zu Redundanzen und in deren Folge zu Inkonsistenzen.

Um dies zu vermeiden, basieren die Datenmodelle der meisten relationalen Datenbanken auf den 1972 von Edgar F. Codd im Artikel "Further normalization of the data base relational model" veröffentlichten Normalformen. Die Zusammenfassung ersten drei, für relationale Datenbanken besonders wichtigen Normalformen finden Sie in den folgenden Abschnitten.

Die erste Normalform

Tabellen beinhalten oft Felder, die nicht nur eine, sondern mehrere Informationen speichern. Viele Anwender bringen beispielsweise gerne Vor- und Nachnamen in einem einzigen Feld unter (wie z. B. beim Feld Kontaktperson der Tabelle Kunden in der Nordwind-Datenbank). Probleme sind vorprogrammiert - schon die getrennte Sortierung nach Vor- oder Nachname ist nicht ohne Weiteres möglich.

Ein weiteres Beispiel ist das Speichern von mehreren Informationen gleicher Art in einem einzigen Feld - z. B. das Speichern aller Untergebenen eines Mitarbeiters.

Nicht-Profis umgehen mit solchen Methoden gerne die Erstellung weiterer Beziehungen und Tabellen (und damit vermeintliche Mehrarbeit), verursachen damit aber letztlich erheblichen Mehraufwand.

Abb. 1: Aufsplittung eines Feldes in seine elementaren Informationen

Die erste Normalform fordert daher, jede relevante Information auch in einzelnen Feldern zu speichern (s. Abb. 1).

Außerdem soll eine Tabelle nicht mehrere gleichartige Daten in unterschiedlichen Feldern enthalten - also in einer Kunden-Tabelle z. B. nicht mehrere Felder für unterschiedliche Kontaktpersonen bereitstellen, sondern die Kontaktpersonen in eine Tabelle auslagern und die Tabellen entsprechend verknüpfen.

Eine weitere Forderung der ersten Normalform ist, dass die Felder einer Tabelle sich lediglich auf die Beschreibung eines einzigen Objekts beziehen - also z. B. auf einen Artikel, einen Kunden, einen Lieferanten oder ähnliche reale Objekte.

Die letzte Forderung ist, auch sich wiederholende Feldinhalte in verknüpfte Tabellen auszulagern. Dies ist sinnvoll, wenn der Inhalt des Feldes aus einer überschaubaren Anzahl von Werten besteht - z. B. den unterschiedlichen Anredeformen für Personen wie Herr, Frau usw. Bei nicht überschaubaren Mengen von möglichen Werten wie z. B. Städtenamen in Adresstabellen ist die Anwendung der ersten Normalform allerdings nicht uneingeschränkt sinnvoll.

Die Nordwind-Datenbank bietet z. B. die Möglichkeit, die Einträge des Feldes Position in der Tabelle Personal in eine weitere Tabelle namens Positionen auszulagern (s. Abb. 2).

Die zweite Normalform

Die zweite Normalform setzt das Bestehen der ersten Normalform voraus und besagt weiterhin, dass jede Tabelle einen Primärschlüssel haben muss und dass alle weiteren Felder nur von diesem einen Primärschlüssel funktionell abhängig sind.

Der Primärschlüssel ist ein Feld oder eine Kombination von mehreren Feldern. Er darf genau einmal in einer Tabelle vorkommen.

Die Bedeutung funktionaler Abhängigkeit lässt sich leicht am Beispiel eines Artikels erläutern: Eine Artikeltabelle enthält einen eindeutigen Index - in der Regel die Artikelnummer - und einige weitere Informationen wie die Bezeichnung des Artikels, den Preis, den aktuellen Bestand usw. Alle diese Informationen beziehen sich genau auf den Artikel mit der jeweiligen Artikelnummer - und sind damit von dem Primärschlüssel Artikel-Nr abhängig.

Abb. 2: Auslagerung der Position in eine verknüpfte Tabelle

Abb. 3: Auslagern von nicht-transitiven Abhängigkeiten

In der Praxis verhindern Sie auf diese Weise, dass sich mehrere völlig gleiche Datensätze in derselben Tabelle befinden.

Die dritte Normalform

Die dritte Normalform setzt das Bestehen der zweiten Normalform voraus und verlangt außerdem die Beseitigung sämtlicher nicht-transitiver Abhängigkeiten.

Nicht-transitive Abhängigkeiten sind funktionale Abhängigkeiten zwischen Feldern der Tabelle, von denen keines der Primärschlüssel dieser Tabelle ist. Das folgende Beispiel verdeutlicht den Zusammenhang:

Möglicherweise enthält die Tabelle aus dem vorherigen Beispiel auch Informationen über den Lieferanten des Artikels in Form der Lieferanten-ID, des Lieferantennamens und einigen weiteren Informationen wie z. B. Adressdaten des Lieferanten (s. Abb. 3).

Wenn Sie sich die Lieferanten-ID als Primärschlüssel für die Lieferantendaten vorstellen, dann sind alle weiteren Lieferantendaten funktional abhängig von der Lieferanten-ID - nicht aber vom eigentlichen Primärschlüssel der Artikeltabelle.

Zur Durchsetzung der dritten Normalform müssten Sie also die Lieferantendaten komplett in eine weitere Tabelle ausgliedern (wie es in der Nordwind-Datenbank der Fall ist) und nur den Primärschlüssel der Lieferantentabelle, also die Lieferanten-ID, als Fremdschlüssel in die Artikeltabelle aufnehmen.

Vorteile der Normalisierung des Datenmodells

Die nachfolgende Auflistung enthält einige wichtige Vorteile der Normalisierung des Datenmodells:

  • nur jeweils einmalige Erfassung immer wiederkehrender Daten
  • Vermeidung von Redundanzen
  • Vermeidung von Inkonsistenzen
  • Die drei wesentlichen Vorteile lassen sich am bereits genannten Beispiel beschreiben, bei dem aus einer Artikeltabelle inklusive detaillierter Lieferantendaten zwei Tabellen mit getrennten Artikel- und Lieferantendaten entstehen.

    Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

    Sind Sie Abonnent?Jetzt einloggen ...
     

    Kompletten Artikel lesen?

    Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

    E-Mail:

    Verwandte Beiträge:

    Datenhierarchien in Access

    Indizierung mit Access

    Hierarchien visualisieren

    DAO: Tabellen, Felder und Co. bearbeiten

    Tabellen und Felder dokumentieren

    Datenbanken und Tabellen per SQL anpassen

    Die Microsoft Data Engine (MSDE)

    Tipps und Tricks

    Softwareprojekte verwalten

    Änderungsdaten protokollieren

    Temporäre Tabellen

    © 2003-2015 André Minhorst Alle Rechte vorbehalten.