Untersuchungen zur Optimierung von Universalrelation

Untersuchungen zur Optimierung von
Universalrelation-Sichten
Diplomarbeit im Studiengang
Mathematik mit Studienrichtung Informatik
vorgelegt von: Martin Boroske
Universität Hannover – Institut für Informatik
Fachgebiet Datenbanken und Informationssysteme
Prüfer: Dr. Hans Hermann Brüggemann
Zweitprüfer: Prof. Dr. Udo Lipeck
Hannover, 4. Oktober 2001
1
Zusammenfassung
Universalrelation-Systeme sind ein Konzept, dem Benutzer eines relationalen Datenbankmanagementsystems beim Stellen einer Anfrage die
Arbeit der Bestimmung der beteiligten Relationen und des Verknüpfens
dieser Relationen abzunehmen, indem das System diese Verknüpfungen
automatisch erstellt. Der Benutzer erhält dadurch eine einheitliche uni”
verselle“ Sicht auf das Datenbankschema. In früheren Arbeiten vorgestellte
Universalrelation-Systeme waren als ein Frontend realisiert, welche diese
Arbeit durch Erzeugen entsprechender SQL-Befehle erledigten. Diese dabei vom System erzeugten SQL-Befehle können sehr schnell sehr komplex
werden.
Die vorliegende Arbeit geht von einer früheren Implementierung eines solchen Universalrelation-Systems aus und untersucht die von diesem
System erzeugten Anfragen auf Optimierungsmöglichkeiten. Es wird der
Frage nachgegangen, inwieweit bei der Erzeugung des sog. Fensters auf die
Universalrelation das Erstellen von Sichten sich auf die Performance auswirkt. Ebenso analysiert wird die Frage, ob bei der Konstruktion des Fensters der Verbund der beteiligten Relationen über den äußeren Verbund“
”
(Outer Join) durchgeführt werden kann, und inwiefern dies Auswirkungen
auf die Komplexität und Performance des Universalrelation-Systems hat.
Beide Untersuchungen sind mit positivem Ergebnis zu bewerten. Die
sich daraus ergebende neue Arbeitsweise des vorgestellten Universalrelation-Systems wird übersichtlich dargestellt.
2
Inhaltsverzeichnis
1 Einführung
6
2 Universalrelation-Systeme
8
2.1
2.2
2.0.1
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.0.2
Datenbankschemas und Hypergraphen . . . . . . . . . . .
12
2.0.3
γ-Azyklizität . . . . . . . . . . . . . . . . . . . . . . . . .
13
Voraussetzungen an das Datenbankschema . . . . . . . . . . . . .
17
2.1.1
Test der Attributnamen-Eindeutigkeit . . . . . . . . . . .
18
2.1.2
Umformung des Film-Datenbankschemas . . . . . . . . .
20
2.1.3
Test auf γ-Azyklizität . . . . . . . . . . . . . . . . . . . .
26
Arbeitsweise des Universalrelation-Systems . . . . . . . . . . . .
27
2.2.1
Bezeichnungen . . . . . . . . . . . . . . . . . . . . . . . .
29
2.2.2
Universalrelation-Kern . . . . . . . . . . . . . . . . . . . .
29
2.2.3
1. Erweiterung: Datenbank-Variablen . . . . . . . . . . . .
32
2.2.4
2. Erweiterung: Geschachtelte Anfragen . . . . . . . . . .
33
2.2.5
3. Erweiterung: Mengen-Operationen . . . . . . . . . . . .
35
2.2.6
4. Erweiterung: ODER-Bedingungen . . . . . . . . . . . .
35
2.2.7
Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3 Literaturübersicht zum Thema Universalrelation-Systeme“
43
”
3.1 Vorläufer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2
Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.3
Weiterführungen und Anwendungen . . . . . . . . . . . . . . . .
44
4 Die Überarbeitung des bisherigen Universalrelation-Systems
46
4.1
Erweiterung auf Sichten . . . . . . . . . . . . . . . . . . . . . . .
46
4.2
Umwandlung der Applikation in ein Applet . . . . . . . . . . . .
49
4.2.1
Einschränkungen eines Applets . . . . . . . . . . . . . . .
49
4.2.2
Änderungen am Programm . . . . . . . . . . . . . . . . .
50
Vereinheitlichung von Disjunktionen und Vereinigungen . . . . .
51
4.3
3
5 Optimierungsuntersuchungen
5.1
5.2
55
Ersetzen der Sicht-Definitionen . . . . . . . . . . . . . . . . . . .
55
5.1.1
Mehrfach vorkommende Hypergraph-Kanten . . . . . . .
55
5.1.2
Verzicht auf Sichten-Erzeugung . . . . . . . . . . . . . . .
55
5.1.3
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
Verwendung von Outer-Joins . . . . . . . . . . . . . . . . . . . .
59
TM
5.2.1
Outer-Join und Oracle8
. . . . . . . . . . . . . . . . .
60
5.2.2
Verwendung von Outer-Joins im Universalrelation-System
63
5.2.3
Die einzelnen Fälle des Universalrelation-Systems in Verbindung mit Outer-Joins . . . . . . . . . . . . . . . . . . .
66
Beispiele und Zugriffspläne . . . . . . . . . . . . . . . . .
67
5.2.4
TM
5.2.5
Outer-Join und Oracle9
. . . . . . . . . . . . . . . . .
72
5.2.6
Zeitmessungen . . . . . . . . . . . . . . . . . . . . . . . .
74
5.2.7
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
6 Das neue“ Universalrelation-System
”
84
7 Ausblick
87
Abbildungsverzeichnis
1
ER-Modell des Bibliotheks-Datenbankschemas . . . . . . . . . .
9
2
Hypergraph des Bibliotheks-Datenbankschemas . . . . . . . . . .
12
3
ER-Modell des γ-zyklischen Bibliotheks-Datenbankschemas . . .
14
4
Hypergraph des γ-zyklischen Bibliotheks-Datenbankschema . . .
14
5
Hypergraph des γ-zyklischen Bibliotheks-Datenbankschema . . .
16
6
ER-Modell des ursprünglichen Film-Datenbankschemas . . . . .
18
7
Hypergraph des Film-Datenbankschemas nach erster Umbenennung 22
8
Hypergraph des endgültigen Film-Datenbankschemas . . . . . . .
23
Tabellenverzeichnis
1
SQL-Kommandos zum Bibliotheks-Datenbankschema . . . . . . .
2
SQL-Kommandos zum γ-zyklischen Bibliotheks-Datenbankschema 15
3
SQL-Kommandos zum ursprünglichen Film-Datenbankschema . .
4
10
19
4
SQL-Kommandos zum endgültigen Film-Datenbankschema . . .
24
5
SQL-Kommandos zum endgültigen Film-Datenbankschema Fortsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
HTML-Seite zum Aufruf des Universalrelation-System-Applets .
50
6
Algorithmenverzeichnis
1
DMF-Reduktion . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2
Erzeugung des Fensters [X] mit der minimalen Verbindungssemantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3
modifizierter GYO-Algorithmus . . . . . . . . . . . . . . . . . . .
30
4
Outer-Join-Bildung über alle Relationen . . . . . . . . . . . . . .
63
5
Outer-Join-Bildung über alle Relationen - Anmerkungen . . . . .
64
6
Outer-Join-Bildung über alle Relationen in Oracle9i . . . . . . .
72
7
Outer-Join-Bildung über alle Relationen in Oracle9i - Anmerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Erzeugung des Fensters [X] mittels Outer-Join . . . . . . . . . .
84
8
5
1
Einführung
Ein Benutzer eines relationalen Datenbankmanagementsystems (DBMS) hat bei
der Erstellung einer Anfrage in der Regel drei wichtige Kriterien zu beachten:
1. Welche Daten möchte ich haben?
2. Aus welchen Relationen erhalte ich diese Daten?
3. Welche Bedingungen und Einschränkungen gelten für diese Daten?
Insbesondere Punkt 2 und 3 erfordern erhöhte Aufmerksamkeit, da für diese das
zugrundeliegende Datenbankschema und auch die Regeln zur Verknüpfung der
einzelnen Relationen (sog. Verbundbedingungen“) dieses Schemas gut bekannt
”
sein müssen.
Universalrelation-Systeme sind ein Konzept, dem Benutzer eines relationalen
DBMS diese logische Navigation“ in einem Datenbankschema zu erleichtern,
”
indem es die Bestimmung der beteiligten Relationen sowie das Erzeugen der
Verbundbedingungen automatisch durchführt, das heißt der Benutzer kann sich
ganz darauf beschränken, die gewünschten Attribute und die für diese Attribute
geltenden Einschränkungen zu bestimmen.
Ein Universalrelation-System kann als eigenständige System entwickelt sein,
oder aber relativ unkompliziert als Frontend für bestehende DBMS entwickelt
werden (vgl. [Bor01], [BT93]). Diese Systeme stellen dem Benutzer eine an SQL
angelehnte Anfragesprache zu Verfügung und erhalten das Ergebnis einer Anfrage, indem die vom Benutzer eingegebene Anfrage in entsprechende SQL-Befehle
umgesetzt wird.
Die Anzahl und die Komplexität der dabei erzeugten SQL-Befehle kann dabei
sehr stark anwachsen. Die vorliegende Arbeit versucht, durch Analyse der von
dem in [Bor01] vorgestellten Universalrelation-Systems erzeugten SQL-Befehle
mögliche Optimierungen der Arbeitsweise des Universalrelation-Systems, und
damit implizit eine Verringerung der Anzahl oder Komplexität der SQL-Befehle
zu finden.
Gliederung der vorliegenden Arbeit
In den Abschnitten 2, 2.1 und 2.2 wird eine Einführung in die Theorie der Universalrelation-Systeme gegeben, es wird erläutert, welche Voraussetzungen an
das zugrundeliegende Datenbankschema gestellt werden, und die Arbeitsweise
des in [Bor01] vorgestellten Universalrelation-Systems wird dargestellt.
Der Abschnitt 3 gibt eine Übersicht über Literatur zum Thema Universalrelation-Modelle und -Systeme.
Im Abschnitt 4 werden Änderungen beschrieben, die am in [Bor01] vorgestellten Universalrelation-System unabhängig von den Optimierungsuntersuchungen
vorgenommen wurden.
Der Abschnitt 5 werden die vorgenommenen Optimierungsuntersuchungen beschrieben, dokumentiert und ausgewertet.
6
Die in diesem Abschnitt gefundenen positiven Ergebnisse werden in Abschnitt
6 zusammengefaßt, und es wird die aus diesen Untersuchungen abgeleitete geänderte Arbeitsweise des Universalrelation-Systems beschrieben.
Abschließende Betrachtungen finden im Ausblick (Abschnitt 7) ihren Platz.
7
2
Universalrelation-Systeme
In relationalen Datenbankmanagementsystemen ist es zum Stellen einer Anfrage notwendig, alle Attribute anzugeben, die vom System ausgegeben werden
sollen, aus welchen Relationen diese Attribute selektiert werden, sowie die Eigenschaften, die diese zu erfüllen haben. Ein Teil dieser Eigenschaften sind die
Bedingungen, in welcher Form die beteiligten Relationen miteinander verknüpft
werden sollen (Verbundbedingungen). Es ist also notwendig, die innere Struktur
eines Datenbankschemas genau zu kennen, um erfolgreich Anfragen stellen zu
können.
Universalrelation-Systeme wurden entwickelt mit der Zielsetzung, den Benutzer von dieser logischen Navigation durch das Datenbankschema zu befreien.
Erreicht wird dies, indem dem Benutzer nur noch eine universelle Relation zugänglich ist, in der alle Daten der Datenbank gespeichert sind. Der Ansatz zu
dieser universellen Relation liegt darin, daß die in einem Datenbankschema vorkommenden Relationen stets über den natürlichen Verbund miteinander verknüpft sind.
In einem Universalrelation-System muß zum Stellen einer Anfrage nur noch die
gewünschte Menge der Attribute sowie die gewünschten Eigenschaften dieser
Attribute angegeben werden. Zusammen mit der Information über das benutzte
Datenbankschema ist dann das System in der Lage, die gewünschten Ergebnistupel zu bestimmen. Dazu muß ein (möglichst minimaler) Ausschnitt aus dem
Datenbankschema gefunden werden. Um semantisch eindeutige Ergebnisse zu
erhalten, ist unter anderem notwendig, daß das verwendete Datenbankschema
γ-azyklisch ist.
8
Autor
Autorenname
Hrsg
hat Autor
Position
Signatur
Inventarnr
ISBN
Titel
Erscheinungsjahr
Buch
ist Exemplar von
Exemplar
Auflage
wird verlegt
ISBN-Code
Verlagsname
Verlag
Verlagsort
Abbildung 1: ER-Modell des Bibliotheks-Datenbankschemas
2.0.1
Beispiel
Anhand eines Beispiels seien die Vorteile eines Universalrelation-Systems veranschaulicht.
Gegeben sei das in Abbildung 1 definierte Datenbankschema einer Bibliotheksdatenbank.
Gespeichert sind Informationen über Bücher, ihre Autoren und ihre Verlage
sowie über die in der Bibliothek vorhandenen Exemplare. Ein Buch wird durch
seine ISBN identifiziert. Jedes Buch kann mehrfach vorhanden sein, verschiedene
Exemplare eines Buches haben die gleiche ISBN, unterscheiden sich jedoch in
Signatur und Inventarnummer. Verlage werden identifiziert durch die ersten
Stellen der ISBN ihrer Bücher, den ISBN-Code. Weitere Attribute eines Verlages
sind der Verlagsname sowie das mengenwertige Attribut Verlagsort.
Eine relationale Umsetzung dieses Schemas könnte wie in Tabelle 1 aussehen.
9
CREATE TABLE Buch (
ISBN
char(13)
primary key,
Titel
char(150),
Erscheinungsjahr
number,
Auflage
number(4)
);
CREATE TABLE wird_verlegt (
ISBN
char(13)
primary key,
ISBN_Code
char(9)
not null
);
CREATE TABLE Verlag (
ISBN_Code
char(9)
primary key,
Verlagsname
char(30)
not null
);
CREATE TABLE Verl_Orte (
ISBN_Code
char(9)
not null,
Verlagsort
char(30)
);
CREATE TABLE Autor (
ISBN
char(13)
not null,
Autorenname
char(30)
not null,
Hrsg
char(4)
not null,
Position
number(2)
not null
);
CREATE TABLE Exemplar (
ISBN
char(13)
not null,
Signatur
char(16)
primary key,
Inventarnr
char(8)
not null
);
Tabelle 1: SQL-Kommandos zum Bibliotheks-Datenbankschema
10
Gegeben sei nun folgende Anfrage:
Gesucht sind alle Bücher, mit ihren Autorennamen und ihrem Verlagsnamen.
Unter SQL würde dies zu folgender Anfrage führen:
SELECT Buch.Titel, Autor.Autorenname, Verlag.Verlagsname
FROM Buch, Autor, Verlag, wird_verlegt
WHERE Buch.ISBN = Autor.ISBN
AND Buch.ISBN = wird_verlegt.ISBN
AND wird_verlegt.ISBN_code = Verlag.ISBN_code;
Es fällt auf, daß in vier der fünf Zeilen dieser Anfrage nur die Relationen und
ihre Verbundbeziehungen festgelegt werden.
Die äquivalente Anfrage an das Universal-Relation-System lautet folgendermaßen:
SELECT Titel, Autorenname, Verlagsname;
Sei nun folgende Anfrage gegeben:
Gesucht sind alle ISBN-Nummern.
Unter SQL lautet diese Anfrage:
SELECT
UNION
SELECT
UNION
SELECT
UNION
SELECT
ISBN FROM Buch
ISBN FROM wird_verlegt
ISBN FROM Autor
ISBN from Exemplar;
Bei dieser Anfrage fällt auf, daß die Hauptarbeit in der Festlegung der einzelnen
Relationen besteht, in denen das gesuchte Attribut vorkommt.
Die äquivalente Anfrage an das Universal-Relation-System lautet hier:
SELECT ISBN;
Allerdings werden durch die Benutzung des Universal-Relation-Systems nicht
alle Anfragen einfacher: Die SQL-Anfrage
SELECT titel, verlagsname
FROM Buch, Verlag;
hätte im Universal-Relation-System folgende Entsprechung:
SELECT a.Titel AS Titel,
b.Verlagsname AS Verlagsname;
Das Universalrelation-System geht davon aus, daß zwischen alle beteiligten Relationen einer Anfrage eine Standardverknüpfung vorliegt. Um hier zu verhindern,
daß diese Beziehung verwendet wird, muß an dieser Stelle mit verschiedenen Kopien das Datenbankschemas gearbeitet werden.
11
Verl_Orte
Verlagsname
Verlagsort
Verlag
Exemplar
ISBN_Code
Inventarnr
Signatur
wird_verlegt
ISBN
Autor
Titel
Autorenname
Hrsg
Position
Buch
Erscheinungsjahr
Auflage
Abbildung 2: Hypergraph des Bibliotheks-Datenbankschemas
2.0.2
Datenbankschemas und Hypergraphen
Im Rahmen der Theorie von Universalrelation-Systemen ist es zweckmäßig, Datenbankschemas als Hypergraphen aufzufassen, da viele Erkenntnisse der Theorie
der Hypergraphen ihre Anwendung finden. Ein Hypergraph ist definiert als ein
Paar (N, E), wobei N eine endliche Menge von Knoten und E eine Menge von
Kanten ist mit e ∈ E ⇒ e ⊂ N . Man kann nun Datenbankschemas als Hypergraphen auffassen, indem jedes Attribut eines Datenbankschemas als Knoten,
und jedes Relationsschema als eine Kante des Hypergraphens interpretiert wird.
Ein Hypergraph (N, E) heißt zusammenhaängend, falls zu je zwei Kanten
e1 , e2 ∈ E ein Weg existiert, es also eine Folge von Kanten (e1 , en1 , . . . , enk , e2) ∈
E gibt, so daß gilt: e1 ∩en1 6= ∅, enk ∩e2 6= ∅ und eni ∩eni+1 6= ∅ ∀i ∈ (1, . . . , k−1).
Ein Datenbankschema heißt zusammenhängend, falls der zugehörige Hypergraph zusammenhängend ist.
Betrachten wir wiederum das Beispiel-Datenbankschema in Tabelle 1, so wird
dadurch der in Abbildung 2 dargestellte Hypergraph definiert.
Zur Bearbeitung einer Anfrage wird vom Universalrelation-System ein geeigneter Ausschnitt aus dem Datenbankschema bestimmt. Dieser Ausschnitt ist ein
Teil-Hypergraph des Datenbankschemas, und wird Anfragehypergraph genannt.
12
2.0.3
γ-Azyklizität
Wie schon weiter oben erwähnt, ist die γ-Azyklizität eines Datenbankschemas
eine notwendige Eigenschaft, damit ein Universalrelation-System verwendet werden kann. Aus diesem Grunde soll hier dieser Begriff im Zusammenhang mit
Datenbankschemas näher erläutert werden.
Ein γ-azyklischer Hypergraph wird wie folgt definiert:
Sei H = (N, E) ein Hypergraph.
1. (e1 , A1 , e2 , A2 , . . . , em , Am , em+1 ) ist γ-Kreis (der Länge m) in H :⇔
(a) A1 , . . . , Am sind verschiedene Knoten aus N .
(b) e1 = em+1 , e1 , . . . , em sind verschiedene Kanten aus E.
(c) m ≥ 3.
(d) ∀i ∈ {1..m} : Ai ∈ ei ∩ ei+1
S
(e) ∀i ∈ {1..m − 1} : Ai ∈
/ j∈{1..m}\{i,i+1} ej .
2. H ist γ-azyklisch :⇔ H enthält keinen γ-Kreis.
In Worten formuliert: Ein Hypergraph besitzt einen γ-Kreis, wenn mindestens
drei verschiedene Hyperkanten immer paarweise einen Knoten gemeinsam haben, aber keiner dieser Knoten in einer anderen Hyperkante enthalten ist.
Wir sprechen von einem γ-azyklischen Datenbankschema, wenn der zugehörige
Hypergraph diese Eigenschaft besitzt.
Anhand eines Beispieles soll die Notwendigkeit der γ-Azyklizität eines Datenbankschemas erläutert werden.
Betrachten wir dazu das in Abbildung 3 und in Tabelle 2 definierte Datenbankschema.
Durch dieses Schema wird der in Abbildung 4 angegebene Hypergraph definiert.
In diesem Hypergraphen bildet die Folge
(leiht aus, Benutzernr, bestellt vor, ISBN, Exemplar, Signatur, leiht aus)
von Hyperkanten und Knoten einen γ-Kreis, der Hypergraph und damit das
Datenbankschema ist also γ-zyklisch.
Semantisch äußert diese Eigenschaft sich folgendermaßen:
In diesem Schema gibt es nun zwischen den Attributen Benutzernr und Signatur
zwei Beziehungen:
• Der durch Benutzernr identifizierte Benutzer hat das Exemplar Signatur
ausgeliehen.
• Der durch Benutzernr identifizierte Benutzer hat ein Buch vorbestellt, von
dem Signatur ein Exemplar ist.
Bei der Anfrage
SELECT Benutzernr, Signatur;
13
ISBN
Titel
Signatur
Buch
Exemplar
ist Exemplar von
bestellt vor
Inventarnr
leiht aus
Benutzernr
Benutzer
Benutzername
Abbildung 3: ER-Modell des γ-zyklischen Bibliotheks-Datenbankschemas
Exemplar
Signatur
Inventarnr
ISBN
Titel
Buch
leiht_aus
bestellt_vor
Benutzernr
Benutzername
Benutzer
Abbildung 4: Hypergraph des γ-zyklischen Bibliotheks-Datenbankschema
14
CREATE TABLE Buch (
ISBN
char(13)
primary key,
Titel
char(150),
Erscheinungsjahr number,
Auflage
number(4)
);
CREATE TABLE Exemplar (
ISBN
char(13)
not null,
Signatur
char(16)
primary key,
Inventarnr
char(8)
not null
);
CREATE TABLE Benutzer (
Benutzernr
number(10) primary key,
Benutzername
char(50)
not null
);
CREATE TABLE leiht_aus (
Benutzernr
number(10)
foreign key references Benutzer(Benutzernr),
Signatur
char(16)
foreign key references Exemplar(Signatur)
);
CREATE TABLE bestellt_vor (
Benutzernr
number(10)
foreign key references Benutzer(Benutzernr),
ISBN
char(13)
foreign key references Buch(ISBN)
);
Tabelle 2: SQL-Kommandos zum γ-zyklischen Bibliotheks-Datenbankschema
15
Exemplar
Signatur
Signatur
Inventarnr
ISBN
leiht_aus
bestellt_vor
Benutzernr
Benutzernr
Abbildung 5: Hypergraph des γ-zyklischen Bibliotheks-Datenbankschema
an das Universalrelation-System kann dieses nun ohne weitere Informationen
nicht erkennen, welche Beziehung zwischen den beiden Attributen gemeint ist.
Dies äußert sich darin, daß die Bestimmung des Ausschnittes aus dem Datenbankschema (dem Anfragehypergraphen) nicht eindeutig ist - die Abbildung 5
zeigt beide möglichen Anfragehypergraphen.
16
2.1
Voraussetzungen an das Datenbankschema
Um mit dem hier vorgestellten Universalrelation-System arbeiten zu können,
muß ein Datenbankschema folgende Voraussetzungen erfüllen:
Die Attributnamen müssen datenbankweit gültig sein Es reicht nicht
mehr aus, daß Attributnamen nur innerhalb einer Relation eindeutig sind.
Dies ist nötig, da in einer UR-Anfrage nicht angegeben wird, aus welcher
Relationen ein Attribut stammen soll. Es muß also gelten, daß zwei Attribute mit dem gleichen Namen stets den gleichen Aspekt der realen Welt
bezeichnen (also keine Homonyme vorkommen) und umgekehrt. Diese Bedingung kann durch geeignetes Umbenennen stets erfüllt werden.
Das Datenbankschema muß γ-azyklisch sein Wie im letzten Abschnitt
dargestellt, führen γ-zyklische Datenbankschemas zu semantisch mehrdeutigen Beziehungen, und damit zu mißverständlichen Anfrageergebnissen.
Um dem zu entgehen, sind die in dieser Arbeit vorgestellten Verfahren auf
γ-azyklische Datenbankschemas beschränkt.
17
Alias
Character
Pos
ID
Title
plays
Year
ID
Movie
follows
Name
Sex
Person
directs
Abbildung 6: ER-Modell des ursprünglichen Film-Datenbankschemas
2.1.1
Test der Attributnamen-Eindeutigkeit
Bezüglich der Eindeutigkeit von Attributnamen kann nur geprüft werden, ob
die zum Datenbankschema gehörenden Attribute gleichen Namens vom gleichen Datentyp sind. Sind sie es nicht, so ist davon auszugehen, daß in diesem
Datenbankschema diese Bedingung verletzt ist.
Letztlich bleibt es die Aufgabe des Datenbank-Administrators, für die Einhaltung der ersten Bedingung Sorge zu tragen. Wie dies in der Praxis aussehen
kann, soll am folgenden Beispiel erläutert werden.
Gegeben sei das in Abbildung 6 definierte Datenbankschema einer FilmDatenbank.
Gespeichert sind Informationen über Filme, sowie die Darsteller und die Regisseure. In der Relation plays wird festgelegt, welche Person in welchem Film
spielt. Attribute dieser Relation sind Alias, in dem ein eventueller Alias-Name
dieser Person festgehalten wird, Character , in dem der Name der Rolle gespeichert ist, den diese Person im betreffenden Film spielt, und Pos, in dem die
Position festgehalten wird, an welcher Stelle des Abspanns die Person erwähnt
wird. In der Relation directs wird der Regisseur eines Filmes gespeichert. Nachfolger eines Filmes werden in der Relation follows festgehalten.
Eine relationale Umsetzung dieses Schemas könnte wie in Tabelle 3 aussehen.
18
CREATE TABLE t_Movie (
ID
number(6) primary key,
Title
varchar2(154),
Year
number(4)
);
CREATE TABLE t_Person (
ID
number(6) primary key,
Name
varchar2(),
Sex
varchar2(1)
);
CREATE TABLE t_plays (
Movie
number(6) foreign key references t_Movie(ID),
Player
number(6) foreign key references t_Person(ID),
Alias
varchar2(45),
Character
varchar2(195),
Pos
number(8)
);
CREATE TABLE t_directs (
Movie
number(6) foreign key references t_Movie(ID),
Director
number(6) foreign key references t_Person(ID)
);
CREATE TABLE t_follows (
Movie
number(6) foreign key references t_Movie(ID),
Successor
number(6) foreign key references t_Movie(ID),
);
Tabelle 3: SQL-Kommandos zum ursprünglichen Film-Datenbankschema
19
2.1.2
Umformung des Film-Datenbankschemas
Das wie in Tabelle 3 vorgestellte Film-Datenbankschema erfüllt nicht die Forderung nach Attributnamen-Eindeutigkeit. So taucht zum Beispiel der Name ID
mehrfach auf, und das Attribut Movie meint das Attribut ID aus der Relation
t Movie.
Es wird nun ein Verfahren vorgestellt, um ein Datenbankschema so anzupassen,
daß es die Forderung nach Attributnamen-Eindeutigkeit erfüllt.
Die einzelnen Schritte sind:
• Unterschiedliche Attribute unterschiedlich benennen.
• Gleiche Attribute gleich benennen.
• Relationen aufspalten:
– Verschiedene Relationenschemas unterschiedlich benennen und entsprechende Teil-Relationen bestimmen.
Anhand des Beispieles des Film-Datenbankschemas sollen die einzelnen Schritte
nun erläutert werden.
Im Folgenden werden einige Operationen auf den einzelnen Relationen durchgeführt. Diese können prinzipiell auch durch ein Löschen und Neuanlegen der
betroffenen Relationen durchgeführt werden. Hier werden diese Operationen allerdings durch Sichten emuliert. Dies hat den Vorteil, daß das alte Datenbankschema nicht verloren geht, man muß allerdings den Nachteil in Kauf nehmen,
daß neue Namen für die beteiligten Relationen gefunden werden müssen.
Unterschiedliche Attribute unterschiedlich benennen
Das Attribut ID wird sowohl in der Relation t Movie als auch in der Relation
t Person als Schlüssel verwendet. Da es sich hier offensichtlich um unterschiedliche Attribute handelt, werden diese geeignet umbenannt:
CREATE VIEW s_Movie AS (
SELECT ID AS MovieID, Title, Year
FROM t_Movie
);
CREATE VIEW s_Person AS (
SELECT ID AS PersonID, Name, Sex
FROM t_Person
);
Gleiche Attribute gleich benennen
Nicht nur durch den Schritt sind in dem Schema mehrere Attribute vorhanden,
die unterschiedliche Namen haben, obwohl sie den gleichen Aspekt der realen
”
Welt“ meinen: In der Relation t plays sind das die Attribute Movie und Player
und Director , die sich jeweils auf das Attribut MovieID der Relation s Movie
bzw. auf das Attribut PersonID der Relation s Person beziehen (analog verhält
es sich mit den Attributen movie und director in der Relation t direts). Diese
Attribute werden nun geeignet umbenannt:
20
CREATE VIEW s_plays AS (
SELECT Movie AS MovieID, Player AS PersonID,
Alias, Character, Pos
FROM t_plays
);
CREATE VIEW s_directs AS (
SELECT Movie AS MovieID, Director AS PersonID
FROM t_directs
);
In der Relation t follows beziehen sich beide Attribute Movie und Successor
auf das Attribut MovieID der Relation s Movie. Eine einfache Umbennung der
Attribute in MovieID scheitert aber, da dann beide Attribute denselben Namen
hätten, was nicht erlaubt ist:
CREATE VIEW s_follows AS (
SELECT Movie AS MovieID, Successor AS MovieID
FROM t_follows
);
ERROR at line 2:
ORA-00957: duplicate column name
Wir nenne daher die Attribute soweit um, wie es möglich ist:
CREATE VIEW s_follows AS (
SELECT Movie AS MovieID, Successor AS SuccessorID
FROM t_follows
);
Der aus dieser Umsetzung bestimmte Hypergraph ist in Abbildung 7 dargestellt.
Wie zu erkennen ist, bildet dieser Hypergraph nicht mehr das in Abbildung 6
definierte Modell ab: Die Universalrelation-Anfrage
SELECT MovieID, PersonID
würde die Tupel sowohl aus der Relation s directs, als auch aus der Relation
s plays selektieren - der Benutzer könnte nicht mehr zwischen Darsteller und
Regisseur unterscheiden.
Man beachte: Die Hyperkanten s directs, s plays und s follows, zusammen mit
den Knoten MovieID und PersonID bilden keinen γ-Kreis.
Um dieses Problem zu lösen, wird der letzte Schritt angewendet:
Relationen aufspalten
Die betroffenen Relationen müssen aufgeteilt“ werden, das heißt, um zum Bei”
spiel bei der Relation s Person zu unterscheiden, ob ein Darsteller oder ein
Regisseur gemeint ist, müßte man die Relation in zwei Teile teilen, von denen
der eine Teil nur die Darsteller enthält, und der andere Teil nur die Regisseure.
Am Beispiel der Relation s directs und der betroffenen Relation Person wird
dies veranschaulicht:
21
s_directs
s_Movie
Title
SuccessorID
Year
MovieID
s_follows
s_Person
PersonID
Character
Alias
Pos
Name
Sex
s_plays
Abbildung 7: Hypergraph des Film-Datenbankschemas nach erster Umbenennung
22
Player
PlayerName
PlayerSex
PlayerID
plays
Alias
Character
Pos
Movie
MovieID
MovieTitle
MovieYear
directs
follows
Director
DirectorName
DirectorSex
Successor
SuccessorID
DirectorID
SuccessorTitle
SuccessorYear
Abbildung 8: Hypergraph des endgültigen Film-Datenbankschemas
CREATE VIEW Director AS (
SELECT p.ID AS DirectorID,
p.Name AS DirectorName,
P.Sex as DirectorSex
FROM t_Person p, t_directs d
WHERE p.ID = d.director
);
In den Tabellen 4 und 5 sind alle Operationen übersichtlich dargestellt.
Man beachte: Die Erzeugung der Relation Successor ist strenggenommen nicht
notwendig, sondern wird nur aus Bequemlichkeitsgründen mit erzeugt.
Aus dieser Umsetzung resultiert der in Abbildung 8 abgebildete Hypergraph.
Mit diesem letzten Schritt sind die nötigen Umbenennungen abgeschlossen, und
das so entstandene Datenbankschema ist tauglich für den Einsatz mit Universalrelation-Systemen.
Zusammenfassend werden hier die ausgeführten Operationen im Überblick dargestellt:
• Finde geeignete Umbenennungen für alle Attribute mit
– gleichem Namen, die aber unterschiedliche Aspekte darstellen.
– unterschiedlichem Namen, die aber denselben Aspekt darstellen.
• Für alle Hyperkanten, die dieselbe Menge von Relationen umfassen, aber
unterschiedliche Aspekte darstellen, müssen geeignete Aufteilungen der
Relationen gefunden werden.
23
/*******************************************************/
/* Attribute geeignet umbenennen:
*/
/*******************************************************/
CREATE VIEW Movie AS (
SELECT ID AS MovieID,
Title AS MovieTitle,
Year AS MovieYear
FROM t_Movie
);
/*******************************************************/
/* Alle Attribute aus T_PERSON, die ein Regisseur
*/
/* sind, und die Attribute geeignet umbenennen:
*/
/*******************************************************/
CREATE VIEW Director AS (
SELECT p.ID AS DirectorID,
p.Name AS DirectorName,
P.Sex as DirectorSex
FROM t_Person p, t_directs d
WHERE p.ID = d.director
);
/*******************************************************/
/* Attribute geeignet umbenennen:
*/
/*******************************************************/
CREATE VIEW directs AS (
SELECT Movie AS MovieID,
Director AS DirectorID
FROM t_directs
);
/*******************************************************/
/* Alle Attribute aus T_PERSON, die ein Darsteller
*/
/* sind, und die Attribute geeignet umbenennen:
*/
/*******************************************************/
CREATE VIEW Player AS (
SELECT p.ID AS PlayerID,
p.Name AS PlayerName,
p.Sex AS PlayerSex
FROM t_Person p, t_plays pl
WHERE p.ID = pl.Player
);
Tabelle 4: SQL-Kommandos zum endgültigen Film-Datenbankschema
24
/*******************************************************/
/* Attribute geeignet umbenennen:
*/
/*******************************************************/
CREATE VIEW plays AS (
SELECT Movie AS MovieID,
Player AS PlayerID,
Alias,
Character,
Pos
FROM t_plays
);
/*******************************************************/
/* Alle Attribute aus T_MOVIE, die ein Nachfolger
*/
/* sind, und die Attribute geeignet umbenennen:
*/
/*******************************************************/
CREATE VIEW Successor AS (
SELECT m.ID AS SuccessorID,
m.Title AS SuccessorTitle,
m.Year AS SuccessorYear
FROM t_Movie m, t_follows f
WHERE m.ID = f.Successor
);
/*******************************************************/
/* Attribute geeignet umbenennen:
*/
/*******************************************************/
CREATE VIEW follows AS (
SELECT Movie AS MovieID,
Successor AS SuccessorID
FROM t_follows
);
Tabelle 5: SQL-Kommandos zum endgültigen Film-Datenbankschema - Fortsetzung
25
2.1.3
Test auf γ-Azyklizität
Die in Abschnitt 2.0.3 eingeführte Definition der γ-Azyklizität ist unhandlich,
wenn es darum geht, diese Eigenschaft bei einem gegebenen Hypergraphen nachzuweisen.
Als Test auf γ-Azyklizität von Hypergraphen (und damit von Datenbankschemas) dient der als DMF-Reduktion bekannte Algorithmus. In der Abbildung
Algorithmus 1“ ist die Definition dieses Algorithmus zu finden.
”
Eingabe: Der zu prüfende Hypergraph.
Verfahren: Führe folgende Operationen in beliebiger Reihenfolge so lange aus,
bis keine Änderung mehr auftritt:
1. Kommt ein Knoten nur in einer Hyperkante vor, so entferne diesen Knoten.
2. Enthält eine Hyperkante weniger als zwei Knoten, so entferne diese Hyperkante.
3. Enthalten zwei Hyperkanten die gleiche Knotenmenge, so entferne eine
dieser Hyperkanten.
4. Sind zwei Knoten in genau den gleichen Hyperkanten enthalten, so entferne
einen dieser Knoten aus allen Hyperkanten.
Ausgabe: Der so modifizierte Hypergraph.
Der Hypergraph ist γ-azyklisch genau dann, wenn die DMF-Reduktion zum
leeren Ergebnis führt.
Algorithmus 1: DMF-Reduktion
26
2.2
Arbeitsweise des Universalrelation-Systems
Das in [Bor01] entwickelte Universalrelation-System ist ein Frontend, das aus
einer vom Benutzer gestellten Anfrage SQL-Kommandos erzeugt, diese an das
DBMS weitergibt, und die Ergebnisse dem Benutzer zugänglich macht.
Bei der Anfragesprache wurde versucht, so nahe wie möglich am Vorbild“ des
”
SELECT -Kommandos von Oracle-SQL zu bleiben, wie es in [Ora97] beschrieben
ist. Insbesondere wurde versucht, SQL-typische Erweiterungen wie geschachtelte
Anfragen, Tupel-Variablen oder Mengen-Operationen mit abzudecken. Weggelassen wurden alle Elemente aus Oracle-SQL, die sich auf einzelne Relationen des
Datenbankschemas beziehen (also alle FROM -Teile des SELECT -Kommandos),
sowie die Objekterweiterungen. Weiterhin wurden Aggregatfunktionen (zum
Beispiel count(), sum() oder max()) weggelassen, was in Abschnitt 4.3 genauer
erläutert wird.
Die prinzipielle Arbeitsweise ist folgende:
1. Bestimme die Struktur des benutzten Datenbankschemas. Überprüfe dieses daraufhin, daß es die Voraussetzungen aus Abschnitt 2.1 erfüllt.
2. Aus der vom Benutzer angegebenen Anfrage und der Struktur des Datenbankschemas bestimme die benötigten Anfragehypergraphen, also alle
benötigten Attribute und Relationen des Datenbankschemas, sowie deren
Verbundbedingungen.
3. Stelle die Anfrage an die Anfragehypergraphen und mache die Ergebnisse
dem Benutzer zugänglich.
Der genaue Arbeitsablauf ist folgender:
•
1. Schritt: ODER-Bedingungen
Forme die Bedingungen der WHERE-Klausel in Disjunktive Form um:
SELECT <Anfrageattribute>
WHERE Disjunkt_1 OR ... OR Disjunkt_n
Für jede Teilanfrage
SELECT <Anfrageattribute>
WHERE Disjunkt_i
ermittle:
•
2.Schritt: Mengenoperation
Für jeden Operanden einer Mengenoperation (UNION, UNION ALL, INTERSECT, MINUS ) berechne:
•
3. Schritt: Geschachtelte Anfragen
Für die Hauptanfrage und für jede darin enthaltene Unteranfrage
berechne:
•
4. Schritt: Datenbank-Variablen
Berechne für jede vorkommende Datenbank-Variable v ∈ Vj :
•
5. Schritt: Anfragehypergraph
Berechne Anfragehypergraph Hv,i , und für jede Kante R des
27
Anfragehypergraphen alle Oberrelationen des Datenbankschemas. Bilde anschließend die Vereinigung aller Projektionen auf R als Sicht:
[
RelKante v,i :=
π(R) (S )
S∈D,S⊃R
•
6. Schritt: Verbundbedingungen
Berechne die Verbundbedingungen und den Ausschnitt der
Universalrelation als Sicht:
U R v,i := πAnf rageattribute (./Kantev,i , RelKantev,i )
•
7. Schritt: Kartesisches Produkt der Ausschnitte
Ermittle das kartesische Produkt der UR-Ausschnitte zu allen
Datenbank-Variablen als Sicht:
U R j := × U R v,i
v∈Vj
•
8. Schritt: Einsetzen der Unteranfragen
Erzeuge für die Unteranfragen keine Sicht, sondern setze die unter 8.
Schritt erstellte SQL-Anfrage in die Sicht der erstellten Hauptanfrage
ein.
•
9. Schritt: Ergänzung um den Mengenoperanden
Ergänze die bisherige (evtl. leere) Sichtdefinition für den UR-Ausdruck
um die Anfrage für diesen Mengenoperanden.
•
10. Schritt: Anfrage stellen
Werte die gestellte UR-Anfrage bzgl. des Gesamtausschnittes der Universalrelation aus, ggf. ergänzt um ORDER-Klauseln und liefere das Ergebnis
zurück.
•
11. Schritt: Abschließendes Aufräumen
Lösche alle definierten Sichten.
Das Universalrelation-System wird in mehreren Stufen entwickelt. Dies sind im
wesentlichen
• Universalrelation-Kern (Schritt 5, 6, 10 und 11)
• 1.Erweiterung: Datenbank-Variablen (Schritt 4 und 7)
• 2.Erweiterung: Geschachtelte Anfragen (Schritt 3 und 8)
• 3.Erweiterung: Mengen-Operationen (Schritt 2 und 9)
• 4.Erweiterung: ODER-Bedingungen (Schritt 1)
Es folgt nun eine Beschreibung der einzelnen Entwicklungsschritte und deren
Arbeitsweise.
28
2.2.1
Bezeichnungen
In der Beschreibung der Arbeitsweise der einzelnen Entwicklungsschritte treten
immer wieder die Sichten [SET j ]KANTE[ m] k und [SET j ]AHG m auf.
Die Benennung dieser Sichten folgt einem Schema, welches hier erläutert werden
soll:
• Der Namensteil SET j wird immer dann verwendet, wenn diese Sichten zu
einem Mengen-Operanden gehören. In solch einem Fall gibt j die Nummer
des zugehörigen Mengen-Operanden an.
• Der Namensteil m tritt immer dann auf, wenn in der Anfrage DatenbankVariablen vorkommen. Dann wird m durch den Namen der Variable ersetzt, zu dem diese Sichten gehören.
• Der Namensteil k bezeichnet die Nummer der Kante des Anfragehypergraphen, zu der diese Sicht gehört. Dieser Namensteil ist immer gleich 0
oder größer.
2.2.2
Universalrelation-Kern
Der Universalrelation-Kern ist die grundlegende Ebene. Mit den in dieser Ebene vorkommenden Verfahren ist das System in der Lage, UniversalrelationAnfragen zu bestimmen, alle weiteren Ebenen sind nur noch Erweiterungen des
Sprachumfanges des Universalrelation-Systems.
Der Universalrelation-Kern kann Anfragen bearbeiten, die folgende Sprachelemente nicht enthalten:
• ODER-Bedingungen in der WHERE -Klausel
• Datenbank-Variablen
• Schachtelungen
• Mengen-Operatoren (UNION [ALL], MINUS, INTERSECT).
Die Aufgabe des Kerns ist es, ausgehend von der in der Anfrage angegebenen
Attribut-Menge X einen geeigneten Ausschnitt aus der Datenbank zu finden
(dieser Ausschnitt wird auch Fenster genannt und mit [X] bezeichnet).
Das Universalrelation-System berechnet
minimalen Verbindungssemantik.
dieses
Fenster
nach
der
Die formale Definition eines Fensters der minimalen Verbindungssemantik lautet:
[
[X ]M C := πX ( o
n
πV (R ))
V ∈AHG
R∈RS,R⊇V
Ausgehend von einem Anfragehypergraphen wird dieses Fenster also wie in der
Abbildung Algorithmus 2“ bestimmt:
”
Der Anfragehypergraph einer Menge von Anfrageattributen X wird dabei nach
dem modifizierten GYO-Algorithmus bestimmt, welcher in der Abbildung Al”
gorithmus 3“ definiert ist.
29
Eingabe: Anfragehypergraph, Attributmenge X
Ausgabe: Das zu X gehörende Fenster [X].
Verfahren:
• Für jede Kante Rk (k = 0, . . . , m) des Anfragehypergraphens mit der
Attributmenge Ak
– Bestimme die Projektion aller Relationen der Datenbank, deren Schema eine Obermenge dieser Attributmenge ist.
– Bilde die Vereinigung aller dieser Projektionen.
• Fasse alle diese Vereinigungen über den natürlichen Verbund zusammen.
• Bilde [X] als die Projektion dieses Verbundes auf die Attributmenge X.
Algorithmus 2: Erzeugung des Fensters [X] mit der minimalen Verbindungssemantik
Eingabe:
• γ -azyklisches Datenbankschema als Attributmenge und Menge der Relationenschemas
• Anfrageattributmenge X
Ausgabe: Der zu X gehörende Anfragehypergraph.
Verfahren: So lange sich etwas ändert führe einen der beiden Schritte aus:
• Kommt ein Attribut, das nicht in X ist, in höchstens einem Relationenschema vor, so lösche das Attribut.
• Sind alle (nicht bereits gelöschten) Attribute eines Relationenschemas vollständig in einem anderen Relationenschema enthalten, so lösche das kleinere Relationenschema.
Der Anfragehypergraph sind dann die Mengen der nicht gelöschten Attribute
und Relationenschemas des Datenbankschemas.
Algorithmus 3: modifizierter GYO-Algorithmus
30
Die genauen Arbeitsschritte sind also:
• Auslesen der Informationen aus der Anfrage:
Die vom Benutzer eingegebene Anfrage wird ausgewertet und alle relevanten Informationen gesammelt. Dies sind
Anfrageattributmenge X Diese Menge enthält alle in der Anfrage vorkommenden Datenbank-Attribute (also die aus dem SELECT -Teil
und die aus dem WHERE -Teil).
Select-Liste Diese Liste besteht aus allen im SELECT -Teil vorkommenden Ausdrücken.
Select-Attribut-Liste Diese Liste besteht aus allen in der Select-Liste
vorkommenden Datenbank-Attributen.
• Erzeugen des Anfragehypergraphens und des Fensters:
Nach den in Algorithmus 2“ und Algorithmus 3“ beschriebenen Verfahren
”
”
werden der Anfragehypergraph und die der Anfrage entsprechenden Sicht
auf das Datenbankschema berechnet.
Das Universalrelation-System erzeugt dabei folgende SQL-Kommandos:
CREATE VIEW KANTE_<i> AS
SELECT <Anfragehypergraph-Kante i>
FROM <Oberrelation i_1>
UNION
...
UNION
SELECT <Anfragehypergraph-Kante i>
FROM <Oberrelation i_n>
für i = 0, . . . , k.
CREATE VIEW AHG_1 AS
SELECT <Anfrage-Attribute>
FROM KANTE_0, ..., KANTE_<k>
WHERE <Verbundbedingungen>
Die Verbundbedingungen werden folgendermaßen erzeugt:
– Für jedes Attribut A, das in mehreren Relationenschemas
(R1 , . . . , Rn ; n ≥ 2) des Anfragehypergraphen vorkommt, wird folgende Bedingung hinzugefügt:
R1 .A = R2 .A AND R1 .A = R3 .A AND . . . AND R1 .A = Rn .A
Es wird noch eine Sicht erzeugt, die alle Ergebnistupel enthält:
CREATE VIEW UR_WINDOW AS
SELECT DISTINCT <Select-Attribut-Liste>
FROM AHG_1
WHERE <Selektions-Bedingungen>;
An diese Sicht wird nun die Anfrage gestellt:
31
SELECT <Select-Liste> FROM UR_WINDOW;
Hat man in der Anfrage SQL-typische Erweiterungen, wie ORDERKlauseln verwendet, so werden diese an die Anfrage angehängt:
SELECT <Select-Liste>
FROM UR_WINDOW
ORDER BY Order_Clause;
• Abschließendes Aufräumen:
Alle zwischenzeitlich erzeugten Sichten werden wieder gelöscht:
DROP VIEW UR_WINDOW;
DROP VIEW AHG_1;
DROP VIEW KANTE_<i>;
für i = 0, . . . , k.
2.2.3
1. Erweiterung: Datenbank-Variablen
Datenbank-Variablen werden verwendet, um mit verschiedenen Kopien der Datenbank arbeiten zu können. Es muß also für jede auftretende Variable m ein
eigener Anfragehypergraph AHGm und das entsprechende Fenster [X]m auf
die Datenbank erzeugt werden. Das kartesische Produkt über diese DatenbankAusschnitte ist dann die gesuchte Ergebnismenge.
Es ergeben sich also folgende Arbeitsschritte:
• Analysieren der Anfrage:
Die vom Benutzer angegebene Anfrage wird analysiert. Gegenüber dem
bisherigen Verfahren wird nun die Anfrageattributmenge für jede vorkommende Datenbank-Variable getrennt erstellt. Wie bisher werden die
Select-Liste und die Select-Attribut-Liste gemeinsam für alle DatenbankVariablen erstellt.
• Erzeugen der Anfragehypergraphen und der Fenster:
Mit den in Algorithmus 2“ und Algorithmus 3“ beschriebenen Verfahren
”
”
werden für jede Datenbank-Variable der Anfragehypergraph und die der
Anfrage entsprechenden Sicht auf das Datenbankschema berechnet, und
diese Sichten mit dem kartesischen Produkt vereinigt.
Seien M := (M1 , . . . , Mn ) die vorkommenden Datenbank-Variablen.
Für m ∈ M erzeugt das Universalrelation-System dabei folgende SQLKommandos:
CREATE VIEW KANTE_m_i_k AS
SELECT <Attribut-Liste>_m
FROM <Oberrelation k_1>_m
UNION
...
UNION
SELECT <Attribut-Liste>_m
32
FROM <Oberrelation k_n>_m
CREATE VIEW AHG_1 AS
SELECT <Anfrage-Attribute>_m1, ... <Anfrage-Attribute>_mn
FROM AHG_m1, ..., AHG_mn
WHERE VERB_m1, AND ... AND VERB_mn;
für i = 0, . . . , k.
Dabei sind AHGmj alle Sichten KANTE m i k, und analog V ERBmj die
zu AHGmj gehörenden Verbundbedingungen (j = 1, . . . , n).
Man beachte: Bei der Erzeugung der Sicht AHG 1 wurden die Erzeugung
des Fensters [X]m für jede Datenbank-Variable m ∈ M und das Bilden
des kartesischen Produktes über die einzelnen Fenster in einem Schritt
durchgeführt.
• Anfrage stellen und abschließendes Aufräumen:
Am restlichen Teil des Verfahrens ändert sich nichts. Es wird noch eine
Sicht erzeugt, die alle Ergebnistupel enthält:
CREATE VIEW UR_WINDOW AS
SELECT DISTINCT <Select-Attribut-Liste>
FROM AHG_1
WHERE <Selektions-Bedingungen>;
An diese Sicht wird nun die Anfrage gestellt:
SELECT <Select-Liste> FROM UR_WINDOW;
Und alle zwischenzeitlich erzeugten Sichten werden wieder gelöscht:
DROP VIEW UR_WINDOW;
DROP VIEW AHG_1;
DROP VIEW KANTE_<i>;
für i = 0, . . . , k.
2.2.4
2. Erweiterung: Geschachtelte Anfragen
In SQL-Anfragen kommen geschachtelte Anfragen sowohl in der FROM -Klausel,
als auch in der WHERE -Klausel vor. Da die FROM -Klausel in SQL-Anfragen
keine Entsprechung in den Anfragen an das Universal-Relation-System hat, kann
das UR-System deshalb nur geschachtelte Anfragen in der WHERE -Klausel
bearbeiten.
Es ist in geschachtelten SQL-Anfragen möglich, daß sich Teile der inneren Anfrage auf Attribute der Tabellen der äußeren Anfrage beziehen (sog. Korrelierte
geschachtelte Anfragen). Dabei müssen Attributnamen der äußeren Anfrage mit
einer Variable eindeutig gekennzeichnet werden, falls sie auch in den Tabellen
der inneren Anfrage vorkommen. In den Anfragen des UR-Systems kann nur aufgrund des Namens nicht entschieden werden, ob eine Spalte zur äußeren oder
inneren Anfrage gehört (sie kann ja in beiden vorkommen). Daher ist in inneren
Anfragen die Verwendung von Variablen zwingend erforderlich, falls sich auf
33
Attribute der äußeren Anfrage bezogen wird. Sind keine Variablen verwendet
worden, so wird davon ausgegangen, daß alle in der inneren Anfrage vorkommenden Attribute sich nicht auf die äußere Anfrage beziehen.
Das Verfahren zur Bearbeitung von geschachtelten Anfragen ist: Für jede vorkommende geschachtelte Anfrage werden die entsprechenden Anfragehypergraphen und Fenster nach den bisherigen Verfahren berechnet. In der endgültigen
Anfrage des Universalrelation-Systems an das Datenbanksystem werden die geschachtelten Anfragen dann übernommen.
Somit ergeben sich folgende Arbeitsschritte:
• Zerlegen der Anfrage nach den Unteranfragen
Beim Parsen wird jedes Vorkommen einer Unteranfrage durch den Bezeichner Subquery j[ attribute ] ersetzt, wobei j das j-te Auftreten einer
Unteranfrage beim Parsen bezeichnet, und attribute eine Liste aller Attribute aus der äußeren Anfrage ist, die in der Unteranfrage vorkommen.
Für jede Unteranfrage werden vom Parser wie gewohnt alle relevanten
Informationen weitergegeben.
• Bearbeitung der Unteranfragen
Für die auftretenden Unteranfragen werden in der Reihenfolge ihres
Auftretens alle ihre Anfragehypergraphen und Fenster bis einschließlich
VIEW i nach den bisher bekannten Verfahren erzeugt. Zur eindeutigen
Unterscheidung erhalten alle Namen der Sichten ein Präfix SUBQUERY j . Analog zur bisherigen Erzeugung der Sicht UR WINDOW (es wird
nur der Teil CREATE VIEW UR WINDOW AS weggelassen) ergibt sich
die Definition der Unteranfrage Subquery j[ ] :
Subquery_j[ ] ≡
SELECT <Select-Liste_j>
FROM SUBQUERY_j_VIEW_1 WHERE <DISJ_1>
UNION
...
UNION
SELECT <Select-Liste_j>
FROM SUBQUERY_j_VIEW_n WHERE <DISJ_n>
Falls in der Unteranfrage keine Attribute aus der äußeren Anfrage vorkommen, wird der Platzhalter innerhalb [ ]“ leer gelassen.
”
• Bearbeitung der äußeren Anfrage
Für die äußere Anfrage werden nach den bisherigen Verfahren alle Anfragehypergraphen und das Fenster erzeugt.
Die View UR WINDOW wird dann wie bisher erzeugt, allerdings wird
jeder Bezeichner Subquery i, der beim Parsen für die entsprechende Unteranfrage in der WHERE -Klausel eingefügt wurde, durch seine Definition
der Unteranfrage ersetzt.
34
2.2.5
3. Erweiterung: Mengen-Operationen
Als Mengen-Operationen werden Verknüpfungen von zwei Anfragen mit
einem Mengen-Operator bezeichnet. Mengenoperatoren sind INTERSECT ,
MINUS und UNION . Oracle8 kennt darüber hinaus noch den den Operator
UNION ALL. Die Auswertung solcher Operationen erfolgt von links nach rechts,
falls die Reihenfolge der Auswertung nicht durch die Benutzung von Klammern
geändert wird.
Eine Mengen-Operation besteht aus einem linken Mengen-Operanden, einem
Mengen-Operator und einem rechten Mengen-Operanden.
Die genaue Syntax einer Anfrage mit Mengen-Operatoren lautet:
Anfrage_1 (
INTERSECT | MINUS | UNION [ALL] ) Anfrage_2
dabei kann Anf rage1 oder Anf rage2 wiederum aus einer Mengen-Operation
bestehen.
Auf Attribute, die in Anf rage1 vorkommen, darf in Anf rage2 nicht verwiesen
werden, und umgekehrt.
Laut der Oracle8-SQL-Referenz ([Ora97]) können sowohl Anf rage1 , als auch
Anf rage2 , als auch der gesamte Ausdruck in Klammern eingeschlossen sein.
Allerdings werden Anfragen, die über die JDBC-Schnittstelle an das RDBMS
gestellt werden, nicht korrekt ausgewertet, falls die Anfrage mit einer öffnenden Klammer beginnt (Es wird die Bearbeitung mit dem Fehler ORA-01009:
Obligatorischer Parameter fehlt abgebrochen).
Daraus ergibt sich (da das Programm zur Universal-Relation über JDBC auf
das RDBMS zugreift), daß nur Anf rage2 in Klammern gesetzt werden darf.
Die Bearbeitung solcher Anfragen durch das Universalrelation-System erfolgt
so, wie man es intuitiv erwarten würde: Jede einzelne Teilanfrage wird komplett
bearbeitet, und die Ergebnis-Mengen werden dann bei der Erzeugung der Sicht
UR WINDOW entsprechend den Angaben in der Anfrage miteinander vereint,
geschnitten oder abgezogen.
Eine Besonderheit ist zu beachten: Da in Unteranfragen auch Mengenoperatioen
vorkommen können, ist es wichtig, daß die Erzeugung der Anfragehypergraphen
und der Fenster aller Teilanfragen in der umgekehrten Reihenfolge ihres Auftretens in der Anfrage vorgenommen wird.
2.2.6
4. Erweiterung: ODER-Bedingungen
Möchte der Benutzer Anfragen stellen, die im Bedingungs-Teil OR-Klauseln
enthalten, so erwartet man als Ergebnis alle die Tupel, deren Attribute eine
der Bedingungen erfüllen, insbesondere auch solche Tupel, die nicht auf allen
Attributen definiert sind. Möchte man solche Anfragen mit der bisher vorgestellten Methode bearbeiten, so wird das im Allgemeinen nicht zum gewünschten
Ergebnis führen, wie folgendes Beispiel zeigt:
Gegeben sei folgender Datenbank-Zustand:
35
Buch
Verlag
ISBN
0-540-12345-1
0-673-12383-1
ISBN Code
0-540
Titel
Datenbanken
Java
Erscheinungsjahr
1996
1996
Auflage
1
1
Verlagsname
Addison-Wesley
Gegeben sei nun eine Anfrage nach allen nach 1994 oder im Addison-WesleyVerlag erschienenen Büchern:
SELECT Titel
WHERE Erscheinungsjahr > 1994
OR Verlagsname = ’Addison-Wesley’;
Die Bearbeitung dieser Anfrage mit der bisherigen Methode würde folgende
Definition der Hilfssichten UNION i und der Sicht VIEW 1 ergeben:
CREATE VIEW KANTE_0 AS
SELECT Titel, Erscheinungsjahr, ISBN
FROM Buch;
Diese Sicht enthält die Werte:
KANTE 0
Titel
Datenbanken
Java
Erscheinungsjahr
1996
1996
ISBN
0-540-12345-1
0-673-12383-1
CREATE VIEW KANTE_1 AS
SELECT ISBN, ISBN_CODE FROM WIRD_VERLEGT;
CREATE VIEW KANTE_2 AS SELECT ISBN_CODE, VERLAGSNAME
FROM VERLAG;
Die Sicht KANTE 1 enthält dann die Werte
KANTE 1
ISBN
0-540-12345-1
ISBN CODE
0-540
CREATE VIEW AHG_1 AS
SELECT KANTE_0.ERSCHEINUNGSJAHR ERSCHEINUNGSJAHR,
KANTE_2.VERLAGSNAME VERLAGSNAME,
KANTE_0.TITEL TITEL
FROM KANTE_0, KANTE_1, KANTE_2
WHERE KANTE_0.ISBN = KANTE_1.ISBN
AND KANTE_1.ISBN_CODE = KANTE_2.ISBN_CODE;
Diese Sicht enthält die Werte:
AHG 1
Titel
’Datenbanken’
Erscheinungsjahr
1996
Verlagsname
Addison-Wesley
Der Datensatz zum Buch Java ist nicht enthalten, da er auf den Attributen
ISBN und ISBN CODE in der Tabelle wird verlegt nicht definiert ist.
Die Anfrage würde lauten:
SELECT Titel
FROM KANTE_1
36
WHERE Erscheinungsjahr = 1996
OR Verlagsname = ’Addison-Wesley’;
Da in der Sicht VIEW 1 nur der Datensatz zum Buch Datenbanken vorkommt,
wird nur dieser von der Anfrage zurückgegeben, obwohl man eigentlich“ auch
”
den Datensatz zum Buch Java erwartet.
Um auch Anfragen mit OR-Bedingungen (Disjunktionen) zu ermöglichen, muß
das bisherige Konzept entsprechend erweitert werden. Um die Methode zu verstehen, vergegenwärtige man sich, daß eine Anfrage der Form
SELECT <attribute> WHERE <bedingung1> OR <bedingung2>
äquivalent ist zu einer Anfrage der Form
SELECT <attribute> WHERE <bedingung1>
UNION
SELECT <attribute> WHERE <bedingung2>
Dabei sind bedingung1 und bedingung2 Konjunktionen.
Um nun mit dem Universalrelation-System auch Anfragen mit disjunktiven Bedingungen zu verarbeiten, werden diese nach dem obigen Prinzip in mehrere
Teilanfragen von Konjunktionen zerlegt und diese dann mit den bisher bekannten Methoden abgearbeitet:
Der Bedingungsteil (die WHERE -Klausel) der von Benutzer angegebenen Anfrage wird durch Ausklammern und Ausmultiplizieren in eine disjunkte Form
gebracht, anschließend wird diese Anfrage in eine äquivalente Form von Teilanfragen zerlegt, welche durch den Mengenoperator UNION vereinigt werden:
Die Anfrage
SELECT <Select-Liste> WHERE <bedingungen>
wird umgeformt zu der Anfrage
SELECT <Select-Liste>
WHERE <DISJ_1> OR <DISJ_2> ... OR <DISJ_n>
und schließlich zu
SELECT <Select-Attribut-Liste> WHERE <DISJ_1>
UNION
SELECT <Select-Attribut-Liste> WHERE <DISJ_2>
...
UNION
SELECT <Select-Attribut-Liste> WHERE <DISJ_n>
Diese Anfrage wird wie gewohnt bearbeitet.
2.2.7
Beispiele
Anhand einiger ausgewählter Beispiel-Anfragen soll die Arbeitsweise des Universalrelation-Systems verdeutlicht werden.
Gesucht seien alle ISBN-Nummern im Bibliotheks-Datenbankschema.
37
Die zugehörige Universalrelation-Anfrage wäre:
SELECT ISBN;
Diese Anfrage würde vom Universalrelation-System folgendermaßen umgesetzt:
Es handelt sich offenbar um eine Anfrage ohne ODER-Bedingungen, Megenoperanden, Unteranfragen oder Datenbank-Variablen. Daher werden nur die Methoden des Universalrelation-Kernes benötigt.
Zuerst werden die Anfrageattributmenge“ X , die Select-Liste“ und die Select”
”
”
Attribut-Liste“ bestimmt. Diese sind in diesem Falle gleich X : X = {ISBN}.
Der Anfragehypergraph ergibt sich zu:
AHG X = { ISBN } Buch,wirdv erlegt,Autor,Exemplar
Damit wird also für jede Kante des Anfragehypergraphen (in diesem Fall nur
eine) eine Sicht erzeugt:
CREATE VIEW KANTE_0 AS
SELECT ISBN FROM Buch
UNION
SELECT ISBN FROM wird_verlegt
UNION
SELECT ISBN FROM Autor
UNION
SELECT ISBN FROM Exemplar;
Das Fenster“ und die Sicht mit den Ergebnistupeln werden erzeugt und die
”
Anfrage gestellt:
CREATE VIEW AHG_1 AS
SELECT UNION_1_0.ISBN ISBN
FROM KANTE_0;
CREATE VIEW UR_WINDOW AS
SELECT DISTINCT "ISBN" FROM AHG_1;
SELECT "ISBN"
FROM UR_WINDOW;
Abschließend werden alle zwischenzeitlich erzeugten Sichten gelöscht:
DROP VIEW UR_WINDOW;
DROP VIEW AHG_1;
DROP VIEW KANTE_0;
Betrachten wir nun ein komplexeres Beispiel:
Gesucht sind alle Filme, wobei der Regisseur nicht der Hauptdarsteller sein darf
oder der Film einen Nachfolger besitzt.
Die Anfrage an das Universalrelation-Systems lautet dann:
SELECT A.MovieTitle
WHERE A.Directorname NOT IN (
SELECT B.PlayerName
WHERE B.Pos = 1
38
AND B.MovieID = A.MovieID
)
OR A.SuccessorID IS NOT NULL;
Die Bearbeitung dieser Anfrage läuft wie folgt:
Der erste Schritt ist das Umformen der Bedingung in disjunktive Form (ist in
diesem Fall gleich der gegebenen Form). Anschließend wird die Anfrage in eine
Vereinigung von Teil-Anfragen umgeformt:
SELECT A.MovieTitle
WHERE A.Directorname NOT IN (
SELECT B.PlayerName
WHERE B.Pos = 1
AND B.MovieID = A.MovieID
)
UNION
SELECT A.MovieTitle
WHERE A.SuccessorID IS NOT NULL;
Die so entstandene Anfrage wird nach dem Verfahren für Mengenoperationen
weiter bearbeitet.
Es ergeben sich die beiden Teilanfragen
SET_0 :=
SELECT A.MovieTitle
WHERE A.Directorname NOT IN (
SELECT B.PlayerName
WHERE B.Pos = 1
AND B.MovieID = A.MovieID
)
SET_1 :=
SELECT A.MovieTitle
WHERE A.SuccessorID IS NOT NULL;
Eine weitere Analyse ergibt folgende Struktur:
auessere_Anfrage ( innere_anfrage ) UNION Teilanfrage
wobei gilt:
auessere_Anfrage :=
SELECT A.MovieTitle
WHERE A.Directorname NOT IN ( ... )
innere_anfrage :=
SELECT B.PlayerName
WHERE B.Pos = 1
AND B.MovieID = A.MovieID
Teilanfrage :=
SELECT A.MovieTitle
39
WHERE A.SuccessorID IS NOT NULL;
Diese werden der Reihe nach abgearbeitet, wobei mit der letzten zuerst angefangen wird.
In der Teilanfrage SET 0 ist eine Unteranfrage. Für diese wird nach dem Verfahren für geschachtelte Anfragen die Definition der Unteranfrage“ bestimmt:
”
SUBQUERY_1[A.MovieID] :=
SELECT DISTINCT "B.PlayerName"
FROM SUBQUERY_1_AHG_1
WHERE "B.Pos" = 1
AND "B.MovieID" = "A.MovieID"
Analog wird für jeden rechten Operanden“ einer Mengenoperation (in diesem
”
Fall nur einer) die Definition der Teilanfrage“ bestimmt:
”
SET_1 :=
SELECT DISTINCT "A.MovieTitle" FROM SET_1_AHG_1
WHERE "A.SuccessorID" IS NOT NULL;
Die einzelnen Kommandos lauten nun:
• Die Kanten für den Anfragehypergraph der letzten Teilanfrage:
CREATE VIEW SET_1_KANTE_A_0 AS
SELECT MovieID, SuccessorID
FROM follows;
CREATE VIEW SET_1_KANTE_A_1 AS
SELECT MovieID, MovieTitle
FROM Movie;
• Das Fenster“ für die letzte Teilanfrage::
”
CREATE VIEW SET_1_AHG_1 AS
SELECT SET_1_KANTE_A_0.SuccessorID "A.SuccessorID",
SET_1_KANTE_A_1.MovieTitle "A.MovieTitle"
FROM SET_1_KANTE_A_0, SET_1_KANTE_A_1
WHERE SET_1_KANTE_A_0.MovieID = SET_1_KANTE_A_1.MovieID;
Die Definition der Teilanfrage“:
”
SELECT DISTINCT "A.MovieTitle" FROM SET_1_AHG_1
WHERE "A.SuccessorID" IS NOT NULL;
• Die Kanten für den Anfragehypergraph der inneren Anfrage:
CREATE VIEW SUBQUERY_1_KANTE_B_0 AS
SELECT PlayerID, PlayerName
FROM Player;
CREATE VIEW SUBQUERY_1_KANTE_B_1 AS
SELECT MovieID, PlayerID, Pos
FROM plays;
• Das Fenster“ für die innere Anfrage:
”
40
CREATE VIEW SUBQUERY_1_AHG_1 AS
SELECT SUBQUERY_1_KANTE_B_1.Pos "B.Pos",
SUBQUERY_1_KANTE_B_1.MovieID "B.MovieID",
SUBQUERY_1_KANTE_B_0.PlayerName "B.PlayerName"
FROM SUBQUERY_1_KANTE_B_0, SUBQUERY_1_KANTE_B_1
WHERE SUBQUERY_1_KANTE_B_0.PlayerID = SUBQUERY_1_KANTE_B_1.PlayerID
• Die Kanten für den Anfragehypergraph der äußeren Anfrage:
CREATE VIEW KANTE_A_0 AS
SELECT DirectorID, DirectorName
FROM Director;
CREATE VIEW KANTE_A_1 AS
SELECT MovieID, DirectorID
FROM Directs;
CREATE VIEW KANTE_A_2 AS
SELECT MovieID, MovieTitle
FROM Movie;
• Das Fenster“ für die äußere Anfrage:
”
CREATE VIEW AHG_1 AS
SELECT KANTE_A_0.DirectorName "A.DirectorName",
KANTE_A_1.MovieID "A.MovieID",
KANTE_A_2.MovieTitle "A.MovieTitle"
FROM KANTE_A_0, KANTE_A_1, KANTE_A_2
WHERE KANTE_A_0.DirectorID = KANTE_A_1.DirectorID
AND KANTE_A_1.MovieID = KANTE_A_2.MovieID;
• Die Sicht der Ergebnistupel im ersten Schritt:
CREATE VIEW UR_WINDOW AS
SELECT DISTINCT "A.MovieTitle" FROM AHG_1
WHERE "A.DirectorName" NOT IN ( SUBQUERY_1[A.MOVIEID] )
UNION SET_1;
• Die Sicht der Ergebnistupel nach dem Einsetzen der Definitionen von
Unter- und Teilanfragen:
CREATE VIEW UR_WINDOW AS
SELECT DISTINCT "A.MovieTitle" FROM AHG_1
WHERE "A.DirectorName" NOT IN (
SELECT DISTINCT "B.PlayerName" FROM SUBQUERY_1_AHG_1
WHERE "B.Pos" = 1 AND "B.MovieID" = "A.MovieID" )
UNION
SELECT DISTINCT "A.MovieTitle" FROM SET_1_AHG_1
WHERE "A.SuccessorID" IS NOT NULL;
• Die Anfrage und abschließendes Aufräumen:
SELECT "A.MovieTitle" FROM UR_WINDOW;
DROP VIEW UR_WINDOW;
DROP VIEW AHG_1;
DROP VIEW KANTE_A_0;
41
DROP
DROP
DROP
DROP
DROP
DROP
DROP
DROP
VIEW
VIEW
VIEW
VIEW
VIEW
VIEW
VIEW
VIEW
KANTE_A_1;
KANTE_A_2;
SET_1_AHG_1;
SET_1_KANTE_A_0;
SET_1_KANTE_A_1;
SUBQUERY_1_AHG_1;
SUBQUERY_1_KANTE_B_0;
SUBQUERY_1_KANTE_B_1;
42
3
3.1
Literaturübersicht zum Thema Universalre”
lation-Systeme“
Vorläufer
Bereits 1976 haben Carlson und Kaplan in [CK76] ein Verfahren zur automatischen Erzeugung eines Zugriffsplanes für Datenbankanfragen vorgestellt. Sie
erkannten das Problem der semantischen Mehrdeutigkeit, das bei dem Vorhandensein mehrerer Zugriffspläne auftritt, und versuchten dieses zu lösen, indem
dem System Hinweise gegeben wurde, welche Relationen semantisch zueinan”
der“ gehören.
3.2
Theorie
Anfang der achtziger Jahre des letzten Jahrhunderts entwickelte sich eine rege
Diskussion um das Universalrelation-Modell. Während unter anderem Kent das
Modell einer universellen Relation“ in [Ken81] wegen Realitätsferne in Frage
”
stellte, bemühte sich Ullman in [Ull82c] um Klärung und Zusammenfassung. Er
stellte mehrere von verschiedenen Autoren entwickelte Modelle vor und bemühte
sich, von Gegnern dieses Modells aufgeworfene Einwände zu zerschlagen.
Ein Ansatz zur Entwicklung des Universalrelation-Modells war der von Maier
und Ullman in [MU81] entwickelte Ansatz der maximalen Objekte“. Dieser An”
satz geht von von der Annahme der Join Dependency“ aus, sieht also die Uni”
versalrelation als eine Sicht, entstanden aus dem natürlichen Verbund aller Relationen. Die Probleme, die durch γ-zyklische Datenbankschemas und hängende
”
Tupel“ entstehen, versuchen sie durch Zerlegung der Anfrage auf maximale
”
Objekte“ (das sind γ-azyklische Teilanfragehypergraphen) und der Vereinigung
dieser Teilergebnisse zu umgehen. Eine strengere Fassung des Ansatzes, die Einschränkung der Join Dependency“ auf γ-azyklische Schemas, beschreiben beide
”
Autoren in [MU82]. Ullman beschreibt in [Ull82a] und [Ull82b] die Implementierung von System/U“, einer Universalrelation-Benutzerschnittstelle. In weiteren
”
Arbeiten ([MUV82], [Ull83] ) fassen Ullman, Maier und Vardi den Stand der
Forschung zusammen.
Malvestuto und Moscarini stellen in [MM98] eine Optimierung der vom Maier
und Ullman entwickelten Methode zur Verbundbestimmung vor.
McCure Kuck und Sagiv beschreiben in [MKS82] die Implementierung eines
Datenbanksystems mit Universalrelation-Schnittstelle über einem NetzwerkDatenbanksystem.
Wie auch schon Maier und Ullman in [MU81], beschäftigte sich Laue in
[Lau82] mit dem Problem der hängenden Tupel“, also Tupeln, die nicht auf
”
allen Attributen in allen Relationen definiert sind. Laue erlaubt in seinem
Universalrelation-Modell Nullwerte nur auf den Attributen, die keine Schlüssel
sind, und definiert die Universalrelation als den Outer-Join über alle Relationen
und der zusätzlichen Bedingung, daß nur die Tupel enthalten sind, die auf den
Schlüssel-Attributen nicht Null sind.
43
In [BB83] stellen Brüggemann einen pragmatischen Zugang“ zum Konzept der
”
Universalrelation vor. Ausgehend von den Erfahrungen zweier Benutzergruppen,
den sporadischen“ (diese kennen nur die Attribute eines Datenbankschemas)
”
und den fortgeschrittenen“ Benutzern (diese kennen die Struktur des Daten”
bankschemas und benutzen das Universalrelation-System, um sich die Arbeit der
Verbundoperationen abnehmen zu lassen) entwickeln sie ein UniversalrelationModell, das auf der Vereinigung von teilweisen Verbunden der beteiligten Relationen basiert. zusammen mit Schnetgöke und Kramer führen sie in [BBSK86]
neben den Annahmen Universal Relation Scheme Assumption“ (URSA: die Be”
deutung der Attribute wird vollständig durch den Attributnamen ausgedrückt)
und Basic Connection Assumption“ ( BCA: Für alle Attributmengen X gibt
”
es genau eine elementare Beziehung zwischen den Attributen aus X) eine dritte
Annahme, die One Flavor Assumption“ (OFA: Die Bedeutung eines Attributes
”
in der Sicht auf die Universalrelation ist unabhängig von der Konstruktion dieser Sicht). Sie zeigen, daß γ-azyklische Datenbankschemas diese dritte Annahme
erfüllen, und führen aus, daß die Berechnung der Sicht auf die Universalrelation nach dem in [MU82] angegebenen Verfahren der GYO-Reduktion bestimmt
werden kann. Diese Ergebnisse lassen sie in das von ihnen entwickelte Universalrelation-System DURST einfließen. In [BB87] schließlich beschreiben sie für das
Universalrelation-System DURST eine SQL-ähnliche und eine QBE-ähnliche
Daten-Manipulations-Sprache.
Brüggemann vergleicht in [Brü86] verschiedene Semantiken von Universalrelation-Systemen, die Verbundpfadsemantik, eine von der unique minimal connec”
tion“ von Yannakakis abgeleitete und die von der modifizierten GYO-Reduktion
abgeleitete Semantik. Er zeigt, daß diese Semantiken nur für γ-azyklische Datenbankschemas die gleichen Ergebnisse liefert, und fordert daher die γ-Azyklizität
als notwendige Eigenschaft eines Datenbankschemas. Er führt als neue Bedingung die Intersection Database Scheme Assumption“ (IDSA: ) ein, welche die
”
URSA und BCA ersetzt.
Eine allgemeine Einführung in Universalrelation-Systeme gibt Vardi in [Var88].
Neben der Theorie stellt er eine einige Universalrelation-Systeme beispielhaft
vor. E. F. Codd, der Vater“ des relationalen Modells, reiht sich mit seiner Ant”
wort auf diesen Artikel ([Cod88]) in die Reihe der Kritiker des Universalrelation-Modells ein (vgl. auch [Ken81]).
3.3
Weiterführungen und Anwendungen
In [AP87] stellen Azar und Pichat einen Algorithmus zur Transformation eines
erweiterten Entity-Relationship-Modells in das Universalrelation-Modell mit
”
Einschlüssen“ vor. Dies ist eine Erweiterung des Universalrelation-Modells um
die Inclusion Dependency“, welche verlangt, daß für zwei Mengen von Attribu”
ten K und L und jedes Tupel t aus der Datenbank es ein Tupel t0 gibt, so daß
t[K] = t0 [L] gilt.
Levene und Loizou und später Levene allein entwickelten in [LL88], [Lev92] und
[LL94]für das Modell der geschachtelten Relationen“ eine Universalrelation”
Erweiterung, das nested UR model . Neben einer gründlichen Entwicklung dieses
Modells stellen sie in [LL89] eine an SQL angelehnte Anfragesprache vor.
44
Laurent, Luong und Spyratos in [LLS97] sowie auch Torlone und Atzeni in
[TA99] beschäftigen sich mit der Frage, wie Update- und Löschoperationen in
einem Universalrelation-System auf deterministische Weise ablaufen können.
Vermehrt findet das Universalrelation-Modell Verwendung als Benutzerschnittstelle für verteilte bzw. heterogene Datenbankmanagementsysteme oder Informationsquellen ([HL91] [ZSC95] [SW95] [RH96] [Rec97] [LW00] [KLSZ01] ).
45
4
Die Überarbeitung des bisherigen Universalrelation-Systems
Die Überarbeitung gliedert sich in drei Bereiche, wobei zwei davon der Vereinfachung des Programmes dienen, und der dritte direkt eine Verallgemeinerung
des Verfahrens umsetzt.
Die drei Bereiche sind:
1. Das Universalrelation-Schema wird nicht nur über Basisrelationen, sondern kann - bei Bedarf - auch über Sichten definiert werden.
2. Die Universalrelation-System-Schnittstelle wird als Java-Applet zur Verfügung gestellt, um sie internetfähig zu machen.
3. Die Bearbeitung von Disjunktionen (OR) und von Vereinigungen
(UNION ) wird vereinheitlicht.
4.1
Erweiterung auf Sichten
Wie in [Bor01] beschrieben, muß dem Universalrelation-System die Struktur
des Datenbank-Schemas mitgeteilt werden. Der bisherige Weg war der, eine
SQL-Kommando-Datei, welche alle CREATE TABLE -Befehle der beteiligten
Relationen enthält, vom System parsen zu lassen. Das System war bisher nur in
der Lage, SQL-Kommandos zur Erzeugung von Relationen korrekt zu parsen.
Es ist allerdings wünschenswert, wenn das System auch mit Sichten umgehen
kann, und der im Abschnitt 4.2 in [Bor01] beschriebene Workaround“ erscheint
”
nicht praktikabel genug. Daher wird nach einer Lösung gesucht, die auch die
Struktur von Sichten korrekt erkennt.
Es werden nun zwei verschiedene Möglichkeiten diskutiert, wie diese Lösung
aussehen könnte:
1. Wie bisher die SQL-Kommandodatei parsen und die Prozedur erweitern
um die Möglichkeit, View-Definitionen parsen zu können.
2. Einen neuen Weg gehen und die Definition einer Tabelle oder Sicht über
JDBC-Metadaten-Befehle erlangen.
Der Vorteil der ersten Methode ist, daß das Konzept und damit die Programmstruktur gleich bleibt, und nur die Parser-Methode um die Behandlung von
CREATE VIEW -Kommandos erweitert werden muß.
Der Datentyp eines Attributes ergibt sich allerdings nicht mehr explizit, sondern
muß aus dem EXPR des SUBQUERYs in der Sicht-Definition bestimmt werden.
Die ist i. A. nicht trivial, wie folgendes Beispiel zeigt:
SQL> create table t (t1 varchar2(10), t2 number(12, 5));
Table created.
SQL> create view v1 as select t1 || t1 v1 from t;
46
View created.
SQL> create view v2 as select t1 || ’10 laenger’ v2 from t;
View created.
SQL> create view v3 as select t1 || t2 v3 from t;
View created.
SQL> desc t;
Name
Null?
Type
---------------------------- -------- ----------------------T1
VARCHAR2(10)
SQL> desc v1
Name
Null?
Type
---------------------------- -------- ----------------------V1
VARCHAR2(20)
SQL> desc v2;
Name
Null?
Type
---------------------------- -------- ----------------------V2
VARCHAR2(20)
SQL> desc v3;
Name
Null?
Type
---------------------------- -------- ----------------------V3
VARCHAR2(50)
Der Datentyp des Attributes V1 ergibt sich aus der Summe der Länge der
Datentypen von T1 und T1 .
Der Datentyp des Attributes V2 ergibt sich aus der Länge von T1 und der
Länge der Zeichenkettenkonstanten ’10 laenger’.
Während der Datentyp des Attributes V1 noch relativ leicht zu ermitteln ist,
wenn man den Datentyp des Attributes T1 kennt, so ist dies beim Datentyp
des Attributes V2 schon komplizierter (hier muß beim Parsen die Länge der
Konstanten ermittelt werden), und beim Datentyp des Attributes V3 reicht
dieses Vorgehen nicht aus - man benötigt Kenntnisse über das interne Vorgehen
es DBMS, um zu verstehen, wie der Datentyp von V3 die Länge 50 bekommt,
und nicht, wie vielleicht erwartet, die Länge 23 (10 von T1 , 12 von T2 und 1
vom Dezimalpunkt).
Dies betrachte ich als einen großen Nachteil dieser Methode, da hier einerseits
die Fehleranfälligkeit hoch ist, und es andererseits kompliziert ist, alle internen
Besonderheiten heraus zu finden, die hier auftreten können.
Die zweite vorgeschlagene Methode, die Erkennung der Schema-Struktur über
JDBC-Metadaten, erfordert zunächst eine Änderung der Programmstruktur.
47
Allerdings wird der Nachteil der ersten Methode umgangen, da Sichten und
Relationen gleich behandelt werden. Desweiteren kann auch das Konzept der
Synonyme mit behandelt werden. Dies wiegt in meinen Augen den Nachteil der
Neustrukturierung des Programmes auf.
Ein weiterer Nachteil allerdings kann nicht umgangen werden:
Enthält eine Relation (oder Sicht oder Synonym) ein Attribut des Datentyps
MLSLABEL, so arbeitet die JDBC-Schnittstelle dies nicht korrekt ab (es wird
mit der Fehlermeldung ORA-00932: inconsistent datatypes abgebrochen). Dies
ist aber keine schwerwiegende Einschränkung in meinen Augen, da laut der
Oracle-SQL-Dokumentation ([Ora97]) dieser Datentyp nur aus Abwärtskompatibilität zu alten Versionen mit Trusted Oracle unterstützt wird, also ein sehr
spezieller Fall ist. Desweiteren wurde dieser Datentyp bisher auch nicht unterstützt, da alle SQL-Befehle über die JDBC-Schnittstelle laufen.
Insgesamt bietet die zweite Methode einen unkomplizierteren Ansatz, um die
Schema-Informationen einzulesen (auch für den Benutzer dieses Systems - er
muß dem System nur noch die Namen der benötigten Relationen und Sichten
mitteilen), so daß bei der Überarbeitung des Programms diese Methode benutzt
wird.
Die genaue Arbeitsweise soll nun erläutert werden:
Wie bei der Arbeit mit der JDBC-Schnittstelle gewohnt (vgl. Abschnitt 5.3 in
[Bor01]), wird zunächst eine Verbindung zum Datenbankserver eröffnet. Dann
wird für jede Relation oder Sicht, deren Struktur gewünscht ist, an den Server
eine Anfrage gestellt, die alle Attribute der gewünschten Relation oder Sicht
einschließt - in der Regel ist das die Anfrage
SELECT * FROM <table_name>;
Dadurch wird eine Instanz der Klasse java.sql.ResultSet erzeugt, von der
man mit der Methode getResultSetMetaData() eine Instanz der Klasse
java.sql.ResultSetMetaData erhält. Mit den Methoden dieser Klasse lassen sich
nun Name und Typ aller im Ergebnis vorkommenden Attribute ermitteln - das
sind in diesem Fall alle Attribute der Relation oder Sicht:
ResultSet rs
ResultSetMetaData rsmd
= stmt.executeQuery(query);
= rs.getMetaData();
// Die Anzahl der Attribute:
int colnum = rsmd.getColumnCount();
for (int i = 1; i <= colnum; i++) {
// Der Name des Attributes:
String name
= rsmd.getColumnName(i);
// Der Datentyp des Attributes:
String type
= rsmd.getColumnTypeName(i);
// Details des Datentyps:
int length
= rsmd.getColumnDisplaySize(i);
int precision = rsmd.getPrecision(i);
int scale
= rsmd.getScale(i);
}
48
4.2
Umwandlung der Applikation in ein Applet
Der grundlegende Unterschied zwischen Applets und Applikationen ist, daß Applets in einer Browser-Umgebung laufen, und prinzipiell dafür gedacht sind, über
das Internet ausgetauscht zu werden.
Um dem mißbräuchlichen Gebrauch solcher Applets zu verhindern, unterliegen
Applets gegenüber Applikationen zwei wesentlichen Restriktionen:
• Sie dürfen keine Dateien auf dem System lesen und schreiben, auf dem sie
laufen,
• Sie dürfen keine Netzwerkverbindungen zu anderen Servern aufbauen, außer zu dem Server, von dem sie geladen wurden.
Es soll nun kurz erläutert werden, inwiefern diese Restriktionen das Programm
betreffen, und wie diese Restriktionen sinnvoll umgangen werden können.
4.2.1
Einschränkungen eines Applets
Die Möglichkeit, Dateien lesen und schreiben zu können wurde bisher verwendet, um Programmeinstellungen zu speichern und DatenbankBeschreibungen zu lesen. Dies wird im Applet umgangen, indem Einstellungen
nicht gespeichert werden, bzw. über die aufzurufende HTML-Seite übergeben
werden. Die Datenbank-Beschreibungen werden auf dem Web-Server abgelegt was allerdings die Wartung für Benutzer kompliziert macht - oder die Beschreibungen könnten auf einem beliebigen dem Benutzer zugänglichen Webspace
abgelegt werden, und von dort aus eingelesen werden (da angeblich Dateien in
Form von URLs (URL: Uniform Resource Locator) gelesen werden können).
Auf die Feinheiten der HTML-Programmierung soll an dieser Stelle nicht eingegangen werden, und wir gehen davon aus, daß alle für das Applet notwendigen
Parameter über die aufrufende HTML-Seite übergeben werden.
Die Möglichkeit, Netzwerkverbindungen herstellen zu können wurde bisher verwendet, um mit dem DBMS zu kommunizieren, ist also ein zentraler Bestandteil der Applikation. Im Applet ist diese Kommunikation nur noch möglich,
falls das DBMS auf demselben Rechner wie der Web-Server läuft. Da dies in den
seltensten Fällen der Fall sein wird, ist dies eine ernstzunehmende Einschränkung. Diese ist im Applet nicht einfach zu umgehen. Eine Möglichkeit wäre die
Programmierung einer Client-Server-Anwendung, wobei der Client das Applet
ist, und der Server eine Applikation. Diese muß dann auf dem Webserver laufen,
und kommuniziert mit dem Datenbank-Server, und liefert die entsprechenden
Daten an das Applet weiter. Dieser Ansatz ist allerdings nicht optimal, da er
letztendlich nicht wirklich aus der bisherigen Applikation ein Applet macht. Wir
werden diesen Ansatz hier nicht weiter verfolgen, sondern gehen davon aus, daß
das Applet mit dem DBMS kommunizieren kann (also auf demselben Rechner
liegt).
49
<HTML>
<HEAD></HEAD>
<BODY>
<APPLET code="UrApplet" archive="./ur.jar" codebase="." >
<PARAM name=dburl
value="jdbc:oracle:thin:@db.server.com:1521:instance">
<PARAM name=driver value="oracle.jdbc.driver.OracleDriver">
<PARAM name=file
value="files/bib.txt">
<PARAM name=user
value="bib">
<PARAM name=pass
value="bibpw">
<PARAM name=anf
value="Select Autorenname, Titel">
</APPLET>
</BODY>
</HTML>
Tabelle 6: HTML-Seite zum Aufruf des Universalrelation-System-Applets
4.2.2
Änderungen am Programm
Neben den bei einer Umwandlung einer Applikation in ein Applet üblichen Änderungen (Die Hauptklasse statt von java.lang.Object nun von java.applet.Applet
ableiten, statt der Methode main{String[] argv} nun die Methoden init() und
start() definieren, usw.) wurden aufgrund der im vorigen Abschnitt erläuterten
Einschränkungen folgendes geändert:
Datenbank-Beschreibungen können nicht mehr über eine Datei vom Benutzer ausgewählt und eingelesen werden. Stattdessen wird dem Applet
beim Start ein URL übergeben, der auf die Datei mit der Beschreibung
verweist. Dies führt dazu, daß ein anderes Datenbankschema nur durch
Neustart des Applets ausgewählt werden kann.
Intern arbeitet die Klasse dbis.appl.liste.MetaDaten nun nicht mehr
mit einem java.io.File -Object als Datenquelle, sondern mit einem
java.io.InputStream-Object.
Programm-Optionen werden nicht mehr nach Beenden des Programms abgespeichert, sondern werden dem Applet beim Start übergeben. Allerdings
können diese im laufenden Betrieb noch geändert werden.
Der Aufruf des Applets erfolgt über eine HTML-Seite mit dem APPLET -Tag.
Diese Seite muß mindestens die in Tabelle 6 aufgeführten Angaben erhalten:
Die Parameter dburl , driver und file sind zwingend, die restlichen Parameter
können weggelassen werden. Die Bedeutung der Parameter ist folgende:
50
Name
dburl
driver
file
user
pass
anf
4.3
Beispiel-Wert
Beschreibung
jdbc:oracle:thin:@db.server.com:1521:orcl Der JDBC-Connect-String
oracle.jdbc.driver.OracleDriver
Der Bezeichner für die JDBCTreiber-Klasse
files/bib.txt
enthält einen URL (absolut
oder relativ), der auf die
Datenbank-BeschreibungsDatei verweist.
bib
Der Benutzername für die Datenbank
bibpw
Das Passwort des DatenbankBenutzers
Select Autorenname, Titel
Die Anfrage, die voreingestellt
im Anfrage-Fenster des Applets erscheint
Vereinheitlichung von Disjunktionen und Vereinigungen
Die in [Bor01] beschriebenen Verfahren für die Behandlung von Anfragen mit
ODER-Bedingungen oder mit Mengen-Operationen lauten in Kurzform:
• ODER-Bedingungen:
– Anfrage:
SELECT <Select-Liste>
WHERE <bedingung1> OR <bedingung2>;
– Verfahren:
∗ Umformen der Anfrage in Teilanfragen:
SELECT <Attribut-Liste> WHERE <bedingung1>
UNION
SELECT <Attribut-Liste> WHERE <bedingung2>;
∗ Jede Teilanfrage einzeln bearbeiten
∗ Die Teilanfragen vereinigen und die Anfrage stellen:
CREATE VIEW UR_WINDOW AS
SELECT <Attribut-Liste> FROM VIEW_1
WHERE <bedingung1>
UNION
SELECT <Attribut-Liste> FROM VIEW_2
WHERE <bedingung2>;
SELECT <Select-Liste> FROM UR_WINDOW;
• Mengen-Operation:
– Anfrage:
51
SELECT <Select-Liste1>
<Set-Op>
SELECT <Select-Liste2>;
– Verfahren:
∗ Jede Teilanfrage einzeln bearbeiten
∗ Die Teilanfragen vereinigen und die Anfrage stellen:
CREATE VIEW UR_WINDOW AS
SELECT <Attribut-Liste1> FROM VIEW_1
<Set-Op>
SELECT <Attribute-Liste2> FROM SET_1_VIEW_1;
SELECT <Select-Liste1> FROM UR_WINDOW;
Wenn nun im zweiten Fall der Mengenoperand Set-Op“ ein UNION ist, so
”
fällt auf, daß beide Verfahren sich stark ähneln - im Prinzip laufen sie nach der
Umformung der Anfrage mit ODER-Bedingungen analog.
Hinzu kommt, daß die Sicht UR WINDOW nur für ODER-Bedingungen wirklich nötig ist (in den anderen Fällen wird sie nur aus Transparenzgründen und
der Übersicht halber mit erzeugt).
Diese beiden Punkte lassen die Frage aufkommen, in wie weit diese beiden Verfahren zu einem einzigen Verfahren zusammengefaßt werden können.
Beispiel:
Anfrage
::=
SELECT sum(Auflage)
WHERE Autorenname = ’Knuth’
OR Verlagsname = ’Addison-Wesley’;
Anfrage_1
::=
SELECT Auflage WHERE Autorenname = ’Knuth’;
Anfrage_2
::=
SELECT Auflage WHERE Verlagsname = ’Addison-Wesley’;
...
CREATE VIEW VIEW_1 AS
SELECT Auflage, Autorenname
FROM UNION_1_0, UNION_1_1
WHERE UNION_1_0.ISBN = UNION_1_1.ISBN;
CREATE VIEW VIEW_2 AS SELECT
Auflage, Verlagsname
FROM UNION_2_0, UNION_2_1, UNION_2_2
WHERE UNION_2_0.ISBN = UNION_2_1.ISBN
AND UNION_2_1.ISBN_CODE = UNION_2_2.ISBN_CODE;
52
CREATE VIEW UR_WINDOW
SELECT Auflage FROM
WHERE Autorenname
UNION
SELECT Auflage FROM
WHERE Verlagsname
AS
VIEW_1
= ’Knuth’
VIEW_2
= ’Addison-Wesley’;
SELECT sum(Auflage) FROM UR_WINDOW;
oder als UNION“-Fall:
”
Anfrage_3
::=
SELECT Auflage where Autorenname = ’Knuth’
UNION
SELECT Auflage WHERE Verlagsname = ’Addison-Wesley’;
...
CREATE VIEW VIEW_1 AS
SELECT Auflage, Autorenname
FROM UNION_1_0, UNION_1_1
WHERE UNION_1_0.ISBN = UNION_1_1.ISBN
CREATE VIEW SET_1_VIEW_1 AS
SELECT Auflage, Verlagsname
FROM SET_1_UNION_1_0, SET_1_UNION_1_1, SET_1_UNION_1_2
WHERE SET_1_UNION_1_0.ISBN = SET_1_UNION_1_1.ISBN
AND SET_1_UNION_1_1.ISBN_CODE = SET_1_UNION_1_2.ISBN_CODE;
CREATE VIEW UR_WINDOW
SELECT Auflage FROM
WHERE Autorenname
UNION
SELECT Auflage FROM
WHERE Verlagsname
AS
VIEW_1
= ’Knuth’
SET_1_VIEW_1
= ’Addison-Wesley’;
SELECT Auflage FROM UR_WINDOW;
Man sieht an diesem Beispiel, daß der Ablauf bis auf Kleinigkeiten
(SET 1 VIEW 1 statt VIEW 2 etc.) und die SELECT -Anfrage identisch ist.
Die Idee ist nun, eine Anfrage mit ODER-Bedingungen durch Umwandlung in
disjunktive Form und dann in eine Anfrage mit UNION-Operatoren genauso
wie eine solche zu behandeln, und nur bei der letztlichen SELECT-Anfrage die
Select-Liste der ursprünglichen Anfrage zu verwenden.
Man beachte, daß dies nur funktionieren kann, solange in der Anfrage mit
ODER-Bedingungen in der Select-Liste keine Aggregatfunktionen vorkommen,
wie folgendes Gegenbeispiel zeigt:
Gegeben sei vom Benutzer die Anfrage
SELECT count(pos) WHERE pos < 2 OR pos > 3;
53
Diese Anfrage nach Zerlegung in disjunktive Form sähe dann folgendermaßen
aus
SELECT count(pos) FROM Autor WHERE pos < 2
UNION
SELECT count(pos) FROM Autor WHERE pos > 3
und sollte einen Wert zurückliefern, aber nach dem bisherigen Verfahren erhält
man für jeden Term der Mengenoperation einen Wert.
Aus diesem Grunde wird verlangt, das Vorkommen von Aggregatfunktionen in
der Anfragesprache auszuschließen.
Damit ergibt sich folgender Ablauf der Anfrage:
• Wandle in jeder (Teil-)Anfrage mit ODER-Bedingungen die Bedingung in
disjunktive Form um.
• Wandle die (Teil-)Anfrage von der disjunkten Form in eine Anfrage mit
UNION -Operatoren um.
• Bearbeite jede (Teil-)Anfrage wie gewohnt ab.
54
5
Optimierungsuntersuchungen
5.1
5.1.1
Ersetzen der Sicht-Definitionen
Mehrfach vorkommende Hypergraph-Kanten
Beim Bearbeiten komplexerer Anfragen, insbesondere Anfragen mit ODERBedingungen fällt auf, daß manche Attribute in mehreren Teilen der Anfrage
vorkommen. Bei Anfragen mit ODER-Bedingungen sind dies auf jeden Fall alle
Select-Attribute, da diese bei allen für jeden Disjunkt der Anfrage-Bedingung
erzeugten Teilanfragen gleich sind. Dies führt dazu, daß dann auch in den verschiedenen Anfrage-Hypergraphen dieser Teilanfragen einige Kanten (teilweise)
gleich sind in dem Sinne, daß Kantei im einem Anfragehypergraphen eine Untermenge der Attribute derselben Relation der Kantej eines anderen Anfragehypergraphen enthält:
Beispiel:
Kante_1: SELECT ISBN, TITEL FROM BUCH
Kante_2: SELECT ISBN, TITEL, ERSCHEINUNGSJAHR, AUFLAGE FROM BUCH
Folgende Kanten sind nicht gleich:
Kante_3: SELECT ISBN FROM BUCH
UNION SELECT ISBN FROM WIRD_VERLEGT
UNION SELECT ISBN FROM AUTOR
UNION SELECT ISBN FROM EXEMPLAR
Kante_4: SELECT ISBN, TITEL FROM BUCH
Ein erster Optimierungsansatz besteht hier darin, solche doppelt vorkommen”
den“ Kanten nur einmal zu erzeugen, und in den anderen Teilanfragen auf die
schon erzeugte Kante zu verweisen.
Der Gewinn aus dieser Maßnahme besteht darin, daß nun weniger Sichten erzeugt werden müssen.
Demgegenüber steht ein erhöhter Aufwand bei der Erzeugung der Sichtdefinitionen, da nun bei jeder Kante zuerst geprüft werden muß, ob sie bereits zu
einer bisher erzeugten Kante im oben beschriebenen Sinne gleich ist. Desweiteren geht die hier beschriebene Maßnahme in der folgenden auf, so daß auf eine
weitere Untersuchung dieses Ansatzes verzichtet wird.
5.1.2
Verzicht auf Sichten-Erzeugung
Sichten sind, gespeicherte Anfragen“ in dem Sinne, daß die Anfrage an eine
”
Sicht
SELECT <Attribut-Liste> FROM <view_name> [WHERE <cond> ...];
mit der Definition der Sicht
CREATE VIEW <view_name>
AS <Sicht_Definition>
55
äquivalent ist zu der Anfrage
SELECT <Attribut-Liste> FROM
(
<Sicht_Definition>
) [WHERE <cond> ...];
, also zu der Anfrage, in der die Sicht durch ihre Definition ersetzt wurde.
Daraus folgt insbesondere, daß man in Anfragen stets die Verwendung einer
Sicht vermeiden kann, indem eine äquivalente Unteranfrage in der FROM Klausel benutzt wird.
Untersucht wird nun die Frage, inwiefern die Tatsache, das bisher im Verfahren explizit mit Sichten anstatt nur mit deren Definition gearbeitet wird, einen
Einfluß auf den Verarbeitungsaufwand einer Universalrelation-System-Anfrage
hat.
Dazu wird untersucht, wie sehr das Oracle-DBMS mit den einzelnen Teilen
dieses Verfahrens
1. Erzeugung der Sichten (CREATE VIEW )
2. Stellen der Anfrage an die Sichten (SELECT FROM )
3. Löschen der Sichten (DROP VIEW )
beschäftigt ist.
Betrachten wir den ersten Teil, das Erzeugen der Sichten. Dies kann unter bestimmten Voraussetzungen einen beträchtlichen Zeitaufwand kosten, wie folgendes Beispiel zeigt:
Betrachten wir folgende Befehle zur Erzeugung von Sichten:
CREATE
CREATE
CREATE
...
CREATE
CREATE
CREATE
VIEW View_0 AS (SELECT isbn FROM autor);
VIEW View_1 AS (SELECT isbn FROM View_0);
VIEW View_2 AS (SELECT isbn FROM View_1);
VIEW View_30 AS (SELECT isbn FROM View_29);
VIEW View_31 AS (SELECT isbn FROM View_30);
VIEW View_32 AS (SELECT isbn FROM View_31);
Diese Befehlsfolge erzeugt eine künstliche“ Verschachtelung von Sichten, in der
”
jede Sicht alle Attribute der vorangegangenen Sicht ohne Einschränkungen selektiert.
Der Zugriffsplan einer Select-Operation auf die Sicht VIEW 32 sieht folgendermaßen aus:
56
Die Zeit, die zum Erzeugen dieser Sichten benötigt wird, wurde mit dem
Sql*Plus-Befehl set timing on angezeigt, die Ergebnisse lauten wie folgt:
Sicht
Zeit / sec
Sicht
Zeit / sec
Sicht
Zeit / sec
Sicht
Zeit / sec
Sicht
Zeit / sec
0
0.03
7
0.01
14
0.05
21
0.33
28
37.71
1
2
3
4
0.01 0.03 0.01 0.01
8
9
10
11
0.03 0.01 0.05 0.01
15
16
17
18
0.03 0.03 0.05 0.06
22
23
24
25
0.63 1.23 2.38 4.76
29
30
31
75.55 151.55 301.80
5
6
0.03 0.01
12
13
0.03 0.03
19
20
0.10 0.20
26
27
9.50 18.88
32
603.88
Insbesondere bei der Betrachtung der Zeiten ab Sicht VIEW 16 (die Zeiten für
die Sichten 0 bis 15 sind im Rahmen der Meßgenauigkeit zu unpräzise) fällt
einem eine ständige Verdoppelung auf, der Zeitbedarf ist O(2n ).
Der zweite Teil, das Stellen der Anfrage an die Sicht VIEW 32 , benötigt 1208.48
Sekunden.
Nur das Löschen der Sichten nimmt einen normalen“ Zeitverbrauch in An”
spruch: Es benötigt jeweils etwa 0.25 Sekunden pro Sicht, also insgesamt 8.25
Sekunden.
Die gesamten Operationen zusammen (CREATE , SELECT , DROP) benötigten
also
CREATE
SELECT
DROP
Σ
+
1209.02 sec
1208.48 sec
8.25 sec
2425.75 sec
insgesamt über 40 Minuten.
Zum Vergleich wurde die gleiche Anfrage ohne Sichten, aber mit Unteranfragen
gestellt:
SELECT * FROM
( SELECT isbn FROM
( SELECT isbn FROM
...
--View_32
--View_31
( SELECT isbn FROM
57
--View_2
( SELECT isbn FROM
( SELECT isbn FROM autor )
)
)
--View_1
--View_0
...
)
);
Für die Bearbeitung dieser Anfrage benötigte das System 0.43 Sekunden.
Daß die Verarbeitung von verschachtelten Sichten nicht immer so viel Zeit beansprucht, zeigt das folgende Beispiel:
create VIEW View_0 AS (SELECT isbn FROM autor);
create VIEW View_1 AS (SELECT isbn FROM autor
WHERE isbn in (SELECT isbn FROM View_0 ) );
create VIEW View_2 AS (SELECT isbn FROM buch
WHERE isbn in (SELECT isbn FROM View_1 ) );
...
create VIEW View_31 AS (SELECT isbn FROM autor
WHERE isbn in (SELECT isbn FROM View_30 ) );
create VIEW View_32 AS (SELECT isbn FROM buch
WHERE isbn in (SELECT isbn FROM View_31 ) );
Mit dieser Befehlsfolge wird wiederum eine Verschachtelung erreicht, allerdings
ist hier der Zugriffsplan einer Select-Operation auch verschachtelt, wie folgende
Grafik des Zugriffsplanes für die Sicht View 6 zeigt:
Das Erzeugen der Sichten geht hier in O(n) vor sich, pro Sicht werden etwa 0.1
Sekunden benötigt, also insgesamt etwa 3.3 Sekunden.
Das Stellen der Anfrage an die Sicht View 32 benötigte etwa 765.18 Sekunden,
das Löschen der Sichten pro Sicht etwa 0.25 Sekunden, also insgesamt 8.25
Sekunden. Dies ergibt als Gesamtsumme
58
CREATE
SELECT
DROP
Σ
+
3.30 sec
765.18 sec
8.25 sec
776.73 sec
Betrachten wir im Vergleich dazu die äquivalente Anfrage mit Unteranfragen:
SELECT isbn FROM
(SELECT isbn FROM buch WHERE isbn in
( SELECT isbn FROM
(SELECT isbn FROM autor WHERE isbn in
( SELECT isbn FROM
(SELECT isbn FROM buch WHERE isbn in
...
( SELECT isbn FROM
(SELECT isbn FROM autor WHERE isbn in
( SELECT isbn FROM
(SELECT isbn FROM autor) )
) )
...
) )
) )
);
-- View_32
-- View_31
-- View_30
-- View_1
-- View_0
Für diese Anfrage benötigte das Oracle-DBMS 772.16 Sekunden.
5.1.3
Fazit
Im Abschluß ist festzustellen, daß die Verwendung einer Unteranfrage anstatt einer Sicht nicht mehr (manchmal sogar erheblich weniger) Zeit für eine SELECT Operation beanspruchen kann. Hinzu kommt noch die Zeit-Ersparnis, die durch
das Wegfallen der CREATE - und DROP-Operationen gewonnen wird (insbesondere die CREATE -Operationen können manchmal teuer sein). Auf der praktischen Seite wird durch das Verwenden von Unteranfragen die TransaktionsVerarbeitung vereinfacht (statt einer Menge von 2k + 1, (k: Anzahl der Sichten)
Anfragen wird nur noch eine Anfrage benötigt).
Das hier vorgestellte Universalrelation-System erzeugt genau die Schachtelungstiefe, die der Benutzer durch seine Anfrage vorgibt: Bei der Verwendung einer
k-fach verschachtelten Unteranfrage ergibt sich eine k + 1-fach verschachtelte
Anfrage an das DBMS. Der hohe Zeitbedarf entsteht also nur, wenn der Benutzer selbst eine stark verschachtelte Anfrage an das Universalrelation-System
stellt.
5.2
Verwendung von Outer-Joins
Das bisherige Verfahren zur Erzeugung des Anfragehypergraphen benutzte immer den sogenannten inneren Verbund, oder auch Inner-Join genannt, (im
DBMS Oracle realisiert durch den =“-Operator) zur Verbindung zweier Re”
lationen. Dieser Verbundoperator hat die Eigenschaft, daß nur Tupel im Ergebnis erscheinen, wenn sie die Verbundbedingung erfüllen und auf den Attributen
59
definiert sind, die in der Verbundbedingung vorkommen. Dies führte dazu, daß
bei der Behandlung von Anfragen mit ODER-Bedingungen diese in einzelne
Disjunkte zerlegt werden müssen.
Der äußere Verbund oder auch Outer-Join ist eine Art Erweiterung des
Inner-Joins in der Form, daß beim Outer-Join zweier Relationen R1 und R2
mit der Verbundbedingung R1 .Ai = R2 .Bj im Ergebnis nicht nur alle Tupel
vorkommen, die diese Bedingung erfüllen, sondern auch alle Tupel, die auf den
Attributen Ai oder Bj nicht definiert sind, und zwar in der Form, daß alle Tupel, die kein passendes Gegenstück“ in der anderen Relation haben, für jedes
”
Attribut aus der anderen Relation um einen NULL-Wert erweitert werden.
Es wird unterschieden zwischen Left- bzw. Right- Outer-Join (nur die Tupel
aus der linken“ bzw. rechten“ Relation ohne Gegenstück werden dem Ergebnis
”
”
hinzugefügt) und dem Full-Outer-Join, bei dem alle Tupel aus beiden Relationen
berücksichtigt werden. Es gilt folgende Beziehung:
R1 FULL OUTER JOIN R2 ON R1 .Ai = R2 .Bj ⇔
(R1 LEFT OUTER JOIN R2 ON R1 .Ai = R2 .Bj
UNION
R1 RIGHT OUTER JOIN R2 ON R1 .Ai = R2 .Bj )
Laut [Dat00] wird ein Left-Outer-Join (und analog dazu ein Right-Outer-Join)
zwischen zwei Relationen R1 und R2 (mit den Attributen A1 , . . . , Ai , . . . , An1 in
R1 und B1 , . . . , Bj , . . . , Bn2 in R2 ) und der Verbundbedingung R1 .Ai = R2 .Bj
wie folgt konstruiert:
R1 LEFT OUTER JOIN R2 ON R1 .Ai = R2 .Bj :⇔
(R1 JOIN R2 )
UNION
( EXTEND ((R1 {Ai } MINUS R2 {Bj }) JOIN R1 )
ADD NULL AS B1 , . . . , NULL AS Bj−1 ,
NULL AS Bj+1 , . . . , NULL AS Bn2 , )
Analog dazu kann man auch einen Outer-Join für mehr als zwei Relationen und
mehr als einer Vergleichs-Operation in der Verbundbedingung konstruieren.
Für die Belange einer Universalrelation-System-Anfragebearbeitung interessant
ist der Full-Outer-Join, da dann die Bearbeitung der Anfragen mit ODERBedingungen stark vereinfacht wird.
In diesem Abschnitt soll nun untersucht werden, inwiefern die Verwendung des
Outer-Joins bei der Anfragebearbeitung zu Optimierungen führt.
5.2.1
Outer-Join und Oracle8T M
Das DBMS Oracle8T M stellt laut [Ora97] mit dem (+)-Operator einen Operator
für Outer-Joins zur Verfügung.
Es gelten folgende Einschränkungen für den Outer-Join-Operator (+):
• Dieser Operator ermöglicht keinen Full Outer Join, sondern nur Left- bzw.
Right Outer Joins.
60
• Ein Join-Operator kann nur auf maximal zwei Relationen gleichzeitig angewandt werden.
Diese Einschränkungen lassen sich glücklicherweise durch geschicktes Konstruieren der Anfrage umgehen, wie folgendes Beispiel verdeutlichen möge:
Gegeben sei folgende Datenbankausprägung:
Autor
Buch
ISBN
0-201-38590-2
0-540-12345-1
ISBN
0-666-98765-1
0-201-38590-2
Autorenname
C. J. Date
Erich Kästner
Titel
Schlafes Bruder
Database Systems
Der Outer-Join dieser beiden Relationen über das Attribut ISBN sollte dann
folgendes Ergebnis liefern:
ISBN
0-201-38590-2
0-540-12345-1
0-666-98765-1
Autorenname
C. J. Date
Erich Kästner
Titel
Database Systems
Schlafes Bruder
Da der (+)-Operator immer nur den Left- oder Right Outer Join liefert, nimmt
man beide Join-Varianten und vereinigt beide Ergebnisse:
Der Right Outer Join
SELECT b.isbn, a.autorenname, b.titel
FROM autor a, buch b
WHERE a.isbn (+) = b.isbn;
liefert
ISBN
0-201-38590-2
0-666-98765-1
Autorenname
C. J. Date
Titel
Database Systems
Schlafes Bruder
, der Left Outer Join
SELECT a.isbn, a.autorenname, b.titel
FROM autor a, buch b WHERE a.isbn = b.isbn (+);
liefert
ISBN
0-201-38590-2
0-540-12345-1
Autorenname
C. J. Date
Erich Kästner
Titel
Database Systems
, und die Vereinigung der beiden Anfragen
SELECT
FROM
UNION
SELECT
FROM
b.isbn, a.autorenname, b.titel
autor a, buch b WHERE a.isbn (+) = b.isbn
a.isbn, a.autorenname, b.titel
autor a, buch b WHERE a.isbn = b.isbn (+);
61
liefert das gewünschte Ergebnis
ISBN
0-201-38590-2
0-540-12345-1
0-666-98765-1
Autorenname
C. J. Date
Erich Kästner
Titel
Database Systems
Schlafes Bruder
Um den Outer-Join von mindestens drei Relationen zu bilden, gehe man wie
folgt vor:
Die obige Datenbankausprägung sei folgendermaßen erweitert:
Verlag
ISBN
0-201-38590-2
0-666-98765-1
0-540-12345-1
0-333-19283-7
Verlagsname
Addison Wesley
DTV
Ullstein Verlag
RoRoRo
Der Outer-Join aller drei Relationen Autor, Buch und Verlag über das Attribut
ISBN sollte dann folgendes Ergebnis liefern:
ISBN
0-201-38590-2
0-540-12345-1
0-666-98765-1
0-333-19283-7
Autorenname
C.J. Date
Erich Kästner
Titel
Database Systems
Schlafes Bruder
Verlagsname
Addison Wesley
Ullstein Verlag
DTV
RoRoRo
Wegen der Einschränkung des Outer-Joins auf zwei Relationen ist es nun nicht
möglich, dieses Ergebnis in einer Anfrage etwa der Form
SELECT ISBN, Autorenname, Titel, Verlagsname
FROM Autor a, Buch b, Verlag v
WHERE a.isbn (+) = b.isbn
AND a.isbn (+) v.isbn
zu erhalten. Allerdings ist es möglich, den im letzten Beispiel erhaltenen OuterJoin in einer Sicht zu speichern, und anschließend diese Sicht mit der der noch
verbliebenen letzten Relation Verlag nach der schon bekannten Art zu einem
Outer-Join zu verknüpfen:
CREATE VIEW ab AS
SELECT b.isbn, a.autorenname, b.titel
FROM Autor a, Buch b
WHERE a.isbn (+) = b.isbn
UNION
SELECT a.isbn, a.autorenname, b.titel
FROM autor a, buch b
WHERE a.isbn = b.isbn (+);
SELECT v.isbn, ab.autorenname, ab.titel, v.verlagsname
FROM ab, verlag v
WHERE ab.isbn (+) = v.isbn
UNION
SELECT ab.isbn, ab.autorenname, ab.titel, v.verlagsname
62
FROM ab, verlag v
WHERE ab.isbn = v.isbn (+);
Anmerkung: Es muß nicht explizit eine Sicht erzeugt werden, es kann auch, wie
im Abschnitt 5.1.2 beschrieben, mit der Definition der Sicht als Unteranfrage
gearbeitet werden. Der besseren Übersicht wegen wird aber in diesem Dokument
immer die Erzeugung der Sicht der Unteranfrage vorgezogen.
5.2.2
Verwendung von Outer-Joins im Universalrelation-System
Die einfachste Art der Verwendung von Outer-Joins im UniversalrelationSystem besteht darin, einen Outer-Join aller zum Datenbankschema gehörenden
Relationen zu bilden und diesen in einer Sicht VIEW OJ zu speichern. Eine Anfrage an das Universalrelation-System würde dann bearbeitet, indem die Anfrage
um die FROM -Klausel
FROM VIEW_OJ
erweitert würde.
Möchte man nur die Tupel im Ergebnis, die keine NULL-Werte enthalten, so
wird die Anfrage noch um folgende Bedingung ergänzt:
Für jedes Attribut A aus der Select-Attribut-Liste ergänze um:
•
AND A IS NOT NULL
Die Bildung des Outer-Joins über alle zum Datenbankschema gehörenden Relationen geschieht dabei, wie in den Abbildungen Algorithmus 4“ und Algo”
”
rithmus 5“ dargestellt.
Eingabe: Datenbankschema
1. Bilde den Hypergraph aller im Datenbankschema vorkommenden Relationen.
2. Bilde die Verbundbedingung für diesen Hypergraphen als Folge von ANDverknüpften Termen.
3. Zu den ersten Term der Verbundbedingung Ri .A1 = Rj .A1 bilde den
Outer-Join zwischen den Relationen Ri und Rj .
4. Tue folgendes, solange es geht:
• Jeder Term der Verbundbedingung, deren beide Relationen schon im
Outer-Join enthalten sind, wird als erledigt betrachtet.
• Für jeden Term der Verbundbedingung, der die Relationen Ri und
Rj verbindet, und bei dem genau eine Relation Ri im bisherigen
Outer-Join enthalten ist, bilde den Outer-Join zwischen dem bisherigen Outer-Join und der Relation Rj .
5. Für eine Verbundbedingung, deren beide Relationen nicht im Outer-Join
enthalten sind, bilde das kartesische Produkt zwischen dem bisherigen
Outer-Join und einer der beiden Relationen.
6. Beginne wieder bei Punkt 4.
Ausgabe: Der so entstandene Outer-Join.
Algorithmus 4: Outer-Join-Bildung über alle Relationen
63
• Den Outer-Join zwischen Relationi und Relationj bilden“ bedeutet fol”
gendes:
– Bilde folgende Anfrage:
SELECT <eindeutige Attribute-Liste>
FROM <Relation_i>, <Relation_j>
WHERE <Right-Outer-Join-Bedingung>
UNION
SELECT <eindeutige Attribute-Liste>
FROM <Relation_i>, <Relation_j>
WHERE <Left-Outer-Join-Bedingung>
– Die eindeutige Attribute-Liste erstellt sich folgendermaßen:
∗ Jedes Attribut, das nur in einer der beiden Relationen vorkommt,
wird übernommen
∗ Für jedes Attribut A, das in beiden Relationen Ri , Rj vorkommt,
wird folgendes übernommen:
· Beim Left Outer Join das Attribut aus der linken’Relation
”
· Beim Right Outer Join das Attribut aus der rechten“ Rela”
tion
Dies stellt sicher, daß dieses Attribut nicht NULL ist, falls es in
einem der beiden Relationen NULL ist.
– Die Right-Outer-Join-Bedingung wird folgendermaßen berechnet:
Für jedes Attribut Ak , das in beiden Relationen Ri , Rj vorhanden
ist, füge die Bedingung
O_i.A_k (+) = O_j.A_k
hinzu (Analog für die Left-Outer-Join-Bedingung).
• Punkt 5 im Verfahren von Algorithmus 4“ dient dazu, auch nichtzusam”
menhängende Hypergraphen bearbeiten zu können.
Algorithmus 5: Outer-Join-Bildung über alle Relationen - Anmerkungen
64
Satz: Für ein Datenbankschema aus n Relationen ergibt sich die Summe aller
verknüpften Relationen zur Bildung des Outer-Joins als
SOJ (1) := 1 für n = 1 bzw.
SOJ (n) := 2n +
n−2
X
2k für n > 1
k=1
Beweis: Durch Induktion über n.
Induktions-Anfang:
n = 1: Es gibt nur eine Relation, daher besteht der Outer-Join nur aus dieser
Relation. Daraus folgt
SOJ (1) = 1
n = 2: Es gibt zwei Relationen A und B. Diese werden einmal zum
Left-Outer-Join und einmal zum Right-Outer-Join verknüpft. Jede dieser Verknüpfungen besteht aus zwei Relationen, sodaß sich ergibt:
4 = 2 ∗ 2 = 22 +
2−2
X
2k = 4 +
k=1
0
X
2k = SOJ (2)
k=1
Induktions-Schluß:
n → n + 1: Der Outer-Join bei n + 1 Relationen A1 , . . . , An , B wird wie folgt
gebildet: Bilde den Left-Outer-Join aus dem bisherigen Outer-Join und der Relation B, vereinigt mit dem Right-Outer-Join aus der Relation B und dem
bisherigen Outer-Join. Dabei ist der bisherige Outer-Join der Outer-Join, der
bisher aus den Relationen A1 , . . . , An erzeugt wurde. Es ergibt sich also:
SOJ (n + 1) = 2 ∗ (SOJ (n) + 1)
= 2 ∗ (2n +
n−2
X
2k + 1)
k=1
= 2n+1 + 2 ∗
= 2n+1 +
n−2
X
2k + 2
k=1
n−2
X
k+1
2
+ 21
X
2k
k=1
(n+1)−2
=2
(n+1)
+
k=1
Durch die hohe Anzahl von Verknüpfungen ist die hier beschriebene Methode zwar prinzipiell geeignet, um Anfragen an das Universalrelation-Systemzu
bearbeiten, allerdings nicht sehr performant. Zum Beispiel bei der Anfrage
SELECT Autorenname, Titel
65
an das Bibliotheks-Datenbankschema werden viel zu viele Verknüpfungen vorgenommen, obwohl man in diesem Falle mit 4 Verknüpfungen ausgekommen
wäre.
Eine leichte Verbesserung der Performance wird erreicht, indem nicht mehr der
Outer-Join des gesamten Datenbank-Schemas, sondern nur noch des wirklich
benötigten Datenbank-Ausschnittes gebildet wird.
Die bedeutet folgende Modifikationen im oben aufgeführten Algorithmus:
• Bilde nur noch den Anfrage-Hypergraph, nicht den Hypergraph aller im
Datenbankschema vorkommenden Relationen, und dementsprechend auch
die Verbundbedingungen.
• Ein Attribut wird nur dann übernommen, wenn es die schon genannten
Eigenschaften erfüllt und zusätzlich in der Select-Attribut-Liste enthalten
oder ein Attribut zur Verbund-Bildung ist.
5.2.3
Die einzelnen Fälle des Universalrelation-Systems in Verbindung mit Outer-Joins
Wie in 2.2 erläutert, ist der genaue Arbeitsablauf des Universalrelation-Systems
in mehrere Schritte unterteilt:
• einfache“ Anfragen
”
• Datenbank-Variablen
• Geschachtelte Anfragen
• Mengenoperationen
Im Folgenden wird nun die Verwendung von Outer-Joins für jeden dieser Schritte
erläutert.
einfache“ Anfragen:
”
Zur Bearbeitung von einfachen“ Anfragen wird das schon bekannte Verfahren
”
verwendet, allerdings werden keine Sichten UNION * und VIEW 1 erzeugt,
sondern ein entsprechender Outer-Join, wie im letzten Abschnitt beschrieben.
Die Sicht UR WINDOW ergibt sich dann wie folgt:
CREATE VIEW UR_WINDOW AS
SELECT DISTINCT <Select-Attribut-Liste>
FROM ( <Outer-Join-Definition> )
WHERE <Selektions-Bedingungen>
Der Rest des Verfahrens bleibt unverändert.
Datenbank-Variablen:
Das Verfahren wird nur insofern abgeändert, daß nun für jede DatenbankVariable Ai ein Outer-Join erzeugt wird. Dadurch ändert sich die Erzeugung
der Sicht UR WINDOW zu:
CREATE VIEW UR_WINDOW AS
SELECT DISTINCT <Select-Attribut-Liste>
66
FROM ( <Outer-Join-Definition zu Variable A_1> ) A_1,
...
( <Outer-Join-Definition zu Variable A_k> ) A_k
WHERE <Selektions-Bedingungen>
ODER-Bedingungen:
Zur Bearbeitung von Anfragen mit ODER-Bedingungen bieten sich nun zwei
Wege an. Der Erste ist der, wie im bisherigen Verfahren, die Umformung der
ODER-Bedingungen in disjunktive Form und die Weiterverarbeitung über Vereinigungen von Teilanfragen. In diesem Fall wäre keine Anpassung nötig.
Der andere Weg besteht darin, die Bedingungen nicht in disjunkte Form aufzulösen, und die Anfrage so zu bearbeiten, als handele es sich um eine einfa”
che“ Anfrage (bzw. eine Anfrage mit Datenbank-Variablen). Da das SELECT Kommando an einen Outer-Join gestellt wird, treten die am Anfang von Abschnitt 2.2.6 erwähnten Probleme bei ODER-Bedingungen nicht mehr auf.
Geschachtelte Anfragen: Auch an diesem Verfahren ändert sich nur, daß für
jeden Anfragehypergraphen nun ein Outer-Join erzeugt wird.
Mengenoperationen: Auch hier wird nun ein Outer-Join für jeden Anfragehypergraphen erzeugt.
5.2.4
Beispiele und Zugriffspläne
Wie weiter oben schon erwähnt, wird durch die besondere Art der Verknüpfung der beteiligten Relationen zu einem Outer-Join eine Anfrage sehr schnell
sehr umfangreich. Anhand einiger ausgewählter Beispiele wird nun versucht, die
prinzipielle Struktur einer Anfrage mit Outer-Joins darzustellen.
Das folgende Beispiel zeigt, wie ein Zugriffsplan bei einem Outer-Join von zwei
Relationen aussieht:
Gegeben sei folgende Anfrage an das Universalrelation-System:
SELECT Autorenname, Titel;
Der Anfragehypergraph AHG und die daraus resultierende Verbundbedingung
sind:
AHG
::= {{ISBN, Autorenname}Autor }
{ISBN, Titel}Buch }
Verbundbedingung ::=
Autor.ISBN = Buch.ISBN
Daraus ergibt sich folgender Outer-Join in der Oracle-Syntax:
SELECT Autorenname, Titel
FROM (
SELECT Buch.Titel,
Autor.Autorenname
FROM Buch, Autor
WHERE Buch.ISBN (+) = Autor.ISBN
67
UNION
SELECT Buch.Titel,
Autor.Autorenname
FROM Buch, Autor
WHERE Buch.ISBN = Autor.ISBN (+) ) )
Die Anfrage an das DBMS erzeugt schließlich folgenden Verbundpfad:
Es läßt sich gut erkennen, wie durch das UNION im SQL-Befehl quasi eine
Verdoppelung der beteiligten Relationen auftritt.
Zum Vergleich sei hier der Verbundpfad gezeigt, wie er sich bei der Bearbeitung
der Anfrage nach der herkömmlichen Methode ergibt:
68
Das folgende Beispiel führt zu einem Outer-Join mit drei beteiligten Relationen:
Gegeben sei folgende Anfrage an das Universalrelation-System:
SELECT Titel, Verlagsname;
Der Anfragehypergraph AHG und die daraus resultierende Verbundbedingung
sind:
AHG
::= {{ISBN, Titel}Buch }
{ISBN, ISBN_Code}wird_verlegt
{ISBN_Code, Verlagsname}V erlag }
Verbundbedingungen ::=
Buch.ISBN = wird_verlegt.ISBN AND
wird_verlegt.ISBN_Code = Verlag.ISBN_Code
Daraus ergibt sich folgender Outer-Join in der Oracle-Syntax:
SELECT Titel, Verlagsname
FROM (
SELECT OJ.Titel, Verlag.Verlagsname
FROM (
SELECT Buch.Titel, wird_verlegt.isbn, wird_verlegt.isbn_code
69
FROM Buch, wird_verlegt
WHERE Buch.ISBN (+) = wird_verlegt.ISBN
UNION
SELECT Buch.Titel, Buch.isbn, wird_verlegt.isbn_code
FROM Buch, wird_verlegt
WHERE Buch.ISBN = wird_verlegt.ISBN (+)
) OJ, Verlag
WHERE OJ.isbn_code (+) = Verlag.isbn_code
UNION
SELECT OJ.Titel, Verlag.Verlagsname
FROM (
SELECT Buch.Titel, wird_verlegt.isbn, wird_verlegt.isbn_code
FROM Buch, wird_verlegt
WHERE Buch.ISBN (+) = wird_verlegt.ISBN
UNION
SELECT Buch.Titel, Buch.isbn, wird_verlegt.isbn_code
FROM Buch, wird_verlegt
WHERE Buch.ISBN = wird_verlegt.ISBN (+)
) OJ, Verlag
WHERE OJ.isbn_code = BIB.VERLAG.isbn_code (+)
)
Die Anfrage an das DBMS erzeugt schließlich folgenden Verbundpfad:
Man erkennt, daß an der zweiten Verzweigungs-Ebene von oben“ zwei Merge”
Joins sind. Diese verknüpfen jeweils die Relation Verlag mit einer verschachtelten Struktur:
70
Diese verschachtelte Struktur ist der Teil-Outer-Join, mit dem dann die Relation
Verlag wiederum zu einem Outer-Join verknüpft wurde.
Würde man die Anfrage nun um das Attribut Verlagsort erweitern, sodaß dann
noch die Relation Verl Orte beteiligt wäre, so würde diese Relation mit dem in
hier erzeugten Outer-Join zweimal verknüpft werden.
Auch hier sei zum Vergleich der aus der herkömmlichen Methode resultierende
Verbundpfad dargestellt:
71
5.2.5
Outer-Join und Oracle9T M
In der mittlerweile veröffentlichten Version 9i des DBMS Oracle ist es laut
[Ora01] nun möglich, direkt einen Full-Outer-Join über mehrere Relationen zu
erzeugen. Die Syntax, um einen solchen Join über m Relationen zu bilden lautet:
SELECT <Attribute>
FROM <Relation_1>
FULL OUTER JOIN <Relation_2> ON <Verbundbedingung_1>
[FULL OUTER JOIN <Relation_3> ON <Verbundbedingung_2>
[...]
[FULL OUTER JOIN <Relation_m> ON <Verbundbedingung_m-1>
[WHERE <Selektionsbedingung> ...]
Dies bedeutet insbesondere, daß die noch in Version 8i vorhandenen Einschränkungen an den Join-Operator (+) wegfallen. Dadurch wird das im vorherigen
Abschnitt beschriebene Verfahren stark vereinfacht und weniger umfangreich,
da insbesondere das sukzessive Verbinden von Teil-Outer-Joins mit einzelnen
Relationen nun wegfällt.
Der Algorithmus zur Outer-Join-Bildung verläuft dadurch unkomplizierter - die
geänderte Fassung ist in den Abbildungen Algorithmus 6“ und Algorithmus
”
”
7“ aufgeführt.
Eingabe: Datenbankschema
1. Bilde den Hypergraph aller im Datenbankschema vorkommenden Relationen.
2. Bilde die Verbundbedingung für diesen Hypergraphen als Folge von ANDverknüpften Termen..
3. Zu dem ersten Term der Verbundbedingung Ri .A1 = Rj .A1 bilde den
Outer-Join zwischen den Relationen Ri und Rj .
4. Tue folgendes, solange es geht:
• Jeder Term der Verbundbedingung, deren beide Relationen schon im
Outer-Join enthalten sind, wird als erledigt betrachtet.
• Für jeden Term der Verbundbedingung, bei der genau eine Relation
Ri im Outer-Join enthalten ist, füge die anderen Relation Rj dem
bisherigen Outer-Join hinzu.
5. Für eine Verbundbedingung, deren beide Relationen nicht im Outer-Join
enthalten sind, bilde das kartesische Produkt zwischen dem bisherigen
Outer-Join und einer der beiden Relationen.
6. Beginne wieder bei Punkt 4.
Ausgabe: Der so entstandene Outer-Join.
Algorithmus 6: Outer-Join-Bildung über alle Relationen in Oracle9i
72
• Den Outer-Join zwischen Relation i und Relation j bilden“ bedeutet fol”
gendes:
– Bilde folgende Anfrage:
SELECT <eindeutige Attribute-Liste>
FROM <Relation_i>
FULL OUTER JOIN <Relation_j>
ON <Outer-Join-Bedingung>
– Die eindeutige Attribute-Liste wird folgendermaßen erstellt:
∗ Jedes Attribut, das nur in einer der beiden Relationen vorkommt,
wird übernommen
∗ Bei Attributen, die in beiden Relationen Ri , Rj vorkommen, wird
das Attribut nur aus einer der beiden Relationen übernommen.
– Die Outer-Join-Bedingung wird folgendermaßen berechnet: Für jedes
Attribut Ak , das in beiden Relationen Ri , Rj vorhanden ist, füge die
Bedingung
[AND] O_i.A_k = O_j.A_k
hinzu.
• Die Relation Rj dem Outer-Join hinzufügen“ bedeutet:
”
– Die bisherige Anfrage wird erweitert um:
FULL OUTER JOIN <Relation_j>
ON <Outer-Join-Bedingung>
– die eindeutige Attribut-Liste in der bisherigen Anfrage wird erweitert
um die Attribute aus der Relation Rj , sofern diese nicht schon in der
Liste vorkommen.
• Punkt 5 im Verfahren Älgorithmus 6”dient dazu, auch nichtzusammenhängende Hypergraphen bearbeiten zu können.
Algorithmus 7: Outer-Join-Bildung über alle Relationen in Oracle9i - Anmerkungen
73
5.2.6
Zeitmessungen
Anhand ausgewählter Beispiele wurde der Zeitaufwand des UniversalrelationSystems zur Bearbeitung von Anfragen mit den verschiedenen Verfahren (herkömmlich, Outer-Join in Oracle8 , Outer-Join in Oracle9 ) ermittelt. Dazu wurde
die Sicht UR WINDOW mit jedem dieser Verfahren erzeugt, und die Anfrage
gestellt.
Alle Anfragen wurden an dasselbe DBMS gestellt.
Die Ermittlung des Zeit- und Speicherbedarfs erfolgte mit dem SQL*PlusKommandos
SET TIMING ON
SET AUTOTRACE ON
Insbesondere die Parameter db block gets und consistent gets (Anzahl der Blockzugriffe, die aus dem Hauptspeicher bedient werden konnten ) und der Parameter
physical reads (Anzahl der lesenden Zugriffe auf die Datenbank) wurden dabei
betrachtet.
Jede SQL-Anfrage an die Sicht UR WINDOW wurde mehrmals gestellt, und die
Bedarfswerte ergaben sich aus dem arithmetischen Mittel der einzelnen Werte.
Sei folgende Anfrage an das Universalrelation-System gegeben:
SELECT MovieTitle, DirectorName, PlayerName
WHERE Pos is not null;
Gesucht sind also alle Filme mit Regisseur und Darstellern.
Für die Messung für das Verfahren mit Outer-Join in Oracle8 wurde der OuterJoin wie folgt erzeugt:
CREATE VIEW OJ1 AS (
SELECT OJ.DIRECTORNAME,
OJ.MOVIEID,
OJ.DIRECTORID,
OJ.MOVIETITLE,
OJ.POS,
PLAYER.PLAYERNAME,
PLAYER.PLAYERID
FROM ( SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
OJ.MOVIETITLE,
PLAYS.PLAYERID,
PLAYS.POS,
PLAYS.MOVIEID
FROM ( SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
MOVIE.MOVIETITLE,
MOVIE.MOVIEID
FROM ( SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
74
DIRECTS.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID (+) = DIRECTS.DIRECTORID
UNION
SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTOR.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID = DIRECTS.DIRECTORID (+)
) OJ, MOVIE
WHERE OJ.MOVIEID (+) = MOVIE.MOVIEID
UNION
SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
MOVIE.MOVIETITLE,
OJ.MOVIEID
FROM ( SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTS.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID (+) = DIRECTS.DIRECTORID
UNION
SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTOR.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID = DIRECTS.DIRECTORID (+)
) OJ, MOVIE
WHERE OJ.MOVIEID = MOVIE.MOVIEID (+)
) OJ, PLAYS
WHERE OJ.MOVIEID (+) = PLAYS.MOVIEID
UNION
SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
OJ.MOVIETITLE,
PLAYS.PLAYERID,
PLAYS.POS,
OJ.MOVIEID
FROM ( SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
MOVIE.MOVIETITLE,
MOVIE.MOVIEID
FROM ( SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTS.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID (+) = DIRECTS.DIRECTORID
UNION
SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
75
DIRECTOR.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID = DIRECTS.DIRECTORID (+)
) OJ, MOVIE
WHERE OJ.MOVIEID (+) = MOVIE.MOVIEID
UNION
SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
MOVIE.MOVIETITLE,
OJ.MOVIEID
FROM ( SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTS.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID (+) = DIRECTS.DIRECTORID
UNION
SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTOR.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID = DIRECTS.DIRECTORID (+)
) OJ, MOVIE
WHERE OJ.MOVIEID = MOVIE.MOVIEID (+)
) OJ, PLAYS
WHERE OJ.MOVIEID = PLAYS.MOVIEID (+)
) OJ, PLAYER
WHERE OJ.PLAYERID (+) = PLAYER.PLAYERID
UNION
SELECT OJ.DIRECTORNAME,
OJ.MOVIEID,
OJ.DIRECTORID,
OJ.MOVIETITLE,
OJ.POS,
PLAYER.PLAYERNAME,
OJ.PLAYERID
FROM ( SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
OJ.MOVIETITLE,
PLAYS.PLAYERID,
PLAYS.POS,
PLAYS.MOVIEID
FROM ( SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
MOVIE.MOVIETITLE,
MOVIE.MOVIEID
FROM ( SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTS.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID (+) = DIRECTS.DIRECTORID
76
UNION
SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTOR.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID = DIRECTS.DIRECTORID (+)
) OJ, MOVIE
WHERE OJ.MOVIEID (+) = MOVIE.MOVIEID
UNION
SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
MOVIE.MOVIETITLE,
OJ.MOVIEID
FROM ( SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTS.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID (+) = DIRECTS.DIRECTORID
UNION
SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTOR.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID = DIRECTS.DIRECTORID (+)
) OJ, MOVIE
WHERE OJ.MOVIEID = MOVIE.MOVIEID (+)
) OJ, PLAYS
WHERE OJ.MOVIEID (+) = PLAYS.MOVIEID
UNION
SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
OJ.MOVIETITLE,
PLAYS.PLAYERID,
PLAYS.POS,
OJ.MOVIEID
FROM ( SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
MOVIE.MOVIETITLE,
MOVIE.MOVIEID
FROM ( SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTS.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID (+) = DIRECTS.DIRECTORID
UNION
SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTOR.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID = DIRECTS.DIRECTORID (+)
77
) OJ, MOVIE
WHERE OJ.MOVIEID (+) = MOVIE.MOVIEID
UNION
SELECT OJ.DIRECTORNAME,
OJ.DIRECTORID,
MOVIE.MOVIETITLE,
OJ.MOVIEID
FROM ( SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTS.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID (+) = DIRECTS.DIRECTORID
UNION
SELECT DIRECTOR.DIRECTORNAME,
DIRECTS.MOVIEID,
DIRECTOR.DIRECTORID
FROM DIRECTOR, DIRECTS
WHERE DIRECTOR.DIRECTORID = DIRECTS.DIRECTORID (+)
) OJ, MOVIE
WHERE OJ.MOVIEID = MOVIE.MOVIEID (+)
) OJ, PLAYS
WHERE OJ.MOVIEID = PLAYS.MOVIEID (+)
) OJ, PLAYER
WHERE OJ.PLAYERID = PLAYER.PLAYERID (+)
);
CREATE VIEW UR_WINDOW AS
SELECT MovieTitle, DirectorName, PlayerName
FROM OJ1
WHERE Pos IS NOT NULL;
Für die Messung für das Verfahren mit Outer-Join in Oracle9 wurde der OuterJoin wie folgt erzeugt:
CREATE VIEW OJ2 AS (
SELECT M.MovieID,
M.MovieTitle,
P.PlayerID,
P.PlayerName,
D.DirectorID,
D.DirectorName,
plays.Pos
FROM Movie M FULL OUTER JOIN directs
ON M.MovieID = directs.MovieID
FULL OUTER JOIN Director D
ON directs.DirectorID = D.DirectorID
FULL OUTER JOIN plays
ON M.MovieID = plays.MovieID
FULL OUTER JOIN Player P
ON P.PlayerID = plays.PlayerID
);
78
CREATE VIEW UR_WINDOW AS
SELECT MovieTitle, DirectorName, PlayerName
FROM OJ2
WHERE Pos IS NOT NULL;
Die Anfrage beim herkömmlichen Verfahren lautete
SELECT MovieTitle, DirectorName, PlayerName
FROM UR_WINDOW;
während bei den Outer-Join-Verfahren folgende Anfrage benutzt wurde:
SELECT MovieTitle, DirectorName, PlayerName
FROM UR_WINDOW
WHERE MovieTitle IS NOT NULL
AND DirectorName IS NOT NULL
AND PlayerName IS NOT NULL;
Mit der herkömmlichen Methode wurden folgende Werte gemessen:
Durchlauf
1
2
3
4
5
Durchschnitt:
Zeit / sec
154.56
73.84
65.89
81.07
77.60
90.59
db block gets
26
26
26
26
26
26
constistent gets
1243198
1243184
1243184
1243184
1243184
1243187
physical reads
1911
1907
1911
1907
1911
1909
Die Messungen beim Verfahren mit Outer-Join in Oracle8 ergaben:
Durchlauf
1
2
3
4
5
Durchschnitt:
Zeit / sec
233.41
138.81
193.77
138.25
164.46
173.74
db block gets
504
504
502
503
504
503
constistent gets
1407943
1407939
1407939
1407939
1407939
1407940
physical reads
24923
24920
24890
24906
24902
24908
Die Messungen beim Verfahren mit Outer-Join in Oracle9 ergaben:
Durchlauf
1
2
3
4
5
Durchschnitt:
Zeit / sec
164.46
65.70
123.71
68.23
66.46
97.71
db block gets
10
10
10
10
10
10
constistent gets
559956
559956
559956
559956
559956
559956
physical reads
0
0
0
0
0
0
Durch die vielen Verschachtelungen beim Erzeugen des Outer-Joins benötigt
das Verfahren mit Outer-Join in Oracle8 etwa doppelt so viel Zeit wie das
herkömmliche Verfahren, während das Verfahren mit echtem Outer-Join in etwa
gleich viel Zeit beansprucht.
Erwartungsgemäß benötigt das Verfahren mit Outer-Join in Oracle8 viel mehr
Leseoperationen und damit mehr Zugriffe auf die Datenbank als die beiden
79
anderen Verfahren.
Das Verfahren mit Outer-Join in Oracle9 konnte alle Leseoperationen komplett
aus dem Hauptspeicher bedienen, war allerdings etwas langsamer in der Zeit als
das herkömmliche Verfahren.
Sei nun folgende Anfrage an das Universalrelation-System gegeben:
SELECT MovieTitle, DirectorName, PlayerName
WHERE Pos pos = 1 OR Directorname = Playername;
Gesucht sind also alle Filme mit Regisseur und Darsteller, wobei der Darsteller
entweder der Hauptdarsteller oder gleichzeitig der Regisseur ist.
Die Sichten OJ1 bzw. OJ2 wurden wie im letzten Beispiel erzeugt. Bei der Erzeugung der Sicht UR WINDOW wurden bei den Outer-Join-Verfahren je einmal die Sicht mit ODER-Bedingungen und je einmal mit UNION -Verknüpfung
erzeugt:
CREATE VIEW UR_WINDOW AS (
SELECT "MOVIETITLE" , ‘‘DIRECTORNAME" , "PLAYERNAME"
FROM OJ1
WHERE POS = 1
OR Directorname = Playername
);
bzw.
CREATE VIEW UR_WINDOW AS (
SELECT "MOVIETITLE" , ‘‘DIRECTORNAME" , "PLAYERNAME"
FROM OJ1
WHERE POS = 1
UNION
SELECT "MOVIETITLE" , ‘‘DIRECTORNAME" , "PLAYERNAME"
FROM OJ1
WHERE Directorname = Playername
);
Mit der herkömmlichen Methode wurden folgende Werte gemessen:
Durchlauf
1
2
3
4
5
Durchschnitt:
Zeit / sec
9.70
16.65
8.72
8.71
8.70
10.50
db block gets
13
13
13
13
13
13
constistent gets
827069
827043
827043
827043
827043
827048
physical reads
186
186
186
186
186
186
Die Messungen beim Verfahren mit Outer-Join in Oracle8 und UNION Verknüpfung ergaben:
80
Durchlauf
1
2
3
4
5
Durchschnitt:
Zeit / sec
180.91
182.33
182.20
182.43
181.94
181.96
db block gets
922
922
922
922
922
922
constistent gets
2701508
2701502
2701502
2701502
2701502
2701503
physical reads
39840
39862
39882
39848
39854
39857
Die Messungen beim Verfahren mit Outer-Join in Oracle8 und ODERBedingungen ergaben:
Durchlauf
1
2
3
4
5
Durchschnitt:
Zeit / sec
202.86
202.85
200.33
287.33
218.79
222.43
db block gets
481
481
481
481
481
481
constistent gets
1539973
1539969
1539969
1539969
1539969
1539970
physical reads
22333
22331
22353
22348
22348
22342
Die Messungen beim Verfahren mit Outer-Join in Oracle9 und UNION Verknüpfung ergaben:
Durchlauf
1
2
3
4
5
Durchschnitt:
Zeit / sec
12.12
16.82
12.00
16.63
12.03
13.92
db block gets
25
25
25
25
25
25
constistent gets
893577
893571
893571
893571
893571
893572
physical reads
185
185
185
185
185
185
Die Messungen beim Verfahren mit Outer-Join in Oracle9 und ODERBedingungen ergaben:
Durchlauf
1
2
3
4
5
Durchschnitt:
Zeit / sec
10.42
10.42
10.43
10.40
10.45
10.42
db block gets
10
10
10
10
10
10
constistent gets
730090
730086
730086
730086
730086
730087
physical reads
0
0
0
0
0
0
Erwartungsgemäß benötigen die Outer-Join-Verfahren in Oracle8 ein Vielfaches
mehr an Zeit und Leseoperationen als die anderen Verfahren. Als erstes Fazit
steht somit fest, daß das Verfahren mit Outer-Join in Oracle8 keinen Optimierungsgewinn bringt.
Das herkömmliche Verfahren und die Verfahren mit Outer-Join in Oracle9 benötigen etwa gleich viel Zeit und Leseoperationen, wobei das Verfahren mit
Outer-Join und ODER-Bedingungen leicht gewinnt, was Zeitbedarf und Anzahl
der Leseoperationen betrifft.
Sei nun folgende Anfrage an das Universalrelation-System gegeben:
SELECT a.MOVIEtitle, a.Directorname, a.Playername,
b.MovieTitle, B.Directorname
81
WHERE b.MovieID = a.SuccessorID;
Gesucht sind also alle Filme mit ihrer Fortsetzung.
Die Messungen wurden jetzt nur noch für das herkömmliche Verfahren und
das Verfahren mit Outer-Join in Oracle9 durchgeführt, da das Verfahren mit
Outer-Join in Oracle8 sich schon als nicht empfehlenswert erwiesen hat.
Die Sichten für das Outer-Join-Verfahren wurden wie folgt erzeugt:
CREATE VIEW oj_a_1 AS
SELECT m.MOVIETITLE, d.Directorname, p.Playername, f.SuccessorID
FROM movie m
FULL OUTER JOIN directs
ON m.MovieID = directs.MovieID
FULL OUTER JOIN director d ON directs.directorID = d.directorID
FULL OUTER JOIN follows f ON f.movieID = m.movieID
FULL OUTER JOIN plays
ON plays.movieID = m.movieID
FULL OUTER JOIN player p
ON plays.playerID = p.playerID;
CREATE VIEW oj_b_1 AS
SELECT m.MOVIEID, m.MOVIETITLE, d.directorname
FROM movie m
FULL OUTER JOIN directs
ON m.movieID = directs.movieID
FULL OUTER JOIN director d ON directs.directorID = d.directorID;
CREATE VIEW UR_WINDOW AS
SELECT DISTINCT A.MOVIETITLE "A.MOVIETITLE" ,
A.DIRECTORNAME "A.DIRECTORNAME",
A.PLAYERNAME "A.PLAYERNAME",
B.MOVIETITLE "B.MOVIETITLE",
B.DIRECTORNAME "B.DIRECTORNAME"
FROM oj_a_1 A, oj_b_1 B
WHERE A.SUCCESSORID = B.MOVIEID;
und die Anfrage lautete
SELECT "A.MOVIETITLE",
"A.DIRECTORNAME",
"B.MOVIETITLE",
"B.DIRECTORNAME"
FROM URW2
WHERE "A.MOVIETITLE" IS NOT NULL
AND "A.DIRECTORNAME" IS NOT NULL
AND "A.PLAYERNAME" IS NOT NULL
AND "B.MOVIETITLE" IS NOT NULL
AND "B.DIRECTORNAME" IS NOT NULL;
Mit der herkömmlichen Methode wurden folgende Werte gemessen:
82
Durchlauf
1
2
3
4
5
Durchschnitt:
Zeit / sec
32.96
34.01
33.62
33.63
33.21
33.48
db block gets
2
2
2
2
2
2
constistent gets
19526
19504
19504
19504
19504
19508
physical reads
0
0
0
0
0
0
Die Messungen beim Verfahren mit Outer-Join in Oracle9 ergaben:
Durchlauf
1
2
3
4
5
Durchschnitt:
Zeit / sec
30.96
30.37
29.90
30.49
30.39
30.42
db block gets
22
22
22
22
22
22
constistent gets
821865
821859
821859
821859
821859
821860
physical reads
38
38
38
38
38
38
Der Zeitbedarf ist für beide Verfahren in etwa gleich, mit leichtem Vorsprung
für das Outer-Join-Verfahren. Allerdings sind beim Outer-Join-Verfahren die
Leseoperationen um ein Vielfaches höher als beim herkömmlichen Verfahren.
5.2.7
Fazit
Von den untersuchten Verfahren bietet sich nur das Outer-Join-Verfahren in
Oracle9 als Alternative zum herkömmlichen Verfahren an. Insbesondere bei der
Behandlung von ODER-Bedingungen kommen die Vorteile des Outer-Joins zum
Tragen. Allerdings sind die Ergebnisse für das Outer-Join-Verfahren nicht immer optimaler als bei der herkömmlichen Methode, denn insbesondere bei der
Verwendung von Datenbankvariablen lag der Leseaufwand um ein Vielfaches höher als beim herkömmlichen Verfahren, was sich allerdings nicht im Zeitbedarf
bemerkbar gemacht hat.
83
6
Das neue“ Universalrelation-System
”
In diesem Abschnitt werden die Neuerungen zusammengefaßt, die sich aus den
in den vorigen Abschnitten durchgeführten Untersuchungen ergeben
Die Untersuchungen aus Abschnitt 5 ergab folgende positive Ergebnisse:
• Die Verwendung von Unteranfragen anstatt Sichten für Zwischenanfragen
kann den Zeitaufwand verringern, außerdem wird die Fehleranfälligkeit
gesenkt, da nur noch ein CREATE -Befehl gesendet werden muß.
• Die Verwendung von Outer-Joins zumindest in Oracle-DMBS ab Version
9i ergibt keine tiefgreifenden Optimierungen im Zeitaufwand, allerdings
wird das Konzept vereinfacht, da für ODER-Bedingungen keine Sonderbehandlung mehr erforderlich ist. Daraus ergibt sich der weitere Vorteil,
daß das Verbot von Aggregatfunktionen wieder aufgehoben werden kann.
Wir verwenden daher in der neuen Fassung des Universalrelation-Systems keine
Zwischensichten“ mehr, und das Fenster“ auf die Universalrelation wird mit
”
”
dem Outer-Join konstruiert.
Die Bestimmung des Fensters“ verläuft analog zu der Bildung des Outer-Joins
”
im in Algorithmus 6“ beschriebenen Verfahrens und wird in Algorithmus 8“ in
”
”
der Übersicht dargestellt.
Der Einfachheit halber wird das Verfahren auf zusammenhängende Datenbankschemas eingeschränkt.
Eingabe: Anfragehypergraph, Attributmenge X
Ausgabe: Das zu X gehörende Fenster [X].
Verfahren:
• Für jede Kante Rk (k = 0, . . . , m) des Anfragehypergraphens mit der
Attributmenge Ak
– Bestimme die Projektion aller Relationen der Datenbank, deren Schema eine Obermenge dieser Attributmenge ist.
– Bilde die Vereinigung aller dieser Projektionen.
• Fasse alle diese Vereinigungen über den Outer-Join zusammen. Die OuterJoin-Bedingung wird dabei über alle gleichen Attribute gebildet.
• Bilde [X] als die Projektion dieses Verbundes auf die Attributmenge X
mit der zusätzlichen Bedingung, daß jedes Attribut A ∈ X nicht NULL
ist.
Algorithmus 8: Erzeugung des Fensters [X] mittels Outer-Join
Beispiel
Betrachten wir noch einmal die in Abschnitt 2.2.6 vorgestellte Anfrage nach allen
nach 1994 oder im Addison-Wesley-Verlag erschienenen Büchern im BibliotheksDatenbankschema:
SELECT Titel
WHERE Erscheinungsjahr > 1994
OR Verlagsname = ’Addison-Wesley’;
Die Attributmenge X und der Anfragehypergraph zu dieser Anfrage sind:
84
X
=
AHG(X)=
{T itel, Erscheinungsjahr, V erlagsname}
{(ISBN, T itel, Erscheinungsjahr)Buch,
(ISBN, ISBN CODE)wird verlegt ,
(ISBN CODE, V erlagsname)V erlag }
Die Definitionen der Kanten“ des Anfragehypergraphen ergeben sich wie folgt:
”
Kante_0 ≡
SELECT ISBN, Titel, Erscheinungsjahr
FROM Buch
Kante_1 ≡
SELECT ISBN, ISBN_CODE
FROM wird_verlegt
Kante_2 ≡
SELECT ISBN_CODE, Verlagsname
FROM Verlag
Das Fenster“ wird berechnet:
”
[X] ≡
SELECT Titel, Erscheinungsjahr, Verlagsname
FROM (
SELECT ISBN, Titel, Erscheinungsjahr FROM Buch
) Kante_0
FULL OUTER JOIN (
SELECT ISBN, ISBN_CODE FROM wird_verlegt
) Kante_1
ON Kante_0.ISBN = Kante_1.ISBN
FULL OUTER JOIN (
SELECT ISBN_CODE, Verlagsname FROM Verlag
) Kante_2
ON Kante_1.ISBN_CODE = Kante_2.ISBN_CODE
Die Sicht auf die Ergebnistupel wird erzeugt und die Anfrage gestellt:
UR_WINDOW ≡
SELECT Titel
FROM (
<Fenster [X]>
) AHG
WHERE Erscheinungsjahr > 1994
OR Verlagsname = ’Addison-Wesley’
SELECT Titel
FROM ( <UR_WINDOW> )
WHERE Titel IS NOT NULL;
Anmerkung: < F enster[X] > und < U R W IN DOW > wurden hier der Übersichtlichkeit halber nicht durch ihre Definition ersetzt. Die fertige“ Anfrage sähe
”
folgendermaßen aus:
SELECT Titel
85
FROM ( SELECT Titel
FROM (
SELECT Titel, Erscheinungsjahr, Verlagsname
FROM (
SELECT ISBN, Titel, Erscheinungsjahr FROM Buch
) Kante_0
FULL OUTER JOIN (
SELECT ISBN, ISBN_CODE FROM wird_verlegt
) Kante_1
ON Kante_0.ISBN = Kante_1.ISBN
FULL OUTER JOIN (
SELECT ISBN_CODE, Verlagsname FROM Verlag
) Kante_2
ON Kante_1.ISBN_CODE = Kante_2.ISBN_CODE
) AHG
WHERE Erscheinungsjahr > 1994
OR Verlagsname = ’Addison-Wesley’
) UR_WINDOW
WHERE Titel IS NOT NULL;
86
7
Ausblick
Wir haben in der vorliegenden Arbeit die Versuche zur Optimierung eines Universalrelation-Systems und die Umsetzung der Ergebnisse beschrieben. Die dabei gewonnenen Erkenntnisse sind nicht spektakulär. Allenfalls die Erkenntnis,
daß ein Outer-Join die Sonderbehandlung von ODER-Bedingungen überflüssig
macht, ragt ein wenig heraus.
Es bleibt am Ende die Frage, was noch zusätzlich zu tun bleibt. Optimierungsuntersuchungen ohne konkrete Anfragen oder gar Datenbankschemas sind eine
vage Angelegenheit. Mit dem Fortschreiten der Fähigkeiten des Optimierers im
DBMS Oracle wird diese Frage immer mehr eine akademische.
Das bereits in [Bor01] vorgestellte Universalrelation-System wurde durch
die Umsetzung der Erkennung der Datenbankschema-Struktur über JDBC Metadaten flexibler in der Anwendung. Der aus Optimierungsgründen vorgenommene Verzicht auf Erzeugung von Sichten hat auch den positiven Nebeneffekt, daß das in [Bor01] erwähnte Problem der Sichten-Benennung sich gelöst
hat.
Die vom Universalrelation-System akzeptierte Anfragesprache ist so nah wie
möglich am Vorbild“ SQL geblieben. Interessant wäre in diesem Zusammen”
hang eine mögliche Erweiterung der Anfragesprache auf objektrelationale Erweiterungen, wie Oracle sie seit der Version 8 anbietet.
87
Literatur
[AP87]
Nabiha Azar and Etienne Pichat. Translation of an extended entityrelationship model into the universal relation with inclusions formalism. Entity-Relationship Approach, 1987.
[BB83]
Joachim Biskup and Hans Hermann Brueggemann. Universal relation views: A pragmatic approach. In 9th International Conference
on Very Large Data Bases,October 31 - November 2, Florence,Italy,
1983.
[BB87]
Joachim Biskup and Hans Hermann Brüggemann. Data manipulation languages for the universal relation view durst. MFDBS, 1987.
[BBSK86] J. Biskup, H. H. Brüggemann, L. Schnetgöke, and M. Kramer. One
flavor assumption and γ-acyclicity for universal relation views. ACM
PODS, 1986.
[Bor01]
Martin Boroske. Universalrelation-Sichten in Java. Studienarbeit,
Universität Hannover, Institut für Informatik, January 2001. Der
Vorgänger dieser Arbeit.
[Brü86]
Hans Hermann Brüggemann.
Semantik von UniversalrelationSichten und ihre Datenbankschemas. Forschungsbericht nr. 214, Universität Dortmund, Abteilung Informatik, 1986.
[BT93]
Hans H. Brüggemann and Bernd Teßmer. Ein UniversalrelationFrontend für SQL. In Hildesheimer Informatik-Berichte. Universität
Hildesheim, Institut für Informatik, July 1993. Der Vorgänger von
[Bor01].
[CK76]
C. Robert Carlson and Robert S. Kaplan. A generalized access path
model and its application to a relational data base system. In ACM
SIGMOD International Conference on Management of Data, Washington, D.C., 1976.
[Cod88]
E. F. Codd. ’universal’ relation fails to replace relational model.
IEEE Software, 1988. Brief an den Herausgeber von [Var88], mit
einer beigefügten Antwort von Vardi.
[Dat00]
C. J. Date. An Introduction to Database Systems. Addison-Wesley,
seventh edition, 2000.
[HL91]
Heikki Hyötyniemi and Aarno Lehtola. A universal relation database
interface for knowledge based systems. In International Symposium
on Database Systems for Advanced Applications, Tokyo, Japan, April
1991.
[Ken81]
W. Kent. Consequences of assuming a universal relation. ACM
Transactions on Database Systems, 6(4):539 – 556, 1981.
[KLSZ01] Ramayya Krishnan, Xiaoping Li, David Steier, and Leon Zhao. On
heterogeneous database retrieval: A cognitively guided approach. Information Systems Research, 12(3):286 – 301, September 2001.
88
[Lau82]
R. Laue. A universal relation with null-values. Technical report,
RWTH Aachen, 1982.
[Lev92]
M. Levene. The nested universal relatione database model. In Lecture
Notes in Computer Science, volume 595. Springer Verlag, 1992.
[LL88]
M. Levene and G. Loizou. A universal relation model for nested
relations. EBDT, 1988.
[LL89]
M. Levene and G. Loizou. Nurql: A nested universal relation query
language. Information Systems, 14:307 – 316, 1989.
[LL94]
Mark Levene and George Loizou. The nested universal relation data
model. Journal of Computer and System Sciences, 49:683 – 717,
1994.
[LLS97]
D. Laurent, V. Phan Luong, and N. Spyratos. The use of deleted tuples in database querying and updating. Acta Informatica, 34(12):905
– 925, 1997.
[LW00]
S.Nilakanta L. Wu, L. Miller. Design of data warehouses using metadata. Information and Software Technology, 2000.
[MKS82] Sharon McCure Kuck and Yehoshua Sagiv. A universal relation database system implemented via the network model. In Proceedings
1st ACM SIGACT SIGMOD Symposium on Principles of Database
Systems, Los Angeles, California, March 1982.
[MM98]
Francesco Mario Malvestuto and Marina Moscarini. A fast algorithm
for query optimization in universal-relation databases. Journal of
Computer and System Sciences, 56:299 – 309, 1998.
[MU81]
David Maier and Jeffrey D. Ullman. Maximal objects and the semantics of universal relation databases. Interim report, Department of
Computer Science, Stanford University, Stanford, CA, October 1981.
[MU82]
David Maier and Jeffrey D. Ullman. Connections in acyclic hypergraphs - extended abstract. In Proceedings 1st ACM SIGACT SIGMOD
Symposium on Principles of Database Systems, Los Angeles, California, March 1982.
[MUV82] David Maier, Jeffrey D. Ullman, and Moshe Y. Vardi. The equivalence of universal relation definitions. Technical report, Department
of Computer Science, Stanford University, Stanford, CA, October
1982.
[Ora97]
Oracle Corporation, Redwood Shores, California. Oracle8 T M SQL
Reference Release 8.0, December 1997.
[Ora01]
Oracle Corporation. Oracle9i SQL Reference Release 1 (9.0.1), June
2001.
[Rec97]
Christine Reck. Poster on transparent access to a network of information sources and service providers via a universal relation interface.
CoopIS, 1997.
89
[RH96]
Christine Reck and Gerd Hillebrand. Implementing a universal relation interface using access scripts with binding patterns. Technical
report, Universität Karlsruhe, 1996.
[SW95]
R. D. Semmel and R. P. Winkler. Integrating reengineered databases
to support data fusion. J. Systems Software, 1995.
[TA99]
Riccardo Torlone and Paolo Atzeni. Efficient database updates with
independent schemes. Siam Journal on Computing, 28(3):1112 –
1135, September 1999.
[Ull82a]
Jeffrey D. Ullman. Design of a universal relation database system.
Annual report sept. 1981 - aug. 1982, Department of Computer
Science, Stanford University, Stanford, CA, August 1982.
[Ull82b]
Jeffrey D. Ullman. Query processing in universal relation systems.
Database Engineering, 5(3), September 1982.
[Ull82c]
Jeffrey D. Ullman. The U. R. strikes back. In Proceedings 1st ACM
SIGACT SIGMOD Symposium on Principles of Database Systems,
Los Angeles, California, March 1982.
[Ull83]
Jeffrey D. Ullman. Universal relation database systems. Annual
report sept. 1982 - aug. 1983, Department of Computer Science, Stanford University, Stanford, CA, August 1983.
[Var88]
Moshe Y. Vardi. The universal-relation data model for logical independence. IEEE Software, 1988.
[ZSC95]
J. Leon Zhao, Arie Segev, and Abhirup Chatterjee. A universal relation approach to federated database management. In Proceedings of
the Eleventh International Conference on Data Engineering, March
6-10, Taipei, Taiwan, 1995.
90
Danksagung
Den Angehörigen des Instituts für Informatik, Fachgebiet Datenbanken und
Informationssysteme (insbesondere meinem Betreuer Dr. Hans Hermann Brüggemann) danke ich für die fachliche und technische Betreuung meiner Arbeit.
Ganz besonders meiner Lebensgefährtin Annette Jürgens möchte ich an dieser
Stelle meinen tief empfundenen Dank für ihre moralische Unterstützung und
Anteilnahme aussprechen.
Dank geht auch an meine Eltern für ihre (nicht selbstverständliche) finanzielle
Unterstützung, sowie meinem Bruder Thomas für Korrekturlesen und hilfreiche
Diskussionen.
91
Erklärung
Hiermit versichere ich, daß ich die vorliegende Arbeit und die zugehörige Implementierung selbstständig verfaßt und dabei nur die angegebenen Quellen und
Hilfsmittel verwendet habe.
Hannover, den 5. Oktober 2001
(Martin Boroske)
92

Zugehörige Unterlagen

Aufgaben vom 21.9.06

Aufgabe 1 - FH Dortmund

Untersuchungen zur Optimierung von Universalrelation

Zugehörige Unterlagen

Dieses Dokument Sammlung (en)

Dieses Dokument gespeichert

Schlagen Sie uns vor, wie wir StudyLib verbessern können