Die nicht konstante Performance ist ein allgemeines Problem bei Datenbanken, auch als "Saegezahn-Leistung" bezeichnet: Sie ist nach der ersten Installation oder nach der Reorganisation einer Datenbank zunaechst sehr gut, laesst, wenn der Datenbestand fragmentiert wird, aber langsam nach. Alle Systeme, die Fragmentierung zulassen, weisen keine gleichbleibende Leistung auf, weil sie zwei wichtige Funktionen nicht erfuellen: das Online- Bereitstellen von geloeschtem Speicherplatz - was auch verhindert, dass Datenbanken allmaehlich an Umfang zunehmen - und die Online- Reorganisation von Daten.
Bei komplexen Daten deutlich schneller
Der Industriestandard-Bench-mark-Test fuer OODBMS von Objektspezialist Rick Catell, zeigt sehr deutlich auf, dass objektorientierte Datenbanken beim Management komplexer Daten viel schneller arbeiten als relationale (RDBMS). Aussagekraeftiger sind allerdings Tests mit einer realistischen Zielanwendung, gefolgt von Benchmarks, die der gewuenschten Applikation zumindest aehnlich sind.
Bei der Durchfuehrung von Benchmarks ist auf eine Reihe von Punkten zu achten. Das gilt zum Beispiel fuer das Datenbankdesign (um Spitzenbelastungen aufzudecken), fuer den Transak-tionsmix (Profile, Lese- versus Schreibzugriffe), die Anzahl der gleichzeitig zugreifenden Benutzer (um Engpaesse aufzuspueren) und die Netzwerktopologie (Stand-alone- oder Client-Server- Architektur). Auch der Umfang der Datenbank und die Testdauer spielen fuer die Aussagekraft des Benchmarks eine wichtige Rolle.
Ein weiterer wichtiger Aspekt zur Beurteilung von Informationssystemen ist deren Erweiterbarkeit. Allerdings hat dieser Begriff mehrere Bedeutungen.
So meint Erweiterbarkeit beispielsweise die Portabilitaet von einer Plattform auf eine andere oder aber auch die Moeglichkeit, Daten ueber ein Netz zu verteilen, um eine gleichmaessige Verteilung der Last zu erreichen, die Leistung zu optimieren und die Lokalisierung der Adressierung sicherzustellen. Erweiterbarkeit wird ferner als Investitionssicherung fuer die Zukunft interpretiert, ohne dass Brueche fuer grundlegende Funktionen wie die Schemaveraenderung entstehen. Und schliesslich sind mit Erweiterbarkeit auch Skalierbarkeit und Unterstuetzung neuer Paradigmen wie Workgroup und Mobile Computing gemeint.
Mit der Entwicklung zum Client-Server-Computing ist der Bedarf an transparenter Datenverteilung stetig gestiegen. Da die ersten OODBMS waehrend der C/S-Aera entstanden, unterstuetzen sie zumindest teilweise verteilte Datenbanken.
Die Hauptanforderungen an eine verteilte Datenbank hat Chris Date, einer der Erfinder von relationalen Datenbanken, in seiner "Null- Regel" formuliert: "Eine verteilte Datenbank sollte fuer den Benutzer wie eine lokale Datenbank erscheinen." Das heisst, dass die Verteilung der Daten fuer den User vollstaendig transparent sein sollte.
In Verbindung mit OODBMS bedeutet Transparenz, dass die Art, wie eine Anwendung ein Objekt adressiert, vom physikalischen Ort des Objekts unabhaengig ist. Ein Objekt auf einem bestimmten Server kann entfernte Objekte auf genau dieselbe Art adressieren wie ein lokales Objekt. Darueber hinaus sind die "Objekt Identifier" (OIDs) vom Ort des Objekts unabhaengig. Sie muessen also nicht veraendert werden, wenn ein Objekt von einem Server zu einem anderen bewegt wird.
Transparenz bezieht sich aber nicht nur auf Datenobjekte, sondern auch auf Transaktionen. Ein OODBMS muss gewaehrleisten, dass Transaktionen bis in die kleinste Einheit (das heisst ganz oder ueberhaupt nicht) durchgefuehrt werden, unabhaengig davon, ob sie Veraenderungen von Instanzen vornehmen, die auf einem oder auf mehreren Servern liegen. Selbst wenn sich die Operationen des "Commit" fuer lokale und verteilte Datenbanken unterscheiden (Single- versus Two-phase-commit), sollten sie auf jeden Fall so stattfinden, dass der Benutzer nichts davon bemerkt. Ausserdem sollte das OODBMS die Opera-tionsart automatisch auswaehlen. Bei manchen RDBMS muss der Programmierer bei verteilten Transaktionen das Two-phase-commit manuell vornehmen, auch programmtechnisches Two-phase-commit genannt.
Transparenz hat viele Vorteile. So ist beispielsweise der Aufwand fuer Pflege und Wartung geringer, wenn der Sourcecode beim Verschieben von Objekten keine Veraenderung erfahren muss. Gleichzeitig laesst sich die Performance durch das Verlagern von Objekten steigern. Zudem ist die Datenintegritaet gewaehrleistet, wenn die OIDs in transparenten OODBMS logisch und nicht vom physikalischen Ort abhaengig sind.
Zu den wesentlichsten Leistungsmerkmalen bei der Unterstuetzung von Workgroups gehoeren der Check-out und Check-in von Objekten in gemeinsam genutzten und persoenlichen Datenbestaenden. Eine wichtige Rolle spielen dabei lange Transaktionen, die Check-out/Check-in- Operationen zur Integritaetssicherung mit der gleichen Semantik wie kurze Transaktionen behandeln, und persistente Sperrmechanismen, die die Konsistenz langer Transaktionen garantieren.
Darueber hinaus ist die Versionskontrolle in Workgroup-Anwendungen wichtig. Sie stellt sicher, dass mehrere Personen an unterschiedlichen Versionen eines Objekts arbeiten koennen. Dabei muss erkennbar sein, wie sich Veraenderungen an ihrem persoenlichen Arbeitsplatz auf die gemeinsam genutzten Datenbestaende auswirken. Zudem muss es moeglich sein, neue oeffentlich zugaengliche Versionen zu schaffen, ohne mit anderen Benutzern in Konflikt zu geraten.
Waehrend RDBMS Arbeitsgruppen nicht unterstuetzen, stellen OODBMS zumindest teilweise einen Support der Grundfunktionen zur Verfuegung. Einige OODBMS bieten hierfuer lange Transaktionen ohne lange Sperrmechanismen an. Dies kann jedoch zu Stoerungen fuehren. Um Transaktionen, die eventuell ueber Tage und Wochen gehen, vollstaendig zu unterstuetzen, muss ein OODBMS auch langanhaltende Sperrmechanismen bereitstellen, so dass auch im Fall eines Netzwerk- oder Systemausfalls die Datenintegritaet garantiert ist.
Zum Check-out und Check-in bieten OODBMS verschiedene Moeglichkeiten an. Einige Produkte laden Objekte in den Speicher. Dabei benoetigen sie allerdings eine aktive Verbindung zum gemeinsam genutzten Server. Andere Systeme unterstuetzen die Abtrennung der persoenlichen Datenbanken. Bei diesem Modell kann die Verbindung zum Netz, wenn die Objekte einmal ausgecheckt sind, voellig abgebrochen werden. Dies ist insbesondere fuer den mobilen Computereinsatz von Vorteil.
Neben den behandelten Aspekten der Erweiterbarkeit sollte auch der Zeitdimension Aufmerksamkeit gelten. Im Laufe eines Projekts tauchen unvermeidlich Schemaaenderungen auf. Dafuer bieten praktisch alle RDBMS den Befehl "Alter Table" an. Er gestattet das Hinzufuegen neuer Spalten in Tabellen oder das Veraendern vorhandener Spaltentypen. Bei Objektdatenbanken entspricht der Begriff des Alter Table der Schemaanpassung.
Drei Methoden der Schemaanpassung
In OODBMS unterscheidet man grundsaetzlich drei Anpassungsarten: Die erste ist die manuelle Schemaanpassung. Dazu muss der Benutzer die Datenbank entladen, die Klassen loeschen, wieder neu generieren und anschliessend die Daten neu laden. Die zweite Art der Schemaanpassung ist die der "pseudo online scheme evolution". Hier genuegt dem User ein einziger OODBMS-Befehl, der dafuer sorgt, dass die Anpassungen im Hintergrund ausgefuehrt werden. Die dritte Moeglichkeit heisst "Lazy update". Bei dieser Methode werden zwei Versionen eines Objekts automatisch gepflegt, und bei Bedarf wird jede Instanz vom alten auf das neue Schema uebertragen. Der Vorteil hierbei ist, dass fuer ein Update kein Herunterladen der Datenbank notwendig ist.
Unter dem Aspekt der Produktivitaet ist es nicht nur wichtig, ob der Uebergang von einer relationalen auf eine objektorientierte Datenbank mit dem vorhandenen Code stattfinden kann, sondern auch, welcher Aufwand fuer das Schreiben des neuen Codes zu betreiben ist. Die meisten OODBMS bieten Sprach-Interfaces an, die denen von RDBMS aus zweierlei Gruenden ueberlegen sind: Zum einen wird bei objektorientierten Datenbanken eine einzige Sprache fuer die Anwendungsentwicklung und den Zugriff auf die Datenbank verwendet. Im Gegensatz dazu brauchen RDBMS zwei Sprachen - eine fuer die Programmierung der Datenbank (SQL) und eine weitere fuer die Anwendungsentwicklung (verschiedene Host-3GLs).
Zum anderen muessen Benutzer von OODBMS nicht zwischen Offenheit und Integration waehlen. In relationalen Systemen waren die Programmierer gezwungen, proprietaere 4GLs einzusetzen. Damit waren sie fuer lange Zeit an einen Hersteller gebunden. Dies trifft auf OODBMS nicht zu. Hier koennen die Anwender beides haben: Produktivitaet und Offenheit.
Bindung an eine einzige Sprache vermeiden
Unterschiede zwischen den Anbietern von OODBMS gibt es bei den Programmiersprachen. Einige Hersteller haben sich eng an eine einzige Sprache gebunden (C++ oder Smalltalk). Diese Einschraenkungen sind fuer den heutigen Markt zu restriktiv. Es sollten deshalb transparente Interfaces zu vielen Programmiersprachen zur Verfuegung stehen.
Die Entscheidung, welche Tools der Anwender von Drittanbietern und welche vom Datenbankan-bieter beziehen sollte, kann sich gerade im OODBMS-Umfeld schwierig gestalten. In diesem noch wachsenden Markt verfuegen bislang nur wenige Hersteller ueber ein umfassendes Angebot. Die anderen sind auf Third-Party-Produkte angewiesen. Unabhaengig davon, woher Software-Tools stammen, gilt es fuer den Kaeufer die Frage zu klaeren, wie und wie gut sich Fremdprodukte in die favorisierte OODBMS integrieren lassen.
Weitere Probleme ergeben sich durch fehlende Reportgeneratoren und in puncto Verwendung von konventionellen Interfaces wie SQL und/oder objektorientierten Entsprechungen. Auch ist darauf zu achten, dass die Programmierer vorhandene SQL-Kenntnisse weiter nutzen koennen. Zusaetzlich ist zu klaeren, ob Fremdprodukte zur Verkaufsstrategie des OODBMS-Anbieters gehoeren, damit er den gesamten Lebenszyklus einer Entwicklung abdecken kann.
Nicht zuletzt sollte der potentielle Kaeufer die einzelnen Hersteller genauer unter die Lupe nehmen. Es ist wichtig, die Marktbedeutung des Anbieters zu kennen und abzuschaetzen, ob es ihn auch in einigen Jahren noch geben wird. Das in Frage kommende Unternehmen sollte zudem eine klare Vision und eine realistische Vorstellung davon haben, wie sich diese Vision in die Realitaet umsetzen laesst. Last, but not least ist auch der finanzielle Background des Anbieters zu untersuchen.
*Dr. Horst Brunner ist Leiter Professional Services der Versant Object Technolgie GmbH Europe, Muenchen.
Kurz & buendig
Fuer die Beurteilung der Leistungsfaehigkeit einer objektorientierten Datenbank gibt es verschiedene Verfahren und Benchmarks. Isoliert betrachtet, lassen sie aber nur Urteile ueber einen kleinen Teilbereich der Datenbank oder ueber eine bestimmte Konfiguration zu. Ohnehin ist zweifelhaft, ob Tests unter Laborbedingungen etwas ueber die Leistung der Datenbank nach einigen Operationen unter tatsaechlichen Anwendungsbedingungen aussagen. Wichtiger ist fuer den Anwender der Aspekt der Investitionssicherheit oder, anders ausgedrueckt, welche Erweiterungsmoeglichkeiten sich ihm in Zukunft bieten. Den ersten Teil dieses Beitrags finden Sie in der COMPUTERWOCHE Nummer 3 vom 19. Januar 1996 auf Seite 39.