Einsatz von DDDS zur Prüfung datenbankgestützter Informationssysteme:

Aktive Systeme unterstützen DV-Revision

09.11.1984

Die Existenz von Dokumentation und internem Kontrollsystem ist eine wesentliche Voraussetzung zur Prüfung betrieblicher Informationssysteme. Dabei erhöht der Einsatz von Datenbanksystemen die Dokumentations- und Kontrollanforderungen erheblich: Zum einen wächst der Komplexitätsgrad der Anwendungen. zum anderen verwischen die Grenzen der einzelnen Funktionsbereiche in einem Unternehmen. Data-Dictionary/Directory-Systeme, so Dr. Wolfgang Zillessen vom Lehrstuhl Betriebswirtschaftslehre V der Universität Bayreuth, können hier ein wichtiges Hilfsmittel sein.

Ein Data-Dictionary/Directory-System (DD/DS) läßt sich bei wörtlicher Übersetzung dieses Begriffes als ein System zur Verwaltung eines kombinierten Datenwörter- und Datenadreßbuches beschreiben. Beim Einsatz von Datenbanksystemen (DBS) sollte ein DD/DS also zum einen vollständige Beschreibungen über die in einer Datenbank befindlichen Daten sowie deren logischer Strukturierung und zum anderen Informationen über die physische Repräsentation dieser Daten auf den jeweiligen Speichermedien bereitstellen. Bezogen auf die DBS-Architektur der ANSI/X3/-SPARC-Study Group müßte ein DD/DS damit sämtliche Schemata zur Beschreibung von interner (physischer), konzeptioneller (gesamtlogischer) und externer (benutzerspezifischer) Datensicht beinhalten.

Die verschiedenen in der Literatur diskutierten Data-Dictionary/Directory-Systeme lassen sich durch die drei Kriterienpaare "abhängig/unabhängig", "aktiv/passiv" und "integriert/nicht-integriert" in entsprechende Klassen einteilen.

Während ein DD/DS als abhängig angesehen wird, wenn die Funktionen zur Verwaltung der Meta-Datenbank von einem bestimmten Datenbankmanagementsystem (DBMS) übernommen werden, verfügt ein unabhängiges DD/DS über eigene Management-Software und stellt zumeist Schnittstellen zu Datenbanksystemen verschiedener Hersteller zur Verfügung.

Als aktiv wird ein DD/DS immer dann bezeichnet, wenn dessen Meta-Datenbank die einzige mögliche Quelle ist, damit Datenbankmanagementsysteme jene Schema-Informationen erhalten, die sie benötigen um von einem Benutzer initialisierte Datenbankzugriffe auf die Ebene der physischen Speicherung transformieren zu können. Sollen dann zum Beispiel bestimmte Datensatzbeschreibungen geändert werden, so bedarf es zuerst einer entsprechenden Modifikation im DD/DS, damit diese für künftige Datenbankzugriffe per DBMS wirksam werden.

Im Gegensatz dazu stehen die Inhalte passiver DD/DS in keinem zwingenden Zusammenhang mit den Schemabeschreibungen eines Datenbanksystems; Änderungen von Meta-Daten müssen mehrfach durchgeführt werden. Damit entsteht bei passiven DD/DS, die zumeist nur als "Nachdokumentationssysteme" mit begrenztem Funktionenumfang eingesetzt werden, schnell die Gefahr einer inkonsistenten Meta-Daten-Haltung.

Schließlich lassen sich Data-Dictionary/Directory-Systeme durch ein drittes Kriterienpaar danach klassifizieren, ob sie zusammen mit einem oder mehreren Datenbankmanagementsystemen eine gemeinsame Meta-Datenbasis besitzen (integriertes DD/DS) oder ob DBMS und DD/DS jeweils über eine gesonderte Meta-Datenbank verfügen (nicht-integriertes DD/DS).

DD/DS soll Meta-Daten abbilden

Damit ein DD/DS möglichst intensiv für Prüfungszwecke eingesetzt werden kann, sollte es in der Lage sein, die Elemente eines datenbankgestützten Informationssystems und die auf dem Austausch von Daten basierenden Beziehungen zwischen diesen Elementen als sogenannte Meta-Objekte abzubilden. Die entsprechenden Meta-Daten zur Beschreibung dieser Objekte sollten in einer Datenbank gespeichert werden, damit diese Informationen für die unterschiedlichsten Personenkreise und Funktionen genutzt werden können.

Aus Revisionssicht heraus ist es dabei nicht nur wichtig, so elementare Meta-Objekte wie "Transaktionen" und "Datenelemente" in einer Meta-Datenbank zu beschreiben, sondern derartige Objekte sollten zu weiteren hierarchisch übergeordneten Objekten aggregiert werden, um einem Prüfer einen sukzessive detaillierbaren Einblick in ihm noch unbekannte Bereiche eines datenbankgestützten Informationssystems auf einfache Weise zu ermöglichen.

Generierung von Datendefinitionen

Der wesentliche Vorzug eines aktiven DD/DS besteht darin, daß die in der Meta-Datenbank gespeicherten Datendefinitionen zur Generierung von Datenbank-Schemata genutzt werden können, so daß zumindest aus theoretischer Sicht heraus stets von einer Identität zwischen dokumentierten und tatsächlich zur Transformation von Datenbankzugriffen verwendeten Datendefinitionen ausgegangen werden kann. Ist darüber hinaus ein DD/DS nicht in ein bestimmtes Datenbankmanagementsystem integriert, das heißt, verfügen DD/DS und DBMS über eine gesonderte Meta-Datenbank, so können vom DD/DS auch Datendefinitionen für Anwendungsprogramme - zum Beispiel Cobol File-Sections - generiert werden, wenn vom jeweiligen DD/DS-Hersteller entsprechende Prozeduren angeboten werden. Integrierte Systeme verfügen zumeist nicht über eine Programmiersprachenschnittstelle .

Für die Anbindung solcher Datendefinitionen an ein Anwendungsprogramm gibt es grundsätzlich drei Alternativen. Die einfachste und derzeit mit einer Ausnahme einzig praktisch verfügbare Möglichkeit besteht darin, die in einer bestimmten Programmiersprache generierten Datendefinitionen vor der Programmübersetzung an das jeweilige Quellprogramm anzubinden; komplizierter ist es bereits, diese Definitionen nach der Compilierung, aber vor der Ausführung mit dem bereits übersetzten Programm zu verknüpfen. Eine dritte Alternative sieht schließlich vor, die Datendefinitionen erst während der Ausführung laufend einzubinden, so daß auch noch während der Programmausführung zentral in der Meta-Datenbank durchgeführte Veränderungen berücksichtigt werden können.

Wird schließlich ein unabhängiges DD/DS eingesetzt, so ist dieses regelmäßig auch in der Lage, Datenbankmanagementsysteme verschiedenster Hersteller mit Meta-Daten zentral zu versorgen.

Aus Revisionssicht ergibt sich nun als wichtigste Konsequenz aus einer derartigen Meta-Daten-Generierung, daß ein entsprechendes DD/DS zur Zentralisierung zahlreicher automatisierbarer interner Kontrollen genutzt werden kann; dabei können sowohl Datenbank- als auch Dateizugriffe überwacht werden. Im einzelnen bietet sich eine Verlagerung folgender Kontrollen in den Bereich eines Data-Dictionary/Directory-Systems an:

Zugriffskontrollen

Sämtliche Zugriffe auf Datensatzinhalte sowie die Berechtigungen zur Ausführung von Programmen können zentral per DD/DS kontrolliert werden, wenn alle Programm- oder Datenanforderungen über ein DD/DS abgewickelt werden und in der Meta-Datenbank entsprechende Kontroll-Attribute verfügbar sind. Dabei können entweder Benutzerprofile angelegt werden, das heißt, beim Meta-Objekt "Benutzer" wird für jede einzelne Person festgelegt, auf welche Programme, Subsysteme oder vollständige Systeme sowie auf welche Datenelemente, Datensegmente, Datensätze, Datenbanken oder Datenbankbereiche diese zugreifen und welche Bildschirmmasken, Druckformate oder Hardwarekomponenten diese einsetzen darf; oder es werden Objektprofile definiert, das heißt, bei den einzelnen Meta-Objekten der verschiedenen Objektkategorien werden derartige Zugriffsrechte durch objektspezifische Zugriffs-Attribute vereinbart.

Plausibilitätskontrollen

Durch die Festlegung von Gültigkeitsbedingungen auf der Ebene der Meta-Objekte "Datensatz", "Datensegment" oder "Datenelement" kann per DD/DS zentral die Plausibilität von Datensatzinhalten geprüft werden. Neben den bereits in jeder Datensatzdefinition enthaltenen Datentyp- und Formatangaben kommt dabei vor allem der Festlegung von Wertebereichen, der Beschreibung von Übergangsbedingungen bei der Veränderung von Datensatzinhalten sowie der Definition von Datenstrukturkontrollen, mit deren Hilfe die Existenz bestimmter Beziehungen zwischen Datensatzinhalten geprüft wird, eine große Bedeutung zu. Derartige Gültigkeitsbedingungen werden dann bei der Generierung von Meta-Daten an das jeweilige DBMS oder an ein auszuführendes Anwendungsprogramm gemeinsam mit den erzeugten Datendefinitionen weitergegeben.

Transaktionskontrollen

Eine dritte Möglichkeit, Kontrollen ins DD/DS zu verlagern, besteht schließlich in der Kennzeichnung bestimmter Meta-Prozeß-Objekte als logisch vollständige Transaktionen durch entsprechende Attribute. Bei jedem von einem DBMS übermittelten Datenbankzugriff werden dann vom DD/DS die zugehörigen Transaktionsmarken an das DBMS übergeben, welches für eine Recoveryorientierte Protokollierung sowie für die Durchführung von Serialisierungskontrollen weiterhin verantwortlich bleibt.

Kontrolle der Meta-Datenbank

Schließlich können nicht nur Zugriffe auf Dateien und Datenbanken sondern auch lesende und ändernde Operationen mit dem Inhalt der Meta-Datenbank selbst durch ein DD/DS überwacht werden. Zu diesem Zweck müssen bei jedem einzelnen Meta-Objekt verantwortliche Benutzer festgelegt und deren Autorisierung bei jedem Zugriff auf die Meta-Datenbankinhalte des DD/DS geprüft werden.

Manuelle Techniken greifen nicht mehr

Gerade beim Einsatz datenbankgestützter Informationssysteme werden an die jeweilige EDV-Abteilung hohe Anforderungen hinsichtlich einer Dokumentation solcher Systeme gestellt, die mit rein manuellen Techniken kaum mehr erfüllbar sind; Umfragen zeigen, daß insbesondere die Vollständigkeit und Aktualität derartiger Systemdokumentationen in der Praxis erheblich zu wünschen übrig läßt. Auf eine umfassende Systemdokumentation sind jedoch nicht nur Systemanalytiker, Programmierer und regelmäßige Endbenutzer, sondern vor allem auch Revisoren dringend angewiesen.

Ein DD/DS bietet hier ein sehr wirkungsvolles Hilfsmittel zur Bereitstellung einer solchen Dokumentation, wenn dieses möglichst vollständig die Meta-Objekt-Struktur eines datenbankgestützten Informationssystems mit Hilfe eines umfangreichen Kataloges von Attributen abbilden und zusätzlich Texte zur verbalen Beschreibung von Meta-Objekten verarbeiten kann. Der Einsatz eines aktiven, nicht-integrierten DD/DS bietet dabei nicht nur den Vorteil der zwangsläufigen Identität von Dokumentation und täglichem Routinebetrieb, sondern auch die Möglichkeit, außerhalb des Datenbanksystems angesiedelte automatisierte Verarbeitungsabläufe in eine solche Dokumentation einzubeziehen.

Die Management-Software eines DD/DS sollte neben der Verwaltung das heißt Erfassung, Änderung, Löschung und Ausgabe von Meta-Daten, grundsätzlich Prozeduren zur Verfügung stellen, die beim Einfügen oder Andern von Meta-Objekten die Zulässigkeit von Objektnamen und Objektdefinitionen prüfen und die auf die Notwendigkeit von Referenzkorrekturen bei anderen Meta-Objekten aufmerksam machen, wenn sie diese nicht sogar unmittelbar selbst durchführen.

Schließlich ist es zur Unterstützung des Prozesses der Entwicklung datenbankgestützter Informationssysteme sowie zur Erfüllung bestimmter gesetzlicher Aufbewahrungspflichten im Bereich des Rechnungswesens erforderlich, daß ein DD/DS unterschiedliche Versionen ein und desselben Meta-Objektes möglichst mit Angabe von Gültigkeitszeiträumen, Versionsnummern oder der relevanten Phase des Systementwicklungsprozesses verarbeiten kann.

Eine per DD/DS verwaltete computergestützte Dokumentation ist aus Revisionssicht allerdings nur dann vielfältig einsetzbar, wenn mit einer einfach erlernbaren Abfragesprache oder mit menügesteuerten Bildschirmmasken die Möglichkeit besteht, aus der Meta-Datenbank entsprechend den unterschiedlichsten Informationsbedürfnissen Daten zu selektieren und diese mittels Report-Generator in Form von übersichtlich strukturierten Berichten aufzubereiten. Dabei sollten nicht nur vollständige Berichte über einzelne Meta-Objekte bereitgestellt werden, sondern der Berichtsumfang sollte durch Angabe konkreter Attributwerte als Selektionskriterium über mehrere oder alle Meta-Objekte hinweg gesteuert werden können.

Weiterhin ist die Generierung von Meta-Objekt-Struktur-Listen sinnvoll, sie bieten eine Übersicht über die innerhalb einer Objektkategorie vorhandene Beziehungsstruktur und informieren zum Beispiel darüber, welchen Datensegmenten, Datensätzen, Datenbankbereichen und Datenbanken ein bestimmtes Datenelement zugeordnet ist. Über die Querbeziehungen zwischen Meta-Objekten unterschiedlicher Objektkategorien sollten schließlich Querverweislisten (Cross-Reference-Reports) Auskunft geben. Zusätzlich bieten einige Softwarepakete spezielle Berichte über die implementierten Zugriffssicherungen .

In einer 1984 an der Universität Bayreuth durchgeführten Untersuchung über die Verfügbarkeit aktiver Data-Dictionary/Directory-Systeme sollte festgestellt werden, inwieweit die derzeit am Markt angebotenen Softwareprodukte bereits in der Lage sind, insbesondere durch eine aktuelle, übersichtliche und aussagefähige Dokumentation sowie durch ein zentralisiertes auf DD/DS-Basis arbeitendes Internes Kontrollsystem ein entscheidendes Werkzeug zur Prüfung datenbankgestützter Informationssysteme bereitzustellen.

Zu diesem Zweck wurden insgesamt fünfzehn verschiedene, in der Bundesrepublik Deutschland angebotene, aktive Data-Dictionary/Directory-Systeme untersucht, um erkennen zu können, welche der in Abschnitt IV als theoretisch möglich beschriebenen Funktionen diese derzeit bereits zur Verfügung stellen. Die Ergebnisse dieser Untersuchung sind im folgenden zusammengefaßt.

Meta-Daten-Generierung

Hardwarevoraussetzungen: 9 Produkte sind auf der Hardware des jeweiligen DD/DS-Anbieters oder nur auf IBM-Anlagen lauffähig; 6 Produkte können neben IBM- auch auf Siemens-, Nixdorf-, Honeywell-Bull- oder Sperry-Anlagen eingesetzt werden. Nur für IBM- mit 9 und Siemens-Benutzer mit 4 Produkten existiert ein relativ breites Angebot.

Datenbankschnittstelle: 12 Produkte sind abhängige DD/DS und besitzen nur zu einem bestimmten DBMS eine aktive Schnittstelle; das Produkt DOKU-2000 (UNA-DAT) kann zwei Siemens-Datenbanksysteme, Data Catalogue 2 (TSI) und Datamanager (MSP) können nahezu alle bekannten Systeme aktiv unterstützen.

Art und Weise der Generierung: Während 11 Produkte vollständige Schemata explizit über eine bestimmte DD/DS-Prozedur generieren, verfügen 3 Produkte über eine gemeinsame Datenbasis mit dem entsprechenden DBMS (vollständig integriert); das DD/DS TIS (Cincom Systems) kann schließlich einzig als ständig aktives, nicht-integriertes Produkt angesehen werden

Programmiersprachenschnittstelle: 13 Produkte können Datendefinitionen für Anwendungsprogramme generieren, wobei alle 13 Schnittstellen zu Cobol-, 9 zu PL/1 -, 8 zu Assembler-, 2 zu Fortran- und ein Produkt zu C-Programmen besitzen.

Art und Weise der Generierung: Wiederum mit Ausnahme des Produktes TIS, welches während der Programmausführung aktiv ist, generieren alle anderen 12 DD/DS Source-Code vor der Programmübersetzung.

Reportgenerierung

Auswertungstechnik: 10 der untersuchten DD/DS ermöglichen dialoggesteuerte Abfragen, unterstützt durch Menütechnik und Bildschirmmasken. Bei 2 Produkten sind Auswertungen durch eine einfache nicht-prozedurale Abfragesprache generierbar, während 3 DD/DS mit einer relativ komplizierten Kommandosprache arbeiten.

Meta-Objekt-Berichte: Mit zwei Ausnahmen sind bei sämtlichen Produkten ausführliche und zusammenfassende Berichte über einzelne Meta-Objekte generierbar.

Meta-Attribut-Berichte: Bei 5 DD/ DS kann die Meta-Datenbank vollständig nach sämtlichen Attributwerten durchsucht werden (zum Beispiel mit Which- oder Wher-Klauseln), bei 3 weiteren Produkten ist zumindest ein Durchsuchen von Begriffskatalogen nach identischen Beschreibungsinhalten möglich.

Meta-Objekt-Struktur-Berichte: Bei 6 Produkten können hierarchische Strukturen innerhalb einer Meta-Objekt-Kategorie als Verwendungsnachweis (Implosion Report) beziehungsweise Zerlegungsübersicht (Explosion Report) ausgehend von einem bestimmten Meta-Objekt vollständig wiedergegeben werden; bei 5 DD/DS sind nur unvollständige Hierarchien zumeist im Bereich der Meta-Daten-Objekte bei 4 Produkten überhaupt keine Strukturen generierbar.

Cross-Reference-Berichte: Querbeziehungen zwischen den verschiedenen Meta-Objekt-Kategorien, etwa zur Darstellung der in Abb. 3 wiedergegebenen Struktur, können in einem aussagefähigen Umfang von 5 Produkten bereitgestellt werden; 7 weitere DD/DS generieren zwar auch sogenannte Cross-Reference-Reports, ihre Verwertbarkeit ist jedoch wegen des zugrunde liegenden geringen Meta-Objekt-Umfanges oder der begrenzten Beziehungsstruktur erheblich eingeschränkt.

Derzeit gibt es noch kein Data-Dictionary/Directory-System, welches für sämtliche der beschriebenen prüfungsbezogenen Einsatzmöglichkeiten entsprechende Funktionen bereitstellt. Dies mag auch die noch relativ geringe Verbreitung solcher Systeme in der betrieblichen Praxis erklären.

Insbesondere im Bereich der Meta-Kommunikations-Objekte, der zur Installation eines Internen Kontrollsystems auf DD/DS-Basis benötigten Meta-Attribute sowie auf den Gebieten Versionenverwaltung, Referenzdefinition und Konsistenzprüfung existieren noch durchgehend für fast sämtliche Produkte erhebliche Lücken, während es im Bereich der Reportgenerierung schon sehr leistungsfähige Data-Dictionary/Directory-Systeme gibt. Kennzeichnend für das momentane Angebot ist weiterhin, daß mit Ausnahme des Produktes "TIS" sowie einiger vollständig integrierter DD/DS alle übrigen Softwarepakete einer expliziten und vollständigen Generierung von Datenbank-Schemata sowie programmbezogenen Dateidefinitionen bedürfen und daher weder auf spätere Datenbankzugriffe, noch auf die eigentliche Programmausführung aktuell einen direkten Einfluß nehmen können.

Abschließend sei noch darauf hingewiesen, daß die meisten der zur Zeit verfügbaren DD/DS abhängige Produkte sind und es nur genau zwei Anbieter gibt, die Schnittstellen zu zahlreichen bekannten Datenbankmanagementsystemen zur Verfügung stellen. Dabei existiert im Bereich der abhängigen DD/DS nur für IBM- und Siemens-Anwender eine gewisse Auswahlmöglichkeit hinsichtlich der Installation eines derartigen Produktes; alle Unternehmungen mit einer anderen Hardwarekonfiguration können in der Regel nur auf ein bestimmtes DD/DS zurückgreifen.

DD/DS-gestütztes Internes Kontrollsystem

Zugriffskontrollen: Bei 12 Produkten kann für Datenbankinhalte mit unterschiedlichen Mechanismen wie Paßworten oder Security Codes ein Zugriffsschutz im DD/DS zum Teil bis auf Datenelement-Ebene definiert werden.

Plausibilitätskontrollen: Bei 5 Produkten können Gültigkeitsbedingungen auf Element-Ebene festgelegt werden; bei 2 DD/DS hat diese Festlegung jedoch nur dokumentierenden Charakter.

Transaktionskontrollen: Bei 2 Produkten können logisch vollständige Transaktionen per DD/DS definiert werden.

Schutz der Meta-Datenbank: Mit Ausnahme von 2 Produkten ist ansonsten stets ein DD/DS-gestützter Zugriffsschutz für die Meta-Datenbank möglich; dieser Schutz reicht von einem einzigen "Master Password" für sämtliche DD/DS-Operationen bis zu einer auf einzelne Meta-Objekte und DD/DS-Operationen ausgerichteten Zugriffskontrolle

Meta-Objekt-Dokumentation

Meta-Prozeß-Objekte: Während 1 DD/DS überhaupt keine und 4 Produkte nur ein Prozeß-Objekt (Programm oder Procedure) zur Verfügung stellen, ermöglichen die übrigen DD/DS die Abbildung einer auf mindestens 3 Prozeß-Objekten aufbauenden Hierarchie automatisierter Verarbeitungsprozeduren.

Meta-Daten-Objekte: Der Umfang der verfügbaren Daten-Objekte kann mit zwei Ausnahmen bei allen DD/DS als ausreichend zur Abbildung des betrieblichen Datenmodells beurteilt werden; im einzelnen korrelieren Anzahl und Bezeichnung von Daten-Objekten eng mit dem jeweils unterstützten DBMS.

Meta-Kommunikations-Objekte: Nur bei 5 DD/DS entsprechen die Kommunikations-Objekte ungefähr dem in Abb. 1 angeführten Mindestumfang; 3 Produkte stellen überhaupt keine Kommunikations-Objekte zur Verfügung und die übrigen DD/DS arbeiten im wesentlichen mit dem Meta-Objekt "User" zur Definition von Benutzerprofilen.

Meta-Objekt-Struktur: Bei 4 Produkten sind Beziehungen zwischen Meta-Objekten im wesentlichen nur innerhalb einer Objektkategorie definierbar und bei 4 weiteren ist eine umfangreiche Beziehungsstruktur herstellbar; 7 Produkte erlauben schließlich eine völlig unbegrenzte Definition von Objektbeziehungen. Unter Berücksichtigung von (31)-(33) erscheinen damit vor allem 3 DD/DS zur vollständigen Abbildung datenbankgestützter Informationssysteme geeignet.

Verbal beschreibende Attribute: Während bei 5 Produkten eine nur wenige Zeilen umfassende Kurzbeschreibung von Meta-Objekten möglich ist, gestatten 10 DD/DS die Ablage bis zu unbegrenzt langen Texten je Objekt. Zusätzlich können bei 4 Produkten Schlagworte als Selektionskriterien zur Reportgenerierung vereinbart werden.

Konsistenzprüfungen: Beim Einfügen, Ändern oder Löschen von Meta-Objekten wird bei 7 Produkten die Vollständigkeit der Beziehungsstruktur und bei 10 Produkten die Eindeutigkeit von Objektnamen geprüft.

Referenzdefinition: Beim Einfügen Ändern oder Löschen von Meta-Objekten wird bei 3 Produkten auf Referenzkorrekturen, also auf das ebenfalls notwendige Einfügen, Ändern oder Löschen anderer Objekt-Definitionen hingewiesen.

Versionenspeicherung: Nur bei 2 DD/DS ist eine echte Speicherung unterschiedlicher Versionen möglich; weitere 4 Produkte erlauben zumindest die Vergabe von Versionsnummern. Bei insgesamt 6 DD/DS können im übrigen Statusangaben zur Kennzeichnung der für eine Objektdefinition relevanten Phase im Systemlebenszyklus vereinbart werden.