Anwendung und Optimierung der Magic Sets Methode

Ausarbeitung
Anwendung und Optimierung der
Magic Sets Methode
Projektgruppe „Intelligente Datenbanken“
Autor:Taner Tas
Siegburg, 16.08.2003
Vorwort
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 1 von 24
Die Magic Sets Methode wurde bei ihrer Einführung 1986 auf der Grundlage von
theoretischen Systemen wie z.B. DATALOG entwickelt.
DBMS, die in der Praxis Anwendung finden, und die auf dem SQL-Standard
aufbauen, haben eine Funktionsvielfalt , die man in DATALOG bisher nicht
kennen gelernt hat. Auf der anderen Seite beherrschten diese DBMS bis zum
ANSI/ISO SQL-Standard von 1999 keine rekursiven Sichten.
Rekursion ist in DATALOG jedoch ein wichtiges Funktionselement, besonders im
Zusammenhang mit der Magic Sets Methode.
Im ersten Teil der Ausarbeitung wird gezeigt, dass auch praktische(kommerzielle)
DBMS von den Vorteilen der Magic Sets Methode profitieren können.
Der zweite Teil der Ausarbeitung beschäftigt sich mit der Optimierung der Magic
Sets Methode insofern, dass für bestimmte Typen von rekursiven Queries spezielle
Optimierungsansätze existieren, die sich der Magic Sets Methode bedienen, jedoch
effizienter arbeiten.
Inhalt
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 2 von 24
Teil 1
Teil 2
Teil 1
Anwendung der Magic Sets Methode in SQL Systemen
1.1
Einleitung
1.2
Traditionelle Optimierungstechniken
1.2.1 Indexing
1.2.2 Korrelation
1.2.3 Dekorrelation
1.3
Die Anwendung Magic Sets Methode á la SQL
1.4
Magic Sets Methode auf nichtrekursiven Anfragen
Effiziente Evaluierung Rechts-, Links-, und Gemischt-linearer
Regeln
2.1
Einleitung
2.2
Rechtslineare Rekursion
2.2.1 Definition
2.2.2 Beispiel
2.2.3 Transformationstechnik für rechtslineare
Rekursionen
2.3
Linkslineare Rekursionen
2.3.1 Definition
2.3.2 Beispiel und Zusammenfassung
2.3.3 Ausblick: Gemischt lineare Rekursion
Anwendung der Magic Sets Methode in SQL-Systemen
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 3 von 24
1.1
Einleitung
Die Magic Sets Methode ist eine Technik zur Optimierung der Anfragebearbeitung,
die auch die Entwicklung moderner kommerzieller DBMS beeinflusst hat.
Als die Magic Sets Methode 1986 in der Publikation "Magic Sets and other strange
ways to implement logic programs"1 veröffentlicht wurde, wurde das Thema aus der
Perspektive der logischen Programmierung betrachtet. DATALOG war das
entsprechende Werkzeug.
Originalzitat [BMSU86 S.1]: “ Logic programming is a simple but powerful
formalism for representing data and queries. The relational data model, for
example, is easily represented, as are extensions to the model. Functions and
programs can be defined along with data such that the distinction between data and
programs is blurred. Logic programming is "very-high-level" in the sense that one
specifies program functionality ("what it does") without giving an algorithm ("how
it does it"). The downside of logic programming is its implementation inefficiency.
To achieve efficient execution, we must rewrite the rules defining data, functions,
and queries in a more efficient form.”
Die Magic Sets Methode wird oft in Zusammenhang mit der logischen Optimierung
von rekursiven Anfragen erwähnt, obwohl die Technik für rekursive und nichtrekursive Anfragen anwendbar ist.
Zu dieser Zeit unterstützten die gängigen SQL-Techniken, vor allem der ANSI/IECSQL Standard vor 1999 keine rekursiven Sichten.
In der logischen Programmierung war man diesem Problem voraus, Rekursion ist
hier fast selbstverständlich. Vielleicht war das ein Grund, warum die Magic Sets
Methode lange Zeit nicht aus der SQL-Perspektive betrachtet wurde.
In diesem Dokument wird gezeigt, dass die Magic Sets Methode auch für (heutige)
kommerzielle SQL-Basierende DBMS eine interessante Technik ist.
Dazu haben sich die Autoren der Publikation [MIR1990] für „SBSQL“(=Starburst
SQL) entschieden[Anhang1].
Starburst SQL ist ein Projekt des IBM Almaden Research Centre, das in 1984-1992
entwickelt wurde. Es ist ein Prototyp eines erweiterbaren DBMS, das sowohl
Rekursion unterstützt als auch durch benutzerdefinierte Funktionen zulässt.
Insbesondere lässt sich der Sprachumfang durch eigene Konstrukte, Funktionen und
Regeln erweitern.
Ein weiteres wichtiges Merkmal ist das „Query Graph Model“ von SBSQL. Die
„query transformation engine“, die für die Optimierung der Query zuständig ist,
kann durch den Benutzer um neue Optimierungstechniken wie z.B. Magic Sets
erweitert werden.
1 [BMSU86]F. Bancilhon, D. Maier, Y. Sagiv, and J. Ullman.
Magic sets and other strange ways to implement logic programs.
In ACM SIGACT-SIGMOD Symp. on Principles of Database Systems, Cambridge MA, March 1986.
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 4 von 24
Für unseren Focus ist die Möglichkeit von „Table Expressions“ in SBSQL (im
folgenden „texp“) wichtig.
Texps ähneln von der Struktur her einer VIEW, in der Tabellen eine syntaktische
Struktur von DATALOG-Regeln haben. Eine Texp hat wie eine DATALOG Regel
einen Regelkopf, der den Tabellennamen und die Attribute beinhaltet, und einen
Regelrumpf, der die Herleitung der Regel mittels einer
SELECT…FROM…WHERE Anweisung vornimmt.
Beispiel:
spaghetti(name,persnr) AS
(SELECT name, persnr FROM personal WHERE
lieblingsessen=“Spaghetti“);
1.2
Traditionelle Optimierungstechniken
Bei der Bearbeitung einer Anfrage kann es durch eine naive Auswertung zu einer
grossen Zwischenergebnismenge relativ zur Antwortmenge kommen.
Ziel ist es, irrelevante Daten herauszufiltern, so dass diese in der
Anfragebearbeitung nicht betrachtet werden.
In der Praxis wurden bisher die Techniken „Korrelation“ und „Dekorrelation“
angewendet, die im Folgenden aufgeführt werden.
Eine gute Strategie ist, Selektionsprädikate zu „pushen“, d.h. in der OperatorbaumDarstellung so früh wie möglich, bzw. vor dem Join/Produkt von Relationen
anzuwenden.
In beiden traditionellen Optimierungsansätzen finden wir Ansätze der SIPStrategien, die systematisch gewonnene Information zur Filterung während der
Anfrage weiterreicht.
Die durch das „pushen“ gewonnenen relevanten Tupel können zum Filtern der
relevanten Daten in der Join/Produkt Operation benutzt werden.
Dabei bedient sich SBSQL eines Indexes auf der Relation.
1.2.1 Indexing
Die meisten relationalen DBMS, darunter auch SBSQL, versehen eine Relation
dynamisch während der Anfragebearbeitung mit einem Index als weiteres
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 5 von 24
Attributfeld. Man kann sich das Indexieren bildlich als einen Join der Relation mit
den Indexwerten vorstellen.
Indexierter Zugriff ermöglicht es, sequentiellen Zugriff auf Relationen zu umgehen.
Generell gilt, dass indexierte Attribute den Zugriff über eine Baumstruktur
ermöglichen*.
Beispiel:
(1) naive implementation:
SELECT
FROM
WHERE
AND
Profs,Docs
unipersonal, dozenten
lieblingsessen = „Eintopf“
unipersonal.persnr = dozenten.persnr;
(2) stattdessen:
SELECT
Profs,Docs
FROM
unipersonal_eintopf, dozenten
AND unipersonal_eintopf.persnr=dozenten.persnr;
unipersonal_eintopf(persnr, lieblingsessen) AS
SELECT persnr,lieblingsessen
FROM unipersonal
WHERE leiblingsessen=“Eintopf“;
zu den Relationen unipersonal(persnr, lieblingsessen, location, lohn) und
dozenten(persnr,name,vorl)
Eine mögliche Strategie wäre es, „dozenten“ zu indexieren um Mithilfe der
gewonnenen (relevanten) Tupel aus „unipersonal_eintopf“ die gewünschten Daten
zu extrahieren. Das relevante Attribut „persnr“ wird hier in der ersten SELECTFROM-WHERE- Klausel an die Tabelle „dozenten“ weitergereicht(„sideways
passing“). Anschliessend könnte über einen Index auf „dozenten“ auf die benötigten
Tupel ohne „Umweg“ zugegriffen werden.
1.2.2 Korrelation
Korrelation nutzt die Möglichkeit, Selektionsprädikate in Unteranfragen zu
verschieben. Dadurch wird evtl. das Bilden von Produkten von Relationen vor der
Selektion vermieden.
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 6 von 24
Beispiel:
SELECT
FROM
WHERE
AND
studnr
studHK s1
lieblingsessen = „Eintopf“
lohn > (
SELECT AVG(s2.lohn)
FROM studHK s2
WHERE s1.abt = s2.abt );
zu der Relation
studHK(name, lohn, studnr, lieblingsessen, abt)
In diesem Beispiel wird für Studenten, deren Lieblinsessen Eintopf ist,
der Durchschnittslohn seiner Kollegen in derselben Abteilung
berechnet und im Falle eines Mehrverdienstes seine studnr selektiert.
Auch hier wird ein gewonnenes Tupel aus „s1“ direkt an die Unteranfrage im Sinne
der SIP weitergereicht.
Der Vorteil ist, dass auf keine irrelevanten Fakten (wie z.B im Falle Produktes von
s1 und s2) zugegriffen wird.
Als Nachteil sticht vor allem die Tatsache ins Auge, dass hier die NichtProzeduralität und Mengenorientiertheit relationaler DBMS zerstört wird, das einen
erheblichen Performancevorteil ausmacht[MIR1990]. Der Zugriff muss zwingend
in der Reihenfolge s1, s2 erfolgen. Ausserdem könnte der Durchschnittsgehalt
mehrfach berechnet werden, z.B. für Studenten in derselben Abteilung.
1.2.3 Dekorrelation
Im Gegensatz zu Korrelation, wo Selektions-Prädikate in Unteranfragen verschoben
werden, werden diese hier aus den Unteranfragen heraus bezogen.
Beispiel:
Wir schreiben die Query aus 1.2.2 in dekorrelierter Form
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 7 von 24
SELECT
FROM
WHERE
AND
AND
studnr
studHK, durchsch_lohn
lieblingsessen = „Eintopf“
lohn > durchsch_lohn.lohn
studHK.abt = durchsch_lohn.abt ;
durchsch_lohn(abt, avg_lohn) AS
(SELECT abt,AVG(lohn)
FROM studHK);
Die dekorellierte Version hat den Vorteil, dass die nicht-prozeduralität
wiederhergestellt ist. Die texp „durchsch_lohn“ könnte in einem Zug den
Durchschnittslohn für alle Abteilungen berechnen (könnte auch noch zusätzlich
materialisiert werden), um anschliessend mit den gewonnenen Daten das HauptGoal der Anfrage zu berechnen.
Auch der Vorteil des mengenorientierten Zugriffes ist wieder verfügbar, da die
Zugriffe auf „studHK“ unabhängig sind.
Es gibt jedoch einen substantiellen Nachteil, weil die VIEW „durchsch_lohn“ das
Durchschnittsgehalt aller Abteilungen berechnet, ohne Hinblick auf relevante
Abteilungen, die im Haupt-Goal betroffen wären.
Diese Überlegungen der traditionellen Optimierungsansätze finden sich alle in der
Magic Sets Methode wieder.
1.3
Die Anwendung Magic Sets Methode á la SQL
Ziel ist es, zu zeigen dass die Magic Sets Methode zur logischen Optimierung der
Anfragebearbeitung ein durchaus praktizierbares, robustes und zudem
interessantes Verfahren ist, das auch für relationale DBMS in der Praxis in Frage
kommt.
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 8 von 24
Betrachten wir als Beispiel die folgende Query, die in SBSQL implementiert wurde:
In diesem Beispiel wird in einem industriellen Produktionswerk nach der Lagerzeit
der Produkte der Auftragsgrösse „450“, sowie ihrem Lagerort gefragt.
Dazu bedient sich die Anfrage der Tabellen produktauftrag, inventar, lagerzeit und
lagerort, auf deren inhaltliche Struktur wir nicht näher eingehen werden.
Die einfache Implementation berechnet in einem Zug die durchschnittliche
Lagerzeit Anhand der texp „lagerzeit“ (V1).
Anschliessend werden die Tabellen produktauftrag, inventar und lagerzeit in
vollem Umfang einem Join unterzogen, um daraufhin die entsprechenden Selektion
nach den Anfragekonstanten durchzuführen.
Man kann sich diese Operation in einem Operatorbaum mit der Anfrageantwort an
der Wurzel folgenderweise vorstellen(natürlich mit dem Hinweis, dass dies keinem
Operatorbaum der relationalen Algebra entsprechen würde, allein aus der Tatsache
heraus, dass z.B. Aggregation nicht definiert wäre).
In der untersten Schicht finden Joins statt, darauf folgend eine Filterung der
Ergebnistupel aus der vorhin entstandenen Zwischenrelation anhand der
Selektionskonstanten, und zuletzt die Projektion der relevanten Attribute.
Es wird bei der Berechnung der durchschnittlichen Lagerzeit (E1) keine Ausnahme
auf relevante Produkte gemacht, alle vorhandenen Tupel werden in die Berechnung
mit einbezogen.
Die hauptsächliche Anfrage verhält sich ebenso, sie ist erst „a posteriori“ über die
benötigten Tupel informiert, so dass die Selektion der entsprechenden Tupel erst
zum Schluss erfolgen muss.
Diese Vorgehensweise ist sehr ineffizient, es ist nicht schwer zu sehen, dass hier
optimiert werden kann.
(E1) lagerzeit(produktnr, halle, avg_zeit)
AS
(SELECT produktnr , halle , AVG(lagerzeit)
FROM lagerort
GROUPBY produktnr, halle)
(E2) SELECT DISTINCT produkt*, halle, avg_zeit
FROM produktauftrag, inventar, lagerzeit
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 9 von 24
WHERE
produktauftrag.auftrmenge = 450
AND
produktauftrag.produktnr = inventar.produktnr
AND
produktauftrag.produktnr = lagerzeit.produktnr
Eine intelligentere Annäherung wäre, Bindungen der relevanten Anfragewerte im
Voraus zu bestimmen.
Das ist der Magic-Sets Ansatz.
Wir bilden eine Texp „q_prod“, um zuerst Bindungen(hier: produktnr) für die
relevanten Produkte zu schaffen, die eine Auftragsgrösse von 450 haben.
Diese Bindungen werden daraufhin an „a_produktzeit“ gemäss SIP weitergereicht.
Die Tabelle „a_produktzeit“ hat den elementaren Vorteil, dass während der JoinOperation Bindungen der relevanten Fakten von „q_prod“ übernommen wurden und
der Join sehr effektiv in dem Sinne ist, dass keine irrelevanten Zwischenergebnisse
berechnet werden müssen.
Berechnung der Durchschnittszeit und Paarung des entsprechenden Produktes mit
den Tupeln aus dem betreffenden Lagerort wird zielgenau ausgeführt.
(M1a)
q_prod AS
(SELECT DISTINCT produkt *
FROM produktauftrag , inventar
WHERE auftrmenge = 450
AND produktauftrag.produktnr = inventar.produktnr)
(M1b)
a_produktzeit(produktnr, halle, avg_zeit) AS
(SELECT lagerort.produktnr, werk.halle, AVG(lagerzeit)
FROM q_prod, lagerort
WHERE q_prod.produktnr = lagerort.produktnr
GROUPBY
werk.produktnr, werk.halle)
(M1c)
SELECT DISTINCT q_prod *, halle, avg_zeit
FROM q_prod, a_produktzeit
WHERE q_prod.produktnr = a_produktzeit.produktnr
Die Anwendung der Magic Sets Methode in diesem Beispiel hat gezeigt, dass sie
durchaus auch in nichtrekursiven Anfragen „relevant“ ist.
Ein Performance-Vergleich zwischen der Query aus (E1),(E2) und der Magic-Sets
transformierten Query auf einem IBM DB2VR2 System im IBM Almaden
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 10 von 24
Research Center ergaben im Zeitlichen Verhältnis ein Ergebnis von 100-0,46 in der
Anfragebearbeitung.
1.4 Magic Sets Methode auf nichtrekursiven Anfragen
Rekursion war(ist) in kommerziellen SQL-Systemen eine Hürde, um die Magic Sets
Methode anwenden zu können, weil viele kommerzielle DBMS dieses Konstrukt
nicht beherrschten. Seit dem SQL-Standard von 1999 werden rekursive Sichten in
begrenztem Maße unterstützt.
Lange Zeit glaubte man auch der Annahme, dass die Magic Sets Methode nur in der
Anfragebearbeitung rekursiver Anfrage nützlich sei.
Der Vorteil der Magic Sets Methode ist, dass sie auch für nichtrekursive Anfragen
effizient arbeitet.
Jedoch kann es vorkommen, dass eine nichtrekursive Anfrage durch die
Transformation rekursiviert wird.
Der Grund dafür liegt häufig in gemeinsamen Teilausdrücken in Regeln, die
Querverknüpfungen verursachen, jedoch effizient behoben werden können.
Beispiel:
Betrachte :
(1)
SELECT A,B
FROM r(A,C), q(C;B)
WHERE A=10;
r(A,C) AS
q(E,F) AS
(SELECT A,C FROM q(A,D), t(D,C))
(SELECT E,F FROM s(E,F))
?
q
s
r
t
Der Abhängigkeitsgraph zeigt keine Rekursive Abhängigkeit, jedoch wird “q” als
gemeinsamer Teilausdruck zweimal benutzt
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 11 von 24
Die Magic Sets Transformation liefert folgende Regelmenge:
(2)
SELECT A,B
FROM rbf(A,C), qbf (C;B)
WHERE A=10;
query_rbf (10);
rbf (A,C)
qbf (E;F)
bf
query_q (A)
AS (SELECT A,C FROM query_rbf (A) , qbf (A,D), t(D,C));
bf
AS (SELECT E,F FROM query_q (E) , s(E,F));
AS ((SELECT C FROM rbf (A,C) WHERE A=10)
UNION
(SELECT A FROM query_rbf (A)));
Nun hat der Abhängigkeitsgraph der Magic Sets transformierten Regel eine
rekursive Abhängigkeit zwischen „q“ , „r“ und „q_q(query_q)“:
?
*
q
s
q_q
r
q_r
t
Die Rekursion ist auf die Magic-Sets-Regel „query_q“ zurückzuführen.
Ein Lösungsvorschlag wäre, den gemeinsamen Teilausdruck „q“ aus der
ursprünglichen(untransformierten) Anfrage (1) nicht als gemeinsamen Teilausdruck
zu verwenden. Stattdessen kann man das zweimalige Auftreten der Regel „q“ aus
(1)
SELECT A,B
FROM r(A,C), q(C;B)
WHERE A=10;
r(A,C) AS
q(E,F) AS
(SELECT A,C FROM q(A,D), t(D,C))
(SELECT E,F FROM s(E,F))
durch Betrachtung als zwei verschiedene Regeln umgehen, z.B. als „q“ und „Q“.
Zu beachten ist hier, dass ei der Datenflussanalyse sich herausstellt, dass die
Rekursion nach einem Loop terminiert, d.h. „q“ kann für „r“ keine neuen Fakten
generieren, ergo ist die Rekursion sinnlos.
Man könnte somit die Regelmenge komplett umschreiben.
Wenn wir die Regel „q“ getrennt als „q“ und „Q“ in ihren Vorkommen betrachten
und (1) durch (1b) ersetzen.
(1b)
SELECT A,B
FROM r(A,C), q(C;B)
WHERE A=10;
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 12 von 24
r(A,C) AS
q(E,F) AS
(SELECT A,C FROM Q(A,D), t(D,C))
(SELECT E,F FROM s(E,F))
//Q statt q
//dieses q bleibt
Anschliessend (1b) durch die Magic Sets Methode transformieren, erhalten wir
folgenden nichtrekursiven Abhängigkeitsgraphen:
?
q
s
r
q_q
q_r
t
Q
Allgemein gilt:
Ist der Abhängigkeitsgraph einer Query ein azyklischer gerichteter Baum, so ist der
Graph seiner Magic-Sets transformierten ein gerichteter azyklischer Graph(evtl.
kein Baum mehr). Ist der Abhängigkeitsgraph einer Query ursprünglich ein
gerichteter azyklischer Graph, so ist der Graph seiner Magic Sets Transformation
ein zyklischer gerichteter Graph(rekursiver Datenfluss).
Teil 2
Effiziente Evaluierung Rechts-, Links-, und Gemischt-linearer
Regeln
2.1 Einleitung
In diesem Kapitel wird ein Verfahren zur Optimierung der Magic Sets Methode
verwendet, die sich in den meisten Fällen als eine Performance steigernde Methode
für bestimmte Rekursionstypen erwiesen hat.
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 13 von 24
Viele Techniken zur Evaluation von Rekursionen wurden vor dem Hintergrund
erdacht, eine „allgemein anwendbare“ Methode zu sein, dazu gehören auch Magic
Sets.
Für einige simplere Rekursionstypen sind jedoch Evaluationsalgorithmen bekannt,
die ein besseres Ergebnis im Sinne der Performance bieten.
Andere Techniken wiederum, die „special purpose“-Evaluationsalgorithmen für
eine breite Menge von Rekursionstypen bereitstellen, haben den Nachteil, nicht im
Gedanken an die Allgemeinheit konzipiert worden zu sein. Diese folgen nicht dem
klassischem „Magic Sets“-Paradigma, einer Regelkompilierungsphase und einer
Anfragebearbeitungsphase, zudem ist es auch schwieriger diese um den Umgang
mit Negation und mengenorientierter Sprachkonstrukte zu erweitern.
Die hier vorgestellten Verfahren zur Optimierung der Magic Sets Methode greifen
in der Regelkompilierungsphase ein. Die rewriting-Strategie hat –vereinfacht
ausgedrückt- den Vorteil, dass die Transformation die Stelligkeit des rekursiven
Prädikates verringert.
Zuerst folgt eine syntaktische Beschreibung der Rekursionstypen, für die unsere
Optimierungstechnik anwendbar ist.
Wir werden rechtslineare Rekursionen , linkslinare Rekursionen und Gemischlineare Rekursionen formal beschreiben.
Dabei betrachten wir Regeln in DATALOG-Notation, zur Vereinfachung nehmen
wir an , dass in einer Regel nur ein rekursives Prädikat vorkommt.
2.2 Rechtslineare Rekursionen
Im Prinzip nennen wir eine rekursive Regel rechtslinear, wenn in einer Regel das
rekursive Prädikat im rechten äusseren Block des Regelrumpfes vorkommt.
2.2.1 Definition
Gegeben ist eine Menge von Regeln in DATALOG Notation, bestehend aus
EDB(Basis-)- und IDB(definiert-)-Prädikaten und ein Query-Goal mit einem
entsprechenden adornment W.
Wir nehmen an, dass nur ein rekursives IDB-Prädikat existiert.
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 14 von 24
(Def.)Datalog-Regeln werden rechtslinear genannt, falls alle rekursiven Regeln,
unter Betrachtung des „adornments“ W folgende Form haben,
p(X1,…Xm, Y1, …,Yn)
G1, …,Gk, p(W1,…Wm,Y1,…,Yn)
Wir nehmen O.B.D.A. an, dass die ersten m Argumente (X1,…Xm) in p
entsprechend W gebunden sind.
Wobei folgende Bedingungen erfüllt sind:
• G1,…Gk sind Subgoals bestehend aus EDB Prädikaten (um die Annahme zu
erfüllen, dass nur ein einziges rekursives Prädikat im Regelrumpf vorkommt)
• Yi (i=1…n)sind paarweise verschieden und kommen sowohl im Regelrumpf
als auch im Regelkopf jeweils einmal vor.
• Wi (i=1…n) entweder Variablen der Subgoals sind, oder zu der Menge
{X1,…,Xm} gehören.
Diese Bedingungen implizieren folgendes:
Das Adornment des Regelrumpfes einer solchen o.g. Regel ist identisch mit dem
Adornment des Regelrumpfes.
Auf diese Weise wird gewährleistet, dass bei der Evaluation eine Antwort auf das
rekursive Subgoal eine direkte Antwort an das aufrufende Subgoal liefert, da die
Antworten auf die freien Variablen sich direkt im aufrufenden Subgoal
wiederspiegeln.
Ziel der Definition ist es, dass das adornment-Pattern der Regel sich in der
rekursiven Regel(im Regelrumpf) wiederfindet.
Es ist hier wichtig, dass W1,…Wm keine freien Variablen sind.
Weiterhin ist es wichtig, dass Y1,….,Yn freie Variablen sind, und dass ihre Existenz
sowohl im Regelkopf als auch im Regelrumpf gesichert ist.
Die rekursive Regel hat im rechten äusseren Block des Regelrumpfes ein rekursives
Subgoal, die vorangehenden Subgoals im Regelrumpf bestehen aus EDBPrädikaten.
2.2.2 Beispiel:
Betrachte folgende Regelmenge:
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 15 von 24
R1:
R2:
p(X,Y)
p(X,Y)
[
[
k(X,Y)
k(X,Z) , p(Z,Y)
Die Regeln R1 und R2 definieren die transitive Hülle eines Graphen, die Relation
„p“ steht für einen Pfad und de Relation „k“ für eine Kante des Graphen.
Die Faktenmenge für „k“ sei {(x0,x1),….,(xn-1,xn)}
Die Anfrage sei {[Y] : p(x0 ,Y)} ?
Wenden wir die Magic Sets Methode an, werden speziell für die aktuelle Anfrage
folgende Regeln benötigt:
query_p(x0) als seed-Fakt
query_p1(Y) [ query_p1 (X) , k(X,Y)
answer_p (X,Y) [ query_p1(X) , k(X,Y)
answer_p (X,Y) [ query_p1(X) , k(X,Z) , answer_p(Z,Y)
Essentiell gesehen ist dieses Problem ein Graphenproblem und wird als singlesource reachabilty Problem bezeichnet. Man kann es durch eine Tiefensuche für
einen Graphen mit n Kanten in Zeit O(n) lösen [Blum2001*].
Man könnte von einem gegebenen Knoten x0 aus eine Tiefensuche starten und alle
über eine Kante erreichbaren Knoten berechnen. Diese Lösung wäre auch geeignet,
unsere Query zu beantworten.
Die Magic Query berechnet aus der Regel „k“ für „query_p“ die Faktenmenge
{x0,…,xn}.
Die für „p“ berechnete Faktenmenge ist {(xi,xj) | 0 ] i < j ] n}
Und speziell die Antwortmenge der Query {(x0,xj) | 0 < j ] n}
Die gesamte Evaluation generiert _(n2) Fakten (wenn man davon ausgeht, dass die
Basisfakten eine Grösse von O(n) haben), wie man leicht sehen kann.
answer_p(x0,x3)
query_p(x0)
k(x0, x1)
answer_p(x1,x3)
_________________________________________________________________________
Anwendung und Optimierung
k(x1, x2)
query_p(x1) der Magic Sets Methode
Taner Tas ©2003
Seite 16
von 24
answer_p(x
2,x3)
k(x2, x3)
…..
Reduziert man die Anfrage auf das Erreichbarkeitsproblem im Graphen, kommen
wir auf folgenden Schluss:
Die Regeln
answers(Y) 4 query_p(X) , k(X,Y)
query_p(x0)
query_p1(Y) [ query_p1 (X) , k(X,Y)
sind völlig hinreichend, um die gesamte Antwortmenge zu produzieren und
sie erzeugen nur O(n)(angenommen, die EDB-Prädikate haben die Grösse
o(n)) Fakten.
Der Grund liegt darin, dass die einzige übrig gebliebene rekursive Regel die
„query“-Regel ist, und diese hat nur ein rekursives Argument anstelle von
zwei in der ursprünglichen Rekursion.
Durch die Regel „query_p“ und „k“ wird sozusagen eine „Tiefensuche“ auf dem
Graphen der Grösse n durchgeführt, den wir Mithilfe der Basisrelation „k“
darstellen können. Die Regel „query_p“ bezeichnet hierbei die
Zusammenhangskomponenten des Graphes.
Dieses Pattern von Rekursionen werden wir weiter aufführen und die
Transformationstechnik näher kennen lernen.
2.2.3 Transformationstechnik für rechtslineare Rekursionen
Gegeben sei eine Regelmenge mit rechtslinear rekursiven Regeln der Form
p(X1,…Xm, Y1, …,Yn)1…m
G1, …,Gk, p(W1,…Wm,Y1,…,Yn)
wir nehmen O.B.D.A. an, dass die linken m Argumente gebunden sind.
Für jede solche Regel erzeugen wir die Regel.
query_p(W1,……Wm) 1…m
query_p(X1,…,Xm), G1, …,Gk
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 17 von 24
„query_p“ entsteht durch weglassen der freien Argumente von „p“
Entsprechend der Magic Sets Methode fügen wir nun ein „Seed-Fakt“ hinzu
query_p(X1,…,Xm)
{x1,…,xm} Anfragekonstanten
Aus den freien Variablen der Query erzeugen wir die Antwortregel
Die Antwortregel entsteht durch Extraktion der nichtrekursiven Bestandteile der
Regelmenge. D.h. für jede Regel nichtrekursive Regel der Form
p(X1,…Xm, Y1, …,Yn)
G1, …,Gk
konstruieren wir die Antwortregel
answer_p(Y1,…,Yn)
query_p (X1,…,Xm) 1…m , G1,…,Gk
Zuletzt wird die Anfrageregel mit {x1,…,xm} als Anfragekonstanten generiert.
p(x1,…,xm, Y1, …,Yn))
answer_p(Y1,…,Yn)
Die neu erzeugten Regeln
answer_p(Y1,…,Yn)
query_p (X1,…,Xm) 1…m , G1,…,Gk
query_p(X1,…,Xm)
query_p(X1,…,Xm), G1, …,Gk
query_p(W1,……Wm) 1…m
sind hinreichend, um die ewünschte Anfrage zu evaluieren.
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 18 von 24
2.3 Linkslineare Rekursion
2.3.1 Definition
Gegeben ist eine Menge von Regeln in DATALOG Notation, bestehend aus EDBund IDB-Prädikaten und ein Query-goal mit einem entsprechenden adornment W.
Wir nehmen an, dass nur ein rekursives IDB-Prädikat existiert.
(Def.)Datalog-Regeln werden linkslinear genannt, falls alle rekursiven Regeln,
unter Betrachtung des „adornments“ W folgende Form haben,
p(X1,…Xm, Y1, …,Yn)
p(X1,…Xm,V1,…,Vn), G1, …,Gk
Wir nehmen O.B.D.A. an, dass die ersten m Argumente (X1,…Xm) in p
entsprechend einem gegebenen Adornment W gebunden sind.
Wobei folgende Bedingungen erfüllt sind:
• G1,…Gk sind Subgoals bestehend aus EDB Prädikaten (um die Annahme zu
erfüllen, dass nur ein einziges rekursives Prädikat im Regelrumpf vorkommt)
• Yi und Vi (i=1…n) paarweise von Xi (i=1…n) verschieden sind.
• Xi (i=1…n) niemals in den Subgoals G1,…,Gk auftauchen.
2.3.2 Beispiel und Zusammenfassung
Dasselbe Beispiel aus 2.2.2 betrachten wir in der linkslinearen Ausführung.
R1:
R2:
p(X,Y)
p(X,Y)
[
[
k(X,Y)
p(X,Z) , k(Z,Y)
Die Anfrage sei {[Y] : p(x0 ,Y)} ?
Setzen wir die Anfragekonstante in die Regel ein, sehen wir, dass das gebundene
Argument an der ersten Position von „p“ stets „besetzt“ ist:
R1:
R2:
p(x0,Y)
p(x0,Y)
[
[
k(x0,Y)
p(x0,Z) , k(Z,Y)
Somit ist die erste Attributposition der Regeln redundant. Vereinfachen wir somit
die Notation, indem wir die rekursive Regel um das gebundene Argument kürzen,
so erhalten wir:
R1:
p(Y) [
k(x0,Y)
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 19 von 24
R2:
p(Y) [
p(Z) , k(Z,Y)
Wir können somit auch direkt ohne Umweg über die Magic Sets Methode die
Antwortmenge erzeugen.
answer_p(Y) [
answer_p(Y) [
k(x0,Y)
answer_p(Z) , k(Z,Y)
Währende der Evaluation können wir durch die systematische Ausweitung der
Antwortmenge rekursiv die gesamte Antwortmenge produzieren.
Wieder ist die Anzahl der Argumente der rekursiven Regel kleiner als ursprünglich.
Die Transformation erreicht jedoch keinen Performance-Vorteil gegenüber der
reinen Magic Sets Methode, vielmehr ist die Performance-Rate gleichzusetzen.
2.3.4
Ausblick: Gemischt lineare Rekursion
Regelmengen, die sowohl aus rechts- als auch linksrekursiven Regeln bestehen,
können von den Vorteilen der Ergebnisse der vorangegangenen Kapitel profitieren.
Eine kurze Erläuterung wäre:
Durch die Analyse der Bindungsmuster der gesamten gegebenen Regelmenge, stellt
man fest, welche Regeln Antworten erzeugen, und welche neue Bindungen
produzieren.
Für jede solche Regel konstruieren wir vereinfachte Regeln, wie in 2.2 und 2.3
erläutert wurde und werten diese Regeln aus.
Anhang1 Starburst SQL
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 20 von 24
Starburst
The goal of the Starburst project at IBM Almaden (1984-1992) was to build a complete,
operational prototype of an extensible relational database management system. The
extensibility built into every aspect of Starburst made it easier for the user to customize the
system for the user's special needs, to experiment with new database technologies, and to
rapidly incorporate new features that better support new application areas (such as
CAD/CAM, geographic, text, and expert systems) as well as traditional business
applications. Starburst allowed the user to add new storage methods for tables, new types
of access methods, user-defined operations on tables or columns of those tables, new query
optimization strategies, and user-defined actions in response to changes in the database,
among many others.
Making Starburst Extensible
Different kinds of internal mechanisms were used to make Starburst extensible.
To make the Starburst language extensible, an open-ended syntax was created that allowed
additions to existing commands without requiring modification of the underlying command
processor, through the addition of user-defined functions. To add a user-defined function,
e.g., "boundary overlap", an extender would insert the function name and parameter types
in the FUNCTIONS catalog, along with the C code implementing it.
Extensions deeper in Starburst, such as adding storage methods or access methods, were
made by registering with Starburst the new code to do certain standard operations -- such
as update, insert, and delete. This was done simply by initializing an entry in an internal
vector for each operation.
Starburst's authorization mechanism made it easy to add user-specific extensions. Access
privileges were granted or revoked on types of database objects for individual users or
groups of users. The authorization algorithm allowed arbitrary, acyclic nesting of user
groups. Regardless of the complexity of the user group nesting, testing authorizations took
constant time. Access privileges for database objects could be hierarchical and could
reflect the wide diversity in requirements and semantics allowed by Starburst's extensions.
It wass possible to restrict access to objects in a variety of ways, including recursively
revokable granting of privileges and transfer of object ownership.
Specialized Indices
Most current systems give a single way of storing data (e.g., a B-tree) and a single way of
reaching the data (e.g., B-tree indices). Starburst allowed the user to choose a storage
method and then to define multiple ways of accessing that data. These multiple access
paths, the attachments, had redundent information that is associated with the data (B-tree
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 21 von 24
indices, signature files, hash tables, join indices, single record integrity constraints and
referential integrity constraints). When the user updated the data, Starburst automatically
updated the attachments.
Cataloging objects (How does Starburst find things?)
Descriptive information, or descriptors, for all objects in the system were kept in system
catalogs. Descriptors contained information about queries or about objects needed by the
query execution routines, such as a table's storage method and all of its attachments. Since
object descriptors were packaged as records, objects associated with the standard Starburst
queries could be handled with the same facility as objects associated with extensions.
Performance and Query Optimization
A query is parsed, semantically checked, and rewritten into a form that is easier to
optimize. In Starburst, this form was known as the query graph model. Starburst provided
powerful and extensible tools for improving query performance that used this model. The
query rewrite engine allowed an extender to define query transformations (for example,
subquery to join transformations) that could improve performance. The query optimizer
determined an execution strategy using macro-like processing, which recognized operators
in the query graph and expanded them using named rules. An expansion might be
expanded, itself, and each expansion could have alternatives. Each branch of this resulting
decision tree was evaluated for its estimated cost of execution, and the lowest-cost branch
was chosen. Although rules were provided with the system, if the user added a new way of
accessing the data, the rules could be modified to reflect this new attachment.
Extensions
We made many extensions to Starburst. Through extensions to Starburst, we
incorporated the advanced structuring and data behavior features offered by object-oriented
database management systems, while retaining the significant gains in data independence
and data integrity of the relational model and upward compatibility with its standard access
language, SQL. Some of the advanced features supported by Starburst extensions include
hierarchies of user-defined types and functions, large unstructured and structured complex
objects, and user-defined rules (triggers) to respond to changes in the database.
Referenzen Starburst SQL
Making Starburst Extensible
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 22 von 24
L.M. Haas, J.C. Freytag, G.M. Lohman, H. Pirahesh, "Extensible Query Processing in Starburst",
Proceedings of ACM SIGMOD, Portland, Oregon (May 1989).
L.M. Haas, W. Chang, G.M. Lohman, J. McPherson, P.F. Wilms, G. Lapis, B. Lindsay, H.
Pirahesh, M. Carey, and E. Shekita, "Starburst Mid-Flight: As the Dust Clears", IEEE Trans. on
Knowledge and Data Engineering, March 1990, pp. 143-160. Also available as IBM Research
Report RJ7278, San Jose, CA, Jan. 1990. R. Gagliardi, George Lapis, Bruce Lindsay, "A Flexible
and Efficient Database Authorization Facility", IBM Research Report RJ 6826 (May 1989).
Specialized Indices
B. Lindsay, J. McPherson, and H. Pirahesh, "A Data Management Extension Architecture", Procs.
of ACM SIGMOD, May 1987, San Francisco, pp. 220-226. Also available as IBM Research
Report RJ5436, San Jose, CA, Dec. 1986.
W. Chang and H-J. Schek, "A Signature Access Method for the Starburst Database System", Procs.
of 15th International Conf. on Very Large Data Bases (VLDB), August 1989, Amsterdam, pp. 145153. Also available as IBM Research Report RJ6670, San Jose, CA, Feb. 1989.
M. Carey, E. Shekita, G. Lapis, B. Lindsay, and J. McPherson, "An Incremental Join Attachment
for Starburst," Procs. of 16th International Conference on Very Large Data Bases (VLDB),
Brisbane, Australia, August 1990, pp. 662-673. Also available as IBM Research Report RJ7544,
San Jose, CA, June 1990.
Performance and Query Optimization
W. Hasan, H. Pirahesh, "Query Rewrite Optimization in Starburst", IBM Research Report RJ 6367
(August 1988).
G.M. Lohman, "Grammar-like Functional Rules for Representing Query Optimization
Alternatives", Proceedings of ACM SIGMOD (June 1988).
M. Lee, J.C. Freytag, and G.M. Lohman, "Implementing an Interpreter for Functional Rules in a
Query Optimizer", Procs. of 14th International Conference on Very Large Data Bases (VLDB)
(August 1988, Long Beach, CA) pp. 218-229. Also available as IBM Research Report RJ6125, San
Jose, CA, March 1988.
K. Ono, G. Lohman, "Extensible Enumeration of Feasible Joins for Relational Query
Optimization", IBM Research Report RJ 6625 (December 1988).
K. Ono and G.M. Lohman, "Measuring the Complexity of Join Enumeration in Query
Optimization", Procs. of 16th Intl. Conf. on Very Large Data Bases (VLDB), August 1990,
Brisbane, Australia.
J.C. Freytag, "A Rule-Based View of Query Optimization", Proceedings of 1987 ACM SIGMOD
San Francisco (May 1987).
Recovery
C.Mohan, D. Haderle, B. Lindsay, H. Pirakesh, P. Schwartz, "ARIES: A Transaction Recovery
Method Supporting Fine-Granulairty Locking and Partial Rollback Using Write-Ahead Logging",
IBM Research Report RJ 6649 (January 1989).
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 23 von 24
C. Mohan, F. Levine, "ARIES/IM: An Efficient and High Concurrency Index Management Method
Using Write-Ahead Logging", IBM Research Report RJ 6846 (May 1989).
K. Rothernel, C. Mohan, "ARIES/NT: A Recovery Method Based on Write-Ahead Logging for
Nested Transactions", IBM Research Report RJ 6650 (January 1989), Proceedings 15th
International Conference on VLDB, Amsterdam, Netherlands (August 1989).
Extensions
G.M. Lohman, B.G. Lindsay, H. Pirahesh, and K.B. Schiefer, "Extensions to Starburst: Objects,
Types, Functions, and Rules", Comms. of ACM (Oct. 1991).
T.J. Lehman and B.G. Lindsay, "The Starburst Long Field Manager", Procs. of 15th Intl. Conf. on
Very Large Data Bases (VLDB), (August 1989, Amsterdam) pp. 375-383.
J. Widom and S.J. Finkelstein, "Set-Oriented Production Rules in Relational Database Systems",
Procs. of ACM-SIGMOD, May 1990, Atlantic City, NJ, pp. 259-270. Extended version available
as IBM Research Report RJ6880, San Jose, CA, June 1989, revised March 1990.
J. Widom and S.J. Finkelstein, "A Syntax and Semantics for Set-Oriented Production Rules in
Relational Database Systems (Extended Abstract)", SIGMOD Record, Special Issue on Rule
Management and Processing in Expert Database Systems, Sept. 1989, vol. 18, no. 3, pp. 36-45.
S. Ceri and J. Widom, "Deriving Production Rules for Constraint Maintenance", Procs. of 16th
International Conference on Very Large Data Bases (VLDB), August 1990, Brisbane, Australia,
pp. 566-577. Extended version available as IBM Research Report RJ7348, San Jose, CA, March
1990.
U. Schreier, H. Pirahesh, R. Agrawal, and C. Mohan, "Alert: an Architecture for Transforming a
Passive DBMS into an Active DBMS", Procs. of 17th International Conference on Very Large
Data Bases (VLDB), Sept. 1991, Barcelona, Spain.
_________________________________________________________________________
Anwendung und Optimierung der Magic Sets Methode
Taner Tas ©2003
Seite 24 von 24