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.

13.10.1995

Datenbanken/Leistungsverluste auf dem Weg zur integrierten Loesung Wie passen relationale und Objektdatenbanken zusammen?

Von Thomas Blummer*

Eine verbreitete Annahme lautet, dass relationale und objektorientierte Datenbanken zusammenwachsen. Die beiden Konzepte widersprechen sich jedoch in ihren Grundanlagen diametral. Gleichwohl gibt es Bruecken zwischen den Systemen. Insbesondere fuer eine postulierte Uebergangszeit bieten sie die Moeglichkeit fuer das Zusammenspiel relationaler mit oblektorientierten Daten.

Relationale Datenbanken sollen den konkurrierenden Zugriff mehrerer Anwendungen auf eine gemeinsame Datenbasis ermoeglichen. Ziel ist die anwendungsunabhaengige Praesentation der Daten und ihrer primitiven Verknuepfungen.

Darueber hinaus dient dieses der Wiederverwendbarkeit von Daten in neuen Anwendungen und erhoeht die Produktivitaet der Software- Entwicklung, da es einen freien und formalisierten Zugriff auf die Daten bietet.

Mit wachsender Komplexitaet des unternehmensweiten Datenbestandes werden aber grundlegende Schwaechen des relationalen Modells sichtbar. Die anwendungsunabhaengige und datenzentrische Repraesentation der Daten verlangt, dass die Anwendungen mit dem immer komplexer werdenden Datenmodell "mitwachsen". Sie traegt dadurch zum - auch sonst massgeblichen - Wartungskostenanteil der Anwendungsbasis bei.

Das aendert nichts am Bedarf an einer vereinfachten Datenrepraesentation. Sie muss der Komplexitaet des darunterliegenden Datenmodells gerecht werden und sie trotzdem handlich darstellen. Sie soll die unwichtigen Details verdecken sowie die Daten und zulaessigen Operationen auf den Daten als eine Einheit behandeln.

Dies fuehrt immer haeufiger zum Einsatz einer Objektdatenbank. Denn eine Objektdatenbank bietet eine andere, neue Sicht auf die Daten. Sie kombiniert die Strenge einer zentralisierten Datenhaltung und die Vorteile der objektorientierten Software-Entwicklung.

Die Objektdatenbank ist keine "alternative" Datenhaltung, sondern ein unweigerlicher Evolutionsschritt der Technologie. Sie erweitert die von den traditionellen Datenbanken eingefuehrte Anwendungsunabhaengigkeit der Daten auf die Beziehungen zwischen ihnen und die zulaessigen Operationen, die man mit den Daten durchfuehren kann.

Objektdaten sollen Qualitaet und Produktivitaet steigern

Das Ziel bei der Eingliederung einer Objektdatenbank in die DV- Infrastruktur eines Unternehmens ist eine effizientere Datenverarbeitung sowie Produktivitaets- und Qualitaetssteigerung bei der Software-Entwicklung und -Wartung. Wie ist aber die neue Technologie in die vorhandene Dateninfrastruktur einzubinden? Fuer eine Antwort auf diese Frage sind zwei bedeutende Unterschiede zwischen relationaler und objektorientierter Technologie relevant:

1. Da Objekte nicht nur Daten sind, ist das Speichern von Objekten in traditionellen Datenbanken mit Informationsverlust verbunden.

2. Datensaetze besitzen keine Identitaet ausser ihrem Inhalt. Deshalb muessen Datensaetze, die in einer Objektdatenbank als Objekte gespiegelt werden, entweder eine datenunabhaengige Identitaet erhalten, oder sie duerfen die Aenderung der Inhalte, die die Objektidentitaet bestimmen, nicht zulassen.

Objekte zu zerlegen ist schlichtweg toericht

Die erste Huerde der Integration ist intuitiv ersichtlich. Selbstverstaendlich waere es toericht - wenn keine aeusseren Restriktionen es erfordern -, Objekte, die bereits als solche in der Anwendung existieren, auseinanderzunehmen, nur um sie in einer relationale Datenbank speichern zu koennen. Dass dies eine aufwendige und fehleranfaellige Prozedur ist, haben Projekte der juengsten Vergangenheit zur Genuege bewiesen. Gerade die unertraegliche Schwerfaelligkeit des Auf- und Abbaus der Objekte in einigen komplexen Anwendungen war der treibende Motor der Entwicklung der ersten Objektdatenbanken.

Objekte gehoeren in eine Objektdatenbank. Eine Zerlegung in Tabellen und, damit einhergehend, die dem objektorientierten Ansatz fundamental widersprechende Aufspaltung zwischen Daten und Funktionen, muss auf Notfaelle beschraenkt bleiben.

Umgekehrt erscheint eine Integration relationaler Daten in eine Objektdatenbank problemloser. Trotzdem ist auch eine solche Vorgehensweise bei weitem nicht trivial. Datensaetze, die in relationalen Datenspeichern hinterlegt sind, verweisen gegenseitig auf ihren Inhalt, indem sie einen Mechanismus aus "Fremdschluesselfeldern" benutzen.

Der Aufbau eines Objektnetzes, das die aktuelle Beziehung der Daten zueinander repraesentiert, ist in Kenntnis der Bedeutung dieser Fremdschluesselfelder einfach. Problematisch ist dagegen die Wahrung dieser Konsistenz nach einer Aenderung der gespiegelten Datensaetze. Die Definition einer inhaltsunabhaengigen Objektidentitaet erfordert es, das als Spiegelbild der relationalen Struktur dienende Objektnetz immer wieder neu zu ueberarbeiten. Eine inhaltsabhaengige Objektidentitaet dagegen setzt voraus, dass das Datenmodell der Anwendung die Aenderung der fuer die Bildung der Objektidentitaet relevanten Felder ausschliesst.

Unter zwei gaenzlich verschiedenen Loesungen gilt es zu waehlen, nachdem der Umstieg auf die neue Softwaretechnologie als notwendig erkannt ist. Zum einen locken Hersteller relationaler Datenbanken mit objektorientierten Erweiterungsschichten. Zum anderen gibt es Objektdatenbanken mit Schnittstellen zu relationalen Datenbanken.

Kein Votum fuer eine objektbasierte Erweiterung

Zunaechst scheint viel fuer die erste Alternative zu sprechen, da man sich von ihr den sanfteren Umstieg erwartet. Doch es spricht vieles dafuer, dass diese Entscheidung nicht nur leicht, sondern auch leichtfertig sein koennte. Objekte sind nicht einfach eine zusaetzliche Schicht auf den Daten. Das Ziel der Objektorientierung ist ja keine neue Abstraktionsebene mit neuen Leistungseinbussen auf der alten Datenbank, sondern eine Leistungssteigerung in der Datenhaltung.

Da sich bei relationalen Datenbanken der grundlegende Speichermechanismus, naemlich die Zergliederung von intakten Objekten in Tabellen, nicht aendert, ist die relationale Datenbank mit einem Objektaufsatz lediglich fuer Anwendungen geeignet, bei denen Performance nur eine untergeordnete Rolle spielt.

Wenn neue Anwendungen mit objektorientierten Sprachen entwickelt werden, sollte sie auch eine objektorientierte Datenbank verwalten. Nur so lassen sich die erwuenschten Leistungen tatsaechlich erreichen. Zur Integration der zwei Datenbanktypen erscheinen demnach Schnittstellen von der objektorientierten zur relationalen beziehungsweise hierarchischen Welt als bessere, wenn auch nicht ideale Loesung.

Es gibt sowohl Werkzeuge fuer die Einbindung relationaler Daten in die Objektdatenbank als auch fuer den Zugriff auf Objekte mit traditionellen Abfragewerkzeugen. Diese Komponenten gewaehrleisten die Unterstuetzung der Programmiersprachen C++ und Smalltalk sowie der Abfragesprache SQL und stellen dem Anwender verschiedene Modelle fuer das Speichern und Wiederauffinden von Daten zur Auswahl. Der Einsatz von Gateway-Diensten fuer den Austausch von Daten und Befehlen zwischen der Objektdatenbank und anderen Datenbanken macht es moeglich, dass Applikationen ueber ein objektorientiertes API auf verschiedene Datenbanktypen zugreifen koennen.

Ein weiterer Weg zur Loesung des Integrationsproblems ist das Schema-Mapping. Dabei lassen sich native Datenmodelle zwischen Objektdatenbank und proprietaeren beziehungsweise relationalen Datenbanken "mappen", das heisst, in einer Art Zwischenspeicher gemeinsam nutzen. Durch Schema-Mapping koennen relationale Datenbanken und Tools Objekte als Tabellen und Reihen lesen. Umgekehrt kann man in relationalen Systemen abgelegte Tabellen als Objekte bearbeiten.

Mit diesen oder aehnlichen Techniken lassen sich also bereits heute Objektdatendanken in gewachsene Strukturen integrieren. Allerdings gehen alle diese Techniken zu Lasten der Performance des Gesamtsystems. Die eierlegende Wollmilchsau gibt es auch in diesem Bereich der DV nicht. Wer sie verspricht, fuehrt bewusst in die Irre.

Weder das objektorientierte Haeubchen auf einer relationalen Datenbank noch die diversen Integrationstechniken von objektorientierter Seite loesen das Problem restlos. Dazu sind die grundlegenden Konzepte der Technologien zu unterschiedlich. Im Zweifel sind aber letztere vorzuziehen, da es wesentlich einfacher ist, die simplen Beziehungen einer relationalen Datenbank objektorientiert nachzubilden, als anders herum das komplexe Innenleben eines Objektes und dessen vielschichtige Beziehungen zu anderen Objekten in Tabellen zu pressen.

*Thomas Blummer ist Systemberater bei der Object Design Software GmbH in Wiesbaden.