Enterprise Data Warehousing With SAP BW an Overview

Enterprise Data Warehousing mit SAP BW – Ein Überblick

White Paper Version 2.0

August 18th, 2003

[email protected]

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


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.



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:




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:


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•......



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.



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.



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




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:




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


LandscapeLandscape

Others

EnterpriseBW

InsideInside--OutOutBWBW EnterpriseEnterprise

DataDataWarehouseWarehouse Spoke

BW

SpokeBW

Others

SpokeBW

EnterpriseBW



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.



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



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




MasterReference

Data


ODSODS



Extra

ctio

n /

Ope

n St

agin

gEx

tract

ion

/ O

pen

Stag

ing



any

targ

et

Ext

ende

d St

ar S

chem

asE

xten

ded

Star

Sch

emas


MetaMeta DataData

any

sour

ce TransactionData


Abbildung 5: BW Layer Architektur - Überblick



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





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



CUSTOMER

MATERIAL

Horizontal Consistency: BW Architected Data Mart Layer

InfoCubeInfoCube



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


X 200 100Y 100 100

Report using 09/98 constellation


X 200 0Y 100 200

Report showing historical truth


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.



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.


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.



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).


A Matter of Consistency and Reliability –The BW Data Warehouse (Layer)

Finance

Logistic Ope

n D

istri

butio

n




MasterReference

Data


ODSODS



Extra

ctio

n /

Ope

n St

agin

g



any

targ

et

Ext

ende

d St

ar S

chem

asE

xten

ded

Star

Sch

emas


MetaMeta DataData

any

sour

ce TransactionData


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



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.



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



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



CUSTOMER

MATERIAL

InfoCubeInfoCube InfoCube

CUSTOMER

MATERIAL

CUSTOMER

MATERIALmaster

CUSTOMERmaster



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)



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.



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.



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


BW Data BW Data WarehouseWarehouse

Extr

actio

n /

Ope

n St

agin

g

BW ODSBW ODSany

sour

ce

StagingStagingArea:Area:PSAPSA


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.



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


DataMart

Logistic Tact

ical

/ St

rate

gic

MasterReference

Data

TransactionData


Extra

ctio

n /

Ope

n St

agin

g

DataMart

Finance

DataMart

Finance


DataMart

Logistic

DataMart

Logistic Tact

ical

/ St

rate

gic

MasterReference

Data

TransactionData


MasterReference

Data

TransactionData


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.



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


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


DataMart

Logistic

Tact

ical

/ St

rate

gic

/ Ope

ratio

nal

MasterReference

DataTransaction

Data


Extra

ctio

n /

Ope

n St

agin

g


DataMart

Finance

DataMart

Finance


DataMart

Logistic

DataMart

Logistic

Tact

ical

/ St

rate

gic

/ Ope

ratio

nal

MasterReference

DataTransaction

Data


MasterReference

DataTransaction

Data


Extra

ctio

n /

Ope

n St

agin

gEx

tract

ion

/ O

pen

Stag

ing


‘..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.




Near Real Time Data Warehousing (Apollo) –BW Operational Data Store

Finance

Logistic Ope

n D

istri

butio

n




MasterReference

Data


ODSODS



Extra

ctio

n /

Ope

n St

agin

g



any

targ

et

Ext

ende

d St

ar S

chem

asE

xten

ded

Star

Sch

emas


MetaMeta DataData

any

sour

ce TransactionData


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.




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 .



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:









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:



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


Object Models

0MATERIAL


Sales Transaction


CustomerCustomer Material Sales Person

Sales Transaction


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



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:


Object Models


Object Models

BWData Model defined by

Business Content

BWData Model defined by

Business Content


Sales Transaction



Sales Transaction


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.



Die Rolle der BW InfoSources mit Blick auf das Data Mart Layer Datenmodell illustriert nachfolgendes Bild:


Object Models


Object Models

0MATERIAL0MATGR0MATTYPE......

BW Data Mart Layer Data Model defined by

Business Content

BW Data Mart Layer Data Model defined by

Business Content


Sales Transaction



Sales Transaction



0SALESPERS0SALESORG.....

0CUSTOMER00CUSTGR......

0CUSTOMER 0MATERIAL 0AMOUNT

Shared/ Conformed DimensionsShared/ Conformed Dimensions InfoCubes with Local DimensionsInfoCubes with Local Dimensions

BCT Extractors/ DataSource



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):




Object Models


Object Models

BW Data Warehouse Layer Data Model defined by

Business Content

BW Data Warehouse Layer Data Model defined by

Business Content


Sales Transaction

Material group Sales ORGMaterial Type


Sales Transaction

Material group Sales ORGMaterial Type


BCT Extractors/ DataSource



+ 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.



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


LandscapeLandscape

Others

‘Local’BW

‘Local’BW

‘Local’BW

GlobalBW


LandscapeLandscape

Others

EnterpriseBW



BW

SpokeBW

Others

SpokeBW

EnterpriseBW



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:




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:



• 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:


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



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.


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



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.



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.


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



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.




Inside-Out: Central EDW BW Instance and BW Spoke Instances

EnterpriseBW



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.



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.


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.



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.


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



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



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




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



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.



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.



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:



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.


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



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.


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.



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.


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.



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!



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



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


Documents

Enterprise Data Warehousing With SAP BW an Overview