You are on page 1of 6


Aggregates are subsets (with aggregated data) of fact table data and are stored in InfoCube like
structure. Using aggregates reduces the volume of data that is accessed for each query because data
is stored in a separate aggregate InfoCube, which contains a limited set of characteristics from the
connected InfoCube. Aggregates can be formed on InfoCubes by selecting specific objects
connected to the InfoCube, such as:

Characteristics in dimension tables

Hierarchies associated with the InfoCube

Navigational attributes associated with the InfoCube (This type of aggregate can be costly

to maintain, as any change in the value of the attribute might cause an adjustment or
complete rebuild of the all the aggregates).

'*' - inclusive; the characteristic is used in the summarization

' ' (blank) - exclusive; a characteristic is not used in the summarization

'F' - inclusive with a fixed value; the characteristic is summarized with a specific fixed value

'H' - hierarchy level; the characteristic is summarized for a specific hierarchy level

You can combine several characteristics into an aggregate. Combinations in the restrictions, such as
fixed values or hierarchy levels, are also possible. For example you can have a "Country=Germany ('F'
- Fixed value) & All customers & Materials ('*' - inclusive) " aggregate.
If the InfoCube uses a key figure for which an exception aggregation has been defined, this
characteristic must be included in an aggregate and defined as all ='*'. Restrictions (for example,
fixed value 'F') are not permitted in this case.


An aggregate is represented in the system as an aggregate InfoCube. Each aggregate consists of
two fact tables (E and F). The 'F' fact table of an aggregate is usually empty since aggregates are
compressed automatically and data moved to the 'E' fact table. It also contains at least two
dimension tables: a package dimension and a customer-defined dimension; the unit and time
dimensions are not mandatory.
If an aggreagate has 16 or fewer characteristics (including time, unit and package), each
characteristic is put into a separate dimension. The dimesions (except package and unit) are marked
as Line Item. In the case of a line item dimension, the dimension table is eliminated and the

Characteristic InfoObject's SID is instead written directly to the fact table. When this happens, the
aggregates are called flat aggregates.
If 17 or more characteristics (including time, unit and package) are included in an aggregate, the BI
system may proceed in two ways:

If two or more characteristics come from one dimension in the InfoCube, the DIM ID of the
InfoCube is stored as a key in the fact table.

If only one characteristic comes from one dimension in the InfoCube, the SID is stored as a
key in the fact table. A line-item dimension is used here.

Aggregates using time-dependant master data are called time-dependant aggregates. It is
recommended to you do not automatically enable time dependency for master data (attributes and
hierarchies) unless it is absolutely needed. This is because this important feature can have
unintended consequences and confuse the user. Enabling time dependency also makes aggregate
maintenance much more complicated. Since master data attributes can change based on a specific
key date, aggregates are created for a key date as well.

Filling is the term given to initially loading data into an aggregate. A rollup is the term given to the
process of loading new data from the InfoCube into the InfoCube's aggregates. A rollup takes place
when the InfoCube request is loaded into the aggregates. A rollup can consist of one or more
requests, and the request ID controls the request. The request ID is stored in the package dimension
of the InfoCube. Both filling and rolling up of aggregate can be monitored in SM37.

Steps in the rollup:

1. A new request is written to the InfoCube (a new RNSID in the fact table).
2. New requests are rolled up into the aggregate.
3. During the rollup, the read pointer moves to the new request. The request is now available for
reporting, as it was even during the rollup.
4. It is possible to compress a request (see the Compressing Aggregates section).

Note: Even though new data was loaded to a BI InfoCube, the data is not available on any query
until it has been moved (rolled up) into all the aggregates. This ensures a consistent (yet older)
response whether a query uses a InfoCube or one of its aggregates.


If changes are made to attributes or hierarchies from characteristics used in aggregates, the
structure of the aggregates also needs to be changed. Since changing this data would invalidate the
aggregates, you are not able to activate hierarchies or navigation attributes directly; you are only
able to flag them for activation. This means that navigation attributes and hierarchies have two
versions: an active version and a modified version. The changes are made during a change run for
hierarchies or attributes. While the changes are being made and the change run is active, the old
data is used in reporting until the aggregates have been reconstructed. A change run is usually
executed after master data is loaded via a process chain.
Use the monitor function (RSA1 Administration Button Change Run) to check which objects are
affected by the change run. This shows you which characteristics and hierarchies are activated and
which aggregates and InfoCubes are affected. If the change run is active, the monitor shows you
whether the changes are active for each aggregate.

Aggregates can be automatically compressed during the rollup. The request(s) are written to the E
fact table of the aggregate InfoCube. This removes the request ID. The option to compress the
aggregate automatically after roll up is available via the Manage Context Menu option > Roll Up tab

for an InfoCube.


To determine if using an aggregate can improve query performance, run the query in RSRT.
Check if any of the following conditions meet:

Records Selected (DBSel) / Records transferred (DBTrans) > 10

Records Selected > 10,000

DB Time (Data Manager) > 30% of total time

DB Time > 3 seconds

When using a MultiProvider, use ST03 to determine query runtimes for each InfoCube in the
MultiProvider individually.


A change run refers to the:

Activation of changed master data

Activation of changed hierarchies

Recalculation of aggregates containing navigational attributes or hierarchy levels

The change run, also called the hierarchy-attribute realignment run, adjusts the data in the
aggregates and turns the modified version of the navigation attributes and hierarchies into an active
version. In almost every phase of the change run, you can carry out reporting on old master data
and hierarchies. If there are any changes to master data, they are not available for reporting until
the change run is executed and finished.
During master data activation, all affected aggregates are recalculated (either new rebuild or delta
mode depending on setting for Delta mode (RSCUSTV8)).
During master data activation, it is not possible to perform a rollup for any InfoCube. This holds
even if the aggregates for a specific InfoCube do not contain any navigational attribute or hierarchy
and are therefore not affected by the master data activation at all. The master data activation simply
locks all InfoCubes against rollups. The master data load and the hierarchy load are also locked for
the affected objects.


You can reach this setting with transaction SPRO SAP Customizing Implementation Guide

SAP NetWeaver Business Intelligence Performance Settings Parameters for Aggregates.

Here you have the following settings:
1. Percentage change in the delta process
You can customize the limit when the change run switches from delta to full recreation mode. This
limit is defined as a percentage of changed master data. The default threshold is 20, which means if

more than 20 percent of the master data is changed, all affected aggregates are completely rebuilt.
If no value is set, the aggregates are completely rebuilt every time.
2. Block size:
If the source (InfoCube or aggregate is very large when you fill an aggregate, the system reads the
data a portion at a time. Block size determines approximately how large each of these individual
portions are.
The block size you choose depends on the amount of temporary table space available on the
database. If the parameter is too small, there are too many read processes and this increases the
runtime. If the parameter is too large, the temporary table space on the database overflows

Basis-Aggregates have the following features:

Contain no navigational attributes or hierarchies. However, they may contain navigational

attributes or hierarchies that are changed very rarely or only slightly.

Are built to avoid accessing the InfoCube during the change run when realigning data in the

Are useful only if they are much smaller than the InfoCube and can be read by several
aggregates during a change run.

Note: The goal of a basis aggregate is to decrease the time needed for the change run.

A probably useless aggregate is:

Too large compared to the InfoCube or the aggregate that it is created from. E.g. An
InfoCube with 7,000,000 entries, an aggregate 6.800.000 entries. Runtime on InfoCube 20.5s,
runtime on aggregate 20s.

Used infrequently or not used at all. Two aggregates contain the almost the same
characteristics. Aggregate 1 has 400,000 entries, aggregate 2 has 350,000 entries. Combine
both aggregates to one aggregate with 450,000 entries or delete one aggregate (depending
on the situation).

Quite similar to another existing aggregate. An aggregate is not used by a query at all or the
last time an aggregate was used is long ago.


A large aggregate containing navigational attributes may be performance beneficial despite

its size.

Basis Aggregate may not be used for reporting but still be useful for maintenance.