Vorlesung - pub.informatik.uni-wuerzburg.de · Deduktive Datenbanken Sommersemester 2012 Auch das...

Vorlesung

Deduktive Datenbanken

Prof. Dr. Dietmar Seipel

Universität Würzburg

Sommersemester 2012

Deduktive Datenbanken Sommersemester 2012

Inhaltsverzeichnis

1 Datenbanken und DATALOG 41

1.1 Grundbegriffe des relationalen Datenmodells. . . . . . . . . . . 42

1.1.1 Relationen und Relationenschemata. . . . . . . . . . . . 42

1.1.2 Relationale Anfragesprachen. . . . . . . . . . . . . . . . 48

1.2 Die deduktive Datenbanksprache DATALOG . . . . . . . . . . . . 58

1.2.1 Regeln und Fakten. . . . . . . . . . . . . . . . . . . . . 64

1.2.2 Integritätsbedingungen und Default Negation. . . . . . . 88

1.2.3 BUILT–IN–Prädikate . . . . . . . . . . . . . . . . . . . . 97

1.2.4 Aggregationsfunktionen. . . . . . . . . . . . . . . . . . 103

Prof. Dr. Dietmar Seipel 1


2 Die deklarative Programmiersprache PROLOG 110

2.1 Grundlegende Strukturen. . . . . . . . . . . . . . . . . . . . . . 116

2.1.1 Klauseln . . . . . . . . . . . . . . . . . . . . . . . . . . 119

2.1.2 Datentypen. . . . . . . . . . . . . . . . . . . . . . . . . 136

2.2 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 PROLOG–Datenbank. . . . . . . . . . . . . . . . . . 215

2.4 Datenbanken und PROLOG . . . . . . . . . . . . . . . . . . . . . 241

2.4.1 ODBC–Zugriff auf eine relationale Datenbank. . . . . . . 243

2.4.2 Das deduktive Mini–DBMS DDBASE . . . . . . . . . . . 249



2.5 GUI–Programmierung in XPCE–PROLOG . . . . . . . . . . . . . 278

2.6 Datenstrukturen, Kontrollstrukturen und Algorithmen. . . . . . . 289

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

2.7 Vergleich mit DATALOG . . . . . . . . . . . . . . . . . . . . . . 353



3 Definite Logikprogramme 380

3.1 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

3.2 Die modelltheoretische Semantik. . . . . . . . . . . . . . . . . . 440

3.2.1 Herbrandinterpretationen und Herbrandmodelle. . . . . . 445

3.2.2 Logische Konsequenzen. . . . . . . . . . . . . . . . . . 460

3.3 Beweistheorie: Bottom–Up. . . . . . . . . . . . . . . . . . . . . 471

3.3.1 Der KonsequenzoperatorTP . . . . . . . . . . . . . . . . 474

3.3.2 Iteration desTP –Operators. . . . . . . . . . . . . . . . . 492



3.3.3 Forward Chaining: Beweisbäume. . . . . . . . . . . . . 515

3.3.4 Der verallgemeinerte KonsequenzoperatorTPbu,Ptd. . . . 519

3.4 Fixpunkttheorie auf Partialordnungen. . . . . . . . . . . . . . . 532

3.5 Beweistheorie: Top–Down. . . . . . . . . . . . . . . . . . . . . 533

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



4 Datenstrukturen und Programmstrukturen für Logikprogra mme 591

4.1 Datenstrukturen in PROLOG . . . . . . . . . . . . . . . . . . . . 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

4.2 Kontrollstrukturen und Meta–Prädikate von PROLOG . . . . . . . 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



5 Auswertungsmethoden und Programmoptimierung für DATALOG 779



6 Default Negation und normale Logikprogramme 780

6.1 DATALOGnot – DATALOG mit Default Negation. . . . . . . . . . 793

6.1.1 Syntax und Semantik (Modelltheorie). . . . . . . . . . . 793

6.1.2 Die Closed–World–Annahme. . . . . . . . . . . . . . . 800

6.2 Stratifizierte Auswertung von DATALOGnot . . . . . . . . . . . . 804

6.2.1 Abhängigkeitsgraphen und Stratifizierung. . . . . . . . . 805

6.2.2 Die KonsequenzoperatorenTP undT ′

P . . . . . . . . . . 826

6.2.3 Das perfekte Modell. . . . . . . . . . . . . . . . . . . . 841

6.2.4 Ontologie–Analyse in DATALOG∗ . . . . . . . . . . . . . 872

6.3 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. . . . . . . . . . . . . . . . . 932Prof. Dr. Dietmar Seipel 8


7 Disjunktive Logikprogramme 978

Literatur 979

Index 981



Vorwort

Deduktive Datenbanken entstehen durch die Integration von

2 Logikprogrammierungund

2 Datenbanktechnologie.

Die darauf aufbauendenDBLP–Systemekönnen z.B.

2 komplexe, wissensbasierte Systeme,

2 intelligente, entscheidungsunterstützende Systeme (Expertensysteme) und

2 Semantic Web–Anwendungen

unterstützen.



Logikprogrammierung und Datenbanken

Logikprogrammierung in PROLOG:

2 Vereinfachung von Techniken des Theorembeweisens 1970

−→ effiziente und einfachere Programmierung

relationales Datenmodell:

2 Vereinfachung des hierarchischen und des Netzwerkdatenmodells

−→mengenorientierte, deklarative Datenmanipulation

kommerzielle Nutzung: 1980

Logikprogrammierung in DATALOG:

2 mächtige, deklarative Datenbankanfragesprache seit 1980

−→ Anfrageoptimierung möglich



Auch das japanische Fifth–Generation–Projekt hat DBLP–Systeme für

Anwendungen aus derkü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.



Architektur eines DBLP–Systems

��

��



Beispiel: Familienstammbaum

George Elizabeth

Philip

Charles

Diana

Anne

Andrew

Edward

William

Harry

-

-

-

-

- -

-

Der Familienstammbaum umfaßt 4 Generationen; Frauen sind in Rot, Männer inBlau angezeigt.



Der Familienstammbaum kann in einer Tabelle (Relation) PARENT einer

relationalen Datenbank gespeichert werden:

PARENT

NAME PARENT

Elizabeth George

Charles Elizabeth

William Charles

. . . . . .

GRANDPARENT

NAME GRANDPARENT

Charles George

William Elizabeth

. . . . . .

Die Großeltern (Tabelle GRANDPARENT) können in SQL berechnet werden:

SELECT P1.NAME , P2.PARENT

FROM PARENT P1, PARENT P2

WHERE P1.PARENT = P2.NAME



Die Vorfahren einer Person können in SQL nicht berechnet werden:

ANCESTOR

NAME ANCESTOR

William George

. . . . . .

In einem DBLP–System kann man diese aber mittelsrekursiver

DATALOG–Regeln berechnen:

ancestor(X ,Z )← parent(X ,Z ),

ancestor(X ,Z )← parent(X ,Y ) ∧ ancestor(Y ,Z ).

Eine PersonZ ist ein Vorfahre einer PersonX,

2 falls Z ein Elternteil vonX ist (erste Regel), oder

2 falls Z ein Vorfahre eines ElternteilsY vonX ist (zweite Regel).

X

Y

Z

parent

ancestor

ancestor

6

6I



Anwendungsbereiche von DBLP

2 Datenbanken mit komplexen Strukturen (Hierarchien, XML )

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.)



Wissensbasiertes System

Wir verwenden DBLP–Systeme z.B. zur Realsierung der Wissensbasis sowie der

Inferenz– und der Erklärungskomponente von wissensbasierten Systemen.



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 (SWRL) baut Regeln aus der

Logikprogrammierung in OWL–Ontologien ein.

Deduktionsaufgaben:

2 Unterstützung derAnfrageauswertung;

2 in derWissensmodellieung: Analyse der Struktur von Ontologien im

Hinblick auf Anomalien.



DBLP–Anwendungen in Würzburg

2 Software Engineering:Analyse und Refaktorisierung von

– Programm–Quellcode (PROLOG, JAVA , PHP, COBOL),

– Datenbankanwendungen (Schema und Embedded SQL–Code) und

– Ontologien (OWL, SWRL) im Semantic Web

2 Bio–Informatik:Management komplexer XML–Daten,

z.B. im Rahmen der Pathway–Analyse

2 Sprachwissenschaften:

Parsing, Analyse und Aufbereitung von Textdaten, oft in XML

2 Analyse–Tools:

– Taktikanalyse imSport(Tennis, Basketball)

– Stocktool: Chartanalyse und Visualisierung



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



Datenintegration

)

? � ? ^

?

?SQL

DATALOG∗

JAVA PROLOG

Datenquellen

DB–Anfragesprachen

Programmiersprachen

RDB XML ,OWL

Excel(.csv)

Text

Abstraktion

Teile der Datenbankprogrammierung erfolgen deklarativ inDATALOG anstelle

prozedural in JAVA mit Embedded SQL.



PROLOG

Man kann mit PROLOG (im Gegensatz zur “reinen” Logikprogrammierung) auch

2 prozedural

2 mit Seiteneffekten und

2 mit globalen Variablen (realisiert mit Hilfe vonassert undretract)

programmieren.

PROLOG–Implementierungen wie – z.B. SWI/XPCE–PROLOG – besitzen

umfangreiche Programmbibliotheken und Erweiterungen:

2 Datenstrukturen und Algorithmen, Kombinatorik,

2 Datenbank– und Web–Programmierung,

2 komfortable GUI–Programmierung, etc.



Die einfache Handhabung vonTermenalsDatenstrukturund die mächtige,

eingebauteKontrollstrukturdesBacktrackingssind Features, die PROLOG im

Vergleich zu anderen Programmiersprachen auszeichnen.

PROLOG 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 PROLOG und DATALOG sind deklarative Sprachen, mit denen man auf

Datenbanken und XML–Dokumenten operieren kann.

2 Relationen und komplexe Objekte (wie z.B. XML–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.



Datenbankprogrammierung

2 Man kann aus PROLOG heraus über eine SQL–Schnittstelle mittels ODBC

auf relationale Datenbanken zugreifen.

2 Die Verbindung von PROLOG und DATALOG erlaubt eine sehr komfortable

Programmierung von Datenbankanwendungen.

2 Der von Embedded SQL (JDBC, ODBC) bekannte Mismatch zwischen

– der Datenbanksprache SQL und

– der Host–Programmiersprache (z.B. JAVA oder C++)

kann hier vermieden werden.



Bei der Datenbankprogrammierung mit Embedded SQL werden deklarative

SQL–Statements in prozeduralen Code (z.B. JAVA ) eingebunden.

In DBLP–Systemen wird der prozedurale Code durch PROLOG ersetzt,

das dann deklarativ über DATALOG∗–Regeln und SQL–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.

SQL JAVA Embedded SQLY

�SQL DATALOG∗ PROLOG DBLP

RDB



APIs und Tools für PROLOG

2 SWI–PROLOG–Libraries (/usr/lib/pl-x.y.z/library):

lists.pl, ordsets.pl, ugraphs.pl, odbc.pl, sgml.pl, . . . ,

andere PROLOG–Libraries: loops.pl, . . .

2 XPCE–PROLOG–Libraries für SWI–PROLOG:

(/usr/lib/pl-x.y.z/xpce/prolog/lib):

WWW, HTML , Charts, . . .

2 DISLOG Developers’ Kit (DDK) für SWI–PROLOG::

Units (~DisLog/sources):

– basic_algebra, nm_reasoning, xml, databases,

– development, stock_tool, projects, linguistics, biology_and_medicine.

SWI–PROLOG ist in C geschrieben.



DDK (D ISL OG Developers’ Toolkit)

eine große PROLOG–Bibliothek mit Algorithmen und Datenstrukturen für

verschiedenste Anwendungen, einschließlich Datenbanken, nicht–montones

Schließen (NMR), WWW, XML und Software Engineering

2 DDBASE:

ein PROLOG–basiertes deduktives Datenbanksystem mit Anbindung an

relationale Datenbanken (MySQL) und verschiedene ASP–Systeme

2 FNQuery/ PL4XML:

eine deklarative, PROLOG–basierte XML–Anfrage–, Transformations– und

Update–Sprache

2 DATALOG∗ :

eine mit PROLOG verwobene Erweiterung von DATALOG



Andere Systeme zur Logikprogrammierung

2 deduktive Datenbanksysteme:

CORAL, LDL, Lola, ADITI

2 Systeme für Answer Set Programming (ASP):

dlv, Smodels, XSB, Lola,Cmodels, ASAT

2 PROLOG–Systeme:

SWI, SICStus, Visual PROLOG, IF PROLOG, Mercury

2 Constraint–logische Programmierung (CLP):

Eclipse, Chip, Minerva

2 Funktional–logische Programmierung (FLP):

Curry



Themengebiete der Vorlesung

2 Grundlagen von DATALOG und PROLOG

2 das deduktive Datenbanksystem DDBASE

2 FNQuery, DATALOG∗

2 effiziente Auswertung von Logikprogrammen

2 weitere Sprachkonstrukte:

– Built–In–Prädikate, Aggregationsfunktionen

– Negation und Disjunktion

−→ Answer Set Programming (ASP), DISLOG

2 Anwendungen



Kapitel 1 und 2: DATALOG und PROLOG

DATALOG und PROLOG sind – auf einem Domänenkalkül basierende – logische

Programmiersprachen, die sich syntaktisch sehr ähneln undsich semantisch (in

der Auswertung) unterscheiden.

2 DATALOG ist eine deklarative Datenbanksprache.

2 Es erweitert die relationale Datenbanksprache SQL (Tupelkalkül) um

Rekursion. Nicht–rekursive DATALOG–Anfragen kann man leicht nach SQL

übersetzen – und umgekehrt.

2 DATALOG kann – ähnlich wie SQL – 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.



PROLOG ist eine deklarative Programmiersprache:

2 Wegen ihrer Kompaktheit und weitgehenden Ungetyptheit kann sie sehr gut

alsSkripting–Spracheverwendet werden.

2 Konstruktehöherer Ordnung(Funktionale) erlauben sehr viel Abstraktion

und selbst–definierte Kontrollstrukturen.

2 Die Programmierung istrelationalmit eingebautemBacktracking, und es

wird häufigRekursionverwendet.

Im Vergleich zu DATALOG

2 bietet PROLOG deutlich mehr syntaktische Features, aber dafür weniger

semantische Alternativen;

2 ist die tupel–orientierte Auswertung von PROLOG weniger effizient und

terminiert für rekursive Programme manchmal nicht.



PROLOG–Programmierung

2 Wir zeigen auf, wie PROLOG in Verbindung mit relationalen Datenbanken

benutzt werden kann.

2 Zur Datenhaltung in PROLOG selbst kann die interne PROLOG–Datenbank

verwenden. Auf deren Basis wurde auch das deduktive

Mini–Datenbanksystem DDBASE entwickelt.

2 XPCE–PROLOG bietet viele weitere Features (GUI–,

Web–Programmierung), die noch nicht im Sprachstandard vonPROLOG

enthalten sind.

2 Wir zeigen verschiedene Anwendungen von PROLOG: Sortieren und Suchen

(auch in Graphen), Analyse hierarchischer Daten, medizinische Diagnose.

Für praktische Anwendungen ist oft die Verbindung von PROLOG, DATALOG und

Datenbanken (relational oder XML ) sehr sinnvoll (DBLP–Systeme).



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 TypC1 enthältQ2 Komponenten vom TypC2.

a

b c

d e f

2 3

4 5 6 7

R

R R

components(a, b:2).

components(a, c:3).

components(b, d:4).

components(b, e:5).

components(c, e:6).

components(c, f:7).

Dann hat ein komplexes Teil vom Typa z.B. folgende Stückliste:

[d:8, e:28, f:21].



Die persistente Speicherung und Verwaltung der Teilehierarchie kann in einer

relationalen Datenbank erfolgen, aus der dann die Faktencomponents(C1,

C2:Q2) extrahiert werden:

a

b c

d e f

2 3

4 5 6 7

R

R R

COMPONENTS

C1 C2 Q2

a b 2

a c 3

b d 4

b e 5

c e 6

c f 7

Das in PROLOG implementierte deduktive Datenbanksystem DDBASE kann über

ODBC auf relationale Datenbanken zugreifen.



Die Stückliste

[d:8, e:28, f:21]

eines komplexen Teils vom Typa wird wie folgt berechnet:

a→ [d:(8 = 2 · 4), e:(28 = 2 · 5 + 3 · 6), f:(21 = 3 · 7)]

b→ [d:4, e:5] c→ [e:6, f:7]

d→ [d:1] e→ [e:1] f → [f:1]

2 3

4 5 6 7

R

R R



Die Berechnung der Stücklisten für beliebig komplexe (tiefe) Teile ist nur in

Embedded SQL möglich, nicht aber in SQL. In PROLOG 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 FallsC1 keine Komponenten hat, so wirdC1:1 berechnet.

2 Andernfalls ermitteltddbase_aggregation/3 für alle Komponenten

Ca:Qa vonC1 wieviele TeileCb:Qb diese enthalten und berechnet die

SummeQ2 über alleQa*Qb.



Kapitel 3: Syntax und Semantik (Theorie)

2 Die syntaktischen Grundbausteine von DATALOG und PROLOG 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 aufHyperresolution– zur Bestimmung aller

ableitbaren Fakten verwendet.

2 Für PROLOG ist die Top–Down–Inferenzmethode derSLDNF–Resolution

die grundlegenede Auswertungsmethode für Anfragen; allerdings muß sie

dann um außer–logische Features mit Seiteneffekten erweitert werden.



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

PROLOG repräsentieren.

2 Sehr geeignet sind dabei Terme, die XML–Elemente repräsentieren,

da man dann entsprechende Anfrage–, Transformations– und

Update–Sprachen wie FNQuery verwenden kann.

2 Neben Schleifen und Verzweigungen kann man vielfältige, weitere

Kontrollstrukturenauf der Basis von Meta–Prädikaten realisieren.

Typisch sind Konstrukte zum Finden aller Antworten auf eineAnfrage sowie

Filter und Transformationen für Listen.

2 Die (rekursive) Struktur von PROLOG–Programmen kann gut analysiert

werden, und es können Äquivalenz–Transformationen zur

Programm–Optimierung – speziell für DATALOG – eingesetzt werden.



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.



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 LogikprogrammeP stratifiziertausgewertet werden:

– Falls sich ein FaktA auf die Negation eines anderen FaktsB bezieht, so

muß zuerstB ausgewertet werden. Erst dann kann man per

Closed–World–Annahmeentscheiden, ob die Negation vonB gilt.

– Auch im Falle von Meta–Prädikaten versucht man so vorzugehen.

Die so berechnete intuitive Semantik nennt man dasperfekteModell MP .

Ohne Default Negation istMP das eindeutige minimale Modell.

2 Manchmal bezieht sich ein Fakt auf die Negation eines anderen Fakts,

mit dem es wechselseitigrekursivist, und man kann nicht stratifizieren.

Dann arbeitet man mitstabilenModellen, die durch einen Fixpunkt–Ansatz

definiert werden, oder mit demwohlfundiertenModellWP .



Anwendungsbeispiel: Studium

Kurse (mit ECTS–Punkten) und Prüfungen:

course(’ADS’, under_graduate, 10).

course(’SWT’, under_graduate, 10).

course(’DB1’, under_graduate, 5).

course(’DB2’, graduate, 5).

course(’DDB’, graduate, 9).

exam(’Mary’, ’ADS’, 2007-02-05).

exam(’Mary’, ’SWT’, 2007-07-05).

exam(’Mary’, ’DB1’, 2008-02-05).

exam(’Mary’, ’DB2’, 2009-02-05).

Diese Fakten könnten in der Erweiterung DATALOG∗ von DATALOGnot auch

durch eine Anfrage an eine relationale Datenbank gewonnen werden.



Ein Student kommt an dem Tag ins Hauptstudium (graduate), andem 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ädikatddbase_aggregate/3 bestimmt für alle Studierenden das

maximale Datum und die Summe der ECTS–Punkte ihrer Prüfungen.



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∗ dasperfekteModell.



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

PROLOG direkt nicht schreiben darf.

Nachdem die Liste “Students” aller entsprechenden Studierenden berechnet

wurde, wird mittels “length(Students, N)” deren Länge “N” ermittelt.



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 vonRekursionin

deduktiven Datenbanken.

Um effizient zu sein müssen rekursive Logikprogramme geschickt ausgewertet

werden, da sonst sehr viel Redundanz entstehen kann.



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

PROLOG–Regeln mit beliebigen Meta–Prädikaten erlaubt, die aber –anders

als in PROLOG – 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.



DATALOG ∗ vs. PROLOG

2 Viele DATALOG∗–Programme – wie z.B. obiges Programm zum Studium –

könnten auch direkt in PROLOG ausgewertet werden.

2 Die tupel–orientierte PROLOG–Auswertung wäre allerdings weniger effizient

als die mengen–orientierte DATALOG∗–Auswertung.

2 Außerdem würde die PROLOG–Auswertung nicht mehr terminieren,

sobald die supports–Relation zyklisch würde.

2 Manche Anwendungen – wie z.B. Diagnose–Systeme – erforderndie

mengen–orientierte DATALOG∗–Auswertung.



Kapitel 7: Disjunktive Logikprogramme (DLPs)

2 DLPs erlauben Disjunktion in Regelköpfen zur Formulierungunsicheren

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 VerallgemeinerungenT sP

undT iP desTP –Operators bestimmt werden können.

2 Wenn zusätzlich Default Negation auftritt, so werden wieder diestabilen

bzw. (als Erweiterung) diepartiell–stabilenModelle herangezogen:

– Ohne Negation entsprechen beide den minimalen Modellen.

– Ohne Disjunktion istWP das kleinste partiell–stabile Modell.

– Falls zuätzlich die Negation stratifiziert ist, so istMP das eindeutige

stabile bzw. partiell–stabile Modell.


Vorlesung - pub.informatik.uni-wuerzburg.de · Deduktive Datenbanken Sommersemester 2012 Auch das...

Documents

Transcript of Vorlesung - pub.informatik.uni-wuerzburg.de · Deduktive Datenbanken Sommersemester 2012 Auch das...