Indexes

Indexes for summarization levels

Indexes let you optimize how the system accesses the summarization levels. Maintain the characteristics before you define indices, since which characteristics are allowed for the indexes depends on the characteristics.

At first it is not necessary to define indexes explicitly. When you save the level, the system creates a default , which is usually sufficient. However, as the data volume in the summarization levels rises, it makes sense to optimize the levels.

Note that you need to delete the data in the summarization levels and refill it after changing the indexes.

You can create up to 15 indexes. For each index, the system creates a database index on the key table (see the manual). The more indexes you create, the better the system supports the various selections. However, additional indexes make it take longer to update the levels.

Two types of indexes are allowed:

1. single column index:

Here you create an index for only one characteristic. To define a single column index, enter only one characteristic name.

Note: All the indexes the system proposes as defaults are single column indexes.

2. multi column index:

You can enter up to five characteristics for one index at a time. This makes sense to do if you want to access combinations of characteristics efficiently (for example, in reports).

Note that which characteristics you can choose for an index depends on the definition of the characteristics. Indexes are only allowed with certain characteristics ("*" in the list of characteristics). Press F4 to display the valid characteristics for indexes.
Maintain all the characteristics before you create indexes. If necessary, changes are made to the list of characteristics for the indexes.

Example:

You have a summarization level with the characteristics "Product group" and "Customer group". In a report, you display a list of customer groups for a single product group. This is supported ideally using an index for the field "Product group". The opposite order, however -- all the product groups for one customer group -- would require the system to read all the data. By creating a second index for the field "Customer group", you can support this as well.