Document

Rückblick: Datenorganisation & Indexstrukturen
§ Datenorganisation der Tupel einer Relation als Haufen,
sequenzielle Datei oder indexsequenzielle Datei
§ Indexstrukturen zum effizienteren Zugriff auf Datensätze
anhand Primärschlüssel oder anhand anderer Attribute
§ B-Bäume (B) als Indexstruktur auf Sekundärspeicher,
die Wertanfragen effizient unterstützt
§ B+-Bäume (B+) als Verbesserung,
die auch Bereichsanfragen effizient unterstützt
§ Hashbasierte Indizes (H) als Indexstruktur,
die Wertanfragen effizient unterstützen
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
116
Geeignete Indizes für die Zugriffsarten
§ Nachschlagen eines Tupels anhand von Primärschlüssel
(z.B. Tupel zu Kunde mit KundenNr 187566)
§ B-Baum, B+-Baum, Hashbasierte Indizes
§ Finde Tupel mit bestimmtem Attributwert
(z.B. Tupel zu Kunden mit PLZ 66117)
§ B-Baum, B+-Baum, Hashbasierte Indizes
§ Finde Tupel mit Kombination von Attributwerten
(z.B. Tupel zu Kunden namens Müller mit PLZ 66117)
§ B-Baum, B+-Baum, Hashbasierte Indizes
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
117
Geeignete Indizes für die Zugriffsarten
§ Finde Tupel mit Attributwert in bestimmten Bereich
(z.B. alle Kunden mit PLZ in 661*)
§ B+-Baum
§ Finde Tupel mit Attributwerten in bestimmten Bereichen
(z.B. alle Kunden namens M* mit PLZ in 661*)
§ ???
§ Wir brauchen also noch Indexstrukturen, welche
mehrdimensionale Bereichsanfragen
effizient unterstützten
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
118
Sortieren mit Indizes
§ Beispiel: Kunden mit PLZ 66119 sortiert nach Namen
1
2
CREATE INDEX Kunden_PLZ_Name
ON Kunden ( PLZ ASC , Name ASC )
§ Blattebene des resultierenden B+-Baumes enthält
Schlüssel der Form PLZ$Name aufsteigend sortiert
66117$Adam
66117$Bär
…
66121$Angst
66121$Bart
§ RDBMS kann nach erstem Schlüssel 66119$ suchen
und dann die Kunden in sortierter Reihenfolge
mittels Durchlaufen der Blätter ermitteln
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
119
Mehrdimensionale Bereichsanfragen
§ Beispiel: Kunden mit Namen M* mit PLZ in 661*
(66129, Marx)
M
(66121, Maas)
L
Name
N
Z
(66131, Wolf)
A
(66113, Calles)
65934
66113
66117
66121
66123
66125
66127
66129
66131
66271
66287
PLZ
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
120
Mehrdimensionale Bereichsanfragen
§ Mehrdimensionale Bereichsanfrage lässt sich i.A. nicht
effizient mit einem oder mehreren eindimensionalen
Indizes (z.B. basierend auf B+-Bäumen lösen)
(66129, Marx)
M
(66121, Maas)
L
§ Index auf PLZ, Name
Name
N
Z
(66131, Wolf)
A
(66113, Calles)
65934
66113
66117
66121
66123
66125
66127
66129
66131
66271
66287
PLZ
(66129, Marx)
M
(66121, Maas)
L
§ Index auf Name, PLZ
Name
N
Z
(66131, Wolf)
A
(66113, Calles)
65934
66113
66117
66121
66123
66125
66127
66129
66131
66271
66287
PLZ
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
121
Mehrdimensionale Bereichsanfragen
§ Mehrdimensionale Bereichsanfrage lässt sich i.A. nicht
effizient mit einem oder mehreren eindimensionalen
Indizes (z.B. basierend auf B+-Bäumen lösen)
§ Beispiel: Kunden mit Namen M* mit PLZ in 661*
§ es kann sehr viele Kunden mit Namen M* geben
§ es kann sehr viele Kunden mit PLZ in 661* gegen
(aber nur wenige, auf die beides zutrifft)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
122
Mehrdimensionale Bereichsanfragen
§ Wir konzentrieren uns auf den Fall mit zwei Dimensionen;
die vorgestellten Indexstrukturen funktionieren mit
beliebiger Anzahl von Dimensionen
0
1
2
3
0
§ Können wir Tupeln einen Schlüssel
anhand ihrer x-/y-Werte zuweisen,
so dass beieinander liegende Tupel
beieinander liegende Schlüssel
bekommen?
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
1
X
2
3
Y
123
Raumfüllende Kurven
§ Raumfüllende Kurven „durchlaufen“ einen
mehrdimensionalen Raum derart, dass
benachbarte Bereiche möglichst kurz
hintereinander besucht werden
§ Z-Kurve „durchläuft“ den Raum
im Zick-Zack; sie lässt sich
durch Bit-Verschachtelung
implementieren
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
X
0
1
2
3
0
1
4
5
0
2
3
6
7
1
8
9
12
13
2
10
11
14
15
3
Y
124
Raumfüllende Kurven
§ Bit-Verschachtelung (bit interleaving)
§ m Dimensionen mit je 2n Werten (n Bits)
§ Schlüssel für Tupel mit Wert wi
für i-te Dimension bestimmt als
w1[1] … wm[1] … w1[n] … wm[n]
mit wi[j] als j-tes Bit des Werts wi
X
00
01
10
11
0
1
4
5
00
2
3
6
7
01
8
9
12
13
10
10
11
14
15
11
Y
§ Beispiel: Tupel mit x = 3 = (11)2
und y = 2 = (10)2 erhält den Schlüssel
(1110)2 = 14, mit X- als erster und Y- als zweiter Dimension
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
125
Raumfüllende Kurven
§ Tupel werden nun anhand des mittels einer raumfüllenden
Kurve ermittelten Schlüssels in einem B+-Baum indiziert
§ Mehrdimensionale Bereichsanfrage
wird nun in entsprechenden
Wertebereich übersetzt
§ Beispiel: Tupel mit x
[1,2] und y
liegen im Wertebereich [3, 13]
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
X
[1,3]
0
1
2
3
0
1
4
5
0
2
3
6
7
1
8
9
12
13
2
10
11
14
15
3
Y
126
Rekursives Partitionieren
§ Verwandter alternativer Ansatz
besteht darin, mehrdimensionalen
Raum rekursiv in gleich große
Bereiche zu unterteilen
§ Der Schlüssel eines Tupels setzt
sich dann aus den Nummern
seiner Bereiche von grober
zu feiner Granularität
zusammen
0
1
2
3
0
0
1
1
X
2
2
3
3
Y
X
0
1
2
3
0
1
0
1
0
2
3
2
3
1
0
1
0
1
2
2
3
2
3
3
Y
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
127
Rekursives Partitionieren
§ Beispiel: Tupel mit x = 3 und y = 2 liegt
in Bereich 3 auf erster und
in Bereich 2 auf zweiter Ebene
und erhält als Schlüssel (11|10)2
0
1
2
3
0
0
1
1
X
2
2
§ Microsoft SQL Server bspw.
verwendet eine ähnliche Idee,
um räumliche Daten
zu indizieren [3]
3
3
Y
X
0
1
2
3
0
1
0
1
0
2
3
2
3
1
0
1
0
1
2
2
3
2
3
3
Y
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
128
R-Bäume
§ Bisher betrachtete Indexstrukturen zur Unterstützung
mehrdimensionaler Bereichsanfragen bilden
mehrdimensionale Daten auf eine einzelne
Dimension ab („linearisieren“) und
verwenden dann B+-Baum
§ Zudem können sie nur mehrdimensionale Punkdaten,
jedoch keine mehrdimensionalen Flächenobjekte,
z.B. aus geografischen Anwendungen, indexieren
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
129
R-Bäume
§ R-Baum ist ein balancierter Suchbaum für
mehrdimensionale Punkt- und Flächenobjekte
§ Knoten ist ein minimales umschließendes Rechteck (MBR)
(minimum bounding rectangle) zugeordnet,
welches alle im entsprechenden Unterbaum
indexierten Objekte vollständig enthält
§ MBRs unterschiedlicher Knoten dürfen sich überlappen
§ MBR der Wurzel enthält alle indexierten Objekte vollständig
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
130
R-Bäume
§ Beispiel:
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
131
R-Bäume
§ Beispiel:
A
E
A
E
B
C
D
F
B
C
D
F
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
132
R-Bäume
§ Beispiel:
G H
A
G
I
E
A E
B C
D F
B
H
C
D
I
F
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
133
R-Bäume
§ Beispiel:
J
G H
A
G
E
A E
H J
I
B C
D F
B
C
D
I
F
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
134
R-Bäume
§ Einfügen und Löschen ähnlich zum B-Baum, d.h. es wird
zuerst ein Blattknoten identifiziert und dann ggf. Knoten auf
dem Weg zur Wurzel geteilt oder verbunden
§ Mehrdimensionale Bereichsanfrage traversiert R-Baum
und besucht alle Knoten, deren MBR mit dem
Anfragebereich überlappt
§ R-Bäume unterstützen zudem Anfragen nach den
k-nächsten-Nachbarn eines Punktes
(k nearest neighbors)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
135
Mehrdimensionale Bereichsanfrage im R-Bäumen
§ Beispiel: Suche nach Anfragebereich
J
G H
A
G
E
A E
H J
I
B C
D F
B
C
D
I
F
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
136
Mehrdimensionale Bereichsanfrage im R-Bäumen
§ Beispiel: Suche nach Anfragebereich
J
G H
A
G
E
A E
H J
I
B C
D F
B
C
D
I
F
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
137
Mehrdimensionale Bereichsanfrage im R-Bäumen
§ Beispiel: Suche nach Anfragebereich
J
G H
A
G
E
A E
H J
I
B C
D F
B
C
D
I
F
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
138
3.5 Anfragebearbeitung
§ SQL ist rein deklarativ (vgl. Kapitel 2), d.h. man sagt dem
RDBMS welches Ergebnis man haben möchte; wie es
ermittelt wird, muss das RDBMS selbst entscheiden
§ SQL Anfrage wird in äquivalenten Ausdruck der
(erweiterten) Relationenalgebra übersetzt,
welcher dann schrittweise in einen
physischen Auswertungsplan
überführt wird
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
139
Anfragebearbeitung
§ Wie lassen sich die Operatoren der Relationenalgebra
implementieren – bei Ausnutzung verfügbarer Indizes?
§ Wie können wir Statistiken berechnen und speichern, um
die Kosten von Auswertungsplänen zu bestimmen?
§ Wie können wir einen Ausdruck der Relationenalgebra
in einen kostengünstigen physischen
Auswertungsplan überführen?
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
140
3.5.1 Basisalgorithmen
§ Physische Implementierung folgender Operatoren
§ Sortieren (s) im Primär- und Sekundärspeicher
§ Selektion (σ) mit/ohne Indexunterstützung
§ Projektion (π) mit/ohne Duplikateneliminierung
§ Join (⨝) mit/ohne Ausnutzung von Sortierung
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
141
Sortieren im Primärspeicher
§ Zusätzlicher Operator zum Sortieren von Relationen
sort [ A ] ( R )
mit A als Folge von Attributen und R als Relation;
Ergebnis ist eine geordnete Folge von Tupeln
§ Passt die Eingaberelation in den Primärspeicher, können
wir die uns bekannten effizienten Sortierverfahren
(z.B. QuickSort oder HeapSort) verwenden
§ Kapazität des Primärspeichers soll M Seiten entsprechen
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
142
Sortieren im Primärspeicher
§ Kosten des physischen Operators
sortP [ A ] ( R )
schätzen wir ab als die Anzahl benötigter Seitenzugriffe
c(sortP [ A ] ( R )) = p(R)
mit p(R) als Seitenanzahl der Relation R
§ Die Zahl benötigter Vergleichsoperationen ist in O(n log n);
Sortieren im Primärspeicher nur anwendbar, wenn
p(R) Æ M
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
143
Sortieren im Sekundärspeicher
§ Relationen passen i.A. nicht in den Primärspeicher,
so dass wir sie oft unter Zuhilfenahme des
Sekundärspeichers sortieren
§ Beim Sortieren im Sekundärspeicher müssen wir dessen
Besonderheiten (langsamer wahlfreier Zugriff; schneller
sequenzieller Zugriff) beachten
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
144
Sortieren im Sekundärspeicher
§ Externes MergeSort-Verfahren
§ teile Relation R in etwa gleich große Teile (runs) auf,
welche im Primärspeicher sortiert werden können,
und speichere sie im Sekundärspeicher
§ mische jeweils m vorsortierte Teile und speichere
das Ergebnis wiederum im Sekundärspeicher
§ stoppe, sobald nur noch ein Teil übrig ist
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
145
Sortieren im Sekundärspeicher
§ Beispiel: Sortieren einer Relation R mit m = 2
R (unsortiert)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
146
Sortieren im Sekundärspeicher
§ Beispiel: Sortieren einer Relation R mit m = 2
T1 (sortiert)
T2 (sortiert)
…
Tn-1 (sortiert)
Tn (sortiert)
Sortieren im Primärspeicher
R (unsortiert)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
147
Sortieren im Sekundärspeicher
§ Beispiel: Sortieren einer Relation R mit m = 2
T1,2 (sortiert)
…
Tn-1,n (sortiert)
Mischen
T1 (sortiert)
T2 (sortiert)
…
Tn-1 (sortiert)
Tn (sortiert)
Sortieren im Primärspeicher
R (unsortiert)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
148
Sortieren im Sekundärspeicher
§ Beispiel: Sortieren einer Relation R mit m = 2
T1… (sortiert)
T…n (sortiert)
Mischen
T1,2 (sortiert)
…
Tn-1,n (sortiert)
Mischen
T1 (sortiert)
T2 (sortiert)
…
Tn-1 (sortiert)
Tn (sortiert)
Sortieren im Primärspeicher
R (unsortiert)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
149
Sortieren im Sekundärspeicher
§ Beispiel: Sortieren einer Relation R mit m = 2
R (sortiert)
Mischen
T1… (sortiert)
T…n (sortiert)
Mischen
T1,2 (sortiert)
…
Tn-1,n (sortiert)
Mischen
T1 (sortiert)
T2 (sortiert)
…
Tn-1 (sortiert)
Tn (sortiert)
Sortieren im Primärspeicher
R (unsortiert)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
150
Sortieren im Sekundärspeicher
§ Kosten des physischen Operators
sortS [ A ] ( R )
hängen offensichtlich von der Anzahl initial erzeugter
Teile Ti und dem Wert des Parameters m ab
§ Anzahl initial erzeugter Teile (runs)
Áp(R)/M Ë
§ Anzahl von Mischrunden (Ebenen)
log m (Áp(R)/M Ë)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
151
Sortieren im Sekundärspeicher
§ Kosten des physischen Operators
sortS [ A ] ( R )
betragen damit
c(sortS [ A ] ( R )) = 2 p(R) (1 + log m (Áp(R)/M Ë))
da wir jede Seite der Relation R beim initialen Aufteilen
und bei jeder Mischrunde einmal lesen und schreiben
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
152
Selektion mittels Tabellenscan
§ Selektion mittels Tabellenscan
‡T [ P ] ( R )
liest Relation R sequenziell und filtert Tupel anhand
der Selektionsbedingung P aus
§ Kosten des physischen Operators entsprechen damit der
Seitenanzahl der Relation R und betragen
c(‡T [ P ] ( R )) = p(R)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
153
Selektion mittels Indexscan
§ Selektion mittels Indexscan
‡I [ P ] ( R )
verwendet einen geeigneten Index, sofern verfügbar,
um Tupel zu identifizieren, welche die
Selektionsbedingung P erfüllen
§ Qualifizierende Tupel werden mit Hilfe des Index
identifiziert und bei Bedarf aus der zur Relation
gehörenden Datendatei geholt
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
154
Selektion mittels Indexscan
§ Kosten des physischen Operators hängen damit, bei
Verwendung eines B+-Baums, von der Höhe des Baums
und der Anzahl sich qualifizierender Tupel ab
c(‡I [ P ] ( R )) = logm p(R) + p(‡ [ P ] ( R ))
mit m als Grad des B+-Baums
§ Anzahl qualifizierender Tupel, d.h. die Selektivität der
Bedingung P, kann meist nur mit Hilfe von Statistiken
geschätzt werden (dazu später mehr)
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
155
Projektion ohne Duplikateneliminierung
§ Projektion ohne Duplikateneliminierung erfordert keine
zusätzlichen Seitenzugriffe, da nur Attribute entfernt
werden müssen
§ Kosten des physischen Operators
c(fiD [ A ] ( R )) = p(R)
entsprechen somit der Seitenanzahl der Relation R
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
156
Projektion mit Duplikateneliminierung
§ Projektion mit Duplikateneliminierung erfordert im
ungünstigsten Fall das Sortieren der Relation
gemäß der Attributmenge A
§ Kosten des physischen Operators
c(fiN [ A ] ( R )) = c(sortS [ A ] ( R ))
entsprechend damit den Kosten für das Sortieren
der Relation R im Sekundärspeicher
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
157
Projektion mit Duplikateneliminierung
§ Existiert ein geeigneter Index (z.B. ein B+-Baum auf den
Attributen aus A), so muss nicht sortiert werden
und die Kosten betragen
c(fiN [ A ] ( R )) = p(R)
§ Bei einem B+-Baum werden die Blattknoten durchlaufen;
Duplikate treten in Gruppen auf und können daher
einfach mittels Gruppenwechsel eliminiert werden
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
158
Nested-Loop Join
§ Nested-Loop Join durchläuft für jedes Tupel aus R alle
Tupel aus S und überprüft, ob die Joinbedingung θ gilt
1
2
3
4
5
for ( r : R ) {
for ( s : S ) {
if ( theta (r , s )) output (r , s );
}
}
§ Block Nested-Loop Join, als Optimierung, durchläuft für
jeden Block der Relation R alle Blöcke der Relation S;
für jedes Paar von Blöcken wird für alle Paare von
Tupeln die Joinbedingung θ überprüft
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
159
Nested-Loop Join
§ Kosten des physischen Operators
R ÛÙL [ ◊ ] S
hängen davon ab, ob ein geeigneter Index verfügbar ist
§ ohne geeignetem Index
c(R ÛÙL [ ◊ ] S) = p(R) · p(S)
§ mit geeignetem Index (B+-Baum)
c(R ÛÙL [ ◊ ] S) = p(R) · (log m p(S) + k)
mit m als Grad des B+-Baums und k als durchschnittliche
Anzahl von Tupeln in S mit gleichem Attributwert
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
160
Merge Join
§ Merge Join, nur anwendbar für Equi-Joins, nutzt aus,
dass die Relationen R und S vorsortiert auf
den Attributen A der Joinbedingung vorliegen
§ Relationen R und S werden im „Zick Zack“ vermischt
§ gilt r < s bzgl. A für die aktuellen Tupel aus R und S,
so wird das nächste Tupel aus R gelesen
§ gilt r > s für die aktuellen Tupel aus R und S,
so wird das nächste Tupel aus S gelesen
§ gilt r = s für die aktuellen Tupel aus R und S,
so wird r mit s und allen darauffolgenden Tupeln s‘
mit r = s‘ verbunden, dann wird nächstes Tupel aus R gelesen
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
161
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
7
162
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
7
163
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
7
164
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
7
165
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
7
§ Ausgabe: 4
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
166
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
7
§ Ausgabe: 4, 4
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
167
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
7
§ Ausgabe: 4, 4
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
168
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
7
§ Ausgabe: 4, 4
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
169
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
7
§ Ausgabe: 4, 4
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
170
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
7
§ Ausgabe: 4, 4
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
171
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
7
§ Ausgabe: 4, 4, 7
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
172
Merge Join
§ Beispiel: Merge Join auf zwei Relationen R und S
R
1
2
4
7
7
S
3
4
4
5
6
7
§ Ausgabe: 4, 4, 7, 7
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
173
Merge Join
§ Kosten des physischen Operators
R ÛÙM [ ◊ ] S
hängen davon ab, ob die beiden Relationen sortiert sind
§ beide Relationen vorsortiert
c(R ÛÙM [ ◊ ] S) = p(R) + p(S)
§ ist keine der Relationen vorsortiert, kommen die
entsprechenden Kosten zum Sortieren der beiden
Relationen hinzu
§ Achtung: Ergebnis kann |R|*|S| Tupeln enthalten
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
174
Hash Join
§ Hash Join konstruiert aus den Tupeln der kleineren
Relation (o.b.d.A. R) eine Hashtabelle und nutzt diese,
um zu jedem Tupel aus S die Joinpartner zu finden
§ Passt selbst die kleinere Relation nicht in den
Primärspeicher, so kann blockweise
vorgegangen werden
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
175
Hash Join
§ Beispiel:
R
1
2
4
7
7
S
3
4
4
5
6
7
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
x
h(x) = x mod 5
0
1
2
3
4
{}
{1}
{2, 7, 7}
{}
{4}
176
Hash Join
§ Beispiel:
R
1
2
4
7
7
S
3
4
4
5
6
7
x
h(x) = x mod 5
0
1
2
3
4
{}
{1}
{2, 7, 7}
{}
{4}
§ Ausgabe: 4
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
177
Hash Join
§ Beispiel:
R
1
2
4
7
7
S
3
4
4
5
6
7
x
h(x) = x mod 5
0
1
2
3
4
{}
{1}
{2, 7, 7}
{}
{4}
§ Ausgabe: 4, 4
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
178
Hash Join
§ Beispiel:
R
1
2
4
7
7
S
3
4
4
5
6
7
x
h(x) = x mod 5
0
1
2
3
4
{}
{1}
{2, 7, 7}
{}
{4}
§ Ausgabe: 4, 4
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
179
Hash Join
§ Beispiel:
R
1
2
4
7
7
S
3
4
4
5
6
7
x
h(x) = x mod 5
0
1
2
3
4
{}
{1}
{2, 7, 7}
{}
{4}
§ Ausgabe: 4, 4
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
180
Hash Join
§ Beispiel:
R
1
2
4
7
7
S
3
4
4
5
6
7
x
h(x) = x mod 5
0
1
2
3
4
{}
{1}
{2, 7, 7}
{}
{4}
§ Ausgabe: 4, 4, 7, 7
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
181
Hash Join
§ Kosten des physischen Operators
c(R ÛÙH [ ◊ ] S) = p(R) + p(S)
sofern die kleinere Relation R in den Primärspeicher passt
§ Bei blockweiser Vorgehensweise mit Kapazität M des
Primärspeichers ergeben sich ansonsten Kosten von
9
:
p(R)
c(R ÛÙH [ ◊ ] S) = p(R) +
· p(S)
M
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
182
Zusammenfassung
§ Mehrdimensionale Bereichsanfragen möglich mit
§ raumfüllenden Kurven
§ rekursiver Partitionierung
§ R-Bäumen
§ Implementierung von Operatoren der Relationenalgebra
§ Selektion mit/ohne Indexunterstützung
§ Projektion mit/ohne Duplikateneliminierung
§ Sortieren im Primär- oder Sekundärspeicher
§ Join mittels verschachtelter Schleifen, Mischen oder Hashing
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
183
Literatur
[1]
A. Kemper und A. Eickler: Datenbanksysteme – Eine
Einführung, De Gruyter Oldenbourg, 2015 (Kapitel 8)
[2]
G. Saake, K.-U. Sattler und A. Heuer:
Datenbanken - Implementierungstechniken,
mitp Professional, 2011 (Kapitel 6 & 7)
[3]
Spatial Indexing Overview, Microsoft TechNet
[Link]
Datenbanken & Informationssysteme / Kapitel 3: Datenbanksysteme
184