„Conformed Dimension“ statt Flickschusterei

Wer von uns hat sich nicht auch schon über die alljährliche Flickschusterei bei Schlaglöchern in den Straßen aufgeregt. Anstatt das Übel an seiner Wurzel zu packen, nämlich die Straße zu sanieren, werden einfach nur die Löcher geflickt, denn dies geht zum einen schneller und ist kurzfristig gesehen günstiger. Mittel- und langfristig gesehen werden die Probleme aber nur aufgeschoben und aufsummiert sind dann die Aufwände höher im Vergleich zu einer Sanierung. Auch im Berichtswesen von Unternehmen oder der Data Warehouse-Modellierung kann auf Flickschusterei getroffen werden, weil zuvor ein höherer Aufwand und damit verbundene höhere Kosten gescheut worden sind.

Hierzu soll ein Beispiel näher betrachtet werden: Wir stellen uns ein Unternehmen vor, welches Apps über verschiedene Vertriebswege, nämlich die eigene Webseite, Apple iTunes und dem Google Play Store vertreibt. Dieses Unternehmen möchte seine Verkäufe mit Hilfe eines Data Warehouse analysieren, und das möglichst schnell. Um es kurz festzuhalten: Wir haben hier ein ganz einfaches Modell: die Verkäufe als Fakten, den Zeitpunkt des Verkaufs als Zeitdimension, die Apps als Produktdimension.

Was sich auf den ersten Blick einfach anhört, entwickelt sich bei der Umsetzung aber schnell zur Herausforderung. Für die Web-Verkäufe hat das Unternehmen sein eigenes System mit eigener Datenbank, in der die Produkte ihren eigenen Schlüssel besitzen. Und auch bei Apple iTunes sowie dem Google Play Store haben die Apps jeweils einen eigenen Schlüssel, obwohl es sich überall um dieselbe App handelt. Außerdem dürfte ein Produkt in der eigenen Datenbank vielmehr Attribute haben als z.B. bei Apple iTunes, wo nur der Schlüssel und Produktname gespeichert wird.

Um Zeit bei der Entwicklung zu sparen, kann man daher dazu verleitet werden, für jede Quelle eine eigene Produktdimension zu bauen, wodurch man eher eine Data Mart-Architektur im Data Warehouse erhält. Dies ist wie gesagt relativ schnell erledigt, und man kann getrennt nach Quelle die Verkaufszahlen betrachten. Das eigentliche Problem ergibt sich aber erst, wenn man die Verkaufszahlen für eine oder mehrere bestimmte Apps über alle Vertriebswege hinweg vergleichen möchte. Da für jede Datenquelle eine eigene Produktdimension vorhanden ist, ist dies von alleine gar nicht möglich, sondern kann nur durch manuelle Nacharbeit erfolgen, sprich: Für jeden Vertriebsweg müsste man sich eine Aufstellung der Verkäufe nach Apps erstellen und danach müssten diese Zahlen per Hand in einer neuen Tabelle zusammengeführt werden. Abgesehen davon, dass es ziemlich aufwändig ist, ist auch nicht gewährleistet, dass hierbei keine Fehler passieren. Ähnlich wie beim Flicken von Schlaglöchern haben wir also das gleiche Resultat: ein schnelles Ergebnis, welches ständiges Nacharbeiten erfordert.

Die empfehlenswertere Alternative ist das Zusammenbringen der Produkt-Dimension, das Fachwort hierfür „conforming dimension“ oder auch „conformed dimension“. Wie erwähnt, werden dieselben Apps über verschiedene Vertriebswege verkauft. Es handelt sich im Grunde genommen also überall um dieselben Produkte, und genauso sollte es auch im Data Warehouse modelliert werden. Hierzu ist natürlich mehr Aufwand nötig, denn wie gesagt sehen die Produktdaten in jeder Quelle anders aus. Mit Hilfe von Mapping-Tabellen kann dieses Problem aber gelöst werden, d.h. es wird z.B. festgelegt, dass Produktnummer 1234 in der Quelle A der Produktnummer XY12 in der Quelle B entspricht. Solche Mapping-Tabellen können beispielsweise mit Hilfe der Master Data Services erstellt und gepflegt werden. Ein verantwortlicher Mitarbeiter kann auf diese Weise neue Produkte nachtragen oder bestehende Verbindungen bearbeiten. Durch dieses Mapping ist es zudem möglich, nach allen gewünschten Dimensionsattributen zu analysieren, auch wenn diese gar nicht durch die Quelle bereitgestellt werden. Mit Hilfe der „conformed dimension“ ist es auch nicht mehr notwendig, die Zahlen nachträglich zusammenzuführen. Es ist möglich die Verkaufszahlen aller Vertriebswege nach einem Attribut der Produktdimension zu analysieren. Dem höheren Aufwand am Anfang steht also kein weiterer nachträglicher Aufwand entgegen.

Das Erstellen von „Conformed Dimension“ steht auch nicht im Gegensatz zu einer agilen Entwicklung, sondern ist im Gegensatz sogar förderlich. Sollten sich das Unternehmen entscheiden, seine Apps auch für den Windows Phone Store anzubieten, muss einfach nur das Mapping erweitert werden. Alle anderen Strukturen können übernommen werden.

Wann sollte man also „Conformed Dimensions“ benutzen? Die Antwort auf die Frage ist: Es hängt davon ab. Nehmen wir an, das Unternehmen würde z.B. auch Zeitschriften verkaufen. Auch hierbei handelt es sich um Produkte, aber würden diese auch in dieselbe Produktdimension passen? Sofern es sich nicht um digitale, sondern Print-Zeitschriften handelt, muss man diese Frage mit „Nein“ beantworten. Zudem sollten die separaten Dimensionen über eine gemeinsame Menge von Attributen zur Analyse verfügen, z.B. Produktgruppe, Plattform etc.

Fazit:

• Sofern es möglich ist, sollten aus mehreren gleichartigen Dimensionen eine „conformed dimension“ erstellt werden. Von „gleichartig“ kann man sprechen, wenn eine gemeinsame Menge von Analyse-Attributen vorhanden ist.
• Für das Zusammenführen können z.B. Mapping-Tabellen benutzt werden, welche auch über die Master Data Services gepflegt werden können.
• Der zusätzliche Entwicklungsaufwand am Anfang zahlt sich mittel- und langfristig durch einfachere Bedienung für den Endanwender und der Minimierung von Fehlern aus.
• Es wird eine agile Entwicklung gefördert, da bestehende Strukturen genutzt werden können.

Wer mehr über das Thema „Conformed Dimension“ wissen möchte kann dies in der neuesten Version des Data Warehouse Toolkit von Ralph Kimball und Margy Ross ab S. 137 nachlesen.

Patrick Rühmkorb