pdf (870 Kb) - Fachgebiet Datenbanken und Informationssysteme

Universität Hannover
Fachbereich Informatik
Institut für Informationssysteme
Diplomarbeit
Heuristische Anfrageoptimierungen
in Relationalen Datenbanken
16. Januar 2003
Mazeyar E. Makoui
Matrikel-Nr. 1873773
Erstprüfer: Prof. Dr. Udo Lipeck
Zweitprüfer: Prof. Dr. Rainer Parchmann

Erklärung
Hiermit versichere ich, Mazeyar E. Makoui, die vorliegende Diplomarbeit ohne
fremde Hilfe und nur unter Verwendung der von mir aufgeführten Quellen und
Hilfsmittel angefertigt zu haben.
Hannover, 16. Januar 2003.
(Mazeyar E. Makoui)

Es gibt nur zwei Dinge, die unendlich groß sind:
Das Weltall und die Dummheit des Menschen.
Beim Weltall bin ich mir nicht sicher.
Es gibt nur zwei Dinge, die in unserer Arbeit von nöten sind:
Unermüdliche Ausdauer und die Bereitschaft,
etwas, in das man viel Zeit und Arbeit gesteckt hat,
wieder wegzuwerfen.
Was wirklich zählt, ist die Intuition.
Albert Einstein

Danksagung
An dieser Stelle möchte ich die Gelegenheit nutzen und mich bei denen bedanken,
die mich im Laufe der Zeit auf meinem Weg begleiteten und somit erst diese
Diplomarbeit ermöglichten.
Besonderer Dank geht an Herrn Prof. Dr. Udo Lipeck, dem ich viele Stunden der
kreativen Diskussion und kritischen Auseinandersetzung verdanke. Erst durch
sein Vertrauen in meine Person konnte ich diese Diplomarbeit angehen und zu
einem Abschluß bringen. Mein Dank geht auch an Prof. Dr. Rainer Parchmann
für seinen Einsatz als Koreferent.
Auch Herrn Prof. Dr. Bernhard Seeger von der Universität Marburg möchte
ich ganz herzlich danken. Er gewährte mir den Zugang zu seinen Unterlagen,
bezüglich der von ihm gehaltenen Vorlesung über Anfrageoptimierung.
Desweiteren möchte ich Katharina Ludwig für ihre kritischen Bemerkungen danken,
die mich immer wieder daran erinnerten, daß meine Gedanken und Ideen
auch aufgeschrieben werden müssen. Herr Dipl.-Math. Frank Samir Attia ließ
mich die Dinge oft aus einem anderen Blickwinkel neu betrachten. Außerdem
Anika Höptner, die mich seelisch und freundschaftlich in den letzten Jahren begleitete.
Hervorheben möchte ich folgende Freunde: Dipl.-Math. Anke Eberhard, cand.
math. Cord Erdenberger, Dr. rer. nat. Daniel Frohn, Dipl.-Math. oec. Marc Heitzer,
cand. math. Iris Lieske, Dipl.-Dolm. Manfred Lisius, Dipl.-Math. SR-Inf. Ulf
Löckmann, Dipl.-Math. Marcus Reich, Dipl.-Math. Simon Stelling, cand. math.
Matthias Schütt und Christian Wederhake.
Schließlich möchte ich meinen Eltern herzlich danken, die vieles auf sich nahmen,
um uns Kindern die Möglichkeit zu geben, in einem fremden Land, all das zu
erreichen, was wir uns schon immer gewünscht hatten.
Hannover, am 16. Januar 2003.

Zusammenfassung
Das Ziel der Anfrageverarbeitung in Relationalen Datenbanken besteht darin, für
eine gegebene Anfrage den optimalen Ausführungsplan zu generieren. Da dieses
im allgemeinen sehr aufwendig ist, reduziert man in der Praxis die Anforderungen
darauf, schlechte Ausführungspläne zu vermeiden.
In der vorliegenden Diplomarbeit wird zunächst eine Einführung in dieses komplexe
Thema gegeben, um danach die heuristische Anfrageoptimierung näher zu
untersuchen. Sie beinhaltet als Basis ein Kostenmodell, das es einem ermöglicht,
relative Aussagen über die Güte des optimierten Anfrageplans zu tätigen. Dabei
ist nicht die Exaktheit der Kosten wichtig, sondern die relativen Kostendifferenzen
der jeweiligen Anfragepläne.
Diese Alternativen entstehen in zwei aufeinanderfolgenden Phasen der Optimierung.
Zuerst wird eine algebraische Optimierung vorgenommen, bei der durch
Termersetzungsregeln Äquivalenzumformungen durchgeführt werden. Da für einen
Operator der logischen Algebra oft unterschiedliche Implementierungen existieren,
wird in der darauffolgenden physischen Optimierung eine möglichst kostengünstigste
gewählt. In beiden Fällen werden Heuristiken zur Steuerung der
Alternativengenerierung eingesetzt. Sie repräsentieren Erfahrungswerte für die
sinnvolle Anwendung bestimmter Umformungsregeln.
Die für die Anfrageoptimierung benötigten Suchverfahren bieten anschließend
die Möglichkeit, den entwickelten Anfragebaum teilweise noch zu verbessern. Die
dafür gegebenen Zusatzinformationen erlauben die Nutzung einer Auswahl von
Suchverfahren, die eine kostengünstigere - wiederum durch Heuristiken beschleunigte
- Anfrage finden können.
Zum Abschluß der Arbeit wird der vorgestellte Anfrageoptimierer simuliert, um
nähere Untersuchungen bezüglich der Feinabstimmungen zu ermöglichen. Dabei
wird das Hauptaugenmerk auf die notwendige Flexibilität und die Erweiterbarkeit
der programmierten Optimierungsmodule gelenkt.

Abstract
The aim of the query evaluation in relational data base systems consists of generating
the optimal execution plan for a given query. Since this is generally a
very complex matter, one reduces the requirements in practice to avoid bad query
trees.
This diploma presents an introduction to this complex topic, in order to examine
afterwards the heuristic query optimization closer. By giving a basic cost model,
it gives one the possibility, to make relative statements about the quality of the
optimized query plan. Not the exactness of the costs is important, but the relative
cost differences of the respective query plans.
These alternatives are developed in two following phases of the optimization.
First an algebraic optimization is made, with which equivalence rewritings are
accomplished by transformation rules. Since for a logical algebra operator often
different implementations exist, the most economical plan is selected in the following
physical optimization. In both cases heuristics are used for the controlling
of generating alternatives. They represent empirical values for the meaningful
application of certain rewriting rules.
The search methods needed for the query optimization offer afterwards the possibility
of improving the developed query tree. The additional given metadatas
permit to use a selection of search methods, which can find a more economical -
again accelerated by heuristics - query.
For the conclusion of this work the presented query optimizer is simulated, in
order to make closer investigations possible concerning the fine tunings. Special
attention is directed on the necessary flexibility and the expandability of the
programmed optimization modules.

Inhaltsverzeichnis
1 Einleitung 1
1.1 Ziel dieser Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Aufbau dieser Diplomarbeit . . . . . . . . . . . . . . . . . . . . . 6
2 Algebraische Optimierung 9
2.1 Rechenregeln der relationalen Algebra . . . . . . . . . . . . . . . . 10
2.2 Beispiel für die algebraische Optimierung . . . . . . . . . . . . . . 14
2.3 Heuristische algebraische Optimierung . . . . . . . . . . . . . . . 17
2.4 Tableau-Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Fazit der algebraischen Optimierung . . . . . . . . . . . . . . . . 18
3 Physische Optimierung 21
3.1 Iteratoren und Iteratorbäume . . . . . . . . . . . . . . . . . . . . 22
3.2 Scan-Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Projektion . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Selektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Join-Methoden (✶p, ⊲⊳p) . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 NestedLoop-Join (✶ NestedLoop
p ) . . . . . . . . . . . . . . . . 26
3.3.2 Index-Join (✶ Index
p ) . . . . . . . . . . . . . . . . . . . . . . 27
3.3.3 Merge-Join (✶ Merge
p ) . . . . . . . . . . . . . . . . . . . . . 28
3.3.4 Hash-Join (✶ Hash
p ) . . . . . . . . . . . . . . . . . . . . . . 29
3.3.5 Semijoin (⋉p, ⋊p) - Antisemijoin ( ¯⋉p) . . . . . . . . . . . . 30
3.3.6 Outer-Joins (❂⋊p, ⋉❁p, ❂×❁p) . . . . . . . . . . . . . . . . . 31
3.4 Mengenoperatoren . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Sortierung und Duplikateliminierung . . . . . . . . . . . . . . . . 33
3.6 Übersetzung der logischen Algebra . . . . . . . . . . . . . . . . . 34
3.7 Physische Optimierungsmöglichkeiten . . . . . . . . . . . . . . . . 35
3.8 Heuristische physische Optimierung . . . . . . . . . . . . . . . . . 37
3.9 Beispiel für die physische Optimierung . . . . . . . . . . . . . . . 39
3.10 Fazit der physischen Optimierung . . . . . . . . . . . . . . . . . . 40
i

ii INHALTSVERZEICHNIS
4 Kostenfunktionen und Selektivitäten 41
4.1 Allgemeine Kostenberechnung . . . . . . . . . . . . . . . . . . . . 42
4.2 Kostenfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Selektivität von Prädikaten . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 Selektivität von Projektion und Selektion . . . . . . . . . . 46
4.3.2 Selektivität eines Joins . . . . . . . . . . . . . . . . . . . . 49
4.4 Selektivitätsabschätzungen . . . . . . . . . . . . . . . . . . . . . . 53
4.4.1 Parametrisierte Verteilung . . . . . . . . . . . . . . . . . . 53
4.4.2 Histogramme . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.3 Stichproben . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . 55
4.5 Fazit der Selektivitätsabschätzungen . . . . . . . . . . . . . . . . 55
4.6 Kostenfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.6.1 Kostenfunktion Scan (Selektion, Projektion) . . . . . . . . 57
4.6.2 Kostenfunktion Sortierung und Indexerzeugung . . . . . . 58
4.6.3 Kostenfunktion Join . . . . . . . . . . . . . . . . . . . . . 59
4.7 Kosteneinsparungen beim Pipelining . . . . . . . . . . . . . . . . 60
4.8 Beispiel zur Kostenberechnung . . . . . . . . . . . . . . . . . . . . 60
4.9 Fazit des Kostenmodells . . . . . . . . . . . . . . . . . . . . . . . 65
5 Kostenbasierte Optimierung 67
5.1 Heuristische Suchverfahren . . . . . . . . . . . . . . . . . . . . . . 68
5.1.1 Hill-Climbing Suche . . . . . . . . . . . . . . . . . . . . . . 68
5.1.2 Simulated Annealing . . . . . . . . . . . . . . . . . . . . . 69
5.1.3 Best-First Suche . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.4 Beam-Search . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2 Fazit der heuristischen Suche . . . . . . . . . . . . . . . . . . . . . 71
5.3 Genetische Algorithmen . . . . . . . . . . . . . . . . . . . . . . . 71
6 Die Optimierungsstrategie 73
6.1 Transformation und Generierung . . . . . . . . . . . . . . . . . . 76
6.2 Die globale kostenbasierte Optimierungsheuristik . . . . . . . . . 80
6.3 Die lokale kostenbasierte Optimierungsheuristik . . . . . . . . . . 84
6.4 Fazit der kostenbasierten Optimierung . . . . . . . . . . . . . . . 85
6.5 Beispiel zur kostenbasierten Suche . . . . . . . . . . . . . . . . . . 86
7 Die Implementierung des SQL-Optimierers 91
7.1 Die Packages des SQL-Optimierers . . . . . . . . . . . . . . . . . 91
7.2 Grafische Benutzerschnittstelle GUI . . . . . . . . . . . . . . . . . 93
7.2.1 de.unihannover.dbs.sopt.gui . . . . . . . . . . . . . . . . . 93
7.3 Der Relationale Anfrageparser . . . . . . . . . . . . . . . . . . . . 96
7.3.1 de.unihannover.dbs.sopt.sqlp . . . . . . . . . . . . . . . . . 96
7.4 Datenstruktur des Anfrageoptimierers . . . . . . . . . . . . . . . . 98

INHALTSVERZEICHNIS iii
7.4.1 de.unihannover.dbs.sopt.struc.alg . . . . . . . . . . . . . . 98
7.4.2 de.unihannover.dbs.sopt.struc.alg.rules . . . . . . . . . . . 101
7.4.3 de.unihannover.dbs.sopt.struc.phys . . . . . . . . . . . . . 101
7.4.4 de.unihannover.dbs.sopt.struc.search . . . . . . . . . . . . 104
7.5 Die Testschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.5.1 de.unihannover.dbs.sopt.test . . . . . . . . . . . . . . . . . 105
7.6 Benutzerhandbuch . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.6.1 Starten des SQL-Optimierers . . . . . . . . . . . . . . . . 105
8 Ausblick 109
A Der Oracle Optimierer 111
A.1 Rule based optimizer . . . . . . . . . . . . . . . . . . . . . . . . . 111
A.2 Cost based optimizer . . . . . . . . . . . . . . . . . . . . . . . . . 112
A.3 Cost based optimizer mit hints . . . . . . . . . . . . . . . . . . . . 113
A.4 Statistiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
A.5 Standardeinstellungen des Optimierers . . . . . . . . . . . . . . . 114
A.6 Indexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
B Konventionen dieser Arbeit 117
C Weblinks zu dieser Diplomarbeit 119
Abbildungsverzeichnis 123
Tabellenverzeichnis 125
Literaturverzeichnis 127

Kapitel 1
Einleitung
Wenn ich die Folgen geahnt hätte,
wäre ich Uhrmacher geworden.
Albert Einstein
Anfragen in deklarativen Sprachen wie SQL, die an ein Datenbanksystem gestellt
werden, definieren zwar das, was der Benutzer wissen möchte, jedoch nicht, wie
das System die gewünschte Information ermitteln soll. Daraus resultieren zumeist
viele verschiedene Möglichkeiten, eine Anfrage auszuwerten. Aus diesem Grund
sollte möglichst früh eine Anfrageoptimierung bei der Anfragebearbeitung stattfinden.
Anfrageoptimierung
❄ ❄
regelbasierte Verfahren kostenbasierte Verfahren
❄
Branch-and-Bound Greedy Methode
❄
❄
zufallsorientierte Verfahren
❄
Optimierer Generator
dynamische Programmierungsmethode
Abbildung 1.1: Strategien zur Anfrageoptimierung
Dafür wird bezüglich der Auswahl realisierter Ausführungspläne zwischen kostenbasierter
und regelbasierter Anfrageoptimierung unterschieden. Während bei
der kostenbasierten Anfrageoptimierung Ausführungspläne aufgrund eines Gütekriteriums
ausgewertet werden, erfolgt bei der regelbasierten die Überprüfung
alternativer Ausführungspläne anhand einer Menge von Regeln.
Kostenbasierte Verfahren sind zum Beispiel genetische Anfrageoptimierung [54],
die zu den zufallsorientierten Verfahren gehören, oder aber auch die dynamische
Programmierung, wie sie im System R Optimierer 1 eingesetzt wird. Zusätzlich
1 Auf Basis des 1979 verfaßten Artikels von Selinger [51] bei IBM entwickelter Optimierer
für Relationale Datenbanken.
1
❄

2 KAPITEL 1. EINLEITUNG
dazu gibt es noch Greedy-Algorithmen, bei denen eine schrittweise Zerlegung der
Anfrage heuristisch vorgenommen wird.
Gegenstand dieser Arbeit ist die Entwicklung eines Optimierer-Generators (regelbasierter
Algorithmus), der aus der Menge der verschiedenen, jedoch semantisch
äquivalenten Auswertungspläne, dem Anfrageraum, den Plan auswählt, der mit
den geringsten Kosten verbunden ist, d.h. mit dem heuristisch kleinsten Zeitaufwand
ausgeführt werden kann. Da für den Anwender entscheidend ist, wieviel Zeit
das Datenbanksystem von der Eingabe der Anfrage bis zur Ausgabe des Ergebnisses
benötigt, muß dabei auch beachtet werden, wie zeitintensiv die Optimierung
ist. Ein Algorithmus, der stets den Plan mit der kürzesten Ausführungszeit findet,
dafür aber mehr Zeit benötigt als durch die Optimierung eingespart wird,
ist für den Anwender sicherlich nicht akzeptabel.
Verbessert man den Optimierer dahingegend, daß er nach den vorgegebenen Regeln
noch eine weitere Suche vornimmt, erreicht man die sogenannten Branchand-Bound
Suchverfahren, die von hier an als Kostenbasierte Optimierung bezeichnet
werden.
Der Ablauf der Anfragebearbeitung sieht wie folgt aus:
deklarative Anfrage
❄
Scanner / Parser / View-Resolution
algebraischer Ausdruck
❄
Anfrageoptimierung
Auswertungsplan (QEP)
❄
Codeerzeugung / Ausführung
Ergebnis
❄
algebraische Optimierung
✒✒✒ algebraischer Ausdruck
✒ ❄
physische Optimierung
❘ ❘❘❘
mehrere Zugriffspläne
❄
kostenbasierte Optimierung
Abbildung 1.2: Ablauf der Anfrageoptimierung
Die vom Benutzer eingegebene Anfrage wird im ersten Schritt von einem Parser
in eine interne Form gebracht, die dann unter Zuhilfenahme des Data Dictionaries
validiert wird, um sicherzustellen, daß die Anfrage nur erlaubte und gültige
Referenzen auf existierende Datenbank-Objekte enthält. Wenn Makros benutzt
worden sind, werden sie durch ihre Definitionen ersetzt.
Der daraus resultierende algebraische Ausdruck wird dann einer Anfrageoptimierung
unterzogen, die sich in algebraische, physische und kostenbasierte Optimierung
aufteilt, wobei die Übergänge in der Implementierung fließend sind. Schließ-

lich wird der optimale Ausführungsplan (Query-Evaluation-Plan oder Query-
Execution-Plan, kurz QEP) in eine ausführbare Form gebracht, so daß - nach
der Bearbeitung - dem Benutzer das Ergebnis präsentiert wird.
Die algebraische Optimierung besteht darin, daß später vorgestellte Rechenregeln
der Relationen-Algebra angewandt werden. Unter Umständen können noch
weitere Verbesserungen vorgenommen werden. Dabei werden die tatsächlichen
Kenngrößen der Relationen sowie das Speichermodell noch nicht berücksichtigt.
Danach erfolgt die physische Optimierung unter Zuhilfenahme von konkreten
Speicherungs- und Zugriffstechniken (z.B. Indexe und Cluster) und Nutzung von
Implementierungsalternativen für algebraische Operationen.
Am Ende dieser Phase werden mehrere semantisch äquivalente Zugriffspläne weitergegeben,
die einen geringen Aufwand erwarten lassen. Diese Zugriffspläne werden
bei der kostenbasierten Optimierung mit Hilfe von Kostenabschätzungen bewertet
und eventuell noch modifiziert. Danach wird der optimale Plan gewählt.
Darüberhinaus gibt es für die Relationenkalküle oder für die Sprache Datalog
(Modellsprache Deduktiver Datenbanken, Relationen werden als Faktenmenge
betrachtet) heuristische Optimierungstechniken, die unabhängig von algebraischer
Transformation agieren.
Bei der Optimierung von Anfragen in klassischen relationalen Systemen lassen
sich zwei Problemkreise identifizieren:
(a) Zum einen muß in der algebraischen und physischen Optimierung aus der
Menge aller möglichen Auswertungspläne eine möglichst kleine Anzahl von
Plänen extrahiert werden, die geringe Kosten bei der Auswertung versprechen,
aber möglichst ohne dabei sehr gute Pläne auszulassen;
(b) zum anderen müssen für die kostenbasierte Optimierung Verfahren entwickelt
werden, mit deren Hilfe die Auswertungskosten eines Planes möglichst
exakt geschätzt werden können, ohne die Anfrage tatsächlich auszuführen.
Dabei gibt es drei verschiedene Zeitpunkte, an denen die Optimierungen stattfinden
können:
(a) Statisch:
Hierbei wird die Optimierung vor der Ausführung getätigt. Das ist sinnvoll,
wenn die Kostenabschätzungen relativ scharf sind und damit die Bewertung
der verschiedenen Pläne sehr genau ist. Anderenfalls ist das Risiko, einen
der schlechteren Pläne zu wählen, recht hoch.
3

4 KAPITEL 1. EINLEITUNG
(b) Dynamisch:
In diesem Fall wird ” während“ der Ausführung optimiert. Da dabei die
Zwischenergebnisse vorliegen, kann eine Entscheidung auf einer sicheren
Grundlage vorgenommen werden. Der Schwachpunkt ist, daß das Verwerfen
einer begonnenen, als suboptimal erkannten Ausführung sehr hohe Kosten
erzeugt.
(c) Hybrid:
Dieser Nachteil kann durch einen kombinierten Einsatz der beiden obigen
Verfahren vermieden werden. Vor der Ausführung wird mit Schätzungen
ein möglichst optimaler Plan ausgewählt, wobei Korrekturmöglichkeiten zur
Laufzeit möglich sind, wenn tatsächliche Größen zu sehr von den Schätzungen
abweichen.
Dabei gibt es zwei Abstraktionslevel der Optimierung, die meist in der Literatur
konzeptionell benutzt werden, während praktisch eine generelle, strikte Trennung
der einzelnen Phasen in der Implementierung eines Optimierers gar nicht stattfindet:
algebraische Optimierung
algebraischer Ausdruck
❄
physische Optimierung ✛
mehrere Zugriffspläne
❄
kostenbasierte Optimierung ✛
✛ High-Level-Optimierung
Abbildung 1.3: Phasen der Optimierung
Low-Level-Optimierung
(a) Eine Anfrage kann alleine durch ” Rechenregeln“ verbessert werden, welche
für die Operatoren der betreffenden Hochsprache gelten. Da dabei
nur im abstrakten Raum agiert wird, spricht man hierbei von einer High-
Level-Optimierung, diese ist datenbankunabhängig. Es kommen hierbei nur
sogenannte Termersetzungs-Techniken zur Anwendung, die auf syntaktischer
Ebene Umformungen an einer Anfrage erlauben und somit eine Art
Anfrage-Modifikation darstellen.
Es sei an dieser Stelle auch bemerkt, daß eine High-Level-Optimierung bereits
auf der Ebene einer deklarativen Sprache ansetzen kann.
(b) Dagegen wird von einer Low-Level-Optimierung ausgegangen, wenn Parameter
der internen Datenbank-Organisation (Data-Dictionary bzw. System-

katalog), in die Optimierung einbezogen werden. Unterschieden wird hierbei,
ob ” nur“ Metadaten oder auch der konkrete Datenbestand eingehen.
Schließlich existieren zwei verschiedene Optimierungsstrategien:
(a) Vollständige Suche (enumerative Suche):
Dabei werden alle möglichen Anfragepläne generiert und bewertet (”Generate-and-Test”-
Strategie). Diese Optimierung ist meist zu teuer und nur
dann sinnvoll, wenn der Anfrageraum relativ klein ist, z.B. weil nur sehr wenige
Operationen nötig und damit wenige Umformungen möglich sind. Beispiele
dafür sind die Tiefensuche (depth-first search) oder die Breitensuche
(breadth-first search). Da ohnehin alle Möglichkeiten untersucht werden, ist
es hierbei unerheblich, wo die Suche begonnen wird.
Bei heutigen föderalen Datenbanksystemen ist die vollständige Suche einfacher
Anfragen aber immer öfter die bessere Alternative, da Datenbankzugriffe
bei breitverteilten Systemen kostenintensiver sein können als zeitintensive
Optimierungen.
(b) Heuristische Suche:
Bei der heuristischen Suche versucht man nun die Optimierungszeit zu verringern,
indem man wahrscheinlich ungünstige Pläne im voraus ausschließt.
Hier ist es wichtig, für die Suche schon einen möglichst guten Startplan zu
kennen, z.B. kann man versuchen, die Größe der Zwischenrelationen zu
verkleinern. Hierfür sind die im Abschnitt 2.3 beschriebenen heuristischen
Regeln zur Transformation eines Anfragebaumes der entscheidende Schritt.
Ausgehend von einem relativ guten Startplan sind dann die heuristischen
Suchverfahren wie z.B. Greedy-Suche, Best-First-Suche und Hill-Climbing
(Kapitel 5) in der Lage, in kürzerer Zeit einen optimierten Anfrageplan zu
finden.
Für die heuristische Suche müssen nun Regeln gefunden werden, die den Suchraum
möglichst stark einschränken, aber gleichzeitig das Risiko klein halten, einen
optimalen Plan auszuschließen. In der algebraischen und physischen Optimierung
soll die Heuristik an zwei Punkten ansetzen. Ausgehend von dem übergebenen
algebraischen Ausdruck soll sie erstens Erfolg versprechende Transformationen
schnell finden und zweitens (höchstwahrscheinlich) wenig sinnvolle Umformungen
ausschließen.
5

6 KAPITEL 1. EINLEITUNG
1.1 Ziel dieser Diplomarbeit
Das Ziel dieser Diplomarbeit ist es, nach einer Einführung in die algebraische bzw.
physische Optimierung einen selbstentwickelten Optimierungssimulator vorzustellen,
der in der Lage ist, die entwickelten Optimierungsstrategien auszuführen.
Die Hauptidee für die heuristische Suche ist hierbei, zu einer gegebenen Anfrage
einen sogenannten Prototypen im Anfrageraum zu finden und von dort aus die
Suche fortzusetzen. Wichtig für den Erfolg dieser Strategie ist, daß der Prototyp
bereits in der Nähe des absoluten Minimums der Kosten liegt.
✛
❅■
❅■
❅
✻
❜ �
�✒
✻
Prototyp
1:1-Übersetzung
Anfrageraum
Abbildung 1.4: Anfrageraum der Ausführungspläne
Der Prototyp entwickelt sich aus der 1:1-Übersetzung der Anfrage in einen Baum
und darauf angewandten Faustregeln. Ausgehend von diesem Prototypen können
dann - durch weitere Modifikation des Operatorbaumes, unter Zuhilfenahme der
Kostenfunktion - weitere Anfragepläne generiert und verglichen werden.
1.2 Aufbau dieser Diplomarbeit
Die folgenden Kapitel gliedern sich wie folgt:
Im 1. Kapitel wird dem Leser eine kurze Einführung in das Thema der Anfrageoptimierung
geboten. Danach folgt in Kapitel 2 eine Darstellung der Ersetzungsregeln
der Relationenalgebra, die daraufhin als Grundlage für Anfrageheuristiken
dient.
Kapitel 3 schafft den Übergang von den algebraischen Operatoren hin zur physischen
Implementierung einer Anfrage.
Das wahrscheinlich wichtigste Kapitel ist das vierte. Hier werden die Kostenfunktionen
zu den einzelnen Operatoren aufgestellt, die für jede Art von (kostenbasierter)
Anfrageoptimierung benötigt werden.

1.2. AUFBAU DIESER DIPLOMARBEIT 7
In Kapitel 5 werden die vorher erzielten Ergebnisse angewandt, um die kostenbasierte
Optimierung zu erläutern.
Das Herzstück der Diplomarbeit ist das 6. Kapitel, das die Entwicklung und die
theoretische Grundlage des SQL-Optimierers erklären wird. Anschließend wird
eine Bewertung der betrachteten Optimierungsmethoden vorgenommen. Danach
folgt ein Ausblick auf weitere Optimierungsstrategien.
In Kapitel 7 wird der simulierte Anfrage-Optimierer näher erklärt. Dieses Kapitel
beschäftigt sich mit dem Implementierungsanteil dieser Diplomarbeit. 2
Schließlich setzt Kapitel 8 einen Schlußstrich unter diese Arbeit und gibt außerdem
einen Ausblick.
2 Als Referenz für die Implementierung des Anfragesimulators dienen die Möglichkeiten des
Oracle-Optimierers, die im Anhang A dargestellt werden.

8 KAPITEL 1. EINLEITUNG

Kapitel 2
Das Schönste, was wir erleben können,
ist das Geheimnisvolle.
Albert Einstein
Algebraische Optimierung
Im Rahmen der algebraischen Optimierung wird die interne 1:1-Übersetzung
der Anfrage in eine Standardform transformiert, die zwar noch äquivalent zur
Original-Anfrage ist, aber schon eine gewisse Optimierung beinhaltet. Dabei wird
eine grundsätzliche Form benötigt, bei der die Ausdrücke der relationalen Algebra
sich direkt in Operatorbäume umsetzen lassen. Relationale Algebraausdrücke
und somit auch die Operatorbäume spiegeln jeweils eine prozedurale Darstellung
der Anfrage wider. Die Blätter sind die Operanden des algebraischen Ausdrucks,
wobei die inneren Knoten die Basisrelationen bzw. Operationen darstellen und
an der Wurzel die letzte auszuführende Operation steht.
Blätter: die Operanden innere Knoten: die Operationen
Kanten: der Datenfluß Wurzel: die letzte auszuführende Operation
Diese baumartige Darstellung kann nicht nur als Evaluierungsvorschrift angesehen
werden, sondern dient hauptsächlich als effiziente Datenstruktur. Das Einfügen
neuer Operatoren ist sehr einfach, da eine Erweiterung des Baumes durch
Einschübe von Teilbäumen leicht implementiert werden kann.
Die dafür benötigte Anfrageumformung (1:1-Übersetzung) wird mit wenig komplizierten
Methoden realisiert. Dabei wird die Anfrage normalisiert und vereinfacht,
wobei noch keine Optimierung im eigentlichen Sinne vorgenommen wird.
Vielmehr versucht man, die Anfrage möglichst gut für den Optimierer vorzubereiten.
Dabei wird vor allem von aussagelogischen Methoden Gebrauch gemacht
(siehe dazu Mitschang [36]).
Um möglichst früh Inkonsistenzen und unerfüllbare Anfragen zu erkennen, kann
bereits in der Übersetzungsphase eine Vereinfachung der Anfrage erfolgen. Meistens
werden diese aber nach der 1:1-Übersetzung der Selektionsbedingungen
durchgeführt, da erst dann eine effiziente Untersuchung der aussagelogischen Ausdrücke
möglich ist.
9

10 KAPITEL 2. ALGEBRAISCHE OPTIMIERUNG
Alle möglichen Vereinfachungsoperationen bzw. Termersetzungen werden nicht
sequentiell durchgeführt, sondern in einem iterativen Prozeß immer wieder eingesetzt.
Dafür benötigt man eine Vielzahl von Regeln, die im folgenden Abschnitt
näher beschrieben werden.
2.1 Rechenregeln der relationalen Algebra
Für die Optimierung der relationalen Ausdrücke benötigt man Ersetzungsregeln,
die einem die Äquivalenzumformungen ermöglichen:
Abkürzungen:
R, R1, R2, . . . Relationen (z. B. Zwischenergebnisse)
q, p, p0, p1, p2, . . . Bedingungen
l1, l2, . . . Attributmengen
attr(p) die Menge der in p enthaltenen Attribute
sch(R) das Schema (also die Menge der Attribute) der Relation R
”→”, ”←” Hin- bzw. Rückrichtungsbedingung
einer Gleichheitsaussage
Operationen:
∩ Durchschnitt zweier Relationen
∪ Vereinigung zweier Relationen
− Differenz zweier Relationen
× Kartesisches Produkt zweier Relationen
πl Projektion einer Relation auf die Attributmenge l
σp Selektion einer Relation durch die Bedingung p
✶p Verbund zweier Relationen durch die Bedingung p
Dafür gelten folgende Gesetze:
(a) R ∪ R = R
R − R = ∅
(b) σp1(R) ∪ σp2(R) = σp1∨p2(R)
σp1(R) − σp2(R) = σp1∧¬p2(R)
(c) R ∪ ∅ = R
∅ ∪ R = R
R − ∅ = R
∅ − R = ∅
R × ∅ = ∅
∅ × R = ∅

2.1. RECHENREGELN DER RELATIONALEN ALGEBRA 11
(d) σp(∅) = ∅
πl(∅) = ∅
(e) πsch(R)(R) = R
(f) Join, Vereinigung, Schnitt und das Kreuzprodukt sind kommutativ:
R1 ✶ R2 = R2 ✶ R1
R1 ∪ R2 = R2 ∪ R1
R1 ∩ R2 = R2 ∩ R1
R1 × R2 = R2 × R1
(g) Join, Vereinigung, Schnitt und das Kreuzprodukt sind assoziativ:
R1 ✶ (R2 ✶ R3) = (R1 ✶ R2) ✶ R3 = R1 ✶ R2 ✶ R3
R1 ∪ (R2 ∪ R3) = (R1 ∪ R2) ∪ R3 = R1 ∪ R2 ∪ R3
R1 ∩ (R2 ∩ R3) = (R1 ∩ R2) ∩ R3 = R1 ∩ R2 ∩ R3
R1 × (R2 × R3) = (R1 × R2) × R3 = R1 × R2 × R3
(h) Selektionen sind untereinander vertauschbar:
σp(σq(R)) = σq(σp(R))
Eine Optimierung der Anfrage wird hierbei durch die Wahl der Restriktivsten
zur inneren Selektion erreicht.
(i) Alle Konjunktionen in einer Selektionsbedingung können in mehrere Selektionen
aufgebrochen, bzw. nacheinander auszuführende Selektionen können
durch Konjunktionen zusammengefügt werden:
σp1∧p2∧...∧pn(R) = σp1(σp2(. . . (σpn(R)) . . .))
(j) Alle geschachtelten Projektionen können eliminiert werden:
πl1(πl2(. . . (πln(R)) . . .)) = πl1(R)
”←” falls l1 ⊆ l2 ⊆ . . . ⊆ ln ⊆ sch(R)
(k) Eine Selektion kann mit einer Projektion vertauscht werden, falls die Projektion
keine Attribute der Selektionsbedingung entfernt. Es gilt also folgendes:
πl(σp(R)) = σp(πl(R))
”→” falls attr(p) ⊆ l
Ist dies nicht der Fall, kann die Vertauschung vorgenommen werden, wenn
die Projektion um die notwendigen Attribute erweitert wird, die danach
wieder wegprojiziert werden können:
πl1(σp(πl2(R))) = πl1(σp(R))

12 KAPITEL 2. ALGEBRAISCHE OPTIMIERUNG
”←” falls l1 ∪ attr(p) = l2 ⊆ sch(R)
In der Praxis wird jedoch die Richtung von ”→” für Ersetzungen genutzt,
so daß kein Aufblähen durch zusätzliche Projektionen erfolgt.
(l) Jede Selektion kann an einer Joinoperation (oder einem Kreuzprodukt)
” vorbeigeschoben“ werden, falls sie nur Attribute eines der beiden Join-
Argumente verwendet. Enthält die Bedingung p beispielsweise nur Attribute
aus R1, dann gilt auch:
Allgemeiner gesagt gilt:
σp(R1 ✶ R2) = σp(R1) ✶ R2
σp(R1 × R2) = σp(R1) × R2
σp(R1 ✶q R2) = σp0(σp1(R1) ✶q σp2(R2))
falls attr(pi) ⊆ sch(Ri) für i = 1, 2 und p = p0 ∧ p1 ∧ p2 gilt. Für das
Kreuzprodukt gilt entsprechend
σp(R1 × R2) = σp0(σp1(R1) × σp2(R2))
(m) Auf ähnliche Weise können auch Projektionen verschoben werden. Hier muß
allerdings beachtet werden, daß die Joinattribute bis zum Join erhalten
bleiben müssen:
πl(R1 ✶p R2) = πl(πl1(R1) ✶p πl2(R2)) mit
l1 = sch(R1) ∩ (l ∪ attr(p)) und
l2 = sch(R2) ∩ (l ∪ attr(p))
(n) Desweiteren können Selektionen mit Mengenoperationen wie Vereinigung,
Schnitt und Differenz vertauscht werden, also:
σp(R1 ∪ R2) = σp(R1) ∪ σp(R2)
σp(R1 ∩ R2) = σp(R1) ∩ σp(R2)
σp(R1 − R2) = σp(R1) − σp(R2)
Vorausgesetzt, daß die Definition des Durschnittes sch(R1) = sch(R2) beinhaltet,
dann gilt zusätzlich dazu noch:
σp(R1 ∩ R2) = σp(R1) ∩ R2
Darüberhinaus reicht es bei der Differenz aus, die Tupel aus der ersten
Relation herauszustreichen, so daß folgt:
σp(R1 − R2) = σp(R1) − R2
(o) Jeder Projektionsoperator kann mit der Vereinigung vertauscht werden. Sei
sch(R1) = sch(R2), dann gilt:

2.1. RECHENREGELN DER RELATIONALEN ALGEBRA 13
πl(R1 ∪ R2) = πl(R1) ∪ πl(R2)
Eine Vertauschung der Projektion mit Durchschnitt und Differenz ist allerdings
im allgemeinen falsch.
(p) Eine Selektion und ein Kreuzprodukt können zu einem Join zusammengefaßt
werden, wenn die Selektionsbedingung eine Joinbedingung ist, sie also
Attribute einer Relation mit Attributen der anderen vergleicht:
σ(R1.A1=R2.A2)(R1 × R2) = R1 ✶(R1.A1=R2.A2) R2
Allgemeiner gesagt gilt für li ⊆ sch(Ri) mit i = 1, 2, und einem Vergleichsprädikat
θ:
σ(l1 θ l2)(R1 × R2) = R1 ✶(l1 θ l2) R2
(q) Desweiteren können an Bedingungen Veränderungen vorgenommen werden.
Da die Bedingungen aus Attributen, Konstanten, Prädikaten wie = und den
logischen Verknüpfungen ∧, ∨ und ¬ bestehen, können alle hierfür geltenden
Regeln benutzt werden. Beispielsweise kann eine Disjunktion mit Hilfe von
DeMorgans Gesetz in eine Konjunktion umgewandelt werden, um vielleicht
später die Anwendung von Regel (i) zu ermöglichen:
¬(p1 ∨ p2) = ¬p1 ∧ ¬p2
¬(p1 ∧ p2) = ¬p1 ∨ ¬p2
Weiterhin ist diese Regel anwendbar, um Negationen ” von außen nach innen“
zu schieben.
(r) Es gilt wegen des Absorptions-Gesetzes für den natürlichen Verbund:
R1 ✶ R2 = R1, falls R1 ⊆ R2
(s) Weiter wird aus dem Anfragebaum ein dag“ (directed acyclic graph) bzw.
”
” collapsed tree“, wenn an zwei Knoten des Anfragebaumes das gleiche Zwischenergebnis
vorliegt. Der Teilbaum τ muß nur einmal berechnet werden.
✪❡❡
′
✪ τ
�
� ❅
✪❡
✪
✪ τ ❡ τ
❡
✪ ❡
✲
✪❡❡
′
✪ τ
❅
✪
✪❡
✪ ❡
✪
τ
Abbildung 2.1: Vom Anfragebaum zum ” dag“-Tree
Vorsicht: Da aber dabei die Ergebnisrelation des mehrfach vorkommenden
Teilbaumes zwischengespeichert werden muß, kommt es zu einem höheren
Speicherplatzbedarf (Trade-Off). Es ist also abzuwägen, ob verringerter
Zeit- oder verringerter Platzbedarf vorzuziehen ist.

14 KAPITEL 2. ALGEBRAISCHE OPTIMIERUNG
Eine derartige Situation kann auch durch Anwendung der Rechengesetze
hergestellt werden.
(t) Außerdem kann das Zwischenergebnis an einem Knoten auch leer sein z. B.
σp∧¬p(R) = σfalse(R) = ∅.
In diesem Fall kann der Teilbaum, der von diesem Knoten ausgeht, gelöscht
werden.
✪❡
✪ ❡
�
�
✪❡
✪ τ1❡
❅
✪❡
✪ τ2❡
τ ✲
✪❡
✪ ❡ τ
❅
✪❡
✪ ❡ τ2
Abbildung 2.2: Eliminierung leerer Teilbäume
(u) Weiterhin ist eine Selektion auf ganz R redundant:
σtrue(R) = R
(v) Schließlich kann ein entarteter Anfragebaum durch Anwendung der Regeln
(f) und (g) zu einem ausgewogenen Operatorbaum umgewandelt werden.
✁ ❆ ✶ ✁✁
R1 R2
✁
✶ R4
❆
R3
✁ ❆ ✶
✲
✁
R1 R2
✁ ❆ ✶ ✟✟✟ ✶ ❍
❍❍
✶
✁
R3 R4
✁ ❆ Abbildung 2.3: Vom entarteten zu einem ausgewogenen Anfragebaum
2.2 Beispiel für die algebraische Optimierung
Zur besseren Verdeutlichung der bislang vorgestellten Ersetzungsregeln soll hier
eine Anfrage in SQL algebraisch optimiert werden.
Gegeben seien folgende Relationen R1 und R2:

2.2. BEISPIEL FÜR DIE ALGEBRAISCHE OPTIMIERUNG 15
R1 A B C
a 1 10
b 1 20
c 2 10
d 2 35
e 3 45
Die zu bearbeitende Anfrage soll lauten:
Select B, D
From R1, R2
Where R1.A= c ∧ R2.E= 2 ∧ R1.C= R2.C
Mit folgendem Ergebnis:
• 1:1-übersetzt:
B D
2 x
πB,D(σ(R1.A=c∧R2.E=2∧R1.C=R2.C)(R1 × R2))
πB,D
×
✓ ❙
✓ ❙
R1
R2 C D E
10 x 2
20 y 2
30 z 2
40 x 1
50 y 3
σ (R1.A=c∧R2.E=2∧R1.C=R2.C)
R2
Abbildung 2.4: 1:1-übersetzter Anfragebaum
Anfangs wird das Kartesische Produkt von R1 und R2 gebildet, um danach
die benötigten Tupel selektieren zu können. Schließlich wird noch die
verlangte Projektion durchgeführt.
Insgesamt werden (1) + (25) + (5 + 5 · 5) = 56 Tupel bearbeitet. Genauer
gesagt wird für das kartesische Produkt jedes Tupel der äußeren Relation
R1 einmal gelesen, um dann mit jedem Innertupel aus R2 verbunden zu
werden. Das bedeutet, daß die 5 Tupel in R1 je einmal gelesen werden und
jedes der 5 Tupel in R2 so oft gelesen wird, wie es Outertupel gibt (also
5 mal). Das macht 5 + 5 · 5 Tupelzugriffe für das Produkt. Es entsteht
eine Zwischenrelation mit 25 Tupeln. Bei der Selektion wird jedes dieser
Tupel einmal bearbeitet, weitere 25 Zugriffe. Das nächste Zwischenergebnis
enthält nur noch ein Tupel, auf dieses wird die Projektion angewandt, so
daß noch ein Tupelzugriff hinzukommt.

16 KAPITEL 2. ALGEBRAISCHE OPTIMIERUNG
• Algebraisch optimiert ergibt sich nach folgenden Transformationen
der Anfragebaum:
πB,D(σ(R1.A=c∧R2.E=2∧R1.C=R2.C)(R1 × R2))
(i)
= πB,D(σ(R1.A=c∧R2.E=2)(σ(R1.C=R2.C)(R1 × R2)))
(p)
= πB,D(σ(R1.A=c∧R2.E=2)(R1 ✶ R2))
(l)
= πB,D(σR1.A=c(R1) ✶ σR2.E=2(R2))
πB,D
✶
✪ ❡
σ
✪ ❡
(R1.A=c) σ (R2.E=2)
R1
Abbildung 2.5: Algebraisch-optimierter Anfragebaum
R2
Hierbei verschiebt man die Selektionen zu den Blättern nach unten und
ersetzt das Kartesische Produkt durch einen Join.
In diesem Fall werden (1)+(1+1·3)+(5+5) = 15 Tupel bearbeitet. Zunächst
wird auf die beiden Relationen R1, R2 je eine Selektion angewandt. Dafür
muß in jeder Relation jedes Tupel einmal eingelesen werden, das ergibt je
5 also 10 = 5 + 5 Zugriffe. Das Zwischenergebnis von σ(R1) enthält nur
ein Tupel, das von σ(R2) hingegen 3. Wenn man als äußere Relation des
Joins σ(R1) wählt (da diese Relation kleiner ist als σ(R2)), greift man auf
jedes Tupel in σ(R1) bzw. σ(R2) nur einmal zu, das ergibt 4 = 1 + 1 · 3
Zugriffe. Dazu kommt noch einer für die Projektion des einzigen Tupels in
dem entstandenen Zwischenergebnis.
Alleine durch die algebraische Transformation des Anfragebaumes konnte also die
Anzahl der Tupelzugriffe um ca. 73% reduziert werden. Bei dieser Berechnung
wird auch ersichtlich, daß die Größe der Zwischenergebnisse eine wichtige Angabe
zur Optimierung darstellt. Würde man beim Join σ(R2) als äußere Relation
wählen, käme man auf 3 + 3 · 1 = 6 Zugriffe, da das eine Tupel von σ(R1) für
jedes der 3 Tupel in σ(R2) einmal gelesen werden müßte.
Der Unterschied ist bei einem so einfachen Beispiel natürlich nicht besonders
groß, da die Relationen in einer realen Datenbank aber im allgemeinen sehr viele
Tupel enthalten, ist dieser Effekt auf jeden Fall zu beachten.

2.3. HEURISTISCHE ALGEBRAISCHE OPTIMIERUNG 17
2.3 Heuristische algebraische Optimierung
Mit Hilfe der im Abschnitt 2.1 erwähnten Ersetzungsregeln können nun heuristische
Faustregeln formuliert werden. Sie basieren auf langjährigen Erfahrungen
mit Optimierungen und sind bei fast allen Anfragen sinnvoll.
Eine wichtige Faustregel ist, alle Zwischenergebnisse möglichst klein zu halten, da
- wie schon erwähnt und im Kapitel 4 genauer erklärt - die Größe der Zwischenergebnisse
einen sehr großen Einfluß auf die Bearbeitungszeit hat. Hierbei wird
z. B. ausgenutzt, daß Selektionen und Projektionen im allgemeinen Zwischenergebnisse
verkleinern.
Dabei verringern Selektionen die Anzahl der Tupel, wohingegen Projektionen
zunächst einmal die Länge des einzelnen Tupels verkürzen und im Falle einer
Duplikateliminierung zusätzlich die Anzahl der Tupel reduziert wird.
Faßt man jetzt alle Erfahrungen bezüglich der Anfrageoptimierung in Relationalen
Datenbanken hinsichtlich einer algebraischen Optimierung zusammen, kann
man folgende Standardregeln zur Erzeugung eines Prototypen als sinnvoll erachten
(siehe dazu Vossen [57] und Mitschang [36]):
• Unter Anwendung der Regel (g) des Abschnittes 2.1 zerlege man komplexe
Verbundoperationen in binäre Verbunde.
• Unter Anwendung der Regeln (q) und (i) zerlege man Selektions-Operationen
in eine Folge von Selektions-Operationen, deren Bedingung eine Konjunktion
von elementaren Bedingungen ist.
• Unter Anwendung der Regeln (h), (k), (l) und (n) vertausche man Selektionen
mit anderen Operationen, wobei die Selektion soweit wie möglich im
Ausdruck nach innen bzw. im Anfragebaum nach unten verschoben werden
sollte.
• Unter Anwendung der Regel (p) fasse man Produkte und Selektionen zu
Joins zusammen.
• Unter Anwendung der Regeln (j), (k), (m) und (o) zerlege man Projektionen
und verschiebe sie im Ausdruck so weit wie möglich nach innen; dabei
erzeuge man gegebenenfalls zusätzliche Projektions-Operationen.
• Unter Anwendung der Regeln (f), (g) und (v) rearrangiere man die Blätter
des Anfragebaums so, daß diejenigen Operanden, welche mit den restriktivsten
Selektions-Operationen versehen sind, am weitesten links stehen (unter
der Annahme, daß ein solcher Baum in LRW-Ordnung (Links-Rechts-
Wurzel-Durchlauf / Postorder) ausgewertet wird).

18 KAPITEL 2. ALGEBRAISCHE OPTIMIERUNG
• Zum Schluß sollten direkt aufeinander folgende Selektionen bzw. Projektionen
mittels (i) und (j) zusammengefaßt und leere Teilbäume eliminiert
werden (t) und (e).
2.4 Tableau-Optimierung
Ein weiteres Verfahren um einen algebraischen Prototypen zu bekommen, ist die
Tableauoptimierung. Dabei existieren, für redundante Verbund-Operationen aus
einem gegebenen relationenalgebraischen Ausdruck, formale Tableau-Methoden.
Diese bieten nachgewiesenerweise die beste algebraische Optimierung eines Selektion-Projektion-Join-Ausdruckes
(SPJ-Ausdruck).
Dafür wird ein gegebener SPJ-Ausdruck zunächst in ein spezielles Tableau übersetzt,
welches eine Zeile mehr hat, als in der Anfrage Verbund-Operationen vorkommen.
Dieses Tableau wird dann mit dem Ziel der Elimination von Zeilen (und
damit redundanter Verbund-Operationen) optimiert und schließlich in einen optimierten,
äquivalenten SPJ-Ausdruck rückübersetzt.
Für eine nähere Erläuterung bezüglich - der hier erwähnten Tableau-Optimierung
- verweise ich auf die Dissertation von Yehoshua Sagiv [47].
2.5 Fazit der algebraischen Optimierung
Bei den meisten Regeln ist nur eine Richtung für die Optimierung eines Anfragebaums
wichtig, da nur diese eine Verbesserung der Anfrage ermöglicht (siehe
dazu Kapitel 6). Zusätzlich dazu ergaben sich im Laufe der Zeit Erkenntnisse
bezüglich der Ersetzungsregeln, die hier kurz zusammengefaßt werden sollen.
Die im ersten Abschnitt vorgestellten Regeln (a) bis (g) und (r) werden später
nicht mehr benötigt, da sie von der benutzten Datenstruktur selber übernommen
werden, das heißt z. B. das Kommutativität und Assoziativität der Operatoren
in der Implementierung verankert sind. Ihre Existenz ist aber maßgeblich für alle
darauf folgenden Ersetzungsregeln.
Bei der Regel (l) wird stillschweigend vorausgesetzt, daß der Optimierer die Selektionen
zu den zugehörigen Relationen zuweisen kann, wobei er bei jedem Schritt
genau die richtige Operation bearbeitet. Dafür wird aber eine spezielle Reihenfolge
der Selektionen benötigt. Grund dafür ist die rekursive Baumdurchwanderung,
die eine leichte Ersetzung der einzelnen Operatoren zuläßt. Bei dieser müssen die
benötigten Selektionen so aufgeteilt werden, daß sie flexibel im Baum verschoben

2.5. FAZIT DER ALGEBRAISCHEN OPTIMIERUNG 19
werden können. Meistens hilft es, wenn man die restriktivste Selektion als letzte
bearbeitet.
Letztendlich wird die richtige Reihenfolge der Selektion durch einen eigens für diese
Aufgabe programmierten Optimierer erledigt, der für jeden Fall die benötigte
Reihenfolge liefert - unabhängig von der Eingabe der Konditionen. Eine einfache
Lösung dieser Problematik besteht darin, die vorher vorgestellte Regel (i)
zu benutzen, denn diese zerlegt die Selektionsbedingungen in atomare Prädikate,
bei denen man die Reihenfolge vorgeben kann. Somit wird die Sortierung der
Selektionen von der Regel (i) vorgenommen, bei der die spätere Implementierung
einfacher ist.
Die Regel (o) wird in den meisten Büchern über Anfrageoptimierung auch mit
Durchschnitt und Differenz angegeben (z. B. bei Mitschang [36]). Dieses ist aber
falsch. Zur Erklärung hier ein kurzes Gegenbeispiel:
Seien folgende Relationen R1, R2 mit gleichen Schemata gegeben:
R1 A B C
2 2 3
3 3 1
R2 A B C
1 1 1
2 2 1
Die gewünschte Operation sei πA,B(R1) ∩ πA,B(R2). Somit bekommt man als Ergebnisrelation:
A B
2 2
Wenn man jetzt aber den Durchschnitt vor der Projektion ausführt πA,B(R1 ∩
R2), bekommt man ein anderes Ergebnis; nämlich die leere Menge. Daraus folgt
πA,B(R1) ∩ πA,B(R2) �= πA,B(R1 ∩ R2).
Gleiches gilt auch für die Differenz zweier Relationen. Auch da können unterschiedliche
Ergebnisse vorkommen.
Die im vorigem Abschnitt vorgestellte Heuristik basiert auf dem Ablauf, der bei
Vossen [57] wieder zu finden ist. Dabei wurde die Regel (p) hinzugefügt, da die
meisten Bücher annehmen, daß Kartesische Produkte gar nicht mehr existieren,
sondern generell schon - bei der 1:1-Übersetzung in den Anfragebaum - als Joins
interpretiert werden. Dieser Sachverhalt entzieht aber dem Nutzer die Möglichkeit,
bei der Bearbeitung der Heuristik einzelne Abläufe zu verändern und den
speziellen Beispielen anzupassen (bei der später vorgestellten Implementierung
werden dafür mehrere Beispiele vorgeführt).
Weitere Bücher (darunter Mitschang [36] und Kemper [29]) haben teilweise andere
Abläufe, die aber - nach mehreren Testdurchläufen mit verschiedenen Bei-

20 KAPITEL 2. ALGEBRAISCHE OPTIMIERUNG
spielen - als weniger geeignet erschienen. Meistens wurde nur ein rudimentärer
Algorithmus angegeben, bei dem das Aufbrechen der Selektionen und darauffolgende
Verschiebungen in die Äste des Anfragebaumes die einzigen Optimierungen
darstellte.
Am Beispiel 2.2 ist leicht zu erkennen, daß nicht immer ein vollständiger Ablauf
der Heuristik benötigt wird. In diesem Fall werden nur drei Regeln benutzt, um
den gesamten Anfragebaum zu optimieren.

Kapitel 3
Physische Optimierung
Je weniger Erkenntnisse ein Mensch besitzt,
desto ferner fühlt er sich zu Gott.
Albert Einstein
Bei der physischen Optimierung geht es darum, die logischen Operatoren mit
Hilfe von physischen Operatoren möglichst kostengünstig zu realisieren. Dabei
können für einen logischen Operator mehrere physische Operatoren existieren,
die eventuell auch zusätzliche Informationen (z. B. Indexe) benötigen. Außerdem
sind für die physische Optimierung noch zusätzliche Operatoren, die kein logisches
Äquivalent haben, zu berücksichtigen (z. B. Sortierung oder Indexerzeugung).
Die physischen Operatoren lassen sich unter Zuhilfenahme von Iteratoren definieren.
Dieses Konzept wird im ersten Abschnitt näher erläutert. Die weiteren
Abschnitte beschäftigen sich mit den verschiedenen Zugriffsmethoden 1,2 :
Zugriffsmethoden
❄ ❄ ❄
Scan-Methoden Mengen-Oper. Join-Methoden
❄
Sequential Scan
❄
Index Scan
❄
Produkt
Differenz
❄❄
❄
Vereinigung Hash Join
Durchschnitt
Semijoin 1
❄ ❄
❄ ❄
❄ ❄
Merge Join Index Join
Nested Loop
Antisemijoin 2
Abbildung 3.1: Zugriffsmethoden der physischen Optimierung
Eine wichtige Zusatzinformation für die physische Optimierung können z. B. die
Integritätsbedingungen sein. Deswegen werden dafür zusätzliche Informationen
1 Semijoin ist kein eigenständiger Join, sondern wird aus den anderen Join-Varianten erzeugt.
2 Hierbei handelt es sich, um das Komplement zum Semijoin.
21

22 KAPITEL 3. PHYSISCHE OPTIMIERUNG
aus statischen Datenbeständen oder statistischen Auswertungen zu Hilfe genommen.
Grundlage sind dabei Auswertungen bisheriger Anfragen, deren Ausführungspläne
sowie die dadurch entstandenen Kosten. Problematisch bleibt - wie
wir später sehen werden - die Beschaffung des zusätzlichen Wissens über das
Datenbanksystem.
3.1 Iteratoren und Iteratorbäume
Zwischenergebnisse bei der Auswertung von Anfragebäumen müssen in der Regel
nicht gespeichert werden. Sie könnten aber in vielen Fällen so groß werden, daß
sie nicht komplett in den Hauptspeicher passen. Würde man sie vollständig berechnen,
bevor man den nächsten Knoten im Anfragebaum abarbeitet, so hätte
man zusätzlichen Aufwand zum Laden bzw. Verdrängen dieser Zwischenergebnisse.
Um diese Kosten zu vermeiden, implementiert man die Operationen eines
Anfragebaumes mit sogenannten Iteratoren.
Ein Iterator liefert keine kompletten Zwischenergebnisse, sondern liefert nur die
Ergebnistupel einzeln weiter zu dem ihm übergeordneten Iterator.
Deshalb bietet jeder Iterator folgende Funktionen:
• open: öffne den Iterator (beginne die Suche nach Elementen beim 1. Element)
• next: gebe das nächste Tupel der Berechnung weiter
• close: schließe den Iterator
• size: schätze die Größe des Ergebnisses ab
• cost: schätze die Kosten der Berechnung ab
Physische Optimierung übersetzt deshalb logische Anfragebäume der relationalen
Algebra in sogenannte Iteratorbäume, wobei jeder Iterator für einen Algebraoperator
im Algebra-Anfragebaum steht.
Dabei öffnet das Anwendungsprogramm einen Iterator und fordert mit next solange
Tupel an, bis keine mehr geliefert werden. Danach wird der Iterator geschlossen
(end-of-iter Funktion). Für die Berechnung der Ergebnistupel benötigt
dieser Iterator die Ausgaben der mit ihm verbundenen Tochteriteratoren. Deshalb
wird er bei den Tochteriteratoren wieder open, next und close aufrufen.
Dies wird bis zu den Blättern des Baumes, an denen sich die Basisrelationen der
Datenbank befinden, fortgesetzt.
Zusätzlich zu einer eleganteren Architektur bietet das Iteratorkonzept den Vorteil,
daß man nicht notwendigerweise Zwischenergebnisse speichern muß. Nehmen
wir mal an, daß eine Anfrage nur Projektionen und Selektionen beinhalten würde,

3.1. ITERATOREN UND ITERATORBÄUME 23
Anwendungsprogramm
Iterator
open next close size cost
Iterator
�
�
❅
❅
Iterator
open next close size cost open next close size cost
�
� ❅ ✎☞ ❅✎☞
R3
✍✌
R4
✍✌
Iterator
open next close size cost
�
� ❅ ✎☞ ❅✎☞
R3
✍✌
✍✌
Abbildung 3.2: Schematische Darstellung eines Auswertungsplanes
dann hätten wir bei Prozeduren, die jeweils einen algebraischen Operator komplett
berechnen, im allgemeinen für jedes Teilergebnis eine Speicherung der Zwischenergebnisse.
Bei der schrittweisen Realisierung werden die Ergebnisse Stück
für Stück durchgereicht, was man dann als kostensparendes Pipelining verstehen
kann.
Zur Vereinfachung der Darstellung der folgenden Iteratoren sollen Trivialoperationen,
die bei jedem Iterator vorkommen, hier einmal erwähnt werden und später
als Grundlage zur Verfeinerung der jeweiligen Iteratoren dienen (z. B. muß bei
manchen Iteratoren open, next das nächste next vorbereiten):
iterator Generisch
open
• Initialisierung (Öffnen des Eingabestroms (ES) und des Ausgabestroms (AS))
next
• Berechnung des nächsten Ergebniselements (und Bereitstellung desselben im
AS)
close
• Abschließen der Verarbeitung (Schließen der offenen Objektströme und Freigeben
temporärer Datenbereiche)
R4
Abbildung 3.3: Generischer Iterator

24 KAPITEL 3. PHYSISCHE OPTIMIERUNG
3.2 Scan-Methoden
Unter den Scan-Methoden werden diejenigen physischen Operatoren zusammengefaßt,
die nur auf einer Relation arbeiten, d.h. die Entsprechungen zu Projektion
und Selektion.
3.2.1 Projektion
Da die Projektion in der physischen Algebra ausschließlich die Projektion der
Tupel und nicht die Duplikateliminierung durchführen soll, sieht der Iterator zur
Projektion wie folgt aus:
iterator π Rel
l
open
next
• Fordere Tupel aus der Eingabe an
• Projiziere das Tupel auf die Attributmenge l
• Gib dieses Tupel aus
close
Abbildung 3.4: Projektions-Iterator
Die Komplexität beläuft sich hierbei auf O(n).
3.2.2 Selektion
Die hier vorgestellte Implementierung kann man als Brute-Force Variante ansehen.
Bei jedem Aufruf von next wird ein die Bedingung erfüllendes Tupel
zurückgeliefert. Die Komplexität erfüllt dabei eine Abschätzung von O(n) (siehe
Abbildung 3.5).
Bei der nachfolgenden Variante wird der Zugriff über eine Indexstruktur ermöglicht
(sei es eine B-Baum- oder eine Hashtabellen-Implementierung). Hierbei wird
beim Öffnen des Iterators schon das erste passende Tupel nachgeschlagen. Bei
einem B + -Baum erreicht man das, indem man innerhalb des Baumes bis zu den
Blättern absteigt. Die Blätter können dann bei jedem next-Aufruf sequentiell
durchsucht werden, bis die Bedingung p nicht mehr zutrifft (siehe Abbildung
3.6).

3.3. JOIN-METHODEN (✶P , ⊲⊳P ) 25
iterator σ Rel
p
open
next
• Hole solange nächstes Tupel der Eingabe, bis eines die Bedingung p erfüllt
• Gib dieses Tupel aus
close
iterator σ Ind
p
open
next
Abbildung 3.5: Selektions-Iterator
• Schlage im Index die TID des nächsten Tupels nach, welches die Bedingung p
erfüllt
• Lies das Tupel zur TID und gib es aus
close
Abbildung 3.6: Selektions-Iterator mit Zugriff über vorhandenen Index
3.3 Join-Methoden (✶p, ⊲⊳p)
Der relationale Join-Operator (✶p) verknüpft zwei Relationen miteinander und
erzeugt dadurch die Ausgaberelation. Meistens werden Joins zur Vermeidung von
kartesischen Produkten eingesetzt. Die Verknüpfung von Tupeln der Eingaberelationen
erfolgt genau dann, wenn das Verbundprädikat von den Partnertupeln
erfüllt wird.
Verbundoperationen werden durch drei Merkmale charakterisiert (siehe dazu Mitschang
[36]):
• Verbundprädikat:
Je nachdem, welches Prädikat verwendet wird, unterscheidet mandenGleichheitsverbund
(Gleichheitsbedingung als Prädikat), den Ungleichheitsverbund
(Ungleichheitsverbund als Prädikat) und den Intervallverbund (echte
Komparatoren als Prädikat, d.h. wenn der Verbund keine dieser Bedingungen
erfüllt, kann nur der nachfolgende NestedLoop-Join benutzt werden).
• Anzahl der Verbundpartner:
Zwei Verbundpartner erzeugen einen binären Verbund, ansonsten spricht
man von einem Mehrwegverbund bzw. n-nären Verbund, der aber mittels

26 KAPITEL 3. PHYSISCHE OPTIMIERUNG
Assoziativgesetz in mehrere binäre Joins aufgespalten wird.
• Art des Verbundes:
Die in dem Verbund realisierten Verknüpfungen der Partnerrelationen können
für den Fall des Binärverbundes entweder 1:1, 1:n oder m:n sein.
Desweiteren stellt der dazugehörige Antijoin (⊲⊳p) die Negierung oder besser gesagt,
die Komplementäroperation zum Join dar. Werden beim Join Elemente
kombiniert, falls das Joinprädikat von beiden erfüllt ist, so werden beim Antijoin
gerade die Elemente verbunden, die das Prädikat nicht erfüllen.
In den folgenden Abschnitten werden vier Implementierungsvarianten des Join-
Operators in Bezug auf Binärverbunde beschrieben und erklärt. Hierbei wird die
Iteratorschreibweise zur Beschreibung der Varianten benutzt. Im Anschluß daran
wird noch auf die Verwandtschaft des Join-Operators zu den Mengenoperatoren
hingewiesen.
3.3.1 NestedLoop-Join (✶NestedLoop p )
Die wahrscheinlich erste Idee, die man zur Implementierung einer Verbundoperation
hat, ist die Schleifenschachtelung (engl. Nested Loop). Hierbei wird jedes Tupel
des ersten Operanden mit jedem Tupel des zweiten verglichen. Bei Erfüllung
der Join-Bedingung werden die beiden Tupel miteinander verbunden.
Die Schleifeniteration läßt sich wie folgt mit Iteratoren darstellen:
iterator ✶ NestedLoop
p
open
• öffne rechten Iterator, rufe solange next auf bis der Iterator keine Tupel mehr
liefert und speichere jedes so erhaltene Tupel in einer temporären Relation temp
• hole erstes linkes Tupel und setze Zeiger auf das erste Tupel von temp
next
• setze den Zeiger auf temp solange weiter bis Bedingung p erfüllt ist
– falls dabei temp keine Tupel mehr liefert, so hole nächstes linkes Tupel
und setze Zeiger auf erstes Tupel von temp
• gib Join der beiden Tupel aus
close
Abbildung 3.7: NestedLoop-Iterator

3.3. JOIN-METHODEN (✶P , ⊲⊳P ) 27
Es ist offensichtlich, daß die Komplexität des gerade beschriebenen Verbundes
(Laufzeit bei gleichen Eingabelängen O(n 2 )) vom Aufwand des Zugriffes auf die
Eingabeströme abhängt. Deshalb gibt es eine Vielzahl von Verbesserungsmöglichkeiten.
Die erste mögliche Zugriffsoptimierung liegt darin, statt der Durchführung der
Schleifeniteration auf Elementbasis ganze Cluster als Schleifengranulat zu verwenden,
die je nach Blockgröße aus einer bestimmten Elementanzahl bestehen.
Aufgrund der Tatsache, daß mit Hilfe dieser Verfahrensänderung die Zahl der
Schleifeniterationen drastisch minimiert werden kann, reduziert sich die Komplexität
erheblich.
Darüberhinaus ist die Schleifeniteration auch kombinierbar mit Indexzugriffen,
wobei es unwichtig ist, welche Zugriffsstruktur verwendet wird (Index- oder Hash-
Strukturen).
3.3.2 Index-Join (✶Index p )
Eine durch die Nutzung eines Index verbesserte Verbundoperation wird Index-
Join genannt. Dabei wird ein Index auf dem Joinattribut einer oder beider Relationen
als vereinfachte Zugriffsmethode benutzt. Manchmal lohnt sich sogar die
Schaffung eines Indexes, um den Zugriff zu beschleunigen. Es sollte auch erwähnt
werden, daß die Iteratoren TID-Folgen liefern und nicht wie die anderen Implementierungen
Tupel wieder zurückgeben. Die Index-Join Varianten stellen sich
mit Iteratoren wie folgt dar (siehe Tabelle 3.8).
iterator ✶ Rel,Index
p
open
next
• Falls TID-Folge nicht vorhanden, hole nächstes Tupel aus der linken Eingabe,
schlage Joinattributwert des linken Tupels im Index nach, setze Zeiger auf den
ersten Eintrag der dadurch erhaltenen TID-Folge
• Falls TID-Folge vorhanden, setze Zeiger auf den nächsten linken TID
• Schlage passendes Tupel zum aktuellen TID nach
• Bilde Join und gib das Jointupel aus
close
Abbildung 3.8: Relationen-Index-Join-Iterator

28 KAPITEL 3. PHYSISCHE OPTIMIERUNG
iterator ✶ Index,Index
p
open
next
• Falls TID-Folge nicht vorhanden, hole nächstes TID aus dem Index der linken
Eingabe, hole passendes Tupel, schlage Joinattributwert des linken Tupels im
Index der rechten Eingabe nach, setze Zeiger auf den ersten Eintrag der dadurch
erhaltenen TID-Folge
• Falls TID-Folge vorhanden, setze Zeiger auf den nächsten TID
• Schlage passendes Tupel zum aktuellen TID der TID-Folge nach
• Bilde Join und gib das Jointupel aus
close
Abbildung 3.9: Index-Index-Join-Iterator
Dabei wird beim Index-Index-Join davon ausgegangen, daß wir einen Äqui-Join
vorliegen haben. Der Iterator agiert vergleichbar zu einem Merge-Join, im Unterschied
dazu wird aber über einen Index auf die Tupel zugegriffen.
Der Relationen-Index-Join hat eine Komplexität von O(n·log(n)) und der Index-
Index-Join besitzt eine Laufzeit von O(n), falls beide Eingabeströme einen Index
besitzen.
3.3.3 Merge-Join (✶Merge p )
Bei der Implementierung lassen sich die Kosten der Realisierung einer Verbundoperation
reduzieren, indem die jeweiligen Operanden bereits sortiert im Speichersystem
vorliegen bzw. vor dem eigentlichen Verbund in eine temporäre Relation
sortiert werden. Diese Zugriffsmethode wird dann als Misch-Verbund (engl.
Merge-Join) bezeichnet. Dabei müssen die Operanden sortiert (bezüglich des
Joinattributes) vorliegen, um danach jeweils sequentiell durchsucht zu werden.
Hierbei werden die zu verbindenen Tupel, die die Join-Bedingung erfüllen, jeweils
einzeln dem Resultat zugewiesen.
Bedingung für den Merge-Join ist, daß die linke Eingabe keine Duplikate bezüglich
des Joinattributes enthält. Sollte dies doch der Fall sein, kann nach der Anwendung
des Kommutativgesetzes für Joins trotzdem ein Merge-Join verwendet werden.
Merge-Join besitzt eine Laufzeit von O(n), falls die beiden Eingangsströme schon
sortiert vorhanden sind.

3.3. JOIN-METHODEN (✶P , ⊲⊳P ) 29
Der Merge-Join (für unique-Join-Attribute) läßt sich wie folgt mit Iteratoren
darstellen:
iterator ✶ Merge
p
open
• Öffne beide Eingaben
• Hole linkes und rechtes Tupel
next
• Solange bis p erfüllt ist
– bestimme Eingabe mit kleinerem anliegendem Joinattributwert
– hole aus dieser Eingabe das nächste Tupel
• Gib den Join der beiden aktuellen Tupel aus.
close
3.3.4 Hash-Join (✶Hash p )
Abbildung 3.10: Merge-Join-Iterator
Der Hash-Join nutzt eine dynamisch aufgebaute Hash-Funktion zum schnellen
Auffinden von Verbundpartnern. Die Hash-Funktion wird dafür verwendet, beide
Relationen in Partitionen zu zerlegen. Der Vorteil dabei ist, daß nicht mehr alle
Tupel miteinander verglichen werden müssen, sondern nur noch Tupelpaare, die
in Partitionen mit gleichem Hashwert vorkommen.
Meistens ist die Tabelle so klein, daß sie im Speicher gehalten werden kann; somit
genügt ein einmaliges Lesen des anderen Join-Operanden, um den Verbund zu
berechnen.
Die Komplexität des Hash-Joins wird mit O(k ·n) angegeben, wobei k für die Anzahl
der Partitionen steht. Der Hash-Verbund ist im wesentlichen nur für Gleichheitsprädikate
mit θ ∈ {=} geeignet, aber man kann ihn auch prinzipiell bei
allen anderen einsetzen. Für eine genauere Darstellung dieses komplexen Themas
verweise ich deshalb auf die Arbeit von H. Garcia-Molina, J. D. Ullman und J.
Widom [37].

30 KAPITEL 3. PHYSISCHE OPTIMIERUNG
iterator ✶ Hash
p
open
• Öffne kleinere Relation (Build Input)
• Partitioniere Build Input solange bis die Partitionen in den Hauptspeicher passen.
• Öffne die andere Relation (Probe Input)
• Partitioniere Probe Input mit der gleichen Hashfunktion
• Lade erste Partition des Build Inputs in den Hauptspeicher und setze Zeiger
auf das erste Tupel
• Lade erste Partition des Probe Inputs in den Hauptspeicher
next
• Hole solange Tupel aus der aktuellen Partition des Probe Inputs bis die Bedingung
p erfüllt ist.
– Falls die Partition von Probe Input leer ist, setze den Zeiger auf das
nächste Tupel der aktuellen Partition von Build Input
– Falls die Partition von Build Input ebenfalls leer ist, lade jeweils die
nächste Partition von Probe und Build Input und setze den Zeiger auf
das erste Tupel der Partition des Build Inputs
• Gebe das gefundene Paar aus
close
Abbildung 3.11: Hash-Join-Iterator
3.3.5 Semijoin (⋉p, ⋊p) - Antisemijoin ( ¯⋉p)
Der Semijoin ⋉p ist für Relationen R1, R2 wie folgt definiert:
R1 ⋉p R2 = R2 ⋊p R1
= πsch(R1)(R1 ✶p R2)
= R1 ✶p πattr(p)(R2)
Das heißt, daß ein Semijoin aus der Relation R1 all diejenigen Tupel heraussucht,
die bezüglich des Prädikates p mindestens einen Joinpartner in der Relation R2
besitzen.
Für einen Semijoin gibt es genau die gleichen Möglichkeiten wie für einen Join:
Man kann ihn als NestedLoop-, Merge-, Index- und Hash-Semijoin implementieren.
Somit erhält man die entsprechenden Laufzeiten wie bei den passenden

3.3. JOIN-METHODEN (✶P , ⊲⊳P ) 31
Joins. Der Iterator zu den verschiedenen Semijoin-Operatoren ist jeweils fast der
gleiche wie bei dem Join-Operator, mit dem kleinen Unterschied, daß stets statt
des Verbundes zweier passender Tupel nur das linke Tupel ausgegeben wird und
die Suche nach Join-Partnern in der rechten Eingabe (Relation bzw. Index) abgebrochen
wird, falls ein Partner für das linke Tupel gefunden wurde.
Für Join und Semijoin gilt:
R1 ✶p R2 = (R1 ⋉p πattr(p)(R2)) ✶p R2.
Aus dieser Gleichung folgt die Möglichkeit, bei verteilten Datenbanken den Transfer
zu verringern. Soll ein Join zweier Relationen vorgenommen werden, die auf
zwei verschiedenen Sites gespeichert sind, kann zunächst die Projektionπattr(p)(R2)
gebildet und versendet werden, daraufhin mittels eines Semijoins R1⋉pπattr(p)(R2)
die ” überflüssigen“ Tupel (sogenannte dangling-tupel) der Relation R1 eliminiert
und die benötigten Tupel, also das erhaltene Zwischenergebnis, zurückgesandt
werden. Zum Abschluß wird ein Join dieses Zwischenergebnisses und der Relation
R2 gebildet. Insbesondere wenn es viele dangling-Tupel gibt, spart diese
Ausführung viel Datentransfer ein.
Der Antisemijoin ( ¯⋉p) liefert im Gegensatz zum Semijoin alle die Tupel aus R1,
die keinen Joinpartner in der zweiten Relation R2 haben:
R1 ¯⋉p R2 = R1 − (R1 ⋉p R2)
3.3.6 Outer-Joins (❂⋊p, ⋉❁p, ❂×❁p)
Die bislang eingeführten Join-Operator nennt man normalerweise Inner-Joins, da
bei dieser Variante die Tupel der Argumentrelation verloren gehen, die keinen
Joinpartner gefunden haben. Bei der Outer-Join Operation werden je nach Typ
auch partnerlose Tupel der linken, der rechten bzw. beider Argumentrelationen
ins Ergebnis übernommen, dabei werden die fehlenden Attribute bei den partnerlosen
Tupeln mit Nullwerten aufgefüllt.
• Left-Outer-Join (❂⋊p)
Die partnerlosen Tupel der linken Relation, rechts aufgefüllt mit Nullwerten,
werden dem Ergebnis hinzugefügt.
• Right-Outer-Join (⋉❁p)
Die partnerlosen Tupel der rechten Relation, links aufgefüllt mit Nullwerten,
werden dem Ergebnis hinzugefügt.

32 KAPITEL 3. PHYSISCHE OPTIMIERUNG
• Full-Outer-Join (❂×❁p)
Die partnerlosen Tupel beider Relationen, rechts bzw. links aufgefüllt mit
Nullwerten, werden dem Ergebnis hinzugefügt.
Die verschiedenen Iteratoren der Left-, Right- und Full-Outer-Joins ähneln den
vorher vorgestellten Alternativen NestedLoop-, Merge-, Index- oder Hash-Join,
wobei nach Ausführung des Inner-Joins in der next-Phase je eines der restlichen
verlangten Tupel ausgegeben wird.
3.4 Mengenoperatoren
Die in jeder Datenbank implementierten Mengenoperatoren wie Vereinigung, Differenz,
Durchschnitt und Produkt lassen sich leicht auf Verbundbildung zurückführen.
So ist zum Beispiel das kartesische Produkt ein Spezialfall des Join-Operators
mit true als Verbundbedingung. Somit werden alle Tupel des einen Joinpartners
mit allen Tupeln des anderen Verbundpartners kombiniert.
Insgesamt erzeugt das Produkt immer eine maximale Ergebnisgröße bezogen sowohl
auf Tupelanzahl als auch auf Attributanzahl. Im Vergleich dazu berechnet
eine Joinoperation, aufgrund der benutzten Selektion, weniger Ergebniselemente
mit zum Teil weniger Attributen, deshalb sollte man möglichst jedes Produkt in
kostengünstige Joins verwandeln.
Interessanterweise ist die Hash-Methode für das Kartesische Produkt ungeeignet,
da sie im wesentlichen auf einer geschickten und scharfen Partionierung beruht,
die für diese Operation nicht existiert. Im Gegensatz dazu könen bei den anderen
Mengenoperationen beide Eingabeströme, abhängig von der jeweiligen Operation,
in der gleichen Hash-Tabelle organisiert werden, aus der dann das Ergebnis
einfach abzuleiten ist.
Bei allen anderen Mengenoperationen läßt sich der Operator durch Gleichheit der
Attribute und geeignete Joinvarianten realisieren.
Gegeben seien zwei Relationen R1 und R2 mit gleichen Schemata, sowie die Teilmengen
A, B und C mit A := R1 − R2, B := R1 ∩ R2 und C := R2 − R1, dann
folgt 3 :
3 p = �
D∈sch(R1)=sch(R2) R1.D = R2.D

3.5. SORTIERUNG UND DUPLIKATELIMINIERUNG 33
R1
✬
✬
A B C
✫
✫
✩
✪
R2
✩
✪
Operations- Operation Joindarstellung mit Vergleich
ergebnis auf allen Attributen
A R1 − R2 ¯⋉p(R1, R2)
B R1 ∩ R2 ✶p (R1, R2) oder ⋉p(R1, R2)
C R2 − R1 ¯⋉p(R2, R1)
A, B R1 ❂⋊p(R1, R2) = R1
A, C (R1 − R2) ∪ (R2 − R1) ⊲⊳p(R1, R2)
B, C R2 ⋉❁p (R1, R2) = R2
A, B, C R1 ∪ R2 ❂×❁p (R1, R2)
Tabelle 3.1: Zusammenfassende Darstellung der Mengenoperationen
3.5 Sortierung und Duplikateliminierung
Bei den in diesem Kapitel vorgestellten Operatoren wird grundsätzlich keine Duplikateliminierung
vorgenommen. Dafür werden die folgenden Dup-Methoden eingeführt.
Es können die schon im vorigen Abschnitt benutzten Methoden eingesetzt
werden (aus diesem Grund verzichten wir diesmal auf die Iteratoren, siehe
dazu Kapitel 3.3). Dabei vergleicht die Brute-Force Methode NestedDup einfach
analog zum NestedLoops-Join - in einer geschachtelten Schleife - jedes Tupel mit
jedem anderen.

34 KAPITEL 3. PHYSISCHE OPTIMIERUNG
Liegt hingegen eine Sortierung vor, braucht die Eingabe lediglich von Anfang
bis Ende einmal durchsucht und Doppelte gelöscht zu werden. Dieses Vorgehen
wird SortDup genannt. Alternativ dazu kann auch ein Index benutzt werden, der
entstehende Operator heißt IndexDup.
Die Laufzeiten dieser Operatoren ergeben sich zu O(n 2 ) für den NestedDup und
O(n) für Sort- und IndexDup. Dabei ist natürlich für Sort- bzw. IndexDup das
Vorliegen einer Sortierung bzw. eines Index Grundvoraussetzung.
Es kann sinnvoll sein, Zwischenrelationen zu sortieren, wenn dadurch später z. B.
durch Anwendung eines Merge-Joins anstelle eines NestedLoops-Joins die investierte
Zeit wieder eingespart werden kann. Für die Sortierung ist der Operator
SortX zuständig, dabei ist X der Sortierungsschlüssel. Die Sortierung hat bekanntlich
eine Laufzeit von O(n · log(n)).
3.6 Übersetzung der logischen Algebra
In diesem Abschnitt werden die einzelnen Operatoren der logischen Algebra (Algebraische
Optimierung) in eine äquivalente Darstellung der physischen Algebra
(Physische Optimierung) übersetzt. Dabei werden zusätzliche Metadaten benutzt.
In den eckigen Klammern stehen Operationen, die nur auszuführen sind,
falls es notwendig ist. Wenn kein Index vorhanden ist, kann mittels Hash bzw.
T ree ein Zugriffsschlüssel aufgebaut werden.
Unäre Operatoren zeigen grundsätzlich eine Komplexität von O(n), alle mit Sortierung
verwandten Operatoren eine von O(n·log(n)) und die binären Operatoren
letztlich höchstens eine Abschätzung von O(n 2 ).
Bei der Übersetzung einer algebraischen Selektion in einen physischen Operator
sollte man sich bewußt sein, daß das Lesen über einen Index eine Sortierung auf
einem Attribut zur Folge haben kann, die für nachfolgende Operationen ausgenutzt
werden könnte. Es ist daher sinnvoll, die Möglichkeit eine Indexselektion
nicht von vornherein zu verwerfen, auch nicht, wenn dieses Attribut in der Selektionsbedingung
nicht vorkommt. Daraus folgt, daß die Wahl des Zugriffs nicht
lokal getroffen werden kann.
Natürlich kann auch in anderen Fällen die beste Implementierung eines algebraischen
Operators im allgemeinen nicht lokal gefunden werden. Beispielsweise
kann ein Hash-Join billiger sein als ein Merge-Join, falls im letzteren Fall die
entsprechenden Relationen noch sortiert werden müssen. Folgt jedoch ein Operator,
der die Sortierung ebenfalls ausnutzen kann (z.B. ein weiterer Join oder eine
Projektion mit Duplikatelimierung), so kann es günstiger sein, den Merge-Join
anzuwenden und dafür vorher zu sortieren.

3.7. PHYSISCHE OPTIMIERUNGSMÖGLICHKEITEN 35
Alg. Operator Physischer Operator Komplexität
✶p (R1, R2) = ✶ NestedLoop
p (R1, R2) O(n 2 )
= ✶ NestedLoop
p (R2, R1) O(n 2 )
= ✶ MergeJoin
p ([SortA]R1, [SortB](R2)) O(n), [O(n · log(n))]
= ✶ IndexJoin
p ([HashA|T reeA](R1), O(n), [O(n · log(n))]
[HashB|T reeB](R2))
= ✶ HashJoin
p (R1, R2) O(k · n)
σp(R) = σ Rel
p (R) O(n)
= σ Index
p (R) O(n)
πl(R) = [NestedDup](π Rel
l (R)) O(n · log(n))
= [SortDup][SortA](π Rel
l (R)) O(n · log(n))
= [IndexDup][HashA|T reeA](π Rel
l (R)) O(n)
Tabelle 3.2: Algebraische Operatoren und die dazugehörigen physischen Implementierungen
3.7 Optimierungsmöglichkeiten mit physischen
Operationen
(a) Eine Möglichkeit, das Speichern von Zwischenrelationen zu vermeiden, stellt
das sogenannte Pipelining dar. Die Idee dabei ist, das Ergebnis einer Operation,
wenn möglich, nicht zwischenzuspeichern, sondern ein berechnetes
Tupel direkt an die nächste Operation zu übergeben.
Wird zum Beispiel auf eine Relation zunächst eine Selektion und dann eine
Projektion angewandt, so bedeutet das Pipelining, daß ein Tupel der Relation,
welches die Selektionsbedingung erfüllt, nicht in ein Zwischenergebnis
geschrieben wird, sondern daß es direkt an die Projektion weitergereicht,
auf die benötigten Attribute projiziert und erst dann gespeichert wird.
Die Schreibweise hierfür ist 〈π ◦ σ〉. Hierzu sei bemerkt, daß, falls bei einem

36 KAPITEL 3. PHYSISCHE OPTIMIERUNG
Operator keine Spezifizierung wie Rel, Index, NestedLoop etc. angegeben
wird, nicht der algebraische Operator gemeint ist, sondern ein beliebiger
physischer Operator dieser Art.
Dabei gibt es natürlich noch viele andere Operationenpaare, auf die das
Pipelining anwendbar ist, hierbei seien insbesondere die folgenden genannt:
• Pipelining von Selektion und Join:
〈σ ◦ ✶〉(R1, R2) = σ(R1 ✶ R2)
• Pipelining von NestedLoop-Join und Selektion:
〈✶ NestedLoop ◦1 σ〉(R1, R2) = σ(R1) ✶ NestedLoop R2
Dabei besagt der Index, auf welchen Operanden die Selektion anzuwenden
ist, also auf welcher Eingabe das Pipelining stattfindet.
• Pipelining von Merge-Join und Selektion:
〈✶ MergeJoin ◦ [σ Rel
p1 , σRel p2 ]〉(R1, R2) = σp1(R1) ✶ MergeJoin σp2(R2)
Dabei ist die erste Selektion auf die linke Relation und die zweite auf
die rechte anzuwenden.
• Pipelining von Projektion und Join:
〈π ◦ ✶〉(R1, R2) = π(R1 ✶ R2)
• Pipelining von NestedLoop-Join und Projektion:
〈✶ NestedLoop ◦1 π〉(R1, R2) = π(R1) ✶ NestedLoop R2
Dabei besagt der Index, auf welchen Operanden die Projektion anzuwenden
ist.
• Pipelining von Merge-Join und Projektion:
〈✶ MergeJoin ◦ [π Rel
l1 , π Rel
l2 ]〉(R1, R2) = πl1(R1) ✶ MergeJoin πl2(R2)
Dabei ist die erste Projektion auf die linke Relation und die zweite auf
die rechte anzuwenden.
Darüberhinaus ist bei einstelligen Operationen ein Pipelining stets möglich.
Außerdem können diese Pipelinings auch hintereinander ausgeführt werden.

3.8. HEURISTISCHE PHYSISCHE OPTIMIERUNG 37
(b) Die Kosten für die Anfragebearbeitung werden wesentlich durch die Anzahl
der Hintergrundspeicherzugriffe bestimmt. Um diese gering zu halten,
liegt es nahe, die Daten temporär komprimiert zu speichern. Hierbei kann
man die bekannten verlustfreien Verfahren wie Huffman-Komprimierung
(Lauflängenkomprimierung), Nullunterdrückung oder LZW benutzen.
(c) Die Erzeugung von Zugriffspfaden kann unter bestimmten Umständen sinnvoll
sein. Dazu gehören die Anfragen, die die Tabelleninformationen mehrmals
direkt ansprechen und somit eine Indexierung sinnvoll machen, da sie
einen log(n) Zugriff ermöglichen.
(d) Vorhandene Sortierungen können für verschiedene Operatoren genutzt werden.
Falls keine Sortierung existiert, kann es kostensparend sein, diese zu
erzeugen.
(e) Darüberhinaus können temporäre Zugriffspfade angelegt werden, die nicht
permanent abgespeichert werden müssen. Dadurch können Zugriffe auf den
externen Speicher verringert werden.
3.8 Heuristische physische Optimierung
In diesem Abschnitt soll der Ablauf beschrieben werden, der einen algebraisch optimierten
Anfragebaum in einen physischen Prototypen verwandelt. Dabei dienen
die Laufzeiten als maßgebliche Vorgabe zur Auswahl des zu ersetzenden Operators.
Bildlich gesprochen wandert man von unten nach oben (bottom-up) durch den
Baum und ersetzt an jedem Knoten den algebraischen Operator durch einen physischen,
indem man die gegebenen Metadaten als Beurteilungskriterium nimmt. 4
Mit Hilfe der in der Tabelle 3.2. zusammengefaßten physischen Operatoren, läßt
sich wie folgt ein einfacher Algorithmus angeben:
(a) Selektionen werden wie folgt ersetzt:
(1) Selektionen werden durch Index-Selektionen ersetzt, falls ein Index auf
dem gesuchten Attribut vorhanden ist (O(n)).
(2) Wenn nicht, werden einfache Scan Rel
p
(b) Projektionen werden wie folgt ersetzt:
benutzt (O(n)).
(1) Projektionen werden durch Index-Projektionen ersetzt, falls ein passender
Index vorhanden ist (O(n)).
4 Folgende Heuristik ist vom Autor selbst entwickelt worden und wird später durch verschie-
dene Beispiele als sinnvoll bestätigt.

38 KAPITEL 3. PHYSISCHE OPTIMIERUNG
(2) Wenn nicht, wird auf Sortiertheit der Relationen untersucht, um daraufhin
eine SortedDup-Projektion zu benutzen (O(n · log(n))).
(3) Schließlich werden nach dem Scheitern aller vorherigen Varianten die
Relationen durch eine NestedDup-Projektion ersetzt (O(n · log(n))).
(c) Verbunde werden wie folgt ersetzt:
(1) Liegen die Relationen schon vorpartioniert im Hauptspeicher wird ein
Hash-Join mit der Laufzeit von O(k · n) genommen.
(2) Falls nicht, wird nach Indexen gesucht. Je nach gegebenem Index zu
den einzelnen zu verbindenden Relationen wird ein Index-Join oder
ein Index-Index-Join gewählt. (O(n) bzw. O(n · log(n)))
(3) Wenn auch diese Metadaten nicht existieren, untersucht man die Relationen
auf Sortiertheit. Sind beide Relationen sortiert, wird mittels
eines Merge-Join verbunden (O(n)).
(4) Als letzte zu benutzende Variante wird ein einfacher Nested-Loop-Join
zur Verbindung der Relationen genommen (O(n 2 )).
(d) Pipelining der Zwischenergebnisse:
Wie im vorigen Abschnitt erwähnt, kann in Spezialfällen das Speichern der
Zwischenergebnisse vermieden werden. Dabei reicht man die Einzelergebnisse
gleich dem nächsten Operator weiter. Wir untersuchen deshalb den
Anfragebaum auf diese genannten Beispiele und fügen das Pipelining des
Zwischenergebnisses ein (siehe dazu Kapitel 3.7).
(1) Untersuche den Anfragebaum auf Pipelining von Selektion bzw. Projektion
und Join.
(2) Untersuche den Anfragebaum auf Pipelining von NestedLoop-Join und
Selektion bzw. Projektion.
(3) Untersuche den Anfragebaum auf Pipelining von Merge-Join und Selektion
bzw. Projektion.

3.9. BEISPIEL FÜR DIE PHYSISCHE OPTIMIERUNG 39
3.9 Beispiel für die physische Optimierung
Das bekannte Beispiel aus dem Kapitel 2.2 kann jetzt physisch optimiert werden
und erlangt schließlich - mit den gewonnenen Methoden - den bislang kostengünstigsten
Zugriffsplan.
Optimierung mittels Metadaten: Angenommen es gibt einen Index auf dem Attribut
R1.A und einen auf R2.C, dann wäre eine Möglichkeit, die Beispielanfrage
auszuführen, folgende:
(1) Verwendung des R1.A-Index zur schnelleren Selektion von R1-Tupeln mit
R1.A = c (1 Tupelzugriff, Ergebnisgröße=1)
(2) Für jeden dadurch ermittelten R1.C-Wert verwende R2.C-Index zur Bestimmung
der Joinpaare. (1 Tupelzugriff, Ergebnisgröße=1)
(3) Eliminiere (σ(R1) ✶ R2)-Tupel mit E �= 2 (0 Tupelzugriffe, Ergebnisgröße=1)
(4) Projeziere auf B, D. (0 Tupelzugriffe, Ergebnisgröße=1)
Dabei soll auf dem linken Pfad von σA=c bis πB,D ein Pipelining genutzt werden.
Daraus ergibt sich der Anfragebaum:
π Rel
B,D
σ Rel
E=2
✶ Rel,Index
R1.C=R2.C
✪ ❡
✪ ❡
✪
✪
σ Index
A=c
R1
Abbildung 3.12: physisch optimierter Anfragebaum
Durch die Hilfe der Meta-Daten werden kaum noch Tupel gebraucht. Die Anfrage
greift somit direkt auf die 2 benötigten Tupel zu; insgesamt sind also 2
Tupelzugriffe nötig.
R2

40 KAPITEL 3. PHYSISCHE OPTIMIERUNG
3.10 Fazit der physischen Optimierung
In den meisten Büchern (darunter Kemper [29]) werden die in diesem Kapitel
vorgestellten Iteratoren - der verschiedenen physischen Operatoren - nicht genau
genug beschrieben. Deshalb wurde viel Wert darauf gelegt, diese ungenau und
teilweise auch falsch beschriebenen Abläufe, neu zu konstruieren.
Auch die Darstellung der Mengenoperationen durch Verbundoperatoren werden
in der Literatur stiefmütterlich behandelt. Deshalb wurde eine neue Form der
Präsentation gewählt, die die spätere Implementierung stark vereinfachen sollte
(siehe dazu Tabelle 3.1).
Schließlich wurde das Hauptaugenmerk auf die Entwicklung einer physischen Heuristik
zur Schaffung eines physischen Prototypen gelegt. Sie basiert größtenteils
auf dem Zusatzwissen, welches aus den Metadaten der gegeben Ausgangsrelationen
gewonnen wird. Der reine Ablauf ist durch mehrere Tests mit verschiedenen
Beispielen gewonnen worden und sollte nicht als einzig richtig bzw. möglich betrachtet
werden.

Kapitel 4
Kostenfunktionen und
Selektivitäten
Ordnung braucht nur der Dumme,
das Genie beherrscht das Chaos.
Albert Einstein
Optimierungssysteme, die auf fundierten Heuristiken basieren, liefern in der Mehrzahl
der Fälle - innerhalb kurzer Zeit - nahezu optimale Anfrageauswertungspläne.
Leider generieren solche Heuristiken auch schlechte Prototypen, die durch ein
sinnvolles Kostenmodell dann ausgeschlossen werden müssen. Dabei werden verschiedene
Anfragepläne miteinander verglichen, und der Beste wird dann gewählt.
Ein Kostenmodell bietet eine Funktion, die die Laufzeit der Operatoren der physischen
Algebra abschätzt. Dazu werden diverse Parameter benötigt, wie zum
Beispiel Indexe, Cluster, Kardinalitäten und Verteilungen. Anfangs muß die Anzahl
der im Berechnungsprozeß benötigten Tupel durch sinnvolle Funktionen abgeschätzt
und verglichen werden.
Indexinformationen
algebraischer Ausdruck
✲
DB-Kardinalitäten
❄
✻
Kostenmodell
Clusterinformationen
❄
✲ Ausführungskosten
✻
Attributverteilung
Abbildung 4.1: Aufbau eines Kostenmodells
Die Ausgabe der Ausführungskosten entsteht aus mehreren Größen, die dem Zeitoder
Platzbedarf für die Anfrageausführung zugeordnet sind. Für den Zeitbedarf
sind die Kosten für Zugriffe auf den externen Speicher, für Tupelzugriffe und
natürlich den CPU-Berechnungsaufwand entscheidend. Für den Platzbedarf ist
die Gesamtgröße aller im Speicher zu haltenden Relationen wichtig.
41

42 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
4.1 Allgemeine Kostenberechnung
Der Suchraum der Planoptimierungen wird in der Literatur mit B bezeichnet.
Dabei wird folgende Definition der allgemeinen Kostenberechnung vorgenommen:
Definition 4.1.1 Für jeden Anfrageplan P existiert eine Kostenabschätzung bezüglich
der Zugriffsmethoden und -reihenfolgen auf die jeweiligen Operanden;
diese wird mit cost(P) bezeichnet. Zielsetzung ist dann die Generierung des optimalen
Ausführungsplanes Popt ∈ B, so daß gilt:
cost(Popt) = min(P∈B) cost(P)
Die Abschätzung der Zugriffskosten cost(P) eines vollständigen Ausführungsplanes
P werden aus den einzelnen Kostenfunktionen für dessen Blätter bzw. interne
Knoten inkrementell berechnet. Dabei gehen die gewählten Zugriffsmethoden, die
Zugriffsreihenfolge und die Selektivitäten der Prädikate als Parameter in die Kostenberechnungen
ein.
Letztendlich werden die gesamten Kosten eines Ausführungsplanes dadurch ermittelt,
daß man rekursiv die Kosten für jeden einzelnen Knoten Ki, i = 1, . . . , n
berechnet und sie dann zu einem Wert zusammenaddiert:
cost(P) =
n�
cost(Ki)
i=1
Dafür benötigt man die Kosten jedes einzelnen Knotens, die wiederum von der
dort auszuführenden Operation und den Relationen, auf denen sie angewendet
werden, abhängig sind.
Die Kostenfunktionen sind maßgebend für die Auswahl möglicher Alternativen
der Implementierung von Zugriffsmethoden. In den folgenden Abschnitten werden
deshalb die benötigten Funktionen und Abschätzungen vorgestellt, die später als
Basis unserer Bewertung eines Ausführungsplanes dienen werden.
4.2 Kostenfunktion
Die in dieser Diplomarbeit verwendeten Formeln zur Abschätzung der Ausführungspläne,
basieren auf dem Kostenmodell von Selinger, Astraham, Chamberlin,
Lorie und Price [51]. Grund dafür sind die präzisen Abschätzungen, die maßgeblich
den Optimierungsprozeß beeinflussen.

4.2. KOSTENFUNKTION 43
Die jeweiligen Formeln zur konkreten Kostenabschätzung der unterstützten Zugriffsmethoden
sind in den nachfolgenden Tabellen zusammengefaßt. Dabei werden
zunächst die üblichen statistischen Annahmen bezüglich der Gleichverteilung
der Werte über den Wertebereich eines Attributes und bezüglich der Unabhängigkeit
zwischen den Werten verschiedener Attribute getroffen.
Um zu einer zuverlässigen Abschätzung der Zugriffskosten cost(P) eines Ausführungsplanes
P zu kommen, müssen diejenigen Ressourcen in den Kostenfunktionen
berücksichtigt werden, welche die Grundlage der Anfrageausführung darstellen.
Hierzu gehört der externe Speicherbedarf, die Anzahl der Disk-I/O-Zugriffe,
der im Systembuffer benötigte Speicherplatz, sowie die notwendige CPU-Zeit zur
Ausführung eines spezifischen Ausführungsplanes.
Deshalb müssen sinnvolle Kostenmodelle sowohl die CPU-Kosten als auch die
I/O-Kosten gleichzeitig betrachten. Dieser Sachverhalt wird nicht nur durch alle
Kostenmodelle in realisierten Datenbankmanagement-Systemen bestärkt, sondern
ist in der Theorie auch fester Bestandteil aller Untersuchungen. Siehe dazu
insbesondere [51].
Vor einem Jahrzehnt fiel der größte Berechnungsaufwand im Zugriffs- und Speichersystem
an. Dazu wurde dieser Wert für vereinfachte Kostenmodelle als Grundlage
der Kostenberechnung benutzt. Natürlich wurde dabei ein Fehler in Kauf genommen,
der sich abhängig von der CPU-Belastung vergrößerte oder relativierte.
Heutige Systeme besitzen immer größer werdende Caches (viele I/O-Zugriffe werden
vermieden), welche zusätzlich berücksichtigt werden müssen, da dadurch die
CPU-Kosten einen höheren Anteil an den Gesamtkosten erlangen.
Inzwischen sind verschiedene Verfeinerungen vorgenommen worden, die eine bessere
Kosteneinschätzung ermöglichen sollen. Verschiedene neue Ansätze lassen
sich bei Mitschang [36] nachlesen. Dabei versucht man zum Beispiel zusätzliche
Faktoren in das Kostenmodell aufzunehmen wie z.B. die Zerlegung der I/O-
Kosten in Input- und separate Output Kosten.
Bei dem eigens für diese Diplomarbeit entwickelten Kostenmodell werden basierend
auf der Doktorarbeit von Utesch (siehe dazu [54]) die I/O-Kosten ausschließlich
als Input-Kosten gesehen, da die gesamten I/O-Kosten dieselbe Größenordnung
haben, wie die Input-Kosten allein. Dies ist der Fall, da nach jeder Operation
das Zwischenergebnis in den Speicher geschrieben wird und danach wieder für die
nächste Operation gelesen werden muß. Diese beiden Schritte benötigen in etwa
denselben Aufwand.
Zusätzlich dazu bietet dieses Kostenmodell auch eine leicht verständliche und
somit einfache Erweiterungsmöglichkeit für spätere Verfeinerungen.

44 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
Seien
R, R1, R2, . . . Relationen
p = AΘB Prädikat, Θ ∈ {, ≥, =, �=}
A, B Attribute oder Konstanten,
|R| Kardinalität von R in Tupeln,
page(R) Kardinalität von R in Seiten (Blöcken),
n(A, R) Anzahl der verschiedenen Werte des Attributes A in R,
Index(R) Index einer Relation R,
IndexA(R) Index einer Relation R auf dem Attribut A,
|Index(R)| Tiefe des Indexbaumes von Index(R),
page(Index(R)) Kardinalität von Index(R) in Seiten (Blöcken),
max(A), min(A) Maximum bzw. Minimum der Werte des Attributes A,
dom(A) Wertebereich des Attributes A,
q(σp(R)) Selektivität der Selektion σp(R) bezüglich des Prädikats p,
q(R1 ✶p R2) Selektivität des Verbundes R1 ✶p R2
bezüglich des Prädikats p.
Definition 4.2.1 Die Abschätzung der Zugriffskosten für eine Relation R lautet:
Zugriffskosten(R) = (I/O-Kosten) + W · (CPU-Kosten)
wobei W : Gewichtung von CPU- zu I/O-Kosten; abhängig von Systemkonfiguration
(Hard- und Software).
Um die beiden stark unterschiedlichen Kostenanteile zu den gesamten Zugriffskosten
zusammenfassen zu können, werden die CPU-Kosten bezüglich der I/O-
Kosten normiert. Dies erfolgt durch den Proportionalitätsfaktor W , der das durchschnittliche
Verhältnis des Aufwandes für einen Aufruf des Zugriffssystems zu
einem Seitenzugriff auf den externen Speicher angibt.
Durch Festlegung des Proportionalitätsfaktors W kann man somit das Kostenmodell
an eine vorhandene Rechnerkonfiguration anpassen, um sinnvolle Aussagen
zu erreichen.
Natürlich gibt es dabei zwei Extremfälle, die in diesem Modell berücksichtigt
werden können [51]:
(a) CPU-Constraints
Ist die CPU der Engpaß des Systems, sind natürlich I/O-Zugriffe zu bevorzugen.
Somit werden rechenintensive Ausführungspläne bei der Optimierung
benachteiligt. Für eine I/O-Operation werden lediglich die hierzu
auszuführenden Instruktionen angesetzt. Dabei wird angenommen, daß die
Zugriffszeit voll überlappend zur weiteren Verarbeitung ausgenutzt werden
kann.

4.3. SELEKTIVITÄT VON PRÄDIKATEN 45
W =
#Instruktionen pro CPU-Operation
#Instruktionen pro I/O-Operation
In der Praxis zeigt sich, daß für W folgendes gilt: 0, 1 ≤ W ≤ 0, 4.
(b) I/O-Constraints
Normalerweise sind es die I/O-Kosten, die Zugriffe, die am meisten Zeit
benötigen. Deshalb sollte man rechenintensive Ausführungspläne bevorzugen.
Somit wird in diesem Fall zusätzlich zu den oben genannten Anteilen,
die volle Zugriffszeit für eine I/O-Operation angerechnet, bei dem sich die
MIPS-Rate des verwendeten Rechners für eine durchschnittliche Zugriffszeit
bestimmen läßt.
W =
# Instruktionen pro CPU-Operation
(# Instruktionen pro I/O-Operation) + (Zugriffszeit · MIPS-Rate)
Erfahrungswerte zeigen, daß man mit einem W < 0, 01 den besten Plan
generieren kann.
Folgendes Beispiel verdeutlicht wie einfach die Berechnung des Proportionalitätsfaktors
W ist:
1000 Instruktionen pro CPU-Operation
2500 Instruktionen pro I/O-Operation
30ms Durchschnittliche Zugriffszeit
10 7 MIPS-Rate (Instruktionen pro Sekunde)
Somit ergibt sich bei einem vorliegendem CPU-Constraint:
Schließlich für einen I/O-Constraint:
W =
W = 1000 1
=
2500 4
1000
(2500 + 30 · 10 −3 · 10 7 )
= 0, 4
= 2
605
4.3 Selektivität von Prädikaten
≈ 0, 0033
Von fundamentaler Bedeutung für die Kostenberechnung ist die Frage, wieviele
Tupel sich bei Auswertung einer Bedingung qualifizieren, da erst dadurch eine
Abschätzung der Größe von Zwischenergebnissen ermöglicht wird. Das führt zur
Einführung des Begriffes Selektivität (Auswahlschärfe), also dem Anteil der sich
qualifizierenden Tupel.

46 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
Definition 4.3.1
(a) Für eine Selektionsbedingung p auf einer Relation R sei die Selektivität
q(p) definiert als das Verhältnis der Tupel, die diese Bedingung erfüllen zu
den gesamten Tupeln der Relation.
(b) Für eine Joinbedingung p der beiden Relationen R1 und R2 sei die Selektivität
q(p) definiert als das Verhältnis der Tupel, die diese Joinbedingung
erfüllen zu den Tupeln des Kartesischen Produktes der beiden Relationen.
Für den Fall, daß A ein gleichverteiltes Attribut von R und a eine Konstante im
Wertebereich von A ist, ergibt sich die Selektivität einer Bedingung AΘa als:
⎧
für Θ ≡ =
⎪⎨
q(AΘa) :=
⎪⎩
1
n(A,R)
max(A)−a
max(A)−min(A)
a−min(A)
max(A)−min(A)
1 − 1
n(A,R)
für Θ ≡ > oder Θ ≡ ≥
für Θ ≡ < oder Θ ≡ ≤
für Θ ≡ �=
Das heißt, ein Prädikat p = AΘa mit einer Selektivität q(AΘa) liefert, wenn
angewandt auf die zugehörige Relation R mit der Kardinalität |R|, ein Zwischenergebnis
der Größe q(AΘa) · |R|.
Darüberhinaus ist für viele Selektivitätsabschätzungen die Anzahl der verschiedenen
Werte eines Attributes einer Relation eine wichtige Größe. Deshalb muß
außer der Größe der Ergebnisrelation R einer Operation auch n(A, R) abgeschätzt
werden.
Unter der Annahme, daß die in den Prädikaten p, p1, p2 auftauchenden Attribute
gleichverteilt sind, ergeben sich folgende Selektivitätsabschätzungen, wobei
a, a1, . . . , an ∈ dom(A) paarweise verschiedene Konstanten sind (siehe Tabelle
4.1) 1 :
4.3.1 Selektivität von Projektion und Selektion
Da die Projektion πA gemäß ihrer Definition der Auswahl eines Attributes A
entspricht, ist somit die Anzahl der verschiedenen Werte n(A, R) in der Relation
R gleich der Kardinalität von πA(R).
1 Bei einer Unteranfrage gilt die genannte Formel nur dann, wenn die A-Werte des Ergebnisses
in dom(A) liegen.

4.3. SELEKTIVITÄT VON PRÄDIKATEN 47
Prädikat p Abschätzung Standardwert
A = a
A {>, ≥} a
A { a1) ∧ (A < a2)
A ∈ {a1, . . . , an}
A ∈ (Unteranfrage) 1
1
10
1
3
1
3
q(p1) + q(p2)
−q(p1) · q(p2) -
a2−a1
max(A)−min(A)
n
n(A,R)
|Unteranfrage|
n(A,R)
Tabelle 4.1: Selektivitätsabschätzung für Prädikate
n(A, R) = |πA(R)|
Die Selektivität einer Selektion der Form σp(R) ist definiert durch:
q(σp(R)) := |σp(R)|
|R|
Sie gibt das Verhältnis der Tupelanzahl von Resultat und Original an. Daraus
folgt dann auch:
0 ≤ q(σp(R)) ≤ 1
Das heißt, das Ergebnis einer Selektion enthält maximal soviel Tupel wie das
Original. Allgemein gilt:
q(σp(R)) = q(p)
Man geht nun davon aus, daß im Mittel die Selektivität wesentlich kleiner als
1 ist, so daß die Kosten einer Anfrageauswertung (bemessen an der Anzahl zu
1
4
1
2
1
2

48 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
bewegender Tupel) desto geringer ist, je früher die Selektion angewandt wird.
Falls das Attribut, nach dem selektiert wird, ein Schlüssel ist oder die Werte des
Attributes gleichverteilt sind, ergeben sich folgende Werte für die Selektivität:
Die Selektivität der Operation σR.A=a(R), also des Vergleiches des Attributs A
, falls A ein Schlüssel ist.
aller Tupel von R mit der Konstanten a, beträgt 1
|R|
Die Selektivität der Operation σ(R.A=a)(R) ist bei einer Gleichverteilung der Werte
1
von R.A gleich , da in diesem Fall
n(A,R)
q(p) = q(R.A = a) =
1
n(A, R)
ist. Dabei ist der obige Fall ein Spezialfall hiervon, da für ein Schlüsselattribut A
einer Relation R n(A, R) = |R| gilt.
Wird eine Selektion durchgeführt, auf die diese Spezialfälle nicht zutreffen, müssen
andere Methoden angewandt werden, um trotzdem Werte für die Selektivität zu
erhalten. Mit diesen Methoden beschäftigt sich der Abschnitt 4.4.
Zur Berechnung der Selektivität benötigt man Abschätzungen für n(A, R1) für
jedes Attribut A, wobei R1 = σp(R2) sei. Von der Ausgangsrelation R2 sei ihre
Größe mit n bezeichnet und m = n(A, R2) bekannt. Um nun eine Abschätzung
für n(A, R1) angeben zu können, müssen zwei Fälle unterschieden werden: Der
Fall, daß das Attribut A nicht in der Bedingung p auftritt und der, bei dem A in
der Bedingung p vorkommt.
• Für den ersten Fall sei r die geschätzte Kardinalität von R1. Dabei läßt sich
das Problem, bei angenommener Gleichverteilung und Unabhängigkeit der
Attribute, auf die folgende kombinatorische Fragestellung zurückführen:
Gegeben sei eine Urne mit n Kugeln in m verschiedenen Farben. Wieviele
verschiedenfarbige Kugeln erhält man, wenn man r Kugeln zufällig ohne
Zurücklegen aus der Urne zieht?
Eine Abschätzung für diese Anzahl ergibt sich nach Ceri [8] zu:
⎧
r
⎪⎨
falls r <
n(A, R1) =
m
2
≤ r < 2 · m
r+m
m falls 3 2
⎪⎩
m falls r ≥ 2 · m
• Für den Fall, daß A in der Selektionsbedingung p auftritt, erhält man
abhängig von der Art des Auftretens von A verschiedene Formeln. Für den
Spezialfall p = (A = a) mit konstantem a bekommen wir n(A, R1) = 1.

4.3. SELEKTIVITÄT VON PRÄDIKATEN 49
Betrachtet man eine Projektion R1 = πl(R2), dann gilt n(A, R1) = n(A, R2) für
alle Attribute A der Ergebnisrelation.
4.3.2 Selektivität eines Joins
Wir wollen jetzt die oben beschriebenen Parameter verwenden, um eine Abschätzung
des natürlichen Verbundes bzw. eine Abschätzung für die Größe des Ergebnisses
einer Equijoin-Operation berechnen zu können.
• Ist sch(R1) ∩ sch(R2) = ∅, so entartet der natürliche Verbund zu einem
Kartesischen Produkt, d.h. es gilt |R1 ✶ R2| = |R1| · |R2|.
• Falls sch(R1) ∩ sch(R2) einen Schlüssel etwa für R1 enthält, so existiert
zu jedem Tupel aus R2 höchstens ein Verbund-Partner in R1. Hieraus folgt
|R1 ✶ R2| ≤ |R2|.
• Sei sch(R1) ∩ sch(R2) = {A} und a ∈ dom(R1.A). Dann gibt es bei Gleich-
|R2|
verteilung ca. n(A,R2) Tupel in R2 mit dem A-Wert a; das gleiche gilt für
alle weiteren auftretenden R1.A-Werte. Hieraus folgt:
|R1 ✶ R2| ≤ n(A, R1) · |R2|
n(A, R2)
≤ |R1| · |R2|
n(A, R2)
Da der Join kommutativ ist, spielen die beiden Operanden dieselbe Rolle;
von daher gilt die Formel auch mit vertauschten Relationen:
|R1 ✶ R2| ≤ n(A, R2) · |R1|
n(A, R1)
≤ |R1| · |R2|
n(A, R1)
Damit gilt insgesamt
�
n(A, R2) · |R1|
|R1 ✶ R2| ≤ min
,
n(A, R1)
n(A, R1)
�
· |R2|
n(A, R2)
• Sei nun sch(R1) ∩ sch(R2) = {A1, . . . , As} mit s ≥ 2 und gleichverteilten
und unabhängigen Attributen Ai. Dann erhält man das Ergebnis des
Equijoins wie folgt:
R1 ✶ R2 = σ (�s
i=2 A(1)
i =A(2)
i ) R1 ✶R1.A1=R2.A1 R2,
dabei sei A (j)
i , i = 2, . . . , s, j = 1, 2, das Attibut der Relation definiert als
R := R1 ✶R1.A1=R2.A1 R2, welches aus Rj.Ai entstanden ist. Die Größe des
Zwischenergebnisses R läßt sich nach obigen Überlegungen mit
�
n(A1, R2) · |R1|
m1 := min
,
n(A1, R1)
n(A1,
�
R1) · |R2|
n(A1, R2)

50 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
abschätzen. Die Größe des Endergebnisses läßt sich dann mit
�
s�
m1 · q A (1)
�
i = A (2)
i ) = m1
s�
· q(A (1)
i
i=2
i=2
abschätzen, wobei qi die Selektivität von A (1)
i
= A(2) i ) =: m1
= A(2)
i
Da die Attribute Ai unabhängig sind, ergibt sich eine Abschätzung für
q2 wie folgt. Es gibt in R maximal n(A2, Ri) verschiedene A (i)
2 -Werte, al-
so n(A (i)
2 , R) ≤ n(A2, Ri). Das Ergbnis der Selektion σ (1)
A 2 =A(2)
2
sei.
s�
i=2
qi
wird de-
sto größer, je größer der Durchschnitt dom(A (1)
2 ) ∩ dom(A (2)
2 ) ist. Sei also
o.B.d.A. dom(A (1)
2 ) ⊂ dom(A (2)
2 ), insbesondere also
min(n(A (1)
2 , R), n(A (2)
2 , R)) = n(A (1)
2 , R).
Die Wahrscheinlichkeit dafür, daß ein Tupel r in R die Bedingung A (1)
2 =
A (2)
2 erfüllt, ergibt sich zu
n(A (1)
2 , R)
n(A (1)
2 , R) · n(A (2)
2 , R)
min(n(A(1) 2 , R), n(A
= (2)
2 , R))
.
n(A (1)
2 , R) · n(A (2)
2 , R)
Betrachtet man nämlich das Paar (r.A (1)
2 , r.A (2)
2 ) =: (a (1)
2 , a (2)
2 ), so gibt es
n(A (1)
2 , R) · n(A (2)
2 , R) verschiedene Paare dieser Form. Ein solches Paar
erfüllt die Selektionsbedingung, falls a (1)
2 = a (2)
2 gilt, die Anzahl dieser Tupel
ist min(n(A (1)
2 , R), n(A (2)
2 , R)) = n(A (1)
2 , R).
Die Wahrscheinlichkeit berechnet sich dann als der Quotient der Anzahl
der sich qualifizierenden Tupel und der Anzahl der gesamten Tupel, wegen
der Gleichverteilungs- und Unabhängigkeitsannahme ist dieser genau der
obengenannte Quotient, der sich noch wie folgt vereinfachen läßt.
q2 = min(n(A(1) 2 , R), n(A (2)
2 , R))
n(A (1)
2 , R) · n(A (2)
2 , R) =
1
max(n(A (1)
2 , R), n(A (2)
2 , R)) .
Induktiv kann man nun folgern, daß diese Formel auch für die anderen
Attribute Ai gilt, d.h.
qi = min(n(A(1)
i , R), n(A (2)
i , R))
1
max(n(A (1)
i , R), n(A (2)
i , R))
n(A (1)
i , R) · n(A (2)
i , R) =
∼ =
1
max(n(Ai, R1), n(Ai, R2)) ,

4.3. SELEKTIVITÄT VON PRÄDIKATEN 51
da die im Fall i = 2 benutzten Abschätzungen auch in jedem weiteren
Schritt gültig sind. Insgesamt gilt also
s�
|R1 ✶ R2| = m1 qi ∼ =
�
n(A1, R2) · |R1|
min
,
n(A1, R1)
n(A1,
�
R1) · |R2|
n(A1, R2)
i=2
·
s�
i=2
1
max(n(Ai, R1), n(Ai, R2)) ,
wobei das Attribut A1 frei gewählt werden kann, d.h. man könnte hier noch
das Minimum über alle Permutationen der Menge {A1, . . . , As} bilden.
Darüberhinaus wird die Selektivität, d. h. die Größe des Ergebnisses relativ zur
Kardinalität des Kreuzproduktes, angegeben. Im allgemeinen gilt q(R1 ✶p R2) =
q(p), also folgt:
q(R1 ✶ R2) = |R1 ✶ R2|
|R1 × R2| = |R1 ✶ R2|
|R1| · |R2|
mit
0 ≤ q(R1 ✶ R2) ≤ 1.
Das heißt in den obigen vier Fällen gilt:
• sch(R1) ∩ sch(R2) = ∅:
q(R1 ✶ R2) = |R1| · |R2|
|R1| · |R2|
= 1
• sch(R1) ∩ sch(R2) enthält den Schlüssel A der Relation R1:
• sch(R1) ∩ sch(R2) = {A}:
q(R1 ✶ R2) ≤
q(R1 ✶ R2) ≤
|R2|
|R1| · |R2|
= 1
|R1|
�
n(A,R2)·|R1|
min
, n(A,R1) n(A,R1)·|R2|
�
n(A,R2)
|R1| · |R2|
�
n(A, R2)
min
n(A, R1) · |R2| ,
�
n(A, R1)
n(A, R2) · |R1|
• sch(R1) ∩ sch(R2) = {A1, . . . , As}:
�
n(A1,R2)·|R1|
min
, n(A1,R1)
q(R1 ✶ R2) ≤
n(A1,R1)·|R2|
�
· n(A1,R2)
�s i=2
|R1| · |R2|
�
n(A,R2)
min n(A,R1)·|R2| ,
�
n(A,R1)
n(A,R2)·|R1|
�s i=2 max(n(Ai, R1), n(Ai, R2))
=
1
max(n(Ai,R1),n(Ai,R2))
=

52 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
In dem zweiten Fall, daß bei einem Equijoin (R1 ✶(R1.A=R2.A) R2) das Attribut
A Schlüsseleigenschaften besitzt, kann die Größe des Ergebnisses mit |R2| und
1
damit die Selektivität mit abgeschätzt werden. Denn jedes Tupel aus R2
|R1|
findet nur maximal einen Joinpartner. Ist A zusätzlich Fremdschlüssel für R2, so
ist die Selektivität q(R1 ✶ R2) = 1
|R1| .
Setzt man voraus, daß die statistischen Werte eines DBMS immer auf dem aktuellen
Stand gehalten werden, kann man im Prinzip die Reihenfolge eines sinnvollen
Verbundes ermitteln, da es wegen kleinerer Zwischenergebnisse für R1 ✶ R2 ✶ R3
am besten wäre, wenn man (R1 ✶ R2) ✶ R3 berechnet, wenn R1 ≤ R2 ≤ R3 ist.
Auch beim Join benötigen wir eine Abschätzung für die Anzahl der verschiedenen
Attribute in den gegebenen Relationen. Dafür wird folgender Ansatz genutzt:
Es sei R1 = R2 ✶p R3, von den Ausgangsrelationen R2, R3 seien die Größen
mit n2, n3 bezeichnet und mi = n(A, Ri) bekannt. Um nun eine Abschätzung für
n(A, R1) angeben zu können, müssen zwei Fälle unterschieden werden, der Fall,
daß das Attribut A nicht in der Bedingung p auftritt und der, bei dem A in der
Bedingung p vorkommt.
• Für den ersten Fall sei r die geschätzte Kardinalität von R1 und o.B.d.A.
A ein Attribut von R2. Dann gilt genau wie bei der Selektion:
⎧
r
⎪⎨
falls r <
n(A, R1) =
m2
2
falls ≤ r < 2 · m2
r+m2
3
m2
2
⎪⎩
m2 falls r ≥ 2 · m2
• Für den Fall, daß A in der Joinbedingung p auftritt, erhält man abhängig
von der Art des Auftretens von A verschiedene Formeln. Für den Spezialfall
p = (R2.A = R3.A) bekommen wir n(A, R1) ≤ min(n(A, R2), n(A, R3)).
Ebenso kann man für einen Equijoin mit sch(R2)∩sch(R3) = {A1, . . . , As},
d.h. p = � s
i=1 R2.Ai = R3.Ai, für jedes der Attribute Ai die Abschätzung
n(A, R1) ≤ min(n(Ai, R2), n(Ai, R3))
nutzen. Im allgemeinen Fall kann man zumindestens noch die folgende
Abschätzung angeben:
n(A, R1) ≤ n(A, R2) + n(A, R3)

4.4. SELEKTIVITÄTSABSCHÄTZUNGEN 53
4.4 Selektivitätsabschätzungen
In den obigen Abschnitten wurden nur in Spezialfällen konkrete Werte für die
Selektivität angegeben. Außerhalb dieser Spezialfälle, insbesondere bei anderen
Verteilungen als der Gleichverteilung, muß es aber auch möglich sein, zumindest
Abschätzungen für die Selektivität anzugeben. Deshalb werden in diesem Abschnitt
weitere Verfahren vorgestellt, mit denen die Anzahl der Tupel in einem
Zwischenergebnis abgeschätzt werden kann, nämlich:
(a) parametrisierte Verteilungen,
(b) Histogramme und
(c) Stichproben.
Diese Verfahren sind natürlich auch in den bereits genannten Spezialfällen anwendbar
und können die dortigen Abschätzungen verfeinern.
4.4.1 Parametrisierte Verteilung
Bei dieser Methode versucht man, zu der vorhandenen Werteverteilung die Parameter
einer Verteilungsfunktion so zu bestimmen, daß diese die Verteilung gut
annähert.
Dabei kann nicht immer die Normalverteilung die tatsächliche Verteilung annähern.
Aber dafür ist eine Abschätzung der Selektivität sehr einfach zu berechnen
(die Approximationsfunktion liefert die Anzahl der Tupel im qualifizierten Bereich.).
0.4
0.2
0
Abbildung 4.2: Normalverteilter Stichprobenraum
x

54 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
Suboptimal ist dabei nur, daß realistische Verteilungsfunktionen oft nicht gut
mit parametrischen Funktionen angenähert werden können. Vor allem bei mehrdimensionalen
Anfragen (d.h. bei Selektionen, die sich auf mehrere Attribute
beziehen) ist dies sehr schwierig.
Bei den meisten Verfahren wird deshalb auf komplexere Funktionen als die Standard-Normalverteilung
zurückgegriffen. Schließlich muß auch eine sinnvolle und
effiziente Möglichkeit der Parameterbestimmung gefunden werden, dafür leistet
man sich Stichproben, die aber sehr kostenintensiv sein können.
4.4.2 Histogramme
Bei dieser Methode wird der Wertebereich der betreffenden Attribute in Intervalle
unterteilt und alle Werte gezählt, die in ein bestimmtes Intervall fallen. Auf diese
Weise ist eine sehr viel flexiblere Annäherung der Verteilung möglich.
Die einfachste Art von Histogrammen unterteilt den Wertebereich in äquidistante
Teilbereiche. Das hat den Nachteil, daß vergleichsweise selten vorkommende
Bereiche zu gut und dafür sehr häufig vorkommende zu ungenau abgeschätzt
werden.
Aus diesem Grund werden sogenannte Equi-Depth-Histogramme benutzt, die
den Wertebereich so in Abschnitte unterteilen, daß in jedem Abschnitt gleich
viele Werte liegen. Somit sind Abschnitte mit wenigen Werten sehr grob, stark
frequentierte Bereiche feiner unterteilt. Mit dieser Methode wird eine genauere
Annäherung möglich. Nachteilig ist dabei der höhere Verwaltungsaufwand, da
Equi-Depth-Histogramme nur mit hohen Kosten an Veränderungen der Datenbasis
angepaßt werden können.
0.4
0.2
0
Abbildung 4.3: Equi-Depth-Histogramm
x

4.5. FAZIT DER SELEKTIVITÄTSABSCHÄTZUNGEN 55
4.4.3 Stichproben
Dieses Verfahren ist recht leicht zu realisieren. Es wird einfach eine zufällige
Menge von Tupeln einer Relation gezogen und deren Verteilung als repräsentativ
angenommen.
Aber auch diese Methode beinhaltet hohe Kosten im Bereich der Zugriffe. Es
ist somit sehr wichtig, daß nicht mehr Zeit durch das Ziehen der Stichproben
aufgewendet wird, als für eine beliebige Abarbeitung der Anfrage. Daraus folgt,
daß auch dieses Verfahren adaptiv agieren muß.
4.4.4 Zusammenfassung
Schließlich fassen wir nochmal zusammen:
Parametrisierte Histogramme Stichproben
Verteilung
Funktion Werteverteilung diskrete Einteilung, zufällige
über Funktion äquidistant, equi-depth Auswahl
Vorteile einfach sehr genaue einfach
Annäherung
Nachteile ungenau Verwaltungsaufwand Entnahme der
hoch Stichproben teuer
Tabelle 4.2: Zusammenfassung der Verfahren
4.5 Fazit der Selektivitätsabschätzungen
Basierend auf den Selektivitätsabschätzungen kann jetzt die Kardinalität einer
Anfrage P bzw. die Kardinalität des Zwischenergebnisses eines Operatorgraphen
(Anfragebaum) abgeschätzt werden (zur Vereinfachung sollen im folgenden
q(σpj (R)) und q(R1 ✶pj R2) mit q(pj) bezeichnet werden).
Es sei folgende SQL-Anfrage P beispielsweise gegeben:

56 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
Select ∗
From R1, R2, . . . , Rn
Where p1 ∧ p2 ∧ . . . ∧ pm
Dabei seien die Ri (i = 1, . . . , n) Relationen und die pj (j = 1, . . . , m) entweder
relationenlokale Selektionsprädikate oder relationenübergreifende Joinprädikate.
Die Größe der Ergebnisrelation der Anfrage P erlangt man durch folgende Formel:
|P| =
n�
|Ri| ·
i=1
m�
q(pj)
Diese ergibt sich aus der Überlegung, daß die Anfrage wie folgt bearbeitet werden
könnte. (Selbstverständlich kann dieser Plan nicht der optimale sein, zur
Berechnung der Größe der Ergebnisrelation ist er aber ausreichend.)
Zunächst wird das Kartesische Produkt der n Relationen Ri gebildet. Dieses hat
die Kardinalität �n i=1 |Ri|. Daraufhin werden die Joinbedingungen in Selektionsbedingungen
auf dem Produkt umgewandelt. Es bleiben also nur Selektionen, die
auf das gesamte Produkt angewendet werden müssen. Dadurch wird die Kardinalität
des Kartesischen Produktes um den Faktor �m j=1 q(pj) verringert, da die
Bedingungen pj mit Undzeichen verknüpft sind und hierfür die Selektivität induktiv
(siehe Tabelle 4.1) das Produkt der einzelnen Selektivitäten ist. Es ergibt
sich die oben genannte Formel.
Hier noch ein paar kleine Beispiele:
j=1
Ausdruck |Ausdruck|
R1 ✶p R2 |R1| · |R2| · q(R1 ✶p R2)
σ(R1) |R1| · q(σ(R1))
Abbildung 4.4: Beispiel für die Kardinalitätsabschätzung
Im allgemeinen Fall müssen kompliziertere Berechnungen vorgenommen werden,
da sich die Kardinalitäten rekursiv aus den voherigen Knoten ergeben. Leider
kann man dafür keine geschlossene Formel angeben. Damit kann man die Kardinalität
des Ergebnisses eines Anfragebaumes aus den oben bestimmten Abschätzungen
wie folgt berechnen:
Ausgehend von den Blättern des Baumes muß rekursiv in jedem inneren Knoten
die Kardinalität des von diesem Knoten bestimmten Zwischenergebnisses, welches
mit R bezeichnet wird, ermittelt werden. Für die Operation in dem betrachteten

4.6. KOSTENFUNKTION 57
Knoten kann die Selektivität nach den oben entwickelten Formeln abgeschätzt
werden. Die Kardinalität von R ergibt sich daraus und aus den Kardinalitäten der
von den Kindern bestimmten Zwischenergebnisse (bzw. der Ausgangsrelationen),
also den Operanden der Operation.
Diese sind zuvor bereits abgeschätzt worden, ebenso wie die für die Selektivitätsabschätzungen
benötigten Zusatzinformationen wie z.B. die Anzahl der verschiedenen
auftretenden Atributwerte (n(·, ·)) oder Schlüsseleigenschaften eines bestimmten
Attributes. Aus dem vorherigen Abschnitt sind ebenfalls Formeln zur
Approximation der Werte n(·, ·) bekannt. Diese werden für die Relation R berechnet,
so daß diese Informationen für den Elternknoten zur Verfügung gestellt
werden können.
4.6 Kostenfunktion
4.6.1 Kostenfunktion Scan (Selektion, Projektion)
Faßt man die Schreibweise der Selektion und der Projektion als Scanp(R) zusammen,
muß man bei der Projektion als Bedingung true wählen. Scan-Kosten bzw.
Selektions- und Projektionskosten sind für eine Relation R : 2
Scan(R) I/O − Kosten (Scan(R)) CPU − Kosten (Scan(R))
Scan Rel
p (R) page(R) |R|
Scan Index
p (R) page(Index(R)) + min(page(R), q(σp(R))·
(q(σp(R)) · page(R) · |Index(R)|) (|R| + |Index(R)|)
Tabelle 4.3: Scankosten
Die Kostenfunktion für einen relationalen Scan ist leicht nachvollziehbar, wenn
man weiß, daß page(R) die Anzahl von Seiten darstellt, die man für das Abspeichern
der Relation R benötigt. Die dazugehörenden CPU-Kosten bestehen aus
der Kardinalität der Relation R, da jedes Tupel genau einmal betrachtet werden
muß.
Bei einem indexbasierten Scan bestehen die I/O-Kosten aus den benötigten Seitenzugriffen
zum Laden des Index in den Hauptspeicher page(Index(R)). Hin-
2 Mit |Index(R)| wird die Höhe des Indexbaumes bezeichnet.

58 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
zugerechnet werden die Kosten des Ladens der benötigten Tupel. Nun sind zwei
Fälle zu unterscheiden, es könnte entweder günstiger sein, gleich alle Seiten der
Relation R zu laden, oder aber nur diejenigen, in denen sich tatsächlich die qualifizierenden
Tupel befinden. Im ersten Fall ergeben sich die Kosten zu page(R).
Im zweiten Fall hingegen ergibt sich folgende Rechnung. Es qualifizieren sich
q(σp(R))·|R| Tupel, für jedes dieser Tupel entstehen Indexkosten von |Index(R)|.
Auf jeder Seite werden durchschnittlich
|R|
page(R)
Tupel abgespeichert, so daß zum
Laden aller Seiten, die sich qualifizierende Tupel enthalten, Kosten in Höhe von
ca.
q(σp(R)) · |R| · |Index(R)|
|R|
page(R)
= q(σp(R)) · page(R) · |Index(R)|
anfallen. Die CPU-Kosten ergeben sich daraus, daß man alle Tupel, die die Bedingung
p erfüllen, bearbeiten muß, das sind also Kosten von q(σp(R))·|R|. Dazu
werden die Kosten für die Indexzugriffe in Höhe von q(σp(R))·|Index(R)| addiert.
4.6.2 Kostenfunktion Sortierung und Indexerzeugung
Bei Merge-Join bzw. Hash-Join fallen unter Umständen zusätzliche Sortierungs-
[Sort(R)] und Hash-Operationen [Hash(R)] an, die bei einer Berechnung der Zugriffskosten
mitberücksichtigt werden müssen. Darüberhinaus müssen auch Indexerzeugungen
bewertet werden. Dafür kann man entweder Hash-Funktionen
[Hash(R)] oder den Aufbau eines Indexbaumes [Tree (R)] nutzen. In diesem Abschnitt
werden die Kosten für diese Operationen angegeben. Sort-, Hash- und
Tree-Kosten einer Relation R ergeben sich wie folgt: 3
I/O-Kosten (·) CPU-Kosten (·)
Sort(R) page(R) · log2(page(R)) |R| · log2(|R|)
Hash(R)
page(R)
k
|R|
Tree(R) page(R) · log2(page(R)) |R| · log2(|R|)
Tabelle 4.4: Sort- Hash- und Tree-Kosten
Die Sortierungskosten entsprechen den allgemein bekannten Laufzeiten von Sortieralgorithmen
von n · log(n). Dagegen werden beim Hashing die eingelesenen
3 k entspricht der Buffergröße des vorhandenen Systems. Bei den folgenden Beispielen wird
k mit 55 festgelegt.

4.6. KOSTENFUNKTION 59
Seiten der Relation R in k Buckets gelegt, um danach schnell per Hashfunktion
darauf zugreifen zu können (siehe Kapitel 3.3.4).
4.6.3 Kostenfunktion Join
Die Joinkosten entsprechen den Zugriffsplänen der einzelnen Iteratoren für die
verschiedenen Joinoperationen. Beim NestedLoop-Join wird nach dem einmaligen
Laden der ersten Relation R1, so oft R2 eingelesen, wie R1 Tupel besitzt.
Join-Kosten für Relationen R1 ✶ R2: 4
R1 ✶p R2 I/O − Kosten (·) CPU − Kosten (·)
NestedLoop-Join 4 Scan Rel
p (R1)+ |R1| + |R1| · |R2|
|R1|·Scan Rel
p (R2)
Merge-Join Scan Rel
p (R1)+ q(R1 ✶p R2)·
(R1 & R2 sortiert) Scan Rel
p (R2) (|R1| + |R2|)
Hash-Join Scan Rel
p (R1)+ q(R1 ✶p R2)·
(R1 & R2 gehashed) Scan Rel
p (R2) (|R1| · |R2|)
Index-Join 4 Scan Rel
p (R1)+ q(R1 ✶p R2)·
(Index auf R2) Scan Index
p (R2) (|R1| + |R2|)
Index-Index-Join 4 Scan Index
p (R1)+ q(R1 ✶p R2)·
(Index auf R1, R2) Scan Index
p (R2) (|R1| + |R2|)
Tabelle 4.5: Join-Kosten
4 Da die Kostenfunktionen in der Literatur nur teilweise zu finden sind, wurde an gegebener
Stelle eine vom Autor selbst entwickelte Kostenfunktion hinzugefügt.

60 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
Beim Merge-Join und den Varianten des Index-Joins sind die CPU-Kosten gleich,
da sich hier die gesamten qualifizierten Tupel wiederfinden. Die I/O-Kosten entsprechen
wieder den Zugriffsmethoden der einzelnen Iteratoren. Beim Index-Join
wird zum Beispiel der Zugriff auf die Relation R1 mit einem Index-Scan durchgeführt.
Nicht zu vergessen ist der Hash-Join, dessen Hash-Kosten für die einzelnen Relationen
R1, R2 noch zu den Standardkosten (I/O-Kosten bzw. CPU-Kosten) addiert
werden müssen.
4.7 Kosteneinsparungen beim Pipelining
Da beim Pipelining keine Zwischenspeicherung der einzelnen Tupel stattfindet,
fallen einige der I/O-Kosten weg. Betrachtet man das Pipelining 〈O1◦ 1 · · ·◦ l−1 Ol〉
der Operationen O1, . . . , Ol, wobei ◦ i jeweils für eines der Symbole ◦, ◦1, ◦2 stehe,
so erhält man die Kosten des Pipelinings wie folgt:
Die Operation Ol, also die zuerst auszuführende Operation, hat die gleichen Kosten
wie in einem Plan ohne Pipelining. Sei nun Oi eine der anderen Operation,
also 1 ≤ i ≤ l − 1. Nun sind drei Fälle zu unterscheiden,
(a) Oi ist eine einstellige Operation, arbeitet also auf einer Relation, dann ist
◦ i = ◦,
(b) Oi ist eine zweistellige Operation, arbeitet also auf zwei Relationen, und
das Pipelining ist auf dem ersten Operanden, dann ist ◦ i = ◦1 oder
(c) Oi ist eine zweistellige Operation, arbeitet also auf zwei Relationen, und
das Pipelining ist auf dem zweiten Operanden, dann ist ◦ i = ◦2.
Im ersten Fall ergibt sich, daß für die Operation Oi keine I/O-Kosten anfallen,
da die gesamten Tupel direkt weiterverarbeitet werden. Im zweiten Fall werden
die I/O-Kosten um den Anteil der ersten Relation reduziert, d.h. die I/O-Kosten
entsprechen denen, die für den Zugriff auf die zweite Relation anfallen.
Die Kosten beim dritten Fall ergeben sich analog, nur daß nun die Zugriffskosten
für die zweite Relation wegfallen. Dabei sei daran erinnert, daß bei unserem
Kostenmodell die I/O-Kosten nur die Input-Kosten beinhalten.
4.8 Beispiel zur Kostenberechnung
Zum Abschluß des Kapitels sollen noch ein paar einfache Beispiele den Ablauf
der Kostenberechnung verdeutlichen:

4.8. BEISPIEL ZUR KOSTENBERECHNUNG 61
Seien folgende Werte für eine Relation R gegeben (siehe Abbildung 4.6).
Metadaten Wert
page|R| 1000
|R| 10000
n(A, R) 50
|Index(R)| 4
page(Index(R)) 50
Tabelle 4.6: Metadaten für die Relation R
Zusätzlich dazu soll die statistische Annahme bezüglich der Gleichverteilung der
Werte über den Wertebereich eines Attributs und der Unabhängigkeit zwischen
den Werten verschiedener Attribute vorausgesetzt werden.
Desweiteren wird ein System eingesetzt, welches I/O-Constraint ist und somit
den Wert W = 0, 02 besitzt:
1) Bei der ersten Variante betrachten wir einen einfachen Relationen Scan:
σ Rel
p (R) mit p = Aθa. Hierbei gehen wir davon aus, daß alle Seiten der Datenbank
gelesen und jeweils alle auf den Seiten vorhandenen Tupel gefunden
werden müssen (siehe dazu 4.6.1):
I/O-Kosten CPU-Kosten Ergebnis
page(R) |R| page(R) + 0, 02 · |R|
1000 10000 (1000 + 0, 02 · 10000) = 1200
2) Bei der zweiten Variante existiert ein Index auf R über dem Selektionsattribut
p: σIndex p (R) mit p = Aθa. Wir können daher den Zugriff beschleunigen
(siehe dazu 4.6.1):
I/O-Kosten CPU-Kosten Ergebnis
page(Index(R)) + min(page(R), q(σp(R))· I/O + 0, 02· CPU
(q(σp(R)) · page(R) · |Index(R)|)) (|R| + |Index(R)|)
50 + min(1000, 1
1
50 · 1000 · 4) 50 · (10000 + 4) (130 + 0, 02 · 200) = 134
= 130 ≈ 200

62 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
Die Analyse der Zahlen zeigt das zu erwartende Ergebnis, nämlich daß für die
vorgegebene Relation R ein Indexzugriff immer schneller ist, als ein einfacher
Relationen-Scan.
Nach dieser einfachen Berechnung einer Kostenabschätzung, kommen wir jetzt
auf unser Standardbeispiel aus Kapitel 2.2 zurück. Wiederum nehmen wir für W
einen Wert von 0, 02 an.
4. Level ( ˆ R)
3. Level ( ˜ R)
2. Level (R)
1. Level ( ˜ R1) ✲
✲
✲
✲
π Rel
B,D
σ Rel
E=2
✶ Rel,Index
R1.C=R2.C
✪ ❡
✪ ❡
✪
✪
σ Index
A=c
Abbildung 4.5: physisch optimierter Anfragebaum
Dabei benutzen wir andere Ausgangsrelationen als zuvor, da die bisherigen zu
klein sind und deswegen keinen sinnvollen Anwendungsbereich für unsere Abschätzungen
darstellen. Zur Vereinfachung werden folgende Abkürzungen definiert:
�R1 := σA=c(R1)
R1
R2
R := ✶ Rel,Index
�R1.C=R2.C ( � R1, R2)
�R := σ Rel
E=2(R)
�R := π Rel
B,D( � R)
Für R1, R2 seien folgende Metadaten bekannt. Für R1 sei das Attribut A der
Schlüssel der Relation und für R2 sei das Attribut C der Schlüssel der Relation
(siehe Abbildung 4.7).
1.Level In diesem Level muß � R1 = σ Index
A=c (R1) berechnet werden (siehe dazu Kapitel
4.6.1).
Dabei wird zur Berechnung die Selektivität von σp(R1) benötigt, die man -
wie im Kapitel 4.3.1 erwähnt - aus der Kardinalität des Wertebereichs des
Attributes A bekommt:
q(σA=c(R1)) = | σA=c(R1) |
| R1 |
=
1
n(A, R1)
⇔ | � R1| = |σA=c(R1)| = q(σA=c(R1)) · |R1| = |R1|
n(A, R1)
10000
= = 1
10000

4.8. BEISPIEL ZUR KOSTENBERECHNUNG 63
Metadaten Wert
page|R1| 1000
|R1| 10000
n(A, R1) 10000
n(B, R1) 10
n(C, R1) 100
|IndexA(R1)| 4
page(IndexA(R1)) 50
Metadaten Wert
page|R2| 1000
|R2| 10000
n(C, R2) 10000
n(D, R2) 10
n(E, R2) 100
|IndexC(R2)| 4
page(IndexC(R2)) 50
Tabelle 4.7: Metadaten für die Relationen R1 und R2
Die Kosten für die Selektion ergeben sich damit zu:
I/O-Kosten CPU-Kosten Ergebnis
page(IndexA(R1)) + min(page(R1), q(σA=c(R1)))· I/O + 0, 02· CPU
(q(σA=c(R1)) · page(R1) · |IndexA(R1)|) (|R1| + |IndexA(R1)|)
1
1
50 + min(1000, 10000 · 1000 · 4)
10000 · (10000 + 4) (50 + 0, 02 · 1) ≈ 50
≈ 50 ≈ 1
2.Level Jetzt werden die Kosten für die Berechnung von R =✶ Rel,Index
�R1.C=R2.C ( � R1, R2)
benötigt (siehe Kapitel 4.6.3).
Dazu wird zunächst Scan Index
C=�R1.C (R2) berechnet:
I/O-Kosten CPU-Kosten Ergebnis
page(IndexC(R2)) + min(page(R2), q(σ C=�R1.C (R2)))· I/O + 0, 02· CPU
(q(σ C=�R1.C (R2)) · page(R2) · |IndexC(R2)|) (|R2| + |IndexC(R2)|)
1
1
50 + min(1000, 10000 · 1000 · 4)
10000 · (10000 + 4) (50 + 0, 02 · 1) ≈ 50
≈ 50 ≈ 1
Schließlich wird der erste Teil der I/O-Kosten für die Berechnung der Joinkosten
auf Null gesetzt, da ein Pipelining im ersten Operanden stattfindet.
Desweiteren wird die Selektivität von ✶ Rel,Index
�R1.C=R2.C ( � R1, R2) benötigt, die man
- wie im Kapitel 4.3.2 erläutert - mit 1
|R2|
abschätzen kann:

64 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN
I/O-Kosten CPU-Kosten Ergebnis
0 + Scan Index (R2) q( � R1 ✶�R1.C=R2.C R2) · (| � R1| + |R2|) I/O + 0, 02· CPU
0 + 50 = 50
1
10000 · (1 + 10000) ≈ 1 (50 + 0, 02 · 1) ≈ 50
3.Level In diesem Schritt benötigen wir die Kosten für � R = σRel E=2 (R), die als Eingaberelation
das vorhergehende Join hat. Dafür benötigen wir die dazugehörige
Kardinalität (siehe dazu Kapitel 4.5):
|R| = | � R1| = 1,
da das Attribut C Schlüssel der Relation R2 ist.
Somit ergibt sich für � R = σRel E=2 (R) wegen des Pipelinings:
I/O-Kosten CPU-Kosten Ergebnis
0 |R| I/O + 0, 02· CPU
0 1 0 + 0, 02 · 1 ≈ 0
4.Level Am letzten Knoten müssen noch die Kosten für die geforderte Projektion
�R = π Rel
B,D ( � R) berechnet werden. Als Eingabe bekommt sie das Ergebnis der
vorhergehende Selektion: � R = σ Rel
E=2 (R).
Wiederum wird die Kardinalität benötigt:
|σ Rel
E=2(R)| = q(σE=2(R)) · |R|
⇒ |σ Rel
E=2(R)| ≤
1
· 1
n(E, R)
⇒ |σ Rel
E=2(R)| ≤ 1
· 1 = 1
1
Damit ergibt sich unter Berücksichtigung des Pipelinings:
I/O-Kosten CPU-Kosten Ergebnis
0 | � R| I/O + 0, 02· CPU
0 1 (0 + 0, 02 · 1) ≈ 0
Somit ergibt sich folgender Kostenwert für den oben genannten Anfrageplan:
cost(P) = 50 + 50 + 0 + 0 = 100

4.9. FAZIT DES KOSTENMODELLS 65
4.9 Fazit des Kostenmodells
Abschließend muß man noch sagen, daß es bei einem sinnvollen Kostenmodell
nicht auf die exakte Abschätzung der Kosten ankommt, sondern darauf, daß
sich die realen Kostendifferenzen der einzelnen Ausführungspläne für die gleiche
Anfrage in dem Modell wiederfinden. Das heißt, daß kleine Fehler und Ungenauigkeiten
in den Abschätzungen keine Auswirkung auf die Bewertungsreihenfolge
der untersuchten Pläne haben. Die relative Bewertung der Pläne und nicht die
Bestimmung der genauen Kosten oder Antwortzeiten ist ausschlaggebend. Diese
Anforderung an ein gutes Kostenmodell läßt sich leicht nachprüfen, indem man
probehalber eine Anfrage Brute-Force optimiert, sich dann die Kostendifferenzen
anschaut und mit den geschätzten Differenzen vergleicht. Entscheidend ist,
daß der geschätzte beste Plan auch tatsächlich in die Nähe des Kostenminimums
gelangt.
Heute erlangt dieses Thema eine immer wichtigere Rolle und wird unter dem
Namen ” statistical database profile“ geführt. Dabei wird das statistische Profil
einer Datenbank durch Verwendung von Statistiken und statistischen Analysen
summiert, das dann als Grundlage für die Anfrageoptimierung, den physischen
Datenbank-Entwurf und die Leistungsvorhersagen einer Datenbank benutzt wird.

66 KAPITEL 4. KOSTENFUNKTIONEN UND SELEKTIVITÄTEN

Kapitel 5
Manchmal bezahlt man den höchsten Preis
für Dinge, die man umsonst erhält.
Albert Einstein
Kostenbasierte Optimierung
Nach erfolgreicher Entwicklung der physischen Prototypen (siehe Abschnitt 3.8)
wird mit Hilfe der im letzten Kapitel vorgestellten Kostenfunktion die Möglichkeit
geschaffen, daß ein Suchalgorithmus ausgehend von dem Prototypen den besten
Anfragebaum finden kann.
Die Ausgangssituation ist folgende: Die gegebene Anfrage wird in einen Anfragebaum
übersetzt und dieser zu einem oder mehreren Prototypen umgeformt 1 .
Dieser Prototyp entsteht durch Ersetzung der algebraischen Operatoren durch
physische (siehe Abschnitt 2.3 und 3.8). Mittels der Ersetzungsregeln der physischen
Algebra können daraufhin diese Operatorbäume weiter modifiziert werden.
1:1-Übersetzung
❚
❚
❚
❚�
✻
✲
��✠ Anfrageraum
Kostenfunktion
��✠
�
❅❄
❅
❅ Prototyp
Abbildung 5.1: Suchraum der Ausführungspläne
1 In der später vorgestellten Implementierung (siehe Kapitel 7) wird durch die beiden Heuristiken
(siehe Abschnitte 2.3 und 3.8) jeweils nur ein Prototyp erzeugt.
67

68 KAPITEL 5. KOSTENBASIERTE OPTIMIERUNG
5.1 Heuristische Suchverfahren
In diesem Abschnitt sollen verschiedene heuristische Suchverfahren vorgestellt
werden, um dann die besten davon für die kostenbasierte Optimierung einzusetzen.
Allen diesen Suchverfahren liegt das Prinzip zugrunde, daß ausgehend von
einem Startknoten sukzessive Nachbarn besucht und bewertet werden. Sie unterscheiden
sich in der Reihenfolge der Abarbeitung der Nachbarn und in der Frage,
ob ein Suchbaum aufgebaut wird oder nicht.
Um also ein solches Verfahren anwenden zu können, muß erstens ein Startknoten
erzeugt werden, dieses ist die Prototypentwicklung. Zweitens muß eine Methode
bereitstehen, die zu einem gegebenen Knoten die Nachbarn ausgibt. Im Fall der
kostenbasierten Anfrageoptimierung sollen hier die Nachbarn eines Operatorbaumes
alle Operatorbäume sein, die aus dem gegebenen Baum durch Anwendung
einer Ersetzungsregel entstehen. Dabei kann es bei der Implementierung sinnvoll
sein, Ersetzungsregeln, die die Laufzeit der Anfragebearbeitung bekanntermaßen
verlängern, von vornherein auszuschließen. Drittens muß eine Bewertungsfunktion
zur Verfügung stehen, mit der einem Knoten ein Wert zugeordnet wird, der
die Qualität des Knotens widerspiegelt. Dabei ist es für die Funktionsweise der
Suchverfahren zunächst einmal unbedeutend, ob diese Funktion eine Art Gütefunktion
ist, dementsprechend ein Maximum dieser Funktion gesucht wird, oder
ob sie eher eine Kostenfunktion darstellt und von daher ein Minimum zu finden
ist. Zur Vereinfachung der Darstellung soll angenommen werden, daß ein Knoten
gesucht wird, der ein (absolutes) Minimum der Bewertungsfunktion realisiert.
Dieser paßt dann mit der kostenbasierten Optimierung durch die Kostenfunktion
zusammen.
5.1.1 Hill-Climbing Suche
Hill-Climbing ist ein heuristisches Suchverfahren, das ohne einen Suchbaum auskommt.
Der Algorithmus speichert den Startknoten als BisherigerKnoten und
iteriert folgendes Verfahren:
(a) Bestimme alle Nachbarn von BisherigerKnoten und bewerte sie.
(b) Speichere den Nachbarknoten mit der niedrigsten Bewertung in Nächster-
Knoten.
(c) Falls die Bewertung von NächsterKnoten besser ist als die von Bisheriger-
Knoten, überschreibe BisherigerKnoten mit dem neu gefundenen Knoten
und beginne von vorn.
Für den Fall, daß die Bewertung von NächsterKnoten nicht besser ist als die
von dem bisherigen, was ja bedeutet, daß keiner der Nachbarn besser ist als der

5.1. HEURISTISCHE SUCHVERFAHREN 69
bisherige Knoten, bricht der Algorithmus ab und gibt BisherigerKnoten aus.
Dieser Algorithmus hat natürlich seine Nachteile, die wichtigsten sind:
(a) Lokales Minimum: Da der Algorithmus abbricht, wenn die Bewertungsfunktion
in der Umgebung des momentanen Knotens keine kleineren Werte mehr
annimmt, kann es sein, daß das Ergebnis ” nur“ ein lokales Minimum ist.
(b) Plateau: Da der Algorithmus nur eine kleine Umgebung untersucht, führen
auch Plateaus zu einem Abbruch. Wenn man bei einem Knoten angekommen
ist, der auf einem Plateau der Kostenfunktion liegt, gibt es in der
kleinen Umgebung um den bisherigen Knoten nur Knoten mit derselben
Bewertung.
Der Algorithmus wird an dieser Stelle abbrechen, da ein Nachbar gesucht
wird, der eine bessere (also echt bessere) Bewertung hat. (Wenn man den
Algorithmus leicht verändert, kann man natürlich auch erreichen, daß er
auf einem Plateau per Zufall einen der gleichwertigen Nachbarn auswählt.
Dies scheint aber nicht sehr erfolgversprechend.)
(c) Sattelpunkt: Auch an einem Sattelpunkt der Kostenfunktion kann der Algorithmus
Probleme bereiten. Da die Nachbarn-Methode nur endlich viele
Nachbarn ausgeben kann, kann ein Sattelpunkt, von dem aus nur in einer
der Hauptrichtungen ein schwacher Abstieg und in den anderen ein starker
Anstieg der Bewertungsfunktion vorliegt, zu den gleichen Problemen wie
ein lokales Minimum führen.
Liegt nämlich keiner der Nachbarn hinreichend genau in Richtung des Abstiegs,
wird keiner der Nachbarn eine bessere Bewertung als der momentane
Knoten bekommen. Je kleiner die Anzahl der betrachteten Nachbarn ist,
desto eher stellt ein Sattelpunkt ein Problem dar.
Diese Probleme kann man z.B. dadurch lösen, daß man den Algorithmus mehrfach
mit verschiedenen Startknoten startet. Die Möglichkeit der zufälligen Erzeugung
von Startknoten erscheint nicht praktikabel; durch die Entwicklung mehrerer Prototypen
und die Anwendung des Hill-Climbing-Algorithmus auf jeden einzelnen
kann man aber diese Probleme entschärfen.
5.1.2 Simulated Annealing
Eine andere Möglichkeit die genannten Probleme der Hill-Climbing Suche zu
lösen, ist die Idee des Simulated Annealing. Dieser Algorithmus verhält sich ähnlich
wie der Hill-Climbing Algorithmus. Ausgehend von einem Knoten wird aber
nicht aus allen Nachbarn der beste weiterverfolgt, sondern ein zufälliger ausgewählt
und bewertet. Abhängig von der Differenz seiner Bewertung und der des

70 KAPITEL 5. KOSTENBASIERTE OPTIMIERUNG
vorherigen Knotens bekommt der neue Knoten eine Wahrscheinlichkeit zugeordnet,
mit der er weiterverfolgt wird.
Ist die Differenz positiv, der neue Knoten also besser als der alte, ist die Wahrscheinlichkeit
1, dieser Knoten wird dann weiterverfolgt. Andernfalls stellt der
neue Knoten eine Verschlechterung dar. Je größer die Verschlechterung ist, desto
unwahrscheinlicher wird die Weiterverfolgung dieses Knotens. Darüberhinaus
wird diese Wahrscheinlichkeit mit wachsender Anzahl der durchgeführten Iterationen
reduziert. Das bedeutet, daß sich dieser Algorithmus mit zunehmender
Anzahl von Iterationen immer mehr wie Hill-Climbing verhält, zu Beginn aber
die Möglichkeit hat, ein lokales Minimum oder ähnliches wieder zu verlassen.
5.1.3 Best-First Suche
Mit der Best-First Suche soll nun ein Suchverfahren vorgestellt werden, das mit
einem Suchbaum arbeitet. Das bedeutet natürlich zusätzlichen Aufwand, birgt
aber auch einige Verbesserungsmöglichkeiten gegenüber den Verfahren, die ohne
einen Suchbaum agieren.
Das grundsätzliche Prinzip bei der Suche mit Suchbaum ist das folgende: Die
Wurzel des Suchbaumes ist der gegebene Startknoten (deshalb auch die Sprachregelung
” Knoten“). Die Kinder eines Knotens im Suchbaum sind alle Nachbarn
des Knotens. In diesem Baum muß nun systematisch derjenige Knoten gesucht
werden, der die global beste Bewertung hat. Zum Beispiel könnte man eine Tiefenoder
Breitensuche durchführen, allerdings wird dabei die zusätzliche Information
durch die Kostenfunktion weitgehend vernachlässigt. Eine Möglichkeit, diese
Information mit einzubeziehen, ist die Best-First Suche.
Dieses Suchverfahren gleicht der Tiefensuche, mit dem Unterschied, daß von einem
Knoten aus nicht zunächst der linkeste Nachfolgeknoten besucht wird, sondern
der Knoten betrachtet wird, der die beste Beurteilung erhalten hat. Es
gibt dabei aber natürlich keine Garantie, daß dieser scheinbar beste Pfad auch
tatsächlich zum kostengünstigsten Knoten führt.
Der Algorithmus sieht wie folgt aus:
(a) Erzeuge einen Baum mit dem gegebenen Startknoten als Wurzel.
(b) Bestimme alle Nachbarn dieses Knotens, bewerte sie und füge diejenigen,
die noch nicht im Baum stehen, als Kinder des betrachteten Knotens ein.
(c) Wähle den Nachfolgerknoten mit der besten Bewertung aus und beginne
wieder bei (b).
(d) Wird ein Blatt des Baumes erreicht, muß entschieden werden, ob dieser
Knoten der Endknoten ist.

5.2. FAZIT DER HEURISTISCHEN SUCHE 71
5.1.4 Beam-Search
Hierbei handelt es sich um ein ähnliches Verfahren wie die Breitensuche. Jedoch
werden pro Ebene nur die x besten Pfade weiter betrachtet. Der Suchbaum bleibt
somit unabhängig vom Branching-Faktor nur x Pfade breit und wächst nicht
exponentiell.
Auch dieser Algorithmus kann im schlimmsten Fall keine Lösung liefern, obwohl
eine existiert. Dies ist dann der Fall, wenn die scheinbar x besten Pfade einer
Ebene in weiterer Folge nicht zum Ziel führen.
5.2 Fazit der heuristischen Suche
Bei all diesen Verfahren ist die Vorgabe eines guten Prototyps unvermeidlich, da
man sonst das globale Minimum nicht finden kann. Somit wird der Startort im
Suchraum fest vorgegeben. Er muß in der Nähe des globalen Minimums liegen
und weit genug entfernt von vermeintlich sinnvollen lokalen Minima.
Eine weitaus effektivere Suche ließe sich realisieren, wenn man das Ziel kennen
würde; bzw. wissen könnte, in welchem Bereich des Anfrageraumes es liegen wird.
Dadurch könnte eine sinnvollere Einschränkung und daraus resultierende Schwellwerte
realisiert werden. Da genau das unser Problem bei der Anfrageoptimierung
ist (der beste Anfragplan ist nicht bekannt), können wir nicht auf Bestinformierte
Heuristiken wie den A*-Algorithmus zurückgreifen.
Somit bleiben uns zur Optimierung der bevorzugten Heuristiken nur sinnvolle
Kombinationen, die den jeweiligen Nachteil der einzelnen Heuristik wieder ausgleichen.
Dazu gehört das parallele Starten verschiedener Optimierungsalgorithmen
mit unterschiedlichen Ausgangspunkten (verschiedene Prototypen), wie auch
der Versuch eines frühzeitigen Prunings (Begrenzung des Lösungsraumes durch
Löschen von schlechten Plänen für die äquivalente Pläne existieren).
5.3 Genetische Algorithmen
Die kanonischen Genetischen Anfrageoptimierungsalgorithmen stellen bei komplexeren
Anfragen alternative Methoden zu deterministischen Verfahren dar, da
sie die Bestimmung des optimalen Ausführungsplanes ohne ein vollständiges
Durchsuchen (Brute-Force-Suche) des Lösungsraumes ermöglichen.
Dabei werden die möglichen Lösungen des Optimierungsproblems als Population
von Individuen in einer künstlichen Welt betrachtet. Der Grad der Anpassung

72 KAPITEL 5. KOSTENBASIERTE OPTIMIERUNG
eines Individuums wird als seine Fitness beschrieben. Die Koordinaten eines Individuums
werden als Gene bezeichnet. Durch Modellierung der evolutionären
Operationen, Rekombinationen, Mutationen und Selektionen werden neue Nachfahren
von Suchpunkten gefunden, die mit höherer Wahrscheinlichkeit eine bessere
Fitness aufweisen als Ihre Ahnen.
Der Algorithmus sieht wie folgt aus:
• Initialisiere zufällig die Elterngeneration P (t) zum Zeitpunkt t = 0 und
berechne die gegenwärtige Fitness eines jeden Individuums
• Wiederhole solange bis Abbruch
– Durch Rekombination vermische den Informationsinhalt der elterlichen
Gene miteinander.
– Durch Mutation verändere stochastisch die Gene, so daß neue Individuen
erzeugt werden, die neuartige (innovativere) Geninformationen
besitzen.
– Durch Selektion bevorzuge Individuen mit besserer Fitness für nachkommende
Generationen.
– Berechne die Fitness der gegenwärtigen Population und erhöhe das
Zeitalter um eins (t = t + 1).
– Starte die Generierung der neuen Kinderpopulation
Eine Steigerung der Robustheit von Genetischen Algorithmen als Optimierungsstrategie
läßt sich durch eine Parameteranpassung realisieren. Dabei wird die
genetische Suche durch Manipulation der Parameter Populationsgröße, Generationszahl
sowie Mutationsrate an die Dynamik der Optimierung angepaßt.

Kapitel 6
Eine wirklich gute Idee erkennt man daran,
daß ihre Verwirklichung von vorneherein
ausgeschlossen erscheint.
Albert Einstein
Die Optimierungsstrategie
Dieses Kapitel dient der Darstellung und Bewertung der entwickelten und favorisierten
Optimierungsstrategie. Ausgehend von den Teilstrategien der bisherigen
Kapitel soll verdeutlicht werden, wie die einzelnen Regeln und Verfahren zusammenwirken.
Der Ablauf sieht dabei schematisch wie in Abbildung 6.1 dargestellt
aus.
Eingabe: Zu Beginn steht bekanntermaßen die Anfrage des Anwenders, die in
SQL oder einem Ausdruck der Relationenalgebra gestellt wird. Diese Anfrage
muß zunächst in eine adäquate Form gebracht werden. Hierzu wird
die Eingabe mittels eines Parsers in einen äquivalenten algebraischen Anfragebaum
umgewandelt. Dabei werden die eingegeben Operatoren in die
implementierte Datenstruktur übersetzt, aber noch keine Optimierungen
durchgeführt. Dieser Schritt wurde im wesentlichen in der Einleitung beschrieben,
der entstehende Baum ist die sogenannte 1:1-Übersetzung der
Anfrage, dieser wird nun weitergegeben.
Algebraische Optimierung: Bei der algebraischen Optimierung werden, wie
in Kapitel 2.1 genauer dargestellt, ausgehend von der 1:1-Übersetzung algebraische
Prototypen erstellt. Grundlage hierfür sind die Faustregeln aus Abschnitt
2.3. Da diese teilweise miteinander konkurrieren, erhält man durch
verschiedene Reihenfolgen der Anwendung der Faustregeln im allgemeinen
verschiedene Prototypen. Dies ist durchaus so gewollt, da durch die Verwendung
mehrerer Startwerte mit genügend großem Abstand die Probleme
der heuristischen Suchverfahren relativiert werden.
Allerdings ist der Zusatz ” mit genügend großem Abstand“ sehr entscheidend.
Startet man nämlich z. B. mit zwei sehr ähnlichen Startwerten, erhöht
sich die Laufzeit der Suche, aber es wird kein Vorteil erreicht, da in beiden
Suchdurchläufen ohnehin dieselbe Region untersucht wird. Deshalb ist
73

74 KAPITEL 6. DIE OPTIMIERUNGSSTRATEGIE
Anfrage (SQL)
Normalisierung
❄
Anfragebaum
alg. Transformation
❄
Prototypen (alg.)
phys. Transformation
❄
Prototypen (physisch)
Hill-Climbing
❄
Eingabe
Algebraische Optimierung
Physische Optimierung
mehrere Vorschläge Kostenbasierte Optimierung
Minimum
❄
opt. Operatorbaum
Ausführung
❄
Ergebnisrelation
Ausgabe
Abbildung 6.1: Ablauf der Anfrageoptimierung
es wichtig, die erzeugten Prototypen vor der Weitergabe dahingehend zu
untersuchen, daß der paarweise Abstand groß genug ist. Der Abstand ergibt
sich hierbei durch die Anzahl der benötigten Transformationsschritte
bei der Umformung des ersten Baumes in den zweiten. Für diesen Teil der
Strategie fehlen aber leider noch die Erfahrungswerte dafür, was es heißt
genügend weit von einander entfernt zu sein. Aus diesem Grund wird bisher
nur ein Prototyp erstellt. 1
Dieser Teil der Optimierungsstrategie besteht, wie der Name schon sagt,
ausschließlich aus algebraischen Optimierungen. Am Ende werden im allgemeinen
mehrere algebraische Prototypen weitergegeben.
1 Bei einem Prototyp läuft man nicht Gefahr, daß die Abstände zwischen den einzelnen
Alternativen zu klein sind. Somit erfüllt ein Prototyp trivialerweise die Forderung hinreichend
unterschiedlich zu sein.

Physische Optimierung: Im nächsten Schritt müssen die algebraischen Operatoren
eines jeden übergebenen algebraischen Prototypen in physische
Operatoren übersetzt werden. Die theoretische Grundlage hierfür liefert
Kapitel 3.
Hierbei ist es analog zur obigen Überlegung weder notwendig noch sinnvoll,
jeden algebraischen Operatorbaum in genau einen physischen Anfragebaum
zu übersetzen. Mehr noch, durch die Erzeugung mehrerer Übersetzungen
werden wiederum mehr Startwerte für die Suchverfahren zur Verfügung
gestellt. Hier muß aber eine sinnvolle Abwägung durchgeführt werden. Denn
die ” einfache“ Methode, jede erdenkliche Übersetzung in Betracht zu ziehen,
führt auf eine zu große Anzahl von Startwerten, die auch nicht hilfreich ist,
da die Abstände hierbei eindeutig zu klein werden.
Dementsprechend werden die Regeln aus Abschnitt 3.8 angewandt, um
verschiedene Varianten jedes algebraischen Prototypen zu erhalten. Dabei
genügt es bei der Übersetzung darauf zu achten, daß zwei Übersetzungen
eines algebraischen Baumes hinreichend unterschiedlich sind. Dies ist der
Fall, da die algebraischen Prototypen bereits paarweise genügend unterschiedlich
übergeben werden, und bei der Übersetzung keine strukturellen
Änderungen am Baum durchgeführt werden. Dementsprechend kann die
Distanz der resultierenden physischen Bäume nicht kleiner werden als der
Abstand der algebraischen war, so daß die Übersetzungen verschiedener
algebraischer Bäume genügend große Entfernungen voneinander haben.
Wichtig ist, daß in diesem Schritt nur vorhandene Metadaten ausgenutzt
werden, aber noch nicht Operationen wie Sortierungen, Hashing oder der
Aufbau von Indexen eingesetzt werden. Dies ist der Fall, da in der physischen
Optimierung noch nicht die Möglichkeit besteht, zu entscheiden, ob
sich die Investition in eine solche Operation lohnen würde. Dementsprechend
erhält man verschiedene physische Prototypen, die genügend unterschiedlich
sind (z. B. genau einen Prototyp), die aber alle eines gemeinsam
haben, sie nutzen nur existierende Strukturen aus. Für die Übersetzungen in
physische Prototypen sind natürlich die Angaben über vorhandene Indexe,
Sortierungen etc. unverzichtbar.
Kostenbasierte Optimierung: Die kostenbasierte Optimierung erhält mehrere
Prototypen, die in diesem Schritt mittels des in Kapitel 4 entwickelten
Kostenmodells und eines angemessenen Suchverfahrens aus Kapitel 5 weiter
optimiert werden sollen. Die nächsten Abschnitte dieses Kapitels sind
der Erklärung der Gesamtstrategie gewidmet.
Ausgehend von einem physischen Prototypen soll die Generierung eines
neuen Operatorbaumes vollzogen werden, die insbesondere die Erzeugung
von zusätzlichen Strukturen wie Partitionierungen, Sortierungen und Inde-
75

76 KAPITEL 6. DIE OPTIMIERUNGSSTRATEGIE
xen in Betracht zieht. Dies ist in der kostenbasierten Optimierung sinnvoll,
da mittels des Kostenmodells eine Grundlage vorliegt, auf der entschieden
werden kann, ob das Hinzufügen einer solchen Operation weniger kostet,
als die Einsparungen, die man damit erreicht.
Anschließend sollen auch noch weitere Transformationen durchgeführt werden.
Mit Generierung und Transformation im allgemeinen und den Vorund
Nachteilen beschäftigt sich der folgende Abschnitt 6.1.
Im Abschnitt 6.2 wird dann die globale Strategie 2 erklärt, wohingegen im
darauffolgenden Abschnitt die lokalen Gesichtspunkte herausgearbeitet werden.
Wurde jeder physische Prototyp in der noch zu erklärenden Weise bearbeitet,
ergeben sich verschiedene physische Operatorbäume, deren Kosten
bekannt sind. Über diese Kosten muß nunmehr nur noch das Minimum gebildet
werden, um den optimalen Ausführungsplan zu erhalten, dieser wird
nun weitergegeben.
Ausgabe: Dieser Schritt erklärt sich fast von selbst. Es wird ein Ausführungsplan
übergeben, dieser wird ausgeführt und das Endergebnis dem Benutzer
zur Verfügung gestellt.
6.1 Transformation und Generierung von physischen
Anfragebäumen
Bislang erwartet man, daß die kostenbasierten Optimierung generell wie folgt
abläuft. Man hat einen Prototypen als Startwert, mit dem ein heuristisches
Suchverfahren begonnen wird. Ein solches Suchverfahren benötigt einen Nachbarschaftsbegriff.
Dieser ist durch die Anzahl von Transformationen gegeben. Das
heißt man transformiert einen Anfragebaum, bewertet die verschiedenen Transformationen
mittels der Kostenfunktion und wählt die günstigste Alternative aus.
Bei diesem Verfahren stößt man aber auf Probleme, die eine Ausführung in dieser
Form unmöglich machen. Diese werden im folgenden Abschnitt genauer erklärt.
Nachdem nun also die Transformation nicht zum Ziel führt, muß ein anderes
Verfahren benutzt werden, das der Generierung. Hier ist die Herangehensweise
eine andere, es werden nicht Bäume transformiert, sondern Schritt für Schritt
benötigte Teilbäume eines Anfragebaumes erzeugt bzw. zusammengefügt. Dies
wird in der zweiten Hälfte des Abschnittes erklärt.
2 Die globale Strategie beschreibt die Optimierung des gesamten Anfragebaumes, wohingegen
die lokale nur einen Teilabschnitt verbessert.

6.1. TRANSFORMATION UND GENERIERUNG 77
Da auch die Generierung nicht problemlos läuft, soll im Endeffekt ein Verfahren
verwendet werden, welches eine Mischung dieser beiden darstellt. Dieses Verfahren
wird im nächsten Abschnitt entwickelt. Dabei wird zwischen lokaler und
globaler Strategie unterschieden, die lokale entspricht der Transformation von
Teilbäumen, die globale eher einer Generierung. Die Erklärungen im folgenden
Abschnitt können daher nur eine kleine Einführung in die Transformation bzw.
Generierung sein (siehe dazu Markoette [38]). Die eigentliche Anwendung wird
erst später genauer beschrieben.
• Transformation
Durch die Anwendung von Transformationsregeln wird ein vollständiger
physischer Anfragebaum in einen weiteren überführt. Diese Vorgehensweise
wird auch als Verbesserungsverfahren bezeichnet. Leider ist dieser Name
leicht irreführend, da zwischenzeitlich auch schlechtere Varianten erzeugt
werden können. Der entscheidende Punkt ist, daß ein Baum als Startwert
gewählt wird und von diesem aus Transformationsregeln angewandt werden.
Abbildung 6.2: Schematische Darstellung der Transformation eines Anfragebaums
Als Startwert würde hier einer der physischen Prototypen genommen (1),
um danach durch Anwendung der Transformationsregeln der physischen Algebra
in verschiedene andere Darstellungen überführt zu werden; (2) und
(3) (siehe dazu Kapitel 2.1). Eine solche Transformation könnte beispielsweise
wie folgt aussehen (siehe Abbildung 6.3).
Wie wir aus dem Abschnitt 2.1 wissen, lassen sich im Prinzip alle Transformationsregeln
in zwei Richtungen anwenden. In Bild 6.2 ist die Rückpfeilspitze
jeweils schwächer dargestellt, um die wenigen Ausnahmen anzudeuten.

78 KAPITEL 6. DIE OPTIMIERUNGSSTRATEGIE
Darüberhinaus werden auch keine Rücktransformationen durchgeführt, da
die Idee des Verfahrens darin liegt, daß Transformationen durchgeführt werden,
um die Nachbarschaft eines Prototypen mittels eines kostenbasierten
Suchalgorithmus’ zu untersuchen.
✶NestedLoop ✪✪ ❡ R1 R2
✲
✶Merge ✪✪ ❡ Sort(·) Sort(·)
Abbildung 6.3: Beipiel für die Transformation eines Anfragebaums
Das Problem dieser Idee liegt in der Tatsache, daß zwar zu jedem so erhaltenen
Baum die Kosten berechnet werden können, aber keinerlei Aussagen
darüber getätigt werden können, wie weit das Optimum, gemessen in Transformationsschritten,
von der aktuellen Repräsentation entfernt liegt (siehe
Kapitel 5). Dies ist aber Voraussetzung dafür, nicht Erfolg versprechende
Transformationen ausschließen zu können. Ohne dieses Ausschließen von
” schlechten“ Transformationen ist es aber nicht möglich, die Suche auf einen
sinnvollen Teilraum einzuschränken. Damit wäre nur noch eine vollständige
Suche in der Lage, schlechte Pläne zielsicher zu vermeiden, diese soll aber
selbstverständlich vermieden werden.
Als Ausnahmen hiervon sind stochastische Optimierungsverfahren zu nennen,
welche aber gewisse Charakteristika des Suchraumes benötigen, die
hier nicht vorausgesetzt werden.
• Generierung
Bei der Generierung werden, beginnend mit den Blättern, also den benötigten
Relationen, (es wurde noch kein Ausführungsplan erzeugt) (1) sukzessive
benötigte Operatoren in die Menge der bereits generierten Teilbäume
eingebaut (2), bis eine vollständige interne Repräsentation gefunden worden
ist (3). Jeder eingebaute Operator wird nicht wieder entfernt oder verschoben.
Je weiter die Generierung gediehen ist, desto weniger Alternativen sind
von der aktuellen Teilrepräsentation aus erzeugbar (siehe Abbildung 6.4).
Geht man von einem Zwischenergebnis der Generierung aus, so ist die Menge
aller aus dieser Teilrepräsentation generierbaren Operatorbäume eine
Obermenge der Anfragebäume, die nach dem nächsten Generierungsschritt
entwickelt werden können.
Wendet man dieses Verfahren z. B. zum Optimieren einer Joinreihenfolge
an, erreicht man hierdurch gegenüber einer erschöpfenden Suche eine Ver-
R1
R2

6.1. TRANSFORMATION UND GENERIERUNG 79
Abbildung 6.4: Schematische Darstellung der Generierung eines Anfragebaums
besserung der Komplexität von n! auf 2 n , wenn aufgrund von Kommutativität
äquivalente, aber kostenaufwendigere Alternativen nicht betrachtet
werden (siehe dafür Moerkotte [38]).
Darüberhinaus hat man bei dieser Vorgehensweise Informationen über die
noch entstehenden Kosten, da die Menge der nicht eingebauten Operatoren
vorliegt. Könnte man dabei die Kosten nach unten abschätzen, lassen
sich effiziente Suchalgorithmen wie der A*-Algorithmus benutzen (dieser
ist nachweislich das beste Suchverfahren bei gleicher Informiertheit aller
Suchmethoden 3 ; siehe dazu Russel und Norvig [45]).
In jedem Schritt der Generierung hat man also eine Menge von Teilbäumen
gegeben, die jeder für sich fest gehalten werden. Darüberhinaus hat man
eine Menge von Operatoren gegeben, die noch einzuarbeiten sind, um eine
vollständige Repräsentation zu erhalten. Hieraus muß ein passender Operator
nach Minimierungsgesichtspunkten der anfallenden Kosten für die Bearbeitung
der Anfrage ausgewählt werden und in sinnvoller Weise in die
Teilbäume eingebaut werden.
Dabei kann der Operator entweder als neue Wurzel über der alten Wurzel
eines Teilbaumes eingesetzt werden, falls es sich um einen einstelligen
Operator handelt, oder aber ein zweistelliger Operator wird so eingefügt,
daß zwei vorhandene Bäume zu einem großen Baum verbunden werden,
der die vorhandenen als rechten und linken Teilbaum und den Operator als
3 Da man aber in der relationalen Anfrageoptimierung den besten Anfragebaum nicht kennt,
können diese Algorithmen nie angewandt werden.

80 KAPITEL 6. DIE OPTIMIERUNGSSTRATEGIE
Wurzel enthält. Dadurch entsteht eine neue Menge von Teilbäumen und die
Operatormenge wird um eins reduziert.
❥
✁❆
✁✁ ❆ ❥
✁❆
✁✁ ❆❆
✁❆
✁✁ ❆ ❥
�� ❅
✁❆
✁✁ ❆ Abbildung 6.5: mögliche Schritte der Generierung
❥
�
�❅
❅
✁❆
✁❆
✁✁ ❆❆ ✁✁ ❆❆
Das Problem hierbei liegt in der Frage, in welcher Reihenfolge welche Operatoren
wo eingefügt werden sollen, um einen korrekten Anfrageplan zu
erhalten. Denn ein Operator, der in der Menge der noch einzufügenden
Operatoren liegt, kann natürlich nicht völlig beliebig hinzugefügt werden.
Um dieses Problem zu lösen, wird der Prototyp vorgegeben. Es sei schon
gesagt, daß für jeden Prototypen eine Generierung durchgeführt werden
soll, bei der der Prototyp sozusagen als ” Peilung“ eingesetzt wird. Einzelne
Teilbäume des Prototypen sollen hierbei transformiert werden und dann
als Teilbaum in den neu zu generierenden Baum eingesetzt werden.
6.2 Die globale kostenbasierte Optimierungsheuristik
Für die kostenbasierte Optimierungsheuristik sei ein physischer Prototyp vorgegeben.
Dieser gibt einen möglichen Ausführungsplan der Anfrage wieder, der als
Ausgangspunkt der Generierung dienen soll. Der Prototyp legt erstens fest, welche
Operatoren einzusetzen sind, um tatsächlich einen Anfrageplan für die gegebene
Anfrage zu erhalten, wobei natürlich Operatoren durch äquivalente ersetzbar
sind. Zweitens legt er fest, in welcher Reihenfolge die Operatoren überhaupt anwendbar
sind, um die korrekte Anfrage zu modellieren.
Die Idee liegt jetzt darin, grundsätzliche Baumstruktur des gegebenen Protoypen
festzulassen, aber durch das Einfügen von einstelligen Operatoren (z. B. Hash),
die Nutzung von günstigeren physischen Operatoren zu ermöglichen. Dabei muß
natürlich überprüft werden, in welchem Verhältnis die neu entstandenen Kosten
zu den eingesparten stehen.
Da für die Generierung ein passender bottom-up-Durchlauf des Prototypen benötigt
wird, soll zunächst die folgende Aussage über den Prototyp gemacht werden.

6.2. DIE GLOBALE KOSTENBASIERTE OPTIMIERUNGSHEURISTIK 81
Jeder Prototyp, der eine Anfrage auf mindestens zwei Relationen repräsentiert 4 ,
ist ein Baum der Form:
[π]
[σ]
✶
✪ ❡
✪ ❡
T1
Abbildung 6.6: lokale Form des Prototypen
Dabei seien die Ti entweder Relationen oder selber Bäume der gleichen Form.
Dazu sei angemerkt, daß natürlich mit π, σ und ✶ nicht die algebraischen Operatoren
dieses Namens gemeint sind, sondern eine der physischen Übersetzungen.
Darüberhinaus sind die eckigen Klammern dahingehend zu verstehen, daß ein
solcher Operator auch fehlen kann.
Diese Form wird erreicht, da erstens jede zweistellige Operation als passender
Join dargestellt werden kann und wird, und zweitens eine beliebige Kette von einstelligen
Operatoren, also Projektionen und Selektionen, im physischen Prototyp
derart zusammengefaßt wird, daß nur noch eine Selektion vor einer Projektion
durchgeführt wird. Wird nach true selektiert bzw. auf das Schema projiziert,
wird die entsprechende Operation weggelassen.
Das Entscheidende an dieser Form ist, daß der Baum einem binären Baum sehr
nahe kommt. Das soll heißen, es gibt nur Knoten mit weniger als zwei Kindern
und die Höhe der linearen Teilgraphen ist durch zwei begrenzt.
Jetzt soll die Generierung erklärt werden.
Initialisierung: Zur Initialisierung wird ein Zeiger auf den Knoten K gesetzt,
der genau zwei Kinder besitzt und unter allen Knoten mit dieser Eigenschaft
das höchste Level hat, also den größten Abstand von der Wurzel, und am
weitesten links steht, falls gleiche Level auftreten. Dieser Zeiger hat die
Aufgabe, den bereits fertig generierten Teil des Operatorbaumes von dem
restlichen Prototypen zu trennen.
Rekursion: In jedem Schritt der Generierung findet folgender Ablauf statt. Zunächst
wird die sogenannte lokale Umgebung des Knotens K im Prototypen
bestimmt, diese ist von der Form (siehe Abbildung 6.7) für passende
physische Operatoren π und σ mit entsprechenden Bedingungen bzw.
4 Ist dies nicht der Fall, handelt es sich um einen der beiden trivialen Fälle: entweder ist der
Baum leer, oder er degeneriert zu einem linearen Graphen.
T2

82 KAPITEL 6. DIE OPTIMIERUNGSSTRATEGIE
K ❧
✪✪ ❡ [π] [π]
[σ] [σ]
Abbildung 6.7: lokale Umgebung
Attributmengen. Dieser Teilbaum wird nach der lokalen Strategie, die im
nächsten Abschnitt erklärt wird, auf verschiedene Weisen optimiert und
jeweils nach und nach in einer Kopie (inklusive des Zeigers) des Prototypen
durch diese Optimierung ersetzt. Wurden in der lokalen Optimierung
zusätzliche Metadaten erzeugt (dies wird i.a. der Fall sein), wird der Pfad
vom Knoten K zur Wurzel in der Kopie bottom-up dahingehend überprüft,
ob ein physischer Operator durch einen äquivalenten mit besserer Laufzeit
ersetzt werden kann. Dieser Teil der Strategie soll die von einer lokalen Optimierung
induzierte globale Optimierung genannt werden. Hierbei wird,
wie in der physischen Optimierung, ein Hash-Join einem Index-Index-Join
vorgezogen, gefolgt von Index-Rel-, Merge- und NestedLoop-Join.
Im gleichen Durchlauf können die Kosten des neu entstehenden Baumes
berechnet werden, da sich außerhalb des Pfades vom Knoten K zur Wurzel
die Kosten nicht verändern. Das bedeutet, daß in jedem besuchten Knoten
auf diesem Pfad, die Kosten des Teilbaumes, aus dem heraus man den
Knoten besucht, und die Kosten an diesem Knoten (nach einer eventuellen
Ersetzung durch einen äquivalenten Operator) inklusive der für die
Kostenberechnung benötigten Parameter, berechnet und in dem Knoten
abgespeichert werden.
Nachdem alle lokalen Optimierungen, die sinnvoll erscheinen, getätigt wurden
und die entsprechenden Kosten vorliegen, wird unter allen der Plan mit
den geringsten globalen Kosten ausgewählt. Insbesondere werden also nicht
die Kosten der lokalen Optimierungen miteinander verglichen. Dieser Plan
wird durch eine modifizierte Kopie des Prototypen gegeben, in der insbesondere
die beste vorgenommene Optimierung der Umgebung des Knotens
K enthalten ist. Diese Kopie nimmt nun den Platz des alten Prototypen
ein.
Als nächstes wird der Zeiger (auf der Kopie) auf den nächsten Knoten gesetzt.
Dieser wird dadurch bestimmt, daß der begonnene Level-Durchlauf
(bottom-up von links nach rechts) des Prototypen fortgeführt wird. Dies ist
trotz der Modifikation des Prototypen wohldefiniert, da die lokalen Optimierungen
sich nur auf den Knoten K und darunterliegende Level auswirken
und die induzierte globale Optimierung keine Veränderungen an der Baum-

6.2. DIE GLOBALE KOSTENBASIERTE OPTIMIERUNGSHEURISTIK 83
struktur bewirkt. (Es werden hier nur die Operatoren in einzelnen Knoten
verändert.)
Dadurch wird die vorgenommene lokale Optimierung fixiert, was dahingehend
interpretiert werden kann, daß die entsprechende, optimierte Umgebung
in die (hier nicht realisierte) Menge der fixierten Teilbäume der
Generierung eingefügt wird. Außerdem wird dadurch die Menge der einzufügenden
Operatoren (in Form von Umgebungen von Joinknoten), um
den abgearbeiteten Teil verringert.
Gesetzt den Fall es gibt keinen weiteren Knoten mit zwei Kindern, kann
die Rekursion abgebrochen werden und die Abschlußphase übergegangen
werden.
Terminierung: Oberhalb des obersten Knotens mit zwei Kindern kann maximal
noch eine Selektion und eine Projektion liegen. In einem abschließenden
Schritt wird überprüft, ob sich das Erzeugen eines Index auf dem Ergebnis
des letzten Joins lohnt, in dem in einer Kopie des Prototypen diese Operation
eingefügt wird, Selektion und Projektion mittels σ Index bzw. π Index
ausgeführt werden und die resultierenden Kosten des gesamten Baumes
berechnet werden. (Dafür müssen natürlich nur die Kosten der Indexierung,
der Index-Selektion und -Projektion auf die Gesamtkosten im letzten
Joinknoten addiert werden.) Der günstigere der beiden Pläne wird dann
ausgegeben.
Diese Strategie entspricht einem leicht modifizierten Hill-Climbing-Algorithmus.
Zunächst eine kurze Zusammenfassung des Hill-Climbing: Ausgehend von einem
Startwert werden mittels eines festen Nachbarschaftsbegriffes alle Nachbarn des
aktuellen Knoten bewertet und der beste ausgesucht. Ist dieser nicht besser als
der aktuelle Knoten, wird der aktuelle Knoten ausgegeben, andernfalls wird der
neue Knoten als aktueller Knoten gespeichert und von dort die Suche fortgesetzt.
Nun zur vorgestellten Generierung: Der vorgegebene Prototyp der physischen
Optimierung bildet den Startwert der Suche. Für einen festen Knoten K mit
genau zwei Kindern ist die Nachbarschaft des aktuellen Prototypen gegeben durch
die modifizierten Kopien des Prototypen (nach lokaler und induzierter globaler
Optimierung) und den Prototypen selbst. Unter diesen Nachbarn (inklusive des
aktuellen Prototypen) wird das Minimium der Kosten gebildet, der entsprechende
Baum wird zum aktuellen Prototypen. Durch das Verschieben des Zeigers wird
nun aber der Nachbarschaftsbegriff verändert. Denn falls der alte Prototyp unter
allen Nachbarn selbst die minimalen Kosten aufweist, bleibt er der Prototyp, aber
im nächsten Schritt werden nicht wieder die gleichen Nachbarn erzeugt, sondern
solche, die durch lokale Optimierungen einer anderen Umgebung (nämlich der
des neuen Knotens K) entstehen. Abgebrochen wird der Algorithmus, wenn man
die Wurzel erreicht.

84 KAPITEL 6. DIE OPTIMIERUNGSSTRATEGIE
6.3 Die lokale kostenbasierte Optimierungsheuristik
Ausgehend von einer in Abschnitt 6.2 gegebenen lokalen Umgebung eines Joinknoten
K der Form (siehe Abbildung 6.8), werden wie folgt Transformationen
erstellt:
(a) Durch zusätzliche Sortierungen unterhalb des Knotens K, falls die Relationen
an dieser Stelle noch nicht sortiert sind, kann der Joinoperator im
Knoten K durch einen Merge-Join ersetzt werden. Der durch diese Transformation
entstandene Teilbaum ist eine der lokalen Optimierungen, die an
die globale Heuristik übergeben wird.
K ❧
✪✪ ❡ [π] [π]
[σ] [σ]
Abbildung 6.8: lokale Umgebung
(b) Vergleichbar zur Sortierung werden zusätzliche Partionierungen der zu
bearbeitenden Anfangsrelationen in den Baum unterhalb des Knoten K
eingefügt, um hierbei einen Hash-Join im Knoten K generieren zu können.
Auch dieser Baum wird der Heuristik zurückgegeben.
(c) Als nächster Schritt wird der Anfragebaum auf kostensparendes Einfügen
von Indexen untersucht. Dabei ist es wichtig, daß frühzeitiges Erzeugen
die beste Art ist, Zugriffskosten zu verringern. Falls auf der Relation unter
einer der Selektionen kein Index vorhanden ist, wird direkt unter der
Selektion die Operation T ree, also der Aufbau eines Indexes, eingefügt. Dadurch
können alle Selektionen bzw. Projektionen durch ihre kostensparende
Index-Variante ersetzt werden. Ebenso kann ein Index-Index-Join verwendet
werden, um danach wiederum den Teilbaum an die globale Heuristik
zurückzugeben.
Nicht vergessen darf man, daß nicht jeder Index sinnvoll sein muß. Wird
zum Beispiel die Attributmenge mit einem Index versehen, bei dem das
Attribut den nachfolgenden Knoten nicht mehr erreicht, verringern sich die
Einsparungspotentiale. Dieses gilt natürlich auch für alle anderen Optimierungsmethoden.

6.4. FAZIT DER KOSTENBASIERTEN OPTIMIERUNG 85
6.4 Fazit der kostenbasierten Optimierung
Es werden zwar bei der Entwicklung der physischen Prototypen keine Hash-Joins
generiert (es kommt selten vor, daß Relationen schon vorgehashed vorliegen), aber
jetzt bei der kostenbasierten Suche ergeben sie dafür mehr Sinn. Dieses Verhalten
läßt sich gut auch bei anderen Optimierern, wie dem Oracle-Optimierer erkennen.
Auch dort werden anfangs kaum Hash-Joins generiert, sondern erscheinen erst
bei einer kostenbasierten Optimierung, die interessanterweise ein Kostenmodell
besitzt, das auf Histogrammen und Stichproben aufbaut.
Das in dieser Diplomarbeit gewählte Kostenmodell bietet einen entscheidenden
Vorteil. Das Scannen einer Relation mit Hilfe eines Indexes ist laufzeitmäßig
in keinem Fall wesentlich schlechter als ein einfacher Relationen-Scan (in vielen
Fällen ist es wesentlich besser), da es erkennt, ob es sich lohnt einen Zugriff über
den Index durchzuführen, oder einfach die gesamte Relation hineinzuladen. Dies
schlägt sich in der Kostenfunktion in der Minimumbildung nieder. Falls das Laden
der gesamten Relation niedrigere Kosten erzeugt als der Zugriff über den Index,
wird dies erkannt und die Laufzeit verschlechtert sich gegenüber dem Relationen-
Scan nur um das Laden des Indexes. Zwar gibt es ein paar Sonderfälle, bei denen
es teurer werden könnte, aber die fallen nicht ins Gewicht, da sie sich maximal
nur um das Reinladen des Indexes unterscheiden (siehe Scan-Kosten 4.6.1).
Abschließend sei noch eine Optimierungsstrategie erwähnt, die in unserem Kostenmodell
keine Vorteile besitzt:
(a) Nämlich das Einfügen von zusätzlichen Projektionen. Dadurch werden
zwar die Anzahl der Zwischenergebnisse nicht geringer, aber es werden I/O-
Zugriffe eingespart, da die Tupellängen verkürzt werden können. Auch diese
Regel sollte möglichst früh ausgeführt werden, da sie verhindert, daß man
redundante Daten in die oberen Knoten mit sich führt.
Schließlich seien hier noch ein paar Transformationsregeln erwähnt, die in speziellen
Fällen eine weitere Optimierung ermöglichen. Diese Methoden benötigen
noch zusätzliche Informationen, die ein komplettes Betrachten des Anfragebaumes
erfordern. Die Anwendung ist je nach Anfrage während oder vor der Generierungsphase
sinnvoll und sollte in jedem Fall neu untersucht werden.
(a) Der Optimierer versucht zusätzliche Transformationen durchzuführen, um
gleiche Zwischenergebnisse zu generieren, die er wiederum redundant
entfernen kann, da er sie ja nur einmal berechnen muß.
(b) Die in die Blätter verschobenen Selektionen können dahingehend überprüft
werden, ob sie vielleicht an einem anderen Ort im Anfrageplan weniger
Kosten verursachen würden.

86 KAPITEL 6. DIE OPTIMIERUNGSSTRATEGIE
Dies kann z. B. sinnvoll sein, wenn die Selektion die Nutzung eines Index in
einer nachfolgenden Operation verhindert (siehe Beispiel 3.9).
(a) Das Anordnen der Joins kann in der physischen Optimierung überdacht
werden. Dabei sollen die Zwischenergebnisse minimiert werden. Tatsächlich
sollte diese Regel schon bei der algebraischen Optimierung stattfinden. Leider
ist der dortige Aufwand um ein Vielfaches größer, da die Daten für die
Abschätzung der Relationengrößen hier nicht vorliegen, weshalb es sinnvoller
ist, diese Regel in der physischen Optimierung durchzuführen. Als eine
kleine Heuristik könnte man in diesem Fall die Anordnung der Relationen
nach der Anzahl ihrer Tupel vornehmen, so daß sich die Zwischenergebnisse
verkleinern. In der kostenbasierten Optimierung könnte diese Anordnung
noch mittels des Kostenmodels detaillierter überprüft werden.
6.5 Beispiel zur kostenbasierten Suche
Erinnern wir uns an unser Beispiel aus Kapitel 2.2 mit der folgenden relationalen
Anfrage: πB,D(σ(R1.A=c∧R2.E=2∧R1.C=R2.C)(R1 × R2))
πB,D
×
✓ ❙
✓ ❙
R1
σ (R1.A=c∧R2.E=2∧R1.C=R2.C)
R2
Abbildung 6.9: 1:1-übersetzter Anfragebaum
Nach der Anwendung der algebraischen Heuristik (siehe Abschnitt 2.3), bekommen
wir folgenden Anfragebaum: πB,D(σR1.A=c(R1) ✶ σR2.E=2(R2))
πB,D
✶R1.C=R2.C
✪ ❡
σ
✪ ❡
(R1.A=c) σ (R2.E=2)
R1
R2
Abbildung 6.10: Algebraischer Prototyp
Desweiteren seien wiederum die Metadaten für R1 wie folgt gegeben:

6.5. BEISPIEL ZUR KOSTENBASIERTEN SUCHE 87
Metadaten Wert
page(R1) 1000
|R1| 10000
n(A, R1) 10000
n(B, R1) 10
n(C, R1) 100
Tabelle 6.1: Metadaten für die Relation R1
Für R2 sei das Attribut C der Schlüssel der Relation und auf E liege ein Index
vor. Außerdem seien die dazugehörigen Metadaten:
Metadaten Wert
page(R2) 1000
|R2| 10000
n(C, R2) 10000
n(D, R2) 10
n(E, R2) 100
|IndexE(R2)| 4
page(IndexE(R2)) 50
Tabelle 6.2: Metadaten für die Relation R2
Somit ergibt sich durch die Anwendung unserer in Abschnitt 3.8 vorgestellten
Heuristik folgender physischer Prototyp:
σ Rel
(R1.A=c)
π IndexDup
B,D
✶ Rel−Index−Join
R1.C=R2.C
✪ ❡
✪ ❡
✪
✪
R1
σ Index
(R2.E=2)
R2
Abbildung 6.11: Physischer Prototyp
Wenn wir wiederum ein I/O-Constraintes System mit W = 0, 02 voraussetzen,
dann bekommen wir die Kosten für diesen Anfragebaum wie folgt: 5
5 Die vollständige Rechnung wird dem Leser erspart, da sie keine neuen Erkenntnisse liefert.
(siehe Beispiel 4.8)

88 KAPITEL 6. DIE OPTIMIERUNGSSTRATEGIE
cost(σRel (R1.A=c) ) = 1000 + 0, 02 · 10000 = 1200
cost(σIndex 1
1
(R2.E=2) ) = (50 + min(1000, · 1000 · 4)) + 0, 02 · ( · (10000 + 4)) = 92
100 100
cost(✶ Rel−Index−Join
R1.C=R2.C ) = (0 + 90) + 0, 02 · ( 1 · (1 + 100)) = 90
100
cost(π IndexDup
B,D ) = 0 + 0, 02 · 100 = 2
cost(P) = 1200 + 92 + 90 + 2 = 1384
Jetzt startet die kostenbasierte Suche, indem sie einen neuen Anfragebaum generiert.
Anfangs betrachtet er den untersten Join mit den dazugehörigen Kindern. Dabei
untersucht er die beiden Selektionen und erkennt, daß bei R2 keine Optimierung
durchgeführt werden muß (Index schon vorhanden). Daraufhin wird bei R1 die
Generierung eines sinnvollen Indexes mittels T ree(R) berechnet:
I/O-Kosten CPU-Kosten Ergebnis
page(R1) · log2(page(R1)) |R1| · log2(|R1|) I/O + 0, 02· CPU
1000 · log2(1000) 10000 · log2(10000) (1000 · 9, 966) + (0, 02·
10000 · 13, 288) ≈ 16610
Da die Kosten für den Aufbau eines Indexes auf R1 größer sind als die Gesamtkosten,
wird die Indexierung verworfen. Darüberhinaus wird auch das Sortieren
nicht näher betrachtet, da Indexierung vergleichbare Kosten wie eine Sortierung
aufwirft.
Als nächster Schritt nimmt sich der Algorithmus den darüberliegenden Join und
untersucht ihn auf kostensparendes Einfügen von Funktionen. Dabei wird zuerst
das Hashen der Ergebnisse aus den jeweiligen vorherigen Selektionen berechnet.
Dabei wird zur Berechnung die Selektivität von σR1.A=c(R1) := � R1 benötigt, die
man - wie im Kapitel 4.3.1 erwähnt - aus der Kardinalität des Wertebereichs des
Attributes A bekommt:
q(σA=c(R1)) =
⇔ | � R1| = |R1|
n(A, R1)
1
n(A, R1)
10000
= = 1
10000
Damit hat man folgende Hashkosten für � R1 = σR1.A=c(R1), dabei darf man nicht
vergessen, daß keine I/O-Kosten anfallen, da das Ergebnis aus der relationalen
Selektion gepiplined wird:

6.5. BEISPIEL ZUR KOSTENBASIERTEN SUCHE 89
I/O-Kosten CPU-Kosten Ergebnis
0 | � R1| I/O + 0, 02· CPU
0 1 0 + 0, 02 · 1 ≈ 0
und folgende Hashkosten für � R2 = σ Index
(R2.E=2) (R2):
q(σE=2(R2)) =
⇔ | � R2| = |R2|
n(E, R2)
1
n(E, R2)
= 10000
100
= 100
Vorausgesetzt, daß durchschnittlich 10 Tupel pro Seite gespeichert werden, folgt
dann:
I/O-Kosten CPU-Kosten Ergebnis
page(�R)
55 · | � R| I/O + 0, 02· CPU
10
10
55 100 55 + 0, 02 · 100 ≈ 2
Daraus folgt, daß ein zusätzliches Hashen der Selektionsergebnisse Kosten in Höhe
von 2 Punkten verursacht. Damit könnte man jetzt den Rel-Index-Join durch
einen Hash-Join ersetzen, der folgendes kostet:
I/O-Kosten CPU-Kosten Ergebnis
0 + Scan Rel (Hash( � R2)) q( � R1 ✶�R1.C=�R2.C � R2) · (| � R1| · | � R2|) I/O + 0, 02· CPU
0 + 0 = 0
1
100 · (1 · 100) = 1 (0 + 0, 02 · 1) ≈ 0
Insgesamt würden also für die beiden Hashes gefolgt von dem Hash-Join folgende
Kosten entstehen
0 + 2 + 0 = 2

90 KAPITEL 6. DIE OPTIMIERUNGSSTRATEGIE
Dafür würde man sich den Rel-Index-Join sparen, der folgendes kostet:
I/O-Kosten CPU-Kosten Ergebnis
0 + Scan Index
p (R2) q( � R1 ✶�R1.C=�R2.C � R2) · (| � R1| + | � R2|) I/O + 0, 02· CPU
0 + 90 = 90
Schließlich bekommen wir für diesen Anfragebaum:
Kosten in Höhe von:
1
100 · (1 + 100) ≈ 1 (90 + 0, 02 · 1) ≈ 90
π IndexDup
B,D
✶HashJoin R1.C=R2.C
✪ ❡
✪ ❡
✪
✪
Hash(·) Hash(·)
σ Rel
(R1.A=c)
R1
σ Index
(R2.E=2)
Abbildung 6.12: Kostenoptimierter Anfragebaum
R2
cost(σRel (R1.A=c) ) = 1000 + 0, 02 · 10000 = 1200
cost(σIndex 1
1
(R2.E=2) ) = (50 + min(1000, · 1000 · 4)) + 0, 02 · ( · (10000 + 4)) = 92
100 100
cost(Hash(σRel (R1.A=c) )) = 0 + 0, 02 · 1 ≈ 0
cost(Hash(σIndex 10
1
(R2.E=2) )) = + 0, 02 · 1 · · 100 = 2
55 100
cost(✶ Hash−Join
R1.C=R2.C ) = 0 + 0, 02 · 1 ≈ 0
cost(π IndexDup
B,D
= 0 + 0, 02 · 100 = 2
cost(P) = 1200 + 92 + 0 + 2 + 0 + 2 = 1298
erhalten. Das sind Einsparungen von 86 Punkten (1486 ⇒ 1298).
Somit fügt der Optimierer die beiden Hashfunktionen ein und liefert den verbesserten
Anfragebaum zurück.

Kapitel 7
Die Implementierung des
SQL-Optimierers
Fantasie ist wichtiger als das Wissen,
denn das Wissen ist begrenzt.
Albert Einstein
In diesem Kapitel soll der Anfrageoptimierer SQLOpt vorgestellt werden, der im
Zuge dieser Diplomarbeit programmiert worden ist. Er beinhaltet - in einzelnen
Java-packages - die zur Optimierung benötigten Module, welche wir in den letzten
Kapiteln kennengelernt haben.
Insgesamt sind es 180 Klassen und Interfaces mit aussagekräftigen Namen. Deshalb
sollten kommende Erweiterungen leicht implementierbar sein, da auch viel
Wert auf einen modularen Aufbau gelegt worden ist. Dazu gehören das einfache
Hinzufügen von weiteren Operatoren, als auch Veränderungen an den implementierten
Heuristiken.
In den folgenden Abschnitten werden sowohl die einzelnen Pakete, als auch die
gesamte Hierachie vorgestellt. Dabei sollen aber nur die wichtigsten Klassen und
Interfaces aufgeführt werden, da es sonst den Rahmen dieser Diplomarbeit sprengen
würde. Für weitere Informationen stehen die dazugehörigen Javadocs zur
Verfügung.
7.1 Die Packages des SQL-Optimierers
Um die eindeutige Zuordnung der programmierten Pakete gewährleisten zu können,
wurde - wie in den allgemeinen Java-Formvorschriften vorgegeben - der DNS-
Name des Institutes gewählt. Darunter befindet sich der eigentliche Optimierer
sopt, der wiederum in seine drei Einzelteile zerlegt wurde:
(a) Das Paket gui bietet dem Benutzer eine grafische Eingabemöglichkeit.
91

92 KAPITEL 7. DIE IMPLEMENTIERUNG DES SQL-OPTIMIERERS
(b) Das Paket struc beinhaltet den eigentlichen Optimierer samt Datenstrukturen.
(c) Das Paket sqlp ermöglicht die Eingabe als Standard-SQL- bzw. relationale
Anfrage.
Die wie folgt hierarchisch zueinander stehen: 1
test
de/unihannover/dbs/sopt/...
gui struc sqlp
search alg phys
rules
Abbildung 7.1: Die Packages des SQL-Optimierers
Unterhalb des struc Paketes befinden sich die drei vorgestellten Optimierungsschritte
mit ihren Datenmodellen.
(a) Das Paket alg beinhaltet die anfangs ausgeführte algebraische Optimierung
des Anfragebaumes in einen algebraischen Prototyp. Dafür werden die im
Kapitel 2.1. vorgestellten Regeln im Paket alg.rules benutzt.
(b) Das Paket phys ermöglicht die physische Optimierung der Anfrage hin zu
einem physischen Prototyp.
(c) Das Paket search ist für den letzten Optimierungsschritt verantwortlich.
Dabei werden durch Kostenfunktion verschiedene Pfade verfolgt, die - je
nach Zeitaufwand - selektiert und zurückgeliefert werden.
Schließlich wurde zum Testen des Anfrageoptimierers ein Paket test programmiert.
Darin befinden sich die verschiedenen Heuristiken, die im Laufe der Diplomarbeit
untersucht worden sind.
1 Dabei stellen die Pfeile die Zufriffshierarchie der einzelnen Pakete dar.

7.2. GRAFISCHE BENUTZERSCHNITTSTELLE GUI 93
7.2 Grafische Benutzerschnittstelle GUI
7.2.1 de.unihannover.dbs.sopt.gui
Dieses Paket stellt die grafische Benutzerschnittstelle bereit. Sie ermöglicht die
Eingabe einer Anfrage in einem editierbaren Fenster (siehe Abbildung 7.7). Alle
weiteren Optimierungsfenster sind modal programmiert und bieten zusätzlich
dazu noch die Möglichkeit zur Vergrößerung der Ansicht.
AbstractListModel
AbstractTableModel
JPanel
JComponent
AttributeSetListModel
AttributeValueCountTableModel
MetaDataTableModel
TableTableModel
AttributeSetList
TableTable
TressTextArea
Package de.unihannover.dbs.sopt.gui
TreeCostTextArea
JDialog
AttributeAddDialog
AttributeEditDialog
AttributeValueCountEditDialog
IndexAddDialog
IndexDataDialog
InfoDialog
MetaDataTable MetaDataDialog
SearchDialog
TableAddDialog
TableDataDialog
TableEditDialog
Abbildung 7.2: Das GUI Package des SQL-Optimierers
Die grafische Schnittstelle bietet mittels des Buttons Relationen die Möglichkeit,
Relationen und die dazugehörigen Attribute festzulegen. Bei der Übernahme der
Eingabe werden die Objekte dann erzeugt. Dazu sind noch weitere Eingabefenster
vorhanden; darunter die Maske für das Erzeugen der Metadaten der vorher
festgelegten Relationen (siehe Abbildung 7.3. und 7.4.).

94 KAPITEL 7. DIE IMPLEMENTIERUNG DES SQL-OPTIMIERERS
Klassen:
Abbildung 7.3: Relationenfenster des SQL-Optimierers
• AttributeSetListModel
Diese Klasse stellt ein GUI-Model für Attributmengen dar.
• AttributeValueCountTableModel
Diese Klasse stellt ein GUI-Model für ” n(A, R)“-Metadaten dar.
• MetaDataTableModel
Diese Klasse stellt ein GUI-Model für Metadaten dar.
• TableTableModel
Diese Klasse stellt ein GUI-Model für Tabellen und Indexe dar.
***
• AttributeSetList
Diese Klasse stellt ein GUI-Element für Attributmengen dar.
• MetaDataTable
Diese Klasse stellt ein GUI-Element für die Metadaten einer Relation dar.
• TableTable
Diese Klasse stellt ein GUI-Element für Tabellen und Indexe dar.

7.2. GRAFISCHE BENUTZERSCHNITTSTELLE GUI 95
Abbildung 7.4: Metadatenfenster des SQL-Optimierers
***
• TreeTextArea
Mit dieser Klasse wird ein Container für die jeweiligen Anzeigen der Baumdarstellungen
geboten. Er ist nicht editierbar und kann zusätzlich dazu in
einen eigenen Dialog vergrößert werden.
• TreeCostTextArea
Diese Klasse bietet als modifizierte TreeTextArea zusätzlich noch die Anzeige
der Gesamtkosten des dargestellten Baumes.
***
• AttributeAddDialog
Diese Klasse stellt ein GUI-Element zur Eingabe von Attributmengen dar.
• AttributeEditDialog
Diese Klasse stellt einen Dialog zur Bearbeitung von Attributmengen dar.
• AttributeValueCountEditDialog
Diese Klasse stellt einen Dialog zur Bearbeitung von ” n(A, R)“-Metadaten
dar.

96 KAPITEL 7. DIE IMPLEMENTIERUNG DES SQL-OPTIMIERERS
• IndexAddDialog
Ein Unterdialog von TableEditDialog zum Hinzufügen eines Indexes für
eine Tabelle.
• IndexDataDialog
Ein Unterdialog von TableEditDialog zum Bearbeiten der Daten eines
Indexes.
• InfoDialog
Diese Klasse wird aufgerufen, wenn der Benutzer den Info-Button drückt.
Sie beinhaltet online Informationen zur Benutzung des Programmes.
• MetaDataDialog
Diese Klasse stellt einen Dialog zur Bearbeitung von Metadaten dar.
• SearchDialog
In diesem Programmabschnitt werden die gewünschten Suchparameter übergeben,
so daß je nach Wunsch ein CPU-Constraint-System oder ein I/O-
Constraint-System simuliert wird.
• TableAddDialog
Ein Unterdialog von TableEditDialog zum Hinzufügen einer Tabelle.
• TableDataDialog
Ein Unterdialog von TableEditDialog zum Bearbeiten der Daten einer
Tabelle.
• TableEditDialog
Diese Klasse stellt einen Dialog zur Bearbeitung von Tabellen und Indexen
dar.
7.3 Der Relationale Anfrageparser
7.3.1 de.unihannover.dbs.sopt.sqlp
Die in SQL bzw. in relationaler Form eingegebene Anfrage muß anfangs so verarbeitet
werden, daß der nachfolgende Optimierer sie weiterbenutzen kann. Für
diesen speziellen Zweck wurde ein Parser programmiert, der dem Benutzer die
grafische Eingabe ermöglichen soll und dessen Input dann in die passende Datenstruktur
umwandelt.
In der vorliegenden Realisierung werden bislang SPJ-Anfragen vollständig verarbeitet.
Der komplette Sprachumfang von SQL konnte aus Zeitgründen nicht
hundertprozentig simuliert werden, dafür wird die gesamte Ausdrucksstärke der
Relationalen Algebra verstanden. Darüberhinaus können durch den modularen

7.3. DER RELATIONALE ANFRAGEPARSER 97
Aufbau des Übersetzers spätere Erweiterungen der Anfragesprache leicht implementiert
werden.
Folgendes Beispiel soll die pseudo SQL-Anfragemöglichkeit des Anfrageparsers
darstellen:
SELECT S.Semester
FROM ((S PRODUCT H) PRODUCT V) PRODUCT P
WHERE P.Name = ’Sokrates’ AND
V.VorlNr = H.VorlNr AND
V.gelesenVon = P.Name AND
H.MatrNr = S.MatrNr
Der Befehl PRODUCT mußte zusätzlich eingeführt werden, da standardmäßig eine
mit Komma getrennte Eingabe von Relationen sofort in Joins umgesetzt wird.
Um dabei komform mit der SQL-Sprache zu bleiben und zusätzlich dazu den
Optimierer die Möglichkeit zu geben, auf Produkten arbeiten zu können, wurde
das genannte Kürzel eingeführt.
Für den relationalen Anfrageparser muß die Anfrage wie folgt aussehen:
(PROJECTION
S.Semester
(SELECTION
(AND P.Name=’Sokrates’ V.VorlNr=H.VorlNr
V.gelesenVon=P.Name H.MatrNr=S.MatrNr)
(PRODUCT (PRODUCT (PRODUCT S H) V) P)))
Dabei ist noch zu erwähnen, daß die relationale Anfragsprache in etwa der Syntax
der Programmiersprache Scheme entspricht.
Interfaces:
• AlgebraicParser
Dieses Interface definiert eine allgemeine Schnittstelle für Parser, die als
Zeichenketten kodierte algebraische Bäume in das benötigte Datenmodell
übersetzt.
Klassen:
• RelationalParser
Diese Klasse ist eine Implementation von AlgebraicParser. Er benutzt
eine Scheme-artige Syntax, die das komplette Datenmodell unterstützt.
• SQLParser
Diese Klassse ist eine Implementation von AlgebraicParser. Er benutzt
eine SQL-artige Syntax, die nur einen Teil des Datenmodells unterstützt.

98 KAPITEL 7. DIE IMPLEMENTIERUNG DES SQL-OPTIMIERERS
Exception:
• ParseException
Signalisiert, daß ein Fehler während des Parsens aufgetreten ist.
7.4 Datenstruktur des Anfrageoptimierers
Nachdem der Anfrageparser die Eingabe zerlegt hat, müssen jetzt die benötigten
Objekte erzeugt werden, mit denen man die Anfrageoptimierung simulieren
möchte. Aus diesem Grund beinhaltet dieses Package Klassen und Interfaces zur
Modellierung der Datenstruktur algebraischer Bäume (siehe Abbildung 7.5).
7.4.1 de.unihannover.dbs.sopt.struc.alg
Interfaces:
• Relation
Dieses Interface definiert einen Knoten im algebraischen Baum, wie eine
Table, eine Selection oder auch eine Union.
• CommutativeRelation
Dieses Interface erbt von Relation und beschreibt kommutative Relationen.
• Condition
Dieses Interface beschreibt abstrakte Bedingungen.
• AtomicCondition.Theta
Dieses Interface definiert mathematische Prädikate, wie , ≤, ≥.
Klassen:
• Attribute
Diese Klasse repräsentiert ein einzelnes Attribut.
• AttributeSet
Diese Klasse repräsentiert eine Menge von Attributen, wie zum Beispiel das
Schema einer Relation oder die Attributmenge einer Condition.
• AlgebraicTree
Diese Klasse stellt den zu optimierenden algebraischen Baum dar und kann
als Kopfzelle der Baumdatenstruktur verstanden werden.
***

7.4. DATENSTRUKTUR DES ANFRAGEOPTIMIERERS 99
• Table
Diese Implementation einer Relation repräsentiert als Blatt der Baumdatenstruktur
eine Tabelle innerhalb der Datenbank.
***
• Selection
Diese Implementation einer Relation repräsentiert die Selektion einer Relation
nach einer bestimmten Condition.
• Projection
Diese Implementation einer Relation repräsentiert die Projektion einer
Relation mit einem bestimmten AttributeSet.
• Join
Diese Implementation einer Relation repräsentiert den Verbund zweier
Relations unter einer bestimmten Condition.
***
• Difference
Diese Implementation einer Relation repräsentiert die Differenz zweier
Relations.
• Intersection
Diese Implementation einer Relation repräsentiert den Schnitt zweier Relations.
• Product
Diese Implementation einer Relation repräsentiert das Produkt zweier
Relations.
• Union
Diese Implementation einer Relation repräsentiert die Vereinigung zweier
Relations.
***
• AbstractCondition
Diese abstrakte Implementierung von Condition bietet insbesondere eine
Methode zur Überprüfung, ob das Objekt eine Joinbedingung ist.
• AtomicCondition
Diese Implementierung von Condition repräsentiert die atomaren Bedingungen,
wie zum Beispiel ” R1.A = 4“ oder ” R1.c = R2.c“.
• AND
Diese Implementierung von Condition beschreibt das logische Und einer

100 KAPITEL 7. DIE IMPLEMENTIERUNG DES SQL-OPTIMIERERS
PhysicalRelation
Package de.unihannover.dbs.sopt.struc
struc.phys struc.alg
Appraisable PhysicalTree
PhysicalTable
AppraisableProjection
AppraisableSelection
AppraisableJoin
struc.alg
AttributeCondition
Selection
Condition
Join
Difference
Table
Projection
Selection
Join
AND OR NOT AtomicConditionTheta
Relation
AttributeSet
AtomicCondition Attribute
AlgebraicTree
Relation
CommutativeRelation
Projection
Abbildung 7.5: Abhängigkeitsgraph der Klassen aus sopt.struc
Product
Union
Intersection
erbt nach
benutzt
Interface
Klassen
Packagegrenzen

7.4. DATENSTRUKTUR DES ANFRAGEOPTIMIERERS 101
Liste von Conditions.
• OR
Diese Implementierung von Condition beschreibt das logische Oder einer
Liste von Conditions.
• NOT
Diese Implementierung von Condition beschreibt das logische Nicht einer
Condition.
7.4.2 de.unihannover.dbs.sopt.struc.alg.rules
Dieses Paket beinhaltet Strukturen und Implementierungen für Regeln zur Optimierung
algebraischer Bäume (siehe Abbildung 7.5).
Interfaces:
• Rule
Dieses Interface definiert eine Regel zur Optimierung eines algebraischen
Baumes.
Klassen:
• AbstractRule
Diese abstrakte Implementation von Rule enthält zusätzliche Methoden zur
Vereinfachung lokaler Optimierungen.
Zusätzlich dazu findet man in diesem Paket die Implementierungen, der in Kapitel
2.1 vorgestellten Ersetzungsregeln a) - t) wie z. B. ARule.
***
7.4.3 de.unihannover.dbs.sopt.struc.phys
Dieses Paket erweitert die Datenstruktur algebraischer Bäume um physische Operatoren
zum Datenmodell für physische Bäume (siehe Abbildung 7.6).
Interfaces:
• Appraisable 2
Beschreibt ein Element innerhalb der Kostenoptimierung. Dabei bietet es
die Möglichkeit sowohl die lokalen Kosten des Knotens, als auch rekursiv
die Kosten des gesamten Teilbaumes zur erhalten.
2 Wann immer eine abstrakte Klasse in Zukunft einen Kostenwert beinhalten soll, wird er
als appraisable (bewertbar) definiert.

102 KAPITEL 7. DIE IMPLEMENTIERUNG DES SQL-OPTIMIERERS
• PhysicalRelation
Dieses Interface erweitert Relation um physische Eigenschaften (wie |R|,
Index(R) oder n(A, R)) und Berechenbarkeit (Appraisable).
Klassen:
• MetaData
Diese Klasse beschreibt die benötigten Metadaten einer Relationen, als ” Ersatz“
für das Datenbank-Management-System.
• PhysicalTree
Diese Klasse erweitert den AlgebraicTree zum physischen Bäume.
• Transformer
Diese Klasse transformiert einen algebraischen Baum (AlgebraicTree) in
einen physischen Prototypen (PhysicalTree). Sie beinhaltet somit die physische
Heuristik zur Optimierung eines Anfragebaumes.
***
• PhysicalTable
Diese Klasse erweitert Table um physische Eigenschaften und Berechenbarkeit
(Appraisable).
***
• AppraisableJoin
Diese physische Erweiterung einer algebraischen Joins implementiert als
abstrakte Klasse einen Großteil der Eigenschaften eines physischen Joins.
• AppraisableProjection
Diese physische Erweiterung einer algebraischen Projection implementiert
als abstrakte Klasse einen Großteil der Eigenschaften einer physischen Projektion.
• AppraisableSelection
Diese physische Erweiterung einer algebraischen Selection implementiert
als abstrakte Klasse einen Großteil der Eigenschaften einer physischen Selektion.
***
• IndexSelection
Diese Klasse stellt die Selektion mit Hilfe eines Indexes dar.
• RelSelection
Diese Klasse beschreibt die relationale Selektion.

7.4. DATENSTRUKTUR DES ANFRAGEOPTIMIERERS 103
Join
Projection
Selection
Table
AlgebraicTree
CommutativeRelation
PhysicalRelation
Appraisable
Relation
Package de.unihannover.dbs.sopt.struc.phys
AppraisableJoin
AppraisableProjection
AppraisableSelection
PreExecuted
PhysicalTable
AntiJoin
AntiSemiJoin
HashJoin
IndexJoin
LeftOuterJoin
MergeJoin
NestedLoopJoin
RightOuterJoin
SemiJoin
IndexDupProjection
NestedDupProjection
SortedDupProjection
IndexSelection
RelSelection
Hash
Pipeline
Sort
Tree
Transformer
PhysicalTree MetaData
LeftRightOuterJoin
IndexIndexJoin
RelIndexJoin
Abbildung 7.6: Abhängigkeitsgraph der Klassen aus sopt.struc.phys
Interfaces
Klassen
erbt von

104 KAPITEL 7. DIE IMPLEMENTIERUNG DES SQL-OPTIMIERERS
• IndexDupProjection
Diese Klasse implementiert eine Index-Projektion.
• NestedDupProjection
Diese Klasse beinhaltet die Beschreibung einer Projektion mit Hilfe einer
einfachen Duplikateliminierung.
• SortedDupProjection
Diese Klasse stellt die Projektion mit Hilfe einer Sortierung dar.
Zusätzlich dazu findet man in diesem Paket die Implementierungen, der in Kapitel
3 vorgestellten Verbundoperatoren wie z. B. HashJoin.
Als nächstes folgen die Optimierungsfunktionen, die bei der physischen bzw. kostenbasierten
Optimierung benötigt werden. Da sie vor einem SPJ-Operator eingefügt
werden, wurden sie als PreExecuted implementiert:
***
• PreExecuted
Diese besondere physische Relation beschreibt Operationen wie Pipelines,
Sortierungen oder Indexierungen.
• Hash
Diese Klasse beschreibt den Aufbau eines Hashes.
• Sort
Diese Klasse beschreibt die Sortierung einer Relation.
• Tree
Diese Klasse beschreibt den Aufbau eines sortierten Indexbaumes über eine
Relation.
• Pipeline
Diese Klasse stellt ein Pipelining zwischen zwei Operationen dar.
7.4.4 de.unihannover.dbs.sopt.struc.search
Dieses Paket besitzt Klassen und Interfaces, die die Suchstrategie zur Gewinnung
des optimalen Anfragbaumes darstellen sollen. Man kann sogar der Combined-
Optimizer Klasse die Reihenfolge von verschiedenen Optimierungsmethoden vorgeben,
die dann nacheinander oder parallel ausgeführt werden.
Interfaces:
• CostBasedOptimizer
Dieses Interface beschreibt einen Kostenbasierten Optimierer.

7.5. DIE TESTSCHNITTSTELLE 105
Klassen:
• CombinedOptimizer
Ein kostenbasierter Optimierer, der eine Folge anderer Optimierer nacheinander
ausführt.
• Builder
Fügt lokal eine Sortierung, Indexierung bzw. Partitionierung zur Verbesserung
ein, indem er die ursprünglichen mit den neuen Kosten vergleicht.
(Die Klasse Builder beschreibt, den in Kapitel 6 vorgestellten Optimierer.)
• Indexer
Fügt anfangs für jede Tabelle Trees ein, um sie danach einzeln - je nach
Nutzen - wieder zu entfernen.
7.5 Die Testschnittstelle
7.5.1 de.unihannover.dbs.sopt.test
Die Testschnittstelle beinhaltet alle zusätzlichen Klassen, die dem Benutzer das
Simulieren der Anfragen ermöglichen.
Klassen:
• SQLOpt
Die Startklasse des SQL- bzw. Relationalen-Optimierers.
7.6 Benutzerhandbuch
Auf der beigelegten CD-ROM befinden sich neben einer digitalen Kopie der Diplomarbeit
auch die Source-Dateien mit der dazugehörigen Dokumentation zum
SQL-Optimierer.
7.6.1 Starten des SQL-Optimierers
Der SQL-Optimierer benötigt ein installiertes Java Runtime Environment ab der
Version 1.4.1. Zum Aufruf des Programmes muß nur im SQL-Optimierer Verzeichnis
folgender Startbefehl eingegeben werden:
java -jar SQLOpt für den SQL-Parser
java -jar RelOpt für den Relationalen-Parser

106 KAPITEL 7. DIE IMPLEMENTIERUNG DES SQL-OPTIMIERERS
Abbildung 7.7: Startfenster des SQL-Optimierers
Danach öffnet sich automatisch die Eingabemaske, in der man links oben die Anfrage
eingeben kann. Nach Betätigen der einzelnen Buttons, die sich im rechten
Fenster befinden, werden die jeweiligen Optimierungsschritte ausgeführt. Je nach
Wahl wird entweder nur eine 1:1-Übersetzung, Algebraische-, Physische- oder eine
Kostenbasierte Optimierung durchgeführt. Da die Optimierungsschritte voneinander
abhängig sind, werden benötigte Optimierungen automatisch ausgeführt,
so daß ein sofortiges Starten der Kostenbasierten Optimierung auch die anderen
Methoden aufruft.
Nicht zu vergessen sind die Relationen, die man nach dem Drücken des dazugehörigen
Knopfes in einer Eingabemaske definieren kann. Im Metadatenfenster
können daraufhin die benötigten Zusatzinformationen festegelegt werden. Schließlich
vervollständigt das Suchparameterfenster den Optimierer, in dem es dem Be-

7.6. BENUTZERHANDBUCH 107
nutzer die Simulation eines I/O-Constraint oder CPU-Constraint-Systems durch
die Wahl eines sinnvollen Proportionalitätsfaktors ermöglicht.

108 KAPITEL 7. DIE IMPLEMENTIERUNG DES SQL-OPTIMIERERS

Kapitel 8
Ausblick
Ich habe keine besondere Begabung, sondern
bin nur leidenschaftlich neugierig.
Albert Einstein
• Entwicklung eines leistungsfähigeren Kostenmodells
Nach der Entwicklung dieser Diplomarbeit wurde eines sofort klar; das
gewählte Kostenmodell, welches auf der Dokotorarbeit von Utesch [54] basierte,
hätte grundsätzlich neu entwickelt werden müssen. Nicht nur, daß
manche Formeln, wie sie in der Literatur wiederzufinden sind, kein richtiges
Ergebnis liefern, sie werden auch nach der Korrektur der Funktionen den
Ansprüchen, die man an ein sinnvolles Kostenmodell stellt, nicht gerecht.
Das Utesch-Modell entspricht eigentlich nur einem Input-Kostenmodell, da
es keinerlei Output-Kosten betrachtet. Zwar kann man annehmen, daß jegliche
Outputkosten einer Operation gleich der Inputkosten des nächsten
Knotens sind und deshalb nur einmal berechnet werden müssen (der letzte
Knoten kostet bei allen Anfragebäumen immer gleich), aber durch die vielen
verschiedenen Variablen wäre eine feinere Auflösung des Kostenmodells
in Input-Kosten, Output-Kosten und CPU-Kosten besser gewesen.
Zusätzlich dazu fallen die CPU-Kosten in keinem der bislang berechneten
Fälle ins Gewicht, da sie in Relation zu den I-Kosten nur einen sehr kleinen
Bruchteil ausmachen und somit für den Entscheidungsprozeß nicht wichtig
sind. Deshalb sollte man, bei einer Weiterführung dieses Themas das
vorliegende Kostenmodel an die jeweiligen neuen Anforderungen anpassen.
• Vergleich des entwickelten Optimierers mit den existierenden Implementierungen
(Oracle, MySQL, DB2 usw.)
Als nächsten Punkt muß man die etwas knapp bemessene Zeit ansprechen,
die sich im Laufe der Diplomarbeit bewahrheitete. Somit wurden Erweiterungen,
die nicht Bestandteil der Aufgabenstellung der Diplomarbeit
waren, größtenteils weggelassen. Darunter fiel die erhoffte Leistungsanalyse
des SQL-Optimierers mit Hilfe des in Kapitel A vorgestellten Oracle-
109

110 KAPITEL 8. AUSBLICK
Optimierers.
In Java hat man durch die JDBC-Schnittstelle die Möglichkeit, Anfragen
an die Datenbank zu stellen, ohne daß sie weiter optimiert werden. Somit
wäre eine interessante Analyse der verschiedenen Optimierungstechniken
möglich gewesen, da man auch ein von Oracle genutztes Kostenmodell als
Vergleichsoperator besitzen würde.
• Untersuchung der neu entwickelten Heuristiken mit verschiedenen
Datentypen
Bei der Implementierung wurde das gesamte Potential der algebraischen
- wie auch der physischen Heuristik - nicht vollständig ausgelotet. Nach
ein paar Bespielen und dem Test der korrekten Optimierung wurde eine
spezielle Analyse der verschiedenen Prototypen nicht mehr angegangen.
Dieses Gebiet bietet deshalb noch viel Freiraum für Forschung. Zwar sind
die algebraischen Methoden begrenzt, aber dafür kann durch die physischen
Heuristiken noch viel an zusätzlicher Optimierungszeit eingespart werden.
• Erweiterung des SQL- bzw. des Relationalen Parsers
Durch den modularen Aufbau der geforderten Implementierung des SQL-
Optimierers, ist ein Ausbau des Simulators auf spezielle Gebiete leicht
möglich. Dafür kann die Anfragesprache auf den kompletten Sprachumfang
von SQL erweitert werden. Im Gegensatz dazu bietet der Relationale
Parser schon jetzt viele Möglichkeiten, verschachtelte Anfragen zu stellen.
Abschließend sollte man erwähnen, daß ein Teil der Literatur, die für diese Diplomarbeit
genutzt wurde, lückenhaft war. Aus diesem Grund mußte vieles durch
eigene Forschung wieder ausgeglichen werden. Darunter die genauen Angaben der
verschiedenen Iteratoren und die Heuristiken, deren Ausarbeitung bislang in keinem
Buch in dieser Form zu finden ist. Dies war zwingend notwendig geworden,
da sich sonst diese Diplomarbeit nicht hätte realisieren lassen können. Somit
richtete sich ein Großteil der Bemühungen auf die Schaffung neuer Erkenntnisse.
Gerade deswegen wäre die weitere Untersuchung dieses Themas in Richtung einer
Dissertation ein lohnendes Ziel.

Anhang A
Der Oracle Optimierer
Freude am Schauen und Begreifen
ist die schönste Gabe der Natur.
Albert Einstein
Der Oracle-Optimierer 1 als Komponente des Datenbankservers hat die Aufgabe,
für einen gegebenen SQL-Befehl den möglichst besten (d.h. kostengünstigsten,
schnellsten) Zugriffsplan zu ermitteln. Er ist für die Umsetzung der Mengenoperationen,
wie sie in SQL-Befehlen einer Anwendung formuliert sind, in konkrete
Zugriffsoperationen verantwortlich.
Weil jede relationale Operation im Prinzip in verschiedene Zugriffsspläne umgesetzt
werden kann, diese jedoch z. B. abhängig von der Menge der Daten zu
unterschiedlichen Laufzeiten führen können, ist die Leistungsfähigkeit des Optimierers
für jedes relationale Datenbanksystem von entscheidender Bedeutung.
Der in Oracle implementierte Optimierer kann nach den folgenden drei Methoden
arbeiten:
• Regelmethode (rule based optimizer)
• Statistische Methode (cost base optimizer)
• Statistische Methode mit Hinweisen (cost based optimizer with hints)
A.1 Rule based optimizer
Die Regelmethode ist die Standardmethode, die schon zur Zeit von Oracle 6
eingeführt wurde und seitdem ein fester Bestandteil des Optimierers ist. Die
Optimierung erfolgt dabei nach einem festen Regelwerk, wofür Informationen
aus dem Data Dictionary (z. B. Informationen über indizierte Spalten) zugrunde
gelegt werden.
1 Wir betrachten hier den Oracle 9i-R2 Optimierer.
111

112 ANHANG A. DER ORACLE OPTIMIERER
In der folgenden Tabelle ist das Bewertungsschema, das sogenannte ” Rankingschema“,
dargestellt, auf dessen Basis der regelbasierte Optimierer die SQL-
Befehle oder ihre Prädikate klassifiziert.
Das am höchsten klassifizierte Prädikat und der Index im Zusammenhang mit
diesem Prädikat steuern dann die Zugriffe auf die betreffende Tabelle. Natürlich
kann man als letzte sinnvolle Methode einen kompletten Tabellendurchlauf durchführen
( ” Full Table Scan“):
1 Ein Datensatz über rowid
2 Ein Datensatz über Cluster-Join = Konstante
3 Ein Datensatz über Hash-Cluster mit eindeutigem Index = Konstante
4 Ein Datensatz über eindeutigen Index = Konstante
5 Cluster Join auf geclusterten Tabellen
6 Hash-Cluster-Schlüssel
7 Cluster-Index auf eine Tabelle
8 Zusammengesetzter Index = Konstante
9 Einfacher Index = Konstante
10 Index range scan mit festen Grenzen
11 Index range scan ohne festen Grenzen
12 sort / merge Join
13 Max / Min auf Indexspalten
14 Order by mit vollständigem Index
15 Full Table Scan
Tabelle A.1: Rule based optimizer
A.2 Cost based optimizer
Die statistische Methode wird in den Fällen gewählt, in denen sich die Zugriffstrukturen
nicht als trivial herausstellen. Sie bedingt aber das Vorliegen einer
aktuellen Tabellenstatistik, die explizit aufgestellt werden muß.
Damit die Statistiken den laufenden Betrieb nicht behindern, werden sie typischerweise
nur auf expliziten Wunsch des DB-Administrators aktualisiert (in
Oracle mit dem Kommando analyse).
Im einzelnen umfaßt diese Optimierungsmethode folgende drei Unterpunkte:
• Generierung aller möglichen Zugriffspfade
• Berechnung der Kosten für jeden möglichen Zugriffspfad durch Einbeziehung
der gespeicherten Statistiken. Die Kosten beziffern die zu erwartende
Nutzung von Ressourcen, z. B. I/O-Operationen, Hauptspeicherbedarf und
die CPU-Zeit.
• Der Plan mit den geringsten Kosten wird ausgewählt.

A.3. COST BASED OPTIMIZER MIT HINTS 113
Die Methoden können sowohl global für die gesamte Datenbank gewählt werden
als auch auf Sessionebene - durch ein alter session-Statement. Auf Befehlsebene
besteht die Möglichkeit der Nutzung von Hinweisen (hints).
Problematisch kann ein Fehlen oder das Alter einer Statistik sein. Falls keine
vorhanden ist, wird nur regelbasiert optimiert. Bei veralteten Statistiken wird
weiterhin nach ihnen ” optimiert“, was zu schlechten Zugriffsplänen führen kann.
A.3 Cost based optimizer mit hints
Zur manuellen Optimierung werden zusätzlich Hints verwendet. Wenn der Ausführungspfad
eines Kommandos analysiert ist und der speziell in der gewünschten
Situation optimale Zugriffspfad durch Tests ermittelt ist, bieten Hints die
Möglichkeit, diesen Zugriffspfad für dieses Statement zu fordern.
werden.
Oracle-Hints in SQL-Statements beeinträchtigen die Portabilität nicht, da sie von
anderen SQL-Interpretern als Kommentare interpretiert werden.
Die am meisten genutzten Hints sind:
1) cost - fordert den Statistik-Optimierer für das Statement
2) rule - fordert den regelbasierten Optimierer
3) full [(table name)] - fordert einen Full Table Scan (auf eine bestimmte Tabelle)
4) rowid [(table name)] - fordert den Zugriff über rowid, falls möglich
5) index [(table name [index name])] - fordert den indizierten Zugriff, ggf. über
den angegebenen Index
6) ordered - fordert einen Join in der Reihenfolge der Tabelle in der from-Klausel
(Umkehrung des regelbasierten Modus, also von rechts nach links)
7) use nl, use merge, use hash - fordert explizit nested loop-, sort/merge- oder
Hash Join
8) star transformation - fordert die Berücksichtigung einer Star-Transformation
A.4 Statistiken
Tabelle A.2: Cost based optimizer mit hints
Das Kostenmodell des kostenbasierten Optimierers kann aber nur dann vernünftig
funktionieren, wenn entsprechende Statistikdaten über die Datenbank zur
Verfügung stehen. Diese werden im allgemeinen weder automatisch erstellt noch
bei Datenbankänderungen aktualisiert.

114 ANHANG A. DER ORACLE OPTIMIERER
Bei Oracle muß der Datenbankadministrator die Generierung selbständig anstoßen.
Dazu bedient er sich des Befehls:
analyze table . . . compute statistics for table;
Auf diese Art werden dann alle Datenbankstrukturen (Relationen und Indexe)
analysiert. Es ist sinnvoll, diese Analysen periodisch zu wiederholen, da der Optimierer
nur dann vernünftig arbeitet, wenn die Daten aktuell bleiben.
Diese Daten werden dann in die dafür vorbereitete Relation geschrieben; dem
sogenannten Data Dictionary, in dem auch Schemainformationen verwaltet und
gespeichert werden.
Falls man dennoch schlechte Ausführungspläne bekommt, kann man sie sich auch
anzeigen lassen. Oracle 9i bietet dafür den Befehl
explain plan for . . .
an, der einem zusätzlich die Kosten angibt. Dabei bietet Oracle auch eine graphische
Benutzerschnittstelle an, in der Auswertungspläne als Anfragebäume dargestellt
werden.
A.5 Standardeinstellungen des Optimierers
Die systemweite Voreinstellung für den Oracle-Optimierer ist der Modus CHOOSE.
Dieser Modus veranlaßt den Optimierer, für eine SQL-Anweisung zwischen dem
regelbasierten und kostenbasierten Ansatz zu wählen. Enthält das Data Dictionary
statistische Daten für mindestens eine der in der Anfrage vorkommenden
Tabellen, auf die von einer Anfrage zugegriffenen wird, so verwendet der Optimierer
den kostenbasierten Ansatz und optimiert mit dem Ziel des höchsten
Datendurchsatzes (ALL ROWS). Enthält das Data Dictionary keine statistischen
Daten für die Anfragetabellen, verwendet der Optimierer den regelbasierten Ansatz
RULE.
Dabei kann der Optimierungsmodus vom Benutzer mit folgenden SQL-Befehlen
gewählt werden:
alter session set optimizer goal = ALL ROWS | FIRST ROW | CHOOSE | RULE
Wird explizit der Modus RULE angegeben, erfolgt stets eine regelbasierte Optimierung.
Vorhandene Statistiken werden vom Optimierer nicht berücksichtigt.

A.6. INDEXE 115
A.6 Indexe
Indexe sind optionale Zugriffspfade auf Tabellen und Cluster. Sie erhöhen die
Bearbeitungsgeschwindigkeit für Anfragen, die z. B. nur einen kleinen Teil der
Datensätze einer Tabelle betreffen oder die mit Hilfe der indexierten Spalten
einen Verbund berechnen. Die häufigste Datenstruktur für einen Index ist der
B*-Baum. Daneben gibt es in Oracle Bitmap-Indexe; sie basieren auf invertierten
Bytefolgen der Schlüssel sowie B*-Bäumen und Hashtabellen für Cluster.
Indexe sind logisch und physikalisch unabhängig von der zugehörigen Tabelle.
Genauer gesagt ist das Erzeugen bzw. Löschen eines Indexes jederzeit ohne Auswirkung
auf die zugehörige Tabelle oder einen anderen Index möglich.
Nach der Erzeugung eines Indexes wird dieser vom Datanbankmanagement automatisch
benutzt und bei Änderungen der Tabelle aktualisiert.
Die einfachste Syntax des create index-Kommandos lautet:
create index
on ( . . .)
Schließlich können Indexe einfach mit dem drop index- Kommando gelöscht
werden.

116 ANHANG A. DER ORACLE OPTIMIERER

Anhang B
Das, wobei unsere Berechnungen
versagen, nennen wir Zufall.
Albert Einstein
Konventionen dieser Arbeit
Typographische Konventionen
In dieser Diplomarbeit werden folgende typographische Konventionen verwendet:
• Package-, Klassen- und Variablennamen und SQL-Befehle werden in
Schreibmaschinenschrift gesetzt.
• Variablen und Formeln für die jeweils ein entsprechender Wert eingesetzt
werden muß, werden im mathematischen Modus angegeben.
• Originalbezeichnungen aus dem Englischen wurden so weit wie möglich ins
Deutsche übersetzt. Dort wo es keinen Sinn ergibt, wurde auf eine Neuformulierung
verzichtet.
117

118 ANHANG B. KONVENTIONEN DIESER ARBEIT

Anhang C
Das Einzige, das mir klar ist:
Gott würfelt nicht!
Albert Einstein
Weblinks zu dieser Diplomarbeit
Am Anfang der Diplomarbeit stand die Internetrecherche, die den Einstieg zu
dem vorgebenen Thema sehr vereinfachte, da die meisten Bücher noch nicht lieferbar
waren. Somit waren die nachfolgenden Vorlesungen, Diplomarbeiten und
Dissertationen Hauptliteratur der Einarbeitungsphase. Später wurden sie meistens
durch gedruckte Literatur fundiert. Aus diesem Grund werden hier nur
kurz ein paar deutsche Links aufgeführt, die eine spätere Analyse des Themas
unterstützen könnten.
Vorlesungen:
• http://lwi2.wiwi.uni-frankfurt.de/lehre/vorlesungen/bed/ws0001/
anfrageoptimierung2.pdf
http://www.wi.uni-trier.de/lehre/Skripte/Vossen/modul15.pdf
Die Online Version der Vorlesung von Herrn Prof. Dr. Gottfried Vossen.
• http://www.mathematik.uni-marburg.de/~seeger/vor02SSopti2.shtml
Eine komplette Vorlesung mit dazugehöriger Übung von Herrn Prof. Dr. Bernhard Seeger
zum Thema Anfrageoptimierung.
• http://www.upb.de/cs/info-cd/vorlesungen/boettcher/dabas99/dbs99k4n.html
Die Online Version der Vorlesung von Herrn Prof. Stefan Böttcher.
• http://www.db.fmi.uni-passau.de/~kossmann/DPDB98/dynamic.ps
http://www3.informatik.tu-muenchen.de/lehre/SS2001/DBSother-kossmann/
geodb5.pdf
http://www.db.fmi.uni-passau.de/~kossmann/IMPL99/week9.ps
Die Online Version der Vorlesung von Herrn Prof. Dr. Donald Kossmann über ” Dynamische
Anfrageoptimierung“.
• http://wwwdbis.informatik.uni-kl.de/courses/VDBS/SS2002/
Vorlesungsunterlagen/Kapitel.04.pdf
Die Online Version der Vorlesung von Herrn Prof. Dr. Theo Härder über ” Datenallokation
in verteilten und parallelen DBS“.
119

120 ANHANG C. WEBLINKS ZU DIESER DIPLOMARBEIT
• http://www.informatik.uni-freiburg.de/~dbis/lehre/db-ws0001/
http://www.informatik.uni-freiburg.de/~dbis/lehre/gis-ws9900/folien/
PowerPoint/vDBAnfrage.ppt
Die Online Version der Vorlesung von Herrn Prof. Dr. Georg Lausen über ” Anfrageoptimierung
in verteilten Datenbank-Systemen“.
• http://cis.cs.tu-berlin.de/Lehre/WS-0102/Sonstiges/db-pages/FolienVL/
vl5vl6.pdf
http://cis.cs.tu-berlin.de/Lehre/WS-0203/Sonstiges/db-pages/FolienVL/
vl06-4.pdf
Die Online Version der Vorlesung von Herrn Prof. Dr. Herbert Weber.
• http://pi3.informatik.uni-mannheim.de/lehre/vorlesungen/dbImplSkript/
part1.ps.gz
Eine Vorlesung von Herrn Prof. Dr. G. Markoette zur ” Implementierung von Datenbanksystemen“.
• http://www.db.fmi.uni-passau.de/publications/books/DBMSeinf/EIS/
Kapitel8.pdf
http://www.db.fmi.uni-passau.de/lehre/SS02/VDBMS/Teil3.ppt
Eine 146 seitige Vorlesung von Herrn Prof. Alfons Kemper über Anfrageoptimierung.
• http://www.imn.htwk-leipzig.de/~kudrass/Lehrmaterial/DB2-VL/PDF/
06-Query-Optimierung.pdf
Die Online Version der Vorlesung von Herrn Prof. Dr. T. Kudraß über Query-Optimierung.
• http://www.dbs.informatik.uni-muenchen.de/~conrad/VFDBS/kap11.4.ps
Eine Online Version der Vorlesung von Herrn Stefan Conrad über Anfragebearbeitung.
• http://www-i5.informatik.rwth-aachen.de/lehrstuhl/lehre/IDB00/
Eine komplette Vorlesung von Herrn Prof. Dr. M. Jarke zum Thema Anfrageoptimierung
und Implementierung Datenbanken.
• http://www.uni-mannheim.de/i3v/00217110/01701391.htm
Eine Vorlesung von Herrn Prof. Dr. Guido Moerkotte über ” Algorithmen und Komplexitätsaussagen
für die Optimierung algebraischer Ausdrücke zur Anfragebearbeitung in
Datenbanken“.
• http://www-ia.tu-ilmenau.de/~katrin/WEB DB/SS2002/Architektur/Teil III.pdf
Eine 60 seitige Vorlesung von Herrn Prof. Dr. M. Reichert zum Thema ” Anfragebearbeitung
und -optimierung“ von 2002.
• http://www.inf.uni-konstanz.de/dbis/teaching/ws0102/informationssysteme/
local/K7.pdf
Eine Vorlesung von Herrn Prof. Dr. Gunter Saake und Herrn Prof. Dr. Andreas Heuer
zum Thema ” Optimierung von Anfragen“.
• http://wwwdb.informatik.uni-rostock.de/Lehre/Vorlesungen/DBIII01.html
http://wwwdb.informatik.uni-rostock.de/~hme/lehre/psdump/qproc.ps.gz
Eine Vorlesung von Herrn PD Dr.-Ing. Holger Meyer über Anfragebearbeitung.
• http://www.informatik.uni-ulm.de/dbis/papers/vdb-buch/vdb99 06.pdf
Die Online Version der 60 seitigen Vorlesung von Herrn Prof. Dr. Peter Dadam über
Anfragebearbeitung.

121
• http://ls6-www.informatik.uni-dortmund.de/ir/teaching/lectures/is ws99-00/
folien/folien14.pdf
Die Online Version der Vorlesung von Herrn Prof. Dr. Joachim Biskup aus der Universität
Dortmund.
• http://wwwiti.cs.uni-magdeburg.de/~sattler/dd/dbimpl-6.pdf
http://wwwiti.cs.uni-magdeburg.de/iti db/lehre/db2/skripte/
optimierung2.ps.gz
Die Online Version der Vorlesung von Herrn Dr.-Ing. Kai-Uwe Sattler aus der Universität
Magdeburg.
• http://www-dbs.inf.ethz.ch/~infosys/folien online/kap8/
Übungen:
Die Online Version der Vorlesung von Herrn von Prof. Dr. H.-J. Schek vom 5.5.1997.
Folgende Übungen wurde zum besseren Verständnis des Themas bearbeitet und
können somit auch als sinnvolle Ergänzung zu den oben genannten Vorlesungen
gesehen werden.
• http://wwwiti.cs.uni-magdeburg.de/~sattler/dd/uebung6.pdf
• http://www.mathematik.uni-marburg.de/~beringer/tutorium/Muster3.pdf
• http://www.informatik.uni-ulm.de/dbis/01/lehre/ss02/ue archimpl/
uebung IV folien.pdf
• http://www.upb.de/cs/sensen/UeDatenbankenI/
• http://www.informatik.uni-ulm.de/dbis/01/lehre/ss02/ue archimpl/
uebungsblatt IV loesung.pdf
• http://www.ifis.uni-luebeck.de/lehre/ss98/anfrage/uebung.html
• http://www-ia.tu-ilmenau.de/~katrin/WEB DB/SS2002/Architektur/
Uebungen2.pdf
• http://www.stephan-brumme.com/studies/basistech.html
• http://www.informatik.tu-cottbus.de/~feyer/Lehre/DB5 02/
Arbeiten:
• http://www.informatik.uni-bonn.de/~tb/Lehre/ws98/sIS++/Ausarbeitung/
heikelson a.pdf
Eine Seminararbeit von Konstantin Heikelson im WS98/99 mit dem Titel ” Anfrageoptimierung“.
• http://www.ifis.uni-luebeck.de/lehre/ss98/anfrage/
oo anfrageoptimierung folie.ps
Ein Folienvortrag von Carsten Lecon vom 14.5.1998 mit dem Titel ” Anfrageoptimierung
in Objektorientierten Datenbanken“.
• http://cis.cs.tu-berlin.de/Dokumente/Papers/1999/Les99b.ps.gz
Ein Artikel von Ulf Leser über ” Globale Anfragebearbeitung mit verteilten und heterogenen
Datenquellen“ von 1999.

122 ANHANG C. WEBLINKS ZU DIESER DIPLOMARBEIT
• http://www3.informatik.tu-muenchen.de/lehre/SS2000/ausarbeitung6.pdf
Eine Seminararbeit von Eduard Scherer über ” Datamining - Knowledge Discovery in
Databases“ vom 6.7.2000.
• http://iaks-www.ira.uka.de/iaks-calmet/papers/DISS.ps
Die Dissertationsarbeit von Peter Kullmann über ” Wissenrepräsentation und Anfragebearbeitung
logikbasierten Mediatorumgebung“ vom 6.7.2001.
• http://www.sts.tu-harburg.de/slides/1994/10-94-Kira-O.ps.gz
Die Diplomarbeit von Plamen Kieradjiev über ” Dynamische Optimierung in CPS -
Zwischensprachen“ von 10/1994.
• http://e-lib.informatik.uni-rostock.de/fulltext/1998/pre-diploma/
JonasMichael-1998.ps.gz
Die Studienarbeit von Michael Jonas über ” Entwicklung und Test von Verfahren zum
Testen von Anfrageoptimierungen“ von 1998.
• http://www.gis1.bv.tum.de/Forschung/Promotionen/Dokumente/Ziegler 2002.pdf
Die Dissertation von Matthias Ziegler über die ” Untersuchung geographischer Anfragesprachen
auf der Basis relationaler und objektrelationaler DBMS“ vom 15.5.2001.
• http://www.iuw.uni-vechta.de/personal/geoinf/diplom/homberg.ps.gz
Die Diplomarbeit von Stefan Schmitz-Homberg über die ” Integrität von Landkarten in
deduktiven Datenbanken“ von 6/1998.
• http://www.zurich.ibm.com/~kju/thesis.ps
Seminararbeit von Klaus Julisch über ” Extensibility and Efficiency of Top-Down-Query-
Optimizers“ vom 9.11.1999
• http://www.ipd.uka.de/~kleinm/arbeiten/diplomarbeit.ps
Michael Kleins Diplomarbeit zum Thema ” Eine Pipelining-Algebra für die effiziente Anfragebearbeitung
im KDD-Prozeß“ vom 30.9.2001.
• http://www.ifi.unizh.ch/ifiadmin/staff/rofrei/DA/DA Arbeiten 2000/
Egli Thomas.pdf
Diplomarbeit von Thomas Egli über ” Anfragebearbeitung in SINGAPORE“ an der Universität
Zürich vom 3.10.2000.
• http://e-lib.informatik.uni-rostock.de/fulltext/1995/diploma/
LuenebergJens-1995.ps.gz
Die Diplomarbeit von Jens Lüneberg über den ” Entwurf und Implementierung eines
algebraischen Optimierers für das verteilte Datenbanksystem HEAD“ vom 30.5.1995.
• http://www.wirsam.de/Wido/VisualXXL/DiplomarbeitWido.pdf
Die Diplomarbeit von Wido Wirsam über ” VisualXXL einer Grafischen Bedienoberfläche
für den XXL Anfrageoptimierer“vom 4/2001.
Source-Sammlungen:
• http://www.informatik.uni-trier.de/~ley/dbi/dbi96.html
Eine Auflistung von Michael Ley von verschiedenen Quellen zum Thema Anfrageoptimierung.

• http://www.informatik.fernuni-hagen.de/import/pi4/themen.html#SECTIONREF
123
Eine Auflistung von mehreren Arbeiten über das Thema Anfrageoptimierung im Zuge
eines Seminars an der Fern-Universität-Hagen.
• http://wwwdb.informatik.uni-rostock.de/Forschung/HEaD.html
Mehrere Artikel zum Projekt Head an der Universitat Rostock.
• http://www.freissler.at/BooksDE/ComputerInternet/Templ004Page003896de.html
Eine Auflistung von Büchern zum Thema Genetische Anfrageoptimierung.
• http://www.informatik.uni-trier.de/~ley/db/dbimpl/qo.html
Eine Auflistung von Büchern zum Thema Query Optimization.
• http://wwwdb.informatik.uni-rostock.de/Forschung/croque/CROQUE.publi.html
Artikel:
Die Hauptseite des DFG-Projektes CROQUE (Cost- and Rulebased Optimization of
object-oriented Queries). Auf dieser Website findet man viele Diplomarbeiten, Studienarbeiten
und Artikel über kostenbasierte und regelbasierte Anfrageoptimierung in ojektorientierten
Datenbanken.
• http://wwwdb.informatik.uni-rostock.de/~gflach/psdump/uhsalz95.ps.gz
http://wwwdb.informatik.uni-rostock.de/~lubinski/artikel/optimierung.ps
Ein Artikel von Uwe Langer und Holger Meyer von 1995 über ” Mehrstufige Anfrageoptimierung
in HEAD“.
• http://www.informatik.uni-stuttgart.de/ipvr/as/lehre/skripte/TRSWS9900/
MIDAS.ps.gz
Ein Folienvortrag von Herrn Prof. Dr. Bernhard Mitschang und Michael Jaedicke über
” Parallele Objekt-Relationale DBMS - Prototyp MIDAS“ vom 21.12.1999.
• http://www.ubka.uni-karlsruhe.de/vvv/ira/1994/7/7.text
Ein Artikel zum Thema ” Eine Basis für effiziente Konsistenzprüfung“ von Uwe Herzog
und Herrn Prof. Dr. Guido Moerkotte vom 1.12.1994.
• http://www.ifi.unizh.ch/dbtg/Classes/371SS2002/Slides/dwh-12.pdf
Ein Folienvortrag von Andreas Geppert über ” Anfrageausführung & Leistungssteigerung“
im SS2002.
• http://www6.informatik.uni-erlangen.de/research/artikel.doc.html
Ein Online Artikel von Herrn Prof. Dr. H. Wedekind und Dipl.-Inf. W. Lehner zu ” Anfrageoptimierung
in statistischen Datenbanksystemen“.
• http://www.gi-ev.de/informatik/lexikon/inf-lex-semant-abfrageopt.shtml
Ein Online Artikel von Siegfried Bell zum Thema ” Semantische Abfrageoptimierung“
(Auszug aus seinem Buch).
• http://idw-online.de/public/pmid-1288/zeige pm.html
Ein Online Artikel von Dr.rer.pol. Dipl.-Kfm. Ragnwolf Knorr zu ” Anfrageoptimierung
in statistischen Datenbanksystemen“.
• http://www.uni-erlangen.de/docs/FAUWWW/Aktuelles/2002/Publikationen 2002/
uk102/71-72.pdf
Ein Online Artikel von Dipl.-Kauffrau Gabriele Brambach über ” Anfrageoptimierung in
Datawarehousesystemen“.

124 ANHANG C. WEBLINKS ZU DIESER DIPLOMARBEIT
• http://www-is.informatik.uni-oldenburg.de/publications/242.pdf
Ein Online Artikel von Marco Grawunder zum Thema ” Agentenbasierte adaptive und
dynamische Anfragebearbeitung in virtuellen Datenbanksystemen“.
• http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/
dnarsqlsg/html/msdn qryoptim.asp
Ein Microsoft Artikel über ” Query Optimization Techniques“ von 1994.
• http://www-dbis.informatik.uni-rostock.de/biber2/biber2teile.ps
Ein Ausschnitt aus dem Buch von Prof. Dr. Günther Saake und Prof. Dr. Andreas
Heuer über verschiedene Implementationen von Anfrageoptimierern in z. B. IBM DB2oder
Oracle-Systemen.
• http://wwwmath.uni-muenster.de/u/beckelu/SeminarWS0102/Vortrag1.pdf
Ein Vortrag von Dr. Ludger Becker über ” Grundlegende Verfahren zur Berechnung von
Verbundoperationen“ vom 29.10.2001.
• http://www.mysql.de/documentation/mysql/bychapter/
manual.de MySQL Optimisation.html
Eine Online Version des Handbuches für die Optimierung von MySQL-Datenbanken.
• http://www.ipd.uka.de/~schmitt/DBI/Folien html/node61.html
Ein Vortrag über Anfrageoptimierung von Bethina Schmitt vom 5.11.1996.

Abbildungsverzeichnis
1.1 Strategien zur Anfrageoptimierung . . . . . . . . . . . . . . . . . 1
1.2 Ablauf der Anfrageoptimierung . . . . . . . . . . . . . . . . . . . 2
1.3 Phasen der Optimierung . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Anfrageraum der Ausführungspläne . . . . . . . . . . . . . . . . . 6
2.1 Vom Anfragebaum zum ” dag“-Tree . . . . . . . . . . . . . . . . . 13
2.2 Eliminierung leerer Teilbäume . . . . . . . . . . . . . . . . . . . . 14
2.3 Vom entarteten zu einem ausgewogenen Anfragebaum . . . . . . . 14
2.4 1:1-übersetzter Anfragebaum . . . . . . . . . . . . . . . . . . . . . 15
2.5 Algebraisch-optimierter Anfragebaum . . . . . . . . . . . . . . . . 16
3.1 Zugriffsmethoden der physischen Optimierung . . . . . . . . . . . 21
3.2 Schematische Darstellung eines Auswertungsplanes . . . . . . . . 23
3.3 Generischer Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Projektions-Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Selektions-Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6 Selektions-Iterator mit Zugriff über vorhandenen Index . . . . . . 25
3.7 NestedLoop-Iterator . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.8 Relationen-Index-Join-Iterator . . . . . . . . . . . . . . . . . . . . 27
3.9 Index-Index-Join-Iterator . . . . . . . . . . . . . . . . . . . . . . . 28
3.10 Merge-Join-Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.11 Hash-Join-Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.12 physisch optimierter Anfragebaum . . . . . . . . . . . . . . . . . . 39
4.1 Aufbau eines Kostenmodells . . . . . . . . . . . . . . . . . . . . . 41
4.2 Normalverteilter Stichprobenraum . . . . . . . . . . . . . . . . . . 53
4.3 Equi-Depth-Histogramm . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 Beispiel für die Kardinalitätsabschätzung . . . . . . . . . . . . . . 56
4.5 physisch optimierter Anfragebaum . . . . . . . . . . . . . . . . . . 62
5.1 Suchraum der Ausführungspläne . . . . . . . . . . . . . . . . . . . 67
6.1 Ablauf der Anfrageoptimierung . . . . . . . . . . . . . . . . . . . 74
6.2 Schematische Darstellung der Transformation eines Anfragebaums 77
125

126 ABBILDUNGSVERZEICHNIS
6.3 Beipiel für die Transformation eines Anfragebaums . . . . . . . . 78
6.4 Schematische Darstellung der Generierung eines Anfragebaums . . 79
6.5 mögliche Schritte der Generierung . . . . . . . . . . . . . . . . . . 80
6.6 lokale Form des Prototypen . . . . . . . . . . . . . . . . . . . . . 81
6.7 lokale Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.8 lokale Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.9 1:1-übersetzter Anfragebaum . . . . . . . . . . . . . . . . . . . . . 86
6.10 Algebraischer Prototyp . . . . . . . . . . . . . . . . . . . . . . . . 86
6.11 Physischer Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.12 Kostenoptimierter Anfragebaum . . . . . . . . . . . . . . . . . . . 90
7.1 Die Packages des SQL-Optimierers . . . . . . . . . . . . . . . . . 92
7.2 Das GUI Package des SQL-Optimierers . . . . . . . . . . . . . . . 93
7.3 Relationenfenster des SQL-Optimierers . . . . . . . . . . . . . . . 94
7.4 Metadatenfenster des SQL-Optimierers . . . . . . . . . . . . . . . 95
7.5 Abhängigkeitsgraph der Klassen aus sopt.struc . . . . . . . . . 100
7.6 Abhängigkeitsgraph der Klassen aus sopt.struc.phys . . . . . . 103
7.7 Startfenster des SQL-Optimierers . . . . . . . . . . . . . . . . . . 106

Tabellenverzeichnis
3.1 Zusammenfassende Darstellung der Mengenoperationen . . . . . . 33
3.2 Algebraische Operatoren und die dazugehörigen physischen Implementierungen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Selektivitätsabschätzung für Prädikate . . . . . . . . . . . . . . . 47
4.2 Zusammenfassung der Verfahren . . . . . . . . . . . . . . . . . . . 55
4.3 Scankosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4 Sort- Hash- und Tree-Kosten . . . . . . . . . . . . . . . . . . . . . 58
4.5 Join-Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6 Metadaten für die Relation R . . . . . . . . . . . . . . . . . . . . 61
4.7 Metadaten für die Relationen R1 und R2 . . . . . . . . . . . . . . 63
6.1 Metadaten für die Relation R1 . . . . . . . . . . . . . . . . . . . . 87
6.2 Metadaten für die Relation R2 . . . . . . . . . . . . . . . . . . . . 87
A.1 Rule based optimizer . . . . . . . . . . . . . . . . . . . . . . . . . 112
A.2 Cost based optimizer mit hints . . . . . . . . . . . . . . . . . . . . 113
127

128 TABELLENVERZEICHNIS

Literaturverzeichnis
[1] J. Albrecht, Anfrageoptimierung in Data-Warehouse-Systemen auf Grundlage
des multidimensionalen Datenmodells, Dissertation, Gruner Druck
GmbH, Januar 2001.
[2] L. Becker, Ein Optimierer für ein erweiterbares Geo-Datenbanksystem, Diplomarbeit,
Universität Dortmund, 1988.
[3] L. Becker, R. H. Güting, Rule-Based Optimization and Query Processing in
an Extensible Geometric Database System, ACM Transactions on Database
Systems, Vol. 17 Nr. 2, pp. 247-303, 1992.
[4] Siegfried Bell, The Expanded Implication Problem of Data Dependencies.
LS8-Report, 16, University Dortmund, Computer Science VIII, 1995.
[5] Siegfried Bell, Discovery and Maintenance of Functional Dependencies by
Independencies, First International Conference on Knowledge Discovery in
Databases, U.M. Fayyad (ed.), AAAI-Press, 1995.
[6] Siegfried Bell, Deciding Distinctness of Query Results by Discovered Constraints.
Proceedings of the Second International Conference on the Practical
Application of Constraint Technology, Mark Wallace (ed.), The Practical
Application Company Ltd., 1996.
[7] Siegfried Bell, Entdeckung von Metadaten zur semantischen Anfrageoptimierung
in relationalen Datenbanken. Berichte aus der Informatik, Shaker Verlag,
1997.
[8] S. Ceri, G. Pelagatti Distributed Databases, Principles ans Systems,
McGraw-Hill Book Company, p. 133, 1984.
[9] S. Chaudhuri, K. Shim, Optimization of queries with user-defined predicates,
In Proceedings of the 22nd International Conference on Very Large Data
Bases, pp. 87-98, Mumbai (Bombay), September 1996.
[10] M. Cherniack, S. B. Zdonik, Rule languages and internal algebras for rulebased
optimizers, In Proceedings of the 1996 ACM SIGMOD International
Conference on Management of Data, pp. 401-412, Montreal, June 1996.
129

130 LITERATURVERZEICHNIS
[11] M. Cherniack, S. B. Zdonik, Changing the rules: Transformations for rulebased
optimizers, In Proceedings of the 1998 ACM SIGMOD International
Conference on Management of Data, pp. 61-72, Seattle, June 1998.
[12] S. Cluet, G. Moerkotte, Query Optimization Techniques Exploiting Class
Hirarchies, Aachener Informatik-Berichte, 1995.
[13] R. L. Cole, G. Gräfe, Optimization of dynamic query evaluation plans, In
Proceedings of the 1994 ACM SIGMOD International Conference on Management
of Data, pp. 150-160, Minneapolis, June 1994.
[14] E. F. Codd, A relational Model of Data for Large Shared Data Banks, In
Communications of the ACM, p.13, 1970.
[15] P. Dadam, Verteilte Datenbanken und Clien/Server-Systeme, Springer-
Verlag Berlin Heidelberg, 1. Auflage, 1996.
[16] S. Dieker, Efficient Integration of Query Algebra Modules into an Extensible
Database Framework, Dissertation, Mensch & Buch Verlag, 2001.
[17] Michael C. Ferrism, A Genetic Algorithm for Database Query Optimization,
Artikel BFI97a, pp. 400-407, 1997.
[18] J.C. Freytag, D. Maier, G. Vossen (Eds.), Query Processing for Advanced
Database Applications, Morgan Kaufmann, 1994.
[19] G. Gräfe, W. McKenna, The Volcano optimizer generator: Extensibility and
efficient search, In Proceedings of the 9th International Conference on Data
Engineering, pp. 209-218, Vienna, April 1993.
[20] G. Gräfe, Query Evaluation Techniques for Large Databases, ACM Computing
Surveys Volume 25. No.2, pp. 79-170, June 1993.
[21] G. Gräfe, The Cascades framework for query optimization Bulletin of the
Technical Commitee on Data Engineering, 18(3):19-29, September 1995.
[22] G. Gräfe, P. OŃeil, G. Gräfe, Multi-Table Joins Bitmapped Join Indices,
SIGMOD Record, Volume 24, No. 3, pp. 8-11, 1999.
[23] T. Härder, Realisierung von operationalen Schnittstellen, Datenbankhandbuch,
P.C. Lockemann, J.W. Schmidt (Hrsg.), Springer-Verlag, 1987.
[24] J. M. Hellerstein, M. Stonebraker, Optimizing queries with expensive predicates.
In Proceedings of the 1993 ACM SIGMOD International Conference
on Management of Data, pp. 267-286, Washington, May 1993.
[25] J. M. Hellerstein. Practical predicate placement, In Proceedings of the 1994
ACM SIGMOD International Conference on Management of Data, pp. 325-
335, Minneapolis, June 1994.

LITERATURVERZEICHNIS 131
[26] Y. E. Ioannidis, V. Poosala, Balancing histogram optimality and practicality
for query result size estimation. In Proceedings of the 1995 ACM SIGMOD
International Conference on Management of Data, pp. 233-244, San Jose,
May 1995.
[27] M. Jarke, J. Koch, Query Optimization in Database Systems, ACM Computing
Surveys Volume 16. No.2, pp. 111-152, June 1984..
[28] N. Kabra, D. J. DeWitt, Efficient mid-query re-optimization of sub-optimal
query execution plans. In Proceedings of the 1998 ACM SIGMOD International
Conference on Management of Data, pp. 106-117, Seattle, June 1998.
[29] A. Kemper, A. Eickler, Datenbanksysteme, 4. Auflage, Oldenbourg Wissenschaftsverlag
GmbH, 2001.
[30] W. Kim, D.S. Reiner, D.S. Batory (Eds.), Query Processing in Database
Systems, Springer-Verlag, 1985.
[31] W. Lehner, Erweiterte Konzepte und Techniken der Anfrageoptimierung in
Datenbanksystemen, Arbeitsbericht, Gruner Druck GmbH, Februar 1998.
[32] U. Lipeck, Datenbanksysteme I-III, Vorlesungscript, WS/SS 2001/2002
[33] St. Manegold, J.K. Obermaier, F. Waas, Flexible Anfrageoptimierung in
parallelen Datenbanksystemen, Arbeitspapier, Humboldt-Universität zu Berlin,
Januar 1997.
[34] V. Markl, Mistral: Processing Relational Queries using a Multidimensional
Access Technique, Dissertation, Handt Druck GmbH, 1999.
[35] H. Meuss, Logical Tree Matching with Complete Answer Aggregates for Retrieving
Structured Documents, Dissertation, Dissertation.de-Verlag, 2000.
[36] B. Mitschang, Anfragebearbeitung in Datenbanksystemen, 1. Auflage, Vieweg
Verlag, 1995.
[37] H. Garcia-Molina, J. D. Ullman, J. Widom, Database System Implementation,
1. Auflage, Prentice-Hall Inc., 2000.
[38] G. Moerkotte, Konstruktion von Anfrageoptimierern für Objektdatenbanken,
Habilitation, Shaker Verlag, 1995.
[39] Oracle 9i, Server Concepts Manual, Kapitel 13: The Optimizer.
[40] M. Tamer Özsu, Patrick Valduriez, Principles of Distrubuted Database Systems,
2. Auflage, Prentice-Hall Inc., 1999.
[41] G. Piatesky-Shapiro, C. Connell, Accurate Estimation of the Number of Tuples
Satisfying a Condition, In Proceedings of the ACM SIGMOD Conference,
Boston, 1984.

132 LITERATURVERZEICHNIS
[42] V. Poosala, Y. E. Ioannidis, P. J. Haas, and E. J. Shekita. Improved histograms
for selectivity estimation of range predicates. In Proceedings of the
1996 ACM SIGMOD International Conference on Management of Data, pp.
294-305, Montreal, June 1996.
[43] V. Poosala, Y. E. Ioannidis, Selectivity estimation without the attribute value
independence assumption. In Proceedings of the 23rd International Conference
on Very Large Data Bases, pp. 486-495, Athens, August 1997.
[44] H. Riedel, Effiziente Anfrageauswertung in objektorientierten Datenbanken,
Dissertation, Shaker Verlag, 1994.
[45] S. Russel, P. Norvig, Artificial Intelligence A Modern Approach, Prentice
Hall Verlag, 1995.
[46] G. Saake, A. Heuer, Datenbanken: Implementierungstechniken, 1. Auflage,
mitp-Verlag GmbH, 1999.
[47] Y. C. Sagiv, Optimization of Queries in Relational databases, 1. Auflage,
UMI Research Press, 1981.
[48] W. Scheufele, G. Moerkotte, Efficient dynamic programming algorithms for
ordering expensive joins and selections. In Proceedings of the 6th International
Conference on Extending Database Technology, pp. 201-215, Valencia,
March 1998.
[49] W. Scheufele, G. Moerkotte, Optimal Ordering of Selections and Joins in
Acyclic Queries with Expensive Predicates, Aachener Informatik-Berichte,
1996.
[50] H. Schöning, Anfrageverarbeitung in Komplexobjekt- Datenbanksystemen,
Dissertation, Deutscher Universitätsverlag GmbH, 1993.
[51] P. Selinger, M. Astraham, D. Chamberlain, R. Lorie, T. Price, Access Path
Selection in a Relational Database Management System, In Proceedings of
the ACM SIGMOD Conference, 1979.
[52] M. Steinbrunn, G. Moerkotte, A. Kemper, Optimizing Join Orders, Universität
Passau, Fakultät für Mathematik und Informatik Universität Passau,
1993.
[53] M. Steinbrunn, G. Moerkotte, A. Kemper, Heuristic and randomized optimization
for the join ordering problem, The VLDB Journal, 6(3):191-208,
1997.
[54] M. Utesch, Ein Beitrag zur Anfrageoptimierung in DBS mit Genetischen
Algorithmen, 1. Auflage, VDE-Verlag, 2000.

LITERATURVERZEICHNIS 133
[55] P. Valduriez, Join Indices, ACM TODS, Volume 12, pp. 218-246, Nr. 2, Juni
1991.
[56] B. Vance, D. Maier, Rapid bushy join-order optimization with Cartesian products.
In Proceedings of the 1996 ACM SIGMOD International Conference
on Management of Data, pp. 35-46, Montreal, June 1996.
[57] G. Vossen, Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme,
Kapitel 15., pp. 471-497, 4. Auflage, Oldenbourg Wissenschaftsverlag
GmbH, 2000.

Nachwort
Diese Diplomarbeit entspricht mehr als sechs Monaten meines Lebens, in denen
ich mir fast jeden Tag ausnahmslos Gedanken und Ideen bezüglich dieses Themas
gemacht habe. Zum erstenmal wurde ich mir meiner Grenzen bewußt und legte
mir selbst auf, sie so oft zu durchbrechen, wie es mir möglich war.
Als es damals darum ging, ob ich jemals ein Gymnasium besuchen dürfte, waren
sich - außer meinen Eltern - alle im Klaren, daß ich nie für eine höhere Schullaufbahn
geeignet sein würde. Jetzt - nach 13 Jahren - soll diese Arbeit das Gegenteil
beweisen.
Perfektionismus, Masochismus und ein bisschen dem Verlangen es all denen recht
zu machen, die große Erwartungen in mich gesetzt haben, hoffe ich Genüge getan
zu haben.
Vieles was man erreichen möchte, kann man nur dann erlangen, wenn man dafür
etwas Anderes aufgibt. Ich bete zu Gott, daß ich nicht zu viele Dinge geopfert
habe, die ich nicht mehr gutmachen kann.
Mazeyar Eghballossaltaneh Makoui
”Zeit ist irrelevant; Raum ist irrelevant;
das Einzige was zählt, ist das jetzt und heute.”