multi-dimensional modeling en
TRANSCRIPT
-
8/6/2019 Multi-Dimensional Modeling En
1/73
Multi-Dimensional Modelingwith BWASAP FOR BW A CCELERATORBUSINESS I NFORMATION WAREHOUSE
A background to the techniques used tocreate SAP BW InfoCubesDocument Version 2.0
SAP (SAP America, Inc. and SAP AG) 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 impliedwarranties 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
-
8/6/2019 Multi-Dimensional Modeling En
2/73
MULTI -DIMENSIONAL MODELING WITH BW
Table of ContentsMULTI-DIMENSIONAL MODELING WITH BW..................................................................................1
ASAP FOR BW A CCELERATOR .........................................................................................................................1
TABLE OF CONTENTS...............................................................................................................................2
INTRODUCTION..........................................................................................................................................1
1. S OFTWARE VERSION SUPPORTED ......................................................................................................................12. R EFERENCES .................................................................................................................................................13. O VERVIEW ....................................................................................................................................................1
FROM MULTI-DIMENSIONAL MODEL TO INFOCUBE STEP ONE............................................5
1. T HE GOALS OF MULTI -DIMENSIONAL DATA MODELS .............................................................................................52. S UBJECT AREA..............................................................................................................................................53. T HE ROLE OF BW B USINESS CONTENT .............................................................................................................54. B ASIC MODELING STEPS ...............................................................................................................................6
1. Step 1: Develop a complete understanding of the underlying business processes............................ ..7 1. Entities and the relations between them...........................................................................................................72. Reaping benefits of BWs Business Content....................................................................................................93. Step 2: Create a valid Schema........................................................................................................................104. The Multi-Dimensional Model (MDM).........................................................................................................105. The Star Schema............................................................................................................................................106. Step 3: Create an InfoCube Description ........................................................................................................137. Resume..........................................................................................................................................................14
STAR SCHEMA BASICS AND MODELING ISSUES...........................................................................15
1. H OW THE STAR SCHEMA WORKS ..................................................................................................................152. S TAR SCHEMA ISSUES ..................................................................................................................................16
MULTI-DIMENSIONAL SCHEMAS IN BW....................................................................................... ...18
1. O VERVIEW .................................................................................................................................................182. C ONNECTING MASTER TABLES TO I NFOCUBES .................................................................................................203. D IMENSIONS IN A BW SCHEMA ....................................................................................................................21
1. Master Data Table..............................................................................................................................241. Reference Characteristic Assignment.............................................................................................................242. Master Table Existence..................................................................................................................................243. Assigning Attributes.......................................................................................................................................244. Attributes and Querying.................................................................................................................................245. InfoObject names and names of attributes......................................................................................................256. Time Dependent Attributes............................................................................................................................257. Compound Attributes.....................................................................................................................................27
2. Text Tables....................................................................................................................................... ...27 3. SID Tables...........................................................................................................................................27
1. InfoObject definition and SID tables..............................................................................................................27(figure 28).........................................................................................................................................................29SID Tables Maintenance...................................................................................................................................29InfoCube Access and SID Tables......................................................................................................................29
2. External Hierarchy Table...............................................................................................................................313. External hierarchy formats.............................................................................................................................314. Tables for external hierarchies.......................................................................................................................325. Loading external hierarchy data.....................................................................................................................326. External hierarchies and InfoCube access......................................................................................................32
4. Dimension tables of an InfoCube........................................................................................................331. Defining dimension tables..............................................................................................................................332. Columns of a dimension table........................................................................................................................333. Limitations.....................................................................................................................................................344. Dimensions and navigation............................................................................................................................35
5. Loading data into dimension tables................................................................................................................356. Special BW dimensions.................................................................................................................................351. Packet dimension.......................................................................................................................................35
-
8/6/2019 Multi-Dimensional Modeling En
3/73
MULTI -DIMENSIONAL MODELING WITH BW
2. Unit/ Currency Dimension.........................................................................................................................357. Dimensions with only one characteristic (line item dimensions)....................................................................35
4. F ACT TABLE ................................................................................................................................................371. Multiple fact tables.............................................................................................................................37 2. Fact table partitioning........................................................................................................................383. BW Terminology ................................................................................................................... ........ ....39
4. Modeling issues and the BW schema..................................................................................................405. G RANULARITY ............................................................................................................................................411. Fact tables and granularity................................................................................................................412. Impacts on Storage.............................................................................................................................423. Impacts on Performance ....................................................................................................................424. Location of dependent attributes in the BW schema...........................................................................425. Performance and location of dependent attributes ............................................................................436. Enterprise data warehouse and location of dependent attributes .....................................................437. Data load and the location of dependent attributes............................................................................448. Tracking history in the BW schema....................................................................................................449. History and InfoCube..........................................................................................................................4410. Slowly Changing Dimensions...........................................................................................................45
1. Scenario I: Report the data to todays constellation - today is yesterday........................................................47
1. Scenario I: Description..............................................................................................................................472. Report the data to yesterdays constellation as well -yesterday is today ........................................................501. Scenario II : Description............................................................................................................................50Scenario II: Solutions with BW....................................................................................................................51
Scenario III: Report the data to the respective constellation-today or yesterday-..............................................532. Scenario III: Description............................................................................................................................53Scenario III: Solution with BW................. ............. ............. ............. ............. ............. ............. ............. ........54
3. Scenario IV: Description............................................................................................................................5511. Usage of time scenarios ...................................................................................................................5812. M:N relationships.............................................................................................................................5913. M:N relationships and the fact table................................................................................................5914. M:N relationships within a dimension .............................................................................................59
1. Designing M:N relationships using the dimension table.................................................................................592. Designing M:N relationships using a compound attribute..............................................................................60
3. Frequently Changing Attributes (Status Attributes)........................................................................................604. Inflation of dimensions...................................................................................................................................615. Multiple process reporting scenarios..............................................................................................................616. MultiCubes.....................................................................................................................................................62
15. Partitioning Attributes .....................................................................................................................651. Attribute or fact (key figure)..........................................................................................................................66
6. T HIS WOULD ALLOW NAVIGATION ON PRICES USING EXTERNAL HIERARCHIES . ........................................................677. S AME CHARACTERISTIC SEVERAL TIMES IN THE MODEL :......................................................................................678. A RTIFICIAL KEY FIGURES ...............................................................................................................................67
1. Factless fact tables..............................................................................................................................67 2. Counting..............................................................................................................................................67
9. B IG DIMENSIONS ..........................................................................................................................................671. Hierarchies in the BW schema............................................................................................................682. Hierarchies within a Dimension.........................................................................................................683. Hierarchies within a master data table of a characteristic................................................................694. External Hierarchies...........................................................................................................................69
-
8/6/2019 Multi-Dimensional Modeling En
4/73
MULTI -DIMENSIONAL MODELING WITH BW
IntroductionThis document provides background information on the techniques used to create InfoCubes,
the multi-dimensional structures within SAP BW, and provides suggestions to help thecustomer in understanding when to apply the various techniques available.
1. Software Version SupportedThis document applies to BW Version 2.0B or higher.
2. ReferencesFor more detailed information on the SAP BW Architecture please refer to The BW ODS
Whitepaper and to the paper Hierachies in BW.
3. OverviewBW version 2.0 was a major step in the evolution of the BW architecture and functionality.Most important in terms of architecture was the introduction of the new BW OperationalData Store (BW ODS).Note: The new BW ODS introduced with version 2.0B is not to be confused with the ODS layer inversion 1.2B. This layer has been renamed in Version 2.0B as Persistent Staging Area (PSA).
The BW ODS is a multi-level layer in the BW data warehouse that offers the functionality tostore the results of data cleansing and data transformation processes in transparent tablescalled ODS Objects. In so doing the BW ODS forms the historical foundation of the datawarehouse.
To enable process integration, multiple BW ODS Objects can feed other ODS Objects or InfoCubes. Business rules can be applied in the integration process. The number of ODSObjects in the integration chain is not limited in BW.
The BW architecture graphic (see fig.01, p.2) illustrates that InfoCubes should be founded onthe integration layer for transactional data in the BW ODS. Furthermore the InfoCubes arelinked to common master reference data located in master data tables, text tables, and(external) hierarchy tables. Thus the BW infrastructure provides the structure for buildingInfoCubes founded on a common integrated basis. This approach allows for partial solutions
based on a blueprint for an enterprise-wide data warehouse.
2000 SAP AG AND SAP A MERICA , INC . 1
-
8/6/2019 Multi-Dimensional Modeling En
5/73
MULTI -DIMENSIONAL MODELING WITH BW
BW Information Integration Architecture
SAPSAPR/3R/3APOAPOCRMCRMBBPBBP
LegacyLegacy
ExternalExternalProviderProvider
E x
t r a c
t i o n
Master DataMaster Data
PSAPersistent Staging Area
SourceSystems
ETL Tools
Meta Data
PSAPSA
BW Operational Data StoreBW Operational Data Store
InfoCubesInfoCubes
B u s
i n e s s
R u
l e s
BW ODSBW Operational Data Store
InfoCubes
C l e a n s
i n g
& T r a n s
f o r m a
t i o n
End-UserData Access
Ad HocAd HocQueriesQueries
ReportingReporting ApplicationsApplications ModelsModels
B u s
i n e s s
R u
l e s
SchedulingScheduling MonitoringMonitoring ChangeChangeManagementManagement
ServiceServiceManagementManagement
Granularity
Integration
(figure 01)
In the context of this paper, additional functionality is also offered through the ability toreport on members of the BW ODS Objects.With regard to InfoCubes, BW ODS Objects can either be accessed directly or serve asdrilldown targets. (see fig.02, p.3)
Which BW structure (InfoCubes or ODS-Objects) to use as the foundation for reporting andanalysis, and in what circumstances, is not discussed in this paper but in The BW ODS Whitepaper .
The focus of this paper is how to support Online Analytical Processing (OLAP) in BW.OLAP functionality is one of the major requirements in data warehousing. In short, OLAPoffers even un-experienced end-users the capability to analyze business process data (KPIs)in terms of the business lines involved. Normally this is done in stages, starting with businessterms showing the KPIs on an aggregate level, and proceeding to business terms on a moredetailed level.
2000 SAP AG AND SAP A MERICA , INC . 2
-
8/6/2019 Multi-Dimensional Modeling En
6/73
MULTI -DIMENSIONAL MODELING WITH BW
BW Information Access Architecture
LegacyLegacy
ExternalExternalProviderProvider
Master DataMaster Data
ETL Tools
Meta Data
PSAPSA
BW Operational Data StoreBW Operational Data Store
InfoCubesInfoCubes
SchedulingScheduling MonitoringMonitoring ChangeChangeManagementManagement
ServiceServiceManagementManagement
BWBusiness Explorer WebGraphical User Interf
SAP-ModelsAdvanced PlanningEnterprise MangemCRM
Third Party Tools
(ODBC/ ODBO)
SAPSAPR/3R/3APOAPOCRMCRMBBPBBP
PSAPersistent Staging Area
SourceSystems
BW ODSBW Operational Data Store
InfoCubes End-UserData Access
(figure 02)
A simple example:
Sales Organisation Product Organisation Time KPIsSales Department Material Group Year Sales AmountSales Person Material Type Month Sales Quantity
Material Day
A multi-step multi-dimensional analysis will look like this:1. Show me the Sales Amount by Sales Department by Material Group by Month2. Show me the Sales Amount for a specific Sales Department X by Material by Month
Analytical processing of this type is normally done using InfoCubes.
An ODS-Object may serve to report on a single record (event) level such as:Show yesterdays Sales Orders for Sales Person Y.
This does not mean that sales order level data cannot reside in an InfoCube but rather thatthis is dependant upon particular information needs and navigation.
ODS Object should not be misused for multi-dimensional analysis.
2000 SAP AG AND SAP A MERICA , INC . 3
-
8/6/2019 Multi-Dimensional Modeling En
7/73
MULTI -DIMENSIONAL MODELING WITH BW
There are no hard and fast rules about the architecture of an enterprise data warehouse andthis will not be discussed in any further detail here. It is important to bear in mind that thisdocument deals only with the building of one part of a data warehouse with reusable objects,namely InfoCubes, with master data, and (external) hierarchies.
In Chapter 2 this document provides initial information concerning the transition from aninformation need to the common multi-dimensional data model / Star schema. As the BWschema is based on the Star schema, an introduction to the Star schema will be given inChapter 3, and some general aspects explained. The BW schema is explained in detail inChapter 4, where modeling aspects that are derived directly from the BW schema are alsoexplained. Chapter 5 deals with time aspects in the BW schema and further demands whichmight have to be designed with BW.
2000 SAP AG AND SAP A MERICA , INC . 4
-
8/6/2019 Multi-Dimensional Modeling En
8/73
MULTI -DIMENSIONAL MODELING WITH BW
From Multi-Dimensional Model to InfoCube Step
OneThis chapter deals with the basic stages of multi-dimensional data modeling to foster a basicunderstanding for the more detailed discussions that follow. The experienced reader maytherefore want to skip this chapter.
1. The goals of multi-dimensional data modelsThe overarching goals of multi-dimensional models are:
To present information to the end-user in a way that corresponds to his normalunderstanding of his business i.e. to show the KPIs, key figures or facts from thedifferent perspectives that influence them (sales organization, product/ material or time).
In other words, to deliver structured information that the end-user can easily navigate byusing any possible combination of business terms to illustrate the behavior of the KPIs. To offer the basis for a physical implementation that the software recognizes (theOLAP engine), thus allowing a program to easily access the data required.
The Multi-Dimensional Model (MDM) has been introduced in order to achieve the first. Themost popular physical implementation of multi-dimensional models on relational databasesystem-based data warehouses is the Star schema implementation. SAP BW uses the Star schema approach and extends it to support integration within the data warehouse, to offer easy handling and allow high performance solutions.
2. Subject AreaAs this paper describes the process of modeling BW InfoCubes, it is assumed that the subjectarea for which we want to create a solution is well defined. It may become apparent duringthe modeling stages that the best solution would be to implement more than one InfoCube.The criteria on which this decision should be made will be discussed in a separate chapter.
3. The role of BW Business ContentThe SAP BW package is not an empty box but comes with a wide range of Business Content ,ready-to-load InfoCube schemas at solution level and queries on these. It is thereforequestionable whether BW data modeling needs to be discussed in general terms, and wherethe source data is from R/3 applications it is not essential. But even in such cases theinformation needs of the end-user must first be understood before these can be comparedwith the Business Content.Business Content InfoCubes, and the Business Content InfoSources (data structures offered
by R/3 applications) in particular, do at least help shorten the modeling process. BusinessContent and how to benefit from it in the modeling process is not discussed here as this isdone in separate papers.
If, however, an InfoCube is to be created based partly or entirely on non-R/3 applications(legacy systems), this general process offers a proven approach.
2000 SAP AG AND SAP A MERICA , INC . 5
-
8/6/2019 Multi-Dimensional Modeling En
9/73
MULTI -DIMENSIONAL MODELING WITH BW
4. Basic Modeling StepsThese steps should be understood as a general approach. To what extent they must becarried out depends on the actual situation and the experience of the project membersinvolved.
After deciding on the subject area being dealt with, the basic steps to implementing a SAPBW based solution are (see fig.03, p.6):1.1. Focus on the structure of informationFocus on the structure of information
Develop a complete understanding of the underlying business processes(E.g. create an Entity Relationship Model [Diagram] of the business model)
The ERM as a function of the information2.2. Focus on analytical needs - Overcome model complexityFocus on analytical needs - Overcome model complexity
Create a valid schemaTranslate the ERM to the MDM / Star schema
The MDM as a function of the analytical processing3.3. Build the solution as a part of an integrated data warehouseBuild the solution as a part of an integrated data warehouse
The schema on the BW stage the InfoCubesTranslate the MDM / Star schema to one or more InfoCube schemas
Sales Rep ID
LastNameSalesDep
Material ID
Material NameMaterial TypeMaterial Group
Customer ID
Customer NameCityRegionOffice Name
Time Code ID
Year Fiscal Year Quater MounthDay of the Week
Material ID
Sales Rep IDTime Code IDCustomer ID
Sales AmountQuantityUnit Price
Time DimensionCustomer Dimension
Sales Org DimensionMaterial Dimension
FACT
Material DIM IDOrgStr DIM IDTime Code ID....
Quantity.....
SalesRep ID
Last Name...
Material DIM ID
Material IDMatType
Material ID
Mat.descriptionMatType...
OrgStr. DIM ID
SalesRepSalesDep
SalesDep ID
Address...
Focus on analytical needs - Overcome model complexity
Build the solution as a part of an integrated data warehouse
MDM/ Star Schema
SAP BW
ERM
Focus on the structure of information
(figure 03)
2000 SAP AG AND SAP A MERICA , INC . 6
-
8/6/2019 Multi-Dimensional Modeling En
10/73
MULTI -DIMENSIONAL MODELING WITH BW
1. Step 1: Develop a complete understanding of the underlying businessprocesses
In this step we focus on the structure structure of information:
1. Entities and the relations between them
There are no strict rules on how to develop a complete understanding of the underlying business process. Nevertheless using an Entity Relationship Model (ERM) is a good way of seeing the relevant business objects and their relationships. Depending on the particular circumstances and the extent of personal experience, it will sometimes be sufficient just todraw a diagram showing the entities and their relationships.
Tools like VISIO or Erwin or any other modeling tool are very useful here.
Examples may be the most efficient means of providing an understanding of how to approacha Multi-Dimensional Model / Star schema and eventually a valid BW implementation, and of introducing basic terms.
E.g. If the end-user describes his information needs and subject area as,
Track the performance of materials with respect to customers and sales persons
The following nouns relate to the end-users information needs: Material Customer Sales Person
The nouns are basic business terms and are usually called Strong Entities (see fig.04) :
Customer Material Sales Person
(figure 04)
Ask the end-user about the relationship between his basic business terms (strong entities). Normally the relationship between strong entities are N:M Relationships i.e. a customer can purchase multiple materials and materials can be purchased by multiple customers (seefig.05):
Customer Material Sales Person
(figure 05)
Ask the end-user how performance is measured.
2000 SAP AG AND SAP A MERICA , INC . 7
-
8/6/2019 Multi-Dimensional Modeling En
11/73
MULTI -DIMENSIONAL MODELING WITH BW
This will give you the basic Facts . Facts are normally additive and describe n:mrelationships. In a business scenario with a working document this document forms anIntersection Entity which often resolves the n:m relationships to 1:n relationships. In thefirst instance, however, it is up to the end-user whether or not to include the workingdocument in the model when analysing, for example, a sales transaction level (see fig.06):
Customer
Sales Transaction
Material
Material group
Sales Person
Sales Department
Intersection Entity
(figure 06)
In the next stage the customer is asked to be more precise and, in this case, determine that additional details for material, customer and sales person are also required.This gives you additional entities and attributes where attributes are the describing fields of an entity. In ERM diagrams attributes show the fields in relational tables.
The attributes demonstrate to what extent it is possible to store data concerning this entity(see fig.07, p.9)
It is useful for the following steps to ask the end-user for details concerning relationshipsbetween entities and relationships between entities and their attributes.
This draws your attention to any abnormal situations like n:m relationships between anentity and an attribute (s. material and color). These relationships have to be treated carefully(see fig.08, p.9).
2000 SAP AG AND SAP A MERICA , INC . 8
-
8/6/2019 Multi-Dimensional Modeling En
12/73
MULTI -DIMENSIONAL MODELING WITH BW
Customer
Material Sales Person
Material group Sales Department
Customer noCustomer nameCity Region
Material noMaterial nameMaterial typecolor
price
Material group noMaterial group name....
Sales TransactionDateCustomer noMaterial noSales pers no
Amount Quantity Currency
Sales pers. noSales pers. name.......
Sales dep. noSales dep. location.......
(figure 08)
Customer
City
Region
Material Group
Sales order
Price
Sales Person
Sales Dept.
Sales Dept. Loc.
Material
Material TypeColor
(figure 09)
After completing these steps you will have a good idea about the business terms involved andhow the relationships between them are configured. This provides a good basis for amultidimensional model.
2. Reaping benefits of BWs Business Content
In SAP product-based scenarios the Business Content InfoSources provide a good basis onwhich to identify the entities, attributes and facts (key figures) of the underlying subject area.As BW provides InfoSources ordered by applications, it is easy to identify the InfoSource(s)which cover(s) your subject area. If the subject area is based on customer-generatedstructures like LIS and CO-PA you have to refer to these structures. The result is normally acomplete set of entities and attributes. The relationships can be derived from the SAP productdata model if they are not obvious.
2000 SAP AG AND SAP A MERICA , INC . 9
-
8/6/2019 Multi-Dimensional Modeling En
13/73
MULTI -DIMENSIONAL MODELING WITH BW
Even if the solution is not entirely SAP product based, or you plan to migrate a source legacysystem to R/3 for example in the future, the respective InfoSources should be considered.
3. Step 2: Create a valid Schema
This crucial step aims to overcome model complexity by focusing on analytical needs (seefig.10).
Sales Rep ID
LastNameSalesDep
Material ID
Material NameMaterial TypeMaterial Group
Customer ID
Customer NameCityRegionOffice Name
Time Code ID
Year Fiscal Year Quater MounthDay of the Week
Material IDSales Rep IDTime Code ID
Customer IDSales AmountQuantityUnit Price
Time DimensionCustomer Dimension
Sales Org DimensionMaterial Dimension
FACT
Focus on analytical needs - Overcome model complexity
MDM/ Star Schema
ERM
(figure 10)
Overcoming model complexity involves the creation of a schema that is comprehensible forboth the end-user and the software.
4. The Multi-Dimensional Model (MDM)(Publications by Ralph Kimball, as referred to below, provide the details for the multi-dimensional data model).Comprehensibility for the end-user is reached by organizing entities and attributes fromstep 1 that are arranged in a parent-child relationship (1:N), into groups. These groups arecalled dimensions and the members of the dimensions dimension attributes, or attributes.The strong entities define the dimensions. For the end-user the attributes of a dimensionrepresent a specific business view on the facts (or key figures or KPIs), which are derivedfrom the intersection entities. The attributes of a dimension are then organized in ahierarchical way and the most atomic attribute that forms the leaves of the hierarchy definesthe granularity of the dimension. Granularity determines the detail of information. Thismodel is called Multi-Dimensional Model (MDM). The Multi-Dimensional Model, wherethe facts are based in the center with the dimensions surrounding them, is a simple buteffective concept that is easily recognized by technical resources as well as by the end-user.
5. The Star SchemaThe Star schema offers comprehensibility for software. The Star schema is the most
popular way of implementing a Multi-Dimensional Model in a relational database.Snowflake schemas are an alternative solution although BW InfoCubes are based on a Star schema, and a short introduction to its main terms and capabilities will now be given here.
2000 SAP AG AND SAP A MERICA , INC . 10
-
8/6/2019 Multi-Dimensional Modeling En
14/73
MULTI -DIMENSIONAL MODELING WITH BW
In a Star schema, one dimension represents one table. These dimension tables surround thefact table , which contains the facts (key figures), and are linked to that fact table via uniquekeys, one per dimension table. Each dimension key uniquely identifies a row in theassociated dimension table. Together these dimension keys uniquely identify a specific rowin the fact table (see fig.11).
Star Schema
Sales RepSales Rep IDID
LastNameSalesDep
Material IDMaterial ID
Material NameMaterial TypeMaterial Group
Customer Customer IDID
Customer NameCity
RegionOffice Name
Time Code IDTime Code ID
Year Fiscal Year
Quater MounthDay of the Week
Material IDMaterial IDSales RepSales Rep IDIDTime Code IDTime Code IDCustomer Customer IDID
Sales AmountQuantity
TimeDimension
(Table )
Customer Dimension
(Table )
Sales Org Dimension
(Table )
Material Dimension
(Table )
FACT (Table )
(figure 11)
The key elements of a Star schema are:
Central fact table with dimension tables shooting off from it Fact tables typically store atomic and aggregate transaction information, suchas quantitative amounts of goods sold. They are called facts Facts are numeric values of a normally additive nature Fact tables contain foreign keys to the most atomic dimension attribute of each dimension table Foreign keys tie the fact table rows to specific rows in each of the associateddimension tables The points of the star are dimension tables Dimension tables store both attributes about the data stored in the fact tableand textual data Dimension tables are de-normalized The most atomic dimension attributes in the dimensions define thegranularity of the information, i.e. the number of records in the fact table
2000 SAP AG AND SAP A MERICA , INC . 11
-
8/6/2019 Multi-Dimensional Modeling En
15/73
MULTI -DIMENSIONAL MODELING WITH BW
The Fact Table (fig.12) :
Customer Customer StreetStreet SalesPersSalesPers SalesRegionSalesRegion MaterialMaterial UnitUnit DateDateDate
Customer SalesPers Material Date Amount Quantity
Ides G mbh Meier Monitor 981118 1000 2
Customer SalesPers Material Date Amount Quantity
Ides Gmbh Meier Monitor 981118 1000 2
Ides Gmbh Meier Monitor 981118
(figure 12)
The basic process of mapping an ERM to the MDM/ Star schema is shown on the following
graphic (fig.13):
Sales Rep ID
LastNameSalesDep
Material ID
Material NameMaterial TypeMaterial Group
Customer ID
Customer NameCityRegionOffice Name
Time Code ID
Year Fiscal Year Quater MounthDay of the Week
Material IDSales Rep IDTime Code IDCustomer IDSales AmountQuantityUnit Price
Time DimensionCustomer Dimension
Sales Org DimensionMaterial Dimension
FACT ??
Customer
City
Region
Material Group
Sales order
Price
Sales Person
Sales Dept.
Sales Dept. Loc.
Material
Material TypeColor
(figure 13)
2000 SAP AG AND SAP A MERICA , INC . 12
-
8/6/2019 Multi-Dimensional Modeling En
16/73
MULTI -DIMENSIONAL MODELING WITH BW
General Mapping Guidelines
Fact Table:
A central intersection entity defines a Fact Table. An intersection entity such as documentnumber is normally described by facts (sales amount, quantity), which form the non-key
columns of the fact table. In fact, M:N relationships between strong entities meet eachother in the fact table, thus defining the cut between dimensions Dimensions (Tables):
Attributes with 1:N conditional relationships should be stored in the same dimension suchas material group and material.
The foreign -> primary key relations define the dimensions Time:
One exception is the time dimension. As there is no correspondence in the ERM, timeattributes (day, week, year) have to be introduced in the MDM process to cover the
analysis needs.These considerations provide a starting point for dimension analysis, but additionalconsiderations will impact on the grouping of the attributes and will be discussed in detaillater.
6. Step 3: Create an InfoCube DescriptionBuild the solution within BW, respecting analytical needs, and as part of an integrated datawarehouse.Translating the MDM/ Star schema (the results of Step 1 and Step 2) into an InfoCubedescription is of course the topic of this paper and will be investigated in the followingchapters in depth.An initial introduction is given in the following graphic (see fig.14, p.14):
2000 SAP AG AND SAP A MERICA , INC . 13
-
8/6/2019 Multi-Dimensional Modeling En
17/73
MULTI -DIMENSIONAL MODELING WITH BW
Translate the MDM/ Star Schema into an InfoCube Description:
Sales Rep ID
LastNameSalesDep
Material ID
Material NameMaterial TypeMaterial Group
Customer ID
Customer NameCityRegionOffice Name
Time Code ID
Year Fiscal Year Quater MounthDay of the Week
Material IDSales Rep IDTime Code IDCustomer ID
Sales AmountQuantityUnit Price
Time DimensionCustomer Dimension
Sales Org DimensionMaterial Dimension
FACT
MDM/ Star Schema
SAP BW
Material DIM IDOrgStr DIM IDTime Code ID....Quantity.....
SalesRep ID
Last Name...
Material DIM ID
Material IDMatType
Material ID
Mat.descriptionMatType...
OrgStr. DIM ID
SalesRepSalesDep
SalesDep ID
Address...
(figure 14)
7. ResumeIn his book The Data Warehouse Toolkit, Ralph Kimball writes:The nine database design decision points for a dimensional data warehouse consist of deciding on the following:
1. The processes, and hence the identity of the fact tables ( [one fact table - one InfoCube] -> intersection entities )
2. The dimensions of each fact table ( -> strong entities ) 3. The dimension attributes with complete descriptions and proper terminology ( ->
attributes and entities )4. The grain of each fact table5. The facts, including pre-calculated facts6. How to track slowly changing dimensions7. The aggregations, heterogeneous dimensions, mini-dimensions, query modes and other
physical storage decisions8. The historical duration of the database (archiving aspects)9. The urgency with which the data is extracted and loaded into the data warehouse (time
frame for loading)
2000 SAP AG AND SAP A MERICA , INC . 14
-
8/6/2019 Multi-Dimensional Modeling En
18/73
MULTI -DIMENSIONAL MODELING WITH BW
Star Schema Basics and Modeling IssuesIn the previous chapter we introduced the Star schema. As most of the relevant properties for modeling derive directly from these schemas, we will now have a closer look to them. Westart with the Star schema as it is the force behind the BW schema and is also easier tounderstand. These basics will also help you to develop a fundamental understanding of themodeling properties of the BW schema before that is discussed in the next chapter. Weemphasize that this chapter discusses the Star schema and not the BW schema
1. How The Star Schema WorksHow the result of a query is evaluated using a Star schema can best be shown through thisexample (fig.15): If we need the following information,
Show me the sales amount for customers located in 'New York' with materialgroup 'XXX' in the year = '1997'
Star Schema
Sales RepSales Rep IDID
LastNameSalesDep
Material IDMaterial ID
Material NameMaterial TypeMaterial Group
Customer Customer IDID
Customer NameCityRegionOffice Name
Time Code IDTime Code ID
Year Fiscal Year Quater MounthDay of the Week
Material IDMaterial IDSales RepSales Rep IDIDTime Code IDTime Code IDCustomer Customer IDID
Sales AmountQuantity
TimeDimension
(Table)
Customer Dimension
(Table)
Sales Org Dimension
(Table)Material
Dimension(Table)
FACT (Table)
(figure 15)
The answer is determined in two stages: Browsing the Dimension Tables
Access the Customer Dimension Table and select all records with City= 'New York' Access the Material Dimension Table and select all records withMaterial group = 'XXX' Access the Time Dimension Table and select all records with Year ='1997'
As a result of these three browsing activities, there are a number of key values(Customer IDs, Material IDs, Time Code ID ), one from each dimension tableaffected. Accessing the Fact Table
2000 SAP AG AND SAP A MERICA , INC . 15
-
8/6/2019 Multi-Dimensional Modeling En
19/73
MULTI -DIMENSIONAL MODELING WITH BW
Using the key values evaluated during browsing, select all records in the fact tablethat have these values in common in the fact table record key.
2. Star Schema IssuesWith respect to the processing of a query and the design of the Star schema we realize that:
Reflecting real world changes in the Star schema
How real-world changes are dealt with, i.e. how the different time aspects are handledis the most important topic with data warehouses.
Star-I. The role of the fact table
The Star schema reflects changes in the real world normally by adding rows to thefact table. More precise real world changes like Customer 4711 purchase Material BBB at Day 19980802 for $100 creates a new record in the fact table, which isidentified by the combination of key attributes in the dimension tables. In this casethe customer number, material ID and the day (fig.16):
Changes in the real world -> new rows in the fact table
Materialgroup Material
X AAA
X BBB
Y CCC
Y DDD
Materialgroup Material
X AAA
X BBB
Y CCC
Y DDD
Material Customer Day Revenue
AAA 4711 19980901 100
BBB 4712 19980901 100
CCC 4712 19980901 100DDD 4712 19980901 100
BBB 4711 19980902 100
Material Customer Day Revenue
AAA 4711 19980901 100
BBB 4712 19980901 100
CCC 4712 19980901 100DDD 4712 19980901 100
BBB 4711 19980902 100
Material Dimension Table
Fact Table
BBB 4711 19980902 100
Transaction record
Add new recordto fact table
Customer Custgroup
4711...........................
4712...........................
Customer Custgroup
4711...........................
4712...........................
Day Month Year
19980901 .....................
19980902 .....................
Day Month Year
19980901 .....................
19980902 .....................
Customer Dimension Table Time Dimension Table
Accessing new recordin fact table
Star-II. The role of dimension tables There are also changes between the attribute values of attributes within the samedimension (e.g. the material X no longer belongs to material group Y but tomaterial group Z). Usually these changes occur more or less frequently and intheory they are therefore called slowly changing dimensions. How these changesare dealt with has a big impact on reporting possibilities and data warehousemanagement. The different possible time scenarios and how to solve these withinBW are discussed in detail in the next sections.
2000 SAP AG AND SAP A MERICA , INC . 16
-
8/6/2019 Multi-Dimensional Modeling En
20/73
MULTI -DIMENSIONAL MODELING WITH BW
Reporting
Star-III. Reports can be created by accessing the dimension tables (master datareporting).
Star-IV. The Star schema saves information about events that did or did not happen (e.g.
reporting the revenue for the customers in New York within a certain time spanwould show the customers that have revenue, but not the customers that have norevenue).
Aggregation
Star-V. Only the information at the granularity of the dimension table keys (materialID, customer ID, time code ID, sales rep ID) need to be stored to make any desiredaggregated level of information available.
Star-VI. More precisely: any summarized information can be retrieved at run time i.e. as far as functionality is concerned, there is no need to store pre-calculated aggregateddata, but with large ( number of rows) fact tables and / or large dimension tables,
pre-calculated aggregates must be introduced for performance reasons.Attribute Relationships (Hierarchies)
In the Star schema there is one (real) attribute (most granular) as the uniqueidentifier of each dimension table row joining the fact table. The other attributes of a dimension table are normally parents of such identifying attributes, thus the termhierarchy. With hierarchies numerous challenges must be resolved:
Star-VII. N:M relationship within a dimension.There is no simple way to handle an N:M relationship between two attributes withina dimension table (such as materials with different colors). If material is the lowestlevel, it is not possible to put both material and material color into one normal star dimension table, as we would have one material value associated with multiplecolors. As such, material is no longer a unique key.
Star-VIII. No leaf attribute values.Again there is no easy way to handle transactional input to a Star schema where thefacts are offered at different attribute levels, whereby the attributes belong to thesame dimension. For example, assume the attributes material and material groupexist in the same dimension. Some subsidiaries can offer transactional data atmaterial level whereas others can only offer data at material group level. The resultin the latter case is dimension table rows with blank or null values for the material,which destroys the unique key material.
Star-IX. Unbalanced hierarchiesVery often we have attributes in a dimension where a relationship exists betweensome attribute values, whereas with others there is none. As the relations betweenattribute values of different attributes within a dimension form a tree that will resultin paths of differing lengths from root to leaves, these unbalanced hierarchies will
produce reports with dummy hierarchy tree nodes.
Table Sizes and Performance
2000 SAP AG AND SAP A MERICA , INC . 17
-
8/6/2019 Multi-Dimensional Modeling En
21/73
MULTI -DIMENSIONAL MODELING WITH BW
Star-X. Do not destroy browsing performance. Dimension tables should have a'relatively' small number of rows (in comparison to the fact table; factor at least1:10 to 1:20).
Schema MaintenanceStar-XI. There are no limitations to the Star schema with respect to the number of
attributes in the dimension and fact tables, except the limitations caused by theunderlying relational database.
Star-XII. Flexibility regarding the addition of characteristics and key figures to theschema is caused by properties of relational databases.
Multi-Dimensional Schemas in BWBased on experience with the Star schema, the SAP BW schema uses a more sophisticatedapproach to guarantee consistency in the data warehouse and to offer schema-basedfunctionality to cover the end-users analysis needs.Creating a valid multi-dimensional schema in BW means that you always have to bear inmind the overall enterprise data warehouse requirements and the solution-specific analysisand reporting needs. Errors in this area will have a deep impact on the solution, resulting in
poor performance or even an invalid schema.
1. OverviewThe graphic shows a multi-dimensional BW schema using the example from the previouschapters. Only those parts that are important as far as modeling is concerned are included(fig.17).
2000 SAP AG AND SAP A MERICA , INC . 18
-
8/6/2019 Multi-Dimensional Modeling En
22/73
MULTI -DIMENSIONAL MODELING WITH BW
FACT Table
G e b i e t 1G e b i e t 2G e b i e t 3
B e z i r k 1
G e b i e t 3 a
B e z i r k 2
R e g i o n 1
G e b i e t 4G e b i e t 5
B e z i r k 3
R e g i o n 2
G e b i e t 6
B e z i r k 4
G e b i e t 7G e b i e t 8
B e z i r k 5
R e g i o n 3
V e r t r i e b s o r g a n i s a t i o n
Material Group
Material Hierarchy TableMaterial_Dimension_IDSalesOrg_Dimension_IDTime_Dimension_IDCustomer_Dimension_ID
Sales AmountQuantity
Material Number Language Code
Material Number Language Code
Material Name
Material Text TableMaterial_Dimension_IDMaterial Number
Material Dimension Table
Material Master Table
Material Number Material Number
Material Type
SalesRep Master Table
SalesRep Number SalesRep Number
Sales DEP
SalesRep Number Language Code
SalesRep Number Language Code
SalesRep Name
SalesRep Text Table
Customer Number Language Code
Customer Number Language Code
Customer Name
Customer Text Table
Customer Master Table
Customer Number Customer Number
City
RegionTime_Dimension_ID
Year Quater MounthDay
Time Dimension Table
SalesOrg_Dimension_IDSales Rep Number
SalesOrg SalesOrg DimensionDimension TableTable
Customer_Dimension_ID
Customer Number
Customer Dimension Table
CustomerCustomer DimensionDimension
InfoCubeInfoCube
TimeTime DimensionDimension
MaterialMaterialDimensionDimension
SalesOrgSalesOrg DimensionDimension
Observations:The center of a multidimensional schema in BW forms the fact table.In BW the facts of the fact table are called key figures (e.g. sales amount).The fact table is surrounded by dimensions.A dimension consist of different table types:
Dimension TableIn BW the attributes of the dimension tables are called characteristics (e.g.material).The meta data object in BW that describes characteristics and also key figures(facts) is called InfoObject.
Master Tables:Master Data Table
Dependent attributes of a characteristic can be stored in a separate table calledthe Master Data Table for the characteristic. In BW they are calledterminology attributes (e.g. material type).
Text TablesTextual descriptions of a characteristic are stored in a separate text table . Thesystem runs in different languages at a time.
2000 SAP AG AND SAP A MERICA , INC . 19
-
8/6/2019 Multi-Dimensional Modeling En
23/73
MULTI -DIMENSIONAL MODELING WITH BW
External Hierarchy TablesHierarchies of characteristics or attributes may be stored in separate hierarchytables . For this reason these hierarchies are named external hierarchies (e.g.standard cost center hierarchy from R/3-CO for the characteristic cost center).
ImportantThe use of the term hierarchy in BW is a possible point of confusion. Thenormal understanding of hierarchy is defined as a sequence of parent-child relationships between characteristics. From this perspective, there arehierarchies in the dimension tables, master tables, and in hierarchy tables.
The multi-dimensional schema in BW is separated into two parts:1. The InfoCube, which describes the process-oriented part of the solution. An InfoCubeconsist of One fact table and
Several dimension tables (fig.18, p.20)
The InfoCube the solution-dependent part of the schema
(figure 18)
2. The solution-independent shared master tables valid for use with any InfoCube andBW ODS Object in the data warehouse.These master tables are the glue that binds the data warehouse and are discussed indepth in the next chapter.
2. Connecting Master Tables to InfoCubes
In order to be able to cover all requirements master tables in a BW Schema are not linkeddirectly to InfoCubes, as the following, simplified, picture illustrates (fig.19):
2000 SAP AG AND SAP A MERICA , INC . 20
-
8/6/2019 Multi-Dimensional Modeling En
24/73
MULTI -DIMENSIONAL MODELING WITH BW
Multi-Dimensional Schema in BW
Text
SID Tables
Master
Hierarchies
Hierarchies
Master
SID Tables
Text
Hierarchies
Master
SID Tables
Text
Hierarchies
Master
SID Tables
Text
Hierarchies
Master
SID Tables
Text
Hierarchies
Master
SID Tables
Text
Text
SID Tables
Master
Hierarchies
Text
SID Tables
Master
Hierarchies
Text
SID Tables
Master
Hierarchies
DimensionTable
Text
SID Tables
Master
Hierarchies
DimensionTable
DimensionTable
DimensionTable
DimensionTable
Hierarchies
Master
SID Tables
Text
FACT
(figure 19)As you can see, pointer or translation tables called SID (Surrogate-ID) tables are used in theBW schema to link the solution-independent master tables of the BW schema to InfoCubes.
The graphic shows a simplified version of what types of SID tables exist and their tasks arediscussed in detail in the section on the SID table.
3. Dimensions in a BW schemaEarlier we introduced some basic rules in defining dimensions on the results of prior analysis:
Attributes with 1:N conditional relationships should be stored in the same dimensionsuch as material group and material.
The foreign -> primary key relations define the dimensions.
Once a decision on the members of a dimension has been made we have to consider thata dimension in the BW schema might consists of different parts (fig.20):
2000 SAP AG AND SAP A MERICA , INC . 21
-
8/6/2019 Multi-Dimensional Modeling En
25/73
MULTI -DIMENSIONAL MODELING WITH BW
G e i t 1G e i tG e i t
B e z i r k 1
G e i t
B e z i r k
R e i 1
G e i t 4G e i t
B e z i r k
R e i
G e i t
B e z i r k 4
G e i tG e i t
B e z i r k
R e i
V e r t r i s r i s t i
Material Group
Material Hierarchy Table
Material Number Language Code
Material Number Language Code
Material Name
Material Text TableMaterial_Dimension_ID
Material Number
Material Dimension Table
Material Master Table
Material Number Material Number
Material Type
MaterialMaterialDimensionDimension
(figure 20)
We emphasize that:Dimensions in a BW schemaThe dependent attributes of the characteristics can reside in different locations of a BWschema dimension.
One of the primary goals of this paper is to show the different modeling aspects that result in
a different location of an attribute in a dimension of a multi-dimensional BW schema (fig.21, p.22).
Material
Material Dimension
Materialgroup
MaterialDimension table
As a Characteristic As a Characteristic ? ? MaterialMaster table
As a Navigational As a Navigational / / Display Display Attribute Attribute ? ?
MaterialHierarchy table
As a Hierarchy As a Hierarchy ? ?
2000 SAP AG AND SAP A MERICA , INC . 22
-
8/6/2019 Multi-Dimensional Modeling En
26/73
MULTI -DIMENSIONAL MODELING WITH BW
(figure 21)
As the graphic shows, the material-material group relation can be designed defining materialgroup
Either as a characteristic i.e. member of a material dimension table
Or as an attribute i.e. member of the material master table Or as a node-describing attribute of the material hierarchy table Or as any combination of the above options.
Which option best fits individual needs depends primarily on the desired time aspects in your queries, and is discussed in chapter 5.
Important
To avoid confusion we emphasize:
In BW the terms characteristic and attribute refer only to the different locations in the
schema. As shown above, even within the same schema material group can occur as acharacteristic in the material dimension table and as an a ttribute of material in the material master data table.
When no reference is being made to specific schema location (as with the meta datadefinition), the term InfoObjects of type characteristic is used.
2000 SAP AG AND SAP A MERICA , INC . 23
-
8/6/2019 Multi-Dimensional Modeling En
27/73
MULTI -DIMENSIONAL MODELING WITH BW
1. Master Data TableIn defining an InfoObject of type characteristic you have the following modeling-relevantoptions with respect to the definition of the Master Data Table.
1. Reference Characteristic Assignment
When defining an InfoObject of type characteristic you are asked whether you want to refer to an existing other characteristic. If you do, beside others, the new characteristic will havethe master table of the referred characteristic.
For example: the characteristics sending cost center and receiving cost center refer to thesame characteristic 0COSTCENTER and thus the same master tables.
2. Master Table Existence
Does a master data table exist at all? (tab page: Master data -> Check box)
This allows you do add InfoObjects as attributes in the attribute tab page section.
For example, in your schema all attributes of a document number may be assigned to other characteristics such as customer or material.
3. Assigning Attributes
The attributes of a characteristic that will reside in its master data table are determined in themodeling phase. The attributes are added using the attributes tab page in InfoObjectmaintenance.
These attributes form the communication structure for the InfoSource to load the master data.
4. Attributes and QueryingWhether an attribute can potentially be used for query navigation (such as drilldown, up,across, or within) on an InfoCube or ODS Object can be individually defined (attribute tab
page-> navigational check boxes). If you mark the navigation check box of an attribute thisattribute is called a navigational attribute.
Note: you have to activate the navigational attributes in the InfoCube definition to allownavigation with respect to this InfoCube.In terms of navigation, navigational attributes behave like characteristics in an InfoCube. Butthe reporting behavior of the navigational attributes in master tables differs from thecharacteristics behavior.
Attributes not used for navigation are called display attributes. If an InfoObject of typecharacteristic is an attribute and not marked as a navigational attribute then it is only possibleto report this attribute in conjunction with a characteristic or with a navigational attribute.For attributes of type key figure the following applies:
InfoObjects of type key figure are always display attributes. If you want to calculate a query with an attribute it has to be an InfoObject of type key
figure.
2000 SAP AG AND SAP A MERICA , INC . 24
-
8/6/2019 Multi-Dimensional Modeling En
28/73
MULTI -DIMENSIONAL MODELING WITH BW
5. InfoObject names and names of attributesIt is possible to create schemas that have the same InfoObject for the characteristics in thedimension table of an InfoCube, and for the navigational attribute of another characteristicalso in the InfoCube. To avoid confusion you should give the navigational attribute a namedifferent to its characteristic name. The name is defined in the attribute tab page for each
navigational attribute.For example:The InfoObject MMATERIAL is in the InfoCube while MMATGR is a navigational attributefrom MMATERIAL. Let us assume that MMATGR is a result of a model that is also acharacteristic in the InfoCube. Material group is the name of the InfoObject MMATGR. If you were to use the same name (material group) for the navigational attribute, this wouldoccur twice in the InfoCube description of the query builder, most certainly confusing theend-user.
6. Time Dependent AttributesEach attribute can be defined individually as being time dependent .
The following example illustrates the different behavior of non-time dependent and timedependent attributes.Example: non-time dependent attributes :The InfoObject material has the attribute MatType and we are only interested in using thelatest materials - MatTypes constellations within reports.MatType is defined as a non-time dependent attribute (there is no check in the timedependent check box). Let us assume that material BBB has MatType 300 in 09 1998. Anew assignment of MatType 200 to material BBB in 10 1998 would then overwrite theold constellation. The material MatType assignments are stored in the non-time dependentattribute master data table (fig.22):
Material MatType
AAA 100
BBB 200
CCC 100
DDD 100
Non-Time Dependent Attribute Master Data Table(table name: /BIC/PMaterial )
(figure 22)
Example: Time Dependent Attributes :The InfoObject material has the attribute MatGroup. We are also interested in former materials MatGroup constellations. MatGroup is defined as a time dependent attribute(there is a check in the time dependent check box). Let us assume that material BBB hasMatGroup X. Then, from October, 1 st 1998 a new assignment of MatGroup Y to materialBBB is valid. The result is a new record in the time dependent attribute master datatable with the respective validity. The old constellation gets only a new date to value(fig.23):
2000 SAP AG AND SAP A MERICA , INC . 25
-
8/6/2019 Multi-Dimensional Modeling En
29/73
MULTI -DIMENSIONAL MODELING WITH BW
Material DateFrom DateTo MatGroup
AAA 01 / 1000 12 / 1999
X
BBB 01 / 1000 09 / 1998 X
BBB 10 / 1998 12 / 9999 YCCC 01 / 1000 12 / 9999 Y
DDD 01 / 1000 12/9999 Y
Time Dependent Attribute Master Data Table(table name: /BIC/QMaterial)
(figure 23)
One important aspect regarding modeling must be emphasized:Time Dependent Attributes and Querying
During a single query execution only ONE characteristc value time dependent attributevalue constellation can be addressed!Addressing a specific constellation is done via the query key date.The key date is valid for all time dependent attribute assignments that are used in the query.
To summarize the following points:
There is one time dependent check box for each attribute in the attribute tab pagesection.
Time dependency of an attribute allows you to keep track on the changes over time of therelation of the characteristic and the time dependent attribute values.
In terms of technical implementation, two master data tables exist if we have both non-time dependent and time dependent attributes. One master data table stores all relations to non-time dependent attributes(name of the table: /BIC/ P infobjectname) and One table stores relations to time dependent attributes (name of the table:/BIC/ Q infobjectname).
The time dependent attributes master data table has additional DATETO andDATEFROM system attributes. In queries the different constellations are addressed usingthe key date (-> Query properties). The validity attributes are not available for navigation.
Note: The table names of BW business content InfoObjects start with /BI0/ ...A closer look at the reporting possibilities of time dependent attributes is given in chapter 5.
Important
There are no pre-calculated aggregates at time-dependent attribute level!
2000 SAP AG AND SAP A MERICA , INC . 26
-
8/6/2019 Multi-Dimensional Modeling En
30/73
MULTI -DIMENSIONAL MODELING WITH BW
7. Compound Attributes
Characteristics may not be unique i.e. another attribute is necessary to allow the data to be addressed. Example: the InfoObject 0COSTCENTER (cost center) offered from R/3applications is only unique with the InfoObject 0CO_AREA (Controlling Area).
Additional attributes can be defined in the compound tab page section of InfoObjectmaintenance.
2. Text TablesThe text table of an InfoObject of type characteristic keeps the descriptions of thecharacteristic values. The existence of a text table and different description types as short,middle and long text descriptions and language dependency can be defined in the master datatab page section.The text table, or better the description attributes, may be defined as time dependent.Transfer rules may be applied during text data load.
3. SID Tables
SID tables play an important role in linking the data warehouse information structures to thesubject-oriented InfoCubes and ODS Objects.
To speed up access to InfoCubes and to allow an InfoCube and ODS-Object independentmaster data layers, each characteristic and attribute is assigned a SID column and their valuesare encoded into 4-byte integer values.
Note:The algorithm to determine a SID value works fastest if the characteristic does not exceed thenumerical size of nine as in this case the characteristic values will be the SID. No traditionalSID table has to be accessed as the characteristic or attribute values correspond 1:1 to their SIDs.
1. InfoObject definition and SID tables
To offer optimal performance with the various schemas with respect to master data access,three different SID tables might be generated.
SID tables with respect to master data:
The traditional SID table, we know from earlier versions, is always generated if anInfoObject is not defined as attribute only (tab page general). This table is used if theaccess to an Infocube or ODS-Object uses a navigational attribute or if the access is via acharacteristic without attributes.
The non-time dependent attribute SID table of a characteristic for access via non-timedependent attributes.
The time dependent attribute SID table of a characteristic for access via timedependent attributes.
2000 SAP AG AND SAP A MERICA , INC . 27
-
8/6/2019 Multi-Dimensional Modeling En
31/73
MULTI -DIMENSIONAL MODELING WITH BW
Example:Supposing the InfoObject material has both non-time dependent and time dependentattributes. The activation of this InfoObject generates the following tables (for illustration
purposes we will use the example from the master table section):
Material master table for non-time dependent attributes : /BIC/P material (fig.24)
Materia l l AAABBBCCCDDD
Non-Time Dependent Attribute Master Data(table name:
Material master table for time dependent attributes : /BIC/Q Material (fig.25)
Material DateFrom DateTo MatGroup AAA 01 / 1000 12 / 9999 X BBB 01 / 1000 09 / 1998 X BBB 10 / 1998 12 / 9999 Y CCC 01 / 1000 12 / 9999 Y DDD 01 / 1000 12/9999 Y
Time Dependent Attribute Master Data Table (table name: /BIC/QMaterial)
Material SID table ( traditional SID table) : /BIC/S Material (fig.26)
Material-SID Material
001 AAA 002 BBB 003 CCC 004 DDD
Traditional SID Table (table name: /BIC/SMaterial )
Material non-time dependent attribute SID table : /BIC/X Material (fig.27)
Material-SID Material MatType-SID 001 AAA 22222 002 BBB 33333 003 CCC 22222 004 DDD 22222
Non-Time Dependent Attribute SID Table (table name: /BIC/XMaterial)
2000 SAP AG AND SAP A MERICA , INC . 28
-
8/6/2019 Multi-Dimensional Modeling En
32/73
MULTI -DIMENSIONAL MODELING WITH BW
Material time dependent attribute SID table : /BIC/Y Material (fig.28)
Material-SID MatGroup - 001 AAA / 1000 12 / 9999 910
002 BBB / 1000 09 / 1998 002 BBB / 1998 12 / 9999 920003 / 1000 12 /9999 004 DD
/ 1000 12/9999 920
Time Dependent Attribute SID (table name:
(figure 28)
SID Tables Maintenance
All these SID tables are automatically maintained during master data load.SID tables are maintained during InfoCube load if no referential integrity check is enforced(InfoPackage).
InfoCube Access and SID Tables
To get an understanding of the function of these SID tables a simple example is given as tohow the result of a query is evaluated. If we need the following information:
Show me the sales amount for customers located in 'New York' with material group'X' and Y in the year = '1999'
Let us assume that the material group is a navigational attribute (non-time dependent) of thecharacteristic material in the material master data table and we have no predefined aggregatesat material group level.
How the different material dimension tables operate together to access the InfoCube facttable is shown in the following picture (fig.29, p.29):
2000 SAP AG AND SAP A MERICA , INC . 29
-
8/6/2019 Multi-Dimensional Modeling En
33/73
MULTI -DIMENSIONAL MODELING WITH BW
1 1 2 2 3 3
111 111 222 222 333 333
Dim ID SID Material
Fact table Dimension table
Material not time dependent Attributes SID table (Name: /BIC/XMATERIAL)
Material Non-timeAttributes SID table (Name: /BIC/XMATERIAL)
Material MatGroup
AAA CCC DDD
X Y Y
Material Master table (Name: /BIC/PMATERIAL)
Material Master table (Name: /BIC/PMATERIAL)
1 1 2 2 3 3
10.000 12.000 25.000
Dim ID Sales
SID Material Material SID MatGroup
AAA CCC DDD
111 111 222 222 333 333
345 345 678 678 678 678
MatGroup SID MatGroup
X Y Z
345 678 999 MatGroup SID table
(Name: /BIC/SMATGROUP) MatGroup SID table (Name: /BIC/SMATGROUP) Not used for Infocube access !
Example: Show me the sales values for material group
Not used in this Example : Traditional Material SID T able: /BIC/S MATERIAL Time dependent Material Master T able: /BIC/Q MATERIAL Material Time dependent Attributes SID T able: /BIC/Y MATERIAL
Not used in this Example : Traditional Material SID T able: /BIC/S MATERIAL Time dependent Material Master Table: /BIC/Q MATERIAL Material Time dependent Attributes SID T able: /BIC/Y MATERIAL
SID Tables for Infocube Access
(figure 29)
The result set for the material groups is then determined in two steps: Browsing the tables that form the dimensions
Material dimension Access the traditional material group SID table and select thematerial group SIDs (here 345 and 678) for material group = 'X' andY Access the material non-time dependent attribute SID table with thesematerial group SIDs and determine the material SID values (here 111,222 and 333). Access the material dimension table with these material SID valuesand determine the material dimension table Dim-Id values (here 1, 2and 3)
Customer dimension: same proceeding
Time dimension: same proceedingAs a result of these three browsing activities, there are a number of key values(material dimension table Dim Ids, customer dimension table Dim-Ids, timedimension table Dim Ids ), one from each dimension table affected. Accessing the fact tableUsing the key values (Dim-Ids) determined during browsing, select all records inthe fact table that have these values in the fact table record key.
2000 SAP AG AND SAP A MERICA , INC . 30
-
8/6/2019 Multi-Dimensional Modeling En
34/73
-
8/6/2019 Multi-Dimensional Modeling En
35/73
MULTI -DIMENSIONAL MODELING WITH BW
2. Or (exclusive) allow time dependency for each external hierarchy node (timedependent structure)
With both structure types you can allow intervals for the leave nodes, which makes thedefinition of the external hierarchy easier.
Important In terms of performance, it is important to know that with external hierarchies of type 1 pre-calculated aggregates are possible at each level, even for specific node values.
With external hierarchies of type 2 there are no pre-calculated aggregates .
4. Tables for external hierarchiesThe activation of the InfoObject material results in the creation of the following tables:
Material hierarchy table : : /BIC/H MaterialMaterial hierarchy SID table : : /BIC/K MaterialMaterial SID-structure hierarchy table : : /BIC/I Material
5. Loading external hierarchy dataExternal hierarchies can be transferred into BW directly from an SAP product environment(e.g. standard cost center hierarchy from R/3), defined manually in BW or loaded via flat file.
6. External hierarchies and InfoCube accessBW allows you to determine multiple external hierarchies for a characteristic. Externalhierarchies can be used for characteristics in the dimension tables and for activatednavigational attributes for query navigation.Example:Consider a simple external hierarchy for the characteristic country. Country is a member of the customer dimension table but it could instead, or additionally, be a navigationalattribute in the customer master data table. The nodes are of a textual nature. If continentwas an InfoObject of type characteristic we could use this InfoObject to define the nodesusing its characteristic values like Europe (fig.31):
World
Europe
GermanyAustriaSwitzerland
America
USACanada
Japan
-3
-2
345
-1
12
6*
Country Hierarchy
* Set Ids only shown for better understanding
(figure 31)
The following graphic illustrates how the access works (fig.32):
2000 SAP AG AND SAP A MERICA , INC . 32
-
8/6/2019 Multi-Dimensional Modeling En
36/73
MULTI -DIMENSIONAL MODELING WITH BW
SID Table: Nodes
Nodes
America
Europe
World
SID
-1
-2
-3
Child
-2-1 663344551122
Parent
-3-3-3-2-2-2-1-1
Inclusion Table:Country
SID
634
512
SID Table:Country
Country
JapanGermanyAustria
Switz.USACanada
Customer Dimension Table
DIM-ID
11223344556677
Cust-SID
1711171227113711471157116711
Country-SID
11112233445566
Text &Rep. Attributes
Text &Rep. Attributes
FactTable
(figure 32)
A node of a hierarchy can either be textual or it can be an InfoObject with a specified valuee.g. InfoObject material group with value X. All display attributes of the InfoObjectmaterial group are associated with this node.
The use of InfoCube-independent hierarchy tables is an additional prerequisite for anenterprise-wide data warehouse as the hierarchy table for a characteristic only exists once.Multiple InfoCubes sharing the same characteristic in a dimension table access the samehierarchy table. This is another architectural aspect that accommodates data integration.
4. Dimension tables of an InfoCube
1. Defining dimension tablesIn defining an InfoCube you select all the InfoObjects of type characteristic that will bedirect members of this InfoCube. After this you define your dimensions and assign theselected characteristics to a dimension.
Important
BW does not force you to only assign related characteristics to the same dimension table,offering you additional schema potential. Nevertheless, as a basic rule you should only
put characteristics that have a parent-child relationship in the same dimension.
The activation of the InfoCube then results (with one exception which we will discuss later)in the generation of an InfoCube dimension table for each dimension.
2. Columns of a dimension tableThe columns of a dimension table are not the characteristics themselves but the SIDs of thecharacteristics you have chosen to be members of the InfoCube dimension (table). The
2000 SAP AG AND SAP A MERICA , INC . 33
-
8/6/2019 Multi-Dimensional Modeling En
37/73
MULTI -DIMENSIONAL MODELING WITH BW
unique key of a dimension table is the dimension ID (DIM-ID), that is a surrogate key(integer 4) (fig.33).
Customer Dimension Table
DIM-ID
11223344556677
Cust-SID
1711171227113711471157116711
Country-SID
11112233445566
(figure 33)
In the BW schema a surrogate key is used as a unique key with each dimension table andnot the real most granular characteristic within the dimension. For example, for eachunique combination of SID values for the different characteristics within a dimensiontable there is a unique surrogate key value assigned. The dimension tables are joined tothe fact table using surrogate keys in BW.
Important
The use of a surrogate key as a unique key in a dimension table allows modeling patterns such as N:M relationships within the same dimension or leafless hierarchies, and most importantly, it allows you to follow up changes of constellations between values of different characteristics within the same dimension over time (time rows). This will bediscussed in depth in chapter 5.
3. LimitationsAn InfoCube allows
16 dimensions3 dimensions exist with each InfoCube (whether they are used and thus visible
or not)Time dimensionUnit/ currency dimensionPacket dimension
The remaining 13 dimensions are for individual schema design
Each dimension table may be up to 248 characteristics.
Important
2000 SAP AG AND SAP A MERICA , INC . 34
-
8/6/2019 Multi-Dimensional Modeling En
38/73
MULTI -DIMENSIONAL MODELING WITH BW
It should be noted that in wider usage each attribute / characteristic is sometimes called a dimension. This a potential point of misunderstanding as then saying that the BW
schema has 16 dimensions, three of which are used internally, may sound very limited. According to this definition of a dimension there are 13 X 248 dimensions possible with BW plus the dimensions defined by the navigational attributes.
4. Dimensions and navigation
All characteristics assigned to dimension tables can be used for navigation (drilling) andfiltering within queries. Navigation with navigational attributes of InfoCubecharacteristics has to be explicitly switched on for each navigational attribute (Tab page:navigation).
The activation of a navigational attribute for an InfoCube can be done afterwards.Deactivation of navigational attributes is not possible!
5. Loading data into dimension tablesDimension tables are maintained during InfoCube load.
6. Special BW dimensionsWith BW we have special predefined dimensions:
Time dimensionUnit/ currency dimensionPacket dimension
1. Packet dimensionWith every load into an InfoCube there is a unique packet-ID assigned. This allows you to
purge erroneous loads without recreating the whole InfoCube again. The packet dimensioncan increase overheads during querying and can therefore be eliminated using the compressfeature of the InfoCube after proven correctness of the loads up to a certain packet-ID.
2. Unit/ Currency DimensionThe respective dimension table is generated if the key figures selected in the InfoCube are of type amount or quantity.
Important
If you are not interested in unit or currency calculations you should define the key figuresas numbers and then introduce the unit in the key figure header (i.e. sales in HL). Thiswill reduce overheads.
7. Dimensions with only one characteristic (line item dimensions)It is very often possible in this model to assign only one characteristic to a dimension.
2000 SAP AG AND SAP A MERICA , INC . 35
-
8/6/2019 Multi-Dimensional Modeling En
39/73
MULTI -DIMENSIONAL MODELING WITH BW
This will probably occur with specific reporting requirements or if for example you have thedocument line item in your model (see chapter 5 for all scenarios except no.3).In these situations a dimension table means only overhead. BW allows you define this kindof dimension as a line item dimension (Check box dimension definition).In doing this no dimension table will be generated for this dimension. A dimension table will
serve the SID table of this characteristic. The key in the fact table will be the SID of the SIDTable (fig.34).Line item dimension:
Line-ItemDimension
(1) Fact Table(1) Fact Table
(2) Dimension Tables(2) Dimension Tables
(3) time-independent-SID(3) time-independent-SID(4)(4) time-dependent-SI Dtime-dependent-SI D(5) traditional SID(5) traditional SID
11
22
22
22 33
55
44
33
5555
55
55
55
55
55
55
33 3355
55
5555
33
55
55
(figure 34)
2000 SAP AG AND SAP A MERICA , INC . 36
-
8/6/2019 Multi-Dimensional Modeling En
40/73
MULTI -DIMENSIONAL MODELING WITH BW
4. Fact tableThe fact table is created during InfoCube activation. The structure of the fact table in the BWschema is the same as it is in the normal Star schema. The keys of the dimension tables (i.e.the dim-IDs) or the SIDs of line item dimensions are the foreign keys in the fact table. Thenon-key columns are defined by the selected key figures during InfoCube definition.
Each row in the fact table is uniquely identified by a value combination of the respectiveDIM IDs/ SIDs of the dimension/ SID Tables
Since the BW uses system-assigned surrogate keys, namely DIM IDs or SIDs of 4 bytesin length per dimension to link the dimension / SID tables to the fact table, there willnormally be a decrease in space requirements for keys in comparison to the use of realcharacteristic values for keys.
The dimension / master (SID) tables should be relatively small with respect to the number of rows in comparison to the fact table (factor 1:10 / 20).
1. Multiple fact tablesEach InfoCube has two fact tables:The F-fact table, which is optimized for loading data, and the E-fact table, which isoptimized for retrieving data (fig.35).
Multiple
Fact Tables
(F) F-Fact Table Requid(F) F-Fact Table Request > 0 (E) E-Fact Table Requid(E) E-Fact Table Request = 0
(2) Dimension(2) Dimension
(3) time-independent-
(3) time-independent- (4) (4) time-dependent-
time-dependent-
(5) traditional(5) traditional
2 2
2 2
5 5 5 5
2 2 3 3
5 5
4 4
3 3 5 5
5 5
5 5
5 5
5 5
5 5
3 3 3 3 5 5
5 5
5 5 5 5
3 3
5 5
5 5
E
F
(figure 35)
2000 SAP AG AND SAP A MERICA , INC . 37
-
8/6/2019 Multi-Dimensional Modeling En
41/73
MULTI -DIMENSIONAL MODELING WITH BW
Both fact tables have the same columns. The F-table uses b-tree indexes the E-Table uses bitmap indexes except for line item dimensions where a b-tree index is used.The InfoCube compression feature moves the fact records of all selected requests from the F-to the E-fact table. In doing so the request-ID of each fact record is set to zero.The separation into two fact tables is fully transparent.
2. Fact table partitioningBW supports the partitioning of fact tables.Partitioning is a database feature and in short means that one table is split internally intoseveral tables, its partitions. Partitions of a table have their own index areas that are thereforesmaller areas than the entire table would have. Together with the possibility of internallysplitting a normally sequential request on the entire table into several parallel requests firedon different partitions, this can speed up a query significantly.Partitioning is fully transparent.To partition a table you have to define criteria that allow the database engine to decide where
a specific record has to be loaded and where it will be found afterwards.In BW the fact table can be either partitioned by the InfoObject 0CALMONTH i.e. calendar year and month, or by 0FISCPER i.e. fiscal year and period (fig.36).
Partitioning Fact Tables
(F) F-Fact Table Requid(F) F-Fact Table Request >
(E) E-Fact Table Requid(E) E-Fact Table Request =
(2) Dimension(2) Dimension
(3) time-independent-
(3) time-independent- (4) (4) time-dependent-
time-dependent-
(5) traditional(5) traditional
5 5 5 5
2 2 3 3
5 5
4 4
3 3 5 5
5 5
5 5
5 5
5 5
5 5
3 3 3 3
3 3
5 5
5 5
Packe Dimensio
Time Dimensio
E
F
(figure 36)
2000 SAP AG AND SAP A MERICA , INC . 38
-
8/6/2019 Multi-Dimensional Modeling En
42/73
MULTI -DIMENSIONAL MODELING WITH BW
Together with the entire value range for the partitioning InfoObject that you would expectand the optional maximal num