Das relationale Konzept, von Edgar F. Codd vor 20 Jahren formuliert, kommt langsam in die Jahre. Noch bevor die Unternehmen in großen Umfang relationale Datenbanken eingesetzt haben, diskutiert die Fachwelt schon über weitergehende Modelle. Worauf müssen sich die Unternehmen gefaßt machen?
Die Diskussionen in der Fachwelt deuten an, daß das Relationenmodell von Codd nicht mehr "in" ist. Die DV-Praxis der Unternehmen dagegen zeigt, daß relationale Datenbanken erst richtig im Kommen sind. Viele Unternehmen haben in letzter Zeit beschlossen, nur noch auf relationale Datenbanken zu setzen - auch für operative Anwendungen. Mit einer solchen Entscheidung steht den Unternehmen trotzdem noch eine Migrationszeit von fünf bis zehn Jahren ins Haus, bis die letzte "Alt-Datenbank" abgelöst ist. Damit würde das Relationenmodell 25 bis 30 Jahre nach seiner ersten Formulierung den Einzug in die DV-Praxis vollzogen haben.
Hat sich die DV-Methodik seit 1970, als Codd sein Modell vorstellte, überhaupt nicht weiterentwickelt? Oder stehen schon weitergehende Konzepte bereit, während die Unternehmen Zeit und Geld in veraltete Ansätze stecken? Um diese Fragen besser beantworten zu können, sollte man zunächst einmal klarstellen, was das Relationenmodell umfaßt und was nicht.
Wichtig zum Verständnis ist, daß das Relationenmodell ein Daten-, aber kein Datenbankmodell ist. Insofern stellt es einen richtungsweisenden Ansatz dar. Hier wurden zum ersten Mal methodisch abgesicherte Regeln formuliert, die die Organisation von Daten und ihre systematische Bearbeitung umfassen.
Das Regelwerk von Codd zwölf Basis- und 30 Zusatzregeln - läßt sich drei Bereichen zuordnen:
- Datenorganisation,
- Datenmanipulation und
- Datenintegrität
Oberfläche aus der Sicht des Benutzers
Aus den wesentlichen Anforderungen des Relationenmodells (siehe Abbildung 1 auf Seite 30) läßt sich erkennen, daß dieses Modell keinerlei Vorschriften über die technische Lösung beinhaltet, sondern nur die Oberfläche eines Datenbank-Management-Systemes (DBMS) - also aus Sicht des Benutzers - beschreibt. Somit ist zum Beispiel "Performance" keine Eigenschaft des Relationenmodells; trotzdem wird sie aber benötigt.
Auf diesen Regen Basierend, konnten Sprachmittel und Operationen implementiert werden, die ein wesentlich höheres Maß an Abstraktion, Mächtigkeit und Datenunabhängigkeit für die Programme oder interaktiven Nutzer bieten. Aus der Vielzahl von Implementierungen schälte sich SQL von IBM als Standard heraus. Doch damit beginnen auch die Probleme. Denn SQL deckt keineswegs alle Coddschen Regeln zur Datenmanipulation ab. So enthält es zum Beispiel auch prozedurale Sprachelemente oder Einzelsatz-Operationen (bei SQL in Programmen).
Verstärkt fallen die Mängel der relationalen Sprache SQL bei komplexen Strukturen wie zum Beispiel Stücklisten auf. Bei einer Stückliste ist die Schachtelungstiefe variabel. Für eine variabel häufige Abarbeitung der gleicher Operation bietet SQL aber keine Sprachmöglichkeit, denn SQL unterstützt keine rekursiven Operationen.
Als Notlösung müssen Programmierer so viele ineinandergeschachtelte Cursor-Operationen programmieren, wie es mögliche Stücklistenstufen gibt. Dies ist weder elegant, noch wird das Ziel einer Unabhängigkeit zwischen Programmen und Daten erreicht.
Die semantische Lücke produziert Unsinn
Größere Schwierigkeiten treten allerdings in der Überführung des konzeptionellen Modells in das relationale, das wiederum Basis der DB-Systeme ist, auf. Während der Analysephase arbeitet man nach dem "Entity-Relationship"-Modell von Chen. Dies kennt sowohl Informationsobjekte ("Entitäten") als auch die Beziehungen zwischen ihnen. Bei der Überführung in das Relationenmodell (zum Beispiel für DB2, Oracle oder Ingres) werden
a) die Entitäten aufgrund der Normierungsregeln zerstückelt und
b) die Beziehungen zwischen den Daten vergessen.
Es geht damit also Wissen verloren. Konsequenz ist, daß die Informationen über eine Entität erst mittels SQL-Anweisungen wieder mühsam zusammengesetzt werden müssen. Außerdem sind in jeder SQL-Anweisung die Beziehungen zwischen den Daten durch die Join-Kriterien explizit zu formulieren (siehe Abbildung 2). Da das RDBMS keine Ahnung über die wirklichen Beziehungen zwischen den Daten hat, sind solch unsinnige Operationen möglich wie:
- Join zwischen Kunden- und Auftragsdaten, wobei die Kundennummer im Auftrag gleich der Postleitzahl beim Kunde sein soll, oder
- mische jeden beliebigen Kunden mit jedem beliebigen Auftrag.
Letztgenannte Operation bezeichnet man als ein kartesisches Produkt. Diese Operation ist mathematisch zwar korrekt, aber praktisch Unsinn. Doch Endbenutzer und weniger routinierte Programmierer fallen darauf immer wieder herein.
Dieser Verlust des Wissens über Beziehungen zwischen den Daten ist eine methodische Schwäche des Relationenmodells. Obwohl ihm Primär- und Fremdschlüssel bekannt sind (für referentielle Integrität), ist es nicht in der Lage, diese Kenntnis bei der Datenmanipulation zu verwenden.
Das Relationenmodell fußt auf normalisierten Tabellen. Doch inzwischen haben die Anwender erkannt, daß eine konsequente Normalisierung in der Praxis an ihre Grenzen stößt. Nicht nur der Verlust an Übersicht durch die Zerstückelung, sondern insbesondere Performance-Probleme machen eine De-Normalisierung notwendig.
So wurde zum Beispiel die Entscheidung von SAP, ihre bekannte Standardsoftware auf Basis relationaler Datenbanken neu zu schreiben, von IBM immer gerne als Beweis für die Eignung von DB2 zitiert. Doch auch SAP hütet sich, seine Datenbestände - insbesondere die Belegdatei - zu sehr zu normalisieren, wenn das Ganze noch laufen soll.
Wenn man also in Praxis sowieso die Normalisierung in Frage stellte warum sollte man dann nicht gleich im Datenmodell andere Datenstrukturen zulassen?
Statt die Informationsobjekte in normalisierte Tabellen zu zerstückeln könnte man diese auch geschlossen speichern. Dazu müssen komplexere Strukturen wie Mehrfachfelder und -gruppen zulässig seine wie zum Beispiel in dem heuristisch entstandenen Datenmodell von Adabas.
Auf ein solches Konzept sind vor einigen Jahren auch die Forscher von IBM am Wissenschaftlichen Zentrum in Heidelberg gestoßen. Ihr Modell heißt "NFFD-Modell", was aus NFNF (= Non first normal form) abgeleitet ist. Hierzu haben sie nicht nur eine Erweiterung der SQL-Syntax erdacht, sondern dies alles auch in ein lauffähiges DBMS namens "AIM" verwandelt. Sie beweisen damit, daß das Strukturproblem des Relationenmodells lösbar ist.
Auch die Kenntnis über die Beziehungen zwischen Daten und die automatisch Abarbeitung von Strukturen hat sich in produktive DB-Systeme implementieren lassen (siehe Abbildung auf Seite 29). Es handelt sich hierbei um Entity-Relationship-Datenbanksysteme (E/R-DBMS). Vertreter dieser Gattung sind das Entire auf Basis von Adabas und der Repository Manager von IBM.
Interessant ist, daß der Repository Manager, der auf DB2 aufsetzt, ein allgemein verwendbares E/R-DBMS ist und damit nicht nur für das Repository geeignet ist. Damit wird bewiesen, daß man auf einem relationalen DBMS ein noch mächtigeres aufsetzen kann.
Objektorientierung ist mehr als eine Mode
Bereits Codd hatte gefordert, daß ein DBMS auch so viel Wissen über die Daten besitzen soll, daß deren Integrität sichergestellt werden kann. Hierzu gehören gültige Wertebereiche (Domänen-Konzept) und Beziehungsregeln. Letztere enthalten neben den trivialen Regeln der referentiellen Integrität (RI) viele an Möglichkeiten durch "User defined integrity".
Dies wird zum Beispiel in Sybase (= Microsofts SQL Server) und Ingres mit "Trigger" und "Stored procedures" realisiert. Dadurch läßt sich der größte Teil der bisher in Programmen eingebauten Prüfungen Einfügen, Ändern oder Löschen von Daten sparen und einmalig beim DBMS hinterlegen.
Noch weitergehend ist der Ansatz - objektorientierter DB-Systeme, bei denen nicht nur Prüf-, sondern auch jegliche Art von Verarbeitungsregeln mit den Daten definiert und gekapselt werden.
Auch können derartige Objektfunktionen wiederum andere Objekte anstoßen, so daß auch komplizierte Verarbeitungsprozesse lediglich mit dem an die Daten gekoppelten Wissen ablaufen.
Ein weiterer wesentlicher Bestandteil der Objektorientierung ist die Vererbung. Dadurch braucht man Eigenschaften und Funktionen nicht für jedes einzelne Objekt erneut zu beschreiben, wenn diese Objekte einer gemeinsamen Klasse angehören. Vererbung spart nicht nur Arbeit, sondern vermeidet auch Fehler.
Die technische Realisierung von OO-Datenbanken sollte man nicht zu euphorisch sehen. Wenn die Objektfunktionen, zu denen auch die ganzen Datenprüfungen gehören, erst zum, Zeitpunkt der DB-Operationen ausgeführt werde, ist es zu spät. Denn viele Prüfungen sollten bereits bei der Dateneingabe durch den Benutzer stattfinden. Deshalb müssen die Verarbeitungsregeln auch in den Werkzeugen, mit denen die Anwendungen erstellt werden, wirken. Ein Beispiel hierfür ist die regelbasierte Sprache Sapiens, bei der keine Programmierung mehr anfällt.
Objektorientierung aber hat wesentlich weitergehende Auswirkungen als nur auf die Technik von DB-Systemen und Sprachen. Sie verändert das Denken und die Vorgehensweise bei der Analyse und ermöglicht die Konstruktion stabiler und redundanzfreier Software. Auch ohne OO-DBMS kann somit Nutzen aus dem objektorientierten Ansatz gewonnen werden (siehe CW Nr. 49 und 50 vom 7. und 14. Dezember 1990: "Unternehmens-Datenmodell plus OO-Ansatz gleich Synergieeffekt").
Welche Konsequenzen kann man hieraus ziehen? Auf diese Frage antwortet die Kolumne auf Seite 29.
Michael Bauer ist langjähriger DB/DC-Fachmann und Geschäftsführer der Informatik Training GmbH, Radolfzell.