Die Umstellung konventioneller Dateitechnik auf ein Datenbanksystem wirft Probleme auf. Vorhandene Programme sollen nicht geändert werden, und die Stammdaten sind meist längst Gegenstand der laufenden Verarbeitung und stellen einen Geschäftswert eigener Art dar. Manfred Flieger, Projektleiter in der Systemplanung der Colonia Bausparkasse AG aus Dortmund, beschreibt, wie das Unternehmen durch einen selbstentwickelten Strukturwandler einen hohen Grad an Datenunabhängigkeit erreicht hat.

1981 wechselte die Colonia Bausparkasse von einer IBM/3-15D auf eine Siemens-Anlage 7.541 unter BS 2000. Die vorhandenen RPG-Programme wurden unverändert übernommen. Allerdings mußten die E/A-Routinen für ISAM-Zugriffe abgeändert werden. Anfang dieses Jahres führte die Colonia das Datenbanksystem Abadas ein. Diese Maßnahme erfolgte als Teil einer neuen Gesamtkonzeption für die künftige Anwendungsentwicklung.

Eines der wichtigsten Ziele von Datenbankinstallationen ist die Unabhängigkeit der Programme von Daten und Datenstrukturen. Mit Unterstützung durch ein Beratungshaus wurde das DB-Design in Anlegung an den "Entity Relatonship Approach" nach P. Chen entwickelt. Hierbei wird die reale Datenwelt mit einem Datenmodell beschrieben, aus dem ein Informationsschema als rein logische Sicht der Daten resultiert.

Stammdaten sind problematisch

Dieser anwendungs- und softwareunabhängige Weg zum idealen DB-Entwurf löst jedoch nicht das Hauptproblem jedes gestandenen EDV-Anwenders: Wie sollen Stammdaten aus einem jahrzehntelang gewachsenen Zustand schnell, sauber und sicher in eine nach völlig neuen Gesichtspunkten strukturierte Datenbank übertragen werden. Eine 1:1-Umstellung mit sukzessiver Auflösung der Dateien in eine veritable Datenbankstruktur verlagert das Problem, löst es aber nicht.

Die vorhandenen Stammdaten sind längst Gegenstand der Verarbeitung durch einen großen Programmbestand. Sie stellen einen hohen Geschäftswert eigener Art dar. Und auch neue Anwendungen müssen von ihnen Gebrauch machen.

Die Reorganisation der Stammdaten auf Datenbankbasis erfordert daher eine konzentrierte Bearbeitung. Außerdem verlangt die starke Abhängigkeit zwischen Anwendungen und Stammdaten eine Umstellung in kürzester Frist.

Die Erstellung von Übertragungsprogrammen einerseits und die Änderung der vorhandenen Programme andererseits erschienen uns nicht als rationelle Lösung - weder in wirtschaftlicher noch in zeitlicher Hinsicht; vom Risiko solcher Umstellungen ganz zu schweigen.

Aufwand und Risiko begrenzen

Folgende Idee brachte uns auf die Lösung. Man kann die ISAM-Struktur der vorhandenen Stammdateien aus Sicht der Verarbeitungsprogramme doch als eine spezifische Datenbank-Benutzersicht (user-view) betrachten. Könnten während der Laufzeit eines Programmes die ISAM-Strukturen in Adabas- und umgekehrt die Adabas- in ISAM-Strukturen umgewandelt werden, dann ließen sich die vorhandenen Programme unverändert einsetzen.

Das war die Idee vom dynamischen Strukturwandler. Seine Entwicklung beanspruchte ein Mannjahr.

Das Prinzip der Strukturwandlung besteht darin, daß der Anwender ein beliebiges Satzmuster (user-view) definiert und daß diese Benutzersicht zur Programmlaufzeit vom Strukturwandler interpretiert wird.

Beispiele dafür auf der Basis der vorhandenen Programme sind: die Verteilung eines oder mehrerer ISAM-Sätze zu einem Datenbank-Satz, die Aufteilung eines ISAM-Feldes auf mehrere Abadas-Felder oder die Beseitigung von redundanten ISAM-Feldern.

Anwendungsprogramm bleibt unbehelligt

Auch bei neuen Programmen definiert der Anwendungsprogrammierer seine Datenforderungen als Benutzersicht, die der Wandler zu interpretieren hat. Dafür muß dem Wandler die entsprechende Wandlungsvorschrift eingebaut werden, und das Programm kann laufen.

Der Vorteil aus dieser Methode ist nicht unerheblich: Denn auch ein relationales DB-System bietet ja keine absolute Datenunabhängigkeit. Aber wenn künftig einmal die DB umstrukturiert werden soll, dann wird kein einziges Anwendungsprogramm betroffen sein - es müssen lediglich die Wandlungsvorschriften geändert werden. Damit ist generell Datenunabhängigkeit für die Programme erreicht.

Wie erstaunlich gering der Aufwand dafür ist, belegen die Erfahrungen aus der Umstellung. Es wurden nur drei Wochen benötigt, um die Grundschemata für die vorhandenen 490 Programme zu entwickeln. Die Analyse eines ISAM-Satzes anhand der Cross-Referenzen und die Definition der Benutzersicht beanspruchen längstens vier Stunden. Wenn es sich aber um einen Satz mit nur zehn Feldern handelt, ist das Ganze eine Angelegenheit von fünf Minuten.

Werkzeug mit Langzeitnutzern

Die Einsatzbereiche des Strukturwandlers lassen sich wie folgt zusammenfassen:

- Übernahme der ISAM-Dateien in die Datenbank. Keine Erstellung von Übertragungsprogrammen.

- Betrieb der vorhandenen Anwendungen mit dem neuen DB-System.

- Testhilfe, weil die Dateien auch wieder in die alte Form gebracht werden können.

- Immer, wenn sich bei einem vorhandenen Programm Laufzeitprobleme ergaben, wurde die Benutzersicht so definiert, daß dem Programm nur noch die tatsächlich benötigten Felder geliefert werden - und nicht mehr alle Felder eines ursprünglichen ISAM-Satzes aus Adabas herausgesucht werden.

Der Strukturwandler verschafft jedoch auch für künftige Aufgaben einen Spielraum.

Obwohl RPG nicht auf dem DB-System oder Colonia einsetzbar ist, können RPG-Neuentwicklungen vorgenommen werden, die auf Adabas-Daten zugreifen. Auch alle künftigen Anwendungen bleiben von Änderungen der DB-Strukturen unberührt.

Der Strukturwandler wurde softwareunabhängig geschrieben; er besitzt sowohl eine ISAM- als auch eine Adabas-Schnittstelle. Daraus ergeben sich zwei weitere Aspekte der Datenunabhängigkeit:

Die Colonia ist in der Lage, das DB-System zu wechseln und beim Kauf von Fremdsoftware, die ja immer andersartige Datenstrukturen verlangt, diese Software dennoch und unverändert einsetzen. Es müssen nur die entsprechenden Benutzersichten für den Strukturwandler definiert werden.

Bei der Umstellung von konventionellen Dateien auf die Datenbank wurde weder in Übertragungsprogramme mit "Wegwerfcharakter" noch in Programmänderungen investiert; statt dessen haben wir einen dynamischen Strukturwandler geschaffen. Dieses Werkzeug hat uns den üblichen Umstellungsaufwand und das hohe Umstellungsrisiko erspart.