3 Das Data Warehouse

3.1 Konzept des Data Warehouse

Das grundlegende Konzept eines Data Warehouse wurde von W.F. Inmon erst 1993 aufgestellt und definiert. Bereits in der Einleitung des Kapitels „The Data Warehouse Environment“ seines Werks „Building the Data Warehouse“ stellt er mit der Aussage „[…] data warehouse is a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management’s decisions.[…]“ fest, welche Anforderungen an die Datenhaltung gestellt werden sollten.[27]

Subjektorientiert: Meist werden Daten nach einem speziellen Muster bzw. einer speziellen Struktur in den einzelnen Datenbanken oder Datenbeständen abgelegt. Diese Strukturen erhalten die Daten, weil sie sehr stark an die Bedürfnisse der Anspruchsgruppen oder auch die Prozessabläufe des Unternehmens angelehnt sind.[28] Für eine entsprechende Möglichkeit der Weiterverarbeitung und des Verständnisses ist diese Vorgehensweise durchaus berechtigt. Soll jedoch ein Data Warehouse aufgebaut und die entsprechenden Datenbestände generiert werden, so ist diese Orientierung an die Prozesse oder Bedarfsanmelder des Unternehmens die falsche Herangehensweise. Da die Daten nicht nur von einer Person, Anspruchsgruppe oder einem Prozess genutzt werden, ist es wichtig bei der Strukturierung der Daten die Orientierung auf die Datenbestände selbst zu legen.[29]

Integriert: Eine integrierte Datenstruktur wird dadurch erreicht, dass die Datenbestände innerhalb des Data Warehouse keine Redundanzen aufweisen und auch keine Inkonsistenzen bestehen. Durch eine Vereinheitlichung der Datenstrukturen im Rahmen des Transformationsprozesses und der einhergehenden Beseitigung von Disharmonien wird diesem Umstand Rechnung getragen.[30] An dieser Stelle sei auf das Metadatenmanagement verwiesen, welches eine hilfreiche Rolle bei der Schaffung einer integrierten Datenstruktur spielt.

Nicht-Volatil: Die Nicht-Volatilität der Daten bezeichnet eine gewisse Persistenz, da eine Abfrage, die man beispielsweise vor einem Monat ausgeführt hat, im nächsten Monat zum gleichen Ergebnis führen sollte. Nutzer des Data Warehouse sollten daher wenn möglich nur reine Leserechte bei der Verwendung der Datenbestände haben. Nur so kann sichergestellt werden, dass die Daten dauerhaft Bestand haben.[31] Ausnahmen sind hier sicherlich spät erfolgte Korrekturbuchungen in den operativen Systemen, die noch nicht im Data Warehouse erfasst worden sind.

Zeitraum bezogen: Operative Systeme, die auf dem OLTP basieren, zeichnen sich dadurch aus, dass sie Daten zeitpunktbezogen speichern. Ein Zugriff auf operative Daten, um einen Zeitraum abzudecken, ist daher nicht zu empfehlen. Auf der einen Seite sind Daten über längere Zeiträume gar nicht in den operativen Systemen vorhanden und auf der anderen Seite würde die Aggregation der einzelnen Zeitpunktdaten viel länger dauern und zudem noch die Performanz der operativen Systeme belasten. Die Strukturen in einem Data Warehouse sind also so zu planen, dass die Datenhaltung zeitraumbezogen stattfinden kann.[32]

Trotz dieser Grunddefinition mit den abgeleiteten Anforderungen kommt es häufig vor, dass der Begriff des Data Warehouse wortwörtlich mit „Datenwarenhaus“ übersetzt wird und so völlig andere Interpretationen in der Praxis entstehen lässt.[33] Eine bessere Definition liefern Hannig und Schwab, die das Data Warehouse als einen Datenvorrat von internen und externen Quellen ansehen, der die Basis für die nachfolgenden Informationssysteme stellt und somit eine Kernkomponente aller Data Warehouse Konzepte darstellt.[34]

3.2 Referenzarchitektur eines Data Warehouse

3.2.1 Aufbau der Architektur

Im 2. Kapitel wurde ein idealtypisches Umfeld einer BI Plattform behandelt und festgehalten, dass es sich um häufig vorkommende Komponenten handelt, die jedoch nicht zwangsläufig implementiert werden müssen. Auch gibt es keine allgemein gültige und akzeptierte Definition, die den Objektumfang eines BI Systems beschreibt. Bei einem Data Warehouse – eine der Kernkomponenten der BI – hat sich jedoch eine gewisse Referenzarchitektur entwickelt, die im Großen und Ganzen von der Fachwelt akzeptiert wird.[35] Die nachfolgende Abbildung stellt diese Referenzarchitektur grafisch dar und zeigt zudem die unterschiedlichen Informationsflüsse auf, die innerhalb der Data Warehouse Architektur eingeleitet werden. Da auch die Open Source Lösungen von dieser Referenzarchitektur ausgehen, wird die Abbildung nachfolgend noch näher erläutert.

Abbildung 6: Referenzarchitektur eines Data Warehouse

Quelle: Eigene Darstellung in Anlehung an Navrade (2008), S. 15.

Intern besitzt das Data Warehouse auf der einen Seite die Datenbestände oder auch Operanden. Diese werden innerhalb des Schemas als dunkelblaue Zylinder dargestellt. Die hellblauen Rechtecke mit den abgerundeten Kanten bezeichnen verschiedene Prozesse und werden daher auch Operatoren genannt. Operanden und Operatoren stehen in der Referenzarchitektur untereinander in zwei möglichen Varianten in Beziehung. Diese Beziehungen werden auf der einen Seite mit den durchgezogenen Linien illustriert, die den Datenfluss markieren und auf der anderen Seite mit den unterbrochenen Linien, welche für die Kontroll- und Steuerungsflüsse stehen.

3.2.2 Datenquellen

Im vorigen Kapitel wurde bereits der ETL-Prozess als Teil der BI Umgebung angesprochen. Dieser wird hier noch einmal auf eine andere Weise dargestellt. Ausgehend von einer Datenquelle wird hier der ETL-Prozess als Datenfluss eingeleitet, der durch die Extraktion in den Arbeitsbereich (staging area) gelangt und zusätzlich an den Metadatenmanager gesendet wird. Das Metadatenmanagement ist für die Beschreibung der Daten innerhalb des Data Warehouse verantwortlich und benötigt daher ebenfalls den Datenfluss, um über die einzelnen Phasen des ETL-Prozesses informiert zu werden. Der Monitor überwacht diesen Prozess und prüft, ob neue Datenquellen verfügbar sind oder sich die Struktur von bereits bekannten Datenquellen verändert hat. Die Prüfung nach der Änderung von Inhalten zählt primär nicht dazu, da bereits vorab festgelegt wird, in welchen Zeitabständen die Aktualisierungen des DW durchgeführt werden.[36] Bei Auffälligkeiten meldet er dies an den Data Warehouse Manager weiter, der die Extraktions- und Transformationsprozesse entsprechend neu erstellen bzw. anpassen kann.[37]

3.2.3 Metadatenmanager und Repositorium

Neben grundlegenden Informationen über die Daten, wie z.B. deren Struktur, Format oder Inhalt, werden im Metadatenmanagement auch noch Informationen über diese Daten gespeichert, die eher mit deren Anwendung zu tun haben, wie z.B. auf welche Transformationsregeln zurückgegriffen wird sowie für welche Systeme oder Auswertungen diese benötigt werden.[38] Idealerweise werden sämtliche Metadaten in einem zentralen Repository (Repositorium) abgelegt, auf welches nicht nur der Metadatenmanager, sondern auch andere Bezugspersonen zugreifen können, um Datenstrukturen besser zu verstehen oder aus ihnen bestimmte Schlussfolgerungen ziehen zu können.[39]

Problematisch wird es, wenn kein zentrales Repository verwendet wird, sondern einzelne Anwendungen oder Funktionsbereiche eigene Repositorys aufstellen und verwalten. Hier muss der Metadatenmanager dafür Sorge tragen, dass die Datendefinitionen innerhalb der Repositorys einheitlich sind und dass er entsprechende Werkzeuge bereithält, die über verschiedene Versionen der Metadaten in den einzelnen Repositorys informieren. Um diese Problematik zu vermeiden, wurde von der Object Management Group der „Common Warehouse Metamodel“ Standard entwickelt, der es ermöglichen soll, Metadaten applikationsübergreifend auszutauschen.[40] Als weitere Aufgaben des Metadatenmanagers werden die Steuerung und Administration der Benutzerzugriffe sowie die Zurverfügungstellung von Analyse- und Entwicklungswerkzeugen genannt.[41]

3.2.4 Arbeitsbereich

Im Arbeitsbereich werden nun die einzelnen Transformationsschichten abgearbeitet, die über den Data Warehouse Manager bzw. dem Metadatenmanager initiiert worden sind. Nach Abschluss des Prozesses wird der bereinigte Datenbestand mit dem Operator „Laden“ in die Basisdatenbank übertragen und steht somit erstmals der Phase der Datenhaltung zur Verfügung....