Objektrelationale Datenbanken

Transkript

1 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

2 Übersicht 1. Motivation des objektrelationalen Datenbankkonzeptes Allgemeine Anforderungen an Datenbanksysteme Nachteile relationaler und objektorientierter Datenbanksysteme Nachteile relationaler Datenbanksysteme Nachteile objektorientierter Datenbanksysteme Resultierende Anforderungen für objektrelationale Datenbanksysteme Merkmale objektrelationaler Datenbanksysteme Erweiterung relationaler Datenbanksysteme um abstrakte Typen Objektorientierte Erweiterungen Beispiele Strukturen und Mengen Hierarchien und Erbungsmechanismen Der neue Standard für objektrelationale Datenbanken SQL: Vergleich unterschiedlicher Produkte Informix Universal Server Oracle IBM DB Fazit Literatur

3 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 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

4 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 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 kompli- 4

5 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

6 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

7 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

8 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

9 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

10 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 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 Per- 10

11 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

12 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 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

13 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 Autoren Tag Monat Jahr Stichworte Reich und Schön Crawford 12 Februar 2000 schminken Reich und Schön Crawford 12 Februar 2000 lächeln Reich und Schön Schiffer 12 Februar 2000 schminken Reich und Schön Schiffer 12 Februar 2000 lächeln Dick und Doof Laurel 1 April 1930 boing Dick und Doof Laurel 1 April 1930 peng Dick und Doof Hardy 1 April 1930 boing Dick und Doof Hardy 1 April 1930 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 Autoren Reich und Schön Crawford Reich und Schön Schiffer Dick und Doof Laurel Dick und Doof Hardy Titel Stichworte Reich und Schön schminken Reich und Schön lächeln Dick und Doof boing Dick und Doof peng Titel Tag Monat Jahr Reich und Schön 12 Februar 2000 Dick und Doof 1 April

14 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 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 O- berklasse 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, Mario Basler 5, April,

15 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 Mario Basler 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, , 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

16 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

17 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

18 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

19 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 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/ 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

20 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 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 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