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.
Den Praktikern des Datendesigns ist es seit langem kein Geheimnis, daß die klassischen Empfehlungen zum Datenbankaufbau überwiegend unbrauchbar sind und in vielen Fällen eher dazu dienen, das Fehlen einer systematischen Datendesign-Methode zu kaschieren. Dieses Fehlen einer zufriedenstellenden Methode ist bisher lediglich deshalb nicht ins breite Bewußtsein der Datenverarbeiter gedrungen, weil die mit dem Datenbankdesign betrauten Fachleute mit mehr oder minder effektiven selbstgemachten "Do-it-yourself"-Methoden doch noch lauffähige Datenbanken erstellen konnten.
Allmählich treten jedoch gravierende Mängel solcher "Hausmacherrezepte" zutage. So zeigt sich beispielsweise, daß viele der auf diese Weise entstandenen Datenbanken gegen Änderungen anfällig sind, was einen enormen Aufwand für die Pflege bestehender Anwender-Software nach sich zieht. Ein weiteres Problem kommt dadurch zustande, daß viele Datenstrukturen sich wegen ihres barocken Aufbaus nicht mehr entkoppeln lassen, obwohl dies organisatorisch notwendig wäre.
Diese Situation hat sich in letzter Zeit noch durch das Aufkommen neuer Datenbanksysteme (Oracle, DB2, TIS) verschärft, die eine Designmethode wünschenswert machen, bei der ein von dem speziellen Datenbanksystem unabhängiges Datenmodell entsteht, das erst später wahlweise in ein spezielles Datenmodell des ausgewählten Datenbanksystems transformiert werden kann.
Mit einem solchen Modell läßt sich der Entscheidungszeitpunkt für ein spezielles Datenbanksystem unabhängig von Terminen der Systemanalyse festlegen, beziehungsweise eine Migration der Datenbasis von einem Datenbanksystem zu einem anderen einfacher durchführen. Ein besonders gravierender Mangel der klassischen Empfehlungen war, daß in den meisten Fällen das organisatorische Umfeld völlig ignoriert wurde.
Unglücklicherweise spielten sich die Bemühungen um eine effektive Datendesign-Methode lange Zeit in einer mehr theoretisch-abstrakten Diskussionsumgebung ab. Erst seit kurzem sind die Bemühungen, eine für die Praxis brauchbare Methode zu finden, mehr in die Arbeitsumgebung der Praktiker des Datenbankdesigns gerückt. Ergebnis dieser praxisorientierten Bemühungen sie Designverfahren, deren Grundlage in erster Linie das Coddsche Relationsmodell bildet, das entgegen einem weit verbreiteten Irrtum nicht nur für relationale Datenbanken von Bedeutung ist.
Die zunehmende Akzeptanz dieser Verfahren äußert sich unter anderem darin, daß sowohl IBM als auch andere Softwarehersteller Tools auf den Markt bringen, die diese Vorgehensweise unterstützen. Zusätzlich werden alle Kurse der Firma IBM über IMS- beziehungsweise DB2-Datenbankaufbau seit etwa einem Jahr mit einem Vorspann über konzeptionelles Design versehen.
Dem großen Bedarf nach effektiven Design-Methoden steht nun ein Mangel an Erfahrungen sowohl bezüglich der Methoden als auch der unterstützenden Tools gegenüber. Viele Unternehmen warten daher mit der Einführung neuer Methoden noch ab.
Die Meinungen schwanken von völliger Ablehnung bis zu einer enthusiastischen Akzeptanz mit übersteigerten Erwartungen sowohl gegenüber den neuen Methoden als auch den entsprechenden Tools. Während die Ablehnung häufig auf einer Unkenntnis der Methode beruht, wird bei der begeisterten Akzeptanz häufig übersehen, daß ein entsprechendes organisatorisches Umfeld - das meist erst noch geschaffen werden muß - ein Muß für den sinnvollen Einsatz der neuen Design-Methode ist.
Noch vor kurzem wurden Besucher klassischer Herstellerkurse über Datendesign mit einer Fülle technischer Details über den physischen Datenbankaufbau gefüttert. Was jedoch das eigentliche Datendesign betrifft, so wurden sie meist mit Bildern analog Abbildung 1 abgespeist, die die Schritte beim Design einer IMS-Datenbank zeigen soll. Diese auf den ersten Blick einleuchtend aussehende Darstellung wirft bereits beim ersten Versuch, damit eine Datenbank für die Praxis aufzubauen, eine Reihe von Schwierigkeiten auf.
Das erste Problem besteht darin, daß das Datendesign nach dieser Abbildung nur von DV-Fachleuten durchgeführt werden kann. Eine praktische Vorgehensweise erfordert nämlich zunächst eine Präzisierung der aufgeführten Schritte, was wiederum detaillierte DV-Kenntnisse voraussetzt.
Optimale Segmentierung und Strukturierung machen Performance-Überlegungen hinsichtlich der Minimierung der E/A-Zugriffe notwendig, was wiederum genaue Kenntnisse der speziellen physischen Speicherung im entsprechenden Datenbanksystem erfordert. Da jedoch die überwiegende Zahl von Fachproblemen, für die eine Datenstruktur notwendig wird, zum Verständnis sehr detaillierte Fachkenntnisse - und nicht DV-Kenntnisse - voraussetzt, ist es meist unerläßlich, daß die erste Datenstrukturierung von Mitarbeitern der Fachabteilungen vorgenommen wird, die das Problem am besten kennen.
Bei der Erstellung der Datenstruktur durch Mitarbeiter der Fachabteilungen muß meist davon ausgegangen werden, daß diese Gruppe entweder über gar keine oder nur minimale DV-Kenntnisse verfügt. Damit hier das Datendesign erfolgreich ist, muß vom Fachbereich ein Datenmodell ohne spezielle DV-Kenntnisse erstellt werden, das auch vom DV-Bereich verstanden und in Datenmodelle spezieller Datenbanksysteme übersetzt werden kann.
Das zweite Problem, das insbesondere durch die zahlreichen neuen Datenbanksysteme aktuell geworden ist, besteht darin, daß ein Übergang von einem Datenbanksystem zu einem anderen im Normalfall unvertretbar aufwendig ist. Mit der in Abbildung 1 dargestellten Methode entsteht eine Datenbank für ein hierarchisches System. Beim Übergang zu einem anderen Datenbanksystem muß der gesamte Designprozeß unter Einbeziehung der Fachseite nochmals nach einem anderen Schema durchgeführt werden.
Analog dem ersten Problem kann auch dieses mit der Erstellung eines systemneutralen Modells als Ergebnis des Designprozesses entschärft werden. Voraussetzung ist, daß ein solches Modell mit vertretbarem Aufwand in ein Datenmodell eines heute kommerziell angebotenen Datenbanksystems überführt werden kann und daß die Auswirkungen von Implementierungskompromissen jederzeit abschätzbar sind.
Das dritte und gravierendste Problem bei dem Vorgehen nach Abbildung 1 besteht darin, daß hier das organisatorische Umfeld völlig außer acht gelassen wird. Das Datenbankdesign nach dieser Methode ist von einem DV-Spezialisten, dem Datenbankadministrator, in Zusammenarbeit mit den Fachabteilungen durchzuführen, lautet hier meist die lapidare Antwort.
Dies läßt sich jedoch insbesondere bei größeren Unternehmen schon deshalb nicht realisieren, weil es die Personalkapazität der hochspezialisierten Datenbankadministration übersteigt. Außerdem ist eine genügend gründliche Einarbeitung von DV-Spezialisten in die relevanten Fachprobleme ein ausgesprochen unökonomischer Vorgang, ganz abgesehen vom Widerstand der Betroffenen. Auch hier bietet sich eine Lösung über ein systemneutrales Datenmodell an, das von der Fachseite ohne DV-Kenntnisse erstellt werden kann.
Obzwar nun die Probleme bei der klassischen Vorgehensweise schon lange bestehen, sind erst seit zwei bis drei Jahren größere Anstrengungen erkennbar, etwas dagegen zu tun. Charakteristischerweise kamen Anstöße hierzu zunächst aus der Reihe der unmittelbar Betroffenen, nämlich von den Anwendungsentwicklern.
So stellt zum Beispiel die Guide-Arbeitsgruppe "Anwendungs-Entwicklung" im Arbeitspapier "Datenstruktur-Analyse" vom Oktober 1983 die Notwendigkeit eines systemneutralen Datenmodells fest (siehe Kasten). Datenmodelle sollen nach dem Arbeitspapier Abbildungen unternehmensrelevanter Daten und ihrer Beziehungen sein.
Als Basis für die Kommunikation zwischen Anwendern und DV-Bereich müssen sie eine gemeinsame Sprache zwischen DV und Fachbereich ermöglichen, wobei entsprechende Namenskonventionen und standardisierte Datenbeschreibungen festzulegen sind.
Als Arbeitsgrundlage für Anwender und DV-Bereich ist darin die Datenintegrität durch die Verfügbarkeit aktueller und allgemein verbindlicher Informationen zu gewährleisten, wodurch die integrierte Anwendungsentwicklung erleichtert wird. Das Datenmodell soll auch Orientierungshilfen für die individuelle Datenverarbeitung bieten und hier das Auffinden von Daten erleichtern.
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.
Die wesentlichen Guide-Anforderungen an ein systemneutrales Datenmodell
Im Modell müssen alle unternehmensrelevanten Daten und ihre Beziehungen abbildbar sein.
Das Modell muß eine Basis für die Kommunikation zwischen Anwendern und DV-Bereich darstellen.
Das Modell muß dem Fachbereich als Grundlage für die Abteilung physischer Datenmodelle des vorhandenen Datenbanksystems dienen.
Der Fachbereich muß das Datenmodell als Arbeitsgrundlage für die Diskussion fachlicher Datenzusammenhänge verwenden können.
Das Modell soll eine Grundlage für die unternehmensweite Planung und Realisierung von Anwendungen darstellen und gleichzeitig eine Orientierungshilfe für die DVc (individuelle Datenverarbeitung) bieten.