Upload
piedone64
View
74
Download
7
Tags:
Embed Size (px)
Citation preview
Enterprise Data Warehousing mit SAP BW – Ein Überblick
White Paper Version 2.0
August 18th, 2003
SAP (SAP AG and SAP America, Inc.) assumes no responsibility for errors or omissions in these materials.
These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.
SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.
SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Inhalt
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK ....................................... 1
INHALT................................................................................................................................................. 2
1 VORBEMERKUNG....................................................................................................................... 1 1.1 UNTERSTÜTZTE SOFTWARE VERSIONEN.................................................................................... 1 1.2 STATUS DES WHITE PAPERS..................................................................................................... 1
2 ZIELE DES WHITE PAPERS ....................................................................................................... 1
3 MOTIVATION................................................................................................................................ 2 3.1 DER MARKT ............................................................................................................................. 2 3.2 WARUM BRAUCHT MAN EINE UNTERNEHMENSWEITE BW STRATEGIE? ........................................ 3
4 ENTERPRISE DATA WAREHOUSING MIT SAP BW................................................................. 6
5 BW ENTERPRISE ARCHITEKTUR ............................................................................................. 7 5.1 ASPEKTE EINER DATA WAREHOUSE ARCHITEKTUR..................................................................... 7 5.2 DATENSPEICHER ARCHITEKTUR - BW DATA LAYER.................................................................. 11
5.2.1 BW Architected Data Mart Layer .................................................................................. 12 5.2.2 BW Data Warehouse Layer .......................................................................................... 15 5.2.3 BW Extraktion und Staging........................................................................................... 20 5.2.4 BW Unterstützung des Operational / Real Time Reporting.......................................... 21
5.3 DATEN ARCHITEKTUR - BW DATEN MODELL............................................................................ 25 5.3.1 Operative Daten Modelle und Data Warehouse Datenmodell ..................................... 25 5.3.2 Das BW Daten Modell .................................................................................................. 26
5.4 TOPOLOGIEN – BW LANDSCHAFTEN ....................................................................................... 30 5.4.1 Konsistenz in einer verteilten BW Landschaft .............................................................. 31 5.4.2 BW Landschaften und Technische Parameter............................................................. 32 5.4.3 Inside-Out Landschafts- Architektur - BW als Zentrales Enterprise Data Warehouse 33 5.4.4 Outside-In Landschafts Architektur - Dezentrale BW Data Warehouses..................... 35
6 ZENTRALE BW ANWENDUNGSENTWICKLUNG ................................................................... 39
7 DATEN UND DATEN MODELL INTEGRATION ....................................................................... 41 7.1 HERAUSFORDERUNGEN BEI DER DATENINTEGRATION .............................................................. 41 7.2 DATEN MODELL INTEGRATION ................................................................................................. 44 7.3 DIE ROLLE DES SAP MASTER DATA MANAGEMENTS (MDM).................................................... 45
8 ZUSAMMENFASSUNG.............................................................................................................. 47
TABELLE DER ABBILDUNGEN....................................................................................................... 48
2003 SAP AG AND SAP AMERICA, INC. INHALT
BW Enterprise Data Warehousing – Im Überblick V2.0
1 Vorbemerkung
1.1 Unterstützte Software Versionen Dieses Dokument bezieht sich auf die BW Versionen 3.x.
1.2 Status des White Papers Das Thema des Dokumentes ist vielschichtig. Es erhebt keinen Anspruch alle Bereiche zu diesem Thema abzudecken und die diskutierten Bereiche vollständig zu beschreiben.
Bitte besuchen Sie den SAP Service Marketplace regelmäßig, um sich über die aktuelle Version dieses Dokumentes zu informieren.
2 Ziele des White Papers Dieses White Paper bietet einen Überblick über die Implementierung des SAP Business Information Warehouse (SAP BW) aus Gesamt-Unternehmenssicht.
Folgende Themen werden betrachtet
• Architektur Aspekte, d.h. konzeptionelle Ebenen der Datenhaltung, Daten Modelle, Topologien etc.
• Integrations- Aspekte, d.h. Unterstützung der Unternehmensstrategie zur Harmonisierung der Stammdaten
• Lösungsentwicklung, d.h. effiziente, konsistente Erstellung von BW basierten Anwendungen
Unternehmen unterscheiden sich hinsichtlich Organisation und die Art ihres Geschäfts. Dies impliziert, dass es keine Standardlösung gibt für eine unternehmensweite BW Implementierungsstrategie. Trotzdem gibt es Grundwahrheiten, die stets zu berücksichtigen sind und Muster, die sich aus Unternehmenstypen ergeben. So beschreibt dieses White Paper vor allen Dingen die grundlegenden Aspekte eines unternehmensweiten BW Einsatzes.
Eine unternehmensspezifische strategische BW Architektur-Beratung kann diese White Paper nicht ersetzen.
Dieses White Paper fokussiert sich also auf generelle Prinzipien einer strategischen unternehmensweiten BW Implementierung, nicht auf die Ausnahmen, es folgt also der 80-20 Regel.
Das White Paper vermeidet Details wo immer möglich, um den Gesamtzusammenhang nicht aus den Augen zu verlieren.
Beim Studium des White Papers sind BW Kenntnisse von Nutzen, aber nicht Voraussetzung.
2003 SAP AG AND SAP AMERICA, INC. 1
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
3 Motivation 3.1 Der Markt Zum Zeitpunkt, da dieses Dokument geschrieben wird gibt es mehr als 6000 BW Installationen im Markt.
Einige grundlegende Vorteile des BW führen dazu, dass mehr und mehr Kunden BW zum Mittelpunkt ihrer unternehmensweiten Data Warehouse Strategie machen. In diesem Kontext wird von Kunden häufig das End-to-End Konzept von BW hervorgehoben. Das integrierte Metadatenkonzept von der Datenintegration bis hin zur Analyse führt im Vergleich zu fragmentierten Technologien zu niedrigeren Gesamtkosten des gesamten Projekts.
Also, weg von den isolierten Instanzen hin zu einer architekturbasierten Sicht. Damit erfährt das BW eine neue Qualität in der Positionierung in den Unternehmen.
Das folgende Bild zeigt unterschiedliche Strategie-Ansätze:
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 3 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 3
Evolution of SAP BW
Strategic Corporate BW Strategic Corporate BW ImplementationsImplementations
Isolated BW Isolated BW ImplementationsImplementations
BW1
BW2
BW3
BWn
BW1
BW2
BWn
GlobalBW
Others
‘Headquarter’ ‘Headquarter’ ReportingReportingScenarioScenario
‘Local’BW
‘Local’BW
‘Local’BW
GlobalBW
Architected Architected BW LandscapeBW Landscape
ScenarioScenario
EnterpriseBW
BW EnterpriseBW EnterpriseDataData
WarehouseWarehouseScenarioScenario
Issues:SynergyIntegrationConsistency
SpokeBW
SpokeBW
Abbildung 1: Evolution des SAP BW Ein Hauptziel des White Papers ist es, den Evolutionsprozess des BW in den Unternehmen zu unterstützen indem es für Kunden und Berater, die in der Entscheidungsfindung sind, einen Überblick über wesentliche Entscheidungsfelder bei einem unternehmensweiten BW Einsatz gibt.
Auf der anderen Seite gibt es noch eine große Zahl von Kunden, die keine unternehmensweite Data Warehouse Strategie haben und deren BW Implementierungen isoliert und eingeschränkt sind.
2003 SAP AG AND SAP AMERICA, INC. 2
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Für diesen Leserkreis möchte das White Paper einen Anstoß geben und Bewusstsein wecken hinsichtlich der Chancen und des Nutzens eines unternehmensweiten, architektur-basierten BW Einsatzes.
3.2 Warum braucht man eine Unternehmensweite BW Strategie? Viele Trainings, ‘enhanced documentations’, ‘ASAP Accelerators’ und ‘How to Guides’ sind verfügbar, die die BW-Nutzer unterstützen. Gemeinsam ist diesen Hilfen die Fokussierung auf die Unterstützung bei konkreten Projekt-Herausforderungen.
Dies ist wichtig und notwendig! Es ergeben sich aber auch Defizite, da die Projekte stets Teil einer inkrementellen BW-Implementierung sind:
Projekt-Ziel auf Projekt-Ziel wird modelliert und umgesetzt in BW. Die Ziele sind typischerweise reporting- und analyse-getrieben und der Gesamt-Projekterfolg wird auf Entscheiderebene daran gemessen, inwieweit die Reporting- und Analyseanforderungen erfüllt wurden. Also liegt der Fokus auf die Lösungsebene sprich den Data Marts.
Wenig Aufmerksamkeit wird dem entscheidenden Faktor für den mittel- und langfristigen Erfolg der BW-Investments gezollt:
Redundanz muss in allen Bereichen kontrolliert werden (controlled redundancy)!
Selten existieren unternehmensweite Richtlinien hinsichtlich
Der persistenten Datenspeicher des BW und deren Design
Des BW Data Warehouse Daten Modells und dessen Handhabung
Der BW Landschaft, d.h. der Rolle von BW Instanzen und welche Bedingungen für neue Instanzen gelten
Auch werden Datenintegrations-Aspekte häufig vernachlässigt. Und nicht zuletzt werden Applikationen in den unterschiedlichen Organisationseinheiten, die ein BW besitzen, unabgestimmt und redundant entwickelt.
Insgesamt aus Gesamtunternehmenssicht ein kostspieliges, wenig effizientes Vorgehen, dass bei komplexen Strukturen eines nicht liefert: Konsistente, verlässliche, integrierte Informationen.
Die folgende Graphik verdeutlicht die Situation eines einseitigen Lösungsfocus:
2003 SAP AG AND SAP AMERICA, INC. 3
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 4 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 4
Redundancy and Data Mart (Solution) Focus
Real World
InformationRequirements
(grouped to Scopes)
....
Schema-Modeling
InfoCubes/ODS-Objects
Extraction
Sources
Business Rules
Transformation
BW Application Project Team
Successful Data Warehousing means ‘Controlled Redundancy’ !Successful Data Warehousing means ‘Controlled Redundancy’ !Successful Data Warehousing means ‘Controlled Redundancy’ !
Impacts of non-existing corporate BW guidelines:
• Redundant Data• Redundant Extraction• Redundant Transformation• Redundant Business Rules• Redundant Masterdata•......
Abbildung 2: Redundanz und Lösungsfocus Die nächste Graphik illustriert die Probleme einer ‚gewachsenen’ Landschaft:
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 5 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 5
Redundancy and Multiple BW Landscape
Sub-Division AR/3
Global
Sub-Division B R/3
only Germany
Sales EuropeR/3
BW Local
Global
HQBW
SubDiv BW
MDMS
BWS-America
BWAsia
BWN-America
BWSales Europe
Source Systems
....................DivR/3
DivR/3
DivR/3
12 systemsworldwide
Successful Data Warehousing means ‘Controlled Redundancy’ !Successful Data Warehousing means ‘Controlled Redundancy’ !Successful Data Warehousing means ‘Controlled Redundancy’ !
A Real Life
BW Landscape ExampleImpacts of non-existing corporate BW guidelines:
•Redundant Data Flows•Redundant Extraction•Redundant Development•Redundant Models•......
2003 SAP AG AND SAP AMERICA, INC. 4
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Abbildung 3: Redundanz und ‚multiple BW’ Landschaft
Je komplexer die Strukturen einer Unternehmung sind desto notwendiger sind unternehmensweit gültige Richtlinien und Empfehlungen für den Einsatz von BW. Sie garantieren langfristig Konsistenz und Reduzierung der Kosten.
2003 SAP AG AND SAP AMERICA, INC. 5
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
4 Enterprise Data Warehousing mit SAP BW Wenn wir über Enterprise Data Warehousing sprechen, stellt sich zunächst die Frage, was wir unter diesem Terminus verstehen wollen: Enterprise Data Warehousing ist die Summe aller Entscheidungen, die auf Unternehmensebene getroffen werden müssen, um eine nach anerkannten Richtlinien unternehmensweit gültige und dauerhafte Lösung zu erhalten, die alle Bedürfnisse nach integrierten, konsistenten, strukturierten Informationen befriedigt.
Diese Entscheidungen spiegeln sich in der Enterprise Data Warehouse Architektur wider.
In diesem Kapitel werden zunächst die Aspekte einer solchen Architektur betrachtet, um dann näher zu untersuchen, wie BW eine architekturbasierte, konsistente, unternehmensweite Data Warehouse Lösung unterstützt.
Neben einer konsistenzsichernden BW Architektur wollen wir betrachten, welche Unterstützung BW bietet, um konsistente Anwendungslösungen zu erzeugen.
Weiterhin ist für eine unternehmensweite BW Strategie, BW mit in die Datenintegrationsstrategie des Unternehmens einzubeziehen. Dies geschieht im letzten Kapitel.
Wie bei allen wichtigen Entscheidungen konzentrieren wir uns dabei auf die grundlegenden Dinge, folgen also der 80:20 Regel.
2003 SAP AG AND SAP AMERICA, INC. 6
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
5 BW Enterprise Architektur Eine Architektur kann man als eine Systemdesign-Entscheidung auffassen, die eine gewisse Dauerhaftigkeit besitzt, d.h. einmal gefällt nicht leicht wieder zu ändern ist. Gilt es eine unternehmensweite BW Architektur zu definieren, so stellt man fest, dass der Begriff Architektur mehrdeutig verwendet wird und Aspekte des „wo, was und wie“ häufig vermischt werden. Dies führt zu Konfusion und birgt die potentielle Gefahr in sich, dass wesentliche Aspekte einseitig oder gar nicht betrachtet werden.
5.1 Aspekte einer Data Warehouse Architektur Bei einer Diskussion über eine aus Enterpise-Sicht optimalen BW Architektur wird der Focus häufig sehr schnell auf physische BW Instanzen gerichtet. Braucht man mehrere BW Instanzen und wenn ja, wo sollen diese institutionalisiert werden und wie arbeiten die Instanzen zusammen. Es geht hier also um eine BW Landschaft oder wie wir es nennen wollen um eine konsistente Enterprise BW Topologie. Dies bedeutet jedoch den zweiten oder sogar erst dritten Architektur-Aspekt vor dem Ersten zu betrachten. Denn wie kann ich einzelne BW Instanzen und ihre Aufgaben diskutieren, ohne definiert zu haben, wie eigentlich in so einer BW Instanz die Daten konsistent behandelt und gespeichert werden? Dies führt uns zunächst zu der Datenspeicher oder Daten-Layer Architektur: Die Layer-Architektur definiert die persistenten Datenzustände und deren Speicher-Schemata auf dem Weg von der Extraktion bis zum End-Benutzer, sowie die Veredelungs-Prozesse auf diesem Weg. Qualifizierte Daten-Zustände und die zugehörigen Layer sind:
• Staging Area - Roh • Data Warehouse Layer - Integriert, granular, nicht applikationsspezfisch, historisch • Data Mart Layer - Integriert, aggregiert, applikationsspezfisch • Operational Data Store (ODS) – integriert, granular, applikationsspezfisch, zeitnah
2003 SAP AG AND SAP AMERICA, INC. 7
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 15 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 15
Conceptual Layers of Data Warehousing
Infor-mationAccess
Non-SAPSource
SAPSource
PersistentStaging
Area
Operational Data Store
Archiving & Near-Line Storage
Data Warehouse
Archi-tected DataMarts
Abbildung 4: Konzeptionelle Layer Architektur Das wiederholte Speichern der Rohdaten in unterschiedlichen Veredelungszuständen bedeutet Redundanz. Eine konsistente Layer-Architektur bietet aber die einzige Möglichkeit, die dem Data Warehousing immanente Redundanz zu kontrollieren. Die Datenspeicher-Schemata der Layer müssen dies berücksichtigen. Eine geeignete Layer-Unterstützung ist jedoch nur eine notwendige aber nicht hinreichende Bindung für eine unternehmensweite Data Warehouse Architektur, welche die Konsistenz mittel- und langfristig sichert. Dies ist nur zu erreichen, wenn auch die operativen Datenmodelle konsistent in das Daten-Modell des Data Warehouse Layers und das Daten-Modell des Data Mart Layers überführt werden. Eine konsistente Daten (-Modell) Architektur beschreibt das Modell jedes Layers und die Modell-Beziehungen untereinander. Wir benötigen also eine Daten-Architektur, die z.B. gewährleistet, dass die operativen Materialbegriffe, wie wir sie etwa im Vertriebs-, Einkaufsbereich oder Materialwirtschaft finden, konsistent auf eine Material-Subject-area im Data Warehouse abgebildet werden. Nur so ist es möglich integrierte Data Warehouse Szenarios zu schaffen. Im Idealfall existiert ein einziges Daten-Modell und das Data Warehouse Modell für die Layer wird hieraus abgeleitet. Ein solches unternehmensweites, operatives Daten Modell existiert jedoch i.R. nicht, besonders dann nicht, wenn Legacy Systeme involviert sind. Wegen der Schwierigkeiten hierauf ein stabiles Data Warehouse Daten-Modell aufzubauen, werden Richtlinien für das Data Warehouse Datenmodell häufig gar nicht oder nur für bestimmte Bereiche erstellt. Die Folge sind nicht abgestimmte Insellösungen ('Stovepipe Solutions’). Dies illustriert die folgende Graphik:
2003 SAP AG AND SAP AMERICA, INC. 8
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 95 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 95
Operational Data Models and the Data Warehouse Data Model
Not aligned operational data models Consistent enterprise data model
Inconsistent data warehouse data models ⇒stovepipe solutions
Consistent data warehouse data model ⇒long term success
A data warehouse A data warehouse consistency challengeconsistency challenge
Abbildung 4: Operative Daten-Modelle und DWH-Daten-Modell Das Fehlen einer Daten-Modell Architektur ist eine der Ursachen für das Scheitern von unternehmensweiten Data Warehouse Strategien. Erst wenn hinsichtlich Daten-Layer und Daten-Modell Klarheit besteht, macht es Sinn über unternehmensweite Topologie-Aspekte einer BW Architektur zu diskutieren, denn die Topologie wird von den Entscheidungen hinsichtlich der Layer Architektur beeinflusst. Man unterscheidet zwei grundlegende Topologien: • Die BW Enterprise Data Warehouse Landschaft mit BW als zentralem Information Hub • Die auf ‚lokalen’ BWs basierende Landschaft mit übergeordnetem ‚globalen’ BW
‘Local’BW
‘Local’BW
‘Local’BW
GlobalBW
OutsideOutside--ININBWBW
LandscapeLandscape
Others
‘Local’BW
‘Local’BW
‘Local’BW
GlobalBW
OutsideOutside--ININBWBW
LandscapeLandscape
Others
EnterpriseBW
InsideInside--OutOutBWBW EnterpriseEnterprise
DataDataWarehouseWarehouse Spoke
BW
SpokeBW
Others
SpokeBW
EnterpriseBW
InsideInside--OutOutBWBW EnterpriseEnterprise
DataDataWarehouseWarehouse Spoke
BW
SpokeBW
Others
SpokeBW
Abbildung 5: BW Basis-Topologien Bei der Festlegung der BW Topologie spielen politische, organisatorische und technische Faktoren eine wichtige Rolle, so dass man nicht von einer allgemein gültigen optimalen BW Topologie sprechen kann.
2003 SAP AG AND SAP AMERICA, INC. 9
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Zusammenfassend kann gesagt werden, dass es gilt in folgendenden Bereichen unternehmensweit geltende Festlegungen zu treffen: • BW Daten Layer Architektur
• welche Datenzustände werden sinnvoller Weise persistent gespeichert • wie werden die unterschiedlichen Datenspeicher Anerkannterweise designed
• BW Daten Modell Architektur • Jeder DWH-Layer benötigt ein Datenmodell, dass die Objekte und ihre Beziehungen
beschreiben • Die Datenmodelle der unterschiedlichen Layer müssen sich konsistent auseinander
ableiten • BW Topologie
• unterschiedliche Unternehmenskulturen, geographische und geschäftliche Diversifikation führen zu unterschiedlichen Data Warehouse Landschaften
2003 SAP AG AND SAP AMERICA, INC. 10
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
5.2 Datenspeicher Architektur - BW Data Layer Es ist allgemein akzeptiert die Datenablagen, die Analyse und Reporting unterstützen von den Datenablagen getrennt zu halten, die im weitesten Sinne der Datenaufbereitung dienen. Analyse und Reporting werden durch sogenannte Data Marts und im Fall von event-nahen, operativem Reporting durch Operational Data Stores abgedeckt. BW unterstützt multidimensionale Data Marts durch ein Extended Star Schema aus BW InfoCubes und übergreifenden BW InfoObject Master Daten Dimensionen. Operational Data Stores werden durch ‚flache’ BW ODS-Objekte unterstützt. Auch hier dienen die BW Master Daten als ODS-Objekt übergreifende Strukturen. Datenaufbereitung, d.h. qualitäts- und integrationssichernde Prozesse werden als Staging-Prozesse bezeichnet. Die persistente Speicherung von Daten der Staging-Prozesse erfolgt in Staging-Bereichen. Data Staging Ablagen werden durch die Persistent Staging Area (PSA) Objekte und durch ODS-Objekte realisiert. Das granulare, integrierte Ergebnis des Staging-Prozesses stellt einen ausgezeichneten Zustand dar und wird als Data Warehouse Layer bezeichnet. BW ODS-Objekte sind die zentralen Speicherobjekte die einen BW Data Warehouse Layer aufbauen. Es ergibt sich also folgendes allgemeine Bild einer BW- Layer Architektur:
Finance
Logistic Ope
n D
istri
butio
n
SAP Business Information WarehouseSAP Business Information Warehouse
StagingStagingAreaArea
CleansingCleansingTransformTransform
MasterReference
Data
Data Data WarehouseWarehouse
ODSODS
PrimaryPrimaryData Data
ManagementManagement
Extra
ctio
n /
Ope
n St
agin
g
DataDataAcquisitionAcquisition
Data Data DeliveryDelivery
any
targ
et
Ext
ende
d St
ar S
chem
asE
xten
ded
Star
Sch
emas
Flow Control Flow Control
MetaMeta DataData
any
sour
ce TransactionData
ArchitectedArchitectedData MartsData Marts
FinanceFinance
LogisticLogistic Ope
n D
istri
butio
n
SAP Business Information WarehouseSAP Business Information Warehouse
StagingStagingAreaArea
CleansingCleansingTransformTransform
MasterReference
Data
Data Data WarehouseWarehouse
ODSODS
PrimaryPrimaryData Data
ManagementManagement
Extra
ctio
n /
Ope
n St
agin
gEx
tract
ion
/ O
pen
Stag
ing
DataDataAcquisitionAcquisition
Data Data DeliveryDelivery
any
targ
et
Ext
ende
d St
ar S
chem
asE
xten
ded
Star
Sch
emas
Flow Control Flow Control
MetaMeta DataData
any
sour
ce TransactionData
ArchitectedArchitectedData MartsData Marts
Abbildung 5: BW Layer Architektur - Überblick
2003 SAP AG AND SAP AMERICA, INC. 11
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
5.2.1 BW Architected Data Mart Layer InfoCube Data Marts erlauben das flexible Erstellen von Abfragen und das Navigieren auf integrierten, granularen oder aggregierten Daten. Um Vergleiche zu ermöglichen, ist ein mehr oder weniger großer Bestand an historischen Daten vorzuhalten. InfoCubes sind multidimensionale Datenstrukturen, auch Star Schemas genannt, die die Daten derart organisieren, dass die Kennzahlen (oder Fakten oder Measures) in Beziehung zu sie umgebenden, sogenannten Merkmalen und ihren Attributen, den Dimensionen (BW-InfoCube-Dimensionen und Master Daten) gesetzt werden. Um die Mächtigkeit der InfoCube Schemas zu erhöhen, sind die Dimensionen in lokal- und global- wirkende Teile zerlegt. Global deshalb, weil diese Teile einer Dimension nur einmal gespeichert werden und von unterschiedlichen InfoCubes gemeinsam adressiert werden.
FACT Table
Material_Dimension_IDSalesOrg_Dimension_IDTime_Dimension_IDCustomer_Dimension_ID
Sales AmountQuantity
InfoCubeInfoCube
Gebiet 1 Gebiet 2 Gebiet 3
Bezirk 1
Gebiet 3a
Bezirk 2
Region 1
Gebiet 4 Gebiet 5
Bezirk 3
Region 2
Gebiet 6
Bezirk 4
Gebiet 7 Gebiet 8
Bezirk 5
Region 3
Vertriebsorganisation
Material Group
Material Hierarchy Table
Material NumberLanguage Code
Material NumberLanguage CodeMaterial Name
Material Text TableMaterial_Dimension_ID
Material NumberMaterial Dimension
Table
Material Master Table
Material NumberMaterial Number
Material Type
MaterialMaterialDimensionDimension
Shared, globalShared, globalPart of
Material Dimension
LocalLocal Part of Material Dimension
BW Extended Star Schema
FACT Table
Material_Dimension_IDSalesOrg_Dimension_IDTime_Dimension_IDCustomer_Dimension_ID
Sales AmountQuantity
Material_Dimension_IDSalesOrg_Dimension_IDTime_Dimension_IDCustomer_Dimension_ID
Sales AmountQuantity
InfoCubeInfoCube
Gebiet 1 Gebiet 2 Gebiet 3
Bezirk 1
Gebiet 3a
Bezirk 2
Region 1
Gebiet 4 Gebiet 5
Bezirk 3
Region 2
Gebiet 6
Bezirk 4
Gebiet 7 Gebiet 8
Bezirk 5
Region 3
Vertriebsorganisation
Material GroupMaterial Group
Material Hierarchy Table
Material NumberLanguage Code
Material NumberLanguage CodeMaterial NameMaterial Name
Material Text TableMaterial_Dimension_ID
Material NumberMaterial Dimension
Table
Material Master Table
Material NumberMaterial Number
Material TypeMaterial Type
MaterialMaterialDimensionDimension
Shared, globalShared, globalPart of
Material Dimension
LocalLocal Part of Material Dimension
BW Extended Star Schema
Abbildung 5: The BW Extended Star Schema BW InfoCubes unterstützen also das Konzept der 'Conformed Dimensions', die eine Art Klebstoff zwischen den InfoCubes bilden.
InfoCube
CUSTOMER
MATERIAL
CUSTOMER
MATERIALmaster
CUSTOMERmaster
Horizontal Consistency:Horizontal Consistency:Conformed Structures Conformed Structures
BW InfoObjectsBW InfoObjectsmaster datamaster data
CUSTOMER
MATERIAL
Horizontal Consistency: BW Architected Data Mart Layer
InfoCubeInfoCube InfoCube
CUSTOMER
MATERIAL
CUSTOMER
MATERIALmaster
CUSTOMERmaster
Horizontal Consistency:Horizontal Consistency:Conformed Structures Conformed Structures
BW InfoObjectsBW InfoObjectsmaster datamaster data
CUSTOMER
MATERIAL
Horizontal Consistency: BW Architected Data Mart Layer
InfoCubeInfoCube
2003 SAP AG AND SAP AMERICA, INC. 12
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Abbildung 6: Horizontale Konsistenz im BW Architected Data Mart Layer Conformed Dimensions sind wesentlich für die horizontale Konsistenz im Data Mart Layer. Sie sind Teil des BW-Konzepts, um zu verhindern, dass Insellösungen ('Stovepipes') entstehen. Der BW-Terminus für die Conformed Dimensions ist 'Master Data'. Dies ist ein Grund, dass BW Data Marts als Architected Data Marts bezeichnet werden. Neben der Konsistenz-Unterstützung ist natürlich die Mächtigkeit des BW InfoCube-Schemas in Hinblick auf die Abbildung der Endbenutzeranforderungen essentiell. Hier sind vor allen Dingen unterschiedliche historische Sichten auf dieselben Kennzahlen zu nennen. Durch die Nutzung von Surrogat-Schlüsseln im InfoCube und durch das Master Data/ Conformed Dimension Konzept erlaubt es BW gleichzeitig in einem InfoCube-Schema unterschiedliche Sichten auf Kennzahlen abzubilden:
SAP AG 2003, Corporate Data Warehousing based on SAP BW, J. Haupt 6 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 6
BW Support of Different Historical Views
Constellation 09/1998Customer Mother-Company
AAA XBBB XCCC Y
Constellation 10/1998
Customer Mother-Company AAA XBBB Y (changed)CCC Y
Customer Date Revenue
AAA 09/1998 100BBB 09/1998 100CCC 09/1998 100BBB 10/1998 100CCC 10/1998 100
Fact Table
Mother-Comp Rev 09/98 Rev 10/98
X 100 0Y 200 200
Report using today‘s (10/98) constellation
Mother-Comp Rev 09/98 Rev 10/98
X 200 100Y 100 100
Report using 09/98 constellation
Mother-Comp Rev 09/98 Rev 10/98
X 200 0Y 100 200
Report showing historical truth
Mother-Comp Rev 09/98 Rev 10/98
X 100 0Y 100 100
Report showing comparable results
BW supported Views in
a single InfoCube
Extended Star Schema
Abbildung 7: BW und Slowly Changing Dimensions • 'Today is Yesterday' : Zeige die Kennzahlwerte auch historische aus der heute gültigen
Perspektive (aktuelle Sicht der Dimensionsattribute) • 'Yesterday is Today' : Zeige die Kennzahlwerte aus einer beliebigen Perspektive
(Stichtagbezogene Sicht der Dimensionsattribute) • 'Historical Truth' : Zeige die Kennzahlen (Transaktionen) in dem Zusammenhang
(Historisierung der Dimensionsattribute), wie er zum Buchungszeitpunkt herrschte - also historisch korrekt
Auch sind Szenarios darstellbar, in denen nur solche Kennzahlwerte (Transaktionen) reported werden, die unter vergleichbaren Dimensionsattribut-Konstellationen entstanden sind.
2003 SAP AG AND SAP AMERICA, INC. 13
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Zur Reduzierung der Redundanz und um dem Irrweg 'ein Report gleich einem InfoCube' zu begegnen, werden auf den persistenten InfoCubes virtuelle multidimensionale Strukturen sog. Multiprovider und Queries unterstützt.
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 24 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 24
Multi-dimensional Schemas in BW
EndEnd--User User Reporting & Analysis needReporting & Analysis need
MultiMulti--dimensional modeldimensional model
BW InfoCube(s)BW InfoCube(s)physical implementation
basic factsnot report specific
BW MultiProviderBW MultiProvidervirtual Structures
basic factsnot report specific
optional
BW BEX QueryBW BEX Queryvirtual Structures
complex KPIsnavigation behaviorreport (type) specific
BW BEX ReportBW BEX Reportend-user requirement
specific
Abbildung 8: Persistente und Virtuelle Multidimensionale Strukturen in BW Neben den Stärken des BW Data Mart Layers sind aber auch die Grenzen und Gefahren einer Data Mart fokussierten BW Implementierung offensichtlich: Begrenzter Wiederverwendbarkeit der Daten und Verlust von Historischen Zuständen
• Daten werden im Data Mart Layer scope-spezifisch behandelt: Aggregation/ Manipulation/ Überschreiben von Daten sind normal. Die Daten sind so nur begrenzt für andere Zwecke nutzbar.
• Der Data Mart Layer ist die direkte Zugriffsschicht für den End-User. Performance spielt daher eine entscheidende Rolle. Folglich werden im Data Mart Layer nur die Daten vorgehalten, die auch gebraucht werden. Eine 'just in case' Speicherung würde schnell zu großen Datenvolumina führen und die Performance korrumpieren. Daher ist ein überschreiben alter Images zulässig und gewollt, wie es etwa normalerweise in den Conformed Dimensions (master data) geschieht. Dies führt jedoch dazu, dass Historie verloren gehen.
Redundante Datenhaltung, d.h. dieselben Daten werden in unterschiedlichen InfoCubes und häufig in unterschiedlicher Granularität gehalten
Redundante Datenaufbereitung (Staging) Redundante Datenextraktion Begrenzter Rückverfolgbarkeit der Daten
Hier ist von der BW Layer Architektur her das Data Staging gefordert. Konsistenzgefahren, die von dem Umgang mit dem Data Mart Datenmodel herrühren, werden in im Kapitel Datenmodel Architektur behandelt.
2003 SAP AG AND SAP AMERICA, INC. 14
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
5.2.2 BW Data Warehouse Layer Um diese Grenzen und Gefahren einer Data Mart fokussierten BW Implementierung zu überwinden muss die unternehmensweite BW Architektur eine Antwort geben auf Forderungen wie
„extract once deploy many” “single point of truth”
Darüber hinaus muss das Dilemma gelöst werden, dass die sinnvolle Reduktion von Informationen im Data Mart Layer, da diese z.Z. nicht vom Endbenutzer nachgefragt werden, im Widerspruch zum Flexibilitätsanspruch eines BW steht, auch auf neue Anforderungen schnell zu reagieren. Die Antwort darauf ist die Herausbildung eines eigenen Layers, der das integrierte Ergebnis der Datentransformierungen und datenqualitätssichernden Prozesse konsistent, granular und historisiert speichert: Des BW Data Warehouse Layers. Ideal ist es, wenn dies unternehmensweit zentral geschieht. Man spricht dann von einem BW Enterprise Data Warehouse (Layer).
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 41 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 41
A Matter of Consistency and Reliability –The BW Data Warehouse (Layer)
Finance
Logistic Ope
n D
istri
butio
n
SAP Business Information WarehouseSAP Business Information Warehouse
StagingStagingAreaArea
CleansingCleansingTransformTransform
MasterReference
Data
Data Data WarehouseWarehouse
ODSODS
PrimaryPrimaryData Data
ManagementManagement
Extra
ctio
n /
Ope
n St
agin
g
DataDataAcquisitionAcquisition
Data Data DeliveryDelivery
any
targ
et
Ext
ende
d St
ar S
chem
asE
xten
ded
Star
Sch
emas
Flow Control Flow Control
MetaMeta DataData
any
sour
ce TransactionData
ArchitectedArchitectedData MartsData Marts
s
Abbildung 9: SAP BW Data Warehouse Layer Die folgende Beschreibung eines BW Data Warehouse Layers basiert auf der Definition von William H. Inmon: Ein BW Data Warehouse Layer bietet:
o Subjekt-orientierte, integrierte Daten o Originale Daten, die nicht in Hinblick auf einen bestimmten Projektzweck verändert
wurden („unflavored data“) o Granulare Daten
nicht aggregierte Daten
2003 SAP AG AND SAP AMERICA, INC. 15
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
o Historisierte Daten, d.h. weder Überschreiben noch Löschen sind erlaubt o Einen ‘single point of truth’
Der BW Data Warehouse Layer ist die einzige Quelle für die BW Architected Data Marts. (“extract once – deploy many”)
Ein BW Data Warehouse bietet damit folgenden Nutzen: I. Flexibilität
o Neue InfoCube-Data Mart Lösungen können inclusive Historie und erneute Extraktion zeitnah aufgebaut werden
o Auf unvorhersehbare, einmalige Benutzeranforderungen kann schnell reagiert werden, u.U. ohne persistente Strukturen aufzubauen. (Der BW DWH Layer sollte jedoch nicht für Standardanalysen missbraucht werden, da er keine daraufhin optimierten Strukturen besitzt)
II. Zuverlässigkeit und Nachvollziehbarkeit o Der BW DWH Layer ist nicht den Projektbeliebigkeiten unterworfen und wird zentral
administriert. Alle Daten die in BW Data Marts angeboten werden haben den DWH Layer als gemeinsame Quelle.
III. Komplette Historie IV. Konsistenz
o Extraktion, Staging und Integration werden zentral verwaltet o Daten werden nur einmal extrahiert o Redundante Staging Prozesse werden vermieden.
Ein BW Data Warehouse (Layer) ist also das Gedächtnis der Unternehmung, ein dem gesamten Unternehmen gehörendes Repository für Informationen. Der BW Data Warehouse Layer offeriert also ergänzend zu der horizontalen Konsistenz innerhalb des Data Mart Layers ein Art vertikale Konsistenz, die ein Data Mart Layer allein nicht garantieren kann.
2003 SAP AG AND SAP AMERICA, INC. 16
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Vertical Consistency: BW Data Warehouse Layer
Source 1 Source 2 Source 3 Source 4 Source 5
Vertical Consistency:Vertical Consistency:Single Point of Truth Single Point of Truth
BW DWH Layer ODSBW DWH Layer ODS--ObjectsObjects
Transaction / Master Data
InfoCube
CUSTOMER
MATERIAL
CUSTOMER
MATERIALmaster
CUSTOMERmaster
Horizontal Consistency:Horizontal Consistency:Conformed Structures Conformed Structures
BW InfoObjectsBW InfoObjectsmaster datamaster data
CUSTOMER
MATERIAL
InfoCubeInfoCube
Vertical Consistency: BW Data Warehouse Layer
Source 1 Source 2 Source 3 Source 4 Source 5
Vertical Consistency:Vertical Consistency:Single Point of Truth Single Point of Truth
BW DWH Layer ODSBW DWH Layer ODS--ObjectsObjects
Transaction / Master Data
InfoCube
CUSTOMER
MATERIAL
CUSTOMER
MATERIALmaster
CUSTOMERmaster
Horizontal Consistency:Horizontal Consistency:Conformed Structures Conformed Structures
BW InfoObjectsBW InfoObjectsmaster datamaster data
CUSTOMER
MATERIAL
InfoCubeInfoCube InfoCube
CUSTOMER
MATERIAL
CUSTOMER
MATERIALmaster
CUSTOMERmaster
Horizontal Consistency:Horizontal Consistency:Conformed Structures Conformed Structures
BW InfoObjectsBW InfoObjectsmaster datamaster data
CUSTOMER
MATERIAL
InfoCubeInfoCube
Abbildung 10: BW DWH Layer und vertikale Konsistenz An der Fragestellung, wie die Datenablagen des DWH-Layers zu organisieren sind, entzündet sich häufig Streit. Die extrem Positionen reichen von 3NF bis zu denormalisierten star schemas. Wir wollen uns hier nicht festlegen, sondern einen pragmatischen Ansatz vorschlagen: Da der DWH-Layer die Basis für die Versorgung der Data Marts bildet, sollten die Daten so gespeichert werden, dass sie ohne große Aufwände in die Conformed Dimensions und InfoCubes überführt werden können. D.h. komplexe Join-Operationen normalisierter DWH-Objekte auf dem Weg in Data Marts sollten vermieden werden. Es ist also z.B. durchaus legitim im DWH Layer für eine sales-order gemeinsam mit den Positionsdaten auch die Kopfinformationen abzulegen.
W.H. Inmon beantwortet die Frage "What kind of database design is appropriate for a data warehouse?" wie folgt: ‘For a data warehouse, it is always better to have a lightly normalized design. Star schemas fit elsewhere (s. Data Marts t. author). The data warehouse design is not perfectly normalized because a few alterations are made for common usage, such as creating arrays of data when data is always used together, creating a small and selective amount of redundancy where appropriate, merging tables that are commonly used together, and so forth. At the end of the day, a data warehouse design is distinctively normalized. This answer presumes that you know the difference between a data warehouse and a data mart.
Restatement or regeneration of some of these higher levels of information requires that we keep available a detailed historical data store. This should be ‘clean’ (free of errors and conformed to the Data Warehouse master data model) to avoid unnecessary reprocessing of source data.’ (W. H. Inmon, Architecture 2002)
2003 SAP AG AND SAP AMERICA, INC. 17
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
BW sieht für den DWH-Layer keine selbständigen Datenspeicher vor. Transaktionsdaten werden i.R. in ODS-Objekten, Master- und Referenz-Daten entweder in InfoObjekten oder ODS-Objekten gespeichert. Das Handling der Historie wird in BW über Staging Prozesse (Transfer/ Update Regeln) und Staging ODS-Objekte unterstützt.
Customer CustomerGroupA YB Z
Customer Source Activ From Activ To CustomerGroup
A S1 20020101 20020331 XB S1 20020101 99991231 ZA S1 20020401 99991231 Y
Customer CustomerGroupA XB ZA Y
Data MartMaster Data Table
DWH Object
Sourcesystem S11st Load: 20020101
after 2nd Load: 20020401
after 2nd Load: 20020401
2nd Load: 20020401
Abbildung 11: Beispiel - BW Data Warehouse: Historisierung von Stammdaten Die Quellsysteme liefern bei Master Daten i.R. keine versionierten oder historisierten Datenimages; Darüber hinaus werden für Master Daten häufig full-loads angeboten. Wenn die Quellsysteme keine Historisierung anbieten, ist es Sache des BW Staging Prozesses diese Information zur Verfügung zu stellen. Die Verwaltung der Aktivitätszeitscheiben wird von BW DWH InfoObjekten direkt unterstützt. Im Falle von DWH-ODS-Objekten bietet BW die Update-Regel Unterstützung. Genauso ist es Aufgabe des BW im Falle von ‚full-loads’ festzustellen, die geänderten records zu ermitteln. Dies kann mit Hilfe von speziellen Staging-ODS-Objekten geschehen. Diese Aufgaben entfallen, wenn SAP Master Data Management (SAP MDM) historisierte Delta- Images angeboten werden. Das Handling von Transaktionsdaten ist einfacher, solange eine Transaktion nicht erneut bebuchbar ist. Bei änderbaren Transaktionen genügt häufig ein einfacher Zeitstempel nicht, um ein Überschreiben zu verhindern.
2003 SAP AG AND SAP AMERICA, INC. 18
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Customer Dimension Material DimensionA 4712
4713
Customer Material TimeAmount
Company Currency
A 4712 200211 100A 4713 200211 150
Time Dimension200211
Customer Time DocNo Pos MaterialAmount Local
Currency
Amount Company Currency
A 20021107-10am 1 10 4711 100 50A 20021107-3pm 1 10 4712 200 100A 20021107-4pm 2 10 4713 300 150
Customer Time DocNo Pos MaterialAmount Local
CurrencyA 20021107-10am 1 10 4711 100 New bookingA 20021107-3pm 1 10 4712 200 Correction bookingA 20021107-4pm 2 10 4713 300 New booking
Sourcesystem
BW Data Warehouse Layer
daily
weekly dailymonthly
other InfoCubeother InfoCube
BW Architected Data Mart Layer
InfoCube
Abbildung 12: Beispiel - BW Data Warehouse: Transactions Daten Die Datenmengen steigen in einem BW Data Warehouse Layer schnell an. Das BW/ SAP Archiving Development Kid (ADK) bietet die Voraussetzung den Anforderungen des Data Warehouse Layers gerecht zu werden, ohne den Speicherplatzverbrauch ins exorbitante steigen zu lassen: Sind trotzdem große Datenvolumina online verfügbar zu halten, so unterstützt BW die Nutzung von Nearline Storage.
2003 SAP AG AND SAP AMERICA, INC. 19
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
5.2.3 BW Extraktion und Staging Um die Qualität der Daten im BW Data Warehouse Layer zu garantieren sind allgemeingültige Regeln für Extraktion und Staging wichtig. Diese sollen vor allen Dingen redundantes Extrahieren und Transformieren verhindern. Die Nutzung von BW als Basis für das Enterprise Data Warehousing erfordert es, dass jedwede Datenquelle adressiert werden kann. Deshalb bietet BW ein weites Spektrum an Extraktions-Unterstützung:
• Vordefinierte, erweiterbare Extraktoren für nahezu alle SAP Applikationsdaten • Generierbare Extraktoren für kundenspezifische SAP Applikationen wie COPA • Generische Extraktoren für kundenspezifische Erweiterungen von mySAP Applikationen • Direkte Extraktion auf Basis von Tabellen- oder View-Definitionen aus Datenbanken, die von SAP unterstützt werden (BW DB-Connect Feature) • Flat-File Extraktion • Integration mit Ascential’s Datastage • Für BW 3.5 ist geplant alle über JDBC oder ODBO adressierbar Datenquellen verfügbar zu machen
Die meisten Extraktoren von Transaktionsdaten der SAP Applikationen sind deltafähig. Dies wird dadurch erreicht, dass die Transaktionen zur Buchungszeit in eine sogenannte Deltaqueue geschrieben werden. Aus dieser Deltaqueue werden sie dann in das BW extrahiert. Es ist einsichtig, dass sich daraus neben der Deltafähigkeit auch für die BW Szenarios wichtige Gestaltungsmöglichkeiten ableiten, da zur Buchungszeit auch Master Daten Informationen wie Preise mitgesichert werden können. Der erste relevante Datenzustand dessen Persistierung einen Nutzen verspricht ist das Extraktionsergebnis. Diese Rohdaten können 1:1 in der sog. Persistent Staging Area (PSA) gespeichert werden. Die PSA bildet für neu aufgesetzte Staging-Prozesse ein Backup.
StagingStagingArea:Area:PSAPSA
CleansingCleansingTransformTransform
BW Data BW Data WarehouseWarehouse
Extr
actio
n /
Ope
n St
agin
g
BW ODSBW ODSany
sour
ce
StagingStagingArea:Area:PSAPSA
CleansingCleansingTransformTransform
BW Data BW Data WarehouseWarehouse
Extr
actio
n /
Ope
n St
agin
gEx
trac
tion
/ O
pen
Stag
ing
BW ODSBW ODSany
sour
ce
Abbildung 13: BW Staging Welche und ob Zustände zwischen dem Roh- und Integrierten Datenzustand gespeichert werden, muss im Einzelfall entschieden werden. Dies hängt von der Datenqualität und dem Aufwand für eine eventuelle Datenharmonisierung ab. Als Datenspeicher werden BW ODS-Objekte genutzt.
2003 SAP AG AND SAP AMERICA, INC. 20
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
5.2.4 BW Unterstützung des Operational / Real Time Reporting Staging, Data Warehouse und Data Mart Layer beschreiben das ‚klassische’ Data Warehousing. ‚Klassisch’ in dem Sinne, dass die Daten einem genau vorbestimmten Procedere unterworfen werden, um die Qualität und Integrität von Reporting und Analyse zu garantieren. ‚Klassisches Data Warehousing’ heißt aber nicht zuletzt auch, Last von den operativen Systemen fernzuhalten.
The classic data warehousing approach:Dedicated load and staging processesHigh qualityOptimized retrieval structuresReduce workload on OLTP systems
DataMart
Finance
ArchitectedArchitectedData MartsData Marts
DataMart
Logistic Tact
ical
/ St
rate
gic
MasterReference
Data
TransactionData
Data Data WarehouseWarehouse
Extra
ctio
n /
Ope
n St
agin
g
DataMart
Finance
DataMart
Finance
ArchitectedArchitectedData MartsData Marts
DataMart
Logistic
DataMart
Logistic Tact
ical
/ St
rate
gic
MasterReference
Data
TransactionData
Data Data WarehouseWarehouse
MasterReference
Data
TransactionData
Data Data WarehouseWarehouse
Extra
ctio
n /
Ope
n St
agin
gEx
tract
ion
/ O
pen
Stag
ing
Abbildung 14: Klassisches Data Warehousing Neben den klassischen Layern: Staging, Data Warehouse und Data Mart wird häufig ein weiterer Daten-Layer postuliert, das Operational Data Store (ODS). Das Operational Data Store soll das operative Reporting unterstützen, wohingegen Data Marts als Datenstrukturen für taktisches und strategisches Reporting und Analyse gelten. In der Praxis stellt sich die physische Trennung Data Mart - ODS speziell dann als künstlich heraus, wenn operatives Reporting keine sekunden-aktuellen Daten verlangt. Meist ist auch für operatives Reporting ein zwei- bis dreimaliges untertägiges Laden ausreichend oder es reichen sogar tagesaktuelle Daten. Je größer die ‚Latency’, also die zeitliche Differenz zwischen dem operativen Ereignis und der Bereitstellung dieses Ereignisses für Reporting Zwecke ist, desto naheliegender ist es, auch granulare Daten in Data Mart InfoCubes abzulegen und diese sowohl für taktische Analysen, als auch für operatives Reporting zu nutzen. Für reines Anlisten von Daten eignen sich die flachen BW ODS-Objekte besser. In dieser Art und Weise unterstützen schon heute die meisten BW Implementierungen operatives Reporting und entlasten so die operativen Systeme.
2003 SAP AG AND SAP AMERICA, INC. 21
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
In most of the cases operational reporting needs can be supportedin BW using the classic data warehouse process
DataMart
Finance
ArchitectedArchitectedData Marts/ Data Marts/ ODSODS--ObjectsObjects
DataMart
Logistic
Tact
ical
/ St
rate
gic
/ Ope
ratio
nal
MasterReference
DataTransaction
Data
Data Data WarehouseWarehouse
Extra
ctio
n /
Ope
n St
agin
g
ODS-ObjectSales Orders
‘..most of the cases..’: classical data warehousing has its limits if we want to provide event-level or close to event-level operational reporting
(near real time reporting) and/ orif we are confronted with huge data volumes
In most of the cases operational reporting needs can be supportedin BW using the classic data warehouse process
DataMart
Finance
ArchitectedArchitectedData Marts/ Data Marts/ ODSODS--ObjectsObjects
DataMart
Logistic
Tact
ical
/ St
rate
gic
/ Ope
ratio
nal
MasterReference
DataTransaction
Data
Data Data WarehouseWarehouse
Extra
ctio
n /
Ope
n St
agin
g
ODS-ObjectSales Orders
DataMart
Finance
DataMart
Finance
ArchitectedArchitectedData Marts/ Data Marts/ ODSODS--ObjectsObjects
DataMart
Logistic
DataMart
Logistic
Tact
ical
/ St
rate
gic
/ Ope
ratio
nal
MasterReference
DataTransaction
Data
Data Data WarehouseWarehouse
MasterReference
DataTransaction
Data
Data Data WarehouseWarehouse
Extra
ctio
n /
Ope
n St
agin
gEx
tract
ion
/ O
pen
Stag
ing
ODS-ObjectSales Orders
‘..most of the cases..’: classical data warehousing has its limits if we want to provide event-level or close to event-level operational reporting
(near real time reporting) and/ orif we are confronted with huge data volumes
Abbildung 15: Klassisches Data Warehousing unterstützt Operatives Reporting BW unterstützt taktische Analyse und operatives Reporting auf demselben InfoCube durch vorberechnete Aggregate und sog. ‚aggregation awerness’ des Olap-Engines, sowie durch sog. ‚query-caching’. Es sei jedoch darauf hingewiesen, dass das Nutzungsprofil der Daten von Operativen- und Analyse-Nutzern gerade in bezug auf Historie und Granularität unterschiedlich ist. Dies muss bei großen Transaktions-Volumina in der Schema-Modellierung berücksichtigt werden! Bei zeitversetztem, operativem Reporting, welches dem ‚klassischen Data Warehousing’ Pfad folgt, gibt es also keine Notwendigkeit, ein dediziertes BW Operational Data Store zu definieren. Wohl muss man sich aber der möglichen Auswirkungen von Analyse und operativem Reporting auf den gleichen Strukturen bewusst sein. Wird dagegen eine Daten-Aktualität gefordert, die nahe dem Ereigniszeitpunkt im operativen System liegt, so sind dem ‚klassischen’ Pull-Prinzip des BW Data Warehousing Grenzen gesetzt. Man spricht in diesem Fall von ‚real time’ oder ‚near real time operational reporting’. In diesem Fall werden die (in Echtzeit) extrahierten Daten direkt in ODS-Objekte geschrieben, ohne den Data Warehouse Layer zu passieren. Diese Objekte bilden das BW Operational Data Store.
2003 SAP AG AND SAP AMERICA, INC. 22
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 83 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 83
Near Real Time Data Warehousing (Apollo) –BW Operational Data Store
Finance
Logistic Ope
n D
istri
butio
n
SAP Business Information WarehouseSAP Business Information Warehouse
StagingStagingAreaArea
CleansingCleansingTransformTransform
MasterReference
Data
Data Data WarehouseWarehouse
ODSODS
PrimaryPrimaryData Data
ManagementManagement
Extra
ctio
n /
Ope
n St
agin
g
DataDataAcquisitionAcquisition
Data Data DeliveryDelivery
any
targ
et
Ext
ende
d St
ar S
chem
asE
xten
ded
Star
Sch
emas
Flow Control Flow Control
MetaMeta DataData
any
sour
ce TransactionData
ArchitectedArchitectedData MartsData Marts
Abbildung 16: BW Operational Data Store: Near Real Time Data Warehousing Aus Gründen der Datenkonsistenz dürfen Daten aus einem Operational Data Store nicht direkt in den Data Mart Layer prozessiert werden. Werden Daten aus einem ODS in einem Data Mart Szenario benötigt, so ist immer der Weg über das (Enterprise) Data Warehouse zu gehen. Zusammenfassend seien die von BW angebotenen und geplanten Funktionalitäten zur Unterstützung von Real Time Reporting Szenarien genannt: BW Remote InfoCubes – externe InfoCube Fakten-Tabellen
BW erlaubt InfoCubes zu definieren, deren Fakten-Tabelle selbst nicht im BW persistent ist. Zur Query-Laufzeit werden die Daten dann von einem Extraktor gelesen und im BW der ‚normalen’ InfoSource-Behandlung unterworfen, sprich Transfer- und Update-Regeln, um sie dann dem Olap-Prozessor zur Verfügung zu stellen. Alle über von BW adressierbaren Datenquellen können somit externe Fakten-Tabellen zur Verfügung stellen.
BW Virtual InfoCubes – ein Programm verhält sich wie eine Fakten-Tabelle BW ‚Near Real Time Data Warehousing’ (nächstes BW Hauptrelease )
Mit dem nächsten BW-Hauptrelease wird es möglich sein Daten direkt nach dem Entstehungs- oder Änderungsereignis in BW-ODS-Objekte zu ‚pushen’.
Direktes Reporten auf operativen Strukturen (nächstes BW Hauptrelease) Ist keine Integration mit anderen Daten gefordert, so ist auch das Reporten direkt auf operativen Strukturen eine Option. Dieser Option sind jedoch durch die erzeugte Last, fehlende Daten-Integration und Daten-Qualitätskontrolle enge Grenzen gesetzt.
2003 SAP AG AND SAP AMERICA, INC. 23
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 89 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 89
BW and Operational/ Real Time Reporting
Key-Questions:
Data Latency ?Data Integration ?Workload on OLTP Systems ?
Ul
BWBW
OLTP
BW Data IntegrationBW Data Acquisition
BW Near real timedata warehousing
BW ‘classic’data warehousing
BW remoteInfoCube
BW virtualInfoCube
ApolloApollo
Adaptors
JDBC ODBO XMLA SAP Query
Abbildung 17: BW und Operational/ Real Time Reporting .
2003 SAP AG AND SAP AMERICA, INC. 24
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
5.3 Daten Architektur - BW Daten Modell Die BW Layer Architektur beschreibt den Lebenszyklus der Daten vom Event bis zu den retrieval-relevanten Data Mart oder flachen BW-ODS-Objekt Strukturen. Doch eines ist intuitiv klar: persistente Speicher und ihre Speicherschemata allein reichen nicht aus, um ‚controlled redundancy’ zu gewährleisten. Dazu braucht es eines DWH Datenmodells.
5.3.1 Operative Daten Modelle und Data Warehouse Datenmodell Als Basis für ein Data Warehouse Datenmodell dienen die Entity-Relationship Modelle der operativen Anwendungen. Der Idealfall eines unternehmensweiten, operationalen Datenmodells ist selten, so dass sich die Herausforderung ergibt aus einer Vielzahl von operativen Modellen ein konsistentes DWH Datenmodell abzuleiten. Die Situation beschreibt die folgende Graphik:
Not aligned operational data models Consistent enterprise data model
Inconsistent data warehouse data models ⇒stovepipe solutions
Consistent data warehouse data model ⇒long term success
A data warehouse A data warehouse consistency challengeconsistency challenge
Not aligned operational data models Consistent enterprise data model
Inconsistent data warehouse data models ⇒stovepipe solutions
Consistent data warehouse data model ⇒long term success
A data warehouse A data warehouse consistency challengeconsistency challenge
Abbildung 18: Operationale Daten Modelle und DWH Daten Modell Das Erstellen eines unternehmensweiten Data Warehouse Datenmodells auf Basis nicht abgestimmter operativer Datenmodelle ist ein komplexer auch politischer Vorgang. Das ist der Grund dafür, das die DWH Datenmodell Architektur häufig vernachlässigt wird. Das Ergebnis sind nicht integrierte Insellösungen, sogenannte ‚Stovepipe’ Data Marts. Die BW Kunden befinden sich auch in dieser Hinsicht in einer komfortableren Situation. BW bietet als Teil des sog. Business Content ein erweiterbares Data Warehouse Daten Modell, das die operativen Modelle der SAP Applikationen und zu einem hohen Maße der industriespezifischen Lösungen konsistent abbildet. Auch für spezielle Anwendungen aus dem Wettbewerberumfeld (z.B. Oracle Financials) existieren BW Datenmodelle. Für BW Kunden mit einem hohen operativen Abdeckungsgrad durch SAP Applikationen stellt sich also die Situation wie in folgender Graphik dar:
2003 SAP AG AND SAP AMERICA, INC. 25
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
N o t a lig n e d o p e ra tio n a l
d a ta m o d e ls S A P e n te rp ris e d a ta m o d e l
B W C o n s is te n t d a ta w a re h o u se d a ta m o d e l fo rS A P A p p lic a tio n s a n d o th e rs ⇒
lo n g te rm su cce ss
A d a ta w a re h o u s e A d a ta w a re h o u s e c o n s is te n c y c h a lle n g ec o n s is te n c y ch a lle n ge
N o t a lig n e d o p e ra tio n a l d a ta m o d e ls S A P e n te rp ris e d a ta m o d e l
B W C o n s is te n t d a ta w a re h o u se d a ta m o d e l fo rS A P A p p lic a tio n s a n d o th e rs ⇒
lo n g te rm su cce ss
A d a ta w a re h o u s e A d a ta w a re h o u s e c o n s is te n c y c h a lle n g ec o n s is te n c y ch a lle n ge
Abbildung 19: DWH-Datenmodell und die Situation von BW Kunden Ohne dass sich die Kunden dessen häufig bewusst sind, wacht das Datenmodell des BW Business Contents darüber, dass die inkrementell erstellten InfoCube-Lösungen ‚zusammenpassen’. Das ist der Wert des BW Business Contents aus Architektursicht und einer der Gründe für den Erfolg des BW.
5.3.2 Das BW Daten Modell Entitäten und Attribute der operativen Systeme finden ihre Entsprechung in sog. BW InfoObjekten.
Enterprise Data Model:e.g. mySAP Component
Object Models
0MATERIAL
Customer Material Sales Person
Sales Transaction
Materialgroup Sales ORGMaterialType
0MATTYPE
0MATGR
BW Data Model0CUSTOMER
0DOCNO
0SALESPERS
0AMOUNT
0SALESORG
Entities, Attributes ->BW InfoObjects
operative entities and attributes ⇒ BW InfoObjects
Enterprise Data Model:e.g. mySAP Component
Object Models
0MATERIAL
Customer Material Sales Person
Sales Transaction
Materialgroup Sales ORGMaterialType
CustomerCustomer Material Sales Person
Sales Transaction
Materialgroup Sales ORGMaterialType
0MATTYPE
0MATGR
BW Data Model0CUSTOMER
0DOCNO
0SALESPERS
0AMOUNT
0SALESORG
Entities, Attributes ->BW InfoObjects
operative entities and attributes ⇒ BW InfoObjects
Abbildung 20: Enterprise Datenmodell und erweiterbares BW Datenmodell: InfoObjekte
2003 SAP AG AND SAP AMERICA, INC. 26
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
InfoObjekte tragen neben technischen Eigenschaften wie Format und Länge Data Warehousing relevante Eigenschaften:
• Aggregationsverhalten (Kennzahlen) • Standard Anzeige (Kennzahlen) • Textuelle Beschreibung • Sprachenabhängige Beschreibungen • Externe Hierarchien • …
Die Clusterung von operativen Entitäten und Attributen zu subject areas erfolgt durch sog. InfoSources. Es werden Master Daten und Transaktionsdaten InfoSources unterschieden:
Enterprise Data Model:e.g. mySAP Component
Object Models
Enterprise Data Model:e.g. mySAP Component
Object Models
BWData Model defined by
Business Content
BWData Model defined by
Business Content
Customer Material Sales Person
Sales Transaction
Materialgroup Sales ORGMaterialType
CustomerCustomer Material Sales Person
Sales Transaction
Materialgroup Sales ORGMaterialType
BCT InfoSources ≡Subject Areas
Master Data Transaction Data
0MATERIAL 0MATGR 0MATTYPE0MATERIAL 0MATGR 0MATTYPE 0DOCNO 0SALESDAT 0CUSTOMER 0SALESPERS 0MATERIAL 0AMOUNT0DOCNO 0SALESDAT 0CUSTOMER 0SALESPERS 0MATERIAL 0AMOUNT
Clustering operative entities and attributes ⇒ Data Warehouse subject-areas⇒BW InfoSources built of InfoObjects
Abbildung 21: BW Datenmodell: InfoSources und subject areas InfoSources stellen sich also immer als Set von InfoObjekten dar und beschreiben eine Relation zwischen diesen. InfoSources sind die zentrale Brücke zwischen dem operativem und dem BW Datenmodell. Sie haben ihre Entsprechung im operativen System in Form einer sog DataSource, welche
wiederum die Ergebnisstruktur eines Extraktors abbildet. Im BW Data Mart Layer definiert eine InfoSource entweder eine Conformed Dimension (Master
Data InfoSources) oder eine Relation (Transaction Data InfoSource) zwischen Conformed Dimensions also die Basis für InfoCube Schemata.
2003 SAP AG AND SAP AMERICA, INC. 27
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Die Rolle der BW InfoSources mit Blick auf das Data Mart Layer Datenmodell illustriert nachfolgendes Bild:
Enterprise Data Model:e.g. mySAP Component
Object Models
Enterprise Data Model:e.g. mySAP Component
Object Models
0MATERIAL0MATGR0MATTYPE......
BW Data Mart Layer Data Model defined by
Business Content
BW Data Mart Layer Data Model defined by
Business Content
Customer Material Sales Person
Sales Transaction
Materialgroup Sales ORGMaterialType
CustomerCustomer Material Sales Person
Sales Transaction
Materialgroup Sales ORGMaterialType
BCT InfoSources ≡Subject Areas
0SALESPERS0SALESORG.....
0CUSTOMER00CUSTGR......
0CUSTOMER 0MATERIAL 0AMOUNT
Shared/ Conformed DimensionsShared/ Conformed Dimensions InfoCubes with Local DimensionsInfoCubes with Local Dimensions
BCT Extractors/ DataSource
Master Data Transaction Data
0MATERIAL 0MATGR 0MATTYPE0MATERIAL 0MATGR 0MATTYPE 0DOCNO 0SALESDAT 0CUSTOMER 0SALESPERS 0MATERIAL 0AMOUNT0DOCNO 0SALESDAT 0CUSTOMER 0SALESPERS 0MATERIAL 0AMOUNT
BW Extended Star SchemasBW Extended Star Schemas
Abbildung 22: BW Datenmodell: Data Mart Layer Daten Modell Im BW (Enterprise) Data Warehouse definiert eine Master Data InfoSource und zusätzliche
Zeitscheiben- oder Zeitstempel-Attribute die Data Warehouse ODS-Objekte, die so die verschiedenen Versionen einer Subject-area speichern können, welche über die Zeit auftreten. Da Zeitscheiben- oder Zeitstempel i.R. nicht von den Datenquellen angeboten werden, müssen diese während des Stagings in Transfer/ Update Regeln bereitgestellt werden. Transaktions-InfoSources beschreiben als Daumenregel die Data Warehouse ODS-Objekte für Transaktionsdaten. (s. folgendes Bild):
2003 SAP AG AND SAP AMERICA, INC. 28
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Enterprise Data Model:e.g. mySAP Component
Object Models
Enterprise Data Model:e.g. mySAP Component
Object Models
BW Data Warehouse Layer Data Model defined by
Business Content
BW Data Warehouse Layer Data Model defined by
Business Content
Customer Material Sales Person
Sales Transaction
Material group Sales ORGMaterial Type
CustomerCustomer Material Sales Person
Sales Transaction
Material group Sales ORGMaterial Type
BCT InfoSources ≡Subject Areas
BCT Extractors/ DataSource
Master Data Transaction Data
0MATERIAL 0MATGR 0MATTYPE0MATERIAL 0MATGR 0MATTYPE 0DOCNO 0SALESDAT 0CUSTOMER 0SALESPERS 0MATERIAL 0AMOUNT0DOCNO 0SALESDAT 0CUSTOMER 0SALESPERS 0MATERIAL 0AMOUNT
+ Insert Timestamp/ Activity Time Slice
+ Source
EDW InfoObject/ ODS-Object ODS-Object
If Overwrite:Unique Identifier
+Source
Abbildung 23: BW Datenmodell: Data Warehouse Layer Daten Modell Für die SAP Komponenten bietet der BW Business Content ein vordefiniertes erweiterbares Datenmodell bestehend aus InfoObjekten und InfoSources. Dieses Datenmodell beschreibt den BW Data Mart Layer und ergänzt um Zeitscheiben auch den BW Data Warehouse Layer. Wird das Business Content Datenmodell für mySAP Komponenten durchgängig genutzt, so können Data Mart InfoCube Szenarios für einen bestimmten Themenbereich aufbaut werden, ohne Insellösungen zu erzeugen.
2003 SAP AG AND SAP AMERICA, INC. 29
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
5.4 Topologien – BW Landschaften Topologie-Aspekte eine BW Architektur stehen häufig im Vordergrund des Interesses. Die Gründe hierfür sind u.a.:
kurzfristiger Optimierungsbedarf bereits existierender BW Landschaften parallele Einführung von BW und R/3 oder einfach eine frühzeitige Konzentrierung auf Kostengesichtspunkte
Nach der Diskussion in den vorhergehenden Kapiteln ist jedoch klar, dass eine Fokussierung allein auf Landschaftsaspekte oberflächlich und keineswegs allein zielführend ist, ohne Strategien zu entwickeln hinsichtlich der persistenten Layer und ihrer Datenmodelle. Wenn hierüber jedoch Klarheit besteht ist es Zeit die Frage zu beantworten: Wie sieht die ideale BW Landschaft für meine Unternehmung aus?
‘Local’BW
‘Local’BW
‘Local’BW
GlobalBW
OutsideOutside--ININBWBW
LandscapeLandscape
Others
‘Local’BW
‘Local’BW
‘Local’BW
GlobalBW
OutsideOutside--ININBWBW
LandscapeLandscape
Others
EnterpriseBW
InsideInside--OutOutBWBW EnterpriseEnterprise
DataDataWarehouseWarehouse Spoke
BW
SpokeBW
Others
SpokeBW
EnterpriseBW
InsideInside--OutOutBWBW EnterpriseEnterprise
DataDataWarehouseWarehouse Spoke
BW
SpokeBW
Others
SpokeBW
The Ideal Corporate BW Landscape ?
Strategic Corporate Implementation Options:Strategic Corporate Implementation Options:
Abbildung 24: Die ideale unternehmensweite BW Landschaft? In dieser Hinsicht müssen wir Sie enttäuschen:: Es gibt keine ‘one size fits all’ BW Landschaft Natürlich gibt es Lösungen, die in Hinsicht auf Konsistenz anderen zu bevorzugen sind, aber häufig verhindern unternehmensspezifische Umstände eine solche Lösung Entscheidungen zur BW Landschaftsarchitektur und letztlich zu allen Architekturaspekten finden in folgenden Spannungsfeldern statt:
2003 SAP AG AND SAP AMERICA, INC. 30
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 109 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 109
Enterprise-wide Strategies
Inside-Out versus Outside-InCentral Data Hub, Local Spokes
Local Hubs, central aggregation
Centralized versus DecentralizedLow dispersal, high centralization
High dispersal, low centralization
High dispersal, high centralization
Global Integrations versus Local ResponsivenessGlobal scale
Global standardization
Global demand
Local customer needs
Local market conditions
Local governmental regulations
“Select the [IT] approach thatfits most closely with corporate strategy”
Prof. Sethi, University of TexasInformation&Management, 2/01
Abbildung 25: Unternehmensweite Strategien und BW Architektur Weitere entscheidungsrelevante Parameter sind:
• Master Daten Integrations-Status und Strategie • Inwieweit ist ein Bewusstsein über die wichtige Rolle von konsistenten Informationen
vorhanden? • Budget • Sponsorship • IT Strategie - Operative System Landscape • Wettbewerbssituation
Grundsätzlich sollte folgender Ratschlag befolgt werden: “Select the [IT] approach that fits most closely with corporate strategy” (Prof. Sethi, University of Texas Information&Management, 2/01) Oder um es mit anderen Worten zu sagen: Eine unternehmensweiten BW Enterprise Data Warehousing Strategie wird kaum erfolgreich sein, wenn sie im Widerspruch zu der Unternehmenskultur steht.
5.4.1 Konsistenz in einer verteilten BW Landschaft Häufig wird die unternehmensweite BW Landschaft aus mehreren BW Instanzen und eventuell auch externen Data Warehouse Tools bestehen. Neben den generellen Entscheidungen, welche die Konsistenz in einem BW Layer und zwischen den Layern garantieren, müssen Regeln festgelegt werden, wie in einer verteilten Data Warehouse Landschaft die Konsistenz der Daten und Metadaten gewährleistet werden soll. BW unterstützt derartige verteilte (BW) Landschaften durch eine Vielzahl von Funktionalitäten:
2003 SAP AG AND SAP AMERICA, INC. 31
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
• Daten-Konsistenz Die Verteilung der Daten in einer solchen Landschaft muss kontrolliert (Delta-Handling) erfolgen. Dies wird garantiert durch die BW Funktionalitäten
o Data Mart Interface (BW-BW Datenverteilung) o Open Hub Service (BW-Third Party Datenverteilung)
• Meta-Daten Konsistenz Dies wird über die BW Entwicklungsumgebung und das BW Metadaten Transport Interface (XML für 3rd-party) realisiert und kontrolliert.
• Daily Operations Durch Partnerschaften mit Herstellern von Rechenzentrumsautomatisierungstools ist es garantiert, dass Datenverteilungs-Prozesse (BW Process Chains) in BW Landschaften von einem Punkt aus kontrolliert und geplant werden können
Diese Funktionalitäten sind von Bedeutung gleichwelche BW Landschafts-Architektur gewählt wird.
5.4.2 BW Landschaften und Technische Parameter Diverse technische Parameter nehmen Einfluss auf die Entscheidung, welche BW Landschaft sich für eine Unternehmung eignet. • Geographische Verteilung der Nutzer
Im Extremfall verteilen sich die Nutzer über den gesamten Globus. Die Herausforderungen, die sich hieraus ergeben illustriert die folgende Graphik:
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 114 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 114
Availability and Maintenance
Availability and Maintenance24 x 7 Access
Performance impacts
Data actuality
Data backup, repair and recovery
System upgrades and maintenance
Zero Downtime B r u s s e l s L . A . T o k y o R e p o r t i n g T i m e
1 2 a m 3 p m 8 a m
2 a m 5 p m 1 0 a m
4 a m 7 p m 1 2 p m
6 a m 9 p m 2 p m
8 a m 1 1 p m 4 p m
1 0 a m 1 a m 6 p m
1 2 p m 3 a m 8 p m
2 p m 5 a m 1 0 p m
4 p m 7 a m 1 2 a m
6 p m 9 a m 2 a m
8 p m 1 1 a m 4 a m
1 0 p m 1 p m 6 a m
B r u s s e l s L . A . T o k y o R e p o r t i n g T i m e
1 2 a m 3 p m 8 a m
2 a m 5 p m 1 0 a m
4 a m 7 p m 1 2 p m
6 a m 9 p m 2 p m
8 a m 1 1 p m 4 p m
1 0 a m 1 a m 6 p m
1 2 p m 3 a m 8 p m
2 p m 5 a m 1 0 p m
4 p m 7 a m 1 2 a m
6 p m 9 a m 2 a m
8 p m 1 1 a m 4 a m
1 0 p m 1 p m 6 a m
B r u s s e l s R e p o r t i n gF r 4 p m
8 p m
S a 1 2 a m
4 a m
8 a m
1 2 p m
4 p m
8 p m
S u 1 2 a m
4 a m
8 a m
1 2 p m
4 p m
8 p m
M o 1 2 a m
4 a m
8 a m
1 2 p m
B r u s s e l s R e p o r t i n gF r 4 p m
8 p m
S a 1 2 a m
4 a m
8 a m
1 2 p m
4 p m
8 p m
S u 1 2 a m
4 a m
8 a m
1 2 p m
4 p m
8 p m
M o 1 2 a m
4 a m
8 a m
1 2 p m
Abbildung 26: BW Landschaft und Verfügbarkeit/ Wartung • Sprachen unterschiedlicher Codepages sind zu unterstützen
2003 SAP AG AND SAP AMERICA, INC. 32
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
BW ist Unicode fähig. Konkrete Lösungsszenarien müssen mit dem BW Produktmanagement abgestimmt werden.
5.4.3 Inside-Out Landschafts- Architektur - BW als Zentrales Enterprise Data Warehouse Unternehmensweite konsistente Informationen lassen sich sicherlich am ehesten garantieren, wenn es eine zentrale BW Instanz gibt, die Data Warehouse Layer Services anbietet, d.h. also unternehmensweite Zusammenführung aller relevanten Daten in granularer, integrierter, nicht-volatiler, unflavored und subject-oriented Form. Diese Lösung propagiert William H. Inmon in der Corporate Information Factory.
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 111 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 111
BW as Central Enterprise Data Warehouse (EDW)
BW Enterprise Data Warehouse:BW Data Warehouse layer as ‘single point of truth’ for the entire corporation
EnterpriseBW
BW EnterpriseBW EnterpriseDataData
WarehouseWarehouseScenarioScenario
SpokeBW
SpokeBW
Abbildung 27: BW als Corporate Information Factory Alle Daten, die als Basis für taktische und strategische Data Marts dienen, müssen das Enterprise Data Warehouse passieren. Ein Extrahieren am EDW vorbei in Data Marts ist nicht zulässig. Ausnahmen müssen kontrolliert werden. Eine Strategie zur Nutzung solcher Data Marts als Basis für operatives Reporting als auch die Nutzung des EDW selbst für operatives Reporting muss vorliegen. Eine solche Landschaft mit ihrem innewohnenden Ansprüchen:
• „Single point of truth” und • “extract once deploy many”
bietet also ideale Voraussetzungen, um auf Unternehmensebene, Redundanz zu kontrollieren. Dieser Lösung wird häufig unterstellt, dass sie zwar ideal, aber praktisch nicht realisierbar ist. Ohne die Argumente im Detail diskutieren zu wollen, lässt sich feststellen, dass dies für BW Kunden nicht notwendig der Fall ist.
2003 SAP AG AND SAP AMERICA, INC. 33
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
So haben große, global operierende Unternehmen häufig bereits ein großes Investment getätigt, um ihre operative Landschaft durch Einführung von SAP R/3 zu vereinheitlichen. Als Ergebnis dieser Aktivitäten finden wir ideale Voraussetzungen für einen zentralen Enterprise Data Warehouse Ansatz: Integration der Daten (common coding), Integration der Datenmodelle in das SAP R/3 Datenmodell, Aufbau einer operativen R/3 Landschaft, welche die organisatorischen und technischen Gegebenheiten im Unternehmen berücksichtigt. D.h. also ein zentralistischer Ansatz in der operativen Welt führt direkt zu dem BW Enterprise Data Warehouse Topologie Ansatz als Lösungsoption. Eine solche ‚ideale’ Welt finden wir häufig in ‚single Division’ Unternehmen in starker Wettbewerbssituation und daraus folgendem hohen Bewusstsein für den Nutzen zuverlässiger und effizienter IT-Lösungen. Dieses Bewusstsein geht meist mit einem hohen Maß an Unterstützung von höchster Management-Ebene für eine solche BW EDW Lösung einher.
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 110 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 110
Inside-Out: Central BW Instance Covers All
BW EDWBW EDW
BW Architected Data MartsBW Architected Data Marts
tactical/operational like
reporting
strategicreporting
integratednon-volatile
no flavor
Inside-Out:Central EDW BW Instance Covers All
rr
PSAPSA
Stag
ing
Area
EnterpriseBW
BW EnterpriseBW EnterpriseDataData
WarehouseWarehouseScenarioScenario
SpokeBW
SpokeBW
BW ODSBW ODSoperational/ near real time
reportingr
ExternalExternal Data MartsData Marts
aggregatedless granulagranula
granula
Abbildung 28: Skalierbarkeit einer BW Corporate Information Factory I Aus Kostengründen wird man eine BW Enterprise Data Warehouse basierte Landschaft inkrementell implementieren. Zu Beginn wird man also eine BW Instanz aufbauen, die sowohl Data Warehouse Layer als auch Data Mart Layer Services inklusive operativ nahem Reporting anbietet. Selbstverständlich muss es das Ziel einer Enterprise Data Warehousing Strategie sein, dass auch alle externen Data Marts ihre Daten nur aus dem BW EDW beziehen! Mit zunehmender Last ist dann eine Abspaltung der Reporting und Analysis Services möglich.
2003 SAP AG AND SAP AMERICA, INC. 34
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 112 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 112
Inside-Out: Central EDW BW Instance and BW Spoke Instances
EnterpriseBW
BW EnterpriseBW EnterpriseDataData
WarehouseWarehouseScenarioScenario
SpokeBW
SpokeBW
BW EDWBW EDW
integratedconsistent
Inside-Out:Central EDW BW Instance as Information HUBArchitected Data Marts Spoke Instances
r
strategicreporting
Corporate BWCorporate BWData Mart Data Mart
r
PSAPSA
Stag
ing
Area tactical/
operational likereporting
BW ODSBW ODSoperational reporting
r
BW OBW Ooperational reporting
granular
PSAPSA
BW Architected Data MartsBW Architected Data Marts
tactical/operational like
reporting
r
ri
BW ODSBW ODSoperational/ near real time
reportingr
ExternalExternal Data MartsData Marts
granula
agg egated
granula
DSDS
less granula
aggegaton
granula
Abbildung 29: Skalierbarkeit einer BW Corporate Information Factory II Zusammenfassend sei gesagt, dass die Bedingungen für eine zentrale BW Enterprise Data Warehouse Lösung immer dann günstig sind, wenn es sich um eine ‚single division company’ mit starker Zentrale handelt.
5.4.4 Outside-In Landschafts Architektur - Dezentrale BW Data Warehouses
Auch wenn es wünschenswert ist ein einziges BW Enterprise Data Warehouse für die gesamte Unternehmung zu haben, so führt doch die Komplexität der unterschiedlichen Geschäftsbereiche eines global operierenden Unternehmens zu verteilten BW Landschaften. William H. Inmon meint dazu:
‘Simply building a central single data warehouse does not address the size and complexity of the problem posed by the need for integrated, historical easily accessible data across a complex global enterprise.’ W.H. Inmon ‘Managing Multiple Data Warehouse Development‘
Häufig führen auch politische Umstände oder ein fehlendes Gesamtkonzept des Unternehmens zu verteilten BW Landschaften, selbst wenn die Gegebenheiten von Seite des Business her günstig erscheinen.
Generell ist bei diversifizierten Unternehmen zu prüfen, ob der Aufwand die Daten auf granularer Ebene zu integrieren, wie beim EDW-Ansatz gefordert nicht größer ist als der Nutzen. Doch selbst wenn ideale Voraussetzungen vorliegen wie etwa eine ‚single division’ Unternehmung, können Umstände wie etwa bei einer regionalen Unternehmens-Struktur ohne Prozessinteraktion zwischen den Regionen zusammen mit technischen und politischen Faktoren dazu führen, von dem zentralen BW EDW Konzept abzuweichen.
2003 SAP AG AND SAP AMERICA, INC. 35
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Dies führt dann zu einer Landschaft mit mehreren ‚lokalen’ BWs, wobei lokal nur besagt, dass ein solches BW nur Teile der Organisation abdeckt. Die Beschreibung, was ‚lokal’ im Einzelfall bedeutet hängt von der Größe und Komplexität einer Unternehmung ab. Jedes ‚lokale’ BW sollte für seinen Bereich wie ein Enterprise Data Warehouse wirken. So bildet die Summe der ‚lokalen’ Enterprise Data Warehouses ein quasi virtuelles EDW. Im Unterschied zum zentralen EDW, welches ja Integration auf granularer Datenebene für alle Daten der Unternehmung fordert, ist dies für die ‚lokalen’ EDWs untereinander wünschenswert, aber nicht notwendige Voraussetzung, d.h. jedes ‚lokale’ EDW stellt notwendig eine ‚lokale’ granulare Daten Integration sicher. Der Landschaftsarchitektur basierend auf ‚lokalen’ BWs bedeutet, dass für übergreifendes Reporting und Analyse mindestens eine weitere Integrationsschicht notwendig ist, um die Daten aus den ‚lokalen’ BWs zusammenzuführen. Ein BW, das die Daten anderer BWs zusammenführt und in integrierter Form anbietet, heißt ‚globales’ BW. Wobei auch hier der Begriff ‚global’ und die Reichweite eines solchen BWs unternehmensspezifisch bestimmt werden muss.
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 128 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 128
Architected Multiple BW Landscape
Divisional
Global
BWBW Europe
LocalR
egional Data Warehouse
ODSData Marts
Global BW Global BW Division AA
Global BWGlobal BWHeadquarter
R/3-ERPAmericas I
R/3-ERPAsia
R/3-ERPEurope I
mySAPCRM
Staging
BWBW Americas
Data Warehouse
ODSData Marts
Staging
R/3-ERPAmericas II
BWBW Asia
Data Warehouse
ODSData Marts
Staging
virtualBW Enterprise
Data WarehouseStaging
Abbildung 30: ‘Lokal - Global’ BW Landschaft Wichtig in Hinblick auf die Daten-Integrationsstrategie eines Unternehmens ist, dass die Harmonisierung der Stammdaten i.R. auf aggregierter Ebene erfolgt.1
1 Eine Integration ist so erst auf höheren Hierarchiestufen einer ‚subject area’ oder Dimension gefordert, was in der Regel leichter zu erreichen ist, als auf granularer Ebene. Damit ist eine solche Topology häufig auch ein Spiegelbild für die Integrationstategie eines Unternehmens, dass nicht auf granulares ‚common coding’ setzt.
2003 SAP AG AND SAP AMERICA, INC. 36
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Ein solches ‚globales’ BW ist also immer ein Integrator. Die Situation der ‚lokalen’ BWs oder auch Legacy-Systeme bestimmt hierbei den Integrationsaufwand: 1. ‚lokale’ BWs sind zu integrieren
I. Das ‚globale’ BW hat die Aufgabe, die Daten aus den ‚lokalen’ BWs zusammenzuführen (Datenwerte sind bereits ‚common coded’, Datenmodelle lokal-global sind integriert, d.h. Datenmodell-Architektur existiert)
II. Das ‚globale’ BW hat die Aufgabe, die Daten zusammenzuführen und zu harmonisieren (mapping) (Datenwerte sind nicht ‚common coded’, Datenmodelle lokal-global sind integriert, d.h. Datenmodell-Architektur existiert)
III. Das ‚globale’ BW hat die Aufgabe, die Daten zusammenzuführen und zu harmonisieren (mapping) und die Datenmodelle lokal-global zu integrieren. (D.h. eine Datenmodell-Architektur existiert nicht bzw. wird nicht kontrolliert, so dass Aussagen über die Modell-Konsistenz nicht ohne Einzelprüfung zu machen sind.)
2. ‚lokale’ BWs und Legacy-Systeme sind zu integrieren I. Für die Legacy-Systeme ist eine Daten und Daten-Modell-Integration notwendig.
Diese Szenarien sind das Abbild unterschiedlicher corporate DWH Strategien. Der wesentliche Unterschied besteht darin, ob ‚lokale’ und ‚globale’ BWs nach gemeinsamen Architektur-Richtlinien entwickelt werden (Szenario 1.I + 1.II ). In diesem Fall kann man von einer ‚Architected Outside-In BW Landscape’ sprechen. Dieses harmonisierte architektur-basierte Zusammenspiel von lokalen und globalen BW Instanzen ist bei Neuaufbau einer BW basierten corporate DWH Strategie eine wesentliche Option, es wird durch ein zentrales Development von BW-Templates für ‚lokales’ Reporting und Analyse unterstützt.
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 139 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 139
Architected Multiple BW Landscape: BW Template Roll-Out
Divisional
Global
BWBW Europe
LocalR
egional Data Warehouse
ODSData Marts
Global BWGlobal BWHeadquarter
R/3-ERPAmericas I
R/3-ERPAsia
R/3-ERPEurope I
mySAPCRM
Staging
BWBW Americas
Data Warehouse
ODSData Marts
Staging
R/3-ERPAmericas II
BWBW Asia
Data Warehouse
ODSData Marts
Staging
virtualBW Enterprise
Data WarehouseStaging
Architected Multiple BW Landscape: BW Template Roll-Out
R/3 templateroll-out
BW templateroll-out
Global BW Global BW Division AA
Abbildung 31: Architektur-basierte BW Landschaft und BW Templates
2003 SAP AG AND SAP AMERICA, INC. 37
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Haben wir es jedoch mit einer gewachsenen BW Landschaft zu tun, so wird man sich wahrscheinlich in Szenario 1.III und in Szenario 2 wiederfinden.Es gibt offensichtlich nur eingeschränkt eine corporate Strategie für ‚lokale’ BWs, und das ‚globale’ BW hat die Aufgabe einen ersten Schritt in Richtung auf eine solche corporate Strategie zu gehen. (‚Catch the BWs Scenario’).
BWlocal
BWlocal
ERP/ Legacy
othersothers
BW GlobalBW Global
ERP/ Legacy Legacy/ Files
BWlocal
BWlocal
Focus on Integration andHeadquarter Reporting
→ Global BW as the Corporate Integrator
BWlocal
BWlocal
ERP/ LegacyERP/ Legacy
othersothers
BW GlobalBW Global
ERP/ LegacyERP/ Legacy Legacy/ FilesLegacy/ Files
BWlocal
BWlocal
Focus on Integration andHeadquarter Reporting
→ Global BW as the Corporate Integrator
Abbildung 32: Global BW als Integrator
2003 SAP AG AND SAP AMERICA, INC. 38
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
6 Zentrale BW Anwendungsentwicklung Neben dem Bedarf nach konsistenten Informationen auf allen organisatorischen Ebenen ist die Vermeidung von redundanter Anwendungsentwicklung (Data Marts) ein Motor für eine unternehmensweite BW Strategie.
Redundante Anwendungsentwicklung ist stets eine Gefahr für die Konsistenz der Daten. Die redundante Anwendungsentwicklung geht häufig mit einer gewissen Beliebigkeit in der Handhabung von persistenten Datenspeichern und des BW Datenmodells einher.
Der allgemeine Lösungsansatz ist die zentrale Entwicklung von Applikationen sog. Templates für alle Organisationseinheiten einer Unternehmung.
Unternehmensspezifisch ist jeweils, in welchem Maße auf ‚lokaler’ Ebene Applikationen (sog. lokal-lokal Applikationen) erstellt und/ oder corporate Templates lokal adaptierbar sind. Symptomatisch ist, dass die Entscheidung hierüber mehr von politischen, als von funktionalen Gesichtspunkten geprägt ist.
Zwei Extrempositionen zeichnen sich hinsichtlich der lokalen Handhabung desTemplates aus:
• Stabiles Template
Keinerlei lokale Veränderungen an dem zentralen Template sind erlaubt
• Beispiel Template
Das zentrale erstellte Template dient lediglich als Beispiel bzw. Vorlage
Eines ist unmittelbar einsichtig: Je weniger Veränderungen am zentralen Template erlaubt sind, desto einfacher die zentrale Weiterentwicklung und Wartung und desto besser für die Gesamtkonsistenz des BW.
Die Beschreibung des Szenarios ‚Stabiles Template’ klingt sehr rigide. Dies stimmt nur bedingt, denn es passt sehr gut in dieses Szenario lokal sog. Power-Usern, die Erstellung von BW Queries auf InfoProvidern und MultiProvidern2 des Templates zu erlauben. So ist es also möglich, lokal virtuelle multi-dimensionale und flache Strukturen, lokale KPIs, Selektionen, Layouts .... zu definieren.
Bei dem ‚stabiles Template’ Szenario wird das Template in Form der aktiven Version der Template Meta Daten (A-Versionen) transportiert.
Wird zusätzlich zur zentralen eine lokale Applikationsentwicklung angestrebt, so bedeutet dies i.R. auch, dass lokale Entwicklungssysteme existieren. Wird in einem solchen Umgebung ein zentrales Template verändert, so führt ein erneutes Einspielen einer neuen Version des zentralen Templates in der A-version (s. oben) zum Überschreiben der lokalen Anpassungen.
Um dieses Szenario zu unterstützen, wird ab BW Version 3.5. die Erstellung eines sog. Kunden-Content ermöglicht.
Dies erlaubt es wie beim SAP Business Content, Meta Objekte in einer sog. D-Version zu erstellen und zu transportieren. Eine Einspielen im lokalen Zielsystem lässt die existierenden aktiven Meta Objekte unberührt. Erst das aktivieren der D-Version Meta Objekte führt zu einem Abmischen mit den existierenden Objekten. Bei Konflikten muss dann lokal entschieden werden wie zu verfahren ist.
2 InfoProvider: InfoCubes, ODS-Objekte; Multiprovider: Union auf InfoCubes und/oder ODS-Objekte
2003 SAP AG AND SAP AMERICA, INC. 39
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 149 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 149
Content Delivery at the Customer Site
M(odified)
create
A(ctive)
activate
11
11
change
11
1122
Customer Content System (Headquarter)
Export (D Object)
import
M(odified)
A(ctive) 11
change
11
11
44
Subsidiary
Content activation
D(elivery)
1111
11 11 11
Abbildung 33: BW Customer Content Ist eine lokale Adaptierbarkeit des zentralen Templates erlaubt, so kommt auf lokaler Seite eine weitere Art von persistenten Datenspeichern hinzu, die sog. ‚distilled data’. Dieses sind Datenspeicher (i.R. ODS-Objekte), deren Struktur und Art der Befüllung lokal nicht verändert werden darf, da sie der Bereitstellung von Daten für das übergreifende ‚globale’ Reporting dienen. Diese Rolle kann das zentrale Template nicht mehr erfüllen, wenn es lokal veränderbar ist.
Die verschiedenen Struktur in einer ‚lokalen’ BW Installation zeigt das folgende Bild.
Local BW Data Structures
corporate
local
distilled
source for source for corporate reportingcorporate reporting
standardized corporatecorporatedefined
local reporting
local definedlocal definedlocal reportinglocal reportingLocal BW
Data Structures
corporate
local
distilled
source for source for corporate reportingcorporate reporting
standardized corporatecorporatedefined
local reporting
local definedlocal definedlocal reportinglocal reporting
Abbildung 34: BW Customer Content
2003 SAP AG AND SAP AMERICA, INC. 40
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
7 Daten und Daten Modell Integration Integration ist das zentrale Thema aus Corporate Sicht. Im Data Warehouse Bereich geht es vornehmlich um die Integration von Daten unterschiedlicher Quellen und die Integration von Datenmodellen unterschiedlicher operativer Komponenten. Das Thema Datenintegration im BW adressiert direkt das Thema Master Daten Management und die Lösung SAP MDM (Master Data Management).
7.1 Herausforderungen bei der Datenintegration Laut Definition stellen sowohl der Data Warehouse Layer als auch der Data Mart Layer integrierte Daten zur Verfügung. Aber Daten Integration aus Unternehmenssicht ist leichter gesagt als getan, bedeutet doch die Integration von Daten aus unterschiedlichen Datenquellen häufig die größte Herausforderung.3 In Enterprise DWH-Szenarios ist Datenharmonisierung also eher das Ziel als der aktuelle Zustand. Und selbst wenn alle operativen Systeme ‚common-coded’ Daten liefern, muss doch immer damit gerechnet werden, dass durch Akquisitionen von Unternehmen zukünftig auch nicht-integrierbare Daten geliefert werden. Daraus ergibt sich, dass im BW zur Ladezeit nicht-integrierbare Daten gespeichert werden müssen. Ein rechtzeitiges Erkennen einer solchen Situation ist essentiell. Dazu muss der Status der Master Daten aufgenommen werden und die unternehmensweite Datenharmonisierungs-Strategie berücksichtigt werden. Dies ermöglicht es spätere Datenharmonisierungen, ohne Anpassungen handhaben zu können. Lassen sich die Daten nicht integrieren, so müssen diese separiert werden, um gegenseitiges Überschreiben zu verhindern.
3 Die Datenharmonisierung stellt bei begrenzten BW Implementierungen häufig nicht das zentrale Thema dar. Doch spätestens mit dem Einsatz von BW als enterpriseweite Data Warehouse Lösung stößt man auf die Aufgabe Daten zu harmonisieren.
2003 SAP AG AND SAP AMERICA, INC. 41
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Not Common Coded Source-Keys as BW-keys *>> Introducing new Sources later
0MATERIAL TextM1 PIPESS2 CONSULTING
0MATERIAL Date QuantityM1 20020601 100S2 20020601 200
M1 20020601 100 M1 PIPES M1 PUMPS2 20020601 200 S2 CONSULTING S22 CONSULTING
InfoCube Fact-table
Conformed Dimension/InfoObject Master Data
Transaction Data Master Data
R/3-1 R/3-2
Later Introduction of Sourcesystem
?
BW-KEY
BW-KEY
* the technical BW implementation is more sophisticated - the key issue exist anyhow
Master Data
Abbildung 35: Source-System Schlüssel als BW-Schlüssel ? BW bietet mehrere Möglichkeiten eine solche Situation zu beherrschen. Zum einen können für die unterschiedlichen nicht integrierbaren operativen Systeme in BW über Namensräume unterschiedliche Datenmodelle gepflegt werden. Dies führt automatisch auch zu einer Trennung der Datenspeicher. Ein solcher Ansatz ist für eine Unternehmung nicht zu empfehlen. Es ist jedoch eine Option für Application Center, die BW-Dienstleistungen für unterschiedliche Unternehmungen anbieten. Erscheint eine Separierung der Daten durch unterschiedliche Datenmodelle in den seltensten Fällen angebracht, so sind die Daten in den durch ein gemeinsames Datenmodell definierten Datenstrukturen zu trennen. Dies geschieht durch eine Erweiterung der Schlüsselstruktur der betroffenen BW InfoObjekte durch einen sog. Separator. Im einfachsten Fall enthält dieser Separator eine Herkunftsinformation (Quellsystem). BW unterstützt die Trennung durch Concatenieren bzw. Compounden.
2003 SAP AG AND SAP AMERICA, INC. 42
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
ConcatenationBW-Key
Concatenated-Key
Separator Text
U1004711 U1 AUDIU2004711 U2 BMW
U1 U2
004711 AUDI 004711 BMW
Source-System 1 Source-System 2
Build Key Build Key
Separator
Source-Value
Abbildung 36: Schlüsselwert Concatenation Concatenation bedeutet, dass das Datenmodell nicht beeinflusst wird. Es findet lediglich eine Erweiterung der Schlüsselwerte um den Separator statt. Dies kann in BW zentral über allgemeine Transfer-Regeln geschehen. Es handelt sich also hierbei um eine vom Benutzer beeinflussbare und auch später anpassbare Trennung.
Beim Compounden hingegen werden für die betroffenen InfoObjekte die Schlüsselspalte um eine Sourcesystemspalte erweitert. Dies ist pro InfoObjekt einstellbar und wird automatisch von BW versorgt. Das Trennen wird also von BW und Datenbank gehandhabt, was den Nachteil hat, dass es später (z.B. nach erfolgter Integration) nicht wieder entfernt werden kann.
Bei komplexen heterogenen Integrationsszenarien hat das Compounden darüber hinaus funktionale Grenzen und ist durch den Automatismus unflexibel, so dass wir das Konkatenieren favorisieren.
Die Nutzung von InfoObjekt Master Data Navigationsattributen (Attributen der Conformed Dimension) in Queries statt der Concatenierten InfoObjekten selbst ermöglicht nach einer Migration ein Realignment zu den Common Coded Werten und macht damit eine Anpassung der Queries obsolet. Dies zeigt das nächste Bild:
2003 SAP AG AND SAP AMERICA, INC. 43
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
0MATERIAL Separator IMATERIAL Text
S1004711 S1 00000123 AUDIS4004711 S4 00000456 BMW00000123 00 00000123 AUDI00000456 00 00000456 BMW
Date 0MATERIAL Amount20020930 S1004711 10020020930 S4004711 20020021001 00000123 300 Query results after migration 20021001 00000456 400
Text 0MATERIAL 2002AUDI S1004711 100BMW S4004711 200AUDI 00000123 300BMW 00000456 400
Text IMATERIAL 2002AUDI 00000123 400BMW 00000456 600
Query access
Group-IDConcatenated-
Key
entries before migration
entires after migration
realigned material numbers after migration
InfoCube Fact Table
Power of BW Navigational Attributes
Abbildung 37: Navigations-Attribute erhalten die BW-Lösungen flexibel
7.2 Daten Modell Integration Unterschiedliche SAP Komponenten wie R/3 und EBP (Enterprise Buyer Professional) aber vor allen Dingen 3rd-Party- und Legacy-Applikationen haben unterschiedliche Semantiken z.B. für den Produktbegriff. Dies führt in BW zu unterschiedlichen Produkt- subject areas, d.h. InfoObjekten. Diese unterschiedlichen Produktsichten werden durch sog. Consolidated InfoObjects wieder zusammengeführt.
SAP AG 2003, Corporate Data Warehousing based on SAP BW, J. Haupt 44 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 44
IS: Material IS: Service IS: BBP Prod
0CRM_PROD
IS: CRM Prod
0BBP_PROD0SERVICE0MATERIAL
Global and consolidated views
on products,
independent from source component
Component restricted Analytics
DataSources
Source Components individual data
models
Cross-Component Integration: Product
R/3 Material
R/3R/3R/3
EBP Product
R/3R/3EBP
CRM Product
R/3R/3CRM
R/3 Service
R/3R/3R/3
0PRODUCT
Abbildung 38: Modell Integration mit Consolidated InfoObjekten
2003 SAP AG AND SAP AMERICA, INC. 44
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Die Herausforderung für die konsolidierte Sicht 0PRODUCT einen common coded key zur Verfügung zu stellen ist damit natürlich nicht gelöst. Hierbei unterstützen Funktionalitäten des SAP MDM (Master Data Management).
7.3 Die Rolle des SAP Master Data Managements (MDM) Unternehmensweites Master Data Management ist ein aktuelles Thema. SAP bietet hierzu das SAP MDM (Master Data Management).4
Aktives Master Data Management, d.h. das zentrale Verwalten und Verteilen von Master Daten, soll hier nicht näher beleuchtet werden. Existiert ein zentrales Master Data Management, so ist BW ein potentieller Klient und das gesamte unternehmensweite Reporting und die Analyse ein Nutznießer.
Interessanter sind in komplexen unternehmensweiten BW Szenarien ohne harmonisierte Daten die Möglichkeiten des MDMs, die Master Daten unterschiedlicher Quellsysteme auf Gemeinsamkeiten zu untersuchen und ein Gruppierung (group-id) sprich ein common coding vorzuschlagen.
Diese eher passive Funktionalität wird als ‚Content Consolidation’ bezeichnet.
SAP AG 2003, Corporate Data Warehousing based on SAP BW, J. Haupt 45 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 45
mySAP MDM Master Data Consolidation
ClientSAP
Clientnon SAP
Clientnon SAP
ClientSAP
Clientnon SAP
Description of a master data object:Identifying AttributesOther application specific data
Load
Matching
?
ID Mapping=
Content ConsolidationCore Process Steps:
1. Loading identifying attributes of master data objects as they were maintained in their local applications (clients)
2. Matching of uploaded master data objects to identify duplicates
3. Providing ID Mapping Information based on matching results for subsequent usage (I.e. in Business Intelligence)
MDMMDM
Abbildung 39: SAP MDM Master Data Consolidation
Die Mapping-Information (group-id) ist dann in BW ein Navigationsattribut des zu harmonisierenden InfoObjektes (s. Abbildung 37: Navigations-Attribute erhalten die BW-Lösungen flexibel). Dies kann also auch nachträglich hinzugefügt werden, ohne die existierenden Schemata zu beeinträchtigen.
4 Eine Integration zwischen BW und MDM wird ab Release BW 3.5 angeboten.
2003 SAP AG AND SAP AMERICA, INC. 45
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
SAP MDM unterstützt durch die ‚Master Data Harmonization’ das in 7.2 (Daten Modell Integration) beschriebene Szenario der Modellzusammenführung mittels konsolidierter InfoObjekte für komponentenübergreifende Analysen.
Hierbei werden im MDM Schlüssel unterschiedlicher InfoObjekte auf Gemeinsamkeiten überprüft, auf eine Gruppen-ID gemappt und zentral infoObjektübergreifende Attribute gepflegt.
SAP AG 2003, Corporate Data Warehousing based on SAP BW, J. Haupt 46 SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 46
Master Data Harmonization
MDMMDMClientSAP
Clientnon SAP
ClientSAP
Clientnon SAP
Local Creation
= ?Matching & ID Mapping
Distribution
+
+
Local Completion
Central Creation
Master data harmonization Core Process Steps:
1. Central Creation of master data objects just covering the global information of the master data object
2. Local Creation within the master data environment of the application system (client) and distributing their global information to MDM
3. Continuous matching processes identify duplicates and result in ID Mapping between them
4. Distribution of global master data information to the various clients
5. Local Completion of master data within the local environment
6. Use of ID Mapping information for MDM Analytics like business-wide analyses etc.
Description of a master data object:Globally relevant Data(Client) specific Data
13.282.401 €=737.108 €
4.002.531 €
634.237 €
6.674.288 €
1.234.237 €
Analytics
Abbildung 40: SAP MDM Master Data Harmonization
Neben dem aktiven Master Daten Management unterstützt MDM also Schlüsselkonsolidierung und komplexe Master Daten Harmonisierungen durch zeitversetztes (asynchrones) zusammenzuführen. Die Flexibilität der Conformed Dimension im BW erlaubt dabei die nachträgliche Erweiterung der BW ‚extended star schemas’ um die vom MDM stammenden Informationen, ohne existierende Lösung zu beeinträchtigen.
2003 SAP AG AND SAP AMERICA, INC. 46
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
8 Zusammenfassung Wesentliche Elemente einer unternehmensweiten BW Strategie sind Architektur, konsistente Anwendungsentwicklung und Unterstützung der Datenintegrationsbestrebungen. Eine corporate BW Architektur ist wesentlich für den mittel- und langfristigen Erfolg. Eine solche Architektur manifestiert sich in unternehmensweit gültigen Design- und Vorgehens-Richtlinien und deren Kontrolle. BW unterstützt die verschiedenen Architekturaspekte durch eine Vielzahl von konsistenzbewahrenden Funktionalitäten. Art und Grad der Nutzung dieser Funktionalitäten sind für jedes Unternehmen individuell festzulegen. Die zentrale Entwicklung von BW Applikationstemplates ist das geeignete Mittel, um eine unternehmensweit gültige BW-Architektur und damit eine Harmonisierung zu unterstützen. Die Integration von Daten ist eine fortwährende Herausforderung. BW ist eng mit dem SAP MDM integriert und bietet darüberhinaus vielfältige Design-Möglichkeiten diesen Herausforderungen zu begegnen. Diese sollten in einer unternehmensweiten BW Strategie berücksichtigt werden. Abschließend sei nocheinmal die wesentliche Aussage dieses Papers wiederholt: Das oberste Ziel einer jeden unternehmensweiten BW Strategie sollte es sein, die Redundanz in allen Bereichen zu kontrollieren! Dies gilt für jedes einzelne BW und für das Zusammenspiel aller BWs einer Unternehmung!
2003 SAP AG AND SAP AMERICA, INC. 47
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Tabelle der Abbildungen Abbildung 1: Evolution des SAP BW................................................................................................... 2 Abbildung 2: Redundanz und Lösungsfocus....................................................................................... 4 Abbildung 2: Redundanz und ‚multiple BW’ Landschaft ..................................................................... 5 Abbildung 3: Konzeptionelle Layer Architektur ................................................................................... 8 Abbildung 4: The BW Extended Star Schema .................................................................................. 12 Abbildung 5: Horizontale Konsistenz im BW Architected Data Mart Layer....................................... 13 Abbildung 6: BW und Slowly Changing Dimensions......................................................................... 13 Abbildung 7: Persistente und Virtuelle Multidimensionale Strukturen in BW.................................... 14 Abbildung 8: SAP BW Data Warehouse Layer ................................................................................. 15 Abbildung 9: BW DWH Layer und vertikale Konsistenz.................................................................... 17 Abbildung 10: Beispiel - BW Data Warehouse: Historisierung von Stammdaten .............................. 18 Abbildung 11: Beispiel - BW Data Warehouse: Transactions Daten ................................................. 19 Abbildung 12: BW Staging.................................................................................................................. 20 Abbildung 13: Klassisches Data Warehousing .................................................................................. 21 Abbildung 14: Klassisches Data Warehousing unterstützt Operatives Reporting ............................. 22 Abbildung 15: BW Operational Data Store: Near Real Time Data Warehousing .............................. 23 Abbildung 16: BW und Operational/ Real Time Reporting................................................................. 24 Abbildung 17: Operationale Daten Modelle und DWH Daten Modell ............................................... 25 Abbildung 18: DWH-Datenmodell und die Situation von BW Kunden ............................................... 26 Abbildung 19: Enterprise Datenmodell und erweiterbares BW Datenmodell: InfoObjekte............ 26 Abbildung 20: BW Datenmodell: InfoSources und subject areas ..................................................... 27 Abbildung 21: BW Datenmodell: Data Mart Layer Daten Modell ...................................................... 28 Abbildung 22: BW Datenmodell: Data Warehouse Layer Daten Modell........................................... 29 Abbildung 23: Die ideale unternehmensweite BW Landschaft? ........................................................ 30 Abbildung 24: Unternehmensweite Strategien und BW Architektur................................................... 31 Abbildung 25: BW Landschaft und Verfügbarkeit/ Wartung............................................................... 32 Abbildung 26: BW als Corporate Information Factory........................................................................ 33 Abbildung 27: Skalierbarkeit einer BW Corporate Information Factory I ........................................... 34 Abbildung 28: Skalierbarkeit einer BW Corporate Information Factory II .......................................... 35 Abbildung 29: ‘Lokal - Global’ BW Landschaft ................................................................................... 36 Abbildung 30: Architektur-basierte BW Landschaft und BW Templates............................................ 37 Abbildung 31: Global BW als Integrator ............................................................................................. 38 Abbildung 32: BW Customer Content ................................................................................................ 40 Abbildung 33: BW Customer Content ................................................................................................ 40 Abbildung 34: Source-System Schlüssel als BW-Schlüssel ? ........................................................... 42
2003 SAP AG AND SAP AMERICA, INC. 48
ENTERPRISE DATA WAREHOUSING MIT SAP BW – EIN ÜBERBLICK V2.0
Abbildung 35: Schlüsselwert Concatenation...................................................................................... 43 Abbildung 36: Navigations-Attribute erhalten die BW-Lösungen flexibel........................................... 44 Abbildung 37: Modell Integration mit Consolidated InfoObjekten ...................................................... 44 Abbildung 38: SAP MDM Master Data Consolidation ........................................................................ 45 Abbildung 39: SAP MDM Master Data Harmonization....................................................................... 46
2003 SAP AG AND SAP AMERICA, INC. 49