Nächste Seite: 2.2 Abgrenzung der Aufgabenstellung Vorige Seite: 2 Umfeld und Aufgabenstellung

Die deduktive Objektbank ConceptBase

 

ConceptBase ist ein deduktives Objektbanksystem, das 1987/88 am Lehrstuhl für dialogorientierte Systeme der Universität Passau unter der Leitung von Prof. Dr. Jarke entstand. Seit 1991 wird ConceptBase am Lehrstuhl für Informationssysteme der RWTH Aachen weiterentwickelt. ConceptBase ist eine Implementierung von O-Telos, einer Variante der Modellierungssprache Telos. Der größte Teil von ConceptBase ist in BIM-ProLog implementiert, der Kern zur Speicherung der Objekte wurde in der aktuellen Version 4.0 in C++ implementiert. Das Programm ist auf PCs und Sun-Workstations mit dem Betriebssystem Solaris lauffähig.

Das System ConceptBase hat eine Client/Server-Architektur (s. Abbildung 2.1), d.h. die deduktive Objektbank (Server) bietet den Kunden (Clients) über einen Kommunikationskanal verschiedene Dienste an. Das Programm CBinterface ist ein Teil der Benutzerschnittstelle für ConceptBase, mit dem die Dienste TELL zum Einfügen von Objekten in die Objektbank, UNTELL zum Löschen von Objekten und ASK für Anfragen an die Objektbank benutzt werden können. Außerdem lassen sich von diesem Programm andere Applikationen zur Darstellung der Objektbank starten, wie z.B. der GraphBrowser mit dem sich die Objekte der Datenbank graphisch anzeigen lassen. Weiterhin können beliebige Anwendungsprogramme die Dienste der Objektbank über eine Programmierschnittstelle (Application Program Interface, API) nutzen. Diese Programmierschnittstelle, die auch von den mitgelieferten Werkzeugen benutzt wird, verkapselt die Kommunikationsroutinen mit dem ConceptBase-Server in Funktionen der Programmiersprache C.

Die Kommunikation zwischen Client und Server findet immer nach dem gleichen Schema statt: der Client schickt eine Nachricht an den Server, worauf der Server die Nachricht verarbeitet und das Ergebnis wieder an den wartenden Client zurückschickt. Als Kommunikationskanal wird das Internet mit dem TCP/IP-Protokoll benutzt. Server und Client können also an verschiedenen Stellen im Internet existieren.

  
Abbildung 2.1: Client/Server-Architektur von ConceptBase

ConceptBase ist eine deduktive Objektbank. Im Gegensatz zu relationalen oder objekt-orientierten Datenbanken besteht der Inhalt der Datenbank nicht nur aus Daten, sondern auch aus einer Menge von logischen Regeln zur Herleitung von impliziten Daten und Integritätsbedingungen. Die Menge der gespeicherten Daten wird auch extensionale Datenbank (EDB) genannt, die Menge der Regeln bildet die intensionale Datenbank (IDB).

Der Benutzer definiert die Objekte der extensionalen Datenbank in der framebasierten Sprache O-Telos. O-Telos ist mehr eine Wissensrepräsentationssprache als eine Datendefinitionssprache und eignet sich daher auch zum konzeptuellen Entwurf. Mit O-Telos können die üblichen Objektbeziehungen Generalisierung, Spezialisierung, Klassifikation und Aggregation dargestellt werden. Die grundlegenden Regeln und Integritätsbedingungen, die diese Eigenschaften beschreiben, sind in den O-Telos Axiomen [Jeu92] definiert. Die Axiome definieren die unten beschriebenen Basisliterale und garantieren zum Beispiel die Typeigenschaften für Attribute von Objekten. Eine vollständige Liste der Telos-Axiome ist in Anhang A angegeben.

Mit der logischen Sprache MSFOL (mehrsortige logische Sprache erster Ordnung) definiert der Benutzer eigene Regeln und Integritätsbedingungen. Das System übersetzt diese logischen Formeln in Datalog-Regeln mit Negation. Beim Zugriff auf die Objekte der Objektbank werden sowohl die extensionale als auch die intensionale Datenbank ausgewertet. Eine Integritätsprüfung findet bei jeder Änderung des Datenbankzustandes statt.

  Die folgenden beiden Frames definieren eine Klasse Employee mit zwei Attributen boss und salary und eine Klasse Manager, die eine Spezialisierung der Klasse Employee ist. Die Integritätsbedingung (constraint) besagt, daßalle Manager mehr verdienen müssen als ihre Angestellten. Die Klasse Manager hat ein Attribut subord, dessen Wert durch die Regel subord_rule bestimmt wird und die Invertierung des Attributs boss darstellt.

Class Employee with 
  attribute
    boss : Manager;
    salary : Integer
  rule
    subord_rule: 
    $ forall m/Manager
      A(this,boss,m) ==> 
      A(m,subord,this) $
end

Class Manager isA Employee with
  attribute
    subord: Employee
  constraint
    c: $ forall e/Employee x,y/Integer
      A(e,boss,this) and A(this,salary,x)
      and A(e,salary,y) ==> (x > y) $
end

Die Instanzen der Klassen werden ebenfalls in Frame-Syntax definiert. Zu beachten ist, daßAttribute in ConceptBase generell mengenwertig sind, z.B. kann ein Angestellter mehrere Vorgesetzte haben.

 
John in Employee with
  boss
    boss1: Bill;
    boss2: Mary
  salary
    Johns_sal : 50000
end

 
Bill in Manager with
  salary
    Bills_sal : 70000
end
Mary in Manager with
salary 
    Marys_sal : 100000
end

Intern übersetzt ConceptBase die Beziehungen zwischen Objekten in eine Menge von sogenannten Propositionen der Form P(id,source,label,dest), d.h. es gibt eine Beziehung ausgehend von dem Objekt source zu dem Objekt dest mit der Bezeichnung label und dem Objektidentifikator id. In der logischen Sprache MSFOL kann man außer der Basisrelation P die folgenden Basisliterale verwenden:

A(source,label,dest):

Das Objekt source hat eine Attributbeziehung mit dem Attributwert dest die zur Attributkategorie label gehört. Im obigen Beispiel gilt u.a. A(Mary,salary,100000).

In(obj,class):

Das Objekt obj ist Instanz der Klasse class.

Isa(c1,c2):

Die Klasse c1 ist eine Spezialisierung der Klasse c2.

From(id,obj):

Von Objekt obj geht eine Beziehung mit dem Identifikator id aus.

To(id,obj):

Zu Objekt obj geht eine Beziehung mit dem Identifikator id ein. Es gilt also: .

Vergleichsliterale:

Zahlenobjekte können mit den Infix-Operatoren <, >, <= und >= miteinander verglichen werden. Mit dem Operator == kann man beliebige Objekte auf Gleichheit prüfen.

Die Literale A, In und Isa können vom Benutzer durch Regeln erweitert werden. Die Regel subord_rule in Beispiel 2.1 definiert das Literal A(man,subord,emp). Die Variablen innerhalb von Regeln und Integritätsbedingungen müssen über Klassen quantifiziert werden. Dadurch wird die Variable an die Instanzen der Klasse gebunden.

In ConceptBase sind nicht nur die Klassen und Instanzen als Objekte gespeichert, sondern auch die Verbindungen zwischen Objekten wie Attributbeziehung, Instanzierung und Spezialisierung. Daher können diese Objekte wieder selbst in Relation zu anderen Objekten stehen. So sind zum Beispiel die Attributbeziehungen von John zu seinen Managern Bill und Mary Instanzen der Attributrelation boss zwischen Employee und Manager. Man bezeichnet daher die Attributrelationen von Klassen auch als Attributklassen. In Abbildung 2.2 sind die Verbindungen zwischen den Objekten graphisch dargestellt. In der Abbildung stellt also jeder Kasten und jeder Pfeil ein Objekt in ConceptBase dar.

  
Abbildung 2.2: Graphische Darstellung eines Teils der Objektbank

Anfragen werden in ConceptBase als Instanz der System-Klasse QueryClass definiert. Für den Benutzer stellt eine Anfrage also eine besondere Klassendefinition dar, während die Anfrage im System in ein Datalog -Programm übersetzt wird. Das Datalog-Programm wird dann von ConceptBase mit den üblichen Methoden zur deduktiven Anfrageauswertung bearbeitet.

Im allgemeinen definiert der Benutzer eine Anfrageklasse als Spezialisierung einer existierenden Klasse. Dadurch wird die Antwortmenge auf die Instanzen dieser Klasse eingeschränkt. Attribute der Anfrageklasse können entweder berechnet werden (computed_attribute) oder von der Oberklasse abgeleitet werden (retrieved_- attribute). Bei generischen Anfragen werden die Parameter als Attribute der Anfrageklasse angegeben. Eine logische Formel (constraint) definiert zusätzliche Einschränkungen für die Antwortmenge und die Berechnungsvorschrift für Attribute. Die Elemente der Antwortmenge werden in für den Benutzer verständliche Frames transformiert.

Diese Anfrage gibt alle Manager, die mehr als 80.000 verdienen, mit ihren Angestellten und ihren Gehältern aus. Das Attribut subord wird von der Klasse Manager abgeleitet, das Attribut sal wird hier berechnet.

QueryClass High_Manager isA Manager with
  retrieved_attribute
    subord : Employee
  computed_attribute
    sal : Integer
  constraint
    c: $ A(this,salary,sal) and (sal > 80000) $
end

Aus der Struktur der Anfrageklasse und der Bedingung generiert der Anfrageübersetzer folgenden Datalog -Code:

High_Manager(_this,_subord,_sal) :-
    In(_this,Manager), In(_subord,Employee), In(_sal,Integer),
    A(_this,subord,_subord), 
    A(_this,salary,_sal), _sal > 80000.

Die Antwort für diese Anfrage mit den obigen Instanzen ist:

Mary in High_Manager with
  subord
    : John
  sal
    : 100000
end

Anfrageklassen können auch Spezialisierung von anderen Anfrageklassen sein. Die Anfrageklasse Generic_High_Manager ist eine Spezialisierung der Klasse High_Mana- ger und ist zusätzlich eine generische Anfrageklasse mit einem Parameter dept_par.

GenericQueryClass Generic_High_Manager isA High_Manager with
  parameter
    dept_par : Department
  constraint
    c: $ A(this,dept,dept_par) $
end

Mit dem Ausdruck Generic_High_Manager[Production/dept_par] werden die gutbezahlten Manager ermittelt, die in der Abteilung Production arbeiten. Eine Belegung des Parameters ist nicht unbedingt erforderlich.

Ein Mangel der Anfragesprache von ConceptBase ist, daßAnfragen nur zweistellige Beziehungen darstellen und nicht verschachtelt sein können. Im vorherigen Beispiel ist es nicht möglich auch das Gehalt der Angestellten zu erhalten. Dies ist aber mit den Sichten in ConceptBase möglich. Sichten sind für den Benutzer spezielle Anfrageklassen, die auch die Benutzung einiger Erweiterungen der Anfragesprache ermöglicht. Eine genaue Definition des Sichtenkonzepts von ConceptBase ist in Kapitel 5 beschrieben.