Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

16.06.1983 - 

Unterschiedliche Produktbilder besonders bei der Integration:

Das typische Dictionary-System gibt es nacht

Die Leistungsfähigkeit eines Data-Dictionary-Systems (DD) für den Betrieb ist im wesentlichen von zwei Faktoren abhängig: Einerseits -bestimmen selbstverständlich die Eigenschaften des Produktes wie Funktionsumfang, Qualität, Integrationsgrad die Leistung; andererseits hängt bei Dictionary-Systemen der Nutzen einer konkreten Implementierung und damit die Benutzerleistung - in hohem Maße von den bei und vor allem vor der Einführung getroffenen Maßnahmen sowie unveränderlichen, meist organisatorischen Randbedingungen ab. Diese Aussage Ist für jede Art Software eigentlich eine Banalität, kann jedoch gerade für DDs, sollen sie mehr als reine Dictionaries sein, nicht genug herausgestellt werden.

Das Lösen organisatorischer Probleme oder gar von Führungsproblemen per Software, von der Fachabteilung häufig genug versucht, funktioniert auch im Bereich der DV nicht. So gibt es denn durchaus Fälle, in denen ein sehr einfaches Dictionary, kaum mehr als eine Aufzählung von Datenelementen mit ihren Attributen und Verwendungen in Datenaggregaten, bei- entsprechend bescheidener Zielsetzung und organisatorischen Möglichkeiten zu mehr Benutzerzufriedenheit führt als die Installation eines umfangreichen, für großmaßstäbliche DV-Einrichtungen gedachten Supertools. Die DV-Wirklichkeit sieht allerdings eher umgekehrt aus: Wo ein leistungsfähiges DD und die entsprechende funktionale Umstellung in der DV notwendig wären, begnügt man sich mit Copy-Strecken von Satzauslagen und den Definitions- und Schnittstellen-Bibliotheken der Datenbanksysteme, die in der überwiegenden Zahl der Fälle eher auf die Verarbeitungsbedürfnisse des DB-Systems zugeschnitten sind. Betrachten wir die beiden Faktoren Produkteigenschaften und Umfeld jedoch zunächst getrennt.

Je nach Philosophie

Jedem, der sich mit der Auswahl und damit mit dem Markt der angebotenen Dictionary-Systeme beschäftigt (eine Eigenerstellung bleibt, wenn technisch irgendwie machbar, tabu), wird zuerst auffallen, daß die DD ein höchst heterogenes Bild bieten. Von dem typischen Dictionary System kann man eigentlich gar nicht sprechen: Je nach Herstellerphilosophie ergibt sich ein anderes Produktbild, insbesondere bei der Integration.

- Da ist zunächst das mehr DB-orientierte Dictionary-System. Es dient vornehmlich der Definition DB-spezifischer Kategorien wie Datenelement, -gruppe, -satz -bank; aber auch Schnittstellen (PCB) und Prozeßsystem (Programm, Transaktion) und ihre Querbeziehungen werden spezifiziert. In neueren Systemen wird das Dictionary dieser Art vor allem zur Laufzeit des Datenbanksystems als Dictionary benötigt. Alle Abfragesprachen benötigen, und zwar um so mehr, je weniger Datennavigation dem Benutzer zugemutet wird, solche Directories, die häufig etwas verschämt "Tabelle" genannt werden.

- Die Hersteller von Tools für die Anwendungsentwicklung, ob mehr Code-orientiert ("Programmgeneratoren"), mit mehr ganzheitlichen, meist spezifikationsorientiertem Ansatz oder mehr dokumentationsorientiert, versuchen alle Entwurfsentscheidungen soweit wie möglich lokal zu halten, um diese Information beherrschbar zu machen. Während diesen Systemen in gewisser Weise die Existenz eines DD, das ja in höchstem Maße globale Information enthält, zuwiderläuft, müssen die Hersteller doch erkennen, daß für Anwendungen in Wirtschaft und Verwaltung eine gemeinsame Metadatenbasis benötigt wird.

- Die Dictionary-Systeme anderer Hersteller sind von der DB-Software wie von den Entwicklungstools desintegriert, sie konzentrieren sich vornehmlich auf die Speicherung und Abfrage von Metadaten aus dem Daten- und Prozeßbereich, insbesondere auf die Darstellung von Verwendungsbeziehungen verschiedener Art. Diese unabhängigen DDs zielen mehr auf die betriebliche Terminologiekontrolle, Dokumentation und Software-Konfigurationssteuerung.

Welcher Herkunft die DD-Systeme auch sind - datenbankunterstützend, entwicklungsunterstützend oder unabhängig - sie sind alle Datenbanken mit Metadaten, und hieraus ergeben sich auch schon die wesentlichen funktionalen Leistungsmerkmale.

- Ein DD ist in gewisser Weise ein Dokumentationssystem. Die Leistungsfähigkeit wird daher durch die gebotenen syntaktischen Möglichkeiten der Definitionssprache bestimmt. Die Fragestellung lautet also, ob das DD geeignet ist, das zu beschreiben, was die verschiedenen Benutzer - Abfragende wie Generatoren und zugreifende Tools - benötigen. Die heutigen Dictionarys-Systeme erlauben hier neben einer vollständigen Beschreibung von Datenelementen und -Aggregaten auch die Unterstützung für DB-Systeme und RZ-Funktionen. Flexiblere Systeme lassen sich in unterschiedlicher Weise - durch benutzerdefinierte Kategorien, Attribute und Relationen - den Gegebenheiten der Installation anpassen.

- Die Leistungsfähigkeit bei der Aufnahme von Metadaten, insbesondere Nacherfassungen, in das DD-Schema ist bei allen Systemen gering. Formatierte Systeme haben es hier einfacher, denn sie können mit einfachen "Fill-in-the-blanks"-Masken arbeiten. Für sprachorientierte Systeme mit ausgefeilter Syntax und entsprechenden Möglichkeiten bleibt nur der Editor zur Erfassung. Möglichkeiten zur automatischen Erfassung, etwa aus bestehenden Strukturbibliotheken, sind bei einigen Systemen vorhanden, jedoch mit Vorsicht zu genießen, da Synonyme nicht entdeckt werden können. Die Eingabe ist auch eine installationsabhängige Problematik, da viele Benutzer zusätzliche Prüfungen entsprechend den hausinternen Standards einschalten möchten.

- Nimmt man an, daß DD-Schema wie Eingabemöglichkeiten stimmen, dann stellt sich die Frage, wie die Daten aus dem DD wiederzugewinnen sind. Hier unterscheiden sich die verschiedenen Dictionaries außer in der Integration noch am deutlichsten. Zumeist werden spezielle Query-Systeme und Report-Generatoren eingesetzt, da wegen unformatierter Daten selbst von DB-Herstellern die Standard-Query nicht eingesetzt werden kann. Dictionaries sollen hier neben direkten Verwendungsnachweisen auch indirekte, über mehrere Stufen gehende Nachweise, ermöglichen. Neben diesen direkten Zugriffen erlaubt ein DD auch den Zugriff über Aliasnamen und Schlüsselworte (KWIC- oder KWOC-Prinzip).

- Abgesetzte DD, die nicht gleichzeitig Directory-Funktionen für das Datenbanksystem erfüllen, sollten über Generierungsfunktionen für das entsprechende DB-System in Form von Schema- und Subschema-Generierung verfügen. Von besonderem Vorteil ist die Generierung von Definitionen für verschiedene Datenbanksysteme, wenn das DB-System noch nicht feststeht, mehrere DB-Systeme installiert sind oder ein Wechsel denkbar erscheint: Die Beschreibung der Daten des Unternehmens bleibt bestehen.

- Die Leistungsfähigkeit eines Data-Dictionary-Systems kann schließlich auch durch den Integrationsgrad mit der umgebenden Software beeinflußt werden. Unter Integration sei hier der Zugriff der umgebenden Software auf die im DD gespeicherten Daten zum benötigten Zeitpunkt verstanden, also nicht die benutzergesteuerte Versorgung über Generierungen oder Kopieren. Integration kann mit verschiedenen Systemen vorliegen:

- Abfragesprachen verwenden das Dictionary als Directory;

- Entwicklungstools verwenden die im Dictionary gespeicherte Information als Entwicklungsdatenbank;

- Zugriffsberechtigungen werden vom DB-System dem Dictionary entnommen.

Es gibt eine weitere Zahl von möglichen benachbarten Softwareprodukten, die integriert werden können, jedoch sei vor zuviel Integration gewarnt. Bei Abfragesprachen wie bei allen Integrationen mit Produktionssystemen handelt man sich leicht Performance-Probleme ein, bei Entwickungstools Abgrenzungsprobleme mit Source-Bibliotheken. Insbesondere in einer heterogenen Umgebung zum Beispiel mit DB-Systemen verschiedener Hersteller, teilweiser dateigeschützter Realisierung, verschiedener Abfragesprachen etc. teilt man die Dictionary- und die Directory-Funktionen besser auf zwei Systeme auf , um die Leistungsfähigkeit der eigentlichen Dictionary-Funktionen nicht zu behindern. Insgesamt gesehen ist die technische Leistungsfähigkeit der Data-Dictionary-Systeme, ein komplexes Produkt, für das es nur wenige Hersteller gibt, heute durchweg gut.

Nur Aktualität macht nützlich

Der Nutzen jeder DD-Installation steht und fällt - wie bei jedem Datenbestand - mit der Aktualität der Daten. Diese Aktualität kann man einmal durch technische Maßnahmen zu erreichen suchen oder aber zumindest zum Teil durch organisatorische Maßnahmen - etwa Überprüfungen (Andits) - sicherstellen wollen. Wenn auch der technische Weg zunächst einfacher und zwingender erscheint, allein ist er nicht gangbar: Synonyme sind zum Beispiel zur Zeit technisch noch nicht ausreichend zu erkennen. Auch die Integration mit anderen Tools sichert zwar den Parallellauf von "Wirklichkeit und Dokumentation", erzwingt aber keine Terminologiekontrolle oder Standardisierung von Dateinamen oder gar -speichern. Um die Leistungsfähigkeit eines Data-Dictionary-Systems voll entfalten zu können, sind entsprechende organisatorische Maßnahmen durchzuführen. Dazu gehört vor allem die Schaffung einer von speziellen Anwendungen unabhängigen Verantwortlichkeit für die Definition oder zumindest Abstimmungssteuerung mehrfach benutzter Datenelemente.

In Zukunft wird das Data Dictionary eine noch größere Rolle spielen, denn

- die Dezentralisierung verlangt nach Möglichkeiten, Daten wenigstens kompatibel zu halten und

- die Verwendung von Abfragesprachen führt zu größeren Anforderungen der Endbenutzer an Aktualität und Verfügbarkeit der betrieblichen Daten. Ein richtig , geführtes DD wird es der DV erst ermöglichen, diese Nachfrage zu befriedigen und die Datenverwendung sichtbar zu machen.

*Andreas Weber, Institut für angewandte Informatik und formale Beschreibungsverfahren der Uni Karlsruhe (TH)