Datenbankaufbau : Skript

dblogo.jpg

Laufkäfer, Käferdatenbank South Kensington

Kapitel 4: Datenbank-Design:

Entwurf einer relationalen Datenbank


von Margarete Payer & Alois Payer

(mailto: payer@hbi-stuttgart.de


Zitierweise / cite as:

Payer, Margarete <1942 - >: Datenbankaufbau : Skript / Margarete Payer & Alois Payer. -- Kapitel 4: Datenbank-Design: Entwurf einer relationalen Datenbank. -- Fassung vom 1997-05-15. -- URL: http://www.payer.de/dbaufbau/dbauf04.html. -- [Stichwort].

Letzte Überarbeitung: 1997-05-15

Anlaß: Lehrveranstaltungen an der HBI Stuttgart

©opyright: Dieser Text steht der Allgemeinheit zur Verfügung. Eine Verwertung in Publikationen, die über übliche Zitate hinausgeht, bedarf der ausdrücklichen Genehmigung der Verfasserin.

Dieser Text ist Teil der Abteilung Datenbankaufbau von Tüpfli's Global Village Library


4.0. Übersicht



4.1. Weiterführende Ressourcen


Printed media:

Taylor, Allen G.: SQL for dummies. -- Foster City [u.a.] : IDG Books Worldwide, 1995. -- ISBN 1-56884-336-4. -- S. 89-116.

WWW:

Özsu, M. Tamer: Database Management Systems : Lecture Notes. -- ER-to-Relational_Mapping [Logical relational database design, step 1]. --Sept. 1995. -- URL: http://web.cs.ualberta.ca/~database/courses/c391/ER-to-Relational/ . -- Zugriff am 15. Mai 97

Özsu, M. Tamer: Database Management Systems : Lecture Notes. -- Normalization [Logical relational data base design, step 2]. -- Sept. 1995. -- URL: http://web.cs.ualberta.ca/~database/courses/c391/Normalization/ . -- Zugriff am 15. Mai 97


4.2. Einleitung


Unter Zuhilfenahme des Entity-Relationship-Modelings geht man beim Entwurf einer relationalen Datenbank am besten in folgenden Schritten vor:

  1. Bestimmung der Objekte (physischer oder konzeptioneller Art), die für die Zielsetzung der Datenbank relevant sind
  2. Festsetzung, welche dieser Objekte Tabellen und welche Kolumnen (Spalten) dieser Tabellen sein sollen
  3. Definition der Tabellen
  4. Festlegung von Schlüsseln (keys)
  5. Festlegung von Indices
  6. Normalisierung (normalization)

4.3. Bestimmung der Objekte


Bestimmung, welche Objekte wichtig genug sind, um sie in das Datenbank Modell einzufügen. Dazu empfehlen sich folgende Arbeitsschritte:

  1. Brainstorming: man mache - mit Hilfe von kooperativem Brainstorming - eine Liste aller Objekte die einem dazu einfallen. Die Frage nach der gegenseitigen Beziehung dieser Objekte lasse man noch beiseite
  2. Man suche, die Beziehungen dieser Objekte zueinander zu bestimmen:
    1. zentrale, hauptsächliche Objekte
    2. Objekte, die Komponenten der hauptsächlichen Objekte sind
    3. Objekte, die Nebenaspekte ausdrücken
    4. Objekte, die für die geplante Datenbank irrelevant sind und deshalb aus der Liste gestrichen werden können
  3. Optionell: Vorläufige Festlegung, was man als Schlüssel (key) verwenden will.

4.4. Festsetzung, welche dieser Objekte Tabellen und welche Kolumnen (Spalten) dieser Tabellen sein sollen


Man bestimmt also (in der Terminologie des ER-Modells) Entitäts-Klassen (Tabellen) und Attribute (Kolumnen, Spalten). Zu diesem Arbeitsgang gibt es keine feste Regeln. Es kommt vielmehr auf ein gegenseitiges Abwägen der verschiedenen Anforderungen die an die zukünftige Datenbank gestellt werden, an.


4.5. Definition der Tabellen


Man mache eine zweispaltige Liste: in die erste Spalte trage man die Tabellen ein, in die zweite Spalte die zugehörigen Spalten (Kolumnen).

Tabelle 1 Spalte 1
  Spalte 2
  Spalte 3
Tabelle 2 Spalte 1
  Spalte 2

In SQL umgesetzt könnte das z.B. so aussehen:

CREATE TABLE Tabelle_1 (

SPALTE_1 NATIONAL CHARACTER (30) NOT NULL,
SPALTE_2 NATIONAL CHARACTER VARYING,
SPALTE_3 NATIONAL CHARACTER (5)
) ;

CREATE TABLE Tabelle_2

SPALTE_1 NATIONAL CHARACTER VARYING,
SPALTE_2 DATE
) ;


Um verschiedene Tabellen miteinander verknüpfen zu können, müssen je zwei jeweils mindestens eine Spalte (ein Attribut) mit gleichartigem Inhalt gemeinsam haben. Diese Spalten (Attribute) können in den Tafeln unterschiedliche Benennungen haben, die Inhalte müssen aber gleichartig sein.

Sind die Tabellen so definiert, bestimme man gegebenenfalls folgende Eigenschaften der Tabellen bzw. Spalten:


4.6. Festlegung von Schlüsseln (keys)


Jede Reihe in einer Tabelle sollte eindeutig identifizierbar sein, d.h. in einer Spalte der Tabelle sollten Werte eingetragen sein, die einmalig sind und die betreffende Reihe eindeutig identifizieren (z.B. Identifikationsnummer). Eine solche Spalte nennt man Primärschlüssel (primary key). Mittels des Primärschlüssels ist die Verknüpfung mit anderen Tabellen einfach: in der anderen Tabelle muß nur eine Spalte vorhanden sein, in der der entsprechende Primärschlüssel der ersten Spalte eingetragen ist. Eine solche Spalte nennt manauswärtigen Schlüssel (foreign key).


Beispiel in SQL:

CREATE TABLE TITELAUFNAHME (

IDENTIFIKATIONSNUMMER INTEGER PRIMARY KEY,
TITEL NATIONAL CHARACTER VARYING NOT NULL,
UNTERTITEL NATIONAL CHARACTER VARYInG
...
) ;

CREATE TABLE AUTORENDATEI (

NACHNAME NATIONAL CHARACTER VARYING NOT NULL,
VORNAME NATIONAL CHARACTER VARYING NOT NULL,
GEBURTSDATUM DATE NOT NULL,
...
IDENTIFIKATIONSNUMMER INTEGER NOT NULL,
...
CONSTRAINT AUTOR PRIMARY KEY (NACHNAME, VORNAME, GEBURTSDATUM),
CONSTRAINT VERKNUEPFUNG FOREIGN KEY (IDENTIFIKATIONSNUMMER) REFERENCES TITELAUFNAHME (IDENTIFIKATIONSNUMMER)
) ;

Bei diesem Beispiel wurde vereinfachend (fälschlich!) angenommen, daß ein Autor durch Namen und Geburtsdatum eindeutig identifiziert ist und daß für alle Autoren das Geburtsdatum bekannt ist.

CONSTRAINT AUTOR PRIMARY KEY (NACHNAME, VORNAME, GEBURTSDATUM) definiert einen zusammengesetzter Primärschlüssel (composite key) , d.h. eine Schlüssel, der die Kombination mehrerer Spalten ist, die zusammen einmalig ist und damit zur eindeutigen Identifikation einer Zeile in einer Tabelle dienen kann.

CONSTRAINT VERKNUEPFUNG FOREIGN KEY (IDENTIFIKATIONSNUMMER) REFERENCES TITELAUFNAHME (IDENTIFIKATIONSNUMMER) definiert einen auswärtigen Schlüssel, der auf die SpalteIdentifikationsnummer in der Tabelle Titelaufnahme verweist. So ist die Autorendatei mit der Datei Titelaufnahme verknüpft

Dies würde Tabellen mit folgender Struktur erzeugen:

Titelaufn. ID-Nr. Integer Not Null Prim. Key
  Titel NatCharVar Not Null  
  Untertitel NatCharVar    
Autorendat. Nachname NatCharVar Not Null Comp. Key
  Vorname NatCharVar Not Null Comp. Key
  Geburtsdat. Date Not Null Comp. Key
  ID-Nr. Integer Not Null Ext. Key

4.7. Festlegung von Indices


Ein Index hat dann Sinn, wenn er das Auffinden eines bestimmten Eintrages in einer Tabelle beschleunigt. Bei der Festlegung von Indices ist also stets die Verlangsamung des Datenbankaufbaus bei simultaner Indizierung, bzw. der zusätzliche zeitliche Aufwand bei periodischer Indizierung abzuwägen gegen den Gewinn an Zeit und Aufwand durch die Indizes: wie oft wird ein bestimmter Zugangspunkt tatsächlich gebraucht usw. ?


4.8. Normalisierung


Hat man eine relationale Datenbank so entworfen, ist der nächste Schritt, zu prüfen, ob die Datenbank so strukturiert ist, daß jede Tabelle so aufgebaut ist, daß das Hinzufügen oder Löschen einer Reihe (eines Eintrages in ihr) nicht Informationen verändert oder löscht, die anderwärts noch benötigt werden. Z.B. daß das Löschen eines Titels in der Titelaufnahmedatei (weil z.B. das betreffende Buch verloren ging) nicht die Informationen über den Autor löscht (die man evtl. in Zukunft durchaus noch braucht).

Treten solche Probleme auf, dann spricht man von Modifikations-Anomalien (modification anomalies), d.h. unerwünschten Folgen für die Datenbank, wenn Daten in einer Tabelle hinzugefügt, geändert oder gelöscht werden. Solche Anomalien treten dann auf, wenn eine Tabelle Einträge enthält, die sinnvollerweise auf zwei oder mehr Tabellen verteilt werden sollten. Das Aufspalten einer Tabelle in zwei oder mehrere Tabellen, um solche Anomalien zu beseitigen, nennt man Normalisierung (normalization).

Zwischen 1970 und 1981 betrieb man Forschung, wie man Modifikations-Anomalien vermeiden kann. Je nach der Quelle der Modifikations-Anomalie, die man auschließt, unterscheidet man seither verschiedene Normalformen (normal forms):

  1. Erste Normalform (first normal form) (1NF)
  2. Zweite Normalform (second normal form) (2NF)
  3. Dritte Normalform (third normal form) (3NF)
  4. Wertbereich/Schlüssel-Normalform (domain key normal form) (DKNF)

4.8.1. Erste Normalform (first normal form) (1NF)


Eine Tabelle hat die erste Normalform, wenn sie folgende Bedingungen erfüllt:


4.8.2. Zweite Normalform (second normal form) (2NF)


In der zweiten Normalform hängen alle Spalten (Attribute), die nicht zum Primärschlüssel gehören, vom Primärschlüssel als ganzem ab. Alle Tabellen in der ersten Normalform, die einen einfachen (aus nur einer Spalte bestehenden) Primärschlüssel haben, sind so automatisch auch in der zweiten Normalform. Ist aber der Primärschlüssel zusammengesetzt, ist für die zweite Normalform zu prüfen, ob es Attribute gibt, die in Wirklichkeit nur von einer oder einem Teil der Spalten des Primärschlüssels abhängen. Ist dies der Fall, ist mit diesem Teil des Primärschlüssels eine neue Tabelle zu bilden und die ursprüngliche Tabelle in zwei Tabellen aufzuteilen. (Einzelheiten und Beispiele entnehme man den angeführten weiterführenden Ressourcen).


4.8.3. Dritte Normalform (third normal form) (3NF)


Eine Tabelle in der dritten Normalform enthält keine transitiven Abhängigkeiten, d.h. Abhängigkeiten der Form, daß ein Attribut A1 von einem anderen Attribut A2 abhängt, welches wieder von einem anderen Attribut A3 abhängt. Solche Abhängigkeiten können bewirken, daß das Löschen einer Reihe mit einem Eintrag von A3 über A2 zu einem Informationsverlust für A1 führt.


4.8.4. Wertbereich/Schlüssel-Normalform (domain key normal form) (DKNF)


Eine Datenbank in dieser Normalform ist frei von Modifikations-Anomalien. Faktisch ist kaum eine Datenbank in DKFN, da diese oft zu einer unübersichtlich großen Anzahl von Tafeln führt. Übernormalisierung kann dazu führen, daß eine Datenbank in ihrer Leistung (besonders Geschwindigkeit) unerträglich abfällt. Es gilt also einen vernünftigen Kompromiß zwischen Normalisierung und Leistung einer Datenbank zu finden. Für die Einzelheiten der DKNF sei auf die weiterführenden Ressourcen verwiesen.


Zu Kapitel 5: Grundzüge von SQL