Semantik und Rekursion Semantik und Rekursion

Semantik
Semantikund
undRekursion
Rekursion
1
Intelligente
IntelligenteDatenbanken
Datenbanken
SS 2011
Semantik
Semantik und
und Rekursion
Rekursion
- Kapitel 1 -
© 2011 Prof. Dr. R. Manthey
Intelligente DB
1
Semantik
Semantikvon
vonSichten
Sichten
1
Die Bedeutung (Semantik) einer Sichtdefinition lässt sich stets nur relativ zu einem
bestimmten Zustand der zugehörigen relationalen DB definieren.
(von griech.:
griech.: sēmainein = “bedeuten”
bedeuten”)
Über einem solchen Zustand „bedeutet“ die Sicht dann die Menge aller über diesem
Zustand mittels der Sichtdefinition ableitbaren Fakten, d.h., die Antworttabelle der
Anfrage SELECT * FROM <view>.
v1:
v2:
a
1
3
a
2
5
6
CREATE
CREATEVIEW
VIEWvvAS
AS
(SELECT
a
(SELECT a
FROM
FROM t)t)
t1: a
1
3
© 2011 Prof. Dr. R. Manthey
t2: a
b
2
4
2
5
6
Intelligente DB
b
2
4
8
2
Beispieldaten
Beispieldatenzur
zurStammbaumdarstellung
Stammbaumdarstellung
Elizabeth
1
∞
Charles ∞ Diana
William
Philip
Anne
Kate
∞ Mark
Peter
∞
Autumn
kinder
mutter
vater
kind
Elizabeth
Philipp
Charles
Elizabeth
Philipp
Anne
Diana
Charles
William
Anne
Mark
Peter
Autumn
Peter
Savannah
© 2011 Prof. Dr. R. Manthey
Savannah
Intelligente DB
3
SQL
-Sicht und
öriger RA
-Operatorgraph
SQL-Sicht
undzugeh
zugehöriger
RA-Operatorgraph
1
Jede SQL-Anfrage wird vom DBMS zunächst intern in einen äquivalenten Ausdruck
der Relationen Algebra (RA) übersetzt – dieser Ausdruck wird dann (ggf. nach weiterer
„Optimierung“) ausgewertet, um die Antworttabelle zu bestimmen.
RA-Ausdrücke werden oft graphisch in Form von Graphen repräsentiert, deren Blätter
Tabellen und deren innere Knoten RA-Operatoren sind.
Jede SQL-Sicht lässt sich analog in der RA als Operatorgraph darstellen.
eltern
∪
π
π
In der Regel werden wir
im folgenden Attribute
einer Projektion vereinvereinfachend weglassen.
© 2011 Prof. Dr. R. Manthey
kinder
CREATE
, kind
) AS
CREATEVIEW
VIEWeltern(el
eltern(el,
kind)
AS
(SELECT
vater
,
kind
(SELECT vater, kind
FROM
)
FROM kinder
kinder)
UNION
UNION
(SELECT
, kind
(SELECT mutter
mutter,
kind
FROM
kinder
);
FROM kinder);
Intelligente DB
4
Operatorgraph
Operatorgraphvs.
vs.Operatorbaum
Operatorbaum
1
Oft wird statt einer allgemeinen Graphdarstellung die Darstellung als Operatorbaum
bevorzugt, bei der mehrfach verwendete Inputtabellen auch durch „Kopien“ desselben
Knotens mehrfach repräsentiert sind:
eltern
eltern
∪
∪
π
π
kinder
π
π
kinder
kinder
Bäume sind (zusammenhängende) Graphen, die auch in ihrer ungerichteten Form
zyklenfrei sind.
Wir werden im folgenden beide Varianten verwenden, je nach Kontext.
© 2011 Prof. Dr. R. Manthey
Intelligente DB
5
Semantik
Semantikder
derElternsicht
Elternsicht
1
kinder
mutter
vater
kind
Elizabeth
Philipp
Charles
Elizabeth
Philipp
Anne
Philipp
Charles
Diana
Charles
William
Philipp
Anne
Anne
Mark
Peter
Charles
William
Autumn
Peter
Savannah
Mark
Peter
Peter
Savannah
Elizabeth
Charles
Elizabeth
Anne
Diana
William
Anne
Peter
Autumn
Savannah
eltern
elternteil
SELECT
SELECT **
FROM
FROM eltern
eltern
CREATE
, kind
) AS
CREATEVIEW
VIEWeltern(el
eltern(el,
kind)
AS
(SELECT
, kind
(SELECT vater
vater,
kind
FROM
kinder
)
FROM kinder)
UNION
UNION
(SELECT
, kind
(SELECT mutter
mutter,
kind
FROM
);
FROM kinder
kinder);
© 2011 Prof. Dr. R. Manthey
Intelligente DB
kind
6
Berechnung
eltern“ ininder
Berechnungder
derSemantik
Semantikvon
von„„eltern“
derRA
RA
1
kinder
mutter
vater
kind
Elizabeth
Philipp
Charles
Elizabeth
Philipp
Anne
Philipp
Charles
Diana
Charles
William
Philipp
Anne
Anne
Mark
Peter
Charles
William
Autumn
Peter
Savannah
Mark
Peter
Peter
Savannah
Elizabeth
Charles
Elizabeth
Anne
Diana
William
Anne
Peter
Autumn
Savannah
eltern
elternteil
eltern
∪
π
π
Wie
Wiewird
wirdein
einsolcher
solcherOperatorgraph
Operatorgraph
abgearbeitet?
abgearbeitet?
kinder
© 2011 Prof. Dr. R. Manthey
kind
Intelligente DB
7
Abarbeitungsalternativen
-Ausdrücken
Abarbeitungsalternativenbei
beiRA
RA-Ausdrücken
1
Eine mögliche Abarbeitungsstrategie würde
zuerst die beiden Projektionen vollständig
und separat berechnen (und danach temporär
zwischenspeichern) und danach erst die
Vereinigung bilden, etwa so:
eltern
1.
∪
2.
π
π
kinder
kinder
eltern
3.
∪
1.
π
π
kinder
kinder
2.
Das
DasZwischenspeichern
Zwischenspeichernvon
vonTeil
Teilergebnissen
ergebnissenwollen
wollenwir
wirebenfalls
ebenfalls
(tempor
ä
re)
Materialisierung
(temporäre) Materialisierungnennen.
nennen.
© 2011 Prof. Dr. R. Manthey
Eine ganz andere Strategie könnte sein,
die linke Projektion gleich „durchzureichen“
und dadurch das Zwischenspeichern zu
vermeiden – danach würde erst die rechte
Projektion folgen (auch direkt mit der
Vereinigung gekoppelt)!
Ein
Einsolches
solchesZusammenfassen
Zusammenfassenvon
vonOperatoren
Operatoren
nennt
.
nenntman
manPipelining
Pipelining.
Intelligente DB
8
Auswertung
Auswertunghierarchisch
hierarchischdefinierter
definierterSichten
Sichten
1
großeltern
π
Sichten können auf anderen Sichten aufbauen – ist
der zugehörige Abhängigkeitsgraph zyklenfrei,
zyklenfrei nennt
man solche Sichten hierarchisch.
hierarchisch
CREATE
ßeltern(ge, enkel
) AS
CREATEVIEW
VIEWgro
großeltern(ge,
enkel)
AS
(SELECT
e1.el,
e2.kind
(SELECT e1.el, e2.kind
FROM
FROM eltern
elternAS
ASe1
e1 JOIN
JOINeltern
elternAS
ASe2
e2
ON
ON e1.kind
e1.kind==e2.el)
e2.el)
eltern
eltern
Abhä
Abhängigkeitsgraph:
groß
großeltern
eltern
CREATE
, kind)
) AS
eltern(el
kind
CREATEVIEW
VIEWeltern(el,
eltern(el,
kind)
AS
(SELECT
vater,
,
kind
vater
(SELECT vater, kind
FROM
)
kinder
FROM kinder)
kinder)
UNION
UNION
(SELECT
, kind
mutter
(SELECT mutter,
mutter,
kind
FROM
kinder);
);
kinder
FROM kinder);
π
π
kinder
kinder
© 2011 Prof. Dr. R. Manthey
∪
Intelligente DB
9
Expandierungssemantik
Expandierungssemantikhierarchischer
hierarchischerSichten
Sichten
1
Im SQL-Standard ist die Bedeutung solcher hierarchischer Sichten mittels syntaktischer
Expandierung der Sichtdefinition beschrieben, d.h. durch Einsetzen der Definition der
Untersicht in den FROM-Teil der Obersicht:
CREATE
ßeltern(ge,
) AS
gro
eltern(ge, enkel)
enkel
CREATEVIEW
VIEWgroß
großeltern(ge,
enkel)
AS
(SELECT
(SELECTe1.el,
e1.el,e2.kind
e2.kind
FROM eltern AS e1 JOIN eltern AS e2
FROM eltern AS e1 JOIN eltern AS e2
ON
ON e1.kind
e1.kind==e2.el)
e2.el)
CREATE
ßeltern(ge, enkel
) AS
CREATEVIEW
VIEWgro
großeltern(ge,
enkel)
AS
(SELECT
(SELECT e1.el,
e1.el,e2.kind
e2.kind
FROM
FROM((SELECT
((SELECT vater
vaterAS
ASel,
el,kind
kind
CREATE
, kind)
) AS
eltern(el
kind
CREATEVIEW
VIEWeltern(el,
eltern(el,
kind)
AS
(SELECT
vater,
,
kind
vater
(SELECT vater, kind
FROM
)
kinder
FROM kinder)
kinder)
UNION
UNION
(SELECT
, kind
mutter
(SELECTmutter,
mutter,
kind
FROM
);
kinder
FROM kinder);
kinder);
© 2011 Prof. Dr. R. Manthey
FROM
)
kinder
FROM kinder)
kinder)
UNION
UNION
(SELECT
, kind
mutter
(SELECT mutter,
mutter,
kind
FROM
kinder))
))
kinder
FROM
kinder))AS
ASe1
e1
JOIN
((SELECT
vater,
,
kind
vater
JOIN ((SELECT vater, kind
FROM
)
kinder
FROM kinder)
kinder)
UNION
UNION
(SELECT
, kind
mutter
(SELECT mutter,
mutter,
kind
FROM
)) AS
kinder
FROM kinder))
kinder))
ASe2
e2
ON
ON e1.kind
e1.kind==e2.el)
e2.el)
Intelligente DB
10
Operatorbaum
Operatorbaumzur
zurexpandierten
expandiertenSichtdefinition
Sichtdefinition
1
großeltern
Gemäß der expandierten Definition
von großeltern würde die Berechnung
der Bedeutung der Sicht eltern doppelt
ausgeführt werden – das entspräche
einer Operatorbaumdarstellung,
Operatorbaumdarstellung die
dann vermutlich mittels Pipelining
abgearbeitet würde:
π
eltern
Diese
äre vermutlich
DieseStrategie
Strategiewwäre
vermutlich
nicht
sonderlich
effizient
, besonders
nicht sonderlich effizient,
besonders
wenn
ß ist!
wenndie
dieElternrelation
Elternrelationgro
groß
ist!
© 2011 Prof. Dr. R. Manthey
eltern
∪
∪
π
π
π
π
kinder
kinder
kinder
kinder
Intelligente DB
11
Operatorgraphvariante
ärer Materialisierung
Operatorgraphvariantemit
mittempor
temporärer
Materialisierung
1
großeltern
π
2.
Wesentlich günstiger würde in diesem Fall
wohl eine Strategie sein, bei der man zuerst
eltern materialisiert (nach welcher Strategie
ist egal) und danach (vermutlich mit Pipelining
von Join und Projektion) erst großeltern mit
doppeltem Zugriff auf die zwischengespeicherte
eltern-Relation berechnet.
eltern
∪
1.
π
π
kinder
© 2011 Prof. Dr. R. Manthey
InIndiesem
diesemBeispiel
Beispielhatten
hattenwir
wirstets
stetsdie
dieWahl
Wahl
zwischen
verschiedenen
Abarbeitungs
zwischen verschiedenen Abarbeitungsstrategien
überstrategienund
undkonnten
konntendabei
dabeiEffizienz
Effizienzüberlegungen
legungeneinsetzen,
einsetzen,ohne
ohnedass
dassdie
dieKorrekt
Korrektheit
gefährdet“ ist.
heitdes
desResultats
Resultats„„gefährdet“
ist.
Das
Dasist
istnicht
nichtimmer
immerso!
so!
Intelligente DB
12
Hierarchische
HierarchischeSicht
Sichtmit
mitDifferenzbildung
Differenzbildung
1
Jemand ist kinderlos, wenn er/sie selbst
ein Kind (von jemandem ist), aber keine
eigenen Kinder hat:
kinderlos
–
π
CREATE
) AS
CREATEVIEW
VIEWkinderlos(person
kinderlos(person)
AS
(SELECT
kind
(SELECT kind
FROM
)
FROM kinder
kinder)
MINUS
MINUS
(SELECT
(SELECT elel
FROM
);
FROM eltern
eltern);
eltern
∪
kinder
π
π
kinder
Welche Strategien zur Bestimmung der
Semantik von kinderlos sind denkbar?
Welche führen zum erwarteten Resultat?
© 2011 Prof. Dr. R. Manthey
Intelligente DB
13
Differenzsichten:
ngend erforderlich!
Differenzsichten:Materialisierung
Materialisierungdes
desrechten
rechtenTeilbaums
Teilbaumsist
istzwi
zwingend
erforderlich! 1
William
Savannah
kinderlos
Charles
Anne
William
Peter
Savannah
π
2.
–
Charles
Anne
Peter
1.
eltern
Materialisierung
∪
kinder
π
π
kinder
CREATE
) AS
kinderlos(person
CREATEVIEW
VIEWkinderlos(person)
kinderlos(person)
AS
(SELECT
kind
(SELECT kind
FROM
)
kinder
FROM kinder)
kinder)
MINUS
MINUS
(SELECT
(SELECT elel
FROM
);
eltern
FROM eltern);
eltern);
CREATE
, kind)
) AS
eltern(el
kind
CREATEVIEW
VIEWeltern(el,
eltern(el,
kind)
AS
(SELECT
vater,
,
kind
vater
(SELECT vater, kind
FROM
)
kinder
FROM kinder)
kinder)
UNION
UNION
(SELECT
, kind
mutter
(SELECT mutter,
mutter,
kind
FROM
kinder);
);
kinder
FROM kinder);
Der MINUS-Operator darf erst dann Antworten produzieren, wenn die eltern-Sicht
eltern
vollständig berechnet worden ist! Diese „Wartepflicht“ gibt es nur bei MINUS!
© 2011 Prof. Dr. R. Manthey
Intelligente DB
14
Stratifikation
Stratifikation
1
CREATE
) AS
kinderlos(person
CREATEVIEW
VIEWkinderlos(person)
kinderlos(person)
AS
(SELECT
kind
(SELECT kind
FROM
)
kinder
FROM kinder)
kinder)
MINUS
MINUS
(SELECT
(SELECT elel
FROM
);
eltern
FROM eltern);
eltern);
2
kinderlos
MINUS
eltern
kinder
1
CREATE
, kind)
) AS
eltern(el
kind
CREATEVIEW
VIEWeltern(el,
eltern(el,
kind)
AS
(SELECT
vater,
,
kind
vater
(SELECT vater, kind
FROM
)
kinder
FROM kinder)
kinder)
UNION
UNION
(SELECT
, kind
mutter
(SELECT mutter,
mutter,
kind
FROM
kinder);
);
kinder
FROM kinder);
0
Schichteneinteilung (Stratifikation)
im Abhängigkeitsgraphen
(lat.
lat. stratum = dt. Schicht, lat.
lat. facere = dt. machen)
© 2011 Prof. Dr. R. Manthey
Intelligente DB
15
MINUS
getarnt“
MINUS„„getarnt“
1
CREATE
) AS
CREATEVIEW
VIEWkinderlos(person
kinderlos(person)
AS
(SELECT
kind
(SELECT kind
FROM
FROM kinder
kinderAS
ASkk
WHERE
WHERE
NOT
NOTEXISTS
EXISTS
(SELECT
(SELECT elel
FROM
FROM eltern
elternAS
ASee
WHERE
);
WHERE k.kind
k.kind==e.el
e.el);
kinderlos
π
π
eltern
SemiSemi-Join
∪
R
kinder
–
(R
S)
π
π
kinder
© 2011 Prof. Dr. R. Manthey
S = R
Auch andere Konstrukte in SQL bieten analoge
Probleme – NOT EXISTS und NOT IN sind aber
letztlich in der RA durch Anti-Joins dargestellt,
die wiederum abgeleitete Operationen sind, in
denen das („versteckte“) MINUS wesentlich ist.
Intelligente DB
16
Rekursive
RekursiveSichten
Sichtenseit
seitSQL:1999
SQL:1999
1
• Rekursive Sichten werden im Prinzip ganz analog definiert wie nicht-rekursive Sichten,
müssen aber durch das Schlüsselwort RECURSIVE kenntlich gemacht werden.
CREATE
CREATE RECURSIVE
RECURSIVE VIEW
VIEW pp AS
AS
((SELECT
SELECT q.A
q.A
FROM
FROM q,q,pp
WHERE
WHERE q.B
q.B==p.A)
p.A)
UNION
UNION
((SELECT
SELECT s.A
s.A
FROM
FROM ss
WHERE
WHERE s.A
s.A>>0)0)
rekursiver Fall
nicht-rekursiver Fall
(Basis der Rekursion)
• Es gibt diverse Einschränkungen für zulässige Sichtdefinitionen, die zum großen Teil
durch SQL-spezifische „Problem“ wie Duplikate, Nullwerte oder Syntaxvarianten hervorgerufen werden. Manche der Einschränkungen (z.B. Stratifizierbarkeit, Linearität,
Monotonie) gehen aber auf prinzipielle Probleme mit Rekursion zurück (mehr dazu später).
• Zudem kennt SQL noch diverse Steuerungsoptionen für rekursive Sichten („search and
cycle clause“), auf die aber in dieser Vorlesung nicht näher eingegangen werden wird.
© 2011 Prof. Dr. R. Manthey
Intelligente DB
17
Rekursive
RekursiveNachkommendefinition
NachkommendefinitionininSQL
SQL
CREATE
(vor, nach)
CREATERECURSIVE
RECURSIVEVIEW
VIEWnachkommen
nachkommen(vor,
nach)AS
AS
(SELECT
(SELECT **
FROM
)
FROM eltern
eltern)
UNION
UNION
(SELECT
(SELECT e.el,
e.el,n.nach
n.nach
FROM
FROM eltern
elternAS
ASee JOIN
JOIN nachkommen
nachkommenAS
ASnn
ON
ON e.kind
e.kind==n.vor)
n.vor)
1
nachkommen
eltern
CREATE
, kind
) AS
CREATEVIEW
VIEWeltern(el
eltern(el,
kind)
AS
(SELECT
vater
,
kind
(SELECT vater, kind
FROM
)
FROM kinder
kinder)
UNION
UNION
(SELECT
, kind
(SELECT mutter
mutter,
kind
FROM
kinder
);
FROM kinder);
© 2011 Prof. Dr. R. Manthey
Intelligente DB
kinder
18
Rekursiv
Rekursivbestimmte
bestimmteNachkommenschaft
Nachkommenschaftim
imBeispiel
Beispiel
eltern
1
nachkommen
kind
vor
nach
Charles
Philipp
Charles
Philipp
Anne
Philipp
Anne
Charles
William
Charles
William
Mark
Peter
Mark
Peter
Peter
Savannah
Peter
Savannah
Elizabeth
Charles
Elizabeth
Charles
Elizabeth
Anne
Elizabeth
Anne
Diana
William
Diana
William
Anne
Peter
Anne
Peter
Autumn
Savannah
Autumn
Savannah
el
Philipp
CREATE
(vor, nach)
nachkommen
CREATERECURSIVE
RECURSIVEVIEW
VIEWnachkommen(vor,
nachkommen(vor,
nach)AS
AS
(SELECT
*
(SELECT *
FROM
)
eltern
FROM eltern)
eltern)
UNION
UNION
(SELECT
(SELECT e.el,
e.el,n.nach
n.nach
FROM
eltern
FROM elternAS
ASee JOIN
JOINnachkommen
nachkommenAS
ASnn
ON
ONe.kind
e.kind==n.vor)
n.vor)
© 2011 Prof. Dr. R. Manthey
Intelligente DB
vor
nach
Philipp
William
Philipp
Peter
Mark
Savannah
Elizabeth
William
Elizabeth
Peter
Anne
Savannah
vor
nach
Philipp
Savannah
Elizabeth
Savannah
Intuitiv ist eigentlich klar,
was gemeint ist und damit,
was die Sicht „bedeutet“!
19
Versagen
Versagendes
desExpandierungsprinzips
Expandierungsprinzipsbei
beiRekursion
Rekursion
1
CREATE
(vor, nach)
nachkommen
CREATERECURSIVE
RECURSIVEVIEW
VIEWnachkommen(vor,
nachkommen(vor,
nach)AS
AS
(SELECT
*
(SELECT *
FROM
)
eltern
FROM eltern)
eltern)
UNION
UNION
(SELECT
(SELECT e.el,
e.el,n.nach
n.nach
FROM
eltern
FROM elternAS
ASee JOIN
JOINnachkommen
nachkommenAS
ASnn
ON
ONe.kind
e.kind==n.vor)
n.vor)
CREATE
, kind)
) AS
eltern(el
kind
CREATEVIEW
VIEWeltern(el,
eltern(el,
kind)
AS
(SELECT
vater,
,
kind
vater
(SELECT vater, kind
FROM
)
kinder
FROM kinder)
kinder)
UNION
UNION
(SELECT
, kind
mutter
(SELECTmutter,
mutter,
kind
FROM
kinder);
);
kinder
FROM
kinder);
Bei rekursiven Sichten versagt das
Expandierungsprinzip, da unbekannt
ist, wie oft expandiert werden muss!
CREATE RECURSIVE VIEW nachkommen(vor,
(vor, nach) AS
CREATE RECURSIVE VIEWnachkommen
nachkommen(vor, nach) AS
(SELECT
*
(SELECT *
FROM
eltern))
FROM eltern
eltern)
UNION
UNION
(SELECT e.el, n.nach
(SELECT
e.el,
n.nach
CREATE
RECURSIVE
VIEW
nachkommen(vor, nach) AS
FROM
eltern
AS nachkommen(vor,
enachkommen(vor,
JOIN nachkommen
AS n
CREATE
RECURSIVE
VIEW
nach) AS
FROM
eltern
(SELECT
*AS e JOIN nachkommen AS n
(SELECT *
ON
e.kind
=
n.vor)
FROM
eltern)
eltern)
ON e.kind = n.vor)
FROM
eltern)
UNION
UNION
CREATE RECURSIVE VIEW nachkommen(vor,
nachkommen(vor, nach) AS
(SELECT e.el,
n.nach
CREATE RECURSIVE
VIEW
nachkommen(vor, nach) AS
(SELECT
e.el,* n.nach
(SELECT
FROM
elterneltern)
(SELECT
*AS e JOIN nachkommen AS n
FROM
) e JOIN nachkommen AS n
eltern
FROM
eltern
AS
FROM
eltern)
ON e.kind = n.vor)
UNION
ON e.kind = n.vor)
UNION
(SELECT e.el, n.nach
(SELECT e.el, n.nach
FROM
eltern AS e JOIN nachkommen AS n
FROM
eltern AS e JOIN nachkommen AS n
ON e.kind = n.vor)
ON e.kind = n.vor)
...
(Das hängt vom aktuellen Zustand ab.)
© 2011 Prof. Dr. R. Manthey
Intelligente DB
20
Rekursive
echt zyklischer
“ RA
-Operatorgraph
RekursiveSicht
Sichtals
als„„echt
zyklischer“
RA-Operatorgraph
CREATE
(vor, nach)
nachkommen
CREATERECURSIVE
RECURSIVEVIEW
VIEWnachkommen(vor,
nachkommen(vor,
nach)AS
AS
(SELECT
(SELECT **
FROM
)
eltern
FROM eltern)
eltern)
UNION
UNION
(SELECT
(SELECTe.el,
e.el,n.nach
n.nach
FROM
eltern
AS
FROM eltern ASe eJOIN
JOINnachkommen
nachkommenAS
ASnn
ON
ON e.kind
e.kind==n.vor)
n.vor)
nachkommen
∪
π
π
eltern
1
Stattdessen ist eine dynamisch kontrollierte
Bestimmung der rekursiv herleitbaren
Fakten erforderlich, die sich durch Zulassen
von „Feedback-Zyklen“ in Operatorgraphen
aus RA-Ebene ausdrücken lassen.
∪
π
π
kinder
© 2011 Prof. Dr. R. Manthey
CREATE
) AS
kind
CREATEVIEW
VIEWeltern(el
eltern(elkind)
kind)
AS
(SELECT vater,
, kind
vater
(SELECT vater, kind
FROM
)
kinder
FROM kinder)
kinder)
UNION
UNION
(SELECT mutter,
, kind
(SELECT mutter
mutter, kind
FROM
kinder);
);
FROM kinder
kinder);
Intelligente DB
21
Schon
Vorwegdenken“: Was
Schonmal
malzum
zum„„Vorwegdenken“:
Waskann
kannman
mandenn
denndamit
damitanfangen?
anfangen?
1
CREATE
CREATE RECURSIVE
RECURSIVEVIEW
VIEWppAS
AS
(SELECT
*
(SELECT *
FROM
FROM s)s)
∪
UNION
UNION
p1
((SELECT
((SELECT aa
FROM
FROM q)q)
MINUS
MINUS
(SELECT
(SELECT aa
FROM
FROM qq JOIN
JOIN pp
ON
))
p.a
ON q.b
q.b==p.a))
p.a))
q:
s:
5
7
© 2011 Prof. Dr. R. Manthey
a
1
2
3
p2
s
–
p3
π
π
b
2
3
4
q
Intelligente DB
22