Zur Datenmodellierung

Einführung

Stellen Sie sich vor, Sie sollen die Daten für eine Analyse des Verhaltens von Kunden zusammensuchen und aufbereiten. Es gibt dazu viele möglichen Datenquellen, und auch viele Dokumente. Sogar ein unternehmensweites Datenmodell ist vorhanden. Aber irgendwie werden Sie aus all dem nicht so richtig schlau, und Sie beginnen sich bei den verschiedenen Experten durchzufragen. Kennen Sie diese Situation?

Oder: Die Fachabteilung erstellt eine Spezifikation. Sie beschreibt die Situationen, die zu den verschiedenen Konstellationen in den Daten gehören, und wie die Daten dann zu verarbeiten sind. Wieviel wesentliche Fälle (ohne Datenfehler) wird sie dabei vermutlich übersehen. Wieviel Anläufe wird sie für eine halbwegs vollständige Beschreibung brauchen?

Es gibt verschiedene Gründe, warum es in vielen Unternehmen praktisch unmöglich ist, richtige und vollständige Informationen über die vorhandenen Daten, ihre Organisation und die genaue fachliche Spezifikation nachzulesen. Zu den wichtigsten gehören:

• Information Hiding: Aus verschiedenen Gründen behalten Mitarbeiter ihr Wissen für sich und geben auf Nachfrage vor allem mündliche Erklärungen und Auskünfte.
• Projektorganisation: Wenn die Datenbestände in einem Unternehmen vor allem durch die Anwendungsentwicklung und andere anwendungsbezogene Projekte entstehen, steht die Beschreibung der Daten in Fachkonzepten und anderen projektbezogenen Dokumenten.. Ein Interesse, diese Informationen systematisch für andere potentielle Konsumenten der Daten aufzubereiten, entsteht in der Regel nicht.
• Taylorisierung: Eng zugeschnittene Kompetenz- und Verantwortungsbereiche führen dazu, dass sich niemand einen vollständigen, integrierten Überblick über einen Teilbereich erarbeitet.
• Ungenügende Methoden und Werkzeuge: Auch wenn die oben angeführten Gründe ausnahmsweise nicht zutreffen, scheitert der Versuch ein technisch sinnvolles und gleichzeitig semantisch gehaltvolles Datenmodell aufzubauen oft daran, dass sich die verschiedenen Zielvorstellungen (oft scheinbar) nicht vereinbaren lassen.

In den folgenden Abschnitten will ich zunächst auf diese Hindernisse für eine gut dokumentierte Datenhaltung eingehen, um dann einige Lösungsvorschläge vorzustellen..

Information Hiding

Wer hat überhaupt ein Interesse, Informationen, die andere bei Ihrer Arbeit unterstützen sollen, schriftlich, vollständig und allgemein zugänglich bereitzustellen? In vielen Unternehmen werden "Experten" belohnt, wenn sie etwas wissen, was nicht jeder weiß. Andererseits legen viele Unternehmen Wert darauf, dass Mitarbeiter austauschbar sind. Was zunächst im Interesse beider Seiten sein könnte, weil nur derjenige, der auf seinem aktuellen Arbeitsplatz ersetzbar ist, auch problemlos wechseln und aufsteigen kann, wird von Mitarbeitern, die wissen, dass nicht jeder aufsteigen wird, als Risiko empfunden. Und viele Versuche, in den erlesenen Kreis der "schwer ersetzbaren Experten" aufzusteigen, beruhen auf der Monopolisierung von "Fakten-Wissen". Verschärft wird dieses Problem natürlich bei befristet Beschäftigten und bei externen Dienstleistern. Im Unterschied zu Spezialisten, die explizit als Know-How-Träger und Coaches Wissen und Methoden vermitteln sollen, erzeugen die Bedingungen für externe Dienstleister zur Unterstützung in Projekten starke Eigeninteressen:

1. In Ausschreibungsverfahren gewinnt das günstigste Angebot. Leistungen die nicht explizit gefordert sind fallen deshalb aus dem Angebot heraus. Aber die Qualität der Pflege von Dokumentationen lässt sich nicht wirksam spezifizieren.
2. Langfristige Kundenbeziehungen können auch entstehen, wenn sich beide Seiten ihrer wechselseitigen Abhängigkeiten bewusst sind. In diesem Fall besitzt der externe Dienstleister einen eigenen, autonomen Kompetenzbereich, in dem er nur schwer ersetzbar ist. Das Wissen um die Daten kann dazugehören.
3. Primärziele, z.B. eine möglichst fehlerfreie Anwendung, Benutzerfreundlichkeit und sichere Transaktionen, lassen sich relativ leicht spezifizieren und kontrollieren. Aber formale Qualitätskriterien allein garantieren weder einen leicht verständlichen Quellcode (wobei man schon darüber streiten kann, wer den Code verstehen soll, jeder Anfänger oder ein Experte) noch verständliche und vollständige Beschreibungen. Eine gemeinsame Praxis mit qualitativ guten Ergebnissen kann nur in einem längeren Lernprozess im Rahmen einer Unternehmens- oder Abteilungskultur entstehen. Deshalb ist es normal, dass externe, die für verschiedene Kunden arbeiten, diese oft informellen Regeln nur unvollkommen ausfüllen können.

Aber selbst, wenn alle Beteiligten ausschließlich an guter Arbeit interessiert sind, gibt es m.E. noch systematische Gründe, die eine vollständige, verständliche und zugängliche Dokumentation des Datenhaushalts in einem Unternehmen verhindern.

Projektorganisation

EDV-Projekte werden häufig, auch unternehmensintern, wie eine Kunden-Beziehung (Auftraggeber-/Auftragnehmer-Beziehung) gestaltet. Im Vordergrund steht dann eine, meist von der Fachabteilung erstellte, Anforderung, in welcher das Verhalten des zu erstellenden oder zu ändernden Systems beschrieben ist. Oft liegt auch die Budget-Verantwortung beim "Auftraggeber". Deshalb wird zunächst gegenüber diesem "Auftraggeber" das tatsächlich implementierte Verhalten des Systems und, für die Entwickler und die Wartung, seine Architektur, sowie der Aufbau der Programme, also z.B. Datenflusspläne, Transaktionen usw., beschrieben: "Wenn in der Maske A in das Feld F eine Zahl eingegeben wird, dann wird diese in der Datenbanktabelle D in der Spalte S gespeichert. In dem Report R werden dann die Werte aus S nach der Spalte K gruppiert zusammengezählt und ausgewertet." Eine solche Beschreibung ist für den Programmierer vollkommen ausreichend, aber außerhalb des Projekts auch vollkommen unbrauchbar, weil auf jeden Ansatz von Beschreibung des Inhalts verzichtet wird. Bei der Dokumentation des Datenhaushalts geht es aber gerade um die vollständige inhaltliche Beschreibung der Daten.

Natürlich gibt es auch eine inhaltliche Beschreibung der verwendeten Daten. Aber das Verständnis von Projekten und Projektergebnissen als Systeme, die mit anderen Systemen kontrolliert interagieren, führt dazu, dass die Sorgfalt vor allem auf die Dokumentation der Schnittstellen konzentriert wird: "In der Maske A trägt der Vertriebsbeauftragte in das Feld F den im aktuellen Jahr erwarteten Umsatz mit dem jeweiligen Kunden ein. Im Report R wird in der Spalte S der erwartete Jahres-Umsatz und in der Spalte U der bisher erzielte Umsatz nach Vertriebsregionen ausgegeben." Damit ist dieser Teil der Anwendung fast vollständig beschrieben. Irgendwer weiß, dass mit Umsatz der Rechnungsbetrag ohne Umsatzsteuer, nach Rabatten aber vor eventuellen Skonti gemeint ist, und das bei der Zielerreichung dieser Betrag aus der jeweiligen Rechnungswährung zum mittleren Kurs des Monats der Rechnungsstellung in Euro umgerechnet wird. Vielleicht steht es auch in einem Fachkonzept, aber mit hoher Wahrscheinlichkeit nicht in einer Schnittstellenvereinbarung: "Das Projekt E erhält monatlich eine Tabelle mit den Spalten K (Verttriebsregion), S (erwarteter Umsatz) und U (erzielter Umsatz). Die Tabelle muss spätestens am zweiten Arbeitstag eines Monats um 8.00 Uhr bereitgestellt werden. ..."

In jedem Unternehmen gibt es (vielleicht) eine zentrale Datenmodellierung, die bei der Qualitätskontrolle auch auf die Einhaltung zentraler Vorgaben zur Modellierung, zu Namenskonventionen und zur konsistenten Verwendung von Namen und Begriffen achtet. Aber sie wird von dem Projekt nur über eine weitere "Schnittstelle" beliefert: in der Regel einem Techniker, der unter großem Zeitdruck arbeitet und froh ist, aus dem verbalen Wust der Anforderung die logischen Zusammenhänge zwischen den Daten halbwegs korrekt verstanden und modelliert zu haben. Und auch sein prüfendes Gegenüber möchte das Projekt sicher nicht durch Pingeligkeit aufhalten.

Diese Verhältnisse lassen sich nur ändern, wenn man die Vorstellung von Fachabteilungen, IT-Projekten und Anwendungen als Systeme, die durch komplexe Beziehungen miteinander vernetzt sind, aufgibt, und sie als abhängige Teile eines Ganzen versteht. Im Rahmen der DWH- bzw. BI-Diskussion könnten Kompetenz-Zentren aufgebaut werden, die eine solche zentral integrierende Funktion wahrnehmen. Die Praxis zeigt aber, dass das eine solche Funktion keineswegs von selbst, mit der Gründung einer Arbeitsgruppe oder Abteilung, entsteht, sondern bewusst aufgebaut und gefördert werden muss.

Taylorisierung

Taylorisierung ist ein Begriff aus dem letzten Jahrhundert und geht auf das Ende des vorletzten Jahrhunderts zurück, als Frederick Winslow Taylor begann, Arbeitsprozesse in der industriellen Produktion systematisch zu erfassen und zu rationalisieren. Dazu gehören klar abgegrenzte Tätigkeits-Beschreibungen und der effiziente Einsatz vorhandener Qualifikationen genauso, wie Vorgehensmodelle mit denen Arbeitsvorgaben systematisch entwickelt und formuliert werden. Das "Wasserfall-Modell" im Software Engineering ist daran orientiert, und die Pseudo-Kundenbeziehung zwischen Fachabteilung und IT trägt ebenfalls dazu bei, dass eine Aufgabenverteilung entsteht, bei der fachliche Aspekte und technische Aspekte verschiedenen Personen zugeordnet werden. Das ist im Grundsatz unvermeidbar. Schließlich muss ein guter Controller nicht auch noch programmieren können, und ein guter Programmierer muss nicht auch noch den Hintergrund einer Buchhaltung oder von Risiko-Kennzahlen verstehen. Warum also soll nicht der auftraggebende Controller einem Business Analysten erklären, was er braucht, der Business Analyst diese Anforderungen dann in eine technische Sprache für einen Architekten übersetzen, welcher daraus wiederum konkrete Module mit Programmiervorgaben entwickelt? Und der Entwickler macht dann aus diesen Vorgaben gut strukturierte Programme.

Das grundsätzliche Problem bei diesem Vorgehen wird vielleicht erst auf den dritten Blick erkennbar: Das Modell stammt aus der industriellen Serienproduktion, wo Arbeiter immer wieder dieselben Produkte, z.B. Waschmaschinen, herstellen. Aber diesen Produkten entspricht nicht die Software, sondern deren Ergebnis, z.B. Reports die regelmäßig erstellt werden, Information die bereitgestellt wird, die Erfassung und Verarbeitung von Bestellungen, Lieferungen, Rechnungen usw.  Die Herstellung der Software ist eher mit dem Aufbau der Fabrik, der Fertigungs-Straßen und Fließbänder, der Anschaffung von Maschinen und der Herstellung der notwendigen Werkzeuge vergleichbar. Und damit ist ein vergleichsweise großer konstruktiver Aufwand verbunden. Um im Bild zu bleiben: Zu der Konstruktion der Waschmaschine kommt die Konstruktion und Herstellung der Mittel, sie rationell zu produzieren. Der Konstruktion der Waschmaschine entspricht die fachliche Definition des Reports: Die in diesem Report (oder Informationssystem) enthaltene Information muss eine sinnvolle und effektive Unterstützung des Empfängers bei seinen Aufgaben sein, so wie eine Waschmaschine die Wäsche mit möglichst wenig Wasser-, Strom- und Waschmittelverbrauch sauber waschen soll. Aber genau so, wie eine Fertigungsstraße für Waschmaschinen in einem komplizierten Prozess entwickelt und aufgebaut wird, sind zur Herstellung des Reports komplizierte Programme notwendig, die einmal "konstruiert" und "aufgebaut" werden. Dazu gehören bei der Waschmaschine Versuche zu Varianten bei der Gestaltung der Maschine selbst genau so, wie Versuche zu der optimalen Fertigungsmethode. Und für den Aufbau eines einen reibungslosen Produktionsprozesses sind viele Kenntnisse, Erfahrungen, aber auch Versuche mit den verschiedenen Werkstoffen, Fertigteilen und Produktionsverfahren erforderlich. Nur beim "Produktionsprozess" für Auswertungen soll dies alles nicht gelten. Da sollen allwissende Facharbeiter endgültige Anforderungen formulieren, die allmächtige Techniker dann planmäßig und fehlerfrei umsetzen.

Wenn man die beiden Bilder vergleicht, fällt auf, dass in der "durchrationalisierten Software-Produktion" nach dem industriellen Vorbild die Pflege von Stücklisten nicht vorgesehen ist. Diesen Stücken entsprächen in der Datenverarbeitung die Daten selbst, nicht irgendwelche "Software-Module" oder "-Dienste". Letzteres wären eher die Maschinen. Den zentralen Teile-Verzeichnissen in SAP entsprächen zentrale Verzeichnisse der Dateien und Attribute, den Stücklisten und "Explosions-Zeichnungen", die zeigen, wie die Teile in einer Konstruktion zusammengesetzt werden, entsprächen die Datenmodelle. Die Datenfluss-Diagramme wiederum entsprechen den Montage-Anleitungen. 

Schon bei der Einzel-Fertigung, einmaligen, komplexeren  Auswertungen wird der Unterschied deutlich: Wenn ein Kunde beim Handwerksmeister einen Tisch bestellt, wird dieser mit großer Sorgfalt eine Konstruktions-Zeichnung erstellen, die richtigen Hölzer aus den Katalogen seiner Lieferanten bestellen, eventuell kontrollieren, ob er Schrauben und Beschläge aus seinem eigenen Lager verwenden kann und schließlich den Tisch zusammenbauen. Die Konstruktionszeichnung, die Stücklisten und die Informationen zu den Lieferanten wird er für den Fall aufbewahren, dass einmal ein ähnlicher Tisch in Auftrag gegeben wird.. Der moderne Softwerker lässt sich eine Skizze erstellen, rennt dann in sein "Lager", um zu sehen, was schon da ist, und wird erstmal versuchen die gefundenen Teile irgendwie sinnvoll zusammenzunageln. Dann schreibt er auf, wie und in welcher Reihenfolge der Tisch zusammengenagelt wurde und welche anderen Bearbeitungsschritte noch erforderlich waren. Wenn er nach ISO 9000 zertifiziert ist, wird er auch noch dokumentieren, wie er geprüft hat, dass der Tisch nur minimal, d.h. vertretbar, wackelt. Vielleicht wird er auch ein Tischbein aus Balsaholz durch eines aus Buche ersetzen, wenn sich herausstellt, dass ersteres zu schwach war. Und in Zukunft wird er wissen, wo er brauchbares Material herbekommt.

Auch in weniger extremen Fällen gibt es auf dem Weg von der Anforderung bis zum fertigen Produkt oft keine Stelle, an der ein Bezug zum Datenhaushalt des Unternehmens systematisch(!) hergestellt würde. Oft werden Daten geprüft, aber wer vorher eine exakte Definition sucht, oder den Unterschied zwischen zwei Datenquellen über Dokumente klären will, verhält sich zumindest merkwürdig. Wichtig ist, dass ein Nachfolger die Programme pflegen kann. Den genauen fachlichen Zusammenhang kennt (und vergisst) der Kollege aus der Fachabteilung. Es reicht doch, wenn er sich bei der Spezifikation etwas gedacht hat.

Methoden und Werkzeuge

Kann es sein, dass kein ernstzunehmender Mitarbeiter eines Unternehmens auf die Idee kommt, eine vollständige integrierte fachliche und technische Dokumentation des Datenhaushalts in seinem Unternehmen zu wollen? Vermutlich nicht, aber denen, die es wollen und versuchen, fehlen offensichtlich die Mittel. Inzwischen glaube ich dafür drei Gründe benennen zu können:

1. Modellierungs-Methoden und -Werkzeuge werden von Technikern für Techniker entwickelt. In dieser Welt existiert eine Spezifikation bevor mit der Arbeit begonnen wird. Das wichtigste Ergebnis ist eine gut aufgebaute Datenbank - wobei die Kriterien für "gut aufgebaut" durchaus variieren. Das Entwickeln einer Spezifikation, die Organisation und das Pflegen der dafür notwendigen Informationen kommen in dieser Welt überhaupt nicht vor. Deshalb gibt es dafür auch keine Methodenlehre, und die Werkzeuge sind bestenfalls zufällig brauchbar, aber keinesfalls optimiert.
2. Modellierungs-Werkzeuge werden für einen Benutzertyp, den Datenmodellierer, seine Anforderungen und Fertigkeiten, entwickelt. Eine vollständige integrierte fachliche und technische Dokumentation des Datenhaushalts in einem Unternehmen hat aber sehr verschiedene "Konsumenten" und wird im Idealfall auch von sehr verschiedenen Mitarbeitern einander ergänzend erstellt und gepflegt. Weder bei der Entwicklung noch bei der Auswahl von Modellierungs-Werkzeugen werden deren Anforderungen berücksichtigt.
3. Wenn Datenmodellierung im Wesentlichen als technische Angelegenheit begriffen wird, entstehen "Sekündärziele", deren Erfüllung zu Lasten der Verständlichkeit und des Informationsgehalts geht. Wenn z.B. die Menge der möglichen Geschlechter oder Familienstände als Entitäten modelliert werden, mag das technisch sinnvoll sein, um eine einheitliche Codierung zu erreichen. Inhaltlich ist es aber etwas vollkommen anderes als die Menge der Kunden, die Menge der Konten oder die Menge der Sicherheiten.

Dabei wäre es m.E. nicht besonders schwer, passende Verfahren und ein dazu passendes Werkzeug zu entwickeln, wenn die verschiedenen Informationen eines Datenmodells nach inhaltlichen Kriterien typisiert und organisiert würden. Beispielsweise kann man eine eindeutige und einheitliche Verwendung von Begriffen auch erreichen, wenn man die möglichen Attribute von Entitäten in einem zentralen Verzeichnis pflegt und dort einmal, vollständig und eindeutig beschreibt. Dann lässt sich auch schnell herausfinden, in welchen Entitäten und denormalisierten Views ein Attribut vorkommt. Über eine differenzierte Rechte-Vergabe und entsprechende Pflege-Masken können verschiedene Benutzergruppen in die Lage versetzt werden, die entsprechenden Teile des Modells und der Dokumentation zu pflegen. und über eine entsprechende Intranet-Anwendung können diese Informationen allgemein zugänglich gemacht werden.

Lösungsansätze

M.E. ist nur eine zentrale, integrierende und gut ausgestattete Organisationseinheit in der Lage, die erforderlichen Informationen zu den Daten in einem Unternehmen zu sammeln und dauerhaft aktuell zu halten. Neben einer zentralen Abteilung, welche in erster Linie für operative Systeme zuständig wäre, und den Aufbau von dispositiven Systemen mit ihren Informationen über die operativ genutzten und gepflegten Daten unterstützen könnte, gibt es mit der im Rahmen von Data Warehouse und "Business Intelligence" aufgekommenen Diskussion um ein "Business Intelligence Competence Center" einen neuen Anlauf, solche Informationen zumindest für Auswertungen zentral und systematisch zu sammeln. Ein solches BICC darf aber nicht wieder als rein technische Veranstaltung von Dienstleistern verstanden werden. Vielmehr müssen m.E. zwei Aspekte berücksichtigt werden:

1. Nur eine zentrale und mächtige Stabs-Stelle ist in der Lage, alle erforderlichen Informationen systematisch zu sammeln und eine konsistente Datenmodellierung in allen Projekten auch gegen Widerstände durchzusetzen. Dabei muss die personelle Besetzung ausreichen, um auch bei Lastspitzen eine angemessene Reaktionszeit bei der Prüfung und Umsetzung von Datenmodellen und Änderungen gewährleisten zu können.

2. Bei der personellen Besetzung ist die Kombination von gutem fachlichem Verständnis und einem fundierten Verständnis der Methoden bei der Modellierung unverzichtbar. Dabei handelt es sich um eine eher seltene Qualifikation. Andererseits lohnt sich der große personelle Aufwand bei der Erstellung von Anforderungen, Grob- und Feinkonzepten. In allen Phasen eines EDV-Projekts können diese Mitarbeiterinnen und Mitarbeiter wertvolle Informationen über die Datenquellen und Zusammenhänge beisteuern und frühzeitig auf unvollständige Spezifikationen oder Widersprüche zu anderen Definitionen hinweisen.

Die so zusammengetragenen Informationen müssen aber auch dezentral, d.h. von den Projekten selbst, zu pflegen sein und allgemein zur Verfügung stehen. Für die Pflege folgt daraus, dass ein mehrstufiges Verfahren von der Eingabe oder Änderung über die Prüfung bis zur Freigabe, und von der Entwicklung über die Abnahme bis zur Produktion erforderlich ist. Natürlich gehört dazu auch eine Benutzerverwaltung mit der differenzierten Vergabe von Rechten. Verfügbar werden die Informationen, wenn sie übersichtlich aufbereitet und sinnvoll zusammengestellt im Intranet für alle zur Verfügung stehen. Wenn Teile des Datenmodells vertraulich sind, ist zusätzlich ein Berechtigungskonzept zur Abfrage erforderlich.

Und jetzt?

Ich denke, dass der "Leidensdruck" mit zunehmender Komplexität größer geworden ist, und es sinnvoll sein könnte, den Nutzen einer solchen zentralen Dokumentation zumindest für Informations-Systeme (Business Intelligence) neu zu überdenken.

Auf diesem Server versuche ich mit einer kleinen Demo zu zeigen, dass und wie die technischen und fachlichen Informationen zum Datenhaushalt eines Unternehmens in einem integrierten System gepflegt, präsentiert und strukturiert werden können. Dabei geht es mir in erster Linie um den praktischen Nachweis, dass solche Informationen verständlich aufbereitet werden können (proof of concept). In zweiter Linie will ich an Beispielen zeigen und begründen, wie man meines Erachtens modellieren bzw. nicht modellieren sollte.

Sie erreichen die Demo über diesen Link: Demo zur Datenmodellierung