Vergleichende Untersuchung verschiedener deduktiv

Vergleichende Untersuchung
verschiedener deduktiv –
objektorientierter
Datenbanksprachen
Mohammad Reza Shahnas
Vorgelegt als Diplomarbeit bei
Prof. Dr. Rainer Manthey
Institut für Informatik, Abteilung III
Rheinische Friedrich-Wilhelms-Universität Bonn
April 2004
Meiner Mutter
und
meinem Vater,
der im letzten Jahr verstorben
ist
2
Danksagung
An dieser Stelle möchte ich einigen Menschen danken:
Mein ganz besonderer Dank gilt Prof. Dr. Rainer Manthey für die viele Zeit, die er der
Betreuung meiner Arbeit gewidmet hat und insbesondere für die vielen substanziellen Diskussionen. Diese Diplomarbeit während meiner beruflichen Tätigkeit durchzuführen, war mir nur aufgrund seines Verständnisses und seiner Flexibilität in der
Korrelierung der Besprechungstermine mit meinen Arbeitszeiten möglich.
Meiner Ehefrau Cana, für Ihre Geduld, ihre moralische Unterstützung, das Korrekturlesen und Ihr Verständnis für aufgeschobene Flitterwochen.
3
Versicherung
Hiermit erkläre ich, dass ich diese Diplomarbeit selbständig durchgeführt und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.
Bonn, den 29. April 2004
M. Reza Shahnas
4
INHALTSVERZEICHNIS
1 EINLEITUNG........................................................................................................... 2
2 DEDUKTIVE DATENBANKEN ............................................................................... 4
2.1 Sprachen für deduktive Datenbanken .................................................................................................... 10
2.1.1 Datalog.............................................................................................................................................. 10
2.1.2 Structured Query Language SQL....................................................................................................... 14
3 OBJEKTORIENTIERTE DATENBANKEN............................................................ 18
3.1 Sprachen für objektorientierte Datenbanken......................................................................................... 23
3.1.1 Object Query Language OQL............................................................................................................. 26
4 DEDUKTIVE OBJEKTORIENTIERTE DATENBANKEN DOOD ......................... 28
4.1 Rule-based Object Language ROL........................................................................................................ 30
4.2 ROL 2...................................................................................................................................................... 41
4.3 C-Logic.................................................................................................................................................... 48
4.3.1 Beschreibung und Berechnung komplexer Objekte............................................................................. 50
4.4 F-Logic .................................................................................................................................................... 51
4.5 Chimera................................................................................................................................................... 58
5 ANALYSE ............................................................................................................. 68
5.1 Vergleich deduktiver objektorientierter Datenbanksprachen ............................................................... 69
6. ERGEBNISSE ...................................................................................................... 80
6.1 Diskussion................................................................................................................................................ 81
6.2 Zusammenfassung und Bewertung......................................................................................................... 85
LITERATUR VERZEICHNIS .................................................................................... 87
1
1 Einleitung
Die Forschung an Datenbanksystemen hat besonders in den letzten zwei Jahrzehnten enorme Fortschritte geleistet, so dass Datenbanksysteme zu den wohl wichtigsten Entwicklungen auf dem Gebiet der Softwareentwicklung gerechnet werden [CBS,
02].
Dabei ist vor allem die Verbindung von Datenbanksystemen und Logikprogrammierung intensiv untersucht worden, mit dem Ziel traditionelle sowie neue Datenbankanwendungen besser zu kombinieren.
Dies führte zu Erweiterungen der herkömmlichen, relationalen Datenbanksysteme
um regelbasierte Sprachen zur Wissensrepräsentation – die sowohl als Modellierungs- als auch als Anfragesprache verwendet werden – und um Deduktionsmethoden zur Wissensverarbeitung [KG, 90/94].
Um auch Inferenzprozesse und rekursive Relationen in solchen Datenbanken zu ermöglichen , wurden deduktive Datenbanken entwickelt, [W, 99].
Deduktive Datenbanken verbinden die Vorteile einer deklarativen logischen Programmiersprache mit Datenbanktechniken zur Anfragebearbeitung und -optimierung
[F, 03].
Syntaktische und semantische Konzepte deduktiver Datenbanken werden heute in
modernen Datenbank-Anfragesprachen, in Workflow-Managementsystemen, in XMLAnfragesprachen, zur Wissensrepräsentation, im Constraint Reasoning und vielen
anderen Bereichen eingesetzt.
Damit stellen deduktive Datenbanken ein Bindeglied zwischen Logikprogrammierung
und Datenbanksystemen dar. Bezüglich der Logikprogrammierung ergeben sich Effizienzvorteile durch eine effiziente Datenbankverwaltung. Die Datenbankprogrammierung profitiert durch eine unkomplizierte Formulierung von Regeln, Anwendungen
und Datenbankanfragen, [CGH,93].
Nach der Entwicklung erster objektorientierter und deduktiver Datenmodelle als Erweiterung der relationalen Datenbanktheorie konnten in beiden Paradigmen orthogonale Merkmale bzw. Funktionalitäten aufgezeigt werden.
2
Durch Integration beider Modelle sind die ersten deduktiven objektorientierten Datenbankmodelle entstanden, und in der Folge wurden dazu zahlreiche Datenbanksprachen entwickelt, wie O-Logic [M, 86], C-Logic [CW, 89], IQL [AK, 89], F-Logic
[KLW,95], LLO [LO, 91], LOGRES [CCCtTZ,90],].
Mit der Integration von aktiven Datenbanktechnologien in diese Datenmodelle wurden schließlich neue deduktive, objektorientierte Datenbanksprachen generiert.
Beispiele für diese neue Sprachengruppe sind Rock &Roll [BFPW,95 und Chimera
[CM,94].
In meiner Diplomarbeit vergleiche ich die wichtigsten Gemeinsamkeiten und Unterschiede von deduktiven objektorientierten Datenbanksystemen anhand von ausgewählten Datenbanksprachen.
Dazu werden in Kapitel 2 die theoretischen Grundlagen deduktiver Datenbanken
vorgestellt, und die Architektur der wichtigsten implementierten deduktiven Datenbanksysteme behandelt.
In Kapitel 3 wird das objektorientierte Datenmodell dargelegt, sowie der zugrunde
gelegte Standard (Object Database Management Group, ODMG) erläutert.
Im zweiten Abschnitt dieses Kapitels wird die Anfragesprache „Object Query Language OQL“, die eine deklarative Anfragsprache für objektorientierte Datenbankmanagementsysteme (OODBMS) darstellt, behandelt.
Die Kombination des logischen Teils der deduktiven Methoden und der Modellierung
von objektorientierten Methoden bildet die Grundlage für die Erweiterung des relationalen Datenmodells um den objektorientierten – und den deduktiven Ansatz.
Dazu werden in Kapitel 4 ausgewählte Sprachen (ROL, ROL 2, C-Logic, F-Logic und
Chimera) beschrieben.
In Kapitel 5 werden die Gemeinsamkeiten und Unterschiede der vorgestellten Datenbanksprachen miteinander verglichen. Die Ergebnisse werden in Kapitel 6 abschließend diskutiert und bewertet.
3
2 Deduktive Datenbanken
Bei der Entwicklung deduktiver Datenbanksysteme wurden Ergebnisse aus der Forschung zur Künstlichen Intelligenz (KI) und Datenbank-Managementsystemen
(DBMS) zugrunde gelegt [Ull88]. Erste Anwendungen basierten auf Experimente, die
unter Kopplung von automatischen Beweissystemen mit Datenbanksystemen durchgeführt wurden [CBS, 02]. Ziel war es, effizientere Methoden zu entwickeln, die es
erlaubten, große Faktenmengen durch möglichst einfache und einzeln definierte
Ausdrücke darzustellen.
Mitte der achtziger Jahre verlagerte sich der Forschungsschwerpunkt auf die Entwicklung verschiedener Implementierungstechniken, insbesondere auf das relationale Datenmodell [CBS, 02]. Dabei wurden auch die regelbasierte Wissensdarstellung und die automatische Datenableitung im Rahmen anderer Datenmodelle, insbesondere innerhalb objektorientierter Systeme untersucht.
Deduktive Datenbanksysteme stellen eine Erweiterung des relationalen Datenmodells um eine sogenannte Deduktionskomponente dar. Die Deduktionskomponente
basiert auf dem Prädikatenkalkül, also der Logik erster Stufe. Deshalb können deduktive Datenbanken auch als eine relationale Datenmodellierung mit Logikprogrammierung betrachtet werden [KE, 96].
Deduktive Datenbanken bieten die Möglichkeit, aus explizit gespeicherten Fakten
neue Fakten abzuleiten. Der Zusammenhang zwischen den ableitbaren Fakten sowie den Basisfakten wird dabei durch Regeln ausgedrückt.
Regeln sind deklarative Ausdrücke und erlauben eine Darstellung ableitbarer Fakten.
Um auf ableitbare Fakten zugreifen zu können, muss das Datenbanksystem entsprechende Methoden zur Materialisierung bereitstellen.
Ein Datenbankmanagementsystem (DBMS) - für beliebige Datenmodelle - wird als
deduktiv bezeichnet, wenn es zusätzlich zu den üblichen Funktionalitäten eines
DBMS die Möglichkeit zur Spezifikation, Verwaltung und Herleitung ableitbarer Daten
bietet. [Skript]
Eine deduktive Datenbank enthält Fakten und Regeln, wobei die Menge der Fakten
als extensionale Datenbank (EDB) und die Menge der Regeln als intensionale Datenbank (IDB) bezeichnet wird. Zudem beruht die Auswertung von Abfragen auf logischer Deduktion.
4
Eine deduktive Datenbank kann mit relativ wenig Aufwand aus einer relationalen
Datenbank abgeleitet werden. Die Abfrageauswertung in deduktiven Datenbanksystemen erfolgt durch einen Mechanismus entsprechend der logischen Programmierung. Dieser Mechanismus basiert auf einer deklarativen Semantik und folgt damit der Anwendungstechnik relationaler Datenbanksysteme.
Formal lassen sich deduktive Datenbanken wie folgt definieren:
Sei ∑ = (S, Ω, Π) eine Signatur und X eine Variabelenmenge zu ∑.
•
•
•
Eine Datenbankklausel bezüglich ∑ und X ist eine Formel der Form: A ← W,
wobei A∈ A∑ (X) ein Atom und W ∈F∑ (X) eine Formel ist. Das Atom A stellt
den Kopf und W den Rumpf der Datenklausel dar [A. Cremers, 94].
Eine Datenbankabfrage bezüglich ∑ und X hat folgende Form: false ← W,
wobei W ∈ F ∑ (X) die Formel darstellt.
Eine deduktive Datenbank bezüglich ∑ und X ist eine endliche Menge von
Datenbankklauseln bezüglich ∑ und X.[CG,93]
Eine Regel ist eine Formel mit der Form: A ← W, wobei A ein Atom darstellt und als
Kopf der Regel bezeichnet wird; W ist eine Formel und stellt den Körper der Regel
dar.
Eine Regel dieser Form wird auch generalisierte Klausel genannt. Im Gegensatz zur
gängigen Theorie der logischen Programmierung ist der Körper einer generalisierten
Klausel nicht auf eine Konjunktion von Literalen eingeschränkt.
Eine generalisierte Klausel kann in eine oder mehrere normale Klausel transformiert
werden.
Ein Datenbankprädikat p wird durch eine Menge von Formeln definiert, die jeweils
die Form einer Implikation p(t1,…, tn) ← W besitzen. Die Formel W beschreibt die
Bedingungen unter denen das Literal (t1, ..., tn) erfüllt ist.[B,99]
Regeln in deduktiven Datenbanken dienen in erster Linie zur Datendefinition. Regeln,
wie Datenbankabfrage, sind deklarative Ausdrücke, das heißt, sie werden lediglich
zur Beschreibung der Zusammenhänge zwischen Datenmengen genutzt. Sie beschreiben nicht, wie diese einzusetzen sind.
In Datalog können beliebig viele Regeln zur Definition einer Relation kombiniert werden. Im Rumpf einer Regel darf ebenfalls eine regeldefinierte Relation angesprochen
werden, daraus folgt die hierarchische Abhängigkeit von Relationen untereinander
(Abstraktionshierarchie). Die regeldefinierten Relationen können von sich selbst abhängen, das bedeutet, dass die Regeln rekursiv sein dürfen. Voraussetzung ist, dass
die rekursiven Regeln mit mindestens einer nichtrekursiven Regel kombiniert werden.
Sei R eine Menge deduktiver Regeln, dann ist eine Schichtung λ auf R, eine eindeutige Abbildung von der Menge aller Prädikatensymbole RelD in die Menge der
natürlichen Zahlen, so dass für alle p, q ∈ RelD gilt:
5
p ∉ def(R)
p ∈ def(R)
p hängt von q ab
⇔ λ(p) = 0
⇔ λ(p) ≥ 1
⇔ λ(p) ≥ λ (q)
Darüber hinaus definiert λ eine vollständige und disjunkte Zerlegung von R in die
Teilmenge R1,..., Rm, so dass für jedes Prädikatensymbol p∈ def(R) alle Fakten und
Regeln, die p definieren, in Rλ(p) enthalten sind. Die Teilmengen R1, ..., Rm werden
als Schichtung von R bezeichnet. Eine Schichtung wird Stratifikation von RelD genannt, wenn zusätzlich folgende Bedingung gilt:[Behrend,99]
p hängt negativ von q ab ⇔ λ(p) > λ(q).
Eine wichtige Einschränkung in deduktiven Datenbanken ist, dass alle Variablen einer Klausel bereichbeschränkt sein müssen. Jede Variable im Regelkopf muss
auch in Regelrumpf vorkommen. Ein Variable gilt als bereichbeschränkt, wenn sie in
einem nicht negierten, benutzerdefinierten Prädikat im Körper einer Regel vorkommt.
Analog heißt eine Regel bereichbeschränkt, falls jede in der Regel vorkommende
Variable ebenfalls bereichbeschränkt ist. Da Fakten als Regeln ohne Körper aufgefasst werden können, ist eine Einschränkung auf bereichbeschränkte Regeln, eine
Verallgemeinerung der Bedingung, dass Fakten variablenfrei sein müssen. Das Kriterium der Bereichbeschränkung stellt sicher, dass ein benutzerdefiniertes Prädikat
eine endliche Anzahl von Lösungen besitzt.[Behrend,99]
Schließlich wird verlangt, dass eine deduktive Datenbank stratifiziert ist, (lat. Stratum: die Schicht). Das bedeutet informell, dass ein rekursiv definiertes Prädikat p in
seiner Definition nicht auf die Negation von p Bezug nehmen darf.
Eine deduktive Datenbank ist stratifizierbar, wenn mindestens eine Stratifikation existiert, andernfalls wird die Datenbank als nicht stratifizierbar bezeichnet.
Wenn keine negativen Abhängigkeiten existieren, ist die Regelmenge immer stratifizierbar. In diesem Fall wird die Datenbank als positive deduktive Datenbank bezeichnet.
Ein weiterer Spezialfall liegt vor, wenn nur negative Abhängigkeiten von extensionalen Prädikaten in einer gegebenen Regelmenge existieren. Auch in diesem Fall ist
die Regelmenge immer stratifizierbar: [Behrend,99]
Sei R eine Menge deduktiver Regeln und λ eine Schichtung auf R mit den Schichten
R1,..., Rm. Bezüglich λ sind folgende Regelklassen zu unterscheiden.
Die Klasse der hierarchischen Regeln R°, die sich nur auf Relationen tieferer
Schichten beziehen, also:
R°: = ∪ k = 1, ..., m R°k, wobei gilt
R°k: = {A ← W ∈ Rk  für alle Literale L in W gilt: λ (L) < k}
6
Die Klasse der nicht stratifizierbaren Regeln R*, die sich jeweils mindestens einmal
negativ auf Relationen der gleichen Schicht beziehen, also:
R*: = ∪ k=1, ..., m R*k, wobei gilt
R*k: = {A ← W∈ Rk ∃ ein negatives Literal L in W mit λ (L) =k}.
Hierbei wird eine deduktive Datenbank D = ⟨F, R⟩ als komplette Darstellung einer
relationalen Datenbank, dass heißt einer expliziten Faktenmenge F* betrachtet, die F
sowie alle durch die Regeln in R ableitbaren Fakten (und keine weiteren Fakten) enthält. Für eine genaue Charakterisierung der Faktenmenge F* wird im Folgenden die
Fixpunktsemantik für positive bzw. semi-positive, stratifizierbare und allgemeine deduktive Datenbanken vorgestellt. Dazu wird zunächst die Definition eines Ableitungsoperators T benötigt, in welcher genau spezifiziert wird, was mit der Anwendung einer Regel erzielt werden soll.[Behrend,99]
Sei R eine deduktive Regel der Form A ← W, wobei W j (1≤ j ≤ n) positive Literale Lj
und Ck (0≤ k ≤ m) negative Literale Ck enthält. Sei weiterhin F eine beliebige Menge
von Fakten, auf die die Regel angewendet wird.
T [Regeln] (Fakten) : = {Aσ | σ konsistente Substitution und
∀ 1≤ j ≤ n : Lj σ ∈ Fakten, 1≤ k ≤ m : Bk σ∉ Fakten}.
Aufgrund der Definition der deduktiven Regeln sowie der Beschränkung auf positive
Fakten ist eine direkte Bestimmung des Wahrheitswerts eines negativen Literals
nicht möglich. Für Datalog ¬ muss daher die Closed Word Assumption (CWA)
durchgeführt werden.
Es wird angenommen, dass die Negierung eines Faktes wahr ist, wenn es weder in F
enthalten ist, noch durch Auswertung der Regeln aus F abgeleitet werden
kann.[Behrend,99]
CWA ist also eine Annahme über vollständiges Wissen. Somit kann die Bedeutung
negativer Literale charakterisiert werden: Wenn für ein negatives Literal einer Regel
das entsprechende positive Fakt nicht in der Faktenmenge enthalten ist, kann aus
der CWA gefolgert werden, dass das negative Literal wahr ist.
Dieses Prinzip wird als Negation as failure (NFA) bezeichnet. Dabei ist die Folgerung
aus einer CWA für eine gegebene Regelmenge R nur korrekt, wenn andere Regeln
aus R das negative Fakt nicht durch Anwendung des T- Operators als positives Fakt
ableiten können.
Dieses Problem wird im Zusammenhang mit der Einführung einer kumulativen Form
des Ableitungsoperators genauer behandelt.
Das Resultat der Simulation ’Anwendung aller Regeln einer Regelmenge R’ ist gegeben durch:
TR (Fakten) : = ∪ Regel ∈ R T [Regel] (Fakten)
7
Dabei sind die Fakten, die durch die Anwendung von TR erzeugt wurden, während
der Ableitung für die einzelnen Regeln noch nicht sichtbar. Für die Regeln, die ausschließlich von Basisrelationen abhängen, erhält man bereits nach einmaliger Anwendung von TR auf die Basisfakten F den Anteil, welcher zusammen mit F die Faktenmenge F* ergibt.
Wenn R Regeln enthält, die selbst von regeldefinierten Relationen abhängen, sind
weitere Anwendungen des TR –Operators auf die Resultate vorhergehender Schritte
erforderlich, um die impliziten oder ableitbaren Fakten von D zu erhalten. Da der Operator aber nicht die Faktenmenge F, auf die er definiert ist, enthält, sondern nur die
Menge der aus Fakten ableitbaren Fakten beschreibt, ist eine kumulative Form von
TR erforderlich, um auch mehrstufige Ableitungen charakterisieren zu können.[B,99]
T*Rs (Fakten) : = TRs (Fakten) ∪ Fakten
Der T*R –Operator übernimmt bei wiederholter Anwendung alle früheren Ableitungen.
Wenn entsprechende positive Fakten zu spät abgeleitet werden, kann daher die
Auswertung von negativen Literalen zu unerwünschten Ableitungen führen.
Um die negativen Literale nicht zu früh auszuwerten, müssen demzufolge die Regeln
aus R von T*R in einer kontrollierten Reihenfolge abgeleitet werden. Wenn die Regelmenge stratifizierbar ist, kann dafür eine Stratifikation verwendet werden.
Mit T*R und dem Stratifikationskonzept ist es möglich, die Semantik von positiven
bzw. semi-positiven und stratifizierbaren Datenbanken zu charakterisieren.
Die Semantik deduktiver Datenbanken wird mittels der Definition von Fixpunkoperatoren eingeführt, die die Ableitbarkeit formalisieren.[Behrend,99]
Diese Fixpunktsemantik kann gleichzeitig als konstruktives Verfahren zur Materialisierung regeldefinierter Daten genutzt werden. Dabei werden iterativ solange regeldefinierte Fakten generiert, bis keine neuen Ableitungen mehr auftreten, und damit
ein Fixpunkt erreicht ist.
Ein solcher Fixpunkt - Iterationsprozess kann neben der Materialisierung auch als
Grundlage für andere Konzepte deduktiver Datenbanken verwendet werden, zum
Beispiel zur Abfragebearbeitung und Änderungspropagierung.
Definition 2.1:
Fixpunktsemantik für stratifizierbare deduktive Datenbanken
Sei D = ⟨F, R⟩ eine positive oder semi-positive, deduktive Datenbank, dann ist D der
kleinste Fixpunkt F* von T*R ( lfp (T*R, F) ) D = ⟨ F, R⟩, der F ganz enthält.
Sei D = ⟨F, R⟩ eine stratifizierbare, deduktive Datenbank und λ eine Stratifikation auf
R mit den Partitionen R1, ..., Rm., also
Fo : = F
Fi : = lfp( T*Ri, Fi-1 ) für 1≤ i ≤ m,
dann ist D definiert als F* : = Fm (iterierter Fixpunkt von D).
8
Die Existenz, die Endlichkeit und die Eindeutigkeit von F* = lfp (T*R, F) ist eine fundamentale Eigenschaft von deduktiven Datenbanken. Dabei liegt die Existenz und
Eindeutigkeit im Wesentlichen an der Monotonie des kumulativen Ableitungsoperators T*R (nach Traxi´s Fixpunkt 1955). Die Endlichkeit von F* beruht hauptsächlich
auf der Endlichkeit von F und R sowie der Einschränkung, dass die Regeln keine
Funktionssymbole enthalten.
Für nichtstratifizierbare Regelmengen wird eine andere Sichtweise auf deduktive
Datenbanken, basierend auf einer dreiwertigen Logik, benötigt.
Man unterscheidet dabei die Menge aller möglichen Fakten, die aus den Relationssymbolen RelD und den Konstanten in D konstruierbar sind (Herbrandbasis von D),
die Menge der positiven (ableitbaren) Fakten F*+ , die Menge der negativen Fakten
F*-, sowie die Menge der Fakten mit undefinierten Wahrheitswert F*?. Um die Bedeutung einer deduktiven Datenbank charakterisieren zu können, müssen mindestens zwei dieser Teilmengen explizit bestimmt werden. Hier wird die Bedeutung einer
deduktiven Datenbank als das Paar ⟨F*+, F*-⟩ betrachtet.
Das Problem nicht stratifizierbarer Regelmengen ist offenbar die korrekte Auswertung negativer Literale.[Behrend,99]
9
2.1 Sprachen für deduktive Datenbanken
2.1.1 Datalog
Der Begriff Datalog leitet sich aus dem englischen Wort Database für Datenbank und
dem Namen der Logikprogrammiersprache Prolog ab. Datalog stellt die Sprache dar,
in der die Regeln für deduktive Datenbanken formuliert werden. Sie entspricht in
vielerlei Hinsicht der vereinfachten Version der logischen Programmiersprache Prolog. Datalog als Datenbanksprache zur prototypischen Untersuchung von Grundphänomenen deduktiver Datenbanken ist eine Abfrage- und Regelsprache für das relationale Datenmodell, welche auf dem Bereichkalkül aufbaut. Grundbausteine jedes
Datalogausdrucks sind Literale.
Ein Literal besteht aus einem Relationsnamen und einer (anhängenden) Parameterliste. Sind in dieser Parameterliste Variablen angegeben, so stellt das Literal eine
Abfrage nach Parameterwerten zu passenden Datenbankfakten für diese Variable
dar. Falls in der Parameterliste eines Literals keine Variablen sondern nur Konstanten aufgeführt sind, dann repräsentiert ein solches Literal ein spezifisches Einzelfakt,
bzw. eine Abfrage nach genau diesem einen Einzelfakt.
Die Bildung konjunktiver Ausdrücke ist die einzige Möglichkeit, in Datalog Literale
miteinander in Beziehung zu setzen.
Konjunktion zweier Literale in Datalog:
Relationsname 1 (X1,…, Xn), Relationsname 2 (Y1, …, Yn),
wobei Xi und Yj sowohl Variablen als auch Konstanten sein können.
Ein weiteres wichtiges, syntaktisches Konzept in Datalog ist die sogenannte Regel.
Durch sie werden neue Datenbankfakten definiert. Dies geschieht, indem ein Datalogausdruck die Parameterwerte der neuen Fakten festlegt. In diesem Sinne sind auch
die Datalogregeln genau wie die Deduktionsregeln konstruktiv. Das Aussehen dieser
Regeln und die Benennung der Regelbestandteile entspricht ebenfalls den Deduktionsregeln:
p(…, Xi, …, Yj, …) ⇐ q( X1, …, Xn), r(Y1, …, Yn),
wobei wiederum gilt, dass Xi und Yj sowohl Variablen als auch Konstanten sein
können.
Die linke Seite des Implikationspfeils wird Regelkopf genannt und stellt ein Muster für
neue Fakten dar. Die rechte Seite heißt Regelrumpf und ist der Ausdruck, der die
neuen Fakten definiert. Die Definition einer neuen Relation durch mehrere Regeln ist
möglich. Dazu erhalten diese Regeln alle den gleichen Regelkopf. Eine Ausnahme
bilden umbenannte Variablen. Dies kann als eine Spezialform der Disjunktion oder
auch Vereinigungssemantik interpretiert werden.
10
Ein neues Fakt wird genau dann hergeleitet, wenn die Variablenbelegung des jeweiligen Regelrumpfs der ersten oder zweiten Regel oder einer der anderen Regeln mit
gleichem Regelkopf konsistent ist. Im Gegensatz zu solchen regeldefinierten Relationen spricht man bei Relationen, die vollständig in der Faktendatenbank realisiert
werden, von Basisrelationen.
Die Interpretation der Semantik einer Regel hängt dabei auch von der Art der Parameter des Regelkopfes ab. Sind im Regelkopf keine Parameter vorhanden, handelt
es sich um aussagenlogische Ausdrücke. Enthält die Parameterliste des Regelkopfs
nur Konstanten, so handelt es sich um Fakten.
Im Regelrumpf dürfen nicht nur Basisrelationen auftreten, sondern auch andere,
durch Regeln definierte Relationen. Daraus ergeben sich hierarchisch voneinander
abhängige Relationen, welche sich sehr anschaulich in einem Abhängigkeitsgraph
darstellen lassen. Durch diese erlaubte Verschachtelung von Relationen ergibt sich
die Möglichkeit, rekursive Regeln zu definieren. Allerdings muss für jede rekursive
Relation immer mindestens eine nichtrekursive Regel angegeben werden.
Ein Datalogprogramm ist genau dann rekursiv, falls der Abhängigkeitsgraph zyklisch
ist, also ein Zyklus vorhanden ist. [Kemper].
Für die Variablen in Datalogregeln gibt es weitere bestimmende Annahmen bzw.
Einschränkungen. So sind alle Variablen, die im Regelrumpf auftreten, implizit als ∃quantifiziert anzusehen, wobei alle ∃-Quantoren am Beginn des Regelrumpfs stehen.
Des Weiteren müssen bei Auswertung des Regelrumpfes alle im Regelkopf auftretenden Variablen durch solche Konstanten ersetzbar sein, die von abgespeicherten
oder durch andere Regeln generierten Fakten stammen.
In der ursprünglichen Form von Datalog gibt es keine Möglichkeit, negative Informationen direkt darzustellen, da dort keine negativen Literale definiert sind. Es gibt jedoch die Möglichkeit, mittels NAF (Negation as failure) und CWA (Closed World Assumption) Aussagen über nicht vorhandene Informationen zu machen. Diese fehlende Ausdrucksfähigkeit von Datalog wird durch Zulassung negativer Literale im Regelrumpf aufgehoben. Diese Sprache wird ’Datalog ¬’ (Datalog neg) genannt. Die Bedeutung der negativen Literale entspricht dem Negation as failure - Konzept. Solche
Fakten sind weder in den Basisfakten, noch in den durch Deduktion hergeleiteten
Fakten enthalten.
Die Auswertung negativer Literale hat jedoch nicht die Speicherung von negativen
Fakten in einer negativen Datenbank zur Folge. Negative Literale dienen ausschließlich zur Überprüfung, ob das betrachtete Literal wirklich nicht vorhanden ist. Dies
macht eine zusätzliche Anforderung an die Bereichsbeschränkung notwendig: Jede
Variable im Rumpf einer Regel in Datalog ¬ kommt in mindestens einem positiven
Literal vor.
Wie in Datalog ohne Negation, können auch in Datalog¬ die freien Variablen in den
negativen Literalen bei einer Auswertung eines Ausdrucks durch jede Konstante ersetzt werden.
Auf Grund der CWA gilt auch hierbei, dass alle Fakten, die nicht in der Basis- bzw. in
der aus herleitbaren Fakten bestehenden Faktenmenge enthalten sind, als falsch
gelten. Dies ist insofern problematisch, da die Möglichkeit besteht, alle in einem ne-
11
gativen Literal vorkommenden Variablen unendlich oft zu ersetzten. Daher ist beabsichtigt, die Bereichsbeschränkung von positiven Literalen innerhalb des Regelrumpfs nach vorne zu ziehen. Dadurch wird erreicht, dass alle Variablenbindungen
der negativen Literale aus mindestens einer Relation stammen. ’Nach vorne ziehen’
von positiven Literalen bedeutet, dass die Auswertung des negativen Literals so lange aufgeschoben wird, bis alle Variablen durch die Auswertung aller positiven Literale ersetzt worden sind. Erst danach erfolgt die Auswertung der negativen Grundliterale über das NAF.
Mit Hilfe von Integritätsbedingungen können gewisse Datenbankzustände oder
gewisse Folgen von Datenbankzuständen ausgeschlossen werden. Im ersten Fall
spricht man von statischen -, im zweiten Fall von dynamischen Integritätsbedingungen.
Eine Integritätsbedingung ist eine geschlossene Formel, deren Auswertung T (true,
also wahr) oder F (false, also falsch) ergibt. Eine Integritätsbedingung gilt bezüglich
eines Datenbankzustands als erfüllt, genau dann, wenn die Integritätsbedingung eine
logische Folge des Datenbankzustandes ist. Mit anderen Worten: Sie ist erfüllt, wenn
sie den Wahrheitswert T besitzt, anderenfalls ist die Integritätsbedingung verletzt.
Die Integritätsbedingungen können in Datalog und Datalog¬ vergleichbar ausgedrückt werden. Es wird ein parameterloses Prädikat eingeführt, dessen Erfülltheit
zwingend erforderlich ist. In Datalog können auf diese Weise Integritätsbedingungen
in negativer Form ausgedrückt werden, genau genommen werden zunächst Fehlerzustände durch Regeln definiert.
Es gibt jedoch auch Integritätsbedingungen, die sich nur mit Hilfe negativer Literale
innerhalb der Fehlerzustände ausdrücken lassen (folglich erst mit Datalog¬ ). Dies
gilt beispielsweise dann, wenn formuliert werden soll, dass Paare von Parametern
verschiedener Literale in Relation vorkommen müssen, in anderen Relationen hingegen aber nicht vorkommen dürfen.
Beispiel:
Fehler ⇐ p(X,Y), q(X,Y), ¬¬
Fakten werden als atomare Formeln dargestellt, deren Parameter ausschließlich aus
Konstanten bestehen. Man kann Fakten als degenerierte Regeln mit Rumpfliteral
gleich ’wahr’ ohne Variablen betrachten.
Beispiel:
P(a, b) ← wahr
Damit ist ein einheitliches Klauselformat für Fakten und Regeln möglich.
L ← L1, ..., Ln, wobei n ≥ 1 und Li ein Literal
12
Im Gegensatz zur Structured Query Language SQL, wo der Lösungsweg vorgegeben wird, ist die Abfragesprache von deduktiven Datenbanken abstrakt, und eine
Vielzahl von Operationsmöglichkeiten ist offen. Und auch die Wahl der Auswertungsstrategie ist möglich.
Es gibt zwei Grundprinzipen:
1.
2.
Bottom - Up Methode
Top - Down Methode
Bei der Bottom–Up Methode wird der Fixpunkt berechnet, während mit der Top –
Down Methode versucht wird, die Abfrage durch Auflösung auf abgespeicherte Fakten zu reduzieren.
13
2.1.2 Structured Query Language SQL
Das Datenbankmanagementsystem (DBMS) ist das technische Werkzeug (engl.
Tool), das Informationen, die in einer Datenbank gesammelt werden, speichert und
verwaltet. Die Structured Query Language (SQL) hingegen ist die Sprache, die es
ermöglicht, dem DBMS den Befehl zu erteilen, etwas mit den in der Datenbank vorhandenen Daten zu tun.
Die Structured Query Language wurde in den 70er Jahren in den Forschungslabors
von IBM entwickelt, um im ersten relationalen Datenbanksystem Daten verwalten zu
können. Mit SQL ist man in der Lage, Datenbanken und Tabellen einzurichten und zu
entfernen, Relationen zu definieren oder Daten in den Tabellen zu verwalten und
abzufragen.
SQL funktioniert wie eine Programmschnittstelle zwischen einen Datenbankanwender oder einer Anwendungssoftware, die auf eine Datenbank zugreift, und dem Datenbanksystem. SQL ist eine Skriptsprache, die gleichermaßen dem Datenbankadministrator, dem Datenbank-Entwickler und dem Datenbankbenutzer einen Zugriff
auf die Datenstruktur und die Daten in einer Datenbank ermöglicht. Die Komplexitätsstärke von SQL beruht allerdings nicht so sehr auf den Basisbefehlen (wie SELECT, DELETE, oder CREATE), sondern vielmehr auf den zahlreichen Anweisungsoperationen.[D,03]
Den Durchbruch als standardisierte Kommunikationsschnittstelle schaffte SQL zu
Beginn der 80er Jahre, als die ORACLE corp. unter dem Namen ’ORACLE’ eines der
ersten und zugleich populärsten, kommerziellen Datenbanksysteme auf den Markt
brachte. Seitdem gilt SQL als Standardsprache für Datenbanken, und wurde später
in andere Datenbanksysteme wie INFORMIX, SYBASE oder MY-SQL implementiert.
Es dauerte allerdings noch bis 1986, bis SQL durch die ANSI (American National
Standard Institute) als Standard normiert wurde.[D,03]
Der Standard von 1986 enthielt alle wesentlichen Anweisungen für die Definition
(DDL) und die Manipulation (DML) von Daten einer relationalen Datenbank.
1987 wurde SQL als ISO-Standard international von der ISO (International Standard
Organization) übernommen. Mit einer Reihe von Erweiterungen, wie Einführung von
Schlüsseln und Integritätsbedingungen, wurde 1989 SQL1 in der Version SQL89
zum verbindlichen, weltweiten Industriestandard erklärt. Erst der 92er Standard
SQL92 oder SQL2 nahm eine Reihe weiterer Spracherweiterungen auf. Dazu gehört
der Befehl ’ALTER’ zur nachträglichen Modifikation von Tabellenstrukturen, Domänen und Transaktionen.
Mit zunehmendem Einsatz objektorientierter Ansätze im Datenbankbereich entstand
Mitte der 90er Jahre verstärkt die Notwendigkeit, die Verwaltung von objektorientierten Daten in einem erweiterten SQL-Sprachkonzept zu verankern. Deshalb wurde
intensiv an einem neuen Standard SQL3 gearbeitet, der vor allem objektorientierte
Ansätze berücksichtigen sollte [CBS,02].
Eine SQL- Anweisung kann aus reservierten und benutzerdefinierten Befehlen zusammengesetzt werden.
14
Reservierte Wörter sind ein fester Bestandteil der SQL- Sprache und haben eine bestimmte, festgelegte Bedeutung. Benutzerdefinierte Befehle können vom Anwender
erstellt werden. Sie dienen als Bezeichnungen für verschiedene Datenbankobjekte.
Vereinfacht dargestellt, unterscheidet man in SQL drei grundlegende Operationen:
Insert:
Daten werden eingegeben.
Update:
Inhalte einzelner Datenfelder werden geändert.
Delete:
Daten werden gelöscht.
Eine SQL-Abfrage ist prinzipiell immer nach dem gleichen Schema aufgebaut:
Das erste Element ist stets eine SQL-Anweisung, wie ’Create’, ’Select’ und ’Drop’.
Es folgen Objekte, mit denen diese Anweisung ausgeführt werden soll, und Daten,
die für die Operationen benötigt werden. Zusätzlich gibt es auch spezifische Bedingungen, die durch Klauseln und Prädikate ergänzt werden.
So ist z.B. eine Select- Anweisung folgendermaßen strukturiert:
Select:
Um Daten abzufragen.
From :
Gibt an, welche Tabelle benutzt wird.
Where:
Filtert die Zeilen gemäß bestimmter Bedingungen.
Group by:
Um Zeilen mit jeweils gleichem Spaltenwert zu gruppieren
Having:
Ähnlich wie where, aber für Gruppen
Select:
Bestimmt, welche Spalte in der Ausgabe erscheinen soll.
Order by:
Die Reihenfolge der Ausgabe wird festgelegt.
Bei der Definition von SQL –Anweisungen sind darüber hinaus noch einige andere
wichtige Regeln zu beachten:
•
•
•
Eine SQL-Abfrage kann in einer oder mehreren Zeilen eingegeben werden.
Eine SQL-Abfrage kann aus mehreren Anweisungen bestehen.
Jede Anweisung wird mit einem Semikolon ’ ; ’ abgeschlossen.
Die Datenkontrolle in SQL wird durch die Verwaltung eines Datenbanksystems realisiert.
15
Dazu gehören die Zugriffberechtigungen für Datenbankbenutzer (Grant und Revoke),
das Anlegen (Create Database) und das Löschen (Drop Database) von Datenbanken, sowie die Nutzung der aktuellen Datenbank (Use Database).
Die Datendefinitionssprache DDL beinhaltet Anweisungen zur Definition (Create Tabelle), Manipulation (Alter Tabelle) und zum Löschen (Drop Tabelle) einer Tabellenstruktur.
Mit der Anweisung ’Explain’ kann die Datenstruktur einer Tabelle jederzeit betrachtet
werden. Durch diese Befehle kann das Datenmodell aufgebaut, und die Datenbank
für die Aufnahme von Daten vorbereitet werden. Nachdem eine Tabellenstruktur erstellt wurde, kann die Tabelle mit Daten gefüllt werden. Diese Aufgabe wird durch die
Anweisungen der Datenmanipulationssprache DML ausgeführt.
In SQL verfügbare DML-Anweisungen sind:
Select:
Fragt Daten einer Datenbank ab.
Insert:
Fügt Daten in eine Tabelle ein.
Update:
Aktualisiert die Daten in einer Tabelle.
Delete:
Entfernt Daten aus einer Tabelle.
Um in SQL Berechnungen oder Vergleichsoperationen auszuführen, werden Ausdrücke eingesetzt. Dazu werden Operatoren und Funktionen benötigt.
Die Rechenoperationen werden in der Regel auf die Daten in den Tabellenspalten
angewendet. So können z.B. mit Select Ergebnisse einer Datenbankabfrage mathematisch aufbereitet und dargestellt werden.
Des Weiteren sind für die Datenbankabfrage einfache oder mit Hilfe logischer Operatoren zusammengesetzte Vergleichsausdrücke wichtig. Da ein Datenmodell in der
Regel nicht nur aus einer einzigen Tabelle, sondern aus mehreren besteht, müssen
die Tabellen miteinander verknüpft werden können. Mit der Anweisung Create Database wird lediglich eine Tabellenstruktur definiert, jedoch keine Tabellenverknüpfung.
Die relationale Verknüpfung von Tabellen wird erst bei einer Datenbankabfrage mit
Hilfe der Anweisung Select definiert. Durch diese Anweisung erhält man die Informationen aus verschiedenen Tabellen.
Die einfachste Art, zwei oder mehrere Tabellen paarweise miteinander zu verknüpfen, besteht darin, eine Where - Klausel in die Select - Anweisung einzufügen, und
den Primärschlüssel der einen Tabelle mit dem Fremdschlüssel der anderen Tabelle
abzugleichen. [R,02]
Um eine benutzerspezifische Sicht auf den Datenbankinhalt zu ermöglichen, existiert
in SQL die Möglichkeit, neben den realen Tabellen (Basisdaten), sogenannte virtuelle Tabellen (engl. Views, Sichten) zu erstellen. Views sind Tabellen, deren Inhalt
durch Abfragen aus anderen Tabellen extrahiert wird.
Bei einer View handelt es sich um eine in einer Datenbank gespeicherte Abfrage, die
sich nach außen wie eine logische Tabelle verhält. Man kann die View wie eine Tabelle verwenden, obwohl sie keine eigenen Daten enthält, denn Views sind keine
16
physischen Tabellen. Die Zugriffsmöglichkeiten entsprechen weitgehend denen von
realen Tabellen.
Die Anlage einer solchen View erfolgt zumeist mit Hilfe des Befehls Create View,
dem der Name der anzulegenden View folgt. Anschließend können die von der View
bereitgestellten Spaltennamen in den Klammern ausgeführt werden. Zum Schluss
folgt eine normale Auswahlabfrage, mit deren Hilfe die aufgezählten Spalten selektiert werden.
Im Select - Teil sind bis auf die Komponente Order by alle Formulierungen des Select- Kommandos erlaubt.[R,03]
create view <viewname> as select <Abfrage>
17
3 Objektorientierte Datenbanken
In objektorientierten Datenbanksystemen werden die in Zusammenhang mit der relationalen Datenbankmodellierung existierenden Probleme vermieden. Dies geschieht
hauptsächlich durch Integration der Verhaltens - und Strukturbeschreibung in eine
einheitliche Objekttypdefinition.
Das anwendungsspezifische Verhaltensmuster, dass heißt die Operationen, ist ein
integraler Bestandteil der Objektdatenbank. So sollen die umständlichen und ineffizienten Transformationen zwischen der Datenbank und der Programmiersprache
vermieden werden. Operationen, die den Objekten zugeordnet werden, sind direkt
ausführbar, ohne detaillierte Kenntnis der strukturellen Repräsentation der Objekte.
Dies wird durch das sogenannte Geheimnisprinzip realisiert, wonach an der Schnittstelle des Objekttyps eine Menge von Operationen angeboten werden, für deren
Ausführung lediglich die Signatur (Aufrufstruktur) bekannt sein muss.
Oft wird in diesem Zusammenhang auch von einer Objektkapselung gesprochen, da
die interne Struktur eines Objekts, d.h. die strukturelle Repräsentation, dem Benutzer
verborgen bleibt. Der Benutzer bekommt nur die den Objekttypen zugeordneten Operationen zu sehen.[CBS,02]
Objekte sind Grundbausteine, aus denen objektorientierte Anwendungssysteme
aufgebaut werden. Jedes Objekt ist eine eigenständige Einheit, die über Daten (Attributwerte des Objekts) verfügt. Jedes Objekt wird durch seine datenspezifischen Eigenschaften (Attribute) und durch sein funktionsspezifisches Verhalten (Methoden)
charakterisiert. Ein Attribut oder Merkmal eines Objekts ordnet jeder Instanz einen
bestimmten Datenwert aus einem definierten Wertbereich zu. Neben dem Attribut
müssen die Methoden festgelegt werden, die sich aus dem Kontext des Problembereichs ergeben.[H,92]
Unter eine Methode versteht man eine klar definierte Dienstfunktion, durch die Werteingaben, Wertänderungen und Wertselektionen der Objekte geregelt werden. Objekte werden in einer objektorientierten Datenbank durch Methoden manipuliert. Eine
Methodendefinition besteht aus zwei Teile, Signatur und Implementation.
Folgende Objektbestandteile werden in der Objekttyp- Definition festgelegt:
18
•
•
•
•
Die Strukturbeschreibung der Instanzen, bestehend aus den Attributen und Beziehungen zu anderen Objekten.
Die Verhaltensbeschreibung der Instanzen, bestehend aus einer Menge von
Operationen.
Die Typeigenschaften, zum Beispiel Generalisierung und Spezialisierungsbeziehungen zu Typen.
Die Datenwerte eines Objekts: Diese können ausschließlich durch die Methoden verändert oder selektiert werden, dass heißt die Daten sind gekapselt.
Die Kapselung ist ein wichtiges Konzept in der objektorientierten Softwareentwicklung, und hat entscheidenden Einfluss auf die Integrität und Stabilität einer objektorientierten Datenbank.
Im relationalen Modell ist das Tupel die einzige Möglichkeit, die Entitäten darzustellen. Ein Tupel besteht aus einer festen Anzahl von atomaren Literalen.
Im objektorientierten Modell hat jedes Objekt eine systemweit eindeutige Objektidentität, die sich während seiner Lebenszeit nicht verändert. Der Objekttyp legt die
Struktur und das Verhalten des Objekts fest.[CBS,02]
Individuelle Objekte werden durch die sogenannte Instanziierung eines Objekttyps
erzeugt. Damit wird sichergestellt, dass ein Objekt die in dem Objekttyp festgelegte
Struktur besitzt und die dem Typ zugeordneten Operationen versteht.
Ein Objekt hat zu jedem Zeitpunkt seiner Lebenszeit einen bestimmten Zustand. Der
Zustand eines Objekts ist durch die Werte seiner beschreibenden Attribute sowie die
mit anderen Objekten bestehenden Beziehungen gegeben. Die eindeutige Zuordnung von Objekten wird mit Hilfe eines Objektidentifikators (Objektidentifier, OID)
realisiert. Anschaulich ist ein Objektidentifikator ein Zeiger auf ein Objekt.
Genau wie gleichartige Entitäten zu Entitätstypen zusammengefasst werden, werden
gleichartige Objekte durch einen gemeinsamen Objekttyp - oft auch Klasse genannt modelliert. Die einem Objekttyp zugehörigen Objekte werden als Instanzen dieses
Typs bezeichnet. Sie weisen eine gemeinsame Typdefinition auf, also eine einheitliche, strukturelle Repräsentation sowie ein einheitliches Verhaltenmuster. Die Menge
aller Objekte (Instanzen) eines Typs fasst man als Extension zusammen.
Eine Eigenschaft von Klassen betrifft die Klassenbezogenen Attribute und Methoden.
Ein Klassenattribut ist ein Attribut der Klasse, welches als Ausprägung einmal pro
Klasse vorkommt und nicht jedes Mal pro Instanz. Neben Klassenattributen können
Klassenmethoden definiert werden. Eine Klassenmethode ist unabhängig von der
Existenz von Objektausprägungen, und arbeitet auf Klassenattributen oder übernimmt spezifische Aufgaben der jeweiligen Klassen.[MW,00]
Die Ableitung von Klasseneigenschaften und Klassenverhalten stellt ein mächtiges
Modellierungskonzept des objektorientierten Ansatzes dar. Jede Beziehung zwischen zwei Objekten bzw. Klassen wird durch einfache - und mehrfache Assoziationen ausgedrückt.
Jede Assoziation charakterisiert also sowohl die Bedeutung (Semantik) wie die
Mächtigkeit der entsprechenden Beziehungsrichtung.
Eine einfache Assoziation von einer Klasse K1 nach einer Klasse K2 sagt aus, dass
zu jedem Objekt in K1 genau ein Objekt in K2 zugeordnet ist.
19
Eine konditionell einfache Assoziation von einer Klasse K1 zu einer Klasse K2 bedeutet, dass zu jedem Objekt der Klasse K1 höchstens ein (dass heißt kein oder ein)
Objekt aus K2 zugeordnet ist.
Eine mehrfache Assoziation von einer Klasse K1 zu einer Klasse K2 besagt, dass
jedem Objekt aus K1 mehrere Objekte aus K2 zugeordnet sind.
Eine Beziehungsklasse beschreibt eine Klasse, die von mehr als einer Klasse abhängig ist. Sie besitzt eigene Attribute, die die Eigenschaft der Beziehung näher umschreibt.
Zudem kann sie über Methoden zur Darstellung der Zugriffsfunktionen für die Objekte der Beziehungsklasse verfügen. Eine weitere wichtige Beziehungsstruktur bildet die Aggregation, die das Kombinieren von Teilobjekten zu zusammengesetzten
Objekten ermöglicht.
Aggregationsbeziehungen bauen auf speziell ausgezeichnete Assoziationen mit entsprechender Semantik und Mächtigkeit auf, um so eine Komponentenstruktur ausdrücken zu können. Eine Aggregationsklasse kann aus unterschiedlichen Komponentenklassen zusammengefügt sein.
Mit dem Begriff Generalisierung wird eine Verallgemeinerung von Klassen in einer
hierarchischen Beziehungsstruktur umschrieben. Dabei werden Klassen in Überklassen verallgemeinert. Umgekehrt werden Klassen in untergeordneten Unterklassen
verfeinert.
Als Spezialisierung wird die zur Verallgemeinerung inverse Sicht bezeichnet. Ausgehend von einer umfassenden Klasse definiert die Spezialisierung eine oder mehrere Unterklassen, die eine Überklasse verfeinern. Falls die Überklasse gemeinsame
Attribute oder Methoden der Unterklasse besitzt, besteht zwischen den Klassen eine
Generalisierungsbeziehung.
Generalisierung und Spezialisierung sind logische Beziehungen zwischen involvierten Klassen, die in objektorientierten Systemen mittels Vererbung direkt realisiert
werden. Die Generalisierung stellt demnach ein wichtiges Abstraktionskonzept für die
Analyse dar.[MW,00]
Sind Attribute und Methoden von Superklassen in einer Unterklasse, auch Subklasse
genannt, verfügbar, so spricht man von Vererbung.
Dieses Vererbungsprinzip gewährleistet die Wiederverwendbarkeit von Datenstrukturen (Attributen) und Verhaltenseigenschaften (Methoden). Ist der Weg von einer Unterklasse zu den Überklassen eindeutig, dass heißt stehen Klassen in einer hierarchischen Beziehung zueinander, so spricht man von einer einfachen Vererbung.
Falls zu einer bestimmten Unterklasse mehrere Überklassen existieren und das gewünschte Attribut nicht in der Subklasse auffindbar ist, so muss eventuell in mehreren Überklassen nach den gewünschten Informationen gesucht werden. In diesem
Fall liegt eine mehrfache Vererbung vor.[CBS02]
Die Überschreibung (Overriding) ist ebenfalls ein wichtiges Prinzip der objektorientierten Softwareentwicklung. Sie erlaubt es, Methoden mit gleicher Signatur in verschiedenen, abhängigen Klassen aufzurufen. Durch unterschiedliche Methodenimplementierung können so Subklassen mit spezifischen Eigenschaften generiert werden.
20
Die Festlegung von Vererbungshierarchien (einfache Vererbung) und Vererbungsnetzen (mehrfache Vererbung) bildet eine wesentliche Aufgabe beim Aufbau eines
Objektmodells. Neben der Modellierung von Datenstrukturen und Zugriffsfunktionen
einzelner Objekte oder Klassen muss zusätzlich der Meldungsverkehr zwischen den
Objekten geregelt werden.
Unter einer Meldung (Message) versteht man die Aufforderung eines Objekts an ein
anderes, eine bestimmte Methode auszuführen. Die Menge aller öffentlichen Meldungen, die einer Klasse zur Verfügung gestellt werden, wird als Protokoll bezeichnet.
Um persistente Objekte logisch adressieren zu können, dient die Vergabe von Datenbanknamen, die Einstiegspunkte in die Datenbank darstellen. Das Festlegen von
Datenbanknamen gehört ebenfalls zu einem Datenbankentwurf.
Nachfolgend sind die wesentlichen Schritte, die beim Entwurf einer objektorientierten
Datenbank beachtet werden müssen, aufgelistet:[MW,99]
•
•
•
Die Ergänzung beziehungsweise Vervollständigung von Klassen und Beziehungsklassen mit Attributen und Methoden.
Die Bestimmung von Assoziationstypen und Dokumentation der Bezeichnungen.
Auflösung von Generalisierung - und Aggregationsklassen und - bei Bedarf –
Bereicherung durch abstrakte Klassen. Eine abstrakte Klasse ist eine künstlich
eingeführte Klasse, die keine Instanzen enthält. Abstrakte Klassen bilden ein
wichtiges Modellierungsinstrument, da sich damit Objektmengen beliebig verallgemeinern lassen.
Bei objektorientierten Datenbanken spielt die Integritätsbedingung eine bedeutende
Rolle. Die folgenden Integritätsbedingungen müssen bei den Entwurfsarbeiten einbezogen werden:
•
•
Fortpflanzungseffekte bei Lösch-, Änderungs- und Einfügeoperationen.
Beim Einfügen, Ändern und Löschen eines Objekts aus einer Objektmenge
muss festgelegt werden, ob Seiteneffekte auftreten oder nicht.
Auch muss die Beziehung für eine gewünschte einfache - beziehungsweise komplexe Beziehung zwischen K1 und K2 definiert werden.
Da der Assoziationstyp von K1 zu K2 mehrfach ist, muss beim Einfügen eines Objekts
in die Objektmenge K1 mindestens ein weiteres Objekt in K2 zwingend erzeugt werden. Analoge Regeln bestehen beim Löschen von Objekten aus einer Objektmenge,
falls abhängige Objekte mitgelöscht werden müssen. Änderungsoperationen sind
insofern problematisch, wenn mit einer Operation auch Beziehungsabhängigkeiten
tangiert werden.
Bidirektionale Abhängigkeiten:
Ein Objekt aus einer Klasse K1 kann nicht existieren, ohne dass sein zugehöriges Objekt in Klasse K2 vorkommt und umgekehrt.
21
Erweiterte Kardialitätsbedingung bei Beziehungen:
Die Mächtigkeit der Beziehung muss immer erhalten bleiben, dabei ist zu berücksichtigen, dass Kardinalitäten konstant sein müssen.
Beliebige Prädikate als Konsistenzbedingungen:
Beliebige Konsistenzbdingungen, die sich nicht durch Beziehungen oder Kardialitäten ausdrücken lassen, können durch Prädikate formuliert werden.[MW,00]
Der objektorientierte Ansatz zeichnet sich dadurch aus, dass er grundsätzlich dieselben Konstruktionselemente für die Analyse wie für den Entwurf verwendet.
Die Modellierungseigenschaften eines objektorientierten Datenmodells sind:
•
•
•
•
•
•
Die Darstellbarkeit komplexer Objekte .
Objekte müssen mit einer eigenen Identität versehen werden.
Das Schema einer Datenbank besteht aus Klassen, deren Attribute jeweils von
einem bestimmten Typen sind.
Klassen können in einer Vererbungshierarchie angeordnet werden und sich
darüber hinaus gegenseitig referenzieren.
Es muss möglich sein, Struktur und Verhalten eines Objektes zu kapseln. Dabei
sollen die Struktur und das Verhalten auf alle Objekte innerhalb einer Klasse
ausführbar sein. Dazu sind Typen als abstrakten Datentyp beschreibbar.
Methodennamen können in der Vererbungshierarchie bzw. dem Klassenverband überladen werden; Durch Überschreiben werden entsprechende Implementierungen ihrem jeweiligen Kontext angepasst. Falls das betreffende Modell
vordefinierte Typen bereitstellt, und ein Benutzer zu diesen zusätzlich neue Typen hinzufügt, werden beide Kategorien gleichbehandelt.
Aus formaler Sicht besteht ein objektorientiertes Datenmodell aus einem strukturellen
sowie einem Verhaltensmäßigen Anteil.[MW,00]
22
3.1 Sprachen für objektorientierte Datenbanken
Der Standard der Object Database Management Group (ODMG Standard), ist ein
wichtiger Schritt zum Aufbau einer Architektur für Objektdatenbanken. Diese Architektur enthält ein Objektmodell und ein Typsystem, eine Menge von Imperativen
Sprachen sowie die Object Query Language (OQL, deklarative Abfragesprache).
Ein Standard ist die Zusammenfassung von Regeln, Abläufen und Modellen gemäß
einer Konvention, und dient der Qualitätssicherung, Interoperabilität und, Kompatibilität. Genügt ein Produkt einem Standard, ist mit einem Synonym eine Vielzahl von
Eigenschaften beschrieben. Standards sind für jede neue Technologie von wesentlicher Bedeutung, insbesondere auch für die objektorientierten Datenbanksysteme, da
sie unter anderem die Basis für die kommerzielle Nutzung und Verarbeitung darstellen.
Wenn objektorientierte Programmier- bzw. Datenbanksprachen ihre jeweils eigenen
Modelle und Sprachkonstrukte verwenden, und damit nicht oder nur partiell kompatibel zu anderen Sprachen sind, wird es schwierig bzw. unmöglich, ein bestimmtes
Objekt aus unterschiedlichen Sprachen aufrufen und verarbeiten zu können.[CBS,02]
Ziel der Object Management Group (OMG) - Entwicklung ist es, insbesondere die
Portabilität und Interoperabilität objektorientierter Software für verteilte Umgebungen zu ermöglichen. Portabilität beschreibt den Grad der Anpassungsfähigkeit eines
Programms an unterschiedliche Rechnerplattformen.
Je geringer die Anzahl der Programmiereingriffe bei einer Anpassung ist, umso höher ist die Portabilität der entsprechenden Software. Interoperabilität ist ein Maß,
Software für verteilte Systeme und deren Umgebung bereitstellen zu können. Um
unabhängig von Betriebssystemen, Datenbanksystemen und Programmierumgebungen Software entwickeln, betreiben und wieder verwenden zu können, müssen
Kommunikationsschnittstellen definiert werden. Dabei kann die Software nur als
Schnittstelle realisiert werden, die lediglich ein Protokoll und nicht dessen Implementierung vereinbart.
Interface Definition Language IDL ist eine Definitionssprache für Schnittstellen, mit
welcher sich ein Client (aufgerufenes Programm) und entsprechender Server
(Dienstprogramm) auf eine Menge von Methoden einigen, die der Client aufruft und
die der Server in beliebige Weise realisieren kann. Dieser Standard besteht aus einem Objektmodell und einer Objektdefinitionssprache. Diese ist mit der Datendefinitionssprache (Data Definition Language DDL) eines herkömmlichen Datenbanksystems gleichzusetzen. Das ODMG - Objektmodell bildet eine Obermenge des Objektmodells der Objekt Management Group (OGM). Mit diesem wird versucht, objektorientierte Standardfunktionen zur Unterstützung einer Reihe von erweiterten Leistungsmerkmalen zu definieren.
Ziel ist es, einen Standard für objektorientierte Datenbanksysteme zu definieren. Daher hat ODMG ein Objektmodell erstellt, das ein Standardmodell für die Semantik
von Datenbankobjekten spezifiziert. Dieses Modell ist essentiell, da damit die Se-
23
mantik festgelegt wird, die eine OODBMS (objektorientiertes Datenbankmanagementsystem) verstehen und einhalten kann.[CBS,02]
Das Design von Klassenbibliotheken und Anwendungen, die diese Semantik verwenden, sollte auf verschiedene objektorientierte Datenbanksysteme, die das Objektmodell unterstützen, portierbar sein.
Die wesentlichen Komponenten der ODMG- Architektur für ein objektorientiertes
Datenbankmanagementsystem (OODBMS) sind:
•
•
•
•
Objektmodell OM
Objektdefinitionssprache ODL
Objektabfragesprache OQL
Anbindung an eine Programmiersprache
Analyse- und Entwurfmethoden sind für die Gestaltung von Informationssystemen
unumgänglich. Die Analyse bezweckt eine nachvollziehbare und widerspruchsfreie
Beschreibung des Problembereichs. Gleiches gilt für den Entwurf bezüglich des informationstechnischen Lösungsbereichs. Objektorientierte Analyse -und Entwurfmethoden verfolgen einen ganzheitlichen Ansatz, bei welchem Objektstruktur und Objektverhalten modelliert und beschrieben werden.
Die einheitliche Darstellung von Struktur und Verhalten in einem Objektmodell ist für
den objektorientierten Ansatz typisch und vorteilhaft im Gebrauch. Wesentliche
Komponenten des Objektmodells sind das Strukturmodell mit der Definition der Klassen und Beziehungsstrukturen, sowie das Verhaltensmodell mit Integritätsbedingungen und Zustandübergangsdiagrammen.[CBS,99]
Das Objektmodell der ODMG ist eine Obermenge des OMG - Objektmodells, das die
Portierung des Entwurfs und der Implementierung zwischen konformen Systemen
ermöglicht.
Die Objektdefinitionssprache ODL ist rein deklarativ und übernimmt die Rolle einer
objektorientierten Datendefinitionssprache. Eine konkrete Repräsentation eines in
ODL definierten Objektmodells wird durch die jeweilige Sprachanbindung realisiert.
ODL unterstützt sowohl Schnittstellen als auch Klassendefinitionen (in Anlehnung an
Java). Klassen sind Typen, die direkt instanziierbar sind, im Gegensatz zu Schnittstellen, die abstrakten Vereinbarungen entsprechen.
Die Mehrfachvererbung von Zuständen hat sich als problematisch erwiesen, deshalb
wird bei Klassen nur eine einfache Vererbung zugelassen. Dabei können die Klassen
von mehreren Schnittstellen abgeleitet werden.
Ein Objekttyp wird durch eine Menge von Attributen, eine Menge von Beziehungen
zu anderen Objekttypen sowie eine Menge von Methoden beschrieben. Mit der Objektdefinitionssprache werden Spezifikationen von Objekttypen in ODMG Systemen
definiert. Wesentliches Ziel dieser Sprache ist es, die Portierbarkeit von Schemata
zwischen konformen Systemen zu erleichtern, und dadurch unter anderem auch die
Zusammenarbeit von objektorientierten Datenbanksystemen untereinander zu ermöglichen.
24
ODL kann mit der Datendefinitionssprache DDL herkömmlicher Datenbanksysteme
verglichen werden. Sie gibt Attribute und Bezeichnungen für Typen an und legt die
Kennung von Operationen fest.
25
3.1.1 Object Query Language OQL
Die Abfragesprache Object Query Language (OQL) ist eine deklarative Abfragesprache der OODBMS. Sie ist an SQL angelegt und bildet die Grundlage für den ODMG
Standard. Jeder atomare oder komplexe Wert, und jedes benannte Objekt kann in
OQL abgefragt werden. Eine deklarative Datenbankabfragesprache bietet die Möglichkeit des Datenzugriffs ohne aufwendige Programmierung. Hier kann festgelegt
werden, welche Objekte mit welchen Eigenschaften beschaffen werden. Der Benutzer definiert auf deskriptive Weise das “Was“ und überlässt dem Datenbanksystem
das “Wie“, dass heißt, die Art der Datensuche und Datenbeschreibung. OQL erfüllt
die Kriterien einer deskriptiven Abfragesprache und unterstützt das Objektmodell. Die
Grundstruktur einer Abfrage mit OQL ist dreiteilig:
•
•
•
Select → Wie soll die Resultatmenge (Objekte oder Werte) aussehen?
From → Welche Objektmenge soll inspiziert werden?
Where → Welche Eigenschaften müssen die Objekte erfüllen?[MW,00]
Das Resultat einer Abfrage in OQL ist stets ein Wert, ein Objekt beziehungsweise
eine Sammlung von Werten oder Objekten. Folglich ist die Sprache nicht objekterhaltend, da die Resultatmenge nicht zwingend Objekte, sondern auch Werte enthalten kann.
Eine weitere Einschränkung bezüglich objektorientierter Konzepte ist die Verletzung
der Kapselungseigenschaft. Kapselung verbirgt für den Anwender die Implementationsdetails des Objekts, und definiert eine Menge von Methoden als Zugriffsschnittstelle.
Datenbanknamen repräsentieren eine Menge von Objekten bzw. Werten. Diese werden in OQL normalerweise als Basisobjektmengen für Abfragen benötigt. Zudem
können zur einfacheren Handhabung häufig gestellter Auswertungen bereits benannte Abfragen (named Query) verwendet werden.
Die benannten Abfragen vergeben dem Resultat einer Abfrage einen eindeutigen
Namen und erlauben, auf dem dynamisch stets von neuem erzeugten Resultat weitere Auswertungen vornehmen zu können. Durch Aggregation wird die Kombination
von Teilobjekten zu zusammengesetzten Objekten ermöglicht. Eine Aggregationsklasse kann aus unterschiedlichen Komponentenklassen zusammengefügt sein.
OQL bietet eine Reihe von Aggregationsfunktionen wie Count für Zählung, Min für
Minimum, Max für Maximum, Avg für den Durchschnitt und Sum für die Summe an.
Numerische Operatoren auf den Basistypen sowie auf werterzeugenden Abfragen
sind erlaubt. Zudem sind die üblichen Vergleichsoperatoren wie die Bool`schen Operatoren (and, or, not) in OQL definiert.[CBS,02]
Modifikationen auf bestehenden Objekt- oder Wertmengen müssen in OQL immer
über die vorgegebenen Methoden ausgeführt werden. Damit erfolgt eine geschützte
Datenbankänderung unter Wahrung der in den Methoden implementierten Integritätsbedingungen.
OQL unterstützt des Weiteren den navigierenden Zugriff auf eine objektorientierte
Datenbank.
26
Dies erfolgt durch so genannte Pfadausdrücke: Ausdrücke, die entlang den im Datenbankschema festgehaltenen Beziehungen verlaufen. Bei objektorientierten Datenbanken können über die Beziehungsattribute Objekte unterschiedlicher Klassen
erreicht werden, sofern solche Beziehungsstrukturen im Objektmodell festgehalten
sind. Darüber hinaus können auch neue Objekt- oder Wertmengen beliebig konstruiert werden, ohne einzelnen Beziehungsstrukturen zu folgen.
Die Sprache OQL ist mittels algebraischer Umformungen optimierbar. Anhand von
Statistiken und eventuell vorhandener Indizes können Ausführungsstrategien berechnet werden. Die optimale Strategie bezüglich des Leistungsverhaltens wird dann
ausgewählt und ausgeführt. Problematisch beim geschätzten Laufzeitverhalten ist
lediglich der Aufruf der Methoden, da nicht alle Auswirkungen und Seiteneffekte im
Voraus berechnet oder abgeschätzt werden können.[MW,00]
Die Objektabfragesprache stellt einen deklarativen Zugriff auf Objektdatenbanken zur
Verfügung. Sie bietet keine ausdrücklichen Operatoren für die Aktualisierung an,
sondern überlässt diese Aufgabe den zu den Objekttypen definierten Operationen.
Die Struktur eines objektorientierten Datenmodells enthält folgende charakteristischen Eigenschaften:
•
•
•
Es erlaubt die Definition der Aggregationshierarchie.
Es erlaubt die Definition von Generalisierungshierarchien.
Es unterstützt die einzige Identifikation von Objekten, das heißt, dass jedes
Objekt nur einen einzigen Identifikator besitzt.
Das Verhalten eines objektorientierten Datenmodells ist durch eine Operation definiert und registriert, die das Verhalten von Objekten in dieser Klasse beschreibt.
Eine Abfrage (Query) in OQL gibt eine Subdatenbank an, die eine mit der Originaldatenbank ähnliche Struktur besitzt. Das bedeutet, das Resultat einer Abfrage kann
auf eine andere Abfrage übertragen werden.
Eine Subdatenbank gibt durch die Repräsentation einer Abfrage einen Kontext an,
durch den die Operationen durchgeführt werden können.
Die Spezifikation eines Kontexts in einer OQL- Abfrage ist von der Spezifikation der
Operationen in dieser Subdatenbank getrennt. Das ermöglicht unterschiedliche Operationen aus unterschiedlichen Objektklassen durchzuführen. Die Menge der Operationen kann über eine vereinigungskompatible (union-compatible) Subdatenbank
durchgeführt werden. Das Ergebnis dieser Operationsmenge ist eine neue Subdatenbank, die auf herkömmliche Weise manipuliert werden kann.[ASL,89]
27
4 Deduktive objektorientierte Datenbanken DOOD
Die deduktive objektorientierte Datenbank DOOD ist eine Kombination der logischen
Eigenschaften von deduktiven Methoden mit der Modellierung von objektorientierten
Methoden.
Es gibt eine Reihe von DOOD Sprachen, wie O- Logic [Maier-1986], C-Logic [Ch,89],
IQL [AK,98], LLO [Lou und Ozs, 1991], Rock and Roll [Barja 95], F-Logic, ROL [Liu1991], ROL 2 [LG,98],Chimera [CM,94 ].
Bei diesen ist die Kapselung regelbasierter Methoden in Klassen unzulässig. Das
heißt, wenn Regeln in Klassen gekapselt werden, ist die Semantik nicht mehr eindeutig. Es gibt jedoch Entwicklungen, wie Datalog++ und Datalogmath , die die Kapselung mit einer rewriting-based semantic ermöglichen.
Diese Sprachen können grob in zwei Arten klassifiziert werden:
•
•
Lossely- coupled (leicht gekoppelt) und
Tightly coupled (fest gekoppelt)
Bei der ersten Vorgehensweise werden vornehmlich Datalog ähnliche Sprachen als
Abfragesprache für objektorientierte Datenbanken eingesetzt. Da die resultierende
Sprache aus zwei unterschiedlichen Teilen mit nicht vereinheitlichter Semantik besteht, stellt dies jedoch nur eine unbefriedigende Methode dar. Typische Beispiele
sind IQL und Rock and Roll.
Die zweite Vorgehensweise ist eine elementare Methode, in der eine neue, einheitliche Logik vorgeschlagen wird, um die zugrundliegende objektorientierte Datenbanknotation zu formulieren. C-Logic, F- Logic und ROL gehören zur zweiten Methode.
Die Methoden in objektorientierten Programmiersprachen und Datenmodellen sind in
der Klassendefinition enthalten, und werden durch Funktionen und Prozeduren definiert. Sie können durch Instanzen abgerufen werden.
In deduktiven Datenbanken werden Regeln anstelle von Funktionen und Prozeduren
eingesetzt. Mit Regeln und durch Schachtelung in der Klassendefinition können mit
derselben Vorgehensweise die Methoden in deduktiven objektorientierten Datenbanken festgelegt werden.
28
Einige Methoden lassen sich durch Klasseninstanzen abrufen. Die Mehrheit der deduktiven objektorientierten Datenbanksprachen, wie F-Logic, IQL oder ROL erlaubt
jedoch keine regelbasierte Methode zur Schachtelung in der Klassendefinition, dass
heißt die Schachtelung wird nicht unterstützt. Sofern Regeln in Klassen gekapselt
sind, bleibt die Definition der Semantik unklar. Daher benutzen viele Sprachen, wie
Datalog math und Datalog ++ eine umgeschriebene Semantik, die nicht direkt an die
Quelle adressiert ist.
Bei Sprachen wie O2 und Orion kann der Benutzer vererbte Attribute oder Methoden
aus der Superklasse umdefinieren oder auch blockieren.
Schwieriger wird es, wenn Attribute oder Methoden in mehreren Superklassen definiert sind.
Derzeit gibt es noch keine logische Semantik für eine mehrfache Vererbung mit den
Funktionen Überschreiben beziehungsweise Blockieren, und es existiert dahingehend auch noch kein erfolgsversprechender Ansatz. Sprachen wie O-Logic, F-Logic
und Chimera erlauben nur eine einheitliche, mehrfache Vererbung. Darüber hinaus
existieren Sprachen wie Datalog math, die eine Überschreibung nur bei einer mehrfachen Vererbung unterstützen.
ROL wiederum hat eine Semantik, die eine nicht-einheitliche Vererbung mit Überschreiben unterstützt, jedoch wird auch hier das Blockieren nicht ermöglicht [Liu,02].
Die deduktiven und objektorientierten Datenbanken bilden zwei wichtige Erweiterungen im Bereich der traditionellen Datenbanktechnologie. Die deduktive Datenbank
ergänzt die Aussagekraft der herkömmlichen Datenbank mit Hilfe der Rekursion und
der deklarativen Abfrage. Objektorientierte Datenbanken erweitern die Datenmodellierung durch die Objektidentität, Klassen, Klassenhierarchie und Schema. Die deduktiven Datenbanken benötigen einen Datenmodellierungsmechanismus, während
für objektorientierte Datenbanken eine deklarative Querysprache erforderlich ist.
29
4.1 Rule-based Object Language ROL
Die Rule-based Object Language (ROL) wurde in der University of Regina von
Mengchi Lui entwickelt.
ROL ist eine regelbasierte, deklarative Sprache für Definitionen und Manipulationen
von Datenbanken und Datenbankabfragen. Sie hat wesentliche Merkmale von deduktiven und objektorientierten Datenbanken, und unterstützt die Objektidentität, die
Objektkomplexität, die Klassenhierarchie sowie die mehrfache Vererbung mit den
Funktionen Überschreiben und Blockieren.
Darüber hinaus unterstützt ROL strukturierte Werte als Functor Objekt (Objekte, die
sich wie Funktionen verhalten und wie Objekte gehandhabt werden) und Menge und
liefert einen Mechanismus für die Repräsentation von Teil- bzw. vollständigen Mengeninformationen.
Dabei werden die wesentlichsten Merkmale, wie Domain, Schlüssel, Funktionalenabhängigkeit und Kardinalität in einer einheitlichen Form unterstützt.
ROL stellt eine regelbasierte Objektsprache dar, welche als Regelsprache bestimmte
Merkmale von objekt – und wertorientierten Methoden integriert. Anstelle des Objektidentifikators können strukturierte Werte für Objekte benutzt werden, falls sich die
Benutzung eines Objektidentifikators als nicht erforderlich bzw. kompliziert darstellt.
ROL kann einerseits wie eine objektorientierte Datenbankprogrammiersprache und
andererseits wie eine wertorientierte deduktive Datenbankprogrammiersprache benutzt werden. Dabei ist wichtig, dass ROL die gleichzeitige Nutzung wertorientierterund objektorientierter Merkmale zulässt. Sie stellt die Menge der Repräsentationsmechanismen, welche die Sprachen LDL- und F-Logic kombiniert.
Zur Beschreibung der Syntax von ROL wird folgendes angenommen.
B={integer, real, string} ist eine Menge von value Klassen.
C ist eine Menge von Objektklassen, die Funktionssymbolen mit n≥0 enthalten.
A ist eine unendliche Menge von Attributen.
D ist eine unendliche Menge von Werten (Values), vereinigt mit der Menge I
(integer) und der Menge R (real) sowie der Menge S (string).
In ROL wird eine Menge von Objekten, die gemeinsame Attribute teilen, als eine
Klasse bezeichnet. Ein Objekt einer Menge, die als Klasse bezeichnet wird, ist eine
Instanz diese Klasse. ROL ist eine Sprache, die auf Objekten und deren Attributen
aufgebaut ist.
Es gibt vier Objektarten in ROL:
•
•
•
Values: Werte (integer, real und string) wie 5, 3, 4.12, “John“, “ Smith“
Objektidentifikatoren: Wie smith, s, p, …,
Functor Objekte: Family (bob, ann)
30
•
Sets: Wie { }, {bob, ann}
Dabei ist darauf zu achten, dass in Werten (Values) die ersten Buchstaben zwischen“ “ groß geschrieben aber in Objektidentifikatoren (OID) klein geschrieben werden.
Objekte werden durch Attribute beschrieben. Attribute sind in ROL partielle Abbildungen von Objekten zu Objekten. Angewandte Attribute für Objekte müssen in den
gleichen Klassen durch Attributdefinitionen definiert werden.
Wenn p und q Klassen sind, und l ein Attribut bezeichnet, dann legt p[l ⇒q] das value
Attribute von p fest. Wenn q eine Menge von Klassen darstellt, dann ist l ein set value Attribute.
Nicht nur Objektidentifikatoren besitzen Attribute, auch Values und Functor Objekte
können Attribute haben. Attributwerte können Objekte verschiedener oder auch unbekannter Art sein.[Lui,96]
Klassen in ROL werden zur Definition einer Menge von Objekten, die gemeinsame
Attribute teilen, eingesetzt.
Auf dieser Definition basierend werden vier Klassenarten unterschieden:
•
Value Klasse:
integer, real, string sind value Klassen
wenn i1 ∈ I und i2 ∈ I und i 1≤ i2, dann ist integer (i 1..i2) eine value Klasse.
wenn r1∈ R, r2 ∈R und r1≤ r2, dann ist real (r1..r2) eine value Klasse.
wenn si ∈ S für i= 1,…, n, dann ist string ({s1, …, sn}) eine value Klasse.
Allgemein: I, S, R {i∈I i11≤ i ≤ i2} und genauso {s1,...,sn} und (r1..r2).
•
Functor Objektklasse:
wenn p1, .., pn Klassen sind und f∈C eine n-stellige Objektklasse ist, dann
ist f(p1, .., pn) eine Objektklasse, genauer eine Functor Objektklasse.
•
OID- Klasse:
wenn n= 0 ist, dann wird dies eine OID - Klasse genannt.
•
Setklasse:
wenn p eine Klasse ist, dann ist {p} eine Setklasse und p die Komponente
der Klasse {p}.[ Lui,96]
Die Menge, die als Objektklasse bezeichnet wird, ist von dem ROL- Programm abhängig. Die Menge, die als Setklasse bezeichnet wird, ist von der Menge der Komponenten dieser Klasse abhängig.
•
•
Value Klasse
OID - Klasse
integer, string, integer (20...50), string ({´Male´, ´Female´})
person, student
31
•
•
Functor Objektklasse family ({person}), supplies (supplier, part)
Setklasse
{integer}, {person}, {family({person})}
Die Klassen sind durch Aggregation und Generalisierung miteinander verbunden.
Dadurch entsteht eine Klassenhierarchie.
In ROL werden die Untermengen von integer, real und string, sowie die Mengeneinschränkung unterstützt.[Lui,96]
Beispiel
{Person} (0,2) bedeutet eine Mengenkollektion mit maximal zwei Personen.
(Person} (2,2) bedeutet eine Mengenkollektion mit exakt zwei Personen.
Die OID- Klasse und Functor Objektklasse haben zwei Arten von Instanzen:
•
•
Immediate (direkte) Instanz
Non- immediate Instanz
Immediate Instanzen müssen genau festgelegt werden.
Beispiel
bob: Student
der Objektidentifikator bob stellt die immediate Instanz
der Klasse Student fest.
Family (bob, ann)
legt eine non-immediate Instanz der Klasse Family
(Person, Person) fest. Das bedeutet, dass bob und ann
beide Instanzen der Klasse Person sind.
Objektidentifikator und Functor Objekte können nur unmittelbare (immediate) Instanzen aus genau einer Klasse sein. Zusätzlich müssen die zutreffenden Attribute aller
Instanzen der Klasse durch Attributsdeklaration definiert sein.
Die Attributsdeklarationen einer Klasse werden zur Einschränkung aller möglichen
Attributswerte von ihren repräsentierten intensionalen und extensionalen Instanzen
benutzt.
In ROL kann eine Klassenhierarchie durch direkte Unterklassendeklaration definiert
werden. Nur die direkte Unterklasse der OID- und Functor Objektklassen können deklariert werden.
Allgemein werden Unterklassen durch direkte Unterklassendeklaration erzielt. Eine
Unterklasse erbt alle Attributsdeklarationen von ihrer Superklasse, außer bei der Überschreibung oder wenn sie blockiert wird. In ROL kann der Anwender die Attributserbschaft aus der Superklasse blockieren. Eine Einführung von zusätzlichen Attributdeklarationen ist ebenfalls möglich.
Wenn p und q Objektklassen sind, dann definiert p isa q , p als eine direkte Unterklasse von q, wobei q die direkte Superklasse von p darstellt.
32
In ROL kann die Mehrfachvererbung mit einer Überschreibung (Overriding) durch
extend isa (e-isa) erfasst werden. E-isa ist eine Beziehung (Relationship) mit folgenden Eigenschaften:
p e-isa q, wenn p und q value Klassen sind und p eine Untermenge von q ist.
p e-isa q, wenn p isa q
•
{p} e-isa {q}, wenn p e-isa q
isa* ist die reflexive Form von isa, und e-isa* die transitive Form von e-isa. Folgende
Notation macht die Mehrfachvererbung mit overriding anschaulich:
{p[l ⇒q’] ∃ p’, p e-isa* p’[l⇒ q’] ∈ DA,
and not ∃p’’, p’ ≠ p’’, p e-isa* p’’,
p’’ e-isa* p’, p’’ [l⇒q’’] ∈ DA}
Eine ROL- Datenbank besteht aus zwei Teilen: Schema und Programm.
•
Ein Schema ist eine Menge von Klassen mit ihren Attributsdeklarationen, sowie
den direkten Unterklassendeklarationen.
•
Ein Programm enthält Objektinformationen und besteht aus Fakten und Regeln,
die Extensionale und Intentionale Informationen über Objekte und deren Attributswerte repräsentieren.
Ein Schema ist ein Tupel K= (B, C, A, DC, isa, DA), wobei B ⊆ B, C ⊆ C, A ⊆ A und
DC eine unendliche Menge von Klassendefinitionen darstellt, die auf B und C basiert.
Jede Objektklasse f ∈ C ist genau mit einer Klasse in DC verbunden. Isa ist eine unendliche Menge von direkten Unterklassendefinitionen. DA ist eine unendliche Menge
von Attributsdefinitionen.
Alle Klassen und Attribute in DA sind Bestandteil aus DC ∪ A.
Ein Schema hat folgende Form:
c [a1 ⇒c1,..., an ⇒ cn ] isa d1,…, dm,
wobei c1,…,cn, und d1,…, dm Klassen sind, a1,…,an sind Attribute mit n ≥0, m ≥ 0.
a1,..., an gehören zu den Klassen c1,..., cn, und d1,...,dm und bilden Superklassen von
c1,..., cn.[Lui,96]
Beispiel:
student [age ⇒ integer (20...30), taking ⇒ {course}] isa person
Die Klasse c erbt alle Attribute der Superklasse d, wobei die Überschreibung und das
Blockieren von Attributen auch möglich sind.
33
Wie bereits erwähnt, liefern Fakten und Regeln liefern extensionale und intensionale
Informationen über Objekte und deren Attributswerte.
Ein Fakt lässt sich durch zwei Formen repräsentieren:
•
O: c [a1 → o1, …, an → on ]
•
f (o’1, …, o’n )[a1→o1, …, an → on ]
wobei o, o’1, …, o’m Objekte sind, c eine OID- Klasse darstellt, und f für Functor Klassen und a1, ..., an für Attribute steht.
Die erste Form bedeutet, dass O ein OID ist und c eine Klasse; a1, ..., an beschreiben
Attribute mit den Werten o1, ..., on.
Die zweite Form legt fest, dass das Functor Objekt f (o’1, …, o’n) die Hauptklasse f
mit den Attributen a1, …, an und die Attributswerte o1, ..., on besitzt.
Eine Regel hat die Form:
A :--- L1, ..., Ln,
wobei der Regelkopf A einen nicht negativen Ausdruck und L den Körper (eine Folge
von Objekten und Vergleichsoperationen) darstellt. [Lui,00]
Eine Regel ohne Körper ist ein Fakt. Fakten repräsentieren extensionale Informationen über Objekte und ihre Attribute. Attribute können in allen Instanzen der Klassen
angewendet werden. Diese Attribute werden Instanzattribute genannt. Vorraussetzung ist die Deklaration in einer Klasse.
Ein Objekt kann maximal einen Wert für die gegebenen Attribute haben. Falls mehr
als ein Wert zugeordnet wird, ist die Datenbank inkonsistent. Da ROL eine regelbasierte Sprache ist, lassen sich Informationen über Objekte und Attribute durch verstärkte Regeln in ROL repräsentieren.
Beispiele zu Schema, Fakt und Regeln in ROL:
Beispiel
Schema:
Person [age ⇒ integer (1..120),
Parents ⇒ {person},
Ancestors ⇒ {person},
TrueAnts ⇒ {person}]
Orphan [parents ⇒ none,
ansector ⇒ none,
34
trueAnta ⇒ none] isa person
family({person}) [childeren ⇒ {person},
childCount ⇒ integer]
{person}[cardinality ⇒ integer]
Fakten:
Pam:
Tom:
Joe:
Sam:
Joe:
Liz:
Ann:
Pat:
Jim:
orphan [age→ 60]
orphan [age→ 65]
person [age→ 40]
person [age→ 25]
person [age→ 40, parents → {pam, tom}]
person [age→ 43, parents → {pam, tom}]
person [age→ 20, parents → {bob, joe}]
person [age→ 23, parents → {bob, joe}]
person [age→ 40, parents → {pat}]
Regeln:
X [ancestors → ⟨ Y⟩]:---X [parents → ⟨Y⟩]
X [ancestors → ⟨ Y⟩]:---X [ancestors → ⟨Z⟩],
Z [parents → ⟨Y⟩]
X [trueAncs → ⟨ Y⟩] : ---X [ancestors → ⟨Y⟩],
not X [parents → ⟨Y⟩]
family (S)[children → ⟨X⟩] :---X[parents → S]
{X}[cardinality → 1]:---X: person
S [cardinality → Y] :---S=S1∪S2, S1∩2={}, Y= Y1 + Y2
S1 [cardinality → Y1],
S2 [cardinality → Y2]
X [childCount → Y] :--- X [children → S], S [cardinality → Y]
Hier gibt es vier Klassen: person, orphan, family und {person}.
•
OID - Klasse person hat age, parents, ancestors, und trueAnts als Attribute.
35
•
•
•
OID - Klasse orphan ist eine Unterklasse von person und erbt das Attribut age
und blockiert die Attribute parents, ancestors, und trueAnts der Klasse person.
Functor-Klasse family besitzt die Attribute children und childcount.
Setklasse {person}besitzt nur cardinality als Attribut.[Lui,00]
Fakten geben extensionale Informationen über Klassen, parents und age von OID’s.
Mit den Regeln wird bestimmt, wie Attributswerte für entsprechende OID, Functor
Objekte und Set abgeleitet werden können.
Wenn O1,…, On Terme sind, dann ist ⟨O1,…,On⟩ ein Teil- (partial) Set davon. Ein partial Set allein stellt in ROL kein Objekt dar, sondern wird benutzt, um eine Teilmenge
zu zeigen.
Falls {smith, john} eine Menge ist, kann ein Teil dieser Menge als partiale Menge
⟨smith⟩, ⟨john⟩ gezeigt werden. ⟨X1, ..., Xn⟩ mit n > 0 ist eine Teilmenge von Termen,
{X1, ..., Xn } ist die Menge der Terme. [LY,97]
Um die Negation auszuführen, muss die Regelmenge der ROL Objektbank stratifizierbar sein. Stratifikation wird durch einen abhängigen Graphen determiniert.
Der Graph wird wie folgt konstruiert:
Für jede Klasse oder Attribut einer Objektdatenbank wird ein Knoten eingefügt. Wenn
eine Regel existiert, in der x den Regelkopf und y den Regelkörper darstellt, dann
existiert auch eine Kante von x nach y.
Die Kante, die von x nach y verläuft ist mit X markiert.
Wenn y ein negativer Ausdruck ist, oder ein Ausdruck mit der Form: P [y? Q], sodass Q keinen partialen Set Term darstellt, existiert eine Regel wie P[y? ‹Q1, ..., Qn›]
im Regelkopf.
ChidrenCount
cardinality
trueAncs
family
children
Person
X
parents
Abbildung 4.1.1 (Abhängiger Graph)
36
ancestors
Die Menge von Regeln in einer Objektdatenbank gilt als stratifiziert, wenn im Abhängigkeitsgraphen kein Zyklus mit der markierten Kante enthalten ist.
In diesem Beispiel enthält die markierte Kante X keinen Zyklus, daher ist die Menge
der Regeln stratifiziert.[Lui,00]
In ROL gibt es drei Arten von Abfragen (Queries):
•
•
•
Schema Abfragen,
Objekt Abfragen,
Fakt- und Regel Abfragen.
Eine Abfrage (Query) in ROL hat die Form: Query L1,..., Ln.
Schema Abfragen werden benutzt, um Informationen über Klassen, deren Attribute
und Unterklassenbeziehungen zu gewinnen. Die direkte Unterklassenbeziehung
kann mit isa definiert werden, die generelle Definition wird mit isa* dargestellt.
Beispiele
Schema Abfragen:
query X:
Abfrage nach jeder definierten Klasse
X isa person:
Abfrage nach der direkten Unterklasse von Person
query orphan [A⇒X]:
Abfrage nach jedem definierten Attribut
query X [A⇒integer]:
Abfrage nach jeder Klasse und deren in integer
definierten Attributen
Objekt Abfragen: Abfrage von Informationen über Objekte, die extensional durch
Fakten oder intensional durch Regeln in der Objektdatenbank definiert sind:
query X: person
Abfrage nach jeder Instanz der Klasse Person.
query X[age→Y], Y> 45
Abfrage nach Personen über 45
query P[ancestors →Y]
Abfrage nach der Person und ihrer Vorfahren
query{pam, liz, bob, tom}[cardinality →Y]
Abfrage nach der Kardinalität der Menge
{pam, liz, bob, tom}.
37
(Die Kardinalität geben an, wie komplex die zueinander in Beziehung gesetzten Instanzierungen der für die Bearbeitungsfunktion benötigten Objekte sind).
Fakt und Regel Abfragen: Objektabfragen ermöglichen kombinierte Informationen
über Objekte, welche extensional und intensional repräsentiert werden. Zur Gewinnung von Informationen über die Art der Objektrepräsentation innerhalb der Objektdatenbank sind Fakten- und Regelabfragen erforderlich.
query [ancestors]
Abfrage aller Regeln zur Ableitung der Attributswerte von ancestors (Vorfahren)
query family[ ]
Abfrage aller Regeln zur Ableitung der Attributswerte aller Instanzen der Klasse Familie
query person [ ]
Abfrage aller Regeln zur Ableitung der Attributswerte der Instanzen der Klasse Person
query ann [children]
Abfrage aller Fakten und Regeln zur Angabe der
Attributswerte Kinder (children) von Objekt Ann
Abfragen können in einer kombinierten Form benutzt werden:
query liz: P [A→ X], P [A ⇒ Y]
Hier wird nach der Klasse von Liz sowie ihrer Attributswerte und der Attributsdeklaration gefragt.
Die Abfragen werden in ROL auf besondere Weise ausgegeben.[Lui,00]
Beispiel:
query X[age→Y]
Ausgabe: X=john, Y=25
ROL unterstützt die objektorientierte Datenmodellierung und die value orientierte
Datenmodellierung sowie ihre Kombination.
Es gibt in ROL drei verschiedene Möglichkeiten zu zeigen, dass Jim und Pat die gemeinsamen Kinder von Bob und Ann sind, und dass die Familie in 123 King St, Regina wohnt.
In der erste Methode, der value orientierten Methode, werden Sprachen wie LDL und
CORAL benutzt. Hier gibt es Mengen und Functor Objekte, aber keinen Objektidentifikator.
person (’Bob’,{’Jim’, ’Pat’},
adresse (’123 King St’, ’Regina’))
38
person(’Ann’,{’Jim’, ’pat’},
adresse (’123 King St’,’Regina’))
Das Problem dieser Methode ist, dass die gemeinsame Nutzung von Objekten, also
ein Objekt Sharing nicht unterstützt wird. Das heißt, wenn Bob und Ann weitere Kinder bekommen oder umziehen, müssen beide Fakten aktualisiert werden, (Update).
Bei dieser Methode unterstützt der Objektidentifikator ein Objekt Sharing und Update
Management.
bob[children→s, adresse → a]
ann [children → s, adresse → a]
s [set → {jim, pat}]
a [city →’Regina’, street→’123 King St’]
Die dritte Methode nutzt die Kombination aus beiden beschriebenen Methoden:
Den Objektidentifikator, die Mengen - und Functor Objekte.
bob[children → {jim,pat},
adresse→addr(‘Regina’, ‘123 king St’)]
ann [children → X, adress → Y]:--bob [children → X, adress → Y],
mit X und Y als Variablen
Diese Regel besagt, falls X die Kinder und Y die Adresse von Bob darstellen, dann
gilt dies ebenfalls bezüglich der Kinder und der Adresse von Ann.
Diese Vorgehensweise eignet sich nicht für objektorientierte Methoden.
Um zu zeigen, dass Jim und Pat die gemeinsamen Kinder von Bob und Ann sind,
aber auch Sam ein Kind von Ann ist, muss für ein maximales Objekt Sharing die
dritte Methode benutzt werden.
bob [children → {jim, pat}]
ann [children → ⟨sam⟩]
ann [children → ⟨X⟩]:---bob [children → ⟨X⟩]
Hier liefert {jim, pat} die vollständigen (complete) Werte für die Attribute children von
Bob, während die partielle Menge ⟨sam⟩ nur die partiellen Werte der Attribute
children von ann liefert.
Die Regel besagt, wenn X die Anzahl der Kinder von Bob darstellt, dann gibt X auch
die Anzahl der Kinder von Ann an. Der Wert {jim, pat, sam} für die Attribute children
von Ann kann durch Kombination des partiellen Werts ⟨sam⟩ mit den partiellen Werten ⟨jim ⟩ und ⟨pat⟩ erhalten werden, und ist aus der Regel herzuleiten.
In ROL werden Klassen Updates sowie Fakt- und Regelupdates unterstützt. Update
Befehle werden im Körper der Regel oder in der Abfrage eingesetzt. Klassen oder
39
direkte Super- und Unterklassen können eingeführt oder gelöscht werden. Attributsdeklarationen können eingeführt, gelöscht oder geändert werden.
insert person [age⇒ integer]
führt einen Attributswert für Person
ein, falls die Klasse Person nicht existiert, wird die Klasse eingeführt.
insert student [age ⇒integer(15..30),
takes ⇒ {course}] isa person
führt die Klasse student als direkte
Unterklasse von Person sowie den
Attributswert takes ein.
modify person [age ⇒ integer(0..100)]
ändert den Attributswert age (Alter)
von Person.
delete student [age ⇒ _]
Operation löscht das Attribut age (Alter) von Student.
delete course
löscht die Klasse course und alle ihre
Instanzen.
Fakten können neu eingeführt oder auch teilweise über Objekte gelöscht werden.
Beim Einführen neuer Fakten in ROL Datenbanken muss beachtet werden, dass die
neuen Fakten zur Klassendeklaration passen. Genauso können auch neue Regel
eingeführt und bei Bedarf gelöscht werden.
Bei der objektorientierten Methode gibt es n: n Beziehungen (many-to-many relationships) zwischen den Objekten. Diese Beziehungen können in ROL auf verschiedene Weise behandelt werden.
Eine symmetrische Methode ist die Benutzung des Functor Objekts zur Repräsentation von Updates über existierende Informationen. Diese Methode ist leichter durchzuführen als in eine relationalen Datenbank. Hierbei wird zwischen den intensionalen
und extensionalen Datenbanken nicht unterschieden, es gibt nur eine Datenbank für
die Anwendungen in ROL: Die Objektbank.
Es gibt Objektinformationen, die extensional definiert sind und Fakten nutzen, und
wiederum Objektinformationen, die intensional definiert sind und Regeln einsetzen.
Darüber hinaus gibt es Informationen, die in der Objektbank gespeichert sind und für
Updates genutzt werden.
40
4.2 ROL 2
Objektorientierte- und deduktive Datenbanken sind zwei wichtige Erweiterungen der
traditionellen Datenbanktechnologie.
Die objektorientierte Datenbank liefert einen besseren Weg zur Organisation und
Manipulation strukturierter Objekte. Den objektorientierten Datenbanken fehlen die
deklarative Abfrage (Query) und das logische Fundament.
Die deduktiven Datenbanken bieten eine logisch basierte Schnittstelle zur deklarativen Abfrage mit einem sicheren Fundament. Die fehlende Datenmodellierung wird
durch Nutzung objektorientierter Datenbanken repräsentiert.
Der folgende Abschnitt geht näher auf die Erweiterung von ROL zu ROL 2 ein.
ROL 2 enthält alle wesentlichen Eigenschaften von ROL. Zwischen der Notation der
Schemata und der Instanzen gibt es eine Teilung.
Die Schemata der Datenbank bestehen aus einer Menge von Klassendefinitionen.
Die Instanz der Datenbank besteht aus der Faktenmenge für die Beschreibung der
Klassen, der Attributdefinitionen, der vorgegebenen Werte (default values), der Methoden und der Klassendefinitionen.
In ROL 2 liegt der Schwerpunkt auf den Objekten und ihren Eigenschaften. Dabei
wird zwischen Objekten und Werten nicht unterschieden. Viele physikalische und
konzeptuelle Entitäten sowie deren Beziehungen in der realen Welt können in ROL 2
als Objekte angesehen werden. Objekte mit gemeinsamer Struktur und Verhalten
gehören zu einer Klasse.
Eine Klasse bezeichnet eine Menge von Objekten mit einer spezifischen Struktur
und spezifischem Verhalten. Der Strukturierungsteil einer Klasse besteht aus einer
Menge von Attributdefinitionen und deren Werten. Der Verhaltensteil besteht aus
einer Menge von Definitionsmethoden, die durch Regeln definiert werden.
In ROL 2 werden fünf Arten von Klassen unterschieden:
Value Klassen, OID- Klassen, Functor Klassen, Tupel Klassen und Set Klassen.
•
•
Value - Klasse:
OID – Klasse:
•
Functor Klasse:
Klassen für primitive Werte wie integer, string, real, ... .
Vorraussetzung ist eine explizite Klassendefinition, diese
kann in ROL 2 konkret oder abstrakt sein, wobei die konkrete Klasse eine direkte Instanz haben kann, während die
abstrakte Klasse dies nicht kann. Die abstrakte Klasse
wird hauptsächlich zur Organisation der Klassenhierarchie
benutzt.
Wird zur Mengendarstellung der Funktionsklassen genutzt, die die Beziehungen zwischen Entitäten der realen
Welt identifizieren.
41
•
Set Klasse:
•
Tupel Klasse
Bezeichnet eine Klasse von homogenen Mengen.
Eine Set Klasse hat die Form{c}, wobei c wiederum eine
Klasse ist.
Bezeichnet Tupel. Eine Tupel hat die Form:
(a1⇒c1, …, an ⇒cn), wobei a1, …, an Attribute und c1, cn
Klassen darstellen.[Lui,99]
Beispiel:
(city ⇒ string, street ⇒ string) ist eine Tupel Klasse mit string als einziger Komponente der Klasse.
Im Gegensatz zu OID - und Functor Klassen brauchen Tupel Klassen keine ausdrückliche Klassendefinition. Sie können direkt in der Klassendefinition einer anderen
Klasse ausgeführt werden. Die Menge, die als Tupel Klasse bezeichnet wird, ist abhängig von der Menge der Komponenten dieser Klasse und wird automatisch vom
System determiniert.
Genau wie Tupel Klassen können Set Klassen direkt ohne explizite Definition benutzt
werden, sobald ihre Klassenkomponenten definiert sind.
Zusätzlich werden in ROL 2 zwei eingebaute Klassen, - Objekt und None -, unterstützt: Die erste bezeichnet alle Objekte, während die zweite leer ist.
Objekte können Attribute besitzen, die untereinander in Beziehung stehen. Attribute,
die in allen Instanzen der Klassen anwendet werden, werden Instanzattribute genannt. Voraussetzung ist ihre Deklaration in einer Klasse. Die Aussage zu einer Attributsdefinition hat die Form:
c [[Public| Private]a==>c’[default o]],
wobei c, c´ Klassen sind, a ist ein Attribut und o eine Instanz von c’. [Lui,99]
Dies zeigt, dass a eine partielle Abbildung der Klasse c in der Klasse c’ darstellt.
Wenn c’ eine Set Klasse ist, dann ist a ein set valued Attribute, aber wenn c’ eine
Tupel Klasse darstellt, ist a ein tupel valued Attribute. Wenn c’ für eine Functor Klasse steht, dann ist a ein functor valued Attribute, sonst ist a ein atomic Attribute.
person [birthyear ⇒ integer (1900..2000) default 1970;
gender ⇒ char ({‘M’, ‘F’}) default ‘F’;
spouse ⇒ person;
parents ⇒ {person}];
address ⇒ (city ⇒ string, street ⇒ string)];
42
Birthyear, gender, spouse sind atomic Attributes, parents ist ein set valued Attribute
und adress ein tupel Attribute.
Wenn die Werte für die Attribute birthyear und gender nicht gegeben sind, können
default valued Attribute benutzt werden.
Falls die Werte von spouse, parents und adresse auch nicht gegeben sind, ist eine
Ausführung nicht mehr möglich.
Eine Reihe von Attributsdefinitionen für gleiche Klassen c[A1], …, c[An] lassen sich in
ROL 2 folgenderweise zusammenfassen: c[A1, …, An].[Lui,99]
Verschiedene Objekte können gemeinsame Attribute besitzen. Voraussetzung ist,
dass alle Instanzattribute in der Klasse deklariert werden. Um darzustellen, dass das
definierte Attribut ein Klassenattribut ist, werden Attributsklassenbeschreiber gebraucht.
Eine Klasse enthält zwei Arten von Informationen, die Attributsdefinition mit voreingestellten Werten (default value) und die Methodendefinition.
In ROL 2 werden diese zwei Informationsarten zu einer Klassendefinition zusammengeschlossen.
[abstract] class c [isa c1, , cl][[A1;…;Am;M1…Mn S1;…;So]],
wobei c, c1, , cl mit l ≥ 0 Klassen sind, und c[A1],…,[Am] die Attributsdefinition von
c darstellt; c [M1]…[Mn] steht für die Methodendefinition von c. Und S1;…;So stellt
die Vererbungsbeschreibung mit m, n, o ≥ 0 dar
Die Klassen werden mit Hilfe von insert Befehlen definiert. Als Beispiel wird die Klasse person eingeführt.
Beispiel
insert class person[
birthyear ⇒ integer(1900..2000) default1970;
gender ⇒ char({’M’, ’F’}) default ’F’;
spouse ⇒ person;
parents ⇒ {person};
age( )⇒ integer(0..100){age( )→ :-birthyear→B, A=1998-B}
ancestors( ) ⇒ {person} {ancestors( )→⟨A⟩ :-parents( )→⟨A⟩;
{ancestors( )→⟨A⟩ :-parents( )→⟨P⟩, P.ancestors( )→⟨A⟩}
children( ) ⇒ {person}{children( )→⟨C⟩ :-C.parents→⟨Self⟩}
divorce( ){divorce( ) :- delete spouse→S, not spouse→Self}
marry(person){marry(S) :- not spose→S1, not S.spouse→S2,
insert spouse→S, insert S.spouse→Self}]
43
Um zu zeigen, mit welcher Methode die Instanz verbunden ist, wird in ROL 2 eine
spezielle Variable Self eingeführt.[Lui,99]
In ROL 2 wird die Klassenhierarchie mit zwei built-in Klassen, - Objekt und none -,
beziehungsweise durch direkte subclass/ superclass - Definitionen organisiert.
Eine Unterklasse erbt in ROL 2 alle Attribute, default values und Methoden direkt von
ihrer Superklasse, und kann zusätzliche Attributdefinitionen, default values und Methoden einführen.
Es gibt zwei Arten von Vererbung: Property-Vererbung und Instanz-Vererbung.
Bei der Property-Vererbung erbt eine Unterklasse alle Instanzattribute mit deren default werten und Instanzmethoden direkt von der Superklasse. Klassenattribute und
Methoden können nicht vererbt werden.
In einer Instanz -Vererbung ist jede Instanz der Unterklasse eine undirekte Instanz
aus der Superklasse. [Lui,99]
Andererseits kann in der Property-Vererbung eine Unterklasse eine Attributsdefinition, default values und die Erbschaftsmethoden neu einführen, überschreiben oder
blockieren. Hierdurch wird die mehrfache Vererbung ebenfalls unterstützt, wodurch
Konflikte entstehen können.
Beispiel:
class employee[…room⇒string]
class student[… room⇒integer default 321]
class wstudent isa employee, student[…]
Wie dargestellt, ist wstudent eine Unterklasse von employee und student. Diese Unterklasse erbt Attribute und Methoden von beiden Klassen. Das führt zu einem Konflikt beim Attribut ’room’.
Zur Lösung dieses Konflikts werden vier verschiedene Methoden vorgeschlagen:
User-Specified Priority: Hier werden die Unterklassen in einer Klassendefinition von links nach rechts geordnet. Nach diesem Prinzip wird wstudent das Attribut von room erben.
Overriding: Soll wstudent die Attributsdefinition und das default value von room
und nicht von employee erben, dann muss die Definition von student in wstudent wiederholt werden, dadurch werden Attribute von employee überschrieben.
class wstudent isa employee, student[room⇒integer default 321]
Mit dieser Methode wird die Verbindung zwischen dem Attribut room von student und
von wstudent gebrochen, sodass jede Änderung der Attributsdefinition und der default values in student keine Wirkung auf wstudent hat.
44
Inheritance Path Selection: Es wird angenommen, dass employee und student die Methode income mit gleicher Signatur aber verschiedener Implementierung haben.
Damit wstudent Attribut room und Methode income von student statt von
employee erbt, kann folgende Definition benutzt werden:
class wstudent isa employee, student[room, income( ) from student]
Laut dieser Definition erbt wstudent nicht nur die Attributsdefinition, sondern
auch das default value room von student.
Explicite Renaming: Eine alternative Methode zur Lösung des oben beschriebenen Konflikts stellt die Umbenennung der Attribute und der Methoden, die zu
diesem Konflikt führen, dar.
Angenommen ein student hat zwei verschiedene rooms, erstes als student
room und zweites als employee room. [Lui,99]
Beispiel:
class wstudent isa employee, student [employee.room as eroom;
student.room as sroom]
Objekte, Klassen und auch ihre Attribute können durch Methoden abgefragt und
manipuliert werden. Die Methoden, die zur Manipulation von Objekten und deren Attributen benutzt werden, werden Instanz Methoden genannt. Methoden in ROL 2 sind
regelbasiert, und müssen definiert und in der Klassendefinition gekapselt werden.
Eine Instanz Methode besteht aus zwei Teilen, - Signatur und Implementation - und
hat folgende Form:
c[[public|private] op(c1,…, cn) [⇒cr]{R1;…; Rm}] ,
wobei c als Klasse in der Methode definiert ist. op(c1,…, cn) ⇒cr ist eine n-Stellige
Signatur. Wenn cr leer ist, kann es weggelassen werden. Anstelle von cr, kann
op(c1,…, cn) benutzt werden.
Falls n=0, dann gilt: op( ) ⇒cr, um cr von den Attributen zu unterscheiden.
age( ) ⇒integer(0..100) und ancestors( ) ⇒{person}sind zwei 0-ary Signaturen, während marry(person) eine unary Signatur ist.
Auch hier lassen sich die Methoden c[M1],…,c[Mn] in c[M1,…,Mn] kombinieren.
Wie bei objektorientierten Programmiersprachen, z.Bsp. bei c++ und Java, unterstützt ROL 2 Overloading. Mit dieser Methode können mehrere Methoden mit verschiedenen Signaturen in der gleichen Klasse benutzt werden.[Lui,99]
45
person[children( )⇒{person},{children( )→⟨C⟩:-C.parents→⟨Self⟩},
children(person)⇒{person},{children(P)→⟨C⟩ :-C.parents→{Self,P}, Self≠P}]
Die beiden Methoden haben denselben Namen ’children’. Die erste Methode ist jedoch eine 0-ary Methode, während die Zweite eine unary Methode darstellt. In ROL 2
werden zwei Arten von Regeln unterschieden, eine Regelabfrage, welche Werte
(values) ausgibt, und eine Update Abfrage, welche Updates der Datenbank übernimmt. Die Regel- und Update Abfragen werden jeweils auf unterschiedliche Weise
ausgewertet. Die Auswertungsmethode bei der Regelabfrage entspricht der bottomup Methode, bei der Update Abfrage ist die Vorgehensweise top-down.
ancestor( )→⟨A⟩ :-parents→⟨A⟩
ancestor( )→⟨A⟩ :-parents→⟨A⟩, P, ancestor( ) →⟨A⟩
marry(S): - not spouse→S1, not S.spouse→S2
insert spouse→S, insert S.spouse→Self
Die erste und zweite Regel entsprechen Abfrageregeln: Wenn A ein Elternteil von
Person ist, dann ist A auch ein Vorfahre von Person. Die dritte Regel ist eine Update
Regel, die die Datenbank mit dem Befehl insert aktualisiert.
Abfragen (Queries) in ROL 2 lassen sich in Schema Abfragen und Objekt Abfragen
klassifizieren.
Schema Abfragen werden benutzt, um Informationen über Klassen zurückzuholen,
und können grob in Klassenabfragen, Attributdefinitionsabfragen, default value- und
Methoden Abfragen klassifiziert werden. Objekt Abfragen können grob in Objektklassen-, Objektattribut-, und Methoden Abfragen unterteilt werden. Durch Objekt Abfragen werden Informationen über Objekte und Manipulationen von Objekten eingeholt,
Objekt Abfragen lassen sich auch in Objektklassenabfragen, Objektattributabfragen
und Methodenaufrufe klassifizieren.
ROL 2 liefert zwei elementare Update Befehle: Insert und delete.
Ein Update Befehl wird als eine Transaktion behandelt, die zu einem Erfolg oder
Misserfolg führen kann. Bei einem Misserfolg hat die Transaktion keinen Effekt auf
die Datenbank. Update Befehle werden zum Definieren und Manipulieren der Datenbanken benutzt. Update- Befehle können ebenfalls in Schema Updates und Objekt
Updates klassifiziert werden. Der Benutzer kann durch ein Schema Update die Klassendefinition löschen, einführen oder modifizieren.
Insert oder delete - Befehle werden zum Löschen oder Erzeugen von OID’s und
Functor Objekten eingesetzt, bzw. wenn Objekten Attributswerte zugewiesen oder
vorhandene Attributswerte gelöscht werden sollen.
46
Zur Modifikation von Attributswerten kann auch die Kombination von insert und delete benutzt werden. (OID’s hingegen können gelöscht bzw. neu erzeugt -, jedoch
nicht modifiziert werden) Zur genauen Angabe eines komplexen Updates, wird die
Kombination von Abfragen und Updates benutzt.[Lui,98]
47
4.3 C-Logic
C- Logic basiert auf Maier´s O-Logic, die Begriffe wie Objektidentität, Labels, und
Typen enthält. Diese Begriffe sind Grundlage für die Modellierung von komplexen
Objekten.
O-Logic ist eine Sprache, die die Semantik von komplexen Objekten beschreibt. Unterschiedliche Sprachen haben verschiedene Merkmale, und es ist nicht immer eindeutig, wozu die eine oder andere Semantik gebraucht wird, und wie durch sie komplexe Objekte unterstützt werden.
Die Integration der Semantik von komplexen Objekten in verschiedene Sprachen ist
nicht ganz einfach. C- Logic kann als eine Erweiterung von O- Logic angesehen werden. Zusätzlich zur Semantik von komplexen Objekten, hat beim Entwurf von CLogic auch Simplizität und Flexibilität eine wesentliche Rolle gespielt.
C- Logic stellt keine neue Logik für komplexe Objekte dar, ihre Semantik ist auf einer
Logik erster Stufe aufgebaut. Jede Formel in C- Logic kann in einer gleichwertigen
Form in eine Logik erster Stufe transformiert werden. Diese Transformation unterstützt nur die fundamentalen Aspekte komplexer Objekte.
Merkmale wie single-value Labels und static notation of types können in C- Logic
hinzugefügt werden. (Mit Labels lassen sich Eigenschaften kennzeichnen und repräsentieren).[CW,98]
C- Logic unterstützt zahlreiche gängige Merkmale von Mengen, und ermöglicht es
dem Benutzer durch Beschreibung von komplexen Objekten eine Gruppe von Informationen zu liefern. In C- Logic werden Labels genutzt. Vorteilhaft ist dabei der Einsatz von multi-valued Labels.
In der Logik erster Stufe gibt es drei Aspekte:
1.
Mit der komplexen Beschreibung eines Objekts kann jeder Subteil der Beschreibung verfolgt werden.
Beispiel: Von john[name⇒‘‘john smith’‘, age⇒28], kann john[name⇒‘‘john
smith’‘] und john[age⇒28] verfolgt werden.
2.
Verschiedene Teile der Beschreibug können zu einer Gesamtheit kombiniert
werden.
3.
Die Translation von Objektbeschreibungen in der Logik erster Stufe bringt Verständnis über komplexe Objekte.
Objekte müssen eine Identität und Eigenschaften bzw. Label values besitzen. Unter
Berücksichtigung der Eigenschaften können Objekte in verschiedene Klassen geteilt
werden. Dabei hat eine Klasse zwei Aspekte, einen dynamischen - und einen statischen Aspekt.
48
Eine Klasse unter einem dynamischen Aspekt stellt eine Menge von Objekten oder
OID’s in einer Klasse sowie deren Beziehungen dar. Der statische Aspekt repräsentiert die gemeinsamen Eigenschaften aller Objekte in dieser Klasse.
Beschreibung der Syntax und Semantik von C-Logic sowie deren Transformation auf
die Logik erster Stufe.
Die Grundsyntax besteht aus (∧, ∨, ¬, ⊃, ∀, ∃) und der Menge von Objekten, bestehend aus:
•
•
•
•
•
einer (abzählbaren, unendlichen) Menge von Variablen;
einer (abzählbaren) Menge von Funktionssymbolen;
einer (abzählbaren) Menge von Prädikatsymbolen;
einer Menge von Labels;
einer partiell geordneten Menge von Typsymbolen;
Falls L eine Objektsprache ist, dann wird die Semantik als ein Paar M=(M, I) definiert,
wobei M ein nicht leerer Mengenbereich (Domain) -, und I eine Auswertungsfunktion
darstellt, welche jedem Wert ein nicht -logisches Symbol zuweist:
I(f) ∈ ρ[Mn à M] für jedes n-stellige Funktionssymbol f;
I(ρ) ∈ ρ(Mn) für jedes Prädikatensymbol ρ
I(l) ∈ ρ(M²) für jedes Label l;
I(i) ∈ ρ(M) für jeden Typ i, wenn i1 ≤ i2, dann gilt I(i 1) ⊆ I(i2).
Es wird angenommen, dass jede Menge eine Partialmenge von Symboltypen besitzt,
die wiederum eine große Anzahl von Objekten haben. Für jede Formel in einer Objektsprache existiert eine gleichwertige Formel in der Logik erster Stufe. Diese
Transformation in first order logic kann als Basisvorschrift zur Ausführung komplexer
Objekte in der Logik erster Stufe genutzt werden.[CW,98]
49
4.3.1 Beschreibung und Berechnung komplexer Objekte
Komplexe Objekte lassen sich durch Fakten und Regeln in Logik beschreiben. Die
Argumentation bzw. Berechnung kann als logische Folgerung ausgeführt werden.
Gegeben sei eine Objektsprache mit einer Untermenge von Formeln, die wie folgt
definiert sind:
Jedes Literal ist eine atomare Formel oder eine Negation von atomaren Formeln.
Eine Klausel ist eine Disjunktion von Literalen: L1∨L2∨…∨Ln
Eine definierte Klausel ist eine Klausel mit genau einem positiven Literal:
A∨¬B1∨…∨¬Bm mit (m ≥ 0), wird auch geschrieben als: A:--B1,…, Bm.
Eine negative Klausel ist eine Klausel, die kein positives Literal enthält:
¬B1∨…∨¬Bm , und wird geschrieben als:
:--B1,…,Bm,
Eine negative Klausel wird auch Query bzw. Goal genannt. Wenn i1 und i2 Typsymbole sind, dann ist i1 ≤ i2 eine Subtypdeklaration. Ein Programm ist eine endliche
Menge von Subtypdeklarationen und Klassendefinitionen. Ein wichtiger Aspekt komplexer Objekte ist die Mengenmanipulation. C-Logic ist eine Logik erster Stufe und
hat keine eigene Wertmenge. Andererseits lassen multi valued Labels die Benutzung
von Mengen zu.
Beispiel:
person: john[childern⇒{bob,bill,joe}]
:--person:john[childern⇒{X,Y}]
sei ein Fakt und
eine Query
Nach der beschriebenen Semantik sind Labels im Wesentlichen binäre Prädikate.
Fakt und Query können folgenderweise transformiert werden:
person:john[children⇒bob, children⇒bill, children⇒joe].
:--person:john[children⇒X, children⇒Y].
X und Y können auf bob, bill und joe zeigen, um die Query (Abfrage) erfolgreich zu
bewerten. Labels können auch als eine Funktionsmenge betrachtet werden, die jeder
einzelnen Objektidentität wiederum eine Menge von Objekidentitäten zuordnet.
Im obigen Beispiel ordnet children john eine Menge von Objekten zu, die aus {bob,
bill, joe} besteht. Die Query kann als eine Frage nach einer Menge {X,Y} angesehen
werden, welche in der Menge von children in Verbindung mit john enthalten
ist.[CW,98]
50
4.4 F-Logic
F-Logic ist eine Sprache, die deduktive und objektorientierte Konzepte, wie Objekte,
Methoden Klassenhierarchien, Vererbung und Signaturen integriert.
Ein Vorzug der F-Logic gegenüber anderen Ansätzen ist die Fähigkeit zur uniformen
Behandlung von Daten und Methoden (z.B. Klassenhierarchie), die sie insbesondere
als Grundlage zur Schemamanipulation und Integration heterogener Datenbestände
interessant macht.
F-Logic ist eine Sprache die zwei verschiedene Ansätze zur Erweiterung des relationalen Modells miteinander verbindet:
Mit dem deduktiven Ansatz wird versucht, die Lücke zwischen Datenbanken und
Anwendungen zu schließen oder zumindest zu verkleinern, indem die Mächtigkeit
der Datenbankabfrage erweitert wird. Hierbei können Daten durch Regeln definiert
sein, wodurch die Mächtigkeit rekursiver Abfragen gegeben ist. Insbesondere kann
der deduktive Ansatz mit einer deklarativen, modelltheoretischen Semantik verbunden werden.
Beim objektorientierten Ansatz steht die Erweiterung des Datenmodells im Vordergrund. Hierbei werden komplex strukturierte Objekte mit einer Objektidentität eingeführt, die hierarchisch angeordneten Klassen zugeordnet ist.
Außerdem werden in F-Logic die Vorteile des Konzepts der High-level Methode (typisch für Frame basierte Sprachen) und well-defined Semantik kombiniert. [GR03]
Frame-Logic beschäftigt sich - vereinfacht ausgedrückt - mit der Spezifikation von FStrukturen. F-Strukturen sind Universen (Klassen), die aus Objekten bestehen, und
denen Attribute und Funktionen zugeordnet werden. Zusätzlich besteht zwischen
diesen Objekten eine Klassenelementrelation.
Mit Hilfe von Frame-Logic lassen sich genau diese Attribute, Funktionen und Relationen spezifizieren, so dass über eine solche F-Struktur Aussagen getroffen werden
können.
Um die Objektidentität einer F-Struktur aufzubauen, werden zunächst eine Menge
von Objektkonstruktionen und Variablensymbolen benötigt.
Ein Objektkonstruktor ist ein Funktionssymbol f mit einer zugehörigen Stelligkeit n.
Mit Hilfe der Objektkonstruktoren und der Variablen lassen sich – genau wie in Algebren - Terme konstruieren:
Jedes 0- Stellige Funktionssymbol und jedes Variablen- Symbol ist ein Term.
Ist f ein n-stelliges Funktionssymbol und sind t1, …, tn Terme,
so ist f (t1, …, tn ) ebenfalls ein Term. [Glausch]
Im Folgenden werden diese Terme ID-Terme genannt, da sie zur Objektidentifikation
benutzt werden.
51
Für eine F-Struktur muss nun als nächstes die Menge aller Objekte (Klassen) festgelegt werden. Weiter müssen alle Objektkonstruktoren durch konkrete Funktionen
mit Wert- und Bildbereichen in U interpretiert werden, das heißt: zu jedem Funktionssymbol f wird eine Funktion zugeordnet, die die Semantik von f festlegt. Durch Ersatz
aller Funktionssymbole in einem variablenfreien Term, lassen sich die ID- Terme, die
keine Variablensymbole enthalten, mit den dazu gehörenden Funktionen ausrechnen. Als Ergebnis erhält man ein konkretes Objekt des Universums U. Aus diesem
Grund werden variablenfreie ID-Terme auch logische Objekt ID’s genannt. Denn sie
identifizieren genau ein Objekt des Universums.
Objekte in F-Logic sind entweder komplexe Objekte oder Klassen von Objekten.
Klassen in F-Logic werden wie in einem Frame basierten Formalismus betrachtet.
Das heißt, dass eine Klasse als Instanz von einer Superklasse betrachtet wird. Dadurch ist die Vererbung in der Semantik von F-Logic aufgebaut. ID- Terme werden
auch als Objekte oder als OID’s betrachtet.
Methoden in F-Logic sind Funktionen. Sie liefern einen Wert oder eine Menge von
Werten zurück.
Klassen und Unterklassenvererbung werden durch Set value Funktionen modelliert.
Deklarative Definitionen von Methoden sind auch möglich, (da ID-Terme auch Labels
benutzen können).
Im Folgenden wird anhand eines Beispiels gezeigt wie Klassenbeziehungen, Unterklassenbeziehungen und Methoden in F-Logic aufgebaut sind:
’Alice’ und ’Bob’ seien 0 stellige Funktionssymbole;
’Paar’ ein 2 stelliges Funktionssymbol und ’X’ ein Variablensymbol.
Dann stellen ’Bob’‚ ’Paar (Alice, Bob)’ und ’Paar(Alice, X)’ ID Terme dar.
Diese Terme besitzen jedoch noch keine Semantik. Dafür muss ein Universum von
Objekten festgelegt werden. Dieses Universum enthalte die Personen Alice und Bob
und Partnerschaft von Alice und Bob, geschrieben als AliceundBob.
Den Funktionssymbolen wird folgende Semantik zu geordnet:
Das Symbol Alice wird durch eine 0 stellige Funktion A interpretiert, die Alice zurück liefert.
Das Symbol Bob wird analog durch eine Funktion B interpretiert, die Bob ergibt.
Das Symbol Paar wird durch die zweistellige Funktion P, die das Tupel (Alice,
Bob) auf das Objekt AliceundBob abbildet, interpretiert.
Damit können nun die oben gebildeten Terme berechnet werden. Der Term ’Bob’
ergibt über die Funktion B das Objekt Bob. Der Term ’Paar(Alice, Bob)’ ergibt nach
Einsetzen der Interpretation P(A(), B()) = P(Alice, Bob) = AliceundBob.
Der Term ’Paar(Alice, X)’ lässt sich nicht auf diese Weise berechnen, sondern benötigt die Interpretation der Variablensymbole. Dies geschieht über eine Funktion V, die
jedem Variablensymbol ein Objekt des Universums zuordnet.
52
V wird in diesem Fall als eine Belegung bezeichnet.
V sei also eine Belegung, die X den Wert Bob zuordnet. Dann kann der Term
’Paar(Alice, X)’ wie oben ausgerechnet werden, und es ergibt sich das Objekt AliceundBob.
In F-Logic existiert keine scharfe Trennung der Begriffe Objekt und Klasse. Ein Objekt, welches Element einer Klasse ist, kann selber wiederum Klasse einer anderen
Menge von Objekten sein.
Diese Element-Klasse-Beziehung wird in einer F-Struktur durch eine binäre Relation ∈ dargestellt. Diese Relation kann sogar zyklisch oder reflexiv sein, und sollte daher also nicht mit der ∈-Relation der Mengentheorie verwechselt werden. Syntaktisch
wird die Element-Klasse-Beziehung durch die molekulare Formel ’O: K’ dargestellt,
wobei ’O’ und ’K’ ID-Terme sind.
O: K bedeutet, dass das Objekt, das durch den ID-Term O beschrieben wird, Element der Klasse ist, die durch den ID-Term K beschrieben wird.
Im Folgenden wird der ID-Term O, also das Objekt, das durch den ID-Term O referenziert wird, abkürzend als ’Objekt O’ bezeichnet.[KL,97]
Die im obigen Beispiel beschriebene F-Struktur wird um die Objektkonstruktoren
Mensch und Spezies erweitert, die durch Mensch und Spezies interpretiert werden.
Mit Mensch sei die Klasse aller Menschen gemeint. Dies sollte nicht mit der Menge
aller Menschen verwechselt werden. Mensch ist ein Objekt, das die Menge aller
Menschen bezeichnet, es ist nicht die Menge selbst. Spezies sei die Klasse aller
Speziesklassen. Für die Element-Klasse-Beziehung wird festgelegt:
Bob ∈ Mensch und Alice ∈ Mensch.
Dies bedeutet, dass die Objekte Bob und Alice Objekte der Klasse aller Menschen
sind. In beiden Beziehungen tritt Mensch als Klasse auf.
Zusätzlich gelte, die Beziehung Mensch ∈ Spezies, in der Mensch die Rolle des Objektes der Klasse Spezies übernimmt. Syntaktisch können diese Zusammenhänge
durch die molekularen Formeln:
Alice: Mensch, Bob: Mensch und Mensch: Spezies
dargestellt werden.
Die zweite Art von Beziehung, die zwischen Objekten einer F-Struktur bestehen
kann, ist die Unterklassenbeziehung. Semantisch wird diese durch eine irreflexive
Halbordnung dargestellt. Syntaktisch wird die Unterklassenbeziehung durch die Formel:
T:: K
53
abgebildet. Dies bedeutet, dass die Klasse (bzw. das Objekt) T eine Unterklasse der
Klasse K ist.
Diese F-Struktur wird nun um die Objektkonstruktoren Mann und Frau und ihren entsprechenden Interpretationen erweitert. Mit Mann sei die Klasse aller Männer -, mit
Frau die Klasse aller Frauen gemeint. Für diese Objekte gelte die Beziehungen:
Mann < Mensch und Frau < Mensch,
das heißt, Mann und Frau sind Unterklassen der Klasse Mensch. Syntaktisch werden
die Beziehungen durch die molekularen Formeln
Mann :: Mensch und Frau :: Mensch
spezifiziert.
In der Objektorientierung sind Methoden Funktionen, die im Kontext eines Objektes
aufgerufen werden, und dabei eventuell eine Zustandsveränderung vornehmen oder
ein Resultat zurückliefern.
Die Basis der Frame-Logic beschäftigt sich aber nicht mit dem dynamischen Verhalten objektorientierter Systeme. F-Logic kann also nur funktionale Methoden modellieren.
In F-Logic werden Methoden semantisch durch partielle Funktionen dargestellt. Sie
können auf eins bis n stellige Tupel von Objekten des Universums angewendet werden. Sofern sie an dieser Stelle definiert sind, liefern sie als Ergebnis ein Objekt des
Universums zurück. Die erste Stelle des Argumenttupels stellt dabei das Objekt dar,
das in diesem Kontext der Methode aufgerufen wird.[KL,97]
In einer F-Struktur sind aus Gründen der Einfachheit alle Methoden Elemente des
Universums. Das bedeutet, Methoden werden in F-Logic mit Hilfe von ID-Termen wie
Objekte referenziert. Um Konflikte zu vermeiden wird deshalb gefordert, dass jedes
Objekt auch als Methode - und umgekehrt - verwendet werden kann.
Gegebenenfalls kann die Menge der verwendeten Methoden und die Menge der
verwendeten Objekte im Universum einer F-Struktur auch disjunkt sein.
Syntaktisch können in F-Logic Methoden durch sogenannte objektmolekulare Formeln spezifiziert werden.
Allgemein haben objektmolekulare Formeln folgende Form: O[a1,…, an],
wobei O ein ID-Term ist, der das zu beschreibende Objekt referenziert, und a1, …, an
Methoden-Ausdrücke sind, die die Methoden im Kontext von O näher beschreiben.
Es gibt eine Reihe verschiedener Formen von Methodenausdrücken. Im Folgenden
werden zwei von ihnen näher beschrieben:
Der skalare Methodenausdruck und der Signaturausdruck.
Ein skalarer Methodenausdruck hat die Form
M Θ A1, …, An → R,
wobei M, A1, …, An und R ID-Terme sind.
54
Die molekulare Formel O [M Θ A1, …, An → R] bedeutet, dass die Methode, die durch
den ID –Term M bestimmt wird, aufgerufen auf das Objekttupel (O, A1, …, An ) das
Ergebnis - R- liefert. Auf diese Weise können einzelne Stellen von Methoden spezifiziert werden. [AL]
Werden zusätzlich Variablen und Quantoren verwendet, lassen sich über unendliche
Objektmengen auch Methoden vollständig spezifizieren. Dies entspricht der Spezifizierung von Funktionen in der Prädikatenlogik.
Die bisher betrachtete F-Struktur wird nun um die Methode Partner erweitert. Partner
bildet das einstellige Tupel (Alice) auf das Objekt Bob ab. Anders ausgedrückt bedeutet dies, dass ’Partner’, - aufgerufen im Kontext von Alice und ohne Argumente -,
das Objekt Bob ergibt. Analog bildet Partner das Tupel (Bob) auf das Objekt Alice ab.
Partner selbst ist Element des Universums, also auch ein Objekt. Aber es hier als
Objekt zu verwenden, macht in diesem Beispiel wenig Sinn.
Die Methode Partner sei des Weiteren über das Funktionssymbol Partner referenzierbar. Damit lassen sich über die molekularen Formeln Alice[Partner Θ → Bob] und
Bob [Partner Θ → Alice] Partner für die Objekte Alice und Bob syntaktisch spezifizieren.
Ein wesentliches Konzept der Objektorientierung ist die Typisierung: Bestimmte Methoden können nur mit Argumentobjekten bestimmter Klassen aufgerufen werden,
und dürfen ihrerseits nur Objekte bestimmter Klassen als Ergebnis zurückliefern.
Dieses Konzept wird in F-Logic durch Signaturausdrücke abgebildet.
Ein Signaturausdruck hat die Form:
MΘ A1, …, An ⇒ R.
Die Molekulare Formel K[MΘA1,…, An ⇒ R] bedeutet, dass es erlaubt ist, im Kontext
von Objekten der Klasse K die Methode M mit Argumentobjekten der Klasse A1 bis
An aufzurufen. Der Ergebnistyp muss dabei Objekt der Klasse R sein. Dies entspricht
in der Objektorientierung der Deklaration einer Methode M in der Klasse K mit den
Argumenttyp A1 bis An und dem Rückgabetyp R.
Semantisch werden Methodensignaturen in F-Strukturen durch partielle Funktionen
dargestellt. Diese ordnen den Argumenklassentupeln die benötigten Rückgabeklassen zu. Der genaue Aufbau der Funktion ist über einige zusätzliche Eigenschaften
festgelegt, die für ein erstes Verständnis der F-Logic irrelevant sind und aus diesem
Grund hier nicht aufgeführt werden. [KL,97]
Mit Hilfe der Signaturausdrücke kann also die Methode Partner näher charakterisiert
werden. Über die Formel Mensch[PartnerΘ⇒Mensch] wird festgelegt, dass die Methode Partner im Kontext eines Objektes der Klasse Mensch ohne Argumente aufrufbar ist. Wird sie ohne Argument aufgerufen, muss sie ein Objekt der Klasse
Mensch zurückliefern. Da Alice und Bob Objekte der Klasse Mensch sind, gilt diese
Einschränkung also auch für Alice und Bob.
Nach der obigen Definition von Partner wird diese Einschränkung aber auch erfüllt.
55
Der Zusammenhang zwischen den Methoden und den Signaturen ist nicht Bestandteil der F-Strukturendefinition.
Das heißt, dass es in F-Strukturen Methoden geben kann, die gegen die Signaturen
verstoßen. Falls die Methoden einer F-Struktur jedoch Signaturen respektieren, so
spricht man von einer typisierten F-Struktur.
Die F-Formeln werden aus den molekularen Formeln (alle Formeln der Form O:K,
U::K, O[…]) mit Hilfe der logischen Operatoren und Quantoren aufgebaut:
Jede molekulare Formel ist eine F-Formel.
Sind φ, ψ F-Formeln, so sind:φ∨ψ, φ∧ψ und ¬φ F-Formeln.
Ist X zusätzlich ein Variablensymbol, so sind auch ∀ x : φ und ∃ x : φ F-Formeln.
Sind eine F-Struktur und eine Belegung gegeben, so kann der Wahrheitswert einer
F-Formel bestimmt werden. Dazu müssen zunächst die Wahrheitswerte aller molekularen Teilformeln definiert werden. Mit Hilfe der Belegung lassen sich alle IDTerme in Objekte umrechnen. Schließlich muss noch überprüft werden, ob die molekulare Formel der entsprechenden Semantik der F-Struktur entspricht.
Der Wahrheitswert einer gesamten F-Formel ergibt sich dann wie in der Prädikatenlogik:
∨ ∧ und ¬ werden als bekannte logische Verknüpfungen interpretiert.
∀ x: φ ist unter der Belegung ν erfüllt, wenn φ für alle Belegungen erfüllt ist, die ν bis
auf die Variable x gleichen. Analog ist ∃ x φ wahr, wenn eine Belegung existiert, die ν
bis auf die Variable x gleich und φ wahr macht. Nun können weitere Eigenschaften
der Methode Partner logisch spezifiziert werden.
Beispielsweise soll festgelegt werden, dass die Methode Partner im Kontext von
Objekten der Klasse Mensch symmetrisch ist. Dies kann über folgende F- Formel
angegeben werden:
∀ X : ∀ Y : (X : Mensch ∧ X [PartnerΘ → Y]) → Y[PartnerΘ → X].
Die Schreibweise φ → ψ ist dabei eine Kurzform für ¬φ ∨ ψ.
Die F-Formel ist also folgendermaßen zu lesen:
Für ein beliebiges Objekt X der Klasse Mensch muss gelten, dass die Methode
Partner, die im Kontext des Ergebnisses der Methode Partner aufgerufen wurde, im Kontext von X selbst wiederum X ergeben wird.
Wenn also der Mensch X einen Partner Y hat, dann muss Y den Partner X haben.
Für die Frame- Logic existiert analog zur Prädikatenlogik eine vollständige und korrekte Beweistheorie, mit deren Hilfe sich aus einer Menge von F-Formeln alle daraus
folgenden F-Formeln bestimmen lassen.
56
Ein F-Logic Programm ist eine Menge von Regeln. Fakten und Abfragen sind Spezialfälle von Regeln. Die Abfragen in FLORID werden getrennt vom übrigen Programm behandelt.
Die Regeln basieren auf den Horn Klauseln.
Fakten
Abraham
Sarah
Isaac
Ismael
Jacob
Esau
:man
:woman
:man[fatheràabraham;
:man[fatheràisaac;
:man[fatheràisaac;
:man[fatheràisaac
motheràSarah].
motheràhagar:woman].
motheràrebekah:woman].
motheràrebekah].
Regeln
x[son->>{Y}]
x[son->>{Y}]
x[daughter-->>{Y}]
x[daughter-->>{Y}]
:Y:man [fatheràx].
:Y:man[motheràx].
:Y:woman[fatheràx].
:Y:woman[motheràx].
Abfragen
? sys. eval.//This is a system command
?x:woman[son->>{Y[fatheràAbraham]}].
In F-Logic fangen Objektnamen immer mit einem Kleinbuchstaben an, wie sarah,
mutter, man. Variablennamen werden mit einem Grossbuchstaben wie X und Y geschrieben.
Allgemein haben Regeln folgende Form:
Logische Formeln: Bindungsformeln(Bedingungsteil).
Logische Formeln gelten nur dann, wenn Bedingungen gelten. (Horn Klausel)
Die Objekte in F-Logic sind entweder komplexe Objekte oder Klassen von Objekten.
Die Basisobjekte sind Konstanten von F-Logic. Objektkonstruktoren (Elemente aus f)
sind logische Funktionssymbole, mit arity ≥ 1, und werden zur Konstruktion neuer
Objekte genutzt.[AL]
57
4.5 Chimera
Chimera ist ein neues Modell für eine Datenbank und eine Datenbanksprache, die
als Schnittstelle der IDEA Methode entworfen wurde.
Ziel dieser Methode ist die Integration von objektorientierten, aktiven und deduktiven
Datenbanktechnologien in einem einzigen Modell.
Also die Zusammensetzung aktiver und deduktiver sowie objektorientierter Datenmodelle und deren Manipulationstechniken innerhalb eines definierten Rahmens (mit
Regeln und Operationen).
Der Begriff ’Chimera’ entstammt der griechischen Mythology: Eine Kreatur mit dem
Kopf eines Löwen, dem Körper einer Ziege und dem Schwanz einer Schlange. Übertragen auf die Datenbanksprache stellt jedes der Körperteile eine der drei Komponenten dieser zusammengesetzten Sprache dar.
Das wichtigste Merkmal von Chimera ist die Entwicklung einer Regelsprache für aktive und deduktive Regeln. Diese Regelsprache wiederum ist in einem objektorientierten Kontext integriert.
Das Chimera-Modell unterstützt zwar nicht die ’Relationship Idee’ von Objekt und
Entity-Relationship Modellen, aber diese werden von den meisten Datenbankprodukten ebenfalls nicht unterstützt.
Chimera als Designmodell zwingt daher die Entwickler ihre Beziehungseigenschaften
in eine geeignete Struktur zu transformieren, um diese so einer finalen Implementation anzunähern.
Chimera besteht aus einem konzeptuellen Modell (objektorientiertes Datenmodell)
und einer konzeptuellen Sprache (Chimera Language), die die Datendefinition, die
deklarative Abfrage, Datenmanipulationsregeln, passive und aktive Regeln, Restriktionen (Constraints) und Operationen unterstützt. Chimera ist der erste Versuch, die
Konzeptentwicklung von aktiven, deduktiven und objektorientierten Datenbanken in
eine systematische Methode zu kombinieren.
Der Kern dieses Modells ist durch Typen, Klassen und einer einfachen Generalisationshierarchie gegeben. Jede Klassendefinition beinhaltet einen einzigen geeigneten
Typen. Jeder Objekttyp umfasst eine Klassendefinition. Dieser Objekttyp wird nur in
einer Klasse eingesetzt, so dass die Beziehung zwischen Objekttypen und Klassen
one-to-one ist. Alle Objekte in Chimera müssen zu einer Objektklasse gehören. Typdefinitionen (Definitionen von Struktur und Verhalten) folgen direkt aus der Klassendefinition. Attributsklassen sind Funktionen, die ganze Klassen in einem einzigen
Wert abbilden. Durch Operationsklassen wird die gesamte Klasse manipuliert und
nicht nur einzelne Instanzen. Values werden durch Typen oder Klassen bestimmt,
meist atomic values wie integer und string. Diese sind vordefiniert und können nicht
durch den Anwender manipuliert werden. Konzepte wie integer und string werden
aber auch nicht als Klasse, sondern als Typ betrachtet[CM,94]
Eine Schemadefinition in CL (Chimera -Language) ist eine Kollektion von gerichteten (targeted) und ungerichteten (untargeted) Definitionen. Jeder definierte Typ und
jede definierte Klasse ist ein Ziel (Target).
58
Merkmale, wie Attribute und Operationen, welche im Kontext von Targets definiert
sind, haben einen Bereich (Domain), der die Grenze für diese Targets bildet. Targets
ermöglichen ein passendes Design und einen bestimmten Informationsgrad. Dies ist
typisch für die objektorientierte Entwicklung. Einige Informationen im Schema (Kontext eines Types oder einer Klasse) lassen sich jedoch nicht zusammenfassen.
Abgeleitete Informationen oder Triggereffekte mehrerer Klassen, sowie eingeschränkt zusammenhängende Zustände von Objekten mehrerer Klassen werden
untargeted genannt.
In CL können zur Informationsherleitung passive Regeln angewendet werden. Vergleichbar zu deduktiven Datenbanken werden passive Regeln in folgenden Fällen
verwendet:
•
•
•
Wenn abgeleitete Attribute Werte besitzen können, die durch Regeln, anstatt
durch Update Operationen definiert sind.
Im Kontext von Klassenhierarchien.
Untargeted views werden immer durch passive Regeln definiert.
Zusätzlich zur Basisstruktur und dem Verhaltenskonzept von Attributen und Operationen bietet Chimera zwei weitere Konzepte: Constraint und Trigger. Dabei können
beide Konzepte gerichtet (targeted) oder ungerichtet (untargeted) sein. Constraints
werden immer durch passive Regeln, und Trigger durch aktive Regeln ausgeführt.
Die Implementation von Constraints erfolgt durch eine Menge von untargeted Regeln. Es gibt auch targeted Constraints, die jedoch nicht neu definiert werden können. Aufgrund der Einmaligkeitsbedingung muss ihre Bezeichnung mit Rücksicht auf
alle targeted Constraints der Klasse gewählt werden. Jedes Constraint hat einen
Outputparameter vom Typen der Klasse, in welchem es definiert ist.
Vergleichbar zu den passiven Regeln in Chimera, welche als deklarative Mittel zur
Ausführung bestimmter Konzepte dienen, gibt es in Chimera noch zwei weitere Kategorien zur Ausführung von imperativen Konstrukten: Trigger und Operationen.
Chimera unterstützt Set– oriented Trigger. Diese werden während der Durchführung
von Datenbankoperationen aktiviert, und sind während der gesamten Berechnungen
reaktionsfähig. In Chimera folgen Trigger dem event- condition- action Muster von
aktiven Datenbanken.
Event entspricht einem Datenbankzugriff zur Wiederherstellung und Manipulation.
Condition ist eine deklarative Formel, die den Zustand einer Aktivität bewertet, bevor
eine Reaktion ausgelöst wird. Jede Reaktion ist eine Kette von einem oder mehreren
Prozeduraufrufen, die bei jeder einzelnen Datenbankberechnung ausgeführt werden
kann. Eine Query ist eine Operation, die ausgeführt wird, während ein Term im Kontext einer passiven Regel bewertet wird.
Einfacher ausgedrückt, können aktive Regeln als eine Tripel betrachtet (Event– Condition– Action / ECA) werden. Event entspricht der Datenmanipulation in Chimera,
Condition ist ein deklarativer -, und Action ein prozeduraler Ausdruck.
59
In einer aktiven Datenbank bestehen die ECA- Regeln aus Ereignissen, Bedingungen und Aktionen. Diese Regeln bewirken bei Eintritt eines Ereignisses, dass die
Bedingungen überprüft werden, und falls diese erfüllt sind, die Aktion ausgeführt
wird.
Sobald eine Menge von Regeln definiert wird, überwacht das aktive Datenbankmanagementsystem (DBMS) alle relevanten Ereignisse. Das Eintreten jedes relevanten
Ereignisses wird sofort entdeckt und die für die Regelausführung zuständigen Komponenten werden benachrichtigt. Dieser Vorgang wird Ereignissignalisierung genannt. Dabei werden die für dieses Ereignis definierten Regeln nacheinander ausgelöst und anschließend ausgeführt.[Schubert, 99]
Chimera unterstützt ein breites Typensystem, das bedeutet, dass die Entwickler in
Chimera die Attributstrukturen weitgehend frei bestimmen können.
Ein Typensystem mit vergleichbaren Merkmalen kann durch herkömmliche, objektorientierte Datenbanken unterstützt werden. Objektidentifikatoren weisen auf Objekte
und sind in die Menge der möglichen Typen eingeführt.
Typen werden durch atomic Types und strukturierte Typen klassifiziert.
•
•
Atomic Types werden entweder durch die Programmierungsumgebung oder
durch die Implementationssprache festgelegt, wie oid, integer, real, boolean,
string und enumeration (benutzerdefiniert).
Strukturierte Typen (Set, List, Record)
Die Semantik von Set Types ist mengenorientiert, das heißt, es gibt keine doppelten
Elemente im Gegensatz zu List Types, wo doppelte Elemente vorkommen können.
Es ist möglich, den Typen (atomic oder strukturiert) einen benutzerdefinierten Namen
zu geben. Diese Eigenschaft ist für Anwendungen wie zum Beispiel Wiederholung
auf komplexe Typen, sehr sinnvoll. Dadurch wird die Typdefinition ausgeklammert
und kann somit einmal für alle benutzt.
Benutzerdefinierte Typen, (Named Types), werden durch Typdefinition eingeführt
und unterstützen nicht immer die gesamte Value Menge. Chimera ermöglicht die
Vereinigung von Constraints mit Named Types.
Typdefinition ::= ‘’defined’’ ‘’value’’ ‘’type’’ ‘’type-name’’:’’type’’
[‘’constraint’’ constraint-names]
’’end’’
Es gibt keine Beschränkungen bezüglich strukturierter Typen, denn sie lassen sich
durch rekursive Verwendung von atomaren und abstrakten Typen (strukturiert) konstruieren. Eine Besonderheit ist der Typ OID, der nicht explizit benutzt werden kann.
Wenn ein Attribut auf ein Objekt einer anderen Klasse verweisen soll, wird der entsprechende Klassenname verwendet, wobei dann intern dafür der OID Typ benutzt
wird.
Folgende vereinfachte BNF-Notation zeigt die Chimera Syntax für Werttypen:
60
type::= atomic-type | structured-type | type-name
atomic-type::= ‘’boolean’‘ ‘‘integer’‘ |’‘real’‘ |’‘string’‘ | class-name | enumerationtype
enumeration’‘{‘‘user-defined-symbols’‘}’‘
structured-type::= ‘‘list-of’‘ ‘‘(‘‘type’‘)’‘| ‘‘set-of’‘ ‘‘(‘‘type’‘)’‘ | ’‘record-of’‘ ‘‘(‘‘fields’‘)’‘
field::= label ‘‘:’‘ type
Klassen bilden die Hauptkonstrukte für objektorientierte Ansätze. In der Terminologie
von Chimera werden Klassen als Objektklassen und Instanzen von Klassen, (also
Objekte), als Objekttypen bezeichnet. Die Schemadefinition ist auf Klassen aufgebaut, die Targets genannt werden. Die Definition der Klasse wird von der Definition
ihrer Signatur und Implementation getrennt.
Die Klassendefinition besteht aus zwei Teilen: Signatur und Implementation.
Die Signatur beschreibt die Klassenstruktur, und insbesondere ihre gesamten Komponententypen. Die Implementation stellt die Semantik der Komponenten dar, und
muss einen Wert haben.
Die Objekte in einer objektorientierten Datenbank werden durch die Methoden manipuliert. Eine Manipulationsmethode hat dieselben Komponenten wie die Klassendefinition: Die Signatur und die Implementation.
Im Folgenden sind Klassenkomponenten in Chimera aufgelistet:[CF,97]
Object-class-definition ::=
“define” “object” “class” class-name
[ [“derived”] “superclass” class-name ]
[“attributs” attribute-defs]
[“constraints” constraints-defs]
[“operations“ operations-defs]
[“triggers” triggers-defs]
[“key” key-defs]
[“unique” key-defs]
“end;”
Superklassen (Oberklassen): Mit der Definition der Superklassen lassen sich Klassenhierarchien gemäß des objektorientierten Konzepts der Vererbung realisieren.
Attribute: In den Attributen werden die eigentlichen Objektinformationen gespeichert. Die Summe aller Attributwerte definiert dabei den Zustand, in dem sich das
Objekt gerade befindet.
61
Constraints: Bezeichnen sogenannte Integritätsbedingungen (IBs). Integritätsbedingungen beschreiben inkonsistente Datenbankzustände. Zur Definition dieser IBs
werden deduktive Regeln verwendet, die im Gegensatz zu den anderen deduktiven
Regeln eine besondere Interpretation haben. Diese Interpretation heißt „denial form“
und bedeutet, dass eine Inkonsistenz eintritt, sobald eine Wertbindung für den deklarativen Ausdruck im Regelkopf erfolgt. Eine Wertbindung hat hier zur Darstellung einer Einschränkung des Inhaltes einer Datenbank jedoch eine negative, “unerwünschte“ Bedeutung.
Operation: Diese wird eingesetzt, um den Objektstatus zu ändern. Formal gesehen
ist eine Operation eine Abbildung, die Objekte von einem Zustand in einen anderen
überführt. In Chimera wird das Konzept der Polymorphie unterstützt, das heißt ein
Objekt einer Unterklasse kann eine eigene Methode für die von der Superklasse vererbten Operationen implementieren.
Triggers: Setzen das Konzept der aktiven Regeln um. In Chimera werden Trigger in
Abhängigkeit von Datenbankereignissen (delete, modify, create, ..) und bestimmten
Bedingungen ausgelöst, das heißt der prozedurale Aktionsteil der Regel wird ausgeführt. Aktive Regeln werden vom Datenbankmanagementsystem autonom verwaltet und automatisch ausgeführt, sobald die triggerspezifische Situation eintritt.[Schubert,99]
Special Key: Definiert die klassischen Primärschlüssel- Attribute.
Unique: Bietet die Möglichkeit, Sekundärschlüssel zu definieren.
Attribute einer Klasse beschreiben die Instanzstruktur der Klasse. Sie werden durch
eine Menge von Attributsspezifikationen deklariert, die die Namen und die Domain
der Attribute bestimmen. Extensionale Attribute werden ausdrücklich durch Einführung neuer Objekte mit expliziten Attributswerten implementiert. Jedes abgeleitete
Attribut wird durch eine Menge von deduktiven Regeln implementiert.
In Chimera wird eine Objektklasse durch Klassensignatur, Klassenimplementation
und Trigger definiert. Die Implementierung von Triggern erfolgt jedoch in einer getrennten Spezifikation (imperative Sprache).
Der Name einer Objektklasse muss unter Berücksichtigung der Menge aller Klassen
und Typnamen einmalig sein. Das heißt, es darf keine andere Objektklasse, Value
Klasse oder Typklasse mit gleichem Namen existieren.
Jede der oben genannten Komponenten kann fehlen. Zur Klarheit sollten jedoch die
Namen der verschiedenen oben aufgeführten Komponenten bestimmt werden.
Klassendefinition in Chimera.
Beispiel:
62
define object class person
attributes
name: string
nationality: string notnull,
birthday: data,
vatCode: string,
age: integer derived,
income: integer,
profession: string,
constraints
toolowIncome
operation
changeIncome(in Amount: integer)
triggers
incomereport
key
(vatCode)
unique
(name,birthday)
end.
Klassen können in einer Generalisierungshierarchie organisiert werden. Jede Unterklasse wird durch einen Hinweis auf eine Superklasse definiert. Die Namen aller
direkten Superklassen einer Klasse werden ebenfalls definiert.
Um eine Subclass-relationship zu bestimmen, müssen folgende Punkte beachtet
werden.
•
•
•
•
•
Alle Objekte einer Unterklasse existieren auch in der Superklasse. Es gibt für
jedes Objekt in einer Unterklasse genau ein Objekt in der Superklasse mit gleichem OID
Attribute, Operationen, Constraints und Trigger, die für die Superklasse definiert
sind, gelten auch für die Unterklasse.
Attribute, Operationen, Constraints und Trigger, die mit der Einführung der Unterklasse eingeführt werden, müssen mit der Superklasse identisch sein.
Ein Objekt kann in mehreren Unterklassen existieren ohne eine direkte Unterklassenhierarchie.
Mehrfachvererbung von C auf die Klassen c1,…,cn sind erlaubt. Es existiert
eine Superklasse als gemeinsamer Vorfahre von c1,…,cn. Instanzen können in
einer Unterklasse explizit eingeführt oder gelöscht werden.
Zum Verständnis des Aufbaus der Generalisierungshierarchie ist es sinnvoll die Semantik der Manipulation informal und kurz zu beschreiben:
63
•
•
•
•
Create kann in jeder Klasse einer Generalisierungshierarchie angewendet werden. Durch die Anwendung dieser Regel werden neue Elemente in der konkreten Klasse sowie in allen Klassen der Hierarchie gebildet.
Specialize wird an zwei Klassen in einer Generalisierungshierarchie angewendet, falls die erste eine Superklasse für die Letztere ist. Als Resultat werden die
Objekte der 1. Klasse auch zu Objekten der letzteren Klasse, und damit auch zu
Objekten aller dazwischen liegenden Klassen.
Generalize wird an zwei Klassen in einer Generalisierungshierarchie angewendet, wenn die 1. Klasse eine direkte Unterklasse ist. Als Resultat werden alle
Objekte der 1. Klasse, auf die die Generalisierung angewendet wird, von dieser
Klasse und damit auch von allen dazwischen liegenden Klassen entfernt.
Delete kann auf jede Klasse in einer Generalisierungshierarchie angewendet
werden. Als Konsequenz der Generalization und Deletion werden einige OID’s
ungültig.
Das Konzept der Vererbung kann entweder neu definiert oder überschrieben werden. Die Redefinition erfordert jedoch die Einführung des Subtypen -Begriffs.
In Chimera kann eine Klasse (Objektklasse) als Unterklasse von einer oder mehreren existierenden Objektklassen deklariert werden. Eine Unterklasse erbt Attribute,
Operationen, Constraints und Trigger von der Superklasse. Wenn ein neues Objekt
eingeführt wird, wird dadurch auch eine neue Subtypenbeziehung in Objekttypen
eingeführt.
Durch folgende Regeln werden Subtypen in Chimera definiert.
wenn user -defined value type T : T1 gilt, dann ist T ein subtype von T1
wenn T ein subtype von T1 ist, dann ist set-of(T) ein subtype von set-of(T1)
wenn T ein subtype von T1 ist, dann ist list-of(T) ein subtype von list-of(T1)
wenn T = record-of (l1: T1,l2:T2,…,ln:Tn) ein record Type ist,
dann ist jeder record Type record-of (l 1:D1, l2:D2,…, ln:Dn) ein subtype von T für
jeden Komponententyp Di, das identisch ist mit den Komponenten Ti oder einem
Subtype des entsprechenden Type Ti.
Die Signatur eines Attributs oder einer Operation kann umgeschrieben werden durch
Spezialisierung der Attributtypen bzw. einem oder mehreren Operationsparametern.
Inputparameter der Operationen können auf zwei Wegen redefiniert werden:
1.
2.
Durch das Ersetzen von Typen in der Superklasse mit einem geeigneten Supertype.
Durch Das Ersetzen von Typen in der Superklasse mit einem geeigneten
Subtype.
64
Auf eine neu definierte Signatur wird durch Einfügen einer geeigneten, redefinierten
Komponente der Subklassendefinition hingewiesen. Es muss beachtet werden, dass
auch extensional und intensional abgeleitete Attribute neu definiert werden können.
Diese können jedoch nicht so definiert werden, dass ein intensional abgeleitetes Attribut zu einem extensionalen Attribut wird und umgekehrt.
Die Implementation auf ein Attribut oder eine Operation kann umgeschrieben werden
durch die Einführung einer anderen Implementation auf das jeweilige Konzept, welches in der Erbdefinition Vorrang hat. Eine Redefinition einer Implementation kann
kombiniert werden mit- oder ohne eine Redefinition der Signatur. Die Umschreibung
von Constraints und Triggers ist nicht erlaubt.
Views werden benutzt, um abgeleitete Konzepte aus existierenden Konzepten der
Datenbank zu bilden. Jede View hat eine Signatur und eine Implementation. Die Signatur ist durch Parameter -, die Implementation durch eine Menge von deduktiven
Regeln gegeben.
Der konzeptionelle Teil von Chimera kann in vier Komponenten zerlegt werden:
Deklarative Ausdrücke werden zur Manipulation und zum Entfernen von Informationen benutzt. Neben der Unterstützung von Queries sind in Chimera die
deklarativen Ausdrücke Komponenten von aktiven und deduktiven Regeln und
Operationen.
Zur Änderung von Objektzuständen ist ein minimaler und zusammenhängender
Satz von Datenmanipulationsregeln erforderlich.
Mit einfachen Ausdrucksverfahren wird die Anwendungskette durch obige Regeln definiert. Das ist die Basis der bekannten Sprachverfahren.
Die Sprache unterstützt die Implementation von Schemakomponenten, (ausgedrückt durch deduktive Regeln, aktive Regeln und Operationen)
In einer Datenbank bilden deduktive Regeln die Basis für detaillierte Angaben von
deklarativen Ausdrücken.
Chimera basiert auf einer logischen Sprache und unterstützt deklarative Queries sowie deklarative Regeln für deduktive Regeln. Ebenso werden deklarative Bedingungen zur Kontrolle von aktiven Regeln und Operationen unterstützt, deshalb sind die
deklarativen Ausdrücke in dieser Sprache ubiquitär vorhanden.
Deklarative Ausdrücke werden in Chimera über eine logische Sprache definiert. Jede
klassische logische Sprache besteht syntaktisch aus Termen und Formeln.[CF,92]
Terme sind entweder atomic oder komplex.
Atomic Terme (Atomare Terme) bestehen aus Konstanten oder Variablen. Konstanten sind atomic values, das heißt integer, string, real, oid oder boolean. Variab-
65
len werden durch eine Kombination alphanumerischer Zeichen gebildet, wobei das
erste Zeichen ein Großbuchstabe sein muss. Bezüglich deduktiver Regeln unterliegen Variablen einem Gültigkeitsbereich (scope), das heißt, sie gelten nur im Kontext
der Regeln, in denen sie auftreten. Kommt ein Variablenname auch in anderen Regeln vor, so sind diese als unterschiedlich zu betrachten, da eine Variablenbindung
nur innerhalb einer Regel erfolgt. Außerhalb der Regel existiert sie nicht mehr.
Komplexe Terme bestehen aus funktionalen und auswertbaren Termen. Unter funktionalen Termen versteht man die strukturierten Werttypen von Chimera (Set, list und
record). Auswertbare Terme (evaluable Terms) werden durch ein auswertbares
Funktionssymbol und eine Liste von Termen als Parameter gebildet, aus denen ein
Rückgabewert berechnet wird. In Chimera gibt es drei Arten von auswertbaren Funktionen: Attributs, Selectors, Operators.[Schubert,99]
In Chimera ist jeder Term an einen Typ gebunden. Jedoch ist eine Bestimmung
dieser Typbindung nicht immer möglich. Dies ist beispielsweise der Fall, wenn innerhalb eines Terms unverträgliche Typbindungen (Typkonflikte) auftreten. In diesem
Fall kann kein gültiger Term ermittelt werden. Terme, die solche Typkonflikte enthalten, sind semantisch nicht korrekt. Um passive Regeln auswertbar zu bleiben, müssen Terme bereichbeschränkt sein. Ein Term ist genau dann bereichbeschränkt
wenn er wiederum nur bereichbeschränkte Variablen enthält bzw. variablenfrei ist.
Eine Variable ist genau dann bereichbeschränkt, wenn sie mit endlich vielen Werten
ersetzt werden kann.
Formeln können atomic oder komplex sein.
Atomic Formeln bestehen aus Prädikatsymbolen. Diese werden aus einer Folge
von alphanumerischen Zeichen gebildet, wobei das erste Zeichen ein kleiner Buchstabe sein muss oder ein spezielles Zeichen einer vordefinierten Relation. Atomare
Formeln werden in Chimera weiter klassifiziert in:
Klassen- und Typformeln
Vergleichformeln
Mitgliedschaftsformeln
Auswahlformeln
Integritätsformeln
Ereignisformeln
Komplexe Formeln werden durch Verknüpfung von atomaren Formeln mit Konjunktion und Negation gebildet:
Formular ::= atomic-formular | komplex-formular
komplex-formular ::= formular [ ^ | ¬ ] formular
66
Prozedurale Ausdrücke stellen eine Kette von Regeln für Datenbankzustände dar.
Es gibt zwei verschiedene Ketten von Operatoren:
1.
2.
Für die vorübergehende Variablenbesetzung, die den Komponentenzustand in
den nächsten Zustand (neuer Zustand) versetzt, und
Für eine vorübergehende individuelle Bindung.
Deklarative Regeln können die Nutzung von Mengen sowie die willkürliche Nutzung
von Disjunktionen und Negationen nicht explizit einbauen. Prozedurale Ausdrücke
sehen keine Strukturkontrollen vor, ermöglichen aber eine Prozeduralkette von Aufrufen (calls), mit set-orientierten oder objektorientierten Aufrufmustern.
Regeln und Operationen sind wichtige Komponenten der IDEA Methode, und besitzen die Fähigkeit, neue Informationen zu modellieren. Abgesehen von deren multiplen
Anwendungs- und Syntaxdetails verfügen IDEA- Regeln und -Operationen über eine
einfache Struktur. Die deduktiven Regeln (mit Kopf und Body) gelten als deklarative
Ausdrücke. Operationen sind eine Kombination aus deklarativen und prozeduralen
Ausdrücken.[CF,92]
Head ? Body ist eine deduktive Regel mit einem atomic - Kopf und einem atomicBody als deklarativer Ausdruck.
In Chimera kann der Objektzustand durch Query und Updateregeln definiert werden.
(Chimera unterstützt die herkömmlichen Query- und Updateregeln.)
Operationen bestimmen den vordefinierten Mechanismus für die Wiederherstellung
und Manipulation eines Objektes. Operationen haben zwei Komponenten:
Kondition: ist eine Formel in Chimera
Operation Code: ist ein prozeduraler Ausdruck
Active Regeln: Active Regeln werden in Chimera als Trigger bezeichnet. Die Definitionen von aktiven Regeln sind durch Triggers vorgeformt.
67
5 Analyse
In Abschnitt 5.1 werden die Sprachen F-Logic, ROL und Chimera bezüglich bestehender Gemeinsamkeiten und Unterschiede analysiert. Die Ergebnisse werden in
Form von Tabellen verdeutlicht.
68
5.1 Vergleich deduktiver objektorientierter Datenbanksprachen
Deduktive objektorientierte Datenbanken bilden eine Kombination aus dem logischen
Teil deduktiver Methoden und der objektorientierten Methodenmodellierung. Neben
einer Reihe von weiteren Sprachen zählen auch F-Logic, ROL und Chimera zu den
deduktiv objektorientierten Datenbanksprachen (DOOD).
Die deduktiven und objektorientierten Datenbanken repräsentieren zwei wichtige Erweiterungen im Bereich der herkömmlichen Datenbanktechnologie. Die deduktive
Datenbank ergänzt die Aussagekraft der traditionellen Datenbank mit Hilfe der Rekursion und der deklarativen Anfrage. Objektorientierte Datenbanken erweitern die
Datenmodellierung durch die Objektidentität, Klassen, Klassenhierarchien und
Schemata. Bei den deduktiven Datenbanken ist ein Datenmodellierungsmechanismus erforderlich, während die objektorientierten Datenbanken eine deklarative Abfragesprache benötigen.
Die DOOD Sprachen können grob in zwei Arten klassifiziert werden:
Lossely coupled und Tightly coupled.
Bei der ersten Vorgehensweise werden als Abfragesprache für objektorientierte Datenbanken vornehmlich Datalog ähnliche Sprachen eingesetzt. Dies stellt jedoch nur
eine unbefriedigende Methode dar, da die resultierende Sprache aus zwei unterschiedlichen Teilen mit einer nicht vereinheitlichten Semantik besteht. Typische Beispiele sind IQL und Rock and Roll.
Die zweite Vorgehensweise ist eine elementare Methode, in der eine neue, einheitliche Logik vorgeschlagen wird, um die zugrunde liegende, objektorientierte Datenbanknotation zu formulieren. C-Logic, F- Logic und ROL gehören zu zweiten Methode. Zu den DOOD Sprachen wird natürlich auch Chimera gezählt, sie ist eine DOOD
Sprache mit einer zusätzlichen Komponente.
Frame basierte Modelle stützten sich im Wesentlichen auf Konzepte von Frames:
Frames entsprechen im semantischen Datenbankmodell den Objekttypen. Diese besitzen wiederum Eigenschaften (Meta-Attribute für den gesamten Objekttyp) und
Methoden.
F-Logic ist eine Sprache, die zwei maßgebliche Ansätze zur Erweiterung des relationalen Modells miteinander verbindet:
69
1.
Der objektorientierte Ansatz: Hierbei steht die Erweiterung des Datenmodells im
Vordergrund, es werden komplexe, strukturierte Objekte mit einer Objektidentität eingeführt, um die Hierarchie von angeordneten Klassen zuzuordnen.
2.
Der deduktive Ansatz: Durch diesen wird versucht, die Mächtigkeit der Datenbankabfragesprachen zu erweitern. Es können Daten durch Regeln definiert
werden, wodurch die Möglichkeit zu rekursiven Anfragen gegeben ist. Hierbei ist
bedeutend, dass der deduktive Ansatz mit einer deklarativen Semantik verbunden werden kann.
Eine weitere Eigenschaft von F-Logic ist, dass Vorteile des High-levelMethodenkonzepts (typisch für Framebasierte Sprachen) mit einer well-defined Semantik kombiniert werden.
Ziel ist es, eine logische Sprache mit objektorientierten Merkmalen zu schaffen.
Als nächste Sprache wird ROL betrachtet: Sie ist eine regelbasierte deklarative
Sprache für Definitionen und Manipulationen von Datenbanken und Datenbankabfragen. Sie besitzt die wesentlichen Merkmale von deduktiven und objektorientierten
Datenbanken, und unterstützt die Objektidentität, die Objektkomplexität, Klassenhierarchien und die mehrfache Vererbung. Deduktive Datenbanken mit einer deklarativen Semantik besitzen eine logische Schnittstelle.
Chimera repräsentiert die Integration von objektorientierten, aktiven und deduktiven
Datenbanktechnologien in einem einzigen Modell. Konkret bildet Chimera die Zusammensetzung aktiver und deduktiver sowie objektorientierter Datenmodelle und
deren Manipulationstechniken innerhalb eines definierten Rahmens (mit Regeln und
Operationen) ab.
Hier wird eine Regelsprache für aktive und deduktive Regeln entwickelt. Diese Sprache wird in einem objektorientierten Kontext integriert. Chimera unterstützt neben
atomaren Typen auch strukturierte Typen.
70
Tabelle 1: Aufbau der Strukturen der Sprachen und Migrationskonzepte
im Vergleich
F-Logic
AusgangsBasis
Traditionelle (relationale ) Datenbank
Erweiterung im Sinne
Migrations- des objektorientierten
Konzept und deduktiven Ansatzes mit deduktiven
Regeln und einer deklarativen Sprache
kombiniert mit der
High-level Methode
und well-defined Semantik
Manipulationsmethode
ROL
Chimera
Traditionelle (relatio- Objektorientierte Datennale) Datenbank
bank,
Deduktive Datenbank,
Aktive Datenbank
Erweiterung im Sinne
des objektorientierten
und deduktiven Ansatzes mit deduktiven Regeln und einer
deklarativen Sprache
kombiniert mit der
High-level Methode
und well-defined
Semantik
Integration der drei Methoden in einem Modell
durch Kombination der
deklarative
Regelsprachen und ,
Objektorientierte Programmiersprache und
Imperativen Regeln
Deklarativ
Deklarativ und Imperativ
Deklarativ
In objektorientierten Datenbanksystemen werden die in Zusammenhang mit der relationalen Datenbankmodellierung existierenden Probleme vermieden. Dies geschieht
hauptsächlich durch Integration der Verhaltens- und Strukturbeschreibung in einer
einheitlichen Objekttyp-Definition. Das anwendungsspezifische Verhaltensmuster,
das heißt die Operationen, werden zum integralen Bestandteil der Objektbank. Dadurch werden die umständlichen und ineffizienten Transformationen zwischen Datenbank und Programmiersprache umgangen. Vielmehr sind die den Objekten zugeordneten Operationen direkt ausführbar,- ohne detaillierte Kenntnis der strukturellen
Repräsentation der Objekte. Dies wird durch das sogenannte Geheimnisprinzip erreicht, wonach an der Schnittstelle eines Objekttyps eine Menge von Operationen
angeboten werden, für deren Ausführung lediglich die Signatur (Aufrufstruktur) bekannt sein muss.
Oft wird in diesem Zusammenhang auch von einer Objektkapselung gesprochen, da
die interne Struktur eines Objekts, also die strukturelle Repräsentation, dem Benut-
71
zer verborgen bleibt. Der Benutzer bekommt nur die den Objekttypen zugeordneten
Operationen zu sehen.
Objekte sind Grundbausteine, aus welchen objektorientierte Anwendungssysteme
aufgebaut werden. Jedes Objekt bildet eine eigenständige Einheit, die über Daten
(Attributwerte des Objekts) verfügt. Jedes Objekt wird durch seine datenspezifischen
Eigenschaften (Attribute) und durch sein funktionsspezifisches Verhalten (Methoden)
charakterisiert. Ein Attribut oder Merkmal eines Objekts ordnet jeder Instanz einen
bestimmten Datenwert aus einem definierten Wertbereich zu. Neben dem Attribut
müssen die Methoden festgelegt werden, die sich aus dem Kontext des Problembereichs ergeben.
Die Darstellung der Objekte in Programmen hängt des weiteren von den Möglichkeiten der Programmiersprache ab, insbesondere von der Definition der zugrunde
liegenden Datentypen (integer, string, real,.. ).
In F-Logic und Rol werden Standarddatentypen als Objekttypen verwendet. In Chimera werden zusätzlich zu diesen Datentypen strukturierte Typen wie set, list und
record unterstützt. Die Semantik des Set - Typs ist mengenorientiert, das heißt es
existieren im Gegensatz zu list, keine doppelten Elemente. Die strukturierten Datentypen lassen sich durch die rekursive Verwendung von atomaren und abstrakten Typen konstruieren. In Chimera enthalten die atomaren Typen zusätzlich OID’s.
Beim Entwurf und beim Aufbau von Informationssystemen ist es üblich, nicht nur einzelne Objekte mit ihren Ausprägungen zu beschreiben, sondern die Menge der Objekte zu klassifizieren, und diejenigen Objekte mit denselben Beschreibungselementen (Attribute, Methoden) in Kassen zusammenzufassen.
Durch die Abstraktion von einzelnen Objekten hin zu einer umfassenden Klasse,
werden gemeinsame Definitionen für Attribute und Methoden einmal pro Klasse festgelegt.
Eine Klasse beschreibt eine Menge von Objekten mit denselben Attributen und Methoden. Dies entspricht einem bekannten Prinzip bei der Modellierung von Datenbanken: Anstelle von einzelnen, konkreten Ausprägungen eines Objekts, werden
Objekte mit ähnlichen Eigenschaften und gemeinsamen Verhalten zu Instanzmengen
zusammengefasst. Die Abstraktion erlaubt es, von wenigen spezifischen Objektexemplaren auf eine Fülle von möglichen Objekten zu verallgemeinern.
Objekte und Klassen werden in den vorgestellten Sprachen zwar auf die gleiche Art
und Weise definiert, dennoch gibt es gewisse Unterschiede.
Beispielsweise wird in F-Logic eine Klasse als ein Objekt betrachtet. Der Grund
hierfür, ist die Notwendigkeit, nicht nur einzelnen Objekten Attribute zuzuordnen,
sondern der gesamten Klassen.
Dies geschieht auf zwei Arten:
1.
Zusätzlich zu den herkömmlichen Attributen einer Klasse werden statische Attribute für die Gesamtklasse, die jeweils nur einen Wert annehmen kann, definiert. Bei allen erzeugten Objekten werden diese Werte als Konstanten be-
72
2.
trachtet, die in den einzelnen Objekten nicht geändert werden können. Diese
Lösung entspricht der Vorgehensweise in C++.
Beim zweiten Ansatz werden Klassen als Objekte betrachtet. Diese Klassen
(Objekte) gehören dann wiederum der Klasse einer höheren Ebene an. Diese
Ebene ist die Metaebene, und Klassen dieser Ebene werden Metaklassen genannt. Jede Klasse kann hier eigene Attribute haben.
Wie bereits erläutert, wird in F-Logic zwischen Klassen und Objekten nicht unterschieden. Folglich besitzen Klassen und Objekte denselben Definitionsbereich (Domain). Dadurch ist ihre Unterscheidung erschwert und nur über Ereignisse im Programm möglich. Ein Objekt, das Element einer Klasse ist, kann selbst wiederum
Klasse einer anderen Menge von Objekten sein. In diesem Fall existieren mehrere
Metaklassen. Diese können jeweils nur einige Klassen umfassen. Im Extremfall gibt
es für jede Klasse verschiedene Metaklassen.
Der Vorteil ist die gute Darstellbarkeit von Klassenattributen, die nur auf eine Klasse
zutreffen. Der Nachteil ist die komplizierte Struktur der Metaebene selbst und die beschränkte Fähigkeit zur Darstellung von Metainformationen, die mehreren bzw. allen
Klassen gemeinsam sind.
Durch die Betrachtung “Klassen als Objekte“ entsteht eine Element - Klassenbeziehung. Diese wird in der F - Struktur von F-Logic als binäre Relation dargestellt.
F - Strukturen bestehen aus einer Menge von Objektkonstruktoren und Variablensymbolen. Ein Objektkonstruktor ist ein Funktionssymbol f mit einer zugehörigen
Stelligkeit n. Nur mit Hilfe von Objektkonstruktoren und Variablen lassen sich wie in
Algebra Terme konstruieren.
Jedes 0 stellige Funktionssymbol und jedes Variablensymbol bildet einen Term.
Durch Terme und Formeln lassen sich Regeln und Anfragen definieren. Jedoch sind
jene Terme, die wie in Algebra konstruiert sind, von ihrer Struktur her zu schwach für
bestimmte, komplizierte Abfragetypen.
Aus diesem Grund werden in F-Logic und in ROL logische Sprachen mit Higher order Methoden kombiniert.
Rol bildet die Entitäten (Entities) der realen Welt als Objekte ab. Zusätzlich werden
auch Values, Functor Objekte, OID’s, Set und Tupel als Objekte betrachtet. In ROL
werden Klassen durch eine Menge von Objekten definiert, die gemeinsame Attribute
teilen.
Aufgrund der Behandlung von value, Set, Functor objekt und Tupel als Objekte können in ROL fünf Arten von Klassen unterschieden werden.
Für jede Gesamtklasse wird jeweils ein Attribut definiert, diesem wird innerhalb der
Gesamtklasse auch nur ein Wert zugeordnet.
In ROL werden, genau wie in F-Logic, atomic Types unterstützt, jedoch wird hier im
Gegensatz zu F-Logic zwischen Objekten und Klassen unterschieden.
F-Logic enthält kein Set und hat daher eine komplizierte Semantik. In ROL hingegen
wird Set unterstützt und entsprechend einfach ist auch ihre Semantik.
73
Chimera ist eine Typ basierte Sprache. Zusätzlich zu atomaren Typen (OID’s gehören in Chimera ebenfalls zu den atomaren Typen) werden hier strukturierte Typen
unterstützt. Jeder strukturierte Typ besitzt eine Reihe von Standardoperationen, wie
Zugriffsoperatoren auf Elemente bzw. Komponenten und Vergleichsoperatoren.
Dadurch wird die Darstellung von komplexen Objekten möglich. Komplexe Typen
legen die möglichen Instanzen fest. Im Datenbankbereich beschreibt ein komplexer
Typ meistens eine Menge von Tupel. Zur Identifikation von Objekten kann dieser Typ
auch eine abstrakte Komponente, also ein Surrogat- Attribut, beinhalten.
Die eindeutige Identifikation von Objekten ist ein Grundpfeiler objektorientierter Softwareentwicklung, und wird mit Hilfe von Surrogaten realisiert. Surrogate sind Stellvertreter. Mit einem Surrogat wird die direkte Darstellung von Anwendungsobjekten
im relationalen Modell bezeichnet. Dieser ist der eindeutige Identifikationsschüssel
für ein Objekt und ist unveränderbar und unabhängig von den Objekteigenschaften.
F-Logic beschäftigt sich mit F Strukturen, die aus dem Funktionssymbol f mit Stelligkeit n bestehen. Wenn jedes 0 stellige Funktionsymbol und jedes Variablensymbol
ein Term ist, dann wird f( t1,..., tn) ebenfalls zu einem Term.
In F-Logic werden diese Terme (genau wie Objektnamen und Variablennamen) IDTerme genannt. Diese komplexen ID-Terme werden durch Funktionssymbole und
andere ID-Terme erzeugt, und zur Identifikation von Objekten und Klassen benutzt.
In ROL werden auch die OID’s durch Terme und Functor Objekte abgebildet. Die
Menge der OID’s wird hier als OID- Klasse bezeichnet, und repräsentiert die Entitäten der realen Welt. OID- Klassen müssen explizit durch Klassendefinition definiert
werden.
In Chimera stellt der OID Typ eine Besonderheit dar. Er kann nicht explizit benutzt
werden, das heißt, wenn ein Attribut auf ein Objekt einer anderen Klasse verweisen
soll, wird der entsprechende Klassename herangezogen, wobei aber intern dafür der
OID Typ verwendet wird.
74
Tabelle 2 : Objekte, OID’s und komplexe Objekte in F-Logic, ROL und Chimera
im Vergleich
Sprachen
F-Logic
Objekt
ROL
Chimera
Abstraktion der
Entitäten der realen
Entitäten der realen
Entitäten der realen
Welt
Welt,
Welt
zusätzliche Betrachtung zusätzliche Betrachtung von
von
Value, OID, Functor
Value, OID, Klassen,
Attribute und Methoden Objekt, Set und Tupel
als Objekte
als Objekte
OID
Term / ID-Term
Term /Functor Objekt
Festlegung erfolgt
bei Objektgenerierung
Komplexe
Objekte
Kein Set
Set
Typ
In objektorientierten Programmiersprachen gibt es zur Steuerung der Vererbung folgende Methoden: Is-a-Hierarchie, Spezialisierung, Typhierarchie, Klassenhierarchie
und die Generalisierung.
Dabei stellen Is-a-Hierarchie und Spezialisierung Integritätsbedingungen dar. Die
Typhierarchie organisiert Klassen anhand ihrer zugeordneten Zustandstypen, und die
Klassenhierarchie ist eine reine Implementierungshierarchie ohne eine weitere, streng
formale Semantik.
Klassenhierarchie: Eine Klasse K ist spezieller als eine Klasse K’, wenn die Objektmenge von K Teilmenge der Objektmenge von K’ ist. K wird dann Unterklasse von K’
genannt, K’ Superklasse von K, [Heuer, 93]. Diese Methode wird in F-Logic verwendet.
Is-a-Hierarchie: Eine Klasse K ist spezieller als eine Klasse K’, wenn sie in der Klassenhierarchie in dieser Beziehung stehen und die zu K und K’ gehörenden Zustandstypen in der Typhierarchie ebenfalls in dieser Beziehung stehen, [Heuer, 93].
Die Generalisierung stellt eine weitere Art der Hierarchie dar. Generalisierungen ermitteln bei vorgegebenen Unterklassendomänen die Domäne der Superklasse. Die
75
Domäne der Superklasse ist bei der Generalisierung die Vereinigung der Objektmenge mit der Unterklasse.
Die Sprachen F-Logic, ROL und Chimera unterstützen die Vererbungsmethoden auf
verschiedene Weise: F-Logic benutzt das Konzept der Klassenhierarchie, während
ROL die Is-a-Hierarchie anwendet und in Chimera die Generalisierung eingesetzt
wird.
Tabelle 3: Klasse und Klassenhierarchie der Sprachen im Vergleich
Sprachen
F-Logic
Klasse
Hierarchie
ROL
Chimera
Metaklasse
Metaklasse,
Metaklasse,
Betrachtung von Trennung von Klasse Komponenten der
und Objekt
Klasse: Superklasse,
Objekten als Klasse
Attribute, Operationen, Triggers, Key
Klassenhierarchie
Is-a-Hierarchie
Generalisierung
Bei der Objektorientierung stellen Methoden Funktionen dar, die im Kontext eines
Objektes aufgerufen werden, und dabei eventuell eine Zustandsänderung vornehmen bzw. ein Resultat zurückliefern.
In F- Logic werden nur die funktionalen Komponenten von Methoden modelliert. Die
Methoden werden semantisch durch partielle Funktionen wieder gegeben, und als
Elemente des Universums betrachtet. Das heißt, Methoden werden wie Objekte mit
Hilfe von ID-Termen referenziert.
Objekte, Klassen sowie die dazugehörenden Attribute können durch Methoden abgefragt und manipuliert werden. Diese Methoden werden als Instanz Methoden bezeichnet.
In ROL sind die Methoden regelbasiert und müssen definiert, und in den Klassen
gekapselt werden.
In Chimera müssen alle Objekte einer Objektklasse angehören. Definitionen von
Struktur und Verhalten (Typdefinitionen) folgen direkt aus der Klassendefinition. Methoden sind auch Funktionen (Attributklassen), die die gesamte Klasse in einem ein-
76
zigen Wert abbilden. Durch Operationsklassen kann die gesamte Klasse manipuliert
werden.
Der Begriff „Deklarative Sprache“ ist ein Oberbegriff für logisch basierte, relationale
Sprachen. Die logische Zustandsbeschreibung ist kennzeichnend für deklarative
Sprachen. Demgegenüber erfordern „Imperative Sprachen“ die Vorgabe einer Ablaufbeschreibung (durch Constraint und Trigger). Deklarative Regeln sind ein wesentliches Prinzip, um die Modellierung von Problemen, Programmierung, Ausführung und Wartung von Programmen zu unterstützen.
F-Logic kombiniert die logische Sprache mit der Higher-order Methode. Die Highorder Syntax von F-Logic kann durch ein Prädikat der Logik erster Stufe gleichwertig
dargestellt werden.
In F-Logic können beispielsweise High-order Konzepte von Methoden und Klassen
durch ID-Terme repräsentiert werden.
Rol unterstützt Higher-order Regeln und Abfragen (Queries). Eine Higher-order Regel wird dynamisch in eine Regel erster Stufe umgeschrieben.
In Chimera werden deklarative Ausdrücke über eine zweiwertige logische Sprache
definiert. Jede klassische logische Sprache besteht syntaktisch aus Termen und
Formeln. Terme haben dabei die Bedeutung von Subjekten, welche entweder durch
konkrete Werte oder Objekte notiert werden. Formeln machen Aussagen über Subjekte, welche wahr oder falsch sein können.
Die Superklasse vererbt Attributswerte und Methoden an die Unterklasse. Neben
dieser Vererbung ist es auch möglich, diese Eigenschaften in einer Unterklasse neu
zu definieren. In diesem Fall findet die in der Unterklasse definierte Eigenschaft Anwendung. Das Überschreiben (Overriding) wird von allen Sprachen (F-Logic, ROL
und Chimera) unterstützt. Blockieren wird aber nur von ROL und Chimera ermöglicht.
Kapselung wird von der Bezeichnung abstrakter Datentypen abgeleitet. In einer objektorientierten Datenbank kapseln Objekte Daten und Methoden ein. Durch Kapselung können Objektinformationen nur durch speziell für dieses Objekt definierte Methoden manipuliert werden.
77
Tabelle 4: Manipulations- - und Auswertungsvorschriften der Sprachen im
Vergleich
Sprachen
F-Logic
ROL
Chimera
unterstützt
unterstützt
unterstützt
Überschreiben
Ja
Ja
Ja
Blockieren
Nein
Ja
Ja
Kapselung
Nein
Ja
Ja
Constraints stellen sogenannte Integritätsbedingungen (IBs) dar, die inkonsistente
Datenbankzustände beschreiben. Zur Definition dieser IBs werden deduktive Regeln
verwendet, die im Gegensatz zu anderen deduktiven Regeln eine besondere Interpretation haben. Diese Interpretation heißt “denial form“ und bedeutet, dass eine Inkonsistenz eintritt, sobald eine Wertbindung für den deklarativen Ausdruck im Regelkopf erfolgt. Im Normalfall ist es bei deduktiven Regeln erwünscht, dass Wertbindungen jedoch eine negative, unerwünschte Bedeutung.
Trigger werden gebraucht, um innerhalb einer bestimmten Zeit eine bestimmte Reaktion auszulösen. Dafür wird das Datenmodell um Regeln zu Definition von DBMS Verhaltensmustern erweitert. Solche Regeln werden in diesem Kontext aktive Regeln
genannt.
Tabelle 5: Unterstützung von Manipulationsmethoden der Sprachen im
Vergleich
Sprachen
F-Logic
ROL
Chimera
Constraints
Nein
Ja*
Ja
Trigger
Nein
Nein
Ja
Konzepte
78
* wird hier als Integritätsbedingung realisiert
Schema Browsing ist die Fähigkeit zur Abfrage von Metadaten im Datenbankschema
ohne einen expliziten Hinweis an die Datenbank.
Higher-order-Syntax bezeichnet Regeln, die syntaktisch nicht mit einer Logik erster
Stufe ausgedrückt werden können.
Collection as 1st Class: Verbindet Attribute, die gemeinsame Eigenschaften haben,
zu einer Menge oder einer Klasse von Attributen.
Tabelle 6: Deklarative- und objektorientierte Unterstützung in den Sprachen im
Vergleich
Spra-
F-Logic
ROL
chen
Chimera
Schema Browsing
Ja
Ja
No
High-order-Syntax
Ja
Ja
No
Collection as 1st
Class
Ja**
Ja**
Ja**
**objektorientierte Unterstützung
79
6. Ergebnisse
Im Folgenden werden die in Kapitel 5 analysierten Gemeinsamkeiten und Unterschiede der drei Sprachen F-Logic, ROL und Chimera diskutiert und anschließend in
Abschnitt 6.2 bewertet.
80
6.1 Diskussion
ROL ist eine regelbasierte Sprache, die auf Strukturen von F-Logic aufbaut. Zuerst
werden die Objektidentitäten festgelegt, wobei values, Functor Objekte, OID’s, Set
und Tupel in ROL als Objekte betrachtet werden. Mit value sind string, integer, real,
char und boolean gemeint. In ROL bilden OID’s die Entitäten der realen Welt ab. Mit
Functor Objekt wird die Beziehung zwischen den Objekten dargelegt. Die jeweilige
Betrachtungsart der einzelnen Objekte ist abhängig von der zugrunde liegenden
Sichtweise der objektorientierten Datenbanken. Objekte mit gemeinsamen Attributen
bilden Klassen, denen ein Attributswert zugeordnet wird. Dieser stellt das Klassenattribut dar und liefert einen Wert.
Zwar werden, wie in ROL und Chimera, auch in F-Logic Klassen als Metaklassen
bezeichnet, da hier aber Objekte und Klassen gleich betrachtet werden, ist das
Schema von F-Logic viel komplizierter als das von ROL. Attribute werden in ROL als
Funktionsterme (Functor Objekt) ausgedrückt.
In F-Logic hingegen werden Attribute durch ID-Terme dargestellt. Aufgrund der Unterstützung von Set in ROL ist auch die Semantik von ROL einfacher als die Semantik von F-Logic.
Functor Objekte werden benutzt, um Typen mit gleicher Klassendefinition zu bilden.
Beispiel für die Anwendung in F-Logic:
Person[name à string,
Ageàinteger,
Person=> person]
employee:: Person
stephan: employee
alex:Person
karin:Person
32:integer
“Stephan” :string
stephan[nameà”Stephan”,
ageà32,
parentsàà{alex, karin}
wobei person, employee, integer und string in diesem Beispiel Klassen sind, und
stephan, alex, karin, 32, und “Stephan“ Objektidentifikatoren darstellen. Der Zustand
employee:: Person bedeutet, dass employee eine Unterklasse von Person ist, und
stephan: employee bedeutet dass stephan eine Instanz von Person ist.
81
Dasselbe Beispiel für die Anwendung in ROL:
Schema
person[name=>string,
age=>integer,
parents=>{person}]
employee isa person
Fakt
alex:person
karin:person
stephan:employee[nameà”Stephan”,
ageà32,
parentsà <alex, karin>]
Person, employee, integer und string sind Klassen; stephan, karin und alex sind die
Objektidentifikatoren und <alex, karin> sind partielle Set Terms.
Beispiel für eine Anwendung in Chimera:
Zur Darstellung der Klassendefinition in Chimera mit den zusätzlichen Komponenten
Trigger und Constraint wird ein komplexeres Beispiel herangezogen.
define object class employee
superclass person
attributes
emplNr: integer,
mgr: employee,
salary:integer,
dependents:set-of (employee)
costraints
exceedsMgrSalary
operations hire(in Mgr:employee, in StartSalary:integer),
fire( )
triggers
adjustSalary
end
Die Klassenhierarchie in F-Logic ist durch Unterklassendefinition realisiert. In ROL
dagegen wird die Klassenhierarchie durch das isa –Prinzip umgesetzt, während sie
in Chimera durch Superklassendefinition erfüllt wird.
82
Wie bereits erwähnt ist die Syntax von F-Logic aufgrund der mehrfachen Metaklassendefinition komplizierter als in ROL.
Die Definition von Klassen bezieht sich in ROL ebenfalls auf die Definition von Metaklassen, jedoch werden in ROL Klassen und Objekte getrennt betrachtet. Dadurch
wird verhindert, dass eine Klasse als ein Objekt wiederum einer Klasse höherer Ebene angehört. In Chimera ist die Klassendefinition von ihrer Signatur und Implementation getrennt. Die Signatur beschreibt die Klassenstruktur, und insbesondere ihre
gesamten Komponententypen.
In Rol sind Objekte und Klassen unterschiedlich definiert und funktionieren auch auf
zwei verschieden Ebenen. Diese Ebenen werden Schema und Instanz genannt. In
der Schemaebene werden Klassen und deren Attribute sowie die Klassenhierarchie
(subclass) definiert. In der zweiten Ebene werden durch Fakten und Regeln extensionale- und intensionale Informationen über Objekte erzeugt.
Da F-Logic keine direkte Unterstützung für Relationship bietet, wie sonst für deduktive Sprachen üblich, kann man sagen, dass der Schwerpunkt von F-Logic eher auf
den objektorientierten Spracheigenschaften liegt.
F-Logic kann nur eine monotonic multiple Attributsvererbung unterstützen. Im Gegensatz zu ROL und Chimera wird das Überschreiben und Blockieren von Attributen
auch nicht ermöglicht.
Ein weiteres wichtiges Merkmal von ROL ist die Functor Klasse, diese wird eingesetzt, um die Generalisierung von Klassen und Relationen aufzubauen. Relationships können direkt durch Functor Objekte repräsentiert werden. Diese können Attribute besitzen und auch als Attributswerte benutzt werden. Zusätzlich können functor
Objekte Sets beinhalten; Dadurch sind sie mächtiger als ID-Terme in F-Logic.
Die Attributsvererbung in ROL, Chimera und F-Logic ist nicht identisch. ROL unterstützt die non-monotonic multiple Attributsvererbung, während in F-Logic und Chimera eine monotonic multiple Attributsvererbung möglich ist.
Bei einer non-monotonic Vererbung, ist die Vererbung algorithmisch definiert und
nicht in die Semantik eingebaut. Unterklassen in F-Logic, ROL und Chimera können
Attributsdeklarationen von Superklasse erben und auch überschreiben. Blockieren
wird nur in ROL und Chimera ebenfalls unterstützt.
In ROL sind einige objektorientierte Merkmale, wie regelbasierte Methoden und Kapselung integriert, sodass ROL im Vergleich zu F-Logic eher als eine deduktive, objektorientierte Sprache betrachtet werden kann. ROL unterstützt OID’s, komplexe
Objekte, die Klassenhierarchie sowie non-monotonic multiple Struktur- und Verhaltensvererbung mit den Funktionen ’Überschreiben und Blockieren’.
Im Gegensatz zu F-Logic und ROL unterstützt Chimera ein breites Typsystem. Zusätzlich werden hier Typen als atomic und strukturiert klassifiziert.
Ein weiterer wichtiger Punkt in Chimera ist die eins- zu- eins Beziehung zwischen
Klassen und Objekttypen. Wie bereits erwähnt, werden in Chimera Typen und Klassen unterstützt. Mit dem Begriff Typ werden Objekte mit ähnlicher Struktur und Ver-
83
halten bezeichnet. Mit der Klasse wird die Mitgliedschaft dieser Objekte in einer gemeinsamen Instanzmenge gezeigt.
Zusätzlich zur Basisstruktur und dem Verhaltenskonzept von Attributen und Operationen bietet Chimera - im Gegensatz zu F-Logic und ROL -, zwei weitere Komponenten an: Constraint und Trigger.
Bei Betrachtung von F-Logic und ROL kann festgestellt werden, dass beide Sprachen über einen vergleichbaren Aufbau verfügen, dass heißt, die relationalen Datenbanken wurden um zwei wichtige Ansätze, und zwar dem objektorientierte Ansatz
und dem deduktive Ansatz erweitert.
Die wesentlichen Unterschiede zwischen den Sprachen liegen in erster Linie in der
Definition des objektorientierten Ansatzes, insbesondere in der Klassendefinition. FLogic, ROL und Chimera basieren auf einer logischen Sprache, die durch Terme und
Formeln konstruiert wird.
Dabei gibt es jedoch auch einen Unterschied: In F-Logic und ROL wird die logische
Sprache im Gegensatz zu Chimera mit der Higher-order Methode kombiniert.
Chimera wiederum wurde durch Zusammensetzung aktiver und deduktiver sowie
objektorientierter Datenmodelle und deren Manipulationstechniken innerhalb eines
definierten Rahmens entwickelt.
Größte Gemeinsamkeit zwischen diesen drei Sprachen ist, dass alle drei Sprachen
die Objektorientierung als Basismodell haben und die deklarative Abfrage unterstützten. F-Logic ist im Gegensatz zu ROL und Chimera jedoch eine nicht typisierte
Sprache mit einer komplizierten Syntax und Semantik.
Ein weiterer Unterschied besteht in der Klassendefinition, die sich in F-Logic auf
mehrfache Metaklassen bezieht, im Gegensatz zu ROL, wo nur statische Metaklassen existieren. Durch die Unterstützung von Set und Tupel ist ROL zudem mächtiger
als F-Logic.
84
6.2 Zusammenfassung und Bewertung
Die Sprachen F-Logic, ROL und Chimera sind deduktiv und objektorientiert. F-Logic
und ROL wurden durch Erweiterung relationaler Datenbanken um das objektorientierte und deduktive Datenmodell konstruiert. Chimera wurde durch Integration von
objektorientierten-, deduktiven- und aktiven Datenbanktechnologien entwickelt. Allen
Sprachen liegt ein objektorientiertes Datenmodell als Basismodell zugrunde, und alle
Sprachen setzten deduktive Regeln mit einer deklarativen Abfragesprache ein.
Nach eingehender Analyse der drei untersuchten Sprachen, kann festgehalten werden, dass alle Modellierungseigenschaften mit Ausnahme von Blockieren und Kapselung unterstützt werden. Diese zwei Eigenschaften können nur in ROL und Chimera durchgeführt werden.
Die Sprachen unterscheiden sich im Wesentlichen in ihrer Klassendefinition, die bei
allen auf der Metaklassendefinition basiert. In allen Sprachen werden nicht nur den
einzelnen Objekten Attribute zugeordnet, sondern der gesamten Klasse. Dies geschieht in allen drei Sprachen unterschiedlich: In F-Logic durch mehrfache Metaklasse, in ROL durch statische Attribute und in Chimera durch Definition von Klassen und
Typen mit einer eins - zu - eins Beziehung.
Dadurch hat F-Logic die komplizierteste Syntax von allen betrachteten Sprachen. Die
Syntax von ROL wird durch Trennung von Objekten und Klassen vereinfacht. Aufgrund der Einführung von Typdefinitionen hat Chimera im Vergleich zu F-Logic und
ROL die zweckmäßigste Syntax.
Um Informationen zu manipulieren, werden deklarative Ausdrücke benutzt. In FLogic und ROL werden diese Ausdrücke mit einer logischen Sprache, die mit Higherorder Methode kombiniert ist, verwendet. In Chimera bilden die deklarativen Ausdrücke Komponenten von aktiven und deduktiven Regeln sowie Operationen. Daher
bietet Chimera die Möglichkeit, Informationen leichter durch Regeln und Operationen
zu beschreiben.
In Chimera gibt es außerdem noch zwei zusätzliche Komponenten, Constraints und
Triggers, die die Beschreibung von Ereignissen, die blockiert oder ausgelöst werden
müssen, erleichtert.
Fazit:
Unter kritischer Beurteilung der beschriebenen Gemeinsamkeiten und Unterschiede
sowie der Analyse der einzelnen Vor- und Nachteile können folgende Aussagen zusammengefasst werden:
•
F-Logic besitzt im Vergleich zu ROL und Chimera die komplizierteste Semantik,
und stellt zudem auch keine mächtige Sprache dar.
85
•
Die Datenmanipulationsmethode ist in Chimera leichter und einfacher zu beschreiben als bei ROL und F-Logic.
•
Chimera ist durch Integration einer zusätzlichen dritten Komponente, und zwar
der aktiven Datenbanktechnologie noch fähiger und attraktiver für die Anwendung im Bereich deklarativer logischer Sprachen.
86
Literatur Verzeichnis
[AK,89]
[S. Abiteboul and P. C. Kanellakies. Object identity as a query
Language primitive, In.Proc.ACM SIGMOND Intel.Conf. An Management of Data, pp 159-173,1989]
[AL]
[J. Angele, G. Lausen. Ontologies in F-Logic University of
Freiburg]
[ASL ]
[A. M. Alashgur, S. Y. W. Su, H. Lam. A Query Language for
Manipulation object-oriented Databases University of Florida]
[Behrend, 99]
[A. Behrend. Effiziente Materialisierung regeldefinierter Daten,
1999]
[BFPWDA,95]
[M. Baraja, A. Fernandes, N. Paton, A. Abdelmoty. Design and
Implementation of Rock&Roll. A deductive object-oriented database system, 20(3): 185-211,1995]
[BOS, 91]
[P. Butterworth, A. Ofis, J. Stein. The Gemstoneobject Database
Managemant System, ACM-34, pp 64-77]
[CBS, 02]
[T. Connoly, C. Begg, A. Strachen. Datenbanksysteme, Addison
Wesley 2002]
[CF, 92]
[S. Ceri, P. Fraternali. Designing Database Applications with
Objects and Rules: The IDEA Methodology, Addison Wesley
1992]
[CM, 94]
[S. Ceri, R. Manthey. Chimera: A Modell and Language for Active
DOOD Systems, 1994, ESPRIT Project number 6333 (IDEA)]
[CW, 98]
[W. Chen, D. S. Warren. C-Logic of complex Objects, Departement of Computer Science, 1998]
[CW,98]
[W.Chen and D. S. Warren C-Logic for complex objects In
Proc.ACM Symp. on Principels of Database Systeme, pp396-378,
Philadelphia, Pennsylvania]
[Däßler, 03]
[R. Däßler. My SQL 4 bhv- Verlag, 2003]
87
[F, 03]
[B. Freitag. Algebraische und logische Deduktionssysteme, Informationsmangement; Universität Passau, 2003].
[Glausch]
[Glausch:Einführung in die Farme-Logik, Quelle: aus Internet]
[GR, 03]
[R. Gegusch, U. Rentsenhand. Wrapping und Mediation von
Web- Quellen mit Florid, TU Berlin, 2003]
[Heuer, 92]
[A. Heuer. Objektorientierte Datenbanken Konzepte - ModelleSysteme Addison Wesely 1992]
[KL, 97]
[M. Kifer, G. Lausen. A Higher-order Language for Reasoning
about Objects, Inheritance und Schema, University of Mannheim,
1997]
[KG,90/94]
[W. Kießling, U. Güntzer: Deduktive Datenbanken auf dem Weg
zur Praxis, Informatik Forschung und Entwicklung, Heft 5, 1990,
S. 177-187 Special Issue on Prototypes of Deductive Database
Systems, The VLDB Journal, vol. 3(2), 1994.]
[KLW, 95]
[M.Kifer, G.Lausen and J. Wu. Logical fundation of objekt-oriented
and frame based languages, Journal of ACM, 42(4): 741-843, Juli
1995]
[LO, 91]
[Y. Lou, M. Ozonoglu. LLO: A deductive Language with methods
and method inheritance, In Proc. ACM SIGMOND Intel. Conf. on
Managmement of Data, pp 198-207, Denver, Colorado,1991]
[Lui 96]
[M. Lui. Deductive Object Based Language Information System
vol.21 pp 431-457 ]
[Lui 96]
[M. Lui. The ROL Deductive object Base Language Workshop
1996 IEEE-CS pp 122- 131]
[Lui 96]
[M. Lui. An Overview of ROL Language, World Scientific Publishing Co. pp 451- 456]
[Lui, Ya 97]
[M. Lui. Weidong Ya, Query Processing in the ROL System IDEA
97, Montreal, Canada, IEEE-CS pp 327-336]
[Lui 98]
[M. Lui. ROL2: A Real Deductive object-oriented Database Language, Spring Verlag, pp 302-315]
[Lui, 99]
[M. Lui. Toward the Real Deductive object-oriented Database
Language, University of Regina, 1999]
88
[Lui 99]
[M. Lui. Overview of the ROL2 Deductive object-oriented Database System, University of Regina, August 1999, IEEE-CS pp
63-72]
[Lui 00]
[[M. Lui. designed Implementation of the ROL System, Journal of
Intelligent Information System Vol. 14 pp 1-21]
[Lui 00]
[M. Lui. journal of intelligent Information system vol.14 pp 1-21]
[Lui 99]
[M. Lui. Deductive Database Language, University of Regina,
1999]
M, 86]
[D. Maier. A. logic for objects Technical Report CS{E 86-012,
Oregon Graduate Center, Beaverton, Oregon,1986]
[MW 00]
[A. Meier, T. Wirt. Objektorientierte und Objektrelationale Datenbanken, dpunkt Verlag 2000]
[Raymans, 02]
[Heine- Gerad Raymans, SQL Addison Wesely 2002]
[S 99]
[S. Schuber, Ein passive Rule Prototyping Tool für Chimera]
[SP]
[P. Sampaio, N. Paton. Deductive Queries in ODMG
Databases: the DOQLc Approach, Department of Computer
Science University of Manchester]
[W, 99]
[W. Wahlster: Expertensysteme und deduktive Datenbanksysteme; Universität des Saarlandes Fakultät - Informatik 1999]
89