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.

12.09.1997 - 

Objektorientierung/Ein Persistency Framework gegen veränderungsbedingte Zerrüttungen

Objekte und Tabellen dauerhaft miteinander verkuppeln

Objektorientierte Datenbanksysteme (ODBMS) bilden Dinge der realen Welt mit ihren Eigenschaften wirklichkeitsnah ab und eignen sich deshalb besonders gut zur Speicherung komplexer Daten, zum Beispiel für Multimedia- und Internet-Anwendungen oder zur Modellierung komplexer Produkte. Mit objektorientiert programmierten Applikationen verstehen sich ODBMS blind, weil beide identische Konzepte wie Vererbung unterstützen.

Müssen ODBMS allerdings mit bestehenden nicht-objekt-orientierten Applikationen zusammenlaufen, sind sie langsamer als relationale. Denn die zugrundeliegenden Konzepte sind unterschiedlich und müssen zunächst aufeinander abgebildet werden.

Objektrelationale Datenbanksysteme (ORDBMS) verfolgen einen hybriden Ansatz: Einerseits speichern sie Daten relational, bilden andererseits aber Datenstrukturen objektorientiert ab. In relationale Datenbanken sind sie nicht problemlos integrierbar. ORDBMS kommen bisher nur in wenigen Unternehmen zum Einsatz.

Relationale Datenbanksysteme (RDBMS) eignen sich mit ihrer Tabellenstruktur besonders gut zur Speicherung einfach strukturierter Massendaten wie etwa Kundenadressen, die alle nach dem gleichen Muster aufgebaut sind. RDBMS sind wohl in allen Unternehmen im Einsatz und haben sich dort seit Jahren erfolgreich bewährt. Zu objektorientierten Applikationen finden sie keinen Zugang, weil ihre Tabellenstruktur objektorientierte Konzepte zunächst nicht unterstützt.

Dennoch möchten viele Unternehmen beide Technologien verbinden, um von den Vorteilen der objektorientierten Applikationsentwicklung ebenso zu profitieren wie von jenen der bewährten RDBMS, auf deren Basis oft viele Applikationen laufen.

Objektorientierte CASE-Tools können in der Beziehung zwischen OO-Applikationen und relationalen Datenbanksystemen allerdings nicht als Kuppler fungieren: Sie unterstützen den Entwickler zwar bei der OO-Modellierung und bei der Klassendefinition, nicht jedoch bei der Anbindung an ein RDBMS. Überall wo relationale Datenbankschemata generiert und Werte aus dem RDBMS gelesen oder dorthin zurückgeschrieben werden sollen, ist zunächst einmal sehr aufwendige SQL-Programmierung vorausgesetzt.

Da die Software-Entwicklung ein iterativer Prozeß ist, reicht es nicht aus, die Schnittstellen nur einmal sauber zu programmieren: Anwendungen werden Schritt für Schritt entwickelt und dann kontinuierlich angepaßt und verbessert. Wie in einer persönlichen Beziehung muß auch das ständigen Veränderungen ausgesetzte Zusammenspiel von OO-Applikationen und RDBMS reibungslos laufen.

Manuell ist das kaum zu leisten, weil man gerade bei komplexen Applikationen nur schwer und mit viel Dokumentationsaufwand den Überblick behalten kann. An eine schnelle und effiziente Weiterentwicklung der Systeme ist dann nicht zu denken.

Hilfe verspricht ein Persistency Framework. Dabei handelt es sich um eine Abstraktionsschicht zwischen dem objektorientierten Datenmodell und dem relationalen Datenbanksystem. Wie ein Übersetzer bildet es OO-Konzepte wie Vererbung, komplexe Objekte oder Objektidentität automatisch auf die Schemata relationaler Datenbanksysteme ab.

Damit ein Persistency Framework diese Übersetzung leisten kann, muß es zum einen - auf der logischen Ebene - über das objektorientierte Datenmodell verfügen und andererseits Mechanismen bereitstellen, die daraus - auf der physikalischen Ebene - die entsprechenden Datenbankschemata und den SQL-Code der Objektoperationen erzeugen. Die Strategien zur Übersetzung der Objekt- in die Tabellenstrukturen sollten auf konzeptioneller Ebene im Persistency Framework definiert sein und für den Entwickler vollkommen transparent bleiben.

Soll zum Beispiel Vererbung auf RDBMS-Schemata abgebildet werden, empfehlen sich - je nach Kontext - unterschiedliche Strategien:

Im Falle einer Eins-zu-eins-Vererbung entsteht für jede Objektklasse eine Tabelle. Diese einfache Strategie ist zum Einstieg in die Methodik beliebt. Allerdings müssen bei komplexen Anfragen zahlreiche SQL-Statements ausgeführt werden, die viel Zeit in Anspruch nehmen können.

Anders beim Weg über abstrakte Klassen: Liegen Objektklassen vor, die keine eigenen Instanzen haben, also abstrakte Klassen, ist es nicht erforderlich, die Persistenz für diese Klassen sicherzustellen, was die Anzahl der notwendigen SQL-Statements reduziert.

Und schließlich gibt es den Ansatz über Hierarchien in einzelnen Tabellen: Die Subklassen einer Oberklasse lassen sich auch in einer Tabelle zusammenfassen, die dann allerdings meist ziemlich komplex gerät. Der Vorteil: Auch im ungünstigsten Fall muß nur ein SQL-Statement ausgeführt werden, weil sich alle Informationen aus einer Tabelle lesen lassen.

Damit der kontinuierliche Software-Entwicklungsprozeß im Unternehmen nicht immer wieder an der Schnittstelle zwischen objektorientierten Applikationen und relationalen Datenbanksystemen ins Stocken gerät, muß das Persistency Framework einige zentrale Anforderungen erfüllen:

Es sollte alle OO-Konzepte vollständig unterstützen, weil auch bei einer partiellen Unterstützung immer noch viel per Hand zu programmieren wäre. Zu den zentralen OO-Konzepten gehören zum Beispiel Vererbung, abstrakte Klassen, Delegation, Polymorphismus, komplexe Objekte (Aggregation, Referenzbeziehungen etc.) und Objektidentität. RDBMS-Konzepte wie Dynamic- und Static-SQL oder Stored Procedures, Transaktionen, Sperren und Sicherheit sollten ebenso umfassend erhalten bleiben.

SQL-Programmierung weitgehend reduzieren

Sowohl Reverse Engineering, die Nutzung bestehender Datenbankspezifikationen, als auch Forward Engineering, der Entwurf neuer Datenbankstrukturen, sollten unterstützt werden. Auf diese Weise lassen sich bestehende IT-Strukturen optimal weiternutzen und neue flexibel aufbauen. Das Persistency Framework sollte weder eingebundene Entwicklungsumgebungen noch Datenbanksysteme in ihrer Funktionalität einschränken, damit ihre Leistungsfähigkeit und ihr Komfort für den Entwickler gewahrt bleiben.

Die Implementierung der Persistenz sollte vollständig gekapselt sein, damit kein SQL-Code von Hand zu programmieren ist. Alle Datentypen sollten geprüft und automatisch in das entsprechende Format konvertiert werden. Dazu gehören zum Beispiel atomare Typen (int, short etc.), einfache Typen (String, Integer, Date etc.), komplexe Typen (eigene Klassen wie Kunde, Auftrag etc.) und Mengen (Vektor aus Auftrag, Vektor aus Kunde etc.).

Entwicklungs-Tools müssen sauber passen

Der Mechanismus Model-View-Controller sollte keine Einschränkung erfahren, weil er aufgrund seiner Vorteile in der objektorientierten Programmierung bereits breite Akzeptanz gefunden hat. Andere Werkzeuge wie OO-Modellierungs-Tools müssen integrierbar sein, damit sie alle Entwicklungsphasen optimal und nahtlos fördern können.

Das Persistency Framework muß sich bei neuen Anforderungen erweitern und anpassen lassen. Es sollte natürlich schnell und durchsatzstark laufen. Dafür sind unter anderem Caching-Mechanismen von Vorteil, um bereits abgefragte Daten ausnutzen zu können oder statische Daten nicht öfter als einmal abfragen zu müssen.

Die Arbeit mit einem solchen Persistency Framework verringert nicht nur den ansonsten enormen Programmieraufwand, sondern öffnet auch den gesamten Entwicklungsprozeß: Die einzelnen Phasen werden durchgängiger, und die Applikationsentwicklung gestaltet sich damit einfacher.

Angeklickt

Unternehmen, die einerseits ihre Applikationen objektorientiert entwickeln, andererseits aber ihre Daten in einem relationalen Datenbanksystem halten wollen, landen schnell bei einem Problem: Auf welche Weise lassen sich beide Technologien zusammenfügen, ohne die Schnittstelle bei jeder Änderung wieder programmieren zu müssen? Wie ein Persistency Framework aus dem schwierigen Verhältnis zwischen OO-Applikationen und relationalen Datenbanksystemen einen stabilen, aber flexiblen "Bund fürs Softwareleben" stiften kann, zeigt dieser Beitrag.

*Anders Bonde ist Technischer Direktor von The Danish Object Company in Hellerup, Dänemark.