Skript: Datenbanksysteme und Datenmodellierung - Praktische ...

Skript:
Datenbanksysteme und Datenmodellierung
Herausgeber: Prof. Dr. Nane Kratzke
21. Februar 2011

Vorwort
Dieses Skript ist im Rahmen einer Lehrveranstaltung zur “Datenbank-gestützten Server-seitigen Programmierung”
im Wintersemester 2010 durch Studenten und Studentinnen der Informatik an der Fachhochschule
Lübeck initial entstanden und wird kontinuierlich fortgeschrieben und erweitert.
Diese Lehrveranstaltung dient Studenten und Studentinnen wesentliche Prinzipien der serverseitigen und
vor allem datenbankgestützten Programmierung zu verstehen. Hierzu wird im ersten Drittel der Lehrveranstaltung
ein Einblick in Datenbanksysteme und die Datenmodellierung gegeben, die vor allem das Ziel hat,
die das Datenmodell betreffenden Entwicklungsschritte eines Datenbankentwurfs (Anforderungserhebung,
konzeptionelle Modellbildung, logische Modellbildung) sauber zu gliedern. In den folgenden Anteilen der
Lehrveranstaltung wird dieses Wissen dazu genutzt, webbasierte Informationssysteme mittels Apache, PHP
und MySQL aufzusetzen.
Im Wesentlichen greift dieses Skript die gängige Einsteigerliteratur (vgl. z.B. [Vet98, EN09, Gei09, SZTZ09,
BJK11, TB10]) zu Datenbanken, Entwicklungsphasen des Datenbankentwurfs und Datenmodellbildung auf
und gliedert diese in folgender Form:
• Einführung in ein Phasenmodell der Datenbankentwicklung (vgl. Teil I)
• Modellierungen von Datenmodellen mittels semantischen Modellen (Entity-Relationship Modellierung,
vgl. Teil II Kapitel 6) und logischen Modellen (Relationenmodell, vgl. Teil II Kapitel 7)
• sowie der Überführung von semantischen Modellen auf konzeptioneller Ebene in Relationenmodellen
auf logischer Ebene mittels Transformations- und Normalisierungstechniken (vgl. Teil II Kapitel 8)
Dieses Skript ersetzt die oben genannten Quellen aber in keinster Weise. Es gibt aber auf knappe Art einen
Überblick über diese Thematiken und ist daher als begleitendes Material zu unseren Lehrveranstaltungen
geeignet und auch für all diejenigen ggf. von Interesse, die sich mit dem Entwicklung von datenbankgestützten
Informationssystemen erstmalig befassen. Dies gilt insbesondere für eine erstmalige systematische
Datenmodellierung.
Die in diesem Skript vorgestellten Themen sind im übrigen nicht auf Websysteme beschränkt, sondern gelten
für alle datenbankgestützten Informationssysteme (insbesondere jedoch relationale Datenbanksysteme).
Ohne unsere Studenten wäre dieses Skript jedoch niemals entstanden. Besonderer Dank gebührt daher
Wiebke Amann, Janina Britze, Wladimir Daibert, Robert Dabrowski, Anna-Karina Drews, Anne
Fidelak, Jana Geduhn, Stefanie Gramm, Christina Heiden, Thomas Plenius, Dan Röndigs, Eduard
Schmalz, Katharina Schrader, Alena Wagner und Elena Wagner.
Vielen Dank.
3
Nane Kratzke
Lübeck, im Februar 2011

Inhaltsverzeichnis
I Datenbanksysteme 9
1 Einleitung 11
1.1 Erste Generation: Lochkarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Zweite Generation: Random Access Dateisysteme . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Dritte Generation: Prärelationale Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Vierte Generation: Relationale Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 Fünfte Generation: Postrelationale Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . 12
2 Begriffsdefinitionen 15
2.1 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Datenbankmanagementsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 Konsistente und integrierte Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2 Datenunabhängigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.3 Gängige Operationen auf Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.3.1 Dateneingabe/-erfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.3.2 Suche/Sortierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.3.3 Datenausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.4 Katalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.5 Benutzersichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.6 Datenschutz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.7 Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.8 Datensicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Datenbanksystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1 Hierarchisches Datenbankmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.2 Das Netzwerk-Datenbankmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3 Das Relationenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3.1 Operationen auf Relationen . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.3.2 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Grundsätzlicher Aufbau von Datenbanksystemen . . . . . . . . . . . . . . . . . . . . . . . . 22
5

6 INHALTSVERZEICHNIS
3 Phasenmodell der Datenbankentwicklung 25
3.1 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Konzeptioneller Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Verteilungsentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Logischer Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Betrieb und Wartung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Die Drei Ebenen Architektur 29
4.1 Konzeptionelles Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Externes Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Internes Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
II Datenmodellierung 35
5 Einleitung 37
5.1 Hierarchisches Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Netzwerk-Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Entity-Relationship Modell und Relationenmodell . . . . . . . . . . . . . . . . . . . . . . . 39
6 Das Entity-Relationship Modell 41
6.1 Entitäten (Objekte) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2 Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.4 Exemplarische Veranschlaulichung des ER-Modells an einem durchgehenden Beispiel . . . . 44
7 Das Relationale Datenmodell 45
7.1 Tabellenanalogie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.2 Schlüsselattribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.3 Relationale Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.3.1 Projektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.3.2 Selektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.3.3 Kartesisches Produkt und JOINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.3.4 Umbenennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.3.5 Vereinigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.3.6 Schnittmengenbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.3.7 Differenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.4 Vollständigkeit der relationalen Algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

INHALTSVERZEICHNIS 7
8 Transformation und Normalisierung 55
8.1 Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1.1 Transformationsregel zur Überführung von Entities . . . . . . . . . . . . . . . . . . 55
8.1.2 Transformationsregel zur Überführung von n:m Relationen . . . . . . . . . . . . . . 56
8.1.3 Transformationsregel zur Überführung von 1:n Relationen . . . . . . . . . . . . . . . 56
8.2 Normalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8.2.1 Erste Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.2.2 Zweite Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.2.3 Dritte Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Literaturverzeichnis 61

8 INHALTSVERZEICHNIS

Teil I
Datenbanksysteme
9

Kapitel 1
Einleitung
Teil I des Skripts wurde von den Studentinnen Wiebke Amann, Anne Fidelak, Jana Geduhn,
Alena Wagner und Elena Wagner im Rahmen der Lehrveranstaltung Datenbank-gestützte
Server-seitige Programmierung im Wintersemester 2010 an der Fachhochschule Lübeck verfasst.
Ihnen gilt besonderer Dank.
Dieser Teil widmet sich der Einführung in das Thema der Datenbanksysteme. Er gibt einen Überblick über
alle wichtigen Begriffe der Datenbankentwicklung und hilft, in das Thema einzusteigen. Zu Beginn werden
die Begriffe Datenbank, Datenbankmanagementsystem und Datenbanksystem erklärt. Außerdem wird ihre
Beziehung zur serverseitigen Programmierung betrachtet. Darauf folgt eine Einordnung der relationalen
Datenbanken in den geschichtlichen Kontext. Das nächste Kapitel befasst sich mit den wesentlichen Funktionen
eines Datenbankmanagementsystems. Es wird ferner ein Phasenmodell der Datenbankentwicklung
behandelt und die einzelnen Phasen dieses Modells erläutert. Das letzte erklärende Kapitel ist eine Erklärung,
wie die Drei-Ebenen-Schemaarchitektur funktioniert und was in den einzelnen Ebenen geschieht. Im
Anschluss an die Kapitel, die sich mit Begriffsklärung befassen, wird erläutert, welche Bereiche des vorliegenden
Skripts skizzierte Themen in dieser Einleitung weiter vertiefen. Zudem wird das in der Vorlesung
genutzte durchgehende Beispiel erläutert und beschrieben.
Schon vor Jahrtausenden begannen die Menschen zu zählen. Sie entwickelten Zahlensysteme und ihre Darstellungsmöglichkeiten.
Beispielsweise existiert eine Tontafel aus dem Jahre 3000 v.Chr. mit Angaben über
Mengen von Tieren und Getreide in 10er und 60er Darstellung. In unserem heutigen komplexen Weltgeschehen
heißen diese vergleichbaren, rechnergestützten Hilfsmittel zur Organisation, Erzeugung, Manipulation
und Verwaltung großer Datensammlungen Datenbanksysteme. Ihre Entwicklungsgeschichte wird häufig in
der Literatur in fünf Generationen gegliedert.
1.1 Erste Generation: Lochkarten
Das Augenmerk der ersten Generation lag hauptsächlich auf dem Rechnen, Zählen und Ordnen von Daten,
welche auf langsame und fehleranfällige Lochkarten basierten. Weil Lochkarten nur sequentiell, also hintereinander,
gelesen werden konnten, mussten alle Informationen verarbeitet werden, die vor der gesuchten
standen. Ähnliches gilt für Magnetbänder, auf denen Daten nur sequentiell gespeichert werden konnten.
Diese wesentlichen Einschränkungen machten das System nicht gerade populär.
11

12 KAPITEL 1. EINLEITUNG
1.2 Zweite Generation: Random Access Dateisysteme
In der zweiten Generation um 1960 begann man die Daten auf Festplatten zu halten. Der schnelle, wahlfreie
Zugriff auf Informationen und die Möglichkeit, dass mehrere Nutzer gleichzeitig Zugriff auf die Datenbank
haben können, war äußerst vorteilhaft. Jedes Programm hatte aber immer noch seine speziellen Datensätze
und –bestände. Eine Programmänderung zog auch Änderungen der Datenverwaltung nach sich. Die
Gefahr der Datenredundanz, Dateninkonsistenz und natürlich die Probleme des Datenschutzes und der
Datensicherheit waren nicht gelöst.
1.3 Dritte Generation: Prärelationale Datenbanksysteme
Die dritte Generation in den 70er Jahren zeigte erste Unterschiede zwischen der logischen und der physischen
Datenverwaltung auf. Es wurden erstmalig Datenmodelle zur logischen Beschreibung physikalischer
Strukturen benutzt. Insbesondere entstanden das hierarchische Datenmodell und das Netzwerkmodell. Sie
wurden für die Implementierung der ersten "echten" Datenbanksysteme verwendet. Ein hierarchisches Datenbankmodell
bildet die reale Welt durch eine hierarchische Baumstruktur ab. Jeder Datensatz (Record)
hat genau einen Vorgänger, mit Ausnahme eines "Wurzel"-Satzes der so entstehenden Baumstruktur. Das
Netzwerkmodell als Erweiterung des hierarchischen Datenmodells bietet die Möglichkeit der Mehrfachbeziehungen
zu den Vorgängern. Ein Nachfolger kann einen oder mehrere Vorgänger haben. Eine heute noch
häufig eingesetzte Netzwerkdatenbank ist IDMS der Firma Computer Associates.
1.4 Vierte Generation: Relationale Datenbanken
Das Relationale System der vierten Generation wurden Anfang der 80er Jahre kommerziell verfügbar. Es
basiert auf einem völlig anderen Ansatz zur Organisation von Daten, welcher eine wesentlich klarere Unterscheidung
zwischen einem physischen und einem logischen Datenmodell erlaubt. Die physische Speicherung
nach außen ist transparent und man kann sowohl auf der logischen als auch auf der physischen Seite
Veränderungen vornehmen, ohne dass die jeweils andere Seite davon betroffen ist. Die Datenverarbeitung
erfolgt tabellarisch und mengenorientiert. Die Sprache, welche dem Benutzer eines relationalen Systems zur
Verfügung steht, befreit ihn im Allgemeinen weitgehend von Problemen des "Wie" beim Verwalten von
und dem Arbeiten mit Daten, er kann sich jetzt zunehmend auf das "Was" konzentrieren. Die Grundsteine
dafür legte Edgar F. Codd mit seiner Forschungsarbeit am IBM Almaden Research Center. Dabei war er
wesentlich beteiligt an der Entwicklung des Systems R. Es ist neben Ingres der erste Prototyp eines relationalen
Datenbankmanagementsystems und verwendete die Abfragensprache SEQUEL (= Structured English
Query Language), aus der die SQL-Abfragesprache hervorging. Auf System R basieren auch die späteren
IBM-Produkte SQL/DS und DB2 sowie die Datenbanksysteme von Oracle. Für seine fortwährenden Arbeiten
auf dem Gebiet der Datenbanken erhielt Codd 1981 den Turing Award, der als höchste Auszeichnung
in der Informatik gilt.
1.5 Fünfte Generation: Postrelationale Datenbanksysteme
In den 90ern, also in der fünften Generation, bilden die Datenbanksysteme die Datenbasis nicht zweidimensional
ab, sondern multidimensional in sogenannten Datenwürfeln. Dadurch arbeiten diese postrelationalen
Datenbanksysteme wesentlich schneller und effizienter. Die Speicherung bzw. Verknüpfung erfolgt in Objektform
und die Zugriffe erfolgen objektorientiert. Da Datenstrukturen äußerst komplex abgebildet werden
können, findet diese Technik hauptsächlich Einsatz bei Internet-Suchmaschinen. Bei der parallelen Entwicklung
der objektorientierten Datenbank werden im Unterschied zur relationalen Datenbank Daten als Objekte

1.5. FÜNFTE GENERATION: POSTRELATIONALE DATENBANKSYSTEME 13
im Sinn der objektorientierten Programmierung verwaltet. Objektdatenbank und Objektdatenbankmanagementsystem
bilden ein Objektdatenbanksystem.

14 KAPITEL 1. EINLEITUNG

Kapitel 2
Begriffsdefinitionen
2.1 Datenbank
Eine Datenbank besteht aus einem strukturierten und integrierten Datenbestand, in dem die Daten miteinander
in Beziehung stehen. Technisch gesehen stellt eine Datenbank ein häufig verteiltes, integriertes
Computersystem dar, welches Nutzdaten und Metadaten enthält. Unter Nutzdaten versteht man Daten,
die der Benutzer in der Datenbank anlegen kann. Aus diesen Daten wird Information gewonnen. Metadaten
hingegen sind Daten über die vom Nutzer eingegebenen Informationsdaten, mit deren Hilfe man die
Möglichkeit hat die Nutzdaten zu strukturieren.
Abbildung 2.1 zeigt ein einfaches Beispiel einer Datenbank für die Kundenverwaltung.
Abbildung 2.1: Bsp. Kundenverwaltungsprogramm
Jede Überschrift verdeutlicht, was der Inhalt der jeweiligen Spalte bedeutet und beschreibt diese Spalte.
Die Überschriften sind hier die Metadaten. Die einzelnen Adressen stehen hierbei in keiner Beziehung zu
einander.
In der Spalte KundenPLZ befinden sich die Postleitzahlen aller Kunden. KundenPLZ ist eine Eigenschaft
des Kunden (Entität). Dieses Segment wird als „Feld“ bezeichnet, in relationalen Datenbanken auch als
Relationenschema bekannt. Eine komplette Zeile der Nutzdaten stellt den „Datensatz“ dar. Einzelne Segmente
der Nutzdaten werden als „Daten“ bezeichnet. Metadaten und Nutzdaten ergeben zusammen die
Datei. Genauso wie eine Ansammlung von zusammengehörigen Datensätzen.
Bei dem Erstellen einer Datenbank ist auf das Design der Datenbank zu achten. Mit Design sind die Struktur
der Tabellen, in denen die Nutzdaten vorhanden sind und die Beziehung zwischen mehreren Tabellen
15

16 KAPITEL 2. BEGRIFFSDEFINITIONEN
gemeint. Ein schlechtes Datenbankdesign kann dazu führen, dass Daten mehrfach in einer Datenbank auftreten.
Diese Daten heißen redundante Daten und werden über ein und dieselbe Entität mehrfach gespeichert.
Eine Entität stellt ein Objekt der realen Welt dar, wie zum Beispiel eine Person oder einen Gegenstand. Ein
Beispiel dafür ist, wenn Kontaktdaten eines Kunden in jedem Datensatz gespeichert werden, in dem auch die
Rechnung gespeichert wird. Bei Änderung der Kontaktdaten müssen diese in JEDEM Rechnungsdatensatz
geändert werden. Das führt zu einer erhöhten Fehlerquote.
2.2 Datenbankmanagementsysteme
Die Verwaltung solcher Datenbanken geschieht über das Datenbankmanagementsystem (DBMS). Eine
DBMS stellt eine Verwaltungssoftware dar und ermöglicht es auf die Nutzdaten zuzugreifen. Ein Beispiel für
ein DBMS wäre Microsoft Access - im Rahmen der Lehrveranstaltungen wird üblicherweise MySQL genutzt.
Ein Datenbankmanagementsystem kann entweder aus einem oder auch mehren Programmen bestehen.
Datenbankmanagementsysteme dienen der effizienten und rechnergestützten Organisation, Erzeugung, Manipulation
und Verwaltung großer Datenmengen. Die Datenverwaltung, die aus dem Schreiben, Ändern und
Löschen von Daten besteht, erfolgt mit ihrer Hilfe. Des Weiteren werden leistungsfähige Suchfunktionen
zur Verfügung gestellt um den Zeitaufwand, der für das Finden von Daten benötigt wird, zu minimieren.
Der große Vorteil von DBMS besteht darin, dass jegliche Art von Daten (Namen, Adressen, etc.) an einem
logisch zusammengehörigen Platz gespeichert und bereitgestellt werden können.
Datenbankmanagementsysteme haben alle die Aufgabe die nachfolgenden Funktionen bereitzustellen.
2.2.1 Konsistente und integrierte Datenhaltung
Datenintegrität bedeutet logische Widerspruchsfreiheit der Daten. Von daher ermöglicht DBMS die einheitliche
Verwaltung der Daten. Alle in einer Datenbank gespeicherten Daten müssen unter sich und vor allem
auch in ihrer Beziehungen zueinander in einem logisch stimmigen Zustand stehen. Somit wird jedes logische
Datenelement, wie beispielsweise der Name eines Kunden, an nur einer Stelle in der Datenbank gespeichert.
Außerdem muss ein DBMS die Möglichkeit bieten, eine Vielzahl komplexer Beziehungen zwischen den Daten
zu definieren sowie zusammenhängende Daten schnell und effizient miteinander zu verknüpfen. Auch
die Sichtweise der Daten muss einheitlich und logisch dargestellt werden. Zum Beispiel bei einem relationalen
Datenbanksystem müssen sämtliche Daten dem Benutzer in Tabellen- oder Relationenform dargestellt
werden. Auch Systemdaten werden in Relationen verwaltet.
Abbildung 2.2 zeigt einen Fall inkonsistenter Datensätze, in denen die Daten nicht korrekt eingetragen
wurden.
2.2.2 Datenunabhängigkeit
Wesentliches Ziel bei Einsatz eines Datenbanksystems besteht darin, Datenunabhängigkeit zu erreichen, das
heißt eine weitgehende Unabhängigkeit von Daten und Programmen oder Benutzern, die mit diesen Daten
arbeiten.
Die Notwendigkeit der Datenunabhängigkeit wird in den folgenden Punkten deutlich:
1. Alle Daten einer bestimmten Anwendung sollen in einem integrierten Bestand der Datenbank, jeweils
einmal und dauerhaft gespeichert werden, sodass der Bestand weitgehend frei von Redundanzen bleibt.
2. Alle Benutzer sollen zeitgleich auf physischer Ebene mit dem gleichen Datenbestand arbeiten können,
so dass einheitliche Integritätskontrollen sowie Schutz und Sicherungsmechanismen anwendbar sind.

2.2. DATENBANKMANAGEMENTSYSTEME 17
Abbildung 2.2: Inkonsistente Datensätze
3. Einzelne Benutzer oder Benutzergruppen sollen unterschiedliche logische Sichten auf die Datenbank
haben, damit die Daten anwendungsbezogen strukturiert werden können.
Datenunabhängigkeit schließt ein, dass ein Datenbanksystem anpassungsfähig ist, d.h. neue Anwendungen
und Benutzersichten sollen keinen Einfluss auf bereits existierende Anwendungen und Sichten haben. Anwendungsprogramme
und Datenorganisation müssen unabhängig voneinander sein. Änderungen der physischen
Organisation der Daten müssen möglich sein, ohne dass sämtliche Anwendungsprogramme geändert werden
müssen. Erweiterungen der Datenstruktur (z.B. Aufnahme eines neuen Datenelementes) dürfen nicht dazu
führen, dass bisherige Anwendungsprogramme, die diese neuen Informationen nicht benötigen, geändert
werden müssen.
2.2.3 Gängige Operationen auf Datenbanken
Alle Datenbankmanagementsysteme unterstützten gewisse Standardfunktionen. Hiezu gehören Datenmanipulationen
(Eingabe, Änderung, Löschen), Datenselektion (Suche) und Datenausgabe. All die werden
in einer einheitlichen Datenbanksprache angeboten und sind möglichst einfach in der jeweiligen Sprache
formulierbar.
2.2.3.1 Dateneingabe/-erfassung
Bei der Dateneingabe (über Tastatur) oder -erfassung (über Messgeräte etc.) ist besonders darauf zu achten,
dass keine falschen oder unvollständigen Daten in die Datenbank gelangen. Ab einer gewissen Größe
sind die Daten nicht mehr wirklich korrigierbar. Entsprechende Maßnahmen dagegen (Konsistenzprüfungen)
werden von den meisten Datenbanksystemen unterstützt. Die Dateneingabe durch Menschen stellt insofern
einen besonderen Problembereich dar, da Menschen üblicherweise "Fehler" machen, die vielleicht für den
anderen Menschen harmlos erscheinen doch für ein Datenverarbeitungssystem katastrophale Folgen haben
können. Je stärker der formale Charakter von Daten ist, desto eher ist der Computer in der Lage, ihre Richtigkeit
zu prüfen (z.B. Prüfziffer am Ende einer mehrstelligen Zahl, Tippfehler durch Rechtschreibkorrektur,
Vollständigkeit eines Datums etc.).

18 KAPITEL 2. BEGRIFFSDEFINITIONEN
2.2.3.2 Suche/Sortierung
Nach Daten in einer Datenbank zu suchen bedeutet, eine Auswahl (Selektion) zu treffen: eine Teilmenge
von Datensätzen aus der Gesamtmenge wird festgelegt. Für den Benutzer präsentiert sich die Suche oft
in einer Maske mit den suchbaren Datenfeldern. Üblicherweise werden boolesche Operationen unterstützt
(logisches UND, logisches ODER, logisches NICHT). Auf jeden Fall ist ein Datenbanksystem darauf zu
prüfen, was es in der Hinsicht auf Suchmöglichkeiten kann und vor allem nicht kann. Die Sortierung von
Daten ist eigentlich eher der Datenausgabe zu zurechnen. Sortierungen erfolgen absteigend oder aufsteigend,
numerisch, alphabetisch oder alphanumerisch, mehrere Sortierebenen sind möglich (die letzte Ebene ist
damit immer die wichtigste).
2.2.3.3 Datenausgabe
Für die Datenausgabe ("Reports") gibt es eine Vielzahl verschiedener Modelle und Möglichkeiten. Die
Daten können sich in der Ausgabe auch völlig anders präsentieren als in der Eingabe. Dies ist in erster Linie
vom Zweck der Datenbank abhängig. Zu beachten ist auch, wohin die Ausgabe erfolgt bzw. erfolgen kann:
Bildschirm, Drucker, Datei, andere Schnittstellen.
2.2.4 Katalog
Das DBMS hat einen Katalog, vergleichbar mit einem Datenverzeichnis, das Daten über die Namen, Struktur,
Attribute, Lage und Typen der abgelegten Daten enthält. Alle diese Daten werden als Metadaten bezeichnet.
Beispielsweise: Eigentümer, Erzeugungszeit von Datenbankobjekten, Beschreibung von Tabellen
und ihren Spalten bei relationaler Datenbank (Datentyp, Länge). In diesem Metadaten-Verzeichnis werden
alle logischen und physikalischen Informationen und Änderungen während der gesamten Lebensdauer der
Daten gespeichert: vom Einlesen bis zu Löschen.
Diese Metadaten können mit den Mitteln der Datenbanksprache genauso gelesen werden wie die normalen
Nutzdaten.
2.2.5 Benutzersichten
Eine Benutzersicht (oder einfach Sicht, engl. view) ist eine Darstellung der Daten, die an die Anforderungen
individueller Benutzer oder Anwendungsfälle angepasst ist. Für unterschiedliche Klassen von Benutzern sind
verschiedene Sichten erforderlich, die bestimmte Ausschnitte aus dem Datenbestand beinhalten und dese
in unterschiedlichen Detaillierungsstufen sehen. Ein Benutzer kennt lediglich die für ihn vorgesehene Sicht.
Er kann sie abfragen und verändern, wie eine eigenständige Datenbank. Durch dieses Konzept bleibt dem
Benutzer die konzeptionelle Komplexität der eigentlichen Datenbank verborgen, wodurch eine Vereinfachung
im Umgang mit der Datenbank erreicht wird. Die Sichten sind im externen Schema der Datenbank definiert
und werden durch Anfragen an die Datenbank beschrieben und reflektieren zu jeder Zeit das Ergebnis
dieser Anfragen. Die Definition von Sichten ist mit den Möglichkeiten des Datenschutzes stark verknüpft
und bietet einen sehr flexiblen Mechanismus zur Zugriffsbeschränkung auf Informationen. So können manche
Informationen in einzelnen Sichten vor dem Benutzer verborgen werden, während sie in anderen Sichten
oder für andere Benutzer verfügbar sind.
2.2.6 Datenschutz
Datenschutz umfasst mehrere Aspekte, von denen zwei besonders wichtig sind. Zunächst müssen aufgrund
des Datenschutzgesetzes die personenbezogenen Informationen vom Zugriff der nicht berechtigten dritten

2.2. DATENBANKMANAGEMENTSYSTEME 19
Personen geschützt werden. Auch der Zugriff auch unternehmensrelevante Daten muss aus Wettbewerbsgründen
geeignet beschränkt werden.
Hauptaufgabe eines Datenbankmanagementsystem hinsichtlich des Datenschutzes ist es also, unautorisierter
Zugriff auf die gespeicherte Daten zu verhindern. In einem Unternehmen, welches eine Datenbank für
Kunden- und Zulieferdaten hat, ist es mit Sicherheit erwünscht, dass nicht jeder Benutzer Zugriff auf die
gesamten Daten hat und diese beliebig verändern kann. Beispielsweise sollte ein Mitarbeiter der Abteilung
“Einkauf” nicht die Rechnungsdaten der Endkunden verändern, vielleicht nicht einmal einsehen, dürfen. Die
Rechnungsdaten dürfen nur die Mitarbeiter der Abteilung “Verkauf/Vertrieb” bearbeiten. Die Geschäftsführung
soll aber alle Daten einsehen und verändern dürfen. Vielleicht gibt es auch Zulieferer oder Endkunden,
die bestimmte Daten aus der Datenbank lesen oder sogar verändern dürfen.
Hierzu können für jeden Benutzer Berechtigungen für den Zugriff auf Daten definiert und in der Datenbank
gespeichert werden. Für verschiedene Benutzer oder Benutzerklassen kann festgelegt werden, auf welchen
Originaldaten oder Sichten sie welche Operationen ausführen dürfen. Ein DBMS verwaltet Zugriffsrechte,
die von den Datenbank-Administratoren eingerichtet werden. So müssen nicht alle Daten der gesamten
Belegschaft oder Dritten anvertraut werden müssen.
Wenn Sichten, Benutzerklassen und Operationen mit der Datenbanksprache sehr detailliert festgelegt werden
können, lassen sich unberechtigte Zugriffe auf die Daten gut ausschließen.
2.2.7 Transaktionen
Eine Transaktion ist eine Folge von Datenbankaufrufen, die logisch zusammengehören und eine Datenbank
von einem konsistenten Zustand in einen anderen konsistenten Zustand überführen. Eine Transaktion arbeitet
nach dem „Alles oder Nichts“ - Prinzip. Das heißt sie muss entweder vollständig durchgeführt oder
ganz zurückgesetzt werden. Beispiel einer Transaktion: Vermutlich hat jeder schon Geld am Bankautomat
abgehoben. Das Konto wird natürlich datenbankunterstützt verwaltet. Beginnend von der Identifikation
der Bankkarte bis zur kompletten Auszahlung des Geldes muss alles ein kompletter Geschäftsvorfall (eine
Transaktion) sein. Wenn irgendetwas „schief läuft“, muss der Zustand des Kontos so sein, als wäre nie ein
Auszahlungsversuch unternommen worden. Dabei ist es gleich, wie viele Leute an wie vielen Automaten
gleichzeitig abheben, sogar wenn dies vom gleichen Konto geschehen würde. Eine Datenbank ist eine integrierte
Ansammlung von Daten, die unterschiedlichen Anwendungen als gemeinsame Datenbasis dient. Um
diesen Dienst konsistent und fehlertolerant anbieten zu können, wurde das Transaktionskonzept entwickelt.
Eine Transaktion sorgt dafür, dass eine logisch zusammengehörige Folge von Operationen ohne negative
Begleiterscheinungen auf der Datenbank ausgeführt werden kann.
Eine Transaktion hat bestimmte Leistungen abzudecken, die durch so genannten ACID - Eigenschaften
beschreiben werden: Atomarität: Eine Transaktion ist unteilbar. Sie wird entweder ganz oder gar nicht
ausgeführt. Wird eine laufende Transaktion abgebrochen, so ist die Datenbank so zu hinterlassen, als hätte
es die Transaktion nie gegeben. Konsistenz: Sind die von einer Transaktion betroffenen Daten vor der
Transaktion konsistent, so sind sie es auch nach der Transaktion (Konsistenzerhaltung). Diese Forderung
kann aber nicht automatisch durch das DBMS garantiert werden. Trotz Konsistenzbedingungen kann nicht
ausgeschlossen werden, dass ein inkorrekter Wert eingefügt wurde (z.B. der Name „Meyer“ statt „Maier“).
Isolation: Trotz der möglicherweise existierenden Parallelarbeit vieler Benutzer auf der Datenbank muss das
DBS so agieren, als würde jeder Benutzer isoliert, d.h. alleine, auf der DB arbeiten. Das geschieht durch die
Synchronisation der Transaktionen, die gleichzeitig ausgeführt werden. Irgendwelche Beeinflussungen durch
den Parallelbetrieb sind dabei auszuschließen. Daten werden von Wettlaufsituationen durch den parallelen
Zugriff mehrerer Benutzer geschützt.
Am Markt erhältliche DBMS realisieren heutzutage zumeist das so genannte Zweiphasensperrprotokoll,
bei dem alle Daten, die von einer Transaktion genutzt werden, zunächst gesperrt werden müssen. Die gemeinsame
Sperre erlaubt paralleles Lesen. Exklusive Sperre ist für das Ändern der Daten zuständig. Dabei
besteht eine Transaktion aus zwei Phasen. In der ersten dürfen nur Sperren erworben werden, in der zweiten

20 KAPITEL 2. BEGRIFFSDEFINITIONEN
nur wieder freigegeben werden. Dauerhaftigkeit: Änderungen, die in einer Transaktion erfolgt sind, sind
in der Datenbank festgeschrieben und stehen allen zur Verfügung. Bei einem Systemausfall werden alle
abgeschlossen Transaktionen festgeschrieben und offene zurückgerollt. Die Auswirkungen einer abgeschlossenen
Transaktion auf der Datenbank können immer wieder hergestellt werden, unabhängig davon, welcher
Fehlerfall auch auftreten mag (bis hin zum kompletten Verlust der eigentlichen Datenbank).
2.2.8 Datensicherung
Im Falle eines Betriebsmittelsausfalles oder eines Systemfehlers kann der interne Zustand der Datenbank in
einen nicht definierten Zustand geraten. Ein DBMS verfügt deshalb über Mechanismen, die den Benutzer
vor den Auswirkungen von Systemfehlern schützen und das System wieder in einen konsistenten Zustand
überführen. Meist nachts werden Sicherungskopien der Datenbank auf Bändern vorgenommen (backup).
Während des Tagesablaufs wird diese Maßnahme gewöhnlich durch ein Protokoll der durchgeführten Änderungen
ergänzt. Wird die Datenbank modifiziert, erfolgt ein Protokolleintrag. Bei einem Systemabsturz
werden die Bänder und das Protokoll dazu benutzt, in der Datenbank den zuletzt aktuellen Zustand automatisch
wiederherzustellen (recovery). Das Rücksetzen der Datenbank soll weitgehend automatisch erfolgen.
2.3 Datenbanksystem
Ein Datenbanksystem (DBS) besteht aus einer oder mehreren Datenbanken und einem Datenbankmanagementsystem.
Es dient zur elektronischen Datenverwaltung und bietet dafür eine Datenbanksprache an (bei relationalen
Datenbanksystemen ist dies zumeist die noch im Detail erläuterte Sprache SQL). Die gängigsten Sprachelemente
der SQL (und auch anderer Datenbanksprachen) sind die Data Manipulation Language (DML),
die Data Definition Language (DDL) und die Data Control Language (DCL). Mit DML können Daten
eingefügt, geändert oder gelöscht werden. Mit DDL können Tabellen (Datenstrukturen) erstellt werden und
mit DCL dient der Rechtsverwaltung und der Transaktionskontrolle.
Die wichtigsten Aufgaben eines Datenbanksystems sind das dauerhafte, widerspruchsfreie und wirksame
Speichern von großen Datenmengen und die Bereitstellung von Teilmengen in unterschiedlichen Darstellungsformen
für User und Anwenderprogramme. Eine gängige Darstellungsform ist die Relation. Mit welcher
Art ein Datenbanksystem Daten speichert und verwaltet legt das logischen Datenbankmodell fest. Es wird
zwischen dem Hierarchischen, Netzwerk-, Relationen, Entity Relationship- und Objektorientierten Modell
unterschieden.
Historisch betrachtet sind die drei folgenden logischen Datenbankmodelle die wichtigsten gewesen, von
denen sich vor allem das relationale Datenmodell durchgesetzt hat.
2.3.1 Hierarchisches Datenbankmodell
Man stelle sich eine Baumstruktur vor, einen Baum mit Verbindungsknoten. Die Knoten werden Records
genannt und die Baumstruktur stellt die Beziehung zwischen den Records dar. Ein Knoten kann mehrere
Nachfolger besitzen. Ein Knoten kann maximal einen Vorgänger haben, aber mehre Nachfolger, Söhne genannt.
Die Nachfolger eines Knotens werden als Kindknoten bezeichnet und der Vorgänger als Elternknoten.
Hat ein Knoten keinen Elternknoten, wird dieser als Wurzelknoten bezeichnet und wenn ein Knoten keine
Nachfolgerknoten hat, ist es ein Blattknoten. Blattknoten bilden die letzte Ebene.
In dem Fall, dass zwei verschiedene Knoten den gleichen Record als Nachfolger haben, muss dieser mehrfach
in der Baumstruktur vorkommen, also redundant sein. Die Technische Umsetzung der Beziehungen zwischen
den Records geschieht über Pointer. Ein Pointer ist eine Variable, die eine Speicheradresse enthält. Dort

2.3. DATENBANKSYSTEM 21
können Daten, wie zum Beispiel Variablen oder Objekte stehen, aber auch Programmcode. Der Zugriff
erfolgt beispielsweise über eine Pre-Order-Traversierung der Struktur. Man geht vom Wurzelknoten aus.
Unter Traversierung versteht man das Untersuchen von Knoten eines Baumes in einer bestimmten Reihenfolge.
Man unterscheidet zwischen Preorder-, Postorder-, Inorder- und Levelorder-Traversierung. Für eine
Preorder-Traversierung lautet die Regel: "Besuche die Wurzel, besuche dann den linken Unterbaum, besuche
dann den rechten Unterbaum". Die Postorder-Traversierung sagt: „Besuche den linken Unterbaum,
besuche dann den rechten Unterbaum und dann die Wurzel“.
Bei der Inorder-Traversierung wird zuerst der linke Unterbaum besucht, dann die Wurzel und dann der
rechte Unterbaum. Laut der Levelorder-Traversierung wird zuerst die Wurzel besucht, dann die Söhne und
dann die nächste Reihe. Der Durchlauf erfolgt von oben nach unten und von links nach rechts.
Das Einfügen, Löschen und Ändern ist nur im Rahmen der Hierarchie möglich, also nur durch Zugriff über
den Vater. Der Nachteil von dem hierarchischen System ist, dass es zwar 1:N-Beziehungen gibt, aber keine
M:N-Beziehung. Des Weiteren können gleiche Datensätze an mehreren Stellen benötigt werden und müssten
demnach mehrmals auftreten. Das erzeugt Datenredundanz.
2.3.2 Das Netzwerk-Datenbankmodell
Das Netzwerk-Datenbankmodell entspricht in groben Zügen dem hierarchischen Datenbankmodell. Die Probleme
der Redundanz von Knoten werden mit den so genannten Link-Records behoben. Link-Records können
Mehrfachzuweisungen darstellen. Die Elternknoten heißen hier Owner und die Söhne heißen Member. Anders
als im hierarchische Datenbankmodell kann ein Knoten mehrere Kindknoten UND mehre Elternknoten
besitzen.
Für die Beziehungen zwischen Knoten sind wie im hierarchischen System Pointer zuständig. Bei den Beziehungen
wird nun zwischen 1:1- und 1:N-Beziehungen unterschieden und die Darstellung erfolgt durch
einen gerichteten Graphen. Die Beziehung zwischen Knoten wird Menge genannt. Die Elternkonten sind
die Besitzer und Kindknoten die Mitglieder der Menge. Das erlaubt einem Knoten in mehreren Beziehungen
gleichzeitig vertreten zu sein. M:N-Beziehungen kommen zustande, in dem ein künstliches Kett-Record
eingefügt wird. Dieser wird in beide Richtungen als Member angegeben, der einen ungerichteten Graphen
erzeugt und somit die Traversierung überflüssig macht. Im Netzwerk-Modell wird ein Mengenmitglied nur
definiert, wenn es einen Besitzer (Owner) der Menge gibt. Dadurch wird die Datenintegrität verbessert. Die
Datenintegrität besagt, dass sich die Daten einer Datenbank in einem widerspruchsfreien Zustand befinden,
also konsistent sind.
Nachteil des Netzwerk-Datenbankmodells ist die schwere Implementierung und Verarbeitung der Datenbank.
2.3.3 Das Relationenmodell
In diesem Datenbank-Modell werden keine Zeiger benutzt um Beziehungen darzustellen. Beziehungen werden
über inhaltliche Angaben realisiert und durch Werte und Attribute dargestellt. Die Daten der Datenbank
werden in Form einer Relation festgelegt. Relationen sind Tabellen, die wiederum Mengen von Tabellen darstellen.
Diese Relation besteht aus einem Namen und Attributen und Datensätzen. Attribute sind die Spalten
und die Datensätze – auch Tupel genannt – die Zeilen. Attribute bestehen aus den Spaltenüberschriften
und bilden die Struktur der Tabelle, auch Relationenschema genannt. Um einen Datensatz eindeutig zu
identifizieren wird ein so genannter Primärschlüssel verwendet, wie beispielsweise eine Matrikelnummer eines
Studenten. Des Weiteren besitzt ein Datensatz auch einen Fremdschlüssel um auf einen Datensatz
einer weiteren Tabelle zu verweisen. Dieser Schlüssel wird auch Pointer genannt. Der Fremdschlüssel ist als
eine fortlaufende ID gekennzeichnet. Diese ID taucht in der ersten Tabelle als Fremdschlüssel auf und in
dem Datensatz, auf den dieser verweist, als Primärschlüssel. So stehen Datensatz A und Datensatz B in
Beziehung zu einander. Die Mastertabelle steht mit der Detailtabelle in einer 1:N-Beziehung. Das bedeutet,

22 KAPITEL 2. BEGRIFFSDEFINITIONEN
dass ein Datensatz der Mastertabelle mit beliebig vielen Datensätzen der Detailtabelle in Beziehung steht.
Eine weitere Besonderheit der Attribute ist die Bezeichnung. Es sind keine zusammengesetzten Attribute erlaubt.
Das Relationale Datenbanksystem bietet den Vorteil, dass es im Vergleich zu anderen Systemen keine
strukturelle Abhängigkeit gibt, also kein Navigieren durch die Struktur. Der Zugriff des Rationalen DBMS
muss nicht geändert werden, wenn sich die Struktur der Datenbank ändert. Außerdem ist die physikalische
Struktur der Daten nicht relevant, da diese durch das RDBMS abgetrennt wird.
2.3.3.1 Operationen auf Relationen
Auf die Daten der Relationalen Datenbank wird mit folgenden Grundoperationen zugegriffen: Selektion,
Projektion und Mengenoperationen, die aus Vereinigung, Durchstoß und Differenz bestehen sowie mit dem
Kartesischen Produkt.
Mit der Selektion ist es möglich, eine Zeile auszuwählen und mit Projektion eine Spalte. Mit der Vereinigung
werden alle Datensätze der Tabelle A mit der Tabelle B vereint, wobei gemeinsame Datensätze nicht doppelt
aufgeführt werden. Die Operation Durchstoß liefert nur die gemeinsamen Attribute von zwei Relationen.
Die Differenz zweier Relationen drückt aus, dass die gemeinsamen Daten der Relationen A und B von A
abgezogen werden. Dabei sind keine N:M-Beziehungen möglich. Das Kartesische Produkt zweier Relationen
besagt, dass jede Zelle der Tabelle mit jeder Zelle der Tabelle B verknüpft wird. Dabei sind N:M-Beziehungen
möglich. Diese Operation wird auch mathematisches Kreuzprodukt genannt.
Des Weiteren werden noch die Operationen Join, Natural Join, Restriktion und Division angewendet um
Daten ausfindig zu machen. Die Join-Operation entspricht einem Kreuzprodukt mit einer anschließenden
Selektion. Natural Join arbeitet ebenfalls mit dem Kartesischen Produkt und verknüpft zwei Relationen über
gemeinsame Attribute. Zwei Tupel verschmelzen, wenn sie in den gemeinsamen Attributen gleiche Werte
besitzen.
2.3.3.2 SQL
Die Konkretisierung des Relationenmodells in Form einer Programmiersprache kann in der Datenbanksprache
SQL gesehen werden. Die im Relationenmodell definierten Prinzipien und Operationen sind in der SQL
realisiert.
SQL hat sich als Standardsprache für den Zugriff auf relationale Datenbanken durchgesetzt. Mit ihr ist es
möglich, Datenbanken zu erzeugen, zu verwalten und Daten in einer Datenbank zu verändern. Sie ist keine
prozedurale Sprache, wie beispielsweise Pascal oder C++, bei denen der Nutzer definieren muss, wie eine
Aufgabe zu lösen ist. SQL ist eine sogenannte deklarative Sprache: Der Nutzer gibt dem Datenbankmanagementsystem
über SQL die Information, was er als Ergebnis erwartet.
2.4 Grundsätzlicher Aufbau von Datenbanksystemen
Ein komplexes Datenbanksystem ist im allgemeinen in vier Schichten gegliedert. Ein DBS besteht aus einer
Hardware-, Daten-, Software- und Personenschicht.
1. Erste Schicht: Hardware Die Hardwareschicht beinhaltet alle physikalischen Geräte wie den Server,
die Clientrechner, Kabel, Hubs, Router, Bridges, Firewalls und Peripheriegeräte.
2. Zweite Schicht: Daten Sie enthält alle Daten, die in der Datenbank gespeichert sind. Wenn die Daten
in Zusammenhang gebracht werden, liefern diese auch sinnvolle Informationen. Da die Daten gut
geschützt werden müssen, greift nur das Datenbankmanagementsystem auf die Daten zu.

2.4. GRUNDSÄTZLICHER AUFBAU VON DATENBANKSYSTEMEN 23
3. Dritte Schicht: Software Diese Schicht besteht aus dem Datenbankmanagementsystem, verschiedenen
Anwendungsprogrammen, wie beispielsweise Windows-Anwendungen oder Webanwendungen.
Des Weiteren gehören Dienstprogramme zur Softwareschicht, die ausschließlich von Administratoren,
Datenbankdesignern und Programmierern verwendet werden. Sie dienen zu Wartungsarbeiten an der
Datenbank. Zu Wartungsarbeiten gehören Datensicherung und Überprüfung der Datenbank. Als letzte
Software ist das Betriebssystem zu nennen. Dazu zählt das Betriebssystem des Servers und der
Clientrechner
4. Vierte Schicht: Personen Personen, die mit dem Datenbanksystem arbeiten, werden in verschiedene
Gruppen unterteilt. Diejenigen, die nur Daten erfassen und auswerten, verwenden nur die Anwendungsprogramme.
Die nächste Personengruppe besteht aus den Datenbankadministratoren. Sie verwalten
das Datenbanksystem und sorgen für die fehlerfreie Funktion des Datenbanksystems. Weitere
Aufgaben der Administratoren wären das zur Verfügung stellen von Speicherplatz, die Vergabe von
Berechtigungen und die Anlage von Benutzern. Für die Struktur des Datenbanksystems sorgen die
Datenbankdesigner und Programmierer.

24 KAPITEL 2. BEGRIFFSDEFINITIONEN

Kapitel 3
Phasenmodell der
Datenbankentwicklung
Um die Prozesse der Systementwicklung planen, steuern und kontrollieren zu können, wird häufig ein Phasenmodell
verwendet. Dieses Modell reicht von der Beschreibung der Anforderungen bis hin zur Realisierung
der Datenbank und ist wichtig, um alle gestellten Ansprüche des Anwenders an die Datenbank zu berücksichtigen.
Die Abarbeitung der einzelnen Schritte ist allerdings nicht bindend. Je nach Problemlage können
Phasen auch mehrmals durchlaufen werden.
Das Phasenmodell gliedert sich in sieben Phasen, die im folgenden Text genauer betrachtet und erläutert
werden. Die folgende Abbildung 3.1 zeigt die einzelnen Phasen des Datenbankentwurfs wobei eine
Vorgehensweise strikt nach diesem Schema ein Idealzustand ist, der nahezu nie so erreicht werden kann.
3.1 Anforderungsanalyse
Abbildung 3.1: Phasenmodell der DB-Entwicklung
In der ersten Phase geht es darum, alle relevanten Informationen einzuholen, die für alle weiteren Schritte
der Datenbankentwicklung wichtig sind. Alle Anforderung potentieller Datenbanknutzer und die des Auf-
25

26 KAPITEL 3. PHASENMODELL DER DATENBANKENTWICKLUNG
traggebers müssen berücksichtigt werden. Wichtig ist, dass nicht nur auf die Funktionalität eingegangen
wird, sondern dass vor allem die Häufigkeit der Datenabfrage und deren Speicherung beachtet werden.
Um genügend und vor allem aussagekräftige Informationen zu erhalten, werden die bestehenden Arbeitsprozesse
und existierende Dokumente analysiert, sodass später die Erwartungen an das auf die Datenbank aufbauende
Informationssystem erfüllt werden können. Eine weitere wichtige Maßnahme ist die Befragung von
zukünftigen Benutzern des Systems. So kann in der Entwicklung speziell auf die Forderungen der Endnutzer
eingegangen werden. Außerdem muss festgestellt werden, wo welche Daten warum gespeichert werden.
Dabei ist zu beachten, wie oft Daten abgefragt oder geändert werden sollen und welche Personen das Recht
haben, auf die Daten zuzugreifen und diese zu ändern.
Damit die Integrität und Persistenz der Daten garantiert werden kann, ist die Einhaltung verschiedener
Bedingungen wie Wertebereiche, Plausibilitäten und Abhängigkeiten von großer Bedeutung. Beispiele zum
Verständnis der Begriffe: Wertebereich: Das Attribut „Alter“ darf keine negative Zahl enthalten und muss
kleiner als 150 sein. Plausibilitäten: Das Geburtsjahr bei der Immatrikulation darf nicht größer sein als
„das aktuelle Jahr“ – 18 (Studierende müssen volljährig sein) Anhängigkeiten: Die Steuerklasse hängt vom
Familienstand ab, d.h., eine verheiratete Person darf nicht Steuerklasse I haben.
Ziel dieser Phase ist eine (in)formelle Beschreibung der Problemstellung und Anforderungen muss
in Form von Texten, Tabellen, Diagrammen, Formblättern etc. erstellt werden. Diese dient dann in den
folgenden Phasen zur Verständigung zwischen den Beteiligten.
Methoden des Requirementsmanagement und -engineering sind jedoch nicht Gegenstand dieser Lehrveranstaltung
und werden auch nicht im Detail behandelt. Im Rahmen dieser Lehrveranstaltung gehen wir davon
aus, dass analysierte Anforderungen bereits existieren.
3.2 Konzeptioneller Entwurf
In der zweiten Phase wird anhand der gesammelten Anforderungen eine erste formale Beschreibung der
Informationsstruktur und Spezifikation der Datenbankinhalte erstellt. Es wird ein semantisches Entwurfsmodell
entwickelt, das meist als Entity Relationship (ER) oder Enhanced Entity Relationship (EER) Modell
beschrieben wird. Entity Relationship Modelle dienen dazu, Eigenschaften Objekte (Entity) und Beziehungen
(Relationship) als Attribute zuzuordnen.
Der konzeptionelle Entwurf gliedert sich in drei Teilphasen.
• Sichtentwurf Es werden verschiedene individuelle Sichten der einzelnen Benutzer bzw. Benutzergruppen
oder Fachabteilungen modelliert.
• Sichtanalyse Die verschiedenen Sichten müssen auf eventuell auftretende Konflikte untersucht werden:
– Namenskonflikte: Es wird zwischen zwei Begriffen unterschieden. Bei Synonymen haben verschiedene
Begriffe dieselbe Bedeutung bzw. dasselbe Konzept (Bsp.: Werbung = Reklame).
Bei Homonymen wird derselbe Begriff für verschiedene Konzepte benutzt (Bsp.: Tau = Seil &
Niederschlag).
– Wertebereichskonflikte: Unterschiedliche Wertebereiche werden für gleiche Elemente verwendet
(Bsp.: Matrikelnummer wird als Zahl oder Zeichenkette festgelegt)
– Bedingungskonflikte: In verschiedenen Sichten werden unterschiedliche Integritätsbedingungen
angegeben (Bsp.: verschiedene Schlüssel für ein Element, also zur Erkennung des Studenten wird
entweder die Matrikelnummer oder der Name und das Geburtsdatum benötigt)

3.3. VERTEILUNGSENTWURF 27
– Typ- und Strukturkonflikte: Der gleiche Sachverhalte wird durch unterschiedliche Konstrukte
ausgedrückt (Bsp.: Aufteilung von „Person“ in „Mann“ und „Frau“ also auch durch „Geschlecht“
mit dem Datentyp {m;w} möglich)
• Sichtintegration Es erfolgt die Eingliederung der Sichten in ein Gesamtschema. Dabei müssen die
Konflikte, die erkannt wurden, gelöst werden, damit ein einheitliches, durchdachtes Gesamtschema
entsteht.
Es soll ein erstes konzeptionelles Datenbankmodell entstehen, das unabhängig vom später eingesetzten
Datenbankmanagementsystem (DBMS) und und produktspezifischem Datenmodell ist.
3.3 Verteilungsentwurf
In der dritten Phase wird festgelegt, auf welche Art und Weise die verteilte Speicherung erfolgt, sofern
Daten auf mehreren Rechnern verteilt vorliegen sollen. Hierbei wird zwischen horizontaler und vertikaler
Fragmentierung unterschieden.
• Eine horizontale Verteilung ist nur dann sinnvoll, wenn es möglich ist, Daten zu gruppieren. Um
das zu erreichen werden die Daten einer Tabelle auf mehrere Tabellen verteilt, wobei die Struktur der
Spalten erhalten bleibt.
• Eine vertikale Verteilung sollte eingesetzt werden, wenn Teile einer Tabelle zwar viel Speicherplatz
verbrauchen, aber nur selten abgefragt werden oder nur an einem Standort eine Abfragung der Daten
erfolgen soll. Dabei verteilt man die Daten einer Tabelle auf mehrere einzelne Tabellen, jedoch ohne
die Spaltenstruktur zu erhalten.
Das Ziel ist die Beschreibung der Verteilung von Daten und Programmen, die auf Daten zugreifen in Form
eines Verteilungsmodells.
3.4 Logischer Entwurf
Das Sprachmittel der vierten Phase ist das Datenmodell des ausgewählten Realisierungs-Datenbankmanagementsystems.
Diese Phase erfolgt in zwei Schritten.
• Transformation: Im ersten Schritt erfolgt die Abbildung vom konzeptionellen Modell ins logische
Modell des Datenbankentwurfs. Es wird also das ER- oder EER-Modell in das relationale Modell
übersetzt. Dieser Vorgang wird Transformation genannt. Werden die Transformationsregeln konsequent
angewandt, ist die Durchführung von Schritt 2 möglicherweise nicht mehr nötig.
• Normalisierung: Im zweiten Schritt wird das logische Schema verbessert. Dies erfolgt anhand von
Gütekriterien um Redundanzen zu eliminieren. Dieser Schritt wird als Normalisierung bezeichnet.
Es entsteht ein logisches Modell wie zum Beispiel eine Sammlung von Relationenschemata. Außerdem soll
eine redundante Speicherung minimiert, die Integrität optimiert und das Relationenmodell optimiert werden.

28 KAPITEL 3. PHASENMODELL DER DATENBANKENTWICKLUNG
3.5 Entwurf
In der fünften Phase wird ein internes Schema festgelegt. In diesem Schema erfolgen Angaben zu effizienten
Speicherung wozu Zugriffspfade, Speicherbedarf und die Häufigkeit von Anfragen zählen. Es müssen
Bearbeitungsanforderungen bezüglich Datenvolumen und Performance berücksichtigt werden.
Die Durchführung erfolgt durch Festlegung der Speicherungsmerkmale wie Indizes zur Beschleunigung von
Zugriffen. Es werden also verschiedene Indizes für Selektionskriterien in Suchanfragen angelegt. Dies gilt
für Attribute, auf die später vermutlich öfter zugegriffen wird.
3.6 Implementierung
In der sechsten Phase wird das zuvor erstellte interne Schema mit Hilfe der Datenbanksprache (Data
Definition Language DDL) eines konkreten Datenbankmanagementsystems angelegt und eventuell weiter
optimiert. Die Indizes der vorangegangenen Phase wie auch die Sichten werden implementiert .
3.7 Betrieb und Wartung
In der siebten und letzten Phase wird das System in Betrieb genommen und im Folgenden unterliegt es der
dauernden Wartung um Fehler zu beheben und Optimierungen und Verbesserungen durchzuführen.
Zu Beginn des letzten Arbeitsschrittes wird die Datenbank mit den benötigten Daten gefüllt und diese
werden während der gesamten Laufzeit geändert, abgefragt oder gelöscht. Anpassungen an geänderte
Rahmenbedingungen oder Änderungswünsche des Anwenders werden ebenfalls vorgenommen. Hierzu kann
es eventuell nötig sein, die Konzeption der Datenbank neu zu überdenken und die Dokumente der vorangegangenen
Phasen nochmals auf ihre Korrektheit zu überprüfen oder eine komplett neue Konzeption
vorzunehmen.

Kapitel 4
Die Drei Ebenen Architektur
In den siebziger Jahren wurden Datenbanksysteme als monolithische Systeme wie „aus einem Guss“ entwickelt.
Die Aufmerksamkeit galt vielmehr nur den Eigenschaften von Datenmodellen. Hierarchie-, Netzwerkund
Relationenmodell wurden gegenübergestellt und es entstanden regelrechte Kontroversen unter Experten,
welches Datenbankmodell optimal als Beschreibungsrahmen dienen könnte. 1975 wurde im Rahmen
einer Studie des nationalen Normierungsausschuss der USA ein Modell für den prinzipiellen Aufbau einer
Datenbankarchitektur entwickelt. Dieses Modell hat die Datenintegration und logische sowie physische Datenunabhängigkeit
als Ziel. Es unterscheidet sich damit von der bisherigen Betrachtungsweise, da es die
Vielzahl der Komponenten und ihre Beziehungen untereinander berücksichtigt. Es werden hier drei Ebenen
differenziert, wodurch sich der Name Drei-Ebenen-Architektur ergab. Das Modell ist auch unter dem Namen
ANSI/SPARC-Modell bekannt. ANSI steht hierbei für den Namen des entwickelnden Insitutes „American
National Standards Institute“, SPARC für den Namen des Ausschusses „Standards Planning And Requirements
Commitee“.
Die drei Ebenen Schemaarchitektur basiert auf drei unterschiedlichen Abstraktionsebenen und den ihnen
zugeordneten Schemata. Auf jeder der drei Ebenen können jeweils verschiedene Typen von Daten und
Schemata identifiziert werden. Insgesamt ist mit der Drei-Ebenen-Schemaarchitektur die Trennung der
logischen Datenmodelle und physischen Datenmodelle möglich. Durch die Abstraktionsebenen wird die
Datenunabhängigkeit ermöglicht.
Die drei Ebenen des ANSI/SPARC Modells gliedern sich wie folgt: Als zentraler Kern zeigt sich die konzeptionelle
Ebene, die die gemeinschaftliche Sicht beinhaltet. Individuelle Benutzersichten werden in der externen
Ebene bestimmt. Um die physische Datenorganisation geht es in der internen Ebene. Konkrete Objekte werden
durch die jeweilige Sprache ihrer Ebene bzw. Schnittstelle beschrieben. Man bezeichnet diese Beschreibung
dann als Schema. Abbildung 4.1 zeigt den allgemeinen Aufbau der Drei-Ebenen-Schemaarchitektur.
Hierbei wird vor allem in komplexen Gebilden davon ausgegangen, dass für das konzeptionelle Schema
der Unternehmens(daten)architekt, für das interne Schema der Datenbank-Entwickler und für das externe
Schema Anwendungs-Entwickler verantwortlich sind. Einzelne Komponenten des Datenbanksystems werden
also von unterschiedlichen Rollen zur Verfügung gestellt.
Durch eine einheitliche Datenbeschreibung sind typübergreifende Operationen und die Integration von Daten
aus verschiedenen Datenbeständen möglich. Anwenderprogramme verschiedenster Art und Programmierweise
sind damit durch Datentypkonvertierung kompatibel. Die Trennung der drei Ebenen verwirklicht logische
und physische Datenunabhängigkeit. Eine höhere Ebene wird nicht durch Änderungen auf der nächst tieferen
beeinflusst. Die logische Datenunabhängigkeit ergibt sich durch die Trennung der konzeptionellen von
der externen Ebene. Änderungen an der Datenbankstruktur bewirken damit keine Änderungen an der externen
Ebene. So müssen beispielsweise Anwenderprogramme nicht geändert oder neu übersetzt werden.
Physische Datenunabhängigkeit ist durch die Trennung der internen von der konzeptionellen und externen
29

30 KAPITEL 4. DIE DREI EBENEN ARCHITEKTUR
Abbildung 4.1: Drei Ebenen Architektur (ANSI/SPARC)
Ebene sichergestellt. Wird beispielsweise das Speichermedium geändert, so hat dies keinen Einfluss auf die
Datenbankstruktur und die externe Ebene. Alle drei Ebenen müssen durch die jeweiligen Schemata definiert
werden. Erst dann kann zusammen mit einem Datenbankmanagementsystem das Datenbanksystem umgesetzt
werden. Die Drei-Ebenen-Architektur soll als Orientierung für Hersteller von Datenbanksoftware und
für Betreiber von Datenbanken dienen.
4.1 Konzeptionelles Modell
Die konzeptionelle Ebene ist die logische Gesamtsicht der Datenbank. In die konzeptionelle Ebene werden
das ER-Modell und das Relationenmodell eingesetzt. Damit die physische Datenunabhängigkeit gewahrt
bleibt, muss das konzeptionelle Schema frei von Datenstruktur- oder Zugriffsaspekten sein.
Das konzeptionelle Modell enthält die systemunabhängige Datenbeschreibung. Hier werden die Daten und
ihre Beziehungen modelliert. Es enthält alle wichtigen Daten sowie auch Beschreibungen von Konsistenzbedingungen.
Hierfür kann beispielsweise das Entity-Relationship-Modell verwendet werden. Es steht dabei
nicht in direkter Beziehung zu einem konkreten Datenbanksystem und dessen Datenstruktur. Hierdurch
wird Datenunabhängigkeit gewährleistet. Seine Gestaltung hängt vielmehr vom verwendeten Datenmodell
und Datenbankentwurf ab. Die Daten werden als Entitäten verstanden, die repräsentativ für Objekte stehen.
Auch Datenbanken, die auf mehreren Rechnern abgelegt werden, besitzen nur ein konzeptionelles Schema.
Abbildung 4.2 zeigt ein ER-Modell für das durchgängige Beispiel dieser Lehrveranstaltung. Im Rahmen
der Lehrveranstaltung werden wir uns immer wieder mit einem kleinen Ausschnitt der realen Welt einer
Hochschule befassen, die für die gedachte Entwicklung eines Hochschulverwaltungssystems von Interesse
sind.

4.2. EXTERNES MODELL 31
Aus den Requirements für das Verwaltungssystem können wir entnehmen, dass die Datensätze „Studenten“,
„Lehrveranstaltungen“ und „Studiengang“ festgelegt werden müssen. Der Datensatz „Studenten“ enthält
unter anderem einen Namen, eine Anschrift, sowie eine Telefonnummer, der Datensatz „Lehrveranstaltungen“
enthält einen Titel, einen Raum, eine Zeit und eine Semesterangabe. Der Datensatz „Studiengang“
enthält eine Bezeichnung und einen Abschluss.
Die Beziehungen unter den Datensätzen verhalten sich wie folgt:
• Studenten studieren einen Studiengang und besuchen Lehrveranstaltungen.
• Ein Studiengang besteht aus Lehrveranstaltungen.
Die Eigenschaften und Beziehungen werden nun mit Hilfe des Entity-Relationship-Modells dargestellt. Ergänzt
wurden hier die Matrikelnummer der Studenten sowie eine Identifikationsnummer des Studiengangs,
hier „SGID“ genannt. Diese dienen später als Primär- und Fremdschlüssel.
Abbildung 4.2: Konzeptionelles Modell eines Sachverhalts (ER Modell)
4.2 Externes Modell
Die externe Ebene umfasst alle individuellen Sichten der einzelnen Benutzer oder Benutzergruppen auf die
Datenbank. Die Sichten werden jeweils einzeln in einem eigenen externen Schema beschrieben. Darin ist
genau der Ausschnitt der konzeptionellen Gesamtsicht enthalten, den der Benutzer sehen möchte oder darf.
Ausgehend vom konzeptionellen Schema werden die individuellen Benutzersichten entwickelt. Es wird festgelegt,
welche Daten von Benutzern und Programmen gesehen und bearbeitet werden können. Jedes Anwenderprogramm
kann sein eigenes externes Schema haben. Dieses stellt die jeweils relevanten Daten der

32 KAPITEL 4. DIE DREI EBENEN ARCHITEKTUR
Datenbank so zur Verfügung, dass das Anwenderprogramm diese verarbeiten kann. Das externe Schema
wird somit den Bedürfnissen des Anwenders bzw. des Anwendungsprogramms angepasst. Die Festlegung
eines externen Schemas bringt mit sich, dass Datentypen des Anwenderprogramms auf die des Datenbanksystems
abgebildet und damit konvertiert werden. So stellen unterschiedliche Programmiersprachen kein
Problem dar. Anwendungsprogramme und das Datenbanksystem sind kompatibel.
Da der Anwender nur die Datenobjekte einsehen kann, die in seinem externen Schema definiert sind, wird
er vor der Komplexität der Datenbank abgeschirmt. Die Handhabung wird vereinfacht. Außerdem entsteht
auf diese Weise ein Zugriffschutz, da er nicht auf alle Daten zugreifen und diese verändern kann. Die Drei-
Ebenen-Schemaarchitektur fördert und unterstützt somit eine Robustheit gegenüber Modifikationen. Daten
werden vor Manipulation und auch vor Programmierfehlern geschützt. Nutzungsrechte werden definiert.
Für unser Beispiel können zwei externe Schemata definiert werden, da wir zwei unterschiedliche Benutzergruppen
haben. So kann in einem externen Schema festgelegt werden, dass die Verwaltungsangestellten
Zugriff auf alle Daten haben. Durch ein entsprechendes Anwendungsprogramm können sie Daten aktualisieren,
löschen, neue Datensätze anlegen und Auskünfte erteilen. Das externe Schema für die Nutzung
durch die Studenten darf dagegen nicht alle Daten mit einbeziehen. Hier brauchen wir ein Schema, das eine
eingeschränkte Sicht auf die Daten definiert. Eine Passwortabfrage im Anwendungsprogramm könnte die
Daten der Studenten vor ungewollten Modifikationen schützen. So kann jeder Student nur seine eigenen
persönlichen Daten einsehen. Des Weiteren wäre vorstellbar, dass Studenten mit Hilfe des Programms eine
Übersicht über besuchte Lehrveranstaltungen erhalten können.
Abbildung 4.3: Externe Schemata für mögliche Anwendungsprogramme

4.3. INTERNES SCHEMA 33
4.3 Internes Schema
Die interne Ebene liegt dem physikalischen Speicher am nächsten, ist aber nicht mit diesem zu verwechseln.
Denn die physisch gespeicherten Daten werden nicht als Seiten oder Blöcke sondern als Datensätze betrachtet.
Im internen Schema sind Informationen über die Art und den Aufbau der verwendeten Datenstrukturen
und spezieller Zugriffsmechanismen darauf oder über die Anordnung der Sätze im (logischen) Adressraum
enthalten. Ferner wird die Lokalisierung der Daten auf den zur Verfügung stehenden Sekundärspeichermedien
geregelt.
In dieser Ebene der Drei-Ebenen-Schemaarchitektur geht es darum, datentechnische Aspekte zu bestimmen.
Das interne Modell repräsentiert diese Aspekte durch das physikalische Modell. Das interne Modell wird
aus dem konzeptionellen Modell abgeleitet.
Im konzeptionellen Modell wurden die Entitäten, ihre Beziehungen untereinander und Eigenschaften festgelegt
und durch ein Entity-Relationship-Modell dargestellt. Dieses Modell einer Datenbank als Verständigung
zwischen Anwender und Entwickler muss für die weitere Entwicklung des Datenbanksystems zunächst in
ein logisches und dann in ein physikalisches Modell übersetzt werden. Es geht darum, die Brücke von der
entwickelten Sachlogik zu den Tabellen einer Datenbank zu erschaffen.
Es findet eine Zuordnung von Datentypen, Tabellen und Feldern an die Attribute der Entitäten und Klassen
statt. Zudem werden Primär- und Fremdschlüssel festgelegt. Das relationale Datenbankmodell ist ein
Beispiel für ein logisches Datenbankmodell. Die Entitäten und Beziehungen werden hier in einem Zwischenschritt
durch Relationen dargestellt, welche sich dann in ein Tabellensystem transformieren lassen.
Die Widerspruchsfreiheit und damit die Qualität der Daten wird unter Berücksichtigung der Datenkonsistenz
und Datenintegrität sichergestellt. Identifikationsnummern dürfen zum Beispiel nicht doppelt vergeben
werden. Durch Integritätsregeln lassen sich Fehler in der Datenbank vermeiden.
Für die Definition eines internen Schemas müssen wir also zunächst das zuvor erstellte Entity-Relationship-
Modell in ein Relationenmodell umwandeln. Auf diese Art erhalten wir beispielsweise für den Datensatz
„Studenten“ folgendes Ergebnis 1 :
Studenten(Matrikelnr, Name, Straße, PLZ, Wohnort, Telefonnr,
E-Mail-Adresse, SGID → Studiengang.SGID)
Um nun die Daten in einer Datenbank speichern zu können, brauchen wir SQL-Befehle. Wir müssen also
das Relationenmodell in SQL-Befehle, auch Statements genannt, transformieren. Zur Definition eines
Datenbankschemas werden DDL-Befehle genutzt. DDL steht für Data Definition Language. Mit dem Befehl
„Create Table“ wird eine Tabelle angelegt. Der folgenden Ausdruck erstellt somit eine Tabelle mit der
Bezeichnung „Studenten“ und den gewünschten Attributen 2 :
CREATE TABLE Studenten (
MatrNr VARCHAR(16) NOT NULL,
Name VARCHAR(64),
Strasse VARCHAR(64),
PLZ VARCHAR(5),
Telefon VARCHAR(16),
EmailAdresse VARCHAR(64),
SGID INT,
PRIMARY KEY (MatrNr),
FOREIGN KEY (SGID) REFERENCES Studiengang (SGID)
1 Wie dies im Detail funktioniert, wird das Kapitel ... zeigen.
2 Mehr hierzu im Kapitel ...

34 KAPITEL 4. DIE DREI EBENEN ARCHITEKTUR
);
Auf diese Art und Weise erstellt man nun alle weiteren Tabellen mit den entsprechenden Attributen um die
physikalischen Datenstrukturen innerhalb der Datenbank anzulegen.

Teil II
Datenmodellierung
35

Kapitel 5
Einleitung
Teil II des Skripts wurde von den Studenten und Studentinnen Janina Britze, Wladimir Daibert,
Robert Dabrowski, Katharina Schrader, Stefanie Gramm, Anna-Karina Drews,
Christina Heiden, Dan Röndigs, Eduard Schmalz und Thomas Plenius im Rahmen der
Lehrveranstaltung Datenbank-gestützte Server-seitige Programmierung im Wintersemester 2010
an der Fachhochschule Lübeck verfasst. Ihnen gilt besonderer Dank.
In diesem Teil werden wir auf die Datenmodellierung eingehen. Es werden insbesondere die Datenmodelle des
Relationenmodells und des Entitity Relationship Modells erläutert und durch Beispiele erklärt. Die beiden
Modelle werden in der Vorlesung ausführlich behandelt. Als erstes wird ein allgemeiner Überblick über die
Datenmodellierung gegeben. Hierbei gehen wir auf die hierarchischen Modelle und auf die Netzwerkmodelle
ein. In diesem Kapitel findet außerdem ein Vergleich zwischen Relationenmodell und Entity Relationship
Modell statt. Danach gehen wir auf das Relationenmodell ein. Wir zeigen kurz die Geschichte auf, geben
eine Definition und zeigen die wichtigsten Bestandteile anhand eines Beispiels. Danach erklären wir die
Schlüsselattribute und zeigen die Beziehungen zu Tabellen. Weiterhin gehen wir auf die Operationen und
mathematischen Grundlagen ein. Zum Schluss geben wir Beispiele für SQL Befehle. Das nächste Kapitel
beschäftigt sich mit dem Entity Relationship Modell, auch hier gehen wir auf die Geschichte ein und geben
eine allgemeine Definition. Wir erläutern was Entitäten und Attribute sind und erklären die unterschiedlichen
Beziehungen untereinander. Danach stellen wir die einzelnen Nationen dar und verdeutlichen das Modell
anhand eines Beispiels.
Eine Datenbank kann als eine elektronische Form eines Karteikastens bezeichnet werden, welche als Gesamtheit
aller gespeicherten Daten, die für eine rechner-gestützte Bearbeitung fachlicher Informationen
erforderlich sind, bezeichnet wird. Zusammen mit dem Datenbankverwaltungssystem bildet sie ein Datenbanksystem.
Ein Datenbankverwaltungssystem sind Programmsysteme zur Speicherung, Bereit-stellung,
Pflege und Sicherung von großen Datenbeständen bzw. Datenbanken. Aufgrund dessen sind Datenbanksysteme
in der heutigen Zeit die Stütze jedes größeren Softwaresystems. Ein Datenbanksystem hat im
wesentlichen zwei Vorteile gegenüber einem Dateiver-waltungssystem: Auf der einen Seite wird die erhöhte
Sicherheit der Daten vor Zerstörung, Verfälschung und Missbrauch und auf der anderen Seite die Möglichkeit
der redundanzfreien Datenspeicherung sowie die einfachere Austauschbarkeit von Programmen und
Dateien garantiert. Die Datenmodellierung wird bei der Entstehung und dem Entwurf von Informationssystemen
verwendet, wenn es um die Identifikation und Beschreibung der relevanten Informationsobjekte
und ihrer Beziehungen geht. Unter Datenmodellierung versteht man dabei die formale Abbildung der Informationsobjekte
mittels ihrer Attribute und Beziehungen. Jede Datenbank kann nach der Art Beziehungen
der einzelnen Datengruppen einem Datenbankmodell zugeordnet werden. Ein Datenbankmodell ist dabei die
theoretische Grundlage für ein Datenbanksystem und bestimmt, auf welche Art und Weise Daten prinzipiell
gespeichert und wie sie manipuliert werden. Historisch bedeutsam waren insbesondere das hierarchische
37

38 KAPITEL 5. EINLEITUNG
Datenmodell sowie das NetzwerkDatenmodell. Beide sind jedoch durch den heute de-facto Standard des
relationalen Datenmodells im wesentlichen verdrängt worden.
5.1 Hierarchisches Datenmodell
Das hierarchische Datenbankmodell ist das älteste Datenbankmodell. Dieses bildet die Realwelt durch eine
hierarchische Baumstruktur ab und speichert die Daten, die in einer 1:1-oder 1:n-Beziehung zueinander stehen.
Das Modell ging aus den Informationsmanagementsystemen in den 1950er und 1960er Jahren hervor
und wurden von vielen Banken und Versicherungsunternehmen eingesetzt, wo sie zum Teil noch heute zu finden
sind. Eine solche Struktur lässt sich leicht modellieren und bietet effiziente Such-und Einfüge- Strategien
für einzelne Themen. Verknüpfungen zwischen den Datensatzabbildern werden als Eltern-Kind-Beziehungen
realisiert. Das hierarchische Modell baut auf Datensätzen (Record-Typen) auf, die zu Satz-klassen zusammengefasst
werden. Die Satzexemplare einer Klasse haben gleich benannte Felder mit jeweils gleichen Datentypen.
Zwischen den Satzklassen können hierarchische Beziehungen bestehen. Ein Record-Typ entspricht
einem Knoten, während die 1:n-Beziehungen zwischen den Record- Typen den Kanten entsprechen.
Die übergeordnete Klasse ist die Elternklasse ("Mutter" im nachfolgenden Beispiel), während die untergeordnete
Klasse Kinderklasse ("Tochter" bzw. "Sohn" im nach-folgenden Beispiel) genannt wird.
Ein Satz aus der Elternklasse kann mit mehreren Sätzen aus der Kinderklasse in Beziehung stehen, wobei
diese Beziehung nicht benannt werden kann. Das Datenbankschema besteht daher aus einer oder mehreren
Hierarchien von Satzklassen. Die Hierarchien werden immer von oben nach unten dargestellt, somit sind die
Eltern- und die Kinderrolle von Satzklassen direkt erkennbar.
Abbildung 5.1: Beispiel hierarchisches Datenmodell
Eine Mutter kann beliebig viele Kinder haben. Jedes Kind kann wiederum eigene Kinder haben. Die Tatsache,
dass ein Kind auch einen Vater hat, lässt sich jedoch in der gleichen Hierarchie nicht darstellen.
Der Nachteil von hierarchischen Datenbanken ist es, dass sie nur mit einem Baum umgehen können. Verknüpfungen
zwischen verschiedenen Bäumen oder über mehrere Ebenen innerhalb eines Baumes sind nicht
möglich. Komplexe Strukturen sind also nicht modellierbar und somit ist der Einsatz für raumbezogene
Daten nicht besonders sinnvoll. Das hierarchische Modell ist heute weitgehend von dem relationalen Datenmodell
abgelöst worden.
5.2 Netzwerk-Datenmodell
Das Netzwerk-Datenbankmodell hat sich aus dem hierarchischen Datenbankmodell entwickelt und wurde
1971 von dem Normungsausschuss CODASYL/ DBTG (Conference on Data Systems Languages & Data
Base Task Group) festgelegt. Beim Netzwerkmodell kann jeder Entitätstyp mehrere Nachfolger und – im
Gegensatz zum hierarchischen Modell – auch mehrere Vorgänger besitzen. Es erlaubt die Modellierung von
hierarchischen und netzartigen Strukturen, d.h. es sind 1:1-, 1:n-und m:n-Beziehungen zugelassen. Zwischen

5.3. ENTITY-RELATIONSHIP MODELL UND RELATIONENMODELL 39
zwei Satzklassen kann es mehrere 1:n-Beziehungen geben. Da die Beziehungstypen (auch "Set" genannt)
im Netzwerkmodell benannt werden, ist es möglich, zwischen zwei Satzklassen auch mehrere Beziehungen
anzugeben.
Abbildung 5.2: Beispiel eines Netzwerk-Datenmodells
Seine Vorteile sind die platzsparende Speicherung komplexer Strukturen und der schnelle Zugriff darauf.
Dem steht als wesentlicher Nachteil die Schwerfälligkeit bei der Anpassung an geänderte Bedingungen
gegenüber. Dieses Modell ist für Anwendungen geeignet, die vorhersehbar und weitgehend stabil sind, weil
die Einführung neuer Datenelemente und neuer Zugriffspfade im Allgemeinen eine Neuorganisation der
gesamten Datenbank bedeutet. Seit den 1990er Jahren wird es vom relationalen Datenbankmodell mehr
und mehr verdrängt.
5.3 Entity-Relationship Modell und Relationenmodell
Relationenmodell und semantische Modellierungsansätze wie das Entity-Relationship-Modell haben heutzutage
weitgehend hierarchische und Netzwerk-Datenmodelle verdrängt.
Das Entity-Relationship-Modell beinhaltet eine graphische Methode der Datenmodellierung, die Ausschnitte
aus der realen Welt (Unternehmensrealität) darstellen und beschreiben. Im Gegensatz zum Entity-
Relationship-Modell (oder Gegenstands-Beziehungs-Modell), das ein konzeptuelles Modell darstellt, handelt
es sich beim Relationenmodell, um ein logisches Datenmodell, welches dazu dient Datenstrukturen einer
Klasse von Datenbanken (den sogenannten relationalen Datenbanken) zu erfassen und zu beschreiben. Dieses
Modell liegt in gewisser Hinsicht eine Stufe „tiefer“ als das Entity-Relationship Modell. Es werden hier
keine abstrakten Gegenstände oder Gegenstandstypen mehr betrachtet, sondern nur noch deren Umsetzung
in relationale Datenstrukturen. Das Ziel der logischen Datenmodellierung ist das Anordnen der zu speichernden
Informationen mit Hilfe eines Modells, das eine möglichst redundanzfreie Speicherung unterstützt
und geeignete Operationen für die Datenmanipulation und -abfrage zur Verfügung stellt.
Mit dem Entity-Relationship-Modell kann die grundlegende Objekt- und Beziehungsstruktur eines Sachverhalts
der realen Welt für eine Datenbank strukturiert analysiert und visualisiert werden. Das Entity-
Relationship-Modell kann ferner in das relationale Datenmodell mittels sogenannter Transformationsregelen
strukturiert überführt werden.

40 KAPITEL 5. EINLEITUNG

Kapitel 6
Das Entity-Relationship Modell
Das ER-Modell ist ein abstraktes Modell, in dem Datenbestände durch abstrakte Datensätze (Entities),
beliebige Beziehungen (Relationships) und Attribute modelliert werden. Dieses Modell wird hauptsächlich
für den Entwurf von Datenbanken eingesetzt. Der Begriff des Entity-Relationship-Modells geht zurück auf
einen grundlegenden Artikel von P.P. Chen im Jahre 1976. Seit dieser Zeit hat sich dieses Datenmodell
fest im Bereich der Datenbankmodelle etabliert und wird - in abgewandelter Form- heutzutage faktisch als
Standardmodell für frühe Entwurfsphasen der Datenbankentwicklung eingesetzt. Das ER-Modell basiert auf
den drei Grundkonzepten Entity als zu modellierende Informationseinheit, Relationship zu Modellierung von
Beziehungen zwischen Entitys und Attribut als Eigenschaft von einem Entity oder einer Beziehung.
Abbildung 6.1: Modellierungsobjekte in ER-Modellen
Das Entity Relationship Modell ist das bekannteste und einfachste semantische Datenmodell für die konzeptionelle
Modellierung im Rahmen einer Datenbankentwicklung. Es dient dazu, Sachverhalte der realen
Welt mittels eines formalen Modells abzubilden. In diesem Modell werden die relevanten Sachverhalte eines
Weltausschnitts modelliert und diese in Relation zueinander gesetzt. Die Modellierung erfolgt ohne
Berücksichtigung technischer Aspekte, wie sie zum Beispiel bei der Speicherung von Daten in einer Datenbank
zu beachten sind. Das ERM wird in der Phase des konzeptionellen Entwurfes in einer Datenbank
eingesetzt. Die semantische Modellbildung ist Standard in der konzeptionellen Modellbildungsphase der
Datenbandkentwicklung. Es ist unabhängig von einem bestimmten Datenbanksystem und dient der Analyse
und dem Design von Datenstrukturen. Es unterscheidet sich zum Relationenmodell durch die semantische
Modellierung, d.h. die formale Erfassung eines Ausschnitts der realen Welt mittels eines Modells. Das relationale
Datenmodell hingegen ist die geeignete Modellierungssprache, wenn man sich auf die Nutzung eines
sogenannten relationalen Datenbanksystems festlegt.
ER-Modell und Relationenmodell sind mittels Transformationsregeln systematische in einander überführbar.
Dies wird im Teil III behandelt.
41

42 KAPITEL 6. DAS ENTITY-RELATIONSHIP MODELL
6.1 Entitäten (Objekte)
Entitäten sind Objekte, die in der abzubildenden Realität zu beobachten und eindeutig identifizierbar sind.
Es sind Objekte der realen oder der Vorstellungswelt, über die Informationen zu speichern sind. Auch Informationen
über Ereignisse wie Bestellungen oder Prüfungen können Objekte im Sinne des ER-Modells sein.
Es sind unterschiedliche Darstellungsformen in Gebrauch. Für den Entitätstyp wird meistens ein Rechteck
verwendet (vgl. Abbildung 6.2), wobei der Name des Typs in das Rechteck eingetragen wird.
Eine Entity ist ein physisches oder logisches Objekt der realen Welt. Eine Entity kann bspw. ein Buch, eine
Person (beides physische Entities) oder etwa eine Lehrveranstaltung (logische Entity) sein.
Es sind unterschiedliche Darstellungsformen in Gebrauch. Für den Entitätstyp wird meistens ein Rechteck
verwendet (vgl. Abbildung 6.2).
6.2 Relationen
Abbildung 6.2: ERM Diagramm Elemente
Entitäten können miteinander in Beziehung stehen. Dies wird durch eine Raute gekennzeichnet. Beziehungen
können nur existieren, wenn Entitäten existieren. Relationen bezeichnen Beziehungen zwischen Entitäten.
Das ER-Modell sieht drei Arten von Kardinalitäten prinzipiell vor.
• 1:1 Kardinalitäten von Relationen bilden den Sachverhalt ab, dass eine Entität nur genau eine Beziehungen
mit einer anderen Entität eingehen kann (bspw. die monogame Ehe-Relation)
• 1:n (bzw. n:1) Kardinalitöten von Relationen bilden den Sachverhalt ab, dass eine Entität in eine
Richtung genau eine Beziehung mit einer anderen Entität eingehen kann, in der anderen Richtung
können aber beliebig viele Beziehungen eingegangen werden (bspw. die polygame Ehe-Relation wie sie
bei den Mormonen praktiziert wird, ein Ehemann kann mehrere Ehefrauen haben, aber eine Ehefrau
nur einen Ehemann)
• m:n Kardinalitäten von Relationen schränken die Möglichkeit der Beziehungen nicht ein. In beide
Richtungen können beliebig viele Beziehungen eingegangen werden (in unserem Ehe-Beispiel wäre
das so etwas wie eine “wilde Ehe-Relation”).
Es sind unterschiedliche Darstellungsformen in Gebrauch. Für den Relationen wird meistens eine Raute
verwendet (vgl. Abbildung 6.2 und 6.1 sowie 6.4). Die Kardinalitäten werden an die Kanten links und rechts
einer Relation geschrieben. Bei 1:n (n:1) Relationen hat sich ferner die sogeannte Pfeilnotation etabliert,
hier wird an der Stelle an der die 1 notiert wird, ein Pfeil in Richtung auf die Entität gesetzt. Werden
keine Kardinalitäten an den Kanten angeben, so bedeutet dies den allgemeinsten Fall einer m:n Relation
(sie können jedoch auch die Kardinalitäten an die Kanten schreiben).

6.3. ATTRIBUTE 43
6.3 Attribute
(a) m:n Relation (b) 1:n Relation (c) 1:1 Relation
Abbildung 6.3: Kardinalitäten von Relationen
(a) m:n ER Relation (b) 1:n ER Relation
(c) 1:n ER Relation (Pfeilnotation) (d) 1:1 ER Relation
Abbildung 6.4: Kardinalitäten in ER-Modellen
Des Weiteren können Entities und Relationen mittels Attributen beschrieben werden. Attribute können
ferner als Schlüsselattribute oder als optional ausgezeichnet werden. Schlüsselattribute sollten für eine
Entität eindeutig sein und pro Entitätsvorkommen nur einmal eindeutig existieren. Optionale Attribute
können für Relationen oder Entitäten angegeben werden, müssen aber nicht. So hat ein Buch zum Beispiel
die Attribute Erscheinungsdatum, Verlag, Titel oder Auflage.
Es sind unterschiedliche Darstellungsformen in Gebrauch. Für Attribute wird meistens eine Oval verwendet
(vgl. Abbildungen 6.2 und 6.1) welches mit einer Verbindungslinie an die zugehörige Entität oder Relation
gebunden wird.
Sollen Attribute als Schlüsselattribute ausgezeichnet werden, so hat es sich durchgesetzt, dies durch einen
ausgefüllten Kreis an der Verbindungslinie zwischen Attribut und Entität/Relation zu kennzeichnen. Optionale
Attribute werden durch einen nicht ausgefüllten Kreis an der Verbindungslinie gekennzeichnet (vgl.
Abbildung 6.5).

44 KAPITEL 6. DAS ENTITY-RELATIONSHIP MODELL
(a) Schlüsselattribute (b) Optionale Attribute
Abbildung 6.5: Kennzeichnung von Schlüsselattributen und optionale Attribute
6.4 Exemplarische Veranschlaulichung des ER-Modells an einem
durchgehenden Beispiel
Das durchgehende Beispiel wird im Rahmen der Lehrveranstaltung im Detail beschrieben. Hier ist es noch
auszuarbeiten.
[TBD]

Kapitel 7
Das Relationale Datenmodell
Das bekannteste Datenmodell ist das relationale Datenmodell. Die Prinzipien hinter dem Relationalen Datenmodell
sind dabei der Kern einer jeden relationalen Datenbank. Relationale Datenbanken sind vermutlich
der am meisten verwendete Datenbanktyp und werden in vielfältigen (betrieblichen) Anwendungssystemen
eingesetzt. Beispielsweise folgen die folgenden (kommerziellen) Produkte den Prinzipien des relationalen
Datenmodells:
• Oracle Sybase
• Microsoft (Access, SQL Server)
• Postgres (Freeware)
• IBM (DB2, Informix)
• MySQL (Freeware)
Die Grundlagen der Theorie der relationalen Datenbank wurden von Edgar F. Codd in den 1960ern und
1970ern gelegt. Eine darauf basierende Datenbank dient zur elektronischen Datenverwaltung in Computersystemen
und beruht auf dem relationalen Datenbankmodell. Die Umsetzung von der Theorie in die Praxis
wurde durch System/R (IBM) und Ingres um 1975 vollzogen. Es ist bis heute trotz einiger Kritikpunkte ein
etablierter Standard für Datenbanken.
Das zugehörige Datenbankmanagementsystem wird als relationales Datenbankmanagementsystem oder
RDBMS (Relational Database Management System) bezeichnet. Zum Abfragen und Manipulieren der Daten
wird überwiegend die Datenbanksprache SQL (Structured Query Language) eingesetzt.
Grundlage des Konzeptes relationaler Datenbanken ist die Relation. Sie stellt eine mathematische Beschreibung
einer Tabelle dar, die der Mengenalgebra ähnlich ist. Operationen auf diesen Relationen werden durch
die relationale Algebra bestimmt. Die relationale Algebra ist somit die theoretische Grundlage von SQL.
Trotz der mathematischen, abstrakten Definition des Datenbankmodells sind relationale Datenbanken vergleichsweise
einfach und flexibel zu handhaben.
Das Relationenmodell bietet die wenigsten Modellierungskonstrukte. Es gibt kein explizites Konstrukt, um
Beziehungen zwischen Relationen zu modellieren, diese werden über die Werte der Attribute dargestellt.
45

46 KAPITEL 7. DAS RELATIONALE DATENMODELL
7.1 Tabellenanalogie
Eine relationale Datenbank kann man sich als eine Sammlung von Tabellen (den Relationen) vorstellen,
in welchen Datensätze abgespeichert sind. Jede Zeile (Tupel) in einer Tabelle ist ein Datensatz. Jedes
Tupel besteht aus einer Reihe von Attributwerten (Attribute = Eigenschaften), den Spalten der Tabelle.
Das Relationenschema legt dabei die Anzahl und den Typ der Attribute für eine Relation fest. Das Bild
illustriert die Relation Studenten mit Attributen MatNr (Matrikelnummer), Vorname, Nachname, LVID
(Lehrveranstaltungs-ID) in den Spalten.
Abbildung 7.1: Begriffserklärung Relationenmodell
Zum Beispiel wird ein Student in einer Fachhochschule durch den Datensatz (MatNr, Vorname, Nachname,
LVID) beschrieben. Ein Datensatz muss über einen oder mehrere Schlüssel eindeutig identifizierbar sein. In
diesem Fall enthält MatNr die Schlüssel. Ein Schlüssel darf sich niemals ändern. Er bezieht sich auf den
Datensatz und nicht auf die Position in der Tabelle.
Abbildung 7.2: Primärschlüssel
Weiterhin können Verknüpfungen genutzt werden, um die Beziehungen zwischen Tabellen auszudrücken.
Eine Studentendatenbank könnte mit Primär- und Fremdschlüsseln damit etwa wie in Abbildung [] gezeigt
implementiert werden:
• Domäne: Eine Domäne besteht aus einem Namen D und einer Menge atomarer Werte. Ein anderer
Name für Domäne ist Wertebereich. Domänen definierenden Wertebereich von Attributen.
• Tupel: Ein Tupel ist eine endliche Liste, in der, wenn sie nicht leer ist, hintereinander Angaben nicht
not-wendig voneinander verschiedener mathematischer Objekte stehen.Er ist also eine Liste mit n
Werten t = , wobei jeder Wert di ein Element der Domäne Di, oder NULL sein
muss.
• Attribut: Ein Attribut A bezeichnet die Funktion, die eine Domäne D in einem Relationenschema R
ausübt. Es kann auch als Abbildung der Tupel einer Relation auf den Wert des jeweiligen Tupels (für

7.2. SCHLÜSSELATTRIBUTE 47
Abbildung 7.3: Fremdschlüssel
dieses Attribut) verstanden werden, wobei jeder Wert di ein Element der Domäne oder NULL sein
muss.
• Relationenschema: Ein Relationenschema R, Schreibweise: R(A1, A2, ..., An), bezeichnet eine Menge
von Attributen {A1, A2, ..., An}.
• Relation: Eine Relation r ist eine Instanz (Ausprägung) des Relationenschemas R(A1, A2, ..., An).
Sie ist eine Teilmenge des kartesischen Produkts (Kreuzprodukt) der beteiligten Domänen.
• Relationales Datenbankschema: Ein relationales Datenbankschema ist eine Menge von Relationenschemata
S = {R1, ..., Rn} zusammen mit einer Menge von Integritätsbedingungen. Eine relationale
Datenbankinstanz ist die Menge {r1, ..., rn}, wobei ri Instanz von Ri ist und alle Integritätsbedingungen
erfüllt sind. Eine relationale Datenbank ist ein relationales Datenbankschema mit einer
entsprechenden Datenbankinstanz.
7.2 Schlüsselattribute
Eine wichtige Eigenschaft einer Datenbanktabelle ist Eindeutigkeit, d.h.dasskeineZeilemehrfach
vorkommt, sich also nicht wiederholt. Ist die Tabelle frei von Wiederholungen, so werden die Zeilen durch
die Werte von mindestens einer Spalte und von höchstens allen Spalten der Tabelle eindeutig. Spalten,
die alleine für die Eindeutigkeit der ganzen Zeile sorgen, die Zeile also identifizieren, nennt man Schlüssel.
Grundsätzlich können in einer Tabelle unterschiedliche Spalten bzw. Spaltenkombi-nationen als Kandidaten
zur Identifizierung der Zeilen herangezogen werden. Diejenige Spalte oder Spaltenkombination, die konkret
zur Identifizierung herangezogen wird, heißt Primärschlüssel.
Ein Primärschlüssel ist demnach also eine Spalte (oder eine Spaltengruppe) in einer Tabelle. Er ist alleine
hinreichend dafür, dass alle Zeilen eindeutig sind. Es gibt also keine zwei gleichen Schlüsselwerte
in einer Tabelle mit Primärschlüssel-spalte(n). Wird ein Schlüssel von mehr als einer Spalte repräsentiert,
so spricht man auch von einem Kombinations- oder Verbundschlüssel. Jede Tabelle kann höchstens einen
Primärschlüssel haben. (Eine weitere übliche Bezeichnung für Primärschlüssel ist Identifikationsschlüssel.)
Beispiele für Primärschlüssel sind die Spalte Matrikelnummer in der Tabelle Studenten und LVID in Kurse.

48 KAPITEL 7. DAS RELATIONALE DATENMODELL
Sekundärschlüssel sind Spalten, über deren Werte Zeilengruppen eindeutig gekennzeichnet sind. Alle Zeilen
einer Gruppe enthalten also gleiche Sekundär-schlüsselwerte. Eine Tabelle kann mehrere Sekundärschlüsselspalten
haben. Beispiel: die Spalte LVID in der Tabelle Studenten.
Fremdschlüssel dienen dagegen nicht der Identifikation von Zeilen und Zeilengruppen, sondern sind Zeiger
oder Verweise auf Schlüssel in anderen Tabellen. In unserem Beispiel ist LVID in Kurse ein Primärschlüssel,
und LVID in Studenten verweist als Fremdschlüssel auf die entsprechenden Zeilen in der Tabelle Kurse.
Abbildung 7.4: Schlüsselattribute
Join-Operationen erfolgen meist über die Verknüpfung von Primär- und Fremdschlüsseln und gehören zu
den sogenannten relationalen Operatoren. Zu diesen kommen wir im folgenden.
7.3 Relationale Operationen
Die Relationale Algebra ist ein algebraisches Modell, das beschreibt, wie Daten gespeichert, abgefragt
und manipuliert werden können. Die wesentlichen Operationen, aus denen alle weiteren abgeleitet werden
können, sind die folgenden:
• Projektion
• Selektion
• Kreuzprodukt oder Kartesisches Produkt
• Umbenennung
• Vereinigung
• Differenz
Alle Anfragen, die mittels SQL an eine relationale Datenbank gestellt werden, werden vom Datenbankmanagementsystem
auf diese Operatoren abgebildet, das heißt übersetzt. In der Praxis gibt es weitere Operatoren,
wie zum Beispiel den Join-Operator (Verbundoperator), was die beiden hintereinander ausgeführten Operationen
kartesisches Produkt und Selektion bezeichnet.

7.3. RELATIONALE OPERATIONEN 49
7.3.1 Projektion
Durch Projektion einer Tabelle wird aus den vorhandenen Spalten ausgewählt. Das Resultat ist wiederum
eine Tabelle, die im Allgemeinen weniger Spalten als die ursprüngliche hat.
Im folgenden Beispiel (vgl. Abbildung 7.5) wird so aus der Tabelle Studenten mit den drei Spalten nachname,
vorname und matr. Nr. durch Projektion eine Tabelle mit den beiden Spalten nachname und matr. Nr.
erzeugt.
Abbildung 7.5: Projektion
In der Datenbanksprache SQL erfolgt die Projektions-Operation mittels des SELECT Schlüsselworts. SE-
LECT leitet in SQL aber außerdem eine ganze Klasse von Ausdrücken ein, die alle eine Auswahl in einer oder
mehreren verknüpften Tabellen bewirken (Query oder Abfrage), ist also sowohl das Schlüsselwort für Abfragen
als auch der Name des Projektionsoperators. Die SQL-Anweisung für die im Bild gezeigte Projektion
ist:
SELECT nachname, matrNr
FROM Studenten
Wähle die Spalten nachname und matr. Nr. aus der Tabelle Personen.
Die Projektion ist also die Auswahl bestimmter Attribute einer Relation, das heißt, die Projektion blendet
Attribute (Spalten) aus (vgl. Abbildung 7.6).
Abbildung 7.6: Projektion (allgemein)
Mathematisch lässt sich dies in der Relationenalgebra wie folgt ausdrücken:
Sei R eine Relation über {A1,...,Ak} und β ⊆{A1,...,Ak} dann ist die Projektion von β auf R wie folgt
definiert:
Πβ := {tβ|t ∈ R}
tβ bezeichnet dabei die Teilmenge eines Tupels mit der in β festgelegten Attributliste. Nicht in β auftauchende
Attribute werden durch die Projektionsoperation der relationalen Alegbra also ausgeblendet.

50 KAPITEL 7. DAS RELATIONALE DATENMODELL
7.3.2 Selektion
Selektion in einer Tabelle bewirkt die Auswahl von Zeilen. Das Resultat ist wiederum eine Tabelle, die
höchstens gleich viele, in der Regel aber weniger Zeilen hat als die ursprüngliche. In der Datenbanksprache
SQL erfolgt die Selektions-Operation mittels des WHERE Schlüsselworts.
Im Beispiel wird so aus der vierzeiligen Tabelle Studenten durch Selektion eine Tabelle mit nur zwei Zeilen
(vgl. Abbildung 7.7).
Die dem Bild entsprechende SQL-Anweisung lautet:
SELECT *
FROM Studenten
WHERE nachname LIKE ’S%’
(Nachname fängt mit S an)
Die Tabelle Studenten wird mit
SELECT * FROM Studenten
Abbildung 7.7: Selektion
also erst auf sich selbst projiziert, und aus dieser Tabelle werden dann mittels WHERE diejenigen Zeilen
selektiert, in denen jeweils der entsprechende Wert in der Spalte nachname mit dem Buchstaben S beginnt
(LIKE ’S%’) 1
Die Selektion kann also als eine Art Filter angesehen werden, denn es werden aus einer gegebenen Relation
alle Tupel herausgesucht, welche der vorgegebenen Bedingung genügen. Das heißt, es werden Tupel
(Zeilen) ausgeblendet. Man schreibt σAusdruck(R) oder in der linearen Schreibweise R[Ausdruck]. Ausdruck
beinhaltet die logische Selektionsbedingung. Mathematisch ist dies in der Relationenalgebra wie folgt
definiert:
σ := {t|t ∈ R ∧ terfüllt Bedingung}
Die Bedingung bezeichnet dabei eine Formel. Diese kann bestehen aus:
wird.
• Konstantenselektionen AttributθKonstante um Attributwerte mit Konstanten zu vergleichen. θ ist
dabei ein üblicher Vergleichsoperator =, ≤,
• Attributselektionen AttributθAttribut um Attributwerte mit anderen Attributwerten einer Relation
zu vergleichen
• Verknüpfungen von Selektionsausdrücken der obigen Art mit logischen Prädikaten UND, ODER,
NICHT (∧, ∨, ¬) um komplexe logische Bedingungen formulieren zu können
1 Man beachte, dass in SQL-Strings als Joker das Prozentzeichen % und nicht der sonst üblichere Asteriskus * verwendet

7.3. RELATIONALE OPERATIONEN 51
7.3.3 Kartesisches Produkt und JOINS
Das Resultat des Kartesischen Produkts ist die Menge aller Kombinationen der Tupel aus R und S, d.h.
jede Zeile der einen Tabelle wird mit jeder Zeile der anderen Tabelle kombiniert. Wenn alle Merkmale
(Spalten) verschieden sind, so umfasst die Resultatstabelle die Summe der Merkmale der Ausgangstabellen.
Die Anzahl der Tupel (Zeilen) in der Resultatstabelle ist das Ergebnis der Multiplikation der Zeilenanzahlen
der Ausgangstabellen (vgl. Abbildung 7.8).
Abbildung 7.8: Kartesisches Produkt
Mathematisch lässt sich dies in der Relationenalgebra wie folgt ausdrücken:
Es seien zwei beliebige Relationen R =(a1,a2,...,an) und S =(b1,b2,...,bm) gegeben. Dann ist das
karteische Produkt zweier Relationen wie folgt definiert:
R × S := {(a1,...,an,b1,...,bm)|(a1,...,an) ∈ R ∧ (b1,...,bm) ∈ S}
Wie sich sogenannte JOINS mittels kartesischem Produkt und Selektion ausdrücken lassen, wird in Abschnitt
7.4 erläutert.
7.3.4 Umbenennung
Durch diese Operation können Attribute und Relationen umbenannt werden. Diese Operation ist wichtig,
um kartesische Produkte über Relationen zu ermöglichen, in denen es gleiche Attributnamen gibt, insbesondere
auch mit der gleichen Relation, und Mengenoperationen zwischen Relationen mit unterschiedlichen
Attributen zu ermöglichen.
Abbildung 7.9: Umbenennung
Hierzu wird in der Relationenalgebra die Umbennungs-Operation wie folgt geschrieben:

52 KAPITEL 7. DAS RELATIONALE DATENMODELL
• ρS(R) und bedeutet, dass die Relation R in S umbenannt wird.
• ρ (B1,...Bn)(R) und bedeutet, dass die Attribute von R in B1,...,Bn umbenannnt werden.
• Sollen nur einzelne Attribute umbenannt werden, so kann dies auch wie folgt notiert werden: ρ (neu←alt)(R)
und bedeutet, dass das Attribut alt der Relation R in neu umbenannt wird. Innerhalb der Klammer
können mehrere Umbenennung vorgenommen werden.
• Relations- und Attributumbenennung geht auch in kombinierter Form. ρ S(B1,B2,...,Bn)(R) bedeutet,
dass die Relation R in S umbenannt und deren Attribute in B1,B2,...Bn wird.
Auf die genaue mathematische Definition verzichten wir an dieser Stelle, da diese für den einfachen Sachverhalt
unangemessen komplex ist, und dadurch dem Verständnis kaum förderlich ist.
7.3.5 Vereinigung
Die Vereinigung zweier Relationen A und B ergibt die Vereinigung beider Relationen, die diejenigen Zeilen
der beiden Tabellen enthält, die zumindest in einer der beiden enthalten sind (vgl. Abbildung 7.10).
Nachname Vorname Geburtsdatum
Mike Lise 03.06.1985
Huber Karl 16.12.1980
Trunstein Helga 30.07.1986
A ∪ B
Nachname Vorname Geburtsdatum
Kelz Andreas 21.07.1965
Huber Karl 16.12.1980
Ernsbach Elli 29.06.1956
(a) Studenten
(b) Dozenten
Nachname Vorname Geburtsdatum
Mike Lise 03.06.1985
Huber Karl 16.12.1980
Trunstein Helga 30.07.1986
Kelz Andreas 21.07.1965
Ernsbach Elli 29.06.1956
(c) Studenten ∪ Dozenten
Abbildung 7.10: Beispiel einer Vereinigung
In der Datenbanksprache SQL erfolgt die Vereinigungs-Operation mittels des UNION Schlüsselworts. Ein
typischer SQL Ausdruck um die Relationen Studenten und Dozenten gem. Abbildung 7.10 mit einander zu
vereinigen sähe wie folgt aus:
SELECT * FROM Studenten
UNION
SELECT * FROM Dozenten
Bei der Vereinigung R∪S werden alle Tupel der Relation R mit allen Tupeln der Relation S zu einer einzigen
Relation vereint. Voraussetzung dafür ist, dass R und S das gleiche Relationenschema haben (weicht es nur
in Reihenfolge und Attributbenennung um, kann dieses mittels der Projektions- und Umbenennungsoperation
angeglichen werden). Das heißt, sie haben gleiche Attribute und Attributtypen. Duplikate werden bei
der Vereinigung gelöscht.
Mathematisch ist die Vereinigungsoperation in der Relationenalgebra wie folgt definiert:
R ∪ S := {t|t ∈ R ∨ t ∈ S}

7.3. RELATIONALE OPERATIONEN 53
7.3.6 Schnittmengenbildung
Die Schnittmenge zweier Relationen A und B ergibt die Schnittmenge beider Relationen, die diejenigen
Zeilen der beiden Tabellen enthält, die in beiden enthalten sind (vgl. Abbildung 7.11).
Nachname Vorname Geburtsdatum
Mike Lise 03.06.1985
Huber Karl 16.12.1980
Trunstein Helga 30.07.1986
A ∩ B
Nachname Vorname Geburtsdatum
Kelz Andreas 21.07.1965
Huber Karl 16.12.1980
Ernsbach Elli 29.06.1956
(a) Studenten
(b) Dozenten
Nachname Vorname Geburtsdatum
Huber Karl 16.12.1980
(c) Studenten ∩ Dozenten
Abbildung 7.11: Beispiel einer Schnittmenge
In der Datenbanksprache SQL erfolgt die Schnittmengen-Operation mittels des INTERSECT Schlüsselworts.
Ein typischer SQL Ausdruck um die Schnittmenge zwischen Studenten und Dozenten gem. Abbildung 7.11
zu bestimmen, sähe wie folgt aus:
SELECT * FROM Studenten
INTERSECT
SELECT * FROM Dozenten
Bei der Schnittmengenbildung R ∩ S werden alle Tupel die sowohl in der Relation R als auch in der
Relation S vorkommen zu einer einzigen Relation vereint. Voraussetzung dafür ist, dass R und S das
gleiche Relationenschema haben (weicht es nur in Reihenfolge und Attributbenennung um, kann dieses
mittels der Projektions- und Umbenennungsoperation angeglichen werden).
Mathematisch ist die Schnittmengenoperation in der Relationenalgebra wie folgt definiert:
7.3.7 Differenz
R ∩ S := {t|t ∈ R ∧ t ∈ S}
Die Differenz zweier Relationen A und B sind die diejenigen Zeilen die in Tabelle A aber nicht in Tabelle B
sind. (vgl. Abbildung 7.12).
A/B
In der Datenbanksprache SQL erfolgt die Differenz-Operation mittels des EXCEPT Schlüsselworts. Ein
typischer SQL Ausdruck um die Differenzmenge zwischen Studenten und Dozenten gem. Abbildung 7.12
zu bestimmen, sähe wie folgt aus:
SELECT * FROM Studenten
EXCEPT
SELECT * FROM Dozenten

Kapitel 8
Transformation und Normalisierung
Transformation bezeichnet die systematische Ableitung eines relationalen Datenbankschemas aus einem
konzeptionellen (ER-)Modell. Anzuwendende Transofrmationsregeln resultieren in normalisierten Relationen.
Transformation ist also eine Top-Down Methode im Datenbankdesign.
Normalisierung befasst sich mit der Qualität eines relationalen Datenbankschemas. Um mehrfaches Festhalten
von gleichen Sachverhalten (Redundanzen) innerhalb eines Datenschemas zu vermeiden, werden
Relationen normalisiert. Hier sind mehrere Normalformen bekannt. In diesem Skript wird die erste bis dritte
Normalform behandelt, da diese die praxisrelevantesten sind. Würde man im Rahmen der Bottom-Up
Entwicklung von Datenbanken den Normalisierungsprozess auslassen, so könnten Anomalien (Inkonsistenz
von Daten) nach der Änderung von Daten im Datenbestand entstehen und es könnte unnötig Speicherplatz
aufgrund redundanter Datenhaltung verbraucht werden. Im Rahmen der Normalisierung nimmt man ein
gegebenes relationales Datenbankschema und überführt dieses schrittweise in die erste, zweite und dritte,
usw. Normalform.
8.1 Transformation
Wendet man auf Basis eines gegebenen ER-Modells Transformationsregeln an, so ist sichergestellt, dass
das resultierende relationale Datenbankschema der dritten Normalform genügt - also qualitativ so gestaltet
ist, dass Änderungs-, Lösch- und Einfügeanomalien im Datenbankbetrieb nicht entstehen können. Ferner
ist eine weitesgehend redundanzfreie Datenhaltung gewährleistet.
8.1.1 Transformationsregel zur Überführung von Entities
Die Entitätstypen werden als Tabelle(Relation) dargestellt, wobei die Entitätstypschlüssel später auch zu
den jeweiligen Tabellenschlüsseln werden. Es werden Relationenschemata erstellt welche der Abbildungen
der Objekttypen entsprechen.
Gesucht werden Entity-Muster in einem ER-Modell wie sie in Abbildung 8.1 allgemein angegeben sind.
Derartige Muster werden pro Muster in folgendes Relationschema überführt. Die Schlüssel werden dabei
als Relationenschlüssel gekennzeichnet (unterstrichen). Die Schlüsselattribute sind Key_1,...,Key_n, die
weiteren Attribute sind Attr_1, ..., Attr_n.
Entity(Key_1,...,Key_n,Attr_1,...,Attr_n)
55

56 KAPITEL 8. TRANSFORMATION UND NORMALISIERUNG
Abbildung 8.1: Entity-Muster
8.1.2 Transformationsregel zur Überführung von n:m Relationen
Für jede n:m Relation eines ER-Modells muss eine zusätzliche Tabelle im Relationenmodell eingeführt
werden. Diese hat den Namen der Relation wie er im ER-Modell festgelegt wurde.
Gesucht werden n:m Relations-Muster in einem ER-Modell wie sie in Abbildung 8.2 allgemein angegeben
sind.
Abbildung 8.2: n:m Relations-Muster
Derartige in Abbildung 8.2 angegebene Muster werden pro Relation in folgende Relationschema überführt.
rel(
)
Key_E1_1->E1.Key_E1_1, ..., Key_E1_n->E1.Key_E1_n,
Key_E2_1->E2.Key_E2_1, ..., Key_E2_m->E2.Key_E2_m,
Attr_rel_1, ...,Attr_rel_k
8.1.3 Transformationsregel zur Überführung von 1:n Relationen
Liegen 1:n Relationen (oder n:1 Relationen - nur andere Lesrichtung vor) kann man sich die Ableitung einer
eigenen Tabelle für die 1:n Relation sparen. Den Verweis eines Entities des Typs E1 auf ein Entity des Typs
E2 kann in einem Attribut des Entities E1 untergebracht werden. Sollte die Relation Attribute haben, so
werden auch diese Relationsattribute in E1 geführt. Man macht dies, um sich das Anlegen einer Tabelle zu
sparen. Auch der Speicherverbrauch sinkt hierdurch.

8.2. NORMALISIERUNG 57
Gesucht werden 1:n Relations-Muster in einem ER-Modell wie sie in Abbildung 8.3 allgemein angegeben
sind.
Abbildung 8.3: 1:n Relations-Muster
Derartige in Abbildung 8.3 angegebene Muster resultieren nicht in der Ableitung einer neuen Tabelle, sondern
nur in der Erweiterung der Tabelle des Entitättyps E1 (Kardinalitätseite n der 1:n Relation). Das Entity
E1 wird wie in Abschnitt 8.1.1 gezeigt abgeleitet (schwarz dargestellt) und zusätzlich um die folgenden
Referenzinformationen und Relationsattribute erweitert (kursiv und rot gekennzeichnet).
E1(
)
Key_E1_1, ..., Key_E1_n,
Attr_E1_1, ..., Attr_E1_l,
Key_E2_1->E2.Key_E2_1, ..., Key_E2_m->E2.Key_E2_m,
Attr_rel_1, ..., Attr_rel_k
8.2 Normalisierung
Werden Relationenschemata nicht auf Basis eines konzeptionellen Modells mittels Transformationsregeln abgeleitet,
so ist Vorsicht geboten. Die so gebildeten Datenstrukturen können sogenannte Einfüge-, Änderungsoder
Löschanomalien verursachen, die letztlich auf redundanter Datenspeicherung beruhen. Durch Normalisierung
wird dieses Problem angegangen. Man versucht sogenannte Normalformen in seinen Datenstrukturen
herzustellen.
Unter Normalisierung eines relationalen Datenschemas versteht man die schrittweise Zerlegung von Relationen,
um Redundanzen innerhalb des Datenschemas zu vermeiden. Die Normalisierung kommt vor allem
beim Design einer relationalen Datenbank zum Einsatz. Innerhalb der relationalen Entwurfstheorie wird
das konzeptionelle Schema der zu entwerfenden Datenbank auf der Grundlage funktionaler Abhängigkeiten
durch den Prozess der Normalisierung redundanzfrei und ohne Datenverlust entwickelt. Für die Normalisierung
gibt es Algorithmen die automatisiert werden können. Für den Nachweis der Verlustfreiheit kann der
Satz von Delobel herangezogen werden. Ohne Normalisierungsprozess läuft der Entwickler einer Datenbank

58 KAPITEL 8. TRANSFORMATION UND NORMALISIERUNG
Gefahr, infolge der Datenredundanzen bei der Änderung von Daten Inkonsistenzen hervorzurufen. Diese
Inkonsistenzen werden auch Anomalien genannt, die nur unnötig Speicherplatz belegen. Das relationale
Datenschema wird schrittweise in die erste, zweite, dritte Normalform überführt. Damit ein relationales
Datenschema in einer Normalform vorliegt, muss es die Kriterien der jeweiligen Normalform erfüllen.
Bei der Normalisierung wird zunächst eine erste, dann eine sogenannte zweite und dann eine dritte Normalform
auf gegebenen Relationen hergestellt (Bottom-Up). Die Normalisierung hat den Zweck, Redundanzen,
mehrfaches Festhalten des gleichen Sachverhalts, zu verringern und dadurch verursachte Anomalien zu verhindern,
um so die Aktualisierung einer Datenbank zu vereinfachen, sowie die Konsistenz der Daten zu
gewährleisten. Normalisierung ist ein probates Mitel sogenannte monothematische Relationen zu bilden.
8.2.1 Erste Normalform
Jedes Attribut der Relation muss einen atomaren Wertebereich haben. (Anm.: statt „atomar“ wird auch die
Bezeichnung „atomisch“ verwendet.)
Das heißt, zusammengesetzte, mengenwertige oder geschachtelte Wertebereiche (relationenwertige Attributwertebereiche)
sind nicht erlaubt. Damit sind auch Wiederholungsgruppen nicht zugelassen. Kurz: Kein
Attributwertebereich kann in weitere (sinnvolle) Teilbereiche aufgespalten werden (Beispiel: Die Adresse
darf nicht als Attribut verwendet werden, sondern muss – sofern es der zugrunde liegende Prozess erfordert
– in PLZ, Ort, Straße und Hausnummer aufgeteilt werden).
Dass die Relation frei von Wiederholungsgruppen sein muss, bedeutet, dass Attribute, die gleiche oder
gleichartige Information enthalten, in eine andere Relation ausgelagert werden müssen.
Ein Beispiel für eine Wiederholungsgruppe wäre eine Spalte Telefon, die mehrere Telefonnummern enthält.
Wichtig ist anzumerken, dass zum Beispiel die Attribute {Telefon1, Telefon2, Telefon3} nicht notwendigerweise
immer eine Wiederholungsgruppe bilden. Ob das der Fall ist, und man diese Attribute daher auslagert,
ist eine Frage der Anforderungen an die Anwendung (siehe Alternative Formulierungen).
Abfragen der Datenbank werden durch die 1NF erleichtert bzw. überhaupt erst ermöglicht, da die Attributwertebereiche
atomar sind. So ist es beispielsweise in einem Feld, das einen ganzen Namensstring aus
Titel, Vorname und Zuname enthält, schwierig bis unmöglich, nach Zunamen zu sortieren.
CD_ID Album Jahr der Gründung Titelliste
4711 Anastacia - Not That Kind 1999 {1. Not That Kind, 2. I’m Outta
Love, 3. Cowboys & Kisses}
4712 Pink Floyd - Wish You Were Here 1964 {1. Shine On You Crazy
Diamond}
4713 Anastacia - Freak of Nature 1999 {1. Paid my Dues}
(a) Beispiel einer Relation, die die 1. NF verletzt
CD_ID Albumtitel Interpret Jahr der Gründung Track Titelliste
4711 Not That Kind Anastacia 1999 1 Not That Kind
4711 Not That Kind Anastacia 1999 2 I’m Outta Love
4711 Not That Kind Anastacia 1999 3 Cowboys & Kisses
4712 Wish You Were Here Pink Floyd 1964 1 Shine On You Crazy
Diamond
4713 Freak of Nature Anastacia 1999 1 Paid my Dues
Tabelle 8.1 zeigt eine Verletztung der 1. NF:
(b) Überführung der Relation in eine 1. NF
Tabelle 8.1: Verletzung der 1NF am Beispiel

8.2. NORMALISIERUNG 59
• Das Feld Album beinhaltet die Attributwertebereiche Interpret und Albumtitel.
• Das Feld Titelliste enthält eine Menge von Titeln.
Dadurch hat man ohne Aufspaltung folgende Probleme bei Abfragen:
• Zur Sortierung nach Albumtitel muss das Feld Album in Interpret und Albumtitel aufgeteilt werden.
• Die Titel können (mit einfachen Mitteln) nur alle gleichzeitig als Titelliste oder gar nicht dargestellt
werden.
Die Lösung zeigt ebenfalls Tabelle 8.1. Die Attributwertebereiche werden in atomare Attributwertebereiche
aufgespalten:
• Das Feld Album wird in die Felder Albumtitel und Interpret gespalten.
• Das Feld Titelliste wird in die Felder Track und Titel gespalten sowie auf mehrere Datensätze aufgeteilt.
Da jetzt jeder Attributwertebereich atomar ist sowie die Tabelle einen eindeutigen Primärschlüssel (Verbundschlüssel
aus den Spalten CD_ID und Track) besitzt, befindet sich die Relation in 1NF.
8.2.2 Zweite Normalform
[TBD] vgl. Wikipedia - Artikel Normalisierung
8.2.3 Dritte Normalform
[TBD] vgl. Wikipedia - Artikel Normalisierung

60 KAPITEL 8. TRANSFORMATION UND NORMALISIERUNG

Literaturverzeichnis
[BJK11] Cornel Brücher, Frank Jüdes, Wulf Kollmann. SQL Thinking - Vom Problem zum SQL-
Statement. mitp, 2011.
[EN09] Ramez A. Elmasri, Shamkant B. Navathe. Grundlagen von Datenbanksystemen (Bachelorausgabe).
Addison-Wesley in Kooperation mit Pearson Studium, wydanie 3. auflage, 2009.
[Gei09] Frank Geisler. Datenbanken - Grundlagen und Design. mitp, wydanie 3. auflage, 2009.
[SZTZ09] Baron Schwartz, Peter Zaitsev, Vadim Tkachenko, Jeremey D. Zawodny. High Performance
MySQL. O’Reilly, wydanie 2. auflage, 2009.
[TB10] Marcus Throll, Oliver Bartosch. Einstieg in SQL. Galileo Computing, 2010.
[Vet98] Max Vetter. Aufbau betrieblicher Informationssysteme. Teubner,1998.
61