Unit 4: Cube Model BW330: Figure 101: SAP BW Table Partitioning Concept

Unit 4: Cube Model BW330
Figure 101: SAP BW Table Partitioning Concept
This is a simple example of how a reporting scenario can be partitioned

using the table partitioning concept:
Table Partitioning
• The basic InfoCube in itself can be partitioned on the database level.
That means that the fact table inside the respective Star Schema,
which physically represents an InfoCube, are partitioned. This is
indicated by those horizontal lines splitting the fact table into various
partitions/fragments.
Fact tables can be partitioned over a time characteristic, either
0CALMONTH, as in the example here, or 0FISCPER. The reasons for this
approach are the following:
The DBMS require that ranges are defined when the Fact table is created,
that is, one needs to know the future values of the partition column in
advance. This is fairly straightforward for 0CALMONTH or the 0FISCPER
as users normally have a clear idea what the time frame of their data is. In
other words, when you specify an InfoCube to be partitioned then you only
have to know the time interval for which data will be loaded into the cube.
Partitioning over time usually leads to well balanced partitions/fragments
as the same amount of data is loaded into the cube at regular points in
time. Archiving usually works over time. Data before a certain date is
archived rather than data for a certain sales region.
Continued on next page
126 © 2003 SAP AG. All rights reserved. 30-12-2003

BW330 Lesson: Master Data
Demonstration: Demonstration Exercise 1 (Unit 4)

Purpose
To demonstrate Exercise 1 (Unit 4)
System Data
System:
Client:
User ID:
Password:
Set up instructions:
1. Exercise 1 performs configuration tasks that have not been discussed
in the topic. You may consider demonstrating and discussing Exercise
1, creation of an InfoCube with “line item dimension” and table
partitioning.
30-12-2003 © 2003 SAP AG. All rights reserved. 127


99 Exercise 2: BW Star Schema

Exercise Duration: 20 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
• Create a basic InfoCube
• Investigate partitioning
• Set line item dimensions and high cardinality (discussed in detail in
the Modeling Dimensions Unit)
Business Example
Your company has decided to use an InfoCube to create summary reports.
First of all, you need to consider some of the master data settings for a
characteristic to see how they will affect data modeling.
Task 1:
Create a basic InfoCube in an InfoArea with a line item dimension with
high cardinality.
1. In your InfoArea BW330 Group ## (T_BW330_GR##) create a basic
InfoCube by copying the existing InfoCube T_GR00SOR.
Use the technical name T_GR##SOR and description GR## Sales
Order Cube.
2. Now, determine the dimension to which the characteristic
0DOC_NUMBER is assigned. Mark this dimension to be a line item
dimension and with high cardinality.
3. Check and activate your InfoCube.
4. Using the transaction LISTSCHEMA, what consequences does this
line item dimension have on the data model of your InfoCube?
___________________________________________________________
Task 2:
Partition a basic InfoCube in your InfoArea by calendar year and month.
1. Change your InfoCube T_GR##SOR. Enter a partition condition
within the InfoCube maintenance for the time characteristic
0CALMONTH with a value range from 01.1999 to 12.2000.

2. What is the maximum number of partitions to be entered in order to

get the data of 2 calendar months in one partition?
______________________
3. Save and activate the changes to InfoCube T_GR##SOR.
4. Using the transaction LISTSCHEMA, look at the structure of the fact
table. What new field has been added after the DIM keys?
_________________________________________

Solution 2: BW Star Schema

Task 1:
Create a basic InfoCube in an InfoArea with a line item dimension with
high cardinality.
1. In your InfoArea BW330 Group ## (T_BW330_GR##) create a basic
InfoCube by copying the existing InfoCube T_GR00SOR.
Use the technical name T_GR##SOR and description GR## Sales
Order Cube.
a) In your InfoArea BW330 Group ## (T_BW330_GR##) create a
basic InfoCube by copying the existing InfoCube T_GR00SOR.
Use the technical name T_GR##SOR and description GR##
Sales Order Cube.
Administrator Workbench → Modeling → InfoObjects → BW
Training 3.0 → BW Customer Training → BW330 Modeling →
BW330 Group ## (T_BW330_GR##)
Select your InfoArea BW330 Group ## (T_BW330_GR##) and
right-click.
From the context menu, select Create InfoCube.
Enter the name T_GR##SOR and description GR## Sales Order
Cube.
From the drop-down list find and select InfoCube T_GR00SOR
or enter the InfoCube name in the field Copy From.
Select the radio button for Basic Cube in InfoCube Type.
Click the Create button.

2. Now, determine the dimension to which the characteristic

0DOC_NUMBER is assigned. Mark this dimension to be a line item
dimension and with high cardinality.
a) Now, determine the dimension to which the characteristic
0DOC_NUMBER is assigned. Mark this dimension to be a line
item dimension and with high cardinality.
On the Characteristics tab, click the Dimensions button.
Switch to the Assign tab.
Determine which dimension contains the InfoObject
0DOC_NUMBER.
Return to the Define tab.
Mark the dimension determined above as both Line item and
High Cardinality.
Select the Continue button.
3. Check and activate your InfoCube.
a) Check and activate your InfoCube.
4. Using the transaction LISTSCHEMA, what consequences does this
line item dimension have on the data model of your InfoCube?

___________________________________________________________
a) Using the transaction LISTSCHEMA, what consequences
does this line item dimension have on the data model of your
InfoCube?
In the command field, enter /nlistschema.
For InfoCube type, enter B.
In the InfoCube field, enter the name of your InfoCube
T_GR##SOR.
Execute.
Expand the fact table.
Find the dimension determined above and expand it.
Find the SID table (/BI0/SDOC_NUMBER) for the dimension
table determined above.
Click the button Call up transaction SE16 icon to see the
structure of the table.
You will see that the SID table has already been populated.
Return to the Administrator Workbench.

Task 2:
Partition a basic InfoCube in your InfoArea by calendar year and month.
1. Change your InfoCube T_GR##SOR. Enter a partition condition
a) Change your InfoCube T_GR##SOR. Enter a partition condition
Find your InfoCube T_GR##SOR and right-click on it to open
the context menu.
From the context menu, select Change.
Use the menu path:
Extras → Partitioning.
In the Determine Partitioning Condition dialog box, you will see
the time characteristic InfoObjects that are part of the InfoCube
definition. One will be grayed out. Select the radio button Select
for the InfoObject 0CALMONTH.
In the Value Range (Partitioning Condition) dialog box, enter the
values 01.1999 and 12.2000 in the From and To fields.
Select Continue.
2. What is the maximum number of partitions to be entered in order to
get the data of 2 calendar months in one partition?
______________________
a) What is the maximum number of partitions to be entered in
order to get the data of 2 calendar months in one partition?
(24 periods / 2 ) + 2 = 14 partitions
3. Save and activate the changes to InfoCube T_GR##SOR.
a) Save and activate the changes to InfoCube T_GR##SOR.
4. Using the transaction LISTSCHEMA, look at the structure of the fact
table. What new field has been added after the DIM keys?

_________________________________________
a) Using the transaction LISTSCHEMA, look at the structure of the
fact table. What new field has been added after the DIM keys?
In the command field, enter /nLISTSCHEMA.
For InfoCube type, enter B.
In the InfoCube field, enter the name of your InfoCube
T_GR##SOR.
Execute.
Select the fact table.
Click the button Call up transaction SE16.
What new field has been added after the DIM keys?
The field SID_0CALMONTH has been added as a result of the
partitioning condition .


107 Exercise 3: Characteristics

Exercise Objectives
• Create a characteristic InfoObject
• Investigate master data settings that affect modeling
• Set up a transitive attribute
Business Example
Your company has decided to use an InfoCube to meet reporting
requirements of a summarized nature. You need to consider some of
the master data settings for a characteristic to see how they will affect
data modeling.
Task 1:
You will create a new InfoObject T_CSTC## (## is your group number).
Your group number should be a part of your long description (GR## Cost
center).
1. Create a new characteristic InfoObject named T_CSTC##
in your InfoObject Catalog Group## Characteristics
(T_BW330_GR##_CHAR) in your InfoArea Administrator
Workbench → Modeling → InfoObjects → BW Training → BW
Customer Training → BW330 Modeling → Group ## .
Select your InfoObject catalog and from the context menu select
Create InfoObject.
On the General tab, choose data type CHAR, length 13, and conversion
routine ALPHA.
On the Master data/texts tab, ensure that the With master data and
With texts check boxes are both selected and that texts are language-
and time-dependent. Select both short and medium length texts.
On the Hierarchy tab, enable hierarchies and specify that intervals
be permitted. Hierarchies should not be time-dependent.
On the Compounding tab, specify the superior InfoObject
0CO_AREA.
On the Attributes tab, enter the following InfoObjects as attributes:

0COMP_CODE
0BUS_AREA
0RESP_PERS
0EVCURRCOST
0PROFIT_CTR
0ENTRYDATE
Mark all attributes as time-dependent.
Activate 0COMP_CODE and 0BUS_AREA as Navigation Attributes
using the standard text.
Save and activate your new InfoObject.
Task 2:
Optional – Look at the underlying tables created when you saved and
activated your InfoObject T_CSTC##.
1. Go to the tab Master data/texts and double-click on the table titled
/BIC/MT_CSTC## in the field View of MstrDtaTbls and view the
structure of the table. What two fields do you see which relate to time?
_______________________________________________
Compare the structure of this table with the order of attributes you
entered on the Attributes tab. Are there similarities?
_______________________________________________________
Go to the tab Master data/texts and double-click the table titled
/BIC/QT_CSTC## in the field Master data tab time dep and view the
structure of the table. Does this table differ from /BIC/MT_CSTC##
and why or why not?
_________________________________________________________
Go to the tab Master data/texts and double-click on the table titled
/BIC/YT_CSTC## in the field SID Tab time dep attr. and view the
and why?
_________________________________________________________
/BIC/TT_CSTC## in the field Text Table and view the structure of
the table. Does this table differ from /BIC/MT_CSTC## and why
or why not?

_________________________________________________________
Go to the tab Hierarchy and double-click the table titled
/BIC/HT_CSTC## in the field Hierarchy table and view the structure
of the table. Does this table differ from /BIC/MT_CSTC## and why
or why not?
_________________________________________________________
Return to the InfoObjects directory.
Task 3:
You need 0COMPANY as a navigational attribute but it isn’t in the data
model. You must now set it up as a transitive attribute.
1. Create a new characteristic InfoObject named COST_T## with
description “ Transitive Cost Center ## ” in your InfoObject Catalog
Group## Characteristics (T_BW330_GR##_CHAR) in your InfoArea
Training 3.0 → BW Customer Training → BW330 Modeling → Group
## .
Copy from T_CSTC##.
Delete all copied attributes and add 0COMPANY.
Mark 0COMPANY as Navigation Attribute using standard
descriptions.
Leave all other settings the same.
Save but don’t activate.
2. Go to SE16 for table RSDCHA and bring up the ‘M’ version of
COST_T##. Change the field CHANAV to 2. This prevents COST_T##
from being used in the query. This is not a required step. Save the
change.
3. Go back to COST_T## and activate it in your other session.
4. Add COST_T## to InfoCube T_330GR## and assign it to dimension
Cost Center. Make 0COMPANY navigational.
5. Create a query off InfoCube T_330GR## with 0QUANTITY in the
columns and COMPANY in the rows.

Save the query with a description ‘Transitive Query ##’ and technical
name Transitive_Q## in your Favorites folder.
Note: Since master data has not been loaded for the
new/changed tables, your query results will not represent
a range of Company values.
Field Name or Data Type Values
Description Transitive Query ##
Technical Name Transitive_Q##

Solution 3: Characteristics
Task 1:
You will create a new InfoObject T_CSTC## (## is your group number).
Your group number should be a part of your long description (GR## Cost
center).
1. Create a new characteristic InfoObject named T_CSTC##
Create InfoObject.
On the General tab, choose data type CHAR, length 13, and conversion
routine ALPHA.
On the Master data/texts tab, ensure that the With master data and
With texts check boxes are both selected and that texts are language-
and time-dependent. Select both short and medium length texts.
On the Hierarchy tab, enable hierarchies and specify that intervals
be permitted. Hierarchies should not be time-dependent.
0CO_AREA.
On the Attributes tab, enter the following InfoObjects as attributes:
0COMP_CODE
0BUS_AREA
0RESP_PERS
0EVCURRCOST
0PROFIT_CTR
0ENTRYDATE
Activate 0COMP_CODE and 0BUS_AREA as Navigation Attributes
using the standard text.


a) You will create a new InfoObject T_CSTC## (## is your group
number). Your group number should be a part of your long
description (GR## Cost center 13).
Create a new characteristic InfoObject named T_CSTC##
Create InfoObject.
On the General tab, choose data type CHAR, length 13, and
conversion routine ALPHA.
On the Master data/texts tab, ensure that the With master data
and With texts check boxes are both selected and that texts are
language- and time-dependent. Select both short and medium
length texts.
On the Hierarchy tab, enable hierarchies and specify
that intervals be permitted. Hierarchies should not be
time-dependent.
0CO_AREA.
On the Attributes tab, enter the following InfoObjects as
attributes:
0COMP_CODE
0BUS_AREA
0RESP_PERS
0EVCURRCOST
0PROFIT_CTR
0ENTRYDATE
Activate 0COMP_CODE and 0BUS_AREA as Navigation
Attributes using the standard text.

Task 2:
Optional – Look at the underlying tables created when you saved and
activated your InfoObject T_CSTC##.
1. Go to the tab Master data/texts and double-click on the table titled
structure of the table. What two fields do you see which relate to time?
_______________________________________________
Compare the structure of this table with the order of attributes you
entered on the Attributes tab. Are there similarities?
_______________________________________________________
/BIC/QT_CSTC## in the field Master data tab time dep and view the
and why or why not?
_________________________________________________________
/BIC/YT_CSTC## in the field SID Tab time dep attr. and view the
and why?
_________________________________________________________
/BIC/TT_CSTC## in the field Text Table and view the structure of
the table. Does this table differ from /BIC/MT_CSTC## and why
or why not?
_________________________________________________________
Go to the tab Hierarchy and double-click the table titled
/BIC/HT_CSTC## in the field Hierarchy table and view the structure
of the table. Does this table differ from /BIC/MT_CSTC## and why
or why not?
_________________________________________________________
a) Optional – Look at the underlying tables created when you
saved and activated your InfoObject T_CSTC##.
structure of the table. What two fields do you see that relate to
time?

Because you marked the attributes as time dependent, the field’s

0DATEFROM and 0DATET0 were added to the master data
table view.
Compare the structure of this table with the order of attributes
you entered on the Attributes tab. Are there similarities?
The order of the InfoObjects you entered as attributes is found
here in the master data table view.
On the tab Master data/texts and double-click on the table
titled /BIC/QT_CSTC## in the field Master data tab time dep.
and view the structure of the table. Does this table differ from
/BIC/MT_CSTC## and why or why not?
This table does not differ from the master data table view. Since
the attributes are all time dependent, the BW system creates the
Q table, which together with the P table (for time-independent
attributes) forms the M master data table view.
Go to the tab Master data/texts and double-click the table
titled /BIC/YT_CSTC## in the field SID Tab time dep attr.
and view the structure of the table. Does this table differ from
/BIC/MT_CSTC## and why?
This table does differ from the master data table view since this
table contains the necessary SIDs for the master data.
Go to the tab Master data/texts and double-click on the
table titled /BIC/TT_CSTC## in the field Text Table and
view the structure of the table. Does this table differ from
The text table does not contain any of the attributes, but does
reflect the settings made in the master data/texts tab of the
InfoObject.
Go to the tab Hierarchy and double-click on the table
titled /BIC/HT_CSTC## in the field Hierarchy table and
view the structure of the table. Does this table differ from
This table does differ from the master data table view since
this table reflects the settings made in the hierarchy tab of the
InfoObject.

Task 3:
You need 0COMPANY as a navigational attribute but it isn’t in the data
model. You must now set it up as a transitive attribute.
1. Create a new characteristic InfoObject named COST_T## with
description “ Transitive Cost Center ## ” in your InfoObject Catalog
Group## Characteristics (T_BW330_GR##_CHAR) in your InfoArea
Training 3.0 → BW Customer Training → BW330 Modeling → Group
## .
Copy from T_CSTC##.
descriptions.


a) You need 0COMPANY as a navigational attribute but it isn’t in
the data model. You must now set it up as a transitive attribute.
Create a new characteristic InfoObject named COST_T## with
description “ Transitive Cost Center ## ” in your InfoObject
Catalog Group## Characteristics (T_BW330_GR##_CHAR)
in your InfoArea Administrator Workbench → Modeling →
InfoObjects → BW Training 3.0 → BW Customer Training →
BW330 Modeling → Group ## .
Copy from T_CSTC##.
description.
Training 3.0 → BW Customer Training → BW330 Modeling →
GR##: InfoArea → Right-click (RMC) → Create InfoObject.
Use T_CSTC## as a template.
On the attribute tab, delete all copied attributes.
Add 0COMPANY as an attribute.
Mark 0COMPANY as Navigation Attribute. Check the box to
use the text from the standard InfoObject description.
2. Go to SE16 for table RSDCHA and bring up the ‘M’ version of
COST_T##. Change the field CHANAV to 2. This prevents COST_T##
from being used in the query. This is not a required step. Save the
change.
a) Go to SE16 for table RSDCHA and bring up the “M” version
of COST_T##. Change the field CHANAV to 2. This prevents
COST_T## from being used in the query. This is not a required
step. Save the change.
Enter /OSE16 in the command field → Enter table RSDCHA.
Select CHANM = COST_T## and OBJVERS = M and execute (F8).
Flag the selected record and choose Change (F6).
Change the field CHANAV to 2 → Save.

3. Go back to COST_T## and activate it in your other session.

a) Go back to COST_T## and activate it in your other session.
4. Add COST_T## to InfoCube T_330GR## and assign it to dimension
Cost Center. Make 0COMPANY navigational.
a) Add COST_T## to InfoCube T_330GR## and assign it to
dimension Cost Center. Make 0COMPANY navigational.
Administrator Workbench → Modeling → InfoProviders →
Search for T_330GR## → RMC → Change
Add COST_T## as a Characteristic → Press the Dimensions
Button → Go to the Assign Tab → Scroll down → Check
COST_T## → Double-click on the ‘Cost Center’ Dimension.
Choose Button Navigation Attributes and flag 0COMPANY as
used in this InfoCube.
Continue → Activate.
5. Create a query off InfoCube T_330GR## with 0QUANTITY in the
columns and COMPANY in the rows.
Save the query with a description ‘Transitive Query ##’ and technical

Description Transitive Query ##
Technical Name Transitive_Q##
a) Create a query off InfoCube T_330GR## with 0QUANTITY in

the columns and COMPANY in the rows.
Save query with a description ‘Transitive Query ##’ and technical
From the SAP Easy Access Screen → Business Explorer →

Analyzer Choose Open → Queries → New → InfoAreas →
Search for InfoCube ‘T_330GR##’.
Drag 0QUANTITY from the Key Figures folder to the columns.
Drag COMPANY from the Cost Center folder to the rows.
Save.

Description Technical Name Transitive Query
##Transitive_Q##

Lesson Summary
You should now be able to:
• Explain master data tables
• Explain how to assign attributes
• Explain hierarchy tables in master data tables
• Explain table partitioning

Unit Summary BW330
Unit Summary
• Describe the problems associated with the basic Star Schema
• Explain the differences between the enhanced SAP Star Schema and
the basic Star Schema
• Explain master data tables
• Explain how to assign attributes
• Explain hierarchy tables in master data tables
• Explain table partitioning

BW330 Test Your Knowledge
Test Your Knowledge

121
1. In the basic Star Schema it is not possible to generate user-defined

hierarchy types.
Determine whether this statement is true or false.
□ True
□ False
2. Which feature of SAP BW Star Schema provides a link to the master

data tables that are outside the dimension of the basic Star Schema?
3. You can define only one hierarchy for a single characteristic.

□ True
□ False
4. attributes have
values that are valid for a specific range of dates, while
attributes do not have a validity
period.
Fill in the blanks to complete the sentence.
5. When you specify an InfoCube to be partitioned then you only have

to know the for which data will be loaded
into the cube.
Fill in the blanks to complete the sentence.
6. How are the master data tables named?

Test Your Knowledge BW330
Answers
122
1. In the basic Star Schema it is not possible to generate user-defined

hierarchy types.
Answer: True
In the basic Star Schema it is not possible to generate user-defined
hierarchy types.
2. Which feature of SAP BW Star Schema provides a link to the master

data tables that are outside the dimension of the basic Star Schema?
Answer: SID tables (pointer tables) provide the technical link to the
master data (attribute, text, and hierarchy) tables that are outside
the dimension of a Star Schema.
3. You can define only one hierarchy for a single characteristic.
Answer: False
You can define several hierarchies for a single Characteristic.
4. Time-dependent attributes have values that are valid for a specific

range of dates, while time-independent attributes do not have a
validity period.
Answer: Time-dependent, time-independent
5. When you specify an InfoCube to be partitioned then you only have

to know the time interval for which data will be loaded into the cube.
Answer: time interval
6. How are the master data tables named?
Answer: Master data tables are named based on their time

dependency. They can be time-independent master data,
time-dependent master data, or a combination of both.

Unit 5
123 Dimensional Modeling
In the beginning, focus on the types of master data relationships in

dimension tables. Then, go on to discuss typical data modeling issues
and explain the participant how to determine appropriate solutions for
such issues.
Hint: It’s important to note mostly standard data warehousing

terminology is used when describing modeling scenarios. Most of
the content that reference the term dimension attribute relate to an
SAP BW characteristic InfoObject.
Unit Overview
This unit will help you understand dimensional modeling in BW. First,
you will learn about various relationships of characteristics in dimension
tables. Next, you will learn about typical data modeling issues and
determine appropriate solutions for such issues. Finally, you will learn
about concepts and recommended modeling solutions along with loading
implications of using these solutions.
Unit Objectives
After completing this unit, you will be able to:
• Explain the types of relationships of master data characteristics in

dimension tables
• Describe the techniques used in modeling data mining
• Explain the concept of partitioning in BW modeling
Unit Contents
Lesson: Designing the Dimensions of the SAP BW InfoCube ............154
Demonstration: Unrelated Characteristics in the Same Dimension .163
Exercise 4: Dimension Tables ............................................171

Unit 5: Dimensional Modeling BW330
Lesson: Designing the Dimensions of the SAP BW InfoCube

124 Lesson Duration: 50 Minutes
Lesson Overview
This lesson will help you understand master data characteristic
relationships in dimension tables. You will learn about the various
techniques used in modeling data mining. In addition, you will learn
about the partitioning concept in BW modeling.
Lesson Objectives
After completing this lesson, you will be able to:
dimension tables
In this lesson, focus on the various relationships of master data

characteristics in dimension tables. After you have explained these
relationships, you can switch to techniques used for modeling data mining
and then explain the concept of partitioning.
Business Example
You are the technology manager of a company that uses Business
Warehousing to store data. As the data increases in volume, you find
that user queries are taking a long time to execute. Therefore, you want
to implement a logical data model so that the query execution time is
reduced. To implement this model, you first have to decide how to design
the dimensions of the SAP BW InfoCube.
Note: The “standard” data warehousing terminology is used

for describing modeling scenarios. The reference to the term
“dimension attribute” relates to an SAP BW characteristic
InfoObject.
Technical Structure
Relationship of Characteristics in Dimension Tables
M: N Relationships of Master Data

BW330 Lesson: Designing the Dimensions of the SAP BW InfoCube
Point out that an M: N relationship within the same dimension will cause
the number of entries in the table to expand exponentially, if the maximum
number of possible values is not restricted to a small number of entries.
M: N Relationship: Two Dimensions
The content depicts a solution to the earlier potential problem. Place the
two dimension attributes (characteristics) in separate dimension tables.
M: N Relationship: One Dimension
The content depicts the problem. Explain to the participants that for good
performance on data loads and queries, dimension tables should be from
5% to 10% of the size of the fact table.
Compounded Master Data Keys
Unrelated Characteristics in the Same Dimension
Explain the idea of merging two small DIM tables results in a larger table.
Point out that reduction of table joins can be used if the maximum number
of entries in each DIM table and the Cartesian product of the combination
are clearly defined.
Mixed Dimensions (1)
Mixed Dimensions (2)
Broad Dimensions
Illustrate the problems of dimensions containing millions of records.
Discuss the pros and cons of aggregates and the usage of demographic
attributes in smaller dimensions.
Categorization
Categorical Dimensions
Categorical Dimensions in SAP BW
Explain the Categorical dimension using the given example in the section.
Point out the problems related to slowly changing dimensions or attributes
set as Navigational.

Relationships of Master Data Characteristics
Figure 102: Technical Structure
In addition to the DIMID as the key of the dimension table, there is one
column for every characteristic in the dimension table.
These columns contain the SID (surrogate ID) value for each characteristic.
The SID is the value field of the SID table. The actual master data value
is the key to the SID table.
Figure 103: Relationship of Characteristics in Dimension Tables

The ideal relationship between characteristics in the same dimension table

is the 1:N relationship.
For every possible combination, there is only a single DIMID at a certain
point of time.
If the combination changes, a new entry with a new DIMID is generated.
The N:M relationship will normally lead to the creation of large dimension
tables.
The maximum number of entries in the dimension table is the Cartesian
product of all SIDs. The assumption is that transactional data is loaded
for every possible combination of characteristics, for example, customer
and material.
Figure 104: M:N Relationships of Master Data

Figure 105: M:N Relationships: Two Dimensions
Usually, M:N relationships mean that the two characteristics are stored in
different dimensions, for example CUSTOMER and MATERIAL. This kind
of relationship is described by facts or key figures, for example sales orders.
In companies that use the R/3 Sales Order variant configuration, several
colors are often used for every product.
This provides information, which reflects characteristic relationships that
exist at the time of the transaction. For example, this solution captures
whatever color is selected for the product on the sales order.
Figure 106: M:N Relationships: One Dimension

In most cases, the alternative to model the N:M relationship in one

dimension will not be the best way.
You should check the actual number of records in the dimension table and
its ratio to the number of records in the fact table.
As a rule of thumb, there should be a ration of 1:10 – 1:20. That means
small dimension tables and larger fact tables.
Figure 107: Compounded Master Data Keys
Compounded keys from the source can be modeled by compounded

attributes into a single characteristic, especially if there is a demand for
time dependent reporting of further attributes of this variant.
Compounded keys can be merged into a single key of a characteristic
during the staging process. This must be done twice, for both master data
and transactional data.
Figure 108: Unrelated Characteristics in the Same Dimension
If you merge two small DIM tables you get a slightly larger table, but it
means that only one table has to be accessed when data is loaded or a query
is executed. Of course, you would not want to place two strong entities
(such as MATERIAL and CUSTOMER) in the same dimension table.

In the majority of cases, 13 dimension tables are more than adequate.

The rule of thumb is to group characteristics with a parent: child
relationship in the same dimension.
Figure 109: Mixed Dimensions (1)
Characteristics with an N:M relationship can be combined in the same

dimension, if the maximal number of records is clearly defined and the
Cartesian product of the characteristic results only in a small dimension
table.
Figure 110: Mixed Dimensions (2)

Characteristics VERSION and COLOR have an N:M relationship.

Nevertheless they can be used in the same dimension, because the
maximum number of records is 3 X 4 = 12.
Figure 111: Broad Dimensions
Experts talk of a 10-20 to one relationship between the size of the fact table
and the size of the dimension tables. Although the optimal relationship
is difficult to determine, a large fact table and smaller dimension tables
provide the best system performance.
Note: In some cases, you may want to consider line-item

dimensions. For example, retail companies could put the
CUSTOMER characteristic in a separate dimension and make it a
‘Line Item Dimension’.
Figure 112: Categorization

Figure 113: Categorical Dimensions
If you want to use a query for categorization, you need, for example, to
include all the customers whose income is greater than X but less than Y.
Category dimensions allow you to use the Income characteristic with the
values A < 1000, 1001 < B < 5000, and 5001 < C < 6000 during the data
transfer. The user then simply filters out all the “B” customers.
Figure 114: Categorical Dimensions in SAP BW
If a customer moves from one category to another, how do you model

this change in the history?
An example of the second bullet point: income would be an attribute of
0SOLD_TO.
An example of the third bullet point: income would be in the same
dimension as 0SOLD_TO.

Demonstration: Unrelated Characteristics in the Same

Dimension
Purpose
To demonstrate unrelated characteristics in the same dimension
System Data
System:
Client:
User ID:
Password:
1. Draw the characteristics, “Version” and “Color”, in a Star Schema, as
one dimension table and as two dimensions.
2. Explain to the participants that since “Version” and “Color” have few
unique values, as one dimension table the entries would be small. For
example, Combination of characteristic ‘Version’ with 3 values (actual,
planned, and forecast) and color with 4 values (green, blue, red, and
yellow) will have maximum 12 records in the combined DIM table.
DIM ID Version Color

1 Actual Green
2 Actual Blue
3 Actual Red
4 Actual Yellow
5 Plan Green
6 Plan Blue
7 Plan Red
8 Plan Yellow
9 Forecast Green
10 Forecast Blue
11 Forecast Red
12 Forecast Yellow

Modeling Data Mining

Data Mining Examples of Key Steps
Status Attributes in BW
The same aspects of dimension sizing and frequent changes in context
with Status Attributes.
Data Mining
Figure 115: Modeling Data Mining
Clustering is used to split data into homogeneous groups. The model

looks for a global structure for the data with the aim of partitioning the
data into clusters.
Association analysis can be used to establish composite effects and thereby
identify cross-selling opportunities. The search for associations considers
objects with information content that is remotely comparable. Statements
are formulated about partial structures in the data and take the form of
rules.
Decision trees display data using (non-continuous) category quantities.
The display rules are determined in training using those sections of historic
data where the assignment to categories is already known.
In Scoring, data is displayed using continuous quantities. If required,
discretion can then be applied to split the data into classes. The scoring
function can either be specified using weighted score tables or be
determined by using historic data as a linear or nonlinear regression of a
target quantity.
ABC Classification displays data grouped into classes of A, B, C and so
on, using thresholds and classification rules. The classified results are
then charted or listed.

Figure 116: Data Mining Examples and Key Steps
The transaction code to access the data mining workbench is

RSDMWB. The delivered role for CRM-related data mining is
SAP_BWC_CUSTOMER_BEHAVIOR.
Queries need to be Released for OLE DB for OLAP.
Currently, only CRM courses include data mining. See the description for
the CR900 and TRCAM6 classes.
Figure 117: Status Attributes in BW
If you integrate the status into the same dimension with article and outlet,
you generate a large number of records in this table. For example, think
about a retailer with 5,000 outlets in a country with 50,000 products with
up to 10 different promotions.
This scenario calls for a separate dimension table with status as the
characteristic. The result is a smaller, more efficient set of dimension tables.
Partitioning Dimensions: Modeling Aspects

Partitioning Example (1)
Partitioning Example (2)

Prevent Aggregation of Partitioning Characteristic

Explain that this option prevents aggregating “Current Qty”, “Planned
Qty”, Forecast Qty…. if a characteristic is introduced for partitioning.
Degenerate or Line-Item Dimensions
Where to Set Line Item in InfoCube
Note: Explain to the participants that the previous Unit’s Exercise

1 demonstrated this function.
If you are working with highly granular data, on the single document level
in the InfoCube or on the document number level in the dimension, there
is an opportunity to improve the system performance.
No additional characteristics are included in this dimension and the
dimension is designated a line-item dimension in the maintenance screens
for the InfoCube.
Partitioning
Figure 118: Partitioning: Modeling Aspects
There is a Version characteristic with three values to model your example:

Actual, Plan, and Forecast each in a separate dimension and the two basic
facts Sales and Unit.
It is very easy to add another scenario, for example, a quarterly forecast.

This solution has the effect of using an additional key field to sort fact table
records. 0VALTYPE is frequently used for this purpose as well.
In business content FI/CO InfoCubes, actual data is typically stored
separately from planned data.
Figure 119: Partitioning Example (1)
Modeling with several key figures in the fact table.
Figure 120: Partitioning Example (2)
In this example, only two key figures are used in the fact table.
An new dimension with the partitioning characteristic VERSION is added.

Any new value for the characteristic VERSION can be used to enhance the
reporting without changing the data model.
Figure 121: Prevent Aggregation of Partitioning Characteristic
The selection describes if and how the values of a characteristic in queries

should be restricted.
If the value, Unique for Every Cell’ has been selected, the characteristic
must be restricted to one value in every column and in every structure for
all the queries. The characteristic can not then be aggregated.
Typical examples for such characteristics are ’Plan Actual Indicator’ or
’Value Type’.
Degenerate Dimensions
Figure 122: Degenerate or Line-Item Dimensions

A degenerate dimension is a large dimension that is approaching the size

of the fact table.
In a degenerate dimension with order numbers, all the descriptive
attributes are located in other dimensions.
When activating the InfoCube, no dimension table is created.
The line item dimension is set in the InfoCube in a change mode in
the dimension pop-up on the define tab. The SID of the ‘degenerate’
dimension is then placed into the fact table by the system with a field name
of ‘RSSID’ which can be viewed through SE11 > /BIC/F<InfoCube name>
If only a limited history of line item detail is required, an ODS Object
should be considered.
Figure 123: Where to Set Line Item in InfoCube
The setting for Line Item Dimensions is set by clicking the Dimensions icon
in the Characteristics tab of InfoCube maintenance.
When creating the dimensions in the InfoCube maintenance, flag the
relevant dimension as a Line Item dimension.
Dimensions set as Line Item Dimensions should contain only one
characteristic.
It is recommended that you use ODS objects, where possible, instead of
InfoCubes for line items.

High Cardinality is used to adjust indexing for a dimension for which the
box is checked:
• The flag defines which index type should be used:
– Low cardinality (Bitmap where values are often repeated)
– High cardinality (B-tree where the values are not often repeated)
Only pertains to an Oracle DB
• Switch on the flag if the dimension size is > 10% of the fact table.
• Should be used in conjunction with Line Item Dimension.

139 Exercise 4: Dimension Tables

Exercise Objectives
• Discuss the placement of Characteristics within the various tables
associated with an InfoCube
Business Example
Your company has decided to use an InfoCube to create summarized
reports. First of all, you need to consider some of the master data settings
for a characteristic to see how they will affect data modeling.
Task 1:
Find InfoCube 0SD_C01 in Metadata Repository.
1. Go to the Metadata Repository in the Administrator Workbench.
2. Choose InfoCube in the list of activated objects.
3. Scroll in the list to InfoCube Customer (0SD_C01).
Note: The InfoCubes are listed in alphabetic order.
4. Click on the InfoCube Customer 0SD_C01.

5. Once the data has loaded, click on InfoCube - schematic display as Star
Schema to view the InfoCube Star Schema Diagram.
Task 2:
Together with your partner or team, answer the following questions:
1. Why are these characteristics in the InfoCube?
2. What determines which dimension table contain them?
3. Where else could some of these characteristics be located?
4. What effect would that have on the structure of the InfoCube and
the data?
5. What effect would moving some of the attributes located in master
data tables into dimensions have on the structure of the InfoCube
and the data?

Task 3:
Discuss with your partner or team alternatives to the data model:
1. Use /oLISTSCHEMA to open the transaction in a new session and
analyze the number of entries in the dimension tables of the InfoCube
0SD_C01.
2. Analyze the number of entries in the S-tables.

Solution 4: Dimension Tables

Task 1:
Find InfoCube 0SD_C01 in Metadata Repository.
1. Go to the Metadata Repository in the Administrator Workbench.
a) Go to the Metadata Repository in the Administrator Workbench.
Administrator Workbench → Metadata Repository
2. Choose InfoCube in the list of activated objects.
a) Choose InfoCube in the list of activated objects.
3. Scroll in the list to InfoCube Customer (0SD_C01).
a) Scroll in the list to InfoCube Customer (0SD_C01).

4. Click on the InfoCube Customer 0SD_C01.

a) Click on the InfoCube Customer 0SD_C01.
5. Once the data has loaded, click on InfoCube - schematic display as Star
Schema to view the InfoCube Star Schema Diagram.
a) Once the data has loaded, click on InfoCube - schematic display as
Star Schema to view the InfoCube Star Schema Diagram.
Task 2:
Together with your partner or team, answer the following questions:
1. Why are these characteristics in the InfoCube?
a) The data model determines the presence of these characteristics.
2. What determines which dimension table contain them?
a) What determines which dimension table contain them?
Of the dimensions in the InfoCube, three are pre-determined by
SAP (InfoPacket, Time, and Unit). The InfoObjects in the Unit
dimension are dictated by the choice of key figures.
The remaining dimensions and the InfoObjects contained in
them are determined according to the reporting requirements.
Reporting requirements also determine which time InfoObjects
are selected for the Time dimension.

3. Where else could some of these characteristics be located?

a) Where else could some of these characteristics be located?
Some of the characteristics in the user-defined dimensions could
be located in master data tables as either display attributes or
navigational attributes or both.
4. What effect would that have on the structure of the InfoCube and
the data?
a) What effect would that have on the structure of the InfoCube
and the data?
Removing some of the characteristics in the user-defined
dimensions would require offloading the data, modifying the
InfoCube dimensions, and reloading the historical data.
5. What effect would moving some of the attributes located in master
data tables into dimensions have on the structure of the InfoCube
and the data?
a) What effect would moving some of the attributes located in
master data tables into dimensions have on the structure of the
InfoCube and the data?
Adding some characteristic attributes into InfoCube dimension
tables would require an offloading of data, modification of the
InfoCube, and a reload of historical data. In addition, objects in
the InfoCube data flow would have to modified and reactivated
to accommodate these new characteristics as keys to the facts.

Task 3:
Discuss with your partner or team alternatives to the data model:
1. Use /oLISTSCHEMA to open the transaction in a new session and
analyze the number of entries in the dimension tables of the InfoCube
0SD_C01.
a) Use /oLISTSCHEMA to open the transaction in a new session
and analyze the number of entries in the dimension tables of
the InfoCube 0SD_C01.
In transaction LISTSCHEMA, choose InfoCube type ‘B’, and
InfoCube ‘0SD_C01’ and execute.
Expand the tree, highlight the specific dimension table, and
choose the button ‘Call up transaction SE16 (Shift + F4)’.
Choose ‘Number of entries’.
It could be possible to use a mixed Dimension of Version (2
records) and Value Type (3 records).
2. Analyze the number of entries in the S-tables.
a) Analyze the number of entries in the S-tables.
The maximum number of records in a mixed Dimension
Version/Value Type could be higher than the number actually
used in this InfoCube. It has to be clearly defined which
combinations can occur to calculate the maximum number of
records in the dimension table.

Lesson Summary
dimension tables

BW330 Unit Summary
Unit Summary
dimension tables

Unit Summary BW330

BW330 Test Your Knowledge
Test Your Knowledge

147
1. The ideal relationship between characteristics in the same dimension

table is:
Choose the correct answer(s).
□ A M:N relationship
□ B N:M relationship
□ C 1:N relationship
□ D N:1 relationship
2. Which data mining modeling technique can be used to establish

composite effects in master data?
Choose the correct answer(s).
□ A Clustering
□ B Decision trees
□ C ABC analysis
□ D Association analysis
3. In partitioning, the business content in InfoCubes is typically stored

in combination with the planned data.
□ True
□ False

Test Your Knowledge BW330
Answers
148
1. The ideal relationship between characteristics in the same dimension

table is:
Answer: C
The ideal relationship between characteristics in the same dimension
table is 1:N relationship.
2. Which data mining modeling technique can be used to establish

composite effects in master data?
Answer: D
Association analysis can be used to establish composite effects in
master data.
3. In partitioning, the business content in InfoCubes is typically stored

in combination with the planned data.
Answer: False
In partitioning, the business content in InfoCubes is typically stored
separately from planned data.

Unit 6
149 Tracking History and Hierarchies
Explain the options available for tracking historical transactional data in

BW. Tell the participants how they can deal with changes to attributes
in the same or different dimensions in the fact table. Finally discuss
hierarchies in BW.
Unit Overview
This unit will help you model various real-world reporting requirements
using the options available for tracking history in BW. First, you will learn
about various options for tracking historical transactional data in BW.
Next, you will compare various tracking scenarios. Finally, you will learn
about hierarchies and their impact on data modeling.
Unit Objectives
After completing this unit, you will be able to:
• Identify requirements for reporting on historical data

• Evaluate the use of characteristic hierarchies
Unit Contents
Lesson: Tracking History.......................................................182
Demonstration: Slowly Changing Attribute of a Characteristic .......185
Lesson: Hierarchies ............................................................198
Demonstration: Demonstration of Hierarchy Tab Page ...............200
Demonstration: Demonstration Hierarchy Presentations .............204
Exercise 5: Hierarchies ....................................................207

Unit 6: Tracking History and Hierarchies BW330
Lesson: Tracking History

150 Lesson Duration: 35 Minutes
Lesson Overview
In this lesson, you will learn the requirements that users have for reporting
on historical data in BW modeling.
Lesson Objectives
After completing this lesson, you will be able to:
• Identify requirements for reporting on historical data
Start by discussing methods for tracking of historical data. Then, move on

to discuss tracking of online data.
Business Example
You are the team leader of the BW project team of your company that
implemented the BW system in the company. You are interviewing users
to determine their requirements in the quarterly sales report generated by
the system. You find that the users want the sales report to be categorized
according to MATERIAL GROUP. To do this, you need to categorize
transactional data related to sales that was recorded during the quarter.
Tracking Based on Historical Data
Tracking History: Business Scenario (I)

Give an introduction to the scenario to illustrate the different demands
for reporting on historical changes. The scenario will be explained later
on in the lesson.
Tracking History: Business Scenario (II)
Point out the four different demands.
Historical Data: The Role of the Fact Table
The focus is on the changes occurring in the fact table during a period of
time. Repeat the technical background of DIM-ID’s relation to the fact table
that results in a compounded key of the combination of characteristics.
Information stored in the fact table retains its relationship to that set of
characteristic values even if the characteristic values change later.

BW330 Lesson: Tracking History
Historical Data: Dimensions that Change Slowly

Explain that the content refers to Industry terminology, in regards to
Dimensions. SAP BW would refer to this as “navigational attributes of a
characteristic that change over time”.
Tracking History: OLTP Supporting Data
The content shows the basic transaction and reference (master) data used
in the scenario. Assume the transaction data is stored in an InfoCube.
Until the end of January 2000, material BBB belongs to material group
FOOD. From the beginning of February 2000 material BBB belongs to
material group CHEMICALS. Material EEE is new in February 2000 and
belongs to the CHEMICALS material group.
Assume a first upload of transaction data in the month of January 2000 and
a second load in February.
Figure 124: Tracking History: Business Scenario (II)
Often different users have different ideas on how to track historical data.
In this section, you are going to look more closely at the four scenarios
shown above. These requirements can be met simultaneously from the
same Star Schema.
The key date mentioned in C is located in the query properties and is
accessed from the Query Designer.

Figure 125: Historical Data: The Role of the Fact Table
If the incoming data has a combination of characteristics which already

exists in the fact table, the key figures for the incoming data are aggregated
with the existing fact records. Only the Request ID is different, because it
identifies different loads of data. Of course, compression will eliminate
the request ID as a key field.
In addition, the fact table is not able to record the situation: “You have not
received a sales order for 100 cartons from company XYZ Inc.” An InfoSet
query that joins the master data and an ODS object should be considered
in this case.
Figure 126: Historical Data: Dimensions that Change Slowly*
This example focuses on changes that are made to the MATERIAL GROUP
(food, chemicals, and so on) in the material master. As MATERIAL to
MATERIAL GROUP assignments change through time in the OLTP
system, you will need to decide how they are recorded in BW.

For example, do the BW users only need the relationship captured in the
sales order when it was created or would they like to do their analysis
based on the latest assignment from the master data tables?
Figure 127: Tracking History: OLTP Supporting Data
This is the data that exists in the OLTP (On Line Transaction Processing
System) or SAP R/3 Enterprise System. It represents sales orders and the
material master table in the SAP R/3 Enterprise System.
Sales orders capture the MATERIAL to MATERIAL GROUP relationships
that exist in master data tables at the time of order creation. As new
assignments are made in the SAP R/3 Enterprise System, new sales orders
reflect the change however existing orders remain the same.
Demonstration: Slowly Changing Attribute of a

Characteristic
Purpose
To demonstrate a slowly changing attribute of a characteristic
System Data
System:
Client:
User ID:
Password:

1. Use the “Marital Status” example on the graphic to begin a discussion

“What happens if this year I’m unmarried (single), but next year I’m
married”. “Do you total all of my purchases as single, married, or
some single and some married?” All 3 responses are correct, based
on the requirements of the reporting user. This is the scenario of a
“slowly changing dimension”.
Tracking Based on Current Data
Scenario A: At the Time of the Sales Order

Explain that scenario A is the most common modeling scenario; often
referred to as “Historical Truth”.
All fields or values are stored at the time of the business event. In this
scenario, you need to record the Material Group at the time of the
business event “Sales Order”. To perform this task, you must assign all
the characteristics to dimensions in the InfoCube. The content shows
the ‘Historical Truth’ is modeled using a characteristic 0MATL_GROUP
in dimension ‘Material’. Be sure to discuss the totals mentioned in the
content.
Scenario B: At the Time of the Data Request (1)
This scenario performs a “realignment” or “restatement” of all transaction
information based on the values, as they exist today.
This scenario performs a “restatement” of BBB data as though it was
always assigned to the Material Group CHEMICALS.
The solution presented models 0MATL_GROUP, not as a characteristic
in the InfoCube, but as a time-independent, navigation attribute of
0MATERIAL and ONLY 0MATIERAL is a characteristic in the InfoCube.
Be sure to compare the totals in the content.

Figure 128: Scenario A: At the Time of the Sales Order
The material group is stored in the dimension table of the MATERIAL

characteristic (InfoCube Maintenance → Characteristics).
If the MATERIAL GROUP is not provided when the transaction data is
loaded, you have to create an update rule to determine the characteristic
value.
The most efficient and beneficial way of doing this is to store the
MATERIAL GROUP characteristic in the master data table of the
MATERIAL characteristic. By reading the master data attributes during the
loading process, the special update rule allows you to add the characteristic
to the dimension table. The user does not need to generate any coding.
If a characteristic is included in both the dimension table and the master
data table, the navigational attribute should have a different name
(NAV_MAT_GRP, for example) to make the difference clear to the query
builder (see scenario B).
This data can easily be depicted using a hierarchy based on the
characteristic relationships in the dimension table, which is discussed
later in this unit.

Figure 129: Scenario B: At the Time of the Data Request (1)
The MATERIAL GROUP characteristic is stored in the master data table of

the MATERIAL characteristic (InfoObject maintenance → Attributes).
The MATERIAL GROUP characteristic has to be designated as a
navigational attribute in MATERIAL and the appropriate InfoCube to
enable the drilldown and filter functions to work.
(Time-dependency is not needed for the MATERIAL characteristic
(InfoObject maintenance → Master data).
Important: To avoid reconstructing the InfoCube, there must be a
higher-level attribute in either the master data table or in an external
hierarchy. This requirement differs from scenario A.
Time-Dependent Tracking
At the Time of the Data Request (2)

The content discusses the implementation of Scenario B using a hierarchy.
The hierarchy is time-independent.
Scenario C: At any Point in Time (1)
Modeling using a time-dependent navigation attribute to show the results
to a key date.
Modeling using a time-dependent hierarchy.


Modeling using a hierarchy with versioning.
Figure 130: Scenario B: At the Time of the Data Request (2)
In this case, you use a time-independent external hierarchy. Hierarchies are

normally extracted from SAP R/3 Enterprise. Typical standard hierarchies
include Product, Customer, Vendor, Cost Center, and Profit Center.
Ad Hoc hierarchies can also be created in BW. This is appropriate when a
unique, one time requirement arises that cannot be met through a standard
hierarchy from SAP R/3 Enterprise. The result is a flexible solution, which
is offset by the cost of maintaining the hierarchy.

Unit 4: Cube Model BW330: Figure 101: SAP BW Table Partitioning Concept

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 4: Cube Model BW330: Figure 101: SAP BW Table Partitioning Concept

Uploaded by

Copyright:

Available Formats

Unit 4: Cube Model BW330

Figure 101: SAP BW Table Partitioning Concept

This is a simple example of how a reporting scenario can be partitioned

Continued on next page

126 © 2003 SAP AG. All rights reserved. 30-12-2003

Demonstration: Demonstration Exercise 1 (Unit 4)

Continued on next page

30-12-2003 © 2003 SAP AG. All rights reserved. 127

Continued on next page

128 © 2003 SAP AG. All rights reserved. 30-12-2003

99 Exercise 2: BW Star Schema

Continued on next page

Continued on next page

30-12-2003 © 2003 SAP AG. All rights reserved. 129

2. What is the maximum number of partitions to be entered in order to

Continued on next page

130 © 2003 SAP AG. All rights reserved. 30-12-2003

Solution 2: BW Star Schema

Continued on next page

Continued on next page

30-12-2003 © 2003 SAP AG. All rights reserved. 131

2. Now, determine the dimension to which the characteristic

Continued on next page

Continued on next page

132 © 2003 SAP AG. All rights reserved. 30-12-2003

Continued on next page

Continued on next page

30-12-2003 © 2003 SAP AG. All rights reserved. 133

Continued on next page

Continued on next page

134 © 2003 SAP AG. All rights reserved. 30-12-2003

Continued on next page

30-12-2003 © 2003 SAP AG. All rights reserved. 135

Continued on next page

136 © 2003 SAP AG. All rights reserved. 30-12-2003

107 Exercise 3: Characteristics

Continued on next page

Continued on next page

30-12-2003 © 2003 SAP AG. All rights reserved. 137

Continued on next page

Continued on next page

138 © 2003 SAP AG. All rights reserved. 30-12-2003

Continued on next page

Continued on next page

30-12-2003 © 2003 SAP AG. All rights reserved. 139

Field Name or Data Type Values

Description Transitive Query ##

Technical Name Transitive_Q##

Continued on next page

140 © 2003 SAP AG. All rights reserved. 30-12-2003

Continued on next page

Continued on next page

30-12-2003 © 2003 SAP AG. All rights reserved. 141

Save and activate your new InfoObject.

Continued on next page

Continued on next page

142 © 2003 SAP AG. All rights reserved. 30-12-2003

Continued on next page

30-12-2003 © 2003 SAP AG. All rights reserved. 143

Because you marked the attributes as time dependent, the field’s

Continued on next page

Continued on next page

144 © 2003 SAP AG. All rights reserved. 30-12-2003