Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

01.10.1993

Der fliessende Uebergang ist kein Ding der Unmoeglichkeit

Der Zukunftstechnologie OO-DBMS mangelt es derzeit noch an Marktpraesenz. Die Anbieter relationaler Systeme nutzen diese Chance, um ihre Produkte weiterzuentwickeln. Das erhoeht die Chancen fuer einen evolutionaeren Uebergang in die objektorientierte Welt. Die reine Lehre des Edgar Codd duerfte dabei allerdings auf der Strecke bleiben, so prognostiziert Michael Bauer*

Objektorientierte Datenbanken stellen eine Revolution dar: Zum einen heben sie die bisherige Trennung zwischen Anwendungsprogramm und Datenbanksystem auf. Es gibt also keine "klassischen" Anwendungsprogramme mehr, denn deren Funktionalitaet wird von Methoden oder "Objektfunktionen" uebernommen, die im DBMS ablaufen.

Zum anderen ignorieren OO-Datenbanken das bisher als richtungsweisend geltende Datenmodell - naemlich die Normalisierung - und unterstuetzen statt dessen komplexe Datenstrukturen. Damit ueberschreiten sie die Faehigkeit relationaler Datenbanken bei weitem.

Relationale Datenbanksysteme wie DB2 bieten den Anwendungsprogrammen nur triviale Funktionalitaet an. Sie koennen lediglich die vier Grundoperationen SELECT, INSERT, DELETE und UPDATE durchfuehren. Bereits das Wissen, wie die einzelnen Tabellen zu einer sinnvollen Informationseinheit zusammengefuehrt werden muessen, hat in den Anwendungsprogrammen zu stecken.

Darueber hinaus muss jede Applikation die Pruefung von Dateninhalten beziehungsweise von Abhaengigkeiten bei Einfuege-, Loesch- oder Aenderungsoperationen sowie bei davon abhaengigen Operationen selbst durchfuehren. Bei Erfassungs- und Aenderungsprogrammen koennen diese Funktionen bis zu 60 Prozent vom Coding ausmachen.

Im Gegensatz zu DB2 gibt es aber auch andere relationale Datenbanksysteme, die es erlauben, einen Teil dieses Codings in Form von Triggern und Stored Procedures in das Datenbank- Management-System zu verlagern. Hierzu gehoeren beispielsweise Ingres und Sybase sowie mittlerweile auch Oracle, SQL-DB und Informix. Damit sind diese Produkte zwar noch lange nicht objektorientiert, doch bieten sie eine Technologie, die die Basis fuer die Objektorientierung darstellen kann.

Allerdings bleiben diesen Datenbanksystemen die Einschraenkungen durch die Normalisierung der Daten erhalten - sowohl wegen der Theorie als auch wegen SQL. Denn die Sprachelemente dieser Abfragesprache unterstuetzen nur flache und keine komplexen Strukturen.

Damit verhaelt sich ein relationales DBMS wie jemand, der sein Auto nicht komplett in der Garage parkt, sondern dort einzelne Komponenten wie Raeder, Motor, Getriebe und Sitze ablegt. Wenn er dann fahren will, baut er sich aus diesen Einzelteilen sein Auto wieder zusammen. Kennt er aber die Montage-Anleitung nicht, so kommt ein recht eigenartiges Vehikel zustande. Anders bei den OO- Datenbanken: Dort werden alle Daten eines Objektes als Einheit verwaltet, was aufwendige Join-Operationen ueberfluessig macht und sich deshalb in besserer Performance niederschlaegt. Allerdings ist es wichtig, sinnvolle Objektklassen zu definieren.

Um solche Objekte zu finden, ist das bewaehrte Instrument eines Datenmodells hilfreich. Der Unterschied zur konventionellen Vorgehensweise besteht allerdings darin, dass die Daten nicht erst noch mittels Normalisierung zerlegt werden muessen. Vielmehr gehen die Entitaeten direkt in Objektklassen ueber.

Die Pruefregeln und Anweisungen, die mit Operationen gegen die Daten eines Objektes verbunden sind, werden dem DBMS durch Methoden mitgeteilt. Deshalb bietet ein OO-DDBMS maechtige Funktionsaufrufe statt einfacher Datenoperationen.

Eine Methode ist ein Programm-Modul, das in C++ oder einer anderen OO-Sprache geschrieben sein kann. Es umfasst alle Anweisungen, die mit einer sinnvollen Operation gegen das Objekt verbunden sind. So lassen sich zum Beispiel fuer das Objekt Auftrag folgende Methoden implementieren:

- Auftrag anlegen,

- Auftrag umterminieren,

- Auftrag ausliefern und

- Auftrag stornieren.

Wichtig ist dabei, dass eine Methode auch Nachrichten an ein anderes Objekt senden und dort eine Methode anstossen kann. Dadurch entstehen komplexe Ablaeufe, fuer die kein Anwendungsprogramm mehr noetig ist.

Es ist einsichtig, dass der Programmieraufwand fuer die erste dieser Anwendungen noch genauso hoch ist wie bei konventionellen DBMS- Applikationen, da die Befehle lediglich anders codiert werden. Doch je mehr Anwendungen die gleichen Daten verwenden, desto geringer wird der Aufwand im Einzelfall.

Diesen Anspruch koennen relationale Datenbanksysteme mit Triggern und Stored Procedures ebenfalls erheben. Doch eine OO-Datenbank weist darueber hinaus eine weitere wichtige Eigenschaft auf: die Vererbung. Sie ermoeglicht die Bildung von Subklassen, die automatisch die Methoden der uebergeordneten Klasse nutzen.

So bilden zum Beispiel "PKW" und "LKW" zwei spezialisierte Subklassen von "Kraftfahrzeug". Fuer diese Unterklassen sind nur noch die abweichenden Methoden zu definieren; alle uebrigen Methoden werden automatisch mit genutzt. So kann der Grad der Wiederverwendbarkeit deutlich erhoeht werden, falls sich sinnvolle Klassenhierarchien finden lassen.

Trotz der geschilderten Eigenschaften ist die Bedeutung objektorientierter Datenbanken noch gering. Dafuer gibt es im wesentlichen fuenf Gruende: Der erste haengt mit dem Paradigmenwechsel zusammen. OO-Datenbanken stellen einen so andersartigen Ansatz dar, dass sie nur bei Neuentwicklungen eingesetzt werden koennen. Weder die Datenstrukturen noch die Anwendungsprogramme lassen sich sinnvollerweise uebernehmen.

Geringe Verbreitung im kommerziellen Bereich

Ein weiteres Hindernis fuer eine breite Marktdurchdringung ist die mangelnde Produktreife. Die OO-Datenbanksysteme sind alle noch recht jung. Die aeltesten Produkte erschienen erst Ende der 80er Jahre auf dem Markt, andere existieren erst seit kurzem als Beta- Release. Wenn man die Reifezeit eines DBMS mit fuenf bis acht Jahren beziffert - wofuer DB2 ein gutes Beispiel gibt -, so haben die OODBMS-Produkte noch einen langen Weg vor sich.

Hemmend auf den Absatz wirkt sich auch die eingeschraenkte Zahl der unterstuetzen Plattformen aus. Zur Zeit werden OO-Datenbanksysteme im wesentlichen auf Unix-Plattformen und PCs, aber nicht fuer Grossrechner angeboten. Damit bleibt ihr Einsatzgebiet auf dezentrale Anwendungen begrenzt. Allerdings sind die meisten Produkte als Client-Server-Loesung ausgelegt, wodurch sie wiederum fuer die Zukunft geruestet sein duerften.

Die bislang geringe Verbreitung im kommerziellen Bereich ermutigt die Anwender auch nicht gerade zur Nachahmung. Zwar weisen die Produkte zum Teil hohe Verbreitungszahlen auf - bei einigen werden mehrere hundert Installationen genannt -, doch stammen die meisten Anwender immer noch aus dem universitaeren Raum.

Schliesslich gibt es bei den OO-Datenbanksystemen - im Gegensatz zu den relationalen Datenbanken, wo Edgar Codd eine verbindliche und praezise Definition geschaffen hat - keinen Standard. Zwar hat inzwischen eine Gruppe von Wissenschaftlern unter der Bezeichnung "Manifesto" einige Basis-Regeln fuer OO-Datenbanksysteme definiert. Noch nicht festgelegt wurden dabei jedoch die Sprachmittel fuer Methoden und Abfragen. Dementsprechend wird ein Anwender mit dem einmal ausgewaehlten OO-DBMS quasi "verheiratet" sein.

Insbesondere die Probleme des Paradigmenwechsels und des fehlenden Standards lassen es fraglich erscheinen, ob sich die OO- Datenbanksysteme ueberhaupt auf breiter Ebene durchsetzen werden - zumal die Konkurrenz auf der relationalen Seite auch nicht schlaeft. Entwicklungen in Richtung Trigger und Stored Procedures sind nur ein erster Schritt. Die Moeglichkeit zur Definition eigener Datentypen und Operationen, wie sie bereits von Ingres angeboten wird, geht schon ein bisschen weiter. Was noch fehlt, sind Vererbungsmechanismen und die Abbildung komplexer Strukturen.

Letzteres wird den derzeit verfuegbaren relationalen Datenbanken schwer fallen, da es Konsequenzen bis auf die Speicher-verwaltung und Zugriffsmechanismen hat. Lediglich "Binary large objects" (Blobs) anzubieten, genuegt nicht. Denn dabei handelt es sich nur um ein unstrukturiertes Grossfeld, dessen Verwaltung das Anwendungsprogramm selbst uebernehmen muss. Suchoperationen gegen einzelne Inhaltsteile sind damit nicht moeglich. Eher geeignet waere die Speicherstruktur eines so alten DB-Systems wie IMS. Ein Objekt wuerde dabei einem "Datenbanksatz" des IMS entsprechen. Deshalb hat auch ein Datenbanksystem wie Adabas technisch gesehen die besten Ausgangsmoeglichkeiten fuer die Objektorientierung. Einerseits unterstuetzt es komplex strukturierte Daten, andererseits besitzt es eine Technologie fuer Klassen und Methoden - den "Active View Processor", der mittlerweile in einer Beta-Version vorliegt. Dass eine evolutionaere Entwicklung relationaler Datenbanksysteme in Richtung OO moeglich ist, belegen experimentelle Systeme wie Postgres (eine Weiterentwicklung auf Basis von Ingres) oder Iris von Hewlett Packard. Dabei wird die Basis-Technologie, die in jedem DBMS steckt, benutzt, um darauf die erforderlichen zusaetzlichen Funktionen aufzubauen.

Allerdings ist die Aussage, dass die Datenbank-Zukunft "relational plus objektorientiert" sei, etwas zu stark vereinfachend. Denn von den relationalen Prinzipien, wie Codd sie formuliert hatte, bleibt nicht mehr viel uebrig. Was kuenftig weiter verwendet werden kann, sind lediglich technologische Komponenten wie SQL-Parser, Optimizer oder Prozedur-Interpreter, also Technologien grundsaetzlicher Art, die sich mit jedem DB-Modell einsetzen lassen(siehe links).

Allerdings gibt es die Moeglichkeit fuer einen fliessenden Uebergang: Die relational konzipierten Anwendungen laufen weiter, waehrend neue Anwendungen die objektorientierten Erweiterungen nutzen. Deshalb ist es wichtig, dass die Sprachschnittstelle SQL erhalten bleibt und lediglich erweitert wird. Weil fuer solche Erweiterungen noch kein Standard existiert, besteht allerdings die Gefahr, dass jeder Datenbankhersteller seine eigenen Erweiterungen propagiert - so wie es vor SQL2 bereits der Fall war. Was wir uns von der Objektorientierung erwarten - Wiederverwendbarkeit, leichtere Wartbarkeit und Erweiterungsfaehigkeit -, tritt durch den Einsatz eines OO-Datenbanksystems keineswegs automatisch ein. Ein solches Werkzeug ist dafuer ueberhaupt nicht noetig. Vielmehr entstehen die gewuenschten Ergebnisse erst durch einen methodischen Design- Prozess.

Die objektorientierte Analyse, die einen systematischen Weg bietet, um Daten und Funktionen gemeinschaftlich zu betrachten und eine saubere Klassenhierarchie zu schaffen, existiert unabhaengig von dem spaeteren technischen Traegersystem. Ein auf diese Weise geschaffenes Modell laesst sich - gegebenenfalls mit einigen Abstrichen - auch durch konventionelle Sprachen und Datenbanken umsetzen. Auf diese Weise ist es sogar Mainframe-Anwendern moeglich, die Chancen der Objektorientierung zu nutzen. Fuer die Realisierung existieren heute bereits Regelwerke wie die DMO- Methode von Plenum, die OO-Prinzipien in ein praktikables Vorgehen einbettet. Die Ergebnisse des Design-Prozesses lassen sich dabei mit verschiedenen Technologien umsetzen.

Objektorientierte Datenbanken haben heute zwar in der Praxis noch keine Bedeutung. Aber OO-Konzepte werden kuenftig eine grosse Rolle spielen - insbesondere dann, wenn sie von etablierten Datenbanksystemen adaptiert werden. Trotzdem sollten die Anwender nicht so lange warten, bis die Technologie reif ist, sondern Objektorientierung als Analyse- und Design-Methodik heute schon nutzen.

*Michael Bauer ist Geschaeftsfueher der Informatik Training GmbH, Radolfzell.

Das OODBMS baut auf der Grundtechnik des RDBMS auf