Kommunikationsprobleme zwischen Fach- und IT-Seite

Datenmodellierung ohne Medienbruch

14.09.2001
Den Case-Tools zum Trotz: Der Prozess von der Erfassung fachlicher Vorgaben bis hin zur Erzeugung eines Datenmodells verläuft in der Regel nicht durchgängig computergestützt. Dieses für Entwickler besonders ärgerliche Manko lässt sich jedoch mit relativ einfachen Mitteln beheben. Von Tamas Szabo und Hans-Dieter Werno*

Datenmodellierung ist einer der wichtigsten und folgenreichsten Schritte im Prozess der Softwareentwicklung. Der Grund dafür liegt auf der Hand: Das Datenmodell soll die fachlichen Anforderungen des Auftraggebers möglichst vollständig, korrekt und eindeutig widerspiegeln und damit überhaupt erst die DV-technische Grundlage für die Entwicklung des Softwareprodukts liefern.

Nun gilt die Kommunikation zwischen dem DV-Fachmann und der meist nicht ausreichend DV-geschulten Fachseite des Auftraggebers schon immer als die Achillesferse der Softwareentwicklung. Oft führt eine missverstandene Kommunikation zwischen Fach- und DV-Seite zum Scheitern oder zur mangelnden Nutzerakzeptanz von Projekten.

Case-Tools sollten alles lösenDieses Kommunikationsproblem schien - ganz im Sinne der Vision vom Software-Engineering - durch das Konzept der "durchgängig computergestützt ablaufenden Datenmodellierungsphase" lösbar. Die seit den achtziger Jahren auf dem Markt existierenden, unterschiedlich mächtigen Case-Tools (von ADW, Bachman, Maestro über IEF, Rochade, Case/4/0 bis zu Rational Rose, Teamwork und Erwin) belegen dies. Auf jedes der mit Marketing-Versprechungen garnierten neuen Case-Tools haben sich Datenmodellierer und Datenbankdesigner mit großen Erwartungen und Euphorie gestürzt. Alle hofften, endlich die maschinelle Lösung ihrer Hauptprobleme bei der Datenmodellierung vorzufinden:

-Erfassung und Aktualisierung der Vorgaben der Fachseite,

-Generierung und Pflege des Datenmodells und der physischen Datenbank,

-grafische Darstellung des Datenmodells sowie

-Synchronisation der fachlichen Kundenanforderungen mit den physischen Datenbankobjekten über mehrere Produktzyklen hinweg und damit ein wirkungsvolles Versions- und Konfigurations-Management.

Sehr bald stellte man jedoch ernüchtert fest, dass auch mit Hilfe dieser Spezialwerkzeuge das angestrebte Ziel nicht erreicht wird, nämlich den Prozess von der Erfassung der fachlichen Vorgaben über die Erzeugung der logischen Datenstrukturen bis hin zu den physischen Datenbankobjekten unter Wahrung der Datenaktualität durchgängig computergestützt abzuwickeln. Etliche Anwender haben kräftig in Case investiert, geben aber nicht zu, sich damit auf dem Holzweg zu befinden.

Die Enttäuschung über die zum Teil so hochgelobten Case-Tools hat im Wesentlichen folgende Ursachen: Die Produkte bieten keine überzeugenden maschinellen Hilfen zur Erfassung und Aktualisierung der für die Datenmodellierung notwendigen Texte (Daten-, Attribut- und Tabellenbeschreibungen) an. Solche Basisfunktionen, die mit rund 80 Prozent den Löwenanteil an der Modellierungsarbeit ausmachen, bleiben deshalb weitgehend Handarbeit - jedenfalls ohne maschinelle Verbindung zum jeweiligen Werkzeug. Die angebotenen Hilfen sind zu komplex, viel zu aufwändig zu lernen und dadurch letztlich zu teuer, rechnet man Beschaffungs- und Ausbildungskosten mit ein.

Das von fast allen Herstellern angebotene Standard-Datenaustauschformat CDIF (Case Data Interchange Format) wird weit- gehend ignoriert. Es gilt als zu komplex und daher nicht praktikabel. Die zum Beispiel in Erwin vorgesehene dialogorientierte Erfassung und Änderung von Attributen und Texten wird von vielen wegen mangelnder Übersichtlichkeit als nicht sehr produktiv angesehen.

Zu viele HürdenDas Problem der fehlenden, zumindest lückenhaften maschinellen Unterstützung gilt gleichermaßen auch für das Nachziehen der Änderungen an den generierten DDL-Jobs für das Versions- und Konfigurations-Management sowie für die Rückkopplung aus dem Katalog des verwendeten Datenbank-Management-Systems (DB2, Oracle etc.).

Stein des Anstoßes ist nicht zuletzt das schlechte Preis-Leistungs-Verhältnis der Tools, die unter Berücksichtigung der genannten Probleme eindeutig zu teuer sind. Die Kosten für eine Einzellizenz liegen im Bereich von 10000 bis 12000 Mark. Eine produktive und effiziente Nutzung des Tools erfordert den Einsatz mehrerer Lizenzen in einem Projekt. Da der Ausbildungs-, Einarbeitungs- und Administrationsaufwand ebenfalls sehr hoch ist, werden in der Regel nur wenige Tool-Spezialisten herangezogen. Schließlich schlägt zu Buche, dass die Werkzeuge schnell altern und sich die Investitionen in den meisten Fällen nicht amortisieren.

Die Gesamtbilanz fällt daher nicht positiv aus - der Verzicht auf die für ein Projekt erforderlichen Mehrbenutzerlizenzen und die notwendige Anzahl ausgebildeter Spezialisten führt zu Engpässen bei der Datenmodellierung. Berücksichtigt man dazu noch, dass letztlich nur rund 20 Prozent des gesamten Modellierungsaufwands von den Tools wirkungsvoll unterstützt werden, so erscheint die Entscheidung vieler Anwender und Projekt-Manager gegen den Einsatz von Spezialwerkzeugen zur Datenmodellierung durchaus verständlich.

Am Anfang steht - wie so oft - die Euphorie, doch schnell mündet die Begeisterung für das vielgepriesene Tool in Enttäuschung. Die Folgen: Man kehrt zurück zur Erfassung der Kundenanforderungen "auf Papier". Es wird grundsätzlich überlegt, ob man die Datenmodellierung nicht besser doch ohne Tools durchführen sollte. Dieser aus Resignation beschrittene (Rück-)Weg ist sicher nicht die Lösung des Problems und zudem alles andere als zeitgemäß.

Der geforderte "einfache" Lösungsweg besteht darin, die Stärken von bekannten, möglichst weit verbreiteten Spezialwerkzeugen zur Datenmodellierung wie beispielsweise Erwin, ER/Studio oder IEF mit universell verwendeten Tools wie Excel oder Access sinnvoll und zielgerichtet zu verbinden.

Der hier gewählte, spezielle Werkzeugmix besteht aus den für die Basisfunktionen der Datenmodellierung eingesetzten Tools Excel und Access sowie dem grafischen Modellierungswerkzeug Erwin.

Dabei wird in Access zunächst ein leeres Erwin-Metamodell vorbereitet. Die Fachseite liefert ihre Eingaben (Texte, Attributbeschreibungen) oder aber die Vorgaben und Muster aus dem Vorgängerprojekt in Form von Excel-Tabellen. Diese Texte werden in Access in den (noch leeren) Tabellen des Erwin-Metamodells (als Kopie aus Erwin übertragen) abgespeichert. Die Zwischenspeicherung in Access macht das ständige Aktualisieren (Überschreiben) der Vorgaben der Fachseite erst möglich.

Keine manuellen EingriffeDie Generierung der physischen Datenbank aus Access erfolgt außerhalb von Erwin mit Hilfe selbst geschriebener Rexx-Prozeduren (eine nicht sehr aufwändige Eigenprogrammierung von Skripts mit insgesamt etwa 2000 Zeilen). Dieser Weg wurde gewählt, um ein lückenloses und ohne manuelle Eingriffe ablaufendes Versions- und Konfigurations-Management sicherzustellen. Die generierte Datenbank wird auf dem Zielsystem gespeichert und in den DB2-Katalog aufgenommen. Für Erwin wird eine Kopie dieser Datenbank erstellt, die dann mit Erwin grafisch dargestellt werden kann. Durch einen jederzeit möglichen Abgleich zwischen der mit den Anwendungsdaten gefüllten Datenbank und dem von der Fachseite gelieferten Mengengerüst lässt sich eine automatische Optimierung der physischen Datenbank durchführen.

Das beschriebene Verfahren stammt aus einem Software-Entwicklungsprojekt der Deutschen Telekom als Auftraggeber. Entsprechend richtete sich die Auswahl des Werkzeug-Mix vorrangig nach den beim Anwender vorhandenen Gegebenheiten. Excel, das der Erfassung und Aktualisierung von fachlichen Anforderungen und Vorgaben dient, bietet vor allem folgende Vorteile:

-Texte in Excel-Tabellenform sind übersichtlicher und eindeutiger als Texte in Word-Dokumentenform. Sie sind maschinell verwertbar. Zwar gibt es auch in Word die Tabellenform, aber bei ungeübtem Gebrauch werden Tabellen erzeugt, die maschinell nicht verwertbar sind.

-Da der Umgang mit Excel inzwischen auch in den Fachabteilungen zur täglichen Routine geworden ist, wird die Kommunikation zwischen der DV-Entwicklung und der Fachseite erheblich erleichtert. Mit Excel kann die Fachseite ihre Vorgaben ohne Mittler selbst erstellen, ändern und nach Bedarf aktualisieren. Dadurch wird die Verantwortung für Daten wieder dort wahrgenommen, wo sie hingehört.

-Erwin-Grafiken können nach konventionellen Verfahren nur auf Papier verteilt werden. Die hier gewählte Methode mit Excel ermöglicht das Speichern der Grafiken in Excel-Zellen (eine Grafik pro Zelle). Somit ist das Problem der maschinellen Verteilung von Bildern im Projekt gelöst. Mit Excel können diese Bilder in beliebigen Vergrößerungen ohne Qualitätsverlust reproduziert werden.

Access als BindegliedAccess bildet das Bindeglied zwischen Excel und Erwin. Es dient zur Speicherung und Pflege der synchronen Kopie des Erwin-Metamodells sowie der dazu gehörenden Inhalte. Anstelle von Access könnten natürlich auch Oracle oder DB2 eingesetzt werden.

Erwin, für das lediglich eine Einzellizenz erforderlich ist, stellt das Datenmodell als Entity-Relationship-Modell grafisch dar. Damit die Generierung und Pflege der SQL, die Rückkopplung mit dem Katalog der physischen Datenbank (hier DB2 auf dem Host) sowie das Versions- und Konfigurations-Management ohne die bei Erwin erforderlichen manuellen Eingriffe und Nacharbeiten ablaufen können, mussten die oben genannten Rexx-Prozeduren geschrieben und in das gesamte Verfahren eingegliedert werden.

Fazit: Mit Hilfe einer geeigneten Kombination von vertrauten Werkzeugen lässt sich der Prozess der Datenmodellierung von der Erfassung der fachlichen Vorgaben bis zur Generierung der physischen Datenbank unter Wahrung der Datenaktualität und über mehrere Produktzyklen hinweg durchgängig computergestützt abwickeln. Durch den Einsatz vertrauter Tools fallen keine Ausbildungskosten an, bei den teuren Spezialwerkzeugen genügt eine Einzellizenz pro Projekt. Ein weiterer Vorteil: Der durchgehend automatisierte Ablauf der Datenmodellierung hat zur Folge, dass Fehler aufgrund manueller Zwischenschritte völlig ausgeschlossen sind. Verbesserungspotenzial bestünde für einen nächsten Schritt dahingehend, dass die Modellierungswerkzeuge die Lage der Bilder in xy-Koordinaten über mehrere Versionen hinweg in einem Repository speichern und dieses nicht manuell nachgebessert werden müsste.

Das beschriebene Verfahren ist bei allen Datenbankanwendungen ab etwa 50 Tabellen sowie überall dort produktiv einsetzbar, wo Data Dictionaries beziehungsweise Modellierungs-Tools zur Verfügung stehen. Als nützlich erweist es sich nicht nur bei Neuentwicklungen, sondern auch in den Fällen, in denen eine Konsolidierung großer Datenbankanwendungen ansteht. Der Umstellungsaufwand rechnet sich für erfahrene Benutzer des gewählten Werkzeug-Mixes bereits nach kurzer Zeit.

*Dipl.-Ing. Tamas Szabo ist Entwickler und Datenbankarchitekt bei der DV Ratio Unternehmensberatung in München; Dipl.-Ing. Hans-Dieter Werno arbeitet als Projekt-Manager bei IBM Global Services in München.

In der Praxis erprobtDas hier beschriebene Verfahren wurde in einem großen Software-Entwicklungsprojekt erprobt, das unter Federführung von IBM mit Mitarbeitern von DV Ratio für die Deutsche Telekom entwickelt und mittlerweile erfolgreich zum Abschluss gebracht wurde.

Die wichtigsten Charakteristika des Projekts waren:

-120 DB2-Tabellen,

-logisches Datenmodell mit 120 Entitäten und 1500 Attributen sowie

-mehr als 600 000 Codezeilen in C++ und Cobol.

Die zunächst nicht durchgängig computergestützte Datenmodellierung auf der Basis von Fachseitenvorgaben (rund 10000 Word-Seiten) stieß sehr bald an ihre Grenzen: Das entstandene Datenmodell hatte keinerlei Bezug mehr zur Realität der Vorgaben. Die Projektleitung entschloss sich daraufhin mitten im laufenden Projekt, diesen Weg aufzugeben, mit dem hier beschriebenen Verfahren auf dem bisherigen Stand aufzusetzen und mit gezielten Aktualisierungsschritten fortzufahren.

Der Umstieg erfolgte auf Basis der vorhandenen Ergebnisse und des existierenden Datenbestands. In mehreren Abgleichverfahren wurden dieser Datenbestand sowie die Datenbankinhalte auf den aktuellen Stand der Fachseitenvorgaben gebracht. Dies war möglich, weil ein Konsens über die eingesetzten und vertrauten Werkzeuge erreicht wurde und die Fachseite bereit war, ihre Eingaben nur noch in Excel-Tabellenform abzuliefern.

Abb.1: Das Problem ...

Eine typische, heute durchaus verbreitete Arbeitsweise: manuelle Eingabe der fachlichen Anforderungen (Word-Dateien) ohne maschinelle Verbindung zum Datenmodellierungs-Tool, hier Erwin. Quelle: DV-Ratio

Abb.2: ... die Lösung

Eine erprobte Lösung stellt die Synchronisation der Vorgaben mit der Datenbank durch eine optimierte Werkzeugkombination dar. Quelle: DV-Ratio