DBDCDD

06.05.1983

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äge zur DB/DC-Thematik.

Kapitel IX, Teil 4:

Rund ums Data-Dictionary

Standardisierung und Dokumentation

Ein Data Dictionary fördert die Schaffung und Einhaltung von Einheitlichkeit in der Softwareentwicklung stärker als lediglich organisatorische Maßnahmen. Es entsteht quasi als "Abfallprodukt" eine aktuelle Dokumentation, die manuell vielleicht nicht nachgehalten worden wäre.

Unterstützung des Datenschutzes

Der Zusammenhang zwischen geschätzten Daten und den unterschiedlichen Berechtigungen der Benutzer läßt sich in einem Data Dictionary gut dokumentieren. Hieraus können die notwendigen Schutzmechanismen abgeleitet werden, die in einem TP-Monitor oder in einem Sicherheitssystem implementiert werden sollen.

Unterstützung der Datenorganisation

Durch die Kenntnis der Eigner von Daten (sie haben die Pflegeberechtigung und -verantwortung), der Nutzer von Daten und des Speicherungsortes der Daten läßt sich die Datenorganisation für Distributed Processing leichter und überschaubarer handhaben.

Zusammenfassend läßt sich sagen, daß der Nutzen eines Data Dictionaries abhängig ist von der Intensität seines Einsatzes. Sein Einsatzspektrum reicht von einer einfachen Definitionssammlung bis zu einem umfassenden Steuerungsinstrument. Alle seine Vorteile rühren daher, daß es die einzige verläßliche Quelle von Informationen über Daten darstellt - falls es stets aktuell gehalten wird.

Damit wären wir bei der Problemseite von Data Dictionaries angelangt.

Ein Manntag je Datenfeld

Daß der Aufbau eines gut dokumentierten Datenkataloges eine zähe und langwierige Arbeit ist, hat sich bereits herumgesprochen. Doch die Aussagen von Anwendern, daß alle Arbeiten aller Beteiligten zusammengerechnet, ein Datenfeld einen Manntag kosten soll, ist auf den ersten Blick erschreckend.

Betrachten wir einmal dazu die Arbeitsgänge. Das Erfassen der kompletten Beschreibung eines Datenfeldes und aller seiner Verwendungen in Programmen, Listen, Masken und Sätzen dauert vielleicht eine Stunde. Aber bis man dahin kommt, ist viel Vorarbeit nötig, die die meiste Zeit verbraucht: Zusammenstellen der bisherigen Daten und Dateien, Analyse der Datenfelder auf Identität und Unterschiede, Bereinigung der Datenlandschaft, Schaffung von Konventionen, genaue Beschreibung und Abgrenzung der Daten, Festlegung der Benutzerberechtigung und so weiter. Wie lange muß zum Beispiel diskutiert werden, bis der Inhalt und die Behandlung des, Feldes "Summe Auftragseingang" eindeutig definiert sind?

So gesehen ist die genannte Zahl nicht unrealistisch. Nur ist uns bisher dieser Aufwand nicht so aufgefallen, weil er als Bestandteil, der Projektarbeit nebenbei anfiel (und in jedem Projekt aufs neue anfallen wird). Doch beim Aufbau eines Data Dictionaries wird der Aufwand deutlich.

Ein mit so viel Mühe aufgebautes Data Dictionary verliert schnell seinen Wert, wenn seine Vollständigkeit und Aktualität nicht mehr gewährleistet ist. Es muß sichergestellt werden, daß alle neuen Datenfelder sofort aufgenommen werden, - die Verwendung bestehender Daten durch neue oder geänderte Programme sofort aktualisiert wird.

Es wird immer Leute geben, die in einem Data Dictionary ein Hindernis sehen, daß sie zu umgehen bemüht sind. Deshalb muß das Management in erster Linie die Notwendigkeit eines Datenverzeichnisses erkennen und seine Einführung mit der notwendigen Kompromißlosigkeit unterstützen; das heißt, es muß auch taube Ohren gegenüber Klagen von Endbenutzern und Projektleitern haben, die so kurzsichtig sind, Standards dem Arbeitstempo zu opfern.

Außer organisatorischen lassen sich auch technische Maßnahmen zur Erreichung dieses Zieles treffen. Sofern ein DBMS vorhanden ist, können neue Felder nicht willkürlich geschaffen werden, weil diese eine neue Generierung der DB-Definition voraussetzt. Das Problem liegt nur darin, undokumentierte Verwendung bestehender Felder in Programmen zu verhindern.

Hierzu lassen sich spezielle Abnahmeprüfungen bei der Übernahme von Programmen in die Produktionsprogrammbibliothek einrichten. Eine andere Möglichkeit besteht in Analyseprogrammen, die in die Umwandlungsprozedur fest eingebettet ist. Die beste Lösung allerdings bietet ein aktives Data Dictionary, daß bei der Kompilierung eines Programmes mitwirkt. (wird fortgesetzt)