Objektrelationale Datenbanken

Schriftliche Ausarbeitung zum Thema:
Objektrelationale Datenbanken
im Rahmen des Proseminars
„Objektorientierte Datenbanken“,
an der GH-Siegen,
WS 1999/2000
von Tobias Fries, Hery L. Ramanoarisoa, Thouraya Ben Kali, Markus Paltian
Übersicht
1. Motivation des objektrelationalen Datenbankkonzeptes.....................................................3
1.1. Allgemeine Anforderungen an Datenbanksysteme............................................................3
1.2. Nachteile relationaler und objektorientierter Datenbanksysteme.......................................4
1.2.1. Nachteile relationaler Datenbanksysteme................................................................4
1.2.2. Nachteile objektorientierter Datenbanksysteme......................................................6
1.3. Resultierende Anforderungen für objektrelationale Datenbanksysteme............................7
2. Merkmale objektrelationaler Datenbanksysteme.................................................................8
2.1. Erweiterung relationaler Datenbanksysteme um abstrakte Typen...................................10
2.2. Objektorientierte Erweiterungen......................................................................................10
3. Beispiele..................................................................................................................................12
3.1. Strukturen und Mengen....................................................................................................12
3.2. Hierarchien und Erbungsmechanismen............................................................................14
4. Der neue Standard für objektrelationale Datenbanken SQL:1999..................................17
5. Vergleich unterschiedlicher Produkte.................................................................................19
5.1. Informix Universal Server................................................................................................19
5.2. Oracle 8............................................................................................................................20
5.3. IBM DB2..........................................................................................................................20
6. Fazit.........................................................................................................................................22
7. Literatur.................................................................................................................................23
2
1. Motivation des objektrelationalen Datenbankkonzeptes
Obwohl mit den relationalen Datenbanken ausgereifte, leistungsfähige und theoretisch untermauerte Systeme vorliegen, ist der alleinige Einsatz des relationalen Datenbankkonzeptes in vielen Anwendungsfällen nicht befriedigend, da die Existenz von nur einfachen Datentypen Modellierungen komplexer Aufgabenstellungen nicht unterstützt.
Objektorientierte Datenbanken sind zwar genau hierzu zu in der Lage, können aber nicht ohne
weiteres Datenbestände aus den älteren relationalen Systemen übernehmen. Außerdem stellen
objektorientierte Datenbanken keinen vollständigen Ersatz für relationale Datenbanken dar, da
sie in den klassischen Anwendung für relationale Systeme, also Verwaltung großer, einfach
strukturierte Datenbestände, gegenüber diesen Systemen konzeptionell im Nachteil sind.
Objektrelationale Datenbanksysteme wurden entwickelt um die Vorteile des objektorientierten
und des relationalen Konzeptes zu vereinen und dabei deren jeweilige Nachteile auszuschalten.
1.1. Allgemeine Anforderungen an Datenbanksysteme
Datenbanken dienen zur strukturierten und effizienten Speicherung und Verwaltung von Daten
in Anwendungsfällen, bei denen das einfache Speichern von Daten über ein Dateisystem nicht
mehr ausreichend ist.
Die in einer Datenbank zu speichernden Daten werden durch ein Datenmodell definiert, indem
deren Struktur, Operationen auf diesen Daten und Konsistenzregeln festgelegt werden.
Die Daten in der Datenbank können nur über das Datenbank-Management-System (DBMS) eingefügt, gelesen, geändert oder gelöscht werden. Das DBMS ist ein Softwaresystem, dass die einheitliche Beschreibung und sichere Bearbeitung einer Datenbank ermöglicht. Es erfüllt unter
anderem die folgenden Anforderungen:
•
Das DBMS sorgt für Physische Datentunabhängigkeit: Änderungen an den hardwaremäßigen Speicherstrukturen und Zugriffspfaden sind für Anwenderprogramme und Queries
unsichtbar, verändern also weder die logische, noch die externen Sichten
•
Das DBMS sorgt für Logische Datentunabhängigkeit: Änderungen an der logischen Sicht
(an den Typendefinitionen, Datenbankschemata) sind für Applikationen und Queries unsichtbar, diese arbeiten nur mit externen Sichten
•
Das DBMS garantiert Korrektheit der Daten (Einhaltung der definierten Konsistenzregeln)
•
Das DBMS garantiert Datensicherheit, d.h. Korrektheit bei fehlerhaftem Ablauf einzelner
Anwendungen und Systemabsturz
3
•
Das DBMS garantiert Korrektheit im Mehrbenutzerbetrieb (concurrency control)
•
Das DBMS bietet feinkörnige Zugriffskontrolle.
•
Das DBMS sorgt für Redundanzvermeidung bzw. –minimierung: Gleiche Daten werden
möglichst nicht mehrfach abgespeichert. Dadurch wird nicht nur Einsparung von Speicherplatz erreicht, sondern auch die Aktualisierung der Daten wesentlich vereinfacht
•
Das DBMS unterstützt spontane Anfragestellung (ad-hoc Queries). Anfragen werden
vom System optimiert
1.2. Nachteile relationaler und objektorientierter Datenbanksysteme
Die im letzten Abschnitt erwähnten Anforderungen an Datenbanksysteme werden, mit Ausnahme des fehlenden Sichtenkonzeptes bei objektorientierten Systemen, grundsätzlich von relationalen sowie objektorientierte Implementierungen erfüllt. Nichtsdestotrotz hat jeder Datenbanktyp,
abhängig von der Beschaffenheit der Datenbankanwendung, seine individuelle Vor- und
Nachteile.
Allgemeingültig, also für beliebige Aufgabenstellungen gleichermaßen, kann keines der beiden
Konzepte empfohlen werden. Vielmehr muss abhängig von der Datenbankanwendung entschieden werden, welchem der Beiden im speziellen Falle der Vorzug zu geben ist. Um diesen Umstand zu verdeutlichen, findet sich im folgenden eine Zusammenstellung der wichtigsten und
schwerwiegensten Nachteile der jeweiligen Konzept.
1.2.1. Nachteile relationaler Datenbanksysteme
Die grundlegende Einschränkung relationaler Datenbanken ist Tatsache, dass diese von Hause
aus nur einfache Datentypen anbieten und darüber hinaus nicht die Neudefinition von benutzerdefinierten Datentypen gestatten. Allein die Fähigkeit zum Umgang mit komplexen Datentypen
würde den Datenbankentwurf in viele Fällen vereinfachen.
Für komplexe Aufgabenstellung hat sich die objektorientierte Modellierung durchgesetzt. Objektorientierte Konzepte werden aber von relationalen Datenbanken in keiner Weise unterstützt,
wodurch der Datenbankentwurf in solch einem Fall extrem umständlich wird.
Ist ein solches komplexes, objektorientiertes Modell einmal in das Relationenschema umgesetzt
worden, so können selten alle Attribute eines Objektes aus dem Ausgangmodell in einer Tabelle
untergebracht werden. Vielmehr ist es notwendig ein Objekt auf mehrere Tabellen aufzuteilen.
Sollen in solch einem Fall durch eine Anfrage alle Attribute dieses Objektes ermittelt werden, so
sind hierzu explizite Join-Operationen notwendig. Für komplexe Aufgabenstellungen bei denen
objektorientierte Modellierung angebracht ist wird also nicht nur der Datenbankentwurf kompli4
zierter, sondern in vielen Fällen müssen auch die späteren Anfragen an die Datenbank umständlicher formuliert werden.
Relationale Datenbanken kennen keine Objektidentität. Dieses Merkmal objektorientierter Datenbanken und Programmiersprachen erlaubt die Identifizierung eines Objektes selbst dann,
wenn all seine Attribute in ihrem ursprünglichen Wert verändert worden sind. Wird ein Objekt in
einem Tupel einer relationalen Tabelle gespeichert, so verliert es seine Identität, also die Möglichkeit es von außen eindeutig zu identifizieren sobald sein Primärschlüssel geändert wird.
Von einer rein relationalen Datenbank wird auch Persistenz durch Erreichbarkeit nicht unterstützt. Bei diesem Persistenzkonzept werden alle Objekte in die Datenbank aufgenommen, die
von einem bereits gespeicherten Objekt referenziert werden. Da auf diese Weise das Persistenzmerkmal von Objekt zu Objekt weitergegeben wird, ist z.B. das Abspeichern oder Löschen einer
kompletten Listen mit nur einer Operation auf dem Listenkopf möglich. Bei relationalen Datenbanken muss man hierzu explizit jedes Element Speichern oder Löschen.
Ein weiteres Manko ist die geringe Mächtigkeit von SQL, der Datenbankprogrammiersprache
relationaler Systeme. Anspruchsvolle Berechnungen lassen sich besser oder ausschließlich in
einer externe Programmiersprache verwirklichen. Auch ist es nicht möglich benutzerdefinierte
Prozeduren oder Funktionen in SQL zu erstellen. Muss im Anwendungsfall auf eine externe
Programmiersprache ausgewichen werden, so kommt es beim Datenaustausch zwischen Datenbank und externer Programmiersprache zum sogenannten Impedance Mismatch. Dieser Begriff
beschreibt den Umstand das die Typsysteme von Datenbank und Programmiersprache sich unterscheiden. So muss das externes Programm dafür sorgen, dass die von der Datenbank gelieferten Daten in das Typsystem der Programmiersprache umgesetzt werden. Umgekehrt müssen die,
in die Datenbank zu transferierenden, Daten zuvor in einen Datenbankkonformen Typen konvertiert werden. Dieser zusätzliche Programmieraufwand ist nicht nur zeitraubend, sondern zudem
eine unerwünschte mögliche Fehlerquelle.
Abschließend nochmals eine Auflistungen der größten Schwächen relationaler Systeme:
•
keine komplexen Typen
•
keine Objektorientierung
•
keine Objektidentität, Primärschlüssel müssen durch Programmierer geeignet gewählt
werden
•
keine Persistenz durch Erreichbarkeit
•
SQL als Programmiersprache nicht mächtig genug, keine benutzerdefinierbaren Prozeduren
•
Impedance Mismatch: Typen von SQL und externen Programmiersprachen passen nicht
zueinander und müssen ineinander konvertiert werden
5
1.2.2. Nachteile objektorientierter Datenbanksysteme
Trotz der im letzten Abschnitt beschriebenen Nachteile stellen relationale Datenbanksysteme
derzeit die weit verbreitetste Technologie dar. Für die Datenbestände, die hier gepflegt werden,
ist es für den Fall, dass die relationale Technologie nicht mehr als ausreichend erachtet wird,
wünschenswert, dass sie mit möglichst geringem Aufwand auf das neue Datenbanksystem zu
portieren sind. Aufgrund der grundlegenden Unterschiede zwischen relationalen und
objektorientierten Systemen ist die Migration von Erstem zu Zweitem keineswegs ohne weiteres
zu erledigen.
Bei Anwendungsfällen, in denen sich die relationale Datenbanktechnologie bewährt hat, also vor
allem beim Verwalten großer, einfach aufgebauter Daten, ist zwar prinzipiell der Einsatz von
objektorientierten Systemen möglich, allerdings nicht sonderlich empfehlenswert. In diesen Fällen nämlich, sind objektorientierte Datenbanksysteme in der Regel erhebliche langsamer. Ein
Grund hiefür ist die gesteigerte Komplexität objektorientierter Datenbankprogrammiersprachen,
die eine datenbankinterne Optimierungen von Lese- und Schreibzugriffen erschwert.
Ein weiterer Nachteil, der mit der Komplexität und Leistungsfähigkeit objektorientierter Datenbankprogrammiersprachen zusammenhängt, ist die erhöhte Fehleranfälligkeit die diese Komplexität mit sich bringt. Je einfacher und überschaubarer eine Programmiersprache desto geringer ist
nämlich auch die Wahrscheinlichkeit von Programmierfehlern, welche den Datenbestand einer
Datenbank eventuell verfälschen könnten.
Den objektorientierten Datenbanken fehlt das theoretische Fundament ihrer relationalen Verwandten, welche mathematisch mit Hilfe der Relationenalgebra eindeutig beschrieben werden
können. Auch sind relationale Datenbankprodukte in der Regel ausgereifter, schließlich existieren diese Produkte seit Beginn der achtziger Jahre, während objektorientierte Datenbanken erst
in den Neunzigern, einhergehend mit der Etablierung objektorientierter Entwurfs und Programmiermethoden, entstanden sind.
Ein Rollenkonzept ist bei objektorientierten Datenbanken zwar vorhanden, allerdings in bestimmten Fällen recht aufwendig nur durch Mehrfacherbung zu realisieren. Im Detail wird dieser
Punkt in Kapitel 3 mit einem Beispiel veranschaulicht. Allgemein kann gesagt werden, dass je
mehr Rollen ein Objekt annehmen kann, desto umständlicher ist das objektorientierte Rollenkonzept.
In Kapitel 1.1. wurde als grundlegende Anforderung an Datenbanksysteme die Datenunabhängigkeit genannt. Objektorientierte Datenbanksysteme besitzen allerdings weder ein Sichtenkonzept, welches logische Datenunabhängigkeit ermöglichen würde, noch implementieren sie externe Datenunabhängigkeit. Vielmehr wird die konzeptuelle Ebene, die Objektstrukturen, nahezu
eins zu eins auf die verwendeten Massenspeichermedien ausgelagert. Das Fehlen von Datenunabhängikeit äußert sich bei nachträglichen Änderungen an konzeptueller oder physischer Ebene,
und führt in diesen Fällen zu einem Mehraufwand, beispielsweise zum Anpassen bereits bestehender Applikationen an neue Datentypen, der bei bestehender Datenunabhängigkeit nicht erbracht werden muss.
6
Zusammenfassen weist ein objektorientiertes Datenbanksystem also folgende Schwachpunkt auf:
•
Migration relationaler Datenbestände in objektorientierte Datenbanken nicht ohne weiteres möglich
•
Performanznachteil bei großen, einfach strukturierten Datenbeständen
•
Höhere Anfälligkeit für Programmierfehler, da Datenbanksprache komplexer
•
keine theoretische Untermauerung, nicht so ausgereift wie relationale Systeme
•
Rollenkonzept in bestimmten Fällen umständlich
•
Keine Datenunabhängigkeit, da kein Drei-Ebenen Konzept
1.3. Resultierende Anforderungen für objektrelationale Datenbanksysteme
Relationale Datenbanksysteme stellen heute eine etablierten Technologie dar, die in vielen Bereichen der Datenverarbeitung erfolgreich eingesetzt wird. Ein Großteil aller Geschäfts- und
Prozessdaten ist in relationalen Datenbanken abgelegt. Die von den Systemen angebotenen Datentypen und Anfragesprachen sind für die typischen Standard-Datenbankanwendungen ausreichend. Nicht-Standard-Datenbankanwendungen stellen neue Anforderungen an Datenbanksysteme wie den Umgang mit komplex strukturierten Multimedia Daten. In einem Städteinformationssystem müssen beispielsweise Anfahrtspläne, Photographien und mit Bildern angereicherte
Dokumente ebenso wie Audiodaten und Videos verwaltet werden. Aufgrund der anwendungsspezifischen Anforderungen an neue Datentypen, wäre eine herstellerseitige Ergänzung der vordefinierten Datentypen um neue Typen unzureichend. Es sollte vielmehr jedem Entwickler möglich sein, das Datenbanksystem seinen Bedürfnissen entsprechend mit neuen Datentypen und
Funktionen zu erweitern.
Somit werden die Anforderungen an ein neues Datenbankkonzept offenbar: Es sollte, um problemlose Übernahme vorhandener Datenbestände zu ermöglichen, auf der konventionellen relationalen Technologie aufsetzen und diese durch objektorientierte Erweiterungen ergänzen. Hierfür
wäre eine objektorientierte Erweiterung des SQL-Standards wünschenswert, der erlaubt das Datenbanksystem mit neuen Typen, Funktionen und Regeln zu erweitern, ohne allerdings die Komplexität der Sprache ausufern zulassen. Genau dieser Gedanke wird von objektrelationalen Datenbanksystemen verfolgt.
Ausgangspunkte für die aktuellen objektrelationalen Datenbankprodukte sind die etablierten
relationalen Systemen, die die Hersteller nun um objektorientierte Konzepte erweitern, um die
erwähnten Einschränkungen relationaler Systeme auszuschalten. Da mit SQL:1999 erst seit kurzem ein wohldefinierter Standard für objektrelationale Funktionalität besteht, ist die Implementierung objektrelationeller Merkmale in den verschiedenen Produkten auch unterschiedlich weit
fortgeschritten. Welche Merkmale dies im einzelnen sind und welchen Funktionsumfang eine
Datenbank mitbringen muss, um sich objektrelational nennen zu dürfen, soll im folgenden Kapitel behandelt werden.
7
2. Merkmale objektrelationaler Datenbanksysteme
Das objektrelationale Konzept ist relativ neu, es ist durch Integration bekannter Ansätze und
durch logische Weiterentwicklung entstanden. Seit vielen Jahren hat man immer wieder versucht
das relationale Datenbankmodell zu erweitern, weil die Umstellung relationaler Datenbestände
auf das strikte objektorientierte Konzept sehr umständlich bleibt. Bevor man aber auf das objektrelationale Modell gekommen ist, sind schon viele Neuerungen und Forschungen gemacht worden. Daraus sind neue Konzepte entstanden. Alle Konzepte sind unter dem Begriff „Postrelationales Datenbanksystem“ zu verstehen. Der Name Postrelational soll an die unternommene Erweiterung des relationalen Modells erinnern. Zu den am häufigsten realisierten Konzepten zählen:
•
Erweiterte, vordefinierte und benutzerdefinierte Datentypen
•
Funktionen und Methoden
•
Typkonstruktkoren
•
Objektidentität
•
Referenzen
Die Basis für diese Systeme ist jeweils das Relationenmodell. Unterscheiden kann man Systeme
dieser Entwicklungsrichtung wieder nach:
•
Relationalen Datenbanksystemen mit strukturellen Erweiterungen
•
Relationalen Datenbanksystemen mit Verhaltensmäßigen Erweiterungen
•
Relationalen Datenbanksystemen mit einem ADT-Konzept, wobei die ADTs gleichermaßen Struktur und Verhalten definieren
•
Relationalen Datenbanksystemen, die innerhalb des Relationenmodells relativ weitgehend ein objektorientiertes Datenbankmodell verwirklichen
Wann ist ein System aber nun objektrelational? Um diese Frage zu beantworten betrachten wir
zunächst die Klassifikationsmatrix von Stonebraker wie sie in [2] wiedergegeben wird:
Demnach ist das Unterscheidungsmerkmal zwischen relationalen und objektrelationalen Datenbanken allein die Unterstützung komplexer Datentypen. In der Praxis müsste man aber dadurch
viele postrelationale Systeme, die die Objektorientierung nicht verwirklichen als objektrelational
bezeichnen. Zwischen objektrelationalen und objektorientierten Datenbanken trennt man nach
8
Stonebraker anhand der Existenz von Abfragesprachen. Aber auch reine objektorientierte Produkte, in [2] werden POET und O2 angegeben, besitzen mittlerweile Anfragesprachen. Mit Stonebraker muss man diese also ebenfalls als objektrelational bezeichnen, obwohl sie keine relationalen Anteile haben. Demnach ist der Ansatz von Stonebraker nicht mehr anwendbar und es
müssen andere Kriterien verwendet werden um über die Objektrelationalität eines Systems zu
entscheiden.
Heuer verwendet hierfür in [2] eine geeigneteren Weg der spezifischere Eigenschaften von Datenbanken berücksichtigt. Objektrelational soll hier zuerst einmal heißen, daß das relationale
Modell vollständig unterstützt wird. Begriffe wie Entitätstypen, Attribute, Tupel, Primärschlüssel
und Fremdschlüssel, Projektion, Selektion und Verbindung von Tabellen gehören hier nach wie
vor zum Grundvokabular. Das objektrelationale Model versucht darüber hinaus ein Datenbankmodell zu erschaffen das mit „einige OO-Konzepten in der Form einer Tabelle" charakterisiert
werden kann. Persistente Daten werden schon längst mit einer Tabelle verarbeitet, hinzugekommen ist nun die Fähigkeit, das Felder der Tabelle strukturierte Daten bzw. abstrakte Datentypen
einnehmen können sollen. Außerdem sollen aus dem objektorientierten Konzept Merkmale wie
Vererbungsprinzipen und Methodenüberschreibung (Overriding) integriert sein.
Die folgende Tabelle veranschaulicht die Kriterien zur Klassifikation von Datenbanken nach
Heuer, wobei die zu Beginn des Kapitel angesprochene Klasse von postrelationalen Datenbaken
hier in zwei Kategorien eingeteilt wird:
Demzufolge stellen Datenbanken die nur den Kriterien der linke Tabelle erfüllen, lediglich eine
Erweiterung des relationalen Modells um abstrakte Datentypen dar, ohne objektorientierte Konzepte zu implementieren. Daher können sie auch nur als erweitert relational bezeichnet werden.
Damit eine Datenbank als objektrelational eingestuft werden kann, müssen die Kriterien in der
rechts stehenden Tabelle erfüllt sein. Hauptkriterium für Objektrelationalität ist also hiernach das
Vorhandensein von Vererbungsmechanismen zur Methoden- und Strukturvererbung.
Nachdem somit festgelegt ist, was unter objektrelationalen Datenbanken zu verstehen ist, erfolgt
in den zwei nächsten Unterkapiteln nun eine Erläuterung der hier zur Unterscheidung aufgeführten Merkmale.
9
2.1. Erweiterung relationaler Datenbanksysteme um abstrakte Datentypen
Damit relationale Datenbanksysteme mit abstrakten Datentypen umgehen können benötigen sie
die folgenden Erweiterungen:
•
komplexe, benutzerdefinierbare Datentypen
•
Funktionen, Methoden
•
Typenkonstruktoren
Unter komplexen Datentypen versteht man Typen wie Struktur und Menge. Benutzerdefinierbare
Datentypen resultieren aus der Kombination der internen Datentypen der Datenbank.
Funktionen konnten bisher in Standard-SQL nicht erzeugt werden. Dieses, in herkömmlichen
Programmiersprachen schon lange bekannte Konzept zur Programmstrukturierung und Wiederverwendung von Quellcode, kann somit auch in Datenbanken Verwendung finden. Angewandt
wird es z. B. für benutzerdefinierbare Operationen in Anfragen. Hauptelement der Erweiterung
um abstrakte Datentypen ist die Einführung von Methoden. Dabei handelt es sich um mit bestimmet Datentypen assoziierte Funktionen. In der Praxis werden Methoden verwand um zu Typen dazugehörigen Zugriffs- und Verarbeitungsfunktionen zu definieren. Neben den klassischen
einfachen Typen wie „Integer“ mit den Funktionen „Addition“ und „Subtraktion“ kann man nun
auch neue Datentypen wie beispielsweise „Bild“ mit den Funktionen „Bildanzeigen“ definieren.
Jeder benutzerdefinierte Typ besitzt einen Konstruktor gleichen Namens, mit dem Objekte bzw.
Instanzen dieses Typs erzeugt werden können. Durch Aufruf eines Konstruktors wird jedoch
nicht nur eine Instanz eines Typen erzeugt, sondern der Konstruktor kann darüber hinaus als benutzerdefinierbare Methode angesehen werden, die bei jeder Erzeugung einer Instanz des Typen
aufgerufen wird. Aufgrund dieser Eigenschaft werden Konstruktoren z. B. für die Zuweisung
von Initialwerten verwendet.
Mit den hier erläuterten Merkmalen erweiterter relationaler Datenbanken ist es also möglich abstrakt Datentypen zu implementieren. Die Unterstützung abstrakter Datentypen ist attraktiv, weil
Methoden als Operationen assoziiert mit diesen neuen Datentypen benutzt werden können um
Datenmengen z. B. zu indexieren, zu speichern und Anfragen, die auf diese Datentypen basieren,
zu realisieren.
2.2. Objektorientierte Erweiterungen
Wie bereits erwähnt ist das wichtigste Merkmal von objektrelationalen Datenbanken die Vererbung. Hierbei handelt es sich um ein grundlegendes objektorientierten Konzeptes, welches vor
allem dann von Vorteil ist, wenn aus Entity-Relationship-Modellen, Datenbankschemata entwickelt werden sollen. Mit herkömmlichen relationalen Datenbanken kann so etwas nämlich nicht
direkt implementiert werden. Mit Vererbung kann man aus einem gebildeten Basistyp wie „Per10
son“ verschiedene Typen beispielweise „Techniker“, „Manager“ oder „Mitarbeiter“ ableiten. Die
abgeleiteten Typen erben alle Eigenschaften von „Person“, können aber auch erweiterte spezifische Attribute zugewiesen bekommen, die nur für den Untertyp gelten. Diese Form von Vererbung, also das Vererben von Attributen von Basisklassen an Unterklassen, wird auch Strukturvererbung genannt. Eine Unterklasse erbt aber auch alle Methoden von der darüber liegenden
Klasse. Soll eine Methode in einer Unterklasse aber nachträglich gegenüber einer geerbten Methode aus einer Basisklasse verändert werden, so wird dieser Vorgang als Overriding oder Überschreiben bezeichnet.
Im objektorientierten Konzept exsistiert lediglich Vererbung auf der Ebene von Typen, die dort
Klassen genannt werden. Eine auf Basis dieser Vererbung erzeugte Hierarchie wird Typenhierarchie genannt. Objektrelationale Systeme kennen weitergehend auch Vererbung auf Tabellenebene, bei der eine Tabelle erstellt werden kann, indem sie Attribute einer bereits bestehenden
Tabelle übernimmt. Eine solche Tabellenhierarchie wird auch als Relationenhierarchie bezeichnet.
Eine weiteres nützliches Merkmal, dass die objektrelationalen von den objektorientierten Datenbanken übernommen haben ist die Objektidentität. Zu jedem Objekt wird automatisch ein systemweit eindeutiger Identifikator erzeugt (OID), der z.B. zur Modellierung von Beziehungen
durch Referenzen herangezogen werden kann. Dieser Identifikator bleibt während der Lebenszeit
des Objekts unverändert.
Wie bereits angedeutet können mit dem OID Referenzen erzeugt werden. Eine Referenz gleicht
dem Speichern eines Fremdschlüssels in einer Tabelle und dient dazu auf ein Objekt oder auf ein
Tupel in einer Tabelle zu zeigen. Beziehungen können durch Referenzen aber „natürlicher“ dargestellt werden, als durch künstlich eingeführte Fremdschlüsselattribute. Sobald Referenzen vorhanden sind kann zwischen verschiedenen Objekten bzw. Tupeln direkt navigiert werden. Somit
werden komplexe Abfragen, die im relationalen Modell Joins über mehrere Tabellen erfordern,
u.U. erheblich vereinfacht, wenn die Beziehung durch Referenzen modelliert wird (weniger Tabellen in der from-Klausel, besser lesbare Anfragebedingungen).
11
3. Beispiele
Um ein Eindruck davon zu bekommen wie sich die geschilderten Eigenschaften objektrelationaler Datenbanken letztlich in der Praxis auswirken betrachten wir in diesem Kapitel einige Beispiele die aus [3] mit leichten Abwandlungen entnommen wurden. Der in den Beispielprogrammen verwendete Code entspricht dem Vorschlag eines erweiterten SQL wie er in [3] verwendet
wird.
3.1. Strukturen und Mengen
Die grundlegendste Erweiterung über die objkektreltionale Datenbanken im Gegensatz zu den
relationalen Datenbanken verfügen, ist die Möglichkeit Tabellen mit Attributen zu erstellen, die
nicht von einem atomaren Typ wie Ganzzahl (integer) oder ASCII-Zeichen (char) sind. Statt
dessen können die Attribute einer Tabelle komplexe Typen wie „Menge eines bestimmten Typs“
(setof) haben oder strukturiert sein, also aus anderen Typen zusammengesetzt sein. Durch diese
Eigenschaft ist es sehr viel einfacher von einer gegebene mittels Datenbank zu erfassenden Situation zu einer korrespondierenden Tabelle zu kommen.
Ein mögliches Beispiel ist ein einfache Datenbankanwendung für die Verwaltung von Büchern.
In einer Tabelle sollen Titel, Autor (bei mehreren Verfassern alle Autoren), Datum (unterteilt in
Tag, Monat, Jahr) und eine Stichwortliste gespeichert werden. Dank komplexer Attribute ist das
Ganze kein Problem: man kann den intuitiven Ansatz wählen welcher wohl bei den Meisten folgendermaßen aussehen würde:
Titel
Autoren
Datum
Stichwortliste
Reich und Schön {Crawford, Schiffer} 12, Februar, 2000 {schminken, lächeln}
Dick und Doof {Laurel, Hardy}
1, April, 1930
{boing, peng}
Hierbei trennen die Kommata in der Spalte Datum die einzelnen Untertypen von einander ab
(also ist das Attribut Datum strukturiert) und die geschweiften Klammern symbolisieren Mengen
(daraus folgt Autoren und Stichwortliste sind Mengen von Zeichenketten). In objektrelationalem
SQL wird diese Tabelle dann so erstellt:
create type MyString char varying
create type MyDate ( Tag integer
, Monat char(10)
, Jahr integer )
create type Buch ( Titel MyString
, Autoren setof(MyString)
, Datum MyDate
, Stichworte setof(MyString) )
create table Buchverwaltung of type Buch
12
Mit der ersten Anweisung wird der Typ MyString als eine Zeichenkette mit unbestimmter Länge
definiert. Mit der zweiten Anweisung wird der Typ MyDate definiert, und zwar als Struktur mit
den Elementen Tag(vom Typ Integer), Monat (Zeichenkette aus maximal 10 Zeichen) und
Jahr(ebenfalls Integer). Mit der dritten Anweisung wird letztlich der Typ der Tabelle, also im
Sprachgebrauch relationaler Datenbanken das Schema, festgelegt. In der letzten Anweisung wird
eine Tabelle des Typs Buch in der Datenbank angelegt. Die Hiermit erstellten Datentypen werden im Metaschema der Datenbank gespeichert und stehen damit allen weiteren auf dieser Datenbank aufsetzenden Applikationen zur Verfügung.
Wollte man die zugrundeliegende Aufgabenstellung mittels einer herkömmlichen relationalen
Datenbank lösen, so könnte man versucht sein die obigen Daten ebenfalls in einer einzigen Tabelle anzulegen. Dies würde allerdings zu folgendem schaurigen Ergebnis führen:
Titel
Reich und Schön
Reich und Schön
Reich und Schön
Reich und Schön
Dick und Doof
Dick und Doof
Dick und Doof
Dick und Doof
Autoren
Crawford
Crawford
Schiffer
Schiffer
Laurel
Laurel
Hardy
Hardy
Tag
12
12
12
12
1
1
1
1
Monat
Februar
Februar
Februar
Februar
April
April
April
April
Jahr
2000
2000
2000
2000
1930
1930
1930
1930
Stichworte
schminken
lächeln
schminken
lächeln
boing
peng
boing
peng
Da in einer relationalen Datenbank ein Attribut kein Mengentyp seien kann, kann in den Spalten
Autoren und Stichworte nur ein Datenelement gespeichert werden. Somit müssen neue Zeilen
erzeugt werden um alle möglichen Kombinationen von Autoren und Stichworte zu speichern.
Außerdem wird die Anzahl der Spalten dadurch erhöht, daß keine strukturierten Typen erlaubt
sind also für jedes Element von Datum eine eigene Spalte notwendig wird.
Die hier auftretenden Redundanzen können dadurch vermieden werden das man die Daten in
mehrere Tabellen speichert:
Titel
Reich und Schön
Reich und Schön
Dick und Doof
Dick und Doof
Autoren
Crawford
Schiffer
Laurel
Hardy
Titel
Reich und Schön
Reich und Schön
Dick und Doof
Dick und Doof
Stichworte
schminken
lächeln
boing
peng
Titel
Tag Monat Jahr
Reich und Schön 12 Februar 2000
Dick und Doof 1
April
1930
13
Der Nachteil dieser Lösung ist ebenfalls offensichtlich: Der Entwurf der Datenbankschemata ist
komplizierter geworden und die direkte Beziehung von Objekt (Buch) zum sie beschreibenden
Tupel in der Tabelle der Datenbank ist verloren gegangen. Für jedes Buch existieren mehrere
Tupel die es beschreiben.
3.2. Hierarchien und Erbungsmechanismen
Die grundlegenden Vorteile Objektorientierter Programmiersprachen und Datenbanken sind die
Unterstützung von Wiederverwendung bereits erstellten Quellcodes und die Vereinfachung der
Modellbildung. Letzteres äußert sich z. B. darin, daß ein zur Objektmodellierung erzeugtes E-R
Diagramm ohne weiteres als Datentyp in einer objektorientierten (Datenbank-) Programmiersprache erzeugt werden kann.
Eine notwendige Voraussetzung für diese Erleichterung der Objektmodellierung ist die Existenz
von Erbungsmechanismen bei der Erzeugung benutzerdefinierter Datentypen. Im Zusammenhang mit der Objektorientierung wird ein Datentyp oder Attribut auch als Klasse bezeichnet.
Durch Erben entsteht aus einer Oberklasse eine Unterklasse. Die Unterklasse besitzt alle Eigenschaften der Oberklasse, und kann um weitere Eigenschaften ergänzt werden. Durch Erbungsmechanismen entstehen also Klassenhierarchien.
Objektrelationale Datenbanken unterstützen das Erben auf zweierlei Weise. Die klassische Variante funktioniert folgendermaßen:
create type Person ( Name MyString
, GeburtsDatum MyDate )
create type Fotomodell ( Gehalt integer
, Haarfarbe MyString ) under Person
create type Schauspieler ( Gehalt integer
, Oscars integer ) under Person
create type Sportler ( Gehalt integer
, ZigarettenProTag integer ) under Person
create table BayernMuenchen of type Sportler
In diesem Beispiel werden wie aus objektorientierten Programmiersprachen bekannt aus der Oberklasse Person die Unterklassen Fotomodell, Schauspieler und Sportler abgeleitet. In der letzten Anweisung wird in der Datenbank eine Tabelle vom Typ Sportler angelegt. Ein Beispiel für
eine solche Tabelle wäre dann:
Name
GeburtsDatum Gehalt ZigaretteProTag
Oliver Kahn 4, April, 1969 1000000 0
Mario Basler 5, April, 1969 2000000 126
14
Bei dem Versuch eine Klassenhierarchie in einer erweiterten relationalen Datenbank (eine Datenbank sie zwar erweiterte Typen wie Menge und Struktur kennt aber keine Erbung anbietet) zu
speichern, ist man dagegen genötigt zwei Tabellen anzulegen und diese dann mittels Primärschlüssel zu verketten:
Name
GeburtsDatum
Oliver Kahn 4, April, 1969
Mario Basler 5, April, 1969
Name
Gehalt ZigaretteProTag
Oliver Kahn 1000000 0
Mario Basler 2000000 126
Neben dem höheren Modellierungsaufwand und dem Verlust der eindeutigen Beziehung zwischen realem Objekt und Tupel in der, die Objektklasse modellierenden, Tabelle, muss man sich
bei einer solchen Lösung auch selber um die Wahrung von Datenkonsistenzen bemühen.
Durch löschen des Tupels ( Mario Basler, (5, April, 1969) ) in der 1.Tabelle des vorangegangenen Beispiels muss auch, und zwar durch die Datenbankanwendung, sichergestellt werden, daß
das Tupel (Mario Basler, 2000000, 126) aus der 2.Tabelle gelöscht wird. Eine weitergehende
Beschreibung der Probleme, die sich beim Abbilden objektorientierter Daten auf ein rein relationale System ergeben, ist in [4] zu finden.
Die bereits angekündigte zweite Art und Weise in der objektrelationale Datenbanken das Erben
unterstützen, ist das Erben auf Relationen- oder Tabellenebene. Hierbei wird nicht aus einem
bereits bestehenden Datentyp , bzw. objektorientiert gesprochen, aus einer bestehende Klasse ein
Unterklasse erzeugt, sondern es wird eine exsistierende Tabelle als Vorlage für eine neue Tabelle
benutzt. Wie beim Erben auf Klassenebene besitzt die neu entstandene Tabelle alle Eigenschaften der Vorlagentabelle.
Dieses Merkmal objektrelationaler Datenbanken ist ein Vorteil gegenüber objektorientierten Systemen, da hierdurch Mehrfacherbung vermieden und Klassenhierarchien vereinacht werden können. In einem objektorientierten System würde man aufsetzend auf die bereits definierten Klassen Fotomodell, Schauspieler, Sportler eine Klasse für Personen die Schauspieler und Fotomodell sind eine gesonderte Klasse FotomodellSchauspieler erstellen die durch Mehrfacherbung
aus Schauspieler und Fotomodell entstanden wäre. Exsistierten darüber hinaus Personen die sowohl Sportler als auch Schauspieler oder Sportler und Fotomodell oder Sportler, Fotomodel und
Schauspieler sind, so müsste man die Klassen SportlerFotomodell, SportlerSchauspieler, SportlerFotomodellSchauspieler erstellen.
In einer objektrelationalen Datenbank löst man solch eine Konstellation dagegen durch das Erben auf Tabellenebene. Die sich durch Erbung auf dieser Ebene ergebenden Hierarchien sind die
in Kapitel 2 angesprochenen Relationen- oder Tabellenhierarchien. In objektrelationalem SQL
drückt man Erben auf Tabellenebene dadurch aus, dass man nach der create table Konstruktion
keinen Typ, sondern eine bereits bestehende Tabelle mittels des Schlüsselwortes under, als Basistabelle angibt. Bei Verwendung dieser Variante des Erbens sieht das vorangegangene Beispiel
folgendermaßen aus:
15
create type Person ( Name MyString
, GeburtsDatum MyDate )
create table Taugenichtse of type Person
create table Fotomodelle ( Gehalt integer
, Haarfarbe MyString ) under Taugenichtse
create table Schauspieler ( Gehalt integer
, Oscars integer ) under Taugenichtse
create table Sportler ( Gehalt integer
, ZigarettenProTag integer ) under Taugenichtse
Statt der vorher notwendigen sieben Tabellen, werden nun nur noch vier benötigt. Eine Person
die zugleich Sportler, Schauspieler und Fotomodell ist wird nun in allen vier Tabelle geführt.
Damit in den Tabellen Fotomodelle, Schauspieler und Sportler nicht redundant die Attribute der
Tabelle Taugenichtse aufführen, werden datenbankintern in den durch Erbung entstandenen Tabellen nur die Primärschlüssel der vererbenden Tabelle gespeichert. Bei Bedarf werden durch
eine internen Join die anderen Attribute ermittelt.
Für den Fall das Mehrfacherbung ausdrücklich erwünscht ist, wird angestrebt diese in objektrelationalen Systemen ebenfalls zu ermöglichen. Der derzeitige Standard:SQL1999 sieht Mehrfacherbung zwar nicht vor, doch ist dies Gegenstand der derzeitigen Entwicklung: Für den angestrebten zukünftigen Standard SQL:2000 ist Mehrfacherbung eingeplant.
16
4. Der neue Standard für objektrelationale Datenbanken SQL:1999
Der lange Zeit unter dem Namen SQL3 entwickelte Standard für objektrelationale Datenbanksprachen ist in 1999 unter dem Namen SQL:1999 verabschiedet worden. Wie im vorangegangenen Kapitel erwähnt, fehlt diesem vor allem noch die Möglichkeit zur Mehrfacherbung, welche
erst mit SQL:2000 angestrebt wird.
Der Aufbau des SQL:1999-Standards besteht wie folgt aus 9 Teilen:
1. Framework: Dieser Teil beschreibt den Aufbau des Standards
2. Foundation: Die Foundation ist der eigentliche Kern des Standards
3. SQL / CLI: Das Call Level Interface des SQL:1999 Standards
4. SQL / PSM: Dies sind die sog. Persistent Storage Modules
5. SQL / Bindings
6. SQL / Transaction
7. SQL / Temporal
8. SQL / MED: Das Management externer Daten
9. SQL / OLB: Das Object Language Binding, was auch dem SQLJ entspricht
Die Neuerungen gegenüber den alten SQL Standards beziehen sich unter anderem auf die neuen
vordefinierten Datentypen. Es existieren jetzt u. a. :
•
ein Boolean Typ
•
Large Objects wie Binary Large Objects (BLOB) und Character Large Objects (CLOB),
mit denen man nun auch Bild- oder sogar ganze Textdateien im DBS und nicht wie vorher in separaten Dateien verwalten kann
Ebenso wurde das Typsystem um die Möglichkeit, der Definition von User-Defined-Types
(UDT) unter Verwendung von vordefinierten Typen, konstruierten Typen und vorher definierten
User-Defined-Types erweitert. Dieses Erweiterbare Typsystem stellt eine signifikante Verbesserung der Modellierungsfähigkeiten dar.
17
Es wurden zahlreiche weitere Fähigkeiten hinzugefügt, wie z.B.:
•
Trigger
•
Rekursion (Rekursive Anfragen)
•
Verbesserte Möglichkeiten, Daten über Sichten (Joins) zu verändern
•
Sprachkonstrukte (Blöcke, Schleifen, Verzweigungen usw.)
•
Verweise über Referenzdatentypen
•
Tabellen-Hierarchien
•
Schema-Evolution bei UDT's und UDF's
•
Komplexe Tabellenstrukturen (Spalten für satz- und arrayartige Werte)
•
Anbindung der neuartigen Datenobjekte an Wirtssprachen (z.B. an Java)
Ebenfalls umfasst SQL:1999 eine Erweiterung der Standardbibliotheken um :
•
Typen und Routinen für die Volltextsuche
•
Typen und Routinen für geographische Informationssysteme (GIS)
18
5. Vergleich unterschiedlicher Produkte
In diesem Kapitel werden unterschiedliche Datenbankprodukte von verschiedenen Herstellern
unter die Lupe genommen. Es findet ein Vergleich der Produkte statt und weiterhin wird versucht die Produkte hinsichtlich ihrer objektrelationalen Eigenschaften zu klassifizieren.
5.1. Informix Universal Server
Als erstes soll nun der Informix Universal Server genauer betrachtet werden. Der Informix Universal Server stellt ein Beispiel für eine objektrelationale Datenbank dar, die aus Teilen von dem
aus dem Postgres weiterentwickeltem Illustra besteht (früher: „Miro“, „Mirage“ bzw. UniSQL).
Informix Universal Server gehört zu der Gruppe der erweiterbaren oder offenen Datenbanksysteme, wie z.B. auch DB2 und Oracle 8. Diese erlauben es neue Datentypen mit ihren Funktionen
unter Bewahrung der Kapselung zu definieren und diese auf der internen Ebene zu verankern.
Diese Technik wird bei Illustra bzw. Informix Universal Server Data Blades, bei DB2 Database
Extenders und bei Oracle 8 Data Cartridges genannt.
Die Datenbanksysteme DB2 V2 und Oracle werden zwar aus werbungstechnischen Gründen als
objektrelationale Datenbankmanagementsysteme bezeichnet, sind eigentlich jedoch nur eine
Vorstufe. Sie zählen zu den objektrelationalen Datenbankmanagementsystemen mit abstrakten
Datentypen, da ihnen das Vorhandensein einer Typhierarchie und die Möglichkeiten zur Vererbung von Strukturen und Methoden fehlt, im Gegensatz zu Informix Universal Server, der die
Vererbung und die Typhierarchie beherrscht.
Da der aktuelle SQL:1999 Standard in 1999 verabschiedet wurde sind bei den Heute verfügbaren objektrelationalen Datenbankmanagementsystemen noch diverse Abweichungen zu erkennen. Das sogenannte CALL-Statement von Informix Universal Server ist im Gegensatz zu dem
von DB2/MVS 4.1, DB2/400 3.1 und DB2 Common Server 2.1 eingesetzten CALL-Statements
noch nicht SQL:1999 konform.
Bei dem Informix Universal Server umschließt die Erweiterbarkeit über Data Blades (welche
von Illustra übernommen wurden) folgende Punkte:
•
benutzerdefinierte Datentypen
•
benutzerdefinierte Routinen
•
benutzerdefinierte Zugriffspfade (Indexstrukturen)
19
Weiterhin enthält der Informix Universal Server die bisherigen insgesamt ca. 30 Data Blade Modules, z.B.:
•
Time Series
•
Web
•
Image
•
Text
•
2D/3D Spatial
•
....
Viele SQL:1999-Features wurden bereits integriert, die Kollektionstypen sind umfassender als in
SQL:1999 vorgeschrieben und es existieren schon explizite ROW-Typen.
5.2. Oracle 8
Bei Oracle 8 wird die Erweiterbarkeit über Data Cartridges, die jedoch weniger eng integriert
wurden als die von Informix Universal Server bekannten Data Blades, unterstützt.
Die Erweiterbarkeit umschließt folgende Punkte:
•
benutzerdefinierte Typen
•
benutzerdefinierte Arrays
•
(einfach) geschachtelte Tabellen, die auf typisierte Tabellen (Objekt-Tabellen) und maximal
•
eine Schachtelungsstufe beschränkt sind. Der Zugriff erfolgt über den THE-Operator
•
(flattened subquery).
In Oracle 8 ist jedoch noch keine Vererbung möglich und auch keine Typhierarchie.
5.3. IBM DB2
IBM's DB2 bietet eine Mischung aus relationalen und objektorientierten Eigenschaften, bleibt im
Kern jedoch relational. Durch diese nach außen hin als Zwitter erscheinende Datenbank ist es
möglich, sowohl die auf dem alten relationalen Datenbankmodell basierenden Anwendungen,
wie auch die neuen mit objektorientierten Features ausgestatteten Applikationen zu benutzen.
20
Das DB2-SQL wurde so erweitert, das die Datenbank nun auch externe Daten, z.B. große Videooder Bilddaten, verarbeiten kann, wofür ein komplettes externes Datei-Handling integriert wurde. Integriert wurden auch die vom Common Server bekannten Multimedia Extender, welche auf
den User Defined Datatypes (UDT) und den User Defined Functions (UDF) aufbauen, wobei die
UDT's aus Performance-Gründen wie interne Funktionen behandelt werden.
Weitere Neuerungen sind:
•
rollenbasierter, erweiterbarer Optimizer
•
paralleles I/O
•
erheblich schnellerer Restart
•
Daten- und Index-Prefetch
•
•
verbesserte LOAD-Jobs (paralleles Lesen und Schreiben von Dateien, Tabellen bzw. Indexen)
verbesserte Skalierbarkeit und hohe Verfügbarkeit
•
verteilen einer Tabelle auf mehrere Laufwerke bzw. Rechner nun möglich
•
Replikation auf dieser Ebene möglich
•
Backup und Recovery jeweils parallel durchführbar
•
Teile einer Tabelle, die auf unterschiedlichen Laufwerken oder Rechnern liegen, können
nun
•
getrennt gesichert werden.
• neues User-Interface
• komplette Steuerung eines entfernten Servers machbar
Es ist jedoch wie bei Oracle 8 keine Vererbung möglich, ebenso ist die Typhierarchie nicht implementiert.
21
6. Fazit
Bei bestimmten Anwendungen haben die herkömmlichen objektorientierten Datenbankmanagementsysteme noch einen Entwicklungsvorsprung, unter anderem weil sie hohe Performanz für
navigierende Zugriffe (Pfadausdrücke) aufgrund ihrer engen Programmiersprachen-Integration
bieten. Außerdem werden sie noch bevorzugt für Anwendungen, die mit objektorientierten Programmiersprachen realisiert wurden und eine persistente Datenverwaltung benötigen, da es hier
nicht zum „Impedance Mismatch“ kommt.
Durch die Heterogenität der verschiedenen Implementierungen und die Unterschiede zur kommenden Norm wird eine Interoperabilität unter den verschiedenen objektrelationalen Produkten
noch vielfach verhindert. Auch können einige, sich selbst als objektrelational bezeichnende, Systeme noch nicht vollständig als solche betrachtet werden. So kann man Oracle 8 und DB2, trotz
ihrer Erweiterung gegenüber dem Relationenschema, noch nicht zu dieser Kategorie von Datenbanken zählen, da sie noch keine Vererbung ermöglichen und daher auch die Typhierarchie noch
nicht implementiert ist. Ebenfalls werden derzeit noch keine neuen Klassen oder Objektstrukturen als Anfrageergebnisse erzeugt, da das grundlegende Konzept immer noch die Relation oder
Tabelle ist. Der Trend zur vollen Unterstützung der objektrelationalen Konzepte ist jedoch bei
allen oben genannten Produkten erkennbar und wird zudem auch durch die Normung, also durch
den geschaffenen SQL:1999 Standard, gefördert.
Für die Integration von Texten Bildern und anderen häufig genutzten Daten, für den objektorientierten Zugriff auf vorhandene Daten und bei der Ergänzung existierender relationaler um objektorientierte modellierte Daten scheint der Einsatz der oben genannten Produkte schon vielversprechend. Das direkte Manipulieren und Abspeichern von Anwendungsobjekten ist mit den
objektrelationalen Datenbanksystemen mit ihren nutzerdefinierten Datentypen und ihren objektorientierten Konzepten möglich, ebenso wie ein flexibles Auffinden und Kombinieren dieser
Objekte in Anfragen.
Somit ist mit den objektrelationalen Datenbanken den objektorientierten Systemen neue Konkurrenz entgegengetreten. Letztere werden dadurch weder verdrängt noch überflüssig werden, jedoch wird in Anwendungsfällen, bei denen ein bestehender relationaler Datenbestand weiter
gepflegt werden soll, in der Regel zugunsten eines objektrelationalen Produktes entschieden
werden.
22
7. Literatur
[1] Martin Hueber, Computer World Spezial: Datenbank 97
[2] Andreas Heuer, Objektorientierte und objektrelationale Datenbanksysteme,
OBJEKTspektrum 1/98
[3] Abraham Silberschatz, Henry F. Korth, S. Sudarshan, Database System Concepts,
McGraw-Hill, 1997
[4] Jonathan Robie, Dirk Bartels, A Comparison between Relational and Object Oriented
Databases for Object Oriented Application Development, Poet Software Corporation, 1994
[5] Jens Lufter, Objektrelationale Datenbanksysteme, Informatik_Spektrum_22_August_1999
[6] Skript Datenbanksysteme 2: www.informatik.uni.leipzig.de/ifi/abteilungen/db/skripte/
DBS2/HTML/kap6-1.html
[7] Deutsches Institut für Normung e.V.: www.din.de/gremien/nas/ni/aktuell/sql3/
[8] Blauer Generalist – DB2 Universal Database: c’t 8/1997
23