Summarization Levels 
Summarization Levels
Definition
A summarization level saves transaction data in compressed form. In such transaction data, individual objects are described using a range of characteristics. Summarizing means that selected characteristics are left out. Objects from the original dataset which are no longer differentiated once characteristics have been left out are summarized in one object in the summarization level. The aggregated data is available to all reports. The summarization allows for quick access to the data in reporting-
Use
Typically, reports are required in which the end user can navigate from a high summarized level down to the level of detail which is of business interest to him or her. The selected report data is contained in the main memory. This can create a large volume of data and cause long response times. There are various alternatives for improving the response time of a report. See the section
Optimizing Performance. In this section, the alternative using summarization levels is described, and the guidelines according to which you summarization levels are to be defined are also explained. For information about how to create and build up summarization levels, see Customizing.The example below shows how the transaction data records can be summarized on the database in order to improve reading times in the report.
Employee xxx in cost center 100 in company code 1000 worked 50 hours overtime.
Employee yyy in cost center 100 in company code 1000 worked 30 hours overtime.
Employee zzz in cost center 200 in company code 1000 worked 20 hours overtime.
If the transaction data were transferred in this way, three records could be written in the transaction data table:
Employees |
Cost center |
Company code |
Overtime |
xxx |
100 |
1000 |
50 |
yyy |
100 |
1000 |
30 |
zzz |
200 |
1000 |
20 |
As a rule, relatively few analysis paths are used in reporting, so you could define a summarization level for the example above.
A summarization level is formed at the cost center level, which means that a summarization is made over the characteristic employee. The records are compressed together and the following structure ensues:
Cost center |
Company code |
Overtime |
100 |
1000 |
80 |
200 |
1000 |
20 |
In this case, you could set the summarization level even higher, by forming it at the company code level.
Company code |
Overtime |
1000 |
100 |
The more characteristics that are summarized, the higher the level of compression of the data and the more limited the use of the level. You must decide between the shortened response time because of the level of summarization, and the possible use of the level in reporting. Highly summarized data will not be of much use to you if it can only be used in very few reports.
At the definition stage, you have the following options:
The key figure values are summarized over a characteristic.
Afterwards, you can no longer evaluate the characteristic in the report.
The key figure values cannot be summarized over the characteristic.
Afterwards, you can evaluate whatever characteristic values you like in the report.
The key figure values can only be retained for a certain characteristic value.
Afterwards, you can only evaluate this characteristic value in the report.
Depending on how you have specified a characteristic in your report, you decide whether a characteristic is to be summarized, given a fixed value, or left free. You define the summarization levels in Customizing. To ensure that the summarization levels can be used by reports, the levels have to be supplied with data. To do this, you schedule a job in the background processing to build up the summarization levels. Only then can the levels be used by reports. After the levels have been built up, the system always updates data as soon as changes occur in the transaction database. The summarized data is therefore always as up-to-date as the transaction data. For more information, see Customizing.
When executing a report, the system checks whether saved data is available for the report. If data has already been saved, it will be displayed. If no data has been saved for the report, but a suitable summarization level exists, the data from the summarization level will be called up. If neither saved data nor a suitable summarization level are available, the data is selected as new.
When Do I Use Summarization Levels?
If you are not satisfied with the response times of the reports in you system, you should consider defining some summarization levels.
However, before you decide on summarization levels, you should read about other ways of improving response times. See the section
Optimizing Performance
/SAPIrExtHelp/IWB_EXTHLP.asp?_LOIO=5CC1C7BC445F11D189F00000E81DDFAC.
Guidelines for Creating a Summarization Level
When defining a summarization level, there are often several possible combinations of characteristics. Since not every summarization level can produce an improvement in response times compared to a report executed online, there are guidelines for defining summarization levels. To obtain the optimum summarization effect, you must analyze the desired report for each summarization level, determine which master and transaction data is affected and consider the following points:
1. A summarization level should contain as few records as possible compared to the number of records in the transaction data.
Estimate the number of records to be read on the database, and the number of records in your planned summarization level. A minimum factor of 10 should be attained.
Where possible, summarization levels should be defined over characteristics with a large number of values. You can attain a greater summarization effect if you summarize over the characteristics article and product, as these characteristics typically contain a large number of values.
If your summarization level contains a large number of records, the corresponding report must be defined in such a way that it does not have to read more than 10,000 to 20,000 records from the summarization level.
2. As few summarization levels as possible should exist
Since the summarization levels are updated automatically, each change in the transaction data leads to an update in all summarization levels. This means that a change to one transaction data record leads to several writing processes in the database. If there are a large number of summarization levels, this will impair performance in data transfer.
If you generate a proposal for a summarization level, you should edit it manually. You should also check whether a similar summarization level already exists. You will find this information when maintaining the summarization levels in the overview and detail screen. You should check this data occasionally for all summarization levels, as the number of accesses, for example, can help you to decide whether a particular level is still required. For more information, see Customizing.
3. Dependent characteristics should always be included in a summarization level.
In many cases there is a dependency between several characteristics. If, for example, the product group is derived from the product number, then the product group is dependent on the product. The volume of data in the summarization level is not enlarged by the inclusion of the product group and therefore does not impair performance. The advantage is that the summarization level can also be used by reports which contain these dependent characteristics.
The dependency between two characteristics normally exists because of derivation or is already given by previous systems, for example a representative for customers in a customer master.
A detailed description of how you create and build up summarization levels is given in Customizing.
For an example of defining a summarization level, see
Example: Optimizing Performance.