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. Gunter Müller-Ettrich* beschreibt seine Erfahrungen mit modernen konzeptionellen Datendesign-Methoden.

Im folgenden werden die Leistungen des "Designmanagers", als Prototypen für ein Datendesign-Tool, anhand einer Kriterienliste diskutiert. Der "Designmanager" wurde deshalb gewählt, weil er einmal alle wichtigen Bestandteile eines Datenmodellierungstools enthält und weil eine zufriedenstellende Wartung sowie eine Integration in die meisten für Datendesign relevanten Soft- und Hardwarekonfigurationen gewährleistet ist. Nicht genügend gesicherte Wartung ist für viele sonst vom Konzept gut angelegte Tools ein K.O.-Kriterium, wobei es bei der Komplexität der Tools dem Anwender wenig nützt, wenn ihm dazu der Sourcecode zur Verfügung gestellt wird, ohne gesicherte Unterstützung durch schnelle verfügbare Spezialisten des Toolherstellers.

Die einmalige Erfassung der Datenelemente, Userviews und Entities kann im "Designmanager" sowohl im Online- als auch im Batchverfahren erfolgen. Man kann die Datenelementnamen direkt verwenden und die Abhängigkeiten zwischen einfachen beziehungsweise zusammengesetzten Datenelementen mit einem leicht erlernbaren Formalismus formulieren.

Eine komfortable Online-Erfassung und -Verwaltung der Datenelemente, Userviews und Entities im Stand-alone-Betrieb des "Designmanagers" setzt den "Controlmanager" als Steuerungsmodul voraus. Bei Einsatz des IBM DB/DC-Dictionary ist es möglich, die Erfassung und Verwaltung in diesem Dictionary vorzunehmen und mit einem Hilfsprogramm die relevanten Informationseinheiten zwischen diesen beiden Tools "Designmanager" und IBM DB/DC-Dictionary auszutauschen. Wird der "Datenmanager" als DB/DC-Dictionary eingesetzt, ist eine integrierte Verarbeitung mit dem "Designmanager" möglich.

Im Gegensatz zum Online-Eingabekomfort bietet der "Designmanager" im "Stand-alone"-Mode auf dem Gebiet der Homonym- beziehungsweise Synonymerkennung wenig. Lediglich über den "Intersecting Data Element"-Report werden alle Datenelementverbindungen mit gleichen funktional abhängigen rechten Seiten aufgelistet, womit die Hinweise auf mögliche Synonyme und Homonyme gegeben werden.

Bei Integration mit dem Datamanager ist es von Anfang an möglich Verknüpfungen zwischen Datenelementen und Entstehungsursprung abzuspeichern, sodaß bereits bei der Erfassung Homonyme und Synonyme leichter identifiziert werden können.

Gesteuerte Online-Verwaltung

Zur Datenhaltung und -verwaltung im Stand-alone-Betrieb verfügt der "Designmanager" über ein Modelling Dictionary, in dem Datenelemente, Userviews und Entitäten erfaßt werden. Eine bequeme Online-Verwaltung setzt hier wiederum den "Controlmanager" als Steuerungsinstrument voraus. Bei Verwendung des IBM DB/DC-Dictionary ist es möglich, die Daten über einen IBM-DDS-Anschluß ins IBM-Dictionary und umgekehrt zu transportieren.

Die Bildung des konzeptionellen Datenmodells beim Designmanager erfolgt nach einem erweiterten "Synthese"-Ansatz nach Bernstein. Als Ergebnis entstehen verknüpfte Relationen in dritter Normalform (3. NF), beziehungsweise wahlweise auch zweiter Normalform in der Version 2.7. Als Eingaben dienen beim "Bottom-up"-Vorgehen Userviews und beim "Top-down"-Vorgehen Entities.

Userviews und Entities können gemischt eingegeben werden, was ein kombiniertes Vorgehen nach der "Bottom-up"- und der "Top-down"-Methode erlaubt. Ein Problem kann dadurch entstehen, daß der Modellierungsprozeß nur an einer Stelle unterbrechbar ist, nämlich nach dem Merge-Prozeß. In diesem Prozeß werden vom "Designmanager" bereits einige Vorentscheidungen über überflüssige und widersprüchliche Beziehungen gefällt, die ihre Ursache in falschen Userviews haben können.

Nach Prüfung durch die Fachseite und Elimination der falschen Userviews muß dann der gesamte Merge-Prozeß nochmals wiederholt werden. Dies kann bei einem iterativen Vorgehen mit umfangreichen komplexen Strukturen zu einem hohen Ressourcenverbrauch führen. In diesem Fall ist es sinnvoll, von kleineren Organisationseinheiten auszugehen und diese genau mit der Fachseite zu überprüfen, bevor die zugrundeliegenden Strukturen zu größeren Organisationseinheiten integriert werden.

Grafik wichtiger Bestandteil

Grafische Ausgaben sind ein wichtiger Bestandteil eines Datendesign-Tools. Einmal weil das konzeptionelle Datenmodell Arbeitsgrundlage für den Fachbereich sein soll, für den eine ansprechende Grafik unentbehrlich ist, andererseits aber auch, weil die Abteilung eines physischen Datenmodells aus dem konzeptionellen Datenmodell ohne grafische Darstellung eine äußerst mühselige Angelegenheit ist.

Grafiken müssen auch verschiedenen Detaillierungsgrad haben, je nach Bezugsgruppe an die sie sich wenden. Ein Manager will zum Beispiel einen Überblick über die Datenbasis haben und ist nicht an Details interessiert, die lediglich für das physische Design von Bedeutung sind.

Zur grafischen Darstellung des konzeptionellen Modells kennt der "Designmanager" zwei Formen: das relationale Schema und ab Version 2.7 das Netzwerkschema. Der wesentliche Unterschied zwischen den beiden Schemata liegt in der Darstellung der sogenannten "Multivalued Dependencies" (MVD), einer Beziehung zwischen Datenelementen, bei denen einem Datenelement mehrere Datenelemente zugeordnet sein können.

Im relationalen Schema entsteht aus solch einer Beziehung immer eine Einzelrelation, im Netzwerkschema ergibt sich daraus letztlich eine Verknüpfung zwischen Relationen. Im allgemeinen ist das Netzwerkschema wesentlich einfacher und übersichtlicher und eignet sich besonders zur Abteilung physischer Modelle.

Die Darstellung des konzeptionellen Modells als relationales Schema hat früher, vor allem wegen der vielen Relationen, nicht unerheblich zur Verwirrung der Datendesigner beigetragen. In beiden Darstellungen werden die entstandenen Relationen durch zahlreiche Verknüpfungen verbunden, die auf sehr viele Besonderheiten Bezug nehmen. Diese sind in vielen Fällen sehr nützlich, zum Beispiel zum Festlegen von Sekundärindizes, verwirren aber nach den Erfahrungen vieler Designer häufig gerade durch die Vielfalt der Informationen.

Weder das relationale Schema noch das Netzwerkschema geben jedoch einen Überblick über das gesamte konzeptionelle Datenmodell. Lediglich am Ende beider Darstellungen wird eine Assoziationsmatrix ausgedruckt, mit der manuell eine Gesamtübersicht erstellt werden kann. Um diesem Mangel abzuhelfen, gibt es ab "Designmanager" Version 2.7 einen Consolidated Network Plot, der eine Ergänzung des Netzwerkschemas darstellt.

Der Consolidated Network Plot liefert einen Überblick über das Netzwerkschema, wobei Details der Einzelrelationen weggelassen werden. Ein weiteres Charakteristikum dieser Darstellung ist, daß netzwerkartige Verknüpfungen in äquivalente hierarchische Verknüpfungen übergeführt werden, was die Übersichtlichkeit erhöht, weil jetzt keine sich kreuzenden Verbindungen auftreten.

Obwohl der Consolidated Plot einen großen Fortschritt bezüglich einer Gesamtübersicht darstellt, wäre es wünschenswert, die Möglichkeit einer dynamischen Gesamtdarstellung zur schaffen, bei der die Relationen optimal aufgrund ihrer Zahl und Art der Verknüpfungen in einer Grafik (eventuell für einen Plotter) dargestellt werden können.

Unterscheidung Tool-Methode

Es ist zu unterscheiden zwischen Dokumentation und Schulung bezüglich des Tools einerseits und der zugrundeliegenden Methode andererseits. Zielsetzung der Toolhersteller ist, Schulung und Dokumentation so auszulegen, daß sie alle denkbaren Methoden zum konzeptionellen Datendesign unterstützen. Eine Folge davon ist jedoch vielfach, daß nur Toolbeschreibungen ohne Bezug oder nur mit kurzen Hinweisen auf Datendesignmethoden existieren.

Dies wiederum führt häufig zu der irrigen Meinung, daß die Datendesignmethode beim Tooleinsatz lediglich eine untergeordnete Rolle spielt. Es ist daher zu begrüßen, daß bei den bisherigen von MSP angebotenen Schulungen (Wochenkurs) das Handling des "Designmanagers" und die zugrundeliegende Datendesignmethode etwa gleichrangig behandelt werden.

Es fehlt aber eine Anleitung, in der zumindest einige Vorschläge für Datendesignmethoden und richtigen Einsatz des "Designmanagers" gemacht werden, mit der auch Mitarbeiter, die die Schulung nicht nutzen konnten, wissen, wie der richtige Einsatz zu planen beziehungsweise durchzuführen ist.

Der "Designmanager" besitzt in der neuen Version 2.7 Einrichtungen, um aus dem konzeptionellen Modell erste Vorschläge für physische IMS/VS-SQL- beziehungsweise DB2-Datenbanken zu machen. In jedem Fall handelt es sich um erste Vorschläge, aus denen erst performanceorientierte Lösungen erarbeitet werden müssen.

Fachleute mit Erfahrungen auf dem Gebiet der physischen Datenoptimierung neigen häufig dazu, die automatische Ableitung eines ersten physischen Datenmodells zu unterschätzen. Diese ersten Vorschläge haben jedoch, trotz der Tatsache, daß es vom ersten physischen Datenmodell zu einer performanceorientierten Lösung ein sehr weiter Weg ist, in vielen Fällen einen großen Wert - und zwar vor allem dann, wenn es sich um sehr viele Relationen und Verknüpfungen handelt, bei denen selbst der Consolidated Plot keine Übersicht mehr liefert.

In diesen Fällen ist es für den Datenbankadministrator einfacher, ein erstes, wenn auch mangelhaftes physisches Datenmodell zu bearbeiten, als eines aus zahlreichen Entitäten mit entsprechend komplexen Verknüpfungen erstmalig aufzubauen.

Eine Wende im Datendesign im Sinne einer vollautomatisierten Methode läßt sich auf absehbare Zeit weder mit neuen Methoden noch über moderne Datendesign-Tools erwarten. Ganz im Gegenteil ist erst durch die Anwendungen konzeptioneller Datendesignmethoden und Datendesign-Tools die wichtige Rolle einer frühzeitigen Einbeziehung der Fachseite in den Designprozeß deutlich geworden.

Eine weitere wichtige Erkenntnis aus den bisherigen Erfahrungen ist, daß Datendesign-Tools stets nur eine vorhandene Designmethode unterstützen können, ohne zugrundeliegende Methode führt der Einsatz von Datendesign-Tools mit Sicherheit zu einem Fiasko.

Festzustellen bleibt, daß die richtige Anwendung konzeptioneller Designmethoden ein großer Fortschritt gegenüber den herkömmlichen Vorgehensweisen zum Aufbau von Datenbanken darstellt. Das konzeptionelle Datendesign bietet augenblicklich die einzig sinnvolle Alternative, um langfristig den gravierenden Nachteilen der klassischen Vorgehensweisen zu entgehen.

*Gunter Müller-Ettrich ist DB/DC-Organisator bei der IABG, Ottobrunn bei München.