In meinem letzten Blogpost habe ich ja ein wenig über Vorschläge für den Entwurf von Data Warehouse Umgebungen im Kontext SQL Server geschrieben. Und mir war klar, dass ich polarisieren werde. Hab es ja so gewollt. Gab dann ja auch schön Feedback von der Community zurück. Daher hier nun weitere Erläuterungen zu dem Thema.

Ein Punkt, welcher Inhalt des Feedbacks an mich war, ist das Thema Presentation Layer im Data Warehouse. Dazu wird viel in der begleitenden Literatur geschrieben und ich habe auch schon viel PowerPoint dazu gesehen. Teilweise wird sowohl in Form eines Prozesses von einem Presentation Layer gesprochen wird als auch bei einer statischen Architektur. Da sehe ich aber durchaus einen Unterschied!

Hier zur Visualisierung ein paar Beispiele:

Bei der Prozessdarstellung kommt der Presentation Layer meist "am Ende" des Prozesses, als der Teil, welcher dann von "Außen" sichtbar sein wird. Der Presentation Layer wird zum Beispiel im Rahmen eines ETL Prozesses am Ende "erzeugt".

Dann gibt es den Ansatz bei einer Architektur vom Presentation Layer zu sprechen. Ich habe also diverse´Ebenen in meiner Architektur und wieder ist nur eine von "Außen" sichtbar.

Jetzt kann natürlich diskutiert werden, wo denn nun der Presentation Layer anfängt? Im Data Warehouse oder sind Cubes in den Analysis Services erst der Presentation Layer? Dann hätte das Data Warehouse in dem Sinne gar keinen Presentation Layer, sondern die OLAP Cubes erfüllen diese Rolle. Das käme dem Prozessbeispiel auch wieder nahe, da die Cubes ja erst am Ende des Datenbewirtschaftungsprozesses "entstehen". Die Cubes wären dann so etwas wie Data Marts.

Kommen wir zu meinen Anregungen aus meinem Blogpost. Dort schlug ich ja vor, dass das Schema des Data Warehouse für sich bereits diverse Abstraktionen enthalten dürfte, sofern diese die Entwicklungs- und Betriebsprozesse unterstützen und den Anwendern nicht im Weg stehen. Dabei ist mein Vorschlag, dass auch einzelne Objekte wie Attribute, Dimensionen, Hierarchien etc. gerne jeweils ihre eigene Abstraktion haben dürfen und sich auch gegenüber den anderen Objekten nur durch diese "mitteilen". Im Hintergrund gibt es dann ein Meta-Universum, welches die Objekte zusammenhält. Das mag der eine oder andere aus der objektorientierten Programmierung kennen.

Nur von den Faktentabellen lasse ich in der Regel die Finger was Abstraktionen angeht, da diese bei echten Massendaten äußerst kontraproduktiv wären!

Hier also ein Beispiel für einen Ansatz, bei dem die Objekte jeweils Ihren eigenen Presentation Layer für eine Abstraktion haben. Das darf dann gerne auch mehrmals geschachtelt sein, wenn es denn die Prozesse genügend unterstützt.

Es ist immer zu klären, ob sich der Aufwand und die Komplexität, welche die Arbeit mit Abstraktionen mit sich bringt, auch wirklich rentiert. Die IT ist voll von Beispielen für positive als auch negativen Ansätzen. Das muss im Einzelfall jeweils mit dem Kunden diskutiert werden.

Im Zweifel ist aber das Ziel der Suche nach dem Presentation Layer immer eine Definitionsfrage! :-)