Modularisierung von Software • Speicherung von Daten (Datenbank

Modularisierung von Software
• Speicherung von Daten (Datenbank-Komponente, database, DB)
• Verarbeitung
von
Daten
(GeschäftsprozessKomponente, business process, BP)
• Benutzung der Daten (Benutzer-Schnittstelle, user interface, UI)
1
• Suchen,
fetch)
Datenbanksystem, DBS
Finden (retrieval,
find,
lookup,
• Einfügen (insert)
• Aktualisieren, Modifizieren (update, modify)
• Löschen (delete, remove)
von Daten und Information.
CRUD, CDUR, RUDI
2
Information, Daten
über alle unterscheidbaren Objekte eines Unternehmens
und deren Beziehungen:
• Entität (entity)
• Beziehung (relationship)
• Eigenschaft (property)
3
Komponenten eines DBS
• Datenbank (DB)
• Datenbankmanagementsystem (DBMS)
• Benutzer
4
Datenbank
• Die DB repräsentiert einen Aspekt der realen Welt,
genannt Miniwelt oder Universe of Discourse
(UoD).
• Die DB ist eine logisch zusammenhängende Sammlung
von Daten mit inhärenter Bedeutung.
• Die Daten der DB werden für einen bestimmten Zweck
gesammelt.
5
Datenbank
• integrated
• shared
6
Eigentliche Daten
Primärdaten
DB-Zustand
DB-Extension
DB-Ausprägung
DB selbstbeschreibend
Beschreibung der Daten
Metadaten
DB-Schema
DB-Intension
Katalog
7
DBMS
• Definition der Daten in der DB
• Speichern von Daten in der DB
• Manipulation von Daten der DB
• Darstellung von Daten der DB
8
Benutzer
• Anwendungsprogrammierer (application programmers,
system analysts)
• Endbenutzer: Sie verkehren mit der Datenbank über ein Anwendungsprogramm oder direkt über das DBMS.
• Daten-Administrator und Datenbank-Administrator:
Der Daten-Administrator (DA, data administrator) trägt die
zentrale Verantwortung für die Daten eines Unternehmens und
fällt die strategischen Entscheidungen bezüglich der Daten. Der
Datenbank-Administrator (DBA, database administrator)
ist verantwortlich für die Implementation der Entscheidungen des
DA.
9
Datenunabhängigkeit
• program – data independence
• program – operation independence
10
DBS – Architektur
= Schema zur Beschreibung von DBS
ANSI/SPARC – Modell
ANSI/X3/SPARC
ANSI/X3/SPARC Study Group on Data Base Management Systems
11
ANSI/SPARC – Modell
Externe Ebene
Externe Ebene
Q
Q
Externe Ebene
Q
Q
Q
Q
Konzeptuelle Ebene
Interne Ebene
12
Beispiel Konzeptuelle Ebene
Angestellter
Name
Nummer
Abteilung
Gehalt
13
Beispiel Interne Ebene
Depardieux\t3264\tKlassiker\t4725.8\n
Belmondo\t3914\tKomödie\t5207.26\n
Delon\t372\tThriller\t7203\n
Bronson\t11122\tWestern\t6134.32\n
14
Beispiel Externe Ebene
Kennung
372
3264
3914
11122
Lohn
7.203,00
4.725,80
5.207,26
6.134,32
15
Beispiel Externe Ebene
Name
Depardieux
Belmondo
Bronson
Delon
Abteilung Kosten
Klassiker
57
Komödie
63
Western
74
Thriller
87
16
Leistungen
• Logische Datenunabhängigkeit
• Physische Datenunabhängigkeit
• Aber: Die Abbildungen zwischen den Ebenen werden
durch Änderungen in den Ebenen berührt.
17
Konzeptuelle Ebene
• konzeptuelle Sicht (conceptual view)
ist eine Repräsentation des gesamten Informationsgehalts der DB.
• konzeptuelle Datensätze (conceptual record)
• konzeptuelles oder logisches Schemas
(conceptual schema)
• datenunabhängig
• Zugriffsrechte und Integritätsregeln
• high-level oder konzeptuelles Datenmodell
18
Interne Ebene
• interne Sicht (internal view)
ist eine Repräsentation der gesamten DB.
• internen Datensätzen (internal record)
• unendlich großer linearer Adressraum
• internes Schema (Speicherstrukturdefinition)
(internal schema, storage structure definition)
• Repräsentations- oder Implementationsmodell
(representational or implementation data model).
• physisches Datenmodell
(physical, low-level data model)
19
Externe Ebene
• Die externe Ebene ist die Ebene
des einzelnen Benutzers.
• externe Sicht (external view)
• externe Datensätze (external record),
logische Datensätze (logical record)
• externen Schemas (external schema)
• Hierarchie von externen Schemata
20
Sprachen
• DSL (data sublanguage)
– enge (tightly coupled) Kopplung
– lose (loosely coupled) Kopplung
• Beispiel: SQL
• Komponenten:
– Datendefinitionssprache
(data definition language, DDL + (CDL))
– Datenmanipulationssprache
(data manipulation language, DML)
21
DDL – Sprachen
• Prinzipiell hat jede Ebene ihre eigene Sprache.
• Interne Ebene: DDL → SDL
(storage definition language)
• Externe Ebene: DDL → VDL
(view definition language)
• Konzeptuelle Ebene: DDL → DDL
• SQL kann alles sein.
Trend: Elimination von SDL-Anteilen
22
DML – Sprachen
• high-level oder deklarative oder nichtprozedurale oder set-at-a-time oder Mengenorientierte Sprachen, die es erlauben DBOperationen in knapper Form interaktiv oder
embedded auszudrücken.
• low-level oder prozedurale oder record-at-atime oder Datensatz-orientierte Sprachen, die in
einer Hostsprache eingebettet sein müssen. Hier werden
einzelne Datensätze ermittelt und bearbeitet.
23
Benutzerfreundliches UI
Menübasierte Oberfläche: Ein Angebot von Optionen (Menü) führt den Benutzer bei der Formulierung einer Anfrage. Beliebt sind Zeilen- und Pulldown-Menüs
und die Verwendung von Funktionstasten für naive Benutzer.
Graphische Oberfläche: Teile des DB-Schemas werden als Diagramm dargestellt. Der Benutzer kann Anfragen formulieren, indem er das Diagramm manipuliert. Kombiniert wird das i.a. mit Menüs.
24
Benutzerfreundliches UI
Formularbasierte Oberfläche: Dem Benutzer wird
ein Formular angeboten, das er auszufüllen hat,
um entweder diese Daten zu speichern oder zu
suchen. Formular-Spezifikations-Sprachen ermöglichen
die leichte Entwicklung solcher formular-basierter Oberflächen für den naiven Benutzer zur Durchführung von
Standard-Transaktionen (canned transaction).
Natürlichsprachliche Oberfläche: Diese
Oberflächen akzeptieren Anfragen, die in Englisch oder
anderen Sprachen formuliert werden können. Dialoge
helfen bei der Klärung von Missverständnissen.
25
Datenbankadministrator – DBA
Daten-Administrator (DA): Hat zentrale Verantwortung für die Daten. Kennt die Bedeutung der Daten
für das Unternehmen.
Datenbank-Administrator (DBA): Ist eine informationstechnisch ausgebildete Person, die dafür verantwortlich ist, dass die Entscheidungen des DA implementiert werden. Richtet die Datenbank ein, vergibt
die Zugriffsrechte nach den Richtlinien des DA. Er ist
auch für die Leistungsfähigkeit des Systems verantwortlich. Dazu mag es erforderlich sein, eine Gruppe von
Systemprogrammierern zu leiten.
26
Aufgaben des DBA
• Definition des konzeptuellen Schemas: DA bestimmt
die für das Unternehmen relevanten Entitäten, deren
Eigenschaften und Beziehungen. Dieser Prozess heißt
logisches oder konzeptuelles Datenbankdesign (logical or conceptual database design). Auf Grund dieses
Designs wird der DBA unter Verwendung der konzeptuellen DDL das konzeptuelle Schema erstellen.
• Definition des internen Schemas: Der DBA entscheidet,
wie die Daten in der gespeicherten DB repräsentiert
werden sollen. Physisches Datenbankdesign (physical
database design).
27
Aufgaben des DBA
• Betreuung der Benutzer: Der DBA sorgt dafür, dass einem Benutzer die Daten zur Verfügung stehen, die er benötigt. Unterstützt
Erstellung externer Schemata.
• Definition von Zugriffsrechten und Integritätsregeln
• Definition von Datensicherungsmechanismen (backup und recovery):
• Überwachung der Systemleistung: Anpassungen des internen Schemas
• Reaktion auf sich ändernde Anforderungen an die DB: Hier kann
es auch mal zu einem Eingriff in das konzeptuelle Schema kommen.
28
Datenbankmanagementsytem
Alle Zugriffe auf die DB gehen über das DBMS.
1. Der Benutzer formuliert eine Anforderung an die DB unter Verwendung einer DSL.
2. Das DBMS fängt die Anforderung ab und analysiert sie. Dabei verwendet das DBMS das externe Schema des betreffenden Benutzers,
die entsprechende Abbildung extern↔konzeptuell, das konzeptuelle Schema, die Abbildung konzeptuell↔intern und das interne
Schema.
3. Das DBMS führt die notwendigen Operationen an der gespeicherten DB durch.
29
Funktionen des DBMS
Datendefinition: Das DBMS muss in der Lage sein,
Datendefinitionen, d.h. externe, konzeptuelle, interne
Schemata im Quellcode zu akzeptieren und in einen
geeigneten Objektcode zu übersetzen. Das DBMS hat
Compiler für die verschiedenen DDLs.
30
Funktionen des DBMS
Datenmanipulation: Zum Verarbeiten von DMLs
muss das DBMS entsprechende Komponenten haben.
DML-Anforderungen können geplant oder ungeplant
sein.
geplant: operative oder Produktionsanwendungen,
compiled oder canned transaction
ungeplant: Ad-hoc-Anforderung (Anwendungen der
Entscheidungsfindung, decision support)
31
Funktionen des DBMS
Datensicherheit und –integrität
Transaktionsmanager (transaction manager)
Datenlexikon (data dictionary) Datenkatalog,
Metadaten, directory, catalog, data repository,
data encyclopedia
32
File-Manager
• Kreiert und löscht Files.
• Weiß nichts über die interne Datensatzstruktur und
kann daher keine Anforderungen bearbeiten, die eine
Kenntnis der Datensatzstruktur voraussetzen.
• Zugriffsrechte und Integritätsregeln werden typischerweise nicht unterstützt.
• Parallele Zugriffe werden typischerweise nicht unterstützt.
33
Datenkommunikation
• Datenkommunikationsmanager
(data communications manager
(DC manager))
• Botschaften (communication messages)
• DB/DC–System
(database/data-communications system)
34
Client/Server–Architektur
zweiteilige Struktur
• Der Server ist das DBMS selbst.
• Clients sind die verschiedenen Anwendungen, die das
DBMS benutzen.
35
Anwendungsprogramme
• Anwendungen, die vom Benutzer geschrieben werden.
• Anwendungen, die der DBS-Lieferant zur Verfügung
stellt, sogenannte Werkzeuge oder Tools.
36
Werkzeuge, Tools
• Interpreter/Compiler für Zugriffssprachen
(query language processors)
• Interpreter/Compiler für natürliche Sprachen
(natural language processors)
• Berichtsgeneratoren (report writers)
• Graphische Teilsysteme (graphics subsystems)
• Tabellenkalkulation (spreadsheets)
• Statistische Pakete (statistical packages)
• Anwendungsgeneratoren
(application generators, 4GL processors)
• CASE–Produkte
37
Dienstprogramme
(utilities)
• Ladeprogramme (load, reload)
• Entladeprogramme (unload, dump)
• Reorganisationsprogramme (reorganization)
• Statistische Programme, die statistische Kenngrößen
der DB (Filegrößen, Zugriffshäufigkeiten) ermitteln und
analysieren.
38
Verteilte Abarbeitung
(distributed processing), DBMS(-backend), Frontends.
• Parallele Verarbeitung
• Die Server-Maschine kann speziell für DBMS-Zwecke
ausgerüstet werden (database machine).
• Die Client-Maschinen können auf die jeweiligen Anwendungen zugeschnitten werden.
• Die Anwendungen sind den betrieblichen Gegebenheiten entsprechend räumlich trennbar.
39
Verteilte Abarbeitung
DB auf verschiedene Server-Maschinen verteilt:
• Ein Client kann auf eine beliebige Anzahl von Servern zugreifen,
aber nur auf einen zur Zeit. Der Benutzer muss wissen, auf welchem
Server sich die von ihm gewünschten Daten befinden. Er kann mit
einem Zugriff nicht Daten von verschiedenen Servern kombinieren.
• Ein Client kann gleichzeitig auf eine beliebige Anzahl von Servern zugreifen. Ein Zugriff kann Daten von verschiedenen Servern
kombinieren. Der Benutzer muss nicht wissen, wo sich die Daten
befinden (transparenter Zugriff). Für ihn verhalten sich die vielen
Server wie ein Server. Man spricht jetzt von einem verteilten
DBS (distributed DBS).
40
Entwicklung von Datenbanken
1. Definition einer Daten-Norm
2. Problembeschreibung
3. Analyse: Identifikation von Entitäten, Eigenschaften,
Beziehungen
4. Design:
• Erstellung des Entity-Relationship-Modells
• Umsetzung in Relationen oder Klassen oder . . .
5. Implementation
6. Erstellung von Anwendungen
41
E/R-Modell — Objektorientierung
E/R-Modell
objektorientiert andere Bezeichnungen
Entität als Typ
Klasse
Typ
Entität als Objekt Objekt
Instanz, Ausprägung, Exemplar,
identifizierbares Etwas
Beziehung
Assoziation
Verknüpfung
”Hat-ein”–Beziehung (has-a)
Aggregation, Komposition
”Benutzt-ein”–Beziehung (uses-a)
Ähnlichkeit (is-like-a)
Eigenschaft
Attribut
(abgeleitet)
Methode
Operation, Botschaft, Verhalten
42
E/R-Modell — Objektorientierung
E/R-Modell objektorientiert andere Bezeichnungen
Obertyp
Basisklasse
Oberklasse, Superklasse, Supertyp,
Eltertyp, Obermenge
”Ist-ein”–Beziehung (is-a),
Erweiterung, Vererbung, Substitution,
Generalisierung / Spezialisierung
Untertyp
Abgeleitete
Unterklasse, Subklasse, Subtyp,
Klasse
Kindtyp, Teilmenge
43
Faches in einem oder mehreren Semestern an mehreren
Terminen und Orten. Die Veranstaltung hat eine eindeutige Nummer und eine Prüfungsleistung. Die in einem Semester angebotenen Fächer erhalten eine Veranstaltungsnummer, die nur für dieses Semester gilt. Dazu wird der
jeweilige Dozent angegeben und die Art der Lehrveranstaltung (Vorlesung, Praktikum, Seminar) sowie ihr Umfang
in Semesterstunden.
Die Notenbildung kann durch eine oder mehrere Prüfungsleistungen erfolgen (Präsentation, Projektarbeit, Klausur, mündliche Prüfung), die in unterschiedlichen Prozentsätzen gewichtet werden. Jede Klausur oder mündlicge Prüfung findet zu einem festgelegten Datum in einem
Raum zu einer Uhrzeit statt und wird durch mindestens
einen Dozenten beaufsichtigt. Zusätzlich soll die Dauer der
Klausur oder mündlichen Prüfung vermerkt werden. Bei
mündlichen Prüfungen muss ein zweiter Dozent dabei sein.
Ein Student hat eine eindeutige Matrikelnummer, einen
Namen und einen Studiengang.
Liste von Substantiven:
Fach, FachNummer, Titel, Studiengang, Veranstaltung, Wirtschaftsinformatik, Angewandte Informatik,
Netzwerk- und Medientechnik, Faecherblock, Consulting,
Informatik Durchfuehrung, Semester, Termin, Ort, Dozent, Art der Lehrveranstaltung, Vorlesung, Praktikum,
Seminar, Umfang, Semesterstunden Notenbildung, Pruefungsleistung, Pruefung Prozentsatz, Praesentation, Projektarbeit, Klausur, Dauer, Muendliche Pruefung, Datum,
Uhrzeit, StudentIn, Matrikelnummer, Name Raum,
Liste nach 1. Bearbeitung:
Fach, Nummer, Titel, Studiengang, Fach[*] Lehrgang Veranstaltung[*] Veranstaltung, Nummer, Termin[*] Semester
Umfang Wirtschaftsinformatik,44Angewandte Informatik,
Netzwerk- und Medientechnik, Faecherblock, Fach[*] Con-
ANR
Abteilung
AbtName
1
AName
VorN MiN NaN
Gehalt
Adresse
Monatsgehalt
AbtAngest
PName
ArbeitetAn
M Projekt
Angestellter M
M
1 Leitet M
1
M
AngestAngeh
M
Vorname
Angehöriger
45
LNR
LName
PName
Status
Lieferant
M
M
Tag
M
Projekt M
M
Tagesprojekt
LiefertTeilFürProj
M
Langzeitproj.
Ende Entwickl.proj.
46
LiefertTeil
M
Teil
M
Laufzeit
Start
Stadt
M
Struktur
Menge
Entität (Entity)
”a thing which can be distinctly identified”
• reguläre (starke, regular, strong)
Diagramm: Rechteck mit Name der Entität
• schwache (weak)
Diagramm: verdoppeltes Rechteck mit Name
47
Beziehung (Relationship)
”an association among entities”
• Teilnehmer (participants)
• Grad (degree)
• zwingend (total, mandatory)
• freigestellt, partiell (optional, partial)
• eineindeutig (one-to-one, 1:1)
• einseitig eindeutig (one-to-many, 1:M)
• komplex (many-to-many, N:M)
48
Beziehung (Relationship)
Diagramm: Rhombus mit Name der Beziehung oder
Doppelrhombus, wenn schwache Entitäten beteiligt sind.
49
Eigenschaft (Property)
• eindeutig (unique, key)
• einfach (simple) oder zusammengesetzt (composite)
• ein- oder mehrwertig (single- or multi-valued)
• abgeleitet oder nicht (derived or base)
50
Eigenschaft (Property)
Diagramm:
• Ellipse mit Namen der Eigenschaft
• Eindeutige Eigenschaften werden unterstrichen
• Doppelellipse bei mehrwertigen Eigenschaften
• Punktierte Ellipse bei abgeleiteten Eigenschaften
51
Untertypen (Subtypes)
• ”Ist-ein”-Typenhierachie
• Obertyp (Vatertyp, parent type, supertype)
Diagramm: Pfeil vom Untertyp zum Obertyp.
52
AName
Abteilung
VorN
MiN
NaN
AbtName
1
Tagesprojekt
AbtAngest
Tag
*
Angestellter
ANR {unique}
Name: AName
Gehalt
Adresse[*]
Monatsgehalt ()
*
ArbeitetAn
*
Projekt
PName
Leitet
1
*
*
Langzeitprojekt
*
Start
Ende
Angehöriger
Vorname
Entwicklungsprojekt
LiefertTeilFürProj
*
*
* LiefertTeil *
Teil
*
*
Lieferant
LNR {unique}
LName
Status
Stadt
Struktur
Menge
53
ANR
Abteilung
AbtName
1
AName
VorN MiN NaN
Gehalt
Adresse
Monatsgehalt
AbtAngest
M
PName
ArbeitetAn
M Projekt
M
1 Leitet M
Angestellter M
1
AngestAngeh
M
Angehöriger
Vorname
54
LNR
PName
LName
Status
Lieferant
M
M
Tag
M
M
Projekt
Tagesprojekt
M
LiefertTeilFürProj
M
Langzeitproj.
Ende
Entwickl.proj.
LiefertTeil
M
Teil
M
Laufzeit
Start
Stadt
M
Menge
Struktur
55
AName
Abteilung
VorN
MiN
NaN
AbtName
1
Tagesprojekt
AbtAngest
Tag
*
Angestellter
ANR {unique}
Name: AName
Gehalt
Adresse[*]
Monatsgehalt ()
*
ArbeitetAn
*
Projekt
PName
Leitet
1
*
*
Langzeitprojekt
*
Start
Ende
Angehöriger
Vorname
Entwicklungsprojekt
LiefertTeilFürProj
*
*
* LiefertTeil *
Teil
*
*
Lieferant
LNR {unique}
LName
Status
Stadt
Struktur
Menge
56
Beziehung (Relationship)
3 Beziehung
−−
—∗
==
==∗
−−
−−
Entität (partiell -zu-eins, partial -to-one)
Entität (partiell -zu-viele, partial -to-many)
Entität (zwingend -zu-eins, total -to-one)
Entität (zwingend -zu-viele, total -to-many)
(Rolle) Entität
(1-3,6) Entität (numerisch spezifizierte Multiplizität)
57
Eigenschaft (Property)
2 Entität
◦ Eigenschaft1
◦ Eigenschaft2 (eindeutig)
◦ Eigenschaft3 (zusammengesetzt)
◦ TeileigenschaftA
◦ TeileigenschaftB
∗ Eigenschaft4 (mehrwertig)
· Eigenschaft5 (abgeleitet)
58
Nichtgraphische Darstellung
2 Angestellter
◦ ANR
◦ AName
◦ Vorname
◦ Mittelname
◦ Nachname
◦ Gehalt
· Monatsgehalt
∗ Adresse
59
Nichtgraphische Darstellung
3 AbtAngest
−− Abteilung
==∗ Angestellter
3
3 AngestAngeh
−− Angestellter
==∗ Angehöriger
u Angehöriger
◦ Vorname
60
Nichtgraphische Darstellung
2 Projekt
◦ PName
2 Langzeitprojekt
—. Projekt
◦ Laufzeit
◦ Start
◦ Ende
2 Entwicklungsprojekt
—. Langzeitprojekt
61
Nichtgraphische Darstellung
3 ArbeitetAn
—∗ Angestellter
—∗ Projekt
3 Leitet
−− Angestellter
==∗ Projekt
62
Mehrdimensionale Zugriffsstrukturen
• KdB-Baum
• Grid-File
• Raumfüllende Kurven
• R-Baum
• Geometrische Zugriffsstrukturen
63
KdB-Baum
• k-dimensionaler B-Baum: k Zugriffs-Attribute
• Bereichsseiten mit b Schnittelementen
• Satzseiten mit t Tupeln
64
Beispiel KdB-Baum
k = 2 (2 Dimensionen)
t = 1 (Satzseiten enthalten höchsten ein Tupel.)
b = 2 (Bereichsseiten enthalten höchstens 2 Schnittelemente.)
Datensätze mit numerischem und alphabetischem Attribut:
15 G | 45 G | 85 F | 15 D | 50 C | 15 A | 85 B | 60 H
65
KdB-Baum
66
KdB-Baum
67
KdB-Baum
68
Brickwall
1. Wir füllen einen zweidimensionalen KdB-Baum nacheinander mit
zweidimensionalen Datensätzen bestehend aus einer ganzen Zahl
und einem Großbuchstaben in Brickwall-Darstellung.
2. Jeder Schritt des Aufbaus der Brickwall (Historie der Zellteilung)
muss verwaltet werden, um Datensätze zu finden, einzufügen oder
zu löschen.
3. Die Brickwall besteht aus Quadern sehr unterschiedlicher Größe
und hat daher eine unregelmäßige Struktur, die es nicht erlaubt,
Hyperebenen oder Regionen für die Suche von Objekten zu definieren.
69
KdB-Baum leer
H
G
F
E
D
C
B
A
0
10
20
30
40
50
70
60
70
80
90
KdB-Baum: plus (15 G)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
15 G
71
60
70
80
90
KdB-Baum: plus (40 G)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
15 G
40 G
72
60
70
80
90
KdB-Baum: plus (80 F)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
60
15 G 40 G
80 F
73
70
80
90
KdB-Baum: plus (10 D)
H
G
F
E
D
C
B
A
0
10
20
30
10 D
40
50
15 G
40 G
74
60
70
80 F
80
90
KdB-Baum: plus (20 A)
H
G
F
E
D
C
B
A
0
10
20
10 D
30
40
15 G
50
60
20 A
40 G
75
70
80 F
80
90
KdB-Baum: plus (50 C)
H
G
F
E
D
C
B
A
0
10
20
10 D
30
15 G
40
50
20 A
40 G
76
60
70
50 C
80
80 F
90
KdB-Baum: plus (90 B)
H
G
F
E
D
C
B
A
0
10
10 D
20
15 G
30
40
20 A
50
60
40 G
50 C
77
70
80 F
80
90 B
90
KdB-Baum: plus (55 E)
H
G
F
E
D
C
B
A
0
10
10 D
20
15 G
30
20 A
40
50
40 G
50 C
78
60
70
55 E
80
90
80 F
90 B
KdB-Baum: plus ( 5 C)
H
G
F
E
D
C
B
A
0
5C
10
10 D
20
15 G
30
40
20 A
50
60
40 G
50 C
79
70
55 E
80
80 F
90
90 B
KdB-Baum: plus (60 H)
H
G
F
E
D
C
B
A
0
5C
10
10 D
20
15 G
30
20 A
40
50
40 G
50 C
80
60
70
55 E
80
90
60 H
80 F
90 B
KdB-Baum leer
H
G
F
E
D
C
B
A
0
10
20
30
40
50
81
60
70
80
90
KdB-Baum: plus (15 G)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
15 G
82
60
70
80
90
KdB-Baum: plus (40 G)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
15 G
40 G
83
60
70
80
90
KdB-Baum: plus (80 F)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
15 G
40 G
80 F
84
60
70
80
90
KdB-Baum: plus (10 D)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
10 D
15 G
40 G
80 F
85
60
70
80
90
KdB-Baum: plus (20 A)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
10 D
15 G
20 A
40 G
80 F
86
60
70
80
90
KdB-Baum: plus (50 C)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
10 D
15 G
20 A
40 G
50 C
80 F
87
60
70
80
90
KdB-Baum: plus (90 B)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
60
10 D
40 G
15 G
80 F
20 A
50 C
90 B
88
70
80
90
KdB-Baum: plus (55 E)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
60
10 D 40 G
15 G 55 E
20 A 80 F
50 C
90 B
89
70
80
90
KdB-Baum: plus ( 5 C)
H
G
F
E
D
C
B
A
0
10
20
30
5C
10 D
40
50
40 G
55 E
80 F
15 G
20 A
90
60
70
50 C
90 B
80
90
KdB-Baum: plus (60 H)
H
G
F
E
D
C
B
A
0
10
20
5C
10 D
30
40
50
60
15 G 40 G
20 A 60 H
50 C
90 B
91
70
55 E
80 F
80
90
Grid-File
• Skala: Für jede Dimension gibt es ein Feld von Intervallen des Wertebereichs eines Zugriffs-Attributs.
• Das Grid-Directory zerlegt den Datenraum in Grid-Zellen (kdimensionale Quader) gemäß den Intervallen der Skalen.
Das Grid-Directory ist i.a. so groß, dass es normalerweise auf dem Sekundärspeicher liegt. Allerdings genügen wenige Zugriffe, um eine Zelle zu
finden. Bei einer exact-match query genügt ein Zugriff.
• Die Grid-Region besteht aus einer oder mehreren Grid-Zellen. Jeder
Grid-Region ist eine Satzseite zugeordnet. Die Grid-Region ist ein kdimensionales konvexes Gebilde, d.h. jeder Datensatz auf der Geraden
zwischen zwei Datensätzen derselben Region liegt ebenfalls in der Region. Regionen sind paarweise disjunkt.
• Die Satzseiten (data bucket) enthalten die Datensätze und liegen auf
dem Sekundärspeicher.
92
Beispiel Grid-File
k = 2 (2 Dimensionen)
t = 1 (Satzseiten enthalten höchsten ein Tupel.)
Datensätze mit numerischem und alphabetischem Attribut:
15 G | 40 G | 80 F | 10 D | 50 C | 20 A | 90 B | 60 H |
93
Grid-File leer
H
G
F
E
D
C
B
A
0
10
20
30
40
50
94
60
70
80
90
Grid-File: plus (15 G)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
15 G
95
60
70
80
90
Grid-File: plus (40 G)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
15 G
40 G
96
60
70
80
90
Grid-File: plus (80 F)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
60
15 G 40 G
80 F
97
70
80
90
Grid-File: plus (10 D)
H
G
F
E
D
C
B
A
0
10
20
30
10 D
40
50
15 G
40 G
98
60
70
80 F
80
90
Grid-File: plus (50 C)
H
G
F
E
D
C
B
A
0
10
20
10 D
30
40
50
60
15 G 40 G
50 C
99
70
80 F
80
90
Grid-File: plus (20 A)
H
G
F
E
D
C
B
A
0
10
20
10 D
30
15 G
40
50
20 A
40 G
100
60
70
50 C
80
80 F
90
Grid-File: plus (90 B)
H
G
F
E
D
C
B
A
0
10
10 D
20
15 G
30
40
20 A
50
60
40 G
50 C
101
70
80 F
80
90 B
90
Grid-File: plus (60 H)
H
G
F
E
D
C
B
A
0
10
10 D
20
15 G
30
20 A
40
50
40 G
50 C
102
60
70
60 H
80
90
80 F
90 B
Grid-File leer
H
G
F
E
D
C
B
A
0
10
20
30
40
50
103
60
70
80
90
Grid-File: plus (15 G)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
15 G
104
60
70
80
90
Grid-File: plus (40 G)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
15 G
40 G
105
60
70
80
90
Grid-File: plus (80 F)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
15 G
40 G
80 F
106
60
70
80
90
Grid-File: plus (10 D)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
10 D
15 G
40 G
80 F
107
60
70
80
90
Grid-File: plus (50 C)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
40 G
50 C
80 F
10 D
15 G
108
60
70
80
90
Grid-File: plus (20 A)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
10 D
15 G
20 A
40 G
50 C
80 F
109
60
70
80
90
Grid-File: plus (90 B)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
60
10 D
40 G
15 G
80 F
20 A
50 C
90 B
110
70
80
90
Grid-File: plus (60 H)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
60
10 D 40 G
15 G 60 H
20 A 80 F
50 C
90 B
111
70
80
90
Grid-File: plus (65 E)
H
G
F
E
D
C
B
A
0
10
20
30
40
50
10 D
40 G
15 G
60 H
20 A
50 C
90 B
112
60
70
65 E
80 F
80
90
Grid-File: plus ( 5 C)
H
G
F
E
D
C
B
A
0
10
20
5C
20 A
30
40
50
60
10 D 40 G
15 G 60 H
50 C
90 B
113
70
65 E
80 F
80
90
Raumfüllende Kurven
Problem: Abbildung k-dimensionales Universum
auf einen ein-dimensionalen Bereich
unter Erhaltung von Nachbarschaftsbeziehungen
114
115
R-Baum
Der R-Baum wurde entwickelt zur Indexierung ausgedehnter Objekte im k-dimensionalen Raum. Der Index speichert für jedes Objekt seine MBB (minimal bounding
box). Der MBB ist dann die Referenz auf das Objekt zugeordnet.
116
117
118
119
120
Beispiel R-Baum
k = 2 (2 Dimensionen)
pKnoten = 3
pBlatt = 3
p1 ... p10 repräsentieren punktförmige Objekte.
m1 ... m10 repräsentieren ausgedehnte Objekte.
121
R-Baum: Einfügen von p1 :
90
80
70
60
50
40
30
p1
20
10
0
0
10
20
30
40
50
60
70
80
90
100
R-Baum
p1
122
110
120
130
R-Baum: Einfügen von m1 :
90
80
m1
70
60
50
40
30
p1
20
10
0
0
10
20
30
40
50
60
70
80
90
100
R-Baum
p1 m1
123
110
120
130
R-Baum: Einfügen von p2 :
90
80
m1
70
60
50
40
30
p2
p1
20
10
0
0
10
20
30
40
50
60
70
80
90
100
R-Baum
p1 m1 p2
124
110
120
130
R-Baum: Einfügen von m2 :
90
R1
80
m1
70
60
m2
50
40
R2
p2
30
p1
20
10
0
0
10
20
30
40
50
60
70
80
90
100
R-Baum
R1 R2
p1 m1 m2 p2
125
110
120
130
R-Baum: Einfügen von p3 :
90
R1
80
m1
70
60
m2
50
40
R2
p2
30
p3
p1
20
10
0
0
10
20
30
40
50
60
70
80
90
100
R-Baum
R1 R2
p1 m1 m2 p2 p3
126
110
120
130
R-Baum: Einfügen von m3 :
90
R1
80
m1
70
60
m2
50
R2
40
30
m3
p2
p3
p1
20
10
0
0
10
20
30
40
50
60
70
80
90
100
R-Baum
R1 R2
p1 m1 m2 p2 p3 m3
127
110
120
130
R-Baum: Einfügen von p4 :
90
R1
80
m1
70
60
m2
50
R2
40
30
R3
p2
m3
p3
p1
20
p4
10
0
0
10
20
30
40
50
60
70
80
90
100
R-Baum
R1 R2 R3
p1 m1 m2 m3 p2 p3 p4
128
110
120
130
R-Baum: Einfügen von m4 :
90
R5R4
80
m1
70
60
m2
R1
50
R2
40
R6
m4
30
R3
p2
m3
p3
p1
20
p4
10
0
0
10
20
30
40
50
60
70
80
90
100
R-Baum
R5 R6
R1 R4
R2 R3
p1 m4 m1 m2 m3 p2 p3 p4
129
110
120
130
R-Baum: Einfügen von p5 :
90
R5R4
80
m1
70
60
m2
R1
50
R2
40
R6
m4
30
R3
p2
m3
p3 R7
p5
p4
p1
20
10
0
0
10
20
30
40
50
60
70
80
90
100
R-Baum
R5 R6
R1 R4
R2 R3 R7
p1 m4 m1 m2 m3 p2 p3 p4
p5
130
110
120
130
R-Baum: Einfügen von m5 :
90
R5R4
80
m1
70
60
m2
R1
50
R2
R6
40
m4
30
m3
R3
p2
m5
p3 R7
p5
p4
p1
20
10
0
0
10
20
30
40
50
60
70
80
90
100
R-Baum
R5 R6
R1 R4
R2 R3 R7
p1 m4 m1 m2 m3 m5 p2 p3 p4
p5
131
110
120
130
R-Baum: Einfügen von p6 :
90
R5R4
80
m1
70
60
m2
R1
50
R2
R6
40
m4
30
m3
R3
p2
m5
20
R7
p3
p1
p4
p6
p5
10
0
0
10
20
30
40
50
60
70
80
90
100
R-Baum
R5 R6
R1 R4
R2 R3 R7
p1 m4 m1 m2 m3 m5 p2 p3 p4
p5 p6
132
110
120
130
R-Baum: Einfügen von m6 :
90
R5R4
80
R6
R7
m1
70
m6
60
m2
R1
50
R2
40
m4
30
m3
R3
p2
m5
p3
p1
20
p4
p6
p5
10
0
0
10
20
30
40
50
60
70
80
90
100
110
R-Baum
R5 R6
R1 R4
R2 R3 R7
p1 m4 m1 m2 m3 m5 p2 p3 p4
p5 p6 m6
133
120
130
R-Baum: Einfügen von p7 :
R9 R8
p7
90
R5R4
80
m1
70
m6
60
m2
R1
50
R2
R6
40
m4
30
m3
R3
p2
m5
20
R7
p3
p1
p4
p6
p5
10
0
0
10
20
30
40
50
60
70
80
90
100
110
R-Baum
R5 R6 R9
R1 R4
R2 R3 R7
p1 m4 m1 m2 m3 m5 p2 p3 p4
R8
p5 p6 m6 p7
134
120
130
R-Baum: Einfügen von m7 :
R9 R8
90
p7
R5R4
80
m1
70
m6
60
m2
R1
m7
50
R2
R6
40
m4
30
m3
R3
p2
m5
20
R7
p3
p1
p4
p6
p5
10
0
0
10
20
30
40
50
60
70
80
90
100
110
R-Baum
R5 R6 R9
R1 R4
R2 R3 R7
p1 m4 m1 m2 m3 m5 p2 p3 p4
R8
p5 p6 m6 p7 m7
135
120
130
R-Baum: Einfügen von p8 :
R9
90
R10
p7
R5R4
80
R8
m1
70
m6
p8
60
m2
R1
m7
50
R2
R6
40
m4
30
m3
R3
p2
m5
20
R7
p3
p1
p4
p6
p5
10
0
0
10
20
30
40
50
60
70
80
90
100
110
120
R-Baum
R5 R6 R9
R1 R4
R2 R3 R7
p1 m4 m1 m2 m3 m5 p2 p3 p4
R8 R10
p5 p6 m7 p8 m6 p7
136
130
R-Baum: Einfügen von m8 :
R9
90
R10
p7
R5R4
80
R8
m1
70
m6
p8
60
m2
R1
m7
50
R2
R6
R7
40
m8
m4
30
m3
R3
p2
m5
p3
p1
20
p4
p6
p5
10
0
0
10
20
30
40
50
60
70
80
90
100
110
120
R-Baum
R5 R6 R9
R1 R4
R2 R3 R7
p1 m4 m1 m2 m3 m5 p2 p3 p4
R8 R10
p5 p6 m8 m7 p8 m6 p7
137
130
R-Baum: Einfügen von p9 :
R9
90
R10
p7
R5 R4
80
R8
m1
70
p9
60
m6
p8
m2
R1
m7
50
R2
R6
R7
40
m8
m4
30
m3
R3
p2
m5
p6
p3
p1
20
p5
p4
10
0
0
10
20
30
40
50
60
70
80
90
100
110
120
130
R-Baum
R5 R6 R9
R1 R4
R2 R3 R7
p1 m4 m1 m2 p9 m3 m5 p2 p3 p4
R8 R10
p5 p6 m8 m7 p8 m6 p7
138
R-Baum: Einfügen von m9 :
R9
R8
90
R5 R4
80
R10
p7
m9
m1
70
p9
60
m6
p8
m2
R1
m7
50
R2
R6
R7
40
m8
m4
30
m3
R3
p2
m5
p3
p1
20
p4
p6
p5
10
0
0
10
20
30
40
50
60
70
80
90
100
110
120
130
R-Baum
R5 R6 R9
R1 R4
R2 R3 R7
p1 m4 m1 m2 p9 m3 m5 p2 p3 p4
R8 R10
p5 p6 m8 m7 p8 m9 m6 p7
139
R-Baum: Einfügen von p10 :
R9
R8
90
R4 R5
80
70
m1
60
m2
p10 R1
R10
p7
m9
R11
p9
m6
p8
m7
50
R2
R6
R7
40
m8
m4
30
m3
R3
p2
m5
p3
p1
20
p4
p6
p5
10
0
0
10
20
30
40
50
60
70
80
90
100
110
120
130
R-Baum
R5 R6 R9
R1 R4 R11
p1 m4 m1 m2 p10
R2 R3 R7
p9 m3 m5 p2 p3 p4
R8 R10
p5 p6 m8 m7 p8 m9 m6 p7
140
R-Baum: Einfügen von m10 :
R9
R8
90
R4 R5
80
R10
p7
m9
R11
m10
70
m1
60
m2
p10 R1
p9
m6
p8
m7
50
R2
R6
R7
40
m8
m4
30
m3
R3
p2
m5
p3
p1
20
p4
p6
p5
10
0
0
10
20
30
40
50
60
70
80
90
100
110
120
130
R-Baum
R5 R6 R9
R1 R4 R11
p1 m4 m1 m2 p10
R2 R3 R7
p9 m10 m3 m5 p2 p3 p4
R8 R10
p5 p6 m8 m7 p8 m9 m6 p7
141
Relationales DBS
• oder Relationales System
• beruht auf relationalem Modell
– Datenrepräsentation durch Tabellen
– Datenintegrität (atomare Zellen)
– Datenmanipulation (select, project, join)
142
Operatoren
select : extrahiert spezifische Zeilen aus einer Tabelle
und generiert daraus eine neue Tabelle.
project : extrahiert spezifische Spalten aus einer Tabelle
und generiert daraus eine neue Tabelle.
join : verbindet zwei Tabellen auf der Basis von gleichen
Werten in gemeinsamen Spalten.
143
Beispiel
Tabelle ABTEILUNG :
ABTNR
A1
A2
A3
ABTNAME BUDGET
Marketing
10M
Entwicklung
12M
Forschung
5M
Tabelle MITARBEITER :
MNR
M1
M2
M3
M4
MNAME
Ibsen
Rostand
Wilde
Canetti
144
ABTNR GEHALT
A1
80K
A1
84K
A2
60K
A2
70K
Beispiel restrict
Operation:
select ABTEILUNG where BUDGET > 6M
Resultat:
ABTNR ABTNAME BUDGET
A1
Marketing
10M
A2
Entwicklung
12M
145
Beispiel project
Operation:
project ABTEILUNG over ABTNR, BUDGET
Resultat:
ABTNR BUDGET
A1
10M
A2
12M
A3
5M
146
Beispiel join
Operation:
join ABTEILUNG and MITARBEITER
over ABTNR
Resultat:
ABTNR
A1
A1
A2
A2
ABTNAME BUDGET MNR
Marketing
10M M1
Marketing
10M M2
Entwicklung
12M M3
Entwicklung
12M M4
147
MNAME GEHALT
Ibsen
80K
Rostand
84K
Wilde
60K
Canetti
70K
Bemerkungen
• Abgeschlossenheit (closure)
• Mengenoperationen
• Tabellen sind die logische (logical), besser konzeptuelle (conceptual) Struktur, nicht unbedingt
die physikalische Struktur. Tabellen repräsentieren eine
Abstraktion der physikalischen Speicherstruktur.
148
Bemerkungen
• Der ganze Informationsgehalt einer relationalen DB
wird nur in einer Art dargestellt, nämlich explizit als
Datenwerte. Es gibt keine Zeiger auf andere Tabellen.
• Alle Datenwerte sind atomar (atomic, scalar).
Keine Gruppen von Werten (repeating group).
ABTNR
A1
A1
A2
A2
MNR
M1
M2
M3
M4
ABTNR MNR
A1
M1, M2
A2
M3, M4
149
Bemerkungen
• Spezifische Integritätsregeln
und relationale Integritätsregeln
– Hat eine Tabelle einen Primärschlüssel (primary key), dann müssen die Datenwerte der entsprechenden Spalte eindeutig (unique) sein.
– Hat eine Tabelle einen Fremdschlüssel (foreign
key), dann dürfen dort nur Datenwerte stehen, die
auch im Primärschlüssel einer Tabelle stehen.
150
Bemerkungen
• Terminologie: Relation ist der mathematische Begriff für Tabelle. Relationale Systeme basieren auf dem relationalen Datenmodell, das eine abstrakte Theorie ist, die auf Mengenlehre und
Prädikatenlogik aufbaut.
Prinzipien des relationalen Modells von E. F. Codd 1969-70.
Das relationale Modell verwendet nicht den Begriff Datensatz
(record), sondern den Begriff Tupel (tuple).
Wir verwenden hier die Begriffe Tabelle, Zeile, Spalte synonym zu den Theoriebegriffen Relation, Tupel, Attribut.
• Das relationale Modell ist eine Theorie. Ein DBS muss nicht unbedingt alle Aspekte der Theorie abdecken. Es gibt auf dem Markt
kein DBS, das das relationale Modell vollständig abdeckt.
151
Optimierung
• Mit SQL definiert man das ”Was” (nicht-prozedural),
nicht das ”Wie”.
• Höheres Abstraktionsniveau als gängige Sprachen.
• Optimierer (optimizer),
eine DBMS-Komponente, die für das automatische
Navigieren (automatic navigation system)
verantwortlich ist, kümmert sich um das ”Wie”.
152
Katalog
Tabelle TABLES :
TABNAME
COLCOUNT ROWCOUNT . . .
ABTEILUNG
3
3 ...
MITARBEITER
4
4 ...
...
...
... ...
TABLES
...
... ...
...
...
... ...
153
Katalog
Tabelle COLUMNS :
TABNAME
ABTEILUNG
ABTEILUNG
ABTEILUNG
MITARBEITER
MITARBEITER
MITARBEITER
MITARBEITER
...
TABLES
...
COLNAME
ABTNR
ABTNAME
BUDGET
MNR
MNAME
ABTNR
GEHALT
...
TABNAME
...
...
...
...
...
...
...
...
...
...
...
...
154
Basistabellen und Views
• Basistabelle (base table): nicht abgeleitet, hat Namen, existiert ”wirklich”, d.h. ist Modell für real existierende Daten.
• View: abgeleitet (derived table) von anderen Tabellen, virtuelle (virtual) Tabelle, Änderungen wirken sich auf die Basistabellen aus.
155
SQL
CREATE TABLE ABTEILUNG
(
ABTNR CHAR (2),
ABTNAME CHAR (20),
BUDGET
INT,
PRIMARY KEY (ABTNR)
);
156
SQL
CREATE TABLE MITARBEITER
(
MNR
CHAR (2),
MNAME CHAR (20),
ABTNR CHAR (2),
GEHALT
INT,
PRIMARY KEY (MNR),
FOREIGN KEY (ABTNR) REFERENCES ABTEILUNG
);
157
SQL
INSERT INTO ABTEILUNG (ABTNR, ABTNAME, BUDGET)
VALUES (’A1’, ’Marketing’, 10M);
158
SQL
Operation:
restrict ABTEILUNG where BUDGET > 6M
SQL:
SELECT ABTNR, ABTNAME, BUDGET
FROM ABTEILUNG
WHERE BUDGET > 6M;
159
SQL
Operation:
project ABTEILUNG over ABTNR, BUDGET
SQL:
SELECT ABTNR, BUDGET
FROM ABTEILUNG;
160
SQL
Operation:
join ABTEILUNG and MITARBEITER
over ABTNR
SQL:
SELECT ABTEILUNG.ABTNR, ABTNAME, BUDGET, MNR,
MNAME, GEHALT
FROM ABTEILUNG, MITARBEITER
WHERE ABTEILUNG.ABTNR = MITARBEITER.ABTNR;
161
SQL
CREATE TABLE ZWISCHENERGEBNIS
(
MNR
CHAR (2)
);
162
SQL
INSERT INTO ZWISCHENERGEBNIS (MNR)
SELECT
MNR
FROM MITARBEITER
WHERE ABTNR = ’A1’;
163
SQL
UPDATE MITARBEITER
SET
GEHALT = GEHALT * 1.1
WHERE ABTNR = ’A1’;
164
SQL
DELETE
FROM MITARBEITER
WHERE ABTNR = ’A2’;
165
SQL
CREATE VIEW VIELVERDIENER AS
SELECT
MNR, MNAME, GEHALT
FROM MITARBEITER
WHERE GEHALT > 66K;
166
Regeln von Codd
1) The Information Rule: Alle Daten, die in einer Datenbank gespeichert werden, sind auf dieselbe Art dargestellt, nämlich durch
Werte in Tabellen.
2) Guaranteed Access Rule: Jeder gespeicherte Wert muss über
Tabellennname, Spaltenname und Wert des Primärschlüssels zugreifbar sein, wenn der zugreifende Anwender über hinreichende
Zugriffsrechte verfügt.
3) Systematic Treatment of Null Values: Nullwerte müssen
datentypunabhängig zur Darstellung fehlender Werte unterstützt
werden. Systematisch drückt hierbei aus, dass Nullwerte unabhängig von demjenigen Datentyp, für den sie auftreten, gleich
behandelt werden.
167
Regeln von Codd
4) Dynamic On-line Catalog Based on the Relational Model:
Der Katalog soll auch in Form von Tabellen vorliegen. Der Katalog beschreibt die Struktur und die Integritätsregeln der in der
Datenbank hinterlegten Tabellen.
5) Comprehensive Data Sublanguage Rule: Für das DBMS
muss mindestens eine Sprache existieren, durch die sich die Tabellenstruktur definieren lässt.
6) View Updating Rule: Alle theoretisch aktualisierbaren Sichten müssen durch Aktualisierung der zugrundeliegenden Basistabellen änderbar sein.
168
Regeln von Codd
7) High-level Insert, Update, and Delete: Innerhalb einer
Operation können beliebig viele Tupel bearbeitet werden, d.h. die
Operationen werden grundsätzlich mengenorientiert ausgeführt.
8) Physical Data Independence: Änderungen an der internen
Ebene dürfen keine Auswirkungen – außer Performanz – auf die
Anwendungsprogramme haben.
9) Logical Data Independence: Änderungen des konzeptuellen
Schemas dürfen keine Auswirkungen auf die Anwendungsprogramme haben, es sei denn, dass sie direkt von der Änderung betroffen
sind. (Wegen ihnen sind die Änderungen vorgenommen worden.)
169
Regeln von Codd
10) Integrity Independence: Alle Integritätsregeln müssen ausschließlich durch die Sprache des DBMS definierbar sein. Ferner
gilt:
• Kein Attribut, das Teil eines Primärschlüssels ist, darf NULL
sein.
• Ein Fremdschlüsselattribut muss als Wert des zugehörigen
Primärschlüssels existieren.
11) Distribution Independence: Die Anfragesprache muss so
ausgelegt sein, dass Zugriffe auf lokal gehaltene Daten identisch
denen auf verteilt gespeicherte Daten formuliert werden können.
170
Regeln von Codd
12) Nonsubversion Rule: Definiert ein DBMS neben der HighLevel Zugriffssprache auch eine Schnittstelle mit niedrigerem Abstraktionsniveau, dann darf durch diese keinesfalls eine Umgehung
der definierten Integritätsregeln möglich sein.
Rule 0: (Zusammenfassung aller zwölf Regeln) Alle Operationen für
Zugriff, Verwaltung und Wartung der Daten dürfen nur mittels
relationaler Fähigkeiten abgewickelt werden.
171
Beispiel SP
Tabelle S:
SNR
S1
S2
S3
S4
S5
SNAME STATUS CITY
Smith
20 London
Jones
10 Paris
Blake
30 Paris
Clark
20 London
Adams
30 Athens
172
Beispiel SP
Tabelle P:
PNR
P1
P2
P3
P4
P5
P6
PNAME
Nut
Bolt
Screw
Screw
Cam
Cog
COLOR WEIGHT CITY
Red
12 London
Green
17 Paris
Blue
17 Rome
Red
14 London
Blue
12 Paris
Red
19 London
173
Beispiel SP
Tabelle SP:
SNR
S1
S1
S1
S1
S1
S1
S2
S2
S3
S4
S4
S4
PNR QTY
P1
300
P2
200
P3
400
P4
200
P5
100
P6
100
P1
300
P2
400
P2
200
P2
200
P4
300
P5
400
174
Relationales Modell
Deutsch
Englisch
Relation
relation
Tupel
tuple
Kardinalität
cardinality
Attribut
attribute
Grad
degree
Primärschlüssel primary key
Wertebereich
domain
Skalar
scalar
Begriffe
Informeller Begriff Erklärung
Deutsch Englisch
Tabelle table
Zeile
row
Anzahl der Tupel
Spalte
column
arity
Anzahl der Attribute
Eindeutiger Identifikator
Typ
type
Werte, die ein Attribut annehmen kann
Wert
value
Wert eines Attributs in einem Tupel
175
Wertebereiche
• Skalar (scalar):
kleinste semantische Dateneinheit, atomar,
keine interne Struktur bezüglich relationalem Modell
• Wertebereich (domain):
benannte Menge von Skalaren, Typ
• Definition: elementweise, konzeptionell
(create domain, destroy domain)
176
Wertebereiche
Datenmanipulation: Attribut kann nur Werte aus dem Wertebereich haben (Datenintegrität).
Vergleiche (domain-constrained comparisons):
SELECT PNAME, QTY
| SELECT PNAME, QTY
FROM P, SP
|
FROM P, SP
WHERE P.PNR = SP.PNR;
|
WHERE P.WEIGHT = SP.QTY;
Anfragen, die auf dem Wertebereich basieren: ”Welche
Tabellen in der DB enthalten irgendwelche Information über
Lieferanten?”
177
Definition Relation
1.) Der Kopf (heading) besteht aus einer Menge von
Attributen,
genauer hAttributname : Wertebereichnamei–Paaren,
{hA1 : D1i, hA2 : D2i · · · hAm : Dmi}
sodaß zu jedem Attribut Aj genau ein Wertebereich
Dj (j = 1, 2 · · · m) gehört. Die Attributnamen sind alle
verschieden.
178
Definition Relation
2.) Der Körper (body) besteht aus einer Menge von
Tupeln {t1, t2 · · · tn}. Jedes Tuple ti besteht aus einer
Menge von hAttributname : Attributwerti–Paaren
ti = {hA1 : vi1i, hA2 : vi2i · · · hAm : vimi}
(i = 1, 2 · · · n), wobei n die Anzahl der Tupel in der
Menge ist. Die vij sind Werte aus dem Wertebereich
Dj .
179
Tabelle
• Zeilen sind geordnet. Duplikate möglich.
• Spalten haben Reihenfolge.
• In einer Tabelle wird nicht deutlich, daß die Werte aus
Wertebereichen stammen.
180
Relationen
• Wert (value)
(Codd: time-varying relations)
• Grad (degree oder auch arity)
181
Eigenschaften von Relationen
• Es gibt keine Tupelduplikate.
• Die Tupel sind nicht geordnet.
• Die Attribute sind nicht geordnet.
• Alle Attributwerte sind atomar.
Keine repeating groups.
Eine Relation ist normalisiert (normalized) oder
ist in der ersten Normalform (first normal
form).
182
Relationsarten
Benannte (named) Relation ist eine Relation, die unter einem
Namen ansprechbar ist (Basisrelation, View, Schnappschuß).
Basisrelation (base relation) ist eine benannte, autonome (autonomous), d.h. nicht abgeleitete Relation.
Abgeleitete (derived) Relation wird durch andere Relationen
in relationalen Ausdrücken definiert.
Ausdrückbare (expressible) Relation ist eine Relation, die
mit relationalen Mitteln erhalten werden kann. Die ausdrückbaren
Relationen sind alle Relationen, Basis– und abgeleitete Relationen.
View ist eine benannte, abgeleitet Relation. Views sind virtuell, da
sie im DBS nur durch ihre Definition repräsentiert werden.
183
Relationsarten
Schnappschuß (snapshot) ist eine benannte abgeleitete Relation, die aber nicht virtuell ist, sondern die – konzeptionell – wenigsten durch ihre eigenen Daten repräsentiert wird.
Anfrageresultat (query result) ist eine nicht benannte abgeleitete Relation, die das Resultat einer Anfrage an die DB ist.
Zwischenresultat (intermediate result) ist das Resultat eines
relationalen Ausdrucks, der in einen anderen Ausdruck geschachtelt ist.
Gespeicherte (stored) Relation ist eine Relation, die direkt und
effizient physikalisch gespeichert ist.
184
Prädikate
Wahrheitswertfunktion (predicate)
von vier Argumenten:
Ein Lieferant mit einer bestimmten Lieferantennummer (SNR) hat den spezifizierten Namen (SNAME)
und den spezifizierten Statuswert (STATUS) und sitzt
in der angegebenen Stadt (CITY). Ferner haben verschiedene Lieferanten nicht dieselbe Lieferantennummer.
185
Prädikate
• Eine Relation enthält zu jeder Zeit nur solche Tupel, die die entsprechenden Propositionen zu der Zeit wahr machen.
• Kriterium für die Akzeptanz einer Manipulation (criterion for update acceptability)
• Das DBMS kennt das Prädikat von vornherein nicht und es ist i.a.
nicht möglich, dem DBMS das Prädikat vollständig zu beschreiben.
• Aber man kann dem DBMS Regeln geben, die eine vernünftige
Annäherung an das Prädikat sind (Integritätsregeln, integrity rules).
186
Integrität
• DB-Konfiguration, die die Wirklichkeit darstellt.
• Bestimmte DB-Konfigurationen machen keinen Sinn.
• Integritätsregeln (integrity rules):
Randbedingungen der realen Welt.
187
Schlüssel
• DB-spezifische Integritätsregeln
• allgemeine Integritätsregeln
(haben mit Schlüsseln zu tun)
188
Schlüssel
Definition: Ein (Kandidaten-)Schlüssel (candidate key) K ist auf einer Relation R definiert als eine
Teilmenge des Kopfes (der Menge der Attribute) von R
mit den Eigenschaften:
1. Eindeutigkeit (uniqueness): Es gibt keine zwei
unterschiedliche Tupel von R mit demselben Wert für
K.
2. Nicht-Reduzierbarkeit (irreducibility, auch
minimality): Keine echte Teilmenge von K hat die
Eigenschaft der Eindeutigkeit.
189
Bemerkungen
1. Jede Relation hat mindestens einen Schlüssel.
2. Reduzierbare Schlüssel: Superschlüssel (superkey).
3. Schlüsseleigenschaft gilt für alle möglichen Werte einer Relation.
4. ”all-key”-Relation
5. Fälle mit mehr als einem Schlüssel sind selten.
6. zusammengesetzte (composite) und einfache (simple)
Schlüssel
7. Forderung der Nicht-Reduzierbarkeit ist notwendig.
8. ”Schlüssel” und ”eindeutiger Index”
9. Schlüssel: Zentraler Mechanismus zur Adressierung von Tupeln
190
Primärschlüssel
• Genau ein Schlüssel kann als Primärschlüssel
(primary key) definiert werden.
• Alternativschlüssel (alternate key) oder
Sekundärschlüssel (secondary key)
• Der Primärschlüssel wird in den Tabellen unterstrichen.
191
Fremdschlüssel
Definition: K sei ein Schlüssel der Basisrelation R1. R2
sei eine (nicht notwendigerweise von R1 verschiedene)
Basisrelation. FK ist ein Fremdschlüssel in der Basisrelation R2, wenn für alle aktuellen Werte von R1 und
R2 gilt:
1. FK ist eine Teilmenge des Kopfes (der Attribute) von
R2.
2. Jeder Wert von FK in R2 ist identisch mit einem
Wert von K in R1.
Fremdschlüssel werden in den Tabellen überstrichen.
192
Bemerkungen
1. Jeder Wert eines Fremdschlüssels in R2 muß zu einem Schlüsselwert in R1 passen.
2. Der Fremdschlüssel ist nur dann zusammengesetzt, wenn auch der
dazugehörige Schlüssel zusammengesetzt ist.
3. Die Wertebereiche der Attribute müssen im Fremdschlüssel und
im dazugehörigen Schlüssel gleich sein.
4. Die Namen der Attribute können im Fremdschlüssel und im dazugehörigen Schlüssel unterschiedlich sein.
5. Ein Fremdschlüssel von R2 muß nicht die Komponente eines
Schlüssels von R2 sein.
193
Bemerkungen
6. Begriffe: Ein Fremdschlüssel steht für eine Referenz (reference) auf das Tupel mit dem passenden Schlüssel (referenziertes Tupel, referenced tuple, target tuple) (Problem
der refenziellen Integrität, referential integrity problem). Es muß die referenzielle Einschränkung (referential constraint) beachtet werden. Der Fremdschlüssel ist in der
referenzierenden (referencing), der dazugehörige Schlüssel
in der referenzierten (referenced, target) Relation definiert.
7. Referenzielle Diagramme (referential diagrams):
R1 ← R2
S ← SP → P
194
Bemerkungen
8. referenzielle Pfade (referential path)
9. Es gibt Relationen, die sich selbst referenzieren (self-referencing).
Sie sind ein Spezialfall von referenziellen Zyklen (referential cycle):
R1 → R2 → R3 → R4 → R1
10. Schlüssel – Fremdschlüsselbeziehungen sind die wichtigsten Beziehungen zwischen Relationen in einer DB. Es gibt aber auch andere
Beziehungen: Z.B. kommt das Attribut CITY in S und P vor. Man
kann nun fragen, ob ein Lieferant und ein Teil in derselben Stadt
sind. CITY ist kein Fremdschlüssel. Diese Art von Fragen kann
aber nur eindeutig beantwortet werden, wenn CITY ein Schlüssel
wird.
195
Fremdschlüsselregeln
1. beschränkt (restricted): Die Manipulation wird auf die Fälle
ohne Referenz beschränkt und in anderen Fällen zurückgewiesen.
2. kaskadiert (cascades): Die Manipulation kaskadiert insofern,
als sie alle referenzierenden Einträge auch manipuliert.
3. Eintrag einer NULL oder eines Defaultwerts in den Fremdschlüssel.
Das ist nur vernünftig, wenn der Fremdschlüssel nicht Komponente
eines Schlüssels ist.
4. Frage den Benutzer, was zu tun ist.
5. Rufe eine installationsabhängige Prozedur auf.
196
Nicht definierte Werte (NULL)
• (missing value or missing information)
• keine Defaultwerte
Regeln:
1. Nach Möglichkeit sollten anstatt von NULLs
Defaultwerte verwendet werden.
2. Ein Schlüssel darf keine NULLs enthalten.
3. Ein Fremdschlüssel darf nur NULLs enthalten,
wenn er nicht Komponente eines Schlüssels ist.
197
Relationale Algebra
• Traditionelle Mengenoperationen:
Vereinigung (union), Schnitt (intersect),
Differenz (minus) und kartesisches Produkt (times),
die alle etwas auf Relationen angepasst wurden.
• Spezifisch relationale Operationen:
select, project, join und devideby.
• extend und summarize
• Zuweisungs- und Update-Operationen
und relationale Vergleiche
198
rename
Die Operationen werden so definiert, dass die resultierenden Relationen vernünftige Köpfe haben. Dazu mag es notwendig sein, Attribute umzubenennen. Wir führen daher
den Operator rename ein mit der Syntax:
Relation rename alterAttributname as neuerAttributname
βneu←altR
199
Traditionelle Mengenoperationen
• Vereinigung, Schnitt, Differenz, kartesisches Produkt
• Operanden typkompatibel
• Vereinigung, Schnitt und kartesisches Produkt sind in der relationalen Algebra assoziativ und kommutativ, die Differenz nicht.
Relation R1 :
Relation R2 :
SNR SNAME STATUS CITY
S1
Smith
20 London
S4
Clark
20 London
SNR SNAME STATUS CITY
S1
Smith
20 London
S2
Jones
10 Paris
200
Vereinigung
ist mengentheoretische Vereinigung
von zwei typkompatiblen Tupelmengen.
R1 union R2:
SNR
S1
S4
S2
SNAME STATUS CITY
Smith
20 London
Clark
20 London
Jones
10 Paris
• outer union
201
R1 minus R2:
R2 minus R1:
Differenz
SNR SNAME STATUS CITY
S4 Clark
20 London
SNR SNAME STATUS CITY
S2 Jones
10 Paris
202
R1 intersect R2:
Schnitt
SNR SNAME STATUS CITY
S1 Smith
20 London
• R1 intersect R2 ≡ R1 minus (R1 minus R2)
Der Schnitt ist keine primitive Operation.
203
Kartesisches Produkt
• Mathematik: Geordnete Paare (r1, r2),
wobei r1 ∈ R1 und r2 ∈ R2 gilt.
• Relationale Algebra:
Mengentheoretische Vereinigung von Tupelpaaren.
• Kopf: Vereinigung der beiden Input-Köpfe
204
Kartesisches Produkt
Relation R3 :
R3 times R4 :
SNR
S1
S2
SNR
S1
S1
S1
S2
S2
S2
Relation R4 :
PNR
P1
P2
P3
PNR
P1
P2
P3
P1
P2
P3
205
Selektion, Restriktion
A where X Θ Y
R where ϕ1 and ϕ2 ≡ (R where ϕ1) intersect (R where ϕ2)
R where ϕ1 or ϕ2 ≡ (R where ϕ1) union (R where ϕ2)
R where not ϕ
≡ R minus (R where ϕ)
206
Selektion, Restriktion
S where CITY = ’London’:
SNR SNAME STATUS CITY
S1
Smith
20 London
S4
Clark
20 London
P where WEIGHT < 14:
PNR PNAME COLOR WEIGHT CITY
P1
Nut
Red
12 London
P5
Cam
Blue
12 Paris
SP where SNR = ’S1’ and PNR = ’P1’:
207
SNR PNR QTY
S1
P1
300
Projektion
R[A, B . . . C]
oder
R[{A, B . . . C}]
ist eine Relation mit dem Kopf {A, B . . . C} und einem
Körper, der aus allen Tupeln der Form {A:a, B:b . . . C:c}
besteht, wobei es in R ein Tupel gibt mit A-Wert a, BWert b . . . C-Wert c.
Duplikate werden eliminiert.
Identische Projektion: R
Nilprojektion (nullary projection): R [ ]
208
Projektion
S [CITY]:
CITY
London
Paris
Athens
P [COLOR, CITY]:
COLOR
Red
Green
Blue
Blue
CITY
London
Paris
Rome
Paris
(S where CITY = ’Paris’) [SNR]:
SNR
S2
S3
209
(Natürlicher) Join
R1 sei Relation mit Kopf { A1 . . . Am, B1 . . . Bn } = { A, B }
R2 sei Relation mit Kopf { C1 . . . Cp, B1 . . . Bn } = { C, B }
Der natürliche Join von R1 und R2
R1 natural join R2
ist eine Relation mit dem Kopf { A, B, C } und einem Körper, der
aus allen Tupeln { A:a, B:b, C:c } besteht, wobei es ein Tupel in R1
gibt mit A-Wert a und B-Wert b und ein Tupel in R2 gibt mit C-Wert
c und B-Wert b.
Der natürliche Join ist assoziativ und kommutativ.
210
Beispiel
S natural join P:
SNR
S1
S1
S1
S2
S2
S3
S3
S4
S4
S4
SNAME STATUS CITY
PNR
Smith
20 London P1
Smith
20 London P4
Smith
20 London P6
Jones
10 Paris
P2
Jones
10 Paris
P5
Blake
30 Paris
P2
Blake
30 Paris
P5
Clark
20 London P1
Clark
20 London P4
Clark
20 London P6
211
PNAME
Nut
Screw
Cog
Bolt
Cam
Bolt
Cam
Nut
Screw
Cog
COLOR WEIGHT
Red
12
Red
14
Red
19
Green
17
Blue
12
Green
17
Blue
12
Red
12
Red
14
Red
19
Bemerkungen
• Schlüssel müssen nicht beteiligt sein.
• Wenn A und B keine gemeinsamen Attribute haben,
dann ist der Join äquivalent zum kartesischen Produkt.
• A natural join B ≡
( (A times (B rename Y as W)) where Y = W)[X, Y, Z]
Der Join ist daher keine primitive Operation.
S natural join P ≡
( (S times (P rename CITY as PCITY)) where CITY = PCITY )
[ SNR, SNAME, STATUS, CITY, PNR, PNAME, COLOR, WEIGHT
]
212
Θ-Join
Sei R1 eine Relation mit dem Attribut A und R2 eine
Relation mit dem Attribut B, dann ist der Θ-Join der
Relation R1 auf Attribut A mit Relation R2 auf Attribut
B
(R1 times R2) where AΘB
eine Relation mit dem Kopf des kartesischen Produkts
und allen Tupeln des kartesischen Produkts, die die
Bedingung AΘB erfüllen.
Der equijoin ist ein Θ-Join,
wobei Θ das Gleichheitszeichen ist.
213
Outer Join
R1 left outer join R2 ≡
Nur Tupel des linken Partners R1 werden erhalten.
R1 right outer join R2 ≡
Nur Tupel des rechten Partners R2 werden erhalten.
R1 full outer join R2 ≡
Tupel des linken und rechten Partners werden erhalten.
214
Division
R1 sei Relation mit Kopf { A1 . . . Am, B1 . . . Bn }
= { A, B }
R1 sei Relation mit Kopf { B1 . . . Bn } = { B }
Die Division von R1 und R2
R1 divideby R2
ist eine Relation mit dem Kopf { A } und einem Körper,
der aus allen Tupeln { A:a } besteht, wobei für jedes Tupel
{ B:b } in R2 mit B-Wert b es ein Tupel { A:a, B:b } in
R1 gibt mit A-Wert a und B-Wert b.
215
Bemerkungen
• ( R1 times R2 ) divideby R2 ergibt wieder R1.
• ( R1 divideby R2 ) times R2 ⊆ R1
• Die Division ist nützlich bei Anfragen, die das Wort
”alle” enthalten.
• Die Division kann durch andere Operationen ausgedrückt werden.
216
V:
SNR PNR
S1 P1
S1 P2
S1 P3
S1 P4
S2 P2
S3 P1
S3 P2
S3 P4
S4 P3
S4 P4
V divideby W:
?
?
?
?
?
?
W:
PNR
P2
P4
...
...
...
...
...
...
217
Anfrage-Beispiele
1. Namen der Lieferanten, die Teil P2 liefern.
2. Namen der Lieferanten, die mindestens ein rotes
Teil liefern.
3. Namen der Lieferanten, die alle Teile liefern.
4. Lieferantennummern der Lieferanten, die mindestens alle die Teile liefern, die Lieferant S2 liefert.
5. Alle Paare von Lieferantennummern der Lieferanten, die in derselben Stadt sitzen.
6. Namen der Lieferanten, die Teil P2 nicht liefern.
218
Sinn der Algebra
• Formulierung von relationalen Ausdrücken zur Definition von Daten.
• Optimierer verwendet Transformationsregeln, um Ausdrücke in effizientere Ausdrücke umzuwandeln. (Mach
Selektion oder Projektion vor einem Join.)
• Relationale Algebra dient als Maßstab für die
Mächtigkeit von Anfragesprachen (Relationale
Vollständigkeit, relational completeness).
219
extend
• Das extend bietet zeilenweise (horizontale)
Berechnungen an.
Berechnungsausdrucks
(scalar computational expression)
• extend term add scalar-expression as attribute
extend R add Ausdruck as C
extend P add (WEIGHT * 454) as GMWT
• Multiples extend:
extend P add City as PCITY, (WEIGHT * 454) as GMWT
220
Beispiele
1. extend S add ’Lieferant’ as BEZEICHNUNG
2. extend (P join SP) add (WEIGHT * QTY) as SHIPWT
3. (extend S add CITY as SCITY)
[SNR, SNAME, STATUS, SCITY]
4. extend S add count ( (SP rename SNR as X)
where X = SNR)
as NP
221
summarize
• summarize ermöglicht spaltenweise oder vertikale
Berechnungen.
• summarize term by (attribute-commalist)
add aggregate-expression as attribute
summarize R by (A1, A2 . . . An) add Ausdruck as C
summarize SP by (PNR) add sum (QTY) as TOTQTY
• Die Kardinalität des Resultats ist gleich der
Kardinalität der Projektion von R über A1, A2 . . . An.
• Multiples summarize:
(summarize SP by (PNR) add sum (QTY) as TOTQTY,
avg (QTY) as AVGQTY
222
Beispiel
summarize (P join SP) by (CITY) add count as NSP
ergibt :
CITY NSP
London
5
Paris
6
Rome
1
223
Beispiele
1. summarize SP by ( ) add sum (QTY) as GRANDTOTAL
2. summarize SP by (SNR) add count as NP
3. Alle Städte mit mehr als fünf roten Teilen:
( (summarize (P where COLOR = ’Red’)
by (CITY) add count as N) where N > 5)[CITY]
Alle Städte mit fünf oder weniger roten Teilen:
( (summarize (P where COLOR = ’Red’)
by (CITY) add count as N) where N ≤ 5)[CITY]
P[CITY] minus
( (summarize (P where COLOR = ’Red’)
by (CITY) add count as N) where N > 5)[CITY]
224
Update-Operationen
Zuweisungsoperator (assignment operator)
target := source;
S := S union { {
hSNR:’S6’i,
hSNAME:’Baker’i,
hSTATUS:50i,
hCITY:’Madrid’i } };
SP := SP minus { {
hSNR:’S1’i,
hPNR:’P1’i,
hQTY:300i } };
225
Update-Operationen
insert-Statement :
insert source into target;
insert (S where CITY = ’London’) into TEMP;
update-Statement :
update target assignment-commalist;
mit attribute := scalar-expression
update P where COLOR = ’Red’, CITY = ’Paris’;
delete-Statement :
delete target;
delete S where STATUS < 20;
226
Symbolische Notation
β[SCITY←CITY] S
βSCITY←CITY S
σ[CITY=’London’] S
σCITY=’London’ S
π[COLOR, CITY] P
πCOLOR, CITY P
227
Symbolische Notation
S1P
SP 1PNR P
SP 1QTY>WEIGHT P
SP 1natural P
γsum(QTY);SNR SP
ωQTY SP
228
Algebra – Kalkül
”Lieferantennummern und Städte von Lieferanten, die Teil
P2 liefern”
Algebra: ”Bilde den natürlichen Join von S und SP über
SNR. Schränke dann das Resultat auf die Tupel für Teil
P2 ein. Projeziere schließlich auf SNR und CITY.”
Kalkül: ”Bestimme SNR und CITY für diejenigen Lieferanten, für die es eine Lieferung in SP gibt mit dem gleichen SNR-Wert und dem PNR-Wert von P2.”
229
Relationales Kalkül
• Prädikatenkalkül oder der Prädikatenlogik
=⇒ ALPHA =⇒ QUEL =⇒ SQL
• Tupelvariable
(tuple variable, range variable)
”Die Tupelvariable T durchläuft (ranges over) die
Relation R.”
• Tupelkalkül (tuple calculus)
• QUEL:
RANGE OF SX IS S
RETRIEVE (SX.SNR) WHERE SX.CITY = "London"
230
Probleme mit Redundanz
• Eine Aktualisierung der Daten muß an mehreren Stellen
durchgeführt werden (duplication effort).
• Speicherplatz wird verschwendet.
• Immer lauert die Gefahr der Inkonsistenz der Daten.
Aber möglicherweise controlled redundancy.
231
Vermeide Redundanz!
• ”one fact in one place”
• William Kent: Each attribute must represent
a fact about the key, the whole key, and
nothing but the key.
• und wir ergänzen: And the key should not tell
us anything about the object.
• Der ”key” repräsentiert eindeutig eine Entität,
ein Objekt der realen Welt.
232
Normalformen
• 1NF, 2NF, 3NF, BCNF, 4NF und 5NF
• Hierarchie
• Ziel eines DB-Entwurfs ist 5NF.
• Eine Relation =⇒ Menge von Relationen.
233
Verlustfreie Zerlegung
(nonloss/lossless decomposition)
Tabelle SSTC :
SNR STATUS CITY
S3
30 Paris
S5
30 Athens
Zerlegung a):
Tabelle SST :
Tabelle SC :
SNR STATUS
SNR CITY
S3
30
S3 Paris
S5
30
S5 Athens
234
Nicht verlustfreie Zerlegung
Tabelle SSTC :
SNR STATUS CITY
S3
30 Paris
S5
30 Athens
Zerlegung b):
Tab. SST :
Tab. STC :
SNR STATUS
STATUS CITY
S3
30
30 Paris
S5
30
30 Athens
235
Funktionale Abhängigkeit
Definition: Sei R eine Relation mit X und Y Teilmengen
der Attribute von R. Y heißt funktional abhängig von
X
symbolisch:
X −→ Y
(”X bestimmt Y funktional”) genau dann, wenn für
alle Werte von R zu jedem X-Wert in R genau ein Y Wert in R gehört. Eine solche Beziehung heißt
funktionale Abhängigkeit oder kurz FD.
X heißt Determinante oder linke Seite,
Y Abhängige oder rechte Seite einer FD.
236
SNR
S1
S1
S2
S2
S3
S4
S4
S4
CITY
London
London
Paris
Paris
Paris
London
London
London
Tabelle SCPQ
PNR QTY
P1
100
P2
100
P1
200
P2
200
P2
300
P2
400
P4
400
P5
400
237
{SNR, PNR}
{SNR, PNR}
{SNR, PNR}
{SNR, PNR}
{SNR, PNR}
{SNR}
{QTY}
{SNR}
{CITY}
{PNR}
Beispiele für FDs und keine FDs
−→
−→
−→
−→
−→
−→
−→
−→
−→
−→
{QTY}
{CITY}
{CITY, QTY}
{SNR}
{SNR, PNR, CITY, QTY}
{QTY}
{SNR}
{CITY}
{SNR}
{QTY}
238
Inferenzregeln von Armstrong
Seien A, B und C Attributteilmengen einer Relation R.
Dann gilt:
1. Reflexivität: B ⊆ A =⇒ A −→ B (triviale FD)
2. Augmentation: A −→ B =⇒ A ∪ C −→ B ∪ C
3. Transitivität: A → B
∧
B→C
239
=⇒ A −→ C
Inferenzregeln von Armstrong
1. Selbstbestimmung: A −→ A (triviale FD)
2. Zerlegung: A −→ B ∪ C =⇒ A → B
3. Vereinigung: A → B
∧
∧
A→C
A → C =⇒ A → B ∪ C
4. Komposition: A → B ∧ C → D
=⇒ A ∪ C → B ∪ D
5. Allgemeines Unifikationstheorem (general
unification theorem):
A → B ∧ C → D =⇒ A ∪ (C − B) → B ∪ D
240
Irreduzierbare FDs
Definition: Eine FD: A −→ B in R heißt irreduzierbar genau dann, wenn kein Attribut der linken Seite
(d.h. von A) entfernt werden kann. Man sagt auch B
ist voll oder irreduzierbar funktional von A abhängig.
241
Theorem von Heath
Theorem von Heath: Sei R eine Relation auf den Attributen A ∪ B ∪ C, wobei A, B und C Mengen von
Attributen mit jeweils leerem Durchschnitt sind.
Wenn R die FD: A −→ B erfüllt, dann ist R gleich
dem Join ihrer Projektionen auf A ∪ B und A ∪ C.
242
Erste Normalform
Definition 1NF: Eine Relation R liegt in der ersten
Normalform vor (”ist in 1NF”) genau dann, wenn
jeder Attributwert atomar ist. (Der zugrundeliegende
Wertebereich enthält nur skalare Werte.)
243
PNR
CITY
P1, P4, P6 London
P2, P5
Paris
P3
Rome
Erste Normalform
−→
PNR
P1
P4
P6
P2
P5
P3
244
CITY
London
London
London
Paris
Paris
Rome
Zweite Normalform
Definition 2NF: Eine Relation R liegt in der zweiten
Normalform vor (”ist in 2NF”) genau dann, wenn
sie in 1NF ist und jedes Nichtschlüsselattribut voll (irreduzierbar) funktional abhängig von einem Schlüssel
ist. Irreduzierbare FDs, bei denen die linke Seite ein
Schlüssel ist, heißen 2NF-konform.
oder anders: Eine Relation R liegt nicht in der zweiten Normalform vor, wenn es ein Nichtschlüsselattribut gibt, das nur von einem Teil des Schlüssels
abhängig ist.
245
Nicht in zweiter Normalform:
SNR STATUS PNR QTY
S1
20 P1
300
S1
20 P2
200
S1
20 P3
400
S1
20 P4
200
S1
20 P5
100
S1
20 P6
100
S2
10 P1
300
S2
10 P2
400
S3
30 P2
200
S4
20 P2
200
S4
20 P4
300
S4
20 P5
400
246
Normalisierung 1NF → 2NF
Jede Relation R, die nicht in 2NF ist, wird folgendermaßen
zerlegt:
Die Relation R[A, B, C] (auf den schnittfreien Attributmengen A, B, C) habe die irreduzierbare FD: A −→ B,
wobei A echter Teil eines Schlüssels ist und B ein Nichtschlüsselattribut ist, dann wird durch die Zerlegung
R1 = R[A, C]
R2 = R[A, B]
die FD: A −→ B 2NF-konform. A ist Fremdschlüssel in
R1.
247
Dritte Normalform
Definition 3NF: Eine Relation R liegt in der dritten
Normalform vor (”ist in 3NF”) genau dann, wenn
sie in 1NF ist und jedes Nichtschlüsselattribut nur
(oder nicht transitiv (Date)) voll (irreduzierbar) funktional abhängig von einem Schlüssel ist. Funktionale
Abhängigkeiten, die der dritten Normalform widersprechen, sind nicht 3NF-konform.
3NF schließt 2NF ein.
248
Tabelle SCST:
Nicht in dritter Normalform:
SNR CITY STATUS
S1 London 30
S2
Paris 10
S3
Paris 10
S4 London 30
S5
Athens 30
249
Normalisierung 1NF → 3NF
Jede Relation R, die nicht in 3NF ist, wird folgendermaßen
zerlegt:
Die Relation R[A, B, C] (auf den schnittfreien Attributmengen A, B, C) habe die irreduzierbare FD: A −→ B,
wobei A nicht ein Schlüssel ist und B ein Nichtschlüsselattribut (auch nicht partiell) ist, dann wird durch die Zerlegung
R1 = R[A, C]
R2 = R[A, B]
die FD: A −→ B 3NF-konform. A ist Fremdschlüssel in
R1.
250
Zerlegung von SCST
SNR
S1
S2
S3
S4
S5
CITY
London
Paris
Paris
London
Athens
und
CITY STATUS
London
30
Paris
10
Athens
30
251
Unabhängige Projektionen
Zerlegung
R1 = SCST[SNR, CITY]
und
R2’ = SCST[SNR, STATUS]
?
252
Unabhängige Projektionen
Definition Rissanen: R1 und R2 sind unabhängige
Projektionen von R genau dann, wenn
1. jede FD in R eine logische Konsequenz der FDs in
R1 und R2 ist und
2. die gemeinsamen Attribute von R1 und R2 einen
Schlüssel für mindestens eine der beiden Projektionen bilden.
253
Boyce-Codd-Normalform
Definition BCNF: Eine Relation ist in BCNF genau
dann, wenn sie in 1NF ist und jede irreduzierbare Determinante (linke Seite) einer nicht trivialen FD ein
Schlüssel ist (bzw wenn jede nicht-triviale irreduzierbare FD einen Schlüssel als Determinante hat).
254
Bem. zu Boyce-Codd-Normalform
1. Weniger formal heißt das: Linke Seiten von FDs müssen
Schlüssel sein.
2. Wir sagen auch: Eine Relation ist in BCNF genau dann,
wenn jede irreduzierbare FD in R BCNF-konform ist,
d.h. entweder trivial ist, oder die Determinante ein
Schlüssel ist.
3. BCNF ist stärker als 3NF. D.h. wenn eine Relation in
BCNF ist, ist sie auch in 3NF.
4. BCNF ist konzeptionell einfacher als 3NF.
255
FD:
2NF
3NF
BCNF
3NF
BCNF
BCNF
Normalformen
A
−→
echter Schlüsselteil −→
B
Nichtschlüssel
Nichtschlüssel oder −→
Nichtschlüssel
echter Schlüsselteil
Nichtschlüssel oder −→ beliebige Attributmenge
echter Schlüsselteil
256
Nicht in Boyce-Codd-Normalform:
SSP:
SNR
S1
S1
S1
S1
S1
S1
S2
S2
S3
S4
S4
S4
SNAME
Smith
Smith
Smith
Smith
Smith
Smith
Jones
Jones
Blake
Clark
Clark
Clark
PNR QTY
P1
300
P2
200
P3
400
P4
200
P5
100
P6
100
P1
300
P2
400
P2
200
P2
200
P4
300
P5
400
257
Normalisierung auf BCNF
Jede Relation R, die nicht in BCNF ist, wird in 1NF
überführt und dann eventuell folgendermaßen zerlegt:
Die Relation R[A, B, C] (auf den schnittfreien Attributmengen A, B, C) habe die nicht BCNF-konforme FD:
A −→ B, dann wird durch die Zerlegung
R1 = R[A, C]
R2 = R[A, B]
die FD: A −→ B BCNF-konform. A ist Fremdschlüssel
in R1.
258
Beispiel zu BCNF
ST
Smith
Smith
Jones
Jones
FC
Math
Phys
Math
Phys
DZ
White
Green
White
Brown
ST
Smith
Smith
Jones
Jones
DZ
White
Green
White
Brown
DZ
White
Green
Brown
259
FC
Math
Phys
Phys
Beispiel zu 4NF
STPLKO:
MG
FK
UK
Smith Informatik, Grundstudium,
Mathematik Hauptstudium
Jones Informatik,
Software,
Grundstudium,
Hauptstudium,
Multimedia
Clark Elektronik, Grundstudium,
Physik,
Technik
Mathematik
260
STPLKO:
MG
Smith
Smith
Smith
Smith
Jones
Jones
Jones
Jones
Jones
Jones
Clark
Clark
Clark
Clark
Clark
Clark
FK
Informatik
Informatik
Mathematik
Mathematik
Informatik
Informatik
Informatik
Software
Software
Software
Elektronik
Elektronik
Physik
Physik
Mathematik
Mathematik
Beispiel zu 4NF
UK
Grundstudium
Hauptstudium
Grundstudium
Hauptstudium
Grundstudium
Hauptstudium
Multimedia
Grundstudium
Hauptstudium
Multimedia
Grundstudium
Technik
Grundstudium
Technik
Grundstudium
Technik
261
Beispiel zu 4NF
MGFK:
und MGUK:
MG
Smith
Smith
Jones
Jones
Clark
Clark
Clark
FK
Informatik
Mathematik
Informatik
Software
Elektronik
Physik
Mathematik
MG
Smith
Smith
Jones
Jones
Jones
Clark
Clark
262
UK
Grundstudium
Hauptstudium
Grundstudium
Hauptstudium
Multimedia
Grundstudium
Technik
Beispiel MVD
{MG} →
→{FK}
{MG} →
→{UK}
263
Multivalued Dependency
Definition MVD: Seien R eine Relation und A, B und C beliebige Teilmengen der Menge der Attribute von R. Dann hängt B
mehrwertig von A ab
A→
→B
genau dann, wenn die Menge der B-Werte, die zu einem gegebenen
Paar (A-Wert, C-Wert) in R gehören, nur vom A-Wert abhängt
und nicht vom C-Wert abhängt, d.h. gleich der Menge der BWerte ist, für die es ein Tupel mit dem vorgegebenen A-Wert gibt,
und ungleich der Menge der B-Werte ist, für die es ein Tupel mit
dem vorgegebenen C-Wert gibt.
Bemerkung: Eine FD ist eine MVD, bei der die Menge der B-Werte
genau ein Element hat.
264
Vierte Normalform
Definition 4NF: Eine Relation R ist in 4NF genau
dann, wenn aus der Existenz einer (nicht trivialen)
MVD: A→
→B in R folgt, daß alle Attribute von R auch
funktional von A abhängig sind.
Bemerkung: In 4NF sind die einzigen nicht trivialen
Abhängigkeiten FDs mit Schlüsseln als Determinanten.
265
mehr zu MVDs
Satz: R sei eine Relation auf den schnittfreien Attributmengen A, B und C, dann folgt aus der MVD
A→
→B die MVD A →
→C. Man schreibt auch:
A→
→B|C
Theorem von Fagin: R sei eine Relation auf den
schnittfreien Attributmengen A, B und C. Analog zum
Heath’schen Theorem ist dann R gleich dem Join seiner
Projektionen auf A ∪ B und A ∪ C genau dann, wenn
in R die MVD: A →
→B | C erfüllt ist.
266
mehr zu MVDs
Rissanen gilt analog: R sei eine Relation auf den
schnittfreien Attributmengen A, B und C und erfüllen
die MVDs
A→
→B und B →
→C (und dann auch A →
→C).
Dann ist die Zerlegung in R[A ∪ B] und R[B ∪ C]
der Zerlegung in R[A ∪ B] und R[A ∪ C] vorzuziehen
(Erhaltung der Abhängigkeiten).
267
STPLKO:
MG
Smith
Smith
Jones
Smith
Beispiel zu JD
FK
Informatik
Mathematik
Informatik
Informatik
UK
Grundstudium
Hauptstudium
Hauptstudium
Hauptstudium
268
Beispiel zu JD
MGUK:
MGFK:
MG
Smith
Smith
Jones
FK
Informatik
Mathematik
Informatik
MG
Smith
Smith
Jones
FKUK:
FK
Informatik
Mathematik
Informatik
UK
Grundstudium
Hauptstudium
Hauptstudium
269
UK
Grundstudium
Hauptstudium
Hauptstudium
Beispiel zu JD
MGFK join MGUK ergibt:
MG
Smith
Smith
Smith
Smith
Jones
FK
Informatik
Informatik
Mathematik
Mathematik
Informatik
UK
Grundstudium
Hauptstudium
Grundstudium ←
Hauptstudium
Hauptstudium
270
SPJ:
SNR
S1
S1
S2
S1
PNR
P1
P2
P1
P1
Abstraktes Beispiel zu JD
JNR
J2
J1
J1
J1
Die drei Projektionen heißen SP, SJ und PJ.
271
SPJ ist
Wenn
und
und
dann
Abstraktes Beispiel zu JD
gleich dem Join von SP,SJ und PJ bedeutet:
das Paar
(s1, p1)
in SP erscheint
das Paar
(s1, j1)
in SJ erscheint
das Paar
(p1, j1)
in PJ erscheint,
muß das Tripel (s1, p1, j1) in SPJ erscheinen.
272
Abtraktes Beispiel zu JD
SPJ ist gleich dem Join von SP,SJ und PJ bedeutet:
Wenn (s1, p1, j2), (s1, p2, j1) und (s2, p1, j1)
in SPJ erscheinen,
dann erscheint auch (s1, p1, j1) in SPJ.
273
Join-Abhängigkeit JD
Definition JD: Seien R eine Relation und A, B · · · Z
beliebige Teilmengen der Attribute von R. Dann erfüllt
R eine Join-Abhängigkeit
JD*(A, B · · · Z)
genau dann, wenn R gleich dem Join seiner Projektionen auf A, B · · · Z ist.
274
Theorem von Fagin
R sei eine Relation auf den schnittfreien Attributmengen
A, B und C. R erfüllt die JD*(A, B, C) genau dann, wenn
in R die MVD: A →
→B | C erfüllt ist.
275
Fünfte Normalform
Definition 5NF oder PJ/NF: Eine Relation R ist in
5NF genau dann, wenn jede JD in R von Schlüsseln in
R impliziert wird.
276
Bemerkung zu 5NF
1. Eine JD*(A, B · · · Z) wird von Schlüsseln impliziert,
wenn jede Attributmenge A, B · · · Z einen Schlüssel
enthält. Diese Implikation folgt aus dem Theorem von
Heath. Eine allgemeinere Formulierung der Implikation
führt hier zu weit.
2. 5NF ist immer erreichbar.
3. Eine Relation in 5NF ist automatisch in 4NF, weil
MVDs spezielle JDs sind.
4. SPJ ist nicht in 5NF, aber die Zerlegungen SP, SJ, PJ
sind es.
277
Zusammenfassung Normalisierung
1. Bilde Projektionen der Original-Relation, bis alle FDs
eliminiert sind, deren Determinante nicht ein Schlüssel
ist. Alle Relationen sind dann in BCNF.
2. Bilde weiter Projektionen, bis alle MVDs eliminiert
sind, die nicht FDs sind. Alle Relationen sind dann
in 4NF.
3. Bilde weiter Projektionen, bis alle JDs eliminiert sind,
die nicht von Schlüsseln impliziert werden. Alle Relationen sind dann in 5NF.
278
Domain-Key Normalform (Fagin)
Definition DK/NF: Eine Relation R ist in DK/NF genau dann,
wenn jede Abhängigkeit in R eine logische Konsequenz einer Wertebereichsabhängigkeit (domain constraint) oder einer
Schlüsselabhängigkeit (key constraint) in R ist.
• domain constraint oder attribute constraint: Jeder
Wert eines Attributs muß aus einem bestimmten Wertebereich
(Domäne) genommen werden.
• key constraint: Gewisse Attributkombinationen bilden
einen Schlüssel.
279
Zusammenfassung
Eine Relation R ist in Normalform, wenn sie in
1NF ist und wenn es kein Tupel in R gibt, das
von anderen Tupeln in R logisch abhängt.
280
SQL als DDL – Datendefinition
CREATE DOMAIN
ALTER DOMAIN
DROP DOMAIN
CREATE TABLE
ALTER TABLE
DROP TABLE
281
Wertebereich – domain
• Syntaktische Kürzel
• Keine Verschachtelung
• Keine Typenbindung
• Keine wertebereichsspezifischen Operationen
• Keine Vererbung
282
Wertebereich: Syntax
CREATE DOMAIN domain data-type
[default-definition]
[domain-constraint-definition-list]
283
Datentypen
CHARACTER [VARYING] (n)
BIT [VARYING] (n)
INTEGER
SMALLINT
NUMERIC (p, q) : NUMERIC(2,1) bedeutet der Bereich -9.9 bis +9.9 .
DECIMAL (p, q) : DECIMAL(2,1) bedeutet mindestens der Bereich -9.9 bis
+9.9 , kann aber auch z.B. von -99.9 bis +99.9 gehen.
FLOAT (p)
DATE
TIME
TIMESTAMP
INTERVAL
284
Wertebereich: Syntax
CREATE DOMAIN domain data-type
[default-definition]
[domain-constraint-definition-list]
CREATE DOMAIN COLOR CHAR (6)
DEFAULT ’???’
CONSTRAINT VALID_COLORS
CHECK (VALUE IN
(’Red’, ’Yellow’, ’Blue’, ’Green’, ’???’));
285
Basistabelle: Syntax
CREATE TABLE base-table (base-table-element-commalist);
base-table-element
::= column-definition | base-table-constraint-definition
column-definition
::= column representation [DEFAULT default]
286
Basistabelle: Syntax
base-table-constraint-definition
::= [CONSTRAINT constraint-name]
UNIQUE (column-commalist)
| PRIMARY KEY (column-commalist)
| FOREIGN KEY (column-commalist)
REFERENCES base-table [(column-commalist)]
[ON DELETE NO ACTION | CASCADE | SET DEFAULT
| SET NULL]
[ON UPDATE NO ACTION | CASCADE | SET DEFAULT
| SET NULL]
| CHECK (conditional-expression)
287
Basistabelle: Beispiel
CREATE TABLE SP
(
SNR SNR NOT NULL, PNR PNR NOT NULL, QTY QTY NOT NULL,
PRIMARY KEY (SNR, PNR),
FOREIGN KEY (SNR)
REFERENCES S
ON DELETE CASCADE
ON UPDATE CASCADE,
FOREIGN KEY (PNR)
REFERENCES P
ON DELETE CASCADE
ON UPDATE CASCADE,
CHECK (QTY > 0 AND QTY < 5001)
);
288
Informationsschema
SCHEMATA
TABLES
COLUMNS
COLUMN_PRIVILEGES
DOMAIN_CONSTRAINTS
REFERENTIAL_CONSTRAINTS
KEY_COLUMN_USAGE
VIEW_TABLE_USAGE
CONSTRAINT_TABLE_USAGE
CONSTRAINT_COLUMN_USAGE
CONSTRAINT_DOMAIN_USAGE
DOMAINS
VIEWS
TABLE_PRIVILEGES
USAGE_PRIVILEGES
TABLE_CONSTRAINTS
CHECK_CONSTRAINTS
ASSERTIONS
VIEW_COLUMN_USAGE
289
INSERT
INSERT
INTO P (PNR, PNAME, COLOR, WEIGHT, CITY)
VALUES (’P8’, ’Sprocket’, ’Pink’, 14, ’Nice’);
INSERT
INTO TEMP (SNR, CITY)
SELECT
S.SNR, S.CITY
FROM S
WHERE S.STATUS > 15;
290
UPDATE
UPDATE
SET
P
P.COLOR = ’Yellow’,
P.WEIGHT = P.WEIGHT + 5
WHERE P.CITY = ’Paris’;
UPDATE
SET
P
CITY =
(SELECT S.CITY
FROM S
WHERE S.SNR = ’S5’
)
WHERE P.COLOR = ’Red’;
291
DELETE
DELETE
FROM SP
WHERE ’London’ =
(SELECT S.CITY
FROM S
WHERE S.SNR = SP.SNR
);
DELETE FROM SP;
292
SELECT
Farbe und Stadt für Teile nicht in Paris und Gewicht
größer als 14:
SELECT
P.COLOR, P.CITY
FROM P
WHERE
P.CITY <> ’Paris’
AND
P.WEIGHT > 14;
293
SELECT
Farbe und Stadt für Teile nicht in Paris und Gewicht größer als
14:
SELECT DISTINCT
P.COLOR, P.CITY
FROM P
WHERE
P.CITY <> ’Paris’
AND
P.WEIGHT > 14;
SELECT DISTINCT
COLOR, CITY
FROM P
WHERE
CITY <> ’Paris’
AND
WEIGHT > 14;
294
SELECT mit Ordnung
SELECT
P.COLOR, P.CITY
FROM P
WHERE
P.CITY <> ’Paris’
AND
P.WEIGHT > 14
ORDER BY CITY DESC;
295
SELECT
Alle Teilenummern und Gewichte in Gramm:
SELECT
P.PNR, P.WEIGHT * 454 AS GMWT
FROM P;
296
SELECT Join (explizit)
Alle Kombinationen von Lieferanten und Teilen, die
in einer Stadt sind:
SELECT DISTINCT
S.SNR, S.SNAME, S.STATUS, S.CITY,
P.PNR, P.PNAME, P.COLOR, P.WEIGHT
FROM S, P
WHERE S.CITY = P.CITY;
297
SELECT Join
Alle Kombinationen von Lieferanten und Teilen, die
in einer Stadt sind:
SELECT DISTINCT
S.SNR, S.SNAME, S.STATUS, S.CITY,
P.PNR, P.PNAME, P.COLOR, P.WEIGHT
FROM S JOIN P ON (S.CITY = P.CITY);
oder
SELECT DISTINCT * FROM S JOIN P USING (CITY);
oder
SELECT DISTINCT * FROM S NATURAL JOIN P;
298
SELECT
Alle Teilenummern und Gewichte in Gramm:
SELECT
P.PNR, P.WEIGHT * 454 AS GMWT
FROM P;
299
SELECT Join
Alle Städtepaare, wobei der Lieferant in der ersten Stadt das Teil
in der zweiten Stadt liefert:
SELECT DISTINCT
S.CITY AS SCITY, P.CITY AS PCITY
FROM S JOIN SP USING (SNR) JOIN P USING (PNR);
oder
SELECT DISTINCT
S.CITY AS SCITY, P.CITY AS PCITY
FROM S NATURAL JOIN SP JOIN P USING (PNR);
nicht aber
SELECT DISTINCT
S.CITY AS SCITY, P.CITY AS PCITY
FROM S NATURAL JOIN SP NATURAL JOIN P;
300
SELECT
Alle Paare von Lieferantennummern, die in derselben
Stadt sitzen:
SELECT ERST.SNR AS ERSTER, ZWEIT.SNR AS ZWEITER
FROM S AS ERST, S AS ZWEIT
WHERE ERST.CITY = ZWEIT.CITY
AND ERST.SNR < ZWEIT.SNR;
301
SELECT
FROM
SELECT Aggregat-Funktionen
COUNT(*) AS N
S;
SELECT
MAX(SP.QTY) AS MAXQTY, MIN(SP.QTY) AS MINQTY
FROM SP
WHERE SP.PNR = ’P2’;
302
SELECT Aggregat-Funktionen
SELECT
AVG(TOTQTY) AS AVGTOTQTY
FROM
(SELECT SP.PNR, SUM(QTY) AS TOTQTY
FROM SP
GROUP BY SP.PNR
);
303
SELECT Aggregat-Funktionen
SELECT
SP.PNR, SUM(SP.QTY) AS TOTQTY
FROM SP
GROUP BY SP.PNR;
SELECT
FROM
P.PNR,
(SELECT SUM(QTY)
FROM SP
WHERE SP.PNR = P.PNR
) AS TOTQTY
P;
304
SELECT HAVING
Teilnummern von Teilen, die von mehr als einem
Lieferanten geliefert werden:
SELECT
SP.PNR
FROM SP
GROUP BY SP.PNR
HAVING
COUNT(SP.SNR) > 1;
305
SELECT subquery
SELECT DISTINCT
S.SNAME
FROM S
WHERE S.SNR IN
(SELECT SP.SNR
FROM SP
WHERE SP.PNR = ’P2’
);
306
SELECT
Nummern der Lieferanten mit Status kleiner als dem
Maximalstatus in der Tabelle S :
SELECT
S.SNR
FROM S
WHERE S.STATUS <
(SELECT MAX (S.STATUS)
FROM S
);
307
SELECT EXISTS
Namen der Lieferanten, die Teil P2 liefern:
SELECT DISTINCT
S.SNAME
FROM S
WHERE EXISTS
(SELECT *
FROM SP
WHERE SP.SNR = S.SNR
AND
SP.PNR = ’P2’
);
308
SELECT EXISTS
Namen der Lieferanten, die nicht Teil P2 liefern:
SELECT DISTINCT
S.SNAME
FROM S
WHERE NOT EXISTS
(SELECT *
FROM SP
WHERE SP.SNR = S.SNR
AND
SP.PNR = ’P2’
);
309
SELECT EXISTS
Namen von Lieferanten, die alle Teile liefern:
SELECT DISTINCT
S.SNAME
FROM S
WHERE NOT EXISTS
(SELECT *
FROM P
WHERE NOT EXISTS
(SELECT *
FROM SP
WHERE SP.SNR = S.SNR
AND
SP.PNR = P.PNR
)
);
310
SELECT EXISTS
Namen von Lieferanten, die alle Teile liefern:
SELECT DISTINCT
S.SNAME
FROM S
WHERE (SELECT COUNT(SP.PNR)
FROM SP
WHERE SP.SNR = S.SNR
)
=
(SELECT COUNT(P.PNR)
FROM P
);
311
Vergleich von Tabellen geht nicht.
Namen von Lieferanten, die alle Teile liefern:
SELECT DISTINCT
S.SNAME
FROM S
WHERE (SELECT SP.PNR
FROM SP
WHERE SP.SNR = S.SNR
)
=
-- Fehler !!!
(SELECT P.PNR
FROM P
);
312
UNION
Nummern von Teilen, die entweder weniger als 16
Pfund wiegen oder von Lieferant S2 geliefert werden:
SELECT
P.PNR
FROM P
WHERE P.WEIGHT < 16
UNION
SELECT
SP.PNR
FROM SP
WHERE SP.SNR = ’S2’;
313
Komplizierte Beispiel-Anfrage
Bestimme Teilenummer, Gewicht in Gramm, Farbe
und maximale Liefermenge für alle Teile, die rot oder
blau sind und wovon mindestens insgesamt 350 geliefert wurden, wobei Lieferungen mit weniger als 201
Teilen unberücksichtigt bleiben.
314
Komplizierte Beispiel-Anfrage
SELECT
P.PNR,
’Grammgewicht = ’ AS TEXT1,
P.WEIGHT * 454 AS GMWT,
P.COLOR,
’Max Liefermenge = ’ AS TEXT2,
MAX(SP.QTY) AS MQY
FROM P, SP
WHERE P.PNR = SP.PNR
AND (P.COLOR = ’Red’ OR P.COLOR = ’Blue’)
AND SP.QTY > 200
GROUP BY P.PNR, P.WEIGHT, P.COLOR
HAVING
SUM(SP.QTY) >= 350;
315
Resultat:
PNR
P1
P5
P3
Komplizierte Beispiel-Anfrage
TEXT1
GMWT COLOR
Grammgewicht =
5448 Red
Grammgewicht =
5448 Blue
Grammgewicht =
7718 Blue
316
TEXT2
MQ
Max Liefermenge =
3
Max Liefermenge =
4
Max Liefermenge =
4
MATCH-Bedingung
Anfrage: Bestimme alle Lieferanten, die genau eine
Lieferung haben.
SELECT
S.*
FROM S
WHERE S.SNR MATCH UNIQUE (SELECT SP.SNR FROM SP);
317
All-or-Any-Bedingung
Anfrage: Bestimme die Namen der Teile, deren Gewicht größer ist als das Gewicht jeden blauen Teils.
SELECT DISTINCT
PX.PNAME
FROM P AS PX
WHERE PX.WEIGHT > ALL ( SELECT
PY.WEIGHT
FROM P AS PY
WHERE PY.COLOR = ’Blue’ );
318
Embedded SQL
• Absetzen von SQL-Statements
• Verwendung von Host-Sprachen-Variablen
• Verarbeitung von Anfrageresultaten
• Fehlerbehandlung
319
EXEC SQL
char
char
int
EXEC SQL
C++ Programmfragment
BEGIN DECLARE SECTION;
SQLSTATE[5];
pnr[2];
weight;
END DECLARE SECTION;
320
C++ Programmfragment
pnr[0] = ’P’;
pnr[1] = ’2’;
EXEC SQL SELECT
INTO
FROM
WHERE
P.WEIGHT
:weight
P
P.PNR = :pnr;
321
C++ Programmfragment
if (SQLSTATE[0] == ’0’
&& SQLSTATE[1] == ’0’
&& SQLSTATE[2] == ’0’
&& SQLSTATE[3] == ’0’
&& SQLSTATE[4] == ’0’)
{
cout << "SELECT hat funktioniert.\n";
}
else
{
cout << "SELECT hat nicht funktioniert.\n";
}
322
EXEC
EXEC
EXEC
EXEC
SQL
SQL
SQL
SQL
WHENEVER-Deklaration
WHENEVER
WHENEVER
WHENEVER
WHENEVER
NOT FOUND
NOT FOUND
SQLERROR
SQLERROR
323
GO TO label;
CONTINUE;
GO TO label;
CONTINUE;
Operationen ohne Kursor
EXEC SQL SELECT
INTO
FROM
WHERE
STATUS, CITY
:rank, :city
S
SNR = :snr;
324
Operationen ohne Kursor
EXEC SQL INSERT
INTO P (PNR, PNAME, COLOR, WEIGHT, CITY)
VALUES (:pnr, :pname, DEFAULT, :weight, DEFAULT);
325
Operationen ohne Kursor
EXEC SQL UPDATE
S
SET
STATUS = STATUS + :mehr
WHERE CITY = ’London’;
326
Operationen ohne Kursor
EXEC SQL DELETE
FROM SP
WHERE :city = (SELECT
CITY
FROM S
WHERE S.SNR = SP.SNR);
327
Operationen mit Kursor
EXEC SQL DECLARE X CURSOR FOR
SELECT
S.SNR, S.SNAME, S.STATUS
FROM S
WHERE S.CITY = :city;
EXEC SQL OPEN X;
while (SQLSTATE[1] != ’2’)
{
EXEC SQL FETCH X INTO :snr, :sname, :status;
cout << "SNR = " << snr << " SNAME = " << sname;
cout << " STATUS = " << status << endl;
}
EXEC SQL CLOSE X;
328
Deklaration eines Kursors
EXEC SQL DECLARE cursor [SCROLL] CURSOR FOR
table-expression
[ ORDER BY order-item-commalist ]
329
Operationen mit Kursor
EXEC SQL OPEN cursor;
EXEC SQL CLOSE cursor;
330
Operationen mit Kursor
EXEC SQL FETCH [[row-selector] FROM] cursor INTO
host-variable-commalist;
row-selector
NEXT
| PRIOR
| FIRST
| LAST
| ABSOLUTE n
| RELATIVE n
331
Operationen mit Kursor
Die UPDATE- und DELETE-Statements können sich auch auf
einen Kursor beziehen (CURRENT OF cursor). Zum Beispiel:
EXEC SQL UPDATE
S
SET
STATUS = STATUS + :mehr
WHERE CURRENT OF X;
332
SELECT mit IN
SELECT DISTINCT
S.SNAME
FROM S
WHERE S.SNR IN
(SELECT SP.SNR
FROM SP
WHERE SP.PNR IN
(SELECT P.PNR
FROM P
WHERE P.COLOR = ’Red’
)
);
333
JOIN-Ausdrücke
AA AB XY
a
aa
x
a
ab
xy
A:
a NULL x
b NULL y
c
cc NULL
BB AB XY
b
bb
x
b
ab
xy
B:
b NULL x
b NULL
z
c
bb NULL
334
A CROSS JOIN B
Resultat ist das kartesische Produkt.
335
A NATURAL [INNER] JOIN B
AA BB AB XY
a b ab xy
336
A [INNER] JOIN B USING (XY)
AA AB
a
aa
a
aa
a NULL
a NULL
a
ab
BB AB XY
b bb
x
b NULL x
b bb
x
b NULL x
b
ab xy
337
A [INNER] JOIN B ON (A.XY = B.XY)
AA AB XY BB AB XY
a
aa
x b bb
x
a
aa
x b NULL x
a NULL x b bb
x
a NULL x b NULL x
a
ab xy b
ab xy
338
A UNION JOIN B
AA
a
a
a
b
c
NULL
NULL
NULL
NULL
NULL
AB
aa
ab
NULL
NULL
cc
NULL
NULL
NULL
NULL
NULL
XY
x
xy
x
y
NULL
NULL
NULL
NULL
NULL
NULL
BB
NULL
NULL
NULL
NULL
NULL
b
b
b
b
c
339
AB
NULL
NULL
NULL
NULL
NULL
bb
ab
NULL
NULL
bb
XY
NULL
NULL
NULL
NULL
NULL
x
xy
x
z
NULL
A LEFT [OUTER] JOIN B USING (XY)
AA
a
a
a
a
a
b
c
AB BB AB XY
aa
b
bb
x
aa
b NULL x
NULL b
bb
x
NULL b NULL x
ab
b
ab
xy
NULL NULL NULL y
cc NULL NULL NULL
340
A RIGHT [OUTER] JOIN B USING (XY)
AA
a
a
a
a
a
NULL
NULL
AB
aa
aa
NULL
NULL
ab
NULL
NULL
BB
b
b
b
b
b
b
c
AB XY
bb
x
NULL x
bb
x
NULL x
ab
xy
NULL z
bb NULL
341
A FULL [OUTER] JOIN B USING (XY)
AA
a
a
a
a
a
b
c
NULL
NULL
AB BB AB XY
aa
b
bb
x
aa
b NULL x
NULL b
bb
x
NULL b NULL x
ab
b
ab
xy
NULL NULL NULL y
cc NULL NULL NULL
NULL b NULL z
NULL c
bb NULL
342
SQLJ
• #sql { <SQL-Befehl> };
• #sql { DELETE * FROM SP };
343
SQLJ-Präprozessor
$ sqlj dateiname.sqlj
344
SQLJ Beispiel
#sql iterator ResultatTyp (String, int, Date);
ResultatTyp resultat;
#sql resultat = { SELECT LNAME, QTY, DATUM
FROM LIEFERUNG
WHERE QTY > :qtySchranke };
while (!resultat.endFetch ())
{
#sql { FETCH :resultat INTO :lname, :qty, :datum };
// --}
345
Vergleich SQLJ – JDBC
• Vorteil von SQLJ: Verwendung von SQL, als ob es zur
Sprache gehört.
• Nachteil von SQLJ: Zwingend zu verwendender Präprozessor, der schlecht lesbaren Java-Code erzeugt.
• Vorteil von SQLJ: Typ- und Syntax-Überprüfung zur
Übersetzungszeit mit Option -online . Bei JDBC treten SQL-Syntax-Fehler erst zur Laufzeit auf.
• Nachteil von SQLJ: SQL-Befehle können nicht zur
Laufzeit erzeugt werden.
• SQLJ und JDBC können gemischt werden.
346
Relationaler Entwurf
Reguläre Entität
=⇒
Basis-Tabelle mit Primärschlüssel
347
Beispiel
Tabelle Abteilung mit Primärschlüssel PK:
PK . . .
... ...
Tabelle Angestellter mit Primärschlüssel PK und Attribut
ANR:
PK ANR . . .
... ...
...
Tabelle Projekt mit Primärschlüssel PK:
PK . . .
... ...
348
Beispiel
Tabelle Lieferant mit Primärschlüssel PK:
PK . . .
... ...
Tabelle Teil mit Primärschlüssel PK:
PK . . .
... ...
349
Relationaler Entwurf
Many-to-Many-Beziehung
=⇒
Basis-Tabelle
• teilnehmende Entitäten werden Fremdschlüssel
• Primärschlüssel:
– Kombination der Fremdschlüssel oder
– Einführung eines neuen Primärschlüssels
350
Beispiel
Tabelle ArbeitetAn mit Primärschlüssel (FKAngestellter,
FKProjekt):
FKAngestellter FKProjekt . . .
...
...
...
Tabelle LiefertTeil mit Primärschlüssel (FKLieferant,
FKTeil):
FKLieferant FKTeil . . .
...
...
...
351
Beispiel
Tabelle LiefertTeilFürProjekt mit
Primärschlüssel (FKLieferant, FKTeil, FKProjekt):
FKLieferant FKTeil FKProjekt . . .
...
...
...
...
Tabelle Struktur mit Primärschlüssel (FKETeil, FKITeil):
FKETeil FKITeil . . .
...
...
...
352
Relationaler Entwurf
One-to-Many-Beziehung und One-to-One-Beziehung
=⇒
• Beziehung zwingend: One-Seite wird als Fremdschlüssel mit eventuellen Attributen der Beziehung in der Tabelle der Many-Seite
aufgenommen.
• Beziehung freigestellt ohne Attribute:
– wie bei ”zwingend”
oder – insbesondere wenn Beziehung selten eingegangen wird –
– eigene Basis-Tabelle
• Beziehung freigestellt mit Attributen: Eigene Basis-Tabelle.
353
Beispiel
Tabelle Angestellter mit Primärschlüssel PK
und Fremdschlüssel FKAbteilung:
PK ANR . . . FKAbteilung
... ...
... ...
Die Beziehung ”Leitet” wird durch den Fremdschlüssel
FKAngestellter in der Tabelle Projekt mit Primärschlüssel
PK ausgedrückt:
PK . . . FKAngestellter
... ... ...
354
Relationaler Entwurf
Dreier- und höherwertige Beziehung
=⇒
Basis-Tabelle wie Many-to-Many-Beziehung
355
Relationaler Entwurf
Schwache Entität
=⇒
Basis-Tabelle, in der die Beziehung zur regulären Entität
durch einen kaskadierenden Fremdschlüssel ausgedrückt
wird.
Primärschlüssel:
• Einführung eines neuen Primärschlüssels oder
• Kombination des Fremdschlüssels mit Attributen
356
Beispiel
Tabelle Angehöriger mit Fremdschlüssel FKAngestellter
und Primärschlüssel (Vorname, FKAngestellter):
Vorname FKAngestellter . . .
...
...
...
357
Relationaler Entwurf
Eigenschaft
=⇒
• normal: Attribut der zugehörigen Tabelle
• zusammengesetzt: Nur Teileigenschaften erscheinen,
oder eigene Tabelle
• mehrwertig: Eigene Tabelle
• abhängig: Darf nur in Views erscheinen.
• viele NULLs: Eigene Tabelle
358
Beispiel
Tabelle Angestellter:
PK ANR VorN MiN NaN Gehalt FKAbteilung
... ...
...
... ... ...
...
Tabelle Adressen:
FKAngestellter Adresse
...
...
359
Relationaler Entwurf
Untertyp
=⇒
• Basis-Tabelle mit demselben Primärschlüssel wie Obertyp
• Primärschlüssel ist auch den Obertyp referenzierender,
kaskadierender Fremdschlüssel.
360
Beispiel
Tabelle Projekt mit Primärschlüssel PK:
PK PName . . .
... ...
...
361
Beispiel
Tabelle Tagesprojekt mit Primärschlüssel PK und Fremdschlüssel PK, Fremdschlüssel referenziert Tabelle Projekt:
PK
Tag . . .
ref. Projekt
...
... ...
362
Beispiel
Tabelle Langzeitprojekt mit Primärschlüssel PK und
Fremdschlüssel PK, Fremdschlüssel referenziert Tabelle
Projekt:
PK
Start Ende . . .
ref. Projekt
...
...
...
...
363
Beispiel
Tabelle Entwicklungsprojekt mit Primärschlüssel PK und
Fremdschlüssel PK, Fremdschlüssel referenziert Tabelle
Langzeitprojekt:
PK
...
ref. Langzeitprojekt
...
...
364
Relationaler Entwurf: Kategorie
1.) Für jede Kategorie wird eine Tabelle angelegt. Die
Tabelle bekommt einen künstlichen Schlüssel (surrogate key), der in jeder Obertyptabelle als Fremdschlüssel
geführt wird. Dieser Fremdschlüssel kann NULL-Werte annehmen.
365
Relationaler Entwurf: Kategorie
2.) Für jede Kategorie wird eine Tabelle angelegt.
Die Schlüssel der Obertypen werden als Fremdschlüssel
geführt, wobei NULL-Werte erlaubt sind. Entweder bildet
die Kombination der Fremdschlüssel den Schlüssel für die
Tabelle der Kategorie, was das DBMS wegen der NULLWerte möglicherweise nicht erlaubt, oder es wird ein künstlicher Schlüssel eingeführt.
366
Relationaler Entwurf: Kategorie
3.) Die sauberste Lösung ist, dass man die Gemeinsamkeiten der Obertypen in eine eigene Tabelle auslagert, von
der alle Obertypen und die Kategorie erben.
367
Many-to-Many mit History
Tabelle Kunde mit Primärschlüssel PK.
Tabelle Lieferant mit Primärschlüssel PK.
Tabelle BestellGeschichte mit zusammengesetztem Schlüssel:
FKKunde FKLieferant KundenNr . . .
...
...
...
...
Tabelle Bestellung mit einem dreifach zusammengesetzten
Schlüssel:
FKKunde FKLieferant LaufendeNr Datum Bestelltext . . .
ref. BestellGeschichte
...
...
...
...
...
...
368
SQL-Statements
CREATE TABLE ABTEILUNG
(
DNR CHAR (6) NOT NULL,
ABTNAME CHAR (12),
PRIMARY KEY (DNR)
);
369
SQL-Statements
CREATE TABLE ANGESTELLTER
(
ANR CHAR (6) NOT NULL,
DNR CHAR (6) NOT NULL,
VORN CHAR (12),
MIN CHAR (12),
NAN CHAR (12),
GEHALT DECIMAL (10, 2),
PRIMARY KEY (ANR),
FOREIGN KEY (DNR)
REFERENCES ABTEILUNG
ON DELETE NO ACTION
ON UPDATE CASCADE,
CHECK (GEHALT > 0.0 AND GEHALT < 1000000.00)
);
370
SQL-Statements
CREATE TABLE ADRESSEN
(
ADNR CHAR (6) NOT NULL,
ANR CHAR (6) NOT NULL,
ADRESSE CHAR VARYING (256),
PRIMARY KEY (ADNR),
FOREIGN KEY (ANR)
REFERENCES ANGESTELLTER
ON DELETE CASCADE
ON UPDATE CASCADE
);
371
SQL-Statements
CREATE TABLE ANGEHOERIGER
(
VORNAME CHAR (12) NOT NULL,
ANR CHAR (6) NOT NULL,
PRIMARY KEY (VORNAME, ANR),
FOREIGN KEY (ANR)
REFERENCES ANGESTELLTER
ON DELETE CASCADE
ON UPDATE CASCADE
);
372
SQL-Statements
CREATE TABLE PROJEKT
(
PNR INTEGER NOT NULL,
PNAME CHAR (20),
ANR CHAR (6) NOT NULL,
PRIMARY KEY (PNR),
FOREIGN KEY (ANR)
REFERENCES ANGESTELLTER
ON DELETE NO ACTION
ON UPDATE CASCADE
);
373
SQL-Statements
CREATE TABLE ARBEITETAN
(
ANR CHAR (6) NOT NULL,
PNR INTEGER NOT NULL,
PRIMARY KEY (ANR, PNR),
FOREIGN KEY (ANR)
REFERENCES ANGESTELLTER
ON DELETE CASCADE
ON UPDATE CASCADE,
FOREIGN KEY (PNR)
REFERENCES PROJEKT
ON DELETE CASCADE
ON UPDATE CASCADE
);
374
SQL-Statements
CREATE TABLE TAGESPROJEKT
(
PNR INTEGER NOT NULL,
TAG DATE,
PRIMARY KEY (PNR),
FOREIGN KEY (PNR)
REFERENCES PROJEKT
ON DELETE CASCADE
ON UPDATE CASCADE
);
375
SQL-Statements
CREATE TABLE LANGZEITPROJEKT
(
PNR INTEGER NOT NULL,
START DATE,
ENDE DATE,
PRIMARY KEY (PNR),
FOREIGN KEY (PNR)
REFERENCES PROJEKT
ON DELETE CASCADE
ON UPDATE CASCADE
);
376
SQL-Statements
CREATE TABLE ENTWICKLUNGSPROJEKT
(
PNR INTEGER NOT NULL,
PRIMARY KEY (PNR),
FOREIGN KEY (PNR)
REFERENCES LANGZEITPROJEKT
ON DELETE CASCADE
ON UPDATE CASCADE
);
377
SQL-Statements
CREATE TABLE LIEFERANT
(
LNR CHAR (6) NOT NULL,
LNAME CHAR (12),
STATUS INTEGER,
STADT CHAR (20),
PRIMARY KEY (LNR)
);
CREATE TABLE TEIL
(
TNR INTEGER NOT NULL,
PRIMARY KEY (TNR)
);
378
SQL-Statements
CREATE TABLE LIEFERTTEILFUERPROJEKT
(
LNR CHAR (6) NOT NULL,
TNR INTEGER NOT NULL,
PNR INTEGER NOT NULL,
PRIMARY KEY (LNR, TNR, PNR),
FOREIGN KEY LNR
REFERENCES LIEFERANT
ON DELETE NO ACTION
ON UPDATE CASCADE,
379
SQL-Statements
FOREIGN KEY TNR
REFERENCES TEIL
ON DELETE NO ACTION
ON UPDATE CASCADE,
FOREIGN KEY PNR
REFERENCES PROJEKT
ON DELETE CASCADE
ON UPDATE CASCADE
);
380
SQL-Statements
CREATE TABLE LIEFERTTEIL
(
LNR CHAR (6) NOT NULL,
TNR INTEGER NOT NULL,
PRIMARY KEY (LNR, TNR),
FOREIGN KEY LNR
REFERENCES LIEFERANT
ON DELETE CASCADE
ON UPDATE CASCADE,
FOREIGN KEY TNR
REFERENCES TEIL
ON DELETE CASCADE
ON UPDATE CASCADE
);
381
SQL-Statements
CREATE TABLE STRUKTUR
(
TNRE INTEGER NOT NULL, -- Das Teil TNRE enthält
TNRI INTEGER NOT NULL, -- das Teil TNRI
MENGE INTEGER,
PRIMARY KEY (TNRE, TNRI),
FOREIGN KEY (TNRE)
REFERENCES TEIL (TNR)
ON DELETE CASCADE
ON UPDATE CASCADE,
FOREIGN KEY (TNRI)
REFERENCES TEIL (TNR)
ON DELETE CASCADE
ON UPDATE CASCADE,
CHECK (MENGE > 0 OR MENGE = NULL)
);
382
Defizite traditioneller DB
• ingenieurmäßige Entwicklungsarbeiten
(CAD/CAM/CAE/CASE)
• integrierte Produktion (CIM)
• Bild- und Graphikdatenbanken
• wissenschaftliche Datenbanken
• geographische Informationssystemen
• Multimedia-Datenbanken
• Entwicklung einer einheitlichen Schnittstelle für viele
unterschiedliche Datenbanksysteme
383
Neue Anforderungen an DB
• Die Strukturen der Entitäten oder Objekte sind wesentlich komplizierter.
• Transaktionen dauern manchmal sehr lange (Stunden,
Tage).
• Neue Datentypen zur Speicherung von Bildern und langen Texten werden benötigt.
• Man muss die Möglichkeit haben, nicht-standardisierte,
von der jeweiligen Anwendung abhängige Operationen
zu definieren.
384
Experimentelle ooDBS-Prototypen
• ORION von MCC (Microelectronics and Computer
Technology Corporation)
• OpenOODB von Texas Instruments
• IRIS von Hewlett-Packard
• ODE von ATT Bell Labs
• ENCORE/ObServer von Brown University
385
Kommerzielle ooDBS
• GEMSTONE/OPAL von Gemstone Systems
• ONTOS von Ontology
• Objectivity von Objectivity
• Versant von Versant Technologies
• ObjectStore von Object Design
• O2 von O2 Technology
• POET von POET Software
• db4o von Versant
386
relational – objektorientiert
• Paradigma der Datenrepräsentation: Im relationalen
Modell werden Daten um Eigenschaften gruppiert, im
objektorientierten Modell um Objekte.
• Identität
• Problem des sogenannten impedance mismatch
• Komplexe Objekte
• Verhalten
• Orthogonale Persistenz
387
Erwartungen an ooDBS
• Komplizierte, verschachtelte Objekte können als Ganzes oder teilweise manipuliert werden.
• Beliebig lange Daten können gespeichert werden. In den Daten
kann gesucht werden.
• Beliebige Datentypen können repräsentiert werden.
• Versionen sollten verwaltbar sein.
• Langandauernde kooperative Transaktionen sollen unterstützt
werden.
• Regeln spezifizierbar. Repräsentation wissensbasierter Systeme.
388
Objekt-orientiertes Datenmodell
Objekt und Objekt-Identifikator: Jede Entität der realen Welt
ist ein Objekt und hat einen systemweit eindeutigen Identifikator.
Attribute und Methoden: Ein Objekt hat Attribute und Methoden, die mit den Werten der Attribute arbeiten. Die Werte von
Attributen sind auch Objekte.
Datenkapselung (encapsulation) und Botschaften (message passing): Einem Objekt werden Botschaften geschickt, um
auf die Werte der Attribute und die Methoden des Objekts zuzugreifen. Die möglichen Botschaften bilden die Oberfläche (interface) des Objekts.
389
Objekt-orientiertes Datenmodell
Klasse: Alle Objekte, die dieselben Attribute und Methoden haben,
können als zu einer Klasse gehörig betrachtet werden. Ein Objekt
gehört nur zu einer Klasse als Instanz der Klasse. Eine Klasse
ist auch ein Objekt, ist eine Instanz einer Metaklasse (metaclass).
Klassenhierarchie und Vererbung: Die Klassen eines Systems
bilden eine Hierarchie oder einen gerichteten, nicht-zyklischen
Graphen mit Wurzel. Spezialisierung. Generalisierung.Subklasse
(Unterklasse) (subclass). Superklasse (Oberklasse)
(superclass). Jede Subklasse erbt alle in der Superklasse definierten
Attribute und Methoden. Die Subklasse kann zusätzliche Attribute und
Methoden haben. Eine Instanz einer Subklasse kann wie eine Instanz der
Superklasse verwendet werden.
390
Normalisierung
These: Eine ooDB ist normalisiert, wenn jedes Datenelement oder Objekt höchstens einmal in der DB vorkommt.
Identifikatoren von Objekten können beliebig oft vorkommen; aber diese Zeiger-Redundanzen müssen von den Objekten transparent für den Benutzer der Objekte verwaltet
werden und dürfen nicht als Datenwerte verwendet werden.
391
Persistenzmodell
• Vererbung
• Delegation
• Explizite Datenbank-Aufrufe (z.B. store, create,
update, delete).
392
Queries – Anfrage-Strings
• IDEs oder Compiler können die Syntax und Semantik der Anfrage
nicht überprüfen.
• Bezeichner, die in Strings vorkommen, werden nicht automatisch
bei einem Refactoring nachgezogen.
• Oft werden private Datenelemente direkt angesprochen, was dem
Prinzip der Datenkapselung widerspricht.
• Die Entwickler müssen zwischen Programmier- und AnfrageSprache hin- und herschalten.
• Typische oo Möglichkeiten (Polymorphismus) stehen bei Anfragen
nicht zur Verfügung.
393
Klasse Teil
class Teil
(extent Teile)
{
attribute string PNR;
attribute string PNAME;
attribute string COLOR;
attribute short
WEIGHT;
attribute string CITY;
short
GMWT () { return 454 * WEIGHT; }
}
394
Klasse Lieferant
class Lieferant
(extent Lieferanten)
{
attribute string SNR;
attribute string SNAME;
attribute short
STATUS;
attribute string CITY;
}
395
Klasse Lieferung
class Lieferung
(extent Lieferungen)
{
attribute Lieferant S;
attribute Teil
P;
attribute short
QTY;
}
396
Objektorientiertes SQL – OQL
• Objekte werden direkt und nicht über Schlüsselwerte
referenziert.
• In der SELECT-Klausel treten Eigenschaften von Objekten auf, wobei die ”Punkt”- oder ”Pfeil”-Notation
verwendet wird.
• In der FROM-Klausel wird angegeben, zu welchen Klassen oder Mengen die Objekte gehören.
• In den SELECT- und WHERE-Klauseln können Operationen verwendet werden.
397
OQL
Farbe und Stadt für Teile nicht in Paris und Gewicht
größer als 10:
SELECT
P.COLOR, P.CITY
FROM P IN Teile
WHERE
P.CITY <> ’Paris’
AND
P.WEIGHT > 10;
398
OQL
Alle Teilenummern und Gewichte in Gramm:
SELECT
FROM
P.PNR, P.GMWT
P IN Teile;
399
OQL
Namen der Lieferanten, die Teil P2 liefern:
SELECT DISTINCT
SP.S.SNAME
FROM SP IN Lieferungen
WHERE SP.P.PNR = ’P2’;
400
Objektorientierter DB-Entwurf
• Pseudocode mit ooDB-Konstrukten wie
persistent, unique, ref, container
• ODL
401
”Hat-ein” – Beziehung
• has-a, Whole-Part, Teil-Ganzes, ”ist-Teil-von”
• Aggregation oder Komposition
• Komponentengruppe hat eine oder viele Komponenten
• One-to-One-Beziehung oder
One-to-Many-Beziehung (”Hat-viele”)
• hat keine Eigenschaften
• Referenz (Referenz-Behälter)
◦ oder Objekt (Objekt-Behälter)
• Eine echte ”Hat-ein” – Beziehung kann wie eine Eigenschaft behandelt werden.
402
”Benutzt-ein” – Beziehung
• uses-a
• meistens eine Many-to-One-Beziehung,
seltener eine Many-to-Many-Beziehung (”Benutztviele”)
• hat keine Eigenschaften
• Referenz oder Referenz-Behälter beim Benutzer (Client)
• selten Referenz-Behälter beim Benutzten (Server)
• E/R-Modell enthält benutzte Methode des Servers.
Deklaration dieser Methode in der Server-Klasse.
403
”Benutzt-ein” – Beziehung
class User
{
private ref Used used;
}
class Used
{
private ref container User
// optional
}
404
contUser;
Ähnlichkeit
• Kann nicht direkt mit Vererbung implementiert werden.
• Gemeinsamkeiten ähnlicher Entitäten müssen in einer
eigenen Klasse definiert werden, von der die einander
ähnlichen Entitäten dann erben.
• Beispiel: Rechteck – Quadrat
405
Kategorie
• K ist Kategorie der Typen Ti.
• G ist gemeinsame für K relevante Schnittstelle von Ti.
• Ti erben bzw implementieren G.
• K hat Referenz g vom Typ G.
• K kann mit g seine Methoden implementieren.
• K kann zusätzlich G erben bzw implementieren.
406
Kategorie
interface G
{
Returntyp
methode ();
}
persistent class Ti implements G
{
Returntyp methode () { Methoden-Implementation }
}
persistent class K
{
Returntyp
methodeVonK () { ... g.methode () ... }
ref G g;
}
407
Entität
class ABTEILUNG
(extent Abteilungen)
{
// --}
class ANGESTELLTER
(extent Angestellte key ANR)
{
attribute string ANR;
// --}
408
Eigenschaften
struct
aname { string VORN, string MIN, string NAN }
struct
adresse { string strasse, string ort }
class ANGESTELLTER
(extent Angestellte key ANR)
{
attribute string ANR;
attribute aname
ANAME;
attribute double GEHALT;
double
monatsgehalt ();
attribute set<adresse> ADRESSE;
}
409
Beziehung
class ABTEILUNG
{
relationship set<ANGESTELLTER> hatAngestellte
inverse ANGESTELLTER::istInAbteilung;
}
class ANGESTELLTER
{
relationship ABTEILUNG istInAbteilung
inverse ABTEILUNG::hatAngestellte;
}
410
Beziehung
class ANGESTELLTER
{
relationship set<ARBEITETAN> bearbeitet
inverse ARBEITETAN::angestellter;
}
class PROJEKT
{
relationship set<ARBEITETAN> wirdBearbeitet
inverse ARBEITETAN::projekt;
}
class ARBEITETAN
{
relationship ANGESTELLTER angestellter
inverse ANGESTELLTER::bearbeitet;
relationship PROJEKT projekt
inverse PROJEKT::wirdBearbeitet;
}
411
Beziehung
class ANGESTELLTER
{
relationship set<PROJEKT> bearbeitet
inverse PROJEKT::wirdBearbeitet;
}
class PROJEKT
{
relationship set<ANGESTELLTER>
wirdBearbeitet
inverse ANGESTELLTER::bearbeitet;
}
412
”Benutzt-ein” – Beziehung
class User
{
relationship Used uses
inverse Used::used;
}
class Used
{
relationship set<User>
inverse User::uses;
}
413
used
Vererbung: Erweiterung
class TAGESPROJEKT extends PROJEKT
{
// --attribute date TAG;
// --}
414
Vererbung: Obertyp-Untertyp
interface VorhabenIfc
{
// --}
interface ProjektIfc : VorhabenIfc
{
// --}
class PROJEKT : ProjektIfc
{
// --}
415
Kategorie
interface G
{
Returntyp
methode ();
}
class Ti : G
{
Returntyp methode () context ( Methoden-Implementation );
}
class K
{
Returntyp
methodeVonK () context ( ... g.methode () ... );
attribute G g;
}
416
Objektorientierter Entwurf
Reguläre Entität
=⇒
Klasse, deren Objekte persistent sind.
Schlüssel sind prinzipiell nicht nötig,
spielen keine Rolle bei Beziehungen,
sind aber nützlich beim Finden von Objekten.
417
Objektorientierter Entwurf
persistent class
{
// --}
ABTEILUNG
persistent class ANGESTELLTER
{
// --unique String ANR; // Primärschlüssel
// --}
418
Objektorientierter Entwurf
Eigenschaft
=⇒
Privates Datenelement einer Klasse mit geeigneten öffentlichen Zugriffsmethoden.
419
Objektorientierter Entwurf
Abgeleitete Eigenschaft
=⇒
Methode
420
Objektorientierter Entwurf
Zusammengesetzte Eigenschaft
=⇒
globale oder lokale Klasse, deren Objekte Datenelement
der Klasse mit der entsprechenden Eigenschaft werden.
421
Objektorientierter Entwurf
Mehrwertige Eigenschaft
=⇒
Behälter-Klassenobjekt als Datenelement
422
Objektorientierter Entwurf
Verhalten
=⇒
Methoden
423
Objektorientierter Entwurf
class ANAME
{
private String
private String
private String
}
VORN;
MIN;
NAN;
424
Objektorientierter Entwurf
persistent class
{
public double
private
private
private
private
}
ANGESTELLTER
monatsgehalt ()
{ return GEHALT / 13.2; }
unique String ANR; // Primärschlüssel
ANAME aname;
double
GEHALT;
container ADRESSE contADRESSE;
425
Objektorientierter Entwurf
Beziehung
=⇒
persistente Klasse (Beziehung mit Eigenschaften)
eventuell mit Referenz(-Behälter) bei den Teilnehmern
oder nur
Referenz(-Behälter) bei den Teilnehmern der Beziehung
426
Objektorientierter Entwurf
Many—
to
—Many
Referenz-Behälter
Referenz-Behälter
Many—
to
—One
Referenz
Referenz-Behälter
One—
to
—One
Referenz
Referenz
427
Objektorientierter Entwurf
Beziehung ”AbtAngest”:
persistent class ABTEILUNG
{
private ref container ANGESTELLTER
}
persistent class ANGESTELLTER
{
private ref ABTEILUNG abteilung;
}
428
contAngestellter;
Objektorientierter Entwurf
Beziehung ”ArbeitetAn”:
persistent
{
private
}
persistent
{
private
}
persistent
{
private
private
}
class
ANGESTELLTER
ref container ARBEITETAN
class
PROJEKT
ref container ARBEITETAN
class
contArbeitetan;
contArbeitetan;
ARBEITETAN
ref ANGESTELLTER angestellter;
ref PROJEKT projekt;
429
Objektorientierter Entwurf
Schwache Entität
=⇒
Klasse, deren Objekte Datenelemente der Klasse
einer regulären Entität sind.
Schwache Entität ist eine ”Hat-ein”–Beziehung
und die ”Hat-ein”–Beziehung ist eine Eigenschaft.
430
Objektorientierter Entwurf
Untertyp-Obertyp-Beziehung
=⇒
Untertyp erbt vom Obertyp.
persistent class TAGESPROJEKT extends PROJEKT
{
private DATE TAG; // Klasse DATE muß
// natürlich definiert sein
}
431
”objektorientiertes” E/R-Diagramm
Stärkere Nutzung der Obertyp-Untertyp-Beziehung
(Vererbung), insbesondere wenn zwei Entitäten zwei
verschiedene Beziehungen eingehen.
Beispiel:
Angestellter ArbeitetAn Projekt
Angestellter Leitet Projekt
sollte modelliert werden als:
Angestellter ArbeitetAn Projekt
Projektleiter Ist-ein Angestellter
Projektleiter Leitet Projekt
432
Hierarchische DBMS
MARS VI (Multi-Access Retrieval System) von Control
Data
IMS (Information Management System) von IBM
System-2000 von MRI/SAS
IMAGE 9000 von HP
433
Hierarchisches Datenmodell
Datensatz
Feldwert
Datensatztyp
record
field value, data item
record type
Elter-Kind-Beziehung
1:M-Beziehung
parent-child relationship
PCR-type
Eltertyp
Kindtyp
parent record type
child record type
434
Hierarchisches Datenmodell
Hierarchisches
Datenbankschema
hierarchical
database schema
besteht aus
consists of
Hierarchien
hierarchies
435
Hierarchisches Datenmodell
ABTEILUNG
ABTNRANAME ... ...
ANGESTELLTER
ANGNR ... ... ... ...
PROJEKT
... ... ... ...
436
Hierarchisches Datenmodell
• Ein spezieller Datensatztyp, die Wurzel (root), ist
niemals Kind.
• Jeder Datensatztyp kann als Kind nur in genau einer
Beziehung vorkommen.
• Als Elter kann ein Datensatztyp in beliebig vielen Beziehungen vorkommen.
• Ein Datensatz, der kein Elter ist, ist ein Blatt (leaf ).
• Wenn ein Elter mehrere Kindtypen hat, dann sind diese
von links nach rechts geordnet.
437
M:N-Beziehung
ABTEILUNG
ANGESTELLTER
PROJEKT
ANGESTELLTER
438
Instanzenbaum occurrence tree
procedure preorder_traverse (parent_record);
begin
output (parent_record);
for each child_record of parent_record
in left to right order
do preorder_traverse (child_record);
end;
439
Probleme
1. M:N-Beziehungen
2. Kinder mit mehreren Eltern
3. ternäre und höherwertige Beziehungen
440
VPCR
Hierarchie 1
Hierarchie 2
ABTEILUNG
PROJEKT
virt. PROJEKT
ANGEST
virt. ANGEST
441
Netzwerk-Datenmodell
1971 CODASYL-DBTG
(Conference on Data System Languages – Database
Taskgroup)
1984 NDL (Netzwerk-Definitions-Sprache)
IDMS von IBM
(Integrated Database Management System)
UDS von Siemens
(Universal Database System)
442
Netzwerk-Datenmodell
Datensatz
Datensatztyp
record
record type
Datenelement
Format
data item, attribute
format, data type
Wiederholungsgruppe repeating group
virtuelle, abgeleitete virtual, derived
Datenelemente
data item
443
Netzwerk-Datenmodell
STUDENT
NAME MATRIKEL GEBURTSTAG
444
Netzwerk-Datenmodell
Datenelementtyp
NAME
MATRIKEL
GEBURTSTAG
Format
CHARACTER 30
CHARACTER 6
CHARACTER 8
445
Netzwerk-Datenmodell
STUDENT
NAME MATRIKEL GEBURTSTAG
446
LEISTUNG
FACH NOTE
Netzwerk-Datenmodell: Beziehungen
Mengentyp set type
Besitzertyp owner record type
Mitgliedstyp member record type
Die Mitglieder einer Menge sind geordnet. Wir können
vom ersten, zweiten, i-ten und letzten Datensatz sprechen.
(owner-coupled set oder co-set).
447
Netzwerk-Datenmodell: Beziehungen
Bachmann-Diagramm
KURS
···
↓ KURSBELEGUNG
STUDENT
NAME
···
KNAME
448
Netzwerk-Datenmodell: Beziehungen
System-eigene Mengen (system-owned, singular set): spezielle Mengen ohne Besitzerdatensatztyp
(entry points).
Multi-Mitglieds-Mengen (multimember set):
Mitglieder unterschiedlichen Typs
449
Netzwerk-Datenmodell: Beziehungen
Rekursiven Mengen (recursive set):
Besitzer und Mitglied sind vom gleichen Typ.
ANGESTELLTER LEITET ANGESTELLTER
−→
ISTLEITER
−→
ANGESTELLTER
MANAGER
←−
LEITET
450
Netzwerk-Datenmodell: Beziehungen
M:N-Beziehungen:
ANGESTELLTER −→ ARBEITETAN ←− PROJEKT
451
Beispiel Transaktion
EXEC SQL INSERT
INTO SP (SNR, PNR, QTY)
VALUES (’S5’, ’P1’, 180);
EXEC SQL UPDATE
P
SET
TOTQTY = TOTQTY + 180
WHERE PNR = ’P1’;
452
Transaktion
begin transaction :
SQL: Es läuft keine Transaktion.
Transaktionsinitiierendes Statement
commit transaction :
SQL: COMMIT;
rollback transaction :
SQL: ROLLBACK;
453
Beispiel Transaktion
EXEC SQL WHENEVER SQLERROR GO TO rollback;
EXEC SQL INSERT -- Beginn der Transaktion
INTO SP (SNR, PNR, QTY)
VALUES (’S5’, ’P1’, 180);
EXEC SQL UPDATE
P
SET
TOTQTY = TOTQTY + 180
WHERE PNR = ’P1’;
EXEC SQL COMMIT -- Ende der Transaktion;
goto ende;
rollback: EXEC SQL ROLLBACK -- Ende der Transa.;
ende: ;
454
ACID-Eigenschaften
• Atomicity : Transaktionen sind atomar.
(”Alles oder Nichts”)
• Consistency : Eine Transaktion transformiert die Datenbank von
einem konsistenten (korrekten) Zustand in einen anderen konsistenten (korrekten) Zustand.
• Isolation : Transaktionen sind voneinander isoliert. Keine Transaktion kann Zwischenzustände einer anderen Transaktion sehen.
• Durability : Änderungen an der Datenbank sind nach einem
COMMIT permanent, auch wenn es sofort danach zu einem Systemabsturz kommt.
455
Nebenläufigkeit (Concurrency)
Probleme:
• lost update
(verlorene Aktualisierung)
• uncommitted dependency
(Abhängigkeit von nicht permanenten Daten)
• inconsistent analysis
(Arbeit mit inkonsistenten Daten)
456
Lost Update
1. Transaktion A ermittelt Tupel p zur Zeit t1.
2. Transaktion B ermittelt Tupel p zur Zeit t2.
3. Transaktion A aktualisiert Tupel p zur Zeit t3 (auf der
Basis von Werten, die zur Zeit t1 gesehen wurden).
4. Transaktion B aktualisiert Tupel p zur Zeit t4 (auf der
Basis von Werten, die zur Zeit t2 gesehen wurden).
457
Uncommitted Dependency
1. Transaktion B aktualisiert Tupel p zur Zeit t1.
2. Transaktion A ermittelt (oder aktualisiert gar) Tupel p
zur Zeit t2.
3. Transaktion B macht ein ROLLBACK zur Zeit t3.
458
Inconsistent Analysis
1. Transaktion A ermittelt K1(= 40) und summiert (S = 40).
2. Transaktion A ermittelt K2(= 50) und summiert (S = 90).
3. Transaktion B ermittelt K3(= 60).
4. Transaktion B aktualisiert K3 = K3 − 10 = 50.
5. Transaktion B ermittelt K1(= 40).
6. Transaktion B aktualisiert K1 = K1 + 10 = 50.
7. Transaktion B COMMIT.
8. Transaktion A ermittelt K3(= 50) und summiert (S = 140).
459
Sperren (Locking)
1. X-Lock (exclusive lock, write-Lock, write-exclusive, exclusives
Schreiben, Schreibsperre)
2. S-Lock (shared lock, read-lock, read-sharable, gemeinsames
Lesen, Lesesperre)
3. U-Lock (upgrade lock)
S-Lock U-Lock X-Lock
S-Lock
ja
ja
nein
U-Lock
ja
nein
nein
X-Lock nein
nein
nein
460
Lost Update
1. Transaktion A fordert S-Lock für Tupel p, bekommt das S-Lock
und ermittelt Tupel p zur Zeit t1.
2. Transaktion B fordert S-Lock für Tupel p, bekommt das S-Lock
und ermittelt Tupel p zur Zeit t2.
3. Transaktion A fordert X-Lock für Tupel p zur Zeit t3 und muß auf
das X-Lock warten, da Transaktion B ein S-Lock auf Tupel p hat.
4. Transaktion B fordert X-Lock für Tupel p zur Zeit t4 und muß
ebenfalls auf das X-Lock warten, da Transaktion A ein S-Lock auf
Tupel p hat.
5. . . .
461
Uncommitted Dependency
1. Transaktion B fordert X-Lock für Tupel p, bekommt
das X-Lock und aktualisiert Tupel p zur Zeit t1.
2. Transaktion A fordert S-Lock (X-Lock) für Tupel p zur
Zeit t2 u nd muß warten, bis B das X-Lock freigibt.
3. Transaktion B macht ein ROLLBACK zur Zeit t3 und
gibt damit alle Locks frei.
4. Transaktion A bekommt das S-Lock (X-Lock) und ermittelt (aktualisiert) Tupel p zur Zeit t4.
462
Inconsistent Analysis
1. Transaktion A fordert S-Lock für K1 , bekommt dies, ermittelt K1 (= 40) und summiert
(S = 40).
2. Transaktion A fordert S-Lock für K2 , bekommt dies, ermittelt K2 (= 50) und summiert
(S = 90).
3. Transaktion B fordert S-Lock für K3 , bekommt dies und ermittelt K3 (= 60).
4. Transaktion B fordert X-Lock für K3 , bekommt dies und aktualisiert K3 = K3 − 10 = 50.
5. Transaktion B fordert S-Lock für K1 , bekommt dies und ermittelt K1 (= 40).
6. Transaktion B fordert X-Lock für K1 und bekommt dies nicht, weil A ein S-Lock darauf
hat. Wartet.
7. Transaktion A fordert S-Lock für K3 und bekommt dies nicht, weil B ein X-Lock darauf
hat. Wartet.
8. . . .
463
Behandlung von Verklemmung
Voranforderungsstrategie (preclaim strategy)
: Jede Transaktion fordert alle ihre Sperren an, bevor
sie mit der Ausführung beginnt.
Toleranzstrategie : Verklemmungen werden erlaubt
und gelöst. Zur Erkennung einer Verklemmung muß ein
Vorranggraph (Wait-For-Graph) aufgebaut werden.
Zur Auflösung einer Verklemmung wird eine der verklemmten Transaktionen zurückgesetzt (ROLLBACK) –
eventuell mit Meldung an den Benutzer – und später
wieder neu gestartet.
464
Behandlung von Verklemmung
Strategie mit U-Locks : Vor Beginn fordert jede
Transaktion für alle Objekte, die gelesen werden sollen,
ein S-Lock, und für alle Objekte, die aktualisiert werden sollen, ein U-Lock an. Während einer Transaktion
werden dann vor dem Aktualisieren die entsprechenden
X-Locks angefordert.
465
Behandlung von Verklemmung
1. Transaktion A fordert S-Locks für K1 , K2 und K3 . Bekommt diese.
2. Transaktion A ermittelt K1 (= 40) und summiert (S = 40).
3. Transaktion A ermittelt K2 (= 50) und summiert (S = 90).
4. Transaktion B fordert U-Locks für K1 und K3 . Bekommt diese.
5. Transaktion B ermittelt K3 (= 60).
6. Transaktion B fordert X-Lock für K3 und bekommt dies nicht. Wartet.
7. Transaktion A ermittelt K3 (= 60) und summiert (S = 150).
8. Transaktion A ist fertig und gibt Locks frei.
9. Transaktion B bekommt nun X-Lock für K3 und aktualisiert K3 = K3 − 10 = 50.
10. Transaktion B ermittelt K1 (= 40).
11. Transaktion B fordert X-Lock für K1 , bekommt dies und aktualisiert K1 = K1 + 10 = 50.
466
Behandlung von Verklemmung
1. Transaktion A fordert S-Locks für K1 , K2 und K3 . Bekommt diese.
2. Transaktion A ermittelt K1 (= 40) und summiert (S = 40).
3. Transaktion A ermittelt K2 (= 50) und summiert (S = 90).
4. Transaktion B fordert X-Locks für K1 und K3 . Bekommt diese nicht und wartet.
5. Transaktion A ermittelt K3 (= 60) und summiert (S = 150).
6. Transaktion A ist fertig und gibt Locks frei.
7. Transaktion B bekommt nun seine Locks.
8. Transaktion B ermittelt K3 (= 60).
9. Transaktion B aktualisiert K3 = K3 − 10 = 50.
10. Transaktion B ermittelt K1 (= 40).
11. Transaktion B aktualisiert K1 = K1 + 10 = 50.
467
Serialisierbarkeit
• Eine verschachtelte Durchführung von mehreren
korrekten Transaktionen ist dann korrekt, wenn sie
serialisierbar ist, d.h. wenn sie dasselbe Resultat liefert wie mindestens eine nicht verschachtelte (serielle) Durchführung der Transaktionen.
468
Zwei-Phasen-Sperrtheorem
• Wenn alle Transaktionen das Zwei-Phasen-Sperrprotokoll (two-phase-locking-protocol) beachten,
dann sind alle möglichen verschachtelten Durchführungen serialisierbar, wobei das Zwei-PhasenSperrprotokoll folgendermaßen aussieht:
1. Bevor eine Transaktion ein Objekt benützt, muß
sie eine Sperre auf das Objekt setzen.
2. Nach der Freigabe einer Sperre darf eine Transaktion keine weiteren Sperren setzen (auch keine
Upgrade-Locks).
469
Sperren und SQL
• SQL unterstützt keine expliziten Sperrmechanismen.
• SQL-Anweisungen fordern implizit die entsprechenden
Locks an.
• Locks werden bis zum Ende einer Transaktion gehalten,
wodurch automatisch das Zwei-Phasen-Sperrprotokoll
eingehalten wird.
470
Isolationsniveau
(Level of Isolation)
SET TRANSACTION ISOLATION LEVEL
SERIALIZABLE Serialisierbarkeit
REPEATABLE READ ermöglicht das Lesen von Phantomen
READ COMMITTED erlaubt zusätzlich nicht wiederholbares
Lesen (nonrepeatable read)
READ UNCOMMITTED erlaubt zusätzlich ”schmutziges”
Lesen (dirty read)
471
Isolationsniveau
Typ der Verletzung der Serialisierbarkeit
Isolationsniveau
dirty read nonrepeatable read phanto
READ UNCOMMITTED
ja
ja
ja
READ COMMITTED
nein
ja
ja
REPEATABLE READ
nein
nein
ja
SERIALIZABLE
nein
nein
nein
472
Sperrgranularität (Degree of Granularity)
• die gesamte Datenbank
• eine Relation
• ein physischer Plattenblock
• ein Tupel
• ein Attributwert
473
Weitere Sperrmechanismen
IS (intent shared) : Transaktion T beabsichtigt S-Locks auf einzelne Tupel
von R zu setzen, um einzelne Tupel in R zu lesen.
S (shared) : Transaktion T erlaubt konkurrierende Leser für R. Aktualisierende Transaktionen sind in R nicht erlaubt. T selbst wird keine Aktualisierungen von R vornehmen.
IX (intent exclusive) : Transaktion T beabsichtigt X-Locks auf einzelne Tupel von R zu setzen.
SIX (shared intent exclusive) : Transaktion T erlaubt konkurrierende Leser für R. Aktualisierende Transaktionen sind in R nicht erlaubt. Aber T
selbst wird einzelne Tupel von R aktualisieren und X-Locks auf einzelne
Tupel von R zu setzen.
X (exclusive) : T erlaubt überhaupt keinen konkurrierenden Zugriff auf R. T
selbst wird eventuell einzelne Tupel von R aktualisieren.
474
Kompatibiltätsmatrix
X
X nein
SIX nein
IX nein
S nein
IS nein
–
ja
SIX
nein
nein
nein
nein
ja
ja
IX S IS –
nein nein nein ja
nein nein ja ja
ja nein ja ja
nein ja
ja ja
ja
ja
ja ja
ja
ja
ja ja
475
interface
{
enum
void
boolean
boolean
Object
void
};
Transaktionsmodell der ODMG
Object
Lock_Type {read, write, upgrade};
lock (in Lock_Type mode)
raises (LockNotGranted);
try_lock (in Lock_Type mode);
same_as (in Object anObject);
copy ();
delete ();
476
interface
{
void
void
void
void
void
void
boolean
};
Transaktionsmodell der ODMG
Transaction
begin ()
raises (TransactionInProgress,
DatabaseClosed);
commit ()
raises (TransactionNotInProgress);
abort ()
raises (TransactionNotInProgress);
checkpoint () raises (TransactionNotInProgress);
join ()
raises (TransactionNotInProgress);
leave ()
raises (TransactionNotInProgress);
isOpen ();
477
Transaktionsmodell der ODMG
interface
TransactionFactory
{
Transaction new ();
Transaction current ();
};
478
Java Binding
public interface Transaction
{
public void begin ();
public void commit ();
public void abort ();
public void checkpoint ();
public void join ();
public void leave ();
public boolean isOpen ();
public void lock (Object obj, int mode);
public boolean try_lock (Object obj, int mode);
public static final int READ = 1;
public static final int UPGRADE = 2;
public static final int WRITE = 4;
}
479
Wiederherstellung (Recovery)
Journal:
1. aktiver Teil auf Platte
2. Archivteil auf Band
480
Arten von Recovery
• Transaction Recovery bei Transaktionsfehlern
• System Recovery bei Systemabsturz ohne Schädigung
der Speichermedien
• Media Recovery bei Hardware-Fehler des Speichermediums
481
Transactionrecovery
COMMIT- oder ROLLBACK-Statement :
Etablierung eines Syncpoints oder commit point
COMMIT :
Neuer Syncpoint etabliert. Dabei werden alle Änderungen an der Datenbank seit dem letzten Syncpoint
permanent gemacht. Alle Tupel-Locks werden freigegeben. Tupeladressierbarkeit geht verloren (Kursoren).
Die Transaktion wird beendet.
ROLLBACK :
Zurück zum vorhergehenden Syncpoint.
482
Systemrecovery
Systemabsturz: Inhalt des Hauptspeichers geht verloren.
(write-ahead log rule): Journaleintrag vor dem COMMIT
Recovery: Für einige Transaktionen muß COMMIT, für
andere ROLLBACK gemacht werden.
Checkpoints in regelmäßigen Abständen.
483
Verwendung von Checkpoints
1. Transaktion T1 wurde vor tc beendet.
Recovery : Nicht nötig.
2. Transaktion T2 wurde vor tc gestartet und zwischen tc und tf
beendet.
Recovery : Muß wiederholt werden.
3. Transaktion T3 wurde vor tc gestartet und nicht vor tf beendet.
Recovery : ROLLBACK
4. Transaktion T4 wurde nach tc gestartet und vor tf beendet.
Recovery : Muß wiederholt werden.
5. Transaktion T5 wurde nach tc gestartet und nicht vor tf beendet.
Recovery : ROLLBACK
484
Mediarecovery
Physikalischer Schaden am Speichermedium
Recovery:
1. (reloading, restoring) der Datenbank von einem
Backup-Medium
2. Mit Journal alle Transaktionen seit Backup wiederholen
485
Schutz von Daten
Sicherheit von Daten bedeutet, daß nur berechtigte
DB-Benutzer auf Daten zugreifen können. Die Berechtigungen können von der Art der Daten abhängen.
Integrität von Daten bedeutet, daß Datenmanipulationen korrekt sind.
486
Problemkreise von Sicherheit
• juristisch (Datenschutz)
• organisatorisch
• technisch
• DB-spezifisch
487
Arten der Zugangskontrolle
1. discretionary access control: Vergabe von Berechtigungen (Lesen, Schreiben) für bestimmte Datenobjekte
an bestimmte Benutzer (privileges, authorities)
2. mandatory access control: Vergabe von unterschiedlichen Sicherheitsstufen an Benutzer (clearance level)
und Datenobjekte (classification level).
488
Sicherheitsregeln in SQL/92
security-rule
::= GRANT privilege-commalist
ON { [TABLE] table | DOMAIN domain }
TO { user-commalist | PUBLIC}
[ WITH GRANT OPTION ]
|
REVOKE [ WITH GRANT OPTION ]
privilege-commalist
ON { [TABLE] table | DOMAIN domain }
FROM { user-commalist | PUBLIC}
{ RESTRICT | CASCADE };
489
Sicherheitsregeln in SQL/92
privilege
::=
USAGE
| SELECT
| INSERT [ (column-commalist) ]
| UPDATE [ (column-commalist) ]
| DELETE
| REFERENCES
490
Sicherheitsregeln in SQL/92
CREATE VIEW SR3 AS
SELECT
S.SNR, S.SNAME, S.CITY
FROM S
WHERE S.CITY <> ’London’;
GRANT SELECT, UPDATE (S.SNAME), DELETE
ON SR3
TO Pschorr, Salvator WITH GRANT OPTION;
REVOKE WITH GRANT OPTION DELETE
ON SR3
FROM Pschorr;
491
Datenverschlüsselung
DES (Data Encryption Standard) ist ein StandardAlgorithmus, der auf dem symmetrischen oder secret key
Verfahren beruht, wo jeder Kommunikationspartner über
denselben, geheimen Schlüssel verfügt.
Asymmetrische Verfahren beruhen darauf, daß zwei
Schlüssel verwendet werden: ein öffentlich bekannter
zum Verschlüsseln und ein geheimer Schlüssel zum Entschlüsseln. Als Algorithmus wird RSA nach Rivest, Shamir und Adleman verwendet.
492
Integritätsregeln
• Wertebereichsintegritätsregeln
• Datenbank-Integritätsregeln
• Basistabellen-Integritätsregeln
• Spalten-Integritätsregeln
493
Wertebereichsintegritätsregel
domain-definition
::= CREATE DOMAIN domain [ AS ] data-type
[ default-definition ]
[ domain-constraint-definition-list ]
domain-constraint-definition
::= [ CONSTRAINT constraint ]
CHECK ( conditional-expression )
domain-constraint-alteration-action
::= ADD domain-constraint-definition
| DROP CONSTRAINT constraint
494
Wertebereichsintegritätsregel
CREATE DOMAIN GESCHLECHT CHAR (1)
CHECK ( VALUE IN ( ’m’, ’w’));
CREATE DOMAIN STATUS INTEGER
CONSTRAINT KEINENULL
CHECK ( VALUE IS NOT NULL )
CONSTRAINT MAXSTATUS CHECK ( VALUE <> 0 )
CONSTRAINT MAXSTATUS CHECK ( VALUE <= 100 );
495
Datenbank-Integritätsregeln
CREATE ASSERTION constraint
CHECK ( conditional-expression );
DROP ASSERTION constraint;
496
Datenbank-Integritätsregeln
CREATE ASSERTION REGEL1 CHECK
( (SELECT MIN(S.STATUS) FROM S) > 4);
CREATE ASSERTION REGEL2
(NOT EXISTS (SELECT
FROM
WHERE
CHECK
*
P
P.COLOR = ’Red’
AND P.CITY <> ’London’));
497
Datenbank-Integritätsregeln
CREATE ASSERTION REGEL3
(NOT EXISTS (SELECT
FROM
WHERE
CHECK
*
S JOIN SP USING (SNR)
S.STATUS < 10));
498
Basistabellen-Integritätsregeln
[ CONSTRAINT constraint ]
{PRIMARY KEY | UNIQUE } ( column-commalist )
[ CONSTRAINT constraint ]
FOREIGN KEY ( column-commalist )
references-definition
[ CONSTRAINT constraint ]
CHECK ( conditional-expression )
499
Spalten-Integritätsbedingungen
1. NOT NULL
2. PRIMARY KEY oder UNIQUE
3. references-definition
4. check-constraint-definition
500
Wann wird Integrität geprüft?
INITIALLY IMMEDIATE NOT DEFERRABLE (Default)
Integritätsbedingung wird sofort bei der Ausführung eines SQL-Statements überprüft.
INITIALLY IMMEDIATE DEFERRABLE
Mit SET CONSTRAINTS Statement (siehe unten) kann
der Mode der Regel auf IMMEDIATE oder DEFERRED
gesetzt werden.
INITIALLY DEFERRED [ DEFERRABLE ]
Integritätsregeln werden nur am Ende der Transaktion
überprüft.
501
Wann wird Integrität geprüft?
SET CONSTRAINTS {constraint-commalist
| ALL} {DEFERRED | IMMEDIATE}
Die genannten Constraints müssen DEFERRABLE sein.
Das Statement kann vor oder während einer Transaktion gegeben werden.
502
CREATE VIEW
SELECT
FROM
WHERE
Beispiel View
SGUT AS
SNR, STATUS, CITY
S
STATUS > 15;
503
Wozu Views ?
• Basisrelationen: Unabhängigkeit von physikalischer
Repräsentation
• Views: Unabhängigkeit von logischer Repräsentation.
Ermöglicht Transparenz für den Benutzer bei
– Wachstum
– Restrukturierung
– verschiedenen Sichten
– Sicherheit
504
SELECT
FROM
P.CITY
S JOIN
JOIN P
WHERE S.CITY
”Macro”-Eigenschaft
AS PCITY
SP USING (SNR)
USING (PNR)
= ’London’;
CREATE VIEW CITIES (PCITY, SCITY) AS
SELECT
P.CITY, S.CITY
FROM S JOIN SP USING (SNR)
JOIN P USING (PNR);
SELECT
PCITY
FROM CITIES
WHERE SCITY = ’London’;
505
SQL/92-Syntax
view-definition
::= CREATE VIEW view [ ( column-commalist ) ]
AS table-expression
[ WITH [ CASCADED | LOCAL ] CHECK OPTION ]
view-destruction
::= DROP VIEW view { RESTRICT | CASCADE }
506
Views sind aktualisierbar oder nicht.
Der View SGUT ist aktualisierbar.
Der View CITIES ist nicht aktualisierbar.
SQL-Aktualisierbarkeit ist eingeschränkter als
theoretische Aktualisierbarkeit.
WITH CASCADED CHECK OPTION ist vernünftig.
507
Verteiltes Datenbanksystem (DDBS)
Daten-Server-Prozesse auf unterschiedlichen Rechnern
Replikation: Daten redundant auf mehreren Servern wegen Effizienz oder Ausfallsicherheit.
Verteilung oder Partitionierung: Daten sind nicht
redundant verteilt.
Verteilungstransparenz
508
ANSI-SPARC-Architektur
(Globale) externe Ebenen: Beschreiben
anwendungsspezifische Darstellungen der Daten. Sie werden
ausschießlich auf dem (globalen) konzeptuellen Schema
definiert.
(Globale) konzeptuelle Ebene: Das (globale) konzeptuelle Schema (GKS) beschreibt den integrierten
globalen Datenbestand ohne Hinweise auf die Verteilung der Daten.
(Globale) interne Ebene: Diese Ebene besteht aus
verschiedenen genormten Ebenen.
509
Interne Ebene
Fragmentierungsebene: Das Fragmentierungsschema
beschreibt die Aufteilung der Datenbankobjekte auf
Teilobjekte, z.B. Relationen auf Teil-Relationen.
Allokationsebene: Das Allokationsschema beschreibt
die Zuordnung von Teilobjekten (Fragmenten) zu
Komponenten-DBSs (Knoten, konkrete Rechner).
Wird ein Teilobjekt mehreren Knoten zugeordnet,
spricht man von Replikation.
Ebene der Komponenten-DBS: Jeder
Knoten
ist wieder ein DBS, dessen externe Ebene eine
Transformations-Ebene (mapping) ist.
510
Fragmentierung und Allokation
• Horizontale Fragmentierung
• Vertikale Fragmentierung
• Gemischte Fragmentierung
• Abgeleitete Fragmentierung
FRi = Ri 1K (πK FRr )
511
kontrollierte Replikation
• Effizienz
• Ausfallsicherheit
• Autonomie (Knoten, die nicht ständig am Netz sind.)
512
Replikationskontrolle
Master-Slave (Primary Copy): Es gibt eine ausgezeichnete Replikation, die Primärkopie, auf der alle Aktualisierungen (Datenänderungen) zuerst durchgeführt
werden.
Majority-Consensus: Beim
Abstimmungsverfahren nehmen die Rechnerknoten an einer
Abstimmung darüber teil, ob ein Zugriff auf replizierte
Daten erlaubt werden kann oder nicht. (Lese- und
Schreibquoren)
513
Katalog
• Ein zentralisierter Katalog wird auf einem Rechner
zentral gehalten.
• Ein vollredundanter Katalog wird vollständig auf
allen Knoten repliziert.
• Ein Cluster- oder Mehrfachkatalog ist ein Kompromiss zwischen den ersten beiden Möglichkeiten. (Teilnetze)
• Schließlich können ausschließlich lokale Kataloge gehalten werden, die zu einem virtuellen globalen Katalog integriert werden.
514
Verteilte Transaktionen, Commit
• Alle Rechnerknoten kommen global zu einer Entscheidung. Dabei
ist nur Commit oder Rollback möglich.
• Ein Knoten kann eine getroffene Entscheidung nicht mehr
rückgängig machen.
• Eine Commit-Entscheidung kann nur getroffen werden, wenn alle
Knoten mit ”ja” gestimmt haben.
• Treten keine Fehler auf und votieren alle Knoten mit ”ja”, so lautet
die Entscheidung auf Commit.
• Das Protokoll ist robust. D.h. unter den vorgegebenen Randbedingungen terminieren alle Prozesse.
515
Zwei-Phasen-Commit
1. Wahlphase: Der Koordinator veranlasst jedes beteiligte DBMS,
alle Journaleinträge, die die Transaktion betreffen, auf das physikalische Speichermedium zu schreiben (Prepare-Commit).
Jedes DBMS meldet dann an den Koordinator ”OK” (VoteCommit), wenn sie ein Commit durchführen können (bzw ”NOT
OK” (Vote-Abort), falls das nicht möglich ist).
2. Entscheidungsphase: Wenn der Koordinator von allen beteiligten
DBMS eine Antwort hat, dann schreibt er in sein eigenes physikalisches Journal seine Entscheidung: ”commit” (alle Antworten
”OK”) oder ”rollback”. Dann benachrichtigt der Koordinator alle
DBMS, die ”OK” gestimmt haben, über seine Entscheidung, die
dann entsprechend dieser Entscheidung verfahren müssen.
516
Drei-Phasen-Commit
1. Wahlphase: Der Koordinator sendet an alle beteiligten
DBMS die Nachricht Prepare.
Jeder Teilnehmer meldet dann an den Koordinator ”OK” (Vote-Commit), wenn er ein Commit
durchführen kann (bzw ”NOT OK” (Vote-Abort),
falls das nicht möglich ist).
517
Drei-Phasen-Commit
1. Wahlphase
2. Entscheidungsvorbereitungsphase: Der Koordinator
sammelt von allen beteiligten DBMS die Antworten.
Wenn alle Antworten ”OK” (Vote-Commit) waren,
sendet er an alle Teilnehmer Prepare-To-Commit.
Ansonsten sendet er an alle Teilnehmer ein ”rollback”
(Abort).
Jeder Teilnehmer, der mit Vote-Commit gestimmt
hat, wartet auf ein Prepare-To-Commit oder ein
Abort. Bei Abort entscheidet er auf Abbruch, ansonsten bestätigt er mit Ready-To-Commit.
518
Drei-Phasen-Commit
1. Wahlphase
2. Entscheidungsvorbereitungsphase
3. Entscheidungsphase: Der Koordinator sammelt alle Bestätigungen und entscheidet gegebenenfalls auf
Commit, das allen Teilnehmern mitgeteilt wird.
Die Teilnehmer warten auf die Entscheidung des Koordinators und führen dann die entsprechende Operation
aus.
519
Transaktionen auf Replikaten
Definition Serialisierbarkeit: Eine
verschachtelte
Durchführung von Transaktionen auf einer replizierten
Datenbank ist 1-Kopie-serialisierbar, wenn es
eine serielle Durchführung auf einer nicht-replizierten
Datenbank gibt, die den gleichen Effekt erzeugt wie
auf dem replizierten Datenbestand.
520
Synchronisation von Replikaten
ROWA-Verfahren (Read One, Write All): Bei ändernden
Operationen sollen alle Replikate synchron geändert werden. Das
ist ein hoher Aufwand. Eine Variante ist das ROWAA-Verfahren
(Read One, Write All Available), bei dem nur die
erreichbaren Replikate verändert werden.
Abstimmungsverfahren: Die schon besprochenen Abstimmungsverfahren gibt es in verschiedenen Varianten (Gewichtung der
Stimmen, statische und dynamische Quoren).
Absolutistische Verfahren: Hierzu gehört die PrimärkopieMethode.
521
Verteilte Verklemmung
Time-Out-Mechanismus: Diese Methode bricht eine wartende
Transaktion nach einer bestimmten Wartezeit ab.
Globaler Deadlock-Graph: Ein zentraler Koordinator vereinigt
die lokalen Deadlock-Graphen zu einem globalen DeadlockGraphen. (Phantom-Deadlock-Problem)
Zeitmarken als Anforderungs-Ordnung: Bei diesem Verfahren wird die totale Ordnung der Zeitmarken der Transaktionen
verwendet. Eine zu spät gekommene Transaktion bricht ab.
Globale Deadlock-Erkennung: Wenn
eine
Transaktion
blockiert wird, dann verschickt sie eine Nachricht, die eine Transaktions-Identifikation enthält, an die blockierende
Transaktion.
522
POET
• persistente Objekte
• Anfragen (Queries)
• Transaktionen (Transactions)
• Sperrmechanismen (Locking)
• Ereignisbehandlung (Event handling)
523
C++ wird als DDL und DML
POET-Schlüsselwörter und Kontrukte werden mit
Präprozessor ptxx
in Standard C++ übersetzt.
524
Persistente Klassen
Headerfile .hcd
#include <poet.hxx>
persistent class Rechteck
{
public:
Rechteck (double a, double b);
double
flaeche ();
double
umfang ();
void
show ();
private:
double
a;
double
b;
};
525
ptxx generiert DB und Files:
Rechteck.hxx
Rechteck.ptx
Rechteck.cxx
Persistente Klasse erben von PtObject.
Implementation der Klasse steht in Rechteck.C,
das den File Rechteck.hxx inkludiert.
526
File.ptx
RechteckAllSet
RechteckQuery
RechteckOndemand
RechteckIndirectLSet
Implementation in File.cxx.
Muß übersetzt und eingebunden werden.
527
Öffnen und Schließen der DB
InitPOET ("ClientName");
PtBase* pooDB;
PtBase::POET ()->GetBase
("ServerName", "DBname", pooDB);
PtBase::POET ()->UngetBase (pooDB);
DeinitPOET ();
528
Speichern eines Objekts
Rechteck*
p = new Rechteck (5, 6);
p->Assign (pooDB);
p->Store ();
delete p;
529
Finden von Objekten
RechteckAllSet alleRechtecke (pooDB);
Rechteck*
p;
for (long i (0);
alleRechtecke.Get (p, i, PtSTART) == 0; i++)
{
p->flaeche ();
alleRechtecke.Unget (p);
}
530
Finden von Objekten
i = 0;
while (alleRechtecke.Get (p, i, PtSTART) == 0
&& p->umfang () <= 10)
{
alleRechtecke.Unget (p);
i++;
}
if (p != (Rechteck*)NULL)
{
p-> show ();
alleRechtecke.Unget (p);
}
531
ondemand-Spezifikation
persistent class
{
};
Beschriftung
persistent class Rechteck
{
public:
ondemand<Beschriftung>
};
532
beschrift;
Belegung eine ondemands
Beschriftung* pB = new Beschriftung ("Hello");
pB->Assign (pooDB);
Rechteck*
pR = new Rechteck (3, 7);
pR->Assign (pooDB);
pR->beschrift.SetReference (pB);
pR->Store ();
533
Laden von der DB bei Bedarf
Beschriftung* pB;
pR->beschrift.Get (pB);
// Verwendung von pB
pR->beschrift.Unget (pB);
534
Abhängige Objekte (Dependents)
persistent class Rechteck
{
public:
depend GeoForm* geoForm;
};
535
Transiente Objekte
persistent class Rechteck
{
public:
void Activate ()
{
PtObject::Activate ();
// init my transients and other stuff
hilf = 42;
}
private:
transient int hilf;
};
536
Mengen (Sets)
persistent class Rechteck
{
public:
cset<GeoForm*> setOfGeoForms;
};
537
Methoden von Mengen
Append (PtObject*) fügt Elemente in die Menge ein.
Get (PtObjekt*, long, ...) setzt aktuelles Element
in Abhängigkeit von einem Offset und einer Startposition und stellt es über einen PtObject*-Zeiger zur
Verfügung. (Eine Menge hat immer ein ”aktuelles” Element.)
Delete () löscht das aktuelle Element.
Clear () löscht alle Elemente der Menge.
538
Mengenarten
cset ist eine kompakte Menge mit schnellem Zugriff, die
z.B. bei einem PC in ein Segment paßt.
lset ist eine große Menge, die beim PC die Segmentgröße
überschreiten und das ganze RAM benutzen kann.
Bei UNIX-Systemen steht der Hauptspeicher dafür zur
Verfügung.
hset ist eine riesige Menge, die den gesamten zur
Verfügung stehenden Plattenplatz einnehmen kann.
Der Zugriff ist hier natürlich am langsamsten.
539
Anfragen (Queries)
Alle Rechtecke mit a-Seite größer 5:
RechteckSet result;
RechteckAllSet alleRechtecke (pooDB);
RechteckQuery rQ;
rQ.Seta (5, PtGT);
alleRechtecke.Query (&rQ, &result);
540
Anfragen über Filter auf AllSet
RechteckAllSet alleRechtecke (pooDB);
RechteckQuery rQ;
rQ.Seta (5, PtGT);
alleRechtecke.SetFilter (&rQ);
// Auswertung von alleRechtecke
alleRechtecke.UnsetFilter ();
541
Komplexe Anfragen
persistent class Rechteck
{
public:
Dreieck* dreieck;
};
542
Komplexe Anfragen
Alle Rechtecke, die ein Dreieck haben,
dessen Seite c kleiner gleich 4 ist:
RechteckQuery rq;
DreieckQuery
dq;
dq.Setc (4, PtLTE);
rq.Setdreieck (&dq);
RechteckAllSet allR (pooDB);
RechteckSet result;
allR.Query (&rq, &result);
543
Komplexe Anfragen
persistent class Rechteck
{
public:
cset<Dreieck*> dreiecke;
};
544
Komplexe Anfragen
Alle Rechtecke, deren Seite a größer als 10 ist und die mindestens 2
Dreiecke haben, deren Seite c kleiner gleich 4 ist:
RechteckQuery rq;
rq.Seta (10, PtGT);
DreieckQuery
dq;
dq.Setc (4, PtLTE);
rq.Setdreiecke (2, PtGTE, &dq);
RechteckAllSet allR (pooDB);
RechteckSet result;
allR.Query (&rq, &result);
545
Sortieren des Resultats
Alle Rechtecke mit a-Seite 10
aufsteigend sortiert nach der b-Seite:
RechteckSet result;
RechteckAllSet alleRechtecke (pooDB);
RechteckQuery rQ;
rQ.Seta (10, PtEQ);
rQ.SortByb (PtASCENDING);
alleRechtecke.Query (&rQ, &result);
546
Komplexe Sortierung
Alle Rechtecke, deren Seite a größer als 10 ist und die ein Dreieck
haben, dessen Seite c kleiner gleich 4 ist, absteigend sortiert nach der
b-Seite des Dreiecks:
RechteckQuery rq;
rq.Seta (10, PtGT);
DreieckQuery
dq;
dq.Setc (4, PtLTE);
rq.Setdreieck (&dq);
rq.SortByb (PtDESCENDING);
RechteckAllSet allR (pooDB);
RechteckSet result;
allR.Query (&rq, &result);
547
Indizierung, Schlüssel
persistent class Rechteck
{
private:
char name[30];
int
nummer;
useindex RechteckIndex;
};
unique indexdef
{
name[[12]];
nummer;
};
RechteckIndex : Rechteck
548
Weitere POET-Mechanismen
• Locking
• Transaktionen
• Ereignisbehandlung
• Sicherheit
549
Locking
Lock-Spezifikationsobjekte der Klasse
PtLockSpec
Konstruktor hat zwei Argumente:
PtLockSpec (PtLK_..v.., Pt...)
550
Argument PtLK_..v..
PtLK_NONE
PtLK_READvDELETE
PtLK_READvWRITE
PtLK_WRITEvWRITE
PtLK_DELETEvWRITE
PtLK_DELETEvREAD
PtLK_EXCLUSIVE
551
Argument Pt...
PtFLAT
PtSHALLOW
PtNO_ONDEMAND
PtDEEP
552
Lock-Syntax
myAllSet.Get (&p, 1, PtStart, &lockSpezifikation);
// Es wird versucht das Lock zu setzen.
// p wird manipuliert.
p->Store ();
myAllSet.Unget (&p, &lockSpezifikation);
// Das Lock wird wieder freigegeben.
553
Typisches Beispiel
int
ret;
for (int i (0); i < maxVersuche; i++)
{
ret = myAllSet.Get (&p, 1, PtStart, &lockSpezifikation);
if (ret == 0) break;
else sleep (1);
}
if (ret == 0) // Lock war erfolgreich.
{
// p wird manipuliert.
p->Store ();
myAllSet.Unget (&p, &lockSpezifikation);
}
554
Bemerkungen
• Freigabe von Locks
• Serialisierung von Locks
• Verschachtelung von Locks
• Lock (PtLockSpec*)
Methode von PtObject,
PtObjectSet
PtOnDemand
und
• Unlock (PtLockSpec*)
• Query (PtQuery*, PtObjectSet*, PtLockSpec*)
555
MySQL – Dokumentation
http://www.mysql.com/documentation/
......../mysql/manual.html
556
MySQL-Installation unter SuSE
Installiere mit YaST:
mysql.rpm
mysqclnt.rpm
mysqllib.rpm
mysqbnch.rpm
mysqldev.rpm
(MySQL-Server)
(MySQL-Clients)
(Shared Libraries)
(Benchmark-Tests)
(C-Entwicklungsumgebung)
557
MySQL-Installation unter SuSE
root# /sbin/init.d/mysql start
Automatisch: /etc/rc.config
START_MYSQL="yes"
$ps -axu | grep mysql
MySQL-Server-User: /etc/my.cnf
user = mysql
558
Sicherheit
• Username (Betriebssystem-Login)
• Passwort ("")
• Hostname ("localhost")
$ mysql -u Username@Hostname -p
559
test_-Datenbanken
root# mysql -u root -p
Enter password: xxx
mysql> USE mysql;
mysql> DELETE FROM user WHERE user=’’;
mysql> FLUSH PRIVILEGES;
mysql> exit
560
Privilegien
Privileg Erklärung
für Tabellen und eventuell Spalten
SELECT Erlaubt Daten zu lesen.
INSERT Erlaubt Datensätze einzufügen.
UPDATE Erlaubt Datensätze zu ändern.
DELETE Erlaubt Datensätze zu löschen.
INDEX Erlaubt Indexe anzulegen oder zu löschen.
ALTER Erlaubt die Tabellenstruktur zu ändern.
561
Privilegien
Privileg
Erklärung
für Datenbanken, Tabellen, Indexe
und eventuell Spalten
USAGE
Erlaubt nichts.
CREATE
Erlaubt Anlegen von Datenbanken bzw Tabellen.
DROP
Erlaubt Löschen von Datenbanken bzw Tabellen.
WITH GRANT OPTION Erlaubt das Weitergeben von Privilegien.
REFERENCES
noch nicht in Verwendung
562
Privilegien
Privileg
Erklärung
für Dateizugriff
FILE
Erlaubt lokale Dateien zu lesen und zu schreiben.
für MySQL-Administration
PROCESS Erlaubt processlist und kill.
RELOAD
Erlaubt reload, refresh, flush-....
SHUTDOWN Erlaubt MySQL herunterzufahren.
563
Tabelle:
Attribut ↓
Host
User
Password
Db
Select_priv
Insert_priv
Update_priv
Delete_priv
Create_priv
Drop_priv
Grant_priv
References_priv
Index_priv
Alter_priv
Reload_priv
Shutdown_priv
Process_priv
File_priv
Table_name
Column_name
Grantor
Timestamp
Table_priv
Column_priv
user
db
host
tables_priv
columns_priv
abc
abc
123
—
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
—
—
—
—
—
—
abc
abc
—
abc
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
—
—
—
—
—
—
—
—
—
—
abc
—
—
abc
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
Y/N
—
—
—
—
—
—
—
—
—
—
abc
abc
—
abc
—
—
—
—
—
—
—
—
—
—
—
—
—
—
abc
—
abc
456
pri1
pri2
abc
abc
—
abc
—
—
—
—
—
—
—
—
—
—
—
—
—
—
abc
abc
—
456
—
pri2
564
Sicherheits-Tabellen
• user
• db
• host
• tables_priv
• columns_priv
• func
565
Granularität der Privilegien
MySQL-Ebene: Privileg gilt für alle Datenbanken und deren Tabellen und
Spalten (global).
SQL: GRANT/REVOKE ... ON *.* ...
Datenbank-Ebene: Privileg gilt für eine Datenbank und ihre Tabellen und
Spalten.
SQL: GRANT/REVOKE ... ON datenbankname.* ...
SQL: GRANT/REVOKE ... ON * ...
(alle Tabellen der aktiven Datenbank)
Tabellen-Ebene: Privileg gilt für eine Tabelle und ihre Spalten.
SQL: GRANT/REVOKE ... ON datenbankname.tabellenname ...
SQL: GRANT/REVOKE ... ON tabellenname ...
(aktive Datenbank)
Spalten-Ebene: Privileg gilt für angegebene Spalten einer Tabelle.
SQL: GRANT/REVOKE privilegx (spaltey, ...), ... ON tabellenname ...
566
Tabelle user
Steuert den Zugang zu MySQL und verwaltet die globalen Privilegien.
Für root sind diese defaultmäßig auf ”Y” gestellt.
mysql> GRANT USAGE ON *.* TO Oskar@Rechner IDENTIFIED BY ’geheim’;
mysql> GRANT ALL ON *.* TO Oskar@Rechner WITH GRANT OPTION;
(ALL umfasst nicht das Privileg GRANT.)
mysql> REVOKE DELETE ON *.* FROM Oskar@Rechner;
mysql> REVOKE GRANT OPTION ON *.* FROM Oskar@Rechner;
mysql> DELETE FROM user where User=’Oskar’;
567
Tabelle db
Steuert den Zugang zu einer Datenbank und verwaltet die
Privilegien für die einzelnen Datenbanken.
mysql> GRANT ALL ON etoto.* TO Oskar WITH GRANT OPTION;
568
Tabelle host
Die Tabelle host kommt nur zum Einsatz, wenn das Feld Host in der
Tabelle db leer ist. Dann wird in host gesucht, ob es ein passendes
Host/Db-Paar gibt, und, falls es ein Paar gibt, werden die Privilegien
aus db und host logsich mit AND verknüpft. Das Resultat ergibt
dann die erlaubten Privilegien.
Die Tabelle host wird nicht durch die Kommandos GRANT und
REVOKE berührt.
mysql> GRANT ALL ON etoto.* TO Oskar@amadeus;
mysql> UPDATE db SET Host=’’
>
WHERE User=’Oskar’ AND Host=’amadeus’;
mysql> INSERT INTO host (Host, Db, Select_priv)
>
VALUES (’amadeus’, ’etoto’, ’Y’);
569
Tabelle tables_priv
Steuert den Zugriff auf einzelne Tabellen.
mysql> GRANT SELECT, UPDATE ON etoto.geld TO Oskar;
Die Tabelle tables_priv verwaltet die Rechte als Mengen (SET).
570
Tabelle columns_priv
Steuert den Zugriff auf einzelne Spalten.
mysql> GRANT SELECT (betrag), UPDATE (betrag)
>
ON etoto.geld TO Oskar;
Die Tabelle cloumns_priv verwaltet die Rechte ebenfalls
als Mengen (SET).
571
Tabelle func
Ermöglicht die bisher noch nicht dokumentierte Verwaltung von benutzerdefinierten Funktionen (UDF, user
defined function).
572
Werkzeuge
mysql> SHOW GRANTS FOR Oskar;
mysql> SHOW GRANTS FOR Oskar@amadeus;
$ mysqlaccess Oskar etoto
$ mysql_setpermission -u root
573
Systemsicherheit
• Kann sich jemand unberechtigterweise als root oder SystemAdministrator auf dem System einloggen?
• Sind die Logging-Dateien abgesichert? Dort finden sich Passwörter
im Klartext.
• Sind Script-Dateien, in denen Passwörter im Klartext stehen, ausreichend abgesichert?
• Der MySQL-Server darf nicht unter root laufen, sondern unter
einem speziellen Benutzer, also etwa mysql.
• Oft ist es nicht nötig, dass MySQL über den Port 3306 von außen ansprechbar ist. Dann kann man diesen Port mit FirewallMechanismen sperren.
574
Einrichten einer Datenbank
mysql> CREATE DATABASE Datenbankname;
mysql> GRANT ALL ON Datenbankname.* TO DatenbanknameAdmin
>
IDENTIFIED BY ’Passwort’ WITH GRANT OPTION;
mysql> CREATE DATABASE etoto;
mysql> GRANT ALL ON etoto.* TO etotoadmin
>
IDENTIFIED BY ’geheim’ WITH GRANT OPTION;
575
Anlegen eines Benutzers
mysql> GRANT USAGE ON etoto.* TO Oskar@Rechner
>
IDENTIFIED BY ’klose’;
mysql> GRANT USAGE ON *.* TO ’’@Rechner;
576
Ändern des Passworts
mysql> GRANT ... IDENTIFIED BY neuesPasswort
$ mysqladmin -u Oskar -p password neuesPasswort
Enter password: altesPasswort
577
Backup einer Tabelle
mysql> BACKUP TABLE Tabelle TO ’Verzeichnis’;
mysql> RESTORE TABLE Tabelle FROM ’Verzeichnis’;
mysql> BACKUP TABLE S TO ’/tmp/supaBackups’;
mysql> DROP TABLE S;
mysql> RESTORE TABLE S FROM ’/tmp/supaBackups’;
578
Backup einer Datenbank
$ mysqldump -u DBloginname -p --opt Datenbankname > Backupdatei
$ mysql -u DBloginname -p Datenbankname <
Backupdatei
oder
mysql> CREATE DATABASE Datenbankname;
mysql> USE Datenbankname;
mysql> SOURCE Backupdatei;
579
Datentyp
TINYINT
SMALLINT
MEDIUMINT
INT, INTEGER
BIGINT
FLOAT
DOUBLE, REAL
DECIMAL(p,s)
NUMERIC, DEC
DATE
TIME
DATETIME
YEAR
TIMESTAMP
CHAR(n)
VARCHAR(n)
TINYTEXT
TEXT
MEDIUMTEXT
LONGTEXT
TINYBLOB
BLOB
MEIUMBLOB
LONGBLOB
ENUM
SET
Erklärung
8-Bit-Integer
16-Bit-Integer
24-Bit-Integer
32-Bit-Integer
64-Bit-Integer
8-stellige Fließkommazahl
16-stellige Fließkommazahl
Fließkommazahl als Zeichenkette
Datum in der Form 2002-07-27
Zeit in der Form 14:31:45
Kombination in der Form 2002-07-27 14:31:45
Jahreszahl 1900 bis 2155
Kombination in der Form 20020727143145
Zeichenkette mit vorgegebener Länge, maximal n = 255
Zeichenkette mit variabler Länge n < 256
wie VARCHAR(255)
Zeichenkette mit variabler Länge, maximal 216 − 1
Zeichenkette mit variabler Länge, maximal 224 − 1
Zeichenkette mit variabler Länge, maximal 232 − 1
Binärdaten mit variabler Länge, maximal 28 − 1
Binärdaten mit variabler Länge, maximal 216 − 1
Binärdaten mit variabler Länge, maximal 224 − 1
Binärdaten mit variabler Länge, maximal 232 − 1
Aufzählung von maximal 65535 Zeichenketten (1 oder 2 Byte)
Menge von maximal 63 Zeichenketten (1 bis 8 Byte)
580
Client / Server
• Web-Technologien
• Client-seitige Applikationsprogramme
581
Web-Technologien
• Browser
• Webserver
• Applikationsserver
• Datenbankserver
• Fileserver
582
Web-Technologien
• statische HTML-Seite
• Applets
• SSI
• CGI
• Server-API
• Server-Skripte
– PHP
– ASP
– JavaScript
– JSP
• Servlets
583
Datenbanksystem db4o
• Installation
• Öffnen, Schließen einer Datenbank
• Speichern von Objekten
• Finden von Objekten
• Aktualisieren von Objekten
• Löschen von Objekten
• NQ – Native Anfragen
• SODA Query API
584
Datenbanksystem db4o
• Strukturierte Objekte
• Felder und Collections
• Vererbung
• Tiefe Graphen und Aktivierung
• Indexe
• Transaktionen
• Client/Server
• Identifikatoren
585
Datenbanksystem db4o
Es fehlt noch:
• SODA-Auswertung
• Konfiguration
• Enhancement
• Replication
586
Installation
db4o-8.0.184.15484-all-java5.jar
(bei uns db4o.jar)
587
Anwendung und DB
DB
TAXI :String
Anwendung
main (arg :String[*])
588
import
Öffnen, Schließen
com.db4o.*;
com.db4o.ObjectContainer
db
= com.db4o.Db4oEmbedded.openFile (
Db4oEmbedded.newConfiguration (),
"taxi.db4o");
db.close ();
try { ... } finally { db.close (); }
589
Bemerkungen
1. ObjectContainer repräsentiert Datenbank oder
Client-Verbindung zu einem db4o-Server.
2. Jeder ObjectContainer besitzt eine Transaktion,
die beim Öffnen beginnt. Mit commit () oder
rollback () wird die nächste Transaktion gestartet.
Die letzte Transaktion wird durch close () beendet.
3. Jeder ObjectContainer verwaltet seine eigenen Referenzen zu gespeicherten Objekten.
4. com.db4o.ext.ExtObjectContainer
590
Speichern von Objekten
Chauffeur
Name :String
Alter :int
591
Speichern von Objekten
Chauffeur
chauffeur
= new Chauffeur ("Ballack", 29);
db.store (chauffeur);
592
Finden von Objekten
Chauffeur
chauffeur = new Chauffeur (null, 29);
List<Chauffeur>
resultat = db.queryByExample (chauffeur);
for (Object o : resultat)
{
System.out.println (o);
}
oder:
List<Chauffeur>
resultat = db.query (Chauffeur.class);
List<Chauffeur>
resultat = db.queryByExample (
new Chauffeur (null, 0));
List<Chauffeur>
resultat = db.queryByExample (
new Chauffeur ("Kahn", 0));
593
Aktualisierung von Objekten
List<Chauffeur>
resultat
= db.queryByExample (new Chauffeur ("Ballack", 0));
Chauffeur
gefunden = resultat.get (0);
gefunden.setAlter (gefunden.getAlter () + 1);
db.store (gefunden); // Aktualisierung!
594
Löschen von Objekten
List<Chauffeur>
resultat
= db.queryByExample (new Chauffeur ("Ballack", 0));
Chauffeur
gefunden = resultat.get (0);
db.delete (gefunden);
------------------------------------------------------//List<Object> resultat = db.query (Object.class);
List<Object>
resultat = db.queryByExample (new Object ());
for (Object o : resultat)
{
db.delete (o);
}
595
NQ – Native Anfragen
List<Chauffeur>
chauffeure
= db.query (new Predicate<Chauffeur> ()
{
public boolean match (Chauffeur chauffeur)
{
return chauffeur.getAlter () > 30;
}
});
596
SODA Query API
SODA ist die low-level Anfrage-API.
// Finde alle Chauffeure jünger als 30 Jahre:
Query query = db.query ();
query.constrain (Chauffeur.class);
query.descend ("alter")
.constrain (new Integer (30))
.smaller ();
List resultat = query.execute ();
597
Strukturierte Objekte
Taxi
Modell :String
Nummer :String
Chauffeur
Name :String
Alter :int
598
Speichern von Strukturen
Chauffeur
chauffeur = new Chauffeur ("Ballack", 31);
db.store (chauffeur);
// Chauffeur ist jetzt schon in der Datenbank.
Taxi taxi = new Taxi ("BMW", "13", chauffeur);
db.store (taxi);
chauffeur = new Chauffeur ("Kahn", 39);
taxi = new Taxi ("VW", "1", chauffeur);
db.store (taxi);
// Chauffeur ist hiermit auch in der Datenbank.
db.store (new Taxi ("Mercedes", "32", new Chauffeur ("Gomez", 22)));
599
QBE-Anfrage
Chauffeur
prototypChauffeur
= new Chauffeur ("Gomez", 0);
Taxi prototypTaxi
= new Taxi (null, null, prototypChauffeur);
List<Taxi> resultat
= db.queryByExample (prototypTaxi);
600
NQ-Anfrage
List<Taxi> resultat = db.query (
new Predicate<Taxi> ()
{
public boolean match (Taxi taxi)
{
return taxi.getChauffeur ().getName ()
.equals ("Gomez");
}
});
601
SODA-Anfrage
Query query = db.query ();
query.constrain (Taxi.class);
query.descend ("aChauffeur")
.descend ("name").constrain ("Gomez");
List
resultat = query.execute ();
602
SODA-Anfrage interessant
Query taxiQuery
= db.query ();
taxiQuery.constrain (Taxi.class);
taxiQuery.descend ("modell").constrain ("BMW");
Query chauffeurQuery
= taxiQuery.descend ("aChauffeur");
List
resultat = chauffeurQuery.execute ();
603
Aktualisieren von Strukturen
List<Taxi> resultat
= db.queryByExample (new Taxi ("BMW", null, null));
Taxi taxi = resultat.get (0);
List<Chauffeur>
res
= db.queryByExample (new Chauffeur ("Gomez", 0));
Chauffeur
chauffeur = res.get (0);
taxi.setChauffeur (chauffeur);
db.store (taxi); // Taxi wird zurückgespeichert.
604
Aktualisieren von Strukturen
List<Taxi> resultat
= db.queryByExample (new Taxi ("BMW", null, null));
Taxi taxi = resultat.get (0);
taxi.getChauffeur ().setName ("Strauss-Kahn");
db.store (taxi); // Taxi wird zurückgespeichert.
605
Felder und Collections
Fahrt
Beginn :Date
Ende :Date
Entfernung :double[*]
*
Taxi
Chauffeur
Modell :String
Nummer :String
erzeugeFahrt ()
Name :String
Alter :int
606
Felder und Collections
• Felder sind keine Objekte der Datenbank.
• Collections sind eigene Objekte der Datenbank.
607
QBE-Anfrage
Chauffeur
prototypChauffeur
= new Chauffeur ("Klose", 0);
Fahrt prototypFahrt
= new Fahrt (null, null, null, prototypChauffeur);
List<Fahrt> resultat = db.queryByExample (prototypFahrt);
608
NQ-Anfrage
List<Fahrt> resultat = db.query (new Predicate<Fahrt> ()
{
public boolean match (Fahrt fahrt)
{
double
v = fahrt.getEntfernung ()[0]
/ ((fahrt.getEnde ().getTime ()
- fahrt.getBeginn ().getTime ())
/1000/60/60);
return v < 40.0 || v > 80.0;
}
});
609
SODA-Anfrage
Query fahrtQuery = db.query ();
fahrtQuery.constrain (Fahrt.class);
fahrtQuery.descend ("aChauffeur")
.descend ("name")
.constrain ("Klose");
List resultat = fahrtQuery.execute ();
610
Vererbung
Fahrt
Beginn :Date
Ende :Date
Entfernung :double[*]
*
Taxi
Chauffeur
Modell :String
Nummer :String
erzeugeFahrt ()
Name :String
Alter :int
LastTaxi
Aufschlag :double
erzeugeFahrt ()
611
Vererbung
• db.query (X.class)
• public boolean match (X x) { }
612
Tiefe Graphen, Aktivierung
ob0
ob1
ob2
ob3
ob4
ob9
ob8
ob7
ob6
ob5
...
613
Tiefe Graphen, Aktivierung
Taxi
Modell :String
Nummer :String
anzFahrten :int
erzeugeFahrt ()
Fahrt
Beginn :Date
Ende :Date
Entfernung :double[*]
nextFahrt :Fahrt
Chauffeur
Name :String
Alter :int
614
Kaskadierte Aktivierung
db.activate (objekt, tiefe);
oder
EmbeddedConfiguration
conf
= Db4oEmbedded.newConfiguration ();
conf.common ().objectClass (Fahrt.class)
.cascadeOnActivate (true);
db = Db4oEmbedded.openFile (conf, "taxi.db4o");
615
Transparente Aktivierung
EmbeddedConfiguration
conf
= Db4oEmbedded.newConfiguration ();
conf.common ().add (new TransparentActivationSupport ());
db = Db4oEmbedded.openFile (conf, "taxi.db4o");
616
Transparente Aktivierung
com.db4o.activation.ActivationPurpose
READ
WRITE
<<interface>>
com.db4o.ta.Activatable
bind (:Activator)
activate (:ActivationPurpose)
Fahrt
:Activator {transient}
Beginn :Date
Ende :Date
Entfernung :double[*]
617
Chauffeur
Name :String
Alter :int
Transparente Aktivierung
public Typ getX ()
{
activate (ActivationPurpose.READ);
return x;
}
618
Transparente Persistenz
EmbeddedConfiguration
conf
= Db4oEmbedded.newConfiguration ();
conf.common ().add (new TransparentPersistenceSupport ());
db = Db4oEmbedded.openFile (conf, "taxi.db4o");
619
Transparente Persistenz
public void setX (Typ x)
{
activate (ActivationPurpose.WRITE);
this.x = x;
}
620
Indexe
db.close ();
EmbeddedConfiguration
conf
= Db4oEmbedded.newConfiguration ();
conf.common ().objectClass (Chauffeur.class)
.objectField ("name")
.indexed (true);
db = Db4oEmbedded.openFile (conf, "taxi.db4o");
Wirkt sich drastisch bei QBE- und SODA-Anfragen aus,
weniger bei NQ-Anfragen.
621
Transaktionen
ObjectContainer
db = Db4oEmbedded.openFile (
Db4oEmbedded.newConfiguration (), "Datei");
db.commit ();
db.rollback ();
db.ext ().refresh (objekt, Integer.MAX_VALUE);
db.close ();
Isolationsniveau: READ COMMITTED
622
Transaktionen
Wie stehts mit Locks?
623
Embedded Server
ObjectServer
server = Db4oClientServer.openServer (
Db4oClientServer.newServerConfiguration (), "taxi.db4o", 0);
try
{
ObjectContainer
ct1 = server.openClient ();
ObjectContainer
ct2 = server.openClient ();
// tu was mit den Containern bzw. Clients
ct1.close ();
ct2.close ();
}
finally
{
server.close ();
}
624
Embedded Server
container.ext ().refresh (objekt, tiefe);
625
Verteiltes System
ObjectServer
server = Db4oClientServer.openServer (
Db4oClientServer.newServerConfiguration (), "taxi.db4o", 0xdb40); // Port >
try
{
server.grantAccess ("user1", "password1");
server.grantAccess ("user2", "password2");
ObjectContainer
ct1 = Db4oClientServer.openClient (
"localhost", 0xdb40, "user1", "password1");
ObjectContainer
ct2 = Db4oClientServer.openClient (
"localhost", 0xdb40, "user2", "password2");
// tu was mit den Containern bzw. Clients
ct1.close ();
ct2.close ();
}
finally { server.close (); }
626
public synchronized void
runServer ()
{
ObjectServer
server = Db4oClientServer.openServer (
Db4oClientServer.newServerConfiguration (), "taxi.db4o", 0xdb40);
try
{
server.grantAccess ("stopUser", "stopPassword");
server.grantAccess ("user1", "password1");
server.grantAccess ("user2", "password2");
server.ext ().configure ().clientServer ().setMessageRecipient (this);
// this.processMessage erhält die Botschaften (insbesondere stop)
Thread.currentThread ().setName (this.getClass ().getName ());
// um die Thread in einem Debugger zu identifizieren
Thread.currentThread ().setPriority (Thread.MIN_PRIORITY);
// server hat eigene Thread. Daher genügt hier ganz niedrige Prio.
try
{
while (!isStop ())
{
this.wait ();
// Warte, bis du gestoppt wirst.
}
}
catch (InterruptedException e) { e.printStackTrace (); }
}
finally
{
server.close ();
}
}
627
public
Klasse StartServer
StartServer (boolean stop) { setStop (stop); }
private boolean
stop;
public boolean isStop () { return stop; }
public void setStop (boolean stop) { this.stop = stop; }
628
Klasse StartServer
public void processMessage (MessageContext mc, Object message)
{
if (message instanceof StopServer)
{
close ();
}
}
public synchronized void close ()
{
setStop (true);
this.notify ();
}
public static void
main (String[] arg)
{
new StartServer (false).runServer ();
}
629
Server stoppen
class StopServer {}
ObjectContainer
cont = null;
try
{
cont = Db4oClientServer.openClient (
DB.HOST, DB.PORT, "stopUser", "stopPassword");
}
catch (Exception e ) { e.printStackTrace (); }
if (cont != null)
{
MessageSender sender = cont.ext ().configure ().clientServer ()
.getMessageSender ();
sender.send (new StopServer ());
cont.close ();
}
630
long
Interne ID
id = objectContainer.ext ().getID (ob);
Object
ob = objectContainer.ext ().getByID (id);
objectContainer.ext ().activate (ob, tiefe);
631
Unique Universal ID (UUID)
Configuration conf = Db4o.newConfiguration ();
conf.generateUUIDs (ConfigScope.DISABLED);
oder
conf.generateUUIDs (ConfigScope.GLOBALLY);
oder
conf.generateUUIDs (ConfigScope.INDIVIDUALLY);
conf.objectClass (Taxi.class).generateUUIDs (true);
632
Unique Universal ID (UUID)
Db4oUUID uuid
= objectContainer.ext ()
.getObjectInfo (ob).getUUID ();
Object
ob
= objectContainer.ext ().getByUUID (uuid);
objectContainer.ext ().activate (ob, tiefe);
633
Viele Objekte, Lazy Query
conf.common ().queries ().evaluationMode (
QueryEvaluationMode.LAZY);
634
Defragmentierung
com.db4o.defragment.Defragment.defrag (
Datenbankdateiname);
635
Maximale Datenbankgröße
Blockgröße von 1 bis 127
entspricht
maximaler DB-Größe von 2 bis 254 GB.
conf.file ().blocksize (8);
ergibt eine maximale DB-Größe von 16 GB.
636
NoSQL
• no SQL, not only SQL, non-relational
• Flexibles Datenmodell
• Skalierung
637
Geschichte
• Google (2006): BigTable reasearch
• Amazon (2007): Dynamo research
638
Charakteristika
• abertausend Benutzer
• low latency
• immer online
• hohe Varianz der Daten
• schnell adaptierbar an geänderte Anforderungen
• Velocity, Variety, Volume, Complexity
639
Applikation
Scale-up
one
growing
server
640
Applikation
Server 1
Scale-out
Server 2
Server 3
641
Server ...
RDB versus NoSQL
• RDB: Schema notwendig
Änderung des Schemas schwierig
• NoSQL: ”schemalos” bzw.
Änderung eines eventuellen Schemas leicht
642
NoSQL-Datenmodell-Typen
Daten-Modell
Key-Value-Store
Document-Store
Column-Family-Store
Graph-Store
Beispiel DB
Riak
MongoDB
Cassandra
Neo4J
643
Integrations-DB
App1
Appx
SQL
SQL
RDB
SQL
SQL
App2
Appn
644
Applikations-DB
SOApp1
SOApp2
App1
App2
Appx
Appn
{as service}
{as service}
{as service}
{as service}
DB1
DB2
DBx
DBn
645