Bemühungen um effektive Datendesign-Methoden spielten sich lange in einer mehr oder weniger theoretisch-abstrakten Diskussionsumgebung ab. Als besonderer Mangel der hieraus resultierenden Empfehlungen für die Praxis erwies sich, daß meist das organisatorische Umfeld völlig ignoriert wurde. Günter Müller-Ettrich* beschreibt seine Erfahrungen mit modernen konzeptionellen Datendesign-Methoden.

Die theoretischen Darstellungen der Methoden zum konzeptionellen Datendesign sind häufig so klar und einleuchtend abgefaßt, daß die Notwendigkeit maschineller Tools nicht sofort erkennbar wird. Häufig müssen erst bittere Erfahrungen in der Praxis gemacht werden, um zu erkennen, wo die Grenzen manueller Verfahren liegen. Einige dieser Hauptprobleme manueller Verfahren wurden bereits vorher beschrieben. Wurde einmal erkannt, daß aufgrund dieser Probleme ein maschinelles Tool notwendig wird, so ist es vorteilhaft, die Auswahl nach einer Anforderungsliste vorzunehmen, die auch in Zukunft auftretende Probleme abdeckt.

Fachseite muß frühzeitig einbezogen werden

Je nach Struktur des Datenmanagements im jeweiligen Unternehmen sind diese Anforderungen verschieden zu gewichten. Als K. O.-Kriterien für ein Tool werden aber wohl überall mangelhafte beziehungsweise nicht vorhandene Wartung und die Nicht-Integrierbarkeit in eine gegebene Hard- und Softwareumgebung gelten.

Da das konzeptionelle Modell eine gemeinsame Basis für Anwendung und System sein soll, sind oft je nach Fall angepaßte optimierte grafische Darstellungen (dynamische Grafiken) von Bedeutung, wobei diese je nach Betrachter (Sachbearbeiter, Manager) einen verschiedenen Detaillierungsgrad haben müssen.

Eine der wichtigsten Forderungen ist die frühzeitige - beziehungsweise unmittelbare - Einbeziehung der Fachseite bei Entscheidungen, bei denen die Bedeutung (Semantik) der Datenelemente und ihrer Verknüpfungen wichtig ist.

Da der Einsatz eines Datendesign-Tools ohne Datendesignmethode aufgrund bisheriger Erfahrungen meist zum Fiasko wird, sind eine Dokumentation der vom Tool unterstützten Methoden und eine diesbezügliche Schulung von besonderer Bedeutung.

Der erste Vorläufer der Datendesign-Tools ist das Data Base Design Aid (DBDA) der IBM. Es ist jedoch in der Handhabung relativ umständlich und bringt Ergebnisse, die in vielen Fallen in keinem Verhältnis zum Aufwand stehen. Dieses Tool wird deshalb heute kaum noch ernsthaft empfohlen.

Ein weiteres Produkt, das Data Model Design Aid, wird von IBM als IFP (International Field Program 5787-IAA) vertrieben. Es ist eine ungarische Entwicklung und stellt das "Gesellenstück" des ungarischen Teams dar, von dem das im folgenden beschriebene "Adam & Eva"* entwickelt wurde. Aufgrund der IBM-Vertriebspolitik blieb dieses Tool relativ unbekannt.

Das erste Datendesign-Tool mit größerer Publizität ist der Data Designer der James Martin Corporation. Dieses Produkt konnte jedoch wegen der problematischen Wartung und Unterstützung in Europa im Gegensatz zu den USA nicht Fuß fassen.

Erfolgreich war hingegen der Designmanager der MSP (Manager Systems & Programming Ltd., London), ein Produkt, das zwar "stand-alone" eingesetzt werden kann, seine volle Wirkung jedoch erst in einer MSP-Softwarefamilie (Datenmanager, Control Manager) entfaltet. Das jüngste Design-Tool (Adam & Eva) kommt aus Ungarn und wurde aufgrund der Erfahrungen des ungarischen Teams bei der Entwicklung des Data Model Design Aid entworfen und implementiert. Es besteht aus zwei unabhängig voneinander einsetzbaren Teilen, einem Data Modeller (Adam) und einem Event-Activity Modeller (Eva).

Sieht man von einigen noch in der Entwicklung befindlichen Tools (wie Prisma innerhalb der Rochade-Familie) ab, so dürften in Europa augenblicklich lediglich der "Designmanager" und eventuell "Adam & Eva" ernsthaft als Datendesigntools in Frage kommen.

Der "Designmanager" ist ein Dictionary-gesteuertes Softwareprodukt, das einerseits als Speichermedium für die Verwaltung von Datenelement-, Userview- und Entitiesdefinitionen, andererseits als Designtool für die Normalisierung (zweite beziehungsweise dritte Normalform) und Optimierung von Daten sowie Generierung von Datenmodellen eingesetzt werden kann.

Der "Designmanager" kann sowohl "stand-alone" als auch mit dem "Datamanager" zusammen installiert werden. In einer integrierten "Datamanager/Designmanager-Installation stehen alle "Datamanager"-Funktionen zur Verfügung.

Der "Designmanager" arbeitet entweder im "Dictionary Mode" oder im "Design Mode". Im "Dictionary Mode" können nur reine Dictionaryfunktionen durchgeführt werden, wie Aufnahme und Änderung von Datenelementen, Userviews und Entities sowie Erstellung bestimmter Auswertungen. Zur Ausführung der Dictionary-Funktionen stehen spezielle Befehle zur Verfügung.

Nach Abschluß der Eingabe der Datenelemente und Userviews (Entities) kann mit der Erstellung des konzeptionellen Modells begonnen werden. Die dazu notwendigen Funktionen werden im "Design Mode" durchgeführt. Hierbei werden zunächst die relevanten Userviews (Entities) aus dem Dictionary in einen Arbeitsbereich im Hauptspeicher, die Workbench Design Area, gebracht. Dies geschieht über einen Merge-Befehl, in dem die interessierenden Userviews (Entities) angegeben werden müssen.

In dem durch diesen Befehl ausgelösten Prozeß werden die Userviews (Entities) zu einer Gesamtsicht (composite view) zusammengemischt (Abbildung 3). Hierbei trifft der "Designmanager" einige wichtige Vorentscheidungen, die unbedingt von der Fachseite zu überprüfen sind. Ist der Anwender mit den Vorentscheidungen des "Designmanagers" nicht zufrieden, müssen Userviews korrigiert und anschließend der Merge-Prozeß wiederholt werden.

Nach erfolgreichem Merge-Prozeß wird durch den Design-Befehl ein Prozeß angestoßen, in dem die aus den Userviews und Entities entstandene Gesamtstruktur normalisiert wird und entsprechende Relationen in dritter Normalform aufgebaut werden. Mit einem Zusatzprogramm kann in der neuesten Designmanager-Version das konzeptionelle Modell-in ein erstes physisches Modell von IMS/VS beziehungsweise SQL/ DS oder DB2 übertragen werden.

Ein Designmanager-Lauf läßt sich sowohl Online als auch Batch durchführen. Online kann im "Design Mode" nur unter TSO und CMS gearbeitet werden, im "Dictionary Mode" auch unter "Roscoe", ISPF, CICS.

Adam & Eva ist das jüngste Produkt unter den Datendesign-Tools. Es besteht aus zwei unabhängig voneinander einsetzbaren Teilen, einem Data Modeller (Adam) und einem Event-Activity Modeller (Eva). Beide Teile benutzen ein Modelling-Dictionary und können gemeinsam zur Entwicklung der Daten-Prozeß-Strukturen eingesetzt werden. Die Funktionen des Adam-Bestandteils zur Datenmodellierung entsprechen etwa denen der bekannten Datendesign-Tools.

Wird im folgenden von "Adam & Eva" gesprochen, so bezieht sich dies ausschließlich auf den Datenmodellierungsteil. Dieser besteht im wesentlichen aus einer Anzahl von Programm-Moduln, die zwar transaktionsorientiert angelegt sind, aber als Batchprogramm ablaufen. Diese Programm-Moduln erfüllen jeweils sehr detaillierte Spezialaufgaben innerhalb des Designprozesses.

Die Ablaufreihenfolge der Programme hängt vom jeweiligen Anwendungsfall und den dort auftretenden Problemen ab. "Adam & Eva" liefert als Ergebnis jedes Programmlaufs eine Liste der Programm-Moduln, mit denen der Modellierungsprozeß fortgesetzt werden kann. Die tatsächliche Auswahl muß aber vom Datendesigner getroffen werden. "Adam & Eva" stellt ihm dazu einen Netzplan möglicher Abläufe zur Verfügung.

Im allgemeinen läuft ein Datendesignprozeß mit der Datenmodellierungskomponente von ".Adam & Eva" in vier Schritten ab. Im ersten Schritt werden die Datenelemente erfaßt und mit einer Beschreibung bezüglich ihres Erfassungsursprungs versehen. Anschließend werden sie analysiert, und es werden Hinweise auf Homonyme beziehungsweise Synonyme ausgegeben.

Erst wenn der Datendesigner alle diesbezüglichen Unstimmigkeiten mit Eingaben über entsprechende Hilfsfunktionen geklärt hat, kann zum zweiten Schritt übergegangen werden. Dort sind die Beziehungen zwischen den Datenelementen festzulegen. Im dritten Schritt werden diese Verknüpfungen zwischen den Datenelementen insbesondere im Hinblick auf eine normalisierte Zusammenfassung zu Entities geprüft.

Hier bietet "Adam & Eva" eine große Palette von Analysen und Prüfungen. Einige bei den Analysen aufgetauchten Unstimmigkeiten müssen auf jeden Fall beseitigt werden, bevor zum nächsten Schritt weitergegangen werden kann, andere wieder um (zum Beispiel transitive Abhängigkeiten) können vom Datendesigner akzeptiert werden. Im vierten und letzten Schritt findet schließlich die endgültige Zusammenfassung von Datenelementen zu Entities und deren Verknüpfung statt.

*Günter Müller-Ettrich ist DB/Dc-Organisator bei der IABG, Ottobrunn bei München.

*Adam und Eva wird vertrieben von Szamalk, Computing Applications and Service Company, Budapest.