André Minhorst, Duisburg Grundlage für die Entwicklung einer professionellen Datenbankanwendung ist eine entsprechende 1 Einleitung... 1 Inhalt Gestaltung des Datenmodells. Die Musterlösungen 2 Beispieldatenbank... 1 und Beispieldatenbanken von 3 Normalisierung Grundlage versuchen, dieser Voraussetzung zu entsprechen. professioneller Datenmodellierung... 1 Im vorliegenden Beitrag erfahren Sie nicht nur, 4 Referentielle Integrität... 4 welche Grundlagen hinter der Datenmodellierung 5 Beziehungsarten... 5 professioneller Datenbanken stehen, sondern lernen auch die wichtigsten Begriffe im Zusammenhang mit relationalen Datenbanken, referentieller Integrität und Beziehungen zwischen Tabellen kennen. 1 Einleitung Das Datenmodell ist das A und O einer Datenbankanwendung. Wenn Sie das Datenmodell vermasseln und das zu spät merken wenn zum Beispiel schon alle Formulare und Berichte fertig sind, fangen Sie je nach Art der Umbaumaßnahmen am Datenmodell am besten noch einmal von vorne an. Und erklären Sie dem Benutzer mal, warum eine kleine Änderung einen Aufwand erfordern kann, der dem einer Neuerstellung gleichkommt. Nach der Lektüre der nachfolgenden Kapitel und ein wenig Praxiserfahrung (es kann nie schaden, das eine oder andere bestehende Datenmodell mal auseinanderzunehmen und auf Konsistenz zu prüfen) werden Sie schnell feststellen, dass man 95% aller Fälle ohnehin nur auf eine Art lösen kann. In diesem Beitrag lernen Sie die ersten drei Normalformen und Grundlagen für den Einsatz der unterschiedlichen Beziehungstypen kennen. Außerdem erfahren Sie einiges über die wichtigsten Begriffe der Datenmodellierung wie Master- und Detailtabelle oder Primär- und Fremdschlüssel. 2 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. 3 Normalisierung Grundlage professioneller Datenmodellierung Warum gibt überhaupt Beziehungen? Das fragt sich so 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. 1
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 der ersten von drei, für relationale Datenbanken besonders wichtigen Normalformen finden Sie in den folgenden Abschnitten. 3.1 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. 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). 3.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. Abb. 1: Aufsplittung eines Feldes in seine elementaren Informationen Die Bedeutung funktionaler Abhängigkeit lässt sich leicht am Beispiel eines Artikels erläutern: Eine Artikeltabelle enthält einen eindeutigen 2
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. 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 beispielsweise 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. Abb. 2: Auslagerung der Position in eine verknüpfte Tabelle 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. 3.4 Vorteile der Normalisierung des Datenmodells Die nachfolgende Auflistung enthält einige wichtige Vorteile der Normalisierung des Datenmodells: 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. 3.3 Die dritte Normalform 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. 3
Einmalige Eingabe von Daten Die Artikeltabelle besteht nur noch aus Feldern, die direkt der Beschreibung des Artikels dienen. Dazu gehört auch ein Feld mit dem Kürzel des Lieferanten als Fremdschlüsselfeld. Dieses Feld beinhaltet einen der in der Lieferantentabelle verwendeten Primärschlüssel und dient damit der Zuordnung des Lieferanten zu dem Artikel. Sie können also jeden eingegebenen Lieferantendatensatz beliebig vielen Artikeldatensätzen zuordnen, ohne die Daten für jeden Artikel neu eingeben zu müssen. Vermeidung von Redundanzen Wenn Sie die Artikeltabelle vor der Abspaltung der Lieferantendaten ansehen, können Sie sich sicher vorstellen, dass einige Lieferanten mehrere Artikel liefern. Die Tabelle enthält dann die gleichen Daten direkt mehrfach ein typischer Fall einer Redundanz. Durch die Abspaltung solcher Daten verhindern Sie solche Redundanzen. Vermeidung von Inkonsistenzen Tabellen mit redundanten Daten bergen immer das Risiko der Entstehung von Inkonsistenzen. Eine Inkonsistenz liegt beispielsweise vor, wenn einer von zwei Datensätzen mit redundanten also eigentlich gleichen Daten so geändert wird, dass die redundanten Daten nicht mehr gleich sind. Wenn keine redundanten Daten vorkommen, droht die Gefahr der Bildung von Inkonsistenzen erst gar nicht. 4 Referentielle Integrität Die Wahrung referentieller Integrität bedeutet die Einhaltung einer einzigen Regel: Jeder Fremdschlüsselwert eines Datensatzes einer Tabelle muss einem Primärschlüsselwert eines Datensatzes der verknüpften Tabelle entsprechen. Um diese Regel mit Leben zu füllen, lernen Sie zunächst die beiden Schlüsselarten Primärschlüssel und Fremdschlüssel kennen und erfahren anschließend, wie sich die Anwendung dieser Regel im praktischen Einsatz einer Datenbank auswirkt. 4.1 Schlüsselarten Im Rahmen des relationalen Datenmodells verwenden Sie zwei unterschiedliche Schlüsselarten, um Beziehungen zu realisieren. Dabei handelt es sich um Primär- und Fremdschlüssel. Primärschlüssel Primärschlüssel dienen unter anderem der eindeutigen Definition eines Datensatzes. Sicher gibt es Tabellen, deren Feldzusammensetzung ein Auftauchen zweier identischer Datensätze nahezu ausschließt. Dennoch wäre es schwierig, auf einfache Weise auf einen bestimmten Datensatz Bezug zu nehmen. Daher sollte jede Tabelle ein Feld mit eindeutigem Inhalt als Primärindex bereitstellen. Fremdschlüssel Fremdschlüssel dienen der Verknüpfung von Datensätzen unterschiedlicher Tabellen. Dabei enthält das Fremdschlüsselfeld der einen Tabelle den Wert des Primärschlüsselfeldes des gewünschten Datensatzes der anderen Tabelle. Im Beispiel der Artikel- und der Lieferantentabelle enthält die Artikeltabelle ein Fremdschlüsselfeld namens Lieferanten-Nr, das den Inhalt des Feldes Lieferanten-Nr des verknüpften Datensatzes der Lieferantentabelle enthält. Bezeichnungen verknüpfter Tabellen Eine relationale Beziehung basiert in der Regel auf dem Vorhandensein von zwei Tabellen. Durch die Natur ihrer unterschiedlichen Funktionen besitzen diese beiden Tabellenarten auch verschiedene Bezeichnungen: Sie werden z. B. Master- und Detailtabelle, Parent- und Childtabelle oder Vater- und Kindtabelle genannt. Dabei ist die Master-, Parent- bzw. Vatertabelle immer diejenige Tabelle, deren Primärschlüsselfeld an der Beziehung beteiligt ist. Die Detail-, Child- bzw. Kindtabelle besitzt ein Fremdschlüsselfeld, das mit dem jeweiligen Inhalt des Primärschlüsselfeldes des Datensatzes der Master-, Parent- bzw. Vatertabelle gefüllt ist. 4
Hinweis Im Folgenden soll um die Begriffsvielfalt ein wenig einzuschränken nur noch von Masterund Detailtabelle die Rede sein. 4.2 Referentielle Integrität in der Praxis Das Datenbankmanagementsystem selbst also z. B. Microsoft Access sorgt für die Durchsetzung der zu Beginn des Kapitels genannten Regel, sofern Sie dies für eine Beziehung festgelegt haben. Die Kontrolle über die referentielle Integrität tritt in vier Fällen in Aktion: beim Hinzufügen eines Datensatzes zur Mastertabelle, deren Fremdschlüsselfeld einen Wert enthält, der in keinem Datensatz der Detailtabelle enthalten ist. beim Löschen eines Datensatzes der Detailtabelle, dessen Primärschlüsselwert noch im entsprechenden Fremdschlüsselfeld mindestens eines Datensatzes der Mastertabelle enthalten ist. beim Ändern des Inhalts eines Primärschlüsselfeldes eines Datensatzes der Mastertabelle. beim Ändern des Inhalts des Fremdschlüsselfeldes eines Datensatzes der Detailtabelle in einen Wert, der nicht in dem Primärschlüsselfeld eines der Datensätze der Mastertabelle enthalten ist. Falls einer der genannten Fälle für eine Beziehung mit definierter referentieller Integrität eintritt, führt Access eine Aktion entsprechend den für die referentielle Integrität festgelegten Eigenschaften aus. In der Grundeinstellung erscheint lediglich eine entsprechende Fehlermeldung, die mit dem Abbruch der gewünschten Datenoperation endet. Sie können allerdings auch festlegen, dass Access beispielsweise beim Löschen eines Datensatzes der Mastertabelle alle mit diesem Datensatz verknüpften Datensätze der Detailtabelle automatisch mitlöscht (Löschweitergabe). Das ist beispielsweise beim Löschen von Bestellungen und den entsprechenden Detaildaten sinnvoll. Mit einer weiteren Einstellung können Sie festlegen, dass Access bei einer Änderung des Wertes des Primärschlüsselfeldes eines Datensatzes der Mastertabelle direkt den Inhalt des entsprechenden Fremdschlüsselfeldes der Detailtabelle aktualisiert (Aktualisierungsweitergabe). 5 Beziehungsarten Die im Rahmen der Normalisierung eines Datenmodells durchgeführten Maßnahmen führen in der Regel zu einem Datenmodell, dessen Tabellen sehr elementare Informationen zu den jeweilig beschriebenen Objekten beinhalten. Dafür enthält das Datenmodell mit wachsender Anzahl von Tabellen eine entsprechend wachsende Anzahl von Beziehungen zwischen diesen Tabellen, die unterschiedliche Ausprägungen aufweisen können. In den folgenden Abschnitten erhalten Sie Informationen über die einzelnen Beziehungsarten. 5.1 1:1-Beziehungen 1:1-Beziehungen verknüpfen die Primärschlüsselfelder zweier Tabellen miteinander. Diese Beziehungsart wird praktisch nie verwendet. Einer der wenigen Gründe für den Einsatz einer solchen Beziehung und damit der Aufteilung einer Tabelle in zwei per 1:1-Beziehung verknüpfte Tabellen ist die Verwendung von mehr als 256 Feldern. Dies ist unter Access nicht möglich, lässt aber auch mit hoher Wahrscheinlichkeit auf Fehler bei der Datenmodellierung schließen. Ein weiterer Grund sind Felder mit großen Inhalten zum Beispiel Felder, die mit Bilddateien gefüllt werden sollen. Wenn Sie solche Felder aus der eigentlichen Tabelle in eine per 1:1- Beziehung verknüpfte Tabelle auslagern, muss das Datenbanksystem keinen unnötigen Platz für 5
Felder reservieren, die möglicherweise gar keine Daten enthalten. Für Access-Datenbanken ist dieser Fall allerdings nicht relevant, da hier ohnehin für keinen Datentyp Speicherplatz reserviert wird. Anders ist es beispielsweise beim Microsoft SQL Server. Eine andere Anwendungsmöglichkeit für solch eine Beziehung besteht, wenn Sie eine verknüpfte Tabelle um eigene Daten erweitern möchten. Mit einer 1:1-Beziehung können Sie dies tun, ohne die Daten der anderen Tabelle zu berühren. So etwas macht beispielsweise Sinn, wenn Sie über ein entsprechendes Feld dauerhaft festlegen möchten, ob ein bestimmter Datensatz gedruckt werden soll. 5.2 1:n-Beziehungen 1:n-Beziehungen beschreiben Verknüpfungen zwischen zwei Tabellen, die über das Primärschlüsselfeld der einen und ein Fremdschlüsselfeld der zweiten Tabelle miteinander verknüpft sind. Beispiele für diese Beziehungsart sind die bereits erwähnte Beziehung zwischen Artikel und Lieferant (s. Abb. 4), Projekt und Kunde usw. Wichtiges Merkmal dieser Beziehungsart ist, dass beide beteiligten Tabellen eigene Objekte repräsentieren. Dies unterscheidet die 1:n-Beziehung von der nachfolgend beschriebenen n:1- Beziehung. Abb. 5: Beispiele für n:1-beziehungen 5.3 n:1-beziehungen n:1-beziehungen sind formal wie 1:n-Beziehungen zu behandeln. Dabei dient der Inhalt der Mastertabelle jedoch nicht der Beschreibung eines realen Objektes. Die Tabelle ist vielmehr das Produkt der Auslagerung von sich wiederholenden Feldinhalten wie beispielsweise Anredeformen (Herr, Frau und so weiter) oder anderen objektspezifischen Eigenschaften und enthält neben dem Primärindexfeld lediglich den eigentlichen Inhalt. Andere Beispiele sind Zahlungsart, Tätigkeitsart etc. (s. Abb. 5). 5.4 m:n-beziehungen m:n-beziehungen verknüpfen wie die 1:1- Beziehung die Primärschlüsselfelder zweier Tabellen miteinander allerdings nicht direkt, sondern über eine Verknüpfungstabelle. Die Verknüpfungstabelle besteht aus zwei Fremdschlüsselfeldern, die als Werte die Primärschlüsselwerte der zu verknüpfenden Datensätze der beiden Tabellen enthalten. Wenn Sie bei den beiden Begriffen Primärschlüssel und Fremdschlüssel hellhörig werden, haben Sie offensichtlich sorgfältig gelesen: In der Tat besteht die m:n-beziehung aus zwei 1:n- Beziehungen, die eine gemeinsame Detailtabelle haben. Abb. 4: 1:n-Beziehung zwischen Artikeln und Lieferanten Um in dieser Detailtabelle Redundanzen zu vermeiden, legen Sie einen zusammengesetzten, aus 6
ist zumindest nicht, wenn Sie eine logische reflexive Beziehung aufbauen möchten. Abb. 6: Beispiel einer m:n-beziehung den beiden Fremdschlüsselfeldern der Tabelle bestehenden eindeutigen Schlüssel fest (s. Abb. 6). m:n-beziehungen müssen allerdings nicht zwangsläufig über eine einzige Verknüpfungstabelle realisiert werden. Zwischen den betroffenen Tabellen können sich auch mehrere statt einer einzigen Tabelle befinden, die ihrerseits per 1:n-Beziehung miteinander verknüpft sind. Ein Beispiel ist die Tabelle Personal der Nordwind-Datenbank (s. Abb. 7). Das Fremdschlüsselfeld Vorgesetzte(r) enthält entweder keinen Wert was darauf hindeutet, dass der entsprechende Mitarbeiter keinen Vorgesetzten hat oder es enthält den Inhalt des Primärschlüsselfeldes eines der Datensätze der Tabelle Personal womit der jeweilige Vorgesetzte festgelegt ist. Die referentielle Integrität kommt hier allerdings mit der Logik in Konflikt, da zumindest ein Mitarbeiter keinen Vorgesetzten haben kann. Sie können in diesem Fall also keine referentielle Integrität festlegen. Das bedeutet, dass Sie die Eingabevalidierung durch geeignete Maßnahmen durchführen müssen zum Beispiel bei der Eingabe der Daten über ein Formular. 5.6 Weitere Beziehungsarten Es gibt noch weitere Beziehungsarten, die in der Praxis allerdings wenig Beachtung finden bzw. Ableitungen von den genannten Beziehungsarten sind. Genau genommen haben Sie mit der m:n- Beziehung ja bereits einen Spezialfall der 1:n- Beziehung kennen gelernt. Abb. 7: Beispiel einer reflexiven Beziehung 5.5 Reflexive Beziehungen Reflexive Beziehungen sind prinzipiell 1:n- Beziehungen mit dem Unterschied, dass Master- und Detailtabelle identisch sind und dass die Festlegung referentieller Integrität nicht möglich Ein weiterer Spezialfall der 1:n-Beziehung ist die n:0-beziehung die allerdings aus einem schlechten Datenbankmodell resultiert. Eine n:0- Beziehung tritt auf, wenn ein Feld der Detailtabelle als Wert den Primärschlüssel der Mastertabelle erwartet z. B. für die Auswahl einer Anrede und kein Wert der Tabelle ausgewählt wird, der Inhalt des Feldes also Null ist. Dies kann allerdings in den meisten Fällen durch das Anlegen eines Wertes wie z. B. Sonstige in der verknüpften Mastertabelle umgangen werden. 7