
Optimizing Response Times
This section contains notes about the optimization of response times in a report. It is most relevant for the project team and the system administrator.
Typically, in an executive information system, reports with aggregated data are required. In these reports the end user navigates down to the level of detail which is of business interest to him or her. If the report is executed, the transaction data records are read and summarized so that the user can navigate as he or she wishes through the free characteristics selected in the report definition. Further summarizations over the free characteristics take place during the terminal session, in order to put the lists together. This data is contained in the main memory and can sometimes lead to a large volume of data and longer response times. In order to read 100,000 records of a length of 500 bytes from the hard-drive, the system typically requires about 3 minutes. The quantities of data are often much larger than that. This means, that in many cases, executing reports online takes too long. In the following section we detail some of the possibilities for obtaining optimal response times in reporting.
Executing the Report Online
To call up a report, which reads data from the transaction database, with an appropriate response time only small quantities of data should be read. As a rule, it makes sense to execute reports of up to 20,000 records online. With special tuning measures this figure can be higher, for example, when the database buffer is enlarged and access to the hard drive is no longer required. Creating special indices can also be of use. The details of the tuning measures are dependent on both the database system and the operating system.
Executing the Report in the Background and Saving Data
You can execute a report in the background and save the data contained in the main memory. This data is then known as saved data.
This method has the advantage that the end user does not have to wait for the reading of transaction data. The report can be scheduled in the background and the end user automatically receives the most recently saved data. The saved data is also in exactly the level of detail which the end user requires. A report with saved data can be called up much more quickly than a report which is executed online, since little demand is placed on the database server.
The disadvantage of this method is that you must create a variant for each variable combination. This can be troublesome if many, different variable combinations are required. However, these variants can be summarized in one variant group and executed together in the background
With large, complex reports it makes sense to use saved data..
Summarization Levels
You can reduce the quantity of data to be read (and, therefore, the response time of a report) by holding the dataset in a summarized form. These summarized datasets are called summarization levels. You can determine both the number of levels required and the respective degree of detail.
This process does not just have the advantage that the data which is read from the summarization levels can be called up quickly, the data is also always up to date compared to the saved data. The data is always updated at the same time as the aspect transaction database. A disadvantage of this process is that the data transfer becomes slower with an increasing number of summarization levels.
The use of summarization levels makes sense if the data is required by several reports.
As not every summarization level can produce an improvement in response times compared to a report which is executed online, there are guidelines for defining your summarization levels.
Using the Report-Report Interface
With the report-report interface you can connect several individual reports, each with a limited number of characteristics, to one another like building blocks in order to be able to navigate from highly aggregated objects into detail, or to other types of objects. To achieve optimal response times you start with a highly summarized report. Few free characteristics should be included in this report. Using the report-report interface you can call up (connected) reports, which contain additional characteristics with which the objects are described in more detail. These connected reports normally have good response times as only a small and very specific quantity of data must be selected.

These processes are in many cases not mutually exclusive. A better result is often attained with a combination of the methods, for example,
See also:
Freezing Report Data and Printing Reports in the Background Summarization Levels
Overview: Report/Report-Interface