Zum Problem der Kopplung von Expertensystemen und Datenbanken

deposit_hagen

Publikationsserver der Universitätsbibliothek

Mathematik und

Informatik

Informatik-Berichte 69 – 05/1987

Renate Meyer, Ulrich Prädel,

Gunter Schlageter, Rainer Unland Zum Problem der Kopplung von

Expertensystemen und Datenbanken

Abstract Sobald

Zum Problem der Kopplung von Expertensystemen und Datenbanken

bei der

R. Meyer, U. Prr:idel, G. Schlageter,

R. Unland

Praktische Informatik I Fernuniversität Hagen

Post fach 940 D 5800 Hagen

Kopplung von Expertensystemen und Datenbanken Perfonnancegesichtspunkte berücksichtigt werden, müssen eine Reihe von Einflußfaktoren betrachtet werden, die zum Teil gegenseitige Abhängigkeiten aufweisen und die Kopplung zu einem vielschichtigen Optimierungsproblem werden lassen.

In dieser Arbeit werden die Abhängigkeiten zwischen Datenbankkosten und Expertensystemkosten aufgezeigt, die in Strategien und Verfahren für Kopplungen berücksichtigt werden müssen.

Diese Arbeit entstand i1 Rah1en des Projektes ffKopplung ES und DBSw, das vo1 Nissenschafts•inisteriu• des Landes NRW gefördert und in Kooperation 1it der Fir1a Nixdorf Computer AG, Paderborn, durchgeführt wird.

1. Einleitung

Für einige wichtige Anwendungsbereiche weisen Expertensysteme (ES) schwerwiegende Defizite auf: die fehlende Möglichkeit, große Faktenmengen zu verwalten, die fehlende Unterstützung eines Mehrbenutzerbetriebes und die mangelhafte Konsistenzsicherung. Dies sind Aufgaben, die von konventionellen Datenbanksystemen (DBS) seit langem ausgeführt werden. Hinzu kommt, daß existierende Datenbestände für ES nutzbar sein müssen. Aus diesen Gründen werden ES und DBS gekoppelt. Dieses Ziel verfolgt ein Projekt, das von der Fernuniversität Hagen und der Nixdorf Computer AG durchgeführt wird. Erste Ergebnisse dieses Projekts werden hier vorgestellt.

ES und DBS wurden gänzlich unabhängig voneinander entwickelt. DBS wurden konzipiert, um große Datenmengen in effizienter Weise zu verwalten. ES wurden entwickelt, um vergleichsweise kleine Mengen von Daten intelligent zu verarbeiten. Intelligent heißt in diesem Zusammenhang, daß ES nicht nur explizite Daten (=Fakten) verwalten können, sondern auch Wissen (z.B. in Form von Regeln) eigenständig verwalten und anwenden können.

Beim derzeitigen Stand der Entwicklung liegt die Frage nahe, inwieweit sich die Techniken der beiden Gebiete in der Form kombinieren lassen, daß sie sich gegenseitig in möglichst idealer Weise ergänzen. Beide Systemtypen weisen unterschiedliche Ansätze in ihren Kernfunktionen auf:

Verwaltung der Daten

DBS sind in der Lage, große Datenmengen effizient zu verarbeiten. Insofern wurde beim Design dieser Systeme davon ausgegangen, daß alle Daten auf externen Speichermedien gespeichert werden. Um effizienten Zugriff auf diese Daten zu gewährleisten, werden aufwendige Zugriffsmechanismen unterhalten.

Da bei der Entwicklung von ES davon ausgegangen wurde, daß die Daten immer im Hauptspeicher gehalten werden können, existieren keine effizienten Speicherabbildungs- und Zugriffsmechanismen. ES suchen sequentiell im Hauptspeicher über Pattern Matching.

Struktur der Daten

Im Bereich der DBS werden nur einfache Datenstrukturen unterstützt. Die Basis des Relationalen Datenmodells bilden Relationen, die Mengentheorie und das Prädikatenkalkül.

Da in einem ES eine wesentlich feinere Modellierung der Realwelt verlangt wird, ist das zugrunde liegende Datenmodell wesentlich flexibler.

Grundlagen bilden z.B. die Modellierungskonzepte der künstlichen

Intelligenz. Typisch sind Modelle mit Hierarchien von Objekten und der Möglichkeit der Vererbung.

Verarbeitung der Daten

DBS bieten zur Verarbeitung der Daten Abfragesprachen. Bei einer Abfrage (Query) wird das DB-Schema benutzt, um den Zielbereich der Query systematisch einzugrenzen. Im allgemeinen sind Queries einfacher auszuwerten und damit schneller als Inferenzen in ES, Eine Erklärungskomponente für die Queryauswertung ist nicht vorhanden.

ES beantworten Anfragen mit Hilfe eines Inferenzmechanismus. Der Inferenzmechanismus benutzt vorhandene Daten und Wissen, um daraus neue Daten herzuleiten. Der Inferenzmechanismus ist i. allg, mächtiger als die Queryauswertung, da nicht immer alle Inferenzschritte in relationale Ausdrücke umgesetzt werden können, er ist jedoch auch langsamer. Die Erklärungsfähigkeit wird durch das Protokollieren von Inferenzschritten gewährleistet.

Systemstruktur Die Systemstruktur Mehrbenutzerfähigkeit

der und

DBS ist gekennzeichnet durch Begriffe wie Konsistenz. Das DBS gewährleistet parallele Arbeit vieler Benutzer auf denselben Daten ohne gegenseitige Beeinflussung.

Das System ist in der Lage, nach Fehlern selbständig wieder einen konsistenten Zustand zu rekonstruieren.

Die Systemstruktur von ES ist bisher recht einfach. ES sind als Einbenutzersysteme entwickelt, die keine Möglichkeiten bieten, nach Fehlern wieder aufzusetzen.

Einige Defizite von ES können durch geschickte Ankopplung von DBS aufgehoben werden:

externe Faktenbasen

Eine Reihe von ES-Anwendungen verlangt, auf extern vorhandene Fakten zuzugreifen. Dies kann der Fall sein bei schon aus anderen Anwendungen vorhandenen Datenmengen oder dort, wo die Faktenmenge für den Hauptspeicher des Systems zu groß wird.

Fehlertoleranz und Mehrbenutzerfähigkeit

Anwendungen von ES in der Praxis sind oft zeitintensiv. Es ist nicht akzeptabel, bei Fehlern den Verlust der kompletten geleisteten Arbeit hinzunehmen. Eine effiziente Nutzung der eingesetzten Ressourcen verlangt, daß mehrere Benutzer gleichzeitig mit einer ES-Anwendung arbeiten können.

Hierzu bietet die DB-Welt ausgereifte Konzepte zur Konsistenzerhaltung und Integritätswahrung an, deren Anwendungsmöglichkeit geprüft werden muß.

Die entscheidende Frage ist, wie bei einer Kopplung eine effiziente Verteilung der Systemfunktionen zwischen ES und DBS definiert werden kann.

In dieser Arbeit wird ein spezieller Aspekt dieses Problems beleuchtet. Kapitel 2 liefert hierzu die terminologischen Grundlagen. In Kapitel 3 wird auf die Optimierungsproblematik eingegangen, die entsteht, wenn existierende ES und DBS effizient miteinander gekoppelt werden sollen. Dabei werden die Kosten für eine solche Kopplung auf die entstehenden ES- und DB-Kosten zurückgeführt. Es wird jeweils untersucht, welche Kopplungsstrategien sinnvoll sind, um die Kosten zu minimieren. In Kapitel 4 werden einige andere Einflußfaktoren auf die Gesamtkosten einer Kopplung betrachtet und deren Auswirkungen diskutiert.

Basierend auf den vorgeschlagenen Strategien werden in Kapitel 4 Kopplungsverfahren entwickelt, die derzeit in der Fernuniversität Hagen implementiert werden.

Bei den Strategien wird vorausgesetzt, daß am ES Modifizierungen möglich sind, um vom ES aus queries an das DBS abzusetzen, d.h. die schnellen Abfragemechanismen des DBS auszunutzen. Das DBS soll völlig unverändert bleiben.

2. Grundlagen

Für die folgenden Betrachtungen wird angenommen, daß das zugrundeliegende ES zu der Klasse der regelbasierten Systeme gehört. Diese ES bestehen im wesentlichen aus drei Komponenten: einer Regelbasis, einer Faktenbasis und einem Inferenzmechanismus. Regeln und Fakten bilden die Wissensbank des ES.

Die Regeln sind von der Form

if <Regelprämisse> then <Ziel>,

wobei die Regelprämisse aus mit und und oder verknüpften Bedingungen (auch Teil- ziele) besteht.

Der Inferenzmechanismus leitet aus Fakten und Regeln neue Fakten her.

Dabei entscheidet er jeweils, welche Regel aktuell anzuwenden ist. Im folgenden wird als Inferenzmechanismus die Rückwärtsverkettung (backward chaining) angenommen, d.h. es werden in der aktuellen Situation nur die Regeln berücksichtigt, deren Prämissen dazu beitragen, ein vorgegebenes Ziel zu erreichen. Wenn die Prämissen der Regeln nicht bekannt sind, werden Teilziele generiert, um die fehlenden Prämissen herzuleiten (vgl. <Pupp>). Diese

Vorgehensweise entspricht der depth-first Suche durch den und-oder-Baum (vgl.

<Kawa>):

Definition: und-oder-Baum

Sei p ein herzuleitendes Ziel, dann gilt:

a) der Wurzel-Knoten ist mit p markiert

b) wenn ein Ziel q hergeleitet werden soll und eine Regel der Form q0 ,

q1 , • • • , qn -> q existiert, die q auf die Teilziele q1 • • • qn reduziert,

dann wird q durch das Bünde 1 der Kanten er1,,1ei tert, die q mit den Teilzielen qi verbinde~. Sind die qi mit oder verknüpft, so wird das Bündel mit ~ , ansonsten mit /\ markiert.

c) wenn qi sich nicht mehr in Teilziele zerlegen läßt (qi ist Blatt, d.h.

es realisiert einen Zugriff auf Fakten, ist eine atomare Bedingung etc), wird qi durch eine Kante mit Q verbunden.

5

Anmerkung: Die Hefleitung von Zielen, die sich durch einen und-oder-Baum darstellen läßt, läßt keine rekursiven Regeln zu. Die Ver1,,1endung rekursiver Regeln ließe sich in einem und-oder-Graphen (siehe <Kawa>) darstellen. Der Einfachheit halber wird hier auf Rekursion verzichtet.

Beispiel 1: Die folgenden Regeln haben zum Ziel, die Marke und den Preis eines Leihwagens (Regel 1) zu ermitteln, der entweder wegen einer Sonderaktion besonders preiswert ist (Regel 2) oder der bequem ist und mit dem es möglich ist, über 100 km Fahrtstrecke ohne Aufpreis zurückzulegen

(Regel 3).

If LWAktion(XMarke,YPreis)

or LWbequem(XMarke,YPreis) Regel 1

then Leihwagen(Xmarke,Ypreis);

If Aktion(Xmarke,Ypreis) Regel 2

then LWAktion(XMarke,YPreis);

If Marke(Xmarke,bequem) and Preis(Xmarke,Ypreis)

and Km(Xmarke,Zkm) Regel 3

and Zkm>=l00

then LWbequem(Xmarke,Ypreis).

Der dazugehörende und-oder-Baum sieht wie folgt aus:

Leihwagen(X11arke,Vpreis)

LWbequem(Xmarke,Ypreis) LWAktion(Xmarke,Vpreis)

Aktion(K1ari Marke(X1arke,beque1) Preis(Xmarke,Ypreis) Kn(X1arke,Zk1) Aktion(VW,l) Marke(Ford,beque1)

Marke(Gogo,unbeque•) Marke(BMW,beque•)

Preis(Gogo,10) Preis(BMW,250) Preis(Ford,5)

Km(Gogo,O) Km(Ford,20) K11(BMW,200)

Zkm>=lOO

[J

•

Die Fakten werden in Prolog-ähnlicher Notation geschrieben, d.h. durch Angabe eines Namens (Marke) und den Werten (Gogo,unbequem). Die Fakten gehören somit zu einer Faktenmenge, in der alle Elemente denselben Namen und dieselbe Anzahl von Werten haben. Die Vereinigung aller Faktenmengen bildet die Faktenbasis des ES.

Im folgenden werden die zur Herleitung eines Zieles p notwendigen Fakten interessant sein.

Definition: Kontext, präziser Kontext

Der Kontext bzgl. eines Teils des und-oder-Baumes ist die Familie aller Faktenmengen, auf die in diesem Teilbaum zugegriffen wird. Ist p ein Ziel, so heiBt der Kontext des und-oder-Baumes von p Kontext von p.

Ein Kontext von p heißt präzise, wenn er nur solche Fakten enthält, die zur Herleitung des Zieles p notwendig sind. •

Beispiel 2: Der Kontext des Zieles Leihwagen( ••• ) aus Beispiel l besteht aus allen Fakten der Faktenmengen Aktion, Marke, Preis und Km.

Der präzise Kontext von Leihwagen( ••• ) besteht nur aus den Fakten Marke(BMW,bequem), Preis(BMW,250) und Km(BMW,200), sowie dem Fakt Aktion(VW,l). •

3. Kostenfaktoren für eine Kopplung

Mit der Kopplung von ES und DBS soll es möglich sein, vom ES auf Fakten zuzugreifen, die auf externen Speichermedien also in Datenbanken untergebracht sind. Dabei sollen existierende DBS und ES möglichst ohne Änderungen miteinander gekoppelt werden.

7

Im folgenden wird die Kostenproblematik einer solchen Kopplung näher betrachtet.

Es wird vereinfachend angenommen, daß sich die Gesamtkosten nur aus den ES- Kosten und den DB-Kosten zusammensetzen. Ziel der Kostenbetrachtung ist es, Verfahren für ein Zusammenspiel von ES und DBS zu finden, die die Gesamtkosten so gering wie möglich halten.

Ausgehend von den ES-Kosten wird eine Strategie für ein Verfahren entwickelt, das diese Kostenart möglichst gering hält. Anschließend wird dasselbe mit den DB-Kosten durchgeführt. Es wird sich zeigen, daß diese Strategien in einigen Punkten nicht miteinander verträglich sind. Aus diesem Grund wird für die Senkung der Gesamtkosten vorges<;:hlagen, die Strategien soweit wie möglich zu

"vermischen".

ES-Kosten

Die Kopplung zwischen ES und DBS soll zum Ziel haben, die externe Datenbank (DB) als Erweiterung der internen Faktenbasis des ES behandeln zu können (vgl.

<JaVa>). Aus diesem Grund stehen bei den Aufwandsbetrachtungen des ES die Fakten und nicht die Regeln im Vordergrund.

Die Suche im ES ist eine rein sequentielle Suche. Um ein Ziel p herzuleiten, muß aus dem Kontext von p eine Kombination von Fakten gefunden werden, die den in den Regeln festgelegten Bedingungen genügt. Wenn eine Kosteneinheit auf ES-Seite

(KEl!:s> einem Zugriff auf Fakten entspricht, dann gilt für die ES-Kosten zur Herleitung eines Zieles p:

Bemerkung 1: Die ES-Kosten für die Herleitung eines Zieles p, dessen Kontext aus n Faktenmengen mit jeweils m:j,, i E {l, ••• ,n} Elementen besteht, betragen

"'

maximal O ( 1T m:j,) KEES • •

i.

Beispiel 3: Suche im ES.

Marke(Xmarke,bequeni) Marke(Ford,bequem) Marke(Gogo,unbequem) Marke(BMW,bequem)

LWbequem(Xmarke,Ypreis)

/ ~---

Preis ( Xm a r k e, Y preis) Km(Xmarke,Zkm) Zkm>=lOO Preis(Gogo,10)

Preis(BMW,250) Preis(Ford,S)

Km(Gogo,O) Km(Ford,20) Km(BMW,200)

Das Beispiel zeigt den und-Baum der "LWbequem"-Regel aus Beispiel 1.

Das Ziel LWbequem( ••• ) ist erreicht, wenn ein Fakt in der Menge Marke gefunden

ist, das in der zweiten Komponente ein "bequem" stehen hat, wenn es außerdem ein Fakt in der Menge Preis gibt, das den zur Marke passenden Preis ermittelt und wenn ein Fakt in der Menge Km gefunden ist, welches für die Marke die Bedingung

>= 100 erfüllt.

Eine gesuchte Faktenkombination besteht dann aus den Fakten Marke (BMW, bequem).

Preis(BMW,250), Km(BMW,200).

Die in den Regeln festgelegten Bedingungen können explizit die Bedingungen der Regelprämissen ( 2km >= 100) sein, aber auch implizit durch Konstanten ( zweite Komponente von Marke bequem) bzw. Gleichheit von Variablennamen (Marke(Xmarke,bequem), Preis(Xmarke,Ypreis) ) ausgedrückt werden.

Um eine geeignete Kombination von Fakten zu finden, wird das ES die Faktenmengen des Kontextes sequentiell durchlaufen. Hier wird zuerst die Faktenmenge "Marke", dann die Faktenmenge "Preis" und dann die Faktenmenge "Km" durchsucht , um dann die Bedingung Zmarke >= 100 zu überprüfen. •

Wenn also der Kontext von p verkleinert bzw. präziser wird, verringern sich auch die Kosten des ES.

Diese Überlegung wird dann interessant, wenn Faktenmengen aus der DB in das ES geholt werden. In DB-Anfragen können Ergebnisrelationen durch Angabe von Bedingungen eingeschränkt werden. Somit können geladene Fakten bereits derart aufbereitet sein, daß sie z.T. bereits die in den Regeln festgelegten Bedingungen erfüllen. Zu diesen Bedingungen gehört z.B. die Kenntnis von konstanten Werten, die Gleichheit von Variablennamen, die Anfrage nach der Existenz von Fakten, Vergleichsoperationen, usw. Darüberhinaus kann man auch die Kenntnis darüber, wie diese Bedingungen miteinander verknüpft sind (und, oder) dazuzählen. Alle diese Bedingungen werden im folgenden statische Bedingungen

genannt.

Werden Variablenbelegungen zum Zeitpunkt des DB-Aufrufs berücksichtigt, so kann man von dynamischen Bedingungen sprechen. Dynamische Bedingungen werden erst zur Laufzeit des ES fixiert.

Sowohl die dynamischen als auch die statischen Bedingungen - bis auf die oder-

Verknüpfung - haben einschränkende Wirkung. Das heißt, wird eine Bedingung auf eine Faktenmenge angewendet, so verkleinert sie diese. Die oder- Verknüpfung hingegen bewirkt, daß Alternativen betrachtet werden. Angewendet auf zu holende Faktenmengen bedeutet dies, daß alle mit oder verknüpften Faktenmengen geho 1 t werden, auch wenn zur Herleitung des Zieles nur eine notwendig ist. Möglichst viele Bedingungen vom ES in die DB zu verlagern, heiBt also auch, möglichst viele Verknüpfungen von Bedingungen in der DB auszuführen. Dies wiederum hat zur Folge, daß möglichst gro8e zusammenhängende Teile des und-oder-Baumes in der DB ausgeführt werden:

9

Bemerkung 2:

a) Je größer die zusammenhängenden, nur mit und verknüpften Teile des und-oder-Baumes sind, die bei der Herleitung eines Zieles p vom DBS ausgeführt werden, desto geringer sind die ES-Kosten zur Herleitung von p.

b) Die Berücksichtigung dynamischer Bedingungen im DBS senkt die ES- Kosten. •

Die Frage ist nun, wie möglichst große Teile des und-oder-Baumes in der DB ausgeführt werden können. Die Teile des und-oder-Baumes setzen sich aus verknüpften Bedingungen zusammen, die vom InferenzprozeS in einer bestimmten Reihenfolge überprüft werden. Bedingungen, die direkt nacheinander abgeprüft werden, können auch zusammengefaßt in einem DB-Aufruf abgearbeitet werden. Die Abarbeitungsreihenfolge der Bedingungen ist in dem hier betrachteten ES-Modell durch den und-oder-Baum und die depth-first Suche festgelegt.

Für die Abarbeitung der Bedingungen und ihren Verknüpfungen stehen auf DB-Seite die Konstrukte der Anfragesprache zur Verfügung, wie z.B. die Operationen Selektion, Projektion, Verbund und Vereinigung. Bedingungen, die Vergleiche mit Konstanten beinhalten, und Variablenbelegungen werden in der Selektion ausgedrückt. Die Verknüpfungen werden durch join ( und) und Vereinigung ( oder)

realisiert. Die Gleichheit von Variablennamen wird bei den Verknüpfungsoperationen berücksichtigt.

Im nächsten Abschnitt soll untersucht werden, wie sich die DB-Kosten verhalten.

DB-Kosten

Vereinfachend wird angenommen, da8 die Kosten für jeden DB-Aufruf eine KEoa be- tragen.

Das Ziel, die DB-Kosten zu minimieren, wäre mit einem Schlag erreicht, wenn vorab alle irgendwann einmal potentiell relevanten Fakten mit einem DB-Aufruf in das ES geholt würden. In Anbetracht der Grö8e der DB-Relationen würde diese Vorgehensweise nicht nur die ES-Kosten in die Höhe treiben, sondern u.u. auch an Hauptspeichergrenzen sto8en.

Es liegt damit nahe, die DB-Aufrufe erst zur Laufzeit auszuführen.

Die DB-Kosten für die Herleitung eines Zieles p sind abhängig von der Anzahl der Stellen im und-oder-Baum, an denen DB-Aufrufe vorkommen, und von der Häufigkeit, mit denen diese DB-Aufrufe ausgeführt werden müssen.

Wenn möglichst gro8e (auch die mit oder verknüpften!) Teile des und-oder-Baumes

als ein DB-Aufruf zusammengefaßt werden, dann kann damit die Anzahl der Stellen, in denen Aufrufe vorkommen, verringert werden.

Beispiel 4: Berücksichtigung statischer Bedingungen im DBS.

LWbequem(Xmarke,Ypreis) Marke(Xmarke,bequem)

1

J,kel

Preis(Xm~eis) Km(Xmarke,Zkm)

~

Zkm>=lOO

Ein Verfahren, das die DB-Aufrufe bei den Blättern startet, braucht hier drei Aufrufe. Während ein Verfahren, das den gesamten Unterbaum von LWbequem in der DB ausführt, nur einen Aufruf benötigt. •

Die Häufigkeit, mit der DB-Ausdrücke ausgeführt werden müssen, hängt von dem Er- gebnis ab, das bei früheren Aufrufen geliefert wird. Hierzu ein Beispiel:

Beispiel 5: Berücksichtigung dynamischer Bedingungen in DB-Aufrufen.

LWbequem(Xmarke,Ypreis)

~,~~ -

Marke(Xmarke,bequem) P L , Y p r e i s ) I < m ( ~ k m > l

bequem

~ ~

Gogo unbequem BMW bequem

BMW 250 Ford 5

Ford 20 BMW 200

Angenommen im DBS werden jeweils die Blätter des Baumes von LWbequem( ••• ) ausgeführt. Dann wird zuerst eine Faktenmenge für Marke aus der DB geholt. Der Inferenzmechanismus sucht eine Marke, die in der 2. Komponente = "bequem" ist.

Anschließend wird überprüft, ob zu dieser Marke ein Preis existiert. Diese Uberprüfung wird, wie vorausgesetzt, vollständig in der DB durchgeführt. Das heißt aber, für jede Marke, die betrachtet wird, wird bei Preis ein neuer DB- Aufruf erzeugt. Hierzu gehören auch alle Marken, die zwar das Kriterium

"bequem" erfüllen, nicht aber die restlichen Bedingungen Km(Xmarke, Zkm) und Zkm

>= 100. Für diese Marken sind dann zusätzlich noch DB-Aufrufe für Km

erforderlich.

Hätte man z.B. für den Aufruf von Preis die Variablenbelegung von Xmarke nicht in der DB berücksichtigt, so wäre zwar ein weniger präziser Kontext für Preis eingefügt worden, dieser hätte aber den Vorteil gehabt, mehrfach nutzbar zu

sein, d.h., für mehrere Marken wäre nur ein DB-Aufruf für Preis durchgeführt worden.

Die dynamische Bedingung Xmarke = Ford schließt hier also aus, daß in dem Daten- bankaufruf der Preis für BMW gleich mitgeholt wi:rd, •

Das Beispiel zeigt, daß die Berücksichtigung dynamischer Bedingungen den ES- Aufwand zwar vermindert, den DB-Aufwand aber gleichzeitig auch erheblich in die Höhe treiben kann.

Bemerkung 3:

a) Je größer die zusammenhängenden Teile des und-oder-Baumes sind, die bei der Herleitung eines Zieles p vom DBS ausgeführt werden, desto geringer sind die DB-Kosten bei Herleitung von p.

b) Die Berücksichtigung dynamischer Bedingungen im DBS erhöhen die DB- Kosten. •

11

zu b) Die DB-Kosten bleiben nur dann gleich, wenn durch Zufall die richtige Alternative betrachtet wird, Die richtige Alternative im obigen Beispiel wäre Xmarke = BMW gewesen.

Strategien

Die Bemerkungen 2 und 3 beinhalten implizit Strategien für Kopplungsverfahren.

Eine Strategie, die die ES-Kosten möglichst gering hält, wird soviel wie möglich de:r statischen (bis auf die oder- Verknüpfung) und dynamischen Bedingungen im DBS ausführen ( "kein oder und dynamisch"). Eine Strategie, die die DB-Kosten möglichst gering hält, wird zwar soviel wie möglich statische aber keine dynamischen Bedingungen in die DB verlagern ( "oder und nicht dynamisch"). Das heißt, die beiden Strategien sind bzgl. der oder-Verknüpfungen und der dynamischen Bedingungen nicht miteinander verträglich.

Es ist offen, welche Strategie die Gesamtkosten einer Kopplung möglichst gering hält. Lösungen könnten Strategien bieten, die eine Mischung aus den beiden genannten darstellen: anstatt ES-Kosten oder DB-Kosten zu minimieren, wird versucht, beide Kostenarten gleichzeitig zu senken, um so zu einer Verminderung der Gesamtkosten zu kommen. Hierzu werden oder-Verknüpfungen und dynamische Bedingungen ("oder und dynamisch) in einer Strategie sowie keine oder- Verknüpfungen und keine dynamischen Bedingungen ( "kein oder und nicht dynamisch") in einer anderen Strategie vom DBS ausgeführt.

Um genauere Aussagen über die Wirksamkeit dieser Strategien treffen zu können,

werden an der Fernuniversität Hagen derzeit Kopplungsverfahren implementiert, die auf diesen Strategien basieren. Die Verfahren werden in Kapitel 5 kurz diskutiert.

Welche Einflußfaktoren neben ES- und DB-Kosten noch eine Rolle für die Höhe der Gesamtkosten spielen, wird im folgenden Kapitel behandelt.

4. Einflußfaktoren bzgl. der Gesamtkosten

12

Im letzten Kapitel wurden weitreichende vereinfachende Annahmen getroffen. Hier sollen kurz einige dieser Annahmen kritisch diskutiert und einige weitere Einflußfaktoren für das Problem aufgezeigt werden.

Speicherverwaltung

Wenn die Ergebnisse der DB-Anfragen zu groß werden, besteht die Gefahr, daß sie nicht mehr in den Hauptspeicher passen. In diesem Fall muß mit einem Puffer gearbeitet werden. Die Existenz eines Puffers verändert aber die Gesamtkosten:

Zum einen verursacht die Pufferverwaltung Aufwand, also zusätzliche Kosten; zum anderen ist es mit dem Puffer möglich, DBS und ES parallel arbeiten zu lassen (vgl. <Mattos>), so daß sich die Gesamtkosten hierdurch vermindern lassen. Damit wird die Pufferverwaltung ein wesentlicher Einflußfaktor für die Kopplungskosten.

Arbeitsweise des ES

ES können an allen Lösungen oder auch nur an der Existenz einer Lösung interessiert sein. Im ersten Fall muß für die Kostenoptimierung immer der maximale Suchaufwand auf ES-Seite berücksichtigt werden. Im letzten Fall kann sich der Suchaufwand aber erheblich verringern. Das heißt, die Art der ES- Arbeitsweise kann das gesuchte Optimum erheblich verschieben.

Erzeugen der DB-Aufrufe

Um DB-Aufrufe ausführen zu können, ist ein Mechanismus erforderlich, der aus der gegebenen Regelbasis DB-Aufrufe erzeugt. Erfordert die gewählte Strategie die Erzeugung des DB-Aufrufs zur Laufzeit des ES, so ist dies ein Kostenfaktor, der die Gesamtkosten der Kopplung erheblich belasten kann.

Kosten für DB-Aufruf

In den Modellannahmen wurde vorausgesetzt, da8 die DB-Kosten für einen DB-Aufruf

13 immer gleich sind und eine KEoa betragen. Dies ist eine sehr vereinfachte Annahme. Tatsächlich hängen die Kosten für einen Aufruf ( = Kosten für die Abarbeitung einer Query) in starkem Maße von der Komplexität der Query, also von der Struktur des Aufrufs, der Größe der zu bearbeitenden Relationen, der Ergebnisrelationen etc., ab.

Datentransformation ES - DBS

ES wurde vorausgesetzt, daß sich die Faktenmengen sehr einfach auf die Relationen abbilden lassen. Diese Annahme trifft aber nicht zu, wenn auf ES- Seite komplexe Strukturen zulässig sind. In solchen Fällen kann der Zugriff auf nur eine Faktenmenge schon für eine erhebliche Erhöhung der DB-Kosten sorgen.

Damit wird auch die Art der Abbildung von Faktenmengen auf Relationen ein Einflußfaktor für die Kopplung (s. <DaSm>).

Bestimmen der relevanten Faktenmengen

Es wurde vorausgesetzt, daß zur Herleitung eines Zieles p schon "im voraus"

(durch die Kenntnis des und-oder-Baumes) erkennbar ist, auf welche Fakten zugegriffen werden soll. Dies ist aber nicht für alle ES-Typen ohne weiteres möglich. Daher müssen andere Konzepte (z.B.: Möglichkeiten zur Kontextdefinition im ES) bereitgestellt und deren Kosten mitberücksichtigt werden.

5. Kopplungsverfahren

Die folgenden Verfahren basieren auf den oben genannten Strategien für eine feste Kopplung zwischen einem ES und einem DBS. Dabei bedeutet feste Kopplung, daß beide Systeme eigenständig bestehen bleiben, möglichst wenig geändert werden und über einen Kommunikationskanal miteinander kommunizieren, so daß das ES die externe DB als Erweiterung ihrer eigenen Faktenbasis betrachten kann. Die Kopplung ist wie folgt realisiert (vgl. <DeRV>, <Palm>):

Uber die Regelbasis des ES läuft ein Preprocessor und fügt an bestimmten Stellen einen - je nach Verfahren mehr oder weniger komplexen - DB-Aufruf ein. Bei Verfahren, die Variablenbelegungen berücksichtigen, wird dieser zur Laufzeit einer ES-Anwendung bzgl. der dynamischen Bedingungen noch modifiziert. Die DB- Aufrufe werden dann zur Laufzeit an die DB abgesetzt und dort ausgewertet. Die Ergebnismenge wird an das ES zurückgeschickt und in den Hauptspeicher eingelagert. Der DB-Aufruf wird aber nur dann abgesetzt, wenn die benötigten Fakten noch nicht im Hauptspeicher sind ( vgl. hierzu "subsumption" in <CeGW>).

Anhand des folgenden Beispiels kann die Vorgehensweise der Verfahren nachvollzogen werden:

Beispiel 6:

Der folgende und-oder-Baum gehört zu den in Beispiel 1 angebenen Regeln:

LWAktion(X1arke,Ypreis)

Aktion(X1arke,Ypreis)

1

1

Leihwagen(Xmarke,Ypreis)

Marke(Xmarke,beque~)

F7

LWbequem(Xmarke,Ypreis)

Preis(Xaarke,Ypreis)

~

BMW 250 Ford 5

Km(Xmarke,Zkm) Zkm>=lOO

rh6

Ford 20 BMW 200

•

14

Das erste Verfahren ist eine einfache und naheliegende Lösung, um einem ES den mengenorientierten Zugriff auf Fakten aus der DB zu ermöglichen. Es basiert nicht auf einer der angegebenen Strategien,

Vergleichsmöglichkeit:

bietet aber eine gute

Verfahren 1: Jedes Blatt des und-oder-Baumes, das einen Zugriff auf Fakten darstellt, wird durch einen DB-Aufruf ersetzt. Hierbei werden die Kenntnis von konstanten Werten und die dynamischen Bedingungen berücksichtigt.

Im obigen Beispiel wird mit diesem Verfahren an den Blättern Aktion, Marke, Preis, Km jeweils ein DB-Aufruf erzeugt (, denn es müssen sowohl LWaktion als auch LWbequem hergeleitet werden, weil es derzeit keinen günstigen Wagen in einer Sonderaktion gibt!). Der Kontext von LWbequem( ••• ) setzt sich aus den Faktenmengen von Marke( ••• ), Preis( ••• ) und Km( ••• ) zusammen. Weil Variablenbelegungen (XMarke = Ford oder XMarke = BMW) berücksichtigt werden, wird sowohl für den Preis von Ford als auch für den Preis von BMW ein DB-Aufruf gestartet.

Bedingungen über Werte von Fakten (konstante Werte und Variablenbelegungen, die an diesem Blatt schon bekannt sind, z.B. : "bequem" bei Marke oder "BMW" bei

15 Preis) werden vom DBS bei der Selektion ausgenutzt. Die Kenntnis der Variablen, die durch diesen Zugriff auf Fakten belegt werden sollen (z.B. Xmarke bei Marke) werden in der Projektion genutzt.

Durch den Einsatz von Selektion und Projektion werden somit nicht die gesamten Relationen, sondern nur ein eingeschränkter Teil geholt. Das Verfahren verkleinert dadurch zwar die geladenen Faktenmengen (gegenüber dem Laden einer gesamten Relation), diese können aber durch die Berücksichtigung von Verknüpfungen noch erheblich präzisiert werden (siehe unten).

Die Anzahl der DB-Aufrufe ist in zweifacher Hinsicht hoch. Zum einen muß im schlimmsten Fall an jedem Blatt des und-oder-Baumes ein DB-Aufruf gestartet werden. Zum anderen führt die Berücksichtigung einer konkreten Variablenbelegung dazu, daß bei jeder neuen Belegung erneute Aufrufe durchgeführt werden müssen.

Der Vorteil dieses Verfahren beruht auf der Tatsache, daß es leicht zu implementieren ist.

Mit dem Verfahren 1 steht offensichtlich ein funktionierender Mechanismus zur Verfügung. verbesserungswürdig sind sowohl die ES- als auch die DB-Kosten.

Das folgende Verfahren setzt den Schwerpunkt auf Verminderung der ES-Kosten (vgl. Bem.2, Kap.3).

Verfahren 2: "kein oder und dynamisch"

Jeder zusammenhängende nur aus und-oder-Baumes wird durch

und-Verknüpfungen bestehende Teil eines einen DB-Aufruf ersetzt. Dynamische Bedingungen werden berücksichtigt.

Im obigen Beispiel wird durch dieses Verfahren der gesamte Unterbaum von LWbequem( ••• ) vom DBS ausgeführt. Der geladene Kontext besteht dann aus dem Fakt LWbequem(BMW,250). Die dynamischen Bedingungen kommen in diesem Beispiel nicht zum Tragen, weil Leihwagen kein Teilziel einer übergeordneten Regel ist, durch die am Knoten Leihwagen schon irgendwelche Variablenbelegungen bekannt gewesen sein könnten.

Durch die Berücksichtigung von und-Verknüpfungen, können neben Variablenbelegungen und konstanten Werten auch die Gleichheit von Variablennamen und Vergleichsoperationen im DBS berücksichtigt werden. Hierbei können Vergleichsoperationen als eine einschränkende Selektionsbedingung interpretiert werden. Bei der Umsetzung der und-Verknüpfungen durch joins vom DBS gehen die Bedingungen über die Gleichheit von Variablennamen (z.B.: das Auftreten von Xmarke in Marke und Preis) ein.

Damit werden in diesem Verfahren mehr statische Bedingungen vom DBS ausgeführt als in Verfahren l, und die ES-Kosten für die Herleitung eines Zieles P sind geringer.

Die Anzahl der DB-Aufrufe ist ebenfalls geringer als in Verfahren 1, weil nicht mehr an jedem Blatt ein DB-Aufruf abgesetzt werden muß. Insbesondere werden die von den Variablenbelegungen abhängigen DB-Aufrufe stark reduziert (vgl.

geladenen Kontext im Beispiel von Verfahren 1).

Das Verfahren 3 setzt, anders als Verfahren 2, den Schwerpunkt auf Verminderung der DB-Kosten (vgl. Bern. 3, Kap. 3).

Verfahren 3: "oder und nicht dynamisch"

16

Jeder zusammenhängende Teil eines und-oder-Baumes wird durch einen DB- Aufruf ersetzt. Dynamische Bedingungen werden nicht berücksichtigt.

Im obigen Beispiel wird mit diesem Verfahren der gesamte Baum von Leihwagen durch einen Datenbankaufruf ersetzt. Als Ergebnis wird aus der DB nur das Fakt Leihwagen( BMW, 250) geholt, weil zu dem Zweig LWAktion kein Fakt in der DB existiert. In Beispiel 1 würde dieses Verfahren die Fakten Leihwagen(VW,l) und Leihwagen(BMW,250) holen.

Die oder-Verknüpfung wird vom DBS durch die Vereinigungsoperation dargestellt.

Da die Kenntnisse über die Variablenbelegungen hier keine Rolle spielen, können bei diesem Verfahren die DB-Aufrufe schon vor der Laufzeit des ES vollständig erzeugt werden.

Im allgemeinen werden die ES-Kosten für dieses Verfahren höher liegen als bei Verfahren 2, weil die aus der DB geladenen Kontexte durch die Berücksichtigung der oder-Verknüpfung und das Vernachlässigen der dynamischen Bedingungen nicht so präzise sind. Gegenüber Verfahren 1 können die ES-Kosten aus demselben Grund höher liegen. Sie könnten aber auch niedriger sein, weil mit Verfahren 3 mehr statische, insbesondere auch einschränkende, Bedingungen vom DBS ausgeführt werden. Genauere Aussagen können erst auf der Basis analytischer Studien und experimenteller Vergleiche getroffen werden.

Die DB-Kosten sind in der Regel niedriger als in Verfahren 1 oder 2.

Die folgenden Verfahren basieren auf den beiden, oben erwähnten, "Misch-"

Strategien, mit denen es u.u. möglich ist, die Gesamtkosten zu verringern:

Verfahren 4: "oder und dynamisch"

Jeder zusammenhängende Teil eines und-oder-Baumes wird durch einen DB- Auf ruf ersetzt. Dynamische Bedingungen werden berücksichtigt.

Im obigen Beispiel wird durch dieses Verfahren der gesamte und-oder-Baum für Leihwagen vom DBS ausgeführt. Die dynamischen Bedingungen kommen in diesem

17 Beispiel - wie im ersten Verfahren - nicht zum Tragen.

Da vom DBS auch oder-Verknüpfungen berücksichtigt werden, verringert sich die Anzahl der DB-Aufrufe gegenüber dem 2. Verfahren. Das Berücksichtigen von Alternativen (oder-Verknüpfungen) erhöht aber die ES-Kosten. Gegenüber Verfahren 3 werden , wegen der Berücksichtigung von Variablenbelegungen, die ES-Kosten niedriger und die DB-Kosten höher liegen. Auch hier gilt, daß genauere Aussagen weitere Untersuchungen voraussetzen. Eine genaue Aussage über die mögliche Einsparung oder die erwartete Erhöhung der jeweiligen Kosten kann erst nach der Implementierung getroffen werden.

Verfahren 5: "kein oder und nicht dynamisch"

Jeder zusammenhängende nur aus und-Verknüpfungen bestehende Teil eines und-oder-Baumes wird durch einen DB-Aufruf ersetzt. Dynamische Bedingungen werden nicht berücksichtigt.

Im obigen Beispiel wird mit diesem Verfahren der Teilbaum von LWbequem vom DBS ausgeführt.

Da die dynamischen Bedingungen hier nicht berücksichtigt werden, werden die ES- Kosten höher und die DB-Kosten niedriger als in Verfahren 2 liegen. Im Vergleich zu Verfahren 3 werden, wegen des Ausklammerns der oder-Verknüpfung, die ES- Kosten niedriger und die DB-Kosten höher liegen.

Durch weitergehende Untersuchungen ist im Vergleich mit Verfahren 4 zu klären, welchen Effekt die Berücksichtigung der oder-Verknüpfung und der Variablenbelegungen hat.

Wie bereits angedeutet, wird zur Zeit an einer quantitativen Bewertung der vorgestellten Verfahren gearbeitet. Dieses Ziel soll auf zwei unterschiedlichen Wegen erreicht werden. Zum einen wird ein Kostenmodell für die Verfahren erstellt, das eine quantitative Analyse ermöglichen soll. Hier gehen die ES- Kosten, Prozeßumschaltung, DB-Kosten und andere Einflußfaktoren als Parameter ein. Der zweite Ansatz zum Vergleich besteht darin, alle fünf Varianten zu implementieren und Leistungsmessungen mit verschiedenen Datenbanksystemen (z.B.:

Reflex, Ingres, Oracle) und Expertensystemen (z.B.: auf der Basis von IF/Prolog und Twaice) durchzuführen. Diese Arbeiten werden derzeit auf einer Targon/ 31 durchgeführt.

6. Zusammenfassung

Die Berücksichtigung von Perfonnanceaspekten bei der Kopplung von ES und DBS führt zu einem vielschichtigen Optimierungsproblem. Einige zentrale Aspekte wurden analysiert, einige grundsätzliche Verfahren wurden abgeleitet. Eine Reihe von Einflußfaktoren (z.B. Wissensrepräsentationsart, Arbeitsweise des ES) deuten darauf hin, daß es befriedigende allgemeingültige Lösungen (wie z.B. die Kopplung über die Implementierungssprache eines ES) nicht geben wird. Es wird daher notwendig sein, nach Lösungen für einzelne ES- und DBS-Typen zu suchen.

Literatur

<CeGW> Ceri, S.; Gottlob, G.; Wiederhold, G.:

18

"Interfacing Relational Databases and Prolog Efficiently", in: Proc, of the 1st International Conference an Expert Database Syste•s, ed. L. Kerschberg, Institute of South Carol ina, 1986, S. 141-153.

<DaS•> Dayal, U.; S1ith, J.M.:

"PROBE: A Knowledge-Oriented Database Manage•ent Syste•", in: <KBMS>.

<DeRV> Denoel, E.; Roelants, O.; Vauclair, M.:

"Query Translation for Coupling Prolog with a Relational Data Base Manage•ent Syste•", in:

Workshop on Integration of Logic Progra•• ing and Data Bases, Venedig, Dec. 1986.

<EXOA> Expert Database Syste•s, Vol. I, II. Proceedings of the First International Workshop on Expert Oatabase Syste•s, ed. Larry Kerschberg, Kiawah Island, South Carolina, Oct. 1984.

<FoMc> Fox, M.S.; McOer•ott,J.:

"The Role of Databases in Knowlegde-Based Syste•s", in: On Knowledge Base Manage11ent Syste•s, ed. Brodie, M.L.; Mylopoulos, J., Springer-Verlag, New York, 1986.

<JaVa> Jarke, M.; Vassiliou,Y.:

"Coupl ing Expert Syste•s With Datab.ase Manage•ent Syste•s", in: Artificial Intel 1 igence Applications for Business, Proc. of the NYU Sy•p,, ed. W. Reit•an, Norwood, N.J. 1984, pp.

65- 85.

<KBMS> On Knowledge Base Manage•ent Syste•s; ed. Brodie, M.L.; Mylopoulos, J., Springer-Verlag, New Vork, 1986.

<Kawa> Kowalski, R,:

Logic for Proble• Solvin9. New York, Oxford: North Holland Publ. Co., 1979.

<Matt> Mattos, M.:

"Konzepte zur Integration von Expertensyste•en und Datenbanksyste•en", Interner Bericht 162/86, Fachbereich Infor•atik, Universität Kaiserslautern, Juni 1986.

<MiWi> Missikoff, ^M.; Wiederhold, G.:

"Towards a Unified Approach for Expert and Database Syste•s", in <EXDA>, Oct. 1984.

<Pal•> Pal•stedt, A.

"Pi: a Prolog Front-End for the Relational Database Syste• INGRES" (in Ger•an), Fernuniversität Hagen, •aster thesis (in preparation)

<Pupp> Puppe, F.

"Expertensyste•e", in Infor•atik-Spektru•, Vol. 9, No. 1, Feb. 1986.

<SaWa> Sauers, R; Walsh, R.:

"On the Require•ents of Future Expert Syste

•

<S•it> S•ith, J.M.:

"Large-Scale Knowledge Syste•s", in: Wissensbasierte Syste•e, GI-Kongreß; ed. Brauer,W.;

Radig, B, München, Oct. 1985,

~Vass> Vassiliou,Y.:

"Knowledge-Based and Database Syste•s: Enhance•ents, Coupling or Integration?", in: On Knowledge Base Mana•ent Syste•s, ed. Brodie, M.L.; Mylopoulos, J., Springer-Verlag, New York, 1986.

{<~ied> Wiederhold, G.:

,._) · "Know 1 edge and Oatabase Manage•ent", in: IEEE Sof hare, Jan. 1984.