Business Intelligence

Integrated Planning
Modeling

Tuesday, October 23, 12 1

 Modeling: Overview
Unit Overview

•Design of an InfoProvider

•MultiProvider in Planning

•Authorization Objects in Planning

Tuesday, October 23, 12 2

 Designing InfoProviders
• SAP BI-IP Consultants Need to Know:
• How to Differentiate between a Key
Figure Model and an Account Model
• The advantages and disadvantages of both
modeling approaches
• How to assess the performance aspects
of both modeling approaches

Tuesday, October 23, 12 3

 DATA MODELING: KEY FIGURE MODELS VS ACCOUNT MODEL
Key Figure Model
Product Sales Price Mfg. Price Mean Price

P1 100 50 75

All key figures are in a data record

Account Model
Product Price Cat Price The price category characteristic
P1 Sales Price 100 replaces the key figures of the key
P1 Mfg. Price 50 figure model, namely in connection
P1 Mean Price 75
with one single key figure

• You can approach the planning with two different modeling strategies, although you must already decide which of the modeling versions you want to use,
the “key figure model” or the “account model”, when you are creating an InfoProvider

• The above illustration uses a simple example to show how the terms key figure model and account model are defined.

• You should use the Key Figure Model when:

• you are working with a limited, and in particular a constant, number of key figures and
• all or at least a large proportion of these key figures of a data record are also used in the other data records
• You should use the account model when
• you are working with a high and in particular, a varying number of key figures and
• most of the key figures within a data record would be empty in the key figure model
• It is easy to add another price category (see example above) in the account model, because the data structure does not have to be changed. In the key
figure model, on the other hand, an additional key figure must be added to the InfoProvider. The extent to which this difference can be seen as an
advantage or disadvantage largely depends on the frequency with which the changes are to be expected.

Tuesday, October 23, 12 4

 PERFORMANCE AND REQUIRED MEMORY

Memory requirement of Reading time

the application server depends more on the
depends equally on the number number of data records than on
and length of the data records their length

The decision “Key Figure Model or Account Model” should generally be based
on which model is better suited to the respective planning process!

• The transaction data is stored in the BW system. Investigations have shown that the reading time largely depends on the number
and not the size of the data records.

• The previous example shows that a switch from the key figure model to the account model increases the number of data records by a factor
of 3, resulting in longer reading times. The increase factor depends on whether all key figures are used in every data record in the key figure
model, because if you switch to the account model, only those data records are created for which the key figure is not equal to zero.

• The transaction data is stored in main memory of the application server after it is read from the BW system. The
amount of memory required depends, among other things, on the number and length of the data records, whereby the
length is influenced by the selection of the data model:
in the key figure model, the data records are longer than in the account model, and they therefore require more memory per
data record.

• Depending on the relationship between the data record length and number, either the key figure model or the
account model will take up less memory.

• The performance of a planning function strongly depends on the number of data records. Therefore, it should be possible to
execute it faster in a key figure-based model than in an account-based model. On the other hand, the data records in a key figure model can
also become large, which also has an impact on performance. Thus a planning function sometimes can be slower in the key figure-based
model.

Tuesday, October 23, 12 5

 DIRECT COMPARISON OF KEY FIGURE MODEL AND ACCOUNT MODEL 1/2
Key Figure Model
Pro Con

A separate key figure is required

Creation of Key Figures for specific
for every account and totaling
usage
level

The subsequent creation of key

No key figure - characteristic value figures, and the removal and
relationship has to be modeled addition of key figures in an
InfoProvider is time-consuming
Possible performance losses due to
The plan query structure is easy to
larger data records in database
create
tables and planning buffers

InfoProvider requires a large

Formulas are easy to create number of key figures, while a
maximum of 233 key figures can be
included per InfoProvider

• The table above lists the advantages and disadvantages of the key figure model.

Tuesday, October 23, 12 6

 DIRECT COMPARISON OF KEY FIGURE MODEL AND ACCOUNT MODEL 2/2
Account Model
Pro Con

Fewer key figures in the Account master data must

InfoCube, fewer columns in
the flat file
Advantages of using
characteristic hierarchies
in queries by simply adding
the hierarchy node
Less InfoObjects to build
for the InfoCube
be loaded
Possible performance
losses due to more data
records in database tables
and planning buffers

Fewer columns in the flat

file

Modifications during
configuration are simpler.
Simply add a hierarchy
node or a characteristic in

• The table above lists the advantages and disadvantages of the account model.

Tuesday, October 23, 12 7

 Designing InfoProviders
Summary
• SAP BI-IP Consultants Now Know:
• How to Differentiate between a Key
Figure and an Account Model
• Evaluate the advantages and
disadvantages of both model approaches
• Evaluate the performance aspects of both
modeling approaches

Tuesday, October 23, 12 8

 Modeling: Overview
Unit Overview

•Design of an InfoProvider

•MultiProvider in Planning

•Authorization Objects in Planning

Tuesday, October 23, 12 9

 MULTIPROVIDER IN PLANNING:

At the completion of the lesson, you will

be able to:
Understand concepts for planning with
MultiProviders
Assess the use of MultiProviders and
data transfer processes for planning

Tuesday, October 23, 12 10

 MULTIPROVIDER IN PLANNING: BUSINESS SCENARIO

In this modeling scenario, you will be

looking at the use of MultiProviders

Tuesday, October 23, 12 11

 MULTIPROVIDER

MultiProvider

MultiProvider
InfoProv
ider

DataStore Aggregation
InfoCube MasterData InfoSet
Object Level

Tuesday, October 23, 12 12

 ADVANTAGES AND DISADVANTAGES OF A MULTIPROVIDER
File Manager

During runtime, split which Data Selection

selection relates to which InfoProvider 1
InfoProvider

Data Selection
InfoProvider 2

MultiProvider

Parallel read statements

InfoPr

DataStore Aggregation
InfoCub MasterData InfoSet
Object Level
MultiProviders are used very often in practice because they are very flexible

An advantage is that if new InfoProviders are created, they can very easily be included in the modeling of the MultiProvider, and
that the queries already existing for the MultiProvider do not have to be adapted

New queries for the MultiProvider with reference to the subsequently integrated InfoProvider can be correctly addressed with
reference to the “InfoProvider” field in the query

A disadvantage with respect to a simple InfoProvider is that in a MultiProvider scenario, at runtime a split is always effected for all
selections, as to which InfoProvider subordinate to the MultiProvider the selection comes from. In contrast to BW-BPS, the
related rad statements in the BW-Integrated planning are not executed sequentially but in parallel, with the aid of the file
manager.

Tuesday, October 23, 12 13

 MULTIPROVIDER IN PLANNING: MODELING I
➡Planning functions and queries
Planning and
reporting on an are located on an aggregation level
aggregation level ➡Data used by planning functions and
queries has the granularity

MultiProvider
InfoProvider

Real-Time DataStore
InfoCub InfoProvide InfoObject
Object

The above illustration shows a first modeling option for MultiProviders.

As you will notice, all the aggregation levels are created on the MultiProvider, so that both the planning -that is, the planning
functions - and the plan queries can be set up on the same aggregation level. This reduces the frequency of errors and the
granularity of the planned and reported data is the same!

If reference data is required for the actual status, it can be read from the “InfoCube” or the “DataStoreObject”, for example.

Tuesday, October 23, 12 14

 MULTIPROVIDER IN PLANNING: MODELING II
Data from planning function
Reporting on MultiProvider and queries can have different
granularities.
MultiProvider

Aggregation Levels

Planning on aggregation levels

Real-Time
Real-Time InfoCube
InfoProv
The above illustration shows a second modeling option for MultiProvider.

Here a MultiProvider is placed on at least one aggregation level, but otherwise also additionally on other InfoProviders, so that
the above MultiProvider is only suitable for reporting.

A planning function, on the other hand, must be created on an aggregation level - this is not possible directly on a MultiProvider

The advantage of this model approach is that the underlying aggregation levels and other InfoProviders and their data records
can have a different granularity.

Thus the plan data from real-time providers could be planned on a quarterly level, and the actual data of the InfoCube could be
kept on a monthly level.

In a query on the MultiProvider that combines this data, the granularities could be “mixed”, for example by corresponding
selection in the data columns of the query.

Please note that multiple aggregation levels can be used in a query simultaneously

Tuesday, October 23, 12 15

 MODELING PREREQUISITES FOR AN INPUT-READY PLAN QUERY

Simple aggregation level Complex aggregation level

MultiProvider

Mandatory!
Real-Time MultiProvider
InfoProvider

Planning on aggregation levels

Real-Time
InfoProvider InfoCube DataStore InfoObject

Aggregation levels are used as InfoProviders for an input-ready query

In general, an aggregation level can be defined on a real-time InfoProvider. This is then known as a simple aggregation level.

If an aggregation level is defined on a MultiProvider, this is known as a complex aggregation level

In this case, a simple aggregation level may not be subordinate to a MultiProvider. On the other hand, at least one real-time InfoCube (direct) must be
subordinate to the MultiProvider

1. To define an input-ready query, you can choose between two basic models:
1. Directly on a complex aggregation level
2. Directly or by means of a MultiProvider on a simple query.

Please note that aggregation levels and MultiProviders cannot be nested, which means that one aggregation level cannot be located in another aggregation
level

Tuesday, October 23, 12 16

 SIMPLE AGGREGATION LEVELS
The following example shows how the system operates when a key figure has been changed (manually
or automatically)

Product Product Version Year Group

Group Sales Fact table of the real-time InfoProvider

P! PG1 V1 2010 10
P2 PG2 V1 2010 20
P3 PG3 V1 2010 42

Product Version Year Group Sales

Group
Aggregation level
(aggregation by means of Group Sales key
figure)(aggregation SUM)
PG1 2010
V1 30 40
PG2 2010
V1 42

Product Product Version Year Group Delta record in fact table of the real-time
Group Sales
InfoProvider
-># For product that was not included in
planning of aggregation level

# PG1 V1 2010 10

A simple aggregation level can only be created ona real-time InfoProvider

Tuesday, October 23, 12 17

 COMPLEX AGGREGATION LEVELS
The following examples show:
•COMPLEX
how the system embeds dataLEVELS
AGGREGATION records from the InfoProviders contained in a MultiProvider into the
MultiProviders and
• how the system writes new or changed data records of the MultiProvider back into the
InfoProviders contained in this MultiProvider

Product Product Version Year Profit

Group Actual data in InfoCube 1 in product and
product group granularity
P1 PG1 V1 2010 10

Product Version Year Profit

Group Plan data in InfoCube 2 in product group granularity

PG1
V1 2010 30

InfoProvider Product Product Version Year Profit Data records in the MultiProvider or in
Group the aggregation level of the
MultiProvider
InfoCube1 P1 PG1 V1 2010 10
InfoCube2 # PG2 V2 2010 30

In the case of a more complex aggregation level that is created on a MultiProvider (compare the figure “Modeling Prerequisites for an Input-Ready Plan
Qyery”), the above figure shows that in the related aggregation levels, the “InfoProvider” characteristic must always be included in order to enable the
reading and writing of data on a source-related basis

This characteristic of the MultiProvider enables you to, for example, copy actual data from one InfoProvider to another, whereby the copy function for the
aggregation level of the MultiProvider must be created.

The MultiProvider technology is thus an option in BW-Integrated Planning for the cross-InfoProvider processing of data.

It is a prerequisite that the target InfoProvider must be a real-time InfoProvider.

Tuesday, October 23, 12 18

 MODELING THE STORAGE OF PLANNED AND ACTUAL DATA

Separate Data Storage Shared Data Storage

Reporting Planning

Reporting Planning

Actual and Plan Data

How was the plan data put into

the InfoProvider
Copy Function

DTP
Actual
Plan Data
Data
Actual Plan Actual Plan
Advantages of separate data storage:

No duplicate data storage

Lower administrative overhead

Is used when actual and plan data are structurally very similar, whereby the granularity of the actual or plan data can be finer or coarser

Disadvantages of separate data storage:

Reporting is difficult if the granularity of actual and plan data differs too greatly

Advantages of shared data storage

The structure of the data can be changed with respect to the original data, so that decoupled, shared reporting of actual and plan data is possible

Disadvantages of shared data storage

Redundant data storage

Tuesday, October 23, 12 19

 MULTIPROVIDER VERSUS DATA TRANSFER PROCESS 1/2
Data Transfer Process

?
MultiProvider with Planning Function

Actual Plan
Advantages of the data transfer process
Less memory is needed on the server as no buffering mechanism is used
Before writing into the database you can drop the database indices, write the data, and then create the indices again. This is considerably faster
than updating the indices after each new data record.
Due to the optimization of the parallelization, this process is faster than a planning function

Disadvantages of the data transfer process

As you are using a real-time InfoProvider as target you have to switch it to “load enabled” before the staging process starts and back to “planning
enabled” afterwards. During that time and during the load process, nobody can perform planning on the InfoProvider

Tuesday, October 23, 12 20

 MultiProvider in Planning:
Summary
• SAP BI-IP Consultants Now Know:
• The concepts for planning with
MultiProviders
• How to use MultiProviders and the Data
Transfer Process for Planning

Tuesday, October 23, 12 21

 Modeling: Overview
Unit Overview

•Design of an InfoProvider

•MultiProvider in Planning

•Authorization Objects in Planning

Tuesday, October 23, 12 22

 Designing Authorization
Objects in Planning

• SAP BI-IP Consultants Need to Know:

• Which authorization objects the
Integrated Planning module contains

Tuesday, October 23, 12 23

 AUTHORIZATION OBJECTS IN BI-INTEGRATED PLANNING

Query Query Query

Aggregation Aggregation
MultiProvider
Level Level

Aggregation
MultiProvider
Level

Actual Actual
Plan InfoCube Plan InfoCube Plan InfoCube
InfoCube InfoCube

Relevant for S_RS_COMP Relevant for Analysis Authorizations

For the BI-Integrated planning, the user basically needs the same authorizations as for the analysis of data in a query

In addition, along with the authorization for displaying data, the authorization for changing data is also required in the analysis authorization.

There are two types of authorization check:

Check for standard authorizations:

The authorization object S_RS_COMP is checked with the activity Execute.

The user requires the authorization for the InfoProvider on which the query is defined.

Check for analysis authorizations:

For a query on an aggregation level that was itself defined on a MultiProvider, the aggregation level is authorized for the field RSINFOCUBE in S_RS_COMP. In the
analysis authorizations, on the other hand, you use the MultiProvider

Tuesday, October 23, 12 24

AUTHORIZATION OBJECTS IN BI-INTEGRATED PLANNING

Authorization Objects

Analysis Authorization Authorization Objects

S_RS_ALVL Authorization for working with aggregation levels

Dig Deeper in BW
365 Course S_RS_PLSE Authorization for working with planning functions

S_RS_PLSQ Authorization for working with the planning sequence

Authorization for working with planning function types

S_RS_PLST

S_RS_PLENQ Authorizations for maintaining and displaying lock settings

The above illustration shows the authorization objects for business planning in object class RS

Tuesday, October 23, 12 25

 Designing Authorization
Objects in Planning:
Summary

• SAP BI-IP Consultants Now Know:

• Understand which authorization objects
the planning contain

Tuesday, October 23, 12 26