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.

28.02.1992 - 

OOP-Datenbanken versus relationale Datenbanksysteme

Am Datenbankmarkt steht ein Generationswechsel ins Haus

28.02.1992

*Dirk Bartels ist Geschäftsführer der BKS Software GmbH in Berlin.

Objektorientierte Datenbanksysteme (OODBS) haben gegenüber konventionellen relationalen Systemen (RDBS) je nach Verarbeitungsart Vor- und Nachteile. Dirk Bartels* vergleicht die beiden Datenbantkwelten und zeigt Konzepte für mögliche Anwendungsgebiete von objektorientierten Datenbanken auf.

"Objektorientiert" ist eines der wichtigsten Schlagworte, wenn es um die Entwicklung modernerer Software geht. Allerdings ist nicht alles objektorientiert, was mit diesem Begriff belegt wird. Eine grafische Benutzeroberfläche, der Einsatz eines C+ + -Compilers oder Binary Large Objects (BLOBs) in einem relationalen Datenbanksystem sind noch lange kein Indiz für den Einsatz von Objekttechnologie.

Seit der Erfindung des Computers gehört das Speichern und Verwalten von Informationen in einem Datenbanksystem zu seinen wichtigsten Einsatzgebieten. Mit der Entwicklung der DV in den letzten 30 Jahren hat sich jedoch auch die Art dieser Systeme geändert. In den 60er Jahren repräsentierten hierarchische Datenbanksysteme (zum Beispiel IMS) und in den 70ern Netzwerkmodelle (Codasyl) den State of the Art der Technologie. Innerhalb der letzten zehn Jahre etablierten sich relationale Datenbanksysteme (RDBS) mit der Datenbanksprache SQL (Structured Query Language) als Standard. Der Vorteil der relationalen gegenüber den bisherigen Systemen wird vor allem in der logischen Unabhängigkeit der Daten vom eigentlichen Speicherungsverfahren gesehen.

Hinzu kommt eine einheitliche und vermeintlich einfache Bedienung durch die Datenbanksprache SQL und die mathematische Grundlage der Relationen-Algebra. Außerdem stehen SQL-Datenbanksysteme auf allen Plattformen, vom Host bis zum PC zur Verfügung. Sie erlauben die unternehmensweite Vernetzung von Datenbanken und ermöglichen eine breite Verfügbarkeit der Daten.

Heute hat sich die DV-Landschaft, bedingt durch die massive Leistungssteigerung von PCs und Workstations, verändert. Es gibt eine Vielzahl von komplexen Aufgaben und Anwendungen, die mit konventionellen Werkzeugen wie strukturierter Programmierung in Verbindung mit einem relationalen Datenbanksystem nicht mehr zufriedenstellend gelöst werden können.

Unsere reale Welt, die im Computer und damit auch im Datenbanksystem abgebildet werden soll, besteht aus komplexen Objekten und Beziehungen. Flache Tabellen mit atomaren Feldern ohne semantische Zusammenhänge verwalten diese Strukturen nicht optimal. Niemand käme beispielsweise auf die ldee, sein Auto (komplexes Objekt), um es in die Garage (Datenbank) zu stellen, in Einzelteile (Spalten, Records) zu zerlegen, und wenn er es herausholt, wieder zusammenzusetzen - mit einem solchen Verfahren arbeiten jedoch herkömmliche Datenbanksysteme.

Die Grenzen relationaler Datenbanksysteme liegen in ihrer zu geringen Abstraktionsfähigkeit und der daraus resultierenden ungenügenden Abbildung der realen Welt. Diese Programme sind hervorragende Werkzeuge für satz- beziehungsweise tabellenorientierte Anwendungen. Sie eignen sich zum Beispiel für die Verarbeitung von Buchungssätzen.

Weniger geeignet sind relationale Systeme jedoch für komplexe Anwendungen wie moderne Informations-, Dokumenten-, Konstruktions- oder Multimedia-Systeme. Hier wird eine höhere Abstraktionsebene für die Daten- beziehungsweise Objektmodellierung benötigt, die erst von objektorientierten Datenbanksystemen zur Verfügung gestellt wird.

Ein Vergleich zwischen objektorientierten und konventionelIen also relationalen Datenbanken macht dies deutlich, wobei hier ausschließlich das Datenmodell und die Datenbank-relevanten Funktionen betrachtet werden sollen. Ein Beispiel: Eine Person hat einen Namen, mehrere Vornamen und mehrere Adressen. Eine Adresse wiederum besteht aus einer Straße, einer Postleitzahl (Länderkennzeichen/Leitzahl), einem Ort und einer Telefonnummer (Vorwahl/Nummer). Zu einem späteren Zeitpunkt soll das System zusätzlich Kunden und Lieferanten verwalten.

Jede Erweiterung führt zu einer neuen Tabelle

Im relationalen Modell wird zunächst eine Tabelle PERSON und eine Tabelle-ADRESS aufgebaut. Die Person wird auf zwei Vornamen beschränkt. Die Relation zwischen den Tabellen wird mittels einer Personennummer als Sekundärschlüssel in der ADRESS Tabelle realisiert. Für das Einfügen einer neuen Person müssen mindestens zwei Datensätze erzeugt werden.

Die Suche nach Personeninformationen erfordert die Selektion in zwei Tabellen: Zunächst in PERSON, dann mit der Personennummer in ADRESS. Bei der Erweiterung gibt es nun verschiedene Alternativen. Die erste Möglichkeit: Die Tabelle PERSON wird um die neuen Attribute für Kunden und Lieferanten erweitert, die nicht verwendeten Felder bleiben leer. Eine Unterscheidung zwischen Person, Kunde und Lieferant müßte über ein Flag gesteuert werden. Das hat aber zur Folge, daß alle Anwendungsprogramme geändert werden müssen .

Die zweite Möglichkeit: Es werden zwei neue Tabellen KUNDE und LIEFERANT aufgebaut, die mit der Personennummer als Sekundärschlüssel mit der Tabelle PERSON verbunden werden. Um an die lnformationen eines Kunden zu gelangen, muß bereits in drei Tabellen selektiert werden. Für das Einfügen eines neuen Kunden beziehungsweise Lieferanten müssen mindestens drei Datensätze erzeugt werden.

Dieses Beispiel zeigt: Jede Erweiterung beziehungsweise jedes komplexe Element (Menge Array, Verweis) in einer Relation führt zu einer eigenständigen Tabelle, die mit einer Relation verbunden werden muß. Dynamische Datenstrukturen, wie wir sie bei Textdokumenten (Kapitel, Überschrift, Paragraph, Satz, Wort etc.) und deren Layout-Informationen (Seite, Absatz, Bereich etc.) oder Konstruktionszeichnungen (Vektor, grafisches Objekt, Hierarchie-Ebenen etc.) finden, können mit Tabellen und Spalten nicht modelliert werden.

Im objektorientierten Modell sieht die Lösung der Aufgabe folgendermaßen aus: Zuerst wird die Klasse PERSON entworfen. Diese enthält neben den einfachen Attributen eine bestimmte Menge von "Vornamen" und eine bestimmte Menge von "Adressen". Ein Objekt der Klasse PERSON kann mit einem Befehl gespeichert und damit in die Menge aller "persistenten" PERSON-Objekte eingefügt werden. Persistenz bedeutet hier, das Objekt wird mit seinen semantischen Verknüpfungen dauerhaft in der Datenbank gespeichert. In dieser "persistenten" Menge kann man die Anwendung selektieren und mit einem Zugriff das gesamte Objekt laden.

Bei der Erweiterung des Modells wird von der Basisklasse PERSON eine Klasse KUNDE und eine Klasse LIEFERANT abgeleitet. Neu eingefügte Objekte der Klasse KUNDE beziehungsweise LIEFERANT werden ebenfalls mit einem Befehl gespeichert oder geladen, die Objekte werden jedoch sowohl der Basismenge aller Personen als auch der Menge der abgeleiteten Klasse zugeordnet. Das Beispiel zeigt: Trotz steigender Komplexität der Datenstruktur erfordert dieser Ansatz keinen Mehraufwand für Design und Implementierung.

OO-Ansatz bildet die reale Welt besser ab

Der OODBS-Ansatz erscheint im Vergleich zum relationalen Ansatz wesentlich einfacher, intuitiver und "natürlicher", da er unserem normalen Denken entspricht und die reale Welt besser abbildet. Zur Verdeutlichung noch ein Blick auf diese Unterschiede aus theoretischer Sicht: Zunächst zur Gegenüberstellung von komplexen Konstruktionen und semantischen Relationen. Ein relationales Datenbanksystem läßt keine komplexe Modellierung zu. Der Grund: Eine Spalte kann keine variable Menge von Einträgen (zum Beispiel in einer Tabelle PERSON eine Menge von Vornamen, eine Menge von Adressen) aufnehmen.

Der Datenbank-Designer hat hier zwei Möglichkeiten. Einmal benutzt er ein restriktives Datenmodell, das heißt, er beschränkt sich beispielsweise auf nur zwei Vornamen, oder er baut eine weitere Tabelle (ADRESS) auf, die mit Hilfe eines Index (Personennummer) mit der Ursprungs-Tabelle (PERSON) verbunden wird.

Das objektorientierte Modell dagegen bietet komplexe Modellierungsmechanismen in Form von variablen Containern und Arrays für Typen/Objekte an. So können in dem Beispiel eine Menge von Vornamen (Basistyp STRING) und eine Menge von Adressen (Klasse ADRESS) in dem Objekt gespeichert werden, ohne daß separate Tabellen aufgebaut oder das Datenmodell beschränkt werden muß.

Beim RDBS hat der Programmierer mehr Arbeit

Beziehungen zwischen Tabellen und darin gespeicherten Daten werden im relationalen Datenmodell in der Regel über numerische Schlüssel in Verbindung mit einem Join-Operator realisiert. Der Anwendungsprogrammierer ist verantwortlich für die Verwaltung der numerischen Schlüssel und für die Einhaltung der Datenintegrität.

In unserem Beispiel bedeutet dies beispielsweise, daß beim Löschen einer "Person" die mit ihr verbundenen Adressen beziehungsweise die Merkmale "Kunde/Lieferant" ebenfalls gelöscht werden müssen. Dies wird bei modernen RDBS teilweise durch Trigger-Mechanismen unterstützt, die die Prüfung der Integritätsbedingungen ausführen können. Realisieren muß diese Aufgabe in jedem Fall der Anwendungsprogrammierer.

Im objektorientierten Modell sind häufig explizite Relationen nicht notwendig, da sie über die "natürlichen" Mechanismen von komplexen Elementen und über Vererbung realisiert werden können. Das objektorientierte Datenmodell besitzt die Eigenschaft, die semantischen Zusammenhänge zwischen Objekten und Klassen abzubilden.

Neben den angesprochenen komplexen Elementen und den Vererbungsmechanismen zählt dazu vor allem die Abbildung von direkten Referenzen auf andere Objekte, wie man sie aus der Welt der Programmiersprachen (hier als Adressen/Pointer) bereits kennt. Referenzen sind Verweise. Das bedeutet, zu einer "Person" werden beispielsweise Verweise auf ihren Partner und ihre Kinder gespeichert.

Verweise werden von einem OODBS in sogenannte Surrogate/Object Identifier umgesetzt, die ein direktes Navigieren in der Datenbank gestatten, ohne zusätzlichen Aufwand für explizite Selektionen und die Verwaltung zusätzlicher Nummernkreise und Indizes.

In einer objektorientierten Umgebung baut der Anwendungsprogrammierer komplexe Klassen, deren Objekte während des Programmlaufs gespeichert, gelesen und abgefragt werden. Bei der Verwendung eines RDBS müssen diese komplexen Objekte in ihre Einzelteile zerlegt und in flache Tabellen und Spalten gestellt werden beziehungsweise aus diesen wieder zusammengesetzt werden.

Operatoren wie INSERT, UPDATE und DELETE sind mir auf eine einzige Tabelle anwendbar und führen zu einer Vielzahl von Programmschritten. Der Grund hierfür: Das relationale Modell kann keine Semantik speichern. Das heißt, das Herstellen impliziter Zusammenhänge zwischen Objekten - wie beispielsweise die Adressen einer Person, die Zeilen einer Rechnung, der Verweis einer Person zu ihrem Partner beziehungsweise ihren Kindern oder die Absätze eines Dokumentes - müssen vollständig von der Datenbankanwendung übernommen werden.

OODBS dagegen bieten Operatoren auf einem Objekt-Level. Das bedeutet, ein Objekt kann mit einem Befehl in seiner gesamten Breite (Vererbungsbaum) und Tiefe (Verweise, Container) manipuliert (STORE, DELETE) und gelesen (GET) werden. Neben Selektionsmöglichkeiten, wie sie von relationalen Systemen und SQL bekannt sind, bieten OODBS Navigationsmöglichkeiten auf der Basis der gespeicherten semantischen Verweise.

In einem relationalen Datenbanksystem steht dem Datenbank-Designer nur eine begrenzte Anzahl von Datentypen zur Verfügung, auf die er seine zu speichernden Informationen abbilden muß. In der Regel besteht dieser Satz aus den Basisdatentypen INTEGER, FLOAT, DECIMAL, CHAR/STRING, DATE, TIME und TEXT/BLOB (entspricht sequentiellen Files) und kann nicht erweitert werden. Wiederkehrende Strukturen, zum Beispiel ein 3D-Vektor, bestehend aus einer X-,Y- und Z-Komponente oder eine Adresse müssen jedesmal neu definiert werden oder in separate Tabellen gestellt werden. Das Anwendungsprogramm muß die Informationen bei jedem Zugriff zusammensetzen beziehungsweise auf die einzelnen Felder verteilen, um den semantischen Zusammenhang wieder herzustellen.

SQL-lntegration macht oft Schwierigkeiten

Ein OODBS läßt die Erweiterbarkeit von Typen und Klassen sowohl auf Applikationsebene als auch als "Add in" innerhalb des Datenbanksystems zu. Damit können logische (auch komplexe) Strukturen, wie zum Beispiel ein 3D-Vektor, vom Datenbanksystem als solche erkannt und verarbeitet werden (strukturelle Erweiterbarkeit). Einmal implementierte Add-in-Typen können dann in jeder neuen Applikation wiederverwendet werden.

Zusätzlich läßt sich ein OODBS durch das Implementieren von neuen Funktionen auf Typ-Ebene ergänzen (verhaltensmäßige Erweiterbarkeit). Solche neuen problemspezifischen Funktionen können beispielsweise Textsuche, Kompression oder Verschlüsselung einer STRING-Klasse sein. Der Vorteil dieser Erweiterbarkeit liegt in der orthogonalen Benutzung der Standard- beziehungsweise der erweiterten Typen/Klassen ohne Beeinflussung der Applikationen, die diese benutzen. Ein weiteres großes Problem, insbesondere von SQL, stellt sich bei der Integration in eine Programmiersprache. SQL ist eine "Ad-hoc-Query-language", das heißt, über einen Datenbankmonitor kann die Datenbank abgefragt und manipuliert werden. Hierzu bedarf es keines Programms, das in einer höheren Programmiersprache wie C oder Cobol verfaßt wurde. Allerdings hat sich dieser vermeintliche Vorteil von SQL in den letzten Jahren als nicht sonderlich praktikabel erwiesen. Nahezu alle Hersteller relationaler Datenbanksysteme entwickelten sogenannte 4GL-Sprachen in Verbindung mit einem Dialog- und Reportsystem, um die leichtere Bedienung des DB-Systems zu ermöglichen.

Innerhalb der konventionellen Programmierung wird in der Regel mit sogenanntem "Embedded SQL" gearbeitet. Das ist eine nicht-prozedurale Sprache, die mit Hilfe eines Preprozessors in die Zielsprache übersetzt wird. Für den Applikationsprogrammierer bedeutet dies aber, daß er neben seiner Programmiersprache eine weitere Sprache lernen muß, die im Gegensatz zu seiner prozeduralen Sprache steht. Damit muß das aktuelle Datenbankdesign sowohl auf der Seite der Programmiersprache (zum Beispiel in C-Strukturen), als auch mit der Data Definition Language von SQL verwaltet werden.

OODB-Systeme versuchen keine weitere formale Sprache zu definieren. Vielmehr werden zusätzliche Anweisungen in eine objektorientierte Sprache wie Smalltalk oder C + + eingebaut. Damit entsteht eine "persistente" Programmiersprache, eine hybride Sprache für Programmierung und Datenbank. Diese homogene Entwicklungssprache entlastet wesentlich den Anwendungsprogrammierer.

Bei der Gegenüberstellung der beiden Datenbankmodells spielt aber nicht nur die Theorie eine Rolle. Letztendlich ist die wichtigste Frage: Welche Vorteile bringt ein OODBS in der Praxis? Beginnen wir mit der Programmierung. Hier ist mit einer deutlichen Reduzierung des Aufwandes für Datenbankaufgaben zu rechnen, da wichtige Teile der Semantik des Modells vom OODBS verwaltet werden. Die größeren Abstraktionsmöglichkeiten erlauben die Realisierung komplexerer Aufgabestellungen in wesentlich kürzerer Zeit.

Hinzu kommen bessere Wartbarkeit (durch reduzierten Code und gekapselte Daten und Methoden), bessere Erweiterbarkeit (durch Ableitung und gekapselte Daten und Methoden) und bessere Wiederverwendbarkeit (bei entsprechen dem Management vorhandene Klassen). Je nach Aufgabenstellung und Komplexität erwarten OODBS-Hersteller eine Reduzierung des Programmieraufwands um 50 bis zu 90 Prozent.

Für die Performance von OODB-Systemen gilt ähnliches. Durch die Fähigkeit, semantische Informationen abzubilden, können komplexe Objekte schneller vom OODB-System verwaltet und zusammengefügt werden. Die Interaktionen zwischen Applikation und Datenbanksystem werden massiv reduziert. Das bedeutet für den Anwender: Ein OODBS erledigt, je nach Aufgabenstellung, seine Datenbankabfrage bis zu 100 mal schneller als ein anderes Datenbanksystem.