Die reine Lehre vom SQL Server Data Warehouse Entwurf…

Heute Abend ist zwar schon wieder ein Treffen der Hamburger SQL Server Community (PASS Chapter), aber ich kam noch gar nicht dazu das letzte Treffen zu reflektieren. War ein super Treffen, viele Leute, gute Diskussionen und eine klasse Lokation!

Bei dem Treffen habe ich eine lockere Liste von Punkten vorgestellt, welche aus meiner Sicht wichtig für den Erfolg von komplexeren Data Warehouse & Business Intelligence Projekten sind. Ein Punkt dabei war, dass ich vorgeschlagen habe, beim Entwurf für ein Data Warehouse ganz bewusst zwischen dem Presentation Layer und der eigentlichen technischen Implementierung in der Datenbank zu unterscheiden. Ich ging dabei soweit, dass ich vorschlagen habe für die physische Modellierung der Dimensionen sogenannte Key-Value-Tabellen einzusetzen. Dabei geht mein Ansatz wieder vom Attribut als Mittelpunkt aus. Das löste natürlich Diskussionen aus!

Wobei ich immer sage, dass es ja KEINE Silver Bullet gibt! Also eine universelle wirklich für jeden passende Lösung! Habe ich ja schon oft drauf hingewiesen. Und auch dieser Ansatz passt bei weitem nicht auf jedes Projekt.

Mir ist nur über die Jahre hinweg aufgefallen, dass sich langsam die Meinung durchsetzt, ein Data Warehouse muss sowohl logisch als auch physisch dem klassischen Star-Schema folgen. Und viele Herausforderungen, oder heute nenne ich sie mal bewusst Probleme, entstehen da heraus, dass sich die DWH Entwickler fast ein Bein ausreißen dieser Linie zu folgen.

Achtung! Ich meine nicht, dass wir auf Dimensionen und Fakten verzichten sollen! Ganz im Gegenteil. Bin immer wieder fasziniert bis entsetzt, was so als Dimension oder Fakt durchgeht. Diese Aufteilung (und der restliche theoretische Background eines Kimball etc.) macht auf jeden Fall Sinn! Nur halt nicht immer wirklich auf der physischen Ebene.

Natürlich stellt sich dann die Frage: Warum geht der Trend in diese Richtung? Ich kann mich noch durchaus an Zeiten erinnern, da waren Data Warehouse Systeme noch hoch komplizierte Werke, welche kein Reporting (bzw. OLAP)Tool   dieser Welt wirklich nutzen konnte. Da ist eine Orientierung in Richtung Star-Schema natürlich von Vorteil. Des Weiteren scheinen die heute verfügbaren Werkzeuge die DWH Entwickler dazu zu motivieren, gleich in Dimensionen und Fakten zu denken. Zweischneidig das Ganze.

Das nimmt auch die Integration Services des SQL Servers (SSIS) nicht aus. Gerade die Integration Services geben dem DWH Entwickler äußerst leistungsfähige Komponenten an die Hand, welche unmoderiert leicht über das eigentliche Ziel hinausschießen. SSIS Komponenten für SCDs tun da ein übriges.

Jegliche Abstraktion bleibt dabei auf der Strecke und wer meinen Empfehlungen und Vorträgen ein wenig gefolgt ist, weiß ja schon wie sehr ich eine gute und saubere Abstraktion in Systemen schätze! :-)

Die Frage nach den Vorteilen ist da natürlich gerechtfertigt und lässt in der Regel auch nicht lange auf sich warten:

- Anreicherung der Strukturen im Hintergrund durch Metadaten
- Integration von Data Quality Informationen und Prozessen
- Anbindung an ein Master Data Management System (wie z.B. Master Data Services)
- Nutzung eines Repositorys (wen hätte es gewundert…)
- etc.

Wenn ich das Thema bringe, dann weht mir natürlich oft gleich ne steife Brise ins Gesicht. Nur solange die Argumentation in die Richtung “Darum!” oder “Weil man das halt so macht…” geht, dann läuft da was falsch und das Thema muss mal sachlich diskutiert werden

Und um eventuelle Bedenken bezüglich der Performance auszuräumen, möchte ich an dieser Stelle die Indizierung von Views als Feature der Wahl vorstellen. Damit lässt sich so eine Umgebung dann auch durchaus zügig nutzen, also sofern nötig.

Ein weiterer Punkt ist meiner Meinung nach zu erwähnen: Der Presentation Layer hat nichts im Data Source View (DSV) der Analysis Services zu suchen!

Und ja, ich möchte an dieser Stelle durchaus polarisieren! :-)