DBDCDD

05.11.1982

In thematisch zusammenhängenden Beiträgen beschäftigt sich Michael Bauer mit Fragen des Ob und Wie einer Datenbank-Implementierung, der Auswahl eines geeigneten TP-Monitors und der Ausbildungserfordernisse je nach Benutzerebene. Außerdem stehen Themen wie Data Dictionary, Dritte Normalform, neue Hochsprachen und Datensicherheit im Mittelpunkt seiner Erörterungen.

Kapitel IV, Teil 2

Kaum Kompatibilität der DB/DC-Systeme

Man kann zwar mittels der Träger-Software - also dem DBMS oder dem TP-Monitor seine Programme leichter auf andere Betriebssysteme oder gar andere Hardware transportieren, aber man kann kaum das BDMS oder den TP-Monitor austauschen. Die DB- und DC-Software ist im Prinzip inkompatibel zueinander, so daß gravierende Umstellungen der Programme die Folge sein würden. In den meisten Fällen ist Wegwerfen und Neuprogrammieren der beste Weg.

Sicher kommt jetzt die Frage: "Aber es gibt doch Codasyl-Datenbanksysteme; sind die nicht, untereinander kompatibel?" Und Radio Eriwan würde darauf antworten: "Im Prinzip ja, aber..."

Zum einen gibt es für die meisten Anwender nicht mehrere Codasysl-DBMS, zwischen denen man wechseln könnte. Welche Codasyl-Alternative hat zum Beispiel ein IBM-Anwender?

Zum anderen waren die Codasyl-DBMS nie vollständig kompatibel und haben sich in den letzten Jahren noch weiter auseinanderentwickelt. Es gibt bei einzelnen DBMS Funktionen, die andere wiederum nicht besitzen, wodurch auch die Sprachelemente betroffen sind. Ein Wechsel zu einem anderen Hersteller könnte den Wechsel zu einem anderen Codasyl-DBMS zur Folge haben; doch dies wird sicherlich nicht problemlos sein.

Ein Lichtblick hinsichtlich der Kompatibilität ergibt sich durch sogenannte "run-time interfaces". Sie lassen DB-Anwendungsprogramme ohne Änderung mit einer anderen Datenbank ablaufen, indem sie zur Ausführungszeit die DB-Anweisungen umsetzen. Solche Interfaces gibt es aber nur wenige; zum Beispiel von IMS-Programmen zu IDMS- oder Adabas-Datenbanken.

Den "point of no return" zurückschieben!

Die bisherigen Überlegungen zeigen, daß man nicht nur auf eine möglichst portable DB- und DC-Software Wert legen sollte. Wichtig sind auch Strategien, den Grad der Abhängigkeit von der einmal ausgewählten Software möglichst gering zu halten.

Je aufwendiger eine mögliche Umstellung auf eine andere DB/DC-Software wird, desto unvertretbarer wird ein Wechsel; das heißt, man ist mit seiner Software zwangsläufig "verheiratet". Dieser Punkt, wo man nicht mehr zurückkann, ist bei einigen Produkten bereits nach einem großen Projekt, bei anderen erst nach zwei oder mehr Jahren Anwedungsentwicklung erreicht.

Strategien gegen DB/DC-Abhängigkeit

Deswegen enpfehlen wir den Teilnehmern unserer DB- und DC-Seminare durch geeignete Strategien, diesen "point of no return" möglichst weit hinauszuschieben.

Hierzu gibt es verschiedene Maßnahmen, die ich aufzeigen möchte.

1. Auslagerung von DB- und DC- spezifischen Funktionen.

Bei dieser Vorgehensweise wird die gesamte Kommunikation mit dem TP-Monitor in einem Rahmen- oder Steuerprogramm - es gibt unterschiedliche programmtechnische Realisierungsmöglichkeiten - zusammengefaßt. Die Anwendungsprogramme übernehmen nur noch die problemorientierte Verarbeitung und enthalten somit keinen TP-Befehl. Generalisierbare Funktionen (zum Beispiel An- und Abmeldung, Berechtigungsprüfung, Menüsteuerung, Hilfe-Funktion, Hardcopy etc.) ergänzen das Steuerprogramm (siehe dazu Abbildung 2). Dies entspricht etwa dem CIS-Konzept, das IBM verkauft.

Anwender, die diesen Weg beschnitten haben, können von Umstellungen größerer TP-Systeme (über 100 Programme) zu vertretbaren Kosten berichten.

Auf der DB-Seite ist ein solches zentrales Zugriffsprogramm wesentlich schwieriger zu erstellen. Deswegen empfehle ich hier mehrere spezifische Zugriffsmoduln (zum Beispiel für Zugriff auf Kunden, für Aufträge eines Kunden und andere). Damit sind die notfalls umzuschreibenden Progammteile eindeutig identifiziert.

2. DB- und DC-neutrale Programmierung

Bei der Vorgehensweise werden nicht der TP-Monitor oder das DBMS direkt angesprochen, sondern ein Interface, das diesen Aufruf in die spezifischen Befehle umwandelt. Viele große Unternehmen wie zum Beispiel Philips, SKF und andere arbeiten über diese Technik.

Allerdings kostet es etwas Gehirnschmalz und viel Arbeit, ein solches generalisiertes Interface selbst herzustellen. Was sich Großunternehmen leisten können, ist recht für jedes Unternehmen empfehlenswert. Deswegen ist es sinnvoll, standardisierte Schnittstellenprogramme zu verwenden, wie man sie mit KDBS und KDCS findet.

Probleme bleiben bei diesen "K-Schnittstellen" allerdings trotzdem. Obzwar die TP-Monitore alle etwa gleichartige Funktionen haben, die sich mit neutralen KDCS-Befehlen ansprechen lassen, gibt es Unverträglichkeiten. So ist zum Beispiel die KDCS-Schnittstelle im UTM um inkompatible - aber sinnvolle - Funktionen erweitert worden.

Auf der DB-Seite ist es noch problematischer. Zwar lassen sich einzelne KDBS-Befehle in Entsprechende Befehle eines beliebigen DBMS umwandeln, doch die Programmlogik orientiert sich an der Datenbankstruktur. Damit muß eine andere Datenbank die Struktur der ursprünglichen nachahmen, wobei man auf die möglichen Vorteile dieses BDMS verzichten muß. Das heißt, wenn man zum Beispiel ein KDBS-Programm für eine IMS-Datenbank geschrieben hat, so muß diese Struktur auch bei einem Wechsel auf Adabas 1 : 1 abgebildet werden.

Ein weiterer Ansatz in dieser Richtung ist die Verwendung von neuen Hochsprachen (wie zum Beispiel Natural Mantis), die weitgehend unabhängig vom eingesetzten TP-Monitor sind. So ist zum Beispiel Natural unter acht verschiedenen TP-Monitoren ablauffähig, ohne daß an den Programmen auch nur ein Befehl geändert werden muß.

Wird fortgesetzt