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.

Gibt es nun eine Datendesign-Methode, die zumindest einen Teil der anspruchsvollen Anforderungen erfüllt und die sich auch vernünftig in das organisatorische Umfeld größerer Unternehmen einfügen läßt? Abbildung 2 zeigt das Schema einer Vorgehensweise, von der man sich die Erfüllung zumindest eines Teils der Maximalanforderungen erhofft. Diese Methode wird im folgenden als konzeptionelles Datendesign bezeichnet.

Zwei Methoden sind die Säulen des Datendesigns

Die beiden Säulen des konzeptionellen Datendesigns sind die "Bottom-up"-und die "Top-down"-Methode. Die "Bottom-up"-Methode beschäftigt sich mit Daten auf elementarster Stufe - den Datenelementen als kleinsten Informationseinheiten und deren Beziehungen zueinander. Die Bausteine der "Bottom-up"-Methode sind Benutzersichten (Userviews), die die gewünschten Zugriffe zu den Datenelementen aus der Sicht einzelner Anwendungen zeigen, beziehungsweise die Datensicht der Anwender wiedergeben.

Ein Userview der Personalabteilung kann zum Beispiel darin bestehen, daß von der Personalnummer über das Monatsdatum zum Gehalt zugegriffen werden soll. Mitarbeiter, Datum und Gehalt stellen hier die Datenelemente dar, die gemäß der gewünschten Zugriffsfolge verknüpft werden müssen. Um zu einer einheitlichen Datenstruktur zu kommen, sind die verschiedenen Userviews in einer gemeinsamen Struktur zu integrieren.

Dies geschieht dadurch, daß bestimmte Datenelemente der Userviews zu größeren Informationseinheiten (Entities) zusammengefaßt werden, wodurch sich die Zahl der Verknüpfungen drastisch verringert, da jetzt nach außen nur noch die Entities verknüpft werden müssen. Um möglichst stabile Datenstrukturen zu bekommen, sind bei dieser Zusammenfassung bestimmte Regeln (Normalisierungsregeln) zu beachten.

Gravierende Probleme können dann bei der Zusammenfassung auftreten, wenn verschiedene Anwendungen verschiedene Namen für gleiche Datenelemente (Synonyme) verwenden oder dieselben Namen für verschiedene Datenelemente (Homonyme). Userviews lassen sich auf verschiedene Arten gewinnen, zum Beispiel aus Formular- und Datenbestandsanalysen, aus Interviews aber auch aus Realitätsbeobachtungen. Der "Bottom-up"-Ansatz ist besonders dann von Nutzen, wenn bereits sehr stark analysierte Anwendungen vorliegen, bei denen die Datenelemente und Zugriffsfolgen bekannt sind.

Der "Top-down"-Ansatz verfolgt die zum "Bottom-up"-Vorgehen entgegengesetzte Richtung. Es wird hier von einem Projekt-(Unternehmens-) Modell in Form grober, untereinander verknüpfter Informationseinheiten ausgegangen, das stufenweise soweit verfeinert wird, daß darin auch die kleinsten Datenelemente einschließlich ihrer Verknüpfungen enthalten sind. Das "Top-down"-Verfahren stellt also eine Systementwicklungsmethode dar, in dem vom Groben durch ständige Verfeinerung zum Detail der Datenstruktur vorgegangen wird.

Erste Eingaben für das "Top-down"-Verfahren liefern normalerweise Mittel- beziehungsweise Top-Management, die am besten in der Lage sind, eine Gesamtsicht des Projekts beziehungsweise des Unternehmens zu liefern. Bei einer Analyse von Einzelproblemen kann es zweckmäßig sein, immer zuerst mit einem "Top-down"-Verfahren zu beginnen.

Mit zunehmender Detaillierung großer Informationseinheiten beziehungsweise deren Beziehungen zueinander entsteht so ein Modell, das mit dem aus dem "Bottom-up"-Ansatz entstandenen Modell vergleichbar ist. Damit kann dann ein Abgleich zwischen den beiden Modellen durchgeführt werden, wobei das aus dem "Bottom-up"-Ansatz entstandene Modell vervollständigt, beziehungsweise das aus dem "Top-down"-Ansatz entstandene Modell verfeinert wird.

Grundsätzlich läßt sich zum "Top-down"- und "Bottom-up"-Ansatz folgendes sagen: Steht man in einem Unternehmen am Anfang des konzeptionellen Designs, dann besteht die Gefahr, daß mit dem "Bottom-up"-Vorgehen ein Datenmodell entsteht, das zu sehr auf die bereits stark analysierten Anwendungen ausgerichtet ist.

Dies kann später zu starken Änderungen im Datenmodell führen, sobald neue Bereiche entsprechend detailliert analysiert werden. Konflikte sind dann vor allem mit den Anwendungsentwicklern der zuerst analysierten Gebiete zu befürchten, die sich bereits feste Vorstellungen über die Datenstruktur gemacht haben. Dieses Problem kann entschärft werden, indem parallel zum "Bottom-up"-Ansatz auch "Top-down" vorgegangen wird.

Ein ganz wesentlicher Anteil am Gelingen des Datenbankdesignprozesses liegt im richtigen Zeitpunkt des Einsatzes der beiden Methoden. Das "Top-down"-orientierte Datenbankdesign muß möglichst früh beginnen, noch bevor mit dem "Bottom-up"-Ansatz angefangen wird, also schon während des Grobkonzeptes. Der Einsatzzeitpunkt des "Bottom-up"-Ansatzes liegt im Phasenkonzept eines Unternehmens recht spät. Er kann erst begonnen werden, wenn nach dem Sollkonzept alle Bildschirmmasken und Listenbilder definiert worden sind.

Ein Problem zu Beginn des "Top-down"-Ansatzes besteht darin, festzulegen über welche Bereiche sich das Gesamtmodell erstrecken soll. Im allgemeinen ist es in Großunternehmen illusorisch, gleich mit einem Modell des ganzen Unternehmens zu beginnen. Man wird hier vielmehr ausgehend von Modellen der Anwendungsebene über die Ressortebene mit dem Ziel fortschreiten, die ganze Unternehmensebene zu erfassen.

Bereits aus diesen kurzen Ausführungen ist zu erkennen, daß es keine von den organisatorischen Einheiten und technischen Problemen eines Unternehmens losgelöste allgemeingültige Datendesign-Methode geben kann. Vielmehr ist jeweils eine auf die Struktur und Probleme des Unternehmens zugeschnittene Datendesign-Methode zu entwickeln, die den "Top-down"- beziehungsweise "Bottom-up"-Ansatz als Bestandteil enthält und die über fest vorgeschriebene Aktivitäten im Phasenmodell des Unternehmens verankert ist.

Vier Faktoren sichern Qualität des Modells

Die Qualität eines nach dem konzeptionellen Datendesign entstandenen Datenmodells hängt davon ab, (...)

- ob alle Typen von Datenelementen enthalten sind, die von den Anwendungen gebraucht werden,

- ob es alle Arten von Anwenderanforderungen (Userviews) zufriedenstellen kann,

- wie gut es neue Datenelemente und Anwenderanforderungen integrieren kann,

- wie gut es sich in ein performanceorientiertes physisches Datenmodell eines speziellen Datenbanksystems übersetzen läßt.

Sind entsprechende Datendesign-Tools vorhanden, so wird man beim "Bottom-up"-Ansatz zunächst die Datenelemente und Userviews in das "Modelling Dictionary" dieser Tools speichern. Ist bereits ein Data Dictionary vorhanden, so müssen hiermit entsprechende Abgleiche vorgenommen werden.

Im Normalfall wird man die Datenelemente lediglich im Data Dictionary bereithalten und sie bei Bedarf in das Tool beziehungsweise das Modelling Dictionary des Tools übertragen. Anschließend werden die Userviews im Dialog mit der Anwenderfachseite bereinigt und mit Hilfe des Modellierungstools unter Berücksichtigung entsprechender Normalisierungsregeln zu einem konzeptionellen Datenmodell zusammengefaßt. Nach Abgleich dieses Modells mit dem Modell des "Top-down"-Ansatzes entsteht als Ergebnis das endgültige konzeptionelle Modell.

Beim "Top-down"-Ansatz werden analog dem "Bottom-up"-Vorgehen zunächst die hier zur Modellierung notwendigen Informationseinheiten (Entities) in das Modelling Dictionary des entsprechenden Werkzeugs gebracht. Die Tools stellen hierfür entsprechende Einrichtungen und Formalismen zur Verfügung. Damit können auch die größeren Informationseinheiten stufenweise verfeinert und Relationen zwischen ihnen festgehalten werden.

Das abgestimmte konzeptionelle Datenmodell bildet die Grundlage für die physischen Datenstrukturen der entsprechenden speziellen Datenbanksoftware. Bei einigen kommerziell verfügbaren Modellierungstools sind Zusatzprogramme vorhanden, mit denen aus dem konzeptionellen Datenmodell ein erstes physisches Modell für IMS, DB2 und ähnliche Produkte erstellt werden kann.

Performance-orientierte Lösungen nicht in Sicht

Man gebe sich jedoch keinen lllusionen hin. Es handelt sich hierbei um "First-Cut"-Modelle, die noch weit davon entfernt sind, performance-orientierte Lösungen zu liefern. Hierzu sind nach wie vor Datenbankspezialisten notwendig, was sich nach Meinung der Experten auch in Zukunft nicht ändern wird.

Damit sind grob die Elemente einer Datendesign-Methode umrissen, von der man sich die Erfüllung der genannten Anforderungen erhofft. Ein detailliertes Verständnis der skizzierten Techniken zum "Top-down"-beziehungsweise "Bottom-up"-Vorgehen ist allerdings wohl lediglich über Beispiele oder Fallstudien möglich.

Allgemein ist für das erfolgreiche konzeptionelle Design der Einsatz eines Design-Tools sicher nicht erforderlich. Es gibt zahlreiche Probleme aus der Praxis, bei denen der Einsatz konzeptioneller Designmethoden zu spektakulären Lösungen führen kann, ohne daß auch nur das geringste maschinelle Hilfsmittel zur Verfügung stehen muß. Dies gilt insbesondere dann, wenn es zunächst darum geht, erste Grobmodelle zu entwickeln. Anders wird aber die Situation, wenn der erste grobe Lösungsansatz detailliert werden muß. Hier treten bei einem manuellen Vorgehen, insbesondere beim relativ aufwendigen "Bottom-up"-Verfahren zunehmend Schwierigkeiten auf.

Das erste Problem besteht darin, daß das manuelle Vorgehen schreibintensiv ist. Die Zusammenfassung der Datenelemente unter Berücksichtigung der Normalformen bringt es mit sich, daß jeder Datenelementname mehrmals geschrieben werden muß. Ebenso sind bei Korrekturen von Normalisierungsprozeßmaßnahmen Formulare sehr oft mehrmals auszufüllen .

Ad-hoc-Änderungen machen DB-Modell zur Makulatur

Ein zweites Problem entsteht, weil Änderungen zum Beispiel durch neue Userviews nach erster Erstellung eines konzeptionellen Modells wegen des großen manuellen Arbeitsaufwandes entweder gar nicht oder verspätet in das Modell integriert werden. Die Änderungen werden häufig ad hoc in das physische DB-Modell eingebracht. Das konzeptionelle Datenmodell wird damit Makulatur.

Ein weiteres Problem tritt durch die mangelnde Übersicht beim manuellen Vorgehen auf. Der Überblick über alle Relationen ist eingeschränkt, meist können nur zwei bis drei Formulare gleichzeitig angeschaut werden. Daher ist es oft besonders schwierig, Synonyme und Homonyme zu entdecken.

Erfordert erfolgreiches konzeptionelles Datendesign ein bestimmtes organisatorisches Umfeld? Hier gibt es aufgrund der bisherigen Erfahrungen zahlreicher Anwender mit dem konzeptionellen Design nur eine Antwort: Unbedingt, es sei denn, man will die Methode nur für einzelne spektakuläre Fälle einsetzen. (Siehe auch Kasten.)

Wie aus dieser Grafik zu entnehmen ist, stellt die Datenadministration gegenüber der "klassischen" Datenverwaltung eine neue zusätzliche Organisationseinheit dar. Die Datenadministration ist im einzelnen verantwortlich für die Definition und Fortführung der Datenelemente, Userviews, Entities und sonstiger anwenderorientierter Informationseinheiten, die Normalisierung der Daten sowie deren Dokumentation und Fortführung, ferner für die Erstellung, Überprüfung, Dokumentation und Verwaltung der Datenmodelle.

Die Funktionen der Datenadministration setzen in erster Linie anwendungsorientiertes Spezialwissen voraus. Es ist deshalb vorteilhaft, diese Funktion nicht auf der DV-Seite, sondern auf der Anwendungsseite anzusiedeln. Die Datenadministration gehört zu dem Management des Bereichs, innerhalb dessen eine einheitliche integrierte Datenorganisation angestrebt wird.

DB-Administration erfordert gute SW-Detailkenntnisse

Die Datenbankadministration benötigt im Gegensatz zur Datenorganisation sehr gutes DV-Know-how. Insbesondere muß sie über sehr gute Detailkenntnisse der relevanten Datenbanksoftware verfügen, da sie im wesentlichen für die physische Implementierung der konzeptionellen Datenmodelle zuständig ist.

Es hat sich bei allen bisherigen Versuchen gezeigt, daß es für ein erfolgreiches konzeptionelles Design zwingend notwendig ist, die Datenadministration auch personell zu besetzen und nicht irgendwo, zum Beispiel in Projektteams oder der Datenbankadministration, mitlaufen zu lassen.

Bei Analyse der heute zur Anwendung kommenden Verfahren für die Abwicklung anspruchsvoller DV-Projekte sucht man meist vergeblich nach zwingend vorgeschriebene und formalisierten Aktivitäten bezüglich des Datendesigns. Dies ist aber unbedingt notwendig. Es ist unter anderem in einem Phasenmodell eines Unternehmens festzulegen, wann und wo "Userviews" zu erstellen sind, beziehungsweise mit "Top-down"-Verfahren des Datendesigns zu beginnen ist, und wann das fertige konzeptionelle Modell vorliegen muß.

Literatur:

1. M. Vetter: Aufbau betrieblicher Informationssysteme, 2. Auflage, Teubner Verlag, Stuttgart 1985

2. J. Martin: Managing the Data Base Environment, Prentice Hall, Englewood Cliffs/ N.J., 1983

3. C. Beeri/P.A. Bernstein: Computational Problems Related to the Design of Normal Form Relational Schemas, ACM Trans. Database Syst. 4,1, März 1979

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