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.

03.04.1998 - 

Hindernisse beim Umstieg

Hindernisse beim Umstieg Oracle 8: Rudimentäre Interfaces für den Client

Mit Oracle 8 haben Anwender erstmals die Möglichkeit, im Rahmen der relationalen Datenbank alternativ oder ergänzend objektorientierte Strukturen abzubilden.Wichtig dabei ist, daß sich die Datenbestände der Objekte über spezielle Views immer auch in eine konventionelle Ansicht konvertieren lassen. Umgekehrt können auf konventionelle Tabellen Objektsichten eingerichtet werden.

Die Migration der Altdaten erfolgt schrittweise, wobei zunächst einzelne Tabellen als Objekttypen definiert und anschließend die verbleibenden Tabellen nachgezogen werden.Die neu aufgenommene Sprachsyntax zur Verwaltung der Objekttypen ist relativ einfach.

Positiv läßt sich das System auch bezüglich der Methodenimplementierung bewerten.Aufgrund der Tatsache, daß den Objekttypen Funktionen zugeordnet werden können, ist in Oracle 8 ein unmittelbarer Bezug zur Entwicklung von Client-Anwendungen hergestellt.Dies war bislang nicht der Fall, da die Implementierung einer PL/SQL-Prozedur in keinem direkten Zusammenhang zur Client-Entwicklung stand.

Zudem wird es künftig neben der etwas "rauhen" Sprache PL/ SQL auch Java geben: Borlands "Jbuilder" soll integriert werden.Damit will der Hersteller die im C++- und Java-Umfeld aktiven Client-Entwickler motivieren, ihre Funktionen differenzierter zwischen Client und Server zu plazieren.

Vorteile ergeben sich somit auch für den Projektalltag, der bislang davon geprägt war, daß die Daten bei Client-Server-Systemen von der Datenbank geladen wurden und die Implementierung der Funktionalität üblicherweise auf dem Client stattfand.Die Verwendung nahezu gleicher Sprachen sowohl auf Client- wie auf Server-Seite macht einen Wechsel von der Client- zur Server-Implementierung deutlich einfacher.

Probleme tauchen dann auf, wenn Oracle 8 in bestehende Frameworks integriert werden soll (Frameworks werden üblicherweise eingesetzt, um die Objektpersistenz in einer relationalen Datenbank zu sichern).

Bis auf wenige Ausnahmen stehen die Mechanismen von Oracle 8 in Konkurrenz zu den bisher verwendeten Frameworks.Dreh- und Angelpunkt ist dabei das gegenüber der Vorgängerversion erheblich veränderte "Oracle Call Interface" (OCI), das selbst Funktionen zur Objektpersistenz bereitstellt.Die Schnittstelle liegt als DLL vor und kann über C/C++ relativ leicht angesprochen werden.Die Aufrufe sind jedoch sehr rudimentär und in dieser Form völlig ungeeignet, um sie im Rahmen einer Applikationsentwicklung einzusetzen.Hier muß über das Framework in jedem Fall eine Kapselung vorgenommen werden.

Bis sich das System zur Applikationsentwicklung eignet, sind bei der OCI-Funktionalität noch viele Defizite zu beheben.Ein Problem ist beispielsweise auch, daß OCI kein Metamodell zur Verfügung stellt.Metamodelle sind Informationen über den Zustand und die Struktur eines Objekts zur Laufzeit.So lassen sich Attribute, Vererbungs- oder Objektbeziehungen ermitteln und auch Veränderungen innerhalb eines Objektes erkennen.Bei der relationalen Anbindung dient das Metamodell zur dynamischen Generierung von SQL-Anweisungen.Innerhalb von Release 8 wird es diese Aufgabe zwar so nicht mehr geben, dennoch bilden die Metainformationen einen unverzichtbaren Bestandteil der Applikationsentwicklung, insbesondere wenn es um die Kopplung an die relationalen Strukturen des Vorgänger-Release geht.

Zu den eigentlichen Stärken eines objektorientierten Systems gehört die Möglichkeit, von der Geschäftsprozeßmodellierung über fachliche Objektmodelle und Systementwurf bis hin zur Implementierung durchgängig vorgehen zu können. Eckpfeiler dabei sind die Modellierungswerkzeuge, die sich an Standards wie der Unified Modelling Language (UML) orientieren.Alle Abschnitte des Entwicklungsprozesses werden über das entsprechende OO-Tool abgebildet und unterstützt.Das Repository des OO-Tools spiegelt den Stand der gesamten Entwicklung wider.

Entscheidende Schwächen zeigten die Werkzeuge bislang allerdings im Bereich der Administration relationaler Datenbanken.Mit Oracle 8 wird diese Lücke ein Stück weiter geschlossen.Die zum Aufsatz der Datenbank notwendigen Skripte können über die vom Hersteller angebotenen OO-Tools generiert werden.

Produkte von Drittanbietern, im relationalen Bereich häufig verwendet, unterstützen die Administration objektrelationaler Datenbanken derzeit allerdings noch nicht ausreichend.Bis dies der Fall ist, müssen die Anwender oft über den Weg selbstgeschriebener Skripte ausweichen.

C-Strukturen behindern durchgängiges Projektieren

Das von Oracle vorgesehene Tool zur Generierung der Client-seitigen Klassen ist für durchgängig aufgesetzte Projekte eher ungeeignet.Der Hersteller gibt hier einen Weg vor, bei dem zunächst Objekttypen auf der Datenbank eingerichtet werden.In einem zweiten Schritt werden dann statische C-Strukturen über den Object Type Translator (OTT) generiert, die sich schließlich in die Client-Entwicklung integrieren lassen.

Das Problem hier sind die statischen Strukturen.Ein deutlich eleganterer Ansatz bestünde darin, daß zur Laufzeit ein Pufferbereich mit den benötigten OCI-Objekten dynamisch bereitgestellt würde.

Ein Konflikt ergibt sich für den Anwender auch im Bereich Objekt-Cache und Objektinstanzierung.Ein Objekt-Cache der aktuell geladenen Objekte ist ein typisches Merkmal für Frameworks zur Anbindung objektorientierter und relationaler Datenbanken.Allerdings werden einige dieser Funktionen künftig von OCI übernommen und müssen deshalb aus den bisher verwendeten Frameworks ausgelagert werden.

Ein Objekt-Cache wird innerhalb des OCI auf dem Client verwaltet.Dort stehen auch sehr mächtige Operationen zur Verfügung.So können einzelne Objekte oder der ganze Objekt-Cache mit der Datenbank abgeglichen werden.Ein detailliertes Benennen geänderter Felder wie innerhalb eines "Update"-Statements ist nicht weiter notwendig.OCI-Objekte erlauben außerdem Objekttransaktionen, also reversible Zustandsveränderungen: Moderne Oberflächen mit "Undo"-Funktionen erfordern solche Mechanismen.

Um OCI-Transaktionen und -Objekt-Caches nutzen zu können, muß das Framework jedoch erheblich angepaßt werden.Wesentliche Teile sind auszulagern und werden von OCI übernommen.Ein vergleichbares Problem ergibt sich für die Objektinstanzierung, die bislang im Framework stattfand und künftig vollständig über OCI abgewickelt wird.

Derzeit noch ungelöst sind die Probleme in Sachen Vererbung.Wenn nur die OCI-Objektinstanzierung verwendet wird, steht Vererbung ausschließlich über die Aggregation (Objekt in Objekt) zur Verfügung.Dieses Vorgehen entspricht zwar dem Microsoft-Objektverständnis von COM, aber nicht der in der Fachwelt vorherrschenden Auffassung von Objektorientierung.

Damit Vererbung über die OCI-Funktionalität erreicht werden kann, müssen entsprechende Mechanismen in das Framework integriert werden.Diese Aufgabe fiel zwar auch schon bei den bestehenden Frameworks an, sie muß jedoch mit der Oracle-8-Einführung neu gelöst werden.

Frameworks

Wer heute eine relationale Datenbank zur Verwaltung von Objekten einsetzt, hält diese üblicherweise mit Hilfe eines Frameworks persistent.Dem Framework fallen dabei eine Reihe von Aufgaben zu:

-Abbildung von Klassen, Attributen, Beziehungen und Vererbung,

-dynamische Objektinstanzierung,

-Objekt-Caching und Garbage-Collection (C++),

-Metainformationen über Klassen, Attribute und Beziehungen,

-Hilfsklassen etwa für Abfragen und Debugging,

-Transaktionen auf Objektebene,

-Verwaltung von Nebenläufigkeit sowie

-Anbindung an Codegenerierung aus dem Objektmodell etwa über die Skriptsprache der Modellierungs-Tools.

Rainer Schmidberger ist Geschäftsführer, Volker Kölle Berater für objektorientierte Systeme bei der IBL Ingenieurbüro Letters GmbH, Leinfelden.