DWH Automation: Die Formel 1 der Datawarehouse-Entwicklung

Einleitung und Anwendungsfall

Vorbei sind die Zeiten, wo man es sich leisten konnte, erst nach vielen Monaten oder sogar Jahren der DWH-Entwicklung eine brauchbare Lösung zur Verfügung zu stellen. Zeit ist bekanntlich Geld und daher kostbar. Auf der Methodenseite bieten sich häufig agile, d.h. iterativ-inkrementelle Vorgehen an, um diesem Umstand zu begegnen. Sie finden in einigen früheren Artikeln von mir bereits zahlreiche Ausführungen dazu. In diesem Artikel möchte ich nun erläutern, welche Rolle Werkzeuge aus der Kategorie «DWH Automation» haben. Das möchte ich anhand eines praktischen Beispiels illustrieren.

Der Anwendungsfall ist folgender: Die Firmen Xtreme und Northwind sind ein Joint Venture («XtremeNorth») eingegangen und möchten nun so rasch wie möglich ein gemeinsames, firmenübergreifendes Reporting etablieren. Dabei greifen sie als Quellen auf ihre jeweiligen ERP-Systeme zurück, wobei die Daten jeweils in einer SQL-Server Datenbank liegen. Um möglichst rasch zu einem ersten Ergebnis zu kommen, setzen die beiden Firmen auf die DWH-Automationslösung «WhereScape RED».

In einer ersten Iteration sollen Bestelldaten («Orders») ausgewertet werden entlang der Zeitdimension sowie nach Produkten und Kunden. Das Core-Warehouse wird dimensional modelliert.

DWH-Automation mit WhereScape RED

WhereScape RED basiert auf dem ELT-Prinzip. D.h. in einem ersten Schritt werden die benötigten Daten aus den Quellsystemen in das Zielsystem, der DWH-Datenbank, geladen. Dort werden die Daten bei Bedarf noch weiter transformiert. Der erste Schritt in WhereScape RED ist die Erstellung von Loadtabellen. Diese werden dadurch erstellt, dass man Tabellen aus dem «Source-Browser» in die eigentliche Arbeitsfläche von RED zieht:

01_LoadTable

Mit wenigen Klicks erstelle ich in der Folge die nachstehenden Load-Tabellen:

02_AllLoadTables

Um die beiden Quellsysteme besser unterscheiden zu können, habe ich bei der Namensgebung entsprechende Kürzel (NW, XT) verwendet.

Der nächste «Layer» im XtremeNorth-DWH ist ein Viewlayer, um die Daten der beiden Firmen zu integrieren. In dieser ersten Iteration wird vorerst auf inhaltliche Konsolidierung verzichtet, d.h. es gibt noch kein einheitliches Stammdatenmanagement z.B. der beiden Kundenstämme. Mittels UNION-Views werden die Daten zusammengefügt:

03_CreateView

04_CreateView2

In der UNION-View mache ich einige inhaltliche Transformationen, z.B. stelle ich sicher, dass der Businesskey (im Beispiel customerid) für beide Systeme eineindeutig ist. Ebenso werden Datentypen transformiert, wo diese in den jeweiligen Quellsystemen unterschiedlich sind.

Im nächsten Schritt erstelle ich die Dimensions-Objekte, z.B. die Kundendimension auf Basis der vorher erstellten View:

05_CreateCustomerDim

WhereScape RED fragt dabei ab, ob die Dimension historisiert werden soll, was ich zurzeit nicht benötige. Anschliessend wird die eigentliche Ladeprozedur erstellt. Dazu muss ich in erster Linie den Businesskey spezifizieren – alles Weitere übernimmt WhereScape, u.a. das Anlegen eines Surrogatekeys:

06_CreateCustomerDim2

Die gleichen Schritte wiederhole ich für die Produktdimension (die Datumsdimension steht im Übrigen standardmässig zur Verfügung).

Anschliessend an die Erstellung der Dimensionen wird eine Stage-Tabelle benötigt, um die eigentlichen Fakten aufzubereiten (Verknüpfung von Orders und Order-Details) und die Verknüpfung mit den Dimensionen zu vollziehen:

Zuerst werden die benötigten Felder aus der Orders- und Order-Details-Tabelle in den Arbeitsbereich gezogen, um die neue Stage-Tabelle zu erstellen.

07_Stage

Anschliessend muss der Join zwischen diesen beiden Tabellen spezifiziert werden:

08_StageJoin

Durch Drag n’Drop werden die Dimensionen hinzugefügt, wobei nur der Surrogatekey in die Stagetabelle hinzugefügt wird – die Verknüpfung spezifiziere ich auf Basis der Business Keys:

09_StageDim

Kennzahlen (z.B. das Liefergewicht der Bestellung), welche ihren Ursprung in der Orders-Tabelle haben, werden durch den Join mit den Order-Details möglicherweise multipliziert (für Bestellungen mit mehr als einer Bestellposition). Entsprechend muss diese Kennzahl über eine kleine Transformation korrekt berechnet werden:

10_StageCalculation

Aus der Stage-Tabelle kann ich nun im Handumdrehen die Faktentabelle erstellen:

11_CreateFact

Um die Daten noch etwas handlicher abfragen zu können, erstelle ich einen OLAP-Cube (in diesem Fall auf Basis von SQL Server Analysis Services):

12_CreateOLAP

Dann wollen wir mal schauen, was dabei rausgekommen ist:

13_QueryExcel

Fazit

WhereScape ist nicht nur eine zweckneutrale «ELT Toolbox», um Daten von A nach B zu schieben. Aufgrund eines inhaltlichen Verständnisses eines Datawarehouse (z.B. von Dimensionen und Fakten), werden auch entsprechende Design Patterns für Automation der Erstellung und Befüllung dieser Strukturen angeboten. Dadurch lässt sich die Entwicklungszeit massiv reduzieren, in unserer Erfahrung je nach Aufgabe zwischen 20 – 40%!

Im nächsten Artikel werde ich dann erläutern, wie die Lösung von einem Entwicklungssystem auf ein Test- und Produktionssystem verteilt werden kann.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert