Claßen, D., "Business Intelligence im Mittelstand"

Diplomarbeit
zur Erlangung des akademischen Grades
Diplom-Informatiker
an der
Fachhochschule Dortmund
im Fachbereich Informatik
im Studiengang Wirtschaftsinformatik
Business Intelligence im Mittelstand
Implementierung eines BI-Gesamtansatzes in einem mittelständischen
Unternehmen mit dem Microsoft SQL Server®.
Autor:
David Claßen
Matrikel-Nr: 7041592
Erstprüfer:
Prof. Dr. Christoph Engels
Abgabe am:
02.03.2009
Markenrechtlicher Hinweis III
Markenrechtlicher Hinweis
Die in dieser Arbeit wiedergegebenen Gebrauchsnamen, Handelsnamen,
Warenzeichen usw. können auch ohne besondere Kennzeichnung geschützte
Marken sein und als solche den gesetzlichen Bestimmungen unterliegen.
Sämtliche in dieser Arbeit abgedruckten Bildschirmabzüge unterliegen dem
Urheberrecht © des jeweiligen Herstellers.
Excel, SQL Server 2005 und Windows sind Marken oder eingetragene Marken der
Microsoft Corporation, Redmond.
MegaWWS ist eine eingetragene Marke der Mega Software GmbH, Dortmund.
V_Olga ist eine eingetragene Marke der Voigt Software und Unternehmensberatung
GmbH, Murr.
Kurzfassung V
Kurzfassung
Die richtige Information, zur richtigen Zeit, richtig aufbereitet und in den richtigen
Kontext eingebettet wird heute immer öfter als wesentlicher Faktor zur Erlangung
von Wettbewerbsvorteilen im Markt angesehen.
Für eine Umsetzung solcher Analysesysteme, die basierend auf riesigen
Datenmengen innerhalb kurzer Zeit auch komplexe Fragestellungen beantworten
und zielgerichtet darstellen können werden immer häufiger Business
Intelligence-Gesamtansätze verwendet. Diese beschreiben in einem mehrstufigen
Aufbau den gesamten Wertschöpfungsprozess von Daten innerhalb einer
Unternehmung.
Die vorliegende Diplomarbeit beschreibt die Implementierung eines solchen
BI-Gesamtansatzes bei der WESTFA GmbH. Der Schwerpunkt dieser liegt auf der
Entwicklung eines ETL-Prozesses zur Generierung und Bereitstellung von
dispositiven Daten in einem Data Warehouse.
Im Weiteren Verlauf soll das Data Warehouse als Datenbasis eines auf OLAP
basierendem, multidimensionalem Analysesystems dienen, das die Anforderungen
an ein komplexes, unternehmensweites Reporting erfüllt.
Für die Implementierung dieses BI-Gesamtansatzes bei der WESTFA GmbH wurde
der Microsoft SQL Server 2005® mit seinen mit seinen, speziell für die
Anforderungen von Business-Intelligence bereitgestellten Komponenten
„Integration Services“ und „Analysis Services“ verwendet.
VI Abstract
Abstract
The right information, at the right time, correctly formatted and in the proper
context is now increasingly seen as an essential factor for obtaining competitive
advantage in the market.
For the implementation of such an analytical system that is based on large amounts
of data within a short time to respond to complex issues supplies are becoming
more business-intelligence approaches used. These describe a multi-structure the
entire value chain of data within a company.
This thesis describes the implementation of such a BI-approach in the WESTFA
GmbH focuses on the development of an ETL process for the generation and
provision of dispositive data in a data warehouse.
Moreover, the data warehouse serves as a data base for OLAP-based,
multidimensional analytical system to meet the requirements of a complex,
enterprise-wide reporting fulfilled.
For the implementation of a BI approach in the WESTFA GmbH was the Microsoft
SQL Server 2005 ® with it’s specifically for the demands of business intelligence
provided components “Integration Services” and “Analysis Services” uses.
Inhalt VII
Inhalt
1
2
3
Einleitung .............................................................................................................. 1
1.1
Beschreibung der Thematik .......................................................................... 1
1.2
Zielsetzung der Arbeit ................................................................................... 1
1.3
Vorgehensweise und Gliederung .................................................................. 2
Werkzeugauswahl ................................................................................................ 3
2.1
Der BI-Markt .................................................................................................. 3
2.2
Entscheidung ................................................................................................. 5
2.3
SQL Server 2005 ............................................................................................ 5
2.3.1
Integration Services ............................................................................... 6
2.3.2
Datenbankmodul ................................................................................... 7
2.3.3
Analysis Services .................................................................................... 7
2.3.4
Reporting Services ................................................................................. 8
Data Preparation .................................................................................................. 9
3.1
Unterschiedliche Strategien .......................................................................... 9
3.2
Extraktion von ausgewählten Daten ........................................................... 11
3.2.1
Persistent Staging Area ........................................................................ 11
3.2.2
Extraktion aus PivotalCRM................................................................... 13
3.2.3
Extraktion aus megaWWS ................................................................... 14
3.2.4
Extraktion aus V_Olga .......................................................................... 15
3.2.4.1
3.2.5
3.3
Fehlerbehandlung während des Extraktionsprozesses ................ 17
Automatisierung der Extraktionen ...................................................... 19
Transformation der Daten .......................................................................... 20
3.3.1
Filterung ............................................................................................... 21
3.3.1.1
Selektion ....................................................................................... 22
3.3.1.2
Datenbereinigung ......................................................................... 23
3.3.1.3
Unterschiede der Filterung für Fakten und Dimensionen ........... 24
3.3.1.3.1 Inkrementelle Selektion von Fakten ......................................... 25
3.3.1.3.2 Vollständige Selektion von Fakten ............................................ 25
3.3.2
Harmonisierung ................................................................................... 25
VIII Inhalt
3.3.3
3.4
Aggregation & Anreicherung ................................................................ 29
3.3.3.1
Aggregation ................................................................................... 29
3.3.3.2
Anreicherung ................................................................................. 30
Konstruktion und Laden des Data Warehouse ............................................ 31
3.4.1
Laden der Dimensionstabellen ............................................................. 33
3.4.1.1
Slowly Changing Dimensions......................................................... 36
3.4.1.1.1 Typ1 ............................................................................................ 36
3.4.1.1.2 Typ2 ............................................................................................ 37
3.4.1.1.3 Typ 3 ........................................................................................... 39
3.4.1.1.4 Implementierung bei WESTFA ................................................... 40
3.4.1.2
3.4.2
4
Laden der Fakten .................................................................................. 46
3.4.2.1
Lookup-Transformation ................................................................ 47
3.4.2.2
Lookup von Surrogatschlüsseln einer SCD vom Typ 2 .................. 50
3.4.3
3.5
Fremdschlüsselbeziehungen im Data Warehouse ............................... 54
Automatisierung der Aktualisierung des Data Warehouse ......................... 56
Modeling ............................................................................................................. 57
4.1
Definition einer Datenquellensicht .............................................................. 58
4.2
Erstellen eines Cubes ................................................................................... 59
4.2.1
Cube-Assistent ...................................................................................... 60
4.2.2
Dimensionen ......................................................................................... 65
4.2.2.1
4.2.3
4.3
5
Surrogatschlüssel .......................................................................... 45
Hierarchien .................................................................................... 66
Measures .............................................................................................. 67
4.2.3.1
Berechnete Werte ......................................................................... 68
4.2.3.2
Kennzahlen (KPIs) .......................................................................... 69
Bereitstellung und Verarbeitung des Cubes ................................................ 70
4.3.1
MOLAP .................................................................................................. 71
4.3.2
ROLAP ................................................................................................... 71
4.3.3
HOLAP ................................................................................................... 71
Evaluation ............................................................................................................ 73
5.1
Evaluation der Funktionen und Daten ......................................................... 73
5.2
Evaluation Informationsbeschaffung........................................................... 76
Inhalt IX
6
7
Deployment ........................................................................................................ 78
6.1
Analysen mit MS Excel 2007 ....................................................................... 78
6.2
Separate Frontendwerkzeuge ..................................................................... 79
6.3
Reporting Services des SQL Servers ............................................................ 79
Abschluss ............................................................................................................ 80
7.1
Zusammenfassung ...................................................................................... 80
7.2
Fazit ............................................................................................................. 81
7.3
Ausblick ....................................................................................................... 82
Eidesstattliche Erklärung ........................................................................................... 83
Abbildungsverzeichnis ............................................................................................... 85
Tabellenverzeichnis ................................................................................................... 87
1 Einleitung 1
1 Einleitung
1.1 Beschreibung der Thematik
Durch sich immer schneller verändernde Marktsituationen werden alle
Marktteilnehmer vor neue Herausforderungen gestellt. Die Fähigkeit einer
Unternehmung, in dieser Situation schnell und richtig zu entscheiden, trägt dabei
wesentlich zur Wettbewerbsfähigkeit und zum Aufbau von Wettbewerbsvorteilen
bei. Grundlage einer Entscheidungsfindung sind verdichtete, zielgerichtet
aufbereitete Daten, die mit Hilfe von Informationssystemen erstellt und
bereitgestellt werden können. Durch den rasanten technologischen Fortschritt der
letzten Jahrzehnte haben sich die Möglichkeiten, aber auch die Zielsetzungen von
Informationssystemen verändert.
Business Intelligence ist ein Schlagwort, das sich in den letzten Jahren im IT-Markt
etabliert hat und als eine moderne Ausprägung der klassischen Management
Support Systeme beschrieben werden kann. Dabei beschreiben Business
Intelligence Ansätze das Sammeln, Aufbereiten, Analysieren und Präsentieren von
Unternehmensdaten.
Wurden Business Intelligence Projekte bisher vor allem bei Großunternehmen und
Konzernen initiiert, findet aktuell eine Neuausrichtung der Anbieter von BIWerkzeugen auf den Mittelstand statt. Denn auch dort hat man entdeckt, welches
Potenzial sich mit Business Intelligence erschließen lässt.
1.2 Zielsetzung der Arbeit
Im Rahmen des dieser Arbeit vorangegangenen Projektverlaufes wurden die ersten
beiden Prozessphasen des CRISP-Prozesses, das Business Understanding und das
Data Understanding bei der WESTFA GmbH durchgeführt. Es wurde ein Verständnis
für die grundlegenden Geschäftsprozesse sowohl aus Datensicht, als auch aus
organisatorischer Sicht erarbeitet. Darauf aufbauend wurde der Informationsbedarf
in Bezug auf einen zu implementierenden BI-Gesamtansatz durch Interviews der
späteren Anwender ermittelt und strukturiert.
Mit dem Abschluss der zweiten Prozessphase wurde ein horizontaler Prototyp in
Form eines nach der ADAPT-Methode entwickelten Datenmodells entworfen, der
die multidimensionale Datenstruktur eines möglichen Zielsystems auf einer
semantischen Ebene beschreibt.
Ziel der vorliegenden Arbeit ist es, anhand der gewonnenen Erkenntnisse, der
gefundenen Voraussetzungen und der ermittelten Anforderungen einen
BI-Gesamtansatz bei der WESTFA GmbH zu implementieren. Im Vordergrund stehen
2 1.3 Vorgehensweise und Gliederung
dabei die Implementierung eines Data Warehouse, eines ETL-Prozesses der das
Data Warehouse regelmäßig mit aktuellen Daten aus den operativen Systemen füllt
und eines auf dem Data Warehouse aufbauenden Analysesystems.
Mit Abschluss der vorliegenden Arbeit soll die WESTFA GmbH in die Lage versetzt
werden, mit Hilfe eines OLAP-Systems unternehmensweite Analysen beruhend auf
tagesaktuellen Daten durchführen zu können.
1.3 Vorgehensweise und Gliederung
Zunächst soll dem Leser ein kurzer Einblick in den BI-Markt gegeben werden.
Nach der Entscheidung für den Microsoft SQL Server 2005 als ein geeignetes
Werkzeug zur Realisierung des BI-Gesamtansatzes bei der WESTFA GmbH wird der
CRISP-Prozess zu Beginn der dritten Phase aufgenommen und die Bearbeitung der
einzelnen Prozessphasen in separaten Kapiteln beschrieben.
Die Phase Data Preparation beschreibt in Kapitel 3 die Implementierung eines
ETL-Prozesses und damit einhergehend auch die des Data Warehouse. Darauf
aufbauend erfolgt in Kapitel 4 die Phase Modeling, in welcher das auf OLAP
basierende Analysesystem in Form einer multidimensionalen Datenstruktur
definiert und anschließend als Cube bereitgestellt und verarbeitet wird.
Anschließend erfolgt eine Evaluation der erarbeiteten Ergebnisse in Bezug auf die
gestellten Anforderungen und den Informationsbedarf der Anwender in Kapitel 5.
Die Produktivsetzung des implementierten BI-Gesamtansatzes erfolgt schließlich in
Kapitel 6.
2 Werkzeugauswahl 3
2 Werkzeugauswahl
Bevor mit der Implementierung eines BI-Gesamtansatzes bei der WESTFA GmbH, im
folgenden WESTFA genannt, begonnen werden kann, muss darüber entschieden
werden, welche Werkzeuge für eine Implementierung verwendet werden sollen.
2.1 Der BI-Markt
Der BI-Softwaremarkt macht bei einer groben Betrachtung durch sein vielfältiges
Angebot einen zunächst unübersichtlichen und nur schwer zu strukturierenden
Eindruck. Als Strukturierungshilfe lässt sich der dieser Arbeit zugrundeliegende und
in der vorhergegangenen Projektarbeit 1 erläuterte BI-Gesamtansatz heranziehen.
Dieser lässt sich in vier unterschiedliche und separat betrachtbare Teilbereiche mit
jeweils andersgearteten Funktionsanforderungen unterscheiden.
!
!
!
!
ETL-Prozess
Datenbereitstellung
Informationsgenerierung/ -speicherung/ -distribution
Informationszugriff
Im Hinblick auf den gegebenen Funktionsumfang und die Einsetzbarkeit der am BIMarkt verfügbaren Werkzeuge in den unterschiedenen Teilbereichen des BIGesamtansatzes, lässt sich eine grobe Unterscheidung der angebotenen Software in
zwei Gruppen vornehmen:
! Einzelne Spezialwerkzeuge
! Modulbasierte Gesamtlösungen
In die Kategorie der einzelnen Spezialwerkzeuge fallen Werkzeuge, die speziell für
die Realisierung eines bestimmten Teilbereiches des BI-Gesamtansatzes entwickelt
wurden. Beispielhaft lassen sich Werkzeuge nennen, die sich auf die Modellierung
von ETL-Prozessen, oder noch spezieller sogar nur auf die Bereinigung von Daten
innerhalb eines ETL-Prozesses konzentrieren.
In den letzten Jahren hat auf dem BI-Markt eine starke Konsolidierung
stattgefunden, die bis heute noch kein Ende gefunden hat. Die zahlreichen Anbieter
von Spezialwerkzeugen werden dabei von großen namhaften Unternehmen
1
(Claßen, 2008 S. 13)
4 2.1 Der BI-Markt
aufgekauft, wodurch die Anzahl von unterschiedlichen BI-Software-Anbietern
rückläufig ist.
Ein Resultat dieser Konsolidierung ist, dass am BI-Markt weniger Werkzeuge zu
finden sind, die lediglich einen Teilbereich des BI-Gesamtansatzes unterstützen.
Anbieter solcher Werkzeuge finden sich heute in Marktnischen oder bieten ein sehr
weit entwickeltes und auf eine bestimmte Kundengruppe bzw. Branche angepasstes
Produkt an.
Mit der Konsolidierung stehen die am Markt angebotenen, modulbasierten
Gesamtlösungen, die eine Unterstützung von allen Teilbereichen des
BI-Gesamtansatzes anbieten, stärker im Fokus. Abbildung 2-1 zeigt eine Übersicht
verschiedener Anbieter von BI-Anwendungen und deren Einordnung in den „Magic
Quadrant for Business Intelligence Platforms“.
Abbildung 2-1: Magic Quadrant for Business Intelligence Platforms, 2008
2
(Richardson, et al., 2008)
2
2 Werkzeugauswahl 5
2.2 Entscheidung
Gemäß der vorgenommenen Abgrenzung von BI-Software in Einzellösungen und
den so genannten BI-Suiten wurde für die Verwendung bei WESTFA eine erste
richtungsweisende Entscheidung für den Einsatz einer BI-Suite getroffen.
Der Nachteil einer Entscheidung für separate Einzelwerkzeuge wurde darin
vermutet, dass die Integration der einzelnen Werkzeuge, aber auch der damit
erstellten Lösungen, die Realisierung des BI-Gesamtansatzes schwieriger gestalten
können. Außerdem ist gegebenenfalls das Einarbeiten in die unterschiedlichen
Handhabungen der einzelnen Werkzeuge zusätzlicher Zeit- und Arbeitsaufwand. Die
beispielhaft genannten Nachteile der Einzellösungen beschreiben zugleich die
Stärken der großen Gesamtlösungen. Die einzelnen Module zur Bearbeitung der
unterschiedlichen Komponenten des BI-Gesamtansatzes sind bereits integriert und
auch die damit erstellten Lösungen harmonisieren untereinander.
In der Kategorie von BI-Gesamtlösungen dominieren derzeit vier Anbieter mit ihren
Produkten zwei Drittel des gesamten BI-Marktes:
!
!
!
!
Microsoft – Microsoft SQL Server 3
IBM - IBM Cognos 8 Business Intelligence 4
SAP - SAP NetWeaver BI 5
Oracle - Oracle Business Intelligence Suite 6
Da bei WESTFA bereits Lizenzen für den Microsoft SQL Server 2005 vorhanden
waren und auch im Hinblick auf die Integration des MS SQL Servers in die bereits
vorhandene, auf weitere Microsoftprodukte basierende Systemlandschaft wurde
beschlossen, den Microsoft SQL Server 2005 für die Implementierung eines BIGesamtansatzes zu einzusetzen.
2.3 SQL Server 2005
Der SQL Server 2005 wurde vor allem durch die Integration von neuen
umfangreichen analytischen Funktionen gegenüber seiner Vorgängerversion noch
stärker auf die Anforderungen von BI-Projekten ausgerichtet. Durch seinen
komponentenbasierten Aufbau bietet er zu jedem der aus dem BI-Gesamtansatz
bekannten Teilbereiche Unterstützung. Abbildung 2-2 zeigt den groben Aufbau des
SQL Server 2005 mit seinen unterschiedlichen Komponenten.
3
(Microsoft Corporation)
(IBM Corporation )
5
(SAP Deutschland AG & Co. KG)
6
(Oracle Corporation)
4
6 2.3 SQL Server 2005
Für eine Implementierung eines BI-Gesamtansatzes bei WESTFA wird der
Schwerpunkt auf den Kernkomponenten Datenbankmodul, Analysis Services,
Reporting Services und Integration Services liegen, die in den folgenden Kapiteln
kurz erläutert werden. Der SQL Server 2005 bringt eine eigene
Entwicklungsumgebung, das „Business Intelligence Development Studio“ mit sich,
mit welcher Lösungen auf Basis der Analysis Services, Integration Services und
Reporting Services entwickelt werden können. Das SQL Server Management Studio
bietet Möglichkeiten zur Verwaltung des Datenbankmoduls und dem Zugriff auf die
mit den Hauptkomponenten erstellten Lösungen.
Abbildung 2-2: Beziehungen zwischen den Komponenten des SQL Server 2005
7
2.3.1 Integration Services
Die SQL Server 2005 Integration Services (SSIS) bieten “eine Plattform zum Erstellen
leistungsfähiger Datenintegrations- und Workflowlösungen, einschließlich ETLVorgängen (Extrahieren, Transformieren und Laden) für das Data Warehousing.“ 8
Für die Extraktion von Daten aus unterschiedlichen und verteilten Datenquellen
steht genau so wie für das Verarbeiten von unterschiedlichen Datenflüssen und das
anschließende Speichern in verschiedenen Datenzielen eine Vielzahl von Tasks zur
Verfügung.
Die Modellierung solcher Prozesse erfolgt mit Hilfe einer grafischen Oberfläche,
ohne dass Kenntnisse einer Programmiersprache erforderlich sind. Modellierte
Prozesse können in einem oder in mehreren Paketen gespeichert und einzeln oder
in definierter Reihenfolge einmalig oder wiederholt ausgeführt werden.
7
8
(Corporation, 2008 S. SQL Server (Übersicht))
(Corporation, 2008 S. SQL Server Integration Services (Übersicht))
2 Werkzeugauswahl 7
Die SSIS sind außerdem auf die speziellen Anforderungen von BI-Lösungen
ausgerichtet. Sie bieten spezielle Tasks, die auf die Verarbeitung von großen
Datenmengen und spezielle Anforderungen beim Befüllen eines Data Warehouse
ausgelegt sind.
2.3.2 Datenbankmodul
„Microsoft SQL Server 2005-Datenbankmodul ist ein Dienst zum Speichern und
Verarbeiten von Daten, die entweder in einem relationalen (tabellarischen) Format
oder als XML-Dokumente vorliegen.“ 9
Innerhalb des Datenbankmoduls angelegte, in Datenbanken gespeicherte Tabellen
oder Views lassen sich durch die Integration Services mit Daten aus
unterschiedlichsten Quellen füllen.
Zusätzlich verfügt das Datenbankmodul über ein eigenes Berechtigungskonzept, das
sich in bereits bestehende Windows-Systemlandschaften integriert und bereits
definierte Benutzerrichtlinien übernehmen kann.
2.3.3 Analysis Services
“Microsoft SQL Server 2005 Analysis Services (SSAS) stellt Online Analytical
Processing (OLAP, Analytische Onlineverarbeitung) und Data Mining-Funktionalität
mithilfe einer Kombination aus Server- und Clienttechnologien bereit.” 10
Durch die Clienttechnologie der SSAS lassen sich Daten aus einer relationalen
Datenquelle, meist einem Data Warehouse, in einer multidimensionalen
Datenstruktur organisieren und in Form von Cubes mit Hilfe der Servertechnologie
für OLTP-Anfragen von Client-Anwendungen wie MS Excel oder verschiedenen
Frontend-Werkzeugen bereitstellen.
Die Entwicklung von Data-Mining Modellen auf Basis von multidimensionalen wie
auch von relationalen Daten und deren Bereitstellung wird ebenfalls durch die SSAS
ermöglicht.
9
(Corporation, 2008 S. SQL Server-Datenbankmodul)
(Corporation, 2008 S. SQL Server Analysis Services)
10
8 2.3 SQL Server 2005
2.3.4 Reporting Services
Die SQL Server Reporting Services (SSRS) bilden “eine serverbasierte
Berichtsplattform zur Erstellung und Verwaltung von Berichten in tabellarischer,
grafischer und freier Form […]“ 11. Grundlage für die erstellten Berichte können
Daten aus multidimensionalen aber auch relationalen Datenquellen sein. Die
Bereitstellung der Berichte erfolgt über Web-Frontend, welches neben dem
einfachen Aufruf auch die Verwaltung von Berichten, Datenquellen und
Zugriffsberechtigungen ermöglicht.
11
(Schrödl, 2006 S. 43)
3 Data Preparation 9
3 Data Preparation
Data Preparation, die dritte Phase des CRISP-Prozesses, beschreibt die Aktivitäten,
die erforderlich sind, um aus vorhandenen operativen Daten dispositive Daten zu
erzeugen. Die in dieser Phase erstellte Datenbasis bildet nach dem CRISP-Prozess
die Grundlage für die Entwicklung von Data Mining Modellen.
Auch wenn bei WESTFA nicht die Entwicklung von Data-Mining-Modellen, sondern
die eines auf OLAP basierenden Analysesystems im Vordergrund steht, sind die
einzelnen Aktivitäten dieser Phase sehr ähnlich. Die im CRISP-Prozess vorgesehenen
Aktivitäten „Select Data“, „Clean Data“, „Construct Data“, „Integrate Data“ und
„Format Data“ entsprechen den Aktivitäten eines ETL-Prozesses. Lediglich die
abschließende Aktivität des Ladens der transformierten Daten in eine
Zieldatenbank, in der Regel ein Data Warehouse, wird durch den CRISP-Prozess
nicht beschrieben. Eine Gegenüberstellung der Aktivitäten eines ETL-Prozesses und
denen der Data Preparation Phase zeigt Abbildung 3-1.
Abbildung 3-1: Aktivitäten eines ETL-Prozesses und der Phase Data Preparation
3.1 Unterschiedliche Strategien
Das Ziel der Data Preparation Phase ist es, aus einem Datenbestand Daten zu
extrahieren und diese für die Analyse in dispositiver Form bereitzustellen. Dieses
Ziel lässt sich auf unterschiedliche Arten erreichen, welche im Folgenden kurz
erläutert werden.
10 3.1 Unterschiedliche Strategien
Die einfachste Möglichkeit lässt sich mit speziellen Frontendwerkzeugen realisieren.
Neben dem Erstellen von Auswertungen erlauben es diese Werkzeuge, heterogene
Datenbanksysteme als Datenlieferanten für die zu erstellende Auswertung zu
nutzen. Dieses hat den Vorteil, dass Berichtssysteme direkt auf den operativen
Datenbestand zugreifen und keine separate Datenhaltungsschicht benötigt wird.
Vergleichbar ist dieser Aufbau mit einer aus der Softwaretechnik bekannten,
zweischichtigen Client-Server-Architektur. Der Nachteil dieser Architektur besteht
jedoch darin, dass aufwendige Analysen direkt auf dem operativen Datenbestand
ausgeführt werden. Dadurch kann es zu negativen Auswirkungen zum Beispiel
durch gesperrte Datensätze oder zu zeitlichen Verzögerungen in den operativen
Systemen kommen.
Diese negativen Auswirkungen lassen sich durch eine separate
Datenhaltungsschicht beseitigen. Diese bildet eine vollständige Kopie der Daten aus
den operativen Systemen und stellt diese dem Frontendwerkzeug für die Analyse
zur Verfügung. Dadurch sind die operativen Systeme auch bei aufwendigen
Auswertungen nicht negativ betroffen.
Eine Erweiterung dieser Architektur besteht darin, zwischen dem Frontend und den
operativen Systemen nicht nur ein vollständiges Abbild der operativen Systeme zu
erstellen, sondern stattdessen ein Data Warehouse zu pflegen. Dieses wird
regelmäßig mit neuen operativen Daten versorgt und bildet diese durch
implementierte Logiken in dispositiver Form ab. Dieser Aufbau ist vergleichbar mit
der Drei-Schichten-Architektur, ebenfalls bekannt aus der Softwaretechnik.
Bei der Überführung der operativen Daten in das Data Warehouse übernimmt der
ETL-Prozess die Verarbeitungslogik. Frontendwerkzeuge mit einem Data Warehouse
als Datenbasis müssen daher lediglich Funktionalitäten zur optischen Aufbereitung
der darzustellenden Informationen bieten.
Abhängig von der Größe eines Data Warehouse und der angestrebten Komplexität
von Analysemöglichkeiten werden für die Analyse separate Cubes erstellt. Sie bilden
eine weitere Datenschicht zwischen dem Data Warehouse und dem Frontend,
welche durch vorberechnete und aggregierte Werte in einer multidimensionalen
Datenstruktur speziell auf die Anforderungen der Analyse ausgerichtet sind.
Die Realisierung der Data Preparation Phase erfolgt bei WESTFA nach oben
beschriebenem Vorgehen des BI-Gesamtansatzes, sodass der vollständige ETLProzess zum Befüllen eines ebenfalls in dieser Phase zu entwickelnden Data
Warehouse gegeben ist.
In den folgenden Kapiteln werden die einzelnen Aktivitäten zur Implementierung
eines ETL-Prozesses bei WESTFA, auftretende Probleme und Schwierigkeiten und
deren Lösung beschrieben. Dabei erfolgt die Bearbeitung der Aktivitäten der Data
3 Data Preparation 11
Preparation Phase eingebettet in die drei Teilbereiche Extraktion, Transformation
und Laden des ETL-Prozesses.
3.2 Extraktion von ausgewählten Daten
In der vorhergehenden CRISP-Prozessphase des Business Understanding12 wurden
die drei bei WESTFA eingesetzten operativen Systeme (megaWWS, V_Olga und
PivotalCRM) 13, genauer deren Datenbasen, betrachtet und bereits Tabellen mit
relevanten Inhalten identifiziert. Als relevante Inhalte wurden dabei Daten
verstanden, die für die Entwicklung eines grundlegenden Analysesystems bei
WESTFA nötig sind.
Als einer der Hauptgründe, warum Analysen bei WESTFA bisher häufig nur auf
Geschäftsbereichsebene oder nur mit viel Zeit- und Arbeitsaufwand
unternehmensweit angestellt werden konnten, wurde in der vorhergehenden
Projektarbeit der Einsatz von drei unterschiedlichen operativen Systemen mit dem
daraus resultierenden getrennten und verteilten operativen Datenbestand
ermittelt.
3.2.1 Persistent Staging Area
Aufgrund der heterogenen und verteilten Systemlandschaft bei WESTFA wurde auf
dem MS SQL Server ein Speicherbereich geschaffen, der als Persistent Staging Area
(PSA) genutzt wird. Dieser dient zur „[…] Zwischenspeicherung der Daten aus den
Vorsystemen vor deren Weiterverarbeitung. Ohne Modifikationen hinsichtlich
Format oder Inhalt werden die gelieferten Informationsobjekte in relationalen
Tabellen deponiert […]“ 14 Für die Abbildung der PSA wurden innerhalb der
Datenbank die drei Schemata „olga“, „wws“ und „kol“ erstellt. Sie stehen jeweils für
die operativen Systeme bei WESTFA und sollen helfen, innerhalb der PSA die
Tabellen dem jeweiligen Quellsystem zuzuordnen. Die PSA dient als Datenquelle für
die weiteren Transformationen innerhalb des ETL-Prozesses, wobei die operativen
Systeme nicht weiter durch diese belastet werden.
Die Extraktion der Daten aus den operativen Systemen, das automatisierte Füllen
der entsprechenden Tabellen sowie deren einmaliges Erstellen in der PSA wurde
mit Hilfe der SQL Server Integration Services realisiert. Als Entwicklungswerkzeug
diente dafür das „SQL Server Business Intelligence Development Studio“ (kurz
BI-Studio), das nach der Installation des MS SQL Servers zur Verfügung stand.
12
(Claßen, 2008)
(Claßen, 2008 S. 38 f.)
14
(Chamoni, et al., 2005 S. 49)
13
12 3.2 Extraktion von ausgewählten Daten
Zunächst wurde ein neues „Integration Services-Projekt“ erstellt, in welchem dann
beliebig viele „SSIS-Pakete“ erstellt werden können. Jedes SSIS-Paket besteht aus
einer „Ablaufsteuerung“. Die Verarbeitung von Daten erfolgt auf der Ebene der
„Ablaufsteuerung“ durch die Verwendung eines „Datenflusstask“. Dieser bietet auf
der Ebene „Datenfluss“ weitere Tasks wie Datenflussquellen,
Datenflusstransformationen und Datenflussziele.
Die einfachste Möglichkeit, Daten zu extrahieren und anschließend in die
Zieldatenbank zu laden, lässt sich über die Verwendung eines „Ole DB Quelle“ und
eines „Ole DB Ziel“ Task realisieren. In so genannten Verbindungsmanagern lassen
sich die Verbindungsdaten zu einer Datenbank speichern und anschließend in Quelloder Ziel-Tasks verwenden. Nach der Auswahl eines Verbindungsmanagers in dem
Quell-Task lassen sich die zu ladende Tabelle und deren Attribute einzeln auswählen
oder sie können über eine manuell einzugebende SELECT-Anweisung bestimmt
werden. Nach dem Verbinden eines Quell-Tasks mit einem Ziel-Task kann in diesem
nach Auswahl eines Verbindungsmanagers für die Zieldatenbank eine bestehende
Tabelle als Ziel ausgewählt werden oder basierend auf den durch den Quell-Task
übergebenen Meta-Daten eine neue Tabelle in der Datenbank angelegt werden.
Wird dieses SSIS-Paket ausgeführt, werden alle Datensätze mit den ausgewählten
Attributen aus der Quelle extrahiert und unverändert in das angegebene Ziel
geladen.
Für den Prozess der Extraktion der Daten aus den operativen Systemen und dem
Befüllen der PSA wurde bei WESTFA zunächst in dem SQL Server Business
Intelligence Development Studio ein neues Integration Services-Projekt mit dem
Namen „ExtractLoad StagingArea“ erstellt. In diesem Projekt wurden dann die drei
SSIS-Pakete „ExtractLoad megaWWS“, „ExtractLoad Kolumbus“, und „ExtractLoad
V_Olga“ erzeugt. In diesen Paketen wurden die jeweiligen Ablaufsteuerungen zur
Extraktion des operativen Datenbestandes für das jeweilige operative System
realisiert. Zur Wahrung der Übersichtlichkeit innerhalb der SSIS-Pakete wurden auf
der Ebene der Ablaufsteuerung mehrere Datenflusstasks erstellt, in denen nach
Informationsobjekten getrennt die einzelnen Datenflüsse mit Quelle und Ziel
definiert wurden. Während der Ausführung eines Paketes werden die einzelnen
Datenflusstasks sequentiell ausgeführt.
Im Folgenden werden die Besonderheiten der Extraktion von Daten aus den
einzelnen Systemen bei WESTFA beschrieben.
3 Data Preparation 13
3.2.2 Extraktion aus PivotalCRM
Die Extraktion der Daten aus dem PivotalCRM System, im folgenden Kolumbus
genannt, hat sich am einfachsten gestaltet, da die Datenbasis von Kolumbus durch
einen MS SQL Server 2005 gebildet wird und dadurch die größtmögliche
Kompatibilität gegeben ist.
In diesem Fall kann die bereits weiter oben beschriebene, einfachste Möglichkeit
mit der ausschließlichen Verwendung von Quell- und Ziel-Tasks verwendet werden
(siehe Abbildung 3-2). Den Datenfluss zeigt Abbildung 3-2 beispielhaft für das
Extrahieren und Laden von Daten aus der Kundentabelle “Company” von Kolumbus.
Dieses ist vor allem dadurch möglich, da der Quell-Task die Datentypen der
Attribute von Tabellen richtig aus der SQL-Server-Quelle lesen kann und somit keine
weitere Verarbeitung nötig ist. Die extrahierten Daten können direkt in die
Zieltabelle geschrieben werden.
Abbildung 3-2: Datenfluss zur Extraktion von Daten aus Kolumbus
14 3.2 Extraktion von ausgewählten Daten
3.2.3 Extraktion aus megaWWS
Mit der aus dem Data Understanding gewonnenen Information, dass megaWWS
trotz der Verwendung einer Informix Datenbank über eine ODBC Schnittstelle
erreichbar ist, gestaltet sich das reine Extrahieren der Daten aus megaWWS ähnlich
zu dem bereits bekannten Vorgehen von Kolumbus. Lediglich die Parameter bei der
Definition des entsprechenden Verbindungsmanagers für die Informix-Datenbank
unterscheiden sich (siehe Abbildung 3-3).
Abbildung 3-3: Verbindungsmanager zur Informix-Datenbank von megaWWS
Die Definition des Ziel-Tasks kann wiederum analog zu der bereits beschriebenen
Vorgehensweise erfolgen.
Aufgrund der Informix-Datenbank als Quelle können die Datentypen der Tabellen
zwar durch den Quell-Task erkannt werden, jedoch werden die Inhalte nicht richtig
ausgelesen. Bei allen Tabellenattributen mit dem Datentyp CHARACTER werden die
Inhalte bis auf die maximale Attributgröße mit Leerzeichen aufgefüllt. Dieses
erfordert vor dem Laden in die Zieltabelle eine Bearbeitung der betroffenen
Attribute durch einen separaten Task (Abbildung 3-4, Seite 15), in der die
vorhandenen Leerzeichen ausschließlich am Ende des ursprünglichen
Attributwertes entfernt werden (Abbildung 3-5, Seite 15). Das wurde durch den
Task „Abgeleitete Spalte“ und der Funktion rtrim() erreicht, die nachfolgende
Leerzeichen eines Textes entfernt.
3 Data Preparation 15
Abbildung 3-4: Datenfluss zur Extraktion von Daten aus megaWWS
Abbildung 3-5: Entfernen von Leerzeichen in einem separaten Task des Datenflusses
3.2.4 Extraktion aus V_Olga
Bereits aus der dieser Arbeit vorausgegangenen Analyse potentieller Datenquellen
bei WESTFA ist bekannt, dass der direkte Datenbankzugriff auf die V_Olga technisch
nicht möglich ist. Alternativ wurden bereits während der Analyse die nachts
erstellten Sicherungsdateien der V_Olga als alternative Datenquellen identifiziert 15.
Für die Extraktion der Daten bedeutet dieses, dass zunächst ein genaues Abbild von
den Tabellen der V_Olga in der PSA erstellt werden muss, da in den
Sicherungsdateien lediglich der Tabelleninhalt gespeichert wird und keine
Informationen über die Struktur der Tabelle.
Um ein genaues Abbild der Tabellenstrukturen erstellen zu können,wird eine
weitere Sicherungsdatei der V_Olga herangezogen. In dieser Datei werden die
SQL-Anweisungen zum Erstellen jeder einzelnen Tabelle abgelegt.
15
Siehe (Claßen, 2008 S. 54)
16 3.2 Extraktion von ausgewählten Daten
Aus dieser können die entsprechenden Anweisungen entnommen, auf die TransactSQL (T-SQL) Syntax und die entsprechenden Datentypen angepasst und schließlich
im SQL Server ausgeführt werden. Somit kann die Tabellenstruktur der V_Olga in
der PSA abgebildet werden.
Die Extraktion der Daten aus einer Datei mit flacher Datenstruktur kann über einen
speziell für diesen Dateityp vorgesehenen Task vorgenommen werden. Die
Besonderheit hierbei ist, dass für jede Datei ein eigener Verbindungsmanager
erstellt werden muss. Innerhalb dieses Verbindungsmanagers müssen die einzelnen
Datentypen der Attribute manuell festgelegt werden, da diese nicht automatisch
oder falsch erkannt werden. Über einen weiteren Task „Konvertierung“ werden die
Längen von Attributen des Datentyps String angepasst.
Abbildung 3-6 zeigt die Datenflussebene des SSIS-Paketes „ExtractLoad V_Olga“ für
die Extraktion von Kundendaten. Links unten sind die erstellten
Verbindungsmanager zu sehen. Das geöffnete Dialogfenster stellt die allgemeinen
Parameter zur Konfiguration eines Verbindungsmanagers für Dateien mit flacher
Datenstruktur dar.
Abbildung 3-6: Datenfluss zur Extraktion von Daten aus V_Olga
3 Data Preparation 17
Abbildung 3-7 zeigt die erweiterten Parameter des Verbindungsmanagers aus
Abbildung 3-6. Hier kann für jede Eingabespalte der Datentyp und eine Name
angegeben werden.
Abbildung 3-7: Erweitere Konfiguration eines Verbindungsmanagers für Dateien mit flacher Datenstruktur
3.2.4.1 Fehlerbehandlung während des Extraktionsprozesses
Eine weitere Hürde hat sich beim Extrahieren der Daten aus den Systemen
megaWWS und V_Olga ergeben. Durch das steigende Exportgeschäft von WESTFA
treten Sonderzeichen wie die französischen Akzente in steigender Zahl in Kundenund Straßennamen sowie in Artikelbezeichnungen oder Angebotstexten auf.
Diese Zeichen werden durch die Anwender oftmals falsch verwendet. Die am
häufigsten auftretende Falscheingabe ist, dass ein Akzent anstelle eines Apostrophs
gesetzt wird. Optisch gibt es in der Zeichensetzung kaum einen Unterschied, jedoch
ist das alleinige Auftreten des Akzents ohne darunterliegenden Buchstaben kein
gültiges Zeichen. Tritt dieses Zeichen dennoch beim Extrahieren der Daten aus der
Datenquelle auf, bricht der Prozess umgehend mit einer Fehlermeldung ab und die
Extraktion schlägt fehl.
Um zu erreichen, dass der Extraktionsprozess trotz eines aufgetretenen Fehlers
fortgeführt werden kann und alle fehlerfreien Datensätze extrahiert werden,
musste an dieser Stelle eine Fehlerbehandlung in den Prozess integriert werden.
18 3.2 Extraktion von ausgewählten Daten
Für eine Fehlerbehandlung lassen sich generell zwei Vorgehensweisen
unterscheiden. Entweder wird ein Fehler zwar erkannt, aber dennoch ignoriert oder
er wird in definierter Form weiterverarbeitet. Da das Ignorieren eines auftretenden
Fehlers zu einer inkonsistenten Datenbasis geführt hätte, wurde eine einfache
Fehlerbehandlung in die SSIS-Pakete zur Extraktion von Daten aus den Systemen
megaWWS und V_Olga implementiert.
Tritt bei der Extraktion der Daten aus der Datenquelle ein Fehler auf, wird der
fehlerhafte Datensatz nicht in die vorgesehene Zieltabelle der PSA geschrieben,
sondern in eine Tabelle einer separat angelegten Datenbank mit dem Namen
„westfaE“. Durch diese Fehlerbehandlung wird sichergestellt, dass alle Datensätze
aus der Datenquelle extrahiert werden können und alle korrekten Datensätze in die
Zieltabelle innerhalb der PSA geschrieben werden. In Abbildung 3-8 wird der aus
Abbildung 3-4 bereits bekannte Datenfluss mit implementierter Behandlung von
fehlerhaften Datensätzen dargestellt.
Abbildung 3-8: Datenfluss zur Extraktion von Daten mit Fehlerbehandlung
Wenn alle Extraktionsprozesse für eine Datenquelle abgearbeitet sind, wird durch
einen separaten Prozess geprüft, ob in den Tabellen der „westfaE“ Datenbank
Inhalte vorhanden sind. Wurden dort Datensätze geschrieben, werden diese in eine
für einen Sachbearbeiter handhabbare Excel-Tabelle importiert und ihm via Email
zugesandt. Dieser ist dann dafür verantwortlich, die Datensätze im jeweiligen
operativen System zu korrigieren, so dass der Fehler in einem der nächsten Läufe
des Extraktionsprozesses nicht mehr auftritt.
3 Data Preparation 19
Diese relativ einfache, aber doch sehr effektive Behandlung von groben
Falscheingaben trägt bereits aktiv zur Verbesserung der Datenqualität in den
operativen Systemen bei. Dabei steht die Strategie im Vordergrund, auftretende
Fehler möglichst weit vorne im Entstehungsprozess zu beheben und möglichst
wenig Fehler automatisiert inmitten des Prozesses zu beheben.
3.2.5 Automatisierung der Extraktionen
Um die Extraktion der operativen Daten und damit das Befüllen der PSA
automatisiert ablaufen lassen zu können, wurde zunächst ein viertes SSIS-Paket
erstellt. In diesem werden nacheinander alle Tabellen der PSA durch mehrere Tasks
vom Typ „SQL ausführen“ mit entsprechenden SQL-Anweisungen geleert. Somit
sind für einen automatisierten Ablauf der Extraktion vier SSIS-Pakete nötig, welche
in Abbildung 3-9 gezeigt werden.
Abbildung 3-9: SSIS-Pakete für die Extraktion
Die SSIS-Pakete können mit Hilfe des Befehlszeilen-Dienstprogramms dtecex 16 in
einer erstellten Batch-Datei ausgeführt werden. Die Abarbeitung der erstellten SSISPakete erfolgt sequentiell entsprechend der innerhalb der Batch-Datei
angegebenen Reihenfolge der Aufrufe. Dabei wird das nächste SSIS-Paket erst
ausgeführt, nachdem die Verarbeitung des vorherigen erfolgreich abgeschlossen
wurde.
Neben der reinen Ausführung der SSIS-Pakete wird durch das Dienstprogramm
dtexec die Log-Datei „SSIS_PSA.log“ erstellt. In diese werden während der
Ausführung von dtexec detailreiche Informationen über auftretende Ereignisse
und durchgeführte Verarbeitungsschritte geschrieben.
16
Für eine nähere Erläuterung zur Funktionsweise des Dienstprogrammes „dtexec“ und der
Bedeutung der Parameter sei auf die SQL Server 2005 Online Dokumentation verwiesen:
http://msdn.microsoft.com/de-de/library/ms162810(SQL.90).aspx
20 3.3 Transformation der Daten
dtexec /FILE „C:\SSIS_PAKETE_PSA\1 truncate StagingArea.dtsx“ MAXCONCURRENT
„ -1 “ /CHECKPOINT OFF /REPORTING EWCDI >> SSIS_PSA.log
dtexec /FILE „C:\SSIS_PAKETE_PSA\2 ExtractLoad megaWWS.dtsx“ MAXCONCURRENT
„ -1 “ /CHECKPOINT OFF /REPORTING EWCDI > SSIS_PSA.log
dtexec /FILE „C:\SSIS_PAKETE_PSA\3 ExtractLoad Kolumbus.dtsx“ MAXCONCURRENT
„ -1 “ /CHECKPOINT OFF /REPORTING EWCDI > SSIS_PSA.log
dtexec /FILE „C:\SSIS_PAKETE_PSA\4 ExtractLoad V_Olga.dtsx“ MAXCONCURRENT
„ -1 “ /CHECKPOINT OFF /REPORTING EWCDI > SSIS_PSA.log
Für die zeitgesteuerte Ausführung der Batch-Datei wurde ein Task auf dem
Betriebssystem definiert. Dieser führt die Batch-Datei an Wochentagen um 00:15
aus (Abbildung 3-10).
Abbildung 3-10: Geplanter Task zur Ausführung der definierten Batch-Datei
So wird der erste Schritt des ETL-Prozesses, nämlich der Teil „Extract“ erledigt. Jede
Nacht werden die vorhandenen Tabellen der Persistent Staging Area zunächst
geleert und anschließend mit den aktuellen Daten aus den operativen Systemen
gefüllt. Dadurch ist WESTFA im Besitz einer tagesaktuellen Spiegelung der
Datenbestände aus den drei operativen Systemen V_Olga, megaWWS und
Kolumbus in nur einer Datenbank. Zusätzlich ist diese für diverse Abfragewerkzeuge
wie MS Access, MS Excel oder andere Frontendwerkzeuge verfügbar.
Bereits durch die Extraktion der Daten und deren Integration in eine Datenbank ist
ein Mehrnutzen für WESTFA geschaffen, indem Daten der V_Olga nun
beispielsweise für das Controlling leicht zugänglich zur Verfügung stehen.
3.3 Transformation der Daten
Im Rahmen der Transformationsphase eines ETL-Prozesses werden alle nötigen
Aktivitäten durchgeführt, um die extrahierten operativen Daten in dispositive Daten
zu überführen. Wie bereits Abbildung 3-1 gezeigt hat, decken sich die Aktivitäten
Filterung, Harmonisierung, Aggregation und Anreicherung im Rahmen der
Transformationsphase eines ETL-Prozesses mit den durch den CRISP-Prozess
vorgesehenen Aktivitäten Clean Data, Construct Data, Integrate Data und Format
Data.
Mit der Erstellung einer Persistant Staging Area wurde bereits eine Filterung auf
Datenbanktabellenebene vorgenommen und dafür gesorgt, dass für die
Konstruktion eines Data Warehouse mit Dimensions- und Faktentabellen nur noch
eine Datenquelle genutzt werden muss.
3 Data Preparation 21
Der gesamte Prozess von der Extraktion der vorgefilterten Daten aus der PSA über
die Transformation, die Erstellung von Dimensions- und Faktentabellen sowie die
damit verbundene Konstruktion und das Laden der Daten in das Data Warehouse
wurde innerhalb eines zweiten, separaten Integration Services-Projekts
implementiert. Dabei wurde durch die Verwendung von zwei getrennten
SSIS-Paketen zwischen der Verarbeitung der Dimensionen und der Verarbeitung der
Fakten unterschieden.
Eine generelle Unterteilung der Transformationsphase in die einzelnen Aktivitäten,
wie sie beispielsweise durch den CRISP-Prozess beschrieben werden, lässt sich nicht
direkt vornehmen. Das liegt daran, dass die einzelnen Aktivitäten nicht einmal
allgemeingültig abgearbeitet werden können, sondern explizit auf die
unterschiedlichen Daten jeder zu ladenden Tabelle individuell angewandt werden
müssen. Einen allgemeingültigen Ablauf der Transformationsphase, wie er bei
WESTFA implementiert wurde, zeigt Abbildung 3-11.
Abbildung 3-11: Der allgemeine Transformationsprozess
Für die weitere Verarbeitung der Daten wurde der Schwerpunkt auf die während
der Informationsbedarfsanalyse gefundenen Anforderungen gelegt 17.
3.3.1 Filterung
Die Filterung beschreibt die erste Schicht der Transformationsphase und hat zum
Ziel, die für das Data Warehouse benötigten Daten aus den entsprechenden
Quellen zu selektieren und diese von Mängeln zu befreien. Somit lässt sich die
Filterung in die beiden Teilbereiche der Selektion und der Bereinigung von Daten
unterteilen. Diese entsprechen den Aktivitäten „Select data“ und „Clean data“ des
CRISP-Prozesses.
17
(Claßen, 2008 S. 50)
22 3.3 Transformation der Daten
3.3.1.1 Selektion
Für die Selektion von Daten kann es nicht nur relevant sein, eine Selektion von
Tabellen und Attributen vorzunehmen, sondern auch eine Selektion auf
Datensatzebene kann ein entscheidendes Kriterium sein. Dieses spielt vor allem
dann eine Rolle, wenn in einer Tabelle des operativen Systems eine sehr große
Datenmenge vorhanden ist oder eine Tabelle aus sehr vielen für das Data
Warehouse relevanten Attributen besteht. In diesen Fällen ist zu überdenken, ob es
nötig ist, alle vorhandenen Daten in das Data Warehouse zu übernehmen oder ob
eine Einschränkung der Daten, beispielweise auf einen bestimmten Zeitraum wie
die letzten drei Jahre, vorgenommen werden kann.
Bei WESTFA sind die in der PSA vorhandenen Daten bereits im Rahmen der
Extraktionsphase auf der Tabellenebene gefiltert worden, so dass nur Tabellen mit
für das Data Warehouse relevanten Inhalten aus den operativen Systemen
übernommen wurden. Für die Erstellung von Dimensions- oder Faktentabellen im
Rahmen der Transformationsphase müssen nun lediglich noch die für das Data
Warehouse benötigten Attribute aus den Tabellen selektiert werden.
Für die Selektion der Attribute bietet der Quell-Task des BI-Studios zwei
grundlegende Möglichkeiten. Entweder können nach Angabe der Quelltabelle die
benötigten Attribute der Tabelle ausgewählt werden, oder sie können über einen
manuell erstellten SQL-Befehl bestimmt werden.
Die Bestimmung der Attribute über einen SQL-Befehl wurde bei WESTFA primär
verwendet, da sich diese Lösung als wesentlich flexibler herausgestellt hat. Über
einen SQL-Befehl lassen sich nicht nur mehrere Tabellen verknüpfen, sondern der
Befehl kann auch zu einem späteren Zeitpunkt noch ohne Probleme erweitert
werden.
Trotz der durch einen SQL-Befehl sehr umfangreichen Möglichkeiten reicht in
manchen Fällen ein einziger Quell-Task nicht aus, um alle benötigten Attribute zu
extrahieren und in den Datenfluss zu integrieren. In einer solchen Situation werden
mehrere Quell-Tasks benötigt, um alle relevanten Attribute aus den Tabellen der
PSA zu extrahieren.
3 Data Preparation 23
3.3.1.2 Datenbereinigung
Der andere Teilbereich der Filterung ist das Bereinigen der selektierten Daten von
syntaktischen und semantischen Mängeln. „Unter syntaktischen Mängeln sind
hierbei formelle Mängel der code-technischen Darstellung zu verstehen.
Semantische Mängel betreffen dagegen Mängel in den betriebswirtschaftlichen
Inhalten der Daten.“ 18 Des Weiteren lassen sich Mängel in drei unterschiedliche
Mängelklassen unterscheiden. Die Unterscheidung wird anhand der Möglichkeiten
zur Erkennung und der Bereinigung von Mängeln vorgenommen. Abbildung 3-12
zeigt den Entscheidungsprozess, der zur Einordnung eines auftretenden Mangels in
eine Mangelklasse dient und verdeutlicht weiter, dass ausschließlich Mängel der 1.
Klasse automatisiert behoben werden können. Mängel der 2. und 3. Klasse
erfordern manuelle Datenmanipulationen.
Abbildung 3-12: Einteilung von Mängeln in drei Klassen
Die Behebung von syntaktischen und semantischen Mängeln der 1. Klasse kann
durch Transformationsregeln automatisiert werden, „da sie bereits vor der
Erstellung der Extraktionsroutinen bekannt sind bzw. ihr Auftreten antizipiert
werden kann.“ 19
Im Rahmen der Implementierung eines BI-Gesamtansatzes bei WESTFA wurde mit
dem Business Sponsor vereinbart, dass semantische Mängel innerhalb des
Datenbestandes nicht automatisiert behoben werden sollen, sondern diese dem
Anwender innerhalb der verschiedenen Analysen präsentiert werden sollen. Mit
diesem Vorgehen soll das parallele Ziel verfolgt werden, die Datenqualität in den
18
19
(Kemper, et al., 2006 S. 25)
(Kemper, et al., 2006 S. 26)
24 3.3 Transformation der Daten
operativen Systemen zu steigern. Eine Bereinigung von Mängeln würde aus
betriebswirtschaftlicher Sicht zunächst zu „sauberen“ Analysen führen. Jedoch
würden Mängel nicht behoben, sondern die Anzahl von Mängeln unter Umständen
weiter steigen, da entsprechende Hinweise auf Falscheingaben oder nicht stimmige
Automatismen bei der Datenpflege nicht erfolgen.
Neben der bereits in Kapitel 3.2.4.1 beschriebenen Fehlerbehandlung während der
Extraktionsphase wurde bei WESTFA nur eine sehr grobe Behandlung von Mängeln
implementiert. Diese beschränkt sich im Rahmen der semantischen Mängel auf das
Verwerfen von verwaisten oder nur testweise angelegten Datensätzen. Diese
Bereinigung wurde entweder direkt in die SQL-Anweisungen der Datenselektion
durch eine WHERE-Bedingung integriert oder durch eine entsprechende Filterung
betroffener Datensätze im Datenfluss implementiert. Abbildung 3-13 zeigt
beispielhaft eine SQL-Anweisung, wobei mit Hilfe einer WHERE-Bedingung
Datensätze von Unternehmen ohne Kunden- oder Interessentennummer gefiltert
werden.
Abbildung 3-13: Filterung semantischer Mängel mittels SQL-Anweisung
Eine Behandlung von syntaktischen Mängeln im Rahmen der Filterung wurde nicht
explizit implementiert. Die Anpassung von unterschiedlichen Datentypen oder
Formatierungen wurde mit der Integration von Daten aus unterschiedlichen
Datenquellen in die im Anschluss an die Filterung durchzuführende Harmonisierung
verschoben.
3.3.1.3 Unterschiede der Filterung für Fakten und Dimensionen
Die Schicht der Filterung, speziell die Selektion von Daten, lässt sich aufgrund der
unterschiedlichen Zielsetzungen danach unterscheiden, ob Daten für eine zu
erstellende Dimensions- oder eine Faktentabelle selektiert werden sollen.
Während für die Erstellung einer Dimensionstabelle die für ein Informationsobjekt
beschreibenden Daten selektiert werden, wird für die Erstellung einer Faktentabelle
auswertbares Zahlenmaterial selektiert.
Aber auch die Datenmenge, die im Rahmen der Filterung an die nächsten
Prozessschritte übergeben wird unterscheidet sich bei Dimensionen und Fakten.
Während für die Erstellung von Dimensionen immer alle vorhandenen Daten zur
weiterverarbeitet werden und die Verarbeitung durch Slowly Changing Dimensions
3 Data Preparation 25
übernommen wird, lassen sich zur Verarbeitung der Fakten zwei
Herangehensweisen unterscheiden, die im Folgenden kurz erläutert werden.
3.3.1.3.1 Inkrementelle Selektion von Fakten
Die inkrementelle Selektion von Fakten setzt voraus, dass mindestens einmal alle
Fakten aus dem jeweiligen Quellsystem extrahiert und in die Faktentabelle des Data
Warehouse geschrieben wurden.
Von diesem Zeitpunkt an ist es ausreichend, nur noch neuere, noch nicht in der
Faktentabelle befindliche Datensätze aus den Quellsystemen zu filtern und zu
verarbeiten. Realisierbar ist diese Methode beispielsweise, wenn Auftrags- oder
Kundennummern fortlaufend durch das Quellsystem vergeben werden. Dann kann
die höchste, in der Faktentabelle vorkommende Nummer ermittelt werde und aus
dem Quellsystem werden nur noch Datensätze extrahiert, deren Nummer größer
ist. Diese Methode verringert nach dem erstmaligen Füllen der Faktentabelle die zu
verarbeitende Datenmenge und dadurch auch die Verarbeitungszeit des gesamten
ELT-Prozesses deutlich.
Ergeben sich jedoch Änderungen an Fakten die bereits in der Vergangenheit liegen,
werden diese Änderungen durch die inkrementelle Selektion der Fakten nicht
berücksichtigt und können das Analyseergebnis auf Basis dieser Fakten verfälschen.
Abhilfe schafft die Erweiterung, die das Änderungsdatum eines Datensatzes, sofern
vorhanden, zusätzlich berücksichtigt.
3.3.1.3.2 Vollständige Selektion von Fakten
Im Gegensatz zur inkrementellen Selektion werden bei der vollständigen Selektion
bei jedem Durchlauf des ETL-Prozesses alle Faktentabellen zunächst geleert und
anschließend vollständig neu selektiert und verarbeitet. Diese Methode der
Selektion benötigt aufgrund der größeren Datenmenge gegenüber der
inkrementellen Selektion mehr Zeit für die entsprechenden Verarbeitungsschritte,
stellt jedoch sicher, dass alle Fakten stets aktuell sind.
3.3.2 Harmonisierung
Die Harmonisierung bildet die zweite Schicht der Transformation. Sie entspricht der
Aktivität „Integrated data“ des CRISP-Prozesses und verfolgt die Angleichung und
die anschließende Zusammenführung der aus unterschiedlichen Tabellen oder
Datenbanken stammenden Daten. Mit der Integration der Daten und der damit
verbundenen themenbezogenen Gruppierung von entsprechenden Informationen
werden die operativen Daten hier bereits betriebswirtschaftlich interpretierbar und
somit für dispositive Zwecke verwendbar.
26 3.3 Transformation der Daten
Um eine themenbezogene Gruppierung, wie sie durch eine Dimension abgebildet
wird, erstellen zu können, müssen drei wesentliche Vorbedingungen gelten:
! Abstimmung von Kodierung, Synonymen und Homonymen
! Lösung des Problems der Schlüsseldisharmonien
! Vereinheitlichung betriebswirtschaftlicher Begriffsabgrenzungen 20
Die Problematik von unterschiedlichen Kodierungen sowie von Homonymen hat bei
WESTFA während der Transformationsschicht keine Rolle gespielt, da diese Fälle
nicht aufgetreten sind. Dass lässt sich mit den drei sehr stark voneinander
abweichenden Datenstrukturen der Quellsysteme begründen.
Unterschiedliche Kodierungen beschreiben Daten, die identische Attributnamen
und eine identische Bedeutung besitzen, jedoch durch abweichende Datenbereiche
beschrieben werden.
Homonyme hingegen besitzen zwar denselben Attributnamen, weisen jedoch
unterschiedliche Bedeutungen auf.
Sehr häufig hingegen musste die Problematik der Synonyme behandelt werden.
Attribute werden als Synonyme bezeichnet, wenn sie unterschiedliche
Attributnamen, jedoch dieselbe Bedeutung besitzen. Auch dieser Fall ist mit den
unterschiedlichen Datenstrukturen der drei Quellsysteme zu begründen. Zur Lösung
dieser Problematik wurde eine Definition von Begrifflichkeiten erstellt. Diese
Definition stellt sicher, dass die Attribute mit demselben Namen im Data
Warehouse immer dieselbe Bedeutung haben.
Die am häufigsten vorkommende Problematik war die der Schlüsseldisharmonien.
Diese lassen sich gerade bei der Integration von Daten aus verschiedenen Systemen
oder Datenquellen nicht vermeiden. „Schlüsseldisharmonien basieren auf
Unverträglichkeiten der Primärschlüssel in den extrahierten und bereinigten Daten
und entstehen durch die Verwendung unterschiedlicher Zugriffsschlüssel in der
operativen Datenhaltung.“ 21
In Kolumbus werden künstliche Primärschlüssel in Form eines Attributes des
Datentyps Binary(8) für jeden Datensatz erzeugt. Sie sind losgelöst von der
Geschäftslogik und dienen lediglich der Identifikation eines Datensatzes. Im
Gegensatz zu Kolumbus verwendet megaWWS keine separaten Attribute als
Primärschlüssel. Diese werden aus einem oder mehreren Attributen gebildet, die
der Geschäftslogik entspringen. Abbildung 3-14 zeigt einen Ausschnitt der
megaWWS Kundentabelle. Der Primärschlüssel wird hierbei durch die
Personenkontonummer (pkt_nr) gebildet. Interessenten werden in megaWWS in
einer separaten Tabelle auf die gleiche Weise gespeichert. In Kolumbus werden
20
21
(Wilmes, et al., 2004 S. 42)
(Kemper, et al., 2006 S. 28)
3 Data Preparation 27
jedoch Kunden und Interessenten in einer Tabelle gespeichert. Diese hat drei
unterschiedliche Attribute zur Speicherung von Nummern. Solange ein
Unternehmen als Interessent geführt wird, ist die entsprechende Nummer in dem
Attribut AO_Lead_Code gespeichert. Wird aus dem Interessent ein Kunde, wird
eine neue Kundennummer generiert und diese in dem Attribut Account_Code
gespeichert. Das Feld ao_display_nummer führt die aktuell gültige Nummer
eines Unternehmens.
Abbildung 3-14: Ausschnitt der Kundentabelle in megaWWS
Abbildung 3-15: Ausschnitt der Unternehmenstabelle von Kolumbus
Im Rahmen der Harmonisierung wurden Unternehmensdaten aus megaWWS und
Kolumbus über die Attribute ao_display_nummer und pkt_nr verknüpft. Als
Verknüpfungstyp wurde die „Vollständige äußere Verknüpfung“ gewählt, da
zunächst alle Datensätze aus beiden Tabellen für die Weiterverarbeitung benötigt
werden. Als Ergebnis liefert diese Verknüpfung ein Datenset bestehend aus allen
Attributen beider Tabellen. Dieses wurde in einem weiteren Schritt so aufbereitet,
dass durch die Verknüpfung doppelt vorhandene Attribute wie Namen, Adressen
oder Kundennummern eliminiert wurden. Diese Zusammenfassung wurde durch
einen Task für „Abgeleitete Spalten“ und bedingte Abfragen realisiert (Abbildung
3-16). Unter der theoretischen Annahme, dass alle Kunden und Interessenten in
Kolumbus vorhanden sind (da hier die zentrale Stammdatenverwaltung
implementiert wurde), werden die aus Kolumbus stammenden Attribute durch die
entsprechenden Werte der aus megaWWS stammenden Attribute ergänzt, wenn
kein Wert aus Kolumbus vorhanden ist.
28 3.3 Transformation der Daten
Abbildung 3-16: Vereinheitlichung von Unternehmensdaten aus megaWWS und Kolumbus
Das inhaltlich aufbereitete Datenset muss nun syntaktisch weiter aufbereitet
werden. Dazu werden in einem separaten Task für „Bedingtes Teilen“ zunächst alle
unbrauchbaren Datensätze, weil sie unvollständig, leer oder nicht identifizierbar
sind gefiltert und von der weiteren Verarbeitung ausgeschlossen. Dieses erfolgt
über die Weiterleitung an einen Task „Multicast“, der keine weitere Ausgabe der
einkommenden Daten fordert. Alle brauchbaren Datensätze werden hingegen an
einen Task zur „Datenkonvertierung“ geleitet, der die Datentypen und deren
Formatierung der einzelnen Attribute auf das für die zu erstellende Unternehmensdimension anpasst.
Den gesamten Ablauf der Harmonisierung von Unternehmensdaten zeigt Abbildung
3-17.
Abbildung 3-17: Harmonisierung von Unternehmensdaten
Ob und welche Arbeitsschritte im Rahmen einer Harmonisierung erforderlich sind,
ist immer auch abhängig von dem zugrundeliegendem Datenmaterial und dem
gewünschten Ergebnis. Aufgrund der jeweiligen Spezialisierungen der drei bei
WESTFA eingesetzten operativen Systeme ist eine aufwendige Harmonisierung wie
im vorherigen Beispiel der Kunden aus megaWWS und Kolumbus nicht immer nötig
oder möglich.
Es werden sowohl in megaWWS als auch in der V_Olga Artikel in separaten
3 Data Preparation 29
Artikeltabellen gepflegt. Allgemein würde eine Harmonisierung im Rahmen einer
Integration hier einen erkennbaren Mehrnutzen bringen. Aufgrund der großen
Unterschiedlichkeit der Artikel aus nicht vergleichbaren Branchen und dem sich
daraus ergebenden vollkommen unterschiedlichen Aufbau der beiden
Artikeltabellen ist der nötige Zeitaufwand einer integrierten Abbildung der Artikel
nicht gerechtfertigt. Daher wurden viele bei WESTFA geschäftsfeldspezifische
Strukturen nicht integriert, sondern separat harmonisiert und in die gewünschten
Zielformate transformiert.
Das Ergebnis der Harmonisierung beschreibt ein „bereinigter und konsistenter
Datenbestand auf der niedrigsten Granularitätsebene[..]“ 22. Dieser Datenbestand
beschreibt bereits den Aufbau einer Dimensionstabelle.
3.3.3 Aggregation & Anreicherung
Mit dem Abschluss der Harmonisierung ist der Transformationsprozess von
operativen zu dispositiven Daten auf der niedrigsten Granularitätsebene vollzogen.
Aufgrund der riesigen Datenmenge die in einem Data Warehouse gespeichert wird,
können Analysen dank der bisher durchgeführten Transformation der Daten zwar
unternehmensweit durchgeführt werden, jedoch sind sie oft noch sehr zeitintensiv.
Dieses lässt sich vor allem mit den verschiedenen Berechnungen von Werten auf
unterschiedlichen Granularitätsebenen begründen, welche im Rahmen einer
Analyse durchzuführen sind. Die Transformationsschichten Aggregation und
Anreicherung behandeln die Themen der betriebswirtschaftlichen Aufbereitung der
gefilterten und harmonisierten Daten.
3.3.3.1 Aggregation
Das Ziel der Aggregationsschicht ist es daher, aus Gründen der
Performanceoptimierung, bestimmte Werte bereits im Vorfeld zu aggregieren und
in separaten Tabellen für spätere Analysen zu speichern. Die Aufsummierungen
lassen sich hierarchisch bis zu einer obersten Gesamtsumme auf
unterschiedlichsten Aggregationsstufen abbilden. Durch die vorberechneten Werte
ist es für durchzuführende Analysen nicht mehr nötig, diese Aggregationen zur
Laufzeit selbst durchzuführen, denn sie können die berechneten Werte direkt aus
dem Data Warehouse entnehmen.
Um aus betriebswirtschaftlicher Sicht sinnvolle Aggregationen von Werten zu
erhalten, orientieren sich die Aggregationen an zu definierenden Hierarchien
innerhalb der Dimensionen. Diese werden in einem Data Warehouse durch
22
(Wilmes, et al., 2004 S. 43)
30 3.3 Transformation der Daten
unterschiedliche Dimensionshierarchietabellen abgebildet. Als typische Hierarchien
lassen sich beispielhaft Artikelgruppen für Artikel oder Kundengruppen für Kunden
nennen. Auch die hierarchische Darstellung der Zeit kann einen Einfluss auf die
Aufsummierung von Werten haben, ebenso wie auf die Darstellung von
Hierarchieebenen. Einmal definierte Dimensionshierarchien durchlaufen mit der
Zeit strukturelle Veränderungen. Beispiele dafür wären, wenn sich das
Verkaufsgebiet eines Vertriebsmitarbeiters zu einem Zeitpunkt um einige
Postleitzahlenbereiche vergrößert oder aufgrund von Änderungen im
Produktsortiment die Unterteilung der Produkte in Produktgruppen geändert wird.
Um solche Änderungen im Rahmen von Analysen auch „über die Historie der Daten
zu gewährleisten, sind die Veränderungen in den Tabellen mit Gültigkeitsstempeln
(Zeitstempeln) zu versehen.“ 23
3.3.3.2 Anreicherung
Die Anreicherung der Daten findet im Anschluss an die Aggregation statt. Dabei
werden aus den Daten der unterschiedlichsten Granularitätsebenen
betriebswirtschaftliche Kennzahlen berechnet und im Data Warehouse gespeichert.
Die Speicherung der ermittelten Kennzahlen kann sowohl in separaten Tabellen
erfolgen und auch als neues Attribut für einen vorhandenen Datensatz.
Mit der Aggregation und der Anreicherung von Daten durch Zusatzinformationen,
beruhend auf betriebswirtschaftlichem Verständnis, verschwimmen die klassischen
Grenzen zwischen der Anwendungs- und der Datenhaltungsschicht. Aus einer
reinen Datenbasis wurde das Data Warehouse durch die Implementierung von
Geschäftslogik zum betriebswirtschaftlichen Werkzeug.
Die Implementierung einer Aggregations- und Anreicherungsschicht wurde für das
bei WESTFA erstellte Data Warehouse nicht vorgenommen.
Mit dem Ziel der Implementierung eines auf OLAP basierenden Analysesystems
wurden die Aktivitäten dieser Schichten erst mit dem durch den SQL-Server
angebotenen Werkzeug zur Erstellung eines OLAP-Cubes implementiert (siehe
Kapitel 4). Dieses bietet für das Definieren von unterschiedlichen Hierarchien,
berechneten Werten und betriebswirtschaftlichen Kennzahlen weitgehende
Unterstützung. Zudem soll der Zugriff der späteren Anwender vorwiegend über das
zu erstellende Analysesystem erfolgen und das Data Warehouse daher primär als
integrierte Datenbasis dienen.
23
(Kemper, et al., 2006 S. 31)
3 Data Preparation 31
Abbildung 3-18 zeigt den bis zu diesem Zeitpunkt bei WESTFA implementierten ETLProzess.
Abbildung 3-18: Bisher bei WESTFA implementierter Aufbau des ETL-Prozesses
24
3.4 Konstruktion und Laden des Data Warehouse
Mit der Verlagerung der Aggregations- und Anreicherungsschicht auf einen
späteren Implementierungszeitpunkt folgt im Anschluss an die Harmonisierung die
abschließende Phase des Ladens der innerhalb der Transformationsphase
konstruierten Dimensionen und Fakten in physisch vorhandene Dimensions- und
Faktentabellen des Data Warehouse.
Die einmalige Erstellung der entsprechenden Tabellen im Data Warehouse erfolgt
dabei während der Realisierung des Ladevorgangs mit Hilfe des BI-Studios. Mit der
Implementierung von Fakten- und Dimensionstabellen im Data Warehouse werden
die aus den operativen Daten erzeugten dispositiven Daten in einer sich am
Geschäftsverständnis von WESTFA orientierenden dimensionalen Datenstruktur
gespeichert.
Eine Definition der dimensionalen Modellierung liefert Kimball:
„Dimensional modeling is a logical design technique for structuring data so that it’s
intuitive to business users and delivers fast query performance.“ 25
Eine dimensionale Datenstruktur lässt sich in Measures, im Weiteren Fakten
genannt, und in beschreibenden Kontext unterteilen. Fakten entstehen durch die
Abbildung von Geschäftsprozessen innerhalb der operativen Systeme in Form von
auswertbarem Zahlenmaterial. Jeder Fakt wird zum Zeitpunkt seiner Erstellung von
24
25
(Kemper, et al., 2006 S. 28)
(Kimball, et al., 2008 S. 234)
32 3.4 Konstruktion und Laden des Data Warehouse
Kontext umgeben, der zu genau diesem Zeitpunkt aktuell ist. Dieser beschreibende
Kontext wird thematisch geordnet und zusammengefasst in Dimensionen
unabhängig von den Fakten abgebildet. „Dimension describe the „who, what, when,
where, why and how” context of the measurement. 26“
Um innerhalb des Ladeprozesses die Fakten ihrem Kontext, also den Dimensionen,
zuordnen zu können, muss dieser vor der Erstellung eines Datensatzes innerhalb
einer Faktentabelle vorhanden sein. Realisiert wird diese Verbindung über
Fremdschlüsselbeziehungen im Data Warehouse, siehe Kapitel 3.4.3. Dieses
impliziert, dass innerhalb des Ladeprozesses zunächst die Dimensionstabellen und
anschließen die Faktentabellen mit Daten gefüllt werden. Entsprechend dieser
Reihenfolge wird in den folgenden Kapiteln zunächst das Laden der
Dimensionstabellen (3.4.1) und anschließend das der Faktentabellen (3.4.2) näher
erläutert.
26
(Kimball, et al., 2008 S. 235)
3 Data Preparation 33
3.4.1 Laden der Dimensionstabellen
Die Implementierung der Ladeprozesse kann aufgrund der gegebenen
Unterstützung des BI-Studios im direkten Anschluss an die Transformationsphase
stattfinden.
Für die Erstbefüllung der Dimensionstabellen muss noch auf keine Restriktion
geachtet werden. Aus Gründen der Performance wurde bei WESTFA deshalb
zunächst ein einfacher OleDB Ziel-Task verwendet. Dieser schreibt übergebene
Datensätze in eine Zieltabelle. Zur Konfiguration des OleDB Ziel-Tasks wurde
zunächst die Datenbank, in diesem Fall westfaDW, ausgewählt.
Jetzt kann entweder eine bestehende Tabelle als Ziel angegeben werden oder es
kann eine neue Tabelle erstellt werden. Wie bereits beschrieben, wurden die
erforderlichen Dimensionstabellen in der Datenbank noch nicht angelegt, weshalb
an dieser Stelle die für eine Dimension entsprechende Tabelle zunächst definiert
werden musste.
Standardmäßig wird durch das BI-Studio in Form einer SQL-Anweisung ein Befehl
zur Erstellung einer neuen Tabelle generiert, siehe Abbildung 3-19 auf Seite 34. Die
Anweisung wird basierend auf den Metadaten, die dem Task vom Datenfluss
übergeben werden generiert. Als Name der Tabelle wird der dem Ziel-Task
angegebene Name verwendet. Als Attribute werden standardmäßig alle im
Datenfluss verfügbaren Attribute mitsamt ihren Datentypen vorgeschlagen. Mit
dem Bestätigen dieser Anweisung wird in der angegebenen Zieldatenbank eine
Tabelle nach diesen Vorgaben erstellt.
34 3.4 Konstruktion und Laden des Data Warehouse
Abbildung 3-19: Ole DB-Ziel: Durch das BI-Studio generierte SQL-Anweisung zum erstellen einer neuen
Dimensionstabelle
Nicht alle im Laufe des Datenflusses verwendeten Attribute sind für den Aufbau
einer Dimensionstabelle erforderlich. Daher ist es zwingend erforderlich, die
generierte SQL-Anweisung lediglich als groben Rahmen zu verstehen und die
erforderlichen Anpassungen gemäß der jeweiligen Zielsetzung vorzunehmen. Die
Anpassungen sind im Wesentlichen:
!
!
!
!
!
Reduzierung der Attribute den Anforderungen entsprechend
Überprüfung der Namensgebung von Attributen
Überprüfen der Datentypen und deren Wertebereiche
Definition eines Surrogat Keys
Definition von zwei Attributen zur Abbildung von Zeitstempeln (falls eine
Historisierung der Dimension erforderlich ist)
3 Data Preparation 35
Die für eine Unternehmensdimension angepasste SQL-Anweisung zeigt Abbildung
3-20. Es wurden überflüssige, noch aus der Transformationsphase stammende
Attribute entfernt, aussagekräftige Attributnamen verwendet, Attributtypen und
deren Wertebereich angepasst, ein künstliches Primärschlüsselattribut erzeugt und
für die Abbildung von historischem Kontext zwei DateTime-Attribute bestimmt.
Abbildung 3-20: Bearbeitete SQL-Anweisung zum erstellen einer Dimensionstabelle
Mit dem Bestätigen dieser SQL-Anweisung wird in der angegebenen Zieldatenbank
die entsprechende Dimensionstabelle angelegt und kann nun erstmalig geladen
werden.
Die Vorgehensweise des Ladeprozesses von Dimensionstabellen lässt sich auf
unterschiedliche Weise implementieren. Grundsätzlich lassen sich jedoch abhängig
von der gewünschten Dimensionsverwendung zwei Arten unterscheiden. Entweder
kann eine Dimension dazu genutzt werden, Fakten lediglich in den aktuellsten
Kontext einzubetten, oder sie kann dazu genutzt werden, Fakten zusätzlich in einem
historischen Kontext darzustellen.
Um Fakten nur dem aktuell gültigen Kontext zuzuordnen, reicht es aus, den Inhalt
der Dimensionstabelle innerhalb des Ladeprozesses neu zu erstellen. Dieses kann
über das Leeren der Dimensionstabelle und das anschließende Laden von aktuellen
Daten realisiert werden. Dieses Vorgehen lässt sich jedoch nicht realisieren, wenn
auf der Datenbankebene Fremdschlüsselbeziehungen der Faktentabelle zu dieser
Dimensionstabelle bestehen. Die Fremdschlüsselbeziehungen dürfen zu keinem
36 3.4 Konstruktion und Laden des Data Warehouse
Zeitpunkt ins Leere verweisen, was sie im Falle einer verknüpften und geleerten
Dimensionstabelle aber tun würden. Die Definition von Fremdschlüsselbeziehungen
wird in Kapitel 3.4.3 genauer erläutert.
In den meisten Fällen jedoch sollen Dimensionen innerhalb eines Data Warehouse
die Schwäche der operativen Systeme, nämlich Daten ausschließlich im aktuellen
Zusammenhang darstellen zu können, durch eine historische
Darstellungsmöglichkeit von Fakten ausgleichen.
Die Verarbeitung von Dimensionen und die je nach Anforderung unterschiedliche
Aufbereitung von inhaltlichen Veränderungen werden unter dem Begriff „Slowly
Changing Dimensions“ zusammengefasst.
3.4.1.1 Slowly Changing Dimensions
Der Begriff der Slowly Changing Dimensions stammt aus der Beobachtung, dass sich
die Inhalte einer Dimensionstabelle im Gegensatz zu den sich ständig verändernden
und stetig anwachsenden Faktentabellen nur langsam verändern.
Innerhalb der Slowly Changing Dimensions werden Typ 1, Typ 2 und Typ 3 abhängig
vom jeweiligen Umgang mit neuen und sich ändernden Attributwerten bestehender
Datensätze unterschieden.
Jede Dimension, unabhängig von ihrem implementierten Verfahren innerhalb des
Ladeprozesses, beinhaltet einen so genannten Geschäftsschlüssel. Dieser kann als
die reale Bezeichnung der Entität verstanden werden, die durch eine Dimension
abgebildet wird. Geschäftsschlüssel für Kunden oder Produkte wären demnach die
Kunden- und die Produktnummer.
3.4.1.1.1 Typ1
Wird eine Dimension als Slowly Changing Dimension vom Typ 1 implementiert,
bedeutet dieses, dass neue Datensätze in die Dimensionstabelle geschrieben
werden und bei einer Änderung eines Attributwertes der alte Wert durch den
neuen überschrieben wird. Die Identifikation eines Datensatzes kann dabei über
den Geschäftsschlüssel, der in einer Dimension vom Typ 1 als Primärschlüssel
verwendet werden kann, erfolgen. Durch das einfache Aktualisieren des
Attributwertes wird gewährleistet, dass die Dimension zu jeder Zeit den aktuellsten
Stand beschreibt. Dadurch wird jedoch die Möglichkeit jeglicher
Vergangenheitsbetrachtung genommen.
Die Verwendung des Typ 1 für eine Dimension ist angebracht, wenn an
bestehenden Daten lediglich Datenkorrekturen vorgenommen werden oder wenn
die Attributwerte keine Bedeutung für eine betriebswirtschaftliche Beschreibung
der Fakten haben.
Die Implementierung eines Ladeprozesses für eine Dimension nach Typ 1 ist ohne
3 Data Preparation 37
viel Aufwand möglich. Jedoch muss man sich während der Implementierung
bewusst sein, dass solche Dimensionen nicht mehr den historischen Kontext zum
Zeitpunkt des Auftretens eines Faktes beschreiben, sondern ihn im aktuellen
Kontext abbilden.
Im Folgenden zeigt ein Beispiel die Verarbeitung von Slowly Changing Dimensions
nach Typ 1.
Ausgangssituation ist eine fiktive Kundendimension.
nummer (pk)
230981
230982
230983
name
Luke
Dalton
Dalton
vorname
Lucky
Joe
Averall
strasse
Wildwestweg 3
Kittchengasse 1
Kittchengasse 2
telefon
123456
456789
123789
Tabelle 1: SCD Typ1: fiktive Kundendimension vor Verarbeitung
Folgender Datensatz wird aus dem operativen System extrahiert:
230982
Dalton
Joe
Freierweg 7
456789
Tabelle 2: SCE Typ1: extrahierter Datensatz mit geändertem Attributwert
Nach Typ 1 sieht die Dimension nach dem Ladeprozess wie folgt aus:
nummer (pk)
230981
230982
230983
name
Luke
Dalton
Dalton
vorname
Lucky
Joe
Averall
strasse
Wildwestweg 3
Freierweg 7
Kittchengasse 2
telefon
123456
456789
123789
Tabelle 3: SCD Typ1: fiktive Kundendimension nach Verarbeitung
3.4.1.1.2 Typ2
Die am häufigsten verwendete Methode, den Ladeprozess einer Dimension zu
implementieren, ist die der Slowly Changing Dimension Typ 2. Im Gegensatz zum
Typ 1 bietet sie die Möglichkeit, Veränderungen von Attributwerten historisch
abzubilden und somit einen Fakt im zum Zeitpunkt seines Auftretens gültigen
Kontext darzustellen.
Im Rahmen der Implementierung einer Slowly Changing Dimension vom Typ 2
werden zunächst die Dimensionsattribute bestimmt, die für eine historische
Darstellung von Fakten relevant sind. Während des Ladeprozesses wird analog zu
Typ 1 anhand des Geschäftsschlüssels zunächst in neue und bereits in der
Dimension vorhandene Datensätze unterschieden. Neue Datensätze werden direkt
in die Dimension geschrieben, während bei bereits vorhandenen Datensätzen eine
erneute Unterscheidung vorgenommen wird. Für diese muss geprüft werden, ob
sich eine Veränderung im jeweiligen Datensatz gegenüber den in der Dimension
gespeicherten ergeben hat. Bei Abweichungen in für die historische Darstellung von
Fakten nicht relevanten Attributen wird der vorhandene Wert mit dem neuen, wie
auch in Typ 1, überschrieben. Liegen Änderungen in für die Historie relevanten
38 3.4 Konstruktion und Laden des Data Warehouse
Attributen vor, wird ein neuer Datensatz mit den nun aktuellen Attributwerten
erzeugt. Um nachvollziehen zu können, welcher Datensatz zu welcher Zeit gültig
war, werden Dimensionen vom Typ 2 um zwei DateTime-Attribute erweitert. In
das eine wird bei der Neuanlage eines Datensatzes der aktuelle Zeitstempel, ab
wann der Datensatz gültig ist, als Indikator eingetragen. Tritt der Fall ein, dass ein
zweiter Datensatz angelegt werden muss, weil Änderungen an wichtigen
Attributwerten festgestellt wurden, erhält der alte Datensatz wiederum einen
Zeitstempel, der das Ablaufdatum des Datensatzes kennzeichnet. Der neue
Datensatz erhält seinerseits einen Zeitstempel, der ihn als aktuell gültig identifiziert.
Durch die Verwendung von Gültigkeitszeiträumen für die Datensätze einer
Dimension lässt sich der historische Kontext für Fakten jederzeit abbilden.
Diese Methode der Historienbildung hat jedoch zur Folge, dass Dimensionstabellen
vom Typ 2 mit der Zeit immer mehr Speicherplatz benötigen, weil sie konstant
anwachsen. Des Weiteren können Datensätze innerhalb dieser Dimension anhand
ihres Geschäftsschlüssels nicht mehr eindeutig identifiziert werden, da diese nun
mehrfach vorkommen können. Hierdurch ist man gezwungen, einen neuen
Primärschlüssel für die Dimension zu erschaffen. Eine Möglichkeit ist, einen neuen
Primärschlüssel bestehend aus dem Geschäftsschlüssel und den
DateTime-Indikatoren für die Gültigkeit der Datensätze zu definieren. Jedoch sind
DateTime-Attribute zur Verwendung als Primärschlüssel schon sehr ungeeignet
und innerhalb eines Data Warehouse verursacht ein aus mehreren Attributen
zusammengesetzter Primärschlüssel sehr hohe Performance- und Speicherkosten.
Aufgrund dessen ist die häufigste Lösung die Konstruktion eines neuen, künstlichen
Ersatzschlüssels, der jeden Datensatz innerhalb einer Dimension eindeutig
identifiziert und der unabhängig von den vorhandenen Attributwerten eines
Datensatzes gebildet wird. Den Ersatzschlüsseln, auch Surrogatschlüssel genannt,
kommt im Rahmen der Konstruktion eines Data Warehouse eine sehr große
Bedeutung zu, weshalb deren Verwendung in Kapitel 3.4.1.2 näher erläutert wird.
3 Data Preparation 39
Im Folgenden ein Beispiel, welches die Verarbeitung von Slowly Changing
Dimensions nach Typ 2 verdeutlicht.
Ausgangssituation ist eine fiktive Kundendimension, die am 7.1.09 geladen wurde.
key (pk)
1
2
3
nummer
230981
230982
230983
name
Luke
Dalton
Dalton
vorname
Lucky
Joe
Averall
strasse
Wildwestweg 3
Kittchengasse 1
Kittchengasse 2
telefon
123456
456789
123789
von
7.1.09
7.1.09
7.1.09
bis
Tabelle 4: SCD Typ2: fiktive Kundendimension vor Verarbeitung
Folgender Datensatz wird aus dem operativen System am 8.1.2009 extrahiert:
230982
Dalton
Joe
Freierweg 7
456789
Tabelle 5: SCD Typ2: extrahierter Datensatz mit geändertem Attributwert
Nach Typ 2 sieht die Dimension nach dem Ladeprozess wie folgt aus:
key (pk)
1
2
3
4
nummer
230981
230982
230983
230982
name
Luke
Dalton
Dalton
Dalton
vorname
Lucky
Joe
Averall
Joe
strasse
Wildwestweg 3
Kittchengasse 1
Kittchengasse 2
Freierweg 7
telefon
123456
456789
123789
456789
von
7.1.09
7.1.09
7.1.09
8.1.09
bis
8.1.09
Tabelle 6: SCD Typ2: fiktive Kundendimension nach Verarbeitung
3.4.1.1.3 Typ 3
Slowly Changing Dimensions Typ 3 werden verwendet, wenn sich Attribute einer
Dimension nur selten ändern und eine nur sehr grobe Historisierung erforderlich ist.
In diesem Fall wird, wenn an einem Attributwert eines in der Dimension bereits
vorhandenem Datensatz eine Änderung festgestellt wird, ein neues Attribut an den
vorhandenen Datensatz angehängt. Dieses Attribut erhält den zu überschreibenden,
nun veralteten Wert. Danach kann der alte Wert in dem ursprünglichen Attribut mit
dem neuen Wert überschrieben werden. Die Dimension enthält dadurch ein
Attribut mit dem aktuell gültigen Wert und eines mit dem Vorgängerwert. Alle auf
diese Dimension beruhenden Auswertungen verwenden automatisch den neuen
Attributwert, wobei es dennoch möglich bleibt, eine Auswertung auf Basis des
Vorgängerwertes zu erstellen.
Dieses Verfahren kommt ohne zusätzliche Zeitstempel aus und macht die
Verwendung von Surrogatschlüsseln zur Identifikation von einzelnen Datensätzen
unnötig. Jedoch kann auf diese Weise nur eine sehr begrenzte Anzahl von
Änderungen an Attributwerten verfolgt werden und auch der Zeitpunkt der
Änderung kann nicht nachvollzogen werden.
Das folgende Beispiel soll die Verarbeitung von Slowly Changing Dimensions nach
Typ 3 verdeutlichen.
Ausgangssituation ist die bekannte, fiktive Kundendimension.
40 3.4 Konstruktion und Laden des Data Warehouse
nummer (pk)
230981
230982
230983
name
Luke
Dalton
Dalton
vorname
Lucky
Joe
Averall
strasse
Wildwestweg 3
Kittchengasse 1
Kittchengasse 2
telefon
123456
456789
123789
Tabelle 7: SCD Typ3: fiktive Kundendimension vor Verarbeitung
Folgender Datensatz wird aus dem operativen System extrahiert:
230982
Dalton
Joe
Freierweg 7
456789
Tabelle 8: SCD Typ3: extrahierter Datensatz mit geändertem Attributwert
nummer (pk)
230981
230982
230983
name
Luke
Dalton
Dalton
vorname
Lucky
Joe
Averall
strasse
Wildwestweg 3
Freierweg 7
Kittchengasse 2
telefon strasse_alt
123456
456789 Kittchengasse 1
123789
Tabelle 9: SCD Typ3: fiktive Kundendimension nach Verarbeitung
3.4.1.1.4 Implementierung bei WESTFA
Das BI-Studio bietet auch für die Abbildung von Slowly Changing Dimensions eine
sehr gute und geführte Unterstützung in Form eines separaten Tasks mit dem
Namen „Langsam veränderliche Dimension“. Mit Hilfe dieses Tasks wurden der
Ladeprozess und die damit verbundene Verarbeitung je nach Dimensionstyp bei
WESTFA implementiert. Vorteil dieses Tasks ist die grafische und durch einen
Assistenten geführte Implementierungsmöglichkeit aller drei Dimensionstypen.
Außerdem lassen sich die Dimensionen über diesen Task aktualisieren, ohne dass
gegen Restriktionen (Fremdschlüsselbeziehungen, siehe Kapitel 3.4.3) auf Seiten der
Datenbank verstoßen wird, da die Dimensionen zu keinem Zeitpunkt geleert
werden müssen. Abbildung 3-21 zeigt den ersten Schritt zum erstellen einer Slowly
Changing Dimension, nachdem der entsprechende Task in den Datenfluss integriert
wurde. Voraussetzung für die Verwendung des Wizards ist, dass die
Dimensionstabelle bereits in der Datenbank angelegt wurde. Nach der Auswahl der
Zieldatenbank westfaDW und der zugrundeliegenden Dimensionstabelle, in diesem
Fall die dimUnternehmen, werden alle verfügbaren Attribute der
dimUnternehmen aufgelistet und es werden die entsprechenden Attribute aus
dem bisherigen Datenfluss den entsprechenden Dimensionsattributen zugeordnet.
Wesentlich hierbei ist, dass gleich welcher Dimensionstyp verwendet werden soll,
ein Dimensionsattribut als Geschäftsschlüssel gekennzeichnet wird anhand dessen
ein Unternehmensdatensatz identifiziert werden kann. Wie zu sehen ist, gibt es für
die vorhandenen Dimensionsattribute gueltig_von und gueltig_bis noch
keine entsprechenden Attribute, weshalb hier keine Zuordnung stattgefunden hat.
Sie werden im weiteren Verlauf des „Assistenten für langsam veränderliche
Dimensionen“ separat behandelt.
3 Data Preparation 41
Abbildung 3-21: SCD Assistent: Zuordnung von Datenflussattributen zu den Dimensionsattributen
Erst im zweiten Schritt zur Konfiguration der Slowly Changing Dimension, den
Abbildung 3-22 auf Seite 42 zeigt, erfolgt die Festlegung auf die Verarbeitungslogik
nach Typ1, Typ2 oder Typ3. Diese wird über die Konfiguration der einzelnen
Änderungstypen der Dimensionsattribute bestimmt. Bei den Änderungstypen
werden die drei Möglichkeiten „Festes Attribut“, „Veränderliches Attribut“ und
„Verlaufsattribut“ unterschieden.
„Feste Attribute“ dürfen ihren Attributwert nie ändern. Wird hier eine Änderung
des Wertes festgestellt, wird die Verarbeitung des Tasks abgebrochen oder, sofern
definiert, eine entsprechende Fehlerbehandlung durchgeführt. Diese Funktionalität
kann genutzt werden, um Slowly Changing Dimensions vom Typ 3 abzubilden. Diese
Änderungen werden durch den Task nicht direkt unterstützt, da hierfür Änderungen
an der Dimensionstabelle nötig wären. Mit Hilfe der Definition von „Festen
Attributen“ lassen sich jedoch Attribute vom Typ 3 identifizieren; lediglich die
weitere Implementierung kann nicht mit Unterstützung des Assistenten
durchgeführt werden
„Veränderliche Attribute“ beschreiben den Typ 1 einer Slowly Changing Dimension.
Bei Veränderungen der Attributwerte wird der alte Wert durch den neuen
überschrieben. Werden alle Attribute einer Dimension als „Veränderliches Attribut“
gekennzeichnet, entspricht dieses einer Slowly Changing Dimension vom Typ 1.
42 3.4 Konstruktion und Laden des Data Warehouse
Werden Veränderungen an Attributwerten festgestellt, die als „Verlaufsattribut“
gekennzeichnet sind, wird ein neuer Datensatz in der Dimensionstabelle angelegt.
Dabei werden alle Attributwerte des bereits vorhandenen Datensatzes
übernommen und ausschließlich die Änderungen von „Verlaufsattributen“ in den
neuen Datensatz geschrieben. Sobald ein Dimensionsattribut als „Verlaufsattribut“
gekennzeichnet wird entspricht dieses einer Slowly Changing Dimension vom Typ 2.
Durch die Möglichkeit, den Änderungstyp für jedes Dimensionsattribut separat
festlegen zu können wird verhindert, dass Dimensionstabellen vom Typ 2 zu schnell
anwachsen, denn nicht bei jeder Änderung eines Attributwertes wird ein neuer
Datensatz angelegt.
Bei WESTFA wurden im Rahmen der durchgeführten Informationsbedarfsanalyse
und dem „Data Understanding“ bereits Attribute einzelner Entitäten identifiziert,
für die eine historische Betrachtung ermöglicht werden soll.
Abbildung 3-22: SCD Assistent: Festlegung von Änderungstypen für die Dimensionsattribute
Im weiteren Verlauf des Assistenten muss bei der Verwendung des Änderungstyps
„Veränderliches Attribut“ angegeben werden, wie der aktuelle Datensatz
gekennzeichnet werden soll. Dazu können entweder ein separates Attribut mit
3 Data Preparation 43
wählbarem Indikator oder zwei zusätzliche DateTime-Attribute genutzt werden.
Während ein Indikator lediglich den aktuellen Datensatz markiert aber keine
Aussage darüber zulässt, bis wann ein alter Datensatz gültig ist, wird dies durch die
Verwendung eines Start- und Enddatums möglich. An dieser Stelle des Assistenten
werden die im ersten Schritt ignorierten Dimensionsattribute gueltig_von und
gueltig_bis konfiguriert. Als Attributwert kann dabei entweder ein Datum
manuell vorgegeben oder der Inhalt einer Systemvariablen genutzt werden.
Bei WESTFA wurden Dimensionen zur Abbildung einer Historie einheitlich nach der
in Abbildung 3-23 gezeigten Methode unter Verwendung von zwei zusätzlichen
DateTime-Attributen implementiert, um die Historie innerhalb der Dimensionen
auch in einem zeitlichen Kontext abbilden zu können.
Abbildung 3-23: SCD Assistent: Kennzeichnung des aktuellen Datensatzes bei SCD Typ 2
Zusätzlich zu den hier beschriebenen grundlegenden Konfigurationen innerhalb des
Assistenten für langsam veränderliche Dimensionen bietet dieser einige zusätzliche
Möglichkeiten der Behandlung von abgeleiteten Attributen. Diese wurden bei
WESTFA zum aktuellen Stand der Implementierung nicht verwendet und werden
daher an dieser Stelle nicht weiter beschrieben.
Der Assistent sorgt zum Schluss abhängig von der durchgeführten Konfiguration für
eine Erweiterung des bisherigen Datenflusses. Die durch den Assistenten erzeugte
Verarbeitung der Dimensionsdatensätze und das anschließende Laden dieser in die
Dimensionstabelle zeigt Abbildung 3-24.
Ausgehend vom Ursprungs Task „Langsam veränderliche Dimension“ wurden drei
Datenflüsse erzeugt:
44 3.4 Konstruktion und Laden des Data Warehouse
Die „Ausgabe der Updates von veränderlichen Attribute“ führt zu einem Task zur
Ausführung einer Datenbank-Anweisung. Hier werden die Werte von bereits
vorhandenen Datensätzen über eine Update-Anweisung aktualisiert.
Die „Ausgabe der Einfügevorgänge im Verlaufsattribut“ behandelt den Fall, dass
eine Änderung an einem Verlaufsattribut festgestellt wurde. Hier wird zunächst das
aktuelle Datum ermittelt und anschließend in den veralteten, bereits in der
Dimensionstabelle vorhandenen Datensatz als gueltig_bis Datum geschrieben.
Die „Neue Ausgabe“ enthält alle Datensätze, die anhand des definierten
Geschäftsschlüssels noch nicht in der Dimensionstabelle gefunden werden konnten
und wird durch den Task „UNION ALL“ mit den Datensätzen aus der „Ausgabe der
Einfügevorgänge im Verlaufsattribut“ zusammengeführt. Für diese Datensätze wird
ebenfalls das aktuelle Datum ermittelt, diesmal jedoch in das Attribut
gueltig_von geschrieben. Anschließend werden diese in die Dimensionstabelle
geladen.
Abbildung 3-24: Implementierung einer Slowly Changing Dimension Typ 2 bei WESTFA
3 Data Preparation 45
3.4.1.2 Surrogatschlüssel
Zunächst soll die Frage beantwortet werden, was ein Surrogatschlüssel ist. Dazu
folgende Definition:
“A surrogate key is an artificial or synthetic key that is used as a substitute for a
natural key.“ 27
Ein Surrogatschlüssel ist jedoch nicht nur ein Ersatz für den aus dem operativen
System stammenden natürlichen Primarschlüssel, sondern innerhalb eines Data
Warehouse dringend erforderlich, um komplexe Abfragen handhabbar zu gestalten
und letztendlich auch, um eine gute Performance sicherstellen zu können.
In megaWWS besitzt zum Beispiel die Tabelle für Auftragspositionen einen
zusammengesetzen Primarschlüssel aus den Attributen bel_art, auftnr und posnr
wie Tabelle 10 zeigt.
bel_art
char(3)
auftnr
char(9)
posnr
char(3)
artnr
char(16)
bez1
char(60)
Tabelle 10: auftpos aus megaWWS
Die Struktur eines Data Warehouse wird in Form eines Star- oder SnowflakeSchema 28 beschrieben und besteht in seiner Summe aus Join-Anweisungen von
Dimensionstabellen und einer oder mehreren Faktentabellen. Je größer der
verwendete Primärschlüssel bei einer solchen Anweisung ist, umso ineffizienter
wird die Ausführung. Die Größe des Primärschlüssels kann dabei entweder durch
den Datentyp des als Primärschlüssel verwendeten Attributes beeinflusst werden
oder durch einen zusammengesetzten Schlüssel. Im hier dargestellten Beispiel
beansprucht der Primärschlüssel einen Speicherbereich von 15 Byte und besteht
aus drei Attributen. Dieses kann für die Abbildung von Geschäftslogiken im
operativen System durchaus als praktikabel gelten, ist jedoch in einem Data
Warehouse mit der Zielsetzung von komplexen und zugleich performanten
Abfragen nicht vereinbar.
Aufgrund dieser Problematik sind Surrogatschlüssel in einem Data Warehouse
notwendig.
Die einfachste und praktikabelste Integration von Surrogatschlüsseln kann über die
Erweiterung der entsprechenden Tabellen um ein zusätzliches Integer-Attribut
erfolgen. Dieses dient dann im Data Warehouse als Primärschlüssel und benötigt
lediglich 4 Byte an Speicherplatz. Dieses kann dann beginnend bei eins für jeden
neuen Datensatz um eins hochgezählt werden. Durch diese sehr einfache
Funktionalität wird erreicht, dass die Join-Anweisung nicht mehr über einen
zusammengesetzten Primärschlüssel mit einer Größe von 15 Byte, sondern lediglich
27
28
(Kimball, 1998)
(Claßen, 2008 S. 16)
46 3.4 Konstruktion und Laden des Data Warehouse
noch über ein Attribut mit der Größe von 4 Byte erfolgen muss. Somit wird die
Abfrage nicht nur schneller, sondern es wird zusätzlich fast dreiviertel des zuvor
benötigten Arbeitsspeicher eingespart.
Eine weitere Verfeinerung dieses Konzeptes könnte dadurch erfolgen, dass bei
Tabellen mit voraussichtlich nur wenigen Datensätzen anstelle eines
Integer-Surrogatschlüssles ein nur 2 Byte belegender Smallint als
Surrogatschlüssel verwendet wird.
Bereits in Kapitel 3.4.1 wurde beschrieben, dass die zu ladenden
Dimensionstabellen mit Hilfe eines OleDB Ziel-Tasks durch die Manipulation der
erzeugten Anweisung erstellt wurden. Abbildung 3-20 auf Seite 35zeigt die
SQL-Anweisung zur Erstellung der Unternehmensdimension. Darin wurde ein neues
Attribut unternehmens_key vom Typ Integer definiert. Dieses wurde zusätzlich
als IDENTITY(1, 1)NOT NULL definiert. Diese Definition weist die Datenbank
an, beim Einfügen eines Datensatzes in die Tabelle, diesem, im Vergleich zu dem
vorherigen Datensatz einen um eins erhöhten Wert für dieses Attribut zuzuweisen.
Das Attribut wird somit durch den SQL-Server selbstständig verwaltet und kann im
Data Warehouse als neuer Primärschlüssel verwendet werden.
3.4.2 Laden der Fakten
Im Gegensatz zu den nötigen Verarbeitungsschritten im Rahmen der
Transformationsschicht für die Erstellung der Dimensionstabellen sind für die
Erstellung der Faktentabellen keine Transformationen nötig.
Das selektierte und bereits bereinigte Datenmaterial besteht zu diesem Zeitpunkt
lediglich noch aus auszuwertendem Zahlenmaterial und Schlüsselattributen aus den
operativen Systemen, anhand derer eine Verknüpfung zu bestehenden
Dimensionen erstellt werden muss.
Die Faktentabellen bilden den Mittelpunkt des durch ein Star- oder
Snowflake-Schema beschriebenen Data Warehouse. Da im Rahmen des
Ladevorgangs der Dimensionen für diese neue Primärschlüssel in Form von
Surrogatschlüsseln definiert wurden, lässt sich der wesentliche Bestandteil des
Ladevorgangs von Faktentabellen wie folgt beschreiben:
„Grab each production dimension key in the fact table record and replace it with the
correct current surrogate key.“ 29
Um die ursprünglichen Schlüssel innerhalb der Fakten durch die neuen
Surrogatschlüssel der Dimensionen ersetzen zu können, ist es zwingend
erforderlich, dass die Fakten erst geladen werden, nachdem die Dimensionen
29
(Kimball, 1998)
3 Data Preparation 47
verarbeitet wurden.
Diese Funktionalität lässt sich manuell über sehr komplexe SQL-Anweisungen
ausführen oder über so genannte „Suche“-Tasks, die das BI-Studio anbietet.
3.4.2.1 Lookup-Transformation
Die deutsche Übersetzung „Suche“ des eigentlichen Lookup-Tasks im BI-Studio ist
irreführend, weil sie von der eigentlichen Funktionalität des Tasks ablenkt. Er bietet
die vor allem während des Ladeprozesses von Fakten benötigte Funktion, aus einer
verknüpften Tabelle den passenden Datensatz zu identifizieren und ein Attribut aus
dieser Tabelle in den Datenfluss zu integrieren.
Innerhalb der Konfiguration des Tasks müssen zunächst die Datenbank und
anschließend die Tabelle angegeben werden, in der sich der gesuchte Ausdruck
befinden. Am Beispiel in Abbildung 3-25 ist dieses die bereits bekannte Dimension
dimUnternehmen.
Abbildung 3-25: Verweistabelle für die Suche nach Surrogatschlüsseln
Auf dem zweiten Reiter „Spalten“ wird die Verknüpfung der bisher im Datenfluss
verfügbaren Attribute mit der Dimensionstabelle definiert. Die Verknüpfung erfolgt
in der Regel über den Geschäftsschlüssel der Dimension. Ist die Verknüpfung
48 3.4 Konstruktion und Laden des Data Warehouse
definiert, können die Dimensionsattribute ausgewählt werden, die an den
Datenfluss zurückgegeben werden sollen. Für den Ladeprozess der Fakten wird hier
lediglich der Surrogatschlüssel der Dimension benötigt. Für die gewählten
Dimensionsattribute kann zusätzlich ein Ausgabealias vergeben werden. Die
Verknüpfung der Dimension anhand des Attributes kundennr und die Rückgabe
des Surrogatschlüssels zeigt Abbildung 3-26.
Abbildung 3-26: Verknüpfung und Suchspalte für die Suche nach Surrogatschlüsseln
Abhängig von der Anzahl der zu verknüpfenden Dimensionstabellen sind
entsprechend viele Suche-Tasks nötig, um die Geschäftsschlüssel durch die
Surrogatschlüssel zu ersetzen.
Wichtig für eine möglichst schnelle Verarbeitung aller Fakten ist, dass die
Verarbeitungsschritte parallel ausgeführt werden. Dies bedeutet, dass nicht erst alle
Datensätze in Suche1 verarbeitet werden und dann in Suche2, sondern dass wenn
ein Datensatz Suche1 durchlaufen hat, er zur Suche2 weitergeleitet wird, während
der folgende Datensatz in Suche1 verarbeitet wird.
Diese Verarbeitungslogik übernimmt das BI-Studio automatisch.
Des Weiteren ist ein wesentlicher Punkt für die Verarbeitungsgeschwindigkeit, ob
die Lookup-Tabellen, also die Dimensionstabellen, in denen nach dem passenden
3 Data Preparation 49
Surrogatschlüssel gesucht werden soll, im Arbeitsspeicher der ausführenden
Maschine vorgehalten werden können, oder ob sie auf der Festplatte physisch
zwischengespeichert werden müssen. Liegt eine Lookup-Tabelle im Arbeitsspeicher,
so kann die Verarbeitung aufgrund seiner wesentlich höheren Geschwindigkeit
schneller ausgeführt werden als wenn die Tabelle auf der im Vergleich zum
Arbeitsspeicher langsameren Festplatte zwischengespeichert wird.
Die Auswahl, in welchem Speicher die Lookup-Tabelle bereitgestellt wird, lässt sich
auf dem Reiter „Erweitert“ des Suche-Tasks bestimmen, wie Abbildung 3-27 zeigt.
Abbildung 3-27: Erweiterte Manipulationen der Suche nach Surrogatschlüsseln
Im Standard sind in dieser Maske alle Felder deaktiviert, wodurch eine vollständige
Vorzwischenspeicherung erfolgt. Dabei werden alle Verweisdaten vor dem Beginn
der Verarbeitung in den Speicher geladen.
Diese Konfiguration hat zur Folge, dass alle Tasks zeitgleich die Lookup-Tabellen in
den Arbeitsspeicher der ausführenden Maschine schreiben und es dadurch zu
negative Auswirkungen auf das Laufzeitverhalten kommen kann, wenn der
Arbeitsspeicher der ausführenden Maschine nicht ausreichend ist.
Bei der Verwendung mehrerer Suche-Tasks und großen Dimensionstabellen
50 3.4 Konstruktion und Laden des Data Warehouse
empfiehlt es sich daher, an dieser Stelle Anpassungen im Hinblick auf die
performante Verarbeitung des Datenflusses anzustellen.
Durch das alleinige Aktivieren der Option „Arbeitsspeicherbeschränkung aktivieren“
wird verhindert, dass die Lookup Tabelle dieses Tasks in den Arbeitsspeicher
geschrieben wird. Dadurch wird der Arbeitsspeicher geschont, jedoch ein
Geschwindigkeitsverlust bei der Verarbeitung in Kauf genommen.
Durch das zusätzliche aktivieren der Option „Zwischenspeichern aktivieren“ kann im
Vorfeld manuell festgelegt werden, wie viel Speicherplatz für das
Zwischenspeichern bereitgestellt werden soll.
Mit der Aktivierung der Option „SQL-Anweisung ändern“ kann Einfluss auf die Daten
genommen werden, die zwischengespeichert werden sollen. Hier können einzelne
Attribute ausgewählt werden oder generelle Einschränkungen der Datenmenge
durch das Anfügen von Bedingungen vorgenommen werden. In Abbildung 3-27
wurde diese Option aktiviert, die SQL-Anweisung jedoch noch nicht manipuliert.
Mit dem Suche-Task stellt das BI-Studio eine sehr einfach zu konfigurierende,
zuverlässige und vor allem schnell auszuführende Methode zur Verfügung, die
Geschäftsschlüssel in einer Faktentabelle durch die entsprechenden
Surrogatschlüssel der Dimensionen zu ersetzen. Jedoch eignet sich die
Standardkonfiguration lediglich für den Fall, dass der gesuchte Geschäftsschlüssel in
der Dimensionstabelle nur genau einmal vorkommt. Dieses entspricht einer Slowly
Changing Dimension vom Typ 1.
Gerade in einem Data Warehouse wird jedoch sehr häufig die Funktionalität von
Slowly Changing Dimensions des Typen 2 genutzt. Wie bereits in Kapitel 3.4.1.1.2
beschrieben, lassen sich in diesem Fall Datensätze über den Geschäftsschlüssel
nicht mehr eindeutig identifizieren. Mit der Problematik, Fakten in den historisch
korrekten Kontext einzubetten befasst sich das folgende Kapitel 3.4.2.2
3.4.2.2 Lookup von Surrogatschlüsseln einer SCD vom Typ 2
Die Konfiguration und die Funktionsweise des Suche-Tasks zum ermitteln von
Surrogatschlüsseln aus einer Dimensionstabelle wurde bereits in dem vorherigen
Kapitel erläutert. Da in einer Slowly Changing Dimension vom Typ 2 ein
Geschäftsschlüssel aufgrund der historischen Abbildung von Datensätzen mehrfach
in der Dimensionstabelle vorhanden sein kann, lässt sich der Suche-Task in seiner
Standardkonfiguration hier nicht verwenden. Ist der gesuchte Schlüssel mehrfach in
der Dimensionstabelle vorhanden, wird durch den Suche-Task der Surrogatschlüssel
des ersten gefunden Datensatzes als Ergebnis zurückgegeben. Die Zuordnung von
Surrogatschlüsseln zu den Fakten würde demnach willkürlich durchgeführt und eine
sinnvolle Analyse auf Basis der Daten nicht mehr möglich.
3 Data Preparation 51
Um einen Fakt den zum Zeitpunkt seiner Erstellung gültigen Dimensionswert
zuordnen zu können, muss ein Abgleich seines Erstellungsdatums mit den
Gültigkeitsbereichen, für seinen Geschäftsschlüssel gefundenen
Dimensionsdatensätzen erfolgen. Gibt es nur einen Dimensionsdatensatz zu dem
Geschäftsschlüssel, muss der Beginn der Gültigkeit kleiner oder gleich dem
Erstellungsdatum des Faktes sein und das Ablaufdatum darf nicht gefüllt sein.
Wurden mehrere Dimensionsdatensätze zu dem Geschäftsschlüssel gefunden, muss
derjenige gefunden werden, dessen Beginndatum kleiner-gleich und dessen
Enddatum nicht definiert oder größer als das Erstellungsdatum des Faktes ist.
Um diese Logik in den Ladevorgang der Fakten zu implementieren bieten sich
verschiedenen Möglichkeiten an.
Die erste Möglichkeit bietet ein separater Task zur Ausführung einer SQLAnweisung. Die definierte SQL-Anweisung zur Ermittlung des passenden
Dimensionsdatensatzes wird dann für jeden Datensatz einzeln gegen die Datenbank
ausgeführt.
Dieser Ansatz ist leicht zu implementieren, benötigt jedoch sehr viel Zeit, da alle
Anfragen direkt an die Datenbank gestellt werden und im Vorfeld der Ausführung
keine Zwischenspeicherung erfolgt. Die Dauer der Ausführung des bei WESTFA
definierten Datenflusses zum Laden der Faktentabelle würde mit dieser Methode
hochgerechnet ca. drei Tage dauern.
Die zweite Möglichkeit besteht in der Nutzung eines Suche-Tasks, wie er bereits für
die Suche nach Surrogatschlüsseln in Slowly Changing Dimensions vom Typ 1
genutzt wird. Durch die manuelle Erweiterung der SQL-Anweisung unter dem Reiter
„Erweitert“ um die bereits beschriebene Logik zur Abfrage der Gültigkeit von
Dimensionsdatensätzen kann das gleiche Ergebnis wie mit der vorherigen
Lösungsmöglichkeit über die einfache SQL-Anweisung erreicht werden. Jedoch
besteht über den Suche-Task die Möglichkeit, den schnelleren Arbeitsspeicher der
ausführenden Maschine zu nutzen, da der Suche-Task Daten vor der Ausführung
dort ablegt. Dieses bringt gegenüber dem Task mit der einfachen SQL-Anweisung
einen Vorteil in der Verarbeitungsgeschwindigkeit, ist jedoch trotzdem zu langsam
für den produktiven Einsatz, da auch hier die meisten Anfragen des Suche-Tasks
nicht aus dem Arbeitsspeicher, sondern von der Datenbank beantwortet werden.
Die Zeitersparnis gegenüber dem Task mit der SQL-Anweisung liegt bei mehreren
Stunden.
Für die Suche nach dem zu einem Fakt passenden Surrogatschlüssel in einer Slowly
Changing Dimension vom Typ 2 wurde bei WESTFA ein INNER JOIN und eine
bedingte Teilung des Datenflusses genutzt. Das Vorgehen wird im Folgenden
anhand eines Beispiels mit der Kundendimension verdeutlicht.
Zunächst muss der Datenfluss nach dem Geschäftsschlüssel, in diesem Beispiel der
52 3.4 Konstruktion und Laden des Data Warehouse
Kundennummer, sortiert werden. Für die Sortierung wurde ein Sortieren-Task
verwendet. Anschließend wurde eine Zusammenführungsverknüpfung in den
Datenfluss integriert. Diese erhält als linke Eingabe die nach dem Geschäftsschlüssel
sortierten Datensätze. Eine zusätzliche Datenquelle selektiert den
Surrogatschlüssel, den Geschäftsschlüssel und die beiden Gültigkeitsdaten aller
Datensätze, sortiert nach dem Geschäftsschlüssel aus der Dimensionstabelle
dimUnternehmen. Diese bilden die rechte Eingabe der
Zusammenführungsverknüpfung. Innerhalb der Zusammenführungsverknüpfung
wurde die Verknüpfungsart „Innere Verknüpfung“ ausgewählt und eine
Verknüpfung der beiden Tabellen über den Geschäftsschlüssel nummer
vorgenommen. Außerdem wurden der Surrogatschlüssel und die Gültigkeitsdaten
der Dimensionstabelle als zusätzliche Ausgabespalten des Tasks definiert.
Die an den Verknüpfungstask übergebene Zeile eines Faktes zeigt Tabelle 11.
nummer
23091981
auftragsdatum
21.12.2008
Tabelle 11: Datensatz vor der Verknüpfung
Nach der Verknüpfung mit drei zur nummer gefundenen Dimensionsdatensätzen
der Unternehmensdimension existieren drei unterschiedliche Datensätze des
Faktes, wie Tabelle 12 zeigt.
nummer
23091981
23091981
23091981
auftragsdatum
21.12.2008
21.12.2008
21.12.2008
sorrogatekey
133
134
135
gueltig_von
01.01.2008
07.01.2008
10.08.2008
gueltig_bis
07.01.2008
10.08.2008
NULL
Tabelle 12: Datensätze nach der Verknüpfung
Im Anschluss an die Verknüpfung findet eine bedingte Teilung des Datenflusses
statt. Dieser Task prüft das Datum des Faktdatensatzes mit den Gültigkeitsdaten der
Dimensionsdatensätze. Nur der passende Datensatz wird an den weiteren Verlauf
des Datenflusses übergeben. Die Filterung des ‚richtigen‘ Datensatzes wird durch
die folgende Split-Bedingung erreicht:
auftragsdatum <= gueltig_von &&
(auftragsdatum < gueltig_bis || ISNULL(gueltig_bis))
Nach der Trennung existiert zu dem Faktdatensatz der Surrogatschlüssel des
historisch gültigen Dimensionsdatensatz (Tabelle 13).
nummer
23091981
auftagsdatum
21.12.2008
sorrogatekey
135
Tabelle 13: Datensatz nach der Trennung mit Surrogatschlüssel
3 Data Preparation 53
Abbildung 3-28 zeigt den gesamten Ablauf der beschriebenen Transformation.
Abbildung 3-28: Lookup des Surrogatschlüssels einer SCD Typ2
Die Realisierung dieser Transformation gestaltet sich im Gegensatz zu den beiden
vorher beschriebenen Möglichkeiten etwas aufwendiger. Dafür konnte die Laufzeit
des Ladeprozesses dieser Faktentabelle auf ca. fünf Minuten reduziert werden.
Den gesamten Ladeprozess der Faktentabelle für eine Darstellung von Umsätzen,
Absätzen, Aufträgen und Angeboten aus megaWWS zeigt die folgende Abbildung
3-29.
Die Fakten werden über zwei getrennte SQL-Anweisungen auf Positionsebene
ermittelt, konvertiert und zusammengeführt. Nachdem Aufträge und Rechnungen
von Testkunden gefiltert wurden werden zunächst die Surrogatschlüssel aus Slowly
Changing Dimensions des Typs 1, dann die aus Typ 2 ermittelt. Anschließend
werden die Daten in die Faktentabelle geschrieben. Für die Lookup-Tasks wurde
zusätzlich eine Fehlerbehandlung implementiert. Datensätze für die kein
Surrogatschlüssel gefunden wurde werden in eine separate Tabelle geschrieben.
Abbildung 3-29: Ladeprozess einer Faktentabelle
54 3.4 Konstruktion und Laden des Data Warehouse
3.4.3 Fremdschlüsselbeziehungen im Data Warehouse
Nachdem Dimensions- und Faktentabellen vollständig verarbeitet sind, lässt sich die
während des gesamten ETL-Prozesses erstellte, multidimensionale Struktur, auch
physisch in der Datenbank, dem Data Warehouse, hinterlegen. Die geleisteten
Vorarbeiten, vor allem aber das Einführen von Surrogatschlüsseln, erlauben es nun,
mit dem „Microsoft SQL Server Management Studio“, die Dimensionstabellen über
Fremdschlüsselbeziehungen mit den Faktentabellen zu verbinden.
Für die Abbildung des Data Warehouse bei WESTFA wurde mit Hilfe des „Microsoft
SQL Server Management Studio“ ein Datenbankdiagramm erzeugt, das die Tabellen
und Beziehungen der Tabellen untereinander visualisiert. Über diese grafische
Oberfläche ließen sich zunächst die Surrogatschlüssel in den Dimensionen als
Primärschlüssel definieren. Dieses ist notwendig, da sich Fremdschlüssel aus einer
Tabelle, im Data Warehouse in der Regel die Faktentabelle, immer auf den
Primärschlüssel einer zu verbindenden Tabelle, hier die Dimensionen, beziehen
müssen. Nachdem die Primärschlüssel definiert waren, konnten die Beziehungen
durch einfaches Ziehen von Verbindungslinien innerhalb des Datenbankdiagramms
erstellt werden. Abbildung 3-30 zeigt einen Ausschnitt des bei WESTFA erstellten
Datenbankdiagramms mit den definierten Primärschlüssen in den
Dimensionstabellen und den Beziehungen der Faktentabelle zu diesen.
Abbildung 3-30: Detailausschnitt des Data Warehouse westfaDW von WESTFA
3 Data Preparation 55
Durch die Definition der Fremdschlüssel der Faktentabelle und den damit
verbundenen Beziehungen zu den Dimensionen wird sichergestellt, dass die
referentielle Integrität innerhalb des Data Warehouse gewahrt ist.
„Die referentielle Integrität (Englisch referential integrity) einer relationalen
Datenbank ist gewahrt, wenn für jeden ihrer Fremdschlüssel gilt:
! Alle Attributwerte des Fremdschlüssels sind ungleich NULL, oder alle
Attributwerde des Fremdschlüsselns sind gleich NULL.[…]
! Für einen [..] Fremdschlüssel muss in der durch den Fremdschlüssel
referenzierten Relation ein Tupel existieren, dessen Primärschlüssel identisch mit
dem Fremdschlüssel ist.“ 30
Die folgende Abbildung 3-31 zeigt eine strukturelle Komplettübersicht des erstellten
Data Warehouse. Deutlich zu erkennen ist die sich herauskristallisierende und
namensgebende Schneeflocke des Snowflage-Schema.
Abbildung 3-31: Aufbau des Data Warehouse "westfaDW" bei WESTFA
30
(Warner, 2007 S. 105)
56 3.5 Automatisierung der Aktualisierung des Data Warehouse
3.5 Automatisierung der Aktualisierung des Data Warehouse
Ähnlich wie auch bei der Erstellung der Persistant Staging Area in Kapitel 3.2
wurden die gesamten Verarbeitungen zur Erstellung und Versorgung des nun
existierenden Data Warehouse in einzelnen SSIS-Paketen eines Integration Services
Projekt abgelegt. Analog zu der bereits in Kapitel 3.2.5 beschriebenen
Vorgehensweise wurde auch hier für jedes SSIS-Paket ein Aufruf zur Ausführung
innerhalb einer Batch-Datei angegeben. Diese wird ebenfalls über einen definierten
Task jede Nacht ausgeführt und startet somit den ETL-Prozess.
Durch die in diesem Kapitel beschriebenen Verarbeitungen wurde bei WESTFA ein
Data Warehouse implementiert, das tagesaktuelle, dispositive Daten vorhält. Dieses
kann, wie auch bereits die erstellte Persistant Staging Area, durch
Abfragewerkzeuge bereits zur Geschäftsanalyse genutzt werden. Im Gegensatz zur
Persistant Staging Area bietet das Data Warehouse jedoch betriebswirtschaftlich
aufbereitete und intuitiv verständliche Daten, die aufgrund ihrer
multidimensionalen Struktur komplexere Anfragen in kürzerer Zeit beantworten
können.
4 Modeling 57
4 Modeling
Die Phase des Modeling beschreibt die vierte Prozessphase des CRISP-Prozesses. In
dieser werden Data Mining Strukturen entwickelt und auf ihre Verwendbarkeit hin
getestet. Diese Modelle werden jedoch nur benötigt, wenn das Ziel tatsächlich
„Data Mining“ ist. Im Rahmen der Implementierung eines BI-Gesamtansatzes bei
WESTFA war das Ziel die Entwicklung eines auf OLAP basierenden Analysesystems.
Demnach wurden im Rahmen der durchzuführenden Implementierung bei WESTFA
in dieser Phase keine Mining-Strukturen entwickelt, sondern ein OLAP Cube.
Die mit dem SQL Server gelieferte Entwicklungssoftware, das SQL Server Business
Intelligence Development Studio, bietet eine eigene Entwicklungsumgebung für die
Erstellung von multidimensionalen Datenstrukturen, deren Aufbereitung,
Verarbeitung, physische Speicherung und schließlich auch für die Analyse des
Datenmaterials. Unter diesen Service, der bei Microsoft „Analysis Services“ oder
auch „SQL Server Analysis Services“ (SSAS) heißt fallen auch die
Entwicklungsumgebungen für das Data Mining, die jedoch nicht Bestandteil dieser
Arbeit sind.
Zunächst wurde im SQL Server Business Intelligence Development Studio ein neues
Analysis Services-Projekt erstellt. Dort musste als erstes eine neue Datenquelle
angelegt werden. Jede Datenbank, die innerhalb dieses Projektes als Quelle für zu
verarbeitende Daten genutzt werden soll, muss hier mit den entsprechenden
Verbindungsparametern wie Server- und Datenbankname, Benutzername und
Kennwort angelegt sein.
Mit der Anlage des Data Warehouse wurde eine integrierte Datenbasis als
Ausgangspunkt für die Erstellung eines Analysesystems geschaffen. Diese soll dem
Analysis Services-Projekt einzig als Datenquelle dienen und wurde
dementsprechend als neue Datenquelle definiert.
58 4.1 Definition einer Datenquellensicht
4.1 Definition einer Datenquellensicht
Die Definition mindestens einer Datenquellensicht ist erforderlich, um im weiteren
Verlauf eine multidimensionale Datenbank in Form eines Cubes erstellen zu
können. Die Datenquellensicht beschreibt ein logisches Datenmodell basierend auf
verknüpften „[…] Tabellen, Sichten und Abfragen aus einer oder mehreren
Datenquellen [.]“ 31.Die Datenquellensicht ruft die Metadaten aller definierten
Tabellen und deren Beziehungen aus den Quellsystemen ab und speichert diese.
Sofern in den Quellsystemen bereits Primärschlüssel oder
Fremdschlüsselbeziehungen definiert wurden, werden diese durch die
Datenquellensicht ebenfalls automatisch erkannt und übernommen.
Die Verwendungsmöglichkeit von mehreren unterschiedlichen Datenquellen erlaubt
es, heterogene Datenquellen in einem homogenen Datenmodell darzustellen.
Durch die Zwischenspeicherung der Metadaten aller in einer Datenquellensicht
verwendeten Objekte wird eine Bearbeitung des Analysis Services-Projekt
ermöglicht, auch wenn keine aktive Verbindung zu den definierten Quellsystemen
besteht. Außerdem erlaubt die von den Quellsystemen unabhängige Speicherung
der Datenquellensicht die Erweiterung und Änderung von darin definierten
Objekten, ohne dass sich diese auf die Quellsysteme auswirken.
Da bei WESTFA in Vorfeld bereits ein separates Data Warehouse erstellt wurde,
bildet dieses für das Analysis Services-Projekt die Datenbasis. Über die bereits
definierte Datenquelle als Verbindung zur Datenbank „westfaDW“ wurden die
erstellten Tabellen für die Verwendung innerhalb der Datenquellensicht
ausgewählt. Da die Definition von Primärschlüsseln und Fremdschlüsselattributen
bereits im Data Warehouse erfolgt ist, wurden diese Informationen ebenfalls
automatisch in die Datenquellensicht übernommen. In diesem Fall spiegelt die
Datenquellensicht das bereits aus Kapitel 3.4.3 bekannte Datenbankdiagramm
wieder. Einen Ausschnitt der Datenquellensicht zeigt Abbildung 4-1 auf der
folgenden Seite.
31
(Corporation, 2008 S. Verwenden von Datenquellensichten)
4 Modeling 59
Abbildung 4-1: Ausschnitt der Datenquellensicht des Data Warehouse "westfaDW"
4.2 Erstellen eines Cubes
Basierend auf der definierten Datenquellensicht können nun ein oder auch mehrere
Cubes erstellt werden. Für die Erstellung und Bearbeitung von Cubes bietet das SQL
Server Business Intelligence Development Studio einen in die
Entwicklungsumgebung eingebetteten Cube-Designer. Dieser stellt alle benötigten
Werkzeuge für die Erstellung von Dimensionen, Fakten, berechneten Werten,
Unternehmenskennzahlen, etc. bereit.
Wie folgende Definition zeigt, bilden Dimensionen und Fakten, im Folgenden
Measures genannt, die wichtigsten Bestandteile eines Cubes.
„Eine multidimensionale Datenmenge wird von zwei Faktoren bestimmt:
! Die Dimensionen […]
! Die Measures […]“ 32
Die folgenden Kapitel zeigen, wie ein Cube, basierend auf dem in den bisherigen
Kapiteln erstellten Data Warehouse, bei WESTFA definiert und in einer Datenbank
bereitgestellt wurde.
32
(Schrödl, 2006 S. 25)
60 4.2 Erstellen eines Cubes
4.2.1 Cube-Assistent
Durch den Cube-Assistenten werden Schritt für Schritt alle nötigen Informationen
zur Erstellung von Dimensionen, Measures, Measuregruppen und, wenn gewollt,
auch zu einer Datenquellensicht. Die Ausführung des Cube-Assistenten und somit
die Erstellung eines neuen Cubes setzt nicht voraus, dass eine entsprechende
Datenquellensicht bereits vorhanden ist. Diese Option kann auf der ersten Seite des
Cube-Assistenten gewählt werden, wie Abbildung 4-2 zeigt.
Abbildung 4-2: Cube-Assistent - Verwendung einer Datenquellensicht
Soll ein Cube ohne die Verwendung einer Datenquelle erstellt werden, werden im
weiteren Verlauf des Cube-Assistenten lediglich die multidimensionalen Objekte
erstellt und mit Fertigstellung des Cubes zusätzlich die für den erstellten Cube
benötigte Datenquellensicht erzeugt.
Diese Vorgehensweise lässt sich mit dem Top-Down Prinzip vergleichen. Zunächst
wird das erwartete Ergebnis, in diesem Fall der Cube, erstellt, danach muss die
untere Ebene, hier die Datenquelle, die entsprechenden Anforderungen zur
Erfüllung des Gesamtergebnisses entsprechend angepasst werden.
Umgekehrt, so wurde es auch bei WESTFA implementiert, entspricht das Vorgehen
dem Bottom-Up Prinzip. Die Implementierung beginnt auf der untersten Ebene, also
dem Data Warehouse, worauf dann der Cube als Endergebnis aufbaut.
Dementsprechend wurde bei WESTFA die Erstellung eines Cubes mithilfe einer
Datenquelle verwendet. Die Option zur automatischen Erstellung von Attributen
und Hierarchien wurde bewusst nicht gewählt, da diese zu einem späteren
Zeitpunkt manuell definiert werden sollen.
4 Modeling 61
Im zweiten Schritt musste dann die für den Cube zu verwendende
Datenquellensicht gewählt werden. Da im Vorfeld nur eine Datenquellensicht
definiert wurde, bildet diese die Grundlage für die weiteren Erstellungsschritte im
Cube-Assistenten. Zunächst wurden die aus der Datenquellensicht verfügbaren
Tabellen in Fakt- und Dimensionstabellen unterschieden. Während bei WESTFA die
Abgrenzung von Fakt- und Dimensionstabellen bereits im Data Warehouse klar
vollzogen wurde, lassen sich Tabellen jedoch auch als Fakt und Dimension
gleichzeitig verwenden. Eine solche Verwendung von Tabellen muss an dieser Stelle
ebenfalls angegeben werden.
Eine besondere Rolle innerhalb jeder multidimensionalen Struktur kommt der
Zeitdimension zu. In jedem Analysesystem lässt sich eine Dimension zur zeitlichen
Einordnung von Fakten finden, da der Zeitdimension auch im Cube-Assistenten eine
besondere Rolle zukommt. Zunächst musste jedoch die als Zeitdimension zu
verwendende Tabelle angegeben werden. Bei WESTFA ist dieses die Tabelle
dimZeit (Abbildung 4-3).
Abbildung 4-3: Unterteilung der Tabellen aus der Datenquellensucht in Fakten und Dimensionen
Wurde eine Tabelle für die Verwendung als Zeitdimension angegeben, wird diese im
nächsten Schritt des Assistenten konfiguriert. Dabei werden die Attribute der
angegebenen Zeitdimensionstabelle den durch die Analysis Services entsprechend
vordefinierten Zeitattributen zugeordnet. Einen Ausschnitt aus der
vorgenommenen Zuordnung für die bei WESTFA verwendete Dimensionstabelle
zeigt Abbildung 4-4 auf Seite 62.
62 4.2 Erstellen eines Cubes
Anhand dieser Zuordnungen erstellt der Assistent unabhängig davon, ob zu Beginn
die automatische Erstellung von Hierarchien aktiviert wurde oder nicht, eine
Hierarchie für die Zeitdimension.
Zusätzlich erlaubt die Definition einer Zeitdimension die Verwendung von
bestimmten, speziell auf den vorgegebenen Zeitattributen anzuwendende
Funktionen. Die Verwendung dieser Funktionen wird in Kapitel 4.2.3.1 im Rahmen
von berechneten Werten näher erläutert.
Abbildung 4-4: Zuordnung von Zeittabellenspalten der Zeitdimension
Im nächten Dialogschritt werden die durch den Cube-Assistenten aus den
angegebenen Faktentabellen identifizierten Measures und die zugehörige
Measuregruppe angezeigt. Die Gruppierung der Measures zu einer Measuregruppe
erfolgt dabei nach den Faktentabellen.
Hier können nichtbenötigte Measures, oder ganze Measuregruppen, deaktiviert
werden, wodurch diese nicht in den Cube übernommen werden. Die Deaktivierung
von Measures wurde bei WESTFA erforderlich, da der Cube-Assistent alle Attribute
der Faktentabelle als Measures behandelt, die nicht als Fremdschlüssel verwendet
werden. Wie Abbildung 4-5 aus Seite 63 zeigt, wurden der in der Datenbank
künstlich angelegte Primärschlüssel der Faktentabelle UmsatzAbsatzTec und drei
weitere Attribute, für die eine Verwendung als Fremdschlüsselattribut geplant, aber
noch nicht implementiert wurde, aus der Verwendung als Measures
herausgenommen. Zusätzlich können die Measures und die Measuregruppen an
dieser Stelle umbenannt werden.
Durch den Cube-Assistenten wird je Measuregruppe zusätzlich ein neues, nicht in
der Faktentabelle vorhandenes Measure erzeugt. Das vorgeschlagene Measure
beschreibt die Anzahl von Datensätzen einer Measuregruppe. Auch wenn dieses
Measure nicht immer eine direkte Aussagekraft im Rahmen einer angestrebten
Analyse hat, kann es trotzdem für später anzustellende Berechnungen sehr hilfreich
sein.
4 Modeling 63
Abbildung 4-5: Auswahl und Benennung von Measures und Measuregruppen
Nach den Measures werden im nächsten Schritt die Dimensionen konfiguriert.
Aufgelistet werden durch den Cube-Assistenten wie in Abbildung 4-6 gezeigt alle als
Dimensionstabelle gekennzeichneten Tabellen. Analog zu den Measures kann hier
ausgewählt werden, welche Dimensionen und zugehörigen Dimensionsattribute
Bestandteile des Cubes werden sollen. Allerdings müssen die
Primärschlüsselattribute einer Dimension übernommen werden, wenn die jeweilige
Dimension in den Cube integriert werden soll. Auch das Umbenennen der
Dimensionsattribute und der Dimensionen selbst ist hier wieder möglich.
Wurde zu Beginn des Cube-Assistenten die automatische Erstellung von Hierarchien
ausgewählt, würde der Cube-Assistent an dieser Stelle neben der Gruppierung
„Attribute“ zusätzlich die Gruppierung „Hierarchien“ anzeigen. In dieser werden
durch den Cube-Assistenten automatisch erstellte Hierarchien angezeigt, die
anhand der gegebenen Metadaten der Dimensionsattribute erkannt wurden. Da die
automatisierte Erstellung von Hierarchien jedoch oftmals zu ungewollten
Ergebnissen in Form von nicht schlüssigen oder unvollständigen Hierarchien führte,
wurde diese Option, wie bereits zu Beginn beschrieben, für die Erstellung eines
Cubes bei WESTFA deaktiviert. Als Folge müssen die gewünschten Hierarchien nach
Abschluss des Assistenten manuell für jede Dimension definiert werden (siehe
Kapitel 4.2.2.1).
64 4.2 Erstellen eines Cubes
Abbildung 4-6: Bestimmung der Dimensionsstrukturen
Mit dem Abschluss der Dimensionskonfiguration hat der Cube-Assistent alle
benötigten Informationen zur Erstellung eines neuen Cubes erhalten.
Nach Beendigung des Assistenten erstellt dieser den Cube und bildet die definierte
multidimensionale Struktur innerhalb der Entwicklungsumgebung im BI-Studio ab.
Abbildung 4-7 zeigt die gesamte Entwicklungsumgebung der Analysis Services zur
Bearbeitung eines Cubes im BI-Studio.
In der Mitte der Entwicklungsumgebung wird die dem Cube zugrundeliegende
Datenquellensicht mit den einzelnen Tabellen und deren Beziehungen zueinander
dargestellt. Die im Cube-Assistenten vorgenommene Unterteilung der Tabellen in
Fakten und Dimensionen wird durch farbliche Hervorhebungen kenntlich gemacht.
Am linken Rand werden die definierten Measuregruppen und Dimensionen
zusätzlich aufgelistet, so dass die Cubestruktur sehr übersichtlich dargestellt wird.
Der Projektmappenexplorer, dargestellt am rechten Bildschirmrand, erlaubt einen
Überblick über das gesamte Analysis Services-Projekt.
Die definierte, multidimensionale Struktur innerhalb des Cubedesigners beschreibt
zu diesem Zeitpunkt einen Cube, der jedoch physisch noch nicht vorhanden ist. Erst
durch die Verarbeitung der Cubestruktur wird der Cube physisch erstellt und steht
nach der durchzuführenden Bereitstellung auch für Anfragen von Clients zur
Verfügung. Diese Vorgänge werden in Kapitel 4.3 beschrieben.
4 Modeling 65
Die erstellte Cubestruktur kann innerhalb des Cubedesigners auf den am oberen
Rand dargestellten Registrierkarten noch detaillierter bearbeitet werden.
Abbildung 4-7: Mit dem Cube-Assistenten definierter Cube in der Entwicklungsumgebung
Die folgenden Kapitel zeigen, wie die durch den Cube-Assistenten erstellte
Cubestruktur bei WESTFA erweitert wurde.
4.2.2 Dimensionen
Die Erstellung der Dimensionen und die Auswahl von benötigten
Dimensionsattributen wurden bereits mithilfe des Cube-Assistenten vorgenommen.
Aufgrund dessen, dass die automatische Erstellung von Dimensionshierarchien im
Cube-Assistenten deaktiviert wurde, mussten die Hierarchien in den jeweiligen
Dimensionen manuell definiert werden.
Die Bearbeitung von Dimensionen erfolgt über den Dimensions-Designer. Dieser
bietet zunächst eine Auflistung der verfügbaren Dimensionsattribute und die
Darstellung der Datenstruktur einer Dimension in Form von den Tabellen und deren
Beziehungen zueinander, aus denen die Dimension besteht.
Neben der Möglichkeit, Hierarchien zu definieren können, Übersetzungen für die
einzelnen Dimensionsattribute angegeben werden, und die definierte Dimension
kann über die Registrierkarte „Browser“ betrachtet werden.
66 4.2 Erstellen eines Cubes
4.2.2.1 Hierarchien
Hierarchien bilden einen wesentlichen Bestandteil der Organisation von
Dimensionsattributen und deren Ausprägungen. Durch eine hierarchische
Darstellung von Daten einer Dimension ergibt sich die Möglichkeit, Measures auf
unterschiedlichen Verdichtungsstufen darzustellen. Die Navigation durch eine
Dimensionshierarchie wird „Drill-down“ genannt, wenn von einer aggregierten
Hierarchieebene auf die darunter liegende Ebene, mit einem höheren
Detailierungsgrad gewechselt wird. Die gegenteilige Operation, wenn von einer
Hierarchieebene auf die darüberliegende, stärker verdichtete Ebene gewechselt
wird, nennt man „Roll-up“.
Zur Erstellung einer neuen Hierarchie für die Unternehmensdimension bei WESTFA
wurde im Dimensions-Designer zunächst das Dimensionsattribut
Klassifikation, das die oberste Hierarchieebene bilden soll, in die Arbeitsfläche
für „Hierarchien und Ebenen“ gezogen. Dadurch wurde eine neue Hierarchie
erstellt, die bisher aus nur einer Ebene bestand. Die zweite Hierarchieebene wurde
aus dem Dimensionsattribut Nummer Name gebildet. Dieses wurde in die erstellte
Hierarchie gezogen und unter dem Klassifikation-Attribut angeordnet. Auf die
gleiche Weise wurde eine zweite Hierarchie mit den Ebenen Typ und Nummer
Name erstellt. Um eine Abhängigkeit zwischen den Hierarchieebenen herzustellen,
müssen Beziehungen zwischen den Attributen innerhalb einen Hierarchie
hergestellt werden. Diese wurden dadurch erstellt, dass dem in der Hierarchie
unterem Attribut sein übergeordnetes Attribut mitgeteilt wurde.
Durch „[…]die Definition von Beziehungen zwischen den Attributen kann die Leistung
gesteigert werden, da Analysis Services diese Beziehungen zum Definieren von
Aggregationen verwendet.“ 33
Den Dimensions-Designer und die beiden Hierarchien für die
Unternehmensdimension zeigt Abbildung 4-8 auf Seite 67.
33
(Corporation, 2008 S. Definieren und Konfigurieren einer benutzerdefinierten Hierarchie)
4 Modeling 67
Abbildung 4-8: Dimensions-Designer mit zwei Hierarchien
Nach diesem Vorgehen wurden Hierarchien in den jeweiligen Dimensionen erstellt.
Die Erstellung von Hierarchien entspricht der Aggregationsschicht innerhalb der
Transformationsphase eines ETL-Prozesses, die ursprünglich für die Aggregation von
Daten auf verschiedenen Verdichtungsstufen vorgesehen ist.
4.2.3 Measures
Den Mittelpunkt einer multidimensionalen Datenstruktur, wie sie auch dem bei
WESTFA erstellten Cube zugrunde liegt, bilden die Faktentabellen mit ihrem
auswertbaren Zahlenmaterial.
Die einzelnen Measures einer Faktentabelle werden im Cubedesigner
zusammengefasst und in einer Measuregruppe dargestellt. Diese bilden die
Grundlage an auszuwertendem Zahlenmaterial innerhalb einer Cubestruktur und
können bereits für Analysen genutzt werden.
68 4.2 Erstellen eines Cubes
4.2.3.1 Berechnete Werte
Eine Erweiterung der vorhandenen Measures und damit des für Analysen
verfügbaren Zahlenmaterials bilden die so genannten „berechnete Werte“. Sie
lassen sich über die Registrierkarte „Berechnungen“ im Cubedesigner erstellen und
bilden Berechnungen, basierend auf bereits vorhandenen Measures. Diese
berechneten Werte stehen dann innerhalb des Cubes als zusätzliche Measures für
Analysen zur Verfügung.
Für die Berechnung von neuen Measures ist es außerdem möglich, die Berechnung
in Abhängigkeit von Dimensionshierarchien zu definieren.
Ein in Analysen häufig angestellter Vergleich ist der eines aktuellen Wertes mit dem
des Vorjahres. Dieser Vergleichswert lässt sich basierend auf einem vorhandenen
Measure in Abhängigkeit zu einem Dimensionsattribut oder sogar einer
Dimensionshierarchie berechnen.
Abbildung 4-9 zeigt die Definition des berechneten Wertes „Positionswert Vorjahr“
in Abhängigkeit einer Hierarchie der Zeitdimension bei WESTFA. Dieser Wert gibt
den Vorjahreswert des in der Faktentabelle vorhandenen Measure „Positionswert“
in Abhängigkeit der gewählten Zeit-Hierarchieebene aus.
Die dafür genutzte, durch das BI-Studio bereitgestellte Funktion
PARALLELPERIODE kann nur auf Attribute angewandt werden, denen im Rahmen
der Bestimmung einer Zeitdimension eine Zeitfunktionalität zugeordnet wurde. In
der Verwendungsmöglichkeit dieser Funktionen begründet sich die explizite
Definition einer Zeitdimension innerhalb des Cube-Assistenten.
Abbildung 4-9: Definition eines berechneten Wertes in Abhängigkeit einer Hierarchie der Zeitdimension
4 Modeling 69
4.2.3.2 Kennzahlen (KPIs)
„Die Idee der KPIs ist, mittels bestimmter Kennzahlen eine quantifizierbare Größe für
einen bestimmten Unternehmensbereich zu ermitteln.“ 34 Häufiger Einsatzbereich
von KPIs ist die Darstellung von Trends, Abweichungen und Erreichungsgraden von
Measures. Unterstützt werden kann das gelieferte Zahlenmaterial zusätzlich durch
optische Signale, die den aktuellen Stand eines KPIs signalisieren. Die bekannteste
Form dieser Darstellungsart von betrieblichen Kennzahlen ist die „Ampelfunktion“.
Über die Registerkarte „KPIs“ können Key Performance Indicators definiert werden.
Durch die Angabe eines Wert- und eines Zielausdrucks, für deren Berechnung
unterschiedliche Funktionen angeboten werden, können Status- und
Trendberechnungen erfolgen. Neben der Ausgabe der einzelnen Berechnungen des
KPIs lassen sich die Ergebnisse in Form von verschiedenen, optischen Indikatoren
darstellen.
Die zusätzliche optische Darstellungsmöglichkeit von KPIs soll den Betrachter einer
Analyse in die Lage versetzen, in großen Datenmengen einen schnelleren Überblick
zu gewinnen.
Die Definition von KPIs ist bei WESTFA vorgesehen, jedoch zum jetzigen Zeitpunkt
der Implementierung noch nicht realisiert worden.
Die Beziehungen zwischen den Dimensionen und den Measuregruppen macht die
Dimensionsverwendungsmatrix deutlich (Abbildung 4-10 auf Seite 70). Anhand
dieser Matrix lässt sich erkennen, nach welchen Kriterien sich eine Measuregruppe
analysieren lässt.
Kann die Datenquellensicht die Beziehung zwischen einer Fakten- und einer
Dimensionstabelle nicht automatisch erkennen, muss die Beziehung der
Dimensionstabelle zu der Measuregruppe in der Dimensionsverwendung manuell
definiert werden. Dieses wird zum Beispiel nötig, wenn die
Fremdschlüsselbeziehungen zwischen den Tabellen innerhalb einer Datenquelle
nicht definiert wurden.
34
(Schrödl, 2006 S. 302)
70 4.3 Bereitstellung und Verarbeitung des Cubes
Abbildung 4-10: Dimensionsverwendungsmatrix des Cube-Designers
4.3 Bereitstellung und Verarbeitung des Cubes
Die bis zu diesem Zeitpunkt im Cube-Designer erstellte logische Struktur des Cubes
wurde bisher nur lokal gespeichert. Um den Cube für die anstehende Analyse
bereitzustellen muss die Cubestruktur zunächst auf den OLAP Server des Microsoft
SQL Servers, die Serverkomponente der Analysis Services, erstellt werden. Dazu
müssen in den Projekteigenschaften der Zielserver und die Zieldatenbank für den zu
erstellenden Cube angegeben werden.
Wurde die Cubestruktur auf dem Server erstellt, kann der Cube verarbeitet werden.
Im Rahmen der Verarbeitung des Cubes erfolgt zunächst ein Abgleich der lokalen
mit der auf dem Zielserver gespeicherten Cubestruktur. Bei Abweichungen wird vor
der eigentlichen Verarbeitung die aktuelle Cubestruktur auf den Server übertragen.
Danach wird mit der Verarbeitung begonnen.
Zur Speicherung von Cubes lassen sich die drei unterschiedliche Speichermodi
multidimensionales OLAP (MOLAP), Relationales OLAP (ROLAP) und Hybrides OLAP
(HOLAP) unterscheiden. Die Auswahl des zu verwendenden Speichermodus hat
unterschiedliche Auswirkungen vor allem auf die Größe eines Cubes und die
Geschwindigkeit, mit der Clientanfragen beantwortet werden können.
4 Modeling 71
4.3.1 MOLAP
Bei der Verwendung von multidimensionalem OLAP werden alle Quelldaten und
Aggregationen in einer multidimensionalen Struktur gespeichert. Diese redundante
Speicherung der Daten ermöglicht die maximale Geschwindigkeit bei der
Beantwortung von Clientanfragen, da alle nötigen Daten im Cube selbst vorhanden
sind. Der Cube kann dadurch ohne Zugriff auf die Quellsysteme alle Anfragen
beantworten.
Die schnellen Antwortzeiten dieses Speichermodus gehen jedoch aufgrund der
redundanten Datenspeicherung auf Kosten des Speicherplatzes. Außerdem muss
dafür gesorgt werden, dass, wenn sich die Quelldaten ändern, der Cube neu
verarbeitet wird, damit die Änderungen in den Cube integriert werden können.
4.3.2 ROLAP
Relationales OLAP speichert die Daten und die Aggregationen in einer relationalen
Datenbank. Auf dem OLAP Server wird lediglich die Cubestruktur hinterlegt, alle
Anfragen werden jedoch von der relationalen Datenbank beantwortet.
Durch die Speicherung aller Daten des Cubes in relationaler Form ist die ROLAP
Speichermethode den Speicherplatz betreffend die effektivste, jedoch bei der
Beantwortungszeit von Anfragen die langsamste der drei Methoden.
4.3.3 HOLAP
HOLAP bildet eine Kombination aus den beiden Speichermodi MOLAP und ROLAP.
Dabei werden die Aggregationen in einer multidimensionalen Struktur gespeichert.
Die Detaildaten werden wie beim ROLAP in einer relationalen Datenbank
gespeichert. Bei Anfragen auf aggregierte Daten kann HOLAP genau so schnell
antworten wie MOLAP, braucht jedoch weniger Speicherplatz. Bei Anfragen über
Detaildaten antwortet HOLAP langsamer als MOLAP, jedoch immer noch schneller
als ROLAP.
Der zu verwendende Speichermodus für einen Cube kann für jede Partition, eine
Partition entspricht einer Faktentabelle mit allen verbundenen Dimensionstabellen,
separat eingestellt werden. Diese separate Auswahlmöglichkeit erlaubt eine
zielgerichtete Konfiguration, den gestellten Anforderungen entsprechend.
Bei WESTFA wurde für alle Partitionen die MOLAP Speichermethode verwendet, da
häufig Anfragen bis auf die unterste Detailebene zu erwarten sind und durch
MOLAP die bestmögliche Antwortzeit gewährleistet wird.
Zusätzlich wurde für die im Vorfeld der Cubeerstellung zu ermittelnden
72 4.3 Bereitstellung und Verarbeitung des Cubes
Aggregationen, pro Partition ein Richtwert von 60% Leistungsgewinn eingestellt,
wie Abbildung 4-11 zeigt.
Abbildung 4-11: Bestimmung der Speichermethode MOLAP für eine Cubepartition
Abhängig von dem gewählten Speichermodus eins Cubes ist seine
Verarbeitungszeit. Wird wie bei WESTFA MOLAP verwendet, müssen alle Daten aus
den Quellsystemen in den Cube geladen werden. Wurde ROLAP als Speichermodus
gewählt, werden keine Daten, sondern nur die Cubestruktur auf den
Serverübertragen.
Ist der Verarbeitungsprozess erfolgreich beendet, kann direkt aus dem
Cube-Designer über die Registerkarte „Browser“ auf den Cube zugegriffen werden.
Aber auch der externe Zugriff über die Serverkomponente der Analysis Services auf
den Cube, sofern in den Sicherheitsrichtlinien erlaubt, kann nun erfolgen. Mögliche
Zugriffsmöglichkeiten bieten das SQL Server Management Studio oder MS Excel
2007.
Für eine regelmäßige und zeitgesteuerte Aktualisierung der Daten im Cube wurde
der im Rahmen der Data Preparation Phase erstellte ETL-Prozess um ein
zusätzliches Paket erweitert. Dieses Paket wird nach dem Ladevorgang des Data
Warehouse ausgeführt. Den Inhalt des Paketes stellt Abbildung 4-12 dar.
Zunächst wird ein Task ausgeführt, der die Verarbeitung des Cubes und somit die
Aktualisierung vornimmt. Nach der Verarbeitung des Cubes wird ein weiterer Task
ausgeführt, der das Logfile für die westfaDW Datenbank verkleinert. In diesem
Logfile werden alle ausgeführten Aktionen, betreffend die westfaDW Datenbank,
gespeichert. Während der Ausführung des ETL-Prozesses vergrößert sich dieses
Logfile um zusätzlich bis zu 20 Gigabyte. Um hier möglichen Problemen den
Speicherplatz betreffend vorzubeugen, wird das File nach jeder Ausführung des ETLProzesses auf eine Größe von zehn Megabyte reduziert.
Zum Abschluss der Paketausführung wird eine Erfolgsmail versendet.
Abbildung 4-12: automatisierte Verarbeitung des Cube
5 Evaluation 73
5 Evaluation
Mit dem Abschluss der Prozessphase des „Modeling“ wurde ein auf OLAP
basierendes Analysesystem in Form eines Cubes erstellt und für den externen
Zugriff bereitgestellt. Die fünfte Prozessphase des CRISP-Prozesses, die Evaluation,
sieht vor, das erstellte Ergebnis mit den zu Beginn des Projektes ermittelten
Anforderungen abzugleichen und auf die korrekte Funktionsweise hin zu
überprüfen.
5.1 Evaluation der Funktionen und Daten
Um das bei WESTFA durch den Cube bereitgestellte Analysesystem auf die Erfüllung
der geforderten Funktionalitäten zu überprüfen, wurde die während der
Informationsbedarfsanalyse erstellte Dimensionsmatrix 35 als Referenz betrachtet.
Die Dimensionsmatrix beschreibt die Anforderungen der interviewten Mitarbeiter
bei WESTFA sowohl in Bezug auf die auszuwertenden Zahlen als auch auf die
Möglichkeiten von deren Darstellung.
35
(Claßen, 2008 S. 50)
74 5.1 Evaluation der Funktionen und Daten
Abbildung 5-1: Aus den Anforderungen der Informationsbedarfsanalyse erstellte Dimensionsmatrix
Die bereits vorhandene Dimensionsmatrix wurde im Rahmen der Evaluation um
zusätzliche, nicht explizit geforderte Möglichkeiten der Analyse erweitert,
beziehungsweise bisher nicht implementierte Möglichkeiten wurden kenntlich
gemacht. Abbildung 5-2 zeigt auf der folgenden Seite die erweiterte
Dimensionsmatrix, die den aktuellen Stand der implementierten
Analysemöglichkeiten zeigt.
In Grau hervorgehoben sind die nicht implementierten und in Grün die nicht
geforderten Analysemöglichkeiten.
Der Grund dafür, dass die offenen Posten der Kunden nicht im erstellten Cube
verfügbar sind, ist, dass diese aus einem vierten Quellsystem hätten extrahiert
werden müssen. Die Konzentration während der Implementierung sollte aber laut
den Anforderungen des Vertriebs von WESTFA auf die Analyse der TEC und
Kolumbus-Daten gelegt werden.
5 Evaluation 75
Abbildung 5-2: Erweiterte Dimensionsmatrix
Um die Qualität der im Cube befindlichen Daten und somit die Qualität von
durchgeführten Analysen zu sichern, wurde auf Basis des Cubes eine Auswertung
über Umsätze, Absätze und den Auftragseingang des Geschäftsfelds WESTFATEC
erstellt. Diese Auswertung wurde einer bei WESTFA bestehenden und seit vielen
Jahren eingesetzten Analyse gegenübergestellt. Die gelieferten Werte wurden
verschiedenen Verdichtungsstufen und mit unterschiedlichen Filterkriterien
verglichen.
Der durchgeführte Vergleich lieferte für jede Stichprobe Werte, die bis auf den
Centbetrag identisch waren. Dieser Vergleich wurde zusätzlich über einen Zeitraum
von zwei Wochen täglich wiederholt, um die Gefahr einer zufälligen
Übereinstimmung vorzubeugen. Während dieser Testphase konnte zu keinem
Zeitpunkt eine Differenz zwischen den verglichenen Werten festgestellt werden.
Um die aus Kolumbus stammenden Vertriebsdaten wie die Anzahl von Besuchen,
die geplante Anzahl von Besuchen oder die Potenzialpunkte zu evaluieren, wurden
nach dem Stichprobenverfahren Analysen der einzelnen Werte durchgeführt und
diese direkt mit den Ist-Daten in Kolumbus abgeglichen. Auch hier konnten keine
Abweichungen festgestellt werden.
76 5.2 Evaluation Informationsbeschaffung
5.2 Evaluation Informationsbeschaffung
Die Evaluation des erstellten Analysesystems im Hinblick auf den funktionalen
Umfang und der Richtigkeit der Daten konnte aufgrund der positiven
Testergebnisse mit Erfolg abgeschlossen werden.
Ein zusätzliches Ziel des Business Intelligence Ansatzes bei WESTFA war es jedoch
auch, den Prozess der Beschaffung von analytischen Informationen für das
Management zu verbessern. Dabei sollte vor allem die Vertriebssteuerung durch
einen ersten Implementierungsansatz unterstützt werden.
In Abbildung 5-3 wird der aktuelle Prozess zur Informationsbeschaffung für eine
Vertriebssteuerung bei WESTFA grob dargestellt.
Abbildung 5-3: Aktueller Prozess zur Informationsbeschaffung für eine Vertriebssteuerung
Zunächst muss sich der Vertriebsleiter entscheiden, welche Daten er betrachten
möchte. Umsatz- und Absatzbetrachtungen für das Geschäftsfeld WESTFATEC
werden durch MS Excel in einer vordefinierten Pivot-Tabelle bereitgestellt.
Informationen über Besuchshäufigkeiten und deren Gründe werden durch
Kolumbus in Form von flachen Listen bereitgestellt.
In Kolumbus muss zusätzlich aus einer Liste von ca. 20 Auswertungen die für die
gesuchte Information richtige ausgewählt und geöffnet werden.
5 Evaluation 77
Durch die integrierte Datenbasis des Cubes ist dieser in der Lage, sowohl die
Vertriebsdaten aus Kolumbus als auch die Umsätze und Absätze aus dem
Geschäftsfeld WESTFATEC darzustellen. Dadurch konnte der Prozess der
Informationsbeschaffung vereinfacht, verbessert und vor allem für den Anwender
wesentlich schneller gemacht werden. Den sich daraus ergebenden neuen Prozess
zur Informationsbeschaffung der gleichen Informationen wie im ersten
Prozessbeispiel zeigt Abbildung 5-4
Abbildung 5-4: Durch das Analysesystem verbesserter Prozess zur Informationsbeschaffung
Rückwirkend betrachtet kann die Prozessphase der Data Preparation, also die der
Implementierung eines ETL-Prozesses, als die aufwändigste, die am meisten Zeit
beanspruchende, als Phase mit den meisten Iterationen des gesamten CRISPProzessverlaufs und damit der Implementierung eines BI-Gesamtansatzes bei
WESTFA, beschrieben werden.
In dieser Phase wurde die Basis für die resultierende „Business Intelligence“ gelegt.
Die Qualität des erstellten OLAP-Analysesystems ist abhängig von den durch das
Data Warehouse bereitgestellten Daten. Somit muss der Fokus, vor allem bei einer
so heterogenen Verteilung der Geschäftsdaten wie bei WESTFA, auf die Phase der
Data Preparation und somit auf die Extraktion, Transformation und die integrierte
Bereitstellung der Geschäftsdaten gelegt werden.
78 6.1 Analysen mit MS Excel 2007
6 Deployment
Mit der sechsten CRISP-Prozessphase, dem Deployment, erfolgt nach Definition des
CRISP-Prozesses die Auslieferung und damit der Übergang in den produktiven
Einsatz des im bisherigen Prozessverlauf implementierten Analysesystems.
Bei WESTFA wurde der abschließende Schritt, das bestehende Analysesystem in
Form des Cubes an die Adressaten in Form des Managements von WESTFA
auszuliefern, noch nicht vollzogen.
Zum aktuellen Zeitpunkt wurde der Zugriff auf den Cube lediglich ausgewählten
Anwendern mit entsprechenden Kenntnissen der Daten und im Umgang mit den
Analysis Services ermöglicht.
Für eine Auslieferung von vordefinierten Analysen und deren Einbindung in ein
Management-Cockpit gibt es jedoch verschiedene für WESTFA denkbare
Alternativen.
6.1 Analysen mit MS Excel 2007
Die am einfachsten zu implementierende Auslieferung könnte in Form von
vordefinierten Pivot-Tabellen in MS Excel 2007 erfolgen.
Excel 2007 bietet eine separate Schnittstelle zu den Analysis Services des SQL Server
an, um diese als Quelle für Analysen zu nutzen.
Geforderte Analysen könnten bei WESTFA durch im Umgang mit Excel erfahrene
Mitarbeiter erstellt und über eine Verzeichnisstruktur mit lesendem Zugriff an die
Adressaten verteilt werden.
Zusätzlich kann Excel 2007 als Werkzeug für Ad-hoc Abfragen genutzt werden.
Excel bietet den Anwendern ein bekanntes Arbeitsumfeld und ist intuitiv bedienbar.
Außerdem ist bei WESTFA bereits jeder Arbeitsplatz mit Excel ausgestattet, was eine
Verteilung von Analysen unproblematisch machen würde.
Nachteilig bei der Auslieferung von Analysen über Excel sind die mangelhafte
Vergabe von Benutzerrechten und der Zugriff auf einzelne Dateien über das
Filesystem. Diese Art der Bereitstellung von Unternehmensanalysen widerspräche
dem Gedanken einer zentralen Portallösung, die die Rechteverwaltung übernimmt
und einen Einstiegspunkt in die Unternehmensanalyse bieten soll.
Jedoch ist Excel sehr gut geeignet, um Ad-hoc Analysen durchzuführen. Aufgrund
der hervorragenden Integration der Microsoftprodukte ist es auch für unerfahrene
6 Deployment 79
Anwender in kurzer Zeit erlernbar, mit Excel Anfragen an das Analysesystem zu
stellen.
6.2 Separate Frontendwerkzeuge
Eine Alternative zu MS Excel bestünde in der Verwendung von
Frontendwerkzeugen, welche auf die Erstellung von komplexen Analysen und den
Umgang mit großen Datenmengen ausgelegt sind.
Viele der Anbieter von Frontendwerkzeugen unterstützen außerdem die Erstellung
von Portallösungen.
Für eine Auslieferung über eine separate Anwendung müsste jedoch eine
Produktauswahl getroffen, ein Produkt angeschafft und eingerichtet werden.
Außerdem müssten Mitarbeiter bei WESTFA in dem Umgang des neuen Produktes
geschult werden. Somit würde ein Zeitverlust und zusätzliche Kosten entstehen.
6.3 Reporting Services des SQL Servers
Der SQL Server bringt eine separate Serverkomponente zur Bereitstellung und eine
eigene Entwicklungsumgebung zur Erstellung von Auswertungen mit. Diese werden
unter dem Namen Reporting Services zusammengefasst.
Mit den Reporting Services lassen sich sowohl statische Listen als auch komplexe
Analysen erstellen und über den Report Server webbasierend bereitstellen.
Die Reporting Services bilden einen Mittelweg zwischen dem Spagat der starren und
schlecht verteilbaren Excel-Lösung und einer neu einzuführenden, separat zu
lizensierenden Portalanwendung. Daher besteht bei WESTFA die Absicht, Analysen
und Auswertungen mithilfe der Reporting Services zu entwickeln und in einem
ersten Schritt über den Reportserver des SQL Servers bereitzustellen.
In einem zweiten Schritt wird geplant, den SharePoint Portal Server von Microsoft
bei WESTFA einzuführen und die mit den Reporting Services erstellten
Auswertungen dort zu integrieren.
80 7.1 Zusammenfassung
7 Abschluss
7.1 Zusammenfassung
Für die Implementierung eines BI-Gesamtansatzes wurde bei WESTFA der bereits
lizensierte Microsoft SQL Server 2005 eingesetzt. Dieser konnte mit seinem
Datenbankmodul, den Integration Services, den Analysis Services und abschließend
auch mit den Reporting Services passende und vor allem integrierte Werkzeuge für
die Erstellung der einzelnen Komponenten eines BI-Gesamtansatzes zur Verfügung
stellen.
Im ersten Schritt wurde durch die Erstellung mehrerer Integration Services-Pakete
eine Extraktion der Daten aus den drei Quellsystemen von WESTFA vorgenommen
und diese unverändert in eine in dem Datenbankmodul erstellte Persistant Staging
Area geladen. Somit konnte diese im weiteren Projektverlauf als homogene
Datenquelle für die Implementierung eines ETL-Prozesses genutzt werden. Der
Schwerpunkt des ETL-Prozesses liegt auf der Transformation der extrahierten,
operativen Daten in dispositives Datenmaterial, das in eine dimensionale
Datenstruktur eines neu erstellten Data Warehouse geladen wird.
Aufbauend auf dem Data Warehouse wurde mit den Analysis Services ein auf OLAP
basierendes Analysesystem in Form eines Cubes erstellt, das über die
Serverkomponente der Analysis Services für Anfragen von Clients bereitgestellt
wurde.
Über unterschiedliche Abfragewerkzeuge kann der Cube bereits für die Analyse
herangezogen werden. Die Implementierung eines Frontends in Form einer
Portallösung das Zugriff auf unterschiedliche, vordefinierte Analysen bietet, wurde
bei WESTFA bisher nicht vorgenommen.
7 Abschluss 81
7.2 Fazit
Die bereits im Rahmen des Business- und des Data Understanding festgestellte
Problematik der Verteilung der geschäftsrelevanten Daten von WESTFA auf zwei,
durch das separat eingesetzte CRM-System sogar auf drei operative Systeme hat
sich auch während der Implementierung des BI-Gesamtansatzes als Hürde
herausgestellt. Diese konnte jedoch über die Zwischenspeicherung der Daten in
einer Persistant Staging Area umgangen werden.
Die Implementierung des ETL-Prozesses zur Datentransformation hat gezeigt,
warum der als Grundlage für dieses Projekt dienende CRISP-Prozess zu den
iterativen Vorgehensmodellen gezählt wird. Durch immer wieder neu auftretende
Probleme mit unvorhergesehenen oder fehlenden Daten musste eine permanente
Iteration der Phasen Business Understanding, Data Understanding, Data
Preparation und Modeling vorgenommen werden, um das gewünschte Ergebnis zu
erreichen.
Am Ende konnte ein vollautomatisierter Prozess erstellt werden, der tagesaktuell
die Daten aus den Quellsystemen extrahiert, diese transformiert und in das Data
Warehouse lädt. Anschließend werden diese Daten für komplexe Analysen mit
kurzen Antwortzeiten in einem Analysesystem, dargestellt als Cube mit einer
multidimensionalen Datenstruktur, bereitgestellt. Dieses eine Analysesystem
erlaubt mit wenigen Klicks Auswertungen, für die bei WESTFA bisher mehrere ExcelTabellen und weitere Mengen an statischen Listen geöffnet werden mussten.
Letztendlich hat die Implementierung eines BI-Gesamtansatzes bei WESTFA gezeigt,
dass Business Intelligence mehr ist als Datenextraktion, Datentransformation,
Datenladen und Datenbereitstellung in Analyse- und Portalsysteme. Im Rahmen des
Business Intelligence Projektes bei WESTFA werden zusätzlich Geschäftsprozesse
hinterfragt und angepasst, Datenbereinigungen der Quellsysteme initiiert und
Mitarbeiter für den richtigen Umgang mit Daten und Informationen sensibilisiert.
82 7.3 Ausblick
7.3 Ausblick
Im weiteren Projektverlauf sollen bei WESTFA der SharePoint Portal Server
eingesetzt und die Reporting Services des SQL Servers 2005 integriert werden.
Somit soll eine Portalanwendung implementiert werden, über die dem Anwender
Auswertungen, Analysen und Listen zur Verfügung gestellt werden können.
Neben der Entwicklung eines Frontends ist die Integration des Geschäftsfeldes
WESTFAGAS in den ETL-Prozess und in das Data Warehouse vorgesehen.
Bei der Größe des Cubes, die mit dieser Integration erreicht werden würde, lässt
sich zusätzlich die Frage nach der Implementierung von Data Marts stellen.
Ein Business Intelligence Projekt lässt sich nicht wie ein klassisches Projekt nach
dem Erreichen des definierten Ziels abschließen. Vielmehr beginnt nach dem
Abschluss der letzten Prozessphase eine neue Iteration durch den gesamten
Implementierungsprozess. Zielsetzungen können dabei die Erschließung neuer
interner oder externer Datenquellen sowie die Anpassung des BI-Gesamtansatzes
an neue Anforderungen, die durch geschäftsinterne oder am Markt entstandene
Veränderungen gegeben werden, sein.
Eidesstattliche Erklärung 83
Eidesstattliche Erklärung
Gemäß § 26 (1) der DPO erkläre ich an Eides statt, dass ich die vorliegende Arbeit
selbstständig angefertigt habe. Ich habe mich keiner fremden Hilfe bedient und
keine anderen, als die angegebenen Quellen und Hilfsmittel benutzt. Alle Stellen,
die wörtlich oder sinngemäß veröffentlichten oder nicht veröffentlichten Schriften
und anderen Quellen entnommen sind, habe ich als solche kenntlich gemacht. Diese
Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde
vorgelegen.
Dortmund, 02.03.2009
___________________________
Erklärung
Mir ist bekannt, dass nach § 156 StGB bzw. § 163 StGB eine falsche Versicherung an
Eides Statt bzw. eine fahrlässige falsche Versicherung an Eides Statt mit
Freiheitsstrafe bis zu drei Jahren bzw. bis zu einem Jahr oder mit Geldstrafe bestraft
werden kann.
Dortmund, 02.03.2009
___________________________
Abbildungsverzeichnis
Abbildungsverzeichnis
Abbildung 2-1: Magic Quadrant for Business Intelligence Platforms, 2008............................ 4
Abbildung 2-2: Beziehungen zwischen den Komponenten des SQL Server 2005 ................... 6
Abbildung 3-1: Aktivitäten eines ETL-Prozesses und der Phase Data Preparation ................. 9
Abbildung 3-2: Datenfluss zur Extraktion von Daten aus Kolumbus ..................................... 13
Abbildung 3-3: Verbindungsmanager zur Informix-Datenbank von megaWWS................... 14
Abbildung 3-4: Datenfluss zur Extraktion von Daten aus megaWWS ................................... 15
Abbildung 3-5: Entfernen von Leerzeichen in einem separaten Task des Datenflusses ....... 15
Abbildung 3-6: Datenfluss zur Extraktion von Daten aus V_Olga ......................................... 16
Abbildung 3-7: Erweitere Konfiguration eines Verbindungsmanagers für Dateien mit flacher
Datenstruktur ................................................................................................................. 17
Abbildung 3-8: Datenfluss zur Extraktion von Daten mit Fehlerbehandlung ........................ 18
Abbildung 3-9: SSIS-Pakete für die Extraktion ....................................................................... 19
Abbildung 3-10: Geplanter Task zur Ausführung der definierten Batch-Datei ..................... 20
Abbildung 3-11: Der allgemeine Transformationsprozess .................................................... 21
Abbildung 3-12: Einteilung von Mängeln in drei Klassen ...................................................... 23
Abbildung 3-13: Filterung semantischer Mängel mittels SQL-Anweisung ............................ 24
Abbildung 3-14: Ausschnitt der Kundentabelle in megaWWS .............................................. 27
Abbildung 3-15: Ausschnitt der Unternehmenstabelle von Kolumbus ................................. 27
Abbildung 3-16: Vereinheitlichung von Unternehmensdaten aus megaWWS und Kolumbus
........................................................................................................................................ 28
Abbildung 3-17: Harmonisierung von Unternehmensdaten ................................................. 28
Abbildung 3-18: Bisher bei WESTFA implementierter Aufbau des ETL-Prozesses ................ 31
Abbildung 3-19: Ole DB-Ziel: Durch das BI-Studio generierte SQL-Anweisung zum erstellen
einer neuen Dimensionstabelle ..................................................................................... 34
Abbildung 3-20: Bearbeitete SQL-Anweisung zum erstellen einer Dimensionstabelle ........ 35
Abbildung 3-21: SCD Assistent: Zuordnung von Datenflussattributen zu den
Dimensionsattributen .................................................................................................... 41
Abbildung 3-22: SCD Assistent: Festlegung von Änderungstypen für die Dimensionsattribute
........................................................................................................................................ 42
Abbildung 3-23: SCD Assistent: Kennzeichnung des aktuellen Datensatzes bei SCD Typ 2 .. 43
Abbildung 3-24: Implementierung einer Slowly Changing Dimension Typ 2 bei WESTFA .... 44
Abbildung 3-25: Verweistabelle für die Suche nach Surrogatschlüsseln .............................. 47
Abbildung 3-26: Verknüpfung und Suchspalte für die Suche nach Surrogatschlüsseln ........ 48
Abbildung 3-27: Erweiterte Manipulationen der Suche nach Surrogatschlüsseln................ 49
Abbildung 3-28: Lookup des Surrogatschlüssels einer SCD Typ2 .......................................... 53
Abbildung 3-29: Ladeprozess einer Faktentabelle ................................................................ 53
Abbildung 3-30: Detailausschnitt des Data Warehouse westfaDW von WESTFA ................ 54
Abbildung 3-31: Aufbau des Data Warehouse "westfaDW" bei WESTFA ............................. 55
Abbildung 4-1: Ausschnitt der Datenquellensicht des Data Warehouse "westfaDW" ......... 59
Abbildung 4-2: Cube-Assistent - Verwendung einer Datenquellensicht ............................... 60
85
86
Abbildung 4-3: Unterteilung der Tabellen aus der Datenquellensucht in Fakten und
Dimensionen .................................................................................................................. 61
Abbildung 4-4: Zuordnung von Zeittabellenspalten der Zeitdimension................................ 62
Abbildung 4-5: Auswahl und Benennung von Measures und Measuregruppen................... 63
Abbildung 4-6: Bestimmung der Dimensionsstrukturen ....................................................... 64
Abbildung 4-7: Mit dem Cube-Assistenten definierter Cube in der Entwicklungsumgebung
........................................................................................................................................ 65
Abbildung 4-8: Dimensions-Designer mit zwei Hierarchien .................................................. 67
Abbildung 4-9: Definition eines berechneten Wertes in Abhängigkeit einer Hierarchie der
Zeitdimension................................................................................................................. 68
Abbildung 4-10: Dimensionsverwendungsmatrix des Cube-Designers................................. 70
Abbildung 4-11: Bestimmung der Speichermethode MOLAP für eine Cubepartition .......... 72
Abbildung 4-12: automatisierte Verarbeitung des Cube ....................................................... 72
Abbildung 5-1: Aus den Anforderungen der Informationsbedarfsanalyse erstellte
Dimensionsmatrix .......................................................................................................... 74
Abbildung 5-2: Erweiterte Dimensionsmatrix ....................................................................... 75
Abbildung 5-3: Aktueller Prozess zur Informationsbeschaffung für eine Vertriebssteuerung
........................................................................................................................................ 76
Abbildung 5-4: Durch das Analysesystem verbesserter Prozess zur Informationsbeschaffung
........................................................................................................................................ 77
Tabellenverzeichnis
Tabellenverzeichnis
Tabelle 1: SCD Typ1: fiktive Kundendimension vor Verarbeitung ......................................... 37
Tabelle 2: SCE Typ1: extrahierter Datensatz mit geändertem Attributwert ........................ 37
Tabelle 3: SCD Typ1: fiktive Kundendimension nach Verarbeitung ...................................... 37
Tabelle 4: SCD Typ2: fiktive Kundendimension vor Verarbeitung ......................................... 39
Tabelle 5: SCD Typ2: extrahierter Datensatz mit geändertem Attributwert ........................ 39
Tabelle 6: SCD Typ2: fiktive Kundendimension nach Verarbeitung ...................................... 39
Tabelle 7: SCD Typ3: fiktive Kundendimension vor Verarbeitung ......................................... 40
Tabelle 8: SCD Typ3: extrahierter Datensatz mit geändertem Attributwert ........................ 40
Tabelle 9: SCD Typ3: fiktive Kundendimension nach Verarbeitung ...................................... 40
Tabelle 10: auftpos aus megaWWS ....................................................................................... 45
Tabelle 11: Datensatz vor der Verknüpfung .......................................................................... 52
Tabelle 12: Datensätze nach der Verknüpfung ..................................................................... 52
Tabelle 13: Datensatz nach der Trennung mit Surrogatschlüssel ......................................... 52
87
Literatur
Literatur
Chamoni, P., Gluchowski, P. und Hahne, M. 2005. Business Information
Warehouse: Perspektiven betrieblicher Informationsversorgung und
Entscheidungsunterstützung auf der Basis von SAP-systemen. Berlin : Springer, 2005.
3540675280.
Claßen, David. 2008. Business Intelligence im Mittelstand. Business Intelligence im
Mittelstand. Dortmund : s.n., 2008.
Corporation, Microsoft. 2008. SQL Server 2005-Onlinedokumentation. SQL Server
2005-Onlinedokumentation. [Online] Microsoft Corporation, November 2008. [Zitat
vom: 16. Januar 2009.] http://msdn.microsoft.com/dede/library/ms130214(SQL.90).aspx.
CRISP-DM consortium. 2000. CRoss Industry Standard Process. CRoss Industry
Standard Process. [Online] 2000. [Zitat vom: 20. Oktober 2008.] http://www.crispdm.org/Process/index.htm.
Gluchwoski, Peter, Gabriel, Roland und Dittmar, Carsten. 2008. Management
Support Systeme und Business Intelligence. Berlin : Springer, 2008.
IBM Corporation . IBM Cognos 8 Business Intelligence . IBM Cognos 8 Business
Intelligence . [Online] IBM Corporation .[Zitat vom: 15. 01 2009.]
http://www.cognos.com/ch/de/products/cognos8businessintelligence/index.html.
Kemper, Hans-Georg, Mehanna, Walid und Unger, Carsten. 2006. Business
Intelligence - Grundlagen und praktische Anwendungen. Wiesbaden :
Vieweg+Teubner, 2006.
Kimball, Ralph. 1998. Data Warehouse Architect. Surrogate Keys. [Online] Miller
Freeman, Inc., 02. Apris 1998. [Zitat vom: 13. 12 2008.]
http://www.dbmsmag.com/9805d05.html.
—. 1998. Data Warehouse Architect. Pipelining Your Surrogates. [Online] Miller
Freeman, Inc., 04. Mai 1998. [Zitat vom: 12. Dezember 2008.]
http://www.dbmsmag.com/9806d05.html.
Kimball, Ralph, et al. 2008. The Data Warehouse Lifecycle Toolkit. Indianapolis :
Wiley Publishing Inc., 2008.
Microsoft Corporation. Microsoft Business Intelligence. Microsoft Business
Intelligence. [Online] Microsoft Corporation.[Zitat vom: 15. 01 2009.]
http://www.microsoft.com/germany/bi/.
89
90
Oracle Corporation. Business Intelligence Lösungen von Oracle. Business
Intelligence Lösungen von Oracle. [Online] Oracle Corporation.[Zitat vom: 15. 01
2009.] http://www.oracle.com/lang/de/solutions/business_intelligence/index.html.
Richardson, James, Schlegel, Kurt und Ne, Bill Hostmann. 2008. Magic Quadrant
for Business Intelligence. Magic Quadrant for Business Intelligence. [Online]
Gartner, Inc., 01. 02 2008. [Zitat vom: 15. 01 2009.]
http://mediaproducts.gartner.com/reprints/microsoft/vol7/article3/article3.html.
G00154227.
SAP Deutschland AG & Co. KG. Komponenten & Werkzeuge von SAP NetWeaver
Business Intelligence. Komponenten & Werkzeuge von SAP NetWeaver Business
Intelligence. [Online] SAP Deutschland AG & Co. KG.[Zitat vom: 15. 01 2009.]
http://www.sap.com/germany/plattform/netweaver/components/businessintellige
nce/index.epx.
Schrödl, Holger. 2006. Business Intelligence mit Microsoft SQL Server 2005.
München : Hanser Fachbuchverlag, 2006.
Warner, Daniel. 2007. Advanced SQL SQL für Praxis und Studium. Poing : Franzis
Verlag, 2007. 3772371701.
Wilmes, Caroline, Dietl, Helmut und van der Velden, Remco. 2004. Die strategische
Resource "data Warehouse". Wiesbaden : Deutscher Universitäts-Verlag/GWV
Fachverlage GmbH, 2004. 3824480468.