Datenmodellierung und Datenbanktechnik

Transcription

Jürgen Spielberger
Dipl. Informatik-Ing. ETH
lic. oec. inform. HSG
Datenmodellierung und
relationale Datenbanktechnik
für Entwickler
und Anwender
©
Jürgen Spielberger
Version 1.0-60, 1. September 2001
2
Inhaltsverzeichnis
Aufbauschema des Buches:
Inhaltsverzeichnis (ab Seite 3)
Inhaltsverzeichnis (ab Seite 3)
Teil 1: Einführung (ab Seite 9)
Einführung in die Thematik der Datenmodellierung und
Datenbanktechnik
Teil 2: Konzeptionelle Datenmodellierung (ab Seite
25)
Theorie und Übungen zum Erstellen konzeptioneller Datenmodelle
Teil 3: Internes Datenmodell (ab Seite 87)
Theorie und Übungen zu Datenbanktechnik und zum Erstellung
des internen/physischen Datenmodells
Teil 4: Fallbeispiel (ab Seite 135)
Umfassende Übung zu den behandelten Themen
Anhang (ab Seite 145)
Musterlösungen zu sämtlichen Aufgaben, Checkliste, Erläuterung der
Fragetypen, Literaturverzeichnis, Index
Auf 213 Seiten Theorie und Übungen
950 Minuten Übungen in 14 Bearbeitungsaufgaben
116 Checkfragen (Multiple Choice)
81 Figuren und Zeichnungen
65 Tabellen und Relationenmodelle
Inhaltsverzeichnis
3
Inhaltsverzeichnis
Teil 1: Einführung
1. Zielsetzung, Zielgruppe, Voraussetzungen und Aufbau
9
11
1.1. Zielsetzung ..................................................................................................................................................................... 11
1.2. Zielgruppe, Voraussetzungen ..................................................................................................................................... 11
1.3. Aufbau des Dokuments .............................................................................................................................................. 11
2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank
12
2.1. Dateiverwaltungssysteme ........................................................................................................................................... 12
2.1.1. Separate Dateiverwaltung ............................................................................................................................... 12
2.1.2. Gemeinsame Dateiverwaltung........................................................................................................................ 12
2.2. Datenbanksysteme...................................................................................................................................................... 13
2.2.1. Hierarchische Datenbanksysteme ................................................................................................................... 13
2.2.2. Netzwerkartige Datenbanksysteme ................................................................................................................ 13
2.2.3. Relationale Datenbanksysteme ....................................................................................................................... 14
2.2.4. Begriff Datenbank .............................................................................................................................................. 15
2.2.5. Eigenschaften von Datenbanken ................................................................................................................... 16
2.3. Checkfragen................................................................................................................................................................. 17
2.3.1. Fragetyp A, Einfachauswahl ............................................................................................................................. 17
2.3.2. Fragetyp E, kausale Verknüpfung.................................................................................................................... 18
2.3.3. Fragetyp K, mehrfache Entscheidung ............................................................................................................ 18
3. Einführung in die Datenmodellierung
19
3.1. Begriff Datenmodell ..................................................................................................................................................... 19
3.2. Gliederung des Datenmodells gemäss ANSI-SPARC.............................................................................................. 19
3.3. Begriff und Zielsetzung der Datenmodellierung ...................................................................................................... 22
3.4. Datenmodellierung als Teil des Informatikprojektes ............................................................................................... 22
3.5. Checkfragen................................................................................................................................................................. 23
Teil 2: Konzeptionelle Datenmodellierung
25
4. Elementarinstrumente des konzeptionellen Datenmodells
27
4.1. Entität, Entitätsmenge ................................................................................................................................................. 27
4.2. Beziehung, Beziehungsmenge ................................................................................................................................... 28
4.2.1. Die Beziehung im Entity-Relationship-Modell ................................................................................................. 28
4.2.2. Erweitertes Relationenmodell, Beziehungs-Variante des Entity-Relationship-Modells............................. 30
4.2.3. Vor- und Nachteile beider Ansätze ................................................................................................................. 30
4.2.4. Assoziationstypen, Beziehungstypen ............................................................................................................... 31
4.2.5. Verhalten bei Datenbank-Transaktionen ....................................................................................................... 33
4.3. Wertebereich ................................................................................................................................................................ 34
4.3.1. Elementarer Wertebereich ............................................................................................................................... 34
4.3.2. Strukturierter Wertebereich  ......................................................................................................................... 35
4.3.3. NULL-Werte .......................................................................................................................................................... 35
4.3.4. Typenbindung  ............................................................................................................................................... 36
4.4. Attribut ........................................................................................................................................................................... 36
4.4.1. Entitätsschlüssel, Schlüsselkandidat ................................................................................................................. 38
4.4.2. Fremdschlüssel .................................................................................................................................................... 38
4.5. Checkfragen................................................................................................................................................................. 41
4.5.2. Fragetyp B, Zuordnung ...................................................................................................................................... 42
4.6. Bearbeitungsaufgaben ............................................................................................................................................... 45
4.6.1. KontoSys, Kontoverwaltungs-System ............................................................................................................... 45
4.6.2. RezeptSys, Rezeptverwaltungs-System ........................................................................................................... 45
4
Inhaltsverzeichnis
5. Normalisierung von Entitätsmengen im konzeptionellen Modell
46
5.1. 1. Normalform ............................................................................................................................................................... 47
5.2. 2. Normalform ............................................................................................................................................................... 48
5.3. 3. Normalform ............................................................................................................................................................... 50
5.4. Checkfragen ................................................................................................................................................................. 53
5.4.2. Fragetyp B, Zuordnung ...................................................................................................................................... 53
5.4.3. Fragetyp E, kausale Verknüpfung .................................................................................................................... 54
5.5.1. Normalisierung Projektverwaltung ................................................................................................................... 56
5.5.2. Normalisierung Buchhandelssystem ................................................................................................................ 56
5.5.3. Normalisierung Wagenvermietung .................................................................................................................. 57
6. Verbundinstrumente des konzeptionellen Modells
58
6.1. Hierarchie....................................................................................................................................................................... 58
6.2. Beziehungsstruktur ........................................................................................................................................................ 58
6.3. Rekursion ........................................................................................................................................................................ 61
6.4. Aggregation .................................................................................................................................................................. 63
6.5. Spezialisierung/Generalisierung ................................................................................................................................. 64
6.6. Wertetabelle ................................................................................................................................................................. 67
6.7. Variante Referenzierung  ....................................................................................................................................... 69
6.8. Checkfragen ................................................................................................................................................................. 71
6.8.2. Fragetyp E, kausale Verknüpfung .................................................................................................................... 71
6.9.1. Liversys, Liegenschafts-Verwaltungs-System ................................................................................................... 73
6.9.2. Transpo, Transport-Verwaltungs-System .......................................................................................................... 73
7. Spezielle Problemstellungen des konzeptionellen Modells 
77
7.1. Mengenprobleme im Verbundinstrument Beziehungsstruktur .............................................................................. 77
7.2. Historisierung von Daten .............................................................................................................................................. 78
7.2.1. Periodenstempel ................................................................................................................................................. 79
7.2.2. Gültig-Ab- und Lösch-Zeitstempel .................................................................................................................... 79
7.2.3. Auslagerung historischer Daten........................................................................................................................ 80
7.2.4. Auslagerung der Änderungen.......................................................................................................................... 80
7.3. Migration von Informationen ...................................................................................................................................... 80
7.4. Verdichtung von Informationen................................................................................................................................. 82
8. Integrität im konzeptionellen Modell
83
8.1. Datenkonsistenz im konzeptionellen Modell ............................................................................................................ 83
8.2. Datenschutz im konzeptionellen Modell................................................................................................................... 84
8.3. Checkfragen ................................................................................................................................................................. 86
Teil 3: Internes Datenmodell
87
9. Datenbanktechnik, Softwarekomponenten eines Datenbanksystems
89
9.1. Externspeicherverwaltung........................................................................................................................................... 90
9.2. Systempufferverwaltung.............................................................................................................................................. 91
9.3. Record- und Zugriffspfadverwaltung ........................................................................................................................ 91
9.3.1. Recordverwaltung .............................................................................................................................................. 91
9.3.2. Zugriffspfadverwaltung ...................................................................................................................................... 92
9.3.2.1. Zugriffsverfahren mit invertierten Listen .................................................................................................. 92
9.3.2.2. Baumstrukturierte Zugriffsverfahren, B- und B*-Baum .......................................................................... 93
9.3.2.3. Zugriffsverfahren mit Schlüsseltransformation ....................................................................................... 97
9.4. Entitätenverwaltung..................................................................................................................................................... 97
9.4.1. Metadatenbank ................................................................................................................................................. 98
9.4.2. Transaktionsverwaltung.................................................................................................................................... 100
9.4.2.1. Optimistisches Verfahren ....................................................................................................................... 102
9.4.2.2. Pessimistisches Verfahren ....................................................................................................................... 102
9.4.2.3. Zeitstempel-Verfahren ............................................................................................................................ 106
9.4.2.4. Transaktionslogik in verteilten Datenbanksystemen .......................................................................... 107
9.4.3. Integritätssicherung im Datenbanksystem (interne Ebene) ....................................................................... 107
Inhaltsverzeichnis
5
9.4.3.1. Datenkonsistenz ...................................................................................................................................... 107
9.4.3.2. Datensicherheit, Recovery .................................................................................................................... 108
9.4.3.3. Datenschutz, Kryptographie ................................................................................................................. 110
9.4.4. Cursor-Verwalter  ......................................................................................................................................... 110
9.5. Entitätsmengenverwaltung ...................................................................................................................................... 110
9.5.1. Zugriffspfadoptimierer, Optimizer................................................................................................................... 111
9.5.2. Datenbanksprachen ....................................................................................................................................... 111
9.6. Checkfragen............................................................................................................................................................... 114
9.6.1. Fragetyp A, Einfachauswahl ........................................................................................................................... 114
9.6.2. Fragetyp B, Zuordnung .................................................................................................................................... 115
9.6.3. Fragetyp E, kausale Verknüpfung.................................................................................................................. 116
9.6.4. Fragetyp K, mehrfache Entscheidung .......................................................................................................... 117
9.7. Bearbeitungsaufgaben ............................................................................................................................................. 118
9.7.1. Zugriffspfade ..................................................................................................................................................... 118
9.7.1.1. 1. Aufgabe: Invertierte Liste .................................................................................................................. 118
9.7.1.2. 2. Aufgabe: HASH ................................................................................................................................... 119
9.7.1.3. 3. Aufgabe: B-Baum ............................................................................................................................... 119
9.7.2. Metadatenbank ............................................................................................................................................... 120
9.7.3. Deadlock im pessimistischen Verfahren ....................................................................................................... 121
9.7.4. Locking im pessimistischen Verfahren ........................................................................................................... 122
9.7.5. Ablaufplan ......................................................................................................................................................... 124
9.7.6. Transaktionslogik und Programme ................................................................................................................. 125
10. Internes Datenmodell
126
10.1. Herleitung des internen Datenmodells für ein vorgegebenes Datenbanksystem ........................................ 126
10.2. Bestimmen der Zugriffspfade ................................................................................................................................. 127
10.2.1. Mögliche Zugriffspfade bestimmen ............................................................................................................ 127
10.2.2. Zugriffspfad-Effizienz bestimmen .................................................................................................................. 128
10.3. Physische Organisation ........................................................................................................................................... 129
10.4. Denormalisierung zur Performance-Verbesserung ............................................................................................. 130
10.5. Checkfragen ............................................................................................................................................................ 131
10.5.1. Fragetyp K, mehrfache Entscheidung ........................................................................................................ 131
11. Verteilung von Daten
132
11.1. Vorteile und Nachteile verteilter Datenbanksysteme ........................................................................................ 132
11.2. Eigenschaften verteilter Datenbanksysteme ...................................................................................................... 132
11.3. Checkfragen ............................................................................................................................................................ 134
11.3.1. Fragetyp K, mehrfache Entscheidung ........................................................................................................ 134
Teil 4: Fallbeispiel
12. Fallbeispiel TTW
135
137
12.1. Ist-Analyse: Datenmodell zur Anwendung TravelSys ermitteln (Bottom-Up) .................................................. 137
12.1.1. Ermittlung des Datenmodells zur Anwendung TravelSys (55 Minuten) .................................................. 138
12.1.2. Normalisierung des Datenmodells (25 Minuten) ....................................................................................... 139
12.2. Soll-Konzept: Datenmodell mit neuen Anforderungen ergänzen (Top-Down) ............................................. 140
12.2.1. Strukturierung der Reisen, Aggregation (Part-Of-Struktur / Stückliste) (25 Minuten) ............................ 140
12.2.2. Zeitabhängige Daten und Varianten von Daten in Datenmodellen (40 Minuten)............................. 141
12.2.3. Mitarbeiterstamm, Spezialisierung/Generalisierung (Is-A-Struktur) (20 Minuten) .................................. 142
12.3. Vorgehensentscheid Dateiverwaltung oder DBMS (20 Minuten) .................................................................... 143
12.4. Ableiten des internen Schemas, Bestimmen der physischen Speicherorganisation .................................... 143
12.4.1. Internes Schema (15 Minuten) ..................................................................................................................... 143
12.4.2. Physische Speicherorganisation (5 Minuten) ............................................................................................. 143
12.5. Meta-Entitätstypen, Data-Dictionary (20 Minuten) ............................................................................................ 143
Anhang
13. Tabellen, Verzeichnisse
145
147
13.1. Farben, Sonderzeichen und deren Bedeutung .................................................................................................. 147
13.2. Synonyme unterschiedlicher Systeme und Modelle .......................................................................................... 148
13.3. Kürzel der Datenmodellierung und Datenbanktechnik .................................................................................... 149
13.4. Kontrollfragen zum konzeptionellen Datenmodell ............................................................................................. 150
6
Inhaltsverzeichnis
14. Fragetypen der Checkfragen
151
15. Lösungen zu den Aufgaben
152
15.1. Checkfragen: 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank ...................... 152
15.1.1. Fragetyp E, kausale Verknüpfung ............................................................................................................... 153
15.1.2. Fragetyp K, mehrfache Entscheidung ....................................................................................................... 153
15.2. Checkfragen: 3. Einführung in die Datenmodellierung ..................................................................................... 154
15.2.1. Fragetyp A, Einfachauswahl ........................................................................................................................ 154
15.3. Checkfragen: 4. Elementarinstrumente des konzeptionellen Datenmodells ................................................. 155
15.3.2. Fragetyp B, Zuordnung ................................................................................................................................. 156
15.4. Bearbeitungsaufgaben: 4. Elementarinstrumente des konzeptionellen Datenmodells ............................... 158
15.4.1. KontoSys, Kontoverwaltungs-System ........................................................................................................... 158
15.4.2. RezeptSys, Rezeptverwaltungssystem ......................................................................................................... 159
15.5. Checkfragen: 5. Normalisierung von Entitätsmengen im konzeptionellen Modell ........................................ 161
15.5.2. Fragetyp B, Zuordnung ................................................................................................................................. 161
15.6. Bearbeitungsaufgaben: 5. Normalisierung von Entitätsmengen im konzeptionellen Modell ...................... 164
15.6.1. Projektverwaltung ........................................................................................................................................... 164
15.6.2. Buchhandelssystem ........................................................................................................................................ 165
15.6.3. Wagenvermietung ......................................................................................................................................... 166
15.7. Checkfragen: 6. Verbundinstrumente des konzeptionellen Modells ............................................................... 169
15.8. Bearbeitungsaufgaben: 6. Verbundinstrumente des konzeptionellen Modells ............................................. 171
15.8.1. Liversys .............................................................................................................................................................. 171
15.8.2. Transpo ............................................................................................................................................................. 175
15.9. Checkfragen: 8. Integrität im konzeptionellen Modell ....................................................................................... 180
15.10. Checkfragen: 9. Datenbanktechnik, Softwarekomponenten eines Datenbanksystems........................... 181
15.10.1. Fragetyp A, Einfachauswahl ...................................................................................................................... 181
15.10.2. Fragetyp B, Zuordnung ............................................................................................................................... 182
15.10.3. Fragetyp E, kausale Verknüpfung ............................................................................................................. 183
15.10.4. Fragetyp K, mehrfache Entscheidung ..................................................................................................... 184
15.11. Bearbeitungsaufgaben: 9. Datenbanktechnik, Softwarekomponenten eines Datenbanksystems ......... 185
15.11.1. Zugriffspfade .................................................................................................................................................. 185
15.11.2. Metadatenbank ........................................................................................................................................... 186
15.11.3. Deadlock im pessimistischen Verfahren ................................................................................................... 189
15.11.4. Locking im pessimistischen Verfahren ....................................................................................................... 190
15.11.5. Ablaufplan ..................................................................................................................................................... 192
15.11.6. Transaktionslogik und Programme ............................................................................................................. 193
15.12. Checkfragen: 10. Internes Datenmodell ............................................................................................................ 194
15.13. Checkfragen: 11. Verteilung von Daten ............................................................................................................ 195
15.14. 12. Fallbeispiel TTW ................................................................................................................................................. 196
15.14.1. Ist-Analyse: Datenmodell zur Anwendung TravelSys ermitteln (Bottom-Up) ....................................... 196
15.14.1.1. Ermittlung des Datenmodells zur Anwendung TravelSys .............................................................. 196
15.14.1.2. Normalisierung des Datenmodells ................................................................................................... 198
15.14.2. Soll-Konzept: Datenmodell mit neuen Anforderungen ergänzen (Top-Down) .................................. 201
15.14.2.1. Strukturierung der Reisen, Aggregation (Part-Of-Struktur / Stückliste) ........................................ 201
15.14.2.2. Zeitabhängige Daten und Varianten von Daten in Datenmodellen ......................................... 204
15.14.2.3. Mitarbeiter-Stamm, Spezialisierung/Generalisierung .................................................................... 206
15.14.3. Vorgehensentscheid Dateiverwaltung oder DBMS ................................................................................ 207
15.14.4. Ableiten des internen Schemas, Bestimmen der physischen Speicherorganisation ......................... 208
15.14.4.1. Internes Schema ................................................................................................................................. 208
15.14.4.2. Physische Speicherorganisation ....................................................................................................... 208
15.14.5. Meta-Entitätstypen, Data-Dictionary......................................................................................................... 209
Inhaltsverzeichnis
7
16. Literatur
211
17. Index
212
9
Teil 1:
Einführung
10
Teil 1: Einführung
11
1. Zielsetzung, Zielgruppe, Voraussetzungen und Aufbau
1.1. Zielsetzung
Dieses Dokument ermöglicht dem Leser folgende zwei Ziele zu erreichen:
1. Das Dokument vermittelt die Grundlagen der Datenmodellierung, so dass der Leser
in der Lage ist, selbständig ein Datenmodell zu entwickeln und/oder dieses auf dessen Zweckmässigkeit und Qualität hin zu überprüfen. In den weiterführenden Kapiteln werden Spezialfälle und deren möglichen Lösungen gezeigt, so dass der Leser
auch für komplexere Probleme der Modellierung gerüstet ist.
2. Des Weiteren soll dem Leser gezeigt werden, mittels welcher Methoden relationale
Datenbanksysteme ihre Aufgaben lösen. Diese Kenntnisse dienen als Basis um zu
zeigen, welche technischen Faktoren beim Einsatz eines Datenbanksystems zu berücksichtigen sind. Danach ist der Leser in der Lage, ein Datenmodell physisch auf
einem Datenbanksystem zu realisieren und das Datenbanksystem in Programmen
und Abfragen optimal zu nutzen (Effizienz, Performanz) bzw. dessen Leistung gezielt
zu beeinflussen.
Um diese Ziele zu erreichen, sind nach jedem Kapitel entsprechende Übungen und/oder
Check-Fragen eingebettet. Diese Übungen ermöglichen es, den Inhalt der Kapitel selbständig
zu erarbeiten und an konkreten, praxisorientierten Fällen zu vertiefen. Eine Erläuterung zu den
Check-Fragen finden Sie im Kapitel '14. Fragetypen der Checkfragen' auf Seite 151.
1.2. Zielgruppe, Voraussetzungen
Diese Dokumentation richtet sich an Entwickler (Informatik, Organisation, ...) und Anwender mit
folgenden Aufgaben:
1. Datenmodellierung: Entwickler und Anwender, welche in ihrer Arbeit Datenmodelle
lesen, erstellen oder verwalten müssen.
2. Programmierung: Entwickler, welche Programme und Abfragen für Datenbanksysteme entwickeln und warten.
3. Tuning: Entwickler, welche das Leistungsverhalten von Datenbanksystemen gezielt
beeinflussen müssen.
Zur Bearbeitung dieses Dokumentes sind folgende Kenntnisse empfohlen:
1. EDV-Grundkenntnisse.
2. Einfache Kenntnisse von Datenbanksystemen oder Dateiverwaltungssystemen (aber
keine Kenntnisse der Datenmodellierung)
Um einen Überblick über die wichtigsten verwendeten Begriffe zu erhalten, empfiehlt sich an
dieser Stelle ein kurzes Studium des Kapitels '13.2. Synonyme unterschiedlicher Systeme und Modelle' auf Seite 148.
1.3. Aufbau des Dokuments
Das Dokument ist derart aufgebaut, dass alle Kapitel gelesen und verstanden werden können,
ohne über Kenntnisse der nachfolgenden Kapitel verfügen zu müssen. Damit kann das Dokument vom Start bis zum Ende linear durchgearbeitet werden. Dies bedingt allerdings, dass stellenweise die Erläuterung gewisser Grundkenntnisse der detaillierten Behandlung des Themas
vorgezogen wird.
Weiter sind Kapitel und Abschnitte, welche für den Anfänger ungeeignet sind, das heisst, welche bereits Erfahrungen in der Datenmodellierung benötigen oder welche detaillierte AusfühTeil 1: Einführung
12
rungen zu einem bestimmten Thema enthalten, mit dem Zeichen  gekennzeichnet. Dadurch
kann der Anfänger zunächst die Grundkenntnisse erarbeiten und später die Detailkenntnisse
gezielt nacherarbeiten.
In diesem Kapitel wird die technologische Entwicklung von Datenbanksystemen gezeigt. Es eignet sich daher speziell für Leser, welche keine oder wenig Erfahrung mit Datenbanksystemen
haben, um sich einen ersten Überblick zu verschaffen und den Einstieg zu erleichtern.
Die Gliederung der Systeme, wie sie in den folgenden Unterkapiteln vorgenommen wird, kann in
der Praxis nicht derart streng erfolgen. In der Realität sind die Grenzen verschwommen und
können sich die gezeigten Eigenschaften vermischen. Die Beispiele müssen daher als Extreme
einer kontinuierlichen technischen Entwicklung angesehen werden.
Um den Vergleich und den Einstieg in die unterschiedlichen Systeme zu erleichtern, sei an dieser
Stelle auf die Tabelle auf Seite 148 im Kapitel '13.2. Synonyme unterschiedlicher Systeme und
Modelle' hingewiesen, in welcher die Begriffe der verschiedenen Systeme und Modelle einander gegenübergestellt werden.
2.1. Dateiverwaltungssysteme
2.1.1. Separate Dateiverwaltung
Dateiverwaltungssysteme sind in unserem Sinne keine Datenbanksysteme. Bei primitiven Dateiverwaltungssystemen werden Dateien durch Programme verarbeitet, welche wieder Dateien
als Ausgabe erzeugen. Die Dateien fliessen dabei förmlich durch die Programme. Der Datenfluss kann dabei mittels sogenannter Datenflussdiagramme grafisch dargestellt werden. Dieser
Datenfluss beschreibt den logischen Ablauf (Reihenfolge) der Programme. Die innere Struktur
der Datei wird hierbei im Programm selbst definiert (z.B. als 'File Of Record'). Müssen Änderungen
in der Datenstruktur vorgenommen werden, so müssen sämtliche Programme, welche eine Datei dieser Struktur verarbeiten, angepasst werden. Zusätzlich treten bei dieser Verarbeitung viele
Redundanzen (Mehrfachspeicherung der selben Information) auf. Dateiverwaltungssysteme mit
dieser Arbeitsweise werden separate Dateiverwaltungssysteme genannt, weil der Zugriff auf die
Daten durch jedes Programm selbständig erfolgt. Diese Art der Programmierung war zu Beginn
in der Informatik der Normalfall und entsprach den technischen Gegebenheiten jener Zeit.
2.1.2. Gemeinsame Dateiverwaltung
Um die schwerwiegendsten Mängel dieser primitiven Dateiverwaltungssysteme zu korrigieren,
wurden in der Folge zentrale Programmmodule erstellt, welche den Zugriff auf die Daten handhabten. Diese Systeme werden daher gemeinsame Dateiverwaltungssysteme genannt. Zentrale
Komponente dieser Systeme ist eine Sammlung von Programmmodulen (Bibliothek), welche
den Zugriff auf die Daten steuern. Die Programme greifen dabei nicht mehr selbst und direkt auf
die Daten zu, sondern nur noch mittels der Programmmodule (z.B. ' Les e_Name[ I N: Kunden_Nr , OUT: Kunden_Name] '). Je nach Reife des Dateiverwaltungssystems werden damit
bereits beträchtliche Vorteile errungen. Prinzipiell könnten damit alle unerwünschten Redundanzen verhindert werden. Die eigentlichen Programme müssten keinerlei Strukturinformationen
(Rekordstruktur) beinhalten. Systeme mit gemeinsamer Dateiverwaltung sind in der Regel auf
bestimmte Aufgabenbereiche zugeschnitten (z.B. Verwaltung von grafischen Objekten) und
dabei durchaus leistungsfähig. Allerdings weisen diese Systeme weitere gravierende Mängel
auf, welche deren Einsatz im Allgemeinen verunmöglichen (z.B. kein Mehrbenutzerbetrieb, keine Transaktionslogik, etc.).
Teil 1: Einführung
13
2.2. Datenbanksysteme
2.2.1. Hierarchische Datenbanksysteme
In einem nächsten Schritt wurden Datenbanksysteme (auch Datenbankmanagementsystem)
(Englisch: Database Management System, Kurzform: DBMS) entwickelt, welche grundsätzlich
unabhängig von vorgegebenen Aufgabenbereichen eingesetzt werden können. Diese Systeme betrachten die einzelnen Dateien dabei nicht nur als isolierte Einzelstücke, sondern berücksichtigen auch die Beziehungen zwischen den Dateien (z.B. zwischen dem Kunden und dessen
Aufträgen).
Hierarchische Datenbanksysteme sind die ältesten Systeme. Sie erlauben nur Beziehungen mit
hierarchischem Charakter darzustellen, dabei kann die entstehende Datenstruktur als Baum
dargestellt werden (siehe Figur: 'Datenmodell eines hierarchischen Datenbanksystem'). Bei hierarchischen Beziehungen kann ein übergeordneter Knoten mehrere untergeordnete Knoten
haben, ein untergeordneter Knoten hat aber höchstens einen übergeordneten Knoten.
Dadurch können Kunden Aufträge und Rechnungen haben, die Aufträge können aber nur den
Kunden untergeordnet werden. Die Beziehungen zwischen den Daten werden hierfür in der Regel mittels physischer Adresszeiger (Pointer) erstellt. Darin widerspiegelt sich auch die Nähe dieser Systeme zur technischen Lösung. Die Verarbeitung der Daten erfolgt, indem in den Programmen diesen Adresszeigern gefolgt wird. Diese Verarbeitungsart in den Programmen wird
Navigation genannt.
Kunden
Aufträge
Rechnungen
Auftragspositionen
Figur 1: Datenmodell eines hierarchischen Datenbanksystems
Mittels hierarchischer Systeme können komplexe Datenstrukturen aber nicht ohne gravierende
Redundanzen abgebildet werden. Rein hierarchische Systeme waren daher auf Dauer den Anforderungen der Praxis nicht gewachsen. Hierarchische Datenbanksysteme in Reinkultur existieren daher nicht mehr. Ursprünglich hierarchische Datenbanksysteme wie IMS (Information
Management System) bieten heute Erweiterungen, welche diesen schwerwiegenden Mangel
beseitigen.
2.2.2. Netzwerkartige Datenbanksysteme
Netzwerkartige Systeme eliminieren den entscheidenden Mangel, welcher den hierarchischen
Systemen eigen war. Sie erlauben nicht nur hierarchische Datenstrukturen, sondern beliebige
netzwerkartige Datenstrukturen (auch Plexstruktur genannt). Dadurch konnten in Datenbanksystemen erstmals Datenstrukturen ohne Redundanzen abgebildet werden. Überdies sind
die netzwerkartigen Datenbanksysteme technologisch noch eng mit den hierarchischen Systemen verwandt. So wird in den Programmen zur Verarbeitung der Daten noch immer navigiert.
Wichtigster Standard für Netzwerkdatenbanken ist das CODASYL-DBTG-Modell. Das CODASYLDBTG-Modell enthält eine Datenbeschreibungskomponente und eine Datenmanipulationssprache.
Teil 1: Einführung
14
Kunden
Artikel
Aufträge
Rechnungen
Auftragspositionen
Figur 2: Datenmodell eines netzwerkartigen Datenbanksystems
Netzwerkartige Datenbanksysteme sind zwar effizient und ausgereift, doch hat eine Reihe von
Mängeln dem relationalen Ansatz zum Durchbruch verholfen. So erfordert der Gebrauch der
Datenbanksprache netzwerkartiger Systeme hohe Kenntnisse des realisierten Datenmodells und
kann durch den Benutzer nicht angewendet werden. Auch sind Strukturänderungen der Daten
mit grossem Aufwand verbunden, da die Daten mittels physischer Adresszeiger verknüpft werden.
2.2.3. Relationale Datenbanksysteme
Während sich das hierarchische und das netzwerkartige Datenbanksystem an der technischen
Lösung orientieren, löst sich das relationale Datenbanksystem vom technischen Ansatz. Ausgangsidee ist, dass alle (wirklich alle) Daten in Relationen (auch Tabellen genannt), ähnlich wie
in einer Tabellenkalkulation, festgehalten werden (einfache Lösungen sind gute Lösungen). Die
Darstellung der Daten mittels Relationen ist für Benutzer und Entwickler einfach und klar verständlich. Selbst die Verknüpfung der Daten erfolgt nicht mehr mittels physischer Adresszeiger,
sondern mittels identischer Feldeinträge. So wird zum Beispiel in einem Auftrag (Datensatz, bzw.
Tupel) mittels dem Attribut (Feld, bzw. Spalte) Kunden# auf den Kunden verwiesen, zu welchem
der Auftrag gehört. Das Attribut Kunden# wird in der Relation Auftrag durch seine spezifische
Aufgabe als Fremdschlüssel bezeichnet. Dieser Lösungsansatz wurde von Edgar F. Codd ausgearbeitet und mit einer fundierten Theorie ausgestattet:
Kunden
Kunden#
1
2
Name
Maier
Müller
PLZ
8001
8001
Ort
Zürich
Zürich
Rechnungen
Rechnungs# Kunden#
32
1
33
2
Datum
4. März
4. März
Betrag
2'778,00
211,50
Aufträge
Auftrags#
254301
254302
244692
Kunden#
1
1
2
Teil 1: Einführung
Auftragsdatum
4. März
4. März
4. März
15
Artikel
Artikel#
Bezeichnung
2531
7121
2644
4623
Monitor XP 34-3
Monitor XP 34-4
Diskette XDS
Tastatur HG/3
Preis
1'090,00
1'490,00
4,50
99,00
Lagerbestand
6,00
5,00
5'465,00
12,00
Auftragspositionen
Auftrags#
254301
254301
254302
244692
244692
Artikel#
2531
7121
4623
2644
4623
Bestellmenge Rechnungsbetr.
1,00
1'090,00
1,00
1'490,00
2,00
198,00
25,00
112,50
1,00
99,00
Tabellen 1: Datendarstellung in relationalen Datenbanksystemen
Ein Datenbanksystem ist, gemäss Codd [Codd 70], minimal relational, wenn dessen Funktionalität mindestens folgende drei Konzepte enthält:
1. Die gesamten Informationen sind einheitlich in Relationen (Tabellen) abgelegt.
2. Der Benutzer sieht keine Verweisstrukturen (keine physischen Adresszeiger) zwischen
den Relationen.
3. Es sind Operationen zur Auswahl von Zeilen (Selektion) und Auswahl von Spalten
(Projektion), sowie zur Verbindung (Join) von Relationeneinträgen definiert.
Datenbanksysteme sind nur dann voll relational, wenn sie über die genannten Konzepte hinaus
bestimmte Integritätsbedingungen selbständig überprüfen und wenn zusätzliche, ergänzende
Datenbankoperationen zur Verfügung stehen.
Die Struktur der Daten selbst kann natürlich auf die selbe grafische Art und Weise wie im Beispiel
der netzwerkartigen Datenbank dargestellt werden. An dieser Stelle werden noch nicht alle Details relationaler Datenbanksysteme gezeigt. Diese werden später noch ausführlich besprochen.
2.2.4. Begriff Datenbank
In der Praxis werden die Begriffe Datenbasis, Datenbanksystem (auch Datenbankverwaltungssystem) und Datenbank leider mehr oder weniger willkürlich verwendet, dabei sind die Begriffe
klar definiert.
 Datenbank: Das Datenbanksystem (DBMS) bildet zusammen mit dem Datenbestand (Datenbasis) die Datenbank.
Datenbanksysteme können in drei wesentliche Komponenten gegliedert werden. Diese Dreigliederung wird im Folgenden immer wieder verwendet werden:
1. Manipulationskomponente: Die Manipulationskomponente erlaubt die Verarbeitung
der Benutzerdaten. Die Verarbeitung kann hierbei mengenorientiert (d.h. mehrere
Datensätze pro Befehl) erfolgen (beispielsweise in SQL). Die Sprache zu dieser Komponente wird Datenmanipulations-Sprache, bzw. DML (Englisch: Data Manipulation
Language) genannt.
2. Strukturierungskomponente: Mittels dieser Komponente wird die Struktur der Benutzerdaten verwaltet. Diese Strukturinformationen werden in der relationalen Datenbank ebenfalls in Relationen abgelegt. Die Sprache, mittels welcher die Struktur
Teil 1: Einführung
16
definiert wird, wird Datendefinitions-Sprache oder Datenbeschreibungs-Sprache,
bzw. DDL (Englisch: Data Definition Language oder Data Description Language)
genannt.
3. Integritätskomponente: Diese Komponente stellt die Integrität (Widerspruchsfreiheit)
der Daten sicher. So werden z.B. die Verknüpfung der Daten und benutzerdefinierte
Integritätsregeln durch das Datenbanksystem kontrolliert. Die Sprache, mittels
welcher die Integritätsregeln definiert werden, wird Datenkontroll-Sprache, bzw.
DCL (Englisch: Data Control Language) genannt.
Im Idealfall existiert eine einzige, einheitliche Sprache, welche alle drei Komponenten umfasst
(z.B. SQL).
2.2.5. Eigenschaften von Datenbanken
In Datenbanken sind eine Reihe von wichtigen Eigenschaften integriert worden. Diese wichtigen Eigenschaften haben Datenbanksystemen zu ihrer weiten Verbreitung verholfen:
 Redundanzarme, strukturierte Datenbasis: Im Gegensatz zu Dateiverwaltungssystemen werden die Daten mit möglichst wenig Redundanzen (diese werden allenfalls zur Steigerung der Performance eingeführt) und in strukturierter Form abgelegt.
 Mehrbenutzerbetrieb: Datenbanksysteme koordinieren den gleichzeitigen, gemeinsamen Zugriff mehrerer Benutzer auf den selben Datenbestand und vermitteln dem
Benutzer den Eindruck, die Daten als einziger zu verwenden.
 Integritätssicherung: Das Datenbanksystem kontrolliert die Daten auf Widerspruchsfreiheit (Datenkonsistenz), bewahrt vor physischer Verfälschung, bzw. Verlust (Datensicherheit) und schützt die Daten vor unerlaubten Zugriffen (Datenschutz).
 Verteilte Datenbanken: Daten können auf verschiedene Systeme (physisch und logisch) verteilt und dennoch durch alle Benutzer gemeinsam genutzt werden.
 Logische und physische Datenunabhängigkeit (Englisch: Data Independence):
Strukturänderungen der Benutzerdaten (logische Datenunabhängigkeit, z.B. Änderungen an Feldformaten) und Änderungen der physischen Organisation der Daten
(physische Datenunabhängigkeit, z.B. Speicherbereiche, Speichersatztypen, Indizes)
haben, soweit möglich, keinen Einfluss auf bestehende Programme.
Das 3-Schema-Modell von ANSI/SPARC (siehe '3.2. Gliederung des Datenmodells
gemäss ANSI-SPARC' auf Seite 19) bezweckt im Kern die Realisierung der Datenunabhängigkeit.
Teil 1: Einführung
17
2.3. Checkfragen
Die im folgenden verwendeten Fragetypen sind im Kapitel '14. Fragetypen der Checkfragen'
auf Seite 151 erklärt. Die Lösungen zu den folgenden Checkfragen finden Sie auf Seite 152.
2.3.1. Fragetyp A, Einfachauswahl
1.
Für hierarchische und netzwerkartige Datenbanksysteme gilt:





2.
hierarchisches DBMS
netzwerkartiges DBMS
relationales DBMS
integrative DBMS
verteilte Datenbanken
A)
B)
C)
D)
E)
hierarchisches DBMS
netzwerkartiges DBMS
relationales DBMS
in keinem werden Beziehungen durch Adresszeiger dargestellt
bei allen
A)
B)
C)
D)
E)
ein beliebiges Datenbankverwaltungssystem.
ein relationales Datenbankverwaltungssystem.
ein beliebiges Datenbankverwaltungssystem und dessen Datenbasis.
ein relationales Datenbankverwaltungssystem und dessen Datenbasis.
ein beliebiges Datenbankverwaltungssystem und die verwendete Hardware.
Eine DML ist...





7.
A)
B)
C)
D)
E)
Eine Datenbank ist...





6.
Die DML wird zur Definition der Datenstruktur relationaler Datenbanksysteme verwendet
Im relationalen Datenbanksystem werden alle Daten in Relationen festgehalten
Die Daten werden baumstrukturiert abgelegt
Der Fremdschlüssel identifiziert die Zeilen (Tupel) der Tabellen eindeutig
Relationale Datenbanken können die physische Datenunabhängigkeit nicht gewährleisten
In welchem Datenbanksystem werden Beziehungen auf der logischen Ebene nicht durch
Adresszeiger (Pointer) dargestellt?





5.
A)
B)
C)
D)
E)
Bei welchem DBMS wird in den Programmen nicht navigiert?





4.
Daten lassen sich immer redundanzfrei ablegen
Sämtliche in der Realität auftretenden Datenstrukturen lassen sich darin 1:1 abbilden
Die Daten werden immer baumstrukturiert abgelegt
Strukturänderungen der Daten können nur mit grossem Aufwand vollzogen werden
Benutzer können Daten einfach abfragen
Für das relationale DBMS gilt:





3.
A)
B)
C)
D)
E)
A)
B)
C)
D)
E)
eine 3. Generationssprache.
eine Menge von Tupeln.
eine Sprache zur Manipulation von Datenbeständen.
eine Datei zum Protokollieren von Zugriffen.
eine Konsistenzbedingung.
Welche Eigenschaft weist eine Datenbank nicht auf?





A)
B)
C)
D)
E)
Trennung der Daten von den Anwendungen
physische Datenabhängigkeit der Anwendungsprogramme
dauerhafte Nutzung der Daten
spezifische Datensichten für verschiedene Benutzer
Strukturierung der Daten (kontrollierte Redundanz)
Teil 1: Einführung
18
2.3.2. Fragetyp E, kausale Verknüpfung
1.
In der heutigen Zeit empfiehlt sich in jedem Fall der Einsatz eines Datenbankmanagementsystems, weil die Integrität der Daten durch ein Datenbankmanagementsystem von Anfang an sichergestellt ist.
 A)
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
2.3.3. Fragetyp K, mehrfache Entscheidung
1.
Welche Aussagen sind für die Dateiverwaltung im Vergleich zum DBMS korrekt?
+  
 
 
 
Die Dateiverwaltung hat einen kleineren Aufwand (Rechenzeit) während des Betriebs.
Die Dateiverwaltung hat einen kleineren Aufwand (Arbeitszeit Entwickler) während der Entwicklung
und Wartung von Anwendungen.
Die Dateiverwaltung erlaubt ein einfacheres, besseres Sicherstellen der Integritätsanforderungen.
Die mit Dateiverwaltungssystemen entwickelten Anwendungen sind flexibler gegenüber zukünftigen
Entwicklungen.
Teil 1: Einführung
19
3.1. Begriff Datenmodell
Der Begriff Datenmodell ist in der Praxis mit zwei voneinander abweichenden Bedeutungen belegt:
1. Datenmodellierungsmethode: Mittels dieser können Struktur, Inhalt und ergänzende
semantische Aspekte des Datenbestandes entwickelt und festgehalten werden.
Hierfür wurden in der Praxis unterschiedliche Methoden entwickelt. Eine der bekanntesten und verbreitesten Methoden ist das Entity-Relationship-Modell (mit vielen
Varianten).
2. Datenstruktur: Die Datenstruktur zeigt den Aufbau der Daten eines Datenbestandes.
Die Daten selbst werden in der Datenstruktur nicht festgehalten, lediglich deren
Aufbau. In der Regel werden in der Datenstruktur auch logische Datenbanktransaktionen und Integritätsregeln definiert.
Diese Doppelbelegung des Begriffs Datenmodell bereitet in der Praxis selten Schwierigkeiten.
Die Bedeutung ergibt sich aus dem Kontext.
3.2. Gliederung des Datenmodells gemäss ANSI-SPARC
Aufgrund der Komplexität sowie der unterschiedlichen Sichtweisen der im Modellierungsprozess
betroffenen Personen (Anwender, Entwickler, DBA, ...), drängt sich eine den Sichtweisen der
Personen angepasste Darstellung und Gliederung des Modells (Datenstruktur) auf. Hierbei hat
sich ein Modell (Datenmodellierungsmethode), das 3-Schema-Modell oder auch 3-SchemaKonzept des ANSI-SPARC-Komitees durchgesetzt (1977). Diese Datenmodellierungsmethode unterscheidet, wie der Name schon sagt, 3 Ebenen. Hierbei wird für jede Ebene eine der Sichtweise angepasste Datenstruktur bzw. Datenstrukturen erstellt. Hier erfolgt eine kurze Erklärung dieser
Ebenen, später werden diese Ebenen anhand von Beispielen ausführlich behandelt.
1. Konzeptionelle Ebene: Diese stellt die gesamte Datenstruktur der Unternehmung dar
(unternehmensweites Datenmodell). Dabei wird dieses Modell unabhängig vom zu
verwendenden Datenbanksystem und Hardware erstellt. Damit ist das konzeptionelle Modell frei von technischen Details und kann auch erstellt werden, wenn das Zielsystem noch nicht bekannt ist. In dieser Ebene wird daher noch keine Rücksicht auf
Performance oder Datenmengen genommen, diese Aspekte werden nur in der internen, physischen Ebene berücksichtigt (siehe unten). In der konzeptionellen Ebene
wird versucht, ein möglichst realitätsnahes Datenmodell zu erstellen, welches keine
Redundanzen aufweist.
Auf dieser Ebene werden die Fachbegriffe der Anwendung eindeutig definiert. Dadurch bildet die konzeptionelle Ebene eine einheitliche, gemeinsame sprachliche
Basis für alle am Projekt beteiligten Personen.
Diese Ebene bildet in der Regel die Ausgangsbasis, um die Datenmodelle der beiden anderen Ebenen zu bilden. Innerhalb eines Projektvorgehens steht daher die Erstellung des konzeptionellen Datenmodells in aller Regel vor der Erstellung der Modelle der beiden anderen Ebenen.
2. Externe, logische Ebene: Auf der externen Ebene wird dargestellt, wie die Daten
dem Benutzer präsentiert werden. Der Benutzer kann hierbei eine ganz andere
Sichtweise auf die Daten einnehmen, als diese im konzeptionellen Modell abgelegt
sind. Auch wird er in der Regel mehrere Sichten auf das selbe Modell einnehmen, je
nach Problemstellung. Auf der externen Ebene werden daher für das konzeptionelle
Modell viele, problemspezifische Teilsichten gebildet. In der Praxis wird für diese externen Sichten häufig der Fachbegriff View verwendet. Der Begriff logische Ebene
sollte vermieden werden, da dieser nicht einheitlich verwendet wird.
Teil 1: Einführung
20
3. Interne, physische Ebene: Diese Ebene stellt dar, wie die Daten mit Hilfe des
Datenbanksystems physisch organisiert werden sollen. Das interne Modell wird in der
Regel vom konzeptionellen Modell abgeleitet. Wurden technische Aspekte beim
Erstellen des konzeptionellen Modells vernachlässigt, so stehen diese jetzt im Zentrum
der Überlegungen. Durch eine genaue Kenntnis des Datenbanksystems (z.B. ein
relationales Datenbanksystem), der Datenmengen, der Zugriffshäufigkeiten und
vieler Details mehr, wird versucht, ein 'optimales' internes Modell zu bilden. Die
Performance der späteren Datenbankoperationen ist vom abgeleiteten internen
(nicht aber vom konzeptionellen) Modell abhängig. Auch hier muss ein Kompromiss
vieler widersprüchlicher Ziele gefunden werden. Eine wichtige Anforderung an
Datenbanksysteme und Entwicklungsumgebungen ist es, diesen Optimierungsprozess auch noch während des normalen Betriebes zu ermöglichen und zu
unterstützen.
1. externe
Datensicht
2. externe
Datensicht
konzeptionelles
Datenm odell
interne Datenstruktur
(z.B. relational)
weitere externe
Datensichten
externe
Ebene
konzeptionelle
Ebene
physische, interne
Ebene
Figur 3: 3-Schema-Modell nach ANSI-SPARC
Diese Gliederung des Datenmodells ist in den folgenden Kapiteln entscheidend. Vorerst wird
einzig von der konzeptionellen Ebene Gebrauch gemacht, in welcher das konzeptionelle Datenmodell erstellt wird. Erst anschliessend wird, nach der Erklärung der Arbeitsweise von Datenbanksystemen, gezeigt, wie dieses konzeptionelle Modell in ein internes Modell abgebildet wird.
Die Dreiteilung des Datenmodells wurde auch in viele Modellierungsmethoden als fester Bestandteil integriert.
Im folgenden Bild werden die unterschiedlichen Datenmodelle der verschiedenen Ebenen an
einem einfachen Beispiel gezeigt:
Teil 1: Einführung
21
externe Datensichten:
Kunden
Artikel
Aufträge
Aufträge
Auftragspositionen
konzeptionelles
Datenm odell:
Kunden
Artikel
Aufträge
Rechnungen
Auftragspositionen
physisches, internes
Datenm odell:
Kunden
Artikel
Aufträge
Rechnungen
Auftragspositionen
Figur 4: 3-Schema-Modell mit Beispielmodellen
Die externen Sichten erlauben dabei eine völlig individuelle Sicht auf die Daten. So könnte z.B.
die zweite externe Sicht in Tabellenform dem Benutzer oder Entwickler wie folgt präsentiert werden:
Aufträge
Auftrags#
254301
254301
254302
244692
244692
Kunden#
1
1
1
2
2
Artikel#
2531
7121
4623
2644
4623
Bestellmenge Bezeichnung
1,00
1,00
2,00
25,00
1,00
Monitor XP 34-3
Monitor XP 34-4
Tastatur HG/3
Diskette XDS
Tastatur HG/3
Tabellen 2: Externe Sicht in Tabellendarstellung
 Stellenweise wird gefordert, dass die interne Ebene eine weitere Gliederung erhalten soll, da in
dieser Ebene Aspekte des Datenbanksystems auf der einen Seite und Aspekte des Betriebssystems und der Hardware auf der anderen Seite vermischt werden. Diese weitere VerTeil 1: Einführung
22
feinerung wird in den späteren Kapiteln nicht weiter berücksichtigt, da im folgenden nur allgemein Bezug auf Betriebssysteme und Hardware genommen werden kann. Auch spielt die Verteilung der Daten auf mehrere Datenbanksysteme eine zunehmend wichtige Rolle, so dass
auch dieser Teilaspekt bei der Herleitung des internen Schemas berücksichtigt werden muss.
3.3. Begriff und Zielsetzung der Datenmodellierung
In der Datenmodellierung wird festgelegt, wie die Daten einer Anwendung konzeptionell strukturiert werden, wie diese Datenstruktur mittels eines Datenbanksystems physisch organisiert wird
und wie diese Daten dem Benutzer präsentiert werden. In diesem Vorgang müssen verschiedene, zum Teil in sich widersprüchliche Zielsetzungen und Bedürfnisse befriedigt werden,
z.B.:
 Das Datenmodell muss die notwendigen Informationen der Anwendung vollständig
darstellen können; dabei ist die Bestimmung der Systemgrenzen wichtig.
 Mit den gespeicherten Informationen im Datenmodell müssen sämtliche Funktionen
(logische Datenbanktransaktionen, Geschäftsprozesse) der Anwendung ausführbar
sein. Eine Modellierung ohne jegliche Kenntnis der grundsätzlich gewünschten Funktionalität der Anwendung kann daher kein zweckmässiges Datenmodell liefern.
 Das Datenmodell soll derart gebildet werden, dass auch zukünftige Bedürfnisse befriedigt werden können.
 Antwortzeiten und Datenmengen des Systems sind von Fall zu Fall ebenfalls zu
berücksichtigen.
Das Erstellen eines Datenmodells kann daher kein fest vorgegebener, streng mathematischer
Ablauf sein. Es ist viel mehr ein kreativer Prozess, in welchem die Abstraktion eine wichtige Rolle
spielt und in welchem immer und immer wieder die Vor- und Nachteile unterschiedlicher Lösungsansätze verglichen werden. Der Datenmodellierer muss daher über Kreativität, Abstraktionsvermögen, Ausdauer und Erfahrungen über Vor- und Nachteile unterschiedlicher Lösungsvarianten verfügen.
Aus den vorhergehenden Erläuterungen geht auch hervor, dass es kein Standarddatenmodell
geben kann, welches die Bedürfnisse einer bestimmten Branche unternehmensspezifisch abdeckt. Bei der Verwendung von Standarddatenmodellen stellen sich die selben Probleme, wie
beim Einsatz von Standardsoftware. Das Standarddatenmodell sollte den entsprechenden Bedürfnissen des Unternehmens angepasst werden.
3.4. Datenmodellierung als Teil des Informatikprojektes
Die Datenmodellierung ist meist Teil eines Informatikprojektes. Die Bildung des Datenmodells
müsste daher korrekterweise im Umfeld eines Informatikprojektes dargestellt werden. Darauf
wird in den folgenden Kapiteln aber verzichtet. Die Beschreibung der Datenmodellierung kann
dadurch wesentlich kompakter und zielstrebiger erfolgen.
Als Nachteil ergibt sich, dass die Berücksichtigung der durch das Datenmodell zu realisierenden
logischen Funktionen (logische Datenbanktransaktion, Geschäftsprozesse) vernachlässigt wird
und dadurch der Eindruck entstehen könnte, Datenmodellierung müsse die zu realisierenden
Funktionen nicht kennen. In Tat und Wahrheit werden beim Modellieren im Hinterkopf aber immer auch diese Funktionen berücksichtigt. Ausserdem werden in den gezeigten Beispielen immer Freiräume offen bleiben, da nicht die gesamten notwendigen Informationen vorhanden
sind und bei Problemen kein Anwender die offenen Fragen beantworten kann.
Teil 1: Einführung
23
3.5. Checkfragen
Die Lösungen zu den folgenden Checkfragen finden Sie auf Seite 154.
1.
Die Ebene des 3-Schema-Konzepts des ANSI-SPARC-Komitees, in welcher die Leistung des
DBMS bzw. der Anwendung wesentlich beeinflusst wird, ist...





A)
B)
C)
D)
E)
die externe Ebene.
die konzeptionelle Ebene.
die interne Ebene.
keine der Ebenen.
alle Ebenen.
1.
Für das konzeptionelle Datenmodell sind leistungsbestimmende Überlegungen nicht erwünscht bzw. notwendig, weil der Benutzer bei der Entwicklung des konzeptionellen Modells einbezogen wird.
 A)
2.

C) +/-

D) -/+

E) -/-
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
Die externe Ebene wird auch Benutzersicht (View) genannt, weil der Benutzer die Daten
sieht, wie sie physisch gespeichert sind.
 A)
5.
B) +/+
Das konzeptionelle Datenmodell soll frei von technischen Details sein, weil das interne Datenmodell sich nicht aus dem konzeptionellen Datenmodell ableiten lässt.
 A)
4.

Im konzeptionellen Datenmodell wird nicht auf die Datenmengen geachtet, weil erst im
physischen Design (internes Datenmodell) die Datenstruktur mit Hilfsorganisationen zur Ablaufbeschleunigung ergänzt wird.
 A)
3.
+weil+
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
Das konzeptionelle Datenmodell ist Grundlage für die Ableitung der physischen und externen Datenstrukturen, weil das konzeptionelle Datenmodell neutral gegenüber Einzelanwendungen und deren lokaler Sicht ist.
 A)
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
1.
Zählen Sie die Merkmale des konzeptionellen Datenmodells auf:
+








Berücksichtigt Hardwareüberlegungen
Nach Ablauf dieser Phase steht das endgültige Datenbankdesign fest
Dient als Grundlage für Entwurf und Betreuung der übrigen Schemata
Realisiert eine erste Stufe der Zugriffsbefugnisse
Teil 1: Einführung
25
Teil 2:
Konzeptionelle
Datenmodellierung
27
Beim Erstellen des konzeptionellen Datenmodells werden in sämtlichen Modellierungsmethoden
wenige, einfache Elementarinstrumente verwendet. Einzelne Methoden bilden daraus dann
weitere Grundstrukturen in ihrer Methodik. In diesem Abschnitt sollen vier Elementarinstrumente
sowie deren Bedeutung eingeführt werden. Die Elementarinstrumente sind die Elemente zur Bildung der Datenstruktur (gleich Datenmodell). Die Begriffe Elementarinstrument und Verbundinstrument, wie sie später eingeführt werden, sind keine in der Datenmodellierung üblicherweise
verwendeten Begriffe. Sie eignen sich aber dazu, den Sachverhalt besser zu gliedern, um damit
die dahinterliegenden Konzepte besser zu verstehen.
Die im folgenden Kapitel eingeführten vier Elementarinstrumente finden sich auch im EntityRelationship-Modell (zu Deutsch etwa: Entitäten-Beziehungs Modell). Diese Begriffe werden im
Folgenden immer dann verwendet, wenn sich die Ausführungen auf die konzeptionelle Ebene
(siehe '3.2. Gliederung des Datenmodells gemäss ANSI-SPARC' auf Seite 19) beziehen. Die Tabelle '13.2. Synonyme unterschiedlicher Systeme und Modelle' auf Seite 148 erleichtert Ihnen den
Einstieg, falls Sie diese Begriffe noch nicht kennen, aber mit einer anderen Systematik vertraut
sind.
Die Elementarinstrumente Wertebereich und Attribut werden in Unterkapiteln zusätzlich nach
bestimmten Eigenschaften charakterisiert. Bei dieser Charakterisierung werden Eigenschaften,
welche Teil des relationalen Modells sind, verwendet. Diese Typen erlauben ein grundlegenderes Verständnis des konzeptionellen Modells, sind in der Praxis verbreitet, sind Grundlage für die
nachfolgende Normalisierung und erleichtern anschliessend die Herleitung des internen Modells. Dies ist Grund genug, diese bereits an dieser Stelle einzuführen.
4.1. Entität, Entitätsmenge
Eine Entität (Englisch: Entity) ist ein einzelnes, in sich geschlossenes Objekt (Synonyme: Record,
Tupel, Datensatz). Eine einfache, einleuchtende Definition ist schwierig, da eine klare Abgrenzung zu den anderen Instrumenten zum Teil schwer fällt und erst im konkreten Fall entschieden
werden kann, was Entität ist und was nicht (dies wird im Weiteren noch besser verständlich).
Häufig ist jedoch sofort klar, was in einem konkreten Projekt Entitäten sind. Mittels Beispielen von
möglichen Entitäten soll der Begriff näher erläutert werden:
 Person: Der Kunde mit Kundennummer K-003432, namens Müller Rolf
 Reales Objekt: Die Aktie der Firma ISAG mit Nummer 023453
 Abstraktes Objekt: Das Aktiendepot mit Nummer DP-Akt-005625 des Kunden
K-003432
 Ereignis: Der Kauf der Aktie Nr. 023453 für den Kunden K-003432
 Entität: Eine Entität ist ein in sich geschlossenes Ding, für welches bestimmte Eigenschaften (Daten) gelten. Entitäten müssen mittels bestimmter Eigenschaften
eindeutig identifiziert werden können.
Bei der Modellierung werden nicht die einzelnen Entitäten dargestellt (was vollständig auch gar
nicht möglich wäre), sondern es werden Mengen aus Entitäten gleicher Art gebildet, sogenannte Entitätsmengen (Englisch: Entity Set). Unseren Beispiel-Entitäten werden Entitätsmengen zugeordnet:
 Personen: Kunden
 Reale Objekte: Aktien
 Abstrakte Objekte: Aktiendepots
 Ereignisse: Aktienkäufe
28
 Entitätsmenge: Eine Entitätsmenge ist eine Menge von Entitäten, welche die selben
Eigenschaften aufweisen.
Die Entitätsmengen werden im grafischen Modell als Rechtecke dargestellt:
Kunden
Figur 5: Darstellung von Entitätsmengen
In der Praxis werden die Begriffe Entität und Entitätsmenge leider häufig als Synonyme verwendet. Eine klare Trennung der Begriffe ist aber zweckdienlich, da z.B. eine Schulklasse eine
einzelne Entität sein kann, aber auch eine Entitätsmenge, nämlich eine Menge von Schülern. Im
zweiten Fall ist der Schüler die Entität.
Auch die Namensgebung (Entitätsmengen werden im Modell benannt) ist nicht einheitlich. So
werden Entitätsmengen im Singular (z.B. Kunde, Aktie, ...) aber auch im Plural (z.B. Kunden, Aktien, ...) benannt. Dies hat aber auf das Verständnis des Datenmodells meist wenig Einfluss.
Wichtig für das Verständnis ist hingegen die Wahl eines sinnvollen, ausdrucksvollen Namens für
die Entitätsmenge. Im Folgenden wird immer die Pluralform verwendet, da diese weniger missverständlich ist.
Entitäten und Entitätsmengen können zusätzlich als unabhängige oder abhängige Entitäten
bzw. Entitätsmengen klassifiziert werden. Eine abhängige Entität ist von der Existenz einer anderen Entität abhängig, kann also nur dann existieren, wenn diese referenzierte Entität auch existiert. Eine abhängige Entitätsmenge ist eine Menge von abhängigen Entitäten gleicher Art. Als
Beispiel für eine abhängige Entität kann z.B. das Aktiendepot DP-Akt-005625 dienen. Es darf nur
dann im System existieren, wenn diesem ein Kunde (Eigentümer) zugeordnet ist (Depots ohne
Eigentümer gibt es nicht). Unterschiedliche Datenmodelle haben weitere Methoden zur Klassifizierung der Entitätsmengen entwickelt, diese lassen wir zunächst ausser Betracht. Später werden
wir Entitätsmengen und die sie umgebenden Entitätsmengen betrachten und hierbei eine weitere Klassifizierung vornehmen.
4.2. Beziehung, Beziehungsmenge
Bisher sind die Entitätsmengen ohne Verknüpfung zueinander dargestellt worden. Mittels Beziehungen (Beziehungsmengen = Menge aus Beziehungen der selben Art) werden diese Verknüpfungen im Datenmodell dargestellt. So wird zum Beispiel festgehalten, dass einem Depot
immer ein Kunde zugeordnet ist und ein Kunde mehrere Depots haben kann.
Leider findet man in der Praxis zwei voneinander abweichende Varianten zur Darstellung der
Beziehungen zwischen den Entitätsmengen. In den folgenden zwei Unterkapiteln werden diese
beiden Varianten erläutert.
4.2.1. Die Beziehung im Entity-Relationship-Modell
Die Beziehungsmenge (Englisch: Relationship Set; der Begriff Relation wird im relationalen Modell für Entitätsmengen verwendet und wird daher im Entity-Relationship-Modell vermieden)
stellt die Verknüpfung zwischen zwei oder mehr Entitätsmengen her. So wird z.B. mittels der Beziehungsmenge 'Depotinhalt' festgehalten, welche Aktien im Depot (eines Kunden) abgelegt
sind (siehe Figur unten). Andererseits ist damit auch festgehalten, in welchen Depots eine bestimmte Aktie abgelegt ist. Entitätsmengen werden nicht direkt miteinander verbunden, sondern werden immer und ausschliesslich mittels einer Beziehungsmenge verknüpft. Zusätzlich wird
festgehalten, wie viele Entitäten der einen Entitätsmenge einer Entität der anderen Entitätsmenge zugeordnet sind (und umgekehrt, Notation wird später erläutert). Grafisch werden Entitätsmengen als Rechtecke, Beziehungsmengen als Rhomben dargestellt.
29
Sachbearbeiter
betreuen
Betreuung
betreut
durch
Kunden
besitzen
KundenDepots
gehören
Depots
Aktien
deponiert
in
enthalten
Depotinhalt
Figur 6: Datenmodellgrafik im Entity-Relationship-Modell
So wird z.B. in unserem Mini-Modell festgehalten, dass:
ein Sachbearbeiter einen oder mehrere Kunden betreuen kann
ein Kunde durch keinen oder einen Sachbearbeiter betreut werden kann
ein Kunde kein, ein oder mehrere Depots besitzen kann
ein Depot genau zu einem Kunden gehört
ein Depot keine, eine oder mehrere Aktien beinhalten kann
eine Aktie in keinem, einem oder mehreren Depots deponiert sein
kann
Im Entity-Relationship-Modell wird auch der Begriff Rolle (Englisch: Role) geführt. Die Rolle einer
Entitätsmenge in einer Beziehung hält fest, welches der Verwendungszweck der Entitätsmenge
in der Beziehung ist. So nimmt die Entitätsmenge 'Aktien' in der Beziehung mit der Beziehungsmenge 'Depotinhalt' die Rolle 'ist deponiert in' wahr. Die Linien zwischen den Entitäts- und Beziehungsmengen repräsentieren somit die Rollen der Entitätsmengen in den Beziehungen und
werden entsprechend ihrer Rolle beschriftet. Die Benennung der Rolle ist in der Praxis häufig
mangelhaft. Auf die Benennung der Rolle kann verzichtet werden, falls sich die Rolle aus dem
Zusammenhang ergibt, muss aber immer dann erfolgen, wenn diese nicht a priori klar ist. Die
konsequente Vergabe von Rollennamen ist sicher die beste Variante. Der Rollenbegriff wird, wie
noch gezeigt wird, auch in anderen Zusammenhängen verwendet.
Um die Verständlichkeit des grafischen Datenmodells zu erhöhen (gilt für beide BeziehungsDarstellungsmethoden), ist es vorteilhaft, die Entitätsmengen derart zu platzieren, dass die Entitätsmengen hierarchisch angeordnet sind. Der routinierte Datenmodellierer kann ein derart gestaltetes Datenmodell schneller lesen.
30
4.2.2. Erweitertes Relationenmodell, Beziehungs-Variante des EntityRelationship-Modells
Eine verbreitete und wichtige Änderung im Entity-Relationship-Modell ist jene, in welcher nicht
zwischen Entitätsmengen und Beziehungsmengen differenziert wird (entsprechende Modelle
sind auch unabhängig vom Entity-Relationship-Modell entwickelt worden). Beziehungsmengen
werden hier als normale Entitätsmengen behandelt, der Begriff Beziehungsmenge existiert genau genommen nicht mehr. Grundsätzlich könnte das Datenmodell noch zu jenem in der ursprünglichen Variante identisch dargestellt werden, abgesehen davon, dass Beziehungsmengen nicht mehr als Rhomben dargestellt werden. Technisch ist es aber möglich, Beziehungen
zwischen Entitätsmengen direkt herzustellen. Es wird daher (in Voraussicht des internen Schemas) gänzlich darauf verzichtet, die ursprünglichen Beziehungsmengen im Modell darzustellen,
vielmehr werden die einzelnen Entitätsmengen direkt miteinander verbunden. Wie später noch
gezeigt wird, ist aber von der Verwendung von direkten 'Mehrfach- zu Mehrfach-Beziehungen'
abzuraten (Normalisierung). Bei diesen Beziehungen wird daher die ursprüngliche Beziehungsmenge nicht eliminiert. Diese Entitätsmengen werden in der Praxis aufgrund ihrer Bedeutung
häufig dennoch als Beziehungsmenge bezeichnet, obgleich der Begriff Beziehungsmenge nicht
mehr eindeutig definiert ist. Diese Variante des Entity-Relationship-Modells wird im Folgenden in
Anlehnung an [Zehnder 89] erweitertes Relationenmodell bezeichnet. Es orientiert sich stark am
relationalen Modell.
Sachbearbeiter
betreuen
Kunden
besitzen
Depots
Aktien
deponiert
in
enthalten
Depotinhalt
Figur 7: Datenmodellgrafik im erweiterten Relationenmodell
Der Begriff der Rolle, wie er im Entity-Relationship-Modell eingeführt wurde, kann in dieser Variante nicht mehr in der selben Form verwendet werden. Die Linie, welche die Entitätsmengen
verbindet, wird hier als Beziehung bezeichnet. Im grafischen Datenmodell kann die Beziehung
(wie vorher die Rolle) mit einer Bezeichnung ergänzt werden, um die Verständlichkeit zu erhöhen.
4.2.3. Vor- und Nachteile beider Ansätze
Die konsequente Verwendung von Beziehungsmengen im Entity-Relationship-Modell zum Verknüpfen von Entitätsmengen hat folgende Vor- und Nachteile:
 Das Datenmodell ist aussagekräftiger.
 Das Datenmodell nimmt keinerlei Bezug auf ein bestimmtes Datenbanksystem, ist
daher wirklich rein konzeptionell.
31
 Die Zahl der Modellierungs-Instrumente und die Anzahl der Elemente im Datenmodell ist grösser und damit unübersichtlicher.
 Die Modellierung ohne Differenzierung zwischen normalen Entitäts- und Beziehungsmengen entspricht der Denkart des relationalen Ansatzes. Die Herleitung der physischen Speicherorganisation (internes Schema) für ein relationales Datenbanksystem
ist daher bei der Modellierung mit Differenzierung geringfügig komplizierter.
 In der Praxis ist es nicht immer einfach zu entscheiden, ob es sich nun tatsächlich um
eine Beziehungsmenge handelt oder ob es nicht vielleicht doch eine Entitätsmenge
ist. Stellenweise wird dieser Konflikt behoben, indem Entitätsmengen erlaubt sind, die
beides gleichzeitig sind (grafisch: Rhombus innerhalb Rechteck).
Die Vor- und Nachteile der beiden Varianten fallen kaum ins Gewicht, so dass der Entscheid für
oder gegen einen der beiden Ansätze schwer fällt. Tröstlich ist der Umstand, dass Modelle, erstellt in einem der beiden Ansätze, immer ohne Schwierigkeiten in den anderen Ansatz umgesetzt werden können. Im Folgenden werden beide Ansätze fallweise verwendet, so dass der Leser im Umgang mit beiden Ansätzen vertraut wird.
4.2.4. Assoziationstypen, Beziehungstypen
Wie oben schon ersichtlich wurde, und dies gilt für beide Ansätze, wird für jede Beziehung bzw.
Beziehungsmenge angegeben, in welchem Mengenverhältnis die Entitätsmengen zueinander
stehen. In der Praxis haben sich folgende vier Mengenangaben (Assoziationstypen) durchgesetzt:
 einfache Assoziation (genau eine): Einer Entität aus der Entitätsmenge A ist genau
eine Entität aus der Entitätsmenge B zugeordnet, z.B. ist einem Aktiendepot genau
ein Kunde zugeordnet.
 konditionelle Assoziation (keine oder eine): Einer Entität aus der Entitätsmenge A ist
keine oder eine Entität aus der Entitätsmenge B zugeordnet, z.B. ist einem Kunden
kein oder ein Sachbearbeiter zugeordnet.
 multiple Assoziation (eine oder mehrere): Einer Entität aus der Entitätsmenge A sind
eine oder mehrere Entitäten aus der Entitätsmenge B zugeordnet, z.B. sind einem
Sachbearbeiter ein oder mehrere Kunden zugeordnet.
 multipel-konditionelle Assoziation (keine, eine oder mehrere): Einer Entität aus der
Entitätsmenge A sind keine, eine oder mehrere Entitäten aus der Entitätsmenge B zugeordnet, z.B. sind einem Kunde kein, ein oder mehrere Aktiendepots zugeordnet.
Zur Angabe der Assoziationstypen (Mengenverhältnisse) in grafischen Modellen haben sich
mehrere Notationen durchgesetzt. Diese sind inhaltlich aber praktisch identisch, so dass eine
Umsetzung von einer Notation zur anderen i.d.R. durch einfache Neubeschriftung erfolgt. Die
folgende Tabelle zeigt einige in der Praxis verwendete Notationen:
genau eine
keine oder
eine
eine oder
mehrere
keine oder
mehrere
1
c
m
mc
1,1
0,1
1,m
0,m
Tabelle 3: Assoziationstypen und Notationen
Bisher wurde die Beziehung nur ausgehend von einer Entitätsmenge betrachtet. Dies ist allerdings erst ein Teil der gesamten Beziehung, die umgekehrte Sichtweise ist ebenfalls Teil der BeTeil 2: Konzeptionelle Datenmodellierung
32
ziehung. Der gerichtete Teilaspekt der Gesamtbeziehung wird Assoziation genannt. Eine einzelne Mengenangabe in der Datenstruktur entspricht daher der Assoziation. Die Beziehung
selbst ergibt sich aus der Summe ihrer Assoziationen. Verwendet man die vier Assoziationstypen,
lassen sich daraus 10 Beziehungstypen herleiten:
1
1:1
c
1:c
c:c
m
1:m
c:m
m:m
mc
1:mc
c:mc
m:mc
mc:mc
1
c
m
mc
Tabelle 4: Beziehungstypen
Die 'leeren' Tabellenzellen sind in der Tabelle bereits vorhanden (symmetrisch). Vier dieser zehn
Beziehungstypen treten aber überhaupt nicht auf (blau unterlegte Felder):
 Die 1:1-Beziehung ergibt mit einer Ausnahme im konzeptionellen Modell keinen Sinn,
da die entsprechenden Entitätsmengen zu einer einzigen Entitätsmenge zusammengefasst werden können, was in der Praxis wenn immer möglich durchgeführt werden sollte. Nur falls eine einzelne Entitätsmenge rekursiv mit sich selbst verknüpft wird,
ist die 1:1-Beziehung sinnvoll (siehe ‘6.3. Rekursion’ auf Seite 61).
 Wie weiter oben bereits erwähnt, sind m:m-, aber auch m:mc- und mc:mc-Beziehungen aufgrund einer Normalisierungsregel (2. Normalform) verboten und
müssen daher auch im erweiterten Relationenmodell mittels einer Beziehungsmenge gestaltet werden.
Woher rührt dieser Unterschied vom Entity-Relationship-Modell zum erweiterten Relationenmodell (zweiter Aufzählungspunkt)? Der Ursprung ist lediglich aufgrund der unterschiedlichen Definition des Begriffs Beziehung zustandegekommen. Genau genommen handelt es sich bei einer
Beziehung im Entity-Relationship-Modell im Sinne des erweiterten Relationenmodells um zwei Beziehungen.
Depots
Aktien
deponiert
in
enthalten
Depotinhalt
Figur 8: Beschriftung des ER-Modells aufgrund des erweiterten Relationenmodells
Dabei handelt es sich im Entity-Relationship-Modell, aus Sicht des erweiterten Relationenmodells, immer um 1:-Beziehungen, d.h. der zweite Punkt der obigen Aufzählung kann gar nicht
auftreten. Aus den 10 Beziehungstypen verbleiben im Sinne des erweiterten Relationenmodells
also lediglich 6 Beziehungstypen (in der Matrix grün hinterlegt). Die restlichen Beziehungstypen
dürfen in der konzeptionellen Datenstruktur nicht direkt auftreten, sondern müssen immer mittels
einer Beziehungsmenge gebildet werden. Im Sinne des Entity-Relationship-Modells verbleiben 9
Beziehungstypen, lediglich die 1:1-Beziehung macht meist keinen Sinn, die anderen Beziehungstypen sind eigentlich bereits aufgelöst.
Beim Auflösen von verbotenen m:m-Beziehungstypen im erweiterten Relationenmodell kann
immer auf die selbe Art verfahren werden. Es wird eine zusätzliche Beziehungsmenge (wie beim
Entity-Relationship-Modell) eingefügt, die beiden Assoziationstypen werden übers Kreuz ausgetauscht und die neuen Assoziationstypen vom Typ 'genau eine' eingetragen:
unerwünschte
m:mc-Beziehung
Depots
Aktien
Depots
Aktien
33
aufgelöste
m:mc-Beziehung
Depotinhalt
Figur 9: Auflösung verbotener m:m-Beziehungstypen
 Stellenweise wird in der Theorie auch gefordert, dass c:c-, c:m- und c:mc-Beziehungen im erweiterten Relationenmodell nicht direkt realisiert werden dürfen. Diese Beziehungstypen sollten im
konzeptionellen Datenmodell ebenfalls mittels einer Beziehungsmenge aufgelöst werden. Diese
berechtige Forderung rührt daher, dass bei diesen Beziehungstypen Entitäten auftreten können,
welche ohne Referenz sind, d.h. eine leere Referenz aufweisen. Wie aber soll festgestellt werden, ob eine Entität referenziert wird oder nicht? Diese Frage muss aber eindeutig beantwortet
werden können, denn nur so kann sichergestellt werden, dass eine allfällige Referenz auch tatsächlich korrekt ist. In der Praxis wird in der Regel angenommen, dass ein Fremdschlüssel keine
Entität referenziert, falls ein Fremdschlüsselattribut den Wert NULL enthält.
 Für den konkreten Fall muss daher bei diesen Beziehungstypen definiert werden, in welcher
Situation eine Entität referenziert wird und in welcher nicht. Diese Frage muss bei der Herleitung
des internen Schemas unter Berücksichtigung des Zieldatenbanksystems geklärt werden. Hierfür
kann allenfalls ein entsprechendes Attribut eingeführt werden. Im Folgenden sollen diese Beziehungstypen im konzeptionellen Modell erlaubt sein, bei der Herleitung des internen Modells müssen diese aber noch gründlich analysiert werden.
 Meist kann das Problem mit diesen Beziehungstypen auch dadurch sinnvoll aufgelöst werden,
dass die Entitätsmenge, welche den Fremdschlüssel enthält, weiter verfeinert wird. Denn eigentlich wurden zwei oder sogar mehr Entitätstypen (solche mit und solche ohne Referenz) in einer
einzigen Entitätsmenge vereint. Im Beispiel besteht zwischen Kunde und Sachbearbeiter eine
m:c-Beziehung. Diese kann durch eine Beziehungsmenge oder durch die Spezialisierung (siehe
'6.5. Spezialisierung/Generalisierung' auf Seite 64) in Beratungskunden (mit Sachbearbeiter) und
Normalkunde (ohne Sachbearbeiter) aufgelöst werden.
4.2.5. Verhalten bei Datenbank-Transaktionen
Die Beziehungstypen halten fest, wie die Entitätsmengen zueinander in Beziehung stehen, aber
sie geben nicht an, wie im Falle einer Datenbank-Transaktion reagiert werden soll. Wie soll das
Datenbanksystem z.B. reagieren, falls ein Kunde gelöscht werden soll, der noch ein gefülltes Aktiendepot besitzt? Damit muss für Transaktionen, in welchen referenzierte Daten gelöscht werden oder in welchen der referenzierte Entitätsschlüssel geändert wird, angegeben werden, wie
das Datenbanksystem bzw. die Anwendung reagieren soll. In der Literatur sind meist drei mögliche Verhaltensvarianten für die beiden Fälle angegeben:
34
Löschung der referenzierten Entitätsmenge
Änderung des referenzierten Entitätsschlüssels
Weiterleiten
(cascades)
Die untergeordneten Entitäten
werden ebenfalls gelöscht.
Die Fremdschlüssel der untergeordneten Entitäten werden ebenfalls geändert.
Verhindern (restricted)
Falls untergeordnete Entitäten
existieren, wird der Löschvorgang
verhindert.
Falls untergeordnete Entitäten
existieren, wird die Änderung des
Entitätsschlüssels verhindert.
Loslösen (nullifies)
Die Fremdschlüssel der untergeordneten Entitäten werden auf
NULL gesetzt.
Die Fremdschlüssel der untergeordneten Entitäten werden auf
NULL gesetzt.
Tabelle 5: Referentielle Integrität und Datenbank-Transaktionen
Allerdings sind die Beziehungstypen und das Fremdschlüsselverhalten nicht ganz unabhängig
voneinander. So muss es sich, falls das Fremdschlüsselverhalten 'Loslösen' definiert ist, immer um
eine c:-Beziehung (=beliebig) handeln, so dass der Fremdschlüssel auch tatsächlich NULLWerte annehmen kann. In der Datenstruktur könnten die Beziehungen mit dem Beziehungstyp,
deren Rollen und dem Fremdschlüsselverhalten versehen werden. In den meisten Datenmodellen ist die Erweiterung um das Fremdschlüsselverhalten nicht vorgesehen, es werden nur der Beziehungstyp und die Rollen angegeben.
4.3. Wertebereich
Der Wertebereich definiert die erlaubten Werte, welche eine bestimmte Eigenschaft (z.B. Alter,
Geschlecht, Zivilstand) einer Entität einnehmen können. Synonyme von Wertebereich sind Domäne und Datentyp. Beispiele für Wertebereiche für die Entitätsmenge Kunde:
 Alter:
0..150
 Geschlecht:
'männlich', 'weiblich'
 Rechtsform:
'natürliche Person', 'Aktiengesellschaft', 'Einzelfirma', 'Verein'
Dabei können die selben Wertebereiche natürlich von mehreren Entitätsmengen gleichzeitig
verwendet werden. So können sämtliche oben aufgeführten Wertebereiche auch von der Entitätsmenge Sachbearbeiter verwendet werden.
4.3.1. Elementarer Wertebereich
In der Praxis werden abhängig vom Datenbanksystem bestimmte elementare Wertebereiche
vorgegeben. Häufig werden folgende Wertebereiche durch das Datenbanksystem zur Verfügung gestellt:
 ganze Zahlen (Integer)
 reelle Zahlen (Real, Float, Numeric)
 Zeichenketten (Charakter, String)
 Wahrheitswerte, logische Variablen mit den Werten 'wahr' und 'falsch' (Boolean: benannt nach dem Logiker und Mathematiker George Bool, 1815 bis 1864)
 Uhrzeit (Time)
 Datum (Date)
Dabei wird in aller Regel für Zahlen und Zeichenketten bei der Definition der Variablen auch
angegeben, wie viele Stellen geführt werden sollen (z.B. 'REAL 6.3', d.h. hier 6 Stellen vor und 3
35
Stellen nach dem Komma). Für diese elementaren Wertebereiche stehen eine Reihe von praktischen Rechenoperationen zur Verfügung. So könnte z.B. berechnet werden, welches Datum
heute in 30 Tagen ist: 'Datum := Heute_Datum + 30'.
4.3.2. Strukturierter Wertebereich 
Mittels elementarer Wertebereiche werden für die gängigsten Wertebereiche deren Definition
sowie dazugehörige Operationen vom Datenbanksystem vordefiniert. In der Praxis ist es zur
Steigerung der Software- und Datenqualität und zur Vereinfachung der Programmierung häufig
wünschenswert, diese mittels selbstdefinierter Wertebereiche (= strukturierte Wertebereiche) zu
ergänzen. Zur Definition strukturierter Wertebereiche stehen mehrere Methoden zur Verfügung;
die wichtigsten Methoden im Datenbankbereich sind:
 Unterbereich: Hier wird der Wertebereich von einem definierten Wertebereich mittels Angabe einer unteren und oberen Grenze, abgeleitet. So kann z.B. der Wertebereich 'Alter' als Unterbereichstyp vom Wertebereich 'Integer' mit der unteren
Grenze 0 und der oberen Grenze 150 definiert werden.
 Aufzählungstyp: Die erlaubten Werte werden mittels Aufzählung definiert. So wurde
im Beispiel oben der Wertebereich 'Geschlecht' durch die beiden Werte 'männlich',
'weiblich' definiert.
 Wiederholungsgruppe: Bei der Wiederholungsgruppe (auch Feldtyp, Array oder Indextyp) können einer Variablen mehrere Werte des selben Wertebereichs zugeordnet werden. So kann z.B. beim Kunden in einem Wertebereich Beratungsdatum
vom Typ Datum[1:4] festgehalten werden, welches die Daten der letzten 4 Beratungsgespräche waren. Der Zugriff auf einen bestimmten Eintrag erfolgt dabei
durch Angabe der Indexnummer. Es sind auch Wertebereiche möglich, die mehr als
eine Dimension aufweisen, z.B. Betrag[1:2,1:12].
Wie später noch gezeigt wird, sind in der konzeptionellen Datenmodellierung Wiederholungsgruppen verboten (Normalisierung). Beim Herleiten des internen Schemas stellen Wiederholungsgruppen aber eine äusserst interessante Möglichkeit zur
Performance-Verbesserung dar. Datenbanksysteme, welche Wiederholungsgruppen zulassen, bieten daher eine wichtige Variante zur Performance-Steigerung.
 Redefinition bzw. varianter Verbund: In vielen Programmiersprachen ist es möglich,
den selben Speicherbereich mit unterschiedlichen Wertebereichen zu redefinieren.
Hiermit kann ein und die selbe Information in mehreren Variablen mit unterschiedlichen Wertebereichen ohne Typumwandlung verwendet werden. So kann
z.B. die Kundennummer 'K-003432' als Charakter 8, oder als zwei Variablen mit den
Wertebereichen Charakter 2 ('K-') und Integer 6 (3432) verwendet werden.
Diese Technik wird beim Erstellen kommerzieller Systeme häufig eingesetzt. Der
Einsatz dieser Technik ist praktisch, aber auch gefährlich. So muss einerseits
sichergestellt sein, dass die innere Struktur der Daten nicht geändert wird, andererseits muss genau bekannt sein, wie das System die internen Daten in die unterschiedlichen Formate umwandelt.
4.3.3. NULL-Werte
Häufig ist für eine Variable deren Wert nicht bekannt, so dass bis zur Eintragung eines korrekten
Wertes ein ungültiger Wert gespeichert wird. So kann z.B. beim Kunden zunächst unklar sein, um
welche Rechtsform es sich handelt und erst nach weiteren Abklärungen kann die Rechtsform
angegeben werden. Um in Abfragen und Programmen dennoch zu erkennen, dass kein gültiger Wert vorhanden ist, werden sogenannte Standardwerte eingetragen, welche diesen ungültigen Zustand repräsentieren. So könnte zum Beispiel im Wertebereich Rechtsform der Wert 'unbekannt' und im Wertebereich 'Alter' der Wert -1 oder 999 zum Festhalten des Umstandes 'Alter
nicht bekannt' verwendet werden. Diese Arbeitsweise hat sich allerdings als unbefriedigend erTeil 2: Konzeptionelle Datenmodellierung
36
wiesen, da diese Werte in sämtlichen Abfragen und Programmen dem Anwender bekannt sein
müssen und zudem bei Änderungen des Wertebereichs der Standardwert nachträglich unerwartet einen gültigen Wert repräsentieren kann.
Es hat sich daher schon in Dritt-Generationssprachen durchgesetzt, einen derartigen Wert explizit als Teil der Programmiersprachen zu integrieren. Dieser Wert ist dadurch automatisch Teil
sämtlicher Wertebereiche. Die Bezeichnungen dieses Wertes sind in den Datenbanksystemen
unterschiedlich, meist aber NULL (im Folgenden wird immer der Wert NULL verwendet). In den
Abfragen und Programmen muss daher nicht der jeweilige Standardwert gekannt werden, sondern es handelt sich immer um den Wert NULL. Zusätzlich werden sämtliche Operationen des
Datenbanksystems derart erweitert, dass diese auch NULL-Werte verarbeiten können. So muss
insbesondere die Verarbeitung boolscher Variablen so erweitert werden, dass nicht nur die Werte 'wahr' und 'falsch', sondern auch der Wert NULL verarbeitet werden kann. Aus einer 2wertigen Logik (wahr und falsch) ist damit eine 3-wertige Logik (wahr, falsch und unbekannt)
geworden.
 Tatsächlich kann der NULL-Wert noch weiter gegliedert werden. So kann NULL etwa bedeuten,
der Wert ist noch nicht bekannt oder aber für diese Entität wird hier kein Wert eingetragen. Bei
Kunden kann NULL im Wertebereich Rechtsform daher bedeuten, die Rechtsform ist noch nicht
bekannt oder es handelt sich um einen Kunden, dem lediglich Werbung zugesandt wird, die
Rechtsform daher nicht interessiert. Auf diese weitere Gliederung wird verzichtet, da hierdurch
die Operationen des Systems erneut erweitert werden müssten, was auch auf Abfragen und
Programme Einfluss hätte, der Gewinn durch die weitere Verfeinerung aber klein wäre. Später
wird zudem gezeigt, dass bei Entitätsmengen, welche NULL-Werte der Art 'hier wird kein Wert
eingetragen' haben, durch Bildung von Teilmengen diese NULL-Werte verschwinden. In unserem
Beispiel könnte die Entitätsmenge Kunden zusätzlich in die Teilmengen Anlagekunden und Werbekunden gegliedert werden. Jeder der drei Entitätsmengen würden jeweils die entsprechenden Wertebereiche zugeordnet. Der Wertebereich Rechtsform würde im Beispiel nur der Entitätsmenge Anlagekunden zugeordnet.
4.3.4. Typenbindung 
Grundsätzlich können Werte unterschiedlicher Wertebereiche für viele Operationen nicht direkt
miteinander verarbeitet werden. So kann etwa der Wert ' +2.4400' des Wertebereichs Charakter 10 nicht direkt mit dem Wert 2.44 des Wertebereichs Real verglichen werden. Diese Art der
Wertebereichsüberprüfung wird strenge Typenbindung (strongly typed) genannt. Datenbanksysteme erlauben es in der Regel aber, Werte von einem Wertebereich in einen anderen Wertebereich zu überführen, so dass die gewünschte Operation dennoch ausgeführt werden kann.
Diese Umwandlung erfolgt mittels Funktionen, welche vom System zur Verfügung gestellt werden. Z.B. wird häufig die Funktion 'VAL()' verwendet, um Zahlen im Charakter-Format in RealZahlen umzuwandeln. Dieser Umwandlungsvorgang wird semantische Übersteuerung (Semantic
Override) genannt.
4.4. Attribut
Im Attribut werden die Werte eines Wertebereichs den Entitäten einer Entitätsmenge oder Beziehungsmenge zugeordnet. Entsprechend ihrer Herkunft werden sie daher auch Entitätsattribut
oder Beziehungsattribut genannt. So kann im Attribut Geburtsdatum (Attributsname) der Entitätsmenge Kunden zum Beispiel der Wert {23.7.1959} (Attributswert) aus dem Wertebereich Datum abgelegt werden (Synonyme: Feldname, Spalte). Mittels der Attribute wird somit die innere
Struktur der Entitätsmenge definiert. Wurde vorher die Entitätsmenge als Menge aller Entitäten
der selben Art definiert, so kann die Entitätsmenge jetzt als Menge aller Entitäten mit den selben
Attributen (nicht aber Attributswerten) festgelegt werden.
37
Kunden
Attributsname:
Kunden#
Kundenname
GeburtsDatum
Geschlecht
Gesellschaft
LetzteBeratung
...
Wertebereich:
Character 8
Character 30
Datum
Geschlecht
Rechtsform
Datum
Beschreibung:
Kundennummer (z.B. K003432)
Name und Vorname des Kunden
Geburtsdatum des Kunden
Geschlecht des Kunden
Rechtsform des Kunden/Gesellschaft
Datum des letzten Beratungsgespräches
Attributsname:
Wertebereich:
Beschreibung:
Depot#
Kunden#
EröffnungsDatum
SaldierungsDatum
...
Character 20
Character 8
Datum
Datum
Depot-Identifikation (z.B. DP-Akt-005625)
 Kunde.Kunden#, Kundennummer des Eigentümers
Datum der Depoteröffnung
Datum der Depotsaldierung
Depots
Tabellen 6: Auszug des Attributskatalogs der Entitätsmengen Kunden und Depots
Wie bei der Beziehungsmenge, so ist jetzt die Linie, welche die Entitäten mit den Wertebereichen verbindet, die Rolle, welche dem Wertebereich für die entsprechende Entitätsmenge
zugeordnet wird. Dabei kann der selbe Wertebereich durchaus mehrere Rollen in der selben Entitätsmenge erhalten (z.B. die Rollen 'Geburtsdatum des Kunden', 'letztes Datum eines Beratungsgespräches' für den Wertebereich Datum). Der Attributsname ist meist ein Kürzel für die
Rolle des Wertebereichs (z.B. wird der Attributsname 'GeburtsDatum' für die Rolle 'Geburtsdatum
des Kunden' vergeben).
Auf die grafische Darstellung der Attribute und Wertebereiche wird in der Regel verzichtet, da
das Modell dabei 'überladen' würde, wie der kleine Ausschnitt des Datenmodells mit wenigen
Attributen schon zeigt:
Kunden
Be le t
ra zte
tu
ng
sd
a
tum
na
m
e
#
ie r
un
g
sng
ffu tum
Erö d a
Sa
ld
en
en
Datum
besitzen
Ku
nd
nd
Ku
m
a tu n
rtsd nd e
u
b Ku
Ged e s
KundenDepots
gehören
Charakter
o t#
sc G
ha e se
fts llfo
rm
De
p
Rechtsform
KundenGeschlecht
Geschlecht
Depots
Figur 10: Datenmodellgrafik im Entity-Relationship-Modell mit Attributsdarstellung
Meist werden die Attribute der Entitätsmengen lediglich in einem separaten Verzeichnis, dem
Attributskatalog, festgehalten. Die Attributsnamen sollten dabei so gewählt werden, dass der
Inhalt des Attributs daraus abgeleitet werden kann. Namen wie K# anstelle von Kunden# sind
überaus mangelhaft.
38
4.4.1. Entitätsschlüssel, Schlüsselkandidat
Zur Verarbeitung und zum Erstellen der Beziehungen zwischen den Daten muss sichergestellt
sein, dass jede Entität eindeutig identifiziert werden kann. Dabei sollten nicht die technischen
Gegebenheiten der Datenbank (Record-Nummer), welche häufig ebenfalls die Entitäten eindeutig identifizieren, genutzt werden, da sich diese Identifikationen bei Strukturänderungen der
Daten oder bei der Reorganisation ändern können. Es wird daher festgelegt, welches Attribut
bzw. welche Kombination von Attributen, d.h. Attributskombination, eine einzelne Entität eindeutig identifiziert. Dieses Attribut oder Attributskombination wird Entitätsschlüssel, aber auch
Identifikationsschlüssel oder Primärschlüssel genannt. So könnte z.B. das Attribut 'Kunden#' Entitätsschlüssel in der Entitätsmenge Kunden sein. Das oder die Attribute, welche den Entitätsschlüssel bilden, werden als Schlüsselattribute bezeichnet. Schlüsselattribute werden im Attributskatalog in der Regel durch einfaches Unterstreichen des Attributsnamens gekennzeichnet.
Werden mehrere Attribute zur Bildung des Entitätsschlüssels verwendet, so dürfen nur jene Attribute in den Entitätsschlüssel aufgenommen werden, welche auch tatsächlich notwendig sind,
d.h. der Entitätsschlüssel muss minimal sein.
In einer Entitätsmenge können sich durchaus mehrere Attribute oder Attributskombinationen als
Entitätsschlüssel eignen. Diese Attribute und Attributskombinationen werden Schlüsselkandidaten (Englisch: Candidate Key) genannt. Weist eine Entitätsmenge mehrere Schlüsselkandidaten auf, so muss einer dieser Schlüsselkandidaten als Entitätsschlüssel gewählt werden. In der
Regel sollte versucht werden, einen Schlüsselkandidaten mit möglichst wenigen Attributen zu
wählen, welcher zudem durch den Anwender leicht gehandhabt werden kann (Verständlichkeit). Es kann aber auch sein, dass eine Entitätsmenge keinen Entitätsschlüssel aufweist. In
diesem Fall muss ein künstlicher Entitätsschlüssel eingeführt werden, d.h. es wird ein weiteres geeignetes Attribut aufgenommen. Im Prinzip handelt es sich bei der Kundennummer ebenfalls um
einen künstlichen Schlüssel, nur wurde dieser auch ohne Datenbanksystem vergeben. Der Entitätsschlüssel sollte etwa folgende Eigenschaften aufweisen:
 Der Entitätsschlüssel muss einfach und eindeutig durch den Benutzer, eventuell
durch das System vergeben werden können.
 Der Entitätsschlüssel sollte kurz, im besten Fall ein Attribut, und durch den Benutzer
leicht zu handhaben sein (merkfähig, schreibbar).
Im Datenbanksystem müssen der Entitätsschlüssel sowie sämtliche Schlüsselkandidaten explizit
definiert werden, damit dieses sicherstellen kann, dass jeder Entitätsschlüssel und jeder Schlüsselkandidat wirklich nur ein einziges Mal in der Entitätsmenge auftritt.
Die Forderung, dass jeder Entitätsschlüssel im System einen eindeutigen Wert in der Entitätsmenge haben muss, wird Entitätsintegrität (Englisch: Entity Integrity) genannt. Dabei wird zudem
gefordert, dass die Attribute des Entitätsschlüssels nicht den Wert NULL annehmen dürfen. Ob
einzelne Attribute des Entitätsschlüssels dennoch den Wert NULL annehmen dürfen, muss im
konkreten Fall untersucht werden.
Stellenweise wird in der Literatur gefordert, dass der Entitätsschlüssel unveränderlich sei. Diese
Forderung ist für die Praxis meist zu streng. Allerdings muss beim Ändern des Entitätsschlüssels darauf geachtet werden, dass Entitätsmengen, welche den Wert des Entitätsschlüssels referenzieren, einen neuen korrekten Wert erhalten.
4.4.2. Fremdschlüssel
Eine technische Erläuterung des Begriffs Fremdschlüssel wurde bereits im Kapitel '2.2.3. Relationale Datenbanksysteme' auf Seite 14 gegeben. Der Fremdschlüssel ist nicht ein allgemeines Instrument der konzeptionellen Ebene, sondern wird im relationalen Datenmodell zur Erstellung
der Beziehungen zwischen den Entitätsmengen verwendet. Die notwendigen Beziehungen, Beziehungsmengen sind im konzeptionellen Modell bereits festgehalten. Die Fremdschlüssel könnten daher bis zur Herleitung des internen Schemas unberücksichtigt bleiben, da erst zu diesem
Zeitpunkt das zu verwendende Datenbanksystem betrachtet wird. In der Praxis ist zum Zeitpunkt
der konzeptionellen Modellierung allerdings meist schon bekannt, welcher Art das zu verwenTeil 2: Konzeptionelle Datenmodellierung
39
dende Datenbanksystem ist. Ist das Zielsystem ein relationales Datenbanksystem, werden daher
die notwendigen Fremdschlüssel bereits im konzeptionellen Modell in den Attributskatalog aufgenommen. Im Attributskatalog wird im Wertebereich des Fremdschlüsselattributs das entsprechende Attribut der referenzierten Entitätsmenge angegeben (siehe Attributskatalog des Beispiels: Kunden# in der Entitätsmenge Depots im Kapitel '4.4. Attribut').
Durch die Definition der Entitätsschlüssel ergibt sich automatisch der Aufbau der Fremdschlüssel.
Der Fremdschlüssel hält ja fest, welche Entität der referenzierten Entitätsmenge verwendet wird.
Zur Identifikation der referenzierten Entität eignet sich natürlich der Entitätsschlüssel dieser referenzierten Entitätsmenge am besten. Der Aufbau des Fremdschlüssels entspricht daher exakt
dem Aufbau des Entitätsschlüssels der referenzierten Entitätsmenge. Für jedes Attribut des Entitätsschlüssels wird ein entsprechendes Attribut im Fremdschlüssel eingebaut. So wird z.B. in der
Entitätsmenge Depots der Fremdschlüssel 'Kunden#' eingefügt, welcher den Entitätsschlüssel im
Kunden referenziert. Die Namensgebung der Fremdschlüsselattribute ist zwar frei, dennoch sollten nach Möglichkeit die selben Attributsnamen wie im Entitätsschlüssel verwendet werden.
Das Besondere des Fremdschlüssels ist, dass die erlaubten Werte der Fremdschlüsselattribute
nicht mittels Wertebereichen definiert werden, sondern dass die erlaubten Werte von den in der
referenzierten Entitätsmenge existierenden Entitätsschlüsseln abhängen. Erlaubt sind im Fremdschlüssel nur Werte im Attribut bzw. in der Attributskombination, welche auch in der referenzierten Entitätsmenge auftreten. Wäre dem nicht so, würde der Fremdschlüssel auf nicht existierende Entitäten verweisen. Der Wertebereich des Fremdschlüssels ist daher nicht ein statischer, fest
vorgegebener Wertebereich, sondern ein dynamischer Wertebereich, welcher sich mit den Entitäten in der referenzierten Entitätsmenge ändert.
Die Sicherstellung des korrekten Fremdschlüsselwertes wird durch die referentielle Integrität (Englisch: Referential Integrity) und deren Definition im Datenbanksystem gewährt. Im Gegensatz
zum Entitätsschlüssel dürfen Fremdschlüssel in ihren Attributen den Wert NULL annehmen. In diesem Fall ist der Entität mit dem Fremdschlüssel keine Entität der referenzierten Entitätsmenge zugeordnet.
In manchen Situationen muss eine aus mehreren möglichen Entitätsmengen zur Definition der
Fremdschlüsseldomäne gewählt werden. Grundsätzlich ist in diesen Situationen immer jene Entitätsmenge zu wählen, welche den erlaubten Wertebereich am stärksten einschränkt. Stehen
zum Beispiel die Entitätsmengen Kunden und Anlagekunden (Anlagekunden ist eine Teilmenge
der Entitätsmenge Kunden) für die Definition des Fremdschlüssels Kunden# der Entitätsmenge
Depots zur Auswahl, so sollte die Entitätsmenge Anlagekunden gewählt werden (linke Variante)
und nicht die Entitätsmenge Kunden (rechte Variante).
Kunden
können
sein
Werbekunden
Kunden
können
sein
können
sein
Anlagekunden
besitzen
Depots
können
sein
Werbekunden
Anlagekunden
besitzen
Depots
Figur 11: Domänenwahl für Fremdschlüssel
 In den vorhergehenden Absätzen sind wir davon ausgegangen, dass der Fremdschlüssel auf
dem Entitätsschlüssel der referenzierten Entitätsmenge basiert. Theoretisch wäre auch denkbar,
einen Schlüsselkandidaten anstelle des Entitätsschlüssels als Basis zu verwenden. Dies ist zwar
möglich, sollte aber zur besseren Lesbarkeit der Daten und der Datenstruktur unterlassen werden.
40
 Da die Entitätsschlüsselwerte der referenzierten Entitätsmenge den gültigen Wertebereich des
Fremdschlüssels definieren, kann die referenzierte Entitätsmenge auch als Wertebereichsdefinition des Fremdschlüssels für einen Aufzählungstyp verstanden werden. Dieser Ansatz wird dann
verwendet, wenn sich der Wertebereich dynamisch ändert oder falls das Datenbanksystem
keine Möglichkeiten bietet, den Wertebereich entsprechend zu definieren. Hier zeigt sich ein
weiteres Mal die Schwierigkeit, abschliessend festzulegen, um welches elementares Instrument
es sich handelt (Wertebereich oder referenzierte Entitätsmenge). Wird eine Entitätsmenge zur
Definition eines Wertebereichs verwendet, besteht diese nur aus dem Entitätsschlüsselattribut,
welches die gültigen Werte definiert (z.B. Entitätsmenge Kontoarten mit den Werten 'Depositenkonto', 'Kontokorrent', 'Fremdwährungskonto'). Häufig wird allerdings ein weiteres den Wert beschreibendes Attribut hinzugefügt (z.B. 'Konto in Fremdwährung ohne Zins und ohne Kreditmöglichkeit'), welches in den Anwendungen aktiv verwendet wird (siehe auch '6.6. Wertetabelle' auf
Seite 67).
41
4.5. Checkfragen
1.
Ein Entitätsschlüssel (Primärschlüssel) ...





2.
A)
B)
C)
D)
E)
1:1
1:c
1:m
1:mc
c:m
A)
B)
C)
D)
E)
werden im relationalen Modell als eigenständige Relationen realisiert.
sind im relationalen Modell nicht notwendig.
lassen sich im relationalen Modell nicht realisieren.
werden aufgelöst, und das Attribut einer der beiden Relationen zugeordnet.
werden mittels Domänenkonzept realisiert.
NULL-Werte...





6.
das erweiterte Relationenmodell
das Entity-Relationship-Modell (ER-Modell) nach Chen
das hierarchische Datenmodell
das netzwerkartige Datenmodell
das relationale Datenmodell
Beziehungsmengen des Typ 1:m im Entity-Relationship-Modell, welche mindestens ein Attribut enthalten...





5.
A)
B)
C)
D)
E)
Welcher Beziehungstyp macht im konzeptionellen Modell nur in einem bestimmten Zusammenhang Sinn?





4.
ist nicht immer ein Schlüsselkandidat.
ist auch immer ein Fremdschlüssel.
kann die Domäne eines Fremdschlüssels definieren.
ist meistens eindeutig.
ist höchstens aus zwei Attributen zusammengesetzt.
Welches Datenmodell kennt Beziehungsmengen?





3.
A)
B)
C)
D)
E)
A)
B)
C)
D)
E)
sind Blanks.
sind Nullen.
stehen für 'kein Wert definiert'.
sind HEX-0 - Werte.
bedeuten 'keine Anzeige'.
Das Entity-Relationship-Modell und das erweiterte Relationenmodell unterscheiden sich wesentlich in/im:





A)
B)
C)
D)
E)
referentieller Integrität
Navigation
Beziehungen zwischen Entitätsmengen
Darstellung
Wertebereich
42
7.
Was triff auf einen Schlüsselkandidaten zu?
 A)
 B)
Er kann aus mehreren Attributen zusammengesetzt sein.
Der Benutzer bestimmt kraft seines betrieblichen Wissens, wann ein Attribut ein Schlüsselkandidat
sein darf.
 C) Jede Entitätsmenge enthält mehrere Schlüsselkandidaten.
 D) Ein Schlüsselkandidat muss mindestens vierstellig sein.
 E) Er kann bei Eignung als Entitätsschlüssel gewählt werden.
8.
Eine Assoziation...
 A)
 B)
ist eine Menge von verschiedenen Datenwerten.
zwischen zwei Entitätsmengen legt fest, wie viele Entitäten aus Entitätsmenge 2 einer Entität aus Entitätsmenge 1 zugeordnet sein können.
 C) legt fest, wie die wechselseitige Beziehung zwischen Entitätsmengen sein kann.
 D) ist die Beschreibung einer bestimmten Eigenschaft einer Entitätsmenge.
 E) ist eine Beziehungsform zwischen zwei Entitäten.
9.
Was bedeuted referentielle Integrität?
 A)
 B)
Keine Komponente des Entitätsschlüssels einer Entitätsmenge darf den Wert NULL haben.
Jeder Entitätsschlüssel einer Entitätsmenge muss auch als Fremdschlüssel in einer anderen Entitätsmenge auftreten.
 C) Stellt sicher, dass Fremdschlüssel keine NULL-Werte haben.
 D) Für jeden von NULL verschiedenen Fremdschlüsselwert muss ein entsprechender Entitätsschlüsselwert aus der gleichen Domäne existieren.
 E) Verbietet NULL-Werte in Attributen.
4.5.2. Fragetyp B, Zuordnung
Für welchen Begriff gilt der unten beschriebene Sachverhalt?
A) Entität
B) Entitätsschlüssel
C) Fremdschlüssel
D) Schlüsselkandidat
E) Nullwerte
1.
Tupel (Zeile) im relationalen Modell
 A)
2.
C)

D)

E)

B)

C)

D)

E)

B)

C)

D)

E)

E)

E)
Ist möglicher Identifikator in einer Entitätsmenge.
 A)
5.

Basiert auf den Werten, welche in einer anderen Entitätsmenge auftreten.
 A)
4.
B)
Verhindert, dass doppelte Einträge in einer Tabelle auftreten.
 A)
3.


B)

C)

D)
Hat eine spezifische Bedeutung in jeder Domäne.
 A)

B)

C)

D)
Ordnen Sie der Beziehung zwischen den beiden Entitätsmengen den korrekten Beziehungstyp
zu.
A) 1:1
B) c:c
C) 1:mc
D) 1:c
E) c:m
6.
Paar: linker Schuh, rechter Schuh
 A)

B)

C)

D)

E)
7.
Heirat: Frauen, Männer (in christlichem Umfeld)
 A)
8.

B)

C)

D)

E)

D)

E)
C)

D)

E)
C)

D)

E)

E)
Kundenbeziehung: Kunden, Werbekunden
 A)
9.
43

B)

C)
Betreuung: Sachbearbeiter, Kunden
 A)

B)

10. Besitzverhältnis: Konti, Kunden
 A)

B)

A) Entitätsmenge
B) Beziehungsmenge
C) Entitätsschlüssel
D) Domäne
E) Attribut
11. Menge von verschiedenen Datenwerten
 A)

B)

C)

D)
12. Beschreibung einer bestimmten Eigenschaft der Entitäten einer Entitätsmenge
 A)

B)

C)

D)

E)

C)

D)

E)

C)

D)

E)
C)

D)

E)
13. Menge von Tupeln
 A)

B)
14. Identifizierendes Attribut
 A)

B)
15. Assoziiert Entitäten wechselseitig
 A)

B)

1.
Der Fremdschlüssel ist in seinem Aufbau identisch zum Entitätsschlüssel der referenzierten
Entitätsmenge, weil der Fremdschlüssel jede Entität der referenzierten Entitätsmenge eindeutig identifizieren muss.
 A)
2.
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
Im Entity-Relationship-Modell müssen m:m-Beziehungen nicht aufgelöst werden, weil das
Entity-Relationship-Modell m:m-Beziehungen verhindert.
 A)
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
1.
Welche Aussagen sind für das erweiterte Relationenmodell zutreffend?
+








Kennt keine Beziehungsmengen.
Enthält weniger Elementarinstrumente als das Entity-Relationship-Modell.
Kennt genau die drei Assoziationstypen 1, c und m.
Hält ausschliesslich das interne Schema (3-Schema-Modell nach ANSI-SPARC) der Daten fest.
44
2.
Der Entitätsschlüssel sollte so gewählt werden, dass dieser
+




3.




einfach und wenn möglich eindeutig ist.
möglichst kurz ist.
numerisch ist.
schreibbar ist.
Welche Aussagen gelten für den Fremdschlüssel?
+  
 
 
 
Mittels des Fremdschlüsselkonzepts lässt sich für Attribute ein dynamischer Wertebereich (dieser ändert sich im Laufe der Zeit) (aber nicht Wertetyp) definieren.
Fremdschlüssel sind immer auch Schlüsselkandidaten.
Die referenzielle Integrität sichert den korrekten Zustand aller Fremdschlüssel.
Die Fremdschlüssel müssen im DBMS definiert werden, damit dieses deren Zustand kontrollieren
kann.
45
4.6. Bearbeitungsaufgaben
Die Lösungen zu den folgenden Bearbeitungsaufgaben finden Sie auf Seite 158.
4.6.1. KontoSys, Kontoverwaltungs-System
Schwierigkeitsgrad: Trockenübung
Zeitaufwand: 20 Minuten
(Trockenübung, Planschbecken, Nichtschwimmer, Schwimmer)
Die Bank 'SuperSeriös & Co. AG' möchte zur Verwaltung der Konti ein Kontoverwaltungs-System
erstellen, um das manuelle Karteisystem abzulösen. Zur Zeit bestehen zwei Karteien für Kunden
und Konten. Ein Kunde kann mehrere Konten haben, ein Konto kann von einem oder von mehreren Kunden eröffnet werden. In der Kontokartei werden zusätzlich für jedes Konto die einzelnen Kontobewegungen (Datum, Buchungsbetrag, Begünstigter bei Belastungen bzw. Auftraggeber bei Vergütungen) festgehalten. Die Kontobewegungen sind genau einem Konto zugeordnet (sie sind daher nicht mit dem Buchungssatz der Buchhaltung zu vergleichen, der immer
zwei Konten angibt).
1. Stellen Sie die oben geschilderte Datenstruktur im Entity-Relationship-Modell dar.
2. Stellen Sie die oben geschilderte Datenstruktur im erweiterten Relationenmodell dar.
3. Zeigen Sie den Attributskatalog für das Kontoverwaltungs-System (Identifikationsund Fremdschlüssel kennzeichnen).
4.6.2. RezeptSys, Rezeptverwaltungs-System
Schwierigkeitsgrad: Planschbecken
Die Textilfärberei 'Colour-It GmbH' hält in ihrem EDV-System unterschiedliche Stammrezepte (pro
Farbe ein Stammrezept) fest. Das Stammrezept setzt sich dabei aus unterschiedlichen Produkten
(Farbstoffe und Chemikalien) zusammen. Auch die Farbstoffe und Chemikalien sollen im System
als selbständige Entitätsmenge(n) geführt werden, da später eine Lagerkontrolle integriert werden soll (Attribute hierfür bereits einfügen). Im Stammrezept wird festgehalten, wie viel (in
Gramm) Farbstoff bzw. Chemikalie pro Liter Färbebrühe (Volumen) oder pro kg Färbematerial
benötigt wird. Diese Stammrezepte werden unabhängig von existierenden Aufträgen verwaltet.
Pro Auftrag wird jeweils ein Stammrezept ausgeführt. Im Auftrag selbst wird lediglich noch festgehalten, wie viel Material (in kg) in welchem Volumen (in Liter) gefärbt wird, daraus errechnet
das Rezeptverwaltungssystem (ausgehend vom zugeordneten Stammrezept) dann automatisch die benötigten Mengen an Farbstoffen und Chemikalien und druckt das entsprechende
Rezept aus.
1. Stellen Sie die oben geschilderte Datenstruktur im Entity-Relationship-Modell dar.
2. Stellen Sie die oben geschilderte Datenstruktur im erweiterten Relationenmodell dar.
3. Zeigen Sie den Attributskatalog für das Rezeptverwaltungssystem (Entitäts- und
Fremdschlüssel kennzeichnen).
46
Im vorhergehenden Kapitel wurde lediglich gezeigt, wie die Datenstruktur dargestellt wird. Es
wurden bisher aber keine Aussagen dazu gemacht, welche Verhaltensregeln beim Erstellen der
Datenstruktur beachtet werden sollten. Die Normalisierung ist eine Sammlung derartiger Verhaltensregeln, deren Einhaltung die Wahrscheinlichkeit von Redundanzen und damit die Wahrscheinlichkeit von widersprüchlichen Daten (Speicheranomalie) reduziert. Beim Eliminieren von
Redundanzen steigt gleichzeitig auch die Verständlichkeit der Datenstruktur. Die Normalisierung
betrachtet allerdings nur einzelne, isolierte Entitätsmengen und erkennt daher Redundanzen,
welche auf mehrere Entitätsmengen verteilt sind, nicht. Auch können innerhalb einer einzelnen,
vollnormalisierten Entitätsmenge weiterhin Redundanzen auftreten. Die Normalisierung ist daher
nur eine erste Hilfe, um die Datenstruktur zu verbessern, darf aber keinesfalls als vollständige und
abschliessende Regelsammlung zur Datenmodellierung aufgefasst werden.
In der Normalisierung sind mehrere Normalformen bekannt. Jede Normalform stellt sicher, dass
die Daten bestimmte Bedingungen einhalten. Am bekanntesten sind die 1., 2. und 3. Normalform (als Kürzel wird häufig NF anstelle von Normalform geschrieben, z.B. 3. NF). Nebst den ersten drei Normalformen sind aber noch weitere Normalformen bekannt. Diese sind in der Praxis
allerdings von geringer Bedeutung und daher kaum bekannt. Bei der Nummerierung der Normalformen ist zu bemerken, dass jede Normalform alle vorhergehenden Normalformen beinhaltet. So ist z.B. eine Entitätsmenge in 3. Normalform auch in 2. und 1. Normalform.
Ursprünglich stammt die Normalisierung aus dem relationalen Ansatz, daher rührt auch der mathematische Ansatz. Die Normalisierung eignet sich aber für sämtliche datenorientierten Modelle und wird heute daher in der Datenmodellierung allgemein verwendet.
Die Normalisierung findet auf der konzeptionellen Ebene statt, in welcher Redundanzen ja
grundsätzlich eliminiert werden. Beim Herleiten des internen Modells wird teilweise denormalisiert, d.h. es werden wieder gezielt Redundanzen eingeführt, um die Performance des Systems
zu verbessern. Dabei wird versucht, möglichst wenig, im besten Fall keine Redundanzen durch
Denormalisierung in die Daten einzubringen. Durch die vorhergehende Normalisierung ist in diesen Fällen aber zumindest bekannt, an welchen Stellen Redundanzen bestehen, so dass diese
entsprechend berücksichtigt werden können. Die Aussage 'unsere Daten sind in der Datenbank
voll normalisiert' lässt daher darauf schliessen, dass die Performance des Systems deutlich verbessert werden könnte (falls nötig). In den meisten Fällen ist die Aussage allerdings schlicht
falsch.
In der Regel treten beim Erstellen des konzeptionellen Datenmodells durch einen erfahrenen
Modellierer gar keine Redundanzen auf. Verletzungen der Normalformen treten nur auf, falls inhaltlich unabhängige Entitätsmengen in eine gemeinsame Entitätsmenge gepackt werden.
Diese unabhängigen Entitätsmengen werden bei der Normalisierung durch das Aufteilen der
gepackten Entitätsmenge erarbeitet.
Die Normalisierung in den folgenden Unterkapiteln soll anhand folgender zwei Entitätsmengen
gezeigt werden, welche eine einfache Auftragsverwaltung realisieren:
Aufträge
Auftrags#
1
2
3
Artikel#[1:10]
4, 5
5, 9
4
Artikel_Bez
Toaster, TV
TV, Locher
Toaster
Betrag
120, 2'889
2'889, 49
120
Kunden
Kunden#
Name
PLZ
Ort
1
2
Maier
Müller
8001
8001
Zürich
Zürich
Auftrags#[1:100]
1, 2
3
Tabellen 7: Unnormalisierte Entitätsmengen
Auftrags_Datum
12. März
24. März
23. März
47
Hinweis zu den Entitätsmengen: Mittels der Wiederholungsgruppe im Attribut Auftrags# (Fremdschlüssel) in der Entitätsmenge Kunden wird zwischen den Entitätsmengen eine m:m-Beziehung
realisiert. Das Datenstrukturmodell der beiden Entitätsmengen sieht wie folgt aus:
Aufträge
Kunden
Figur 12: Auftragsverwaltung unnormalisiert
5.1. 1. Normalform
 Eine Entitätsmenge ist in 1. Normalform, wenn die Wertebereiche sämtlicher Attribute skalar (ein Wertebereich ohne Wiederholungsgruppen heisst skalar oder atomar)
sind.
Damit sind für Attribute Wiederholungsgruppen (siehe '4.3.2. Strukturierter Wertebereich' auf Seite 35) als Wertebereiche verboten. Die 1. Normalform wird in aller Regel im Modellierungsprozess vom Modellierer automatisch eingehalten. Beim ersten Normalisierungsschritt werden
die betroffenen Entitätsmengen noch nicht geteilt, wie dies in den folgenden Normalisierungsschritten der Fall sein wird. Die Entitäten der betroffenen Entitätsmengen werden aber mehrfach, nämlich je Ausprägung in der Wiederholungsgruppe, in die Entitätsmenge eingetragen.
Nach dieser Mehrfacheintragung ist allerdings der bisherige Entitätsschlüssel in aller Regel nicht
mehr eindeutig, so dass der Entitätsschlüssel neu bestimmt werden muss, dies auch darum, weil
der Entitätsschlüssel in den folgenden Normalisierungsschritten eine wichtige Rolle spielt.
Im Beispiel müssen beide Entitätsmengen bearbeitet werden. Nach der Vervielfachung der Entitäten fällt auf, dass der Entitätsschlüssel, wie vorhergesagt, nicht mehr eindeutig ist, daher muss
dieser um geeignete Attribute erweitert werden. Hierfür sind lediglich Attribute aus der Wiederholungsgruppe geeignet. Im Beispiel werden in der Entitätsmenge Aufträge das Attribut Artikel#
und in der Entitätsmenge Kunden das Attribut Auftrags# dem Entitätsschlüssel hinzugefügt:
Aufträge
Auftrags#
1
1
2
2
3
Artikel#
4
5
5
9
4
Artikel_Bez
Toaster
TV
TV
Locher
Toaster
Betrag
120
2'889
2'889
49
120
Auftrags_Datum
12. März
12. März
24. März
24. März
23. März
Kunden
Kunden#
1
1
2
Name
Maier
Maier
Müller
PLZ
8001
8001
8001
Ort
Zürich
Zürich
Zürich
Auftrags#
1
2
3
Tabellen 8: Entitätsmengen in 1. Normalform
 Basis des gesamten Normalisierungsprozesses sind funktionale Abhängigkeiten. In der Normalisierung werden die funktionalen Abhängigkeiten zwischen den Attributen betrachtet. Ein Attribut A (z.B. Kundenname) ist von einem Attribut B (z.B. Kundennummer) funktional abhängig,
wenn zu einem bestimmten Wert von B höchstens ein Wert von A möglich ist. Bei Angabe der
Kundennummer kann im Beispiel der Kundenname hergeleitet werden und es ist pro Kundennummer höchstens ein Kundenname möglich (mathematisch: f[x]=y, bzw. f[KunTeil 2: Konzeptionelle Datenmodellierung
48
dennummer]=Kundenname). Damit ist der Kundenname funktional abhängig von der Kundennummer. Bei Angabe des Kundennamens kann die Kundennummer nicht eindeutig hergeleitet
werden, da ev. zwei Kunden mit dem selben Namen existieren. Die Kundennummer ist damit
nicht funktional abhängig vom Kundennamen.
 In der ersten Normalform wird verlangt, dass sämtliche Nichtschlüsselattribute (Attribut, welches
nicht Teil des Entitätsschlüssels ist) funktional abhängig vom Entitätsschlüssel sind. Daraus folgt,
dass ein Nichtschlüsselattribut höchstens einen Wert aufweisen darf, d.h., dass Wiederholungsgruppen als Wertebereich für Attribute nicht erlaubt sind.
5.2. 2. Normalform
 Eine Entitätsmenge ist in 2. Normalform, wenn sie in 1. Normalform ist und wenn jedes
Nichtschlüsselattribut von allen Attributen des Entitätsschlüssels gemeinsam
abhängig ist.
Die 2. Normalform kann nur verletzt sein, falls sich der Entitätsschlüssel aus mehreren Attributen
zusammensetzt und die Entitätsmenge Nichtschlüsselattribute enthält. Dann kann es nämlich
vorkommen, dass ein Attribut nicht vom gesamten Entitätsschlüssel, sondern nur von einem Teil
der Attribute des Entitätsschlüssels abhängig ist. Dies ist in der Entitätsmenge 'Aufträge' leicht zu
sehen. Die Artikelbezeichnung lässt sich schon allein aufgrund des Attributes Artikelnummer herleiten, ohne dass das zweite Entitätsschlüsselattribut Auftragsnummer dazu notwendig ist. Auch
sind die sich daraus ergebenden Redundanzen leicht zu erkennen.
Diese Redundanzen lassen sich nur entfernen, indem die betroffenen Entitätsmengen gezielt
aufgeteilt werden. In den meisten Fällen ist die Teilung der Entitätsmengen intuitiv klar und einfach. Dennoch ist dabei Vorsicht geboten. Grundsätzlich sind die Entitätsmengen derart zu
trennen, dass sich aus den resultierenden Entitätsmengen die vorherige Entitätsmenge herleiten
lässt. D.h. Trennung ohne Informationsverlust. Auf wie viele Arten kann eine Entitätsmenge getrennt werden? Dies ist abhängig von der Anzahl der Attribute im Entitätsschlüssel. Die Tabelle
unten zeigt, auf wie viele Arten eine Entitätsmenge mit 2 und 3 Schlüsselattributen A, B und C
getrennt werden kann:
 2 Attribute: A; B oder AB
 3 Attribute: A; B; C; AB; AC; BC oder ABC
Eine Entitätsmenge mit n Attributen lässt sich damit auf 2 n - 1 Arten teilen. Bei vier Schlüsselattributen sind damit schon 15 mögliche Entitätsmengen zu betrachten. Bei der Trennung der
Entitätsmenge geht man am besten in folgenden Schritten vor:
1. Bestimmen der möglichen Entitätsschlüsselkombinationen, die aus den gegebenen
Schlüsselattributen gebildet werden können.
2. Zuordnen der Nichtschlüsselattribute zu jener Entitätsschlüsselkombination, von welcher das Nichtschlüsselattribut tatsächlich abhängig ist. Diese Zuordnung kann nur
mit Kenntnis des tatsächlichen Sachverhaltes erfolgen.
3. Entitätsschlüsselkombinationen, welchen mindestens ein Nichtschlüsselattribut zugeordnet wurde, sind mit Sicherheit notwendig. Diese Entitätsmengen sind die ersten
Resultatemengen.
4. Verbleiben Entitätsschlüsselkombinationen, welchen kein Nichtschlüsselattribut zugeordnet wurde, muss entschieden werden, ob diese ohne Informationsverlust
weggelassen werden können. Dies ist nicht einfach. Wieder muss dies aufgrund des
tatsächlichen Sachverhalts entschieden werden. Dabei wird überlegt, ob sich die
ursprüngliche Entitätsmenge noch herleiten lässt, falls diese Entitätsschlüsselkombination nicht verwendet wird.
5. Benennung der Resultatemengen.
49
Diese Ausführungen zeigen, dass die Herleitung der Resultatemengen in 2. Normalform nicht trivial ist und eine vertiefte Kenntnis des Sachverhalts verlangen. Es sollte daher bei der Normalisierung der Versuch vermieden werden, ausgehend von einer unnormalisierten Entitätsmenge direkt die Resultatemengen in 3. Normalform herzuleiten, dabei werden häufig Fehler begangen.
Durch die notwendige Kenntnis des Sachverhalts, treten bei der Normalisierung häufig auch inhaltliche Fragen zu den Daten auf. Es werden jetzt die beiden Entitätsmengen des Beispiels in 2.
Normalform gebracht.
Herleitung der 2. Normalform der Entitätsmenge Aufträge:
1. Auftrags#; Artikel#; Auftrags#, Artikel#
2. Artikel_Bez und Betrag gehören zu Artikel#.
Auftrags_Dat gehört zu Auftrags#
3. 1. Artikel#, Artikel_Bez, Betrag
2. Auftrags#, Auftrags_Dat
4. Die Entitätsschlüsselkombination Auftrags#, Artikel# ist notwendig und muss daher
als dritte Resultatemenge verwendet werden. Diese Entitätsmenge erstellt die Verbindung zwischen den Artikeln und den Aufträgen.
5. Resultatemengen:
Aufträge
Auftrags#
1
2
3
Auftrags_Datum
12. März
24. März
23. März
Artikel
Artikel#
Artikel_Bez
4
5
9
Toaster
TV
Locher
Betrag
120
2'889
49
Auftragspositionen
Auftrags#
1
1
2
2
3
Artikel#
4
5
5
9
4
Tabellen 9: Entitätsmengen in 2. Normalform (Auftrag)
Herleitung der 2. Normalform der Entitätsmenge Kunde:
1. Kunden#; Auftrags#; Kunden#, Auftrags#
2. Name, PLZ und Ort: Kunden#.
3. 1. Kunden#, Name, PLZ, Ort
4. Während die Entitätsschlüsselkombination Kunden#, Auftrags# notwendig ist (diese
hält fest, welcher Kunde welche Aufträge vergeben hat), kann die Entitätsschlüsselkombination Auftrags# ohne Informationsverlust eliminiert werden.
Interessant ist hierbei der Aspekt, dass bei der Normalisierung der ersten Entitätsmenge bereits eine Entitätsmenge der Aufträge entstanden ist. Da die Normalisierung aber nur einzelne Entitätsmengen isoliert betrachtet, erkennt sie diesen UmTeil 2: Konzeptionelle Datenmodellierung
50
stand nicht! Hier zeigen sich bereits deutlich die Grenzen einer isolierten Betrachtung
der Entitätsmengen.
5. Resultatemengen:
Kunden
Kunden#
1
2
Name
Maier
Müller
PLZ
8001
8001
Ort
Zürich
Zürich
Auftragsvergaben
Kunden#
1
1
2
Auftrags#
1
2
3
Tabellen 10: Entitätsmengen in 2. Normalform (Kunde)
Nachdem die Ausgangsentitätsmengen in die 2. Normalform gebracht worden sind, hat sich
die Struktur des Datenmodells deutlich geändert. Dabei fällt insbesondere auf, dass die
m:m-Beziehung in 1:m-Beziehungen aufgelöst wurde. Damit wird deutlich, das
m:m-Beziehungen die 2. Normalform verletzen und darum verboten sind. Beim Erstellen der Datenstruktur sollten m:m-Beziehungen im erweiterten Relationenmodell daher am besten von Anfang an vermieden und sofort mittels zweier 1:m-Beziehungen aufgelöst werden.
Artikel
Aufträge
Auftragspositionen
Kunden
Auftragsvergaben
Figur 13: Auftragsverwaltung in 2. Normalform
 Während in der 1. Normalform die funktionalen Abhängigkeiten betrachtet wurden, wird in der
2. Normalform verlangt, dass sämtliche Nichtschlüsselattribute voll funktional abhängig vom Entitätsschlüssel sind. D.h., es gilt f[s]=a (wobei s Entitätsschlüssel, und a Nichtschlüsselattribut), aber
es gibt für t kein g so dass gilt, g[t]=a (wobei t Entitätsschlüsselteil ist).
5.3. 3. Normalform
In der ersten und zweiten Normalform standen die Nichtschlüsselattribute und deren Abhängigkeit vom Entitätsschlüssel im Zentrum der Überlegungen. In der dritten Normalform werden nun
störende Abhängigkeiten zwischen den Nichtschlüsselattributen gesucht und eliminiert. Hier
muss bemerkt werden, dass von verschiedenen Autoren unterschiedlich strenge Definitionen
der 3. Normalform gegeben wurden. Der Einfachheit halber wird hier nur die strengste Form,
welche die Mängel der vorhergehenden Formen beseitigte, gezeigt. Diese Normalform wird in
Anlehnung an deren Autoren auch Boyce/Codd-Normalform genannt.
 Eine Entitätsmenge ist in 3. Normalform, wenn sie in 2. Normalform ist, und wenn
jedes Nichtschlüsselattribut nur vom Entitätsschlüssel und den Schlüsselkandidaten
abhängig ist.
Ein Nichtschlüsselattribut darf damit nicht von einem anderen Attribut oder einer Attributskombination abhängig sein, welches nicht Entitätsschlüssel oder Schlüsselkandidat ist (Bem: der EntiTeil 2: Konzeptionelle Datenmodellierung
51
tätsschlüssel ist auch ein Schlüsselkandidat). Im Gegensatz zur 2. Normalform, bei welcher sich
die Beseitigung des Mangels schwierig gestaltete, ist dies bei der 3. Normalform einfach. Werden Attribute gefunden, welche die 3. Normalform verletzen, werden diese in eine separate Entitätsmenge ausgelagert. Dabei werden Attribute, welche vom selben Attribut bzw. von der selben Attributskombination abhängig sind, natürlich in eine gemeinsame Entitätsmenge eingelagert. Zusätzlich wird in die Entitätsmenge das Attribut bzw. die Attributskombination, von
welchem die ausgelagerten Attribute abhängen, als Entitätsschlüssel in die neue Entitätsmenge
eingefügt, ohne dass dieses aus der ursprünglichen Entitätsmenge entfernt würde. In der ursprünglichen Entitätsmenge ist dieses Attribut bzw. Attributskombination der Fremdschlüssel,
welcher die neue Entitätsmenge referenziert.
Im Beispiel der Auftragsverwaltung ist nur eine Verletzung der 3. Normalform zu finden. Das Attribut Ort der Entitätsmenge Kunden ist vom Attribut PLZ abhängig (ohne Berücksichtigung der
Tatsache, dass Ortschaften allenfalls die selbe PLZ haben). Das Attribut PLZ ist in der Entitätsmenge Kunden weder Entitätsschlüssel noch Schlüsselkandidat, was an den Beispieldaten leicht
zu erkennen ist. Nach der Behebung des Mangels sind aus der Entitätsmenge Kunden zwei Entitätsmengen entstanden:
Kunden
Kunden#
1
2
Name
Maier
Müller
PLZ
8001
8001
Ortsverzeichnis (CH)
PLZ
Ort
8001
Zürich
Tabellen 11: Entitätsmengen in 3. Normalform
Ortsverzeichnis
Artikel
Aufträge
Auftragspositionen
Kunden
Auftragsvergaben
Figur 14: Auftragsverwaltung in 3. Normalform
 Die 3. Normalform ist verletzt, falls es Funktionen f und g gibt, so dass f[a]=b, g[b]=c gilt, aber
keine Funktion h, so dass h[b]=a, wobei bc (a ist Entitätsschlüssel, b ist ein Attribut oder eine Attributskombination, c ist Nichtschlüsselattribut). Damit ist b und c von a, aber auch c von b funktional abhängig; b kann kein Schlüsselkandidat sein, da sonst a von b funktional abhängig wäre. Diese Art der Abhängigkeit g[f[a]]=c wird transitive Abhängigkeit genannt, c ist transitiv abhängig von a.
 Im Zusammenhang mit der 3. Normalform wird zu deren Definition auch der Begriff Determinante (Englisch: Determinant) eingeführt. Die Determinante ist ein Attribut bzw. Attributskombination, von welchem ein Attribut funktional abhängig ist. Eine Verletzung der 3. Normalform liegt demnach vor, wenn b Determinante aber nicht Schlüsselkandidat ist. Die 3. Normalform lässt sich damit auch wie folgt definieren:
52
 Eine Entitätsmenge ist in 3. Normalform, wenn jede Determinante Schlüsselkandidat
ist.
 Dabei fällt auf, dass in dieser Definition die 1. und 2. Normalform nicht explizit erwähnt werden
müssen, sondern dass diese bereits integriert sind. Die letzte Definition besticht durch ihre Eleganz, während die vorhergehenden Definitionen für den Praktiker verständlich und leicht umzusetzen sind.
53
5.4. Checkfragen
1.
Folgende Entitätsmenge befindet sich in:





A)
B)
C)
D)
E)
in keiner Normalform
1. Normalform
2. Normalform
3. Normalform
In 3. aber nicht in 2. Normalform
Annahme: Ein Mitarbeiter ist nur in einer Filiale angestellt.
Personal
Personal#
2.
1
1
1
2
2
2
Lohn
Maier
Mayr
Meier
Meyer
Meyr
794.63.268.156
120.55.221.257
820.70.334.055
653.09.529.127
3'400
6'700
5'400
4'500
557.33.271.059
4'900
A)
B)
C)
D)
E)
wird auf der internen, physischen Ebene ausgeführt.
hat das Ziel, Redundanzen innerhalb einer Entitätsmenge zu minimieren.
ist eine umfassende Entwurfsmethodik für konzeptionelle Datenmodellierung.
zerlegt Entitätsmengen und fügt diese in einem geordneten Prozess wieder zusammen.
dient ausschliesslich der Vermeidung von Anomalien bei Speicheroperationen.
Bei welchem Normalisierungsschritt werden m:m-Beziehungen zu je zwei 1:m-Beziehungen
aufgelöst?





4.
1
2
3
1
Name AHV#
Die Normalisierung...





3.
Filial#
A)
B)
C)
D)
E)
bei keinem Normalisierungsschritt
1. Normalform
2. Normalform
3. Normalform
bei der Denormalisierung
Eines der Ziele der Normalisierung ist...





A)
B)
C)
D)
E)
die übersichtliche Gestaltung der Entitätsmengen.
das Schaffen neuer Entitätsmengen.
die Minimierung der Redundanz.
die Gewährleistung der Benutzerfreundlichkeit.
das Erkennen der funktionalen Abhängigkeiten.
Welche Begriffe lassen sich einander zuordnen?
A) Normalisierung
B) Denormalisierung
C) Referentielle Integrität
D) Schlüsselkandidaten
E) Restriktion
1.
Performance-Verbesserung
 A)

B)

C)

D)

E)
54
2.
Redundanzminderung
 A)
3.


C)

D)

E)
B)

C)

D)

E)
Vermeidung von Speicheranomalien
 A)
5.

Voraussetzung für Fremdschlüssel-Entitätsschlüsselbeziehung
 A)
4.
B)

B)

C)

D)

E)

C)

D)

E)
Eindeutige Identifikation
 A)

B)
 Für welchen Begriff gilt der unten beschriebene Sachverhalt?
A) funktionale Abhängigkeit
B) voll funktionale Abhängigkeit
C) transitive Abhängigkeit
D) Wiederholungsgruppe
E) Fremdschlüsselbeziehung
6.
Welcher Begriff wird einzig im Zusammenhang mit unnormalisierten Relationen verwendet?
 A)
7.


C)

D)

E)
B)

C)

D)

E)
Welcher Begriff betrachtet die Abhängigkeiten von Nichtschlüsselattributen in einer einzelnen Relation?
 A)
9.

Was betrachtet die Normalisierung nicht?
 A)
8.
B)

B)

C)

D)

E)
Welcher Begriff betrachtet die Entitätsschlüsselteile in einer Relation?
 A)

B)

C)

D)

E)
10. Bei welchem der Begriffe werden allfällige Schlüsselkandidaten betrachtet?
 A)

B)

C)

D)

E)
1.
Bei der Normalisierung werden leistungsbestimmende Überlegungen nicht einbezogen, weil
die Normalisierung keine Aussagen zu Hilfsorganisationen (Zugriffsbeschleunigung) in der internen Ebene macht.
 A)
2.
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
Durch die Normalisierung der Entitätsmengen werden Anomalien bei Speicheroperationen
vermieden, weil die Normalisierung eine umfassende Entwurfsmethodik für konzeptionelle
Datenbanken ist.
 A)
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
1.
Entitätsmengen in der 1. Normalform...
+








lassen am Schnittpunkt Attribut/Tupel auch Attribute mit mehreren Werten zu.
haben keine Nichtschlüsselattribute, die vom Gesamtschlüssel abhängig sind.
können in Datensichten (Views) gebraucht werden.
haben grössere Redundanzen als voll normalisierte Entitätsmengen.
2.
Was sind die Ziele und Eigenschaften der Normalisierung?
+




 3.
55




Redundanzen innerhalb einer Entitätsmenge zu minimieren.
Sorgt für eine zweckmässige Strukturierung der Daten, auch für die physische, interne Ebene.
Dient der Vermeidung von Anomalien bei Speicheroperationen.
Eliminiert auch Redundanzen, die über mehrere Entitätsmengen verteilt sind.
Welche Abhängigkeiten sind funktionale Abhängigkeiten?
+








Geburtsdatum  Sternzeichen
Schweizer AHV-Nummer  Name
Name  Vorname
Autokennzeichen  Wagentyp (Wechselnummern vernachlässigen)
56
5.5.1. Normalisierung Projektverwaltung
Schwierigkeitsgrad: Trockenübung (Trockenübung, Planschbecken, Nichtschwimmer, Schwimmer)
Normalisieren Sie folgende Entitätsmenge einer Projektverwaltung. Zeigen Sie die Entitätsmenge(n) nach jedem Normalisierungsschritt und kennzeichnen Sie deren Entitätsschlüssel.
Projektverwaltung
Mitarbeiter#
1
2
Name
Projekt#
Müller
Meier
1
2, 3
Projektbezeichnung
Staudamm S3
Brücke B134, Tunnel T25
StatusCode
A
B, B
3
Sieber
1, 2
Staudamm S3, Brücke B134 A, B
StatusBezeichnung
aktiv
offeriert, offeriert
aktiv, offeriert
Tabelle 12: Unnormalisierte Entitätsmenge Projektverwaltung
5.5.2. Normalisierung Buchhandelssystem
Normalisieren Sie folgende Entitätsmenge einer Applikation, welche Bestellungen von Büchern
verwalten soll. Zeigen Sie die Entitätsmenge(n) nach jedem Normalisierungsschritt und kennzeichnen Sie deren Entitätsschlüssel. Annahmen zur Aufgabe:
 Eine Bestellung kann durch mehrere Besteller gemeinsam ausgelöst werden.
 Eine Bestellung kann mehrere Bücher umfassen.
Bestellungen
Bestell_Nr
1
Bestell_Datum
4. März
2
3
4
6. März
7. März
7. März
Buch_Nr
232-41,
343-21
534-45
231-55
232-41
Buch_Bez
Mörder im Rosengarten,
Der Tod im Schulzimmer
Vegetarier leben länger
Sinue und Echnaton
Mörder im Rosengarten
Besteller_Nr
1
Besteller
Fritz Müller
2
1
3, 4
Hans Meier
Fritz Müller
Urs Schmid, Rita Gugolz
Tabelle 13: Unnormalisierte Entitätsmenge Bestellwesen
57
5.5.3. Normalisierung Wagenvermietung
Schwierigkeitsgrad: Schwimmer
Normalisieren Sie die unten gezeigten Entitätsmengen (1. bis 3. Normalform). Bemerkungen und
Tipps zum Vorgehen:
 Vorsicht, die in dieser Übung verwendeten Entitätsmengen weisen mehrere Stolpersteine auf. Ein unüberlegtes Anwenden der Normalisierungsregeln führt zu unsinnigen Resultaten! Überlegen Sie sich bei jedem Schritt genau, was Sie tun.
 Beim Übergang in die erste Normalform sind die Entitätsschlüssel beider Entitätsmengen nicht mehr eindeutig, so dass diese um geeignete Schlüsselattribute erweitert werden müssen, bevor der zweite Normalisierungsschritt angegangen werden
kann (der zweite Normalisierungsschritt untersucht den Entitätsschlüssel).
In der Entitätsmenge Wagen kann dies durch den Einbezug zweier weiterer Attribute
erreicht werden. In der Entitätsmenge Mieter ist die Situation wesentlich ungünstiger,
da zwei Entitäten in der Tabelle sind, die absolut identisch sind, so dass der Einbezug
beliebig vieler Attribute nicht zu einem eindeutigen Schlüssel führt. Um einen eindeutigen Schlüssel zu erhalten, muss ein neues Attribut eingeführt werden!
 Annahme: Ein Kunde mietet den selben Wagen nur ein einziges Mal am gleichen
Tag, kann aber natürlich mehrere Wagen am selben Tag mieten.
 Annahme: Der Kilometeransatz ist einzig vom Wagentyp abhängig.
Unnormalisierte Relationen:
Wagen
Wagen_Nr Kennzeichen
1
ZH 333 666
2
ZH 111 222
3
ZH 100 000
4
ZH 25 25 25
Wagentyp
Fr/km Mieter_Nr
Mercedes 190
Toyota MR2
Suzuki Swift
Mercedes 190
0.80
0.75
0.50
0.80
3/64/19
5/3
19/5
-
Datum
Preis
11.11/2.5/14.3
5.8/24.4
12.3/12.8
-
160/400/200
82.50/150
200/50
-
Total
760.00
232.50
250.00
-
Mieter
Mieter_Nr
3
64
5
19
Name
Maier
Meier
Meyer
Meyr
Total
310.00
400.00
132.50
400.00
Zahl_Datum
1.12/26.4
2.6
3.9/3.9
28.3/28.3
Zahl_Betrag
160/150
400
82.50/50
200/200
Tabellen 14: Unnormalisierte Entitätsmengen Wagen und Mieter
58
Während bei den Elementarinstrumenten die kleinsten Einheiten des konzeptionellen Datenmodells besprochen wurden (die Normalisierung zeigt Regeln zur Strukturierung der Elementarinstrumente Entitäts- und Beziehungsmenge), sollen jetzt daraus komplexere Gebilde zusammengefügt werden. Vergleichbar ist dies etwa mit den chemischen Elementen (der Periodentabelle), aus welchen komplexere chemische Verbindungen (Moleküle) erzeugt werden können.
Aus diesen Verbundinstrumenten wird schliesslich das eigentliche Datenmodell gebildet.
6.1. Hierarchie
Die hierarchische Beziehung zweier Entitätsmengen wird mit genau einer 1:m-, 1:mc- c:m- oder
c:mc-Beziehung hergestellt (z.B. Kunden und Aktiendepots, oder Sachbearbeiter und Kunden).
Es ist das einfachste Verbundinstrument. Hierarchische Beziehungen sind in Datenstrukturen sehr
häufig. Dabei bilden sich häufig mehrstufige Hierarchien.
Kunden
besitzen
Kunden
KundenDepots
besitzen
Depots
gehören
Depots
Figur 15: Hierarchie
Kunden
Kunden#
K-000001
K-000002
K-000003
K-000004
Name
Müller
Meier
Sieber
Egli
Gurtsdatum
7. März
4. Juli
12. März
20. Januar
Geschlecht
männlich
männlich
weiblich
männlich
Depots
Depot#
Kunden#
Eröffnungsdatum
Saldierungsdatum
DP-Akt-001001
DP-Akt-001231
DP-Akt-002342
DP-Akt-009786
K-000002
K-000001
K-000003
K-000003
3. Juni
6. Juni
9. April
12. Januar
<NULL>
19.8.
<NULL>
<NULL>
Tabellen 15: Entitätsmengen bei der Hierarchie
6.2. Beziehungsstruktur
Zur Abgrenzung zu den Begriffen Beziehung und Beziehungsmenge wurde hier der Name Beziehungsstruktur vergeben. Die Beziehungsstruktur realisiert eine m:m-, m:mc- oder mc:mcBeziehung zwischen zwei (oder mehr) Entitätsmengen. Im Entity-Relationship-Modell werden als
Elementarinstrumente zwei Entitätsmengen und eine Beziehungsmenge zur Bildung der BeTeil 2: Konzeptionelle Datenmodellierung
59
ziehungsstruktur verwendet; im erweiterten Relationenmodell werden 3 Entitätsmengen verwendet. Die Entitätsmenge in der Beziehungsstruktur, welche die Entitätsmengen verbindet,
wird auch im erweiterten Relationenmodell häufig Beziehungsmenge genannt.
Depots
Aktien
deponiert
in
enthalten
Depotinhalt
Depots
Aktien
deponiert
in
enthalten
Depotinhalt
Figur 16: m:m-, m:mc- und mc:mc-Beziehungsstruktur
Depots
Depot#
Kunden#
DP-Akt-001001
DP-Akt-001231
DP-Akt-002342
DP-Akt-009786
K-000002
K-000001
K-000003
K-000003
Eröffnungsdatum
3. Juni
6. Juni
9. April
12. Januar
Saldierungsdatum
<NULL>
19. August
<NULL>
<NULL>
Aktien
Aktien#
103923
204432
532994
394001
AktienArt
Inhaberaktie
Obligation
Namenaktie
Inhaberaktie
Emittent
FantasyAG
FantasyAG
TraspoAG
Colour-It & Co. AG
AktuellerKurs
450,55
28,60
230,30
202,05
Depotinhalt
Depot#
DP-Akt-001001
DP-Akt-001231
DP-Akt-001231
DP-Akt-001231
DP-Akt-002342
DP-Akt-002342
Aktien#
204432
103923
204432
394001
103923
204432
Saldo
20
50
250
10
100
500
Tabellen 16: Entitätsmengen bei der Beziehungsstruktur
Mit dieser Grundstruktur lassen sich aber nicht nur zwei, sondern auch drei oder mehr Entitätsmengen miteinander verbinden.
60
Aufträge
Artikel
Rechnungen
erbracht
im Auftrag
bestehen
aus
Rechnungsdetails
Auftragspositionen
Aufträge
Artikel
Rechnungen
erbracht im
Auftrag
bestehen
aus
Rechnungsdetails
Auftragspositionen
Figur 17: Beziehungsstruktur mit drei Entitätsmengen
Aufträge
Auftrags#
254301
254302
244692
Kunden#
1
1
2
Auftragsdatum
4. März
4. März
4. März
Artikel
Artikel# Bezeichnung
2531
7121
2644
4623
Monitor XP 34-3
Monitor XP 34-4
Diskette XDS
Tastatur HG/3
Preis
1'090,00
1'490,00
4,50
99,00
Lagerbestand
6,00
5,00
5'465,00
12,00
Rechnungen
Rechnungs#
32
33
34
35
Datum
12. März
23. März
14. März
5. Mai
Betrag
2'580,00
198,00
112,50
99,00
Auftragspositionen
Auftrags# Artikel# Rechnungs#
254301
254301
254302
244692
244692
2531
7121
4623
2644
4623
32
32
33
34
35
Bestellmenge
1,00
1,00
2,00
25,00
1,00
Rechnungsbetr.
1'090,00
1'490,00
198,00
112,50
99,00
Lieferdatum
10. März
10. März
23. März
12. März
2. Mai
Tabellen 17: Entitätsmengen bei der Beziehungsstruktur mit drei Entitätsmengen
Als Entitätsschlüssel der Beziehungsmenge wird häufig die Kombination der Fremdschlüssel verwendet. In besonderen Fällen ist diese Wahl allerdings nicht korrekt. Soll eine Entität der einen
Entitätsmenge (z.B. die Aktie 023453) mehrfach der selben Entität (Aktiendepot DP-Akt-001001
des Kunden K-000002) der anderen Entitätsmenge zugeordnet werden (wobei jeder Eintrag z.B.
61
einem Kaufgeschäft zu einem bestimmten Preis entspricht), so würde die selbe Entitätsschlüsselwert-Kombination mehrfach auftreten und wäre damit nicht mehr eindeutig. Meist erhält die
Beziehungsmenge in diesen Fällen weitere Beziehungsattribute. Diese eignen sich allenfalls dafür, den Entitätsschlüssel in geeigneter Weise zu ergänzen. Falls dies nicht möglich ist, muss ein
künstlicher Entitätsschlüssel für die Beziehungsmenge geschaffen werden. Dieser künstliche
Schlüssel kann natürlich von der Applikation verwaltet werden und dem Anwender verborgen
bleiben.
 Auch muss beachtet werden, dass drei Entitätsmengen nicht nur mittels einer einzigen Entitätsmenge (mit drei referenzierten Entitätsmengen), sondern auch mit 2 oder 3 Beziehungsmengen (mit jeweils zwei referenzierten Entitätsmengen) verknüpft werden können. Ausserdem
lassen sich 3 Entitätsmengen mit 2 Beziehungsmengen mit jeweils 2 referenzierten Entitätsmengen auf 3 unterschiedliche Arten verknüpfen. 3 Entitätsmengen lassen sich damit auf insgesamt
fünf verschiedene Arten verknüpfen. Nur eine dieser fünf Varianten ist jeweils korrekt. Bei einer
genauen Betrachtung des Sachverhalts lässt sich die korrekte Lösung bestimmen.
6.3. Rekursion
Bei der Rekursion erstellt eine Entitätsmenge mittels einer c:c- oder c:mc-Beziehung eine Referenz auf sich selbst. Dabei sind die Assoziationstypen 1 und m fast immer ungeeignet, da sonst
eine Entität immer eine Entität referenzieren (1), bzw. immer durch eine Entität der selben Entitätsmenge referenziert werden müsste (m), wobei fast zwangsläufig Zyklen, Kreise entstehen.
Rekursive mc:mc-Beziehungen sind aufgrund der Normalisierung verboten und müssen mittels
einer Beziehungsmenge aufgelöst werden. Dabei entsteht das Verbundinstrument, wie es im
Kapitel '6.4. Aggregation' auf Seite 63 beschrieben wird. Es verbleiben demnach nur die beiden
anfangs genannten Beziehungstypen.
Durch die rekursive Referenz für sich ist noch keine innere Strukturierung der Entitäten vorgegeben (innerhalb der Entitätsmenge). D.h. die Entitäten können, zumindest von aussen betrachtet,
kreuz und quer Referenzen aufbauen. Eine rekursive c:c-Beziehung lässt allerdings höchstenfalls
paarige Verknüpfungen von Entitäten zu, denn einer Entität kann höchstens eine Entität zugeordnet werden. So liesse sich in der Entitätsmenge der Kunden z.B. festhalten, welches der Lebenspartner des Kunden ist.
Lebenspartner
Kunden
Kunden
verbunden m it
verbunden m it
verbunden m it
Figur 18: Paarbildung durch rekursive c:c-Beziehung
Kunden
Kunden#
K-000001
K-000002
K-000003
K-000004
Lebenspartner
K-000003
<NULL>
<NULL>
<NULL>
Name
Gurtsdatum
Geschlecht
Müller
Meier
Sieber
Egli
7. März
4. Juli
12. März
20. Januar
männlich
männlich
weiblich
männlich
Tabelle 18: Entitätsmenge bei der rekursiven c:c-Beziehung
Eine rekursive c:mc-Beziehung erlaubt fast alle Möglichkeiten der Verknüpfung. Eine Entität kann
aber im Maximum genau eine Entität referenzieren, dadurch lassen sich nur bestimmte Netzstrukturen bilden. Grundsätzlich können nun daraus dennoch beliebig viele Grundstrukturen (inTeil 2: Konzeptionelle Datenmodellierung
62
nerhalb der selben Entitätsmenge) gebildet werden. In der Praxis sind zwei Strukturen häufig. Die
erste ist jene, in welcher die Entitäten beliebig miteinander verknüpft werden können. Dabei
entsteht ein oder auch mehrere voneinander unbhängige Netzwerke von verbundenen Entitäten (dabei besteht kein Zusammenhang zu netzwerkartigen Datenbanksystemen). So kann
z.B. festgehalten werden, welcher Sachbearbeiter welchen Sachbearbeiter bei Absenz vertritt.
Von aussen betrachtet scheinen die Entitäten aber keinem Ordnungsprinzip untergeordnet.
Sachbearbeiter
Stellvertretung
Sachbearbeiter
Stellvertretung
vertritt
vertreten durch
Figur 19: Rekursive c:mc-Beziehung ohne innere Strukturierung
Sachbearbeiter
Sachbearbeiter#
1
2
3
4
Name
Stellvertretung
Jäggi
Wick
Schär
Pfeiffer
2
3
1
2
Tabelle 19: Entitätsmenge der rekursiven c:mc-Beziehung ohne innere Strukturierung
Vielfach wird mittels rekursiver c:mc-Beziehungen eine hierarchische Struktur der Entitäten erstellt, die zweite mögliche Grundstruktur rekursiver c:mc-Beziehungen. Bei einer hierarchischen
Grundstruktur hat eine Entität maximal eine übergeordnete Entität. Nur die Entität der obersten
Hierarchiestufe hat keine übergeordnete Entität mehr. Dabei können wiederum mehrere voneinander unabhängige Hierarchien innerhalb einer einzigen Entitätsmenge gebildet werden. Hätte eine Entität mehr als eine übergeordnete Entität, würde daraus wieder die oben gezeigte
Netzwerkstruktur. Daher kann die hierarchische Struktur auch als Spezialfall der Netzwerkstruktur
betrachtet werden. So kann z.B. festgehalten werden, wie sich die Organisationseinheiten einer
Unternehmung hierarchisch gliedern, wie Hauptkonten der Buchhaltung in Konten und wieder
in Unterkonten gegliedert werden.
Organisationseinheiten
Organisationsstruktur
untergeordnete
Einheit
Figur 20: rekursive c:mc-Beziehung zur Hierarchiebildung
Einheiten_Id
Bezeichnung
OrgEDV
Organisation und EDV
Übergeordnete_Einheit
GeschLeit
Organisationsstruktur
übergeordnete Einheit
EntWart
RechZen
SysProg
Entwicklung und Wartung
Rechenzentrum
Systemprogrammierung
63
OrgEDV
OrgEDV
RechZen
Tabelle 20: Entitätsmenge der rekursiven c:mc-Beziehung zur Hierarchiebildung
Natürlich könnte die selbe Hierarchie auch mittels mehrerer Entitätsmengen, welche mit dem
Verbundinstrument Hierarchie verknüpft werden, erzeugt werden. Dabei würden einerseits aber
Entitäten der selben Art in mehreren Entitätsmengen verwaltet, andererseits wäre die Struktur
der Hierarchie fest vorgegeben und Änderungen der Hierarchie (z.B. der Gliederungstiefe)
könnten nur mit grossem Aufwand vollzogen werden.
Die Problemstellung bei rekursiven Beziehungen ist immer von der selben Art. Wie soll die gewählte innere Strukturierung, welcher Art auch immer, gewährleistet werden? Durch die innere
Struktur, d.h. durch die Fremdschlüssel, ist die Einhaltung der Strukturierungsregel bei diesem
Verbundinstrument nicht garantiert. Damit muss diese durch ergänzende Regeln, Integritätsregeln garantiert werden. Diese Integritätsregeln sind Teil des Datenmodells. Falls möglich,
werden diese Integritätsregeln bei der physischen Definition der Datenstruktur direkt im Datenbanksystem definiert. Im schlechteren Fall müssen diese in der Anwendung in den Programmen
sichergestellt werden. In den gezeigten drei Grundstrukturen ist die Definition der Integritätsregeln selbst einfach.
 Paarbildung: Bei c:c-Beziehungen muss garantiert werden, dass nur eine Entität der
beiden verknüpften Entitäten effektiv einen Eintrag im Fremdschlüssel hat, oder dass
dieser auch tatsächlich auf den anderen Partner zeigt.
 Netzstruktur: In der Netzstruktur ist keine Integritätsregel notwendig, sämtliche Verknüpfungen sind erlaubt.
 Hierarchische Struktur: Die hierarchische Struktur ist sichergestellt, falls keine
zyklischen Verknüpfungen der Entitäten vorhanden sind. Beim Einfügen von Entitäten oder beim Ändern des Fremdschlüssels einer Entität muss daher lediglich geprüft werden, ob dadurch ein Zyklus entsteht.
 An dieser Stelle sei erneut auf die Problematik von Fremdschlüsseln in c:-Beziehungen hingewiesen, siehe auch Kapitel '4.2.4. Assoziationstypen, Beziehungstypen' auf Seite 31.
6.4. Aggregation
Bei der Aggregation (zu lat. aggregare "beigesellen") werden, ganz ähnlich zur Rekursion, die
Entitäten einer Entitätsmenge netzwerkartig verknüpft, einander beigesellt. Während bei der
Rekursion eine Entität nur eine einzige Entität referenzieren kann, kann in der Aggregation eine
einzelne Entität beliebig viele Entitäten referenzieren. Dadurch können alle denkbaren Netzstrukturen gebildet werden (die Rekursion kann als Spezialfall der Aggregation aufgefasst werden), was bei der Rekursion nicht möglich war. Bei der Aggregation wird eine Beziehungsmenge eingefügt, welche eine selbstbezügliche mc:mc-Beziehung ermöglicht. Die m:m-Beziehung ist, entsprechend den Ausführungen zur Rekursion, bei diesem Verbundinstrument nur in
den seltensten Fällen sinnvoll.
Die bekannteste Verwendung der Aggregation ist die Stückliste. Bei der Stückliste werden Stücke (z.B. die Kaffeemaschine) verwaltet, welche sich aus anderen Einzelteilen (z.B. Wasserbehälter, Pumpe, Schraube M6/5, ...) zusammensetzt. Dabei kann das selbe Stück, wie zu erwarten, mehrfach bei der Herstellung unterschiedlicher Stücke verwendet werden.
64
Stücke
Oberteil
Stücke
Unterteil
Stückstrukturen
Oberteil
Unterteil
Stückstrukturen
Figur 21: Darstellung der Aggregation
Stücke
Stück#
57120
76342
36234
77982
90871
Bezeichnung
Kaffeemaschine
Pumpe
Wasserbehälter C-8.5
Dichtung K6-4
Schraube M6/5
Stückstrukturen
Oberteil
57120
57120
76342
76342
Unterteil
36234
76342
77982
90871
Menge
1
1
1
3
Tabellen 21: Entitätsmengen bei der Aggregation
Durch das Datenmodell selbst ist nicht sichergestellt, dass keine zyklischen (unerwünschten) Verknüpfungen entstehen. So könnte z.B. eingetragen werden, dass der Wasserbehälter Unterteil
von sich selbst ist. Es muss daher mittels einer Integritätsregel sichergestellt werden, dass zyklische Verknüpfungen verhindert werden (siehe auch '8. Integrität im konzeptionellen Modell' auf
Seite 83).
Im Beispiel erfolgt pro Unterteil ein einzelner Eintrag in die Entitätsmenge Stückstrukturen (z.B. für
die Schraube M6/5 3 Stück), auch wenn dieses mehrfach verwendet wird. Sollen für das einzelne Unterteil aber zusätzliche Informationen gespeichert werden (z.B. Planlage), so muss pro Unterteil ein Eintrag erstellt werden (im Beispiel wären das 3 Tupel).
 Häufig wird versucht, die Stückliste mittels einer selbstbezüglichen Beziehungsmenge zu bilden,
welche nicht nur zwei Fremdschlüssel, sondern so viele Fremdschlüssel wie Anzahl notwendige
Gliederungsstufen enthält. Meist werden dabei drei Fremdschlüssel, womit die maximale Gliederungstiefe von drei Stufen vorgegeben wird, in die Beziehungsmenge eingebettet. Diese Entitätsmenge enthält mit Sicherheit Redundanzen und ist damit in der konzeptionellen Datenmodellierung unerwünscht. Durch die vorgegebene Strukturierungstiefe der Stückliste hat das Modell zudem viel an Flexibilität verloren. Es ist nachträglich nur mit grossem Entwicklungsaufwand
möglich, Änderungen der vorgegebenen Strukturierungstiefe zu realisieren.
6.5. Spezialisierung/Generalisierung
Bei der Spezialisierung wird eine Entitätsmenge in mehrere Entitätsmengen zerlegt. Dabei werden Entitätsmengen mit spezifischeren Eigenschaften gebildet. So kann z.B. die Entitätsmenge
Valoren (Wertpapiere) in die Entitätsmengen Inhaberaktien, Namensaktien und Obligationen
aufgeteilt werden. Die ursprüngliche Entitätsmenge wird dabei nicht eliminiert. In dieser werden
die gemeinsamen Eigenschaften (Attribute) aller spezialisierten Entitätsmengen geführt, während die neuen Entitätsmengen nur die für sie spezifischen Eigenschaften führen. So sind in der
Entitätsmenge Valoren die Attribute Valoren-Nr, Bezeichnung, etc. zu finden, während in der Entitätsmenge Obligationen z.B. der Zinssatz, der Verfalltermin, etc. festgehalten werden. Dadurch
ist auch unmittelbar klar, dass die spezialisierten Entitätsmengen mit der Entitätsmenge, welche
65
die gemeinsamen Eigenschaften beinhaltet, verknüpft werden müssen. Dabei wird jede spezialisierte Entitätsmenge mit genau einer 1:c-Beziehung mit der gemeinsamen Entitätsmenge verknüpft. Die spezialisierten Entitätsmengen werden dann häufig Subentitätsmengen, die ursprüngliche Entitätsmenge Superentitätsmenge bezeichnet. Die gesamten Eigenschaften einer
einzelnen 'Entität' sind dabei nur bekannt, falls die Eigenschaften beider Entitäten zusammen
betrachtet werden.
Valoren
können sein
können sein
können sein
Inhaberaktien
Nam enaktien
Obligationen
Valoren
können
sein
können
sein
Inhaberaktien
Nam enaktien
können
sein
Obligationen
Figur 22: Darstellung der Spezialisierung/Generalisierung
Valoren
Valoren#
103923
204432
532994
394001
AktienArt
Inhaberaktie
Obligation
Namenaktie
Inhaberaktie
Emittent
FantasyAG
FantasyAG
TranspoAG
Colour-It & Co. AG
AktuellerKurs
450,55
28,60
230,30
202,05
Inhaberaktien
Valoren#
103923
394001
Kaufkurs
420,30
210,10
Namenaktien
Valoren#
532994
Kunden#
K-0000005
Obligationen
Valoren#
204432
Zinssatz
Verfalltermin
4.75
31. Dezember
66
Tabellen 22: Entitätsmengen bei der Spezialisierung/Generalisierung
Bei der Generalisierung handelt es sich um das selbe Verbundinstrument, aber um den umgekehrten Vorgang. Wurden bei der Spezialisierung für eine einzelne Entitätsmenge Attribute in
mehrere spezialisierte Entitätsmengen ausgelagert, so werden bei der Generalisierung die gemeinsamen Attribute von Entitätsmengen in eine gemeinsame Entitätsmenge eingebracht. So
können z.B. die gemeinsamen Attribute (Name, Strasse, Ort, ...) der Entitätsmengen Kunden und
Angestellte in die Entitätsmenge Partner eingebracht werden.
Auf konzeptioneller Ebene ist die möglichst detaillierte und realitätsnahe Gliederung der Entitätsmengen wünschenswert. Wird zur Darstellung des Sachverhalts die obige Notation verwendet, so droht die Gefahr, dass das Datenmodell unübersichtlich und damit schlecht lesbar
wird. Ausserdem ist es mittels der bisherigen Instrumente nicht möglich festzuhalten, ob im Datenmodell überlappende Entitätsmengen zugelassen sind oder nicht. So können sich zum Beispiel die Entitätsmengen Kunden und Angestellte überlagern, d.h. der Partner ist sowohl Kunde
als auch Angestellter und benötigt daher die Eigenschaften beider Subentitätsmengen (bereits
möglich). Ein Valor aber kann eine Namensaktie, aber niemals gleichzeitig auch Inhaberaktie
oder Obligation sein. Daher muss in diesem Fall ein gleichzeitiger Eintrag in beide Subentitätsmengen verhindert werden (noch nicht möglich).
In der Praxis sind zwei Ansätze zu finden, mittels welcher dieser Sachverhalt festgehalten werden
kann. Im ersten Ansatz werden die Entitätsmengen unverändert belassen, während die Darstellung der Beziehung verändert wird. Die betroffenen 1:c-Beziehungen, welche bisher unabhängig voneinander modelliert wurden, von welchen aber nur jeweils eine einzige verwendet werden darf, werden als eine 'gegabelte' Beziehung dargestellt:
Valoren
können sein
Inhaberaktien
Nam enaktien
Obligationen
Valoren
können
sein
Inhaberaktien
Nam enaktien
Obligationen
Figur 23: Darstellung Spezialisierung/Generalisierung mittels gegabelter Beziehungen
Bei dieser Darstellungsform wird der Sachverhalt korrekt widergegeben, aber das Datenmodell
verliert erneut an Übersichtlichkeit. Mit der zweiten Methode wird der Sachverhalt ebenfalls korrekt festgehalten, zusätzlich wird das Datenmodell aber kompakter, was insbesondere bei grösseren Modellen wünschenswert ist. Zur Darstellung der Mengen und deren Verhältnisse werden
die Teilmengen und die Schnittmengen (falls vorhanden) direkt grafisch veranschaulicht (entsprechend Mengenalgebra). Zwar können die 1:c-Beziehungen noch immer in das Modell eingetragen werden, in der Regel wird aber darauf verzichtet, da sich diese direkt aus dem Zu-
67
sammenhang heraus ergeben. Grundsätzlich können damit vier unterschiedliche Fälle auftreten:
Valoren
Inhaberaktien
Partner
Nam enaktien
Kunden
Obligationen
Teilmengen ohne
Überschneidung
Angestellte
Teilmengen mit
Überschneidung
Valoren
Inhaberaktien
Partner
Nam enaktien
Obligationen
Teilmengen mit vollständiger
Überdeckung ohne
Überschneidung
Kunden
Angestellte
Teilmengen mit vollständiger
Überdeckung mit
Überschneidung
Figur 24: Darstellung Spezialisierung/Generalisierung mittels Mengendarstellung
Wurde die zerlegte Entitätsmenge durch eine andere Entitätsmenge referenziert, so muss nach
der Zerlegung überlegt werden, welche Entitätsmenge neu referenziert werden soll. Und auch
im umgekehrten Fall muss überlegt werden, welche Entitätsmenge die Referenz behalten soll.
Dabei sollten Referenzen grundsätzlich so gewählt werden, dass die mögliche Menge der Entitäten möglichst klein ist. So muss z.B. für Namenaktien der Inhaber festgehalten werden (Aktienbuch), während bei Inhaberaktien dieser nicht verwaltet werden muss. Der Fremdschlüssel
(welcher den Inhaber referenziert) wird daher nicht in der Superentitätsmenge Valoren integriert, sondern besser in der Entitätsmenge der Namensaktien.
 NULL-Werte in einer Entitätsmenge in 3. Normalform sind häufig ein Hinweis darauf, dass die
betroffene Entitätsmenge mittels einer Spezialisierung in mehrere Subentitätsmengen zerlegt
werden kann. Die Attribute, in welchen NULL-Werte auftreten, werden dabei in die Subentitätsmengen ausgelagert. Dadurch treten in der ursprünglichen Entitätsmenge keine NULLWerte mehr auf. Bei der Erklärung von NULL-Werten wurde bereits darauf hingewiesen, dass
NULL-Werte unterschiedliche Bedeutungen haben können (siehe '4.3.3. NULL-Werte' auf Seite
35). Diese Zerlegung in Subentitäten ist immer dann sinnvoll, wenn der NULL-Wert die Bedeutung
'für diese Entität wird hier kein Wert eingetragen' hat und dieser spezielle Typ von Entität innerhalb der Entitätsmenge mehrfach auftritt.
6.6. Wertetabelle
Mittels der Wertetabelle (auch Code-Tabelle oder statische Tabelle) kann für Attribute ein dynamischer Wertebereich definiert werden. Die erlaubten Werte des Wertebereichs ändern sich
dabei mit der Zeit, was für einen normalen Wertebereich nicht unmittelbar möglich ist. So kann
z.B. in einer Wertetabelle festgehalten werden, mit welchen Strategien die Depots der Kunden
68
verwaltet werden (z.B. CH-Low-Risk-Fond). Wird eine neue Strategie hinzugefügt, bzw. eine alte
eliminiert, können diese Änderungen ohne Eingriff in das Datenmodell, d.h. die Definition der
Wertebereiche, vorgenommen werden. Zwischen der Wertetabelle und der Entitätsmenge,
welche die Wertetabelle verwendet, besteht eine 1:mc-Beziehung. Das Attribut, welches die
Wertetabelle als Wertebereich verwendet, ist dabei ein Fremdschlüssel, welcher die Wertetabelle referenziert.
VerwaltungsStrategien
verwendet
in
VerwaltungsStrategien
StrategieZuordnung
verwendet
in
Depots
haben
Depots
Figur 25: Darstellung der Wertetabelle
Depots
Depot#
Kunden#
DP-Akt-001001
DP-Akt-001231
DP-Akt-002342
DP-Akt-009786
K-000002
K-000001
K-000003
K-000003
Eröffnungsdatum
3. Juni
6. Juni
9. April
12. Januar
Saldierungsdatum
<NULL>
19.8.
<NULL>
<NULL>
Verwaltungsstrategie
CHLowRiskFond
USALowRiskFond
CHLowRiskFond
CHAktienAAA
Verwaltungsstrategien
Verwaltungsstrategie
ohne
CHLowRiskFond
USALowRiskFond
CHAktienAAA
Beschreibung
kein Verwaltungsauftrag
Aktienfonds Schweizer Firmen mit geringem Risiko
Aktienfonds USA Firmen mit geringem Risiko
Aktien von Firmen mit S&P-Rating AAA
Tabellen 23: Entitätsmengen bei der Wertetabelle
In der Wertetabelle werden häufig zusätzliche Attribute eingefügt, welche den Wert ausführlicher Beschreiben (z.B. 'Aktienfonds Schweizer Firmen mit geringem Risiko') oder welche die
Verarbeitung der Entitäten mittels Parametern zulassen (z.B. zur Steuerung der Verrechnungsart
der Managementgebühren).
Von aussen betrachtet mag die Wertetabelle zunächst wie das Verbundinstrument 'Hierarchie'
aussehen, inhaltlich handelt es sich aber um einen gänzlich anderen Sachverhalt (Semantik des
Modells). Dies äussert sich auch in einer Reihe von inhaltlichen Unterschieden. Während bei der
Hierarchie die Menge der Entitäten in der übergeordneten Entitätsmenge meist kontinuierlich
wächst, enthält die Wertetabelle relativ wenige und eine mehr oder weniger konstante Zahl von
Entitäten (dieser Umstand nimmt Einfluss auf die Herleitung des internen Modells). Ausserdem
werden in der Hierarchie zusammengehörige Entitäten zu einem ganzheitlichen Gebilde verknüpft, während bei der Wertetabelle lediglich Entitäten mit gleichen Eigenschaften versehen
werden.
In Datenmodellen treten zum Teil sehr viele Wertetabellen auf. Die Übersichtlichkeit des Datenmodells leidet darunter, obgleich die Wertetabellen meist wenig zum grundlegenden Verständnis des Modells beitragen. Häufig werden daher Wertetabellen in grossen Datenmodellen
überhaupt nicht dargestellt.
69
6.7. Variante Referenzierung 
Bisher wurde davon ausgegangen, dass Beziehungen zwischen Entitätsmengen unabhängig
voneinander modelliert werden können. Einzige Ausnahme war bisher das Verbundinstrument
Spezialisierung/Generalisierung (siehe '6.5. Spezialisierung/Generalisierung' auf Seite 64). In der
Praxis treten aber häufig Situationen auf, in welchen eine Beziehung je nach Fall die eine oder
andere Entitätsmenge verwenden soll.
So können z.B. Versandinstruktionen (wohin sollen die Kunden-Unterlagen verschickt werden)
auf Kundenebene festgehalten werden. Die Versandinstruktionen gelten dann auch für sämtliche dem Kunden untergeordneten Konti:
Versandinstruktionen
Versandart
festlegen
VersandartenZuordnung
Versandart
festlegen
haben
Kunden
Kunden
besitzen
besitzen
KundenKonti
Konti
gehören
Konti
Figur 26: Versandinstruktionen auf Kundenebene
Es kann aber auch auf Kontoebene festgehalten werden, wohin die Konto-Unterlagen je Konto
verschickt werden sollen. Es muss dann für jedes einzelne Konto des Kunden die Versandinstruktion definiert werden.
Kunden
Versandart
festlegen
besitzen
KundenKonti
gehören
Kunden
Versandart
festlegen
besitzen
haben
Konti
Konti
Figur 27: Versandinstruktionen auf Kontoebene
Keiner der beiden Ansätze lässt es zu, die Versandinstruktionen situationsgerecht zu vergeben
und damit vollständig und einfach zu verwalten. Wünschenswert ist daher ein Ansatz, der beide
Möglichkeiten fallweise, aber nicht gleichzeitig bietet. Wären beide Möglichkeiten gleichzeitig
70
erwünscht (was durchaus denkbar ist), würden natürlich zwei voneinander unabhängige Beziehungen zur Entitätsmenge Versandinstruktionen erstellt.
Während bei der Spezialisierung/Generalisierung die Darstellung des Sachverhalts mittels gegabelter Beziehung oder mittels Mengendarstellung möglich ist, kann hier nur eine Darstellung
mittels gegabelter Beziehungen angewandt werden. Für das Verbundinstrument variante Referenzierung ist damit etwa folgende Darstellung möglich (in der Praxis existiert keine einheitliche Darstellungsform!):
Versandart
festlegen
haben
Kunden
Versandart
festlegen
Kunden
besitzen
KundenKonti
besitzen
Konti
gehören
Konti
Figur 28: variante Referenzierung, Versandinstruktionen auf Kunden- oder Kontoebene
71
6.8. Checkfragen
1.
Bei der Rekursion...





2.
werden zwei Entitätsmengen mittels Fremdschlüssel rekursiv verknüpft.
wird eine mc:mc-Beziehung aufgelöst.
wird die 3. Normalform verletzt.
wird eine Entitätsmenge mit sich selbst mittels Fremdschlüssel verknüpft.
wird kein Fremdschlüssel benötigt.
Bei der Spezialisierung...





3.
A)
B)
C)
D)
E)
A)
B)
C)
D)
E)
werden Entitäten einer einzelnen Entitätsmenge mittels Attribut spezifiziert.
entsteht eine Super- und mehrere Subentitätsmengen.
entsteht eine selbstbezügliche Beziehungsmenge.
entstehen mehrere 1:-mc, bzw. 1:m-Beziehungen.
werden Entitäten hierarchisch geordnet.
Mit welchem Verbundinstrument wird die Stückliste realisiert?





A)
B)
C)
D)
E)
Hierarchie
Beziehungsstruktur
Rekursion
Aggregation
Generalisierung
1.
Bei der Hierarchie kann einer untergeordneten Entität nur genau eine Entität der übergeordneten Entitätsmenge zugeordnet werden, weil der Fremdschlüssel der Entität in der untergeordneten Entitätsmenge nur genau eine Entität referenzieren kann.
 A)
2.
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
Die Anzahl Entitätsmengen, welche mittels einer Beziehungsstruktur verknüpft werden können, ist beliebig, weil die Fremdschlüssel der untergeordneten Entitätsmenge immer als Entitätsschlüssel verwendet werden.
 A)
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
1.
Bei der Spezialisierung/Generalisierung...
+




2.




handelt es sich um die selben, aber umgekehrten Vorgänge.
werden Entitätsmengen eliminiert.
werden Super- und Subentitätsmengen gebildet.
werden Entitäten zyklisch verknüpft.
Bei der Aggregation...
+








wird ein Fremdschlüssel benötigt.
werden zwei Fremdschlüssel benötigt.
können alle Entitätsmengen Attribute enthalten.
handelt es sich um einen Spezialfall der Generalisierung.
72
3.
Subentitätsmengen...
+








enthalten den Entitätsschlüssel der Superentität als Fremdschlüssel.
sind Spezialisierungen der Superentität.
erben die Eigenschaften der Superentität.
dürfen nicht konditional mit der Superentität assoziiert sein.
73
6.9.1. Liversys, Liegenschafts-Verwaltungs-System
Schwierigkeitsgrad: Nichtschwimmer (Trockenübung, Planschbecken, Nichtschwimmer, Schwimmer)
Sie sind in einem Projekt zur Automatisierung einer Liegenschaftsverwaltung einer grösseren
Verwaltungsgesellschaft beschäftigt. Die Gesellschaft verwaltet die Liegenschaften verschiedener, ev. mehrerer Eigentümer und vermietet diese weiter (die kleinste Einheit für Eigentum ist
die Liegenschaft).
Liegenschaftsaufbau: In der Regel enthält eine Liegenschaft mehrere Häuser bzw. Wohnungen.
Jedes Haus hat, innerhalb der Ortschaft, eine eindeutige Hausnummer. Zusätzlich hat jedes
Haus einen oder aber auch mehrere Ausgänge und liegt damit eventuell an mehreren Strassen
und hat mehrere Strassennummern (die Hausnummer hat nichts mit der Strassennummer gemeinsam).
Mietobjekte: Das Haus selbst kann wieder über mehrere Mietobjekte verfügen, über die mit einem oder mehreren Mietern ein Mietvertrag abgeschlossen wird. Dabei müssen auch Garagen,
Parkplätze, Kellerabteile etc. erfasst werden können. Ein Mietvertrag kann mehrere Mietobjekte
umfassen, kann aber auch mehrere Mieter einbeziehen.
1. Entwickeln Sie das grafische, konzeptionelle Datenmodell.
2. Erstellen Sie einen Attributskatalog der notwendigen und weiterer möglicher Attribute.
3. Erweitern Sie den Attributskatalog sowie das Datenbankstrukturdiagramm um die
Entitätsmenge Hauswarte.
4. Zeichnen Sie je ein externes Schema für die Funktionen: 'Mutation von Mietverträgen' und 'Mutation von Eigentümer'.
6.9.2. Transpo, Transport-Verwaltungs-System
Die Transpo AG ist ein grosses Transportunternehmen, das in den meisten Ländern Europas Filialen betreibt. Die zu transportierenden Waren werden von der Transpo AG jeweils durch die
nächstgelegene Filiale (mit eigenen Transportmitteln) beim Kunden abgeholt und zunächst im
lokalen Lager der Filiale (jede Filiale verfügt über genau ein Lager) zwischengelagert. Die Transportaufträge (nicht die Ware) werden dann in die Dispositionszentrale des eigenen Landes geschickt. Jedes Land besitzt eine eigene Dispositionszentrale, eine ausgewählte Filiale. Für länderübergreifende Transporte werden die Aufträge in die in der Schweiz gelegene Dispositionszentrale geschickt. Viele der Auftraggeber und deren Empfänger gehören zu den ständigen
Kunden der Transpo AG (siehe auch Beispieldaten auf den folgenden Seiten).
In der Dispositionszentrale wird dann versucht, die einzelnen Aufträge optimal zu kombinieren,
wobei insbesondere der letzte erlaubte Auslieferungstermin beachtet werden muss. Für den
Transport der Waren werden Zugverbindungen, Fluggesellschaften und eigene Fahrzeuge eingesetzt. In einem ersten Schritt werden die Waren in die dem Zielort am nächsten liegende Filiale transportiert. Von dieser Filiale aus werden die Waren mit den eigenen Transportfahrzeugen
ausgeliefert.
Die Empfänger werden über die Lieferung wenn zeitlich möglich per Post, ansonsten per Telefon
informiert. Für sämtliche Transporte müssen die Routen und die Auslastung der Fahrzeuge geplant werden. Die Planung der Fahrstrecke und der Ladung der Fahrzeuge erfolgt manuell.
74
Die Transpo AG verfügt zur Zeit über drei Kategorien von Fahrzeugtypen (A, B und C), für welche
die Fahrer die notwendige Qualifikation ausweisen müssen.
Für die Lieferung von Filiale zu Filiale wird in einer Tabelle festgehalten, welches die Transportmittel und welches die Transportkosten je kg Ware sind. Die Berechnung der Kosten der Abholung und Anlieferung erfolgt aufgrund der Anzahl km sowie dem Gewicht der Materialien.
Folgende Listen und Tabellen werden zur Zeit geführt (Beispiellisten siehe unten):
 Transportauftrag: Wird pro Auftrag geführt und beinhaltet die Artikel eines Kunden,
die ausgeliefert werden sollen (siehe Beispiel).
 Abholliste: Enthält die Artikel und Auftraggeber, bei welchen auf einer Fahrt die Artikel abgeholt und ins lokale Lager transportiert werden.
 Transferliste: Enthält die Artikel, welche von einer Filiale auf einer Fahrt in die anderen
Filialen transportiert werden bzw. an entsprechende Verladestellen gebracht werden.
 Lieferliste: Enthält die Artikel, welche von einer Filiale auf einer Fahrt zu den Empfängern gebracht werden (siehe Beispiel).
 Transportkosten und Transportartenliste: Hält fest, wie die Artikel zwischen Kunden
und Filiale bzw. zwischen Filialen transportiert werden und was der Transport kostet
(siehe Beispiel).
 Rechnung: Verrechnung der im Transportauftrag aufgeführten Lieferungen (siehe
Beispiel).
 Empfangsbestätigung: Was erhält der Empfänger in einer Lieferung?
Aufgaben:
1. Erstellen Sie das grafische, konzeptionelle Datenmodell und den Attributskatalog der
Transpo AG.
2. Verwenden Sie den Fragenkatalog im Kapitel '13.4. Kontrollfragen zum konzeptionellen Datenmodell' auf Seite 150, um das konzeptionelle Datenmodell zu überprüfen.
3. Tragen Sie die Beispieldaten der beiliegenden Listen in Ihr Modell ein (Tabellen aufzeigen).
4. Normalisieren Sie (erste drei Normalformen) das konzeptionelle Datenmodell der
Transpo AG.
5. Externe Schemata der Transpo AG erstellen für:
 Fahrer modifizieren
 Auftrag erfassen
 Lieferliste erstellen
Transportauftrag
Auftraggeber:
Auftragsnummer:
Rufi AG
Langackerstr. 12
9001 St.Gallen, Schweiz
Tel: 071: 225 40 90
7721
Auftragsdatum:
12. Mai
Abholdatum:
2. Juni
Artikelbezeichnung, Masse,
Menge, Gewicht
Empfänger
Spätestes
Lieferdatum
1.
Schreibmaschine, 30x20x15 cm,
3 Stück, 0.4 kg je Stück
Flexi AG
Bächliweg 8
8001 Zürich, Schweiz
Tel: 01- 363 89 56
14. Juni
2.
Bürostuhl Vario, 50x50x80 cm,
2 Stück, 16 kg je Stück
Blusara AG
Querstrasse 20
Tel: 01- 223 11 54
12. Juni
3.
... (weitere Auftragspositionen)
...
Lieferliste
Uhrzeit, Datum:
Fahrer:
Fahrzeugtyp:
Material-Nr.
75
Liefernummer:
1722
Routennummer:
2341
8:00 Uhr; 12. Juni
Mario Donati. Filiale Zürich, Personalnr. 403
LW 2-1, ZH 244 684
Artikelbezeichnung
Empfänger
1.
23509
Flexi AG
Bächliweg 8
Tel: 01- 363 89 56
2.
23798
Fahrräder, ca. 150x40x100 cm,
Velos und Mofas Müller
Runzelstrasse 879
Tel: 01 - 296 78 39
3.
...
(weitere Positionen)
76
Rechnung
Auftraggeber:
Rechnungsnummer:
Rufi AG
Langackerstr. 12
9001 St.Gallen, Schweiz
Tel: 071: 225 40 90
4679
Auftragsdatum:
12. Mai
Abholdatum:
2. Juni
Rechnungsdatum:
30. Juni
Artikelbezeichnung, Masse,
Menge, Gewicht
Empfänger
Kosten je
Position
1.
Flexi AG
Bächliweg 8
Tel: 01- 363 89 56
25.40
2.
Bürostuhl Vario, 50x50x80 cm,
2 Stück, 16 kg je Stück
Blusara AG
Querstrasse 20
Tel: 01- 223 11 54
34.40
3.
... (weitere Auftragspositionen)
...
...
Total
254.30
Transportkosten und Transportartenliste
Von (Auftraggeber,
Empfänger bzw.
Filiale)
Nach (Filiale)
Art
Distanz in
km
Kosten
pro kg
Die Verechnung erfolgt entweder je kg oder je km. Bei der Verrechnung je km ist der Kostenansatz fest: 0.30 Fr. /kg /km. Die Kosten für
die umgekehrte Reiserichtung sind jeweils identisch.
Filiale Russikon
Filiale St.Gallen
Lastwagen
Schweizer Verband der
Färbereien,
9303 Wittenbach SG
Filiale St.Gallen
Lastwagen
8.5
Technikum Winterthur,
Technikumsstrasse 12,
9400 Winterthur
Filiale Winterthur
Lastwagen
1.5
Filiale St.Gallen
...
Zug
Figur 30: Beispiellisten zur Übung Transpo
10.-
23.50
7. Spezielle Problemstellungen des konzeptionellen Modells
77
7. Spezielle Problemstellungen des konzeptionellen Modells 
In diesem Kapitel werden Problemstellungen und Fragen, wie sie in der konzeptionellen Modellierung häufig auftreten, besprochen und deren möglichen Lösungsansätze gezeigt.
7.1. Mengenprobleme im Verbundinstrument Beziehungsstruktur
In diesem Kapitel soll gezeigt werden, wie Mengenprobleme im Verbundinstrument Beziehungsstruktur gemildert werden können. Dabei werden nicht Mengenprobleme besprochen, welche
die Performance der Datenbank beeinflussen, denn diese werden beim Herleiten des internen
Modells betrachtet. Hier werden Mengenprobleme diskutiert, welche den Benutzer einzig in der
Handhabung der Daten behindern.
Bei der Erstellung einer Beziehung können in der Beziehungsmenge sehr viele Entitäten auftreten. Falls eine Entität eine Entität der anderen Entitätsmenge höchstens ein Mal referenzieren
darf, sind im Maximum Anzahl Entitäten der Entitätsmenge A mal Anzahl Entitäten der Entitätsmenge B möglich. Enthält A 100'000 und B 50'000 Entitäten sind bereits 5'000'000'000 Entitäten in
der Beziehungsmenge möglich. Falls eine Entität die selbe Entität der referenzierten Entitätsmenge mehrfach verwenden darf, können sogar beliebig viele Entitäten in der Entitätsmenge
auftreten. Abgesehen davon, dass in dieser Situation technische Probleme auftreten können, ist
auch der Benutzer in der Verwaltung der Daten gefordert.
Ein typisches Problem der Informatik ist die Zuordnung von Zugriffsrechten zu Benutzern. Enthält
die Anwendung z.B. lediglich 1'000 Funktionen und 200 Benutzer, wobei jeder Benutzer im
Durchschnitt 100 Zugriffsrechte zu den Funktionen erhält, so muss der Verantwortliche 20'000 Zugriffsrechte verwalten. Hierbei die Übersicht zu behalten und allen Benutzern die notwendigen,
aber keine überflüssigen Rechte zu erteilen, fällt schwer. Ausserdem müssen für jeden neuen
Benutzer 100 Zugriffsrechte im System erfasst werden.
Zugriffsrechte
Benutzer
vergeben
an
erhalten
Zugriffsrechtvergaben
Zugriffsrechte
Benutzer
vergeben
an
erhalten
Figur 29: Zugriffsrechtvergabe an Benutzer
Die Lösung für dieses Problem liegt auf der Hand und wird in der Praxis häufig angewendet. Die
Zugriffsrechte werden mittels einer übergeordneten Entitätsmenge (Hierarchie, Zugriffsrechtgruppe) strukturiert und die Benutzer werden nicht mehr unmittelbar den Zugriffsrechten
zugeordnet, sondern der Entitätsmenge Zugriffrechtsgruppen. Ein einzelner Benutzer kann hierbei natürlich mehreren Zugriffrechtsgruppen zugeordnet werden.
78
Benutzer
zugeteilt zu
Gruppenzuordnungen
beinhalten
Zugriffsrechte
Zugriffsrechtgruppen
vergeben
an
erhalten
Benutzer
zugeteilt zu
Zugriffsrechte
Zugriffsrechtgruppen
vergeben
an
erhalten
Figur 30: Zugriffsrechtvergabe an Benutzer mittels Zugriffsrechtgruppen
Bei der Modellierung von Beziehungsmengen im konzeptionellen Modell sollte auf eine effiziente
und überschaubare Handhabbarkeit von Beziehungsmengen geachtet werden. Dadurch kann
die Qualität der Anwendungen aus Sicht der Benutzer oft deutlich gesteigert werden.
7.2. Historisierung von Daten
Ein in der Praxis häufiges Problem ist die vollständige Rekonstruktion des Datenbestandes für einen bestimmten Zeitpunkt bzw. der Nachvollzug aller Änderungen innerhalb einer bestimmten
Periode (z.B. Aktienbestand des Depots per Vormonat, Zu- bzw. Abfluss an finanziellen Mitteln
innerhalb des letzten Monats). Dabei ist klar, dass bei sämtlichen Änderungen die vorherigen
Daten in irgendeiner Art und Weise erhalten bleiben müssen, ansonsten ist eine Rekonstruktion
nicht mehr möglich.
Im Folgenden werden Methoden aufgezeigt, wie diese historischen Daten im Datenmodell
festgehalten werden können. Grundsätzlich ist auch denkbar, dass das Datenbanksystem die
historischen Daten gänzlich selbständig verwaltet. Gängige relationale Systeme bieten diese
Möglichkeit allerdings nicht, so dass das Problem durch den Entwickler bzw. Datenmodellierter
gelöst werden muss.
Sämtliche unten aufgeführten Methoden gehen davon aus, dass der Entitätsschlüssel unveränderlich sei. Die historischen und aktuellen Daten einer Entität werden nämlich mittels des selben Entitätsschlüsselwertes verknüpft. Es sollten daher auch keine Entitätsschlüsselwerte von bereits gelöschten Entitäten verwendet werden.
79
7.2.1. Periodenstempel
Sämtliche Entitäten, für welche historische Daten geführt werden sollen, werden mit einem Periodenstempel ergänzt. Dieser hält fest, ab wann (Gültig-Ab-Zeitstempel) und bis wann (GültigBis-Zeitstempel) die Entität Gültigkeit hatte. Beim Erzeugen, Ändern oder Löschen der Entitäten
müssen die entsprechenden Zeitstempel gesetzt werden.
 Einfügen: Der Gültig-Ab-Zeitstempel wird mit dem Datum und der Systemzeit (die
Uhrzeit ist allenfalls zu ungenau) der Einfügeoperation versehen.
 Ändern: Bei der zu verändernden Entität wird der Gültig-Bis-Zeitstempel gesetzt, ohne dass die Entität tatsächlich geändert wird. Zum Festhalten der Änderungen wird
die ursprüngliche Entität kopiert (ohne Gültig-Bis-Zeitstempel) und bei der neuen Entität der Gültig-Ab-Zeitstempel auf den selben Wert gesetzt, wie der Gültig-BisStempel der ursprünglichen Entität.
 Löschen: Beim Löschen wird lediglich der Gültig-Bis-Zeitstempel gesetzt.
Wird der Periodenstempel eingesetzt, muss innerhalb der Anwendung sichergestellt werden,
dass nur jeweils die aktuellen bzw. die gewünschten historischen Daten angezeigt werden. Die
Datenstruktur des konzeptionellen Modells selbst ändert sich nicht, es müssen lediglich die notwendigen Attribute in jene Entitätsmengen eingefügt werden, für welche historische Daten gesammelt werden sollen.
Ein Problem stellt sich allerdings. Der Entitätsschlüssel der derart erweiterten Entitätsmengen ist
nicht mehr eindeutig. Durch Erweitern des Entitätsschlüssels mit dem Datum-Ab-Zeitstempel ist
dieser wieder eindeutig. Dadurch müssen aber sämtliche Fremdschlüssel, welche den Entitätsschlüssel referenzieren, genauer untersucht werden. Grundsätzlich müssten alle Fremdschlüssel
ebenfalls mit dem Datum-Ab-Zeitstempel der referenzierten Entitätsmenge erweitert werden.
Dabei stellt sich jedoch das Problem, dass nicht immer die aktuellste Version referenziert wird,
falls nicht auch der Fremdschlüssel stetig nachgeführt wird. Dieser Ansatz ist daher nur für Datenbanksysteme sinnvoll, welche eine Fremdschlüsseldefinition zulassen, welche nicht ausschliesslich auf der Wertebereichsdefinition des Fremdschlüssels durch die Entitätsschlüsselwerte
basiert, sondern welche mit einer Bedingung (im Bsp.: immer die aktuell gültige Version verwenden) verknüpft werden kann (siehe interne Ebene). An dieser Stelle ist damit eine Kenntnis des
Datenbanksystems bereits auf der konzeptionellen Ebene von Vorteil. Im Kapitel '7.2.3. Auslagerung historischer Daten' auf Seite 80 wird ein Ansatz aufgezeigt, welcher diesen Nachteil nicht in
sich birgt, daher für sämtliche Datenbanksysteme geeignet ist.
7.2.2. Gültig-Ab- und Lösch-Zeitstempel
Die Methode des Periodenstempels brilliert durch ihre Einfachheit. Bei Datenbanksystemen mit
hoher Belastung (Transaktionslast) ist es aber aus Performancegründen unerwünscht, dass bei
Änderungsoperationen auch eine Änderungsoperation des Gültig-Bis-Zeitstempels an der ursprünglichen Entität vorgenommen werden muss. Daher wird der Gültig-Bis-Zeitstempel aufgegeben. Der Zeitpunkt, bis zu welchem eine Entität gültig war, ergibt sich ja aus dem Gültig-AbZeitstempel der zeitlich nachfolgenden Entität.
Man könnte nun versucht sein zu behaupten, der Gültig-Bis-Zeitstempel des Periodenstempels
berge lediglich Redundanzen, daher könne dieser vernachlässigt werden. Dies ist nicht der Fall.
Ohne Gültig-Bis-Stempel kann nicht mehr festgestellt werden, ob eine Entität gelöscht worden
ist. Es muss daher ein Lösch-Zeitstempel in die Entitätsmenge eingefügt werden.
 Einfügen: Der Gültig-Ab-Zeitstempel wird gesetzt.
 Ändern: Der Gültig-Ab-Zeitstempel wird gesetzt.
 Löschen: Beim Löschen wird der Lösch-Zeitstempel gesetzt.
Der Lösch-Zeitstempel enthält damit in allen historischen Entitäten, abgesehen von der letzten
gelöschten Entität, NULL-Werte. Vergleicht man die Lösung, fällt die Ähnlichkeit zum Periodenstempel auf. Mit dem Vorteil, dass bei Änderungsoperationen die ursprüngliche Entität
80
nicht geändert werden muss, ist gleichzeitig ein Nachteil aufgetaucht. Bis wann eine historische
Entität gültig war oder ob die Entität noch gültig ist, kann erst festgestellt werden, wenn die zeitlich nächste Entität gelesen wird. Dies kann in den Auswertungen deutlich ins Gewicht fallen. Eine generelle Aussage zugunsten dieser Methode oder des Periodenstempels kann daher nicht
gemacht werden, es muss einmal mehr von Fall zu Fall entschieden werden.
Für diesen Ansatz gelten die selben Bemerkungen zum Problem des Entitätsschlüssels und der
Fremdschlüsselreferenzen, wie diese bereits im Kapitel '7.2.1. Periodenstempel' gemacht wurden.
7.2.3. Auslagerung historischer Daten
Anstatt die historischen Entitäten in der selben Entitätsmenge zu belassen, werden sie in diesem
Ansatz in eine separate Entitätsmenge ausgelagert. Die aktuelle Version der Entität verbleibt in
der ursprünglichen aktuellen Entitätsmenge. Die Datenstruktur der historischen Entitätsmenge
muss erweitert werden. Hierfür stehen wiederum die beiden vorgängig besprochenen Varianten
mit den jeweiligen Vor- und Nachteilen offen.
Bei diesem Ansatz stellt sich das Problem des Entitätsschlüssels, im Gegensatz zu den beiden
vorherigen Varianten, nicht. Der Entitätsschlüssel der aktuellen Entitätsmenge muss nicht geändert werden; lediglich der Entitätsschlüssel der historischen Entitätsmenge muss ergänzt werden.
Fremdschlüsselreferenzen zur aktuellen Entitätsmenge können unverändert übernommen werden.
Durch die Trennung der aktuellen von den historischen Daten ist es auch leicht möglich, diese
auf physisch unterschiedlichen Speichermedien abzulegen. Die historischen Daten können daher, falls diese nur gelegentlich verwendet werden, auf einem billigeren, dafür langsameren
Speichermedium abgelegt werden.
Es ist auch denkbar, nicht nur die historischen Daten in die Entitätsmenge auszulagern, sondern
jeweils auch eine Kopie der aktuellen Entität auszulagern. Dadurch beinhaltet die ausgelagerte
Entitätsmenge nicht nur historische Informationen zu einer Entität, sondern immer deren gesamten bisherigen Lebenslauf. Damit kann häufig die technische Erzeugung und applikatorische
Verarbeitung der Auslagerungsdatei vereinfacht werden. Hierbei entstehen Redundanzen,
welche allerdings keine Gefahr für die Datenbasis darstellen, da diese Redundanzen immer korrekt sind.
7.2.4. Auslagerung der Änderungen
Sollen für bestimmte Attribute die Änderungen an den Entitäten festgehalten werden, für andere Attribute aber nicht (z.B. aufgrund von Datenschutzüberlegungen), so werden in die ausgelagerte historische Entitätsmenge nur jene Attribute aufgenommen, für welche die Änderungen
nachvollzogen werden können müssen. Die Gültigkeitsperiode der ausgelagerten Änderungen
wird entsprechend der Auslagerung historischer Daten festgehalten.
Sollen die Änderungen sowie der letzte vollständige Zustand auch nach dem Verfall der Entität
noch nachvollzogen werden können, so darf die Entität beim Verfall nicht physisch gelöscht
werden. Sie muss auch nach der Löschung, entsprechend gekennzeichnet (z.B. 'Status gelöscht'), in der Entitätsmenge verbleiben (einige Datenbanksysteme unterstützen die Verwaltung gelöschter Entitäten).
7.3. Migration von Informationen
Bei der Migration werden Informationen von einem Datenbanksystem auf ein anderes Datenbanksystem übertragen. Dies ist eine höchst anspruchsvolle Aufgabe. Ob die zu übertragenden
Informationen aus einem alten oder aus einem fremden System (z.B. eingekaufter Adressenstamm) stammen, ist dabei eher nebensächlich. Für eine erfolgreiche Migration müssen zunächst die konzeptionellen Modelle sowie die Geschäftsprozesse beider Systeme exakt bekannt
sein.
81
Sind die entsprechenden Kenntnisse über die konzeptionellen Modelle und die Geschäftsprozesse aufgebaut worden, so können der Zeitplan und die Migrationsregeln erstellt werden. In
den Migrationsregeln wird definiert, wie die Entitäten und deren Attribute des Zielsystems mittels
der Informationen des Ausgangssystems gefüllt werden müssen. Im einfachsten Fall entsprechen
sich Entitäten und Attribute beider Systeme und können 1:1 übernommen werden. Meist ist dies
jedoch nicht der Fall. Selbst wenn zwei Attribute in beiden Systemen in den selben Entitätsmengen auftreten, stimmen häufig deren Domänen nicht überein. In diesem Fall muss überprüft
werden, ob bei der Übertragung der Daten keine Informationen verloren gehen und im Fehlerfall ein entsprechendes Protokoll erzeugt werden (z.B. numerischer Überlauf). Es kann aber auch
sein, dass ein Attribut des Zielsystems aufgrund von Informationen von mehreren Attributen in
unterschiedlichen Entitätsmengen des Ausgangssystems hergeleitet werden muss. Diese Herleitung ist dann meist aufwendig und mit grosser Unsicherheit belastet. Häufig tritt auch der Fall
auf, dass eine Entität des Ausgangssystems mehrere Entitäten im Zielsystem verlangt (oder umgekehrt). Die Definition der Migrationsregeln verlangt daher eine sehr gute Kenntnis beider Systeme.
Für den Entscheid über das weitere Vorgehen und zur Bereitstellung des notwendigen Externspeichers müssen im nächsten Schritt die zukünftigen Datenmengen ermittelt werden. Diese lassen sich mit Hilfe der Migrationsregeln meist recht leicht berechnen.
Aufgrund der Migrationsregeln und der Datenmengen muss nun entschieden werden, mit welchem Verfahren die Informationen auf das neue System übertragen werden sollen. Dabei sind
grundsätzlich das manuelle und das maschinelle Verfahren möglich sowie entsprechende
Mischformen. In der Praxis zeigt sich immer wieder, dass Aufwandschätzungen zur Erstellung von
Migrationsprogrammen deutlich zu tief liegen. Bei ähnlich grossen Aufwandschätzungen (Kosten) sollte daher eher die manuelle Form bevorzugt werden.
Die Migration selbst erfolgt meist in zwei Schritten. Im ersten Schritt werden die Informationen
des Ausgangssystems extrahiert und in sequentiellen Dateien gespeichert bzw. auf Listen ausgegeben. Im zweiten Schritt werden diese Daten in das Zielsystem übertragen (maschinell bzw.
manuell). Falls der direkte Zugriff auf beide Systeme möglich ist, können die Informationen auch
ohne Zwischenschritt übertragen werden. Bei der Extraktion der Daten in sequentielle Dateien
sollten diese soweit möglich, falls eine maschinelle Migration geplant ist, ohne Änderungen in
die sequentiellen Dateien übertragen werden. Dadurch muss bei einer allfällig notwendigen
Korrektur der Migrationsprogramme nur der zweite Teil der Migration wiederholt werden. Der
Zeitverlust durch die erneute Migration kann damit in Grenzen gehalten werden. Während der
Migration müssen vielfach zusätzliche Protokolle erstellt werden. Diese dienen der Revision der
Migration. Diese Protokolle erfordern manchmal einen Aufwand, der die eigentliche Migration
der Informationen übersteigt.
Nach der Migration der Daten muss deren Qualität kontrolliert werden. Einerseits können Entitätsintegrität, referentielle Integrität und benutzerdefinierte Integritätsregeln überprüft werden,
sofern dies nicht bereits durch das Datenbanksystem erfolgt. Andererseits müssen die Daten
durch fundierte Testverfahren auf deren Qualität hin untersucht werden. Auf Testverfahren kann
an dieser Stelle nicht eingegangen werden, hierfür muss entsprechende Literatur zur Hand genommen werden. Der gesamte Ablauf der Migration stellt sich damit wie folgt dar:
1. Ermittlung der konzeptionellen Modelle und der Geschäftsprozesse beider Systeme
2. Bestimmung des Migrationszeitplanes und Erstellung der Migrationsregeln
3. Datenmengen ermitteln
4. Entscheid zur manuellen oder automatischen Migration
5. Bereitstellung der Informationen (Datei oder Liste)
6. Erzeugung und Protokollierung der neuen Informationen (automatisch oder manuell)
7. Qualitätskontrolle der neuen Informationen mittels Testverfahren
82
7.4. Verdichtung von Informationen
Bei der Verdichtung werden Informationen nach bestimmten Kriterien gruppiert und für diese
Gruppen statistische Informationen ausgewiesen. So wird zur Gruppenbildung häufig die Bildung
von Zeitperioden, z.B. Tag, Monat verwendet. Aber auch andere Kriterien, z.B. nach Organisationseinheit, Produkt, Absatzland sind möglich. Bei der Bildung der statistischen Informationen
werden meist numerische Informationen verwendet. So können z.B. die Gesamtsumme, Mittelwert, Varianz gebildet werden. Es kann der arithmetische Mittelwert des Wertes des Aktiendepots je Monat berechnet werden oder die Gesamtsumme der Erträge je Produkt und Jahr oder
die Anzahl der Ein- Auslagerungen von Aktien eines Aktiendepots je Monat.
Die verdichteten Informationen sind, zumindest im Zeitpunkt ihrer Erstellung, völlig redundant,
gehören damit vom Grundsatz her nicht ins konzeptionelle Datenmodell. Meist ist die Bildung
entsprechender Entitätsmengen aber ein komplexer und schwer nachvollziehbarer Vorgang, so
dass die Bildung, Darstellung und Erläuterung dieser Entitätsmengen durchaus schon auf der
konzeptionellen Ebene seine Berechtigung hat.
83
Der Begriff Integrität wurde bisher mehrfach verwendet. Allerdings waren die Darstellungen bis
jetzt unsystematisch und fallweise. In diesem Kapitel wird der Begriff Integrität auf konzeptioneller Ebene systematisch eingeführt. Integrität umfasst, betrachtet man alle Ebenen und
nicht nur die konzeptionelle Ebene, drei Komponenten [Zehnder 89]:
 Datenkonsistenz (logisch): Mittels Konsistenzregeln werden gültige Datenzustände
definiert, ungültige Zustände werden verboten (z.B. Wertebereich). Hierdurch wird
die Qualität der Daten selbst gewährleistet. In der Praxis werden die Begriffe
Konsistenz und Integrität häufig als Synonyme verwendet.
 Datensicherheit (physisch): Die Datensicherheit stellt sicher, dass die Daten nicht
durch technische Fehler verfälscht werden oder gar verloren gehen (z.B.
Systemabsturz). Datensicherheit wird mittels technischer Massnahmen sichergestellt,
hat keinen Einfluss auf die Definition des konzeptionellen Modells und wird daher erst
zu einem späteren Zeitpunkt detailliert betrachtet.
 Datenschutz (ethisch): Beim Datenschutz werden die Daten (und damit auch die
von den Daten Betroffenen) vor unerlaubten Zugriffen und Änderungen geschützt
(z.B. Datenschutzgesetz). Aber auch vor unbeabsichtigten Fehlmanipulationen
müssen die Daten geschützt werden.
Eingabe
Verwendung
Datenkonsistenz
Datenschutz
Datenbasis
Datensicherheit
Betrieb
Figur 31: Datenintegrität und Datenbasis
Im Folgenden werden die Datenkonsistenz und der Datenschutz im konzeptionellen Modell betrachtet.
8.1. Datenkonsistenz im konzeptionellen Modell
Die Datenkonsistenz, häufig auch semantische Integrität genannt, selbst kann wiederum in drei
Teile gegliedert werden:
 Entitätsintegrität: Die Entitätsintegrität stellt sicher, dass jeder Entitätsschlüsselwert
nur ein einziges Mal in einer Entitätsmenge auftritt. Siehe hierfür Kapitel '4.4.1.
Entitätsschlüssel, Schlüsselkandidat' auf Seite 38.
 Referentielle Integrität: Mittels referentieller Integrität wird gewährleistet, dass jeder
Fremdschlüssel immer einen korrekten Wert enthält. Siehe hierfür Kapitel '4.4.2.
Fremdschlüssel' auf Seite 38.
 Benutzerdefinierte Konsistenz: Hier werden spezifische Konsistenzregeln der Anwendung definiert, welche die gültigen Zustände der Daten definieren.
Im Folgenden soll lediglich die benutzerdefinierte Konsistenz vertieft werden. Werden die benutzerdefinierten Konsistenzregeln eingehalten, kann die Qualität der Daten aus applikatorischer Sicht gewährleistet werden. Es wird daher versucht zu definieren, was gültige DatenTeil 2: Konzeptionelle Datenmodellierung
84
bankzustände sind und was unerlaubte Datenbankzustände sind. Das Datenbanksystem wird
dann überprüfen müssen, ob vom Benutzer ausgeführte Änderungen an Daten sinnvoll sind oder ob diese definierte Konsistenzbedingungen verletzen. Die vollständige Definition einer Konsistenzregel umfasst vier Angaben [Schlag 83]:
1. Objekt: Beschreibung der Menge der Objekte, auf die sich die Konsistenzbedingung
erstreckt.
2. Bedingung: Die logische Bedingung (Prädikat), welche für alle betroffenen Objekte
immer erfüllt sein muss.
3. Auslöseregel: Ereignis, welches die Überprüfung der Bedingung auslöst.
4. Reaktionsregel: Wie soll im Falle einer Konsistenzverletzung verfahren werden?
Die Definition der benutzerdefinierten Konsistenzregeln kann im konzeptionellen Modell natürlichsprachlich oder in einer SQL-ähnlichen Form erfolgen. Wichtig ist hierbei, immer alle vier Angaben festzulegen. Meist dürfte die natürlichsprachliche Definition bevorzugt werden, da diese
auch von den am Modellierungsprozess betroffenen Benutzern verstanden wird.
1. Objekt: Attribut Lebenspartner in der Entitätsmenge Kunden (siehe Beispiel im Kapitel '6.3. Rekursion' auf Seite 61.
2. Bedingung: Das Feld Lebenspartner eines allfällig referenzierten Partners muss den
Wert NULL enthalten (d.h. darf nicht nochmals mit jemand anders verbunden sein).
3. Auslöseregel: Änderungen am Attribut Lebenspartner.
4. Reaktionsregel: Änderungen verweigern.
Mittels 'Pseudo'-SQL:
ASSERT Leb_Partner ON UPDATE OF Kunden (Lebenspartner):
Lebenspartner = <NULL> OR
(SELECT Kunden (Lebenspartner)
FROM Kunden
WHERE Kunden# = Kunde.Lebenspartner) = <NULL>
Figur 32: Definition der Konsistenzregel Leb_Partner
In der Literatur werden benutzerdefinierte Konsistenzregeln ausserdem häufig nach bestimmten
Eigenschaften gegliedert. Mögliche Gliederungskriterien sind z.B.:
 Reichweite der Bedingung: Ein Attribut, mehrere Attribute einer Entität, mehrere Entitäten einer Entitätsmenge oder mehrere Entitäten mehrerer Entitätsmengen.
 Zeitpunkt der Überprüfung: Unmittelbar nach jeder Datenbankoperation (primäre
Konsistenzbedingung) oder erst nach mehreren Datenbankoperationen (sekundäre
Konsistenzbedingung).
 Reaktion auf Verletzung: Muss die Konsistenzbedingung immer eingehalten werden
(strenge Konsistenzbedingung) oder kann die Konsistenzbedingung ausnahmsweise
verletzt werden (schwache Konsistenzbedingung).
 Art der Überprüfbarkeit: Wird mit der Konsistenzbedingung ein Zustand (z.B. Abholdatum < Lieferdatum) oder ein Übergang (z.B. vom Zivilstand 'ledig' in 'verheiratet')
überprüft.
8.2. Datenschutz im konzeptionellen Modell
Eigentlich kann bereits im konzeptionellen Modell zusammen mit dem Benutzer definiert werden, wer wie auf welche Daten zugreifen darf. In der Praxis wird der Datenschutz meist gar nicht
85
oder dann äusserst restriktiv gehandhabt. Im ersten Fall ist die Einhaltung der Datenschutzgesetzte (auch im Interesse des Unternehmens) auf den guten Willen der Mitarbeiter angewiesen. Im zweiten Fall fehlen dafür im täglichen Ablauf häufig notwendige Zugriffsrechte
und die Effizienz der Arbeit leidet dann darunter drastisch. Wünschenswert ist es daher, pragmatische, den Bedürfnissen angepasste Definitionen zu finden. Zusätzlich zu den angesprochenen
EDV-Schutzmassnahmen müssen auch organisatorische Massnahmen wie Zu- und Abgangskontrollen, Transportkontrollen (Kryptographie) etc. eingeführt werden.
Drei wichtige Begriffe im Datenschutz sind:
1. Identifikation: Anmeldung eines Benutzers unter Angabe einer Benutzeridentifikation
und eines Kennwortes.
2. Authentisierung: Vorgang, bei welchem überprüft wird, ob es sich tatsächlich um
den berechtigten Benutzer handelt.
3. Autorisierung: Vergabe von Zugriffsrechten an Benutzer.
Der Mechanismus zur Vergabe der Zugriffsrechte kann sehr unterschiedlich gelöst werden. Eine
grosse Verbreitung hat die Definition der Zugriffsrechte mittels der Zugriffsrechtsmatrix. In der Zugriffsrechtsmatrix werden die Objekte der Anwendung (Daten, Programme, ...) sowie die erlaubten Aktivitäten für jeden Benutzer bzw. Benutzergruppe festgehalten. In der Abszisse werden dann die Objekte, in der Ordinate die Benutzer und in den Zellen die erlaubten Aktivitäten
(Lesen, Ändern, ...) festgehalten.
Einen anderen Ansatz wählt SQL. In SQL hat der Erzeuger einer Entitätsmenge zunächst das alleinige Recht diese Entitätsmenge zu nutzen. Diese Rechte kann er gezielt mit Angabe der erlaubten Operationen an weitere Benutzer weitergeben. Diese Benutzer dürfen die ihnen vergebenen Rechte allenfalls wieder an andere Benutzer weitergeben und so weiter. Wird einem Benutzer ein Recht entzogen, so werden auch sämtliche Rechte, die er aufgrund des entzogenen
Rechts vergeben hat, den betroffenen Benutzern entzogen. Die Definition des Zugriffsrechts erfolgt mit folgender Syntax:
GRANT INSERT, UPDATE ON Aufträge TO Moni WITH GRANT OPTION
Figur 33: Zugriffsrechtsvergabe mittels SQL
86
8.3. Checkfragen
1.
Die Authentisierung bezweckt...





2.
A)
B)
C)
D)
E)
die Anmeldung des Benutzers.
die Komprimierung der Daten.
die Überprüfung der Zugriffsberechtigung des Benutzers.
die Verdichtung der Daten.
die Daten in verschlüsselter Form für andere unleserlich abzuspeichern.
Datenschutz ist ein Element der...





A)
B)
C)
D)
E)
Datenkonsistenz.
Datensicherheit.
Datenintegrität.
referentiellen Integrität.
Entitätsintegrität.
1.
Die Definition einer Konsistenzbedingung umfasst:
+








die Auslöseregel
die betroffenen Objekte
die Reaktionsregel
die Bedingung
87
Teil 3:
Internes Datenmodell
89
In diesem Kapitel muss vorerst ein rudimentäres Verständnis für die Arbeitsweise von Datenbanksystemen vermittelt werden. Nur mit Kenntnis der internen Softwarekomponenten und deren Lösungskonzepten kann ein effizientes und auf das Datenbanksystem ausgerichtetes internes Datenmodell erstellt werden, können Programme mit optimalem Zugriffsverhalten gestaltet
werden.
Ein noch so komplexes und leistungsstarkes Datenbanksystem besteht letztendlich nur aus Software. Entsprechend jeder anderen Software lassen sich Datenbanksysteme ebenfalls in Software-Module gliedern. Zwar existiert für bestehende Datenbanksysteme keine allgemeingültige
Gliederung in Module, doch lässt sich durch eine verallgemeinerte Gliederung die Arbeitsweise
anschaulich erklären. Im Folgenden werden wir ein Schichtenmodell, angelehnt an Senko
[Senko73], verwenden, welches das Datenbanksystem in fünf Schichten (Module) gliedert (siehe auch [Härder 01]).
90
Program m e, Benutzer
Mengenorientierte Schnittstelle
Entitätsmengenverwaltung
• Optimizer
• Datenbanksprachen (SQL)
Satzorientierte Schnittstelle
Entitätenverwaltung
•
•
•
•
Metadatenbank
Transaktionsverwalter
Integritätssicherung
Cursor-Verwalter
Interne Satzschnittstelle
Record- und
Zugriffspfadverwaltung
• Recordverwalter
• Zugriffspfadverwalter
System pufferschnittstelle
Systempufferverwaltung
• Systempufferverwalter
Dateischnittstelle
Externspeicherverwaltung
• Externspeicherverwalter
Geräteschnittstelle
Daten
Figur 34: Schichtenmodell eines Datenbanksystems
Jede Schicht verwendet die Funktionen der unteren Schicht, um ihre jeweils spezifischen Funktionen zu realisieren, welche diese Schicht wieder der nächsthöheren Schicht zur Verfügung stellt.
Dadurch wird das Datenbanksystem hierarchisch strukturiert. Die von den Schichten den untenliegenden Schichten zur Verfügung gestellten Funktionen werden auch als Schnittstelle bezeichnet.
9.1. Externspeicherverwaltung
Die Software-Komponente Externspeicherverwaltung hat zur Aufgabe, die unterschiedlichen
Geräteeigenschaften (z.B. Spurenanzahl, Blockgrösse etc.) der verwendeten Speichermedien
der nächsthöheren Komponente (der Systempufferverwaltung) zu verstecken und stattdessen
eine dateiorientierte Sichtweise auf die Speichermedien zu gewähren. Diese Schicht ist im Normalfall Teil des Betriebssystems. Diese Schicht stellt in der Dateischnittstelle Funktionen zur Verfü-
91
gung, welche ein Verarbeiten von Dateien erlauben: Erzeugen, Löschen, Öffnen und Schliessen
von Dateien, Lesen und Schreiben eines Dateiblocks.
9.2. Systempufferverwaltung
Die Systempufferverwaltung vermittelt der übergeordneten Schicht den Eindruck, sämtliche Daten seien im Systempuffer des Hauptspeichers gespeichert. Die Systempufferverwaltung übernimmt dabei die Aufgabe, Daten im Systempuffer zur Verfügung zu stellen und geänderte Daten wieder auf die Speichermedien zu übertragen. Die im Systempuffer verarbeiteten Einheiten
werden Segmente oder Seiten genannt.
Natürlich haben nicht sämtliche Daten im Systempuffer Platz. Der Systempufferverwalter muss
daher für neu angeforderte Segmente entscheiden, welche Segmente auf das Speichermedium ausgelagert werden sollen. Für diesen Entscheid sind eine ganze Reihe von Strategien
denkbar. Durch die geeignete Wahl der Ersetzungsstrategie kann die Leistung des Datenbanksystems beträchlich gesteigert werden. Sinnvollerweise unterstützt der Systempufferverwalter unterschiedliche Segmenttypen, um einen differenzierten Einsatz unterschiedlicher
Strategien je Datentyp (Benutzerdaten, DBMS-Daten etc.) zu ermöglichen. Die Konfiguration des
Systempufferverwalters (z.B. auch dessen Grösse) kann an dieser Stelle nicht weiter beschrieben
werden und es muss daher auf weitere Ausführungen verzichtet werden.
Der Systempufferverwalter selbst kann noch immer als Teil des Betriebssystems realisiert sein. In
diesem Fall sollten aber bestimmte Funktionen vom Systempufferverwalter dem Datenbanksystem zur Verfügung gestellt werden, ansonsten können wünschenswerte Funktionen des Datenbanksystems nicht oder nur ineffizient realisiert werden.
9.3. Record- und Zugriffspfadverwaltung
Die in dieser Schicht wahrgenommenen Aufgaben können leicht in zwei Aufgabenbereiche gegliedert werden:
1. Recordverwalter bzw. Satzverwaltung: Der Recordverwalter übernimmt die physische Abspeicherung von Datensätzen mit entsprechenden Funktionen wie Lesen,
Einfügen, Modifizieren und Löschen.
2. Zugriffspfadverwaltung: Für eine praktikable Verarbeitung müssen Datensätze mit
bestimmten gesuchten Eigenschaften effizient gefunden werden. Hierfür stellt das
Datenbanksystem spezielle Zugriffshilfen zur Verfügung. Diese Zugriffshilfen werden
allgemein als Zugriffspfade bezeichnet.
9.3.1. Recordverwaltung
Der Recordverwalter hat die Aufgabe, die physischen Datensätze des Datenbanksystems in
den Segmenten des Systempuffers abzulegen. Bei der Definition des Datensatzformates werden
dessen Felder sowie deren Datenformate festgehalten. Dadurch ist die Gesamtlänge des Datensatzes gegeben. Im günstigen Fall haben pro Segment ein oder auch mehr Datensätze Platz.
Ist der Datensatz grösser als ein einzelnes Segment, muss dieser auf mehrere Segmente verteilt
werden, was zu einer deutlichen Verschlechterung der Zugriffszeiten führt.
Zur besseren Nutzung des verfügbaren Speichermediums drängt sich die Komprimierung (allenfalls mit gleichzeitiger Chiffrierung) der physischen Datensätze auf. Der erhöhte Rechenaufwand
hält sich dabei die Waage mit den Zeitersparnissen beim reduzierten Ein- und Ausgabeaufwand. Der Datensatz hat dann keine feste Länge mehr, sondern diese variiert je nach Dateninhalt. Messungen zeigen, dass durch Komprimierung der physische Speicherbedarf für die
Daten im Durchschnitt auf ca. 50% der ursprünglichen Grösse reduziert werden kann.
Dadurch wäre es dem Datenbanksystem grundsätzlich auch möglich, die Feldlänge der einzelnen Datensätze variabel zu gestalten. Die meisten Datenbanksysteme bieten diese Möglichkeit
nicht an, sondern haben aus Effizienzgründen feste Feldlängen. Diese stellen dafür andere KonTeil 3: Internes Datenmodell
92
strukte zur Verfügung, um Felder variabler Länge (z.B. für Textdokumente, Grafiken) im Datenbanksystem abzulegen.
9.3.2. Zugriffspfadverwaltung
Bis jetzt können Daten im Datenbanksystem zwar abgelegt werden, doch muss zum Auffinden
eines Datensatzes mit bestimmten Eigenschaften der gesamte Datenbestand sequentiell durchsucht werden. In einem ersten Lösungsansatz könnten die Datensätze nach einem einzigen Kriterium physisch sortiert werden (z.B. nach dem Entitätsschlüssel Kundennummer), doch sind
dann andere Zugriffspfade (z.B. nach dem Kundennamen oder nach Ort und Kundenname)
noch immer nicht möglich. Mittels Hilfsstrukturen sollen derartige Zugriffe nach beliebig kombinierten Attributen möglichst effizient gestaltet werden können.
Die physische Sortierung der Daten auf dem Speichermedium wird physischer Zugriffspfad genannt. Das physische Sortierkriterium entspricht dem Primärschlüssel. Der Primärschlüssel muss
nichts mit dem Entitätsschlüssel (oder auch Identifikationsschlüssel) der Entitätsmenge gemeinsam haben (meist verwendet das DBMS einen eigenen Primärschlüssel, die Datensatznummer).
Der sekundäre Zugriffspfad erlaubt den Zugriff mit einem frei definierbaren Sekundärschlüssel. Im
Gegensatz zum Primärschlüssel dürfen für einen Sekundärschlüssel bei einem bestimmten
Schlüsselwert beliebig viele Datensätze auftreten (z.B. 20 Entitäten mit dem Kundennamen ‘Müller’). Im Folgenden wird nicht mehr zwischen physischem und sekundärem Zugriffspfad differenziert, da die Realisierung der Zugriffspfade auf inhaltlich identischen Algorithmen basiert.
Zur Optimierung der Zugriffszeiten müssen für sekundäre Zugriffspfade zwingend redundante Informationen durch den Zugriffspfadverwalter (z.B. ein Index nach Kundennamen) bereitgestellt
werden. Es werden damit gezielt redundante Informationen eingeführt, um die Leistung des Datenbanksystems zu erhöhen. In der Theorie wurde eine Vielzahl von Algorithmen für Zugriffsverfahren entwickelt. In der Praxis sind allerdings nur wenige dieser Verfahren mit leichten Abweichungen und allerlei Mischvarianten anzutreffen.
 Mittels Hilfsstrukturen wird der effiziente Zugriff nach einem festgelegten Kriterium möglich. Doch
lässt sich der Zugriff weiterhin beschleunigen, falls die Datensätze nach dem am häufigsten
verwendeten Kriterium eines Sekundärschlüssels physisch sortiert abgelegt werden und zur Sortierung nicht die Datensatznummer verwendet wird. Diese gezielte physische Anordnung der
Datensätze wird Clustering genannt. Können z.B. 20 Datensätze pro Segment gespeichert werden, so müsste im günstigsten Fall erst nach jeweils 20 Datensätzen wieder ein neues Segment
gelesen werden. Wird kein Clustering eingesetzt, sind die Datensätze unsortiert und es würde allenfalls pro Zugriff ein Segment gelesen werden. Mittels Clustering kann die Zugriffshäufigkeit auf
das Speichermedium daher im angesprochenen Fall bis zum Faktor 20 reduziert werden. Dies
bedingt allerdings, dass die Entwickler über das Clustering informiert sind und dieses gezielt nutzen, oder dass das Datenbanksystem selbständig den optimalen Zugriffspfad wählt.
9.3.2.1. Zugriffsverfahren mit invertierten Listen
Bei der invertierten Liste wird für das gewünschte Zugriffskriterium ein Index gebildet in welchem
die auftretenden Werte sortiert abgelegt werden. Zusätzlich wird für jeden Indexeintrag eine
Zeigerliste geführt, welche die betreffenden Datensätze referenziert (z.B. mittels interner Datensatznummer). Für einen Zugriff auf den bzw. die Datensätze mit dem gewünschten Kriterium wird
zunächst im Index die Position der Datensätze bestimmt und anschliessend direkt auf die entsprechenden Datensätze zugegriffen. Eine Zugriffsbeschleunigung erfolgt aus zwei Gründen: Erstens ist der Index nach dem gewünschten Zugriffskriterium sortiert und ermöglicht damit binäres
Suchen. Zweitens benötigt der Index selbst deutlich weniger Platz als die eigentlichen Daten, so
dass pro Segment beträchtlich mehr Indexeinträge als Datensätze gespeichert werden können.
Index
Anz.
Zeiger
93
Zeigerlisten mit
Record-Id
Schluep
2
2'345
Schlüer
1
9'452
Schlum sberger
4
16
Schlünz
1
734
...
...
321
341
389
1'532
Figur 35: Index und Zeigerlisten bei der invertierten Liste
Da die Länge der Zeigerlisten zu Beginn nicht bekannt ist und die Realisierung variabel langer
Zeigerlisten aufwendige Algorithmen bedingt, werden die Zeigerlisten meist separat zur Indexstruktur abgelegt. In der Indexstruktur wird lediglich auf die betreffende Zeigerliste referenziert
(wieder mittels Zeiger), welche separat hiervon verwaltet wird.
Trotz der einfachen Struktur und Algorithmen sind invertierte Listen in Reinform kaum anzutreffen.
Das Aufsuchen von Datensätzen ist zwar äusserst effizient, aber beim Einfügen und Löschen
neuer Datensätze ergeben sich Schwierigkeiten. Grundlage der invertierten Listen ist ein sortierter Index, dessen Einträge physisch sortiert sind. Dies bedingt, dass beim Einfügen für den neuen
Indexeintrag Platz geschaffen werden muss und sämtliche nachfolgenden Indexeinträge daher
nach hinten geschoben werden. Entsprechend müssen beim Löschen die Lücken wieder geschlossen werden. Zwar können durch Überlaufbereiche die Mängel etwas gedämpft werden,
sie gewähren aber nur einen mangelhaften Kompromiss.
Um diesen Mangel zu beseitigen liegt die Idee nahe, den Index in kleinere Einheiten zu gliedern
und zum Auffinden des korrekten Indexteiles wiederum einen Index zu verwenden. Dadurch
würde ein hierarchischer, zweistufiger Index gebildet. Natürlich kann dieser Unterteilungsschritt
beliebig oft wiederholt werden und dadurch ein mehrstufiger Index gebildet werden. Dieser
Vorgang wird sinnigerweise so lange wiederholt, bis die grössten Indexteile physisch exakt die
Grösse eines Segmentes haben. Verfeinert man diesen Algorithmus noch in der Art und Weise,
dass die einzelnen Indexteile auf allen Hierarchiestufen möglichst gleichmässig und vollständig
gefüllt sind, dann handelt es sich annähernd um einen baumstrukturierten Zugriffspfad.
 Interessant ist natürlich die Frage, wie viele Zugriffe sind auf den Systempufferverwalter nötig, bis
die gesuchten Daten gefunden werden. Die Antwort ist nicht ganz einfach zu geben. Geht
man von einem einfachen Index aus, in welchem mittels binärer Suche die Zeigerreferenz eruiert wird und bei welchem für jeden Suchschritt ein Segment angefordert werden muss (was
nicht ganz korrekt ist), so müssen etwa log 2(D) Zugriffe auf den Index erfolgen (D entspricht der
Anzahl der Datensätze). Bei 1’000’000 Datensätzen sind damit ca. 17 Zugriffe notwendig. Dies ist
ein durchaus befriedigendes Ergebnis, allerdings treten beim Einfügen und Löschen von Daten
beträchtliche Probleme auf. So muss für diese Operationen im Schnitt jeweils die Hälfte aller Datensätze verschoben werden, für ein Datenbanksystem keine akzeptable Lösung.
9.3.2.2. Baumstrukturierte Zugriffsverfahren, B- und B*-Baum
Für baumstrukturierte Zugriffsverfahren wurde eine Vielzahl unterschiedlicher Algorithmen entwickelt. Im Folgenden werden zwei wichtige Vertreter vorgestellt, welche sich speziell für den
Einsatz in Datenbankumgebungen eignen und daher auch eine entsprechende Verbreitung
gefunden haben. Dabei handelt es sich bei Ersterem um sogenannte B-Bäume und beim Zweiten um eine Variante hiervon, dem B*-Baum (siehe auch [Wirth 96]). Das B in der Bezeichnung
bringt zum Ausdruck, dass es sich um balancierte Bäume handelt, es darf nicht mit Binär- (für
Datenbanksysteme ungeeignet) oder Bitbäumen (nur in Ausnahmefällen geeignet) in Verbindung gebracht werden. Folgende Begriffe werden im Zusammenhang mit Bäumen verwendet:
1. Knoten: Die Knoten sind die Grundkomponenten des Baumes.
2. Zeiger: Mittels der Zeiger (physische Adressverweise, Pointer) werden die Knoten des
Baumes miteinander verknüpft.
94
3. Wurzel: Die Wurzel ist der oberste Knoten des Baumes.
4. Blätter: Die Blätter sind jene Knoten, welche selbst keine untergeordneten Knoten
mehr haben.
In B-Bäumen werden die Daten baumartig in den Knoten angeordnet, welche mittels Zeigern
verknüpft sind. Die Grösse der Knoten entspricht dabei i.d.R. der Grösse der durch den Systempufferverwalter verarbeiteten Segmente. Die Knoten des B-Baumes beinhalten:
1. Mehrere Schlüsseleinträge
2. Die jeweils zugehörigen Daten selbst oder als Variante einen Zeiger auf die eigentlichen Daten
3. Mehrere Zeiger, welche auf je einen untergeordneten Knoten verweisen, in welchem sämtliche Schlüsselwerte grösser sind als der links vom Zeiger liegende
Schlüsselwert, aber in welchem alle Schlüsselwerte kleiner sind als der rechts vom
Zeiger liegende Schlüsselwert (dies gilt auch für alle wiederum untergeordnete
Knoten)
Graf
Egli
Aelig
Dim m
Voss
Hess
Koster
Sandr
Frei
Figur 36: Baum für das Attribut Name (ohne Daten)
Damit ist es möglich einen gewünschten Schlüsselwert gezielt zu suchen. Bei optimaler Verteilung und Belegung des Baumes ist das Suchen eines Schlüsselwertes sogar effizienter als die binäre Suche, und das ganz ohne dass die Daten physisch sequentiell geordnet sein müssen. Lediglich in den einzelnen Knoten selbst müssen die Daten sortiert sein.
Durch geeignete Algorithmen muss nun sichergestellt werden, dass die Knoten immer mindestens bis zu einem bestimmten Grad gefüllt sind und dass der Baum mehr oder weniger gleichmässig balanciert ist. Werden diese Forderungen nicht aufgestellt, kann ein Baum im schlimmsten Fall zu einer linearen Liste verkommen, der Zugriff zu gesuchten Daten entspricht dann dem
sequentiellen Durchsuchen der Daten. In der Regel werden folgende Bedingungen für B-Bäume
definiert:
1. Alle Knoten, mit Ausnahme der Wurzel, müssen mindestens je zur Hälfte mit Daten
gefüllt sein.
2. Die Weglänge von der Wurzel bis zu sämtlichen Blättern des B-Baumes ist identisch.
95
Locher
Isler
Burri
Klee
Sigg
Hasler
Popp
Kägi
Rüegg
Kasper
Stam pf
Kram er
Lanz
Vettiger
Theiler
Lehner
Weiss
Zappa
Zwingli
Figur 37: B-Baum
Während die erste Forderung intuitiv noch recht einfach zu gewährleisten ist, scheint es zunächst schwierig die zweite Forderung zu erfüllen, doch lässt sich dieses Problem recht elegant
lösen. Geht man davon aus, dass der Baum an den Blättern wächst und schrumpft, kann ein
unkontrolliertes Wachstum nur schwerlich verhindert werden. Lässt man den Baum aber an der
Wurzel wachsen und schrumpfen, wird vieles deutlich einfacher. Wächst und schrumpft der
Baum an der Wurzel, ist immer automatisch sichergestellt, dass sämtliche Weglängen immer
gleich lang sind.
Durch geeignete Algorithmen müssen Daten im korrekten Blatt im Baum so eingefügt werden,
dass beim Überlauf (Einfügen in einen vollen Knoten) der Knoten in der Mitte geteilt wird und
genau ein Knoteneintrag nach oben gereicht wird. Dadurch entstehen zunächst zwei exakt zur
Hälfte gefüllte Knoten, ohne dass der Baum nach unten gewachsen wäre. Der nach oben gereichte Knoteneintrag enthält den Schlüsselwert, der exakt den Wert in der Mitte aller sortierten
Schlüsselwerte enthält. Damit können die beiden neuen Knoten leicht mittels Zeigern an den
neu im obenliegenden Knoten eingebetteten Schlüsselwert angebunden werden. Ist dieser
obenliegende Knoten wiederum voll, wird der selbe Vorgang rekursiv wiederholt.
Isler
Aerni
Burri
Hasler
Kägi
Klee
Kram er
Lanz
Lehner
Kasper
Isler
Meier
Leitner
Klee
Lehner
Aerni
Burri
Hasler
Kägi
Kram er
Kasper
Lanz
Leitner
Meier
96
Isler
Aerni
Burri
Klee
Hasler
Lehner
Kram er
Kägi
Lanz
Kasper
Leitner
Meier
Figur 38: Einfügen von Daten in einen B-Baum
Handelt es sich beim obenliegenden Knoten um die Wurzel, dann wird die Wurzel geteilt und
ein Knoteneintrag gemäss den vorgängigen Erläuterungen nach oben gereicht. Bei dem nach
oben gereichten Knoteneintrag handelt es sich natürlich um die neue Wurzel, während die alte
Wurzel zu zwei ‘normalen’ Knoten umgewandelt wird. Der Baum ist nach oben gewachsen. Die
Weglängen von der Wurzel zu den Blättern hat für alle Wege um eine Hierarchiestufe zugenommen. Beim Löschen von Knoteneinträgen sorgen entsprechend umgekehrte Vorgänge für
ein Zusammenlegen von Knoten und allenfalls für ein Schrumpfen der Baumhöhe.
Entscheidend für die Effizienz der Zugriffe ist die höchstmögliche Anzahl der Knoteneinträge in
die Knoten. Es liegt daher nahe, diese dadurch zu erhöhen, dass die Daten bzw. die Zeiger auf
die Daten, nicht in sämtlichen Knoten geführt werden. Im B*-Baum werden die Daten oder deren Zeiger nicht in sämtlichen Knoten geführt, sondern nur in den Blättern des Baumes. In einem
‘normalen’ Knoten haben damit mehr Schlüsseleinträge Platz. Dies bedingt allerdings, dass die
Schlüsseleinträge von ‘normalen’ Knoten redundant geführt werden und in den Blättern erneut
auftreten.
Locher
Isler
Burri
Hasler
Klee
Sigg
Isler
Kägi
Popp
Kasper
Rüegg
Klee
Kram er
Sigg
Stam pf
Lanz
Locher
Vettiger
Theiler
Vettiger
Weiss
Zappa
Figur 39: B*-Baum
B-Bäume und B*-Bäume sind die Standardlösung als Zugriffsverfahren. Sie erlauben den raschen
Zugriff für ein bestimmtes Zugriffskriterium, ermöglichen effizientes sequentielles Lesen, Einfügeund Lösch-Operationen zeigen ebenfalls ein gutes, ausgewogenes Leistungsverhalten.
 Die notwendige Anzahl der Zugriffe auf den Systempufferverwalter hängt jetzt nicht nur von der
Anzahl der Datensätze ab, sondern auch von der Anzahl der im Knoten abgelegten Schlüsselwerte (im Folgenden S genannt). Die benötigte Anzahl Zugriffe ist für B-Bäume etwa logS(D)+1.
Bei 1’000’000 Datensätzen und einem S von 100 (für B-Bäume) ergibt sich eine durchschnittliche
Zugriffszahl von unter 4. Im Vergleich zur invertierten Liste erhält man bei einem grossen S eine
deutliche Leistungssteigerung.
97
 Zur Steigerung der Performance bieten bzw. nutzen Datenbanksysteme auch die Möglichkeit,
für einen Zugriff nur den Zugriffspfad zu verwenden. So lange nur Daten benötigt werden, welche im Zugriffspfad gespeichert sind, ist ein Zugriff auf die eigentlichen Daten überflüssig. Da der
Zugriffspfad meist vollständig im Systempuffer abgelegt ist, sind derartige Zugriffe im Vergleich zu
vollständigen Zugriffen dann um ein Vielfaches schneller. Entsprechend kann auch verfahren
werden, wenn nur die Anzahl der Datensätze gesucht wird, die ein bestimmtes Kriterium erfüllen.
9.3.2.3. Zugriffsverfahren mit Schlüsseltransformation
Das Zugriffsverfahren mit Schlüsseltransformation (auch Hash, bzw. Hashing genannt) besticht
durch seine unglaublichen Leistungsmerkmale. Im günstigen Fall benötigt es einen einzigen Zugriff auf das externe Speichermedium um gesuchte Daten zu finden. Im Gegensatz zu den
baumstrukturierten Zugriffsverfahren wird keine zusätzliche Hilfsorganisation aufgebaut, sondern
die Daten werden derart geschickt abgelegt, dass das Datenbanksystem direkt aus dem
Schlüsselwert die Segment-Adresse des Datensatzes berechnen kann.
Damit ist auch bereits die Arbeitsweise von Zugriffsverfahren mit Schlüsseltransformation erklärt.
Das Datenbanksystem nimmt den Schlüsselwert und berechnet daraus mittels definierter Transformationen die Segment-Adresse, an welcher der Datensatz gespeichert wird. Beim Suchen
von Daten wird mittels des selben Transformationsverfahrens die Segment-Adresse des vermeintlichen Datensatzes bestimmt, und der Zugriff auf das betreffende Segment gibt Auskunft, ob der
Datensatz tatsächlich existiert. Für dieses Verfahren muss damit bereits beim Anlegen der Datenbank bestimmt werden, wieviel Speicherplatz die Entitätsmenge benötigt, damit dieser reserviert werden kann.
Entscheidend für die Effizienz des Zugriffsverfahrens ist der Algorithmus, mittels welchem der
Schlüsselwert in die Segment-Adresse umgerechnet wird. Einerseits muss verhindert werden,
dass allzu häufig die selbe Segment-Adresse berechnet wird, denn dann müssen Überlaufbereiche angelegt werden, welche zusätzliche Zugriffe erfordern. Andererseits sollte der zur Verfügung gestellte Speicherbereich möglichst dicht mit Daten belegt werden. Es muss also ein
Transformationsverfahren gewählt werden, welches die Daten möglichst gleichmässig verteilt.
Häufig wird für die Transformation das Divisionsrestverfahren (Modulo-Funktion) verwendet. Dabei wird der Schlüsselwert (bzw. dessen numerischer Bytewert) durch eine vorgegebene Zahl,
vorteilhafterweise eine Primzahl, dividiert (z.B. 19 Modulo 7 ergibt 5; 2*7+5=12. Der Divisionsrest
ergibt dann direkt die Segment-Adresse des Datensatzes. Die gewählte Primzahl entspricht damit auch direkt dem Speicherplatz, welcher reserviert werden muss.
Neben den bereits erwähnten Nachteilen (der zu reservierende Speicherplatz, die Überlaufbereiche mit mehrfachem Zugriff), ist die sequentielle sortierte Verarbeitung der Daten kaum
möglich. Zugriffsverfahren mittels Schlüsseltransformation eignen sich daher nur für Datenbestände, welche bestimmte Bedingungen erfüllen:
 Die Menge der zur Laufzeit auftretenden Entitäten sollte möglichst genau bekannt
sein und sollte sich im Lauf der Zeit nur wenig ändern.
 Die Werte und die Verteilung der Schlüsselwerte sollten ebenfalls möglichst genau
bekannt sein, damit ein geeigneter Transformationsalgorithmus bestimmt werden
kann.
 Die Verarbeitung der Daten sollte nicht sequentiell sortiert erfolgen.
Zwar wurden auch dynamische Verfahren entwickelt, um die vorgängigen Bedingungen zu
entschärfen, doch haben sich Schlüsseltransformationsverfahren in der Praxis nicht durchgesetzt, sondern wurden allenfalls als zusätzliche Variante (zu den B-Bäumen) integriert.
9.4. Entitätenverwaltung
Während der Recordverwalter noch mit den physischen Einheiten des Datenbanksystems arbeitet, werden die Daten in der satzorientierten Schnittstelle (realisiert durch Entitätenverwaltung) in
den logischen Einheiten des Datenbanksystems verwaltet. So verwendet der Recordverwalter
98
z.B. für die Bezeichnung der Datensatzfelder noch technische Bezeichnungen (z.B. ‘AB’), während die Entitätenverwaltung (auch zugriffspfadbezogenes Datenmodell genannt) hiervon abstrahiert und die Feldbezeichnung logisch geführt wird (z.B. ‘Kundennummer’). Für diese Umsetzung muss das Datenbanksystem Informationen über die gespeicherten Informationen sammeln. Diese Informationen über die Informationen werden Metadaten genannt. Die
Datenbankkomponente, in welcher die Metadaten gehalten werden, wird sinngemäss Metadatenbank genannt.
9.4.1. Metadatenbank
 In der Metadatenbank (auch Data Dictionary, Datenwörterbuch, Repository) werden sämtliche Informationen über die verwalteten Daten und Komponenten des
Datenbanksystems abgelegt.
So können in der Metadatenbank nicht nur Strukturinformationen über die Benutzerdaten selbst
abgelegt werden (physisches und externe Schemas), sondern es können zum Beispiel auch die
verwendeten Programme, Benutzerangaben, Statistiken registriert werden.
Diese Informationen spielen in der Entwicklung und Wartung von Datenbanksystemen eine entscheidende Rolle zur Effizienzsteigerung. So kann zum Beispiel mittels Metadatenbank festgehalten werden, welches Programm welche Entitätsmengen verwendet. Eine derart ausgelegte
Metadatenbank wird zum zentralen Koordinationsinstrument aller betroffenen Abteilungen
(EDV-Entwicklung, Fachabteilungen, Organisation etc.). Die folgenden Entitätsmengen zeigen
im Ausschnitt, wie ein kleines konzeptionelles Datenmodell in einer Metadatenbank abgelegt
werden könnte.
Entitätsmengen
Entitätsmengenname
Kunden
Aufträge
Auftragspositionen
...
Beschreibung
Enthält die Informationen unserer Kunden
Enthält die durch unsere Kunden vergebenen Aufträge
Hält fest, welche Artikel in einem Auftrag verkauft wurden.
...
Attribute
Entitätsmengenname
Kunden
Attributsname
Kunden_Id
Entitätsschlüsselteil
Ja
Kunden
Name
Nein
Kunden
Geschäftsform Nein
Beschreibung
Domäne
Eindeutige Identifikation
des Kunden
Name des Kunden
(Nachname bzw. Firmenname)
Geschäftsform: juristisch
/ natürlich
Numerisch 10
Alphabetisch 30
...
...
Tabellen 24: Teil des konzeptionellen Datenmodells (Struktur der Benutzerdaten), gespeichert in Metadatenbank
Werden in der Metadatenbank nicht nur das physische Schema und die externen Schemas
verwaltet, sondern wird darüber hinaus auch das konzeptionelle Datenmodell bewirtschaftet,
lässt sich das Datenbanksystem über alle Phasen der Datenmodellierung einsetzen. Gängige
Datenbanksysteme sind allerdings nicht in der Lage, das konzeptionelle Datenmodell parallel
zum physischen Datenmodell zu pflegen. Werden zusätzlich zu den Datenmodellen Geschäftsprozesse, logische Transaktionen etc. betreut, der Entwickler mit abgestimmten Methoden in
99
seiner Arbeit unterstützt, dann handelt sich um mehr als eine reine Datenbank, dann ist es ein
Case-Tool.
Da ein Datenbanksystem als Zielsetzung die effiziente Verwaltung von Daten hat, sollte es auch
möglich sein, die Metadaten selbst mittels den genau gleichen Komponenten und Methoden
des Datenbanksystems zu verwalten wie normale Daten. Dieser Ansatz wird in relationalen Datenbanksystemen auch tatsächlich verfolgt. Hierdurch können alle Vorteile von Datenbanksystemen voll genutzt werden. Es wird somit eine Meta-Datenbasis angelegt, für welche
das Datenbanksystem wie für normale Daten z.B. die Datenintegrität (z.B. für den Mehrbenutzerbetrieb) sicherstellt. Das Datenmodell mittels welchem die Metadaten abgelegt werden können, kann nun auch exakt mit den selben Methoden dargestellt und strukturiert werden, wie wir
dies für ‘normale’ konzeptionelle Datenmodelle gezeigt haben:
Dom änen
Applikationen
Benutzer
Datensichten
Entitätsm engen
Zugriffsrechte
Attribute
Datensichtenaufbau
Figur 40: Ausschnitt eines einfachen, konzeptionellen Datenmodells für Metadaten
Betrachtet man das Datenmodell der Metadaten eines konkreten Datenbanksystems, so können daraus direkt auch die Fähigkeiten des Datenbanksystems abgeleitet werden. Z.B. kann
man direkt ersehen, welches die maximale Länge für die Bezeichnung eines Attributes ist, ob für
Domänendefinitionen Aufzählungstypen erlaubt sind.
In der Praxis ist leider nicht in jedem Datenbanksystem eine Metadatenbank integriert. In diesen
Fällen kann es sinnvoll sein, trotzdem eine Metadatenbank anzulegen. Natürlich ist dann der
Funktionsumfang nicht der selbe, wie dies bei einer integrierten Metadatenbank der Fall ist. Zur
Unterscheidung des Funktionsumfangs lassen sich Metadatenbanken nach bestimmten Kriterien
klassifizieren:
 Passive Metadatenbank: Bei einer passiven Metadatenbank ist die
Metadatenbank nicht in das Datenbanksystem integriert. Damit kann die
Metadatenbank das Datenbanksystem in dessen Arbeit nicht unterstützen, sondern
dient vorwiegend Dokumentationszwecken. Häufig müssen damit identische Informationen in die Metadatenbank und in das Datenbanksystem eingegeben
werden.
 Aktive Metadatenbank: Eine aktive Metadatenbank weist Schnittstellen zum
Datenbanksystem auf und hat damit die Möglichkeit, Informationen gezielt auszutauschen. So können z.B. die Informationen in der Metadatenbank eingegeben
werden und später mittels Schnittstelle in das Datenbanksystem übertragen werden.
Damit entfällt die doppelte Eingabe der Informationen.
 Integrierte Metadatenbank: Eine integrierte Datenbank ist Teil der Datenbank selbst.
Damit werden auch die Metadaten nicht mehr doppelt geführt, sondern müssen
100
nur einmal abgelegt werden, Schnittstellen und Kommunikation entfällen. Integrierte
Metadatenbanken sind die beste Lösung und heute in den meisten Datenbanksystemen standardmässig eingebaut. Damit können z.B. Programme zur Laufzeit Informationen aus der Metadatenbank lesen und verwenden.
Natürlich stellt sich jetzt wiederum die Frage, wo speichert das Datenbanksystem die Informationen über die Struktur der Metadaten (die Meta-Meta-Daten). Im Prinzip könnte eine beliebig
lange Kette von Meta-Ebenen gebildet werden, wobei jede höherliegende Ebene einen höheren Abstraktionsgrad aufweist und im Vergleich zu den untenliegenden Ebenen einfacher gestaltet ist. In der Praxis werden die Strukturinformationen der Metadatenbank aus Gründen der
Effizienz allerdings häufig bereits nicht mehr in einer Meta-Meta-Datenbank abgelegt, sondern
sind als Teil der Programme des Datenbanksystems implementiert.
 Erfüllt das Datenbanksystem in der gegebenen Form nicht die durch den konkreten Einsatz
nötigen Anforderungen, so ist es theoretisch möglich, die Metadatenbank so zu gestalten, dass
die zusätzlichen Anforderungen doch noch befriedigt werden. Dies indem die Strukturinformationen über die Metadatenbank in der Meta-Meta-Datenbank entsprechend ergänzt
werden. Soll z.B. die Anzahl der erlaubten Zeichen für Attributsnamen verlängert werden, so wird
die Domänendefinition für Attribute in der Meta-Meta-Datenbank geändert. Dabei ist zu beachten:
1. Durch die Änderung der Struktur der Metadatenbank müssen allenfalls bestehende
Programme des Datenbanksystems geändert und neue Programme erstellt werden.
2. Bei jedem Versionswechsel des Datenbanksystems müssen die geänderten und neu
erstellten Programme überarbeitet werden. Ausserdem muss sichergestellt werden,
dass die Metadaten vollständig in die neue und geänderte Metadatenbank
übernommen werden.
 Trotz der reizvollen Aufgabe sollte daher in aller Regel darauf verzichtet werden Strukturänderungen vorzunehmen. Bei notwendigen Änderungen müssen diese gezielt vorgenommen und
gut dokumentiert ausgeführt werden.
9.4.2. Transaktionsverwaltung
Die Entitätenverwaltung erlaubt die Verarbeitung der Datenbankobjekte mittels definierter
Operationen. Bisher sind die vom Datenbanksystem dargebotenen Operationen als einzelne,
unabhängige Operationen betrachtet worden. In der Praxis genügt diese Sichtweise aber nicht.
Eine logisch zusammengehörige Operation (aus Sicht der Anwendung) kann sich aus mehreren
Operationen des Datenbanksystems zusammensetzen. So sind z.B. Buchung und Gegenbuchung auf zwei Konten aus abstrakter Sicht eine einzelne Operation, aus Sicht des Datenbanksystems aber aus mindestens zwei oder sogar mehr Operationen zusammengesetzt. Diese
abstrakten Operationen werden Transaktionen genannt.
 Transaktion: Eine Transaktion ist aus Sicht der Anwendung eine unteilbare, ununterbrechbare Operation (bestehend aus beliebig vielen Datenbankoperationen) auf
den Daten des Datenbanksystems [Date 00].
Mittels des Transaktionskonzepts lassen sich zwei wesentliche Eigenschaften von Datenbanksystemen realisieren:
1. Integritätswahrung: Die Integritätsbedingungen werden während der Ausführung
von einzelnen Operationen zwangsläufig verletzt und sind erst nach einer Reihe von
Operationen wieder erfüllt (z.B. Ausführung einer Haben- und Sollbuchung). Das Datenbanksystem muss daher wissen, welche Operationen zusammengehören und die
Datenbank wieder in einen konsistenten Zustand überführen. Mittels Transaktionen
können diese Operationen zu einer einzigen logischen Operation (der Transaktion)
gebündelt werden. Ohne Transaktionskonzept ist daher schwerlich eine griffige InTeil 3: Internes Datenmodell
101
tegritätssicherung zu realisieren. Natürlich muss vom Datenbanksystem auch verhindert werden, dass nur ein Teil der Transaktion ausgeführt wird. Dies ist nicht im Sinne
des Anwenders und würde die Datenbank zudem mehrheitlich in einen inkonsistenten Zustand versetzen.
2. Mehrbenutzerbetrieb: Im Mehrbenutzerbetrieb muss das Datenbanksystem dem
einzelnen Anwender den Eindruck vermitteln, er sei zur Zeit allein im Datenbanksystem aktiv. Es darf nicht geschehen, dass ein Anwender eine Reihe von zusammengehörenden Operationen ausführt und ein anderer Anwender gleichzeitig
die verwendeten Daten verändert. Dadurch könnten Daten verloren gehen oder
widersprüchlich gespeichert werden. Das Datenbanksystem muss damit während
den logisch zusammengehörenden Operationen (der Transaktion) sicherstellen,
dass kein anderer Benutzer die Daten lesen oder ändern kann.
Transaktion 1:
Verbuchen Ertrag
Transaktion 2:
Verbuchen Aufwand
Einlesen des Ertrages
Einlesen des Aufwandes
Kontostand Konto
'Kasse' lesen
Kontostand Konto
'Gewinn' lesen
Kontostand Konto
'Gewinn' lesen
Kontostand Konto
'Kontokorrent' lesen
Kontostand Konto
'Kasse' um Ertrag erhöhen
Kontostand Konto
'Kontokorrent' um Aufwand
verkleinern
Zeit
Kontostand Konto
'Gewinn' um Ertrag erhöhen
Kontostand Konto
'Gewinn' um Aufwand
verkleinern
Figur 41: Fehlerbeispiel für Mehrbenutzerbetrieb ohne Transaktionslogik
In der Figur wird die zeitliche Abfolge gezeigt, in welcher zwei Benutzer die gemeinsamen Daten
ohne schützende Transaktionslogik verändern und dadurch am Ende ihrer Arbeit einen inkonsistenten Zustand der Daten hinterlassen. Im Beispiel wird nur der Aufwand im Gewinnkonto verbucht. Der Ertrag wird nur im Konto Kasse verbucht, denn die nachfolgende Operation beim
Verbuchen des Aufwandes im Gewinnkonto überschreibt die Verbuchung des Gewinnes im
Gewinnkonto wieder.
Zur Realisierung des Transaktionskonzepts muss das Datenbanksystem eine Reihe von Fähigkeiten aufweisen:
1. Änderungen an Daten durch unvollständig abgelaufene Transaktionen (z.B. beim
Systemabsturz, Programmfehlern) oder durch Transaktionen mit einem integritätsverletzenden Endzustand müssen auf den ursprünglichen Zustand zurückgesetzt werden. Derartige fehlerhafte Transaktionen dürfen keine Spuren in den Daten hinterlassen.
2. Dagegen muss sichergestellt sein, dass Transaktionen, welche erfolgreich abgeschlossen wurden, auch tatsächlich in der Datenbank gespeichert sind. Es darf
102
nicht der Fall eintreten, dass Änderungen verloren gehen, weil diese nur im Systempuffer abgelegt waren (z.B. beim Systemabsturz).
3. Im Mehrbenutzerbetrieb muss verhindert werden, dass Transaktionen anderer Benutzer Daten lesen, welche durch die eigene laufende Transaktion verändert oder
eingefügt wurden. Würden andere Benutzer diese Daten als Basis für ihre Transaktionen nehmen, die eigene Transaktion aber abgebrochen und die bisherigen
Änderungen zurückgesetzt, würden die anderen Transaktionen auf falschen Daten
basieren.
4. Ausserdem muss im Mehrbenutzerbetrieb verhindert werden, dass andere Transaktionen Daten ändern, welche die eigene Transaktion lediglich gelesen hat. Wäre
dies erlaubt, könnten z.B. die von der eigenen Transaktion gelesenen Daten zum Teil
auf einem alten und zum Teil auf einem neuen Stand basieren.
Zur Realisierung dieser Fähigkeiten sind im Wesentlichen drei Algorithmen von Interesse. Diese
drei Algorithmen werden als optimistisches, pessimistisches und Zeitstempel-Verfahren bezeichnet. Im Folgenden werden diese kurz, aber nicht im letzten Detail besprochen.
 Die drei im Folgenden aufgeführten Algorithmen stellen sicher, dass der parallele Betrieb von
Transaktionen zu gültigen Resultaten führt. Ein Transaktionsalgorithmus gilt dann als korrekt, wenn
er serialisierbar ist, d.h., dass die Resultate, welche durch den Transaktionsalgorithmus erzeugt
werden, auch durch irgendeine erlaubte serielle Ausführung der Transaktionen erzeugt würden.
9.4.2.1. Optimistisches Verfahren
Dieses Verfahren wird optimistisches Verfahren genannt, weil die Grundannahme des Algorithmus jene ist, dass es sehr selten Konflikte zwischen den unterschiedlichen Anwendern im Zugriff auf die Daten gibt. Der Algorithmus wird leider sehr ineffizient, falls es dennoch häufig zu
Konflikten kommt. Im schlechtesten Fall kann kein einziger Anwender mehr seine Transaktion erfolgreich beenden. Dieser gravierende Mangel hat auch verhindert, dass dieser Algorithmus in
bestehenden Datenbanksystemen realisiert wurde. Welcher Hersteller könnte sein Datenbanksystem mit dieser Einschränkung erfolgreich verkaufen?
Hier soll daher auch nur kurz und oberflächlich die Funktionsweise des Algorithmus erläutert
werden. Während der eigentlichen Transaktion, in der Lesephase, werden sämtliche Änderungen an den Daten nicht an den Daten selbst, sondern an Kopien der Daten vorgenommen. Erst
am Ende der Transaktion wird in der Validierungsphase überprüft, ob es zu einem Konflikt mit
anderen Transaktionen gekommen ist. Ist kein Konflikt aufgetreten, werden die Änderungen an
den Daten in der Schreibphase auf die effektiven Daten übertragen. Im Falle eines Konfliktes
werden die Änderungen auf den Kopien verworfen.
9.4.2.2. Pessimistisches Verfahren
Das pessimistische Verfahren oder auch Sperrverfahren ist das bedeutendste Verfahren für die
Praxis. Die Mehrzahl der Datenbanksysteme verwendet dieses Verfahren. Im Gegensatz zum optimistischen Verfahren wird ein allfälliger Konflikt nicht erst am Ende der Transaktion festgestellt,
sondern es wird jeder einzelne Zugriff unmittelbar auf Konflikte überprüft. Zudem kann garantiert
werden, dass selbst bei höchster Last immer wieder Transaktionen erfolgreich beendet werden.
Da dieses Verfahren das meistverbreitete Verfahren ist und weil das Verfahren auf das Erstellen
der Anwendungsprogramme Einfluss nimmt, soll es hier entsprechend detailliert erläutert werden.
Grundidee des pessimistischen Verfahrens ist es, ein Verzeichnis der durch die aktuell aktiven
Transaktionen benutzen Objekte mit Verweis auf die Nutzungsart in einer zentralen Sperrtabelle
(Locktabelle) anzulegen (siehe Tabelle unten). Dazu eignen sich zunächst zwei Nutzungsarten:
1. Lesesperre (Shared Lock): Das Objekt wurde durch die Transaktion gelesen.
2. Schreibsperre (Exclusive Lock): Das Objekt wurde durch die Transaktion verändert
und in die Datenbasis geschrieben.
Sperrobjekt
Nutzungsa rt
Verwendungsna chwies
Datensatz 253
Schreibsperre
Transaktion T1
Datensatz 563
Lesesperre
Transaktionen T1, T2, T4
Datensatz 974
Lesesperre
Transaktion T1
Datensatz 2983
Schreibsperre
Transaktion T2
...
...
...
103
Figur 42: Beispiel einer Sperrtabelle
Bei jedem Lese- oder Schreibzugriff innerhalb einer Transaktion auf ein Objekt des Datenbanksystems muss nun überprüft werden, ob kein Konflikt vorhanden ist. Dabei können folgende Fälle
auftreten:
1. Falls das Objekt noch nicht in der zentralen Tabelle vorhanden ist, ist der Zugriff sicher erlaubt. Das Objekt muss noch mit der Identifikation der entsprechenden
Transaktion (Transaktionsmarke) und der Nutzungsart eingetragen werden.
2. Das Objekt wird ausschliesslich durch die eigene Transaktion genutzt: Der Zugriff ist in
jedem Fall erlaubt. Falls die Nutzungsart vorgängig ‘gelesen’ war und das Objekt
geändert wird, muss neu die Nutzungsart ‘geschrieben’ gesetzt werden.
3. Das Objekt soll gelesen werden und wurde bereits durch eine oder mehrere andere
Transaktionen gelesen (ohne Schreiboperationen): So lange die anderen Transaktionen die verwendeten Daten nicht ändern, besteht keine Gefahr, der Zugriff ist erlaubt. Damit keine andere Transaktion die gelesenen Daten ändert, wird in der Tabelle das Objekt mit der Nutzungsart ‘gelesen’ durch die eigene Transaktion eingetragen.
4. Das Objekt soll gelesen werden, wurde aber bereits durch eine andere laufende
Transaktion geändert: Die eigene Transaktion darf auf die Daten nicht zugreifen,
denn der effektive Zustand der Daten ist erst bekannt, wenn die andere Transaktion
beendet wird. Würden die Daten dennoch verwendet, bestünde z.B. die Gefahr,
dass die Daten als ganzes inkonsistent erscheinen. Die eigene Transaktion muss daher so lange warten, bis die andere Transaktion beendet ist und die Daten wieder
frei gibt (d.h. Fall 1, 2 oder 3 eintritt).
5. Das Objekt soll geändert werden und wurde bereits durch eine andere Transaktion
gelesen oder geändert: Die eigene Transaktion darf die Daten nicht ändern und
muss warten, bis die anderen Transaktionen die Daten vollständig freigegeben
haben. Würde z.B. eine andere Transaktion abgebrochen und müsste zurückgesetzt
werden, dann würden die Änderungen der eigenen Transaktion verloren gehen
oder die Transaktion müsste ebenfalls zurückgesetzt werden (d.h. Fall 1 oder 2 tritt
ein).
Die Eintragungen in der Locktabelle müssen bis zum endgültigen Ende der Transaktion bestehen
bleiben und dürfen nicht früher freigegeben werden. Würden Objekte noch während der
Transaktion freigegeben, so könnte z.B. bei einem Fehler der eigenen Transaktion diese nicht
mehr korrekt zurückgesetzt werden, falls eine andere Transaktion Daten, welche die eigene
Transaktion geändert hat, später auch geändert hat und die andere Transaktion bereits erfolgreich das Ende der Transaktion erreicht hat. Transaktionen tragen damit während der Transaktion mehr und mehr Sperren in die Tabelle ein (Wachstumsphase) und geben sämtliche Sperren
am Ende der Transaktion gleichzeitig frei (Schrumpfungsphase). Dieses Verfahren wird daher
strikt zweiphasig genannt. Strikt, da die Sperren bis zum Ende gehalten werden.
104
Anz. Sperren
Zeit
Transaktionsstart
Transaktionsende
Figur 43: Sperrenanzahl einer Transaktion bei strikt zweiphasigem Verfahren
Bisher war einfach von Daten bzw. Objekten die Rede, die gesperrt werden. Dabei sind grundsätzlich zwei Ansätze möglich. Entweder werden die logischen Objekte der Datenbank (z.B. die
einzelnen Datensätze) oder es werden die physischen Objekte (z.B. Segmente des Systempuffers) gesperrt. Je kleiner der Sperrbereich ist, desto kleiner ist die Wahrscheinlichkeit, dass sich
Transaktionen gegenseitig behindern. So werden beim Sperren eines Segments i.d.R. mehrere
Datensätze gesperrt. Dafür wird, je kleiner der Sperrbereich, der notwendige Verwaltungsaufwand umso grösser. Es gilt damit zwischen der Wahrscheinlichkeit der gegenseitigen Behinderung und dem Verwaltungsaufwand abzuwägen. In der Praxis haben sich jene Systeme durchgesetzt, welche die logischen Objekte der Datenbank sperren.
Prinzipiell können die logischen Objekte der Datenbank auf unterschiedlicher Stufe gesperrt
werden. So ist es z.B. denkbar, anstelle des ganzen Datensatzes nur die betroffenen Attribute
des Datensatzes zu sperren. In den meisten Datenbanksystemen werden aber nur Datensätze
und allenfalls ganze Entitätsmengen gesperrt. Damit ist auch schon angedeutet, dass ein Datenbanksystem nicht nur genau zwei Arten von Sperren (Lese- und Schreibsperre) haben kann,
sondern dass eine ganze Reihe von verschiedenen Sperrtypen auftreten können. Zusätzlich zur
Differenzierung der gesperrten Objekte kann auch noch detaillierter auf die gewünschte Zugriffsart eingegangen werden. In der Praxis muss daher abgeklärt werden, welche Sperrmodi
das eingesetzte Datenbanksystem unterstützt.
Damit das Datenbanksystem weiss, wann eine Transaktion beginnt und wann sie wieder endet,
müssen die Transaktionsgrenzen definiert werden. Hierfür müssen drei Befehle vom Datenbanksystem in dessen Sprache zur Verfügung gestellt werden:
1. Transaktionsstart (z.B. ‘Begin Of Transaction’): Sämtliche nachfolgenden Befehle sind
Teil der Transaktion.
2. Transaktionsende (z.B. ‘End Of Transaction’ oder ‘Commit’): Mit diesem Befehl wird
die Transaktion erfolgreich abgeschlossen. Sämtliche Änderungen müssen unwiderruflich gespeichert werden und alle Sperren müssen anschliessend freigegeben
werden.
3. Transaktionsabbruch (z.B. ‘Rollback’, ‘Undo’): Tritt innerhalb der Transaktion ein
Fehler auf, muss es möglich sein die Transaktion abzubrechen und sämtliche bisher
durchgeführten Änderungen auf den Anfangszustand zurückzusetzen (Rollback =
zurückrollen).
Um die Arbeit anderer Benutzer möglichst wenig zu behindern und die Performance des Systems nicht zu belasten, sollten Transaktionen möglichst wenige Befehle beinhalten. Die Startund Endemarke der Transaktion sollten daher in Programmen möglichst nahe beieinander liegen. Vorbereitende Datenbankzugriffe sollten wenn immer möglich (d.h. die konsistente Sicht
auf die Daten ist dennoch gewährleistet) ausserhalb der Transaktion liegen. Zusammengehörige
Lese- und Änderungsoperationen müssen aber innerhalb der Transaktionsgrenzen liegen. Durch
eine geeignete Strukturierung der Programme können die Transaktionen meist deutlich gekürzt
werden.
Im pessimistischen Verfahren kann eine Situation auftreten, in welcher sich zwei oder mehr
Transaktionen gegenseitig derart blockieren, dass keine der Transaktionen mehr mit der Verarbeitung fortfahren kann. Diese Situation tritt z.B. ein, wenn die Transaktion T1 das Datenbankobjekt O1 mittels Schreibsperre exklusiv für sich reserviert und nun auf das Datenbankobjekt O2 zugreifen möchte. Das Datenbankobjekt O2 hat wiederum die Transaktion T2 mittels Schreibsperre
105
exklusiv für sich reserviert, welche gleichzeitig versucht auf das Datenbankobjekt O1 zuzugreifen. Damit wartet T1 darauf, dass T2 O2 freigibt und T2 wartet darauf, dass T1 O1 freigibt. Ohne
Eingriff von aussen wären die beiden Transaktionen für immer blockiert. Diese Verklemmungssituation wird als Deadlock bezeichnet.
 Bei einem Deadlock blockieren sich zwei oder mehr Transaktionen gegenseitig, so
dass ohne Eingriff von aussen keine der betroffenen Transaktionen mehr mit der
Verarbeitung fortfahren kann.
Grundsätzlich sind zwei Ansätze zum Erkennen eines Deadlocks möglich. Im ersten Ansatz geht
das Datenbanksystem davon aus, dass eine Deadlocksituation dann vorliegt, wenn eine Transaktion für eine bestimmte Zeit (z.B. 10 Minuten) auf die Freigabe eines Objektes warten muss.
Durch diesen Algorithmus werden allenfalls Transaktionen abgebrochen, für die gar keine
Deadlocksituation vorlag.
Im zweiten Ansatz untersucht das Datenbanksystem, wer auf wen wartet und erkennt die Deadlocksituation korrekt. Betrachtet man die nachfolgende Figur, so ist leicht zu erkennen, wann eine Deadlocksituation auftritt. Der Pfeil stellt dar, dass z.B. Transaktion 2 darauf wartet, dass
Transaktion 4 ein Objekt freigibt. Eine Deadlocksituation besteht damit genau dann, wenn in der
Grafik ein geschlossener Zyklus (im Beispiel unten rot markiert) existiert.
T6
T2
T1
T4
T5
T3
Figur 44: Deadlock mit mehreren Transaktionen
Zur Auflösung des Deadlocks muss eine der betroffenen Transaktionen abgebrochen werden
(d.h. der Kreis zerstört werden). Im ersten Ansatz fällt dieser Entscheid dahin. Im zweiten Ansatz
muss jedoch eine der Transaktionen, welche sich gegenseitig blockieren, ausgewählt werden.
Hier sind wiederum unterschiedliche Algorithmen in unterschiedlichen Datenbanksystemen realisiert worden. Sinnvoll wäre es z.B. jene Transaktion auszuwählen, welche bisher am wenigsten
Rechenzeit verwendet hat. Hier zeigt sich auch der Nachteil des ersten, einfacheren Ansatzes.
Dieser setzt immer jene Transaktion zurück, die am längsten von allen gewartet hat.
 In bestimmten Datenbanksystemen wird der Transaktionsbeginn und/oder das Transaktionsende
nicht explizit in den Programmen festgelegt, sondern implizit durch das Datenbanksystem bestimmt. Um sicherzustellen, dass während der gesamten Transaktion (aus der Sicht des Entwicklers) die verwendeten Objekte korrekt gesperrt werden, muss durch den Entwickler überprüft
werden, ob das Datenbanksystem den Start- und Endpunkt der Transaktion korrekt erkennt. Gegebenenfalls muss steuernd eingegriffen werden.
 Oben wurde ein Ansatz mit zwei Sperrmodi eingeführt und darauf verwiesen, dass Datenbanksysteme zum Teil noch weitere Sperrmodi haben. Leider gibt es auch Systeme, welche nur die
Schreibsperre kennen, aber keine Lesesperre aufweisen. Zur Wahrung der konsistenten Sicht auf
die Daten während der Transaktion müssten diese Datenbanksysteme gelesene Daten ebenfalls
mit einer Schreibsperre versehen. Genau darauf verzichten diese Datenbanksysteme aber in aller Regel. Es wird damit dem Entwickler überlassen zu überprüfen, ob die Gefahr besteht, dass
durch die Transaktion eine inkonsistente Sicht auf die Daten entsteht. Dies ist kein einfacher Entscheid. Verhindert werden kann dies dann nur dadurch, dass gelesene Daten ebenfalls mit einer Schreibsperre versehen werden. Hierfür müssen gelesene Daten zusätzlich mittels einer Änderungsoperation ohne Änderung (Pseudo-Update) bearbeitet werden.
106
 Leider treten in der Praxis häufig Transaktionen auf, welche sehr lange dauern. Dies ist z.B. dann
der Fall, wenn der Benutzer eine grössere Menge von Daten eingeben bzw. ändern muss. Ändert diese Transaktion Daten, welche durch andere Transaktionen ebenfalls häufig benötigt
werden, kann schnell ein Engpass in der Verarbeitung auftreten. Dieses Problem wir häufig mittels folgendem Algorithmus gelöst:
1. Die benötigten Daten werden vor dem eigentlichen Start der Transaktion gelesen.
Damit werden diese nicht mit einer Lesesperre versehen und können durch andere
ohne Einschränkungen genutzt werden.
2. Der Benutzer gibt die Daten ein, bzw. ändert die Daten. Hierbei werden nicht die eigentlichen Daten selbst, sondern Kopien der Daten verwendet.
3. Nachdem der Benutzer abgeschlossen hat, wird der Transaktionsstart ausgeführt.
4. Jetzt muss überprüft werden, ob die betroffenen Daten zwischenzeitlich geändert
wurden. Dies erfolgt z.B. mit einem Zeitstempel, welcher im Datensatz gespeichert
ist. Wurden die Daten geändert, muss jetzt die Transaktion abgebrochen (Rollback)
werden.
5. Die Änderungen werden an den Daten durchgeführt und die Transaktion abgeschlossen.
 Sinnvoll ist dieses Vorgehen insbesondere dann, wenn ein Teil der vor Beginn der Transaktion
gelesenen Daten, ohne Einfluss auf den Erfolg der Transaktion, geändert werden dürfen. D.h. im
Schritt 4 werden nicht sämtliche, sondern nur ein Teil der Daten auf Änderungen untersucht.
Dieses Verfahren wird häufig Read-Before-Update genannt. Im Prinzip handelt es sich um ein
erweitertes, selektives, optimistisches Verfahren.
9.4.2.3. Zeitstempel-Verfahren
Im pessimistischen Verfahren werden die Informationen über die aktiven Lese- und Schreiboperationen in einer zentralen Tabelle verwaltet. Beim Zeitstempelverfahren werden diese Informationen nun direkt beim betroffenen Datensatz abgelegt. Jeder Datensatz muss hierfür mit
einer Lese- und Schreibmarke versehen werden. Die Lesemarke hält fest, wann der Datensatz
zum letzten Mal gelesen wurde. Die Schreibmarke hält fest, wann der Datensatz zum letzten Mal
geändert wurde. Beim Lesen bzw. Schreiben eines Datensatzes müssen nun folgende Bedingungen überprüft werden:
 Lesen: Der Zeitpunkt der Schreibmarke muss vor der Startzeit der Transaktion, festgehalten in der Transaktionsmarke, liegen.
 Schreiben: Der Zeitpunkt der Lese- und der Schreibmarke muss vor der Startzeit der
Transaktion liegen.
Ist eine der beiden Bedingungen nicht erfüllt, so ist die Operation nicht erlaubt. Das ZeitstempelVerfahren hat aber einen gravierenden Nachteil. Das Verfahren kann nur dann ordnungsgemäss ablaufen, wenn die Transaktion nur eine einzige Schreiboperation aufweist. Treten mehrere eigenständige Schreiboperationen auf, dann können andere Transaktionen die vorgängigen eigenen Schreiboperationen allenfalls noch zu Laufzeit der eigenen Transaktion wieder
überschreiben. Andere Transaktionen dürfen die geänderten Daten nämlich ändern, falls diese
zeitlich nach der Änderung gestartet wurden. Im Fehlerfall der eigenen Transaktion ist dann das
Rücksetzen nicht mehr möglich. Für den praktischen Einsatz muss das Zeitstempel-Verfahren daher noch dahingehend ergänzt werden, dass die Änderungsoperationen zusammen in einem
einzigen logischen Schritt ausgeführt werden.
Das Zeitstempelverfahren weist aber noch einen weitere Nachteil im Vergleich zum pessimistischen Verfahren auf. Während im pessimistischen Verfahren im Falle eines Konfliktes die betroffene Transaktion wartet, bis das angeforderte Datenbankobjekt freigegeben wird, wird die
Transaktion im Zeitstempel-Verfahren sofort abgebrochen. Die Wahrscheinlichkeit, dass eine
107
Transaktion im Zeitstempel-Verfahren erfolgreich abgeschlossen werden kann, ist daher kleiner
als im pessimistischen Verfahren.
9.4.2.4. Transaktionslogik in verteilten Datenbanksystemen
Bei verteilten Datenbanksystemen, d.h. die Daten sind auf mehrere parallel arbeitende Datenbanksysteme verteilt, sind die entsprechenden Algorithmen für das Zeitstempelverfahren relativ
einfach zu realisieren. Es muss lediglich dafür gesorgt werden, dass ein zentraler Taktgeber die
‘Uhren’ der Systeme gleichschaltet. Natürlich muss im Fehlerfall dafür gesorgt werden, dass
sämtliche Änderungsoperationen auf allen Datenbanksystemen zurückgesetzt werden.
Im pessimistischen Verfahren ist der Sachverhalt etwas komplizierter. Im pessimistischen Verfahren wurden die Daten der Sperren zentral in der Locktabelle verwaltet. Würde diese Tabelle
nun zentral auf einem zuvor bestimmten Datenbanksystem verwaltet, müssten sämtliche Leseund Schreib-Operationen an jene Datenbank mitgeteilt werden. Die Verwaltung der Locktabelle an und für sich ist schon eine sehr rechenintensive Angelegenheit, so dass Datenbankhersteller diese mit grosser Umsicht implementieren. Würde nun zusätzlich für jede Operation eine
Kommunikation zwischen den unterschiedlichen Datenbanksystemen notwendig, wäre die Leistung des Datenbanksystems stark beeinträchtigt. Um diesen Kommunikationsaufwand möglichst
klein zu halten, synchronisieren sich heutige Datenbanksysteme erst wieder am Ende ihrer Transaktionen. Das Verfahren wird Two-Phase-Commit (Zwei-Phasen-Bestätigung) genannt:
 Phase 1: Jedes Datenbanksystem startet eine eigene Transaktion und versucht die
anfallenden Operationen auszuführen. Am Ende der systemübergreifenden Transaktion versuchen die einzelnen Datenbanksysteme ihre Transaktionen abzuschliessen. Dabei dürfen die Sperren auf die Objekte aber noch nicht freigegeben
werden. Ist die Teiltransaktion erfolgreich beendet worden, so meldet das Datenbanksystem dies an den zentralen Transaktionsmanager (Commit der ersten Phase).
 Phase 2: In der zweiten Phase wird überprüft, ob alle beteiligten Datenbanksysteme
die betroffene Transaktion erfolgreich beenden konnten. Ist dies der Fall, so können
die Transaktionen endgültig abgeschlossen (Commit der zweiten Phase), die
Sperren auf die Datenbankobjekte zurückgezogen werden. Im Fehlerfall müssen
sämtliche Transaktionen zurückgesetzt (Rollback) werden.
9.4.3. Integritätssicherung im Datenbanksystem (interne Ebene)
Die Integrität der Daten wurde bereits auf konzeptioneller Ebene besprochen, siehe ‘8. Integrität
im konzeptionellen Modell’ auf Seite 83. An dieser Stelle soll die Integrität aus Sicht des Datenbanksystems auf der internen Ebene betrachtet werden. Dabei sollen aber nicht die technischen Integritätssicherungen im Datenbanksystem selbst (z.B. Paritätsbit), sondern nur jene Integritätsmassnahmen betrachtet werden, welche die Integrität der Benutzerdaten selbst (Miniwelt) sicherstellen.
9.4.3.1. Datenkonsistenz
Bei der Betrachtung der integritätssichernden Massnahmen stellt sich zunächst die Frage nach
der Effizienz. Integritätsregeln erfordern häufig zusätzliche Datenbankoperationen. Wird nicht
nur eine einfache Integritätsregel überwacht (z.B. die Geschwindigkeit muss zwischen 0 und 200
liegen), so müssen meist zusätzliche Werte in der Datenbank gelesen werden (z.B. der eingegebene Wechselkurs darf nur 5% vom Tageskurs abweichen). Diese Zugriffe müssen bei der Definition der Integritätsregel bezüglich Rechenleistung vorsichtig beurteilt werden.
Bei der Realisierung der Integritätssicherung haben die Datenbankhersteller deutlich abweichende Wege beschritten. Diese sollen nur im Ansatz aufgezeigt werden. Ein erster Ansatz ist es,
die Programme vor der eigentlichen Übersetzung durch den Compiler mit einem speziellen PreCompiler zu übersetzen. Dieser untersucht die auftretenden Änderungsoperationen und überTeil 3: Internes Datenmodell
108
prüft, welche Integritätsregeln davon berührt werden. Falls er derartige Operationen findet, ergänzt er diese in geeigneter Weise, so dass die Integritätsregeln nicht verletzt werden können.
Wird dieser Ansatz gewählt, ist es dem professionellen Anwender meist möglich, die Operationen auf einer tieferen Schicht der Datenbank auszuführen und damit die Integritätsregeln zu
umgehen. Zudem müssen Online-Abfragen vor ihrer Ausführung aufwändig überprüft werden
und sind damit entsprechend langsamer.
Ein anderer Ansatz legt die Überprüfung der Integritätsregeln im Kern des Datenbanksystems ab.
Der Zugriff auf die Daten erfolgt hierbei immer über ein Modul. Dieses Modul wird nach der Definition der Integritätsregeln generiert und beinhaltet deren Überprüfung. Ein Umgehen der Integritätsregeln ist damit ausgeschlossen. Die Performance des Systems ist in Programmen und Online-Abfragen gleichermassen gut. Allerdings können nur unverzögerte Integritätsregeln überprüft
werden (d.h. nach jeder einzelnen Operation), aber keine Integritätsregeln, die erst am Ende
der Transaktion erfüllt sein müssen.
9.4.3.2. Datensicherheit, Recovery
Das oben eingeführte Transaktionskonzept stellt besondere Anforderungen an die Datensicherheit im Datenbanksystem. Änderungen durch Transaktionen dürfen nur gänzlich oder gar nicht
im Datenbestand Eingang finden. Das Datenbanksystem muss daher in bestimmten Fällen fähig
sein, bereits vollzogene Änderungen rückgängig zu machen, bzw. verlorene Änderungen erneut in den Datenbestand einfliessen zu lassen. Für einen sicheren Betrieb sind zumindest folgende vier Recovery-Massnahmen notwendig [Reuter 81]:
1. Partielles Zurücksetzen (partieller Rollback): Falls eine einzelne Transaktion nicht erfolgreich abgeschlossen werden kann, müssen sämtliche bisher durchgeführten Änderungen der Transaktion wieder auf den Startzustand zurückgesetzt werden. Parallel hierzu laufende Transaktionen dürfen dabei nicht gestört werden.
2. Partielles Wiederholen (partieller Rollforward): Bei einem Systemausfall müssen Änderungen, welche erfolgreich abgeschlossene Transaktionen ausgeführt haben, die
nur im Systempuffer nicht aber auf dem externen Speichermedium abgelegt wurden, nachträglich im externen Speichermedium eingetragen werden.
3. Vollständiges Zurücksetzen (vollständiger Rollback): Sämtliche Änderungen aller
Transaktionen, die zum Zeitpunkt eines Systemabsturzes noch aktiv waren, müssen
zur Konsistenzerhaltung beim erneuten Starten des Datenbanksystems rückgängig
gemacht werden.
4. Vollständiges Wiederholen (vollständiger Rollforward): Bei einem Defekt der externen Speichermedien (z.B. bei einem Head-Crash) muss der letzte konsistente
Zustand wieder hergestellt werden. Hierfür muss zunächst eine Archivkopie geladen
werden und anschliessend müssen sämtliche nachträglichen Änderungen von
erfolgreich abgeschlossenen Transaktionen wiederholt werden.
Bei einem Systemabsturz müssen in einem ersten Schritt sämtliche unerwünschten Änderungen
nicht abgeschlossener Transaktionen im externen Speichermedium mittels vollständigem Rücksetzen (Rollback) beseitigt werden. Im zweiten Schritt müssen verloren gegangene Änderungen
abgeschlossener Transaktionen durch ein partielles Wiederholen (Rollforward) wieder aufgenommen werden.
Im Folgenden wird anhand einiger einfacher Operationen gezeigt, wie das Datenbanksystem
die oben aufgezählten Forderungen erfüllen kann. Grundsätzlich ist es natürlich immer derart,
dass die Sicherheit nur durch Sammeln von redundanten Informationen erhöht werden kann.
Die folgenden Ausführungen zeigen daher hauptsächlich, welche redundanten Informationen
zu welchem Zeitpunkt durch das Datenbanksystem abgelegt werden. Diese Redundanzen
werden im Protokoll bzw. Log festgehalten. Entsprechend wird das Verfahren als Protokollierungsverfahren bzw. Logging bezeichnet.
109
2.
1.
3.
BeforeIm age
Datensatz
After-Im age
4.
6.
tem poräre
Protokolldatei
System puffer
Daten
5.
After-Im age
ArchivProtokolldatei
Figur 45: Physisches Logging
Im Bild werden die einzelnen Schritte gezeigt, welche das Datenbanksystem zum Lesen und
Ändern eines Datenbankobjektes (z.B. Datensatz) ausführt:
1. Das gewünschte Datenobjekt wird vom externen Speichermedium in den Systempuffer kopiert. Zur Vereinfachung sei angenommen, dass das Datenbanksystem die
logischen Objekte des Datenbanksystems (hier ein Datensatz) für das Logging verwendet, und dass die Segmente des Systempuffers exakt einem Datensatz entsprechen.
2. Soll eine Änderung an den Daten vorgenommen werden, so muss vorerst eine Kopie
des aktuellen Zustandes vom Datensatz angelegt werden. Diese Kopie wird als Before-Image (Vor-Abbild) bezeichnet. Die Kopie wird in der temporären Protokolldatei
(rascher, nichtflüchtiger Speicher) abgelegt. Mittels dieser Kopie kann später ein
partieller oder vollständiger Rollback ausgeführt werden.
3. Nun können die Änderungen an den Daten ausgeführt werden.
4. Schliesst die Transaktion die Verarbeitung erfolgreich ab, muss sichergestellt werden,
dass die ausgeführten Änderungen nicht verloren gehen können. Hierfür wird eine
Kopie des geänderten Datensatzes im schnellen Speichermedium der temporären
Protokolldatei abgelegt. Dieses Abbild des geänderten Zustandes wird als AfterImage (Danach-Abbild) bezeichnet. Diese Kopien ermöglichen das partielle Wiederholen nach einem Systemabsturz.
5. Für ein vollständiges Wiederholen ist die temporäre Protokolldatei ungeeignet, da
sämtliche Änderungen seit dem Erstellen der letzten Archivkopie gespeichert werden müssen, was eine beträchtliche Menge an Daten wäre. Es wird daher ein günstigeres, dafür langsameres Speichermedium für die Archiv-Protokollldatei verwendet. Auf keinen Fall dürfen die After-Images aber auf dem selben physischen
Speichermedium wie die Daten selbst liegen, ansonsten wären diese z.B. bei einem
Head-Crash ebenfalls verloren.
6. Wird das Segment zu einem beliebigen späteren Zeitpunkt im Systempuffer für
andere Daten benötigt, so werden die geänderten Daten auf das externe
Speichermedium geschrieben und das Segment freigegeben. After-Images in der
temporären Protokolldatei, welche Änderungen für dieses Segment festgehalten
hatten, können jetzt gelöscht werden.
Bei einem Systemabsturz stellt sich allerdings noch immer ein Problem. Da das Datenbanksystem
nicht weiss, welches die erste älteste Änderung ist, die nicht vom Systempuffer auf das externe
110
Speichermedium übertragen wurde, müssen sämtliche Änderungen seit dem letzten Start des
Datenbanksystems nachgeholt werden (partieller Rollforward). Dies kann lange Laufzeiten erfordern. Um dies zu verhindern werden während der Verarbeitung Checkpoints (Sicherungspunkte) gesetzt.
Bei einem Checkpoint werden sämtliche Daten des Systempuffers auf das externe Speichermedium übertragen. Damit ist der Zeitpunkt, ab welchem die Änderungen nachgeholt werden
müssen, bekannt. Im Extremfall könnte immer am Ende einer Transaktion ein Checkpoint gesetzt
werden. Damit würde der partielle Rollforward überflüssig, denn alle Änderungen wären immer
im externen Speicher abgelegt. Leider kostet auch der Checkpoint Zeit (zum Teil einige Sekunden), so dass dieser nur abgestimmt eingesetzt werden darf.
9.4.3.3. Datenschutz, Kryptographie
Der Datenschutz wurde auf konzeptioneller Ebene bereits im Kapitel ‘8.2. Datenschutz im konzeptionellen Modell’ auf Seite 84 besprochen. Hier sollen Schutzmassnahmen auf physischer
Ebene gezeigt werden. Dabei spielt das Betriebssystem eine wichtige Rolle. Das Betriebssystem
sollte über sichere Massnahmen zur Identifikation und Authentisierung der Benutzer verfügen.
Dadurch kann sichergestellt werden, dass tatsächlich nur berechtigte Benutzer das Datenbanksystem verwenden. Ausserdem sollte das Betriebssystem Möglichkeiten bieten, auch Dateien
vor unerlaubten Zugriffen zu schützen. Nur so können Daten, welche z.B. auch in Zugriffswegen
und Protokolldateien liegen, effektiv vor unerwünschten Einblicken geschützt werden.
Mittels Kryptographie können Daten verschlüsselt in den Dateien abgelegt und bei Bedarf auch
verschlüsselt über die Leitungen verschickt werden. Verschlüsselte Daten können nur mit grösstem Aufwand entschlüsselt werden. Verschlüsselte Daten bieten daher einen guten Schutz,
auch wenn der Zugriff versehentlich erfolgte. Zum vollständigen Schutz müssen, wie Eingangs
bereits erwähnt, natürlich auch alle redundanten Informationen verschlüsselt werden. Damit
müssen bei Schlüsseländerungen die alten Schlüssel aufbewahrt werden, da ansonsten z.B. eine
alte Archivkopie nicht mehr entschlüsselt werden kann.
9.4.4. Cursor-Verwalter 
Das durch den Cursor-Verwalter realisierte Currency-Konzept ermöglicht die satzorientierte Verarbeitung der Datensätze. Die nächsthöhere Schicht realisiert zwar die mengenorientierte Verarbeitung, dennoch ist es in Programmen häufig trotzdem notwendig, die Daten Satz für Satz zu
lesen und zu verarbeiten. So stellt z.B. auch die mengenorientierte Sprache SQL das CurrencyKonzept zur Verfügung (SQL-Befehl: ‘DECLARE CURSOR’).
Mittels Cursor (häufig auch Datensatzzeiger genannt) wird die aktuelle Position in einer Menge
von Datensätzen festgehalten. Diese Cursor können vom Datenbanksystem implizit erstellt werden oder müssen explizit durch den Anwender definiert werden. Weitere Operationen erlauben
den Programmen, den Cursor innerhalb der Menge auf jeden beliebigen Datensatz zu setzen
und diesen gezielt zu verarbeiten. Typische Operationen sind ‘springe auf den nächsten / vorhergehenden Datensatz’ und ‘gehe auf den ersten / letzten Datensatz’.
DECLARE Cursor_Aufträge_Kunde CURSOR FOR
SELECT Auftrags_Nr, Auftraggeber_Nr, Auftrags_Datum
FROM Aufträge
WHERE Aufträge.Auftraggeber_Nr = Kunden.Kunden_Nr
Figur 46: Explizite Cursordefinition in SQL
9.5. Entitätsmengenverwaltung
Während mit der satzorientierten Schnittstelle eine satzorientierte Verarbeitung ermöglich wird,
wird mittels der Entitätsmengenverwaltung (auch zugriffspfadunabhängiges Datenmodell geTeil 3: Internes Datenmodell
111
nannt) die mengenorientierte Schnittstelle realisiert. Anfragen und Änderungsoperationen können dann auf ganze Mengen von Daten ausgeführt werden (z.B. Zeige die Angestellten in Zürich). Die Entitätsmengenverwaltung übersetzt hierfür die mengenorientierten Anfragen in satzorientierte Anfragen.
9.5.1. Zugriffspfadoptimierer, Optimizer
Mittels Optimierern möchte man verhindern, dass der Benutzer bzw. die Programme entscheiden müssen, welche Zugriffspfade für den Zugriff auf die Daten verwendet werden sollen.
Damit erhöht man die Unabhängigkeit der Programme vom internen Modell (physische Datenunabhängigkeit). So soll z.B. beim Suchen der Angestellten in Zürich das Datenbanksystem
selbständig überprüfen, ob ein geeigneter Zugriffsweg für das Attribut Arbeitsort besteht. Bei
Bedarf können ohne Änderungen in den Programmen neue Zugriffspfade erzeugt, bzw. bestehende Zugriffspfade gelöscht werden. Damit hat man ein geeignetes Mittel, um die Performance des Datenbanksystems zu steuern.
Bei komplexeren Anfragen ist es meist schwierig zu entscheiden, welches die optimale Kombination von Zugriffspfaden ist. Sollen z.B. alle weiblichen Angestellten in Zürich gesucht werden,
kann nicht mehr a priori gesagt werden, welcher Zugriffsweg zur Bestimmung des ersten Zugriffspfades Vorrang hat. Sind z.B. nur 2% der Angestellten in Zürich, aber insgesamt 60% der Angestellten weiblich, dann ist es sicher besser den Ort zur ersten Selektion zu verwenden. Damit
zeigt sich bereits, dass zur Wahl der besten Zugriffsstrategie statistische Informationen benötigt
werden. Für die Realisierung eines effizienten Optimizers (Optimierer) gilt es demnach, den Aufwand für die Gewinnung der statistischen Informationen dem hierdurch gewonnenen Minderaufwand beim Suchen der eigentlichen Daten gegenüberzustellen.
Fehlentscheide durch den Optimizer können drastische Auswirkungen auf das Laufzeitverhalten
der Programme haben (Faktor 1000 und mehr). Daher bieten Sprachen gängiger Datenbanksysteme meist ergänzende Möglichkeiten, den Optimizer bei der Wahl des Zugriffspfades
zu steuern.
Bekannte Schwächen von Optimizern werden vom Konkurrenten häufig für den Vergleich unterschiedlicher Datenbanksysteme verwendet. Das eigene Datenbanksystem zeigt dann ein
unvergleichlich besseres Leistungsverhalten. Es ist daher entscheidend, dass Laufzeitverhalten
des Datenbanksystems in der eigenen Umgebung mit den eigenen Daten zu testen.
9.5.2. Datenbanksprachen
Datenbanksprachen müssen eine Reihe unterschiedlichster Bedürfnisse erfüllen. Je nach Benutzergruppe werden differenzierte Anforderungen gestellt:
 Anwendungsprogrammierer: Zum Erstellen von Programmen sind primär Manipulationssprachen (Englisch: Data Manipulation Language, DML) erwünscht, die es erlauben, die Verarbeitung der Daten zielgerichtet zu definieren, und eine effiziente
Verarbeitung durch die Programme gewährleisten.
 Datenbankadministrator (DBA): Der Datenbankadministrator möchte die Struktur
der Daten (auf allen Ebenen) möglichst realitätsnahe festhalten, hierfür nutzt er die
Datendefinitionssprache (Englisch: Data Definition Language, DDL). Zusätzlich muss
er die Konsistenzregeln zum Datenmodell festhalten können.
 Endbenutzer: Der Endbenutzer möchte seine Operationen auf den Daten möglichst
einfach gestalten können. Die Ausführungseffizienz ist für ihn in der Regel nur von
zweitrangigem Interesse.
Zusätzlich werden an eine Datenbanksprache weitere Anforderungen gestellt, welche unabhängig von der jeweiligen Benutzergruppe sind. So sollte die Sprache z.B. möglichst homogen
für alle drei Benutzergruppen sein. Sie sollte den einzelnen Benutzern die Möglichkeit bieten, mit
zunehmender Kenntnis der Sprache einen erweiterten, komplexeren Sprachumfang zu nutzen.
112
Sie muss sämtliche notwendigen Operationen zur Verarbeitung und Definition der Daten aufweisen.
Bei all diesen Anforderungen ist es schwer, eine kompakte und dennoch allen Anforderungen
gerechtwerdende Sprache zu definieren. Hierfür wurde eine Reihe von unterschiedlichen Ansätzen zur Definition einer derartigen Sprache entwickelt:
 Tupelorientierte gegenüber mengenorientierten Sprachen: Mengenorientierte Sprachen (auch als relationale Sprachen bezeichnet) verwenden als Operanden immer
Mengen von Datensätzen, d.h. Entitätsmengen. Auch die Resultate dieser Operationen sind wieder Entitätsmengen. Diese Sprachen werden häufig auch als Sprachen der 4. Generation bezeichnet. Ein typisches Beispiel hierfür ist SQL mit dem
mengenorientierten SELECT-Befehl.
Tupelorientierte Sprachen (Sprachen der 3. Generation) verwenden in ihren Operationen hingegen immer einzelne Datensätze. So finden sich darin typischerweise
Anweisungen, welche das Suchen von einzelnen Datensätzen erlauben (z.B. Seek
oder Find), die das sequentielle Verarbeiten einer Folge von Datensätzen ermöglichen (z.B. Next oder Skip).
 Eingebettete gegenüber selbständigen Sprachen: Selbständige Sprachen verfügen
über sämtliche Operationen, die zum Erstellen vollständiger Anwendungen notwendig sind. Eingebettete Sprachen bieten hingegen nur jene Operationen an, die zur
Anwendung der Datenbank unmittelbar notwendig sind. Die Programme werden
dann in einer anderen Gast-Sprache (English: Host-Sprache, z.B. COBOL) erstellt, die
DML-Befehle aber in der Datenbanksprache (z.B. mittels SQL) definiert. Bei
eingebetteten Sprachen ist häufig zwischen Gast- und Datenbanksprache ein
konzeptioneller Bruch festzustellen, viele erwünschte Eigenschaften gehen dabei
verloren. Eine moderne Datenbank-Sprache erhält dabei unter Umständen das
Korsett einer 'veralteten' Gast-Sprache.
Für relationale Systeme wurden durch E.F. Codd [Codd 72] die grundlegenden relationalen
Operationen definiert. Für diese Operationen wurde gezeigt, dass sämtliche denkbaren und erwünschten Abfragen ausgeführt werden können. Datenbanksprachen, mit denen alle relationalen Operationen ebenfalls definiert werden können, werden daher als relational vollständig bezeichnet. So ist z.B. die Datenbanksprache SQL relational vollständig.
Die Definition der relationalen Operationen im relationalen System lehnt sich an der Relationenalgebra an und ist damit stark mathematisch geprägt. Auf eine detaillierte Ausführung wird an
dieser Stelle daher verzichtet.
Dagegen soll hier eine kurze Einführung in die Datenbanksprache SQL (Structured Query Language, zu Deutsch: Strukturierte Abfrage-Sprache) gegeben werden, da diese in der Praxis eine
grosse Bedeutung gewonnen hat. Für vertiefte Ausführungen sei auf [Date 97] verwiesen. SQL
enthält Befehle zur Datendefinition, zur Datenmanipulation und eine Reihe weiterer notwendiger Befehle. Im Folgenden werden typische Befehle aufgezeigt (zum Teil nicht ANSI-StandardSQL).
Zur Datendefinition wird der Create-Table-Befehl eingesetzt. Im folgenden wird eine Entitätsmenge für Aufträge mit entsprechenden Attributen, Datentypen und Integritätsregeln erzeugt:
CREATE TABLE Aufträge
( Auftrags_Nr
Auftraggeber_Nr
Autrags_Datum
Bezeichnung
DECIMAL(10) PRIMARY KEY,
DECIMAL (10) NOT NULL REFERENCES Auftraggeber,
DECIMAL(8),
CHARACTER(20) )
Figur 47: Definition der Entitätsmenge Aufträge mittels SQL
Bei der Erzeugung der Entitätsmenge Aufträge wird definiert, dass die Attribute Auftrags_Nr und
Auftraggeber keine NULL-Werte enthalten dürfen, dass das Attribut Auftrags_Nr eindeutig sein
muss, da dieses als Entitätsschlüssel (Primärschlüssel) definiert wurde. Das Attribut Auftraggeber
113
wurde als Fremdschlüssel definiert und referenziert die Entitätsmenge der Auftraggeber. Damit
lässt sich die gesamte Datenstruktur festhalten. Müssen zusätzlich Konsistenzbedingungen zum
Datenmodell sichergestellt werden, lassen sich diese ebenfalls in SQL festhalten, siehe ‘8.1. Datenkonsistenz im konzeptionellen Modell’ auf Seite 83. Auch für den Datenschutz stellt SQL Befehle zur Definition der Zugriffsrechte zur Verfügung, siehe ‘8.2. Datenschutz im konzeptionellen
Modell’ auf Seite 84.
Zur Manipulation von Daten werden vier Grundbefehle verwendet: INSERT (Einfügen), DELETE
(Löschen), UPDATE (Manipulation) und SELECT (Auswahl). Alle vier Befehle sind grundsätzlich
mengenorientiert. Die Syntax ist ebenfalls sehr ähnlich. An dieser Stelle soll nur ein Beispiel für
den SELECT-Befehl gegeben werden:
SELECT Auftrags_Nr, Auftraggeber_Nr, Auftrags_Datum
FROM Aufträge
WHERE Auftrags_Nr > 1000
Figur 48: Bilden einer Entitätsmenge mit Auftragsnummern grösser als 1'000
Direkt hinter dem SELECT-Befehl werden die Attribute aufgezählt, welche in der durch den Befehl gebildeten Entitätsmenge enthalten sein sollen. Die Resultatemenge enthält damit die drei
Attribute Auftrags_Nr, Auftraggeber_Nr und Auftrags_Datum. Hinter dem FROM-Schlüsselwort
wird die Entitätsmenge angegeben, aus welcher die Entitäten selektiert werden sollen, in unserem Fall aus der Entitätsmenge Aufträge. Im letzten Teil des Befehls, im WHERE-Teil, wird die Bedingung formuliert, mittels welcher die Datensätze aus der Ursprungsentitätsmenge ausgewählt
werden.
Da die SQL-Befehle in Programmen aber oft in eine Gast-Sprache eingebettet werden, ist eine
mengenorientierte Verarbeitung nicht immer möglich. Um die satzweise Verarbeitung der Daten zu ermöglichen, wird daher ein Cursor eingeführt, mittels welchem Satz für Satz dem Programm zugänglich gemacht wird. Siehe auch ‘9.4.4. Cursor-Verwalter ’ auf Seite 110.
114
9.6. Checkfragen
1.
Hash ist...





2.
den Vorgang, eine nicht mehr lesbare Datenbank wieder herzustellen.
die Rücksetzung fehlerhafter Transaktionen.
den Vorgang, eine inkonsistente Datenbank wieder in einen konsistenten Zustand zu überführen.
die Wiederholung abgebrochener Transaktionen.
die Auflösung von Deadlocks.
A)
B)
C)
D)
E)
Physische Speicherung von Benutzerdaten
Element der konzeptionellen Modellierung
Redundante Information
Teil des Loggings
Hilfsstruktur um auf Daten zuzugreifen
A)
B)
C)
D)
E)
Je kleiner der Sperrbereich umso weniger parallele Verarbeitung
Je kleiner der Sperrbereich umso höher der Verwaltungsaufwand
Je kleiner der Sperrbereich umso mehr Deadlocksituationen
Je kleiner der Sperrbereich umso mehr Logging
Je kleiner der Sperrbereich umso weniger Locking
Es gibt Datenbanksysteme, in welchen kein Shared-Lock existiert, sondern nur ein ExclusiveLock für Änderungs-Operationen. In diesen Datenbanksystemen...





7.
A)
B)
C)
D)
E)
Welche Aussage trifft für den Sperrbereich beim Locking zu?





6.
bei einem Systemabsturz fehlerhafte Daten zurückzusetzen.
bei einem Systemabsturz die Logdatei wieder herzustellen.
bei einem Systemabsturz die verlorenen Daten des Puffers zu retten.
bei einem Systemabsturz den Rollforward zu gewährleisten.
Änderungen der Metadaten zu protokollieren.
Welche Beschreibung trifft den Begriff Zugriffspfad am besten?





5.
A)
B)
C)
D)
E)
Der Begriff Recovery umschreibt...





4.
eine Netzwerk-Datenbankstruktur.
eine Zugriffsorganisation, die nur Fremdschlüssel zulässt.
eine Datenbankstruktur, die nur sequentielles Lesen effizient unterstützt.
eine Zugriffsorganisation, bei der die Blockadresse direkt aus dem Schlüsselwert bestimmt wird.
eine Tabelle für die indexsequentielle Speichertechnik.
After-Images werden verwendet, um...





3.
A)
B)
C)
D)
E)
A)
B)
C)
D)
E)
ist die Datenkonsistenz immer sichergestellt.
spielt die Datenkonsistenz keine Rolle.
wird die Datenkonsistenz nachträglich sichergestellt.
kann die Datenkonsistenz nur durch besondere Massnahmen sichergestellt werden.
kann die Datenkonsistenz auch durch besondere Massnahmen nicht garantiert werden.
Welche Aussage trifft für Transaktion am besten zu? Eine Transaktion...





A)
B)
C)
D)
E)
kann zurückgesetzt werden.
wird protokolliert.
ist eine atomare Operation auf einer konsistenten Datenbasis.
kann vorübergehend zu inkonsistenten Datenbeständen führen.
sollte bei jeder Datenmanipulation gemacht werden.
115
Welche Begriffe lassen sich einander zuordnen?
A) Checkpoint
B) Rollback
C) Generationsprinzip
D) Reaktionsregel
E) Sperrprotokoll
1.
Konsistenzbedingung
 A)
2.

D)

E)

B)

C)

D)

E)

B)

C)

D)

E)
Synchronisation paralleler Transaktionen
 A)
5.
C)
Recovery
 A)
4.

Log-Unterteilung
 A)
3.
B)


B)

C)

D)

E)

B)

C)

D)

E)

E)
Archivkopie
 A)
Welche Begriffe, Aussagen lassen sich einander zuordnen?
A) Pessimistisches Sperrverfahren
B) Optimistisches Sperrverfahren
C) Zeitstempelverfahren
D) Recovery
E) Logging
6.
Deadlocksituationen treten auf beim...
 A)
7.

C)

D)

B)

C)

D)

E)

D)

E)

D)

E)

D)

E)
Die Kontrolle erfolgt dezentral im...
 A)
9.
B)
Eignet sich auch für Datensysteme mit vielen gleichzeitig laufenden, konkurrenzierenden
Transaktionen.
 A)
8.


B)

C)
Legt die Informationen beim Datensatz ab:
 A)

B)

C)
10. Verwaltet die Informationen zentral:
 A)

B)

C)
A) Checkpoints
B) After Image
C) Before Image
D) Protokolldatei
E) Transaktion
11. Damit werden redundante Informationen über Änderungen gezielt gesammelt.
 A)

B)

C)

D)

E)
D)

E)
12. Dient der Minimierung des Recoveryaufwands.
 A)

B)

C)

116
13. Fasst die Datenbankoperationen in logische Einheiten zusammen.
 A)

B)

C)

D)

E)

E)
14. Beeinflusst die Verarbeitung des Systempufferverwalters.
 A)

B)

C)

D)
15. Steuert die Vergabe und Freigabe der Sperren im pessimistischen Verfahren.
 A)

B)

C)

D)

E)
A) Entitätsmengenverwaltung
B) Entitätenverwaltung
C) Record- und Zugriffspfadverwaltung
D) Systempufferverwaltung
E) Externspeicherverwaltung
16. Überführt mengenorientierte Anforderungen relationaler Datenbanksysteme in satzorientierte Operationen.
 A)

B)

C)

D)

E)
17. Benötigt einen Optimizer, um die Datenbankzugriffe zu verbessern.
 A)

B)

C)

D)

E)

D)

E)

D)

E)

D)

E)
18. Wird auch Satz-Verwalter genannt.
 A)

B)

C)
19. Verwaltet den Puffer im Speicher.
 A)

B)

C)
20. Fügt neue Datensätze in den B-Baum ein.
 A)

B)

C)
1.
Direktlesen ist bei Hash-Organisation sehr effizient, weil Kollisionen beim Einfügen bei der
Hash-Organisation durch Überlaufbereiche aufgelöst werden können.
 A)
2.
B) +/+

C) +/-

D) -/+

E) -/-
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
Um eine Datenbank bei einem Systemabsturz wieder in einen konsistenten Zustand zu überführen, genügt es nicht, nur After-Images auf der Archivprotokolldatei zu verzeichnen, weil
die Archivprotokolldatei bei einem Systemabsturz ev. auch nicht alle abgeschlossenen
Transaktionen verzeichnet hat.
 A)
4.

Für die Zugriffspfade sind baumstrukturierte Organisationsformen von grosser Bedeutung,
weil baumstrukturierte Organisationsformen für alle möglichen Datenbankoperationen optimal sind.
 A)
3.
+weil+
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
Synchronisationsverfahren sollten nicht durch den Anwendungsprogrammierer selbst programmiert werden, weil die Programmierung von Synchronisationsverfahren auf der Ebene
der Anwendungsprogramme aufwendig und ineffizient ist.
 A)
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
5.
Für mengenorientierte Befehle sollte das DBMS einen Optimizer (optimiert Benutzerabfragen) besitzen, weil der Benutzer bei mengenorientierten Befehlen nicht angibt, auf welche
Art und Weise die Befehle ausgeführt werden sollen.
 A)
6.
117
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
Transaktionen müssen vollständig abgearbeitet werden, weil Konsistenzbedingungen zu Datenverlust führen.
 A)
+weil+

B) +/+

C) +/-

D) -/+

E) -/-
1.
Ein Data Dictionary-System ist...
+




2.




 
 
Deadlocksituationen treten nur beim pessimistischen Synchronisationsverfahren auf.
Der Deadlock lässt sich nur durch Zurücksetzen (Rollback) aller beteiligten Transaktionen wieder auflösen.
Bei Systemen ohne Shared-Lock aber mit Exclusive-Lock können keine Deadlocksituationen auftreten.
Bei einem Deadlock haben zwei Transaktionen Exclusive-Locks auf mindestens je zwei Datenobjekte
beantragt.
Folgende Aussagen treffen für das Zeitstempelverfahren zu:
+






 
5.
Eignet sich vor allem bei stark dynamischen Datenbeständen.
Garantiert, dass beim Lesen der Datensatz mit einem einzigen Datenbankzugriff gelesen wird.
Die Berechnung der Speicheradresse erfolgt direkt aus dem Primärschlüsselwert.
Das Divisionsrestverfahren wird für Hashing häufig verwendet.
Folgende Aussagen treffen für den Deadlock zu:
+  
 
4.
selbst ein Datenverwaltungssystem.
ein Führungsmittel.
wegen der Netzwerkstruktur der Metaobjekte nur als CODASYL-Datenbank implementierbar.
ein Mittel für Revision und Datenschutz.
Folgende Aussagen treffen für die gestreute Organisation (Hash) zu:
+




3.




Jedes Objekt erhält eine Lese- und eine Schreibmarke.
Die Transaktion erhält eine Transaktionsmarke mit der Startzeit.
Die Transaktion darf nur Daten lesen, deren Lesemarke einen späteren Zeitpunkt enthält als die
Transaktionsmarke.
Das Verfahren eignet sich für verteilte Datenbanken.
Folgende Aussagen treffen für den Sperrmodus Shared-Lock zu:
+








Er erlaubt anderen Transaktionen nur das Lesen.
Er kann unter gewissen Umständen in einen Exclusiv-Lock umgewandelt werden.
Wird beim strikt zweiphasigen Sperren erst am Ende der Transaktion aufgelöst.
Sperrt immer nur physische Objekte.
118
9.7.1. Zugriffspfade
Unten finden Sie die Daten für die nachfolgenden drei Aufgaben:
Kunden
Daten- Id.-Nr
Name
satz-Nr
1
2 Meier
2
23 Müller
3
166 Sieber
4
64 Mori
5
132 Müller
6
101 Keller
7
37 Wurster
Ort
Zürich
Russikon
Waldkirch
Greifensee
Winterthur
Zürich
Zürich
Tabellen 25: Übungsdaten
9.7.1.1. 1. Aufgabe: Invertierte Liste
Erstellen Sie eine invertierte Liste, sortiert nach Namen für die obigen Beispieldaten. Was passiert,
falls Sie nachträglich den Datensatz ‘42; Kübler; Thalwil’ einfügen müssen?
Index
Anz.
Zeiger
Zeigerlisten mit
Satznr.
Figur 49: Index und Zeigerlisten für die invertierte Liste
119
9.7.1.2. 2. Aufgabe: HASH
Es wird zur Berechnung der Adresse das Divisionsrestverfahren auf die Id-Nr (die Datensatznummer wird hier nicht verwendet) angewandt, der Divisionsrest ergibt direkt die Seitenadresse.
Zur Division wird die Zahl 7 verwendet. Pro Segment (Seiten) können maximal 2 Datensätze gespeichert werden. Beim Überlauf der Seite wird die Seite mit den zusätzlichen Daten via Adresszeiger (Pointer, d.h. Seitenadresse) referenziert (siehe unten).
Segmentadresse
Daten
Adresszeiger
Segmentadresse
0
7
1
8
2 2; Meier; Zürich
9
3
Überlaufbereich
Adresszeiger
10
4
5
6
Tabelle 26: Segmente für Hashing
9.7.1.3. 3. Aufgabe: B-Baum
Die Daten sollen in der oben gezeigten Reihenfolge (siehe ‘9.7.1. Zugriffspfade’ auf Seite 118), in
einen B-Baum eingefügt werden. Dabei soll jeder Knoten zwei Einträge inkl. Daten aufweisen.
Der Baum wird nach der Id.-Nr sortiert.
120
Entwickeln Sie ein konzeptionelles Datenmodell (Entitätsmengen, sowie deren Attribute) für ein
Data Dictionary, welches geeignet ist, die Informationen der konzeptionellen Ebene aufzunehmen. Entitätsmengen bzw. Teil des DDs (Data Dictionary) sind zum Beispiel:










Entitätsmengen
Attribute
Views
Entitäts-, Sortier-, Fremdschlüssel
Datentypen (Domänen)
Programme
Zugriffsrechte
Applikationen
Konsistenzbedingungen
etc.
Übertragen Sie das konkrete Beispiel von unten in Ihre Metadatenbank und überprüfen Sie dabei die Vollständigkeit ihres Datenmodells:
Beschreibung der Applikation Auftrag:
In der Applikation 'Auftragsabwicklung' werden drei Relationen verwendet, dies sind die 'Kunden', die
'Aufträge' und 'Artikel'. Die Datenstruktur sieht wie folgt aus (Fremdschlüssel beachten!):
Kunden
Kund_Id
Name
Strasse
PLZ
Ort
N8
A40
A40
N5
A40
Artikel
Art_Id
Bez
Preis
N8
A40
N11.4
Aufträge
Kund_Id
Art_Id
Menge
Datum
Preis
N8
N8
N8
D
N11.4
Für die Relation 'Kunden' ist eine View 'Kunden', für die Relation 'Artikel' eine View 'Artikel' definiert, die
sämtliche Attribute umfasst. Des weiteren wurde die View 'Auftrag' definiert, die folgende Attribute enthält.
Aufträge.Kund_Id
Kunden.Name
Aufträge.Art_Id
Artikel.Bezeichnung
Artikel.Preis
Aufträge.Menge
Aufträge.Datum
Aufträge.Preis
Es wurde eine Konsistenzbedingung (Aufträge.Preis = Artikel.Preis * Aufträge.Menge) definiert, die sicherstellen soll, dass der Preis (redundante Information) in der Relation 'Aufträge' immer aktuell ist.
Der Benutzer 'MARE' hat lediglich Zugriff auf die View 'Kunden', der Benutzer 'BRUNNER' hat Zugriff auf alle
drei Views.
Für die Applikation 'Auftragsabwicklung' wurden drei Programme entwickelt. Das Programm 'Kun_Mut'
verwendet die View 'Kunden', das Programm 'Art_Mut' die View 'Artikel' und das Programm 'Auftr_Mut' alle drei Views.
121
9.7.3. Deadlock im pessimistischen Verfahren
Die folgende Liste zeigt den hypothetischen Ablaufplan (Folge von Anweisungen) von drei
Transaktionen. Dabei bewirkt die Anweisung 'FETCH a' eine Lesesperre für das Datenelement a,
die Anweisung 'UPDATE a' eine Schreibsperre für das Datenelement a. Kann der Ablaufplan so
durchgeführt werden oder kommt es zu einem Deadlock?
Transaktionen:
Transaktion 1
Transaktion 2
Transaktion 3
Fet1:
Fet2:
Fet3:
Ope1:
Fet4:
Fet5:
Ope2:
Upd2:
Ope3:
Upd3:
Fet6:
Ope4:
Fet7:
Ope5:
Fet8:
Ope6:
Upd1:
FETCH a INTO var1
FETCH b INTO var2
FETCH c INTO var3
var4 :=
var1 + var2 + var3
UPDATE a FROM var4
FETCH a INTO var5
FETCH b INTO var6
var5 := var5 * var6
UPDATE a FROM var5
var6 := var6 * 1.1
UPDATE b FROM var6
FETCH e INTO var7
DISPLAY var7
FETCH f INTO var8
DISPLAY var8
FETCH a INTO var9
DISPLAY var9
Tabelle 27: Drei Transaktionen
Ablaufplan
Fet1
Fet4
Fet6
Fet2
Ope4
Fet5
Ope2
Fet7
Ope5
Fet3
Ope1
Fet8
Ope6
Upe1
Upd2
Ope3
Upd3
Tabelle 28: Ablaufplan dreier Transaktionen
122
9.7.4. Locking im pessimistischen Verfahren
Unten ist der Aufbau von drei Transaktionen gezeigt. Die Transaktionen sollen in einem DBMS mit
pessimistischem Sperrverfahren (Locking, strikt zweiphasig) vollständig abgearbeitet werden. Die
Anweisung 'FETCH a' bewirkt dabei eine Lesesperre für das Datenelement a, die Anweisung
'UPDATE a' eine Schreibsperre für das Datenelement a (wird erst zugelassen, wenn kein einziger
Eintrag für eine Lesesperre für das Datenelement a vorhanden ist). Jede der drei Transaktionen
darf jeweils eine einzelne Operation (0pe1, Ope2, ...) (Fetch, Update oder Berechnung) durchführen, danach wird die Kontrolle an die nächste Transaktion abgegeben (Transaktion 1 »
Transaktion 2 » Transaktion 3 » Transaktion 1 » Transaktion 2 usw.).
Transaktion 1
Transaktion 2
Transaktion 3
Ope1:
Ope2:
Ope3:
Ope1:
Ope2:
Ope3:
Ope4:
Ope5:
Ope6:
Ope1:
Ope2:
Ope3:
Ope4:
Ope5:
Ope6:
Fetch a
var1 := a * 2
Update a FROM var1
Fetch a
Fetch b
var3 := a - 1
var4 := b - 1
Update a FROM var3
Update b FROM var4
Fetch b
Fetch a
var5 := a - 2
Update a FROM var5
var5 := b- 2
Update b FROM var5
Tabelle 29: Definition der Operationen der Transaktionen
Kann eine Transaktion keine Operation ausführen, weil sie auf ein Datenelement wartet, so
übergibt sie die Kontrolle direkt an die nächst folgende Transaktion. Tritt ein Deadlock auf, erkennt dies das DBMS sofort und setzt diejenige Transaktion, die gerade aktiv ist, noch in der selben Anweisung zurück (Rollback) und übergibt anschliessend die Kontrolle an die nächstfolgende Transaktion.
Das Programm ist derart gestaltet, dass nach einem Deadlock und anschliessendem Rollback
erneut versucht wird, die Transaktion von vorne auszuführen. Erst nach drei erfolglosen Versuchen, die gesamte Transaktion auszuführen (beim dritten Rollback) wird die betroffene Transaktion durch das Anwendungsprogramm endgültig abgebrochen und eine Fehlermeldung
ausgegeben.
Unten sehen Sie, wie die ersten Schritte ausgeführt werden. Wie sieht der gesamte Ablaufplan
aus, wenn alle drei Transaktionen vollständig abgearbeitet werden? Welches sind die Werte von
a und b nach Ablauf aller Transaktionen (Initialwerte a=1; b=2)?
Transaktion 1
Transaktion 2
Transaktion 3
Ope1: BOT, Shared-Lock: a
(ok)
Fetch a (Wert von a ist 1)
Ope1: BOT, Shared-Lock: a
(ok)
Fetch a (Wert von a ist 1)
Ope1: BOT, Shared-Lock: b
(ok)
Fetch b (Wert von b ist 2)
Ope2: var1 := a * 2 (Wert von
a
ist 2)
123
124
Tabelle 30: Ablaufplan der Operationen der Transaktionen
9.7.5. Ablaufplan
Wir definieren drei Transaktionen mit folgenden Operationen:
TA1: Addiere 1 zu a.
TA2: Verdopple den Wert von a.
TA3: Zeige den Wert von a an und setzte den Wert von a anschliessend auf 1.
Teilaufgaben:
a: Nehmen wir an, die Transaktionen werden in einer belieben Reihenfolge gestartet.
Wie viele mögliche korrekte Resultate gibt es, falls a zu Beginn mit 0 initialisiert wird?
(6)
b: Die Tabelle unten zeigt die interne Struktur der Transaktionen:
Transaktionen:
Transaktion TA1
Transaktion TA2
Transaktion TA3
Fet1:
Fet2:
Fet3:
Upd1:
FETCH a INTO t1
t1 := t1 + 1
UPDATE a FROM t1
Upd2:
FETCH a INTO t2
t2 := t2 * 2
UPDATE a FROM t2
Upd3:
FETCH a INTO t3
DISPLAY t3
UPDATE a FROM 1
Tabelle 31: Operationen der Transaktionen
Wie viele Ablaufpläne sind möglich, falls die Transaktionen ohne jegliches Locking
abgearbeitet werden? (90 Stück, wieso?)
c: Wird a wieder mit 0 initialisiert, gibt es dann einen Ablaufplan (ohne Locking!), der
ein korrektes Resultat produziert, der aber nicht konsistenzerhaltend ist? (ja, wieso?)
d: Gibt es einen konsistenzerhaltenden Ablaufplan, der mit Locking nicht erlaubt ist?
(ja, welchen?)
125
9.7.6. Transaktionslogik und Programme
Betrachten Sie die beiden folgenden Programm-Beispiele und überlegen Sie sich, ob die Lösung
gut ist oder ob diese besser programmiert werden könnte.
* Dieses Programm rechnet jede Buchungen in Fremdwährung des gestrigen
* Tages in Landeswährung um. Dieses Programm wird am Tagesende ausgeführt.
DECLARE tageskurs
BEGIN TRANSACTION
READ ALL Buchung FOR Buchung.datum = YESTERDAY
IF Buchung.währ_bez <> 'CHF' THEN
FETCH tageskurs FROM tag_kurs TABLE Kurse
WHERE Kurse.währ_bez = Buchung.währ_bez AND
Kurse.datum = Buchung.datum;
UPDATE haben_chf TABLE Buchung WITH haben_fremdwährung * tageskurs;
UPDATE soll_chf TABLE Buchung WITH soll_fremdwährung * tageskurs;
ENDIF;
ENDREAD;
END TRANSACTION;
Figur 50: Programm Umrechnung
* Dieses Programm liest die Währung, zwei Konti mit identischer Währung und
* einen Betrag ein und überträgt den Betrag vom ersten zum zweiten Konto.
DECLARE währung,konto_1,konto_2,bu_betrag
BEGIN TRANSACTION
INPUT währung
READ FIRST Währung FOR Währung.währ_bez = währung
IF Währung.währ_bez = währung
INPUT bu_betrag,konto_1;
READ FIRST Konto FOR Konto.konto_nr = konto_1;
IF Konto.konto_nr <> konto_1 OR
Konto.betrag - bu_betrag < Konto.min_betrag
Konto.währ_bez <> währung THEN
ERROR 'Buchungen nicht ausgeführt';
ROLLBACK;
ELSE
UPDATE betrag TABLE Konto WITH Konto.betrag
ENDIF;
INPUT konto_2;
Konto.betrag + bu_betrag < Konto.min_betrag
ROLLBACK;
ELSE
ENDIF;
ELSE
ERROR 'Währung nicht gefunden';
ROLLBACK;
ENDIF;
END TRANSACTION;
OR
- bu_betrag;
OR
+ bu_betrag;
Figur 51: Programm Kontoübertrag mit Fremdwährung
126
An dieser Stelle sind nun alle Kenntnisse vorhanden, um das interne Datenmodell zu erstellen. In
aller Regel wird dabei, ausgehend vom konzeptionellen Modell, das interne Modell für ein bestimmtes Datenbanksystem abgeleitet. Zielsetzung ist hierbei, dass interne Modell möglichst wenig zu ändern und so nahe wie möglich am konzeptionellen Modell zu bleiben. Bestehen keine
Performance-Probleme, so sollte das interne Modell, wenn möglich, 1:1 übernommen werden.
Beim Herleiten des internen Modells müssen folgende mögliche bzw. notwendige Aktivitäten
und. Änderungen untersucht werden:
 Herleitung des internen Datenmodells für vorgegebenes Datenbanksystem: Es muss
für das festgelegte Datenbanksystem untersucht werden, ob das konzeptionelle
Modell 1:1 in das interne Modell umgesetzt werden kann. Allenfalls muss das interne
Modell den Möglichkeiten des Datenbanksystems angepasst werden.
 Bestimmen der Zugriffspfade: Damit ein Datenbanksystem mit grösseren Datenmengen sinnvolle Antwortzeiten haben kann, müssen für die häufigsten Zugriffe
zwingend Zugriffspfade erstellt werden. Allerdings kann die Zahl der Zugriffspfade
nicht beliebig erhöht werden. Jeder zusätzliche Zugriffspfad bedeutet einen erhöhten Verwaltungsaufwand und reduziert damit die Gesamt-Performance.
 Physische Organisation: Festlegen der physischen Organisation der Daten, z.B. Komprimierung.
 Denormalisierung zur Performance-Verbesserung: Bestehen Performance-Probleme,
so muss das interne Modell entsprechend überarbeitet werden. Hierbei werden bewusst Normalisierungsregeln verletzt, das Datenmodell wird wieder denormalisiert.
Damit ist auch schon gesagt, dass zwar das konzeptionelle Modell voll normalisiert
sein muss, das interne Modell aber durchaus Normalisierungsregeln verletzen darf. In
der Praxis ist die Aussage ‘Unsere Datenbank ist voll normalisiert’ nicht nur meist
falsch, sondern die Aussage muss zudem auf deren Zweckmässigkeit überprüft werden.
 Berücksichtigung von Betriebssystem und Hardware: In einem letzten Schritt kann
das interne Modell den Bedürfnissen und Gegebenheiten des Betriebssystems und
der Hardware angepasst werden. Details hierzu können hier nicht gegeben werden,
sondern müssen im konkreten Fall betrachtet werden.
Dabei müssen z.B. folgende widersprüchlichen Ziele bei der Herleitung des internen Modells gegeneinander abgewogen werden:
 Effiziente Ausführungsgeschwindigkeit
 Minimaler Speicherbedarf der Daten und Hilfsstrukturen
 Möglichst wenig Redundanzen
10.1. Herleitung des internen Datenmodells für ein vorgegebenes Datenbanksystem
In diesem Kapitel wird beschrieben, wie ausgehend vom konzeptionellen Modell, das interne
Modell für ein gegebenes Datenbanksystem hergeleitet wird. Dabei sollen ausschliesslich relationale Datenbanksysteme betrachtet werden. Für die Darstellung des konzeptionellen Modells
wurde das erweiterte Relationenmodell und das Entity-Relationship-Modell eingeführt. Für beide
müssen die Regeln zur Erstellung des internen Modells gegeben werden. Zum Glück sind dafür
bereits sämtliche Grundlagen geschaffen.
Beim erweiterten Relationenmodell ist die Umsetzung denkbar einfach; alle Entitätsmengen
können direkt in Relationen des Datenbanksystems umgewandelt werden. Daher ist die Modellierung mittels erweitertem Relationenmodell in der Praxis auch so beliebt. Im Entity-RelationshipModell ist die Umsetzung etwas komplizierter.
127
 Sämtliche Entitätsmengen werden unverändert als Relationen verwendet.
 Beziehungsmengen, welche mehr als eine c-, m-, oder mc-Assoziation (Rolle) aufweisen, werden ebenfalls als eigenständige Relationen im internen Modell benötigt.
 Die verbleibenden Beziehungsmengen weisen höchstens eine c-, m-, oder mc-Assoziation auf und haben genau eine oder mehrere 1-Assoziationen. Diese Beziehungsmengen werden im internen Modell nicht benötigt. Die Beziehungsmenge
kann in eine der Entitätsmengen integriert werden, welche die 1-Assoziation aufweist. Dies daher, weil zwischen der Entitätsmenge und der Beziehungsmenge eigentlich eine 1:1-Beziehung besteht. D.h. für jeden Datensatz in der Beziehungsmenge existiert genau ein Datensatz in der Entitätsmenge. Damit liegt es nahe, aus
den jeweils zusammengehörenden Datensätzen einen einzigen Datensatz zu bilden,
d.h. eine einzelne Relation zu erstellen.
10.2. Bestimmen der Zugriffspfade
Ideal wäre sicher, wenn für jeden zukünftig notwendigen Zugriff auf die Daten ein Zugriffspfad
zur Verfügung stünde. Allerdings wäre der Verwaltungsaufwand beim Einfügen, Löschen oder
Ändern von Daten dann gewaltig, ganz abgesehen von der riesigen Menge redundanter Daten. Es liegt damit in der Natur der Sache, dass man sich auf die wichtigsten, am häufigsten
verwendeten Zugriffspfade beschränkt. Um die Zahl und Art der Zugriffspfade festzulegen, kann
wie folgt vorgegangen werden (unter Vernachlässigung der zusätzlichen Datenmengen):
1. Auffinden der potentiell geeigneten Zugriffspfade und Bestimmen der Verwendungshäufigkeit eines ausgewählten, hypothetischen Zugriffspfades (z.B. pro Tag).
2. Berechnen, welches der Zeitgewinn (CPU-Zeit) pro Tag ist, falls dieser Zugriffspfad
existieren würde.
3. Berechnen des Zeitaufwandes (in CPU-Zeit) zur Verwaltung des ausgewählten Zugriffspfades. Dafür muss bekannt sein, wie häufig Datensätze der entsprechenden
Relation eingefügt, gelöscht oder geändert werden.
Ist der Zeitgewinn pro Tag grösser als der Zeitaufwand, dann lohnt sich die Realisierung des Zugriffspfades. Zur Berechnung des Zeitaufwandes bzw. -gewinns müssen somit eine Reihe statistischer Daten erhoben werden. Eine besondere Schwierigkeit stellt dabei der Umstand dar, dass
der Datenbestand keine statische Grösse ist, sondern sich im Laufe der Zeit ändert.
10.2.1. Mögliche Zugriffspfade bestimmen
Die am meisten verwendeten Zugriffspfade ergeben sich direkt aus dem Datenmodell. Häufig
werden natürlich Entitäts- und Fremdschlüssel als Zugriffspfad verwendet. Dadurch ist der
schnelle Zugriff von über- auf untergeordnete Daten und umgekehrt möglich. Es liegt damit nahe, für jeden Entitäts- und Fremdschlüssel einen Zugriffspfad zur Verfügung zu stellen. Häufig ergänzt man in der Praxis diese ermittelten Zugriffspfade durch zusätzliche Zugriffspfade, für welche man intuitiv häufig Zugriffe erwartet. Allerdings ist es bei diesem Vorgehen möglich, dass
sehr viel Rechenzeit verschwendet wird, weil die Zugriffspfade nicht optimal sind.
Ein besseres Bild über die möglichen Zugriffspfade erhält man, wenn man sämtliche notwendigen logischen Transaktionen betrachtet, welche auf den Daten ausgeführt werden sollen. Diese logischen Transaktionen sind die aus Sicht der Anwendung notwendigen Operationen. Meist werden diese als Geschäftsprozesse bzw. als Systemfunktionen bezeichnet. So ist
z.B. das ‘Erfassen eines neuen Kunden’ ein Geschäftsprozess. Für jeden Geschäftsprozess kann
angegeben werden, welche Zugriffspfade dieser verwendet und wie häufig der Geschäftsprozess auftritt. Hat man alle Geschäftsprozesse bestimmt, festgelegt, wie häufig diese
verwendet werden und welche Zugriffspfade diese benutzen, dann ist für die gesamte Anwendung bekannt, welche Zugriffspfade, wie oft verwendet werden. Diese Informationen lassen
sich in einer Tabelle festhalten:
128
Geschäftsprozess
1.
1.1
1.2
1.3
Häufigkeit
Zugriffspfad:
Zugriffspfad
Kunden: Kunden#
Kunden: Name
(pro
Tag)
Anz. Zugriffe /
Geschäftsprozess
Kundenverwaltung
Kunden erfassen
Kunde und dessen
Verwandten löschen
Kunde suchen
2
Auftragsverwaltung
2.1 Auftrag erfassen
...
TOTAL
Anz. Zugriffe /
Tag
Anz. Zugriffe /
Geschäftsprozess
4
2
1.0
3.4
4.0
6.8
0.0
0.0
24
2.0
24.0
…
100
0.2
20.0
0.8
…
54.8
Tabelle 32: Ausschnitt aus der Geschäftsprozess-/ Zugriffspfad-Matrix
Falls in der Anwendung auch Tagesendverarbeitungen (Batch-Programme) oder ähnliches ausgeführt werden, ist es sinnvoll, diese in einer separaten Tabelle explizit auszuweisen. Häufig kann
bei Batch-Programmen eine längere Verarbeitungszeit akzeptiert werden.
10.2.2. Zugriffspfad-Effizienz bestimmen
Um den Zeitgewinn bzw. -verlust zu berechnen, müssen zunächst die Datenmengen sowie die
anfallenden Operationen je Relation bekannt sein. Diese Zahlen können wieder in einer Tabelle
oder direkt in einem leicht erweiterten Datenmodell abgelegt werden:
Mengen und Operationen auf den
Relationen
Kunden
Aufträge
Auftragspositionen
...
Anzahl Datensätze
Anzahl Datensätze /
Segment
10’000
100’000
Einfügen /
Tag
10
40
Löschen /
Tag
4
50
2
50
Tabelle 33: Ausschnitt aus der Relationen-/ Operationen-Matrix
Ausserdem müssen die Änderungsoperationen festgehalten werden, welche einen Zugriffspfad
betreffen, sowie wie viele Einträge pro Knoten im B-Baum Platz haben:
Operationen auf
Zugriffspfaden der
Relation Kunden
Änderungen /
Tag
Kunden#
Name
...
0.1
5
Einträge /
Knoten des
B-Baumes
40
10
Tabelle 34: Ausschnitt aus der Zugriffspfad-/ Operationen-Matrix
Jetzt kann die Gewinn-/Verlustrechnung ausgeführt werden (hier eine einfache Form). Es wird
hier nur die Anzahl der Zugriffe auf das externe Speichermedium als Mass für den Zeitaufwand
verwendet:
129
Aufwand (in Anzahl
pro Zugriff
Zugriffen) Zugriffspfad
Kunden: Kunden#
pro Tag
(* 54.8)
Zugriffsaufwand ohne Anzahl Datensätze / Anzahl Datensätze pro Segment / 2 =
Zugriffspfad
Zugriffsaufwand mit
Log(Einträge pro Knoten) (Anzahl Datensätze) + 1 =
Zugriffspfad
Zeitgewinn / Zugriff
500
27’400
3.5
192
495
27’208
Tabelle 35: Zeitgewinn beim Zugriff
Aufwand Zugriffspfad pro Operation
Kunden: Kunden#
Aufwand Einfügen
Aufwand Löschen
Aufwand Ändern
Aufwand TOTAL
pro Tag
5.5
5.5
8.5
22
11
0.85
33.85
Tabelle 36: Zeitverlust durch Verwaltungsaufwand
Durch die Einführung eines Zugriffspfades für die Kunden# in der Relation Kunden lassen sich
somit pro Tag ca. 27’000 Zugriffe auf das externe Speichermedium sparen (27’208 minus 33.85).
Diese berechneten Werte sind mit äusserster Vorsicht zu geniessen und müssen durch eine Vielzahl weiterer Faktoren relativiert werden:
 In der Berechnung wurde der Systempuffer nicht berücksichtigt.
 In der Berechnung wurde die eigentliche Rechenzeit (CPU-Leistung) nicht berücksichtigt.
 In der Berechnung wurde der zusätzliche Speicherbedarf nicht berücksichtigt.
Trotzdem liefern diese Werte einen wichtigen Hinweis für die Wahl der Zugriffspfade. Leider ändern sich die für die Rechnungen verwendeten Werte während des Betriebes der Anwendung,
so dass die getroffenen Annahmen revidiert werden müssen. Für ein Datenbanksystem, in welchem der Optimizer dynamisch entscheidet, welche Zugriffspfade verwendet werden sollen,
können noch während des Betriebs ohne Programmänderungen Zugriffspfade gelöscht oder
eingefügt werden. Falls die Zugriffspfade aber in den Programmen fest vorgegeben werden,
können keine dynamischen Anpassungen ohne Eingriffe in die Programme vorgenommen werden.
Ist die Gesamt-Performance der Anwendung nach der Gestaltung der Zugriffspfade nicht genügend, bleiben zwei Möglichkeiten: Entweder werden die Geschäftsprozesse gezielt überarbeitet oder das interne Datenmodell wird denormalisiert (siehe unten). Mit den obigen Berechnungen lässt sich bereits vor der Erstellung der Anwendung eine erste Aussage zur GesamtPerformance machen.
10.3. Physische Organisation
Bei der Abbildung der logischen Datensätze der Datenbank in die physischen Datensätze können eine Reihe von Massnahmen zur Performance-Verbesserung ergriffen werden, z.B. Clustering, Komprimierung, Wahl der physischen Abbildung, Prefetch-Technik, virtuelle Attribute etc.
An diese Stelle wird nicht weiter auf diese Möglichkeiten eingegangen, da diese stark vom konkreten Datenbanksystem abhängen. Einige Ansatzpunkte sind auch im Kapitel ‘9. Datenbanktechnik, Softwarekomponenten eines Datenbanksystems’ auf Seite 89 aufgezeigt.
130
10.4. Denormalisierung zur Performance-Verbesserung
Bei der Denormalisierung des internen Datenmodells werden zur Performance-Verbesserung gezielt Normalisierungsregeln gebrochen. Allerdings sollte nur dann denormalisiert werden, wenn
die Performance des Systems nicht mehr genügend ist und keine anderen Massnahmen (ev. Erhöhung der Rechnerleistung) möglich sind. Nach der Denormalisierung sind zumindest die kritischen Stellen (mit Redundanzen) im internen Datenmodell bekannt und können mit entsprechender Vorsicht behandelt werden.
Bei der Denormalisierung können die kritischen Zugriffe betrachtet werden und daraus gezielt
Änderungen am internen Datenmodell abgeleitet werden. Es ist nicht möglich, sämtliche Massnahmen abschliessend aufzuzählen. Im Folgenden sollen einige Beispiele eine Idee über mögliche Änderungen geben:
 Einführen von Redundanzen (z.B. der Kundennummer in der Relation Auftragsposition).
 Werden Datensätze einer Relation und referenzierte untergeordnete Datensätze einer anderen Relation häufig zusammen gelesen, dann können die beiden Relationen zusammengelegt werden.
 Werden häufig nur bestimmte Felder einer Relation verwendet, kann die Relation
geteilt werden, so dass die häufig verwendeten Felder kompakt in einer einzigen Relation abgelegt sind.
 Bietet das Datenbanksystem die Möglichkeit, Attribute oder Attributsgruppen mit
Mehrfacheintrag (Wiederholungsgruppen) zu bilden, ergeben sich daraus eine Reihe interessanter Möglichkeiten. Damit können z.B. m:m-Beziehungen ohne Beziehungsmenge direkt realisiert werden.
131
10.5. Checkfragen
1.
Die Datenmodellierung auf der internen Ebene setzt folgende Ziele:
+




2.




effiziente Ausführungsgeschwindigkeit
minimaler Speicherbedarf der Daten
wenig Redundanz
Vernachlässigung datenbankspezifischer Eigenschaften
Zählen Sie die Merkmale des internen, physischen Designs auf:
+








Berücksichtigt Hardwareüberlegungen
Berücksichtigt Datenmengen und Zugriffshäufigkeiten
Hier wird die Datenstruktur denormalisiert
Die Speicherstruktur und -organisation wird hier festgelegt
132
11.1. Vorteile und Nachteile verteilter Datenbanksysteme
Von einer verteilten Datenbasis bzw. verteilten Datenbanksystemen spricht man in aller Regel,
wenn mehrere, mittels Netzwerk verbundene, ansonsten aber unabhängige Datenbanksysteme
eine gemeinsame Datenbasis bilden. Jeder Netzwerkknoten verfügt dabei über ein eigenes, eigenständiges Datenbanksystem mit eigenem Rechner.
So kann ein verteiltes Datenbanksystem z.B. einen Knoten in München, einen anderen Knoten in
Zürich und einen weiteren Knoten in Wien aufweisen. Die Datensätze der Relation Kunden werden hierbei z.B. jeweils lokal im entsprechenden Knoten verwaltet. Es werden also alle Kunden
von München im Knoten von München, alle Kunden von Zürich in Zürich und alle Kunden von
Wien in Wien selbst gespeichert. Aber nur alle Daten zusammengezogen ergeben die gemeinsame, konsistente Datenbasis. Die Vorteile und Nachteile einer solchen Verteilung liegen
auf der Hand, z.B.:
 Durch die lokale Speicherung der Daten reduziert sich der Kommunikationsaufwand
zwischen den Knoten. Wären sämtliche Daten zentral gespeichert, müsste ein noch
grösserer Teil der Kommunikation über das langsame Netz erfolgen.
 Da die für die einzelnen Knoten relevanten Daten lokal gespeichert werden, können
diese Daten auch dann noch verwendet werden, wenn ein anderer Knoten ausgefallen ist.
 Werden die Daten mehrfach in unterschiedlichen Knoten gespeichert, erhöht sich
die Datensicherheit dadurch beträchtlich. Allenfalls kann sogar auf eine Sicherungskopie verzichtet werden.
 Die Integrität der Daten ist nur mit hohem Rechenaufwand zu gewährleisten. Integritätsregeln können Daten auf unterschiedlichen Knoten betreffen, was einen zusätzlichen Kommunikationsaufwand schafft.
 Durch die Verteilung der Daten entstehen neue, komplexe Anforderungen an den
Integritätsschutz.
11.2. Eigenschaften verteilter Datenbanksysteme
Durch die Verteilung der Datenbasis auf mehrere unabhängige Datenbanksysteme müssen eine Reihe neuer Fähigkeiten durch das Datenbanksystem wahrgenommen werden. Diese Fähigkeiten zu gewährleisten ist besonders dann schwierig, wenn die miteinander verbundenen Datenbanksysteme nicht vom selben Hersteller sind, sondern es sich dabei um technisch unterschiedliche Datenbanksysteme handelt. Man spricht von homogener Verteilung, wenn in
sämtlichen Knoten das selbe Datenbanksystem verwendet wird, ansonsten von heterogener
Verteilung.
Um Programme und Abfragen auch in verteilten Systemen einfach und unabhängig von der effektiven Verteilung der Daten erstellen zu können, werden eine Reihe von Eigenschaften von
verteilten Datenbanksystemen gefordert. Diese Eigenschaften sind Teil der physischen Datenunabhängigkeit:
 Ortstransparenz (Englisch: Location Transparency): Weder Benutzer noch Entwickler
sollten von der Verteilung der Daten Kenntnis nehmen oder diese gar kennen
müssen. Für jede Operation auf Daten, auch wenn diese nicht in der lokalen
Datenbasis abgelegt sind, muss das Datenbanksystem die entsprechenden Daten
automatisch und selbständig beschaffen. Dadurch können Programme unabhängig von der Verteilung der Daten erstellt werden und die Daten können auch
noch während des Betriebes neu verteilt werden.
 Fragmentierungstransparenz (Englisch: Fragmentation Transparency): Können nicht
nur Entitätsmengen verteilt werden, sondern können auch einzelne Entitätsmengen
133
in Stücke geschnitten werden, sogenannte Fragmente, spricht man von
Fragmentierung. Fragmentierungstransparenz ist gegeben, wenn weder Benutzer
noch Entwickler von der Verteilung der Fragmentierung Kenntnis haben müssen.
Von horizontaler Fragmentierung spricht man, falls eine Entitätsmenge tupelweise
zerschnitten wird. Von vertikaler Fragmentierung ist die Rede, wenn die Entitätsmenge spaltenweise zerschnitten wird. Hierbei muss zusätzlich in jedem Fragment
der Entitätsschlüssel mitgeführt werden.
 Replikationstransparenz (Englisch: Replication Transparency): Zur Verbesserung der
Performance und zur Erhöhung der Datensicherheit liegt es nahe, Kopien von Daten
in mehreren Knoten abzulegen. Diese Datenkopien werden als Replikat bezeichnet.
Replikationstransparenz fordert vom Datenbanksystem, dass diese Replikate
vollautomatisch vom Datenbanksystem verwaltet werden. So muss das Datenbanksystem z.B. eine Änderung an den Daten auch an allen übrigen Replikaten
nachführen.
Durch diese Eigenschaften wird sichergestellt, dass eine verteilte Datenbank sich Benutzern und
Entwicklern wie eine einzige, zentrale Datenbank präsentiert. Dadurch wird die Komplexität verteilter Systeme gänzlich verborgen. Das darf aber nicht darüber hinwegtäuschen, dass die
technischen Anforderungen an das Datenbanksystem enorm sind. So müssen z.B. Mehrbenutzerbetrieb, Transaktionslogik, Integrität weiterhin gewährleistet werden. Auf das Problem der
Transaktionslogik in verteilten Datenbanksystemen wurde in Kapitel ‘9.4.2.4. Transaktionslogik in
verteilten Datenbanksystemen’ auf Seite 107 eingegangen.
134
11.3. Checkfragen
1.
Folgende Aussagen zur Datenverteilung sind korrekt:
+








Replikate sind Datenkopien auf unterschiedlichen Knoten.
Änderungen an Replikaten werden bei Ortstransparenz automatisch in allen Knoten nachgeführt.
Fragmente sind Datenkopien auf unterschiedlichen Knoten.
Änderungen an Fragmenten werden bei Ortstranspartenz automatisch in allen Knoten nachgeführt.
135
Teil 4:
Fallbeispiel
137
Das Fallbeispiel behandelt die Probleme der TTW AG (Travel-The-World AG). Hierbei werden alle
wichtigen Themen der Datenorganisation und -modellierung kurz angesprochen. Die Durchführung des Fallbeispiels ist nur in der angegebenen Reihenfolge möglich, da nachfolgende Übungen auf den vorgehend aufgebauten Erkenntnissen basieren! Beachten Sie jeweils die Lösungen der einzelnen Aufgabenschritte und verwenden Sie diese als Basis zur weiteren Bearbeitung
der Aufgaben. Die Lösungen zu den einzelnen Aufgabenschritten finden Sie ab Seite 196. Der
zeitliche Aufwand zur Durchführung der Übung beträgt ca. 3½ bis 4 Stunden. Zielsetzungen zum
Fallbeispiel (Anwendung von):
 Dateiverwaltung / DBMS
 Top-Down- und Bottom-Up-Analyse
 ANSI/SPARC-Architektur
 Normalisierung
 Verbundinstrumente in Datenmodellen (Hierarchie, Rekursion, Beziehungsmenge,
Spezialisierung/Generalisierung, Aggregation, etc.)
 Zeitabhängige Daten und Varianten von Daten
 Meta-Entitätstypen, Data-Dictionary
 Integration von Teilmodellen
 Internes Schema, physische Datenorganisation
Die Travel-The-World AG ist ein kleines schweizerisches Reiseunternehmen, welches geführte
Gruppenreisen in alle Teile der Welt organisiert (ca. 45 Reise-Angebote pro Jahr, welche ca. 10
mal mit etwa 18 Reisenden pro Reise durchgeführt werden) und mit Reiseleitern, welche i.d.R.
aus dem Ferienland stammen, durchführt. Die Reisen und Prospekte werden vom Unternehmen
selbst zusammengestellt. Die gesamte Organisation (Reisezusammenstellung, Planung & Kontrolle, Rechnungswesen, ...) liegt in den Händen von einem kleinen Team von Mitarbeitern (ca. 10
Personen). Die TTW AG konnte ihre Arbeit in der Vergangenheit vor allem darum sehr effizient
durchführen, da das Arbeitsteam klein, die Kommunikation im Team und der Informationsstand
der einzelnen Mitarbeiter gut waren. In den letzten Jahren ist allerdings die Gewinnmarge der
einzelnen Reisen immer kleiner geworden, so dass sich die TTW gezwungen sah (entgegen ihrer
Geschäftsstrategie, welche die Abgrenzung zu den grossen Reiseunternehmen beabsichtigt),
das Reiseangebot und -volumen zu vergrössern. Die TTW AG hat dadurch ihren Personalbestand
vergrössern müssen (ursprünglich waren 6 Mitarbeiter angestellt) und für grössere Schwankungen mehrere temporäre Arbeitskräfte (Studenten) einsetzen müssen. Dadurch ist aber ein grosser Teil der Vorteile, welche die TTW AG gegenüber ihren grösseren Konkurrenten hatte, verloren
gegangen (Führungsprobleme, Wissenslücken, gegensätzliche Entscheide, ...).
Um diesem Missstand abzuhelfen und wieder auf die ursprüngliche Unternehmensgrösse zu gelangen (Personalbestand, ROI, ...), wurde beschlossen ein neues EDV-System anzuschaffen bzw.
entwickeln zu lassen. Bei der aktuellen Unternehmensstruktur ist ansonsten das Überleben des
Unternehmens ernsthaft gefährdet. Da die Margen durch den erhöhten Konkurrenzdruck klein
sind und bleiben, ist dies natürlich nur mit dem bereits erhöhten Kapitalumschlag möglich. Daher muss der bestehende Umsatz beibehalten werden, der Personalbestand aber deutlich verringert werden.
Zur Zeit wird in der TTW AG eine einfache Applikation (TravelSys) eingesetzt, basierend auf einem
Dateiverwaltungssystem, welches vor Jahren für die Firma entwickelt wurde und seither ohne
Änderungen läuft. Dieses System ist nur schlecht und unvollständig dokumentiert.
12.1. Ist-Analyse: Datenmodell zur Anwendung TravelSys ermitteln (Bottom-Up)
In einem ersten Schritt soll die Struktur der bestehenden Anwendung TravelSys ermittelt werden
(Datenmodell und Attributskatalog). Dieses Datenmodell ist die Grundlage für den Entscheid,
wie weiter vorgegangen werden soll.
138
12.1.1. Ermittlung des Datenmodells zur Anwendung TravelSys (55 Minuten)
Zur Ermittlung der bestehenden Struktur können das Datenmodell (unvollständig), verschiedene
Bildschirmmasken (nur ein Teil der Masken) und Recordbeschreibungen (nur von einem Teil der
Dateien) verwendet werden. Jeder der drei Teile gibt nur einen Teil der Gesamtlösung wieder,
dennoch kann aus den Angaben die gesamte Ist-Lösung rekonstruiert werden.
Erstellen Sie das grafische Datenmodell der Ist-Lösung sowie den vollständigen Attributskatalog
von TravelSys. Kennzeichnen Sie Entitäts- und Fremdschlüssel in Ihrer Lösung. In dieser ersten
Aufgabe ist die Analyse der bestehenden Lösung gefragt, nicht eine verbesserte Lösung! Fügen
Sie keine Entitätsmengen und Attribute ein, die nicht Teil der Ist-Lösung sind. Versuchen Sie in einem ersten Schritt, die Entitäts- und Fremdschlüssel der Ist-Lösung zu bestimmen und erst anschliessend die Entitätsmengen und deren Beziehungen festzulegen.
Das 'Datenmodell' ist mit unbekannten Konventionen erstellt worden. Es ist nicht gesichert, dass
sämtliche Dateien und Zusammenhänge aufgezeigt werden:
Kunden
Reisen
Rechnungen
Preise
Figur 52: Datenmodell-Ausschnitt von TravelSys mit unbekannter Notation
Recordstruktur zweier Dateien (nur von einem Teil der Dateien):
DEFINE RECORD Preis
Reise#: Numeric(10)
Datum_Start_Fenster: Date
Anzahl_Nächte: Numeric(3)
Zimmergrösse: Numeric(2)
Verpflegung: Character(4)
Preis: Numeric(10.2)
Woche_Start_Fenster: Numeric(2)
END OF RECORD Preis
DEFINE RECORD Rechnung
Rechnungs#: Numeric(10)
Rechnungsdatum: Date
Kunden#: Numeric(10)
Rechnungsbetrag: Numeric(10.2)
Rechnungscode: Character(2)
Rechnungscode_Text: Character(20)
Buchungs#[4]: Numeric(10)
Künstliche Nummer der Reise (pro Reise mehrere Preise)
Datum, ab welchem der Preis gilt
Anzahl Buchungsnächte der Reise
Zimmergrösse (z.B. Einzel-, Doppel-Zimmer)
Verpflegungsart ('VP'=Vollpension, 'HP'=Halbpension,
'ZF'=Frühstück oder 'ohne')
Preis gültig ab diesem Datum, für diese Anz. Nächte,
für diese Zimmergrösse etc.
Wochennr., ab welchem der Preis gilt
Künstliche Rechnungsnummer
Datum der Rechnungsstellung
Künstliche Kundennummer (bezahlt die Rechnung)
Rechnungs-, bzw. Teilrechnungsbetrag in Fr.
Rechnungscode (z.B. 'Of')
Rechnungscodetext (z.B. 'Offen' für Code = 'Of')
Wiederholungsgruppe mit max. 4 Ausprägungen. Mit
einer (Teil-)Rechnung können max. 4. Reisen eines
Kunden bezahlt werden (unternimmt die Reise).
END OF RECORD Rechnung
Figur 53: Rekorddefinitionen von TravelSys
Bildschirmmasken (nur ein Teil der Masken der Anwendung): Felder mit kleinen Buchstaben können nicht bearbeitet werden (reine Output-Felder), Felder mit Buchstaben in roter Farbe können
eingegeben bzw. bearbeitet werden.
n
x
tt/mm/jjjj
l
139
Numerisch
Alphanumerisch
Datum
Logisch (J/N)
Buch01
Buchung erfassen / modifizieren
Kunden-Nr:
Name:
Adress_Zeile_1:
Adress_Zeile_2:
Land, PLZ, Ort:
User-ID
nnnnnnnnnn
xxxxxxxxxxxxxxxxxxxx
Nationalität:
Rechnungs-Saldo:
xxx-nnnnnn xxxxxxxxxxxxxxxxxxxx
_
_
_
_
_
_
_
_
_
_
_
ReiseDatum
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
ReiseNummer
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
_
tt/mm/jjjj
nnnnnnnnnn
Anzahl
Nächte
nnn
nnn
nnn
nnn
nnn
nnn
nnn
nnn
nnn
nnn
nnn
Anzahl
Personen
nnn
nnn
nnn
nnn
nnn
nnn
nnn
nnn
nnn
nnn
nnn
Zimmergrösse
nn
nn
nn
nn
nn
nn
nn
nn
nn
nn
nn
Verpflegung
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
tt/mm/jjjj
xxx
nnnnnnnnnnnn.nn (offen)
Preis
(effektiv)
nnnnnnnnnn.nn
nnnnnnnnnn.nn
nnnnnnnnnn.nn
nnnnnnnnnn.nn
nnnnnnnnnn.nn
nnnnnnnnnn.nn
nnnnnnnnnn.nn
nnnnnnnnnn.nn
nnnnnnnnnn.nn
nnnnnnnnnn.nn
nnnnnnnnnn.nn
BuchungsNummer
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
F1=Auswahl F3=Ende F5=Auswahl Reisevariante (Preis) F6=Einfügen Buchung F7=Löschen Buchung
Reis01
Reisen erfassen / modifizieren
Reise-Nr:
Bezeichnung:
Dauer (Anzahl Tage):
Hotel:
Reisemittel zum Startort:
Startort:
Reisemittel vom Endeort:
Endeort:
User-ID
tt/mm/jjjj
nnnnnnnnnn
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
nnn (0 falls variable Buchungsdauer)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Durchschnittliche Einnahmen pro Kunde (Ertrag):
Durchschnittliche Ausgaben pro Kunde (Aufwand):
nnnnnnnnnn.nn
nnnnnnnnnn.nn
F1=Auswahl F3=Ende F6=Einfügen Reise F7=Löschen Reise
Figur 54: Bildschirmmasken von TravelSys
12.1.2. Normalisierung des Datenmodells (25 Minuten)
Zeigen Sie für jeden Normalisierungsschritt den vollständigen Attributskatalog aller geänderten
Entitätsmengen sowie das Datenmodell für die 3. Normalform auf. Es dürfen keine Attribute
weggelassen oder hinzugefügt werden. Zeigen Sie die Resultate (Attributskatalog für jede betroffene Entitätsmenge) für jeden einzelnen Normalisierungsschritt. Überlegen Sie sich nach jedem Schritt, wie sich der Entitätsschlüssel der veränderten Entitätsmengen zusammensetzt und
kennzeichnen Sie diesen.
 1. Normalform: Keine Wiederholungsgruppen.
 2. Normalform: Alle Relationen sind in 1. Normalform und alle Nichtschlüsselattribute
sind vom Entitätsschlüssel voll funktional abhängig.
 3. Normalform: Alle Relationen sind in 2. Normalform und kein Nichtschlüsselattribut
ist von einem Entitätsschlüssel transitiv (via Nichtschlüsselattribut) abhängig.
140
12.2. Soll-Konzept: Datenmodell mit neuen Anforderungen ergänzen (TopDown)
Um eine Reduktion des Personalbestandes zu ermöglichen, muss die neue Anwendung eine
Reihe neuer Fähigkeiten aufweisen. Erweitern Sie das Datenmodell in der Weise, dass diese
neuen Fähigkeiten ebenfalls abgedeckt sind und bestehende Daten in das neue Modell migriert werden können.
12.2.1. Strukturierung der Reisen, Aggregation (Part-Of-Struktur / Stückliste)
(25 Minuten)
Die Struktur der Reisen kann im jetzigen System nicht mit dem notwendigen Detaillierungsgrad
festgehalten werden. Der Aufbau der Reisen ist den einzelnen Mitarbeitern durch die grössere
Anzahl von Reisen nicht mehr geläufig, so dass deren Struktur festgehalten werden können
muss. Eine Reise kann sich aus einer Reihe von Reisen zusammensetzen, jede dieser Reisen kann
wiederum aus einer Reihe von Reisen bestehen usw. Jede Reise lässt sich damit als eine Art
Baum darstellen, wobei jeder Knoten des Baumes eine Reise repräsentiert. Ein und dieselbe Reise kann Bestandteil mehrerer Reisen sein.
Sonderangebot
USA intensiv
Reisenr. 67452
USA
Western Ride
Reisenr. 7634
Great Canyon
Donkey Trip
Reisenr. 76341
Reisefolgenr. 1
Miami,
Disneyworld
Reisefolgenr. 1
Reisenr. 2453
Reisefolgenr. 2
Los Angeles,
San Francisco
Reisenr. 76352
Reisefolgenr. 2
Figur 55: Beispiel einer Reisestruktur
Ein Mitarbeiter der TTW AG hat seine Vorstellungen zu Papier gebracht und eine Bildschirmmaske hierfür entwickelt:
ReSt01
Reisen-Struktur erfassen / modifizieren
Reise-Nr:
Bezeichnung:
Dauer:
User-ID
141
tt/mm/jjjj
nnnnnnnnnn
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
nnn
untergeordnete Reisen:
ReisefolgeNr.
Reise-Nr
nn
nnnnnnnnnn
nn
nnnnnnnnnn
nn
nnnnnnnnnn
nn
nnnnnnnnnn
nn
nnnnnnnnnn
nn
nnnnnnnnnn
nn
nnnnnnnnnn
nn
nnnnnnnnnn
nn
nnnnnnnnnn
nn
nnnnnnnnnn
nn
nnnnnnnnnn
_
_
_
_
_
_
_
_
_
_
_
Bezeichnung
F1=Auswahl F3=Ende F6=Einfügen Teilreise F7=Löschen Teilreise
Figur 56: Beispielmaske für die Reisestrukturierung
Zeigen Sie, wie sich dieser Sachverhalt im Datenmodell festhalten lässt und ergänzen Sie dieses
entsprechend. Welche Variante wäre ebenfalls möglich, falls jede Reise nur ein einziges Mal als
Teilreise auftreten würde (diese Variante wird in der Lösung nicht weiter verwendet)?
12.2.2. Zeitabhängige Daten und Varianten von Daten in Datenmodellen (40
Minuten)
Zusätzlich zur eigentlichen Strukturierung der Reisen muss festgehalten werden können, an welchem Datum welche Reisen durchgeführt werden (zeitabhängige Daten). Auch hierfür hat ein
Mitarbeiter einen Vorschlag für eine Bildschirmmaske erstellt:
ReTe01
Reisetermine erfassen / modifizieren
Reise-Nr:
Start-Datum:
Bezeichnung:
Dauer:
User-ID
tt/mm/jjjj
nnnnnnnnnn
tt/mm/jjjj
nnn
untergeordnete Reisen:
_
_
_
_
_
_
_
_
_
_
_
Start-Dat.
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
ReisefolgeNr.
nn
nn
nn
nn
nn
nn
nn
nn
nn
nn
nn
Reise-Nr
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
Bezeichnung
F1=Auswahl F3=Ende F6=Einfügen Teilreise F7=Löschen Teilreise
Figur 57: Beispielmaske für die Verwaltung der Reisedaten
Welche zwei grundsätzlichen Methoden können angewandt werden? Welches sind die Vorund Nachteile der beiden Lösungsansätze? Welche Lösung empfehlen Sie? Zeigen Sie die LöTeil 4: Fallbeispiel
142
sung für beide Varianten in Ihrem Datenmodelldiagramm. Beachten Sie, dass in der ermittelten
Lösung auch ersichtlich sein muss, welche Teilreise (an einem bestimmten Datum) zu welcher
übergeordneten Reise (an einem bestimmten Datum) gehört!
Zum Teil müssen Reisen auch individuell angepasst werden (z.B beim Anschluss von einer Woche
Badeurlaub) (Varianten von Daten). Wie können individuelle Varianten im Datenmodell abgelegt werden?
12.2.3. Mitarbeiterstamm, Spezialisierung/Generalisierung (Is-A-Struktur) (20
Minuten)
Zwar ist der Mitarbeiterbestand in der Zentrale klein (ca. 10 Mitarbeiter), dafür sind etwa 100 Reiseleiter im Dienste der TTW AG tätig. Diese sollen ebenfalls erfasst werden können. Dabei muss
festgehalten werden können, welche Reisen (bzw. Teilreisen) die einzelnen Reiseleiter begleiten
können und welche Reisen diese an welchen Terminen effektiv begleiten (nur ein Reiseleiter pro
Termin). Hierbei sollen die gemeinsamen Daten der Kunden und Mitarbeiter (Reiseleiter sind
ebenfalls Mitarbeiter) mittels Generalisierung festgehalten werden:
Rele01
Reiseleiter erfassen / modifizieren
Reise-Nr:
Bezeichnung:
Dauer:
User-ID
tt/mm/jjjj
nnnnnnnnnn
nnn
mögliche Reiseleiter:
Reiseleiter/Name
nnnnnnnnnn xxxxxxxxxxxxxxxxxxxxxxxxxxxx
F1=Auswahl F3=Ende F6=Einfügen möglichen Reiseleiter F7=Löschen möglichen Reiseleiter
Rele02
Eff. Reiseleiter erfassen / modifizieren
Reise-Nr:
Start-Datum:
Reiseleiter/Name:
Bezeichnung:
Dauer:
User-ID
tt/mm/jjjj
nnnnnnnnnn
tt/mm/jjjj
nnn
effektive Reiseleiter:
_
_
_
_
_
_
_
_
_
_
_
Start-Dat.
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
tt/mm/jjjj
ReisefolgeNr.
nn
nn
nn
nn
nn
nn
nn
nn
nn
nn
nn
Reise-Nr
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
nnnnnnnnnn
Bezeichnung
Reiseleiter/Name
nnnnnnnnnn xxxxxxxxxxxxxx
F1=Auswahl F3=Ende
Figur 58: Beispielmasken für die Verwaltung des Mitarbeiterstamms
143
Untersuchen Sie das Datenmodell auf Verbundinstrumente im Datenmodell. Welche Verbundinstrumente finden Sie, welche weiteren Verbundinstrumente kennen Sie?
12.3. Vorgehensentscheid Dateiverwaltung oder DBMS (20 Minuten)
Für das weitere Vorgehen soll der Grundsatzentscheid gefällt werden, ob das bestehende Dateiverwaltungssystem ausgebaut werden soll oder ob eine gänzlich neue Lösung mittels eines
Datenbankmanagementsystems erstellt werden soll. Welche Argumente sprechen für, welche
gegen den Wechsel zum Datenbanksystem? Bereiten Sie eine Kurzpräsentation der Argumente
vor. Bedenken Sie, dass die bestehenden Hardwareressourcen, d.h. das PC-Netzwerk mit Server,
weiterhin genutzt werden sollen.
12.4. Ableiten des internen Schemas, Bestimmen der physischen Speicherorganisation
12.4.1. Internes Schema (15 Minuten)
Die Geschäftsleitung hat sich aufgrund Ihrer Argumente für die Einführung eines DBMS entschieden. In einem ersten Schritt soll daher das interne Schema ausgehend vom entwickelten
konzeptionellen Datenmodell hergeleitet werden. Welche Unterlagen können für die Gestaltung des internen Schemas herangezogen werden? Welche Einflüsse können diese Unterlagen
auf das Modell haben, welche Entscheidungen erwarten Sie?
12.4.2. Physische Speicherorganisation (5 Minuten)
Das ausgewählte DBMS unterstützt sowohl eine baumstrukturierte Zugriffsmethode wie auch das
Hashing-Verfahren. Entscheiden Sie für jede Entitätsmenge, welches der beiden Zugriffsverfahren Sie für diese Entitätsmenge einsetzen möchten.
12.5. Meta-Entitätstypen, Data-Dictionary (20 Minuten)
Das Datenbankverwaltungssystem, welches im Netzwerk eingesetzt wird, ist eine typische PCLösung und enthält kein Data-Dictionary. Die Geschäftsleitung der TTW AG hat aus den Erfahrungen mit der Vorgängerlösung gelernt und beschlossen, dass das Datenmodell für die neue
Lösung durchgängig zu dokumentieren sei. Hierfür soll ein sehr einfaches Datenmodell für ein
passives Data-Dictionary entwickelt werden. Folgende Dokumente und Zusammenhänge sollen
darin möglichst einfach abgelegt werden können:
 Entitätsmengen
 Attribute
 Entitäts- und Fremdschlüssel
Das Data-Dictionary ist weder aktiv noch integriert zu gestalten. Es wird lediglich zu Dokumentationszwecken eingesetzt.
145
Anhang
147
13.1. Farben, Sonderzeichen und deren Bedeutung
Folgende Farben und Sonderzeichen werden im Dokument mit folgender Bedeutung verwendet:
 Das Kapitel bzw. der Abschnitt enthält Informationen, welche für den Anfänger ohne Modellierungserfahrung nicht geeignet sind oder das vertiefende Detailkenntnisse aufweist.
 Weist auf die Definition eines Begriffes hin.
 Wird in Aufzählungen verwendet, die keine feste Anzahl von Punkten haben.
1. Wird in Aufzählungen verwendet, die eine feste Anzahl von Punkten haben.
 Vorteil in einer Vergleichsliste der Vor- und Nachteile.
 Nachteil in einer Vergleichsliste der Vor- und Nachteile.
Beispiele in SQL-Code sind gelb hinterlegt.
Anhang
148
13.2. Synonyme unterschiedlicher Systeme und Modelle
Die Tabelle enthält die Synonyme (sinnverwandtes Wort) der unterschiedlichen Systeme und Modelle. Dabei wurde stärker auf den möglichen Quervergleich als auf die 100%-ige Übereinstimmung der Begriffe geachtet. In Klammer sind die jeweiligen englischen Begriffe angebracht, sofern diese von den
im Deutschen verwendeten Ausdrücken abweichen.
Dateiverwaltung
hierarchische Datenbank
netzwerkartige Datenbank
relationale Datenbank
Entity-Relationship-Modell
objektorientierter Ansatz
Datei (File)
Record-Typ
Record-Typ
Tabelle (Table), Relation
(Relation)
Entitätsmenge (Entity Set)
Klasse (Class)
Datensatz (Record)
Datensatz (Record)
Datensatz (Record)
Tupel , Zeile (Row)
Entität (Entity)
Objekt, Instanz
Feld (Field)
Feld (Field)
Item
Attribut, Spaltenname
Attribut
Variable, Attribut
-
-
-
Primärschlüssel (Primary
Key)
Entitätschlüssel (Entity Key)
-
Set-Typ
Set-Typ
Referentielle Integrität
(Referential Integrity)
Beziehungsmenge (Relationship Set)
Tabelle 37: Synonyme Systeme und Datenmodelle
Anhang
149
13.3. Kürzel der Datenmodellierung und Datenbanktechnik
# .......................................... Nummer, meist innerhalb Entitätsschlüssel verwendet
ANSI-SPARC ........................ Study Group on Data Base Management Systems
BCNF ................................... Boyce/Codd Normal Form
CODASYL ............................ Conference on Data Systems Languages
c ........................................... konditionelle Assoziation: keine oder eine
DB ........................................ Database
DBA...................................... Database Administrator
DBMS ................................... Data Base Management System (Datenbank Management System)
DBTG ................................... Data Base Task Group
DCL ...................................... Data Control Language (Daten-Integritäts-Sprache)
DD........................................ Data Dictionary
DDL ...................................... Data Definition Language (Daten-Definitions-Sprache)
DML ..................................... Data Manipulation Language (Daten-Manpulations-Sprache)
ER ......................................... Entity-Relationship
ERM...................................... Entity-Relationship-Model
IMS ....................................... Information Management System (IBM)
NF......................................... Normalform (1NF, 2NF ...)
m .......................................... multiple Assoziation: eine oder mehrere
mc ....................................... multiple-konditionelle Assoziation: keine oder mehrere
SQL ...................................... Structured Query Language
1 ........................................... einfache Assoziation: genau eine
1NF....................................... Erste Normalform
2NF....................................... Zweite Normalform
3NF....................................... Dritte Normalform
Anhang
150
13.4. Kontrollfragen zum konzeptionellen Datenmodell
 Die folgenden 16 Kontrollfragen dienen der Selbstkontrolle von konzeptionellen Datenmodellen. Hiermit können die häufigsten 'einfachen' Fehler aufgespürt und eliminiert werden:
Fragen zum Diagramm:
 Sind alle m:m-Beziehungen aufgelöst (nur für konzeptionelle Modelle) (Assoziationstypen
übers Kreuz austauschen)?
 Sind alle 1:1-Beziehungen eliminiert (nur für konzeptionelle Modelle) (Mengen zusammenfassen)?
 Sind unklare Fremdschlüsselbeziehungen im grafischen Modell beschriftet?
 Sind die Namen der Entitätsmengen sinnvoll und beschreiben den Inhalt eindeutig?
 Ist die Darstellung halbhierarchisch?
 Wurde die Notation gemäss Vorgabe verwendet?
Abgleich zwischen Diagramm und Attributskatalog:
 Ist die Anzahl der Entitätsmengen im Diagramm und im Attributskatalog identisch? Vorsicht
bei Spezialisierungen! Für jede Spezialisierung und für die Generalisierung muss je eine Entitätsmenge im Attributskatalog auftreten!
 Sind die Namen der Entitätsmengen im Diagramm und im Attributskatalog identisch?
 Ist die Anzahl der Fremdschlüssel im Diagramm (ein Fremdschlüssel je Verbindungsstrich und
je Spezialisierung) und im Attributskatalog identisch?
 Sind die Fremdschlüssel im Attributskatalog in jenen Entitätsmengen, welche im Diagramm
die m-, mc- oder c-Assoziation (nur bei 1:c-Beziehungen) aufweisen?
Fragen zum Attributskatalog:
 Ist der Attributskatalog vollständig (erhöht die Verständlichkeit des Modells)?
 Sind die Identifikationsschlüssel unterstrichen?
 Sind die Identifikationsschlüssel eindeutig?
 Sind die Fremdschlüssel gekennzeichnet (bei Attributskombinationen zusammengehörige Attribute angeben!) und die referenzierte Entitätsmenge angegeben?
 Ist der Aufbau des Fremdschlüssels identisch zum Aufbau des Identifikationsschlüssels der referenzierten Entitätsmenge?
 Referenziert der Fremdschlüssel jene Entitätsmenge, welche den erlaubten Wertebereich am
stärksten einschränkt (referenziert Aufträge z.B. die Partner anstatt die Kunden)?
Anhang
151
In den Checkfragen werden folgende vier Fragetypen verwendet:
1. Fragetyp A, Fragetyp der Einfachauswahl:
Bezeichnen Sie nur eine Wahlantwort (die beste oder einzig zutreffende) durch Markieren des betreffenden Buchstabens.
2. Fragetyp B, Fragetyp der Zuordnung:
Auf fünf mit Buchstaben bezeichneten Auswahlantworten folgt eine Gruppe von
nummerierten Fragen. Wählen Sie zu jeder dieser nummerierten Fragen nur eine,
(die am besten dazu passende) Wahlantwort und markieren Sie den entsprechenden Buchstaben. Ein und dieselbe Antwort kann dabei einmal, mehrmals oder gar
nicht verwendet werden. Es braucht also nicht "aufzugehen".
3. Fragetyp E, Fragetyp der kausalen Verknüpfung
Halten Sie
A) b e i d e Feststellungen u n d die Weil-Verknüpfung für richtig, so markieren Sie
den Buchstaben A.
B) beide Feststellungen für richtig, die Weil-Verknüpfung jedoch für falsch, so markieren Sie den Buchstaben B.
C) die erste Feststellung für richtig, die zweite für falsch, so markieren Sie den Buchstaben C.
D) die erste Feststellung für falsch, die zweite für richtig, so markieren Sie den Buchstaben D.
E) beide Feststellungen für falsch, so markieren Sie den Buchstaben E.
4. Fragetyp K, Fragetyp der mehrfachen Entscheidung richtig/falsch für jede von vier
Fragen:
Eine Frage oder Feststellung ist begleitet von vier Antworten oder Ergänzungen; jede
dieser Antworten kann richtig oder falsch sein. Halten Sie eine Antwort für richtig,
bezeichnen Sie diese mit (+), halten Sie die Antwort für falsch, mit (-). Unabhängig
davon, ob die Frage grammatikalisch im Singular oder Plural formuliert ist, können 1,
2, 3, 4 oder auch gar keine der Antworten richtig sein. Die Frage ist nur dann richtig
beantwortet, wenn alle 4 Antworten korrekt bezeichnet sind.
Anhang
152
15.1. Checkfragen: 2. Die historische Entwicklung von Datenbanksystemen, Begriff Datenbank
1.
In hierarchischen Systemen können netzwerkartige Strukturen nur mit hohen Redundanzen gebildet
werden.
 B) In hierarchischen Systemen können netzwerkartige Strukturen nicht direkt abgebildet werden.
 C) In netzwerkartigen Systemen können auch netzwerkartige Strukturen gebildet werden.
 D) Durch die physische Referenzierung der Daten sind Strukturänderungen mit hohem technischen
Aufwand verbunden. Alle betroffenen Referenzen müssen neu ermittelt werden.
 E) Die Sprachen hierarchischer und netzwerkartiger Systeme verlangen vom Benutzer eine hohe
Kenntnis der Datenbanksprache.
2.





3.
 A) In hierarchischen DBMS wird mittels physischer Adressverweise navigiert.
 B) In netzwerkartigen DBMS wird mittels physischer Adressverweise navigiert.
 C) In relationalen DBMS werden die Daten ohne Navigation aufgrund der Referenzen in den Fremdschlüsseleinträgen verarbeitet.
 D) Der Begriff ‘Integrative DBMS’ ist frei erfunden.
 E) Verteilte Systeme können hierarchischer, netzwerkartiger und relationaler Natur sein. Nur in den hierarchischen und netzwerkartigen DBMS wird navigiert.
4.
 A)
In hierarchischen DBMS werden auf der physischen, internen Ebene Beziehungen mittels physischer
Adressverweise hergestellt.
 B) In netzwerkartigen DBMS werden auf der physischen, internen Ebene Beziehungen mittels physischer
Adressverweise hergestellt.
 C) In relationalen DBMS werden die Beziehungen auf der logischen Ebene durch identische Fremdschlüsseleinträge hergestellt.
 D) Falsche Antwort, siehe C.
 E) Falsche Antwort, siehe A und B.
5.





6.
 A)
Datenmanipulationssprachen sind nicht nur als 3. Generationssprache entwickelt worden, sondern
z.B. auch als 4. Generationssprache (z.B. SQL).
 B) Eine Menge von Tupeln bildet eine Tabelle (Relation) der Datenbank. Die Tupel werden durch DMLBefehle verarbeitet.
 C) Die DML (Data Manipulation Language, Daten Manipulations Sprache) wird zur Manipulation der
Daten verwendet.
 D) In der Protokolldatei werden die Änderungen der Daten durch die DML-Befehle protokolliert.
 E) Konsistenzbedingungen gewährleisten, dass DML-Befehle nur konsistenzerhaltend ausgeführt werden können.
7.
 A)
 A)
A)
B)
C)
D)
E)
A)
B)
C)
D)
E)
Korrekte, aber nicht beste Antwort.
Korrekte und beste Antwort.
Im relationalen DBMS können Daten auch netzwerkartig abgelegt werden.
Nicht der Fremd-, sondern der Entitätsschlüssel identifiziert die Zeilen eindeutig.
Relationale Datenbanken können ein Höchstmass an physischer Datenunabhängigkeit gewährleisten.
Die Datenbasis ist ebenfalls Teil der Datenbank.
Nicht nur relationale Datenbanksysteme können Datenbanken bilden.
Richtig, das Datenbanksystem zusammen mit der Datenbasis ergeben die Datenbank.
Nicht nur relationale Datenbanksysteme können Datenbanken bilden.
Die Datenbasis ist ebenfalls Teil der Datenbank, die Hardware ist belanglos.
Durch die Trennung der Daten von den Anwendungen können Struktur-Änderungen auf der logischen Ebene ohne Einfluss auf die Programme vorgenommen werden (z.B. Einfügen eines Feldes).
 B) Falsch: Durch die Trennung der Daten von den Anwendungen können Struktur-Änderungen auf der
physischen Ebene ohne Einfluss auf die Programme vorgenommen werden (z.B. Änderungen der
physischen Speicherorganisation). Damit besteht keine Abhängigkeit der Programme.
 C) Der dauerhafte Bestand der Daten ist Basis jedes Datenbanksystems. Selbst in schwierigen Situationen (z.B. Head-Crash) müssen die Daten erhalten bleiben.
 D) Mittels Datensichten sollen Benutzer nur den für sie relevanten Teil der Datenbasis sehen.
 E) Die Strukturierung der Daten verlängert die Lebensdauer der Anwendungen und sorgt für widerspruchsfreie Informationen.
Anhang
153
1.
1. /
2. -
Der Einsatz von Datenbanksystemen kann nicht generell empfohlen werden (z.B. zur Steuerung
technischer Maschinen).
Die beiden Aussagen sind ohne Zusammenhang.
Die Integrität der Daten muss durch die Definition der Konsistenzregeln (mit dem Benutzer) im Datenbanksystem gesichert werden.
1.
+  
 
 
 
Die Dateiverwaltung führt zur Rechenzeit meist nur die notwendigsten Operationen aus. Auf die
Überprüfung von Zugriffsrechten, kontrolliertem Mehrbenutzerbetrieb, Überprüfung von Integritätsregeln etc. wird im Gegensatz zum DBMS meist verzichtet. Die Dateiverwaltung ist daher schneller,
verzichtet aber auf wichtige Prüfungen.
Durch die Trennung der Daten von den Anwendungen können in DBMS Änderungen an der Datenstruktur auch nachträglich einfach ausgeführt werden. Es leistet damit einen direkten Beitrag zur beschleunigten Entwicklung und Wartung.
In Datenbanken können Integritätsregeln (im Gegensatz zur Dateiverwaltung) direkt definiert werden. Deren Sicherstellung ist dort automatisch gewährleistet.
Entspricht im Kern der Aussage zur zweiten Feststellung. Durch die Trennung der Daten von den Anwendungen ist es möglich die Datenstruktur dynamisch zu entwickeln, ohne bestehende Anwendungen zu gefährden.
Anhang
154
15.2. Checkfragen: 3. Einführung in die Datenmodellierung
1.
 A)
In der externen Ebene wird der für den Benutzer relevante Teil des Datenmodells dargestellt. Auf die
Leistung des DBMS hat sie keinen Einfluss, sie ist lediglich ein Ausschnitt des Datenmodells.
 B) In der konzeptionellen Ebene wird die Datenstruktur unabhängig von einem Ziel-DBMS dargestellt.
Überlegungen zur Leistungsbeeinflussung des DBMS sind auf dieser Ebene daher unerwünscht.
 C) In der internen Ebene wird das Datenmodell für ein bestimmtes DBMS dargestellt. Auf dieser Ebene
nehmen Leistungsüberlegungen einen zentralen Punkt ein.
 D) Siehe Antwort C.
 E) Siehe Antworten A und B.
1.
1. +
/
2. +
Leistungsbestimmende Überlegungen werden nur beim Erstellen des internen Datenmodells, welches auf ein bestimmtes DBMS ausgerichtet ist, einbezogen.
Der Benutzer muss beim Erstellen des konzeptionellen Modells einbezogen werden, denn nur er
kann die Anforderungen an die zu erstellende Anwendung definieren. Meist sind die Benutzer aber
nicht in der Lage, das entwickelte Datenmodell zu lesen oder zu überprüfen, sondern müssen gezielt
befragt werden.
2.
Das konzeptionelle Datenmodell nimmt keinen Bezug auf ein bestimmtes DBMS. Erst beim Erstellen
des internen Modells werden Leistungsüberlegungen, bezogen auf ein konkretes DBMS, ausgeführt.
weil Die beiden Aussagen sind sinnvoll verknüpft.
2. + Im physischen Design wird entschieden, mittels welcher Hilfsorganisationen (z.B. Index für eine Personalnummer) die effiziente Verarbeitung gewährleistet werden soll.
3.
1. +
1. +
/
2. -
Das konzeptionelle Datenmodell wird ohne konkreten Bezug auf ein bestimmtes Datenbanksystem
erstellt, sondern stellt die Datenstruktur aus abstrakter Sicht dar.
Das interne Datenmodell wird beim Top-Down-Vorgehen ausgehend vom konzeptionellen Modell
abgeleitet. Die Ableitung des internen Modells aus dem konzeptionellen Modell wird daher häufig
ausgeführt.
4.
1. +
/
2. -
Externe Ebene, Benutzersicht und View sind Synonyme.
Die externe Sicht erlaubt es, die Daten in beliebiger Art und Weise darzustellen (z.B. können zwei Entitätsmengen zu einer Entitätsmenge zusammengefasst werden). Der Benutzer kann daher aus der
Benutzersicht keine Rückschlüsse auf das interne Datenmodell ziehen.
5.
1. +
Ausgehend vom konzeptionellen Modell werden beim Top-Down-Vorgehen die interne und auch
die externen Datenstrukturen abgeleitet.
Im konzeptionellen Modell werden die Daten aus abstrakter Sicht des Unternehmens dargestellt. Eine Anwendung nimmt dabei meist nur auf einen Ausschnitt des Datenmodells Bezug.
/
2. +
1.
+  
 
 
 
Anhang
Das konzeptionelle Datenmodell wird auf abstrakter Ebene, ohne Berücksichtigung des DBMS oder
der Hardware erstellt.
Aus dem konzeptionellen Datenmodell werden das interne Datenmodell und die externen Sichten
abgeleitet. Das endgültige Datenbankdesign steht mit dem konzeptionellen Modell daher noch
nicht fest.
Siehe Teilfrage 2 dieser Frage.
Mittels des konzeptionellen Datenmodells lassen sich keine Zugriffsbefugnisse realisieren. Mit den externen Datenmodellen können aber Teilsichten auf die Datenbank gebildet werden. Die externen
Datenmodelle bieten daher die Möglichkeit, eine erste, einfache Struktur von Zugriffsbefugnissen zu
bilden. Indem Benutzern nur jene externen Sichten mit den für sie relevanten Daten zugänglich gemacht werden, können schützenswerte Daten verborgen werden.
155
15.3. Checkfragen: 4. Elementarinstrumente des konzeptionellen Datenmodells
1.
Der Entitätsschlüssel ist immer auch Schlüsselkandidat. Der Entitätsschlüssel ist jener Schlüsselkandidat, der als Entitätsschlüssel festgelegt wurde.
 B) Ein Entitätsschlüssel kann Fremdschlüssel sein, muss aber nicht Fremdschlüssel sein.
 C) Die Domäne eines Fremdschlüssels sind immer die Werte eine Entitätsschlüssels.
 D) Ein Entitätsschlüssel muss immer eindeutig sein.
 E) Ein Entitätsschlüssel kann aus einem oder beliebig vielen Attributen bestehen.
2.
 A)
Das erweiterte Relationenmodell kennt keine Beziehungsmengen. Dennoch werden Entitätsmengen, welche zwei Entitätsmengen mittels zweier 1:m-Beziehungen verbinden, häufig als Beziehungsmengen bezeichnet.
 B) Im Entity-Relationship-Modell werden Beziehungsmengen explizit modelliert.
 C) Das hierarchische Datenmodell kennt keine Beziehungsmengen.
 D) Das netzwerkartige Datenmodell kennt keine Beziehungsmengen.
 E) Das relationale Datenmodell kennt keine Beziehungsmengen.
3.





4.
 A) Siehe Antwort D.
 B) Korrekte Anwort, bessere Antwort siehe D.
 C) Jedes Datenmodell des Entity-Relationship-Models lässt sich ohne Informationsverlust in ein relationales Datenmodell umwandeln (und umgekehrt).
 D) Beim Herleiten des relationalen Modells wird die Beziehungsmenge in eine Entitätsmenge umgewandelt und es werden eine 1:m- und eine 1:1-Beziehung hergestellt. Durch die 1:1-Beziehung kann
die neu gebildete Entitätsmenge mit der entsprechenden Entitätsmenge zusammengelegt werden.
Dadurch verschwindet die Entitätsmenge und das Attribut wird einer bestehenden Entitätsmenge
einverleibt.
 E) Diese Antwort hat keinen Zusammenhang mit der Frage.
5.





6.
 A)
 B)
In beiden Modellen spielt die referentielle Integrität eine wichtige Rolle.
Der Begriff Navigation wird nur in hierarchischen und netzwerkartigen Datenbanksystemen verwendet.
 C) Während im Entity-Relationship-Modell Beziehungen immer mittels Beziehungsmengen realisiert
werden, werden im erweiterten Relationenmodell keine Beziehungsmengen eingefügt, sondern die
Entitätsmengen werden direkt mittels Beziehungen verknüpft.
 D) Die beiden Modelle unterscheiden sich aufgrund der unterschiedlichen Konzepte etwas in der Darstellung. Die Antwort C ist aber die bessere Antwort.
 E) Bei beiden Modellen wird der Wertebereich eingesetzt.
7.
 A)
 B)
Ein Schlüsselkandidat kann mehrere Attribute beinhalten, Antwort E ist aber die bessere Antwort.
Schlüsselkandidaten werden aufgrund ihrer eindeutigen Identifizierung der Entitäten einer Entitätsmenge bestimmt.
 C) Jede Entitätsmenge enthält mindestens einen Schlüsselkandidat, muss aber nicht mehrere Schlüsselkandidaten haben.
 D) Der Aufbau eines Schlüsselkandidaten kann alle möglichen Formen annehmen.
 E) Aus der Menge der Schlüsselkandidaten wird der geeignetste als Entitätsschlüssel verwendet.
8.
 A) Eine Menge verschiedener Datenwerte ist ein Wertebereich, aber keine Assoziation.
 B) Korrekte Definition der Assoziation.
 C) Die Beziehung besteht aus einer Assoziation und einer Gegenassoziation. Die Beziehung besteht
daher aus zwei Assoziationen.
 D) Das Attribut beschreibt die Eigenschaften der Entitätsmengen.
 E) Die Antwort ist ohne tieferen Sinn.
 A)
A)
B)
C)
D)
E)
A)
B)
C)
D)
E)
Die 1:1-Beziehung sollte nur für rekursive Beziehungen verwendet werden.
Die 1:c-Beziehung tritt im konzeptionellen Modell auf.
Die 1:m-Beziehung tritt im konzeptionellen Modell auf.
Die 1:mc-Beziehung tritt im konzeptionellen Modell auf.
Die c:m-Beziehung tritt im konzeptionellen Modell auf.
Blanks stellen die leere Zeichenkette dar, nicht den Wert NULL.
Nullen stellen den numerischen Wert Null dar.
Die Antwort ist korrekt.
HEX-0 - Werte sind numerische Nullen im hexadezimalen System.
Diese Antwort hat keinen Zusammenhang mit der Frage.
Anhang
156
9.
 A) Diese Eigenschaft wird in der Entitätsintegrität gefordert.
 B) Dies ist falsch. Entitätsschlüssel werden häufig nicht als Fremdschlüssel verwendet.
 C) Fremdschlüssel haben dann, wenn keine Beziehung hergestellt werden soll, den NULL-Wert gespeichert.
 D) Korrekte Definition der referentiellen Integrität.
 E) NULL-Werte sind in Attributen erlaubt, nur dort können NULL-Werte eingesetzt werden.
1.

A)

B)

C)

D)

E)
Der Begriff Tupel des relationalen Modells entspricht dem Begriff Entität im Entity-Relationship-Model.
2.

A)

B)

C)

D)

E)
Da der Entitätsschlüssel immer eindeutig sein muss, verhindert er identische Entitäten in einer Entitätsmenge
(Tabelle).
3.

A)

B)

C)

D)

E)
Der Fremdschlüssel referenziert die Werte eines Entitätsschlüssels und darf nur Werte annehmen, die in der
referenzierten Entitätsmenge tatsächlich auftreten.
4.

A)

B)

C)

D)

E)

D)

E)
Schlüsselkandidaten sind mögliche Entitätsschlüssel.
5.

A)

B)

C)
Der NULL-Wert hat in sämtlichen Domänen die Bedeutung von ‘Der Wert ist undefiniert’.
6.

A)

B)

C)

D)

E)

E)
Zu einem linken Schuh gehört genau ein rechter Schuh (und umgekehrt).
7.

A)

B)

C)

D)
Eine Frau kann einen Mann heiraten und ein Mann kann eine Frau heiraten.
8.

A)

B)

C)

D)

E)
Ein Kunde kann zugleich auch ein Werbekunde sein, ein Werbekunde ist aber immer auch (genau ein)
Kunde.
9.

A)

B)

C)

D)

E)
Ein Kunde kann durch einen Sachbearbeiter betreut werden und ein Sachbearbeiter hat mehrere Kunden,
deren Unterstützung er wahrnehmen muss.
10.  A)

B)

C)

D)

E)
Ein Kunde kann mehrere Konti haben, ein Konto gehört immer genau einem Kunden.
11.  A)

B)

C)

D)

E)
Die Domäne enthält die Menge der erlaubten (verschiedenen) Datenwerte.
12.  A)

B)

C)

D)

E)

E)
Die Attribute beschreiben die Eigenschaften der Entitätsmenge.
13.  A)

B)

C)

D)
Die Entitätsmenge besteht aus einer Menge von Entitäten (Tupel ist Synonym für Entität).
14.  A)

B)

C)

D)

E)
Der Entitätsschlüssel mit einem oder mehreren Attributen identifiziert jede Entität eindeutig.
15.  A)

B)

C)

D)

Die Beziehungsmenge verknüpft Entitäten von Entitätsmengen miteinander.
Anhang
E)
157
1.
Der Fremdschlüssel entspricht in seinem Aufbau exakt dem Entitätsschlüssel der referenzierten Entitätsmenge.
weil Die beiden Aussagen sind korrekt verknüpft.
2. + Würde der Aufbau der beiden Schlüssel nicht übereinstimmen, bestünde die Gefahr, dass mehrere
Entitäten gleichzeitig referenziert werden.
2.
1. +
/
2. -
1. +
Im Entity-Relationship-Modell können m:m-Beziehungen direkt dargestellt werden.
m:m-Beziehungen werden nicht verhindert, sondern sind explizit erlaubt.
1.
+  
 
 
 
2.
+




3.
+  




 
 
 
Das erweiterte Relationenmodell kennt im Gegensatz zum Entity-Relationship-Modell keine Beziehungsmengen.
Das erweiterte Relationenmodell hat keine zusätzlichen Elementarinstrumente, dafür fehlt ihm aber
die Beziehungsmenge.
Das erweiterte Relationenmodell kennt auch den Assoziationstypen mc.
Das erweiterte Relationenmodell kann auf allen drei Ebenen verwendet werden.
Der Entitätsschlüssel muss immer eindeutig sein.
Ein kurzer Entitätsschlüssel ist vorteilhaft.
Der Entitätsschlüssel kann Attribute aller möglichen Domänen enthalten.
Ein schreib- und lesbarer Entitätsschlüssel erleichtert für Entwickler und Benutzer die Arbeit ungemein.
Da sich die effektiv auftretenden Entitätsschlüsselwerte in der durch den Fremdschlüssel referenzierten Entitätsmenge ändern, ändern sich auch die erlaubten Werte für den Fremdschlüssel selbst.
Fremdschlüssel können ein Schlüsselkandidat oder ein Teil eines Schlüsselkandidaten (oder auch Entitätsschlüssel) sein, müssen aber nicht.
Die referenzielle Integrität ist für den korrekten Zustand der Referenzen verantwortlich.
Das DBMS kann nicht von sich aus wissen, welche Fremdschlüssel welche Entitätsmengen referenzieren. Daher müssen diese im DBMS explizit definiert werden.
Anhang
158
15.4. Bearbeitungsaufgaben: 4. Elementarinstrumente des konzeptionellen Datenmodells
15.4.1. KontoSys, Kontoverwaltungs-System
Kunden
Konti
besitzen
gehören
Kundenbeziehungen
haben
KontiUm sätze
aus
Kontoum sätze
Figur 59: Entity-Relationship-Modell von KontoSys
Kunden
Konti
besitzen
gehören
KundenBeziehungen
haben
Kontoum sätze
Figur 60: Erweitertes Relationenmodell von KontoSys
Kunden
Attributsname:
Kunden#
Name
Vorname
...
Wertebereich:
Numerisch 10
Character 20
Character 20
Beschreibung:
Kundennummer
Name des Kunden
Vorname des Kunden
Wertebereich:
Numerisch 10
Numerisch 10.5
Datum
Beschreibung:
Kontonummer
Aktueller Saldo des Kontos
Datum der Kontoeröffnung
Wertebereich:
Numerisch 10
Numerisch 10
Beschreibung:
 Kunden.Kunden#, Fremdschlüssel
 Konti.Konto#, Fremdschlüssel
Konti
Attributsname:
Konto#
Betrag
Eröffnungsdatum
...
Kundenbeziehungen
Attributsname:
Kunden#
Konto#
Anhang
159
Kontoumsätze
Attributsname:
Buchungs#
Konto#
Umsatz
...
Wertebereich:
Numerisch 10
Numerisch 10
Numerisch 10.5
Beschreibung:
Eindeutige Nummer des Kontoumsatzes
 Konti.Konto#, Fremdschlüssel
Verbuchter Umsatz
Tabellen 38: Attributskatalog zu KontoSys
15.4.2. RezeptSys, Rezeptverwaltungssystem
Stam m rezepte
angewandt
in
Produkte
enthalten
in
verwenden
Auftragsvergaben
Rezeptzus'setzungen
basierend
auf
Aufträge
Figur 61: Entity-Relationship-Modell von RezeptSys
Stam m rezepte
angewand
t in
Aufträge
Produkte
enthalten
in
verwenden
Rezeptzusam m ensetzungen
Figur 62: Erweitertes Relationenmodell von RezeptSys
Stammrezept
Attributsname:
Stammrezept_Id
Vorgehensbesch.
...
Wertebereich:
Numerisch 10
Text
Beschreibung:
Identifikation des Stammrezepts
Vorgehensbeschreibung zur Ausführung des Stammrezepts
Anhang
160
Auftrag
Attributsname:
Auftrags_Id
Stammrezept_Id
Liter_Färbetrog
Wertebereich:
Numerisch 10
Numerisch 10
Numerisch 10.3
kg_Material
...
Numerisch 10.3
Beschreibung:
Identifikation des Auftrags
 Stammrezept.Stammrezept_Id
Anzahl Liter, die der verwendete Färbetrog für diesen
Auftrag hat
Anzahl kg, die für diesen Auftrag gefärbt werden
Attributsname:
Wertebereich:
Beschreibung:
Produkt_Id
Character 20
Produktbezeichnung
kg_Lagermenge
...
Character 80
Identifikation des Produkts (Chemikalien und Farbstoffe
werden hier gemeinsam abgelegt)
Bezeichnung des Produkts
Numerisch 10.3
Aktuelle Anzahl kg im Lager
Produkt
Rezeptzusammensetzung
Attributsname:
Zusammensetz_Id
Stammrezept_Id
Produkt_Id
Gramm_Pro_kg
Wertebereich:
Numerisch 10
Numerisch 10
Character 20
Numerisch 10.3
Gramm_Pro_Liter
Numerisch 10.3
Beschreibung:
Identifikation des Produktzusammensetzungseintrags
 Stammrezept.Stammrezept_Id
 Produkt.Produkt_Id
Wieviel Gramm des referenzierten Produkts sollen pro kg
Färbematerial für dieses Stammrezept verwendet werden.
Wieviel Gramm des referenzierten Produkts sollen pro Liter des Färbetroges für dieses Stammrezept verwendet
werden.
...
Tabellen 39: Attributskatalog zu RezeptSys
Anhang
161
15.5. Checkfragen: 5. Normalisierung von Entitätsmengen im konzeptionellen
Modell
1.
 A) Falsch, siehe B), C) und D).
 B) Die Werte der Attribute sind atomar, die Entitätsmenge ist damit in 1. Normalform.
 C) Keines der Attribute ist nur von einem Teil des Entitätsschlüssels (Personal# oder Filial#) abhängig, die
Entitätsmenge erfüllt damit auch die 2. Normalform.
 D) Zwar ist der Name funktional abhängig vom Nichtschlüsselattribut AHV#, aber die AHV# ist in der
Entitätsmenge Schlüsselkandidat. Damit ist die Entitätsmenge auch in 3. Normalform.
 E) Eine Entitätsmenge in 3. Normalform muss auch die 1. und 2. Normalform erfüllen. Die Antwort kann
daher für keine Entitätsmenge zutreffen.
2.
 A)
 B)
Die Normalisierung wird auf der konzeptionellen Ebene ausgeführt.
Die Normalisierung reduziert Redundanzen innerhalb einer Entitätsmenge. Sie ist aber nicht in der
Lage, Redundanzen, welche über mehrere Entitätsmengen verteilt sind, zu erkennen.
 C) Die Normalisierung ist ein kleiner Hilfskoffer, um Redundanzen während der Erstellung des konzeptionellen Modells zu verringern.
 D) Die Normalisierung zerlegt zwar Entitätsmengen, verfügt aber über keinen Algorithmus, um Entitätsmengen allenfalls wieder zusammenzusetzen.
 E) Durch die Normalisierung gewinnt das Datenmodell zusätzlich an Aussagekraft. Es werden dabei Entitätsmengen gebildet, welche inhaltlich zusammen gehören.
3.
 A) siehe C).
 B) siehe C).
 C) Werden m:m-Beziehungen direkt realisiert, so wird in der Entitätsmenge, in welcher der Fremdschlüssel eingebettet wird, die 2. Normalform verletzt. Dies, weil sämtliche Attribute, welche nicht zur
zu bildenden Entitätsmenge (Beziehungsmenge) gehören, nur von einem Teil des Entitätsschlüssels
abhängig sind und zwar von jenem Teil des Entitätsschlüssels, welcher bei der Zerlegung zurückbleiben würde.
 D) siehe C).
 E) siehe C).
4.
 A)
 B)
Korrekte Antwort, beste Antwort siehe C).
Es ist nicht das Ziel der Normalisierung, möglichst viele Entitätsmengen zu bilden. Das konzeptionelle
Modell sollte ja auch nur so wenig Entitätsmengen wie nötig enthalten. Durch das Zerlegen in inhaltlich zusammengehörige Entitätsmengen entstehen aber zwangsläufig neue Entitätsmengen.
 C) Durch die Reduzierung der Redundanzen gewinnt das konzeptionelle Modell viel. So ist es besser zu
verstehen, führt weniger zu Speicheranomalien, etc.
 D) Korrekte Antwort, beste Antwort siehe C).
 E) Korrekte Antwort, beste Antwort siehe C).
1.

A)

B)

C)

D)

E)
Bei der Denormalisierung wird die Datenstruktur bewusst derart verändert, dass die Ausführungsgeschwindigkeit der Anwendung optimal bzw. genügend ist. Dadurch wird die interne Datenstruktur hergeleitet, welche demnach nicht mehr voll normalisiert ist.
2.

A)

B)

C)

D)

E)
Die Normalisierung entfernt unerwünschte Redundanzen in der konzeptionellen Datenstruktur.
3.

A)

B)

C)

D)

E)
Die referentielle Integrität stellt sicher, dass ein Fremdschlüsselwert immer einen korrekten Wert enthält. Die
referentielle Integrität ist damit Basis für die Fremdschlüssel-Entitätsschlüssel-Beziehung.
4.

A)

B)

C)

D)

E)
Durch die Normalisierung werden Redundanzen innerhalb der Entitätsmengen reduziert. Dadurch sinkt
auch die Wahrscheinlichkeit von Speicheranomalien.
5.

A)

B)

C)

D)

E)
Durch die Normalisierung werden Redundanzen innerhalb der Entitätsmengen reduziert. Dadurch sinkt
auch die Wahrscheinlichkeit von Speicheranomalien.
Anhang
162
6.

A)

B)

C)

D)

E)
Wiederholungsgruppen verletzen die 1. Normalform. Entitätsmengen mit Wiederholungsgruppen sind daher
nicht normalisiert.
7.

A)

B)

C)

D)

E)
Die Normalisierung betrachtet ausschliesslich funktionale Abhängigkeiten innerhalb einer Entitätsmenge.
Die Fremdschlüsselbeziehung, welche eine funktionale Abhängigkeit über zwei Entitätsmengen herstellt,
wird damit nicht untersucht.
8.

A)

B)

C)

D)

E)
Bei der transitiven Abhängigkeit wird eine allfällige funktionale Abhängigkeit unter Nichtschlüsselattributen
gesucht.
9.

A)

B)

C)

D)

E)
Bei der Sicherstellung der vollen funktionalen Abhängigkeit der Nichtschlüsselattribute vom Entitätsschlüssel
wird dies betrachtet.
10.  A)

B)

C)

D)

E)
Bei der transitiven Abhängigkeit muss sichergestellt werden, dass das Nichtschlüsselattribut, von welchem
ein anderes Nichtschlüsselattribut funktional abhängig ist, nicht Schlüsselkandidat ist.
1.
Die Normalisierung findet auf der konzeptionellen Ebene statt und berücksichtigt die Leistung des internen Datenmodells daher nicht.
2. + Hilfsorganisationen werden in der internen Ebene untersucht, daher macht die Normalisierung dazu
keine Aussagen.
2.
1. +
1. +
/
2. -
Durch die systematische Verringerung der Redundanzen verkleinert sich auch die Wahrscheinlichkeit von Fehlern innerhalb der gespeicherten Entitätsmengen.
Die Normalisierung wird während der Bildung des konzeptionellen Modells verwendet und unterstützt den Ersteller der Datenstruktur bei der Entfernung von Redundanzen. Sie nimmt damit aber nur
einen kleinen Teil des gesamten Ablaufs ein.
1.
+  
 
 
 
2.
+  
 
 
 
Anhang
Wiederholungsgruppen verletzen die 1. Normalform.
Die 2. Normalform stellt sicher, dass alle Nichtschlüsselattribute vom Gesamtschlüssel abhängig sind.
Die 1. Normalform verbietet dies aber nicht, so dass es auch in der 1. Normalform Entitätsmengen
geben kann, in welchen alle Nichtschlüsselattribute vom Gesamtschlüssel abhängig sind.
Das Erstellen von Datensichten ist anhand jeder beliebigen, auch einer nicht normalisierten Entitätsmenge möglich.
Die 2. und 3. Normalform entfernen verbleibende Redundanzen in Entitätsmengen der 1. Normalform.
Die Normalisierung beseitigt die am häufigsten auftretenden Redundanzen innerhalb einer einzelnen Entitätsmenge.
Die Normalisierung findet auf der konzeptionellen Ebene statt. Beim Bilden des internen Modells wird
Denormalisiert. Dabei wird die allenfalls ungünstige Datenstruktur des konzeptionellen Modells überarbeitet.
Entitätsmengen mit weniger Redundanzen erleiden weniger häufig Speicheranomalien.
Die Normalisierung betrachtet immer nur einzelne Entitätsmengen, kann daher über mehrere Entitätsmengen verteilte Redundanzen gar nicht erkennen.
3.
+  
 
 
 
163
Aus einem Geburtsdatum lässt sich eindeutig das Sternzeichen herleiten.
Mittels der AHV-Nummer kann mit Hilfe von Registern eindeutig der Name des Inhabers bestimmt
werden. Dass aus der AHV-Nummer selbst der Name nicht hergeleitet werden kann ist dabei irrelevant. Entscheidend ist, dass mittels irgendeiner Methode der Name ermittelt werden kann.
Allein aus dem Namen kann der Vorname nicht eindeutig bestimmt werden.
Ist die Wagennummer bekannt, so kann unter Zuhilfenahme der Eintragungen ermittelt werden,
welcher Wagen und damit auch welcher Wagentyp diese Nummer trägt.
Anhang
164
15.6. Bearbeitungsaufgaben: 5. Normalisierung von Entitätsmengen im konzeptionellen Modell
15.6.1. Projektverwaltung
1. Normalform: Es existieren nur einfache Attributswerte.
Projektverwaltung
Mitarbeiter#
Name
Projekt#
1
2
2
3
3
Müller
Meier
Meier
Sieber
Sieber
1
2
3
1
2
Projektbezeichnung
Staudamm S3
Brücke B134
Tunnel T25
Staudamm S3
Brücke B134
StatusCode
A
B
B
A
B
StatusBezeichnung
aktiv
offeriert
offeriert
aktiv
offeriert
Tabelle 40: Attributskatalog Projektverwaltung in 1. Normalform
2. Normalform: Jedes nicht zum Entitätsschlüssel gehörige Attribut ist voll von diesem abhängig.
Mitarbeiter
Mitarbeiter#
1
2
3
Name
Müller
Meier
Sieber
Projekte
Projekt#
1
2
3
Projektbezeichnung
Staudamm S3
Brücke B134
Tunnel T25
StatusCode
A
B
B
StatusBezeichnung
aktiv
offeriert
offeriert
Projektmitarbeit
Mitarbeiter#
1
2
2
3
3
Projekt#
1
2
3
1
2
Tabellen 41: Attributskatalog Projektverwaltung in 2. Normalform
3. Normalform: Kein Attribut, das nicht zum Entitätsschlüssel gehört, ist transitiv von diesem abhängig.
Projekte
Projekt#
1
2
3
Projektstati
Projektbezeichnung
Staudamm S3
Brücke B134
Tunnel T25
StatusCode
A
B
B
StatusCode
A
B
StatusBezeichnung
aktiv
offeriert
Tabelle 42: Attributskatalog Projektverwaltung in 3. Normalform
Anhang
165
15.6.2. Buchhandelssystem
Bestellungen
Bestell_Nr
1
1
2
3
4
4
Bestell_Datum
4. März
4. März
6. März
7. März
7. März
7. März
Buch_Nr
232-41
343-21
534-45
231-55
232-41
232-41
Buch_Bez
Sinue und Echnaton
Besteller_Nr
1
1
2
1
3
4
Besteller
Fritz Müller
Fritz Müller
Hans Meier
Fritz Müller
Urs Schmid
Rita Gugolz
Tabelle 43: Attributskatalog Buchhandelssystem in 1. Normalform
Bestellungen
Bestell_Nr
1
2
3
4
Bestell_Datum
4. März
6. März
7. März
7. März
Besteller
Bestellungen / Besteller
Besteller_Nr
1
2
3
4
Besteller
Fritz Müller
Hans Meier
Urs Schmid
Rita Gugolz
Bücher
Buch_Nr
232-41
343-21
534-45
231-55
Besteller_Nr
1
2
1
3
4
Bestell_Nr
1
2
3
4
4
Bestellpositionen
Buch_Bez
Sinue und Echnaton
Bestell_Nr
1
1
2
3
4
Buch_Nr
232-41
343-21
534-45
231-55
232-41
Tabellen 44: Attributskatalog Buchhandelssystem in 2. Normalform
3. Normalform: Kein Attribut, das nicht zum Entitätsschlüssel gehört, ist transitiv von diesem abhängig:
Die Entitätsmengen sind bereits in 3. Normalform.
Anhang
166
15.6.3. Wagenvermietung
Wagen
Wagen_Nr
1
1
1
2
2
3
3
4
Kennzeichen
ZH 333 666
ZH 333 666
ZH 333 666
ZH 111 222
ZH 111 222
ZH 100 000
ZH 100 000
ZH 25 25 25
Wagentyp
Mercedes 190
Mercedes 190
Mercedes 190
Toyota MR2
Toyota MR2
Suzuki Swift
Suzuki Swift
Mercedes 190
Fr/km
0.80
0.80
0.80
0.75
0.75
0.50
0.50
0.80
Mieter_Nr
3
64
19
5
3
19
5
<NULL>
Datum
11.11
2.5
14.3
5.8
24.4
12.3
12.8
<NULL>
Preis
Total
160,00
160.00
400,00
560.00
200.00
760.00
82.50
82.50
150.00
232.50
200.00
200.00
50.00
250.00
<NULL>
<NULL>
Mieter
Mieter_Nr
3
3
64
5
5
19
19
Name
Maier
Maier
Meier
Meyer
Meyer
Meyr
Meyr
Total
160.00
310.00
400.00
82.50
132.50
200.00
400.00
Zahl_Datum
1.12
26.4
2.6
3.9
3.9
28.3
28.3
Zahl_Betrag
160.00
150.00
400.00
82.50
50.00
200.00
200.00
Rech_Nr
1
2
3
4
5
6
7
Tabellen 45: Attributskatalog Wagenvermietung in 1. NF
Bemerkungen:
 Der ursprüngliche Entitätsschlüssel beider Entitätsmengen ist nicht mehr eindeutig, so
dass in beiden Entitätsmengen der Entitätsschlüssel um geeignete Attribute erweitert
werden muss.
In der Entitätsmenge 'Wagen' wird der Entitätsschlüssel mit den beiden Attributen
'Mieter_Nr' und 'Datum' ergänzt, alle drei Attribute sind notwendig.
In der Entitätsmenge 'Mieter' gibt es kein geeignetes Attribut, so dass sogar ein neues Attribut eingefügt werden muss! Oben wurde das Attribut 'Rech_Nr' (numerisch
fortlaufend) eingeführt, in der Meinung, dass pro Mietwagen eine Rechnung erstellt
wird.
 Der Entitätsschlüssel der Entitätsmenge 'Wagen' enthält zum Teil NULL-Werte im
Schlüssel, was gemäss Entitätsintegrität verboten ist! Wir wollen diesen Zustand hier
vorübergehend erlauben, da dieser Umstand im folgenden Normalisierungsschritt
wieder verschwindet.
 Der Inhalt der Felder 'Total' in der Entitätsmenge 'Wagen' und in der Entitätsmenge
'Mieter' ist schwierig zu interpretieren. Diese Felder sollen im folgenden Schritt eliminiert werden, da die in ihnen enthaltene Information mit Hilfe der restlichen Daten
sowieso ermittelt werden kann und damit eher die Gefahr besteht, dass Widersprüche in den Daten entstehen. Die Normalisierung macht zu derartigen Situationen
auf der konzeptionellen Ebene keine Aussagen. Auf der internen Ebene ist es
durchaus denkbar, diese Felder aus Performance-Gründen bewusst in das Modell
aufzunehmen.
 Möglich und eigentlich auch die bessere Lösung wäre es, in der Entitätsmenge 'Wagen' ebenfalls das Attribut 'Rech_Nr' einzuführen (was die Normalisierung nicht
macht). Dann wäre 'Rech_Nr' der Entitätsschlüssel. Dies darum, weil durch die Felder
'Preis' und 'Zahl_Betrag' eigentlich eine weitere Beziehung zwischen den beiden Entitätsmengen hergestellt wird, die in den weiteren Schritten verloren geht. Sodass
Anhang
167
schlussendlich nicht mehr sicher festgestellt werden kann, welcher Wagen einer bestimmten Rechnung zugeordnet ist.
Hier spürt man ganz deutlich, dass die Normalisierung kein Allheilmittel ist. Sie muss
mit Bedacht angewendet werden. Wir wollen in den folgenden Schritten diese
Überlegungen aber weglassen und mit den oben gezeigten Entitätsmengen weiterarbeiten.
Wagen
Wagen_Nr Kennzeichen
Wagentyp
1
2
3
4
Mercedes 190
Toyota MR2
Suzuki Swift
Mercedes 190
ZH 333 666
ZH 111 222
ZH 100 000
ZH 25 25 25
Fr/km
0.80
0.75
0.50
0.80
Preise
Wagen_Nr Mieter_Nr
Datum
1
1
1
2
2
3
3
11.11
2.5
14.3
5.8
24.4
12.3
12.8
3
64
19
5
3
19
5
Preis
160.00
400.00
200.00
82.50
150.00
200.00
50.00
Mieter
Mieter_Nr
3
3
64
5
5
19
19
Name
Maier
Maier
Meier
Meyer
Meyer
Meyr
Meyr
Zahl_Datum
1.12
26.4
2.6
3.9
3.9
28.3
28.3
Zahl_Betrag
160.00
150.00
400.00
82.50
50.00
200.00
200.00
Rech_Nr
1
2
3
4
5
6
7
Bemerkungen:
 Aus der Entitätsmenge 'Wagen' in erster Normalform könnten theoretisch 7 Entitätsmengen in 2. Normalform abgeleitet werden. Die Entitätsschlüssel dieser Entitätsmengen wären:
1.
2.
3.
4.
Wagen_Nr
Mieter_Nr
Datum
Wagen_Nr, Mieter_Nr
5. Wagen_Nr, Datum
6. Mieter_Nr, Datum
7. Wagen_Nr, Mieter_Nr, Datum
 Es ist allerdings nicht sinnvoll, jede dieser Entitätsmengen zu bilden. Welche Entitätsmengen sollen nun gebildet werden? Es müssen jene Entitätsmengen gebildet
werden, deren Weglassen zu einem Informationsverlust führen würde. Oder umgekehrt: Aus den gebildeten Entitätsmengen muss sich die ursprüngliche Entitätsmenge in 1. Normalform wieder herleiten lassen. Dieser Entscheid ist nicht immer einfach und es treten in diesem Zusammenhang auch häufig Fragen über die abzubildende Realität auf.
Anhang
168
 Die Entitätsmenge Mieter kann die 2. Normalform nicht verletzen, da der Entitätsschlüssel aus nur einem Attribut besteht.
3. Normalform: Kein Attribut, das nicht zum Entitätsschlüssel gehört, ist transitiv von diesem abhängig.
Wagen
Wagen_Nr
1
2
3
4
Kennzeichen
ZH 333 666
ZH 111 222
ZH 100 000
ZH 25 25 25
Wagentyp
Mercedes 190
Toyota MR2
Suzuki Swift
Mercedes 190
Wagenpreise
Wagentyp
Mercedes 190
Toyota MR2
Suzuki Swift
Fr/km
0.80
0.75
0.50
Preise
Wagen_Nr
1
1
1
2
2
3
3
Mieter_Nr
3
64
19
5
3
19
5
Mieter
Mieter_Nr
3
64
5
19
Name
Maier
Meier
Meyer
Meyr
Datum
11.11
2.5
14.3
5.8
24.4
12.3
12.8
Preis
160.00
400.00
200.00
82.50
150.00
200.00
50.00
Rechnung
Mieter_Nr
3
3
64
5
5
19
19
Zahl_Datum
1.12
26.4
2.6
3.9
3.9
28.3
28.3
Zahl_Betrag
160.00
150.00
400.00
82.50
50.00
200.00
200.00
Rech_Nr
1
2
3
4
5
6
7
Bemerkungen:
 Die Entitätsmenge Wagen und die Entitätsmenge Mieter weisen je eine transitive
Abhängigkeit auf, diese wurden beseitigt (Wagen.WagentypWagen.Fr/km und
Mieter.Mieter_NrMieter.Name).
Anhang
169
15.7. Checkfragen: 6. Verbundinstrumente des konzeptionellen Modells
1.
 A) Es werden nicht zwei, sondern es wird nur eine Entitätsmenge verknüpft.
 B) Bei der Auflösung von mc:mc-Beziehungen entstehen keine rekursiven Verknüpfungen.
 C) Die dritte Normalform darf auf der konzeptionellen Ebene nicht verletzt werden, auch nicht durch
rekursive Beziehungen.
 D) Die Antwort ist korrekt.
 E) Zur Erstellung von Beziehungen werden immer Fremdschlüssel benötigt.
2.
 A)
Die Spezialisierung beschreibt einen Vorgang, der mehrere Entitätsmengen umfasst, nicht einen
Vorgang, der sich innerhalb einer einzelnen Entitätsmenge abspielt.
 B) Korrekt. Die Superentitätsmenge enthält dabei alle den Entitätsmengen gemeinsamen Attribute.
Die Subentitätsmengen erhalten die jeweils spezifischen Attribute.
 C) Selbstbezügliche Beziehungsmengen existieren nicht.
 D) Es entstehen ausschliesslich 1:c-Beziehungen.
 E) Bei der Hierarchie handelt es sich um 1:m-, bzw. 1:mc-Beziehungen, bei der Spezialisierung um
1:c-Beziehungen.
3.





A)
B)
C)
D)
E)
Falsch.
Falsch.
Falsch.
Korrekt. Die Stückliste kann ausschliesslich mittels der Aggregation gebildet werden.
Falsch.
1.
Jede Entität der untergeordneten Entitätsmenge ‘hat’ genau einen Vater in der übergeordneten
Entitätsmenge.
2. + Zur Ermöglichung der Beziehung wird in der untergeordneten Entitätsmenge der Fremdschlüssel eingefügt. Da pro Fremdschlüssel aber genau eine Entität referenziert werden kann, kann eine Entität
der untergeordneten Entitätsmenge nur genau eine Entität der übergeordneten Entitätsmenge referenzieren.
1.
1. +
1. +
/
2. -
Mittels einer Beziehungsstruktur können tatsächlich beliebig viele Entitätsmengen miteinander verknüpft werden. In der Praxis findet man sehr häufig den Fall, bei welchem zwei Entitätsmengen verknüpft werden.
Der Fremdschlüssel steckt immer in der untergeordneten Entitätsmenge. In dieser Entitätsmenge ist
er aber sicher nicht Entitätsschlüssel, ansonsten könnten die beiden Entitätsmengen zusammengefasst werden. Der Fremdschlüssel kann aber ganz oder teilweise Teil des Entitätsschlüssels sein.
1.
+  
 
 
 
2.
+






 
Bei der Spezialisierung werden die Subentitätsmengen, bei der Generalisierung die Superentitätsmenge gebildet. Man kann die beiden Vorgänge daher tatsächlich als ‘umgekehrt’ bezeichnen.
Es werden eine Super- oder mehrere Subentitätsmengen neu gebildet.
Korrekt.
Die zyklische Verknüpfung ist ohne Zusammenhang zur Spezialisierung/Generalisierung.
Bei der Aggregation werden zwei Fremdschlüssel in die untergeordnete Entitätsmenge eingebettet.
siehe Antwort oben..
Nicht nur die übergeordnete Entitätsmenge kann Attribute enthalten, auch die untergeordnete Entitätsmenge kann Attribute enthalten.
Aggregation und Generalisierung haben nichts gemeinsam.
Anhang
170
3.
+  
 
 
 
Anhang
Korrekt. Die Referenzierung des Fremdschlüssels erfolgt immer mittels Entitätsschlüssels der referenzierten Entitätsmenge.
Korrekt.
Sämtliche Eigenschaften (z.B. Name in der Superentitätsmenge Partner) werden auf die Subentitätsmengen vererbt (z.B. auf die Subentitätsmenge Angestellte).
Subentitäten ist immer genau eine Entität der Superentitätsmenge zugeordnet.
171
15.8. Bearbeitungsaufgaben: 6. Verbundinstrumente des konzeptionellen Modells
15.8.1. Liversys
Partner
Mieter
Eigentüm er
Liegenschaften
besitzen
im Besitz von
bestehen
aus
Eigentum sverhältnisse
m ieten
Häuser
Mieterverträge
m it
Ortsverzeichnis
um fassen
Mietverhältnisse
enthalten
Strassenverzeichnis
Mietobjekte
lokalisiert
an
Adressen
Figur 63: Erweitertes Relationenmodell von Liversys
Partner
Partner_Nr Name
6
14
18
35
Keller
Ott
Ruf
Zürcher
Vorname
Hans
Urs
Urs
Ralf
Mieter
Mieter_Nr
6
14
18
Verrechnungsweg
LSV
LSV
Rechnung
Eigentümer
Eigentümer_Nr
6
35
Abrechnungsmodus
monatlich
quartalsweise
Liegenschaften
Liegenschafts_Nr
1
2
Bezeichnung
Sonnenhof
Römertor
Wert
3'500'000
62'250'000
Anhang
172
Häuser
HausId
SonBlau
SonRot
Liegenschafts_Nr
1
1
Haus_Nr
4572
2134
Baujahr
93
95
Mietobjekte
Mietobjekt_Nr
2352
2353
2354
HausId
SonBlau
SonBlau
SonRot
Mietvertrags_Nr
10021
10021
10022
Beschreibung
2-Zimmer Wohnung
Garagenplatz
6½-Zimmer Wohnung
Anz_Zimmer
2
<NULL>
6½
Eigentumsverhältnisse
Eigentümer_Nr
6
35
35
Liegenschafts#
1
1
2
Mietverträge
Mietvertrags_Nr
10021
10022
Gültig_Ab_Datum
1. Mai
1. September
Mietzins
2'000,00
3'750,00
Mietverhältnisse
Mietvertrags_Nr
10021
10021
10022
Mieter_Nr
6
14
18
Ortsverzeichnis
PLZ
CH-8000
CH-8405
CH-9000
Ort
Zürich
Winterthur
St.Gallen
Strassenverzeichnis
StrassenId
ZHBach
WintiSunne
WintiLerchen
Strassenname
Bächliweg
Sunnewis
Im Lerchenweg
PLZ
CH-8000
CH-8405
CH-8405
Adressen
StrassenId
ZHBach
ZHBach
SGLerchen
Mietobjekt_Nr
2352
2353
2354
Strassen_Nr
23
23B
2
Adresstyp
Postadresse
Lage
Postadresse
Tabellen 48: Attributskatalog mit Beispieldaten zu Liversys
Anhang
173
In den Entitätsmengen Mieter und Eigentümer wurden für die Entitätsschlüssel die Namen Mieter_Nr und Eigentümer_Nr vergeben. Diese sind beide gleichzeitig auch Fremdschlüssel und referenzieren die Partner_Nr in der Entitätsmenge Partner. Es wäre auch denkbar, die beiden
Fremdschlüssel ebenfalls Partner_Nr zu nennen, inhaltlich würde sich dadurch nichts ändern.
Durch die Vergabe von neuen Namen ist allerdings in untergeordneten Entitätsmengen direkt
ersichtlich, welche Entitätsmenge diese referenzieren. So lässt sich z.B. in der Entitätsmenge
Mietverhältnis direkt ersehen, dass diese auf die Entitätsmenge Mieter und nicht die Entitätsmenge Partner verweist.
Anstatt die Entitätsmengen Partner, Mieter und Eigentümer 'mengenmässig' darzustellen, können diese auch wie folgt dargestellt werden:
Partner
können
sein
können
sein
Mieter
Eigentüm er
Figur 64: Spezialisierung der Entitätsmenge Partner
Partner
Mieter
Eigentüm er
Hauswarte
Liegenschaften
besitzen
im Besitz von
unterhalten
bestehen
aus
Eigentum sverhältnisse
Häuser
Mieterverträge
m it
Ortsverzeichnis
um fassen
enthalten
unterhalten
Mietverhältnisse
Strassenverzeichnis
Mietobjekte
lokalisiert
an
Adressen
Figur 65: Erweitertes Relationenmodell von Liversys ergänzt um Hauswarte
In der obigen Lösung können Hauswarte je nach Bedarf Häusern und/oder Mietobjekten zugeordnet werden. Falls Hauswarte auch Liegenschaften zugeordnet werden können müssen, würde auch zwischen Hauswarten und Liegenschaften eine Beziehung erstellt. In dieser Lösung
muss definiert werden, ob eine Beziehung zu einem Mietobjekt erlaubt ist, falls ein anderer
Hauswart bereits mit dem übergeordneten Haus des Mietobjekts verknüpft wurde und gegebenenfalls eine entsprechende Integritätsregel erstellt werden.
Anhang
174
Mieter
Mietverträge
m it
m ieten
Mieterverhältnisse
um fassen
Mietobjekte
Figur 66: Externes Schema 'Mutation von Mietverträgen'
Partner
können
sein
Eigentüm er
Figur 67: Externes Schema 'Mutation von Eigentümer'
Anhang
175
15.8.2. Transpo
Dispozentrale
Länder
Ortsverzeichnis
Partner
Filialen
aktueller Standort
aktuell gelagert in
im Besitz von
Auftraggeber
Fahrer
Em pfänger
Fahrzeugtypen
Aufträge
Transportwege
Auftragspositionen
Routen
Fahrerqualifikationen
Transportm ittel
AuftragspositionenRouten
Figur 68: Erweitertes Relationenmodell von Transpo
Bemerkungen:
 Im Datenmodell wurde keine Entitätsmenge für die Artikel gebildet. Ein Artikelstamm
ist dann sinnvoll, wenn durch die Transpo AG immer wieder die selben Artikel befördert werden. Dann könnten die interessierenden Eigenschaften (Attribute) der Artikel zentral verwaltet werden. Ein derartiger Entscheid kann in der Praxis nur in direkter Absprache mit dem Benutzer gefällt werden. Es wäre auch möglich, häufig
transportierte Artikel im Stamm zu erfassen und Einzelfälle speziell zu behandeln.
 In den Subentitätsmengen der Superentitätsmenge Partner wurde für den Fremdschlüssel, welcher die Entitätsmenge Partner referenziert (und gleichzeitig Entitätsschlüssel ist), ein eigener Name vergeben (z.B. Auftraggeber_Nr). Dadurch ist in Entitätsmengen, welche die Subentitätsmengen referenzierten (z.B. in Aufträge) sofort
ersichtlich, welche Subentitätsmenge referenziert wird. Allerdings ist in den Subentitätsmengen dadurch nicht mehr direkt ersichtlich, welches Attribut Fremdschlüssel
ist und die Entitätsmenge Partner referenziert. Diese Information muss im Attributskatalog zum Datenmodell explizit festgehalten werden.
 Die Materialnummer in der Entitätsmenge Auftragspositionen wird durch die Transpo
AG vergeben und wird nicht durch den Auftraggeber übermittelt.
Anhang
176
Partner
Partner_Nr
1
2
4
5
6
7
8
9
403
Name
Rufi AG
Flexi AG
Velos & Mofas
Filiale Russikon
Filiale St.Gallen
SVF
Müller
Filiale Zürich
Donate
Vorname
<NULL>
<NULL>
<NULL>
<NULL>
<NULL>
<NULL>
<NULL>
<NULL>
Mario
Strasse
Langackerstr. 12
Bächliweg 8
Bächliweg 112
Tüfiwis 4
Zürcherstr. 2
Grüntalstr. 25
Langweg 2
Usterstr. 2
Seeweg 2
Land
CH
CH
CH
CH
CH
CH
CH
CH
CH
PLZ
8001
8001
8001
8332
9000
9303
9003
8050
8052
Tel_Nr
071 - 25 40 90
01 - 363 89 56
01 - 363 20 40
01 - 955 05 00
071 - 25 40 93
071 - 38 34 19
071 - 23 78 70
01 - 565 55 66
01 424 45 95
Auftraggeber
Auftraggeber_Nr
1
Zahlungsstatus
ok
Empfänger
Empfänger_Nr
2
4
Ansprechpartner
Müller
Meier
Filialen
Filial_Nr
5
6
9
Domizil
RU
SG
ZU
Fahrer
Fahrer_Nr
8
403
Angestellt in_Filial_Nr
6
9
Ortsverzeichnis
Land
PLZ
Ortsname
CH
CH
CH
CH
CH
CH
CH
8001
8050
8052
8400
9000
9003
9303
Zürich
Zürich
Zürich
Winterthur
St. Gallen
St. Gallen
Wittenbach
Länder
Land
CH
Bezeichnung
Schweiz
Währung
SFr
Aufträge
Auftrags_Nr
Anhang
Auftraggeber_Nr
Auftragsd.
Abhold.
Rechnungs_Nr
Rechungsd. Zahlungsstatus
7721
1
12. Mai
2. Juni
4679
30. Juni
177
offen
Anhang
178
Auftragspositionen
Material
_Nr
Artikelbez.
Auftrags
_Nr
Empf
_Nr
Lieferd.
Anz.
23509
Schreibm
.
Fahrräder
7721
2
3
7732
12
14. Juni
14. Juni
23798
Gewicht/
Stück
0.4
12
8.3
Masse
Info
Kosten
30x20x15
Tel.
25.40
6
150x40x100
Post
23.60
6
Auftragspositionen-Routen
Material_Nr
23509
23509
23509
23798
Transportweg_Nr
Routen_Nr
1
4
5
6
7706
7707
7721
7721
Transportwege
Transportweg_Nr
Von
Nach
1
2
3
4
5
6
1
5
7
6
9
9
6
6
6
9
2
4
Fahrzeugtyp_Code
A
A
A
Z
C
C
Distanz
Kosten/kg/km
<NULL>
10.00
<NULL>
7.80
<NULL>
<NULL>
8.0
<NULL>
8.5
<NULL>
14.5
7.4
Routen
Routen_Nr
2341
Uhrzeit Datum
8:00 12. Juni
Fahrer_Nr
3
Transportmittel_Nr
1
Fahrzeugtypen
Fahrzeugtyp_Code
A
Bezeichnung
Fahrzeugkategorie
A
Fahrzeugkategorie B
Fahrzeugkategorie
C
Flugzeug
Zug
B
C
F
Z
Fahrerqualifikationen
Fahrer_Nr
Fahrzeugtyp_Code
3
3
8
A
C
A
Transportmittel
Transportmittel_Nr
1
2
3
Anhang
Transportmittelbezeichnung
LW 2-1, ZH 244 468
LW 2-1, ZH 295 4331
Zug D2709
Fahrzeugtyp_Code
A
A
Z
Standort_Filiale
Besitzt_Filiale
6
6
9
5
6
5
Lagerort
4
5
Flug SR 133
LK 233, SG 123 433
F
B
9
5
179
9
9
Tabellen 49: Attributskatalog mit Beispieldaten zu Liversys
Anhang
180
15.9. Checkfragen: 8. Integrität im konzeptionellen Modell
1.
 A) Die Anmeldung des Benutzers nennt sich Identifikation.
 B) Die Komprimierung hat keinen Zusammenhang mit der Authentisierung.
 C) Anhand der Identifikation und eines Kennwortes wird die Zugriffsberechtigung des Benutzers überprüft.
 D) Die Verdichtung hat keinen Zusammenhang mit der Authentisierung.
 E) Durch Verschlüsselung der Daten werden diese zwar vor unerwünschten Zugriffen geschützt, jedoch
ist diese Verschlüsselung ohne Zusammenhang zur Authentisierung.
2.





A)
B)
C)
D)
E)
Datenkonsistenz ist Teil der Datenintegrität.
Datensicherheit ist Teil der Datenintegrität.
Datenschutz ist Teil der Datenintegrität.
Referenzielle Integrität ist Teil der Datenkonsistenz.
Entitätsintegrität ist Teil der Datenkonsistenz.
1.
+








Anhang
Korrekt.
Korrekt.
Korrekt.
Korrekt.
181
15.10. Checkfragen: 9. Datenbanktechnik, Softwarekomponenten eines Datenbanksystems
1.




A)
B)
C)
D)
 E)
Hashing hat keinen Zusammenhang mit Netzwerk-Datenbankstrukturen.
Hashing verwendet für den Zugriff den Entitäts- oder Fremdschlüssel.
Mittels Hashing ist sequentielles Lesen nur sehr schwierig zu realisieren.
Korrekt. Meistens wird das Divisionsrest-Verfahren zur Bestimmung der Ziel-Blockadresse aus dem
Schlüsselwert verwendet.
Die Antwort hat keinen Zusammenhang mit der Frage.
2.
Mittels Before-Images werden Daten zurückgesetzt.
Die Logdatei protokolliert sämtliche Änderungen fortlaufend und unmittelbar, ein Wiederherstellen
der Logdatei ist damit überflüssig.
 C) Änderungen, welche vom Puffer noch nicht in den Externspeicher übertragen wurden, werden mittels After-Images nachträglich auf das Externspeichermedium geschrieben.
 D) Korrekte Antwort. Der Rollforward ist der Begriff für den unter C) beschriebenen Vorgang. C) ist die
bessere Antwort.
 E) After-Images protokollieren nicht nur Änderungen an den Metadaten, sondern Änderungen an
sämtlichen Daten.
3.
 A) Korrekte Antwort, beste Antwort siehe C).
 B) Korrekte Antwort, beste Antwort siehe C).
 C) Der Begriff Recovery umschreibt eine Vielzahl von Aktivitäten, um die Integrität der Daten im Fehlerfalle zu sichern. Die unter C) gegebene Definition ist sicherlich die umfassendste Definition.
 D) Korrekte Antwort, beste Antwort siehe C).
 E) Korrekte Antwort, beste Antwort siehe C).
4.
 A)
Der Zugriffspfad hat tatsächlich mit der physischen Speicherung der Daten zu tun. Allerdings nicht
mit der Speicherung der Daten selbst, sondern mit dem Zugriff auf die Daten.
 B) Der physische Zugriffspfad ist nicht Teil der konzeptionellen Modellierung.
 C) Die Beschreibung ist korrekt, der Zugriffspfad besteht vollständig aus redundanter Information. Dies
mag im ersten Moment erstaunen, ist aber auf den zweiten Blick leicht einzusehen.
 D) Der Zugriffspfad hat direkt nichts mit dem Logging zu tun, wohl aber müssen Änderungen am Zugriffspfad mit dem Logging des DBMS abgestimmt werden.
 E) Der Zugriffspfad ist zur Beschleunigung des Zugriffs auf die Daten gedacht. Der Zugriffspfad kann
den Zugriff auf die Daten um 10er-Potenzen beschleunigen. Intelligente Datenbanksysteme nutzen
den Zugriffspfad auch, wenn Informationen gesucht werden, die vollständig im Zugriffspfad abgelegt sind (z.B. kann ausschliesslich mittels eines Zugriffspfades für Namen ermittelt werden, wie viele
Kunden ‘Müller’ heissen).
5.
 A)
Je kleiner der Sperrbereich, desto kleiner die Wahrscheinlichkeit, dass unterschiedliche Benutzer den
selben Sperrbereich benötigen. Damit steigt die parallele Verarbeitung im System.
 B) Je kleiner der Sperrbereich, desto mehr Sperren fallen an (z.B. Sperren einer Relation oder Sperren
von 20 Tupeln). Damit steigt der Verwaltungsaufwand für das DBMS.
 C) Je kleiner der Sperrbereich, desto kleiner die Wahrscheinlichkeit, dass unterschiedliche Benutzer den
selben Sperrbereich benötigen. Damit sinkt tendenziell die Wahrscheinlichkeit eines Deadlocks.
 D) Die Anzahl Änderungen welche durch das Logging protokolliert werden müssen, ist unabhängig
von der Grösse des Sperrbereichs.
 E) Aussage E) ist die entgegengesetzte Antwort zur Aussage B).
6.
 A)
 A)
 B)
Falsch. Die Datenkonsistenz wäre nur sichergestellt, wenn für jede Lese-Operation ebenfalls ein
Exclusiv-Lock gesetzt würde. Ohne Sperren können gelesene Daten zur Laufzeit der Transaktion geändert werden, so dass eine inkonsistente Sicht auf die Daten entsteht.
 B) Die Datenkonsistenz ist unabhängig vom Datenbanksystem immer wichtig.
 C) Nach Verletzungen der Konsistenz ist es oft schwierig, meist unmöglich, den korrekten Zustand allein
aufgrund der Daten wieder herzustellen.
 D) Die Konsistenz kann nur dann garantiert werden, wenn alle gelesenen Daten vor dem eigentlichen
Lese-Zugriff durch eine unnötige Änderungsoperation exklusiv gesperrt werden.
 E) Falsch, siehe D).
Anhang
182
7.
 A)
Mittels Rollback können die Änderungsoperationen der Transaktion auf den Ausgangszustand zurückgesetzt werden.
 B) Die Änderungen der Transaktion werden in den Before- und After-Images protokolliert.
 C) Korrekte, beste Antwort.
 D) Während der Transaktion können bestimmte Konsistenzbedingungen verletzt sein (z.B. Ausgleich der
Soll- und Haben-Buchungen). Am Ende der Transaktion müssen aber alle Konsistenzbedingungen
wieder erfüllt sein. Können nicht alle Konsistenzbedingungen erfüllt werden, muss die Transaktion zurückgesetzt werden.
 E) Die Aussage ist korrekt, C) ist aber die bessere Antwort.
1.

A)

B)

C)

D)

E)

E)
Teil der Definition einer Konsistenzbedingung ist die Reaktionsregel.
2.

A)

B)

C)

D)
Der Checkpoint unterteilt das Log-Band (Archiv-Protokolldatei) in Abschnitte. Mittels Checkpoint lässt sich
sicherstellen, dass die Daten des Puffers in das externe Speichermedium übertragen wurden. Dadurch muss
nach einem Systemabsturz der Rollforward nicht mit der ganzen Protokolldatei, sondern erst ab dem
Checkpoint ausgeführt werden.
3.

A)

B)

C)

D)

E)
Das Recovery dient der Wiederherstellung eines konsistenten Datenbankzustandes. Mittels Rollback werden
Änderungen fehlerhafter, konsistenzverletzender Transaktionen aus der Datenbasis entfernt.
4.

A)

B)

C)

D)

E)
Das Sperrprotokoll stellt mittels Sperren auf Daten sicher, das keiner der parallel arbeitenden Benutzer eine
inkonsistente Sicht auf die Daten erhält.
5.

A)

B)

C)

D)

E)
Im Generationsprinzip werden mehrere Archivkopien zyklisch für die Datensicherung verwendet. Dadurch
sind einerseits ältere Datenbestände rekonstruierbar. Andererseits kann bei einem Speicherfehler auf der
aktuellsten Archivkopie wenigstens noch auf eine Vorgängerversion zurückgegriffen werden.
6.

A)

B)

C)

D)

E)
Einzig im pessimistischen Verfahren können Deadlocksituationen auftreten.
7.

A)

B)

C)

D)

E)
Im pessimistischen Verfahren kann garantiert werden, dass selbst bei höchster Last auf dem Datenbanksystem immer wieder Transaktionen erfolgreich abschliessen können.
8.

A)

B)

C)

D)

E)
Im Zeitstempelverfahren werden die Informationen über die Zugriffe bei den Daten selbst abgelegt und
nicht zentral in einer Tabelle verwaltet.
9.

A)

B)

C)

D)

E)

B)

C)

D)

E)
Siehe Antwort 8.
10.  A)
Im pessimistischen Verfahren werden die Sperren zentral in einer Tabelle (Lock-Tabelle) verwaltet.
11.  A)

B)

C)

D)

E)
Das After-Image enthält die Informationen, wie die Daten nach der Änderung aussehen.
12.  A)

B)

C)

D)

E)
Mittels Checkpoint kann bei einem Systemabsturz der Recovery-Aufwand reduziert werden. Dank dem
Checkpoint müssen nur jene Änderungen der Protokolldatei in die Datenbasis eingespiesen werden (Rollforward), welche nach dem Checkpoint ausgeführt wurden.
13.  A)

B)

C)

D)

E)
Die Transaktion bildet aus einzelnen Datenbankbefehlen eine atomare Operation.
14.  A)

B)

C)

D)

E)
Der Checkpoint veranlasst den Systempufferverwalter, sämtliche geänderten Pufferseiten in den Externspeicher zu schreiben.
Anhang
15.  A)

B)

C)

D)

183
E)
Die Transaktion bzw. die Transaktionsgrenzen steuern, ab und bis wann Sperren gesetzt und freigegeben
werden.
16.  A)

B)

C)

D)

E)
Die Entitätsmengenverwaltung übersetzt mengenorientierte Befehle in satzorientierte Befehle, die dem Entitätenverwalter übergeben werden.
17.  A)

B)

C)

D)

E)
Der Entitätsmengenverwalter hat die Aufgabe, die mengenorientierten Befehle in satzorientierte Befehle
umzusetzen. Dabei muss er den geeigneten Zugriffsweg unter Berücksichtigung der bestehenden Zugriffspfade ermitteln. Diese Aufgabe nimmt der Optimizer, eine Komponente des Entitätsmengenverwalters,
wahr.
18.  A)

B)

C)
D)

E)

D)

E)

D)

E)

Ein Synonym für den Entitätenverwalter ist Satzverwalter.
19.  A)

B)

C)
Der Systempufferverwalter verwaltet den Puffer.
20.  A)

B)

C)
Der Zugriffspfadverwalter ist für den B-Baum zuständig (der B-Baum ist ein Zugriffspfad).
1.
1. +
/
2. +
Da die Adresse des Datensatzes direkt aus dem Schlüsselwert berechnet wird, genügt im günstigen
Fall ein einziger Zugriff um den Datensatz zu finden. Schneller können Daten nicht gelesen werden.
Bei Kollisionen werden beim Hashing Überlaufbereiche mittels Adresszeigern angebunden.
2.
1. +
/
2. -
Baumstrukturierte Organisationsformen sind die Organisationsform für Datenbanksysteme.
Baumstrukturierte Organisationsformen bieten nicht für alle Zugriffe die beste Lösung. Sie sind aber
im Schnitt für alle Zugriffsarten sehr gut.
3.
1. +
Bei einem Systemabsturz müssen auch die Before-Images vorhanden sein, damit Änderungen unvollständig abgeschlossener Transaktionen zurückgesetzt werden können. Die Before-Images werden allerdings in der temporären Protokolldatei und nicht in der Archivprotokolldatei abgelegt.
In der Archivprotokolldatei dürfen nur After-Images von erfolgreich beendeten Transaktionen abgelegt werden. Und eine Transaktion gilt erst als abgeschlossen, wenn die After-Images in der Archivprotokolldatei abgelegt sind.
/
2. -
4.
1. + Das Datenbanksystem muss das Synchronisationsverfahren im Kern implementiert haben.
2. + Die korrekte Programmierung von Synchronisationsverfahren ist für Anwendungsentwickler praktisch
unmöglich.
5.
1. + Datenbanksysteme mit mengenorientierten Abfragen weisen meist einen Optimizer auf.
weil Die beiden Aussagen sind ohne Zusammenhang.
2. + In mengenorientierten Abfragen sind Hinweise auf den Zugriffspfad grundsätzlich unerwünscht. Entscheidet das Datenbanksystem selbständig, welcher Zugriffspfad verwendet wird, so können die
existierenden Zugriffspfade dynamisch den wechselnden Bedürfnissen angepasst werden (physische Datenunabhängigkeit).
6.
1. +
/
2. -
Transaktionen sind atomare Operationen und müssen daher immer vollständig oder gar nicht ausgeführt werden.
Konsistenzbedingungen stellen sicher, dass die Daten widerspruchsfrei gespeichert werden. Ein Datenverlust kann nicht durch Konsistenzbedingungen verursacht werden.
Anhang
184
1.
+  
 
 
 
2.
+  
 
 
 
3.
+  
 
 
 
4.
+






 
5.
+  
 
 
 
Anhang
Die Metadaten des Data Dictionary werden in Analogie zu den Benutzerdaten gespeichert und
verwaltet.
Die Informationen des Data Dictionary eignen sich dazu, die Führung und Ausrichtung der Aktivitäten zu steuern.
Data Dictionary-Systeme haben sich zusammen mit der Verbreitung von relationalen Datenbanksystemen durchgesetzt.
Die Informationen im Data Dictionary können für die Revision und im Datenschutz verwendet werden.
Hashing bedingt eine feine Abstimmung des Hashing-Algorithmus mit den vorhandenen bzw. zu erwartenden Datenbeständen. Bei stark dynamischen Datenbeständen ist Hashing daher eher ungeeignet.
Im Idealfall ist es tatsächlich möglich, einen gesuchten Datensatz mit einem einzigen Datenbankzugriff zu lesen. Falls aber Überlaufbereiche angelegt werden, können auch beim Hashing mehrere
Datenbankzugriffe nötig werden.
Korrekt.
Korrekt.
Da weder beim optimistischen noch beim Zeitstempel-Verfahren die Transaktion bei einem Zugriffskonflikt auf die Freigabe des angeforderten Datensatzes wartet, ist bei diesen eine Deadlocksituation nicht möglich.
Eine Deadlocksituation lässt sich durch Zurücksetzen einer einzelnen Transaktion auflösen.
Erst beim Auftreten von mindestens zwei Exclusive-Locks kann eine Deadlock-Situation entstehen.
Zur Entstehung eines Deadlocks genügt ein Datenobjekt. Haben zwei Transaktionen einen SharedLock auf das selbe Datenobjekt eingelöst und möchten beide Transaktionen diesen anschliessend
in einen Exclusive-Lock umwandeln, kommt es zum Deadlock.
Diese Marken enthalten den letzten Lese- bzw. Schreibzugriff.
Korrekt.
Die Transaktion darf nur Daten lesen, deren Schreibmarke einen früheren Zeitpunkt enthält als die
Transaktionsmarke.
Da die Verwaltung der Locktabelle in verteilten Datenbanken schwierig ist, bietet sich das Zeitstempelverfahren für verteilte Datenbanksysteme an.
Korrekt.
Falls keine andere Transaktion einen Shared-Lock auf dem Datenobjekt beansprucht, kann der
Shared-Lock in einen Exclusive-Lock umgewandelt werden.
Dies gilt auch für den Exclusive-Lock.
Ein Shared-Lock kann auch auf logischen Objekten, wie Datensätze und Relationen, ausgeführt
werden.
185
15.11. Bearbeitungsaufgaben: 9. Datenbanktechnik, Softwarekomponenten eines Datenbanksystems
15.11.1. Zugriffspfade
Index
Anz.
Zeiger
Zeigerlisten mit
Satznr.
Keller
1
6
Meier
1
1
Mori
1
4
Müller
2
2
Sieber
1
3
Wurster
1
7
5
Figur 69: Index und Zeigerlisten für die invertierte Liste
Segmentadresse
Daten
Adresszeiger
Segmentadresse
Überlaufbereich
0
7 37; Wurster; Zürich
1 64; Mori; Greifensee
8
2 2; Meier; Zürich
9
23; Müller; Russikon
Adresszeiger
7
3 101; Keller; Zürich
10
4
5 166; Sieber; Waldkirch
6 132; Müller; Winterthur
Tabelle 50: Segmente für Hashing
Anhang
186
37
23
132
2
64
101
166
Figur 70: B-Baum
Applikationen
Program m e
Dom änen
Datensichten
Entitätsm engen
DatensichtenVerwendungen
Attribute
Entitätsschlüssel
Sortierschl.
Frem dschlüssel
Frem dschlüsseldom äne
Attributskom binationen
Attributskom binationsstücke
Datensichtenkom binationen
Frem dschlüssel
Figur 71: Grafisches Datenmodell zur Metadatenbank-Aufgabe
Applikationen
Applikations_Id
Auftrag
Anhang
Beschreibung
Auftragsverwaltungssystem
Benutzer
Zugriffsrechte
187
Programme
Programm_Id
Kun_Mut
Applikations_Id
Auftrag
Art_Mut
Auftr_Mut
Auftrag
Auftrag
Beschreibung
Mutation der Kundendaten
Mutation der Artikeldaten
Mutation der Auftragsdaten
Autor
K. Meier
R. Müller
R. Müller
Entitätsmengen
Entitätsmengenname
Kunden
Artikel
Aufträge
Applikations_Id
Entitätsschlüssel
Auftrag
Auftrag
Auftrag
Prim_Kunden
Prim_Artikel
Prim_Aufträge
Datenmenge
1’394
29’343
392’099
Erzeuger
K. Meier
K. Meier
K. Meier
Attribute
Attributsname
Entitätsmengenname
Domäne
Obligatorisch Bezeichnung
Kund_Id
Name
Strasse
PLZ
Ort
Art_Id
Bez
Preis
Kund_Id
Art_Id
Menge
Datum
Preis
Kunden
Kunden
Kunden
Kunden
Kunden
Artikel
Artikel
Artikel
Aufträge
Aufträge
Aufträge
Aufträge
Aufträge
Id_Numerisch
Bezeichnung
Bezeichnung
Postleitzahl
Bezeichnung
Id_Numerisch
Bezeichnung
Betrag
Id_Numerisch
Id_Numerisch
Menge
Datum
Betrag
ja
ja
nein
nein
nein
ja
nein
ja
ja
ja
ja
nein
nein
Identifikation des Kunden
Name, Vorname des Kunden
Strassenname, -nummer
Postleitzahl
Ortschaft
Identifikation des Artikels
Bezeichnung des Artikels
Preis des Artikels
Auftraggeber
Artikel des Auftrages
Menge der verkauften Artikel
Auftragsdatum
Preis des Artikels (redundante Information aus der Entitätsmenge
Artikel)
Domänen
Domänen_Id
Datentyp
Grösse
Dezimalen
Id_Numerisch
Bezeichnung
Postleitzahl
Betrag
Menge
Datum
Numerisch
Alphanumerisch
Numerisch
Numerisch
Numerisch
Datum
8
40
5
11
8
<NULL>
0
<NULL>
0
4
0
<NULL>
Datensichten
View Name
Kunden
Artikel
Auftrag
Erzeuger
K. Meier
R. Müller
R. Müller
Anhang
188
Datensichtenverwendung
View Name
Kunden
Artikel
Auftrag
Kunden
Artikel
Programm_Id
Kun_Mut
Art_Mut
Auftr_Mut
Auftr_Mut
Auftr_Mut
letzter_Zugriff
1. März
1. März
20. Februar
20. Februar
20. Februar
Benutzer
Benutzer_Id
MARE
BRUNNER
Geburtsdatum
4. April
23. Dezember
Zugriffsrechte
Benutzer_Id
MARE
BRUNNER
BRUNNER
BRUNNER
View_Name
Kunden
Kunden
Artikel
Auftrag
Konsistenzbedingungs_Id
Auftrags_Preis
Entitätsmengenname
Aufträge
Auslöseregel
Update, Insert
Datensichtenkombinationen
Attributsname
Kund_Id
Name
Strasse
PLZ
Ort
Art_Id
Bez
Preis
Kund_Id
Name
Art_Id
Bezeichnung
Preis
Menge
Datum
Preis
Anhang
Entitätsmengenname
Kunden
Kunden
Kunden
Kunden
Kunden
Artikel
Artikel
Artikel
Aufträge
Kunden
Aufträge
Artikel
Artikel
Aufträge
Aufträge
Aufträge
View_Name
Kunden
Kunden
Kunden
Kunden
Kunden
Artikel
Artikel
Artikel
Auftrag
Auftrag
Auftrag
Auftrag
Auftrag
Auftrag
Auftrag
Auftrag
Prädikat
Reaktionsregel
Aufträge.Preis =
Reject
Artikel.Preis * Aufträge.Menge
189
Attributskombinationen
Attributskombinations_Id
Prim_Kunden
Prim_Artikel
Prim_Aufträge
Ref_Aufträge_Kunden
Ref_Aufträge_Artikel
Sort_Kunden_Name
Entitätsmengenname
Kunden
Artikel
Aufträge
Aufträge
Aufträge
Kunden
Attributskombinationsstücke
Attributskombinations_Id
Prim_Kunden
Prim_Artikel
Prim_Aufträge
Prim_Aufträge
Sort_Kunden_Name
Attributsname
Kund_Id
Art_Id
Kund_Id
Art_Id
Kund_Id
Art_Id
Name
Entitätsmengenname
Kunden
Artikel
Aufträge
Aufträge
Aufträge
Aufträge
Kunden
Fremdschlüssel
Fremdschlüssel
Fremdschlüsseldomäne
Prim_Kunden
Prim_Artikel
Tabellen 51: Attributskatalog mit Beispieldaten zur Metadatenbank
15.11.3. Deadlock im pessimistischen Verfahren
Ablaufplan
Fet1
Fet4
Fet6
Fet2
Ope4
Fet5
Ope2
Fet7
Ope5
Fet3
Ope1
Fet8
Ope6
Upd1
Upd2
Transaktionen:
Transaktion 1
BOT, Shared-Lock: a (ok)
Transaktion 2
Transaktion 3
BOT, Shared-Lock: a (ok)
BOT, Shared-Lock: e (ok)
Shared-Lock: b (ok)
Kein Lock
Shared-Lock: b (ok)
Kein Lock
Shared-Lock: c (ok)
Kein Lock
Exclusive-Lock: a (Waiting)
Shared-Lock: f (ok)
Kein Lock
Shared-Lock: a (ok)
Kein Lock und EOT
Exclusive-Lock: a (Waiting)
Tabelle 52: Effektiver Ablaufplan der drei Transaktionen
Anhang
190
Die Transaktion 3 kann vollständig ablaufen. Die Transaktionen 1 und 2 geraten in eine Deadlock-Situation, eine der Transaktionen muss zurückgesetzt werden. Daher ist der vorgeschlagene
Ablaufplan nicht möglich.
15.11.4. Locking im pessimistischen Verfahren
Transaktion 1
Transaktion 2
Transaktion 3
Ope1: BOT, Shared Lock: a
(ok)
Fetch a (1)
(ok)
Fetch a (1)
Ope1: BOT, Shared Lock: b
(ok)
Fetch b (2)
Ope2:
var1 := a * 2 (2)
Ope2: Shared Lock: b (ok)
Fetch b (2)
Ope2: Shared Lock: a (ok)
Fetch a (1)
Ope3: Exclusive Lock: a (ok)
(Waiting)
Ope3:
var3 := a - 1 (0)
Ope3:
Ope4:
var5 := a - 2 (-1)
var4 := b - 1 (1)
Ope4: Exclusive
Lock:
a
(Deadl.)
(Rollback Transaktion 3)
Ope5: Exclusive
Lock
a:
(Deadl.)
Ope1: BOT, Shared Lock: b
(ok)
Fetch b (2)
Ope3: Update a FROM var1
(2)
EOT
(ok)
Fetch a (2)
Ope2: Shared Lock: a (ok)
Fetch a (2)
Fetch b (2)
Ope3:
Ope3:
var5 := a - 2 (0)
var3 := a - 1 (1)
(Waiting)
Ope4:
var4 := b -1 (1)
Ope5: Exclusive
Lock:
a
(Deadl.)
Anhang
191
Ope4:
(0)
Update a FROM var5
Ope5:
var5 := b - 2 (0)
(ok)
(Waiting)
Ope6: Exclusive Lock: b (ok)
Update b FROM var5 (0)
EOT
Ope1:
Fetch a (0)
Fetch b (0)
Ope3:
var3 := a - 1 (-1)
Ope4:
var4 := b -1 (-1)
Update a FROM var3 (-1)
Ope6: Excluxive Lock: b (ok)
Update b FROM var4 (-1)
EOT
Tabelle 53: Ablauf der drei Transaktionen
Anhang
192
15.11.5. Ablaufplan
a: TA1, TA2, TA3:
1
TA1, TA3, TA2:
2
TA2, TA1, TA3:
1
TA2, TA3, TA1:
2
TA3, TA1, TA2:
4
TA3, TA2, TA1:
3
b: Feti, Fetj, Fetk stehen für die Operationen Fet1, Fet2 und Fet3, wobei Fet i nicht Fet1
(u.s.w.) entsprechen muss, d.h. die Reihenfolge der Operationen ist beliebig. Desgleichen für Updi, Updj und Updk, welche die Operationen Upd1, Upd2 und Upd3
repräsentieren.
Feti, Fetj, Fetk, Updi, Updj, Updk: 3*2*1*3*2*1
=
36 Möglichkeiten
Feti, Fetj, Updi, Fetk, Updj, Updk: 3*2*2*1*2*1
=
24 Möglichkeiten
Feti, Fetj, Updi, Updj, Fetk, Updk: 3*2*2*1*1*1
=
12 Möglichkeiten
Feti, Updi, Fetj, Fetk, Updj, Updk: 3*1*2*1*2*1
=
12 Möglichkeiten
Feti, Updi, Fetj, Updj, Fetk, Updk: 3*1*2*1*1*1
=
6 Möglichkeiten
=
90 Möglichkeiten
TOTAL
c: Ja, z.B. produziert der Ablaufplan Fet1, Fet2, Fet3, Upd3, Upd2, Upd1 das selbe Resultat (1) wie zwei der sechs möglichen Reihenfolgen (siehe a) ) der Transaktionen. Es
muss dabei aber klar hervorgehoben werden, dass dies purer Zufall ist und nur Dank
dem Initialwert 0 von a möglich ist. Was würde passieren, wenn der Initialwert von a
z.B. 10 wäre? Würden die Resultate dann abweichen, so ist der Ablaufplan nicht
konsistenzerhaltend, serialisierbar.
d: Ja, z.B. der Ablaufplan Fet1, Fet3, Upd1, Upd3, Fet2, Upd2 ist serialisierbar (er ist zu
TA1, TA3, TA2 äquivalent), kann aber bei einem System mit zweiphasigem Locking
nicht auftreten. In diesem Fall würde Fet1 und anschliessend Fet3 für a Shared-Lock
verlangen. Mit Upd1 würde Transaktion 1 versuchen Exclusive-Lock auf a zu erhalten, muss aber warten, bis Transaktion 2 die Shared-Lock Anforderung auf a wieder
freigibt. Mit Upd3 verlangt nun Transaktion 2 auch noch Exclusive-Lock, muss aber
warten, bis Transaktion 1 abschliesst, es resultiert ein Deadlock!
Anhang
193
15.11.6. Transaktionslogik und Programme
In beiden Programmen werden die Transaktionsgrenzen ganz am Anfang und ganz am Ende
des Programmes gesetzt. Dadurch werden nach und nach immer mehr Objekte gesperrt und
erst ganz am Ende des Programmes wieder freigegeben. Zielsetzung muss es aber sein, möglichst wenig Objekte möglichst kurz zu sperren. Es muss daher für beide Programme geprüft
werden, ob die Transaktionsgrenzen nach innen verschoben werden können oder ob die Transaktion in mehrere Teiltransaktionen zerlegt werden kann, ohne dass...
 bei einem Fehler oder Absturz des Programmes Daten anderer Transaktionen verloren gehen oder Daten widersprüchlich gespeichert werden oder dass
 für parallel arbeitende Transaktionen inkonsistente Sichten auf die Daten entstehen.
Im Umrechnungs-Programm kann allenfalls sogar ganz auf die Definition einer Transaktion verzichtet werden. Falls sichergestellt werden kann, dass bei einem Absturz des Programmes das
Programm erneut gestartet wird, ist mit keinen Datenverlusten zu rechnen. Kann zusätzlich gewährleistet werden, dass keine anderen Programme die Daten gleichzeitig verwenden, dann
besteht auch nicht die Gefahr der inkonsistenten Sicht.
Beim Programm für den Kontoübertrag zeigt sich eine gänzlich andere Situation. Die Lese- und
Schreibzugriffe auf die Datenbankobjekte dürfen nur als Ganzes ausgeführt werden. Die Eingaben des Benutzers können aber allenfalls ausserhalb der Transaktion platziert werden. Dadurch wird die Transaktion deutlich kürzer, denn die Eingaben durch den Benutzer, welche in
der Regel lange dauern, liegen jetzt ausserhalb.
* Dieses Programm liest die Währung, zwei Konti mit identischer Währung und
* einen Betrag ein und überträgt diesen Betrag vom ersten zum zweiten Konto.
DECLARE währung,konto_1,konto_2,bu_betrag
INPUT währung,bu_betrag
INPUT konto_1,konto_2;
READ FIRST Währung FOR Währung.währ_bez = währung
IF Währung.währ_bez = währung
BEGIN TRANSACTION
Konto.betrag - bu_betrag < Konto.min_betrag
ROLLBACK;
ELSE
ENDIF;
Konto.betrag + bu_betrag < Konto.min_betrag
ROLLBACK;
ELSE
END TRANSACTION;
ELSE
ERROR 'Währung nicht gefunden';
ENDIF;
OR
- bu_betrag;
OR
+ bu_betrag;
Figur 72: Programm Kontoübertrag mit Fremdwährung
Anhang
194
15.12. Checkfragen: 10. Internes Datenmodell
1.
+  
 
 
Die effiziente Ausführungsgeschwindigkeit ist eines der wichtigsten Kriterien beim Herleiten des internen Schemas.
Zwar steht die Anforderung eines minimalen Speicherbedarfs im Gegensatz zur effizienten Ausführungsgeschwindigkeit die Kunst bei der Herleitung des internen Schemas ist, derartige widersprüchliche Zielsetzungen zu berücksichtigen.
Die Zielsetzung von minimalem Speicherbedarf und wenig Redundanz gehen Hand in Hand.
Im internen Schema werden explizit datenbankspezifische Eigenschaften berücksichtigt.
+




Korrekt.
Korrekt.
Korrekt.
Korrekt.
 
2.




Anhang
195
15.13. Checkfragen: 11. Verteilung von Daten
1.
+  
 
 
 
Korrekt.
Ortstransparenz stellt sicher, dass der Benutzer/Entwickler von der effektiven Verteilung der Daten
keine Kenntnis nimmt.
Bei Fragmenten handelt es sich nicht um Kopien, sondern um Teile von Entitätsmengen, welche verteilt gespeichert werden.
Diese Frage ergibt keinen Sinn. Siehe 2. und 3. Antwort.
Anhang
196
15.14. 12. Fallbeispiel TTW
15.14.1. Ist-Analyse: Datenmodell zur Anwendung TravelSys ermitteln (BottomUp)
15.14.1.1. Ermittlung des Datenmodells zur Anwendung TravelSys
Kunden
Reisen
Buchungen
Preise
Rechnungen
Figur 73: Datenmodell Ist-Zustand TTW
Eine Rechnung kann mehrere Reisen eines Kunden umfassen, im Maximum sind allerdings nur 4
Reisen pro Rechnung möglich. Für jeden Fremdschlüssel MUSS genau eine Linie im grafischen
Modell eingetragen werden. Daher werden zwischen Rechnungen und Buchungen 4 Beziehungen gezogen.
Kunden
Attributsname:
Kunden#
Name
Adresse_1
Adresse_2
Land
PLZ
Ort
Nationalität
Rechnungs_Saldo
Wertebereich:
Numeric(10)
Character(20)
Character(20)
Character(20)
Character(3)
Numeric(6)
Character(20)
Character(3)
Numeric(12.2)
Beschreibung:
Künstliche Kunden-Nummer
Name des Kunden
Adresslinie 1 des Kunden
Adresslinie 2 des Kunden
Land (ISO) der Kundenadresse
Eindeutige Postleitzahl der Kundenadresse
Ortsbezeichnung der Kundenadresse
Nationalität des Kunden
Aktuell offener Rechnungssaldo des Kunden
Wertebereich:
Numeric(10)
Character(30)
Numeric(3)
Character(50)
Character(50)
Character(50)
Character(50)
Character(50)
Numeric(10.2)
Numeric(10.2)
Beschreibung:
Künstliche Nummer der angebotenen Reise
Bezeichnung der Reise, z.B. 'USA Western Ride'
Dauer der Reise bei fixer Reisedauer
Name des Hotels (bei einfachen Hotelbuchungen)
Transportmittel des Kunden zum Reisestartort
Startort der Reise
Transportmittel des Kunden zur Heimreise ab Endeort
Endeort der Reise
Durchschnittliche Einnahmen/Kunde zu dieser Reise
Durchschnittliche Ausgaben/Kunde zu dieser Reise
Reisen
Attributsname:
Reise#
Bezeichnung
Dauer
Hotel
Reisemittel_Start
Startort
Reisemittel_Ende
Endeort
Einnahmen
Ausgaben
Anhang
197
Buchungen
Attributsname:
Buchungs#
Kunden#
Reise_Datum
Reise#
Anzahl_Nächte
Anzahl_Personen
Zimmergrösse
Verpflegung
Preis_effektiv
Wertebereich:
Numeric(10)
Numeric(10)
Date
Numeric(10)
Numeric(3)
Numeric(3)
Numeric(2)
Character(4)
Numeric(10.2)
Beschreibung:
Künstliche Buchungs-Nummer
 Kunden.Kunden#, Kunde, der die Reise unternimmt
Startdatum der Reise
 Reisen.Reise#, Nummer der gebuchten Reise
Anzahl der gebuchten Nächte
Anzahl der teilnehmenden Personen
Gebuchte Zimmergrösse (z.B. Doppelzimmer)
Gebuchte Verpflegung (z.B. 'VP' für Vollpension)
Effektiv bezahlter Preis (d.h. bereits unter Berücksichtigung von Preisreduktionen)
Attributsname:
Wertebereich:
Reise#
Datum_Start_Fenster
Anzahl_Nächte
Zimmergrösse
Verpflegung
Preis
Woche_Start_Fenster
Numeric(10)
Date
Numeric(3)
Numeric(2)
Character(4)
Numeric(10.2)
Numeric(2)
Beschreibung:
 Reisen.Reise#, Nummer der Reise
Datum, ab welchem der Preis gilt
Anzahl Nächte, für welcher der Preis gilt
Zimmergrösse, für welche der Preis gilt
Verpflegung, für welche der Preis gilt
Standardpreis (für Vorschlag in der Buchung )
Wochen-Nummer, ab welcher der Preis gilt
Preise
Rechnungen
Attributsname:
Rechnungs#
Rechnungsdatum
Kunden#
Rechnungsbetrag
Rechnungscode
Rechnungscode_Text
Buchungs#[4]
Wertebereich:
Numeric(10)
Date
Numeric(10)
Numeric(10.2)
Character(2)
Character(20)
Numeric(10)
Beschreibung:
Künstliche Rechnungsnummer
Datum der Rechnungsstellung
 Kunden.Kunden#, Kunde, der die Reise bezahlt
Rechnungsbetrag (ev. Teil- bzw. Sammelrechnung)
Hält den Status der Rechnung fest
Text zum Rechnungscode
 Buchungen.Buchungs#, hält fest, für welche Buchungen die Rechnung erstellt wurde. Bei Sammelrechnungen werden mehrere Einträge vorgenommen
(Wiederholungsgruppe), je verrechneter Buchung ein
Eintrag
Tabellen 54: Dateistruktur Ist-Zustand TTW
Anhang
198
15.14.1.2. Normalisierung des Datenmodells
1. Normalform
Die Entitätsmenge Rechnungen enthält eine Wiederholungsgruppe. Diese wird eliminiert, indem
die sie durch ein einzelnes Attribut ersetzt wird und je Eintrag in der Wiederholungsgruppe eine
Entität in die Entitätsmenge eingetragen wird. Beachten Sie, dass der Entitätsschlüssel um das
Attribut der Wiederholungsgruppe erweitert wird.
Das mehrfache Einfügen des selben Attributs in die Entitätsmenge (z.B. Buchungs#1, Buchungs#2, ...) ist für die Erstellung der 1. Normalform i.d.R. nicht zulässig, da bei unbegrenzten Wiederholungsgruppen nicht unbegrenzt viele Attribute eingefügt werden können. Dieser Lösungsansatz ist ausserdem grundsätzlich zu vermeiden, da hierdurch die Anzahl der Wiederholungen fest vorgegeben würde, was eine unerwünschte und neue Einschränkung zur Folge
hätte.
Rechnungen
Attributsname:
Rechnungs#
Rechnungsdatum
Kunden#
Rechnungsbetrag
Rechnungscode
Rechnungscode_Text
Buchungs#
Beschreibung:
 Kunden.Kunden#
 Buchungen.Buchungs#
Tabelle 55: Entitätsmenge Rechnungen in 1. Normalform
2. Normalform
Die Entitätsmenge Preise enthält ein Attribut, welches nicht voll funktional abhängig vom Entitätsschlüssel ist und verletzt daher die 2. Normalform. Dies ist das Attribut Woche_Start_Fenster,
welches funktional abhängig vom Teilschlüssel Datum_Start_Fenster ist. Im Normalfall würde man
dieses Attribut berechnen; der Normalisierung wegen normalisieren wir diese Entitätsmenge.
Preise
Attributsname:
Reise#
Datum_Start_Fenster
Anzahl_Nächte
Zimmergrösse
Verpflegung
Preis
Beschreibung:
 Reisen.Reise#
 Wochennr.Datum
Wochennr.
Attributsname:
Datum
Wochennummer
Beschreibung:
Tabellen 56: Entitätsmenge Preise in 2. Normalform
Die Entitätsmenge Rechnungen verletzt ebenfalls die 2. NF. Die Attribute Rechnungsdatum, Kunden#, Rechnungsbetrag, Rechnungscode und Rechnungscode_Text sind funktional abhängig
vom Teilschlüssel Rechnungs#.
Anhang
199
Rechnungen
Attributsname:
Rechnungs#
Rechnungsdatum
Kunden#
Rechnungsbetrag
Rechnungscode
Rechnungscode_Text
Beschreibung:
 Kunden.Kunden#
Rechnungen-Buchungen
Attributsname:
Rechnungs#
Buchungs#
Beschreibung:
 Rechnungen.Rechnungs#
 Buchungen.Buchungs#
Tabellen 57: Entitätsmenge Rechnungen in 2. Normalform
3. Normalform
Die Entitätsmenge Kunden verletzt die dritte Normalform. Das Attribut Ort ist transitiv abhängig
von den Nichtschlüsselattributen Land und PLZ.
Kunden
Attributsname:
Kunden#
Name
Adresse_1
Adresse_2
Land
PLZ
Nationalität
Rechnungs_Saldo
Beschreibung:
 Ortschaften.Land (zusammen mit der PLZ)
 Ortschaften.PLZ (zusammen mit dem Land)
Ortschaften
Attributsname:
Land
PLZ
Ort
Beschreibung:
Tabellen 58: Entitätsmenge Kunden in 3. Normalform
Die Entitätsmenge Rechnungen verletzt die 3. Normalform. Das Attribut Rechnungscode_Text ist
transitiv abhängig vom Nichtschlüsselattribut Rechnungscode.
Rechnungen
Attributsname:
Beschreibung:
Rechnungs#
Rechnungsdatum
Kunden#
Rechnungsbetrag
Rechnungscode
 Kunden.Kunden#
 Rechnungscode.Rechnungscode
Anhang
200
Rechnungscode
Attributsname:
Rechnungscode
Rechnungscode_Text
Beschreibung:
Tabellen 59: Entitätsmenge Rechnung in 3. Normalform
Ortschaften
Kunden
Rechnungscode
Reisen
Buchungen
Rechnungen
RechnungenBuchungen
Figur 74: Datenmodell TTW in 3. Normalform
Anhang
Wochennr.
Preise
201
15.14.2. Soll-Konzept: Datenmodell mit neuen Anforderungen ergänzen (TopDown)
15.14.2.1. Strukturierung der Reisen, Aggregation (Part-Of-Struktur / Stückliste)
Im Folgenden wird nur der für diese Teilaufgabe relevante Teilausschnitt angegeben. Die Gliederung der Reise in Unterreisen entspricht einer Stückliste bzw. Aggregation.
Reisen
übergeordnete
Reise
untergeordnete
Reise
Reisestruktur
Figur 75: Reisestruktur mittels Aggregation
Reisen
Attributsname:
Reise#
Bezeichnung
Dauer
Hotel
Reisemittel_Start
Startort
Reisemittel_Ende
Endeort
Einnahmen
Ausgaben
Beschreibung:
Reisestruktur
Attributsname:
Reise_Struktur#
Reisefolge#
Überg._Reise
Unterg._Reise
Beschreibung:
 Reisen.Reise#
 Reisen.Reise#
Tabellen 60: Entitätsmengen zum Festhalten der Reisestruktur mittels Aggregation
Könnte eine Reise nur ein einziges Mal als Teilreise einer Reise auftreten, so ist auch folgender
Ansatz mittels Rekursion möglich (was für TTW nicht gilt):
Reisen
übergeordnet
e Reise
Figur 76: Reisestruktur mittels Rekursion
Anhang
202
Reisen
Attributsname:
Reise#
Überg._Reise
Bezeichnung
Dauer
Hotel
Reisemittel_Start
Startort
Reisemittel_Ende
Endeort
Einnahmen
Ausgaben
Beschreibung:
 Reisen.Reise#
Tabelle 61: Entitätsmengen zum Festhalten der Reisestruktur mittels Rekursion
Falsche Lösung: Folgende Lösungsvariante ist hingegen unter keinen Umständen zulässig:
Reisen
Reisestruktur
übergeordnet
e Reise
Figur 77: Falsche Lösung zur Reisestruktur
Reisen
Attributsname:
Reise#
Bezeichnung
Dauer
Hotel
Reisemittel_Start
Startort
Reisemittel_Ende
Endeort
Einnahmen
Ausgaben
Beschreibung:
Reisestruktur
Attributsname:
Reise#
Teil_Reise#
Reisefolge#
Beschreibung:
 Reisen.Reise#
 Reisestruktur.Reise#
Tabellen 62: Falsche Lösung zum Festhalten der Reisestruktur
Das Fremdschlüsselattribut Reisestruktur.Teil_Reise# basiert auf dem Attribut Reisestruktur.Reise#;
d.h. im Attribut Reisestruktur.Teil_Reise# sind nur Werte erlaubt, welche im Attribut Reisestruktur.Reise# auftreten. Im Attribut Reisestruktur.Reise# treten aber nur die Nummern jener Reisen
auf, die untergeordnete Reisen haben. Damit würde in diesem Fall die referentielle Integrität
(Fremdschlüssel) auf jeden Fall verletzt.
Anhang
203
Ausserdem muss der Fremdschlüssel den gesamten Entitätsschlüssel der referenzierten Entitätsmenge beinhalten. Im gegebenen Fall ist der Fremdschlüssel aber selbst Teil des Entitätsschlüssels! Er kann aber nie vollständig in sich selbst enthalten sein. Der Fremdschlüssel kann daher nicht korrekt gebildet werden.
Für das weitere Vorgehen muss die erste Variante angewandt werden. Das ergänzte Datenmodell sieht wie folgt aus:
Ortschaften
Kunden
Rechnungscode
Reisen
Buchungen
Rechnungen
Wochennr.
Preise
Reisestruktur
RechnungenBuchungen
Figur 78: Datenmodell mit Reisestrukturierung
Anhang
204
15.14.2.2. Zeitabhängige Daten und Varianten von Daten in Datenmodellen
1. Variante, betroffene Entitätsmengen mit Datumsattribut ergänzen: Die Entitätsmenge Reisen
wird mit dem Attribut Reise_Datum (Teil des Entitätsschlüssels) erweitert. Der Entitätsschlüssel der
Entitätsmenge Reisen setzt sich danach aus den Attributen Reise# und Reise_Datum zusammen.
Ausserdem muss das Reise_Datum auch in sämtliche abhängigen Entitätsmengen der Reisen
eingefügt werden, da diese Entitätsmengen den Entitätsschlüssel der Entitätsmenge Reisen als
Fremdschlüssel enthalten. Für jedes Reisedatum wird in der Entitätsmenge Reisen ein Eintrag erstellt (inkl. Unterreisen). Die allg. Reisebeschreibung bleibt unverändert mit leerem Datumsfeld
(allenfalls mit qualifizierendem Attribut ergänzen) als Rahmen für den Kopiervorgang bestehen.
Diese veränderte Entitätsmenge Reisen verletzt die 2. Normalform, da sämtliche Nichtschlüsselattribute lediglich vom Teil-Entitätsschlüssel Reise# abhängig sind. Würde man die veränderte
Entitätsmenge Reisen sowie sämtliche abhängigen Entitätsmengen normalisieren, so erhält man
in diesem Fall (dies gilt nicht immer) etwa die selbe Lösung wie bei der 2. Variante!
2. Variante, betroffene Entitätsmengen kopieren und mit Datumsattribut ergänzen: Die Daten
(mit Datum) werden nicht in den selben, sondern in separaten Entitätsmengen geführt. Dadurch müssen auch alle bestehenden Beziehungen zu den verdoppelten Entitätsmengen frisch
überdacht werden. Die Lösung im Überblick:
Ortschaften
Grundreisen
Kunden
Rechnungscode
Reisen
Buchungen
Rechnungen
Wochennr.
Preise
Grundreisestruktur
Reisestruktur
RechnungenBuchungen
Figur 79: Datenmodell mit Reisestrukturierung und Zeitvarianten
Betrachtet man die Entitätsmengen Reisestruktur und Grundreise-Struktur im Detail (siehe unten),
so fällt auf, dass diese, abgesehen von der unterschiedlichen Bezeichnung des Attributs Reise#,
identisch sind. Würde man sicherstellen, dass in Reisen und Grundreisen nicht identische Nummern für die Reise# bzw. Grundreise# verwendet werden, könnten die Entitätsmengen Reisestruktur und Grundreise-Struktur zusammengelegt werden. In diesem Fall muss überlegt, werden welche Vor- und Nachteile beim Zusammenlegen der Entitätsmengen für die zu realisierende Anwendung, basierend auf einem bestimmten DBMS, entstehen (d.h., diese
Überlegungen werden erst bei der Ableitung des physischen Schemas gemacht). Auf der konzeptionellen Ebene (auf welcher wir uns zur Zeit befinden) ist die gezeigte Lösung sicher die bessere Lösung, da diese einen höheren Erklärungswert hat. Folgende Entitätsmengen sind neu oder wurden verändert:
Anhang
205
Grundreisen
Attributsname:
Grundreise#
Bezeichnung
Dauer
Hotel
Reisemittel_Start
Startort
Reisemittel_Ende
Endeort
Einnahmen
Ausgaben
Beschreibung:
Grundreisestruktur
Attributsname:
Grundreise_Struktur#
Reisefolge#
Überg._Reise
Unterg._Reise
Beschreibung:
 Grundreise.Grundreise#
Reisen
Attributsname:
Reise#
Grundreise#
Reisedatum
Beschreibung:
Reisestruktur
Attributsname:
Reise_Struktur#
Reisefolge#
Überg._Reise
Unterg._Reise
Beschreibung:
 Reise.Reise#
 Reise.Reise#
Preise
Attributsname:
Grundreise#
Datum_Start_Fenster
Anzahl_Nächte
Zimmergrösse
Verpflegung
Preis
Beschreibung:
 Wochennr.Datum
Buchungen
Attributsname:
Buchungs#
Kunden#
Reise#
Anzahl_Nächte
Anzahl_Personen
Zimmergrösse
Verpflegung
Preis_effektiv
Beschreibung:
(neu ohne Reisedatum)
 Kunde.Kunden#
 Reise.Reise#
Tabellen 63: Entitätsmengen mit Reisestrukturierung und Zeitvarianten
Anhang
206
Vor- und Nachteile der Variante 1 gegenüber Variante 2 (für die folgenden Aufgabenschritte
gehen wir davon aus, dass die 2. Variante gewählt wurde):
 Verständlichkeit des Datenmodells
 Redundanzen, da Attribute in der Entitätsmenge Reisen mehrfach geführt werden
(dies kann in anderen Situationen durchaus erwünscht sein.
 Geringere Anzahl Entitätsmengen
 Ev. einfachere Programmstrukturen
.
…
Varianten von Reisen: Das Führen von individuellen Varianten von Reisen ist in beiden Modellen
bereits ohne Änderung möglich. Es muss lediglich die applikatorische Möglichkeit geben, auch
die Struktur von individuellen Reisen zu bearbeiten. Lassen sich Varianten nicht direkt im Datenmodell ablegen, so muss i.d.R. an der entsprechenden Stelle die Hierarchie um eine Stufe vergrössert werden und die Entitätsmenge Variante zwischengeschaltet werden.
15.14.2.3. Mitarbeiter-Stamm, Spezialisierung/Generalisierung
In diesem Schritt werden die Entitätsmengen Mitarbeiter und Partner eingeführt. Es muss lediglich überlegt werden, wie festgehalten wird, welches mögliche und welches die effektiven Reiseleiter einer Reise sind. Bei den möglichen Reiseleitern muss eine weitere Entitätsmenge eingeführt werden, da es sich hier um eine m:m-Beziehung handelt. Der effektive Reiseleiter lässt sich
direkt, ohne weitere Entitätsmenge festhalten.
Anhang
207
Ortschaften
Partner
Kunden
Mitarbeiter
Grundreisen
m ögliche Reiseleiterzuteilungen
Wochennr.
Preise
effektiver
Reiseleiter
Reisen
Rechnungscode
Buchungen
Rechnungen
Grundreisestruktur
Reisestruktur
RechnungenBuchungen
Figur 80: Datenmodell mit Spezialisierung/Generalisierung
Verbundinstrumente im Datenmodell:
Hierarchie:
Beziehungsmenge:
Spezialisierung/Generalisierung:
Aggregation:
Rekursion:
Wertetabelle:
Partner - Kunden - Rechnungen
Mitarbeiter - mögl. Reiseleiter - Grundreisen
Kunden und Mitarbeiter generalisiert zu Partner
Reisen - Reisestruktur
kein Beispiel in der Lösung
Rechnungscode
15.14.3. Vorgehensentscheid Dateiverwaltung oder DBMS
Der Vorgehensentscheid wird aufgrund eines Kriterienkataloges, dessen Gewichtung und Bewertung gefällt. Um eine bessere Übersichtlichkeit der Kriterien zu erreichen, sollten diese hierarchisch gegliedert werden. Mögliche Kriterien sind (Auswahl):
 Aufwand Entwicklung und Wartung
 Verfügbare Rechnerleistung
 Flexibilität
Anhang
208
 EDV-technisches Know-How
 Integritätsanforderungen (insbesondere im Mehrbenutzerbetrieb)
 …
15.14.4. Ableiten des internen Schemas, Bestimmen der physischen Speicherorganisation
15.14.4.1. Internes Schema
Mögliche Unterlagen für die Ableitung des internen Schemas (und damit der Denormalisierung
des konzeptionellen Schemas) sind:
 Menge der Entitäten pro Entitätsmenge
 Menge der Elemente pro Beziehungsmenge
 Erwartete Zuwachsraten der Entitätsmengen
 Datensatzgrössen
 Zugriffshäufigkeit auf Attribute
 Häufigkeit der Anwendung von Zugriffswegen
 …
Mögliche Einflüsse auf das konzeptionelle Datenmodell (grundsätzlich sollte versucht werden,
möglichst nahe am voll normalisierten konzeptionellen Datenmodell zu bleiben):
 Erstellen von Zugriffspfaden für die häufigst verwendeten Zugriffswege
 Splitten von einzelnen Entitätsmengen
 Zusammenlegen von einzelnen Entitätsmengen (Attribute teilweise mit Leerwerten)
 Bestimmte Daten in mehreren Entitätsmengen redundant führen
 …
Folgende Entscheide könnten in unserem Fall getroffen werden:
 Die Entitätsmenge Wochennr. wird fallen gelassen. Die Wochennr. wird bei Bedarf
berechnet.
 Die Entitätsmenge Ortschaften wird eliminiert und beim Kunden geführt, die 3. NF
wird hierfür bewusst verletzt.
 Die Entitätsmengen Partner, Mitarbeiter und Kunden werden aufgrund geringer Unterschiede zusammengefasst.
 Die Entitätsmengen Reisen und Grundreisen, Reisestruktur und Grundreise-Struktur
werden zusammengelegt.
 Für sämtliche Entitäts- und Fremdschlüssel werden invertierte Listen angelegt.
 …
Würden diese Entscheide durchgeführt, so verblieben dadurch von den ursprünglich 15 Entitätsmengen nur noch 9. Dafür würden je nach Sichtweise unterschiedliche Datensichten (Views) erstellt.
15.14.4.2. Physische Speicherorganisation
Bäume eignen sich für dynamische, schlecht vorhersehbare Datenbestände. Das Hash-Verfahren eignet sich hingegen für statische, zu Beginn bekannte Datenbestände. Es werden daher
die beiden Verfahren wie folgt eingesetzt:
Anhang
Relation
Ortschaften
Partner
Kunden
Mitarbeiter
Grundreisen
mögl. Reiseleiter
Wochennr.
Reisen
Preise
Rechnungscode
Buchungen
Grundreise_Struktur
Reisestruktur
Rechnungen
RechnungenBuchungen
209
Zugriffsverfahren
Hash
Baum
Baum
Baum
Baum
Baum
Hash
Baum
Baum
Hash
Baum
Baum
Baum
Baum
Baum
Tabelle 64: Relationen und Zugriffsverfahren
15.14.5. Meta-Entitätstypen, Data-Dictionary
Unten ist eine mögliche Lösung für ein einfaches Data-Dictionary skizziert, welches ausschliesslich zu Dokumentationszwecken verwendet werden soll.
Entitätsm engen
Entitätsschlüsselrelation
Attribute
Frem dschlüsselrelation
Entitäts-, Frem dschlüssel
Attributskom binationen
Figur 81: Datenmodell zum Data-Dictionary
Entitätsmengen
Attributsname:
Entitätsmengen#
Entitätsmengenname
Dokumentation
Wertebereich: Beschreibung:
Numeric(10)
Character(20)
Memo
Attribute
Attributsname:
Attribut#
Numeric(10)
 EntitätsmenEntitätsmengen# Numeric(10)
gen.Entitätsmengen#
Attributsname
Character(20)
Dokumentation
Memo
Anhang
210
Entitäts-, Fremdschlüssel
Attributsname:
Schlüssel#
Entitätsschlüsselrelation
Fremdschlüsselrelation
Rollenbezeichnung
Dokumentation
Numeric(10)
 EntitätsmenNumeric(10)
 EntitätsmenNumeric(10)
Character(20)
Memo
Attributskombinationen
Attributsname:
Schlüssel#
Attribut#
 Entitäts-Fremdschlüssel.Schlüssel#
Numeric(10)
 Attribute.Attribut#
Numeric(10)
Tabellen 65: Attributskatalog zum Data-Dictionary
Anhang
16. Literatur
211
16. Literatur
[Boehm 96]
Böhm, Fuchs, Pacher: Systementwicklung in der Wirtschaftsinformatik. Verlag der
Fachvereine an den Schweizerischen Hochschulen und Techniken, Zürich, 1996.
[Chen 80]
Chen P.P. ed.: Entity-Relationship Approach to Systems Analysis and Design.
North Holland, Amsterdam, 1980.
[Codd 70]
Codd, E.F.: A relational model of data for large shared data banks. Comm. ACM,
1970.
[Codd 72]
Codd, E.F.: Relational Completeness of data base sublanguages. In: Data Base
Systems, Courant Computer Science Symposium 6, 1971, Prentice Hall, Englewood Cliffs (NJ), 1972.
[Codd 91]
Codd, E.F.: The Relational Modell for Database Management - Version 2. Addison-Wesley, 1991.
[Date 00]
Date, C.J.: An introduction to database systems. Addison-Wesley, 2000.
[Date 97]
Date, C.J.: A Guide to the SQL Standard. Addison-Wesley, 1997.
[Härder 01]
Härder, T., Rahm, E.: Datenbanksysteme, Konzepte und Techniken der Implementierung. Springer-Verlag Berlin, 2001.
[Reuter 81]
Reuter, A.: Fehlerbehandlung in Datenbanksystemen. Carl Hanser, 1981.
[Lock 87]
Lockemann, P.C. und Schmidt J.W.: Datenbank-Handbuch. Springer Verlag,
1987.
[Schlag 83]
Schlageter, G., Stucky, W.: Datenbanksysteme: Konzepte und Modelle. Teubner
Studienbuch Informatik, 1983.
[Senko 73]
Senko, M. E., et al: Data structures and access in data base systems. IBM Syst.
Journal 12, 1973.
[Vetter 98]
Vetter, M.: Aufbau betrieblicher Informationssysteme mittels pseudoobjektorientierter, konzeptioneller Datenmodellierung. Teubner Verlag, Stuttgart,1998.
[Wirth 96]
Wirth, N.: Algorithmen und Datenstrukturen mit Modula-2. Teubner Verlag, Stuttgart,1996.
[Zehnder 89]
Zehnder, C.A.: Informationssysteme und Datenbanken. dvf Hochschulverlag AG
an der ETH und Teubner Stuttgart, 1989.
[Zehnder 98]
Zehnder, C.A.: Informationssysteme und Datenbanken. dvf Hochschulverlag AG
an der ETH und Teubner Stuttgart, 1998.
Anhang
212
17. Index
17. Index
#
# 141
3
3-Schema-Modell ................................. 17
A
Abhängigkeit
Funktionale ........................................ 43
Transitive ............................................ 47
Voll funktionale ................................. 46
Ablaufplan .......................................... 113
Adresszeiger .......................................... 11
Aggregation ......................................... 58
ANSI-SPARC ................................... 17, 141
Assoziation ............................................. 29
Assoziationstypen ................................. 29
Attribut ..................................... 12, 34, 140
Attributskatalog .................................... 35
Attributskombination ........................... 35
Aufzählungstyp ..................................... 32
Authentisierung .................................... 79
B
B*-Baum ................................................. 86
Bäume ................................................... 86
B-Baum .................................................. 86
BCNF ................................................... 141
Begin Of Transaction ........................... 97
Beziehung .............................................. 26
Beziehungsattribut................................ 34
Beziehungsmenge ................. 25, 26, 140
Beziehungsstruktur ................................ 53
Beziehungstyp ....................................... 29
Blatt ........................................................ 87
Blockgrösse ........................................... 84
Boolean ................................................. 32
Boyce/Codd-Normalform ................... 46
C
Candidate Key ..................................... 35
cascades ............................................ 31
Case-Tool .............................................. 91
Charakter .............................................. 32
Checkpoints ........................................ 102
Chiffrierung............................................ 85
Class ..................................................... 140
Clustering .............................................. 85
CODASYL .......................................... 141
CODASYL-DBTG-Modell....................... 11
Code-Tabelle ........................................ 62
Commit .................................................. 97
Compiler .............................................. 100
CREATE TABLE ...................................... 104
Currency-Konzept .............................. 102
Cursor ................................................... 102
Cursor-Verwalter................................. 102
D
Data Control Language...................... 13
Data Definition Language .................. 13
Data Description Language ............... 13
Data Dictionary . Siehe Metadatenbank
Data Manipulation Language ........... 13
Database Management System ....... 10
Date ....................................................... 32
Datei .................................................... 140
Dateiverwaltung................................. 140
Datenbankmanagementsystem ....... 10
Datenbanksystem ................................ 13
Anhang
hierarchisches ............................10, 140
netzwerkartiges..........................11, 140
relationales .................................12, 140
verteiltes ............................................. 99
Datenbanktechnik ................................ 83
Datenbanktransaktion ...................17, 20
Datenflussdiagramm ............................ 10
Datenkonsistenz ............................77, 100
Datenmodell.......................................... 17
zugriffspfadbezogenes ..................... 90
zugriffspfadunabhängiges ............. 103
Datenmodellierung .............................. 20
Datensatz ............................................. 140
Datensatzzeiger .................................. 102
Datenschutz .............................77, 78, 102
Datensicherheit .............................77, 100
Datentyp ........................................32, 112
Datenunabhängigkeit.......................... 14
physische ..................................103, 124
DatenwörterbuchSiehe Metadatenbank
DB ......................................................... 141
DBA ...................................................... 141
DBMS ...............................................10, 141
DBTG .................................................... 141
DCL .................................................13, 141
DD......................................................... 141
DDL ..........................................13, 103, 141
Deadlock ............................................... 97
Denormalisierung ..................42, 118, 121
Determinante ........................................ 47
Divisionsrestverfahren ........................... 90
DML .........................................13, 103, 141
Domäne ................................................. 32
E
Effizienz ..................................................... 9
Elementarinstrument ............................. 25
End Of Transaction................................ 97
Entität..............................................25, 140
abhängige ......................................... 26
Definition............................................. 25
historische ........................................... 75
Sub- ..................................................... 59
Super- .................................................. 59
unabhängige ..................................... 26
Entitäten-Beziehungs-Modell ............... 25
Entitätenverwaltung ............................. 90
Entitätsattribut ....................................... 34
Entitätschlüssel ..................................... 140
Entitätsintegrität .................................... 36
Entitätsmenge ...............................25, 140
Definition............................................. 25
Entitätsschlüssel ...............................35, 85
Entity ...............................................25, 140
Entity Integrity ........................................ 36
Entity Key .............................................. 140
Entity Set .........................................25, 140
Entity-Relationship-Modell......17, 26, 140
ER .......................................................... 141
ERM ...................................................... 141
Ersetzungsstrategie ............................... 84
Exclusive Lock ........................................ 95
Externe Ebene ....................................... 17
Externspeicherverwaltung ................... 84
Funktion .................................................. 20
Funktionale Abhängigkeit ................... 43
G
Generalisierung ..................................... 59
Geschäftsprozess .......................... 20, 119
H
Hash ........................................................ 90
Hauptspeicher ....................................... 84
Hierarchie ............................................... 53
I
Identifikation .......................................... 79
Identifikationsschlüssel .................... 35, 85
IMS................................................... 11, 141
Index ....................................................... 85
Instanz ................................................... 140
Instrument ........................................ 25, 53
Integer .................................................... 32
Integrität .......................13, 17, 77, 93, 100
Entitäts- ............................................... 36
Entitäts- ............................................... 77
referentielle .......................... 36, 77, 140
semantische ....................................... 77
Integritätsregel ...................................... 58
Integrity
Referential ........................................ 140
Interne Ebene ........................................ 17
Invertierte Liste ....................................... 85
Item ....................................................... 140
K
Klasse .................................................... 140
Knoten .................................................... 87
Komprimierung ...................................... 85
Konsistenz ............................................... 77
Konsistenzbedingung
primäre ............................................... 78
schwache .......................................... 78
sekundäre .......................................... 78
Strenge ............................................... 78
Konsistenzregel ...................................... 78
Konzeptionelle Ebene .......................... 17
Kryptographie ..................................... 102
L
Lesemarke.............................................. 99
Lesephase .............................................. 95
Lesesperre .............................................. 95
Liste
Invertierte ........................................... 85
Lock ........................................................ 95
Locktabelle ............................................ 95
Log ........................................................ 101
Logging ................................................ 101
Logik
2-wertig ............................................... 33
3-wertig ............................................... 33
Logische Ebene..................................... 17
F
M
Feld ....................................................... 140
Feldlänge ............................................... 85
Field ....................................................... 140
File ......................................................... 140
Float ........................................................ 32
Fragment .............................................. 124
Fragmentierungstransparenz ............ 124
Fremdschlüssel .................................12, 36
Fremdschlüsselverhalten ...................... 31
m\:m-Beziehung ................................... 46
Mehrbenutzerbetrieb ........................... 93
Metadaten ............................................ 90
Metadatenbank ................................... 91
aktive .................................................. 92
integrierte ........................................... 92
passive ................................................ 92
Meta-Meta-Daten ................................ 92
Migration ................................................ 75
17. Index
Migrationsregel ..................................... 75
Modell
3-Schema- ......................................... 17
Entity-Relationship ............................. 26
erweitertes Relationen- .................... 27
Relationales ....................................... 26
N
Namensgebung ................................... 26
Navigation ............................................. 11
NF .................................................... 42, 141
Nichtschlüsselattribute ......................... 43
NIL ........................................................... 33
Normalform ........................................... 42
1. 43
2. 44
3. 46
Boyce/Codd ..................................... 46
Normalisierung .................. 30, 33, 42, 118
NULL ........................................................ 33
nullifies .................................................. 31
NULL-Wert ........................................ 33, 74
Numeric ................................................. 32
O
Objektorientiert ................................... 140
Optimierer............................................ 103
Optimistisches Verfahren ..................... 95
Optimizer ..................................... 103, 121
Ortstransparenz ................................... 124
P
Performance ............................... 9, 33, 42
Performanz .............................................. 9
Periodenstempel .................................. 73
Pessimistisches Verfahren .................... 95
Physische Ebene ................................... 17
Pointer .................................................... 11
Primärschlüssel ........................ 35, 85, 140
Primary Key .......................................... 140
Projekt .................................................... 20
Protokoll ............................................... 101
Protokollierungsverfahren .................. 101
R
Read-Before-Update ........................... 98
Real ........................................................ 32
Record ................................................. 140
Record-Manager .................................. 84
Record-Typ .......................................... 140
Recordverwalter ................................... 84
Recovery ............................................. 100
Redefinition ........................................... 33
Redundanz ...................................... 10, 17
Referential Integrity .............................. 36
Referentielle Integrität ......................... 36
Rekursion ................................................ 56
Relation .......................................... 12, 140
relational
minimal ............................................... 13
voll ....................................................... 13
Relationship Set............................. 26, 140
Replikat ................................................ 125
Replikationstransparenz ..................... 125
Repository .......... Siehe Metadatenbank
Restricted ............................................ 31
Role......................................................... 27
Rollback ......................................... 97, 100
Rolle ...................................... 27, 28, 31, 34
Rollforward .......................................... 100
Row ....................................................... 140
Schlüsselattribut .................................... 35
Schlüsselkandidat ................................. 35
Schlüsseltransformation ....................... 90
Schnittstelle ........................................... 84
Schreibmarke ........................................ 99
Schreibphase ........................................ 95
Schreibsperre ........................................ 95
Segement .............................................. 84
Seite ........................................................ 84
SELECT .................................................. 105
Semantic Override ............................... 34
Semantik ................................................ 63
Serialisierbar .......................................... 94
Shared Lock .......................................... 95
Sonderzeichen .................................... 139
Sortierschlüssel ...................................... 85
Spaltenname ...................................... 140
Speicheranomalie ................................ 42
Sperrtabelle ........................................... 95
Sperrverfahren ...................................... 95
Spezialisierung ....................................... 59
SQL ............. 13, 78, 79, 102, 104, 141, 199
Standarddatenmodell ......................... 20
Standardwert ........................................ 33
Statische Tabelle .................................. 62
String....................................................... 32
Stückliste ................................................ 58
Subentität .............................................. 59
Superentität........................................... 59
Synonym .............................................. 140
Systemabsturz ..................................... 100
Systemfunktion .................................... 119
Systempufferverwaltung...................... 84
213
Zeile ...................................................... 140
Zeitstempel ...................................... 73, 74
Zeitstempel-Verfahren ......................... 99
Zugriffshilfen........................................... 84
Zugriffspfad ........................... 84, 118, 119
physischer .......................................... 85
sekundärer ......................................... 85
Zugriffspfadoptimierer ....................... 103
Zugriffspfadverwaltung ................. 84, 85
Zugriffsrechtsmatrix............................... 79
Zugriffsverfahren
Baumstrukturiertes ............................ 86
Invertierte Liste .................................. 85
Schlüsseltransformation ................... 90
T
Tabelle ................................................. 140
Table .................................................... 140
Time ........................................................ 32
Transaktion ............................................ 93
logische ............................................ 119
serialisierbar ....................................... 94
Transaktionsverwaltung ....................... 93
Transitive Abhängigkeit ....................... 47
Tupel ............................................... 12, 140
Two-Phase-Commit .............................. 99
Typenbindung ....................................... 33
Ü
Übersteuerung, semantische .............. 34
U
Undo ....................................................... 97
Unterbereich ......................................... 32
V
Validierungsphase ................................ 95
Verbund, Varianter .............................. 33
Verbundinstrument .............................. 53
Verdichtung .......................................... 76
Verteilung ............................................ 124
heterogene ..................................... 124
homogene ....................................... 124
View ....................................................... 17
Voll funktionale Abhängigkeit ............ 46
W
Wertebereich .................................. 32, 43
Wertetabelle ......................................... 62
Wiederholungsgruppe ................... 32, 43
Wurzel ..................................................... 87
S
Z
Satzverwaltung ..................................... 84
Schichtenmodell................................... 83
Zeiger ..................................................... 87
Zeigerliste ............................................... 85
Anhang

Datenmodellierung und Datenbanktechnik

Transcription

Similar documents

Einheitliche Repräsentation heterogener Datenquellen

miteinander15 Dez. 2013 / Jan/Feb 2014

Der Wertanalyse

Modellierung von IuK-Systemen

ITB 2008

Unterlagen

Entity Relationsship Modelle

genugate Version 7.0 Release Notes

1 Relationale Datenbanken (DB): Das Relationenmodell

3_Ulrich Schwinges_neu_20120625

der Studie

Time-integrative Geographic Information Systems

Relationales Datenmodell

Datenbanksysteme

Klausur WS0708 ohne Musterlösungen

„Dem Ingenieur ist nichts zu schwör...“ – wie man konstruktive