Data Warehouse Blueprints

Business Intelligence in der Praxis
 
 
Hanser (Verlag)
  • 1. Auflage
  • |
  • erschienen am 10. Oktober 2016
  • |
  • 283 Seiten
 
E-Book | ePUB mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-446-45145-2 (ISBN)
 
Data-Warehouse-Lösungen mit Blueprints erfolgreich umsetzen
Dieses Buch gibt Ihnen einen Überblick über eine typische Data-Warehouse-Architektur und zeigt anhand von zahlreichen Best Practice-Beispielen, wie Sie die einzelnen Komponenten eines Data Warehouses realisieren und betreiben können. Skalierbarkeit, Performance und Integration sind dabei die wichtigsten Erfolgsfaktoren.

Der kompakte und kompetente Leitfaden für Ihr Projekt
Warum benötigt man eine Staging Area? Wie sollen fehlende oder fehlerhafte Daten beim Ladeprozess behandelt werden? Ist es zweckmäßiger, einen oder mehrere Data Marts zu erstellen? Wo werden die Daten aus verschiedenen Datenquellen integriert und wie sollen sie historisiert werden? Zu diesen und vielen weiteren Fragen erhalten Sie Antworten sowie Tipps und Tricks aus der Praxis.

Wertvolles Know-how aus der Praxis
Profitieren Sie von der langjährigen Erfahrung der Autoren. Die vorgestellten Konzepte und Vorgehensweisen haben sich bereits in zahlreichen Projekten bewährt.

EXTRA: E-Book inside

AUS DEM INHALT
Einleitung
Architektur
Datenmodellierung
Datenintegration
Design der DWH-Schichten
Physisches Datenbankdesign
BI-Anwendungen
Betrieb
  • Deutsch
  • München
  • |
  • Deutschland
  • 25,03 MB
978-3-446-45145-2 (9783446451452)
weitere Ausgaben werden ermittelt
Claus Jordan, Dani Schnider, Joachim Wehner und Peter Welker sind Data-Warehouse-Architekten mit langjähriger Erfahrung aus zahlreichen BI-Projekten in unterschiedlichen Branchen. Ihr Fokus liegt vor allem in der breit gefächerten Oracle-Technologie - von der Datenbank über das Design, ETL, Frontends sowie Performance-Reviews bis hin zum Redesign von Data Warehouses.
3 Datenmodellierung

Die Erstellung eines geeigneten Datenmodells ist in vielen Data Warehouses eine der größeren Herausforderungen. Wie werden die analytischen Anforderungen an das Data Warehouse in geeignete Datenstrukturen übersetzt? Das vorliegende Kapitel befasst sich mit der Thematik der Datenmodellierung im Data Warehouse.

  • Abschnitt 3.1 beschreibt die unterschiedlichen Vorgehensweisen für die Datenmodellierung im Data Warehouse mit ihren Vor- und Nachteilen.

  • Abschnitt 3.2 gibt einen kurzen Überblick über die relationale Datenmodellierung und zeigt auf, in welchen Bereichen im Data Warehouse sie eingesetzt werden kann.

  • Abschnitt 3.3 erklärt die wichtigsten Konzepte und Begriffe der dimensionalen Datenmodellierung. Diese Art der Datenmodellierung kommt in fast allen DWH-Systemen zur Anwendung, zumindest für die Implementierung von Data Marts.

  • Das Kapitel schließt mit Hinweisen zu Datenmodellierungswerkzeugen, die in Abschnitt 3.4 zusammengefasst sind.

3.1 Vorgehensweise

Um ein Data Warehouse zu modellieren, also die Datenmodelle für Staging Area, Cleansing Area, Core und Data Marts zu entwickeln, gibt es verschiedene Vorgehensweisen. Nachfolgend werden zwei typische Ansätze vorgestellt. In den meisten DWH-Projekten werden Mischformen davon eingesetzt.

3.1.1 Anforderungsgetriebene Modellierung

Bei diesem Ansatz werden zuerst die analytischen Anforderungen mittels fachlicher Analyse und Betrachtung der fachlichen Zusammenhänge ermittelt. Daraus werden die Datenmodelle der Data Marts und des Core abgeleitet. Erst dann werden die Quellsysteme untersucht, um zu ermitteln, woher die Daten beschafft werden können. Im Rahmen einer Gap-Analyse wird untersucht, welche erforderlichen Daten nicht in der gewünschten Form zur Verfügung stehen und unter Umständen von weiteren Datenquellen beschafft werden müssen.

Der Vorteil der in Bild 3.1 dargestellten Vorgehensweise ist, dass nur die fachlich relevanten Informationen im Data Warehouse gespeichert werden. Allerdings kann dies auch zu einem Nachteil werden: Werden in weiteren Phasen zusätzliche Anforderungen an das DWH gestellt, fehlen die dazu benötigten Informationen im Core, und das Datenmodell sowie die Schnittstellen zu den Quellsystemen und die ETL-Prozesse müssen nachträglich erweitert werden. Dieser Ansatz eignet sich deshalb nur dann, wenn die analytischen Anforderungen an das Data Warehouse bekannt und einigermaßen vollständig sind. Nachträgliche Erweiterungen sind möglich, aber aufwendig.

Bild 3.1 Anforderungsgetriebene Datenmodellierung

Wichtig bei diesem Ansatz ist deshalb, dass die Fachbereiche, die mit den Data Marts arbeiten werden, bereits zu Beginn des Projekts in die Entscheidungsprozesse eingebunden werden. Welche Informationen in welcher Form in den Data Marts zur Verfügung stehen sollen, muss von den zuständigen Fachbereichen festgelegt werden. Aus diesem Grund sollten geeignete Fachvertreter bei der Anforderungsanalyse und der logischen Modellierung der Data Marts involviert sein.

Die logische Datenmodellierung der Data Marts, also das Festlegen von Dimensionen und Hierarchien sowie Kennzahlen und Fakten, sollte nicht IT-getrieben, sondern in Zusammenarbeit zwischen dem DWH-Entwicklungsteam und den zuständigen Fachbereichen durchgeführt werden. Die physische Datenmodellierung der Data Marts, insbesondere die technische Umsetzung mittels relationaler oder multidimensionaler Technologie, wird ausschließlich von der Informatik gemacht. Die Fachseite wird für diese Aufgaben nicht einbezogen.

Bei der Datenmodellierung des Core besteht die Hauptschwierigkeit darin zu entscheiden, welche zusätzlichen Informationen im Core gespeichert werden sollen. Werden nur genau die Daten ins Core übernommen, die in den Data Marts benötigt werden, tritt bei zusätzlichen Anforderungen oder der Erweiterung bestehender Data Marts das Problem auf, dass das Core auch erweitert werden muss. Dies ist mit viel Aufwand verbunden. Deshalb sollte von Anfang an bei der Modellierung des Core überlegt werden, welche Daten fachlich relevant sein können und somit „auf Vorrat“ im Core abgelegt werden sollen. Ein empfehlenswerter Ansatz ist es, die Daten in der feinsten Granularität, die vom Quellsystem geliefert wird, im Core abzulegen und in den Data Marts auf die erforderliche Verdichtungsstufe zu aggregieren.

3.1.2 Quellsystemgetriebene Modellierung

Dieser Ansatz geht von den zur Verfügung stehenden Daten der Quellsystemeaus, wie in Bild 3.2 dargestellt. Vorerst wird ? in der Regel IT-getrieben ? ermittelt, welche Informationen für das Data Warehouse relevant sind. Daraus wird das Datenmodell für das Core erstellt. Basierend auf dem Core werden dann in Zusammenarbeit mit den Fachabteilungen für unterschiedliche Bedürfnisse spezifische Data Marts erstellt. Wenn sich bei der Modellierung der Data Marts herausstellt, dass gewisse Informationen nicht zur Verfügung stehen, muss das Core entsprechend erweitert werden.

Bild 3.2 Quellsystemgetriebene Datenmodellierung

Diese Vorgehensweise wird oft verwendet, wenn die analytischen Anforderungen der Fachbereiche an das Data Warehouse noch unklar oder nur ansatzweise vorhanden sind. Darin besteht auch die Gefahr dieses Ansatzes: Oft werden zu viele oder die falschen Daten ins DWH übernommen, und das Core tendiert zu einem Archivierungssystem für Daten, die in keinem Data Mart benötigt werden. Wenn nur ein Quellsystem vorhanden ist, wird das Core mit großer Wahrscheinlichkeit nichts anderes als eine historisierte Kopie des Quellsystems werden, indem das gleiche oder ein sehr ähnliches Datenmodell verwendet wird.

Ein reiner quellsystemgetriebener Ansatz sollte als Vorgehensweise für die Datenmodellierung eines Data Warehouse möglichst vermieden werden, da es typischerweise zu DWH-Systemen mit vielen Daten führt, aber nicht den erforderlichen Informationen, die von den Fachbereichen benötigt werden.

3.1.3 Kombination der Ansätze

Eine sinnvolle und oft angewendete Vorgehensweise ist es, in einem ersten Schritt die anforderungsgetriebene Datenmodellierung zu wählen, um dann in einer zweiten Phase mithilfe der quellsystemgetriebenen Modellierung das Datenmodell zu ergänzen.

Durch die Kombination der beiden Modellierungsvarianten kann sichergestellt werden, dass die Anforderungen an die Data Marts erfüllt werden. Zusätzlich werden fachlich relevante Informationen ins Core übernommen, die momentan zwar noch nicht benötigt werden, aber in Zukunft von Interesse sein könnten.

3.2 Relationale Modellierung

Die relationale Datenmodellierung wird typischerweise in OLTP-Systemen eingesetzt. Ein großer Teil der Quellsysteme, welche Daten an ein Data Warehouse liefern, besitzen ein Datenmodell in 3. Normalform.

Ob diese Art der Datenmodellierung auch im Data Warehouse eingesetzt werden soll, hängt von verschiedenen Faktoren ? und Meinungen ? ab. Während für Data Marts hauptsächlich dimensionale Datenmodelle verwendet werden (siehe Abschnitt 3.3), wird für das Core je nach verwendeter Architektur ein dimensionales oder ein relationales Datenmodell verwendet. Auch Mischformen zwischen diesen Ansätzen sind weit verbreitet.

Varianten von relationalen Core-Modellen

In der von William H. Inmon definierten DWH-Architektur Corporate Information Factory (CIF) besitzt das zentrale Enterprise Data Warehouse ein normalisiertes Datenmodell in 3. Normalform. Ebenfalls auf relationalen Konzepten basierend und in den letzten Jahre vermehrt eingesetzt wird Data Vault Modeling, ein von Dan Linstedt definierter Modellierungsansatz für Data Warehouses. Diese beiden Ansätze werden am Ende dieses Kapitels kurz beschrieben.

3.2.1 Darstellung von relationalen Datenmodellen

Relationale Datenmodelle werden typischerweise als Entity-Relationship-Diagramme dargestellt. Die Entitätstypen werden als Tabellen implementiert. Die Beziehungen (Relationships) zwischen den Entitäten werden als Fremdschlüsselbeziehungen bzw. Foreign Key Constraints implementiert.

Entitätstypen werden im Entity-Relationship-Diagramm als Rechtecke dargestellt. Je nach verwendeter Darstellung und Modellierungstool werden darin nur die Namen der Entitätstypen oder auch die Attribute aufgeführt. Die Verbindungen zwischen den Entitätstypen werden als Linien zwischen den einzelnen Rechtecken dargestellt.

Für die Kardinalitäten und Bedeutungen der Beziehungen gibt es ebenfalls verschiedene Darstellungen (Chen, IDEF1X, UML, Bachmann etc.). Bild 3.3 zeigt ein Beispiel eines Entity-Relationship-Diagramms mit IDEF1X-Notation, erstellt mit dem CA Erwin Data Modeler.

Bild 3.3 Entity-Relationship-Diagramm eines normalisierten Datenmodells

3.2.2 Normalisierung

Das wichtigste Grundkonzept der relationalen Datenmodellierung ist die Normalisierung der Daten. Ziel der Normalisierung ist es, Redundanz zu vermeiden. Der ursprüngliche Grund, damit Speicherplatz zu sparen, ist heute nicht mehr relevant. Nach wie vor wichtig ist es aber, durch die Vermeidung mehrfach gespeicherter Daten sicherzustellen, dass die Datenkonsistenz gewährleistet werden kann. Ein redundanzfreies relationales...

Dateiformat: ePUB
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie eine Lese-Software, die das Dateiformat EPUB verarbeiten kann: z.B. Adobe Digital Editions oder FBReader - beide kostenlos (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nicht Kindle)

Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet - also für "fließenden" Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Download (sofort verfügbar)

33,99 €
inkl. 7% MwSt.
Download / Einzel-Lizenz
ePUB mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
E-Book bestellen