Von Friedrich Koopmann*

Die meisten Anwender im kommerziellen Bereich setzen, auch wenn objektorientiert programmiert wird, in der Regel weiter auf die bewaehrte relationale Technologie. Wer auch bei der Datenspeicherung die Objektorientierung durchhalten will, geht, wie das Beispiel des Duesseldorfer Rechtsschutzversicherers Oerag zeigt, zunaechst einen steinigen Weg, der aber schliesslich doch einigen Gewinn bringt.

Neue Applikationen sollten, so entschied 1991 die DV-Leitung bei Oerag, nur noch auf Basis von Client-Server-Strukturen entwickelt werden. Die Informationsverarbeitung beruhte zu diesem Zeitpunkt ganz auf Host-basierten Anwendungen, die auf einem Rechner beim Partnerunternehmen Provincial-Versicherung in Duesseldorf, liefen.

Zunaechst begann die DV-Abteilung damit, eine lokale Datenbank aufzubauen, um Anfragen zu Bestandsdaten zu beschleunigen und zu vereinfachen. Statt beim jeweiligen Partner anzufragen und moeglicherweise erst am naechsten Tag von dessen Bestandsabteilung eine Antwort zu bekommen, sollten die Daten vor Ort im direkten Zugriff verfuegbar sein. Realisiert wurde dies mit C-Programmen unter OS/2 Presentation Manager (PM) und Sybase als Datenbank.

Die 1992 fertiggestellte Anwendung hatte den Effekt, so Sam Sepehran, Abteilungsleiter Anwendungsentwicklung bei Oerag, "dass das Interesse der Sachbearbeiter an PC-Programmen stieg. Sie sahen, dass sich dadurch neue Moeglichkeiten bieten und PM-Programme leicht zu erlernen sind. Die Anwender aeusserten zunehmend den Wunsch, das alte Host-basierte-System zur Schadenbearbeitung abzuloesen".

Aber die Konstellation aus C, PM und einer relationalen Datenbank bedeutete aus Sicht des Entwicklerteams einen Bruch zwischen der Analyse auf der einen sowie Design und Implementierung auf der anderen Seite. "Wenn wir zusammen mit der Fachabteilung Analysen machten, waren die Mittel zur Umsetzung nicht gut genug", beschreibt Sepehran die Erfahrungen aus der Entwicklung der Sybase-Anwendung. "Wir wollten eine bessere Wartbarkeit des Produkts. Wenn das fachliche Problem sich aendert, muss man sofort sehen, was sich machen laesst, ohne lange Dokumentationen studieren und Sourcecode-Reviews vornehmen zu muessen."

Schliesslich entschieden sich die DV-Spezialisten fuer Objektorientierung, weil sie in ihr - im Unterschied etwa zu strukturierter Programmierung oder 4GLs - die Moeglichkeit sahen, "die Wuensche der Endanwender transparent darzulegen". Die Methodik schien die gewuenschten Vorteile in Sachen Wartbarkeit der Software zu bieten.

Das erste Projekt war die Entwicklung einer Anwendung fuer die 1992 gegruendete Oerag Service GmbH. Die Unternehmenstochter, die 30 Mitarbeiter beschaeftigt, bietet Assistance-Dienste an.

Dazu zaehlen unter anderem Leistungen aus Schutzbriefen fuer Auto und Reise oder im Zusammenhang mit der Krankenversicherung im Ausland. Versicherte rufen an, wenn sie zum Beispiel eine Autopanne in Spanien haben. Die Duesseldorfer sorgen dann dafuer, dass ein Abschlepper kommt, ein Taxi besorgt, ein Hotel gebucht, eine Zugfahrkarte bestellt und das Auto eventuell zur Hauptwerkstaette ueberfuehrt wird.

Vorgaenge muessen einfach und durchschaubar sein

Die verschiedenen Massnahmen muessen organisatorisch zusammenlaufen. Wichtig ist dabei ein Wiedervorlagesystem, das die Abwicklung sichert. Benoetigt wird weiterhin ein leistungsfaehiges Abbuchungssystem, das Zusammenarbeit mit verschiedenen Partnern bei den einzelnen Dienstleistungen erlaubt. Bei der Verrechnung ist zu beruecksichtigen, dass die Kunden eventuell Teilzahlungen zu leisten haben oder manchmal ein anderer Dienstleister wie der ADAC einen Teil der Kosten uebernimmt.

Fuer den Sachbearbeiter sollen diese Vorgaenge einfach und durchschaubar abzuwickeln sein. Neben der leichten Bedienung waren Hauptanforderungen an die Anwendung, dass sie schnell und stabil zu sein habe. Das System muss sieben Tage in der Woche rund um die Uhr verfuegbar sein.

Das Projekt begann Anfang 1993. Dabei sollte ein Softwarehaus die damals aus acht Personen bestehende Entwicklungsabteilung unterstuetzen. Einen Partner mit Erfahrungen in Versicherungsanwendungen, OS/2 und Objektorientierung zu finden, war damals, so Sepehran, kaum moeglich. Denn objektorientierte Projekte liefen in diesem Bereich gerade erst an. Das gewaehlte Unternehmen Softpro aus Boeblingen erfuellte aber die ersten beiden Bedingungen. Um das Defizit an objektorientiertem Know-how auszugleichen, zogen beide Teams jeweils einen Experten auf diesem Gebiet hinzu.

Eine der Grundbedingungen war, dass die Anwendung ORB-faehig zu sein hatte, also den Corba-Normen des Object Request Broker fuer Interoperabilitaet zwischen Objekten entsprechen. Konkret bedeutete dies, die ORB-Implementation von IBM (SOM/DSOM) zu unterstuetzen. Dadurch wollten die Entwickler erreichen, dass die Applikation skalierbar ist. Und fuer die zukuenftige Kommunikation mit anderen Anwendungen sollte eine genormte Schnittstelle vorhanden sein.

Die Auswertung laufender Projekte ergab, dass Unternehmen, die in puncto Objektorientierung weit vorangeschritten waren, bei der Implementierung einen Bruch hinzunehmen hatten, wenn eine gewachsene relationale Datenbank zu integrieren war. Da es bei der Service GmbH keine solche Erbschaft gab, wollte man die Objektorientierung auch bei der Datenspeicherung durchhalten. "Fuer uns", so erlaeutert Sepehran das Konzept, "konnte ein relationales DBMS mit einem Object-Layer keine lang- oder auch nur mittelfristige Strategie sein. Wir wollten durchgaengige Objektstrukturen realisieren."

Ein wichtiges Kriterium bei der Auswahl der Datenbank war das Zusammenspiel mit der Programmiersprache C++, fuer die sich der Entwicklungsstab entschieden hatte. Des weiteren war ausschlaggebend, ob unbedingt benoetigte Merkmale vorhanden waren, die bei objektorientierten Datenbanken auch heute noch keineswegs selbstverstaendlich sind. Gefordert wurden Mechanismen fuer Backup und Recovery sowie Transaction Logging und die Faehigkeit, mit grossen Datenmengen umzugehen. Anhand dieser Kriterien und weiterer Leistungsdaten fiel die Wahl auf "Objectstore" von Object Design.

Probleme beim Umstieg

Was der Umstieg auf eine objektorientierte Datenbank bedeutet, wurde den Entwicklern erst im Laufe des Projekts klar, das im Oktober 1993 begann. So fehlen etwa bei relationalen Systemen selbstverstaendliche Dinge wie ein Tool fuer Im- und Export von Datensaetzen in Form von ASCII-Tabellen. "Solche Methoden mussten wir mitten im Projekt implementieren", erinnert sich Sepehran. "Das bedeutete Redesign, Veraenderung in vielen Komponenten, die bereits erstellt waren und stabil liefen."

Ein anderes Problem war die Auslegung der Datenbank fuer Multiuser- Betrieb. Objectstore ist eine Client-orientierte Datenbank. Jeder Client hat einen Cache, der die Daten enthaelt, mit denen der Anwender arbeitet. Wenn Veraenderungen an den Daten vorgenommen werden, erfolgt eine Benachrichtigung zwischen Client und Server. Unter Umstaenden loest dies einen Refresh von Caches anderer Clients aus. Da bestimmte Veraenderungen das System blockieren koennen, kam es im Projektverlauf immer wieder zu Deadlock-Situationen.

Die Kenntnis darueber, wann solche Konstellationen auftreten und wie man sie durch entsprechendes Design verhindert, war in der Mannschaft noch nicht vorhanden. "Das notwendige Know-how", so Sepehrans Erfahrung, "erwirbt man nicht innerhalb von zwei Monaten. Um die Datenbank zu beherrschen, bedarf es sehr umfangreichen Background-Wissens und guter Designentscheidungen."

Die Aufgabenverteilung zwischen Server und Client sei ganz anders als bei relationalen Systemen. So gebe es keine Server-side- Queries, Abfragen liefen vielmehr grundsaetzlich auf der Client- Seite ab. Die Anwendungsseite regelt, wo was geschieht. "Wir programmieren in vielen Bereichen, in denen bei relationalen Datenbanken der Hersteller die Verarbeitungsmechanismen zur Verfuegung stellt. Daher koennen die Ergebnisse durch fehlendes, nicht ausreichendes Know-how auch schlecht sein. Die Performance- Unterschiede zwischen gutem und schlechtem Code sind enorm, oft ein Vielfaches."

Schlechtes Design raeche sich bei einer objektorientierten Datenbank wie Objectstore. Umgekehrt seien die Ergebnisse bei gutem Design auch ausgesprochen gut. Sepehran schaetzt, dass es laenger als ein halbes Jahr gedauert habe, bis sein Team gewusst habe, wie man es richtig macht.

Als nach wie vor bestehenden Nachteil erwaehnt er die Durchfuehrung von Schema-Aenderungen. Diese sind notwendig, wenn ein Datenbankmerkmal so veraendert wird, dass die Datenbank nicht mehr kompatibel zur vorherigen Struktur ist. Doch die Transformation ist bei Objectstore bisher noch nicht im Online-Betrieb moeglich. Das heisst, fuer etwa vier Stunden koennen die Anwender nicht aktiv mit dem System arbeiten, sondern nur passiv Daten abrufen. Bei einem Unternehmen, das ohne Unterbrechung jeden Tag 24 Stunden auf sein DV-System angewiesen ist, bedeutet das durchaus ein Problem.

Da Object Design bisher kein Verfahren zur Online-Schemaaenderung angekuendigt hat, will man bei Oerag versuchen, die Datenbank so zu organisieren, dass sich die Transformationen in kleinere Zeiteinheiten aufsplittern lassen. Im bald vollendeten ersten Einsatzjahr sind zwei Schemaaenderungen angefallen.

Ansonsten waren die Erfahrungen mit der Anwendung, die seit Maerz 1994 laeuft, also in knapp eineinhalb Jahren fertiggestellt wurde, im wesentlichen positiv. Die Programme liefen vom ersten Tag an stabil; einen Absturz des Gesamtsystems hat es nicht gegeben.

Sepehran hebt vor allem die hohe Akzeptanz bei den Anwendern hervor: "Da sie von Anfang an und zyklisch immer wieder in den Entwicklungsprozess einbezogen wurden, verstehen sie die Programme auch als ihr eigenes Werk. Daher besteht eine Akzeptanz, wie ich sie bisher nicht gekannt habe."

Gestaltet ist die Anwendung nach Art eines Aktenordners, in dem die Anwender ueber Laschen die verschiedenen Bereiche oeffnen. Die Antwortzeiten liegen auch bei Suchoperationen immer unter zwei Sekunden.

Rund 20 User arbeiten parallel mit der Anwendung. Die Arbeitsplaetze, an denen auch andere Applikationen wie Lotus Notes oder Textverarbeitung laufen, sind mit 486er PCs mit 32 MB RAM ausgestattet. Die Datenbank befindet sich auf zwei AIX-Rechnern RS/6000 58H, die sich im Stand-by-Betrieb gegenseitig gegen Ausfall sichern.

Mitte 1994 begann das Hauptprojekt, eine Anwendung fuer die Schadensbearbeitung in der Oerag AG. Bis Ende 1996 wollen die DV- Experten damit fertig sein. Die inzwischen auf elf Mitarbeiter erweiterte Entwicklungsabteilung arbeitet daran im wesentlichen ohne externe Unterstuetzung. Im neuen Projekt kommt die erworbene Erfahrung zum Tragen.

Waehrend er den Aufwand bei der ersten Anwendung als im Vergleich zu konventionellem Vorgehen hoeher einschaetzt, registriert Sepehran inzwischen einen deutlichen Beschleunigungseffekt. Man sei jetzt etwa doppelt so schnell wie bei herkoemmlicher Programmierung. Designvorgaben aus der ersten Anwendung liessen sich uebernehmen und viele Komponenten wiederverwenden.

Bei der Datenbank vermisst der Oerag-Entwicklungsleiter noch einige Funktionen. Object Design habe zwar im Laufe des ersten Projekts bestimmte Anforderungen der Versicherung umgesetzt, so etwa hinsichtlich des Multiuser-Betriebs; aus dem CAD/CAM-Bereich kommend, arbeite der Hersteller offenbar ernsthaft an den neuen Aufgaben. Was aber noch fehle, seien Tools fuer die Administration, die End-User-Anwendungsentwicklung und fuer Reports.

Der Einstieg in die neue Technologie habe, so Sepehrans Resuemee, "Schweiss und Traenen gekostet". Aber die Muehen haetten sich gelohnt. Denn man verfuege jetzt ueber die "mit Abstand beste Software unter den Assi-stance-Dienstleistern. Durch strukturiertes Ablegen der Informationen und Transparenz bei der Schadenbearbeitung sind wir in der Informationsverarbeitung als einem entscheidenden Element unserer Dienstleistung ein Stueck voraus."

*Friedrich Koopmann ist freier DV-Fachjournalist in Muenchen.