Multi-Dimensional Modeling with BW

ASAP FOR BW ACCELERATOR
BUSINESS INFORMATION WAREHOUSE

A background of 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

TH BW ASAP FOR BW ACCELERATOR

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.........................................................................................................................................2 3 FROM MULTI-DIMENSIONAL MODEL TO INFOCUBE – FIRST APPROACH.......................6 3.2 THE GOALS OF MULTI-DIMENSIONAL DATA MODELS.....................................................................................7 3.3 SUBJECT AREA...................................................................................................................................7 3.4 THE ROLE OF THE BW BUSINESS CONTENT..............................................................................................7 3.5 BASIC MODELING STEPS .....................................................................................................................8 3.5.1 Step 1: Develop a complete understanding of the underlying business processes.......................9 3.5.2 Step 2: Create a valid Schema......................................................................................................14
3.5.1.2 Reaping benefits of BW’s Business Content........................................................................................12 3.5.2.1 The Multi-Dimensional Model (MDM)................................................................................................14 3.5.2.2 The Star Schema....................................................................................................................................14

3.5.3 Step 3 : Create an InfoCube Description ....................................................................................19 3.6 RESUME...........................................................................................................................................20 4 STAR SCHEMA BASICS AND MODELING ISSUES.........................................................................22 4.1 HOW THE STAR SCHEMA WORKS.........................................................................................................22 4.2 STAR SCHEMA ISSUES........................................................................................................................23 5 MULTI-DIMENSIONAL SCHEMAS IN BW.......................................................................................25 5.1 OVERVIEW ......................................................................................................................................26 5.2 CONNECTING MASTER TABLES TO INFOCUBES........................................................................................28 5.3 DIMENSIONS IN A BW SCHEMA ..........................................................................................................31 5.3.2 Master Data Table........................................................................................................................33
5.3.2.1 5.3.2.2 5.3.2.3 5.3.2.4 5.3.2.5 5.3.2.6 5.3.2.7 Reference Characteristic Assignment...................................................................................................33 Master Table Existence.........................................................................................................................33 Assigning Attributes..............................................................................................................................34 Attributes and Querying........................................................................................................................34 InfoObject Names and Names of Attributes.........................................................................................34 Time Dependent Attributes...................................................................................................................34 Compound Attributes............................................................................................................................37

5.3.3 Text Tables....................................................................................................................................37 5.3.4 SID Tables....................................................................................................................................38
5.3.4.1 InfoObject Definition and SID Tables..................................................................................................38 5.3.4.2 SID Tables Mainetance.........................................................................................................................41 5.3.4.3 InfoCube Access and SID Tables..........................................................................................................41

5.3.5 External Hierarchy Table.............................................................................................................45
5.3.5.2 5.3.5.3 5.3.5.4 5.3.5.5 External Hierarchy Types......................................................................................................................45 Tables for External Hierarchies............................................................................................................45 Loading External Hierarchy Data.........................................................................................................45 External Hierarchies and InfoCube Access...........................................................................................46

5.3.6 Dimension Tables of an InfoCube.................................................................................................48

5.3.6.1 Defining Dimension Tables..................................................................................................................48 5.3.6.2 Columns of a Dimension Table.............................................................................................................48

©2000 SAP AMERICA, INC.

AND

SAP AG

TABLE

OF

CONTENTS

MULTI-DIMENSIONAL MODELING

WITH

BW

TH BW ASAP FOR BW ACCELERATOR

5.4 FACT TABLE.....................................................................................................................................54 5.4.1 Multiple Fact Tables.....................................................................................................................54 5.4.2 Fact Table Partitioning.................................................................................................................55 5.5 BW TERMINOLOGY ..........................................................................................................................58 6 MODELING ISSUES ANDOF THE BW SCHEMA............................................................................60 6.1 GRANULARITY ..................................................................................................................................61 6.1.1 Fact Tables and Granularity.........................................................................................................61 6.1.2 Impacts on Storage........................................................................................................................62 6.1.3 Impacts on Performance ..............................................................................................................62 6.2 LOCATION OF DEPENDENT ATTRIBUTES IN THE BW SCHEMA.....................................................................64 6.2.1 Performance and Location of Dependent Attributes ...................................................................64 6.2.2 Enterprise Data Warehouse and Location of Dependent Attributes ..........................................65 6.2.4 Data Load and Location of Dependent Attributes.......................................................................66 6.3 TRACKING HISTORY IN THE BW SCHEMA..............................................................................................68 6.3.3 History and InfoCube....................................................................................................................69 6.3.4 Slowly Changing Dimensions.......................................................................................................71
6.3.4.1 Scenario I: Report the data to today‘s constellation - Today is Yesterday...........................................74 6.3.4.1.1 Scenario I : Description.................................................................................................................74 6.3.4.1.2 Scenario I: Solutions with BW......................................................................................................75 6.3.4.2 Report the data to yesterday‘s constellation as well -Yesterday is Today ..........................................78 6.3.4.2.1 Scenario II : Description................................................................................................................78 6.3.4.2.2 Scenario II: Solutions with BW.....................................................................................................80 6.3.4.3 Scenario III: Report the data to the respective constellation-Today or Yesterday-..............................84 6.3.4.3.1 Scenario III : Description..............................................................................................................84 6.3.4.3.2 Scenario III: Solution with BW....................................................................................................85 6.3.4.4 Scenario IV: Report only on data for constellations valid today and yesterday -Today and Yesterday...........................................................................................................................................................................87 6.3.4.4.1 Scenario IV : Description..............................................................................................................87 6.3.4.4.2 Scenario IV: Solution with BW....................................................................................................89

5.3.6.3 Limitations............................................................................................................................................50 5.3.6.4 Dimensions and Navigation..................................................................................................................50 5.3.6.5 Loading data into Dimension Tables....................................................................................................50 5.3.6.6 Special BW Dimensions........................................................................................................................50 5.3.6.6.1 Packet Dimension..........................................................................................................................50 5.3.6.6.2 Unit/ Currency Dimension.............................................................................................................51 5.3.6.7 Dimensions with only one Characteristic (Line Item Dimensions)......................................................51

6.3.5 Usage of Time Scenarios .............................................................................................................91 6.4 M:N RELATIONSHIPS.........................................................................................................................93 6.6.1 M:N Relationships and the Fact Table.........................................................................................95 6.6.2 M:N Relationships within a Dimension .......................................................................................95 6.7 FREQUENTLY CHANGING ATTRIBUTES (STATUS ATTRIBUTES ).....................................................................97 6.8 INFLATION OF DIMENSIONS..................................................................................................................98 6.9 MULTIPLE PROCESS REPORTING SCENARIOS............................................................................................99 6.9.1 MultiCubes..................................................................................................................................100 6.9.2 Partitioning Attributes ...............................................................................................................103 6.10 ATTRIBUTE OR FACT (KEY FIGURE)...................................................................................................106 6.11 .................................................................................................................................................107 6.13 SAME CHARACTERISTIC SEVERAL TIMES IN THE MODEL.........................................................................108 6.14 ARTIFICIAL KEY FIGURES................................................................................................................108 6.14.1 Factless Fact tables..................................................................................................................108 6.14.2 Counting....................................................................................................................................108 6.15 BIG DIMENSIONS...........................................................................................................................108 6.16 HIERARCHIES IN THE BW SCHEMA...................................................................................................111 6.16.1 Hierarchies within a Dimension...............................................................................................111 ©2000 SAP AMERICA, INC. SAP AG TABLE CONTENTS
6.6.2.1 Designing M:N Relationships using the Dimension Table...................................................................95 6.6.2.2 Designing M:N Relationships using a Compound Attribute................................................................96

AND

OF

MULTI-DIMENSIONAL MODELING

WITH

BW

TH BW ASAP FOR BW ACCELERATOR

6.16.2 Hierarchies within a Master Data table of a Characteristic...................................................112 6.16.3 External Hierarchies................................................................................................................112

©2000 SAP AMERICA, INC.

AND

SAP AG

TABLE

OF

CONTENTS

DATA MODELING

WITH

BW

ASAP FOR BW ACCELERATOR

1 Introduction
This document provides background on the techniques used to create multi-dimensional structures within SAP BW which are called InfoCubes and suggestions to help the customer to understand when to apply the various techniques available.

1.1

Software Version Supported

This document applies to BW Version 2.0B or higher.

1.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.

© 2000 SAP AMERICA, INC.

AND

SAP AG

1

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

1.3

Overview

2
The BW version 2.0 was a major step in the evolution of the BW architecture and functionality. From the architecture point of view the introduction of the new BW Operational Data Store (BW ODS) is most important. Note: The new BW ODS introduced with version 2.0B may not be confused with layer in version 1.2B which was called ODS. This layer is renamed in Version 2.0B to Persistent Staging Area (PSA). The BW ODS is a multi-level layer in the BW data warehouse, which offers the functionality to store the result of the data cleansing, and data transformation process in transparent tables that are called ODS Objects. Doing so 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 length of this integration chain of ODS Objects is not limited by BW.

©2000 SAP AG

AND

SAP AMERICA, INC.

2

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

BW Information Integration Architecture
Source Systems PSA
Persistent Staging Area

BW ODS

InfoCubes

BW Operational Data Store

End-User Data Access

Meta Data

Cleansing & Transformation

Business Rules

Business Rules

SAP R/3 APO CRM BBP Legacy
Extraction ETL Tools

PSA

InfoCubes

• Ad Hoc   Queries • Reporting • Applications • Models

Integration Granularity

External Provider

BW Operational Data Store

Master Data
Scheduling Monitoring Change Management Service Management

The BW Architecture graphics illustrate that the InfoCubes should be founded on the integration layer for transactional data the BW ODS, but this is of course an option. 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.

3

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

With the reporting capability on the members of the BW ODS Objects, also in the context of this paper additional functionality is offered. BW ODS Objects can either be accessed directly or serve as Drill Thru target from the InfoCube point of view.

BW Information Access Architecture
Source Systems PSA
Persistent Staging Area

BW ODS

InfoCubes

BW Operational Data Store

End-User Data Access

Meta Data

SAP R/3 APO CRM BBP
ETL Tools

PSA

InfoCubes
BW
•Business Explorer •Web •Graphical User Interf

Legacy

SAP-Models
•Advanced Planning •Enterprise Mangem •CRM

External Provider

BW Operational Data Store

Third Party Tools
(ODBC/ ODBO)

Master Data
Scheduling Monitoring Change Management Service Management

However when to use what BW structure (InfoCubes or ODS-Objects) as foundation for reporting and analysis is not discussed in this paper. This is done in The BW ODS White paper. The focus of this paper is the support of Online Analytical Processing (OLAP) in BW. OLAP functionality is one of the mayor requirements in data warehousing. Roughly speaking OLAP offers even to inexperienced end-users the capability to analyze business process data (KPIs) with respect to the terms of the involved business lines. This is normally done step-by-step starting with business terms showing the KPIs on an aggregate level and further by proceeding to business terms on a more detailed level.

©2000 SAP AG

AND

SAP AMERICA, INC.

4

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

A simple example: Salesorganisation Sales Department Sales Person Productorganisation Material Group Material Type Material Time Year Month Day KPIs Sales Amount Sales Quantity

A multi-step multidimensional analysis could 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 3. Etc., etc., Such kind of analytical processing is normally solved using InfoCubes. An ODS-Object may serve to report on single record (event) level like: Show the yesterdays Sales Orders for Sales Person ‘Y’. What does not mean that sales order level data may not reside in an InfoCube this is always a question of information needs and navigation. ODS Object should not be misused for multi-dimensional analysis.

The architecture of an enterprise data warehouse is quite a controversial issue and no further detail will be discussed here. Just keep in mind that this document details building only a part of a data warehouse with reusable objects, namely InfoCubes with master data and (external) hierarchies. This document initially provides in Chapter 2 information concerning the transition from an information need to the common the multi-dimensional data model / Star Schema. As the BW Schema is based on the Star Schema we will give an introduction to the Star Schema and explain some general aspects in Chapter 3. The BW Schema is explained in detail in Chapter 4, we also explain here some modeling aspects, which directly derive from the BW Schema. In Chapter 5 deals with time aspects in the BW Schema and further demands which might have to be designed with BW.

©2000 SAP AG

AND

SAP AMERICA, INC.

5

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

3 From Multi-Dimensional Model to InfoCube – First Approach
This chapter deals with the fundamental steps of multi-dimensional data modeling to offer a motivation and understanding for the following more detailed modeling discussions. The experienced reader may therefore skip this chapter.

©2000 SAP AG

AND

SAP AMERICA, INC.

6

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

3.1 3.2 The goals of multi-dimensional data models
• Offer the information to the end-user in a way that corresponds to his normal understanding of his business i.e. show the KPIs or key figures or facts from the different points of view that influence them like sales organization, the product/ material perspective or of course time. In other words deliver structured information allowing the end-user easy navigation on it using any possible combination of business terms to illustrate the behavior of the KPIs. • Beside this the model should offer the basis for a physical implementation which is understandable for software (the so called OLAP engine) thus allows a program to access easily the required data To cover the first point we introduce the Multi-Dimensional Model (MDM).The most popular physical implementation of multi-dimensional models on relational data base 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.

The overall goals of multi-dimensional models are:

3.3

Subject Area

As this paper describes the proceeding to model BW InfoCubes we assume that the subject area we want to create a solution for is well defined. During the modeling steps the awareness may come up that the best solution would mean more than one InfoCube. The criteria that influence this decision will be discussed in a special chapter.

3.4

The role of the BW Business Content

The SAP BW is not delivered as an empty box but with a wide range of Business Content i.e. with ready for load InfoCube schemas on the solution level and even queries based on these InfoCubes. Therefore the question may arise whether it is necessary to discuss data modeling with respect to BW in a general and fundamental manner. In situations with source data from R/3 applications there is something to be said for this objection. But also in this case we first have to understand the information needs of the end-user before we are able to compare these with the business content. Nevertheless Business Content InfoCubes and even more the Business Content InfoSources (data structures offered by R/3 applications) helps at least to abbreviate the modeling process. We will not discuss the Business Content and how to get benefit during the modeling process as this is done in special papers. If however we are in the situation to create an InfoCube based partly or even entirely on non-R/3 applications (so called legacy systems) the general proceeding offer a proofed approach.

©2000 SAP AG

AND

SAP AMERICA, INC.

7

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

3.5

Basic Modeling Steps

The steps should be understood as a general approach. Up to what extend they have to be carried out depends very much on the concrete situation and the experience of the involved project members. After deciding about the subject area to be treated the basic steps that leads to a SAP BW based solution are:

1. Focus on the structure of information
• Develope 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

©2000 SAP AG

AND

SAP AMERICA, INC.

8

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

 Focus on the structure of information
ERM
Sales Rep ID LastName SalesDep Sales Org Dimension

 Focus on analytical needs Overcome model complexity
MDM/ Star Schema
Material ID Material Name Material Type Material Group Material Dimension Material ID Sales Rep ID Time Code ID Customer ID Time Code ID Year Fiscal Year Quater Mounth Day of the Week Time Dimension

Customer ID Customer Name City Region Office Name

SalesRep ID Last Name ... OrgStr. DIM ID SalesRep SalesDep SalesDep ID Address ...

Sales Amount Quantity Unit Price FACT Material ID Customer Material DIM ID Dimension Mat.description Material ID MatType MatType ...

SAP BW

Material DIM ID OrgStr DIM ID Time Code ID .... Quantity .....

 Build the solution as a part of an integrated data warehouse

3.5.1

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

In this step we focus on the structure of information : the entities and the relations between them

3.5.1.1 There is no strict rule 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. But depending on the situation and the experience sometimes it will be sufficient just to paint a diagram showing the entities and their relations. Tools like VISIO or Erwin or any other modeling tool could be very helpful in this step. An example may be the most efficient means to provide the understanding of how to approach to a Multi-Dimensional Model / Star Schema and finally to a valid BW implementation and to introduce the basic terms.

©2000 SAP AG

AND

SAP AMERICA, INC.

9

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

If the end-user describes his information needs and thus the subject area as follows: ‘Track the performance of materials with respect to customers and sales persons’ . The following nouns tell how the end-user looks at the world: • Material • Customer • Sales Person The nouns are basic business terms and are usually called Strong Entities :
Customer Material Sales Person

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:

Customer

Material

Sales Person

Ask the end-user how he measures performance. This will give you the basic Facts. Facts are normally of additive nature and describe the 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. But in a first approach it is up to the end-user whether he wants to make analysis on e.g. sales transaction level i.e. whether he wants the working document to be in the model:

©2000 SAP AG

AND

SAP AMERICA, INC.

10

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Material group

Sales Department

Customer

Material

Sales Person

Sales Transaction

Intersection Entity
Now the customer is asked to be more precise. The customer determines 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 which extent it is possible to store data concerning this entity.

Material group
 Material group no  Material group name  ....

Sales Department

Customer

 Sales dep. no  Sales dep. location  .......

 Customer no  Customer name  City  Region

Material

 Material no  Material name  Material type color price

Sales Person

 Sales pers. no  Sales pers. name  .......

Sales Transaction
 Date  Customer no  Material no  Sales pers no  Amount  Quantity  Currency

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.

©2000 SAP AG

AND

SAP AMERICA, INC.

11

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

It gives you an idea of ‘abnormal’ situations like n:m relationships between an entity and an attribute (s. material and color). This relationships have to be treated carefully:

Material Group Region Sales Dept. Loc.

City

Color

Material Type

Sales Dept.

Customer Price

Material

Sales Person

Sales order

After these steps you will have an good idea about the business terms and how are the relationships between them. It gives you a good basis for a multidimensional model. 3.5.1.2 Reaping benefits of BW’s Business Content

In SAP product based scenarios the Business Content InfoSources give you a good foundation to identify entities, attributes and facts (key figures) of the underlying subject area. As BW offers the 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 contact 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 e.g. to R/3 in the future the respective InfoSources should be regarded.

©2000 SAP AG

AND

SAP AMERICA, INC.

12

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

©2000 SAP AG

AND

SAP AMERICA, INC.

13

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

3.5.2

Step 2: Create a valid Schema

This decisive step has the goal to overcome model complexity by focusing on analytical needs.

 Focus on analytical needs Overcome model complexity
ERM
Sales Rep ID LastName SalesDep Sales Org Dimension Material Dimension Customer ID Customer Name City Region Office Name Customer Dimension Time 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

MDM/ Star Schema

Material ID Material Name Material Type Material Group

Overcome model complexity means the creation of a schema that is comprehensible for the enduser and for software. 3.5.2.1 The Multi-Dimensional Model (MDM)

(References to publications by Ralph Kimball provide the details for the multi-dimensional data model.) Comprehensibility for end-user is reached by organizing entities and attributes from step 1 that are related in parent-child relationship (1:N) into groups. We call such groups Dimensions and the members of the dimensions Dimension Attributes or just Attributes. One could say that 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. According to his usual understanding the attributes of a dimension are 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 MultiDimensional Model (MDM). The Multi-Dimensional Model with the facts based in the center and the dimensions surrounding them is a simple but mighty concept and is understood by technical resources as well as by the end-user. 3.5.2.2 The Star Schema

The Star Schema offers comprehensibility for software. The Star Schema is the most popular way to implement a Multi-Dimensional Model in a relational database. Other solutions in this area are Snowflake Schemas. The BW InfoCubes are based on a Star Schema therefore we give a short introduction to the main terms and capabilities of the Star Schema. ©2000 SAP AG
AND

SAP AMERICA, INC.

14

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

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.

Star Schem a
Sales R ep LastN e am SalesD ep Sales O rg D ension im (Table ) C ustom er ID M aterial ID Sales R ep ID Tim C e ode ID C ustom er ID Sales Am ount Q uantity FA T (Table ) C C ustom er D ension im (Table ) ID M aterial ID M aterial N e am M aterial Type M aterial G roup M aterial D ension im (Table ) Tim C e ode ID Year Fiscal Year Q uater M ounth D of the W ay eek Tim e D ension im (Table )

C ustom er N e am C ity R egion O ffice N e am

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 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 • Points of the star are Dimension Tables • Dimension Tables store attributes about the data stored in the Fact Table, and also textual data • Dimension Tables are denormalized • 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 :

©2000 SAP AG

AND

SAP AMERICA, INC.

15

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR
Customer Street SalesPers SalesRegion Material Unit Date Date

Ides Gmbh

Meier

Monitor

981118

Customer SalesPers Material Date
Ides Gmbh Meier Monitor 981118

Amount Quantity
1000 2

©2000 SAP AG

AND

SAP AMERICA, INC.

16

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

The basic proceeding mapping an ERM to the MDM/ Star Schema is shown on the following graphic:

Material Group Region City Customer Price Color Material Material Type Sales Dept. Loc. Sales Dept. Sales Person

Sales order
Sales Rep ID LastName SalesDep Sales Org Dimension Material ID Sales Rep ID Time Code ID Customer ID Sales Amount Quantity Unit Price Material ID Material Name Material Type Material Group Material Dimension Time Code ID Year Fiscal Year Quater Mounth Day of the Week

Customer ID Customer Name City Region Office Name Customer Dimension

FACT

?

Time Dimension

General Mapping Guidelines • Fact Table: A Central intersection entities defines a Fact Table. An intersection entity like document number is normally described by facts (Sales Amount, Quantity) which form the non-key columns of the Fact Table. One could say the 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 : A special case is the time dimension because there is no correspondence in the ERM therefore we have to introduce time attributes (like day, week, year,..) in the MDM process to cover the analysis needs ©2000 SAP AG SAP AMERICA, INC. 17

AND

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

These considerations provide a starting point for dimension analysis, but additional considerations will impact the grouping of the attributes and will be discussed in detail later.

©2000 SAP AG

AND

SAP AMERICA, INC.

18

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

3.5.3

Step 3 : Create an InfoCube Description

Build the solution within BW with respect to the analytical needs and as a part of an integrated data warehouse.

3.5.4 Translating the MDM/ Star Schema i.e. the results of Step 1 and Step 2 to an InfoCube Description is of course the topic of this paper and will be investigated in the following chapters in depth. A first impression is given by the following graphic: Translate the MDM/ Star Schema to an InfoCube Description :

Sales Rep ID LastName SalesDep Sales Org Dimension Material ID Sales Rep ID Time Code ID Customer ID Sales Amount Quantity Unit Price FACT

Material ID Material Name Material Type Material Group Material Dimension Time Code ID Year Fiscal Year Quater SalesRep IDMounth Day of the Week Last Name OrgStr. DIM ID ... Time Dimension SalesRep SalesDep SalesDep ID Address ... Material DIM ID OrgStr DIM ID Time Code ID .... Quantity .....

Customer ID Customer Name City Region Office Name Customer Dimension

SAP BW
Material DIM ID Material ID MatType Material ID Mat.description MatType ...

MDM/ Star Schema

©2000 SAP AG

AND

SAP AMERICA, INC.

19

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

3.6
3.6.1.1

Resume

©2000 SAP AG

AND

SAP AMERICA, INC.

20

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

3.7
Ralph Kimball writes in his book ‘ The Data Warehouse Toolkit’ : 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)

©2000 SAP AG

AND

SAP AMERICA, INC.

21

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

4 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 the 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 easier to understand as well. Coming to the BW Schema in the next chapter this basics will help you to develop a fundamental understanding of the modeling properties of the BW Schema. We emphasize that this chapter discusses the Star Schema and not the BW Schema

4.1

How the Star Schema Works

How the result of query is evaluated using a Star Schema can be best shown by an example. If we need the following information : Show me the Sales Amount for Customers located in 'New York' with Material group 'XXX' in the Year = '1997'

Star Schema
Sales Rep ID LastName SalesDep Sales Org Dimension (Table) Customer ID Customer Name City Region Office Name Customer Dimension (Table) Material ID Sales Rep ID Time Code ID Customer ID Sales Amount Quantity FACT (Table) Material ID Material Name Material Type Material Group Material Dimension (Table) Time Code ID Year Fiscal Year Quater Mounth Day of the Week Time Dimension (Table)

Then the result is determined in two steps: • 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'

©2000 SAP AG

AND

SAP AMERICA, INC.

22

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

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 which have these values in common in the Fact Table record key.

4.2

Star Schema Issues

With respect to the processing of a query and design of the Star Schema we realize : Reflecting ‘real world’ changes in the Star Schema How the changes in the real world are treated 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 the changes in the ‘real world’ normally by adding rows to the Fact Table. More precise changes in the world like Customer ‘4711’ purchase Material ‘BBB’ at Day ‘19980802’ for 100$ create a new record in the Fact Table which is identified by the combination of the key attributes of the Dimension Tables. In this case the Customer number, the Material Id and the Day :

Changes in the real world -> new rows in the fact table
Material Dimension Table
Materialgroup Material Materialgroup Material X AAA X AAA X BBB X BBB Y Y Y Y CCC CCC DDD DDD

Customer Dimension Table
Customer Custgroup Customer Custgroup 4711........................... 4711........................... 4712........................... 4712...........................

Time Dimension Table
Day Month Year Day Month Year 19980901 ..................... 19980901 ..................... 19980902 ..................... 19980902 .....................

Material Customer Material Customer

Day Day

Revenue Revenue

Fact Table
Accessing new record in fact table

AAA AAA BBB BBB CCC CCC DDD DDD BBB BBB Add new record to fact table

4711 19980901 4711 19980901 100 100 4712 19980901 4712 19980901 100 100 4712 19980901 4712 19980901 100 100 4712 19980901 4712 19980901 100 100 4711 19980902 4711 19980902 100 100

BBB 4711 19980902

100
Transaction record

©2000 SAP AG

AND

SAP AMERICA, INC.

23

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Star-II. The role of the Dimension Tables But there are also changes between attribute values of attributes within the same dimension (e.g. the material X belongs no longer to material group Y but to material group Z). Usually these changes occur more or less frequent and in the theory they are therefore called ‘slowly changing dimensions’. How to deal with these changes has a big impact on reporting possibilities and the data warehouse management. The different time scenarios that are possible and how you can solve these with BW are discussed in detail in the next sections. Reporting Star-III. Many reports can be created by accessing only the Dimension Tables (Master data reporting).

Star-IV. The Star Schema saves information about things that did happen and not things that did not happen (e.g. report the revenue for the customers in New York within a certain time span would show the customers that have any 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, SalesRep ID) need to be stored to make any desired aggregated level of information available. Star-VI. More precise: any summarized information can be retrieved at run time i.e. from a functionality point of view there is no need to store precalculated aggregated data but Star-VII. With large ( number of rows) Fact Tables and / or large Dimension Tables precalculated aggregates must be introduced for performance reasons. Attribute Relationships (Hierarchies) In the Star Schema there is one (real) attribute (most granular) as unique identifier of each Dimension Table row joining the Fact Table. The other attributes of a Dimension Table normally are parents of such an identifying attribute. This leads to the term Hierarchy. With hierarchies there exist a lot of challenges : Star-VIII. 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 having 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 the one material value with multiple colors associated with that one material. If this were the case, material is no longer a unique key.

©2000 SAP AG

AND

SAP AMERICA, INC.

24

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Star-IX. (s. 6.1.6).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 there are the attributes material and material group 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-X. Unbalanced Hierarchies Very often we have attributes in a dimension where there exists a relationship 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 from the root to the leaves of different length. This unbalanced hierarchies will produce reports with dummy hierarchy tree nodes. Table Sizes and Performance Star-XI. Don't destroy browsing performance. Dimension Tables should have a 'relatively' small number of rows (in comparison to the Fact Table; factor at least 1:10 until 1:20). Schema Maintenance Star-XII. 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 data base. Star-XIII. Flexibility regarding the addition of characteristics and key figures to the schema caused by properties of relational data bases.

5 Multi-Dimensional Schemas in BW

©2000 SAP AG

AND

SAP AMERICA, INC.

25

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

BW ‘Developed’ Star SchemaBased 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 a multi-dimensional Schema in BW means always that you have to bear in mind the overall enterprise data warehouse requirements and the solution specific analysis and reporting needs. Wrong decisions in this area will have a deep impact to the solution. The result can mean bad performance or even an invalid schema.

5.1

Overview

The picture shows you a multi-dimensional BW Schema using the example from the previous chapters. Only those parts are included which are important from the modeling point of view.

SalesOrg Dimension SalesRep Master Table
SalesRep Number SalesRep Number Sales DEP SalesOrg_Dimension_ID SalesRep Text Table SalesRep Number SalesRep Number Language Code Language Code SalesRep Name Sales Rep Number SalesOrg Dimension Table

Material Dimension
Material_Dimension_ID Material Number Material Dimension Table

Material Master Table Material Number Material Number Material Type Material Text Table Material Number Material Number Language Code Language Code Material Name Material Hierarchy Table
V R B e g i o e r t r i e b n R 1 e g i o s o nR r g e2 g ke a n i o i s n z4 i r k ie6 e b t i 7 e a t i o 3 5 t 8 n

InfoCube
Customer Master Table Customer Number Customer Number City Region Customer Text Table Customer Number Customer Number Language Code Language Code Customer Name

Material_Dimension_ID SalesOrg_Dimension_ID Time_Dimension_ID Customer_Dimension_ID Sales Amount Quantity

Materiali B r Group3z i B r e z i r k B 1e z k e z2 i B r k e
i e e G b t i e1 e G b t ei 2 e G b t i e 3e G bt

G

e Gb

i e 3 e G b at i e4 e G b t i e e5 G b t

Customer_Dimension_ID Customer Number Customer Dimension Table

FACT Table

Time_Dimension_ID Year Quater Mounth Day Time Dimension Table

Customer Dimension

Time Dimension

Observations:  The center of a multidimensional Schema in BW forms the Fact Table The facts of the Fact Table are called in BW Key Figures (e.g. Sales Amount).
AND

©2000 SAP AG

SAP AMERICA, INC.

26

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

 

The Fact Table is surrounded by Dimensions A Dimension consist of different table types:  Dimension Table The attributes of the Dimension Tables are called in BW Characteristics (e.g. Material). The meta data object in BW to describe 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 of the characteristic. They are called in BW terminology Attributes (e.g. Material Type).  Text Tables Textual descriptions of a characteristic are stored in a separate Text Table. The system runs consistently 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

A possible point of confusion is the use of the term hierarchy in BW. 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:  The InfoCube which describes the process oriented part of the solution. An InfoCube consist of   One Fact Table and Several Dimension Tables

The InfoCube – the solution dependent part of the schema

©2000 SAP AG

AND

SAP AMERICA, INC.

27

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

 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 of the data warehouse and are discussed in depth in the next chapter.

5.2

Connecting Master Tables to InfoCubes

To cover all the requirements Master Tables of a BW Schema are not linked directly to InfoCubes as the following simplified picture illustrates : Multi-Dimensional Schema in BW

©2000 SAP AG

AND

SAP AMERICA, INC.

28

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Master Master SID Tables Text Hierarchies SID Tables

Text Hierarchies

Master SID Tables

Text Hierarchies Master SID Tables Text Hierarchies

Dimension Table
Master SID Tables Text Hierarchies

SID Tables Master

Hierarchies Text

Dimension Table

FACT

Dimension Table

SID Tables

Hierarchies Text

SID Tables Master

Hierarchies Text

Dimension Table

Dimension Table
SID Tables Master

Master

Hierarchies Text

SID Tables Master

Hierarchies Text

SID Tables Master

Hierarchies Text

As you can observe in the BW Schema pointer or translation tables called SID (Surrogate-ID) Tables are used to link the solution independent Master tables of the BW Schema to InfoCubes. The graphic shows a simplified version of the reality what kind of SID tables exist and their tasks is discussed in detail in the SID table section.

©2000 SAP AG

AND

SAP AMERICA, INC.

29

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

©2000 SAP AG

AND

SAP AMERICA, INC.

30

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5.3

Dimensions in a BW Schema

Earlier we introduced some basic rules to define the dimensions on the results of the prior analysis. Rules of thumb to: 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. If we have made the decision about the members of a dimension we have to consider that a Dimension in the BW Schema might consists of different parts :

Mate rial Dim ns e Dime ion
Material_Dimension_ID Material Number Material Dimension Table

Material Master Table Material Number Material Number Material Type Material Text Table Material Number Material Number Language Code Language Code Material Name Material Hierarchy Table
V R B G e Gb e g io e r t r i e g b io s nR o r g e2 g a io n i s n 4z i r k a 3 5 t 8 t io n n R 1 e

Materiali B r Group3z i B r k e e z i r k B 1e z k e 2z i B r k e
i e e G b t i e1 e G b t i e2 e Gb t i 3e G b t i e3 e G ba t i e4 e G bt

i 5e e G b t i 6e e b t i 7 e

We emphasize the following: 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 which result in a different location of an attribute in a dimension of a muti-dimensional BW schema. ©2000 SAP AG
AND

SAP AMERICA, INC.

31

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

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 • • • • 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 choice fits best primarily depends 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 shall only show the different locations in the Schema. As shown above the Material group can occur even in the same schema as a Characteristic in the Material Dimension table and as an Attribute of Material in the Material Master Data Table. Without regard to a specific schema location as with the meta data definition we just talk about InfoObjects of type characteristic.

©2000 SAP AG

AND

SAP AMERICA, INC.

32

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5.3.1

5.3.2

Master Data Table

Defining an InfoObject of type Characteristic you have the following modeling relevant options with respect to the defintion of the Master Data Table. 5.3.2.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 so beside others the new characteristic will have the master table of the referred characteristic. For example: the characteristics ‘sending costcenter’ and ‘receiving costcenter’ refer to the same characteristic 0COSTCENTER and thus the same Master Tables 5.3.2.2 Master Table Existence

Does a Master Data Table exist at all ? (tab strip: Master Data -> Check box) This allows you do add Infoobjects as attributes in the attribute tab strip section. For example in your schema all attributes of a document number may be assigned to other characteristics like customer or material.

©2000 SAP AG

AND

SAP AMERICA, INC.

33

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5.3.2.3

Assigning Attributes

A result of the modeling phase are the attributes of a characteristic which shall reside in it’s Master Data Table. The attributes are added using the ‘Attributes’ tab strip in the InfoObject maintenance.
 

 These attributes form the communication structure for the InfoSource to load the master data. 5.3.2.4 Attributes and Querying

Whether an attribute can potentially be used for query navigation (such as drill-down, up, across, or within) on an InfoCube or ODS Object can be individually defined (Attribute tab strip-> 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. From navigational point of view navigational attributes behave like characteristics in an InfoCube. But the reporting behavior of the Navigational Attributes in Master Tables differ 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 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 in a query with an attribute it has to be an InfoObject of type key figure. InfoObject Names and Names of Attributes

5.3.2.5

It is possible to create schemas having the same InfoObject as characteristic in a Dimension Table of an InfoCube and as Navigational Attribute of another characteristic which is in the InfoCube as well. To avoid confusion you should give a name to the Navigational Attribute that differs from its characteristic name. The name is defined in the attribute tabstrip for each navigational attribute. For example: The InfoObject MMATERIAL is in the InfoCube and MMATGR is a Navigational Attribute from MMATERIAL. Let’s assume MMATGR is as a result of the model also a characteristic in the InfoCube. ‘Material group’ is the name of the InfoObject MMATGR if now you would use the same name ‘Material group’ for the Navigational Attribute this name would occur twice in the InfoCube description of the query builder. This would certainly confuse the end user. 5.3.2.6 Time Dependent Attributes

Each Attribute can be defined individually as Time Dependent. ©2000 SAP AG
AND

SAP AMERICA, INC.

34

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

An example will make clear the different behavior of Not Time Dependent and Time Dependent Attributes . Example Not Time Dependent Attributes: The InfoObject Material has the attribute MatType and we are only interested to use the latest Materials - MatTypes constellations within reports. MatType is defined as a not time dependent attribute (no check in time dependent check box). Lets assume that Material ‘BBB’ has MatType ‘300’ in 09 1998. Then a new assignment of MatType ‘200’ to Material ‘BBB’ in 10 1998 would overwrite the old constellation. The Material – MatType assignments are stored in the Not Time Dependent Attribute Master Data Table:

Material AAA BBB CCC DDD

MatType 100 200 100 100

Not Time Dependent Attribute Master Data Table (table name: /BIC/PMaterial)
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 (check in time dependent check box). Lets 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:

Material DateFrom AAA BBB BBB CCC DDD 01/1000 01/1000 10/1998 01/1000 01/1000

DateTo 12/9999 09/1998 12/9999 12/9999 12/9999

MatGroup X X Y Y Y

Time Dependent Attribute Master Data Table (table name: /BIC/QMaterial)
There exist one important aspect from the modeling point which we want to emphasize: ©2000 SAP AG
AND

SAP AMERICA, INC.

35

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

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 attributes assignments which are used in the query. We summarize the following aspects: • • • In the Attribute tabstrip section exists one ‘time dependent’ check box for each attribute. 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. From the technical implementation point of view there exist two Master Data Tables if we have not time dependent and time dependent attributes. • One master data table to store all relations to not time dependent attributes (name of the table: /BIC/Pinfobjectname) and • one table for 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 precalculated aggregates at time-dependent attribute level!

©2000 SAP AG

AND

SAP AMERICA, INC.

36

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5.3.2.7

Compound Attributes

Characteristics may not be unique i.e. another attribute is necessary to allow addressing the data. Example: the InfoObject 0COSTCENTER (cost center) offered from R/3 applications is only unique with the InfoObject 0CO_AREA (Controlling Area) These additional characteristics attributes can be defined in the compound tabstripsect section of the characteristic InfoObject maintenance.

5.3.3

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 tabstrip section. The Text Table or better the description attributes may be defined as time dependent. Transfer Rules may be applied during text data load.

©2000 SAP AG

AND

SAP AMERICA, INC.

37

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5.3.4

SID Tables

SID Tables play an important role linking the data warehouse information structures to the subjectoriented InfoCubes and ODS Objects. To speed up the access to InfoCubes and to allow an InfoCube and ODS-Object independent master data layer 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 charactereristic or attribute values correspond 1:1 to their SIDs.

5.3.4.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 which we know already from earlier versions is always generated if an InfoObject is not defined as ‘Attribute Only’ (Tabstrip general). This table is used if the access to an Infocube or ODS-Object use an navigational attribute or if the access is via a characteristic without attributes. The Not Time Dependent Attribute SID table of a characteristic for access via not time dependent attributes. The Time Dependent Attribute SID table of a characteristic for access via time dependent attributes.

 

Example: Supposed the InfoObject Material has attributes of type ‘not time dependent’ and ‘time dependent’. The activiation of this InfoObject generates the following tables (for illustration purposes we use the example from the Master Table section) : :  Material Master Table for not time dependent attributes : /BIC/Pmaterial

©2000 SAP AG

AND

SAP AMERICA, INC.

38

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Material AAA BBB CCC DDD

MatType 100 200 100 100

Not Time Dependent Attribute Master Data Table (table name: /BIC/PMaterial)

©2000 SAP AG

AND

SAP AMERICA, INC.

39

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Material Master Table for time dependent attributes

: /BIC/QMaterial

Material DateFrom AAA BBB BBB CCC DDD 01/1000 01/1000 10/1998 01/1000 01/1000

DateTo 12/9999 09/1998 12/9999 12/9999 12/9999

MatGroup X X Y Y Y

Time Dependent Attribute Master Data Table (table name: /BIC/QMaterial)

Material SID Table (traditional SID Table)

: /BIC/SMaterial

Material-SID Material 001 002 003 004 AAA BBB CCC DDD

‘Traditional‘ SID Table (table name: /BIC/SMaterial)

Material not time dependent Attribute SID Table

: /BIC/XMaterial

Material-SID Material 001 002 003 004 AAA BBB CCC DDD

MatType-SID 22222 33333 22222 22222

Not Time Dependent Attribute SID Table (table name: /BIC/XMaterial)

Material time dependent Attribute SID Table

: /BIC/YMaterial

©2000 SAP AG

AND

SAP AMERICA, INC.

40

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Material-SID Material 001 002 002 003 004 AAA BBB BBB CCC DDD

DateFrom 01/1000 01/1000 10/1998 01/1000 01/1000

DateTo 12/9999 09/1998 12/9999 12/9999 12/9999

MatGroup-SID 910 910 920 920 920

Time Dependent Attribute SID Table (table name: /BIC/YMaterial)

5.3.4.2

SID Tables Mainetance

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). 5.3.4.3 InfoCube Access and SID Tables

To get an understanding of the function of these SID tables a simple example is given how the result of 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' Lets assume the Material group is an Navigational Attribute (not 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 tables of the Material Dimension operate together to access the InfoCube Fact Table shows the following picture:

©2000 SAP AG

AND

SAP AMERICA, INC.

41

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

SID Tables for Infocube Access
Material Master table Material Master table
Material AAA CCC DDD MatGroup X Y Y MatGroup SID MatGroup X Y Z SID Material Material SID MatGroup 345 678 999

Example: Show me the sales values for material group X and Y

(Name: /BIC/PMATERIAL) (Name: /BIC/PMATERIAL)

MatGroup SID table MatGroup SID table

Not used for Infocube access !

(Name: /BIC/SMATGROUP) (Name: /BIC/SMATGROUP)

111 222 333
Dim ID Dim ID 1 2 3 Sales 10.000 12.000 25.000 1 2 3 SID Material 111 222 333

AAA CCC DDD

345 678 678

Material not time dependent Material not time dependent Attributes SID table Attributes SID table
(Name: /BIC/XMATERIAL) (Name: /BIC/XMATERIAL)

Dimension table Fact table

Not used in this Example : : Not used in this Example •Traditional Material SID Table: /BIC/SMATERIAL •Traditional Material SID Table: /BIC/SMATERIAL •Time dependent Material Master Table: /BIC/QMATERIAL •Time dependent Material Master Table: /BIC/QMATERIAL •Material Time dependent Attributes SID Table: /BIC/YMATERIAL •Material Time dependent Attributes SID Table: /BIC/YMATERIAL

Then the result set for the Material groups is 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 not 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 which have these values in the Fact Table record key. ©2000 SAP AG
AND

SAP AMERICA, INC.

42

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

We can summarize that accessing an InfoCube no ‘real value’ Master Data Tables are used. The following graphic illustrates that: 

  

©2000 SAP AG

AND

SAP AMERICA, INC.

43

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

SID Tables and InfoCube Access 5 5

5

5

5 4 5 5 5 5 5

4

2 2 1 2
3 5 3 5 5 5

2

3 5 3

5 5
(1) Fact Table

3

(2) Dimension Tables (3) time-independent-SI D (4) time-dependent-SI D (5) ‘traditional‘ SI D SID

©2000 SAP AG

AND

SAP AMERICA, INC.

44

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5.3.5

External Hierarchy Table

Hierarchies in general are essential structures for navigation and of course having characteristics and attributes in the Dimension Tables and Master Data Tables that are related in a sequence of parentchild relationships means hierarchies but internal hierarchies. External Hierarchies of a characteristic are defined seperatly from the other master data and are as mentioned above indepent from specfic 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. 5.3.5.1 During the creation of an InfoObject of type characteristic you define the basic functionality of External Hierachies for this InfoObject (Tabstrip: Hierarchies) and whether they exist at all. 5.3.5.2 External Hierarchy Types

The following external hierarchy types are possible : 1. Allow Versioning and / or time dependency of the whole external hierarchy structure (DateTo, 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 make the definition of an External Hierarchy easier.

 Important
From the performance perspective it is important to know, that ith external hierarchies of type 1 there are precalculated aggregates at each level even for specific node values possible. With external hierarchies of type 2 there are no precalculated aggregates. 5.3.5.3 Tables for External Hierarchies

The activation of the InfoObject Material results in the creation of the following tables:    Material Hierarchy Table : Material Hierarchy SID Table : Material SID-Structure Hierarchy Table : : /BIC/HMaterial : /BIC/KMaterial : /BIC/IMaterial

5.3.5.4

Loading External Hierarchy Data

External hierarchies can be transferred into the 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 latest is discussed in a separate paper.

©2000 SAP AG

AND

SAP AMERICA, INC.

45

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5.3.5.5

External Hierarchies and InfoCube Access

BW allows you the definition of 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 characteristic Country. Country is a member of the Customer Dimension Table but it could be instead or additionally a Navigational Attribute in the Customer Master Data Table. The nodes are of textual nature. If ‘Continent’ would be an InfoObject of type characteristic we could use this InfoObject to define the nodes using its characteristic values like ‘Europe’:
Country Hierarchy
-3 -2 3 4 5 -1 1 2 6*
* Set Ids only shown for better understanding

World Europe Germany Austria Switzerland America USA Canada Japan

How the access fundamentally works illustrates the following graphic:

©2000 SAP AG

AND

SAP AMERICA, INC.

46

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

SID Table: Country Country Japan Germany Austria Switz. USA Canada SID 6 3 4 5 1 2

Inclusion Table: Country Child Parent -2 -1 6 3 4 5 1 2 -3 -3 -3 -2 -2 -2 -1 -1

SID Table: Nodes Nodes America
Text & Rep. Attributes

SID -1 -2 -3

Text & Rep. Attributes

Europe World

Customer Dimension Table DIM-ID Cust-SID 1711 1712 2711 3711 4711 5711 6711 Country-SID 1 1 2 3 4 5 6

Fact Table

11 22 33 44 55 66 77

A node of a hierarchy can be either textual or 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.

©2000 SAP AG

AND

SAP AMERICA, INC.

47

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

The use of InfoCube-independent Hierarchy Tables is an additional prerequisite for an enterprisewide data warehouse because the Hierarchy Table for a characteristic only exists once. Multiple InfoCubes souring the same characteristic in a Dimension Table access the same Hierarchy Table. This is another architectural aspect that accommodates data integration.

5.3.6 5.3.6.1

Dimension Tables of an InfoCube Defining Dimension Tables

In the definition of an InfoCube you select all the InfoObjects of type characteristic which shall 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 assign only related characteristics to the same Dimension Table. This offers you additional schema potential. Nevertheless as a rule of thumb you should put only characteristics into the same Dimension that have a parent – child relationsship. The activation of the InfoCube results (with one exception which we discuss later) then in the generation of InfoCube Dimension Tables one for each Dimension. 5.3.6.2 Columns of a Dimension Table

The columns of a Dimension Table are not the characteristics themself but the SIDs of the characteristics you have chosen to be member 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).

Customer Dimension Table DIM-ID 11 22 33 44 55 66 77 Cust-SID 1711 1712 2711 3711 4711 5711 6711 Country-SID 1 1 2 3 4 5 6

We emphasize:

©2000 SAP AG

AND

SAP AMERICA, INC.

48

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

In the BW Schema a surrogate key is used as a unique key with each Dimension Table, not the real most granular characteristic within the dimension. I.e. for each unique combination of SID values of the different characteristics within a Dimension Table there is a unique surrogate key value assigned. So in the BW the Dimension Tables are joined to the Fact Table using surrogate keys.

 Important
The use of a surrogate key as a unique key in a Dimension Table allows modeling patterns like N:M relationships within the same dimension or like leafless hierarchies and most important 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.

©2000 SAP AG

AND

SAP AMERICA, INC.

49

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5.3.6.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 Thus remaining 13 Dimensions for individual schema design  Within each Dimension Table may be up to 248 characteristics

 Important
It should be mentioned that in the market sometimes each attribute / characteristic is called a dimension. This a potential point of misunderstandings as just saying with the BW Schema we have 16 dimensions and three of them are used internally this may sound very limited. Using this definition of a dimension there are 13 X 248 dimensions possible with BW plus the dimensions defined by the Navigational Attributes. 5.3.6.4 Dimensions and Navigation

All characteristics which assigned to Dimension Tables can be used for navigation (drilling) and filtering within queries. Navigation with Navigational Attributes of InfoCube characteristics has to be explictly switched on for each Navigational Attribute (Tabstrip: Navigation). The activation of a Navigational Attribute for an InfoCube can be done afterwards. Deactivation of Navigational Attributes is not possible! 5.3.6.5 Loading data into Dimension Tables

Dimension Tables are maintained during InfoCube load. 5.3.6.6 Special BW Dimensions

With BW we have special predefined Dimensions:    Time Dimension Unit/ Currency Dimension Packet Dimension

5.3.6.6.1

Packet Dimension

©2000 SAP AG

AND

SAP AMERICA, INC.

50

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

With each 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 cause an overhead during querying it therefore can be eliminated after proofed correctness of the loads up to a certain packet-id using the compress feature of the InfoCube.

5.3.6.6.2

Unit/ Currency Dimension

The respective Dimension Table is generated if in the InfoCube key figures are selected which 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 (like: Sales in HL). This will reduce overhead.

5.3.6.7

Dimensions with only one Characteristic (Line Item Dimensions)

Very often we have the situation that our model let’s us assign only one characteristic to a Dimension. This will probably occurr if for example you have the document line item in your model or with specific reporting requirements (Chapter 5: all scenarios exept no. 3). In this situations a Dimension Table means only overhead. BW allows you define this kind of Dimensions as a Line Item Dimension. (Check box Dimension definition) Doing so no Dimension Table for this Dimension will be generated. As Dimension Table will serve the SID Table of this characteristic. The key in the Fact Table will be the SID of the SID Table. Line-Item Dimension:

©2000 SAP AG

AND

SAP AMERICA, INC.

51

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Line-Item Dimension 5 3 5

5

5

5 4 5 5 5 5 5

2 1 2 2

3 5 3

(1) Fact Table (2) Dimension Tables (3) time-independent-SI D (4) time-dependent-SI D (5) ‘traditional‘ SI D

3 5

3 5

5 5

5.3.7 5.3.8

©2000 SAP AG

AND

SAP AMERICA, INC.

52

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5.3.9 5.3.10

©2000 SAP AG

AND

SAP AMERICA, INC.

53

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5.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).

 5.4.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.

©2000 SAP AG

AND

SAP AMERICA, INC.

54

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5

5

2
5

multiple Fact Tables 4

5 5 5 5 5 5

E
3 5

2 F

3 5 3

(F) F-Fact Table Requid > 0 (E) E-Fact Table Requid = 0 (2) Dimension Tables (3) time-independent-SI D (4) time-dependent-SI D (5) ‘traditional‘ SI D

2
3 5 3 5 5 5

Both Fact Tables have the same columns. The F-Table uses b-tree indixes the E-Table uses bitmap indixes 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. Doing so the Request-ID of each fact record is set to zero. The separation into two fact tables is fully transparent.

5.4.2

Fact Table Partitioning

BW supports the Partitioning of Fact Tables. Partitioning is a database feature and means in short words to split one table internally into several tables the so called partitions. Partitions of a table have there own index areas and thus smaller areas as the entire table would have. Togather with the possibility to split internally a normally sequentiell request on the entire table into several parallel request fired on different Partitions this can speed up a query significantly. Partitioning is fully transparent.

©2000 SAP AG

AND

SAP AMERICA, INC.

55

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

To partition a table you have to define a criteria which allows the database engine to decide where a specific record has to be loaded and to find him afterwards. In BW the Fact Table can be either partitioned by the InfoObject 0CALMONTH i.e. Calender year and month or by 0FISCPER i.e. fiscalyear and period.

5
Time Dimension

5 Partitioning Fact Tables 4

5 5 5 5 5 5

5

E
3 5

2

3 5 3

F

(F) F-Fact Table Requid > 0 (E) E-Fact Table Requid = 0 (2) Dimension Tables (3) time-independent-SI D (4) time-dependent-SI D (5) ‘traditional‘ SI D Packet Dimension

3

3

Togather with the entire value range for your partitioning InfoObject that you 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 to the OSS up to which degree and how 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 life time of our InfCube until ‘201012’. Without specifying a maximum value for the Partitions we would have ©2000 SAP AG
AND

SAP AMERICA, INC.

56

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

11 years x 12 month + 2 = 134 Partitions The additional 2 Partitions are reserved for data which have a 0CALMONTH value less or larger our expected values. To bring in 1 Quarter in each Partition we proceed as follows : 134 Part. / 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! The above described Fact Table Partitioning affects only the E-Fact Table. The F-Fact Table is automatically partitioned by the Reqeust-ID. For this and other reasons do not forget to compress your InfoCube on a regular base!

©2000 SAP AG

AND

SAP AMERICA, INC.

57

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

5.5

BW Terminology

The following picture shows the differences in the terminology.

MDM / Star Schema
Fact Fact Table (Dimension) Attribute

BW Schema
Key Figure Fact Table Characteristic / Navigational Attribute/ Display Attribute / (external) Hierarchy Node Dimension Table / Master Table / Text Table / External Hierarchy Table / (SID Table)

Dimension (Table)

 Important
It should be mentioned that in the market sometimes each attribute/ characteristic is called a dimension. This a potential point of misunderstandings as just saying with the BW Schema we have 16 dimensions and three of them are used internally this sounds very limited. Using this definition of a dimension there are 13 X 248 dimensions possible with BW plus the dimensions defined by the Navigational Attributes.

©2000 SAP AG

AND

SAP AMERICA, INC.

58

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

©2000 SAP AG

AND

SAP AMERICA, INC.

59

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6 Modeling issues andof the BW Schema
The proceeding will be that we look at the various important modeling issues from a topic-based point of view. Explaining how to implement these issues with BW will step by step improve our understanding of the BW schema. Trying to map real world processes the following graphic illustrates the competition of different interests which always arise during design phase. This explains the reason why some of the following modeling recommendations even contradict each other. A good design will always be a compromise. Therefore we will also strike out the impacts of modeling especially to performance (please have also a look to the accelerator ‘Sizing and Performance’) and vice versa.

Competition in Data Warehousing

Analysis Aspects

Performance Aspects

Global Data Warehouse Design Aspects

©2000 SAP AG

AND

SAP AMERICA, INC.

60

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.1

Granularity

The decision about Granularity that means the level of detail of your data is one of the important results of data modeling phase. Granularity deeply influences     Reporting capabilities Performance Space needed Load Time....

You have to decide whether you really need the data in an InfoCube or whether it is meaningful to store detailed data in an ODS object or even whether you do not store detailed data in your data warehouse at all addressing via Drill Thru the detailed data in your Source system directly. These decisions are decisions which do not influence only your current scope but the entire data warehouse approach and architecture. This topic is discussed in a special paper.

6.1.1

Fact Tables and Granularity

Volume is a concern for Fact Tables. How can the number of rows of data in a Fact Table be estimated? Consider the following:   How long shall the data be stored in the Fact Table? How granular shall the data be?

The first point is quite understandable. However, the grain of the information has a large impact on querying efficiencies and overall storage requirements. The grain of the Fact Table is directly impacted by Dimension Table design because the most atomic characteristic in each dimension determines the grain of the Fact Table. For example, assume the need to analyze the performance of outlets and articles. Attributes exist which describe: Outlet • Receipts • Articles • Customers • Time Limit analysis to articles and time, and further assume 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 ©2000 SAP AG SAP AMERICA, INC. 61

AND

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

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. 6.1.2 Impacts on Storage

Quite obviously granularity directly impacts the storage space needed. The Fact Table stores the transaction data so is the largest table in the InfoCube. Therefore, reviewing the size of the Fact Table provides a rough idea of 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 required dimensions are time, unit, and packet. 6.1.3 Impacts on Performance

Large Fact Tables impact reporting and analysis. Apart from hardware considerations, there are a few additional considerations to keep in mind Aggregation For large Fact Tables consider the use of precalculated aggregates. See the implications, such as the increase in the storage space required, in an earlier section of this document. 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.

©2000 SAP AG

AND

SAP AMERICA, INC.

62

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

©2000 SAP AG

AND

SAP AMERICA, INC.

63

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.2

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

Material Dimension
Material Dimension table

Material

As a Characteristic ?
Material Master table

Materialgroup

As a Navigational / Display Attribute ? As a Hierarchy

?

Material Hierarchy table

The freedom to choose between different locations of dependent attributes means no real freedom 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 exactly the location of a dependent attribute. This is discussed in detail in the following chapters.

6.2.1

Performance and Location of Dependent Attributes

The reporting needs should guide you in the decision where put a dependent attribute. There is little or nothing to be said from the performance point of view in favor of attributes in an InfoCube Dimension Table instead in Master or Hierarchy Tables.

©2000 SAP AG

AND

SAP AMERICA, INC.

64

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.2.2

Enterprise Data Warehouse and Location of Dependent Attributes

©2000 SAP AG

AND

SAP AMERICA, INC.

65

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.2.3 From an enterprise data warehouse point of view and apart 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 the dependent attributes should reside in master tables which means in the extreme case that there is only one characteristic in each Dimension Table (s. Line-Item Dimension).

6.2.4

Data Load and Location of Dependent Attributes

Apart from analysis demands the following hint should be observed:  Characteristics delivered by transaction data load are normally located in Dimension Tables (rule of thumb) InfoSources for transaction data load that fill the InfoCubes InfoSources for master data load that fill Master Data Tables, Text Tables and Hierarchy Tables

There are different load processes within BW covered by different types of InfoSources :  

Thus the Dimension Tables are maintained during transaction data load which means 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.

©2000 SAP AG

AND

SAP AMERICA, INC.

66

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

©2000 SAP AG

AND

SAP AMERICA, INC.

67

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.3
6.3.1

Tracking History in the BW Schema

©2000 SAP AG

AND

SAP AMERICA, INC.

68

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.3.2 We now discuss the most important term with data warehouses : time

6.3.3

History and InfoCube

Time and Fact Table 6.3.3.1 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 thus the existence of the new relationship between material ‘AAA‘ and customer ‘123‘ and date ‘19990630‘ become visible. Things that did happen 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, i.e. if during 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 is added to the Dimension Table reporting this new constellation. Additionally a row is added to the Fact Table having beside others this Dim-Id.

©2000 SAP AG

AND

SAP AMERICA, INC.

69

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Materialgroup SID
Mat Mat-SID AAA BBB CCC DDD EEE 001 002 003 004 005

Material Dimension Table
Mat-GR-SID Mat-SID Mat-DIM-ID Mat-GR-SID Mat-SID Mat-DIM-ID 910 001 111 910 001 111 910 910 920 920 920 920 920 920 920 920 002 002 002 002 003 003 004 004 005 005 222 222 666 666 333 333 444 444 555 555

Fact Table
Mat-DIM-ID Time-DIM-ID Revenue Mat-DIM-ID Time-DIM-ID Revenue

Fact Table 222 09/1998
222 333 333 444 444 111 111 222 222 333 333 444 444

111 111

09/1998 09/1998 09/1998 09/1998 09/1998 09/1998 09/1998

100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100

Material SID
Mat-GR Mat-GR-SID X Y 910 920

10/1998 10/1998 10/1998 10/1998 10/1998 10/1998 10/1998 10/1998

Add new record to dim table

555 10/1998 10/1998 555 10/1998 Add new record to fact table

Transaction record

EEE

Y

10/1998

100

Changes in the relationship between the values of parent - child attributes within a Dimension are discussed in detail in the next chapter.

©2000 SAP AG

AND

SAP AMERICA, INC.

70

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.3.4

Slowly Changing Dimensions

To Track changes between attributes of different dimensions (like a sales transaction) is the ‘normal‘ business of an InfoCube and is covered by the Fact Table. But there are also changes between characteristic value and dependent attribute value assignments. For example : Tthe Material ‘BBB’ belongs no longer to Material group ‘X’ but to Material group ‘Y’ Usually these changes occur rarely and in the theory they are addressed as ‘slowly changing dimensions’. How to handle these changes has a big impact on reporting possibilities and the data warehouse management. We emphasize again: The reporting possibilities differ whether you define a dependent attribute as a characteristic, a Navigational Attribute or a node of an external hierarchie. Because the loactions offer different time scenarios

To explain the different time scenarios we will use the example as follows :

Constellation 09/1998:
Material AAA BBB CCC DDD Material group X X Y Y

Fact Table
Material Date AAA BBB CCC DDD AAA BBB CCC DDD EEE 09/1998 09/1998 09/1998 09/1998 10/1998 10/1998 10/1998 10/1998 10/1998 Revenue 100 100 100 100 100 100 100 100 100

Constellation 10/1998:
Material AAA BBB CCC DDD EEE Material group X Y (changed) Y Y Y (new)

The example shows the Material – Material group value constellations in 09/1998 and in 10/1998. The Fact Table shows the transactions which occurred during the same time span.

©2000 SAP AG

AND

SAP AMERICA, INC.

71

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

©2000 SAP AG

AND

SAP AMERICA, INC.

72

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

With this simple example we are able to produce 4 reports with different results which all can claim to report the truth. But the truth depends on how you treat changes in the relationships between Materials and Material groups :

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

Report using 09/98 constellation Material group Rev 09/98 Rev 10/98 X Y 200 200 200 200

Report showing historical truth Material group Rev 09/98 Rev 10/98 X Y 200 200 100 400

Report showing comparable results Material group Rev 09/98 Rev 10/98 X Y 100 200 100 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 YesterdayScenario II : Report the data to yesterday‘s 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 Yesterday-

©2000 SAP AG

AND

SAP AMERICA, INC.

73

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.3.4.1 6.3.4.1.1

Scenario I: Report the data to today‘s constellation - Today is Yesterday 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’ belongs to Material group ‘Y’ from the very beginning.

Constellation 09/98:
Material AAA BBB CCC DDD Material group X X Y Y

Fact Table
Material Date AAA BBB CCC DDD AAA BBB CCC DDD EEE 09/1998 09/1998 09/1998 09/1998 10/1998 10/1998 10/1998 10/1998 10/1998 Revenue 100 100 100 100 100 100 100 100 100

Reporting demands:

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

Constellation 10/98:
Material AAA BBB CCC DDD EEE Material group X Y (changed ) Y Y Y (new)

Example from reality: 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 shall be reported as if the were made by the new sales person. This requirement means a realignment of the fact data to the new constellation.

©2000 SAP AG

AND

SAP AMERICA, INC.

74

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.3.4.1.2

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

MatGr MatGr-SID X 910 MatGr ‘Traditional‘ SID Table Y 920

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

MatGr-SID Material Material-SID 910 920 920 920 920 AAA BBB CCC DDD EEE 001 002 003 004 005 Fact Table Mat-DIM-ID Date 111 222 333 Material-SID Mat-DIM-ID 001 002 003 Material Dimension Table 004 005 111 222 333 444 555 444 111 222 333 444 555 09/1998 09/1998 09/1998 09/1998 10/1998 10/1998 10/1998 10/1998 10/1998 Revenue 100 100 100 100 100 100 100 100 100

Material Attribute SID Table

The parent attribute (Material group) resides in the Master Date Table of the child characteristic (Material) (BW Admin WB : InfoObject maintenance-> Attributes)

©2000 SAP AG

AND

SAP AMERICA, INC.

75

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

 

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)

©2000 SAP AG

AND

SAP AMERICA, INC.

76

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

2nd Solution : Today is Yesterday or Today‘s constellation is the truth – 2nd solution: Define the dependent attribute of your multi-dimensional model as Node Attribute of an External Hierarchy of your characteristic. As with BW Vers. 1.2b for all attributes of Material there would be no precalculated aggregates possible even if there is only a time dependency desired for the Material – Material group relationship (-> section about aggregates). Example – 2nd Solution: Material group as node-attribute of an External Material Hierarchy.
Material SID
Material Material-SID AAA 001 002 003 004 005 BBB CCC DDD
-1 (All) -2 (X) -3 (Y)

Report using Today‘s constallation Materialgroup Rev 9/98 Rev 10/98

+ +

X Y

100 300

100 400

Material Hierachy Table

EEE

Fact Table
Mat-DIM-ID Date Revenue 111 9/1998 9/1998 9/1998 9/1998 10/1998 10/1998 10/1998 10/1998 10/1998 100 100 100 100 100 100 100 100 100 222 333 444 111 222 333 444 555

001 002 003 004 005 (AAA) (BBB) (CCC) (DDD) (EEE)

Material Dimension Table
Material-SID Mat-DIM-ID 001 002 003 004 005 111 222 333 444 555

 

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.

©2000 SAP AG

AND

SAP AMERICA, INC.

77

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Today is Yesterday or Today‘s constellation is the truth – conclusion :  If you want to report your fact data always with respect to latest characteristic – attributes value constellations the dependent attributes have to be either Navigational Attributes or Nodes of an External Hierarchy of the characteristic.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 the possibility to define this characteristic as Line Item Dimension!

6.3.4.2 6.3.4.2.1

Report the data to yesterday‘s constellation as well -Yesterday is Today 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 descibed 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 report on the fact data as if Material ‘BBB’ belongs to Material group ‘Y’ or to Material group ‘X’.

©2000 SAP AG

AND

SAP AMERICA, INC.

78

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Constellation 09/98:
Material AAA BBB CCC DDD Material group X X Y Y

Fact Table
Material Date AAA BBB CCC DDD AAA BBB CCC DDD EEE 09/1998 09/1998 09/1998 09/1998 10/1998 10/1998 10/1998 10/1998 10/1998 Revenue 100 100 100 100 100 100 100 100 100

Reporting demands:

Report using yesterday ‘s constallation Material group Rev 09/98 X Y 200 200 Rev 10/98 200 200

Constellation 10/98:
Material AAA BBB CCC DDD EEE Material group X Y (changed ) Y Y Y (new) ?

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 year sales data with the today’s Material assignment and another query with the Material assignment which was valid last year. Thus offering a fundament for comparisons. The question may come up how to handle revenues in the Fact Table which cannot be assigned to a Material because it does not exist in the yesterdays master data.

©2000 SAP AG

AND

SAP AMERICA, INC.

79

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.3.4.2.2

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 Time Dependent Navigational Attribute of your characteristic. Example for Scenario II – 1st Solution: Material group as Time Dependent Navigational Attribute of Material
MatGr ‘Traditional‘ SID Table MatGr MatGr-SID X Y 910 920 Query Keydate == 09/1998 Query Keydate 09/1998 DateTo Material Material-SID AAA BBB BBB CCC DDD EEE 001 002 002 003 004 005 Fact Table Mat-DIM-ID Date 111 222 333 444 111 222 333 444 555 09/1998 09/1998 09/1998 09/1998 10/1998 10/1998 10/1998 10/1998 10/1998 Revenue 100 100 100 100 100 100 100 100 100

Report using yesterday‘s constellation Material group Rev 09/98 X Y not assigned 200 200 Rev 10/98 200 200 100

MatGr-SID DateFr 910 910 920 920 920 920

01/1000 12/9999 01/1000 09/1998 10/1998 12/9999 01/1000 12/9999 01/1000 12/9999 10/1998 12/9999

Material Time Dependent Attribute SID Table Material-SID Mat-DIM-ID 001 002 003 Material Dimension Table 004 005 111 222 333 444 555

The Material group is a Time Dependent Navigational Attribute of Material. (BW Admin WB : InfoObject maintenance-> Attributes) As emphasized above there would be no precalculated aggregates possible at Material group level. How to address different constellations ©2000 SAP AG SAP AMERICA, INC. 80

AND

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

 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. E.g. 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 having 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 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: Material group as node-attribute of an external hierarchy with versions, entire Hierarchy timedependent or even time-dependent Hierarchy structures in the Material Hierarchy table. Here we use a entire Hierarchy time-dependent external hierarchy:

©2000 SAP AG

AND

SAP AMERICA, INC.

81

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Keydate ==09/1998 Keydate 09/1998

Report using yesterday‘s constellation Material group Rev 9/98 Rev 10/98 200 200 100

Material Hierachy Table
-1 (All) -2 (X) 001 (AAA) 002 (BBB) -3 (Y) 003 004 (CCC) (DDD) -2 (X) -1 (All) -3 (Y)

+ +

X Y

200 200

not assigned

001 002 003 004 005 (AAA) (BBB) (CCC) (DDD) (EEE)

Fact table
Mat-DIM-ID Date Revenue Mat-DIM-ID Date Revenue 111 9/98 100 111 9/98 100 222 222 333 333 444 444 111 111 222 222 333 333 444 444 555 555 9/98 100 9/98 100 9/98 100 9/98 100 9/98 100 9/98 100 10/98 100 10/98 100 10/98 100 10/98 100 10/98 100 10/98 100 10/98 100 10/98 100 10/98 100 10/98 100

Ext Hierarchy : Mathier Valid From : 01/1000 Valid To : 09/1998

Ext Hierarchy : Mathier Valid From : 10/1998 Valid To : 12/9999 Material-SID Mat-DIM-ID Material-SID Mat-DIM-ID 001 111 001 111 002 002 003 003 222 222 333 333 444 444 555 555

004 Material Dimension Table 004 005 005

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 time dependency always means overhead. No reporting about different characteristic – attribute value constellations within a single query execution (scenario III)

©2000 SAP AG

AND

SAP AMERICA, INC.

82

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

 Important
If all dependent attributes of a characteristic are Navigational (time dependent or not) or 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 the possibility to define this characteristic as Line Item Dimension!

©2000 SAP AG

AND

SAP AMERICA, INC.

83

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.3.4.3 Yesterday6.3.4.3.1

Scenario III: Report the data to the respective constellation-Today or

Scenario III : Description

‘Yesterday or Today’ or Report the historical truth : Report the data according to the constellation of characteristics and attribute values which 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 to report the fact data with respect to Material group with the Material assignment which was valid at the Date value.

Constellation 09/98:
Material AAA BBB CCC DDD Materialgroup X X Y Y

Fact Table
Material Date AAA BBB CCC DDD AAA BBB CCC DDD EEE 09/1998 09/1998 09/1998 09/1998 10/1998 10/1998 10/1998 10/1998 10/1998 Revenue 100 100 100 100 100 100 100 100 100

Reporting demands:

Constellation 10/98:
Material AAA BBB CCC DDD EEE Material group X Y (changed) Y Y Y (new)

Report showing historical truth Material group Rev 09/98 Rev 10/98 X Y 200 200 100 400

This scenario is of interest if you want reports that track the organizational changes (time rows): e.g. With Human Resources

©2000 SAP AG

AND

SAP AMERICA, INC.

84

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.3.4.3.2

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:

©2000 SAP AG

AND

SAP AMERICA, INC.

85

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Material group as characteristic in the Material Dimension table

Report showing historical truth Material group Rev 09/98 X Y 200 200 Rev 10/98 100 400

MatGr ‘Traditional‘ SID Table MatGr MatGr-SID X Y 910 920 Fact Table Mat-DIM-ID Date 111 222 333 MatGr-SID Material-SID Mat-DIM-ID 910 910 920 920 Material Dimension Table 920 920 001 002 002 003 004 005 111 222 666 333 444 555 444 111 666 333 444 555 09/1998 09/1998 09/1998 09/1998 10/1998 10/1998 10/1998 10/1998 10/1998 Revenue 100 100 100 100 100 100 100 100 100

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 via automatic lookup to the Characteristic’s Master the parent characteristic value.

Conclusion - Today or Yesterday -: This scenario illustrates a 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 constellation implicitly via the Time in the Fact Table. ©2000 SAP AG SAP AMERICA, INC. 86

AND

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.3.4.4 Scenario IV: Report only on data for constellations valid today and yesterday -Today and Yesterday6.3.4.4.1 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: 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 to report the fact data with respect to Material group only for Material – Material group assignments which exist continously during a certain time span. You don’t want to compare oranges with pears. In our example only the white coloured constallations exist without change in our reporting time span 09 1998 until 10 1998.

Constellation 09/98:
Material AAA BBB CCC DDD Material group X X Y Y

Fact Table
Material Date AAA BBB CCC DDD AAA BBB CCC DDD EEE 09/1998 09/1998 09/1998 09/1998 10/1998 10/1998 10/1998 10/1998 10/1998 Revenue 100 100 100 100 100 100 100 100 100

Reporting demands:

Report showing comparable results Material group Rev 9/98 X Y 100 200 Rev 10/98 100 200

Constellation 10/98:
Material AAA BBB CCC DDD EEE Material group X Y (changed) Y Y Y (new)

©2000 SAP AG

AND

SAP AMERICA, INC.

87

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

This scenario may be of interest if you want comparable results.

©2000 SAP AG

AND

SAP AMERICA, INC.

88

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.3.4.4.2

Scenario IV: Solution with BW

‘Yesterday and Today’ or Report the comparable truth : Given a attribute – characteristic relation. Define the dependent attribute as a Time Dependent Navigational Attribute of the characteristic. Define additionally user-defined Date To and Date From Time Dependent Navigational Attributes. Togather with the Query Key date and a Filter on Date To and Date From excluding your reporting time span you get the desired result. Example for Scenario IV – Solution: 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 MatGr MatGr-SID X Y 910 920

Fiter: Fiter: From-User == 011900 - 091998 From-User 011900 - 091998 To-User == 101998 – 129999 101998 – 129999 To-User Query Keydate ε { 09/ v 10/1998} Query Keydate ε { 09/ v 10/1998} From-Sys To-Sys Material Material-SID 01/1000 01/1000 10/1998 01/1000 01/1000 10/1998 12/9999 09/1998 12/9999 12/9999 12/9999 12/9999 AAA BBB BBB CCC DDD EEE 001 002 002 003 004 005

Report showing comparable results Material group Rev 09/98 X Y 100 200 Rev 10/98 100 200

MatGr-SID From-User To-User 910 910 920 920 920 920 01/1000 01/1000 10/1998 01/1000 01/1000 10/1998 12/9999 09/1998 12/9999 12/9999 12/9999 12/9999

Fact Table Mat-DIM-ID Date 111 222 333 444 111 222 333 444 555 09/1998 09/1998 09/1998 09/1998 10/1998 10/1998 10/1998 10/1998 10/1998 Revenue 100 100 100 100 100 100 100 100 100

Material Time Dependent Attribute SID Table Material-SID Mat-DIM-ID 001 002 Material Dimension Table 003 004 005 111 222 333 444 555

As in the Yesterday is Today scenario we store all the different Parent-Child constellations which occurred over time.
AND

©2000 SAP AG

SAP AMERICA, INC.

89

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

    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 which are generated automatically to handle Time Dependent Attributes cannot be used for user defined navigation or filters. We have to define our own DateTo and DateFrom attributes (To-User and From-User) in the master table. During master data load the user Date To value of the old master record has to be updated. Hint: Define time variables with intervals for Date From and Date To to allow flexible reports and analysis (BEx Query Builder) e.g. 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

    

©2000 SAP AG

AND

SAP AMERICA, INC.

90

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.3.5

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 design all time scenarios within one BW Scema.  Using different time scenarios in a Schema increases the potential value of our solution Thus during analysis it is quite understandable that the end-user may wish to have all time scenarios in the BW Schema – just in case. If this wish comes up and there is no fundamental information need one have to warn the end-user because he will have to pay for it : He will lose the simplicity of the Multi-Dimensional Model and beside this produce overhead during load and querying thus:  With each additional time scenario in a BW Schema the complexity increases and thus the potential of erroneous and misleading queries. Additional training has to be done for ad hoc users and for query authors to explain the differences of the time scenarios and how and in which case to use them.

A direct consequence is: 

Beside this experience shows that :   The value of historical structure diminishes with time especially with the scenario II The scenarios I & III are the by far most frequent scenarios.

If on the other hand side the end-user has a real need to report using different time scenarios the following rules has to be observed:  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) in a BW Schema the Navigational Attribute should have a name different from the name in the InfoObject definition to avoid misunderstandings.

Otherwise you would have the same name twice in the query builder (BW Admin WB : InfoObject maintenance-> Attributes). Furthermore we realize performance impacts with certain time scenarios:

©2000 SAP AG

AND

SAP AMERICA, INC.

91

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

There are no precalculated aggregates possible on Time Dependent Attribute level thus introducing time dependency for an attribute without any need might make performance improvements impossible. The same is true with external hierarchies that are structuretime-dependent.

©2000 SAP AG

AND

SAP AMERICA, INC.

92

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.4

M:N Relationships

M:N relationships detected during logical modeling need special observation.

6.5

©2000 SAP AG

AND

SAP AMERICA, INC.

93

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.5.1.1

©2000 SAP AG

AND

SAP AMERICA, INC.

94

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.6
6.6.1 M:N Relationships and the Fact Table

Normally N:M relationships between two attributes discovered during analysis mean that they reside as characteristics in different Dimension Tables like customer and material. And the Fact Table resolves this M:N relationship. This kind of relationship is described by facts / key figures like revenue. 6.6.2 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

Material

Color

Color is an attribute of the characteristic Material. A Material can have multiple colors and vice versa. From normal understanding color should be in the Master Data Table of material like material type. But this is not possible because the material is the unique key of the master table. Thus we cannot have one material with multiple colors in the master table (This a typical challenge with Star Schemas4.2). 6.6.2.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.

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 1 2 3 4 5 Material* A A A B B color* green red yellow blue green

* remember that there are only SIDs in the dim table!

©2000 SAP AG

AND

SAP AMERICA, INC.

95

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.6.2.2

Designing M:N Relationships using a Compound Attribute

It is possible to achieve the uniqness of a characteristic defining one or even multiple attributes as a Compound Attributes (InfoObject mainetance – Tabstrip Compound). Compound Attributes If you can avoid Compounding - do it ! Compound Attributes means always an overhead with respect to Reporting as you will alwas have to qualify the Compound Attributes within a query And from performance point of view. Bear in mind: Compounding means always a heritage of Source Systems. What make sense with Source Systems does not necessarilly mean that it make sense in data warehousing. Remember that data warehousing does not mean copy management!

©2000 SAP AG

AND

SAP AMERICA, INC.

96

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.7

Frequently Changing Attributes (Status Attributes)

If you find frequently changing characteristic – attribute relations in your data model then normally the Master Data Table is not 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 important: you want normally to report on the influence of these changes but a Time Dependent Attribute allows you only to report on one constellation at a time (query execution) • Furthermore very often such an attribute is not only dependent on time and one 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. As it is the nature of status attributes the status of an Article changes frequently. The Promotion Status is normally not only an attribute of Article but on the 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 an own Dimension Table. With respect of our example ‘an own Dimension Table’ means not to put the status into the same Dimension Table as Article as this might result in a explosion of the Dimension Table. An own Dimension Table will have a positive influence to query performance as the status is often used as a filter. E.g. Show me the revenue of articles which are on promotion in region X would leave the normally large article Dimension Table untouched.

©2000 SAP AG

AND

SAP AMERICA, INC.

97

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.8

Inflation of Dimensions

It might happen that your multi-dimensional model shows you a lot of ‘small’ dimensions. ‘Small’ in this concern means Dimensions that will have only one or two characteristics whereby these characteristics have only a few number of values. You have to regard the following: • The limitations with respect to the number of dimensions within a BW Schema. • The possible produced overhead during query execution due to the fact that you have to join a lot of Dimension Tables to a large Fact Table A possible solution to overcome these impacts : Combining ‘Small’ Dimensions to overcome Dimension Inflation The BW Schema does not force you to bring only related characteristics into one Dimension Table. This allows you create one 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 the usibility i.e. for query authors you have to create a meaningful dimension name (like: Scenario Dimension) which allows him easy navigation on the model in the query builder.

©2000 SAP AG

AND

SAP AMERICA, INC.

98

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.9

Multiple Process Reporting Scenarios

A normal data warehouse issue is the reporting on information offered by different operational processes like • • order process, delivery process and billing process or sales process (actual) and planning or budgeting process

Let’s have a look to the following example:
Order
• • • • • • • O U : O e N m e (C) N M rd r u b r CU Cu om r (C) S: st e PRO : Prod ct(C) D u O AT: O e D t (C) D rd r a e SALP: Sa s Pe le rson(C) O TY: O e Q a t y (K) Q rd r u n it O PRI: O e Price(K) rd r

Delivery
• • • • • • • O U : O e N m e (C) N M rd r u b r CU Cu om r (C) S: st e PRO : Prod ct(C) D u D AT: D live D t (C) D e ry a e D ELP: D live Pe e ry rson(C) D TY: D live dQ a t y (K) Q e re u n it D PRI: D live Price(K) e ry

Billing
• • • • • • • O U : O e N m e (C) N M rd r u b r CU Cu om r (C) S: st e PRO : Prod ct(C) D u BD Billin D t (C) AT: g ae BILP: Billin Pe g rson(C) BQ Billin Q a t y (K) TY: g u n it BPRI: Billin Price(K) g

The three sceanrios have the marked characteristics in common. The question to be answered is whether there are general rules how to implement in BW reporting scenarios that consist of sub-scenarios.

©2000 SAP AG

AND

SAP AMERICA, INC.

99

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.9.1

MultiCubes

Looking at the example introduced above one might come to the following conclusion: As you frequently want to report data from these processes togather the first approach might be to create one common multi-dimensional model and following one Infocube. Creating a solution using one InfoCube without any further schema improvements we would achieve :

Order - Delivery - Billing Cube
OU N M CU S PRO D O AT D SALP D AT D D ELP BD AT BILP O TY Q O PRI D TY Q D PRI BQ TY BPRI

1 2 3 4 4 1 2 2 3 4 1 2 3

C1 C2 C1 C2 C2 C1 C2 C2 C1 C2 C1 C2 C1

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

5 10 4 8 -2 0 0 0 0 0 0 0 0

100 200 130 150 -40 0 0 0 0 0 0 0 0

0 0 0 0 0 5 7 3 2 6 0 0 0

0 0 0 0 0 100 120 80 60 110 0 0 0

0 0 0 0 0 0 0 0 0 0 5 10 4

0 0 0 0 0 0 0 0 0 0 100 200 130

Common Chars

Sales Chars

Delivery Chars

Billing Chars

Sales Keyfs

Delivery Keyfs

Billing Keyfs

The cube looks like a swiss cheese. Of course it is possible to design a more appropiate schema for the single cube approach. This is discussed in the next chapter. Using the BW MultiCube functionality we can use a space-saving, more performant and more transparent approach. A MultiCube is a virtual cube which does not exist physically. (for more details consult the BW AWB Documentation): We define three so called Basic InfoCubes. This three Basic Infocubes serve as input for the MultiCube definition. You have to observe the following • Only characteristics and navigational attributes can be declared as to be the same which reference the same InfoObject. • If the same InfoObject of type Key Figure occurrs multiple times you have to decide whether to add the values from the different cubes or you have to choose one Key Figure from one cube. In some scenarios adding makes sense (for example: MultiCube on country-specific Basic Cubes with revenue data) with other scenarios (example: actual and plan) adding is nonsense. ©2000 SAP AG
AND

SAP AMERICA, INC.

100

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

The best way to handle Key Figures is to use an Key figure InfoObject not in different semantic constellations like Key Figure QTY for ordered quantity in the Order cube and for invoiced quantity in the Invoiced .

As the allows you to access multiple InfoCubes within one query. With this background we can create three Infocubes:
OU NM CU S PRO D O AT D SALP O TY Q O PRI

Order-Cube

1 2 3 4 4
OU NM

C1 C2 C1 C2 C2
CU S

P1 P1 P2 P2 P2
PRO D

1998 1998 1997 1997 1998
D AT D

S1 S2 S3 S2 S2
D ELP

5 10 4 8 -2
D TY Q

100 200 130 150 -40
D PRI

Delivery-Cube

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

Billing-Cube

OU NM

CU S

PRO D

BD AT

BILP

BQ TY

BPRI

1 2 3

C1 C2 C1

P1 P1 P2

1999 1999 1998

B1 B1 B2

5 10 4

100 200 130

and based on these Basic InfoCubes a MultiCube a query showing Sales and Delivered Quantity would look like this:

PRO D

P1 P2

SQ TY

15 10

D TY Q

15 8

Drilling to Salesperson the result we will get:

©2000 SAP AG

AND

SAP AMERICA, INC.

101

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

PRO D

P1

SALP

S1 S2 unassigned S2 S3 unassigned

SQ TY

5 10 15 6 4 10

D TY Q

15 15 8 8

P2

This results a evaluated sending two queries in parallel to the Order and Delivery Cube. A subsequent union creates the result table.

Multi-Cube Queries

Basic-Cube Queries

Sales Delivery Billing Multi-Cube

Basic-Cube Queries

Sales Cube Delivery Cube

Billing Cube

Basic-Cube Queries

©2000 SAP AG

AND

SAP AMERICA, INC.

102

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.9.2

Partitioning Attributes

In the modeling phase the situation often appears that there are dozens of key figures (facts) like 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 ? 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 make sense to think of two basic reporting scenarios and to create two cubes one for actual sales and one for plannings, forecasts and budget  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 for example named ‘ValueType’ located in a separate dimension (table) for example named ‘Scenario’. ValueType replicates the remaining structure of the schema. We will then have only one key figure e.g. Sales Amount which only in conjunction with the characteristic ValueType gives a meaning. These attributes are often called Partitioning Attributes and their dimension a Partitioning Dimension. • The structure is flexible to expand, if for instance another scenario like 3-month forecast is needed this will be just a new ValType value. Example:
CU S PO R D DT A V lT p Q Y a ye T

Answer:

This takes into consideration the different granularity levels in the scenarios

C1 C2 C1 C2 C1 C2 C1 C2

P1 P1 P2 P2 P1 P1 P2 P2

190 981 190 981 190 981 190 981 190 981 190 981 190 981 190 981

P P P P F6 F6 F6 F6

1 0 1 0 4 8 8 0 7 0 3 0 6 0

©2000 SAP AG

AND

SAP AMERICA, INC.

103

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

It is important to remember that reporting the Sales Amount is not meaningful without specifying the ValType (as filter, in a restricted key figure...) . You would summarize for example plan data and forecast data.

©2000 SAP AG

AND

SAP AMERICA, INC.

104

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Enforcing the existance of a Partition Attribute Characteristics that partition the schema like ValType have to be in every query and every precalculated aggregate ! This can be enforced defining ValType as ‘Unique for each Cell’ in the InfoObject maintenance (Tabstrip Explorer). Further advantages of Partitioning Attributes: • • There can be external Hierarchies defined over the partitioning characteristic • • • • The BW Staging supports this feature as the update rules are defined for every key figure from the communication structure of the InfoSource. Thus enabling to split one large transactional record with many key figures into many records in the Fact Table with one key figure. Thus using both features the MultiCube and a Partitioning Attribute offer a good implementation:

Multi-Cube Queries

Plan / Actual Multi-Cube Basic-Cube Queries Basic-Cube Queries

Plan, Forecast.. Data Cube

Actual Data Cube

©2000 SAP AG

AND

SAP AMERICA, INC.

105

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.10

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. From one perspective, price describes the article as for example the manufacturer attribute does, and therefore it seems that it should be in the Master Data Table Infoobjects of Type Key Figure as Attribute in a Master Data Table Introducing a Formular Variable which addresses an Attribute of Type Key Figure like Price in a Master Data Table allows calculations within queries using this Formular Variable (s. Documentation)

Sometimes Key Figure Attributes must be integrated to the Fact Table From another perspective the price is continuous over time that means it doesn’t make sense to calculate discounts on basis of sales amount and quantity in a fact record using the actual price from the Master Data Table like 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 via lookup to the Master Data Table the actual price. From reporting point of view it can also be of interest to store an Attribute Key Figures additionally as a characteristic or an attribute of type characteristic. This would allow navigation on prices using for example External Hierarchies.

©2000 SAP AG

AND

SAP AMERICA, INC.

106

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.11

©2000 SAP AG

AND

SAP AMERICA, INC.

107

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.12 6.13 Same Characteristic several times in the Model

It may occurr that you find the same characteristic several times in your BW Schema just playing a different role. Example: Sales Employee, Delivery Employee, Billing Employee Create one InfoObject Employee. The other characteristics as InfoObject that refer to Employee. It makes often sense to introduce Employee additionally to the schema to allow simple questions like show me all transactions where a specific Employee was involved it doesn’t matter in which role.

6.14
6.14.1

Artificial Key Figures
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 which is always ‘1’ :
Month 199905 199905 Course TABW10 TABW10 Student Haupt Brugna Attendance 1 1

6.14.2

Counting

Often it makes sense to introduce additionally an artificial key figure to allow easy counting. This key figure is filled by ‘1’during load for each record.

6.15

Big Dimensions

The question may arise during modeling : How do we deal with dimension and master tables with 100 thousends or even millions of records? Use Line Item Dimensions ! We have this situation often with large customer dimensions. Very quick the solution may be :  use aggregates for demographic characteristics in the customer dimension,    this improves query performance significantly but causes possibly large space requirements and aggregates have to be maintained after data load and this may take some time

so in such a extreme situation it makes sense to think about alternatives : ©2000 SAP AG
AND

SAP AMERICA, INC.

108

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

create a smaller demographic dimension using demographic attributes of the customer    this improves query performance significantly data are available immediately after transaction data load but has a certain overhead during load time

Both approaches can be combined. As the BW Schema does not force you to put a parent attribute into the same Dimension Table as it’s child attribute it is often worth thinking about locating parent attributes in an own Dimension Table (e.g. with 100 000 article and 2000 article groups why not putting the article group in an own Dimension Table if queries often reports at article group level ?) ?)

©2000 SAP AG

AND

SAP AMERICA, INC.

109

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

©2000 SAP AG

AND

SAP AMERICA, INC.

110

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

6.16

Hierarchies in the BW Schema

Hierarchies in general are essential structures for navigation and of course having characteristics and attributes in the Dimension Tables and Master Data Tables that are related in a sequence of parentchild relationships means hierarchies. But as the real world is sometimes unbalanced or ragged so it is with hierarchies. In BW, the are essentially three possibilities to model 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 shortly look at the pros and cons of those different modeling techniques. 6.16.1 Hierarchies within a Dimension

A typical example for a hierarchy fitting into this context 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. Example: A geographic dimension with InfoObjects 0COUNTRY (country), 0REGION (region) and 0CITY (city). • But as the BW does not know anything about parent-child relationships within Dimension Tables it can make sense to design even unbalanced hierarchies in a Dimension Table if the end-user know about these strange behavior and can choose so a meaningful child attribute. Note there are no predefined 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:
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

* remember that there are only SIDs in the dim table !

The performance aspects of this technique are:

1

Actually, this is the notion of a hierarchy that is used in documents related to BW.
AND

©2000 SAP AG

SAP AMERICA, INC.

111

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

Queries to InfoCubes that use such kind of hierarchies are generally faster than the same queries to InfoCubes that model the same scenario with one of the two other hierarchy modeling techniques. The BW does not explicitly know about the 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 precalculated aggregate as well! Therefore you should always include the hierarchical levels to such an aggregate that are 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, ... too!

The reporting aspects of this technique are:  The BW does not explicitly know about the hierarchical dependencies. Therefore there is no predefined drill down path with this hierarchy design. Hierarchies within a Master Data table of a Characteristic

6.16.2

This case is very similar to the one discussed in section 6.16.1. 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. From a performance perspective this is the least attractive hierarchy modeling technique. 6.16.3 External Hierarchies

This is the ideal type if a hierarchy • • frequently changes, has no fixed number of levels (sometimes referred to as a "ragged" or “unbalanced” hierarchy).

unbalanced hierarchy

©2000 SAP AG

AND

SAP AMERICA, INC.

112

MULTI-DIMENSIONAL DATA MODELING

WITH

BWI

TH BW ASAP FOR BW ACCELERATOR

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 shallow on the other end. Another major advantage of external hierarchies vs. its alternatives is that an InfoObject can have several such hierarchies and all these can be used within the same cube. The same effect could only be achieved through nasty work-arounds when using the alternative approaches. The performance issues connected to this type of hierarchy are the following:     These hierarchies usually perform worse that those modeled within dimensions. They usually perform at least as well as the hierarchies based on Navigational Attributes. Problems can arise for big external hierarchies with many thousands of nodes and leaves. In that case it might be better to consider one of the two alternatives. We have the following types of external Hierarchies :  Versions and / or time dependency of the whole external hierarchy structure (DateTo, DateFrom) - there are precalculated 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 precalculated aggregates possible

7 8

©2000 SAP AG

AND

SAP AMERICA, INC.

113

Sign up to vote on this title
UsefulNot useful