Inhalt

Titelei

Impressum

Inhalt

Geleitwort / Über dieses Buch / Die Autoren

Über dieses Buch

Die Autoren

Danksagung

1 Einleitung

1.1 Ziele dieses Buches

1.2 Struktur dieses Buches

1.3 Hinweis zur Anwendung dieses Buches

2 Architektur

2.1 Data Warehouse-Architektur

2.1.1 Aufbau eines Data Warehouse

2.1.2 Transformationsschritte

2.1.3 Architekturgrundsätze

2.2 Architektur BI-Anwendungen

2.2.1 Die BI-Plattform zur Integration von Datenquellen

2.2.2 Die BI-Plattform zur Vereinheitlichung der Frontends

2.3 Datenhaltung

2.3.1 Grenzen gängiger DWH/BI-Technologien

2.3.2 Datenhaltung im Hadoop-Ecosystem

2.3.3 In-Memory-Datenbanken

3 Datenmodellierung

3.1 Vorgehensweise

3.1.1 Anforderungsgetriebene Modellierung

3.1.2 Quellsystemgetriebene Modellierung

3.1.3 Kombination der Ansätze

3.2 Relationale Modellierung

3.2.1 Darstellung von relationalen Datenmodellen

3.2.2 Normalisierung

3.2.3 Stammdaten und Bewegungsdaten

3.2.4 Historisierung

3.2.5 Relationales Core

3.2.6 Corporate Information Factory

3.2.7 Data Vault Modeling

3.3 Dimensionale Modellierung

3.3.1 Implementierung von dimensionalen Modellen

3.3.2 Dimensionen

3.3.3 Fakten

3.3.4 Modellierung spezieller Problemstellungen

3.3.5 Darstellung von dimensionalen Modellen

3.3.6 Dimensionales Core

3.4 Tools zur Datenmodellierung

3.4.1 Tools für relationale Datenmodellierung

3.4.2 Tools für dimensionale Datenmodellierung

4 Datenintegration

4.1 Data Profiling

4.1.1 Probleme mangelnder Datenqualität

4.1.2 Einsatz von Data Profiling

4.2 ETL

4.2.1 Aufgaben der ETL-Prozesse

4.2.2 ETL-Tools

4.2.3 Performance-Aspekte

4.2.4 Steuerung der ETL-Prozesse

4.3 Extraktion und Delta-Ermittlung

4.3.1 Delta-Extraktion im Quellsystem

4.3.2 Voll-Extraktion und Delta-Abgleich im Data Warehouse

4.3.3 Wann verwende ich was?

4.4 Fehlerbehandlung

4.4.1 Fehlende Attribute

4.4.2 Unbekannte Codewerte

4.4.3 Fehlende Dimensionseinträge

4.4.4 Doppelte Datensätze

4.5 Qualitätschecks

4.5.1 Qualitätschecks vor und während des Ladens

4.5.2 Qualitätschecks nach dem Laden

4.5.3 Qualitätschecks mithilfe von Test-Tools

4.6 Real-Time BI

4.6.1 Begriffsbestimmung

4.6.2 Garantierte Verfügbarkeit von Informationen zu gegebenem Zeitpunkt

4.6.3 Verfügbarkeit von Informationen simultan zur Entstehung

4.6.4 Verfügbarkeit von Informationen kurz nach ihrer Entstehung

4.6.5 Zusammenfassung

5 Design der DWH-Schichten

5.1 Staging Area

5.1.1 Gründe für eine Staging Area

5.1.2 Struktur der Stage-Tabellen

5.1.3 ETL-Logik für Stage-Tabellen

5.2 Cleansing Area

5.2.1 Gründe für eine Cleansing Area

5.2.2 Struktur der Cleanse-Tabellen

5.2.3 Beziehungen in der Cleansing Area

5.2.4 ETL-Logik für Cleanse-Tabellen

5.3 Core-Datenmodell allgemein

5.3.1 Aufgaben und Anforderungen an das Core

5.3.2 Stammdaten im Core

5.3.3 Bewegungsdaten im Core

5.3.4 Beziehungen im Core

5.3.5 Datenmodellierungsmethoden für das Core

5.4 Core-Datenmodell relational mit Kopf- und Versionstabellen

5.4.1 Historisierung von Stammdaten mit Kopf- und Versionstabellen

5.4.2 Struktur der Stammdatentabellen

5.4.3 ETL-Logik für Stammdatentabellen

5.4.4 Typen von Bewegungsdaten

5.4.5 Struktur der Bewegungstabellen

5.4.6 ETL-Logik für Bewegungstabellen

5.4.7 Views für externen Core-Zugriff

5.5 Core-Datenmodell relational mit Data Vault

5.5.1 Stammdaten

5.5.2 Beziehungen

5.5.3 Bewegungsdaten

5.5.4 Historisierung

5.5.5 Struktur der Tabellen

5.5.6 ETL-Logik

5.5.7 Views für externen Core-Zugriff auf das Data-Vault-Datenmodell

5.6 Core-Datenmodell dimensional

5.6.1 Star- oder Snowflake-Schema

5.6.2 Historisierung von Stammdaten mit SCD

5.6.3 Struktur der Dimensionstabellen (Snowflake)

5.6.4 ETL-Logik für Dimensionstabellen (Snowflake)

5.6.5 Struktur der Faktentabellen (Snowflake)

5.6.6 ETL-Logik für Faktentabellen (Snowflake)

5.6.7 n:m-Beziehungen im dimensionalen Core

5.7 Marts

5.7.1 ROLAP oder MOLAP?

5.7.2 Historisierung von Data Marts

5.7.3 Star- oder Snowflake-Schema (ROLAP)

5.7.4 Struktur der Dimensionstabellen (Star)

5.7.5 ETL-Logik für Dimensionstabellen (Star)

5.7.6 Struktur der Faktentabellen (Star-Schema)

5.7.7 ETL-Logik für Faktentabellen (Star)

5.7.8 Multidimensionale Data Marts

6 Physisches Datenbankdesign

6.1 Indexierung

6.1.1 Staging Area

6.1.2 Cleansing Area

6.1.3 Core

6.1.4 Data Marts

6.2 Constraints

6.2.1 Primary Key Constraints

6.2.2 Foreign Key Constraints

6.2.3 Unique Constraints

6.2.4 Check Constraints

6.2.5 NOT NULL Constraints

6.3 Partitionierung

6.3.1 Grundprinzip von Partitionierung

6.3.2 Gründe für Partitionierung

6.3.3 Partitionierung in Staging und Cleansing Area

6.3.4 Partitionierung im Core

6.3.5 Partitionierung in den Data Marts

6.4 Datenkomprimierung

6.4.1 Redundanz

6.4.2 Wörterbuchmethode/Tokenbasierte Reduktion

6.4.3 Entropiekodierung

6.4.4 Deduplikation

6.4.5 Komprimierung bei spaltenorientierter Datenhaltung

6.5 Aggregationen

6.5.1 Vorberechnete Aggregationen

6.5.2 Query Rewrite

6.5.3 Einsatz im Data Warehouse

7 BI-Anwendungen

7.1 Überblick

7.2 Standardberichte

7.3 Ad-hoc-Analyse

7.4 BI-Portale

8 Betrieb

8.1 Release-Management

8.1.1 Kategorisierung der Anforderungen

8.1.2 Schnittstellen zu Quellsystemen

8.1.3 Umgang mit historischen Daten

8.1.4 Datenbankumgebungen

8.2 Deployment

8.2.1 Manuelles Deployment

8.2.2 Filebasiertes Deployment

8.2.3 Repository-basiertes Deployment

8.2.4 Kombiniertes Deployment

8.3 Monitoring

8.3.1 Betriebsmonitoring

8.3.2 System und DB-Monitoring

8.3.3 ETL-Monitoring

8.3.4 Performance-Monitoring

8.4 Migration

8.4.1 Datenbank

8.4.2 ETL-Tool

8.4.3 BI-Tools

Literatur

Dani Schnider
Claus Jordan
Peter Welker
Joachim Wehner

Data Warehouse Blueprints

Business Intelligence
in der Praxis

Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht.

Ebenso übernehmen Autoren und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen­ und Markenschutz­Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

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.

Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.

Lektorat: Sylvia Hasselbach
Copyediting: Sandra Gottmann, Münster-Nienberge
Herstellung: Irene Weilhart
Umschlagdesign: Marc Müller-Bremer, www.rebranding.de, München
Umschlagrealisation: Stephan Rönigk

Print-ISBN 978-3-446-45075-2
E-Book-ISBN 978-3-446-45111-7

Verwendete Schriften: SourceSansPro und SourceCodePro (Lizenz)
CSS-Version: 1.0

Font License Zurück zum Impressum

Copyright 2010, 2012, 2014 Adobe Systems Incorporated (http://www.adobe.com/), with Reserved Font Name 'Source'. All Rights Reserved. Source is a trademark of Adobe Systems Incorporated in the United States and/or other countries. This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is copied below, and is also available with a FAQ at: http://scripts.sil.org/OFL ----------------------------------------------------------- SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007 ----------------------------------------------------------- PREAMBLE The goals of the Open Font License (OFL) are to stimulate worldwide development of collaborative font projects, to support the font creation efforts of academic and linguistic communities, and to provide a free and open framework in which fonts may be shared and improved in partnership with others. The OFL allows the licensed fonts to be used, studied, modified and redistributed freely as long as they are not sold by themselves. The fonts, including any derivative works, can be bundled, embedded, redistributed and/or sold with any software provided that any reserved names are not used by derivative works. The fonts and derivatives, however, cannot be released under any other type of license. The requirement for fonts to remain under this license does not apply to any document created using the fonts or their derivatives. DEFINITIONS "Font Software" refers to the set of files released by the Copyright Holder(s) under this license and clearly marked as such. This may include source files, build scripts and documentation. "Reserved Font Name" refers to any names specified as such after the copyright statement(s). "Original Version" refers to the collection of Font Software components as distributed by the Copyright Holder(s). "Modified Version" refers to any derivative made by adding to, deleting, or substituting -- in part or in whole -- any of the components of the Original Version, by changing formats or by porting the Font Software to a new environment. "Author" refers to any designer, engineer, programmer, technical writer or other person who contributed to the Font Software. PERMISSION & CONDITIONS Permission is hereby granted, free of charge, to any person obtaining a copy of the Font Software, to use, study, copy, merge, embed, modify, redistribute, and sell modified and unmodified copies of the Font Software, subject to the following conditions: 1) Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself. 2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user. 3) No Modified Version of the Font Software may use the Reserved Font Name(s) unless explicit written permission is granted by the corresponding Copyright Holder. This restriction only applies to the primary font name as presented to the users. 4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font Software shall not be used to promote, endorse or advertise any Modified Version, except to acknowledge the contribution(s) of the Copyright Holder(s) and the Author(s) or with their explicit written permission. 5) The Font Software, modified or unmodified, in part or in whole, must be distributed entirely under this license, and must not be distributed under any other license. The requirement for fonts to remain under this license does not apply to any document created using the Font Software. TERMINATION This license becomes null and void if any of the above conditions are not met. DISCLAIMER THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE.

Geleitwort

Von Dr. Carsten Bange, Gründer und Geschäftsführer des Business Application Research Centers (BARC), Teil des europäischen Analystenhauses CXP Group.

Noch ein Buch über Data Warehousing? Ist darüber in den vergangenen 25 Jahren nicht genug geschrieben worden? Ich gebe zu, ich war skeptisch als die Autoren mich baten, ein Vorwort zu verfassen. Insbesondere auch, da wir in unserer täglichen Praxis als Marktanalysten eine deutlich wachsende Kritik vieler Unternehmen an ihrem Data Warehouse wahrnehmen. Insbesondere die Anwender verlangen nach Änderungen, um ihren veränderten Anforderungen Rechnung zu tragen. Die letzte BARC-Anwenderbefragung zu diesem Thema1 zeigt deutlich, was den Veränderungsbedarf treibt: 62 % der 323 befragten BI- und Data-Warehouse-Verantwortlichen sehen sich mit deutlich erhöhten Erwartungen in den Fachbereichen konfrontiert, 51 % verstehen dabei die schnellere Veränderung von Geschäftsprozessen als wesentlichen Treiber für Anpassungen an Datenmanagement-Konzepten und 45 % erfahren eine Unzufriedenheit mit der benötigten Zeit, um neue Anforderungen im Data Warehouse umzusetzen.

Vielen Unternehmen wird also immer klarer, dass sie die etablierten Data-Warehouse-Systeme so nicht mehr weiterbetreiben können, sondern hinsichtlich der Prozesse und der Organisation, IT-Architektur und eingesetzte Technologien und Werkzeuge komplett überdenken müssen.

Das vorliegende Buch liefert hierzu einen guten Beitrag und legt seinen Fokus dabei auf Methodik und Technologie. Es trägt eine große Menge von Erfahrungen zu „Best Practice“-Anleitungen zusammen, die helfen, das eigene Projekt auf eine solide Basis zu stellen und typische Fehler zu vermeiden. Es behandelt dabei auch neue Technologien, z. B. aus dem Hadoop- und NoSQL-Umfeld, die eine interessante Ergänzung der etablierten und ausgereiften Datenbank- und Datenintegrationstechnologien sein können. Die Autoren bieten damit Entwicklern, BI- und Data-Warehouse-Verantwortlichen ein solides methodisches Fundament, um die Informationsversorgung zur Entscheidungsfindung in Unternehmen erfolgreich aufzubauen.

Es bleibt dann im Unternehmen die wichtige Aufgabe, die verfügbaren Technologien in eine anforderungsgerechte Organisation einzubetten. Gerade Agilität und Flexibilität sind hier die wesentlichen Anforderungen, die in den letzten Jahren beispielsweise den Trend zu „Self Service BI“ angefeuert haben, also der Bereitstellung weitgehender Möglichkeiten zur Zusammenstellung, Aufbereitung und Visualisierung von Daten für Fachanwender. Da dies häufig auch mit einer „Self Service-Datenintegration“ verbunden ist, ergibt sich schnell die Kehrseite der Medaille solcher Initiativen: Die Konsistenz von Daten kann in einer dezentralisierten Welt individueller Datenaufbereitung ‒ wenn überhaupt ‒ nur mit erheblichen Anstrengungen einer Data Governance sichergestellt werden. Die ersten Unternehmen kehren demnach auch schon wieder zu stärker zentralistisch ausgerichteten Konzepten zurück, um dem Daten-Wildwuchs Einhalt zu gebieten.

Dieser Spagat zwischen der Bereitstellung qualitätsgesicherter Daten unter übergreifender Kontrolle auf der einen sowie Flexibilität und Individualität in Datenzusammenstellung und -auswertung auf der anderen Seite ist aus unserer Sicht die momentan größte Herausforderung für Betreiber entscheidungsunterstützender Informationssysteme.

Das Buch zeigt, dass viele Methoden und Technologien hierfür zur Verfügung stehen. Werden sie richtig eingesetzt, sind dem Data Warehouse auch weitere 25 Jahre erfolgreichen Einsatzes beschieden, denn Entscheidungsträger im Unternehmen werden auch in Zukunft nicht auf konsistente und qualitätsgesicherte Daten zur Entscheidungsfindung verzichten.

Würzburg, den 14. 7. 2016

Dr. Carsten Bange

Über dieses Buch

Das vorliegende Buch ist eine Weiterentwicklung des Buches „Data Warehousing mit Oracle ‒ Business Intelligence in der Praxis“, das 2011 beim Carl Hanser Verlag erschienen und mittlerweile vergriffen ist. Im Vergleich zur vorherigen Version wurden hier die allgemeinen Konzepte, Architekturvorschläge und Vorgehensweisen stark ausgebaut und aktualisiert. Oracle-spezifische Informationen wurden ‒ bis auf die Verwendung in Beispielen ‒ weitgehend verallgemeinert, sodass die vorliegenden Blueprints auch für andere Datenbanktechnologien eingesetzt werden können.

Die Data Warehouse Blueprints wurden vorerst als interner Leitfaden für die BI-Consultants bei Trivadis zur Verfügung gestellt, bevor sie öffentlich publiziert wurden. Während dieser Zeit haben verschiedene Trivadis-Kollegen die einzelnen Kapitel überprüft und zahlreiche Korrekturen, Änderungsvorschläge und Ergänzungen zur nun vorliegenden Ausgabe beigetragen.

Die Autoren

Dani Schnider

Dani Schnider ist seit seinem abgeschlossenen Informatikstudium an der ETH Zürich (1990) in der Informatik tätig. Seit 1997 arbeitet er vorwiegend in DWH-Projekten. Konzeption, Design, Aufbau und Weiterentwicklung von Data Warehouses, logische und physische Datenmodellierung im DWH-Umfeld sowie Reviews, Architekturberatungen und Schulungen bilden seine Aufgabenschwerpunkte in diesem Bereich. Präsentationen an verschiedenen Konferenzen und Publikationen von Fachartikeln und Blog-Posts runden seine Tätigkeiten ab. (Kontakt: dani.schnider@trivadis.com)

Claus Jordan

Seit seinem Abschluss des Studiums der Wirtschaftsinformatik 1993 ist Claus Jordan im Umfeld Data Warehouse und Business Intelligence aktiv. Seit 2003 bringt er seine Erfahrung in diesen Bereichen für die Trivadis GmbH in zahlreichen Kundenprojekten, als Trainer und als Autor ein. Seine Schwerpunkte liegen dabei im Design unterschiedlicher Datenmodellierungsmethoden eines Data Warehouse, sowie in der Implementierung von ETL-Prozessen und deren Standardisierung. (Kontakt: claus.jordan@trivadis.com)

Peter Welker

Peter Welker arbeitete bereits vor dem Abschluss seines Studiums der Medizininformatik 1996 als Entwickler für Anwendungssoftware. 1998 wechselte er ins Data Warehousing und ist seitdem hauptsächlich in Projekten mit dem Fokus ETL, DWH-Lösungsarchitektur, Review und Performance aktiv. In den letzten Jahren beschäftigt er sich intensiv mit den neuen Technologien. Er präsentiert an Konferenzen, publiziert Fachartikel und verantwortet bei der Deutschen Oracle-Anwendergruppe (DOAG) das Thema „Big Data“. (Kontakt: peter.welker@trivadis.com)

Joachim Wehner

Seit seiner Diplomarbeit „Werkzeuge zum Aufbau eines Data Warehouses“ aus dem Jahre 1996 lässt ihn dieses Thema nicht mehr los. Als Berater und Trainer arbeitet Joachim Wehner über die Jahre primär in BI-/DWH-Kundenprojekten. Im Mittelpunkt stehen dabei fast immer die Architektur, das Design sowie Reviews solcher Data-Warehouse-Umgebungen. Inzwischen hat sich sein Verantwortungsbereich von der Technik auf die Managementseite verlagert. (Kontakt: joachim.wehner@trivadis.com)

Danksagung

Die Kapitel dieses Buches wurden von verschiedenen Trivadis-Consultants geprüft, korrigiert und mit wertvollen Ergänzungen und Änderungsvorschlägen angereichert. Der Dank für diese Reviewarbeit gilt folgenden Personen: Adrian Abegglen, Aron Hennerdal, Beat Flühmann, Christoph Hisserich, Kamilla Reichardt, Maurice Müller, Peter Denk, Stanislav Lando, Thomas Brunner und Willfried Färber. Die gute und konstruktive Zusammenarbeit mit Frau Hasselbach und Frau Weilhart vom Hanser Verlag ist an dieser Stelle ebenfalls dankend zu erwähnen wie das passende Geleitwort zu diesem Buch von Herrn Dr. Carsten Bange vom Business Application Research Center (BARC).

Ein besonderer Dank gilt natürlich der Trivadis AG für die Unterstützung des Buchprojekts während der Erstellung und dafür, dass sie es ermöglicht hat, dass das Buch wiederum öffentlich publiziert werden kann.

Fussnoten

1 s. BARC-Anwenderbefragung „Modernes Datenmanagement für die Analytik“ (BARC 2015), Ergebnisstudie kostenfrei verfügbar unter www.barc.de im Bereich Research.

1Einleitung

Business Intelligence (BI) und Data Warehousing (DWH) sind zwei Begriffe, die in vielen Unternehmen nicht mehr wegzudenken sind und denen eine immer wichtigere Bedeutung zukommt. In vielen großen Unternehmen gehören Data Warehouses und BI-Applikationen zu den zentralen Systemen. Auch kleinere und mittlere Betriebe benutzen Business Intelligence für die Planung und Überprüfung ihrer Geschäftsziele.

Business Intelligence bezeichnet die systematische Auswertung von Daten eines Unternehmens, um damit Geschäftsprozesse zu analysieren und zu optimieren. Das Ziel von Business Intelligence ist es, aus vergleichbaren Kennzahlen neue Erkenntnisse zu gewinnen. Sie dienen als Basis für strategische und operative Entscheidungen, mit denen die Unternehmensziele besser erreicht werden können.

Bild 1.1 Data Warehouse als Basis für Business Intelligence

Um Business Intelligence erfolgreich betreiben zu können, muss eine solide Data-Warehouse-Architektur als Basis vorhanden sein. Ziel eines Data Warehouse ist es, die Daten aus verschiedenen operativen Quellsystemen so zusammenzuführen und in geeigneter Form abzuspeichern, dass darauf einfache und flexible Abfragen sowie verschiedenste Arten von Auswertungen möglich sind.

Data Warehouse oder Business Intelligence?

Die Begriffe „Data Warehouse“ und „Business Intelligence“ werden teilweise in unterschiedlichem Kontext verwendet. So wird „Business Intelligence“ einerseits als Sammelbegriff für BI-Gesamtlösungen ‒ unter anderem Data Warehouses ‒ verwendet, andererseits für die systematische Analyse von Geschäftsprozessen anhand von Kennzahlen.

Ein Data Warehouse wiederum bezeichnet zum einen ein System aus Datenbank(en) und ETL-Prozessen, das die notwendigen Informationen zur Verfügung stellt, um Business Intelligence betreiben zu können. Zum anderen wird der Begriff „Data Warehouse“ oft auch für die zentrale Integrations- und Historisierungsschicht innerhalb eines DWH-Gesamtsystems verwendet.

Eine einheitliche Namensgebung innerhalb der Informatikwelt ist kaum möglich, aber zumindest im vorliegenden Buch wurde versucht, die Begriffe einheitlich zu verwenden. Hier verstehen wir unter Business Intelligence (BI) jede Art von Anwendungen zur Datenanalyse, basierend auf einem Data Warehouse (DWH). Das Data Warehouse ist somit die technische Datenbasis für Business Intelligence. Die zentrale Schicht im DWH wird hier ‒ zur Unterscheidung vom DWH-Gesamtsystem ‒ als Core (oder Core Data Warehouse) bezeichnet.

Ein Data Warehouse umfasst somit die technische und fachliche Basis, die notwendig ist, um Anwendungen im Bereich Business Intelligence betreiben zu können. Integration, Skalierbarkeit und Performance sind wichtige Erfolgsfaktoren. Jede BI-Applikation und jedes Data Warehouse kann nur dann erfolgreich sein, wenn die Architektur richtig aufgebaut ist, die einzelnen Komponenten zusammenpassen und das Gesamtsystem fehlerlos konfiguriert wird.

In den Data Warehouse Blueprints werden Grundlagen und Konzepte für den Aufbau und Betrieb von Data Warehouses beschrieben. Die vorliegenden Kapitel wurden soweit möglich unabhängig von einer spezifischen Technologie beschrieben und lassen sich mit unterschiedlichen Datenbanksystemen und Softwarekomponenten umsetzen. Da jedoch die Autoren alle im Oracle-Umfeld tätig sind, schimmern teilweise technologiespezifische Detailinformationen durch. Die mit anderen Datenbanktechnologien vertrauten Leserinnen und Leser werden aufgefordert, beim Lesen der folgenden Kapitel tolerant zu sein und die technologiespezifischen Begriffe sinngemäß in ihre Nomenklatur zu übersetzen.

1.1 Ziele dieses Buches

Um leistungsfähige und stabile DWH-Systeme aufbauen und betreiben zu können, ist entsprechendes Know-how über Data Warehousing notwendig. Das vorliegende Buch gibt einen Überblick über eine typische DWH-Architektur und zeigt anhand von zahlreichen Beispielen auf, wie die einzelnen Komponenten eines Data Warehouse realisiert und betrieben werden können. Der Hauptfokus liegt dabei nicht auf einer vollständigen Aufzählung der technischen Möglichkeiten ‒ dazu stehen die Dokumentationen oder entsprechende Schulungen für die jeweilige Datenbanktechnologie zur Verfügung ‒, sondern darauf, wie allgemeine Technologien und Methoden in konkreten DWH-Projekten verwendet werden können. Die hier aufgezeigten Konzepte und Vorgehensweisen wurden in zahlreichen Projekten eingesetzt und ‒ basierend auf den Erfahrungen daraus ‒ verfeinert und erweitert.

Anhand verschiedener Tipps und Tricks aus der Praxis wird erläutert, wie die beschriebenen Methoden im Data Warehousing eingesetzt werden können. Es versteht sich von selbst, dass die hier beschriebenen Möglichkeiten keinen Anspruch auf Vollständigkeit erheben. Jedes Data Warehouse hat andere Anforderungen, Systemvorgaben und Spezialfälle, die zu berücksichtigen sind. Die hier vorgestellten Konzepte sollen jedoch als technischer Leitfaden dienen, um auch komplexe und umfangreiche Data Warehouses nach bewährtem Muster aufbauen zu können.

1.2 Struktur dieses Buches

Das vorliegende Buch ist in folgende Hauptkapitel unterteilt:

1.3 Hinweis zur Anwendung dieses Buches

Als „Blueprints“ ‒ also Baupläne ‒ werden hier Verfahren und Methoden bezeichnet, die sich in verschiedenen DWH-Projekten bewährt haben. Das bedeutet aber nicht, dass sie die einzige oder beste Lösung für jedes Data Warehouse beschreiben.

Erfahrene DWH-Entwickler und BI-Consultants werden nach der Lektüre der nachfolgenden Kapitel in der Lage sein, die beschriebenen Konzepte und Praxistipps soweit sinnvoll in konkreten DWH-Projekten anzuwenden. Sie sollten aber auch die nötige Erfahrung haben, bei Bedarf zu erkennen, ob und wann von den hier beschriebenen Blueprints abzuweichen ist ‒ sei es durch den Einsatz anderer Technologien, durch spezielle Kundenbedürfnisse oder durch eine andere Ausgangslage, als sie hier angenommen wird.

Das gilt auch für die Architektur eines Data Warehouse: Die im vorliegenden Buch verwendete Architektur beschreibt eine bewährte, aber nicht die einzig mögliche Variante, wie ein Data Warehouse auszusehen hat. Vielleicht hat das DWH bei einem spezifischen Kunden mehr oder weniger Schichten, oder es werden andere Begriffe für die einzelnen Komponenten verwendet. Auch hier gilt: Was zweckmäßig ist, kann und soll aus den Blueprints übernommen werden. Wenn es sinnvoll und begründbar ist, von den hier beschriebenen Methoden abzuweichen, ist dies durchaus erlaubt und gewünscht ‒ sofern es der Qualität des zu bauenden Data Warehouse und der Zufriedenheit des Kunden dient.

2Architektur