Die Anforderungen an objektorientierte Datenbank-Management- Systeme (OODBMS) sind vielschichtig. So muessen sie beispielsweise die Verwaltung komplexer Daten einschliesslich grafischer Informationen, das Abspeichern von Objekten, die mit objektorientierten Programmiersprachen generiert wurden, und die Funktionen traditioneller Datenbanksysteme unterstuetzen.
Zur Informationsspeicherung waehlten Anwendungsentwickler in der Vergangenheit entwe-der Flat-Files oder relationale Datenbank- Management-Systeme (RDBMS). Flat-Files erlauben das Speichern beliebig komplexer Daten, es fehlen ihnen aber die Grundfunktionalitaeten traditioneller Datenbanksysteme wie geregelter Datenzugriff, Datenverteilung und Datenintegritaet.
Relationale Datenbanken erfuellen diese Kriterien zwar, sind aber aufgrund ihres tabellenorientierten Datenmodells nicht in der Lage, komplexe Datenmodelle und Beziehungen adaequat abzubilden. Ferner ist es mit relationalen Systemen nicht moeglich, Objekte in ihrer nativen Form abzuspeichern.
Objektorientierte Datenbanksysteme bieten Vorteile beider Welten und verfuegen ueber die Flexibilitaet, alle nur denkbaren komplexen Datenobjekte zu speichern. Deshalb ist fuer viele Unternehmen die prinzipielle Entscheidung fuer eine objektorientierte Datenbank relativ einfach. Schwieriger ist die Auswahl eines bestimmten OODBMS. Zieht man in Betracht, wie viele verschiedene Produkte inzwischen erhaeltlich sind, so kann es sehr zeitaufwendig und kompliziert werden, den Markt zu sondieren.
Vier Kategorien von OODBMS
Alle objektorientierten Datenbanken - einschliesslich artverwandter Produkte - lassen sich in vier Hauptkategorien einteilen: echte OODBMS, Produkte mit persistenter Datenhaltung, Object-Wrappers und erweiterte relationale Datenbanksysteme.
1. Echte OODBMS basieren auf einem Objektmodell und bieten traditionelle Datenbankfunktionalitaet, das heisst, sie unterstuetzen Persistenz, Verteilung, Integritaet, Recovery und den gleichzeitigen Datenzugriff. Typischerweise stellen sie permanente, eindeutige Identifikationsmechanismen fuer die einzelnen Objekte zur Verfuegung, die die Integritaet der Daten garantieren. Echte OODBMS unterstuetzen darueber hinaus Funktionen zur transparenten Verteilung der Datenbank sowie fuer Workgroup- und Mobile-Computing. Aehnlich wie relationale Datenbanken werden OODMBS meist mit integrierten Anwendungsentwicklungs-Umgebungen und Datenbank-Management-Tools angeboten.
2. Persistant Storage Managers (PSMs) sind aus dem Markt der Stand-alone-CAD-Systeme entstanden und wurden fuer die Speicherung und Verwaltung von sehr kleinen Objekten (weniger als 20 Byte) konzipiert. Genau aus diesem Grund fehlen den PSMs permanente Objektidentifika-tions-Mechanismen, so dass sie ein niedrigeres Datenintegritaetsniveau bieten als echte OODBMS. Weitere Nachteile dieser Kategorie sind die umstaendliche Datenverteilung, grobgranulare Sperrmechanismen, eine aeusserst duerftige Online- Speicherverwaltung und fehlende Schema-Anpassungen.
3. Object-Wrappers sind Softwaremodule, die auf ein RDBMS aufgesetzt werden und ein objektorientiertes Interface des darunterliegenden relationalen Datenbank-Managers bereitstellen. Derartige Systeme bieten einerseits die Vorteile der Objekttechnologie wie verbesserte Programmierproduktivitaet, da sie die Wiederverwendung von Code unterstuetzen. Auf der anderen Seite aber bedeutet die Tatsache, dass ein Object-Wrapper auf einer relationalen Datenbank aufbaut, ernsthafte Performance-Probleme vor allem bei der Verwaltung komplexer Daten. Weil diese Maengel bereits erkannt wurden, spielen Object-Wrapper im Markt keine grosse Rolle.
4. Viele Hersteller von RDBMS versuchen der wachsenden Begeisterung fuer Objekttechnologie dadurch zu begegnen, dass sie entweder die Strategie der Object-Wrapper einschlagen oder Objekttechnologie-aehnliche Funktionen in ihre RDBMS integrieren. Relationale Datenbanken bieten eine flexible und leistungsfaehige Umgebung fuer das Management konventioneller Zeichenketten und numerischer Daten. Die ueblichen Erweiterungen wie Trigger oder Stored Procedures verbessern aber keineswegs ihre Faehigkeit, mit multimedialen oder anderen komplexen Datentypen umzugehen.
Keines der erweiterten relationalen Modelle kann mit den Vorteilen aufwarten, die der objektorientierte Ansatz mit sich bringt. Ein Beispiel: Stored Procedures bieten zwar eine eingeschraenkte Form der Kapselung (Encapsulation), sie unterstuetzen aber Vererbung und Polymorphismus genausowenig wie sie die Wiederverwendbarkeit und Produktivitaet in der Form bereitstellen, wie es die Objekttechnologie kann. Deshalb ist es am sinnvollsten, wenn man erweiterte RDBMS als bessere relationale Datenbanksysteme ansieht.
Nach der Kategorisierung der Produkttypen wird die Zahl der in Frage kommenden OODBMS bereits wesentlich kleiner. Es ist aber unumgaenglich, diese einer tiefergehenden Analyse hinsichtlich ihrer Leistungsfaehigkeit und Erweiterbarkeit zu unterziehen.
Um die Leistungsfaehigkeit eines bestimmten OODBMS fuer eine ausgewaehlte Zielanwendung festzustellen, sind drei Arten von Tests ratsam. Zum einen sind die Leistungsmerkmale des Produkts zu analysieren. Danach bietet sich ein Benchmark-Vergleich an, und zu guter Letzt kann nur ein kundenspezifischer Benchmark eine praezise Auskunft sicherstellen.
In einem ersten Schritt ist die Frage nach der Unterstuetzung ganz bestimmter Features der betrachteten Produkte zu beantworten. Dies garantiert jedoch nicht immer, dass die Systeme die tatsaechlichen Leistungsanforderungen auch erfuellen. Immerhin kann eine derartige Analyse aber dazu beitragen, die moeglichen Funktionsmaengel und Flaschenhaelse eines Produkts zu erkennen.
Besondere Beachtung sollten die Ebenen des Parallelzugriffs und die implementierten Sperrmechanismen (Locking) finden, da sie fuer die Leistungsfaehigkeit des Systems stehen. In jedem Datenbanksystem wird versucht, dass moeglichst viele Nutzer gleichzeitig darauf zugreifen koennen und es zu moeglichst wenig Kollisionen und Wartezeiten kommt.
RDBMS wie Oracle oder DB2 arbeiten mit einem satzweisen Sperrmechanismus. Bei OODBMS entspricht dies der Objektstufe. Benchmark-Tests bestaetigen, dass satzweises Locking schneller als seitenweises ist. OODBMS, die mit seitenweisem Locking arbeiten, verursachen fuer den Anwender unnoetige Wartezeiten.
Diese entstehen dann, wenn zwei Benutzer mit verschiedenen Datensaetzen arbeiten, die zufaellig auf derselben Seite abgelegt sind und daher miteinander kollidieren. Derartige Situationen koennen sogar zum totalen Systemstillstand fuehren, weil Transaktionen unnoetigerweise rueckgaengig gemacht und anschliessend wieder neu aufgesetzt werden.
Einige Hersteller kaschieren Page-Locking und deklarieren es als Objektsperrung, indem sie Objekte auf leere Seiten umsiedeln. Andere vergroessern Objekte kuenstlich, so dass nur eines auf eine Seite passt. Beide Methoden gehen mit den Ressourcen offensichtlich sehr verschwenderisch um.
Der Sperrmechanismus auf Objektebene ist nur eine Moeglichkeit, den gleichzeitigen Zugriff zu verbessern. Einige Produkte arbeiten mit benutzerdefinierten Sperren oder sogenannten "nested" Transaktionen, die gleichzeitige, Multi-Windows-basierte Anwendungen unterstuetzen. In diesem Fall schneidet der Programmierer den Sperrmechanismus individuell auf die Anforderungen einer Anwendung zu.
Drei Arten der Implementierung
Wenngleich alle OODBMS nach einem Client-Server-Design entworfen wurden, lassen sich drei Arten der Implementierung unterscheiden. In RDBMS ist ein Server-zentriertes Modell realisiert, bei dem die Clients keine Datenbankfunktion ausueben, sondern lediglich SQL- Statements an den Server schicken, der die komplette Datenbankverarbeitung uebernimmt. Diese Implementierung hat zwei entscheidende Nachteile. Zum einen ist ein hoher Netzwerk-I/O zu verzeichnen, und zum anderen bleibt die Leistungsfaehigkeit der heutigen Client-Rechner ungenutzt.
OODBMS verlegen im allgemeinen mehr Verarbeitungsleistung in den Client. Einige Systeme haben sogar ein Client-zentriertes Modell implementiert. Dabei wird der Server nur auf einen "dummen Seiten- Server" reduziert, der zu keiner Verarbeitungsleistung in der Lage ist.
Ein wichtiger Nachteil ist hier, dass sehr viel Netzverkehr stattfindet. In Stand-alone-Systemen ist diese Methode durchaus sinnvoll, weil Client und Server in derselben Maschine untergebracht sind.
Die Aufgaben sind gleichmaessig verteilt
Der dritte Ansatz ist der der ausgeglichenen Client-Server- Implementierung. Hier sind die Aufgaben gleichmaessig zwischen Client und Server aufgeteilt. Dabei uebernimmt der Client das Transaktions- und das Session-Management, waehrend der Server fuer das Locking und die Sperrmechanismen zustaendig ist.
Dieses Verfahren verringert den Netzverkehr deutlich, indem "dual caching" auf dem Client und dem Server zum Einsatz kommt. Das wiederholte Lesen von Daten aus dem Cache-Speicher ("warm object traversal") geht sogar ohne Netzbeteiligung vor sich. Darueber hinaus stellt die Faehigkeit, Server-basierte Anfragenbearbeitung auszufuehren, sicher, dass nur die angeforderten Daten vom Server auf den Client uebertragen werden.
*Dr. Horst Brunner ist Leiter Professional Services der Versant Object Technologie GmbH Europe, Muenchen.
Kurz & buendig
Objektdatenbank ist - trotz immer mehr Standards - nicht gleich Objektdatenbank. Die Produkte weisen zum Teil erhebliche Unterschiede in wichtigen Bereichen der Speichertechnik auf. Waehrend derlei im Einzelplatzbetrieb nicht ins Gewicht faellt, sind sie in Client-Server-Umgebungen von entscheidender Bedeutung fuer die Flexibilitaet und Geschwindigkeit der Datenbank. Der Autor zeigt im Detail auf, worauf Anwender achten sollten.