Objektrelationale Datenbanksysteme

Die Basis objektorientierter Anwendungen sind Datenobjekte, die oft sehr komplex und auf vielfache Weise miteinander verbunden sind. Ein Objekt umfaßt als Instanz einer Klasse nicht nur die zu manipulierenden Daten, sondern auch die für die Klasse definierten Operationen (Methoden); die Daten können in der Regel nur über diese Operationen angesprochen werden (Datenkapselung). Die Klassendefinition legt also das Verhalten ihrer Objekte fest, in Sprachen mit Typsystem spricht man auch von der Spezifikation nutzerdefinierter Datentypen.

Ein Objekt hat zudem eine werteunabhängige, unveränderliche Identität, die in einem gegebenen Umfeld räumlich und idealerweise auch zeitlich eindeutig ist. Die Objektidentität dient unter anderem zur Herstellung von Beziehungen zwischen Objekten über Objektreferenzen, die damit im Gegensatz etwa zu Fremdschlüsseln in relationalen Datenbanken nicht wertebezogen sind. Neben solchen Beziehungen kann ein Objekt auch direkt Teil eines anderen Objekts sein, auf diese Weise können komplex verschachtelte Objektstrukturen entstehen.

Ein Grundkonzept der Objektorientierung ist die Vererbung von Klassen in ihren verschiedenen Spielarten. Eine Klasse wird dabei mit Bezug auf eine oder mehrere andere Klassen definiert, sie erbt deren Datenstrukturen und Operationen, kann diese in Grenzen verändern und eigene hinzufügen. Objekte einer solchen Klasse lassen sich dann auch an allen Stellen verwenden, an denen Objekte einer Oberklasse nötig sind, die objektspezifisch erforderlichen Operationen werden zur Laufzeit be stimmt (Substituierbarkeit, Polymorphie und dynamisches Binden).

Für die Integration von Persistenz in objektorientierte Anwendungen gibt es im wesentlichen drei Varianten. Der Gateway-Ansatz erlaubt als Middleware-Lösung die Nutzung nicht-objektorientierter, oft schon existierender Datenquellen zum Speichern von Objektdaten. Erforderlich ist dazu eine Abbildung zwischen dem objektorientierten Schema der Anwendung und dem auf einem anderen Datenmodell beruhenden Schema des Speichers, z.B. einer relationalen Datenbank. Als anwendungs- oder auch programmiersprachenzentriert kann man den Einsatz objektorientierter DBMS ansehen, der eine nahtlose Einbindung von Persistenz in Anwendungen erlaubt. Ein dritter, datenbankzentrierter Ansatz zum Speichern von Objekten ergibt sich schließlich aus der Weiter entwicklung relationaler zu objektrelationalen DBMS.

Objektrelationale Datenbanksysteme sind um nutzerdefinierte Datentypen mit Eigenschaften wie den oben genannten erweiterbar, interessant ist daneben auch die typunabhängige Verlagerung von Anwendungslogik in ein Datenbanksystem. Die Möglichkeiten eines solchen Systems sollen im folgenden anhand von SQL:1999 angedeutet werden. Für einen effizienten Datenbankbetrieb müssen neue Datentypen und Routinen durch geeignete Optimierungsmöglichkeiten unterstützt werden, die auf generischen oder nutzerdefinierbaren Zugriffsmethoden basieren.

Mit SQL:1999 werden in diesem Jahr wichtige objektrelationale Sprachmittel normiert. Dazu gehören der Umgang mit großen Datenmengen (LOB-Datentypen), nutzerdefinierte Datentypen und Datenbankroutinen, verschiedene Typgeneratoren und typisierte Tabellen. An der Normung für den integrierten Zugriff auf extern erstellte und verwaltete Daten über Dateiverweise oder sogenannte abstrakte Tabellen und für einen verbesserten Datenzugriff aus objektorientierten Programmierspachen (Vorbild SQLJ) wird dagegen noch gearbeitet.

Das Typsystem von SQL:1999 ist unter anderem durch verschiedene Typgeneratoren und nutzerdefinierbare Datentypen erweiterbar. Letztere werden von SQL:1999 als strukturiert bezeichnet, die Attribute dieser inneren Struktur können orthogonal wiederum auf beliebigen Datentypen beruhen. Strukturierte Datentypen ermöglichen Methodendefinition, Objektidentität und -referenzierbarkeit, eine gewisse Datenkapselung und Einfachvererbung, darauf aufbauend Substituierbarkeit von Objekten und dynamisches Binden der Methoden. Die ursprünglich geplante Mehrfachvererbung wurde für SQL:1999 fallengelassen, Generik gibt es ebensowenig. Typgeneratoren dienen der Definition von Struktur-, Kollektions- und Referenzdatentypen, SQL kennt hier unbenannte Strukturen, Felder und Referenzen auf Objekte strukturierter Datentypen.

Die neuen Datentypen können analog zu vordefinierten Typen zur Definition von Attributen einer Datenbanktabelle genutzt werden, SQL erweitert auch die Datenmanipulationsmöglichkeiten entsprechend. Man beachte im übrigen, daß nutzerdefinierte Datentypen durchaus nicht dem Relationenmodell, der theoretischen Grundlage relationaler Datenbanksysteme, widersprechen, auch die Forderung nach skalaren Attributwerten (erste Normalform) ist bei genauem Hinsehen keine ernsthafte Hürde. Weiterhin sei angemerkt, daß eine zu tiefe Verschachtelung von Daten mit Hilfe nutzerdefinierter Datentypen auch Probleme mit sich bringen kann, insbesondere für vom Modellierer zunächst nicht vorgesehene Ad-hoc-Anfragen, bei denen relationale Datenbanksysteme aufgrund der anwendungsneutralen Datenmodellierung traditionell stark sind.

Eine andere Art der Verwendung nutzerdefinierter Datentypen sind typisierte Tabellen. Eine solche Tabelle wird bezüglich eines strukturierten Datentyps angelegt, dessen Struktur bildet zusammen mit einem Feld zur Aufnahme von Objektidentifikatoren die Tabellenattribute. Neben der gewohnten relationalen Nutzbarkeit kann die Tabelle dann auch als Container für Werte (Objekte) des strukturierten Datentyps angesehen werden; die einzelnen Tabellentupel repräsentieren die Zustände der abgelegten Objekte, auf die Objekte sind die zugehörigen Methoden anwendbar. Mit Hilfe der bereits genannten Referenzdatentypen können Tupel typisierter Tabellen direkt angesprochen werden, die Sprache erlaubt die Nutzung dieser Referenzen bei der Datenmanipulation mit Hilfe sogenannter Pfadausdrücke als Alternative zum mengenorientierten Tabellenverbund. Pfadausdrücke lösen die Referenzen zwischen Objekten auf und erlauben das Eindringen in deren Struktur. Vererbungsbeziehungen zwischen strukturierten Datentypen können auf darauf beruhende typisierte Tabellen ausgedehnt werden; es entstehen Tabellenhierarchien, in denen Tupel einer Subtabelle automatisch auch zu jeder Supertabelle gehören (extensionale Vererbung). Typisierte Tabellen eignen sich damit insbesondere zur Ablage von Objekten objektorientierter Anwendungen, für die auch auf der Datenbankebene selbst geeignete Manipulationsmöglichkeiten, z.B. komplexe mengenorientierte Anfragen, zur Verfügung stehen sollen.

Die Entwicklung von SQL:1999 wurde durch bereits vorhandene Produkte beeinflußt, schließlich sind führende Hersteller relationaler DBMS in den Normungsgremien vertreten. Informix war ein Vorreiter unter den großen Herstellern, auch Marktführer Oracle und IBM (DB2) bieten seit längerem objekt-relationale Funktionen. Leider lassen die Heterogenität der verschiedenen Implementierungen und die Unterschiede zur kommenden Norm Interoperabilität nur in sehr geringem Umfang zu. Es bleibt zu hoffen, daß sich das mit SQL:1999 allmählich ändert.

Die genannten Hersteller bieten neben der eigentlichen Funktionalität auch proprietäre Programmierschnittstellen und Werkzeuge an, die das Zusammenfassen nutzerdefinierter Erweiterungen in Paketen erleichtern. Solche auch von Drittanbietern und Endanwendern implementierbaren Pakete (Oracle: Cartridges, Informix: DataBlades, IBM DB2: Extenders) wurden zunächst u.a. für Text-, Zeitserien- und Bilddaten angeboten, prinzipiell ist die Technik aber für beliebige Erweiterungen verwendbar.

Nutzerdefinierbare Erweiterungen relationaler Datenbanksysteme wurden bisher vor allem im Rahmen der erwähnten Pakete von DBMS- oder Drittherstellern eingesetzt, der tagtägliche Einsatz objektrelationaler Modellierungsmöglichkeiten hält sich bisher in Grenzen. Das ist im wesentlichen auf die noch unzureichende und vor allem sehr heterogene Implementierung in den Produkten zurückzuführen, aber auch auf die oft recht komplexe physische Optimierung, etwa die Implementierung adäquater Zugriffspfade für neue Datentypen und Datenbankroutinen. Die neue SQL-Norm könnte hier auf funktionaler Ebene einen entscheidenden Schub bewirken, für eine Vereinfachung des physischen Datenbankentwurfs ist aber noch einiges an Entwicklungsarbeit zu leisten. Interessant für die weitere Entwicklung dürften unter anderem Bibliotheken neuer Datentypen und Datenbankroutinen sein, aber auch die verbesserte Einbindung externer Daten unter dem Stichwort der föderierten Datenbanken.

Vielversprechend erscheint der Einsatz objektrelationaler Datenbanksysteme insbesondere für die schon in größerem Umfang praktizierte Integration von Texten, Bildern und anderen Daten häufig genutzter Art in relationale Datenbanken, bei der Ergänzung existierender relationaler um objektorientiert modellierte Daten oder für den objektorientierten Zugriff auf vorhandene Daten. Mit nutzerdefinierten Datentypen und objektorientierten Konzepten erlauben objektrelationale Datenbanksysteme das Abspeichern und das direkte Manipulieren von Anwendungsobjekten ebenso wie ein flexibles Auffinden und Kombinieren dieser Objekte in Anfragen. Die Datenmodelle von Datenbanksystemen und den verschiedenen objektorientierten Programmiersprachen werden jedoch trotz gemeinsamer Grundlagen aufgrund der Sprachvielfalt nie völlig übereinstimmen. Diesem Nachteil stehen Sprachunabhängigkeit, eine ausgereifte Datenbanktechnologie, reiche Anfragemöglichkeiten und Mittel zum datenzentrierten Verlagern von Typ- und Anwendungslogik in das Datenbanksystem gegenüber.

1. Date, C. J., Darwen, H.: Foundation for Object/Relational Databases: The Third Manifesto. Addison-Wesley, Reading, MA, 1998
2. Eisenberg, A., Melton, J.: SQL:1999, formerly known as SQL3. ACM SIGMOD Records, 28(1), März 1999
3. ISO/IEC Final Committee Draft: Information Technology – Database Languages – SQL Multimedia and Application Packages (SQL/MM) – Part 1: Framework. Oktober 1998
4. ISO Working Draft: Information Technology – Database Languages – SQL – Part 9: Management of External Data (SQL/MED). März 1999
5. ISO Working Draft: Information Technology – Database Languages – SQL – Part 10: Object Language Bindings (SQL/OLB). März 1999
6. ISO/IEC 9075:1999: Information Technology – Database Languages – SQL – Part 2: Foundation (SQL/Foundation). 1999. To be published
7. Lufter, J.: Datentypkonzepte und funktionaler Vergleich einiger objektrelationaler Datenbanksysteme. Jenaer Schriften zur Mathematik und Informatik Math/Inf/99/02, Institut für Informatik, Friedrich-Schiller-Universität Jena, Februar 1999
8. Mattos, N.: From Object-Relational to Federated Databases. In: Tagungsband der GI-Fachtagung Datenbanksysteme in Büro, Technik und Wissenschaft (BTW), S. 185–209, Freiburg, März 1999
9. Srinivasan, V., Chang, D. T.: Object persistence in object-oriented applications. IBM Systems Journal, 36(1), 1997
10. Stonebraker, M., Moore, D.: Object-Relational DBMSs: The Next Great Wave. Morgan Kaufmann, San Francisco, CA, 1996

Jens Lufter
Friedrich-Schiller-Universität Jena, Institut für Informatik,
Ernst-Abbe-Platz 1–4, D-07743 Jena
lufter@informatik.uni-jena.de

© 1999 Informatik Spektrum, Springer-Verlag Berlin Heidelberg