Wissensmanagement beim Aufbau eines Data Warehouse

Inhalt

• Zielsetzung
• Das Enterprise DWH als Wissensquelle (konzeptionelle Grundlagen)
• Wissen erfassen und speichern
• Enterprise DWH und DataMart
• Vorteile dieser konzeptionellen Unterscheidung
• Beispiel
• Die Umsetzung mit XDWH
• Das optimierte Tool für die Planung eines SAS-DWH
• Denormalisierung
• Historisierung
• Integrierte Erfassung fachlicher und technischer Spezifikationen
• Unterstützung der Entwickler durch Code-Generierung
• Vollständige Dokumentation in HTML
• Anwendererfahrung

Das Ziel

Die Qualität eines Data Warehouse läßt sich in der Praxis am Aufwand im Betrieb und am Nutzen für das Unternehmen messen. Im Grundsatz reichen hierfür vier Parameter aus:

• Der Aufwand (Arbeit und Rechner-Kapazität) im Betrieb, d.h. der zum regelmäßigen Laden des DWH, für die Erstellung von Data Marts und für Auswertungen erforderlich ist.
• Der Aufwand der zur Pflege des DWH, d.h. zur Anpassung an die Entwicklung des Unternehmens und an neu hinzukommende Anforderungen, erforderlich ist.
• Die Nutzung des DWH durch die verschiedenen Abteilungen im Unternehmen und bei der Entwicklung neuer Anwendungen.
• Der Nutzen, den das Unternehmen aus der verbesserten Informationslage zieht.

Bei der Definition der Ziele gilt es, mehrere Gefahren zu vermeiden:

• Auch wenn zunächst eine einzige Anwendung oder eine Fachabteilung den Anlaß für den Aufbau des Enterprise DWH darstellen, muß das strategische Ziel des Unternehmens, eine abgestimmte universelle Datenbasis für alle dispositiven Systeme zu erhalten, unbedingt erfüllt werden.
• Andererseits dürfen überhöhte Ansprüche an die Allgemeingültigkeit der Lösung sinnvolle pragmatische Wege nicht verstellen.
• Hinzu kommt, daß in vielen Projekten ein "Nutzer-Konzept" für das DWH fehlt. Wenn nur Anwendungen und die Nutzer dieser Anwendungen benannt werden, bleiben die Anforderungen an das DWH selbst abstrakt. Die Komplexität der konkreten Anforderungen an ein DWH geht dann oft verloren.

In diesem Sinn bekommt der Wissensvorsprung, den ein Unternehmen durch die Einführung eines DWH erzielen kann, einen zwei Aspekte:

• Die Daten-Basis, aus der die Informationen gewonnen werden, wird qualitativ und quantitativ verbessert.
• Das Wissen über den Inhalt des DWH und die Bedeutung der Daten im DWH wird verbessert und im Unternehmen verbreitet.

Wissen erfassen und speichern

Beim Aufbau eines Data Warehouse muß sich das Entwickler-Team auch mit einer Vielzahl fachlicher Fragen, Abgrenzungsproblemen, unterschiedlichen Definitionen u.v.a.m., auseinandersetzen und erarbeitet sich häufig ein fundiertes Wissen über die Materie, die im DWH dargestellt wird. Entscheidend für den langfristigen Nutzen eines DWH ist, daß auch dieses "Meta-Wissen" über die Daten systematisch erfaßt und gespeichert wird, damit es nicht mit dem Abschluß des Projekts wieder verloren geht - in Protokollen verschwindet. Um den Aufwand zu minimieren, sollte die Erfassung von fachlichen Informationen in den Aufbau des DWH nahtlos integriert werden. Die einzelnen Schritte sollten so aufeinander abgestimmt werden, daß die Erfassung der fachlichen Aspekte und ihre technische Umsetzung in Modellen und Spezifikationen möglichst gleichzeitig erfolgen. Mit der Speicherung in einer Datenbank (Meta-Daten, Repository) wird sichergestellt, daß diese Eingaben in den folgenden Schritten wiederverwendet und ggf. überarbeitet werden. Am Projektende läßt sich daraus eine vollständige integrierte Dokumentation des DWH mit allen technischen und fachlichen Aspekten erstellen.

Enterprise DWH und Data Mart

Universalität, Flexibilität, Performance und Anwenderorientierung sind Ziele, die sich nicht gleichzeitig erreichen lassen. Deshalb hat es sich durchgesetzt, ein DWH grundsätzlich in zwei Ebenen aufzubauen.

In der ersten Ebene, dem Enterprise DWH, werden die relevanten Daten aus den operativen Systemen für alle dispositiven Anforderungen in einer konsistenten Form aufbereitet. Hier erfolgt die Qualitätssicherung, die Historisierung und die Dokumentation der Daten. Sinnvollerweise werden hier normalisierte Datenmodelle verwendet, um die notwendige Flexibilität für Auswertung sicherzustellen.

In der zweiten Ebene, den Data Marts, werden diese Daten dann für Auswertungen und Anwendungen aufbereitet. Dabei werden häufig denormalisierte Designs und anwendungs-spezifische, z.B. multidimensionale, Modelle verwendet, um die Performance der Systeme zu optimieren.

Sinnvollerweise wird mit dieser Unterscheidung auch ein Perspektivenwechsel bei der Konzeption des DWH verbunden:

• Beim Aufbau des Enterprise DWH ist die Nutzung der Daten per Definition unbekannt. Es ist deshalb nicht sinnvoll, sich hier bereits an existierenden Anwendungen oder Auswertungen zu orientieren. Vielmehr sollten die Daten möglichst so modelliert werden, daß die Entitäten im Modell entsprechende "Objekte" in der realen Welt repräsentieren, z.B. Verträge, Konten, Vertriebsmitarbeiter, Kunden, Marktsegmente. Bei Vernachlässigung des Zeit-Aspekts identifizieren dann die primary keys den einzelnen Vertrag, das Konto, den Vertriebsmitarbeiter etc. Die Attribute enthalten die Informationen, die über das jeweilige Objekt gespeichert werden. Dadurch kann schon am Modell genau abgelesen werden, welche Informationen gespeichert werden, und wie sie mit anderen Informationen verknüpft werden können. Gleichzeitig bleibt der Bezug zur realen Welt erhalten.
• Bei der Erstellung des Data Marts steht dagegen die Anwendung im Vordergrund. Letztendlich müssen hier oft "Berichtspositionen" definiert und verortet werden. Z.B. "Brutto- und Netto-Umsatz werden nach Produkten, Regionen, Vertriebsorganisationen und Kundengruppen dargestellt". Die Fakten, Brutto- und Netto-Umsatz, müssen genau definiert und die Dimensionen, Produkte etc., müssen erstellt werden. Wenn das Enterprise DWH der "realen Welt" entspricht, werden schon durch die Aufbereitung des Data Marts alle Positionen genau und transparent beschrieben. D.h. es wird nachvollziehbar, wie eine Zahl im EIS-System durch Ereignisse in der realen Welt entstanden ist.

Mit dieser Vorgehensweise werden eine Reihe großer Probleme, die sonst häufig in DWH-Projekten auftreten vermieden:

• Beim Versuch, bereits das Datenmodell für das Enterprise DWH mit Starscheme- oder Snowflake-Ansätzen zu entwickeln, scheitern viele Projekte an der Unmöglichkeit, ein unternehmensweit einsetzbares Dimensionen-Gerüst zu entwickeln. Dafür gibt es einen systematischen Grund: Mit solchen Ansätzen wird versucht, eine auswertungsorienterte Sicht auf die Daten zu erstellen, und die Transformation in Reporting- bzw. Analyse-Größen bereits in die Ladeprozesse zu stecken. In jedem realen Unternehmen gibt es aber immer mehrere Sichtweisen, die nebeneinander ihre Berechtigung haben.
• Mit dem hier empfohlenen Ansatz ist es nicht notwendig, schon bei der Erstellung des Enterprise DWH die Menge der möglichen Anwendungen und Auswertungen zu kennen und zu berücksichtigen. Es muß kein globales Konzept zur Beschreibung des Reportings (und der Analysen) entwickelt werden. Vielmehr entstehen kleinere und deshalb leichter zu bearbeitende Aufgaben, was auch das gesamte Projekt wesentlich beschleunigt.
• Die einfachere Struktur und die Nähe zur "realen Welt" führt zu einem "zukunftssicheren" Modell, das leicht erweitert und angepaßt werden kann. Insbesondere wird eine, oft zu spät erkannte, implizite Spezialisierung auf die erste Anwendung vermieden.

Eindeutigkeit und Einheitlichkeit spielen vor allem in den Unternehmen eine besondere Rolle, die bisher kein unternehmensweites Datenmodell implementiert oder in den operativen Systemen nur teilweise umgesetzt haben - also in der weit überwiegenden Mehrzahl aller großen Unternehmen. Aber auch wenn ein unternehmensweites Datenmodell für den operativen Bereich existiert, geht daraus oft nicht hervor, welche Daten in welchem fachlichen Kontext berichtenswert sind.

Ein eigenes DWH-Modell hat den Vorteil, daß genau die Entitäten und Attribute angegeben und definiert werden, die für dispositive Anwendungen und Berichte benötigt werden. Dabei fördert die systematische Verknüpfung von fachlicher Spezifikation und technischer Umsetzung die Umsetzung klassischer Design-Prinzipien. Gleiches wird gleich benannt und im gleichen Format gespeichert. Verschiedenes wird auch unterschiedlich benannt.

Beispiel

Das folgende (frei erfundene) Beispiel zeigt, wie bei dieser Art der Modellierung die Besonderheiten eines Unternehmens dargestellt werden.

Das Unternehmen ist offensichtlich in der Lage, Kunden einem Haushalt zuzuordnen. "Firmen-Kunden" können erkannt und ggf. Einem Konzern zugeordnet werden. Allerdings sind Verflechtungen, d.h. Beteiligungen unter 50% offensichtlich nicht zugänglich. Auch können "Privat-Kunden" nicht als Inhaber von Unternehmen erkannt werden.

Die Bedeutung von "Unternehmen gehört zu Konzern" würde in einem Kommentar zu diesem Bereich noch genauer definiert.

Verträge und Vertrieb sind in diesem Chart nur soweit dargestellt, wie es für die Erläuterung der Beziehungen erforderlich war. Man erkennt aber die komplizierte Struktur. Offensichtlich fehlt hier ein Konzept zur Betreuung von Haushalten und Firmen.
 

Das optimierte Tool für die Planung eines SAS-DWH

Ein solches Konzept steht und fällt mit der Qualität, d.h. der Richtigkeit und der Vollständigkeit, der Dokumentation. Allerdings ist die manuelle Erstellung und Pflege einer solchen Dokumentation sehr aufwendig, weil die Informationen zu den einzelnen Elementen nicht in der Reihenfolge bekannt werden, wie sie für die Modellierung und Dokumentation benötigt werden. Je nach Fragestellung müssen die einzelnen Elemente auch immer wieder neu kombiniert werden.

XDWH wurde speziell dafür entwickelt und optimiert, jede einzelne Information genau dann zu erfassen, wenn sie erstmalig bekannt wird, und strukturiert abzuspeichern. Die Verknüpfung von technischer und fachlicher Information ermöglicht es, aus derselben Quelle die vollständige Modelldokumentation und Teile des DWH automatisch zu erzeugen. Dadurch wird sichergestellt, daß Dokumentation und technische Umsetzung übereinstimmen. Darüber hinaus wurde versucht, die Anbindung zur technischen Umsetzung so komfortabel zu gestalten, daß der Mehraufwand für die Dokumentation minimiert wird, wenn vor der technischen Umsetzung zuerst die Dokumentation in XDWH gepflegt wird.

Ein wichtiger Grund für die Entwicklung von XDWH war auch die vollständige Unterstützung des SAS-Systems und der SAS-Datenhaltung. Benutzerdefinierte Formate und Informate haben im SAS-System einen besonderen Stellenwert. Sie können manuell erstellt oder aus Dateien automatisch erzeugt werden und sind wichtige Attribute bei der Deklaration von Variablen. Deshalb müssen sie auch im DWH-Modell entsprechend dokumentiert werden.

Denormalisierung

Für die Umsetzung des oben beschriebenen Konzepts ist es unverzichtbar, daß als Teil des Modells beschrieben werden kann, wie die Daten für Auswertungen und Reports zusammengeführt, also denormalisiert, werden. Die Denormalisierung spielt in der Planungsphase als logischer Schritt zur Überprüfung der Vollständigkeit, z.B. "welche Informationen sind über einen Kunden verfügbar", eine wichtige Rolle. Darüber hinaus läßt sich die Erstellung von Data Marts als Denormalisierung der Enterprise DWH-Tabellen darstellen.

Historisierung

Ein besonderes Problem bei der Modellierung eines DWH ist die Behandlung der Zeit. Manche Informationen, z.B. Vertragsmerkmale, sind über lange Zeiträume gültig, andere, z.B. Kontensalden, nur an einem Stichtag. Bei einer "normalen" Modellierung würde im Beispiel eine 1-zu-n-Beziehung zwischen Vertragsdaten und Kontensalden modelliert, auch wenn zu einem Vertrag genau ein Konto gehören würde. Zwischen Inhaberdaten und Vertragsdaten würde möglicherweise sogar eine n-zu-m-Beziehung modelliert, obwohl ein Vertrag genau einen Inhaber hat. Durch diesen Effekt der Zeit würde das ER-Modell einen wesentlichen Teil seines Informationsgehalts verlieren.

Deshalb wird in XDWH genau ein Stichtag modelliert. Die Zeit und ihre Behandlung werden als Eigenschaften der Tabellen gespeichert. Die Daten in einer Tabelle können

• einen Gültigkeits-Zeitraum haben (von-bis),
• an einem Stichtag gültig sein (z.B. Salden),
• über ein Intervall summiert sein (z.B. Umsätze).

Integrierte Erfassung fachlicher und technischer Spezifikationen

Mit XDWH werden fachliche und technische Spezifikationen integriert erfaßt und gespeichert. D.h. daß jede fachliche Definition einem technischen Element, einer Variablen, einer Datei, einem Format, einem (geplanten) Programm, zugeordnet wird. Damit wird eine genaue fachlich Definition der einzelnen Elemente erreicht. Zusätzliche Hinweise, z.B. zur Prüfung der Datenqualität, können mehreren Elementen zugeordnet werden.

In der Dokumentation werden diese Einzelinformationen dann kombiniert. Z.B. sind aus der Dokumentation einer Datei auch alle Informationen zu den Variablen und alle Hinweise zu Variablen, die in dieser Datei verwendet werden abrufbar.

Unterstützung der Entwickler durch Code-Generierung

In der Praxis ist es meistens sinnvoll, Prüf- und Lade-Programme "von Hand" zu schreiben. Code-Generatoren können nur in seltenen einfachen Fällen optimale Programme erstellen.

Die Übereinstimmung von Dokumentation und realisiertem DWH läßt sich aber am besten dadurch sichern, daß der Code zur Erstellung der Dateien, D.h. das DATA-Statement mit den Index-Definitionen und das ATTRIB-Statement zur Deklaration der Variablen automatisch erzeugt werden. Auch der Code zur Erstellung von SAS-Formaten und Informaten aus Dateien läßt sich maschinell gut erzeugen.

Beides wurde in XDWH umgesetzt, um die Akzeptanz des Aufwands für die Pflege der Dokumentation durch den Entwickler zu unterstützen.

Vollständige Dokumentation in HTML

Die gesamte Dokumentation des DWH läßt sich per Knopfdruck vollautomatisch im HTML-Format erstellen. Gerade bei Dokumenten, die im Unternehmen verteilt werden sollen, ist die Gefahr, daß gedruckte Dokumentationen veralten und veraltete Dokumentationen benutzt werden, besonders groß. Deshalb sind m.E. Ausdrucke nur für Meetings sinnvoll. Die aktuelle Dokumentation sollte dagegen in elektronischer Form leicht erreichbar vorliegen.

Der besondere Vorteil des HTML-Formats besteht darin, daß sich die einzelnen Seiten beliebig verknüpfen lassen. Statische HTML-Seiten benötigen keine zusätzliche Software zur Verteilung und können mit jedem Browser geöffnet werden. Mit einem Intranet-Server ist die Verbreitung der Informationen besonders einfach. HTML-Seiten, z.B. zur Dokumentation eines Data Mart oder einer Anwendung, lassen sich auch leicht erstellen und können dann Verweise auf einzelne DWH-Dokumente enthalten.

Im einzelnen umfaßt die Dokumentation eines DWH Übersichten, in denen z.B. auch mit der Such-Funktion des Browsers gesucht werden kann, und detaillierte Beschreibungen der einzelnen Elemente.

Folgende Übersichten werden generiert:

• Liste aller Bereiche (Themen, Ladeprozesse, Data Marts, s.u.)
• Dateilisten (gesamt und nach Typen, z.B. DWH, Quelldateien, Data Marts)
• Variablenlisten (gesamt und nach Typen)
• Liste aller Formate
• Liste aller Programme
• Verzeichnis aller Probleme und Hinweise

• Bereiche: Themenorientierte Zusammenstellungen von Dateien und evtl. Programmen und Formaten zur Beschreibung einzelner Bereiche im DWH (Kunden, Vertrieb, spezielle Themen), der Ladeprozesse und von Data Marts. Sie können ER-Charts oder Datenflußdiagramme enthalten.
• Dateibeschreibung: Fachliche Beschreibung des Inhalts, Liste aller Variablen, Verzeichnis aller Programme, die auf diese Datei zugreifen, Liste der Denormalisierungen, in denen diese Datei verwendet wird. Bei Denormalisierungen wird zusätzlich eine HTML-Datei erstellt, in der die Quellen, die Art der Verknüpfung und das Mapping von Variablen dokumentiert ist.
• Variablenbeschreibung: Fachliche Definition der Variablen, Liste aller Dateien, in denen diese Variable verwendet wird.
• Formatbeschreibung: Beschreibung des benutzerdefinierten Formats, ggf. Quelldatei und Optionen zur Erstellung, Verwendung bei Variablen. Durch die konsequente Verwendung von benutzerdefinierten Formaten für verschiedene Inhalte entstehen z.B. Listen für Geldbeträge und Zinssätze.
• Programmbeschreibung: Fachliche Beschreibung der Funktion, Liste aller Dateien die von diesem Programm gelesen oder geschrieben werden.
• Probleme und Hinweise: In allen vorgenannten Beschreibungen gibt es ggf. zusätzliche Verweise auf "Probleme und Hinweise". Hier werden Informationen abgelegt, die auf mehrere Elemente zutreffen. Dazu gehören z.B. auch die Ergebnisse von Daten-Tests und Hinweise zur Behandlung von Sonderfällen und Datenfehlern.

1. Wir haben eine effiziente Methode eingeführt um mit externen Entwicklern zusammenzuarbeiten. Durch unseren Ansatz, die Eingabe in XDWH vom Entwickler ausführen zu lassen und das Ergebnis in HTML zu überprüfen, wurde die Qualität der Zusammenarbeit und der Ergebnisse wesentlich verbessert.
2. Durch diese Art der Modellierung wurden uns schwierige Details frühzeitig bewußt, und wir konnten sie in vernünftiger Weise und in kurzer Zeit handhaben.
3. Dank der Dokumentation haben wir eine gemeinsame Terminologie und ein gutes Verständnis des Unternehmens und seiner Besonderheiten entwickelt.
4. Durch den einfachen Zugriff auf die Dokumentation wird unsere tägliche Arbeit unterstützt.
5. Am Anfang war es ziemlich schwierig, die angemessenen fachlichen Informationen in ausreichendem Maße in das Modell einzutragen. Es ist sehr wichtig, daß jemand, der an der Entwicklung nicht beteiligt ist, die Dokumentation auf Vollständigkeit und Verständlichkeit prüft.
6. Die Pflege des Modells ist sehr einfach geworden. Während der Entwicklung mußten Entscheidungen mehrfach revidiert werden. Das relationale Modell und das Tool machten es sehr einfach, diese Änderungen einzupflegen und ihre Konsequenzen zu überblicken.

XDWH wurde unter anderem auch bei der Deutschen Bank in der Planungsphase zum "Local Reporting Instrument" eingesetzt. (Vgl. hierzu: "Der WS-Web-Reporter im LRI der Deutschen Bank")