Bei den sogenannten "postrelationalen" Datenbanken handelt es sich entweder um Erweiterungen relationaler Systeme oder um Modifikationen des Relationenmodells. Harald Summa* gibt in seinem Beitrag einen Ausblick auf die künftige Entwicklung von Datenbanksystemen. In fünf bis sechs Jahren ist nach Ansicht des Kölners mit "echten objektorientierten Systemen" zu rechnen.

Um den wachsenden Anforderungen an die Datenhaltung zu genügen, kommen immer mächtigere Datenbanksysteme zum Einsatz. Systeme, die auf alle Anwendungsfälle gleichermaßen passen, wird es aber auch in Zukunft nicht geben.

Von Lochkarten zu Magnetplatten

Daten sind das zentrale wirtschaftliche Gut, um das sich die gesamte Datenverarbeitung letztlich dreht. Betrachtet man die Geschichte der DV und damit in gewissem Sinne auch die Historie der Datenhaltung, so sind zwei deutlich getrennte Generationen auszumachen. Am Anfang wurden Informationen in Papier gestanzt und auf Lochkarten fixiert - aus heutiger Sicht ein kaum noch vorstellbarer Zustand, in den 70er Jahren Realität. Die Listen und Lochkarten wurden in der zweiten Generation von Magnetplatten abgelöst. Zur besseren Gewöhnung an die neue Zeit erhielten die Bildschirme entsprechend der Spaltenzahl einer Lochkarte 80 Zeichen.

Diese auf magnetischen Informationsträgern fixierten Daten konnten nach Belieben vermehrt werden, da sie einfacher waren und permanent für die Programmierer zur Verfügung standen. Diese Daten ließen sich so im Programmspeichern, wie es der jeweilige Programmierer für richtig hielt. Das Wissen um die Semantik der Daten lag direkt in den Programmen. Die so immer mehr zunehmende Unübersichtlichkeit machte den Einstieg in die Datenbanktechnologie notwendig.

Die Erfinder der Datenbanktechnologie wollten die bisherige Anbindung von Daten an Programme zugunsten einer unabhängigen Datenhaltung aufbrechen. Zudem sollten Redundanz und die damit eng verbundene Problematik einer fehlenden Datenintegrität vermieden werden. Der vorhandene Datenbestand sollte von allen Benutzern quasi gleichzeitig zugreifbar sein.

Ergebnis dieser Überlegungen waren Datenbank-Management-Systeme (DBMS), ursprünglich gedacht für die Verwaltung großer Datenbestände in Großrechnern. Diese DBMS waren von Anfang an sehr komplex, da sie eine Abbildung der realen Welt in den Daten zum Ziel hatten.

Je nach Modell stehen die Daten in einer hierarchischen Beziehung zueinander, oder sie sind in einem Netz von Beziehungen verwoben. Diese Systeme erleichtern die Designphase eines Datenmodells und dessen Abbildung auf eine Datenbank. Sie zeigen bei statischen Anwendungen ein exzellentes Zeitverhalten, sind aber in der Programmierung sehr aufwendig.

Theorie der relationalen Datenhaltung

Bereits Ende der sechziger Jahre wurde darüber nachgedacht, wie man dieses Problem lösen könnte. Basierend auf der Mengenlehre wurde die Theorie der relationalen Datenhaltung geboren. In diesem Ansatz werden alle Daten in Tabellen abgelegt. Direkte Beziehungen zwischen Daten wie im Netzwerk- oder hierarchischen Modell gibt es nicht. Auf Grundlage der Arbeiten von Edgar F. Codd und Chris Date entwickelte die Industrie Produkte, mit denen wir heute zu arbeiten beginnen.

Jeder, der ein Projekt nach relationalen Methoden über die verschiedenen Stufen der Realisierung gebracht hat, weiß um die Schwierigkeiten: Die Normalisierung zerlegt das Datenmodell in atomare Teile; große Mengen von Daten stehen in primitiven Tabellenstrukturen, aber in großer Anzahl auf dem Magnetträger. Das Ergebnis ist ein hoher Speicherbedarf. Bei vielstufigen Zugriffen auf Daten über mehrere Tabellen entsteht eine Performance-Problematik. Die Betrachtung einer realen Datenwelt führt über den Umweg einer Normalisierung der Daten. Und dies bedeutet eine Zerlegung der Datenobjekte in atomare Tupel.

Für sehr viele, besonders für kommerziell orientierte DV-Problemstellungen, schafft die Normalisierung ein klares Bild für das DV-Design, was die verwendeten Daten und ihre Beziehungen angeht. In der technischen DV-Welt ist ein Aufbrechen von Datenobjekten auf normalisierte Tabellen mit einem größeren Aufwand verbunden.

So ist zum Beispiel ein Roboter als Datenobjekt in seine einzelnen Bestandteile zu zerlegen, die dann in Tabellen abgelegt werden. Sobald die zerlegten Objekte zur Laufzeit wieder zusammengesetzt werden, treten mit Sicherheit Performance-Probleme auf. Rein relationale Datenbanken sind in solchen Anwendungsfallen nicht selten überfordert.

Die technische Entwicklung hat dazu geführt, daß Anwender heute im Kommunikationsverbund arbeiten können. An Fließbändern und in Hochregallagern der Fabriken stehen dezentrale Einheiten, die mehr oder weniger geschickt an die Zentrale angebunden sind. Dabei werden die zu verwaltenden Datenstrukturen immer komplexer. So müssen Datenbanksysteme Zeichnungen oder Spezifikationen für Konstruktionsdaten verwalten können und komplexe Abfragen erlauben.

Rechenleistung und Speicherkapazitäten spielen heute quasi keine Rolle mehr. Rechenleistung muß nicht mehr zentral vorgehalten werden. Sie ist am Arbeitsplatz vor Ort erhältlich. Die schier unbegrenzte Rechnerkapazität und -leistung erlaubt Entwicklungen, die noch vor Jahren ausgeschlossen schienen. Zunehmend rückt dabei der Mensch in den Mittelpunkt der DV-Entwicklung.

Die DV-Strategen beginnen zu erkennen, daß mit intelligenten grafischen Benutzerschnittstellen eine bessere und höhere Produktivität erzielt wird. Man nähert sich dem Menschen und seinem typischen Verhalten über objektorientierte Sprachen. Hier liegt die Schnittstelle zur Datenhaltung.

Es liegt in der Natur der zukünftigen Anwendungen, daß die Repräsentation eines beliebigen Objektes auf einem grafischen Schirm ihre Entsprechung in objektorientierten Strukturen der Datenrepräsentation sucht. Die flachen Tabellen der relationalen Datenbanken sind dafür nicht geeignet - verlangt werden mächtigere Konstrukte. An diesem "postrelationalen Ansatz" wird heute gearbeitet.

Kürzere Zugriffszeiten und weniger Speicherbedarf

Dabei lassen sich zwei Richtungen erkennen. Bei der ersten Tendenz handelt es sich entweder um Erweiterungen relationaler Systeme oder Erweiterungen des Relationenmodells. Zu diesem Ansatz gehören Systeme mit NF2-Relationen (NF2 = non first normal form). Diese "nicht normalisierten" Relationen ermöglichen es, innerhalb einer Tabelle weitere Tabellen als Datenelement zu speichern, diese zu schachteln und somit ein mächtiges Datenobjekt zu definieren.

Das NF2-Modell erlaubt die Definition mehrwertiger Felder und geht damit über das relationale Modell hinaus Die Attribute einer Relation dürfen auch auf mehrfachen und zusammengesetzten Werten bestehen und können sogar selbst wieder Relationen sein. Trotzdem stehen dem Anwender dieselben Operationen zur Verfügung, die er von den relationalen Systemen her kennt. So kann bei diesem Ansatz SQL als Abfragesprache mit Erweiterungen genutzt werden.

Nebeneffekt der wesentlich kompakteren Darstellung der Daten sind erheblich kürzere Zugriffszeiten und weniger Plattenspeicherbedarf: Ein vollständiges NF2-Modell ist in einem kommerziellen Produkt bisher noch nicht verwirklicht. Der NF2-Ansatz wird gegenwärtig in mehreren Prototypen angewandt. Unter anderem verfolgt das Heidelberger Forschungszentrum der IBM diese Richtung. Als relationales Datenbanksystem mit NF2-Relationen mit einer Implementierung über invertierte Listen kommt das System "Pisa" von Infodas dem NF2-Modell bereits sehr nahe.

Auf der zweiten Seite finden sich recht unterschiedliche Ansätze, die von den Entwicklungen in objektorientierten Programmiersprachen geprägt sind. In dieser Klasse gibt es ebenfalls bereits Systeme, die vermarktet werden. Dazu zählt zum Beispiel das SISP-basierte System "Statice" von Symbolics.

Die voll objektorientierten Systeme befinden sich alle noch im Prototyp-Stadium. Zu den bekannteren gehört "Postgres", das designierte Nachfolgesystem des relationalen "Ingres". Diese unterschiedlichen Ansätze in verfügbaren Produkten geben zu der Hoffnung Anlaß, daß in fünf

oder sechs Jahren echte objektorientierte Systeme verfügbar sein werden. Wenn man bedenkt, daß die relationalen Systeme etwa 20 Jahre gebraucht haben, um vom theoretischen Entwurf bis zur Marktdurchdringung zu gelangen, ist das eine gute Perspektive. +