Account Model Vs KF Model

1) 1 Record in KF model becomes multiple records in Account Model.

2) 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.
Product
P1
Product
P1
P1
P1

Sales Price
100

Manufacturer Price
50

Price Type
Sales Price
Manufacturer Price
Mean Price

Mean Price
75

Price
100
50
75

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

We can add an additional Price type in the account model, because we do

not have to change the data structure.
In the KF model on the other hand, we must add an additional KF to the
structure. (So it actually depends on the frequency of these changes
occurring.
In KF model record length will be more and in Account Model no. of
records will be more.

3) In KF Model we can read only those KFs which are needed in the report.
4) KF Model is used when we are working with a restricted and consistent no. of
KFs.
where as Account model is used when we are working with large and
changing no. of KFs
5) KF Model:
Pro:
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.
Cons:
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.
6) Account Model
Pro

Cons

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.

Current Model:
1) Master data is loaded with Transaction data.
2) What is the reason for segregating source data into CHAR table, Numeric
table, Time series & Flexible list.
- In order to get the transaction data for 1 record, it should read all the
above tools using some Key
- If all the relevant transaction data is stored in different tables then BW can
extract directly from those tables without reading the data from different
tables using the Key and data loading .

Quick Solution:
1) We can consider APD (Tcode: RSANWB), which has a transpose
functionality built inThe target will be a Direct update DSO, which can then
be mapped via normal transformation to Infocube.
2)