Data Modeling: Key Figure Model and Account Model (SAP Library

Data Modeling: Key Figure Model and Account Model

Definition

You can use two different modeling strategies to carry out a planning project in BW-BPS. To illustrate these strategies in terms of a data model, the following terms are used:

· Key figure model

· Account model

Caution

You have to consider the data modeling aspects for the entire procedure as soon as you begin to create InfoCubes.

This simple example shows how the terms key figure model and account model are defined.

Example

You want to assign several key figures (sales price, manufacturer price, mean price) to a characteristic (product P1). The key figures have the same unit (currency EUR).

The key figure model includes all the key figures in one data record:

Product	Sales Price	Manufacturer Price	Mean Price
P1	100	50	75

However, in the account model, you add a new characteristic which separates the key figures (here: price types) within the data record, and which you can use to determine which key figure is being used for planning.

Product	Price Type	Price
P1	Sales Price	100
P1	Manufacturer Price	50
P1	Mean Price	75

Use

Use the key figure model if:

...

1. You are working with a restricted and consistent number of key figures, and

2. Each, or at least a large proportion of the key figures in the data record are also being used in the other data records.

Use the account model if:

...

1. You are working with a large and changing number of key figures, and

2. Most of the key figures would have no value in a data record in the key figure model.

Note

If your planning model requires it, you can use different data models in different InfoCubes. In this case, you are able to convert or transform data from one data model into another data model using FOX formulas, which assign the respective combinations.

As a general rule: Subsequently converting the data model (from the key figure model to the account model and vice versa) involves a large amount of work. Instead, it is better to create a new InfoCube.

In the account model, adding an additional price type (see the example above) does not pose a problem as the data structure does not have to be changed. However, in the key figure model, an additional key figure has to be added to the structure. The extent to which this difference is to be seen as an advantage or a disadvantage depends on the frequency of changes expected.

Performance and Required Memory Capacity

Transaction data is stored in the BW system. Analysis has shown that the read time depends essentially on the number of data records and not their size. Even in the example above you can see that if you change from a key figure model to an account model, the number of data records increases by a factor of 3; consequently, longer read times can be expected.

When determining the factor, also consider that in the key figure model, not all key figures are used in every data record. This means that upon switching to an account model, only those data records are generated that have key figures that are not zero.

Example

If, in the example above, the key figure sales price was not being used, only two data records would be generated and the factor is reduced to 2.

After being read from the BW system, the transaction data is stored in the working memory of the application server. Among other things, the memory space required depends on the number and length of the data records. As discussed, the length of the data record is influenced by the choice of data model; in the key figure model data records are longer than in the account model, and they use more memory space per data record. Whether less memory space would be used by the key figure model or the account model depends on the ratio between the number and length of the data records.

If the data model is changed, the planning functions also have to be revised. According to the sort of calculation you want to perform, one model may have advantages over the other.

This graphic is explained in the accompanying text

For more information on forecasts, see SAP Note 407563.

Direct Comparison of Key Figure Model and Account Model

The following table shows the advantages and disadvantages of each data model.

Key Figure Model

PRO

CONTRA

· Key figures are created for a specific usage.

· When configuring the system you do not have to think about whether a key figure has a reference to characteristic properties.

· The planning layout is easily structured.

· Formulas are simple.

· A separate key figure is required for each account and summation level.

· Creating and deleting key figures in an InfoCube that has already been loaded is not straightforward.

· Selection variables cannot be used in BEx and BW-BPS.

· BEx queries cannot be structured as flexibly.

· Possible negative effect on performance due to the size of data records in the database table and planning buffer.

Account Model

PRO

CONTRA

· Fewer key figures in the InfoCube, fewer columns in the flat file.

· Advantages offered by ability to use characteristic hierarchies.

· Configuration is simpler; Simply add hierarchy nodes.

· Use of selection variables in BEx and BW-BPS.

· BEx queries can be structured flexibly.

· Account master data has to be entered from customer data.

· Planning layouts in manual planning have to contain hierarchies in order to retain the order of account characteristics in the lead column. As a result, unnecessarily long hierarchies have to be entered. An understanding of the InfoObject hierarchy concept is necessary.

· You always get subtotals in the planning layout, unless you deactivate Total.

· Possible negative effect on performance due to the number of data records in the database table and planning buffer.

Data Flow

You can use multi-planning areas to transfer and convert data from one InfoCube to another. The different data models (key figure model, account model) are no obstacle. For more information, see Multi-Planning Area.