Modellierung von Business-Intelligence-Systemen E-Book

Michael Hahne

• Herausgeber: dpunkt
• Kategorie: Wissenschaft und neue Technologien
• Serie: Edition TDWI
• Sprache: Deutsch
• Veröffentlichungsjahr: 2014

Seitenzahl: 301

Beschreibung

Die Modellierung von Business-Intelligence-Systemen (BI) umfasst eine Vielzahl unterschiedlicher Facetten, die im Kontext von Operational BI, agile Warehousing, Real-Time und Self-Service BI zu bewerten sind. Dieses Buch beschreibt die Architektur und Gestaltung von unternehmensweiten analyseorientierten Informationssystemen insbesondere unter dem Aspekt zunehmend agiler Geschäftsanforderungen und deren Unterstützung durch BI-Methoden. Neben der Darstellung von Best Practices der Historisierung und der Data-Mart-Modellierung ist der Aufbau eines Enterprise Data Warehouse von zentraler Bedeutung. Behandelt werden im Einzelnen: - Business-Intelligence-Architektur - Mehrdimensionale Datenstrukturen - Semantische mehrdimensionale Modellierung - Bestandteile und Varianten des Star-Schemas - Historisierung und Zeitabhängigkeit im Data Warehouse - Faktenmodellierung - Dimensionsmodellierung - Core-Data-Warehouse-Modellierung Dieses Buch ist ein Muss für alle mit der Gestaltung und Nutzung von BI-Systemen betrauten Architekten, Analysten, Entwickler und Projektleiter.

Leseprobe

Dr. Michael Hahne ist Geschäftsführender Gesellschafter der Hahne Consulting GmbH, einem auf Business-Intelligence-Architektur und -Strategie spezialisierten Beratungsunternehmen. Zuvor war er Vice President und Business Development Manager bei SAND Technology, einem internationalen Anbieter von intelligenter Software für das Informationsmanagement spezialisiert auf Lösungen für unternehmensweite und große Data Warehouses. Darüber hinaus hat er sieben Jahre als Geschäftsbereichsleiter und CTO bei der cundus AG, einem auf Business Intelligence fokussierten IT-Dienstleistungsunternehmen, gearbeitet. Er hat mehr als 10 Jahre Erfahrung in der Implementierung und Optimierung von Data-Warehouse-Lösungen.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.de/plus

Modellierung von Business-Intelligence-Systemen

Leitfaden für erfolgreiche Projekte auf Basisflexibler Data-Warehouse-Architekturen

Edition TDWI

Michael Hahne

Dr. Michael Hahne

E-Mail: [email protected]

Lektorat: Christa Preisendanz

Fachlektorat: Prof. Peter Gluchowski, Technische Universität Chemnitz

Copy-Editing: Ursula Zimpfer, Herrenberg

Herstellung: Frank Heidt

Umschlaggestaltung: Anna Diechtierow, Heidelberg

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Fachliche Beratung und Herausgabe von dpunkt.büchern in der Edition TDWI: Marcus Pilz · [email protected]

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBNBuch 978-3-89864-827-1PDF 978-3-86491-523-9ePub 978-3-86491-524-6

1. Auflage 2014Copyright © 2014 dpunkt.verlag GmbHWieblinger Weg 1769123 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Geleitwort

Bereits seit den Anfängen der Diskussion um die Ausgestaltung einer Data-Warehouse-Landschaft sowie die zugehörige multidimensionale Sichtweise auf betriebswirtschaftliches Datenmaterial wird intensiv über geeignete Formen und Techniken der Datenmodellierung nachgedacht. Die gewählte Art der Ablage relevanter Daten bestimmt dabei nicht zuletzt einerseits die Flexibilität bei der Reaktion auf veränderte oder erweiterte Benutzeranforderungen und andererseits die Zugriffsmöglichkeiten für den Endanwender, vor allem im Hinblick auf Navigationsfunktionalität und Antwortzeitgeschwindigkeit. Allerdings lassen sich die etablierten Verfahren und Methoden der Datenmodellierung aus dem operativen Systemumfeld nur sehr eingeschränkt nutzen, da die entsprechenden Systeme eher auf die schnelle und konsistente Erfassung zahlreicher Einzeltransaktionen ausgerichtet sind und weniger auf die umfassende Auswertung großer Datenvolumina.

Vor diesem Hintergrund nimmt das Modellierungsthema auch bei den Aktivitäten des TDWI (The Data Warehousing Institute) Germany e.V. breiten Raum ein und manifestiert sich sowohl bei den großen TDWI-Konferenzen als auch im Rahmen des Seminarprogramms. Bei diesen Gelegenheiten zeigt sich stets ein ungebrochenes großes Interesse der Teilnehmer an den unterschiedlichen Modellierungsaspekten einer umfassenden Business-Intelligence-Architektur, nicht nur hinsichtlich der verschiedenen BI-Systemkomponenten, sondern auch bezüglich verschiedener Abstraktionsebenen der Modellierung.

Somit erscheint es nicht nur folgerichtig, sondern darüber hinaus sehr begrüßenswert, dass mein langjähriger Wegbegleiter und ein ausgewiesener Experte im BI-Sektor Dr. Michael Hahne sich der Modellierung von Business-Intelligence-Systemen umfassend angenommen hat, zumal eine derartige Abhandlung zumindest im deutschsprachigen Raum bislang nicht zu finden war. Da der Autor selbst im Projektgeschäft tätig ist und daher ständig mit den Herausforderungen in der BI-Praxis konfrontiert wird, erweist sich das vorliegende Werk als hochgradig relevant für alle Mitarbeiter aus Anwenderunternehmen und Beratungshäusern, deren Aufgaben in der Konzeption und Implementierung tragfähiger BI-Lösungen liegen. Aber auch bei der Ausbildung von Studierenden in den Bereichen Informatik und vor allem Wirtschaftsinformatik leistet das vorliegende Buch wertvolle Unterstützung.

Inhaltlich deckt das Werk ein breites Spektrum unterschiedlicher Facetten der Modellierung von BI-Systemen ab. Ausgehend von den Grundbestandteilen multidimensionaler Datenmodelle reicht die Betrachtung von semantischen Modellierungstechniken (ADAPT) über die ROLAP-Datenmodellierung (Star- und Snowflake-Schema) mit Dimensions- und Faktentabellenmodellierung bis hin zu den aktuellen Data-Vault-Konzepten für das Core Data Warehouse. Ein eigenes Kapitel widmet sich überdies dem sehr interessanten Thema der Historisierung. Die durchgängige Unterlegung der Ausführungen mit gut nachvollziehbaren Anwendungsbeispielen fördert die Verständlichkeit und stiftet unmittelbaren Mehrwert.

Ich wünsche allen Lesern bei der Lektüre viel Vergnügen und bin sicher, dass sich hilfreiche Erkenntnisse schnell einstellen werden.

Prof. Dr. Peter Gluchowski

Herdecke, im April 2014

Vorwort

Seit vielen Jahren bietet TDWI (The Data Warehousing Institute) Germany e.V.1 mit seinem Seminar- und Konferenzprogramm umfassende Weiterbildungsangebote im Bereich Business Intelligence und Data Warehousing. Als Gründungsmitglied war ich von Anfang an dabei und bin u. a. Referent der Seminare zu Themen der Gestaltung und Architektur von Business-Intelligence-(BI-)Systemen. Und immer kam die Frage bei meinen Seminarteilnehmern auf, welche Literaturempfehlungen es denn gibt, und der Wunsch nach einem deutschsprachigen Buch zur Modellierung von BI-Systemen trat immer deutlicher zutage. Als dann das TDWI-Buchprogramm unter der Herausgeberschaft von Marcus Pilz erfolgreich startete, wurde die Idee zum Projekt, dessen Ergebnis nun in Ihren Händen liegt.

Zum Aufbau des Buches

Das Buch startet in Kapitel 1 mit der Darstellung der verschiedenen Architekturvarianten von Business-Intelligence-Landschaften. Dabei erfolgt neben der vergleichenden Betrachtung der Ansätze von Kimball und Inmon auch eine Darstellung von mehrschichtigen Architekturen.

Die Darstellung des Wesens mehrdimensionaler Datenstrukturen, Grundparadigma von Data Marts, erfolgt in Kapitel 2. Gerade für OLAP-Anwendungen ist dies ganz essenziell, sind dies doch die Objekte, auf deren Basis Analyse und Reporting vornehmlich stattfinden. Dabei stehen neben den vier konstituierenden Strukturkomponenten der Kennzahlen, Dimensionen, Hierarchien und Regeln auch Aspekte der Historisierung im Fokus. Dies beantwortet die Frage »Was ist das?«. Im anschließenden dritten Kapitel steht die Gestaltung dieser mehrdimensionalen Datenstrukturen auf fachlich konzeptioneller Ebene im Vordergrund und berücksichtigt die Fragestellung »Wie kann es gestaltet werden?«.

Eine Option der Implementierung von mehrdimensionalen Datenstrukturen auf Basis relationaler Datenbanktechnologie ist mit dem Modellierungsansatz des Star-Schemas gegeben. Kapitel 4 betrachtet zunächst die Grundlagen dieses Modellierungsansatzes. In Kapitel 5 erfolgt die eingehende Diskussion der Berücksichtigung von Historisierungsanforderungen und temporalen Aspekten. Eine eingehende Diskussion der im Kontext der Modellierung von Dimensionen relevanten Varianten des Star-Schema-Ansatzes ist Gegenstand von Kapitel 6. Für die Gestaltung von Faktentabellen sind u. a. Themen der Additivität sowie von Bestands- und Flussgrößen relevant. Neben den Gestaltungsempfehlungen für die Modellierung von Faktentabellen ist dies Gegenstand der Betrachtung in Kapitel 7. Insbesondere aufgrund der Bedeutung in den Projekten nehmen Aspekte der Star-Schema-Modellierung einen großen Teil des Buches ein, denn sie beantworten die Frage »Wie kann es implementiert werden?«.

In der Perspektive einer ganzheitlichen Data-Warehouse-Architektur stehen die Data Marts zwar dem Endbenutzer am nächsten, aber diese müssen ja auch im Rahmen eines Datenintegrationsprozesses bewirtschaftet werden. Dies erfolgt oftmals auf Basis eines zentralen Repositoriums etwa in Form eines Core Data Warehouse. Kapitel 8 widmet sich der Gestaltung dieser sehr wichtigen zentralen Komponente in einer Data-Warehouse-Architektur, denn diese ist wesentlich für die Aufgaben der Integration und Harmonisierung von Daten unterschiedlichster Quellen verantwortlich. Leitgedanke ist dabei die Frage »Woher kommt es?«.

Der rote Faden des Buches ist über die mehrdimensionalen Datenstrukturen folgendermaßen festgelegt: Beschreibung des Wesens, der Methoden der fachlichen Gestaltung, der Übertragung auf die Ebene der Implementierung und schließlich der Aspekte der Bewirtschaftung. Das Buch bietet damit eine ganzheitliche Darstellung aller Facetten der Modellierung für Business-Intelligence-Systeme, stellt adäquate Methoden dar und präsentiert Gestaltungsempfehlungen.

Für wen ist das Buch

Das Buch wendet sich an Projektleiter und Projektmitarbeiter von Data-Warehouse-und Business-Intelligence-Projekten, an Mitarbeiter aus IT und Informationsmanagement sowie an interessierte Fach- und Führungskräfte aus allen Unternehmensbereichen.

Danksagung

Wer schon mal ein Buch geschrieben hat, weiß, dass dies harte Arbeit ist und sehr viel Zeit kostet. Dieses Buchprojekt hat mehrere Jahre gedauert. Dabei blieben andere Dinge auf der Strecke liegen und die Familie musste oft zurückstecken. Ich danke meiner Frau und meinen Kindern für ihr Verständnis und die mir geschaffenen Freiräume, ohne die dieses Projekt nicht zu bewerkstelligen gewesen wäre.

Wesentlich für die Abrundung der Inhalte und auch die Erweiterung meiner vielleicht auch mal eingefahrenen Sichtweise waren die vielen fachlichen Diskussionen in Seminaren, im Kreis der Veranstaltungen des TDWI und insbesondere mit meinem Fachlektor Prof. Dr. Peter Gluchowski, mit dem mich seit nunmehr zwei Jahrzehnten die gemeinsame Leidenschaft für die Themen Data Warehousing und Business Intelligence verbindet. Viele gemeinsame Projekte und Veröffentlichungen haben sich dabei als sehr fruchtbar für die Entwicklung des Themas herausgestellt.

Mein besonderer Dank gilt allen Mitarbeitern des dpunkt.verlags und an erster Stelle Christa Preisendanz, deren Geduld immer wieder auf eine harte Probe gestellt wurde und die trotz vieler Verzögerungen das Projekt tatkräftig unterstützt hat. Ihr ist zu verdanken, dass die tief in der technischen Wolke entstandenen Satzkonstruktionen wieder zu einem lesbaren und korrekten Deutsch gefunden haben.

Über Ihre Anregungen und Kommentare als Leser des Buches freue ich mich und wünsche Ihnen viel Vergnügen sowie hilfreiche Ideen und Anregungen bei der Lektüre.

Dr. Michael Hahne

Bretzenheim, im April 2014

Inhaltsverzeichnis

1 Business-Intelligence-Architektur

1.1 Data Warehouse

1.2 OLAP und mehrdimensionale Datenbanken

1.3 Architekturvarianten

1.3.1 Stove-Pipe-Ansatz

1.3.2 Data Marts mit abgestimmten Datenmodellen

1.3.3 Core Data Warehouse

1.3.4 Hub-and-Spoke-Architektur

1.3.5 Data-Mart-Busarchitektur nach Kimball

1.3.6 Corporate Information Factory nach Inmon

1.3.7 Architekturvergleich Kimball und Inmon

1.4 Schichtenmodell der BI-Architektur

1.4.1 Acquisition Layer

1.4.2 Integration Layer

1.4.3 Reporting Layer

1.4.4 Modellierung im Schichtenmodell

2 Mehrdimensionale Datenstrukturen

2.1 Datenmodelle und Datenmodellierung

2.2 Grundbestandteile mehrdimensionaler Datenstrukturen

2.3 Hierarchische Dimensionsstrukturen

2.3.1 Strukturlose Dimensionen

2.3.2 Balancierte Baumstrukturen

2.3.3 Balancierte Waldstrukturen

2.3.4 Unbalancierte Baum- und Waldstrukturen

2.3.5 Parallele Hierarchien

2.3.6 Heterarchien (Many-Many-Beziehungen)

2.3.7 Rekursive Hierarchien und bebuchbare Knoten

2.3.8 Hierarchieattribute

2.4 Kennzahlen und deren Berechnung

2.4.1 Kennzahlen und Kennzahlensysteme

2.4.2 Kennzahlen im mehrdimensionalen Modell

2.4.3 Additivitätseigenschaft

2.5 Historisierung und Zeitabhängigkeit

3 Semantische mehrdimensionale Modellierung

3.1 Methoden auf Basis der Entity-Relationship-Modellierung

3.1.1 Grundbestandteile der ER-Modellierung

3.1.2 Erweiterte ERM-Konstrukte

3.1.3 ER-basierte mehrdimensionale Modellierung

3.1.4 Mehrdimensionales ER-Modell (ME/R)

3.2 Mehrdimensionale Modellierung mit ADAPT

3.2.1 Dimensionsmodellierung in ADAPT

3.2.2 Varianten der Hierarchiemodellierung

3.2.3 Modellierung von Würfeln

3.3 T-ADAPT: Modellierung von Zeitabhängigkeit

4 Bestandteile und Varianten des Star-Schemas

4.1 Einfaches Star-Schema

4.1.1 Grundform des Star-Schemas

4.1.2 Abbildung von Kennzahlen und Kennzahlensystemen

4.1.3 Attribute in Dimensionen

4.2 Modellierung von Dimensionshierarchien

4.2.1 Flache Strukturen

4.2.2 Balancierte Baum- und Waldstrukturen

4.2.3 Unbalancierte Strukturen

4.2.4 Parallele Hierarchien

4.2.5 Anteilige Verrechnung und Heterarchien

4.3 Normalisierung von Dimensionen

4.4 Übergang von T-ADAPT zum logischen Modell

4.4.1 Transformation von Dimensionen

4.4.2 Abbildung von Attributen

4.4.3 Transformation von Scopes

4.4.4 Behandlung spezieller ADAPT-Varianten

4.5 Modellierung von Parent-Child-Hierarchien

4.5.1 Iterative Abfrage

4.5.2 Einstufige Rekursion

4.5.3 Mehrstufige Rekursion

4.5.4 Rekursives SQL

4.5.5 Brückentabellen

5 Historisierung und Zeitabhängigkeit im Data Warehouse

5.1 Historisierung im Star-Schema

5.1.1 Keine Historisierung bei Type 0 und Type 1

5.1.2 Type-3-Attribut-Paare

5.1.3 Versionen und Zeitstempelung für as is und as of

5.2 Bewegungsdatensicht in der Historisierung

5.2.1 As-posted-Type-2-Szenario

5.2.2 Snapshot-Verfahren

5.2.3 Vollständige Zeitstempelung plus as posted

5.2.4 Varianten für hybride Historisierung

5.3 Best Practices der Historisierung

5.4 Bitemporale Historisierung

6 Dimensionsmodellierung

6.1 Dimensionstabellen

6.1.1 Degenerierte Dimensionen

6.1.2 Housekeeping und technische Dimensionen

6.1.3 Große Dimensionen

6.1.4 Mehrsprachigkeit

6.1.5 Outrigger-Tabellen

6.2 Rollen von Dimensionen

6.3 Many-Many-Beziehungen

6.3.1 Heterarchien über Faktentabellen

6.3.2 Mehrwertige Dimensionen (multi valued dimensions)

6.3.3 Many-Many-Beziehungen über Dimensionen

6.3.4 Mehrwertige Attribute

6.4 Datum- und Zeitdimension

7 Faktenmodellierung

7.1 Kennzahlen und Kennzahlensysteme

7.2 Aggregate

7.3 Snowflake-Schema

7.4 Faktenlose Faktentabellen

7.5 Granularität

7.6 Additivität und berechnete Kennzahlen

7.6.1 Transaktionsfaktentabellen

7.6.2 Bestandsmodelle

7.6.3 Prozessmodelle

7.7 Abgeleitete Schemata

8 Core-Data-Warehouse-Modellierung

8.1 Aufgaben der Data-Warehouse-Komponenten

8.1.1 Datenintegrations-Framework

8.1.2 Aufgaben und Komponenten in Multi-Layer-Architekturen

8.1.3 Eignungskriterien für Methoden der Core-Data-Warehouse-Modellierung

8.2 Star-Schema-Modellierung im Core Data Warehouse

8.2.1 Granulare Star-Schemata im Core Data Warehouse

8.2.2 Bewertung dimensionaler Core-Data-Warehouse-Modelle

8.3 3NF-Modelle im Core Data Warehouse

8.3.1 Core-Data-Warehouse-Modellierung in 3NF

8.3.2 Historisierungsaspekte von 3NF-Modellen

8.3.3 Bewertung der 3NF-Modellierung im Core Data Warehouse

8.4 Data-Vault-Ansatz

8.4.1 Hub-Tabellen

8.4.2 Satellite-Tabellen

8.4.3 Link-Tabellen

8.4.4 Zeitstempel im Data Vault

8.4.5 Harmonisierung von fachlichen Schlüsseln

8.4.6 Agilität in Data-Vault-Modellen

8.4.7 Vorgehensweise zur Data-Vault-Gestaltung

8.4.8 Bewertung der Data-Vault-Methode

Anhang

A Abkürzungen

B Literaturverzeichnis

Index

1 Business-Intelligence-Architektur

Unter dem Sammelbegriff Business Intelligence werden Konzepte des Data Warehouse, OLAP und Data Mining diskutiert. Durch die zunehmend strategische Ausrichtung der Informationsverarbeitung erhalten diese Konzepte einen neuen Stellenwert in der Praxis. Unter dem Begriff Analyseorientiertes Informationssystem werden Systemlösungen im Bereich Business Intelligence mit der Ausrichtung an der Analyseanforderung zusammengefasst.

Der Fokus analyseorientierter Informationssysteme liegt in der zeitnahen Versorgung betrieblicher Entscheidungsträger mit relevanten Informationen zu Analysezwecken. Diese Systeme zielen somit auf die Unterstützung der dispositiven und strategischen Prozesse in einem Unternehmen ab und bilden damit ein logisches Pendant zu den operativen Systemen, die zumeist in Form einer integrierten betriebswirtschaftlichen Standardsoftware wie z. B. SAP ECC (ERP Central Component) eingesetzt werden.

1.1 Data Warehouse

Allen analyseorientierten Informationssystemen gemeinsam ist eine geeignete zugrunde liegende Datenbasis. Diese bildet damit eine wesentliche Komponente, auf deren Grundlage die verschiedenen Auswertungssysteme aufsetzen. Dem Aufbau dieser zentralen Datenbasis widmet sich die Diskussion seit einigen Jahren unter dem Stichwort Data Warehouse. Hierunter soll im Folgenden ein unternehmensweites Konzept verstanden werden, dessen Ziel es ist, eine logisch zentrale, einheitliche und konsistente Datenbasis für die vielfältigen Anwendungen zur Unterstützung der analytischen Aufgaben von Führungskräften aufzubauen, die losgelöst von den operativen Datenbanken betrieben wird.

Der Begriff Data Warehouse geht auf Inmon zurück. Inmon beschreibt ihn mit der Aufgabe, Daten zur Unterstützung von Managemententscheidungen bereitzustellen, die die folgenden vier wesentlichen Eigenschaften aufweisen [Inmon 1996, S. 33]:

Themenorientierung

Vereinheitlichung

Zeitorientierung

Beständigkeit

Die in einem Data Warehouse abzulegenden Daten orientieren sich an dem Informationsbedarf von Entscheidungsträgern und beziehen sich demnach auf Sachverhalte, die das Handeln und den Erfolg eines Unternehmens bestimmen. Die Daten fokussieren sich daher auf die Kernbereiche der Organisation. Diese datenorientierte Vorgehensweise unterscheidet sich deutlich von den prozessorientierten Konzepten der operativen Anwendungen.

Eine wesentliche Eigenschaft eines Data Warehouse ist ein konsistenter Datenbestand, der durch eine Vereinheitlichung der Daten vor der Übernahme entsteht. Diese Vereinheitlichung bezieht sich sowohl auf die Struktur wie auch auf die Formate, häufig müssen die verwendeten Begriffe, Codierungen und Maßeinheiten zusammengeführt werden.

Für die Managementunterstützung werden Daten benötigt, die die Entwicklung des Unternehmens über einen bestimmten Zeitraum repräsentieren und zur Erkennung und Untersuchung von Trends herangezogen werden. Dazu wird der Data-Warehouse-Datenbestand periodisch aktualisiert und der Zeitpunkt der letzten Aktualisierung definiert damit einen Schnappschuss des Unternehmensgeschehens, der je nach Ladezyklus Minuten, Stunden, Tage, Wochen oder Monate zurückliegen kann.

Der Begriff Data Warehouse beschreibt ein unternehmensweites Konzept, dessen Ziel die Bereitstellung einer einheitlichen konsistenten Datenbasis für die vielfältigen Anwendungen zur Unterstützung der analytischen Aufgaben von Fach- und Führungskräften ist. Diese Datenbasis ist losgelöst von operativen Datenbanken zu betreiben.

Das vierte wesentliche Charakteristikum bezieht sich auf die Beständigkeit der Daten in einem Data Warehouse. Da diese in der Regel nur einmal geladen und danach nicht mehr geändert werden, erfolgt ein Datenzugriff im Allgemeinen nur lesend. Einmal erstellte Berichte auf Basis dieses Datenbestands sind daher reproduzierbar, da auch in späteren Perioden die Datenbasis die gleiche ist. Diese Eigenschaft wird mit dem Begriff der Nicht-Volatilität umschrieben.1 Die Beständigkeit bezieht sich aber auch auf ein verlässliches annähernd gleichbleibendes Antwortzeitverhalten.

Die Einordnung eines Data Warehouse in die IT-Struktur eines Unternehmens ergibt sich aus der in Abbildung 1–1 dargestellten Referenzarchitektur. Ausgangsbasis dieser Architektur sind die operativen Vorsysteme, aus denen periodisch Datenextrakte generiert werden. Im Rahmen des ETL-Prozesses (extract transform load, ETL) erfolgen die Bereinigung und Transformation der Daten aus den verschiedenen Vorsystemen sowie externen Datenquellen zu einem konsistenten einheitlichen Datenbestand und der Transport in das Data Warehouse. Hierbei sind die beiden Phasen des erstmaligen Befüllens sowie der regelmäßigen periodischen Aktualisierungen zu unterscheiden.

Dieser ETL-Komponente kommt beim Aufbau eines Data Warehouse eine zentrale Bedeutung zu, denn ein hoher Anteil des Aufwands beim Aufbau eines Data Warehouse resultiert aus der Implementierung von Zugriffsstrategien auf die operativen Datenhaltungseinrichtungen.2

Abb. 1–1 Data-Warehouse-Referenzarchitektur

Aus diesem Datenbestand können des Weiteren kleinere funktions- oder bereichsbezogene Teilsichten in sogenannten Data Marts extrahiert werden. Diese müssen wiederum periodisch aus dem Data-Warehouse-Datenbestand aktualisiert werden. Für diese Teildatenbestände kommen im Allgemeinen sogenannte OLAP-Datenbanken zum Einsatz, deren Diskussion Gegenstand des nächsten Abschnittes ist.

Die Auswertung über die Frontend-Applikationen kann sowohl direkt auf dem zentralen Data Warehouse erfolgen als auch auf den einzelnen Data Marts aufsetzen. In Data-Warehouse-Konzepten können auch Applikationen wie beispielsweise Management-Support-Systeme auf diesen Datenbeständen basieren, d. h., die Datenbasis für diese Systeme kann auch in einem Data Warehouse liegen. Hier verbinden sich also bekannte Konzepte des Managementsupports mit dem neuen Konzept des Data Warehouse zu einer neuen Systemkategorie. Eine weitere wesentliche Erweiterung ergibt sich aus dem Ansatz des Online Analytical Processing (OLAP), der im folgenden Abschnitt dargestellt wird.

1.2 OLAP und mehrdimensionale Datenbanken

Der Begriff OLAP beschreibt ein Leitbild für eine endanwenderorientierte Analysetechnik und wird häufig konträr zum sogenannten Online Transaction Processing (OLTP) gesehen. Online Analytical Processing (OLAP) ist ein mittlerweile anerkannter Bestandteil für eine angemessene DV-Unterstützung betrieblicher Fach- und Führungskräfte und bietet einen endanwenderorientierten Gestaltungsrahmen für den Aufbau von Systemen zur Unterstützung dispositiver bzw. analytischer Aufgaben [Gluchowski/Chamoni 2009, S. 197 ff.].

Als zentrales Charakteristikum gewährleisten multidimensionale Sichtweisen auf unternehmensinterne und -externe Datenbestände brauchbare Näherungen an das mentale Unternehmensbild des Managers. Betriebswirtschaftliche Variablen bzw. Kennzahlen (wie z. B. Umsatz oder Kostengrößen) werden entlang unterschiedlicher Dimensionen (wie z. B. Kunden, Artikel, Regionen) angeordnet, und diese Strukturierung gilt als geeignete entscheidungsorientierte Sichtweise auf betriebswirtschaftliches Zahlenmaterial. Bildlich gesprochen werden die quantitativen Kenngrößen in mehrdimensionalen Würfeln gespeichert, deren Kanten durch die einzelnen Dimensionen definiert und beschriftet sind.

OLAP soll es Benutzern ermöglichen, flexible komplexe betriebswirtschaftliche Analysen wie auch Ad-hoc-Auswertungen mit geringem Aufwand eigenständig durchführen zu können. Um dieses Ziel zu erreichen, wurden von Codd, Codd und Sally 12 Regeln als Anforderung an OLAP-Lösungen definiert:3

1. Die mehrdimensionale konzeptionelle Sicht auf die Daten wird als elementarstes Wesensmerkmal für OLAP postuliert. Diese Darstellungsform ermöglicht eine Navigation in den Datenwürfeln mit beliebigen Projektionen und Verdichtungs- und Detaildarstellungen.

2. Transparenz beschreibt die nahtlose Integration in Benutzerumgebungen.

3. Eine offene Architektur gewährleistet Zugriffsmöglichkeiten auf heterogene Datenbasen, eingebunden in eine logische Gesamtsicht.

4. Ein gleichbleibendes Antwortzeitverhalten, selbst bei vielen Dimensionen und sehr großen Datenvolumina, ist ein wesentlicher Aspekt.

5. Postuliert wird auf Basis einer Client-Server-Architektur die Möglichkeit verteilter Datenhaltung sowie der verteilten Programmausführung.

6. Aufgrund der generischen Dimensionalität stimmen alle Dimensionen in ihren Verwendungsmöglichkeiten überein.

7. Betriebswirtschaftliche mehrdimensionale Modelle sind oft sehr gering besetzt. Das dynamische Handling »dünnbesetzter Würfel« ist elementar für eine optimale physikalische Datenspeicherung.

8. Unter Mehrbenutzerfähigkeit in OLAP-Systemen wird der gleichzeitige Zugriff verschiedener Benutzer auf die Analysedatenbestände, verbunden mit einem Sicherheits- und Berechtigungskonzept, verstanden.

9. Der Kennzahlenberechnung und Konsolidierung dienen unbeschränkte dimensionsübergreifende Operationen innerhalb einer vollständigen integrierten Datenmanipulationssprache.

10. Eine ergonomische Benutzerführung soll intuitive Datenmanipulation und Navigation im Datenraum ermöglichen.

11. Auf Basis des mehrdimensionalen Modells soll ein leichtes und flexibles Berichtswesen generiert werden können.

12. Die Forderung nach einer unbegrenzten Anzahl an Dimensionen und Aggregationsebenen ist in der Praxis schwer realisierbar.

Dieses Regelwerk ist nicht unumstritten und erfuhr verschiedene Erweiterungsvorschläge u. a. von der Gartner Group [Gartner 1995].4 Eine etwas pragmatischere und technologiefreie Variante zur Definition der konstituierenden Charakteristika von OLAP stammt von Pendse und Creeth, die ihren Ansatz mit FASMI benennen [Pendse/Creeth 1995]:

1. Fast: Ganz konkret wird für das Antwortzeitverhalten ein Grenzwert von zwei Sekunden für Standardabfragen und 20 Sekunden für komplexe Analysen festgelegt.

2. Analysis: Benutzern muss es ohne detaillierte Programmierkenntnis möglich sein, analytische Berechnungen und Strukturuntersuchungen auf Basis definierter Verfahren und Techniken ad hoc zu formulieren.

3. Shared: Für den Mehrbenutzerbetrieb werden Berechtigungsmöglichkeiten bis auf Datenelementebene sowie Sperrmechanismen bei konkurrierenden Schreibzugriffen gefordert.

4. Multidimensional: Die mehrdimensionale Sichtweise ist ein elementares Wesensmerkmal analytischer Systeme.

5. Information: Für OLAP-Systeme ist die verwaltbare Informationsmenge bei stabilem Antwortzeitverhalten ein kritischer Bewertungsfaktor.

Verschiedene Ansätze zur Definition dessen, was OLAP ausmacht, resultieren in der Anforderung nach Vereinheitlichung und dem Setzen von Standards. Dieses hat sich der OLAP-Council zum Ziel gesetzt.5 Diese Diskussion ist losgelöst von Implementierungsaspekten, für die es jedoch gleichermaßen verschiedenste Architekturansätze gibt.

Online Analytical Processing (OLAP) als Grundprinzip für den Aufbau von Systemen zur Unterstützung von Fach- und Führungskräften in ihren analytisch geprägten Aufgaben basiert im Kern auf einer mehrdimensionalen konzeptionellen Sicht auf die Daten mit Möglichkeiten der Navigation in den Würfeln mit beliebigen Projektionen und auf verschiedenen Verdichtungsstufen.

1.3 Architekturvarianten

Die Architektur von BI-Systemen dient der Beschreibung der wesentlichen Komponenten mit ihren Eigenschaften und Funktionen sowie deren Beziehung untereinander. Dabei sind in der Praxis sehr unterschiedliche Formen und Ausgestaltungen anzutreffen, die nicht immer aufgrund proaktiver Entscheidungen etwa aus einer BIOrganisation heraus entstehen, sondern oft das Ergebnis historisch gewachsener Landschaften sind. Jedoch zeigt sich, dass eine saubere Architektur als Grundlage für die BI-Systeme in Unternehmen Vorteile für Entwicklung und Betrieb mit sich bringt. Dies drückt sich auch in der zunehmend bedeutenden Rolle des BI-Architekten aus.6

Bekannte Architekturvarianten unterscheiden sich deutlich hinsichtlich der Anzahl der Komponenten, der gesamten Komplexität, des Aufwands für Entwicklung und Betrieb sowie der Performance und Skalierbarkeit. Aber auch die Fähigkeit, effizient und agil mit neuen Anforderungen umzugehen und den Wandel zu unterstützen, ist ein wesentliches Erfolgskriterium für verschiedene Ansätze.7

1.3.1 Stove-Pipe-Ansatz

In den Fällen, in denen im Unternehmen keine übergreifenden Auswertungen erforderlich sind, kann eine dezentrale Architektur mit unabhängigen Data Marts wie in Abbildung 1–2 dargestellt durchaus sinnvoll sein. Bei diesem Ansatz, auch unter dem Namen »Stove Pipe« (Ofenrohr) bekannt [Kimball et al. 2008, S. 249], entstehen einzelne Silos bzw. Inseln, da die Daten für jeden Anwendungsbereich isoliert aus den Quellsystemen extrahiert und aufbereitet werden [Kemper et al. 2010, S. 22 f.]. Dabei erfolgt die Transformation der Daten redundant, was auch zu entsprechenden Aufwänden und potenziellen Inkonsistenzen im Falle einer Änderung führt.

Diese Datensilos sind nur eingeschränkt in einem anderen Kontext nutzbar und bieten damit eine sehr schlechte Unterstützung für bereichsübergreifende Auswertungen. Für autonome Organisationseinheiten kann dieser Ansatz aufgrund der leichteren Berücksichtigung fachlicher Anforderungen jedoch durchaus geeignet sein [Sinz/Ulbrich-vom-Ende 2009, S. 189 f.]. Oftmals handelt es sich aber um eine rein historisch gewachsene Struktur, die den im Zeitablauf gestiegenen Anforderungen nicht mehr gerecht wird.

Abb. 1–2 Unabhängige Data Marts

Der Übergang von einer derartigen Struktur mit unabhängigen Data Marts zu einer besser geeigneten Architektur mit logischer Integration der Daten gestaltet sich im Allgemeinen recht schwierig, da es auch keine standardisierten bewährten Migrationskonzepte gibt. Dies wird auch durch empirische Untersuchungen untermauert.8

Der Stove-Pipe-Ansatz ist oftmals historisch bedingt und liefert keine Integration, sondern isolierte Data Marts.

1.3.2 Data Marts mit abgestimmten Datenmodellen

Eine erste Möglichkeit zur Entschärfung der Probleme des Stove-Pipe-Ansatzes besteht in der Abstimmung der Data-Mart-Datenmodelle bzw. Dimensionsstruktur (conformed dimensions, siehe Abb. 1–3). Diese erleichtern die Gewährleistung von Konsistenz und Integrität der dispositiven Daten. Neben den Dimensionen sind auch die Kennzahlen abgestimmt, man spricht hier von conformed facts.

Die Abstimmung und der Aufbau eines konsolidierten Datenbestands erfolgt dabei virtuell durch die Abstimmung und Koordination zwischen den Unternehmensbereichen ohne den Aufwand für dessen Entwicklung. Andererseits geht dies einher mit einem erhöhten Aufwand für die Abstimmung [Sinz/Ulbrich-vom-Ende 2009, S. 191].

Abb. 1–3 Abgestimmte Data-Mart-Modelle (Conformed)

Auch bei dieser Gestaltungsalternative erfolgen die Transformationen redundant, sodass die Risiken möglicher Inkonsistenzen sowie erhöhte Aufwände im Fall einer Änderung bestehen bleiben.

Die Ausprägung der Data Marts geschieht typischerweise kontextbezogen, sodass sich diese hinsichtlich der Granularität in allen Dimensionen unterscheiden. Des Weiteren berücksichtigen diese Data Marts ggf. unterschiedliche betriebswirtschaftliche Anreicherungen und basieren auf verschiedenen Aggregationsniveaus in den Dimensionshierarchien. Somit bleiben übergreifende Auswertungen oftmals mit Informationsverlusten verbunden.

1.3.3 Core Data Warehouse

Sind für die analytischen Anwendungen nur Daten aus einer Anwendungsdomäne zu berücksichtigen, kann der Verzicht auf Data Marts eine Alternative sein. Stattdessen ist ein zentrales Core Data Warehouse aufzubauen, auf dem die Analysen direkt erfolgen. Neben dem Aspekt der Analyse hat ein Core Data Warehouse auch eine Sammel- und Integrationsfunktion. Es gewährleistet dadurch die Qualitätssicherung und hat eine Distributionsfunktion.

Dieser in Abbildung 1–4 visualisierte Architekturansatz stößt hinsichtlich der Anzahl der Benutzer schnell an seine Grenzen und ist kritisch bei einem größeren Datenvolumen, auf dem direkt Auswertungen stattfinden [Sinz/Ulbrich-vom-Ende 2009, S. 188]. Aufgrund der fehlenden anwendungsspezifischen Aufbereitung dispositiver Daten ist dieser Ansatz nicht für verschiedene ggf. zu integrierende Anwendungsdomänen geeignet, da es an der kontextbezogenen Aggregation betriebswirtschaftlicher Daten mangelt.

Abb. 1–4 Zentrales Core Data Warehouse

Auf Basis der zentralen Architektur eines Core Data Warehouse sind Betrieb und Pflege des Systems zunächst leichter zu realisieren als bei einer Silo-Architektur. Aufgrund der wenigen Komponenten sind auch Änderungen in den Datenstrukturen direkt für alle Anwendungen sichtbar. Dadurch stehen Änderungen im Rahmen eines Change-Prozesses relativ schnell zur Verfügung. Komplexere Lösungen stoßen aber aus Performance- und Administrationsgründen schnell an ihre Grenzen [Kemper et al. 2010, S. 23].

In einem Core Data Warehouse erfolgt die Speicherung dispositiver Daten nach ersten Transformationsschritten der Bereinigung und Harmonisierung für unterschiedlichste Auswertungszwecke für eine Vielzahl von Benutzern und weist daher einen hohen Grad von Mehrfachverwendbarkeit der Daten zusammen mit einer starken Detaillierung auf.

Gerade die Integrationsfunktion eines Core Data Warehouse ermöglicht Analysen auf abgestimmten harmonisierten Datenbeständen. Jedoch stößt dies bei mehreren Geschäftsfeldern mit stark divergierenden Geschäftsprozessen an seine Grenzen, da eine Integration auf allen Ebenen für alle Bereiche oftmals nicht sinnvoll mit vertretbarem Kostenaufwand realisierbar ist.

In diesen Fällen, in denen einzelne Geschäftseinheiten durch unterschiedliche Produkt- oder Marktstrukturen gekennzeichnet sind, ist der Einsatz mehrerer autarker Core Data Warehouses sinnvoll, die jeweils auf die Anforderungen einer strategischen Einheit fokussieren. Dies ist exemplarisch in Abbildung 1–5 dargestellt.

Abb. 1–5 Mehrere Core Data Warehouses

Eine solche Architektur mit mehreren Core Data Warehouses findet sich typischerweise bei Konzernen und spartenorientierten Unternehmen.

In Konzernen und Unternehmen mit sehr unterschiedlichen Geschäftsprozessen sind oftmals einzelne Core Data Warehouses für jede strategische Geschäftseinheit vorzufinden.

1.3.4 Hub-and-Spoke-Architektur

Ein Core Data Warehouse ist eine zentrale Architekturkomponente in vielen Varianten von BI-Architekturen, da es sehr gut geeignet ist, um die folgenden Funktionen zu erfüllen [Kemper et al. 2010, S. 39 f.]:

Sammlung und Integration von dispositiven Daten

Distribution, also Verteilung der abgestimmten Daten an nachgelagerte Komponenten wie etwa Data Marts

Qualitätssicherung, da die syntaktische und semantische Stimmigkeit der dispositiven Daten durch die Integration und Harmonisierung gesichert ist

Die Distributionsfunktion kommt insbesondere in der um Data Marts erweiterten Architektur zum Tragen, denn aus dem Core Data Warehouse erfolgt die Bewirtschaftung der Data Marts auf Basis geeigneter Aggregations- und Transformationsprozesse. Oftmals wird diese Form daher auch als Hub-and-Spoke-Architektur bezeichnet.

Die Data Marts sind dabei im Regelfall immer noch unterschiedlich hinsichtlich ihrer Granularität9 in allen Dimensionen, der Verwendung unterschiedlicher Formen der Aggregation und Nutzung verschiedener Dimensionshierarchien sowie auch bezogen auf die betriebswirtschaftliche Anreicherung. Da sich die Data Marts aus dem Core Data Warehouse ableiten, wird auch von abhängigen Data Marts gesprochen (vgl. [Gluchowski et al. 2008, S. 129f.]).

Die Vorteile einer solchen Architektur können direkt aus Abbildung 1–6 abgeleitet werden, denn es treten viel weniger Schnittstellen auf, sodass die Logik zur Transformation nicht redundant vorzufinden ist. Ein weiterer Vorteil der Architektur liegt in der zentralen Datenintegration und Aufbereitung. Im Wesentlichen ist dies auch die Grundlage des Architekturverständnisses nach Inmon mit der Corporate Information Factory (CIF) (siehe Abschnitt 1.3.6 sowie [Inmon et al. 2001]).

In einer Hub-and-Spoke-Architektur dient das Core Data Warehouse als Hub und erfüllt die Aufgabe der Integration, Qualitätssicherung und Datenverteilung an die Data Marts als Spokes, die einen hohen Grad an Anwendungsorientierung und vordefinierte betriebswirtschaftliche Anreicherungen und Aggregationen aufweisen.

Abb. 1–6 Core Data Warehouse mit abhängigen Data Marts

In der Praxis findet sich jedoch häufig ein Mix verschiedener Architekturansätze wie in Abbildung 1–7 exemplarisch dargestellt, der teilweise historisch entstanden oder aber das Ergebnis bewusster Gestaltung sein kann.

Abb. 1–7 Gemischte Architektur

In dem Beispiel in Abbildung 1–7 ist erkennbar, dass teilweise auch virtuelle Data Warehouses eingesetzt werden. Diese ermöglichen einen direkten Zugriff auf die Daten des Core Data Warehouse. Dieser Aspekt wird zunehmend kontrovers diskutiert, und die Frage, ob das Core Data Warehouse direkt abgefragt werden darf, ist nicht eindeutig zu beantworten. Aufgrund der negativen Erfahrungen der Vergangenheit findet dieser Ansatz aber immer weniger Zuspruch.

Grenzen bei der Analyse direkt auf dem zentralen Datenbestand ergeben sich unter anderem durch die zunehmend großen Datenvolumina und die Gefahr von Abfragen, die sehr langsam sind und damit das System sehr stark beanspruchen.

1.3.5 Data-Mart-Busarchitektur nach Kimball

In der Sichtweise nach Kimball sollte ein Core Data Warehouse dimensional modelliert sein [Kimball/Ross 2002, S. 10 ff.]. Er nennt es Dimensional Data Warehouse. Es handelt sich hierbei um ein Repository, das sehr wohl für Auswertungen genutzt werden soll bzw. kann. Die einzelnen Data Marts dieser sogenannten Data-Mart-Busarchitektur werden auch Subject Areas genannt.

Bei dieser Architektur gibt es demzufolge ein zentrales Repository, das wie in Abbildung 1–8 verdeutlicht, zwar im Sinne eines Hubs die Data Marts bedient, jedoch selbst schon ein mehrdimensionales Modell der integrierten atomaren Daten darstellt. Daher auch der Name Dimensional Data Warehouse für das Repository, das ebenfalls atomare Granularität aufweist.

Abb. 1–8 Data-Warehouse-Architektur nach Kimball [Kimball 2002]

Wichtig ist in dieser Sichtweise, dass alle Modelle ausschließlich in dimensionaler Form vorliegen und die Auswertungen auf diesem zentralen Repository stattfinden. Zusätzliche Data Marts müssen nicht notwendigerweise persistiert vorliegen, eine Speicherung ist also optional, die Modelle sind aber alle untereinander abgestimmt und nutzen das Prinzip der »conformed dimensions and facts« im Sinne einer Enterprise Bus Architecture (siehe [Kimball et al. 2008, S. 114 ff.]).

In einer Architektur nach Kimball [Kimball 2002] sind alle Modelle dimensional strukturiert, insbesondere auch das Core Data Warehouse als zentrales granulares Repository.

1.3.6 Corporate Information Factory nach Inmon

Während nach Kimball die dimensionale Modellierung für das gesamte Data Warehouse verpflichtend ist, sieht Inmon deren Nutzen nur auf der Ebene der Data Marts, für die er auch immer den dimensionalen Ansatz empfohlen hat (»… if I had to design a data mart tomorrow, I would not consider using any other approach« [Inmon 2000].).

Es sind aber nur die Departmental Data Marts, für die der Ansatz der dimensionalen Modellierung zum Tragen kommt. Diese implementieren ja gerade die abteilungs- oder funktionsbezogene Sichtweise für die Endbenutzerzugriffe. Dabei basieren die zwingend physisch gespeicherten Data Marts auf einheitlichen Strukturen zur Aggregation und Anreicherung (vgl. [Inmon et al. 2001, S. 110 ff.]).

Eine zentrale Komponente der Corporate Information Factory (CIF) ist das Enterprise Data Warehouse, ein auf einem normalisierten Modell basierendes zentrales Repository von granularen Daten, das als Basis im Sinne eines Hubs innerhalb einer Hub-and-Spoke-Architektur fungiert und auch nicht für direkte Analysen des Endanwenders genutzt werden soll (siehe Abb. 1–9). Die dimensionale Modellierung ist nach Inmon für diesen wie auch für die meisten anderen Bereiche in der Architektur ungeeignet (vgl. [Inmon et al. 2008, S. 18 ff.]).

In der Architektur nach Inmon [Inmon 2008] kommt die dimensionale Modellierung nur für die Data Marts zum Einsatz. Das Core Data Warehouse ist normalisiert modelliert und soll eine möglichst flexible granulare Basis darstellen.

Das Architekturverständnis von Inmon erfuhr im Zeitablauf eine Erweiterung u. a. um Aspekte des Umgangs mit unstrukturierten bzw. semistrukturierten Daten. Diese Architektur wurde als DW 2.0 eingeführt [Inmon et al. 2008].

Abb. 1–9 Corporate Information Factory (CIF) nach Inmon bzw. DW-2.0-Architektur

Aspekte des sogenannten Cross Media Storage Manager und des Nearline Storage wurden zu einem umfassenden Konzept verschiedener Sektoren zur Speicherung ausgebaut, die auf einem Konzept des Information Lifecycle Management (ILM) basieren (siehe hierzu auch [Hahne 2007] sowie [Hahne 2011]). Durch die Einführung verschiedener Sektoren kann den unterschiedlichen Anforderungen an die Service Levels der Daten im Laufe des Informationslebenszyklus besser Rechnung getragen werden. Neben dem Onlinesektor treten der Nearlinesektor und der Archivsektor hinzu. Aspekte des Information Lifecycle Management im BI-Kontext gehen auf die Inmon-Architektur zurück [Inmon 2008, S. 55 ff.].

1.3.7 Architekturvergleich Kimball und Inmon

Obwohl die öffentliche Diskussion, sicherlich auch durch die beiden Protagonisten selbst bewusst verursacht, sehr kontrovers und polarisierend geführt wird, haben beide Vorstellungen von einer guten Data-Warehouse-Architektur auch Gemeinsamkeiten. Die beiden Architekturvarianten mit ihren zentralen Eigenschaften sind in der Tabelle 1–1 gegenübergestellt (vgl. [Adamson 2010, S. 24 ff.]).

Architektur

Begriffe

Charakteristika

Mehrdimensionalität

Inmon

CorporateInformation Factory (CIF), EnterpriseData Warehouse (EDW)

EDW ist integriert und atomar.EDW ist nicht im direkten Zugriff.Data Marts basieren auf EDW und sind physisch getrennt.

Nur für Data Marts.

Kimball

Dimensional Data Warehouse,Data-Mart-Bus-Architektur

Dimensional Data Warehouse: integriert auf Basis von »conformed dimensions« im Star-Schema.Subject Areas im Dimensional Data Warehouse heißen Data Marts.Data Marts müssen nicht separat sein.

Alle Daten sind mehrdimensional organisiert.

Tab. 1–1 Gegenüberstellung von Kimball- und Inmon-Architektur

Zu den Gemeinsamkeiten gehört auch die Einsicht, dass eine logische Integrationsschicht sinnvoll und notwendig ist. In beiden Sichtweisen ist diese Anforderung über ein zentrales Repository abgedeckt. Des Weiteren soll dieses in beiden Fällen atomare Granularität aufweisen. Unterschiedlich ist hingegen die Speicherform dieses zentralen Datenpools. Während in der Kimball-Architektur die dimensionale Modellierung ein zwingendes Kriterium ist, sieht Inmon hier im Wesentlichen normalisierte Modelle vor. Auch der Zugriff, der auf das Dimensional Data Warehouse nach Kimball der Normalfall ist, wird im Fall des Core Data Warehouse nach Inmon im Regelfall ausgeschlossen, da dies durch die dahinterliegenden Data Marts abgedeckt ist.

Ein weiteres Unterscheidungsmerkmal ist die Persistenz der Data Marts. Denn in der Kimball-Sichtweise ist deren physische Speicherung optional. Bei Inmon ist die Persistierung der Data Marts immer vorgesehen, um schlechte Performance bei Zugriffen auf das Core Data Warehouse per se auszuschließen.

1.4 Schichtenmodell der BI-Architektur

Heutige Data-Warehouse-Architekturen sind in mehrfacher Hinsicht mit neuen Anforderungen konfrontiert, die eine klare Architektur sowie adäquate Methoden des Entwurfs fordern. Neben den klassischen Erwartungen an die Kostenstrukturen für den Aufbau und den Betrieb von BI-Systemen sind zunehmend gerade die geschäftlichen Anforderungen, sogenannte Business Requirements, die aufgrund der stetig zunehmenden Dynamik des Geschäftslebens einer starken Volatilität unterworfen sind, wesentliche Treiber für neue BI-Projekte. Gefordert sind Architekturen und Konzepte, die ein schnelles Reagieren auf neue Herausforderungen ermöglichen und somit die Time-to-Market von BI-Applikationen drastisch senken. Die konzeptionelle Antwort hierauf sind mehrschichtige Data-Warehouse-Architekturen, die als logische Klammer zu verstehen sind. Diese implizieren in der Konsequenz unterschiedliche Modellierungsansätze für die differenzierten Anforderungen der diversen Ebenen innerhalb solcher Strukturen. Eine zentrale Rolle für die Gewährleistung der notwendigen Flexibilität, um auf neue geschäftliche Anforderungen schnell reagieren zu können, spielt dabei ein zentrales unternehmensweites Data Warehouse, ein Enterprise Data Warehouse (EDW), das einerseits die vollständige Historie abbildet und andererseits auch die Mechanismen zur Historisierung implementiert. Dies gewährleistet, auf Basis eines abgestimmten harmonisierten Data-Warehouse-Datenbestands, neue Anforderungen in sogenannten Data Marts on Demand schnell erfüllen zu können.

Das heutige Wirtschaftsleben ist gekennzeichnet durch eine hohe Komplexität und rasche Veränderungen der allgemeinen Rahmenbedingungen, die die Marktteilnehmer mit neuen Herausforderungen des Informationsmanagements konfrontieren. Dabei rücken dispositive und strategische Aspekte zunehmend in die Betrachtung. Business Intelligence und Data Warehousing sind dabei die Konzepte, die eine unternehmensweite Informationsversorgung für diese Zwecke realisieren sollen.

Damit sind aber auch Probleme hinsichtlich der Konsistenz und Flexibilität verbunden, die sich in unkontrollierten Datenflüssen, wiederholten und redundanten Extraktionen der gleichen Daten, vielfältigen inkonsistenten Datenmodellen, hohen Entwicklungskosten, Einschränkungen bei der Erfüllung von Informationsbedürfnissen, Informationsinseln und einer insgesamt eher unzuverlässigen unternehmensweiten Datenbasis niederschlagen. Zu allem Übel stehen die IT-Abteilungen vor einem Flickenteppich aus Werkzeugen, der hohe Pflege- und Integrationsanstrengungen sowie ständige Nacharbeit fordert. Dies treibt nicht nur die Gesamtkosten in die Höhe, sondern beeinflusst auch deutlich die Flexibilität im Unternehmen – mithin entscheidend für die Wettbewerbsfähigkeit.

Eine zukunftsorientierte Architektur für die dispositive Informationsversorgung ist nach heutigem allgemeinem Verständnis im Wesentlichen durch eine mehrschichtige unternehmensweit ausgerichtete Data-Warehouse-Struktur gegeben (vgl. [Haupt/Hahne 2007] und [Hahne/Böttiger 2006]). Demzufolge sind die in Abbildung 1–10 dargestellten Schichten zu differenzieren. Im Acquisition Layer erfolgt die Aufnahme der untransformierten Rohdaten aus den Quellsystemen und den externen Datenquellen. Ziel der Transformations- und Harmonisierungsprozesse ist die Ablage im Integration Layer, in dem die aufbereiteten Daten in ihrer vollständigen Historie vorliegen. Die Aggregation hinsichtlich der betriebswirtschaftlichen Anforderungen erfolgt auf dem Weg in den Reporting Layer (vgl. [Hahne 2011, S. 60 ff.]).

In der Praxis haben sich verschiedenste Varianten mehrstufiger Architekturen ausgebildet. Je nach Art und Komplexität der Aufgaben der Harmonisierung und Transformation kommen durchaus sehr viele unterschiedliche Stufen der Datenveredelung zum Einsatz. Insofern kann bei Multi-Layer-Architekturen von einem logischen Konzept gesprochen werden, das jeweils unternehmensindividuell auszuprägen ist.

Abb. 1–10 Konzeptionelle Multi-Layer-Architektur

Neben dem Bereich des Acquisition Layer als erste Schicht im Data Warehouse werden die Schritte der Datenaufbereitung im Integration Layer auch gerne in eigene Schichten mit dedizierten Aufgaben unterteilt. Hierzu gehören die unterschiedlichen Stufen der Harmonisierung. Die Anwendung von Businesslogik erfolgt dann zumeist auf dem Weg Richtung Reporting Layer auch wieder über ggf. mehrere Schichten.

1.4.1 Acquisition Layer

Im Allgemeinen wird die Staging Area als Ort der temporären Ablage für extrahierte Daten verstanden, die nach erfolgter weiterer Verarbeitung und deren Qualitätssicherung zu löschen sind. Dies trägt aber nicht dem Umstand Rechnung, dass oftmals Daten aus Quellsystemen erneut zu extrahieren sind, wenn sich an der weiteren Logik der Aufbereitung etwas geändert hat oder gar Fehler auftraten. Zwar bieten Quellsysteme die Option erneuter Extraktion auch schon gelieferter Daten, jedoch impliziert dies zwei grundsätzliche Probleme. Einerseits halten operative Systeme keine langfristige Historie vor, sodass nur auf relativ aktuelle Daten zurückgegriffen werden kann. Andererseits ist gerade die erneute Extraktion großer Datenvolumina ein Problem der Laufzeit, sodass diese Option eher theoretischer Natur ist.