Deduktive Datenbanken - Universität Würzburg

Vorlesung
Deduktive Datenbanken
Prof. Dr. Dietmar Seipel
Universität Würzburg
Sommersemester 2012
Deduktive Datenbanken
Sommersemester 2012
Inhaltsverzeichnis
1 Datenbanken und DATALOG
1.1
1.2
Prof. Dr. Dietmar Seipel
41
Grundbegriffe des relationalen Datenmodells . . . . . . . . . . .
42
1.1.1
Relationen und Relationenschemata . . . . . . . . . . . .
42
1.1.2
Relationale Anfragesprachen . . . . . . . . . . . . . . . .
48
Die deduktive Datenbanksprache DATALOG . . . . . . . . . . . .
58
1.2.1
Regeln und Fakten . . . . . . . . . . . . . . . . . . . . .
64
1.2.2
Integritätsbedingungen und Default Negation . . . . . . .
88
1.2.3
B UILT–I N–Prädikate . . . . . . . . . . . . . . . . . . . .
97
1.2.4
Aggregationsfunktionen . . . . . . . . . . . . . . . . . . 103
1
Deduktive Datenbanken
Sommersemester 2012
2 Die deklarative Programmiersprache P ROLOG
2.1
2.2
110
Grundlegende Strukturen . . . . . . . . . . . . . . . . . . . . . . 116
2.1.1
Klauseln . . . . . . . . . . . . . . . . . . . . . . . . . . 119
2.1.2
Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . 136
Programmierstrukturen . . . . . . . . . . . . . . . . . . . . . . . 164
2.2.1
Rekursion . . . . . . . . . . . . . . . . . . . . . . . . . . 166
2.2.2
Prädikatenorientiertes, relationales Programmieren . . . . 184
2.2.3
Backtracking und der Cut . . . . . . . . . . . . . . . . . 199
2.3
Die interne P ROLOG–Datenbank . . . . . . . . . . . . . . . . . . 215
2.4
Datenbanken und P ROLOG . . . . . . . . . . . . . . . . . . . . . 241
Prof. Dr. Dietmar Seipel
2.4.1
O DBC–Zugriff auf eine relationale Datenbank . . . . . . . 243
2.4.2
Das deduktive Mini–DBMS DD BASE . . . . . . . . . . . 249
2
Deduktive Datenbanken
Sommersemester 2012
2.5
GUI–Programmierung in X PCE–P ROLOG . . . . . . . . . . . . . 278
2.6
Datenstrukturen, Kontrollstrukturen und Algorithmen . . . . . . . 289
2.7
Prof. Dr. Dietmar Seipel
2.6.1
Suche in Graphen . . . . . . . . . . . . . . . . . . . . . . 290
2.6.2
Sortierverfahren . . . . . . . . . . . . . . . . . . . . . . 297
2.6.3
Binäre Suchbäume . . . . . . . . . . . . . . . . . . . . . 304
2.6.4
Hierarchische Daten . . . . . . . . . . . . . . . . . . . . 314
2.6.5
Diagnoseregeln in DATALOG∗ . . . . . . . . . . . . . . . 347
Vergleich mit DATALOG . . . . . . . . . . . . . . . . . . . . . . 353
3
Deduktive Datenbanken
Sommersemester 2012
3 Definite Logikprogramme
3.1
3.2
3.3
Prof. Dr. Dietmar Seipel
380
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
3.1.1
Klauseln und Regeln . . . . . . . . . . . . . . . . . . . . 384
3.1.2
Definite Logikprogramme, DATALOG . . . . . . . . . . . 393
3.1.3
Substitutionen und Unifikation . . . . . . . . . . . . . . . 399
3.1.4
Herbranduniversum, Herbrandbasis, Grundinstanz . . . . 431
Die modelltheoretische Semantik . . . . . . . . . . . . . . . . . . 440
3.2.1
Herbrandinterpretationen und Herbrandmodelle . . . . . . 445
3.2.2
Logische Konsequenzen . . . . . . . . . . . . . . . . . . 460
Beweistheorie: Bottom–Up . . . . . . . . . . . . . . . . . . . . . 471
3.3.1
Der Konsequenzoperator TP . . . . . . . . . . . . . . . . 474
3.3.2
Iteration des TP –Operators . . . . . . . . . . . . . . . . . 492
4
Deduktive Datenbanken
Sommersemester 2012
3.3.3
Forward Chaining: Beweisbäume . . . . . . . . . . . . . 515
3.3.4
Der verallgemeinerte Konsequenzoperator TPbu ,Ptd . . . . 519
3.4
Fixpunkttheorie auf Partialordnungen . . . . . . . . . . . . . . . 532
3.5
Beweistheorie: Top–Down . . . . . . . . . . . . . . . . . . . . . 533
Prof. Dr. Dietmar Seipel
3.5.1
Backward Chaining: Suchbäume und Beweisbäume . . . . 534
3.5.2
SLD–Resolution und SLD–Bäume . . . . . . . . . . . . . 545
3.5.3
SLDNF–Resolution
. . . . . . . . . . . . . . . . . . . . 577
5
Deduktive Datenbanken
Sommersemester 2012
4 Datenstrukturen und Programmstrukturen für Logikprogramme
4.1
4.2
591
Datenstrukturen in P ROLOG . . . . . . . . . . . . . . . . . . . . 592
4.1.1
Terme und Goals . . . . . . . . . . . . . . . . . . . . . . 593
4.1.2
Logikprogramme als Klauseln oder als Terme . . . . . . . 627
4.1.3
Die Field Notation für komplexe Objekte . . . . . . . . . 649
Kontrollstrukturen und Meta–Prädikate von P ROLOG . . . . . . . 670
4.2.1
Finden aller Lösungen . . . . . . . . . . . . . . . . . . . 671
4.2.2
Filter und Transformationen . . . . . . . . . . . . . . . . 682
4.2.3
Schleifen und Verzweigungen . . . . . . . . . . . . . . . 686
4.3
Struktureigenschaften von Logikprogrammen . . . . . . . . . . . 705
4.4
Äquivalenz und Transformation von Logikprogrammen . . . . . . 735
Prof. Dr. Dietmar Seipel
6
Deduktive Datenbanken
5 Auswertungsmethoden und Programmoptimierung für DATALOG
Prof. Dr. Dietmar Seipel
Sommersemester 2012
779
7
Deduktive Datenbanken
Sommersemester 2012
6 Default Negation und normale Logikprogramme
6.1
6.2
6.3
Prof. Dr. Dietmar Seipel
780
DATALOGnot – DATALOG mit Default Negation . . . . . . . . . . 793
6.1.1
Syntax und Semantik (Modelltheorie) . . . . . . . . . . . 793
6.1.2
Die Closed–World–Annahme . . . . . . . . . . . . . . . 800
Stratifizierte Auswertung von DATALOGnot . . . . . . . . . . . . 804
6.2.1
Abhängigkeitsgraphen und Stratifizierung . . . . . . . . . 805
6.2.2
Die Konsequenzoperatoren TP und TP′
6.2.3
Das perfekte Modell . . . . . . . . . . . . . . . . . . . . 841
6.2.4
Ontologie–Analyse in DATALOG∗ . . . . . . . . . . . . . 872
. . . . . . . . . . 826
Stabile und wohlfundierte Modelle . . . . . . . . . . . . . . . . . 894
6.3.1
Stabile Modelle . . . . . . . . . . . . . . . . . . . . . . . 896
6.3.2
Berechnungsfolgen für stabile Modelle . . . . . . . . . . 921
6.3.3
Das wohlfundierte Modell . . . . . . . . . . . . . . . . . 932
8
Deduktive Datenbanken
Sommersemester 2012
7 Disjunktive Logikprogramme
978
Literatur
Index
979
981
Prof. Dr. Dietmar Seipel
9
Deduktive Datenbanken
Sommersemester 2012
Prof. Dr. Dietmar Seipel
10
Deduktive Datenbanken
Sommersemester 2012
Vorwort
Deduktive Datenbanken entstehen durch die Integration von
2 Logikprogrammierung und
2 Datenbanktechnologie.
Die darauf aufbauenden DBLP–Systeme können z.B.
2 komplexe, wissensbasierte Systeme,
2 intelligente, entscheidungsunterstützende Systeme (Expertensysteme) und
2 Semantic Web–Anwendungen
unterstützen.
Prof. Dr. Dietmar Seipel
1
Deduktive Datenbanken
Sommersemester 2012
Logikprogrammierung und Datenbanken
Logikprogrammierung in P ROLOG:
2 Vereinfachung von Techniken des Theorembeweisens
−→ effiziente und einfachere Programmierung
1970
relationales Datenmodell:
2 Vereinfachung des hierarchischen und des Netzwerkdatenmodells
−→ mengenorientierte, deklarative Datenmanipulation
kommerzielle Nutzung:
1980
Logikprogrammierung in DATALOG:
2 mächtige, deklarative Datenbankanfragesprache
−→ Anfrageoptimierung möglich
Prof. Dr. Dietmar Seipel
seit 1980
2
Deduktive Datenbanken
Sommersemester 2012
Auch das japanische Fifth–Generation–Projekt hat DBLP–Systeme für
Anwendungen aus der künstlichen Intelligenz (KI) propagiert.
2 Diese erfordern extrem viele Deduktionen pro Zeiteinheit, und
2 sie greifen auf ein relationales Datenmodell zur Speicherung großer
Datenmengen zurück.
Kombination:
2 Datenbanktechnologie für effizienten Zugriff und zuverlässigen Update
persistenter Daten,
2 Logikprogrammierung als homogener, ausdrucksmächtiger Formalismus zur
Formulierung von Anfragen, Integritätsbedingungen und prozeduralen
Komponenten, und für deklarative Programmier–Frontends für Datenbanken.
Prof. Dr. Dietmar Seipel
3
Deduktive Datenbanken
Sommersemester 2012
Architektur eines DBLP–Systems
Prof. Dr. Dietmar Seipel
4
Deduktive Datenbanken
Sommersemester 2012
Beispiel: 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
5
Deduktive Datenbanken
Sommersemester 2012
Der Familienstammbaum kann in einer Tabelle (Relation) PARENT einer
relationalen Datenbank gespeichert werden:
PARENT
G RANDPARENT
NAME
PARENT
Elizabeth
George
Charles
Elizabeth
William
Charles
...
...
NAME
G RANDPARENT
Charles
George
William
Elizabeth
...
...
Die Großeltern (Tabelle G RANDPARENT) können in S QL berechnet werden:
S ELECT P1.NAME , P2.PARENT
F ROM PARENT P1, PARENT P2
W HERE P1.PARENT = P2.NAME
Prof. Dr. Dietmar Seipel
6
Deduktive Datenbanken
Sommersemester 2012
Die Vorfahren einer Person können in S QL nicht berechnet werden:
A NCESTOR
NAME
A NCESTOR
William
George
...
...
In einem DBLP–System kann man diese aber mittels rekursiver
DATALOG–Regeln berechnen:
ancestor (X , Z ) ← parent(X , Z ),
ancestor (X , Z ) ← parent(X , Y ) ∧ ancestor (Y , Z ).
Eine Person Z ist ein Vorfahre einer Person X,
2 falls Z ein Elternteil von X ist (erste Regel), oder
Z
I
ancestor 6
Y ancestor
parent 6
X
2 falls Z ein Vorfahre eines Elternteils Y von X ist (zweite Regel).
Prof. Dr. Dietmar Seipel
7
Deduktive Datenbanken
Sommersemester 2012
Anwendungsbereiche von DBLP
2 Datenbanken mit komplexen Strukturen (Hierarchien, X ML)
2 komplexe, wissensbasierte Systeme,
regelbasierte Systeme, Diagnosesysteme (Medizin, Technik)
2 Datenintegration
2 Semantic Web
2 Default Reasoning, Answer Set Programming (ASP)
2 symbolische Informationsverarbeitung, Parsing
2 Graphenprobleme und kombinatorische Probleme
(Spiele wie Sudoku oder Minesweeper, etc.)
Prof. Dr. Dietmar Seipel
8
Deduktive Datenbanken
Sommersemester 2012
Wissensbasiertes System
Wir verwenden DBLP–Systeme z.B. zur Realsierung der Wissensbasis sowie der
Inferenz– und der Erklärungskomponente von wissensbasierten Systemen.
Prof. Dr. Dietmar Seipel
9
Deduktive Datenbanken
Sommersemester 2012
Semantic Web
Knowledge Engineering im Semantic Web basiert auf Ontologien und Logik und
kann von Techniken aus dem Bereich der Deduktiven Datenbanken und der
Logikprogrammierung unterstützt werden.
Die Semantic Web Rule Language (S WRL) baut Regeln aus der
Logikprogrammierung in OWL–Ontologien ein.
Deduktionsaufgaben:
2 Unterstützung der Anfrageauswertung;
2 in der Wissensmodellieung: Analyse der Struktur von Ontologien im
Hinblick auf Anomalien.
Prof. Dr. Dietmar Seipel
10
Deduktive Datenbanken
Sommersemester 2012
DBLP–Anwendungen in Würzburg
2 Software Engineering: Analyse und Refaktorisierung von
– Programm–Quellcode (P ROLOG, JAVA, P HP, C OBOL),
– Datenbankanwendungen (Schema und Embedded S QL–Code) und
– Ontologien (OWL, S WRL) im Semantic Web
2 Bio–Informatik: Management komplexer X ML–Daten,
z.B. im Rahmen der Pathway–Analyse
2 Sprachwissenschaften:
Parsing, Analyse und Aufbereitung von Textdaten, oft in X ML
2 Analyse–Tools:
– Taktikanalyse im Sport (Tennis, Basketball)
– Stocktool: Chartanalyse und Visualisierung
Prof. Dr. Dietmar Seipel
11
Deduktive Datenbanken
Sommersemester 2012
DBMS–Eigenschaften von DBLP–Systemen
2 Datenintegration, Datenunabhängigkeit/Datenabstraktion:
Wissen aus Fakten (Tupeln von Relationen) und Regeln (Methoden)
2 Datenintegrität:
wie bei relationalen DBMS + erweiterte Ausdrucksmächtigkeit
2 Datenpersistenz, Datensicherheit, Datenschutz:
vom zugrunde liegenden relationalen DBMS übernommen
2 deklarative Anfragesprache:
ausdrucksmächtig, Zugriffsoptimierung auch für rekursive Regeln
Prof. Dr. Dietmar Seipel
12
Deduktive Datenbanken
Sommersemester 2012
Datenintegration
JAVA
Programmiersprachen
P ROLOG
?
DATALOG∗
DB–Anfragesprachen
?)
S QL
?
RDB
X ML,
OWL
?
Excel
(.csv)
^
Text
Datenquellen
Abstraktion
Teile der Datenbankprogrammierung erfolgen deklarativ in DATALOG anstelle
prozedural in JAVA mit Embedded S QL.
Prof. Dr. Dietmar Seipel
13
Deduktive Datenbanken
Sommersemester 2012
P ROLOG
Man kann mit P ROLOG (im Gegensatz zur “reinen” Logikprogrammierung) auch
2 prozedural
2 mit Seiteneffekten und
2 mit globalen Variablen (realisiert mit Hilfe von assert und retract)
programmieren.
P ROLOG–Implementierungen wie – z.B. S WI/X PCE–P ROLOG – besitzen
umfangreiche Programmbibliotheken und Erweiterungen:
2 Datenstrukturen und Algorithmen, Kombinatorik,
2 Datenbank– und Web–Programmierung,
2 komfortable GUI–Programmierung, etc.
Prof. Dr. Dietmar Seipel
14
Deduktive Datenbanken
Sommersemester 2012
Die einfache Handhabung von Termen als Datenstruktur und die mächtige,
eingebaute Kontrollstruktur des Backtrackings sind Features, die P ROLOG im
Vergleich zu anderen Programmiersprachen auszeichnen.
P ROLOG ist sehr gut zur eingebetten Datenbankprogrammierung geeignet.
Im Datenbankkontext wird häufig eine eingeschränkte Version benutzt, die
DATALOG genannt wird – die Basis der deduktiven Datenbanken.
2 P ROLOG und DATALOG sind deklarative Sprachen, mit denen man auf
Datenbanken und X ML–Dokumenten operieren kann.
2 Relationen und komplexe Objekte (wie z.B. X ML–Dokumente) können in
sehr natürlicher Weise als Terme repräsentiert werden.
2 Mithilfe deklarativer Regeln können wir auch Integritätsbedingungen und
Inferenzregeln zur Ableitung von Schlußfolgerungen aus der gegebenen
Information repräsentieren.
Prof. Dr. Dietmar Seipel
15
Deduktive Datenbanken
Sommersemester 2012
Datenbankprogrammierung
2 Man kann aus P ROLOG heraus über eine S QL–Schnittstelle mittels O DBC
auf relationale Datenbanken zugreifen.
2 Die Verbindung von P ROLOG und DATALOG erlaubt eine sehr komfortable
Programmierung von Datenbankanwendungen.
2 Der von Embedded S QL (J DBC , O DBC) bekannte Mismatch zwischen
– der Datenbanksprache S QL und
– der Host–Programmiersprache (z.B. JAVA oder C++)
kann hier vermieden werden.
Prof. Dr. Dietmar Seipel
16
Deduktive Datenbanken
Sommersemester 2012
Bei der Datenbankprogrammierung mit Embedded S QL werden deklarative
S QL–Statements in prozeduralen Code (z.B. JAVA) eingebunden.
In DBLP–Systemen wird der prozedurale Code durch P ROLOG ersetzt,
das dann deklarativ über DATALOG∗ –Regeln und S QL–Statements auf die
Datenbank zugreift.
Dadurch wird ein deutlich größerer Anteil der Datenbankprogrammierung
deklarativ, und zwar ohne daß man die zugrundeliegende Datenbank ändern
müßte.
RDB
Prof. Dr. Dietmar Seipel
Y
S QL
S QL
DATALOG∗
P ROLOG
JAVA
DBLP
Embedded S QL
17
Deduktive Datenbanken
Sommersemester 2012
APIs und Tools für P ROLOG
2 S WI–P ROLOG–Libraries (/usr/lib/pl-x.y.z/library):
lists.pl, ordsets.pl, ugraphs.pl, odbc.pl, sgml.pl, . . . ,
andere P ROLOG–Libraries: loops.pl, . . .
2 X PCE–P ROLOG–Libraries für S WI–P ROLOG:
(/usr/lib/pl-x.y.z/xpce/prolog/lib):
WWW, H TML, Charts, . . .
2 D IS L OG Developers’ Kit (D DK) für S WI–P ROLOG::
Units (~DisLog/sources):
– basic_algebra, nm_reasoning, xml, databases,
– development, stock_tool, projects, linguistics, biology_and_medicine.
S WI–P ROLOG ist in C geschrieben.
Prof. Dr. Dietmar Seipel
18
Deduktive Datenbanken
Sommersemester 2012
DDK (D IS L OG Developers’ Toolkit)
eine große P ROLOG–Bibliothek mit Algorithmen und Datenstrukturen für
verschiedenste Anwendungen, einschließlich Datenbanken, nicht–montones
Schließen (NMR), WWW, X ML und Software Engineering
2 DD BASE:
ein P ROLOG–basiertes deduktives Datenbanksystem mit Anbindung an
relationale Datenbanken (MySQL) und verschiedene ASP–Systeme
2 F N Query/ PL4XML:
eine deklarative, P ROLOG–basierte X ML–Anfrage–, Transformations– und
Update–Sprache
2 DATALOG∗ :
eine mit P ROLOG verwobene Erweiterung von DATALOG
Prof. Dr. Dietmar Seipel
19
Deduktive Datenbanken
Sommersemester 2012
Andere Systeme zur Logikprogrammierung
2 deduktive Datenbanksysteme:
C ORAL, LDL, Lola, A DITI
2 Systeme für Answer Set Programming (ASP):
dlv, Smodels, X SB, Lola, Cmodels, ASAT
2 P ROLOG–Systeme:
S WI, S ICStus, Visual P ROLOG, IF P ROLOG, Mercury
2 Constraint–logische Programmierung (CLP):
Eclipse, Chip, Minerva
2 Funktional–logische Programmierung (FLP):
Curry
Prof. Dr. Dietmar Seipel
20
Deduktive Datenbanken
Sommersemester 2012
Themengebiete der Vorlesung
2 Grundlagen von DATALOG und P ROLOG
2 das deduktive Datenbanksystem DD BASE
2 F N Query, DATALOG∗
2 effiziente Auswertung von Logikprogrammen
2 weitere Sprachkonstrukte:
– Built–In–Prädikate, Aggregationsfunktionen
– Negation und Disjunktion
−→ Answer Set Programming (ASP), D IS L OG
2 Anwendungen
Prof. Dr. Dietmar Seipel
21
Deduktive Datenbanken
Sommersemester 2012
Kapitel 1 und 2: DATALOG und P ROLOG
DATALOG und P ROLOG sind – auf einem Domänenkalkül basierende – logische
Programmiersprachen, die sich syntaktisch sehr ähneln und sich semantisch (in
der Auswertung) unterscheiden.
2 DATALOG ist eine deklarative Datenbanksprache.
2 Es erweitert die relationale Datenbanksprache S QL (Tupelkalkül) um
Rekursion. Nicht–rekursive DATALOG–Anfragen kann man leicht nach S QL
übersetzen – und umgekehrt.
2 DATALOG kann – ähnlich wie S QL – effizient mengen–orientiert ausgewertet
werden.
2 Für praktische Anwendungen braucht man oft zusätzliche Features, wie
Built–In–Prädikate, komplexe Typen, Aggregation und Default Negation, die
nicht von allen Systemen unterstützt werden.
Prof. Dr. Dietmar Seipel
22
Deduktive Datenbanken
Sommersemester 2012
P ROLOG ist eine deklarative Programmiersprache:
2 Wegen ihrer Kompaktheit und weitgehenden Ungetyptheit kann sie sehr gut
als Skripting–Sprache verwendet werden.
2 Konstrukte höherer Ordnung (Funktionale) erlauben sehr viel Abstraktion
und selbst–definierte Kontrollstrukturen.
2 Die Programmierung ist relational mit eingebautem Backtracking, und es
wird häufig Rekursion verwendet.
Im Vergleich zu DATALOG
2 bietet P ROLOG deutlich mehr syntaktische Features, aber dafür weniger
semantische Alternativen;
2 ist die tupel–orientierte Auswertung von P ROLOG weniger effizient und
terminiert für rekursive Programme manchmal nicht.
Prof. Dr. Dietmar Seipel
23
Deduktive Datenbanken
Sommersemester 2012
P ROLOG–Programmierung
2 Wir zeigen auf, wie P ROLOG in Verbindung mit relationalen Datenbanken
benutzt werden kann.
2 Zur Datenhaltung in P ROLOG selbst kann die interne P ROLOG–Datenbank
verwenden. Auf deren Basis wurde auch das deduktive
Mini–Datenbanksystem DD BASE entwickelt.
2 X PCE–P ROLOG bietet viele weitere Features (GUI–,
Web–Programmierung), die noch nicht im Sprachstandard von P ROLOG
enthalten sind.
2 Wir zeigen verschiedene Anwendungen von P ROLOG: Sortieren und Suchen
(auch in Graphen), Analyse hierarchischer Daten, medizinische Diagnose.
Für praktische Anwendungen ist oft die Verbindung von P ROLOG, DATALOG und
Datenbanken (relational oder X ML) sehr sinnvoll (DBLP–Systeme).
Prof. Dr. Dietmar Seipel
24
Deduktive Datenbanken
Sommersemester 2012
Anwendungsbeispiel: Stücklistenauflösung
Die Stücklistenauflösung dient in der Betriebswirtschaftslehre der Ermittlung der
in einer Planperiode erforderlichen Bedarfsmengen an Werkstoffen und Teilen.
components(C1, C2:Q2):
Ein Werkteil vom Typ C1 enthält Q2 Komponenten vom Typ C2.
a
d
4
b
2
3
R
5 6
R e
c
7
R
f
components(a,
components(a,
components(b,
components(b,
components(c,
components(c,
b:2).
c:3).
d:4).
e:5).
e:6).
f:7).
Dann hat ein komplexes Teil vom Typ a z.B. folgende Stückliste:
[d:8, e:28, f:21].
Prof. Dr. Dietmar Seipel
25
Deduktive Datenbanken
Sommersemester 2012
Die persistente Speicherung und Verwaltung der Teilehierarchie kann in einer
relationalen Datenbank erfolgen, aus der dann die Fakten components(C1,
C2:Q2) extrahiert werden:
C OMPONENTS
a
d
4
b
2
3
R
5 6
R e
c
7
R
f
C1
C2
Q2
a
b
2
a
c
3
b
d
4
b
e
5
c
e
6
c
f
7
Das in P ROLOG implementierte deduktive Datenbanksystem DD BASE kann über
O DBC auf relationale Datenbanken zugreifen.
Prof. Dr. Dietmar Seipel
26
Deduktive Datenbanken
Sommersemester 2012
Die Stückliste
[d:8, e:28, f:21]
eines komplexen Teils vom Typ a wird wie folgt berechnet:
a → [d:(8 = 2 · 4), e:(28 = 2 · 5 + 3 · 6), f:(21 = 3 · 7)]
2
b → [d:4, e:5]
4
d → [d:1]
Prof. Dr. Dietmar Seipel
3
R
c → [e:6, f:7]
5
6
R
e → [e:1]
7
R
f → [f:1]
27
Deduktive Datenbanken
Sommersemester 2012
Die Berechnung der Stücklisten für beliebig komplexe (tiefe) Teile ist nur in
Embedded S QL möglich, nicht aber in S QL. In P ROLOG reicht dagegen das
folgende, kompakte Logikprogramm zur Stücklistenaggregation schon aus:
parts_of(C1, C2:Q2) :( not(components(C1, _)) -> C2:Q2 = C1:1
; ddbase_aggregation( [Cb, sum(Qa*Qb)],
( components(C1, Ca:Qa),
parts_of(Ca, Cb:Qb) ), [C2, Q2] ) ).
(If->Then;Else):
2 Falls C1 keine Komponenten hat, so wird C1:1 berechnet.
2 Andernfalls ermittelt ddbase_aggregation/3 für alle Komponenten
Ca:Qa von C1 wieviele Teile Cb:Qb diese enthalten und berechnet die
Summe Q2 über alle Qa*Qb.
Prof. Dr. Dietmar Seipel
28
Deduktive Datenbanken
Sommersemester 2012
Kapitel 3: Syntax und Semantik (Theorie)
2 Die syntaktischen Grundbausteine von DATALOG und P ROLOG stammen aus
der Prädikatenlogik: Terme, Atome und Klauseln. Letztere werden für
Fakten, Regeln und Anfragen verwendet.
2 Die Semantik von DATALOG kann mittels Inferenzmethoden
(beweis–theoretisch: TP , SLD/SLDNF), modell–theoretisch oder mittels
eines Fixpunktansatzes beschrieben werden.
2 In der Praxis wird bei DATALOG die Bottom–Up–Inferenzmethode des
TP –Operators – basierend auf Hyperresolution – zur Bestimmung aller
ableitbaren Fakten verwendet.
2 Für P ROLOG ist die Top–Down–Inferenzmethode der SLDNF–Resolution
die grundlegenede Auswertungsmethode für Anfragen; allerdings muß sie
dann um außer–logische Features mit Seiteneffekten erweitert werden.
Prof. Dr. Dietmar Seipel
29
Deduktive Datenbanken
Sommersemester 2012
Kapitel 4: Daten– und Programmstrukturen für P ROLOG
2 Es gibt nur eine Reihe von Basis–Datentypen. Aber man kann beliebige
komplexe Strukturen als Terme (ein wichtiger Spezialfall sind Listen) in
P ROLOG repräsentieren.
2 Sehr geeignet sind dabei Terme, die X ML–Elemente repräsentieren,
da man dann entsprechende Anfrage–, Transformations– und
Update–Sprachen wie F N Query verwenden kann.
2 Neben Schleifen und Verzweigungen kann man vielfältige, weitere
Kontrollstrukturen auf der Basis von Meta–Prädikaten realisieren.
Typisch sind Konstrukte zum Finden aller Antworten auf eine Anfrage sowie
Filter und Transformationen für Listen.
2 Die (rekursive) Struktur von P ROLOG–Programmen kann gut analysiert
werden, und es können Äquivalenz–Transformationen zur
Programm–Optimierung – speziell für DATALOG – eingesetzt werden.
Prof. Dr. Dietmar Seipel
30
Deduktive Datenbanken
Sommersemester 2012
Kapitel 5: Auswertungsmethoden für DATALOG
2 Man kann DATALOG–Programme leicht in relationen–algebraische
Ausdrücke übersetzen, die man dann sehr effizient auf der Basis relationaler
Datenbanken auswerten kann.
2 Für spezielle, häufig auftretende DATALOG–Programme kann man Anfragen
mit Wavefront–Methoden relationen–algebraisch auswerten.
2 Die Ketten–Normalisierungsmethode kann beliebige DATALOG–Programme
mit genau einer linear–rekursiven Regeln mittels einer graph–basierten
Analyse auf diese Form bringen.
2 Die Magic–Sets–Methode transformiert ein DATALOG–Programm bezüglich
einer Anfrage durch Nachahmung der SLD–Resolution in ein
DATALOG–Programm (Source–to–Source–Transformation), das zielgerichtet
und effizienter bottom–up ausgewertet werden kann.
2 In der Literatur findet man viele weitere Auswertungsmethoden.
Prof. Dr. Dietmar Seipel
31
Deduktive Datenbanken
Sommersemester 2012
Kapitel 6: Default Negation in Logikprogrammen
2 Praktische Anwendungen erfordern Default Negation, Aggregation,
Built–In– und oft auch Meta–Prädikate.
2 Häufig können solche Logikprogramme P stratifiziert ausgewertet werden:
– Falls sich ein Fakt A auf die Negation eines anderen Fakts B bezieht, so
muß zuerst B ausgewertet werden. Erst dann kann man per
Closed–World–Annahme entscheiden, ob die Negation von B gilt.
– Auch im Falle von Meta–Prädikaten versucht man so vorzugehen.
Die so berechnete intuitive Semantik nennt man das perfekte Modell MP .
Ohne Default Negation ist MP das eindeutige minimale Modell.
2 Manchmal bezieht sich ein Fakt auf die Negation eines anderen Fakts,
mit dem es wechselseitig rekursiv ist, und man kann nicht stratifizieren.
Dann arbeitet man mit stabilen Modellen, die durch einen Fixpunkt–Ansatz
definiert werden, oder mit dem wohlfundierten Modell WP .
Prof. Dr. Dietmar Seipel
32
Deduktive Datenbanken
Sommersemester 2012
Anwendungsbeispiel: Studium
Kurse (mit ECTS–Punkten) und Prüfungen:
course(’ADS’,
course(’SWT’,
course(’DB1’,
course(’DB2’,
course(’DDB’,
exam(’Mary’,
exam(’Mary’,
exam(’Mary’,
exam(’Mary’,
under_graduate, 10).
under_graduate, 10).
under_graduate, 5).
graduate, 5).
graduate, 9).
’ADS’,
’SWT’,
’DB1’,
’DB2’,
2007-02-05).
2007-07-05).
2008-02-05).
2009-02-05).
Diese Fakten könnten in der Erweiterung DATALOG∗ von DATALOGnot auch
durch eine Anfrage an eine relationale Datenbank gewonnen werden.
Prof. Dr. Dietmar Seipel
33
Deduktive Datenbanken
Sommersemester 2012
Ein Student kommt an dem Tag ins Hauptstudium (graduate), an dem er
180 ECTS–Punkte im Grundstudium (under_graduate) erreicht:
exam(Student, Course, Level, Date, ECTS) :exam(Student, Course, Date),
course(Course, Level, ECTS).
graduate(Student, Date) :ddbase_aggregate( [Student, max_date(D), sum(E)],
exam(Student, _, under_graduate, D, E),
Tuples ),
member([Student, Date, Total], Tuples),
Total >= 180.
Das Prädikat ddbase_aggregate/3 bestimmt für alle Studierenden das
maximale Datum und die Summe der ECTS–Punkte ihrer Prüfungen.
Prof. Dr. Dietmar Seipel
34
Deduktive Datenbanken
Sommersemester 2012
Wenn man die Studierenden im Grund– bzw. Hauptstudium zählen will,
dann muß man zuerst alle graduate–Studierenden bestimmen;
alle anderen Studierenden sind dann under_graduate:
under_graduate(Student) :student(Student),
not(graduate(Student)).
graduate(Student) :graduate(Student, Date).
Aus technischen Gründen muß man in der Regel für under_graduate mit der
Projektion von graduate auf die Studierenden arbeiten.
Diese stratifizierte Auswertung bestimmt in DATALOG∗ das perfekte Modell.
Prof. Dr. Dietmar Seipel
35
Deduktive Datenbanken
Sommersemester 2012
Das generische Prädikat “count_students/2” wendet “graduate/1”
bzw. “under_graduate/1” auf alle Studierenden an und zählt die Hits:
count_students(Pred, N) :member(Pred, [graduate, under_graduate])
ddbase_aggregate( [length(Student)],
call(Pred, Student),
[[N]] ).
Durch “call(Pred, Student)” wird das Argument Predicate zum
Prädiaktensymbol des Aufrufs “Pred(Student)” gemacht, was man in
P ROLOG direkt nicht schreiben darf.
Nachdem die Liste “Students” aller entsprechenden Studierenden berechnet
wurde, wird mittels “length(Students, N)” deren Länge “N” ermittelt.
Prof. Dr. Dietmar Seipel
36
Deduktive Datenbanken
Sommersemester 2012
Das rekursive Prädikat supports bestimmt Kurse, welche andere Kurse (transitiv)
unterstützen:
supports(C1, C2) :supports(C1, C3),
supports(C3, C2).
supports(’DB1’, ’DDB’).
supports(’SWT’, ’DB1’).
supports(’ADS’, ’SWT’).
Die transitive Verketteng ist eine der häufigsten Formen von Rekursion in
deduktiven Datenbanken.
Um effizient zu sein müssen rekursive Logikprogramme geschickt ausgewertet
werden, da sonst sehr viel Redundanz entstehen kann.
Prof. Dr. Dietmar Seipel
37
Deduktive Datenbanken
Sommersemester 2012
DATALOG–Erweiterungen
2 Aktuelle DATALOG–Systeme erlauben nur konjunktive Regelrümpfe mit
Default Negation und elementaren Built–In–Prädikaten sowie einfache
Aggregation.
2 In der hier verwendeten Erweiterung DATALOG∗ sind beliebige
P ROLOG–Regeln mit beliebigen Meta–Prädikaten erlaubt, die aber – anders
als in P ROLOG – bottom–up ausgewertet werden.
2 Dadurch kann man viele Sachverhalte in DATALOG∗ deutlich komfortabler
ausdrücken als in DATALOG, und man kann externe Tools gut einbinden.
2 Momentan erlaubt DATALOG∗ wie die meisten DATALOG–Systeme nur
stratifizierte Meta–Prädikate – mit Default Negation und Aggregation als
Spezialfällen.
Prof. Dr. Dietmar Seipel
38
Deduktive Datenbanken
Sommersemester 2012
DATALOG∗ vs. P ROLOG
2 Viele DATALOG∗ –Programme – wie z.B. obiges Programm zum Studium –
könnten auch direkt in P ROLOG ausgewertet werden.
2 Die tupel–orientierte P ROLOG–Auswertung wäre allerdings weniger effizient
als die mengen–orientierte DATALOG∗ –Auswertung.
2 Außerdem würde die P ROLOG–Auswertung nicht mehr terminieren,
sobald die supports–Relation zyklisch würde.
2 Manche Anwendungen – wie z.B. Diagnose–Systeme – erfordern die
mengen–orientierte DATALOG∗ –Auswertung.
Prof. Dr. Dietmar Seipel
39
Deduktive Datenbanken
Sommersemester 2012
Kapitel 7: Disjunktive Logikprogramme (DLPs)
2 DLPs erlauben Disjunktion in Regelköpfen zur Formulierung unsicheren
Wissens. Typische Beispiele sind unsichere Diagnoseregeln,
Graphenprobleme und kombinatorische Probleme, wie etwa Spiele.
2 Die Semantik eines Negations–freien DLPs ist durch die minimalen
Herbrandmodelle gegeben, die mittels der beiden Verallgemeinerungen TPs
und TPi des TP –Operators bestimmt werden können.
2 Wenn zusätzlich Default Negation auftritt, so werden wieder die stabilen
bzw. (als Erweiterung) die partiell–stabilen Modelle herangezogen:
– Ohne Negation entsprechen beide den minimalen Modellen.
– Ohne Disjunktion ist WP das kleinste partiell–stabile Modell.
– Falls zuätzlich die Negation stratifiziert ist, so ist MP das eindeutige
stabile bzw. partiell–stabile Modell.
Prof. Dr. Dietmar Seipel
40