Ein Data-Warehouse (DWH) ist eine Lagerhalle für Daten mit dem Ziel, die Daten so zu lagern bzw. zu strukturieren, dass diese möglichst einfach ausgewertet werden können. Damit können Kennzahlen gewonnen werden, mit denen das Business intelligent kontrolliert und gesteuert werden kann. Daher spricht man von Business Intelligence oder BI. Dabei ist das Erheben und Darstellen der Anforderungen, sprich der business-relevanten Kennzahlen, oft der Knackpunkt. Dieser Artikel stellt eine einfache Möglichkeit dar, Anforderungen zu ermitteln und darzustellen.
Eine Data-Warehouse/BI-Lösung ist sowohl fachlich als auch technisch eine Herausforderung. Diese kann nicht alleine von der IT, aber auch nicht alleine vom Fachbereich gemeistert werden. Ein zentraler Punkt ist die Ermittlung der Anforderungen. Diese müssen so formuliert sein, dass sie sowohl vom Fach als auch von der IT verstanden werden. Weiter müssen diese auf einer Abstraktionsstufe dokumentiert werden, die noch übersichtlich, aber doch schon präzise genug ist.
Was will das Fach?
Das kommt ganz darauf an, wen man im «Fach» fragt. Zum Fach gehören beispielsweise eine Verkaufsabteilung, das HR oder auch die Geschäftsleitung. Alle arbeiten mit Kennzahlen, aber je nach Abteilung werden unterschiedliche Kennzahlen benötigt. Die Geschäftsleitung benutzt teilweise die gleichen Kennzahlen wie einzelnen Abteilungen, aber höher verdichtet. Beim Erheben von Anforderungen ist es daher wichtig, mit den verschiedenen Abteilungen zu sprechen und diese einzubeziehen.
Was sind Kennzahlen, was sind Dimensionen?
Nehmen wir ein einfaches Beispiel einer Auswertung, die von Kundenberatern benötigt wird:
Abbildung 1: Beispiel Kontobestände
Wenn wir nach Kennzahlen suchen, so suchen wir Zahlen, die etwas aussagen und mit denen gerechnet werden kann. Diese Kennzahlen nennt man auch Fakten [1]. Der Kontobestand ist ein typisches Beispiel einer Kennzahl. Wenn ein Kunde mehrere Konten hat, so können die Bestände dieser Konten auf den Kunden aufsummiert werden. Das bedeutet, dass «Konto» eine Dimension mit der Hierarchie «Kunde» ist. Eine weitere Dimension ist die Zeit. Dabei kann der Bestand über die Zeit aber nicht aufsummiert werden. Hier machen nur Maximum, Minimum oder Durchschnitt Sinn.
Visualisierung von Fakten und Dimensionen
Je nachdem, was modelliert wird, eignen sich unterschiedliche Modelle und Notationen. So kennt man für die Modellierung von transaktionsorientierten Datenbanken das Entitäten-Relationen-Diagramm (ERD). Abläufe zeichnet man mit Ablaufdiagrammen, und in der Programmierung wird mit Klassenmodellen gearbeitet. Wichtig bei solchen Modellen ist die Einfachheit. Sie zeigen mit wenigen Standardelementen die wichtigsten Gegebenheiten und Zusammenhänge. Für die dimensionale Modellierung mit Fakten (Kennzahlen) und Dimensionen wurde die ADAPT-Notation entwickelt. So kann das obige Beispiel als ADAPT dargestellt werden:
Abbildung 2: ADAPT zu Kontobestände
Die Notation ADAPT ist relativ umfangreich und ermöglicht eine präzise, detaillierte Darstellung von Fakten und Dimensionen [2]. In der Praxis hat sich aber gezeigt, dass bereits wenige Elemente genügen, um Anforderungen vernünftig darzustellen.
Abbildung 3: Die 4 wichtigsten Elemente von ADAPT
Beim Cube ist es sinnvoll, auch gleich die Kennzahlen (Fakten) anzugeben, die mit diesem Cube dargestellt werden. So kann ein Cube mit der Bezeichnung «Verkauf» sowohl den Betrag in CHF als auch die Menge beinhalten, was dann zwei Kennzahlen sind.
Vorgehen beim Erarbeiten der Anforderungen
- Beispiel als Excel
- Gemeinsam Kennzahlen erarbeiten
- Gemeinsam Dimensionen ermitteln
- Gemeinsam Dimensionen mit Hierarchien zeichnen
Häufig bestehen schon Auswertungen, die manuell zusammengestellt wurden und als Excel zur Verfügung stehen. Diese sind eine hilfreiche Grundlage, sind so doch die Kennzahlen und Dimensionen wenigstens teilweise schon erfasst.
Als erstes gilt es nun, daraus die Kennzahlen zu ermitteln. Wie erwähnt, sind das die Zahlenwerte, die eine fachliche Bedeutung haben und deren Summe oder eine andere Berechnung sinnvoll ist. Beispielsweise könnten Personalnummern aufsummiert werden. Da das aber fachlich keinen Sinn ergibt, gehören Personalnummern zu den Dimensionen. Die Anzahl geleisteter Stunden aber ist klar eine Kennzahl. Etwas schwieriger wird es bei Preisen. Wenn auf einer Rechnung 4 Flaschen Bier zum Einzelpreis von 4.50 und dem Totalpreis von 18.00 aufgeführt sind, so ist die 4 die Menge, die eine Kennzahl ist, der Einzelpreis gehört zur Dimension Produkt (hier Bier) und der Totalpreis ist wiederum eine Kennzahl.
Sind die Kennzahlen definiert, müssen die restlichen Spalten zu den Dimensionen gehören. Hier ist es wichtig zu überlegen, welche Attribute (Spalten) voneinander abhängig sind. Im Beispiel oben gibt es einen Zusammenhang zwischen Konto und Kunde. So können die Attribute, die zur selben Dimension gehören, gruppiert werden. Dann kann überlegt werden, welche Attribute zu welcher Hierarchiestufe gehören und wie sich diese zu Hierarchien gruppieren. Hier ist es wichtig, dass das Fach die fachlichen Zusammenhänge an Beispielen erklärt und die IT versucht, diese in Hierarchien abzubilden. Dieser Prozess muss teilweise auf mehrere Workshops verteilt werden, da das Fach Fragen klären und die IT Daten analysieren muss.
Am Schluss sollte eine ADAPT-Grafik entstehen, die für alle verständlich ist. Wenn diese Unbeteiligten gezeigt und erklärt wird und diese staunen, wieso man dafür so viele Workshops benötigt hat, dann sind die Grafiken gut. Dann sind sie wirklich einfach, nachvollziehbar und korrekt. Sind die Grafiken nicht so einfach verständlich, so ist es wichtig, dass die verwendeten Begriffe nochmals geprüft und falls nötig angepasst oder mindestens präzise definiert werden.
Wie weiter?
Betrachten wir die minimalen Schichten, die ein DWH benötigt:
- Quellen
- Staging und Cleancing Bereich
- Core
- Marts
Die ADAPT-Grafiken beschreiben die Anforderungen auf Stufe Mart. Normalerweise sind es dieselben Abteilungen, die sowohl Anforderungen an das DWH haben als auch für eine der Quellen oder einen Teil davon zuständig sind. So sind diese auch die richtigen Ansprechpartner, um zu ermitteln, welche Attribute in den Auswertungen woher kommen. Mit diesen Angaben sollte es nun möglich sein, das Herz des DWH, also den Core, zu modellieren. Damit der Core schrittweise umgesetzt und später auch einfach erweitert werden kann, empfiehlt es sich, diesen mit Data Vault zu modellieren und umzusetzen. Diese Methode ist in Skandinavien und den USA bereits weit verbreitet und wird auch im deutschsprachigen Raum bekannt. Verständlich, denn diese Methode bewährt sich sehr gut.
Quellen
[1] Ralph Kimball, Margy Ross: The Data Warehouse Toolkit. The Complete Guide to Dimensional Modeling. 2. Auflage. John Wiley & Sons, New York u. A. 2002, ISBN 0-471-20024-7
[2] https://www.tu-chemnitz.de/wirtschaft/sapr3/bw/Stud_Einfuehrung_multidimensionale_Modellierung.pdf
Autorin:
Dr. Andrea Kennel ist promovierte Informatikerin. Sie arbeitet seit über 20 Jahren im Bereich Data-Warehousing. Als Beraterin, Entwicklerin und Projektleiterin durfte sie schon viele DWH/BI Projekte mitgestalten. Ihr Wissen und ihre Erfahrung gibt sie in Vorträgen, Fachartikeln und als Dozentin weiter.