Professional Documents
Culture Documents
Multi-Dimensional Modeling With BW
Multi-Dimensional Modeling With BW
Multi-Dimensional Modeling With BW
with BW
ASAP FOR BW ACCELERATOR
BUSINESS INFORMATION WAREHOUSE
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.
Table of Contents
MULTI-DIMENSIONAL MODELING WITH BW....................................................................................1
ASAP FOR BW ACCELERATOR....................................................................................................................1
TABLE OF CONTENTS................................................................................................................................2
1
INTRODUCTION...................................................................................................................................1
1.1
1.2
1.3
2.4.2
2.4.2.1
2.4.2.2
2.4.3
Step 3 : Create an InfoCube Description................................................................................13
2.5
RESUME...........................................................................................................................................14
3
4.3.2
4.3.3
4.3.3.1
4.3.3.2
4.3.3.3
4.3.4
4.3.4.1
4.3.4.2
4.3.4.3
4.3.4.4
4.3.5
Text Tables...............................................................................................................................26
SID Tables...............................................................................................................................26
InfoObject Definition and SID Tables..............................................................................................26
SID Tables Mainetance.....................................................................................................................28
InfoCube Access and SID Tables......................................................................................................28
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
TABLE OF CONTENTS
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
5.4.2.2
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
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
PSA
BW ODS
InfoCubes
End-User
Data Access
Meta Data
Business Rules
Legacy
Extraction
ETL Tools
InfoCubes
PSA
Business Rules
SAP
R/3
APO
CRM
BBP
Ad Hoc
Queries
Reporting
Applications
Models
Integration
Granularity
External
Provider
Master Data
Scheduling
Monitoring
Change
Management
Service
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.
PSA
BW ODS
InfoCubes
End-User
Data Access
Meta Data
SAP
R/3
APO
CRM
BBP
InfoCubes
PSA
BW
Business Explorer
Web
Graphical User Interf
ETL Tools
SAP-Models
Legacy
Advanced Planning
Enterprise Mangem
CRM
External
Provider
(ODBC/ ODBO)
Master Data
Scheduling
Monitoring
Change
Management
Service
Management
(figure 02)
A simple example:
Sales Organisation
Sales Department
Sales Person
Product Organisation
Material Group
Material Type
Material
Time
Year
Month
Day
KPIs
Sales Amount
Sales Quantity
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.
Sales Rep ID
LastName
SalesDep
Sales Org Dimension
Customer ID
Customer Name
City
Region
Office Name
SalesRep ID
Last Name
...
OrgStr. DIM ID
SalesRep
SalesDep
SalesDep ID
Material ID
Material Name
Material Type
Material Group
Material Dimension
Material ID
Sales Rep ID
Time Code ID
Customer ID
Sales Amount
Quantity
Unit Price
FACT
Material ID
DIM ID
Customer Material
Dimension
Mat.description
Material ID
MatType
MatType
...
Time Code ID
Year
Fiscal Year
Quater
Mounth
Day of the Week
Time Dimension
Address
...
SAP BW
(figure 03)
Material DIM ID
OrgStr DIM ID
Time Code ID
....
Quantity
.....
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-users information needs:
Material
Customer
Sales Person
The nouns are basic business terms and are usually called Strong Entities (see fig.04):
Customer
Material
Sales Person
(figure 04)
Ask the end-user about the relationship between his basic business terms (strong entities).
Normally the relationship between strong entities are N:M Relationships i.e. a customer can
purchase multiple materials and materials can be purchased by multiple customers (see
fig.05):
Customer
Material
(figure 05)
Sales Person
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
Customer
Material
Sales Department
Sales Person
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).
Customer
Customer no
Customer name
City
Region
Material
Material no
Material name
Material type
color
price
Sales Department
Sales dep. no
Sales dep. location
.......
Sales Person
Sales pers. no
Sales pers. name
.......
Sales Transaction
Date
Customer no
Material no
Sales pers no
Amount
Quantity
Currency
(figure 08)
Material Group
Sales Dept. Loc.
Region
City
Color
Material Type
Material
Customer
Sales Dept.
Sales Person
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 BWs 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.
Step 2: Create a valid Schema
This crucial step aims to overcome model complexity by focusing on analytical needs (see
fig.10).
3.
Sales Rep ID
LastName
SalesDep
Customer ID
Customer Name
City
Region
Office Name
Material ID
Material Name
Material Type
Material Group
Material Dimension
Material ID
Sales Rep ID
Time Code ID
Customer ID
Sales Amount
Quantity
Unit Price
FACT
Time Code ID
Year
Fiscal Year
Quater
Mounth
Day of the Week
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 multidimensional 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
Material Type
Material Group
LastName
SalesDep
Sales Org
Dimension
(Table)
Customer ID
Customer Name
City
Region
Office Name
Material ID
Sales Rep ID
Time Code ID
Customer ID
Sales Amount
Quantity
FACT (Table)
Customer
Dimension
(Table)
Material
Dimension
(Table)
Time Code ID
Year
Fiscal Year
Quater
Mounth
Day of the Week
Time
Dimension
(Table)
(figure 11)
Ides Gmbh
Street
SalesPers
SalesRegion
Material
Meier
Unit
Date
Date
Monitor
Meier
Monitor
981118
981118
Amount Quantity
1000
(figure 12)
The basic process of mapping an ERM to the MDM/ Star schema is shown on the following
graphic (fig.13):
Material Group
Sales Dept. Loc.
Region
City
Color
Material Type
Sales Person
Material
Customer
Sales Dept.
Price
Sales order
Sales Rep ID
Material ID
LastName
SalesDep
Material Name
Material Type
Material Group
Customer ID
Customer Name
City
Region
Office Name
Material ID
Sales Rep ID
Time Code ID
Customer ID
Sales Amount
Quantity
Unit Price
FACT
Material Dimension
Time Code ID
Year
Fiscal Year
Quater
Mounth
Day of the Week
Customer Dimension
Time Dimension
(figure 13)
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.
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):
6.
Sales Rep ID
Material ID
LastName
SalesDep
Material Name
Material Type
Material Group
Customer ID
Customer Name
City
Region
Office Name
Material Dimension
Material ID
Sales Rep ID
Time Code ID
Customer ID
Sales Amount
Quantity
Unit Price
FACT
Customer Dimension
Time Code ID
Year
Fiscal Year
Quater
SalesRep ID Mounth
Day of the Week
Last Name
OrgStr. DIM ID
...
Time Dimension
SalesRep
SalesDep
SalesDep ID
SAP BW
Material DIM ID
Material ID
Material ID
MatType
Mat.description
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.
2.
3.
4.
5.
6.
7.
8.
9.
The processes, and hence the identity of the fact tables ([one fact table - one
InfoCube] -> intersection entities)
The dimensions of each fact table (-> strong entities)
The dimension attributes with complete descriptions and proper terminology (->
attributes and entities)
The grain of each fact table
The facts, including pre-calculated facts
How to track slowly changing dimensions
The aggregations, heterogeneous dimensions, mini-dimensions, query modes and other
physical storage decisions
The historical duration of the database (archiving aspects)
The urgency with which the data is extracted and loaded into the data warehouse (time
frame for loading)
Star Schema
Material ID
Sales Rep ID
Material Name
Material Type
Material Group
LastName
SalesDep
Sales Org
Dimension
(Table)
Customer ID
Customer Name
City
Region
Office Name
Material ID
Sales Rep ID
Time Code ID
Customer ID
Sales Amount
Quantity
FACT (Table)
Customer
Dimension
(Table)
Material
Dimension
(Table)
Time Code ID
Year
Fiscal Year
Quater
Mounth
Day of the Week
Time
Dimension
(Table)
(figure 15)
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.
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
Materialgroup
Materialgroup Material
Material
XX
AAA
AAA
XX
BBB
BBB
YY
YY
CCC
CCC
DDD
DDD
Day
Month
Day
Month Year
Year
19980901
.....................
19980901 .....................
4712...........................
4712...........................
19980902
19980902 .....................
.....................
Material Customer
Material Customer
AAA
AAA
BBB
BBB
CCC
CCC
DDD
DDD
BBB
BBB
Customer
Customer Custgroup
Custgroup
4711...........................
4711...........................
Day
Day
4711
4711 19980901
19980901
4712
4712 19980901
19980901
4712
4712 19980901
19980901
4712
4712 19980901
19980901
4711
19980902
4711 19980902
Fact Table
Revenue
Revenue
100
100
100
100
100
100
100
100
100
100
100
Transaction record
Star-II.
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.
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).
SalesOrg
Dimension
SalesRep Master Table
Material
Dimension
SalesRep Number
SalesRep Number
Sales DEP
SalesRep Text Table
SalesRep Number
SalesRep Number
Language Code
Language Code
SalesRep Name
SalesOrg_Dimension_ID
Material_Dimension_ID
Material Number
InfoCube
Material_Dimension_ID
SalesOrg_Dimension_ID
Time_Dimension_ID
Customer_Dimension_ID
R e g io n 2
R e g io n 3
Material
B e z ir k 2
B e z Group
ir k 3
B e z ir k 4
B e z irk 1
Sales Amount
Quantity
Customer Number
Customer Number
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
B e z ir k 5
G e b ie t 7
G e b ie t 8
City
Region
Customer Text Table
Customer Number
Customer Number
Language Code
Language Code
Customer Name
Customer_Dimension_ID
Customer Number
Customer Dimension Table
Customer Dimension
FACT Table
Time_Dimension_ID
Year
Quater
Mounth
Day
Time Dimension Table
Time Dimension
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.
Important
(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
SID Tables
Hierarchies
Master
Text
Master
Text
SID Tables
Hierarchies
SID Tables
Hierarchies
Master
Text
SID Tables
Hierarchies
Dimension
Table
Master
SID Tables
Text
Hierarchies
SID Tables
Hierarchies
Master
Text
Dimension
Table
FACT
Dimension
Table
SID Tables
Hierarchies
Master
Text
Dimension
Table
Hierarchies
Master
Text
Hierarchies
Master
Text
SID Tables
Hierarchies
Master
Text
Dimension
Table
SID Tables
SID Tables
SID Tables
Hierarchies
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):
Material
Dimension
Material_Dimension_ID
Material Number
Material Number
Material Number
Language Code
Language Code
Material Name
R e g io n 2
R e g io n 3
Material
B e z ir k 2
B e z Group
irk 3
B e z irk 4
B e z irk 1
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
B e z irk 5
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
Materialgroup
As a Navigational /
Display Attribute ?
As a Hierarchy
Material
Hierarchy table
As the graphic shows, the material-material group relation can be designed defining material
group
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.
100
BBB
200
CCC
100
DDD
100
Material DateFrom
AAA
01 /1000
BBB
DateTo
MatGroup
X
01 /1000
12 / 1999
99
09 /1998
BBB
10 /1998
12 /9999
CCC
01 /1000
12 /9999
DDD
01 /1000
12/9999
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 nontime 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
dependent attributes.
The time dependent attribute SID table of a characteristic for access via time
dependent attributes.
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:
DateFrom
DateTo
AAA
01 / 1000
12 /9999
BBB
01 / 1000
09 /1998
BBB
10 / 1998
12 /9999
CCC
01 / 1000
12 /9999
DDD
01 / 1000
12/9999
: /BIC/QMaterial (fig.25)
MatGroup
: /BIC/SMaterial (fig.26)
Material-SID Material
001
AAA
002
BBB
003
CCC
004
DDD
AAA
MatType-SID
22222
002
BBB
33333
003
CCC
22222
004
DDD
22222
: /BIC/XMaterial (fig.27)
Material
MaterialMaster
Mastertable
table
(Name: /BIC/PMATERIAL)
(Name: /BIC/PMATERIAL)
Material MatGroup
AAA
CCC
DDD
X
Y
Y
X
Y
Z
111
222
333
Dim ID
Dim ID
Sales
1
2
3
10.000
12.000
25.000
1
2
3
SID Material
MatGroup
MatGroupSID
SIDtable
table
(Name:
(Name:/BIC/SMATGROUP)
/BIC/SMATGROUP)
SID MatGroup
345
678
678
Material
MaterialNon-time
not time dependent
Attributes
ddependantdepend
SID
Attributes
SIDtable
table
(Name:
ent
(Name:/BIC/XMATERIAL)
/BIC/XMATERIAL)
111
222
333
Dimension table
Fact table
AAA
CCC
DDD
345
678
999
(figure 29)
The result set for the material groups is then determined in two steps:
We can summarize that in accessing an InfoCube no real value master data tables are used.
The following graphic illustrates this (fig.30):
2
5
(1) Fact Table
(2) Dimension Tables
(3) time-independent-SI D
(4) time-dependent-SID
time-dependent-SI D
(5) traditional SID
5
5
2
3
5
3
5
5
(figure 30)
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.
2. 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.
3. 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
1. 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.
2. 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
4
5
-1
Germany
Austria
Switzerland
America
1
2
USA
Canada
6*
Japan
(figure 31)
SID Table:
Country
Country
Japan
Germany
Austria
Switz.
USA
Canada
SID
6
3
4
5
1
2
Child Parent
Text &
Rep. Attributes
-2
-1
6
3
4
5
1
2
-3
-3
-3
-2
-2
-2
-1
-1
Nodes
Text &
Rep. Attributes
SID
America
-1
Europe
-2
World
-3
Fact
Table
DIM-ID
Cust-SID
Country-SID
11
22
33
44
55
66
77
1711
1712
2711
3711
4711
5711
6711
1
1
2
3
4
5
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.
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
22
33
44
55
66
77
1711
1712
2711
3711
4711
5711
6711
1
1
2
3
4
5
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
Dimension
5
3
(figure 34)
5
5
5
5
5
2
3
2. 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).
Multiple
Fact Tables
3
5
5
4
5
5
(F)
F-Fact
Table
Requid
(F) F-Fact
Table
Request
>0
> 0E-Fact Table Request = 0
(E)
(E) E-Fact Table Requid
=0
(2) Dimension
Tables
(3) time-independent(4)
SI Dtime-dependent(5)SI
traditional
D
(figure
SI D 35)
2
3
5
5
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 Fto 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
Time
Dimensio
n
5
Partitioning
Fact Tables
3
5
5
4
5
5
5
(F)
Table
Request
>
(F)F-Fact
F-Fact
Table
Requid
0
> 0E-Fact Table Request =
(E)
(E) E-Fact Table Requid
0
=0
(2) Dimension
Tables
(3) time-independent(4)
SI Dtime-dependent(5)SI
traditional
D
SI D
(figure 36)
5
3
Packe
Dimensio
t
3n
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
The following picture shows differences in the terminology (fig.37):
3.
Key Figure
Fact Table
Fact Table
(Dimension) Attribute
Dimension (Table)
(figure 37)
BW Schema
Characteristic /
Navigational Attribute/
Display Attribute /
(external) Hierarchy
Node
Dimension Table /
Master Table /
Text Table /
External Hierarchy
Table /
(SID Table)
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
Performance
Aspects
(figure 38)
Global
Data Warehouse
Design Aspects
3. 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.
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.
4.
Material
As a Characteristic ?
Material
Master table
Materialgroup
As a Navigational /
Display Attribute ?
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.
Materialgroup SID
Mat Mat-SID
AAA
001
BBB
002
CCC
003
Mat-GR-SID
Mat-GR-SIDMat-SID
Mat-SID Mat-DIM-ID
Mat-DIM-ID
910
001
111
910
001
111
DDD
004
EEE
005
Material SID
910
910
920
920
002
002
002
002
222
222
666
666
920
920
920
920
003
003
004
004
333
333
444
444
920
920
005
005
555
555
Mat-GR Mat-GR-SID
X
910
920
Add new record to dim table
Transaction record
EEE
Fact Table
Mat-DIM-ID
Mat-DIM-IDTime-DIM-ID
Time-DIM-ID Revenue
Revenue
111
111
09/1998
09/1998
222
333
333
444
444
09/1998
09/1998
09/1998
09/1998
09/1998
111
111
222
222
10/1998
10/1998
10/1998
10/1998
100
100
100
100
333
333
444
444
10/1998
10/1998
10/1998
10/1998
100
100
100
100
555
10/1998
1998
10/
555
10/1998
Add new record
to fact table
100
100
Fact
222 Table
09/1998
10/1998
100
100
100
100
100
100
100
100
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
BBB
CCC
DDD
Material Date
Constellation 10/1998:
Material
Fact Table
Material group
Revenue
AAA
09/1998
100
BBB
09/1998
100
CCC
09/1998
100
DDD
09/1998
100
AAA
10/1998
100
10/1998
100
AAA
BBB
BBB
Y (changed)
CCC
10/1998
100
CCC
DDD
10/1998
100
DDD
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 todays constellation
Material group Rev 09/98 Rev 10/98
X
100
100
300
400
200
200
200
200
200
100
200
400
100
100
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 todays constellation
-Today is yesterdayScenario II: Report the data to yesterdays constellation as well
-Yesterday is todayScenario III: Report the data to the respective constellation
-Today or yesterdayScenario IV: Report only on data for constellations valid today and yesterday
-Today and yesterday1. Scenario I: Report the data to todays constellation - today is
yesterday
1. Scenario I: Description
Today is yesterday or todays constellation is the truth:
Report all fact data according to todays 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:
Material
Material group
Fact Table
Material Date
Reporting demands:
Revenue
AAA
AAA
09/1998
100
BBB
BBB
09/1998
100
CCC
CCC
09 / 1998
100
DDD
DDD
09/1998
100
AAA
10 / 1998
100
BBB
10 / 1998
100
Constellation 10/98:
Material
Material group
AAA
CCC
10 / 1998
100
BBB
Y ( changed )
DDD
10 / 1998
100
CCC
EEE
10 / 1998
100
DDD
EEE
Y ( new )
(figure 43)
Rev 09 /98
100
300
Rev 10/ 98
100
400
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 todays 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 MatGrMatGr Traditional SID
r X SID
Table
Y 910920
MatGr-SID
Material
910
(figure 44)
100
300
100
400
MaterialSID
AAA
001
920
BBB
002
920
CCC
003
920
DDD
004
920
EEE
005
Material Attribute SID
Table
Material-DIMSID
Mat ID
001
MateriaDimension
l
Table
Rev 10/98
111
002
222
003
333
004
444
005
555
Fact
Table
Mat-DIM-ID
Date
111
222
333
444
111
10/222
10/333
10/444
10/555
10/
09/199Revenue
09/8
199 100
8 100
09/199
8 100
09/199
8 100
199
8 100
199
8 100
199
8
199 100
8
199 100
8 100
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 todays 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
Material Material-SID
AAA
001
BBB
002
CCC
003
DDD
004
EEE
005
+
+
100
100
300
400
Fact Table
Mat-DIM-ID Date Revenue
-3
(Y)
001
002 003 004 005
(AAA) (BBB) (CCC) (DDD) (EEE)
111
9/1998
100
222
9/1998
100
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.
Important
If all dependent attributes of a characteristic are navigational or display attributes in the
characteristics 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 yesterdays constellation as well -yesterday is today
1. Scenario II : Description
Yesterday is today or yesterdays constellation is the truth:
Allow to report the fact not only to todays but also according to yesterdays constellation of
characteristics and attribute value assignments.
Material group
Fact Table
Material Date
Reporting demands:
Revenue
AAA
AAA
09/1998
100
BBB
BBB
09/1998
100
CCC
CCC
09/1998
100
DDD
DDD
09/1998
100
Constellation 10/98:
Material
Material group
AAA
10/1998
Rev 10/98
100
200
200
200
200
BBB
10/1998
100
AAA
CCC
10/1998
100
BBB
Y (changed)
DDD
10/1998
100
CCC
EEE
10/1998
100
DDD
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 todays 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 yesterdays master data.
Scenario II: Solutions with BW
1st Solution :
Today is yesterday or todays 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
MatGr MatGr-SID
X
910
920
MatGr-SID DateFr
01/1000 12/9999
AAA
001
910
01/1000 09/1998
BBB
002
920
10/1998 12/9999
BBB
002
920
01/1000 12/9999
CCC
003
920
01/1000 12/9999
DDD
004
920
10/1998 12/9999
EEE
005
200
200
200
100
Fact Table
Mat-DIM-ID Date
200
not assigned
910
Rev 10/98
001
111
002
222
003
333
004
444
005
555
Revenue
111
09/1998
100
222
09/1998
100
333
09/1998
100
444
09/1998
100
111
10/1998
100
222
10/1998
100
333
10/1998
100
444
10/1998
100
555
10/1998
100
(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 todays 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
002
(BBB)
-1
(All)
-3
(Y)
003 004
(CCC) (DDD)
-2
(X)
-3
(Y)
+
+
200
200
not assigned
001
002 003 004 005
(AAA) (BBB) (CCC) (DDD) (EEE)
200
200
100
Fact table
Mat-DIM-ID
Mat-DIM-IDDate
Date Revenue
Revenue
111
9/98
100
111
9/98 100
222
222
333
333
004
Material Dimension Table 004
444
444
555
555
005
005
Rev 10/98
222
222
333
333
444
444
111
111
9/98
9/98 100
100
9/98
100
9/98 100
9/98
9/98 100
100
222
222
333
333
10/98
10/98 100
100
10/98
100
10/98 100
10/98
10/98 100
100
444
444
555
555
10/98
10/98 100
100
10/98
100
10/98 100
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 characteristicattribute 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 characteristics 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 yesterday2. 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:
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 reporting the fact data with respect to the material group with the
material assignment that was valid at the date value (fig.49).
Constellation 09/98:
Fact Table
Reporting demands:
Material
Materialgroup
AAA
AAA
09/1998
100
BBB
BBB
09/1998
100
CCC
CCC
09/1998
100
DDD
DDD
09/1998
100
AAA
10/1998
100
200
100
BBB
10/1998
100
200
400
CCC
10/1998
100
DDD
10/1998
100
EEE
10/1998
100
Constellation 10/98:
Material
Material group
AAA
BBB
Y (changed)
CCC
DDD
EEE
Y (new)
Material Date
Revenue
(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
Rev 10/98
200
100
200
400
MatGr MatGr-SID
X
910
920
Mat-DIM-ID Date
910
001
111
910
002
222
920
002
666
920
003
333
920
004
444
920
005
555
Revenue
111
09/1998
100
222
09/1998
100
333
09/1998
100
444
09/1998
100
111
10/1998
100
666
10/1998
100
333
10/1998
100
444
10/1998
100
555
10/1998
100
(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
characteristics 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 yesterday3. 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
Material group
Fact Table
Material Date
Reporting demands:
Revenue
AAA
AAA
09/1998
100
BBB
BBB
09/1998
100
CCC
CCC
09/1998
100
DDD
DDD
09/1998
100
AAA
10/1998
100
100
100
200
200
Constellation 10/98:
Material
Material group
BBB
10/1998
100
AAA
CCC
10/1998
100
BBB
Y (changed)
DDD
10/1998
100
CCC
EEE
10/1998
100
DDD
EEE
Y (new)
Rev 10/98
(figure 51)
910
920
Query
QueryKeydate
Keydate { {09/
09/vv10/1998}
10/1998}
Rev 10/98
100
100
200
200
910
01/1000
12/9999
01/1000
12/9999
AAA
001
910
01/1000
09/1998
01/1000
09/1998
BBB
002
920
10/1998
12/9999
10/1998
12/9999
BBB
002
920
01/1000
12/9999
01/1000
12/9999
CCC
003
920
01/1000
12/9999
01/1000
12/9999
DDD
004
920
10/1998
12/9999
10/1998
12/9999
EEE
005
Fact Table
Mat-DIM-ID Date
111
09/1998
100
222
09/1998
100
333
09/1998
100
444
09/1998
100
111
10/1998
100
111
222
10/1998
100
222
333
10/1998
100
003
333
444
10/1998
100
004
444
555
10/1998
100
005
555
Revenue
(figure 52)
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.
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)
Color
Material
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 schemasStar-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
Dim ID
1
2
3
4
5
Dimension table
SALES
Umsatz
10.000
12.000
25.000
50.000
40.000
(figure 54)
Dim ID
1
2
3
4
5
Material*
A
A
A
B
B
color*
green
red
yellow
blue
green
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.
Delivery
Billing
(figure 55)
1
2
3
4
4
1
2
2
3
4
1
2
3
CUS
PROD
ODAT
SALP
DDAT
DELP
BDAT
BILP
P1
P1
P2
P2
P2
P1
P1
P1
P2
P2
P1
P1
P2
1998
1998
1997
1997
1998
*
*
*
*
*
*
*
*
S1
S2
S3
S2
S2
*
*
*
*
*
*
*
*
*
*
*
*
*
1998
1999
1999
1998
1998
*
*
*
*
*
*
*
*
D2
D1
D2
D1
D2
*
*
*
*
*
*
*
*
*
*
*
*
*
1999
1999
1998
*
*
*
*
*
*
*
*
*
*
B1
B1
B2
C1
C2
C1
C2
C2
C1
C2
C2
C1
C2
C1
C2
C1
Common
Chars
Sales
Chars
Delivery
Chars
(figure 56)
Billing
Chars
OQTY
5
10
4
8
-2
0
0
0
0
0
0
0
0
OPRI
100
200
130
150
-40
0
0
0
0
0
0
0
0
Sales
Keyfs
DQTY
0
0
0
0
0
5
7
3
2
6
0
0
0
DPRI
0
0
0
0
0
100
120
80
60
110
0
0
0
Delivery
Keyfs
BQTY
0
0
0
0
0
0
0
0
0
0
5
10
4
BPRI
0
0
0
0
0
0
0
0
0
0
100
200
130
Billing
Keyfs
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 countryspecific 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):
Order-Cube
Delivery-Cube
Billing-Cube
ONUM
CUS
PROD
ODAT
SALP
OQTY
OPRI
1
2
3
4
4
C1
C2
C1
C2
C2
P1
P1
P2
P2
P2
1998
1998
1997
1997
1998
S1
S2
S3
S2
S2
5
10
4
8
-2
100
200
130
150
-40
ONUM
CUS
PROD
DDAT
DELP
DQTY
DPRI
1
2
2
3
4
C1
C2
C2
C1
C2
P1
P1
P1
P2
P2
1998
1999
1999
1998
1998
D2
D1
D2
D1
D2
5
7
3
2
6
100
120
80
60
110
ONUM
CUS
PROD
BDAT
BILP
BQTY
BPRI
1
2
3
C1
C2
C1
P1
P1
P2
1999
1999
1998
B1
B1
B2
5
10
4
100
200
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
P1
P2
15
10
DQTY
15
8
(figure 58)
PROD
P1
P2
SALP
S1
S2
unassigned
S2
S3
unassigned
SQTY
DQTY
5
10
15
6
4
10
15
15
8
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
Basic-Cube Queries
Sales
Delivery
Billing
Multi-Cube
Sales
Cube
Basic-Cube Queries
Billing
Cube
Delivery
Cube
Basic-Cube Queries
C1
C2
C1
C2
C1
C2
C1
C2
PROD
P1
P1
P2
P2
P1
P1
P2
P2
DAT
199801
199801
199801
199801
199801
199801
199801
199801
ValType
P
P
P
P
F6
F6
F6
F6
QTY
10
10
4
8
80
70
30
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.
Plan / Actual
Multi-Cube
Basic-Cube Queries
Plan,
Forecast..
Data
Cube
Basic-Cube Queries
Actual Data
Cube
(figure 62)
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.
4. This would allow navigation on prices using external hierarchies.
5. 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.
6. 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
199905
199905
Course
TABW10
TABW10
Student
Haupt
Brugna
Attendance
1
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.
7. 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:
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):
Fact table
Dim ID
1
2
3
4
5
SALES
Umsatz
10.000
12.000
25.000
50.000
40.000
Dimension table
Dim ID
Material*
1
A
2
B
3
C
4
'_'
5
'_'
Materialgroup*
beverage
sweets
beverage
beverage
sweets
(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 precalculated 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.
BW does not explicitly know about the hierarchical dependencies. Therefore there is no
predefined drill down path with this hierarchy design.
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.