Vorlesungsinhalt - DBIS Informatik

25.10.2012
Grundlagen relationaler
Datenbanksysteme
Kapitel
III
Vorlesung Datenbanksysteme
Univ.-Prof. Dr. Günther Specht
Universität Innsbruck
Institut für Informatik
Datenbanken und Informationssysteme (DBIS)
Vorlesungsinhalt
3. Grundlagen relationaler Datenbanksysteme
–
–
–
–
–
Motivation
Relationenmodell
Sprachen des Basismodells
Relationen-Algebra
Relationen-Kalkül
2
G. Specht: Datenbanksysteme
3-1
25.10.2012
Motivation
3
Motivation
•
Ende der 60er Jahre Grundlagenforschung am IBM-Forschungslabor San Jose,
California, mit dem Ziel, die Erstellung von Datenbankanwendungen „einfacher“
zu machen.
•
1970 erste Veröffentlichung von E.F. Codd zum „Relationalen Datenmodell“
•
In der Folge verschiedene Prototyp-Entwicklungen, am bekanntesten wurden
– System R, IBM
– Ingres, University of California, Berkeley
•
Heute wichtigste kommerziell verfügbare Datenbanktechnologie
•
Inzwischen sind viele relationale DBS auf dem Markt
– DB2 (IBM)
– Oracle (Oracle)
– SQL-Server (Microsoft)
– Sybase (Sybase)
– Informix (IBM)
– etc.
4
G. Specht: Datenbanksysteme
3-2
25.10.2012
Relationenmodell
5
Motivation
Das haben wir: E/R-Modell Bsp.: KursDB
6
G. Specht: Datenbanksysteme
3-3
25.10.2012
Motivation
Da wollen wir hin: Bsp. Relationen zur KursDB
Kurs
Kursleiter
Vorauss
Fuehrt_durch
KursNr
Titel
PersNr
Name
Gehalt
VorNr
KursNr
AngNr
G08
Grundlagen I
27183
Meier, I.
4300.50
G08
P13
1
G08
38197
G10
Grundlagen II
29594
Schulze, H.
3890.20
G10
P13
2
G08
38197
P13
C-Programmierung
38197
Huber, L.
4200.10
G08
I09
1
G10
43325
I09
Datenbanken
43325
Müller, K.
3400.80
G10
I09
2
G10
29594
P13
I09
1
P13
27183
2
P13
27183
1
I09
29594
2
I09
29594
3
I09
29594
Teilnehmer
Nimmt_teil
KursNr
TnNr
Name
Ort
AngNr
KursNr
TnNr
143
Schmidt, M.
Bremen
2
G08
143
145
Huber, Chr.
Augsburg
2
P13
143
146
Abele, I.
Senden
1
G08
145
149
Kircher, B.
Bochum
1
P13
146
AngNr
KursNr
Datum
Ort
155
Meier, W.
Stuttgart
1
I09
146
1
G08
2000-10-13
München
171
Möller, H.
Innsbruck
2
P13
149
2
G08
2000-11-24
Bremen
173
Schulze, B.
Stuttgart
1
I09
155
1
G10
2000-12-01
München
177
Mons, F.
Essen
1
I09
171
2
G10
2001-02-15
Hamburg
185
Meier, K.
Heidelberg
1
I09
173
1
P13
2001-05-28
Innsbruck
187
Karstens, L.
Hamburg
2
P13
177
2
P13
2001-07-01
Essen
194
Gerstner, M.
Innsbruck
1
I09
185
1
I09
2001-03-27
Stuttgart
2
I09
187
2
I09
2001-04-23
Hamburg
1
P13
194
3
I09
2001-05-29
München
PersNr
Angebot
7
Basiskonzepte
Darstellung der Miniwelt in Tabellenform
(Datenbank = Menge von Relationen/Tabellen)
Ansatz
•
Einzige Datenstruktur: Tabelle ≡ Relation
•
Saubere mathematische Grundlage:
Mengentheorie (vgl. math. Relation)
•
Einfache Operationen, mengenorientiert
•
Abgeschlossenheit: Operationen überführen
Tabellen in Tabellen
•
∃ Entwurfstheorie (was sind
„gute“ Tabellen?)
Relation = Menge von Tupeln (mit atomaren Komponenten)
8
G. Specht: Datenbanksysteme
3-4
25.10.2012
Eigenschaften
•
Alle Informationen werden als Relationen modelliert
•
Relation
•
Jede Zeile - genannt Tupel - entspricht einem Entity oder/und einer Beziehung
•
Die Spalten der Tabelle (Relation) sind benannt und werden als die Attribute
bezeichnet
•
Die Reihenfolge der Spalten ist nicht relevant, da sie über ihren Namen
identifiziert werden
•
Jedem Attribut ist ein Wertebereich (sog. Domain) zugeordnet.
•
Ein Wertebereich ist eine Menge atomarer Werte, welche - aus Sicht des
DBMS - „elementar“ sind, d.h. keine weitere Substruktur mehr aufweisen.
•
Beziehungen werden ausschließlich über Attributwerte realisiert
= zweidimensionale Tabelle von Werten
= Menge von Tupeln (keine Duplikate, keine Reihenfolge!)
Bem: Wie wir später noch sehen werden, werden die letzten beiden Forderungen im Kontext der objektorientierten
Erweiterungen von SQL wieder aufgeweicht bzw. fallengelassen.
9
Mathematische Notation
∀
…
für alle
∈
…
Element aus
∉
…
kein Element aus
⊆
…
Subset, Teilmenge, kann auch ganze Menge sein
⊂
…
„echtes“ Subset, Teilmenge
∪
…
Vereinigung
⇒
…
daraus folgt
∃
…
es gibt
∆
…
Delta
≡
…
Äquivalent (Menge)
∧
…
UND
∨
…
ODER
¬
…
NICHT
⇔
…
Äquivalent (Logik)
10
G. Specht: Datenbanksysteme
3-5
25.10.2012
Schreibweisen und Definitionen
•
Relation R mit Attributen A1 bis A5:
R ( A1, A2, A3, A4, A5)
•
Relation mit Attributen A bis D oft auch:
ABCD
•
Domain
dom(Ai) = Di
Domäne (Wertebereich) von Ai
•
Schema
sch(R) = {A1,..., An}
Schema einer Relation
•
Wert
•
Tupel
val(R) ⊆ dom(A1) x ... x dom(An)
Wert einer Relation
t = <A1:v1, ..., An:vn> mit vi ∈ Di,
meist mit fester Reihenfolge der Attribute:
t = (v1, ..., vn), t ∈ val(R)
11
Schreibweisen und Definitionen
•
Tupelkomponenten/Attributwerte: t (Ai) = vi oder auch t[Ai] oder t.Ai,
auch mit A ⊆ sch(R) : t(A)
(„Set of Mappings“ Definition von Relationen: Relation ist Menge von Abbildungen
tj: sch(R) → ∪ Di, so dass tj(Ai) ∈ Di)
•
K ⊆ sch (R) heißt Schlüsselkandidat oder auch nur kurz Schlüssel,
wenn ∀ t, t' : t(K) = t'(K) ⇒ t = t' und K minimal
•
Primärschlüssel : ein ausgewählter Schlüsselkandidat [1]
•
Fremdschlüssel F in Relation R :
F ⊆ sch(S) und F ⊆ sch(R) für eine Relation S, in der F Primärschlüssel ist
•
A ∈ sch(R) ist Schlüsselattribut, wenn es Teil eines Schlüsselkandidaten ist
[1] Eine Relation kann also mehrere Attribute oder Attributkombinationen besitzen, die Schlüsseleigenschaft haben
(= Schlüssel(kandidaten)), wie z. B. Personalnummer oder Sozialversicherungsnummer oder (Vorname, Nachname,
Straße, Plz, Ort). Einer davon wird dann als bevorzugter Schlüssel (= Primärschlüssel) ausgewählt.
12
G. Specht: Datenbanksysteme
3-6
25.10.2012
Modellinhärente Integritätsbedingungen des
Relationenbasismodells
1. „Entity Integrity“
Primärschlüsselattribute dürfen nie undefiniert (NULL) sein
2. „Referential Integrity“
Fremdschlüssel sind entweder undefiniert (NULL) oder es gibt ein entsprechendes Tupel
mit diesem Primärschlüssel in der anderen Relation.
3. „Domains“
Attribute dürfen nur Werte aus der jeweiligen Domain annehmen (oder undefiniert
(„NULL“)) sein.
Nullwerte
•
Nullwerte sind spezielle logische Werte und entsprechen nicht dem Leerzeichen oder dem
numerischen Wert Null. Mittels Nullwerten lässt sich eine dreiwertige Logik realisieren:
Prädikat = {true | false | unknown}
Hinweise
•
In den folgenden Relationen werden Nullwerte durch "--" dargestellt, im DBS muss stattdessen NULL eingeben werden.
•
Im nächsten Kapitel werden wir noch ausführlicher auf Nullwerte eingehen.
13
Umsetzregeln:
E/R-Modell ins Relationenmodell
1. Abbildung von Entity-Typen auf Relationen:
– Entity-Typ E mit Attributen Ai aus Domäne Di (1 ≤ i ≤ k) wird abgebildet auf k-stellige
Relation E(A1:D1, A2:D2, ..., Ak:Dk)
– Falls außerdem "E isa F" besteht oder E ein schwacher Entity-Typ, existenz-abhängig
von F ist, werden alle Schlüsselattribute von F hinzugenommen.
G. Specht: Datenbanksysteme
3-7
25.10.2012
Umsetzregeln:
E/R-Modell ins Relationenmodell
2. Abbildung von Relationship-Typen auf Relationen:
2.1. n:m-Beziehungen und alle 3er, 4er, ... etc. Beziehungen:
– Relationship R zwischen Entity-Typen E1 ... En wird abgebildet auf Relation R,
deren Attribute aus den Primärschlüsseln der Ei bestehen.
• Gleiche Attributnamen werden durch Umbenennung in R eindeutig gemacht.
• Falls R eigene Attribute hat, werden diese hinzugenommen.
2.2. 1:n Beziehung zwischen nur 2 Entitytypen E und F (oft)):
– Keine Relation R aus Relationship,
statt dessen Primärschlüssel von E in Relation F als Fremdschlüssel aufnehmen.
Falls Relationship R eigene Attribute hat, müssen diese auch in F aufgenommen
werden.
2.3. 1:1 Beziehung zwischen nur 2 Entitytypen E und F:
– Keine Relation R aus Relationship,
statt dessen Primärschlüssel von E in Relation F
oder Primärschlüssel von F in Relation E als Fremdschlüssel aufnehmen.
2.4. isa Beziehungen und Existenzabhängigkeiten
– "E isa F" und Existenabhängigkeiten werden nicht in Relationen abgebildet,
da sonst redundante Tupel der Art isa (133, 133) entstehen.
Beispiel (selbst probieren):
Name
Adresse
Passagier
Vegetarier?
Passagier
Pass#
n
(1,*)
hat
gebucht
Preis
hat
gebucht
Sitz#
(0,*)
Datum
Flug
(1,1)
wird
ausgeführt
(0,*)
Flugzeug
G. Specht: Datenbanksysteme
m
vgl: n:m
Darstellung:
Flug
n
Flug#
wird
ausgeführt
Flugzeug#
Hersteller
Typ
1
Flugzeug
16
3-8
25.10.2012
Bsp.: KursDB
17
Bsp.: Relationen zur KursDB
Kurs
Kursleiter
Vorauss
Fuehrt_durch
KursNr
Titel
PersNr
Name
Gehalt
VorNr
KursNr
AngNr
G08
Grundlagen I
27183
Meier, I.
4300.50
G08
P13
1
G08
38197
G10
Grundlagen II
29594
Schulze, H.
3890.20
G10
P13
2
G08
38197
P13
C-Programmierung
38197
Huber, L.
4200.10
G08
I09
1
G10
43325
I09
Datenbanken
43325
Müller, K.
3400.80
G10
I09
2
G10
29594
P13
I09
1
P13
27183
2
P13
27183
1
I09
29594
2
I09
29594
3
I09
29594
Teilnehmer
TnNr
Name
Ort
Nimmt_teil
AngNr
KursNr
TnNr
143
Schmidt, M.
Bremen
2
G08
143
145
Huber, Chr.
Augsburg
2
P13
143
146
Abele, I.
Senden
1
G08
145
149
Kircher, B.
Bochum
1
P13
146
AngNr
155
Meier, W.
Stuttgart
1
I09
146
171
Möller, H.
Innsbruck
2
P13
173
Schulze, B.
Stuttgart
1
177
Mons, F.
Essen
185
Meier, K.
187
194
KursNr
Angebot
KursNr
Datum
Ort
1
G08
2000-10-13
München
149
2
G08
2000-11-24
Bremen
I09
155
1
G10
2000-12-01
München
1
I09
171
2
G10
2001-02-15
Hamburg
Heidelberg
1
I09
173
1
P13
2001-05-28
Innsbruck
Karstens, L.
Hamburg
2
P13
177
2
P13
2001-07-01
Essen
Gerstner, M.
Innsbruck
1
I09
185
1
I09
2001-03-27
Stuttgart
2
I09
187
2
I09
2001-04-23
Hamburg
1
P13
194
3
I09
2001-05-29
München
G. Specht: Datenbanksysteme
PersNr
18
3-9
25.10.2012
Sprachen des Basismodells
19
Sprachen des Basismodells
Zwei formale (mathematische) Abfragesprachen als Basis für reale Sprachen
(z.B.: SQL):
•Relationenalgebra:
operational (wird intern verwendet für die Optimierung und Ausführung)
•Relationenkalkül:
deklarativ (man beschreibt was man haben möchte, nicht wie)
20
G. Specht: Datenbanksysteme
3-10
25.10.2012
Sprachen des Basismodells cont.
Eigenschaften
•
•
Mengenorientiert (im Gegensatz zu tupelorientiert, navigierend)
–
abgeschlossen
d.h. Operationen liefern immer wieder Relationen
–
orthogonal
d.h. Operationen lassen sich beliebig kombinieren
Mathematische Fundierung:
–
Relationen-Algebra
(5 Basisoperatoren: Vereinigung, Differenz, Produkt, Selektion, Projektion)
–
Relationen-Kalkül
(vgl. Prädikatenkalkül 1. Ordnung)
21
Relationen-Algebra
22
G. Specht: Datenbanksysteme
3-11
25.10.2012
Die relationale Algebra: Operatoren
σ
Selektion
π
Projektion
ρ
Umbenennung
x
Kreuzprodukt
A
Join (Verbund)
∪
Vereinigung
∩
Durchschnitt
−
Mengendifferenz
÷
Division
F
Semi-Join (linker)
E
Semi-Join (rechter)
C
linker äußerer Join
D
rechter äußerer Join
Charakteristisch
„Konstruktion“ der
Ergebnis-Relation durch ggf.
geschachtelte Anwendung von
Algebra-Operationen auf die
Ausgangs-Relation(en).
23
Selektion
σF R
steht für eine Selektion (Tupelauswahl)
angewandt auf Relation R unter Anwendung
der Selektionsformel F
Anfrage
σTnNr > 155 Teilnehmer
TnNr
Name
Ort
171
Möller, H.
Innsbruck
173
Schulze, B.
Stuttgart
177
Mons, F.
Essen
185
Meier, K.
Heidelberg
187
Karstens, L.
Hamburg
194
Gerstner, M.
Innsbruck
Teilnehmer
TnNr
143
Name
Ort
Schmidt, M.
Bremen
145
Huber, Chr.
Augsburg
146
Abele, I.
Senden
149
Kircher, B.
Bochum
155
Meier, W.
Stuttgart
171
Möller, H.
Innsbruck
173
Schulze, B.
Stuttgart
177
Mons, F.
Essen
185
Meier, K.
Heidelberg
187
Karstens, L.
Hamburg
194
Gerstner, M.
Innsbruck
24
G. Specht: Datenbanksysteme
3-12
25.10.2012
Selektion cont.
Selektionsformel F
Vergleiche (<, >, >=, >=, <>) sowie logische Verknüpfungen (∧, ∨, ¬) davon über Attributwerte und Konstanten
Anfrage:
σ (TnNr <= 146) ∧ (Ort = ‚‘Innsbruck‘) Teilnehmer
TnNr
Name
143
Schmidt, M.
Ort
Bremen
145
Huber, Chr.
Augsburg
146
Abele, I.
Senden
171
Möller, H.
Innsbruck
194
Gerstner, M.
Innsbruck
Ergebnis: leere Rel.
Anfrage:
σ (TnNr < 180) ∧ (Ort = ‚‘Innsbruck') Teilnehmer
Ergebnis:
Formal:
TnNr
Name
Ort
171
Möller, H.
Innsbruck
sch(σF R) = sch(R)
val(σF R) = {t ∈ val(R) | F(t)}
25
Projektion
πAttr R
Steht für eine Projektion angewandt auf Relation R,
wobei Attr die Teilmenge der Attribute ist, auf die R abgebildet (projiziert) wird.
Anfrage:
π{TnNr,Name} Teilnehmer
Teilnehmer
TnNr
Name
Anfrage:
Ort
TnNr
π{Ort} Teilnehmer
Name
Ort
143
Schmidt, M.
Bremen
143
Schmidt, M.
145
Huber, Chr.
Augsburg
145
Huber, Chr.
Bremen
146
Abele, I.
Senden
146
Abele, I.
Augsburg
149
Kircher, B.
Bochum
149
Kircher, B.
Senden
155
Meier, W.
Stuttgart
155
Meier, W.
Bochum
171
Möller, H.
Innsbruck
171
Möller, H.
Stuttgart
173
Schulze, B.
Stuttgart
173
Schulze, B.
Innsbruck
187
Karstens, L.
Hamburg
187
Karstens, L.
Hamburg
194
Gerstner, M.
Innsbruck
194
Gerstner, M.
Formal:
sch(πL R) = L,
wobei L ⊆ sch(R)
val(πL R) = {t(L): ∃ t' ∈ val(R) ∧ t'(L) = t}
G. Specht: Datenbanksysteme
26
3-13
25.10.2012
Umbenennung
a) Explizite Umbenennung: Operator ρ (griechisch roh, von rename)
a1) Relationen-Umbenennung:
ρ NeuerRelName Rel
Bsp: ρ
k1
Kursleiter
a2) Attribut-Umbenennung
ρ NeuerAttrName <- AlterAttrN
ame
Rel
Benennt nur den Spaltennamen um (zur besseren Ausgabe)
Bsp: ρ Voraussetzung_fuer <- KursNr Vorauss
b) Implizite Umbenennung:
Attribut-Umbenennung
Es ist sinnvoll, auch den Projektions-Operator gleich mit der Möglichkeit zur
Attribut-Umbenennung zu versehen:
π NeuerAttrName : AlterAttrName Rel
27
Zusammengesetzte Anfragen
„Gib Teilnehmer-Nummer und -Name aller Teilnehmer aus Innsbruck aus“
Anfrage
π{TnNr,Name} (σOrt = Innsbruck' Teilnehmer)
Die logische Abarbeitungsreihenfolge
1. Schritt
Berechnung des σ-Ausdrucks
⇒ Rel1
2. Schritt
Anwendung des π-Operators auf Rel1 ⇒ Erg
Die alternative Formulierung
σOrt = ‚Innsbruck' (π{TnNr,Name}Teilnehmer)
wäre nicht korrekt. Warum? (Selektion enthält nur Ort, keine TnNr bzw. Namen mehr)
28
G. Specht: Datenbanksysteme
3-14
25.10.2012
Weitere Operatoren
R∪S
steht für die Vereinigung (union) der Relationen R und S,
wobei R und S strukturgleich sein müssen, d.h. es muss gelten: sch(R) = sch(S).
Kurzschreibweise
∪ i=1,2,..k Ri ≡ R1 ∪ R2 ∪ ... ∪ Rk
R-S
steht für die Differenz der Relationen R und S, d.h.
alle Tupel von R, die auch in S vorkommen, werden
aus R entfernt. (Auch hier gilt sch(R) = sch(S)).
R x S
steht für das kartesische Produkt
der Relationen R und S.
S
R
A
B
C
D
a1
b1
c1
d1
a2
b2
c2
d2
c3
d3
Anmerkung
R∩S
RxS
≡ R - (R - S)
ableitbar, wie üblich.
Formal
A
B
C
D
a1
b1
c1
d1
a1
b1
c2
d2
sch(R ∪ S)
= sch(R - (R - S)) = sch(R)
a1
b1
c3
d3
val(R ∪ S)
= val(R) ∪ val(S),
a2
b2
c1
d1
val(R - S)
= val(R) - val(S)
a2
b2
c2
d2
sch(R x S)
= sch(R) .∪. sch(S) disjunktive Vereinigung
a2
b2
c3
d3
val(R x S)
= {t | t(sch(R)) ∈ val(R) ∧ t(sch(S)) ∈ val(S)}
29
Verknüpfung von Tabellen
Kombination von x und σ, gleichzeitig Beispiel für die Verknüpfung von
Tabellen
Anfrage
„Welche Kurse (Ausgabe: Kurs-Nummer und -Titel) sind für welche
anderen Kurse (Ausgabe: Kurs-Nummer) Voraussetzung?“
Kurs
KursNr
Ausgangsrelationen
Titel
Vorauss
VorNr
KursNr
G08
Grundlagen I
G08
P13
G10
Grundlagen II
G10
P13
P13
C-Programmierung
G08
I09
I09
Datenbanken
G10
I09
P13
I09
Anfrage in der Relationalen Algebra
πVorNr,Titel,VorausFür:Vorauss.KursNr (σ VorNr = Kurs.KursNr (Vorauss x Kurs))
G. Specht: Datenbanksysteme
30
3-15
25.10.2012
Verknüpfung von Tabellen cont.
Abarbeitungsreihenfolge
1. Schritt
Berechnung Vorauss x Kurs ⇒ Rel1
2. Schritt
Anwendung von σ VorNr=Kurs.KursNr auf Rel1
Titel
VorNr
Vorauss.KursNr
Kurs.KursNr
G08
P13
G08
Titel
Grundlagen I
G08
P13
G10
Grundlagen II
...
...
...
...
G08
P13
I09
Datenbanken
G10
P13
G08
Grundlagen I
...
...
...
...
G10
P13
I09
Datenbanken
VorNr
Vorauss.KursNr
Kurs.KursNr
...
...
...
...
G08
P13
G08
Grundlagen I
P13
I09
I09
Datenbanken
G10
P13
G10
Grundlagen II
VorNr
G08
I09
G08
Grundlagen I
G08
G10
I09
G10
Grundlagen I
...
P13
I09
P13
C-Programmierung
P13
Titel
Vorauss_für
Grundlagen I
P13
...
...
C-Programmierung
I09
Mögliche Umbenennung von Attributen und Änderung der Attribut-Reihenfolge mittels
(erweitertem) π-Operator
π {VorNr, Titel, Vorauss_für: Vorauss.KursNr} Erg-Rel
bzw.
π {VorNr, Titel, Vorauss_für: Vorauss.KursNr}σ VorNr = Kurs.KursNr (Vorauss x Kurs)
31
Join (Verbund)
Die Verknüpfung von Tabellen aufgrund von Attributwert-Beziehungen ist eine häufige
Operation im relationalen Datenmodell, sie wird daher durch spezielle Join-Operation
explizit unterstützt.
R AF S steht für den Join (Verbund) der Relationen R und S unter Verwendung der
Verbundbedingung F.
R AF S ist semantisch äquivalent zu σF (R x S)
Beispiel (siehe Beispiel zuvor)
Vorauss A VorNr = KursNr Kurs
A-Ausführungslogik
entspricht:
σ VorNr = Kurs.KursNr (Vorauss x Kurs)
„Nested Loops Algorithmus“
for each Tupel x in Vorauss do
for each Tupel y in Kurs do
if x.VorNr = y.KursNr then
erzeuge Resultat-Tupel x || y und füge in Ergebnisrelation ein
fi
done
done
32
G. Specht: Datenbanksysteme
3-16
25.10.2012
Join cont.
Beispiel: „Gib KursNr und Titel aller Kurse sowie den Namen des Kursleiters aus, die
von dem Kursleiter mit der Personalnummer 27183 durchgeführt werden“
Kurs
KursNr
Titel
Kursleiter
PersNr
Name
Fuehrt_durch
Gehalt
AngNr
KursNr
PersNr
G08
Grundlagen I
27183
Meier, I.
4300.50
1
G08
38197
G10
Grundlagen II
29594
Schulze, H.
3890.20
2
G08
38197
P13
C-Programmierung
38197
Huber, L.
4200.10
1
G10
43325
I09
Datenbanken
43325
Müller, K.
3400.80
2
G10
29594
1
P13
27183
2
P13
27183
1
I09
29594
2
I09
29594
2
I09
29594
Mögliche Anfrageformulierung
π {Kurs.KursNr, Titel, Name}
(σ PersNr = 27183 (Kurs A (Kursleiter A Fuehrt_durch)))
Kurs.KursNr
=
Fuehrt_durch.KursNr
Kursleiter.PersNr
=
Fuehrt_durch.PersNr
Anmerkung
•
Die „Join-Bedingung“ kann auch mittels <, >, >=, >= sowie (∧, ∨, ¬) formuliert
werden.
33
Join cont.
Equi-Join, Theta-Join
•
Joins über “=“-Bedingung heißen: Equijoin
•
Joins über “<, >, ≤, ≥“ etc heißen: θ-Join (Theta-Join)
Natural-Join
1.
Joins mit "="-Bedingung sind am häufigsten.
•
Gleiche Spalten werden nur einmal benötigt.
Hierauf abgestellte Join-Variante: Natural Join
R A S steht für natürlichen Verbund (natural join) der Relationen R und S.
Wirkungsweise
•
Alle in R und S auftretenden Attribute gleichen Namens werden mittels "="-Bedingung verknüpft
und treten in der Ergebnisrelation nur einmal auf! (implizite Projektion!)
•
Haben R und S keine gemeinsamen Attribute, so hat R A S die gleiche Wirkung wie R x S.
34
G. Specht: Datenbanksysteme
3-17
25.10.2012
Join cont.
Beispiel: Die vorige Anfrage mittels natürlichem Verbund formuliert
π {KursNr, Titel} Kurs A ((σ PersNr = 27183 Kursleiter) A Fuehrt_durch)
Anmerkung Unterschied zum Equi-Join
•
Attribute gleichen Namens treten in der Ergebnis-Relation (sowie in allen
Zwischenergebnis-Relationen) natürlich jeweils nur einmal auf.
Also: sch(R A S) = sch(R) ∪ sch(S)
35
Beispiele zur Relationenalgebra
Gegeben
R
S
T
A
B
C
B
D
B
D
1
a
d
a
100
a
100
3
c
c
b
300
d
200
4
d
f
c
400
f
400
5
d
b
d
200
g
120
6
e
f
e
150
Anfragen und Ergebnisse
σ
D<300
S
π
{A,C}
R
π
{C}
B
D
A
C
C
a
100
1
d
d
d
200
3
c
c
e
150
G. Specht: Datenbanksysteme
4
f
f
5
b
b
6
f
S∪T
R
S - T
B
D
B
D
a
100
b
300
RA
R.B=S.B
S
A
R.B
C
S.B
D
1
a
d
a
100
3
c
c
c
400
4
d
f
d
200
T - S
5
d
b
d
200
B
D
6
e
f
e
150
b
300
c
400
c
400
e
150
d
200
e
150
f
400
f
400
g
120
g
120
36
3-18
25.10.2012
Beispiele zur Relationenalgebra cont.
RAT
SAT
R A A*100=D S
R×T
A
B
C
D
B
D
A
R.B
C
S.B
D
A
R.B
C
T.B
D
1
a
d
100
a
100
1
a
d
a
100
1
a
d
a
100
4
d
f
200
d
200
4
d
f
c
400
1
a
d
d
200
5
d
b
200
3
c
c
b
300
1
a
d
f
400
1
a
d
g
120
3
c
c
a
100
3
c
c
d
200
3
c
c
f
400
3
c
c
g
120
4
d
f
a
100
4
d
f
d
200
4
d
f
f
400
4
d
f
g
120
5
d
b
a
100
5
d
b
d
200
5
d
b
f
400
5
d
b
g
120
6
e
f
a
100
6
e
f
d
200
6
e
f
f
400
6
e
f
g
120
37
Äquivalenzumformungen
Seien R, S und T drei jeweils geeignet definierte Relationen.
Klassifikation algebraischer Umformungen
•
Kommutativität von unären Operationen (σ
σ, π):
U1 U2 R → U2 U1 R
•
Kommutativität von binären Operationen (∪, ∩ , ×, A):
RBS→SBR
•
Assoziativität von binären Operationen (∪, ∩ , ×, A):
R B (S B T) → (R B S) B T
•
Idempotenz (bzw. Zusammenfassung) von unären Operationen (σ
σ, π):
UR→UUR
•
Distributivität von unären Operationen in bezug auf binäre Operationen:
U (R B S) → (U R) B (U S)
Hinweis
•
•
Es gilt: Relations-Typ R ≡ Relations-Typ S ⇔ wenn sch(R) = sch(S)
Die Reihenfolge der Attribute ist hierbei ohne Bedeutung, d.h.
es gilt: R(A,B,C) ≡ R(A,C,B) ≡ R(C,A,B) ≡ ... ≡ R(C,B,A).
G. Specht: Datenbanksysteme
38
3-19
25.10.2012
Äquivalenzumformungen von
Relationalen-Algebra-Ausdrücken
39
Äquivalenzumformungen von
Relationalen-Algebra-Ausdrücken cont.
40
G. Specht: Datenbanksysteme
3-20
25.10.2012
Äquivalenzumformungen von
Relationialen-Algebra-Ausdrücken cont.
41
Erläuterungen zu den Äquivalenzumformungen
Gegeben seien die Relationen R(A,B,C), R1(A,B,C), R2(A,B,C), S(D,E) und T(F,G,H) wobei die
Wertebereiche der Attribute A bis H jeweils Teilmengen der natürlichen Zahlen sein sollen.
Zu 1: σA<10 ∧ C>8 (σ B>8 R) kann in σB>8(σA<10 ∧ C>8 R) transformiert werden und umgekehrt.
Zu 2: σB<200 (π{A,B} R) kann in π{A,B} (σB<200 R) transformiert werden. - Geht man von der rechten Seite aus,
d.h. von π{A,B} (σB<200 R), so kann die Transformation nur dann durchgeführt werden, wenn sich die
Selektions-Bedingung lediglich auf Attribute bezieht, die auch in der Projektion spezifiert sind (siehe NB
zu Regel 2). Im vorliegenden Fall entspricht Attr(F) der Attributmenge {B} und A entspricht der
Attributmenge {A,B}. Die Nebenbedingung ist also erfüllt. D.h. die Transformation in die "←"-Richtung
ist ebenfalls möglich.
Zu 8: Gegeben sei (R A A=D S) A E=F T. Für die "→"-Transformation muss folgende Nebenbedingung erfüllt
sein: {E,F} ⊆ ({D,E} ∪ {F,G,H}). Dies ist hier der Fall. Der Ausdruck kann somit in R A A=D (S A E=F T)
transformiert werden. - Bei (R A A=D S) A A=F T ginge dies z.B. hingegen nicht.
Zu 9: π {A} R kann in π {A} π {A,B} R transformiert werden und umgekehrt.
Zu 10: σ A<100 ∧ B>30 R kann zerlegt werden in σ A<100 σ B>30 R. Umgekehrt kann man σ A<100 σ B>30 R durch
Zusammenfassen der Selektionsbedingungen (UND-Verknüpfung) in σ A<100 ∧ B>30 R transformieren.
42
G. Specht: Datenbanksysteme
3-21
25.10.2012
Erläuterungen zu den Äquivalenzumformungen cont.
Zu 11: σ B<300 (R1 ∪ R2) kann in (σB<300 R1) ∪ (σB<300 R2) transformiert werden und umgekehrt.
Anmerkung: Hier ist keine Nebenbedingung erforderlich, da die Vereinigung nur zwischen Relationen
gleichen Typs definiert ist.
Zu 12: σB<300 (R1 − R2) kann in (σB<300 R1) − (σB<300 R2) transformiert werden und umgekehrt. (σ bei R2
kann auch entfallen!)
Zu 13: Gegeben sei σ A<300 ∧ D>50 (R × S). Dieser Ausdruck kann in zwei Selektion überführt werden, indem
man die Selektions-Bedingung geeignet „aufspaltet“. In diesem Fall wäre etwa (σ A<300 R) × (σ D>50 S)
eine mögliche Aufspaltung.
Zu 14: Da ein Verbund R A F S äquivalent zu σF (R × S) ist, gilt das im vorangegangenen Beispiel Gesagte
– analog übertragen – auch hier.
Zu 15: Ein Ausdruck der Art π {A,B} {R1 ∪ R2) kann stets „ausmultipliziert“ werden zu (π {A,B} R1) ∪ (π {A,B}
R2).
Zu 16: Die Nebenbedingung für die "→"-Richtung besagt, dass nach dem „Ausmultiplizieren“ die
Projektions-Attribute so gewählt werden müssen, dass sie für die jeweilige Relation auch definiert sind.
Im Falle des Ausdruckes π {A,R.B,D} (R × S) wäre z.B. (π {A,R.B} R) × (π {D} S) eine korrekte Transformation,
(π {A} R) × (π {R.B, D} S) hingegen nicht.
43
Erläuterungen zu den Äquivalenzumformungen cont.
Zu 17: Die Nebenbedingung für die "→"-Richtung kann wie folgt interpretiert werden: Sind die in der
Verbund-Bedingung angegebenen Attribute eine Teilmenge der in der Projektion angegebenen
Attribute (d.h. gilt Attr(F) ⊆ A), dann kann der Ausdruck „ausmultipliziert“ werden, wobei wieder zu
beachten ist, dass die in der Projektion auf der linken Seite angegebenen Attribute wieder korrekt auf
ihre Relationen „verteilt“ werden.
Der Ausdruck π{A,B,E}(R A B<E S) kann z.B. transformiert werden in (π {A,B} R) B<E (π {E} S).
π {A,B,D} (R A B<E S) hingegen wäre nicht transformierbar, da {B,E} ⊄ {A,B,D}.
Die umgekehrte Richtung ("←") ist trivial. Hier sind lediglich die Projektions-Attribute
zusammenzufassen.
Wichtiger "Spezialfall": π A1 ∪ A2 R ≡ ? (π A1 R) A (π A2 R) "←"-Richtung gilt i.a. nicht !! Voraussetzung,
damit es doch gilt: „lossless join“ → siehe Kapitel 4
Zu 23: R − σ B<200 R kann in σ B ≥ 200 R transformiert werden und umgekehrt.
Zu 26: (σ A<10 R) − (σ B>100 R) kann in σ A<10 ∧ B≤100 R transformiert werden und umgekehrt.
44
G. Specht: Datenbanksysteme
3-22
25.10.2012
Abgeleitete Operatoren der Relationenalgebra
R ∩ S Durchschnitt
S
wie üblich: R ∩ S ≡ R - (R - S)
A
A
B
a1
a1
b1
a2
a2
b1
a3
a3
b1
a4
b1
a1
b2
a3
b2
a2
b3
R÷S
a3
b3
„Welchen Lieferanten liefern alle Teile?“
B
a4
b3
„Welche Mitarbeiter arbeiten an allen Projekten mit?“
„Welche Kursleiter können alle Kurse halten?“
b1
a1
b4
b4
a2
b4
a3
b4
R ÷ S Division
Sei D = R ÷ S, dann muss gelten:
sch(S) ⊂ sch(R)
sch(D) = sch(R) - sch(S)
t ∈ D ⇔ ∀ s ∈ val(S): < t,s > ∈ val(R)
Anwendungsbeispiele
R
Berechnung von D äquivalent zu
(1) Temp1 ← π Attr(R -S) R
(2) Temp2 ← π Attr(R -S) (( S × Temp1 ) - R)
(3) D ← Temp1 - Temp2
45
Abgeleitete Operatoren der Relationenalgebra cont.
RC
F
S
Left Outer Join
(Einseitiger) „äußerer-Verbund“. Alle Tupel der linken Relation (d.h. alle R-Tupel) sind im Ergebnis
enthalten. Gibt es für ein Tupel ri ∈ R kein S-Tupel, das F erfüllt, so werden die S-Attribute im
Ergebnistupel mit NULL aufgefüllt.
R
A
a1
b1
B
b1
c1
b2
b1
c2
a3
b4
b2
c3
a4
a5
b2
b3
R
C
a2
a4
Analog
S
B
c6
b5
b1
C
R.B=S.B S
R.A
R.B
S.B
S.C
a1
b1
b1
c1
a1
b1
b1
c2
a2
b2
b2
c3
a3
b4
--
--
a4
b2
b2
c3
a4
b5
--
--
RC S
Left Outer Join
a5
b1
b1
c1
RD
R
Right Outer Join
Full Outer Join
a5
b1
b1
c2
S
S
⇐ Nullwert!
⇐ Nullwert!
Weitere Join-Varianten
Semijoin
R E S:= π (R A S)
…alle Attribute von R
Geeignet für Fragen: wie viele Joinpartner existieren zu S in R.
G. Specht: Datenbanksysteme
46
3-23
25.10.2012
Bsp. für Query-Auswertung: Weinfreund
•
DB-Schema:
– Weinfreund (P#, Name, Vorname)
– Konsum (P#, W#, Datum, Menge)
– Wein (W#, Weinberg, Jahrgang, Prozent, Rebsorte)
•
“Wieviel Prozent Alkohol haben die 78’er Weine des Weinbergs ‘Würzburger
Stein’?”
π{Prozent, w#} (σ(Jahrgang = 1978) ∧ (Weinberg = ’Würzburger Stein’)(Wein))
47
Bsp. Weinfreund cont.
•
DB-Schema:
– Weinfreund (P#, Name, Vorname)
– Konsum (P#, W#, Datum, Menge)
– Wein (W#, Weinberg, Jahrgang, Prozent, Rebsorte)
•
“Ermittle Name und Vorname von Weinfreunden von ‚Silvaner‘ und ‚Riesling‘”
π{Name, Vorname}
(Weinfreund A ( Konsum A (σ(Rebsorte = ‘Silvaner‘) ∨ (Rebsorte=‘Riesling‘)(Wein))))
48
G. Specht: Datenbanksysteme
3-24
25.10.2012
Bsp. Weinfreund cont.
•
DB-Schema:
– Weinfreund (P#, Name, Vorname)
– Konsum (P#, W#, Datum, Menge)
– Wein (W#, Weinberg, Jahrgang, Prozent, Rebsorte)
•
“Gesucht sind Name und Vorname von Weinfreunden, die an einem Tag mehr
als 10 Gläser 86’er Obereisenheimer Höll getrunken haben, sowie der
dazugehörige Alkoholgehalt.”
π{Name, Vorname, Prozent}
(σ(Menge > 10) ∧ (Weinberg=‘Obereisenheimer Höll‘) ∧ (Jahrgang=1986)
(Weinfreund A Konsum A Wein)
)
49
Bsp. Weinfreund cont.
•
DB-Schema:
– Weinfreund (P#, Name, Vorname)
– Konsum (P#, W#, Datum, Menge)
– Wein (W#, Weinberg, Jahrgang, Prozent, Rebsorte)
•
“W# aller Weine mit mehr Prozent Alkohol als ‘Riesling 1993‘”
π{W2, W#}
(σ(w1.Rebsorte=‘Riesling‘) ∧ (Jahrgang=1993)) (Wein W1 A Wein W2))
W1.Prozent < W2.Prozent
50
G. Specht: Datenbanksysteme
3-25
25.10.2012
Aggregation
Mengenorientierte Operation, die
•
zuerst eine Partitionierung einer Relation in Teilmengen gemäß
einer Gruppe von Attributwerten vornimmt (Gruppierung),
•
dann eine Aggregatsfunktion (z.B. sum, min, max, avg, etc.) auf
jeder Teilmenge auswertet.
•
Das Ergebnis ist eine Relation, die für jede Gruppe ein Tupel mit
dem Aggregationswert enthält.
Sei R(x1, ..., xn, y, ...) eine Relation, mit Gruppierungsattributen X = {x1, ..., xn} und
Aggregationsattribut y, und agg eine Aggregationsfunktion auf y:
groupby (R, X, agg, y, duplicates)
mit duplicates ∈ {distinct, all}.
51
Aggregation cont.
Häufig verwendete Aggregations-Funktionen:
– COUNT
– SUM
– MIN
– MAX
– AVG
52
G. Specht: Datenbanksysteme
3-26
25.10.2012
Aggregation cont.
•
„Wie hoch ist jeweils der durchschnittliche Alkoholgehalt der Jahrgänge 1985
und 1986?”
σ(Jahrgang=1985) ∧ (Jahrgang=1986) (groupby(Wein, Jahrgang, AVG, Prozent, all))
53
Aggregation cont.
•
Anmerkung:
Aggregationen sollten im Allgemeinen auf Mengen mit Duplikaten (Multisets)
angewendet werden, sonst entstehen falsche Ergebnisse.
•
Beispiel:
Annahme, es gibt einen weiteren 85’er Wein mit 12.0%, dann ergäbe AVG({11,
10, 12, 12}) mittels “distinct” dasselbe (jetzt falsche) Resultat.
54
G. Specht: Datenbanksysteme
3-27
25.10.2012
Query Optimierung
•
Motivationsbeispiel:
Sei die Kardinalität der Relationen R und S jeweils 10000
•
Naiver Ansatz:
Join wie in Definitionen als σ (R x S) berechnen
108 = 100 Mio.
108 Tupelzugriffe, je Zugriff nur 10-6 sec
Antwortzeit: 100sec!!! Viel zu lange, praktisch untragbar
55
1. Nichtalgebraische Optimierungen
D.h. einzelne Operationen günstiger implementieren.
•
Komplexitäten:
– Selektion:
• Relationen-Scan (sequentieller Durchlauf)
O(n)
• Index als B-Baum
O(log n)
• Index als Hash
O(1) – hoffentlich
– Projektion
• naiv
O(n2)
• mit Index
O(n log n) <= meist
• Mit Hashindex
O(n) <= wirklich gute Impl.
+ Kosten für Anlegen des Index
56
G. Specht: Datenbanksysteme
3-28
25.10.2012
Nichtalgebraische Optimierungen cont.
Join
O(n2)
nested-loop-Join (naiv)
for i:=1 to |R| do
for j := 1 to |S| do
if ri θ sj then Rel := Rel ∪ append(r, s);
sort-merge-Join
O(n log n)
RAA
S
=B
R sei sortiert nach A
S sei sortiet nach B
…,
…
…,
…
…,
…
…,
…
3, …
…, 2,
4, …
…, 4,
4, …
…, 4,
5, …
…, 6,
57
Nichtalgebraische Optimierungen cont.
Hash Join R A S
O(n) (sei |R|=n)
1. |R| sei klein (z.B. Join- oder Selektionsausgabe)
2. auf S.B liege Hash
•Fragen des Optimierers (Programm):
– Können bestehende Indexe ausgenutzt werden?
– Rentiert es sich, einen temporären Index anzulegen, so dass trotz
Indexerzeugung die Query-Auswertung schneller wird (auch Indexe
brauchen Platz!).
58
G. Specht: Datenbanksysteme
3-29
25.10.2012
2. Algebraische Optimierungen
Ausnützen der Gesetze der relationalen Algebra als Rechenregeln, um möglichst
kleine Zwischenrelationen zu erhalten!
1.R A (S A T) = (R A S) A T
=> optimale Joinreihenfolge
2.σF1(σF2(R)) = σF1 ∧ F2(R)
3.σF(R A S) = σF(R) A S
falls F nur Attribute aus R betrifft
4.σF(R A S) = R A σF(S)
falls F nur Attribute aus S betrifft
5.σF(πA(R)) = πA(σF(R))
falls Attribute(F) ⊆ A
usw.
Dazu wird eine komplette Query vom Optimierer in einen Operatorbaum
transformiert und dieser dann transformiert.
59
Algebraische Optimierungen cont.
•
Beispiel:
„Name, Vorname von Weinfreunden, die an einem Tag mehr als 10 Gläser 86‘er
Obereisenheimer Höll getrunken haben, so wie der zugehörige Alkoholgehalt“
πName, Vorname, Prozent
(σMenge > 10 ∧ Weinberg = “Obereisenheimer Höll” ∧ Jahrgang = 1986(Weinfreund A (Konsum A Wein)))
Operatorbaum:
60
G. Specht: Datenbanksysteme
3-30
25.10.2012
Baumtransformationen zur Optimierung
z.B. Selektionen und Projektionen zu den Blättern schieben,
d.h. heuristisch “möglichst kleine Zwischenergebnisse produzieren”.
Ergebnis:
Jetzt viel kleinere Zwischenergebnisse => Joins (n log m) viel billiger
Gute Optimierer bauen ist schwierig, da allein das Problem der richtigen
Joinreihenfolge NP-vollständig ist.
61
Abschließende Bemerkungen zur Relationen-Algebra
•
In der Relationalen Algebra ist kein Komplementoperator definiert.
Grund: im Allgemeinen ∞-große Relationen (außer bei endlichen Domänen)
•
Relationen-Algebra als Datenbanksprache nur bei den ersten relationalen
DBMS-Prototypen als Anfragesprache verwendet
•
Jedoch bis heute wichtige formale Grundlage für DBMS-interne AnfrageVerarbeitung und Optimierung.
•
Darüberhinaus dient die Relationale Algebra als theoretisches Maß für die
Ausdrucksmächtigkeit relationaler Datenbank-Sprachen
→ „relationale Vollständigkeit“
•
Relationale Algebra ist nicht rein deskriptiv, wegen Reihenfolgen
abhängigkeiten (funktionale Sprache). Jedoch: Äquivalenz-Umformungen
erlauben Optimierung.
62
G. Specht: Datenbanksysteme
3-31
25.10.2012
Relationen-Kalkül
63
Relationen-Kalkül
Relationen-Algebra
•
„Konstruktion“ der Ergebnisrelation durch sukzessive (geschachtelte) Anwendung von
Algebra-Operatoren auf die Ausgangsrelationen
(→ prozedurale Vorgehensweise)
Relationen-Kalkül liegt andere Philosophie zugrunde:
•
Beschreibung, welche Bedingungen (Prädikate) die Tupel der Ergebnisrelation erfüllen
müssen, vgl. Prädikatenkalkül
(→ deklarative Vorgehensweise)
64
G. Specht: Datenbanksysteme
3-32
25.10.2012
Beispiel
Gegeben seien die folgenden Relationen:
Vorauss(VorNr, KursNr)
Kurs(KursNr, Titel)
Angebot(AngNr, KursNr, Datum, Ort)
Zu beantworten sei folgende Anfrage:
„Gib für alle Kurse, die zwischen dem 1.1.12 und 31.3.12 stattfanden und den Kurs
G08 als Voraussetzung haben, die KursNr, den Titel, das Datum und den Ort
aus.“
65
Anfrageformulierung
In Algebra (schrittweise Konstruktion der Ergebnismenge)
π KursNr, Titel, Datum, Ort
(( Kurs A σ 1.1.12 < Datum < 31.3.12 Angebot) A (σ VorNr = 'G08' Vorauss))
Tupel-Relationenkalkül (prädikative Beschreibung der Ergebnismenge)
{t|
( ∃ a ( ∃ v ( ∃ k (Kurs(k) ∧ Angebot(a) ∧ Vorauss(v) ∧
k.KursNr = a.KursNr ∧ k.KursNr = v.KursNr ∧
a.Datum > 1.1.12 ∧ a.Datum < 31.3.12 ∧
v.VorNr = 'G08' ∧
t.KursNr = k.KursNr ∧ t.Titel = k.Titel ∧
t.Datum = a.Datum ∧ t.Ort = a.Ort )))) }
66
G. Specht: Datenbanksysteme
3-33
25.10.2012
Anfrageformulierung cont.
Relationenkalkül
•
vgl. Prädikatenlogik 1. Stufe
•
Tupel-Relationenkalkül vs. Domain-Relationenkalkül :
Variablen für ganze Tupel bzw. für einzelne Attributwerte
67
Tupel-Relationenkalkül (TRC)
• „Atome“
1. R(t) :
R = Relationenname
t = Tupelvariable
Aussage: „Tupel t ist in R enthalten“
2. X Θ Y:
X, Y = Konstanten oder Tupelkomponenten t[i]
(t = Tupelvariable, i = i-te Tupelkomponente)
Θ = arithm. Vergleichsoperator (<, >, =, ...)
Alle Tupel einer Relation haben eine konstante Stelligkeit.
Falls hierauf explizit Bezug genommen wird, so schreiben wir t(s) .
68
G. Specht: Datenbanksysteme
3-34
25.10.2012
Tupel-Relationenkalkül (TRC)
• „freie / gebundene Variablen“:
Analogie:
– gebundene Variablen
≈
lokale Variablendeklaration einer Prozedur,
kann nicht von außen referenziert werden.
– freie Variablen
≈
globale Variablen,
außerhalb der betrachteten Prozedur deklariert.
Sei eine freie Tupelvariable t „global“ bzgl. Formel F,
dann entspricht (∃t) bzw. (∀t) in etwa der „Deklaration“ der Variablen t.
69
Tupel-Relationenkalkül (TRC) cont.
Formeln, freie und gebundene Variablen im TRC:
•
Jedes Atom ist eine Formel.
Alle in einem Atom auftretenden Tupelvariablen sind „frei“
•
Falls F1 und F2 Formeln sind,
dann sind auch ¬ F1, (F1), F1 ∧ F2 und F1 ∨ F2 Formeln.
•
Wenn F eine Formel ist, dann ist „(∃ t F)" auch eine Formel. Alle in F
auftretenden freien Tupelvariablen t werden an ∃ t in der Formel " ∃ t F"
gebunden. Der Status anderer Tupelvariablen in F ändert sich dadurch nicht
•
Wenn F eine Formel ist, dann ist „(∀ t F)" auch eine Formel. Alle in F
auftretenden freien Tupelvariablen t werden an t in der Formel " (∀ t F)"
gebunden. Der Status anderer Tupelvariablen in F ändert sich dadurch nicht
•
Nichts anderes ist eine Formel
70
G. Specht: Datenbanksysteme
3-35
25.10.2012
Tupel-Relationenkalkül (TRC) cont.
Anfrage im TRC:
{ t | F(t) } mit t als einziger freien Tupelvariablen in Formel F
Anmerkung:
Eine Anfrage des TRC liefert nicht notwendig eine endliche Tupelmenge!
71
Beispiel
Vereinigung von R1 und R2: { t | R1(t) ∨ R2(t) }
Anmerkungen:
– Jedes Tupel hat auch eine feste Stelligkeit. R1 und R2 müssen also entsprechend
„kompatibel“ sein.
– In dieser einfachen Form sind alle Komponenten (Attribute) auch „domainkompatibel“.
„Gib alle Tupel t, die nicht in Relation R vorkommen, aus !“ (Negation):
{ t | ¬ R(t) }
Anmerkungen:
– Welche Ergebnistupel (Schema) ?
Vereinfachende Annahme: Schema von R
– Welche Ausprägungen ?
Vereinfachend: Komplement von R bzgl. Produkt der Attributdomains
– Resultat von Domains abhängig!
evtl. nicht endlich!
72
G. Specht: Datenbanksysteme
3-36
25.10.2012
Beispiel cont.
•
Projektion auf Attribute (Komponenten) i1, i2, ..., ik von R
{ t (k) | ∃ u ( R(u) ∧ t[1] = u[i1] ∧ ... ∧ t[k] = u[ik] ) }
•
Selektion aller Tupel aus R, die Bedingung F erfüllen: { t | R(t) ∧ F (t) }
– F(t) steht hier stellvertretende für die konkrete Bedingung an die Tupelkomponente(n)
– z.B. (t[1] = 17) ∧ (t[3] = 24)
•
Differenz zweier Relationen R und S: { t | R(t) ∧ ¬ S(t) }
•
Kartesisches Produkt von R und S:
{ t(r+s) |
(∃ u(r) (∃ v(s) ( R(u) ∧ S(v)
∧ t[1] = u[1] ∧ ... ∧ t[r] = u[r]
∧ t[r+1] = v[1] ∧ ... ∧ t[r+s] = v[s] ) }
73
Sicherer Tupel-Relationenkalkül
Problem:
Bei bisheriger TRC-Definition können unendlich Ergebnismengen auftreten
{ t | ¬ R(t) } : nur Einschränkung hinsichtlich Stelligkeit von t
(≡ R), hinsichtlich des Domains aber nicht beschränkt
Überlegung:
1. Wir fragen nach Werten aus der Datenbank, nicht von „sonst
irgendwoher“
2. Jede Relation in der konkreten Datenbank ist endlich, damit ist auch
der betrachteten Datenbank-Zustand endlich
3. Einschränkung: Als Domain (für die Auswertung von Anfragen) werden
nur in der DB vorkommende Werte oder in der Anfrage auftretende
Konstanten zugelassen
74
G. Specht: Datenbanksysteme
3-37
25.10.2012
Definition „Safety“
Eine Formel F des TRC heißt sicher, wenn
a) keine ∀ - Quantoren vorkommen
b) bei F1 ∨ F2, F1 und F2 jeweils nur eine freie Variable haben, und zwar die
gleiche
c) bei (maximalen) konjunktiven Teilformeln F1 ∧ F2 ∧ ... ∧ Fn alle freien
Tupelkomponenten in den Fi begrenzt sind:
− Fi nicht negiert, kein arithm. Vergleich, freie Tupelvariable t → alle Komp. von t
begrenzt
− Fi ≡ t[a] = c oder Fi ≡ c = t[a], für c ... Konstante → t[a] begrenzt
− Fi ≡ t[a] = t'[a']
oder Fi ≡ t'[a'] = t [a] und t' [a'] begrenzt → t[a]
begrenzt
d) Negation (¬) nur auf Termen innerhalb einer Konjunktion wie in c) erlaubt
75
Definition „Safety“ cont.
Bemerkung zu a)
•
(∀ t) F(t) ⇔ ¬ (∃ t) (¬ F(t) ) ... d.h. keine Einschränkung
•
Alternativ:
∀ nur in der Form:
... und bei ∃:
(∀ t) (¬ R(t) ∨ ...)
(∃ t) ( R(t) ∨ ...)
76
G. Specht: Datenbanksysteme
3-38
25.10.2012
Relationale Vollständigkeit
Satz:
Relationenalgebra und sicherer Relationenkalkül (TRC) sind äquivalent
Beweisidee:
Finde zu jedem Ausdruck in Relationenalgebra einen sicheren TRC
Ausdruck und umgekehrt (siehe Lehrbücher)
„Relational Completeness“
Eine Anfragesprache für das Relationenmodell heißt
relational vollständig, wenn sie (mindestens) so ausdruckskräftig wie
die Relationenalgebra (oder der sichere TRC) ist [Codd 70]
77
G. Specht: Datenbanksysteme
3-39