Konzepte der Datenmodellierung:

Weg von der bloßen Paperware

Obwohl als Verfahren altbekannt und durchaus weit verbreitet, gerät die Datenmodellierung oft in Geruch, ein bloßer Papiertiger zu sein. Der Beitrag zum Unternehmenserfolg scheint fragwürdig. Dabei können moderne Vorgehenswesen der Objektorientierung hier durchaus eine klare Perspektive bieten. Wichtig ist freilich, daß nicht aus Werkzeug-Sicht begonnen wird, sondern der Entwurf des Metamodells am Anfang steht.

Seit Beginn der Datenverarbeitung wird Datenmodellierung betrieben. Seit ungefähr fünfzehn Jahren wird sie auch als solche benannt und durch Werkzeuge unterstützt. Die Grundaufgabe, das Strukturieren und Gruppieren der Daten war vom Beginn der Informationsverarbeitung an erforderlich. In der Anfangszeit, die durch die reine Rationalisierung vorhandener Abläufe gekennzeichnet war, gab es einfache Anwendungen und überschaubare Daten. Erst bei der Kopplung mehrerer Anwendungen zu übergreifenden Abläufen trat die Notwendigkeit der formalen und dokumentierten Datenmodellierung schärfer zutage. Als die Systementwicklungs- und Programmierabteilungen rapide wuchsen, wurde die Systemerstellung arbeitsteilig sowie selbst zum rationalisierten Arbeitsablauf. Jetzt entstanden die ersten Werkzeuge, mit denen Datenmodelle erstellt und verwaltet werden konnten.

Von der Lochkarte zum Datenmodell

Tabelle 1: Entwicklungsstufen von "Datenmodellen"

Tabelle 1 zeigt einen historischen Abriß der "Datenmodellierung" seit Beginn der Informationsverarbeitung in fünf Stufen. In der Lochkartenära existierte der Systemanalytiker, Systementwickler und Programmierer noch in Personalunion. Das Modell entstand in seinem Kopf, wo es auch blieb. Die Kündigung "des" Programmierers konnte damals zur echten Gefahr für das Unternehmen werden. Als die Leistungsfähigkeit der Maschinen stieg und die Bandverarbeitung einen Riesenschritt in Speichervolumen und Verarbeitungsgeschwindigkeit brachte, wurden die Anforderungen und auch die Programmierer zahlreicher. Die Systemerstellung wurde arbeitsteilig organisiert und auch die Fluktuation des Personals erhöhte sich dem Personalstand entsprechend. Jetzt war der Zwang zur Dokumentation gegeben. Diese erhielt für die Daten die Form von Datensatz- und Dateibeschreibungen auf Papier. Die indizierten Plattendateien erlaubten es erstmals, mehrere Programme, auch parallel, im direkten Zugriff mit Datenbeständen arbeiten zu lassen. Die Datensatz- und Dateibeschreibungen wurden hierbei nicht mehr nur zur Dokumentation in einer isolierten Anwendung, sondern unternehmensweit als Informationsmedium benötigt.

Tabelle 2: Data Dictionary - Anspruch und Wirklichkeit

Mit der Verbreitung insbesondere der relationalen Datenbanken gegen Mitte der achtziger Jahre konnten die Informationen aus den teilweise endlos langen Bandsätzen herausgelöst werden. Die "Normalisierung" befreite sie zwar von Redundanz, zersplitterte aber auch ihre Struktur. Dieser weitere Komplexitätsschub und der Anspruch, Datenfelder jetzt unternehmensweit redundanzfrei und wiederverwendbar zu halten, machte eine automatisierte Verwaltung der entsprechenden Strukturen und Beschreibungen notwendig. Das Datenmodellierungs-Werkzeug und das Data-Dictionary waren geboren. In den folgenden Jahren wuchsen die Data-Dictionaries als Sammlung von Datenbanktabellen- und Datenfeld-Beschreibungen immer weiter an. Da diese Sammlungen aber nur auf der untersten, der Detailebene angelegt waren, wurden sie bald unübersichtlich und ihrem Anspruch (siehe Tabelle 2) nicht mehr gerecht. Der Aufwand für eine grundlegende Renovierung mit strategischen Konzepten und eindeutigen Grunddefinitionen wurde entweder gescheut oder in den Sand gesetzt.

Die dubiosen Nothelfer

Langsam wächst die Erkenntnis, daß die Wirklichkeit im Bereich der Datenmodellierung und der Data-Dictionaries den Anspruch noch lange nicht erreicht hat. Es tut sich eine Lücke auf, die beim weiteren Versuch, die notwendige unternehmensweite Integration der Datenmodell-Bruchstücke voranzutreiben, empfindlich schmerzt. Nach der beliebten Methode der Entscheidungsvermeidung durch Fremdvergabe werden jetzt verzweifelt Nothelfer von außen gesucht. Die Lücke und die daraus entstehende Notlage erkannten auch Hersteller und Dienstleister aller Schattierungen. Es werden verstärkt Schnellschüsse ohne Substanz oder von Kundenprojekten abgeleitete, mit der heißen Nadel allgemeingültig gestrickte Modelle als "die Lösung für alle Probleme" angeboten.

Sehen wir uns die Angebote einmal näher an:

• Es werden standardisierte Branchen-Modelle angeboten. Bei näherem Hinsehen bestehen diese Modelle aber nur aus abstrakten Formulierungen der höchsten Ebenen. Ist ein Kunde erst einmal an der Angel, läßt sich bei den Beratungsleistungen zur Definition der benötigten niedrigen Ebenen wirklich gutes Geld verdienen.
• Manche Unternehmen wollen die oben genannten Ausgaben durch Kooperationsvorhaben mit Partnern der gleichen Branche umgehen. Oft scheitert ein solches, mit Elan und externen Beratern begonnenes, Projekt an dem unterschiedlichen Verständnis der Grundaufgabe oder dem aufbrechenden Konkurrenzdenken bei der Verfeinerung des Modells. So entstehen oft unbrauchbare Gerippe, die keinen Eingang in die Praxis finden.
• Ein neuer Gag der Hersteller sind die "Frameworks", die ein oberflächliches Datenmodell anbieten. Dieses wird durch eine Datenbank mit angeschlossener Oberfläche (ggf. VisualAge/Smalltalk oder im schlimmsten Falle Visual-Basic) veredelt. Diese Frameworks machen bei einer ersten Präsentation großen Eindruck. Die eigentlichen Funktionalitäten, das was fachlich, konzeptionell und in der Realisierung die Mühe macht, einschließlich Formatprüfungen usw. sind aber dort nicht enthalten. Dies muß der Käufer (natürlich mit heftiger und teurer Unterstützung des Anbieters) noch selbst entwickeln und einfügen.

Selbst von größten und renommierten Herstellern werden solche Windeier und anderes Windiges angeboten. Die Tragik hierbei ist oft, daß die Entscheider die "Frameworks" oder "Visual-x"-Systeme trotz Warnung der Fachleute nicht als luftdurchlässige Gerippe erkennen. Es herrscht dann die Meinung, die Spezialisten wollten nur wieder ihr eigenes Süppchen kochen, wo man doch die perfekte Lösung kaufen kann. Das spätere Erwachen wird durch die krampfhafte Vermeidung eines "Gesichtsverlustes" erschwert. Aber auch Träume können sich zu schmerzhaften Alpträumen auswachsen.

Datenmodellierung ist mehr

Kasten1: Was ist Datenmodellierung ?

Bevor hier über einen Weg gesprochen werden kann, wie eine zeitgemäße Datenmodellierung aussehen sollte, ist primär die Frage zu klären "Was ist Datenmodellierung?". Grundsätzlich handelt es sich um ein Modell, das selbst wieder nach den Regeln eines Metamodells aufgebaut ist. Dieses Metamodell bewirkt, daß das Datenmodell eine stabile Weiterentwicklung erfährt und dabei die Anforderungen abgedeckt werden können, die dem Unternehmen den Nutzen bringen.

Bevor auf die Definition der Datenmodellierung eingegangen wird, soll vorausgeschickt werden, was sie nicht ist, nämlich eine mechanische Detailsammlung von Beschreibungen, um irgendeiner Form mit einem vorhandenen Werkzeug Genüge zu tun. Datenmodellierung kann nicht vom operationalen Standpunkt aus definiert und betrieben werden, sondern muß sich aus dem Bewußtsein um die strategische Ausrichtung des Unternehmens, der eingebetteten Informationsverarbeitung sowie der übergreifenden Anwendungsarchitektur entwickeln. Hierbei muß ebenfalls die strategische Zukunftsplanung einbezogen werden.

Datenmodellierung ist (siehe auch Kasten "Was ist Datenmodellierung ?") nicht eine Sammlung, sondern die Strukturierung der Menge der für ein Unternehmen erforderlichen Informationen. Hierbei sind verschiedene Abstraktionsebenen (z.B. Geschäftssparten, Geschäfte, Abläufe, Anwendungen, Programme) zu berücksichtigen. Diese Abstraktionsebenen haben zwar ihren logischen Zusammenhang und müssen eine aus der anderen entwickelt werden, sind aber für verschiedene Entwicklungsstufen und Zielgruppen bestimmt. Um die unterschiedliche fachliche Ausrichtung und Bewußtseinsebene der Zielgruppen verständlich anzusprechen, ist wiederum ein zielgerichteter Stil und Inhalt der Beschreibung erforderlich. Nur so kann eine Abstimmung der Schnittstellen mit dem "Kunden" vorgenommen werden, die konstruktiv und frei von Mißverständnissen ist. Zu beachten ist bei dem Modell, daß nicht nur die Schnittstelle zum Endbenutzer existiert, sondern die Komplexität der Informationsverarbeitung darüber hinaus weitere Schnittstellen auf dem Weg von der strategischen Planung bis zur Realisierung erfordert.

Das Metamodell

Kasten 2: Eigenschaften und Anforderungen des Metamodells

Das Metamodell zur Datenmodellierung erschöpft sich derzeit oft in der Beschreibung der Syntax des jeweiligen Data-Dictionaries. Wenn es hoch kommt, werden noch einige Sätze zur Semantik spendiert. Diese Vorgehensweise geht nicht weiter als die Dokumentation der Entwicklungsstufen 1 bis 3 gem. Tabelle 1 und ist für ein Datenbank-Datenmodell absolut ungeeignet. Dies ist auch der Hauptgrund dafür, daß in vielen Unternehmen zwar Datenmodellierung betrieben, das Dictionary aber nur widerwillig gefüllt und gepflegt wird. Die Folge sind lückenhafte und redundante Einträge.

Das Metamodell muß den strategischen und organisatorischen Willen verkörpern, das Datenmodell zu einer Drehscheibe des Informationsaustausches zu machen und damit eine Basis für die Fortentwicklung auf jeder Ebene darzustellen. Insofern ist das Metamodell als Entwurfsmuster (siehe auch " Entwurfsmuster als Firmen-Paradigma: Keine bloßen IT-Konstrukte") auf hoher Ebene zu sehen. Kasten 2 zeigt die Eigenschaften, die ein Metamodell haben muß sowie die Anforderungen, die es an das Datenmodell stellt. Zu den bereits oben behandelten Punkten ist hier noch folgendes zu ergänzen:

• Um die Datenbanken und die objektorientierten Modelle (Entwicklungsstufen 4 und 5 gem. Tabelle 1) abdecken zu können, ist das Metamodell und das Datenmodell an den Strukturen der Objektorientierung auszurichten. Wer meint, mit der Objektorientierung entfiele die Datenmodellierung, befindet sich im Irrtum. Das Datenmodell wird sich mit dem Objektmodell verbinden, die erforderlichen konzeptionellen Überlegungen werden sich anders niederschlagen, sind aber dennoch erforderlich und entscheiden über den Erfolg des Vorhabens.
• Die Redundanzfreiheit ist zwar ein Ziel, wird sich aber im Anfang nicht durchsetzen lassen. Gerade die zu übernehmenden Altbestände werden eine Vielzahl von Redundanzen und Mehrdeutigkeiten aufweisen. Um so wichtiger ist es, diese zu dokumentieren und durch entsprechende Querverweise auf die Zieldefinition kenntlich zu machen.
• Wiederverwendung ist nur möglich, wenn die entsprechenden Elemente auch gefunden werden. Ein Schwachpunkt heutiger Data-Dichtionaries ist, daß sie meist keine entsprechenden Such- und Indizierungsmechanismen im Hinblick auf die Dokumentation bieten, um dieser Aufgabe gerecht zu werden. Die objektorientierten Werkzeuge bieten zwar entsprechende Ansätze, sind aber noch entwicklungsbedürftig.

Der Übergang muß gründlich geplant werden

Bild 1: Mögliche Schichtung eines Datenmodells

Wenn der Umstieg auf eine zeitgemäße Datenmodellierung in Angriff genommen wird, ist eine gründliche Planung vonnöten. Wichtig hierbei ist, daß nicht (erneut) aus der technischen bzw. Werkzeug-Sicht begonnen wird, sondern der Entwurf des Metamodells am Anfang steht. Hier werden die Schichten des Datenmodells festgelegt und dokumentiert. Bild 1 zeigt eine mögliche Schichtung, die auf die unterschiedlichen Anforderungen der beteiligten Zielgruppen eingeht und die in Tabelle 3 nochmals im Detail erläutert wird. Das Ergebnis wird das Entwurfsmuster (siehe auch "Entwurfsmuster als Firmen-Paradigma: Keine bloßen IT-Konstrukte") für das Datenmodell.

Tabelle 3: Schichtung eines Datenmodells

Um die grundlegenden Bestandteile des Datenmodells zu fixieren, muß eine umfassende Bestandsaufnahme der beiden Ebenen Business und Fachprobleme mit einer übergreifenden Definition erfolgen. Erfahrungsgemäß treten hier die ersten und schwierigsten Probleme und Mißverständnisse auf. Die Gründe dafür sind, daß einerseits eine Menge Wissen vermittelt werden muß (siehe "Wissenstransfer beim OO-Übergang: Firmenschätze müssen gut gehütet werden"), sich das ganze Unternehmen andererseits auf ein gemeinsames Verständnis zu einigen hat (siehe "Neue Strukturen im OO-Umfeld als Katalysator für die Unternehmenskultur"). Bei der Dokumentation der Arbeitsergebnisse ist darauf zu achten, daß nicht nur die nackten Sachverhalte, sondern auch das gemeinsame Verständnis zu den Daten festgehalten wird. Dies ist für die Ableitung der weiteren Ebenen und das dort erforderliche Verständnis von eminenter Wichtigkeit. Die bei der Aufarbeitung des Ist-Zustandes erkannten Abweichungen von der Zielstruktur sind ebenfalls in das Modell aufzunehmen, dort aber mit Begründung als Abweichung zu dokumentieren und für eine spätere Zusammenführung mit den entsprechenden Verweisen zu versehen.

Objektorientierung hilft

Das objektorientierte Verständnis kann bei der Konzeption eines umfassenden Datenmodells helfen. Allerdings muß darauf geachtet werden, daß die Objektorientierung ganzheitlich (siehe " Neue Strukturen im OO-Umfeld als Katalysator für die Unternehmenskultur") und nicht techniklastig begriffen wird. Heute wird nämlich bei der objektorientierten Modellierung der gleiche Fehler gemacht wie bei der Datenmodellierung mit Hilfe von Data-Dictionaries (siehe Wirklichkeit aus Tabelle 2). Dies liegt am Grundverständnis und nicht an der Methode, da vielfach die Objekte auf unterster Ebene zuerst in Angriff genommen werden. Viele Zeitgenossen glauben gar, es könnte Tools geben, die ihnen aus einer beliebigen Menge von Einzeldatenfeldern Objekte bilden. Dies ist ein grundlegender Trugschluß der mechanistischen Denkweise.

Die Modellierung der weiteren Schichten, der Daten in den Anwendungen und für die Technik werden sinngemäß vorgenommen. Hierbei dienen die oberen Schichten als Entwurfsmuster für die darunterliegenden1. Auf diese Weise können skalierbare Komponenten auf allen Ebenen entwickelt werden. Details zur Komponententechnik und Skalierbarkeit wurden in einem früheren Beitrag (siehe "Komponenten und Skalierbarkeit: Softwareteile in allen Größen") ausgeführt.

Optimistisch in die Zukunft gehen

Mit der beschriebenen Vorbereitung kann durchaus optimistisch in die Zukunft gegangen werden. Wichtig ist, daß keine Wundertools erwartet werden und die Verantwortlichen selbst über künftige Strukturen nachdenken. Die grundlegenden Entwurfsmuster müssen selbst entwickelt und umgesetzt werden. Sie enthalten auch die Anforderungen, die an künftige Werkzeuge gestellt werden. Blender, die windige "Patentrezepte" anbieten, müssen erkannt und diesen aus dem Weg gegangen werden. Seriöse Hilfe sollte natürlich auf Basis der eigenen Erkenntnisse in Anspruch genommen werden.

Es ist festzustellen, daß die Objektorientierung die Datenmodellierung nicht obsolet macht, sondern einer Verbindung beider in einem neuen Gewand die Zukunft gehört. Auf diese Weise wird die Datenmodellierung kein Papiertiger, sondern ein Werkzeug zur Beherrschung der Komplexität.