Zusammenfassung

Einführung in Datenbanken (DBS1)
Andreas Blunk
März 2006, Berlin
Der vorliegende Text ist eine Zusammenfassung der wichtigsten Themen aus der Vorlesung Einführung in Datenbanken (DBS1) im März 2006. Ich habe die Zusammenfassung zur Prüfungsvorbereitung benutzt und nach der Klausur den Abschnitt
Prüfungsfragen ergänzt. Dieser enthält alle Fragen aus der Klausur, die ich mir noch
merken konnte. Diese Fragen können wirklich so gestellt werden.
Inhaltsverzeichnis
1. Das Relationale Modell
1.1. Strukturelle Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
2. Entwurf relationaler Datenbanken
2.1. Funktionale Abhängigkeiten (FD) . . . .
2.1.1. Logische Folgerbarkeit . . . . . .
2.1.2. Die Hülle . . . . . . . . . . . . .
2.1.3. Formale Definition des Schlüssels
2.1.4. Armstrong-Kalkül . . . . . . . .
2.2. Normalisierung . . . . . . . . . . . . . .
.
.
.
.
.
.
5
5
5
5
6
6
7
.
.
.
.
.
.
.
.
.
.
.
8
8
8
8
9
9
9
9
9
10
10
10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Relationale Anfragesprachen
3.1. Operationen der Relationalen Algebra . . . . . . .
3.1.1. Grundoperationen . . . . . . . . . . . . . .
3.1.2. Weitere Operationen . . . . . . . . . . . . .
3.2. Logik als Anfragesprache - der Relationenkalkül . .
3.2.1. Well-Formed-Formula (WFF) . . . . . . . .
3.2.2. Interpretation von WFFs . . . . . . . . . .
3.2.3. Abbildung von WFF auf Wahrheitswerte W
3.2.4. Das Domänenkalkül . . . . . . . . . . . . .
3.2.5. RA nach DRC (am Beispiel) . . . . . . . .
3.2.6. Beschränkte Variablen in WFFs . . . . . .
3.2.7. Sichere (safe) DRC-Formeln . . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
4. Anfragebearbeitung
4.1. Gesetze zur Optimierung . . . . . . . . . . . .
4.1.1. Joins und Produkte . . . . . . . . . .
4.1.2. Projektion und Selektion . . . . . . .
4.1.3. Selektion und Join . . . . . . . . . . .
4.1.4. Selektion und Vereinigung / Differenz
4.1.5. Projektion und Join . . . . . . . . . .
4.1.6. Projektion und Vereinigung . . . . . .
4.1.7. Selektion und Produkt . . . . . . . . .
4.1.8. Umschreiben eines Produktes . . . . .
4.2. Beispiel für eine Optimierung . . . . . . . . .
4.3. Nested-Loop-Join . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
11
12
12
12
12
12
13
13
13
5. Speicherstrukturen
14
5.1. B-Baum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. B*-Baum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Transaktionskonzept
15
6.1. 2-Phasen-Sperrprotokoll (2PL) . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Fehlererholung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. XML
17
7.1. DTD für ein Adressbuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Die Verwendung von ID und IDREF . . . . . . . . . . . . . . . . . . . . . 17
A. Algorithmen
A.1. Die Hülle (bezüglich einer Attributmenge)
A.2. Schlüsselkandidaten bestimmen . . . . . .
A.3. Basis bzw. minimale Überdeckung . . . .
A.4. Lossless-Join-Zerlegung . . . . . . . . . .
A.5. Dekomposition . . . . . . . . . . . . . . .
A.6. Synthese . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
21
22
24
24
B. Prüfungsfragen
B.1. ER-Modell . . . . . . . . . .
B.2. Funktionale Abhängigkeiten
B.3. Relationale Algebra . . . .
B.4. SQL . . . . . . . . . . . . .
B.5. B-Baum . . . . . . . . . . .
B.6. XML . . . . . . . . . . . . .
B.7. Transaktionen . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
26
27
27
28
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1. Das Relationale Modell
1. Das Relationale Modell
1.1. Strukturelle Definitionen
Die Domäne ist der Wertebereich einer Relation. Man unterscheidet: intensionale (Integer, Real, String) und extensionale (explizite Auflistung der Werte, z.B. Farbe = rot,
grün, blau) Domänen.
Eine Relation ist eine Teilmenge des Kreuzproduktes von Domänen, d.h.
R ⊆ D1 × D2 × . . . × Dn
Ein Element einer Relation wird als Tupel bezeichnet.
Beispiel:
• Domäne D1 = { rot, grün, blau, gelb }
• Domäne D2 = { VW, Opel, Mercedes }
• Relation R1 = { (VW,grün), (Opel,rot) }
• ein Tupel von R1 ist (VW,grün)
Die sog. Spalten“ einer Relation werden als Attribute bezeichnet. Diese müssen in”
nerhalb einer Relation eindeutig sein. Beispiel: Farbe, Autotyp
Eine Relation ist definiert durch ein Relationenschema
R(A1 : D1 , . . . , An : Dn )
bestehend aus dem Relationennamen R, den Attributnamen Ai und
den Domänennamen Di .
Die Extension einer Relation ist die Menge der momentanen Instanzen. Sie muss
dem Relationenschema genügen und kann sich durch Operationen (Einfügen, Löschen)
ändern.
Beispiel:
• Domäne ID Typ = { rot, grün, blau, gelb }
• Domäne Farbpalette = { rot, grün, blau, gelb }
• Domäne Autotypen = { VW, Opel, Mercedes }
• Relationenschema
Auto(ID : ID Typ, Farbe : Farbpalette, Typ : Autotyp)
3
1. Das Relationale Modell
Ein Datenbankschema ist die Menge aller Relationenschemata.
Eine Relationale Datenbank ist ein Datenbankschema und alle Extensionen der zugehörigen Relationen.
Jedes Tupel kann als Abbildung
µ : {A1 , . . . , An } → D1 ∪ . . . ∪ Dn
aufgefasst werden mit
µ(Ai ) → d ∈ Di
Beispiel:
• µ1 = (007, grün, Mercedes) ∈ R
• µ1 (ID) = 007
Sei S ⊆ {A1 , . . . , An } Teilmenge des Relationenschemas R. Verallgemeinert man den Abbildungsgedanken für Tupel, so bezeichnet µ[S] die Werte des Tupels µ in den Attributen
Ak ∈ S.
Beispiel: µ1 [ID,Typ] = (007, Mercedes)
Ein Schlüsselkandidat (bzw. Schlüssel) von R ist jede Teilemenge K ⊆ {A1 , . . . , An }
der Attributmenge von R mit:
• Eindeutigkeit:
Für je zwei Tupel µ1 , µ2 gilt: µ1 6= µ2 ⇒ µ1 [K] 6= µ2 [K]
• Minimalität:
Es gibt kein K 0 ⊂ K, das diese Eigenschaft besitzt.
Der Primärschlüssel ist ein ausgezeichneter Schlüsselkandidat (Entwurfsentscheidung).
Ein Superschlüssel ist eine Teilmenge S ⊆ {A1 , . . . , An } der Attributmenge von R,
die einen Schlüsselkandidaten K enthält, d.h. K ⊆ S (jeder Schlüsselkandidat ist auch
Superschlüssel).
Ein Fremdschlüssel ist wie folgt definiert:
• Seien R(A1 , . . . , An ) und S(B1 , . . . , Bn ) zwei Relationenschemata.
• Sei F ⊆ {B1 , . . . , Bn } ein Schlüsselkandidat für S.
• Ist F ⊆ {A1 , . . . , An }, so heißt F Fremdschlüssel von S in R.
4
2. Entwurf relationaler Datenbanken
2. Entwurf relationaler Datenbanken
Wie können relationale DB-Schemata ohne Datenredundanz entworfen werden? Welche
Datenabhängigkeiten können auftreten?
2.1. Funktionale Abhängigkeiten (FD)
Sei R(A1 , . . . , An ) ein Relationenschema.
Sei X, Y ⊆ {A1 , . . . , An }.
Y ist genau dann funktional abhängig von X
(X → Y )
wenn für alle µ1 , µ2 in der Extension von R gilt:
µ1 [X] = µ2 [X] ⇒ µ1 [Y ] = µ2 [Y ]
Funktionale Abhängigkeiten sind Aussagen über die Semantik der Daten (Meta- Informationen), die aus der Anwendungswelt abgeleitet sind. Sie sind nicht beweisbar und
nicht aus einer aktuellen Extension ableitbar.
Aber: Funktionale Abhängigkeiten schränken die möglichen Instanzen in einer Extension
ein!
Hinweise:
• (X → Y ) wird auch als X dominiert Y gelesen
• (XY → ZW ) ist gleichbedeutend mit (XY → Z) und (XY → W )
2.1.1. Logische Folgerbarkeit
Sei F eine Menge von funktionalen Abhängigkeiten über R.
Eine FD (X → Y ) folgt logisch aus F
F |= X → Y
wenn für jede Instanz r der Extension von R gilt
r erfüllt alle FDs f ∈ F ⇒ r erfüllt X → Y
2.1.2. Die Hülle
Die Hülle von F ist definiert durch
F + := {X → Y | F |= X → Y }
Lemma:
F |= X → Y ⇔ X → Y ∈ F +
5
2. Entwurf relationaler Datenbanken
2.1.3. Formale Definition des Schlüssels
Sei R(A1 , . . . , An ) ein Relationenschema und F eine Menge von FDs über R.
• X ⊆ {A1 , . . . , An } heißt Superschlüssel, wenn gilt X → {A1 , . . . , An } ∈ F +
• X heißt Schlüsselkandidat, wenn X minimal mit der genannten Eigeschaft ist
(also keine echte Teilmenge X 0 ⊂ X diese Eigenschaft erfüllt).
2.1.4. Armstrong-Kalkül
Deduktionsregeln (Herleitungsregeln) dienen der Ableitung neuer FDs aus bereits
bekannten.
• Vollständig, wenn alle logisch folgerbaren FDs auch hergeleitet werden können.
• Korrekt, wenn nur logisch folgerbare FDs hergeleitet werden können und keine
falschen FDs.
Das Armstrong-Kalkül ist ein logisches Kalkül und besteht aus
• einer Menge von Axiomen AX
• einem Herleitungsbegriff `, beschrieben durch eine Menge von Deduktionsregeln
Die konkreten Axiome und Deduktionsregeln des Armstrong-Kalkül fehlen hier.
Lemma:
F ` X → Y ⇔ Y ⊆ XF+
6
2. Entwurf relationaler Datenbanken
2.2. Normalisierung
Eine Relation ist in 1. Normalform, wenn alle Attribute atomare Wertebereiche haben.
Das heißt zusammengesetzte, mengenwertige oder geschachtelte Wertebereiche sind nicht
erlaubt.
Eine Relation ist in 2. Normalform, wenn alle Nichtschlüsselattribute voll funktional von jedem Schlüsselkandidaten abhängen. Das bedeutet sie dürfen nicht von einer
Teilmenge eines Schlüsselkandidaten abhängen, sondern nur vom ganzen Schlüsselkandidaten.
Eine Relation ist in 3. Normalform, wenn für alle FD X → A mit A ∈
/ X gilt:
A ist Schlüsselattribut oder X ist ein Superschlüssel für A.
Diese Definition für die 3. Normalform wurde direkt aus den Vorlesungsfolien entnommen, da es teils widersprüchliche Definitionen in der externen Literatur und den Praktikumsfolien gab. Die obige Definition sollte also die korrekte sein.
Eine Relation ist in Boyce-Codd-Normalform, wenn alle Attribute nur direkt von
einem (oder mehreren) Schlüsselkandidaten abhängen.
7
3. Relationale Anfragesprachen
3. Relationale Anfragesprachen
3.1. Operationen der Relationalen Algebra
3.1.1. Grundoperationen
• Vereinigung
• Differenz
• Kartesisches Produkt
• Projektion
• Selektion
3.1.2. Weitere Operationen
• Durchschnitt
• Division (Simulation des All-Quantor)
• Join (mit Condition)
• Natural-Join
• Semi-Join
8
3. Relationale Anfragesprachen
3.2. Logik als Anfragesprache - der Relationenkalkül
3.2.1. Well-Formed-Formula (WFF)
• jede atomare Formel
• wenn F1 und F2 WFFs sind, dann auch F1 ∧ F2 und F1 ∨ F2
• wenn F eine WFF ist, dann auch (F ) und ¬F
• wenn F eine WFF ist und x ∈ F V (F ), dann auch ∃x(F ) und ∀x(F )
F heißt geschlossen, wenn F V (F ) = ∅. Sonst heißt F offen.
3.2.2. Interpretation von WFFs
• Prädikate p = Relationen mit Namen P
• Konstanten sind Werte der jeweiligen Domäne
• θ sind ausführbare arithmetische Vergleiche (wie op)
3.2.3. Abbildung von WFF auf Wahrheitswerte W
W : WFF ⇒ {true, false}
Definition:
• W (p(c1 , . . . , cn )) := true, wenn (c1 , . . . , cn ) ∈ p, sonst false
• W (c op d) := Ergebnis des Vergleichs“ mit op ∈ {=, 6=, ≥, >, ≤, <}
”
• W (F1 ∧ F2 ) = W (F1 ) ∧ W (F2 )
• W (F1 ∨ F2 ) = W (F1 ) ∨ W (F2 )
• W (¬F ) = ¬W (F )
• W (∃x(F ) = W (F (x/d1 )) ∨ . . . ∨ W (F (x/dn )) mit di aus der Domäne {di , . . . , dn }
• W (∀x(F ) = W (F (x/d1 )) ∧ . . . ∧ W (F (x/dn )) mit di aus der Domäne {di , . . . , dn }
Achtung: Der Wahrheitswert einer WFF kann von der zugrundeliegenden Domäne
abhängen!
3.2.4. Das Domänenkalkül
Sei F (X1 , . . . , Xn ) eine WFF.
Der Ausdruck
{(X1 , . . . , Xn ) : F (X1 , . . . , Xn )}
ist eine Domänenkalkülanfrage (oder auch DRC-Query) mit der Antwortrelation
rF = {(a1 , . . . , an ) : W (F (a1 , . . . , an )) = true }
9
3. Relationale Anfragesprachen
3.2.5. RA nach DRC (am Beispiel)
Relationaler Ausdruck:
ΠStName (σHörsaal = HS1 (Prüfung o
n Beteiligt))
DRC-Query:
FE = ∃P r ∃H ∃T ∃P (Prüfung(P r, H, T ) ∧ Beteiligt(P r, ST N, P ) ∧ (H = HS1))
rF = {(ST N ) : W (FE (ST N )) = true }
Alle Variablen, die nicht im Ergebnis erscheinen soll werden durch ∃ quantifiziert.
3.2.6. Beschränkte Variablen in WFFs
Sei F = F1 ∧ . . . ∧ Fn eine konjunktive WFF.
X heißt beschränkt, falls es ein Fi gibt, so dass eine der folgenden Bedingungen erfüllt
ist:
1. X ∈ F V (Fi ) und Fi ist eine nicht negierte atomare Formel
der Form p(t1 , . . . , X, . . . , tn )
2. Es gilt: Fi ≡ (X = a) oder Fi ≡ (a = X) mit a als Konstante.
3. Es gilt: Fi ≡ (X = Y ) oder Fi ≡ (Y = X) für eine beschränkte
Variable Y ∈ F V (F ).
3.2.7. Sichere (safe) DRC-Formeln
Eine Formel F heißt sicher (safe), falls gilt:
1. Es gibt keinen All-Quantor in F.
2. Bei jedem OR-Operator in F, der zwei Teilausdrücke F1 ∨F2 verbindet, muss gelten:
F V (F1 ) = F V (F2 )
3. Die freien Variablen jeder maximalen konjunktiven Teilformel F1 ∧ . . . ∧ Fn von F
sind beschränkt.
4. Die Negation darf nur in solchen Konjunktionen auftreten, in denen mindestens
ein Fi nicht negiert ist.
Maximale konjunktive Teilformeln sind alle Teilformeln einer durch “∧“ verbundenen Kette.
10
4. Anfragebearbeitung
4. Anfragebearbeitung
4.1. Gesetze zur Optimierung
Seien E1 und E2 Ausdrücke der relationen Algebra. E1 und E2 heißen äquivalant, falls
sie die gleichen Operanden (Selektion, Join, Produkt, . . . ) benutzen und für beliebige
Instanziierungen die gleiche Antwortrelation berechnen.
4.1.1. Joins und Produkte
Kommutativität:
E1 o
nCond E2 ≡ E2 o
nCond E1
E1 × E2 ≡ E2 × E1
Assoziativität:
(E1 o
nCond1 E2 ) o
nCond2 E3 ≡ E1 o
nCond1 (E2 o
nCond2 E3 )
(E1 × E2 ) × E3 ≡ E1 × (E2 × E3 )
4.1.2. Projektion und Selektion
Kaskade von Projektionen:
Π{B1 ,...,Bm } Π{A1 ,...,An } (E) ≡ Π{B1 ,...,Bm } (E)
falls {B1 , . . . , Bm } ⊆ {A1 , . . . , An }
Kaskade von Selektionen:
σCond1 (σCond2 (E)) ≡ σCond2 (σCond1 (E)) ≡ σCond1∧Cond2 (E)
Vertauschen (1):
Π{A1 ,...,An } (σCond (E)) ≡ σCond (Π{A1 ,...,An } (E))
falls in Cond nur Attribute A1 , . . . , An auftreten.
Vertauschen (2):
Π{A1 ,...,An } (σCond (E)) ≡ σCond (Π{A1 ,...,An ,B1 ,...,Bm } (E))
falls in Cond die Attribute A1 , . . . , An und B1 , . . . , Bm auftreten.
11
4. Anfragebearbeitung
4.1.3. Selektion und Join
Vertauschen (Join):
σCond (E1 o
nCond1 E2 ) ≡ σCond (E1 ) o
nCond1 E2
falls in Cond nur Attribute aus E1 auftreten.
Vertauschen (Natural Join):
σCond (E1 o
n E2 ) ≡ σCond (E1 ) o
n σCond (E2 )
4.1.4. Selektion und Vereinigung / Differenz
Vertauschen:
σCond (E1 ∪ E2 ) ≡ σCond (E1 ) ∪ σCond (E2 )
σCond (E1 \ E2 ) ≡ σCond (E1 ) \ σCond (E2 )
4.1.5. Projektion und Join
Vertauschen:
Π{A1 ,...,An ,B1 ,...,Bm } (E1 o
nCond E2 ) ≡ Π{A1 ,...,An } (E1 ) o
nCond Π{B1 ,...,Bm } (E2 )
falls in Cond nur Attribute A1 , . . . , An und B1 , . . . , Bm auftreten
und A1 , . . . , An nur in E1 und B1 , . . . , Bm nur in E2 auftritt.
4.1.6. Projektion und Vereinigung
Vertauschen:
Π{A1 ,...,An } (E1 ∪ E2 ) ≡ Π{A1 ,...,An } (E1 ) ∪ Π{A1 ,...,An } (E2 )
falls A1 , . . . , An Attribute in E1 bzw. E2 sind.
4.1.7. Selektion und Produkt
Zusammenfassen zum Join:
σCond (E1 × E2 ) ≡ E1 o
nCond E2
falls Cond von der Form (A op B) ist und A in E1 und B in E2 als Attribut
auftritt.
12
4. Anfragebearbeitung
4.1.8. Umschreiben eines Produktes
(E1 × . . . × En ) ≡ (((E1 × E2 ) × E3 ) . . . × En )
und alle möglichen Permutationen.
4.2. Beispiel für eine Optimierung
ΠBetreut.PrName, Betreut.StName (σCond (Betraut × Beteiligt × Prüfung))
mit Cond = (Betreut.StName = Beteiligt.StName)
and (Beteilgt.Pr = Prüfung.Pr) and (Prüfung.Hörsaal = HS1)
and (Prüfung.Datum < 31.12.1994)
4.3. Nested-Loop-Join
Pseudocode:
FOR EACH r in R DO
FOR EACH s in S DO
IF(r.B = s.B) THEN
OUTPUT (r,s)
END IF
NEXT
NEXT
Kostenbetrachtung:
TR , TS := Anzahl der Tupel von R bzw. S
PR , PS := Anzahl der Seiten von R bzw. S
βR =
βS =
PR
TR
PS
TS
Ro
nS :
So
nR:
(Tupel pro Seite von R)
(Tupel pro Seite von S)
PR + TR · PS = PR + TR · βS · TS = PR + βS · TR · TS
PS + TS · PR = PS + TS · βR · TR = PS + βR · TR · TS
PR + βS · TR · TS ≈ βS
PS + βR · TR · TS ≈ βR
Ro
n S wenn βS < βR und sonst S o
n R.
13
5. Speicherstrukturen
5. Speicherstrukturen
5.1. B-Baum
B-Bäume minimieren die Anzahl der wahlfreien Zugriffe unter Ausnutzung der charakteristischen Eigenschaften des Hintergrundspeichers. Sie speichern pro Baumknoten eine
variable Anzahl von Schlüsseln (statt nur eines einzelnen Schlüssels beim Binärbaum).
Mit der Schlüsselanzahl steigt auch die Anzahl der Verweise auf Kindknoten pro Knoten
(der Verzweigungsgrad) auf eine variable Anzahl mit festgelegtem Schwankungsbereich
von minimal t und maximal 2t (gegenüber zwei beim Binärbaum). Der Parameter t
ist wählbar und wird verwendet, um die Datenstruktur so an die Blockgröße des Speichermediums anzupassen, dass ein Baumknoten maximal gerade einen kompletten Block
des Speichermediums belegt. Der große Verzweigungsgrad reduziert die Baumhöhe und
damit die Anzahl der kostspieligen wahlfreien Zugriffe. Die variable Schlüsselmenge pro
Knoten vermeidet häufiges Balancieren des Baumes.
Alle Knoten außer der Wurzel haben
• mindestens t − 1 und höchstens 2t − 1 Schlüssel
• und entsprechend mindestens t und höchstens 2t Kindverweise
Die Wurzel hat
• mindestens 1 und höchstens 2t − 1 Schlüssel, wenn der Baum nicht leer ist
• und entsprechend mindestens 2 und höchstens 2t Kindverweise, wenn die Höhe des
Baumes größer 0 ist
Eine ausführliche Beschreibung ist in Wikipedia vorhanden:
http://de.wikipedia.org/wiki/B-Baum
5.2. B*-Baum
Der B*-Baum ist eine Erweiterung des B-Baumes. Bei einem B*-Baum werden die eigentlichen Datenelemente nur in den Blattknoten gespeichert, während die inneren Knoten
lediglich Schlüssel enthalten. Dadurch kann der Verzweigungsgrad erhöht und damit die
Baumhöhe verringert werden, weil in den Indexknoten mehr Platz zur Verfügung steht.
14
6. Transaktionskonzept
6. Transaktionskonzept
Ein Ablaufplan (Schedule) ist eine Folge von Aktionen, die durch Überlappung der
Einzelaktionen unter Beibehaltung der Reihenfolgen innerhalb jeder einzelnen Transaktion ensteht.
Ein serieller Schedule ist ein Ablaufplan in dem sich Transaktionen nicht überlappen.
Eine Transaktion beendet alle ihre Operationen bevor eine andere Transaktion mit ihren
Operationen beginnt.
Ein Ablaufplan heißt serialisierbar, falls seine Wirkung äquivalent zu der Wirkung
eines seriellen Schedule ist.
Ziel: Nur serialisierbare Schedules im DB-System zulassen.
Als Concurrency Control bezeichnet man Protokolle der Zugriffskontrolle im Mehrbenutzerbetrieb.
6.1. 2-Phasen-Sperrprotokoll (2PL)
Regeln:
• vor dem Lesen eines Objekt X muss die TA eine Lesesperre auf diesem Objekt
besitzen
• vor dem Schreiben eines Objekt X muss die TA eine Schreibsperre auf diesem
Objekt besitzen
• eine TA behält ihre Sperren bis zu ihrem Ende
• 2 TA können nicht gleichzeitig unverträgliche Sperren auf dem gleichen Objekt
besitzen (nur mehrfache Schreibsperren auf gleichem Objekt sind verträglich)
Bemerkungen:
• erzeugt nur serialisierbase Schedules
• verschiedene Variationen (bezogen auf die Anzahl der Lese- und Schreiboperationen)
• Deadlocks zwischen Transaktionen sind möglich
15
6. Transaktionskonzept
6.2. Fehlererholung
Im Fehlerfall müssen Transaktionen zurückgesetzt werden und es muss die zuletzt gültige
Version in der Datenbank wiederhergestellt werden.
Möglicherweise geht der Inhalt des Hauptspeichers verloren. In diesem Fall müssen genug
Informationen bereitstehen um die Datenbanken wieder in einen konsistenten Zustand zu
überführen. Dazu werden auf einem Sekundärspeicher Informationen zur Fehlererholung
angelegt. Dabei werden die durch eine Transaktion veränderten Daten in einem Log
gespeichert (alte und neue Werte). Dieser Log dient auch der Archivierung (gesicherter
Zustand + Log = aktueller Zustand) und als Nachweis wer wann was verändert hat
(gesetzliche Gründe).
Ablauf eines Fehlererholungsalgorithmus:
1. Normalbetrieb:
• beim Schreiben eines Wertes X: Schreibe alten und neuen Wert von X als
Log-Record in das Log
• beim EOT: Sicherstellen, dass alle Log-Records auf Platte geschrieben wurden
und schreibe COMMIT als Log-Record in das Log
2. Transaktionsfehler:
• lies Log und trage alten Wert für Operationen ein, die von der TA ausgeführt
wurden
• füge ein ABORT in das Log ein
3. Systemfehler:
• lies das Log und bestimme die Menge der aktiven Transaktionen (kein COMMIT) und die Menge der abgeschossenen Transaktionen (COMMIT vorhanden)
• alle aktiven TA werden abgebrochen
• die neuen Werte der abgeschlossenen TA werden in die DB eingetragen
16
7. XML
7. XML
Eine Document Type Definition (DTD) legt die Struktur eines XML-Dokuments
rein syntaktisch fest (ähnlich einem Datenbankschema).
7.1. DTD für ein Adressbuch
<!DOCTYPE addressbook [
<!ELEMENT addressbook (projekt*)>
<!ELEMENT projekt (name, greet?, address*, (fax | tel)*, email*)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT greet (#PCDATA)>
<!ELEMENT address (#PCDATA)>
<!ELEMENT fax (#PCDATA)>
<!ELEMENT tel (#PCDATA)>
<!ELEMENT email (#PCDATA)>
]>
7.2. Die Verwendung von ID und IDREF
<!DOCTYPE db [
<!ELEMENT db (movie*, actor*)>
<!ELEMENT movie (title, director, cast, budget)>
<!ELEMENT actor (name, actedIn)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT director (#PCDATA)>
<!ELEMENT budget (#PCDATA)>
<!ELEMENT name (#PCDATA)>
<!ATTLIST cast
id ID #REQUIRED>
<!ATTLIST actedIn
idrefs IDREF #IMPLIED>
]>
• #REQUIRED bedeutet auf jeden Fall festzulegen
und #IMPLIED bedeuted optional
• falls ein Attribut als ID definiert ist müssen alle assoziierten Werte unterschiedlich
sein
• falls ein Attribut als IDREF definiert ist müssen die vergebenen Werte als ID eines
Attributes existieren (IDREFs spezifiziert Null oder mehr IDs)
• ID und IDREF sind nicht getypt
17
7. XML
Eine Instanz der DTD könnte dann so aussehen:
<db>
<movie id=’m1’>
<title>Waking Ned Devine</titel>
<director>Kirk Jones III</director>
<cast idrefs=’a1 a3 a12’></cast>
<budget>100,000</budget>
</movie>
..
.
<actor id=’a1’>
<name>David Kelly</name>
<actedIn idrefs=’m1 m78’></actedIn>
</actor>
<actor id=’a3’>
<name>Ian Bannen</name>
<actedIn idrefs=’m1 m35’></actedIn>
</actor>
..
.
</db>
18
A. Algorithmen
A. Algorithmen
A.1. Die Hülle (bezüglich einer Attributmenge)
Eingabe: FD-Menge F und Attributmenge X
Ausgabe: Hülle von F bezüglich X (XF+ )
Methode:
Solange es noch eine FD A → B gibt, bei der A in meiner Hülle enthalten ist und B
noch nicht, dann nehme B in die Hülle mit auf.
Beispiel:
R = {A, B, C, D, E}
F = {(AB → C), (B → D), (D → E)}
X = {A, B}
Schrittweise Berechnung der Hülle:
1. XF+ = X ∪ {C} ∪ {D} = {A, B, C, D}
2. XF+ = XF+ ∪ {E} = {A, B, C, D, E}
A.2. Schlüsselkandidaten bestimmen
Eingabe: FD-Menge F und Attributmenge V = {A1 , . . . , An }
Ausgabe: Ein Schlüsselkandidat K ⊆ V .
Methode:
• Zunächst ist V selbst der Schlüssel, also K = V (trivial).
• Gehe nacheinander alle Attribute Ai ∈ V durch und prüfe ob V = (K \ {Ai })+
F.
• Wenn ja, dann setze K = K \ {Ai }.
Problem:
Wenn man alle Schlüsselkandidaten bestimmen will, so dauert die Berechnung mit dem
vorgestellten Algorithmus viel zu lange. Man kann unmöglich alle Teilmengen von V
auf Schlüsselkandidaten untersuchen. Deshalb muss die Menge der zu untersuchenden
Schlüsselkandidaten eingeschränkt werden.
19
A. Algorithmen
Dazu soll der folgende Algorithmus dienen:
• Falls ein Attribut niemals auf der rechten Seite einer FD steht, dann muss es in
allen Schlüsselkandidaten enthalten sein.
• Untersuche alle X mit (X → Y ) ∈ F .
• Für alle echten Teilmengen Z ⊂ X von X, prüfe ob es eine FD (U → Z) ∈ F gibt.
Falls ja, dann untersuche auch U ∪ (X \ Z).
Beispiel:
V = {A, B, C, D, E, F }
F = {(AC → EF ), (BC → AD), (DEF → C)}
Alle Schlüsselkandidaten müssen B enthalten!
Folgende Mengen müssen nun auf Schlüsselkandidaten untersucht werden:
• ACB, BC, DEF B
• BDEF wegen (BC → AD) und (DEF → C)
• ADEF B wegen (AC → EF ) und (DEF → C)
Aber: BDEF ⊆ ADEF B, also überflüssig
• DACB wegen (AC → EF ) und (DEF → C)
Aber: BC ⊆ DACB, also überflüssig
• CBC wegen (AC → EF ) und (BC → A)
Aber: CBC = BC, also überflüssig
• BCEF wegen (BC → D) und (DEF → C)
Aber: BC ⊆ BCEF , also überflüssig
Ergebnis: Die Schlüsselkandidaten sind BC und BDEF.
Diese Vorgehensweise erscheint nicht in den Vorlesungsfolien. Die Benutzung erfolgt
deshalb auf eigene Gefahr!
20
A. Algorithmen
A.3. Basis bzw. minimale Überdeckung
Eingabe: Menge F von FDs
Ausgabe: Basis FC von F
Beispiel: F = {(A → B), (B → C), (A → C), (AB → C), (A → BC)}
Methode:
Untersuche alle funktionalen Abhängigkeiten (α → β) ∈ F :
1. Linksreduktion:
• Prüfe welche Attribute A ∈ α überflüssig sind.
• Entferne A, falls β bereits in der Hülle von F über α \ A enthalten ist, d.h.
falls gilt β ⊆ (α \ A)+
F.
• im Beispiel ist das B in (AB → C) überflüssig, weil C ⊆ A+
F = {A, B, C}
2. Rechtsreduktion
• Prüfe welche Attribute B ∈ β überflüssig sind.
• Entferne B, falls B bereits in der Hülle von F \ (α → β) ∪ (α → β \ B) über
α enthalten ist, d.h. falls gilt B ⊆ αF+\(α→β)∪(α→β\B) .
• im Beispiel ist das B in (A → BC) überflüssig, weil B ⊆ {A, B, C}
3. Entferne alle überflüssigen funktionalen Abhängigkeiten X → ∅.
4. Fasse (α → β), (α → γ) zusammen zu (α → β, γ).
21
A. Algorithmen
A.4. Lossless-Join-Zerlegung
Eine Lossless-Join-Zerlegung ist eine Zerlegung eines Relationenschema, so dass dabei
keine Informationen verloren gehen.
Test auf Informationserhaltung
Eingabe: ein Relationenschema R(A1 , . . . , An ), eine Zerlegung p = {R1 , . . . , Rk } und
eine Menge F von FDs
Ausgabe: True, falls p eine Lossless-Join-Zerlegung ist, False sonst.
Methode:
1. Hilfstabelle konstruieren:
Attribute A1 , . . . , An
1 ...
n
Zerlegungen
p = {R1 , . . . , Rk }
1
...
k
rij
rkn
rij = aj , falls A ∈ Ri
rij = bij , falls A ∈
/ Ri
2. Wähle (X → Am ) ∈ F .
Wiederhole bis keine Änderungen mehr erfolgen:
Falls in zwei Zeilen i1 und i2 die Werte von X übereinstimmen, dann setze die
Werte von Am wie folgt:
Falls i1 = am dann i2 := am ,
falls i2 = am dann i1 := am ,
sonst i1 := i2 .
3. Falls es eine Zeile (a1 , . . . , an ) gibt, dann gibt True zurück, sonst False.
22
A. Algorithmen
Beispiel:
R := (Pr, Datum, Hörsaal, StName, Platz)
R1 := (Pr, Datum, Hörsaal)
R2 := (Pr, StName, Platz)
p := {R1 , R2 }
F := {(Pr → Datum), (Pr → Hörsaal), (Pr,StName → Platz)}
nach Schritt 1:
R1
R2
Pr
a1
a1
Datum
a2
b22
Hörsaal
a3
b23
StName
b14
a4
Platz
b15
a5
Hörsaal
a3
b23
StName
b14
a4
Platz
b15
a5
Hörsaal
a3
a3
StName
b14
a4
Platz
b15
a5
nach Schritt 2:
(Pr → Datum) ∈ F
R1
R2
Pr
a1
a1
Datum
a2
a2
(Pr → Hörsaal) ∈ F
R1
R2
Pr
a1
a1
Datum
a2
a2
nach Schritt 3:
True
23
A. Algorithmen
A.5. Dekomposition
Verlustlose Zerlegung eines Relationenschemas R in Teilrelationen,
die in BCNF sind.
Die Abhängigkeitserhaltung ist nicht gewährleistet!
Eingabe: Menge Z = {R}
Ausgabe: Menge Z = {R1 , . . . , Rn }
Solange noch Ri ∈ Z existieren, die nicht in BCNF sind, wiederhole folgendes:
• Falls gilt: es gibt eine FD α → β in Ri mit α ∩ β = ∅ und ¬(α → Ri ).
• Dann zerlege Ri in Rj = α ∪ β und Rk = Ri \ β.
• Rj erhält die funktionellen Abhängigkeiten F Dj := {X → Y | X ∪ Y ⊆ Rj }
und entsprechendes gilt für die funktionellen Abhängigkeiten F Dk von Rk .
• Entferne Ri aus Z und füge Rj und Rk ein.
A.6. Synthese
Verlustlose und abhängigkeitserhaltende Zerlegung eines Relationenschemas R
in Teilrelationen, die in 3. NF sind.
Eingabe: Menge Z = {R}
Ausgabe: Menge Z = {R1 , . . . , Rn }
Methode:
• Bestimme die Basis Fc zu F .
• Für jede FD (α → β) ∈ Fc :
– Erzeuge Relationenschema Ri = α ∪ β.
– Ri erhält die funktionellen Abhängigkeiten F Di := {X → Y | X ∪ Y ⊆ Ri }
• falls der Schlüsselkandidat k von R bezüglich Fc in keiner der Relationen Ri enthalten ist, dann:
– Neues Relationenschema Rk := k
– F Dk := ∅
• Elimiere Relationenschemata, die in anderen enthalten sind.
24
B. Prüfungsfragen
B. Prüfungsfragen
Dieses Kapitel ist keinesfalls vollständig und dient nur als Ergänzung zu den Prüfungsfragen aus dem Skript von N. Lohmann (WS 04/05). Sie sollten sich also beides ansehen!
B.1. ER-Modell
Gegeben sind Instanzen von Entitäten und Beziehungen (als Mengen).
A = {A1 , A2 , A3 }
D = {D1 , D2 , D3 }
B = {B1 , B2 }
E = {E1 , E2 }
Bez1 = {(A1 , D2 ), (A2 , D3 ), (A3 , D1 )}
Bez3 = {(C1 , F2 ), (C1 , F3 )}
C = {C1 }
F = {F2 , F3 }
Bez2 = {(B1 , C2 , E1 ), (B2 , C2 , E1 )}
Aufgaben:
1. Eintragen in ein ER-Model (siehe Abbildung)
2. Welche Constraints gelten für die Generalisierung?
(Hinweis: Wenn in den Instanzmengen der Spezialisierungen Elemente Ei und Fj
mit i = j auftreten dann bedeutet das Overlapping! Dieser Sachverhalt war in der
Klausur etwas komisch beschrieben und deshalb hab ich das leider nicht mitbekommen.)
3. Umformen in ein Relationales Modell
25
B. Prüfungsfragen
Hinweis zur Umformung in ein Relationales Modell:
Sollte die folgende Form einer Beziehung vorliegen:
Dann kann man diese in ein einziges Relationenschema umformen: AD(h,g,o,p)
B.2. Funktionale Abhängigkeiten
• Was ist eine Lossless-Join-Zerlegung und was ist eine abhängigkeitserhaltende Zerlegung?
• Wie heißt der Algorithmus zur Zerlegung eines Relationenschema in 3. NF?
• Wie heißt der Algorithmus zur Zerlegung eines Relationenschema in BCNF?
B.3. Relationale Algebra
• Was versteht man unter einer minimalen Menge?
Lösung: Eine minimale Menge ist eine Menge von Basisoperatoren aus denen alle
anderen Operatoren gebildet werden können.
• Eine minimale Menge angeben!
• Operatoren nur mit Hilfe anderer Operatoren der RA darstellen
(z.B. für die Operatoren Durchschnitt und Division)
• Join-Graphen für gegebene Join-Reihenfolgen zeichnen und benennen
• Gegeben ist eine Anfrage im DRC mit einer WFF.
– Beschreiben Sie in einem deutschen Satz was diese Anfrage macht.
– Ist die WFF sicher oder nicht sicher? Begründen Sie!
26
B. Prüfungsfragen
• Gegeben ist der Pseudocode für einen Nested-Loop-Join. Geben sie den Pseudocode
für einen Semi-Join (R semi-join S) an (auf der Seite von R ist das Join-Symbol
geschlossen und bei S ist es offen - kann man hier leider nicht darstellen).
Dabei gibt es eine kleine Falle. Deshalb hier die Lösung:
FOR EACH r in R DO
FOR EACH s in S DO
IF(r.B = s.B) THEN
OUTPUT (r)
BREAK
END IF
NEXT
NEXT
Sehr wichtig ist es das BREAK nicht zu vergessen, weil sonst r wiederholt ausgegeben wird, falls mehrere Join-Partner s existieren!
B.4. SQL
Gegeben ist die Struktur von mehreren Tabellen in DDL.
• Welche Bedeutung haben die folgenden Constraints für Einträge in den jeweiligen
Tabellen:
– PRIMARY KEY(x,y)
– FOREIGN KEY station REFERENCES station(name)
• SQL-Anfragen formulieren. Dazu muss u.a. folgendes verwendet werden: Kartesisches Produkt, GROUP-BY mit HAVING und Sub-Queries (Unterabfragen)
B.5. B-Baum
Bei den Aufgaben zum B-Baum hatte ich nur 3 von 10 Punkten. Das, was ich auf
Wikipedia dazu gelesen hatte, konnte ich irgendwie nicht so richtig umsetzen.
• Zwei Eigenschaften von B-Bäumen nennen.
• Wo finden Einfügeoperationen in einem B-Baum statt? (die Antwort in den Kno”
ten“ fanden die nicht so toll)
• Gegeben ist die Höhe (h) und Breite (k) eines B-Baum. Wieviele Schlüssel kann
der Baum maximal enthalten?
• Entfernen eines Elements aus einem B-Baum.
27
B. Prüfungsfragen
• Einfügen eines neuen Elements in einen B-Baum:
1. mit Einbeziehen des freien Platzes in Nachbarknoten
2. ohne Einbeziehen ...
Tja, hier wusste ich nicht so recht was die vom mir wollten. Punkt 1 hatte ich
richtig und den Punkt 2 wusste ich nicht.
B.6. XML
Eine Aufgabe aus der Klausur:
<!DOCTYPE db [
<!ELEMENT db (flug | fluggesellschaft)*>
<!ELEMENT fluggesellschaft (name, kurzel)>
<!ELEMENT flug (flugnr, gesellschaft, start, ziel, uhrzeit)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT flugnr (#PCDATA)>
<!ELEMENT gesellschaft (#PCDATA)>
<!ELEMENT start (#PCDATA)>
<!ELEMENT ziel (#PCDATA)>
<!ELEMENT uhrzeit (#PCDATA)>
<!ATTLIST start
iaca code CDATA #REQUIRED>
<!ATTLIST ziel
iaca code CDATA #REQUIRED>
<!ATTLIST name
www CDATA #IMPLIED>
]>
• Fehler in einem XML-Dokument finden, d.h. Widersprüche zur DTD finden (hier
nicht gegeben).
• ID und IDREF so in die DTD einfügen, dass gilt:
– kuerzel identifiziert eindeutig eine fluggesellschaft
– flugnr identifiziert eindeutig einen flug
– gesellschaft ist Fremdschlüssel von fluggesellschaft in flug
• Die XML-DTD in ein Relationenschema transformieren. Folgendes muss gelten:
– die gegebenen Constraints durch Schlüssel und Fremdschlüssel werden eingehalten
– das Attribut aca code legt eindeutig den Start- und Zielflughafen fest (Attribute start und ziel)
– das Relationenschema befindet sich in 3. Normalform
28
B. Prüfungsfragen
Ein Ansatz zur Umformung in ein Relationenschema:
fluggesellschaft(name, kuerzel, www)
flug(flugnr, gesellschaft, start iaca code, ziel iaca code, uhrzeit)
FOREIGN KEY gesellschaft REFERENCES fluggesellschaft(kuerzel)
FOREIGN KEY start iaca code REFERENCES flughafen(iaca code)
FOREIGN KEY ziel iaca code REFERENCES flughafen(iaca code)
flughafen(iaca code, name)
Achtung: Keine Garantie auf Korrektheit! Also bitte nachprüfen.
B.7. Transaktionen
• Für welche Eigenschaften von ACID ist der Recovery-Manager bzw. der
Concurrency-Control-Manager verantwortlich?
Lösung:
– Recovery-Manager ist verantwortlich für Durability und Consistency
– Concurrency-Control-Manager ist nur verantwortlich für Isolation
• Die vier Regeln des 2-Phasen-Sperrprotokoll nennen.
• Ist ein gegebener Schedule serialisierbar? Man soll begründen!
Ich hatte hier sowas geschrieben wie:
T1 hat bereits Lesesperre auf X, dann kann T2 keine Schreibsperre anfordern
Dafür gabs 0 Punkte und den Kommentar Das ist nicht die Begründung!“.
”
29