Multi-Dimensional Modeling En

8/6/2019 Multi-Dimensional Modeling En

1/73

Multi-Dimensional Modelingwith BWASAP FOR BW A CCELERATORBUSINESS I NFORMATION 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/73

MULTI -DIMENSIONAL MODELING WITH BW

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

ASAP FOR BW A CCELERATOR .........................................................................................................................1

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

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

1. S OFTWARE VERSION SUPPORTED ......................................................................................................................12. R EFERENCES .................................................................................................................................................13. O VERVIEW ....................................................................................................................................................1

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

1. T HE GOALS OF MULTI -DIMENSIONAL DATA MODELS .............................................................................................52. S UBJECT AREA..............................................................................................................................................53. T HE ROLE OF BW B USINESS CONTENT .............................................................................................................54. B ASIC MODELING STEPS ...............................................................................................................................6

1. Step 1: Develop a complete understanding of the underlying business processes............................ ..7 1. Entities and the relations between them...........................................................................................................72. Reaping benefits of BWs Business Content....................................................................................................93. Step 2: Create a valid Schema........................................................................................................................104. The Multi-Dimensional Model (MDM).........................................................................................................105. The Star Schema............................................................................................................................................106. Step 3: Create an InfoCube Description ........................................................................................................137. Resume..........................................................................................................................................................14

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

1. H OW THE STAR SCHEMA WORKS ..................................................................................................................152. S TAR SCHEMA ISSUES ..................................................................................................................................16

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

1. O VERVIEW .................................................................................................................................................182. C ONNECTING MASTER TABLES TO I NFOCUBES .................................................................................................203. D IMENSIONS IN A BW SCHEMA ....................................................................................................................21

1. Master Data Table..............................................................................................................................241. Reference Characteristic Assignment.............................................................................................................242. Master Table Existence..................................................................................................................................243. Assigning Attributes.......................................................................................................................................244. Attributes and Querying.................................................................................................................................245. InfoObject names and names of attributes......................................................................................................256. Time Dependent Attributes............................................................................................................................257. Compound Attributes.....................................................................................................................................27

2. Text Tables....................................................................................................................................... ...27 3. SID Tables...........................................................................................................................................27

1. InfoObject definition and SID tables..............................................................................................................27(figure 28).........................................................................................................................................................29SID Tables Maintenance...................................................................................................................................29InfoCube Access and SID Tables......................................................................................................................29

2. External Hierarchy Table...............................................................................................................................313. External hierarchy formats.............................................................................................................................314. Tables for external hierarchies.......................................................................................................................325. Loading external hierarchy data.....................................................................................................................326. External hierarchies and InfoCube access......................................................................................................32

4. Dimension tables of an InfoCube........................................................................................................331. Defining dimension tables..............................................................................................................................332. Columns of a dimension table........................................................................................................................333. Limitations.....................................................................................................................................................344. Dimensions and navigation............................................................................................................................35

5. Loading data into dimension tables................................................................................................................356. Special BW dimensions.................................................................................................................................351. Packet dimension.......................................................................................................................................35


3/73


2. Unit/ Currency Dimension.........................................................................................................................357. Dimensions with only one characteristic (line item dimensions)....................................................................35

4. F ACT TABLE ................................................................................................................................................371. Multiple fact tables.............................................................................................................................37 2. Fact table partitioning........................................................................................................................383. BW Terminology ................................................................................................................... ........ ....39

4. Modeling issues and the BW schema..................................................................................................405. G RANULARITY ............................................................................................................................................411. Fact tables and granularity................................................................................................................412. Impacts on Storage.............................................................................................................................423. Impacts on Performance ....................................................................................................................424. Location of dependent attributes in the BW schema...........................................................................425. Performance and location of dependent attributes ............................................................................436. Enterprise data warehouse and location of dependent attributes .....................................................437. Data load and the location of dependent attributes............................................................................448. Tracking history in the BW schema....................................................................................................449. History and InfoCube..........................................................................................................................4410. Slowly Changing Dimensions...........................................................................................................45

1. Scenario I: Report the data to todays constellation - today is yesterday........................................................47

1. Scenario I: Description..............................................................................................................................472. Report the data to yesterdays constellation as well -yesterday is today ........................................................501. Scenario II : Description............................................................................................................................50Scenario II: Solutions with BW....................................................................................................................51

Scenario III: Report the data to the respective constellation-today or yesterday-..............................................532. Scenario III: Description............................................................................................................................53Scenario III: Solution with BW................. ............. ............. ............. ............. ............. ............. ............. ........54

3. Scenario IV: Description............................................................................................................................5511. Usage of time scenarios ...................................................................................................................5812. M:N relationships.............................................................................................................................5913. M:N relationships and the fact table................................................................................................5914. M:N relationships within a dimension .............................................................................................59

1. Designing M:N relationships using the dimension table.................................................................................592. Designing M:N relationships using a compound attribute..............................................................................60

3. Frequently Changing Attributes (Status Attributes)........................................................................................604. Inflation of dimensions...................................................................................................................................615. Multiple process reporting scenarios..............................................................................................................616. MultiCubes.....................................................................................................................................................62

15. Partitioning Attributes .....................................................................................................................651. Attribute or fact (key figure)..........................................................................................................................66

6. T HIS WOULD ALLOW NAVIGATION ON PRICES USING EXTERNAL HIERARCHIES . ........................................................677. S AME CHARACTERISTIC SEVERAL TIMES IN THE MODEL :......................................................................................678. A RTIFICIAL KEY FIGURES ...............................................................................................................................67

1. Factless fact tables..............................................................................................................................67 2. Counting..............................................................................................................................................67

9. B IG DIMENSIONS ..........................................................................................................................................671. Hierarchies in the BW schema............................................................................................................682. Hierarchies within a Dimension.........................................................................................................683. Hierarchies within a master data table of a characteristic................................................................694. External Hierarchies...........................................................................................................................69


4/73


IntroductionThis 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

Whitepaper and to the paper Hierachies 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 or InfoCubes. 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 solutions

based on a blueprint for an enterprise-wide data warehouse.

2000 SAP AG AND SAP A MERICA , INC . 1


5/73


BW Information Integration Architecture

SAPSAPR/3R/3APOAPOCRMCRMBBPBBP

LegacyLegacy

ExternalExternalProviderProvider

E x

t r a c

t i o n

Master DataMaster Data

PSAPersistent Staging Area

SourceSystems

ETL Tools

Meta Data

PSAPSA

BW Operational Data StoreBW Operational Data Store

InfoCubesInfoCubes

B u s

i n e s s

R u

l e s

BW ODSBW Operational Data Store

InfoCubes

C l e a n s

i n g

& T r a n s

f o r m a

t i o n

End-UserData Access

Ad HocAd HocQueriesQueries

ReportingReporting ApplicationsApplications ModelsModels

B u s

i n e s s

R u

l e s

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 asdrilldown 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 ODS Whitepaper .

The focus of this paper is how to support Online Analytical Processing (OLAP) in BW.OLAP functionality is one of the major requirements in data warehousing. In short, 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 moredetailed level.



6/73


BW Information Access Architecture

LegacyLegacy

ExternalExternalProviderProvider

Master DataMaster Data

ETL Tools

Meta Data

PSAPSA

BW Operational Data StoreBW Operational Data Store

InfoCubesInfoCubes

SchedulingScheduling MonitoringMonitoring ChangeChangeManagementManagement

ServiceServiceManagementManagement

BWBusiness Explorer WebGraphical User Interf

SAP-ModelsAdvanced PlanningEnterprise MangemCRM

Third Party Tools

(ODBC/ ODBO)

SAPSAPR/3R/3APOAPOCRMCRMBBPBBP

PSAPersistent Staging Area

SourceSystems

BW ODSBW Operational Data Store

InfoCubes End-UserData Access

(figure 02)

A simple example:

Sales Organisation Product Organisation Time KPIsSales 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.



7/73


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



8/73


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 normalunderstanding 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 (theOLAP 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 Star schema approach and extends it to support integration within the data warehouse, to offer easy handling and allow high performance solutions.

2. Subject AreaAs 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 offered

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



9/73


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

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 information2.2. Focus on analytical needs - Overcome model complexityFocus on analytical needs - Overcome model complexity

Create a valid schemaTranslate the ERM to the MDM / Star schema

The MDM as a function of the analytical processing3.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 InfoCubesTranslate the MDM / Star schema to one or more InfoCube schemas

Sales Rep ID

LastNameSalesDep

Material ID

Material NameMaterial TypeMaterial Group

Customer ID

Customer NameCityRegionOffice Name

Time Code ID

Year Fiscal Year Quater MounthDay of the Week

Material ID

Sales Rep IDTime Code IDCustomer ID

Sales AmountQuantityUnit Price

Time DimensionCustomer Dimension

Sales Org DimensionMaterial Dimension

FACT

Material DIM IDOrgStr DIM IDTime Code ID....

Quantity.....

SalesRep ID

Last Name...

Material DIM ID

Material IDMatType

Material ID

Mat.descriptionMatType...

OrgStr. DIM ID

SalesRepSalesDep

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)



10/73


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

In this step we focus on the structure structure of information:

1. Entities and the relations between them

There are no strict rules on how to develop a complete understanding of the underlying business process. Nevertheless using an Entity Relationship Model (ERM) is a good way of seeing the relevant business objects and their relationships. Depending on the particular circumstances and the extent of personal experience, it will sometimes be sufficient just 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 of introducing basic terms.

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

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

The following nouns relate to the end-users information needs: Material Customer Sales Person

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

Customer Material Sales Person

(figure 04)

Ask the end-user about the relationship between his basic business terms (strong entities). Normally the relationship between strong entities are N:M Relationships i.e. a customer can purchase multiple materials and materials can be purchased by multiple customers (seefig.05):

Customer Material Sales Person

(figure 05)

Ask the end-user how performance is measured.



11/73


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 that additional details for material, customer and sales person are also required.This gives you additional entities and attributes where attributes are the describing fields of an entity. In ERM diagrams attributes show the fields in relational tables.

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

It is useful for the following steps to ask the end-user for details concerning 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).



12/73


Customer

Material Sales Person

Material group Sales Department

Customer noCustomer nameCity Region

Material noMaterial nameMaterial typecolor

price

Material group noMaterial group name....

Sales TransactionDateCustomer noMaterial noSales pers no

Amount Quantity Currency

Sales pers. noSales pers. name.......

Sales dep. noSales 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.



13/73


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

LastNameSalesDep

Material ID


Customer ID


Time Code ID


Material IDSales Rep IDTime Code ID

Customer IDSales AmountQuantityUnit Price



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, or attributes.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 SchemaThe Star schema offers comprehensibility for software. The Star schema is the most

popular way of implementing a Multi-Dimensional Model in a relational database.Snowflake schemas are an alternative solution although BW InfoCubes are based on a Star schema, and a short introduction to its main terms and capabilities will now be given here.



14/73


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

LastNameSalesDep

Material IDMaterial ID


Customer Customer IDID

Customer NameCity

RegionOffice Name

Time Code IDTime Code ID

Year Fiscal Year

Quater MounthDay of the Week

Material IDMaterial IDSales RepSales Rep IDIDTime Code IDTime Code IDCustomer Customer IDID

Sales AmountQuantity

TimeDimension

(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, suchas 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 associateddimension tables The points of the star are dimension tables Dimension tables store both attributes about the data stored in the fact tableand textual data Dimension tables are de-normalized The most atomic dimension attributes in the dimensions define thegranularity of the information, i.e. the number of records in the fact table



15/73


The Fact Table (fig.12) :

Customer Customer StreetStreet SalesPersSalesPers SalesRegionSalesRegion MaterialMaterial UnitUnit DateDateDate

Customer SalesPers Material Date Amount Quantity

Ides G mbh 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

LastNameSalesDep

Material ID


Customer ID


Time Code ID


Material IDSales Rep IDTime Code IDCustomer IDSales AmountQuantityUnit Price



FACT ??

Customer

City

Region

Material Group

Sales order

Price

Sales Person

Sales Dept.

Sales Dept. Loc.

Material

Material TypeColor

(figure 13)



16/73


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 DescriptionBuild 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):



17/73


Translate the MDM/ Star Schema into an InfoCube Description:

Sales Rep ID

LastNameSalesDep

Material ID


Customer ID


Time Code ID


Material IDSales Rep IDTime Code IDCustomer ID

Sales AmountQuantityUnit Price



FACT

MDM/ Star Schema

SAP BW

Material DIM IDOrgStr DIM IDTime Code ID....Quantity.....

SalesRep ID

Last Name...

Material DIM ID

Material IDMatType

Material ID

Mat.descriptionMatType...

OrgStr. DIM ID

SalesRepSalesDep

SalesDep ID

Address...

(figure 14)

7. ResumeIn his book The Data Warehouse Toolkit, Ralph Kimball writes:The nine database design decision points for a dimensional data warehouse consist of deciding on the following:

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

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

attributes and entities )4. The grain of each fact 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)



18/73


Star Schema Basics and Modeling IssuesIn the previous chapter we introduced the Star schema. As most of the relevant properties for modeling derive directly from these schemas, we will now have a closer look to them. Westart with the Star schema as it is the force behind the BW schema and is also easier tounderstand. 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 WorksHow 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 materialgroup 'XXX' in the year = '1997'

Star Schema

Sales RepSales Rep IDID

LastNameSalesDep

Material IDMaterial ID


Customer Customer IDID


Time Code IDTime Code ID


Material IDMaterial IDSales RepSales Rep IDIDTime Code IDTime Code IDCustomer Customer IDID


TimeDimension

(Table)

Customer Dimension

(Table)

Sales Org Dimension

(Table)Material

Dimension(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 withMaterial group = 'XXX' Access the Time Dimension Table and select all records with Year ='1997'

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



19/73


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 Customer 4711 purchase Material BBB 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 100DDD 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 recordto 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 recordin fact table

Star-II. The role of dimension tables There are also changes between the attribute values of attributes within the samedimension (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.



20/73


Reporting

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

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

reporting the revenue for the customers in New York within a certain time spanwould show the customers that have revenue, but not the customers that have norevenue).

Aggregation

Star-V. Only the information at the granularity of the dimension table keys (materialID, 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 aggregateddata, but with large ( number of rows) fact tables and / or large dimension tables,

pre-calculated aggregates must be introduced for performance reasons.Attribute Relationships (Hierarchies)

In the Star schema there is one (real) attribute (most granular) as the uniqueidentifier of each dimension table row joining the fact table. The other attributes of a dimension table are normally parents of such identifying attributes, thus the 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 lowestlevel, it is not possible to put both material and material color into one normal star dimension table, as we would have one material value associated with 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 hierarchiesVery 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 will

produce reports with dummy hierarchy tree nodes.

Table Sizes and Performance



21/73


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 theschema is caused by properties of relational databases.

Multi-Dimensional Schemas in BWBased on experience with the Star schema, the SAP BW schema uses a more sophisticatedapproach 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 in

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



22/73


FACT Table

G e b i e t 1G e b i e t 2G e b i 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 e t 4G e b i e 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 i e t 7G e b i e 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

Material Group

Material Hierarchy TableMaterial_Dimension_IDSalesOrg_Dimension_IDTime_Dimension_IDCustomer_Dimension_ID


Material Number Language Code


Material Name

Material Text TableMaterial_Dimension_IDMaterial Number


Material Master Table

Material Number Material Number

Material Type

SalesRep Master Table

SalesRep Number SalesRep 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 Number Customer Number

City

RegionTime_Dimension_ID

Year Quater MounthDay

Time Dimension Table

SalesOrg_Dimension_IDSales Rep Number

SalesOrg SalesOrg DimensionDimension TableTable

Customer_Dimension_ID

Customer Number

Customer Dimension Table

CustomerCustomer DimensionDimension

InfoCubeInfoCube

TimeTime DimensionDimension

MaterialMaterialDimensionDimension

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 TableIn 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 calledterminology attributes (e.g. material type).

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



23/73


External Hierarchy TablesHierarchies 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).

ImportantThe use of the term hierarchy in BW is a possible point of confusion. Thenormal 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):



24/73


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

DimensionTable

Text

SID Tables

Master

Hierarchies

DimensionTable

DimensionTable

DimensionTable

DimensionTable

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 prior analysis:

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):



25/73


G e i t 1G e i tG e i t

B e z i r k 1

G e i t

B e z i r k

R e i 1

G e i t 4G e i t

B e z i r k

R e i

G e i t

B e z i r k 4

G e i tG e i t

B e z i r k

R e i

V e r t r i s r i s t i

Material Group

Material Hierarchy Table



Material Name

Material Text TableMaterial_Dimension_ID

Material Number


Material Master Table

Material Number Material Number

Material Type

MaterialMaterialDimensionDimension

(figure 20)

We emphasize that:Dimensions in a BW schemaThe 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

MaterialDimension table

As a Characteristic As a Characteristic ? ? MaterialMaster table

As a Navigational As a Navigational / / Display Display Attribute Attribute ? ?

MaterialHierarchy table

As a Hierarchy As a Hierarchy ? ?



26/73


(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 your queries, and is discussed in chapter 5.

Important

To avoid confusion we emphasize:

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

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

When no reference is being made to specific schema location (as with the meta datadefinition), the term InfoObjects of type characteristic is used.



27/73


1. Master Data TableIn 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 refer to 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 other characteristics such as customer or material.

3. Assigning Attributes

The attributes of a characteristic that will reside in its master data table are determined in 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 QueryingWhether an attribute can potentially be used for query navigation (such as drilldown, up,across, or within) on an InfoCube or ODS Object can be individually defined (attribute tab

page-> navigational check boxes). If you mark the navigation check box of an attribute 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.



28/73


5. InfoObject names and names of attributesIt 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. If you 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 AttributesEach 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 former materials MatGroup constellations. MatGroup is defined as a time dependent attribute(there is a check in the time dependent check box). Let us assume that material BBB hasMatGroup X. Then, from October, 1 st 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):



29/73


Material DateFrom DateTo MatGroup

AAA 01 / 1000 12 / 1999

X

BBB 01 / 1000 09 / 1998 X

BBB 10 / 1998 12 / 9999 YCCC 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 pagesection.

Time dependency of an attribute allows you to keep track on the changes over time of therelation 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/ P infobjectname) and One table stores relations to time dependent attributes (name of the table:/BIC/ Q infobjectname).

The time dependent attributes master data table has additional DATETO andDATEFROM 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!



30/73


7. Compound Attributes

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

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

2. Text TablesThe 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 their SIDs.

1. InfoObject definition and SID tables

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

SID tables with respect to master data:

The traditional SID table, we know from earlier versions, is always generated if 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.



31/73


Example:Supposing the InfoObject material has both non-time dependent and time dependentattributes. The activation of this InfoObject generates the following tables (for illustration

purposes we will use the example from the master table section):

Material master table for non-time dependent attributes : /BIC/P material (fig.24)

Materia l l AAABBBCCCDDD

Non-Time Dependent Attribute Master Data(table name:

Material master table for time dependent attributes : /BIC/Q Material (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/S Material (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/X Material (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)



32/73


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

Material-SID MatGroup - 001 AAA / 1000 12 / 9999 910

002 BBB / 1000 09 / 1998 002 BBB / 1998 12 / 9999 920003 / 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 amount for customers located in 'New York' with material group'X' and Y in the year = '1999'

Let us assume that the material group is a navigational attribute (non-time dependent) of 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):



33/73


1 1 2 2 3 3

111 111 222 222 333 333

Dim ID SID Material

Fact table Dimension table

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

Material Non-timeAttributes SID table (Name: /BIC/XMATERIAL)

Material MatGroup

AAA CCC DDD

X Y Y

Material Master table (Name: /BIC/PMATERIAL)

Material Master table (Name: /BIC/PMATERIAL)

1 1 2 2 3 3

10.000 12.000 25.000

Dim ID Sales

SID Material Material SID MatGroup

AAA CCC DDD

111 111 222 222 333 333

345 345 678 678 678 678

MatGroup SID MatGroup

X Y Z

345 678 999 MatGroup SID table

(Name: /BIC/SMATGROUP) MatGroup SID table (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 T able: /BIC/S MATERIAL Time dependent Material Master T able: /BIC/Q MATERIAL Material Time dependent Attributes SID T able: /BIC/Y MATERIAL

Not used in this Example : Traditional Material SID T able: /BIC/S MATERIAL Time dependent Material Master Table: /BIC/Q MATERIAL Material Time dependent Attributes SID T able: /BIC/Y MATERIAL

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 thematerial group SIDs (here 345 and 678) for material group = 'X' andY Access the material non-time dependent attribute SID table with thesematerial group SIDs and determine the material SID values (here 111,222 and 333). Access the material dimension table with these material SID valuesand determine the material dimension table Dim-Id values (here 1, 2and 3)

Customer dimension: same proceeding

Time dimension: same proceedingAs 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 tableUsing the key values (Dim-Ids) determined during browsing, select all records inthe fact table that have these values in the fact table record key.



34/73


35/73


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 1 pre-calculated aggregates are possible at each level, even for specific node values.

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

4. Tables for external hierarchiesThe activation of the InfoObject material results in the creation of the following tables:

Material hierarchy table : : /BIC/H MaterialMaterial hierarchy SID table : : /BIC/K MaterialMaterial SID-structure hierarchy table : : /BIC/I Material

5. Loading external hierarchy dataExternal 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.

6. External hierarchies and InfoCube accessBW 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 member of 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

GermanyAustriaSwitzerland

America

USACanada

Japan

-3

-2

345

-1

12

6*

Country Hierarchy

* Set Ids only shown for better understanding

(figure 31)

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



36/73


SID Table: Nodes

Nodes

America

Europe

World

SID

-1

-2

-3

Child

-2-1 663344551122

Parent

-3-3-3-2-2-2-1-1

Inclusion Table:Country

SID

634

512

SID Table:Country

Country

JapanGermanyAustria

Switz.USACanada


DIM-ID

11223344556677

Cust-SID

1711171227113711471157116711

Country-SID

11112233445566

Text &Rep. Attributes

Text &Rep. Attributes

FactTable

(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 tablesIn 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.

2. Columns of a dimension tableThe 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). The



37/73


unique key of a dimension table is the dimension ID (DIM-ID), that is a surrogate key(integer 4) (fig.33).


DIM-ID

11223344556677

Cust-SID

1711171227113711471157116711

Country-SID

11112233445566

(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 patterns such as N:M relationships within the same dimension or leafless hierarchies, and most importantly, it allows you to follow up changes of constellations between values of different characteristics within the same dimension over time (time rows). This will bediscussed in depth in chapter 5.

3. LimitationsAn InfoCube allows

16 dimensions3 dimensions exist with each InfoCube (whether they are used and thus visible

or not)Time dimensionUnit/ currency dimensionPacket dimension

The remaining 13 dimensions are for individual schema design

Each dimension table may be up to 248 characteristics.

Important



38/73


It should be noted that in wider usage each attribute / characteristic is sometimes called a dimension. This a potential point of misunderstanding as then saying that the BW

schema has 16 dimensions, three of which are used internally, may sound very limited. According to this definition of a dimension there are 13 X 248 dimensions possible with BW plus the dimensions defined by the navigational attributes.

4. Dimensions and navigation

All characteristics assigned to dimension tables can be used for navigation (drilling) 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 tablesDimension tables are maintained during InfoCube load.

6. Special BW dimensionsWith BW we have special predefined dimensions:

Time dimensionUnit/ currency dimensionPacket dimension

1. Packet dimensionWith every load into an InfoCube there is a unique packet-ID assigned. This allows you to

purge erroneous loads without recreating the whole InfoCube again. The packet 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 DimensionThe respective dimension table is generated if the key figures selected in the InfoCube are of type amount or quantity.

Important

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

7. Dimensions with only one characteristic (line item dimensions)It is very often possible in this model to assign only one characteristic to a dimension.



39/73


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 kindof dimension as a line item dimension (Check box dimension definition).In doing this no dimension table will be generated for this dimension. A dimension table will

serve the SID table of this characteristic. The key in the fact table will be the SID of the SIDTable (fig.34).Line item dimension:

Line-ItemDimension

(1) Fact Table(1) Fact Table

(2) Dimension Tables(2) Dimension Tables

(3) time-independent-SID(3) time-independent-SID(4)(4) time-dependent-SI Dtime-dependent-SI D(5) traditional SID(5) traditional SID

11

22

22

22 33

55

44

33

5555

55

55

55

55

55

55

33 3355

55

5555

33

55

55

(figure 34)



40/73


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. Thenon-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 number of rows in comparison to the fact table (factor 1:10 / 20).

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

Multiple

Fact Tables

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

(2) Dimension(2) Dimension

(3) time-independent-

(3) time-independent- (4) (4) time-dependent-

time-dependent-

(5) traditional(5) traditional

2 2

2 2

5 5 5 5

2 2 3 3

5 5

4 4

3 3 5 5

5 5

5 5

5 5

5 5

5 5

3 3 3 3 5 5

5 5

5 5 5 5

3 3

5 5

5 5

E

F

(figure 35)



41/73


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

2. Fact table partitioningBW 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. calendar year and month, or by 0FISCPER i.e. fiscal year and period (fig.36).

Partitioning Fact Tables

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

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

(2) Dimension(2) Dimension

(3) time-independent-

(3) time-independent- (4) (4) time-dependent-

time-dependent-

(5) traditional(5) traditional

5 5 5 5

2 2 3 3

5 5

4 4

3 3 5 5

5 5

5 5

5 5

5 5

5 5

3 3 3 3

3 3

5 5

5 5

Packe Dimensio

Time Dimensio

E

F

(figure 36)



42/73


Together with the entire value range for the partitioning InfoObject that you would expectand the optional maximal num

Documents

Multi-Dimensional Modeling En