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.

11.10.1991

Das sogenannte Manifest über objektorientierte Datenbanken

Da die Grundlage für die Entwicklung von OODBMS-Produkten nicht auf einem gemeinsamen, allgemein akzeptierten Datenmodell fußt, wie es beim relationalen Modell der Fall ist, kann noch keine verbindliche, allgemein akzeptierte Aussage über alle Kerneigenschaften eines: solchen Datenbanksystems gemacht werden. Die zur Zeit bemerkenswerteste Klassifikation nahm daß Autorenteam Atkinson, Bancilhon, DeWit, Dittrich, Maier und Zdonik in Ihrem "Manifest über objektorientierte Datenbanken" vor. Demnach gilt ein DBMS dann als objektorientiert, wenn es die unten aufgelisteten 13 Eigenschaften aufweist. (Bei den Eigenschaften 9 bis 12 handelt es sich um Grundeigenschaften, die ohnehin von jedem Datenbanksystem gefordert werden sollten.)

1. Angemessene Repräsentation komplexer Objekte: Unter komplexen Objekten sind hier Objekte zu verstehen, die aus einfacheren Objekten aufgebaut sind. Minimale Konstrukte hierfür sind Listen, Mengen und Tupel; insbesondere für technische Anwendungen sollte das OODBMS auch Arrays unterstützen. Die Konstrukte müssen orthogonal zueinander sein, also unabhängig voneinander eingeführt werden können, ohne sich dabei gegenseitig zu stören beziehungsweise zu beeinflussen.

2. Identität: Jedes Objekt muß eindeutig identifizierbar sein; Objekte mit gleicher Belegung der Variablen müssen unterscheidbar sein. Im Gegensatz dazu ist bei relationalen Systemen die Objektidentität nicht zu bestimmen, da wegen der mengenorientierten Grundlage der Tabellenstruktur zwei identische Tupel in einer Relation nicht unterschieden werden können. Aus der Objektidentität folgt, daß das OODBMS auch Operationen für das Zuweisungen und für das Objektduplizieren zur Verfügung stellt.

3. Datenkapselung: Das OODBMS soll aus Gründen der Modularität und der Erweiterbarkeit eine Datenkapselung im Sinne der objektorientierten Programmierung zur Verfügung stellen. Zusätzlich soll das OODBMS eine Datenkapselung im Sinne der Datenabstraktion bei Datenbanksystemen gewährleisten, indem es Implementierungsdetails vor dem Benutzer verbirgt.

4. Klassen- oder Typenkonzept: Ein OODBMS sollte die Konzepte von Klassen beziehungsweise Typen unterstützen. Unterschieden wird hier zwischen Typen in Programmier sprachen (beispielsweise in C + + ) und in Klassen (beispielsweise in den Smalltalkorientierten Sprachen). Die Autoren des Manifests unterteilen die Implementierungen von Typen in einen Datenteil und einem Operatorenteil; beide können schon zum Übersetzungszeitpunkt auf ihre Korrektheit geprüft werden. Im Gegensatz hierzu können die Klassenkonzepte vom Smalltalk- und Lisp-basierten Systemen zur Laufzeit wesentlich mehr Dynamik zeigen, da durch die Interpretierung dieser Sprachen zur Laufzeit leicht Manipulationen der Klassen und ihrer Instanzen möglich sind. Manche C++-orientierten OODBMS verfügen über dynamische, zur Laufzeit verfügbare Metainformationen über die gespeicherten Klassen und unterstützen dadurch ähnliche dynamische Eigenschaften - ohne die in Smalltalk oder Lisp vorhandenen Nachteile bezüglich Stabilität und Geschwindigkeit.

5. Klassenhierarchie: Die Möglichkeit der Vererbung von Eigenschaften zwischen Objektklassen dient der Steigerung der Flexibilität bei Systementwurf und Modifikationen und wird hier im gleichen Sinn wie in der objektorientierten Programmierung verstanden.

6. Spätes Binden, Überladen: Diese Eigenschaft eines OODBMS stammt aus der objektorientierten Programmierung und ermöglicht die Verwendung des gleichen Methoden- oder Funktionsnamens für äquivalente Algorithmen bei unterschiedlichen Objektklassen .

7. Semantische Vollständigkeit: Die Anfragesprache des OODBMS muß die Mächtigkeit einer Programmiersprache besitzen. Das OODBMS soll also in der Lage sein, die Implementierung von Anwendungsprogrammen zu unterstützen.

8. Typen-Erweiterbarkeit: Das OODBMS darf keine Unterschiede zwischen systemdefinierten und benutzerdefinierten Typen machen. Dies bedeutet, daß ein Mechanismus zur Erzeugung neuer Typen zur Verfügung gestellt werden muß.

9. Persistenz: Dem Benutzer muß die Persistenz der Objekte ohne zusätzliche Operationen (wie zum Beispiel Kopieren des Objekts) garantiert werden.

10. Große Datenbestände: Das OODBMS soll in der Lage sein, sehr große Datenmengen zu verwalten.

11. Mehrbenutzerfähigkeit: Das OODBMS soll einen Mehrbenutzerbetrieb erlauben, wie er von konventionellen Datenbanksystemen bekannt ist.

12. Wiederaufsetzen nach Fehlern: Auch das Aufsetzen nach Systemfehlern und Abstürzen gehört: zu den allgemeinen Anforderungen an ein Datenbanksystem .

13. Ad-hoc-Anfragemöglichkeiten: Das OODBMS sollte einfache Anfragemöglichkeiten zur Verfügung stellen - zum Beispiel in Form einer Sprache oder einer grafischen und interaktiven Benutzerschnittstelle. Die Anfragesprache sollte nicht triviale Anfragen erlauben sowie effizient und anwendungsunabhängig sein.

Als optionale Eigenschaften, welche sich größtenteils auf spezifische Probleme technischer Anwendungen und auf allgemeine Eigenschaften on Datenbanksystemen beziehen, werden außerdem die folgenden Eigenschaften angesehen:

- Multiple Vererbung: Bezüglich der multiplen Vererbung werden zur Zeit kontroverse Diskussionen geführt. Hier müssen die Vorteile beim Entwurf eines Systems mit multipler Vererbung sorgfältig gegen die Gefahren nicht mehr nachvollziehbarer Tiefen, daraus resultierender Inkonsistenzen und eines Verlusts an Modularität abgewogen werden.

- Typenprüfung: Das OODBMS sollte schon zum Übersetzungszeitpunkt möglichst alle Typenkonflikte überprüfen. Im Idealfall dürfen zur Laufzeit keine Typenfehler mehr auftreten.

- Transaktionen für Designprozesse: In vielen neuen Anwendungen ist das klassische, aus den kommerziellen Anwendungen erwachsene Transaktionsmodell nicht ausreichend. Transaktionen können sehr lang werden und auch mehrfach geschachtelt sein (design transactions); ein OODBMS sollte solche langen und geschachtelten Transaktionen unterstützen.

- Versionsverwaltung: Während des Software-Entwicklungsprozesses ist es oft praktisch und bequem, wenn mehrere Versionen einer Klasse in der Datenbank vorhanden sein können. Versionsverwaltung ist eine wünschenswerte Eigenschaft eines Datenbanksystems, das den menschlichen Entwurfsprozeß unterstützen soll.