asap multi dimensional modeling
TRANSCRIPT
-
7/27/2019 Asap Multi Dimensional Modeling
1/72
Multi-Dimensional Modeling
with BWASAP FOR BW ACCELERATORBUSINESS INFORMATION 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
-
7/27/2019 Asap Multi Dimensional Modeling
2/72
MULTI-DIMENSIONAL MODELINGWITH BW
Table of ContentsMULTI-DIMENSIONAL MODELING WITH BW..................................................................................1
ASAP FORBW ACCELERATOR....................................................................................................................1
TABLE OF CONTENTS...............................................................................................................................2
INTRODUCTION..........................................................................................................................................1
1. SOFTWARE VERSION SUPPORTED..............................................................................................................12. REFERENCES..............................................................................................................................................13. OVERVIEW.................................................................................................................................................1
FROM MULTI-DIMENSIONAL MODEL TO INFOCUBE STEP ONE............................................5
1. THEGOALSOFMULTI-DIMENSIONALDATAMODELS.................................................................................52. SUBJECT AREA...........................................................................................................................................53. THEROLEOF BW BUSINESS CONTENT.....................................................................................................54. BASIC MODELING STEPS .........................................................................................................................6
STAR SCHEMA BASICS AND MODELING ISSUES...........................................................................15
1. HOW THE STARSCHEMA WORKS...........................................................................................................152. STARSCHEMA ISSUES..............................................................................................................................16
MULTI-DIMENSIONAL SCHEMAS IN BW........................................................................................ ..18
1. OVERVIEW ..............................................................................................................................................182. CONNECTING MASTERTABLESTO INFOCUBES......................................................................................203. DIMENSIONSINA BW SCHEMA ..............................................................................................................214. FACTTABLE.............................................................................................................................................375. GRANULARITY ........................................................................................................................................416. THISWOULDALLOWNAVIGATIONONPRICESUSINGEXTERNALHIERARCHIES. ....................................677. SAMECHARACTERISTICSEVERALTIMESINTHEMODEL:........................................................................67
8. ARTIFICIALKEYFIGURES.........................................................................................................................679. BIGDIMENSIONS......................................................................................................................................67
-
7/27/2019 Asap Multi Dimensional Modeling
3/72
MULTI-DIMENSIONAL MODELINGWITH BW
Introduction
This 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
Whitepaperand to the paperHierachies 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 orInfoCubes. 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 solutionsbased on a blueprint for an enterprise-wide data warehouse.
2000 SAP AG AND SAP AMERICA, INC. 1
-
7/27/2019 Asap Multi Dimensional Modeling
4/72
MULTI-DIMENSIONAL MODELINGWITH BW
BW Information Integration Architecture
SAPAPR/3/3APOPOCRMRMBBPBP
Legacyegacy
ExternalxternalProviderrovider
Extraction
Master Dataaster Data
PSAPersistent Staging Area
SourceSystems
ETL Tools
Meta DataPSASA
BW Operational Data StoreW Operational Data Store
InfoCubesnfoCubes
BusinessRules
BW ODSBW Operational Data Store
InfoCubes
Cleansing&Transformation
End-UserData Access
Ad HocAd HocQueriesQueriesReportingReportingApplicationsApplicationsModelsModels
BusinessRules
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 as
drilldown 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 ODSWhitepaper.
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 more
detailed level.
2000 SAP AG AND SAP AMERICA, INC. 2
-
7/27/2019 Asap Multi Dimensional Modeling
5/72
MULTI-DIMENSIONAL MODELINGWITH BW
BW Information Access Architecture
Legacyegacy
ExternalxternalProviderroviderMaster Dataaster Data
ETL Tools
Meta DataPSASA
BW Operational Data StoreW Operational Data Store
InfoCubesnfoCubes
SchedulingScheduling MonitoringMonitoring ChangeChangeManagementManagement
ServiceServiceManagementManagement
BWBusiness Explorer
Web
Graphical User Interf
SAP-ModelsAdvanced Planning
Enterprise MangemCRM
Third Party Tools
(ODBC/ ODBO)
SAPAPR/3/3APOPOCRMRMBBPBP
PSAPersistent Staging Area
SourceSystems
BW ODSBW Operational Data Store
InfoCubes End-UserData Access
(figure 02)
A simple example:
Sales Organisation Product Organisation Time KPIs
Sales 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 AMERICA, INC. 3
-
7/27/2019 Asap Multi Dimensional Modeling
6/72
MULTI-DIMENSIONAL MODELINGWITH 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 an
information 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 AMERICA, INC. 4
-
7/27/2019 Asap Multi Dimensional Modeling
7/72
MULTI-DIMENSIONAL MODELINGWITH 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 normal
understanding 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 (the OLAP
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 Starschema approach and extends it to support integration within the data warehouse, to offereasy handling and allow high performance solutions.
2. Subject Area
As 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 offeredby 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 AMERICA, INC. 5
-
7/27/2019 Asap Multi Dimensional Modeling
8/72
MULTI-DIMENSIONAL MODELINGWITH 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 members
involved.
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 information
2.2. Focus on analytical needs - Overcome model complexityFocus on analytical needs - Overcome model complexity
Create a valid schema
Translate the ERM to the MDM / Star schema
The MDM as a function of the analytical processing
3.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 InfoCubes
Translate the MDM / Star schema to one or more InfoCube schemas
Sales Rep ID
LastName
SalesDep
Material ID
Material Name
Material Type
Material Group
Customer ID
Customer Name
City
Region
Office Name
Time Code ID
Year
Fiscal Year
Quater
Mounth
Day of the Week
Material ID
Sales Rep IDTime Code IDCustomer ID
Sales Amount
Quantity
Unit Price
Time Dimension
Customer Dimension
Sales Org DimensionMaterial Dimension
FACT
Material DIM ID
OrgStr DIM ID
Time Code ID....
Quantity.....
SalesRep ID
Last Name
...Material DIM ID
Material ID
MatType
Material ID
Mat.description
MatType...
OrgStr. DIM ID
SalesRep
SalesDep
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 AMERICA, INC. 6
-
7/27/2019 Asap Multi Dimensional Modeling
9/72
MULTI-DIMENSIONAL MODELINGWITH BW
1. Step 1: Develop a complete understanding of the underlying businessprocesses
In this step we focus on the structurestructure of information:
1. Entities and the relations between them
There are no strict rules on how to develop a complete understanding of the underlyingbusiness process. Nevertheless using an Entity Relationship Model (ERM) is a good way ofseeing the relevant business objects and their relationships. Depending on the particularcircumstances 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 ofintroducing 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 canpurchase 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 AMERICA, INC. 7
-
7/27/2019 Asap Multi Dimensional Modeling
10/72
MULTI-DIMENSIONAL MODELINGWITH 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 thatadditional details for material, customer and sales person are also required.
This gives you additional entities and attributes where attributes are the describing fields ofan 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 AMERICA, INC. 8
-
7/27/2019 Asap Multi Dimensional Modeling
11/72
MULTI-DIMENSIONAL MODELINGWITH BW
Customer
Material Sales Person
Material group Sales Department
Customer no
Customer name
City
Region
Material no
Material name
Material type
color
price
Material group no
Material group name
....
Sales TransactionDate
Customer no
Material no
Sales pers no
Amount
Quantity
Currency
Sales pers. no
Sales pers. name
.......
Sales dep. no
Sales 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 AMERICA, INC. 9
-
7/27/2019 Asap Multi Dimensional Modeling
12/72
MULTI-DIMENSIONAL MODELINGWITH 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
LastName
SalesDep
Material ID
Material Name
Material TypeMaterial Group
Customer ID
Customer NameCity
RegionOffice Name
Time Code ID
YearFiscal Year
QuaterMounth
Day of the Week
Material ID
Sales Rep IDTime Code ID
Customer ID
Sales Amount
QuantityUnit 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, orattributes.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 Schema
The Star schema offers comprehensibility for software. The Star schema is the mostpopular way of implementing a Multi-Dimensional Model in a relational database.Snowflake schemas are an alternative solution although BW InfoCubes are based on a Starschema, and a short introduction to its main terms and capabilities will now be given here.
2000 SAP AG AND SAP AMERICA, INC. 10
-
7/27/2019 Asap Multi Dimensional Modeling
13/72
MULTI-DIMENSIONAL MODELINGWITH 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
LastName
SalesDep
Material IDMaterial ID
Material Name
Material Type
Material Group
CustomerCustomerIDID
Customer Name
City
RegionOffice Name
Time Code IDTime Code ID
Year
Fiscal Year
QuaterMounth
Day of the Week
Material IDMaterial ID
Sales RepSales Rep IDID
Time Code IDTime Code ID
CustomerCustomerIDID
Sales Amount
Quantity
Time
Dimension
(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, such as
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 associated
dimension tables
The points of the star are dimension tables
Dimension tables store both attributes about the data stored in the fact table and
textual data
Dimension tables are de-normalized
The most atomic dimension attributes in the dimensions define the granularity of the
information, i.e. the number of records in the fact table
2000 SAP AG AND SAP AMERICA, INC. 11
-
7/27/2019 Asap Multi Dimensional Modeling
14/72
MULTI-DIMENSIONAL MODELINGWITH BW
The Fact Table (fig.12):
CustomerCustomer StreetStreet SalesPersSalesPers SalesRegionSalesRegion MaterialMaterial UnitUnit DateDateDate
Customer SalesPers Material Date Amount Quantity
Ides Gmbh 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
LastName
SalesDep
Material ID
Material Name
Material Type
Material Group
Customer ID
Customer Name
City
Region
Office Name
Time Code ID
Year
Fiscal Year
Quater
Mounth
Day of the Week
Material ID
Sales Rep IDTime Code ID
Customer ID
Sales Amount
Quantity
Unit 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 AMERICA, INC. 12
-
7/27/2019 Asap Multi Dimensional Modeling
15/72
MULTI-DIMENSIONAL MODELINGWITH 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 Description
Build 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 AMERICA, INC. 13
-
7/27/2019 Asap Multi Dimensional Modeling
16/72
MULTI-DIMENSIONAL MODELINGWITH BW
Translate the MDM/ Star Schema into an InfoCube Description:
Sales Rep ID
LastNameSalesDep
Material ID
Material NameMaterial Type
Material Group
Customer ID
Customer Name
City
RegionOffice Name
Time Code ID
Year
Fiscal Year
QuaterMounth
Day of the Week
Material ID
Sales Rep ID
Time Code ID
Customer ID
Sales AmountQuantity
Unit Price
Time DimensionCustomer Dimension
Sales Org DimensionMaterial Dimension
FACT
MDM/ Star Schema
SAP BW
Material DIM ID
OrgStr DIM IDTime Code ID
....
Quantity
.....
SalesRep ID
Last Name
...Material DIM ID
Material ID
MatType
Material ID
Mat.descriptionMatType
...
OrgStr. DIM ID
SalesRepSalesDep
SalesDep ID
Address
...
(figure 14)
7. Resume
In 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 - oneInfoCube] -> 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 AMERICA, INC. 14
-
7/27/2019 Asap Multi Dimensional Modeling
17/72
MULTI-DIMENSIONAL MODELINGWITH BW
Star Schema Basics and Modeling Issues
In the previous chapter we introduced the Star schema. As most of the relevant properties formodeling 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 to
understand. 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 Works
How 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 material
group 'XXX' in the year = '1997'
Star Schema
Sales RepSales Rep IDID
LastNameSalesDep
Material IDMaterial ID
Material NameMaterial Type
Material Group
CustomerCustomerIDID
Customer NameCityRegion
Office Name
Time Code IDTime Code ID
YearFiscal YearQuater
Mounth
Day of the Week
Material IDMaterial ID
Sales RepSales Rep IDID
Time Code IDTime Code ID
CustomerCustomerIDID
Sales Amount
Quantity
TimeDimension
(Table)
CustomerDimension
(Table)
Sales Org
Dimension(Table)
MaterialDimension
(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 with Materialgroup = '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 AMERICA, INC. 15
-
7/27/2019 Asap Multi Dimensional Modeling
18/72
MULTI-DIMENSIONAL MODELINGWITH 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 Customer4711 purchaseMaterialBBB 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 100
DDD 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 record
to 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 record
in fact table
Star-II. The role of dimension tables
There are also changes between the attribute values of attributes within thesame dimension (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 AMERICA, INC. 16
-
7/27/2019 Asap Multi Dimensional Modeling
19/72
MULTI-DIMENSIONAL MODELINGWITH BW
Reporting
Star-III. Reports can be created by accessing the dimension tables (master data
reporting).
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 timespan would show the customers that have revenue, but not the customers that haveno revenue).
Aggregation
Star-V. Only the information at the granularity of the dimension table keys (material
ID, 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
aggregated data, but with large ( number of rows) fact tables and / or large
dimension tables, pre-calculated aggregates must be introduced for performancereasons.
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 ofa 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 lowest
level, it is not possible to put both material and material color into one normal stardimension 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 hierarchies
Very 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 willproduce reports with dummy hierarchy tree nodes.
2000 SAP AG AND SAP AMERICA, INC. 17
-
7/27/2019 Asap Multi Dimensional Modeling
20/72
MULTI-DIMENSIONAL MODELINGWITH BW
Table Sizes and Performance
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 the
schema is caused by properties of relational databases.
Multi-Dimensional Schemas in BW
Based on experience with the Star schema, the SAP BW schema uses a more sophisticated
approach 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 inpoor 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 AMERICA, INC. 18
-
7/27/2019 Asap Multi Dimensional Modeling
21/72
MULTI-DIMENSIONAL MODELINGWITH BW
FACT Table
G e bi et 1 G e b ie t 2 G e bi 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 et 4 G e b i et 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 et 7 G e b i et 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
MaterialGroup
Material Hierarchy TableMaterial_Dimension_ID
SalesOrg_Dimension_IDTime_Dimension_ID
Customer_Dimension_ID
Sales Amount
Quantity
Material Number
Language Code
Material Number
Language Code
Material Name
Material Text TableMaterial_Dimension_ID
Material Number
Material Dimension Table
Material Master Table
Material NumberMaterial Number
Material Type
SalesRep Master Table
SalesRep NumberSalesRep 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 NumberCustomer Number
City
RegionTime_Dimension_ID
Year
QuaterMounth
Day
Time Dimension Table
SalesOrg_Dimension_ID
Sales Rep Number
SalesOrgSalesOrgDimensionDimension TableTable
Customer_Dimension_ID
Customer Number
Customer Dimension Table
CustomerCustomer DimensionDimension
InfoCubeInfoCube
TimeTime DimensionDimension
MaterialMaterial
DimensionDimension
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 Table
In 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 calledterminologyattributes (e.g. material type).
Text Tables
Textual descriptions of a characteristic are stored in a separate text table. Thesystem runs in different languages at a time.
2000 SAP AG AND SAP AMERICA, INC. 19
-
7/27/2019 Asap Multi Dimensional Modeling
22/72
MULTI-DIMENSIONAL MODELINGWITH BW
External Hierarchy Tables
Hierarchies 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).
Important
The use of the term hierarchy in BW is a possible point of confusion. The
normal 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 AMERICA, INC. 20
-
7/27/2019 Asap Multi Dimensional Modeling
23/72
MULTI-DIMENSIONAL MODELINGWITH 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
Dimension
Table
Text
SID Tables
Master
Hierarchies
Dimension
Table
Dimension
Table
Dimension
Table
Dimension
Table
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 prioranalysis:
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 AMERICA, INC. 21
-
7/27/2019 Asap Multi Dimensional Modeling
24/72
MULTI-DIMENSIONAL MODELINGWITH BW
G e bi et 1 G e b ie t 2 G e bi et 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 et 4 G e b ie 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 ie t 7 G e b ie 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
MaterialGroup
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 NumberMaterial Number
Material Type
MaterialMaterial
DimensionDimension
(figure 20)
We emphasize that:
Dimensions in a BW schema
The 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
Material
Dimension table
As a CharacteristicAs a Characteristic??
MaterialMaster table
As a NavigationalAs a Navigational//
DisplayDisplayAttributeAttribute ??
Material
Hierarchy tableAs a HierarchyAs a Hierarchy??
2000 SAP AG AND SAP AMERICA, INC. 22
-
7/27/2019 Asap Multi Dimensional Modeling
25/72
MULTI-DIMENSIONAL MODELINGWITH 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 yourqueries, 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 attribute of material in the materialmaster data table.
When no reference is being made to specific schema location (as with the meta data
definition), the term InfoObjects of type characteristic is used.
2000 SAP AG AND SAP AMERICA, INC. 23
-
7/27/2019 Asap Multi Dimensional Modeling
26/72
MULTI-DIMENSIONAL MODELINGWITH BW
1. Master Data Table
In 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 referto 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 othercharacteristics 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 Querying
Whether 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 tabpage-> 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 AMERICA, INC. 24
-
7/27/2019 Asap Multi Dimensional Modeling
27/72
MULTI-DIMENSIONAL MODELINGWITH BW
5. InfoObject names and names of attributes
It 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. Ifyou 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 Attributes
Each 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 formermaterials 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, 1st 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 AMERICA, INC. 25
-
7/27/2019 Asap Multi Dimensional Modeling
28/72
MULTI-DIMENSIONAL MODELINGWITH BW
Material DateFrom DateTo MatGroup
AAA 01 /1000 12 / 1999
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)
(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 page
section.
Time dependency of an attribute allows you to keep track on the changes over time of the
relation 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/Pinfobjectname) and
One table stores relations to time dependent attributes (name of the table:
/BIC/Qinfobjectname).
The time dependent attributes master data table has additional DATETO and
DATEFROM 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 AMERICA, INC. 26
-
7/27/2019 Asap Multi Dimensional Modeling
29/72
MULTI-DIMENSIONAL MODELINGWITH BW
7. Compound Attributes
Characteristics may not be unique i.e. another attribute is necessary to allow the data tobe 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 InfoObject
maintenance.
2. Text Tables
The 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 theirSIDs.
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 AMERICA, INC. 27
-
7/27/2019 Asap Multi Dimensional Modeling
30/72
MULTI-DIMENSIONAL MODELINGWITH BW
Example:Supposing the InfoObject material has both non-time dependent and time dependentattributes. The activation of this InfoObject generates the following tables (for illustrationpurposes we will use the example from the master table section):
Material master table fornon-time dependent attributes : /BIC/Pmaterial (fig.24)
Materiall
AAA
BBB
CCC
DDD
Non-Time Dependent Attribute MasterData(table name:
Material master table fortime dependent attributes : /BIC/QMaterial (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/SMaterial (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/XMaterial (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 AMERICA, INC. 28
-
7/27/2019 Asap Multi Dimensional Modeling
31/72
MULTI-DIMENSIONAL MODELINGWITH BW
Material time dependent attribute SID table : /BIC/YMaterial (fig.28)
Material-SID MatGroup-
001 AAA /1000 12/9999 910
002 BBB /1000 09/1998
002 BBB /1998 12/9999 920
003 /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 amountfor 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 AMERICA, INC. 29
-
7/27/2019 Asap Multi Dimensional Modeling
32/72
MULTI-DIMENSIONAL MODELINGWITH BW
112233
111111222222333333
Dim ID SIDMaterial
Fact tableDimension table
Material not time dependentAttributes SIDtable(Name: /BIC/XMATERIAL)
MaterialNon-timeAttributes SIDtable(Name: /BIC/XMATERIAL)
Material MatGroup
AAACCCDDD
XYY
Material Master table(Name: /BIC/PMATERIAL)
Material Master table(Name: /BIC/PMATERIAL)
112233
10.00012.00025.000
Dim ID Sales
SIDMaterial Material SID MatGroup
AAACCCDDD
111111222222333333
345345678678678678
MatGroupSID MatGroup
XYZ
345678999 MatGroup SIDtable
(Name: /BIC/SMATGROUP)
MatGroup SIDtable(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 Table: /BIC/SMATERIALTime dependent Material Master Table: /BIC/Q MATERIALMaterial Time dependent Attributes SID Table: /BIC/YMATERIAL
Not used in this Example :Traditional Material SID Table: /BIC/SMATERIALTime dependent Material Master Table: /BIC/QMATERIALMaterial Time dependent Attributes SID Table: /BIC/YMATERIAL
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 the material
group SIDs (here 345 and 678) formaterial group = 'X' and Y
Access the material non-time dependent attribute SID table with these
material group SIDs and determine the material SID values (here 111,222 and 333).
Access the material dimension table with these material SID values and
determine the material dimension table Dim-Id values (here 1, 2 and3)
Customer dimension: same proceeding
Time dimension: same proceeding
As 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 table
Using 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 AMERICA, INC. 30
-
7/27/2019 Asap Multi Dimensional Modeling
33/72
MULTI-DIMENSIONAL MODELINGWITH BW
We can summarize that in accessing an InfoCube no real value master data tables are used.The following graphic illustrates this (fig.30):
SID Tables and
InfoCube Access
(1) Fact Table(1) Fact Table
(2) Dimension Tables(2) Dimension Tables
(3) time-independent-SID(3) time-independent-SID
(4)(4) time-dependent-SIDtime-dependent-SID
(5) traditional SID(5) traditional SID
11
22
22
22
22 33
55
44
33
5555
55
55
55
55
55
55
33 33
55
55
5555
44
33
55
55
55
55
(figure 30)
2. External Hierarchy Table
In general hierarchies are structures essential to navigation. Having characteristics andattributes in dimension tables and master data tables that are related in a sequence of parent-child relationships indicates, of course, not only hierarchies, but internal hierarchies.The external hierarchies of a characteristic are defined separately from the other master dataand, as mentioned above, are independent of specific InfoCubes. They are therefore calledexternal hierarchies. The different model properties of internal and external hierarchiesin the BW Schema will be discussed in chapter 5.
During the creation of an InfoObject of type characteristic you can define the basicfunctionality of external hierarchies for this InfoObject (Tab page: hierarchies) or
whether they will exist at all.
3. External hierarchy formats
The following external hierarchy formats are possible:
1. Allow versioning and/ or time dependency of the whole external hierarchy structure(date to, date from)
2000 SAP AG AND SAP AMERICA, INC. 31
-
7/27/2019 Asap Multi Dimensional Modeling
34/72
MULTI-DIMENSIONAL MODELINGWITH 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 1pre-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 hierarchies
The activation of the InfoObject material results in the creation of the following tables:
Material hierarchy table : : /BIC/HMaterial
Material hierarchy SID table : : /BIC/KMaterial
Material SID-structure hierarchy table : : /BIC/IMaterial
5. Loading external hierarchy data
External 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.The latter is discussed in a separate paper.
6. External hierarchies and InfoCube access
BW 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 memberof 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
Germany
Austria
Switzerland
America
USA
Canada
Japan
-3
-2
3
4
5
-1
1
2
6*
Country Hierarchy
* Set Ids only shown for better understanding
(figure 31)
2000 SAP AG AND SAP AMERICA, INC. 32
-
7/27/2019 Asap Multi Dimensional Modeling
35/72
MULTI-DIMENSIONAL MODELINGWITH BW
The following graphic illustrates how the access works (fig.32):
SID Table: Nodes
Nodes
America
Europe
World
SID
-1
-2
-3
Child
-2
-1
66
33
44
55
11
22
Parent
-3
-3
-3-2
-2
-2
-1
-1
Inclusion Table:
Country
SID
6
34
5
1
2
SID Table:
Country
Country
Japan
GermanyAustria
Switz.
USA
Canada
Customer Dimension Table
DIM-ID
11
22
33
44
55
66
77
Cust-SID
1711
1712
2711
3711
4711
5711
6711
Country-SID
11
11
22
33
44
55
66
Text &
Rep. Attributes
Text &
Rep. Attributes
Fact
Table
(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 tables
In 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.
2000 SAP AG AND SAP AMERICA, INC. 33
-
7/27/2019 Asap Multi Dimensional Modeling
36/72
MULTI-DIMENSIONAL MODELINGWITH BW
2. Columns of a dimension table
The 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). Theunique 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
11
22
33
44
55
66
77
Cust-SID
1711
1712
2711
3711
4711
5711
6711
Country-SID
11
11
22
33
44
55
66
(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 patternssuch 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. Limitations
An InfoCube allows
16 dimensions
3 dimensions exist with each InfoCube (whether they are used and thus visible ornot)
Time dimension
Unit/ currency dimension
Packet dimension
The remaining 13 dimensions are for individual schema design
Each dimension table may be up to 248 characteristics.
2000 SAP AG AND SAP AMERICA, INC. 34
-
7/27/2019 Asap Multi Dimensional Modeling
37/72
MULTI-DIMENSIONAL MODELINGWITH BW
Important
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 withBW 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 tables
Dimension tables are maintained during InfoCube load.
6. Special BW dimensions
With BW we have special predefined dimensions:
Time dimension
Unit/ currency dimension
Packet dimension
1. Packet dimension
With every load into an InfoCube there is a unique packet-ID assigned. This allows you topurge 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 Dimension
The respective dimension table is generated if the key figures selected in the InfoCube are oftype 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). This
will reduce overheads.
2000 SAP AG AND SAP AMERICA, INC. 35
-
7/27/2019 Asap Multi Dimensional Modeling
38/72
MULTI-DIMENSIONAL MODELINGWITH BW
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.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 kind
of 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 willserve 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-Item
Dimension
(1) Fact Table(1) Fact Table
(2) Dimension Tables(2) Dimension Tables
(3) time-independent-SID(3) time-independent-SID
(4)(4) time-dependent-SIDtime-dependent-SID
(5) traditional SID(5) traditional SID
11
22
22
22 33
55
44
33
5555
55
55
55
55
55
55
33 335555
5555
33
55
55
(figure 34)
2000 SAP AG AND SAP AMERICA, INC. 36
-
7/27/2019 Asap Multi Dimensional Modeling
39/72
MULTI-DIMENSIONAL MODELINGWITH 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. The
non-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 numberof rows in comparison to the fact table (factor 1:10 / 20).
1. Multiple fact tables
Each 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
22
22
5555
22 33
55
44
33
55
55
55
55
55
55
33 33
55
55
5555
33
55
55
E
F
(figure 35)
2000 SAP AG AND SAP AMERICA, INC. 37
-
7/27/2019 Asap Multi Dimensional Modeling
40/72
MULTI-DIMENSIONAL MODELINGWITH BW
Both fact tables have the same columns. The F-table uses b-tree indexes the E-Table usesbitmap 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 partitioning
BW 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. calendaryear and month, or by 0FISCPER i.e. fiscal year and period (fig.36).
PartitioningFact 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
5555
22 33
55
44
33
55
55
55
55
55
55
33 33
33
55
55
PackeDimensio
TimeDimensio
E
F
(figure 36)
2000 SAP AG AND SAP AMERICA, INC. 38
-
7/27/2019 Asap Multi Dimensional Modeling
41/72
MULTI-DIMENSIONAL MODELINGWITH BW
Together with the entire value range for the partitioning InfoObject that you would expectand the optional maximal number of partitions, the value range for each partition isdetermined.Note: Partitioning is a database functionality. Have a look at the OSS to find out how and towhat extent your database provider supports partitioning!
For example:Let us assume we want to partition a fact table using 0CALMONTH. We want tohave data in our fact table starting from 199901. Let us further assume that weexpect a lifespan of our InfoCube up until 201012. Without specifying a maximumvalue for the partitions we would have
11 years x 12 month + 2 = 134 partitions
The additional 2 partitions are reserved for data which have a 0CALMONTH valueless or larger than our expected values.To bring in 1 quarter in each partition we proceed as follows :
134 Partition / 4 = 33,5 => maximum = 34
Important
Partitioning for a fact table has to be defined before you activate the InfoCube. It cannot
be done afterwards!
Fact table partitioning as described above only affects E-fact tables. F-fact tables are
automatically partitioned by the request-ID. For this and other reasons do not forget tocompress your InfoCube on a regular base!
3. BWTerminologyThe following picture shows differences in the terminology (fig.37):
MDM / Star Schema BW Schema
Fact
Fact Table
Characteristic /
Navigational Attribute/
Display Attribute /
(external) Hierarchy
NodeDimension Table /
Master Table /
Text Table /
External Hierarchy
Table /
(SID Table)
Dimension (Table)
(Dimension) Attribute
Fact Table
Key Figure
(figure 37)
2000 SAP AG AND SAP AMERICA, INC. 39
-
7/27/2019 Asap Multi Dimensional Modeling
42/72
MULTI-DIMENSIONAL MODELINGWITH BW
ImportantIt should again be noted that generally attributes/ characteristics are sometimes calleddimensions. This a potential point of misunderstanding as saying that the BW Schema offers16 dimensions, three of which are used internally, sounds very limited. Using this definitionof a dimension there are actually 13 X 248 dimensions possible with BW plus the dimensions
defined by the navigational attributes.
4. Modeling issues and the BW schema
We will now look at the various important modeling issues from a topic-based perspective.Explaining how to implement these issues with BW will improve understanding of the BWschema.Trying to map real world processes, the following graphic illustrates the competition ofdifferent interests that always arise during the design phase. This explains why even some ofthe following modeling recommendations contradict each other. A good design will alwaysbe a compromise.
We will therefore also leave out the impacts of modeling, especially on performance and viceversa (although please have also have a look at the accelerator Sizing and Performance)(fig.38).
PerformancePerformance
AspectsAspects
GlobalGlobal
Data WarehouseData Warehouse
DesignDesign AspectsAspects
AnalysisAnalysis
AspectsAspects
Competition in Data Warehousing
(figure 38)
2000 SAP AG AND SAP AMERICA, INC. 40
-
7/27/2019 Asap Multi Dimensional Modeling
43/72
MULTI-DIMENSIONAL MODELINGWITH BW
5. Granularity
An important result of the data modeling phase is that the granularity (the level of detail ofyour data) is determined. Granularity deeply influences
Reporting capabilities
Performance Space needed
Load TimeYou have to decide whether you really need to store detailed data in an InfoCube or whetherit is better in an ODS object or even not stored in your data warehouse at all, but accesseddirectly from your Source system via drill thru.These decisions are decisions that do not only influence your current scope, but the entireapproach to and architecture of your data warehouse.This topic is discussed in a special paper.
1. Fact tables and granularity
Volume is a concern with fact tables. How can the number of rows of data in a fact table beestimated? Consider the following:
How long will the data be stored in the fact table?
How granular will the data be?The first is fairly straightforward. However, the granularity of the information has a largeimpact on querying efficiency and overall storage requirements. The granularity of the facttable is directly impacted by dimension table design as the most atomic characteristic in eachdimension determines the granularity of the fact table. For example, let us assume we need toanalyze the performance of outlets and articles. Attributes exist which describe:
Outlet
Receipts
Articles
Customers
Time
Let us limit our analysis to articles and time, and further assume that 1,000 articles aregrouped by 10 article groups. To track the article group performance on a weekly basis:
Granularity: article group, week, and 300 sales days a year (45 weeks)10 X 45 = 450 records in the fact table per year due to only these two attributes if allarticles are sold within a week
Granularity: article, week, 300 sales days a year (45 weeks)1,000 X 45 = 45,000 records in the fact table per year due to only these two attributesif all articles are sold within a week
Granularity: article, day, 300 sales days a year1,000 X 300 = 300,000 records in the fact table per year due to only these twoattributes if all articles are sold within a day
2000 SAP AG AND SAP AMERICA, INC. 41
-
7/27/2019 Asap Multi Dimensional Modeling
44/72
MULTI-DIMENSIONAL MODELINGWITH BW
Granularity: article, hour, 300 sales days a year, 12 sales hours a day500 X 300 X 12 = 1,800,000 records in the fact table per year due to only these twoattributes if on average 500 articles are sold within an hour
Finally, assuming 500 outlets, there will be 900,000,000 records a year in the fact table.
2. Impacts on StorageQuite obviously granularity directly impacts the storage space needed. As it stores thetransaction data, the fact table is the largest table in the InfoCube. Therefore, estimating thesize of the fact table provides a rough idea of the space required for the InfoCube.For each dimension table a four-byte integer DIM ID (dimension ID) is used, in conjunctionwith the other DIM IDs, to point to the associated row of data in the fact table. In addition,the length of all the key figures in the fact table must be considered:
((Number of DIM IDs) * 4 + (total length of all key figures)) * number of records
ImportantRemember the three dimensions required are time, unit, and packet.
3. Impacts on Performance
Large fact tables impact on reporting and analysis. Apart from hardware considerations, thereare a few additional considerations to bear in mind.
AggregationFor large fact tables consider the use of pre-calculated aggregates. For implications,such as an increase in the storage space required, see earlier sections of this paper.
PartitioningPartition the fact table. The option exists to divide a table with respect to the values ofa specific attribute, into several physical tables. This process is transparent to the user.
This technique is useful with large fact tables because it provides access via smallerindexes.
4. Location of dependent attributes in the BW schema
The BW schema offers more than one possible location for dependent (parent) attributes.Where to put dependent attributes in the BW schema is one of the decisive results of theprojects blueprint phase.
2000 SAP AG AND SAP AMERICA, INC. 42
-
7/27/2019 Asap Multi Dimensional Modeling
45/72
MULTI-DIMENSIONAL MODELINGWITH BW
Parent Attributes in BW (fig.39)
Material
Material Dimension
Materialgroup
Material
Dimension table
As a CharacteristicAs a Characteristic??Material
Master table
As a NavigationalAs a Navigational//
DisplayDisplayAttributeAttribute ??
Material
Hierarchy tableAs a HierarchyAs a Hierarchy??
(figure 39)
The freedom to choose between the different locations of dependent attributes is actuallyrestricted as the reporting behavior and possibilities differ and depend upon the location.Thus the reporting needs investigated during the blueprint phase of the project normallydefine the location of a dependent attribute. This is discussed in detail in the followingchapters.
5. Performance and location of dependent attributesThe reporting needs should guide you in the deciding