Überlegungen über den Aufbau eines Repositorys in einer Business Intelligence Umgebung

Ein kürzlich geführtes Gespräch mit einem Community Kollegen über das Thema Repositorys in Microsoft Business Intelligence Umgebungen, brachte mich auf die Idee meine Überlegungen und Erfahrungen zu dem Thema hier mal kurz zu skizzieren.

Meine Definition eines Repositorys ist eine zentrale Sammlung von Metadaten, Versionsständen und Protokollen. Ein solches Repository gehört meiner Meinung nach primär zu dem Themenkomplex Data Warehouse.

Das Versprechen einer Business Intelligence Lösung bzw. eines Data Warehouses ist u. a. die Bereitstellung der sogenannten “einzigen Wahrheit” in der Organisation. Das ist zum Beispiel durch den Einsatz von OLAP Cubes technisches relativ leicht durchzusetzen. Alle weiteren Frontend Werkzeuge (zum Beispiel Reporting Services oder Excel) greifen auf diese Datenquellen zu. Was passiert aber nun, wenn sich Strukturen des Data Warehouses und/oder der OLAP Cubes verändern? Diese Veränderungen ziehen sich in der Regel bis zu den Frontends durch und haben sehr wahrscheinlich auch Einfluss auf die schon bereitgestellten Reports in Reporting Services und Excel.

In einer klassischen Microsoft Business Intelligence Umgebung greifen die Dienste direkt auf die jeweils anderen Dienste zu.

Die Dienste des SQL Servers sind technisch gesehen eigenständig. In einer BI Lösung werden diese zwar miteinander verbunden, aber diese Kopplung ist recht lose. Auf der einen Seite sind damit äußerst flexible Architekturen möglich, auf der anderen Seite gibt es kein zentrales Element, welches die Kommunikation zwischen den Diensten steuert. Szenarien, wie das oben geschilderte, werden durch keine Architekturschicht “aufgefangen”.

Die Verwendung eines zentralen Repositorys, welches zwischen den Dienste steht, unterstützt die Business Intelligence Umgebung dabei das Versprechen einer einzigen Wahrheit nachhaltig einzulösen.

Die Technologie hinter einem solchem Repository ist in unseren Projekten die relationale Engine des SQL Servers. Die notwendige Flexibilität gibt mir aber die Kombination aus strukturierten und semi-strukturierten Daten. Ein Ziel ist es, dass im Projekt als auch bei der späteren Verwendung der Business Intelligence Umgebung nicht mehr an unterschiedlichen Orten nach Informationen gesucht werden muss, sondern, dass gezielt das Repository genutzt werden kann.

Bereits während der Einführung einer Business Intelligence Lösung sollte daher auf den konsequenten Aufbau eines durchgängigen Repositorys geachtet werden.

Das ist zwar jetzt sehr theoretisch, aber gehen wir mal bei einem Beispiel ein wenig ins Detail. Die Reporting Services sind ein sehr leistungsfähiger Dienst. Die Definition der Reports liegen in sogenannten RDL-Dateien vor. Als Beschreibungssprache wird die Report Definition Language verwendet. Diese ist auch sauber von Microsoft dokumentiert.

Innerhalb einer RDL-Datei wird auf eine Datenquelle verwiesen, welche gesondert beschrieben wird. Aber die eigentliche Definition der verwendeten Felder innerhalb des Reports ergibt sich im Report direkt aus dem CommandText der Query und den definierten Feldern. Es ist mit Hausmitteln später nicht mehr einfach herauszufinden, woher die Felder im Report kommen. Dazu müsste die Query analysiert werden (komme ich noch zu). Auch das neue Feature der Shared datasets bringt hierfür nicht wirklich etwas (sonst äußerst praktisch!), da es nur eine weitere Abstraktionsebene zwischen Report und Datenquelle zieht, aber keine eindeutiges Mapping der Felder zu Tabellen (oder Cubes) zulässt. Hier mal ein Blick direkt in eine RDL-Datei. Wir sehen die Query und die einzelnen Felder, aber kein Mapping!

Eine konkrete Überlegung für das Repository ist, dass dieses Mapping aber für Impact-Analysen auf jeden Fall stattfinden muss. Wie kann sowas nun realisiert werden?

Im Falle einer relationalen Quelle, also zum Beispiel des direkten Zugriffs von Reports auf das Data Warehouse, lässt sich das recht einfach mittels automatischer generierter Views lösen. Das Data Warehouse stellt über das Repository, als eine Art Presentation Layer, eine Reihe von Views bereit, welche in den Reports verwendet werden können. Wichtig ist dabei, dass die Flexibilität nicht künstlich beschnitten wird. Es sollte auch nicht verschwiegen werden, dass es durchaus Möglichkeiten gibt auf Basis der Query innerhalb eines Reports an die verwendeten Tabellen und Views zu kommen. Realisierbar ist das mit einer Mischung aus RDL-Datei auslesen und Queryplan abfragen! Damit bringen uns selbst Sub-Queries und geschachtelte Views nicht um den Verstand! :-)

Bei einer multidimensionalen Quelle, also einem OLAP Cube, ist es leider nicht ganz so einfach. Da haben wir out-of-the-box keine Views, die wir dafür verwenden können. Um dieser Herausforderung Herr zu werden, macht es Sinn sich mit AMO zu beschäftigen. Den Analysis (Services) Management Objects. Mittels dieses praktischen Frameworks können Cubes auf Basis unserer Metadaten aus dem Repository automatisiert erzeugt werden. Damit haben wir zumindest eine zuverlässige und saubere Datenbasis, auf welcher wir dann aufsetzen können mit den Frontends. Die Metadaten, welche AMO nutzt, greifen zum Beispiel wiederum auf die oben erwähnten Views des Data Warehouses zu.

Wie Ihr seht gibt es durchaus Anwendungsfälle für ein Repository im Rahmen eines Business Intelligence Projektes!

Ein Repository wird bei der Erstellung eines ersten Prototypen einer Business Intelligence Lösung bzw. Umgebung aber meist als überflüssig empfunden. Vielleicht entsteht sogar der Verdacht, dass der Berater künstlich zusätzlichen Zeitaufwand generieren möchte und keinen echten Gegenwert dafür liefert. Dabei gibt es ja eine ganze Reihe von sehr guten Gründen für den Einsatz einer solchen Architektur!

Ein guter Ansatz ist es wesentlich mehr Aufmerksamkeit (und das ist nicht zu verwechseln mit Zeit!) in die Pflege der verwendeten Quellen zu legen. Wenn es geschafft wird die Quellen als eigenständige Objekte zu verstehen, welche entsprechend auch für sich gepflegt werden, dann ist das Projekt meist auf einem guten Weg. Im Rahmen eines standardisierten Deployment Prozesses sollten später neue Objekte auch direkt in das Repository aufgenommen werden.

Ich denke, dass ich mit Sicherheit auf dem PASS Camp im Oktober das eine oder andere zu diesem Thema zeigen werde. Wir werden zum Beispiel RDL-Dateien auseinandernehmen und uns eigene AMO Prozesse codieren.