Special Features of InfoCubes in InfoSets 

Use

InfoCubes are handled logically in InfoSets like DataStore objects. This is also true for time dependencies.

Features

Request Status

In an InfoCube, the system can read data with different request statuses. In the table view of the InfoCube, you make this setting in the context menu of the rows.

When you use InfoCubes in InfoSets, you can set the request up to which you want to rollup data in the aggregate (rollup), and the request up to which the data is qualitatively correct (qualok). You make these settings in InfoCube administration. The default for qualok is all green requests, where no yellow or red requests exist before them.

For example, requests 1-23 are rolled up into aggregates. Requests 1-27 are qualitatively correct.

In the context of the InfoCube in the InfoSet, the following alternatives are possible for the up-to-dateness of the data of an InfoCube:

●     Rolled Up Data(rollup):

The system only reads the rolled-up requests. This setting is the only setting that allows you to use aggregates under the conditions described in the following sections.

●     Up To Current Status(qualok):

In this case you cannot use aggregates, since the system also has to read data that has not been rolled up.

●     All Green Requests(all):

The system reads all correctly loaded requests. You cannot use aggregates.

●     All Requests(dirty):

The system reads all requests, including requests that were terminated and requests that were not loaded successfully, as well as requests that are currently being loaded. You cannot use aggregates.

For large InfoCubes, only the Rolled Up Data (Rollup) option is useful. This is due to performance reasons. This is the default setting for each InfoCube in the InfoSet.

Using Aggregates

For queries based on an InfoSet with an InfoCube, the system decides at runtime whether aggregates can be used for the InfoCube. This is the case if all the required InfoObjects of the InfoCube exist in an aggregate. The following InfoObjects are required:

●     The key figures of the InfoCube selected in the query

●     The characteristics of the InfoCube selected in the query

●     The characteristics required for a join with other InfoProviders in the InfoSet.

Furthermore, as a prerequisite for using aggregates, all the data required by an InfoCube must be readable using logical access. For an InfoCube within an InfoSet with InfoCubes, it is no longer possible to read part of the data from one aggregate and part of the data from another aggregate or the InfoCube itself.

The system cannot access BI accelerator indexes within an InfoSet.

Interpreting Record Counters for InfoSets with InfoCubes

The record counter of an individual InfoCube renders the number of records that physically exist and are affected by the selection. The record counter depends on the present aggregation status of the InfoCube. If you have chosen an aggregate, the record counter renders the selected number of records for the aggregate, not the number of records in the InfoCube from which the selected records in the aggregate were built.

For InfoSets with several InfoProviders, the key figure values are generally duplicated if all the characteristics affected by the join are not specified in the drilldown of the query. This also applies to the record counter.

Constraints

●     For performance reasons, you cannot define an InfoCube as the right operand of a left outer join.

●     SAP does not generally support more than two InfoCubes in an InfoSet. If you include more than two InfoCubes in an InfoSet, the system produces a warning. There are several reasons for this limitation:

○     Generally, the application server cannot create SQL statements with more than 64kb (in Unicode systems 32k characters). The more InfoCubes you use in an InfoSet, the quicker this limit is reached.

○     In contrast to the star schema (for which the potentially useful database access plans are limited by the table structure), several InfoCubes exist for a join, and several fact tables or DataStore object tables exist if you join InfoCubes with DataStore objects. There is no longer one large table at the center of the schema, and choosing a good access plan is much more difficult. Therefore, the average response time increases exponentially with the number of InfoCubes included.

○     If all of the characteristics affected by the join condition are not in the drilldown of a query, the key figure values of InfoCubes and DataStore objects are duplicated when you join them to InfoProviders (see SAP Note 592785). Therefore, interpreting the results of joins with non-unique InfoProviders becomes more difficult the more InfoProviders you include.

Design Recommendations

●     To avoid problems caused by duplicated key figure values (see SAP Note 592785), we recommend that you only stage the key figures of one DataStore object or InfoCube of the InfoSet for the query (indicator in the first column in InfoSet maintenance).

●     We recommend that you only use one InfoSet object (DataStore object, InfoCube, or master data table) with ambiguous characteristic values. This means that when you join a DataStore object with an InfoCube, as long as the InfoCube contains the visible key figures, all the key characteristics of the DataStore object are used in the join condition for the InfoCube. Equally, when joining a master data table with compounding to an InfoCube, all of the key characteristics of the master data table are joined with the characteristics of the InfoCube.