Datenbanksysteme - Institute of Computer Science

Datenbanksysteme
sechste, uberarbeitete Auage
Vorlesung gehalten im SS '95
Oliver Vornberger
Fachbereich Mathematik/Informatik
Universitat Osnabruck
1
Inhaltsverzeichnis
1 Einfuhrung
1.1
1.2
1.3
1.4
1.5
Erste Denition : : : : : : : : : : : : : : : : : : : : : : : : :
Modellierungskonzept : : : : : : : : : : : : : : : : : : : : :
Wozu Datenbanksysteme? : : : : : : : : : : : : : : : : : : :
Losungsansatz : : : : : : : : : : : : : : : : : : : : : : : : : :
Architektur eines DBMS (Data Base Management System)
2 Logische Datenorganisation
2.1
2.2
2.3
2.4
2.5
Das Entity/Relationshipmodell : : :
Das Hierarchische Datenmodell : : :
Das Netzwerk-Datenmodell : : : : :
Das Relationale Datenmodell : : : :
Das Objektorientierte Datenmodell :
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Vorbemerkung : : : : : : : : : : : : : : : : : : :
Grundidee : : : : : : : : : : : : : : : : : : : : : :
DDL (Data Denition Language) der DBTG : :
DML (Data Manipulation Language) der DBTG
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Heap-File Organisation : : : : : : :
Hash-Organisation : : : : : : : : :
Index-Organisation : : : : : : : : :
B*-Baume : : : : : : : : : : : : : :
Dense Index : : : : : : : : : : : : :
Variabel lange records : : : : : : :
Sekundar-Index : : : : : : : : : : :
Partial Match Retrieval : : : : : :
Multidimensionale Range-Queries :
2 ; d-trees (allgemein k ; d-trees)
Gitterverfahren : : : : : : : : : : :
Verwaltung geometrischer Objekte
IMS-Begrie : : : : : : : : : :
Datenbeschreibung in IMS : :
Die externe Ebene von IMS :
Datenmanipulation in IMS :
Speicherorganisation fur IMS
:
:
:
:
:
5 Das Netzwerk-Konzept
5.1
5.2
5.3
5.4
:
:
:
:
:
:
:
:
:
:
4 Das Hierarchische Konzept
4.1
4.2
4.3
4.4
4.5
:
:
:
:
:
:
:
:
:
:
3 Physikalische Datenorganisation
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
:
:
:
:
:
2
:
:
:
:
:
:
:
:
:
:
5
5
5
6
7
8
12
12
15
17
19
22
23
24
24
28
32
35
36
36
38
39
40
43
51
54
54
56
60
62
67
69
69
69
70
73
6 Das Relationale Konzept
78
7 Funktionale Abhangigkeiten
98
6.1 Relationenalgebra : : : : : : : : : : : : : : : : : : : : : : : : : : : 78
6.2 Query by example : : : : : : : : : : : : : : : : : : : : : : : : : : 84
6.3 INFORMIX : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 86
7.1 Armstrong-Axiome : : : : : : : : : : : : : : : : : : : : : : : : : : 98
7.2 Normalformen : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 105
8 Das objektorientierte Konzept
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
Schwachen von relationalen Systemen
Objektorientierte Programmierung : :
Objekt-Identitat : : : : : : : : : : : :
Objekt-Struktur : : : : : : : : : : : :
Persistenz : : : : : : : : : : : : : : : :
Objekt-Methoden : : : : : : : : : : : :
Applikation : : : : : : : : : : : : : : :
O2 SQL : : : : : : : : : : : : : : : : :
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
9 Synchronisation paralleler Transaktionen
9.1
9.2
9.3
9.4
Transaktionen : : : :
Serialisierbarkeit : :
Zeitstempelverfahren
Recovery : : : : : : :
10.1
10.2
10.3
10.4
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Organisatorische Manahmen
Identitatskontrolle : : : : : :
Zugriskontrolle : : : : : : :
Kryptographische Methoden :
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
10 Datenschutz
:
:
:
:
:
:
:
:
:
:
:
:
3
108
108
109
110
110
113
113
115
116
120
120
122
128
130
131
131
131
132
134
Literatur
G. Schlageter, W. Stucky:
C.J. Date:
J. Ullmann:
A. Heuer:
R. Elmasri, S. Navathe:
\Datenbanksysteme: Konzepte und Modelle", Teubner
\An Introduction to Database Systems", Addison-Wesley
\Principles of Database Systems", Computer Science Press
\Objektorientierte Datenbanken", Addison-Wesley
\Fundamentals of Database Systems", Addison-Wesley
Danksagung
Ich danke : : :
: : : Frau Gerda Holmann fur sorgfaltiges Erfassen des Textes und Erstellen
der Graken.
: : : Herrn Frank M. Thiesing fur seine engagierte Mitarbeit bei der inhaltlichen und auerlichen Gestaltung des Textes.
: : : der Studentin Sigrid Knust fur grundliches Korrekturlesen.
Osnabruck, im Juli 1995
(Oliver Vornberger)
4
1 Einfuhrung
1.1 Erste Denition
Ein Datenbanksystem ist ein computergestutztes System, das sich mit der
Beschreibung vorhandener Daten, ihrer Speicherung und ihrer Manipulation befat. Die Daten sollen in irgendeiner Abstraktion einen Ausschnitt der Realwelt
beschreiben (Modellbildung).
1.2 Modellierungskonzept
Die Realwelt wird modelliert durch Entities und Relationships:
entity:
Gegenstand des Denkens und der Anschauung (z.B. eine
konkrete Person, ein bestimmter Ort)
relationship: Beziehung zwischen den entities (z.B. wohnt in)
Entities werden charakterisiert durch eine Menge von Attributen, die gewisse
Attributwerte annehmen konnen. Entities, die durch dieselbe Menge von Attributen charakterisiert sind, konnen zu einer Klasse, dem Entity-Typ zusammengefat werden. Entsprechend entstehen relationship-Typen.
Beispiel: Entity-Typ Student habe die Attribute Mat-Nr., Name,
Hauptfach
Entity-Typ Ort habe die Attribute PLZ, Name
Relationship-Typ wohnt setzt Student und Ort in Beziehung zueinander.
Die graphische Darstellung erfolgt durch Entity-Relationship-Diagramme (E-RDiagramm):
Entity-Typ
Attribut
Relationship-Typ
HH
H
HH
H
5
Beispiel:
Matr.-Nr. Nachname
Vorname Hauptfach
@
;
@
@
@
;
;
@
PLZ
Name
@ @
;
;
HH
wohnt
H
HH in
H
Student
@
@
@
Ort
Hinweis: Derselbe Sachverhalt konnte auch durch einen entity-Typ Student modelliert werden, der ein Attribut Ort hat.
1.3 Wozu Datenbanksysteme?
Zur Speicherung der Daten bietet sich an, die entities durch Datensatze fester
Lange (records) darzustellen und die relationships durch Anordnung der records
auszudrucken.
Beispiel:
Es gibt eine Datei mit Personaldaten aller Mitarbeiter (sortiert nach Personen).
Es gibt eine Datei mit Angaben zu allen Projekten (sortiert nach Projekten).
Hinter jedem Projekt folgen die zugehorigen Mitarbeiter.
Probleme entstehen, wenn unterschiedliche Anwendungen auf denselben Daten laufen sollen. Dies verlangt verschiedene Datenorganisationen fur dieselben
Daten. Die Folge sind
Redundanz
Gefahr der Inkonsistenz
Daten/Programmabhangigkeit
Inexibilitat
6
1.4 Losungsansatz
U bergang von
Programm 1
Programm n
..
.
phys. Datei 1
phys. Datei n
zu
Programm 1
Programm n
..
.
logische Datei 1 H
H
'$
H Datenbank
logische Datei
Software
&%
Datenbank
Ziel:
Gewahrung von Sichten
(jeder Benutzer sieht die Welt durch seine Brille)
physikalische Datenunabhangigkeit
(A nderung der phys. Datei verlangt nicht die A nderung des Anwenderprogramms)
logische Datenunabhangigkeit
(A nderung der Gesamtsicht verlangt nicht die A nderung der Einzelsicht)
geringe Redundanz (Daten werden nur an einer Stelle gehalten)
Vermeidung von Inkonsistenz (widerspruchliche Daten vermeiden)
Gewahrung von Integritat (nur plausible Daten zulassen)
Flexibilitat (neue Verknupfungen ermoglichen)
Transaktionsverarbeitung (Kapselung zusammengehorender Aktionen)
Koordination und Synchronisation bei Parallelbetrieb
Sicherheit (Datenschutz vor unberechtigtem Zugri und vor Zerstorung)
Persistenz (dauerhafte Speicherung von Programm-Datenstrukturen)
Multiple User Interfaces (Query language, programming language, Masken)
7
1.5 Architektur eines DBMS (Data Base Management System)
Die Beschreibung der Realwelt (z.B. bestehend aus den Daten eines Unternehmens) erfolgt in drei Ebenen:
Konzeptuelles Modell
Hier wird auf logischer Ebene, unabhangig vom Anwenderprogramm, die
Gesamtheit der Daten beschrieben. Es werden die vorhandenen EntityTypen und Relationship-Typen deniert sowie die Attribute und deren
Wertebereiche festgelegt. Die Formulierung erfolgt vom enterprise administrator mittels einer DDL (data denition language). Das Ergebnis ist
das konzeptuelle Schema.
Externes Modell
Hier wird fur jede Benutzergruppe eine spezielle anwendungsbezogene
Sicht der Daten (view) speziziert. Die Beschreibung erfolgt durch den
application administrator mittels einer DDL, Umgang vom Benutzer mit
einer DML (data manipulation language). Ergebnis ist das externe Schema.
Internes Modell
Hier wird festgelegt, in welcher Form die logisch beschriebenen Daten im
Speicher abgelegt werden sollen. Geregelt werden record-Aufbau, AttributDarstellung, Dateiorganisation, Zugrispfade. Fur einen ezienten Entwurf werden statistische Informationen uber die Haugkeit der Zugrie
benotigt. Die Formulierung erfolgt durch den database administrator. Ergebnis ist das interne Schema.
Die Verbindungen zwischen den drei Ebenen werden durch die Transformationsregeln deniert. Sie legen fest, wie die Objekte der verschiedenen Ebenen aufeinander abgebildet werden. Z.B. legt der Anwendungsadministrator fest, wie
Daten des externen Modells aus Daten des konzeptuellen Modells zusammengesetzt werden. Der Datenbank-Administrator legt fest, wie bestimmte Attribute
bestimmter entities aus den abgespeicherten Daten zu erhalten sind.
Beispiel Bundesbahn:
Die Gesamtheit der Daten (d.h. Streckennetz mit Zugverbindungen) ist beschrieben im konzeptuellen Modell (Kursbuch). Ein externes Modell ist z.B. beschrieben im Heft Stadteverbindungen Osnabruck.
Beispiel Personaldatei:
Im konzeptuellen Modell wird der Entity-Typ Angestellter festgelegt mit den
Attributen Pers.-Nr., Name, Geb.-Datum, Telefon, Wohnort.
Das externe Modell Geburtstagsliste besteht aus den Komponenten Name,
Datum, Alter, wobei das Datum aus Tag und Monat des Geb.-Datum besteht,
8
und Alter sich aus der Dierenz vom laufenden Jahr und Geburtsjahr berechnet.
Im internen Modell wird festgelegt, da es eine Datei PERS gibt mit records
vom Typ Angestellter, in der fur das Attribut Wohnort nicht der volle Name,
sondern eine Kennzier gespeichert ist. Eine weitere Datei ORT enthalt Paare
von Kennziern und Ortsnamen. (Diese Speicherorganisation spart Platz, wenn
es nur wenige verschiedene Ortsnamen gibt. Sie verlangsamt allerdings den Zugri auf das Attribut Wohnort.)
Bemerkung: Das konzeptuelle Schema soll sowohl die reale Welt unabhangig
von DV-Gesichtspunkten beschreiben als auch die Grundlage fur das interne
Modell bilden, welches naturlich stark maschinenabhangig ist. Um diesen Konikt zu losen, stellt man manchmal dem konzeptuellen Schema ein sogenanntes
\logisches" Schema zur Seite, welches die Gesamtheit der Daten zwar hardwareunabhangig, aber doch unter Berucksichtigung von Implementationsgesichtspunkten beschreibt. Das logische Schema heit darum auch implementiertes
konzeptuelles Schema. Es ubernimmt die Rolle des konzeptuellen Schemas, das
nun nicht mehr Teil des eigentlichen Datenbanksystems ist, sondern etwas daneben steht und z.B. auch aufgestellt werden kann, wenn uberhaupt kein Datenbanksystem zum Einsatz kommt (siehe Bild).
externes
Schema
'$
reale
Welt
&%
konzeptuelles
Schema
logisches
Schema
internes
Schema
Datenbanksystem
9
Die Software des Datenbanksystems zergliedert sich in
das Datenbankmanagementsystem (DBMS)
File-Manager (FM)
und bewirkt bei einer konkreten Anfrage (Query) etwa folgenden Ablauf (siehe
Bild):
/Ben./APn
(10) /
/Ben./APn
n
/
n
;
AA
;
;
1;
A
;9
A
;;
A
;
;
EM/ES
;
2
;
;
(8) Trafo.DBMS H
Regeln
HH
HH
6
@
H3 H
@
HH Konzeptuelles Modell /
@
Konzeptuelles Schema
@
5 7
@
@4
Trafo.@
Regeln
@
@
@
?
/Ben./APn
n
/
:::
Trafo.- Regeln EM/ES
FM
H
HH 6
Internes Modell /
Internes Schema
HH
H
HH Speicher
H
DBMS
FM
||!
-
Datenbankmanagementsystem
File-Manager (Teil des Betriebssystems)
Befehlsweitergabe
Daten- und Kontrollubergabe
Ausfuhrung einer Verarbeitung
Architektur eines Datenbanksystems
10
1. Das DBMS empfangt die Query Wo wohnt Muller?
2. Das DBMS besorgt die benotigten Denitionen des entsprechenden EntityTyps aus dem externen Schema: z.B. Entity-Typ Angestellter mit Attribut
Name und Wohnort.
3. Das DBMS besorgt die entsprechenden Teile des konzeptuellen Schemas
(unter Ausnutzung der Transformationsregeln) und stellt fest, welche konzeptuellen Entities und Beziehungen benotigt werden.
4. Das DBMS besorgt die benotigten Teile des internen Schemas (unter
Ausnutzung der Transformationsregeln) und stellt fest, welche physischen
Satze zu lesen sind (z.B. aus der Datei PERS den Satz mit Name = Muller,
aus der Datei Ort den Satz mit der bei Muller gefundenen Kennzier).
5. Das DBMS ubergibt dem Betriebssystem die Nummern der zu lesenden
Speicherblocke.
6. Das Betriebssystem liest die angeforderten Blocke aus dem Speicher.
7. Das Betriebssystem ubergibt die verlangten Blocke dem DBMS in einem
Systempuer.
8. Das DBMS stellt das externe entity zusammen (unter Berucksichtigung
von Format und Anordnung deniert im externen Schema).
9. Das DBMS ubergibt das externe entity dem Anwenderprogramm in einem
Kommunikationsbereich.
10. Das Anwenderprogramm verarbeitet die Daten.
Die Punkte 4-7 mussen im allgemeinen mehrfach durchlaufen werden, da das
DBMS oft erst aufgrund eines gelesenen Satzes entscheiden kann, welcher Satz
als nachster zu lesen ist.
Die Abbildung von externen entities auf konzeptuelle und weiter auf interne
entities nennt man Binden. Statisches Binden liegt vor, wenn diese Abbildung
zur U bersetzungszeit des Programms berechnet wird. Findet sie dagegen erst
unmittelbar zum Zeitpunkt des Datenzugris statt, spricht man von dynamischem Binden. Bei statischem Binden mu das Anwendungsprogramm neu ubersetzt werden, wenn sich am konzeptuellen oder internen Modell etwas andert.
Beim dynamischen Binden entstehen Kosten durch zusatzliche Tabellenzugriffe und Schemainterpretationen. Fur die weiter oben geforderte physikalische
Datenunabhangigkeit akzeptiert man gewohnlich das statische Binden, da eine
Neuubersetzung vertretbar ist.
11
2 Logische Datenorganisation
2.1 Das Entity/Relationshipmodell
Schlusseleigenschaft
Sei E ein Entity-Typ, sei A die Menge seiner Attribute. Jedes entity ist durch
seine Attribut-Kombination eindeutig bestimmt, d.h. A ist identizierend fur
E. B A heit Schlussel, falls B identizierend ist, und alle Teilmengen von B
sind nicht identizierend.
B ist identizierend () fur zwei entities e1 e2 gilt:
e1 = e2 bzgl. B ) e1 = e2 (zu jedem Zeitpunkt).
Achtung: Die Schlusseleigenschaft bezieht sich auf Attribut-Kombinationen, nicht nur auf die momentan vorhandenen
Attributwerte!
Ein Schlussel kann als Primarschlussel ausgezeichnet sein: er identiziert ein Objekt wahrend seiner ganzen Lebenszeit im System, sein Wert kann nicht geandert
werden.
Beispiel:
Im Entity-Typ Person mit den Attributen Name, Vorname, Personenkennziffer,
Geburtsdatum, Wohnort ist Personenkennziffer der Prim
arschlussel. Die Kombination Name, Vorname, Geburtsdatum bildet ebenfalls einen (Sekundar-)Schlussel,
sofern garantiert wird, da es nicht zwei Personen mit demselben Namen und
demselben Geburtsdatum gibt.
Komplexitat von Beziehungen
Sind die Entity-Typen E1 E2 : : : Ek am Beziehungstyp f beteiligt, so gilt
grad(f) = k:
Zur naheren Klassizierung der Beziehung f gibt es drei Schreibweisen:
die (min, max)-Notation
Hierbei wird zu jedem an f beteiligten Entity-Typ E angegeben, in wievielen konkreten Beziehungen bzgl. f ein entity mindestens () und hochstens
() vorkommt:
kgrad(f E) = ( ) 2 INo 2 INo fg
(Das Symbol bedeutet \beliebig viel".)
12
Beispiel:
Student
(0 )
HH
H
HH
H
h
ort
(3 )
Vorlesung
Die (1 c m)-Notation
Es handelt sich um die (min, max)-Notation mit = 0 oder 1 und = 1
oder .
kgrad (f, E) (1, c, m)-Notation
(1, 1)
1
(0, 1)
c (choice)
(1, )
m (multiple)
(0, )
mc (multiple choice)
HH
mc
m
Student
Vorlesung
h
ort H
Beispiel:
H
HH
Die (1, n)-Notation
Nur anwendbar fur binare Beziehungen. Zwar ungenau, aber sehr verbreitet. Wir nennen f eine one-one, one-many, many-one, many-manyBeziehung, wenn folgender Sachverhalt vorliegt:
1:1
one | one
1:n
one | many
n:1
many | one
n : m many | many
Oftmals signalisiert man eine manyone-Beziehung zwischen E1 und E2
durch einen Pfeil von E1 nach E2 :
H H
H
X
X
X
XXX
H
XXX
H
XH
X
X
E1 0 1
E1 0 E1 0 1
E1 0 E1
13
HH
H
f
HH
H
HH
H
f
HH
H
HH
H
f
HH
H
HH
H
HH f
H
HH
H
f
HH
H
0 1 E2
0 1 E2
0 E2
0 E2
-
E2
Weitere Klassizierungen fur Beziehungen
Beziehung mit Attribut
H
H
H wirkt mit H
Angestellter
% der Arbeitszeit HH
Beziehung auf einem Entity-Typ
Projekt
Angestellter
HHkenntHHH H
\isa"-Beziehung
(1 1)
Abt.leiter
H
is HH
HH a
H
(0 1) Angestellter
Abt.leiter ist Subtyp von Angestellter und hat spezielle, zusatzliche Attribute.
Die allgemeinen Attribute sind uber isa zu erreichen. Selber Primarschlussel. In
diesem Fall wird ein Pfeil vom Subtyp zum Obertyp gezogen.
Achtung: ggf. zusatzlich:
Abt.leiter
(0 )
H
H
H befehligt H
(0 1)
HH
Angestellter
hierarchische Beziehung
E 0 ist E hierarchisch untergeordnet, wenn es zu jedem e0 2 E 0 genau ein e 2 E
gibt.
Abteilung
(0 )
HH
H enthalt H
HH
14
(1 1)
Angestellter
In Abhangigkeit von der zu verwendenden Speicherorganisation wahlt man zur
computergerechten Darstellung des Entity-Relationship-Modells eines der folgenden drei Datenmodelle:
2.2 Das Hierarchische Datenmodell
Eine Hierarchie X besteht aus einem Entity-Typ Xo , dem beliebig viele EntityTypen Xi unmittelbar untergeordnet sind jedem Entity-Typ Xi konnen wiederum Entity-Typen Xij untergeordnet sein usw. Alle Entity-Typen sind verschieden.
Beispiel: Bundesliga
Spieler
Ort
Name Gebdatum
Ortsname
;
;
;
;
;
@
@
@
@
@
Adresse
Position
Mannschaft
PLZ Ort
Posbez Posnr
Vereinsname
Saison
Entity-Typen heien Segmente,
Attribute heien Felder.
Name Jahr Gehalt
15
Grundsatzlich sind einer Vater-Auspragung (z.B. \Beckenbauer") fur jeden ihrer Sohn-Typen jeweils mehrere Sohnauspragungen zugeordnet (z.B. konnte der
Sohn-Typ Adresse 2 konkrete Adressen enthalten. Dadurch entsprechen dem
Baum auf Typ-Ebene mehrere Baume auf Entity-Ebene. Diese entities sind in
preorder-Reihenfolge zu erreichen, d.h. vom Vater zunachst seine Sohne und
dann dessen Bruder. Dieser Baumdurchlauf ist die einzige Operation auf einer
Hierarchie jedes Datum kann daher nur uber den Einstiegspunkt Wurzel erreicht werden.
Beispiel-Query: \Welche Spieler waren 1975 bei Bayern Munchen unter Vertrag?"
1.) Einstieg im Baum mit Wurzel Ort
2.) suche ersten Ort
3.) suche unter seinen Sohnen den Verein \Bayern Munchen"
4.) falls gefunden: durchlaufe dessen Sohne und gib sie aus, sofern Jahr =
1975
falls nicht gefunden: suche nachsten Ort, gehe nach 3).
16
2.3 Das Netzwerk-Datenmodell
Im Netzwerk-Datenmodell konnen nur binare many-one- (bzw. one-many)-Beziehungen dargestellt werden.
Entity-Typen heien logische record-Typen.
Entities heien logische records, sie haben logisches record-Format und bestehen
aus Feldern.
Die Beziehungen heien links.
Ein E-R-Diagramm mit den genannten Bezeichnungen und Einschrankungen
heit Netzwerk. Im Netzwerk werden die links als gerichtete Kanten gezeichnet
von Kastchen fur member zum Kastchen fur owner (funktionale Abhangigkeit).
In einer Auspragung fuhrt ein gerichteter \Ring" vom owner uber alle seine
member.
Beispiel: Verlag
Auspragung:
Netzwerk:
Durch die
Wuste
?
?
Buch
-
Autor
Winnetou
?
member
Karl May
6
Der Schut
owner
Selber
Atmen
?
?
Topfern in
der Toscana
17
Willi
Wachtel
6
Bei nicht binaren Beziehungen oder nicht many-one-Beziehungen hilft man sich
durch Einfuhrung eines kunstlichen logischen Record-Typs.
Beipiel: Bundesliga
Spieler
SP
-
Position
Beckenbauer
6
Muller
6
owner
?
?
?
?
?
?
6
Verteidiger
6
member owner
Typische Operationen auf Netzwerken:
Selektion: suche unter den logischen Records eines Typs gewisse heraus.
Projektion: ltere eine oder mehrere Felder heraus.
Navigation: nde mit Hilfe der links das nachste member eines owner oder
nde den owner des momentanen member.
Beispiel-Query: \Wo wohnen die Verteidiger?"
nde im Record-Typ Position ein record mit Posbez = \ Verteidiger".
durchlaufe alle seine member.
fur jeden member nde dessen owner im record-Typ Spieler.
gib bei jedem dieser owner das Feld Adr aus.
18
Sturmer
2.4 Das Relationale Datenmodell
Seien D1 D2 : : : Dk Wertebereiche.
R D1 D2 : : : Dk heit Relation.
Wir stellen uns eine Relation als Tabelle vor, in der jede Zeile einem Tupel
entspricht und jede Spalte einem bestimmten Wertebereich.
Die Folge der Spaltenidentizierungen heit Relationenschema.
Beispiel:
Dinge
(Bezeichnung,
Ball
Brikett
Hut
,
Form
Kugel
Quader
Zylinder
) Relationenschema 9
>
=
)
Relation
>
Tupel
Farbe
rot
schwarz
schwarz
Eine Menge von Relationenschemata heit relationales Datenbankschema, die
aktuellen Werte der einzelnen Relationen ergeben eine Auspragung der relationalen Datenbank.
pro Entity-Typ gibt es ein Relationenschema mit Spalten benannt nach
den Attributen
pro Relationship-Typ gibt es ein Relationenschema mit Spalten fur die
Schlussel der beteiligten Entity-Typen und ggf. weitere Spalten.
%
Angestellter
H
H
arbeitet H
HH
mit
H
| {z }
6
Projekt
6 6
%
Schlussel fur Projekt
Schlussel fur Angest.
19
Typische Operationen auf relationaler Datenbank:
Selektion: suche alle Tupel einer Relation mit
gewissen Attributeigenschaften
?
Projektion: ltere gewisse Spalten heraus
?
Verbund: nde Tupel in mehreren Relationen, die
bzgl. gewisser Spalten ubereinstimmen.
20
B
A
A
B
?
A
A
B
B
Beispiel: Bundesliga (Schlussel sind unterstrichen)
:
Spieler
Name
Leifeld
:
Mannschaft
Adr
Dortmund
Ort
Bochum
Bochum
Verein
VFL Bochum
Wattenscheid 09
spielt
Name
Leifeld
Posnr
1
Saison
Name
Leifeld
Verein
VFL Bo
:
Position
Posnr
1
mmm
Gebdatum
1.1.65
Jahr
90/91
@
Spieler
;
m m
H
@ ;
HH Position
HHspielt
H
SaisonHHH HHH
Gehalt
250.000
Mannschaft
;
;
m
Posbez
Torwart
@
@
m
Projektionsquery: \In welchen Stadten wohnen Spieler?"
Wahle aus Spieler die Spalte Adr
Selektionsquery: \Wer wohnt in Dortmund?"
Wahle aus Spieler solche Tupel mit Adr = Dortmund
Verbund-Query: \In welchen Stadten war Leifeld beschaftigt?"
Wahle aus Mannschaft die Spalte Ort von solchen Tupeln, wo Spalte
Verein = Spalte Verein von Saison und
wo Spalte Name von Saison = Leifeld
Charakteristika fur das relationale Modell:
Suchalgorithmus braucht nicht angegeben zu werden, alle Relationen
und Attribute sind gleichberechtigt, System ist benutzerfreundlich,
evtl. inezient.
21
2.5 Das Objektorientierte Datenmodell
Eine Klasse reprasentiert einen Entity-Typ zusammen mit darauf erlaubten Manipulationen, genannt Methoden. Attribute mussen nicht atomar sein, sondern
bestehen ggf. aus Tupeln, Listen und Mengen. Die Struktur einer Klasse kann
an eine Unterklasse vererbt werden. Binare Beziehungen konnen durch mengenwertige Attribute modelliert werden.
class Person
type tuple (name: String,
geb_datum: Date,
kinder: list(Person))
end
class Student inherit Person
type tuple (mat_nr: Integer,
hoert: set (Vorlesung))
method add_vorlesung (v: Vorlesung)
end
class Vorlesung
type tuple (titel: String,
gehoert_von: set (Student))
method add_student (s: Student)
end
22
3 Physikalische Datenorganisation
Die grundsatzliche Aufgabe bei der Realisierung eines internen Modells besteht
aus dem Abspeichern von Records in einem File. Jedes Record hat ein festes
Record-Format und besteht aus mehreren Feldern fester Lange mit zugeordnetem Datentyp. Folgende Operationen sind erforderlich:
INSERT: Einfugen eines Records
DELETE: Loschen eines Records
MODIFY: Modizieren eines Records
LOOKUP: Suchen eines Records mit bestimmtem Wert in bestimmten
Feldern.
Files werden abgelegt im Hintergrundspeicher (Magnetplatte), die aus Blocken
fester Groe (etwa 29 - 212 Bytes) bestehen, die direkt adressierbar sind. Ein
File ist verteilt uber mehrere Blocke, ein Block enthalt mehrere Records. Einige
Bytes des Blockes sind unbenutzt, einige werden fur den header gebraucht, der
Blockinformationen (Verkettung, Record-Interpretation) enthalt. Die Adresse
eines Records besteht aus der Blockadresse und einem Oset (Anzahl der Bytes vom Blockanfang bis zum Record). Der Pointer (Zeiger) zu einem Record
besteht entweder aus der Record-Adresse oder der Blockadresse, sofern genug
Information bekannt ist, um das Record im Block zu identizieren. Blockzeiger
erlauben das Verschieben der Records im Block (\unpinned records"), RecordZeiger setzen xierte Records voraus (\pinned records"), da durch Verschieben
eines Records Verweise von auerhalb miinterpretiert wurden (\dangling pointers").
Das Lesen und Beschreiben von Records kann nur im Hauptspeicher geschehen. Die Blockladezeit ist gewohnlich groer als die Zeit, die zum Durchsuchen
des Blockes nach bestimmten Records gebraucht wird. Daher ist fur Komplexitatsabschatzungen nur die Anzahl der Blockzugrie relevant.
Zur Umsetzung des Entity-Relationship-Modells verwenden wir
Records fur Entities
Records fur Relationships
(pro konkrete Beziehung ein Record, bestehend aus Pointer-Tupeln)
23
3.1 Heap-File Organisation
Die einfachste Methode zur Abspeicherung eines Files besteht darin, alle Records hintereinander zu schreiben (ohne Blockgrenzen zu uberlappen).
Operationen:
INSERT: Record am Ende einfugen (ggf. \Locher" nutzen)
DELETE: Losch-Bit setzen
MODIFY: Record uberschreiben
LOOKUP: Gesamtes File durchsuchen
Bei groen Files ist der lineare Aufwand fur LOOKUP nicht mehr vertretbar.
Gesucht ist daher eine Organisationsform, die
ezientes LOOKUP erlaubt
die restlichen Operationen nicht inezient macht
wenig zusatzlichen Platz braucht.
3.2 Hash-Organisation
Die grundlegende Idee bei Hash-Verfahren ist es, die Records des Files auf mehrere Buckets aufzuteilen, die jeweils aus einem oder mehreren Blocken bestehen.
Es gibt eine Hash-Funktion h, die einen Schlussel als Argument erhalt und ihn
auf die Bucket-Nummer abbildet, unter der der Block gespeichert ist, welcher
das Record mit diesem Schlussel enthalt. Sei B die Anzahl der Buckets, sei V
die Menge der moglichen Record-Schlussel, dann gilt gewohnlich jV j jB j.
Beispiel fur eine Hash-Funktion:
Fasse den Schlussel v als k Gruppen von jeweils n Bits auf. Sei di die i-te Gruppe
als naturliche Zahl interpretiert. Setze
k
X
h(v) = (
i=1
di )mod B
24
Im Bucket-Directory ndet sich als h(v)-ter Eintrag der Verweis auf den Anfang
einer Liste von Blocken, unter denen das Record mit Schlussel v zu nden ist.
0
1
B ;1
bucket
directory
-
-
6
?
b1
b2
b3
?
b4
?
b5
b6
Falls B klein ist, kann sich das Bucket-Directory im Hauptspeicher benden
andernfalls ist es uber mehrere Blocke im Hintergrundspeicher verteilt, von denen zunachst der \zustandige" Block geladen werden mu.
Jeder Block enthalt neben dem Zeiger auf den Folgeblock noch jeweils 2 Bits
pro Subblock (Platz fur ein Record), die angeben, ob dieser Subblock leer (also
beschreibbar), gefullt (also lesbar) oder geloscht (also nicht zum Lesen geeignet) ist. Geloschte Records werden wegen der Gefahr hangender Zeiger bis zum
generellen \Aufraumen" nicht wieder verwendet.
25
Gegeben sei ein Schlussel v:
LOOKUP: Berechne h(v) = i.
Lies den fur i zustandigen Directory-Block ein, und beginne
bei der fur i vermerkten Startadresse mit dem Durchsuchen
aller Blocke.
MODIFY: Falls Schlussel beteiligt: Loschen und Neueintragen.
Falls Schlussel nicht beteiligt: LOOKUP und U berschreiben.
INSERT: LOOKUP. Falls Satz mit v vorhanden: Fehler.
Sonst: Freien Platz im Block uberschreiben und ggf. neuen
Block anfordern.
DELETE: LOOKUP. Bei Record Loschbit setzen.
Der Aufwand aller Operationen hangt davon ab, wie gleichmaig die HashFunktion auf die Buckets verteilt und wie viele Blocke im Mittel ein Bucket
enthalt.
Im gunstigsten Fall ist nur ein Directory-Zugri und ein Datenblock-Zugri erforderlich und ggf. ein Blockzugri beim Zuruckschreiben. Im ungunstigsten Fall
sind alle Records in dasselbe Bucket \gehasht" worden und daher mussen ggf.
alle Blocke durchlaufen werden.
Bei Hashtabellen, deren Eintrage komplett im Hauptspeicher liegen, gibt es
(statt dynamisch wachsender Blocklisten) fur jeden Hash-Wert i einen reservierten Speicherplatz fester Groe. Gilt h(v) = i und i ist bereits gefullt, so
wird nach einer Kollisionsstrategie nach einem Ausweichplatz gesucht. Beim linearen Sondieren testet man die Platze i+1 i+2 i+3 : : : beim quadratischen
Sondieren testet man die Platze i + 1 i + 4 i + 9 : : : beim Double Hashing
wird mit einer 2. Hashfunktion die Sondierschrittweite bestimmt.
Sei Lastfaktor := Tabelleninhalt
Tabellengroe .
Bei linearem Sondieren dauert
die erfolglose Suche 12 ((1 + 1;1 )2), ergibt 5 fur = 23
die erfolgreiche Suche 12 (1 + ( 1;1 )), ergibt 2 fur = 23 .
Bei Double Hashing dauert
die erfolglose Suche 1;1 , ergibt 5 fur = 45
die erfolgreiche Suche ;ln(1 ;) , ergibt 2 fur = 45
Beispiel:
Gegeben die Hash-Funktion h, die einen Schlussel v abbildet auf die Lange von
v mod 5. Gegeben folgendes File (pro Block zwei Records mit Angaben zum
Dinosaurier und im Header zwei Bits zum Frei/Belegt-Status der Subblocks,
ubernommen aus Ullmann, Kapitel 2):
26
voll/leer-Information
ein Datensatz
@
@
z}|{z
}|
{z
JurasAllo11 Diplodlake
herb.
90
15
sic
ocus
saurus
0 XX
z
X
1
2
11 Pterodactyl
3
?
4
10 Triceratops
bucket
directory
11 Plateosaurus
?
Stego0 saurus
Leerraum
ein Datensatz
@
@
}|
{z}|{
Juras- land carn. 35 5
sic
Juras- land herb. 20 2
sic
Cretaceous
air carn. 1
Cretaceous
land herb. 25 10
Triassic
Juras- lake herb. 70 25
land herb. 30 5 Brontosic
saurus
Juras11 Brachiosaurus sic
Juraslake herb. 80 50 Compsognathus sic land carn. 2
Cret10 Tyrannosaurus aceous
land carn 50 8
0
Es werde nun \Elasmosaurus" (Hashwert = 2) eingefugt. Hierzu mu ein neuer
Block fur Bucket 2 angehangt werden. Dann werde \Brontosaurus" umgetauft
in \Apatosaurus". Da diese A nderung den Schlussel beruhrt, mu das Record
geloscht und modiziert neu eingetragen werden. Das File hat dann folgende
Struktur:
0 XX
z
X
11 Diplodocus
1
2
11 Pterodactyl
3
?
4
11 Triceratops
bucket
directory
10 Plateosaurus
?
?
Jurassic
Allolake herb. 90 15 saurus
Juras- land carn. 35 5
sic
Cretaceous
air carn. 1
Stego0 saurus
Juras- land herb. 20 2
sic
Cretaceous
land herb. 25 10 Apatosaurus
Juras- lake herb. 70 25
sic
Triassic
land herb. 30 5
Cret10 Elasmosaurus aceous
sea carn. 40 5
Juras11 Brachiosaurus sic
Juraslake herb. 80 50 Compsognathus sic land carn. 2
Cret10 Tyrannosaurus aceous
land carn. 50 8
0
Vorteil Hashorganisation: sehr schnell, gute Speicherausnutzung.
Nachteil Hashorganisation: keine Sortierung generierbar, keine Bereichsabfragen
moglich, nur eingeschrankte Dynamik, d.h. ggf. aufwendige Umorganisation erforderlich bei U ber/Unterlauf.
27
3.3 Index-Organisation
Wir setzen nun voraus, da sich die Schlussel der zu verwaltenden Records als
Zeichenketten interpretieren lassen und damit eine lexikographische Ordnung
auf der Menge der Schlussel impliziert wird: Fur zwei Strings x = x1 x2 : : : xk
und y = y1 y2 : : : ym gilt:
x < y : , (k < m und x1 : : :xk = y1 : : :yk ) oder
(9i min(k m) : (x1 : : :xi;1 = y1 : : :yi;1 und xi < yi )
Sind mehrere Felder am Schlussel beteiligt, so wird zum Vergleich deren Konkatenation herangezogen.
Neben der Haupt-Datei (main le), die alle Datensatze in lexikographischer
Reihenfolge enthalt, gibt es nun eine Index-Datei (sparse index) mit Verweisen in die Hauptdatei. Die Eintrage der Index-Datei sind Tupel, bestehend aus
Schlusseln und Blockadressen, sortiert nach Schlusseln. Liegt < v a > in der
Index-Datei, so sind alle Record-Schlussel im Block, auf den a zeigt, groer oder
gleich v. Zur Anschauung: Fassen wir ein Telefonbuch als Hauptdatei auf (eine Seite ein Block), so bilden die Namen \links oben" aller Seiten einen Index.
Wir nehmen an, die Records seien verschiebbar und pro Block sei im Header vermerkt, welche Subblocks belegt sind. Dann ergeben sich die folgenden
Operationen:
LOOKUP: Gesucht wird ein Record mit Schlussel v1 .
Suche (mit binary search) in der Index-Datei den letzten Block mit erstem
Eintrag v2 v1 . Suche in diesem Block das letzte Paar (v3 a) mit v3 v1 .
Lies Block mit Adresse a und durchsuche ihn nach Schlussel v1 .
MODIFY: Zunachst LOOKUP. Ist der Schlussel an der A nderung beteiligt, so
wird MODIFY wie ein DELETE mit anschlieendem INSERT behandelt.
Andernfalls kann das Record uberschrieben und dann der Block zuruckgeschrieben werden.
INSERT: Eingefugt wird ein Record mit Schlussel v.
Suche zunachst mit LOOKUP den Block Bi , auf dem v zu nden sein
mute (falls v kleinster Schlussel, setze i =1). Falls Bi nicht vollstandig
gefullt: Fuge Record in Bi an passender Stelle ein, und verschiebe ggf.
Records um eine Position nach rechts (Full/Empty-Bits korrigieren). Wenn
v kleiner als alle bisherigen Schlussel, so korrigiere Index-Datei. Wenn Bi
ufe, ob Bi+1 Platz hat. Wenn ja: Schiebe uberlaufendes
gefullt: Uberpr
Record nach Bi+1 und korrigiere Index. Wenn nein: Fordere neuen Block
Bi0 an, speichere das Record dort, und fuge im Index einen Verweis ein.
DELETE: analog zu INSERT
28
Beispiel:
Gegeben eine Hauptdatei mit Blocken, die jeweils 2 Records speichern. Die
Blocke der Index-Datei enthalten jeweils vier Schlussel/Adre-Paare. Weiterhin gibt es im Hauptspeicher eine Tabelle mit Verweisen zu den Index-DateiBlocken.
voll/leer-Bits
z }| {
-
11
Allosaurus
Brachiosaurus
-
11
Brontosaurus
Compsognathus
-
11
Diplodocus
Plateosaurus
-
11
Pterodactyl
Stegosaurus
-
11
Triceratops
Tyrannosaurus
voll/leer-Bits
z }| {
- 1111
Allosaurus
- 1000
Triceratops
Brontosaurus
Diplodocus
g Tabelle zum Einstieg in den Index
29
Pterodactyl
Leerraum
z }| {
Nun wird \Elasmosaurus" eingefugt. Hierzu ndet man zunachst als Einstieg
\Diplodocus". Der zugehorige Dateiblock ist voll, so da nach Einfugen von
\Elasmosaurus" fur das uberschussige Record \Plateosaurus" ein neuer Block
angelegt und sein erster Schlussel in die Index-Datei eingetragen wird.
-
11
Allosaurus
Brachiosaurus
-
11
Brontosaurus
Compsognathus
-
11
Diplodocus
Elasmosaurus
-
10
Plateosaurus
-
11
Pterodactyl
Stegosaurus
-
11
Triceratops
Tyrannosaurus
- 1111
Allosaurus
Brontosaurus
- 1100
Pterodactyl
Triceratops
30
Diplodocus
Plateosaurus
Nun wird \Brontosaurus" umbenannt in \Apatosaurus". Hierzu wird zunachst
\Brontosaurus" geloscht, sein Dateinachfolger \Compsognathus" um einen Platz
vorgezogen und der Schlussel in der Index-Datei, der zu diesem Blockzeiger
gehort, modiziert. Das Einfugen von \Apatosaurus" bewirkt einen U berlauf
von \Brachiosaurus" in den Nachfolgeblock, in dem \Compsognathus" nun wieder an seinen alten Platz rutscht. Im zugehorigen Index-Block verschwindet
daher sein Schlussel wieder und wird uberschrieben mit \Brachiosaurus".
-
11
Allosaurus
Apatosaurus
-
11
Brachiosaurus
Compsognathus
-
11
Diplodocus
Elasmosaurus
-
10
Plateosaurus
-
11
Pterodactyl
Stegosaurus
-
11
Triceratops
Tyrannosaurus
- 1111
Allosaurus
Brachiosaurus
- 1100
Pterodactyl
Triceratops
Diplodocus
Plateosaurus
Bemerkung: Ist die Verteilung der Schlussel bekannt, so sinkt die Suchzeit durch
Interpolation Search auf log log n Schritte!
31
3.4 B*-Baume
Betrachten wir das Index-File als Daten-File, so konnen wir dazu ebenfalls einen
weiteren Index konstruieren und fur dieses File wiederum einen Index usw. Diese
Idee fuhrt zum B*-Baum. Ein Baum T heit B*-Baum mit Parameter k ,
1. Jeder Weg von der Wurzel zu einem Blatt hat dieselbe Lange.
2. Jeder Knoten auer der Wurzel und den Blattern hat mindestens k Nachfolger. Die Wurzel hat keinen oder mind. 2 Nachfolger.
3. Jeder Knoten hat hochstens 2 k Nachfolger.
Der Baum T bendet sich im Hintergrundspeicher, und zwar nimmt jeder Knoten einen Block ein. Ein Knoten mit j Nachfolgern speichert j Paare von
Schlusseln und Adressen (s1 a1 ) : : : (sj aj ). Es gilt s1 s2 : : : sj . Eine Adresse in einem Blattknoten bezeichnet den Block mit Informationen zum
zugehorigen Schlussel, sonst bezeichnet sie den Block zu einem Baumknoten:
Enthalte der Block fur Knoten p die Eintrage (s1 a1) : : : (sj aj ). Dann ist der
erste Schlussel im i-ten Sohn von p gleich si , alle weiteren (sofern vorhanden)
Schlussel in diesem Sohn sind groer als si und kleiner als si+1 .
Operationen auf B*-Baumen
Wir betrachten nur die Operationen auf den Knoten des Baumes und nicht auf
den eigentlichen Datenblocken. Gegeben sei der Schlussel s.
LOOKUP: Beginnend bei der Wurzel steigt man den Baum hinab in Richtung
des Blattes, der den Schlussel s enthalten mute. Hierzu wird bei einem
Knoten mit Schlusseln s1 s2 : : : sj als nachstes der i-te Sohn besucht,
wenn gilt si s < si+1 .
MODIFY: Wenn das Schlusselfeld verandert wird, mu ein DELETE mit
nachfolgendem INSERT erfolgen. Wenn das Schlusselfeld nicht verandert
wird, kann der Datensatz nach einem LOOKUP uberschrieben werden.
INSERT: Nach LOOKUP sei Blatt B gefunden, welches den Schlussel s enthalten soll. Wenn B weniger als 2k Eintrage hat, so wird s eingefugt, und
(sofern s kleinster Schlussel im Baum) es werden die Vorgangerknoten berichtigt. Wenn B 2k Eintrage hat, wird ein neues Blatt B 0 generiert, mit
den groeren k Eintragen von B gefullt und dann der Schlussel s eingetragen. Der Vorganger von B und B 0 wird um einen weiteren Schlussel s0
(kleinster Eintrag in B 0 ) erweitert. Falls dabei U berlauf eintritt, panzt
sich dieser nach oben fort.
Beispiel fur B-Baum mit Parameter k = 2, es werden nacheinander die Schlussel
wie folgt eingefugt:
3,7,1,16,4,14,12,6,2,15,13,8,10,5,11,9
""
1.2.
"" "
" "
3.4. 5. 6. 7.
"
8.
32
1.)
1 3 7 16
Schnappschu gezeichnet:
1
2.)
7 H
H
1 3 4
1
3.)
7 H
H
1 3 4 6
1
1 2 3
4
4 6
1
5.)
1 2 3
HH
j
7 12 14 16
;
)
;
4.)
HH
j
7 16
4
4 6
7
@
R
@
7 12 14 16
7
14
@ HHH
j
H
?
R
@
7 12
14 15 16
1 4 7 14 H
;
HH
j
H
)
;
?
6.)
1 2 3
4 6
7 8 12 13
1
7.)
1
PP
q
P
7
?
1 2 3
7 PP
P
4
4 6
7 8 10
1
8.)
1
1 2 3
)
4
;
;
4 5 6
14 15 16
7 8 9
33
12
;
;
14
12 13
@
R
@
14 15 16
7 P
PP
PP
q
P
7 10
)
10 11
12
;
;
12 13
14
?
14 15 16
DELETE: Nach LOOKUP sei Blatt B gefunden, welches den Schlussel s enthalt.
Das Paar (s a) wird entfernt und ggf. der Schlusseleintrag der Vorganger
korrigiert. Falls B jetzt k ; 1 Eintrage hat, wird der unmittelbare Bruder
B 0 mit den meisten Eintragen bestimmt. (Haben beide Bruder gleich viel
Eintrage, so wird der linke genommen.) Hat B 0 mehr als k Eintrage, so
werden die Eintrage von B und B 0 auf diese beiden Knoten gleichmaig
verteilt. (Haben B und B 0 zusammen eine ungerade Anzahl, so erhalt der
linke einen Eintrag mehr.) Hat B 0 genau k Eintrage, so werden B und B 0
verschmolzen. Die Vorgangerknoten mussen korrigiert werden.
Der Parameter k ergibt sich aus der Blockgroe und dem Platzbedarf fur die
Schlussel/Adrepaare. Die Hohe des Baumes ergibt sich aus der benotigten Anzahl von Verzweigungen, um in den Blattern genugend Zeiger auf die Datenblocke zu haben.
Beispiel 300.000 Datenrecords !a 100 Bytes
1.024 Bytes pro Block
15 Bytes fur Schlussel
4 Bytes fur Adresse
) b151024
+ 4c = 53 ) k = 26
Die Wurzel sei im Mittel zu 50 % gefullt (hat also 26 Sohne), ein innerer Knoten
sei im Mittel zu 75 % gefullt (hat also 39 Sohne), ein Datenblock sei im Mittel
zu 75 % gefullt (enthalt also 7 bis 8 Datenrecords). 300.000 Records sind auf
b 3007:5000 c = 40:000 Datenblocken verteilt.
Hohe Anzahl Blatter Anzahl Zeiger
0
1
26
1
26
26 39
= 1.014
2
26 39
26 39 39
= 39.546
Damit reicht die Hohe 2 aus, um genugend Zeiger auf die Datenblocke bereitzustellen.
Der Platzbedarf betragt
1 + 26 + 26 39 + 39546 40:000 Blocke
die Zugriszeit 4. Zum Vergleich: Das Heaple benotigt 30.000 Blocke.
Soll fur oenes Hashing eine mittlere Zugriszeit von 4 Blockzugrien gelten, so
mussen in jedem Bucket etwa 5 Blocke sein (1 Zugri fur Hash-Directory, 3 Zugrie im Mittel fur eine Liste von 5 Blocken). Von diesen 5 Blocken sind 4 voll,
der letzte halbvoll. Somit benden sich in einem Bucket etwa 4 5 10 = 45 Records. Also sind 30045:000 = 6:666 Buckets erforderlich. Da 256 Adressen in einen
Block passen, werden b 666
256 c = 26 Directory-Blocke benotigt. Der Platzbedarf
betragt daher 26 + 5 6666 = 33356.
Vorteil B*-Baum: dynamisch, schnell, Sortierung generierbar (ggf.
Blatter verzeigern).
Nachteil:
komplizierte Operationen, Speicheroverhead.
34
3.5 Dense Index
Sparse Index verlangt, da main le sortiert ist, da nicht alle Eintrage im Index
stehen.
May Meier
;
;
;
Muller
;
;
;
May ; Muller ;
Dense Index ist eine Datei mit Paaren (s a) fur alle Schlussel, sortiert nach
Schlusseln.
Idee:
Suche im Index, greife dann auf Hauptdatei zu.
Vorteil:
main le kann kompakter gehalten werden (dadurch wird zusatzlicher Platz kompensiert)
Lucken nutzen, dangling pointers uber Index abfangen! D.h. main
le ist jetzt unpinned! Index nicht! Schlusselfeld kann im main le
fehlen, falls neben Blockadresse auch oset vermerkt wird.
Nachteil: 1 Blockzugri mehr als notig (vom gefundenen Schlussel ins
Mainle)
Beispiel fur B*-Baum mit Dense Index
300.000 Records mit je 100 Bytes, davon 15 Bytes fur den Schlussel. Im Mainle
werden die Datensatze ohne Schlussel abgelegt, d.h. b1001024
;15c = 12 Records pro
Block.
Also werden 300b12:000
ocke benotigt.
c = 25:000 Datenbl
Im Dense Index belegt jedes Tripel der Form <Schlussel, Blockadresse,
Offset> jeweils 15 + 4 + 1 = 20 Bytes. Also passen 1024
b20c = 50 Tripel auf einen
:000
Index-Block. Sind die Index-Blocke zu 75 % gefullt, sind 300
b375c = 8:000 Verweise von den Blattern des B*-Baums in den Dense-Index erforderlich.
Der Platzbedarf betragt daher etwa
im B*-Baum 1 + 32 + 1536 =
1569 Blocke
im Dense Index
8000 Blocke
im Main-File
25000 Blocke
35000 Blocke
35
3.6 Variabel lange records
geeignet fur one-many relationships, z.B. record-Format sei
name, vorname, (studienfach), Problem bei Decodieren im Block.
1. reserviere Platz fur maximale Anzahl und merke aktuelle Anzahl
2. verwende Zeiger zu records mit je 1 Fach
3. reserviere Platz fur mittlere Zahl und U berlauf-Zeiger.
3.7 Sekundar-Index
Die bisher behandelten Organisationsformen sind geeignet zur Suche nach einem
Record, dessen Schlussel gegeben ist. Um auch ezient Nicht-Schlussel-Felder
zu behandeln, wird fur jedes Attribut, das unterstutzt werden soll, ein sogenannter secondary index (Sekundar-Index) angelegt. Er besteht aus einem Index-File
mit Eintragen der Form <Attributwert, Adresse> und erlaubt es, bei gegebenem Attributintervall, die dazu passenden Records zu nden.
Beispiel:
Im Dinosaurier-File ist ein secondary index angelegt fur das Attribut GEWICHT,
welches, gespeichert in der letzten Record-Komponente von 5 bis 50 variiert. Der
Sekundarindex (er wird erreicht uber einen Index mit den Eintragen 0 und 15)
besteht aus den Blocken <0, 2, 5, 8, 10> und <15, 25, 50>. Die beim Gewicht g
gespeicherte Adresse fuhrt zunachst zu einem Vermerk zur Anzahl der Eintrage
mit dem Gewicht g und dann zu den Adressen der Records mit Gewicht g.
36
Allosaurus
Jurassic
land
carn. 35 5 Brachiosaurus
Jurassic
lake
herb. 80 50 -
Brontosaurus
Jurassic
lake
herb. 70 25
-
Compsognathus
Jurassic
land
carn.
-
Diplodocus
Jurassic
lake
herb. 90 15
Elasmosaurus
Cretaceous
sea
carn. 40 5 Plateosaurus
Triassic
land
herb. 30 5 -
Pterodactyl
Cretaceous
air
carn.
-
Stegosaurus
Jurassic
land
herb. 20 2
Triceratops
Cretaceous
land
herb. 25 10 Tyrannosaurus
Cretaceous
land
carn. 50 8
-
2 0
1 0
Main le
0
15
0
2
5
8
Zahl der nachfolgenden Zeiger
2
?
- 3
1
- 1
1
- 15
1
10
Index zum
Sekundar-Index
25
Q 50
Q
Q
s PPP
Q
q 1
P
1
Sekundar-Index fur GEWICHT
37
3.8 Partial Match Retrieval
Unter Partial Match Retrieval versteht man die Suche nach Records, bei denen
gewisse Attribute a1 : : : ak mit gegebenen Werten w1 : : : wk ubereinstimmen.
Um ein vollstandiges Durchsuchen aller Blocke zu vermeiden, setzt man die
folgenden Verfahren ein:
Mehrfach-Sekundar-Index
Fur diejenigen Attribute, die durch einen Sekundar-Index unterstutzt werden, ndet man die zugehorigen Zeiger-Mengen S1 : : : Sj und bildet deren
Durchschnitt S. Alle Blocke, deren Adressen im Schnitt S liegen, werden
nun auf Records hin durchsucht, die mit den Werten w1 : : : wk ubereinstimmen. (Achtung: Da S als Schnitt von Blockadressen gebildet wird,
mu nicht jeder Block aus S tatsachlich ein Record enthalten, das mit
w1 : : : wj ubereinstimmt.)
Partitionierte Hash-Funktion
Es wird eine Hash-Funktion h verwendet, die als Argument alle Attribute, und nicht nur den Schlussel, enthalt. Sei die Anzahl der Buckets
eine Zweier-Potenz, z.B. 2b . Dann besteht eine (logische) Bucketadresse
aus b Bits. Fur jedes Attribut ai i = 1 : : : k verwenden wir eine HashFunktion hi, deren Funktionswert
im Intervall 0::2bi ; 1 liegt, d.h. aus bi
P
Bits besteht. Es gilt ki=1 bi = b. Die Hashfunktion h besteht nun aus der
Konkatenation der einzelnen Hashwerte hi :
h(a1 a2 : : :ak ) = h1 (a1 )h2(a2 ) : : :hk (ak ):
Beispiel: Gegeben der Record-Typ Student mit den Feldern a1 a2 a3.
Matrikel-Nummer : integer
Versicherungsnummer : integer
Hauptfach : 10 characters.
Es seien 29 = 512 Buckets zu verwalten. Es sei
h1 (x) := x mod 16 (liefert 4 Bits)
h2 (x) := x mod 8 (liefert 3 Bits)
h3 (x) := (Lange von x) mod 4 (liefert 2 Bits)
Der Student mit Matrikel-Nummer 58651 und Versicherungsnummer
130326734 und Hauptfach Mathe bekommtden Hashwert 101111001 (binar),
denn 58651 mod 16 ergibt 11 = 1011 (binar), 130326734 mod 8 ergibt
6 = 110 (binar), 5 mod 4 ergibt 1 = 01 (binar).
Ist zum Suchen das Attribut ai gegeben, so sind bereits bi Bits der Bucketadresse bekannt. AttributePa1 : : : aj reduzieren damit den Suchraum
um den Faktor 2a mit a = ji=1 bi.
38
3.9 Multidimensionale Range-Queries
Bisher:
Jetzt:
Beispiel:
Alter
Einkommen
PLZ
Finde alle Records mit x1 a x2
Finde alle Records mit x1 a1 x2 und y1 a2 y2 : : :
gesucht sind alle Personen
zwischen 20 und 30 Jahre alt
zwischen 2000 und 3000 DM
zwischen 40000 und 50000
im folgenden (zur Veranschaulichung) nur 2-dimensionaler Fall (ist verallgemeinerbar):
y
6
G
y2
B
y1
A
E
x1
F
D
H
C
I
K
J
x2
-
x
d.h. gegeben Rechteck mit seinen Eckpunkten, nde alle Punkte, die im Rechteck
liegen. Gegeben sei
function imrechteck (p : Punkt r : rechteck) : boolean
1. Moglichkeit: sequentiell alle Punkte testen
2. Moglichkeit: Projektion auf x oder y mit binarer Suche uber vorhandenen Index, danach sequentiell, d.h. zunachst werden
G F C D E ermittelt, danach bleibt F ubrig
3. Moglichkeit: Projektion auf x und Projektion auf y, anschlieend
Durchschnitt bilden.
Beobachtung: ggf. lange Laufzeit trotz kleiner Treerzahl!
Dagegen: 1-dimensionale Suche: Aufwand k+log n bei k Treern in einem Suchbaum mit n Knoten.
39
3.10
2
; d-trees (allgemein k ; d-trees)
Verallgemeinerung von binaren Suchbaumen
homogene Variante: Knoten enthalt Datenrecord
linker Sohnzeiger
rechter Sohnzeiger
Fur jeden Knoten mit Schlussel x=y gilt
im linken Sohn
im rechten Sohn
auf ungerader Ebene alle Schlussel x alle Schlussel > x
auf gerader Ebene
alle Schlussel y alle Schlussel > y
10
9
8
7
6
5
4
3
2
1
E
G
F
A
H
C
B
D
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
A5=6 Ebene 0
bzgl. y kleiner H
y groer
Hbzgl.
HH
H
B14=3 E7=9 HHbzgl. x groer
bzgl. x kleiner H
x groer
Hbzgl.
H
H
H
G1=8 F 12=7 C9=4 H
bzgl. y kleiner H
y groer
Hbzgl.
H
H
H
D6=2 H8=5 bei k ; d-trees: verwende auf Ebene z als Diskriminator das Attribut (z mod k)
40
Aufbau des 2 ; d-Baums analog zu binarem Baum:
Suche mit Schlussel x=y abwechselnd die Stelle, wo x=y Knoten sein mute und
hange ihn dort ein.
Exakt Match
z.B. nde Record (15=5)
Suche mit Schlussel x=y abwechselnd bis zur Stelle,
an der x=y Knoten sein mute.
Partial Match
z.B. nde alle Records mit x = 7:
an den Knoten, an denen nicht bzgl. x diskriminiert
wird, steige in beide Sohne ab, an den Knoten, an
denen bzgl. x diskriminiert wird, steige in den zutreenden ab.
Range-Query
z.B. nde alle Records mit 7 x 13 7 y 10:
an den Knoten, an denen die Diskriminatorlinie das
Suchrechteck schneidet, steige in beide Sohne ab,
sonst steige in den zutreenden Sohn ab.
m
;
;
m
A
B
@
m
@
@
m
m
B
El
;
;
Gm;
Cm
; @
;
@
Dm
Hm
Am
@
@
l
Em
; @
;
@
l
Gm Fm
;
;
A
Beobachtung: Laufzeit k + log n Schritte bei k Treern!
Best-Match z.B. nde \nachstgelegenes" Record zu x = 7 y = 3 :
) Range-Query, statt Suchrechteck jetzt Suchkreis mit Radius gema Distanz-
funktion, wahrend der Baumtraversierung schrumpft der Suchradius. Ist erweiterbar auf k-best-Matches.
A best 5 6
m
;
;
x
m
; @
;
m
j
opt-best
j
best 9 4
C
opt 6
;
@
;
lbest 6Hj2
m
D
B
41
@
Wenn k ; d-Baum im Hindergrundspeicher liegt, dann verwende inhomogene
Variante:
interner Knoten enthalt Schlusselinformation
linker Sohnzeiger
rechter Sohnzeiger
Blatter verweisen in Hauptdatei
6 HHo
u
4 u; @ o
;
;
C
B
D
@
@
l
A
H
14 HHHr
8 u; @
;
;
@
@
G
7 HHr
HH
H
l
E
12 u; @ o
H
H
H
;
;
@
F
9
>
>
>
>
>
=
Index Datei
>
>
>
>
>
9
>
=
Hauptdatei
>
speichere zusammengehorende interne Knoten auf einen Block
Beispiel: ein Block fasse 7 interne Knoten
;@
;
@
;
@
;
@
;
@
;
@
;
@
;@
;@
;
@
;
@
;
@
;
@
;
@
;
@
;@
;@
;@
;@
; @
; @
; @
; @
;@
;@
;@
;@
;@
;@
;@
@ ;
@ ;
@ ;
@ ;
@ ;
@
;
@ ;;@
@ ;
;@ ;@
/n /n/n /n
Bewertung: k ; d-Baum ist statische Struktur, loschen und balancieren ist
aufwendig.
42
Statt anhand der Daten zu partitionieren, wird jetzt der Datenraum partitioniert.
3.11 Gitterverfahren
Bei konstanter Gittergroe wird der Datenraum in Quadrate fester Groe aufgeteilt, und Zeiger werden auf die Quadrate verwaltet.
Beispiel: 48 records, jeder Block kann 2 records aufnehmen.
Wahle Gitter mit 24 Quadraten.
Index enthalt bis zu 24 Zeiger.
Bei einer Query lade die Blocke, die in Frage kommen.
Oenbar: Quadrate nur gleichmaig ausgelastet bei Gleichverteilung. Im
Ballungsraum keine Wirkung
Also:
Quadratgroen den Datenmengen anpassen!
43
Grid File (Hinrichs & Nievergelt 1981)
fur beliebige Dimension k moglich, dynamische Struktur mit \2 Platten-Zugrisgarantie"
hier: Dimension 2
Buckets fur Datensatze
Grid-Direktory zum Finden der Bucket-Nr.
2 Skalen zum Einstieg ins Grid-Directory.
Skala (im Hauptspeicher)
var X: array 0 : : : max x] of attribut wert x
var Y: array 0 : : : max y] of attribut wert y
d.h. die Skalen enthalten die (momentane) Unterteilung der X- bzw. Y -Achse
y
3030
x
G
6
2500
2050
0 30 40 85 120 xi] i = 0 : : : max x
Gi] i = 0 : : : max x ; 1
@
I
@
@ Gitterzellen
800
6
0
30 40
85
- x Bucketbereich
120
Grid-Directory (im Hintergrundspeicher)
: : :max x - 1, 0: : :max y - 1] of pointer
d.h.
enthalt eine Bucketadresse, z.B. alle Punkte mit
30 < x 40 2050 < y 2500 sind im Bucket mit Adresse G1,2] zu nden
(im Beispiel gestrichelt umrandet).
Achtung: mehrere Gitterzellen konnen im selben Bucket liegen.
var G: array 0
Gx, y]
Bucket (im Hintergrundspeicher) = Block
44
Philosophie: Bei sich anderndem Datenbestand werden durch Modikation der
Skalen die Groen der Gitterzellen angepat.
LOOKUP fur x y.
Beispiel x = 100 y = 1000
Suche in Skala x den letzten Eintrag < x. Habe Index i = 3.
Suche in Skala y den letzten Eintrag < y. Habe Index j = 1.
Lade den Teil des Grid-Directory in den Hauptspeicher, der G#i j] enthalt.
Lade Bucket mit Adresse G#i j].
Beispiel:
1.000.000 Datensatze, 4 passen in einen Block
x und y haben 500 Unterteilungen
) G hat 250.000 Eintrage
bei 4 Bytes pro Zeiger und 1024 Bytes pro Block passen 250 Zeiger auf
einen Directory-Block
) es gibt 1000 Directory-Blocke
d.h. G#i j] ndet sich auf Block 2 j als i-te Adresse, falls i < 250
auf Block 2 j + 1 als (i ; 250)-te Adresse, falls i 250
exakt match benotigt 2 Plattenzugrie
range-query bestimmt zunachst die Gitterzellen, die in Frage kommen, und
liest dann die zugehorenden Buckets ein.
45
Dynamik des Gridle
Annahme: 2 Records pro Datenbucket
Splitting-Policy: Region halbieren, Dimension abwechseln
AB
AD
6
8
6
8
6
6
A
4
A
4
B
2
2
4
6
AE
8
10
12
C
2
14
2
E
8
6
A
@
4
C
2
B
D
2
4 ?6
G
AE
8
D
6
10
12
@
R
@
- BC
14
6
E
G
6
A
4
C
2
B
D
2 ?4 ?6
D
-
F
8
10
12
F
- BC
14
Grid-Directory hat 6 Zeiger auf insgesamt 5 Buckets,
x-Skala hat 3 Eintrage, y-Skala hat 2 Eintrage.
46
B
D
6
8
BC
6
4
6
8
10
12
14
Splitting Policy
Bei U berlauf eines Buckets, dessen Region aus einer Zelle besteht, entsteht eine
Gitterverfeinerung. (Annahme: 3 Records pro Datenbucket)
-
-
-
Hierzu Region halbieren, dabei Dimension abwechseln. Skala modizieren, Directory modizieren.
Bei U berlauf eines Buckets, dessen Region aus mehreren Gitterzellen besteht,
entsteht keine Gitterverfeinerung.
PPP
P
q
P
1
-
-
Achtung: Bei Verfeinerung einer Skala ist directory-Modikation erforderlich:
0 10 30 40 70 80 100 110
0 10 30 40 50 70 80 100 110
6
Beim U berlauf eines Directory-Blockes wird dieser halbiert und auf zwei Blocke
verteilt. Hierbei kann es zu einer Vergroberung der Skala kommen. Der Einstieg in den zustandigen Directory-Block erfolgt uber das Root-Directory im
Hauptspeicher mit vergroberten Skalen.
47
Beispiel: 3 Records pro Datenblock
4 Zeiger pro Directoryblock
300
Einfügen von A, B, C verursacht
A
einen Datenblock und
C
einen Directoryblock.
300
100
10 50
B
200
10
50
300
Einfügen von D verursacht
Datenblocksplit.
A
D
C
300
100
10 30 50
B
200
10
30
50
300
Einfügen von E
verursacht Datenblocksplit.
A
D
C
E
300
250
250
200
B
200
10
30
50
48
10 30 50
Einfügen von F verursacht
Datenblocksplit und
300
Directoryblocksplit.
F
A
D
C
E
250
300
300
250
250
200
10 20 30
200
30 50
B
200
10
20
50
30
Ein Directoryblock
kann seine Skala
in y-Richtung vergröbern.
300
F
D
A
C
E
300
250
250
200
300
10 20 30
B
200
10
20
30
50
Beispiel
49
200
30 50
Merging Policy legt fest
1. Wer ist Mischpartner?
2. Wann wird Mischen ausgelost?
zu 1) Mischpartner zu einem Bucket X kann nur ein Bucket Y sein, wenn die
Vereinigung der beiden Bucketregionen ein Rechteck bilden.
Grund: Zur ezienten Bearbeitung von Range-Queries sind \gradlinige"
Gitter sinnvoll!
-
Query testet 7 Punkte!
nicht
erlaubt
erlaubt
zu 2) wenn Bucket hochstens zu 30 % belegt ist und wenn vereinigtes Bucket
hochstens zu 70 % belegt sein wurde (um erneutes Splitten zu vermeiden)
Achtung:
Werden beliebige Nachbarn (mit Rechteckbedingung) als Mischpartner zugelassen, besteht Deacklockgefahr, d.h. trotz schlechter Blockausnutzung sind keine
weiteren Verschmelzungen mehr moglich.
50
3.12 Verwaltung geometrischer Objekte
Bisher: Punkte reprasentieren Attributkombinationen
Jetzt: Punkte reprasentieren geometrisches Objekt
Beispiel: Zu verwalten seien eindimensionale Intervalle
E
0
A
1
C
B
2
3
4
5
F
D
6
7
8
9
10
11
Ordne jedem Intervall zwei Zahlen zu, z.B. Anfang und Ende ) alle Eintrage
oberhalb der Diagonale, bei kurzen Intervallen in schmaler Bandbreite
rx
15 6
;
14
F
;
13
;
12
;
11
;
10
;
C D ;
9
;
8
;
7
E B
;
6
;
5
;
4
;
A
3
;
2
;
;
1
;
- lx
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Ordne jedem Intervall zwei Zahlen zu, z.B. Mittelpunkt und halbe Lange )
bessere Ausnutzung der Flache
dx
3 6
E
2
1
B
A
C
D
F
- cx
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
51
12
13
14
Typische Queries:
Gegeben Punkt P, nde alle Intervalle, die ihn enthalten.
Gegeben Invervall I, nde alle Intervalle, die es schneidet.
Ein Punkt P ist enthalten im Intervall mit Mitte cx und halber Lange dx ,
cx ; dx p cx + dx.
dx
4 6
Beispiel fur
p=5
AA
A
3
2
A
E
A
A
A
A
A
A A
1
C
B
D
A A
F
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
- cx
Ein Intervall mit Mitte p und halber Lange d schneidet ein Intervall mit Mitte
cx und halber Lange dx , cx ; dx p + d und cx + dx p ; d
dx
4 6
Beispiel fur
p = 10 d = 1
3
E
2
1
AA
A
A
B
A
A
A
A C
A
A
A D
A
A
F
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
- cx
Fazit: Es entstehen Range-Queries mit kegelformigem Abfragebereich.
Zur Verwaltung von orthogonalen Rechtecken in der Ebene bietet sich an: Ein
Rechteck wird reprasentiert als ein Punkt im 4-dimensionalen Raum, gebildet
durch die beiden 2-dimensionalen Punkte fur horizontale bzw. vertikale Lage.
Zu einem Query-Rechteck, bestehend aus horizontalem Intervall P und vertikalem Intervall Q, lassen sich die schneidenden Rechtecke nden im Durchschnitt
der beiden kegelformigen Abfragebereiche zu den Intervallen P und Q.
52
Nearest Neighbor im Gridle
Suche auf dem Datenblock, der fur den Querypoint Q zustandig ist, den nachstgelegenen Punkt P. Bilde Range-Query mit Quadrat um den Kreis um Q mit
Radius jP ; Qj. Schranke Quadratgroe weiter ein, falls nahere Punkte gefunden
werden.
P
R
Q
Idee zum Finden des nachsten Nachbarn im Gridle
53
4 Das Hierarchische Konzept
4.1 IMS-Begrie
Datenbanksysteme, die auf dem hierarchischen Datenmodell basieren, sind noch
sehr verbreitet, da sie sich aus Dateiverwaltungssystemen fur die konventionelle
Datenverarbeitung heraus entwickelt haben. Wir stellen hier das am meisten
verbreitete derartige Datenbanksystem vor: IMS (Information Management System) von IBM.
Grundlage einer IMS-Datenbank sind die PDBs (physical databases) jede PDB
besteht aus einer Menge von PDBRs (physical database records) eines bestimmten Typs. Ein PDBR-Typ entspricht einem Baum auf Typ-Ebene, eine PDB
entspricht einer Realisierung des Baumes, und ein zugehoriges PDBR entspricht
einem durch ein Wurzel-Entity erzeugten einzelnen Baum der Entity-Ebene, d.h.
ein Wurzel-Entity zusammen mit allen hierarchisch untergeordneten Entities.
Spieler
Name
Gebdatum
Adresse
PLZ
root segment
Segment-Typ
Position
Ort
Muller
Posnr
?
Posbez
PDBR-Typ
-
segment
occurrence
PDBR-occurrence
Jedes PDBR besteht aus Segmenten. Ein Segment entspricht einem Entity-Typ,
eine Auspragung davon heit segment occurrence und entspricht einem entity.
Die Wurzeln der Baume auf Entity-Ebene heien root segments. Jedes Segment
besteht aus elds (entsprechen den Attributen), Auspragungen davon heien
eld occurrence (entsprechen den Attributwerden).
Eine PDB wird beschrieben (als Baum der Typebene) durch eine DBD (data base description). Die Menge aller DBDs einschlielich einiger Transformationsregeln zwischen konzeptueller und interner Ebene ergibt das konzeptuelle
Schema.
54
Zusatzlich gibt es in zwei Verwendungen die LDB (logical database):
auf konzeptueller Ebene, um verschiedene PDBs durch logische Zeiger in
Beziehung zu setzen. Beschreibung erfolgt als DBD.
auf externer Ebene, um Benutzersichten darzustellen (Einschrankung auf
eine PDB bzw. konzeptuelle LDB). Beschreibung erfolgt durch den Anwendungsadministrator als PCB (program communication block).
Die Menge aller fur den Benutzer relevanten externen LDBs bilden sein externes Modell, die Menge aller zugehorigen PCBs werden in einem PSB (program
specication block) zusammengefat und bilden das externe Schema.
;
@
Benutzer
;
@
fCOBOLjPL/2g + DL/I
@
;
@
;
A
A
A
A
A
A
; Benutzer @
@ASS + DL/I;
PSB (externes Schema)
PCB
PCB
LDBE
LDBE : : :
@
@
@
@
DBD
PDB
;
;
DBD
LDBK
DBD
LDBK
;
;
;
@
@;
PCB
LDBE
:::
:::
Anwendungsebene
externe Ebene
;
;
:::
XXX
@
X;
XXX
@
X
;
DBD
PDB
:::
DBD
PDB
:::
Konzeptuelle Ebene
+ Teil der internen
Ebene bzw. Teil der
Transformationsregeln
konzeptuelles/internes Modell
physische Ebene
IMS-Datenbankarchitektur
55
4.2 Datenbeschreibung in IMS
Wir beschreiben den prinzipiellen Aufbau der DBDs anhand einer einfachen
PDB mit dem Namen XA, die aus einer hierarchischen Beziehung zwischen den
Segmenten PROJEKT und ANGEST besteht (Zeilen sind zu Referenzzwecken numeriert):
XA
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
DBD
SEGM
FIELD
FIELD
FIELD
FIELD
SEGM
FIELD
FIELD
FIELD
FIELD
NAME
NAME
NAME
NAME
NAME
NAME
NAME
NAME
NAME
NAME
NAME
=
=
=
=
=
=
=
=
=
=
=
XA, ACCESS = HIDAM
PROJEKT, BYTES = 182
(PNR,SEQ,U), BYTES = 6, START = 1
PNAME, BYTES = 20, START = 7
PLEITER, BYTES = 6, START = 27
PBESCHR, BYTES = 150, START = 33
ANGEST, PARENT = PROJEKT, BYTES = 30
(NAME,SEQ,M), BYTES = 20, START = 6
ANGNR, BYTES = 5, START = 1
ABTNR, BYTES = 2, START = 26
PROZARBZ, BYTES = 3, START = 28
Erlauterung: Es werden alle Segmente in ihrer hierarchischen Reihenfolge nacheinander beschrieben:
1.) Festlegung des Namens XA fur die PDB und der Zugrismethode. Es gibt
HSAM: hierarchical sequential access method
HISAM: hierarchical indexed sequential access method
HDAM: hierarchical direct access method
HIDAM: hierarchical indexed direct access method
2.) Wurzelsegment PROJEKT hat eine Gesamtlange von 182 Bytes
3.) Feld PNR ist 6 Bytes lang, beginnt bei Position 1 (relativ zum Segment).
PNR ist Sequenzfeld (SEQ), d.h. segment occurrences werden aufsteigend
nach PNR geordnet abgespeichert. \U" (unique) bedeutet, da PNR eindeutig
(pro Vater occurrence) ist.
7.) Das Segment ANGEST hat als Vater das Segment PROJEKT.
8.) \M" (multiple) im Sequenzfeld NAME erlaubt pro Vater occurrence mehrere
bzgl. NAME gleichlautende Sohne.
Man beachte, da ein Teil dieser Angaben nach unserer Notation nicht zum
konzeptuellen, sondern zum internen Schema gehort.
Entities vom Typ ANGEST sind nur als Sohne vom Segment PROJEKT zu erreichen. Mochte man die Angestellten auch fur sich alleine verarbeiten, so mu
56
man alle ANGEST-Entities dupliziert in einer weiteren PDB, z.B. mit dem Namen XB, halten. (Das Feld PROZARBZ ist hier weggelassen, statt dessen wurde
zusatzlich ein Feld ANSCHRIFT eingefuhrt.)
XB
DBD
SEGM
FIELD
FIELD
FIELD
FIELD
NAME
NAME
NAME
NAME
NAME
NAME
=
=
=
=
=
=
XB, ACCESS = HIDAM
ANGEST, BYTES = 67
(ANGNR ,SEQ), BYTES = 5, START = 1
NAME, BYTES = 20, START = 6
ANSCHRIFT, BYTES = 40, START = 26
ABTNR, BYTES = 2, START = 66
Folgende Probleme sind oensichtlich:
Daten werden doppelt gespeichert
Zusammenhang zwischen XA und XB ist nur dem Anwendungsprogrammierer bekannt.
Dieser Mistand wird durch die Einfuhrung einer logischen Datenbank auf konzeptueller Ebene behoben. Statt der PDB XA wird eine PDB XC deniert,
welche als Sohn von PROJEKT einen Entity-Typen PA enthalt. PA besitzt einen
Zeiger auf das Segment ANGEST in der PDB XD:
XC:
PROJEKT
XD:
ANGEST
XE:
PROJEKT
6
PA
PROJANG
PROZARBZ
ANGEST PROZARBZ
PDB-Ebene
LDB-Ebene
Kante eines physischen Baumes (physisch realisiert)
(PROJEKT \physischer Vater" von PA)
-
Zeiger (physisch realisiert)
(ANGEST \logischer Vater" von PA)
Kante eines logischen Baumes
(nicht physisch realisiert)
Redundanzfreie Speicherung mittels einer
konzeptuellen LDB
57
Wir nennen PA den physischen Sohn von PROJEKT und den logischen Sohn von
ANGEST entsprechend heit PROJEKT der physische Vater von PA und ANGEST
der logische Vater.
Die Beschreibung der PDBs
tangaben sind weggelassen):
XC
XD
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
DBD
SEGM
FIELDs
SEGM
XC
und XD sieht aus wie folgt (Bytes- und Star-
FIELD
FIELD
NAME = XC, ACCESS = HIDAM
NAME = PROJEKT,
f
ur PROJEKT wie in DBD f
ur XA
NAME = PA, POINTER = (LPARNT,
),
PARENT = (PROJEKT,(ANGEST, XD)),
NAME = (NAME, SEQ, M),
NAME = PROZARBZ,
DBD
SEGM
LCHILD
FIELDs
NAME = XD, ACCESS = HIDAM
NAME = ANGEST,
NAME = (PA, XC)
f
ur ANGEST wie in DBD f
ur XB
<
<
:::
:::
>
:::
:::
:::
:::
>
4.) Ein Zeiger zum logischen Vater ist einzurichten.
5.) Es wird der physische (PROJEKT) und logische Vater (ANGEST in der PDB
XD) genannt.
6.) Es wird NAME (aus dem Segment ANGEST) als Sequenzfeld angegeben.
10.) Es wird vermerkt, da PA in der PDB XC das logische Kind ist von ANGEST.
Beide DBDs werden nun zusammengefat zu einer LDB
Segment angegeben wird, wo seine Quelle SOURCE liegt:
XE
1.
2.
3.
4.
5.
DBD
DATASET
SEGM
SEGM
, in der fur jedes
XE
NAME = XE, ACCESS = LOGICAL
LOGICAL
NAME = PROJEKT, SOURCE = (PROJEKT, XC)
NAME = PROJANG,PARENT = PROJEKT,
SOURCE = ((PA,XC), (ANGEST, XD))
1.) Die DBD XE existiert nicht physisch, sondern logisch.
3.) PROJEKT ndet sich als PROJEKT in XC.
5.) PROJANG erhalt man als Ersetzung des Zeigers PA in XC durch das Segment
ANGEST ind XD.
58
Das \Einhangen" von Teilbaumen kann an beliebiger Stelle geschehen:
A
Y 1:
PDB-Ebene:
Y 2:
B
D
C
E
C
J
Y 3:
F
C
66
G
Y 4:
LDB-Ebene:
H
A
B
Y 5:
C
G
D
J
C
H
G
H
Eine many-many-Beziehung wird durch ein Zeigerpaar realisiert:
PDB-Ebene:
LDB-Ebene:
XF:
XG: -
PROJEKT ANGEST
PA
AP
PROZARBZ
PROZARBZ
XH: PROJEKT
XJ:
ANGEST
PROJANG
ANGPROJ
ANGEST PROZARBZ
PROJEKT PROZARBZ
59
Die DBDs fur XF und XG weisen auf das paarweise Auftreten der Zeiger PA und
AP einmal durch das Wort PAIRED hin, zum anderen wird bei der Angabe des
logischen Kindes zu PROJEKT der inverse Zeiger PA erwahnt und bei Angabe des
logischen Kindes zu ANGEST der inverse Zeiger AP erwahnt.
XF
DBD
SEGM
LCHILD
FIELDs
SEGM
<
FIELD
FIELD
XG
DBD
SEGM
LCHILD
FIELDs
SEGM
<
FIELD
FIELD
NAME
NAME
NAME
f
ur
NAME
PARENT
NAME
NAME
= XF, ACCESS = HIDAM
= PROJEKT,
= (AP,XG), PAIR = PA
PROJEKT wie in DBD f
ur XA
= PA, POINTER = (LPARNT, PAIRED,
= (PROJEKT, (ANGEST, XG)),
= (NAME, SEQ, M),
= PROZARBZ,
NAME
NAME
NAME
f
ur
NAME
PARENT
NAME
NAME
= XG, ACCESS = HIDAM
= ANGEST,
= (PA, XF), PAIR = AP
ANGEST wie in DBD f
ur XB
= AP, POINTER = (LPARNT, PAIRED,
= (ANGEST, (PROJEKT, XF))
= (PNR, SEQ),
= PROZARBZ,
:::
>
:::
:::
:::
: : :),
:::
>
:::
:::
:::
: : :),
Der Aufbau der logischen LDBs XH und XJ geschieht analog zu XE.
4.3 Die externe Ebene von IMS
Eine IMS-Datenbank besteht auf der konzeptuellen Ebene aus einer Menge von
PDBs und LDBs.
Da der Benutzer i.a. nicht die gesamte Datenbank sehen soll, wahlt er durch
eine externe LDBE die fur ihn relevanten Teile der konzeptuellen PDBs und
LDBK aus.
Diese LDBE besteht aus LDBRE s eines LDBRE -Typs dieser LDBRE -Typ ist
ein Teil eines PDBR-Typs oder LDBRK -Typs und entsteht durch Weglassen
von mehreren oder auch null Segmenten des unterliegenden PDBR-Typs. Mit
einem Segment s mu auch der gesamte Teilbaum, der s als Wurzel hat, gestrichen werden. Die root-Segmente von LDBRE und PDBR sind identisch.
Jede LDBE eines Benutzers wird beschrieben durch einen PCB (Program Communication Block), der den Namen der zugrunde liegenden PDB oder LDB, das
Wurzelsegement und die fur die LDBE benogtigten Segmente, die sogenannten
sensitiven Segmente (SENSEG), angibt. Zu jedem sensitiven Segment mu der
60
unmittelbare Vorganger (PARENT) sowie eine Verarbeitungsart (PROCOPT
= Processing Option) speziziert werden moglich sind dabei
G
R
I
D
fur get
fur replace
fur insert
fur delete
(nur Lesen erlaubt)
(Lesen und Schreiben erlaubt)
(Einfugen erlaubt)
(Loschen erlaubt)
sowie beliebige Kombinationen davon. Es mu immer ein vollstandiger Weg angegeben werden, d.h. alle Segmente, die auf dem Weg von der Wurzel (einschlielich) bis zum angesprochenen Entity liegen, mussen sensitiv sein. Soll ein
Benutzer nicht alle dazwischen liegenden Entities sehen, wird durch PROCOPT =
K die sogenannte key sensitivity deniert, welche von einem Segment nur den
Schlussel sichtbar macht.
Beispiel: Folgender PCB prasentiert die LDBK Y4 dem Benutzer als
\seine" LDBE Y6:
Y6 PCB
TYPE = DB, DBDNAME = Y4, : : :
SENSEG
SENSEG
SENSEG
SENSEG
Y 4:
NAME
NAME
NAME
NAME
=
=
=
=
A,
B,
C,
G,
PROCOPT = G
PARENT = A, PROCOPT = G
PARENT = A, PROCOPT = K
PARENT = C, PROCOPT = I, D
A
B
Y 6:
C
G
D
B
H
A
C
G
PDBR-Typ oder
LDBRK -Typ
LDBRE -Typ
IMS prasentiert die LDBE immer nur so, als ob sie tatsachlich in dieser Form
existiert, d.h. die nicht sensitiven Segmente (genauer: occurrences) werden beim
Baumdurchlauf ubersprungen.
Achtung: Ist S ein sensitives Segment, in dessen Teilbaum nichtsensitive Elemente enthalten sind, so werden beim Loschen eines S-occurrence alle davon
abhangigen occurrences, auch die nicht-sensitiven, geloscht. Der Benutzer bleibt
daruber im unklaren!
61
4.4 Datenmanipulation in IMS
Als DML (data manipulation language) steht in IMS die sogenannte DL/1 (data
language 1) zur Verfugung, die durch Prozeduraufrufe aus dem Anwenderprogramm (COBOL, Pl/I, IBM-Assembler) realisiert wird. Die Befehle von DL/1
verursachen immer zunachst einen Einstieg ins Wurzelsegment und dann ein
Durchlaufen des Baumes gema seiner hierarchischen Ordnung.
Zur Festlegung dieser Ordnung denieren wir fur jedes segment
den HSKV (hierarchical sequence key value) wie folgt:
occurrence
s
HSKV(s) := HSKV (vater(s))
Typnr(s)
sequenzfeld(s)
Existiert kein Vater, so ist der entsprechende HSKV leer. Die Typnr fur Segmente erhalten wir durch fortlaufende Nummerierung der Knoten im PDBRTyp-Baum gema einem Preorder-Durchlauf. Alle segment occurrences sind
nun geordnet in aufsteigender Folge ihrer HSKVs.
Zur Identizierung eines Segments verwenden wir den FCK (fully concatenated key). Er besteht aus dem HSKV ohne Typnummern.
Folgende Befehle (stark vereinfachte Syntax) gibt es in DL/1:
GU
get unique
GN
GNP
get next
get next within parent
GHU
GHN
GHNP
ISRT
DLET
REPL
get hold unique
get hold next
get hold within parent
insert
delete
replace
direkter Zugri ab Wurzel auf erstes
Segment
sequentiell ab aktueller Position
sequentiell innerhalb des am aktuellen Vater hangenden Teilbaums
wie oben, aber DLET oder REPL geplant
wie oben, aber DLET oder REPL geplant
wie oben, aber DLET oder REPL geplant
fuge ein
losche
ersetze
Die Operationen bekommen als Argument ggf. eine Folge von SSAs (segment
search arguments), die aus einem Segmentnamen und mehreren Bedingungen
bestehen. Die SSAs mussen angegeben werden fur alle Segmente langs des Pfades von der Wurzel bis zum referierten Segment. Als aktueller Vater gilt immer
das zuletzt mit GU oder GN angesprochene Segment. Die aufgerufene Prozedur
liefert neben mehreren Statusmeldungen eine boolesche Variable GEFUNDEN
zuruck, die signalisiert, ob der Zugri erfolgreich war.
Vor Anwendung von ISRT oder RPL mu ein entsprechendes Segment mit den
62
neuen bzw. zu andernden Daten im I/O-Bereich vorbereitet werden.
Das SSA kann optional einige sogenannte Command Codes enthalten. Die beiden wichtigsten sind D (data) und F (first):
D bewirkt, da nicht nur das referierte Segment zuruckgeliefert
F
wird, sondern auch samtliche Segmente auf dem Weg von der
Wurzel bis dorthin.
bewirkt, da ein GNP-Befehl nicht innerhalb des aktuellen Vaters eine Vorwartssuche auslost, sondern einen Rucksprung
zum ersten (naher bezeichneten) Segment des aktuellen Vaters bewirkt.
Die folgenden Befehle beziehen sich auf das Beispiel Schulungsrma (Seite 66).
1.) Finde den ersten Kurs mit Durchfuhrungsort Dublin:
GU COURSE
OFFERING (LOCATION = 'DUBLIN')
2.) Drucke alle Horer ab dem ersten Kurs in Madrid:
GU COURSE
OFFERING (LOCATION = 'MADRID')
STUDENT
while gefunden do
begin
write (STUDENT.NAME)
GN STUDENT
end
63
3.) Drucke alle Horer mit Note A ab dem ersten Kurs in Madrid:
GU COURSE
OFFERING (LOCATION = 'MADRID')
STUDENT (GRADE = 'A')
while gefunden do
begin
write (STUDENT.NAME)
GN STUDENT (GRADE = 'A')
end
4.) Drucke alle Horer des Kurses M23 am 13. August 1973:
GU COURSE (COURSE] = 'M23')
OFFERING (DATE = '730813')
if gefunden then
begin
GNP STUDENT
while gefunden do
begin
write (STUDENT.NAME)
GNP STUDENT
end
end
5.) Drucke Kursbeschreibung zum Kurs, der in Dublin stattndet:
GU COURSE D
OFFERING (LOCATION = 'DUBLIN')
if gefunden then write (COURSE.DESCRIPN)
64
6.) Drucke Dozentennamen des ersten Studenten mit Namen Meier:
fertig := false
GU COURSE
OFFERING
while gefunden and not fertig do
begin
GNP STUDENT (NAME = 'MEIER')
if gefunden then
begin
GNP TEACHER F
write (TEACHER.NAME)
fertig := true
end else GN OFFERING
end
7.) Fuge fur Kurs M23 als weitere Voraussetzung M18
PREREQ.COURSE] := 'M18'
(Analysis)
ein:
PREREQ.TITLE
:= 'ANALYSIS'
ISRT COURSE (COURSE = 'M23')
PREREQ
]
8.) A ndere uberall die Schreibweise des Dozentennamens Meier in Meyer:
GHU COURSE
OFFERING
TEACHER (NAME = 'MEIER')
while gefunden do
begin
TEACHER.NAME := 'MEYER'
REPL
GHN TEACHER (NAME = 'MEIER')
end
9.) Losche alle Studenten Meier:
GHU COURSE
OFFERING
STUDENT (NAME = 'MEIER')
while gefunden do
begin
DLET
GHN STUDENT (NAME = 'MEIER')
end
65
Beispiel: Schulungsrma
LDBR-Typ:
COURSE
COURSE#
TITLE
PREREQ
DESCRIPN
OFFERING
COURSE# TITLE
DATE LOCATION FORMAT
TEACHER
STUDENT
EMP#
EMP#
NAME
NAME GRADE
Auspragung:
COURSE
M 23
PREREQ
PREREQ
M 19
Calculus
M 16 Trigonometry
:::
Dynamics
750106
741104
730813
Oslo
Dublin
F2
F3
Madrid
F3
761620
Tallis, T.
OFFERING
OFFERING
OFFERING
TEACHER
421633
Sharp, R.
B
183009 Gibbons, O. A
102141
Byrd, W.
66
B
STUDENT
STUDENT
STUDENT
4.5 Speicherorganisation fur IMS
Jede PDB bildet eine Speichereinheit (z.B. ein Magnetband), in der alle segment occurrences abgespeichert sind. Jedes segment occurrence wird in einem
sogenannten \stored segment" abgelegt, zusammen mit einem Prex, der Informationen uber Loschbit, Segment-Typ und Zeiger enthalt. Der Prex ist transparent fur den Benutzer. Es gibt vier Methoden, um die hierarchische Ordnung
zu verwalten:
HSAM (Hierarchical Sequential Access Method)
Die hierarchische Reihenfolge der segment occurrences wird durch physikalische Anordnung der stored segments realisiert, d.h. strikt sequentiell (ohne Zeiger) hintereinander. Mehrere stored segments sind in einem stored record fester
Lange zusammengefat. Spanned segment occurrences, d.h. Record-uberschreitende Segmente, sind nicht erlaubt. HSAM-Dateien liegen auf Magnetbandern,
sie erlauben nur Lese- bzw. Kopieroperationen und sind fur Backup-Zwecke geeignet.
HISAM (Hierarchical Indexed Sequential Access Method)
Die Root-Segmente sind indiziert, d.h. sie sind uber eine Indexdatei erreichbar,
welche als Schlussel die Sequenzfelder der Root-Segmente benutzt. Alle \Nachkommen" (Sohne, Enkel etc.) eines Root-Segments sind in einer weiteren Datei
zu nden, in der sie in einfach verketteten Listen gema ihrer hierarchischen
Reihenfolge abgelegt werden:
ISAM data set
COURSE PREREQ M 16
M 23
COURSE PREREQ
Q
M 27
L02
OSAM data set
PREREQ
OFFERING TEACHER STUDENT
730813
421633
102141
:::
3 M 19
- STUDENT
OFFERING OFFERING
741104
75106
761620
Q
s OFFERING TEACHER TEACHER
Q
740602
421633
Beispiel fur HISAM-Organisation
67
502417
HDAM + HIDAM (Hierarchical Direct Access Method + Hierarchical Indexed Direct Access Method)
Bei HDAM und HIDAM sind die segment occurrences durch Zeiger miteinander
verkettet. Es gibt
hierarchische Zeiger (zeigen auf das nachste segment occurrence gema der
hierarchischen Ordnung)
Kind/Zwilling Zeiger (zeigen auf das jeweils erste segment occurrence jedes
Kindes und des nachsten Zwilling)
Zusatzlich zu diesen Zeigern gibt es zum Zugri auf die root occurrences in
HDAM eine Hashorganisation und in HIDAM eine Indexdatei.
Beispiele fur hierarchische Zeiger und fur Kind/Zwilling-Zeiger:
COURSE M 23
PREREQ M 19 PP
PP
PREREQ M 16 ;
PP
?
OFFERING 750106
OFFERING 741104 ;
P
q OFFERING 730813 6
P
STUDENT 761620
TEACHER 421633 PP
P
STUDENT 183009
;
STUDENT 102141 ;
PP
q
P
;
COURSE M 236
PREREQ M 19
PREREQ M 16 ;
?
OFFERING 750106
? OFFERING 741104 ;
OFFERING 730813 ;
STUDENT 761620
?
TEACHER 421633
? STUDENT 183009 ;
STUDENT 102141 ;
68
;
5 Das Netzwerk-Konzept
5.1 Vorbemerkung
Seit Anfang der 70er Jahre erarbeitet die DBTG (Data Base Task Group) der
CODASYL (Conference on Data Systems Languages) Vorschlage zur Realisierung von Netzwerk-Datenbanken. Inzwischen liegen (vorlauge) Spezikationen
und auch Implementationen vor fur eine
DDL (Data Denition Language) und
DML (Data Manipulation Language).
Beide Sprachen sind eingebettet in die Wirts-Sprache COBOL und verwenden
selbst zahlreiche COBOL-Konstrukte.
5.2 Grundidee
Im Netzwerk-Konzept besteht eine Datenbank aus records verschiedener Typen.
Zur Modellierung von many-one-relationships gibt es sogenannte Set-Typen,
die zwei Record-Typen zueinander in Beziehung setzen. Ein Record-Typ (z.B.
AUTOR) u
bernimmt mittels eines Set-Typs (z.B. SCHREIBT) die Rolle des owner
bzgl. eines weiteren Record-Typs (z.B. BUCH), genannt member.
owner-Typ:
AUTOR
set-Typ:
SCHREIBT
member-Typ:
BUCH
owner occurrence
6
Simmel set occurrence
- Der Henker -
Selber
atmen
- Richtig
Streiken
6
@
I
;
@ member occurrence ;
Der Owner-Typ mu verschieden sein vom member-Typ. Jeder Record-Typ besitzt gewohnlich mehrere Felder bei kunstlichen Kett-Records zur Realisierung
von many-many-Beziehungen konnen diese auch fehlen.
69
Die einzige Operation auf dem Netzwerk ist die Navigation. Hierbei gelangt man
von einem record-occurrence langs der Verbindungen zu einem weiteren record
occurrence. Die Kommunikation des Benutzers mit dem Netzwerk geschieht uber
die UWA (User Working Area). Sie enthalt
Platzhalter fur jeden Record-Typ
currency indicators,
nicht explizit zuganglich, vermerken fur jedes Anwendungsprogramm pro
Record-Typ und pro Set-Typ das zuletzt besuchte record occurrence bzw.
set occurrence
Statusinformation,
z.B. die boole'sche Variable GEFUNDEN, die angibt, ob die gewunschte Operation erfolgreich war.
5.3 DDL (Data Denition Language) der DBTG
Wir beschreiben die DDL anhand eines Beispiels.
Denition eines Netzwerks mit zwei Record-Typen:
1. schema name is Verlag
2. record name is Autor
3. 02 Vorname pic X(15)
4. 02 Nachname pic X(15)
5. 02 Jahrgang pic 99
6. key Gesamtname is ascending Nachname ascending Vorname
7. duplicates are not allowed
8. location mode is direct
9. record name is Buch
10. 02 Titel pic X(30)
11. 02 Preis pic 9(3)
12. key Titel is ascending Titel
70
Erlauterung:
1.)
2.)
3.)
5.)
6.)
Das gesamte Netzwerk heit `Verlag'
Denition des Record-Typs `Autor'
COBOL-Denition fur 15-Character-String
COBOL-Denition fur 2-stellige Zahl
alle Autoren-Records konnen bzgl. Nachname und Vorname geordnet durchlaufen werden
7.) Der unter 6. denierte key ist tatsachlich ein Schlussel
8.) Ein Autor-Record kann mittels Hashfunktion direkt angesprungen werden
11.) COBOL-Denition fur 3-stellige Zahl
Denition eines Set-Typen:
1. set name is Schreibt
2. owner is Autor | System
3. order is first | last | next | prior | system default |
sorted by defined keys
4. member is Buch
5. insertion is automatic | manual
6. retention is fixed | mandatory | optional
7. key is ascending Titel
8. set selection is thru Schreibt
9. owner identified by application | by key
71
Erlauterung:
1. Name des Set-Typs lautet `Schreibt'
2. \Singulare Sets" haben als owner `System', sie haben nur ein set-occurrence.
3. Der Einfugepunkt eines neuen member in einem Owner-Ring wird bestimmt:
sorted by defined keys: gem
a Schlussel-Information
first: direkt hinter dem owner (erste Position)
last: als letzter vor dem owner (letzte Position)
next: hinter dem current of set-type
Owner
prior: vor dem current of set-type
;
YH ;last
H
@
system default: egal
;
H
rst@
m
R
@
m
7 A
1A
A
U
A
9 sorted
m
einzufugender
Member
m
10
HH
H
;
;
i
P
P
;next PP
6
m
;
- 11
I
@
current of set-type
prior
4. member ist der Record-Typ `Buch'
5. Das Einfugen geschieht
automactic: automatisch gem
a Punkt 3 durch STORE
manual: die Einf
ugestelle mu \von Hand" aufgesucht werden
und wird dann mit Connect gefullt
6. Das Loschen einer record-occurrence wird geregelt:
fixed: record stirbt mit seinem jetzigen owner
mandatory: record mu member dieses Set-Typs bleiben
optional: record darf auch ohne diesen Set-Typ existieren
7. Ordnungskriterium fur `sorted by defined keys' (3.)
8. Vorspann zu 9
9. Die Festlegung des owner geschieht durch
application: ein konkretes owner-occurrence wird durch den
Benutzer aktiviert (current of set-type),
by key: ein konkretes owner-occurrence wird durch einen Schl
ussel
in der UWA aktiviert
72
m
14
5.4 DML (Data Manipulation Language) der DBTG
Mit der DML navigiert der Benutzer durch die Datenbank. Zur Orientierung
und als Bezugspunkt dienen die (bereits in 5.2 erwahnten) currency indicators.
Es gibt
current of run unit
Der Satz der Datenbank, egal welchen Typs, auf den zuletzt zugegrien
wurde
current of record type
Fur jeden Record-Typ wird festgehalten, auf welches record occurrence
zuletzt zugegrien wurde
current of set type
Fur jeden Set-Typ wird festgehalten, auf welches record occurrence (kann
owner oder member sein) zuletzt zugegrien wurde. Da sets vom gleichen
Typ disjunkt sind, identiziert der current of set type damit genau ein set
occurrence.
Ware
Apfel
Birne
Nr Bezeichnung
Tomate
6
Wb
Bestellung
Anz
- 30
- 18
- 12
- 24
- 22
- 18
Pb
?
Person
Nr
Name
Netzwerk
Lehmann
Auspragung
73
Schulz
Meier
Anhand eines konkreten Programms, welches auf dem Schema \Teutoramsch"
operiert, soll die typische DML-Syntax und die Auswirkung auf die currency indicators demonstriert werden. Das Programm druckt alle Waren aus, die Schulz
bestellt hat.
1.)
2.)
3.)
4.)
5.)
6.)
7.)
8.)
9.)
10.)
11.)
12.)
13.)
PERSON.NAME := 'SCHULZ'
FIND ANY PERSON USING NAME
IF GEFUNDEN THEN
BEGIN
FIND FIRST BESTELLUNG WITHIN PB
WHILE GEFUNDEN DO
BEGIN
FIND OWNER WITHIN WB
GET WARE
WRITE(WARE.BEZEICHNUNG)
FIND NEXT BESTELLUNG WITHIN PB
END
END
Erlauterungen:
1.) In der UWA (User Working Area) wird ein Platzhalter vom Typ PERSON
besetzt.
2.) Wenn in der Record-Beschreibung fur PERSON \location mode is direct"
angegeben wurde, so ist mittels des dort angegebenen Schlussels der direkte Zugri moglich. Gilt \duplicates allowed", so wird ein erster Treer
ermittelt.
5.) Innerhalb des Set-Typs PB wird nun das erste member vom Typ BESTELLUNG
angesprungen.
8.) Von diesem Record wird der owner bzgl. des Set-Typs WB angesprungen.
9.) Dessen Inhalt wird in die user working area geladen.
10.) Ausgabe unter Benennung der Feldbezeichner
11.) Das nachste member im Set-Typ PB wird ermittelt.
74
Die Befehle haben die folgenden Auswirkungen auf die currency indicators:
Current of : : :
Nr. run unit Person
2 Schulz Schulz
5
12
Schulz
8 Apfel Schulz
11
18
Schulz
8 Birne Schulz
Bestellung
12
12
18
18
Ware
Apfel
Apfel
Birne
PB
WB
Schulz
12
12
12
Apfel
18
18
18
Birne
Im Beispiel wurden bereits behandelt:
1. FIND ANY <RECORD-NAME> USING <KEY>
2. FIND FIRST <RECORD-NAME> WITHIN <SET-NAME>
3. FIND NEXT <RECORD-NAME> WITHIN <SET-NAME>
4. FIND OWNER WITHIN <SET-NAME>
5. GET <RECORD-NAME>
Weitere Befehle lauten:
6. FIND FIRST <RECORD-NAME>
FIND NEXT <RECORD-NAME>
Es werden alle Satze einen Typs sequentiell durchlaufen gema der Angabe
\key : : : is : : :" in der Record-Denition.
7. FIND : : : USING <FIELD-LIST>
Bei der Auswahl des nachsten Record wird verlangt, da er bzgl. der Feldbezeichner aus der <FIELD-LIST> mit in der UWA abgelegten Werten
ubereinstimmt.
Beispiel (gesucht ist die nachste Birnenbestellung):
WARE.BEZEICHNUNG := `BIRNE'
FIND NEXT WARE USING BEZEICHNUNG,
8.
FIND CURRENT <RECORD-NAME>
Der current of <RECORD-NAME> wird zur current of run unit gemacht.
Dies ist vor manchen Befehlen erforderlich, die sich auf die current of run
unit beziehen (z.B. GET, ERASE, : : :).
9. FIND CURRENT WITHIN <SET-NAME>
Der current of <SET-NAME> wird zur current of run unit gemacht. Siehe
8.
10. FIND : : : RETAINING <RECORD-NAME> CURRENCY
Es wird kein current of record type verandert.
75
11.
: : : RETAINING <SET-NAME> CURRENCY
Es wird der current of <SET-NAME> nicht verandert.
FIND
Beispiel:
Von Personen, die Birnen kaufen, drucke Namen und Anzahl der Bestellungen.
ware.bezeichnung := 'Birne'
find any ware using bezeichnung
if gefunden then
begin
find first bestellung within WB
while gefunden do
begin
find owner within PB
get person
write (person.name)
find first bestellung within PB retaining WB currency
while gefunden do
begin
get bestellung
write (bestellung.anz)
find next bestellung within PB retaining WB currency
end
find next bestellung within WB
end
end
sonst geht's hier schief
12.
<RECORD-NAME>
Ein neuer Satz vom Typ <RECORD-NAME> wird abgespeichert. Zuvor mussen
seine Felder in der UWA besetzt werden. Der abgespeicherte Satz wird zur
current of run unit, zum current of record type seines Record-Typs und
zum current of set type fur jeden Set-Typ, in dem sein Typ owner-Typ ist,
oder in dem sein Typ AUTOMATIC member ist.
Zugleich werden alle Einfugungen in die Sets vorgenommen, fur die dies
in der Set-Denition (INSERTION IS AUTOMATIC) vorgesehen ist. Das konkrete Set-occurrence, in das eingefugt werden soll, wird gema den Angaben der SET SELECTION ausgewahlt, d.h. entweder vom Benutzer durch
Setzen des current of set type oder durch Setzen des Schlussels.
STORE
76
Beispiel fur STORE:
Lehmann bestellt 10 Birnen
(Es sei im set WB und PB jeweils angegeben ``insertion
is automatic''
person.name := 'Lehmann'
find any person using name
ware.bezeichnung := 'Birne'
find any ware using bezeichnung
bestellung.anzahl := '10'
STORE bestellung
13.
14.
15.
16.
17.
18.
<RECORD-NAME>
Es wird der aktuelle Satz der run unit, die vom Typ <RECORD-NAME> sein
mu, entfernt. Danach ist current of run unit undeniert. Die Auswirkungen auf die member des zu loschenden Satzes hangen von der retentionKlasse der Sets ab, in denen er owner ist.
MANDATORY: es d
urfen keine member vorhanden sein.
OPTIONAL:
member werden aus dem Set herausgenommen, verbleiben
aber in der Datenbank.
FIXED:
member werden ebenfalls geloscht.
ERASE ALL <RECORD-NAME>
Er wird der aktuelle Satz der run unit entfernt und (rekursiv) alle seine
member.
CONNECT <RECORD-NAME> TO <SET-NAME>
Es wird der akuelle Satz der run unit, die vom Typ <RECORD-NAME> sein
mu, eingefugt in den current of <SET-NAME>.
DISCONNECT <RECORD-NAME> FROM <SET-NAME>
Es wird der aktuelle Satz der run unit aus dem current of < SET-NAME>
entfernt (nur moglich, wenn Mitgliedschaft OPTIONAL).
RECONNECT <RECORD-NAME> WITHIN <SET-NAME>
Es wird die current of run unit umgehangt. Beispiel:
(a) Bestimme den neuen current of set type S.
(b) Bestimme das umzuhangende Element vom Typ R mit der Klausel
: : : RETAINING S CURRENCY.
(c) Hange R in den Set S mit der Klausel
RECONNECT R WITHIN S.
MODIFY <RECORD-NAME>
In der current of run unit werden die in der UWA vorbereiteten Werte
ubernommen (dies kann Auswirkungen auf die Sortierreihenfolge haben).
ERASE
77
.)
6 Das Relationale Konzept
Seien D1 : : : Dk Wertebereiche fur Auspragungen der Attribute A1 : : : Ak .
Eine Relation ist eine Teilmenge des kartesischen Produktes, d.h.
R D1 D2 : : : Dk . Eine Relation lat sich speichern als Tabelle mit
Zeile i = i-tes Tupel
Spalte j = Dj
Spalten sind bezeichnet mit Attributnamen.
Entity-Typ: Tabelle mit Spalten fur Attribute
Relationship-Typ: Tabelle mit Spalten fur Schlussel der beteiligten Entity-Typen
Student: mat nr Name hort: matr nr
123456 Meier
123456
765432 Schulz
123456
765432
vor nr Vorlesung: vor nr Titel
4711
4711 Algebra
8643
8643 Analysis
8643
Abfragesprachen fur das relationale Datenmodell
1.) Algebraische Sprachen:
verknupfe Relationen durch Operatoren \ : : :
2.) Relationenkalkul:
beschreibe Eigenschaften mit Hilfe der Pradikatenlogik 1. Stufe ^ _ : 9 8
3.) SQL
in kommerziellen Systemen, Mischung aus 1 + 2
4.) Query by example
(fur Analphabeten)
6.1 Relationenalgebra
Operanden: Menge von Relationen (endlich)
Operatoren: Vereinigung
Dierenz
Kartesisches Produkt
Projektion
Selektion
Durchschnitt
Quotient
Verbund
naturlicher Verbund
78
9
>
>
=
unabhangig
>
>
9
>
=
ableitbar
>
Beispiel:
R: A
a
d
f
B
b
a
b
C S: D E F
c
b g a
f
d a f
d
Vereinigung (gleiche Stelligkeit fur R und S)
U := R S := ftjt 2 R _ t 2 S g
a
d
f
b
b
a
b
g
c
f
d
a
Dierenz (gleiche Stelligkeit fur R und S)
D := RnS := ftjt 2 R ^ t 62 S g
a b c
f b d
Kartesisches Produkt
Sei R k-stellig, sei S l-stellig.
C := R S := ft = t1 : : :tk tk+1 : : :tk+l jt1 : : :tk 2 R ^ tk+1 : : :tk+l 2 S g
A
a
a
d
d
f
f
B
b
b
a
a
b
b
C
c
c
f
f
d
d
D
b
d
b
d
b
d
E
g
a
g
a
g
a
F
a
f
a
f
a
f
Projektion
Sei R k-stellig, i1 i2 : : : in verschiedene Zahlen zwischen 1 und k
P := i i :::in (R) := fti ti : : :tin jt = t1 t2 : : :tk 2 Rg
1
2
1
2
13(R) = a c = AC (R)
d f
f d
B (R) = a
b
79
Selektion
Sei F eine boole'sche Formel, bestehend aus
Operanden:
Konstante oder
Attributnamen oder
Attributnummern
arithmetische Operatoren: < = > 6= logische Operatoren:
^ _ : (und oder nicht)
S := F (R) := ft 2 RjF ist wahr fur tg
(B= b ) (R) : a b c
f b d
0
0
Zusatzliche Operatoren, ableitbar:
Durchschnitt
D := R \ S := ftjt 2 R ^ t 2 S g d a f
= Rn(RnS)
Verbund
R '$
S
'$
RnS
&%
&%
Sei R r-stellig, S s-stellig, ' ein Vergleichsoperator = < > 6=.
R i1j S := ft = t1 : : :tr+s jt1 : : :tr 2 R tr+1 : : :tr+s 2 S ti 'tj 1 i r 1 j sg
= ir+j (R S)
A B C D E F
R A<E
1 S a b c b g a
d a f b g a
f b d b g a
80
Naturlicher Verbund
nur sinnvoll, wenn Spaltenbezeichnungen vorhanden sind. Seien A1 A2 : : : Al
die gemeinsamen Attributnamen, seien i1 : : : im die Positionen der Attributnamen, die in S, aber nicht in R vorkommen.
Sei R r-stellig, S s-stellig
R 1 S := 12:::rr+i r+i :::rim R:A =S:A R:A =S:A :::R:Al =S:Al (R S)
1
2
1
1
2
2
d.h. vom Kreuzprodukt solche Zeilen, die an gemeinsamen Spalten ubereinstimmen, doppelte nur einmal listen.
A
a
d
b
c
B
b
b
d
a
C
c
c
f
b
B
b
b
a
C
c
c
d
A
a
a
d
d
D
d
e
b
B
b
b
b
b
C
c
c
c
c
D
d
e
d
e
Beispiel: Was hort Meier?
TitelName= Meier ((Student 1 hort) 1 Vorlesung)
0
Ergebnis:
0
Algebra
Analysis
Quotient
Sei R r-stellig, S s-stellig
Q := R S := ft = t1 : : :tr;s j8u 2 S : tu 2 Rg
d.h. solche Anfangsstucke in R, zu denen samtliche Verlangerungen aus S in R
sind
R a b c
S: c d
RS b
a b d
x d
b c d
b x d
Bilde
T := 1:::r;s (R)
T S
alle Anfangsstucke
alle Anfangsstucke kombiniert mit
allen Verlangerungen aus S
(T S)nR
davon nur solche, die nicht in R sind
V := 1:::r;s ((T S)nR) davon die Anfangsstucke
T nV
davon das Komplement
81
Zum Relationenkalkul
Gegeben R(A B) S(B C)
statt c(A=a (R 1 S))
konstruktiv
jetzt: fcj9b : R(ab) ^ S(bc)g nicht konstruktiv
Beide Ansatze sind gleichmachtig.
Abfragesprache, basierend auf Relationenalgebra
ISBL (Information System Base Language) von IBM
Seien R S Relationen, sei F eine boole'sche Formel.
Relationenalgebra
ISBL
RS
R+S
RnS
R;S
R\S
R:S
F (R)
R:F
A :::Ak (R)
R%A1 : : : Ak
R1S
RS
1
R S wirkt wie das kartesische Produkt, wenn R und S keine gemeinsamen
Spaltenbezeichnungen haben.
Zusatzliche Features:
LIST R
R = E
R = N!E
Ausgabe der Tupel von R
Ausdruck E wird ausgewertet und der Relation R zugewiesen
eine Sicht R wird deniert gema dem Ausdruck E. Erst bei Referenz von R wird E ausgewertet.
Beispiel:
Gegeben die Relationen R(A B) S(C D)
U = ((R S) : B = C)%A D
unmittelbare Auswertung
V = ((N!R N!S) : B = C)%A D Denition der Sicht
LIST V
Auswertung
X =V +W
Auswertung
82
Abweichungen von Relationenalgebra
Attributnamen erforderlich
R + S und R:S verlangen identische Attributnamen
R ; S bezieht sich nur auf solche Attribute, die R und S haben
Umbenennung moglich:
Gegeben R(A B) und S(A C)
Bilde (R%A |B !
{z C}) + S
neuer Name fur B
Neckermann
Neckermann
Quelle
Hinz
Kunz
Hinz
Kunz
Beispiel:
Lieferant (Name, Ware, Preis)
Bestellung (Name, Ware, Anzahl)
Kunde (Name, Adresse)
Ball 10
Hemd 20
Hemd 25
Hemd 3
Hemd 5
Dortmund
Essen
a) Welche Ware liefert Firma Neckermann?
% Ware
b) Welche Lieferanten liefern mindestens einen Artikel, den Lehmann bestellt
hat?
B = (N! Lieferant % Name ! LName, Ware)* (N! Bestellung % Name,
LIST (Lieferant:Name = 'Neckermann')
Ware)
B hat das Format (LName,
Ware, Name)
LIST (B:Name = 'Lehmann')
LName
%
c) Welche Lieferanten liefern alle Artikel, die Lehmann bestellt hat?
L = N! Lieferant % Name
Lieferantennamen
W = N! Lieferant % Ware
lieferbare Waren
B = (N! Bestellung : Name = 'Lehmann') % Ware Lehmann's Bestellungen
NL = (N!L * N! W) - (N! Lieferant % Name, Ware)
nicht lieferbare Kombinationen, Format (Name, Ware)
|(N!L*N!B)
{z }
Lieferanten Lehmann's Bestellungen
{z
}
|
NLB = N!NL
LIST (L
Kombinationen von Lieferanten und Waren, die
sie nicht liefern, aber Lehmann bestellt hat
- NLB % Name)
83
6.2 Query by example
Beispiel fur Relationenkalkul
Ablauf
1.) Benutzer verlangt Tabellenskelett
2.) System liefert Tabellenskelett
xxxx
3.) Benutzer tragt Tabellennamen ein
4.) System tragt Attribute ein
xxxx xx xx xx
5.) Benutzer tragt Beispielantwort ein
kein Prax:
Konstante
Prax :
Variable, darf beliebig ersetzt werden
Pra-Prax P.: wahlt Spalte fur Antwort
xxxx xx xx xx
x
Beispiel: Liste die Relation Student
student
mat nr
P.
name
Beispiel: Wer wohnt in Rheine?
student
mat nr
name
P.
ort
ort
Rheine
Beispiel: Wer hort Datenbanken?
student
hoert
mat nr
name
plum
mat nr
plum
vorlesung
P.
geb dat
ort
geb dat
geb dat
vor nr
plisch
vor nr
titel
plisch Datenbanken
84
umfang
Beispiel: Welche Vorlesungen sind umfangreicher als Datenbanken?
vorlesung
vor nr
P.
titel
umfang
Datenbanken
stunden
> stunden
Beispiel: Welche Vorlesung hat den hochsten Umfang?
vorlesung
vor nr
:
"
titel
P.
umfang
x
> x
Was auf diese Zeile zutrit, darf nicht in R sein.
Welches ist der durchschnittliche Stundenumfang?
Vorlesung
vor nr
titel
umfang
analog:
P.AVG.ALL. 999
In wieviel Orten wohnen die Studenten?
student
mat nr
name
ort
P.CNT.UN.ALL. 999
Wer ist alter als Lehmann und junger als Schulz?
student
mat nr
conditions
name
P.
Lehmann
Schulz
I.
Modizieren U.
vorlesung
U.
geb dat
P. a1
a2
a3
a2 > a1
a1 > a3
Einfugen (I.) und Loschen (D.)
vorlesung
ort
vor nr
4711
vor nr
4711
titel
Algebra
titel
umfang
4
umfang
3
85
SUM
MAX
MIN
CNT
geb dat
6.3 INFORMIX
INFORMIX ist ein relationales Datenbanksystem der Firma \Relational Database Systems, Inc", Menlo Park, California, USA. Folgende Punkte charakterisieren INFORMIX:
Menue-gesteuerte Benutzeroberache, interaktiv,
Erzeugen von Tabellen durch Festlegung der Spaltentypen, Indizes und
Nullwertmoglichkeiten,
Denition von statistischen und dynamischen Tabellen,
Formulieren von Anfragen (Queries) mit der Sprache RDSQL (Erweiterung von SQL = IBM-Standard fur relationale Datenbanken),
Editierung der Query mit eigenem oder SQL-Editor,
Erzeugen von Bildschirmmasken zur Ein-/Ausgabe von Daten (mit Bereichsuberprufung) und zur Datensuche,
Erzeugen von Reports (= formatierte Ausgaben),
Gewahrung von Datensicherheit und Datenschutz durch
{ Zugrisrechte fur Queries,
{ Transaktionen (Folge von Operationen, von denen alle oder keine
ausgefuhrt werden),
{ Logbuch (protokolliert Veranderungen),
Beispieldatenbank.
Die von INFORMIX verwendeten Datentypen lauten:
Typ
Wertebereich
Platz
char(n)
string mit n Zeichen
n Bytes
smallint
;32767 : : :32767
2 Bytes
integer
;2147483647 : ::2147483647
4 Bytes
smalloat
Gleitpunkt mit 7 Stellen Genauigkeit
4 Bytes
oat
Gleitpunkt mit 14 Stellen Genauigkeit
8 Bytes
decimal(n m) Dezimalzahl mit n Stellen
1 + n=2 Bytes
davon m hinter dem Komma
serial (x)
Seriennummer, beginnend mit x
4 Bytes
date
Datum (gespeichert als Tage seit 31.12.1899 4 Bytes
money(n m) Geldbetrag (wie decimal, mit Dollarzeichen) 1 + n=2 Bytes
Nicht besetzte Attributwerte werden durch das Schlusselwort NULL gekennzeichnet.
86
Eine RDSQL-Query hat den folgenden Aufbau:
<Spalten-1>
<Tabellen>
<Bedingung-1>
<Spalten-2>
<Bedingung-2>
<Spalten-3>
<Tabelle>
SELECT
FROM
WHERE
GROUP BY
HAVING
ORDER BY
INTO TEMP
Nur die Klauseln SELECT und FROM sind erforderlich, der Rest ist optional. Es
bedeuten
<Spalten-1>
Bezeichnungen der Spalten, die ausgegeben werden
<Tabellen>
Bezeichnung der verwendeten Tabellen
<Bedingung-1> Auswahlbedingung f
ur die auszugebenden Zeilen verwendet
AND, OR, NOT, =, >, <, !=, <=, >=, IS NULL, BETWEEN,
MATCHES
<Spalten-2>
<Bedingung-2>
<Spalte-3>
<Tabelle>
Bezeichnungen der Spalten, die eine Gruppe denieren.
Eine Gruppe bzgl. Spalte x sind diejenigen Zeilen, die bzgl. x
identische Werte haben.
Bedingung zur Auswahl einer Gruppe
Ordnungsreihenfolge fur Spalten-1
Name einer neu angelegten temporaren Datei, die das Ergebnis
der Query enthalt
Vor <Spalten-1> kann das Schlusselwort UNIQUE stehen, welches identische Ausgabezeilen unterdruckt. Aggregate Functions konnen uberall dort stehen, wo
Konstanten erlaubt sind. Es liefert
COUNT (*)
Anzahl der Zeilen
COUNT (DISTINCT x) Anzahl der verschiedenen Werte in Spalte x
SUM (x)
Summe der Werte in Spalte x
SUM (DISTINCT x)
Summe der verschiedenen Werte in Spalte x
AVG (x)
Durchschnitt der Werte in Spalte x
AVG (DISTINCT x)
Durchschnitt der verschiedenen Werte in Spalte x
MAX (x)
Maximum der Werte in Spalte x
MIN (x)
Minimum der Werte in Spalte x
jeweils bezogen auf solche Zeilen, die die WHERE-Bedingung erfullen. Null-Eintrage
werden bei AVG, MIN, MAX und SUM ignoriert.
87
Beispiel-Queries fur das Schema mit den Relationen
STUDENT
VORLESUNG
HOERT
(NACHNAME, VORNAME, MAT NR, GEB DAT, FACH)
(VOR NR, TITEL, UMFANG)
(MAT NR, VOR NR)
1. Liste alle Zeilen mit samtlichen Spalten aus der Tabelle Student:
select * from student
2. Liste Nachname, Vorname, Fach aus der Tabelle Student
sortiere nach Nachname, Vorname:
select nachname, vorname, fach from student
order by nachname, vorname
3. Liste alle Facher:
select unique fach from student
4. Liste Vorlesungstitel mit Umfang zwischen 2 und 4 Stunden:
select * from vorlesung
where umfang between 2 and 4
5. Liste Studenten, die keine Geburtstagsangabe haben:
select nachname from student
where geb_dat is null
6. Liste Studenten, deren Name mit W anfangt:
select * from student
where nachname matches "W*"
7. Liste Vorlesungstitel mit Umfang in Minuten:
select titel, umfang*45 Minuten from vorlesung
8. Bestimme Anzahl der Studenten, die Mathematik studieren:
select count(*) from student
where fach = "Mathe"
88
9. Bestimme minimalen, maximalen, durchschnittlichen, summierten Stundenumfang der Vorlesungen:
select min(umfang), max(umfang), avg(umfang), sum(umfang) from vorlesung
10. Liste Studenten mit Geburtsdatum und Alter:
select nachname, geb_dat, (today - geb_dat)/ 365 Alter from student
order by alter
11. Liste die Sonntagskinder:
select * from student
where weekday(geb_dat)=0
12. Liste Studentennamen zusammen mit ihren Vorlesungsnummern:
select nachname, vor_nr from student, hoert
where student.mat_nr = hoert.mat_nr
order by nachname
13. Liste Studentennamen zusammen mit ihren Vorlesungstiteln:
select nachname, titel from student, hoert, vorlesung
where student.mat_nr = hoert.mat_nr
and hoert.vor_nr = vorlesung.vor_nr
order by nachname
14. Liste Studenten, die dasselbe Fach studieren wie Willi Wachtel:
select y.nachname, y.vorname, y.fach from student x, student y
where y.fach = x.fach
and x.nachname = "Wachtel"
and x.vorname
= "Willi"
and (y.nachname != x.nachname
or y.vorname != x.vorname)
15. Liste Name und Geburtsdatum des altesten Studenten:
select nachname, vorname, geb_dat from student
where geb_dat =
(select min(geb_dat) from student)
89
16. Liste Name und Geburtsdatum des zweitaltesten Studenten:
select nachname, vorname, geb_dat from student
where geb_dat =
(
select min(geb_dat) from student
where geb_dat >
(select min(geb_dat) from student)
{aeltestes Geburtsdatum}
)
17. Liste Facher zusammen mit Anzahl der Studenten:
select fach, count (*) Anzahl from student
group by fach
18. Liste fur jedes Fach das Geburtsdatum des Fachaltesten:
select fach, min(geb_dat) Geburtsdatum from student
group by fach
19. Liste Vorlesungen mit mehr als 10 Teilnehmern
zusammen mit der Teilnehmerzahl:
select titel, count(*) Hoerer from hoert, vorlesung
where hoert.vor_nr = vorlesung.vor_nr
group by titel
having count(*) > 10
20. Liste Facher mit Durchschnittsalter groer als 25:
select fach, avg(today-geb_dat)/365 Durchschnittsalter from student
group by fach
having avg(today-geb_dat)/365 > 25
90
21. Liste alle Studenten des Faches mit dem kleinsten Durchschnittsalter:
select nachname, fach, geb_dat from student
where fach =
(
select fach from student
{ Fach mit kleinstem Durchschnittsalter }
group by fach
having avg(today-geb_dat) <= all
(select avg(today - geb_dat)
from student
group by fach
)
{ alle Durchschnittsalter}
)
22. Liste alle Fachaltesten,
fulle zunachst Facher und Geburtsdaten der Fachaltesten in temporare
Relation facher:
select fach, min(geb_dat) geb_dat from student
group by fach
into temp faecher
Verbinde dann die Relation student mit der temporaren Relation facher:
select nachname, vorname, student.fach, student.geb_dat from student, faecher
where student.fach = faecher.fach
and student.geb_dat = faecher.geb_dat
Entferne temporare Relation:
drop table faecher
23. Liste alle Studenten, die nicht die Vorlesung Internet-Dienste horen:
select nachname from student
where mat_nr not in
(select hoert.mat_nr from hoert, vorlesung
where vorlesung.titel = "Internet-Dienste"
and hoert.vor_nr = vorlesung.vor_nr
)
24. Entferne die Vorlesung Textverarbeitung aus der Tabelle Vorlesung:
delete from vorlesung where titel= "Textverarbeitung"
91
25. Losche den gesamten Inhalt von Tabelle Student und von Tabelle hort:
delete from student
delete from hoert
26. Fuge die Veranstaltung Textverarbeitung in die Tabelle Vorlesung ein:
insert into vorlesung values ("6754", "Textverarbeitung",2)
27. Fuge in die Relation student alle Tupel aus der Datei \student.doc" ein:
load from "student.doc"
insert into student
28. Alle Studenten sollen Datenbanksysteme horen:
insert into hoert
select mat_nr, vor_nr from student, vorlesung
where titel = "Datenbanksysteme"
29. Alle Systemwissenschaftler horen Internet-Dienste:
insert
select
where
and
into hoert
mat_nr, vor_nr from student, vorlesung
fach = "System"
titel = "Internet-Dienste"
30. Erika Mustermann soll alle Veranstaltungen horen.
Hierzu werden zunachst ihre schon vorhandenen Vorlesungsnummern
in der temporaren Relation mustermann vor nr gespeichert:
select vor_nr from student, hoert
where nachname
= "Mustermann"
and
vorname
= "Erika"
and
student.mat_nr = hoert.mat_nr
into temp mustermann_vor_nr
Dann werden alle Vorlesungsnummern, die nicht schon in der temporaren
Relation stehen, zusammen mit Mustermanns Matrikelnummer in die Tabelle hort eingefugt:
insert into hoert
select mat_nr, vor_nr from student, vorlesung
where nachname = "Mustermann"
and
vorname = "Erika"
and
vor_nr not in
(select vor_nr from mustermann_vor_nr)
92
Zum Schlu wird die temporare Tabelle entfernt:
drop table mustermann_vor_nr
31. A ndere das Geburtsdatum von Willi Wachtel:
update student
set
geb_dat = date("06/27/65")
where nachname = "Wachtel"
and
vorname = "Willi"
32. Schreibe alle Tupel der Relation student in die Datei \student.doc":
unload to "student.doc"
select * from student
33. Deniere eine Sicht, bestehend aus Vorlesungstiteln und Horerzahlen:
create view hoerer (titel, hoererzahl) as
select titel, count(*)
from hoert, vorlesung
where hoert.vor_nr = vorlesung.vor_nr
group by titel
Die Sicht kann wie eine Tabelle verwendet werden:
select * from hoerer where ...
34. Deniere eine Sicht systies als Teilmenge der Studenten,
die Systemwissenschaften studieren:
create view systies as
select * from student
where fach="System"
35. Deniere eine Sicht dbsysties als Teilmenge der Studenten,
die Systemwissenschaften studieren und Datenbanksysteme horen:
create view dbsysties as
select nachname, vorname, geb_dat, student.mat_nr, fach
from student, hoert, vorlesung
where fach = "System"
and student.mat_nr = hoert.mat_nr
and hoert.vor_nr
= vorlesung.vor_nr
and vorlesung.titel= "Datenbanksysteme"
93
36. Liste Informationen auf ...
info tables info columns for student
{
{
{
{
{
{
info indexes for student
info access for student
info status for student
alle Tabellen der Datenbank
}
alle Spalten zur Tabelle student
}
mit Bezeichnung, Typ, Null/nichtnull }
Indexinformationen zur Tabelle student}
Zugriffsrechte zur Tabelle student
}
Besitzer, Anzahl der Eintraege, ...
}
37. Bestimme die drei haugsten Vornamen der Tabelle student.
Schicke hierzu den Output einer Query als Input in ein Shellkommando.
Idee: Sortiere, zahle Doppel, sortiere absteigend, ltere die ersten drei.
output to pipe "sort | uniq -c | sort -r | head -3"
without headings
{ ohne Tabellenkopf
select vorname from student
{ Liste Vornamen
94
}
}
{ statistik.ace:
{
{
{
{
database
uni
end
script zum Erstellen eines Reports
mit Angaben zu Fach, Nachname, Vorname, Geburtsdatum
und Vermerk, ob der Geburtstag auf einem Sonntag liegt
Pro Fachgruppe wird das Fach nur einmal gelistet
Uebersetzen erzeugt statistik.arc
{ verwende Datenbank uni
}
}
}
}
}
}
output
report to "statistik.doc"
page length 70
{ schreibe nach "statistik.doc" }
{ 70 Zeilen pro Seite
}
nachname,
vorname,
mat_nr,
geb_dat,
fach
from student
order by fach
{
{
{
{
{
{
{
{
end
select
erzeuge Tabelle mit SQL-Query
Nachname
Vorname
Matrikelnummer
Geburtsdatum
Studienfach
aus der Relation student
sortiert nach Faechern
end
format
{ es folgen Formatangaben
first page header
{ Kopfzeile
print "Studentenstatistik vom ",
today using "dd. mmm yy" { Tagesdatum
skip 2 lines
{ zwei Leerzeilen
before group of fach
{ vor jedem Fachwechsel
print fach
{ drucke Fach ohne Vorschub
on every row
{ fuer jede selektierte Zeile
print column 18, nachname,
{ drucke Nachname in Spalte 18
column 30, vorname
{ drucke Vorname in Spalte 30
if weekday(geb_dat)=0
{ falls Geburtstag ein Sonntag
then print " *"
{ drucke Stern
else print " "
{ sonst drucke Leerzeichen
after group of fach
{ nach jedem Fachwechsel
print "---------------------------------------------"
on last row
{ am Reportende
print column 27, "Sonntagskinder: ",
{ drucke in Spalte 27
count where weekday(geb_dat)=0 { die Zahl der Sonntagskinder
using "##"
{ als zweistellige Integer
end
{ Ende der Reportbeschreibung
95
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
{ student.per: Maske zum Eingeben von Daten in die Relation student
{
Uebersetzen erzeugt student.frm
{
Mit der Maske koennen Datensaetze gesucht, manipuliert
{
und geloescht werden
database uni
screen size 24 by 80
{
Nachname
f000
]
Vorname
f001
]
Matrikelnummer f002 ]
Geburtsdatum
f003
]
Studienfach
f004
]
Mathe
= Mathematik
Physik = Physik
System = angewandte Systemwissenschaften
Gast
= Gasthoerer
CL&KI
= Computerlinguistik & Kuenstliche Intelligenz
}
}
}
}
}
end
tables
student
attributes
f000 = student.nachname
f001 = student.vorname
f002 = student.mat_nr,
{
include=("200000" to "999999") {
f003 = student.geb_dat,
{
comments = "Format: MM/TT/JJ" {
f004 = student.fach,
{
include = ("Mathe","Physik",
"System","Gast","CL&KI")
end
96
zugelassen sind Strings
zwischen 200000 und 999999
Kommentar erscheint am
unteren Bildschirmrand
zulaessige Werte fuer fach
}
}
}
}
}
{ verbund.per:
{
Maske zur Manipulation der Daten aus den Relationen
student, hoert, vorlesung
}
}
database uni
screen size 24 by 80
{
Nachname
Vorname
Matrikelnummer
Geburtsdatum
Studienfach
f000
f001
f002
f003
f004
]
Vorlesungsnummer
Vorlesungstitel
Vorlesungsumfang
}
end
f007]
f008
f009 ]
]
]
]
]
]
tables
student
hoert
vorlesung
{
{
{
{
attributes
f000 = student.nachname
f001 = student.vorname
f002 = *student.mat_nr = hoert.mat_nr
beteiligt sind die Tabellen
Student
hoert
Vorlesung
{ angezeigte Attribute:
{ Nachname
{ Vorname
{ Matrikelnummer, als join
{ zwischen student und hoert
f003 = student.geb_dat
{ Geburtsdatum
f004 = student.fach
{ Studienfach
f007 = *vorlesung.vor_nr=hoert.vor_nr { Vorlesungsnummer, als join
f008 = vorlesung.titel
{ Vorlesungstitel
f009 = vorlesung.umfang
{ Vorlesungsumfang
instructions
{ Anweisungen zum Blaettern der Seiten
student master of hoert
{ zu einem Student koennen mehrere
hoert master of vorlesung
{ Vorlesungen durchlaufen werden
end
97
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
7 Funktionale Abhangigkeiten
7.1 Armstrong-Axiome
Gegeben sei eine Relation R.
Nicht alle Auspragungen sind moglich wegen
1. Beschrankung durch Semantik der Wertebereiche, z.B. Gewicht, Groe,
Geburtsdatum (dieses ist ohne Einu auf den Entwurf der Relationenschemata)
2. Beschrankung durch Abhangigkeiten zwischen den Attributen (dies hat
Einu auf den Entwurf der Relationenschemata)
Def.: Sei R(A1 A2 : : : Ak ) ein Relationenschema.
Seien X Y fA1 A2 : : : Ak g. Wir sagen \Y ist funktional abhangig von
X" oder \X bestimmt Y " (Schreibweise X ! Y ) , fur jede Auspragung
r 2 R, 8s t 2 r : X (s) = X (t) ) Y (s) = Y (t).
Funktionale Abhangigkeit bedeutet also: sind zwei Tupel bzgl. X gleich, so sind
sie auch bzgl. Y gleich. Wichtig: diese Eigenschaft mu immer gelten, nicht nur
fur die momentane Auspragung r. Funktionale Abhangigkeit entsteht durch die
Bedeutung der Attribute.
Beispiel: Gegeben sei eine Relation mit der momentanen Auspragung
Meier
Rheine
Lehmann Dortmund
Schulz
Bremen
trotzdem gilt nicht Ort ! Name
Zur Schreibweise: Statt fA B C g schreiben wir ABC.
Beispiel:
Gegeben das Relationenschema R (city, street, zip), welches die (amerikanischen) Postleitzahlen enthalt. Es gelten die funktionalen Abhangigkeiten
city street
zip
city
!
!
zip
da mehrere Straen eines Bezirks zu einem ZIP-Code zusammengefat sind.
Def.: Sei F eine Menge von funktionalen Abhangigkeiten fur das Relationenschema R. F impliziert X ! Y (Schreibweise F j= X ! Y ), falls jede
Relation r 2 R, die F erfullt, auch X ! Y erfullt.
98
Def.: F + := fX ! Y jF j= X ! Y g
Beispiel: Sei R(A B C) F = fA ! B B ! C g
) F + := fABC ! AB AB ! BC BC ! B : : :g
Gesucht: Inferenzregeln, um von F zu F + zu gelangen.
Armstrong-Axiome
Gegeben Relationenschema R mit Attributmenge U, Abhangigkeiten F.
A1) Reexivitat: Aus Y X U folgt X ! Y .
A2) Erweiterung: Aus X ! Y folgt XZ ! Y Z fur Z U.
A3) Transitivitat: Aus X ! Y Y ! Z folgt X ! Z.
Beispiel:
Zeige: \ Alles ist von zip street funktional abhangig"
1. zip ! city (gegeben)
2. zip street ! city street (Erweiterung von 1. mit street)
3. city street ! zip (gegeben)
4. city street ! city street zip (Erweiterung von 3. mit city
5. zip street ! city street zip (Transitivitat von 2. + 4.)
Behauptung:
Armstrong Axiome sind
\sound"
und \complete"
(nichts ist falsch)
(nichts fehlt)
Beweis fur \sound":
Reexivitat ist \sound" (Y X ) X ! Y ):
2 Tupel, die bzgl. X ubereinstimmen, stimmen auch bzgl. jeder Teilmenge von
X uberein.
Erweiterung ist \sound" (X ! Y ) XZ ! Y Z):
Annahme: 2 Tupel stimmen bzgl. XZ uberein, aber nicht bzgl. Y Z. Dann
mussen sie bzgl. Y dierieren. Widerspruch, da X ! Y .
Transitivitat ist \sound" (X ! Y Y ! Z ) X ! Z):
Annahme: 2 Tupel stimmen bzgl. X uberein, aber nicht bzgl. Z. Wenn sie bzgl.
99
)
street
Y nicht ubereinstimmen, ist X ! Y verletzt, wenn sie bzgl. Y uberereinstimmen, ist Y ! Z verletzt. Daher: Widerspruch.
Es gibt weitere Axiome, die aus A1 ; A3 abgeleitet werden konnen
A4: Aus X ! Y X ! Z
folgt X ! Y Z (Vereinigung)
A5: Aus X ! Y WY ! Z folgt XW ! Z (Pseudotransitivitat)
A6: Aus X ! Y Z Y
folgt X ! Z
(Zerlegung)
Def.: Gegeben Relationenschema R, Attributmenge U, Abhangigkeiten F . Sei
X U.
Der Abschlu einer Attributmenge X wird deniert als
X + := fY 2 U jX ! Y folgt aus Armstrongaxiomen angewandt auf F g
Lemma: Gegeben eine Menge F von funktionalen Abhangigkeiten.
X ! Y folgt aus Armstrongaxiomen , Y X +
Beweis:
(() Sei Y = A1A2 : : :An X + . Nach Denition von X + gilt: X ! Ai folgt
aus Armstrongaxiomen fur i = 1 : : : n. Nach Axiom A4 (Vereinigung) folgt
X ! A1 : : :An, d.h. X ! Y .
()) Es folge X ! Y aus den Armstrongaxiomen. Nach der Zerlegungsregel gilt
X ! Ai fur i = 1 : : : n. Daraus folgt Y X + .
D.h., um festzustellen, ob X ! Y aus den Armstrongaxiomen folgt, testet
man, ob Y in X + liegt.
Beweis fur \complete":
Sei F eine Menge von funktionalen Abhangigkeiten uber Attributmenge U und
sei X ! Y nicht ableitbar aus den Axiomen. Zeige: F impliziert nicht X ! Y .
D.h. nde Relation r, die F erfullt, aber X ! Y nicht.
Betrachte Relation r mit 2 Tupeln
Attribute
z }| von{ X
1 1 1 ::: 1
1 1 1 :::1
+
andere
z }|Attribute
{
1 1 1 : : :1
0 0 0 : : :0
Zu zeigen
a) alle Abhangigkeiten von F sind erfullt durch r:
Annahme: V ! W 2 F sei nicht erfullt
) V X + , denn sonst wurden die beiden Tupel von r bzgl. V dierieren
und konnten V ! W nicht verletzen. Auerdem W 6 X + , denn sonst
ware V ! W durch r erfullt. Sei daher A ein Attribut aus W, das nicht
in X + liegt.
100
Da V X + ) X ! V ist ableitbar mit Armstrong ) X ! V 2 F +
(Lemma)
(sound)
auerdem:
auerdem:
also:
dann ware
V !W 2F
W ! A (Reexivitat)
X ! A (Transitivitat)
A 2 X + . Widerspruch!
Also: Jede funktionale Abhangigkeit V ! W ist erfullt.
b) Zu zeigen: X ! Y wird von r nicht erfullt
Annahme: X ! Y sei erfullt von r
Es gilt X X + , daraus folgt Y X + , denn sonst ist die Abhangigkeit
durch die beiden Tupel verletzt (auf X identisch, auf Y nicht).
Aus Y X + folgt (wg Lemma): X ! Y ist mit Armstrong ableitbar.
Widerspruch zu \sei X ! Y nicht aus den Axiomen ableitbar".
Also: Annahme falsch, d.h. X ! Y wird von r nicht erfullt.
Aus a + b folgt: Wenn X ! Y nicht mit den Armstrong-Axiomen aus
F ableitbar ist, dann impliziert F die Abhangigkeit X ! Y auch nicht.
Also: Armstrong Axiome sind sound.
Korollar: X + = fY jF impliziert X ! Y g
Korollar: F + = fX ! Y jX ! Y ist aus F mit den Armstrong-Axiomen ableitbarg.
Gegeben sei F , und gegeben sei die Frage \Gilt X ! Y ?"
Es ist unklug, F + aus F zu berechnen und dann auf X ! Y zu testen. Denn
sei F = fA ! B1 A ! B2 : : : A ! Bn g ) F + enthalt 2n Elemente.
Besser (und korrekt wegen Lemma): Berechne X + und teste, ob Y 2 X + .
Algorithmus zur Bestimmung von X + :
Input: Menge F von funktionalen Abhangigkeiten uber Attributmenge U,
Teilmenge X U.
Output: X +
Bestimme X 0 X 1 X 2 : : : wie folgt:
X 0 := X
X i+1 := X i Z, falls Y ! Z 2 F Y X i (d.h. suche Regel in F, deren linke
Seite in X i enthalten ist, nimm rechte Seite hinzu).
Abbruch, wenn X i+1 = X i
101
Beispiel:
Sei U
Sei F
Sei X
X0
X1
X2
X3
Also: (BD)+
= fA B C D E Gg
= fAB ! C C ! A BC ! D ACD ! B
D ! EG BE ! C CG ! BD CE ! AGg
= fB Dg
= BD
= BDEG
= BCDEG
= ABCDEG = X 4 , Abbruch.
= ABCDEG
Ein ezienter Algorithmus zur Bestimmung von X + speichert die bereits erreichten Attribute in einem boole'schen array und die Nummern der inzwischen
anwendbaren Regeln in einer Schlange. Genauer:
Numeriere alle Regeln.
Initialisiere fur jedes Attribut eine Liste der Regeln, in denen es auf der linken
Seite vorkommt.
Initialisiere fur jede Regel einen Zahler mit der Anzahl der noch fehlenden Attribute (unter Berucksichtigung der Startmenge X). Regelnummern mit Zahlerstand 0 werden in Schlange ubernommen.
Solange Schlange nicht leer ist:
Entferne Regel aus Schlange
Fur jedes Attribut A der rechten Seite:
erweitere X um A
fur jede Regel aus der Liste von A erniedrige den Zahler
falls Zahler auf 0 springt, ubernimm Regelnr. in Schlange
Die Laufzeit betragt O(jF j).
102
Attribut
Regeln
Zähler
1: AB ! C
1
2: C ! A
1
B
3: BC ! D
1
C
4: ACD ! B
2
D
5: D ! EG
0
E
6: BE ! C
1
7: CG ! BD
2
A
G
8: CE ! AG
2
bisher erreichbare Attribute
BD
Schlange: 5
Beh.: Algorithmus berechnet X +
1. wenn A in X j plaziert wird, so gehort A zu X +
Induktion uber j.
j = 0 ) X0 X+
Sei bis j bewiesen, d.h. X j X + . Kommt nun Z in X j +1 wegen Regel
Y ! Z und Y X j , so ist das korrekt wegen Transitivitat.
2. Sei A 2 X + , so gilt: es gibt j : A 2 X j
Zeige: Lat sich X ! Y aus F ableiten, so gilt Y X j . Fuhre dazu
Induktionsbeweis uber die Lange der Ableitung (Armstrong Schritte)
103
Def.: Zwei funktionale Abhangigkeitsmengen F G sind aquivalent,
falls F + = G+ .
Zum Testen, ob F + = G+ : Fur jede Abhangigkeit X ! Y 2 F teste, ob
X ! Y 2 G+ , d.h. teste, ob Y X + bzgl. G.
Def.: Eine Menge von funktionalen Abhangigkeiten heit minimal ,
1. Jede rechte Seite hat nur ein Attribut.
2. Weglassen einer Abhangigkeit aus F verandert F + .
3. Weglassen eines Attributs in der linken Seite verandert F + .
Konstruktion der minimalen Abhangigkeitsmenge geschieht durch Aufsplitten
der rechten Seite und durch probeweises Entfernen von Regeln bzw. von Attributen auf der linken Seite.
Beispiel:
Sei U = f A B C D E Gg
Sei F = f AB ! C,
D ! EG
C
! A, BE ! C,
BC ! D, CG ! BD,
ACD ! B, CE ! AG g
Aufspalten der rechten Seiten liefert
AB ! C
C ! A
BC ! D
ACD ! B
D ! E
D ! G
BE ! C
CG ! B
CG ! D
CE ! A
CE ! G
Regel CE ! A
CG ! B
ist redundant wegen
ist redundant wegen
C
CG
C
ACD
Regel ACD ! B kann gekurzt werden zu CD
104
!
!
!
!
!
A
D
A
B
B, wegen C ! A
7.2 Normalformen
Problemstellung: Entwurf der Relationenschemata
Frage: Was ist ein guter Entwurf?
Zunachst: Beispiel fur schlechten Entwurf:
Gegeben sei das Relationenschema
Grosshandel (Name, Adresse, Best Nr, Ware, Preis)
mit folgenden Bedeutungen:
Name:
Name des Lieferanten
Adresse: Adresse des Lieferanten
Best nr: Bestellnummer der Ware
Ware:
Bezeichnung der Ware
Preis:
Preis der Ware
Folgende Eekte sind zu beobachten:
Redundanz:
Adresse ist mehrfach gespeichert.
Update Anomalie: Adresse wird nicht uberall geandert.
Insertion Anomalie: Lieferant kann nur eingefugt werden, wenn er
mindestens einen Artikel liefert. Oder: einige
Attribute auf 0 setzen, gibt Probleme, wenn
sie Teil des Schlussels sind.
Deletion Anomalie: Beim Loschen der letzten Ware eines Lieferanten verschwindet der Lieferant.
Besser:
Lieferant (Name, Adresse)
Lieferbar (Name, Best Nr, Ware, Preis)
Gro$handel = Lieferant * Lieferbar
Es gilt:
.
Fazit: Probleme entstehen durch funktionale Abhangigkeiten.
Def.: Sei R(A1 : : : An ) ein Relationenschema, seien X Y (A1 : : : An). Eine
Attributmenge Y heit voll funktional abhangig von X ,
X ! Y und 8X 0 X : X 0 6! Y
Eine Attributmenge X heit Schlusselkandidat , A1 : : : An ist voll funk-
tional abhangig von X.
Ein Attribut A heit Primarattribut , A kommt in mindestens einem
Schlusselkandidaten vor. A heit Nichtprimarattribut , A kommt in keinem Schlusselkandidaten vor.
Def.: Eine Relation R ist in 1. Normalform (1. NF.) , jedes Tupel enthalt nur
atomare Komponenten, d.h. kein Attribut besteht aus zusammengesetzten
Werten.
105
Def.: Eine Relation R ist in 2. Normalform nach Codd ,
1.) R ist in 1. NF
2.) Jedes Nichtprimarattribut ist voll funktional abhangig von jedem Schlusselkandidaten.
Etwas scharfer:
Def.: Eine Relation R ist in 2. Normalform nach Kent ,
1.) R ist in 1. NF
2.) Jedes Attribut im Komplement eines Schlusselkandidaten ist von diesem Schlusselkandidaten voll funktional abhangig.
Idee: |A1 :{z: :Ak}
A
| k+1{z: : :An}
Primarattribute
Nichtprimarattribute voll funktional abhangig,
d.h. nicht von Teilen des Schlussels abhangig
Satz: R in 2. NF nach Kent ) R in 2. NF nach Codd
Beweis: Sei R in 2. NF nach Kent. Jedes Nichtprimarattribut liegt im Komplement jedes Schlusselkandidaten (da es in keinem Schlussel vorkommt), also (2.
NF Kent) ist es von diesem Schlusselkandidaten voll funktional abhangig, also
2. NF Codd.
Satz: R in 2. NF nach Codd 6) R in 2. NF nach Kent
Gegenbeispiel: R
(Vorlesung, Dozent, Termin, Raum)
Algorithmen
Datenbanksysteme
Datenbanksysteme
Graphenalgorithmen
Seehusen
Vornberger
Vornberger
Vornberger
Mo,
Mo,
Di,
Do,
14:15
14:15
16:15
14:15
32/102
31/449
31/449
31/449
Die Schlusselkandidaten lauten:
Vorlesung
Dozent
Raum
Termin
Termin
Termin
Also gibt es keine Nichtprimarattribute, also liegt 2. NF nach Codd vor. Aber:
liegt im Komplement des Schlusselkandidaten Vorlesung Termin und
ist nicht voll funktional abhangig davon (es gilt Vorlesung ! Dozent).
Die Relation Grosshandel ist nicht in 2. NF nach Codd (und daher auch nicht
nach Kent), da Adresse nicht voll funktional abhangig ist vom einzigen Schlusselkandidaten Name Best Nr.
Aber: Lieferant und Lieferbar sind beide in 2. NF nach Kent (und somit
auch nach Codd): Ware Preis sind voll funktional abhangig von Name Best Nr.
und Adresse ist voll funktional abhangig von Name.
Dozent
106
Bemerkung: Relationen mit atomarem Schlussel sind immer in 2. NF nach Kent
und nach Codd.
Beispiel: Student (Mat Nr, Fachbereich, Dekan) ist in 2. NF nach Kent
und nach Codd. Aber: es bestehen Abhangigkeiten zwischen den Nichtprimarattributen, z.B. Dekan hangt vom Fachbereich ab. D.h. bei Dekanswechsel
mussen mehrere Tupel geandert werden.
Def.: Seien X Y Z Mengen von Attributen eines Relationenschemas R mit Attributmenge U. Z heit \transitiv abhangig" von X, falls gilt
X \Z = 9 Y U : X \ Y = Y \ Z = X ! Y ! Z Y 6! X
Beispiel: Dekan ist transitiv abhangig von Mat Nr:
!
Mat Nr 6 Fachbereich ! Dekan.
Def.: Eine Relation R ist in 3. NF nach Codd ,
1.) R ist in 2. NF nach Codd.
2.) Jedes Nichtprimarattribut ist nicht-transitiv abhangig von jedem Schlusselkandidaten.
Def.: Eine Relation R ist in 3. NF nach Kent ,
1.) R ist in 2. NF nach Kent.
2.) Jedes Attribut im Komplement eines Schlusselkandidaten ist nichttransitiv abhangig von diesem Schlusselkandidaten.
Satz: R in 3. NF nach Kent ) R in 3. NF nach Codd.
Beweis: Sei R in 2. NF nach Kent. Jedes Nichtprimarattribut liegt im Komplement jedes Schlusselkandidaten und ist (wegen 3. NF Kent) nicht-transitiv
abhangig von ihm. Also sind alle Nichtprimarattribute nicht-transitiv abhangig
von allen Schlusselkandidaten.
Satz: R in 3. NF nach Codd 6) R in 3. NF nach Kent
Gegenbeispiel: R (Vorlesung, Dozent, Termin, Raum)
Es gibt keine Nichtprim
arattribute ) 3. NF nach Codd.
!
Aber: Termin Raum 6 Vorlesung ! Dozent, d.h. das Attribut
Komplement des Schlussels Raum
Termin
Dozent
ist transitiv von ihm abhangig.
im
Beobachtung: Um Relationen in 3. Normalform zu erhalten, ist haug eine starke
Aufsplittung erforderlich. Dies fuhrt naturlich zu erhohtem Aufwand bei Queries, da ggf. mehrere Verbundoperationen erforderlich werden.
107
8 Das objektorientierte Konzept
8.1 Schwachen von relationalen Systemen
Die Relation Buch (ISBN, Verlag, Titel, Autor, Version, Stichwort)
erfordert bei 2 Autoren, 5 Versionen, 6 Stichworten fur jedes Buch 2 5 6 = 60
Eintrage. Aufsplittung ergibt
Buch
Autor
Version
Stichwort
(ISBN,
(ISBN,
(ISBN,
(ISBN,
Titel, Verlag)
Name, Vorname)
Auflage, Jahr)
Stichwort)
Astra GL:
Astra GS:
Golf L:
Golf GT:
fRadio, ZVg
fRadio, Alu-Felgen, Airbagg
fSSD, ZVg
fAllradg
Nachteil: Informationen zu einem Buch sind auf vier Tabellen verteilt. Beim
Einfugen eines neuen Buches mussen mehrmals dieselbe ISBN eingegeben werden. Die referentielle Integritat mu selbst uberwacht werden.
Query Liste Bucher mit den Autoren Meier und Schmidt ist umstandlich zu
formulieren. Query Liste Bucher mit ihren Stichworten fuhrt zu Verbund, bei
dem Bucher ohne Stichworte herausfallen.
Sets of sets: Ein Autotyp habe mehrere Ausstattungspakete, jedes Paket hat
mehrere Komponenten.
Typ
Astra GL
Astra GS
Golf L
Golf GT
Die Relation
Paket
1
2
3
4
Paket
1
1
2
2
2
3
3
4
Inhalt
Radio
ZV
Radio
Alu-Felgen
Air-Bag
SSD
ZV
Allrad
verlangt die Tabellen
Person (Name, Ort, Stra$e, Hobbies)
Person (Name, Ort, Stra$e)
Hobbies (Name, Ort, Stra$e , Hobby)
und
|
{z
}
dient als Schlussel
Wiesenweg> seinen Wohnsitz, so gehen seine Hob-
A ndert <Meier, Hamburg,
bies verloren.
Fur die Relation Person (Name, Vorname, Ort, Stra$e, Vater) fuhrt die
Query Liste Vorname des Vaters von Erika Mustermann in SQL zu einem SelfJoin oder einer Subquery.
108
8.2 Objektorientierte Programmierung
Historie:
1940
1950
1960
1970
1980
Beispiel:
Maschinenprogrammierung
Assembler
Hohere Programmiersprachen
Strukturierte Programmierung
Objektorientierte Programmierung
class Geo
type tuple (x: real,
y: real,
z: real)
method zeichne
end
class Kugel inherit geo
type tuple (radius: real)
method zeichne
end
method body zeichne in class Kugel
{
/* zeichnet Kugel unter Verwendung von x, y, z, radius */
}
var g : Geo
k : Kugel
k = new Kugel
g = k
g->zeichne
Objekte einer Klasse werden charakterisiert durch ihre Datenstruktur und durch
die auf ihnen zugelassenen Methoden. Der Aufbau einer Klasse kann vererbt
werden (Spezialisierung/Verallgemeinerung). U berladen von Methoden verlangt
dynamisches Binden.
109
8.3 Objekt-Identitat
Jedes Objekt erhalt bei Eintritt ins System einen eindeutigen Objekt-Identier
(OID). Der OID bleibt dem Anwender verborgen, er ist unveranderlich und
unabhangig vom momentanen Objekt-Inhalt. Er dient auch zum Verwalten von
Objekt-Beziehungen. Die momentane physikalische Adresse eines Objekts ergibt
sich aus dem Inhalt einer Tabelle, die mit dem OID referiert wird. Manche OODatenbanksysteme verlangen, da selbst konstante Werte als Objekt dargestellt
werden einfacher ist es, zwischen Objekten (mit OIDs) und Werten (ohne OIDs)
zu trennen.
8.4 Objekt-Struktur
Beginnend mit den atomaren Typen (z.B. boolean, character, integer,
real, string) werden unter Verwendung von Konstruktoren (z.B. atom, tuple,
list, set) hierarchisch strukturierte Objekte geformt. Ein Objekt besteht somit aus einem Tripel < i c v >, wobei i der eindeutige Objekt-Identier ist,
c der verwendete Konstruktor und v der Wert des Objekts. Ist c = atom so
enthalt v einen atomaren Wert. Ist c = tuple, so besteht der Wert v aus einer
Folge von Paaren < ai oi > wobei ai ein Attributname und oi der zugehorige
Objekt-Identier ist. Ist c = list oder c = set, so besteht der Wert v aus
einer Folge von OIDs. Neben strukturierten Objekten gibt es auch strukturierte
Werte, die durch dieselben Konstruktoren entstehen (aber keine OIDs besitzen).
titel: "Selber atmen",
tuple
autor:
version:
list
list
tuple
vorname: "Peter, nachname: "Pan", adresse
tuple
tuple vorname: "Willi", nachname: "Wacker", adresse
tuple
auflage: 1, jahr: 1991
tuple
auflage: 2, jahr: 1995
strasse: "Heuweg 2", plz: "12100", ort: "Berlin"
tuple
strasse: "Ostallee 10", plz: "26131", ort: "Oldenburg"
Ausschnitt aus der Verzeigerungsstruktur fur ein Objekt der Klasse Buch
110
Notation in O2:
class Buch public
type tuple ( isbn
verlag
titel
autor
version
:
:
:
:
:
string,
Verlag,
string,
list (Person),
list (tuple ( auflage : integer,
jahr
: integer
)
),
stichwort: set (string)
)
end
class Verlag public
type tuple ( name
: string,
adresse : Adresse
)
end
class Adresse public
type tuple (strasse: string,
plz
: string,
ort
: string
)
end
class Person public
type tuple ( vorname
nachname
adresse
geb_dat
geschlecht
photo
partner
kinder
)
end
:
:
:
:
:
:
:
:
string,
string,
Adresse,
Date,
char,
Bitmap,
Person,
list(Person)
111
Die Sichtbarkeit der Attribute variiert von \nicht sichtbar" uber \nur lesbar"
zu \veranderbar":
private gehalt:
real,
/* nicht sichtbar */
read
nachname: string, /* lesbar */
public project: string, /* veraenderbar */
Fur die Modellierung von isa-Beziehungen bietet sich die Vererbung an:
class Student inherit Person public
type tuple (/* zusaetzliche Attribute */)
Fur die Modellierung von many-one-Beziehungen bietet sich ein mengenwertiges
Attribut an:
class Buch
type tuple (
.
.
.
vorgemerkt von: set (Person),
.
.
.
)
end
class Student
type tuple (
.
.
.
vorgemerkt: set (Buch),
.
.
.
)
112
8.5 Persistenz
Es wird zwischen transienten und persistenten Objekten unterschieden. Transiente Objekte existieren nur wahrend der Laufzeit des Anwendungsprogramms
und verschwinden nach der Terminierung (wie eine Variable). Persistente Objekte uberdauern einzelne Programmlaufe und werden in der Datenbank gespeichert. Objekte werden persistent durch die Vergabe eines Namens oder indem
sie von einem persistenten Objekt erreichbar sind.
name alle buecher : set (Buch)
o2 Buch b
.
.
.
alle buecher = alle buecher + set(b)
Jetzt ist auch das Buch b persistent.
8.6 Objekt-Methoden
Prozeduren zur Manipulation von Objekten heien Methoden. Innerhalb der
Klassendenition taucht nur der Prozedurkopf, genannt Signatur, auf. Separat
davon wird die Implementation beschrieben.
class Person public
type tuple ( ... )
method kind_hinzu (vorname : string, geschlecht : char)
end
method body kind_hinzu (vorname: string, geschlecht: char) in class Person
{
o2 Person nb = new Person
/* lege Platz fuer neue Person an */
nb->vorname
= vorname
/* Vorname gegeben durch Parameter */
nb->nachname = self->nachname
/* Nachname wird uebernommen
*/
nb->adresse
= self->adresse
/* Adresse wird uebernommen
*/
nb->geb_dat
= new Date (0,0,0) /* Geburtstag = heutiges Datum
*/
nb->geschlecht= geschlecht
/* Geschlecht
*/
self->kinder += list(nb)
/* erweitere Menge der Kinder
*/
personen
+= set(nb)
/* erweitere Menge der Personen
*/
self->refresh_all
/* zeichne Praesentation neu
*/
if (self->partner != nil) {
/* falls Partner vorhanden
*/
self->partner->kinder+=list(nb)/* dessen Kindermenge erweitern
*/
self->partner->refresh_all
/* auch dort neu zeichnen
*/
}
printf("Kind eingefuegt\n")
}
113
Typischerweise wird eine Methode dadurch aufgerufen, da eine entsprechende
Nachricht an das Objekt geschickt wird. Zum Beispiel bekommt ein Objekt p
vom Typ Person eine Tochter namens Martina durch den Aufruf
p->kind hinzu ("Martina", `w'). Die folgende Methode verwendet die aus
O2kit importierte Klasse Box zur Auswahl eines Heiratskandidaten:
method body heirate: boolean in class Person
{
o2 Box
dialog
/* Variable vom Typ Box
o2 string
ergebnis
/* Variable vom Typ String
o2 list(string) liste
/* Liste von Strings
o2 Person
p
/* Variable vom Typ Person
*/
*/
*/
*/
dialog = new Box
/* lege eine Box an
*/
for (p in personen)
if (p != self)
liste += list(p->vorname + " "
+ p->nachname)
/*
/*
/*
/*
*/
*/
*/
*/
durchlaufe alle Personen
uebernimm in Liste
die Konkatenation von
Vorname und Nachname
ergebnis = dialog->selection("Heiratskandidaten:","",liste)
if (ergebnis != "")
for (p in personen) {
if ((ergebnis == p->vorname
+ " " + p->nachname) &&
(p->geschlecht != self->geschlecht)
&& (p->partner == nil))
/*
/*
/*
/*
/*
/*
/* Box */
falls nicht cancel
durchlaufe alle Personen
suche nach Person mit
ergebnis-Vor/Nachnamen
anderes Geschlecht
und ohne Partner
*/
*/
*/
*/
*/
*/
{
self->partner = p
p->partner
= self
if (self->geschlecht=='M')
p->nachname = self->nachname
else self->nachname=p->nachname
self->refresh_all
self->partner->refresh_all
return true
}
} else return false
}
114
/* setze Partnerverweise
*/
/* trage Familiennamen ein
*/
/* zeichne Person neu
/* zeichne Partner neu
*/
*/
8.7 Applikation
Programme zum Aufruf von Methoden werden in einer Applikation zusammengefat. Die folgende Prozedur verheiraten sucht nach Vorgabe von Vor- und
Nachnamen zwei Personen in der benannten Variablen personen und setzt die
Partnerverweise entsprechend.
transaction body verheiraten(vorname1: string,
nachname1: string,
vorname2: string,
nachname2: string): boolean in application uni
{
o2 Person x,y
/* zwei Personen
*/
for (x in personen)
{
if ((x->vorname == vorname1) &&
(x->nachname== nachname1)&&
(x->partner == nil))
{
for (y in personen)
{
if ((y->vorname == vorname2) &&
(y->nachname== nachname2) &&
(y->geschlecht != x->geschlecht)
&& (y->partner == nil))
{
y->partner = x
x->partner = y
if (x->geschlecht=='M')
y->nachname = x->nachname else
x->nachname = y->nachname
y->refresh_all
x->refresh_all
return true
}
}
}
}
return false
}
115
/* durchlaufe Personen
*/
/* suche nach Vorname1
/* und Nachname1
/* ohne Partner
*/
*/
*/
/* durchlaufe Personen
*/
/*
/*
/*
/*
*/
*/
*/
*/
suche Vorname2
und Nachname2
anderes Geschlecht
ohne Partner
/* setze Partnerverweise */
/* bestimme Familienname */
/* zeichne das display
/* beider Personen neu
/* Heirat erfolgreich
*/
*/
*/
/* Heirat gescheitert
*/
8.8 O2 SQL
Die Abfragesprache O2 SQL kann als Ergebnis einer Query Werte, strukturierte
Tupel oder Objekte zuruckliefern.
1. Liste alle Personen (als Objekte)
select p from p in personen
2. Liste das Alter aller Personen (als Wert)
select p->alter from p in personen
3. Liste Vorname und Alter aller Personen (als Tupel)
select tuple(name : p->vorname,
alter: p->alter)
from p in personen
4. Liste die Kinder von Willi Wachtel (als Objekte)
select p->kinder
from p in personen
where p->nachname = "Wachtel"
and
p->vorname = "Willi"
5. Liste die Vornamen der Kinder von Willi Wachtel (als Werte)
select q->vorname
from p in personen, q in p->kinder
where p->nachname = "Wachtel"
and
p->vorname = "Willi"
6. Liste die Vornamen der Kinder von Willi Wachtel (als Tupel)
select tuple(kinder : select k->vorname
from k in p->kinder)
from p in personen
where p->nachname = "Wachtel"
and
p->vorname = "Willi"
116
7. Liste die Vornamen aller Partner (als Tupel)
select tuple(mann: p->vorname,
frau: p->partner->vorname)
from p in personen
where p->geschlecht ='M'
and
p->partner
!= nil
8. Liste die Vornamen aller Vater mit den Vornamen ihrer Kinder (als Tupel)
select tuple(vater : p->vorname,
kinder: select b->vorname
from b in p->kinder)
from p in personen
where p->geschlecht='M'
and count(p->kinder) > 0
9. Liste alle Vornamen mit der Anzahl der Kinder (als Tupel)
select tuple(vorname: p->vorname,
anzahl: count(p->kinder))
from p in personen
10. Liste das Durchschnittsalter der Kinder von Willi Wachtel (als Wert)
select avg(select k->alter from k in p->kinder)
from p in personen
where p->nachname = "Wachtel"
and
p->vorname = "Willi"
11. Liste alle Vornamen von Personen, die als Buchtitel auftauchen (als Werte)
select p->vorname
from p in personen, b in buecher
where p->vorname = b->titel
12. Bestimme das hochste Alter (als Wert)
max(select p->alter from p in personen)
13. Finde die alteste Person (als Objekt)
select p
from p in personen
where p->alter = max(select q->alter from q in personen)
117
14. Gruppiere alle Personen bezuglich ihrer Kinderzahl (als Objekte)
group p in personen
by (wenig : count(p->kinder) < 2,
mittel: count(p->kinder) = 2,
viel : count(p->kinder) > 2)
15. Gruppiere alle Personen nach ihren Vornamen (als Objekte)
group p in personen
by (vorname: p->vorname)
16. Liste zu jedem Vornamen seine Haugkeit (als Tupel)
group p in personen
by (vorname: p->vorname)
with ( anzahl : count(partition))
17. Liste Vorlesungen von Willi Wachtel (als Objekte)
select s->hoert
from s in student
where s->nachname = "Wachtel"
and
s->vorname = "Willi"
18. Liste Vorlesungstitel von Willi Wachtel (als Werte)
select v->titel
from s in student, v in s->hoert
where s->nachname = "Wachtel"
and s->vorname
= "Willi"
118
Das Ergebnis einer Query kann alphanumerisch oder graphisch dargestellt werden. Fur die ersten drei Queries lautet die alphanumerische Antwort:
set(
Person]
Person]
Person]
)
set(
40
43
52
)
set(
tuple(
name:
Erika
alter:
40
)
tuple(
name:
Willi
alter:
43
)
tuple(
name:
Daniel
alter:
52
)
)
119
9 Synchronisation paralleler Transaktionen
9.1 Transaktionen
Bisher:
Jetzt:
Serieller Zugri auf die Datenbank
Paralleler Zugri auf die Datenbank
Beispiel: Flugplatzreservierung im Reiseburo
2 Kunden fragen an, Antwort: ja, beide bekommen den letzten
Platz
Losung: Zusammenfassung nicht-trennbarer Aktionen zu Transaktionen
Wechselseitiger Ausschlu (mutual exclusion)
Def.:
Eine Transaktion ist die Zusammenfassung zusammengehoriger
Einzelaktionen
Beispiele fur 2 Transaktionen:
t1
t2
t1
t2
a b seien Konten desselben Kunden
read(a)
read(a)
read(b)
a := a - 1
write(a)
read(a)
a := a - 1
a := a - 1
read (a)
read(b)
write(a)
write(a)
b:= b + 1
write(b)
"
falsches Ergebnis
in a
"
inkonsistente
Sicht bzgl. der Summe
der Sparguthaben
Also: Erforderlich ist exklusiver Zugri!
Def.: Ein Item ist eine Einheit der Datenbank, das mit einem lock fur einen
exclusiven Zugri reserviert werden kann (locks vergibt der lock manager).
Transaktionen lauten jetzt:
lock(a)
read(a)
a := a - 1
write(a)
unlock(a)
120
Bedeutung von lock(a):
falls a nicht reserviert: reserviere es fur Aufrufer
sonst: blockiere Aufrufer.
Bedeutung von unlock(a):
lose Reservierung fur a
falls jemand durch lock(a) blockiert ist, lose Blockierung und reserviere a fur ihn.
Probleme durch locks:
1.) Livelock (Starvation)
Eine Transaktion t wartet mit lock(a) ewig, da sich andere Transaktionen
mit lock(a), unlock(a) abwechseln.
Losung: Bedienung der Warteschlange fur ein Item nach First-Come-FirstServed.
2.) Deadlock
t1
t2
lock(a)
lock(b)
lock(b)
lock(a)
unlock(b)
unlock(a)
unlock(a)
unlock(b)
..
.
..
.
t1 und t2 warten ewig aufeinander.
Losung: z.B. alle locks gleichzeitig beantragen
z.B. lineare Ordnung auf Items einfuhren, locks nur
in dieser Reihenfolge beantragen
z.B. von Zeit zu Zeit im wait-for-graph nach Kreisen
suchen und \brutal" auosen
wait-for-graph:
m
Ti
m
- Tj
Ti wartet auf item, das Tj belegt.
Im weiteren: weder livelocks noch deadlocks vorhanden
Problem jetzt: Verhindern von ungewollten Seiteneekten.
121
9.2 Serialisierbarkeit
Def.: Ein Schedule fur eine Menge von Transaktionen ist eine Festle-
gung fur die Reihenfolge samtlicher Einzelaktionen (die Reihenfolge
der Einzelaktionen einer Transaktion mu naturlich berucksichtigt
werden).
Def.: Ein Schedule heit seriell, wenn jeweils alle Schritte einer Transaktion unmittelbar hintereinander ablaufen.
Def.: Ein Schedule heit serialisierbar, wenn es ein serielles Schedule gibt,
das denselben Eekt produziert.
seriell:
serialisierbar:
read(a)
a := a-10
write(a)
read(b)
b := b+10
write(b)
read(a)
read(b)
read(a)
a := a-10
b := b-20
write(a)
write(b)
read(b)
read(c)
b := b+10
c := c+20
write(b)
a := a-10
read(b)
write(a)
read(b)
b := b-20
write(b)
read(c)
c := c+20
write(c)
vorher
nacher
nicht serialisierbar:
a
a-10
b
b-10
b := b-20
read(b)
write(b)
b := b+10
read(c)
write(b)
c := c+20
write(c)
write(c)
c
c+20
a
a-10
Wichtig:
b
b-10
c
c+20
a
a-10
b
b+10
Sei f(a) die Wirkung einer Transaktion T auf a zwischen lock(a) und unlock(a).
Dann verursachen fur uns g(f(a)) und f(g(a)) zwei verschiedene Eekte! (auch
wenn zufallig f(g(a)) = g(f(a)) sein sollte)!
122
c
c+20
Algorithmus zum Testen auf Serialisierbarkeit:
Input:
Output:
Ein Schedule S fur Transaktionen T1 : : : Tk .
entweder: \ nein, ist nicht serialisierbar"
oder: \ja, ist serialisierbar wie folgt + serielles Schedule"
Methode: Bilde gerichteteten Graph, dessen Knoten den Transaktionen entsprechen. Sei Aktion Ti : unlock(x), suche nachste Aktion der
Form Tj : lock(x). Bilde Ti - Tj
Idee: In jedem seriellen Schedule mu Ti vor Tj kommen. Es gilt: G hat keinen Kreis
, S ist serialisierbar, und zwar gema der topologischen Ordnung
von G.
m
Beispiel:
T1 : lock (a)
T2 : lock (b)
T2 : lock (c)
T2 : unlock (b)
T1 : lock (b)
T1 : unlock (a)
T2 : lock (a)
T2 : unlock (c)
T2 : unlock (a)
T3 : lock (a)
T3 : lock (c)
T1 : unlock (b)
T3 : unlock (c)
T3 : unlock (a)
m
m@
T1
ergibt
@
I
R
@
@
m
T2
m;
T3 ;
Beweis fur Korrektheit:
()) Hat G keinen Kreis, so betrachte fur item a die Folge von locks und unlocks
und die zugehorigen Transaktionen.
Ti :
lock (a)
unlock (a)
Ti :
..
.
lock (a)
unlock (a)
Tir :
lock (a)
unlock (a)
1
2
123
Nach Konstruktion gilt Ti ! Ti ! Ti ! : : : ! Tir . Also wird im konstruierten seriellen Schedule diese Reihenfolge eingehalten. Keine weiteren Transaktionen fuhren locks auf a aus. Also hat das konstruierte Schedule denselben Eekt
bzgl. a wie Schedule S. Dies gilt fur alle Items ) serialisierbar.
1
2
3
(() Hat G einen Kreis Tj ! Tj ! : : : ! Tj t ! Tj , so nimm an, R sei
ein zu S aquivalentes, serielles Schedule. Die erste Transaktion in R vom Kreis
sei Tj p . Wegen
Tjp ! Tjp im Kreis
gilt oenbar
Tjp : unlock a
Tjp : lock a
Tj p wendet auf a Funktion f an. In R wendet spater Tjp g an. In S wird
jedoch durch Tjp g vor f angewendet. Widerspruch!
1
2
1
;1
;1
;1
;1
Fazit: Beliebige Verzahnung von Transaktionen kann Livelock, Deadlock oder
nicht-serialisierbare Schedules hervorbringen. Der Scheduler mu beim Bemerken dieser Eekte eingreifen: er setzt eine oder mehrere Transaktionen zuruck.
Def.: Eine Transaktion gehorcht dem 2-Phasen-Sperrprotokoll, falls sie
nach dem ersten unlock kein lock mehr anfordert.
sperren
6
-
124
Zeit
Satz:
Ein Schedule S, entstanden nach dem 2-Phasen-Sperrprotokoll, ist
serialisierbar.
Beweis: Annahme: nicht. Wegen Beweis fur Korrektheit des Algorithmus zum
Testen auf Serialisierbarkeit mu der Vorranggraph G fur S einen
Kreis Ti ! Ti ! : :(: ! Tip ! Ti haben. Dann aber gilt
1
2
..
.
Ti
1
(
Ti
unlock(x)
lock(x)
..
.
..
.
2
Tip
(
Ti
(
1
..
.
unlock(y)
lock(y)
..
.
1
Also folgt in Ti nach einem unlock ein lock. Widerspruch!
1
Beobachtung: Nicht immer wird zwischen lock und unlock das Item verandert!
Also: unterscheide zwischen read-only-Zugri und read-write-Zugri.
also:
reserviert x zum Lesen
reserviert x zum Schreiben
gibt x frei
Ein Item kann mehrere rlocks haben, aber nur ein wlock.
rlock(x)
wlock(x)
unlock(x)
Sei Ti : rlock(a) eine Transaktion, die lesen will.
Sei Tj : wlock(a) die nachste Transaktion, die schreiben will.
Dann gilt Ti ! Tj .
Sei Ti : wlock(a) eine Transaktion, die schreiben will.
Sei Tj : wlock(a) die nachste Transaktion, die schreiben will.
Dann gilt Ti ! Tj .
Sei Tm : rlock(a) eine Transaktion, die lesen will und zwar nach Ti :
und vor Tj : wlock(a).
Dann gilt Ti ! Tm .
125
unlock(a)
Algorithmus zum Testen auf Serialisierbarkeit mit read- und write-locks
Input:
Schedule S
Output: A quivalentes, serielles Schedule, falls existiert
Methode: Bilde gerichteten Graph G, Knoten Transaktionen, Kanten
gema der Fallunterscheidung.
T1
T2
T3
wlock a
T4
rlock b
unlock a
rlock a
unlock b
rlock
wlock b
a
unlock b
wlock b
unlock a
unlock a
wlock a
unlock b
rlock b
unlock a
unlock b
Es ergibt sich der folgende Graph:
T1
Y
H
H
T2
6
H
HH
HH
HH
H
-
T4
?
T3
H
H
126
Beobachtung: Nicht immer wird bei write
..
.
lock
das Item gelesen.
write (x)
unlock (x)
Eekt geht verloren!
wlock (x)
x := 0
write (x)
unlock (x)
Also:
Wenn im Schedule S die Transaktion T2 ein Item x liest, welches von T1 geschrieben wurde, so gilt:
m
T1
m
- T2
und niemand darf zwischen T1 und T2 Item x verandern. D.h. wenn im Schedule
S Transaktion T3 das Item x schreibt, so mu dies entweder vor T1 oder nach
T2 erfolgen.
Der resultierende Graph hat \entweder-oder"-Kanten, der Test auf Serialisierbarkeit hat exponentielle Laufzeit.
127
9.3 Zeitstempelverfahren
Jede Transaktion erhalt beim Eintritt ins System einen eindeutigen Zeitstempel
(durch System-Uhr, z.B. bei 1 tic pro millisecunde ) 32 Bits reichen fur
49 Tage). Schedule korrekt, falls seine Wirkung dem seriellen Schedule gema
Eintrittszeiten entspricht.
Jede Einzelaktion druckt einem Item seinen Zeitstempel auf. D.h. jedes Item
hat einen
Lesestempel
hochster Zeitstempel, verabreicht durch eine Leseoperation
Schreibstempel hochster Zeitstempel, verabreicht durch eine Schreiboperation
Marken sollen Verbotenes verhindern:
1. Transaktion mit Zeitstempel t darf kein Item lesen mit Schreibstempel
tw > t. (Denn alter Item-Wert ist weg.)
2. Transaktion mit Zeitstempel t darf kein Item schreiben mit Lesestempel
tr > t. (Denn der neue Wert kommt zu spat.)
Bei Eintreten von Fall 1, 2 mu Transaktion zuruckgesetzt zu werden.
Bei den beiden anderen Fallen brauchen die Transaktionen nicht zuruckgesetzt
zu werden:
3. 2 Transaktionen konnen dasselbe Item zu beliebigen Zeitpunkten lesen.
4. Wenn Transaktion mit Zeitstempel t ein Item beschreiben will mit Schreibstempel tw > t, so wird der Schreibbefehl ignoriert.
Also folgt als Regel fur Einzelaktion X mit Zeitstempel t bei Zugri auf Item
mit Lesestempel tr und Schreibstempel tw :
if (X = read) and (t tw )
f
uhre X aus und setze tr := maxftr , tg
if (X = write) and (t tr ) and (t tw ) then
f
uhre X aus und setze tw := t
if (X = write) and ( r
w ) then tue nichts
else (X = read and
)
or
(X = write and
w
setze Transaktion zur
uck
f
t t<t
t<t
128
t < tr )g
Beispiel:
1.)
2.)
T1
Stempel
T2
150
read(a)
r := 150
t
3.)
4.)
5.)
a := a - 1
6.)
write(a)
Item
160
a
hat tr = tw = 0
read(a)
:= 160
tr
a := a - 1
write(a)
tw := 160
ok, da 160 tr = 160 und 160 tw = 0
T1 wird zruckgesetzt, da
150 < tr = 160
Beispiel:
T1
200
1.)
2.)
3.)
4.)
5.)
6.)
7.)
T2
150
T3
175
a
tr = 0
tw = 0
read(b)
read(a)
read(c)
write(b)
write(a)
tr = 150
tw = 200
write(c)
write(a)
129
ignoriert, da
175 < tw (a) = 200
b
tr = 0
tw = 0
tr = 200
tw = 200
c
tr = 0
tw = 0
tr = 175
Abbruch von T2 ,
da 150 < tr (c) = 175
9.4 Recovery
Zum Schutz vor Systemzusammenbruchen werden Sicherungskopien auf Magnetbandern erstellt (z.B. taglich). Zwischen den Sicherungslaufen durchlauft das
Datenbanksystem eine Folge von konsistenten Zustanden, von denen jeweils der
letzte auf Platte gespeichert ist. Bei einem Systemzusammenbruch kann der letzte konsistente Zustand mit Hilfe eines log-Files rekonstruiert werden. Im log-File
werden alle A nderungsaktionen der Datenbank protokolliert. Ein typischer Eintrag enthalt Angaben zur Kennung der Transaktionen, des veranderten Items
sowie Anfangs- und Endezeit.
Wenn alle Aktionen einer Transaktion im Arbeitsbereich beendet sind und diese Aktionen im log-File vermerkt sind, gilt eine Transaktion als committed.
Wenn eine Transaktion committed ist, wird der neue Zustand in die Datenbank ubertragen. Dann wird im log-File die Endezeit vermerkt. Bei einem Problem wahrend des U bertragens des Arbeitsbereiches in die Datenbank wird eine
solche Transaktion wiederholt, die zwar eine Anfangszeit, aber keine Endezeit
im log-File aufweist. Bei einem Systemabsturz ohne Plattencrash werden, beginnend beim aktuellen Datenbankzustand, alle committed Transaktionen mit
Hilfe des log-Files wiederholt. Bei einem Plattencrash werden, beginnend bei
der auf Band gesicherten Version, alle committed Transaktionen mit Hilfe des
log-Files wiederholt.
Obacht: Transaktionen, die Items von non-committed-Transaktionen lesen wollen, mussen entweder auf das commit warten oder durfen fortfahren mit der
Bereitschaft, sich spater zurucksetzen zu lassen.
130
10 Datenschutz
Ziel: Mibrauch der gespeicherten Daten verhindern.
Rechtlicher Aspekt:
Durch gesetzgeberische Manahmen ist festzulegen, welche Daten in
welchem Umfang schutzbedurftig sind.
Technischer Aspekt:
Durch technische Manahmen ist der geforderte Schutz zu gewahren.
Zum rechtlichen Aspekt:
Bundesdatenschutzgesetz, 1977: Gesetz zum Schutz vor Mibrauch
personenbezogener Daten bei der Datenverarbeitung
Zum technischen Aspekt:
10.1 Organisatorische Manahmen
|
|
|
|
|
bauliche Manahmen
Pfortner
Ausweiskontrolle
Diebstahlsicherung
Alarmanlage
10.2 Identitatskontrolle
| Magnetkarte
| Stimmanalyse/Fingerabdruck
| Pawort: w ohne Echo eintippen,
System uberpruft, ob f(w) eingetragen ist, f ;1 aus f nicht rekonstruierbar
| dynamisches Pawort: vereinbare Algorithmus, der aus Zufallsstring gewisse Buchstaben heraussucht
Pawortverfahren sollten mit U berwachungsmanahmen kombiniert werden (Ort,
Zeit, Fehleingabe notieren)
131
10.3 Zugriskontrolle
Verschiedene Benutzer haben verschiedene Rechte bzgl. derselben Datenbank.
Berechtigungsmatrix (wertunabhangig):
Benutzer Ang-Nr Gehalt Leistung
A
R
R
RW
(Manager)
B
RW
RW
R
(Personalchef)
C
R
R
|
(Lohnburo)
wertabhangig:
Zugri (A, Gehalt): R: Gehalt < 10.000
W: Gehalt < 5.000
Wesentlich kostspieliger, da erst nach Lesen der Daten entschieden werden kann,
ob der Benutzer die Daten lesen darf. Ggf. werden dazu Tabellen benotigt, die
fur die eigentliche Anfrage nicht verlangt waren.
Beispiel: Zugri verboten auf Gehalter der Mitarbeiter an Projekt 007.
Realisierung durch Sichten:
define view v(ang nr, gehalt) as
select ang nr, gehalt from angest
where gehalt < 3000
Realisierung durch Abfragemodikation:
deny (name, gehalt) where gehalt > 3000
liefert zusammen unter der Query
select gehalt from angest where name = 'Schmidt'
die Query
select gehalt from angest
where name = 'Schmidt' and not gehalt > 3000
In statistischen Datenbanken durfen Durchschnittswerte und Summen geliefert
werden, aber keine Aussagen zu Einzelpersonen. Dies ist sehr schwer einzuhalten, selbst wenn die Anzahl der referierten Datensatze gro ist.
Es habe z.B. Manager X als einziger die Eigenschaft Q.
x := select sum (gehalt) from angest /
y := select sum (gehalt) from angest where not Q /
x ; y liefert das Gehalt von Manager X.
In manchen relationalen Datenbanksystemen sind Zugrisrechte nicht statisch/zentral,
sondern dynamisch verteilt. D.h. der Eigentumer einer Relation kann anderen
Benutzern Rechte erteilen und entziehen.
132
f
grant
read | insert | delete | update | all rights
on <relation> to <user> with grant option]
:
read
insert
delete
update
all rights
with grant option
:
:
:
Beispiel:
A:
B:
B:
:
:
g
darf Tupel lesen
darf Tupel einfugen
darf Tupel loschen
darf Tupel andern
read + insert + delete + update
<user>
darf die ihm erteilten Rechte weitergeben
B
grant read, insert on angest to
with grant option
grant read on angest to
with grant option
grant insert on angest to
C
C
Jeder Benutzer, der ein Recht vergeben hat, kann dieses mit einer
Anweisung wieder zurucknehmen:
f
revoke
read | insert | delete | update | all rights
on <relation> from <user>
-
Revoke
g
Beispiel:
B : revoke all rights on angest from C
Es sollen dadurch dem Benutzer C alle Rechte entzogen werden, die er von
B erhalten hat, aber nicht solche, die er von anderen Benutzern erhalten hat.
Auerdem erloschen die von C weitergegebenen Rechte.
Idee: Der Entzug eines Grant G soll sich so auswirken, als ob G niemals gegeben
worden ware!
Beispiel:
A:
B:
D:
A:
grant read, insert, update
grant read, update
grant read, update
revoke insert, update
on
on
on
on
angest
angest
angest
angest
D
D
E
to
to
with grant option
to
from
D
Hierdurch verliert D sein insert-Recht, E verliert keine Rechte. Falls aber
vorher A Rechte an B gab, z.B. durch
A: grant all rights on angest to B with grant option
dann muten D und E ihr update-Recht verlieren.
133
10.4 Kryptographische Methoden
Schlussel
Schlussel
?
Klartext
-
Verschlusselungsalgorithmus
-
verschlusselter
Text
?
-
Entschlusselungsalgorithmus
- Klartext
Beispiel:
Klartext
Schlussel
Alg.: XOR
Schlussel
Alg: XOR
011
110
101
110
011
000
110
110
110
000
111
110
001
110
111
001
110
111
110
001
geeignet fur lokales Verschlusseln. Problem beim U bertragen.
?
-
Spion
?
-
-
1. Losung: Schicke Schlussel per Kurier.
2. Losung: Schicke \oentlichen" Schlussel uber Leitung, fuhrt zu Public Key Systems.
Public Key Systems:
z.B. Verschlusselungsalgorithmus
enc(x) = xe mod n
Entschlussungsalgorithmus dec(x) = xd mod n
e d n sind so gewahlt, da dec(enc(x)) = x
Aus der Kenntnis von enc(x) e n lat sich d nicht ezient berechnen.
Also: Empfanger B veroentlicht e n.
Sender bildet y = xe mod n.
Empfanger bildet yd mod n = x.
134