Ein Data Dictionary/Directory System (DD/DS) ist das entscheidende Werkzeug zur Dokumentation und Kontrolle von betrieblichen Informatonssystemen (IS) - insbesondere solchen, die auf Datenbankbasis arbeiten. Wolfgang Zillessen* nahm 16 gängige Produkte dieser Weichware-Spezies unter die Lupe. Die Untersuchung zeigte, daß auch hier noch einiges im argen liegt: Zwar existieren durchaus leistungsfähige Systeme, die selbst hochgesteckten Ansprüchen genügen, doch konnte bei näherem Hinsehen offenbar keines der untersuchten Software-Erzeugnisse sämtliche Anforderungen vollständig erfüllen.

*Wolfgang Zillesen ist ein Systemanalytiker, Hamburg-Neu Wulmstdorf

Ein DD/DS sollte als sogenanntes Meta-Informationssystem in der Lage sein, möglichst das gesamte betriebliche Informationssystem abzubilden. Somit ist es nicht alleine ausreichend, die durch ein DBMS verwalteten Datenelemente und deren Gruppierung zu Datensegmenten, Datensätzen, Datenbankbereichen (areas) und ganzen Datenbanken als Meta-Objekte zu beschreiben, sondern das gesamte unternehmensweite Datemodell muß abgebildet werden können.

Ebenso ist es erforderlich, die automatisierten wie auch die manuellen betrieblichen Verarbeitungsabläufe (Prozesse) in ein DD/DS aufzunehmen und in einer entsprechenden Meta-Objekt-Hierarchie zu gruppieren (System, Subsystem, Programm, Modul, Transaktion) sowie die Kommunikationsstruktur einer Unternehmung sowohl auf der Ebene der Benutzer (Organisationsstruktur) als auch auf der DV-Seite (Hardware-konfiguration inklusive Benutzer-schnittstellen) zu beschrieben.

Insofern serden die 16 untersuchten DD/DS hinsichtlich notwendiger Daten-, Prozeß- und Kommunikations-Objekte analysiert und die Möglichkeiten der Hierarchiebildung innerhalb einer solchen Objekt-Kategorie sowie Verknüpfungen der Kategorien zueinander angeführt.

Neben der Fähigkeit zur Abbildung eines Infomationssystems sind schließlich noch drei weitere dokumentationsorientierte Anforderungen zu stellen. Zum einen muß das DD/DS offen für benutzerdefinierte Meta-Objekte sein, da nur so ein unternehmensspezifisches IS-Modell uwerfälscht abgebildet werden kann. Weiterhin sollte jedes Meta-Objekt möglichst unbegrenzt durch erklärende Text-Attribibute verbal beschrieben werden können und schlleßlich muß die Technik der Erfassung von DD/DS-Inhalten möglichst einfach sein, nämlich menügesteuert und ohne schwer verstän[P1]dlche Spezialbegriffe erfolgen, um die Benutzerakzeptanz nicht unnötig zu erschweren.

Komplizierte Komandosprachen und umfangreiche Referenzkarten behindern insbesondere die Arbeit desjenigen, der nicht täglich mit dem DD/DS arbeitet, auf dessen Beteiligung es aber gerade ankommt, um vollständige, konsistente und auch betriebswirtschaftlich aussagefähige DD/DS-Inhalte ze erarbeiten.

DD/DS für interne Kontrollen gut geeignet

Da aus den Meta-Daten-Objekten eines aktiven DD/DS die zur Realisierung von Datenbankzugriffen erforderlichen Schemabeschreibungen auf interner (physischer) konzeptioneller (gesamtlogischer) und externer (benutzerspezifischer) Ebene generiert werden können, lassen sich auf eben diesem Weg auch eine Reihe dokumentierter interner Kontrollen in aktiv wirksame Prüfungen für laufende Anvendungssysteme überführen. Insofern eignet sich ein DD/ DS vorzüglich zur Installatio wesentlicher Teile eines internen Kontrollsystems; vorausgesetzt, die entsprechenden Beschreibungsinhalte sind im DD/DS vorgesehen.

Schwerpunkte einer solchen Verlagerung von Kontrollen ins DD/DS bilden dabei die verschiedenen Plausibilitäts- und Zugriffskontrollen. Als Plausibilitätskontrollen, die die logische Gültigkeit von Datensatzinhalten überwachen, kommen hauptsächlich Wertebereichsangaben und Übergangsbedingungen bei der Veränderung von Datensatzinhalten in Betracht. Daneben gibt es auch die Möglichkeit sogenannter Datenstrukturkontrollen, mit deren Hilfe eine inhaltliche Entsprechung oder die Existenz bestimmter logischer Beziehungen zwischen verschiedenen Datenelementen geprüft werden kann.

Bonutzerprofile dienen als Zugriffskontrolle

Aufgrund definierter Zugriffskontrollen kann die "Nutzung" nahezu aller im DD/DS beschriebenen Meta-Objekte überwacht werden, wenn alle Programm- und Datenbankzugriffe (untergliedert zum Beispiel in lesende, verändernde und löschende Operationen) sowie Hardwareanforderungen mit DD/DS-Unterstützung erfolgen. Das geschieht entweder durch die unmittelbare Abwicklung aller Anforderungen über das (integrierte) DD/DS oder per Generierung von Job-Control-Anweisungen (JCL) aus dem (nicht-integrierten) DD/DS heraus.

Zugriffskontrollen können hierbei in Form von Benutzerprofilen definiert werden, das heißt, es existiert ein Meta-Objekt "Benutzer", welches für jede zugriffsberechtigte Person festlegt, mit welchen Transaktionen, Programmen oder Programmsystemen, Datenelementen, Dateien oder Datenbanken sowie mit welcher Hardware-Peripherie dieser arbeiten darf. Alternativ besteht auch die Möglichkeit, bei jedem einzelnen Meta-Daten-, Meta-Prozeß- oder Meta-Kommunikations-Objekt mittels sogenannter Objekt-Profile derartige Zugriffsrechte über objektspezifische Zugriffsattribute zu vereinbaren.

Eine dritte Möglichkeit, Kontrollen ins DD/DS zu verlagern, bietet schließlich die Kennzeichnung bestimmter automatisierter Verarbeitungsabläufe (Programme, Module) als logisch vollständige Transaktionen im DD/DS. Können dann aus dem DD/DS heraus die zugehörigen Transaktionsmarken generiert und an das DBMS übergeben werden, so übernimmt das DD/DS damit die Steuerung der für Recovery-/Backout-Zwecke notwendigen Protokollierung von DBMS-Operationen. Besitzt ein DD/DS neben einer DBMS- und JCL-Schnittstelle auch die Möglichkeit,Dateidefinitionen für Anwendungsprogramme zu generieren, so können auch die Inhalte konventionell organisierter Dateien, wie oben beschrieben, überwacht werden. In diesem Sinne verfügen die meisten DD/DS über eine Programmiersprachen-Schnittstelle für Cobol-Programme. Dabei müssen - mit Ausnahme des Produktes "TIS" (Cincom Systems) - Dateidefinitionen stets als Quellcode vor der Programmübersetzung generiert werden, so daß auf die Ausführung kompilierter Programme kein Einfluß mehr genommen werden kamm.

Schließlich sei noch darauf hingewiesen, daß vollständig integrierte DD/DS auch im Bereich des internen Kontrollsystems prinzipiell

zusätzliche Vorteile bieten können, weil sie derartige Kontrollen nicht nur veranlassen,

sondern selbst aktiv, prozeßbegleitend durchführen, sowie mögliche Verstöße gegen spezifizierte Gültigkeits- und Zugriffskontrollen speichern und statistisch ausw(...)ten können.

Damit das DD/DS als Meta-Informationssystem fungieren kann und die Beschreibung des betrieblichen Informationssystems über Daten-, Prozeß- und Kommunikations-Objekte nicht nur der Generierungsfunktion die Entwiçklung DV-gestützter Anwendungssysteme unterstützt, sondern auch die Aufgabenerfüllung von Revisoren, Controllern und Organisatoren qualitativ verbessert beziehungsweise vereinfacht wird, ist die bloße 1:1-Wiedergabe vòn DD/ DS-Inhalten unzureichend. Vielmehr müssen übersichtlich strukturierte Berichte, angepaßt an die unterschiedlichsten Informationsbedürfnisse, generiert werden können.

Die Festlegung von Berichtsinhalten und -strukturen darf dabei keine komplexen Sprachgebilde erfordern sondern bedingt regelmäßig eine (...) nügesteuerte Abfragetechnik, so daß bezüglich der Reportgenerierung die gleichen Anforderungen gelten wie für die Erfassung von DD/DS-Inhalten.

Im einzelnen sollten wahlweise ausführliche oder zusammenfassende Berichte über ein bestimmtes Meta-Objekt - ein Programm, ein Datenelement oder einen Benutzer - sowie Berichte über mehrere Meta-Objekte hinweg bereitgestellt werden können. Dabei muß der Berichtsumfang durch konkrete Attributwerte oder Schlüsselbegriffe als Selektionskriterium steuerbar sein, um zum Beispiel Kurzbeschreibungen aller Datenelemente, auf die ein bestimmter Benutzer zugreifen kann, anbieten oder verbale Erläuterungen zu sämtlichen Transaktionen bereitstellen zu können, die einer bestimmten Vertriebsanwendung zugeordnet sind.

Weiterhin ist die Generierung von Struktur- und Querverweislisten eine wichtige Voraussetzung für den sinnvollen Einsatz eines DD/DS. Meta-Objekt-Struktur-Listen bieten dabei eine Übersicht über die innerhalb einer Meta-Objekt-Kategorie vorhandene Objekt-Struktur (zum Beispiel als Datenmodell oder Prozeßstruktur) in Form sogenannter Verwendungsnachweise (Implosion-(...)orts, Bottom-up-Sichtweise) oder Zerlegungsübersichten (Explosion-Reports, Top-down-Betrachtung).

Querverweislisten (Cross-Reference-Reports) informieren schließlich über die definierten Querbeziehungen zwischen Meta-Objekten unterschiedlicher Objekt-Kategorien, also beispielsweise über die Zuordnung eines Benutzers zu bestimmten Datenelementen, Transaktionen Programmsystemen und Ein-/Ausgabemedien. Gerade die Aussagefähigkeit solcher Cross-Reference-Reports hängt natürlich erheblich von der im DD/DS grundsätzlich definierten Beziehungsstruktur ab.

SDLC-Unterstützung besonders wichtig

Für einen systematischen Aufbau (...)vie die kontrollierte Fortentwicklung eines datenbankgestützten Informationssystems ist es besonders wichtig, daß auch ein DD/DS die verschiedenen Phasen des Systemlebenszyklus (System Development Life Cycle, SDLC) eines solchen Informationssystems aktiv unterstützt. Dies bedeutet insbesondere, daß die schrittweise Definition eines neuen oder geänderten Systems entsprechend den verschiedenen Entwicklungsphasen (Analyse, logischer und physischer Entwurf, Implementierung, Integration, Test und Pflege) im DD/DS nachvollziehbar dokumentierbar sein muß.

Zu diesem Zweck ist eine Dokumentation unterschiedlicher Versionen desselben Meta-Objektes erforderlich, wobei allerdings die bloße Vergabe von Versionsnummern oder Statusangaben alleine nicht ausreichend ist. Vielmehr müssen derartige Versionen parallel mit gleichen Objektnamen aktiv vom DD/DS verwaltet werden.

Diese Anforderungen werden relativ selten erfüllt, obwohl doch die Beschreibung unterschiedlicher Versionen eines betrieblichen Informationssystems unter Angabe von Gültigkeitszeiträumen zur Erfüllung bestimmter gesetzlicher Aufbewahrungsvorschriften im Bereich des Rechnungswesens unbedingt erforderlich ist, um die Nachprüfbarkeit und Nachvollziehbarkeit betrieblicher Abläufe gewährleisten zu können. Neben der Verwaltung unterschiedlicher Meta-Objekt-Versionen sollte ein DD/DS darüber hinaus in der Lage sein, die Zuverlässigkeit von Objektdefinitionen und die logische Vollständigkeit der abgebildeten Meta-Objekt-Struktur beim Einfügen, Ändern oder Löschen von Objektbeschreibungen zu prüfen (Konsistenzprüfungen) sowie erforderliche Referenzkorrekturen bei anderen betroffenen Meta-Objekten selbst durchführen oder zumindest deren Notwendigkeit erkennen zü können.

Schließlich kann auch die Verfügbarkeit von Konvertierungssoftware, also die Existenz solcher DD/DS Dienstprogramme, mit deren Hilfe Datendefinitionen aus existierenden Cobol-, PL/ 1- oder Assembler Programmen sowie aus vorhandenen Datenbankbeschreibungen ins DD/ DS übertragen werden können, eine DD/DS-gestützte Entwicklung von Datenbanksystemen wesentlich vereinfachen.

Vom Optimum noch weit entfernt

Wie die Übersichttabelle zeigt, kann -wie nicht anders zu ervarten - derzeit keines der untersuchen Data Dictionaries/Directory Systeme sämtiche der formulierten Anforderungen vollständig erfüllen. Gerade die kontrollorientierten Funktionen sowie eine leistungsfähige Versionsverwaltung sind meist sehr unzureichend ausgeprägt.

Auch bieten nur maximal 50 Prozent aller DD/DS die Möglichkeit, betribliche Informationssysteme umfassend zu beschreiben, wobei der Bereich der Meta-Komunikations-Objekte sowie der Umfang verfügbarer nicht-DBMS-orientierter Atribute häufig sehr zu wünschen übrig läßt.

Andererseits existieren insbesondere im Bereich der Reportgenerierung schon sehr leistungsfähige Produkte, die auch anspruchsvollen Anforderungen genüber. Der Aussagegehalt der erzeugten Berichte ist natürlich vom umfang der zugelassenen Meta-Objekte direkt abhängig.

Kennzeichnend für das momentane Angebot scheint daneben auch die zunehmende Verfügbarkeit echt aktiver, vollständig integrierter DD/DS zu sein , die ausschließlich auf die Beschreibung eines konkreten DBMS abgestimmt sind, keiner Generierungsfunktion im herkömmlichen Sinne mehr bedürfen und daher ein Datenbanksystem stets laufend kontrollieren könen. Diese Systeme befindet sich allerdings zum Teil noch in einem lägerfristigen Entwicklungsprozeß bis hin zu vollständig ausgereiften Produkten. Sie weisen derzeit immer dann große Lücken auf, wenn eine Beschreibung des betrieblichen Informationssystems außerhalb der reinen DBMS-Umgebung gefordet ist.

Tatsache ist aber auch, daß es für Unternehmen mit mehreren Datenbanksystemen mit den

Data Dictionaries von TSI (Data Catalogue 2), MPS (Datamanager) und möglicherweise auch Una-Dat (Doku-2000) nur wenige echte Alternativen gibt. Hier ist zusätzlich noch zu berücksichtigen, daß von den Hardwarevoraussetzungen her gesehen sowieso nur IBM- und Siemens-Anwender die Möglichkeit haben, zwischen Data Dictionaries verschiedener Anbieter "auszuwählen".