Data Warehouse Factory: BI-Automation durch Data Vault mit SSIS und SAS Base (eBook)

Textprobe: Kapitel 3.1.3: BI-Ready: BIReady ist eine Automatisierung für eine DWH-Befüllung, welche vom gleichnamigen Unternehmen entwickelt wurde. Diese Automatisierung umfasst sowohl das Design eines DWHs, als auch die Implementierung und Wartung. Ausgelegt wurde das Tool auf die Implementierung eines Stern- oder Schneeflockenschemas. Neu hinzugefügt wurde auch eine Unterstützung für DV. Eine grundlegende Idee dieses Tools ist ebenfalls die Beachtung eines bestimmten Punktes im ETL-Prozess, bis zu welchem die Daten automatisiert durch einen reinen Kopiervorgang geladen werden können. In dem Tool kann das Datenmodell grafisch erstellt werden. Dieses gestaltet sich sehr unkompliziert und variabel. Es bietet eine unkomplizierte Handhabung einer Historisierung an. Der Vorteil des DV-Konzepts ist es, dass viele dieser Überlegungen vom Modell bereits übernommen werden. Beispielsweise ist eine Historisierung der Daten bereits durch den LDTS gesichert. Im Gegensatz zu den anderen in diesem Buch beschriebenen Tools und Automatisierungen muss der Prozess an sich aber trotzdem einmal für ein DV-Modell erstellt werden und kann folgend für weitere Modelle angepasst werden. Daraus lässt sich der angepasste SQL-Code generieren, je nachdem für welche Datenbank er gebraucht wird. 3.1.4: PDI DV Framework: Das Pentaho Data Integration Data Vault Framework (PDI DV Framework) ist eine vollständige Sammlung an Programmen und Dateien für die automatisierte Befüllung eines DVs. Angewandt wird hierfür ein mit Pentaho Kettle entwickelter dynamischer Ladeprozess. Entwickelt wurde es von dem niederländischen BI-Experten Edwin Weber. Es als eine virtuelle Maschine verfügbar und kann somit komplett eigenständig genutzt werden. Als Betriebssystem nutzt es Ubuntu 12.04 LTS Server. Es beinhaltet eine MySQL-Datenbank zur Speicherung der Daten. Ein Beispiel DV-Datenbankschema ist ebenfalls enthalten. Um das Schema für das eigene DV aufzubauen ist die MySQL-Workbench enthalten. Gesteuert wird das Framework durch die Verwendung von Metadaten. Diese Metadaten werden in einer Excel-Datei gepflegt und in dem Prozess in eine Datenbank geschrieben und gehalten. In diese Metadaten muss eingetragen werden, welche Hubs, Links und Satelliten es, mit ihren jeweiligen Attributen, in dem DV gibt. Das Open Source-ETL-Tool Kettle von Pentaho liest diese Metadaten aus und der Prozess wird für das zu befüllende DV flexibel angepasst ausgeführt. Es dient lediglich der Befüllung und das Datenbankschema muss manuell aufgebaut werden. Um den Einsatz und Umgang mit dem Framework und dem DV-Modell nachvollziehbar zu halten ist eine Versionskontrolle enthalten. Diese hält fest, wann und welche Änderungen vorgenommen wurden. Zuerst werden die Hubs und anschließend die Links befüllt. Anschließend werden Hub-Satelliten und Link-Satelliten befüllt, wie bereits in Kapitel 2.2 näher erläutert. 3.2: Mögliche Automatisierung von Ladeprozessen: Die bisher scheinbar am weitesten verbreitete Methode zur automatischen Befüllung eines DWH, oder spezieller eines DV-basierten DWH, ist die automatisierte Generierung von Ladeprozessen. Darauf lässt sich insofern schließen, als dass die meisten in Kapitel 3.1 vorgestellten und erhältlichen Anwendungen auf diese Weise arbeiten. Abbildung 8 stellt eine denkbare Vorgehensweise schematisch dar. Grundlage sind zentral gespeicherte Metadaten. Je nach Anforderung des Prozessgenerators beschreiben diese sowohl den Aufbau und die Datenstruktur von Quell- sowie Zielsystemen, als auch die Beziehung dazwischen. So wird in den Metadaten festgelegt, welche Rohdaten in welcher Tabelle des DV gespeichert werden sollen (für genauere Angaben siehe Kapitel 4.4). Der Generator verwendet diese Informationen zum Erstellen der Ladeprozesse. Schließlich müssen die generierten Prozesse noch ausgeführt werden. Sie sorgen dann für den Datenfluss (weiße Pfeile) vom Quellsystem ins DV. Zur Vereinfachung und Reduktion der Metadaten wäre noch eine Verbindung zwischen dem Prozessgenerator sowie dem Quellsystem denkbar. Werden zum Beispiel die Datentypen der einzelnen Attribute vom Generator benötigt, könnte er diese selbst aus dem Quellsystem lesen. Ein Nachteil dieses Ansatzes ist, dass bei jeder Änderung der steuernden Metadaten, also Änderungen an den Quell- oder Zielsystemen, die Ladeprozesse neu erzeugt werden müssen und somit nicht unmittelbar zur Verfügung stehen.