asap multi dimensional modeling

7/27/2019 Asap Multi Dimensional Modeling

1/72

Multi-Dimensional Modeling

with BWASAP FOR BW ACCELERATORBUSINESS INFORMATION WAREHOUSE

A background to the techniques used tocreate SAP BW InfoCubesDocument Version 2.0

SAP (SAP America, Inc. and SAP AG) assumes no responsibility for errors or omissions in these materials.These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the impliedwarranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that


2/72

MULTI-DIMENSIONAL MODELINGWITH BW

Table of ContentsMULTI-DIMENSIONAL MODELING WITH BW..................................................................................1

ASAP FORBW ACCELERATOR....................................................................................................................1

TABLE OF CONTENTS...............................................................................................................................2

INTRODUCTION..........................................................................................................................................1

1. SOFTWARE VERSION SUPPORTED..............................................................................................................12. REFERENCES..............................................................................................................................................13. OVERVIEW.................................................................................................................................................1

FROM MULTI-DIMENSIONAL MODEL TO INFOCUBE STEP ONE............................................5

1. THEGOALSOFMULTI-DIMENSIONALDATAMODELS.................................................................................52. SUBJECT AREA...........................................................................................................................................53. THEROLEOF BW BUSINESS CONTENT.....................................................................................................54. BASIC MODELING STEPS .........................................................................................................................6

STAR SCHEMA BASICS AND MODELING ISSUES...........................................................................15

1. HOW THE STARSCHEMA WORKS...........................................................................................................152. STARSCHEMA ISSUES..............................................................................................................................16

MULTI-DIMENSIONAL SCHEMAS IN BW........................................................................................ ..18

1. OVERVIEW ..............................................................................................................................................182. CONNECTING MASTERTABLESTO INFOCUBES......................................................................................203. DIMENSIONSINA BW SCHEMA ..............................................................................................................214. FACTTABLE.............................................................................................................................................375. GRANULARITY ........................................................................................................................................416. THISWOULDALLOWNAVIGATIONONPRICESUSINGEXTERNALHIERARCHIES. ....................................677. SAMECHARACTERISTICSEVERALTIMESINTHEMODEL:........................................................................67

8. ARTIFICIALKEYFIGURES.........................................................................................................................679. BIGDIMENSIONS......................................................................................................................................67


3/72


Introduction

This document provides background information on the techniques used to create InfoCubes,

the multi-dimensional structures within SAP BW, and provides suggestions to help thecustomer in understanding when to apply the various techniques available.

1. Software Version SupportedThis document applies to BW Version 2.0B or higher.

2. ReferencesFor more detailed information on the SAP BW Architecture please refer to The BW ODS

Whitepaperand to the paperHierachies in BW.

3. OverviewBW version 2.0 was a major step in the evolution of the BW architecture and functionality.Most important in terms of architecture was the introduction of the new BW OperationalData Store (BW ODS).Note: The new BW ODS introduced with version 2.0B is not to be confused with the ODS layer inversion 1.2B. This layer has been renamed in Version 2.0B as Persistent Staging Area (PSA).

The BW ODS is a multi-level layer in the BW data warehouse that offers the functionality tostore the results of data cleansing and data transformation processes in transparent tablescalled ODS Objects. In so doing the BW ODS forms the historical foundation of the datawarehouse.

To enable process integration, multiple BW ODS Objects can feed other ODS Objects orInfoCubes. Business rules can be applied in the integration process. The number of ODSObjects in the integration chain is not limited in BW.

The BW architecture graphic (see fig.01, p.2) illustrates that InfoCubes should be founded onthe integration layer for transactional data in the BW ODS. Furthermore the InfoCubes arelinked to common master reference data located in master data tables, text tables, and(external) hierarchy tables. Thus the BW infrastructure provides the structure for buildingInfoCubes founded on a common integrated basis. This approach allows for partial solutionsbased on a blueprint for an enterprise-wide data warehouse.

2000 SAP AG AND SAP AMERICA, INC. 1


4/72


BW Information Integration Architecture

SAPAPR/3/3APOPOCRMRMBBPBP

Legacyegacy

ExternalxternalProviderrovider

Extraction

Master Dataaster Data

PSAPersistent Staging Area

SourceSystems

ETL Tools

Meta DataPSASA

BW Operational Data StoreW Operational Data Store

InfoCubesnfoCubes

BusinessRules

BW ODSBW Operational Data Store

InfoCubes

Cleansing&Transformation

End-UserData Access

Ad HocAd HocQueriesQueriesReportingReportingApplicationsApplicationsModelsModels

BusinessRules

SchedulingScheduling MonitoringMonitoring ChangeChangeManagementManagement

ServiceServiceManagementManagement

Granularity

Integration

(figure 01)

In the context of this paper, additional functionality is also offered through the ability toreport on members of the BW ODS Objects.With regard to InfoCubes, BW ODS Objects can either be accessed directly or serve as

drilldown targets. (see fig.02, p.3)

Which BW structure (InfoCubes or ODS-Objects) to use as the foundation for reporting andanalysis, and in what circumstances, is not discussed in this paper but in The BW ODSWhitepaper.

The focus of this paper is how to support Online Analytical Processing (OLAP) in BW.OLAP functionality is one of the major requirements in data warehousing. In short, OLAPoffers even un-experienced end-users the capability to analyze business process data (KPIs)in terms of the business lines involved. Normally this is done in stages, starting with businessterms showing the KPIs on an aggregate level, and proceeding to business terms on a more

detailed level.



5/72


BW Information Access Architecture

Legacyegacy

ExternalxternalProviderroviderMaster Dataaster Data

ETL Tools

Meta DataPSASA

BW Operational Data StoreW Operational Data Store

InfoCubesnfoCubes

SchedulingScheduling MonitoringMonitoring ChangeChangeManagementManagement

ServiceServiceManagementManagement

BWBusiness Explorer

Web

Graphical User Interf

SAP-ModelsAdvanced Planning

Enterprise MangemCRM

Third Party Tools

(ODBC/ ODBO)

SAPAPR/3/3APOPOCRMRMBBPBP

PSAPersistent Staging Area

SourceSystems

BW ODSBW Operational Data Store

InfoCubes End-UserData Access

(figure 02)

A simple example:

Sales Organisation Product Organisation Time KPIs

Sales Department Material Group Year Sales AmountSales Person Material Type Month Sales Quantity

Material Day

A multi-step multi-dimensional analysis will look like this:1. Show me the Sales Amount by Sales Department by Material Group by Month2. Show me the Sales Amount for a specific Sales Department X by Material by Month

Analytical processing of this type is normally done using InfoCubes.

An ODS-Object may serve to report on a single record (event) level such as:

Show yesterdays Sales Orders for Sales Person Y.

This does not mean that sales order level data cannot reside in an InfoCube but rather thatthis is dependant upon particular information needs and navigation.

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



6/72


There are no hard and fast rules about the architecture of an enterprise data warehouse andthis will not be discussed in any further detail here. It is important to bear in mind that thisdocument deals only with the building of one part of a data warehouse with reusable objects,namely InfoCubes, with master data, and (external) hierarchies.

In Chapter 2 this document provides initial information concerning the transition from an

information need to the common multi-dimensional data model / Star schema. As the BWschema is based on the Star schema, an introduction to the Star schema will be given inChapter 3, and some general aspects explained. The BW schema is explained in detail inChapter 4, where modeling aspects that are derived directly from the BW schema are alsoexplained. Chapter 5 deals with time aspects in the BW schema and further demands whichmight have to be designed with BW.



7/72


From Multi-Dimensional Model to InfoCube Step

OneThis chapter deals with the basic stages of multi-dimensional data modeling to foster a basicunderstanding for the more detailed discussions that follow. The experienced reader maytherefore want to skip this chapter.

1. The goals of multi-dimensional data modelsThe overarching goals of multi-dimensional models are:

To present information to the end-user in a way that corresponds to his normal

understanding of his business i.e. to show the KPIs, key figures or facts from thedifferent perspectives that influence them (sales organization, product/ material or time).

In other words, to deliver structured information that the end-user can easily navigate byusing any possible combination of business terms to illustrate the behavior of the KPIs.

To offer the basis for a physical implementation that the software recognizes (the OLAP

engine), thus allowing a program to easily access the data required.The Multi-Dimensional Model (MDM) has been introduced in order to achieve the first. Themost popular physical implementation of multi-dimensional models on relational databasesystem-based data warehouses is the Star schema implementation. SAP BW uses the Starschema approach and extends it to support integration within the data warehouse, to offereasy handling and allow high performance solutions.

2. Subject Area

As this paper describes the process of modeling BW InfoCubes, it is assumed that the subjectarea for which we want to create a solution is well defined. It may become apparent duringthe modeling stages that the best solution would be to implement more than one InfoCube.The criteria on which this decision should be made will be discussed in a separate chapter.

3. The role of BW Business ContentThe SAP BW package is not an empty box but comes with a wide range of Business Content ,ready-to-load InfoCube schemas at solution level and queries on these. It is thereforequestionable whether BW data modeling needs to be discussed in general terms, and wherethe source data is from R/3 applications it is not essential. But even in such cases theinformation needs of the end-user must first be understood before these can be comparedwith the Business Content.Business Content InfoCubes, and the Business Content InfoSources (data structures offeredby R/3 applications) in particular, do at least help shorten the modeling process. BusinessContent and how to benefit from it in the modeling process is not discussed here as this isdone in separate papers.

If, however, an InfoCube is to be created based partly or entirely on non-R/3 applications(legacy systems), this general process offers a proven approach.



8/72


4. Basic Modeling StepsThese steps should be understood as a general approach. To what extent they must becarried out depends on the actual situation and the experience of the project members

involved.

After deciding on the subject area being dealt with, the basic steps to implementing a SAPBW based solution are (see fig.03, p.6):

1.1. Focus on the structure of informationFocus on the structure of information

Develop a complete understanding of the underlying business processes

(E.g. create an Entity Relationship Model [Diagram] of the business model)

The ERM as a function of the information

2.2. Focus on analytical needs - Overcome model complexityFocus on analytical needs - Overcome model complexity

Create a valid schema

Translate the ERM to the MDM / Star schema

The MDM as a function of the analytical processing

3.3. Build the solution as a part of an integrated data warehouseBuild the solution as a part of an integrated data warehouse

The schema on the BW stage the InfoCubes

Translate the MDM / Star schema to one or more InfoCube schemas

Sales Rep ID

LastName

SalesDep

Material ID

Material Name

Material Type

Material Group

Customer ID

Customer Name

City

Region

Office Name

Time Code ID

Year

Fiscal Year

Quater

Mounth

Day of the Week

Material ID

Sales Rep IDTime Code IDCustomer ID

Sales Amount

Quantity

Unit Price

Time Dimension

Customer Dimension

Sales Org DimensionMaterial Dimension

FACT

Material DIM ID

OrgStr DIM ID

Time Code ID....

Quantity.....

SalesRep ID

Last Name

...Material DIM ID

Material ID

MatType

Material ID

Mat.description

MatType...

OrgStr. DIM ID

SalesRep

SalesDep

SalesDep ID

Address

...

Focus on analytical needs -

Overcome model complexity

Build the solution as a

part of an integrated

data warehouse

MDM/ Star Schema

SAP BW

ERM

Focus on the structure of information

(figure 03)



9/72


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

In this step we focus on the structurestructure of information:

1. Entities and the relations between them

There are no strict rules on how to develop a complete understanding of the underlyingbusiness process. Nevertheless using an Entity Relationship Model (ERM) is a good way ofseeing the relevant business objects and their relationships. Depending on the particularcircumstances and the extent of personal experience, it will sometimes be sufficient just todraw a diagram showing the entities and their relationships.

Tools like VISIO or Erwin or any other modeling tool are very useful here.

Examples may be the most efficient means of providing an understanding of how to approacha Multi-Dimensional Model / Star schema and eventually a valid BW implementation, and ofintroducing basic terms.

E.g. If the end-user describes his information needs and subject area as,

Track the performance of materials with respect to customers and sales persons

The following nouns relate to the end-users information needs:

Material

Customer

Sales Person

The nouns are basic business terms and are usually called Strong Entities (see fig.04):

Customer Material Sales Person

(figure 04)

Ask the end-user about the relationship between his basic business terms (strong entities).

Normally the relationship between strong entities are N:M Relationships i.e. a customer canpurchase multiple materials and materials can be purchased by multiple customers (seefig.05):

Customer Material Sales Person

(figure 05)

Ask the end-user how performance is measured.



10/72


This will give you the basic Facts. Facts are normally additive and describe n:mrelationships. In a business scenario with a working document this document forms anIntersection Entity which often resolves the n:m relationships to 1:n relationships. In thefirst instance, however, it is up to the end-user whether or not to include the workingdocument in the model when analysing, for example, a sales transaction level (see fig.06):

Customer

Sales Transaction

Material

Material group

Sales Person

Sales Department

Intersection Entity

(figure 06)

In the next stage the customer is asked to be more precise and, in this case, determine thatadditional details for material, customer and sales person are also required.

This gives you additional entities and attributes where attributes are the describing fields ofan entity. In ERM diagrams attributes show the fields in relational tables.

The attributes demonstrate to what extent it is possible to store data concerning this entity(see fig.07, p.9)

It is useful for the following steps to ask the end-user for details concerning relationshipsbetween entities and relationships between entities and their attributes.

This draws your attention to any abnormal situations like n:m relationships between anentity and an attribute (s. material and color). These relationships have to be treated carefully(see fig.08, p.9).



11/72


Customer

Material Sales Person

Material group Sales Department

Customer no

Customer name

City

Region

Material no

Material name

Material type

color

price

Material group no

Material group name

....

Sales TransactionDate

Customer no

Material no

Sales pers no

Amount

Quantity

Currency

Sales pers. no

Sales pers. name

.......

Sales dep. no

Sales dep. location

.......

(figure 08)

Customer

City

Region

Material Group

Sales order

Price

Sales Person

Sales Dept.

Sales Dept. Loc.

Material

Material TypeColor

(figure 09)

After completing these steps you will have a good idea about the business terms involved andhow the relationships between them are configured. This provides a good basis for amultidimensional model.

2. Reaping benefits of BWs Business Content

In SAP product-based scenarios the Business Content InfoSources provide a good basis onwhich to identify the entities, attributes and facts (key figures) of the underlying subject area.As BW provides InfoSources ordered by applications, it is easy to identify the InfoSource(s)which cover(s) your subject area. If the subject area is based on customer-generatedstructures like LIS and CO-PA you have to refer to these structures. The result is normally acomplete set of entities and attributes. The relationships can be derived from the SAP productdata model if they are not obvious.



12/72


Even if the solution is not entirely SAP product based, or you plan to migrate a source legacysystem to R/3 for example in the future, the respective InfoSources should be considered.

3. Step 2: Create a valid Schema

This crucial step aims to overcome model complexity by focusing on analytical needs (seefig.10).

Sales Rep ID

LastName

SalesDep

Material ID

Material Name

Material TypeMaterial Group

Customer ID

Customer NameCity

RegionOffice Name

Time Code ID

YearFiscal Year

QuaterMounth

Day of the Week

Material ID

Sales Rep IDTime Code ID

Customer ID

Sales Amount

QuantityUnit Price

Time DimensionCustomer Dimension


FACT

Focus on analytical needs -

Overcome model complexity

MDM/ Star Schema

ERM

(figure 10)

Overcoming model complexity involves the creation of a schema that is comprehensible forboth the end-user and the software.

4. The Multi-Dimensional Model (MDM)

(Publications by Ralph Kimball, as referred to below, provide the details for the multi-dimensional data model).Comprehensibility for the end-user is reached by organizing entities and attributes fromstep 1 that are arranged in a parent-child relationship (1:N), into groups. These groups arecalled dimensions and the members of the dimensions dimension attributes, orattributes.The strong entities define the dimensions. For the end-user the attributes of a dimensionrepresent a specific business view on the facts (or key figures or KPIs), which are derivedfrom the intersection entities. The attributes of a dimension are then organized in ahierarchical way and the most atomic attribute that forms the leaves of the hierarchy definesthe granularity of the dimension. Granularity determines the detail of information. Thismodel is called Multi-Dimensional Model (MDM). The Multi-Dimensional Model, wherethe facts are based in the center with the dimensions surrounding them, is a simple buteffective concept that is easily recognized by technical resources as well as by the end-user.

5. The Star Schema

The Star schema offers comprehensibility for software. The Star schema is the mostpopular way of implementing a Multi-Dimensional Model in a relational database.Snowflake schemas are an alternative solution although BW InfoCubes are based on a Starschema, and a short introduction to its main terms and capabilities will now be given here.



13/72


In a Star schema, one dimension represents one table. These dimension tables surround thefact table, which contains the facts (key figures), and are linked to that fact table via uniquekeys, one per dimension table. Each dimension key uniquely identifies a row in theassociated dimension table. Together these dimension keys uniquely identify a specific rowin the fact table (see fig.11).

Star Schema

Sales RepSales Rep IDID

LastName

SalesDep

Material IDMaterial ID

Material Name

Material Type

Material Group

CustomerCustomerIDID

Customer Name

City

RegionOffice Name

Time Code IDTime Code ID

Year

Fiscal Year

QuaterMounth

Day of the Week





Sales Amount

Quantity

Time

Dimension

(Table)

Customer

Dimension

(Table)

Sales Org

Dimension

(Table)

Material

Dimension(Table)

FACT(Table)

(figure 11)

The key elements of a Star schema are:

Central fact table with dimension tables shooting off from it

Fact tables typically store atomic and aggregate transaction information, such as

quantitative amounts of goods sold. They are called facts

Facts are numeric values of a normally additive nature

Fact tables contain foreign keys to the most atomic dimension attribute of each

dimension table

Foreign keys tie the fact table rows to specific rows in each of the associated

dimension tables

The points of the star are dimension tables

Dimension tables store both attributes about the data stored in the fact table and

textual data

Dimension tables are de-normalized

The most atomic dimension attributes in the dimensions define the granularity of the

information, i.e. the number of records in the fact table



14/72


The Fact Table (fig.12):

CustomerCustomer StreetStreet SalesPersSalesPers SalesRegionSalesRegion MaterialMaterial UnitUnit DateDateDate

Customer SalesPers Material Date Amount Quantity

Ides Gmbh Meier Monitor 981118 1000 2

Customer SalesPers Material Date Amount Quantity

Ides Gmbh Meier Monitor 981118 1000 2

Ides Gmbh Meier Monitor 981118

(figure 12)

The basic process of mapping an ERM to the MDM/ Star schema is shown on the following

graphic (fig.13):

Sales Rep ID

LastName

SalesDep

Material ID

Material Name

Material Type

Material Group

Customer ID

Customer Name

City

Region

Office Name

Time Code ID

Year

Fiscal Year

Quater

Mounth

Day of the Week

Material ID

Sales Rep IDTime Code ID

Customer ID

Sales Amount

Quantity

Unit Price



FACT??

Customer

City

Region

Material Group

Sales order

Price

Sales Person

Sales Dept.

Sales Dept. Loc.

Material

Material TypeColor

(figure 13)



15/72


General Mapping Guidelines

Fact Table:

A central intersection entity defines a Fact Table. An intersection entity such as documentnumber is normally described by facts (sales amount, quantity), which form the non-key

columns of the fact table. In fact, M:N relationships between strong entities meet eachother in the fact table, thus defining the cut between dimensions

Dimensions (Tables):

Attributes with 1:N conditional relationships should be stored in the same dimension suchas material group and material.

The foreign -> primary key relations define the dimensions

Time:

One exception is the time dimension. As there is no correspondence in the ERM, timeattributes (day, week, year) have to be introduced in the MDM process to cover the

analysis needs.

These considerations provide a starting point for dimension analysis, but additionalconsiderations will impact on the grouping of the attributes and will be discussed in detaillater.

6. Step 3: Create an InfoCube Description

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



16/72


Translate the MDM/ Star Schema into an InfoCube Description:

Sales Rep ID

LastNameSalesDep

Material ID

Material NameMaterial Type

Material Group

Customer ID

Customer Name

City

RegionOffice Name

Time Code ID

Year

Fiscal Year

QuaterMounth

Day of the Week

Material ID

Sales Rep ID

Time Code ID

Customer ID

Sales AmountQuantity

Unit Price



FACT

MDM/ Star Schema

SAP BW

Material DIM ID

OrgStr DIM IDTime Code ID

....

Quantity

.....

SalesRep ID

Last Name

...Material DIM ID

Material ID

MatType

Material ID

Mat.descriptionMatType

...

OrgStr. DIM ID

SalesRepSalesDep

SalesDep ID

Address

...

(figure 14)

7. Resume

In his book The Data Warehouse Toolkit, Ralph Kimball writes:The nine database design decision points for a dimensional data warehouse consist of

deciding on the following:

1. The processes, and hence the identity of the fact tables ([one fact table - oneInfoCube] -> intersection entities)

2. The dimensions of each fact table (->strong entities)3. The dimension attributes with complete descriptions and proper terminology (->

attributes and entities)

4. The grain of each fact table5. The facts, including pre-calculated facts6. How to track slowly changing dimensions7. The aggregations, heterogeneous dimensions, mini-dimensions, query modes and other

physical storage decisions8. The historical duration of the database (archiving aspects)9. The urgency with which the data is extracted and loaded into the data warehouse (time

frame for loading)



17/72


Star Schema Basics and Modeling Issues

In the previous chapter we introduced the Star schema. As most of the relevant properties formodeling derive directly from these schemas, we will now have a closer look to them. Westart with the Star schema as it is the force behind the BW schema and is also easier to

understand. These basics will also help you to develop a fundamental understanding of themodeling properties of the BW schema before that is discussed in the next chapter. Weemphasize that this chapter discusses the Star schema and not the BW schema

1. How The Star Schema Works

How the result of a query is evaluated using a Star schema can best be shown through thisexample (fig.15): If we need the following information,

Show me the sales amount for customers located in 'New York' with material

group 'XXX' in the year = '1997'

Star Schema


LastNameSalesDep


Material NameMaterial Type

Material Group


Customer NameCityRegion

Office Name


YearFiscal YearQuater

Mounth

Day of the Week





Sales Amount

Quantity

TimeDimension

(Table)

CustomerDimension

(Table)

Sales Org

Dimension(Table)

MaterialDimension

(Table)

FACT(Table)

(figure 15)

The answer is determined in two stages:

Browsing the Dimension Tables

Access the Customer Dimension Table and select all records with City = 'New

York'

Access the Material Dimension Table and select all records with Materialgroup = 'XXX'

Access the Time Dimension Table and select all records with Year= '1997'

As a result of these three browsing activities, there are a number of key values(Customer IDs, Material IDs, Time Code ID), one from each dimension tableaffected.

Accessing the Fact Table



18/72


Using the key values evaluated during browsing, select all records in the fact tablethat have these values in common in the fact table record key.

2. Star Schema IssuesWith respect to the processing of a query and the design of the Star schema we realize that:

Reflecting real world changes in the Star schema

How real-world changes are dealt with, i.e. how the different time aspects are handledis the most important topic with data warehouses.

Star-I. The role of the fact table

The Star schema reflects changes in the real world normally by adding rows to thefact table. More precise real world changes like Customer4711 purchaseMaterialBBB at Day 19980802 for $100 creates a new record in the fact table, which isidentified by the combination of key attributes in the dimension tables. In this casethe customer number, material ID and the day (fig.16):

Changes in the real world -> new rows in the fact table

Materialgroup Material

X AAA

X BBB

Y CCC

Y DDD

Materialgroup Material

X AAA

X BBB

Y CCC

Y DDD

Material Customer Day Revenue

AAA 4711 19980901 100

BBB 4712 19980901 100

CCC 4712 19980901 100

DDD 4712 19980901 100

BBB 4711 19980902 100

Material Customer Day Revenue

AAA 4711 19980901 100

BBB 4712 19980901 100

CCC 4712 19980901 100DDD 4712 19980901 100

BBB 4711 19980902 100

Material Dimension Table

Fact Table

BBB 4711 19980902 100

Transaction record

Add new record

to fact table

Customer Custgroup

4711...........................

4712...........................

Customer Custgroup

4711...........................

4712...........................

Day Month Year

19980901 .....................

19980902 .....................

Day Month Year

19980901 .....................

19980902 .....................

Customer Dimension Table Time Dimension Table

Accessing new record

in fact table

Star-II. The role of dimension tables

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



19/72


Reporting

Star-III. Reports can be created by accessing the dimension tables (master data

reporting).

Star-IV. The Star schema saves information about events that did or did not happen

(e.g. reporting the revenue for the customers in New York within a certain timespan would show the customers that have revenue, but not the customers that haveno revenue).

Aggregation

Star-V. Only the information at the granularity of the dimension table keys (material

ID, customer ID, time code ID, sales rep ID) need to be stored to make any desiredaggregated level of information available.

Star-VI. More precisely: any summarized information can be retrieved at run time i.e.as far as functionality is concerned, there is no need to store pre-calculated

aggregated data, but with large ( number of rows) fact tables and / or large

dimension tables, pre-calculated aggregates must be introduced for performancereasons.

Attribute Relationships (Hierarchies)

In the Star schema there is one (real) attribute (most granular) as the uniqueidentifier of each dimension table row joining the fact table. The other attributes ofa dimension table are normally parents of such identifying attributes, thus the termhierarchy. With hierarchies numerous challenges must be resolved:

Star-VII. N:M relationship within a dimension.There is no simple way to handle an N:M relationship between two attributes withina dimension table (such as materials with different colors). If material is the lowest

level, it is not possible to put both material and material color into one normal stardimension table, as we would have one material value associated with multiplecolors. As such, material is no longer a unique key.

Star-VIII. No leaf attribute values.Again there is no easy way to handle transactional input to a Star schema where thefacts are offered at different attribute levels, whereby the attributes belong to thesame dimension. For example, assume the attributes material and material groupexist in the same dimension. Some subsidiaries can offer transactional data atmaterial level whereas others can only offer data at material group level. The resultin the latter case is dimension table rows with blank or null values for the material,

which destroys the unique key material.Star-IX. Unbalanced hierarchies

Very often we have attributes in a dimension where a relationship exists betweensome attribute values, whereas with others there is none. As the relations betweenattribute values of different attributes within a dimension form a tree that will resultin paths of differing lengths from root to leaves, these unbalanced hierarchies willproduce reports with dummy hierarchy tree nodes.



20/72


Table Sizes and Performance

Star-X. Do not destroy browsing performance. Dimension tables should have a

'relatively' small number of rows (in comparison to the fact table; factor at least1:10 to 1:20).

Schema MaintenanceStar-XI. There are no limitations to the Star schema with respect to the number of

attributes in the dimension and fact tables, except the limitations caused by theunderlying relational database.

Star-XII. Flexibility regarding the addition of characteristics and key figures to the

schema is caused by properties of relational databases.

Multi-Dimensional Schemas in BW

Based on experience with the Star schema, the SAP BW schema uses a more sophisticated

approach to guarantee consistency in the data warehouse and to offer schema-basedfunctionality to cover the end-users analysis needs.Creating a valid multi-dimensional schema in BW means that you always have to bear inmind the overall enterprise data warehouse requirements and the solution-specific analysisand reporting needs. Errors in this area will have a deep impact on the solution, resulting inpoor performance or even an invalid schema.

1. OverviewThe graphic shows a multi-dimensional BW schema using the example from the previouschapters. Only those parts that are important as far as modeling is concerned are included(fig.17).



21/72


FACT Table

G e bi et 1 G e b ie t 2 G e bi e t 3

B e z i r k 1

G e b i e t 3 a

B e z i r k 2

R e g i o n 1

G e b i et 4 G e b i et 5

B e z i r k 3

R e g i o n 2

G e b i e t 6

B e z i r k 4

G e b i et 7 G e b i et 8

B e z i r k 5

R e g i o n 3

V e r t r i e b s o r g a n i s a t i o n

MaterialGroup

Material Hierarchy TableMaterial_Dimension_ID

SalesOrg_Dimension_IDTime_Dimension_ID

Customer_Dimension_ID

Sales Amount

Quantity

Material Number

Language Code

Material Number

Language Code

Material Name

Material Text TableMaterial_Dimension_ID

Material Number


Material Master Table

Material NumberMaterial Number

Material Type

SalesRep Master Table

SalesRep NumberSalesRep Number

Sales DEP

SalesRep Number

Language Code

SalesRep Number

Language Code

SalesRep Name

SalesRep Text Table

Customer Number

Language Code

Customer Number

Language Code

Customer Name

Customer Text Table

Customer Master Table

Customer NumberCustomer Number

City

RegionTime_Dimension_ID

Year

QuaterMounth

Day

Time Dimension Table

SalesOrg_Dimension_ID

Sales Rep Number

SalesOrgSalesOrgDimensionDimension TableTable

Customer_Dimension_ID

Customer Number

Customer Dimension Table

CustomerCustomer DimensionDimension

InfoCubeInfoCube

TimeTime DimensionDimension

MaterialMaterial

DimensionDimension

SalesOrgSalesOrg DimensionDimension

Observations:

The center of a multidimensional schema in BW forms the fact table.In BW the facts of the fact table are called key figures (e.g. sales amount).

The fact table is surrounded by dimensions. A dimension consist of different table types:

Dimension Table

In BW the attributes of the dimension tables are called characteristics (e.g.material).The meta data object in BW that describes characteristics and also key figures(facts) is called InfoObject.

Master Tables:

Master Data Table

Dependent attributes of a characteristic can be stored in a separate table calledthe Master Data Table for the characteristic. In BW they are calledterminologyattributes (e.g. material type).

Text Tables

Textual descriptions of a characteristic are stored in a separate text table. Thesystem runs in different languages at a time.



22/72


External Hierarchy Tables

Hierarchies of characteristics or attributes may be stored in separate hierarchytables. For this reason these hierarchies are named external hierarchies (e.g.standard cost center hierarchy from R/3-CO for the characteristic cost center).

Important

The use of the term hierarchy in BW is a possible point of confusion. The

normal understanding of hierarchy is defined as a sequence of parent-child

relationships between characteristics. From this perspective, there arehierarchies in the dimension tables, master tables, and in hierarchy tables.

The multi-dimensional schema in BW is separated into two parts:1. The InfoCube, which describes the process-oriented part of the solution. An InfoCubeconsist of

One fact table and

Several dimension tables (fig.18, p.20)

The InfoCube the solution-dependent part of the schema

(figure 18)

2. The solution-independent shared master tables valid for use with any InfoCube andBW ODS Object in the data warehouse.

These master tables are the glue that binds the data warehouse and are discussed indepth in the next chapter.

2. Connecting Master Tables to InfoCubes

In order to be able to cover all requirements master tables in a BW Schema are not linkeddirectly to InfoCubes, as the following, simplified, picture illustrates (fig.19):



23/72


Multi-Dimensional Schema in BW

Text

SID Tables

Master

Hierarchies

Hierarchies

Master

SID Tables

Text

Hierarchies

Master

SID Tables

Text

Hierarchies

Master

SID Tables

Text

Hierarchies

Master

SID Tables

Text

Hierarchies

Master

SID Tables

Text

Text

SID Tables

Master

Hierarchies

Text

SID Tables

Master

Hierarchies

Text

SID Tables

Master

Hierarchies

Dimension

Table

Text

SID Tables

Master

Hierarchies

Dimension

Table

Dimension

Table

Dimension

Table

Dimension

Table

Hierarchies

Master

SID Tables

Text

FACT

(figure 19)

As you can see, pointer or translation tables called SID (Surrogate-ID) tables are used in theBW schema to link the solution-independent master tables of the BW schema to InfoCubes.

The graphic shows a simplified version of what types of SID tables exist and their tasks arediscussed in detail in the section on the SID table.

3. Dimensions in a BW schemaEarlier we introduced some basic rules in defining dimensions on the results of prioranalysis:

Attributes with 1:N conditional relationships should be stored in the same dimensionsuch as material group and material.

The foreign -> primary key relations define the dimensions.

Once a decision on the members of a dimension has been made we have to consider thata dimension in the BW schema might consists of different parts (fig.20):



24/72


G e bi et 1 G e b ie t 2 G e bi et 3

B e z i r k 1

G e b i e t 3 a

B e z i r k 2

R e g i o n 1

G e b i et 4 G e b ie t 5

B e z i r k 3

R e g i o n 2

G e b i e t 6

B e z i r k 4

G e b ie t 7 G e b ie t 8

B e z i r k 5

R e g i o n 3

V e r t r i e b s o r g a n i s a t i o n

MaterialGroup

Material Hierarchy Table

Material Number

Language Code

Material Number

Language Code

Material Name

Material Text TableMaterial_Dimension_ID

Material Number


Material Master Table

Material NumberMaterial Number

Material Type

MaterialMaterial

DimensionDimension

(figure 20)

We emphasize that:

Dimensions in a BW schema

The dependent attributes of the characteristics can reside in different locations of a BWschema dimension.

One of the primary goals of this paper is to show the different modeling aspects that result in

a different location of an attribute in a dimension of a multi-dimensional BW schema (fig.21,p.22).

Material

Material Dimension

Materialgroup

Material

Dimension table

As a CharacteristicAs a Characteristic??

MaterialMaster table

As a NavigationalAs a Navigational//

DisplayDisplayAttributeAttribute ??

Material

Hierarchy tableAs a HierarchyAs a Hierarchy??



25/72


(figure 21)

As the graphic shows, the material-material group relation can be designed defining materialgroup

Either as a characteristic i.e. member of a material dimension table

Or as an attribute i.e. member of the material master table

Or as a node-describing attribute of the material hierarchy table

Or as any combination of the above options.

Which option best fits individual needs depends primarily on the desired time aspects in yourqueries, and is discussed in chapter 5.

Important

To avoid confusion we emphasize:

In BW the terms characteristic and attribute refer only to the different locations in the

schema. As shown above, even within the same schema material group can occur as acharacteristic in the material dimension table and as an attribute of material in the materialmaster data table.

When no reference is being made to specific schema location (as with the meta data

definition), the term InfoObjects of type characteristic is used.



26/72


1. Master Data Table

In defining an InfoObject of type characteristic you have the following modeling-relevantoptions with respect to the definition of the Master Data Table.

1. Reference Characteristic Assignment

When defining an InfoObject of type characteristic you are asked whether you want to referto an existing other characteristic. If you do, beside others, the new characteristic will havethe master table of the referred characteristic.

For example: the characteristics sending cost center and receiving cost center refer to thesame characteristic 0COSTCENTER and thus the same master tables.

2. Master Table Existence

Does a master data table exist at all? (tab page: Master data -> Check box)

This allows you do add InfoObjects as attributes in the attribute tab page section.

For example, in your schema all attributes of a document number may be assigned to othercharacteristics such as customer or material.

3. Assigning Attributes

The attributes of a characteristic that will reside in its master data table are determined in themodeling phase. The attributes are added using the attributes tab page in InfoObjectmaintenance.

These attributes form the communication structure for the InfoSource to load the master data.

4. Attributes and Querying

Whether an attribute can potentially be used for query navigation (such as drilldown, up,across, or within) on an InfoCube or ODS Object can be individually defined (attribute tabpage-> navigational check boxes). If you mark the navigation check box of an attribute thisattribute is called a navigational attribute.Note: you have to activate the navigational attributes in the InfoCube definition to allownavigation with respect to this InfoCube.In terms of navigation, navigational attributes behave like characteristics in an InfoCube. Butthe reporting behavior of the navigational attributes in master tables differs from thecharacteristics behavior.

Attributes not used for navigation are called display attributes. If an InfoObject of typecharacteristic is an attribute and not marked as a navigational attribute then it is only possibleto report this attribute in conjunction with a characteristic or with a navigational attribute.For attributes of type key figure the following applies:

InfoObjects of type key figure are always display attributes.

If you want to calculate a query with an attribute it has to be an InfoObject of type key

figure.



27/72


5. InfoObject names and names of attributes

It is possible to create schemas that have the same InfoObject for the characteristics in thedimension table of an InfoCube, and for the navigational attribute of another characteristicalso in the InfoCube. To avoid confusion you should give the navigational attribute a namedifferent to its characteristic name. The name is defined in the attribute tab page for each

navigational attribute.For example:The InfoObject MMATERIAL is in the InfoCube while MMATGR is a navigational attributefrom MMATERIAL. Let us assume that MMATGR is a result of a model that is also acharacteristic in the InfoCube. Material group is the name of the InfoObject MMATGR. Ifyou were to use the same name (material group) for the navigational attribute, this wouldoccur twice in the InfoCube description of the query builder, most certainly confusing theend-user.

6. Time Dependent Attributes

Each attribute can be defined individually as being time dependent.

The following example illustrates the different behavior of non-time dependent and timedependent attributes.

Example: non-time dependent attributes:The InfoObject material has the attribute MatType and we are only interested in using thelatest materials - MatTypes constellations within reports.MatType is defined as a non-time dependent attribute (there is no check in the timedependent check box). Let us assume that material BBB has MatType 300 in 09 1998. Anew assignment of MatType 200 to material BBB in 10 1998 would then overwrite theold constellation. The material MatType assignments are stored in the non-time dependentattribute master data table (fig.22):

Material MatType

AAA 100

BBB 200

CCC 100

DDD 100

Non-Time Dependent Attribute Master Data Table

(table name: /BIC/PMaterial)

(figure 22)

Example: Time Dependent Attributes:The InfoObject material has the attribute MatGroup. We are also interested in formermaterials MatGroup constellations. MatGroup is defined as a time dependent attribute(there is a check in the time dependent check box). Let us assume that material BBB hasMatGroup X. Then, from October, 1st 1998 a new assignment of MatGroup Y to materialBBB is valid. The result is a new record in the time dependent attribute master datatable with the respective validity. The old constellation gets only a new date to value(fig.23):



28/72


Material DateFrom DateTo MatGroup

AAA 01 /1000 12 / 1999

X

BBB 01 /1000 09 /1998 X

BBB 10 /1998 12 /9999 Y

CCC 01 /1000 12 /9999 Y

DDD 01 /1000 12/9999 Y

Time Dependent Attribute Master Data Table

(table name: /BIC/QMaterial)

(figure 23)

One important aspect regarding modeling must be emphasized:

Time Dependent Attributes and Querying

During a single query execution only ONE characteristc value time dependent attributevalue constellation can be addressed!Addressing a specific constellation is done via the query key date.The key date is valid for all time dependent attribute assignments that are used in the query.

To summarize the following points:

There is one time dependent check box for each attribute in the attribute tab page

section.

Time dependency of an attribute allows you to keep track on the changes over time of the

relation of the characteristic and the time dependent attribute values.

In terms of technical implementation, two master data tables exist if we have both non-time dependent and time dependent attributes.

One master data table stores all relations to non-time dependent attributes (name of

the table: /BIC/Pinfobjectname) and

One table stores relations to time dependent attributes (name of the table:

/BIC/Qinfobjectname).

The time dependent attributes master data table has additional DATETO and

DATEFROM system attributes. In queries the different constellations are addressed usingthe key date (-> Query properties). The validity attributes are not available for navigation.

Note: The table names of BW business content InfoObjects start with /BI0/ ...A closer look at the reporting possibilities of time dependent attributes is given in chapter 5.

Important

There are no pre-calculated aggregates at time-dependent attribute level!



29/72


7. Compound Attributes

Characteristics may not be unique i.e. another attribute is necessary to allow the data tobe addressed. Example: the InfoObject 0COSTCENTER (cost center) offered from R/3applications is only unique with the InfoObject 0CO_AREA (Controlling Area).

Additional attributes can be defined in the compound tab page section of InfoObject

maintenance.

2. Text Tables

The text table of an InfoObject of type characteristic keeps the descriptions of thecharacteristic values. The existence of a text table and different description types as short,middle and long text descriptions and language dependency can be defined in the master datatab page section.The text table, or better the description attributes, may be defined as time dependent.Transfer rules may be applied during text data load.

3. SID Tables

SID tables play an important role in linking the data warehouse information structures to thesubject-oriented InfoCubes and ODS Objects.

To speed up access to InfoCubes and to allow an InfoCube and ODS-Object independentmaster data layers, each characteristic and attribute is assigned a SID column and their valuesare encoded into 4-byte integer values.Note:The algorithm to determine a SID value works fastest if the characteristic does not exceed thenumerical size of nine as in this case the characteristic values will be the SID. No traditionalSID table has to be accessed as the characteristic or attribute values correspond 1:1 to theirSIDs.

1. InfoObject definition and SID tables

To offer optimal performance with the various schemas with respect to master data access,three different SID tables might be generated.

SID tables with respect to master data:

The traditional SID table, we know from earlier versions, is always generated if anInfoObject is not defined as attribute only (tab page general). This table is used if theaccess to an Infocube or ODS-Object uses a navigational attribute or if the access is via acharacteristic without attributes.

The non-time dependent attribute SID table of a characteristic for access via non-timedependent attributes.

The time dependent attribute SID table of a characteristic for access via timedependent attributes.



30/72


Example:Supposing the InfoObject material has both non-time dependent and time dependentattributes. The activation of this InfoObject generates the following tables (for illustrationpurposes we will use the example from the master table section):

Material master table fornon-time dependent attributes : /BIC/Pmaterial (fig.24)

Materiall

AAA

BBB

CCC

DDD

Non-Time Dependent Attribute MasterData(table name:

Material master table fortime dependent attributes : /BIC/QMaterial (fig.25)

Material DateFrom DateTo MatGroup

AAA 01/1000 12/9999 X

BBB 01/1000 09/1998 X

BBB 10/1998 12/9999 Y

CCC 01/1000 12/9999 Y

DDD 01/1000 12/9999 Y

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

Material SID table (traditional SID table) : /BIC/SMaterial (fig.26)

Material-SID Material

001 AAA

002 BBB

003 CCC

004 DDD

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

Material non-time dependent attribute SID table : /BIC/XMaterial (fig.27)

Material-SID Material MatType-SID

001 AAA 22222

002 BBB 33333

003 CCC 22222

004 DDD 22222

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



31/72


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

Material-SID MatGroup-

001 AAA /1000 12/9999 910

002 BBB /1000 09/1998

002 BBB /1998 12/9999 920

003 /1000 12/9999

004 DD

/1000 12/9999 920

Time Dependent Attribute SID(table name:

(figure 28)

SID Tables Maintenance

All these SID tables are automatically maintained during master data load.SID tables are maintained during InfoCube load if no referential integrity check is enforced(InfoPackage).

InfoCube Access and SID Tables

To get an understanding of the function of these SID tables a simple example is given as tohow the result of a query is evaluated. If we need the following information:

Show me the sales amountfor customers located in 'New York'with material group'X' and Y in the year = '1999'

Let us assume that the material group is a navigational attribute (non-time dependent) of thecharacteristic material in the material master data table and we have no predefined aggregatesat material group level.

How the different material dimension tables operate together to access the InfoCube facttable is shown in the following picture (fig.29, p.29):



32/72


112233

111111222222333333

Dim ID SIDMaterial

Fact tableDimension table

Material not time dependentAttributes SIDtable(Name: /BIC/XMATERIAL)

MaterialNon-timeAttributes SIDtable(Name: /BIC/XMATERIAL)

Material MatGroup

AAACCCDDD

XYY

Material Master table(Name: /BIC/PMATERIAL)

Material Master table(Name: /BIC/PMATERIAL)

112233

10.00012.00025.000

Dim ID Sales

SIDMaterial Material SID MatGroup

AAACCCDDD

111111222222333333

345345678678678678

MatGroupSID MatGroup

XYZ

345678999 MatGroup SIDtable

(Name: /BIC/SMATGROUP)

MatGroup SIDtable(Name: /BIC/SMATGROUP)Not used for Infocube access !

Example: Show me the sales values for material group

Not used in this Example :Traditional Material SID Table: /BIC/SMATERIALTime dependent Material Master Table: /BIC/Q MATERIALMaterial Time dependent Attributes SID Table: /BIC/YMATERIAL

Not used in this Example :Traditional Material SID Table: /BIC/SMATERIALTime dependent Material Master Table: /BIC/QMATERIALMaterial Time dependent Attributes SID Table: /BIC/YMATERIAL

SID Tables for Infocube Access

(figure 29)

The result set for the material groups is then determined in two steps:

Browsing the tables that form the dimensions

Material dimension

Access the traditional material group SID table and select the material

group SIDs (here 345 and 678) formaterial group = 'X' and Y

Access the material non-time dependent attribute SID table with these

material group SIDs and determine the material SID values (here 111,222 and 333).

Access the material dimension table with these material SID values and

determine the material dimension table Dim-Id values (here 1, 2 and3)

Customer dimension: same proceeding

Time dimension: same proceeding

As a result of these three browsing activities, there are a number of key values(material dimension table Dim Ids, customer dimension table Dim-Ids, timedimension table Dim Ids), one from each dimension table affected.

Accessing the fact table

Using the key values (Dim-Ids) determined during browsing, select all records inthe fact table that have these values in the fact table record key.



33/72


We can summarize that in accessing an InfoCube no real value master data tables are used.The following graphic illustrates this (fig.30):

SID Tables and

InfoCube Access

(1) Fact Table(1) Fact Table

(2) Dimension Tables(2) Dimension Tables

(3) time-independent-SID(3) time-independent-SID

(4)(4) time-dependent-SIDtime-dependent-SID

(5) traditional SID(5) traditional SID

11

22

22

22

22 33

55

44

33

5555

55

55

55

55

55

55

33 33

55

55

5555

44

33

55

55

55

55

(figure 30)

2. External Hierarchy Table

In general hierarchies are structures essential to navigation. Having characteristics andattributes in dimension tables and master data tables that are related in a sequence of parent-child relationships indicates, of course, not only hierarchies, but internal hierarchies.The external hierarchies of a characteristic are defined separately from the other master dataand, as mentioned above, are independent of specific InfoCubes. They are therefore calledexternal hierarchies. The different model properties of internal and external hierarchiesin the BW Schema will be discussed in chapter 5.

During the creation of an InfoObject of type characteristic you can define the basicfunctionality of external hierarchies for this InfoObject (Tab page: hierarchies) or

whether they will exist at all.

3. External hierarchy formats

The following external hierarchy formats are possible:

1. Allow versioning and/ or time dependency of the whole external hierarchy structure(date to, date from)



34/72


2. Or (exclusive) allow time dependency for each external hierarchy node (timedependent structure)

With both structure types you can allow intervals for the leave nodes, which makes thedefinition of the external hierarchy easier.

Important

In terms of performance, it is important to know that with external hierarchies of type 1pre-calculated aggregates are possible at each level, even for specific node values.

With external hierarchies of type 2 there are no pre-calculated aggregates.

4. Tables for external hierarchies

The activation of the InfoObject material results in the creation of the following tables:

Material hierarchy table : : /BIC/HMaterial

Material hierarchy SID table : : /BIC/KMaterial

Material SID-structure hierarchy table : : /BIC/IMaterial

5. Loading external hierarchy data

External hierarchies can be transferred into BW directly from an SAP product environment(e.g. standard cost center hierarchy from R/3), defined manually in BW or loaded via flat file.The latter is discussed in a separate paper.

6. External hierarchies and InfoCube access

BW allows you to determine multiple external hierarchies for a characteristic. Externalhierarchies can be used for characteristics in the dimension tables and for activatednavigational attributes for query navigation.

Example:Consider a simple external hierarchy for the characteristic country. Country is a memberof the customer dimension table but it could instead, or additionally, be a navigationalattribute in the customer master data table. The nodes are of a textual nature. If continentwas an InfoObject of type characteristic we could use this InfoObject to define the nodesusing its characteristic values like Europe (fig.31):

World

Europe

Germany

Austria

Switzerland

America

USA

Canada

Japan

-3

-2

3

4

5

-1

1

2

6*

Country Hierarchy

* Set Ids only shown for better understanding

(figure 31)



35/72


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

SID Table: Nodes

Nodes

America

Europe

World

SID

-1

-2

-3

Child

-2

-1

66

33

44

55

11

22

Parent

-3

-3

-3-2

-2

-2

-1

-1

Inclusion Table:

Country

SID

6

34

5

1

2

SID Table:

Country

Country

Japan

GermanyAustria

Switz.

USA

Canada


DIM-ID

11

22

33

44

55

66

77

Cust-SID

1711

1712

2711

3711

4711

5711

6711

Country-SID

11

11

22

33

44

55

66

Text &

Rep. Attributes

Text &

Rep. Attributes

Fact

Table

(figure 32)

A node of a hierarchy can either be textual or it can be an InfoObject with a specified valuee.g. InfoObject material group with value X. All display attributes of the InfoObjectmaterial group are associated with this node.

The use of InfoCube-independent hierarchy tables is an additional prerequisite for anenterprise-wide data warehouse as the hierarchy table for a characteristic only exists once.Multiple InfoCubes sharing the same characteristic in a dimension table access the samehierarchy table. This is another architectural aspect that accommodates data integration.

4. Dimension tables of an InfoCube

1. Defining dimension tables

In defining an InfoCube you select all the InfoObjects of type characteristic that will bedirect members of this InfoCube. After this you define your dimensions and assign theselected characteristics to a dimension.

Important

BW does not force you to only assign related characteristics to the same dimension table,offering you additional schema potential. Nevertheless, as a basic rule you should only

put characteristics that have a parent-child relationship in the same dimension.

The activation of the InfoCube then results (with one exception which we will discuss later)in the generation of an InfoCube dimension table for each dimension.



36/72


2. Columns of a dimension table

The columns of a dimension table are not the characteristics themselves but the SIDs of thecharacteristics you have chosen to be members of the InfoCube dimension (table). Theunique key of a dimension table is the dimension ID (DIM-ID), that is a surrogate key(integer 4) (fig.33).


DIM-ID

11

22

33

44

55

66

77

Cust-SID

1711

1712

2711

3711

4711

5711

6711

Country-SID

11

11

22

33

44

55

66

(figure 33)

In the BW schema a surrogate key is used as a unique key with each dimension table andnot the real most granular characteristic within the dimension. For example, for eachunique combination of SID values for the different characteristics within a dimensiontable there is a unique surrogate key value assigned. The dimension tables are joined tothe fact table using surrogate keys in BW.

Important

The use of a surrogate key as a unique key in a dimension table allows modeling patternssuch as N:M relationships within the same dimension or leafless hierarchies, and most

importantly, it allows you to follow up changes of constellations between values of

different characteristics within the same dimension over time (time rows). This will bediscussed in depth in chapter 5.

3. Limitations

An InfoCube allows

16 dimensions

3 dimensions exist with each InfoCube (whether they are used and thus visible ornot)

Time dimension

Unit/ currency dimension

Packet dimension

The remaining 13 dimensions are for individual schema design

Each dimension table may be up to 248 characteristics.



37/72


Important

It should be noted that in wider usage each attribute / characteristic is sometimes called

a dimension. This a potential point of misunderstanding as then saying that the BW

schema has 16 dimensions, three of which are used internally, may sound very limited.

According to this definition of a dimension there are 13 X 248 dimensions possible withBW plus the dimensions defined by the navigational attributes.

4. Dimensions and navigation

All characteristics assigned to dimension tables can be used for navigation (drilling) andfiltering within queries. Navigation with navigational attributes of InfoCubecharacteristics has to be explicitly switched on for each navigational attribute (Tab page:navigation).

The activation of a navigational attribute for an InfoCube can be done afterwards.Deactivation of navigational attributes is not possible!

5. Loading data into dimension tables

Dimension tables are maintained during InfoCube load.

6. Special BW dimensions

With BW we have special predefined dimensions:

Time dimension

Unit/ currency dimension

Packet dimension

1. Packet dimension

With every load into an InfoCube there is a unique packet-ID assigned. This allows you topurge erroneous loads without recreating the whole InfoCube again. The packet dimensioncan increase overheads during querying and can therefore be eliminated using the compressfeature of the InfoCube after proven correctness of the loads up to a certain packet-ID.

2. Unit/ Currency Dimension

The respective dimension table is generated if the key figures selected in the InfoCube are oftype amount or quantity.

Important

If you are not interested in unit or currency calculations you should define the key figuresas numbers and then introduce the unit in the key figure header (i.e. sales in HL). This

will reduce overheads.



38/72


7. Dimensions with only one characteristic (line item dimensions)

It is very often possible in this model to assign only one characteristic to a dimension.This will probably occur with specific reporting requirements or if for example you have thedocument line item in your model (see chapter 5 for all scenarios except no.3).In these situations a dimension table means only overhead. BW allows you define this kind

of dimension as a line item dimension (Check box dimension definition).In doing this no dimension table will be generated for this dimension. A dimension table willserve the SID table of this characteristic. The key in the fact table will be the SID of the SIDTable (fig.34).Line item dimension:

Line-Item

Dimension

(1) Fact Table(1) Fact Table

(2) Dimension Tables(2) Dimension Tables

(3) time-independent-SID(3) time-independent-SID

(4)(4) time-dependent-SIDtime-dependent-SID

(5) traditional SID(5) traditional SID

11

22

22

22 33

55

44

33

5555

55

55

55

55

55

55

33 335555

5555

33

55

55

(figure 34)



39/72


4. Fact tableThe fact table is created during InfoCube activation. The structure of the fact table in the BWschema is the same as it is in the normal Star schema. The keys of the dimension tables (i.e.the dim-IDs) or the SIDs of line item dimensions are the foreign keys in the fact table. The

non-key columns are defined by the selected key figures during InfoCube definition.

Each row in the fact table is uniquely identified by a value combination of the respectiveDIM IDs/ SIDs of the dimension/ SID Tables

Since the BW uses system-assigned surrogate keys, namely DIM IDs or SIDs of 4 bytesin length per dimension to link the dimension / SID tables to the fact table, there willnormally be a decrease in space requirements for keys in comparison to the use of realcharacteristic values for keys.

The dimension / master (SID) tables should be relatively small with respect to the numberof rows in comparison to the fact table (factor 1:10 / 20).

1. Multiple fact tables

Each InfoCube has two fact tables:The F-fact table, which is optimized for loading data, and the E-fact table, which isoptimized for retrieving data (fig.35).

Multiple

Fact Tables

(F) F-Fact Table Requid(F) F-Fact Table Request > 0

(E) E-Fact Table Requid(E) E-Fact Table Request = 0

(2) Dimension(2) Dimension

(3) time-independent-


(4)(4)time-dependent-

time-dependent-

(5) traditional(5) traditional

22

22

5555

22 33

55

44

33

55

55

55

55

55

55

33 33

55

55

5555

33

55

55

E

F

(figure 35)



40/72


Both fact tables have the same columns. The F-table uses b-tree indexes the E-Table usesbitmap indexes except for line item dimensions where a b-tree index is used.The InfoCube compression feature moves the fact records of all selected requests from the F-to the E-fact table. In doing so the request-ID of each fact record is set to zero.The separation into two fact tables is fully transparent.

2. Fact table partitioning

BW supports the partitioning of fact tables.Partitioning is a database feature and in short means that one table is split internally intoseveral tables, its partitions. Partitions of a table have their own index areas that are thereforesmaller areas than the entire table would have. Together with the possibility of internallysplitting a normally sequential request on the entire table into several parallel requests firedon different partitions, this can speed up a query significantly.Partitioning is fully transparent.To partition a table you have to define criteria that allow the database engine to decide where

a specific record has to be loaded and where it will be found afterwards.In BW the fact table can be either partitioned by the InfoObject 0CALMONTH i.e. calendaryear and month, or by 0FISCPER i.e. fiscal year and period (fig.36).

PartitioningFact Tables

(F) F-Fact Table Requid(F) F-Fact Table Request>

(E) E-Fact Table Requid(E) E-Fact Table Request =

(2) Dimension(2) Dimension



(4)(4)time-dependent-

time-dependent-

(5) traditional(5) traditional

5555

22 33

55

44

33

55

55

55

55

55

55

33 33

33

55

55

PackeDimensio

TimeDimensio

E

F

(figure 36)



41/72


Together with the entire value range for the partitioning InfoObject that you would expectand the optional maximal number of partitions, the value range for each partition isdetermined.Note: Partitioning is a database functionality. Have a look at the OSS to find out how and towhat extent your database provider supports partitioning!

For example:Let us assume we want to partition a fact table using 0CALMONTH. We want tohave data in our fact table starting from 199901. Let us further assume that weexpect a lifespan of our InfoCube up until 201012. Without specifying a maximumvalue for the partitions we would have

11 years x 12 month + 2 = 134 partitions

The additional 2 partitions are reserved for data which have a 0CALMONTH valueless or larger than our expected values.To bring in 1 quarter in each partition we proceed as follows :

134 Partition / 4 = 33,5 => maximum = 34

Important

Partitioning for a fact table has to be defined before you activate the InfoCube. It cannot

be done afterwards!

Fact table partitioning as described above only affects E-fact tables. F-fact tables are

automatically partitioned by the request-ID. For this and other reasons do not forget tocompress your InfoCube on a regular base!

3. BWTerminologyThe following picture shows differences in the terminology (fig.37):

MDM / Star Schema BW Schema

Fact

Fact Table

Characteristic /

Navigational Attribute/

Display Attribute /

(external) Hierarchy

NodeDimension Table /

Master Table /

Text Table /

External Hierarchy

Table /

(SID Table)

Dimension (Table)

(Dimension) Attribute

Fact Table

Key Figure

(figure 37)



42/72


ImportantIt should again be noted that generally attributes/ characteristics are sometimes calleddimensions. This a potential point of misunderstanding as saying that the BW Schema offers16 dimensions, three of which are used internally, sounds very limited. Using this definitionof a dimension there are actually 13 X 248 dimensions possible with BW plus the dimensions

defined by the navigational attributes.

4. Modeling issues and the BW schema

We will now look at the various important modeling issues from a topic-based perspective.Explaining how to implement these issues with BW will improve understanding of the BWschema.Trying to map real world processes, the following graphic illustrates the competition ofdifferent interests that always arise during the design phase. This explains why even some ofthe following modeling recommendations contradict each other. A good design will alwaysbe a compromise.

We will therefore also leave out the impacts of modeling, especially on performance and viceversa (although please have also have a look at the accelerator Sizing and Performance)(fig.38).

PerformancePerformance

AspectsAspects

GlobalGlobal

Data WarehouseData Warehouse

DesignDesign AspectsAspects

AnalysisAnalysis

AspectsAspects

Competition in Data Warehousing

(figure 38)



43/72


5. Granularity

An important result of the data modeling phase is that the granularity (the level of detail ofyour data) is determined. Granularity deeply influences

Reporting capabilities

Performance Space needed

Load TimeYou have to decide whether you really need to store detailed data in an InfoCube or whetherit is better in an ODS object or even not stored in your data warehouse at all, but accesseddirectly from your Source system via drill thru.These decisions are decisions that do not only influence your current scope, but the entireapproach to and architecture of your data warehouse.This topic is discussed in a special paper.

1. Fact tables and granularity

Volume is a concern with fact tables. How can the number of rows of data in a fact table beestimated? Consider the following:

How long will the data be stored in the fact table?

How granular will the data be?The first is fairly straightforward. However, the granularity of the information has a largeimpact on querying efficiency and overall storage requirements. The granularity of the facttable is directly impacted by dimension table design as the most atomic characteristic in eachdimension determines the granularity of the fact table. For example, let us assume we need toanalyze the performance of outlets and articles. Attributes exist which describe:

Outlet

Receipts

Articles

Customers

Time

Let us limit our analysis to articles and time, and further assume that 1,000 articles aregrouped by 10 article groups. To track the article group performance on a weekly basis:

Granularity: article group, week, and 300 sales days a year (45 weeks)10 X 45 = 450 records in the fact table per year due to only these two attributes if allarticles are sold within a week

Granularity: article, week, 300 sales days a year (45 weeks)1,000 X 45 = 45,000 records in the fact table per year due to only these two attributesif all articles are sold within a week

Granularity: article, day, 300 sales days a year1,000 X 300 = 300,000 records in the fact table per year due to only these twoattributes if all articles are sold within a day



44/72


Granularity: article, hour, 300 sales days a year, 12 sales hours a day500 X 300 X 12 = 1,800,000 records in the fact table per year due to only these twoattributes if on average 500 articles are sold within an hour

Finally, assuming 500 outlets, there will be 900,000,000 records a year in the fact table.

2. Impacts on StorageQuite obviously granularity directly impacts the storage space needed. As it stores thetransaction data, the fact table is the largest table in the InfoCube. Therefore, estimating thesize of the fact table provides a rough idea of the space required for the InfoCube.For each dimension table a four-byte integer DIM ID (dimension ID) is used, in conjunctionwith the other DIM IDs, to point to the associated row of data in the fact table. In addition,the length of all the key figures in the fact table must be considered:

((Number of DIM IDs) * 4 + (total length of all key figures)) * number of records

ImportantRemember the three dimensions required are time, unit, and packet.

3. Impacts on Performance

Large fact tables impact on reporting and analysis. Apart from hardware considerations, thereare a few additional considerations to bear in mind.

AggregationFor large fact tables consider the use of pre-calculated aggregates. For implications,such as an increase in the storage space required, see earlier sections of this paper.

PartitioningPartition the fact table. The option exists to divide a table with respect to the values ofa specific attribute, into several physical tables. This process is transparent to the user.

This technique is useful with large fact tables because it provides access via smallerindexes.

4. Location of dependent attributes in the BW schema

The BW schema offers more than one possible location for dependent (parent) attributes.Where to put dependent attributes in the BW schema is one of the decisive results of theprojects blueprint phase.



45/72


Parent Attributes in BW (fig.39)

Material

Material Dimension

Materialgroup

Material

Dimension table

As a CharacteristicAs a Characteristic??Material

Master table

As a NavigationalAs a Navigational//

DisplayDisplayAttributeAttribute ??

Material

Hierarchy tableAs a HierarchyAs a Hierarchy??

(figure 39)

The freedom to choose between the different locations of dependent attributes is actuallyrestricted as the reporting behavior and possibilities differ and depend upon the location.Thus the reporting needs investigated during the blueprint phase of the project normallydefine the location of a dependent attribute. This is discussed in detail in the followingchapters.

5. Performance and location of dependent attributesThe reporting needs should guide you in the deciding

asap multi dimensional modeling

Documents