Einordnung
Die Informationsbereitstellung ist und bleibt ein wesentlicher
Gesichtspunkt von Managementunterstützungs- bzw. Business-Intelligence-Systemen.
Große Potenziale entfaltet die Sammlung, Verdichtung und Selektion
entscheidungsrelevanter Informationen insbesondere auf Basis einer konsistenten
unternehmungsweiten Datenhaltung.
An dieser Stelle setzt das Data-Warehouse-Konzept an und
fordert den Aufbau einer zentralen und von den Vorsystemen getrennten Datenbasis
zur Unterstützung dispositiver Aufgaben [Gluchowski, Gabriel, Dittmar 2008, S. 118;
Kemper, Baars, Mehanna 2010, S. 19]. Im Idealfall soll eine derartige
Datenbasis unternehmens- bzw. konzernweit ausgerichtet sein und das
Informationsbedürfnis verschiedenster Anwendergruppen abdecken. Aus technischen
Gründen erweist es sich als sinnvoll, ein derartiges zentrales Data Warehouse (DW)
von den datenliefernden Vorsystemen zu entkoppeln und auf einer separaten
Plattform zu betreiben, was teilweise sogar als konstituierendes Merkmal für
Data Warehouse-Lösungen gewertet wird [Hahne 2014, S. 2]. Eine Entkopplung
führt einerseits zu einer Entlastung der operativen Systeme und eröffnet
andererseits die Option, das analyseorientierte System auf die Belange von
Auswertungen und Berichten hin zu optimieren [Gluchowski, Gabriel, Dittmar 2008,
S. 118].
Die erstmalige Verwendung der Begrifflichkeit kann bis in die
späten 1980er Jahre zurückverfolgt werden, als Devlin und Murphy das Data
Warehouse als zentrale Datensammelstelle skizzieren, die den Nutzer von
technischen Details der Datenintegration entlastet, damit er sich auf die
Verwendung der aufbereiteten Inhalte konzentrieren kann [Devlin, Murphy 1988,
S.61].
Sehr zur Popularität des Data-Warehouse-Konzeptes hat William
Inmon beigetragen, der die vier idealtypischen Merkmale Themenorientierung,
Vereinheitlichung, Zeitorientierung und Beständigkeit formuliert hat, die bis
heute weitgehend Gültigkeit aufweisen [Inmon 2005]. Mit dieser inhaltlichen
Ausrichtung einer Data-Warehouse-Lösung ist folglich die zugehörige Aufgabenstellung
festgelegt, themenorientierte und integrierte (i. S. v.
vereinheitlichte) Informationen über lange Zeiträume und mit Zeitbezug zur
Unterstützung von Entscheidern aus unterschiedlichen Quellen periodisch zu
sammeln, nutzungsbezogen aufzubereiten und bedarfsgerecht zur Verfügung zu
stellen [Gluchowski, Gabriel, Dittmar 2008, S. 121; Kemper, Baars, Mehanna
2010, S. 21].
Gestaltung einer Data Warehouse-Lösung
Beim Aufbau eines Data Warehouse-Konzeptes sind sowohl
betriebswirtschaftlich-organisatorische als auch technische Gestaltungsaspekte
sorgfältig zu durchdenken. Aus betriebswirtschaftlich-organisatorischer Sicht
ist zu überlegen, welche Informationen auf welchen Verdichtungsstufen im
Datenspeicher abgelegt werden müssen und welchen Mitarbeitern diese zugänglich
gemacht werden sollen. Zudem ist zu klären, was konkret unter einzelnen
Begriffen zu verstehen ist bzw. woraus sich die einzelnen Größen
zusammensetzen, was sie repräsentieren und wie sie ermittelt werden [Gluchowski
2016, S. 230 - 232].
Daneben muss ebenfalls ein tragfähiges technisches
Realisationskonzept mit dem Ziel erarbeitet werden, die atomaren Daten aus den
vielfältigen und heterogenen operativen Vorsystemen systematisch
zusammenzuführen. Aus diesem Grund sind periodisch oder ad-hoc Verbindungen aufzubauen,
um die relevanten Daten zu extrahieren. Durch vielfältige
Aufbereitungsmechanismen werden diese gesäubert und entsprechend den
Anforderungen strukturiert abgelegt. Die Integration der Daten in einem System
führt dazu, dass ein gleichartiger Zugriff auf ein sehr breites inhaltliches
Spektrum ermöglicht wird. Da im Idealfall alle Managementanwendungen eines
Unternehmens mit diesen Daten arbeiten, gibt es nur eine „Version der Wahrheit“
[Gluchowski, Gabriel, Dittmar 2008, S. 124], d. h. dass in unterschiedlichen Berichten und Auswertungen
auch abteilungsübergreifend keine abweichenden Zahlen vorkommen können.
Architektur und Komponenten
Wurde am Anfang der Diskussion um das Data-Warehouse-Konzept
noch vehement um die richtige Anordnung einzelner Komponenten gerungen, so hat
sich im Laufe der Zeit die Hub-and-Spoke-Architektur als geeignete Form des
Aufbaus einer entscheidungsorientierten IT-Landschaft etabliert [Hahne 2014, S.
10f.]. Die gewählte Begrifflichkeit ist darauf zurückzuführen, dass die Anordnung
der Komponenten an eine Naben-Speichen-Kombination erinnert.
Der Datenfluss führt ausgehend von den operativen und externen
Informationssystemen, die als Lieferanten für das Rohdatenmaterial dienen, über
die eingesetzten Komponenten für die Extraktion, Transformation und das Laden
von Daten (ETL) zunächst bis zum Enterprise (oder Core) Data Warehouse. Hier
finden sich aufbereitete und
aggregierte Daten (beispielsweise auf Tagesbasis) aus allen
Unternehmensbereichen und mit langer, meist über mehrere Jahre reichende
Historie. Das gespeicherte Datenvolumen im Core Data Warehouse erweist sich in
der Regel als sehr umfangreich und kann Größenordnungen bis in den hohen
Terabyte-Bereich annehmen.
Bei einem derart großen Datenvolumen bereiten vor allem interaktive
und ggf. multidimensionale Sichtweisen auf den verfügbaren Datenbestand mit
ausgeprägter Navigationsfunktionalität erhebliche Probleme. Schließlich sind entsprechend
den OLAP-Forderungen beliebigen Rotationen und Schnittbildungen nebst
Analysefunktionalitäten anzubieten. Aus diesem Grund werden Datenextrakte zur
weiteren Verarbeitung gebildet, die sich als personen-, anwendungs-,
funktionsbereichs- oder problemspezifische Segmente des zentralen Data
Warehouse-Datenbestandes verstehen und als Data Marts[Kemper, Baars, Mehanna 2010, S. 22] bezeichnen
lassen.
Beim Zusammenspiel zwischen einem Data Warehouse und den
zugehörigen Data Marts sind unterschiedliche Grundformen voneinander
abgrenzbar. Sehr häufig setzen Data Marts auf dem zentralen Data Warehouse auf
und speichern Teilextrakte des Gesamtdatenbestandes nochmals separat in
physischer Form ab.
Abbildung 1 visualisiert die unterschiedlichen
Speicherkomponenten einer Data Warehouse-Lösung nochmals mitsamt den
zugehörigen Datenflüssen.

Abb. 1: Hub-and-Spoke-Architektur
Neben den Speicherkomponenten für die Problemdaten weist eine
Data Warehouse-Architektur auch ein Archivierungssystem auf, das sowohl der
Datenarchivierung als auch der Datensicherung dient. Die Datensicherung wird
zur Wiederherstellung der Inhalte eines Data Warehouses im Falle von Programm-
oder Systemfehlern benötigt. Die zu speichernden Datenvolumina in einem Data
Warehouse können im Laufe der Nutzungszeit einen erheblichen Umfang erreichen.
Um das Volumen in erträglichen Grenzen zu halten, werden Archivierungssysteme
eingesetzt, die atomare wie verdichtete Daten aus der Data-Warehouse-Datenbank
entfernen, ohne dass diese für spätere Analysen verloren gehen. Technologisch
erfolgt dabei eine Auslagerung eines Teils der Daten aus der
Data-Warehouse-Datenbank in langsamere Datenträger, auf die entweder direkt
zugegriffen werden kann oder aus denen sich der ursprüngliche Datenbestand
jederzeit regenerieren lässt.
Neben den entscheidungsorientierten Daten enthält ein Data
Warehouse auch Metadaten, die in einem Metadatenbanksystem verwaltet werden. Im
Idealfall handelt sich dabei nicht nur um rein technische Angaben, die neben
ihrer Informationsfunktion auch zur Steuerung des Data-Warehouse-Betriebs
dienen. Vielmehr werden im Metadatenbanksystem auch betriebswirtschaftliche
Angaben abgelegt, die dem Endanwender dabei helfen, Analyseanwendungen
effektiver einzusetzen und deren Ergebnisse zu interpretieren oder die für ihn
relevanten Daten zu finden. In diese Kategorie der semantischen Metadaten
fallen beispielsweise Dokumentationen zu vordefinierten Anfragen und Berichten
sowie die Erläuterung von Fachbegriffen und Terminologien.
Allerdings ist darauf hinzuweisen, dass das vorgestellte Hub-and-Spoke-Architekturkonzept
nur eine mögliche Architekturvariante darstellt. In der praktischen
Ausgestaltung finden sich auch Lösungen, die davon abweichen und beispielsweise
ohne Data Marts oder mit unabhängigen Data Marts operieren [Kemper, Baars,
Mehanna 2010, S. 22; Seiter 2017, S. 85].
Neben der klassischen Hub-and-Spoke-Architektur hat sich in den
letzten Jahren in immer stärkeren Maße eine logische Aufteilung des
DW-Datenbestandes in Schichten ergeben, die in ihrer Gesamtheit heute als
Data-Warehouse-Schichtenarchitektur bezeichnet wird [Hahne 2014, S. 16 - 23].
Auch wenn die einzelnen Ebenen teilweise unterschiedlich benannt sind und auch
die Anzahl der Schichten variieren kann, erfolgt hier die Vorstellung einer
idealtypischen Architektur mit insgesamt vier Datenschichten bzw. Layer.

Abb. 2: DW-Schichtenarchitektur
Der Acquisition Layer dient der Aufnahme untransformierter
Rohdaten aus internen und externen Datenquellen. Bereits im Kontext der
Hub-and-Spoke-Architektur war ein derartiger Datenbereich unter der Bezeichnung
Staging Area gebräuchlich. Vor allem dann, wenn die angelieferten Rohdaten als
Textdateien formatiert sind, wird hier auch von einer Landing Zone gesprochen.
Im Falle einer dauerhaften Ablage der Rohdaten zur möglichen späteren
Verwendung der Extraktionshistorie erfolgt die Bezeichnung Staging Memory.
Der Integration Layer entspricht dem Enterprise oder Core Data
Warehouse klassischer Prägung und bildet mit aufbereiteten Daten das Ziel der
Transformations- und Harmonisierungsprozesse in ihrer vollständigen Historie.
Im Gegensatz zu früheren Lösungen finden sich die Daten hier heutzutage oftmals
in der größtmöglichen Detailierung, d.h. bis auf die Belegebene der
datenliefernden Vorsysteme. Das gesamte gespeicherte Datenvolumen kann in
dieser Komponente bis in den dreistelligen Terabyte-Bereich und darüber hinaus
anwachsen, zumal die Daten über einen mehrjährigen Zeitraum vorgehalten werden.
Der Integration Layer vereinigt durch die Bereitstellung der gesamten
relevanten Unternehmensdaten in detaillierter und integrierter Form damit
sowohl eine Sammel- und Integrationsfunktion als auch als Hub für nachgelagerte
Schichten eine Distributionsfunktion in sich.
Der Propagation Layer implementiert einheitliche
Business-Logiken bzw. Business-Rules, indem eine zentrale Ermittlung
abgeleiteter Merkmale und Kennzahlen an einer Stelle erfolgt. Durch die zentralisierte
Ableitung wird vermieden, dass unterschiedliche Berechnungsvorschriften auf dem
Weg zu den nachgelagerten Data Marts zur Anwendung gelangen. Je nach
Anwendungsfall kann auf diese Schicht auch verzichtet werden.
Der Reporting Layer stellt Daten für den Fachbereich
aufbereitet entsprechend der betriebswirtschaftlichen Aufgabenstellungen zur
Verfügung. Im Allgemeinen erfolgt die Speicherung dieser Daten in
unterschiedlichen, aufgabenbezogenen Data Marts und dort mit multidimensionalen
Datenstrukturen, wobei in immer stärkeren Maße auch die Belange von Self
Service Beachtung finden. Aufgrund der ausgeprägten Volatilität der
Anforderungen aus den Fachbereichen (Business Requirements) muss eine gute
Anpassbarkeit durch hohe Agilität gewährleistet sein.
Zusammenfassend ist damit unter einem Data Warehouse ein
unternehmensweites Konzept zu verstehen, das als logisch zentraler Speicher
eine einheitliche und konsistente Datenbasis für die vielfältigen dispositiven
Anwendungen bietet und losgelöst von den operativen Datenbanken betrieben wird.
Literatur
Gluchowski, Peter; Gabriel, Roland; Dittmar, Carsten:
Management Support Systeme und Business Intelligence, Computergestützte Informationssysteme
für Führungskräfte und Entscheidungsträger. 2. Auflage. Berlin u. a.: Springer,
2008.
Gluchowski, Peter: Entwicklungstendenzen bei
Analytischen Informationssysteme, in: Chamoni, Peter; Gluchowski, Peter
(Hrsg.): Analytische Informationssysteme. Business Intelligence-Technologien
und -Anwendungen, Berlin u. a.: Springer, 2016, S. 225 - 238.
Hahne, Michael: Modellierung von Business-Intelligence-Systemen,
Heidelberg: dpunkt, 2014.
Inmon, William H.: Building the Data Warehouse. 4.
Auflage. New York: Wiley, 2005.
Kemper, Hans-Georg; Baars, Henning; Mehanna, Walid:
Business Intelligence - Grundlagen und praktische Anwendungen. 3. Aufl., Wiesbaden:
Vieweg, 2010.
Seiter, Mischa: Business Analytics. Effektive Nutzung
fortschrittlicher Algorithmen zur Unternehmenssteuerung, München: Vahlen, 2017.
Autoren
Prof. Dr. Peter Gluchowski, Technische Universität Chemnitz, Fakultät für Wirtschaftswissenschaften, Professur Systementwicklung / Anwendungssysteme, Thüringer Weg 7/225, 09126 Chemnitz
Autoreninfo