Relationale Datenbanken haben Konkurrenz bekommen: Objektdatenbanken wird ein aehnlicher Boom vorausgesagt wie relationalen Systemen Anfang der Achtziger. Bei komplexen Aufgabenstellungen ist die neue Technik aufgrund ihres flexibleren Ansatzes ueberlegen.

Die Konzepte von Daten-Management und Datenhaltung haben sich in den letzten 30 Jahren zweimal entscheidend geaendert: erst mit der Marktreife von hierarchischen, dann mit der relationaler Systeme. Zur Zeit laesst sich bei den Objektdatenbanken ein weiterer, genauso wichtiger Entwicklungsschub beobachten. Aehnlich wie vor etwa einem guten Jahrzehnt, als zu den ueberwiegend hierarchischen Datenbanksystemen die relationalen Datenbanken auf den Markt kamen, sehen sich Anwender heutzutage unter Zugzwang.

Damals diskutierte man die Frage, ob man sein hierarchisches System gegen eine relationale Datenbank austauschen sollte - beide Loesungen bestehen immer noch. Von dem viel zitierten "Paradigmenwechsel" kann nicht die Rede sein.

Heute stehen relationale und objektorientierte Systeme im Mittelpunkt der Diskussion. Da erneut die wenigsten Unternehmen willens und faehig sind, ihr Daten-Management komplett auf eine neuere Technologie umzustellen, lautet die Entscheidung mittelfristig nicht "Entweder - Oder", sondern: "Welche Technologie wo?" Die Anfang der 80er Jahre auf den Markt gekommenen relationalen Datenbank-Management-Systeme (RDBMS) in Verbindung mit der Datenbanksprache Structured Query Language (SQL) zaehlen zu den heute am haeufigsten benutzten Speicherungsinstrumenten.

Vorteile gegenueber den hierarchischen Systemen wie IMS von IBM sind die logische Unabhaengigkeit der Daten vom eigentlichen Speicherungsverfahren, die vermeintlich einfache Bedienung sowie die mathematische Grundlage der Relationenalgebra. Die Ablage von Informationen erfolgt bei diesen Systemen mit Hilfe verschiedener Listen, in die jeweils Daten gleicher Natur hineingeschrieben werden. Sollen Daten aus verschiedenen Listen zu einer Information zusammengefasst werden, prueft ein Suchalgorithmus Feldgleichheiten zwischen den Listen und bringt die als zusammengehoerig entdeckten Datenfelder mit einem "Join" zusammen.

Relationale Datenbanken haben Vorteile bei Anwendungen mit sehr hohen Transaktionsraten auf einfache Datenstrukturen gebracht. Die Verwaltung von Geldautomat-Eingaben, die Erfassung von Messdaten oder die Kontofuehrung und Flugbuchungssysteme sind Anwendungen, die auf Basis eines relationalen Systems nahezu optimal funktionieren.

Wenn jedoch Datenmengen von komplexer Struktur mit vielen Beziehungen untereinander - zum Beispiel dreidimensionale Volumenmodelle, Simulationsgrafiken und Workflow-Anwendungen - verwaltet werden muessen, stossen relationale Systeme schnell an ihre Grenzen. Solche komplexen Daten muessten erst in ihre Bestandteile zerlegt werden, um anschliessend in vordefinierte Listen einsortiert zu werden. Das Lesen der Daten wuerde dann genau umgekehrt erfolgen.

Mit Hilfe der Joins und der definierten Feldgleichheiten muessten relationale Systeme die Daten wieder aus den einzelnen Bausteinen zusammensetzen. Was bei einfachen Beziehungen sinnvoll ist, wird bei n-zu-m-Beziehungen, die komplexe Datenstrukturen charakterisieren, untauglich. Das ganze Verfahren waere zu aufwendig und ginge massiv zu Lasten der Performance. Doch in immer mehr Anwendungsbereichen fallen heute komplexe Datenstrukturen an: in der Bueroautomation, bei der Modellierung von Produkten und Unternehmensvorgaengen sowie bei Multimedia- oder anspruchsvollen Workgroup-Anwendungen. Mit konventionellen Methoden wie der strukturierten Programmierung in Verbindung mit einem relationalen Datenbanksystem lassen sich die immer vernetzter werdenden Aufgaben und Anwendungen nicht mehr zufriedenstellend loesen.

Die reale Welt besteht nun einmal fast ausschliesslich aus komplizierten, verschachtelten und komplexen Zusammenhaengen. Diese gilt es nun in einem Datenbanksystem moeglichst vollstaendig zu beschreiben. Diese Anforderungen an Datenbanksysteme waren die Ausloeser fuer objekt- orientierte Datenbank-Management-Systeme (OODBMS).

Der objektorientierte Ansatz, vor den Datenbanksystemen bereits in Benutzeroberflaechen und Programmiersprachen realisiert, versucht, der menschlichen Denkweise so weit wie moeglich zu entsprechen. In diesem Konzept wird es abgelehnt, funktionale Einheiten bei der Speicherung aufzubrechen.

Voraussetzung fuer neue Anwendungen

Vielmehr sind objektorien- tierte Datenbanken in der Lage, Objekte - als Einheiten von Daten und Funktionen, wie sie, mit Hilfe von objektorientierten Sprachen erzeugt, fluechtig im Hauptspeicher vorliegen, - per- sistent abzuspeichern. Ein Objekt wird also nicht zerstueckelt, sondern liegt auch im Speichermedium in der gleichen verzweigten Struktur vor, in der es sich im Hauptspeicher befand. Mit der Moeglichkeit, Daten als Objekte in den Hauptspeicher lesen zu koennen, anstatt sie mit Hilfe von Select- Statements und vielen hundert Instruktionen zusammensetzen zu muessen, steigt natuerlich die Gesamtleistung des Systems. Wichtiger noch: Objektdaten sind die Voraussetzung fuer neue, zukunftstraechtige Anwendungen in Bueroautomation, Workflow-Systemen und Multimedia-Applikationen.

Mit ihrer Hilfe sind vernetzte Strukturen wesentlich einfacher modellierbar.

Der Grund dafuer und ein weiterer wesentlicher Unterschied zwischen beiden Datenbankkonzepten besteht in dem Program- mieraufwand: Der Entwickler einer relationalen Datenbank besitzt nur eine begrenzte Anzahl von Datentypen, mit denen er seine zu speichernden Informationen darstellen muss. Diese Datentypen - in der Regel Basis- typen wie Integer, String, Datum - kann er nicht erweitern.

Daher muss der Programmierer eine komplexe, vernetzte Datenstruktur erst einmal von Hand in eine einfache, listenorientierte Datenstruktur ueberfuehren. Ist das geschehen, ist ein Algorithmus zu entwickeln, der den zerstueckelten Datenkomplex rekonstruiert oder ihn beim erneuten Abspeichern wieder auseinanderreisst. Mit einem objektorientierten System hingegen lassen sich Typen und Klassen auf der Applikationsebene innerhalb des Datenbanksystems direkt verwenden. Der Programmieraufwand fuer das Zusammensetzen der strukturlosen, "blanken" Daten entfaellt, die Struktur wird sozusagen mitgespeichert. Einmal implementierte Klassen und deren Objekte lassen sich dann in jeder neuen Applikation wiederverwenden. Des weiteren muessen bei einer relationalen Datenbank die impliziten Zusammenhaenge zwischen Objekten - beispielsweise die Beziehung zwischen einer Adresse und einer Person, der Verweis von einer Person zu einer anderen (von den Eltern auf die Kinder) oder die Abhaengigkeiten unter den Absaetzen eines Dokumentes - vollstaendig von der Datenbankanwendung selbst hergestellt werden. Was ist daran so unvorteilhaft? Wichtige Semantik liegt in zusaetzlichem Code und nicht in der Datenbank selbst!

Fuer Updates, Pflege und Wartung solcher Systeme bedeutet dies einen immensen Programmier- und Zeitaufwand. Zudem ist bei relationalen Systemen wegen der Trennung von Daten und Datenbankanwendung das Problem der Konsistenz der im System abgelegten Informationen aeusserst heikel. Gerade im Hinblick auf Qualitaetssiche- rungs-Konzepte wie ISO 9000 macht sich der relativ geringe Pflegeaufwand von Objektdatenbanken bezahlt.

Dennoch: Umfangreiche, aber relativ einfache Datenstrukturen, wie sie sich in Adress- und Personalverwaltung oder der Listenfuehrung einer Lagerhaltung finden, lassen sich mit relationalen Datenbanken sehr gut verwalten. Bei solch einfachen Strukturen bieten objektorientierte Datenbanken keinen systembedingten Vorteil. Ausserdem sind sie fuer solche Anwendungen noch nicht optimiert. Ein sicherlich nicht zu unterschaetzender Gesichtspunkt ist, dass viele Anwendungen auf der Basis von relationalen Systemen gut laufen - hier einen "Paradigmen-Shift" herbeizureden, ist nicht realistisch. Bei der Entwicklung von neuen Anwendungen hingegen ist sehr wohl zu fragen, ob das objektorientierte Modell nicht das zukunftstraechtigere ist.

Derzeit vor allem im Technik-Bereich stark

Schliesslich ist relationale Technik am Ende ihres Weges, viel Innovatives steht nicht mehr zu erwarten. Zu fragen ist, wie es um die Standards bei relationalen Systemen bestellt ist. Wird SQL 3 angesichts der objekt- orientierten Modelle jemals kommen? Oder kurz: Wie sehen relationale Datenbanken in drei Jahren aus?

Objektorientierte Systeme finden ihre Anwendungsgebiete zur Zeit noch verstaerkt in der technischen Domaene wie zum Beispiel bei CAD/CAM. Bald werden sie wegen der oben skizzierten Staerken aber auch in die Bereiche Bueroautomation, Workgroup-Computing und Multimedia eindringen. Mega-Konzepte wie das unternehmensweite Repository lassen sich nach Einschaetzung von Experten ueberhaupt nicht anders realisieren als auf Basis von objektorientierten Datenbanken. Eine Studie von IDC prognostiziert fuer Objektdatenbanken denn auch ein aehnliches Marktwachstum wie vor etwa zehn Jahren fuer relationale Datenbanken.

Den fuer andere Datenbank- und 4GL-Systeme vorhergesagten Marktzuwachsraten von etwa 20 Prozent stehen - allerdings auf zunaechst deutlich niedrigerem absoluten Niveau - etwa 100 Prozent pro Jahr fuer objektorientierte Datenbanksysteme gegenueber.

* Stephan Rasp ist Geschaeftsfuehrer der Object Design GmbH inWiesbaden.

Datenablage mit objektorientierten Datenbanken

Datenablage mit relationalen Datenbanken