Laufkäfer, Käferdatenbank South Kensington
(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
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
Unter Zuhilfenahme des Entity-Relationship-Modelings geht man beim Entwurf einer relationalen Datenbank am besten in folgenden Schritten vor:
Bestimmung, welche Objekte wichtig genug sind, um sie in das Datenbank Modell einzufügen. Dazu empfehlen sich folgende Arbeitsschritte:
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.
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:
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 |
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. ?
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):
Eine Tabelle hat die erste Normalform, wenn sie folgende Bedingungen erfüllt:
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).
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.
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