Die Ankündigung des lang erwarteten IBM Repository steht unmittelbar bevor. Über die Vorteile des Repository sind zwar seit einiger Zeit Spekulationen im Umlauf, aber eine revolutionäre Lösung darf nach Meinung von Ernst H. Kelting* niemand erwarten. Für den Autor geht das Repository vielmehr auf den Erfahrungen mit Datenkatalogen, Data Dictionaries oder Directories auf.
Als ich 1966 meine Laufbahn in der Datenverarbeitung begann, konnte ich bei einem Versicherungsunternehmen den Aufbau eines Datenkataloges mitverfolgen. Der Katalog war eine Loseblattsammlung, pro Datenelement wurde eine Seite angelegt. Ich erinnere mich noch gut, wie damals ein Mitarbeiter erschöpft aus einer Sitzung kam und meinte: "Jetzt haben wir schon drei Tage über die Policennummer gesprochen und haben immer noch keine exakte Definition. Die Probleme, ein Datensegment sauber zu definieren, haben sich seitdem nicht geändert.
Anfangs nur für Dateibeschreibungen
Der Datenkatalog war damals eben ein Buch, in dem man nachschlagen könnte, wenn man ein Feld suchte. Da die Indexmöglichkeiten natürlich nur begrenzt waren, konnten Doppeldefinitionen einfach nicht vermieden werden, insbesondere auch, weil man Datenanalysemethoden noch nicht kannte. Das relationale Modell, das die Basis für Datenanalysemethoden heute ist, wurde in den Tagen gerade erst veröffentlicht. Der Datenkatalog war damit dann meist nur Eingabe für das Erstellen von Dateibeschreibungen (sogenannte Copy-Member), die dann von allen Programmen verwendet werden konnten.
Die nächste Entwicklungsstufe kam dann etwa 1975. Es erschienen die ersten Produkte auf dem Markt, die eine maschinelle Verwaltung des Datenkataloges erlaubten. In der ersten Form erlaubten diese Programme im wesentlichen, eine Programm-Datei/DB- Feldverknüpfung herzustellen. Die angebotenen Produkte konnte man aber damals schon in zwei Gruppen unterteilen, nämlich die zur Unterstützung der Datenbankadministration (zum Beispiel IMS/DD, Predict, IDMS-IDD) oder solche, die datenbankunabhängig und stärker auf die Unterstützung weiterer Teile des Software-Entwicklungsprozesses ausgerichtet waren (zum Beispiel Byblos, Data Catalogue, Datamanager, Lexicon).
Die Struktur der datenbankabhängigen Dictionaries war ausgelegt auf die Objekte, die für die spezielle Unterstützung dieser Datenbank notwendig waren. Die andere Gruppe der datenbankunabhängigen Data-Dictionaries unterstützte zwar häufig auch die Generierung von Datenbankdefinitionen, dies war jedoch nur eine Teilfunktion. Diese Systeme soweit sie überlebt haben, wurden so weiterentwickelt, daß sie auch frühere Phasen in der Systementwicklung unterstützen konnten. Damit bestand nicht nur die Möglichkeit, Informationen des gesamten Systementwicklungsprozesses abzuspeichern, sondern auch maschinell Prüfungen durchzuführen. So kamen zum Beispiel zu Beginn der 80er Jahre Produkte auf den Markt, die maschinell die Datenanalyse unterstützten (Data-Designer, Designmanager), und automatisch stabile Datenstrukturen generierten.
Aus dieser Zeit stammen aber auch die Anforderungen, die bei IBM zur Entwicklung eines Repository geführt haben. Hierbei muß man sehen, daß des jetzt angekündigte Produkt mindestens die dritte Version ist, die innerhalb der IBM entwickelt wurde. Die erste Entwicklungsstufe wurde dabei im wesentlichen von technischen Anforderungen bestimmt. Statt nur die Datenbankdefinitionen zu generieren, sollte dieses System in der Lage sein, die gesamte Systemgenerierung inklusive Netzwerkbeschreibungen zu verwalten Die Entwicklungsaufgabe lag deshalb auch bei der Betriebssystementwicklung innerhalb IBMs.
Nachdem man wohl intern die Fehlplazierung der Entwicklung des Repository erkannt hatte, wurden die Entwicklungsaktivitäten zur Datenbankseite hin verschoben. Die Anforderungen an das Repository wurden erweitert, und eine neue Entwicklung begann. Nur glaubte man intern damals wohl nicht, jeden Kunden auch zwangsweise ein Datenbanksystem als Voraussetzung für ein Repository vorschreiben zu können und so wurde diese Entwicklung weiter auf der Idee einer VSAM-Datenhaltung vorangetrieben. Es zeigte sich aber, daß man hier eine der komplexesten Datenbanken eines Unternehmens aufbauen wird und gerade deshalb ein starkes Datenbanksystem als Basis verfügbar sein muß.
Inzwischen hatte auch DB2 eine größere Akzeptanz gefunden und die Entwicklung wurde deshalb wieder aufgenommen. Hierbei wurden dann auch stärker die von der logischen Systemspezifikation kommenden Anforderungen mit berücksichtigt. So veröffentlichte eine Arbeitsgruppe des amerikanischen "Guides" im September 1986 ihr "Repository Data Model Strategy Paper" in dem aus dem Anwenderkreis die Anforderungen an ein Repository detailliert dargelegt wurden.
Ein weiterer Einflußfaktor war sicherlich auch die Aktivität des amerikanischen Normenausschusses, der Ende letzten Jahres den ANSI/IRDS (Information Ressource Dictionary System)-Standard verabschiedet hat. Sowohl der Guide-Vorschlag als auch der ANSI/IRDS-Standard basieren auf einem Entity-Relationship Datenmodell und bereiteten damit Schwierigkeiten bei der Implementierung auf Basis einer relationalen Datenbank. Im heute verfügbaren SQL-Standard gibt es keine rekursiven Abfragen, um zum Beispiel alle von einem Programm benutzten Felder zu finden. Vielmehr müssen über die verschiedenen Beziehungen und Ebenen, wie zum Beispiel Programm - Datenbank - Segment - Gruppe -Feld, jeweils spezielle SQL-Abfragen gestartet werden. So wird denn auch allgemein erwartet, daß nicht der SQL-Zugriff auf das Repository der normale Weg sein wird, um Informationen abzurufen sondern daß über dem Repository eine Serviceschnittstelle auf Basis eines Entity-Attribut-Relationship-Modells liegt.
Die letzte Entwicklungsänderung kam sicherlich, als IBM das SAA-Konzept ankündigte und das Repository jetzt natürlich den SAA-Ansprüchen gerecht werden mußte. Was erwartet man denn überhaupt von einem Repository? Schauen wir in ein Wörterbuch, so wird das Repository dort als "Lager", "Magazin", "Quelle" oder "Fundgrube" beschrieben. Wie in der Abbildung gezeigt, liegt das Repository dabei über dem Datenbankmanagement, aber vor den Werkzeugen und dem im Repository abgebildeten Datenmodell.
Das Repository ist somit nichts anderes als eine Ablage von Objekten. Das Datenmodell ist die Beschreibung dieser Objekte und zusätzlicher Regeln, welche die zwischen diesen Objekten bestehenden Beziehungen beschreiben. Es soll eine Fundgrube sein für Werkzeuge, die Informationen benötigen. Fast jedes Softwareprodukt, sei es eine 4GL-Sprache oder eine Buchhaltungsanwendung, wird heute mit einem eigenen Dictionary ausgeliefert. Keines dieser Dictionaries kann ohne große Schwierigkeiten mit dem anderen verbunden werden.
Vielleicht bekommen wir mit dem Repository eine Basis für eine standardisierte Abspeicherung und Bereitstellung von Dictionary-Informationen. Es gab zwar schon in der Vergangenheit für spezielle Phasen der Systementwicklung funktionierende Werkzeuge; ihre Integration war aber wegen der unterschiedlichen Datenmodelle und Datenhaltung nur sehr schwer möglich. Mit dem Repository wird vielleicht zum ersten Mal eine Standardschnittstelle zu einer integrierten Datenbasis geschaffen, die das Abspeichern redundanter Informationen nicht mehr notwendig macht.
In Zukunft wird die Anwendungssystementwicklung sicherlich durch grafische Workstations unterstützt werden. Die hierbei gewonnenen Informationen müssen unternehmensweit zusammengeführt werden. Gerade der Einsatz von CASE scheitert heutzutage häufig daran, daß im allgemeinen für jeden PC oder über ein Netzwerk für ein Projekt eine separate Datenhaltung erfolgt. Eine Zusammenführung der Daten aus den
verschiedenen Projekten ist meist schon aufgrund der Struktur der gespeicherten Daten überhaupt nicht möglich. Dies mag der Grund dafür sein, daß CASE-Anbieter in Amerika, wo mehr projektorientiert gearbeitet wird, sehr viel erfolgreicher waren als in Europa, wo eine Integration aller Anwendungen schon immer einen etwas höheren Stellenwert hatte.
Dieser Unterschied war in der Vergangenheit schon beim Dictionary-Einsatz zu bemerken. Während in Europa im allgemeinen ein Dictionary unternehmensweit eingesetzt worden ist, verwendet man in den USA häufig pro Projekt ein eigenes Data-Dictionary. Die Einsatzmöglichkeiten des Repository werden also auch sehr stark dadurch bestimmt werden, wie stark dieses Repository mit anderen verteilten Repositories zusammenarbeiten und Informationen kontrolliert zusammenführen kann. Nur dann wird es im Rahmen von CASE erfolgreich eingesetzt werden können. Ein nur auf DB2 und da mit auf den Großrechner beschränktes Repository würde einem Unternehmen heute, außer daß es vielleicht eine IBM Standardschnittstelle besitzt, keine Vorteile gegenüber den heute verfügbaren Dictionaries geben, sondern es dürfte funktional sogar viel schwächer sein.
Ob das Repository ein Erfolg wird, liegt also nicht an der Mächtigkeit des Repositories, sondern an der Mächtigkeit der Werkzeuge, die in Zukunft die Daten aus dem Repository verarbeiten können. Nur wenn Anbieter ihre Softwareprodukte auf das Repository umstellen, können Aktivitäten wie Systemdesign, Programmgenerierung und Testen vereinfacht werden. Sicherlich entsteht durch die Ankündigung des Repository für viele Software-Anbieter ein Zwang, ihre Produkte umzustellen.
Gleichzeitig wird man auch sehen müssen, für welche Bereiche die IBM selbst bereit ist, ihre Produkte dem Repository anzupassen. Wird also zum Beispiel in Zukunft ein Compiler direkt auf das Repository zugreifen (und damit das Repository in einen aktiven Status bringen), oder werden weiterhin Informationen aus dem Repository in eine Zwischendatei kopiert werden müssen, auf die dann der Compiler zugreift?
Überhaupt wird es interessant sein, zu prüfen, in wieweit logische Informationen mit physischen Informationen im Repository gemischt werden können. Kann zum Beispiel die verteilte Kundendatenbank, die in der Zentrale des Unternehmens auf DB2 läuft, an
dezentralen Orten unter SQL/DS und im Ausland vielleicht auf Basis des OS/2 Databasemanagers so im Repository beschrieben werden, daß die verschiedenen Kataloge direkt aus dem Repository gefüllt werden können? Logisch ist es zwar immer die gleiche Datei, physisch kommen aber für die entsprechende Umgebung unterschiedliche Attribute hinzu. Nur wenn diese Möglichkeiten im Repository enthalten sind, kann es auch langfristig erfolgreich im Unternehmen eingesetzt werden.
Das Repository ist die Basis, auf die in Zukunft die Werkzeuge zugreifen und ihre Eingaben beziehen. Das bedeutet aber, daß nur bei einem gefüllten Repository die Werkzeuge erfolgreich eingesetzt werden können. Wer also schon ein Dictionary im Einsatz hatte, der wird sicherlich ohne große Schwierigkeiten das Repository füllen können. Wer aber den Einsatz eines Dictionary in der Vergangenheit hinausgeschoben hat (vielleicht macht ja das Repository die Datensammlung automatisch), der kommt auch mit dem Einsatz des Repository jetzt nicht mehr darum herum, sein Unternehmensdatenmodell aufzustellen und zum Beispiel Fragen nach der Definition der Policennummer zu beantworten. Diese Datensammlung ist sicherlich die erste Stufe für einen erfolgreichen Repositoryeinsatz.