IM FOKUS: DESIGN & MANAGEMENT VON DATA WAREHOUSES

Transkript

1 10 IM FOKUS: DESIGN & MANAGEMENT VON DATA WAREHOUSES Step by Step Zehn Schritte für ein erfolgreiches Data Warehouse Design IM FOKUS: DESIGN & MANAGEMENT VON DATA WAREHOUSES Data Warehouse Technologie bildet heute in den meisten Unternehmen die Grundlage für Entscheidungsunterstützungssysteme und analytische Intelligenz. Auch neue Konzepte wie Business Performance Measurement (BPM) beruhen auf der Existenz einer unternehmensweit integrierten, konsolidierten Datenbasis in einer für Business Intelligence optimierten Aufbereitung. Dennoch ist vielfach immer noch nicht klar, welches nun der beste Weg ist, die Anforderungen von Business Intelligence Anwendungen (BI) zu erheben, und in ein adäquates Data Warehouse Design umzusetzen. Konsens herrscht im Allgemeinen darüber, dass der Aufbau eines Data Warehouse durch fachliche Fragestellungen getrieben sein soll und nicht durch die zur Verfügung stehende Technologie. Aber damit ist das eigentliche Vorgehen leider auch nicht geklärt. Dieser Artikel stellt ein aus vielfachen Projekterfahrungen entwickeltes Vorgehen der saracus consulting vor, das immer wieder überzeugende Ergebnisse erzielt. Der erste Ansatzpunkt ist, die Anforderungen nach bestimmten Kategorien zu untersuchen: Bestimmung der Use Cases Definition des Datenhaushaltes Erhebung der Anforderungen an Analyse- und Berichtslayout Anforderungen an Toolfunktionalität Zusätzlich müssen natürlich einschränkende Rahmenbedingungen erfasst werden. Bestimmung der Use Cases Das hört sich erst mal kompliziert an, ist in vielen Data Warehouse-Projekten aber von vornherein fokussiert: meistens auf OLAP (OnLine Analytical Processing) und Reporting, dabei mit den Facetten ad hoc Analyse, Standard-Reporting und vielleicht Management-Reporting (oder anderen speziellen Sichten). Es geht hier also um die Frage der Einsatzszenarien der geplanten Data Warehouse-Lösung. Solange die Fachbereiche dabei an multidimensionale Analysen und/oder SQL-basierte Abfragen mit der entsprechende Ergebnisanzeige denken, haben wir sozusagen den Normal-Fall. Wollen die Anwender aber auch Planzahlen erfassen können wie etwa für die Vertriebsplanung? Oder sollen Kundenverhaltensmuster aufgedeckt werden, beispielsweise durch Data Mining? Das sind sicherlich keine exotischen Anforderungen aber dennoch eher die Spezial-Fälle. Außerdem ergeben sich daraus später gleich mehrere Use Cases, die genau spezifiziert werden müssen, um angemessene Analysewerkzeuge auszuwählen. Vor allem aber hängt vom jeweiligen Use Case das grundsätzliche Design der auswertungsoptimierten Datenbestände ab. Die Bestimmung der Use Cases ist meist aus dem eingereichten Fachkonzept des Fachbereichs herauslesbar und kann in Form von Use Case Diagrammen oder Actor-Interaktionsdiagrammen dokumentiert werden (Bild 1).

2 IM FOKUS: DESIGN & MANAGEMENT VON DATA WAREHOUSES 11 3) In welchem Detaillierungsgrad (Granularität) wird jeder der Kennzahlen für die Analysen benötigt? 4) Welche Dimensionen ergeben sich aus der Granularität für den Business Case? 5) Welche Attribute und Hierarchien werden für die Auswertung der Kennzahlen benötigt? 6) Welche Anforderungen an Historisierung und Versionierung gelten? In einer Kurzfassung könnte das Ergebnis also wie folgt aussehen: Business Case: Erlösrechnung für die Artikelabverkäufe der Verkaufsfilialen Bild 1: Use Case Diagramm dokumentieren Einsatzszenarien der geplanten Data Warehouse-Lösung. Definition des Datenhaushalts Wenn der oder die Use Cases definiert sind, kann man mit der Erhebung der Anforderungen an den Datenhaushalt beginnen und damit die ersten Eckpfeiler des Data Warehouse-Designs festlegen. Der Begriff Datenhaushalt wird hier als Klammer für alle Datenobjekte benutzt, die später bei der Analyse von Relevanz sind und in unterschiedlichen Ausprägungen an verschiedenen Stellen im Data Warehouse realisiert werden. Um das Vorgehen zur Definition des Datenhaushalts zu beschreiben, soll in diesem Artikel der Fokus auf OLAPund Reporting Anwendungen gelegt werden. Damit ist für den Design-Prozess auch das Ziel definiert: Business Analysten oder Modellierer führen die Erhebung des Datenhaushalts üblicherweise in einem Prozess durch, der mit einem zweitägigen Workshop beginnt. In diesem Workshop, bei dem alle betroffenen Fachbereiche vertreten sein sollten, werden von einem zehnstufigen Vorgehen sechs Stufen beziehungsweise Fragen abgearbeitet: 1) Welcher Geschäftsvorfall (oder Business Case) soll modelliert werden? 2) Welche steuerungsrelevanten Kennzahlen beinhaltet dieser Business Case? Kennzahlen: Menge je Artikel, Verkaufsumsatz, rechnerischer Kostensatz Granularität: pro Artikel, pro Tag, pro Filiale, pro Einkäufer Dimensionen: Artikel, Zeit, Verkaufsorganisation, Einkaufsorganisation Attribute: zum Beispiel Artikelname, EAN, Warengruppe, Hersteller, Lieferant, Preis..., Hierarchie: Warengruppe > Artikelgruppe > Artikel Historisierung: sechs Monate auf täglicher Basis, danach 30 Monate auf monatlicher Basis Versionierung: Verkaufsorganisation soll aus heutiger Sicht dargestellt werden, Einkaufsorganisation aus historisch richtiger Sicht. Aus Sicht der Datenmodellierung soll die Erhebung zu einem Datenmodell im Stil eines Star- oder Snowflake- Schema führen (oder Mischformen). Aus Sicht des Analysewerkzeuges soll die Erhebung zum Business Layer, zum Cube-Design oder zur Report-Objekten führen. Der erste Schritt zur Abstimmung der Anforderungen an den Datenhaushalt führt aber zunächst zu einem Business Modell, mit dem versucht wird, den aktuellen Business Case multidimensional abzubilden. Bild 2: Modellierungsergebnis im CASE-Tool.

3 12 IM FOKUS: DESIGN & MANAGEMENT VON DATA WAREHOUSES Vor dem Workshop sind gerade die Projektleiter aus der IT skeptisch, ob denn dieser Workshop zielführend sei und man es verantworten könne, die Ressourcen des Fachbereichs für zwei Tage einzufordern. Doch für den Workshop und die gleichzeitige Beteiligung aller Betroffenen spricht die Erfahrung aus vielen saracus Modellierungsprojekten. Erst der Workshop zeigt den späteren Data Warehouse-Anwendern, wie uneinheitlich ihre fachlichen Sichten untereinander sind und welcher Konsolidierungsbedarf dabei entsteht. Einzelinterviews als Alternative würde zu mehreren individuellen Befragungsrunden führen, die letztendlich mehr Zeit kosteten und auch Abstimmungsrunden mit allen Beteiligten bedürften. Was passiert nun in diesen Workshops? Der Business Case (Frage 1) wird an einer Tafel oder auf dem Flip-Chart durch zwei bis drei Sätze beschrieben. Diese Frage dient dazu, den Fokus zu finden, Aspekte auszugrenzen und zu erarbeiten, ob es überhaupt allen Personen um den gleichen Business Case oder eventuell mehrere geht. Die weitere Dokumentation der Fragen zwei bis sechs wird meist mit einem Case-Tool durchgeführt. Auch hier hat sich gezeigt, dass Teilnehmer ohne Modellierungserfahrung leicht die Notation multidimensionaler Modelle verstehen, wenn man sich auf Attribute, Entitäten, Beziehungen und Schlüsselkennzeichnung beschränkt (Bild 2). Welche Schwierigkeiten ergeben sich im Workshop? Zunächst scheint es oft gar nicht so einfach zu identifizieren, was denn nun die auswertungsrelevanten Kennzahlen sein sollen. Im Sprachgebrauch in Unternehmen wird leicht jede Zahl, die in einer Auswertung auftaucht, zu einer Kennzahl. Als hilfreich hat sich folgende Definition erwiesen: Kennzahlen sind die Zahlen, die für den Auswertenden die Meßlatte für den Erfolg darstellt. Die Zahlen von denen man möchte, dass sie sich über die Zeit ändern. Die nächsten Schritte im Workshop führen zur Beschäftigung mit der Granularität und Dimensionalität jeder Kennzahl. In den meisten Business Cases haben die Kennzahlen nicht alle die gleiche Granularität und Dimensionalität. Dadurch werden die Kennzahlen auf mehrere Fakttabellen-Kandidaten verteilt. Wichtig ist in diesem Schritt, wie auch bei der folgenden Definition von Attribut-Hierarchien, m:n-beziehungen zwischen Entitäten aufzudecken und möglichst zu beseitigen. Die Diskussion über Versionierungsanforderungen ist dann noch mal eine Herausforderung an die Konzentrationsfähigkeit der Workshop-Teilnehmer. Die Problematik ist nicht leicht zu verstehen und oft haben die Teilnehmer widersprüchliche Anforderungen. Bild 3: Phasen der Modellierung. Zur Verdeutlichung hier ein Beispiel: Eine Versicherung schließt die Regionalvertretung Lüneburg zum Ein Teil der Versicherten wird zukünftig bei der Vertretung Hamburg, der andere Teil in Hannover geführt. Dann stellt sich aus fachlicher Sicht die Frage der Versionierung für die Geographische Zuordnung der Versicherten. Die Tabellen (Variante 1 und 2) zeigen die mögliche Ergebnisdarstellung im Report abhängig von der gewählten Versionierung. Beide Sichten können zu problematischen Interpretationen führen. Bei Variante 1 freut man sich bei einem Vorjahresvergleich über den Vertriebserfolg der Hamburger und Hannoveraner, obwohl eigentlich kein Erfolg erzielt wurde. Bei Variante 2 hat es Lüneburg quasi nie als Regionalvertretung gegeben! Die Fachbereiche müssen hier entscheiden, welche Sicht für sie richtiger ist. Eventuell resultieren daraus zwei Dimensionen, eine versionierte und eine nichtversionierte. Die Ergebnisse der Fragen 1 bis 6 werden am besten wie ein Snowflake- Schema dargestellt. Jeder Hierarchielevel erhält mit seinen Attributen eine eigene Dimensionstabelle, die Dimensionen sind vorerst normalisiert und die Tabellen werden entlang der Hierarchie verknüpft (siehe Bild 2). Wobei man gestehen muss, dass nicht alle Anforderungen multidimensional modelliert werden können. Mit den Ergebnissen des Workshops führt der Modellierer erste Qualitätssicherungsmaßnahmen durch. Anhand bestehender Berichte wird überprüft, ob Anforderungen übersehen wurden. Untersuchungen der Quelldaten sollen Widersprüche zu den Modellierungsergebnissen aufzeigen und Mengengerüste liefern. Danach wird es weitere mehrstündige Treffen mit den Workshop-Teilnehmern geben, um offene Fragen und Widersprüche zu klären. Dabei werden auch die Fragen sieben bis zehn des Vorgehens diskutiert: 7) Ist jede Dimension so homogen, dass alle Attribute in einer Tabelle gespeichert werden sollten?

4 14 IM FOKUS: DESIGN & MANAGEMENT VON DATA WAREHOUSES 8) Welche Aggregationslevel sind bezogen auf die Dimensionen erwartbar? 9) Welche Ladezeitfenster stehen zur Verfügung und welche Dringlichkeit besteht für das Laden der Daten? 10) Welche Anforderungen an Datenschutz und Berechtigungen existieren? Je nach Komplexität kann das Business Modell nach zwei bis vier Wochen fertig abgestimmt und abgenommen vorliegen. Dann schließt sich die Phase der logischen Modellierung an. Logische Datenmodellierung und Performanz Die Kernaufgabe der logischen Modellierung besteht darin, die Dimensionen zu Dimensionstabellen und die Kennzahlen zu Fakttabellen werden zu lassen und dabei Aspekte wie Performanz und Tooleinsatz zu berücksichtigen. Die Kernaktivität ist dabei, einen angemessenen Grad der Normalisierung oder Denormalisierung zu finden. Für die logische Modellierung kann man einige grobe Regeln formulieren: Für die Abfrage-Performanz wäre ein Star-Schema am besten. Pro Fakttabelle gibt es für jede Dimension auch nur eine Tabelle. Anzahl Versicherte im Jahr 2003 im Jahr 2004 Hamburg Hannover Lüneburg 300 Variante 1: mit Versionierung die historisch richtige Sicht. Anzahl Versicherte im Jahr 2003 im Jahr 2004 Hamburg Hannover Lüneburg Variante 2: keine Versionierung es gilt die Sicht von heute. Von Fakttabellen mit Daten auf Tagesbasis (oder anderen großen Fakttabellen) werden Aggregationstabellen angelegt, um Abfragen zu beschleunigen, die nicht auf Detaillevel stattfinden. Dadurch lässt sich aber der Wunsch nach einem Star-Schema nicht durchhalten, da Dimensionstabellen für die Aggregationstabellen entsprechend der Granularität der Aggregation aufgesplittet werden müssen. Fakten aus verschiedenen Fakttabellen dürfen nicht in eine zusammengelegt werden, wenn der Datensatz beim Laden nicht vollständig vorliegt. Das ist meist für eine Supply-Chain relevant. Kennzahlen zu Bestellung, Lieferung und Rechnung können nicht in einer Fakttabelle sein, wenn man mit dem Laden nicht bis zur Bezahlung warten will. Wären sie in einer Fakttabelle, müsste man die Datumsangaben zu Lieferung, Rechnung usw. später aktualisieren. Mehrere Minidimensionen, die nur aus einer Code- und einer Beschreibungsspalte bestehen, können durch Ausmultiplikation zusammengelegt werden. Sind in einem Modell mit mehreren Fakttabellen Abfragen auf mehrere Fakttabellen gleichzeitig zu erwarten, benötigen manche Tools eine gleiche Dimensionalität, um Ergebnisse liefern zu können. Teilweise müssen Fakttabellen also um Dimensionen erweitert werden, die aus anderen Fakttabellen stammen. Wenn Fakten aus Business-Sicht rückwirkend geändert werden können, wird eine zusätzliche Fakttabelle benötigt. Eine Fakttabelle stellt die Daten laut dem ursprünglichen Laden dar, die andere Fakttabelle aus heutiger Sicht. Bild 4: Das Ergebnislayout. Soll das logische Modell auf einer relationalen Datenbank realisiert werden, müssen zusätzlich jetzt die physischen Parameter wie Feldformate, Datentypen usw. definiert werden. Bei einer multidimensionalen Datenbank ist die logische Modellierung sehr Anbieter-spezifisch. Falls man sie überhaupt so bezeichnen möchte, meint sie in diesem Kontext die Übersetzung des Business Modells in Cube-Strukturen, auf deren Basis dann die Cubes geladen

5 16 IM FOKUS: DESIGN & MANAGEMENT VON DATA WAREHOUSES werden können. Letztendlich geschieht aber hier ähnliches, nämlich die Anpassung des Business Modells für das Tool und die Performanz (Bild 3). Erhebung der Anforderungen an Analyse- und Berichtslayout Für Business Intelligence ist zwar der zur Verfügung stehende Datenhaushalt grundlegend, aber auch die Anforderungen an die Analyse und Darstellung der Ergebnisse müssen erhoben werden. Zusätzlich sind diese Anforderungen auch unter dem Aspekt zu untersuchen, ob die zukünftigen Analysen und Berichte Daten enthalten, die besondere Modellierungslösungen erfordern. Oft betrifft das beispielsweise Berichtsmetadaten, wenn Abfragedatum oder Berichtsersteller im Bericht angezeigt werden sollen. Außerdem dienen die Anforderungen zur Qualitätssicherung des Datenhaushalts. Schließlich muss jedes Feld, dass in einem Bericht angezeigt wird, vorher im Datenhaushalt definiert worden sein (Bild 4). Anforderungen an Toolfunktionalität Dieses ist dann der letzte Punkt der Erhebung der Anforderungen mit potenziellen Design-Konsequenzen. Es gibt dabei die beiden grundlegenden Situationen schon ein OLAP- oder Reporting- Werkzeug im Unternehmen im Einsatz zu haben oder nicht (beziehungsweise Vorgaben für eine Auswahl zu haben). Werden die Anforderungen der Nutzer erhoben, um Kriterien für eine Toolauswahl zu generieren, spielt der Datenhaushalt dabei eine wichtige implizite Rolle. Beispielsweise wird daraus abzuleiten sein, inwieweit die Anforderungen durch ein OLAP-Tool mit multidimensionaler Datenhaltung (MOLAP- Tool) oder durch ein Werkzeug, das relationale Abfragen generiert (Relational OLAP, Desktop OLAP, Reporting), erfüllt werden können. Ist das OLAP-Tool vorgegeben, definiert es durch seine Möglichkeiten und Beschränkungen Modifikationen am logischen Modell. Es gibt je nach Tool Vorgaben für die Modellstruktur wie etwa im Sinne von Star- oder Snowflake-Präferenzen, Namenskonventionen, Möglichkeiten bei der Aggregat Navigation oder auch Beschränkungen der Dimensionalität oder der Anzahl Fakttabellen. Zusammenfassend kann man sagen, dass die meisten Unternehmen ein bis zwei Tools einsetzen, um die Bandbreite der Anforderungen zwischen Adhoc Analyse und Standardreporting mit entsprechenden Verteilmechanismen abzudecken. Ebenso führen die meisten Modellierungsanforderungen zu einem relationalen Data Mart mit einem multidimensionalen Modell als Mischform zwischen Star- und Snowflake- Schema. Wichtig beim Data Warehouse- Design ist es, keine Schritte zu überspringen und immer auch ein wenig in die Zukunft zu schauen. Der Modellierer sollte immer wieder alle Anforderungen auf ihre Steuerungsrelevanz überprüfen und das Ziel haben, die Modelle möglichst übersichtlich zu gestalten. Volker Wutschik