Enterprise data warehousing with sap bw overview

Enterprise Data Warehousingwith SAP BW – An Overview White Paper Version 2.0 August 18th, 2003 juergen.haupt@sap.comSAP (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, theimplied 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 damagesthat 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 withinthese materials. SAP has no control over the information that you may access through the use of hot links contained in thesematerials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third partyweb pages.

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0Table of ContentsENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW ....................................... 11 INTRODUCTION........................................................................................................................... 1 1.1 SUPPORTED SOFTWARE VERSIONS ........................................................................................... 1 1.2 THIS WHITE PAPER .................................................................................................................. 12 AIMS OF THE WHITE PAPER ..................................................................................................... 13 MOTIVATION ................................................................................................................................ 2 3.1 THE MARKET ............................................................................................................................ 2 3.2 WHY DO YOU NEED A CORPORATE BW STRATEGY?................................................................. 34 ENTERPRISE DATA WAREHOUSING WITH SAP BW.............................................................. 55 BW ENTERPRISE ARCHITECTURE........................................................................................... 6 5.1 ASPECTS OF A DATA WAREHOUSE ARCHITECTURE .................................................................... 6 5.2 DATA STORE ARCHITECTURE - BW DATA LAYER ..................................................................... 10 5.2.1 BW Architected Data Mart Layer .................................................................................. 11 5.2.2 BW Data Warehouse Layer .......................................................................................... 14 5.2.3 BW Extraction and Staging........................................................................................... 19 5.2.4 BW Support for Operational / Real Time Reporting ..................................................... 20 5.3 DATA ARCHITECTURE - BW DATA MODEL ............................................................................... 24 5.3.1 Operative Data Models and Data Warehouse Data Model .......................................... 24 5.3.2 The BW Data Model ..................................................................................................... 25 5.4 TOPOLOGIES – BW LANDSCAPES ........................................................................................... 29 5.4.1 Consistency in a distributed BW Landscape ................................................................ 30 5.4.2 BW Landscapes und Technical Parameters ................................................................ 31 5.4.3 Inside-Out Landscape Architecture - BW as Central Enterprise Data Warehouse...... 32 5.4.4 Outside-In Landscape Architecture - Decentralized BW Data Warehouses................ 346 CENTRAL BW APPLICATION DEVELOPMENT ...................................................................... 387 DATA AND DATA MODEL INTEGRATION .............................................................................. 40 7.1 CHALLENGES POSED BY DATA INTEGRATION............................................................................ 40 7.2 DATA MODEL INTEGRATION ..................................................................................................... 42 7.3 THE ROLE OF SAP MASTER DATA MANAGEMENTS (MDM) ...................................................... 438 SUMMARY .................................................................................................................................. 45TABLE OF ILLUSTRATIONS ………………………………………………………………………………432003 SAP AG AND SAP AMERICA, INC. CONTENT

BW Enterprise Data Warehousing – Overview V2.01 Introduction1.1 Supported Software VersionsThis document is relevant for BW Versions 3.x.1.2 This White PaperThe subject of this document is very complex. Therefore, we do not claim to cover all the variousaspects of this topic, or to offer an exhaustive description of the areas discussed.To see updated versions of this document, visit the SAP Service Marketplace regularly.2 Aims of the White PaperThis White Paper offers an overview of the implementation of SAP Business Information Warehouse(SAP BW) from a corporate perspective.It considers the following issues: • Architectural aspects: data management, data models, topologies etc. on a conceptual level • Integration aspects: supporting corporate strategy as far as the harmonization of master data is concerned • Solution development: the efficient, consistent development of BW-based applications.Enterprises differ in terms of their organization and their business. This implies that there can be nostandard solution for a corporate BW implementation strategy. However there are basic truths thatalways have to be considered, and patterns that arise within specific business types. Above all, thisWhite Paper will describe fundamental aspects of a corporate-wide BW implementation.This White Paper is no substitute for a business-specific consultation on BW architecture.This White Paper focuses on the general principles involved in a strategic corporate BWimplementation and not on exceptions to this. It follows the 80-20 rule.The White Paper avoids details wherever possible, so as not to lose sight of the overall context.Knowledge about BW is useful to read this White Paper but no prerequisite for it.2003 SAP AG AND SAP AMERICA, INC. 1

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.03 Motivation3.1 The MarketAt the time of writing, there are more than 6000 BW installations within the market.The fundamental advantages of BW have led more and more customers to center their corporatedata warehousing strategy around BW. Customers frequently stress the end-to-end conception of theBW in this context. In comparison to fragmented technologies, the integrated metadata concept, fromdata integration right through to analysis, leads to lower total costs for the project overall.The BW has moved away from isolated instances to incorporate an architecturally-based view. In thisway, the BW has come to set new standards of quality in terms of its positioning within an enterprise.The following graphic shows various rudiments of this strategy: Evolution of SAP BW Isolated BW Strategic Corporate BW Implementations Implementations BW1 BW2 ‘Headquarter’ BW1 Global Reporting BW BWn Scenario Others BW2 ‘Local’ BW Architected Global ‘Local’ BW Landscape BW3 BW BW Scenario ‘Local’ BWn BW Spoke BW Enterprise Issues: BW Data Synergy Enterprise BW Warehouse Integration Spoke Scenario Consistency BW  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 Illustration 1: Evolution of the SAP BWThis leads to one main motivation for this paper. It aims to support the evolution-process of BWoffering an overview of the essential criteria for corporate architected BW implementations forcustomers and consultants.On the other hand, there is still a large number of customers who do not have a corporate datawarehouse strategy and who have implemented BW in a more isolated and restricted way.Thus, another motive is the hope of making people aware of the prospects and benefits of abusiness-wide, architecturally-based BW implementation.2003 SAP AG AND SAP AMERICA, INC. 2

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.03.2 Why Do You Need A Corporate BW Strategy?There are many training guides, ‘enhanced documentations’, ‘ASAP Accelerators’ and ‘How toGuides’ available that offer support to BW users. These documents all focus on offering support withconcrete challenges that arise during a project.This is obviously important and necessary. However there are also short-comings as projects arealways part of an incremental BW implementation:From project to project, project goals are modeled and realized in BW. These goals are typicallyreporting- and analysis-driven, and the overall success of the project is then often measured bydecision-makers in terms of how far these reporting and analysis demands are met. As such, thefocus is at solution level or using a data warehouse term the focus is at data mart level.Less attention is accorded to decisive factors for the mid- and long-term success of an investment inBW: Redundancy has to be controlled in all areas!Business-wide guidelines rarely exist regarding: The persistent BW data stores and their design The BW Data Warehouse data model and its management The BW landscape (the role of BW instances and which conditions are valid for new instances).Aspects of data integration are often neglected too, and applications in various organization units thatfeature a BW are developed asynchronously and redundantly.Altogether, from an overall business perspective, you are left with a costly and less efficientprocedure that delivers neither consistent, reliable, nor integrated information.The following graphic clarifies the solution-focus issues: Redundancy and Data Mart (Solution) Focus Real World .... Requirements Information (grouped to Scopes) BW Application Project Team Impacts of non-existing Schema-Modeling corporate BW guidelines: InfoCubes/ • Redundant Data ODS-Objects • Redundant Extraction • Redundant Transformation • Redundant Business Rules Business Rules • Redundant Masterdata •...... Transformation Extraction Sources Successful Data Warehousing means ‘Controlled Redundancy’ !! Successful Data Warehousing means ‘Controlled Redundancy’  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 4  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 4 Illustration 2: Redundancy and Solution focus2003 SAP AG AND SAP AMERICA, INC. 3

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0The next graphic clarifies the multiple BW landscape issues: Redundancy and Multiple BW Landscape Impacts of non-existing Global e corporate BW guidelines: MDMS pl am Ex HQ e BW •Redundant Data Flows ap sc •Redundant Extraction nd SubDiv BW Local La BW •Redundant Development W if eB •Redundant Models L •...... al Re A BW BW BW BW Sales Europe Asia N-America S-America Sub-Division A Sub-Division B Sales Europe Div Div Div R/3 R/3 R/3 .................... R/3 R/3 R/3 Global only Germany 12 systems worldwide Source Systems Successful Data Warehousing means ‘Controlled Redundancy’ !! Successful Data Warehousing means ‘Controlled Redundancy’  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 5  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 5 Illustration 3: Redundancy and multiple BW landscapeThe more complex an enterprise’s structures, the more important it is to have corporate-wideguidelines and recommendations for the implementation of BW. They guarantee long-termconsistency and reduced costs.2003 SAP AG AND SAP AMERICA, INC. 4

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.04 Enterprise Data Warehousing with SAP BWWhen we talk about enterprise data warehousing it is first necessary to ask what we understand bythis term:Enterprise data warehousing is the sum of all the decisions that have to be taken at corporate level inorder to obtain a durable solution that adheres to business-wide, specified guidelines, and fulfills allrequirements for integrated, consistent and structured information.These decisions are mirrored in the enterprise data warehouse architecture.In this chapter we will consider the aspects of such an architecture so that we can then look moreclosely at how BW supports an architecturally-based, consistent, corporate data warehouse solution.As well as a BW architecture that ensures consistency, we want to consider in what ways the BWoffers support in generating consistent application solutions.Furthermore, in discussing a corporate BW strategy, we have to include BW in the data integrationstrategy of the company. This is done in the last chapter.As with all important decisions, we concentrate on the fundamental aspects, following the 80:20 rule.2003 SAP AG AND SAP AMERICA, INC. 5

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.05 BW Enterprise ArchitectureAn architecture can be seen as a system design decision that has a specified duration. In otherwords, once it has been implemented it is not easy to change.In defining a corporate BW architecture it is clear that the term ‘architecture’ is used in varioussenses, and that aspects such as ‘where’, ‘what’ and ‘how’ often become confused. This leads toconfusion and is dangerous in that essential factors may be considered from a lop-sided perspective,or not at all.5.1 Aspects of a Data Warehouse ArchitectureIn discussing an optimal BW architecture, an enterprise often focuses too quickly on physical BWinstances. Is more than one BW instance needed and if yes, where are they to be institutionalized?How will they work together? These questions concern a BW landscape, or as we prefer to call it, aconsistent enterprise BW topology.This means that the second or even third architecture elements are being considered before the first.How can individual BW instances and their tasks be discussed without having first defined how datais consistently handled and saved in such a BW instance?We must start with the BW data store or data layer architecture:The layer architecture defines persistent data stores and their storage schemas from extractionthrough to the end-user, and refinement processes between the layers.Qualified data status and the respective layers: • Staging Area - row • Data Warehouse Layer - integrated, granular, not application-specific, historical • Data Mart Layer - integrated, aggregated, application-specific • Operational Data Store (ODS) – integrated, granular, application-specific, close to event2003 SAP AG AND SAP AMERICA, INC. 6

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 Conceptual Layers of Data Warehousing Operational Data Store Non-SAP Source Persistent Infor- Staging mation Area Archi- Access Data tected SAP Warehouse Data Source Marts Archiving & Near-Line Storage  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 15  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 15 Illustration 4: The conceptual layer architecture of data warehousingRepeatedly saving raw data in various refinement situations means on the one hand sideredundancy. On the other hand side means a consistent layer architecture the only way to control theredundancy of data warehousing, which derives from its very nature. This has to be taken intoconsideration with the layer data store schemas.However, a suitable layer support is not the only necessary condition for a corporate-wide datawarehouse architecture that can secure consistency in the mid- and long-term.This can only be achieved if the operative data models are mapped consistently to the model of thedata warehouse layer and the model of the data mart layer. Such a consistent data (model)architecture therefore describes the model of each layer and how the models relate to each other.As such we need a data architecture that guarantees, for example, that operative material terms, asthey are found in the respective sales or distribution area, or in materials management, arereproduced consistently in the material subject area.Ideally you would have a single operative enterprise data model and use that to derive the model foreach layer. However, a corporate data model of this sort does not normally exist, particularly if legacysystems are being used.This means that often no or only limited guidelines and rules exist how to map the operative modelsto a single data warehouse layer model and a single data mart layer model because of the difficultiesto achieve this. The result is unsynchronized isolated solutions (‘stovepipe solutions’).This is illustrated in the following graphic:2003 SAP AG AND SAP AMERICA, INC. 7

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 Operational Data Models and the Data Warehouse Data Model Inconsistent data warehouse data models ⇒ Consistent data warehouse data model ⇒ stovepipe solutions long term success A data warehouse consistency challenge Not aligned operational data models Consistent enterprise data model  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 95  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 95 Illustration 4: Operational Data Models and DWH Data ModelA missing data model architecture is one reason why corporate data warehouse strategies fail.Only when there is clarity regarding the data layer and data model does it make sense to discuss thecorporate-wide topological aspects of a BW architecture. Because topological aspects areinfluenced by the layer architecture.Two basic topologies are differentiated:• The BW enterprise data warehouse landscape with BW as the central information hub• Landscape based on ‘local’ BWs with a higher level ‘global’ BW Inside-Out Inside- Others Others Outside-IN Outside- BW Enterprise BW Data Landscape Spoke Warehouse ‘Local’ BW BW Enterprise Spoke Global BW ‘Local’ BW BW BW Spoke ‘Local’ BW BW Illustration 5: BW basic topologiesWhen determining the BW topology, political, organizational and technical factors play an importantrole. As a result you cannot really talk about a generally valid optimal BW topology.We summarize that it is necessary to make definitions that are valid enterprise-wide in the followingareas:2003 SAP AG AND SAP AMERICA, INC. 8

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0• BW data layer architecture • Which data statuses does it make sense to save persistently? • Which designs are approved for the various data stores?• BW data model architecture • Each data warehouse layer requires a data model that describes objects and their relationships • The data models of the various layers have to be derived from each other consistently• BW topology architecture • Different corporate cultures, geographical, and business diversifications lead to different data warehouse landscapes.2003 SAP AG AND SAP AMERICA, INC. 9

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.05.2 Data Store Architecture - BW Data LayerIt is generally accepted that the data store that supports analysis and reporting is to be kept separatefrom the data store that deals with any sort of data acquisition.Analysis and reporting are handled by data marts. Close to event-level operative reporting is handledby the operational data store.BW supports multidimensional data marts in an extended star schema. This is made up of BWInfoCubes and over-arching BW InfoObject master data dimensions.Operational data stores are supported by ‘flat’ BW ODS objects. Here too BW master data acts asstructures that span ODS objects.Data acquisition (processes that secure quality and integration) are referred to as staging processes.The persistent saving of staging process data occurs in staging areas.Data staging stores are realized by the Persistent Staging Area (PSA) Objects and by ODS objects.The granular, integrated result of the staging process reproduces data in optimal condition. This isreferred to as the data warehouse layer.BW ODS objects are the central storage objects that build a BW data warehouse layer.This gives us the following general picture of a BW layer architecture: SAP Business Information Warehouse Data Primary Data Acquisition Data Delivery Staging Cleansing Management Area Transform Data Architected Warehouse Data Marts Extended Star Schemas Extraction / Open Staging Master Reference Open Distribution Data Financeany source any target Transaction Data Logistic ODS Flow Control Meta Data Illustration 5: BW layer architecture - overview2003 SAP AG AND SAP AMERICA, INC. 10

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.05.2.1 BW Architected Data Mart LayerInfoCube data marts allow the flexible generation of queries and navigation to integrated, granular oraggregated data. In order to make comparisons possible, an amount of historical data (defined byyou) can be retained.InfoCubes are multidimensional data structures (also called star schemas) that organize data in sucha way that key figures (or facts or measures) are affixed to characteristics and their attributes, whichform the so-called dimensions (BW InfoCube dimensions and master data).To increase the capacity of an InfoCube schema, dimensions are separated into local and globaloperative parts. Global, because these dimension-parts are only saved once and are conjointlyaddressed by various InfoCubes. Material Local Part of Material Dimension Dimension Material Master Table Material Number Material Number Material Type Material_Dimension_ID Material Text Table Material Number Material Number Material Dimension Material Number InfoCube Table Language Code Language Code Material Name Material_Dimension_ID Material Hierarchy Table SalesOrg_Dimension_ID Vertriebsorganisation Time_Dimension_ID Region 1 Region 2 Region 3 Customer_Dimension_ID MaterialBezirkGroup Bezirk 5 Bezirk 1Bezirk 2 3 Bezirk 4 Sales Amount Gebiet 1 Gebiet 2 Gebiet 3 Gebiet 3a Gebiet 4 Gebiet 5 Gebiet 6 Gebiet 7 Gebiet 8 Quantity FACT Table Shared, global Part of BW Extended Star Schema Material Dimension Illustration 5: The BW extended star schemaIn this way BW InfoCubes support the concept of ‘conformed dimensions’, which form a sort of ‘glue’between InfoCubes. Horizontal Consistency: BW Architected Data Mart Layer CUSTOMER master CUSTOMER CUSTOMER CUSTOMER Horizontal Consistency: Conformed Structures InfoCube InfoCube InfoCube BW InfoObjects master data MATERIAL MATERIAL MATERIAL master Illustration 6: Horizontal consistency in the BW architected data mart layer2003 SAP AG AND SAP AMERICA, INC. 11

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0Conformed dimensions essentially support horizontal consistency within the data mart layer. Theyare part of the BW concept and help prevent the occurrence of isolated solutions (‘stovepipes’). TheBW term for these conformed dimensions is ‘master data’.This is one reason to qualify the BW data marts as Architected data marts.The effectiveness of the BW InfoCube schema does not just support consistency but is obviously alsoessential for mapping end-users’ demands. Above all we have to mention here the ability to mapentities from different historical views to the same key figure.By using surrogate keys in the InfoCube and because of the master data/ conformed dimensionconcept, the BW makes it possible to simultaneously map different views to key figures in oneInfoCube. BW Support of Different Historical Views Constellation 09/1998 Customer Mother-Company Report using today‘s (10/98) constellation AAA X Mother-Comp Rev 09/98 Rev 10/98 BBB X X 100 0 CCC Y Y 200 200 Report using 09/98 constellation Customer Date Revenue Mother-Comp Rev 09/98 Rev 10/98 AAA 09/1998 100 BW supported Views in X 200 100 BBB 09/1998 100 a single InfoCube Y 100 100 CCC 09/1998 100 BBB 10/1998 100 Extended Star Schema Report showing historical truth CCC 10/1998 100 Mother-Comp Rev 09/98 Rev 10/98 Fact Table X 200 0 Customer Mother-Company Y 100 200 AAA X BBB Y (changed) Report showing comparable results CCC Y Mother-Comp Rev 09/98 Rev 10/98 Constellation 10/1998 X 100 0 Y 100 100  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 Illustration 7: BW and slowly changing dimensions• Today is Yesterday : Show key figure values, including historical key figure values, from the currently valid perspectives (current view of dimension attributes)• Yesterday is Today : Show key figure values from user-defined perspectives (key date oriented view of dimension attributes)• Historical Truth : Show key figures (transactions) in the same state (historicization of dimension attributes), as at the time of posting – historically correctScenarios can also be presented in which only key figure values with unchanged dimension attributeconstellations are reported.In order to reduce redundancy and counteract the ‘one report is equal to one InfoCube’ error, virtualmultidimensional structures are supported for persistent InfoCubes. These are called BWMultiProviders and BW Queries.2003 SAP AG AND SAP AMERICA, INC. 12

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 Multi-dimensional Schemas in BW End-User End- Reporting & Analysis need BW BEX Report Multi-dimensional model Multi- end-user requirement specific BW InfoCube(s) BW BEX Query physical implementation virtual Structures basic facts complex KPIs not report specific navigation behavior report (type) specific BW MultiProvider virtual Structures basic facts not report specific optional  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 24  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 24 Illustration 8: Persistent and virtual multidimensional structures in BWDespite the capabilities of BW data mart layers, the limitations and dangers of a data mart-focusedimplementation are also evident: Limited reusability of data and loss of historical conditions • Data is dealt with in the data mart layer in a scope-specific manner: Aggregation/ manipulation/ overwriting of data is normal. It follows that the usage of these data for other purposes is limited. • The data mart layer is the direct access layer for the end-user. Performance, therefore, plays a decisive role. For this reason only data that is actually needed is retained in the data mart layer. Saving data ‘just in case’ will quickly lead to a large data volume and impact negatively on performance. Overwriting old images, as normally happens in the conformed dimensions (master data), is therefore valid and indeed desired. However, this means that history is lost. Redundant data storage (the same data is held in various InfoCubes and often in different degrees of granularity) Redundant data acquisition (staging) Redundant data extraction Limited ability to trace data.Data staging is required by the BW layer architecture here.Factors arising from contact with the data mart data model that threaten consistency are discussed inthe chapter on data model architecture.2003 SAP AG AND SAP AMERICA, INC. 13

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.05.2.2 BW Data Warehouse LayerIn order to overcome the limitations and dangers of a data mart-focused BW implementation, thecorporate BW architecture has to answer demands such as: „extract once deploy many” “single point of truth”Furthermore, the contradiction between quite sensibly reducing information in the data mart layer if itis not currently required by the end-user, and the claims the BW makes to flexibility, has to beresolved. The BW also has to be able to respond quickly to new requests.The answer is to build a separate layer that saves the integrated results of the data transformationand data quality-ensuring processes in a consistent, granular and historical form: The BW datawarehouse layer.Ideally this is built centrally and extends business-wide. We can then talk about a BW enterprise datawarehouse (layer). A Matter of Consistency and Reliability – The BW Data Warehouse (Layer) SAP Business Information Warehouse Data Primary Data Acquisition Data Delivery Staging Cleansing Management Area Transform Data Architected Warehouse Data Marts Extended Star Schemas Extraction / Open Staging Master Reference Open Distribution Data Finance any source any target Transaction Data Logistic ODS Flow Control Meta Data  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 41  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 41 Illustration 9: SAP BW data warehouse layerThe following description of a BW data warehouse layer is based on William H. Inmon’s definition:A BW data warehouse layer offers: o Subject-oriented, integrated data o Original data that will not be changed in relation to the goals of a particular project (‘unflavored data’) o Granular data Non-aggregated data o Historical data (that cannot be overwritten or deleted)2003 SAP AG AND SAP AMERICA, INC. 14

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 o A ‘single point of truth’ The BW data warehouse layer is the only source for BW architected data marts. (“extract once – deploy many”).In this way a BW data warehouse offers the following benefits: I. Flexibility o New InfoCube data mart solutions that include history and new extraction can be built in real-time o The BW can respond quickly to unpredictable, one-off user requests, without having to build persistent structures (Although the BW data warehouse layer is not to be misused for standard analysis as it does not possess the optimal structures for this). II. Reliability and Reproducibility o The BW data warehouse layer is centrally administrated and not subjected to arbitrary projects. The data warehouse layer is the common source for all the data provided in the data marts. III. Complete history IV. Consistency o Extraction, staging and integration are managed centrally o Data is extracted only once o Redundant staging processes are avoided.A BW data warehouse (layer) is an enterprise’s memory, a repository for information for thewhole enterprise.In addition to offering horizontal consistency within the BW data mart layer, the BW data warehouselayer offers a sort of vertical consistency that the data mart layer alone is not able to guarantee.2003 SAP AG AND SAP AMERICA, INC. 15

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 Vertical Consistency: BW Data Warehouse Layer CUSTOMER master CUSTOMER CUSTOMER CUSTOMER Horizontal Consistency: Conformed Structures InfoCube InfoCube InfoCube BW InfoObjects master data MATERIAL MATERIAL MATERIAL master Vertical Consistency: Single Point of Truth BW DWH Layer ODS-Objects ODS- Transaction / Master Data Source 1 Source 2 Source 3 Source 4 Source 5 Illustration 10: BW data warehouse layer and vertical consistencyThe question of how to organize data warehouse layers often causes arguments. Extreme positionson this range from 3NF to de-normalized star schemas. We do not want to give a definite answerhere, but suggest taking a pragmatic approach. As the data warehouse layer forms the basis forsupplying the data marts, data should be saved so that it can be easily transported into conformeddimensions and InfoCubes. This means complex join operations for normalized data warehouseobjects on the way to the data marts should be avoided. It is therefore, for example, legitimate tostore position data and header information for a sales order together in the data warehouse layer.To the question, "what kind of database design is appropriate for a data warehouse?", W.H. Inmonoffers the following answer:‘For a data warehouse, it is always better to have a lightly normalized design. Star schemas fitelsewhere (s. Data Marts t. author). The data warehouse design is not perfectly normalized becausea few alterations are made for common usage, such as creating arrays of data when data is alwaysused together, creating a small and selective amount of redundancy where appropriate, mergingtables that are commonly used together, and so forth. At the end of the day, a data warehousedesign 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 keepavailable a detailed historical data store. This should be ‘clean’ (free of errors and conformed to theData Warehouse master data model) to avoid unnecessary reprocessing of source data.’(W. H. Inmon, Architecture 2002)2003 SAP AG AND SAP AMERICA, INC. 16

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0The BW does not offer a data store specific for the data warehouse layer. Transaction data is savedin flat ODS objects, master data, reference data, in InfoObjects or ODS objects. Handling history issupported in BW by staging processes (transfer/ update rules) and staging ODS objects. Data Mart Customer CustomerGroup Master Data Table A Y after 2nd Load: B Z 20020401 DWH Object Customer Source Activ From Activ To CustomerGroup A S1 20020101 20020331 X after 2nd Load: B S1 20020101 99991231 Z 20020401 A S1 20020401 99991231 Y Customer CustomerGroup A X 1st Load: 20020101 Sourcesystem S1 B Z 2nd Load: 20020401 A Y Illustration 11: Example - BW data warehouse: Historization of master dataWith master data, the source system normally does not deliver versioned or historical data images.Furthermore full-loads are often provided for master data. If the source system does not provide anyhistorization, the BW staging processes must provide this information. The management of activitytime slots is supported by BW for data warehouse InfoObjects automatically. For data warehouseODS objects activity time slots must be maintained during staging. It is also the task of the BW with‘full loads’ to determine the changed records. This is done using special staging ODS objects.These tasks are omitted when SAP Master Data Management (SAP MDM) historicized Delta imagesare provided.Handling transaction data is easier, as long as the transaction is not to be posted again. Withchangeable transactions a simple time stamp is often not enough to prevent it from being overwritten.2003 SAP AG AND SAP AMERICA, INC. 17

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 InfoCube Customer Dimension Material Dimension A 4712 4713 Amount Customer Material Time Company Currency A 4712 200211 100BW Architected Data Mart Layer A 4713 200211 150 Time Dimension other InfoCube other InfoCube 200211 monthly weekly daily Amount AmountBW Data Warehouse Customer Time DocNo Pos Material Local Company Layer Currency Currency A 20021107-10am 1 10 4711 100 50 A 20021107-3pm 1 10 4712 200 100 A 20021107-4pm 2 10 4713 300 150 dailySourcesystem Amount Customer Time DocNo Pos Material Local Currency A 20021107-10am 1 10 4711 100 New booking A 20021107-3pm 1 10 4712 200 Correction booking A 20021107-4pm 2 10 4713 300 New booking Illustration 12: Example - BW data warehouse: Transaction dataThe quantity of data in a BW data warehouse layer mounts quickly. The BW/ SAP ArchivingDevelopment Kid (ADK) provides the prerequisites for the data warehouse layer to cope with thedemand, without the memory space used escalating exorbitantly.If a large data volume is to be made available online, the BW supports the usage of nearline storage.2003 SAP AG AND SAP AMERICA, INC. 18

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.05.2.3 BW Extraction and StagingIn order to guarantee the quality of data in the BW data warehouse layer, corporate-wide rules withrespect to extraction and staging are important. First and foremost, these should avoid redundantextraction and transformation.Using BW as the basis for enterprise data warehousing requires that all data sources can beaddressed. For this reason the BW offers a wide spectrum of support for extraction: • Predefined, enhanceable extractors for practically all SAP application data • The possibility to generate extractors for customer-specific SAP applications like COPA • Generic extractors for customer-specific enhancements of mySAP applications • Direct extraction from databases supported by SAP (BW DB-Connect Feature), based on table- or view-definitions • Flat file extraction • Integration with Ascential’s Datastage • BW 3.5 it is scheduled to support extraction from sources that can be addressed using JDBC or ODBO .Most extractors for SAP application transaction data are delta-enabled. This means that transactionscan be written to a delta queue at the time of posting. They are then extracted from this delta queueinto the BW. It is evident that as well as delta-enabling, important design possibilities for BWscenarios are also derived from this, as master data information like price, for example, can also besaved at the time of posting.Extracted data is the first status at which it is relevant to save data persistently. This raw data issaved in the persistent staging area (PSA) on a 1:1 basis. The PSA forms a backup for newlydesigned staging processes. Staging Cleansing Area: Transform PSA BW Data Extraction / Open Staging Warehouse any source BW ODS Illustration 13: BW stagingWhether and which data statuses between raw and integrated data is saved persistently has to bedecided on a case by case basis. This decision depends on the quality of data and the outlay forpotential data harmonization. BW ODS objects are used as data stores.2003 SAP AG AND SAP AMERICA, INC. 19

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.05.2.4 BW Support for Operational / Real Time ReportingStaging, data warehouse and data mart layers constitute ‘classic’ data warehousing. ‘Classic’ in thesense that data is subjected to an exact and predefined procedure in order to guarantee the qualityand integrity of reporting and analysis. ‘Classic data warehousing’ also means the ability to take theburden away from the operative systems. The classic data warehousing approach: Dedicated load and staging processes High quality Optimized retrieval structures Reduce workload on OLTP systems Architected Data Data Marts Warehouse Extraction / Open Staging Tactical / Strategic Data Master Mart Reference Data Finance Transaction Data Data Mart Logistic Illustration 14: Classic data warehousingAlongside the classic layers (staging, data warehouse and data mart) an additional data area is oftenpostulated: The Operational Data Store (ODS). The operational data store supports operativereporting, whereas data marts are data structures for tactical and strategic reporting and analysis.In practice, if operative reporting does not demand real-time data, the physical division between thedata mart and the ODS becomes artificial.Mostly loading data two or three times daily is sufficient for operative reporting. Updating data on adaily basis may even be enough. The greater the ‘latency’ (the time difference between the operativeevent and the acquisition of this event for reporting purposes), the more sensible it is to store granulardata in data mart InfoCubes too, and to use this both for tactical analysis and operative reporting. FlatBW ODS objects are better suited to purely listing data.In this way, most BW implementations already support operative reporting and so relieve thepressure on operative systems.2003 SAP AG AND SAP AMERICA, INC. 20

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 In most of the cases operational reporting needs can be supported in BW using the classic data warehouse process Tactical / Strategic / Operational Architected Data Data Marts/ Extraction / Open Staging Warehouse ODS-Objects ODS- Data Master Mart Reference Data Finance Transaction Data Data Mart Logistic ODS-Object Sales 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/ or if we are confronted with huge data volumes Illustration 15: Classic data warehousing supports operatives reportingBW supports this tactical analysis and operational reporting on the same InfoCube through pre-calculated aggregates, ‘aggregation awareness’ in the OLAP Engine, and ‘query catching’.However it is to be pointed out that the utilization profile of data for operative usage is different inregard to both its history and its granularity to data for analytical usage. With large volumes oftransaction data this has to be accounted for in the schema modeling.With delayed operative reporting, which follows the path of ‘classic data warehousing’, there is noneed to define a dedicated BW operational data store. You do then have to be aware of the possibleconsequences of basing analysis and operative reporting on the same structures.One the other hand, if data is requested close to the event time in the operative system, the ‘classic’pull principle of the BW data warehousing boundaries are set. In this case we talk about ‘real-time’ or‘near real time operational reporting’. The data extracted (in real time) is written straight to ODSobjects, without going through the data warehouse layer. These objects form the BW operational datastore.2003 SAP AG AND SAP AMERICA, INC. 21

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 Near Real Time Data Warehousing (Apollo) – BW Operational Data Store SAP Business Information Warehouse Data Primary Data Acquisition Data Delivery Staging Cleansing Management Area Transform Data Architected Warehouse Data Marts Extended Star Schemas Extraction / Open Staging Master Reference Open Distribution Data Finance any source any target Transaction Data Logistic ODS Flow Control Meta Data  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 83  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 83 Illustration 16: BW operational data store: Near real time data warehousingData from an operational data store is not to be processed directly in the data mart layer for reasonsof data consistency. If data from an operational data store is needed in a data mart scenario, youshould always go through the (enterprise) data warehouse.To summarize, the functionalities planned and offered by BW to support real time reporting scenariosare: BW Remote InfoCubes – external InfoCube fact tables BW allows you to define InfoCubes whose fact tables are themselves not persistent in the BW. The data is then read by an extractor during the query runtime and subjected to ‘normal’ InfoSource treatment as far as transfer and update rules are concerned. It can then be made available to the OLAP processor. All data sources that can be addressed by BW can make external fact tables available in this way. BW Virtual InfoCubes – a program that behaves like a fact table BW ‘near real time data warehousing’ (next main BW release) With the next main BW release it will be possible to ‘push’ data into BW ODS objects directly after either its emergence or the change event. Direct reporting to operative structures (next main BW release) Reporting directly to operative structures will also be an option if integration with other data is not required. However the burden produced (lack of data integration and data quality controls) means tight limitations are set for this option.2003 SAP AG AND SAP AMERICA, INC. 22

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 BW and Operational/ Real Time Reporting Key-Questions: Data Latency ? Data Integration ? Workload on OLTP Systems ? Ul Apollo Apollo BW BW Near real time BW remote BW virtual BW ‘classic’ data warehousing InfoCube InfoCube data warehousing Adaptors BW Data Integration BW Data Acquisition JDBC ODBO XMLA SAP Query OLTP  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 89  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 89 Illustration 17: BW and operational / real time reporting.2003 SAP AG AND SAP AMERICA, INC. 23

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.05.3 Data Architecture - BW Data ModelThe BW layer architecture describes the life-cycle of data from the event through to the retrieval-relevant data mart or flat ODS object structure. One thing is intuitively clear: persistent stores andtheir storage schemata alone are not sufficient to ensure ‘controlled redundancy’. This requires adata warehouse data model.5.3.1 Operative Data Models and Data Warehouse Data ModelThe operative application’s entity relationship model serves as the basis for a data warehouse datamodel. Ideal examples of an business-wide, operational data model are scarce. The challenge then isto derive a consistent data warehouse data model from a multitude of operative models. Thefollowing graphic illustrates this: Inconsistent data warehouse data models ⇒ Consistent data warehouse data model ⇒ stovepipe solutions long term success A data warehouse consistency challenge Not aligned operational data models Consistent enterprise data model Illustration 18: Operational data model and data warehouse data modelGenerating a business-wide data warehouse data model based on operative data models, which arenot harmonized, is a complex and political procedure. This is why the data warehouse data modelarchitecture is often neglected. The result is isolated applications or ‘stovepipe’ data marts that arenot integrated.In this regard BW customers finds themselves in a good position.BW offers an extensible data warehouse data model that represents the operative models of the SAPapplications and a large number of industry-specific solutions consistently as part of the BW BusinessContent. Data models also exist for specific applications from the competitive environment (OracleFinancials, for example).BW customers with a high operative degree of coverage from SAP applications can enjoy being inthe situation illustrated in the following graphic:2003 SAP AG AND SAP AMERICA, INC. 24

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 B W C o n s is te n t d a ta w a re h o u s e d a ta m o d e l fo r S A P A p p lic a tio n s a n d o th e rs ⇒ lo n g te rm s u c c e s s 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 e 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 Illustration 19: Data warehouse data models and the situation for BW customersThe BW Business Content data model watches over the incremental generation of InfoCubesolutions and ensures that they match, often without the customer even having to be aware of this.This is the true value of BW Business Content from an architecture point of view, and one reason forthe success of BW.5.3.2 The BW Data ModelOperative entities and attributes correspond to BW InfoObjects. 0MATTYPE 0AMOUNT 0CUSTOMER 0SALESORG BW Data Model 0SALESPERS 0MATERIAL 0MATGR 0DOCNO operative entities and attributes Entities, Attributes -> ⇒ BW InfoObjects BW InfoObjects Materialgroup Sales MaterialType Enterprise Data Model: ORG e.g. mySAP Component Object Models Customer Material Sales Person Sales Transaction Illustration 20: Enterprise data model and enhanceable BW data model: InfoObjects2003 SAP AG AND SAP AMERICA, INC. 25

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0Alongside technical properties like format and length, InfoObjects carry data warehousing-relevantproperties: • Aggregation behavior (key figures) • Standard displays (key figures) • Textual description • Language-dependant descriptions • External hierarchies •…Clustering operative entities and attributes to subject areas takes place through InfoSources. Masterdata and transaction data InfoSources are differentiated: Clustering operative entities and attributes ⇒ Data Warehouse subject-areas ⇒ BW InfoSources built of InfoObjects BW BW DataModel defined by Data Model defined by Business Content Business Content BCT InfoSources ≡ 0MATERIAL 0MATGR 0MATTYPE 0DOCNO 0SALESDAT 0CUSTOMER 0SALESPERS 0MATERIAL 0AMOUNT Subject Areas Master Data Transaction Data Materialgroup Sales MaterialType ORG Customer Material Sales Person Enterprise Data Model: Enterprise Data Model: e.g. mySAP Component e.g.mySAP Component Object Models Object Models Sales TransactionIllustration 21: BW data model: InfoSources and subject areasInfoSources always represent a set of InfoObjects and describe relations between these.InfoSources are the central bridge between the operative and the BW data model. In the operative system they correspond in form to a DataSource that, in turn, represents an extractor’s result structure. In the BW data mart layer an InfoSource either defines a conformed dimension (master data InfoSources), or a relation between conformed dimensions (transaction data InfoSources), in other words, the basis for InfoCube schemata.The following graphic illustrates the role of BW InfoSources with regard to the data mart layer datamodel:2003 SAP AG AND SAP AMERICA, INC. 26

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 BW Extended Star Schemas BW Extended Star Schemas 0MATERIAL 0CUSTOMER 0SALESPERS 0MATGR 00CUSTGR 0SALESORG 0CUSTOMER 0MATTYPE ...... ..... 0MATERIAL ...... 0AMOUNT Shared/ Conformed Dimensions Shared/ Conformed Dimensions InfoCubes with Local Dimensions InfoCubes with Local Dimensions BW Data Mart Layer BW Data Mart Layer Data Model defined by DataModel defined by Business Content Business Content BCT InfoSources ≡ 0MATERIAL 0MATGR 0MATTYPE 0DOCNO 0SALESDAT 0CUSTOMER 0SALESPERS 0MATERIAL 0AMOUNT Subject Areas Master Data Transaction Data BCT Extractors/ DataSource Materialgroup Sales MaterialType ORG Customer Material Sales Person Enterprise Data Model: Enterprise Data Model: e.g. mySAP Component e.g.mySAP Component Object Models Object Models Sales TransactionIllustration 22: BW data model: data mart layer data model In the BW (enterprise) data warehouse a master data InfoSource and additional time-slice or time-stamp attributes defines a data warehouse ODS object, which is able to store different versions of a subject area, which occur over time. Time-slices or time-stamps for master data are normally not offered by the source systems. This information has to be provided in the transfer or update rules during staging. As a rule of thumb a transactional-InfoSources define the structure of a data warehouse ODS object for transactional data (see following graphic):2003 SAP AG AND SAP AMERICA, INC. 27

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 EDW InfoObject/ ODS-Object ODS-Object BW Data Warehouse Layer BW Data Warehouse Layer + Insert Timestamp/ Data Model defined by Data Model defined by If Overwrite: Activity Time Slice Unique Identifier + Source Business Content Business Content +Source BCT InfoSources ≡ 0MATERIAL 0MATGR 0MATTYPE 0DOCNO 0SALESDAT 0CUSTOMER 0SALESPERS 0MATERIAL 0AMOUNT Subject Areas Master Data Transaction Data BCT Extractors/ DataSource Material group Sales Material Type ORG Customer Material Sales Person Enterprise Data Model: Enterprise Data Model: e.g. mySAP Component e.g.mySAP Component Object Models Object Models Sales Transaction Illustration 23: BW data model: Data warehouse layer data modelBW Business Content offers a pre-defined extensible data model for SAP components based onInfoObjects and InfoSources. This data model describes the BW data mart layer and also extendsthe BW data warehouse layer to include time slices.If the Business Content data model for mySAP components is used throughout, data mart InfoCubescenarios for a particular themed area can be built without producing isolated applications.2003 SAP AG AND SAP AMERICA, INC. 28

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.05.4 Topologies – BW LandscapesThe topology aspects of a BW architecture often interest people most. Some reasons for this are: The short-term need to optimize already existing BW landscapes The parallel implementation of BW and R/3 Or simply a short-term focus on factors pertaining to costs.However, the discussion in the previous chapters has made it clear that focusing on landscapeaspects alone is superficial and in no way productive if strategies regarding the persistent layer andits data models are not also developed. If this is now clear, we can pose the question:What does the ideal BW landscape for my enterprise look like? The Ideal Corporate BW Landscape ? Strategic Corporate Implementation Options: Inside-Out Inside- Others Others Outside-IN Outside- BW Enterprise BW Data Landscape Spoke Warehouse ‘Local’ BW BW Enterprise Spoke Global BW ‘Local’ BW BW BW Spoke ‘Local’ BW BW Illustration 24: The ideal corporate BW landscape?Unfortunately we have to disappoint you: There is no ‘one size fits all’ BW landscapeNaturally there are solutions that are to be favored in terms of consistence, but enterprise-specificcircumstances often prevent such solutions.Decisions on BW landscape architecture and ultimately on all aspects of the architecture have to bemade amidst the following conflicts:2003 SAP AG AND SAP AMERICA, INC. 29

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 Enterprise-wide Strategies Centralized versus Decentralized Low dispersal, high centralization “Select the [IT] approach that High dispersal, low centralization fits most closely with High dispersal, high centralization corporate strategy” Inside-Out versus Outside-In Prof. Sethi, University of Texas Information&Management, 2/01 Central Data Hub, Local Spokes Local Hubs, central aggregation Global Integrations versus Local Responsiveness Global scale Global standardization Global demand Local customer needs Local market conditions Local governmental regulations  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 109  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 109 Illustration 25: Enterprise-wide strategies and BW architectureFurther parameters relevant to this decision are: • Master data integration status and strategy • To what extent is an awareness of the essential roles of consistent data available? • Budget • Sponsorship • IT Strategy - Operative System Landscape • Competitive environment. As a basic principle the following advice should be followed: “Select the [IT] approach that fits most closely with corporate strategy” (Prof. Sethi, University of Texas Information&Management, 2/01) In other words, a business-wide BW enterprise data warehousing strategy will hardly ever be successful when it contradicts the corporate culture.5.4.1 Consistency in a distributed BW LandscapeThe corporate BW landscape will often consist of several BW instances and possibly also externaldata warehouse tools.Alongside general decisions that ensure consistency within and between BW layers, rules must alsobe defined to ensure the consistency of data and metadata in a distributed data warehouselandscape.BW supports distributed (BW) landscapes with a multitude of functionalities:• Data consistency The distribution of data in a landscape like this has to be controlled (delta handling). This is guaranteed by BW functionalities:2003 SAP AG AND SAP AMERICA, INC. 30

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 o Data Mart Interface (BW-BW data distribution) o Open Hub Service (BW-Third Party data distribution)• Metadata consistency This is realized and controlled using the BW development environment and the BW metadata interface (XML for 3rd-party)• Daily Operations Partnerships with producers of automization tools for data centers guarantee that the data distribution process (BW process chains) can be controlled and scheduled from one central point.These functionalities are the same whatever BW landscape architecture you choose.5.4.2 BW Landscapes und Technical ParametersDiverse technical parameters also influence what BW landscape is suitable for your enterprise.• Geographical distribution of users In the most extreme cases users can be spread around the whole world. This graphic illustrates challenges that then arise: Availability and Maintenance Availability and Maintenance 24 x 7 Access B rru s s e lls B u sse s R e p o rrttiin g Repo ng F rr 4pm Performance impacts F 4p m 8pm 8p m Data actuality Sa Sa 12a m 12a m Data backup, repair and recovery 4a m 4a m 8a m 8a m System upgrades and maintenance 12p m 12pm Zero Downtime B ru sse ls B ru sse ls L .A . L .A . T o k y o T o k y o R e p o r tin g T Rm p o r t i n g i e e 4pm 4p m T im e 1 2 a m 3 p m 8 a m 1 2 a m 3 p m 8 a m 8pm 8p m 2 a m 5 p m 1 0 a m 2 a m 5 p m 1 0 a m Su Su 12a m 12a m 4 a m 7 p m 1 2 p m 4 a m 7 p m 1 2 p m 4a m 4a m 6 a m 9 p m 2 p m 6 a m 9 p m 2 p m 8a m 8a m 8 a m 1 1 p m 4 p m 8 a m 1 1 p m 4 p m 1 0 a m 1 a m 6 p m 12p m 12pm 1 0 a m 1 a m 6 p m 1 2 p m 3 a m 8 p m 4pm 4p m 1 2 p m 3 a m 8 p m 2 p m 5 a m 1 0 p m 8pm 2 p m 5 a m 1 0 p m 8p m 4 p m 7 a m 1 2 a m 4 p m 7 a m 1 2 a m M o M o 12a m 12a m 6 p m 9 a m 2 a m 6 p m 9 a m 2 a m 4a m 4a m 8 p m 1 1 a m 4 a m 8 p m 1 1 a m 4 a m 8a m 8a m 1 0 p m 1 p m 6 a m 1 0 p m 1 p m 6 a m 12p m 12pm  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 114  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 114 Illustration 26: BW landscape and availability / maintenance• Code pages in different languages have to be supported BW is Unicode-compatible. Concrete solution scenarios have to be agreed with BW product management.2003 SAP AG AND SAP AMERICA, INC. 31

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.05.4.3 Inside-Out Landscape Architecture - BW as Central Enterprise Data WarehouseIt is indisputable that business-wide, consistent information can soonest be guaranteed where thereis a central BW instance offering data warehouse layer services. This means the business-wideconsolidation of all relevant data in a granular, integrated, non-volatile, unflavored and subject-oriented form.William H. Inmon forwards this solution in the ‘corporate information factory’. BW as Central Enterprise Spoke BW BW Enterprise Enterprise Data Warehouse (EDW) Data BW Warehouse Spoke BW Scenario BW Enterprise Data Warehouse: BW Data Warehouse layer as ‘single point of truth’ for the entire corporation  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 111  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 111 Illustration 27: BW as Corporate Information FactoryAll data that acts as the basis for tactical and strategic data marts has to go through the enterprisedata warehouse.Extraction straight into data marts, ignoring the enterprise data warehouse, is not permitted.Exceptions have to be controlled. There must be a strategy in place for using these data marts as thebasis for operative reporting, as well as for using the enterprise data warehouse itself for operativereporting.A landscape of this sort with the inherent demands • „single point of truth” and • “extract once, deploy many”offers the ideal prerequisites for controlling redundancy at corporate level.It is often assumed that this solution, although ideal, is practically unrealizable. Without going into thearguments in detail, it is sufficient to say that this is not necessarily the case for BW customers.2003 SAP AG AND SAP AMERICA, INC. 32

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0Many large companies that operate globally make a large investment in order to unify their operativelandscapes by implementing SAP R/3. As a result, the ideal prerequisites for a central enterprise datawarehouse approach emerge: integration of data (common coding), integration of data models intothe SAP R/3 data model, the building of an operative R/3 landscape, which takes the companyorganizational and technical conditions into account.In other words, a centralized approach in the operative environment leads directly to a solution optionfor the enterprise data warehouse topology. This type of ’ideal’ environment is often found in ’singledivision’ enterprises that find themselves in strongly competitive environments and as a result, have ahigh sense of awareness for the usage of more reliable and efficient IT solutions. This awarenessmostly involves a high degree of support from the highest management level for a BW enterprise datawarehouse solution. Inside-Out: Enterprise Spoke BW BW Enterprise Central BW Instance Covers All Data BW Warehouse Spoke BW Scenario Inside-Out: Central EDW BW Instance Covers All External Data Marts PSA BW Architected Data Marts BW EDW tactical/ strategic Staging Area operational like reporting integrated reporting non-volatile no flavor less granular aggregated granular BW ODS operational/ near real time reporting granular  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 110  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 110 Illustration 28: Scalability of a BW Corporate Information Factory IA BW enterprise data warehouse based landscape will be implemented incrementally for costreasons. Often, first a BW instance will be built that offers data warehouse layer as well as data martlayer services, including operative-level reporting.Obviously the aim of the enterprise data warehousing strategy also has to be to source all externaldata marts with data from the BW enterprise data warehouse only!It is then possible to separate reporting and analysis services as the load increases.2003 SAP AG AND SAP AMERICA, INC. 33

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 Inside-Out: Central EDW BW Instance Enterprise Spoke BW BW Enterprise and BW Spoke Instances Data BW Warehouse Spoke BW Scenario Inside-Out: Central EDW BW Instance as Information HUB Architected Data Marts Spoke Instances External Data Marts PSA BW ODS  operational/ near real time reporting BW ODSgranular  operational reporting BW Architected Data Marts BW ODS granular operational reporting granular tactical/ operational like PSA reporting Corporate BW  less granular Data Mart Staging Area tactical/ strategic aggregation BW EDW operational like  reporting reporting integrated consistent aggregated granular  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 112  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 112 Illustration 29: Scalability of a BW Corporate Information Factory IITo summarize, the conditions for a central BW enterprise data warehouse solution are always mostfavorable within a ‘single division company’ with ‘strong’ headquarter.5.4.4 Outside-In Landscape Architecture - Decentralized BW Data WarehousesEven where it is preferable to have a single BW enterprise data warehouse for the whole enterprise,the complexity of the different business areas in a company that operates globally can lead to sharedBW landscapes. On this issue William H. Inmon says: ‘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‘Often political circumstances or a company’s lack of an over-arching concept lead to shared BWlandscapes too, even when the business conditions seem to be favorable.Enterprises that choose diversification should generally check that the outlay involved in integratingdata on a granular level, as required with the enterprise data warehouse approach, is not greaterthan the benefit.Even when the ideal prerequisites exist such as for a ‘single division’ enterprise, certain conditions (aregional enterprise structure, for example, without process integration between the regions), coupledwith technical and political factors, can lead to an enterprise moving away from the central BWenterprise data warehouse concept.This leads to a landscape that comprises several ‘local’ BWs. ‘Local’ here means that one of theseBWs covers only one part of the organization. The description of what ‘local’ can mean in individualcases depends on the size and the complexity of the company.2003 SAP AG AND SAP AMERICA, INC. 34

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0Each ‘local’ BW should operate like an enterprise data warehouse for its own area. In this way, thesum of the ‘local’ enterprise data warehouses forms a quasi virtual enterprise data warehouse.Unlike the central enterprise data warehouse that requires all corporate data to be integrated atgranular data level, this is not necessary with ‘local’ enterprise data warehouses, although it is stillpreferable. Each ‘local’ enterprise data warehouse necessarily ensures a ‘local’ granular dataintegration.Having a landscape architecture based on ‘local’ BWs means that for over-arching reporting andanalysis, at least one additional integration layer is required to consolidate the data from the ‘local’BWs.A BW that consolidates the data from other BWs and offers this in an integrated form is called a‘global’ BW. Again, the term ‘global’, and the scope of a particular ‘global’ BW can only be defined onan individual, company-specific basis. Architected Multiple BW Landscape Global Global BW Headquarter Divisional Global BW Division A BW Europe BW Americas BW Asia Regional Data Marts ODS Data Marts ODS Data Marts ODS virtual Data Warehouse Data Warehouse Data Warehouse BW Enterprise Staging Data Staging Staging Staging Warehouse Local R/3-ERP mySAP R/3-ERP R/3-ERP R/3-ERP Europe I CRM Americas I Americas II Asia  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 128  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 128 Illustration 30: ‘Local - Global’ BW LandscapeIn terms of an enterprise’s data integration strategy, it is important that master data harmonizationtakes place on an aggregated level (global BW)1.In these terms a ’global’ BW of this sort is always an integrator.1 Integration is then only demanded at the higher hierarchy levels of a ’subject area’ or dimension.This is generally easier to achieve than integration at granular level. As a result, a topology of thiskind often mirrors the integration strategy of an enterprise that does not choose granular ‘commoncoding’.2003 SAP AG AND SAP AMERICA, INC. 35

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0The situation of ’local’ BWs or legacy systems with respect to harmonization determines theintegration efforts at global BW site:1. ‘Local’ BWs are to be integrated I. It is the task of the ’global’ BW to gather data from ‘local’ BWs (Data values are already ’common coded’, local-global data models are integrated, a data model architecture exists) II. It is the task of the ’global’ BW to consolidate and harmonize data (mapping) (Data values are not ’common coded’, local-global data models are integrated, data model architecture exists) III. It is the task of the ’global’ BW to consolidate and harmonize data (mapping) and to integrate the local-global data models. (A data model architecture either does not exist, or is not controlled. Statements about model consistency cannot be made without doing individual checks.)2. ’Local’ BWs and legacy systems are to be integrated I. For legacy systems data and data model integration is necessary.These scenarios copy the different corporate data warehousing strategies. The essential differencelies in whether ‘local’ and ‘global’ BWs are developed according to common architecture guidelines(scenario 1.I and 1.II). If this is the case we can talk about an ‘architected outside-in BW landscape’.This harmonized, architecture-based interaction of local and global BW instances is a serious optionfor building a BW based corporate data warehousing strategy from the very beginning. It is supportedby the central development of BW templates for ‘local’ reporting and analysis. Architected Multiple BW Landscape: BW Template Roll-Out Global Global BW Headquarter Divisional Global BW Division A BW template roll-out BW Europe BW Americas BW Asia Regional Data Marts ODS Data Marts ODS Data Marts ODS virtual BW Enterprise Data Warehouse Data Warehouse Data Warehouse Data Staging Staging Staging Staging Warehouse Local R/3-ERP mySAP R/3-ERP R/3-ERP R/3-ERP Europe I CRM Americas I Americas II Asia R/3 template roll-out  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 139  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 139 Illustration 31: Architected Multiple BW Landscape and BW Template roll-out2003 SAP AG AND SAP AMERICA, INC. 36

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0However, if dealing with a mature BW landscape, you will probably echo scenario 1.III and scenario2. There is obviously only a restricted corporate strategy for ‘local’ BWs and it is the task of the‘global’ BW to take the first step towards a corporate strategy (‘catch the BWs scenario’). Focus on Integration and Headquarter Reporting → Global BW as the Corporate Integrator BW BW Global Global BW BW BW BW others local local others local local ERP/ Legacy ERP/ Legacy Legacy/ Files Illustration 32: Global BW as corporate Integrator2003 SAP AG AND SAP AMERICA, INC. 37

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.06 Central BW Application DevelopmentAs well as the need for consistent information on all organizational levels, avoiding redundantapplication development (data marts) is also a motivation for a business-wide BW strategy.Redundant application development poses a constant threat to data consistency. Redundantapplication development is often accompanied by a certain arbitrariness in the management ofpersistent data stores and BW data models.The general solution approach is to develop applications or templates for all the organization units ofan enterprise centrally.To what extent applications are generated on a ’local’ level (local-local applications) and/ or corporatetemplates are adaptable locally, is always company-specific. It is symptomatic that this decision isinfluenced more by political than functional factors.Two extreme positions stand out regarding the local management of templates:• Stable templates No local changes to the central template are permitted• Example templates The centrally produced template acts as an example only.The first is self-evident: The fewer changes are allowed to the central template, the easier the centralfurther development and maintenance of these templates, and the better it is for overall consistencyin the BW.The description of this scenario sounds very rigid. This is not entirely true as it can work very well iflocal ‘power users’ are allowed to generate BW queries for template InfoProviders andMultiProviders2 within this scenario. It is then possible to define, for example, local virtual multi-dimensional and flat structures, local KPIs, selections, and layouts.In the ’stable template’ scenario, the template is transported in the form of the active version of thetemplate metadata (A versions).If a local application development is intended in addition to central application development, thisnormally means that local development systems exist. If a central template is changed in thisenvironment, importing a new version of the central template in the A version (see above) willoverwrite local adaptations.As of BW Version 3.5 the generation of customer content is possible to support this scenario.This enables you to generate and transport meta objects in a D version, as is the case with BusinessContent. An import into the local target system does not affect the existent active meta objects. Metaobjects are merged with existing objects only when the D version is activated. When there areconflicts, how to proceed must be resolved locally.2 InfoProvider: InfoCube, ODS objects; MultiProvider: Union of InfoCubes and/ or ODS objects.2003 SAP AG AND SAP AMERICA, INC. 38

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 Content Delivery at the Customer Site Customer Content System (Headquarter) M(odified) 11 11 22 A(ctive) 11 11 Export (D Object) 11 11 create activate change import Subsidiary M(odified) 11 44 A(ctive) 11 11 D(elivery) 11 11 11 Content activation change  SAP AG 2003, Enterprise Data Warehousing based on SAP BW, J. Haupt 149  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 149 Illustration 33: BW Customer ContentIf locally adapting the central template is permitted an additional type of persistent data store is addedlocally: ‘distilled data’. These are data stores (usually ODS objects) whose structure and method offilling cannot be changed locally as they serve to prepare data for over-arching ‘global’ reporting. If itcan be changed locally, the central template can no longer fill these roles.The different structures of a ‘local’ BW instance illustrates the following picture. standardized source for corporate defined corporate reporting local reporting distilled corporate local defined local local reporting Local BW Data Structures Illustration 34: BW Customer Content2003 SAP AG AND SAP AMERICA, INC. 39

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.07 Data and Data Model IntegrationIntegration is the central issue from a corporate point of view. In the data warehouse area thisprimarily concerns the integration of data from different sources and the integration of data modelsfrom different operative components.Data integration in BW directly addresses the topic Master Data Management and the SAP solutionMDM (Master Data Management).7.1 Challenges Posed by Data IntegrationBoth the data warehouse layer and the data mart layer make integrated data available by definition.But data integration in corporate terms is easier said than done. As such integrating data fromdifferent sources is often the greatest challenge3.The harmonization of data is therefore not a fact of enterprise data warehousing scenarios, but ratherthe aim. Even when all operative systems deliver ‘common coded’ data, you always have toanticipate that data that cannot be integrated may also be delivered in the future because of companyacquisition.The result of this is that data that cannot be integrated during load time has to be saved in the BW.Recognizing this in good time is essential. The status of the master data has to be investigated andthe enterprise-wide data harmonization strategy has to be considered carefully. This will allow laterdata harmonization without having to make adjustments.If data cannot be integrated then the different sets of data have to be separated so that they do notoverwrite each other. Not Common Coded Source-Keys as BW-keys *>> Introducing new Sources later BW-KEY Conformed Dimension/ 0MATERIAL Text InfoObject Master Data M1 PIPES S2 CONSULTING BW-KEY 0MATERIAL Date Quantity M1 S2 20020601 20020601 100 200 ? InfoCube Fact-table M1 20020601 100 M1 PIPES M1 PUMP S2 20020601 200 S2 CONSULTING S22 CONSULTING Transaction Data Master Data Master Data Later Introduction of Sourcesystem R/3-1 R/3-2* the technical BW implementation is more sophisticated - the key issue exist anyhow3 With restricted BW implementations data harmonization is often not a central issue. You maytherefore only come up against the data harmonization task later when the BW is implemented as anenterprise-wide data warehouse solution.2003 SAP AG AND SAP AMERICA, INC. 40

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0Illustration 35: Source system key as BW key?There are several ways in which this situation can be controlled with BW. For one, by using namespaces different data models can be maintained in BW for the different operative systems that cannotbe integrated. Data stores are then separated automatically too.This approach is not recommended for an enterprise, however, it is an option for application centers(which offer BW services for different enterprises).As separating data using different data models is only advisable in odd cases, data should actually beseparated in data structures defined by a common data model. This is done by extending the keystructure of the BW InfoObject affected using a ‘separator’. In the most straightforward of cases thisseparator will contain origin information (source systems).BW supports separation through concatenation and compounding. Concatenation BW-Key Concatenated- Separator Text Key U1004711 U1 AUDI U2004711 U2 BMW Build Key Build Key U1 Separator U2 Source-Value 004711 AUDI 004711 BMW Source-System 1 Source-System 2 Illustration 36: Key value concatenationConcatenation means the data model is not affected. The key values are simply extended by theseparator. This can happen centrally in the BW using general transfer rules. Here we have a dataseparation option that can be influenced by the user and which it is possible to modify at a later date.With compounding on the other hand, the key column of the InfoObjects affected are extended to asource system column. This can be done per InfoObject and is automatically supplied by the BW.Separation is handled by the BW and the database. However this has the disadvantage that it cannotbe removed again later (for example, after subsequent integration).We favor concatenation as compounding has further functional limitations when handling complexheterogeneous integration scenarios and is inflexible because of automatism.Using InfoObject master data navigation attributes (conformed dimension attributes) in queries,instead of concatenated InfoObjects, makes realignment to the common coded values after amigration possible. Adjustments to queries are then obsolete. This is illustrated in the next graphic:2003 SAP AG AND SAP AMERICA, INC. 41

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0 Power of BW Navigational Attributes Concatenated- Query access Key Group-ID 0MATERIAL Separator IMATERIAL Text S1004711 S1 00000123 AUDI S4004711 S4 00000456 BMW 00000123 00 00000123 AUDI 00000456 00 00000456 BMW InfoCube Fact Table realigned material Date 0MATERIAL Amount numbers after migration 20020930 S1004711 100 20020930 S4004711 200 20021001 00000123 300 Query results after migration 20021001 00000456 400 Text 0MATERIAL 2002 entries before migration AUDI S1004711 100 BMW S4004711 200 entires after migration AUDI 00000123 300 BMW 00000456 400 Text IMATERIAL 2002 AUDI 00000123 400 BMW 00000456 600 Illustration 37: Navigation attributes support the flexibility of BW solutions7.2 Data Model IntegrationThird party and legacy applications, and even different SAP components such as R/3 and EBP(Enterprise Buyer Professional), use different semanitics for, for example, product terms. For thisreason there are different subject areas for products in BW (InfoObjects). These various productviews are consolidated again by ‘consolidated’ InfoObjects. Cross-Component Integration: Product Global and consolidated views 0PRODUCT on products, independent from source component 0MATERIAL 0SERVICE 0BBP_PROD 0CRM_PROD Component restricted Analytics IS: Material IS: Service IS: BBP Prod IS: CRM Prod DataSources R/3 Material R/3 Service EBP Product CRM Product Source Components individual data R/3 R/3 R/3 R/3 EBP R/3 CRM R/3 R/3 R/3 R/3 R/3 models  SAP AG 2003, Corporate Data Warehousing based on SAP BW, J. Haupt 44  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 44 Illustration 38: Model integration with consolidated InfoObjects2003 SAP AG AND SAP AMERICA, INC. 42

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0This obviously does not resolve the challenge of making a common coded key available for theconsolidated view 0PRODUCT. SAP MDM functionalities offer support in this respect.7.3 The Role of SAP Master Data Managements (MDM)Corporate master data management is a topical issue. SAP offers SAP MDM (Master DataManagement).4Active master data management, the central management and distribution of master data, will not beexamined any more closely here. If a central master data management exists, BW is a potential clientand the overall corporate reporting and analysis is a beneficiary.More interesting are the possibilities offered by MDM in complex, business-wide BW scenarioswithout harmonized data. Master data from different source systems can be analyzed forcommonalities and a grouping (group ID) corresponding to common coding suggested.This passive functionality is termed ‘content consolidation’. mySAP MDM Master Data Consolidation Content Consolidation MDM MDM Core Process Steps: Client SAP 1. Loading identifying attributes of master data objects as they were maintained in their local Client applications (clients) non SAP Load Client non SAP ? 2. Matching of uploaded master data Matching objects to identify duplicates Client SAP = 3. Providing ID Mapping Information ID Mapping based on matching results for subsequent usage (I.e. in Client Business Intelligence) non SAP Description of a master data object: Identifying Attributes  SAP AG 2003, Corporate Data Warehousing based on SAP BW, J. Haupt 45Other application specific data  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 45 Illustration 39: SAP MDM master data consolidationThe mapping information (group ID) is then a navigation attribute of the InfoObject to be harmonizedin BW (see Illustration 37: Navigation attributes support the flexibility of BW solutions). This can alsobe added afterwards without interfering with the existing schemata.4 Integration between BW and MDM will be offered as of Release BW 3.5.2003 SAP AG AND SAP AMERICA, INC. 43

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0SAP MDM supports the model consolidation scenario described in 7.2 (Data Model Integration)through ’master data harmonization’ by means of consolidated InfoObjects for an analysis that spanscomponents.Keys of different InfoObjects are checked in MDM for commonalities, mapped to a group ID, andmaintained centrally as attributes that span InfoObjects. Master Data Harmonization MDM MDM Master data harmonization Client SAP Core Process Steps: 1. Central Creation of master data Local + Creation objects just covering the global information of the master data object Client non SAP 2. Local Creation within the master data Central Local environment of the application Creation Completion system (client) and distributing their 1.234.237 € global information to MDM =? 6.674.288 € 634.237 € 3. Continuous matching processes Matching & 4.002.531 € 737.108 € identify duplicates and result in + ID Mapping = 13.282.401 € ID Mapping between them Client 4. Distribution of global master data SAP information to the various clients 5. Local Completion of master data Distribution within the local environment Client 6. Use of ID Mapping information for non SAP Analytics MDM Analytics like business-wide analyses etc. Description of a master data object: Globally relevant Data  SAP AG 2003, Corporate Data Warehousing based on SAP BW, J. Haupt 46(Client) specific Data  SAP AG 2001 BW - The Open Business Intelligence Platform/ J. Haupt / 46 Illustration 40: SAP MDM master data harmonizationAs well as active master data management, MDM supports key consolidation and complex masterdata harmonization through deferred (asynchronous) consolidation. The flexibility of the conformeddimension in BW allows the ’extended star schemas’ to be subsequently enhanced with informationfrom the MDM, without interfering with existing solutions.2003 SAP AG AND SAP AMERICA, INC. 44

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.08 SummaryImportant elements of a corporate BW strategy are architecture, consistent application developmentand data integration concepts.A corporate BW architecture is essential to mid- and long-term success. An architecture of this kindmanifests itself in design and procedural guidelines that are valid enterprise-wide, and in their control.BW supports various aspects of the architecture through a multitude of functionalities that secureconsistency. It is up to each individual enterprise to determine how and to what extent thesefunctionalities are used.A central development of BW application templates is an adequate way to support a corporate wideBW architecture and harmonization.Integration of data is an ongoing challenge. BW is tightly integrated with SAP’s MDM and offers inaddition various design options to meet integration requirements. This has to be considered in a BWstrategy.Coming to the end we want to repeat once more the main statement of this paper:The top priority of any corporate BW strategy must always be to control redundancy. This istrue for each individual BW, and for the interaction of all the BWs within an enterprise!2003 SAP AG AND SAP AMERICA, INC. 45

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0Table of IllustrationsIllustration 1: Evolution of the SAP BW ................................................................................................ 2Illustration 2: Redundancy and Solution focus ..................................................................................... 3Illustration 2: Redundancy and multiple BW landscape ....................................................................... 4Illustration 3: The conceptual layer architecture of data warehousing ................................................. 7Illustration 4: The BW extended star schema .................................................................................... 11Illustration 5: Horizontal consistency in the BW architected data mart layer ..................................... 11Illustration 6: BW and slowly changing dimensions ........................................................................... 12Illustration 7: Persistent and virtual multidimensional structures in BW............................................. 13Illustration 8: SAP BW data warehouse layer..................................................................................... 14Illustration 9: BW data warehouse layer and vertical consistency ..................................................... 16Illustration 10: Example - BW data warehouse: Historization of master data .................................... 17Illustration 11: Example - BW data warehouse: Transaction data ..................................................... 18Illustration 12: BW staging.................................................................................................................. 19Illustration 13: Classic data warehousing ........................................................................................... 20Illustration 14: Classic data warehousing supports operatives reporting........................................... 21Illustration 15: BW operational data store: Near real time data warehousing.................................... 22Illustration 16: BW and operational / real time reporting .................................................................... 23Illustration 17: Operational data model and data warehouse data model......................................... 24Illustration 18: Data warehouse data models and the situation for BW customers............................ 25Illustration 19: Enterprise data model and enhanceable BW data model: InfoObjects...................... 25Illustration 20: BW data model: InfoSources and subject areas ....................................................... 26Illustration 21: BW data model: data mart layer data model ............................................................. 27Illustration 22: BW data model: Data warehouse layer data model .................................................. 28Illustration 23: The ideal corporate BW landscape?........................................................................... 29Illustration 24: Enterprise-wide strategies and BW architecture ........................................................ 30Illustration 25: BW landscape and availability / maintenance ............................................................ 31Illustration 26: BW as Corporate Information Factory ........................................................................ 32Illustration 27: Scalability of a BW Corporate Information Factory I................................................... 33Illustration 28: Scalability of a BW Corporate Information Factory II.................................................. 34Illustration 29: ‘Local - Global’ BW Landscape................................................................................... 35Illustration 30: Architected Multiple BW Landscape and BW Template roll-out................................. 36Illustration 31: Global BW as corporate Integrator ............................................................................. 37Illustration 32: BW Customer Content ................................................................................................ 39Illustration 33: BW Customer Content ................................................................................................ 39Illustration 34: Source system key as BW key? ................................................................................. 412003 SAP AG AND SAP AMERICA, INC. 46

ENTERPRISE DATA WAREHOUSING WITH SAP BW – AN OVERVIEW V2.0Illustration 35: Key value concatenation............................................................................................. 41Illustration 36: Navigation attributes support the flexibility of BW solutions ....................................... 42Illustration 37: Model integration with consolidated InfoObjects ........................................................ 42Illustration 38: SAP MDM master data consolidation ......................................................................... 43Illustration 39: SAP MDM master data harmonization ....................................................................... 442003 SAP AG AND SAP AMERICA, INC. 47

Enterprise data warehousing with sap bw overview

by esteban donoso on Jan 27, 2011

Accessibility

Upload Details

Usage Rights

Statistics

Enterprise data warehousing with sap bw overview — Document Transcript