Objektorientierte Ansätze werden in der letzten Zeit vehement propagiert. Gleichwohl bestehen nach Meinung von Hartmut Schaper* Zweifel, ob diese Technologie den Sprung in die Praxis schafft. Denn während ihre Befürworter vor allem den grundsätzlichen, qualitativen Fortschritt sehen, werden sich wohl gerade Unternehmen mit einer bereits bestehenden DV-Infrastruktur fragen, ob sie sich damit nicht bestenfalls eine weitere technologische Insellösung einhandeln. Alles hängt daher von der Art und Weise des Einstiegs ab. Eine praxisnahe Möglichkeit ist die objektbasierte Integration existierender Datenbanken mit aktiven Views.
Die meisten großen Unternehmen verfügen über eine in vielen Jahren gewachsene DV-Welt, in der Daten aus historischen Gründen oft in verschiedenen Datenhaltungssystemen mit zum Teil inkompatiblen Schnittstellen gespeichert sind. Integritätsbedingungen sind, wenn überhaupt vorhanden, direkt in den bestehenden Anwendungen ausprogrammiert, so daß eine globale, anwendungsübergreifende Konsistenzsicherung aller Daten nur schwer möglich ist. Dies führt zu einem erhöhten Wartungsaufwand, der dringend benötigte Kapazitäten für die Neu- und Weiterentwicklung blockiert. Als Lösung für die daraus resultierende sogenannte Softwarekrise wird in letzter Zeit zunehmend der Einsatz objektorientierter Werkzeuge in Analyse und Programmierung propagiert.
Nun bietet die objektorientierte Programmierung in speziellen Entwicklungsumgebungen, wie dem von Xerox bereits Anfang der siebziger Jahre entwickelten Smalltalk-System, sicherlich die Möglichkeit einer evolutionären Systementwicklung unter Verwendung kybernetischer Vorgehensweisen wie dem Rapid Prototyping. Darüber hinaus wird die Wiederverwendbarkeit von Codes durch die stärker ausgeprägten Lokalitäts- und Strukturierungseigenschaften solcher Systeme gegenüber konventionellen Ansätzen verbessert. Zudem ist die integrierte Benutzerschnittstelle dieser Umgebungen selbst objektorientiert und bietet einen hohen, grafisch unterstützten Benutzerkomfort. Diese Schnittstelle kann - wie alle Systemkomponenten - einfach in eigene Anwendungen integriert werden, was die Produktivität in der Anwendungsentwicklung erheblich steigern kann.
Wesentliche Schwachpunkte solch dezidiert objektorientierter Ansätze sind jedoch oft die fehlenden Integrationsmöglichkeiten für bestehende Anwendungen und Daten. Werden dagegen objektorientierte Vorgehensweisen ausschließlich in der Systemanalyse verwendet, so entsteht häufig eine semantische Lücke, wenn die in der Analyse gefundenen und klassifizierten Strukturen dann auf dafür ungeeignete, konventionelle Werkzeuge abgebildet werden müssen.
Ein sinnvoller Einsatz neuer Technologien ist jedoch nur möglich und wirtschaftlich, wenn vorhandene Programme und Daten als Bausteine problemlos in die neue Umgebung eingebunden werden können. So werden nicht nur die Investitionen in vorhandene Programme und Datenbestände geschützt, sondern auch das bei den Mitarbeitern vorhandene Wissen. Damit lassen sich neben einer deutlichen Kostensenkung auch viele soziale Widerstände, die sonst bei der Einführung neuer Techniken auftreten, schon im Ansatz verhindern oder zumindest abmildern.
Unter diesen Gesichtspunkten sind objektbasierte Systeme eine vielversprechende Entwicklung. Objektbasierte Systeme bestehen aus komplexen, strukturierten Objekten. Diese entsprechen den in der Analyse identifizierten Objekten der realen Welt und enthalten neben einer Datenstruktur die dafür definierten Methoden. Jedes Objekt gehört einer logischen Einheit (Klasse) an, aber im Gegensatz zu objektorientierten Systemen gibt es keine Hierarchie von Klassen und entsprechend keine Vererbung von Methoden oder anderen Attributen.
Damit bietet der objektbasierte Ansatz eine wesentlich flexiblere Struktur, die die Integration mit der bestehenden DV-Welt vereinfacht, da alle bereits vorhandenen Programme und Datensichten als eigenständige Objekte in diese Betrachtungsweise integriert werden können. Somit kann der neue Ansatz ohne Veränderungen an bestehenden Objekten eingeführt werden und im Zuge der notwendigen Weiterentwicklung eine schrittweise, evolutionäre Anpassung an die neuen Denk- und Vorgehensweisen erreicht werden.
Eine gute Möglichkeit, objektbasierte Vorgehensweisen zu etablieren, bietet sich bei der Erstellung und Umsetzung eines unternehmensweiten, einheitlichen Datenmodells. Um dabei objektbasiert vorgehen zu können, müssen die vorhandenen Daten-Views aktiviert werden. Das heißt daß logische Datensichten (Views) nicht mehr nur ausschließlich aus einer Auswahl von Datenfeldern bestehen, sondern darüber hinaus auch die für diese Daten erlaubten Zugriffe definieren. Eine aktive View muß also alles Wissen über die verwendeten Daten und die definierten Zugriffsmethoden enthalten und selbst wieder möglichst umgebungsunabhängig programmierbar sein.
Auch benutzerdefinierte Manipulationen möglich
Die Felder innerhalb einer aktiven View können aus verschiedenen heterogenen und über ein Netz verteilten Datenbanken stammen. Als Zugriffe auf die Daten sind sowohl standardisierte DB-Zugriffe wie Select oder Update, als auch komplexe, benutzerdefinierte Datenmanipulationsmethoden möglich.
Eine solche benutzerdefinierte Methode könnte zum Beispiel "Storniere-Auftrag" oder "Buche-Ticket" heißen und in der aktiven View eine Vielzahl unterschiedlicher Aktionen bewirken. Damit kann unabhängig von der Anwendungslogik die semantische Integrität strukturierter Objekte gewahrt werden, ohne - wie bei expliziter referenzieller Integrität möglich - das Prinzip der Lokalität von Wirkungen zu verletzen.
Semantische Integrität bedeutet eine umfassende, alle Bereiche eines Objekts umfassende Integrität, die durch Überführung eines Objekts von einem konsistenten Zustand in einen anderen implizit die referenzielle Integrität in den darunterliegenden Datenbanken sicherstellt. Damit verfügt das Anwendungsprogramm über semantisch mächtige Zugriffsmethoden, die von der jeweiligen tatsächlichen Implementierung (zum Beispiel relationale/nichtrelationale DB) unabhängig sind und keine weiteren Auswirkungen auf nicht in der aktiven View referenzierte Daten haben.
Durch diese zusätzliche Abstraktionsebene ist sogar ein Wechsel des DB-Systems möglich, ohne die vorhandenen Anwendungen anpassen zu müssen. In der Einführungsphase objektbasierter aktiver Views, können alle vorhandenen Views als aktive Views definiert werden, die über die in den jeweiligen DB-Systemen vorhandenen Standardmethoden (wie SQL) verfügen. Vorhandene Zugriffe auf diese Views bleiben unberührt, da lediglich eine Erweiterung der vorhandenen Funktionalität erfolgt. Somit kann ein neuer einheitlicher Formalismus geschaffen werden, ohne die vorhandenen Anwendungen verändern zu müssen.
Aktive Views sind in der Lage, verschiedene Typen von Datenbanken aufeinander abzubilden. Strukturierte Informationen wie sie in Sätzen mit multiplen Feldwerten enthalten sind, können als flache relationale Tabellen dargestellt werden. Umgekehrt können aus normalisierten, zweidimensionalen Tabellen komplexe Objekte gebildet werden, die das Anwendungsprogramm als ganzes manipulieren kann. Damit wird das Wissen über die technische Realisierung solcher Objekte wieder aus den Anwendungen herausgenommen und zentral für alle betroffenen Anwendungen in einer aktiven View abgelegt. Anwendungen greifen nur noch direkt auf Anwendungsobjekte wie Aufträge oder Roboter zu, anstatt diese aus einer Vielzahl von Einzelinformationen selbst zusammenfügen zu müssen. Da solche aktiven Views beliebig miteinander kombinierbar sind, bleibt eine maximale Flexibilität für Modifikationen oder Ergänzungen wie in rein relationalen Systemen erhalten.
Neben der Beschreibung der Leistungsfähigkeit aktiver Views selbst sind natürlich auch Fragen der einfachen Handhabung und der Performance zu beachten. Dazu gehören
zum Beispiel umfangreiche automatische Optimierungen. Für die Zugriffe muß es eine statische Vorplanung zur Übersetzungszeit geben, die, falls notwendig, automatisch zur Laufzeit korrigiert und automatisch gesichert wird, um Mehrfacharbeit zu vermeiden. Auch manuelle Eingriffsmöglichkeiten in die verwendeten Optimierungsalgorithmen sowie eine assoziative Planverwaltung, um ähnlich strukturierte View-Zugriffe nur einmal zu planen, sollten vorhanden sein.
Und nicht zuletzt ist die Integration mit anderen Werkzeugen wesentlich. Dazu gehören etwa ein aktives Datendiktionär, das alle Integritätsregeln zentral verwaltet, und CASE-Tools, die konzeptionelle Modellierungstechniken wie Aggregation oder Generalisierung von Daten unterstützen und aktive Views direkt aus der Analyse generieren.
Die beschriebenen aktiven Views ermöglichen so eine vollständige Integration der stehenden DV-Anwendungen mit einem objektbasierten Ansatz beim DB-Zugriff. Damit werden die Vorteile objektorientierten Denkens und Handelns unter minimalen Reibungsverlusten auf die D\/ übertragen, denn weder vorhandene Software noch vorhandenes Wissen müssen abgeschrieben werden. So kann dies der erste Schritt zu allgemeinen aktiven Objekten sein, die vom Programmierer nur noch nach dem Baukastenprinzip zusammengesetzt werden müssen.