Entwurf und Implementierung einer Kompo- nente zur ... · Kapitel1 Einleitung...

Rheinische Friedrich-Wilhelms-Universität Bonn Institut für Informatik

Abteilung III

Diplomarbeit

Entwurf und Implementierung einer Kompo-nente zur Anfragebearbeitung in einem

deduktiven Datenbanksystem

Svitlana Lobko 6. Juli 2004

Erstgutachter: Professor Dr. R. Manthey

Inhaltsverzeichnis

1 Einleitung 1

2 Deduktive Datenbanken 5

2.1 Einfuhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Alphabet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 Darstellung von Fakten und Regeln in Datalog . . . . . . . . 8

2.2.3 Erweiterung von Datalog um”Built In“-Konzepte . . . . . . . 12

2.3 DDL und DML fur Datalog . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1 Die Datendefinitionssprache (DDL) . . . . . . . . . . . . . . . 14

2.3.2 Die Datenmanipulationssprache (DML) . . . . . . . . . . . . . 16

2.4 Semantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.1 Semantik von deduktiven Regeln . . . . . . . . . . . . . . . . 17

2.4.2 Semantik von Anfragen . . . . . . . . . . . . . . . . . . . . . . 20

2.5 Architektur eines deduktiven Datenbanksystems . . . . . . . . . . . . 21

3 Darstellung von Datalog-Regeln in Java 25

3.1 Ziele und Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1 Vorbereitende Analyse . . . . . . . . . . . . . . . . . . . . . . 27

3.2.2 Analyse der Anforderungen an Regeln . . . . . . . . . . . . . 30

3.2.3 Analyse der Anforderungen an Literale . . . . . . . . . . . . . 31

3.2.4 Analyse der Anforderungen an Argumente . . . . . . . . . . . 33

3.3 Entwurf und Implementierung der Datenstruktur . . . . . . . . . . . 35

3.3.1 Objektorientierte Eigenschaften von Java . . . . . . . . . . . . 35

3.3.2 Modellierung der Datenstruktur . . . . . . . . . . . . . . . . . 36

i

ii INHALTSVERZEICHNIS

4 Anfragebearbeitung via”Magic Sets“-Methode 45

4.1 Die”Magic Sets“-Methode . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.1 Motivation und Prinzip . . . . . . . . . . . . . . . . . . . . . . 45

4.1.2 Die”Magic Sets“-Transformation . . . . . . . . . . . . . . . . 47

4.2 Uberblick der Optimierungstechniken . . . . . . . . . . . . . . . . . . 55

4.2.1”Supplementary Magic Sets“-Transformation . . . . . . . . . . 56

4.2.2 Die Steuerung und Optimierung der SIP-Auswahl . . . . . . . 60

4.2.3 Effiziente Auswertung von linearer Rekursionen . . . . . . . . 65

4.2.4 Effiziente Materialisierung von”Magic Sets“-

transformierten Regeln . . . . . . . . . . . . . . . . . . . . . . 73

4.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5 Entwurf und Implementierung des Regelcompilers 79

5.1 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.1.1 Aufgaben und Ziele . . . . . . . . . . . . . . . . . . . . . . . . 80

5.1.2 Regelkompilierungsprozess . . . . . . . . . . . . . . . . . . . . 81

5.2 Die Architektur des Regelcompilers . . . . . . . . . . . . . . . . . . . 82

5.2.1 Entwurfsprinzipien . . . . . . . . . . . . . . . . . . . . . . . . 82

5.2.2 Der Aufbau des Regelcompilers . . . . . . . . . . . . . . . . . 83

5.2.3 Die Arbeitsweise . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.3 Der Uberblick uber die Module des Regelcompilers . . . . . . . . . . 89

5.3.1 Steuerungsklasse RulesCompiler . . . . . . . . . . . . . . . . . 90

5.3.2 Adornments-Propagierung . . . . . . . . . . . . . . . . . . . . 90

5.3.3 Transformations-Methoden . . . . . . . . . . . . . . . . . . . . 97

6 Weitere implementierte Komponenten 103

6.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.2 Graphische Schnittstelle zum Regelcompiler . . . . . . . . . . . . . . 105

6.3 Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7 Zusammenfassung 111

Literaturverzeichnis 115

Abbildungsverzeichnis

2.1 Architektur eines deduktiven Datenbanksystems . . . . . . . . . . . . 22

3.1 Klassendiagramm: Regeln . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2 Klassendiagramm: Literale . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3 Klassendiagramm: Argumente . . . . . . . . . . . . . . . . . . . . . . 42

3.4 Klassendiagramm: Datenstruktur . . . . . . . . . . . . . . . . . . . . 43

4.1 Regelkompilierung: Komponenten der DBMS zur fixpunktbasiertenAnfragebeantwortung . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2 Prinzipielle Aufbau eines AND/OR-SIP Graphen . . . . . . . . . . . 61

5.1 Die Schnittstelle zum Regelcompiler . . . . . . . . . . . . . . . . . . . 83

5.2 Interface CompilerInterface . . . . . . . . . . . . . . . . . . . . . . . 83

5.3 Architektur des Regelcompilers . . . . . . . . . . . . . . . . . . . . . 85

5.4 Aktivitatsdiagramm: Auswahl einer geeigneten Kompilierungstechnikim Regelcompiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.5 Aktivitatsdiagramm: Steuerung der Module bei der Regelkompilierung 89

5.6 Klassendiagramm: Steuerungsklasse RulesCompiler . . . . . . . . . . 90

5.7 Klassendiagramm: Das Modul Adornments-Propagierung . . . . . . . 91

5.8 Ablauf der Adornments-Propagierung bezuglich einer Anfrage . . . . 93

5.9 Klassendiagramm: Das Modul Transformations-Methoden . . . . . . . 98

5.10 Ablauf der”Magic Sets“-Transformation . . . . . . . . . . . . . . . . 100

5.11 Ablauf der”Supplementary Magic Sets“-Transformation . . . . . . . 101

5.12 Ablauf der”Multilinearen“-Transformation . . . . . . . . . . . . . . . 102

6.1 Architektur der Testumgebung . . . . . . . . . . . . . . . . . . . . . . 104

iii

iv ABBILDUNGSVERZEICHNIS

6.2 Graphische Schnittstelle zum Regelcompiler . . . . . . . . . . . . . . 106

6.3 Klasse Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6.4 Beispiel einer Regel im internen Regelformat . . . . . . . . . . . . . . 109

Kapitel 1

Einleitung

Fast alle Datenbanksysteme erlauben die Modellierung und Verarbeitung von abge-leiteten Informationen und mussen somit als ein deduktives Datenbanksystem be-trachtet werden. Ein wichtiges Merkmal von deduktiven Datenbanksystemen bestehtdarin, dass sie neben explizit gespeicherten Daten auch eine Regelmenge besitzen,mit deren Hilfe eine Menge von ableitbaren Daten spezifiziert wird. In der Daten-bankforschung wird zur Regeldarstellung die deklarative Anfrage und RegelspracheDatalog verwendet. Die Verarbeitung von Informationen, zum Beispiel bei der An-fragebeantwortung oder Anderungspropagierung, erfolgt durch eine spezielle Infe-renzkomponente, die von einem deduktiven Datenbankmanagementsystem (DBMS)zur Verfugung gestellt wird. Solche regelbasierte Datendarstellung und die Moglich-keit aus explizit gespeicherten Daten automatisch weitere Daten zu erzeugen, machtsie fur viele Anwendungen besonders attraktiv, bei denen große ableitbare Daten-mengen effizient verwaltet werden sollen.

In modernen relationalen Datenbanksystemen werden ublicherweise mit derDatendefinitionssprache SQL Sichten zur Darstellung abgeleiteter Informationen(”Views“ analog zu deduktiven Regeln) definiert. In SQL werden diese Sichten als

spezielle Anfragen definiert. In kommerziellen Datenbanksystemen ist allerdings dieDefinition und Auswertung von rekursiven Sichten bis jetzt nur beschrankt imple-mentiert. In der Forschung uber deduktive Datenbanken ist die effiziente Anfrage-bearbeitung ein intensiv behandeltes Thema und es existieren viele Methoden zurAnfragebearbeitung, die auch rekursive Falle effizient behandeln. Oft handelt essich dabei um transformationsbasierende Ansatze, die unabhangig von anderen Op-timierungstechniken implementiert werden konnen. Die Ergebnisse dieser Forschungwurden ublicherweise in Datalog prasentiert, da diese Datenbanksprache durch ihresyntaktische Einfachheit zur Darstellung solcher Konzepte geeignet ist. Deswegenist eine prototypische Implementierung und Untersuchung eines deduktiven Daten-banksystems, fur die Datalog als eine syntaktische Grundlage dient, wichtig.

1

2 KAPITEL 1. EINLEITUNG

Die”Magic Sets“-Methode ist dabei eine der wichtigsten Optimierungstechniken,

die auf Regeltransformation und Fixpunktberechnung (”Bottom Up“-Auswertung)

basiert. Ein wesentlicher Schritt bei diesem Ansatz ist also die Regelkompilierung.Die Hauptidee solcher Regelkompilierung besteht darin, die speziellen Eigenschafteneiner gegebenen Anfrage auszunutzen, indem die Regeln in eine effizient auswertbareRegelmenge bezuglich dieser Anfrage transformiert werden. Dadurch werden nurdie fur die Anfrage relevanten Antworten bei der nachfolgenden Materialisierungerzeugt.

Das wesentliche Ziel dieser Diplomarbeit ist der Entwurf und die Implementie-rung eines Regelcompilers, welcher das Konzept der

”Magic Sets“-Transformation

durch geeignete Methoden realisiert. Die Implementierung erfolgt in der Program-miersprache Java, deren Eigenschaften wie die Plattformunabhangigkeit, die Un-terstutzung objektorientierter Programmierung oder die dynamische Speicherver-waltung viele Vorteile bringen. Die Plattformunabhangigkeit erlaubt, die auf einerbeliebigen Umgebung erzeugten Java-Programme auf verschiedenen Rechnersyste-men zum Laufen zu bringen und die Objektorientierung bietet die Moglichkeit,Programme aus unabhangigen Komponenten zusammenzustellen. Der so erzeug-te Regelcompiler kann spater ohne großen Aufwand in eine prototypische Imple-mentierung einer deduktiven Datenbank als eine fur die Anfrageoptimierung ver-antwortliche Komponente integriert werden. Dazu wird eine spezielle Schnittstelleimplementiert.

Eine daraus resultierende Aufgabe dieser Diplomarbeit besteht darin, die in Da-talog formulierten Regeln durch eine geeignete Datenstruktur in Java darzustellen.Bei dem Entwurf und der Implementierung der Datenstruktur mussen syntakti-sche Merkmale von Datalog-Regeln berucksichtigt werden. Die objektorientiertenKonzepte der Programmiersprache Java eignen sich sehr gut zum Modellieren derunterschiedlichen Bestandteile von Regeln in Form von Hierarchien.

In der Forschungsliteratur existieren neben der”Magic Sets“-Methode weitere

Optimierungstechniken zur effizienten Anfragebearbeitung. In dieser Arbeit werdenauch andere auf Regeltransformation basierende Ansatze untersucht. Anschließendwerden solche Optimierungstechniken implementiert, die zur weiteren Verbesserungder

”Magic Sets“-transformierten Regeln geeignet sind. In erster Linie sind solche

Ansatze interessant, die auch auf Regelmodifikation basieren und die mit dem”Ma-

gic Set“-Ansatz kompatibel sind.

Die Arbeit ist wie folgt gegliedert:

Im Kapitel 2 werden die Grundlagen deduktiver Datenbanken erlautert. Außer-dem wird die Syntax und die Semantik deduktiver Regeln sowie weitere Konzepteeines deduktiven Datenbanksystems auf der Basis von der Datenbanksprache Data-log dargestellt.

3

Im Kapitel 3 wird der Entwurf und die Implementierung einer Datenstrukturzur Darstellung von Datalog-Regeln in der Programmiersprache Java vorgestellt.Zunachst werden unterschiedliche Bestandteile von Regeln identifiziert und ihrewichtigen Eigenschaften motiviert. Danach werden alle identifizierten Bestandtei-le mit deren Eigenschaften modelliert.

Im Kapitel 4 wird die Anfragebearbeitung mit Hilfe der”Magic Sets“-Methode

betrachtet. Dabei werden wichtige Prinzipien der”Magic Sets“-Transformation be-

schrieben. Daruber hinaus werden mogliche Optimierungsansatze vorgestellt undbezuglich ihrer Verwendung fur den Regelcompiler diskutiert.

Im Kapitel 5 wird der Entwurf und die Implementierung des Regelcompilersdargestellt. Es werden wichtige Module des realisierten Regelcompilers detailliertbeschrieben und die dabei getroffenen Entscheidungen vorgestellt und begrundet.

Im Kapitel 6 werden weitere zum Testen der Funktionalitaten des Regelcompi-lers implementierte Komponenten, wie die graphische Oberflache zum Regelcompilerund der Parser, kurz dargestellt.

4 KAPITEL 1. EINLEITUNG

Kapitel 2

Deduktive Datenbanken

In diesem Kapitel werden die Grundlagen von deduktiven Datenbanken vorgestellt.Zunachst erfolgt eine allgemeine Einfuhrung in das Gebiet. Es werden die Grundbe-griffe regelbasierter Datendarstellung beschrieben. Im Abschnitt 2.3 wird die Syntaxvon deduktiven Regeln und weitere Konzepte eines deduktiven Datenbanksystemsauf der Basis von der Datenbanksprache Datalog dargestellt. Abschnitt 2.4 befasstsich mit der Semantik deduktiver Datenbanken. Insbesondere wird die fixpunktba-sierte Semantik von Datalog-Regeln und Anfragen betrachtet. Im Abschnitt 2.5 wirdauf die Struktur eines deduktiven Datenbanksystem eingegangen. Die Darstellungvon deduktiven Datenbanken in diesem Kapitel richtet sich nach [7][15][14][6][11][9].

2.1 Einfuhrung

Aus der Motivation heraus, traditionelle und neue Datenbankanwendungen besserbehandeln zu konnen, untersuchte man Moglichkeiten zur Erweiterung von kon-ventionellen Datenbanksystemen bezuglich der Modellierung und Verarbeitung vonableitbaren Informationen. So entstand das Forschungsgebiet

”deduktive Datenban-

ken“, in dem Konzepte von traditionellen Datenbanksystemen und logischer Pro-grammierung kombiniert werden. Deduktive Datenbanksysteme bieten regelbasierteSprachen zur Darstellung von Informationen und Deduktionsmethoden zur Verar-beitung dieser Informationen.

Somit besteht eine deduktive Datenbank sowohl aus explizit gespeicherten Datenals auch aus einer Menge von Regeln, die ableitbare Daten spezifizieren. Diese Regelnsind deklarative Ausdrucke, die zur Ableitung von Informationen aus Basisdatendienen. Die Basisdaten (oder Fakten) werden als extensionale Datenbank (EDB)und die ableitbaren Fakten als intensionale Datenbank (IDB) bezeichnet. Solcheregelbasierte Datendarstellung bringt viele Vorteile mit sich, unter anderem eine

5

6 KAPITEL 2. DEDUKTIVE DATENBANKEN

effiziente und speicherplatzsparende Datenhaltung sowie eine bequeme Verwaltungvon großen Datenmengen.

Da Regeln deklarative Ausdrucke sind, die nur die Zusammenhange zwischen Da-tenmengen beschreiben, muss ein deduktives DBMS auch Methoden zur Verwaltungund Anwendung von Regeln enthalten. Deswegen verfugt ein deduktives DBMS ubereine auf logischer Deduktion beruhende Inferenzkomponente zur Datenherleitungund Konsistenzprufung. Je nach dem Zeitpunkt zu welchem eine Regelaktivierungerfolgt, unterscheidet man zwischen anfragegetriebener und anderungsgetriebenerInferenz. Die anfragegetriebene Inferenz erfolgt bei der Anfrage nach regeldefinier-ten Daten, die nicht explizit gespeichert sind. Dabei wird zu jeder Anfrage durchgegebenenfalls wiederholte Anwendung von Regeln eine temporare Antwortmengeerzeugt. Bei der anderungsgetriebenen Inferenz werden hingegen die Anderungenvon Basisdaten an die explizit gespeicherten (materialisierten), regeldefinierten Da-ten inkrementell fortgeschrieben.

Allerdings konnen einige Anderungsoperationen zu unerlaubten Datenbank-zustanden fuhren. Die Konsistenz einer Datenbank muss aber immer erhalten blei-ben. Dazu gibt es in einer Datenbank (statische) Integritatsbedingungen, die konsi-stente (erlaubte) Datenbankzustande beschreiben. Die Integritatsbedingungen sindspezielle normative Regeln, die nicht zur Konstruktion neuer Daten, sondern zumVerhindern von inkonsistenten Datenbankzustanden verwendet werden. Keine derAnderungsoperationen darf zur Verletzung der Integritatsbedingungen fuhren. Sollteeine Integritatsbedingung dennoch verletzt werden, werden unerwunschte Anderun-gen ruckgangig gemacht. Damit wird sichergestellt, dass die Datenbank nach einerTransaktion immer konsistent ist.

Das Merkmal von deduktiven Datenbanksystemen, aus explizit gespeichertenDaten automatisch weitere Daten erzeugen zu konnen, macht sie fur betriebswirt-schaftliche Anwendungen attraktiv, bei denen große Mengen von ableitbaren Datenverwaltet werden mussen. Ein Beispiel einer moglichen Anwendung von deduktivenDatenbanksystemen ist die Erstellung von Fahrplanauskunften bei einem Verkehrs-unternehmen (zum Beispiel einer Fluggesellschaft), wo man mit großen Mengen vonDaten arbeiten muss. Eine enorme Speicherplatzersparnis ergibt sich dann, wennanstatt alle moglichen Verbindungsdaten individuell abzuspeichern, der gewunschteFahrplan mit Hilfe von entsprechenden Regeln berechnet wird. Beispielsweise kanneine Regel wie folgt spezifiziert werden:

”Jede volle Stunde ab 6:00 startet ein Flug von Koln/Bonn nach Berlin“

Das erspart die Speicherung jedes einzelnes Fluges. Allerdings benotigt man zurAnfragebeantwortung eine schnelle und effiziente Implementierung eines Ableitungs-mechanismus.

Regeldefinierte Daten, die nicht explizit gespeichert sind, werden als”virtuell“

2.2. SYNTAX 7

bezeichnet. Solche Datendarstellung ist sehr platzeffizient und anderungsfreundlich,erfordert aber, wie man im oben beschriebenem Beispiel sehen kann, eine effizi-ente Inferenzkomponente zur Anfragebeantwortung. In Anwendungen, bei denenbestimmte regeldefinierte Daten haufig abgefragt und selten modifiziert werden,konnen diese nach Erzeugung auch individuell gespeichert werden. Man sprichtdann von einer

”materialisierten“ Darstellung. Der Vorteil dieser Darstellung ist eine

schnelle Anfragebeantwortung durch direkte Datenzugriffe auf gespeicherte Daten.Das konnte man auch im oben beschriebenen Beispiel anwenden. Wie man sieht,muss man abhangig von den Anforderungen der jeweiligen Anwendung entscheiden,welche Darstellungsart am besten zur Problemlosung geeignet ist.

2.2 Syntax

In diesem Abschnitt wird die Syntax von deduktiven Regeln sowie weitere Konzep-te eines deduktiven Datenbanksystems auf der Basis der Datenbanksprache Data-log vorgestellt. Als Grundlage zur Formulierung von Regeln kann im Prinzip jedesDatenmodell und jede deklarative Anfragesprache dienen. Datalog ist eine in derForschungsliteratur uber deduktive Datenbanken weit verbreitete Sprache zur Re-geldarstellung.

Datalog ist eine Anfrage- und Regelsprache fur das relationale Datenmodell, dieauf dem relationalen Bereichskalkul basiert. Die Daten werden in aus Tupeln (Fak-ten) bestehenden Relationen gespeichert und mengenorientiert verarbeitet. Syntak-tisch ahnelt sich Datalog mit der logischen Sprache PROLOG, hat aber nur einenminimalen Satz von syntaktischen Konzepten, wie etwa Konjunktion, Negation underlaubt keine Funktionssymbole.

Obwohl Datalog in der Forschung zum Thema deduktive Datenbanken weit ver-breitet ist, wurde diese Sprache bisher nicht standardisiert. In der Grundform bein-haltet Datalog zum Beispiel keine Negation. Aber um seine Ausdruckfahigkeit zuerhohen wird Negation bei der Regelformulierung zugelassen. Das so erweiterte Da-talog wird als Datalog¬ (DatalogNeg) bezeichnet. Im weiteren werden syntaktischeGrundlagen von Datalog dargestellt, dabei wird mit Datalog stets DatalogNeg ge-meint. Die folgende Beschreibung von Regeln, Fakten und anderen Konzepten richtetsich nach [15][14][11].

2.2.1 Alphabet

Das Alphabet zur Formulierung von logischen Formeln besteht aus folgenden Sym-bolen:


• Variablen

• Konstanten

• Pradikatensymbolen

• und speziellen Interpunktionszeichen

Als Variablen bezeichnet man Großbuchstaben oder Zeichenreihen, die mit Groß-buchstaben beginnen. Zu den Konstanten zahlt man Ziffern, Kleinbuchstaben oderZeichenreichen, die mit Kleinbuchstaben oder Ziffern beginnen oder beliebige Zei-chenreihen in Hochkommata. Pradikatensymbole bestehen aus Zeichenreihen, diemit Kleinbuchstaben beginnen. Pradikatensymbole bezeichnen Datenbankrelatio-nen und haben eine bestimmte Stelligkeit n ≥ 0. Spezielle Interpunktionszeichensind unter anderem Komma ’,’ , Punkt ’.’ sowie der Implikationspfeil ’←’ und dasNegationssymbol ’¬’ aus der Logik [15][14].

2.2.2 Darstellung von Fakten und Regeln in Datalog

Ein Datalog-Programm besteht aus Regeln und Fakten. Die wichtigsten Grund-bausteine jedes Datalog-Ausdrucks sind atomare Formeln (auch Literale genannt).Literale spezifizieren einzelne Datenbankrelationen und dienen als Muster fur dieDarstellung von Datenbankfakten.

Definition 2.1 (atomare Formel) Sei p ein n-stelliges Pradikatensymbol undseien ti (i = 1, ... , n und n = 0) Terme, d.h. entweder Variablen oder Konstanten,dann ist

p (t1, ..., tn)

eine atomare Formel oder ein Atom. Fur ein Atom A ≡ p (t1, ..., tn) bezeichnetpred(A) das Pradikatensymbol p von A.

Definition 2.2 (Formel) Eine Formel ist entweder

1. die Konstante true,

2. eine atomare Formel (positives Literal) A,

3. eine negierte atomare Formel (negatives Literal) ¬A oder

4. eine Konjunktion L1, ..., Ln von Literalen Li (i = 1, ...., n und n ≥ 1).

2.2. SYNTAX 9

Eine wichtige Einschrankung in einer deduktiven Datenbank ist die Verwendungvon bereichsbeschrankten Formeln zur Vermeidung von unendlichen Ergebnissen beider Regelauswertung. In dieser Arbeit werden nur sichere (bzw. bereichsbeschrankte)Fakten und Regeln einer deduktiven Datenbank betrachtet. Um sichere Formeln ge-nau zu spezifizieren, werden zunachst die Begriffe ’Variablenvorkommen’ und ’Input-und Outputvariablen’ definiert.

Definition 2.3 (Variablenvorkommen) Fur eine Formel W wird die Menge al-ler in W vorkommenden Variablen als vars(W) bezeichnet. Falls vars(W) = ®, wirdFormel W als grundinstanziiert bezeichnet.

Unter den in einer Formel vorkommenden Variablen unterscheidet man Input-und Outputvariablen. Dabei kommen Inputvariablen nur in negativen Literalen vorund mussen noch vor Beginn der Auswertung von negativen Literalen gebundensein. Alle anderen Variablen einer Formel nennt man Outputvariablen.

Definition 2.4 (Input- und Outputvariablen) Fur eine Formel W wird dieMenge der Inputvariablen vars+(W ) und die Menge der Outputvariablen vars−(W )wie folgt definiert:

1. Falls W ≡ A ein positives Literal ist, dann sind alle Variablen von A Output-variablen, d.h. vars+(A) := ® und vars−(A) := vars(A).

2. Falls W ≡ ¬A ein negatives Literal ist, dann sind alle Variablen von A Input-variablen, d.h. vars+(¬A) := vars(A) und vars−(¬A) := ®.

3. Falls W ≡ L1, ..., Ln(n ≥ 1) eine Konjunktion von Literalen ist, dann sindalle Variablen, die nur in negativen Literalen auftreten, Inputvariablen, alleanderen sind Outputvariablen:

vars+(W ) :=⋃i=1,...,n vars

+(Li) \⋃i=1,...,n vars

−(Li)

vars−(W ) :=⋃i=1,...,n vars

−(Li).

Definition 2.5 (Datenbank-Klausel) Eine Datenbank-Klausel ist ein Ausdruckder Form

A← W ,

wobei A ein Atom und W eine Formel ist. Das Atom A wird als Kopf und dieFormel W als Rumpf der Datenbank-Klausel bezeichnet. Im Falle W ≡ true kannder Rumpf weggelassen werden und A wird als Fakt bezeichnet. Andernfalls wird dieKlausel deduktive Regel genannt.


Jede deduktive Regel muss sicher sein. Das bedeutet, dass alle Variablen, die imKopf oder im Rumpf einer deduktiven Regel auftreten, in mindestens einem positivenRumpfliteral vorkommen mussen. Solche Regeln heißen auch bereichsbeschrankt. Esgilt also:

vars(A) ⊆ vars−(W ) und vars+(W ) = ®.

Nach den oben genannten Bedingungen muss jedes Fakt variablenfrei sein. Sicherheitvon Fakten und deduktiven Regeln wird im Weiteren vorausgesetzt.

Zur Definition einer Relation p kann sowohl eine einzige Klausel als auch eineMenge von Datenbankklauseln verwendet werden. Dabei mussen nur alle Regelkopfediese Relation p spezifizieren, d.h. fur jeden Kopf A gilt: pred(A) = p. Fur die Mengealler Datenbank-Klauseln C bezeichnet def(C) die Menge aller Pradikatensymbole,die durch Klauseln in C spezifiziert sind.

Definition 2.6 (Deduktive Datenbank) Eine deduktive Datenbank D ist einPaar 〈F,R 〉, wobei F eine Menge von Basisfakten und R eine Menge von deduktivenRegeln ist, so dass def(F ) ∩ def(R) = ® gilt. Eine deduktive Datenbank kann alsendliche Menge von Datenbank-Klauseln betrachtet werden, d.h. D = F ∪R.

Sei RelD die Menge aller Pradikatensymbole in D. Ein Pradikatensymbol p ∈ RelDwird als abgeleitetes Pradikat (abgeleitete Relation) bezeichnet, falls p ∈ def(R).Andernfalls wird es fur p ∈ def(F ) als extensional (Basisrelation) bezeichnet.

Literale, die abgeleitete Relationen oder Basisrelationen referenzieren, werdenentsprechend abgeleitete Literale bzw. Basisliterale genannt.

Eine abgeleitete Relationen kann sowohl von Basisrelationen als auch von abge-leiteten Relationen abhangen. Das bedeutet, dass im Rumpf einer Regel Basisliteraleund abgeleitete Literale stehen konnen. Dadurch entstehen Abhangigkeiten zwischenRelationen. Man sagt, dass eine Relation p von einer Relation q abhangt, wenn qzum Rumpf einer Regel gehort, die die Relation p definiert. Wenn eine regeldefinier-te Relation direkt oder indirekt von sich selbst abhangt, spricht man von rekursivenAbhangigkeiten.

Die Abhangigkeiten zwischen Relationen werden mit Hilfe eines Pradikat-Ab-hangigkeitsgraphen dargestellt. Man unterscheidet positive und negative Abhangig-keiten zwischen Relationen. Im Folgenden werden Begriffe ’Pradikat-Abhangigkeits-graph’ und ’Pradikat-Abhangigkeiten’ praziser definiert.

Definition 2.7 (Pradikat-Abhangigkeitsgraph) Sei D eine deduktive Daten-bank. Der Pradikat-Abhangigkeitsgraph von D ist ein gerichteter Graph GD = (V,E),wobei V = RelD die Menge aller Pradikatensymbole in D ist und E die Menge al-ler beschrifteten Kanten, die folgendermaßen definiert ist: Sei A ← W ∈ D einededuktive Regel, L ∈ W ein Literal, pred(A)=p und pred(L)=q:

2.2. SYNTAX 11

1. Falls L ein positives Literal ist, dann enthalt GD eine positive Kante von qnach p, die mit ′+′ beschriftet wird.

2. Falls L ein negatives Literal ist, dann enthalt GD eine negative Kante von qnach p, die mit ′−′ beschriftet wird.

Definition 2.8 (Pradikat-Abhangigkeiten) Sei D eine deduktive Datenbankund p, q ∈ pred(D). Dann heißt

1. p abhangig von q (p < q) genau dann, wenn der Pradikat-AbhangigkeitsgraphGD von D einen Pfad der Lange n ≥ 1 von q nach p enthalt,

2. p positiv von q abhangig (p <+1 q) genau dann, wenn p < q und der Pfad keinenegative Kante enthalt,

3. p negativ von q abhangig (p <−1 q) genau dann, wenn p < q und der Pfadmindestens eine negative Kante enthalt,

4. p und q voneinander abhangig (p ≈ q) genau dann, wenn p < q und q < p.

Hinsichtlich der bestehenden Abhangigkeiten kann man eine deduktive Datenbankin folgende Klassen unterteilen: positive, semi-positive, stratifizierbare und unstra-tifizierbare deduktive Datenbanken.

Eine deduktive Datenbank heißt positiv, wenn sie keine negative Abhangigkeitenenthalt und semi-positiv, wenn alle negative Abhangigkeiten ausschließlich zu Ba-sisrelationen bestehen. Zur Definition einer stratifizierbaren deduktiven Datenbankwird zunachst der Begriff ’Stratifikation’ vorgestellt.

Definition 2.9 (Stratifikation) Sei D = (F,R) eine deduktive Datenbank. EineStratifikation λ der Regelmenge R ist eine eindeutige Abbildung von der Menge allerPradikatensymbole aus RelD in die Menge der naturlichen Zahlen, so dass fur allep, q ∈ RelD gilt:

p ∈ def(F )⇔ λ(p) = 0,

p ∈ def(R)⇔ λ(p) ≥ 1,

p hangt positiv von q ab ⇒ λ(p) ≥ λ(q),

p hangt negativ von q ab ⇒ λ(p) > λ(q).

Daruber hinaus definiert die Abbildung λ eine vollstandige und disjunkte ZerlegungR1 ∪ ... ∪ Rl von R, so dass fur jeden Pradikatensymbol p ∈ def(R) alle p definie-renden Fakten und Regeln in Rλ(p) enthalten sind. Die Regelmengen R1...Rl heißenSchichten von R. Eine deduktive Datenbank heißt stratifizierbar, wenn mindestenseine Stratifikation der Menge aller Pradikatensymbole existiert. Andernfalls heißteine deduktive Datenbank unstratifizierbar.


2.2.3 Erweiterung von Datalog um”Built In“-Konzepte

Datalog kann um weitere wichtige Konzepte erweitert werden, die eigentlich nichtzum einheitlichen Kern gehoren, aber die fur praktische Anwendungen unverzichtbarsind. In diesem Abschnitt werden spezielle Sprachelemente wie

”Built In“-Pradikate,

”Built In“-Funktionen und Zuweisungsliterale vorgestellt. Die Darstellung orientiertsich dabei an [15].

”Built In“-Pradikate

Eine sinnvolle Erweiterung von Datalog sind Vergleichspradikate, wie

’<’, ’< =’, ’>’, ’>=’, ’=’, ’\=’,

die der Selektionsoperation in der relationalen Algebra entsprechen. Aus der Sichtder Logik konnen Vergleichspradikate als spezielle Relationen betrachtet werden,die aber keine Datenbankrelationen referenzieren, sondern nur zum Testen dienen.Dabei wird gepruft, ob zwei Argumente des jeweiligen Vergleichspradikates in ei-ner bestimmten Beziehung zueinander stehen. Dazu mussen beide Argumente dengleichen Datentyp haben.

Als Argumente von Vergleichspradikaten treten normalerweise atomare Formeln(Terme) auf. Es konnen aber auch sogenannte binare Terme (funktionale Terme)sein, die im nachsten Unterabschnitt (

”Built In“-Funktionen) detaillierter dargestellt

werden.

In Datalog werden Vergleichspradikate zum Bilden von Vergleichsliteralen ver-wendet. Sie konnen wie positive oder negative Literale auch in Regelrumpfen ent-halten sein.

Es ist jedoch zu beachten, dass wenn einer der Argumente eines Vergleichspradi-kates nicht gebunden, also variabel, ist, kann eine unendliche Relation entstehen.Eine Regel, die ein Vergleichsliteral mit ungebundenem Argument enthalt, ist unsi-cher, was man im folgenden Beispiel sehen kann.

Beispiel 2.1 Sei p eine abgeleitete (regeldefinierte) Relation und q sowie s Basis-relationen. Sei eine Regel fur p wie folgt aufgebaut

p(X,Y) ← q(X,Z), s(Z,Y), W < Y

mit dem Vergleichsliteral W < Y. Dann wird das Vergleichsliteral W < Y gemaß derhier angegebenen Reihenfolge der Rumpfliterale als letztes betrachtet (ausgewertet).Dabei wird uberpruft, ob die Werte der Variablen W und Y in Relation ’<’ stehen. Daswurde aber zu einer unendlichen Anzahl von Substitutionen fur Variable W fuhren,wenn die Datentypen von den Termen W und Z zum Beispiel ganze Zahlen sind, weildie Variable W in keinem der positiven Literale dieses Regelrumpfes vorkam.

2.2. SYNTAX 13

Da die Sicherheit von Regeln und Fakten in einer deduktiven Datenbank voraus-gesetzt wird, mussen alle Vergleichspradikate auch bereichsbeschrankt sein. Fur siemuss deswegen die gleiche Sicherheitsanforderung wie fur negative Literale gelten.Das bedeutet, dass jede Variable, die in einem Vergleichsliteral vorkommt, in min-destens einem positiven Literal vorkommen muss, welches zu demselben Regelrumpfwie das Vergleichsliteral gehort. Dadurch kann jede seiner Variablen zum Zeitpunktdes Testens gebunden werden und unendliche Relationen werden vermieden.

”Built In“-Funktionen

Zur Berechnung von Ergebnisparametern in deduktiven Regeln ist noch eine wei-tere Erweiterung von Datalog sinnvoll, namlich das Verwenden von arithmetischenGrundoperationen wie

’+’, ’-’, ’/’, ’×’.

Diese Operationen gehoren wie Vergleichspradikate nicht zum Datalogkern.

Dazu definiert man funktionale Terme (oder auch binare Terme) wie zum Bei-spiel X + Y oder X + 1. Sie bestehen aus zwei Termen und einer arithmetischenOperation. Die Auswertung solcher binaren Terme erfolgt dann, wenn beide ihreArgumente (Terme) nicht mehr variabel sind, d.h. durch entsprechende Konstan-ten gebunden wurden. Das erfordert also die gleiche Sicherheitsanforderung fur jedeVariable eines binaren Terms wie bei den Vergleichsliteralen.

Da die Auswertung von Datenbankrelationen uber Fakten oder Regel auf Sub-stitutionen von Termen (direkter Parameterubergabe) basiert, kann das Verwen-den von funktionalen Termen in Literalen diesen Prozess verkomplizieren. Deswe-gen werden binare Terme nur in speziellen separat zu bearbeitenden Literalen, wieVergleichs- oder Zuweisungsliterale, verwendet.

Zuweisungsliterale

Es gibt noch ein”Built In“-Pradikat, das in Rumpfen von deduktiven Regeln verwen-

det werden kann, namlich das Zuweisungsliteral. Das Zuweisungsliteral wird danneingesetzt, wenn es notwendig ist, einer Variable einen bestimmten Wert zuzuwei-sen. Ein Zuweisungsliteral besteht aus einer definierten Variable, einem Schlussel-wort ’is’ und einem definierenden Ausdruck. Die definierte Variable kann dabeieine beliebige freie Variable sein, und als definierender Ausdruck kann entweder einTerm, ein binarer Term oder ein Compound-Term auftreten.

Das folgende Beispiel veranschaulicht den Aufbau eines Zuweisungsliterals.


Beispiel 2.2 Gegeben sei eine Regel

p(X,Y) ← s(X,Z), Y is X+1, Z is ((a,X),2),

welche die Zuweisungsliterale Y is X+1 und Z is ((a,X),2) enthalt. Betrachtenwir zunachst den Aufbau von Y is X+1. Die definierte Variable in diesem Zuwei-sungsliteral ist Y und der definierende Ausdruck ist der binare Term X+1. Im Zu-weisungsliteral Z is ((a,X),2) tritt als definierte Variable die Variable Z und alsdefinierender Ausdruck der Compound-Term ((a,X),2) auf.

Ein Compound-Term ist ein zusatzliches Konstrukt, welches aus einer beliebi-gen Komposition von Termen, binaren Termen und Compound-Termen aufgebautwerden kann. Im oben genannten Beispiel wird der Compound-Term ((a,X),2) ausdem Compound-Term (a,X) und dem Term 2 zusammengesetzt. Fur die Auswer-tung eines Compound-Terms werden alle Variablen und arithmetische Funktionendurch ihre Werte ersetzt. Deswegen muss jede Variable eines Compound-Terms zumZeitpunkt der Auswertung gebunden sein. Dazu wird gefordert, dass sie noch inmindestens einem positiven Literal des Rumpfes vorkommt.

Zur Vermeidung von unendlichen Relationen mussen Zuweisungsliterale wie Ver-gleichsliterale bereichsbeschrankt sein. Das erfordert die Sicherheit des definierendenAusdrucks, d.h. dass jede Variable, die im definierenden Ausdruck vorkommt, in ei-nem positiven Rumpfliteral auftreten muss.

Im nachsten Abschnitt werden syntaktische Vereinbarungen fur die Datendefini-tionssprache (DDL) und Datenmanipulationssprache (DML) fur Datalog vorgestellt.An dieser Darstellung orientiert sich der Entwurf einer geeigneten Datenstruktur zurReprasentation von Datalog-Regeln in Java.

2.3 DDL und DML fur Datalog

In der Forschungsliteraltur existiert eine weitgehend einheitliche Syntax fur die Dar-stellung von Regeln und Fakten in Datalog. Zur Formulierung von Anfragen undAnderungen sowie zur Schemadefinition gibt es hingegen viele unterschiedliche Vor-schlage. Bei der Vorstellung dieser Konzepte richtet sich diese Arbeit nach [15][14].Im Abschnitt 2.3.1 werden wichtige Sprachelemente zur Schemadefinition wie De-klarationen von Relationen, Regeln und Integritatsbedingungen vorgestellt. Auf dieDarstellung von Anfragen wird im Abschnitt 2.3.2 eingegangen.

2.3.1 Die Datendefinitionssprache (DDL)

Bestandteile von Datalog-Schemata sind Deklarationen von Datenbank-Relationen,Ableitungsregeln und Integritatsbedingungen. Im Folgenden wird der syntaktische

2.3. DDL UND DML FUR DATALOG 15

Aufbau dieser Sprachelemente betrachtet.

Darstellung von Relationen

Die Menge fur eine bestimmte Anwendung benotigter Relationen muss deklariertwerden. Das erfolgt in der Form:

[derived | stored] <Name> / <Stelligkeit>

Eine Relationsdeklaration ’stored p/2’ bedeutet beispielsweise, dass Relation peine Basisrelation ist und eine Stelligkeit 2 hat. Im Allgemeinen kann eine Relationals derived (abgeleitete Relation), stored (Basisrelation) oder sowohl als derivedals auch stored (materialisierte abgeleitete Relation) deklariert werden. Der Para-meter <Stelligkeit> gibt dabei die Anzahl der Argumente dieser Relation an undkann eine positive ganze Zahl oder Null sein.

Darstellung von Ableitungsregeln

Deduktive Regeln gehoren auch zu einem Datalog-Schema und stehen ublicherweisenach den Deklarationen von Relationen. Regeln werden in der traditionellen Formwie folgt dargestellt:

<Kopf> ← <Rumpf>.

Dabei ist der Kopf ein positives Literal, welches eine abgeleitete Relation reprasen-tiert, die unter den als abgeleitet deklarierten Relationen des Schemas vorkommt.Der Rumpf besteht aus einer Konjunktion von Literalen (oder einem einzigen Literal).Zu beachten ist, dass auch jede als abgeleitet deklarierte Relation durch mindestenseine Regel definiert sein muss.

Darstellung von Integritatsbedingungen

Ein Datalog-Schema kann neben Relationsdeklarationen und Regeln auch Inte-gritatsbedingungen enthalten. Es werden nur statische Integritatsbedingungen be-trachtet, die einen konsistenten Datenbankzustand beschreiben und die nach jederAnderungsoperation erfullt sein mussen. Integritatsbedingungen werden als speziel-le normative Regeln aufgefasst. In Datalog werden Integritatsbedingungen wie folgtformuliert:

constraint <Literal>.

Das Schlusselwort constraint bezeichnet eine Integritatsbedingung und wird voneinem Grundliteral gefolgt. Dieses entweder positive oder negative Grundliteral istvariablenfrei und kann die Werte true oder false annehmen.


2.3.2 Die Datenmanipulationssprache (DML)

Mittels Datalog konnen Anfragen und Anderungsoperationen formuliert werden. Indiesem Abschnitt wird insbesondere die Syntax von Anfragen betrachtet, welche beider

”Magic Sets“-Transformation eine wichtige Rolle spielen. Auf die Darstellung

von Anderungen wird in dieser Arbeit verzichtet und stattdessen auf [15] verwiesen.

Darstellung von Anfragen

Die Datalog-Anfragen spezifizieren temporare Antwortrelationen, welche speziell beider Anfragebeantwortung intern berechnet werden. Sie bezeichnen endliche Tupel-mengen uber einer oder mehreren Datenbank-Relationen. Unterschied zwischen ei-ner Datalog-Anfrage und einer Datalog-Regel besteht darin, dass die letzte eineDatenbank-Relation spezifiziert und daher einen Bezeichner fur sie einfuhrt.

Zur Erhohung der Ausdruckskraft von Datalog-Anfragen kann Datalog um lo-kales Regelkonzept erweitert werden. Dabei werden zusatzliche temporare Hilfsre-lationen durch lokale Regeln spezifiziert, welche es ermoglichen, die gewunschtenUnteranfragen zu formulieren. Solche Hilfsrelationen gehoren nicht zum Datenbank-schema und durfen nur innerhalb der Anfrage verwendet werden, in der sie definiertwurden.

Definition 2.10 (Datalog-Anfrage) Eine Datalog-Anfrage ist ein Mengenaus-druck folgender Form:

{ [t1, ..., tn] | Q } ? [with Rlocal1 ; ...;Rlocal

m ], wobei n,m ≥ 0

Dabei sind t1, t2, ..., tn Datalog-Terme (Zielliste) , Q ist eine sichere Konjunktionvon Datalog-Literalen (Qualifikation) und im optionalen Teil [with Rlocal

1 ; ...;Rlocalm ]

werden lokale deduktive Regeln Rlocali zur Definition von temporaren Hilfsrelationen

eingefuhrt.

Eine Anfrage, derer Zielliste leer ist, kann als Boolesche Existenzanfrage bzw. eineTestanfrage interpretiert werden, die zum Prufen von Ja/Nein Bedingungen dient.

Zu beachten ist, dass jede Datalog-Anfrage auch bestimmte Sicherheitsanforde-rungen erfullen muss. So muss jede in der Zielliste vorkommende Variable auch imQualifikationsteil auftreten und jede in einem negativen Literal vorkommende Va-riable in einem positiven Literal auftreten. Zusatzlich muss jede lokale Regel auchsicher sein.

Einfache Anfragen (ohne lokalen Regeln) der Form

{ [t1, ..., tn] | Q } ?

2.4. SEMANTIK 17

werden als atomare Anfragen bezeichnet und spater bei der Anfragebearbeitungmittels

”Magic Sets“-Methode (vgl. Kapitel 4) behandelt. Solche Anfragen konnen

auch alternativ durch ein positives Literal (Basisliteral oder abgeleitetes Literal)ausgedruckt werden, welches die Antwortrelation spezifiziert:

Literal ?

Dabei werden die Variablen dieses Literals als Zielliste interpretiert.

Beispiel 2.3 Lautet eine Anfrage:”Geben Sie alle Zielflughafen an, die vom

Koln/Bonn aus erreichbar sind“, so kann sie wie folgt ausgedruckt werden:

{ [Ziel] | flug(’Koln/Bonn’, Ziel) } ? oder als

flug(’Koln/Bonn’, Ziel) ?

Dabei kann flug/2 eine regeldefinierte Datenbankrelation sein.

2.4 Semantik

Dieser Abschnitt befasst sich mit der Semantik deduktiver Datenbanken. Insbeson-dere wird die fixpunktbasierte Semantik von Datalog-Regeln und Anfragen vorge-stellt. Die Semantikdefinition fur Datalog kann unter anderem modelltheoretischoder fixpunktbasiert vorgenommen werden. Die Fixpunktsemantik liefert im Unter-schied zur modeltheoretischen Semantik konstruktive Ansatze zur Bestimmung einereindeutigen Bedeutung sowohl fur positive als auch fur semi-positive, stratifizierbareund unstratifizierbare deduktive Datenbanken.

Zudem kann die Semantik von Datalog-Anfragen auch mit Hilfe der Fixpunktse-mantik fur deduktive Datenbanken definiert werden. Zusatzlich stellt die Fixpunkt-berechnung (zusammen mit der Regeltransformation) eine wichtige Basis fur einenAnsatz zur effizienten Anfragebearbeitung (die

”Magic Sets“-Methode) dar, die im

Kapitel 4 genau betrachtet wird. Daruber hinaus wird Fixpunktsemantik zur Be-grundung der Korrektheit der

”Magic Sets“-Methode herangezogen (vgl. Kapitel

4).

2.4.1 Semantik von deduktiven Regeln

Eine deduktive Datenbank D = (F,R) besteht aus einer endlichen explizit gespei-cherten Faktenmenge F und aus einer endlichen Regelmenge R, die eine Menge vonneuen ableitbaren Fakten spezifiziert. Die Bedeutung von D kann man durch eineexplizite Faktenmenge F* auffassen, die sowohl alle Fakten in F als auch alle durch


die Regeln in R ableitbaren Fakten enthalt. Dann entspricht eine formale Semantik-definition einer deduktiven Datenbank einer Charakterisierung dieser FaktenmengeF*.

Das erfordert zunachst eine genaue Beschreibung der Ableitbarkeit durch Regeln.Eine deduktive Regel kann als eine fakterzeugende Funktion betrachtet werden. Umdie Anwendung einer Regel genau zu spezifizieren, wird im Folgenden der Begriffder ’Ableitbarkeit’ formalisiert.

Definition 2.11 (Ableitungsoperator) Gegeben sei eine Menge deduktiver Re-geln und eine beliebige Faktenmenge F. Eine deduktive Regel Ri sei wie folgt gege-ben: Ri = A ← L1, ..., Ln und o.B.d.A. sei Li fur 1 ≤ i ≤ m ein positives Literalund fur m+1 ≤ i ≤ n ein negatives Literal. Die Menge aller Fakten, die durch eineeinmalige Anwendung einer Regel Ri auf eine Faktenmenge F abgeleitet wird, wirddurch den Ableitungsoperator T wie folgt definiert:

T [Ri](F ) := {Aσ | σ ist konsistente Variablensubstitution1 , so dass

∀1≤i≤m : Liσ ∈ F und

∀m+1≤i≤n : Liσ /∈ F gilt}

Die Auswertung von negativen Literalen beruht auf dem negation as failure(NAF) Prinzip und der closed world assumption (CWA). Dabei wird jedes Fakt alsfalsch angenommen, wenn es nicht in F enthalten oder nicht mittels Regeln R aus Fableitbar ist. Nach dem NAF-Prinzip wird die Bedeutung eines negativen Literalsdann als true ermittelt, wenn kein entsprechendes positives Fakt in F enthalten ist.In der oben eingefuhrten Definition wurde das formal beschrieben.

Die einmalige simultane Anwendung aller Regeln aus R auf eine FaktenmengeF wird durch einen kollektiven Ableitungsoperator TR(F ) wie folgt definiert:

TR(F ) :=⋃Ri∈R T [Ri](F )

Dabei sind die Fakten, die durch einmalige Anwendung von TR erzeugt werden,wahrend der Ableitung fur andere Regeln noch nicht zugreifbar. Die Bedeutung vonRegeln, die ausschließlich von Basisrelationen abhangen, wird nach solcher einma-ligen Anwendung von TR sofort bekannt. Dagegen sind fur die Regeln, die wiedervon regeldefinierten Relationen abhangen, weitere Anwendungen von TR auf bereitserzeugten Fakten aus vorherigen Schritten notig. Zu beachten ist, dass der Ablei-tungsoperator TR nur die Menge neuer ableitbarer Fakten beschreibt, aber die bereitserzeugten Fakten nicht erhalt. Deswegen wird zur Charakterisierung mehrstufigerAbleitungen ein spezieller kumulativer Ableitungsoperator T ∗R(F ) verwendet, der die

1Bei einer konsistenten Variablensubstitution werden alle Variablen durch Konstanten ersetzt.Dabei wird jedes Vorkommen einer Variable durch dieselbe Konstante ersetzt.

2.4. SEMANTIK 19

Faktenmenge F und die Menge der abgeleiteten Fakten, die durch den Ableitungs-operator TR erzeugt werden, aufsammelt (kumuliert):

T ∗R(F ) := TR(F ) ∪ F.

Fur semi-positive und stratifizierbare Datenbanken ist die Reihenfolge, in der dieRegeln von dem Ableitungsoperator T ∗R angewendet werden, zur Verhinderung vonunerwunschten Ableitungen von Fakten (die nicht in F* enthalten sein sollen) rele-vant. Bei unkontrollierter Regelanwendung kann es passieren, dass negative Literalezu fruh ausgewertet werden. Dadurch konnen manche positive Fakten zu fruh alsfalsch angenommen werden, welche eigentlich durch eine spatere Anwendung einerpositiven Regel als wahr abgeleitet werden. Um das zu verhindern wird eine strati-fizierbare Regelmenge R gemaß einer Stratifikation in Schichten aufgeteilt und dieAnwendung des Operators T ∗R auf R erfolgt entsprechend dieser Aufteilung.

Definition 2.12 (Fixpunktsemantik stratifizierbarer deduktiver Daten-banken) Sei lfp(t, M) der kleinste Fixpunkt der Abbildung t, der das ArgumentM ganz enthalt. Dann gilt:

1. Sei D = (F,R) eine positive oder semi-positive deduktive Datenbank, dann istdie Bedeutung F* von D der kleinste Fixpunkt lfp(T ∗R, F) von T ∗R, der F ganzenthalt.

2. Sei D = (F,R) eine stratifizierbare deduktive Datenbank und sei λ eine Strati-fikation von R in die Schichten R1, ..., Rl , dann ist die Bedeutung F* von Dder iterierte Fixpunkt Fl von D:

F0 := F

Fi := lfp(T ∗Ri, Fi−1) fur 1 ≤ i ≤ l

Es gilt also F* := Fl .

Eine fundamentale Eigenschaft einer deduktiver Datenbank in Datalog ist, dassein kleinster Fixpunkt von T ∗R , der F enthalt, immer existiert, endlich und eindeutigbestimmt ist. Aus der Monotonie des Ableitungsoperators T ∗R folgt die Existenz unddie Eindeutigkeit des kleinsten Fixpunktes. Die Endlichkeit von F* beruht auf derEndlichkeit von F und R und der Tatsache, dass R keine Funktionssymbole enthalt,und so keine neuen Argumente fur ableitbare Fakten entstehen konnen.

Die Semantik unstratifizierbarer deduktiver Datenbanken basiert auf einer drei-wertigen Logik. Das bedeutet, dass einzelne Fakten eine undefinierte Bedeutunghaben konnen. Dabei wird die Menge aller moglichen Fakten, die aus Relationssym-bolen und Konstanten in D konstruiert werden konnen (die Herbrandbasis von D),in drei Teilmengen aufgeteilt, namlich in die Teilmenge der positiven (ableitbaren)


Fakten, der negativen Fakten und der Fakten mit undefiniertem Wahrheitswert. Zubeachten ist, dass mindestens zwei dieser drei Teilmengen dabei explizit bestimmtsein mussen.

Zur konstruktiven Bestimmung der Bedeutung einer unstratifizierbaren deduk-tiven Datenbank existieren unterschiedliche Ansatze, wie zum Beispiel die alternie-rende Fixpunktberechnung (

”alternating fixpoint“ (AFP)-Methode) oder die Fix-

punktberechnung mit bedingten Fakten (”conditional fixpoint“ (CFP)-Methode).

Diese beiden alternativen Methoden weisen einer deduktiven Datenbank die gleicheSemantik zu. Auf eine detaillierte Beschreibung dieser Ansatze wird an dieser Stelleverzichtet und stattdessen auf [23] und [5] verwiesen.

2.4.2 Semantik von Anfragen

Die Bedeutung einer Datalog-Mengenanfrage ist die Menge aller Antworten auf dieseAnfrage. Diese Antwortmenge kann als eine temporare Relation aufgefasst werden,deren Struktur in der Zielliste spezifiziert wird. Die Semantik von Datalog-Anfragenwird mit Hilfe der Fixpunktsemantik fur deduktive Datenbanken bestimmt. Dazuwird die Datenbank temporar um eine neue Hilfsregel erweitert, die eine temporareAntwortrelation zu der Anfrage definiert. Gegebenenfalls ist es notwendig, die Da-tenbank um die lokalen Regeln der Anfrage auch temporar zu erweitern. Formalwird die Semantik einer Datalog-Anfrage wie folgt definiert.

Definition 2.13 (Semantik einer Datalog-Anfrage) Sei D = (Rglobal , F) einededuktive Datenbank und sei

A = {[t1, ..., tn] | Q}? [with Rlocal1 ; ...;Rlocal

m ], fur n,m ≥ 0

eine Datalog-Anfrage. Weiter sei Rerw die um die Hilfsregel fur die Antwortrela-tion und um die lokalen Regeln der Anfrage erweiterte Regelmenge Rglobal. Sei F*die Bedeutung der so erweiterten Datenbank Derw = (Rerw, F ). Die Bedeutung derAnfrage A uber der so erweiterten deduktiven Datenbank D ist definiert als

{[t1σ, t2σ, ..., tnσ] | σ ist konsistente Substitution und

∀L ∈ Q : Lσ ∈ F* }.

Die Bedeutung einer Testanfrage A = L?, die aus einem einzigen positiven parame-terlosen Literal L besteht, lasst sich direkt uber F* bestimmen. Die Bedeutung vonA ist true, wenn L ∈ F*, sonst ist sie false.

Man kann die oben vorgestellte Semantikdefinition direkt zur Bestimmung derBedeutung einer Datalog-Anfrage verwenden. Dabei wird F* zunachst vollstandigmaterialisiert und danach aus der Menge von erzeugten Fakten werden diejenigen

2.5. ARCHITEKTUR EINES DEDUKTIVEN DATENBANKSYSTEMS 21

ausgewahlt, die durch die Antwortrelation spezifiziert wurden. Allerdings ist dieseVorgehensweise ineffizient, da die speziellen Eigenschaften der jeweiligen Anfrage,wie die darin vorkommenden Relationen oder Konstanten, nicht berucksichtigt wer-den. Deswegen wird eine solche Semantikdefinition auch als

”naive“ Semantik be-

zeichnet. Es gibt mehrere effizientere Verfahren zur Anfragebeantwortung, die dieEigenschaften der Anfrage ausnutzen. Eine Reihe solcher Ansatze, wie zum Beispieldie

”Magic Sets“-Methode, basiert auf Regeltransformation und Fixpunktberech-

nung. Eine genauere Beschreibung dieser und anderen Optimierungstechniken zurAnfragebeantwortung erfolgt in Kapitel 4.

2.5 Architektur eines deduktiven Datenbanksy-

stems

Nach der allgemeinen Einfuhrung in das Gebiet deduktiver Datenbanken wird in die-sem Abschnitt auf die logische Struktur eines deduktiven Datenbanksystems (DBS)eingegangen. Dabei werden die einzelnen Komponenten eines DDBS dargestellt so-wie ihre Funktionalitaten und Kommunikation zwischen ihnen erklart. Insbesonderewird die Anfragebearbeitungskomponente und darauf basierend die Bedeutung desim Rahmen dieser Arbeit entwickelten Regelcompilers motiviert.

Zu den wichtigsten Aufgaben eines deduktiven DBMS zahlen unter anderem:

• Schemaverwaltung (Definition und Evaluation der Datalog-Schematas).

• Verwaltung von Datenbankrelationen (Basis- und abgeleiteten Relationen).

• Integritatsprufung und Integritatserhaltung der Datenbank.

• Anfragebearbeitung und Anfrage-Optimierung.

• Unterstutzung des Transaktionskonzeptes zum Durchfuhren von Basisda-tenanderungen.

• Anderungspropagierung.

Die Abbildung 2.1 zeigt die vereinfachte logische Struktur eines deduktiven DBS.

Im Folgenden werden die wichtigsten Funktionalitaten einzelner Komponenteneines deduktiven DBS in Anlehnung an die Beschreibung der Komponenten des pro-totypischen DBSs (DatalogLab), das am Institut fur Informatik III der UniversitatBonn entwickelt wurde, erklart ([4] [20]).


Schnittstellegrapische

Steuerungs−komponente

Anfrage−Manager

DDL−Manager

Regelcompiler

I/O Prozessor

ManagerÄnderungs−IB−Prüfung

DB Verwaltung Schema−Manager

RegelntemporäreData

Dictionary

Benutzerschnittstelle

DatenbasisFakten

temporäreFaktenDB −

FPI

DBMS

Abbildung 2.1: Architektur eines deduktiven Datenbanksystems

Uber eine graphische (bzw. eine textbasierte Kommando-) Schnittstelle (GUIbzw. CUI ) erfolgt die Kommunikation zwischen dem Datenbank-Benutzer und derDatenbank. Sie ermoglicht, dass sowohl die Datenbankschemata als auch die Da-tenbankfakten geladen, angezeigt und bearbeitet werden. Alle DDL- und DML-Anweisungen konnen mit Hilfe von GUI bzw. CUI formuliert und ihre Ergebnisse vi-sualisiert werden. Dementsprechend konnen an die Datenbank unterschiedliche An-fragen gestellt werden bzw. benotigte Anderungen vorgenommen werden. Daruberhinaus bietet sie dem Benutzer die Moglichkeit, die systeminternen Prozesse, diediese Anweisungen bearbeiten, zu konfigurieren. So kann man zum Beispiel die an-zuwendende Fixpunktberechnung (eine iterative oder eine alternierende) oder die

2.5. ARCHITEKTUR EINES DEDUKTIVEN DATENBANKSYSTEMS 23

Art der Anfragebearbeitung (wie etwa naiv oder mittels der”Magic Sets“-Methode)

auswahlen.

Der I/O-Prozessor nimmt die uber die graphische Schnittstelle eingegebenenKommandos entgegen und fuhrt sie mit Hilfe eines Parsers in ein internes Formatuber. Dieser Format wird im Kapitel 3 ausfuhrlich beschrieben. Zu seinen Aufga-ben gehort auch die nachfolgende Uberprufung der syntaktischen und semantischenKorrektheit der DDL- oder DML-Anweisungen. Dies geschieht mit Hilfe des DDL-bzw. des Schema-Managers. Sollten diese Anweisungen nicht korrekt sein, werdenentsprechende Fehlermeldungen uber die graphische Schnittelle ausgegeben. Andern-falls werden sie an die Steuerungskomponente weitergeleitet. Die Anfrageergebnissewerden ebenfalls uber die graphische Schnittstelle ausgegeben.

Die Steuerungskomponente stellt eine globale Schnittstelle fur alle Komponen-ten des DBMS dar. Sie bewerkstelligt die Kommunikation zwischen den einzelnenKomponenten und steuert die Ausfuhrung von systeminternen Prozessen gemaß denuber die GUI konfigurierten Parametern. So werden zum Beispiel die Anweisungenbezuglich der Modifikationen der Datenbankschemata an den DDL-Manager unddie DML-Anweisungen werden gemaß ihrer Art (wie etwa Anfrage oder Anderung)an den zustandigen Anfrage- oder Anderungs-Manager weitergereicht.

Alle DDL-Anweisungen werden an den DDL-Manager ubergeben. Dieser ist furdie Verwaltung der Struktur und der Semantik der Datenbank verantwortlich. Uberseine Komponente Schema-Manager hat er Zugriff auf die Meta-Daten (Data Dictio-nary). Damit konnen die Informationen uber die Datenbankrelationen, Regeln undIntegritatsbedingungen abgefragt und bearbeitet werden. Außerdem verwaltet erauch die fur die Anfragebearbeitung oder Anderungspropagierung temporar erzeug-ten Regeln. Der Anfrage- oder Anderungs-Manager kann dann uber den Schema-Manager die neuen dynamisch erzeugten Regeln ablegen oder gegebenenfalls diebereits im Voraus erzeugten relevanten Regeln anfordern.

Der Anfrage-Manager ist eine fur die Anfragebearbeitung zustandige Kompo-nente. Sie realisiert eine mengenorientierte fixpunktbasierte Anfragebeantwortung,die auf der

”Magic Sets“-Methode basiert (genaueres dazu im Abschnitt 4.1). Dazu

werden die beiden folgenden Komponenten des DBMS benutzt.

Der Regelcompiler nimmt die”Magic Sets“-Transformation einer gegebenen Re-

gelmenge vor, um eine effizient auswertbare Regelmenge zu erhalten. Dabei wird au-tomatisch eine systeminterne temporare Regelmenge (sogenannte

”Magic“-Regeln)

erzeugt, welche dann uber den Schema-Manager verwaltet wird. Zur Anfragebear-beitung holt der Anfrage-Manager die zu der Anfrage relevanten

”Magic“-Regeln aus

dem Data Dictionary (falls sie vorher erzeugt wurden) oder veranlasst den Regel-compiler diese Regeln zu erzeugen. Danach werden die

”Magic“-Regeln mittels der

FPI -Komponente, die die Fixpunktberechnung bezuglich der Basisfakten und der


speziell kodierten Anfrage durchfuhrt, materialisiert. Anschließend werden aus derMenge der temporar erstellten Relationen die zu der Anfrage entsprechenden Ant-worten selektiert und uber die Steuerungskomponente zur Ausgabe weitergereicht.Relationen, die fur die Anfragebearbeitung temporar erzeugt wurden, werden amEnde uber die FPI-Komponente wieder geloscht.

Der Anfrage-Manager unterstutzt außerdem zur Verbesserung der”Magic Sets“-

Transformation verschiedene Optimierungstechniken, die sowohl automatisch alsauch gemaß der Benutzerkonfiguration verwendet werden konnen. So kann im Regel-compiler eine Regelanalyse erfolgen und daraufhin eine geeignete Optimierungstech-nik ausgewahlt werden. Alternativ kann der Benutzer die fur die Regelkompilierunggewunschten Einstellungen selbst setzen. Der Entwurf und die Implementierung desRegelcompilers ist eines der Ziele dieser Arbeit. Eine ausfuhrliche Beschreibung sei-ner Architektur und Arbeitsweise erfolgt im Kapitel 5. Außerdem werden in Kaptel4 mogliche Optimierungstechniken diskutiert.

Die FPI -Komponente ist fur die Fixpunktberechnung bezuglich einer gegebenenFaktenmenge und einer gegebenen Menge deduktiver Regeln zustandig. Dabei wer-den unterschiedliche Typen der Fixpunktberechnung wie semi naive-, iterierte-, soft-oder alternierende-Berechnung unterstutzt. Uber die DB Verwaltungs-komponentehat die FPI -Komponente Zugriff auf die Datenbankfakten. Die Ergebnisse der Fix-punktberechnung werden als temporare Fakten abgelegt, die dem Anfrage-Manageroder dem Anderungs-Manager zur Verfugung stehen. Die FPI-Komponente realisiertzudem eine effiziente Speicherverwaltung.

Der Anderungs-Manager organisiert die Ausfuhrung von Transaktionen (simulta-ne Propagierung mehrerer Basisdatenanderungen) und wickelt die Anderungspropa-gierung ab. Dabei wird jede Transaktion zunachst virtuell (temporar) durchgefuhrtund dann die Konsistenz der Datenbank uberpruft, d.h. es wird uberpruft, ob al-le Integritatsbedingungen erfullt sind. Wenn durch die Ausfuhrung dieser Trans-aktion mindestens eine Integritatsbedingung verletzt wird, wird eine Fehlermel-dung ausgegeben und die Durchfuhrung der Transaktion zuruckgewiesen. Andern-falls werden induzierte Anderungen der Datenbank-Fakten physisch realisiert. Ahn-lich wie bei der Anfragebeantwortung basiert eine effiziente Anderungspropagierungauch auf der Regelkompilierung und der anschließenden Fixpunktiteration (

”Ma-

gic Updates“-Methode). Daher wird im Rahmen der Anderungspropagierung derAnfrage-Manager benutzt, um bei der Materialisierung die fur die Anderungspro-pagierung irrrelevanten Fakten zu vermeiden. Die Materialisierung wird mittels derFPI -Komponente durchgefuhrt.

Kapitel 3

Darstellung von Datalog-Regeln inJava

In diesem Kapitel wird der Entwurf und die Implementierung einer Datenstrukturzur Darstellung von Datalog-Regeln in Java vorgestellt. Von einer geeignet model-lierten Datenstruktur hangt die Effizienz der Verarbeitungsmethoden bzw. der re-gelverarbeitenden Algorithmen (wie etwa der

”Magic Sets“-Transformation) ab. Die

wichtigsten Entwurfskriterien fur eine geeignete Datenstruktur werden im Abschnitt3.2 diskutiert. Dort werden relevante Elemente der zu modellierenden Bestandteileeiner Datalog-Regel gemaß den festgelegten Kriterien identifiziert und ihre Dar-stellungsmoglichkeiten untersucht. Dabei werden wahrend der Anforderungsanalyseauch wichtige Eigenschaften (Attribute und Verhalten) von Regelbestandteilen, dieaus syntaktischer und anwendungsspezifischer Sicht relevant sind, vorgeschlagen undmotiviert. Anschließend wird im Abschnitt 3.3 eine Modellierung der Datenstrukturvorgestellt, welche die bei der Analyse spezifizierten Anforderungen erfullt.

3.1 Ziele und Motivation

Wie man im Kapitel 2 uber deduktive Datenbanken bereits sehen konnte, wurdeDatalog als eine Anfrage- und Regelsprache fur deduktive Datenbanken gewahlt.Datalog ist eine deklarative Sprache. Das bedeutet, dass Datalog-Regeln nur dieZusammenhange zwischen Basisdaten und ableitbaren Daten beschreiben, wahrenddie Datalog-Anfragen nur die Antwortmenge spezifizieren. Die eigentliche Daten-verarbeitung, wie zum Beispiel die Anfragebearbeitung, erfolgt durch eine spezielleInferenzkomponente, die von einem deduktiven Datenbankmanagementsystem zurVerfugung gestellt wird. Die Daten werden also von Anwendungsprogrammen ver-arbeitet, die die Methoden zur Verwaltung und Anwendung von Regeln implemen-

25

26 KAPITEL 3. DARSTELLUNG VON DATALOG-REGELN IN JAVA

tieren. Dazu wird eine interne anwendungsorientierte Datenstruktur benotigt, diedie Datalog-Regeln in einer fur die Verarbeitung geeigneten Form prasentiert.

Nach diesen ersten Uberlegungen muss eine geeignete Datenstruktur sowohl de-klarative Konzepte deduktiver Regeln sinnvoll prasentieren als auch den Anforderun-gen bezuglich der effizienten Datenverarbeitung genugen. Das bedeutet, dass eineDatenstruktur nicht nur syntaktische Merkmale von Datalog-Regeln wiedergebenmuss, sondern auch die spezielle interne Organisation von Bausteinen und bestimm-tes anwendungsunterstutzendes Verhalten anbieten muss. Dabei stellen verschiede-ne Anwendungsprogramme bezuglich der Effizienz und Effektivitat unterschiedlicheAnforderungen an die Datenstruktur.

Viele Anforderungen, wie zum Beispiel das Ermoglichen eines leichten Zugriffesauf die einzelnen Bausteine einer Regel, sind bei den meisten Methoden zur Re-gelverarbeitung relevant - so ist es auch in einem im Rahmen dieser Diplomarbeitentwickelten Modul, welches eine Regeltransformation zur effizienten Anfragebeant-wortung durchfuhrt. Im Weiteren werden die Anforderungen von solchen Anwen-dungen wie die Anfragebearbeitung (insbesondere bezuglich einer effizienten Regel-transformation) berucksichtigt. Die wichtigsten Anforderungen an die Datenstrukturwerden in den nachsten Abschnitten genauer betrachtet sowie entsprechende Reali-sierungsmoglichkeiten diskutiert.

Fur bestimmte Anwendungsfalle konnen eventuell spezifische Anforderungen andie Datenstruktur bestehen, die bei dem ersten Entwurf der Datenstruktur nochnicht genau spezifiziert wurden. Deswegen besteht ein wichtiges zusatzliches Ent-wurfskriterium in der Moglichkeit der einfachen Erweiterung der Datenstruktur umdie fur andere Anwendungsprogramme relevanten Konzepte.

Die drei wichtigsten Kriterien des Entwurfes einer geeigneten Datenstrukturkonnen wie folgt zusammengefasst werden:

1. Darstellung deklarativer Konzepte von Datalog-Regeln.

2. Unterstutzung von Regeltransformationen durch spezielle Zugrifs- und Hilfs-methoden.

3. Einfache Erweiterbarkeit um weitere Konzepte.

3.2 Anforderungsanalyse

In diesem Abschnitt wird die Aufgabenstellung prazisiert. Es werden also An-forderungen spezifiziert, welche die Datenstruktur zur Darstellung von Datalog-Regeln aus syntaktischer und anwendungsspezifischer Sicht erfullen muss. Dabei

3.2. ANFORDERUNGSANALYSE 27

wird zunachst der syntaktische Aufbau einer Datalog-Regel betrachtet, mit demZiel, ihre wichtigen syntaktischen Bestandteile und Besonderheiten zu identifizierenund die Moglichkeiten ihrer Modellierung zu untersuchen. Nach der Festlegung ei-ner bestimmten Darstellungsform fur die identifizierten Elemente, werden weiteremoglichen Elemente, deren Verhalten und Eigenschaften, die aus der anwendungs-spezifischen Sicht relevant sind, diskutiert. Dabei sind solche Eigenschaften undsolches Verhalten von Interesse, die die allgemeine Organisation, Verwaltung undZugriffe auf einzelne Elemente der Datenstruktur erleichtern sollen und daher beider Regeltransformation hilfreich sind.

3.2.1 Vorbereitende Analyse

Zunachst werden die syntaktischen Besonderheiten einer einzigen Datalog-Regel be-trachtet. Wie bereits in Kapitel 2.2 uber die Syntax deduktiver Regel definiert wurde,hat eine Regel folgende Form

Kopf ← Rumpf ,

wobei der Kopf ein positives Literal und der Rumpf eine Konjunktion von Literalenist. Offenbar ist es sinnvoll, eine Regel als ein komplexes Element zu modellieren,das alle Informationen uber die Bestandteile einer Regel enthalten und verwaltenkann. Im Folgenden wird dieses Element der Datenstruktur als Rule bezeichnet, daes spater auch in der gleichnamigen Java-Klasse realisiert wird. Als nachstes mussuntersucht werden, welche Bestandteile das erste identifizierte Element (Rule) habensoll und wie diese geeignet modelliert werden sollen.

Der Regelkopf hat in einer Datalog-Regel eine besondere Stellung und bestimmteEigenschaften. Der Kopf sollte ein positives abgeleitetes Literal sein, dessen Argu-mente in den Rumpfliteralen auftreten und dessen Auswertung von der Auswertungder Rumpfliterale abhangt. Deswegen wird es im Basiselement Rule zwischen einemKopfliteral und einer Menge von Rumpfliteralen unterschieden. Diese werden alsoals eigenstandige Bestandteile head und body spezifiziert. Das ermoglicht eine ein-fache Handhabung dieser beiden Bestandteile, die dann bei der Regelabarbeitungseparat behandelt werden konnen.

Als erstes stellen sich zwei Fragen: wie die Menge der Rumpfliterale organisiertwird und welche Darstellungsform fur die einzelnen Literale gewahlt werden soll.

Organisation von Rumpfliteralen

Wie bereits angesprochen, stellt eine effiziente Regelverarbeitung die Anforderungbezuglich eines schnellen Zugriffes auf die einzelnen Literale. So sollte es bei derRegelkompilierung moglich sein, die Literale sequenziell zu bearbeiten und einzelne


Literale in den entsprechenden Algorithmen auf unterschiedliche Eigenschaften hinzu untersuchen (wie etwa, ob alle Argumente eines Literals frei oder gebunden sind,oder wie viele Argumente frei sind). Dabei ist ein direkter schneller Zugriff auf diegewunschten Literale (bzw. Argumente) sehr wichtig. Deswegen ist eine Strukturnotig, die diese Menge von Literalen aufnehmen und effizient verwalten kann.

Es gibt mehrere Moglichkeiten, die Rumpfliterale zu organisieren. Die zu denoben eingefuhrten Anforderungen passenden Strukturen sind zum Beispiel ein Ar-ray oder eine Liste. In einem Array ist es moglich, auf einzelne Elemente direktzuzugreifen, wobei die Anzahl der Elemente von Anfang an bekannt sein muss undalle Elemente vom gleichen Typ sein mussen, was bei Literalen (wie man spater sehenwird) nicht immer erfullt wird. In einer Liste konnen dagegen Elemente unterschied-licher Typen aufgenommen werden, und neue Elemente konnen einfach hinzugefugtwerden. Zusatzlich bietet eine Liste auch die Moglichkeit, ihre Elemente sequenziellzu bearbeiten. Zur Organisation von Rumpfliteralen wurde sich also eine Daten-struktur eignen, die sowohl die Vorteile eines Arrays als auch die einer Liste in sichkombiniert.

Die Programmiersprache Java bietet mehrere alternative dynamische Daten-strukturen, sogenannte Collections, in denen die Daten in einer bestimmten Form ab-gelegt werden und die spezielle Funktionen zum Datenzugriff zur Verfugung gestelltwerden. Zur Organisation von Literalen wird im Folgenden eine Java-ListenstrukturArrayList verwendet, da sie im Unterschied zu den anderen Listenstrukturen wiezum Beispiel LinkedList oder Vector am besten den gewunschten Anforderungengerecht wird. Dieses kann wie folgt begrundet werden: ArrayList ist eine Listen-struktur, die eigene Elemente in einem dynamischen Array speichert, was sowohleinen schnellen wahlfreien als auch einen sequentiellen Zugriff uber die Position inder Liste auf Elemente ermoglicht [21]. ArrayList wird dann eingesetzt, wenn manes ofter mit Lesezugriffen als mit Anderungszugriffen zu tun hat und die schnellenwahlfreien Zugriffe von Bedeutung sind. Somit konnen nicht nur die gespeichertenLiterale effizient bearbeitet werden, sondern auch die neuen Literale einfach zumRegelrumpf hinzugefugt werden. Bei der

”Magic Sets“-Transformation, wo die neu-

en speziellen”magic“-Literale am Anfang des Regelrumpfes eingefugt werden, wird

das besonders benotigt.

Moglichkeiten der Darstellung von Literalen und deren Argumente

Die Rumpfliterale (body) werden in einem bereits identifizierten Element der Da-tenstruktur Rule in einer Liste (ArrayList) verwaltet. Als nachstes stellt sich dieFrage, wie die einzelnen Literale modelliert werden sollen. Im Folgenden werdenzwei alternative Moglichkeiten zur Darstellung von Literalen untersucht.


Eine Moglichkeit besteht darin, jedes Literal als eine Zeichenkette (String) zu be-trachten und diese in einer (oben motivierten) ArrayListe zu speichern. Jedes Literalwird also als eine Zeichenkette dargestellt, in der zunachst ein Pradikatensymbol ge-folgt von Argumenten stehen kann. Die Operationen wie Suchen und Vergleichen las-sen sich fur solche Zeichenketten gut realisieren. Diese Darstellungsform ermoglichteine einfache Regelauswertung, die entweder durch eine gleichzeitige Bearbeitungaller Rumpfliterale oder durch eine sukzessive Verknupfung von ausgewerteten Li-teralen geschehen kann. Wenn die Basisfakten zum Beispiel auch als eine Liste vonStrings realisiert werden, dann kann die Auswertung von einzelnen Literalen aufeinfache Vergleiche zuruckgefuhrt werden.

Allerdings ist damit eine Analyse von einzelnen Literalen auf bestimmte Ei-genschaften bezuglich ihrer Argumente kompliziert. So muss zum Beispiel fur dieBestimmung, ob es sich bei einigen Argumenten des Literals um eine Variable odereine Konstante handelt, die ganze Zeichenkette durchsucht werden, weil keine direk-ten Zugriffe auf einzelne Argumente moglich sind. Besonders problematisch wird es,wenn die Argumente eines Literals nicht mehr Terme, sondern zum Beispiel binareTerme oder Compound-Terme sind. Außerdem ist diese Darstellungsform fur eineeffiziente Verarbeitung von Literalen bei der Regeltransformation nicht so gut ge-eignet, weil sie keine speziellen Eigenschaften und Besonderheiten von unterschied-lichen Literalen sowie keine direkten Zugriffe auf einzelne Argumente unterstutzt.Diese Problematik wird im Folgenden erlautert.

In entsprechenden Phasen der Regelkompilierung (vgl. Kapitel 4) mussen einzel-ne Literale abhangig von ihren Eigenschaften unterschiedlich behandelt werden. Somussen zum Beispiel einige Literale bei der Bestimmung einer fur die Auswertungguten Reihenfolge gegenuber anderen Literalen bevorzugt werden. Dies geschiehtgemaß Informationen uber ihren Typ und der Anzahl von freien oder gebundenenArgumente in Bezug auf ihre Sicherheit (vgl. Abschnitt 2.2). Dazu mussen einzelneArgumente innerhalb eines Literals auch auf ihre aktuellen Eigenschaften getestetoder ihnen neue Eigenschaften (wie etwa Informationen, ob dieses Argument freioder gebunden ist) zugewiesen werden. Es sollte also ermoglicht werden, in einemLiteral auch einzelne Argumente zu verarbeiten, auf sie zu zugreifen und ihre Eigen-schaften abfragen zu konnen.

Zudem unterscheidet sich die Sicherheit von positiven und negativen Literalenvon der Sicherheit eines

”Built In“-Literals. Die wichtigen Informationen uber die

Besonderheiten eines Literals werden auch bei der”Magic Sets“-Transformation

benotigt, weil positive und”Built In“-Literale auf unterschiedliche Weise behandelt

werden, sowie abgeleitete und Basisliterale anders transformiert werden.

Wie man sieht, mussen fur eine vielseitige Verarbeitung von Literalen alle spe-ziellen Informationen uber ein Literal wahrend der Regelkompilierung handhabbarsein. Aus diesem Grund ist es sinnvoll, die einzelnen Literale als komplexe Elemente


zu modellieren, die alle ihre wichtigen Eigenschaften und Merkmale beinhalten undeffiziente Zugrifffs- und Bearbeitungsmethoden fur verschiedene Anwendungen (ins-besodere Regelkompilierung) anbieten. Da es auch unterschiedliche Argumenttypengibt (Terme, binare Terme und Compound-Terme), welche auch eigene Besonder-heiten haben, die bei der Verarbeitung von Literalen untersucht werden, konnen sieauch als komplexe Elemente (eigenstandige Objekte) modelliert werden. Die Ele-mente der Datenstruktur zur Darstellung von Literalen und Argumenten werden imFolgenden entsprechend als Literal und Argument bezeichnet.

Diese Darstellungsform ermoglicht auch eine einfache mengenorientierte Auswer-tung einer Regel, indem in verschiedenen Literaltypen (diese werden in den nachstenAbschnitten eingefuhrt) eigene Auswertungsmethoden (wie zum Beispiel durch eineeval() Funktion) realisiert werden konnen. Dabei werden die einzelnen Literale inder gewunschten Reihenfolge entsprechend einer SIP-Strategie (vgl. Kapitel 4) undunter Berucksichtigung bereits gewonnener Bindungen separat ausgewertet. Aller-dings benotigt hier eine globale Regelauswertung, also eine gleichzeitige Auswertungaller Rumpfliterale, einen komplexeren Auswertungsmechanismus, der in jeder Regel(Rule) realisiert werden kann.

Ein weiterer Vorteil einer solchen Modellierung ist die einfache Erweiterbarkeitder Datenstruktur um weitere Konzepte, wie es spater detaillierter beschrieben wird.

Diese ersten Entwurfsentscheidungen zur Modellierung von Literalen und Argu-menten (als eigene Objekte, die alle ihre Eigenschaften und Verhalten kapseln) unduber ihre Organisation in einer Regel (als eine Liste), werden als Grundlage fur dieweitere Modellierung dienen. Im Folgenden werden wichtige Eigenschaften (Attribu-te und auch Verhalten) von diesen Elementen, die zu ihrer effizienten Verarbeitungbei der Anfragebearbeitung behilflich sein konnen, identifiziert und motiviert.

3.2.2 Analyse der Anforderungen an Regeln

Wie bereits identifiziert wurde, enthalt ein Objekt Rule ein Element head von TypLiteral und eine Menge von Elementen body von Typ Literal.

Eine weitere Eigenschaft einer Regel, die zum internen Regelidentifizieren dienenkann, ist eine Identifikationsnummer ruleId. Damit kann man eine Regel innerhalbeiner deduktiven Datenbank gemass ihrer ruleId verschieben oder ausgeben.

Zu einer effizienten Verarbeitung von Regeln mussen sie anwendungsspezifischesVerhalten aufweisen. So wird eine Abfrage des Regelkopfes oder der Rumpfliteralebei vielen Anwendungen benotigt. In den modellierten Java-Klassen wird dieses Ver-halten durch entsprechende Methoden wie zum Beispiel getHead()und getBodyLite-rals() realisiert. Daruber hinaus konnen auch weitere spezifische Methoden wie etwasameRule(Rule testRule) benotigt werden. Diese Methode dient zum Testen, ob zwei


Regeln bis auf Variablensubstitutionen identisch sind. Das wird bei der Regeltrans-formation in einem der Schritte der Adornmentpropagierung verwendet, um Regel-Duplikate zu entdecken und zu eliminieren. Fur die


ware es hilfreich, wenn neue Literale in eine bestehende Regel eingefugt werdenkonnten (wie etwa durch addFirstliteral(Literal lit)) oder einige Literale durch an-dere ersetzt werden konnten (wie etwa durch replaceLiteralOnPosition()). Fur gra-phische Ausgaben sollten auch Ausgabemethoden vorhanden sein (toString()).

Manche Anwendungen brauchen solche Regeln, die neben den bereits identifizier-ten allgemeinen Eigenschaften auch spezifische Besonderheiten enthalten. So kannman zum Bespiel fur die Regeltransformation zwei Spezialfalle einer Regel wie Trans-formedRule und MultilinearRule unterscheiden. Hierbei stellt die TransformedRuleeine nach der Regelkompilierung transformierte Regel dar. Sie enthalt neben den all-gemeinen Eigenschaften einer Regel noch zusatzliche Informationen uber den Typdieser transformierten Regel (wie etwa

”answer“-Rule oder

”query“-Rule) und eini-

ge spezifische Verarbeitungsmethoden. Bei der MultilinearRule handelt es sich umeine rekursive Regel, deren Literale bestimmte Bedingungen bezuglich der abgeleite-ten Literalen erfullen mussen und entsprechend zusatzliche Bearbeitungsmethodenerfordern. Um einige Spezialfalle der

”Magic Sets“-Transformation effizienter bear-

beiten zu konnen, werden diese Methoden auch bei Regelkompilierung benotigt. Zureiner besseren Behandlung von Besonderheiten dieser Regeltypen konnen sie auchals eigene Objekte realisiert werden.

3.2.3 Analyse der Anforderungen an Literale

Wie bereits erwahnt, sind Literale wichtige Elemente einer Regel, die wiederumeine komplexe innere Struktur besitzen und daher als ein eigenes Objekt Literalrealisiert werden. Jetzt werden die moglichen Eigenschaften und Verhaltensweisenvon Literalen untersucht, die zu ihrer effizienten Verarbeitung dienen konnen.

Es gibt mehrere Typen von Literalen, namlich atomare Formeln (wie p(t1, ..., tn))und spezielle

”Built-In“ Literale wie Zuweisungs- und Vergleichsliterale (wie zum

Beispiel X is Y + 1 und X <= Y ). Jeder Typ hat eigene Besonderheiten bezuglichdem syntaktischen Aufbau und der Semantik des jeweiligen Literals. Um solche Lite-raltypen besser behandeln zu konnen, scheint es sinnvoll, sie als eigenstandige Einhei-ten, die ihre Merkmale kapseln, zu modellieren. Man kann unterschiedliche Varianteneines Grundelementes Literal wie NormalLiteral (zur Behandlung von positiven undnegativen Literalen), AssignLiteral (zur Behandlung von Zuweisungsliteralen) undCompareLiteral (zur Behandlung von Vergleichsliteralen) identifizieren, die sowohlgemeinsame als auch eigene, spezifische Eigenschaften haben. Dabei sind AssignLi-teral und CompareLiteral wiederum Spezialfalle von

”Built In“-Literalen. Deswegen

wird eine geeignete Modellierung dieser hierarchischen Beziehungen benotigt.


Die gemeinsamen Eigenschaften aller Literaltypen sind das Pradikatensymbol(name), die Menge der Argumente dieses Literals (args) und seine Position imRumpf einer Regel (position). Das Attribut name ist eine Zeichenkette, die entwe-der den Namen der jeweiligen Relation oder die entsprechende Vergleichsoperationeines

”Built In“-Literals darstellt. Zusammen mit anderen Attributen kann name

eine Relation innerhalb einer Datenbank identifizieren. Ein weiteres Attribut positi-on ist fur die eindeutige Bestimmung der Reihenfolge von Literalen im Rumpf einerRegel fur viele Anwendungen relevant. So muss die Reihenfolge der Abarbeitungvon Literalen bei der Regelauswertung oder Regeltransformation festgelegt werden.Daruber hinaus kann man bestimmte Literale anhand ihrer Positionen im Rumpfschnell suchen und darauf zugreifen. Das wird durch Organisation der Menge allerRumpfliterale als eine ArrayList unterstutzt. Dadurch wird auch eine erleichterteNavigation im Regelrumpf erreicht.

Die Menge der Argumente eines Literals kann aus ahnlichen Grunden wie dieMenge der Rumpfliterale einer Regel in einer Listenstruktur ArrayList verwaltetwerden. Dies ist sehr wichtig, weil sowohl ein wahlfreier als auch sequentieller Zu-griff auf die verwalteten Argumente notig ist, was in ArrayList unterstutzt wird.Zudem gibt es mehrere Typen von Argumenten, worauf spater detaillierter ein-gegangen wird. Da ArrayList nicht auf bestimmte Datentypen fixiert ist, sondernElemente eines beliebigen Typs zulasst, ist diese Datentruktur zur Speicherung vonArgumenten unterschiedlicher Typen gut geeignet.

In unterschiedlichen Literaltypen konnen eigene Merkmale identifiziert werden.So unterscheidet man unter normalen Literalen, also Objekten von Typ Normal-Literal, Literale, die entweder abgeleitete oder Basisrelationen spezifizieren. Dazukann ein Attribut status eingesetzt werden. Fur weitere Differenzierung zwischenpositiven und negativen normalen Literalen wird ein Attribut typ benotigt. Daruberhinaus werden entsprechende Methoden zum Abfragen und Setzen dieser und ande-rer Parameter notwendig.

Außerdem sollen Literale bestimmtes Verhalten aufweisen, das die entsprechen-den Anwendungen (wie zum Beispiel Anfragebearbeitung) unterstutzt. Diese sindzum Beispiel die Moglichkeit auf die Argumente eines Literals zuzugreifen und siezu bearbeiten oder einen Literal auf die Ahnlichkeit bzw. Unifizierbarkeit mit einemanderen Literal zu uberprufen. So konnen solche Methoden wie getArgs() oder isSa-me(), die entsprechend alle Argumente eines Literals zuruckgeben oder ein Literalauf die syntaktische Gleichheit mit einem anderen Literal prufen, in unterschied-lichen Algorithmen verwendet werden. Fur die Regelkompilierung wird noch einweiteres spezifisches Verhalten benotigt, namlich die Bestimmung des Adornments(Informationen uber freie und gebundene Argumente im Literal) eines Literals oderdie Markierung entsprechender Argumente als frei oder gebunden. Dazu konnenviele hilfreiche Methoden wie getAdornment(), getBoundArgs() und markBoundPo-


sition() verwendet werden.

Wahrend der Regelkompilierung entstehen neue modifizierte Literale, die zusatz-lich zu allen Eigenschaften von normalen Literalen auch weitere spezifische Beson-derheiten haben. Deswegen werden noch spezielle Untertypen von Literalen benotigt,die wahrend der Regelkompilierung entsprechend modifizierte Literale prasentieren.Diese Literale konnen als AdornedLiteral, AnswerLiteral, QueryLiteral und Supma-gicLiteral bezeichnet werden. So erhalt zum Beispiel ein SupmagicLiteral zusatzlicheine Referenz auf die Regel, aus der es stammt. Die genauere Bedeutung dieserLiterale wird im Abschnitt uber die

”Magic-Set“-Transformation erlautert.

3.2.4 Analyse der Anforderungen an Argumente

Ein Element der Datenstruktur Argument wurde also fur die Darstellung von Argu-menten eines Literals im Abschnitt 3.2.1 motiviert. In diesem Abschnitt werden seineBesonderheiten in Bezug auf die Anforderungen einer effizienten Regelverarbeitunguntersucht.

Es konnen drei Typen von Argumenten identifiziert werden, je nachdem in wel-chen Literalen sie vorkommen. Wahrend positive und negative Literale ausschließlichTerme enthalten, konnen bei den Vergleichsliteralen sowohl Terme als auch binareTerme auftreten, wobei in Zuweisungsliteralen Terme, binare Terme und zusammen-gesetzte Terme vorkommen konnen. Außerdem konnen binare und zusammengesetz-te Terme selbst aus unterschiedlichen Argumententypen zusammengesetzt werden.Folgendes Beispiel dient zur Veranschaulichung des oben beschriebenen Prinzips:

Beispiel 3.1 Sei X is (Y,(Z+1),2) ein Zuweisungsliteral. Dann sind der TermX und der zusammengesetzte Term (Y,(Z+1),2) seine Argumente. Dieser zusam-mengesetzte Term besteht selbst aus drei Argumenten und zwar dem Term Y, dembinaren Term Z+1 und dem Term 2. Außerdem hat der binare Term Z+1 auch zweiArgumente: die Terme Z und 1.

Zu beachten ist, dass alle diese drei Typen zwar die Argumente eines Literals dar-stellen, aber unterschiedliche Auswertungsmechanismen und Bearbeitungsmethodenbenotigen. Daher konnen sie als Elemente (Klassen) Term, BinaryTerm und Com-poundTerm modelliert werden.

Das erfordert aber eine solche Struktur zur ihrer Darstellung, die einerseits so-wohl allgemeine als auch spezielle Eigenschaften von jedem Argument enthalt unddie Besonderheiten der Konstruktion einiger Argumente aus anderen Argumentenunterstutzt. Andererseits muss sie die einheitliche Handhabung von individuellenund zusammengesetzten Elementen ermoglichen.


Zu den allgemeinen Eigenschaften aller Argumente zahlt die Position eines Argu-mentes im zugehorigen Literal. Diese Charakteristik wird bei vielen Anwendungenbenotigt. So mussen Literale bei der Regelkompilierung in unterschiedlichen Algo-rithmen verglichen werden, wobei untersucht wird, ob zum Beispiel auf korrespon-dierenden Positionen stehende Argumente gleich sind. Deswegen spielt ein Attributposition in einem Argument eine wichtige Rolle.

Aus anwendungsspezifischer Sicht (zum Beispiel bei der”Magic Sets“- Trans-

formation) mussen Argumente besondere Informationen, wie etwa ob sie frei odergebunden sind, beinhalten und verwalten. Deswegen mussen in einem Element derDatenstruktur Term, das Variablen oder Konstanten prasentiert, solche Attributewie status (

”free“ oder

”bound“) und typ (

”Variable“ oder

”Constant“) enthalten

werden. Außerdem mussen entsprechende Zugriffsmethoden wie getStatus(), get-Typ() diese Informationen liefern. Daruber hinaus wird bei der Regelkompilierungein aktuelles Adornment jedes Argumentes benotigt. Dazu mussen alle Argument-typen in der Lage sein, diese Informationen wiederzugeben (zum Beispiel durchgetAdornment()). Wahrend eine solche Abfrage bei einem Term sehr einfach beant-wortet wird, wird dies bei komplexeren Argumenten wie CompoundTerm rekursivgemaß ihrem Aufbau berechnet. Es muss also fur alle Argumente ein bereits an-gesprochenes einhaltliches Verhalten modelliert werden. Eine Modellierung solcherStruktur wird im Abschnitt 3.3 vorgestellt.

Zusammenfassung

In diesem Abschnitt wurden wichtige Basiselemente einer Datenstruktur zur Re-geldarstellung identifiziert. Es kann zwischen folgenden 3 Gruppen von Grundele-menten (im Weiteren werden sie auch als Objekte bezeichnet) unterschieden werden:

• Rule,

• Litaral,

• Argument.

Dabei wurden wichtige Eigenschaften und Merkmale von einzelnen Objekten erkanntund motiviert, die sowohl syntaktische als auch anwendungsspezifische Anforderun-gen berucksichtigen. Diese Objekte haben unterschiedliche Beziehungen zueinander.So bestehen einige Objekte aus anderen oder sind einige Spezialfalle der anderen,was bei dem nachfolgenden Entwurf durch eine geeignete Modellierung wiederspie-gelt werden soll.

Im nachsten Abschnitt wird eine Datenstruktur festgelegt, die auf der Grund-lage der hier diskutierten Anforderungen basiert. Einzelne Komponenten werdendetailliert beschrieben.

3.3. ENTWURF UND IMPLEMENTIERUNG DER DATENSTRUKTUR 35

3.3 Entwurf und Implementierung der Daten-

struktur

Die Datenstruktur, die in diesem Abschnitt vorgestellt wird, wurde in der Program-miersprache Java realisiert. Dabei ist Java eine Sprache, die auf objektorientiertenKonzepten basiert. Die objektorientierten Eigenschaften von Java wie Abstraktion,Datenkapselung, Polymorphismus, Vererbung und Wiederverwendung zeichnen sieals eine geeignete Sprache zum Modellieren von komplexen Problemstellungen aus.Somit konnen die im vorherigen Abschnitt identifizierten Objekte und Anforderun-gen, sowie Beziehungen zwischen Objekten, bei dem Entwurf berucksichtigt und inein Programm umgesetzt werden.

Im Weiteren werden die wichtigsten objektorientierten Eigenschaften der Pro-grammiersprache Java kurz erlautert. Diese Konzepte werden bei dem nachfolgen-dem Entwurf der Datenstruktur verwendet und stellen somit eine Grundlage, diezum Verstandnis von getroffenen Entwurfsentscheidungen bei dem Modellieren vonRegel-, Literal- und Argumentenhierarchien unabdingbar sind. Die Darstellung die-ser Konzepte und Entwurf der Datenstruktur beruht auf [13][21][12][10][18].

3.3.1 Objektorientierte Eigenschaften von Java

Kapselung, Vererbung und Polymorphismus sind die drei wesentlichen objektorien-tierten Konzepte und werden im Folgenden in Anlehnung an [13] vorgestellt.

Kapselung

Die bei einer Problemstellung identifizierten Objekte der realen Welt werden als ei-genstandige Einheiten interpretiert, die seine Eigenschaften und Verhalten kapseln.Identische oder sehr ahnliche Objekte (Objekte eines bestimmten Typs), werdenzu Klassen zusammengefasst. Jede Java-Klasse beschreibt also die Eigenschaften ei-nes Objekts durch einen Satz von Variablen (Attribute, Instanzvariablen etc.) unddas Verhalten eines Objekts durch verschiedene Methoden. Die Kapselung bedeu-tet, dass Daten eines Objektes nur uber definierte Methoden zuganglich sind. Dabeiwerden oft komplexe Details der internen Struktur in einer Klasse gekapselt und nuruber definierte Schnittstellen zugegriffen. Das ermoglicht eine leichte Wiederverwen-dung von Programmelementen.


Vererbung

Vererbung bedeutet, dass Objekte Eigenschaften und Methoden von anderen Objek-ten ubernehmen konnen. Man sagt, dass eine Klasse B (Unterklasse) eine Klasse A(Oberklasse oder Basisklasse) erbt. Dabei kann Klasse B auch weitere eigene spezifi-sche Eigenschaften und Methoden definieren, also die Klasse A erweitern. Vererbungentspricht einer

”is-a“ Beziehung, was bedeutet, dass ein Objekt der Unterklasse

gleichzeitig ein Objekt der Oberklasse ist und deswegen das Objekt der Oberklasseuberall ersetzen kann.

Vererbungen konnen mehrstufig sein. Dadurch entstehen Vererbungshierarchi-en, die zur Darstellung komplexer Begriffsstrukturen der zu modellierenden An-wendungswelt geeignet sind. Im Unterschied zu anderen Sprachen wird in Java dieMehrfachvererbung nicht erlaubt, d.h. dass eine Klasse nur eine einzige Oberklasseerben kann. Eine Klasse kann dafur aber beliebig viele Unterklassen besitzen. Furden Fall, bei dem die Eigenschaften und Methoden von mehreren Klassen ubernom-men werden sollen, bietet Java das Konzept der Interfaces an.

Polymorphismus

Eine Unterklasse kann Methoden der Oberklasse abandern und erweitern. Dabeikonnen, wie bereits erwahnt, die Objekte der Unterklasse als Objekte der Oberklas-se behandelt werden. Polymorphismus ermoglicht, dass verschiedene Unterklassenauf die gleichen Nachrichten auf gewunschte Weise unterschiedlich reagieren. DieEntscheidung, welche Methoden aufgerufen werden mussen, erfolgt zur Laufzeit.

3.3.2 Modellierung der Datenstruktur

Bei der Anforderungsanalyse wurden mehrere Objekte als wichtige Bestandteile vonDatalog-Regeln identifiziert. Das sind viele unterschiedliche Typen von Regeln, Li-teralen und Argumenten sowie ihre Attribute und Eigenschaften, die durch syntak-tische und anwendungsspezifische Anforderungen motiviert wurden. Dies stellt dieBasis fur die Festlegung der Datenstruktur dar, die in diesem Abschnitt erfolgt.Im Weiteren werden Modellierungen von Regel-, Literal- und Argumenthierarchienvorgestellt und begrundet, die sowohl allgemeine als spezifische Anforderungen aneinzelne Objekte erfullen.

Regelhierarchie

Ein identifiziertes Objekt Rule hat folgende Attribute:


• Ein Literal mit besonderer Stellung head (Regelkopf) und

• eine Liste der Rumpfliterale body,

• eine Identifikationsnummer der Regel RuleId,

sowie Methoden zum Verwalten eigener Literale und viele anwendungsspezifischeMethoden.

In einer Java-Klasse Rule konnen also alle Eigenschaften und Verhalten festgehal-ten werden, die eine allgemeine Datalog-Regel prasentieren. Die einzelnen Bestand-teile werden wie folgt realisiert. Die Liste der Rumpfliterale body wird durch eineStruktur ArrayList implementiert, die bei der Anforderungsanalyse motiviert wur-de. Die einzelnen Literale werden durch eine weitere Klasse Literal dargestellt (imnachsten Unterabschnitt wird es genauer betrachtet). Die Beziehung zwischen denKlassen Rule und Literal kann durch Aggregation modelliert werden, die die Zusam-mensetzung einer Regel aus Literalen wiederspiegelt. Die Literale sind dabei auchohne Regeln existenzberechtigt, was fur nachfolgende Erweiterung der Datenstruk-tur relevant ist. Beispielsweise kann die Datenstruktur um Integritatsbedingungenals spezielle Literale erweitert werden.

...

...+ toString(): String

− typ: String− IDBs: ArrayList

+ getNumberOfIDB(): int+ getIDBs(): ArrayList+ getRuleTyp(): String+ clone(): Objekt

− body: ArrayList...

+ getBodyLiterals(): ArrayList+ sameRule(r:Rule): boolean

− head: NormalLiteral

+ replaceLiteral(l:Literal, pos:int): void

+ getHead(): NormalLiteral

+ clone(): Objekt+ toString(): String...

...

...

+ getTyp(): String+ formatTyp(): String+ clone(): Objekt+ toString(): String

− ruleTyp: String

MultilinearRule

Rule

TransformedRule

Abbildung 3.1: Klassendiagramm: Regeln

Die weiteren identifizierten Regeltypen wie transformierte Regel und multilineareRegel sind Spezialfalle einer allgemeinen Regel. Sie werden daher als abgeleitete Un-terklassen TransformedRule und MultilinearRule durch Vererbung der Basisklasse


Rule modelliert. Dadurch wird erreicht, dass diese Unterklassen sowohl alle allge-meinen Eigenschaften von Rule als auch eigene spezifische Eigenschaften besitzen.Durch Substitutionsprinzip kann uberall, wo ein Objekt Rule erwartet wird, eineTransformedRule oder eine MultilinearRule eingesetzt werden. Das bedeutet, dassman bei verschiedenen Anwendungen wiederum mit einer allgemeinen Rule arbei-ten kann. Dies kann am folgenden Bespiel fur die Anfragebearbeitung verdeutlichtwerden. Die ursprungliche Regelmenge wird hierbei zur effizienten Anfragebeantwor-tung transformiert, also jede Regel wird beim Kompilieren zur TransformedRule. Beider nachfolgenden Bearbeitung (zum Beispiel Fixpunktiteration) kann sie aber auchals eine ganz normale Regel von Typ Rule behandelt werden. Das bedeutet, dass furden Fixpunktoperator in diesem Fall irrelevant ist, welcher Typ genau diese Regelhat - sie kann einfach als Rule bearbeitet werden. Sollen spezielle Eigenschaften vonTransformedRule abgefragt werden, konnen sie auch bearbeitet werden.

Durch solche Modellierung wird zusatzlich einfache Erweiterbarkeit der Daten-struktur um weitere eventuell hinzukommende Regeluntertypen erreicht, was als einKriterium zum Entwurf der Datenstruktur aufgestellt wurde. Das geschieht durchHinzunahme von gewunschten Unterklassen von Klasse Rule.

Die resultierende Regelhierarchie wird durch Klassendiagramm”Regeln“ (Abbil-

dung 3.1) beschrieben.

Literalhierarchie

Bei der Analyse wurden Literale als wichtige Komponenten einer Regel erkannt, dieeinen komplexen internen Aufbau aufweisen und deswegen durch eine eigenstandigeStruktur realisiert werden sollen. Es wurden mehrere Typen von Literalen iden-tifiziert. Das sind einerseits solche Literale wie CompareLiteral, AssignLiteral undnormale Literale (NormalLiteral), die Bestandteile einer Datalog-Regel sein konnen.Andererseits wurden neue anwendungsspezifische Literale wie AdornedLiteral, Que-ryLiteral, AnswerLiteral und SuppmagicLiteral motiviert, die spezielle Hilfsrelatio-nen bei der Anfragebeantwortung spezifizieren. Diese Literaltypen werden durchgleichnamige eigene Java-Klassen realisiert, die die Eigenschaften und das Verhal-ten jedes einzelnen Typs kapseln.

Wie schon bei der Anforderungsanalyse festgestellt wurde, besitzen alle Literal-typen viele gemeinsamen Eigenschaften. Das sind zum Beispiel:

• Position im Rumpf einer Regel position,

• Pradikatensymbol name,

• Liste der Argumente args,


• Methoden zur Verwaltung dieser Attribute.

Daruber hinaus konnen Literale ein gemeinsames Verhalten aufweisen, wel-ches aber in jedem Literaltyp unterschiedlich und zwar gemass spezifischer Beson-derheiten implementiert werden soll. Als Beispiel kann man die Berechnung desAdornments getAdornment() oder Methoden zum Auswerten eines Literals eval()anfuhren. Hier muss jeder Literaltyp in der Lage sein, ein eigenes Adornment auszu-geben, wobei die Details dieses Vorgehens von Besonderheiten des gegebenen Literalsabhangen.

Gemeinsame Eigenschaften und Verhalten aller Literaltypen konnen in einerOberklasse Literal generalisiert werden. Die Klasse Literal stellt somit ein allgemei-nes Literal (also Literal beliebiges Typs) dar und bildet die Oberklasse in der Lite-ralhierarchie. Alle anderen Literaltypen werden von Literal abgeleitet. Diese Klassewird als abstrakt deklariert. Das bedeutet, dass sie abstrakte Methoden besitzt, diein jeder konkreten Literal-Unterklasse realisiert werden sollen und dadurch ein ge-meinsames Verhalten aller Untertypen erreicht wird. In der Klasse Literal werdengemeinsame strukturelle Eigenschaften und funktionelles Verhalten aller Literalty-pen definiert. Somit besitzt jeder Literaltyp die geerbten Eigenschaften von Literalund es konnen die vorgegebenen Methoden der Klasse Literal, in allen Unterklassenaufgerufen werden, da sie dort implementiert werden.

Die zwei direkten Unterklassen der Klasse Literal sind NormalLiteral und Buil-tInLiteral. Klasse NormalLiteral stellt einen Literal dar, das die Datenbankrelatio-nen spezifiziert. Sie besitzt daher solche identifizierten Attribute wie status (

”deri-

ved“ oder”stored“), typ (

”positiv“ oder

”negativ“) und Liste der Argumente args,

wobei als Argumente nur Terme auftreten durfen. Außerdem sind in dieser Klassesowohl allgemeine Methoden wie zum Beispiel getArgs() oder getAdornment() alsauch spezifische wie boundArgs(), isDerived() oder getVaribleForPosition() vorhan-den.

Auf ahnliche Weise kann man die Gemeinsamkeiten von Klassen CompareLiteralund AssignLiteral in die abstrakte Klasse BuiltInLiteral verallgemeinern. Sie enthaltdann auch die Vorgaben der allgemeinen Eigenschaften und Verhalten von

”BuiltIn“-

Literalen. Die”Built In“-Literale konnen nur zwei Argumente enthalten, die im

Gegensatz zu Argumenten von normalen Literalen zusammengesetzt sein konnen.Dazu sollen auch spezifische Abarbeitungsmethoden dieser Merkmale berucksichtigtwerden.

Die fur die”Magic Set“-Transformation relevanten Klassen AdornedLiteral, Que-

ryLiteral, AnswerLiteral sowie SupmagicLiteral stellen etwas veranderte normaleLiterale dar, die einige ihre Eigenschaften erweitert. Deswegen konnen sie als Unter-klassen der Klasse NormalLiteral modelliert werden. Somit konnen sie die gewunsch-ten Methoden abandern und daher entsprechend reagieren.


...+ toString(): String+ QueryLiteral(l:NormalLiteral)

+ toString(): String...

+ refRule: Rule

+ removeTerm(t:Term): void+ SupmagicLiteral(l:NormalLiteral)

+ AnswerLiteral(l:NormalLiteral):

...

+ AnswerLiteral(l:NormalLiteral, v:boolean)+ toString(): String

+ isSame(): boolean

+ name: String

...

+ getDefVariable(): Term+ getDefExpression(): Argument+ toString(): String

name="is"

...− position: int− name: String

+ getArgs(): ArrayList

+ getPosition(): int

+ getAdornment(): String

...+ toString(): String+ clone(): Objekt

+ getName(): String

...

+ AdornedLiteral(l:NormalLiteral):+ getAdornment(): String+ toString(): String


+ compareSign: String

+ isSame(): boolean+ getCompareSign(): String

"assign" oder"compare"

"derived""stored" oder

"positiv" oder"negativ"

− typ: String

...

− arg2: Argument− arg1: Term

+ getAdornment(): String+ getArgs(): ArrayList+ isSame(): boolean+ getTyp(): String

− Terms: ArrayList− status: String− typ: String


+ isDerived(): boolean+ boundVariables(): ArrayList+ setValuesFromQuery(): void+ isSame(): boolean+ getTyp(): String

QueryLiteral

SupmagicLiteral

AnswerLiteral AssignLiteral

Literal

AdornedLiteral CompareLiteral

BuiltInLiteralNormalLiteral

Abbildung 3.2: Klassendiagramm: Literale


In der Abbildung 3.2 wird die resultierende Literalhierarchie dargestellt. Sieermoglicht unter anderem die leichte Erweiterbarkeit dieser Datenstruktur um wei-tere Typen von Literalen durch die Vererbung der Basisklasse Literal oder Unter-klassen mit passenden Eigenschaften.

Argumenthierarchie

Argumente sind wichtige Bestandteile jedes Literals. Man kann zwischen drei folgen-den Agumenttypen zur ihrer besseren Behandlung unterscheiden, namlich zwischenTermen, binaren Termen und zusammengesetzten Termen. Sie konnen durch ent-sprechende Klassen Term, BinaryTerm und CompoundTerm realisiert werden.

Obwohl diese drei Typen von Argumenten unterschiedlichen Aufbau haben,mussen sie in einem Literal bestimmte gemeinsame Aufgaben als ein allgemeiner TypArgument erfullen und zwar unabhangig von der Konstruktion und den Besonder-heiten des jeweiligen Argumenttyps. So wird es von einem Argument beliebigen Typserwartet, dass man ihm zum Beispiel ein Wert mittels setValue(v) zuweisen kannoder ihn auf die Gleichheit mit einem anderen Argument mittels isLike(Argumentarg) uberpruften kann.

Es ist zu beachten, dass ein Argument CompoundTerm, wegen seiner Konstrukti-on aus elementaren Argumenten wie Term oder BinaryTerm besteht. Dieses hat zurFolge, dass die Ausfuhrung bestimmter Aufgaben in Klasse CompoundTerm auf dieentsprechende Ausfuhrungen in Term bzw. BinaryTerm zuruckgefuhrt werden soll.Dies erfordert, wie bereits motiviert, eine solche Modellierung dieser Argumenthier-archie, so dass eine einheitliche Handhabung sowohl von elementaren Argumentenals auch von zusammengesetzten Argumenten ermoglicht wird und die Besonderhei-ten ihrer Komposition unterstutzt werden.

Die resultierende Datenstruktur basiert auf Composite Design Pattern ([18]).Dabei werden alle gemeinsamen Eigenschaften und Verhalten aller Argumentty-pen in eine allgemeinere abstrakte Klasse Argument verlagert. Die Basisklasse Ar-gument kann sowohl elementare als auch zusammengesetzte Argumente prasentie-ren. Die Unterklassen Term, BinaryTerm und CompoundTerm werden dann alle inder Oberklasse Argument vorgegebene Methoden implementieren. Die Klasse Com-poundTerm kann außerdem Argumente aller Typen als Objekte der Klasse Argumentaufnehmen. Solche Konstruktion ermoglicht es, dass die Klasse Argument eine ein-heitliche Schnittstelle fur alle Argumenttypen bildet.

Die hier beschriebene Argumenthierarchie wird in folgendem Klassendiagrammveranschaulicht.


1

− name: String− status: String− typ: String+ getAdornment(): String+ getTyp(): String+ isBound(): boolean

...+ toString(): String+ clone(): Objekt

+ getAdornment(): String

− funcor: String− term1: Term− term2: Term

+ computeValue(): int

...

+ getFuncor(): String

+ clone(): Objekt...

− args: ArrayList

+ getAdornment(): String+ addNewTerm(): void

+ getAllTerms(): ArrayList+ getArguments(): ArrayList+ clone(): Objekt

bestehtaus

1..*+ getPosition(): int

...

...

+ getAllTerms: ArrayList+ getAdornment(): String+ isLike(arg:Argument): boolean+ setValue(values:Objekt[]): void+ toString(): String+ clone(): Objekt

− position: Term

Term BinaryTerm CompoundTerm

Argument

Abbildung 3.3: Klassendiagramm: Argumente

Zusammenfassung

Die erstellte Datenstruktur zur Regeldarstellung besteht aus drei wichtigen Grup-pen von Klassen - Regelhierarchie, Literalhierarchie und Argumenthierarchie - diesowohl die wichtigsten Konzepte von Datalog-Regeln darstellen als auch viele anwen-dungsunterstutzende Eigenschaften (insbesondere fur die Regelkompilierung) besit-zen. Durch diese Modellierung kann die Datenstruktur auch um andere Konzepteeinfach erweitert werden. So konnen einerseits sowohl die neuen gewunschten Regel-typen, Literaltypen und Argumenttypen als auch ihre neuen Attribute eingefuhrtwerden. Anderseits kann die Datenstruktur auch um eine Klasse zur allgemeinenVerwaltung aller Regeln erweitert werden, in der dann die Abhangigkeiten zwischeneinzelnen Regeln analysiert werden konnen, was zum Beispiel bei der Stratifikationder Regelmenge verwendet werden kann.

Sie kann in einem deduktiven Datenbanksystem zur internen Darstellung vonDatalog-Regeln dienen, welche in anwendungsspezifischen Programmen bearbeitetwerden konnen. Der im Rahmen dieser Diplomarbeit entwickelte Regelcompiler be-nutzt die hier vorgestellte Regeldarstellung.

Das folgende Klassendiagramm stellt alle implementierten Klassen und ihre Be-


ziehungen zueinander dar.

Term

BinaryTerm

CompoundTerm

Argument

NormalLiteral

AdornedLiteral

QueryLiteral

AnswerLiteral

SupmagicLiteral

BuiltInLiteral

CompareLiteral

AssignLiteral

Literal

TransformedRule

MultilinearRule

besteht aus

1 1 0..* 1..*

1

Datastructure

2..*

besteht aus

bestehtaus

Rule

Package

Abbildung 3.4: Klassendiagramm: Datenstruktur

Kapitel 4

Anfragebearbeitung via”Magic

Sets“-Methode

Im Rahmen dieser Arbeit wird eine Komponente (Regelcompiler) eines dedukti-ven DBMS entwickelt, die die Regelkompilierung (Regeltransformation) bei der fix-punktbasierten Anfragebeantwortung durchfuhrt. Diese Regeltransformation basiertauf der

”Magic Sets“-Methode, welche zu einer der wichtigsten Optimierungstech-

niken zur Anfragebearbeitung gezahlt wird. In diesem Kapitel wird diese Methodegenauer vorgestellt. Außerdem werden im Abschnitt 4.2 andere Techniken zur Ver-besserung der Anfragebeantwortung diskutiert und solche zur Implementierung imRegelcompiler ausgewahlt, die auch auf der Regeltransformation beruhen und mitdem

”Magic Sets“-Ansatz kompatibel sind.

4.1 Die”Magic Sets“-Methode

In diesem Abschnitt werden die Grundlagen der”Magic Sets“-Methode dargestellt.

Zunachst wird im Abschnitt 4.1.1 der Einsatz dieser Methode bei der fixpunktba-sierten Anfragebeantwortung motiviert und die Architektur der zugehorigen Kom-ponente eines deduktiven DBMS vorgestellt. Danach werden im Abschnitt 4.1.2 diePrinzipien der Regeltransformation erlautert. Die Darstellung der

”Magic Sets“-

Methode und der Prinzipien orientieren sich im Wesentlichen an [15][14][7][3] sowie[17].

4.1.1 Motivation und Prinzip

Eine der Moglichkeiten, eine an eine deduktive Datenbank gestellte Anfrage zu be-antworten, ist ein naiver Ansatz, bei dem zunachst alle abgeleiteten Relationen mit-

45

46 KAPITEL 4. ANFRAGEBEARBEITUNG VIA”MAGIC SETS“-METHODE

tels Fixpunktiteration materialisiert werden. Danach werden die Fakten ausgewahlt,die durch die Anfragerelation spezifiziert sind (vgl. Kapitel 2). Allerdings ist eine sol-che Anfragebearbeitung ineffizient, weil bei der Materialisierung (auch als Bottom-Up-Prozess bezeichnet) zu viele fur die Anfragebeantwortung irrelevante Relationenerzeugt werden. Sogar bei den Relationen, die fur die Anfragebeantwortung vonBedeutung sind, werden viele irrelevante Fakten erzeugt, weil die ganze Relationzunachst vollstandig berechnet wird und erst dann die zu der Anfrage passendenFakten herausgesucht werden. Dieser Bottom-Up-Prozess ist also ein zielloser Ma-terialisierungsprozess, bei dem die Eigenschaften der Anfrage nicht berucksichtigtwerden. Deswegen ist eine effizientere Methode zur Anfragebearbeitung erwunscht,die die Materialisierung nur auf relevante Relationen und Fakten beschrankt.

Eine solche Anfragebearbeitung kann mit Hilfe der”Magic Sets“-Methode, ei-

nes auf der Regeltransformation basierenden Ansatzes, durchgefuhrt werden. DieHauptidee bei diesem Ansatz besteht darin, die speziellen Eigenschaften der jeweili-gen Anfrage (wie etwa Informationen uber die Konstanten) geschickt auszunutzen.Dies geschieht dadurch, dass man die Regelmenge bezuglich der gegebenen Anfrageso transformiert, dass bei der nachfolgenden Bottom-Up-Materialisierung nur Rela-tionen und Fakten betrachtet werden, die fur die Anfragebeantwortung relevant sind.Dabei werden spezielle Hilfsrelationen in Regelrumpfe eingefuhrt, die die Variablen-bindungen der Anfrage dynamisch weiterpropagieren und dadurch die Generierungirrelevanter Fakten einschranken.

Regelcompiler

Fixpunktiteration

Antworten undZwischenergebnisse

R

DatalogSchemata

Q?Anfrage

FFaktenmenge

magicR

pro Anfragemuster

Regelmenge

internetransformierte

Abbildung 4.1: Regelkompilierung: Komponenten der DBMS zur fixpunktbasiertenAnfragebeantwortung

Die Abbildung 4.1 zeigt die Vorgehensweise bei der Anfragebeantwortung mittels

4.1. DIE”MAGIC SETS“-METHODE 47

der”Magic Sets“-Methode in einem deduktiven DBMS (aus [15]). Die gegebene

Regelmenge R wird dabei automatisch mit Hilfe eines Regelcompilers in eine Re-gelmenge Rmagic transformiert, die nur intern von einem DBMS verwendet wird.Diese transformierte Regelmenge Rmagic besteht aus zwei Regelarten. Das sind die

”answer“-Regeln, die die Teil-Relationen der Antwortrelation erzeugen, und

”que-

ry“-Regeln, welche die Hilfsrelationen zur Propagierung von Inputbindungen derAnfrage definieren. Der genauere Aufbau dieser Regeln wird im nachsten Abschnitterlautert. Nach der Kompilierung werden die transformierten Regeln (Rmagic) mittelsder Fixpunktiteration bezuglich der Basisfakten und der speziell kodierten Anfragematerialisiert. Anschließend werden die zu der Anfrage passenden Fakten (aus derMenge der erzeugten Fakten) selektiert. Es ist zu beachten, dass die wahrend derFixpunktiteration erzeugten Relationen nur systemintern existieren und nach derAnfragebeantwortung geloscht werden.

4.1.2 Die”Magic Sets“-Transformation

Ein wesentlicher Schritt bei der”Magic Sets“-Methode ist also die Regelkompilie-

rung. In diesem Abschnitt wird detailliert erlautert, wie eine Regelmenge transfor-miert wird, da es fur den Entwurf und die Implementierung des Regelcompilers (sie-he Kapitel 5) unabdingbar ist. Die Darstellung der wichtigen Konzepte der

”Magic

Sets“-Transformation richtet sich an [3][17][15][7].

Wie schon angesprochen, werden bei der”Magic Sets“-Transformation zwei Ar-

ten von Regeln erzeugt. Das sind die Antwortregeln (”answer“-Regeln) und die

Regeln, die weitere Unteranfragen definieren (”query“-Regeln). Diese beiden Re-

geltypen enthalten neue Literale wie”answer“-Literale und spezielle Hilfsliterale

-”query“-Literale. Die

”answer“-Literale bezeichnen dabei die Teil-Relationen der

Antwortrelation und die”query“-Literale dienen zum dynamischen Propagieren von

Variablenbindungen der Anfrage. Die”query“-Literale lassen in Regelrumpfen nur

die fur die Antwortproduktion relevanten Bindungen durch.

Die Bestimmung solcher relevanten Bindungen hangt von der jeweiligen Anfra-ge ab. Das Bindungsmuster einer Anfrage, also die Informationen uber die frei-en (gefragten) Parameter und die gebundenen (gegebenen) Parameter, werden andie entsprechenden Regelkopfe gegeben und dann seitwarts an die Rumpfliteraleweiterpropagiert. Deswegen mussen die Rumpfliterale einer Regel zur Steigerungder Effektivitat der

”Magic Sets“-Transformation in einer zur Anfragebeantwortung

gunstigen Reihenfolge angeordnet werden. Diese Reihenfolge hangt von Bindungendes Regelkopfes ab, was seinerseits vom Bindungsmuster der Anfrage abhangt. Indiesem Zusammenhang spricht man uber eine SIP-Strategie.


SIP-Strategie

Eine SIP-Strategie (engl. Sideways Information Passing Strategy) bestimmt die Ab-arbeitungsreihenfolge der Rumpfliterale. Dabei wird formal festgelegt, welche Werte(Bindungen) wahrend der Bottom-Up-Auswertung von einem Literal bzw. von einerKonjunktion von Literalen an einen anderen Literal ubergeben werden. Fur unter-schiedliche Anfragen gibt es naturlich unterschiedliche SIP-Strategien. Zur Unter-scheidung zwischen SIP-Strategien, die zu verschiedenen Anfragen gehoren, markiertman den Regelkopf mit dem Bindungsmuster der Anfrage.

Das Bindungsmuster eines Literals wird auch als Adornment bezeichnet. DasAdornment eines Literals gibt an, welche Argumente in diesem Literal frei undwelche gebunden sind. Fur ein n-stelliges Literal p stellt eine aus den Buchstaben’b’ und ’f’ bestehende Zeichenkette der Lange n sein Adornment dar. Dabei stehen’b’-s auf Positionen, die den gebundenen Argumenten des Literals p entsprechen, und’f’-s stehen auf Positionen, die den freien Argumenten des Literals p entsprechen.

Bei der Auswertung eines Literals spielt das Bindungsmuster eine wichtige Rol-le, weil es diese nur auf die relevanten Fakten beschrankt, also auf diejenigen, dieaufgrund der Bindungen in der Datenbank selektiert werden konnen. Welches Bin-dungsmuster ein Rumpfliteral bekommt, hangt von der Wahl der SIP-Strategie ab.Deswegen ist es von großer Bedeutung, eine solche Auswertungsreihenfolge der Lite-rale zu bestimmen, die es ermoglicht, jedem Literal ein fur die Auswertung gunstigesBindungsmuster zuzuweisen. Dann kann ein gewunschter Teil der Datenbankfaktendurch die Auswertung des jeweiligen Literals selektiert werden, was beim Auswertender anderen Literalen verwendet wird und dadurch ihre Auswertung auch auf dierelevanten Fakten einschrankt.

Es gibt unterschiedliche Kriterien zur Wahl einer gunstigen SIP-Strategie. Manunterscheidet zwischen statischen und dynamischen SIP-Strategien. Bei einer sta-tischen SIP-Strategie werden nur Informationen uber aktuelle Variablenbindungenbenutzt, um eine fur die Materialisierung gute Literalreihenfolge zu bestimmen. DieAuspragungen der Relationen werden dabei nicht berucksichtigt. Der Vorteil dieserStrategie liegt vor allem darin, dass die festgelegte Reihenfolge der Literale sich beider Materialisierung nicht mehr andert und dass nur eine Regelanalyse zur Bestim-mung einer guten Reihenfolge erforderlich ist. Bei einer dynamischen SIP-Strategiewerden Informationen uber die Datenbankrelationen (wie zum Beispiel ihre Großen)und auch uber die wahrend der Materialisierung abgeleiteten Fakten berucksichtigt.Allerdings andert sich bei der Materialisierung die Abarbeitungsreihenfolge der Lite-rale. Das passt nicht so gut zu dem

”Magic Sets“-Konzept, weil die durch die

”Magic

Sets“-Transformation bestimmte Reihenfolge wieder geandert werden kann.

Deswegen werden im Weiteren nur die statischen SIP-Strategien betrachtet, dieauf der Regelanalyse basieren. Es gibt dabei verschiedene Heuristiken zur Bestim-


mung einer guten Literalreihenfolge. Eine Heuristik besagt, dass als nachstes aus-zuwertende Literal immer das Rumpfliteral ausgewahlt werden soll, das die maxi-male Anzahl von gebundenen Parametern enthalt. Dann konnen seine Variablen-bindungen optimal weitergereicht werden. Diese Strategie wird als most-boundedbezeichnet. Bei einer anderen Heuristik (minfree) wird als Nachstes das Rumpflite-ral ausgewahlt, das die wenigsten freien Variablen enthalt. Dies geschieht unter derAnnahme, dass durch seine Auswertung viele relevante Fakten moglichst fruh selek-tiert werden konnen und dadurch die Auswertung der nachfolgenden Literale auchauf relevante Fakten eingeschrankt werden kann. Es gibt auch eine left-to-right-SIP-Strategie, bei der alle Literale in der Reihenfolge, in der sie im Regelrumpf stehen,abgearbeitet werden. Man kann auch diese oder andere Heuristiken, die auf der Aus-nutzung von Informationen uber freie und gebundene Variablen basieren, miteinan-der kombinieren. Im Folgenden wird das genaue Vorgehen bei der Regelkompilierungvorgestellt. Sie lauft in zwei Schritten ab:

Schritt 1: Erzeugen einer”adorned“-Regelmenge

Im ersten Schritt der”Magic Sets“-Transformation wird eine

”adorned“-Regelmenge

Rad zu einer gegebenen Regelmenge R und Anfrage q erzeugt. Diese”adorned“-

Regelmenge bezeichnet dabei eine Regelmenge, derer Regeln gemaß einer SIP-Strategie zum Adornment der Anfrage (oder Unteranfrage) umgeordnet sind. DieBindungsmuster (Adornments) von Literalen werden dabei in jeder Regel explizitbestimmt. Demzufolge kann eine

”adorned“-Regelmenge als eine formale Darstellung

der Informationen uber die Variablenbindungen zwischen den Literalen betrachtetwerden, die durch eine SIP-Strategie spezifiziert werden.

Im Folgenden wird die Erzeugung einer”adorned“-Regelmenge beschrieben. Die

Darstellung dieser Vorgehensweise richtet sich im Wesentlichen an [17].

Eine Regel wird als”adorned“-Regel bezeichnet, wenn alle ihre Literale gemaß

einer SIP-Strategie umgeordnet sind und das Adornment jedes Literals damit be-stimmt ist. Ein Literal wird als

”adorned“-Literal bezeichnet, wenn sein Adornment

explizit bestimmt ist.

Die Erzeugung einer”adorned“-Regelmenge

Gegeben sei eine Regelmenge R und eine Anfrage q. Die”adorned“-Regelmenge Rad

wird wie folgt konstruiert:

Zunachst wird die Anfrage durch ihre”adorned“-Version: qα ersetzt. Jede ihrer

Argumentpositionen wird als gebunden markiert, die einer Konstante oder einer sichwiederholenden Variable entspricht.


Danach wird fur jeden”adorned“-Literal pα und fur jede Regel mit dem Kopf

p eine SIP-Strategie ausgewahlt und eine”adorned“-Version dieser Regel erzeugt.

Ihre”adorned“-Literale werden dabei zum weiteren Propagieren herangezogen. Im

rekursiven Fall kann der Kopf einer Regel deswegen unterschiedliche Adornmentsbekommen und infolgedessen konnen auch mehrere

”adorned“-Varianten einer Re-

gel entstehen. Es liegt daran, dass fur ein n-stelliges Literal 2n”adorned“-Varianten

existieren konnen. Jedes Literal einer”adorned“-Regel bekommt dabei ein eindeu-

tiges Bindungsmuster (das wird auch als unique-binding property bezeichnet). Einbereits betrachtetes

”adorned“-Literal pα wird markiert, damit es nicht wieder zum

Erzeugen einer”adorned“-Regel verwendet wird.

Diese Schritte konnen wie folgt formal dargestellt werden:

(AdornRules)

Fur jedes noch nicht bearbeitete”adorned“-Literal pα

Fur jede Regel r mit dem Kopf p

Erzeuge eine”adorned“- Regel (AdornRule)

Fuge diese”adorned“- Regel in Rad ein.

Vervollstandige die Liste der noch zu bearbeitenden”adorned“-Literale mit

”adorned“-Literalen der erzeugten Regel (falls sie dort nicht bereits enthaltensind).

Markiere”adorned“-Literal pα als bearbeitet.

Vorgehensweise beim Erzeugen einer”adorned“-Regel:

(AdornRule)

Fur eine Regel r mit dem Kopf p

Ersetze den Kopf p durch pα (d.h. markiere sein Adornment als α).

Ordne den Regelrumpf gemaß einem SIP zum Adornment α um.

Erzeuge dabei”adorned“-Version jedes abgeleiteten Literals im Rumpf

der Regel r. (AdornLiteral)

Ein”adorned“-Literal wird folgendermaßen erzeugt:

(AdornLiteral) Dabei werden folgende Prinzipien berucksichtigt:

Ein Argument in einem Literal wird gebunden und seine Position als ’b’ markiert,wenn

• es eine Konstante ist oder


• es unter Argumenten von Literalen vorkommt, die vor diesem Literal im Rumpfstehen und deswegen zuvor ausgewertet wurden oder

• es unter gebundenen Argumenten des Kopfes vorkommt. Sonst wird diesesArgument als frei markiert.

Beispiel 4.1 Sei p(a,Y)? eine Anfrage, bei der a eine Konstante und Y eine Va-riable ist. Seien auch

p(X,Y) ← q(X,Z),p(Z,Y).

p(X,Y) ← s(X,Y).

Datalog-Regeln, wobei p ein abgeleitetes Literal und q, s Basisliterale sind. Dann wirddie

”adorned“-Regelmenge bezuglich dieser Anfrage gemaß dem oben beschriebenen

Algorithmus folgendermaßen erzeugt:

1. Zunachst wird das Adornment der Anfrage bestimmt: In diesem Fall ist es ’bf’und die Anfrage ist entsprechend als pbf markiert.

2. Fur jede Regel mit dem Kopf p werden ihre”adorned“-Versionen erzeugt.

Zunachst wird hier die Regel p(X,Y) ← q(X,Z),p(Z,Y) betrachtet. Als Erstes mar-kiert man den Kopf dieser Regel mit dem Adornment der Anfrage:

pbf(X,Y) ← q(X,Z),p(Z,Y).

Das bedeutet, dass die Variable X in dieser Regel gebunden und die Variable Y freiist.

Danach wird diese Konstellation der Inputparameter seitwarts an die Rumpflite-rale gemaß einer gewahlten SIP-Strategie zum Adornment des Kopfes weitergegeben.In diesem Beispiel wird eine Links-rechts-Anordnung der Literale (eine left-to-right-SIP-Strategie) ausgewahlt. Gemaß dieser SIP-Strategie wird zunachst das Adorn-ment des Literals q(X,Z)bestimmt. Die Variable X wird dabei als gebunden (da sieunter gebundenen Argumenten des Kopfliterals vorkommt) und die Variable Z alsfrei markiert. Beim Bestimmen des Adornments des Literals p(Z,Y) wird die Varia-ble Z als gebunden markiert, weil sie im links stehenden Literal q(X,Z)auftrat.

Damit sieht die”adorned“-Version dieser Regel gemaß einer left-to-right-SIP-

Strategie zum Adornment ’bf’ wie folgt aus:

pbf(X,Y) ← q(X,Z),pbf(Z,Y).

Es ist zu beachten, dass eigentlich nur die abgeleiteten Literale ihre”adorned“-

Version erhalten konnen. In diesem Beispiel hat das Basisliteral q(X,Z)ein implizitesAdornment ’bf’.


Nach diesem Schritt sollten die neu entstandenen”adorned“-Literale aus dieser

Regel in die Liste zum weiteren Propagieren hinzugefugt werden. In diesem Fallware das Literal pbf(Z,Y) ein Kandidat zum weiteren Propagieren. Allerdings hatdieses Literal genau das gleiche Bindungsmuster wie das gerade betrachtete Literalpbf(X,Y). Deswegen wird pbf(Z,Y) nicht zum Weiterpropagieren herangezogen, daes zu gleichen

”adorned“-Regeln (wie bei pbf(X,Y)) fuhren wird. Wenn p aber ein

anderes Bindungsmuster wie zum Beispiel pfb hatte, so sollte eine weitere”ador-

ned“-Version der Regel p(X,Y) ← q(X,Z),p(Z,Y) zum Adornment ’fb’ von pfb undentsprechend auch weitere Versionen aller ubrigen Regeln mit dem Kopf p erzeugtwerden.

Auf die gleiche Weise erzeugt man”adorned“-Version der Regel p(X,Y) ← s(X,Z)

als

pbf(X,Y) ← s(X,Y).

Dabei hat das Literal s(X,Y)ein implizites Adornment sbf(X,Y).

Da keine abgeleiteten Literale im Rumpf dieser Regel vorhanden sind, werden auchkeine

”adorned“-Literale zum weiteren Propagieren herangezogen. Das gerade bear-

beitete Literal pbf(X,Y)wird als betrachtet markiert. Daruber hinaus gibt es keinezu propagierende

”adorned“-Literale und damit ist das Erzeugen der

”adorned“-

Regelmenge beendet. Die resultierende Regelmenge ist dann:

pbf(X,Y) ← q(X,Z),pbf(Z,Y).

pbf(X,Y) ← s(X,Y).

Schritt 2: Query- und Answer-Regeln erzeugen

Auf der Basis der im ersten Schritt erzeugten”adorned“-Regelmenge Rad wird im

zweiten Schritt der”Magic Sets“-Transformation eine Regelmenge Rmagic erzeugt.

Sie besteht aus oben motivierten”query“- und

”answer“- Regeln. Dieses Vorgehen

wird im Folgenden beschrieben:

1. Fur jedes regeldefinierte Literal Lα ∈ Rad wird ein neues”query“-Literal

queryαL eingefuhrt. Dabei sind die Argumente von queryαL nur diejenigen Ar-gumente von Lα, die im Adornment von Lα als ’b’ markiert wurden. queryαLbesitzt also nur die gebundenen Argumente von Lα.

2. Fur jede Regel r : H ← L1, L2, ..., Ln ∈ Rad und jedes regeldefinierte Literal Li

im Rumpf von r, das Adornment β hat, wird folgende”query“-Regel erzeugt:

queryβLi ← queryαH,L1, L2, ..., Li−1


Dabei ist der Kopf (queryβLi) ein ”query“-Literal, welches das Adornment β

und gebundene Argumente des Literals Li enthalt. Der Rumpf dieser”query“-

Regel besteht aus allen Literalen, die vor dem Literal Li im Rumpf der Regelr standen, gefuhrt von einem speziellen

”query“-Literal (queryαH), das Ad-

ornment α und gebundene Argumente des Kopfliterals H enthalt. Jedes regel-definierte Literal Lj unter L1, L2, ..., Li−1 wird dabei durch ein entsprechendes

”answer“-Literal (answer Lj)ersetzt, das alle Parameter von Lj enthalt.

3. Fur jede Regel r : H ← L1, L2, ..., Ln ∈ Rad wird eine”answer“-Regel folgen-

dermaßen erzeugt:

answer H ← queryαH,L1, L2, ..., Ln.

Der Kopf (answer H ) dieser Regel ist ein”answer“-Literal, das alle Para-

meter von H enthalt. Im Rumpf dieser Regel wird jedes regeldefinierte Li-teral Lj unter L1, L2, ..., Ln auch durch ein entsprechendes

”answer“-Literal

answer Lj ersetzt. Zudem wird das zu dem Kopfliteral H erzeugte”query“-

Literal queryαH als erstes Rumpfliteral eingefugt.

4. Zu der Anfrage q(θ)? wird ein seed-Fakt queryαq(θ′) erzeugt, welches nur diegebundenen Parameter der Anfrage enthalt.

Fur zwei Anfragen mit einem gleichen Bindungsmuster aber unterschiedlichen Kon-stanten (wie zum Beispiel p(a,Y)? und p(b,Y)? ), unterscheidet sich die transfor-mierte Regelmenge Rmagic dabei nur um seed-Fakt. Deswegen muss die Regelkompi-lierung fur solche Anfragen nicht erneut durchgefuhrt werden, sondern es muss beider Anfragebeantwortung einfach ein anderer seed-Fakt verwendet werden. Wennaber eine Anfrage mit einem anderen Bindungsmuster (wie zum Beispiel p(X,b)? )gestellt wird, muss die Regelkompilierung zum Adornment dieser Anfrage durch-gefuhrt werden. Die Regelkompilierung kann in einer deduktiven Datenbank auchim Voraus fur alle relevanten Adornments durchgefuhrt werden. Bei einer Anfrage-beantwortung kann dann auf die bereits transformierten Regeln schnell zugegriffenwerden.

Beispiel 4.2 Betrachten wir die im Beispiel 4.1 bezuglich der Anfrage p(a,Y)? er-zeugte

”adorned“-Regelmenge:

pbf (X,Y )← q(X,Z), pbf (Z, Y ).

pbf (X,Y )← s(X,Y ).

Nach dem zweiten Schritt der Regelkompilierung besteht die transformierte Regel-menge Rmagic aus zwei ”

answer“-Regeln (zu jeder”adorned“-Regel) und einer

”que-

ry“-Regel (zu dem abgeleiteten Literal p(Z,Y) der ersten Regel):


answer p(X,Y )← querybf p(X), q(X,Z), answerp(Z, Y ).

answer p(X,Y )← querybf p(X), s(X,Y ).

querybf p(Z)← querybf p(X), q(X,Z).

Bemerkungen zur”Magic Sets“-Transformation

Bei der”Magic Sets“-Transformation wird eine sichere Datenbank vorausgesetzt. Die

Sicherheit der transformierten Regelmenge muss auch fur die nachfolgende Auswer-tung erhalten bleiben. Das betrifft besonders negative und

”Built-In“-Literale, weil

sie nicht wie positive Literale ausgewertet werden und alle ihre Argumente zum Zeit-punkt der Auswertung gebunden sein mussen. Das erfordert die Wahl solcher SIP-Strategie, die Sicherheitsbedingungen von negativen und

”Built-In“-Literalen bei der

Umordnung berucksichtigt. Da die Auswertung von Rumpfliteralen von links nachrechts erfolgt, mussen negative und

”Built-In“-Literale soweit nach rechts verscho-

ben werden, dass alle ihre Variablen durch die Auswertung der von links stehendenpositiven Literalen gebunden werden.

Das kann in folgendem Beispiel illustriert werden.

Beispiel 4.3 Betrachten wir eine Datalog-Regel, die unter anderem auch ein nega-tives Literal ¬q(V,W)enthalt:

p(V) ← ¬q(V,W),r(V),q(W).

Sei p(a)? eine Anfrage und als SIP-Strategie eine Links-rechts-Anordnung der Lite-rale ausgewahlt. Dann muss das negative Literal ¬q(V,W) solange nach rechts ver-schoben werden, bis jede seiner Variablen gebunden wird, obwohl die Literalreihen-folge bei dieser SIP-Strategie unverandert sein sollte. Andernfalls musste ¬q(V,W)bei der Auswertung des Regelrumpfes laut der bestehenden Reihenfolge als Erstesausgewertet werden. Da aber zum Zeitpunkt der Auswertung nicht alle Variablengebunden sind (die Variable V ist gebunden, aber die Variable W ist frei), ware dieAuswertung dieses Literals nach dem negation as failure Prinzip unmoglich.

In diesem Beispiel ergibt sich folgende zulassige Literalreihenfolge:

p(V) ← r(V),q(W),¬q(V,W).

Wenn”Magic Sets“-Transformation auf eine sichere Regelmenge angewendet

wird und dabei eine sichere SIP-Strategie benutzt wird, dann liefert die”Magic

Sets“-Transformation wiederum eine sichere transformierte Regelmenge [2].

Die”Magic Sets“-Transformation kann sowohl auf eine positive als auch auf eine

semi-positive oder stratifizierbare Regelmenge angewendet werden. Allerdings kann

4.2. UBERBLICK DER OPTIMIERUNGSTECHNIKEN 55

die Stratifikation bei stratifizierbaren Regeln nach der Regelkompilierung zerstortwerden. In diesem Fall konnen solche transformierten Regeln mit einem anderenVerfahren (anstatt einer einfachen Fixpunktiteration) materialisiert werden. Die imKapitel 2 angesprochenen Ansatze, wie alternierende Fixpunktberechnung (AFP-Methode) oder Fixpunktberechnung mit bedingten Fakten (CFP-Methode), stellensolche Verfahren dar.

Korrektheit von”Magic Sets“-Transformation

Sei Rmagic eine mittels der”Magic Sets“-Transformation erzeugte Regelmenge. Wie

oben bereits erwahnt, unterscheidet sich die transformierte Regelmenge Rmagic furzwei Anfragen mit gleichem Bindungsmuster, aber unterschiedlichen Konstantennur um einen seed-Fakt, der durch die jeweilige Anfrage spezifiziert wird. Deswegenbetrachtet man den seed-Fakt nicht als einen Teil von Rmagic.

Ein”adorned“-Literal pα kann als eine Anfrage p(θ) gesehen werden, so dass jedes

seiner Argumente gebunden ist, falls die entsprechende Argumentposition im Ad-ornment α als gebunden markiert ist. Man sagt dann, dass (R, pα) und (Rmagic, p

α)aquivalent sind, falls die Materialisierung dieser beiden Regelmengen die gleichenErgebnisse fur jede Instanz von pα liefert, wenn entsprechender seed-Fakt zu Rmagic

hinzugefugt wird [17].

Satz 4.1 Sei R eine positive Regelmenge und seien Rad und Rmagic entsprechenddie

”adorned“- und transformierte Regelmenege. Sei pα ein

”adorned“-Literal aus

Rad. Dann ist (R, pα) zu (Rmagic, pα) aquivalent [17].

In [17] wird außerdem gezeigt, dass bei der Auswertung einer mittels der”Ma-

gic Sets“-Transformation modifizierten Regelmenge keine fur die Beantwortung derAnfrage irrelevanten Relationen und wenige irrelevante Fakten erzeugt werden.

4.2 Uberblick der Optimierungstechniken

In der Forschungsliteratur gibt es auch viele andere Optimierungsansatze zur Anfra-gebearbeitung. Insbesondere gibt es Ansatze, die auch wie die

”Magic Sets“-Methode

auf Regelkompilierung und fixpunktbasierter Materialisierung beruhen. So konnendabei die bestimmten Spezialfalle effizienter behandelt werden oder einige Verbes-serungen bei der

”Magic Sets“-Transformation vorgenommen werden, was zur Effi-

zienzsteigerung der Anfragebeantwortung fuhrt.

Ziel dieses Abschnittes ist es, solche Optimierungstechniken zu untersuchen unddie zur Implementierung geeigneten Techniken auszuwahlen, die zur Verbesserung


der”Magic Sets“-Transformation im Regelcompiler verwendet werden konnen. Die

Idee besteht darin, dass der Regelcompiler in der Lage sein sollte, neben der”Ma-

gic Sets“-Transformation, in speziellen Fallen auch andere (effektivere) Transfor-mationen im Sinne der

”Magic Sets“-Transformation vorzunehmen oder die

”Magic

Sets“-Transformation selbst zu verbessern. Die durch den Regelcompiler modifizier-te Regelmenge sollte dann bei der Fixpunktiteration wie eine normale

”Magic Sets“-

transformierte Regelmenge behandelt werden konnen, d.h., sie muss mit ihr kompa-tibel sein.

Die”Magic Sets“-Transformation und die geeigneten Verbesserungsansatze sol-

len sich also sowohl spater in einer gemeinsamen Komponente (dem”RegelCompi-

ler“) realisieren lassen als auch in die bestehende Datenstruktur effizient integrierenlassen.

Die Kriterien fur die Auswahl der zur Implementierung geeigneten Optimierungs-techniken lassen sich dann wie folgt kurz formulieren:

• Die Optimierungen sollten regelbasiert sein, d.h. mit der”Magic Sets“- Me-

thode kompatibel sein.

• Die Optimierungstechniken sollten gut in die bestehende Datenstruktur inte-grierbar sein, bzw. sollte die Datenstruktur effizient um die benotigten Kom-ponenten erweitert werden konnen.

• Die Optimierungen sollten im Sinne der”Magic Sets“- Transformation sein.

• Der Optimierungsaufwand sollte nicht zu groß sein, um die Komplexitat desRegelcompilers nicht zu stark zu beeintrachtigen.

Im Weiteren werden unterschiedliche Optimierungstechniken beschrieben und aufihren Einsatz im

”Magic Sets“-Regelcompiler diskutiert.

4.2.1”Supplementary Magic Sets“-Transformation

Ein Nachteil der”Magic Sets“-Transformation besteht darin, dass einige identische

Daten wahrend der Fixpunktiteration wiederholt berechnet werden. Das liegt daran,dass die erzeugten

”query“- und

”answer“-Regeln fur dasselbe Bindungsmuster die

gleichen Teilausdrucke enthalten, die dann bei der Materialisierung doppelt berech-net werden mussen. Das lasst sich auch anhand der transformierten Regeln aus demBeispiel 4.2 zeigen:

answer p(X,Y )← querybf p(X), q(X,Z), answerp(Z, Y ).

answer p(X,Y )← querybf p(X), s(X,Y ).


querybf p(Z)← querybf p(X), q(X,Z).

Der Teilausdruck ′querybf p(X), q(X,Z)′ kommt sowohl in einer”query“- als

auch in einer”answer“-Regel vor, weil diese beiden Regeln aus derselben Regel

entstanden sind.

Deswegen kann hier eine Verbesserung dieser redundanten Berechnung durch-gefuhrt werden, indem zusatzliche regeldefinierte Relationen eingefuhrt werden, diediese mehrfach auftretenden Teilausdrucke zwischenspeichern. Damit konnen dieZwischenergebnisse nach einmaliger Berechnung gespeichert werden und uberall, wosie nur vorkommen, wiederverwendet werden.

Um diese Optimierungstechnik zu realisieren, wird die etwas modifizierte”Magic

Sets“-Transformation, die sogenannte”Supplementary Magic Sets“- Transformati-

on, auf eine”adorned“-Regelmenge verwendet. Die Zwischenergebnisse werden dabei

in speziellen Hilfsrelationen”supplementary magic“-Relationen gespeichert. Die Be-

schreibung dieser Transformation richtet sich nach [22].

Die Transformation lauft auch in zwei Schritten ab. Im ersten Schritt wirdeine

”adorned“-Regelmenge Rad auf die gleiche Weise wie bei der

”Magic Sets“-

Transformation erzeugt. Im zweiten Schritt wird die transformierte RegelmengeRsup−magic folgendermaßen produziert:

Fur jede”adorned“-Regel r : H ← L1, ..., Ln ∈ R

ad werden folgende Regeln erzeugt:

1. Fur jedes regeldefinierte”adorned“-Literal Li im Rumpf von r, welches Ad-

ornment β hat und auf der Position i steht, wird folgende”query“-Regel auf-

gebaut:

queryβLi ← supmagicri−1(args),

wobei queryβLi nur die Argumente von p enthalt, die im Adornment β alsgebunden markiert sind, und supmagicri−1(args) eine i-1 ”

supplementary ma-gic“-Relation ist (die genauere Erzeugung dieser Relationen wird im Punkt 2erlautert).

2. Erzeugung von”supplementary magic“-Relationen und

”supplementary ma-

gic“-Regeln.

(a) Fur den Kopf H der Regel r, der das Adornment α hat, wird die erste

”supplementary magic“-Regel wie folgt aufgebaut:

supmagicr0(args0)← queryαH.

Dabei stellen die Argumente args0 von Literal supmagicr0 die gebundenenParameter von H vor und queryαH ist ein

”query“-Literal fur Kopf H.


(b) Fur jedes Rumpfliteral Li, das auf der Position i = 1 , ... , n-1 steht, wirdeine

”supplementary magic“-Relation supmagicri (args) und eine

”supple-

mentary magic“-Regel erzeugt, die diese Relation definiert.

supmagicri (argsi)← supmagicri−1(argsi−1), Li.

Dabei sind die Argumente argsi von Literal supmagicri solche Argumente,die unter Argumenten von Literalen supmagicri−1 und Li vorkommen.

3. Wenn diese”adorned“-Regel r n Rumpfliterale enthalt, dann wird eine

”ans-

wer“-Regel mit Hilfe des letzten Literals Ln und (n-1 )-ten”supplementary“-

Relation supmagicrn−1 wie folgt aufgebaut.

answer H ← supmagicrn−1(argsn−1), Ln.

4. Schließlich wird ein seed-Fakt queryαq(θβ) zu der Anfrage q(θ)? erzeugt. Da-bei enthalt

”query“-Literal queryαq(θβ) nur die gebundenen Parameter der

Anfrage.

Beispiel 4.4 Betrachten wir wieder die”adorned“-Regelmenge aus dem Beispiel

4.2 :

r1 : pbf (X,Y )← q(X,Z), pbf (Z, Y ).

r2 : pbf (X,Y )← s(X,Y ).

Mit Hilfe der gerade beschriebenen”Supplementary Magic Sets“-Transformation

wird die folgende transformierte Regelmenge Rsup−magic erzeugt:

suppmagicr10 (X)← querybfp(X).

suppmagicr11 (X,Z)← suppmagicr10 (X), q(X,Z).

answer p(X,Y )← suppmagicr11 (X,Z), answer p(Z, Y ).

querybfp(Z)← suppmagicr11 (X,Z).

suppmagicr20 (X)← querybfp(X).

answer p(X,Y )← suppmagicr20 (X), s(X,Y ).

Wenn die”Magic Sets“-transformierten Regeln aus dem Beispiel 4.2 mit den hier

”Supplementary Magic Sets“-transformierten Regeln verglichen werden, dann wird

herausgestellt, dass der wiederholt auftretende Teilausdruck ′querybfp(X), q(X,Z)′

durch die”supplementary“-Relation suppmagicr11 (X,Z) ersetzt wird:

answer p(X,Y )← querybfp(X), q(X,Z), answer p(Z, Y ).

querybfp(Z)← querybfp(X), q(X,Z).

vergleiche mit

answer p(X,Y )← suppmagicr11 (X,Z), answer p(Z, Y ).

querybfp(Z)← suppmagicr11 (X,Z).


In [3] wird gezeigt, dass”Supplementary Magic Sets“-Transformation korrekt ist.

Satz 4.2 Seien Rad und Rsup−magic entsprechend die”adorned“- und transformierte

Regeln der Regelmenge R. Sei pα ein abgeleitetes Literal aus Rad. Dann sind (R, pα)und (Rsup−magic, p

α) aquivalent [3].

Wie man sieht, ist eine solche Verbesserung der”Magic Sets“-Transformation zur

Vermeidung von redundanten Berechnungen sehr hilfreich. Jetzt wird diskutiert, obdieser Ansatz zur Verbesserung der

”Magic Sets“-transformierten Regelmenge im

Regelcompiler verwendet werden kann. d.h., ob die oben eingefuhrten Kriterien furgeeignete Optimierungsansatze erfullt werden.

Pro und Contra der Verwendung von”Supplementary Magic Sets“-

Transformation im Regelcompiler

Fur die Verwendung dieser Optimierung im Regelcompiler spricht erstens ihre Na-tur, denn es handelt sich auch um einen transformationsbasierten Ansatz. Die Regelnwerden zunachst gemaß einer SIP-Strategie bezuglich des Adornments der Anfrageumgeordnet und dann transformiert. Insbesondere erfolgt die Erzeugung der Re-gelmenge Rad sowohl bei der

”Magic Sets“- als auch der

”Supplementary Magic

Sets“-Transformation auf dieselbe Weise. Deswegen kann man eine Realisierung die-ses Prozesses im Compiler bei beiden Transformationsarten wiederverwenden.

Daruber hinaus gestalten sich die transformierten Regeln bei der”Supplemen-

tary Magic Sets“-Transformation im Sinne der”Magic Set“-transformierten Regeln.

Es entstehen also ahnlich wie bei der”Magic Sets“-Transformation wiederum

”que-

ry“- und”answer“-Regeln. Die zusatzlichen

”supplementary“-Regeln enthalten aber

auch die”query“-Literale. Die Datenstruktur zur Regeldarstellung kann einfach um

die neuen”supplementary“-Literale erweitert werden, welche als ein Untertyp von

normalen Literalen betrachtet werden konnen, der zusatzlich zu den anderen Infor-mationen auch Informationen uber die zugehorige Regel enthalt. Somit lasst sichdieses Verfahren in die bestehende Datenstruktur einfach integrieren.

Allerdings bringt die”Supplementary Magic“-Transformation in bestimmten

Fallen weniger kompakte Darstellung, insbesondere wenn es sich um kleine Redun-danzen in einer

”Magic Sets“-transformierten Regelmenge handelt. Das kann man

auch in Beispielen 4.2 und 4.4 beobachten. Die transformierten Regeln aus Bei-spiel 4.2 enthalten nur einen kleinen gemeinsamen Ausdruck, der in zwei Regelnvorkommt. Die Beseitigung dieser Redudanz fuhrt aber zu einer großeren Regelan-zahl wie im Beispiel 4.4. In solchen Fallen (wo es um kleine Redundanzen handelt)kann man dann bei der Regelkompilierung auf die

”Supplementary Magic Sets“-

Transformation verzichten und die”Magic Sets“-Transformation anwenden. In den


meisten Fallen kann aber die”Supplementary Magic Sets“- Transformation durch-

gefuhrt werden, weil sie eine Verbesserung bei solchen redundanten Berechnungenliefert.

Zusammenfassung

Die am Anfang dieses Abschnittes aufgefuhrten Kriterien zur Auswahl einer geeig-neten Optimierungstechnik bezuglich der Implementierung im Regelcompiler sinderfullt und dieser Ansatz kann im Regelcompiler implementiert werden. Die ent-scheidenden Grunde dafur konnen wie folgt zusammengefasst werden:

1. Es ist auch ein transformationsbasiertes Verfahren.

2. Es lasst sich einfach in die bestehende Datenstruktur integrieren.

3. Die transformierte Regelmenge ist mit der”Magic Sets“-transformierten Re-

gelmenge kompatibel und kann ahnlich bei der nachfolgenden Materialisierungnoch effizienter ausgewertet werden.

4.2.2 Die Steuerung und Optimierung der SIP-Auswahl

Wie bereits erwahnt, ist die Wahl einer SIP-Strategie fur die”Magic Sets“-

Transformation sehr wichtig. Durch eine SIP-Strategie wird bestimmt, wie undwelche Variablenbindungen weitergegeben werden. Daher ist es fur eine effizienteRegelauswertung relevant, dass eine fur die Auswertung gunstige Literalreihenfolge(und entsprechend das Propagieren von Bindungen) festgelegt wird.

In vielen bisherigen Systemen wird vor allem eine left-to-right-SIP verwendet. In[19] wird die SIP-Auswahl genau untersucht. Dort wird eine spezielle Datenstruk-tur (der AND/OR-SIP Graph) zur Darstellung und Bewertung der verschiedenenSIP-Strategien vorgestellt. Auf diesem Graphen basiert dann ein Such- und Gene-rierungsalgorithmus, der eine optimale SIP-Auswahl trifft.

Im Folgenden wird dieser Graph sowie der darauf basierende Algorithmus aus[19] betrachtet. Die Idee besteht darin, unterschiedliche SIP-Strategien zu generie-ren, die mit Hilfe dieses Graphen dargestellt werden konnen. Da das Generieren al-ler moglichen SIP-Strategien zu aufwendig und daher ineffizient ist, wird der Graphmit dem Expandierungsalgorithmus nur so lange aufgebaut, wie dies zur Wahl einerguten SIP-Strategie notig ist. Ein heuristischer Such- und Generierungsalgorithmusarbeitet also auf diesem AND/OR-SIP Graphen. Dabei wird durch eine spezielle Ko-stenfunktion bestimmt, welcher Teil-SIP weiterexpandiert werden soll, d.h. welcher


SIP potenziell fur die”Magic Sets“-Transformation relevant ist. Diese Kostenfunk-

tion ist der Hauptparameter im Generierungsalgorithmus, der als HSB (HeuristicSearch Best) bezeichnet wird.

Datenstruktur: der AND/OR-SIP Graph

R[q,a] R[q,a]R[q,a]

InitnodeRulenode

SipnodeGoalnode

PfadKostenc

AND − Verbindung

c

c c c

c c

Initnode

Rulenode

Sipnode

I(p,β) I(r, γ )

I(q,α )

SIP1 c SIP2 SIP3

Goalnode

Abbildung 4.2: Prinzipielle Aufbau eines AND/OR-SIP Graphen

Im Allgemeinen besteht dieser Graph aus verschiedenen Knotentypen. JedemKnoten werden Kosten zugewiesen und abhangig von diesen Kosten wird ein oderanderer Teil-SIP ausgewahlt. Man definiert einen AND/OR-SIP Graphen G zu ei-nem Logikprogramm P und einer Anfrage qα wie folgt:

1. Der Startknoten dieses Graphen entsteht aus der Anfrage qα und wird alsInitnode I(q, α) bezeichnet.

2. Ein Initnode I(q, α) hat n AND-Nachfolger, wobei n die Anzahl der Regelnmit dem Kopf p ist. Diese AND-Nachfolger werden als Rulenodes bezeichnet.


3. Ein Rulenode R[p, α] hat k OR-Nachfolger, dabei ist k die Anzahl der SIP-Strategien, die zu dieser Regel generiert werden konnen. Diese OR-Nachfolgerwerden als Sipnodes bezeichnet.

4. Ein Sipnode Sipi hat m AND-Nachfolger, wobei m die Anzahl der Rumpfli-terale einer Regel r und durch den SIP erreichten Literale bezeichnet. DieseAND-Nachfolger stellen die neuen Initnodes dar.

5. Ein Initnode I(s, α) wird alsGoalnode bezeichnet und nicht mehr weiter expan-diert, wenn s eine Basisrelation oder bereits im G vorhanden ist. Andernfallswird ein Initnode weiterexpandiert.

6. Jedem Knoten aus G wird eine positive reelle Zahl oder ∞ zugewiesen, diemittels einer Kostenfunktion C berechnet wird. Dabei gilt: Je großer die zu-geordneten Kosten eines Knotens sind, desto schlechter wird dieser Knotenausgewertet.

In Abbildung 4.2 wird ein prinzipieller Aufbau eines AND/OR- Graphen prasentiert.

Ein Pfad L im G ist ein Losungspfad genau dann, wenn fur jeden Knoten n aus Lgilt:

• falls n ein AND-Knoten ist, dann fuhrt ein Pfad ausgehend von jedem Nach-folger von n zu einem Goalnode,

• falls n ein OR-Knoten ist, dann existiert ein Nachfolger k, so dass der Pfadausgehend von k zu einem Goalnode fuhrt,

• falls fur Kosten C(n) Folgendes gilt: C(n)< ∞.

Ein Losungspfad L ist optimal, wenn er an allen OR-Verzweigungen des GraphenG einen Knoten mit den kleinsten Kosten enthalt und die Gesamtkosten fur Lminimiert worden sind.

Die Arbeitsweise des HSB-SIP-Algorithmus

Die Idee besteht darin, einen AND/OR-Graphen zu generieren und die einzelnenKnoten mit Hilfe einer Kostenfunktion zu bewerten. Anschließend wird in diesemGraphen nach optimalen Pfaden gesucht. Die Expandierung erfolgt in einem Top-Down-Prozess, wobei die Sipnodes ausgehend von einem Initnode fur jede Regel ge-neriert werden. Fur jeden generierten Sipnode werden seine Kosten berechnet undmit Hilfe der Kostenfunktion C bewertet. Dabei werden solche Sipnodes weiterex-pandiert, die die besten regellokalen (d.h. basierend auf nur einer Regel) Kosten


haben. Die Kostenberechnung erfolgt hierbei in einem Bottom-Up-Prozess, bei demdie Kosten der entstandenen Rulenodes berechnet und nach oben propagiert wer-den. Das Bottom-Up-Abandern der Knotenkosten wird dabei mit einer Auswahl desaktuellen Pfades im Graphen kombiniert. Unter Umstanden ist hier Backtrackingerforderlich.

Mogliche SIP-Strategien und ihre Kostenfunktionen

Es konnen unterschiedliche SIP-Strategien fur den HSB-SIP Algorithmus verwen-det werden (vgl. [19]). Sie konnen in zwei Gruppen aufgeteilt werden. Das sind diestatischen und dynamischen Strategien, welche auf der Struktur der Regeln undentsprechend auf den Machtigkeiten der Relationen basieren. Dabei konnen die sta-tischen SIP-Strategien in zwei Gruppen aufgeteilt werden, namlich in regellokaleund regelglobale Strategien. Die regellokalen Strategien betrachten dabei nur denAufbau einer Regel, wahrend die regelglobalen Strategien die ganze Regelmengeberucksichtigen.

Im Abschnitt 4.1.2 wurden bereits die statischen regellokalen SIP-Strategien(most-boundet, minfree und left-to-right) betrachtet. Die Kostenfunktion zum Bei-spiel fur eine left-to-right-SIP-Strategie wird wie folgt definiert:

C(Sipnode) = if left-to-right SIP then 0 else∑

Anzahl der Abweichungen.

Zusatzlich sind auch andere Heuristiken denkbar. Eine Heuristik besagt dabei,dass die Basisrelationen bei der Wahl des nachsten Kandidaten zum Propagierenvon Bindungen vor den regeldefinierten Relationen bevorzugt werden. Das erfolgtunter der Annahme, dass viele Argumentpositionen von regeldefinierten Relationenmoglichst fruh gebunden werden konnen. Eine Kostenfunktion kann in diesem Fallwie folgt definiert werden:

C(Sipnode) =∑∀Tail∈Sipnode

∑∀p∈Tail

if p = Basisrelation then 0 else 1

Eine der regelglobalen Strategien ist zum Beispiel die Minimierung der Großeder

”adorned“-Regelmenge. Dabei wird bei der Berechnung der Kostenfunktion auch

die Anzahl der Rulenodes berucksichtigt. Allerdings kann es dazu fuhren, dass dergesamte AND/OR-Graph aufgebaut wird.

Bei dynamischen SIP-Strategien (Strategien uber Relationsgroßen) konnen Heu-ristiken wie die Extension der relevanten Relationen oder die Bevorzugung der Re-lationen, deren gebundene Argumente eine moglichst hohe Selektivitat aufweisen,berucksichtigt werden.

Es ist auch eine Kombination aller Heuristiken denkbar. Dabei kann eine Kosten-funktion als die gewichtete Summe aller zu den entsprechenden Heuristiken gehoren-den Kostenfunktionen definiert werden.


C(Sipnode) =∑|Heiristiken|

i=1 gi Ci(S)

Dabei konnen bestimmte Heuristiken durch eine Zuordnung der unterschiedli-chen Gewichte gi bevorzugt werden. Diese Gewichte konnen experimentell ermitteltwerden.

Pro und Contra des Einsatzes eines AND/OR-Graphen und des daraufbasierenden Algorithmus im Regelcompiler

Fur die Verwendung dieses Verfahrens spricht vor allem die Moglichkeit, nicht nurleft-to-right SIP-Strategien (gemaß der Aufschreibungsreihenfolge der Rumpflitera-le) zu bestimmen, sondern auch andere Heuristiken zu berucksichtigen. Es konnensichere SIP-Strategien unter Benutzung von mehreren Heuristiken generiert werden.

Allerdings benotigt dieses Verfahren fur die Bestimmung einer guten SIP-Strategie eine spezielle eigene Datenstruktur (AND/OR-Graph), weil der HSB-SIP-Algorithmus auf diesem AND/OR-Graphen arbeitet, welcher eine spezielle Form(Knoten) zur Darstellung eigener Parameter enthalt. Um diesen Graphen generie-ren und verwalten zu konnen, werden zum Beispiel folgende neue Elemente (Klassen)wie etwa AndOrGraph, SipNode, InitNode, RuleNode benotigt. Diese Datenstrukturstellt somit eine andere Art der Darstellung von Datalog-Regeln als eine im Kapitel3 vorgestellte Datenstruktur, welche eine effiziente Anfragebearbeitung unterstutzt.Das fuhrt dazu, dass fur die SIP-Generierung eine zusatzliche Datenstruktur zurGraphendarstellung und Bearbeitung erstellt werden sollte, die einen eigenen Abar-beitungsmechanismus enthalt. Es ist aber nicht effizient, die Regelverarbeitung undSIP-Generierung basierend auf zwei verschiedenen Datenstrukturen durchzufuhren.Es sollte also moglich sein, eine gute SIP-Generierung basierend auf der gleichen Da-tenstruktur auszufuhren, die zur Regeldarstellung dient (vgl. Kapitel 3) und vieleHilfsmethoden auch zur SIP-Generierung bietet.

Des Weiteren sollte die Bestimmung einer guten SIP-Strategie bei dem hier vor-gestellten Verfahren (HSB-SIP-Algorithmus) zur Laufzeit erfolgen, also zum Ad-ornment der gestellten Anfrage. Bei der

”Magic Sets“-Transformation musste dann

die Generierung, Expandierung und Bewertung der erstellten SIP-Strategien (bzw.jedes Knoten im AND/OR-Graphen) in der Phase der Adornments-Propagierungauch zur Laufzeit erfolgen. Das hat den Nachteil, dass es unter Umstanden dabeizu einer enormen zusatzlichen Erhohung der Komplexitat der Anfragebearbeitungfuhren kann, insbesondere wenn die Regelmenge groß ist.

In einem deduktiven Datenbanksystem ist es moglich und sinnvoll, die Regeln,wie bereits erwahnt, im Voraus fur alle Anfragemuster zu transformieren (precompi-le). Zur Anfragebeantwortung wird dann nur ein konkreter seed -Fakt (zum Adorn-ment der Anfrage) in die Datenbank hinzugefugt, und die bereits transformierten


Regeln werden anschließend materialisiert. Der HSB-SIP-Algorithmus kann daherbei der precompile-Transformation nicht verwendet werden, denn seine Starke liegtim Generieren einer SIP-Strategie zu einer konkreten Anfrage zur Laufzeit.

Zusammenfassung

Eine direkte Umsetzung dieses Verfahrens im Regelcompiler ist also nicht effizient.Zur Verbesserung der Effizienz der

”Magic Sets“-Methode es ist aber sinnvoll, auch

andere als die left-to-right SIP-Strategien zu berucksichtigen, bzw. unterschiedlicheSIP-Strategien erzeugen zu konnen.

Mit der bestehenden Datenstruktur lasst sich das umsetzen (im Kapitel 5 wirdes genauer dargestellt). Dabei werden dynamische SIP-Strategien nicht einbezogen,weil diese mit der

”Magic Sets“-Transformation nicht kompatibel sind und außer-

dem Informationen uber Relationsgroßen beim Regelkompilieren nicht bekannt sind.Wenn nur die statischen SIP-Strategien betrachtet werden, dann lassen sich sol-che Heuristiken wie zum Beispiel minfree oder most-bounded mit der Datenstruk-tur zur Regeldarstellung (vgl. Kapitel 3) realisieren. Wegen ihrer Listendarstellungermoglicht die Datenstruktur zur Regeldarstellung eine einfache und effiziente Ver-arbeitung von Rumpfliteralen.

Bei der Bestimmung einer guten SIP-Strategie im Regelcompiler kann eine Ko-stenfunktion bezuglich der Anzahl von freien oder gebundenen Argumenten jedesLiterals berucksichtigt werden. Dabei werden nicht alle moglichen SIP-Strategienwie im oben dargestellten HSB-Verfahren erzeugt und dann bewertet (d.h. auchungunstige, die spater bei der Bewertung wegfallen). Sondern die

”besseren“ SIP-

Strategien bezuglich der bekannten Heuristiken zur Bestimmung einer guten SIP-Strategie (wie etwa minfree)konnen direkt erzeugt werden. Bei Bedarf wird es auchmoglich sein, zum Beispiel anhand von Kosten fur die erhaltene Regel, zwischen meh-reren SIP-Strategien nach besseren Kosten auswahlen zu konnen. Die regelglobalenSIP-Strategien, wie zum Beispiel das Minimieren der Anzahl von

”adorned“-Regel,

werden hier aber nicht berucksichtigt. In diesem Fall kann dennoch eine Verbesse-rung realisiert werden, die darin besteht, die redundant erzeugten Regeln (also diedie bis auf die Variablenumbenennung gleichen Literale mit dem gleichen Adornmententhalten) zu eliminieren. Im Regelcompiler sollte es zudem moglich sein, beliebigeweitere Heuristiken realisieren zu konnen.

4.2.3 Effiziente Auswertung von linearer Rekursionen

Wie bereits angesprochen, gibt es Spezialfalle, in denen die”Magic Sets“-

Transformation noch effizienter durchgefuhrt werden kann, wenn spezielle Beson-derheiten von Regeln berucksichtigt werden.


Im Folgenden wird eine transformationsbasierte Methode (vgl. [16]) beschrie-ben, die fur eine Teilmenge rekursiver Regeln (welche spater naher erlautert wer-den) bessere Ergebnisse als die

”Magic Sets“-Transformation liefert. Das ist damit

verbunden, dass die Stelligkeit von rekursiven Literalen in den mittels dieser Trans-formation modifizierten Regeln (im Unterschied zu den mittels der

”Magic Sets“-

Transformation modifizierten Regeln) kleiner als in ursprunglichen Regeln ist. Sowerden fur eine Datenbank der Große O(n)(mit n > 0) O(n) Fakten bei dieser Trans-formation im Unterschied zu O(n2) Fakten bei der

”Magic Sets“-Transformation ge-

neriert. Fur eine große Datenbank (große n) ist diese Verbesserung sehr wichtig, umdie irrelevanten Berechnungen nicht durchzufuhren. Alle Antworten zu einer Anfragewerden mit dem in [16] vorgestellten Algorithmus in linearer Zeit gefunden.

Die Regeln, auf die diese Transformationsmethode angewendet werden kann,konnen in vier Kategorien aufgeteilt werden: rechts-lineare Rekursionen, links-lineareRekursionen, gemischte Rekursionen, die sowohl rechts-lineare als auch links-lineareRegeln enthalten konnen und multilineare Rekursionen. Im Weiteren werden allediese Kategorien von rekursiven Regeln formal definiert und ihre Transformationwird vorgestellt.

Rechts-lineare Regeln

Definition 4.1 (Rechts-lineare Regeln) Sei R eine Menge von Datalog-Regeln,die nur eine einzige regeldefinierte Relation p enthalten kann. Sei pα eine

”adorned“-

Anfrage. Dann heißt die Regelmenge R hinsichtlich des gegebenen Adornments αrechts-linear, wenn jede rekursive Regel r ∈ R folgende Form hat:

p(X1, ..., Xm, Y1, ..., Yn)← G1, ..., Gk, p(W1, ...,Wm, Y1, ..., Yn),

wobei o.B.d.A angenommen wird, dass m die linkeste gebundene Position von phinsichtlich des Adornments α ist, und folgende Bedingungen erfullt sind:

• G1, ..., Gk sind Literale, die Basisrelationen referenzieren (d.h., dass r nur eineinziges abgeleitetes Literal enthalt),

• alle Yi sind paarweise verschieden und jeder Yi kommt genau zwei mal in dieserRegel vor, einmal im Kopf und einmal im rekursiven Literal (auf der gleichenPosition wie im Kopf),

• jeder Term Wi kommt entweder in Literalen G1, ..., Gk oder unter ArgumentenX1, ..., Xm vor.

Aus diesen Bedingungen folgt, dass, wenn der Kopf p das Adornment α hat (pα)und ein Rumpfliteral p das letzte Rumpfliteral ist, dann bekommt p nach einerSIP-Strategie auch das Adornment α.


Außerdem wird gewahrleistet, dass bei der Auswertung dieser Regel jede Antwortauf das rekursive Literal p direkt auch eine Antwort auf das Kopfliteral liefert, weildie freien Argumente von p mit den freien Argumenten des Kopfes ubereinstimmen.

Beispiel 4.5 (Eine rechts-lineare Regelmenge) Sei p(x0, Y ) ? eine Anfrageund seien die Regeln r1 und r2 wie folgt gegeben:

r1 : p(X,Y )← q(X,Z), p(Z, Y ).

r2 : p(X,Y )← q(X,Y ).

Diese Regelmenge ist rechts-linear, weil diese Regeln nur ein regeldefiniertes Literalp enthalten, und die rekursive Regel r1 ein einziges rekursives Literal besitzt. Wennman außerdem die

”adorned“-Regel pbf (X,Y )← q(X,Z), pbf (Z, Y ) betrachtet, dann

sieht man, dass alle Bedingungen bezuglich freien oder gebundenen Argumente desrekursiven Literals pbf (Z, Y ) erfullt sind (die freie Variable Y kommt nur im Regel-kopf und diesem rekursiven Literal vor, Variable Z ist gebunden).

Die Transformation einer rechts-linearen Regelmenge R in eine effizientere alsbei der

”Magic Sets“-Transformation auswertbare Regelmenge wird wie folgt durch-

gefuhrt:

1. Fur jede wie oben definierte rechts-lineare rekursive Regel

p(X1, ..., Xm, Y1, ..., Yn)← G1, ..., Gk, p(W1, ...,Wm, Y1, ..., Yn).

wird eine”query“-Regel erzeugt

query p(W1, ...,Wm)← p(X1, ..., Xm), G1, ..., Gk.

wobei query p ein”query“-Literal ist, das nur die gebundenen Argumentposi-

tionen von p enthalt.

2. Zu der Anfrage wird ein seed -Fakt query p(x1, ..., xm) erzeugt, wobei x1, ..., xmKonstanten der Anfrage sind.

3. Fur jede nicht rekursive Regel (Basisregel)

p(X1, ..., Xm, Y1, ..., Yn)← G1, ..., Gk.

wird eine”answer“-Regel folgendermaßen erzeugt:

answer p(Y1, ..., Yn)← query p(X1, ..., Xm), G1, ..., Gk.

wobei ein”answer“-Literal ist, das nur die freien Argumentpositionen von p

enthalt. Es ist zu beachten, dass ein”answer“-Literal alle Argumente eines

Literals bei der”Magic Sets“-Transformation enthalt.


4. Schließlich kann die Antwort auf die Anfrage p(x1, ..., xm, Y1, ..., Yn)? mit Hilfefolgender Regel ermittelt werden:

p(x1, ..., xm, Y1, ..., Yn)← answer p(Y1, ..., Yn),

wobei x1, ..., xm Konstanten der Anfrage sind.

Die so transformierte Regelmenge R wird als reduzierte Regelmenge (Rred) be-zeichnet.

Links-lineare Regeln

Definition 4.2 (Links-lineare Regeln) Sei R eine Menge von Datalog-Regeln,die nur eine einzige regeldefinierte Relation p enthalten kann. Sei pα eine

”adorned“-

Anfrage. Dann heißt die Regelmenge R hinsichtlich des gegebenen Adornments αlinks-linear, wenn erstens die Kopfliterale aller Regeln (sowohl rekursiver als auchnicht rekursiver) unterschiedliche Variablen auf gebundenen Positionen haben, undzweitens jede rekursive Regel r ∈ R folgende Form hat:

p(X1, ..., Xm, Y1, ..., Yn)← p(X1, ..., Xm, V1, ..., Vn), G1, ..., Gk,


• G1, ..., Gk sind Literale, die Basisrelationen referenzieren (d.h. dass r nur eineinziges abgeleitetes Literal enthalt),

• jeder Term Yi ist paarweise von X1, ..., Xm verschieden und ebenso ist jederTerm Vi paarweise von X1, ..., Xm verschieden,

• kein Term Xi kommt in Literalen G1, ..., Gk vor.

Falls die ersten zwei Bedingungen erfullt sind und nur die letzte Bedingung nichterfullt ist, wird R als pseudo-links-linear bezeichnet.

Beispiel 4.6 (Eine links-lineare Regelmenge) Sei p(x0, Y )? eine Anfrage undseien die Regeln r1 und r2 wie folgt gegeben:

r1 : p(X,Y )← p(X,Z), q(Z, Y ).

r2 : p(X,Y )← q(X,Y ).

Diese Regelmenge ist links-linear, weil diese Regeln nur ein regeldefiniertes Literalp enthalten, und die rekursive Regel r1 ein einziges rekursives Literal besitzt. Außer-dem wenn man die

”adorned“-Regel pbf (X,Y )← pbf (X,Z), q(Z, Y ) betrachtet, stellt


sich heraus, dass alle Bedingungen bezuglich der freien oder gebundenen Argumentedes rekursiven Literals pbf (X,Z) erfullt sind (Terme X und Y sowie X und Z sindpaarweise verschieden, gebundene Variable X kommt in keinem anderen Rumpfliteralvor).

Die Transformation einer links-linearen Regelmenge R in eine effizientere alsbei der

”Magic Sets“-Transformation auswertbare Regelmenge wird wie folgt durch-

gefuhrt:

1. Fur jede wie oben definierte pseudo-links-lineare rekursive Regelp(X1, ..., Xm, Y1, ..., Yn) ← p(X1, ..., Xm, V1, ..., Vn), G1, ..., Gk wird eine

”ans-

wer“-Regel erzeugt

answer p(Y1, ..., Ym)← answer p(V1, ..., Vm), σ(G1), ..., σ(Gk),

wobei answer p ein”answer“-Literal ist, das nur die freien Argumentpositio-

nen von p enthalt, und σ eine Substitution ist, bei der jede Variable Xi durcheine Konstante xi ersetzt wird. x1, ..., xm sind dabei gebundene Parameter(Konstanten) der Anfrage.

Es ist zu beachten, dass wenn es sich dabei um eine links-lineare Regel handelt,die Substitution σ nicht benotigt wird, da keine X1 in G1, ..., Gk vorkommen:

answer p(Y1, ..., Ym)← answer p(V1, ..., Vm), G1, ..., Gk.

2. Fur jede nicht rekursive Regel (Basisregel)p(X1, ..., Xm, Y1, ..., Yn)← G1, ..., Gk wird eine

”answer“-Regel folgendermaßen

erzeugt:

answer p(Y1, ..., Ym)← sigma(G1), ..., σ(Gk).

3. Schließlich kann die Antwort auf die Anfrage p(x1, ..., xm, Y1, ..., Yn)? mit Hilfefolgender Regel ermittelt werden:

p(x1, ..., xm, Y1, ..., Yn)← answer p(Y1, ..., Yn),

wobei x1, ..., xm Konstanten der Anfrage sind.

Gemischt-lineare Regeln

Definition 4.3 (Gemischt-lineare Regeln) Sei R eine Menge von Datalog-Regeln, die nur eine einzige regeldefinierte Relation p enthalten kann. Sei pα eine

”adorned“-Anfrage. Dann wird die Regelmenge R hinsichtlich des gegebenen Adorn-

ments α als gemischt-linear bezeichnet, wenn jede ihrer rekursiven Regel entwederrechts-linear oder links-linear ist.


Die Transformation von gemischt-linearen Regeln wird folgendermaßen durch-gefuhrt:

1. Die rechts-linearen Regeln werden gemaß der Transformation fur die rechts-linearen Regeln transformiert.

2. Die links-linearen Regeln werden gemaß der Transformation fur die links-linearen Regeln transformiert.

3. Die Basisregeln werden auch gemaß der Transformation fur die rechts-linearenRegeln transformiert.

Beispiel 4.7 (Transformation einer gemischt-linearen Regelmenge) Seip(x0, Y, Z)? eine Anfrage und sei die Regelmenge R wie folgt gegeben:

r1 : p(X,Y, Z)← q(X,Y, Z).

r2 : p(X,Y, Z)← a(X,A), p(A, Y, Z).

r3 : p(X,Y, Z)← p(X,B,Z), b(Y,B).

r4 : p(X,Y, Z)← p(X,Y,C), c(Z,C).

Zunachst bestimmt man den Typ jeder Regel. Offensichtlich ist die Regel r1 eineBasisregel, da sie keine rekursiven Literale enthalt. Da bff Adornment der Anfra-ge p(x0, Y, Z) ist, ist r2 eine rechts-lineare Regel (Adornment des rekursiven Lite-rals pbff (A, Y, Z)) und r3, r4 sind links-lineare Regeln (mit den rekursiven Literalenpbff (X,B,Z) und entsprechend pbff (X,Y,C)).

Die reduzierte Regelmenge Rred ist dann die Folgende:

query p(x0). (seed-Fakt)

query p(A)← query p(X), a(X,A). (”query“-Regel aus r2)

answer p(Y, Z)← answer p(B,Z), b(Y,B). (”answer“-Regel aus r3)

answer p(Y, Z)← answer p(Y,C), c(Z,C).(”answer“-Regel aus r4)

answer p(Y, Z)← query p(X), q(X,Y, Z). (”answer“-Regel aus r1)

p(x0, Y, Z)← answer p(Y, Z). (Antwort auf die Anfrage)

Es ist zu beachten, dass wahrend die rechts-lineare Regel r2 zum Produzieren neuerBindungen dient, die links-linearen Regeln r3 und r4 neue Antworten erzeugen. DieBasisregel r1 wird dabei zum Initialisieren der Berechnung von

”answer“-Relationen

verwendet.


Multi-lineare Regeln

Definition 4.4 (Multi-lineare Regeln) Sei R eine Menge von Datalog-Regeln,die nur eine einzige regeldefinierte Relation p enthalten kann. Sei pα eine

”adorned“-

Anfrage. Dann heißt die Regelmenge R hinsichtlich des gegebenen Adornments αmulti-linear, wenn jede ihrer rekursiven Regeln entweder rechts-linear, links-linearoder multi-linear ist. Dabei hat jede multi-lineare Regel folgende Form:

p(X1, ..., Xm, Y1, ..., Yn)← G1, ..., Gk, p(W1, ...,Wm, Y1, ..., Yn),


• Alle Xi sind paarweise verschieden und konnen ausschließlich in rekursivenLiteralen vorkommen (auf gleichen Argumentpositionen wie im Regelkopf).

• Falls Gi(i=1,...,k) ein rekursives Literal ist, dann enthalten seine ersten m Ar-gumentposition genau die gebundenen Argumente des Kopfes X1, ..., Xm undauf den restlichen Argumentposition stehen Variablen, die von X1, ..., Xm paar-weise verschieden sind.

• Falls Gi (i=1,...,k) ein Basisliteral ist, dann kann keine seiner Variablen einevon X1, ..., Xm sein.

• Alle Terme Yi sind paarweise verschieden und jeder Term Yi kommt genau zweimal in dieser Regel vor, einmal im Kopf und einmal im rekursiven Literal (aufder gleichen Position wie im Kopf).

• Jeder Term Wi muss in Literalen G1, ..., Gk vorkommen und muss sich vonTermen X1, ..., Xm unterscheiden.

Beispiel 4.8 (Eine multi-lineare Regel) Sei p(x0, Y, Z)? eine Anfrage und seieine Regel r wie folgt gegeben:

p(X,Y, Z)← p(X,W, V ), b(U, V ), p(X,W,U), p(W,Y, Z).

Diese Regel ist laut der Definition 4.4 multi-linear. Es ist zu beachten, dass das Ad-ornment von rekursiven Literalen (ausgenommen des letzten) nicht unbedingt gleichdem Adornment der Anfrage sein sollte. Das kann man in der

”adorned“-Version

dieser Regel sehen:

pbff (X,Y, Z)← pbff (X,W, V ), b(V, U), pbbb(X,W,U), pbff (W,Y, Z).


Die Transformation einer Regelmenge, die links-lineare, rechts-lineare undmulti-lineare Regeln enthalt, geschieht nach folgendem Prinzip:

1. Zunachst werden alle rekursiven Literale (ausgenommen das letzte Literal) injeder multi-linearen Regel durch

”answer“-Literal, das nur die freien Argumen-

te dieses Literals enthalt, ersetzt.

2. Weiter werden die links-linearen Regeln gemaß der Transformation fur dielinks-linearen Regeln und alle anderen gemaß der Transformation fur dierechts-linearen Regeln modifiziert. Dabei werden die im ersten Schritt durch

”answer“-Literale ersetzten rekursiven Literale als Basisrelationen behandeltund dann werden die multi-linearen Regeln wie die rechts-linearen transfor-miert.

Satz 4.3 Die transformierte Regelmenge Rred erzeugt die gleichen Antworten wiedie ursprungliche Regelmenge R und ihre Auswertung ist mindestens so effizient wieeine Auswertung einer

”Magic Sets“-transformierten Regelmenge Rmagic.

Pro und Contra der Verwendung dieses Verfahrens im Regelcompiler

Fur das Verwenden dieses Verfahrens zur Verbesserung der”Magic Sets“-

Transformation sprechen viele Argumente. Erstens liefert dieses Verfahren gegenuberder

”Magic Sets“-Transformation fur eine Klasse rekursiver Regeln eine viel effizi-

enter auswertbare Regelmenge (um den Faktor O(n) schneller).

Außerdem ist es auch ein transformationsbasierter Ansatz. Die Regeln werdendabei zunachst transformiert und dann mittels Fixpunktiteration materialisiert. DesWeiteren werden bei der Transformation zunachst eine

”adorned“-Regelmenge und

erst dann die neuen Regeln erzeugt. Das lauft ahnlich wie bei der”Magic Sets“-

Transformation ab. Das bedeutet, dass dieses Verfahren sich gut (bzgl. seines Ab-laufs) mit der

”Magic Sets“-Transformation kombinieren lasst.

Zudem sind die dabei entstehenden Regeln mit den”Magic Sets“-transformierten

Regeln kompatibel. So werden auch”query“- und

”answer“- Regeln erzeugt, welche

die”query“- und

”answer“-Literale enthalten konnen. Das heißt, dass die gleiche

Datenstruktur zur Regeldarstellung wie fur die”Magic Sets“-Transformation ver-

wendet werden kann bzw. sie sehr einfach um eine neue etwas veranderte Art des

”answer“-Literals erweitert werden kann, welches nur die freien Argumente einesLiterals enthalt. Diese transformierten Regeln konnen dann genau so wie

”Magic

Sets“-transformierte Regeln materialisiert werden.

Da aus einer Regel entweder eine”query“ (aus einer rechts-linearen Regel)

oder eine”answer“-Regel (aus links-linearen, multi-linearen und Basisregeln) er-

zeugt wird, wird dabei das Problem der redundant vorkommenden Ausdrucke in


Regelrumpfen nicht auftreten. Deswegen muss hier eine”Supplementary Magic

Sets“-Transformation nicht durchgefuhrt werden und somit stellt dieser Ansatz eineunabhangige Optimierung dar. Daruber hinaus sind auch andere bereits beschrie-bene Verbesserungsansatze wie etwa verschiedene auf Heuristiken basierende SIP-Strategien mit diesem Ansatz kompatibel. Dabei sollte lediglich sichergestellt wer-den, dass die gewunschten Bedingungen zum Beispiel bezuglich bestimmten freienoder gebundenen Positionen von rekursiven Literalen erfullt sind.

Ein moglicher Nachteil dieses Optimierungsansatzes besteht darin, dass einezusatzliche Regelanalyse vor eigentlicher Transformation notwendig ist, um fest-zustellen, ob alle Bedingungen einer multi-linearen Regelmenge erfullt sind. Erfolgtallerdings eine precompile-Transformation, d.h erfolgt das Regelkompilieren im Vor-aus fur unterschiedliche Anfragemuster, dann ist es irrelevant, ob eine Regelanalyseausgefuhrt wird. Fur die nachfolgende Auswertung ist es entscheidend, dass die sotransformierte Regelmenge effizienter materialisiert werden kann. Erfolgt außerdemeine Regelkompilierung zur Laufzeit (on demand), so kann die Regelanalyse schnel-ler ausgefuhrt werden, indem sie in Teile zerlegt wird, welche nacheinander gepruftwerden konnen. Wenn zum Beispiel eine Bedingung verletzt ist, so kann das Testenvon Bedingungen jederzeit abgebrochen werden, anstatt ein komplettes Testen allerBedingungen (was moglicherweise zu einem negativen Ergebnis fuhren kann) weiterdurchzufuhren.

Zusammenfassung

Dieser Optimierungsansatz kann im Regelcompiler zur Verbesserung der”Magic

Sets“-Transformation realisiert werden, da er zum einen mit der”Magis Sets“-

Transformation kompatibel ist (namlich einen Spezialfall darstellt) und zum anderensich die bestehende Datenstruktur zur Regeldarstellung fur seine Realisierung eig-net. Das hat den Vorteil, dass die transformierten Regeln unabhangig von der Artder Transformation immer einheitlich sind. Außerdem passt dieser Ansatz auch zuden anderen Verbesserungsmethoden.

4.2.4 Effiziente Materialisierung von”Magic Sets“-

transformierten Regeln

Eine weitere Verbesserung der Anfragebearbeitung kann wahrend der Materialisie-rungsphase vorgenommen werden. Bei der Bottom-Up-Materialisierung der

”Magic

Sets“-transformierten Regelmenge soll ein wiederholtes Berechnen der bereits ab-geleiteten Fakten vermieden werden. Sonst wird zum Beispiel eine Ableitung vonFakten, die fur eine

”query“-Relation querybfp(a) erzeugt wurden, bei der Ablei-

tung von Fakten fur querybbp(a, a) wiederholt. Dabei ist querybfp) allgemeiner als


querybbp und enthalt schon alle moglichen ableitbaren Fakten, die fur querybbp er-zeugt werden konnen.

Dazu sollte eine Uberprufung der Subsumption (dieser Begriff wird im Weiterendefiniert) von einer Literalen durch die anderen durchgefuhrt werden. Die Uber-prufung der Subsumption von

”query“-Relationen ist in traditionellen Anwendun-

gen schwierig, weil sich (”adorned“-)

”query“-Literale syntaktisch unterscheiden. So

werden beispielsweise pbb und pbf als unterschiedliche Literale betrachtet und damitdie Antworten fur pbf konnen nicht fur pbb benutzt werden.

Zur Losung dieses Problems (Behandlung von”query“-Literalen beim Testen

der Supsumption) werden in [1] zwei Techniken vorgeschlagen: erstens eine ande-re Adornments-Behandlung und zweitens ein neuer Algorithmus zum Testen derSubsumption von

”query“-Literalen.

Das Ziel einer anderen Adornments-Propagierung besteht darin, keine explizi-ten Adornments allen Literalen bis auf die

”query“-Literale zuzuordnen, damit fur

die nachfolgenden Algorithmen (bzw. Vergleiche) keine syntaktischen Unterschie-de zwischen einem Literal und seiner

”adorned“-Version entstehen. Das Vergleichen

von”query“-Literalen wird im nachsten Algorithmus behandelt. Es werden also nur

”query“-Literale ein explizites Adornment bekommen (zum Beispiel querybfp undquerybbp).

An dieser Stelle ist zu beachten, dass ein Verzicht auf explizite Adornments inRumpfliteralen zu einem Nachteil bei der Auswertung fuhren kann. Allerdings wirddieser Schritt mit der Datenstruktur zur Regeldarstellung, die im Kapitel 3 vor-gestellt wurde, nicht benotigt. Die Schwierigkeit bei der Behandlung von Literalenund ihren

”adorned“-Versionen wird hier behoben, weil die einzelnen Literale nicht

als syntaktische Einheiten (Strings, die diese Literale darstellen), sondern als ei-gene Objekte mit ihren Eigenschaften modelliert wurden. Deswegen werden solcheOperationen wie zum Beispiel das Vergleichen von zwei Literalen nicht nach ih-rer Schreibweise (zum Beispiel fur

”p(X,Y)“ und

”pbf (X,Y )“) ausgefuhrt, sondern

auf das Vergleichen entsprechender relevanter Attribute (wie etwa name, adornmentetc.) zuruckgefuhrt. Die Modellierung der Literale ist also von der Form ihrer gra-phischen Darstellung unabhangig und daher wird ein Verzicht auf die explizitenAdornments nicht benotigt.

Im Folgenden wird der allgemeine Begriff der ’Subsumption’ definiert.

Definition 4.5 (Subsumption) Ein Atom G subsumiert ein Atom S (G w S),wenn eine Substitution θ existiert, so dass Gθ = S gilt.

Es stellt sich die Frage, wie man Subsumption von”query“- bzw.

”adorned“-

Literalen testet. Dabei sollte auch das Adornment des Literals einbezogen werden.


In [1] wird jedes”query“-Literal in ein spezielles neues Literal uberfuhrt, auf dem

das Testen der Subsumption einfacher durchzufuhren ist. Dabei wird das Adornmenteines Literals unter den Argumenten eines Literals integriert, und damit wird einLiteral kein explizites Adornment mehr besitzen. So wird zum Beispiel das

”query“-

Literal querybfbbfp(a, b, c) in das Literal p(a,X,b,c,Y) ubersetzt.

Da, wie bereits erwahnt, eine Sonderbehandlung von Adornments bei der beste-henden Datenstruktur nicht mehr erforderlich ist, wird auf eine detaillierte Beschrei-bung dieser Uberfuhrung verzichtet und auf [1] verwiesen. Im Weiteren werden diePrinzipien des Testens auf Subsumption (aus [1]) vorgestellt, das sich ohne zusatz-liche Modifikationen mit der bestehenden Datenstruktur realisieren lasst.

Zunachst wird eine andere Definition der ’Subsumption’ eingefuhrt.

Definition 4.6 (Subsumption’) Ein Atom G subsumiert ein Atom S (G w S),wenn eine Substitution θ existiert, so dass θ = m.g.u(G,S) und Sθ = S gilt. Dasbedeutet, dass Atom G ein Atom S subsumiert, wenn m.g.u 1 (most general unifier)von S und G keine Variable von S bindet.

Beispiel 4.9 Das Literal p(X,Y,2,Z) subsummiert das Literal p(X,5,2,Z), weil eineVariablensubstitution Y/5 existiert, die das p(X,Y,2,Z) gleich dem Literalp(X,5,2,Z) macht.

Das Literal p(X,Y,2,Z) subsummiert aber das Literal p(X,5,10,Z) nicht, weil kei-ne Variablensubstitution existiert, die das p(X,Y,2,Z) gleich dem Literal p(X,5,10,Z)macht. Das ist damit verbunden, dass auf der Position 3 in diesen zwei Literalenunterschiedliche Konstanten stehen

Um zu testen, ob ein Literal Gα ein anderes Literal Sβ subsumieren kann, werdenzunachst ihre Adornments betrachtet. Dabei wird untersucht, ob Variablen von S(freie Argumente, die als ’f’ markiert sind) in G gebunden sein konnen, d.h. obentsprechende Argumentpositionen in G frei sind (auch als als ’f’ markiert sind).Ihre Adornments werden betrachtet, weil sie alle Informationen uber die freien odergebundenen Argumente von Literalen enthalten. Anhand dieses Vortestes kann manerkennen, ob ein Literal Gα potenziell (unabhangig von konkreten Konstanten aufgebundenen Positionen) ein anderes Literal Sβ subsumieren kann oder nicht. Wenndiese Uberprufung ein positives Ergebnis liefert, dann werden entsprechende Argu-mente auf gebundenen Positionen dieser Literale verglichen. So subsumiert beispiels-weise im Beispiel 4.9 das Literal p(X,Y,2,Z) das andere Literal p(X,5,10,Z) nicht,

1m.g.u bezeichnet einen allgemeinsten Unifikator. Ein Unifikator ist eine Variablensubstitution,die Atome identisch macht. Ein Unifikator θ wird als allgemeinster Unifikator (m.g.u) fur AtomeG und S bezeichnet, wenn fur jeden weiteren Unifikator θ’ eine Variablensubstitation σ existiert,so dass θσ = θ’gilt.


weil seine gebundenen Argumente mit gebundenen Argumenten des anderen Literalsnicht ubereinstimmten.

Die Idee dieses Algorithmus wird wie folgt zusammengefasst: Ein Literal Gα

subsumiert das Literal Sβ, wenn Folgendes gilt:

subsumes(Gα, Sβ)↔ or(a, b, b) ∧match(G,S).

Zum Testen des Adornments (in or(a,b,b) ) kann jedes Adornment als eine Bit-folge interpretiert werden, und zwar so, dass jeder Buchstabe ’f’ eine Ziffer 0 undjeder ’b’ eine 1 entspricht (zum Beispiel bfbff wird als 10100 interpretiert). Dannwerden diese Bitfolgen mit einer Operation der Logik OR verknupft. Falls das Ergeb-nis dieser Verknupfung mit der Bitfolge von S ubereinstimmt, bedeutet das, dass Gpotenziell S subsumieren kann. Das gilt, weil das Ergebnis dieser OR-Verknupfungfreie/gebundene Argumentpositionen beider Atome darstellt (wie es auch nach derUnifikation der Fall ist). Falls eine Argumentposition in einem Atom gebunden war,dann wird sie nach der Unifikation in beiden Atomen gebunden. Nach der neuenDefinition der Subsumption darf keine Variable in S nach der Unifikation gebundensein, die vorher nicht gebunden war. Deswegen sollte uberpruft werden, ob(Bitfolge(a) or Bitfolge(b)) = Bitfolge(b) ist.

Zusammenfassung

Dieser Ansatz stellt keine regelbasierte Optimierung zur Verbesserung der”Magic

Sets“-transformierten Regelmenge, sondern einen nutzlichen Mechanismus bei dernachfolgenden Materialisierung dar. Das bedeutet, er sollte im Regelcompiler nichtimplementiert werden, da er keinen Bezug mit der Regeltransformation hat, sondernsich mit einer effizienten Bottom-Up-Auswertung einer

”Magic Sets“-transformierten

Regelmenge befasst.

Diese Optimierung hat also nur einen indirekten Bezug auf die in diesen Ab-schnitten diskutierten transformationsbasierten Verbesserungsansatze fur die

”Ma-

gic Sets“-Transformation. Die Implementierung des hier vorgestellten Algorithmusist jedoch von unterschiedlichen Entwurfsentscheidungen bei der Realisierung eineskonkreten Materialisierungsprozesses abhangig. Deswegen kann an dieser Stelle nurvorgeschlagen werden, diesen Algorithmus in Methoden (zum Beispiel boolean sub-sumes(NormalLiteral lit)) der jeweiligen Klassen der Datenstruktur (namlich Nor-malLiteral, AdornedLiteral und QueryLiteral) zu implementieren. Diese Methodenkonnen dann bei der Materialisierungsphase als ein Hilfsmechanismus zum Testender Subsumption verwendet werden.

4.3. ZUSAMMENFASSUNG 77

4.3 Zusammenfassung

In diesem Kapitel wurden Prinzipien der Anfragebearbeitung mittels der”Magic

Sets“-Methode betrachtet. Insbesondere wurden die Grundkonzepte der Regelkom-pilierung (die

”Magic Sets“-Transformation) ausfuhrlich vorgestellt, die im Regel-

compiler, der im Abschnitt 5 beschrieben wird, umgesetzt werden. Daruber hinauswurden unterschiedliche Optimierungstechniken zur Verbesserung der

”Magic Sets“-

Transformation erortert und auf ihre Einsatzmoglichkeit im Regelcompiler disku-tiert.

Das Ziel dabei war, aus unterschiedlichen Techniken solche auszuwahlen, die diegestellten Kriterien bezuglich moglicher Integration dieser Techniken in die beste-hende Datenstruktur sowie der Kombinierbarkeit mit den Konzepten der

”Magic

Sets“-Transformation erfullen. Aufgrund dieser Anforderungen erwiesen sich folgen-de Techniken zur Realisierung im Regelcompiler als geeignet:

• Die”Supplementary Magic Sets“-Methode. Sie hat nicht nur den Vorteil, dass

sie redundante Berechnungen von identischen Ausdrucken vermeidet, sondernauch die oben aufgefuhrten Anforderungen erfullt.

• Eine verbesserte Generierung einer SIP-Strategie. Sie stellt eine auch mit an-deren Techniken kombinierbare Optimierung dar, die zur Steigerung der Ef-fektivitat der

”Magic Sets“-Transformation dienen kann.

• Eine Sonderbehandlung von linearen Rekursionen. Sie liefert eine effizientereTransformation, die einen Spezialfall der

”Magic Sets“-transformation dar-

stellt.

Kapitel 5

Entwurf und Implementierung desRegelcompilers

Dieses Kapitel befasst sich mit der Realisierung einer Komponente zur Regeltransfor-mation eines deduktiven DBMS, die zu einer effizienten Anfragebearbeitung mittelsder

”Magic Sets“-Methode verwendet wird. Die im Kapitel 4 ausfuhrlich beschriebe-

nen Konzepte sowohl der”Magic Sets“-Transformation als auch der ausgewahlten

Optimierungstechniken werden in einer Komponente, namens Regelcompiler, um-gesetzt. Im Abschnitt 5.1 wird die Aufgabenstellung prazisiert sowie die Moglich-keiten der Realisierung diskutiert. Der Abschnitt 5.2 prasentiert die Architekturund verdeutlicht die Arbeitsweise des Regelcompilers. Im Abschnitt 5.3 erfolgt dieBeschreibung seiner wichtigen Module.

5.1 Anforderungsanalyse

Dieser Abschnitt beschaftigt sich mit der Analyse der sowohl funktionalen als auchnicht-funktionalen Anforderungen an den zu realisierenden Regelcompiler. Zunachstwerden die Aufgaben des Regelcompilers im Abschnitt 5.1.1 prazisiert. Außerdemwerden Anforderungen und Randbedingungen bezuglich der Integration des Regel-compilers in ein deduktives DBMS untersucht. Im Abschnitt 5.1.2 werden mogli-che Bestandteile des Regelkompilierungsprozesses identifiziert und ihre Modellierungbezuglich der spateren Anderbarkeit oder Wiederverwendbarkeit im Regelcompilermotiviert.

79

80 KAPITEL 5. ENTWURF UND IMPLEMENTIERUNG DES REGELCOMPILERS

5.1.1 Aufgaben und Ziele

Wie bereits angedeutet, soll der zu implementierende Regelcompiler die”Magic

Sets“-Transformation sowie die im Kapitel 4 diskutierten Verbesserungen der”Magic

Sets“-Transformation bei der Anfragebearbeitung vornehmen. In einem deduktivenDBMS (vgl. Abbildung 2.1 im Abschnitt 2.5) wird der Regelcompiler von einer furdie Anfragebearbeitung verantwortlichen Komponente (Anfrage-Manager) benutzt,um eine gegebene Regelmenge in eine effizient auswertbare Regelmenge, sogenannte

”Magic“-Regelmenge, bezuglich einer gegebenen Anfrage bzw. bezuglich der vomRegelcompiler generierten Anfragen zu transformieren.

Es ist also sinnvoll, den Regelcompiler als eine eigenstandige Komponente zuimplementieren, die ihre Dienste nach außen durch eine eigene Schnittstelle zurVerfugung stellt und ihre interne Struktur und Arbeitsweise verbirgt. Somit kann derRegelcompiler als eine Einheit angesehen werden, die alle fur die Regelkompilierungwichtigen Komponenten zusammenfasst. Solche Realisierung hat den Vorteil, dassder Regelcompiler ohne Einfluss auf andere Konzepte eines DBMS intern geandertund erweitert werden kann. Ein weiterer Vorteil solcher Realisierung ist die Moglich-keit der Wiederverwendbarkeit des Regelcompilers. So kann der Regelcompiler nichtnur bei der Anfragebearbeitung verwendet werden, sondern uberall wo die

”Magic

Sets“-Transformation benotigt wird (zum Beispiel bei der Anderungspropagierunginnerhalb der sogenannten

”Magic Update“-Methode). Uber die vom Regelcompiler

zur Verfugung gestellte Schnittstelle kann dann der Kompilierungsprozess einfachangesteuert und die transformierten Regeln zuruckgegeben werden.

Daher sollen uber diese Schnittstelle unterschiedlich parametrisierte Konfigura-tionen des Regelcompilers ermoglicht werden. Der Regelcompiler sollte einerseitseine geeignete effiziente Transformation bezuglich der gegebenen Regelmenge undAnfrage automatisch vornehmen, andererseits sollte es moglich sein, die gewunschtenKompilierungsparameter (wie etwa Transformationsmethode) von außen zu setzenund eine bestimmte Transformation durchzufuhren. Im Falle einer automatischenRegelkompilierung sollen vom Regelcompiler die passenden Optimierungstechnikennach bestimmten Kriterien ausgewahlt und verwendet werden. Eine parametrisier-te Regelkompilierung, bei der man beispielsweise uber eine graphische Schnittstellediese Parameter (wie etwa eine konkrete SIP-Strategie oder eine gewunschte Trans-formationsmethode) eingeben kann, muss auch durch entsprechende Methoden un-terstutzt werden.

Als Nachstes wird hier das Eingabe- und das Ausgabeformat fur die zu trans-formierenden Regeln besprochen. Wie bereits im Abschnitt 2.5 erwahnt, werdenDatalog-Regeln in einem deduktiven DBMS in ein fur die Verarbeitung geeigne-tes Format uberfuhrt. Daher wird auch der Regelcompiler eine zu transformierendeRegelmenge in einem internen Format (das im Kapitel 3 vorgestellt wurde) als Ein-


gabe ubergeben bekommen. Dabei wird angenommen, dass diese Regelmenge sicher(bereichsbeschrankt) ist, da in einer deduktiven Datenbank die Sicherheit von Re-geln vorausgesetzt wird. Infolgedessen muss die transformierte Regelmenge, die vomRegelcompiler zuruckgegeben wird, dann auch sicher sein.

5.1.2 Regelkompilierungsprozess

In diesem Abschnitt werden die zu implementierenden Bestandteile des Regel-kompilierungsprozesses identifiziert und ihre Aufteilung in einzelne Module disku-tiert. Wenn man dazu die im Kapitel 4 erlauterten Konzepte der

”Magic Sets“-

Transformation sowie die dort motivierten Optimierungstechniken genau betrachtet,kann man Folgendes feststellen. Diese Techniken beinhalten einige gleiche Phasen,fur die es viel effizienter ist, sie nicht mehrmals (pro Kompilierungsmethode), son-dern global fur alle Transformationsarten zu implementieren. Daher werden zunachstdie Gemeinsamkeiten und die Unterschiede aller Kompilierungstechniken identifi-ziert, um diese Informationen bei der Realisierung moglichst optimal ausnutzen zukonnen.

Der Ablauf der”Magic Sets“-Transformation kann im Allgemeinen in zwei auf-

einanderfolgende Schritte aufgeteilt werden: das Erzeugen einer”adorned“- und einer

transformierten Regelmenge. Sie werden im Weiteren als Adornments-Propagierungund entsprechend Transformation-Schritt bezeichnet. Bei den Optimierungstechni-ken wie

”Supplementary Magic Sets“-Transformation und

”Spezielle Behandlung

linearer Rekursionen“ (siehe Abschnitt 4.2.3) konnen ebenso zwei ahnliche Schritteidentifiziert werden. Dies war eigentlich eine der Anforderungen an die Auswahl vongeeigneten Techniken (siehe Abschnitt 4.3), namlich, dass sie im Sinne der

”Magic

Sets“-Transformation durchgefuhrt werden konnen und somit mit ihr kombinierbarsind.

Da die Adornments-Propagierung bei allen hier betrachteten Kompilierungs-Methoden vorhanden ist und zudem uberall auf die gleiche Weise verlauft, kannman diesen Schritt unabhangig von der nachfolgenden Transformation realisieren.Außerdem existieren mehrere Moglichkeiten fur die Adornments-Propagierung, weildabei sowohl unterschiedliche SIP-Strategien als auch einige Verbesserungen bei derSIP-Generierung verwendet werden konnen. Deshalb ware jeweils eine Realisierungpro Transformationsmethode redundant und daher nicht effizient. Das motiviert so-mit die Implementierung dieses Schrittes in einem separaten Modul

”Adornments-

Propagierung“ des Regelcompilers, der von allen Transformationsarten verwendetwerden kann. Dadurch kann auch eine geeignete einheitliche Behandlung dieser Kon-zepte und eine einfache Erweiterbarkeit um die weiteren Konzepte (wie etwa neueSIP-Strategien) erreicht werden.


Wahrend die Adornments-Propagierung bei allen Kompilierungstechniken aufdie gleiche Weise ablauft, unterscheiden sich die zweiten Schritte (die Erzeugungvon transformierten Regeln) um eigene Besonderheiten. Deswegen sollen die unter-schiedlichen Transformationsarten wie die

”Magic Sets“-, die


Sets“- und die spezielle Transformation von linearen Rekursionen (sie wird imWeite-ren als

”Multilineare“-Transformation bezeichnet) geeignet modelliert werden. Das

bedeutet, dass die spezifischen Merkmale jeweiliger Transformationen (wie zum Bei-spiel Vorbedingungen) dabei berucksichtigt werden sollen. Da zudem auch andereTransformationsmoglichkeiten denkbar sind, sollte die Erweiterbarkeit des Regel-compilers um andere Transformationstypen ermoglicht werden. Die Besonderheitender Implementierung der hier diskutierten Bestandteile werden im Abschnitt 5.3beschrieben.

Somit lassen sich vorerst zwei wichtige Bestandteile des Regelcompilersidentifizieren: ein gemeinsamer Teil

”Adornments-Propagierung“ und ein Teil

”Transformations-Methoden“ mit ahnlichen Funktionen, aber eigenen Besonderhei-ten. Außerdem wird eine Steuerungskomponente benotigt, die den gesamten Prozessder Regelkompilierung steuert.

5.2 Die Architektur des Regelcompilers

Dieser Abschnitt prasentiert die Architektur des Regelcompilers, der die im letz-ten Abschnitt aufgefuhrten Anforderungen erfullt. Zunachst werden im Abschnitt5.2.1 die Entwurfsprinzipien erlautert. Danach werden im Abschnitt 5.2.2 der Auf-bau des ganzen Regelcompilers und im Abschnitt 5.2.3 die Arbeitsweise sowie dieBeziehungen zwischen den einzelnen Modulen dargestellt.

5.2.1 Entwurfsprinzipien

Beim Entwurf der Architektur des Regelcompilers wurden sowohl die oben spezifi-zierten Anforderungen als auch die allgemeinen Prinzipien eines guten Systement-wurfs befolgt. So sollte die Architektur vor allem so gestaltet werden, dass sie sowohleine korrekte und effiziente Ausfuhrung der Regelkompilierung ermoglicht als aucheine einfache und unkomplizierte Zusammenarbeit mit anderen Komponenten ei-nes deduktiven DBMS erlaubt. Außerdem muss sie die Qualitatsanforderungen wieeinfache Erweiterbarkeit, Wiederverwendbarkeit oder Integrierbarkeit der einzelnenKomponenten erfullen. Sie muss also flexibel und einfach sein.

In diesem Zusammenhang sind folgende allgemeine Entwurfsprinzipien (zum Bei-spiel nach [8][12]) wichtig. Die Architektur sollte modular sein. Das bedeutet, dass

5.2. DIE ARCHITEKTUR DES REGELCOMPILERS 83

das ganze System aus den an sich abgeschlossenen Komponenten bestehen soll, diedie eigenen Schnittstellen zur Verfugung stellen. Dann konnen die einzelnen Kom-ponenten ohne Einfluss auf die anderen Komponenten einfach geandert und ausge-tauscht werden. Somit konnen ihre Funktionalitaten verwendet werden, ohne dabeidie konkrete Realisierung genau zu kennen.

Zudem tragen die zwei folgenden wichtigen Prinzipien einer Systemarchitekturwie die Erzielung einer geringen Kopplung sowie die Erzielung einer hohen Kohasionbei. Unter einer geringen Kopplung versteht man eine geringe Anzahl von Abhangig-keiten zwischen unterschiedlichen Modulen, wodurch eine einfache und unabhangigeAnderbarkeit der einzelnen Komponenten erreicht werden kann. Die hohe Kohasionbedeutet, dass alle Bestandteile der einzelnen Module an einer gemeinsamen Aufga-be arbeiten sollen. Beim Entwurf der Architektur des Regelcompilers wurden alsoeine hohe Koharenz sowie eine geringe Kopplung angestrebt.

5.2.2 Der Aufbau des Regelcompilers

In diesem Abschnitt wird die grobe Architektur der realisierten Komponente Regel-compiler vorgestellt. Dabei werden ihre wichtigen Module sowie ihre Beziehungenzueinander beschrieben.

Schnittstelle

Der Regelcompiler bietet eine bereits motivierte Schnittstelle CompilerInterface, diedie Kommunikation zwischen dem Regelcompiler und anderen Komponenten einesdeduktiven DBMS ermoglicht.

«interface»CompilerInterface

Anfrage−Manager

Regelcompiler

Abbildung 5.1: Die Schnittstelle zumRegelcompiler

+ compile(rules: Arraylist):Arraylist

+ setSipStrategy(sipStr: String): void

String): void+ setTransformationMethod(method:

CompilerInterface«interface»

+ setQuery(query: Literal): void

Abbildung 5.2: Interface CompilerIn-terface


Uber diese Schnittstelle konnen die zu transformierenden Regeln an den Re-gelcompiler ubergeben und die transformierten Regeln zuruckgegeben werden. Au-ßerdem konnen die relevanten Parameter, wie etwa eine bestimmte SIP-Strategie,eine gewunschte Transformations-Methode oder eine spezielle Anfrage, konfiguriertwerden.

Module

Im Wesentlichen setzt sich der Regelcompiler aus drei folgenden Bestandteilen bzw.Modulen zusammen (siehe Abbildung 5.3):

• Steuerungsklasse RulesCompiler,

• Adornments-Propagierung und

• Transformations-Methoden.

Diese Aufteilung wurde sowohl durch die Zustandigkeitsbereiche der jeweiligenModule, die im Abschnitt 5.1.2 diskutiert wurden, als auch durch die im vorheri-gen Abschnitt beschriebenen Prinzipien einer guten Systemarchitektur motiviert.Jedes Modul ist fur die Ausfuhrung einer eigenen Aufgabe zustandig und kann ausweiteren funktionalen Teilen (Modulen) zusammengesetzt werden. Diese erfullenihre jeweiligen Teilaufgaben und besitzen eine eigene Architektur und Merkmale.Das Modul Adornments-Propagierung ist fur die Realisierung des ersten, das ModulTransformations-Methoden fur die Umsetzung des zweiten Schrittes der Regelkom-pilierung verantwortlich.

Solche getrennte Modellierung der Bestandteile des Regelkompilierungsprozes-ses ermoglicht unter anderem eine unabhangige Erweiterbarkeit dieser um weitereKonzepte. So kann das Modul Adornments-Propagierung, das unterschiedliche SIP-Strategien unterstutzt, ohne Einfluss auf die dabei zu verwendende Transformati-onsmethode einfach intern um die neuen SIP-Generierungsmoglichkeiten erweitertwerden (siehe Abschnitt 5.3.2). Im Modul Transformations-Methoden konnen sei-nerseits die neuen Transformationsarten implementiert werden, die dann auf einegemaß einer beliebigen SIP-Strategie erzeugte

”adorned“-Regelmenge angewendet

werden. So kann eine gewunschte SIP-Strategie mit einer gewunschten Transforma-tionsmethode bei der Regelkompilierung beliebig kombiniert werden.

Die Steuerung der Module Adornments-Propagierung und Transformations-Methoden und somit des ganzen Kompilierungsprozesses erfolgt uber die Klasse Ru-lesCompiler, auf die spater detaillierter eingegangen wird. Sie realisiert die Schnitt-stelle CompilerInterface und stellt alle dort angebotenen Methoden zur Verfugung.


RegelcompilerPackage

...

# generatePermutations(range: int): ArrayList

Mathematics

...

− s: AbstractSipStrategy

# adornRules(rules, query)# adornRules(rules)

AdornmentPropagation

...

# transformRules(rules: ArrayList): ArrayList

MagicMethod

...


SupplementaryMethod

...


MultilinearMethod

...ArrayList): ArrayList

TransformationMethodInterface«interface»

# transformRules(rules:

...

AbstractSipStrategy

# orderingSubgoals(r: Rule): Rule

«used»

«used»

− method: TransformationMethodInterface

− sip: String

+ compile(rules: ArrayList): ArrayList

+ setSipStrategy(sipStr :String): void+ setQuery(q: Literal): void

− adornProp: AdornmentPropagation

RulesCompiler

...

+ setTransformationMethod(method: String):void

− query: Literal...


SipMinFree

...


SipMostBounded

...Rule): Rule

# orderingSubgoals(r:

SipLeftToRight

− automaticCompile(rules:ArrayList):ArrayList

Steuerungsklasse

Adornments−Propagierung

Transformations−Methoden

Abbildung 5.3: Architektur des Regelcompilers

Diese Klasse ist, wie bereits erwahnt, fur den ganzen Kompilierungsprozess verant-wortlich. Sie nimmt die Konfigurationsparameter entgegen und steuert alle Moduleinnerhalb des Regelcompilers. Der im nachsten Abschnitt beschriebene Ablauf derRegelkompilierung wird durch entsprechende Methoden dieser Klasse unterstutzt.

5.2.3 Die Arbeitsweise

Zum besseren Verstandnis der Arbeitsweise und Kommunikation zwischen den ein-zelnen Modulen wird in diesem Abschnitt der Ablauf der Regelkompilierung imGroben erlautert. Eine ausfuhrliche Beschreibung einzelner Module erfolgt im Ab-schnitt 5.3.


Die Konfiguration der Parameter

Im Allgemeinen kann der Kompilierungsprozess durch folgende Parameter konfigu-riert werden:

• Name der gewunschten SIP-Strategie (setSipStrategie(String sipStr))Der Regelcompiler unterstutzt die Adornments-Propagierung mit folgendenSIP-Strategien wie left-to-right, minfree und most-bounded.

• Name der zu verwendenden Transformations-Methode (setTransformationMe-thod(String method))Es kann zwischen magic, suppmagic, multilinear oder automatic ausgewahltwerden. Wahrend die magic- und suppmagic-Transformations-Methoden da-bei direkt ausgefuhrt werden, mussen bei multilinear einige Vorbedingungengepruft werden. Bei automatic muss nach bestimmten Kriterien eine geeigneteTransformations-Methode vom Regelcompiler selbst ausgesucht werden.

• Anfrage (setQuery(QueryLiteral query))Außerdem gibt es zwei Moglichkeiten fur die Verwendung des Regelcompi-lers, wie etwa eine Regeltransformation zur Laufzeit (on demand) oder furalle moglichen Anfragemuster im Voraus (precompile). Im ersten Fall soll ei-ne aktuelle Anfrage (Anfragelitereal) als Parameter ubergeben werden undim zweiten werden die moglichen Anfragen passend zu der Regelmenge vomRegelcompiler generiert.

Die Regelkompilierung kann entweder entsprechend den gesetzten Parameternoder, falls keine Parameter ubergeben wurden, automatisch geschehen. Im Falle,wenn keine, falsche oder nicht alle Parameter gesetzt wurden, werden

”default“-

Settings fur die fehlenden Parameter benutzt. Als eine SIP-Strategie wird dabei diemost-bounded -Strategie verwendet.

Eine fehlende Anfrage deutet auf eine precompile-Kompilierungsart. In diesemFall werden alle moglichen Anfragen bei dem Schritt der Adornments-Propagierungvom Regelcompiler passend zu der gegebenen Regelmenge generiert und die Re-gelkompilierung bezuglich dieser Anfragen durchgefuhrt. Wenn zum Beispiel kei-ne spezielle Transformationsmethode eingegeben wird, wird dies als eine automati-sche Auswahl der geeigneten Transformation interpretiert (automatic). Im Prinzipmussen also keine Parameter explizit gesetzt werden bzw. konnen nur die gewunsch-ten gesetzt werden. Der Regelcompiler kann dadurch flexibel konfiguriert werden.


Der Ablauf der Regelkompilierung

Zum Anfang der Regelkompilierung sollen die oben erlauterten Parameter, fallsdies erwunscht ist, bereits gesetzt werden. Mit dem Aufruf der Methode compi-le(inputRules) der Klasse RulesCompiler wird der Prozess der Regelkompilierungangestoßen. Diesen kann man in zwei logische Schritte aufteilen: die Verifikationder gesetzten Parametern (bzw. die interne Auswahl geeigneter Kompilierungspara-meter) und eigentliche Regelkompilierung gemaß diesen Parametern. Dieser Ablaufwird in der Abbildung 5.4 vereinfacht dargestellt und seine wichtigen Schritte imFolgenden beschrieben.

Transformations−Methode alsfestlegenmultilinear

Check 3

Check 2multilinear ]

[ magic,

Check 3und Überprüfung von Bedingungen für die Anwendung der"Multilinearen"−Transformation

Check 2

[ automatic,suppmagic ]

zurückgebentransformierte Regeln

Check 1

Transformations−Methode alssuppmagic festlegen

Check 1 Bestimmung der Art der Transformationautomatic

odermagic, suppmagic, multilinear

[ nicht erfüllt ] [ erfüllt ]

[ nicht erfüllt ] [ erfüllt ]

veranlassenRegelkompilierung

Abbildung 5.4: Aktivitatsdiagramm: Auswahl einer geeigneten Kompilierungstech-nik im Regelcompiler

Zunachst erfolgt eine erste Uberprufung (Check 1) zum Unterscheiden zwischenden Fallen magic, suppmagic und multilinear. Wahrend die Ausfuhrung der

”Magic

Sets“- oder der”Supplementary Magic Sets“-Transformation direkt erfolgen kann,

mussen fur die Anwendung der”Multilinearen“-Transformation bestimmte Vorbe-


dingungen erfullt sein. Fur die Anwendung der”Multilinearen“-Transformation muss

die gegebene Regelmenge alle speziellen Eigenschaften multilinearer Rekursionen(vgl. 4.2.3) aufweisen. Dafur wird eine Regelanalyse benotigt, bei der die unter-schiedlichen Bedingungen uberpruft werden. Das geschieht in zwei Schritten (Check2 und Check 3), um einen schnelleren Verlauf der Regelanalyse durch einen vor-zeitigen Abbruch zu bewirken. Wenn namlich einige Bedingungen nicht erfullt sind,konnen die Uberprufungen abgebrochen und ein anderes Verfahren angewendet wer-den. Die eigentliche Regelanalyse liegt im Zustandigkeitsbereich der Klasse Multili-nearMethod.

Bei einer automatischen Regelkompilierung (automatic) wird folgende Strate-gie verfolgt: Zunachst wird versucht, eine

”Multilineare“-Transformation anzuwen-

den, weil dieses Verfahren gegenuber der”Magic Sets“-Transformation eine viel

effizienter auswertbare Regelmenge liefert (vgl. Abschnitt 4.2.3). Wenn dabei diezu uberprufenden Bedingungen fur die Anwendung dieses Verfahrens nicht erfulltsind, wird vom Regelcompiler die

”Supplementary Magic Sets“-Transformation aus-

gewahlt, weil sie eine Verbesserung zur Vermeidung von redundanten Berechnungender

”Magic Sets“-Transformation bringt.

Nachdem die zu verwendende Transformations-Methode bei einer automatischenRegelkompilierung (automatic) festgelegt wurde, wird von der Steuerungsklasse Ru-lesCompiler die eigentliche Regelkompilierung veranlasst (Aktivitat

”Regelkompi-

lierung veranlassen“ im Aktivitatsdiagramm 5.4). Diese kann auch direkt im Falleeiner magic- oder suppmagic-Transformations-Methode geschehen. Das bedeutet,dass Prozesse der Adornments-Propagierung und Transformation eingeleitet wer-den, wodurch diese Module nacheinander entsprechend parametrisiert aufgerufenwerden. Dieser Ablauf sowie die Zustandigkeitsbereiche einzelner Module kann mitHilfe des folgenden Aktivitatsdiagramms (Abbildung 5.5) verdeutlicht werden.

Dabei wird zunachst das Modul Adornments-Propagierung aufgerufen, welcheszuvor mit dem Namen der zu verwendenden SIP-Strategie (und gegebenenfalls eineminternen Steuerungs-Parameter) parametrisiert wurde. Als Eingabe bekommt diesesModul entweder nur eine Regelmenge (adornRules(Rules)) oder eine Regelmengemit einer Anfrage (adornRules(Rules, query)), was einem precompile- bzw. einem ondemand -Kompilierungstyp entspricht. Danach wird in diesem Modul Adornments-Propagierung eingeleitet.

Die vom Modul Adornments-Propagierung erhaltene”adorned“-Regelmenge Rad

wird als Inputparameter an das Modul Transformations-Methoden von Steue-rungsklasse RulesCompiler zur weiteren Verarbeitung ubergeben. Das ModulTransformations-Methoden liefert dann eine transformierte Regelmenge Rtransform.Anschließend wird sie zur weiteren Bearbeitung an eine Komponente des DBMS (wieetwa Anfrage-Manager) ubergeben, die ursprunglich den RegelCompiler aufgerufen

5.3. DER UBERBLICK UBER DIE MODULE DES REGELCOMPILERS 89

ad[ R ]R

ad

Rtransform

[ R ]Propagierungveranlassen

SIP−Klasse SIP−Strategieerzeugen

ensprechende

setzen

den Namen der

veranlassenTransformation

durchführenPropagierung

durchführen

Regel− Regel−Transformation

RegelnKompilierten

zurückgeben

Adornments−Adornments−

Transformations−MethodenPropagierung RulesCompilerAdornments−

Abbildung 5.5: Aktivitatsdiagramm: Steuerung der Module bei der Regelkompilie-rung

hat. Rtransform besteht aus den Regeln vom Typ TransformedRule (siehe Kapitel 3),die eine einheitliche Behandlung aller Arten transformierter Regeln erlaubt.

Wahrend fur die Festlegung einer bestimmten Transformationsart eine Reihevon Uberprufungen benotigt wird, kann jede beliebige eingegebene SIP-Strategiedirekt zur Verwendung bei der Adornments-Propagierung ubergeben werden, ohnedabei irgendwelche speziellen Vorbedingungen uberprufen zu mussen. Der Schrittder Adornments-Propagierung kann zudem wegen der unabhangigen Modellierungmit beliebigen Transformations-Methoden kombiniert werden.

5.3 Der Uberblick uber die Module des Regel-

compilers

In diesem Abschnitt erfolgt eine ausfuhrliche Beschreibung der einzelnen Module desRegelcompilers. Außerdem werden die Arbeitsweise und die wichtigen Merkmale derModellierung diskutiert.


5.3.1 Steuerungsklasse RulesCompiler

Die Steuerung des ganzen Kompilierungsprozesses erfolgt uber die Klasse RulesCom-piler. Diese Klasse implementiert die Schnittstelle CompilerInterface zum Regelcom-piler und stellt somit die dort deklarierten Methoden sowohl fur die Konfiguration alsauch fur die Verwendung des Regelcompilers zur Verfugung. Außerdem enthalt sieauch eigene interne Methoden zur Organisation des Kompilierungsprozesses. EinenUberblick daruber gibt das Klassendiagramm 5.6.

+ setSipStrategy(sipStr :String): void+ setQuery(q: Literal): void+ compile(rules: ArrayList): ArrayList

− sip: String− query: Literal− method: TransformationMethodInterface− adornProp: AdornmentPropagation

− automaticCompile(rules: ArrayList): ArrayList+ setTransformationMethod(method: String):void

− initiateAdornmentPropagation(inputRules,query)...

RulesCompiler

Abbildung 5.6: Klassendiagramm: Steuerungsklasse RulesCompiler

Diese Klasse fasst also alle Funktionalitaten der Komponente Regelcompiler zu-sammen und delegiert benotigte Aufrufe an die entsprechenden

”zustandigen“ Mo-

dule. Dadurch wird zwischen den einzelnen Komponenten eine geringe Kopplungerzielt. Dazu besitzt sie als Instanzvariablen unter anderem die Instanzen derKlassen AdornmentPropagation und TransformationMethodInterface. Diese Klas-sen stellen selbst die Schnittstellen fur die Module Adornments-Propagierung undTransformations-Methoden dar und agieren ahnlich wie RulesCompiler als Steue-rungsklassen (Fassadenklassen) fur die jeweiligen Module. Der im Abschnitt 5.2.3dargestellte Ablauf der Regelkompilierung wird durch die Klasse RulesCompiler ab-gewickelt.

5.3.2 Adornments-Propagierung

In der Abbildung 5.5 (”Steuerung der Module bei der Regelkompilierung“) wird

die Aufgabe, fur eine gegebene Regelmenge R eine”adorned“-Regelmenge Rad zu

erzeugen, an das Modul Adornments-Propagierung weitergeleitet. Seine Architekturund die Arbeitsweise wird in diesem Abschnitt erlautert.


...

range: int): ArrayList# generatePermutations(

Mathematics

− getPossibleBoundTerms():int− updateBoundVars():void...

# orderingSubgoals(r:Rule): Rule

− isSafeRule(r: rule):boolean

AbstractSipStrategy

− s: AbstractSipStrategy

# adornRules(rules)# createSIPStrategie(String s)# generateQueries(rules)

...

# adornRules(rules, query)

− eliminateDoublesRules()− initiateSipReordering(rule)

AdornmentPropagation

SipLeftToRight

Rule): Rule...

SipMinFree

Rule): Rule...

# orderingSubgoals(r: # orderingSubgoals(r:

SipMostBounded


...

Adornments−Propagierung

Abbildung 5.7: Klassendiagramm: Das Modul Adornments-Propagierung

Design

Dieses Modul besteht aus folgenden funktionalen Bestandteilen (Klassen):

• AdornmentPropagation,

• AbstractSipStrategy (SipLeftToRight, SipMinFree, SipMostBounded),

• Mathematics.

Die Klasse AdornmentPropagation ist die zentrale Klasse dieses Moduls undrealisiert alle notigen Methoden zur Durchfuhrung des Schrittes der Adornments-Propagierung. Dabei ist es moglich, fur eine gegebene Regelmenge R eine

”ador-

ned“-Regelmenge Rad sowohl bezuglich einer gegebenen Anfrage (adornRules(rules,query)) als auch fur alle moglichen Anfragemuster (adornRules(rules)) zu erzeu-gen. Im letzten Fall werden mit Hilfe der Klasse Mathematics zu einer gegebenenAnzahl der Argumente eines Literals alle moglichen Anfragemuster mit Hilfe vongeneratePermutations(int range) generiert.

Bei der Adornments-Propagierung muss unter anderem eine bestimmte Reihen-folge der Rumpfliterale bzw. eine SIP-Strategie ausgewahlt werden. Wie es im Ka-pitel 4 diskutiert wurde, konnen fur eine Regel mehrere SIP-Strategien verwendetwerden. Zur Implementierung wurden dabei statische SIP-Strategien wie left-to-right, minfree und most-bounded ausgewahlt, die auf unterschiedlichen Heuristiken


basieren. Da noch weitere SIP-Strategien denkbar sind, wurde dieser Schritt (SIP-Generierung) unabhangig von der eigentlichen Adornments-Propagierung realisiert,um die potentielle Erweiterbarkeit zu ermoglichen. Es wurde dabei eine auf demTemplate Design Pattern basierende Architektur gewahlt, welche fur die Modellie-rung von ahnlichen Algorithmen gut geeignet ist.

Die abstrakte Klasse AbstractSipStrategy stellt eine allgemeine Schnittstelle furalle Algorithmen dar, die die konkreten SIP-Strategien (SipLeftToRight, SipMinFree,SipMostBounded) implementieren. Sie enthalt eine abstrakte Methode orderingSub-goals(Rule r), die in den jeweiligen Unterklassen realisiert werden soll. Daruber hin-aus bietet sie viele wichtige Hilfsmethoden (zum Beispiel Methoden zur Uberprufungder Sicherheit eines Literals isSafe(Literal testLiteral)), die bei der SIP-Generierungvon allen Unterklassen benutzt werden konnen.

Die Klasse AdornmentPropagation enthalt eine Instanzvariable von Typ Ab-stractSipStrategy, welche je nach der gewunschten SIP-Strategie als ein Objekt einerkonkreten Unterklasse agiert und somit ein konkretes gewunschtes Verhalten auf-weist. Dadurch wird eine einfache Erweiterbarkeit um die neuen SIP-Algorithmenerreicht. So kann jede neu hinzukommende SIP-Strategie als eine Unterklasse derAbstractSipStrategy realisiert werden und ein eigenes Verhalten in der Methode or-deringSubgoals(Rule r) zeigen. Zudem ermoglicht diese Modellierung, die so separatrealisierten SIP-Algorithmen auch nacheinander zu verwenden, um zum Beispielnach einer Bewertung eine bessere Variante auszuwahlen (vgl. Kapitel 4). Daruberhinaus kann jede Klasse, die einen SIP-Algorithmus implementiert, intern beliebigmodifiziert werden, ohne dabei einen Einfluss auf die anderen Klassen des ModulsAdornments-Propagierung auszuuben.

Arbeitsweise

Im Folgenden wird der Ablauf der Adornments-Propagierung bezuglich einer gege-benen Anfrage gezeigt (adornRules(inputRules, query)). Man kann das in der Ab-bildung 5.8 sehen.

Im Wesentlichen richtet sich der hier dargestellte Ablauf der Adornments-Propagierung auf die im Abschnitt 4.1.2 beschriebene Vorgehensweise, nach der furjedes

”adorned“-Literal pα und fur jede Regel mit dem kopf p eine

”adorned“-Version

dieser Regel gemaß einer SIP-Strategie erzeugt wird.

Dazu wird eine Liste ToDo gefuhrt, die alle Literale beinhaltet, deren Bindun-gen (Adornments) noch propagiert werden sollen. Am Anfang wird diese Liste mitdem Anfrageliteral query initialisiert. Dann wird jeweils ein

”adorned“-Literal aus

der ToDo-Liste genommen (falls diese nicht leer ist) und seine Bindungen in allenRegeln, deren Kopfe mit diesem Literal unifizierbar sind, weiterpropagiert. Dabei


ToDoist leer?

Rjede Regel aus aus ]r[ führe folgende Schritte für

Rad

pα

Rad

Rad

R ad zurückgeben

[ ja ]

suche alle Regeln Rmit dem Kopf p

[ nein ]

mit der AnfrageToDo queryals leer

ToDoaus wähle ein Literal

speichere in

ToDo ist die Liste der "adorned"−Literale, deren Bindungen propagiert werden sollen

Input: Regelmenge, Anfrage

rung von Bindungenim Regelrumpf (SIP)

αr’

der Regel r: r’

setze das Adornmentan den Kopf von

vervollständige ToDo

veranlasse Propagie−

ist die Ergebnisliste

r’

Initialisiere die Listen:

erzeuge eine Kopie

*

Abbildung 5.8: Ablauf der Adornments-Propagierung bezuglich einer Anfrage

wird zunachst eine Kopie der gerade bearbeiteten Regel erzeugt, dann das Adorn-ment des Literals p an den Regelkopf gesetzt. Danach wird die Propagierung derBindungen gemaß einer ausgewahlten SIP-Strategie veranlasst. Die somit erzeugte

”adorned“-Regel wird in der Ergebnisliste Rad gespeichert und anschließend die Li-ste ToDo vervollstandigt. Dabei werden die

”adorned“-Literale aus dem Rumpf der

gerade erzeugten Regel der Liste ToDo hinzugefugt, die einerseits regeldefiniert sindund andererseits nicht in der ToDo Liste momentan enthalten sind oder waren. Da-durch wird verhindert, dass die gleichen Literale wieder zur Propagierung ihrer Bin-dungen herangezogen werden. Dadurch wird die Terminierung bei der Adornments-Propagierung sichergestellt. Zum einen gibt es endlich viele Regeln, die endlich vieleRumpfliterale enthalten und zum anderen wird beim Vervollstandigen der Liste To-Do immer uberpruft, ob das neue Literal momentan in der ToDo-Liste enthalten istoder bereits enthalten war. Das bedeutet, dass keine Literale zum zweiten Mal zuder Liste hinzugefugt werden und somit diese Liste nach endlich vielen Schritten leer


wird. Wenn aber die ToDo-Liste leer ist, bedeutet es, dass Adornments-Propagierungabgeschlossen ist und die

”adorned“-Regeln zuruckgegeben werden.

Einige Besonderheiten des Ablaufs werden im Folgenden genauer erlautert.

unique-binding property Nachdem ein abgeleitetes Literal p aus der ToDo-Liste zur Weiterpropagierung in allen Regeln mit dem Kopf p herangezogen wird,wird fur jede Regel r ∈ R eine Kopie r’ erzeugt, fur die dann die eigentlicheAdornments-Propagierung erfolgt. Das ist wichtig, weil der Kopf einer rekursiven Re-gel im Laufe der Adornments-Propagierung unterschiedliche Adornments bekommenkann und infolgedessen mehrere

”adorned“-Varianten einer Regel entstehen konnen.

Durch jeweiliges Kopieren einer Regel konnen dann abhangig vom Bindungsmusterdes Kopfes unterschiedliche

”adorned“-Versionen einer Regel erzeugt werden. Da-

durch wird die im Kapitel 4 angesprochene unique-binding property gewahrleistet.

Beim Vervollstandigen der Liste ToDo, werden bereits betrachtete Literale, diesich also in der Liste Done befinden, nicht hinzugenommen, weil dies zu identischen

”adorned“-Regeln fuhren kann. Aus dem gleichen Grund werden auch keine Literalein ToDo hinzugefugt, die bei den unterschiedlichen Termen dasselbe Bindungsmusterwie bereits abgearbeitete Literale haben. Dadurch wird namlich verhindert, dass diebis auf die Variablenumbenennung gleichen

”adorned“-Regeln erzeugt werden. So

zum Bespiel wird das Literal pfb(V,W ) nicht in die ToDo-Liste aufgenommen, wennein Literal pfb(X,Y ) bereits betrachtet wurde.

Umordnung des Regelrumpfes gemaß einer SIP-Strategie Die Umordnungdes Regelrumpfes ((initiateOrderingSubgoals(rule)) erfolgt gemaß einer ausgewahl-ten SIP-Strategie, die, wie oben erlautert wurde, in entsprechenden Klassen SipLeft-ToRight, SipMinFree, SipMostBounded geschieht.

Im Allgemeinen lauft es nach folgendem Prinzip ab (ahnlich wie in [22]). Fur jedemogliche Literalposition (1,2,...) im Regelrumpf wird ein passendes Literal aus derMenge aller Rumpfliterale ausgesucht. Diese Menge enthalt solche Literale, denennoch keine Positionen zugewiesen wurde. Es wird zunachst versucht, jedes dieserLiterale zu binden. Dabei werden solche Variablen als gebunden markiert, die inLiteralen vorkamen, deren Position bereits festgelegt wurde, die also links von demgerade betrachteten Literal im Rumpf stehen. Dazu wird eine Liste der VariablenboundVars gefuhrt, die aus Variablen besteht, die in den bereits festgelegten, alsolinksstehenden Literalen vorkamen. Danach wird jedes so

”temporar“ gebundene

Literal als ein Kandidat auf die jeweilige aktuelle Position untersucht. Dabei werdensowohl die entsprechenden Kriterien der jeweiligen SIP-Strategie wie etwa maximalebzw. minimale Variablenanzahl als auch die Sicherheit des Literals berucksichtigt.Wenn ein Literal eine maximale bzw. minimale Anzahl der gebundenen bzw. freien


Variablen enthalt und zudem sicher ist, wird es auf die gerade zu besetzende Positiongenommen, sonst wird ein anderes Literal unter den verbleibenden Literalen aufdiese Position im Regelrumpf weitergesucht. Im Falle einer left-to-right-SIP-Strategiewird lediglich die Sicherheit des jeweiligen Literals gepruft und im Falle, wenn esunsicher ist, ein anderes Literal gesucht. Am Ende wird eine sichere

”adorned“-

Regel zuruckgegeben, weil in jedem Schritt der oben beschriebenen Umordnung desRegelrumpfes nur sichere Literale einbezogen werden.

In Bezug auf die Sicherheit gibt es verschiedene Realisierungsmoglichkeiten, dieim Folgenden diskutiert werden.

Behandlung von negativen- und”Built In“-Literalen Es wird vor allem

die Sicherheit von negativen- und”Built In“-Literalen untersucht. Wie im Kapitel

2 definiert wurde, mussen in solchen Literalen alle Variablen zum Zeitpunkt derAuswertung gebunden werden, was bedeutet, dass sie unter den Variablen der links-stehenden Rumpfliterale vorkommen sollen.

Genau dieses Prinzip wurde in dieser Arbeit zur Gewahrleistung der Sicherheitdieser Literale gefolgt. Noch bei der Bindung der Variablen der negativen- und

”Built

In“-Literalen werden nur die Variablen als gebunden markiert, die nur in den links-stehenden Literalen des Regelrumpfes und nicht des Regelkopfes vorkamen. Es istzu beachten, dass beim Binden von positiven Literalen auch gebundene Variablendes Regelkopfes berucksichtigt werden. Bei der nachfolgenden Sicherheitsprufung(isSafe(Literal lit)) negativer- und

”Built In“-Literale wird dann untersucht, ob alle

Variablen gebunden sind. Sind nicht alle Variablen gebunden, wird fur die aktuellePosition ein anderes Literal gesucht. Das gerade betrachtete Literal kann aber dannals ein Kandidat fur die nachste Position wieder betrachtet werden. Dadurch wirdermoglicht, dass ein solches Literal nur solange nach rechts verschoben wird, bis esnotig ist, d.h. bis alle Kriterien der jeweiligen SIP-Strategie erfullt sind sowie seineSicherheit gewahrleistet ist.

Eine andere Moglichkeit ware, die Sicherheit von negativen und”Built In“-

Literalen zu gewahrleisten, indem sie sofort an das Ende des Regelrumpfes verscho-ben werden. Dadurch wurde ihre Sicherheit auch sichergestellt, da alle positivenLiterale automatisch vor ihnen im Regelrumpf stunden. Allerdings hatte eine sol-che Realisierung den Nachteil, dass die moglichen wichtigen Einschrankungen beider Auswertung des Regelrumpfes (von links nach rechts) zu spat zur Verwendungkommen wurden und infolgedessen viele irrelevanten Fakten wahrend der Auswer-tung materialisiert wurden, die am Ende rausgefiltert werden mussten. Wurde sozum Beispiel das

”Built In“-Literal

”X < 10“ moglichst fruh im Rumpf der Regel

p(X,Z) ← s(X,Z), X < 10, p(X,Z) auftreten, wurde das bei der Materialisierungder Relation p berucksichtigt und daher weniger Fakten erzeugt. Wenn es dagegen


ans Ende des Regelrumpfes verschoben wird, werden oben aufgefuhrte Vorteile nichtausgenutzt. Deswegen ist es viel effektiver, negative- und

”Built In“-Literale nur so-

lange nach rechts zu verschieben, bis ihre Sicherheit erfullt ist, wie es auch in dieserArbeit realisiert wurde.

Als nachstes wird der Ablauf einer”precompile“-Kompilierung kurz vorgestellt.

Generierung von Anfragen

Wenn bei der Adornments-Propagierung keine Anfrage gegeben wird, bedeutet dies,dass zu der gegebenen Regelmenge alle moglichen Anfragen erzeugt werden sollen.In diesem Fall lauft die Adornments-Propagierung nach folgendem Prinzip ab:

Schritt 1 Erzeuge alle moglichen Anfragen (Liste Q) zu den abgeleiteten Literalenin der Regelmenge R.

Schritt 2 Fur jede erzeugte Anfrage q ∈ Q wende den oben beschriebenen Algo-rithmus fur Adornments-Propagierung an. Speichere erzeugte Regeln in derListe Rad ab.

Schritt 3 Eliminiere ahnliche Regeln aus Rad.

Zu Schritt 1. Fur jedes abgeleitete Literal1 p aus der Regelmenge R werden ver-schiedene Adornments mit Hilfe der Klasse Mathematics generiert. Ihre MethodegeneratePermutations(range) erzeugt fur eine gegebene Anzahl der Argumentposi-tionen (range) alle moglichen Permutationen von

”0“ und

”1“. Die Idee besteht dar-

in, dass fur eine Anzahl der Argumente n insgesamt 2n unterschiedliche Adornmentserzeugt werden konnen. Wenn ein Adornment (eine aus den Buchstaben

”b“ und

”f“ bestehende Zeichenkette) als eine entsprechend aus den Ziffern

”1“ und

”0“ be-

stehende Zeichenkette interpretiert wird, kann die Generierung von Adornments aufeine einfache Generierung von binaren Zahlen zuruckgefuhrt werden. Danach wer-den unterschiedliche QueryLiterale bezuglich generierter Adornments erzeugt undin einer Liste Q fur weitere Bearbeitung gespeichert.

Beispiel 5.1 (Erzeugung aller Permutationen) Gegeben sei ein Literal p mitder Stelligkeit n, z.B. p(X,Y,Z), fur welches alle moglichen Adornments erzeugtwerden sollen. Es sollen dann 2n = 23 = 8 unterschiedliche Permutationen von

”1“

und”0“ generiert werden.

1Kommt dieses Literal in der Regelmenge R mehrmals vor, so werden unterschiedliche Adorn-ments nur einmal generiert.


Idee: Erzeuge alle binaren Darstellungen fur dezimale Zahlen von 0 bis 2n−1.In diesem Beispiel werden dann fur n=3 folgende binare Folgen erzeugt: [dezimaleZahl]:[ihre binare Darstellung] 0: 000, 1: 001, 2: 010, 3: 011, 4: 100, 5:101 ... 7:111.Somit werden alle mogliche Permutationen von Nullen und Einsen fur eine Zeile derLange n erzeugt. Wenn dabei jede Permutation als Adornment eines Literals mit derStelligkeit n interpretiert wird, dann werden somit auch alle moglichen Adornments(ausgehend von fff bis bbb) dieses Literals erzeugt. Da es zu jeder dezimalen Zahlnur eine einzige binare Darstellung gibt und im Bereich von 0 bis 2n−1 fur sie diegleiche Lange n benotigt wird, werden entsprechend alle Adornments fur ein Literalder Stelligkeit n auch eindeutig bestimmt.

Zu Schritt 2. Wende den oben beschriebenen Algorithmus fur Adornments-Propagierung ((adornRules(inputRules, query)) fur jede im vorherigen Schritt er-zeugte Query q ∈ Q an. Speichere erzeugte Regeln in der Liste Rad ab.

Zu Schritt 3. Nach dem die Adornments-Propagierung fur alle Anfragen abge-schlossen wurde, d.h. die Regelmenge Rad erzeugt wurde, erfolgt die Eliminierungvon ahnlichen Regeln. Mit

”ahnlich“ werden solche Regeln bezeichnet, die die bis

auf die Variablenumbenennung gleichen Literale mit den gleichen Adornments ent-halten. So ist zum Beispiel eine

”adorned“-Regel pfb(X,Y ) ← qfb(X,Z), sbb(Z, Y )

einer anderen”adorned“-Regel pfb(U, V ) ← qfb(U, V ), sbb(V,W ) ahnlich. Daher

wird eine dieser Regeln eliminiert, weil sonst bei der nachfolgenden”Magic Sets“-

Transformation ahnliche”query“- und

”answer“-Regeln entstehen wurden, wobei fur

die Materialisierung der Relation p eigentlich nur eine dieser Regel ausreicht.

5.3.3 Transformations-Methoden

Als zweiter Schritt der Regelkompilierung kommt die eigentliche Transformation,das heißt die Erzeugung von

”query“- und

”answer“-Regeln, also eine Regelmenge

Rtransform, bezuglich einer”adorned“-Regelmenge Rad. In diesem Abschnitt wird

die Architektur des fur diesen Schritt verantwortlichen Moduls Transformations-Methoden dargelegt und der Ablauf der Regeltransformation im Regelcompiler be-schrieben.

Design

Wie bereits identifiziert wurde, sollten folgende Transformationsarten realisiertwerden: die

”Magic Sets“-Transformation, die

”Supplementary Magic Sets“-

Transformation und die”Multilineare“-Transformation. Da alle diese Transforma-


tionen eine ahnliche Aufgabe transformRules(rules) erfullen mussen, dabei aber un-terschiedliches Verhalten aufweisen sollen, wurde sich hier fur eine Architektur diesesModuls entschieden, die auf dem Strategy Design Pattern basiert.

TransformationMethodInterface«interface»

...# transformRules(rulrs:ArrayList):

ArrayList)

MagicMethod

...

# transformRules(rules)− createTransformedRule(

head,body,typ)− makeAnswerRules(rules)− makeHelpRules(rules)− makeQueryRules(rules)

...

SupplementaryMethod

# transformRules(rules)− makeNullSupplRule()− verifiereArguments()− createTransformedRule()

MultilinearMethod

...

− secondMultilinearTest(rules):

− firstMultilinearTest(rules):# transformRules(rules)

− transformBasisRule(rule): Rule− transformRightLinearRule(rule)− transformLeftLinearRule(rule)− transformMultiLinearRule(rule)

boolean

boolean

Transformations−Methoden

Abbildung 5.9: Klassendiagramm: Das Modul Transformations-Methoden

So besteht dieses Modul (siehe Abbildung 5.9) aus einer Schnittstelle Transfor-mationMethodInterface, die gemeinsames Verhalten aller Transformationsarten alseine abstrakte Aufrufmethode transformRules(rules) herausfaktorisiert, und es be-steht aus jeweiligen Transformationsarten. Sie werden in Klassen MultilinearMethod,SupplementaryMethod, MagicMethod durch entsprechende Methoden (Algorithmen)realisiert.

Da es noch weitere Optimierungstechniken der”Magic Sets“-Transformation

gibt, hat diese Modellierung den Vorteil, dass dieses Modul sehr einfach um die neu-en Transformationsarten erweitert werden kann. Jede neu hinzukommende Klasse,die eine weitere Transformationstechnik realisiert, sollte daher nur die in der Schnitt-stelle geforderte Methode transformRules(rules) implementieren.

Es ist zu beachten, dass im Regelcompiler diese Transformations-Methoden un-abhangig voneinander verwendet werden konnen und daher in eigenen Klassen reali-siert wurden. Eine kombinierte Ausfuhrung dieser Transformationen, zum Beispiel,dass diese nacheinander ausgefuhrt werden, ware hier nicht sinnvoll, da diese wirklichunterschiedliche Falle (unterschiedliche Konzepte) der


darstellen. So werden die”query“- und

”answer“-Regeln bei der

”Multilinearen“-


Transformation auf eine etwas andere Weise als bei der”Magic Sets“- oder der

”Supplementary Magic Sets“-Transformation erzeugt (vgl. Kapitel 4).

Arbeitsweise

Die Aufgabe, zu einer gegebenen Regelmenge Rad eine transformierte RegelmengeRtransform zu erzeugen (siehe Abbildung 5.5), wird in der Steuerungsklasse Rules-Compiler automatisch an die dafur zustandige Klasse MagicMethod, Multilinear-Method oder SupplementaryMethod weitergeleitet. Die Transformation wird dabeidurch entsprechende effiziente Methoden dieser Klassen unterstutzt und im We-sentlichen gemaß den im Kapiteln 4 dargestellten Transformationsalgorithmen ge-schehen. Unterschiedliche transformierte Regeln von Typ TransformedRule werdendabei erzeugt und in einer Liste gespeichert, die am Ende der Transformation andie Steuerungsklasse RulesCompiler zuruckgegeben wird.

Der Uberblick uber die wichtigen Methoden (Algorithmen) dieser Klassen kann manin der Abbildung 5.9 sehen.

Im Weiteren wird der Ablauf der jeweiligen Transformation kurz dargestellt.

Ablauf der Transformation in der Klasse MagicMethod

Bei dem Aufruf der Methode transformRules(inputRules) der Klasse MagicMe-thod (siehe Abbildung 5.10) werden zunachst die Hilfsregeln erzeugt (makeHelpRu-les(rules)). Dabei wird ein

”query“-Literal zum Regelkopf am Anfang jedes Regel-

rumpfes gesetzt. Danach werden die”query“- und

”answer“-Regeln in den Methoden

makeQueryRules(rules) und makeAnswerRules(rules) basierend auf diesen Hilfsre-geln erzeugt und der Ergebnisliste hinzugefugt.

Ablauf der Transformation in der Klasse SupplementaryMethod

Das Aktivitatsdiagramm 5.11 zeigt den Ablauf der Transformation nach der”Sup-

plementary Magic Sets“-Methode in der Klasse SuppmagicMethod. Dieser Ablaufkann fur jede Regel in drei logische Schritte aufgeteilt werden. Zunachst werden imSchritt 1 die ersten

”supplementary“-Relationen fur den Regelkopf generiert sowie

die ersten Regeln erzeugt, die diese Relationen definieren. Im Weiteren wird derRegelrumpf sequenziell verarbeitet und fur jedes Rumpfliteral q weitere

”Supple-

mentary“-Relationen sowie sie definierende Regeln erzeugt. Da sich im Allgemeinender Rumpf einer

”supplementary“-Regel aus einem aktuellen Literal und einem vor-

herigen”supplementary“-Literal zusammensetzt, werden diese durch zwei interne

100KAPITEL 5. ENTWURF UND IMPLEMENTIERUNG DES REGELCOMPILERS

erzeuge Hilfsregeln

makeHelpRules(rules)

erzeuge "query"−Regeln

makeQueryRules(rules)

makeAnswerRules(rules)

erzeuge "answer"−Regeln

gebe die transformierten Regeln aus

Abbildung 5.10: Ablauf der”Magic Sets“-Transformation

Variablen suppmagicLiteral und supmPrevios dargestellt. Sie werden beim Erzeu-gen unterschiedlicher Regeln fur jedes Rumpfliteral benutzt und bei dem Ubergangzum nachsten Rumpfliteral aktualisiert.

Die”supplementary“-Relationen und -Regeln werden dann fur jedes Rumpflite-

ral im Schritt 2 erzeugt. Es ist zu bemerken, dass die Argumente eines neu kreierten

”supplementary“-Literals suppmagicLiteral nicht nur die Argumente des zugrunde-liegenden Rumpfliterals q enthalten sollen. Dabei mussen auch die Argumente deranderen Literale berucksichtigt werden, die im Rumpf der

”supplementary“-Regel

vorkommen, die diese”supplementary“-Relation definiert. Es wird durch die Metho-

de verifierArguments(newSupmagicLiteral, supmPrevios, literalForSuppl) gewahrlei-stet.

Im letzten Schritt (Schritt 3) wird die”query“-Regel fur das betrachtende Rumpf-

literal q erzeugt, vorausgesetzt, dass dieses ein abgeleitetes Literal ist. Anschließendwerden interne Hilfsvariablen und unter anderem die Variable supmPrevios mit demaktuell erzeugten Literal suppmagicLiteral aktualisiert. Die unterschiedlichen trans-formierten Regeln, welche wahrend dieser Schritte erzeugt werden, werden in einerErgebnisliste gespeichert und am Ende der Transformation ausgegeben.


erzeuge "query"−Literale und Regeln, falls q abgeleitet ist

Schritt 3

erzeuge die ersten "supplemen− tary"−Literale und Regeln

Schritt 1 Schritt 2

aktualisiere Parameter:

erzeuge "supplementary"−Literale und Regeln

*

(suppmPrevios)

initialisiere Parameter:(suppmagicLiteral,supmPrevios)

für jedes Rumpfliteral q


* [ ]für jede Regel r aus inputRules

Abbildung 5.11: Ablauf der”Supplementary Magic Sets“-Transformation

Ablauf der Transformation in der Klasse MultilinearMethod

Ein Aufruf der Methode transformRules(rules) der Klasse MultilinearMethod be-deutet, dass alle notigen Uberprufungen von unterschiedlichen Bedingungen fur dieAnwendung dieser Transformations-Methode erfolgreich abgeschlossen sind. Die Re-gelmenge, die zur Transformation ubergeben wird (inputRules), besteht also aus-schließlich aus den linearen- oder Basisregeln, die im Abschnitt 4.2.3 definiert wur-den. Abhangig vom jeweiligen Typ der linearen Regel (left-linear, right-lineare odermultilineare) werden unterschiedliche Transformationsalgorithmen verwendet (sieheAbbildung 5.12). Deswegen wird fur jede Regel eine geeignete Transformation aus-gewahlt. Dieses geschieht gemaß den im Vortest zugewiesenen Typen der linearenRegel.

Die Klasse MultilinearMethod enthalt also neben den Transformationsmethodenauch unterschiedliche wichtige Uberprufungsmethoden, mit deren Hilfe eine gegebe-ne Regelmenge bezuglich der fur die Anwendung dieser Transformationsart notwen-digen Bedingungen getestet werden kann. Dabei werden in den dafur zustandigenMethoden die jeweiligen Eigenschaften der linearen Regeln gemaß den im Abschnitt4.2.3 vorgestellten Definitionen fur die rechts-lineare, links-lineare oder multi-lineare

102KAPITEL 5. ENTWURF UND IMPLEMENTIERUNG DES REGELCOMPILERS

Regeln gepruft. Die durch die Steuerungsklasse RulesCompiler veranlassten Uber-prufungen Check2 und Check3 erfolgen mittels diesen Methoden. Außerdem wirddabei (bei der erfolgreichen Uberprufung) jeder Regel ihr Typ zugewiesen, was furden Transformations-Schritt, wie oben beschrieben wurde, bei der Auswahl der ge-eigneten Transformation von großer Bedeutung ist.

transformiere r als eine

transformMultiLinearRule(r)multilineare Regel

ist r eine lineare Regel?

[ ja ]

[ ja ]

[ ja ]

[ nein ]

[ nein ]

[ nein ]

[ ja ]

ist r eine Regel


transformLeftLinearRule(r)links−lineare Regel


transformRightLinearRule(r)rechts−lineare Regel


transformBasisRule(r)Basis−Regel

multi−lineare

ist r eine Regel

ist r eine Regel

ist r eine Regel

ist r eine Regel

links−lineare

rechts−lineare


* [ für jede Regel r aus inputRules ]

Abbildung 5.12: Ablauf der”Multilinearen“-Transformation

Kapitel 6

Uberblick uber weitereimplementierte Komponenten

Der im Rahmen dieser Arbeit realisierte Regelcompiler wurde als eine der erstenKomponenten eines prototypischen deduktiven Datenbanksystems entwickelt. Danoch keine anderen Komponenten des Datenbanksystems (siehe Abbildung 2.1) vor-handen sind, wurden in dieser Arbeit einige dieser Komponenten zum Testen derFunktionalitaten des Regelcompilers realisiert. Sie besitzen vor allem alle fur die Re-gelkompilierung notwendige Funktionalitaten, konnen aber wegen ihrer modularenImplementierung um die weiteren vollen Funktionalitaten einfach erweitert werdenund als eigenstandige Komponenten des DBMS ubernommen werden.

Im Abschnitt 6.1 wird der Uberblick uber die implementierten Komponenten ge-geben. In Abschnitten 6.2 und 6.3 erfolgt die Beschreibung der graphischen Schnitt-stelle und des Parsers entsprechend.

6.1 Motivation

Im Rahmen der Anfragebearbeitung wird der Regelcompiler von dem Anfrage-Manager (siehe Abbildung 2.1) benutzt. Der Anfrage-Manager parametrisiert ihn,ubergibt die zu transformierenden Regeln und stoßt den Regelkompilierungsprozessan. Da wie bereits erwahnt es noch keine dafur zustandigen Datenbankkomponen-ten gibt, sollte ihre Aufrufe zu Testzwecken simuliert werden bzw. die fehlendenKomponenten mit notigsten Funktionalitaten entwickelt werden.

Dazu ist es vorteilhaft, dass der Regelcompiler als eine unabhangige eigenstandi-ge Komponente, die ihre Dienste uber eine Schnittstelle zur Verfugung stellt, im-plementiert wurde. So kann er seine Funktionalitaten unabhangig von der Art der

103

104 KAPITEL 6. WEITERE IMPLEMENTIERTE KOMPONENTEN

Verwendung, d.h. entweder in einem konkreten DBMS oder in einer Testumgebung,uber diese Schnittstelle zur Verfugung stellen. Dazu wurden eine graphische Schnitt-stelle (GUI) zum Regelcompiler und einige andere Komponenten realisiert.

Das Ziel war es also, vor allem die Aufrufe, also die Benutzung des Regelcom-pilers, wahrend der Anfragebearbeitung zu simulieren und seine Funktionalitatenzu uberprufen. In diesem Zusammenhang sollte der Regelcompiler die Regeln in ei-nem internen Format bekommen und von außen unterschiedlich konfigurierbar sein.Deswegen wurde eine graphische Schnittstelle RulesCompilerGui entwickelt, die esermoglicht, das Datalog-Schema zu laden und zu bearbeiten. Außerdem bietet siedie Moglichkeiten, den Kompilierungsprozess zu konfigurieren und anzustoßen, sowieseine Ergebnisse auszugeben. Es wurde ein vereinfachter I/O-Prozessor GuiModelentwickelt, welcher uber die GUI eingegebenen Kommandos und Regeln entgegen-nimmt und sie mit Hilfe eines Parsers Parser in ein internes Format uberfuhrt.Zu den Aufgaben von GuiModel gehort auch die Uberprufung der syntaktischenKorrektheit der eingegebenen Anfrage und des Schema (Regeln) sowie das Ansto-ßen der Anfragebearbeitung simulierender Komponente QueryHandlingSimulation,die hier die Aufgabe hat, lediglich den Regelkompilierungsprozess zu starten. DieUberfuhrung der eingegebenen Datalog-Regeln und der Anfrage in das interne For-mat erfolgt mit Hilfe der Komponente Parser, die dazu ihre lexikalische und syn-taktische Analyse durchfuhrt. Dieses interne Format fur Regeldarstellung in Java(Datastructure) wurde bereits im Kapitel 3 ausfuhrlich beschrieben.

Die Abbildung 6.1 prasentiert die Zusammenarbeit aller oben beschriebenenKomponenten.

Datastructure

Textdateials eineDatalog−

Schemata

RulesCompilerGUI

GUI−Model

QueryHandling−Simulation Regelcompiler

Parser

Zugriffs−komponente

Abbildung 6.1: Architektur der Testumgebung

6.2. GRAPHISCHE SCHNITTSTELLE ZUM REGELCOMPILER 105

6.2 Graphische Schnittstelle zum Regelcompiler

Beim Entwurf der graphischen Schnittstelle wurden folgende Ziele verfolgt. Sie soll-te in erster Linie zu Testzwecken dienen, um die Funktionalitaten des Regelcom-pilers uberprufen und die Arbeitsweise beobachten zu konnen. Dazu sollten in dergraphischen Schnittstelle alle verfugbaren Funktionen bzw. ihre bequeme Einstel-lung unterstutzt werden. Außerdem sollten die fur die Regelkompilierung benotigtenTestdaten (Regeln und Anfrage) auch in GUI angezeigt und bei Bedarf modifiziertwerden konnen. Die wichtigen Aufgaben konnen wie folgt zusammengefasst werden:

• Konfiguration samtlicher Kompilierungsparameter

• Laden des bestehenden Datalog-Schema bzw. Ermoglichen, die Regeln undAnfrage selbst zu verfassen und zu modifizieren

• Ausgabe aller Informationen uber den Kompilierungsprozess und Zwischener-gebnisse

Zusatzlich wurden auch Anforderungen bezuglich einer einfachen Bedienbarkeitund Fehlerrobustheit berucksichtigt. So wird die graphische Darstellung in drei ab-gegrenzte Bereiche aufgeteilt: der Bereich zur Konfiguration der wichtigen Kompi-lierungsparameter, Eingabebereich fur die zu transformierenden Regeln (input rules)und Ausgabebereich fur die Veranschaulichung der Ergebnisse (test output). Alleeinzustellenden Parameter sind durch spezielle Auswahlboxen vordefiniert, so dasseine korrekte Parameterubergabe ermoglicht wird.

Daruber hinaus wurde beim Entwurf der Architektur der graphischen Schnitt-stelle eine Variante des Model-View-Controller (MVC)-Prinzips, namlich Model-Delegate-Prinzip verfolgt, bei dem eine Trennung zwischen der graphischen Dar-stellung und Verarbeitungslogik der Komponente angestrebt wird ([13]). So ist dieKlasse RulesCompilerGui fur die Interaktion mit dem Benutzer und die Prasen-tation der Daten zustandig, wahrend die Klasse GuiModel fur die Verwaltung derDaten verantwortlich ist. Somit kann die graphische Darstellung bei einer moglichenWeiterentwicklung leicht geandert und erweitert werden.

Die Abbildung 6.2 zeigt die Hauptansicht der graphischen Schnittstelle zum Re-gelcompiler. Die wichtigsten Komponenten werden im Folgenden beschrieben.

Eingabebereich

Das Datalog-Schema bzw. die zu kompilierenden Regeln werden in die Textflacheinput rules geladen (siehe Abbildung 6.2). Diese Flache ist als eine Liste realisiert,


Abbildung 6.2: Graphische Schnittstelle zum Regelcompiler

so dass in jeder Zeile eine einzige Regel oder Relationsdefinition steht. Daher kannjede Regel nach dem Wunsch modifiziert (editiert) werden, was mit Hilfe des sichunten befindenden Panel Edit rule geschieht. Jede zu editierende Regel wird nachdem Doppelmausklick aus der Liste geloscht und in den Textfeldern Head und Bodyerscheinen, wo sie modifiziert werden kann. Danach kann sie nach dem Knopfdruck[add rule] wieder in die Liste aufgenommen werden. Daruber hinaus kann jede neueRegel durch Knopfdruck [add rule] der Liste auch hinzugefugt werden. Die graphischeSchnittstelle bietet zudem die Moglichkeit nicht nur ein existierendes Schema zuladen sondern auch ein modifiziertes oder eine selbst verfasstes zu speichern. So kannzum Beispiel ein abgeandertes Test-Schema dann wieder mit Hilfe des Menupunktes

”File | Save“ oder

”File | Save As“ gespeichert werden.

Konfigurationsbereich

Die graphische Schnittstelle gibt dem Benutzer die Moglichkeit, die gewunschtenParameter der Regelkompilierung einzustellen. Wie man in der Abbildung 6.2 se-hen kann, befinden sich auf der linken Panel unterschiedliche Auswahlboxen fur die

6.3. PARSER 107

Einstellung der unterstutzten Parameter (siehe Kapitel 5), wie die Regelkompilie-rungsart (compilation art), die Transformationsmethode (compilation method) oderdie SIP-Strategie (SIP-Strategy). Bei der Auswahl der

”on demand“-Kompilierung

wird das Textfeld”query“ zum Editieren der gewunschten Anfrage aktiviert und bei

einer”precompile“-Kompilierung dagegen deaktiviert.

Sind die gewunschten Parameter konfiguriert oder die automatisch beim Aufrufvon GUI voreingestellten Parameter akzeptiert, kann die Regelkompilierung zumBeispiel mit dem Knopfdruck [compile] angestoßen werden. Das heißt, dass sie inden Zustandigkeitsbereich der Klasse GuiModel kommt. Die Eingabedaten wer-den zunachst lexikalischer und syntaktischer Analyse mit Hilfe des Parsers (KlasseParser) unterzogen. Sind alle Regeln und Anfrage syntaktisch korrekt und wurdedaruber hinaus die Anfrage passend zu den eingegebenen Regeln gestellt (d.h. ob siemit dem Kopf mindestens einer Regel unifizierbar ist), wird die Regelkompilierungangestoßen.

Ausgabebereich

Die Ergebnisse der Regelkompilierung sowie eventuelle Fehlermeldungen werdendann in der Textflache test output erscheinen. Daruber hinaus werden dabei diebei der Kompilierung verwendeten Parameter und die relevanten Zwischenergebnis-se (wie etwa eine

”adorned“-Regelmenge) ausgegeben.

Jede Input-Regel kann zudem mit Hilfe des Menupunktes”Rules | Internal For-

mat“ im internen Format auch in der Ausgabeflache test output angezeigt werden.Eine Beispielausgabe einer Regel mit der Beschreibung ihres internen Formates kannman in der Abbildung 6.4 sehen.

6.3 Parser

Bevor die Regeln verarbeitet werden, mussen sie in ein internes Format (vgl. Kapitel3) uberfuhrt werden. Dafur ist die Klasse Parser zustandig.

Der Parser bekommt als Eingabe eine Liste der Strings, welche die einzelnenZeilen des Datalog-Schema (also Regeln, Relationsdeklarationen, Integritatsbedin-gungen) prasentieren. Zunachst erfolgt eine lexikalische Analyse, mit dem Ziel diegegebenen Strings in eine Folge von elementaren Bestandteilen zu zerlegen. Wenn dieerkannten Bestandteile syntaktisch korrekt sind, d.h. der im Abschnitt 2.3 vorgestell-ten Grammatik fur die DDL und DML fur Datalog genugen, werden entsprechendeinterne Objekte erzeugt. Eine semantische Analyse, das heißt die Uberprufung, obzum Beispiel die eingegebenen Relationen wirklich existieren oder jede regeldefinier-te Relation als abgeleitet deklariert wurde, wird hier nicht durchgefuhrt. Das gehort


zu den Aufgaben des Schema-Managers, was dann spater einfach geschehen kann.Zur Uberprufung der Funktionalitaten des Regelcompilers in dieser Testumgebungwird im Weiteren angenommen, dass die eingegebenen Regeln semantisch korrektsind.

...

+ getInternalRules(): ArrayList+ makeQuery(queryStr: String): QueryLiteral− getNextLitString(input: String): String− parseString(input: String, muster: String): String[]− matchString(String input, String muster): boolean− makeRule(rulrStr: String): Rule− makeBodyLiterals(bodyStr: String): Arraylist− makeNormalLiteral(litStr: String): NormalLiteral− makeAssignLiteralLiteral(litStr: String): AssignLiteral− makeTerm(termStr: String): Term

− schema: String[]...

Parser

+ parseSchema(): void

Abbildung 6.3: Klasse Parser

Die Zerlegung in elementare Bestanteile erfolgt stufenweise. Zunachst wirdzwischen Elementen

”Regel“,

”Relationsdefinition“ oder

”Integritatsbedingung“ in

Abhangigkeit davon, womit die untersuchende Zeile anfangt, unterschieden. Dannwird eine Regel (bzw. ein String, der sie prasentiert) weiterzerlegt. Dabei wird Pat-tern Matching verwendet. Es wird also nach bestimmten Zeichenfolgen gesucht,die mit einem speziellen Suchmuster ubereinstimmen. Mit Hilfe des Java-Paketesjava.util.regex lassen sich die Zeichenketten (Strings) nach einem Muster einfach su-chen bzw. auf Vorhandensein eines Musters prufen. So wird zunachst nach demMuster

”< − “ gesucht, um eine Regel in zwei Teile

”Kopf“ und

”Rumpf“ zu zer-

legen. Danach wird der Rumpf in einzelne Literale und die Literale ihrerseits ineinzelne Argumente zerlegt. In unterschiedlichen Methoden zum Zerlegen von ver-schiedenen Literaltypen und Argumenttypen werden auch dort relevante Musterwie zum Beispiel Klammern

”( “ (zum Bestimmen des String, welcher die Argu-

mente des Literals prasentiert) oder Kommas”, “ oder andere regulare Ausdrucke

wie etwa”>= “ eingesetzt. Die komplexen Elemente werden sukzessiv in kleinere

Elemente in Bezug auf die syntaktischen Regeln eindeutig zerlegt. Die wichtigenMethoden dieser Klasse kann man in der Abbildung 6.3 sehen. Genugt ein gera-de zu untersuchendes Element der Grammatik der Sprache nicht, wird das Parsenabgebrochen und eine Fehlermeldung ausgegeben. Das passiert zum Beispiel, wenneine Regel keinen Rumpf enthalt oder wenn in einem Vergleichsliteral als Argument

6.3. PARSER 109

ein Compound-Term vorkommt (siehe Kapitel 2).

Nach dem Parsen werden die internen Objekte erzeugt. Das wird durch die ent-sprechenden Konstruktoren der jeweiligen Klassen der Datenstruktur (vgl. Kapitel3) unterstutzt. Analog wird zu der Anfrage ein QueryLiteral erzeugt. Der Parsergibt dann die Regeln im internen Format als eine Liste zuruck.

In der Abbildung 6.4 wird eine Beispielausgabe einer Regel, insbesondere ih-rer einzelnen Bestandteile, im internen Format dargestellt. Diese textuelle Ausgabewird zudem mit Hilfe entsprechender Ausgabemethoden der jeweiligen Klassen derDatenstruktur unterstutzt.

p(X,Y) <− p(X,Z), !q(X), X<=10, s(Z,’bonn’)Rule:

Head:

Bodyliterals:

Arguments

Arguments

Arguments

Arguments

Arguments

Term: X, [typ] "Variable", [pos] 0, [status] "free"Term: Y, [typ] "Variable", [pos] 1, [status] "free"

Term: X, [typ] "Variable", [pos] 0, [status] "free"Term: Z, [typ] "Variable", [pos] 1, [status] "free"

Term: X, [typ] "Variable", [pos] 0, [status] "free"

Term: X, [typ] "Variable", [pos] 0, [status] "free"Term: 10, [typ] "Constant", [pos] 1, [status] "bound"

Term: Z, [typ] "Variable", [pos] 0, [status] "free"Term: ’bonn’, [typ] "Constant", [pos] 1, [status] "bound"

p(X,Z) [pos] 1, [typ] "positiv" ("NormalLiteral"), [status] "derived"

p(X,Y) [pos] 0, [typ] "positiv" ("NormalLiteral"), [status] "derived"

!q(X) [pos] 2, [typ] "negativ" ("NormalLiteral"), [status] "stored"

X<=10 [pos] 3, [typ] "CompareLiteral"

s(Z,’bonn’) [pos] 4, [typ] "positiv" ("NormalLiteral"), [status] "stored"

Abbildung 6.4: Beispiel einer Regel im internen Regelformat

Kapitel 7

Zusammenfassung

Das Ziel dieser Diplomarbeitarbeit war, eine Komponente zur effizienten Anfra-gebearbeitung eines deduktiven DBMS zu realisieren, die eine Regelkompilierungdurchfuhrt. Dieser Regelkompilierung liegt die

”Magic Sets“-Transformation zu

Grunde und daher sollten ihre wesentlichen Konzepte durch geeignete Methodenunterstutzt werden. Daruber hinaus bestand ein weiteres Ziel darin, auch ande-re Optimierungstechniken bei der Anfragebearbeitung zu untersuchen und die ge-eigneten zur Verbesserung der

”Magic Sets“-Transformation im Regelcompiler zu

realisieren. Dazu wurde eine Komponente - Regelcompiler - entwickelt und imple-mentiert, die eine beliebige Regelmenge sowohl bezuglich einer gegebenen Anfrageals auch bezuglich einer gegebenen Regelmenge selbst generierter Anfragen trans-formiert. Der Regelcompiler unterstutzt somit sowohl eine

”on demand“- als auch

eine”precompile“-Kompilierungsart. Außerdem realisiert er neben der

”Magic Sets“-

Transformation auch andere effiziente Transformations-Methoden, die abhangig vonder gegebenen Regelmenge und Anfrage ausgewahlt werden konnen. Die Funktiona-litaten des Regelcompilers wurden mit Hilfe der dafur entwickelten Komponenten(graphische Schnittstelle und zusatzliche erforderliche Komponenten des DBMS)erprobt.

Zu einer effizienten Regelverarbeitung in einem DBMS sollen die Datalog-Regelnin ein fur die Verarbeitungsanwendungen geeignetes Format uberfuhrt werden.Da der Regelcompiler in der Programmiersprache Java implementiert wurde, be-stand ein weiteres Ziel dieser Arbeit darin, eine Datenstruktur zur Darstellung vonDatalog-Regeln in Java zu realisieren. Im Kapitel 3 wurden der Entwurf und dieImplementierung dieser Datenstruktur prasentiert. Einer der wichtigsten Entwurfs-kriterien war es, dass die Datenstruktur (ihre Elemente) sowohl syntaktische Kon-zepte von Datalog-Regeln als auch die Regelkompilierung durch spezielle Zugriffs-und Hilfsmethoden unterstutzt. Daruber hinaus sollte eine einfache Erweiterbarkeitum die fur die anderen Anwendungen relevante Eigenschaften ermoglicht werden.

111

112 KAPITEL 7. ZUSAMMENFASSUNG

Aufgrund dieser Kriterien wurden wahrend der Anforderungsanalyse wichtigeBestandteile der Datenstruktur identifiziert und ihre Implementierung als einzelneElemente (Objekte) motiviert, die ihre Eigenschaften und Verhalten kapseln. Beidem Entwurf der Datenstruktur wurden außerdem die objekt-orientierten Konzep-te wie Datenkapselung, Polymorphismus, Vererbung und Wiederverwendung sowieunterschiedliche Design-Paterns eingesetzt, damit die Datenstruktur den gestelltenAnforderungen gerecht wird. Die erstellte Datenstruktur besteht aus drei Gruppenvon Elementen: Regelhierarchie, Literalhierarchie und Argumenthierarchie, welchedie Verarbeitungsmethoden durch ihre Modellierung sowohl die Datalog-Konzepteals auch durch entsprechendes Verhalten unterstutzen.

Das Kapitel 4 beschaftigte sich mit der Untersuchung der”Magic Sets“-Methode

und insbesondere der unterschiedlichen Optimierungstechniken zur Verbesserung derAnfragebearbeitung. Das Ziel bestand darin, solche Ansatze auszuwahlen, die imRegelcompiler zur Verbesserung der

”Magic Sets“-Transformation eingesetzt wer-

den konnten. Dazu mussten die zu untersuchenden Ansatze die Kriterien bezuglichsowohl der Kombinierbarkeit mit dem

”Magic Sets“-Ansatz als auch der moglichen

Integration in die bestehende Datenstruktur erfullen, um zum Beispiel eine einheit-liche Ergebnis-Regelmenge zu erzeugen. Unter den untersuchten Techniken habensich folgende zur Implementierung als geeignet erwiesen: die


Sets“- und die”Multilineare“-Transformation, die mit der

”Magic Sets“-Methode

sehr gut kombinierbar sind und deutliche Verbesserungen bringen. Eine behebt denNachteil, dass die identischen Daten bei der Materialisierung der

”Magic Sets“-

transformierten Regeln redundant berechnet werden, und die andere bringt eine vieleffizienter auswertbare Regelmenge fur eine spezielle Unterklasse von linearen Re-geln. Daruber hinaus wurden einige Heuristiken zu einer verbesserten Generierungeiner SIP-Strategie wie most-bounded, min-free und left-to-right ausgewahlt, welcheauch die Effizienz der Magic SetsTransformation erhohen konnen.

Nachdem die zugrundeliegende Datenstruktur festgelegt wurde und die Verbes-serungsansatze diskutiert wurden, wurde im Kapitel 5 der Entwurf und die Im-plementierung der Komponente Regelcompiler vorgestellt. Zunachst wurden dieMoglichkeiten zur Realisierung des Regelcompilers in Bezug auf die formuliertenAnforderungen untersucht. Dabei wurden die einzelnen Bestandteile des Kompilie-rungsprozesses identifiziert und deren mogliche Aufteilung in Module motiviert. Beidem nachfolgenden Entwurf der Architektur wurden dann sowohl funktionale alsauch nichtfunktionale Anforderungen berucksichtigt und eine flexible, leicht ander-bare und verstandliche Architektur angestrebt. Das wurde durch den Einsatz vonDesign-Patterns und allgemeinen Prinzipien eines Systementwurfes ermoglicht. Sowurde die Architektur des Regelcompilers modular aufgebaut, so dass jedes Mo-dul fur eine eigene Aufgabe verantwortlich ist. Der Regelcompiler setzt sich ausdrei wichtigen Modulen zusammen: Steuerungsklasse RulesCompiler, Adornments-

113

Propagierung und Transformations-Methoden, die durch entsprechende Schritte der

”Magic Sets“-Transformation sowie der ausgewahlten Optimierungstechniken mo-tiviert wurden. Solche getrennte Modellierung ermoglicht zudem eine unabhangigeErweiterbarkeit der einzelnen Module um weitere Konzepte, was im Hinblick auf diemoglichen hinzukommenden Optimierungstechniken wichtig ist.

Der Regelcompiler wurde als eine eigenstandige Komponente realisiert, die ihreDienste (Regelkompilierung) nach außen uber eine eigene Schnittstelle bietet und so-mit einfach in ein deduktives Datenbanksystem integriert werden kann. Dieser kannuber diese Schnittstelle konfiguriert und angestoßen werden. Der Regelcompiler kannsomit sowohl eine geeignete effiziente Transformation bezuglich der gegebenen Re-gelmenge und Anfrage automatisch vornehmen (d.h. zwischen den implementiertenMethoden eine passende wahlen) als auch die von außen gesetzten gewunschten Pa-rameter verwenden. Wenn die Regeln fur alle mogliche Anfragemuster im Voraustransformiert werden sollen (

”precompile“), werden unterschiedliche zu der Regel-

menge passende Anfragen vom Regelcompiler generiert und die Regelkompilierungwird bezuglich dieser Anfragen ausgefuhrt.

Da der Regelcompiler als eine der ersten Komponenten des prototypischen DBMSentwickelt wird und noch keine anderen Komponenten vorhanden sind, wurden eini-ge zum Testen der Funktionalitaten des Regelcompilers erforderliche Komponentenrealisiert. Sie besitzen vor allem alle fur die Regelkompilierung notwendige Funk-tionalitaten, konnen aber einfach wegen ihrer modularen Implementierung um dieweiteren vollen Funktionalitaten erweitert und als eigenstandige Komponenten desDBMS ubernommen werden. Der Kapitel 6 beschaftigte sich mit der Darstellungder realisierten Komponenten. Es wurden eine graphische Schnittstelle zum Regel-compiler, ein I/O Prozessor sowie ein Parser fur die Uberfuhrung der Test-Regelnin das interne Format entwickelt.

In der Forschungsliteratur gibt es außerdem viele weitere Optimierungstechni-ken der Anfragebearbeitung, die untersucht und zur Verbesserung der

”Magic Sets“-

Transformation im Regelcompiler verwendet werden konnen. Das betrifft die auf derRegeltransformation und Fixpunktiteration basierenden Ansatze. Außerdem konnennoch weitere Heuristiken fur die Generierung gunstiger SIP-Strategien erforscht undauch im Regelcompiler realisiert werden. Eine unabhangige Erweiterung des Re-gelcompilers sowohl um die neuen SIP-Generierungsmoglichkeiten als auch um dieneuen Transformationsmethoden wird durch die Architektur des Regelcompilers ein-fach ermoglicht. Daruber hinaus konnen die zu Testzwecken realisierten Komponen-ten weiterentwickelt werden und zusammen mit weiteren im Rahmen anderer For-schungsprojekte realisierten Komponenten eines DBMS in ein prototypisches Systemintegriert werden.

114 KAPITEL 7. ZUSAMMENFASSUNG

Literaturverzeichnis

[1] P. J. Azevedo. Magic Sets with Full Sharing. Journal of Logic Programming(JLP),30:223–237, March 1997.

[2] I. Balbin, G. Port, K. Ramamohanarao and K. Meenakshi. EfficientBottom-up Computation of Queries on Stratified Databases. Journal of LogicProgramming (JLP),15:295–344, March 1991.

[3] C. Beeri and R. Ramakrishnan. On the Power of Magic. In Proceedingsof the 6th ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Da-tabase Systems, pages 269–283, 1987.

[4] A. Behrend. Effiziente Materialisierung regeldefinierter Daten in PROLOG.Diplomarbeit, Rheinische Friedrich-Wilhelms-Universitat Bonn, Institut fur In-formatik III, 1999.

[5] F. Bry. Logic Programming as Constructivism: A Formalization and its Ap-plication to Databases. In Proceedings of the 8thACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, pages 34–50. ACM,March 1989.

[6] F. Bry, R. Manthey und H. Schutz. Deduktive Datenbanken. KI - Kunst-liche Intelligenz, (3):17–23, September 1996.

[7] A. B. Cremers, U. Griefahn und R. Hinze. Deduktive Datenbanken - EineEinfuhrung aus der Sicht der logischen Programmierung. Vieweg-Verlag, 1994.

[8] S. Dustdar, H. Gall und M. Hauswirth. Software-Architekturen fur Ver-teilte Systeme, (Kapitel 4 Architekturelle Prinzipien, Bausteine und Muster).Springer Verlag, Juli 2003.

[9] Gesellschaft fur Informatik e.V.-. Informatik-Lexikon.http://www.gi-ev.de/informatik/lexikon/inf-lex-deduktive-db.shtml.

115

116 LITERATURVERZEICHNIS

[10] C. Ghezzi, M. Jazayeri and D. Mandrioli. Fundamentals of SoftwareEngineering. Prentice Hall, 1991.

[11] U. Griefahn. Reaktive model computation: A uniform approach to the imple-mentation of deductive database. Dissertation, Rheinische Friedrich-Wilhelms-Universitat Bonn, Institut fur Informatik III, 1997.

[12] I. Jacobson, G. Booch and J. Rumbauch. The Unified Software Develop-ment Process. Object Technology. Addison-Wesley, 1999.

[13] G. Kruger. Handbuch der Java-Programmierung. Addison-Wesley, 2002.http://www.javabuch.de/.

[14] R. Manthey. Folien zur Vorlesung Deduktive Datenbanken im WS’1999/2000.Rheinische Friedrich-Wilhelms-Universitat Bonn, 1999.

[15] R. Manthey. Folien zur Vorlesung Deduktive Datenbanken im SS’2003. Rhei-nische Friedrich-Wilhelms-Universitat Bonn, 2003.

[16] J. F. Naughton, R. Ramakrishnan, Y. Sagiv and J. D. Ullman. Effi-cient Evaluation of Right-, Left-, and Multi-Linear Rules. In SIGMOD Conf.,pages 235–242, 1989.

[17] R. Ramakrishnan. Magic Templates: A Spellbinding Approach to Logic Pro-grams. In Proc. Joint Symposium on Logic Programming and InternationalConference on Logic Programming, 1988.

[18] Software Design Pattern Catalog. http://patterndigest.com/.

[19] G. Specht und O. Krone. Zur Steuerung und Optimierung der SIP-Auswahlin der Magic Set Transformation. In T. Christaller, editor, GWAI-91: Proc. der15. Fachtagung fur Kunstliche Intelligenz, Bonn, Deutschland, pages 33–42.Springer, 1991.

[20] O. Speidel. Entwurf und Implementierung einer Erweiterung von Datalog umaktive Regeln. Diplomarbeit, Rheinische Friedrich-Wilhelms-Universitat Bonn,Institut fur Informatik III, 2001.

[21] C. Ullenboom. Java ist eine Insel, Dritte Auflage, Programmieren fur dieJava 2-Plattform in der Version 1.4. Galileo Computing, 2003.HTML-Version http://www.galileocomputing.de/openbook/javainsel3/.

[22] J. D. Ullman. Principles of Database and Knowledge-Base Systems, volumeII: The New Technologies. Computer Science Press, 1989.

LITERATURVERZEICHNIS 117

[23] A. v. Gelder. The Alternating Fixpoint of Logic Programs with Negation. InProceedings of the 8thACM SIGACT-SIGMOD-SIGART Symposium on Prin-ciples of Database Systems, pages 1–10. ACM, March 1989.

118 LITERATURVERZEICHNIS

Erklarung

Hiermit erklare ich, dass ich diese Diplomarbeit selbstandig durchgefuhrt und keineanderen als die angegebenen Quellen und Hilfsmittel benutzt habe.

Bonn, den 19. Juli 2004

Entwurf und Implementierung einer Kompo- nente zur ... · Kapitel1 Einleitung...

Documents

Transcript of Entwurf und Implementierung einer Kompo- nente zur ... · Kapitel1 Einleitung...