Das System LDL

Inhaltsverzeichnis

  1. Einleitung
  2. Logische Fundierung anhand von Hornklauseln
  3. Verwendung von Mengen als Datenobjekte
  4. Negation
  5. Aktualisierung
  6. Compilationstechniken
  7. Einsatz von LDL für Boolsches Dokumentenretrieval
  8. Schlußbetrachtung
  9. Literaturangaben





Einleitung

LDL (Logic Data Language) ist von dem Unternehmen Microelectronics and Computer Technology Corporation (MCC) in Austin, Texas entwickelt worden. Ebenso wie bei NAIL! war die Zielsetzung bei der Entwicklung von LDL, die Flexibilität logischer Programmierung mit der Leistungsfähigkeit relationaler Datenbanken zu kombinieren. Diese Kombination erforderte eine logikbasierte Anfragesprache, welche die Mächtigkeit von Prolog mit besonderen Eigenschaften der relationalen Systeme verbindet. Diese Eigenschaften sind die einfache Verwendung sowie die Geeignetheit für parallele Verarbeitung und für "secondary storage management". Eine derartige Sprache sollte rein deklarativ in der Weise sein, daß die Ausführungskontrolle (controll over the execution) in die Verantwortung des Systems übergeht. Dieses System wäre in der Lage, neben traditionellen Datenbankanfragen auch deduktive "retrieval" und schlußfolgerende Anfragen abzuarbeiten. Ferner würde es datenintensive und wissensbasierte Anwendungen bzw. Anwendungen im Zusammenhang mit Expertensystemen unterstützen.
In der Hauptsache waren Aktivitäten in zwei Aspekten erforderlich:
  1. Eine logikbasierte Sprache war zu entwickeln, die frei von sequentiellen Ausführungsmodellen und anderen nicht-deklararive Prologkonstrukten wie der CUT ist, ohne daß sie die Funktionalität von Prolog verliert.
  2. Compilation der Datenbasis und Techniken der Optimierung waren zu erweitern, um die größere Funktionalität dieser Sprache zu handhaben.

Aus diesen Anforderungen ergaben sich die Besonderheiten von LDL, auf die im folgenden näher eingegangen wird. Im Anschluß daran werden die Compilationstechniken in LDL skizziert, um die Ausführungen zu LDL abzurunden.



Zurük zum Inhaltsverzeichnis


Logische Fundierung anhand von Hornklauseln

Die sequentielle Abarbeitung der Regeln in Prolog impliziert, daß der Programmierer die Verantwortung für die Anordnung der Regeln und Fakten innerhalb jeder Regel hat und weiß, wie das anstehende Problem zu lösen ist. Diese Verantwortung geht in LDL auf das System über. Folgendes Beispiel ist ein gültiges LDL-Programm für die
Ableitung der Vorfahrensbeziehung, wobei par ( X , Y ) die Basisrelation ist: 
	anc ( X , Y )  *  par ( X , Z ), anc ( Z , Y ).
	anc ( X , Y )  *  par ( X , Y ).
Wenn eine Zielspezifikation wie im Beispiel in Prolog aufgestellte wäre, dann würde die erste Klausel vor der zweiten abgearbeitet werden. Dies hätte zur Folge, daß eine Anfrage in Prolog nicht terminieren würde. In LDL ist die Reihenfolge der Spezifikation ebenso wie bei Datalog irrelevant, da beide Klauseln während der Compilierung analysiert werden, bevor eine Anfrage ausgeführt wird. Das Ergebnis dieser Analyse ist eine Ausführungsstrategie und ein Anfrageoptimierungsprozeß, die eher die allgemeine Bedeutung der Hornklauseln berücksichtigen, als eine Strategie, die auf die besondere Anordnung der Klauseln abzielt.
In LDL ist die Verwendung von 'komplexen Termen' möglich. In dem folgenden Beispiel enthält die Relation emp Informationen über den Vor- und Familiennamen, dem Beruf und der Ausbildung der Angestellten. Die Verwendung solcher komplexer Terme bewirkt die Zusammenfassung von einzelnen Fakten z.B. nach der Ausbildung der Angestellten in einer flexiblen Weise, die sich nicht auf die rigide Tupelstruktur von relationalen Systemen beschränkt.
	emp ( joe , cool , porter , none ).
	emp ( max , fax , guard , high_school ( 1976 ) ).
	emp ( joe , doe , vp , college ( ms , engl , school ( ut , tx ), 1981 ) ).
	emp ( fred , red , staff , college ( ms , ba , school ( mit , ma ), 1983 ) ).

Interessant hierbei ist, daß die benutzten Begriffe in den Fakten wie high_school, college und school als Platzhalter dienen, der die Strukturierung der Terme ermöglicht. Komplexe Terme stiften in bewerteten Funktionssymbolen keine Verwirrung, die nicht in LDL explizit definiert sind.
Ferner können Regeln durch Verwendung von komplexen Termen gelöst werden. Folgende Regel ermittelt den Namen, die Schule und das Jahr der Gradierung von MBA's, die ihr Studium nach 1981 abgeschlossen haben. 
	new_mbas ( Last , First , School , Year )	*
			emp ( Last , First , _ , college ( ms , ba , School , Year ) ),
			Year > 1981.

Die Anfrage ? - new_mbas ( L , F , S , Y ) würde, angewendet auf die obere Datenbasis, die Menge { ( fred , red , mit , 1983 ) } ergeben. Die Formulierung dieser Anfrage in einer konventionellen Datenbank erfordert entweder die Unterscheidung zwischen Angestellten mit nur einer high_school-Ausbildung und Angestellten mit einer college- Ausbildung oder die Spezifizierung mit Nullwerten (null values) in der normalisierten Relation und der gleichzeitigen Bewältigung von Problemen, die durch die Vereinigung mit Nullwerten entstehen.
In LDL ist es auch möglich, komplexe Terme in rekursiven Regeln zu verwenden. Nachfolgend ist das Beispiel von der Hinzufügung (appending) an eine Liste dargestellt. Die Liste in dem Beispiel ist der komplexe Term und würde als * ( x1 , * ( x2 , ... * ( xn , nil) ... ) repräsentiert werden, wobei " * " der Operator für Listenkonkatenation (list concatenation) steht. 
	append ( X , nil , X ).
	append ( X , A , Z , B , X )  *  append ( A , Z , B ).



Zurük zum Inhaltsverzeichnis


Verwendung von Mengen als Datenobjekte

LDL gestattet Variablen und Argumenten, Mengen als Werte aufzufassen. Falls in einer Anfrage eine Variable auftaucht, würde die Antwort alle möglichen Ergebnisse liefern, die sich aus der Datenbasis ableiten lassen. Bezogen auf das obere Beispiel mit der Vorfahrenrelation würde die Anfrage ? - anc ( joe , X ). als Antwort alle Vorfahren von joe ergeben. Insofern werden Mengen implizit bei der Abarbeitung von Anfragen berücksichtigt.
Mengen können in LDL auch explizit durch Aufzählung der Elemente definiert werden. Hierbei werden die Mengen als Objekte in die Fakten eingebettet. Im Gegensatz zu Prolog brauchen die Objekte nicht als Listen dargestellt werden. Folgendes Beispiel veranschaulicht diese Art der Mengendefinition, wobei das Prädikat hobbies_of ( VORNAME , MENGE_DER_HOBBIES ) alle Hobbys eines Individuums enthält. 
	hobbies_of ( kurt , { gardening , physics , spirtism } ).
	hobbies_of ( john , { gardening , painting , shopping } ).
	hobbies_of ( emanuel , { surfing , ufo_watching } ).
	hobbies_of ( robert , { physics , spiritism , gardening } ).
Durch die Anwendung der Regel 
	same_hobbies ( X , Y )  *  hobbies_of ( X , Z ), hobbies_of ( Y , Z ), X * Y.
auf die Datenbasis können neue Fakten gefolgert werden, nämlich 
	same_hobbies ( kurt , robert )	und
	same_hobbies ( robert , kurt ).
In LDL ist es auch möglich, durch Gruppierung Mengen zu generieren. Mengengenerierung ist der Prozeß, bei dem sich alle Elemente einer Menge aufgrund einer Spezifikation erzeugen lassen. Mathematisch wird eine Menge durch folgende Schreibweise generiert: 
	S = { x | p ( x ) }
S ist die Menge, bei der p ( x ) ein Prädikat auf x ist bzw. x die Eigenschaft p erfüllt. In LDL kann eine Menge anhand folgender Regel generiert werden: 
	s ( < X > )  *  p ( X ).
Bezüglich der oben dargestellten Vorfahrensrelation kann anhand der folgenden Regel die Menge aller Vorfahren generiert werden. 
	anc_set ( X , < Par > )  <-  anc ( X , Par ).
Auf die Anfrage ? - anc_set ( X , Y ). kämen als Ergebnis alle Vorfahren der in der Datenbasis vorhandenen Personen.
Das nachfolgende Beispiel erzeugt eine Menge aus Artikeln, die von einem Lieferanten bezogen werden, wobei die Basisrelation suppl ( Sup# , Item# ) wäre. 
	item_set ( Sup# , < Item# > )  *  suppl ( Sup# , Item# ).
Die Anfrage ? - item_set ( S , L ). ergibt ein unnormalisierte Relation, der von der Basisrelation die Menge der von jedem Lieferanten zugestellten Artikel zusammenfaßt.
Es ist auch möglich, die Anzahl der Elemente in der Menge zu ermitteln, da in LDL Rechenvorgänge erlaubt sind. Im folgenden Beispiel wird die Anzahl der Artikel errechnet, die von jedem Lieferant geliefert werden. 
	item_count ( Sup# , Count )  *   item_set ( Sup# , S), card ( S , Count ).
	card ( {} , 0 ).
	card ( { X } , 1 ).
	card ( Set , Value )  *	part ( Set , Set1 , Set2 ),
				card ( Set1 , Value1 ),
				card ( Set2 , Value2 ),
				Value = Value1 + Value2.
Die Kardinalität einer Menge ist ein Konzept der Logik zweiter Ordnung und daher in Hornklauselnlogik nicht spezifizierbar. Allerdings ist dieses Konzept von großem praktischem Nutzen. Aus diesem Grunde wurde in LDL eine Erweiterung in der Form der ersten Teilung, der sog. primitive partition ( S , S1 , S2 ), eingeführt. Hierbei wird eine Menge S in zwei disjunkte Untermenge S1 und S2 mit mindestens einem Element geteilt. Diese "partition primitive" ermöglicht die Spezifikation der Kardinalität in einer rekursiven Weise und die Berechnung jeder geteilten Untermenge kann parallel erfolgen. Andere Beziehung z.B. die Aggregation von Mengen kann in einer ähnlichen Weise spezifiziert werden. Die Rekursion beruht auf der leeren Menge und die Menge mit einem Element. Der Vergleich Value = Value1 + Value2 zeigt die Handhabung mit Arithmetik und Vergleichsprädikaten in LDL. Das Gleichheitszeichen und andere Vergleichsprädikate ( >, >= , ... ) werden formell derart behandelt, als ob sie durch abgeschlossene Mengen von Fakten mit zwei komplexen Argumenten definiert sind. Diese Fakten können all die Argumentenwerte annehmen, die der Vergleich zuläßt. Beispielsweise wird die Menge, die mit " < " Prädikat verbunden wird, nicht nur ( 1 < 2 , 1 < 3 , ... ) umfassen, sondern auch ( 1 < 1 + 1 , ... 1 < 4 - 2 , ... ) usw. Diese Art von Arithmetik ist klarer als das Prädikat in Prolog.
Nachfolgend ist ein weiteres Beispiel für Mengenaufzählung wiedergegeben. Im Beispiel folgt die Relation 3_distinct_parts aus der Basisrelation suppl und schließt auf alle Lieferanten, die mindestens drei unterschiedliche Teile liefern. 
	3_distinct_parts ( Sup# , { X , Y , Z } )  *	suppl ( Sup# , X ),
						suppl ( Sup# , Y ),
						suppl ( Sup# , Z ),
						distinct ( X , Y , Z ).
Die Liste aller Lieferanten, die zumindest die Teile a, b und c liefern, wäre mit der Anfrage ? - 3_distinct_parts ( S , { a , b , c } ) zu erhalten. Mengen können in einer "non-minimalen" Weise spezifiziert sein. Die Auslassung des Prädikates distinct auf der rechten Seite der Regel würde die mögliche Wiederholung von Elementen auf der linken Seite verursachen. Zum Zwecke der Unifikation sind diese "non-minimalen" Mengen mit minimalen Mengen gleichwertig und daher unifizierbar. Die Zuweisung { X/a , Y/a , Z/b } wäre mit { a , b } gleichbedeutend.
In LDL sind auch eine Reihe von vordefinierte Mengenoperationen vorhanden. Bei diesen vordefinierten Mengenoperationen handelt es sich um Funktionssymbole, die eine präzise Bedeutung haben und insofern nicht frei interpretierbar sind. Eine dieser Mengenoperationen sind die geschweiften Klammern { ... }. Wie aus den vorangegangen Beispiel zu erkennen, werden mit ihr Mengen beschrieben. Z.B. bedeutet der schon verwendete Ausdruck { } die leere Menge und { X } die einelementige Menge, dessen einziges Element den Wert von X übergeben bekommt.
Im folgenden werden noch weitere in LDL vordefinierte Mengenoperationen aufgezählt, jedoch ohne den Anspruch auf Vollständigkeit erheben zu wollen. Beachtenswert ist bei dem Funktionssymbol scons, daß sie die Eigenschaften Kommutativität und Idempotenz erfüllt, die von Mengenoperationen erfordert wird. D.h. scons erfüllt die folgenden Anforderungen: 
	Kommutativität:		scons ( X , scons ( Y , S ) ) = scons ( Y , scons ( X , S ) )
	Idempotenz:		scons ( X , scons ( X , S ) ) = scons ( X , S )
Beispielsweise kann die Menge { a , b , c } als scons ( a , scons ( b , scons ( c , { } ) ) ) oder scons ( b , scons ( c , scons ( a , { } ) ) ) usw. dargestellt werden.
In dem folgenden Anwendungsbeispiel wird das Prädikat disjoint verwendet, um die Schnittmenge zweier Mengen zu bestimmen. Die Idee dabei ist, Schnittmenge induktiv anhand der Anzahl der Elemente in der Schnittmenge auszudrücken. 
	inter ( S , T , {} )  *  disjoint ( S , T ).
	inter ( scons ( X , S ) , scons ( X , T ) , scons ( X , U ) )  *  inter ( S , T , U ).
Die erste Regel besagt, daß die Schnittmenge disjunkter Mengen leer ist, die zweite bestimmt die Schnittmenge von nicht-disjunkten Mengen dadurch, daß die gemeinsamen Elemente X aus den Mengen S und T herausgefunden werden. Die gemeinsamen Elemente werden aus beiden Mengen S und T gelöscht und in die Schnittmenge U eingefügt.



Zurük zum Inhaltsverzeichnis


Negation

Eine weitere Besonderheit von LDL ist die Negation, welche die Negation in Prolog durch failure ersetzt. Die Negation in LDL basiert auf die Berechnung von Mengenunterschieden in den Relationen der zugrundeliegenden Domäne. Das nachfolgende Beispiel veranschaulicht die Verwendung einer solchen Negation. 
	orphan ( X )  <-  person ( X ), NOT father ( X , Y ),  NOT  mother ( X , Z ).
Dieses Beispiel könnte durch eine NBF nicht dargestellt werden, da die NBF ein Test. Beispielsweise erfordert NOT mother ( X , Z ) keine Bindung für X oder Z. Wenn auch person ( X ) zuerst ausgeführt werden würde, enthalten die beiden anderen Bedingungen ungebundene Variablen. NBF ist für Bedingungen nicht definiert, die ungebundene Variablen einschließen.
In LDL wird eine negierte Bedingung in einen relativ komplementen Ausdruck übersetzt. Beispielsweise würde für * A eine Obermenge B von A gefunden und * A durch B - A ersetzt werden. Wenn keine Obermenge gefunden werden könnte, dann soll die Negation 'undefiniert' oder 'unsicher' sein. Der Zweck der Obermenge beruht auf der Vorstellung, daß eine Relation aus einer Menge von Tupelobjekten besteht und jedes Tupel ein Objekt ist. Auf die einzigartige Identifizierung von Tupelobejekten basierend kann eine Menge B mit B * A definiert werden, wenn alle Objekte in A auch in B enthalten sind. B sollte ein Obermenge von A sein. Mit anderen Worten wird eine Teilordnung * auf die Relationen in LDL auferlegt.
Bezogen auf das obere Beispiel wird das Ergebnis anhand der folgenden Berechnung ermittelt: 
	ORPHAN ( X )	*  PERSON ( X ) -  *   X ( FATHER ( X , Y )  *  MOTHER ( X , Z ) )
Die Verwendung der Negation zwingt insofern eine Teilordnung bei der Berechnung der Bedingungen einer Regel auf: Die positiven Literale werden vor ihren Negationen abgearbeitet. Der Versuch, die negierten Literale direkt z.B. durch Berechnung des Komplements einer Menge zu ermitteln, kann zu einer unendlichen Menge und allgemein zu unsicheren Ergebnissen führen. Der allgemeine Fall einer Schnittmenge, bei der eine Negation vorkommt, wird durch die folgende Regel wiedergegeben: 
	r ( X , Y )  *  q ( X , Y ), *  p ( Y , Z ).
Die zugrundeliegende relationale Interpretation für diesen Fall ist: 
	R ( X , Y ) = Q ( X , Y ) -  *  XY ( Q ( X , Y )  YY P ( Y , Z ) ).
Dieser Fall deckt auch den sich nicht-schneidenden Sachverhalt in Gegenwart von Negation ab.



Zurük zum Inhaltsverzeichnis


Aktualisierung

Eine vollständige Aktualisierungsfähigkeit in einer logikbasierten Datenbanksprache unterstützt die Aktualisierung in Form des Hinzufügens, des Löschens und des Veränderns der Datenbankschemata, der Basisrelationen und der abgeleiteten Relationen. LDL bietet nur eine minimale Möglichkeit zur Aktualisierung von Schemata und Basisrelationen. Datenbankschemata können durch folgende Ausdrücke aktualisiert werden: 
	create ( RelationName , NrArgument ).
	destroy ( RelationName ).
Diese Ausdrücke enthalten die Vollständigkeits- bzw. Integritätskontrolle, die zur Erhaltung des einzigen Relationennamens erforderlich ist. Relationen können anhand nachstehenden Ausdrücken in Daten geladen und entladen werden: 
	load ( RelationName , File ).
	unload ( RelationName , File ).
Über dieser atomischen Aktualisierung der Relationen (Einfügen, Löschen und Verändern eines Tupels in einer Basisrelation) hinaus ist das Problem der Aktualisierung bisher offen und Gegenstand der Forschungsbemühungen. Insbesondere sind folgende Punkte von Interesse:
  1. Die Spezifikation von zusammengesetzter Aktualisierung, d.h. wie kann das (Teil-) Ergebnis einer Aktualisierung in der Art übergeben werden, daß die spätere(n) Aktualisierung(en) einer zusammengesetzten Aktualisierung ersichtlich sind. Die Übergabe sollte datenbezogen und konsistent mit dem Paradigma der logischen Programmierung sein.
  2. Die Parametrisierung einer zusammengesetzten Aktualisierung, d.h. wie kann eine zusammengesetzte Aktualisierung in der Art spezifiziert werden, daß sich zur Vermeidung der Respezifikation zu jeder Zeit eine neue Menge von Relationen entwickelt. Dieser Punkt ist ein Thema der Softwareentwicklung, verglichen mit dem vorhergehenden Punkt, der sich mit Semantiken beschäftigt.



Zurük zum Inhaltsverzeichnis


Compilationstechniken

In LDL wurde eine Compilierungsmethode gewählt, mit der die Ziele Berechnungsunterstützung bei dem Modell "Menge-zu-einer-Zeit" und hohe Leistungsausführung der Anfragen erreichbar sind. Der Compillierungsprozeß erfolgt in zwei Phasen:
  1. Die Compilierung der Regeln
  2. Die Compilierung und Optimierung von Anfragen
Regeln werden in eine interne Form namens prediate connection graph transformiert, der dem rule/goal graph bei NAIL! ähnlich ist, jedoch nicht die adornments hat, die die ungebundenen und freien Argumente anzeigen. Nach dem umfassenden Anfrageoptimierungsprozeß werden Regeln in einen intermediate code namens FAD übersetzt. FAD ist im wesentlichen die relationale Algebra, erweitert um die Fähigkeit mit Funktionssymbolen und Kontrollflüssen umzugehen. Diese Struktur speichert die Beziehungen zwischen Termen und den Klauselheads, die (potentiell) unifiziert werden können. Zudem dienen sie als Ausgangspunkt für einzelne Anfragen.
Die Faktoren, die den Anfrageoptimierungsprozeß bestimmen, sind die Regel- und Termkomplexität von den Regeln und ihren Argumenten, die durch die Anfragen aufgerufen werden. Die in LDL angewendete Technik ermöglicht die Compilierung von rekursiven Regeln mittels (halb-)naiver Evaluation und sog. "Zaubermengen" (magic sets).
Die Architektur des LDL Anfrageoptimierers unterscheidet sich wesentlich von dem in NAIL!, obwohl der ‘Nettoeffekt’ häufig der gleiche ist. Um auf eine Anfrage mit einigen gebunden und einigen freien Argumenten zu antworten, legt LDL das Bindungsmuster für alle benötigten Prädikate selber fest. Im Unterschied zu NAIL! zeichnet LDL Bedingungen bzw. Unterziele an diesem Punkt nicht auf, aber berücksichtigt sorgfältig die Ordnung, in der es die Beziehungen zu den entsprechenden Bedingungen bzw. Unterziele vereinigt hat, wenn es später naive Bewertungen der Regeln durchführt. Sobald das Bindungsmuster bekannt ist, werden Regeln zum Zwecke der Anfrage neu geschrieben. Diese Umwandlung erfolgt durch
  1. sog. Zaubermengen
  2. speziellen Transformation für links- oder rechtslinearen Regeln
  3. einer „Auszähltransformation“ für lineare Regeln
  4. einer Transformation, die Projektionen, so schnell wie möglich in der Weise durchführt, das die links- und
  5. rechtslinearen Transformationen so früh wie möglich Selektionen ausführen.
Wenn mehr als eine Technik anwendbar ist, so wird die links- und/oder rechtlineare Transformation vor allen anderen vorgezogen. Andernfalls wird die Auszähltransformation vor den sog. Zaubermengen (magic sets) bevorzugt. Nach Anwendung der Transformation, die möglich ist, werden die resultierenden Regeln durch eine naive (bottum- up) Technik evaluiert.
Die durch diese Technik entstehenden Probleme sind die Verbreitung (propagation) von ausgewählten Operationen in der rekursiven Schleife und die frühe Elimination von redundanten Tupeln, die zu der Ergebnismenge kein Beitrag leisten.
Ein andere „compile-time“ Analyse ist für Sicherheitszwecke (safety purposes) nötig. Diese Analyse ist insbesondere bei der Existenz von arithmetischen Prädikaten wichtig, da infolge dieser Analyse gesichert ist, daß die generierte Ergebnismenge für eine Anfrage abgeschlossen ist. Nachfolgend ist ein Beispiel für eine unsichere Regel dargestellt: 
	p ( X , Y )		X = Y.
Die Anfrage ? - p ( 3 , Y ) ist sicher, wohingegen die Anfrage ? - p ( X , Y ) in dem Sinn unsicher ist, daß sie eine unendliche Menge von Antworttupeln generieren könnte. In LDL werden solche unsichere Antworten von vornherein im Rahmen der Compilierung ausgeschlossen.



Zurük zum Inhaltsverzeichnis


Anwendung von LDL

Das folgende Beispiel soll zeigen, wie LDL auch zur Modellierung von Booleschem Dokumentenretrieval in Anlehung an das CSLIB-2000-Datenmodell verwendet werden kann. Ähnliches wurde bereits für DATALOG [Fuhr95] untersucht, welches allerdings über keine Mengen als Terme oder Gruppierungs-Operatoren verfügt. Letztere sind aber gerade sehr nützlich, um geschachtelte Ergebnisse zu erzeugen, welche sich auch für die hypertextuelle Aufbereitung eignen.

Allgemeines Wissen aus der Domäne

Generalisierungen, Abstraktion

dokument(D) <- monographie(D).
dokument(D) <- kongressband(D).
dokument(D) <- reihe(D).
dokument(D) <- artikel(D).
dokument(D) <- sammelwerk(D).

selbstaendigErschienen(D) <- monographie(D).
selbstaendigErschienen(D) <- sammelwerk(D).
selbstaendigErschienen(D) <- kongressband(D).

enthaelt(D,E) <- gezaehltErschienenIn(E,_,D).
enthaelt(D,E) <- veroeffentlichtIn(E,D).

produzent(D,P) <- herausgeber(D,P).
produzent(D,P) <- verfasser(D,P).
produzent(D,P) <- verlag(D,P).

Rekursion

enthaeltR(D,E) <- enthaelt(D,E).
enthaeltR(D,E) <- enthaelt(D,X), enthaeltR(X,E).

umfasstR(O,U) <- umfasst(O,U).
umfasstR(O,U) <- umfasst(O,X), umfasstR(X,U).

indexiertDurchR(D,B) <- indexiertDurch(D,B).
indexiertDurchR(D,B) <- umfasstR(B,U),indexiertDurch(D,U).

Gruppierungen

produzenten(D,<P>) <- produzent(D,P).
bestandteile(D,<E>) <- enthaelt(D,E).
dokumente(P,<D>) <- produzent(D,P).
inhaltR(D,<E>) <- enthaeltR(D,E).
Vererbung', abgeleitete Eigenschaften 
verlag(D,V) <- verlag(R,V),gezaehltErschienenIn(D,_,R),reihe(R).
erscheinungsjahr(D,E) <- erscheinungsjahr(X,E),veroeffentlichtIn(D,X).

Dokument-Datenbank (Fakten)

Dokumentbeschreibung 
reihe(r1).
titel(r1,'Reihe Informationswissenschaft der DGD').
herausgeber(r1,'Wolfram Neubauer').
verlag(r1,'Deutsche Gesellschaft fuer Dokumentation').
indexiertDurch(r1,'Informationswissenschaft').

monographie(d1).
titel(d1,'Anfragesprache fuer Informationssysteme').
erscheinungsjahr(d1,1991).
verfasser(d1,'Ulrike Reiner').
gezaehltErschienenIn(d1,1,r1).
indexiertDurch(d1,'Anfragesprache').
indexiertDurch(d1,'Informationssystem').
indexiertDurch(d1,'IQL').

sammelwerk(d2).
titel(d2,'Texte verstehen - Konzepte, Werkzeuge, Methoden').
herausgeber(d2,'A. Böhm').
herausgeber(d2,'A. Mengel').
herausgeber(d2,'T. Muhr').
gezaehltErschienenIn(d2,14,r1). % hoffentlich stimmt das

artikel(d3).
titel(d3,'Anfragesprachen fuer Textsuchsysteme').
verfasser(d3,'Ulrike Reiner').
veroeffentlichtIn(d3,d2).
indexiertDurch(d1,'Anfragesprache').
indexiertDurch(d1,'Textsuchsystem').
Thesaurus 
umfasst('Wissenschaft','Informationswissenschaft').
umfasst('System','Suchsystem').
umfasst('System','Informationssystem').
umfasst('Suchsystem','Textsuchsystem').
umfasst('Sprache','Anfragesprache').

beispielFuer('IQL','Anfragesprache').

verwandtZu('Suchsystem','Informationssystem').

Anfragen

% Dokumente von Ulrike Reiner
ergeb1(X) <- dokumente('Ulrike Reiner',X).
--> ergeb1 = {{d1,d3}}

% Dokumente der DGD
ergeb2(X) <- dokumente('Deutsche Gesellschaft fuer Dokumentation',X).
--> ergeb2 = {{d1,d2}}

% Produzenten mit ihren Dokumenten
ergeb3(P,D) <- dokumente(P,D).
--> ergeb3 = {('Ulrike Reiner', {d1,d3}),
              ('Deutsche Gesellschaft ...', {d1,d2}),
              ('T.Muhr', {d2}),
              ('A. Mengel', {d2}),
              ('A. Böhm', {d2})}


% In der Reihe r1 direkt oder indirekt enthaltene Dokumente
ergeb4(X) <- inhaltR(r1,X).
--> ergeb4 = {{d1,d2,d3}}

% Dokumente, die mit 'Suchsystem' oder Unterbegriff davon indexiert sind und
% nach 1990 erschienen sind mit Erscheinungsjahr
ergeb5(X,E) <- indexiertDurchR(X,'Suchsystem'),erscheinungsjahr(X,E),E > 1990.
--> ergeb5 = {(d3, 1991)}



Zurük zum Inhaltsverzeichnis



Schlußbetrachtung

LDL wurde als Projekt in Angriff genommen, um relationale Datenbanken und logische Programmierung miteinander zu verknüpfen. Daher ist LDL ein Datenbank-Mangementsystem und gleichzeitg auch ein Logikprozessor. Diese Verknüpfung ist geboten, damit zum einen iterative und rekurisve Anfragen an Datenbanksysteme gestellt werden können. Zum anderen wird solch eine Verknüpfung arithmetische und Mengenoperationen auf Datenbasen zulassen. Sowohl iterative und rekursive Anfragen als auch arithmetische und Mengenoperationen bringen insbesondere bei datenintensiven und wissensbasierten Anwendungen sowie bei Anwendungen von Expertensystemen Effizienzgewinne.Es wird deutlich, daß eine logische Anfragesprache wie LDL sehr mächtige Hilfsmittel zur Realisierung von Booleschem Dokumentenretrieval bereitstellt.



Zurük zum Inhaltsverzeichnis


Literaturangaben

Zurük zum Inhaltsverzeichnis



Copyright ©: 1996, Uzay Mericten, Revised April 29, 1996