Aggregation Level

Simple Aggregation Level

A real-time InfoCube is the basis of a simple aggregation level or of a DataStore object for direct updates in planning mode. For a basic example, see Simple Aggregation Level.

Complex Aggregation Level

Complex aggregation levels are based on MultiProviders containing at least one real-time InfoCube or DataStore object for direct updates in planning mode, but no simple aggregation level.

Like MultiProviders, aggregation levels cannot be nested.

With a complex aggregation level, note how data records from the InfoProviders included in the MultiProviders are embedded in the MultiProviders (and thus also the aggregation levels) and how the system writes changes to data records of the aggregation level back to the InfoProviders included in the MultiProviders. For more information on these MultiProvider-specific features - with simple examples - see Complex Aggregation Levels.

The following conditions apply for both aggregation level types:

• The aggregation level must contain at least one key figure and one characteristic.

• The key figures used here must have the database aggregations SUM, MIN, MAX or NO2. With MIN or MAX, key figure values can only be displayed. They cannot be changed using manual planning or planning functions.

• For key figures of type date or time, only data type 'DEC'is supported.

• Referencing key figures (and therefore non-cumulative key figures or elimination of internal business volume too) are not supported in aggregation layers.

• If a characteristic is compounded and used in an aggregation level, the aggregation level must also contain all compounding "parent" characteristics.

• If a key figure is used in an aggregation level and does not have a fixed unit of measure or currency, the aggregation level must contain the associated characteristic for the unit.

• If a key figure with exception aggregation is used in an aggregation level, the aggregation level must also contain the characteristic for exception aggregation if it occurs in the underlying InfoProvider.

• The aggregation level inherits a navigation attribute from the underlying InfoProvider if it includes the basic characteristic of the navigation attribute. Note that the navigation attribute for an aggregation level is not visible in the Planning Modeler. It is only visible in the Query Designer.

• An aggregation level cannot be created on MultiProviders if a characteristic of an InfoProvider contained in the MultiProvider supplies two different characteristics in the MultiProvider.

• If a characteristic on the InfoProvider that serves as the basis for an aggregation level is constant, this characteristic has to be included in the aggregation level.

• An aggregation level that uses a DataStore object for direct updates in planning mode (in either direct or indirect conjunction with a MultiProvider) must contain enough characteristics to fill the DataStore object key. If the key fields are not all directly included in the aggregation level, then characteristic relationships are required to derive the missing key fields from the characteristics included in the aggregation level.

  Note

  In some cases, this condition cannot be fully checked in the aggregation level modeling, because the derivation steps are only performed at runtime. Therefore the situation might occur where the system only checks incomplete modeling at runtime and cannot change the data using planning functions (cells in queries are no longer input-ready).