BW Multi Dimensional Modeling

Multi-Dimensional Modeling
with BW
ASAP FOR BW ACCELERATOR
BUSINESS INFORMATION WAREHOUSE
A background to the techniques used to

create SAP BW InfoCubes
Document 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 implied
warranties of merchantability, fitness for a particular purpose, or non-infringement.
SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that
may result from the use of these materials.
SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these
materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and
does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.
MULTI-DIMENSIONAL MODELING WITH BW
Table of Contents
MULTI-DIMENSIONAL MODELING WITH BW...................................................................................1
ASAP FOR BW ACCELERATOR...................................................................................................................1
TABLE OF CONTENTS................................................................................................................................2
1 INTRODUCTION...................................................................................................................................1
1.1 SOFTWARE VERSION SUPPORTED......................................................................................................1
1.2 REFERENCES......................................................................................................................................1
1.3 OVERVIEW.........................................................................................................................................1
2 FROM MULTI-DIMENSIONAL MODEL TO INFOCUBE – FIRST APPROACH...................5
2.1 THE GOALS OF MULTI-DIMENSIONAL DATA MODELS.........................................................................5
2.2 SUBJECT AREA..................................................................................................................................5
2.3 THE ROLE OF THE BW BUSINESS CONTENT......................................................................................5
2.4 BASIC MODELING STEPS...................................................................................................................6
2.4.1 Step 1: Develop a complete understanding of the underlying business processes...................7
2.4.1.1 Reaping benefits of BW’s Business Content......................................................................................9
2.4.2 Step 2: Create a valid Schema................................................................................................10
2.4.2.1 The Multi-Dimensional Model (MDM)............................................................................................10
2.4.2.2 The Star Schema...............................................................................................................................10
2.4.3 Step 3 : Create an InfoCube Description...............................................................................13
2.5 RESUME...........................................................................................................................................14
3 STAR SCHEMA BASICS AND MODELING ISSUES....................................................................15
3.1 HOW THE STAR SCHEMA WORKS....................................................................................................15
3.2 STAR SCHEMA ISSUES.....................................................................................................................16
4 MULTI-DIMENSIONAL SCHEMAS IN BW...................................................................................18
4.1 OVERVIEW.......................................................................................................................................18
4.2 CONNECTING MASTER TABLES TO INFOCUBES..............................................................................20
4.3 DIMENSIONS IN A BW SCHEMA......................................................................................................21
4.3.1 Master Data Table..................................................................................................................23
4.3.1.1 Reference Characteristic Assignment...............................................................................................23
4.3.1.2 Master Table Existence....................................................................................................................23
4.3.1.3 Assigning Attributes.........................................................................................................................23
4.3.1.4 Attributes and Querying...................................................................................................................23
4.3.1.5 InfoObject Names and Names of Attributes.....................................................................................24
4.3.1.6 Time Dependent Attributes...............................................................................................................24
4.3.1.7 Compound Attributes.......................................................................................................................26
4.3.2 Text Tables..............................................................................................................................26
4.3.3 SID Tables..............................................................................................................................26
4.3.3.1 InfoObject Definition and SID Tables..............................................................................................26
4.3.3.2 SID Tables Mainetance....................................................................................................................28
4.3.3.3 InfoCube Access and SID Tables.....................................................................................................28
4.3.4 External Hierarchy Table.......................................................................................................30
4.3.4.1 External Hierarchy Types.................................................................................................................30
4.3.4.2 Tables for External Hierarchies........................................................................................................31
4.3.4.3 Loading External Hierarchy Data.....................................................................................................31
4.3.4.4 External Hierarchies and InfoCube Access.......................................................................................31
4.3.5 Dimension Tables of an InfoCube..........................................................................................32
4.3.5.1 Defining Dimension Tables..............................................................................................................32
4.3.5.2 Columns of a Dimension Table........................................................................................................33
4.3.5.3 Limitations.......................................................................................................................................33
4.3.5.4 Dimensions and Navigation..............................................................................................................34
4.3.5.5 Loading data into Dimension Tables................................................................................................34
4.3.5.6 Special BW Dimensions...................................................................................................................34
4.3.5.6.1 Packet Dimension......................................................................................................................34
4.3.5.6.2 Unit/ Currency Dimension.........................................................................................................34
4.3.5.7 Dimensions with only one Characteristic (Line Item Dimensions)...................................................34
2000 SAP AG AND SAP AMERICA, INC. TABLE OF CONTENTS

4.4 FACT TABLE....................................................................................................................................36

4.4.1 Multiple Fact Tables...............................................................................................................36
4.4.2 Fact Table Partitioning..........................................................................................................37
4.5 BW TERMINOLOGY.........................................................................................................................38
5 MODELING ISSUES AND THE BW SCHEMA..............................................................................39
5.1 GRANULARITY.................................................................................................................................40
5.1.1 Fact Tables and Granularity..................................................................................................40
5.1.2 Impacts on Storage.................................................................................................................41
5.1.3 Impacts on Performance.........................................................................................................41
5.2 LOCATION OF DEPENDENT ATTRIBUTES IN THE BW SCHEMA.......................................................41
5.2.1 Performance and Location of Dependent Attributes..............................................................42
5.2.2 Enterprise Data Warehouse and Location of Dependent Attributes......................................42
5.2.3 Data Load and Location of Dependent Attributes..................................................................43
5.3 TRACKING HISTORY IN THE BW SCHEMA......................................................................................43
5.3.1 History and InfoCube.............................................................................................................43
5.3.2 Slowly Changing Dimensions.................................................................................................44
5.3.2.1 Scenario I: Report the data to today‘s constellation - Today is Yesterday........................................46
5.3.2.1.1 Scenario I : Description.............................................................................................................46
5.3.2.1.2 Scenario I: Solutions with BW..................................................................................................47
5.3.2.2 Report the data to yesterday‘s constellation as well -Yesterday is Today.........................................49
5.3.2.2.1 Scenario II : Description............................................................................................................49
5.3.2.2.2 Scenario II: Solutions with BW.................................................................................................50
5.3.2.3 Scenario III: Report the data to the respective constellation-Today or Yesterday-............................52
5.3.2.3.1 Scenario III : Description...........................................................................................................52
5.3.2.3.2 Scenario III: Solution with BW................................................................................................53
5.3.2.4 Scenario IV: Report only on data for constellations valid today and yesterday -Today and Yesterday-
54
5.3.2.4.1 Scenario IV : Description..........................................................................................................54
5.3.2.4.2 Scenario IV: Solution with BW................................................................................................54
5.3.3 Usage of Time Scenarios.......................................................................................................56
5.4 M:N RELATIONSHIPS.......................................................................................................................57
5.4.1 M:N Relationships and the Fact Table...................................................................................57
5.4.2 M:N Relationships within a Dimension..................................................................................57
5.4.2.1 Designing M:N Relationships using the Dimension Table...............................................................57
5.4.2.2 Designing M:N Relationships using a Compound Attribute.............................................................58
5.5 FREQUENTLY CHANGING ATTRIBUTES (STATUS ATTRIBUTES)......................................................58
5.6 INFLATION OF DIMENSIONS.............................................................................................................59
5.7 MULTIPLE PROCESS REPORTING SCENARIOS..................................................................................59
5.7.1 MultiCubes..............................................................................................................................60
5.7.2 Partitioning Attributes............................................................................................................63
5.8 ATTRIBUTE OR FACT (KEY FIGURE)................................................................................................64
5.9 SAME CHARACTERISTIC SEVERAL TIMES IN THE MODEL................................................................65
5.10 ARTIFICIAL KEY FIGURES...............................................................................................................65
5.10.1 Factless Fact tables................................................................................................................65
5.10.2 Counting.................................................................................................................................65
5.11 BIG DIMENSIONS.............................................................................................................................65
5.12 HIERARCHIES IN THE BW SCHEMA.................................................................................................66
5.12.1 Hierarchies within a Dimension.............................................................................................66
5.12.2 Hierarchies within a Master Data table of a Characteristic..................................................67
5.12.3 External Hierarchies..............................................................................................................67
2000 SAP AG AND SAP AMERICA, INC. TABLE OF CONTENTS

 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 the
customer in understanding when to apply the various techniques available.
1. Software Version Supported

This document applies to BW Version 2.0B or higher.
2. References
For more detailed information on the SAP BW Architecture please refer to The BW ODS
Whitepaper and to the paper Hierachies in BW.
3. Overview
BW 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 Operational
Data Store (BW ODS).
Note: The new BW ODS introduced with version 2.0B is not to be confused with the ODS layer in
version 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 to
store the results of data cleansing and data transformation processes in transparent tables
called ODS Objects. In so doing the BW ODS forms the historical foundation of the data
warehouse.
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 ODS
Objects in the integration chain is not limited in BW.
The BW architecture graphic (see fig.01, p.2) illustrates that InfoCubes should be founded on
the integration layer for transactional data in the BW ODS. Furthermore the InfoCubes are
linked to common master reference data located in master data tables, text tables, and
(external) hierarchy tables. Thus the BW infrastructure provides the structure for building
InfoCubes 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 AMERICA, INC. 1

BW Information Integration Architecture

Source PSA BW ODS InfoCubes End-User
Systems Persistent Staging Area BW Operational Data Store Data Access
Meta Data
SAP PSA InfoCubes

R/3
APO
Business Rules
CRM
Business Rules
Cleansing & Transformation
BBP
•Ad Hoc
Queries
Extraction
ETL Tools
•Reporting
Legacy •Applications
•Models
Integration
Granularity
External BW Operational Data Store

Provider
Master Data
Change Service
Scheduling Monitoring
Management Management
(figure 01)
In the context of this paper, additional functionality is also offered through the ability to
report 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 and
analysis, 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, OLAP
offers 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 business
terms 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

BW Information Access Architecture

Source PSA BW ODS InfoCubes End-User
Systems Persistent Staging Area BW Operational Data Store Data Access
Meta Data
SAP PSA InfoCubes

R/3 BW
APO •Business Explorer
•Web
CRM •Graphical User Interf
BBP
ETL Tools
SAP-Models
Legacy •Advanced Planning
•Enterprise Mangem
•CRM
BW Operational Data Store Third Party Tools

External (ODBC/ ODBO)
Provider
Master Data
Change Service
Scheduling Monitoring
Management Management
(figure 02)
A simple example:
Sales Organisation Product Organisation Time KPIs

Sales Department Material Group Year Sales Amount
Sales 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 Month
2. 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 yesterday’s Sales Orders for Sales Person ‘Y’.
This does not mean that sales order level data cannot reside in an InfoCube but rather that
this is dependant upon particular information needs and navigation.
ODS Object should not be misused for multi-dimensional analysis.

There are no hard and fast rules about the architecture of an enterprise data warehouse and
this will not be discussed in any further detail here. It is important to bear in mind that this
document 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 BW
schema is based on the Star schema, an introduction to the Star schema will be given in
Chapter 3, and some general aspects explained. The BW schema is explained in detail in
Chapter 4, where modeling aspects that are derived directly from the BW schema are also
explained. Chapter 5 deals with time aspects in the BW schema and further demands which
might have to be designed with BW.

 From Multi-Dimensional Model to InfoCube – Step

One
This chapter deals with the basic stages of multi-dimensional data modeling to foster a basic
understanding for the more detailed discussions that follow. The experienced reader may
therefore want to skip this chapter.
1. The goals of multi-dimensional data models

The 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 the
different perspectives that influence them (sales organization, product/ material or time).
In other words, to deliver structured information that the end-user can easily navigate by
using 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. The
most popular physical implementation of multi-dimensional models on relational database
system-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 Area
As this paper describes the process of modeling BW InfoCubes, it is assumed that the subject
area for which we want to create a solution is well defined. It may become apparent during
the 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 Content

The 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 therefore
questionable whether BW data modeling needs to be discussed in general terms, and where
the source data is from R/3 applications it is not essential. But even in such cases the
information needs of the end-user must first be understood before these can be compared
with 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. Business
Content and how to benefit from it in the modeling process is not discussed here as this is
done 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.

4. Basic Modeling Steps

These steps should be understood as a general approach. To what extent they must be
carried 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 SAP
BW based solution are (see fig.03, p.6):
1. Focus 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. Focus 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. Build 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
 Focus on the structure of information  Focus on analytical needs -

Overcome model complexity
ERM Sales Rep ID Material ID
MDM/ Star Schema
LastName Material Name
SalesDep Material Type
Material Group
Sales Org Dimension
Material Dimension
Material ID
Sales Rep ID
Customer ID Time Code ID Time Code ID
Customer ID
Customer Name Year
City Sales Amount Fiscal Year
Region Quantity Quater
SalesRep ID Office Name Unit Price Mounth
FACT Day of the Week
Last Name OrgStr. DIM ID Material ID
Customer Material
DimensionDIM ID
...
Mat.description Time Dimension
SalesRep Material ID
SalesDep MatType MatType
SalesDep ID ...
Address
...
Material DIM ID
OrgStr DIM ID
Time Code ID
SAP BW ....
Quantity
.....  Build the solution as a
part of an integrated
data warehouse
(figure 03)

1. Step 1: Develop a complete understanding of the underlying business

processes
In this step we focus on the 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 to
draw 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 approach
a 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-user’s 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 (see
fig.05):
(figure 05)
Ask the end-user how performance is measured.

This will give you the basic Facts. Facts are normally additive and describe n:m
relationships. In a business scenario with a working document this document forms an
Intersection Entity which often resolves the n:m relationships to 1:n relationships. In the
first instance, however, it is up to the end-user whether or not to include the working
document in the model when analysing, for example, a sales transaction level (see fig.06):
Material group Sales Department
Sales Transaction
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 relationships
between entities and relationships between entities and their attributes.
This draws your attention to any ‘abnormal’ situations like n:m relationships between an
entity and an attribute (s. material and color). These relationships have to be treated carefully
(see fig.08, p.9).

Material group Sales Department

Sales dep. no
Material group no
Sales dep. location
Material group name
.......
....
Customer
Customer no
Customer name
City
Region Material Sales Person
Material no Sales pers. no
Material name Sales pers. name
Material type .......
 color
 price
Sales Transaction
Date
Customer no
Material no
Sales pers no
Amount
Quantity
Currency
(figure 08)
Material Group
Region Sales Dept. Loc.
City Color Material Type Sales Dept.
Price
Sales order
(figure 09)
After completing these steps you will have a good idea about the business terms involved and
how the relationships between them are configured. This provides a good basis for a
multidimensional model.
2. Reaping benefits of BW’s Business Content

In SAP product-based scenarios the Business Content InfoSources provide a good basis on
which 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-generated
structures like LIS and CO-PA you have to refer to these structures. The result is normally a
complete set of entities and attributes. The relationships can be derived from the SAP product
data model if they are not obvious.

Even if the solution is not entirely SAP product based, or you plan to migrate a source legacy
system 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 (see
fig.10).
 Focus on analytical needs -

Overcome model complexity
ERM Sales Rep ID Material ID
MDM/ Star Schema
Material Group
Sales Org Dimension
Material Dimension
Material ID
Sales Rep ID
Customer ID
Customer Name Year
City Sales Amount Fiscal Year
Office Name Unit Price Mounth
Customer Dimension
Time Dimension
(figure 10)
Overcoming model complexity involves the creation of a schema that is comprehensible for
both 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 from
step 1 that are arranged in a parent-child relationship (1:N), into groups. These groups are
called 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 dimension
represent a specific business view on the facts (or key figures or KPIs), which are derived
from the intersection entities. The attributes of a dimension are then organized in a
hierarchical way and the most atomic attribute that forms the leaves of the hierarchy defines
the granularity of the dimension. Granularity determines the detail of information. This
model is called Multi-Dimensional Model (MDM). The Multi-Dimensional Model, where
the facts are based in the center with the dimensions surrounding them, is a simple but
effective 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 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.

In a Star schema, one dimension represents one table. These dimension tables surround the
fact table, which contains the facts (key figures), and are linked to that fact table via unique
keys, one per dimension table. Each dimension key uniquely identifies a row in the
associated dimension table. Together these dimension keys uniquely identify a specific row
in the fact table (see fig.11).
Star Schema
Material ID
Sales Rep ID
Material Name
LastName
Material Type
SalesDep
Material Group
Sales Org
Dimension Material ID Material
(Table) Sales Rep ID Dimension
Time Code ID (Table)
Customer ID
Customer ID Time Code ID
Customer Name Sales Amount Year
City Quantity Fiscal Year
Region Quater
Office Name Mounth
FACT (Table) Day of the Week
Customer
Dimension Time
(Table) Dimension
(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
The Fact Table (fig.12):

C
u
st
ome
rSt
r
eet S
a
le
sP
e
rs S
a
le
sR
e
gi
on M
a
t
e
tr
i
ra
l
l U
a n
it D
a
D
te
a
t
e
I
des
Gmb
h M
e
i
er M
o
ni
tor 9
8
11
18
C
u
st
om
me
r
eSa
l
esP
e
rs
Mat
er
ia
lD
at
eAm
o
un
tQ
ua
n
ti
ty
I
des
Gmb
hMe
i
er M
o
ni
tor 9
8
11
18 1
0
00 2
(figure 12)
The basic process of mapping an ERM to the MDM/ Star schema is shown on the following
graphic (fig.13):
Material Group
Region Sales Dept. Loc.
City Color Material Type Sales Dept.
Price
Sales order
Sales Rep ID Material ID

Material Group
Sales Org Dimension Material ID
Sales Rep ID Material Dimension
Time Code ID
Customer ID
Customer ID Sales Amount Time Code ID
Quantity
Customer Name Year
?
Unit Price
City Fiscal Year
Region Quater
Office Name Mounth
Customer Dimension
Time Dimension
(figure 13)

General Mapping Guidelines

 Fact Table:
A central intersection entity defines a Fact Table. An intersection entity such as document
number 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 each
other 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 such
as 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, time
attributes (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 additional
considerations will impact on the grouping of the attributes and will be discussed in detail
later.
6. Step 3: Create an InfoCube Description

Build the solution within BW, respecting analytical needs, and as part of an integrated data
warehouse.
Translating the MDM/ Star schema (the results of Step 1 and Step 2) into an InfoCube
description is of course the topic of this paper and will be investigated in the following
chapters in depth.
An initial introduction is given in the following graphic (see fig.14, p.14):

Translate the MDM/ Star Schema into an InfoCube Description:
Sales Rep ID Material ID

Material Group
Sales Org Dimension
Material Dimension
Material ID
Sales Rep ID
Customer ID
Customer Name Year
City Sales Amount Fiscal Year SAP BW
Office Name SalesRep ID Mounth
Unit Price
Last Name OrgStr. DIM ID Material DIM ID Material ID
Customer Dimension ...
Time Dimension
SalesRep Material ID Mat.description
MatType
MDM/ Star Schema SalesDep ID
SalesDep MatType
...
Address
...
Material DIM ID
OrgStr DIM ID
Time Code ID
....
Quantity
.....
(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 - 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 table
5. The facts, including pre-calculated facts
6. How to track slowly changing dimensions
7. The aggregations, heterogeneous dimensions, mini-dimensions, query modes and other
physical storage decisions
8. 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)

 Star Schema Basics and Modeling Issues

In 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. We
start 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 the
modeling properties of the BW schema before that is discussed in the next chapter. We
emphasize 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 this
example (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
Material ID
Sales Rep ID
Material Name
LastName
Material Type
SalesDep
Material Group
Sales Org
Dimension Material ID Material
(Table) Sales Rep ID Dimension
Time Code ID (Table)
Customer ID
Customer ID Time Code ID
Customer Name Sales Amount Year
City Quantity Fiscal Year
Region Quater
Office Name Mounth
FACT (Table) Day of the Week
Customer
Dimension Time
(Table) Dimension
(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 Material
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 table
affected.
 Accessing the Fact Table

Using the key values evaluated during browsing, select all records in the fact table
that have these values in common in the fact table record key.
2. Star Schema Issues

With 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 handled
is 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 the
fact 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 is
identified by the combination of key attributes in the dimension tables. In this case
the customer number, material ID and the day (fig.16):
Changes in the real world -> new rows in the fact table
Material Dimension Table Customer Dimension Table Time Dimension Table

Materialgroup
Materialgroup Material
Material Customer
Customer Custgroup
Custgroup Day
Day Month
Month Year Year
XX AAA
AAA 4711...........................
4711........................... 19980901 .....................
19980901 .....................
XX BBB
BBB 4712...........................
4712........................... 19980902
19980902 .....................
.....................
YY CCC
CCC
YY DDD
DDD Fact Table
Material Customer Day Revenue
Material Customer Day Revenue
AAA
AAA 4711
4711 19980901
19980901 100
100
BBB 4712 19980901 100 Accessing new record
BBB 4712 19980901 100 in fact table
CCC
CCC 4712
4712 19980901
19980901 100
100
DDD
DDD 4712
4712 19980901
19980901 100
100
BBB
BBB 4711 19980902
4711 19980902 100
100
Add new record

to fact table
BBB 4711 19980902 100

Transaction record
Star-II. The role of dimension tables

There are also changes between the attribute values of attributes within the
same dimension (e.g. the material X no longer belongs to material group Y but to
material group Z). Usually these changes occur more or less frequently and in
theory they are therefore called ‘slowly changing dimensions’. How these changes
are dealt with has a big impact on reporting possibilities and data warehouse
management. The different possible time scenarios and how to solve these within
BW are discussed in detail in the next sections.

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 time
span would show the customers that have revenue, but not the customers that have
no 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 desired
aggregated 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 performance
reasons.
Attribute Relationships (Hierarchies)
In the Star schema there is one (real) attribute (most granular) as the unique
identifier 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 term
hierarchy. 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 within
a 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 star
dimension table, as we would have one material value associated with multiple
colors. 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 the
facts are offered at different attribute levels, whereby the attributes belong to the
same dimension. For example, assume the attributes material and material group
exist in the same dimension. Some subsidiaries can offer transactional data at
material level whereas others can only offer data at material group level. The result
in 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 between
some attribute values, whereas with others there is none. As the relations between
attribute values of different attributes within a dimension form a tree that will result
in paths of differing lengths from root to leaves, these unbalanced hierarchies will
produce reports with dummy hierarchy tree nodes.
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 least
1:10 to 1:20).
Schema Maintenance
Star-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 the
underlying 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-based
functionality to cover the end-users analysis needs.
Creating a valid multi-dimensional schema in BW means that you always have to bear in
mind the overall enterprise data warehouse requirements and the solution-specific analysis
and reporting needs. Errors in this area will have a deep impact on the solution, resulting in
poor performance or even an invalid schema.
1. Overview
The graphic shows a multi-dimensional BW schema using the example from the previous
chapters. Only those parts that are important as far as modeling is concerned are included
(fig.17).

S aS a ll e es R se p OM a srt e gr T a bDl e i m e n s i o n M a te ria l M a t e r ia l M a s t e r T a b le
S a le s R e p N u m b e r
S a le s R e p N u m b e r D im e n s io n M a te r ia l N u m b e r
M a te r ia l N u m b e r
M a te r ia l T y p e
S a le s D E P
S a le s O r g _ D im e n s io n _ ID M a t e r ia l_ D im e n s io n _ ID
M a te r ia l T e x t T a b le
S a le s R e p T e x t T a b le
S a le s R e p N u m b e r M a t e r ia l N u m b e r M a te r ia l N u m b e r
S a le s R e p N u m b er M a te r ia l N u m b e r
S a le s R e p N u m b er Language C ode
Languag e C ode S a le s O r g D im e n s io n T a b le M a t e r ia l D im e n s io n T a b le Language C ode
Langua g e C ode
M a te r ia l N a m e
S a le s R e p N am e
M a t e r ia l_ D im e n s io n _ ID
M a t e r ia l H ie r a r c h y T a b le
S a le s O r g _ D im e n s io n _ ID
In fo C u b e
V e rtri e b s o rg a n i s a ti o n
T im e _ D im e n s io n _ ID
C u s to m e r _ D im e n s io n _ ID R e g io n 1 R e g io n 2 R e g io n 3
M a t eB e z irr k 2 i a l B e z Gir k 3 r o B e zuir k 4 p

B e z ir k 1 B e z ir k 5
C u s to m e r M a s te r T a b le S a le s A m o u n t
G e b ie t 1 G e b ie t 2 G e b ie t 3 G e b ie t 3 a G e b ie t 4 G e b ie t 5 G e b ie t 6 G e b ie t 7 G e b ie t 8
C u s to m e r N u m b e r Q u a n tity
C u s to m e r N u m b e r
C ity
R e g io n F A C T T a b le
C u s to m e r _ D im e n s io n _ ID T im e _ D im e n s io n _ ID
C u s to m e r T e x t T a b le C u s to m e r N u m b e r Y ear
Q u a te r
C u s to m e r N u m b e r M o u n th
C u s to m e r N u m b e r
Language C ode C u s to m e r D im e n s io n T a b le D ay
Language C ode
C u s to m e r N a m e T im e D im e n s io n T a b le
C u s to m e r D im e n s io n T im e D im e n sio n
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 called
the Master Data Table for the characteristic. In BW they are called
terminology attributes (e.g. material type).
 Text Tables
Textual descriptions of a characteristic are stored in a separate text table. The
system runs in different languages at a time.
 External Hierarchy Tables

Hierarchies of characteristics or attributes may be stored in separate hierarchy

tables. 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 are
hierarchies 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 InfoCube
consist 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 and
BW ODS Object in the data warehouse.
These master tables are the glue that binds the data warehouse and are discussed in
depth 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 linked
directly to InfoCubes, as the following, simplified, picture illustrates (fig.19):
Multi-Dimensional Schema in BW

Master Text Master Text
SID Tables Hierarchies Master Text

Master Text SID Tables Hierarchies
SID Tables Hierarchies

Dimension SID Tables Hierarchies

Table
Master Text
Master Text
Dimension Dimension
SID Tables Hierarchies Table Table
FACT
Dimension Dimension Master Text

Table Table
Master Text SID Tables Hierarchies
Master Text
SID Tables Hierarchies SID Tables Hierarchies
Master Text
Master Text
(figure 19)
As you can see, pointer or translation tables called SID (Surrogate-ID) tables are used in the
BW 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 are discussed
in detail in the section on the SID table.
3. Dimensions in a BW schema
Earlier 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 dimension
such 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 that a
dimension in the BW schema might consists of different parts (fig.20):

M a te r ia l M a te r ia l M a s te r T a b le
D im e n sio n
M a t e r ia l N u m b e r
M a te r ia l T y p e
M a te r ia l_ D im e n s io n _ ID
M a t e r ia l T e x t T a b le
M a te r ia l N u m b e r M a t e r ia l N u m b e r
L a ngu a ge C o d e
M a t e r ia l D im e n s io n T a b le L an g u ag e C o d e
M a t e r ia l N a m e
M a te r ia l H ie r a r c h y T a b le
V e r trie b s o rg a n is a ti o n
R e g io n 1 R e g io n 2 R e g io n 3
M a t eB e z irr k 2 i a l B e z Girk 3 r o B e zuirk 4 p

B e z irk 1 B e z ir k 5
G e b ie t 1 G e b ie t 2 G e b i e t 3 G e b i e t 3 a G e b ie t 4 G e b ie t 5 G e b ie t 6 G e b ie t 7 G e b ie t 8
(figure 20)
We emphasize that:
Dimensions in a BW schema
The dependent attributes of the characteristics can reside in different locations of a BW
schema 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 Dimension
Material
Dimension table
Material
As a Characteristic ?
Material
Master table
As a Navigational /
Display Attribute ?
Materialgroup
As a Hierarchy ? Material
Hierarchy table

(figure 21)
As the graphic shows, the material-material group relation can be designed defining material
group
 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 a
characteristic in the material dimension table and as an attribute of material in the material
master 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.

1. Master Data Table

In defining an InfoObject of type characteristic you have the following modeling-relevant
options 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 have
the master table of the referred characteristic.
For example: the characteristics ‘sending cost center’ and ‘receiving cost center’ refer to the
same 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 the
modeling phase. The attributes are added using the ‘attributes’ tab page in InfoObject
maintenance.
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 tab
page-> navigational check boxes). If you mark the navigation check box of an attribute this
attribute is called a navigational attribute.
Note: you have to activate the navigational attributes in the InfoCube definition to allow
navigation with respect to this InfoCube.
In terms of navigation, navigational attributes behave like characteristics in an InfoCube. But
the reporting behavior of the navigational attributes in master tables differs from the
characteristics behavior.
Attributes not used for navigation are called display attributes. If an InfoObject of type
characteristic is an attribute and not marked as a navigational attribute then it is only possible
to 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.

5. InfoObject names and names of attributes

It is possible to create schemas that have the same InfoObject for the characteristics in the
dimension table of an InfoCube, and for the navigational attribute of another characteristic
also in the InfoCube. To avoid confusion you should give the navigational attribute a name
different 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 attribute
from MMATERIAL. Let us assume that MMATGR is a result of a model that is also a
characteristic 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 would
occur twice in the InfoCube description of the query builder, most certainly confusing the
end-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 time
dependent attributes.
Example: non-time dependent attributes:
The InfoObject ‘material’ has the attribute MatType and we are only interested in using the
latest materials - MatTypes constellations within reports.
MatType is defined as a non-time dependent attribute (there is no check in the time
dependent check box). Let us assume that material ‘BBB’ has MatType ‘300’ in 09 1998. A
new assignment of MatType ‘200’ to material ‘BBB’ in 10 1998 would then overwrite the
old constellation. The material – MatType assignments are stored in the non-time dependent
attribute 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’ has
MatGroup ‘X’. Then, from October, 1st 1998 a new assignment of MatGroup ‘Y’ to material
‘BBB’ is valid. The result is a new record in the time dependent attribute master data
table with the respective validity. The old constellation gets only a new ‘date to’ value
(fig.23):

Material DateFrom DateTo MatGroup

AAA 01 /1000 12 / 1999 X
BBB 01 /1000 99
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 attribute
value 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 using
the 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!

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/3
applications 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 the
characteristic 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 data
tab 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 the
subject-oriented InfoCubes and ODS Objects.
To speed up access to InfoCubes and to allow an InfoCube and ODS-Object independent
master data layers, each characteristic and attribute is assigned a SID column and their values
are encoded into 4-byte integer values.
Note:
The algorithm to determine a SID value works fastest if the characteristic does not exceed the
numerical size of nine as in this case the characteristic values will be the SID. No traditional
SID 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 an
InfoObject is not defined as ‘attribute only’ (tab page general). This table is used if the
access to an Infocube or ODS-Object uses a navigational attribute or if the access is via a
characteristic without attributes.
 The non-time dependent attribute SID table of a characteristic for access via non-time
 The time dependent attribute SID table of a characteristic for access via time

Example:
Supposing the InfoObject ‘material’ has both ‘non-time dependent’ and ‘time dependent’
attributes. 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/Pmaterial (fig.24)
Materiall
AAAMatType
BBB 100
CCC 200
DDD 100
100
Non-Time Dependent Attribute Master Data
(table
Tablename:
 Material master table for time 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)

 Material time dependent attribute SID table : /BIC/YMaterial (fig.28)

Material-SID MatGroup-
Material
001 AAA DateFrom
/1000 DateTo
12/9999 SID 910
002 BBB 01 /1000 09/1998
002 BBB 01 /1998 12/9999 910 920
003 10 /1000 12/9999
CCC
004 DD 01 /1000 12/9999920 920
D 01
Time Dependent Attribute SID
(table name:
Table
/BIC/YMaterial)
(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 to
how 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 the
characteristic material in the material master data table and we have no predefined aggregates
at material group level.
How the different material dimension tables operate together to access the InfoCube fact
table is shown in the following picture (fig.29, p.29):

SID Tables for Infocube Access
Material
MaterialMaster
Mastertable
table Example: Show me the sales values for material group X
(Name: /BIC/PMATERIAL)
(Name: /BIC/PMATERIAL) and Y
Material MatGroup
MatGroup SID MatGroup
AAA X
CCC Y X 345
DDD Y 678
Y MatGroup
Z 999 MatGroupSID
SIDtable
table
Not used for Infocube access ! (Name:
(Name:/BIC/SMATGROUP)
/BIC/SMATGROUP)
SID Material Material SID MatGroup
111 AAA 345

222 CCC 678
333 DDD 678 Material
MaterialNon-time
not time dependent
Attributes
ddependantdepend
Attributes SID
SIDtable
table
(Name: ent
(Name:/BIC/XMATERIAL)
/BIC/XMATERIAL)
Dim ID SID Material
Dim ID Sales
1 111
1 10.000 2 222
2 12.000 3 333
3 25.000 Not used in this Example :
Not used in this Example :
•Traditional Material SID Table: /BIC/S
MATERIAL
Dimension table •Traditional Material SID Table: /BIC/S
MATERIAL
•Time dependent Material Master Table: /BIC/Q
MATERIAL
•Time dependent Material Master Table: /BIC/QMATERIAL
Fact table •Material Time dependent Attributes SID Table: /BIC/Y
MATERIAL
•Material Time dependent Attributes SID Table: /BIC/YMATERIAL
(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’) for material 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’ and
‘3’)
 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, time
dimension 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 in
the fact table that have these values in the fact table record key.

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 5 5
5
5
2 4 5
4
5
3 5
2 1 2
5
5 5
3 2 3
5 5
(1) Fact Table
5 5
3 3
(2) Dimension Tables
5
(3) time-independent-SID
(4) time-dependent-SID
5 5
(5) ‘traditional‘ SID
(figure 30)
2.External Hierarchy Table

In general hierarchies are structures essential to navigation. Having characteristics and
attributes 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 data
and, as mentioned above, are independent of specific InfoCubes. They are therefore called
external hierarchies. The different model properties of ‘internal’ and ‘external’ hierarchies
in the BW Schema will be discussed in chapter 5.
During the creation of an InfoObject of type characteristic you can define the basic
functionality 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)

2. Or (exclusive) allow time dependency for each external hierarchy node (time
dependent structure)
With both structure types you can allow intervals for the leave nodes, which makes the
definition 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 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. External
hierarchies can be used for characteristics in the dimension tables and for activated
navigational 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 navigational
attribute in the customer master data table. The nodes are of a textual nature. If ‘continent’
was an InfoObject of type characteristic we could use this InfoObject to define the nodes
using its characteristic values like ‘Europe’ (fig.31):
Country Hierarchy
-3 World
-2 Europe
3 Germany
4 Austria
5 Switzerland
-1 America
1 USA
2 Canada
6* Japan
* Set Ids only shown for better understanding
(figure 31)

The following graphic illustrates how the access works (fig.32):

Inclusion Table:
SID Table: Country
Country SID Table: Nodes
Child Parent
Country SID Nodes SID
-2 -3
Japan 6 America -1
-1 -3
Germany 3 6 -3 Europe -2
Text & Text &
Austria 4 Rep. Attributes 3 -2 Rep. Attributes
Switz. 5 World -3
4 -2
USA 1 5 -2
Canada 2 1 -1
2 -1
Customer Dimension Table

DIM-ID Cust-SID Country-SID
Fact 11 1711 1
Table 22 1712 1
33 2711 2
44 3711 3
55 4711 4
66 5711 5
77 6711 6
(figure 32)
A node of a hierarchy can either be textual or it can be an InfoObject with a specified value
e.g. InfoObject ‘material group’ with value ‘X’. All display attributes of the InfoObject
‘material group’ are associated with this node.
The use of InfoCube-independent hierarchy tables is an additional prerequisite for an

enterprise-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 same
hierarchy 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 be
direct members of this InfoCube. After this you define your dimensions and assign the
selected 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 table

The columns of a dimension table are not the characteristics themselves but the SIDs of the
characteristics you have chosen to be members of the InfoCube dimension (table). The
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 Cust-SID Country-SID
11 1711 1
22 1712 1
33 2711 2
44 3711 3
55 4711 4
66 5711 5
77 6711 6
(figure 33)
In the BW schema a surrogate key is used as a unique key with each dimension table and not
the real most granular characteristic within the dimension. For example, for each unique
combination of SID values for the different characteristics within a dimension table there is a
unique surrogate key value assigned. The dimension tables are joined to the 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 be discussed 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 or
not)
 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.

 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 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) and
filtering within queries. Navigation with navigational attributes of InfoCube characteristics
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 to
purge erroneous loads without recreating the whole InfoCube again. The packet dimension
can increase overheads during querying and can therefore be eliminated using the compress
feature 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 of
type ‘amount’ or ‘quantity’.
 Important
If you are not interested in unit or currency calculations you should define the key figures
as numbers and then introduce the unit in the key figure header (i.e. sales in HL). This
will 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.

This will probably occur with specific reporting requirements or if for example you have the
document 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 will
serve the SID table of this characteristic. The key in the fact table will be the SID of the SID
Table (fig.34).
Line item dimension:
Line-Item
5 5
Dimension
5
5
2 4 5
3 5
3 1 2
5 5
5
2 3
5
(1) Fact Table
5 5
3 3
(2) Dimension Tables
5
(3) time-independent-SID
(4) time-dependent-SID
5 5
(5) ‘traditional‘ SID
(figure 34)

4. Fact table
The fact table is created during InfoCube activation. The structure of the fact table in the BW
schema 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 respective
DIM IDs/ SIDs of the dimension/ SID Tables
 Since the BW uses system-assigned surrogate keys, namely DIM IDs or SIDs of 4 bytes
in length per dimension to link the dimension / SID tables to the fact table, there will
normally be a decrease in space requirements for keys in comparison to the use of real
characteristic 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 tables

Each InfoCube has two fact tables:
The F-fact table, which is optimized for loading data, and the E-fact table, which is
optimized for retrieving data (fig.35).
5 5
2 Multiple
Fact Tables 5
4 5
5
E
3 5
3 2
5 5
F
5
3
5
(F) F-Fact
(F) F-Fact Table
Table Requid
Request >0 2 5
> 0E-Fact Table Request = 0
(E)
(E) E-Fact Table Requid
=0
3 3 5
(2) Dimension
Tables 5
(3) time-independent-
(4)
SIDtime-dependent- 5 5
(5)SID‘traditional‘
SID 35)
(figure

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 partitioning

BW supports the partitioning of fact tables.
Partitioning is a database feature and in short means that one table is split internally into
several tables, its partitions. Partitions of a table have their own index areas that are therefore
smaller areas than the entire table would have. Together with the possibility of internally
splitting a normally sequential request on the entire table into several parallel requests fired
on 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).
5 5
Time
Dimensio Partitioning
n 5
Fact Tables
5 4 5
E 5
2 3
3
5 5
F
5
3
5
(F)
(F)F-Fact
F-FactTable Request
Table >
Requid 5
0
> 0E-Fact Table Request =
(E)
(E) E-Fact Table Requid Packe
0 Dimensio
t
=0
(2) Dimension 3 3n
Tables
(3) time-independent-
(4)
SIDtime-dependent-
(5)SID
‘traditional‘
SID
(figure 36)

Together with the entire value range for the partitioning InfoObject that you would expect
and the optional maximal number of partitions, the value range for each partition is
determined.
Note: Partitioning is a database functionality. Have a look at the OSS to find out how and to
what extent your database provider supports partitioning!
For example:
Let us assume we want to partition a fact table using 0CALMONTH. We want to
have data in our fact table starting from ‘199901’. Let us further assume that we
expect a lifespan of our InfoCube up until ‘201012’. Without specifying a maximum
value 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 value
less 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 to
compress your InfoCube on a regular base!
BW Terminology
3.
The following picture shows differences in the terminology (fig.37):
MDM / Star Schema BW Schema
Fact Key Figure

Fact Table Fact Table
Characteristic /
(Dimension) Attribute Navigational Attribute/
Display Attribute /
(external) Hierarchy
Node
Dimension Table /
Master Table /
Dimension (Table) Text Table /
External Hierarchy
Table /
(SID Table)
(figure 37)

 Important
It should again be noted that generally attributes/ characteristics are sometimes called
dimensions. This a potential point of misunderstanding as saying that the BW Schema offers
16 dimensions, three of which are used internally, sounds very limited. Using this definition
of 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 BW
schema.
Trying to map real world processes, the following graphic illustrates the competition of
different interests that always arise during the design phase. This explains why even some of
the following modeling recommendations contradict each other. A good design will always
be a compromise.
We will therefore also leave out the impacts of modeling, especially on performance and vice
versa (although please have also have a look at the accelerator ‘Sizing and Performance’)
(fig.38).
Competition in Data Warehousing
Analysis
Aspects
Global
Performance
Data Warehouse
Aspects
Design Aspects
(figure 38)

5. Granularity
An important result of the data modeling phase is that the granularity (the level of detail of
your data) is determined. Granularity deeply influences
 Reporting capabilities
 Performance
 Space needed
 Load Time
You have to decide whether you really need to store detailed data in an InfoCube or whether
it is better in an ODS object or even not stored in your data warehouse at all, but accessed
directly from your Source system via drill thru.
These decisions are decisions that do not only influence your current scope, but the entire
approach 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 be
estimated? 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 large
impact on querying efficiency and overall storage requirements. The granularity of the fact
table is directly impacted by dimension table design as the most atomic characteristic in each
dimension determines the granularity of the fact table. For example, let us assume we need to
analyze 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 are
grouped 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 all
articles 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 attributes
if all articles are sold within a week
Granularity: article, day, 300 sales days a year
1,000 X 300 = 300,000 records in the fact table per year due to only these two
attributes if all articles are sold within a day
Granularity: article, hour, 300 sales days a year, 12 sales hours a day

500 X 300 X 12 = 1,800,000 records in the fact table per year due to only these two
attributes 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 Storage
Quite obviously granularity directly impacts the storage space needed. As it stores the
transaction data, the fact table is the largest table in the InfoCube. Therefore, estimating the
size 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 conjunction
with 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
 Important
Remember 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, there
are a few additional considerations to bear in mind.
Aggregation
For 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.
Partitioning
Partition the fact table. The option exists to divide a table with respect to the values of
a 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 smaller
indexes.
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 the
projects blueprint phase.

Parent Attributes in BW (fig.39)

Material Dimension
Material
Dimension table
Material
As a Characteristic ?
Material
Master table
As a Navigational /
Display Attribute ?
Materialgroup
As a Hierarchy ? Material
Hierarchy table
(figure 39)
The freedom to choose between the different locations of dependent attributes is actually
restricted as the reporting behavior and possibilities differ and depend upon the location.
Thus the reporting needs investigated during the blueprint phase of the project normally
define the location of a dependent attribute. This is discussed in detail in the following
chapters.
5. Performance and location of dependent attributes

The reporting needs should guide you in the deciding where to put a dependent attribute.
There is little or nothing to be said in terms of performance to favor locating attributes in an
InfoCube dimension table instead in master or hierarchy tables.
6. Enterprise data warehouse and location of dependent attributes

From the perspective of the company data warehouse and aside from analysis demands and
performance issues, the following hint should be observed:
 Parent attributes should be placed in master tables (->Navigational/ Display Attributes) or
designed as an external hierarchy to minimize redundancy and to guarantee integration in
the data warehouse.
Data warehousing should mean controlled redundancy to achieve a high degree of
integration. From this point of view, all dependent attributes should reside in master tables or
in cases where there is only one characteristic, in each dimension table (see line item
dimension).

7. Data load and the location of dependent attributes

Aside from analysis demands, the following hint should be observed:
 Characteristics delivered by transaction data load are normally located in dimension
tables (rule of thumb)
There are different load processes within BW covered by different types of InfoSources:
 InfoSources for transaction data load that fill the InfoCubes
 InfoSources for master data load that fill master data tables, text tables and hierarchy
tables
Thus dimension tables are maintained during transaction data load which means that to put a
characteristic in a dimension table that is not delivered from transaction data load or that
cannot be simply derived from transaction data (like calendar year from date) means
additional lookup of master data tables and thus a certain overhead during load time.
8. Tracking history in the BW schema

We now turn to the most important aspect of data warehousing: time
9. History and InfoCube
Time and Fact Table

Changes over time are normally tracked in the fact table by loading transaction data.
It is the task of the fact table to track changes (e.g. sales) between characteristics of different
dimensions.
For example:
If the material ‘EEE‘ is purchased by customer ‘123‘ on day ‘19990630‘, this sale will occur
as a new row in the fact table and making the existence of the new relationship between
material ‘AAA‘ and customer ‘123‘ and date ‘19990630’ visible.
Events that did occur

The fact table normally reports things that did happen. There is no easy way to report on
things that did not happen.
Dimension tables and real world changes

Changes in the relationship between the values of two characteristics within a dimension
table will be tracked automatically. For example, if during the transaction data load a new
value combination for characteristics within one dimension table is detected, a new DIM ID
will be assigned for this new combination and a row added to the dimension table reporting
this new constellation. Additionally a row is added to the fact table where this DIM ID,
among others, resides (fig.40, p.44).

Materialgroup SID
Mat Mat-SID Material Dimension Table
AAA 001 Mat-GR-SID
Mat-GR-SIDMat-SID
Mat-SID Mat-DIM-ID
Mat-DIM-ID Fact Table
BBB 002
910
910 001
001 111
111
CCC 003
Mat-DIM-ID
910
910 002
002 222
222 Mat-DIM-IDTime-DIM-ID
Time-DIM-ID Revenue
Revenue
DDD 004
920 002 666 111
111 09/1998
09/1998 100
100
EEE 005 920 002 666
920 003 333 Fact
222 Table
09/1998 100
920 003 333 222 09/1998 100
Material SID 920
920 004
004 444
444 333
333 09/1998
09/1998 100
100
920
920 005
005 555
555 444
444 09/1998
09/1998 100
100
Mat-GR Mat-GR-SID 111
111 10/1998
10/1998 100
100
X 910 222
222 10/1998
10/1998 100
100
333
333 10/1998
10/1998 100
100
Y 920
444
444 10/1998
10/1998 100
100
Add new record to dim table
555
555 10/1998
10/1998
10/1998 100
100
Add new record
to fact table
Transaction record EEE Y 10/1998 100
(figure 40)
Changes in the relationship between the values of parent-child attributes within a dimension
are discussed in detail in the next chapter.
10. Slowly Changing Dimensions

The ‘normal’ job of an InfoCube is to track any changes between attributes of different
dimensions (like a sales transaction) and is covered by the fact table.
But there are also changes between characteristic value and dependent attribute value
assignments. For example:
The material ‘BBB’ belongs no longer to material group ‘X’ but to material group ‘Y’.
Usually these changes occur rarely and in theory they are addressed as ‘slowly changing
dimensions’. How these changes are handled has a big impact on reporting possibilities and
data warehouse management.
Again it is to be stressed that:

Reporting possibilities differ depending on whether you define a dependent attribute as a
characteristic, a navigational attribute or a node of an external hierarchy, because the
locations offer different time scenarios.

We will use the following example to explain the different time scenarios (fig.41):
Constellation 09/1998:
Material Material group
AAA X
Fact Table
BBB X
Material Date Revenue
CCC Y
AAA 09/1998 100
DDD Y
BBB 09/1998 100
CCC 09/1998 100
Constellation 10/1998: DDD 09/1998 100
Material Material group AAA 10/1998 100

AAA X BBB 10/1998 100
BBB Y (changed) CCC 10/1998 100
CCC Y DDD 10/1998 100
DDD Y EEE 10/1998 100
EEE Y (new)
(figure 41)
The example shows the material – material group value constellations in 09/1998 and in
10/1998. The fact table shows the transactions that occurred during the same time span.
With this simple example we are able to produce 4 reports with different results that can all
claim to report the truth. But the truth depends on how you treat changes in the relationships
between materials and material groups (fig.42):
Possible reporting demands:

Report using today‘s constellation
Material group Rev 09/98 Rev 10/98
X 100 100
Y 300 400
Report using 09/98 constellation

X 200 200
Y 200 200
Report showing historical truth

X 200 100
Y 200 400
Report showing comparable results

X 100 100
Y 200 200

The reader is invited to implement this little example (just 9 rows in the Fact Table) on BW
to verify the following scenarios:
Scenario I : Report the data to today’s constellation

-Today is yesterday-
Scenario II: Report the data to yesterday‘s constellation as well
-Yesterday is today-
Scenario III: Report the data to the respective constellation
-Today or yesterday-
Scenario IV: Report only on data for constellations valid today and yesterday
-Today and yesterday-
1. Scenario I: Report the data to today’s constellation - today is

yesterday
1. Scenario I: Description
‘Today is yesterday’ or today’s constellation is the truth:

Report all fact data according to today’s value constellation of a characteristic and a
dependent attribute.
Example for Scenario I:

In 10 1998 the assignment of material ‘BBB’ to material group ‘X’ was changed to ‘Y’. A
new material ‘EEE’ assigned to material group ‘Y’ appeared.
You are not interested in the old assignments anymore. Thus you report on the fact data as if
material ‘BBB’ belonged to material group ‘Y’ from the very beginning (fig.43).
Constellation 09/98: Fact Table Reporting demands:

Material Material group Material Date Revenue
AAA X AAA 09/1998 100
BBB X BBB 09/1998 100
CCC Y CCC 09 / 1998 100
Report using Today ‘s constellation
DDD Y DDD 09/1998 100
Material group Rev 09 /98 Rev 10/ 98
Constellation 10/98: X 100 100
AAA 10 / 1998 100
Material Material group Y 300 400
BBB 10 / 1998 100
AAA X CCC 10 / 1998 100
BBB Y ( changed ) DDD 10 / 1998 100
CCC Y EEE 10 / 1998 100
DDD Y
EEE Y ( new )
(figure 43)

Real example:
This time scenario typically occurs with sales forces.
When the assignment of sales persons to customers changes to a new sales person-customer
constellation, all the sales data from earlier times will be reported as if they always referred
to the new sales person. This requirement means a realignment of the fact data to the new
constellation.
Scenario I: Solutions with BW

1st Solution:
‘Today is yesterday’ or today’s constellation is the truth – 1st solution:

Define the dependent attribute of your multi-dimensional model as navigational attribute of
the characteristic.
Example for Scenario I – 1st Solution:

Material group as navigational attribute in the material master table (fig.44)
MatG MatGr- Report using Today‘s constellation

r X SID MatGr ‘Traditional‘ SID Material group Rev 09/98 Rev 10/98
Table
Y 910920 X 100 100
Y 300 400
MatGr-SID Material-
Material
910 SID
AAA
920 001 Fact
BBB
920 002 Table
Mat-DIM-ID
CCC
920 003
DDD Date
111 09/199Revenue
004
920 EEE
222 8 100
09/199
Material 005
Attribute SID 333 09/8
199 100
Table
444 09/8
199 100
Material- -DIM-
111 8
199 100
SID
001 Mat ID
10/222 8
199 100
111
002 10/333 8
199 100
222
003 10/444 8 100
199
333
004 10/555 8 100
MateriaDimension 199
l Table 444
005 10/ 8 100
555
(figure 44)
 The parent attribute (material group) resides in the master data table of the child
characteristic (material) (BW Admin WB: InfoObject maintenance-> attributes).

 The parent attribute has to be defined as a navigational attribute to allow drill and filter
functions (BW Admin WB: InfoObject maintenance-> attributes and InfoCube
maintenance -> navigation).
2nd Solution:
Today is yesterday or today’s constellation is the truth – 2nd solution:
Define the dependent attribute of your multi-dimensional model as a node attribute of an
external hierarchy of your characteristic.
Example – 2nd Solution:

Material group as node attribute of an external material hierarchy (fig.45)
Material SID Report using Today‘s constallation

Materialgroup Rev 9/98 Rev 10/98
Material Material-SID
+ X 100 100
AAA 001 + Y 300 400
BBB 002
Material Hierachy Table CCC 003
DDD 004
-1 EEE 005
Fact Table
(All) Mat-DIM-ID Date Revenue
-2 -3
(X) (Y) 111 9/1998 100
Material Dimension Table 222 9/1998 100
001 002 003 004 005
(AAA) (BBB) (CCC) (DDD) (EEE) 333 9/1998 100
Material-SID Mat-DIM-ID 444 9/1998 100
001 111 111 10/1998 100
002 222 222 10/1998 100
003 333 333 10/1998 100
004 444 444 10/1998 100
005 555 555 10/1998 100
(figure 45)
 Parent attribute resides in the hierarchy table as node attribute of an external hierarchy of
the child characteristic.
 No time-dependent hierarchy name, structure or versions are necessary for the external
hierarchy to implement this scenario.
Today is yesterday or today’s constellation is the truth – conclusion:

If you want to report your fact data in terms of its latest characteristic–attributes value
constellations, the dependent attributes have to be either navigational attributes or nodes of
an external hierarchy of the characteristic. In loading new constellations (master or hierarchy
data), the fact data stored on characteristic level are automatically realigned to the new
navigational attribute or node values.

 Important
If all dependent attributes of a characteristic are navigational or display attributes in the

characteristic’s master data table or nodes of an external hierarchy, then remember you
have the option to define this characteristic as a line item dimension.
2. Report the data to yesterday’s constellation as well -yesterday is today
1. Scenario II : Description
‘Yesterday is today’ or yesterday’s constellation is the truth:

Allow to report the fact not only to today’s but also according to yesterday’s constellation of
characteristics and attribute value assignments.
Example for Scenario II:

As described above, in 10 1998 the assignment of material ‘BBB’ to material group ‘X’ was
changed to ‘Y’. A new material ‘EEE’ assigned to material group ‘Y’ appeared.
You are interested in the new and the old assignments. Thus you are able to report on the fact
data as if material ‘BBB’ belongs to material group ‘Y’ or material group ‘X’ (fig.46).

AAA X AAA 09/1998 100
BBB X BBB 09/1998 100
CCC Y CCC 09/1998 100
Report using yesterday‘s constallation
DDD Y DDD 09/1998 100
Constellation 10/98: AAA 10/1998 100 X 200 200
Material Material group BBB 10/1998 100 Y 200 200
AAA X CCC 10/1998 100
BBB Y (changed) DDD 10/1998 100
CCC Y EEE 10/1998 100
DDD Y
EEE Y (new) ?
(figure 46)
This scenario may be of interest if you want to report the effects of organizational changes.
Example:
When the Materials are reorganized using new material group assignments, this scenario
would allow one query to report your last years sales data with today’s material assignment
and another query with the material assignment which was valid last year, offering a
fundament for comparisons.
A FAQ may be how to handle revenues in the fact table that cannot be assigned to a material
because they do not exist in yesterday’s master data.

Scenario II: Solutions with BW

1st Solution :
‘Today is yesterday’ or today’s constellation is the truth – 1st solution:

Design the dependent attribute of your multi-dimensional model as a time-dependent
navigational attribute of your characteristic.
Example for Scenario II – 1st Solution (fig.47):

Material group as time-dependent navigational attribute of material
MatGr ‘Traditional‘ SID Table

Report using yesterday‘s constellation
MatGr MatGr-SID
X 910
Y 920 X 200 200
Query Keydate = 09/1998
Query Keydate = 09/1998
Y 200 200
MatGr-SID DateFr DateTo Material Material-SID
not assigned 100
910 01/1000 12/9999 AAA 001
910 01/1000 09/1998 BBB 002
Fact Table
920 10/1998 12/9999 BBB 002
Mat-DIM-ID Date Revenue
920 01/1000 12/9999 CCC 003
111 09/1998 100
920 01/1000 12/9999 DDD 004
920 10/1998 12/9999 EEE 005 222 09/1998 100
333 09/1998 100
Material Time Dependent Attribute SID Table
444 09/1998 100
Material-SID Mat-DIM-ID
111 10/1998 100
001 111
222 10/1998 100
002 222
333 10/1998 100
003 333
444 10/1998 100
004 444
Material Dimension Table 555 10/1998 100
005 555
(figure 47)
The material group is a time-dependent navigational attribute of material (BW Admin WB:
InfoObject maintenance-> attributes).
As emphasized above there would be no pre-calculated aggregates possible at material group
level.
How to address different constellations

The DateTo and DateFrom attributes are not for navigation and do not appear directly in the
query builder. Different master data records of the same characteristic value are addressed
using the key date in the properties window of a query. For example, a key date 30.09.1998
means: select master records with DateTo >= 30.09.1998 and DateFrom =< 30.09.1998.
Hint: Define a BW variable to allow flexible reports and analysis (BEX Query Builder) with
different key dates.

 Important
The key date of a query allows you to address different master data records with the
same characteristic value.
This key date is valid for all master records of characteristics having time dependent
attributes.
Using the time-dependent feature you are not able to report more than one master
record (constellation) for a characteristic value at a single query execution.
2nd Solution:
Today is yesterday or today’s constellation is the truth – 2nd solution:
Define the dependent attribute of your multi-dimensional model as a node attribute of an
external hierarchy of your characteristic where the entire hierarchy or even the structure is
time dependent.
Example for Scenario II – 2nd Solution:

The material group is a node attribute of an external hierarchy in the material hierarchy table
where either the entire hierarchy is time dependent or is simply a time-dependent hierarchy
structure. Here we use an entire hierarchy time-dependent external hierarchy (fig.48):
Keydate
Keydate==09/1998
09/1998
Report using yesterday‘s constellation
Material Hierachy Table Material group Rev 9/98 Rev 10/98
-1 -1
(All) (All)
+ X 200 200
-2 -3 -2 -3 + Y 200 200
(X) (Y) (X) (Y) not assigned 100
001 002 003 004 001 002 003 004 005

(AAA) (BBB) (CCC) (DDD) (AAA) (BBB) (CCC) (DDD) (EEE) Fact table
Mat-DIM-ID
Mat-DIM-IDDate
Date Revenue
Revenue
Ext Hierarchy : Mathier Ext Hierarchy : Mathier
Valid From : 01/1000 Valid From : 10/1998 111
111 9/98 100
9/98 100
Valid To : 09/1998 Valid To : 12/9999 222
222 9/98
9/98 100
100
333
333 9/98 100
9/98 100
Material-SID
Material-SID Mat-DIM-ID 444 9/98
Mat-DIM-ID 444 9/98 100
100
001
001 111
111 111
111 10/98
10/98 100
100
002
002 222
222 222
222 10/98 100
10/98 100
003
003 333
333 333
333 10/98
10/98 100
100
004 444 444
444 10/98
10/98 100
100
Material Dimension Table 004 444
005
005 555
555 555
555 10/98 100
10/98 100
(figure 48)
Allow versions and/ or entire hierarchy time dependent or even time-dependent structures for
external hierarchies of the child characteristic (material) (BW Admin WB: InfoObject
maintenance-> hierarchies).
The parent attribute resides as a node attribute of an external hierarchy in the hierarchy table
of the child characteristic (BW Admin WB: InfoObject maintenance-> hierarchies).

Conclusion - yesterday is today:

Yesterday is today allows you to cover 'today is yesterday' situations too but the time
dependency always means more overheads.
There is no reporting on different characteristic–attribute value constellations within a single
query execution (scenario III).
 Important
If all dependent attributes of a characteristic are navigational (time dependent or not) or are
display attributes in the characteristic’s master data table or nodes (time dependent or not)
of an external hierarchy (time dependent or not), then remember you have the option to
define this characteristic as a line item dimension.
Scenario III: Report the data to the respective constellation-today or yesterday-
2. Scenario III: Description
‘Yesterday or today’ or report the historical truth:

Report the data according to the constellation of characteristics and attribute values that was
valid when the data occurred.
Example for Scenario III:

You are interested in reporting the fact data with respect to the material group with the
material assignment that was valid at the date value (fig.49).

Material Materialgroup Material Date Revenue
AAA X AAA 09/1998 100
BBB X BBB 09/1998 100
CCC Y CCC 09/1998 100
DDD Y DDD 09/1998 100 Report showing historical truth
Constellation 10/98:
AAA 10/1998 100 X 200 100
BBB 10/1998 100
AAA X
CCC 10/1998 100
CCC Y EEE 10/1998 100
DDD Y
EEE Y (new)
(figure 49)

This scenario is of interest if you want reports that track the organizational changes (time
rows), for example with Human Resources.
Scenario III: Solution with BW
‘Yesterday or today’ or report the historical truth:

Put the dependent attribute of your characteristic as a characteristic in the same dimension.
Example for Scenario III – Solution (fig.50):

Material group as characteristic in the material dimension table
Report showing historical truth
X 200 100
Y 200 400
MatGr ‘Traditional‘ SID Table

Fact Table
MatGr MatGr-SID
X 910
111 09/1998 100
Y 920
222 09/1998 100
333 09/1998 100
444 09/1998 100
MatGr-SID Material-SID Mat-DIM-ID
111 10/1998 100
910 001 111
666 10/1998 100
910 002 222
333 10/1998 100
920 002 666
444 10/1998 100
920 003 333
555 10/1998 100
Material Dimension Table 920 004 444
920 005 555
(figure 50)
The parent attribute (material group) resides as a characteristic in the dimension table of the
child characteristic (material) (BW Admin WB: InfoCube maintenance -> characteristics).
If the parent characteristic is not delivered via transaction data load an update rule has to be
created to determine the parent characteristic value via automatic lookup in the
characteristic’s master data.
Conclusion - Today or Yesterday:

This scenario illustrates one strength of the BW schema; the usage of surrogate keys (DIM
IDs) for the dimension tables makes this time scenario possible. It allows you to track all the

constellation changes and to assign the validity of such constellations implicitly via the time
in the fact table.
Scenario IV: Report only on data for constellations valid today and yesterday -today
and yesterday-
3. Scenario IV: Description
‘Yesterday and today’ or report the comparable truth:

Report only on the data for constellations of characteristic and attribute values that existed
yesterday and still exist today
Example for Scenario IV:

You are interested in reporting the fact data with respect to the material group only for
material–material group assignments that exist continuously during a certain time span. You
do not want to compare oranges with pears.
In our example only the white colored constellations exist without change in our reporting
time span 09 1998 until 10 1998 (fig.51).

AAA X AAA 09/1998 100
BBB X BBB 09/1998 100
CCC Y CCC 09/1998 100
Report showing comparable results
DDD Y DDD 09/1998 100
Constellation 10/98: AAA 10/1998 100 X 100 100
BBB 10/1998 100
AAA X CCC 10/1998 100
CCC Y EEE 10/1998 100
DDD Y
EEE Y (new)
(figure 51)
This scenario may be of interest if you want comparable results.

Scenario IV: Solution with BW
‘Yesterday and today’ or report the comparable truth:

Given an attribute–characteristic relation.
Define the dependent attribute as a time-dependent navigational attribute of the
characteristic. Define additionally user-defined DateTo and DateFrom time-dependent
navigational attributes. Together with the query key date and a filter on DateTo and
DateFrom excluding your reporting time span, you will get the desired result.
Example for Scenario IV – Solution (fig.52):

Material group as time-dependent navigational attribute in the material master table
and additional validity attributes also defined as time-dependent navigational attributes
MatGr ‘Traditional‘ SID Table Fiter:

Fiter: Report showing comparable results
From-User = 011900 - 091998
MatGr MatGr-SID From-User = 011900 - 091998
To-User = 101998 – 129999
To-User = 101998 – 129999
X 910 X 100 100
Y 920 Query Keydate  { 09/ v 10/1998} Y 200 200
Query Keydate  { 09/ v 10/1998}
MatGr-SID From-User To-User From-Sys To-Sys Material Material-SID

910 01/1000 12/9999 01/1000 12/9999 AAA 001
910 01/1000 09/1998 01/1000 09/1998 BBB 002
Fact Table
920 10/1998 12/9999 10/1998 12/9999 BBB 002
920 01/1000 12/9999 01/1000 12/9999 CCC 003
111 09/1998 100
920 01/1000 12/9999 01/1000 12/9999 DDD 004
222 09/1998 100
920 10/1998 12/9999 10/1998 12/9999 EEE 005
333 09/1998 100
Material Time Dependent Attribute SID Table 444 09/1998 100
Material-SID Mat-DIM-ID 111 10/1998 100
001 111 222 10/1998 100
002 222 333 10/1998 100

003 333 444 10/1998 100
Material Dimension Table 004 444 555 10/1998 100
005 555
(figure 52)
 As in the ‘yesterday is today’ scenario we store all the different parent-child

constellations that have occurred over time.
 The parent attribute (material group) resides in the master table of the child characteristic
(BW Admin WB: InfoObject maintenance-> attributes).
 The key date mechanism for addressing specific master data records does not allow time
ranges.
 Furthermore the DateTo and DateFrom (To-Sys/From-Sys) attributes that are generated
automatically to handle time-dependent attributes cannot be used for-user defined
navigation or filters.
 You have to define your own DateTo and DateFrom attributes (To-User and From-User)
in the master table.

 During master data load the user DateTo value of the old master record has to be updated.
 Hint: Define time variables with intervals for DateFrom and DateTo to allow flexible
reports and analysis (BEx Query Builder).
 For example, to make a query with comparable data for the period 9/1998 to 10/1998 you
have to define the intervals as follows:
(userdefined) DateFrom: 011900 - 091998
(userdefined) DateTo: 101998 – 129999
The query key date must be in 9 or 10/1998
11. Usage of time scenarios

As shown in the previous chapter BW supports a wide range of time scenarios. Summarizing
what we learned in the previous sections we emphasize:
It is possible to incorporate each time scenario within one BW schema.
 Using different time scenarios in a schema increases the potential value of our
solution
It is understandable that the end-user may wish to have all the time scenarios in the BW
schema – just in case.
If this is so but there is no fundamental justification for this in terms of information needs,
the end-user should be warned that he will pay for it in the following ways:
He will lose the simplicity of the Multi-Dimensional Model and moreover produce extra
overheads during loading and querying:
 With each additional time scenario in a BW schema the complexity is increased and
with it, the potential of erroneous and misleading queries.
A direct consequence is:
 Additional training has to be done for ad hoc users and for query authors to explain
the differences between the time scenarios and how and in which cases to use them.
Moreover experience shows that:

 The value of the historical structure diminishes with time, especially with scenario II
 Scenarios I & III are by far the most frequently used scenarios.
If, on the other hand, the end-user has a real need to report using different time scenarios the
following rules have to be observed:

 When designing the same parent attribute as a characteristic in a dimension table

(scenario III: historical truth) and as an navigational attribute in a master data
table (all other scenarios) remember that in a BW schema the navigational attribute
should have a different name from its name in the InfoObject definition to avoid
misunderstandings.
Otherwise the same name would be repeated twice in the query builder (BW Admin WB:
InfoObject maintenance-> attributes).
Furthermore we realize that there is an impact on performance with certain time scenarios:
 Pre-calculated aggregates are not possible on the time dependent attribute level.
Introducing time dependency for an attribute where it is not strictly necessary may
render performance improvements impossible. The same is true with external
hierarchies that are structure time dependent.
12. M:N relationships

M:N relationships detected during logical modeling need special observation.
13. M:N relationships and the fact table

Normally N:M relationships between two attributes are discovered during analysis meaning
that they reside as characteristics in different dimension tables like customer and material.
The fact table resolves the M:N relationship. This kind of relationship is described by facts /
key figures like revenue.
14. M:N relationships within a dimension

N:M relationships may also occur within the same dimension like material and color or
customer and communication-possibilities.
e.g. material and color (fig.53)
Material Color
Color is an attribute of the characteristic ‘material’. A material can have multiple colors and
vice versa. According to the standard process, color should be in the master data table for
material, like material type. But this is not possible because the material is the unique key of
the master table. We cannot have one material with multiple colors in the master table. (This
is a typical challenge with Star schemasStar-VII.).
1. Designing M:N relationships using the dimension table

The BW schema allows such N:M relationships, locating the parent attribute ‘color’ as a
characteristic in the material dimension table. This is possible due to the usage of surrogate
keys (DIM IDs) in the dimension tables allowing the same material several times in the
dimension table (fig.54, p.58).

Fact table Dimension table

Dim ID SALES
Umsatz Dim ID Material* color*
1 10.000 1 A green
2 12.000 2 A red
3 25.000 3 A yellow
4 50.000 4 B blue
5 40.000 5 B green
* remember that there are only SIDs in the dim table!
(figure 54)
2. Designing M:N relationships using a compound attribute

It is possible to achieve the uniqueness of a characteristic by defining one or even multiple
attributes as a compound attribute (InfoObject mainetance – tab page compound).
Compound attributes
If you can avoid compounding - do it!
Compound attributes always mean there is an overhead with respect to:
Reporting - you will always have to qualify the compound attributes within a query
Performance
Bear in mind:
Compounding always implies a heritage of source systems and just because it makes sense
within the source systems does not necessarily mean that it will also make sense in data
warehousing.
Remember that data warehousing does not mean copy management!
3. Frequently Changing Attributes (Status Attributes)

If you find frequently changing characteristic–attribute relations in your data model then the
master data table is not normally the right place to handle these relation as:
 Defining the attribute as time-dependent would result in an explosion of the master data,
which is not efficient.
 More importantly: you normally want to report on the effects of these changes but a time-
dependent attribute only allows you to report on one constellation at a time (query
execution).
 Furthermore very often such an attribute is not only dependent on time and one other
characteristic but on a combination of characteristics.
Example: Promotion Status

The promotion status is an attribute of ‘article’. The promotion values could be TV,
newspaper, or handouts. Being the nature of status attributes, the status of an article changes
frequently. The promotion status is normally not only an attribute of article but a
combination of article and outlet: e.g. an article may be on promotion in one outlet whereas it
is not on promotion for others.

This leads to:

Frequently changing attributes (status attributes)
Frequently changing attributes like promotion status should be designed as a characteristic of
their own dimension table.
Regarding our example ‘its own dimension table’ means not putting ‘status’ into the same
dimension table as ‘article’ as this might result in an explosion of the dimension table.
Having a separate dimension table will have a positive influence on query performance as the
status is often used as a filter.
E.g. show me the revenue of articles that are on promotion in region X would not require that
the normally large article dimension table be accessed.
4. Inflation of dimensions
It might happen that your multi-dimensional model shows you a lot of ‘small’ dimensions.
‘Small’ in this regard means dimensions that will have only one or two characteristics,
whereby these characteristics have only a few values.
Bear in mind the following:
 The limitations with respect to the number of dimensions within a BW schema.
 The possible overhead produced during query execution by having to join many
dimension tables to a large fact table
A possible solution to overcome these:
Combining ‘small’ dimensions to overcome dimension inflation
The BW schema does not enforce that only related characteristics are brought into one
dimension table. This allows you create a dimension (table) collecting more or less unrelated
characteristics from ‘small’ dimensions.
You must observe that the number of expected combinations of characteristics values should
of course not be the Cartesian product!
Another aspect is usability i.e. for query authors you have to create a meaningful dimension
name (like ‘scenario dimension’), which allows him easy navigation of the model in the
query builder.
5. Multiple process reporting scenarios

A standard data warehouse issue is reporting on information offered by different operational
processes such as:
 Order process, delivery process and billing process or

 Sales process (actual) and planning or budgeting process

Let us take a look to the following example (fig.55):
Order Delivery Billing
 ONUM: Order Number (C)  ONUM: Order Number (C)  ONUM: Order Number (C)
 CUS: Customer (C)  CUS: Customer (C)  CUS: Customer (C)
 PROD: Product (C)  PROD: Product (C)  PROD: Product (C)
 ODAT: Order Date (C)  DDAT: Delivery Date (C)  BDAT: Billing Date (C)
 SALP: Sales Person (C)  DELP: Delivery Person (C)  BILP: Billing Person (C)
 OQTY: Order Quantity (K)  DQTY: Delivered Quantity (K)  BQTY: Billing Quantity (K)
 OPRI: Order Price (K)  DPRI: Delivery Price (K)  BPRI: Billing Price (K)
(figure 55)
The three scenarios have the marked characteristics in common.
The question is whether there are general rules on how to implement reporting scenarios in
BW that consist of sub-scenarios.
6. MultiCubes
Looking at the example introduced above you might come to the conclusion that as you
frequently want to report data from these processes together, the first step might be to create
one common multi-dimensional model and subsequently one Infocube.
Creating a solution using one InfoCube without any further schema improvements we would
achieve (fig.56):
O r d e r - D e liv e r y - B illin g C u b e
ONUM CUS PROD ODAT SALP DDAT DELP BDAT B IL P OQTY OPRI DQTY DPRI BQTY BPRI
1 C1 P1 1998 S1 * * * * 5 100 0 0 0 0
2 C2 P1 1998 S2 * * * * 10 200 0 0 0 0
3 C1 P2 1997 S3 * * * * 4 130 0 0 0 0
4 C2 P2 1997 S2 * * * * 8 150 0 0 0 0
4 C2 P2 1998 S2 * * * * -2 -4 0 0 0 0 0
1 C1 P1 * * 1 99 8 D2 * * 0 0 5 1 00 0 0
2 C2 P1 * * 1 99 9 D1 * * 0 0 7 1 20 0 0
2 C2 P1 * * 1 99 9 D2 * * 0 0 3 80 0 0
3 C1 P2 * * 1 99 8 D1 * * 0 0 2 60 0 0
4 C2 P2 * * 1 99 8 D2 * * 0 0 6 1 10 0 0
1 C1 P1 * * * * 1 99 9 B1 0 0 0 0 5 1 00
2 C2 P1 * * * * 1 99 9 B1 0 0 0 0 10 2 00
3 C1 P2 * * * * 1 99 8 B2 0 0 0 0 4 1 30
Com m on S a le s D e liv e r y B illin g S a le s D e liv e r y B illin g

C h a rs C h ars C h a rs C h a rs K e yfs K e y fs K e y fs
(figure 56)

The cube looks like a Swiss cheese.

Of course it is possible to design a more appropriate schema for the single cube approach.
This is discussed in the next chapter.
Using the BW MultiCube functionality we can use a space-saving, better performing and
more transparent approach.
A MultiCube is a virtual cube that does not exist physically (for more details consult the BW
AWB Documentation):
SAP defines three Basic InfoCubes, which serve as the input for the MultiCube definition.
The following has to be observed:
 Only characteristics and navigational attributes that reference the same InfoObject can be
declared to be the same.
 If the same InfoObject of type key figure occurs multiple times you have to decide
whether to add the values from the different cubes or choose one key figure from one
cube. In some scenarios the first option makes sense (for example: MultiCube of country-
specific basic cubes with revenue data) with other scenarios (example: actual and plan)
this would be nonsensical.
 The best way to handle key figures is to use a key figure InfoObject not in different
semantic constellations such as key figure QTY for ordered quantity in the order cube
and for invoiced quantity in the invoiced cube as this allows you to access multiple
InfoCubes within one query.
With this background we can create three Infocubes (fig.57):
O N U M C U S P R O D O D A T S A LP O Q TY O P R I
O rd e r-C u b e
1 C 1 P 1 1 9 9 8 S 1 5 100
2 C 2 P 1 1 9 9 8 S 2 10 200
3 C 1 P 2 1 9 9 7 S 3 4 130
4 C 2 P 2 1 9 9 7 S 2 8 150
4 C 2 P 2 1 9 9 8 S 2 -2 -4 0
O N U M C U S P R O D D D A T D E LP D Q TY D P R I
D e liv e r y - C u b e 1 C 1 P 1 1 9 9 8 D 2 5 100
2 C 2 P 1 1 9 9 9 D 1 7 120
2 C 2 P 1 1 9 9 9 D 2 3 80
3 C 1 P 2 1 9 9 8 D 1 2 60
4 C 2 P 2 1 9 9 8 D 2 6 110
O N U M C U S P R O D B D A T B IL P B Q TY B P R I
B illin g - C u b e 1 C 1 P 1 1999 B 1 5 100
2 C 2 P 1 1999 B 1 10 200
3 C 1 P 2 1998 B 2 4 130
(figure 57)
… and based on these Basic InfoCubes a MultiCube, a query showing sales and delivered
quantity, would look like this (fig.58):

PROD SQTY DQTY

P1 15 15
P2 10 8
(figure 58)
Drilling down to salesperson will show the following results (fig.59):
PROD SALP SQTY DQTY

P1 S1 5
S2 10
unassigned 15
15 15
P2 S2 6
S3 4
unassigned 8
10 8
(figure 59)
Two queries are sent in parallel to the order and delivery cube. The subsequent union creates
the result table (fig.60).
Multi-Cube Queries
Sales
Delivery
Billing
Basic-Cube Queries Multi-Cube Basic-Cube Queries
Sales Billing
Cube Cube
Delivery
Cube
Basic-Cube Queries

15. Partitioning Attributes

In the modeling phase it often happens that there are dozens of key figures (facts) such as:
Actual Sales / Planned Sales / Forecast Sales / Budget Sales / Planned Units / Forecast Units
Furthermore actual and plan key figures are normally defined on different granular levels
like:
 Actual data on product and daily level
 Plan data on product group and monthly level
Question:
 Shall I introduce all these key figures into the fact table of a single InfoCube?
Answer:
 Bearing in mind what we discussed with respect to MultiCube scenarios it does not make
sense to create n-cubes, one for each scenario.
 It makes sense to think of two basic reporting scenarios and to create two cubes one for
actual sales and one for planning, forecasts and budgets.
 This also takes into account the different granularity levels in the scenarios.
Question:
 What will happen if the users want to introduce a 3-month forecast, a 6-month forecast?
Answer:
 Think of plan, budget and forecast as values of a characteristic named, for example,
‘value type’ and located in a separate dimension (table) named, for example, ‘scenario’.
‘Value type’ replicates the remaining structure of the schema. We will then have only one
key figure, e.g. sales amount, which only becomes meaningful in conjunction with the
characteristic ‘value type’. These attributes are often called partitioning attributes and
their dimensions a partitioning dimension.
 The structure is flexible and expandable so if, for instance, another scenario like a 3-
month forecast is needed this will simply be created as a new ValType value.
Example (fig.61):
CUS PROD DAT ValType QTY
C1 P1 199801 P 10
C2 P1 199801 P 10
C1 P2 199801 P 4
C2 P2 199801 P 8
C1 P1 199801 F6 80
C2 P1 199801 F6 70
C1 P2 199801 F6 30
C2 P2 199801 F6 60
(figure 61)
 It is important to remember that reporting the sales amount here is not meaningful
without specifying the ValType (as a filter, in a restricted key figure). For example, you
would summarize plan data and forecast data.

Enforcing the existance of a partition attribute

Characteristics that partition the schema like ValType have to be in every query and every
pre-calculated aggregate!
This can be enforced by defining ValType as ‘unique for each cell’ in InfoObject
maintenance (tab page, Explorer).
Further advantages of partitioning attributes:
 External hierarchies can be defined over the partitioning characteristic
 BW staging supports this feature as the update rules are defined for every key figure from
the communication structure of the InfoSource, enabling one large transactional record
with many key figures to be split into many records in the fact table with one key figure.
Thus incorporating both features (the MultiCube and a partitioning attribute) provides
successful implementation (fig.62):
Multi-Cube Queries
Plan /Actual
Multi-Cube
Basic-Cube Queries Basic-Cube Queries
Plan,
Forecast.. Actual Data
Data Cube
Cube
(figure 62)
1. Attribute or fact (key figure)

Usually it is quite obvious how to distinguish attributes and facts. But there will be some
attributes that will be confusing. Prices are a good example. On one hand, price describes the
article (as for example the manufacturer attribute does), and it therefore may seem to belong
in the master data table
InfoObjects of type key figure as attributes in a master data table

Introducing a formular variable that addresses an attribute of type key figure like ‘price’ in a
master data table allows calculations within queries using this formular variable (see
Documentation)

Sometimes key figure attributes must be integrated into the fact table
On the other hand, price is continuous over time and that means that it does not make sense
to calculate discounts on the basis of sales amount and quantity in a fact record using the
actual price from the master data table as described above with fact records which are for
example one year old.
In this case the discount has to be calculated during load time in an update rule addressing
the actual price via lookup to the master data table.
In terms of reporting, it can also be of interest to store attribute key figures additionally as a
characteristic or an attribute of type characteristic.
6. This would allow navigation on prices using external hierarchies.
7. Same characteristic several times in the model:

It may happen that you find the same characteristic several times in your BW schema but
playing a different role.
Example:
Sales Employee, Delivery Employee, Billing Employee
Create one InfoObject ‘employee’. Create other characteristics as InfoObjects that refer to
‘employee’.
It makes often sense to add ‘employee’ to the schema separately to facilitate simple questions
like “show me all transactions where a specific employee was involved in no matter what
role”.
8. Artificial key figures
1. Factless fact tables

There might be a fact table without a “true” fact, e.g. with attendance questions (attendance
intersection entity). The same applies to human resource statistics.
Those situations could be solved introducing an artificial key figure, always ‘1’ (fig.63):
Month Course Student Attendance
199905 TABW10 Haupt 1
199905 TABW10 Brugna 1
(figure 63)
2. Counting
Often it makes sense to add separately an artificial key figure to allow easy counting. ‘1’
represents this key figure during the load for each record.
9. Big dimensions
During modeling the question of how to deal with dimension and master tables with
hundreds of thousands or even millions of records may be raised.
=Use line item dimensions
This situation often occurs with larger customer dimensions. In brief one solution may be to:

 Use aggregates for demographic characteristics in the customer dimension,

 this improves query performance significantly
 but quite possibly requires a large amount of space
 and aggregates have to be maintained after data load and this may take some time
so, in extreme circumstances it makes sense to think about alternatives :
 Create a smaller demographic dimension using the demographic attributes of the
customer
 this improves query performance significantly
 data is available immediately after the transaction data load
 but there is a certain overhead during load time
The two approaches can be combined:
As the BW schema does not enforce that you put a parent attribute into the same dimension
table as its child attribute, it is often worth thinking about locating parent attributes in their
own dimension table (e.g. with 100, 000 article and 2,000 article groups why not put the
article group in its own dimension table if queries are often reported at article group level?)
1. Hierarchies in the BW schema

Hierarchies in general are essential structures for navigation. Having characteristics and
attributes in the dimension and master data tables that are related in a sequence of parent-
child relationships, obviously involves hierarchies. But as the real world is sometimes
irregular, so are hierarchies. In BW there are essentially three possibilities for modeling
hierarchies:
 as a hierarchy of characteristics within a dimension table
 as a hierarchy of attributes attached to a characteristic
 as an external hierarchy1
Let us look quickly at the pros and cons of those different modeling techniques.
2. Hierarchies within a Dimension

A typical example of a hierarchy of this type is a time hierarchy with levels such as
millenium – century – decade – year – month – day – hour etc. Another typical example is a
geographic hierarchy with levels such as continent – country – state – region – city etc.
Hierarchies that can be modeled within a dimension table have certain properties:
 The number of levels should be fixed i.e. each path from the root to a leaf should have the
same length. Each level is represented by an InfoObject, e.g. a geographic dimension
with InfoObjects 0COUNTRY (country), 0REGION (region) and 0CITY (city).
 As BW does not know anything about parent-child relationships within dimension tables
it is sometimes sensible to design even irregular hierarchies in a dimension table if the
end-user knows about its irregular behavior and can choose a meaningful child attribute.
Note: There are no pre-defined drill down paths within a dimension table. (As Kimball
says, the true meaning of drilling is just adding or removing row headers).
 Due to the fact that surrogate keys are used in the dimension tables it is possible to design
even ‘leafless’ hierarchies. This situation often arises when different OLTP source
systems offer data at different attribute (Hierarchy) levels (fig.64):
1
This is the notion of a hierarchy as it is used in documents related to BW.

Fact table Dimension table

Dim ID SALES
Umsatz Dim ID Material* Materialgroup*
1 10.000 1 A beverage
2 12.000 2 B sweets
3 25.000 3 C beverage
4 50.000 4 '_' beverage
5 40.000 5 '_' sweets
* remember that there are only SIDs in the dim table !
(figure 64)
Performance aspects:
 Queries to InfoCubes that use hierarchies of this kind are generally faster than the same
queries to InfoCubes that model the same scenario with one of the two other hierarchy
modeling techniques.
 BW does not automatically know about any hierarchical dependencies. Therefore pre-
calculated aggregates that summarize data over ‘regions’ are not used for queries that
summarize over ‘countries’ if the country is not included in that pre-calculated
aggregate as well. You should, therefore, always include hierarchical levels to an
aggregate that is above the level over which data is summarized.
Example 1: If an aggregate summarizes data over 0REGION then do include
0COUNTRY in that aggregate too.
Example 2: If an aggregate summarizes data over months then do include years, decades,
etc. too.
The reporting aspects of this technique are:
 BW does not explicitly know about the hierarchical dependencies. Therefore there is no
predefined drill down path with this hierarchy design.
3. Hierarchies within a master data table of a characteristic

This case is very similar to the one discussed in section before 2. The difference is the
increased flexibility (i.e. realignment facilities) that comes with navigational attributes. The
hierarchy should still have a fixed number of levels. However, changes to that hierarchy (i.e.
changes to attribute values) can be easily applied to facts that are already loaded into a cube.
A typical example is the hierarchy of sales office – sales group – sales person. This hierarchy
has a fixed number of levels but is frequently reorganized.
In terms of performance, this is the least attractive of the hierarchy modeling techniques.
4. External Hierarchies
This is the ideal type if a hierarchy (fig.65)
 frequently changes
 has no fixed number of levels (sometimes referred to as a "ragged" or “unbalanced”
hierarchy).

unbalanced hierarchy
(figure 65)
A typical example is a cost center hierarchy in which several (sub-) cost centers belong to
one cost center which itself belong to another cost center and so on. Such a hierarchy has no
fixed number of levels as cost centers usually correspond to departments or groups within a
company, which might be reorganized into new subgroups. Thus new levels might be
introduced, old ones disappear. The hierarchy might be deeper at one end (due to a deeper
hierarchical organization) and shallower at the other.
Another major advantage of external hierarchies in comparison to their alternatives is that an
InfoObject can have several such hierarchies and all these can be used within the same cube.
With the alternative approaches the same effect could only be achieved through difficult
work-arounds.
Performance issues connected to this type of hierarchy are as follows:
 These hierarchies do not usually perform as well as those modeled within dimensions.
 They usually perform at least as well as the hierarchies based on navigational attributes.
 Problems can arise for large external hierarchies with many thousands of nodes and
leaves. In that case it might be better to consider one of the two alternatives.
 Types of external Hierarchies:
 Versions and/or time dependency of the whole external hierarchy structure (DateTo,
DateFrom) - there are pre-calculated aggregates at each level even for specific node
values possible
 Or (exclusive) time dependency for each external hierarchy node (time-dependent
structure) - there are no pre-calculated aggregates possible.

BW Multi Dimensional Modeling

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BW Multi Dimensional Modeling

Încărcat de

Drepturi de autor:

Formate disponibile

Multi-Dimensional Modeling

A background to the techniques used to

2000 SAP AG AND SAP AMERICA, INC. TABLE OF CONTENTS

4.4 FACT TABLE....................................................................................................................................36

2000 SAP AG AND SAP AMERICA, INC. TABLE OF CONTENTS

1. Software Version Supported

 2000 SAP AG AND SAP AMERICA, INC. 1

BW Information Integration Architecture

SAP PSA InfoCubes

External BW Operational Data Store

2000 SAP AG AND SAP AMERICA, INC. 2

BW Information Access Architecture

SAP PSA InfoCubes

BW Operational Data Store Third Party Tools

Sales Organisation Product Organisation Time KPIs

A multi-step multi-dimensional analysis will look like this:

Analytical processing of this type is normally done using InfoCubes.

ODS Object should not be misused for multi-dimensional analysis.

2000 SAP AG AND SAP AMERICA, INC. 3

2000 SAP AG AND SAP AMERICA, INC. 4

 From Multi-Dimensional Model to InfoCube – Step

1. The goals of multi-dimensional data models

3. The role of BW Business Content

If, however, an InfoCube is to be created based partly or entirely on non-R/3 applications

2000 SAP AG AND SAP AMERICA, INC. 5

4. Basic Modeling Steps

 Focus on the structure of information  Focus on analytical needs -

2000 SAP AG AND SAP AMERICA, INC. 6

1. Step 1: Develop a complete understanding of the underlying business

1. Entities and the relations between them

Customer Material Sales Person

Customer Material Sales Person

Ask the end-user how performance is measured.

2000 SAP AG AND SAP AMERICA, INC. 7

Material group Sales Department

Customer Material Sales Person

2000 SAP AG AND SAP AMERICA, INC. 8

Material group Sales Department

Region Sales Dept. Loc.

City Color Material Type Sales Dept.

Customer Material Sales Person

2. Reaping benefits of BW’s Business Content

2000 SAP AG AND SAP AMERICA, INC. 9

3. Step 2: Create a valid Schema

 Focus on analytical needs -

4. The Multi-Dimensional Model (MDM)

5. The Star Schema

2000 SAP AG AND SAP AMERICA, INC. 10

The key elements of a Star schema are:

The Fact Table (fig.12):

2000 SAP AG AND SAP AMERICA, INC. 11

City Color Material Type Sales Dept.

Customer Material Sales Person

Sales Rep ID Material ID

LastName Material Name

2000 SAP AG AND SAP AMERICA, INC. 12

General Mapping Guidelines

6. Step 3: Create an InfoCube Description

2000 SAP AG AND SAP AMERICA, INC. 13

Translate the MDM/ Star Schema into an InfoCube Description:

Sales Rep ID Material ID

LastName Material Name

2000 SAP AG AND SAP AMERICA, INC. 14