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.

18.10.1991 - 

Technik und Anwendung der objektorientierten Datenbanken (Teil 2)

Mit der Formel OODBMS gegen Probleme der Datenspeicherung

Die Objektorientierten Datenbank-Management-Systeme (OODBMS) haben verschiedene spezifische Stärken, die sie heute schon in den "nicht-Standard-Anwendungsbereichen" den relationalen Datenbanken überlegen machen. Deshalb erwartet Christoph Mathis*, daß sich die OODBMS in nächster Zeit - zumindest in diesen Bereichen - durchsetzen werden.

Die Verwendung der objektorientierten Entwicklung über alle Erstellungsphasen hinweg bringt für die Software-Entwicklung verschiedene Vorteile mit sich. Bestimmte Probleme lassen sich mit einer solchen Analyse- und Designmethodik zumindest entschärfen: Sie basiert auf einer mächtigen und konsistenten Darstellungsmethode, die auf der einen Seite als umfassende Grundlage über den gesamten Software-Entwicklungszyklus geeignet ist und darüber hinaus Strukturen direkt aus den Anforderungen der realen Welt abbildet, weshalb sie auf der anderen Seite auch zur Kommunikation mit dem Anwender taugt.

Diese Analyse- und Designmethode ermöglicht es auch, Familien von Systemen zu erzeugen und den Wandel explizit in den Lebenszyklus der Software einzubeziehen. Außerdem ermöglicht sie es, die stabilen Aspekte von Systemen zu identifizieren sowie die Wiederverwendung von Strukturen, Design und Code zu fördern.

Die letzten beiden Aspekte sind besonders interessant für einen Datenbank-Entwurf, bei dem es um verschiedene Systeme geht, die sich ein Datenmodell "teilen", und der entsprechend langlebig sein muß. Durch eine - mit der objektorientierten Methode mögliche - evolutionäre Entwicklung sowie durch die Reduzierung von Kommunikationsverlusten und die Konsistenz in der Applikations- und Datenbank-Struktur kommt es zu stabilen langlebigen Systemen, die sich an veränderte Anforderungen anpassen lassen, ohne dabei instabil zu werden.

Wie funktionieren objektorientierte Datenbank-Management-Systeme (OODBMS)? Beispielsweise bauen sie ihre Schemata analog zu Klassendefinitionen in C++ auf. Eine Klasse in C++ wird am besten als ein vom Benutzer definierter Datentyp beschrieben. Eine Klasse hat Datenfelder wie eine gewöhnliche Record-Struktur, darüber hinaus aber auch zugeordnete Methoden. Die Klasse kann nun festlegen, daß Datenfelder für die Außenwelt unsichtbar sind und nur durch die eigenen "Methoden" (Funktionen) bearbeitet werden können. Damit entsteht ein sehr mächtiges Werkzeug zur Modularisierung von Systemen.

Zusätzlich können Redundanzen durch Vererbungs-Relationen vermieden werden. Dabei werden ähnliche Klassen zu Familien zusammengefaßt und die Gemeinsamkeiten (in gleichen Datenfeldern oder in gleichen Methoden) werden einer gemeinsamen Mutterklasse zugeordnet.

In den abgeleiteten Klassen werden diese Eigenschaften durch einen Verweis auf die gemeinsame Mutterklasse ersetzt. Gemeinsame Nachrichten müssen nur einmal hinterlegt werden. Verfeinerungen einzelner Objektarten können auf jeder Ebene der Hierarchie redefiniert werden.

Auf dieser Redefinition beruht die Eigenschaft des Polymorphismus in einer Datenstruktur. Polymorphismus bedeutet, daß - bis zu einem gewissen Grad unabhängig vom konkreten Subtyp - die "richtige" Methode automatisch ausgewählt wird.

Diese Struktur wird nun in der Datenbank nachgebildet. Eine Suche kann damit über eine Mutterklasse formuliert werden, und die "richtigen" Bearbeitungen werden für jedes gefundene Objekt gemäß seiner Klassenzugehörigkeit automatisch ausgewählt.

Durch die Speicherung eines Schemas in der Datenbank werden auch Bearbeitungen möglich, die sich auf Kenntnisse der Klassenstruktur zur Laufzeit beziehen müßte.

Ohne solche Kenntnisse muß man auf interpretierende Sprachen wie Lisp zurückgreifen und würde sich weit aus dem Bereich der normalen Programmierung entfernen. Durch eine objektorientierte Datenbank, die diese Schemata abspeichert, können die Vorteile der beiden Welten miteinander verbunden werden.

Ein Kernbegriff in der Welt der OODBMS ist ein persistentes Objekt. Das bedeutet, daß ein Objekt - oder eine Struktur - am Ende eines Programmlaufs in der Datenbank abgespeichert und bei einem späteren Lauf identisch mit allen Verweisen wiedergeholt werden kann.

Daraus ergibt sich eine einfache und transparente Verwaltung von komplizierten Strukturen; der Anwendungsprogrammierer muß keine eigenen Vorkehrungen treffen, um aus den Strukturen im Programm Datenbank-Tabellen abzubilden (und umgekehrt), sondern hat für diesen Prozeß einen automatischen Mechanismus zur Verfügung. Ein Objekt "lebt" im Adreßraum des Prozesses wie auch in der Datenbank. Mit dieser strukturellen Gleichheit entfällt ein großer Teil des Aufwands im Programm ersatzlos.

Eine technische Voraussetzung hierfür ist, daß jedes einzelne Objekt eine eindeutige Identität besitzt. Dies ist ein grundlegender Unterschied zu relationalen Datenbanken, in denen verschiedene Einträge mit ansonsten identischen Daten nicht unterschieden werden können. Besonders kommt das bei Relationen zum Tragen, die nur über indirekte (und ineffektive) Mechanismen wie die künstliche Einführung von Indizes nachzubilden sind.

Mit der Identität von Objekten können Referenzen direkt verwaltet werden. Ein Verweis auf ein Objekt bedeutet die Angabe des (eindeutigen) Bezeichners. Im Unterschied dazu wird ein Verweis in einer relationalen Datenbank immer über einen Schlüssel, also über Datenfelder, realisiert. Dies bedeutet jeweils eine Suchoperation, die in der Regel über einen Index läuft. Gerade bei sehr komplexen Datenstrukturen, wie sie bei CAD, Netzwerkmanagement und ähnlichen Problemstellungen zu finden sind, führt dies sehr schnell zu hohem Verwaltungsaufwand.

Die Navigation in der Datenbank wird hier zum Teil wieder in das Programm gezogen. Allerdings ist dieser Aspekt in die Klassendefinition eingekapselt und nicht - wie in der klassischen hierarchischen oder Netzwerk-Datenbank - im gesamten Programm verstreut. Die Klassendefinition wiederum wird von allen Applikationen die auf die Datenbank zugreifen, verwendet. Durch die Anwendung der objektorientierten Methode werden Vorteile der

verschiedenen Datenbank-Techniken miteinander kombiniert, wodurch der Anwendungsbereich der Datenbank-Technologie insgesamt ausgeweitet wird.

Mit der direkten Angabe von Objekt-Identitäten kann man bei der Bearbeitung von Relationen noch einen Schritt weiter gehen: Referenzen können virtuell sein, das heißt, ein referiertes Objekt wird erst dann aus der Datenbank angefordert, wenn der erste Zugriff erfolgt. Die Objekt-Datenbank fungiert dann wie eine problemorientierte virtuelle Speicherverwaltung.

Ein objektorientiertes Daten-bank-System verfügt über diese Techniken als Standard-Zugriffsmethode und macht zusätzlich einen expliziten Zugriff auf Objekte über verschiedene Optimierungsmöglichkeiten möglich. Diese Optimierung ist weitgehend orthogonal zum Applikationskern, so daß zunächst die Anwendungsentwicklung ohne Berücksichtigung von Optimalitätskriterien geschehen kann. Ein maßgeschneidertes

Laufzeitverhalten läßt sich dann nachträglich hinzufügen.

Kernmodell und Erweiterungen

In den verschiedenen objekt orientierten Programmiersprachen und Systemen gibt es eine bestimmte Menge von Konzepten, die übereinstimmend als Kern des Modells bezeichnet werden. Dieses Kernmodell um faßt:

- Objekt-ldentifier,

- Klassen,

- Attribute und Methoden,

- Verkapselung und Message Passing,

- Polymorphismus und

Inheritance-Hierarchie.

Für ein Datenbank-System muß dieses Kernmodell um Eigenschaften erweitert werden die die semantische Integrität des Datenbestands sicherstellen und die interessanten Beziehungen und Relationen abbilden helfen.

Jedes Datenbank-System muß ein Data-Dicitionary haben. Dieses Data-Dictionary ist aber für eine objektorientierte Datenbank umfassender als in relationalen Datenbanken: Es enthält auch eine Beschreibung der Methoden, also der Funktionen. Die Datenbank und eine globale Bibliothek können damit - abhängig vom Typ eines Objekts - Funktionen "abstrakt" aufrufen (siehe Polymorphismus) wodurch die Erstellung von sehr leicht pflegbaren Applikationen erreicht wird.

Bei der Einbindung einer objektorientierten Datenbank in eine Anwendung gibt es zwei Wege: zum einen die völlige Neuerstellung, zum anderen die Portierung einer existierenden Applikation. Bei einer Neuentwicklung stehen dem Programmierer Hilfsmittel in der Datenbank zur Verfügung, mit denen sich die Klassenstruktur grafisch visualisieren läßt. Gegebenenfalls kann die Erzeugung von Masken für eine Benutzerschnittstelle ebenfalls grafisch unterstüzt werden.

Die konzeptionelle Modellierung der Datenbank-Struktur spiegelt gleichzeitig die Struktur der Anwendung wider. Entsprechend können aus der Datenbank-Struktur direkt die Klassendefinitionen generiert werden. Diese wiederum bilden den Rahmen, innerhalb dessen dann die Funktionalität - zum Beispiel in C++ - ausprogrammiert wird.

Bei einer existierenden Applikation werden die persistenten Klassen, also der Teil der Anwendungsdaten, der als Teil der Datenbank gespeichert werden soll, identifiziert. Aus der C++ -Klassendefinition werden - falls die Datenbank entsprechende Vorkehrungen zur Verfügung stellt - automatisch Schemata abgeleitet. Danach können diese Schemata interaktiv bearbeitet werden.

Dann lassen sich Transaktionen und Speicherpunkte definieren, ebenso Such- und Leseoperationen, zum Beispiel in SQL. Dabei ist zu beachten, daß nur die Einstiegsobjekte explizit gelesen werden müssen; die weiteren Objekte finden objektorientierte Datenbank-Systeme durch die transparenten Referenzen meist "von selbst".

Der Kern der Applikation bleibt unverändert; nur die Organisation der Datenspeicherung ist weggefallen. Die Softwarestruktur ist dadurch einfacher und geschlossener geworden, und mit Hilfe der direkten Abbildung gleicher Strukturen ist je nach Komplexität der Datenstrukturen zusätzlich ein dramatischer Performancegewinn erzielt worden. +