Die Hymnen auf relationale Datenbanken sind noch nicht verklungen, und schon erhalten die Marketingstrategien für objektorientierte Datenhaltungsprodukte ihren letzten Schliff. Was objektorientierte Datenbanken sind und in welcher Beziehung sie zu den objektorientierten Programmiersprachen stehen, erklärt Harald Summa*.
Die Datenhaltungsseite der objektorientierten Datenverarbeitung hat sich parallel zu den objektorientierten Programmiersprachen entwickelt. Auf getrennten Wegen folgten Datenbankentwicklung und Programmiersprachen dem gleichen Trend: weg von Bit und Byte, hin zur Objektorientierung mit mächtigen Konstrukten und Strukturen.
Smalltalk 80 gilt als die reine Lehre
Objektorientierte Verfahren wurden lange Zeit in ihrer Bedeutung unterschätzt, während die relationalen Ansätze die Diskussion dominierten. Böse Zungen behaupten gar, daß der Auf stieg objektorientierter Datenbanken auf den Mißerfolgen der relationalen Systeme beruht.
Bei objektorientierten Programmiersprachen ist die Begriffsbestimmung einfacher als bei objektorientierten Datenbanken. Da es sich um einen neuen Zweig der Datenbanktechnologie handelt, wird noch viel experimentiert und es gibt noch keine Produkte, die dem Stadium des Prototypen entwachsen sind.
Der Begriff der Objektorientierung stammt aus den 60er Jahren. Damals wurden in der Programmiersprache Simula die ersten Möglichkeiten ausprobiert, mit Objekten an Stelle von Datensätzen zu arbeiten. Klassisches Vorbild einer echten objektorientierten Sprache ist heute aber SmalItalk 80.
Objekte sind in Smalltalk und allen sonstigen "echten" objektorientierten Sprachen wie zum Beispiel Eiffel das, was in den prozeduralen oder deklarativen Sprachen in einem Programm fein säuberlich voneinander getrennt ist: Eine Verbindung von Code und Daten. Ein Objekt besteht also aus Daten und den zu ihnen gehörenden Programmen oder Methoden.
Objekte der gleichen Art, mit den gleichen Eigenschaften werden zu Klassen zusammengefaßt. Die Eigenschaften sind in den Klassen vererbbar. Dieser Ansatz schafft Raum für die Darstellung beliebiger und beliebig komplexen Strukturen, die in ihrer Begrifflichkeit und Semantik der realen Welt entsprechen. So wird zum Beispiel das Objekt "Roboter" im gesamten definiert und bearbeitet und nicht mehr über seine einzelnen Komponenten, die auf viele Datensätze verteilt sind.
Die Problematik der objektorientierten Sprachen liegt in der Fixierung dieser komplexen Strukturen, wie sie von Datenbanken bekannt ist als persistente Information. Bisweilen sind die Objektwelten - wie etwa in der Programmiersprache Lisp - in einem virtuellen Adreßraum abgelegt und haben keine direkte Schnittstelle zu einer wie auch immer gearteten traditionellen Datenhaltung.
Relationale DB-Ansätze zerlegen die Datenobjekte
Traditionelle Datenhaltung bedeutet hier aber im Theoretischen wie im Praktischen den Einsatz eines Datenverwaltungssystems, im besten Fall eines relationalen Datenbank-Management-Systems. Diejenigen, die sich mit dem relationalen Datenmodell beschäftigt haben, wissen, daß die Betrachtung einer realen Datenwelt über den Umweg einer Normalisierung der. Daten führt und dies eine Zerlegung der Datenobjekte in atomare Tupel bedeutet. So ist der Roboter als Datenobjekt in seine atomaren Bestandteile zu zerlegen, die dann in Tabellen abgelegt werden.
Dieses Aufbrechen der Daten ist für sehr viele, insbesondere kommerziell orientierte DV-Problemstellungen ein notwendiges, aber tragbares Übel. Immerhin schafft die Normalisierung ein klares Bild für das DV-Design hinsichtlich der verwendeten Daten und ihrer Beziehungen. In der technischen DV-Welt ist ein Aufbrechen von Datenobjekten auf normalisierte Tabellen aber mit einem größeren Aufwand verbunden. Sobald die zerlegten Objekte wieder zur Laufzeit zusammengesetzt werden, treten mit Sicherheit Performance-Probleme auf.
Zielsetzung der Datenbankentwickler ist es nun, ein Datenbanksystem mit einem objektorientierten Datenmodell zu entwickeln, das allen wesentlichen - Forderungen der Programmiersprachen- und der Datenbankwelt gerecht wird. Das System muß insbesondere:
- eine persistente Datenhaltung haben,
- eine Hintergrundspeicherverwaltung ermöglichen,
- einen Mehrbenutzerbetrieb erlauben,
- über Recoverymechanismen verfügen und
- her Ad-hoc-Anfragen zugänglich sein.
Dies sind Eigenschaften, die den objektorientierten Sprachen weitestgehend fehlen. Trotzdem werden natürlich Eigenschaften verlangt wie Datenintegritäts- und Konsistenzsicherung, Datenunabhängigkeit, Datenschutz und Datensicherung und last but not least Datenverteilung.
Typisch ist die Forderung nach beliebig zusammengesetzten Objekten und benutzerdefinierbaren Typen, die bisher den Datenbanken fehlte. Auch diese Forderung ist zusätzlich zu den allgemeinen Eigenschaften von Objektorientierten Sprachen wie Objektidentität, Einkapselung, Typen/Klassen von Objekten mit Hierarchie und Vererbung zu stellen.
Wie bereits erwähnt, gibt es bisher noch keine einheitliche Definition objektorientierter Datenbanken. Kein Papst oder Guru hat bisher die zehn goldenen Regeln für objektorientierte Datenbanken verkündet. Allerdings finden sich unterschiedliche Ansätze in verfügbaren Produkten, die vermuten lassen, daß in etwa fünf oder sechs Jahren echte objektorientierte Systeme verfügbar sein werden. Eine gute Perspektive, bedenkt man, daß relationale Systeme etwa 20 Jahre gebraucht haben, um vom theoretischen Entwurf bis zur Marktdurchdringung zu gelangen!
Professor Dittrich von der ETH Zürich hat diese "postrelationalen" Ansätze zu Systemen mit struktureller und verhaltensmäßiger Objektorientierung zusammengefaßt. Danach arbeiten strukturelle Systeme mit konzeptionellen Objektstrukturen, die bisherige semantische Modelle erweitern. Erweitert werden entweder relationale Systeme oder das Relationenmodell.
Zu diesem Ansatz gehören auch Systeme mit geschachtelten NF2-Relationen. NF2 (non first normal form) bedeutet "nicht normalisierte" Relationen und ermöglichen das Speichern weiterer Tabellen als Datenelement innerhalb einer Tabelle, die wiederum ineinander geschlachtet werden können. Auf diese Art lassen sich mächtige Datenobjekte definieren. Ein wesentlicher Vorteil bei diesem Ansatz ist, daß die positiven Eigenschaften relationaler Systeme erhalten bleiben. Auch kann zum Beispiel SQL als Abfragesprache mit Erweiterungen genutzt werden.
Das vollständige NF2-Modell ist bisher noch in keinem kommerziell verfügbaren Produkt verwirklicht, aber an vielen Stellen wird an ihm gearbeitet. Unter anderem verfolgt das Heidelberger Forschungszentrum der IBM diese Richtung.
Auf Seiten der verhaltensmäßigen Objektorientierung finden sich unterschiedliche Ansätze, die von den Entwicklungen in den objektorientierten Programmiersprachen geprägt sind. In dieser Klasse gibt es auch bereits Systeme, die vermarktet werden, wie das Lispbasierte System Statice von Symbolics.
Die voll-objektorientierten Systeme befinden sich alle noch im Prototyp-Stadium. Zu den bekannteren gehört Postgres, das designierte Nachfolgesystem des relationalen Ingres. Mit der Diskussion um objektorientierte Datenbanken gehen aber noch einige weitere Aspekte zu Datenbanken einher, die nicht unbedingt an den Objektbegriff gebunden sind, aber in diesem Problemfeld ihre Ursache haben. Der erste wird unter dem Begriff "lange Transaktion" diskutiert.
Echte Objektorientierung hat noch Seltenheitswert
Transaktionen dienen der Konsistenzsicherung von Daten im Übergang von einem Zustand zu einem anderen. Eine "lange Transaktion" könnte nun zum Beispiel der Entwurf eines Maschinenteils auf einem CAD-System sein, das auf existierende Komponenten aufbaut. Der veränderte Zustand wird erst mit der Freigabe durch die Konstruktionsabteilung erreicht. Zwischenzeitlich soll auf jedem Zustand der Daten innerhalb der Entwurfsperiode aufgesetzt werden können. Einzelne oder die gesamte, Änderung sollen wieder rückgängig gemacht werden können.
Auch sogenannte "geschachtelte" Transaktionen, die hierarchisch zusammengesetzte Arbeitseinheiten konsistent halten sollen, fallen in diesen Bereich. Erste Ansätze zu geschachtelten Transaktionen sind bereits in Produkten am Markt erhältlich, lange Transaktionen werden jedoch noch von keinem Produkt beherrscht.
Als zweiter Aspekt sei auf die Notwendigkeit umfassenden Konsistenzhaltung mittels Regelmechanismen verwiesen. Gerade bei relationalen Ansätzen wird diese Problematik deutlich, wenn die Semantik eines Objektes der realen Welt in einem Datenbanksystem über Dutzende von Tabellen verteilt ist. Hier zu einer Lösung zu kommen, geht weit über den Ansatz eines Data Dictionaries hinaus und zielt auf ein aktives Datenbanksystem anstelle eines aktiven Data Dictionaries. Von echten Produkten in diesem Umfeld kann noch nicht gesprochen werden, es gibt aber bereits Erweiterungen in diese Richtung bei bestehenden Systemen.
Der letzte Aspekt, der zunehmend im Zusammenhang mit objektorientierten Datenbanken diskutiert wird, ist die Frage nach der generellen Systemarchitektur eines Datenbanksystems.
Ausgehend von den vielfältigen Anforderungen, die heutige und zukünftige DV-Anwendung an eine Datenhaltung stellen, erhebt sich die Frage, ob es nicht sinnvoller sei, auf dem Kern eines Datenbanksystems spezifische Anwendungsforderungen zu implementieren, als ein generelles, vollständiges Datenbanksystem für Anwendungen zu vergewaltigen oder gar ein weiteres neues Spezialdatenbanksystem zu entwickeln.
Zur Sprache kommen diese "Baukasten" oder erweiterbaren Datenbanksysteme insbesondere in Zusammenhang mit kartographischen und Molekül-Datenbanken.
Auch hierzu gibt es bereits Forschungsprototypen, eine generelle Vermarktung ist jedoch noch nicht abzusehen.
Objektorientierte Datenbanken sind gegenwärtig noch geprägt vom Geklapper der Marketingstrategen, die sich um Abgrenzung von homogenen Vertriebsaussagen bemühen. Mit der verbalen Verwendung der Begriffe wird aber auch die zukünftige Existenz derartiger Systeme gesichert, da die Anwender sich auf diese Art mit der Problematik auseinandersetzen und ihre Anforderungen an eine objektorientierte Datenhaltung präzisieren werden.
Der Trend ist unverkennbar, daß ein postrelationales Zeitalter begonnen hat, das leistungsfähigere Rechner, leistungsfähigere Software und besonders Datenhaltungssoftware bringen wird.
Es wird in der Natur der zukünftigen Anwendungen liegen, daß die Repräsentation eines beliebigen Objektes auf einem grafischen Schirm seine Entsprechung in der gleichen Struktur auch als Datenrepräsentation in einer objektorientierten Datenbank finden wird. Bis dieses Ziel allerdings er. reicht sein wird, wird noch viel Entwicklerschweiß fließen und es werden noch viele relationalen Systeme zum Einsatz kommen.