Kaum schreibe ich ein wenig aus der Praxis als Coach, schon kommen die Fragen. Bin ja selbst schuld.

Der Hinweis, doch bitte ein Vorgehensmodell zu nutzen, hat Wellen geschlagen. Denn wie kommt denn nun der interne als auch externe BI Entwickler/Implementierer/Berater an ein solches Vorgehensmodell. Oder fassen wir die Frage ein wenig allgemeiner: Wie kommt ein Unternehmen, welches den Microsoft Business Intelligence Stack einführen möchte, an einen entsprechenden Plan?

Und was ist überhaupt so ein Modell? Ein Projektplan? Nein, ist es nicht, sondern eher eine Art Handlungsanweisung zur Erreichung des Ziels. Nenne wir es mal nicht Karte sondern Kompass! Dieser Vergleich leuchtet vielen meist schnell ein! Projektplan ist die Karte, Modell der Kompass!

Eine Lösung kann natürlich sein, sich einen entsprechenden Partner zu suchen, welcher ein fertiges Modell liegen hat. Grundsätzlich ein guter Plan! Eine Sache gebe ich aber zu bedenken bzw. mit auf den Weg. Ruhig mal fragen, ob die Kollegen denn mehr als ein Modell dabei haben. Wenn schon von der Stange, dann bitte auch in der richtigen Größe und Farbe kaufen. Nicht jedem passt ja schließlich jedes Modell!

Und wenn man nun selbst drauf kommen muss! Was dann? Woher nehme ich meinen Kompass?

Puh. weites Feld, gibt viel zu tun!

Wie fängt man denn nun an? Es gibt eine Business Seite und eine Technik Seite. Da das hier ein SQL Server orientierter Blog ist, bleibe ich mal bei der technischen Seite. Und einigen wir uns kurz mal, dass die Einführung Projektmanagement auch übersprungen wird. :-)

Was bleibt? Genau, fast zu viel! Zum Beispiel die Definition des Ziels bzw. der Modellierung eines Cubes. Immer ein super spannendes gruppendynamisches Erlebnis für die ganze Arbeitsgruppe!

Ein Punkt, welcher Teilnehmer häufig weiterbringt, ist eine für sie verständliche Vorstellung des Ziels. Gerade für Einsteiger in das Thema BI sind Konzepte wie ein OLAP Cube doch recht abstrakt, oder? Da hilft für den Anfang dann eine vereinfachte Sicht auf die Dinge oft weiter. Das gilt besonders für Kollegen aus den kaufmännischen Abteilungen, welche spontan dem Projektteam zugeordnet wurden. Ihr seit uns herzlich willkommen!

Nur wie kann man sich nun so einen Cube vorstellen? Anwender als auch Berater schauen sich dann gern in Excel einen fertigen Cube an. Ja, das ist das Endergebnis, welches in einer GUI aufbereitet vorliegt. Meiner Erfahrung nach kommen aber gerade Anwender von diesem Standort aus schwer auf die notwenige abstrakte Ebene. Da wird sich mit Händen und Füssen an Excel geklammert. Bringt keinen Spaß.

Auch ein Sterndiagramm hilft hier meist nur bedingt weiter. Da es ja nun mal nicht wirklich einen Cube beschreibt, sondern die perfekte Quelle. Es muss eine Vorstellung des multidimensionalen Raums her.

Ok, bei drei Achsen usw. ist das ja noch fast kein Problem. Dummerweise haben Cubes häufig wesentlich mehr Achsen, sprich Dimensionen. Ein Ansatz aus meinen Coachings ist, dass sich die Teilnehmer diesen doch bitte mal als ein mehrdimensionales Array vorstellen sollen. Was ist ein Array? Das kennen die jüngeren noch aus dem Programmierkurs in der Schule.

Das hier

Array[i] = Wert

wird vielen bekannt vorkommen. Ist ein eindimensionales Array. Das "Teil" hat einfach mehrere Schubladen, welche durchnummeriert sind und wir sagen über i welche Schublade es sein darf.

Werden wir hiermit komplexer

Array[x,y] = Wert .

Das ist jetzt ein zweidimensionales Array. Ideal für einfache Koordinatensysteme.

Wie kommen wir jetzt zum Cube?

Das hier ist vereinfacht ausgedrückt ein Cube

Cube[a₁,a₂,a₃,a₄,..a_n] = Wert .

Jede Dimension in unserem Array steht nun für ein Attribut innerhalb des Cubes! Das lässt sich übrigens super am Flip Chart oder Whiteboard live entwickeln! :-)

Warum jetzt Attribut? Weil, hier werden sich jetzt die Älteren von uns dran erinnern können, wir ab spätestens SQL Server Analysis Services 2005 von einem attributsorientierten OLAP Cube sprechen. Das Attribut steht im Vordergrund. Was ist ein Attribut? Eine Eigenschaft innerhalb einer Dimension. Zum Beispiel eine Produktnummer, eine Produktgruppe oder ein Produktsegment. Alles Beispiele für Attribute. Und diese Attribute haben Ausprägungen. Also zum Beispiel "Holzschrauben" und "Metallschrauben" als Produktgruppen.

Wenn also a₁ die Produktgruppe ist und a₂ die Produktnummer, dann sieht unser Array nun so aus

Cube[Holzschrauben,4711-42,a₃,a₄,.a_n] = Wert

Unsere a₁ & a₂ beschreiben eine sehr sehr einfache Dimension Produkte. Und a₃ & a₄ sind einfach mal Dimension Zeit mit Jahr und Quartal.

Cube[Holzschrauben,4711-42,2011,Q1,.a_n] = Wert

Schon bauen wir uns einen sehr einfachen Cube. Durch weitere Klammern, können wir nun noch die Dimensionen kenntlich machen.

Cube[ (Holzschrauben,4711-42) , (2011,Q1) ,.a_n] = Wert

Denke mal, dass die Idee verstanden ist. Und was ist Wert? Unsere Measure? Nein! Hier werden wir gleich ein wenig technischer im Modell und weisen drauf hin, dass Measures ja am Ende auch "nur" eine Dimension sind. Also unsere a_n ist die Measure Dimension.

Cube[ (Holzschrauben,4711-42) , (2011,Q1) , Umsatz in Euro] = Wert

Auf Basis dieses Modells können wir nun mit dem Würfel spielen. Zum Beispiel den Umsatz für eine andere Schraubenart abrufen.

Cube[ (Holzschrauben,0815-05) , (2011,Q1) , Umsatz in Euro] = Wert

Und uns auch in der Zeit bewegen.

Cube[ (Holzschrauben,0815-05) , (2011,Q2) , Umsatz in Euro] = Wert

Und auch andere Measures abfragen.

Cube[ (Holzschrauben,0815-05) , (2011,Q2) , Menge in Stück] = Wert

Damit wird auch dem Laien im übrigen schnell deutlich, dass ein multidimensionaler Raum sehr wahrscheinlich recht dünn besiedelt ist. Hilft auch bei vielen Diskussionen! Glaubt mir!

So, aber genug dazu. Damit stellt Ihr das Attribut in den Mittelpunkt. Wenn Ihr nun Eurer eigenes Vorgehensmodell definieren wollt oder müsst, dann orientiert Euch daran, dass Ihr die Attribute wirklich sauber definieren müsst. Sowohl für einen OLAP Cube als auch schon im Data Warehouse. Das ist natürlich einfach so dahin geschrieben. Es ist in Projekten oft eine echte Herausforderung!

Mit den Cube = Array Modell kann aber zumindest relativ schnell über das Wesentliche diskutiert werden. Klar, jetzt fehlen noch ein paar Seiten Projektmanagement dazu. Des Weiteren macht häufig ein Reifegradmodell für eine saubere projektübergreifende Strategie Sinn.

Ich hoffe mal, dass Euch dieser Kompass und die Dialogvorlage aus der Praxis ein klein wenig den Weg in Richtung Vorgehensmodell gewiesen hat.