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.

* Michael Bauer, Leiter des Bereichs DV-Beratung bei der GES-Gesellschaft für elektronische Systemforschung mbh in Allensbach, ist seit vielen Jahren mit der Anwendungspraxis von Datenbank- und Online-Systemen vertraut. Er ist Autor Zahlreicher Fachbeiträger zur DB/DC-Thematik.

Kapitel IX, Teil 1:

Rund ums Data-Dictionary

Als einen der "Kardinalfehler der Vergangenheit" hatte ich die Implementierung eines Datenbanksystems ohne ein Data-Dictionary bezeichnet (siehe Kapitel V dieser Serie). Sicherlich ist es den meisten DV-Fachleuten einsichtig, daß eine gemeinsame zentrale Datenbasis auch ein zentrales Datenverzeichnis benötigt.

Vergleicht man aber die Zahlen der installierten Data-Dictionaries mit denen der installierten Datenbanksysteme, so stellt man eine große Diskrepanz fest. Mehr als die Hälfte aller Datenbankinstallationen besitzt kein Data Dictionary. Werden die Kardinalfehler der Vergangenheit auch in der Gegenwart weiterhin begangen?

Für diese Situation gibt es zwei Erklärungen.

Grund 1:

Isolierte Anwendungen

In der Anfangsphase einer DB-Installation unterschätzt man leicht die Notwendigkeit und den Nutzen eines Data-Dictionaries. Denn die für ein Anwendungsgebiet benötigten Daten sind noch überschaubar. So lassen sich Datenanalyse, Datenbankentwurf und Erstellung der Datendefinitionen noch manuell durchführen. Das geht zuerst auch viel schneller.

Noch befinden sich viele Unternehmen in der Phase, wo sie ein DBMS erst für eine oder nur wenige Anwendungen einsetzen. Aber mit zunehmender Anzahl von Anwendungen steigt das Volumen an Daten und an Querbeziehungen, so daß eine maschinelle Verwaltung sinnvoll, ja notwendig erscheint. Und dann ärgert man sich, daß man reicht gleich von Anfang an ein richtiges Datenverzeichnis aufgebaut hat.

Grund 2:

Selbstgebastelte Data-Dictionaries

Für die DV-Abteilung ist der wichtigste Effekt eines Data Dictionaries zunächst nur die Möglichkeit der Codegenerierung; das heißt einheitliche Datendefinitionen für alle Anwendungsprogramme zu erzeugen. Diese Erfahrung wird durch eine europäische Umfrage untermauert, die unter anderem von der GMD unter Data-Dictionary-Anwendern durchgeführt wurde.

Einheitliche Datenbeschreibungen kann man aber auch mittels einer recht einfachen und billigen Methode erhalten - nämlich durch Aufbau von Copy-Membern.

Doch in der weiteren Entwicklung kommt dann der Wunsch nach einem Datenverwendungsnachweis. Aber auch hier kann man sich noch recht preiswert helfen: zum Beispiel mit einem kleinen Programm, das die Steueranweisungen (Job Control) nach verwendeten Dateien durchsucht, was allerdings nur für Batch-Anwendungen sinnvoll ist. Oder ein Programm wird in die Umwandlungsprozedur eingebunden, das das Source-Programm nach verwendeten Copy-Membern durchsucht oder die Cross-Referenzliste des Compilers verarbeitet.

Auf diese Weise entstehen eigene "selbstgestrickte" Data-Dictionaries, die für den Anfang auch ohne weiteres genügen. Doch dann stellt man fest, was man mit diesem zentralen Verzeichnis noch alles machen könnte - und damit wird es notwendig, Aufwand und Geld in eine Eigenentwicklung zu investieren, die immer teuerer, komplexen und wartungsintensiver wird.

Was kann man von einem Data-Dictionary erwarten?

Ein Data-Dictionary ist - wie bereits gesagt - ein zentraler Katalog von Definitionen von Daten und ihrer Verwendung innerhalb einer Organisation. Es konzentriert alle Informationen über Daten wie

- Name, Bedeutung, programminterne Namen und Format

- ihre Zusammenfassung zu Segmenten, Sätzen, Dateien oder Datenbanken

- die Verwendung in Auswertungen und Bildschirmmasken

- ihre Erzeugung, Änderung oder Benutzung durch Programme

- die Zusammenfassung der Programme zu Jobs, Anwendungen und Systemen.

- Berechtigungen zur Aktualisierung und Benutzung der Daten

Darüber hinaus können in einem Data-Dictionary noch eine Vielzahl weiterer Informationen abgelegt werden wie zum Beispiel

- zulässige Inhalte der Daten und Prüfalgorithmen

- Standardüberschriften und Feldnamen für DB-Sprachen

- Verteilungsalgorithmen bei Distributed Processing

- Datenbeschreibungen

- Generierungsparameter für DBMS und TP-Monitor

- Programm- und Systembeschreibungen (Dokumentation)

- Betriebsanleitungen

- Überlegungen zur Datenanalyse und zum konzeptionellen Entwurf (zum Beispiel Views, Datenkataloge)

- Daten, die außerhalb des Rechners existieren.

Ein Data-Dictionary stellt gewissermaßen eine "Datenbank der Informationen über Daten" dar. Was kann es mit diesen Informationen machen?

1. Generierung von DBMS- und Dateidefinitionen

Jedes Datenbanksystem verfügt über ein Directory, aus dem es sich zur Ausführungszeit die Beschreibungen der zu verarbeitenden Datenbank (zum Beispiel Schema und Subschema, DBD und PSB oder ähnliches) holt. Der Input für dieses Directory läßt sich aus dem Data Dictionary generieren. Ähnliches gilt auch für Dateidefinitionen (zum Beispiel Cluster-Definitionen für VSAM).

Wird fortgesetzt