Auch heute noch wird ein grosser Anteil der Unternehmensdatenbestaende mit aelteren Datenbanktechnologien verwaltet. Wegen der Inflexibilitaet zur Strukturaenderung und der Notwendigkeit, Riesenbestaende mit alten Anwendungen weiterfuehren zu muessen, ist nur langsam ein Uebergang zu neuen Datenbanktechnologien durchsetzbar. Relationale Datenbanksysteme sind ein wichtiger Schritt in Richtung offene Systeme, Hardware- und Betriebssystemunabhaengigkeit und Schaffung eines Datenbank- Sprachstandards. Mit der Moeglichkeit, Implementierungsdetails vor dem Anwendungsentwickler verbergen zu koennen, stellen sie einen wesentlichen Schritt in Richtung Datenunabhaengigkeit der Anwendungen dar.
Obwohl es noch Jahre dauern wird, bis dieser Vorteil fuer den Grossteil der benutzten Anwendungen greifen wird, wendet man sich jetzt schon wieder den neuen objektorientierten Datenbanken zu. Von den Chancen und Gefahren, die beim Uebergang von der einen zur anderen, beziehungsweise gar beim Ueberspringen der relationalen Datenbanktechnologie auftreten koennen, soll die Rede sein.
Der Gedanke "persistenter Objekte" ist zunaechste einmal verlockend. Gemeint sind damit Objekte, die ueber das Programmende hinaus erhalten bleiben. Somit ist auch zunaechst einmal naheliegend, die Objekte so behandeln zu wollen, als waeren sie gewoehnliche Typ-Konstrukte und Instanzen einer Objekt-orientierten Programmiersprache e la C++ oder Smalltalk. Ein Ansatz koennte sein, die virtuellen Speichermechanismen des zugrundeliegenden Betriebssystems nutzen zu wollen, um ein Ansprechen der Objekte mit den gleichen syntaktischen Mitteln zu ermoeglichen, wie es auf Ebene der Programmiersprache ebenfalls getan wuerde.
Dieser vordergruendige Vorteil erzwingt aber die Vermischung von Schemadaten mit dem eigentlichen Anwendungscode und hat damit unmittelbar eine hohe Datenabhaengigkeit zur Folge. Die Auswirkungen der Aenderungen des Datenschemas koennen somit auf Dauer nicht mit ueberschaubarem Aufwand verwaltet und gepflegt werden.
Objektorientierte Datenbanksysteme verdanken ihre Popularitaet hauptsaechlich den Anwendungsbereichen, in denen die Struktur des verwendeten Datenmodells eher unstrukturiert und komplex ist. Beispiele dafuer sind Multimedia- und CAD-Anwendungen. Ein weiterer Vorteil, den man sich von OODB verspricht, ist die geclusterte Abspeicherung (Objektballung) von Objekten. Ziel ist das schnelle Lokalisieren und Laden von grossen Objekten.
Viele Hersteller von OODB haben sich leider dazu verleiten lassen, diese Clusterung eins-zu-eins auf die externen Datentraeger zu uebertragen. Damit hat man den Grund fuer eine weitere fatale Abhaengigkeit gelegt, die schon den Verwendern hierarchischer Datenbanksysteme viel Kummer beschert hat.
Den Vorteil des schnellen Zugriffs erkauft man sich mit dem Riesennachteil der absoluten Inflexibilitaet bezueglich Schemaaenderungen sowie dem Nachteil, keine symmetrischen Datenbankabfragen stellen zu koennen. Wo relationale Datenbanken noch durch dynamisch erzeugbare externe Sichten auf wechselndes Benutzer-Abfrageverhalten eingestellt werden koennen, findet man bei objektorientierten Datenbank-Implementierungen in der Regel die Struktur der Daten fest eingebrannt vor.
Der Grund des Uebels bei Verwendung von Sprachen wie C++ und Smalltalk liegt darin, dass es eine klare Unterscheidung zwischen funktionaler/operationaler Repraesentation einer Anwendung (in der Regel der Programmquelltext) und struktureller Repraesentation gibt (in der Regel die zu einer Applikation gehoerenden externen Programmressourcen, wie Data-Dictionaries, Repositories, Programm- Resourcefiles ...).
Eine Aenderung in jeweils einer der Repraesentationsformen hat in der Regel einen nicht klar absehbaren Aenderungsbedarf in der korrespondierenden Ressource zur Folge.
Einen Ansatz, von dieser Art von Datenabhaengigkeit los zu kommen, kann man nur dann finden, wenn man vom Paradigma des "Dualismus von Programm und Daten" ausgeht.
Programmiersprachen wie Lisp, Prolog und Assembler erfuellen die Grundvoraussetzungen dafuer, da jeder Teil eines Programmes sowohl als Datum oder als Befehl angesehen werden kann. In dem vom Assembler erzeugten Maschinencode kann man dem einzelnen Byte genausowenig ansehen, ob es sich um Befehlscode oder Datenteil einer Instruktion handelt, wie man auch bei Lisp-Programmen nicht ohne weiteres erkennen kann, ob es sich um einen algorithmischen Programmteil oder lediglich nur um die Listenrepraesentation der Datenstruktur eines Binaer-Baumes handelt.
Damit ist der Weg fuer einen generellen Loesungsansatz vorgezeichnet. Wenn man davon ausgeht, dass die Performance nicht allein das ausschlaggebende Kriterium ist, sondern dass insbesondere die Flexibilitaet fuer Schemaaenderungen und ein im Mittel gutes Such- und Updateverhalten sicher eher die Garanten fuer einen oekonomischen Betrieb und die Wartbarkeit der Vielzahl der Datenbankanwendungen sind, dann kann dieser Loesungsansatz nur ueber die konsequente Einfuehrung des Paradigmas vom "Dualismus von Programm und Daten" gefunden werden. Das bedeutet nichts anderes, als dass Programme in der Datenbank abgelegt und von dort aus ausgefuehrt werden koennen, aber auch dort editiert und geaendert werden koennen. Viele Ansaetze mit Datenbank-Sprachen, 4GL-Sprachen und Script-Sprachen kommen diesem Prinzip bereits sehr nahe. Moeglicherweise kommen auch die fruehen Ansaetze der Methodenbanksysteme vom Beginn der siebziger Jahre wieder zu neuer Aktualitaet.
Datenunabhaengigkeit bekommt man im Umkehrschluss natuerlich nur durch Indirektionismen. Diese kosten zusaetzliche Ausfuehrungszeit durch Interpretation. Moeglicherweise ist das einer der Gruende, warum dieser Weg noch nie in der vollen Konsequenz beschritten wurde. Im Zeitalter des Client-Server-Computing und des zunehmenden Rechnerdurchsatzes duerfte die Performance aber nicht mehr lange ein haltbares Gegenargument sein.
Nun gilt es, den durch die relationalen Datenbanksysteme aufgezeigten, richtigen Weg konsequent fortzusetzen. Was sich im einzelnen bei der Datenmodellierung als Performance-Bremse erweist, die Normalisierung der Relationen, scheint ein hohes Mass an Robustheit gegen Schemaaenderungen zu bewirken. Ueber die Join- Operationen werden die Benutzersichten nach Bedarf materialisiert. Noch flexibler werden kann man nur durch eine totale Normalisierung der Anwendungsdaten in eine Art binaeres, semantisches Datenmodell. In diesem spielen die Objekte den zentralen Part, an den sich wiederum wie um einen Atomkern die Attribut-Wert-Beziehungen gruppieren.
Jederzeit lassen sich die Beziehungen zwischen Objekten und ihren Attribut-Werte-Beziehungen erweitern, aendern oder aufloesen. Die sich daraus ergebende Objekte-Chemie ermoeglicht es auf einem mindestens eine Stufe abstrakteren Niveau Datenunabhaengigkeit zu garantieren. Es sind Ansaetze bekannt, wie sich diese Ziele erreichen lassen bei gleichzeitiger Verwirklichung von vollstaendig redundanzfreier Datenspeicherung und dynamischer Voll-Indexierung. Ueber die Beruecksichtigung einer Zeitdimension lassen sich zudem Konzepte wie Versionsverwaltung und zeitbasierende Datenmodelle realisieren.
Von hier ist es dann nicht mehr weit zur Realisierung von Datenbanksystemen mit Superset-Funktionalitaet. Ein solches System waere in der Lage, fuer einen moeglicherweise sogar verteilten Datenbankbestand eine nach Wunsch hierarchische, Netzwerk-, relationale oder gar Objekt-orientierte Sichtweise anzubieten. Jedes beliebige Datenmodell und jede beliebige Abfragefunktionalitaet kann dem Anwendungsentwickler zur Verfuegung gestellt werden. Aehnliche Ansaetze wurden bereits im Bereich der Entwicklungsumgebun-gen fuer portable Software mit grafischer Benutzeroberflaeche erfolgreich umgesetzt.