1 Datenbanken und DATALOG

Deduktive Datenbanken
1
Sommersemester 2012
Datenbanken und DATALOG
Dieser Abschnitt gibt zunächst eine kurze Einführung zu einigen Grundlagen
relationaler Datenbanken.
Danach werden die zwei Gesichter der Logikprogrammierung vorgestellt:
2 Bei der deduktiven Datenbanksprache DATALOG steht der deklarative
Aspekt im Vordergrund. Hier wird eine Datenbank über
Verwandtschaftsbeziehungen betrachtet.
2 Bei der Programmiersprache P ROLOG (Kapitel 2) steht der prozedurale
Aspekt im Vordergrund. Neben einigen elementaren, kleinen
P ROLOG–Beispielen werden als größere Programmierbeispiele binäre
Suchbäume, Stücklisten und Firmenbeteiligungen behandelt.
Prof. Dr. Dietmar Seipel
41
Deduktive Datenbanken
1.1
Sommersemester 2012
Grundbegriffe des relationalen Datenmodells
1.1.1 Relationen und Relationenschemata
2 Attribute: A1 , . . . , An , Domänen: D1 , . . . , Dn
2 Relation: R, mit R ⊆ D1 × . . . × Dn
2 Stelligkeit: n, Kardinalität: |R| (Spalten–, Zeilenanzahl)
2 Tupel: h d1 , . . . , dn i ∈ R
2 Relationenschema: RS = h V, K, Not_Null i, mit
– Attributmenge V = { A1 , . . . , An },
– Primärschlüssel K ⊆ V,
– Menge Not_Null von Attributen, die bekannt sein müssen.
Prof. Dr. Dietmar Seipel
42
Deduktive Datenbanken
Sommersemester 2012
Beispiel (C OMPANY–Datenbank)
Relationenschemata:
E MPLOYEE
= h { L NAME, S SN, B DATE, S EX, S ALARY, S UPERSSN, D NO },
{ S SN }, { S SN, E NAME } i
D EPARTMENT = h { D NAME, D NUMBER, M GRSSN, M GRSTARTDATE },
{ D NUMBER }, { D NUMBER, D NAME } i
W ORKS _O N
= h { E SSN, P NO, H OURS },
{ E SSN, P NO }, { E SSN, P NO } i
P ROJECT
= h { P NAME, P NUMBER, P LOCATION, D NUM },
{ P NUMBER }, { P NUMBER, P NAME } i
Es folgen Relationen dazu.
Prof. Dr. Dietmar Seipel
43
Deduktive Datenbanken
Sommersemester 2012
E MPLOYEE
L NAME
S SN
B DATE
S EX
S ALARY
S UPERSSN
D NO
Smith
1111
1955–01–09
M
30000
3333
5
Wong
3333
1945–12–08
M
40000
5555
5
Zelaya
2222
1958–07–19
F
25000
7777
4
Wallace
7777
1931–06–20
F
43000
5555
4
Narayan
6666
1952–09–15
M
38000
3333
5
English
4444
1962–07–31
F
25000
3333
5
Jabbar
8888
1959–03–29
M
25000
7777
4
Borg
5555
1927–11–10
M
55000
NULL
1
D EPARTMENT
Prof. Dr. Dietmar Seipel
D NAME
D NUMBER
M GRSSN
M GRSTARTDATE
Research
5
3333
1978–05–22
Administration
4
7777
1985–01–01
Headquarters
1
5555
1971–06–19
44
Deduktive Datenbanken
Sommersemester 2012
W ORKS _O N
E SSN
P NO
H OURS
1111
1
32.5
4444
1
20.0
1111
2
7.5
3333
2
10.0
6666
2
20.0
2222
10
10.0
8888
10
35.5
5555
20
NULL
7777
30
20.0
8888
30
15.0
Prof. Dr. Dietmar Seipel
P ROJECT
P NAME
P NUMBER
P LOCATION
D NUM
Product X
1
Bellaire
5
Product Y
2
Sugarland
5
Computerization
10
Stafford
4
Reorganization
20
Houston
1
New Benefits
30
Stafford
4
45
Deduktive Datenbanken
Sommersemester 2012
Data Dictionary in X ML:
Mithilfe der P ROLOG–Bibliothek D DK können wir das Data Dictionary einer
relationalen Datenbank (z.B. MySQL) in eine X ML–Repräsentation
transformieren:
<database name="company">
<table name="department"> ... </table>
<table name="employee"> ... </table>
<table name="dependent"> ... </table>
<table name="dept_locations"> ... </table>
<table name="project"> ... </table>
<table name="works_on"> ... </table>
</database>
Prof. Dr. Dietmar Seipel
46
Deduktive Datenbanken
Sommersemester 2012
<table name="employee">
<attribute name="LNAME" type="varchar(15)" is_nullable="NO"/>
<attribute name="SSN" type="varchar(9)" is_nullable="NO"/>
<attribute name="BDATE" type="date" is_nullable="YES"/>
<attribute name="SEX" type="char(1)" is_nullable="YES"/>
<attribute name="SALARY" type="decimal(10,2)" is_nullable="YES"/>
<attribute name="SUPERSSN" type="varchar(9)" is_nullable="YES"/>
<attribute name="DNO" type="int(11)" is_nullable="NO"/>
<primary_key> <attribute name="SSN"/> </primary_key>
<foreign_key> <attribute name="SUPERSSN"/>
<references table="employee">
<attribute name="SSN"/> </references> </foreign_key>
<foreign_key> <attribute name="DNO"/>
<references table="department"> <attribute name="DNUMBER"/>
</references> </foreign_key>
</table>
Prof. Dr. Dietmar Seipel
47
Deduktive Datenbanken
Sommersemester 2012
1.1.2 Relationale Anfragesprachen
Eine Anfrage (Query) spezifiziert Daten, welche aus der Datenbank abgeleitet
werden sollen.
2 Relationenalgebra:
interne Repräsentation von Anfragen
mengen–orientiert
2 Relationenkalkül:
Anfragen als Formeln der Prädikatenlogik erster Stufe (PL1)
tupel–orientiert, deklarativ (nicht prozedural)
Grundlage der relationalen Anfragesprache SQL
weitere Anfragesprachen: QUEL, QBE, DATALOG
Prof. Dr. Dietmar Seipel
48
Deduktive Datenbanken
Sommersemester 2012
Die Relationenalgebra
Positive Relationenalgebra RA+ :
2 Selektion σF (R),
2 Projektion ΠAi1 ,...,Aik (R), 1 ≤ i1 , . . . , ik ≤ n
2 kartesisches Produkt R × S
2 Vereinigung R ∪ S
die Erweiterung der positiven Relationenalgebra RA+ um
2 Differenz R \ S
ist relational vollständig, d.h. gleichmächtig wie das Relationenkalkül
Prof. Dr. Dietmar Seipel
49
Deduktive Datenbanken
Sommersemester 2012
Beispiel (RA)
Basisrelationen
R
Prof. Dr. Dietmar Seipel
A1
A2
A3
a
b
c
a
b
d
b
c
d
S
T
B1
B2
B1
B2
a
b
b
c
b
c
c
d
50
Deduktive Datenbanken
Sommersemester 2012
Grundlegende Operationen
σA1 =a (R)
S∪T
A2
A3
B1
B2
a
b
c
a
b
A1
A2
A3
B1
B2
a
b
d
b
c
a
b
c
a
b
c
d
a
b
c
b
c
a
b
d
a
b
a
b
d
b
c
b
c
d
a
b
b
c
d
b
c
Selektion
Vereinigung
ΠA1 ,A2 R
A1
A2
a
b
B1
B2
b
c
a
b
Projektion
Prof. Dr. Dietmar Seipel
R×S
A1
S\T
Kartesisches Produkt
Differenz
51
Deduktive Datenbanken
Sommersemester 2012
Joins
2 Join R ⊲⊳F S = σF (R × S) ⊆ R × S
F : Joinbedingung
2 natürlicher Join UR = { A1 , A2 }, US = { A2 , A3 }
R ⊲⊳ S = ΠA1 ,A2 ,A3 (σR.A2 =S.A2 (R × S))
2 Komposition binärer Relationen mit US = UT = { B1 , B2 }
S ◦ T = ΠS.B1 ,T.B2 (S ⊲⊳S.B2 =T.B1 T )
In der Prädikatenlogik: st(X , Y ) ← s(X, Z) ∧ t(Z, Y )
2 Semijoin R ⋉F S = ΠUR (R ⊲⊳F S)
2 natürlicher Semijoin R ⋉ S = ΠUR (R ⊲⊳ S)
Prof. Dr. Dietmar Seipel
52
Deduktive Datenbanken
Sommersemester 2012
Beispiel (RA)
Abgeleitete Operationen
R ⊲⊳A2 =B2 S
R ⋉A1 =B1 T
A1
A2
A3
B1
B2
a
b
c
a
b
A1
a
b
d
a
b
b
b
c
d
b
c
Join
Prof. Dr. Dietmar Seipel
A2
A3
c
Semijoin
d
S◦T
B1
B2
a
c
b
d
Komposition
53
Deduktive Datenbanken
Sommersemester 2012
Die Anfragesprache S QL
S QL–Anfrage (eventuell geschachtelt):
S ELECT
h attribute list i
F ROM
h relations i
W HERE
{ h predicate i | h attribute list i I N h query block i }
2 Das S ELECT–Statement stellt eine Projektion auf die h attribute list i dar.
2 Mit dem F ROM– und dem W HERE–Statement kann man Joins bilden,
wobei F ROM dazu dient, das kartesische Produkt zu bilden, und mit der
W HERE–Anweisung Selektionen durchgeführt werden können.
Prof. Dr. Dietmar Seipel
54
Deduktive Datenbanken
Sommersemester 2012
Beispiel (S QL)
Die folgende S QL–Anfrage liefert alle Angestellten der Abteilung 5,
die mindestens 30.000 Dollar verdienen:
S ELECT L NAME
F ROM E MPLOYEE
W HERE S ALARY >= 30000
A ND D NO = 5
Sie entspricht dem folgenden Ausdruck der relationalen Algebra:
ΠL NAME (σS ALARY ≥ 30000 ∧ D NO = 5 (E MPLOYEE ))
In der Prädikatenlogik:
select(Lname) ← employee(Lname, _, _, _, S , _, 5 ) ∧ S ≥ 30000
Prof. Dr. Dietmar Seipel
55
Deduktive Datenbanken
Sommersemester 2012
Das folgende S ELECT–F ROM –W HERE–Statement findet für alle Projekte die
Summe der geleisteten Arbeitsstunden (Aggregation):
S ELECT P NAME , SUM (H OURS )
F ROM P ROJECT, W ORKS _O N
W HERE P ROJECT.P NUMBER = W ORKS _O N .P N O
G ROUP B Y P NAME
View:
Relation, die nicht explizit in der Datenbank gespeichert sondern mittels
eines Ausdruckes aus der Anfragesprache definiert ist.
Dieser Ausdruck kann sich auf Datenbankrelationen und/oder auch wieder
auf Views stützen.
Die transitive Hülle einer binären Relation (eines Graphen) kann in
Standard–S QL leider nicht berechnet werden – wohl aber in DATALOG.
Prof. Dr. Dietmar Seipel
56
Deduktive Datenbanken
Sommersemester 2012
G:
Graphentheoretische Grundlagen
2 Ein Graph G = (N, E) ist gegeben durch:
– Knoten N = { a, . . . , g },
a f -g
6R
c
b
R
e
d
– Kanten E = { (a, b), (a, c), (c, d), (c, e), (d, a), (f, g) }.
2 Die transitive Hülle G + = (N, E + ) enthält eine Kante (v, w), falls w von v
aus über einen gerichteten Weg positiver Länge erreichbar ist:
– Kanten E + = E ∪ { (a, e), (a, a), (c, c), (d, d) }.
– a, c und d liegen auf einem Kreis. Deswegen sind diese Knoten von sich
selbst aus über einen gerichteten Weg positiver Länge erreichbar.
2 Die reflexive, transitive Hülle G ∗ = (N, E ∗ ) enthält eine Kante (v, w), falls
w von v aus über einen gerichteten Weg beliebiger Länge erreichbar ist:
– Kanten E ∗ = E + ∪ { (b, b), (e, e), (f, f ), (g, g) }.
– Für alle Knoten v gilt (v, v) ∈ E ∗ .
Prof. Dr. Dietmar Seipel
57
Deduktive Datenbanken
1.2
Sommersemester 2012
Die deduktive Datenbanksprache DATALOG
In DATALOGfun werden – wie in der Logik – Terme und Atome aus Konstanten,
Variablen und Funktionssymbolen bzw. Prädikatensymbolen gebildet.
Konstanten beginnen mit einem Kleinbuchstaben, sind in Hochkommatas
eingeschlossen oder Zahlen:
z.B. book, ’Book’, 0, 123.
Variablen sind Zeichenketten, die mit einem Großbuchstaben oder dem
Unterstrich “_” beginnen:
z.B. X, Y, Book, _, _A, _a.
Die Unterscheidung zwischen Konstanten und Variablen erfolgt also auf
syntaktischer Ebene, ohne daß man dies explizit deklarieren muß.
Prof. Dr. Dietmar Seipel
58
Deduktive Datenbanken
Sommersemester 2012
Man unterscheidet Zahlen (wie 23 ) von Zeichenketten (wie ’23’ ).
Bei Zahlen sind führende Nullen bedeutungslos (es gilt 023 = 23 ),
bei Zeichenketten haben sie eine Bedeutung (hier gilt ’023’ 6= ’23’ ).
Prädikatensymbole und Funktionssymbole sind Funktoren.
Funktoren sind Zeichenketten, die mit einem Kleinbuchstaben beginnen oder
in Hochkommatas eingeschlossen sind, oder Folgen von Sonderzeichen:
z.B. ancestor, ’Parent’, true, ->.
Daraus kann man dann in DATALOG bzw. DATALOGfun Terme, Atome und
Formeln bilden. Diese in der Logik gebräuchliche Unterscheidung wird in
P ROLOG aufgehoben; man spricht hier allgemeiner von Strukturen.
Prof. Dr. Dietmar Seipel
59
Deduktive Datenbanken
Sommersemester 2012
Terme:
2 Variablen und Konstanten sind Terme.
2 Falls t1 , . . . , tn Terme sind und f ein Funktionssymbol, dann ist auch
f (t1 , . . . , tn ) ein Term.
Man nennt n die Stelligkeit eines Terms f (t1 , . . . , tn ).
Ein 0–stelliger Term f () wird (abgekürzt) als f notiert und als Konstante
betrachtet.
Dann sind “+(X, 123)” und “log(3)” Terme.
Anstelle der Präfix–Notation kann man oft auch die Infix–Notation
schreiben: “X + 123”.
In DATALOG sind dagegen keine Funktionssymbole erlaubt, d.h. Terme sind
entweder Konstanten oder Variablen.
Prof. Dr. Dietmar Seipel
60
Deduktive Datenbanken
Sommersemester 2012
Atome werden nun entsprechend aus Termen und Prädikatensymbolen
gebildet:
2 Ein Prädikatensymbol p hat dabei eine Stelligkeit n.
2 Falls t1 , . . . , tn Terme sind, dann ist p(t1 , . . . , tn ) ein Atom.
Z.B. ancestor(charles, george).
2 Falls das Prädikatensymbol p die Stelligekit n = 0 hat, so schreiben wir
kurz p anstelle von p(): z.B. true.
Atome können – anders als Terme – nicht ineinander verschachtelt sein.
Formeln:
2 Atome sind in DATALOG Fakten.
2 Komplexere Formeln (Regeln) können aus den Atomen mit Hilfe der
Junktoren “←” und “∧” (und) gebildet werden.
2 In DATALOGnot ist zusätzlich “not” (Default Negation) erlaubt.
Prof. Dr. Dietmar Seipel
61
Deduktive Datenbanken
Sommersemester 2012
Überladung:
Ein Symbol kann sowohl als Funktionssymbol als auch als Prädikatensymbol
auftreten; außerdem kann es mit unterschiedlichen Stelligkeiten auftreten.
2 Im Atom parent(mother(anne), goerge) wird mother als einstelliges
Funktionssymbol betrachtet und mother(anne) als Term.
Die Bedeutung des Atoms könnte sein, daß goerge ein Elternteil der Mutter
von anne ist.
2 Steht mother(anne) alleine, so wird es als Atom betrachtet, und mother als
Prädikatensymbol. Die Bedeutung könnte dann sein, daß anne eine Mutter
ist.
2 Theoretisch ist sogar ein Atom mother(mother(mother)) möglich, in dem
mother – je nach Position – ein Prädikaten–, Funktions–, bzw.
Konstantensymbol ist.
Prof. Dr. Dietmar Seipel
62
Deduktive Datenbanken
Sommersemester 2012
Domain Specific Language (DSL):
Mithilfe von Infix–Funktoren, die man in P ROLOG definieren kann, kann man
sich auf einfache Weise eine leichter zu lesende DSL schaffen, ohne dafür einen
eigenen Parser schreiben zu müssen.
Wenn man z.B. likes als zweistelligen Infix–Funktor in P ROLOG definiert,
dann kann man fast wie in natürlicher Sprache
’John’ likes ’Mary’
anstelle von likes(’John’, ’Mary’) schreiben.
Prof. Dr. Dietmar Seipel
63
Deduktive Datenbanken
Sommersemester 2012
1.2.1 Regeln und Fakten
Prädikatensymbole: parent, grandparent, ancestor , alle 2–stellig
Regeln: Kopf ← Rumpf , man sagt “ Kopf falls Rumpf ”
Rumpf ist Konjunktion von Atomen oder deren Negation
grandparent(X , Z ) ← parent(X , Y ) ∧ parent(Y , Z )
ancestor (X , Y ) ← parent(X , Y )
ancestor (X , Z ) ← ancestor (X , Y ) ∧ parent(Y , Z )
Bedeutung:
∀X ∀Y ∀Z ((ancestor(X, Y ) ∧ parent(Y, Z)) → ancestor(X, Z))
Fakten:
parent(’Elizabeth’, ’George’)
parent(’Charles’, ’Elizabeth’)
parent(’William’, ’Charles’)
Prof. Dr. Dietmar Seipel
64
Deduktive Datenbanken
Sommersemester 2012
Familienstammbaum
-
Charles
Diana
George
- Elizabeth
Philip
-
- William
-
Harry
Anne
- Andrew
-
Edward
Der Familienstammbaum umfaßt 4 Generationen; Frauen sind in Rot, Männer in
Blau angezeigt.
Prof. Dr. Dietmar Seipel
65
Deduktive Datenbanken
Sommersemester 2012
Ableitung: Bottom–Up, Forward Chaining
In DATALOG (ohne Negation) werden Regeln bottom–up ausgewertet:
aus den bekannten Fakten für die Rumpfatome einer Regel werden neue Fakten
für das Kopfatom der Regel abgeleitet (Forward Chaining).
2 Man ersetzt die Variablen in einer Regel durch geeignete Konstanten.
2 Falls die Rumpfatome B1 , . . . , Bn der so erhaltenen Regel
A ← B1 ∧ . . . ∧ Bn
bereits bekannt sind, dann kann man das Kopfatom A ableiten.
In der Praxis findet man die geeigneten Konstanten indem man der Reihe nach
passende, bereits bekannte Atome Bi (1 ≤ i ≤ n) für den Regelrumpf sucht.
Prof. Dr. Dietmar Seipel
66
Deduktive Datenbanken
Sommersemester 2012
Z
Man kann mittels der Regel
grandparent(X , Z ) ← parent(X , Y ) ∧ parent(Y , Z )
z.B. folgende neuen Fakten ableiten.
I
parent 6
Y grandparent
parent 6
X
Dazu ersetzt man die Variablen der Regel wie folgt:
2 Für { X 7→ ’Charles’, Y 7→ ’Elizabeth’, Z 7→ ’George’ } erhalten wir
grandparent(’Charles’, ’George’) ←
parent(’Charles’, ’Elizabeth’) ∧ parent(’Elizabeth’, ’George’).
Mit Hilfe der entsprechenden Fakten aus dem Regelrumpf kann man dann
grandparent(’Charles’, ’George’) ableiten.
2 Für { X 7→ ’William’, Y 7→ ’Charles’, Z 7→ ’Elizabeth’ } kann man
grandparent(’William’, ’Elizabeth’) ableiten.
Prof. Dr. Dietmar Seipel
67
Deduktive Datenbanken
Sommersemester 2012
Die Menge aller Fakten zu einem n–stelligen Prädikat entspricht einer
n–stelligen Relation.
Falls parent als zweispaltige Relation PARENT realisiert wäre, so könnte man die
Relation G RANDPARENT zu grandparent wie folgt in S QL berechnen:
C REATE V IEW G RANDPARENT (NAME , G RANDPARENT ) A S
S ELECT P1.NAME , P2.PARENT
F ROM PARENT P1, PARENT P2
W HERE P1.PARENT = P2.NAME
PARENT
NAME
PARENT
Elizabeth
George
Charles
Elizabeth
William
Charles
Prof. Dr. Dietmar Seipel
G RANDPARENT
NAME
G RANDPARENT
Charles
George
William
Elizabeth
68
Deduktive Datenbanken
Sommersemester 2012
Nested–Loop–Join in S QL:
2 Die äußere Schleife durchläuft alle Tupel P1 von PARENT (unten links).
2 Die innere Schleife testet für jedes solche Tupel wiederum alle Tupel P2 von
PARENT (unten rechts) auf die Bedingung P1.PARENT = P2.NAME.
PARENT
PARENT
NAME
PARENT
NAME
PARENT
Elizabeth
Queen Mum
Elizabeth
Queen Mum
Elizabeth
George
Elizabeth
George
Charles
Elizabeth
Charles
Elizabeth
William
Charles
William
Charles
Falls es einen Index über NAME gibt, so können sehr schnell die (jeweils
maximal zwei) passenden Tupel für P2 gefunden werden.
Prof. Dr. Dietmar Seipel
69
Deduktive Datenbanken
Sommersemester 2012
Transformiert man ein S ELECT–Statement nach DATALOG so ergibt sich
folgendes:
2 der S ELECT–Teil entspricht dem Regelkopf,
2 der F ROM–Teil entspricht den Prädikaten im Regelrumpf,
2 Gleicheitsbedingungen aus dem W HERE–Teil können direkt durch gleiche
DATALOG–Variablen ausgedrückt oder wie alle weiteren arithmetischen
Bedingungen in den Regelrumpf übernommen werden.
In DATALOG erfolgt die Selektion nicht über Attribute, sondern über die
Argumentposition.
Die Relation A NCESTOR kann man in S QL im allgemeinen nicht berechnen, da
man nicht weis wieviele Stufen die zugrunde liegende Relation PARENT hat.
Prof. Dr. Dietmar Seipel
70
Deduktive Datenbanken
Sommersemester 2012
Der S QL–View zur Berechnung der Relation A NCESTOR wäre rekursiv, da er
sich im zweiten S ELECT–Statement wieder auf A NCESTOR selbst bezieht:
C REATE V IEW A NCESTOR (NAME , A NCESTOR ) A S
S ELECT * F ROM PARENT
U NION
S ELECT A NCESTOR .NAME , PARENT.PARENT
F ROM PARENT, A NCESTOR
W HERE A NCESTOR .A NCESTOR = PARENT.NAME
Die den beiden Regeln für ancestor entsprechenden S ELECT–Statements werden
mittels U NION vereinigt.
Rekursive Views sind in Standard–S QL nicht erlaubt.
Es gibt allerdings S QL–Erweiterungen, in denen spezielle, einfache rekursive
Views wie der obige erlaubt sind.
Prof. Dr. Dietmar Seipel
71
Deduktive Datenbanken
Sommersemester 2012
In DATALOG werden die folgenden Fakten berechnet:
2 Zuerst berechnet die Regel ancestor (X , Y ) ← parent(X , Y ) die neuen
Fakten ancestor (’Elizabeth’, ’George’), ancestor (’Charles’, ’Elizabeth’),
und ancestor (’William’, ’Charles’).
George
2 Danach berechnet die Regel
ancestor (X , Z ) ← ancestor (X , Y ) ∧ parent(Y , Z )
aus diesen Fakten und den parent–Fakten die Fakten
1
6
Y
2 Elizabeth
1 I 3
6
Charles 2
1
6
William
ancestor (’Charles’, ’George’), ancestor (’William’, ’Elizabeth’),
2 und schließlich wiederum daraus ancestor (’William’, ’George’).
2 Falls es mehr als drei Stufen in PARENT gäbe, so würde diese Regel weiter
angewendet bis keine neuen Fakten mehr abgeleitet werden können.
Prof. Dr. Dietmar Seipel
72
Deduktive Datenbanken
Sommersemester 2012
Extensionale und intensionale Datenbank, Anfragen
2 EDB: relationale Datenbank
2 IDB: wird aus der EDB mit Hilfe von Regeln abgeleitet,
ist nicht explizit gespeichert (vgl. Views in relationalen Datenbanken)
2 Rekursive Regeln erlauben es, wichtige IDB–Relationen auszudrücken
(etwa A NCESTOR), die man sonst nicht so einfach ausdrücken könnte.
2 Regeln können in DATALOG effizient abgearbeitet werden;
ein P ROLOG–Interpreter würde viele Resultats–Tupel zu einer Query
mehrfach generieren und möglicherweise nicht terminieren.
2 Anfragen werden in Form von Regeln ohne Kopfatom, sogenannten Zielen
(Goals), repräsentiert.
Prof. Dr. Dietmar Seipel
73
Deduktive Datenbanken
Sommersemester 2012
Beispiel (Extensionale und intensionale Datenbbank, Anfragen)
EDB
P ERSON
NAME
B ORN
S EX
Anne
1950
female
Andrew
1960
male
Charles
1948
male
Diana
1961
female
Edward
1964
male
Elizabeth
1926
female
Harry
1984
male
Philip
1921
male
William
1982
male
Prof. Dr. Dietmar Seipel
PARENTS
NAME
M OTHER
FATHER
Anne
Elizabeth
Philip
Andrew
Elizabeth
Philip
Charles
Elizabeth
Philip
Edward
Elizabeth
Philip
Harry
Diana
Charles
William
Diana
Charles
74
Deduktive Datenbanken
Sommersemester 2012
in DATALOG erhält man ein Fakt pro Tupel der Datenbank:
person(’Anne’, 1950, female).
person(’Andrew’, 1960, male).
person(’Charles’, 1948, male).
person(’Diana’, 1961, female).
person(’Edward’, 1964, male).
person(’Elizabeth’, 1926, female).
person(’Harry’, 1984, male).
person(’Philip’, 1921, male).
person(’William’, 1982, male).
parents(’Anne’, ’Elizabeth’, ’Philip’).
parents(’Andrew’, ’Elizabeth’, ’Philip’).
parents(’Charles’, ’Elizabeth’, ’Philip’).
parents(’Edward’, ’Elizabeth’, ’Philip’).
parents(’Harry’, ’Diana’, ’Charles’).
parents(’William’, ’Diana’, ’Charles’).
Prof. Dr. Dietmar Seipel
75
Deduktive Datenbanken
Sommersemester 2012
Mit den folgenden Regeln können die bisherigen Tabellen als IDB–Tabellen
daraus hergeleitet werden:
mother (X , Y ) ← parents(X , Y , _)
father (X , Y ) ← parents(X , _, Y )
parent(X , Y ) ← mother (X , Y )
parent(X , Y ) ← father (X , Y )
Die Mutter Y einer Person X steht an der zweiten Position, der Vater an der
dritten Position in den parents–Fakten.
In den Regeln für mother und father ist die jeweils andere Position der
parents–Fakten mit einer anonymen Variable “_” belegt.
Diese fungiert als Wildcard und drückt aus, daß der Wert an dieser Position für
die entsprechende Regel irrelevant ist. Wie üblich steht jedes Auftreten einer
anonymen Variable für einen separaten Wert.
Prof. Dr. Dietmar Seipel
76
Deduktive Datenbanken
Sommersemester 2012
Die weiteren IDB–Tabellen können daraus dann wie folgt hergeleitet werden:
grandparent(X , Z ) ← parent(X , Y ) ∧ parent(Y , Z )
sibling(X , Y ) ← parent(X , Z ) ∧ parent(Y , Z ) ∧ X 6= Y
ancestor (X , Y ) ← parent(X , Y )
ancestor (X , Y ) ← parent(X , Z ) ∧ ancestor (Z , Y )
Die vierte Regel ist rekursiv, da das Kopfprädikat ancestor /2 ebenfalls im
Regelrumpf aufgerufen wird.
Darauf aufbauend kann man Anfragen stellen. Die Auswertung der Anfrage
← grandparent(’William’, Z )
liefert für Z die Belegungen Z 7→ ’Elizabeth’ und Z 7→ ’Philip’.
Prof. Dr. Dietmar Seipel
77
Deduktive Datenbanken
Sommersemester 2012
A NCESTOR
Auszug der IDB
G RANDPARENT
NAME
A NCESTOR
Anne
Elizabeth
Anne
Philip
Andrew
Elizabeth
Andrew
Philip
Charles
Elizabeth
Charles
Philip
Edward
Elizabeth
Edward
Philip
Harry
Charles
NAME
G RANDPARENT
Harry
Elizabeth
Harry
Philip
Harry
Diana
William
Elizabeth
Harry
Elizabeth
Harry
Philip
William
Charles
William
Diana
William
Elizabeth
William
Philip
William
Prof. Dr. Dietmar Seipel
Philip
78
Deduktive Datenbanken
Sommersemester 2012
Weitere Regeln:
aunt
aunt(X , Y ) ← parent(X , Z ) ∧ sibling(Z , Y ) ∧
person(Y , _, female)
uncle(X , Y ) ← parent(X , Z ) ∧ sibling(Z , Y ) ∧
person(Y , _, male)
cousin(X , Y ) ← parent(X , U ) ∧ parent(Y , V ) ∧
sibling(U , V ) ∧ X 6= Y
cousin(X , Y ) ← parent(X , U ) ∧ parent(Y , V ) ∧
cousin(U , V ) ∧ X 6= Y
ancestor : Vorfahre
sibling: Geschwister (Bruder, Schwester)
uncle
?
?
+ U
parent
sibling
K
I
sU
person
6
R
cousin
Veranschaulichung: Rule/Goal–Graph
Prof. Dr. Dietmar Seipel
79
Deduktive Datenbanken
Sommersemester 2012
Beispiel (Transitive Vorgesetzte)
Auch die bekannte C OMPANY–Datenbank kann als extensionale Datenbank in
DATALOGfun repräsentiert werden:
employee(’Smith’, ’4444’, 1955–01–09, ’M’, 30000, ’2222’, 5)
employee(’Wong’, ’2222’, 1945–12–08, ’M’, 40000, ’1111’, 5)
employee(’Zelaya’, ’7777’, 1958–07–19, ’F’, 25000, ’3333’, 4)
employee(’Wallace’, ’3333’, 1931–06–20, ’F’, 43000, ’1111’, 4)
employee(’Narayan’, ’5555’, 1952–09–15, ’M’, 38000, ’2222’, 5)
employee(’English’, ’6666’, 1962–07–31, ’F’, 25000, ’2222’, 5)
employee(’Jabbar’, ’8888’, 1959–03–29, ’M’, 25000, ’3333’, 4)
employee(’Borg’, ’1111’, 1927–11–10, ’M’, 55000, ’$null$’, 1)
Es sollen nun Paare von Personennamen abgeleitet werden, so daß die erste
Person ein indirekter Vorgesetzter (superior) der zweiten Person ist.
Prof. Dr. Dietmar Seipel
80
Deduktive Datenbanken
Sommersemester 2012
Datentypen:
2 Die Namen, die Sozialversicherungsnummern und die Geschlechterangaben
zu den Personen sind Zeichenketten.
2 Der Lohn ist eine Zahl, damit man damit rechnen kann.
2 Die Abteilungsnummer kann man als Zahl oder als Zeichenkette
repräsentieren.
2 Ein Geburtsdatum wird als Term Year–Month–Day in Infix–Notation
repräsentiert. Dies entspricht dem S QL–Datumstyp und dient auch der
Lesbarkeit. Die drei Komponenten des verschachtelten Terms sind Zahlen.
Die Präfix–Notation zum Datum 1955–01–09 wäre z.B. – (– (1955, 01), 09).
Die führenden Nullen in den Zahlen sind bedeutungslos, sie verbessern aber
ebenfalls die Lesbarkeit.
Prof. Dr. Dietmar Seipel
81
Deduktive Datenbanken
Sommersemester 2012
Regeln zur Ableitung der intensionalen Datenbank:
superior _by_name(Name1 , Name2 ) ←
superior (SSN1 , SSN2 ) ∧
employee(Name1 , SSN1 , _, _, _, _, _) ∧
employee(Name2 , SSN2 , _, _, _, _, _)
superior (SSN1 , SSN2 ) ←
direct_supervisor (SSN1 , SSN2 )
superior (SSN1 , SSN2 ) ←
direct_supervisor (SSN1 , SSN3 ) ∧
superior (SSN3 , SSN2 )
/* Rekursion */
direct_supervisor (SSN1 , SSN2 ) ←
employee(_, SSN2 , _, _, _, SSN1 , _).
Zur besseren Lesbarkeit erlauben wir hier DATALOG–Variablen Xn mit Indizes,
die man streng genommen als X_n schreiben müßte.
Prof. Dr. Dietmar Seipel
82
Deduktive Datenbanken
Sommersemester 2012
Bottom–Up–Auswertung von DATALOG
2 Die Menge aller Fakten zu einem Prädikat entspricht einer Relation.
2 Die Menge aller Regeln mit demselben Prädikatensymbol im Kopf entspricht
einem V IEW–Statement, das eine Relation zum eben diesem
Prädikatensymbol erzeugt.
2 Die Relationen zu den Prädikatensymbolen aus dem Regelrumpf werden
selbst wieder mithilfe von Regeln berechnet.
So kann es passieren, daß eine Regel dabei hilft, transitiv Tupel für eines
ihrer eigenen Rumpfprädikatensymbole abzuleiten (Rekursion).
Z.B. ist die zweite Regel für superior direkt rekursiv.
2 Die Bottom–Up–Auswertung vergrößert iterativ die Relationen zu den
Prädikatensymbolen durch wiederholte Auswertung aller Regeln bis
schließlich ein Fixpunkt erreicht wird.
Auf diese Weise können alle transitiven Vorgesetzten abgeleitet werden,
was mit Standard–S QL beweisbar nicht möglich ist.
Prof. Dr. Dietmar Seipel
83
Deduktive Datenbanken
Sommersemester 2012
Beispiel (Transitive Vorgesetzte)
1111
j
2222
4444
?
5555
3333
j
6666
7777
R
8888
In der ersten Iteration werden Fakten für direct_supervisor aus den Fakten für
employee abgeleitet:
direct_supervisor(’1111’, ’2222’).
direct_supervisor(’1111’, ’3333’).
direct_supervisor(’2222’, ’4444’).
direct_supervisor(’2222’, ’5555’).
direct_supervisor(’2222’, ’6666’).
direct_supervisor(’3333’, ’7777’).
direct_supervisor(’3333’, ’8888’).
Prof. Dr. Dietmar Seipel
84
Deduktive Datenbanken
Sommersemester 2012
Die zweite Iteration überführt diese Fakten in die entsprechenden 7 Fakten für
superior.
superior(’1111’, ’2222’).
...
superior(’3333’, ’8888’).
Die dritte Iteration leitet 5 neue Fakten ab, die besagen daß der Angestellte ’1111’
der transitive (indirekte) Vorgesetzte der Angestellten ’4444’ bis ’8888’ ist:
superior(’1111’, ’4444’).
...
superior(’1111’, ’8888’).
Wenn man die Tiefe der Hierarchie beschränkt (hier Tiefe 2), dann könnten die
Relationen zu diesen Fakten auch in S QL abgeleitet werden.
Ohne Beschränkung der Tiefe ist es jedoch nicht möglich die transitiven
Vorgesetzten in S QL abzuleiten; hier wäre bereits Embedded S QL erforderlich.
Prof. Dr. Dietmar Seipel
85
Deduktive Datenbanken
Sommersemester 2012
Prizipiell können alle Regeln in allen Iterationen benutzt werden. Aber eine
Regel kann nur feuern und Fakten ableiten, nachdem passende Fakten für die
Rumpfatome in früheren Iterationen abgeleitet wurden. Von da an kann eine
Regel immer benutzt werden, um dieselben Fakten abzuleiten.
Eines der Ziele der effizienten Bottom–Up–Auswertung in deduktiven
Datenbanken ist die Vermeidung dieser redundanten Ableitungen – insbesondere
für rekursive Regelsysteme.
Die Regel für superior _by_name feuert in Iteration 3 zum ersten Mal und leitet
7 Fakten für direkte Vorgesetzte ab:
superior _by_name(’Borg’, ’Wong’).
...
superior _by_name(’Wallace’, ’Jabbar ’).
Zum Abschluß werden in Iteration 4 die 5 Fakten für die transitiven Vorgesetzten
abgeleitet. Iteration 5 leitet keine weiteren, neuen Fakten mehr ab. Also ist ein
Fixpunkt erreicht, und die Iteration terminiert.
Prof. Dr. Dietmar Seipel
86
Deduktive Datenbanken
Sommersemester 2012
Vergleich mit S QL
2 Nicht–rekursives DATALOG kann in S QL simuliert werden, indem man die
Regeln auf V IEW–Statements abbildet.
2 Rekursion bringt höhere Ausdrucksmächtigkeit für DATALOG.
2 Es gibt DATALOG–Erweiterungen, die (Default–) Negation und
Aggregatsfunktionen erlauben.
2 Der regelbasierte Ansatz von DATALOG unterstützt Modularisierung:
anstelle komplexer S ELECT– und V IEW–Statements in S QL können
einfachere und kompaktere DATALOG–Regeln benutzt werden.
Das deduktive Datenbanksystem DD BASE (vgl. Kapitel 2) unterstützt auch
Update–Operationen wie I NSERT und D ELETE, und es kann sich mit relationalen
Datenbanken verbinden.
Prof. Dr. Dietmar Seipel
87
Deduktive Datenbanken
Sommersemester 2012
1.2.2 Integritätsbedingungen und Default Negation
Transaktionen
2 Atomarität: Eine Transaktion ist eine atomare Einheit, welche verschiedene
Operationen zum Einfügen, Löschen und Update von Tupeln enthält.
2 Konsistenz: Vor und nach der Ausführung der Transaktion müssen alle
Integritätsbedingungen erfüllt sein.
2 Isolation: Verschiedene Transaktionen müssen voneinander isoliert
ausgeführt werden.
2 Dauerhaftigkeit: Die Effekte einer erfolgreichen Transaktion überleben jeden
danach auftretenden Hardware– oder Softwarefehler.
Wir interessieren uns im folgenden nur für die Integritätsbedingungen.
Prof. Dr. Dietmar Seipel
88
Deduktive Datenbanken
Sommersemester 2012
Beispiel (Integritätsbedingungen in DATALOGfun,not )
Schlüsselbedingung:
r1 = incorrect_db(one_mother (X , M1 , M2 )) ←
mother (X , M1 ) ∧ mother (X , M2 ) ∧ M1 6= M2
Fremdschlüsselbedingungen:
r2 = incorrect_db(person_parent(X )) ←
parent(X , _) ∧ not person(X )
r3 = incorrect_db(person_child (Y )) ←
parent(_, Y ) ∧ not person(Y )
r4 = person(X ) ← person(X , _, _)
Anomalien:
r5 = incorrect_db(self _parent(X )) ← parent(X , X )
r6 = incorrect_db(cyclic_ancestor (X )) ← ancestor (X , X )
Prof. Dr. Dietmar Seipel
89
Deduktive Datenbanken
Sommersemester 2012
Obige Regeln verwenden eine DATALOG–Erweiterung um Negation “not ” und
Funktionssymbole (z.B. “one_mother”).
Die Auswertung von DATALOGnot – bzw. DATALOGfun,not –Regeln ist etwas
komplizierter als bei DATALOG.
Obiges Programm ist aber stratifiziert:
2 Das Prädikat incorrect_db/1 hängt zwar von person/1 über Negation “not ”
ab, umgekehrt hängt person/1 aber nicht von incorrect_db/1 ab.
2 Deswegen kann man zuerst person/1 basierend auf dem EDB–Prädikat
person/3 auswerten. Danach kann man incorrect_db/1 auswerten.
Zur Auswertung von nicht–stratifizierten DATALOGnot – bzw.
DATALOGfun,not –Regeln braucht man kompliziertere Konzepte.
Prof. Dr. Dietmar Seipel
90
Deduktive Datenbanken
Sommersemester 2012
incorrect_db/1
R
r1
r2 , r3
not
6= /2
U
mother /2
parent/2
U
person/1
?
r4
?
person/3
Prof. Dr. Dietmar Seipel
91
Deduktive Datenbanken
Sommersemester 2012
Korrektheit der Datenbank:
r7 = correct_db(one_mother ) ←
not incorrect_db(one_mother )
r8 = incorrect_db(one_mother ) ←
mother (X , M1 ) ∧ mother (X , M2 ) ∧ M1 6= M2
Die obige Regel r1 für incorrect_db(one_mother (X , M1 , M2 )) kann hier nicht
direkt für r7 verwendet werden, denn
r9 = correct_db(one_mother ) ←
not incorrect_db(one_mother (X , M1 , M2 ))
würde die Datenbank immer als korrekt ansehen, da man Tupel findet, für die
incorrect_db(one_mother (X , M1 , M2 )) nicht gilt (z.B. für M1 = M2 ).
r9 ist in DATALOGfun,not auch gar nicht erlaubt, da die Variablen des negativen
Rumpfs nicht im positiven Rumpf vorkommen.
Prof. Dr. Dietmar Seipel
92
Deduktive Datenbanken
Sommersemester 2012
Ebenso kann man die Regel r4 , die in ihrer ausführlichen Schreibweise eigentlich
eine Regel
r4′ = person(X ) ← person(X , Y , S )
mit drei paarweise verschiedenen Variablen ist, nicht in r2 bzw. r3 einsetzen:
r2′ = incorrect_db(person_parent(X )) ←
parent(X , _) ∧ not person(X , _, S )
r3′ = incorrect_db(person_child (Y )) ←
parent(_, Y ) ∧ not person(Y , _, S )
Die erhaltenen Regeln hätten ebenfalls eine andere Bedeutung:
Falls es mindestens ein Fakt parent(X , Y ) gibt, so würden sie die Datenbank
immer als inkorrekt ansehen, da man Tupel findet, für die person(X , Y , S ) nicht
gilt (z.B. für S 6= female und S 6= male).
Außerdem wären r2′ und r3′ in DATALOGfun,not ebenfalls nicht erlaubt, da je zwei
Variablen (_ und S) des negativen Rumpfs nicht im positiven Rumpf vorkommen.
Prof. Dr. Dietmar Seipel
93
Deduktive Datenbanken
Sommersemester 2012
Gegenüberstellung entsprechender Konzepte
Prof. Dr. Dietmar Seipel
Datenbanken
DATALOG
Relation
Prädikat
Attribut
Argument
Tupel
Fakt
Anfrage
Ziel (Goal)
Sicht
Regeln
Integritätsbedingung
Regeln
94
Deduktive Datenbanken
Sommersemester 2012
Literatur
2 S. Ceri, G. Gottlob, L. Tanca:
Logic Programming and Databases, Springer, 1990.
2 S.K. Das:
Deductive Databases and Logic Programming, Addison–Wesley, 1992.
2 J.W. Lloyd:
Foundations of Logic Programming, Springer, Second Edition, 1987.
2 A. Cremers, U. Griefahn, R. Hinze:
Deduktive Datenbanken, Vieweg, 1994.
Prof. Dr. Dietmar Seipel
95
Deduktive Datenbanken
Sommersemester 2012
Erweiterungen von DATALOG
2 B UILT–I N–Prädikate: “<”, “≤”, “>”, “≥”, “=”, “6=”, “is”
2 Funktionssymbole: → DATALOGfun
Komplexe Objekte, z.B. für X ML, CAD, Geo–Datenbanken
2 Aggregationsfunktionen: sum, count, max, min, avg → DATALOGagg
2 Default Negation: → DATALOGnot
Closed–World–Annahme, Stratifizierung, perfekte/stabile Modelle
2 DATALOG∗ : beliebige P ROLOG–Regeln mit stratifizierten Meta–Prädikaten
(z.B. für Aggregation und Negation), Bottom–Up–Auswertung
2 Unvollständiges und unsicheres Wissen, Disjunktion: → D IS L OG
2 Updates, Typenkonzepte, Nullwerte, . . .
Prof. Dr. Dietmar Seipel
96
Deduktive Datenbanken
1.2.3
Sommersemester 2012
B UILT–I N–Prädikate
B UILT–I N–Prädikate sind EDB–Prädikate, die – meist in Infix–Notation
geschrieben – nicht explizit in der EDB gespeichert, sondern durch eine
Auswertungsvorschrift gegeben sind.
Beispiele:
“<”, “≤”, “>”, “≥”, “=”, “6=”, “is”
Regel mit Built–In–Prädikat:
sibling(X , Y ) ← parent(X , Z ) ∧ parent(Y , Z ) ∧ X 6= Y
Die zugehörigen EDB–Relationen sind meist unendlich, was Probleme bei der
Auswertung der sie enthaltenden DATALOG–Programme aufwerfen kann
(unendlich viele abgeleitete Fakten).
Prof. Dr. Dietmar Seipel
97
Deduktive Datenbanken
Sommersemester 2012
Beispiele:
is
6=
=
Prof. Dr. Dietmar Seipel
a
a
b
b
c
..
.
c
..
.
X
Y
Z is X + Y
a
b
0
1
1
b
a
0
2
2
a
c
c
a
0
..
.
3
..
.
3
..
.
b
c
1
1
2
c
..
.
b
..
.
1
2
3
1
..
.
3
..
.
4
..
.
98
Deduktive Datenbanken
Sommersemester 2012
Deswegen müssen DATALOG–Programme mit B UILT–I N–Prädikaten folgende
Bedingung erfüllen:
Sicherheitsbedingung
jede Variable, die in einem Input–Argument eines B UILT–I N–Prädikates
in einem Regelrumpf auftritt, muß
2 gleichzeitig auch in einem gewöhnlichen Prädikat desselben
Regelrumpfes auftreten, oder sie muß
2 durch eine Folge von Gleichheits–Prädikaten ausgehend von
gewöhnlichen Prädikaten gebunden sein.
In der constraint–logischen Programmierung (CLP) ist diese Bedingung nicht
erforderlich. Dann werden bei Aufrufen mit arithmetischen Vergleichsprädikaten
alle möglichen Bindungen – innerhalb einer vorgegebenen Domäne – für die
beteiligten Variablen generiert.
Prof. Dr. Dietmar Seipel
99
Deduktive Datenbanken
Sommersemester 2012
Beispiel (Sichere und unsichere DATALOG–Regeln)
2 unsichere Regel:
ordinary_citizen(X ) ←
president(Y ) ∧ X 6= Y
Bei der Auswertung kann man beliebige Werte für X einsetzen.
2 sichere Regeln:
ordinary_citizen(X ) ←
citizen(X ) ∧ president(Y ) ∧ X 6= Y,
ordinary_citizen(X ) ←
citizen(X ) ∧ president(Y ) ∧ X = U ∧ Y = V ∧ U 6= V
Bei der Auswertung werden die Werte für X durch das Domänen–Prädikat
citizen gebunden.
Prof. Dr. Dietmar Seipel
100
Deduktive Datenbanken
Sommersemester 2012
Auswertung eines B UILT–I N–Prädikats
2 “<”, “≤”, “>”, “≥”, “6=” erfolgt erst, sobald alle seine Argumente gebunden
sind,
2 “=” erfolgt erst, sobald ein Argument gebunden ist,
2 “is” erfolgt erst, sobald alle seine Input–Argumente gebunden sind.
Der Vergleich X = Z in der ersten der folgenden Regeln stellt kein Problem dar.
In der zweiten Regel hat Z is U +V die Input–Variablen “U” und “V”.
r (X , Y ) ← p(a, X) ∧ X = Z ∧ q(Z, Y ),
r (X , Y , Z ) ← p(X, U ) ∧ q(Y, V ) ∧ Z is U +V
Prof. Dr. Dietmar Seipel
101
Deduktive Datenbanken
Sommersemester 2012
Bei der Übersetzung von DATALOG–Regeln in S QL oder die Relationenalgebra
werden B UILT–I N–Prädikate durch Join–Bedingungen ausgedrückt.
Relationenalgebra und S QL
Für die DATALOG–Regel
sibling(X , Y ) ← parent(X , Z ) ∧ parent(Y , Z ) ∧ X 6= Y
erhalten wir in der Relationenalgebra
S IBLING = ΠP1.NAME,P2.NAME (P1 1C P2),
mit P1 = P2 = PARENT und C = (P1.PARENT = P2.PARENT ) A ND (P1.NAME
6= P2.NAME ), und in S QL
C REATE V IEW S IBLING A S
S ELECT P1.NAME , P2.NAME
F ROM PARENT P1, PARENT P2
W HERE C.
Prof. Dr. Dietmar Seipel
102
Deduktive Datenbanken
Sommersemester 2012
1.2.4 Aggregationsfunktionen
Datenbankschema für komplexe Objekte:
2 components(Product, Component, Qty):
Ein komplexes Teil Product enthält Qty Teile Component.
2 price(Product, Price):
Ein elementares Teil Product kostet Price Geldeinheiten.
Für ein Teil sind entweder die Komponenten (komplexes Teil) oder der Preis
(elementares Teil) angegeben – aber nicht beides.
Die Kosten eines Teils berechnen sich rekursiv aus den Kosten seiner Unterteile:
2 costs(Product, Costs).
Wenn das Teil Component die Kosten C hat, dann trägt es mit C * Qty
Geldeinheiten zum Preis von Product bei.
Prof. Dr. Dietmar Seipel
103
Deduktive Datenbanken
Sommersemester 2012
Graphische Form
engine
4
9
sparkplug
4
cylinder
1
piston
2
gasket
R
hanger
4
4
screw
3
screw
4
?
20
2
?
bolt
joint
10
screw
gasket
8
R
screw
crankshaft
connecting rod
z
j
1
R
2
1
valve
1
Prof. Dr. Dietmar Seipel
4
?
bolt
?
bolt
104
Deduktive Datenbanken
Sommersemester 2012
Relationale Form
C OMPONENTS
Prof. Dr. Dietmar Seipel
engine
sparkplug
4
engine
cylinder
4
engine
valve
4
engine
crankshaft
1
cylinder
piston
1
cylinder
connecting rod
1
valve
gasket
1
valve
hanger
2
crankshaft
joint
8
piston
screw
2
piston
gasket
3
connecting rod
screw
4
connecting rod
bolt
4
hanger
screw
4
hanger
bolt
2
joint
screw
10
joint
bolt
20
P RICE
sparkplug
10
screw
2
gasket
3
bolt
2
105
Deduktive Datenbanken
Sommersemester 2012
Stücklisten–Auflösung
Die folgenden DATALOGagg –Regeln berechnen rekursiv die Kosten eines Teils
als die Summe der Kosten seiner Unterteile:
costs(Product, hCost isum ) ←
components(Product, Component, Qty) ∧
costs(Component, C ) ∧ Cost is C ∗ Qty.
costs(Product, Price) ←
price(Product, Price).
Da die zum Prädikat component gehörige Teilehierarchie azyklisch ist, kann
man die Kosten der Komponenten vor den Kosten eines Teils berechnen.
Im Allgemeinen erfordert die Auswertung rekursiver Regeln mit Aggregation
allerdings kompliziertere Mechanismen.
Prof. Dr. Dietmar Seipel
106
Deduktive Datenbanken
Sommersemester 2012
In DATALOG∗ könnte die Berechnung wie folgt aussehen:
costs(Product, Sum) :ddbase_aggregation( [Product, sum(Cost)],
( transitive_closure( components,
Product:1, P2:Q2 ),
price(P2, Price),
Cost is Price * Q2 ),
[Product, Sum] ).
components(P1:Q1, P2:Q2) :components(P1, P2, Q),
Q2 is Q1 * Q.
Anstelle mit der rekursiven Aggregation aus DATALOGagg , die hier nicht erlaubt
ist, wird der Preis über die transtive Hülle der Teilehierarchie ermittelt.
Prof. Dr. Dietmar Seipel
107
Deduktive Datenbanken
Sommersemester 2012
Hierbei wird der folgende virtuelle Graph verwendet:
engine:1
9
sparkplug:4
cylinder:4
piston:4
R
connecting rod:4
gasket:12
crankshaft:1
R
gasket:4
R
hanger:8
screw:16
?
Prof. Dr. Dietmar Seipel
valve:4
screw:8
z
j
screw:32
?
bolt:16
joint:8
screw:80
?
bolt:16
?
bolt:160
108
Deduktive Datenbanken
Sommersemester 2012
In P ROLOG könnte man die Berechnung dagegen direkt umsetzen:
costs(Product, Sum) :ddbase_aggregation( [Product, sum(Cost)],
( components(Product, Component, Qty),
costs(Component, C), Cost is C * Qty ),
[Product, Sum] ).
costs(Product, Price) :price(Product, Price).
Hier ist die rekursive Aggregation aus DATALOGagg erlaubt.
2 Für komplexe Teile werden die Kosten der Unterteile aggregiert (Regel 1).
2 Für elementare Teile ist ein Preis angegeben (Regel 2).
Das Prädikat ddbase_aggregation/3 basiert auf
ddbase_aggregate/3; beide finden sich im D DK.
Prof. Dr. Dietmar Seipel
109