Architektur eines Data Warehouse (Datenbankmanagement)

Inhaltsverzeichnis

Vorwort

Inhaltsverzeichnis

Abbildungsverzeichnis

1. Einleitung
1.1 Relevanz des Themas
1.2 Zielsetzung der Arbeit

2. Begriffliche und inhaltliche Einordnung
2.1 Data Warehouse
2.2 Data Warehouse System
2.3 Data Warehousing
2.4 Architektur
2.5 Differenzierung operativer und informativer Systeme

3. Aufbau und Architektur eines Data Warehouse Systems
3.1 Anforderungen
3.2 Referenzarchitektur
3.3 Beschreibung der einzelnen Ebenen und Komponenten
3.4 Verteilung des Data Warehouse

4. Phasen des Data Warehouse Prozess
4.1 Monitoring
4.2 Extraktionsphase
4.3 Transformationsphase
4.4 Ladephase
4.5 Analysephase

5. Praxisbeispiel Data Warehouse Architektur
5.1 Steckbrief
5.2 Anforderungen und Motivation
5.3 Architekturmodell

6. Fazit und kritische Betrachtung

Literaturverzeichnis

Vorwort

Die vorliegende wissenschaftliche Arbeit entstand im Zeitraum vom 24.09.2012 bis 05.01.2013 an der FOM Hochschule am Studienstandort Mannheim. Die formale Gestaltung der Arbeit richtet sich nach dem offiziellen Leitfaden für Gestaltung wissenschaftlicher Arbeiten der FOM Hochschule sowie nach den Vorgaben und der Zitierrichtlinie des betreu­enden Dozenten. Inhaltlich umfasst die Arbeit den Themenbereich „Architektur eines Data Warehouse“. Das Thema der Arbeit wurde im Modul „Datenbankmanagement“ vergeben und ist Bestandteil der zu erbringenden Prüfungsleistung im genannten Modul. Ziel der Arbeit ist die umfassende und wissenschaftliche Betrachtung des Themengebiets mit all seinen wesentlichen Aspekten.

Mannheim, den 05.01.2013 Dennis Schindeldecker

Abbildungsverzeichnis

Abb. 3-1: Darstellung der Referenzarchitektur (i.A.a. BAUER, GÜNZEL 2009, S. 38)

Abb. 3-2: Beispiel von Datenqualitätsmängeln (i.A.a. BAUER, GÜNZEL 2009, S. 43)

Abb. 3-3: Architektur bei abhängigen (links) und unabhängigen (rechts) Data Marts (i.A.a. KUDRAß 2007, S. 434; BAUER, GÜNZEL 2009, S. 63-65)

Abb. 4-1: Phasen des Data Warehouse Prozess

Abb. 5-1: Architektur des Data Warehouse Systems der Kaufwelt Kaiser AG

1. Einleitung

Boden, Arbeit und Kapital. Die drei klassischen Produktionsfaktoren in unserer Gesellschaft. Doch schon seit langem werden in unserer sogenannten Informationsgesellschaft auch Informationen als vierter Produktionsfaktor mit hinzugerechnet.

Informationen spielen in der Wissenschaft und Betriebswirtschaft eine wesentliche Rolle. Auf Basis von Informationen werden Entscheidungen getroffen. Entscheidungen die für den weiteren Einsatz und die Notwendigkeit der drei anderen Produktionsfaktoren elementar sind. Steht ein Unternehmen beispielsweise vor der Wahl ob ein neues Produkt eingeführt werden soll, so sind hierfür im Vorfeld umfangreiche Daten und Informationen notwendig (z.B. über Kunden, über Märkte, über das eigene Unternehmen). Sind die zugrundeliegenden Daten für diese Informationen fehlerhalt, ungenügend, falsch aufbereitet oder unzureichend, so werden falsche oder nicht optimale Entscheidungen getroffen.

1.1 Relevanz des Themas

Das oben genannte Beispiel unterstreicht die Bedeutung einer strukturierten Datenspeicherung, Datenverarbeitung und vor allem Datenanalyse. Daten in unterschiedlichen Datenbanksystemen zu erfassen ist nichts Neues. In jedem Unternehmen werden Personaldaten eingegeben oder Daten zu Verkäufen erfasst. Die Verarbeitung und Verwaltung dieser Daten geschieht aber im Großteil autonom in Verantwortung des jeweiligen Bereiches / Abteilung. Schwierig wird es nun, wenn Entscheidungen getroffen werden müssen, die mehrere Unternehmensbereiche gleichzeitig tangieren und dadurch aus diesen betroffenen Bereichen unterschiedlich gespeicherte Daten herangezogen werden müssen. Nicht selten werden die verschiedenen Daten noch zusätzlich in völlig heterogener Qualität, Datenformaten, Datenmodellen und Datenbanksystemen gehalten. Dies erhöht die Komplexität noch weiter. Es wird daher eine Plattform benötigt, welche die bestehenden Daten unterschiedlicher Quellen integriert und durch eine integrierte Sicht auf beliebige Daten Analysezwecke ermöglicht. Das Data Warehouse.

Ein Data Warehouse dient der Integration eines zentralen, analyseorientierten Datenbestandes um Entscheidungsprozesse zu vereinfachen. Aufgrund seiner speziellen Funktion werden auch verschiedene Anforderungen an ein Data Warehouse System gestellt. Diese Anforderungen müssen bei der Konzeption und Gestaltung eines Data Warehouse Systems berücksichtigt werden. Ein entscheidender Punkt ist dabei dessen Aufbau und Architektur. Von außen betrachtet ist das Data Warehouse System ein monolithisches Informationssystem zur Analyse von Daten, welches allerdings durch eine spezifische Architektur beschrieben werden kann. Diese Architektur definiert sich einerseits aus einzelnen, statischen Komponenten und andererseits aus Daten- und Kontrollflüssen welche die Interaktion dieser einzelnen Komponenten miteinander beschreiben.

Diese grundlegenden architektonischen Punkte bilden die Basis für ein ausgereiftes und effizientes Data Warehouse System und sind daher in dessen Kontext ganz besonders zu betrachten.

1.2 Zielsetzung der Arbeit

Innerhalb dieser wissenschaftlichen Arbeit sollen alle wesentlichen Aspekte der Architektur eines Data Warehouse Systems betrachtet werden. Zu Beginn und zum gemeinsamen Verständnis werden daher zuerst die grundlegenden Begrifflichkeiten weiter definiert und beschrieben. Im darauf folgenden Kapitel wird der Grundstein gelegt und es werden zuerst die wesentlichen Anforderungen an die Architektur eines Data Warehouse Systems beschrieben, um dann eine Referenzarchitektur mit der Beschreibung seiner wichtigsten Architekturkomponenten vorzunehmen. Während dieses Kapitel eine funktionsorientierte Beschreibung der Komponenten vorsieht, steht im nächsten Kapitel die Dynamik der Komponenten und deren Zusammenspiel im sogenannten Data Warehouse Prozess im Vordergrund. Die zuvor erarbeiteten Grundlagen bilden nun im darauffolgenden fünften Kapitel die Basis für einen Transfer der Theorie in die Praxis. Hier soll an einem selbstgewählten fiktiven Unternehmen die beschriebene Architektur mit seinen Komponenten praxisnah erprobt werden. Letztendlich rundet eine kritische Betrachtung und ein Fazit die wissenschaftliche Arbeit ab.

Aufgrund der Komplexität und des Umfangs des Themenbereiches soll der Fokus primär auf der Architektur eines Data Warehouse Systems liegen. Weitere Bereiche wie die Entwicklung, die Modellierung und Anwendung eines Data Warehouse Systems oder eng verbundene Themenbereiche wie OLTP, Business Intelligence, Business Analytics, multidimensionale Datenmodelle, etc. werden daher nur an den tangierenden Stellen, soweit für das Verständnis erforderlich, umrissen. Eine vollumfängliche Beschreibung der oben genannten Bereiche findet aufgrund des Umfangs der Arbeit nicht statt.

2. Begriffliche und inhaltliche Einordnung

Als Grundlage für die folgenden Kapitel und zum gemeinsamen Verständnis sollen zu Beginn die wesentlichen Begrifflichkeiten in Bezug auf die Architektur eines Data Warehouse näher beleuchtet werden.

2.1 Data Warehouse

Die in der Literatur wohl am weitesten verbreitete und am häufigsten zitierte Definition des Begriffes Data Warehouse geht auf den amerikanischen Berater William H. Inmon im Jahre 1996 zurück: „A data warehouse is a subject oriented, integrated, non-volatile, and time variant collection of data in support of management´s decisions.“ (INMON 1996, S. 33). Aus dieser Definition lassen sich vier grundlegende Eigenschaften beschreiben. Alle Eigenschaften können der Entscheidungsunterstützung dienen. Diese sind:

- Fachorientierung (engl. subject orientation): Ein Data Warehouse beinhaltet Daten, die für die Unterstützung von Entscheidungsprozessen, unter Berücksichtigung eines spezifischen Anwendungsziels, relevant sind. Nicht für operative Prozesse, wie beispielsweise eine Personaldatenverwaltung.
- Integrierte Datenbasis (engl. integration): In einem Data Warehouse werden Daten, die aus heterogenen, operativen Systemen stammen, in einer integrierten Datenbasis und in einheitlicher Form gehalten.
- Nicht flüchtige Datenbasis (engl. non-volatile): Daten, die in ein Data Warehouse geladen wurden, können als stabil betrachtet werden. Diese Daten werden in der Regel nicht mehr verändert oder gelöscht.
- Historische Daten (engl. time variance): Eine Datenhistorie ermöglicht eine Analyse über zeitliche Veränderungen und Entwicklungen. Daher ist es notwendig, Daten über einen längeren Zeitraum zu halten.

2.2 Data Warehouse System

Das Data Warehouse ist in ein Data Warehouse System eingebettet. Das Data Warehouse System umfasst im Gegenzug zum Data Warehouse nicht nur die eigentliche Datenbank, sondern die gesamte Umgebung zur Beschaffung, Speicherung und Auswertung von Daten. Dies umfasst alle für die Integration und Analyse notwendigen Komponenten. Für die Integration sind die Komponenten der Datenbeschaffung hervorzuheben, für die Analyse die entsprechenden Analysekomponenten. Eine Basisdatenbank dient letztendlich zur Haltung des homogenen Datenbestands in der Umgebung. Alle genannten Komponenten haben einen statischen Charakter (vgl. LEHNER 2003, S. 9f; BAUER, GÜNZEL 2009, S. 8f; FARKISCH 2011, S. 7).

2.3 Data Warehousing

Der Data Warehouse Prozess (auch Data Warehousing) beschreibt hingegen den dynamischen Vorgang bzw. Prozess angefangen vom Datenbeschaffungsprozess über deren Speicherung bis hin zum Analyseergebnis beim Anwender; d.h. Data Warehousing beschreibt den Fluss und die Verarbeitung der Daten aus den Datenquellen bis hin zum Analyseergebnis beim Anwender. Der Data Warehouse Prozess lässt sich in verschiedene Schritte gliedern. Dazu zählen insbesondere die Extraktion der relevanten Daten aus den unterschiedlichen Quellsystemen, deren Transformation (mit Datenbereinigung), sowie die Integration, Analyse und Auswertung dieser Daten (vgl. BAUER, GÜNZEL 2009, S. 8f; FARKISCH 2011, S.8).

2.4 Architektur

Der Begriff Architektur stammt eigentlich aus dem Bereich von Bauwerken und beschreibt dort den Aufbau von Gebäuden, Objekten oder Gegenständen. Dort übernimmt eine Architektur primär drei Aufgaben: Sie erfüllt die geforderten Anforderungen, ist entsprechend robust gegen Änderungen und äußere Einwirkungen und weist eine definierte Ästhetik auf. Eine Architektur ist durch statische Komponenten (strukturbildenden Komponenten) als auch durch dynamische Komponenten (das Zusammenspiel der Komponenten) geprägt.

Eine solche Definition des Begriffes kann auch auf die Architektur eines Data Warehouse Systems übertragen werden. Genau wie ein Bauwerk ist auch ein Data Warehouse System von außen betrachtet eine funktionierende monolithische Einheit. Im Detail betrachtet besteht aber auch ein Data Warehouse System aus statischen und dynamischen Komponenten (siehe Kapitel 2.2, 2.3). Die Architektur eines Data Warehouse Systems lässt sich daher als die Struktur beschreiben, die alle Komponenten eines Data Warehouses Systems und deren Zusammenspiel vereint (vgl. PONNIAH 2001, S. 127; BAUER, GÜNZEL 2009, S. 3).

2.5 Differenzierung operativer und informativer Systeme

Aufgrund der aufgeführten Definitionen, Funktionen und Charakteristika von Data Warehouse Systemen können diese grundsätzlich von operativen Systemen unterschieden werden. Betriebliche Anwendungssysteme die den täglichen Geschäftsablauf von Unternehmen unterstützen (z.B. Auftragserfassungs-, Lagerverwaltungs-, Buchführungssysteme) werden häufig als operative Systeme bezeichnet und unterliegen dem Verarbeitungskonzept On-Line Transaction Processing (OLTP). In operativen Systemen werden aktuelle Daten zu bestimmten Geschäftsvorfällen anwendungsbezogen in dedizierten Datenbanken hinterlegt. Hauptanwender sind primär Sachbearbeiter die häufige Transaktionen (lesende und schreibende Zugriffe) während des Tagesgeschäftes vornehmen. Als zentrale Datenstruktur für operative Datenbanken bzw. im OLTP-Bereich gilt die zweidimensionale Darstellung in Form von Tabellen.

Das Gegenteil dazu bilden Entscheidungsunterstützungssysteme bzw. informative Systeme (Data Warehouse Systeme), welche sich durch das Verarbeitungskonzept On-Line Analytical Processing (OLAP) von den operativen Systemen abgrenzen. Hauptaufgabe dieser Systeme ist die Datenintegration heterogener Quellen und die Analysefunktion. Die Datenintegration bzw. die Datenaktualisierung erfolgt meist periodisch durch Abzüge aus den operativen Systemen. Diese Daten werden in multidimensionalen Datenstrukturen und mit historischen Verlaufsdaten gehalten. Hauptanwender sind primär Manager, Controller und Analysten (vgl. BÖHNLEIN, ULBRICH-VOM ENDE 2000, S. 2f: GOEKEN 2006, S. 20f; BAUER, GÜNZEL 2009, S. 9-11).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-1: Gegenüberstellung operativer Datenbanken und informativer Datenbanken (Data Warehouses)

3. Aufbau und Architektur eines Data Warehouse Systems

Nachdem eine begriffliche Einordnung und Abgrenzung erfolgt ist, soll nun auf den Aufbau und die Architektur eines Data Warehouse Systems eingegangen werden.

3.1 Anforderungen

In Hinblick auf die Architektur eines Data Warehouse Systems sind im Vorfeld einige generelle Anforderungen zu nennen, denen ein Data Warehouse System gerecht werden sollte. Diese sind (vgl. KIMBAL 2002, S. 3f; FARKISCH 2011, S. 56):

- Unabhängigkeit: Eine klare Trennung und Unabhängigkeit zwischen den Datenquellen (operativen Systemen) und dem Analysesystem (Data Warehouse System) muss gegeben sein. Die Unabhängigkeit bezieht sich vor allem auf die Verfügbarkeit, die Belastung sowie auf die laufenden Änderungen der Datenlieferung. Eine Analyse der Daten soll unabhängig von den Systemen, aus denen die Daten stammen, möglich sein.
- Persistenz: Ein Data Warehouse System muss eine persistente Datenhaltung durch eine dauerhaft bereitgestellte Struktur der abgeleiteten, integrierten und konsolidierten Daten sowie deren formelle und semantische Eindeutigkeit ermöglichen.
- Wiederverwendbarkeit: Die bereitgestellten Daten eines Data Warehouse Systems müssen beliebig oft wiederverwendet werden können.
- Flexibilität: Die in einem Data Warehouse System integrierten und abgeleiteten Daten müssen prinzipiell für nachfolgende Auswertungen herangezogen werden können.
- Individualität: Ein Data Warehouse System soll möglichst viele individuelle Sichten bezüglich der Datenstrukturen und Zeithorizonte ermöglichen und für den Anwender die notwendigen und geeignete Werkzeuge für Auswerte- und Analyseszenarien bereitstellen.
- Skalierbarkeit: Erweiterungen (z.B. die Integration neuer Datenquellen oder Erweiterung des Data Warehouse Systems) müssen einfach und ohne negative Auswirkungen auf die bisherige Architektur durchgeführt werden können.
- Effizienz: Die Abläufe, Prozesse und Prozessschritte in einem Data Warehouse System sollten vollkommen transparent und weitestgehend automatisiert sein (z.B. eine automatisierte Reporterstellung).

Es können weitere spezifische Anforderungen (z.B. durch die Umgebung, Anwender, etc.) an die Architektur eines Data Warehouse Systems gestellt werden. Diese gilt es im Rahmen eines Anforderungsmanagements im jeweiligen Entwicklungsprozess/-modell zu definieren, zu spezifizieren und zu berücksichtigen.

3.2 Referenzarchitektur

Nachdem die grundlegenden Anforderungen an ein Data Warehouse System behandelt wurden, kann nun der Blickwinkel auf die Architektur gelegt werden. Diese versteht sich als gegliederter Aufbau vergleichbar mit einem Bauwerk. Daraus ergeben sich sowohl unterschiedliche Komponenten innerhalb der Architektur als auch unterschiedliche Ebenen, in denen die Komponenten anzusiedeln sind. Da sowohl die Beschreibung der Komponenten als auch die Ebenstruktur in der Literatur sehr stark variiert, soll hier eine um Ebenen erweiterte Referenzarchitektur eines Data Warehouse Systems in Anlehnung an BAUER und GÜNZEL (2009, S. 38ff) angeführt werden. Die Referenzarchitektur ermöglicht Vergleiche zwischen Data Warehouse Systemen und dient gleichzeitig als Basis für deren Implementierung.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3-1: Darstellung der Referenzarchitektur (i.A.a. BAUER, GÜNZEL 2009, S. 38)

3.3 Beschreibung der einzelnen Ebenen und Komponenten

Im Folgenden sollen nun die einzelnen Komponenten sowie deren Zusammenspiel in der Architektur basierend auf den angesiedelten Ebenen näher beschrieben werden.

3.3.1 Datenquellen

Die Betrachtung eines Data Warehouse Systems geht von seinen Datenquellen aus. Diese sind allerdings selbst kein Bestandteil des Data Warehouse Systems. Dennoch stellen die Datenquellen den Ausgangspunkt und die elementare Grundlage für jedes Data Warehouse System dar. Die zu integrierenden, meist sehr heterogenen Datenquellen können entweder aus operativen Systemen, externen Quellen oder sonstigen Datenquellen (z.B. Flat Files, Tabellenkalkulationsprogramme, Batchdaten, etc.) stammen. Der Auswahl geeigneter Datenquellen kommt eine ganz besondere Bedeutung zu, da das resultierende Analyseergebnis eines jeden Data Warehouse nur so gut wie die Beschaffenheit der Quelldaten sein kann (vgl. WREMBEL, KONCILIA 2007, S. 77ff; FAKRISCH 2011, S. 58). Bei der Auswahl der Datenquellen sollte daher der Fokus auf nachfolgende Faktoren gelegt werden (vgl. BAUER, GÜNZEL 2009, S. 41ff):

1. Zweck des Data Warehouse Systems: Die Auswahl der Datenquellen ist unmittelbar von dem angestrebten Verwendungszweck des Data Warehouse Systems abhängig. So kann beispielsweise die einmalige Aufstellung aller wichtigen betriebswirtschaftlichen Kennzahlen, aufgrund der Bewertung für den Börsengang eines Unternehmens, nicht als Datenquellen für ein Data Warehouse im Controlling genutzt werden. Grund hierfür ist, dass die Aufstellung nicht fortgeschrieben wurde, wäre dies der Fall, könnte diese Quelle auch als Datenquelle für oben genanntes Beispiel dienen.

2. Qualität der Quelldaten: Alle Datenquellen sollten die wohldefinierte Datenqualität bereitstellen können. Hierbei kann es zu massiven Qualitätsmängel kommen, welche sich in unterschiedlichen Bereichen widerspiegeln können:

- Inkorrekte Daten (z.B. durch Fehleingabe)
- Uneinheitliche/Widersprüchliche Daten
- Duplikate und Redundanzen im Datenbestand
- Unvollständige Daten
- Inkonsistente Daten

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3-2: Beispiel von Datenqualitätsmängeln (i. A. a. BAUER, GÜNZEL 2009, S. 43)

Im Vorfeld sind daher entsprechende Qualitätsanforderungen an die Quelldaten zu stellen, die dann bei der Evaluierung der Datenquellen überprüft werden sollten.

3. Verfügbarkeit der Quelldaten: Die Definition der Quelldaten ist nicht gleichbedeutend mit deren Verfügbarkeit. Es muss daher sichergestellt werden, dass die zu verwendenden Daten auch verfügbar sind. Hierbei können organisatorische und technische Voraussetzungen betrachtet werden:

- Organisatorisch :
- Dürfen die Datenquellen (insbesondere externe Quellen) auch rechtlich verwendet werden (Datenschutzgesetz)?
- Hat der Betriebsrat, im Falle von personenbezogenen Daten, deren Nutzung im vorgesehenen Maße zugestimmt?
- Hat der Besitzer der Daten deren Weitergabe in das Data Warehouse System gewährt?
- Sind Daten vertraulich zu behandeln und bietet das Data Warehouse System die hierfür geforderten Sicherheitsmechanismen?
- Technisch:
- Ist ein Datenzugriff überhaupt technisch möglich?
- Ist der Datenzugriff bei der Übertragung abgesichert und können die Daten hinreichend schnell übermittelt werden?

4. Preis für den Erwerb der Quelldaten: Letztendlich spielt der Preis für den Erwerb der Quelldaten (sowohl bei externen als auch internen Datenquellen) eine wesentliche Rolle. Die hier anfallenden Kosten sind in das Projekt für das Data Warehouse System mit einzukalkulieren und sollten daher bei der Auswahl mit berücksichtigt werden.

3.3.2 Datenbeschaffungsebene

Nach den Datenquellen ist die Datenbeschaffungsebene die erste Ebene eines Data Warehouse Systems. Ihre Zielsetzung ist die Sicherstellung der Versorgung des Data Warehouse Systems mit Daten aus den unterschiedlichen Quellsystemen. Innerhalb dieser Ebene werden Daten der Quellsysteme physisch in den Bereich des Data Warehouse Systems geladen, gesäubert und zusammengefasst (vgl. LEHNER 2003, S. 22).

Der Datenbeschaffungsbereich beschreibt daher all diejenigen Komponenten eines Data Warehouse Systems, die funktional zwischen den Datenquellen und der Basisdatenbank anzusiedeln sind. Hierzu zählen sowohl die ETL-Komponenten als auch der Arbeitsbereich und der Monitor.

Monitor: Der Monitor ist für die Identifikation von Datenmanipulationen in den Datenquellen verantwortlich. Damit sowohl die Basisdatenbank als auch das Data Warehouse aktuelle Daten halten, müssen Aktualisierungen inkrementell beobachtet und verfolgt werden. Die konkrete Funktion des Monitors hängt unmittelbar von den angeschlossenen Datenquellen und deren Charakteristika sowie von den Anforderungen der Analysekomponente ab. Aus diesem Grund existiert in der Regel je Datenquelle ein Monitor (vgl. BAUER, GÜNZEL 2009, S. 49).

Arbeitsbereich: Innerhalb des Arbeitsbereiches (engl. Staging Area) werden Daten auf ihrem Weg von den Datenquellen in die Basisdatenbank temporär zwischengespeichert. Alle notwendigen Datentransformationen können dann direkt im Arbeitsbereich durchgeführt werden, ohne negative Folgen auf den laufenden Betrieb der Datenquellen oder der Basisdatenbank (vgl. BAUER, GÜNZEL 2009, S. 51).

ETL (Extraktion, Transformation, Laden): Mithilfe der Extraktionskomponente werden die Daten aus den Quellsystemen in den Arbeitsbereich übertragen. Hierbei werden bereits fundamentale Fehlerbeseitigungen durchgeführt und die Daten zur Modifikation vorbereitet. Zusätzlich kommt der Extraktionskomponente die Aufgabe zu, die Auswahl der Quellen bzw. Ausschnitte von Quellen, die in das Data Warehouse System importiert werden sollen, zu steuern. Hierbei ist wiederum der Zweck des Data Warehouse Systems (siehe Kapitel 3.3.1) entscheidend, da dadurch unter Umständen spezielle Anforderungen an die Relevanz und Beschaffenheit der Daten gestellt werden (vgl. KIMBALL, ROSS 2002, S. 7f; GOEKEN 2006, S. 29).

Die Transformationskomponente sorgt für den korrekten Zustand der Daten (Qualität), bevor diese in die Basisdatenbank geladen werden. Dies betrifft sowohl strukturelle Aspekte wie beispielsweise die Schemaintegration (Beseitigung von Inkonsistenzen auf Schemaebene) als auch inhaltliche Punkte wie die Datenintegration und Datenbereinigung. Zusätzlich werden durch die Transformationskomponente künstliche Schlüsse (Surrogate Keys) angelegt, da nicht sichergestellt ist, dass die Schlüssel der Quellsysteme Verwendung finden können (vgl. KIMBALL, ROSS 2002, S.8; BAUER, GÜNZEL 2009, S. 52f).

Der letzte Bestandteil der ETL – Komponenten ist die Ladekomponente. Nachdem die Datentransformation abgeschlossen ist, liegen im Arbeitsbereich die bereinigten und aufbereiteten Daten vor. Die Ladekomponente greift nun auf diese Daten zu und leitet diese Daten an die Basisdatenbank weiter. Es werden sowohl analyseunabhängige Detaildaten als auch analysespezifische Daten (z.B. Aggregate) in die Basisdatenbank geladen. Üblicherweise wird innerhalb der Ladekomponente das Ladewerkzeug des zugrundeliegenden Datenbankmanagementsystems (z.B. den SQL*Loader von Oracle) verwendet. Man unterscheidet weiterhin zwischen dem ersten Ladevorgang (Data Loading), im Zuge der Data Warehouse Entwicklung, und den permanenten bzw. periodischen Datenaktualisierungen während der Nutzung (Data Refreshment) (vgl. DODGE, GORMAN 2000, S.320f; GOEKEN 2006, S. 30; BAUER, GÜNZEL 2009, S. 53).

3.3.3 Datenhaltungs- und Datensteuerungsebene

Die auf der Datenerfassungsebene bereinigten und harmonisierten Daten gehen im nächsten Schritt auf die Datenhaltungs-/Datensteuerungsebene über. Diese besteht im Wesentlichen aus einer Basisdatenbank, welche als zentrale Datenbasis dient, sowie einem Repositorium für die Ablage der Metadaten. Der Data Warehouse Manager und der Metadaten Manager regeln als zusätzliche Steuerungskomponenten den Daten- und Kontrollfluss.

Data Warehouse Manager: Die zentrale Steuerungskomponente eines Data Warehouse Systems bildet der Data Warehouse Manager. Dieser ist für die Initiierung, Steuerung und Überwachung der einzelnen Prozesse (von der Extraktion aus den Datenquellen bis hin zur Analyse der Daten im Data Warehouse) zuständig. Er übernimmt hierbei die zentrale Steuerung aller an den Prozessen beteiligten Komponenten (Monitore, ETL-Komponenten, Analysekomponenten). Einer wesentlichen Bedeutung kommt in diesem Zusammenhang die Initiierung des Datenbeschaffungsprozesses durch den Data Warehouse Manager zu. Dieser kann in verschiedener Art und Weise (regelmäßigen Zeitintervallen, in Abhängigkeit von Datenänderungen, auf explizites Verlangen eines Anwenders) erfolgen. Sobald der Datenbeschaffungsprozess angestoßen wurde, steuert der Data Warehouse Manager die einzelnen Aufgaben und Schritte innerhalb dieses Prozesses. In den meisten Fällen findet der Datenbeschaffungsprozess sequentiell statt, d.h. der Data Warehouse Manager wartet auf die Vollendung eines bestimmten Schrittes, bevor der nächste angestoßen wird. Vereinzelt können bestimmte Schritte auch parallel erfolgen, z.B. bei der Extraktion aus den Datenquellen, wenn diese keine Abhängigkeiten untereinander aufweisen. Für die Steuerung der einzelnen Schritte verwendet der Data Warehouse Manager Informationen die im Repositorium abgelegt sind. Er ist daher in einer stetigen Kommunikation mit dem Metadaten Manager. Letztendlich werden eventuell auftretende Fehler durch den Data Warehouse Manager dokumentiert und (abhängig seiner Konfiguration) bestimmte Wiederanlaufmechanismen bereitgestellt, sodass beim Abbruch eines Prozesses nicht der komplette Prozess erneut durchlaufen werden muss (vgl. BAUER, GÜNZEL 2009, S. 39f).

Basisdatenbank: Die Basisdatenbank (auch konsolidierte Datenbank, operative Datenbasis, etc.) stellt die Stufe zwischen dem Arbeitsbereich und dem Data Warehouse dar. Sie dient als integrierte Datenbasis. Die Basisdatenbank orientiert sich allerdings nicht an spezifischen Analysebedürfnissen des Data Warehouse, sondern ist durch eine Anwendungsneutralität gekennzeichnet. Hierin liegt der Vorteil der Basisdatenbank, da durch die Anwendungsneutralität eine Mehrfachverwendung und Flexibilität in der Nutzung der Daten möglich ist. Zusätzlich sind die Datenhaltung (Basisdatenbank) und die Datenaufbereitung/-analyse (Arbeitsbereich, Data Warehouse) klar voneinander getrennt, was sich insbesondere in einer erhöhten Spezialisierung der einzelnen Komponenten widerspiegelt. Aufgrund der vorgegangenen Aufgaben des Arbeitsbereiches sind die Daten ebenfalls in der nötigen Granularität, bereinigt und integriert vorhanden. Die Daten der Basisdatenbank können an ein oder mehrere Data Warehouses übertragen werden. Zusätzlich besteht die Möglichkeit die Daten für weitere zentrale (operative) Systeme zur Verfügung zu stellen. Die Basisdatenbank nimmt daher zusammenfassend eine Sammel-, Integrations-, Distributions- und Qualitätssicherungsfunktion war (vgl. BAUER, GÜNZEL 2009, S. 53ff).

Repositorium: Im Repositorium sind alle Metadaten des Data Warehouse Systems abgelegt. Hierbei bezeichnen Metadaten alle Informationen, die den Aufbau, die Wartung und die Administration des Data Warehouse Systems beschreiben und somit vereinfachen. Bei den Metadaten handelt es sich um Informationen aus den Datenquellen, dem Arbeitsbereich, der Basisdatenbank und dem Data Warehouse. Beispiele hierfür sind: Konzeptuelle und logische Datenbankschemata, physische Speicherinformationen, Zugriffsrechte, Anzahl der geladenen Datensätze oder Informationen über die Data Warehouse Prozesse. Letztgenannte sind besonders interessant, da sich durch die Ablage dieser prozessrelevanten Informationen eine höhere Automatisierung im Data Warehouse System erreichen lässt (vgl. BAUER, GÜNZEL 2009, S. 72ff).

Metadaten Manager: Der Metadaten Manager ist die zentrale Steuerungseinheit für alle im Repositorium befindlichen Metadaten. Er steuert die Metadatenverwaltung des Data Warehouse Systems und liefert die notwendigen Metadaten an die jeweiligen Architekturkomponenten. Bei metadatengesteuerten Prozessen (z.B. bei der Aktualisierung von Daten aus einer Datenquelle) arbeitet der Metadaten Manager eng mit dem Data Warehouse Manager zusammen und liefert diesem die notwendigen Metadaten aus dem Repositorium. Der Data Warehouse Manager liefert diese Informationen nun an die jeweiligen Architekturkomponenten, welche die Informationen zur Laufzeit interpretieren und ausführen (vgl. BAUER, GÜNZEL 2009, S. 74f).

[...]