In SAP BW, what are aggregates in the context of an InfoCube?

Introduction / Context:
Aggregates in SAP BW are an important performance optimisation technique used mainly with classic InfoCubes. When queries repeatedly access similar combinations of characteristics at higher aggregation levels, reading directly from the full InfoCube can become slow, especially for very large fact tables. Aggregates provide a way to pre summarise data so that queries can be answered more quickly. Certification exams often test whether you understand that aggregates are subsets of InfoCube data, not independent cubes or technical indexes.

Given Data / Assumptions:

• We are working with classic InfoCubes in an SAP BW system.
• Some queries repeatedly request similar aggregated views, such as totals by region and product group over time.
• Response time is critical and the underlying fact table is large.
• The system supports the creation and maintenance of aggregates.

Concept / Approach:
An aggregate is a smaller, specialised summary table that contains pre aggregated values for a subset of an InfoCube based on chosen characteristics and key figures. When a user runs a query whose selection and aggregation level match an existing aggregate, the system can read from the aggregate instead of scanning the full fact table. This reduces I/O and improves response times. The aggregate is conceptually a subset of the cube data, not a standalone cube. It must be built and rolled up when new data is loaded to keep it synchronized with its parent InfoCube.

Step-by-Step Solution:
Step 1: Recall that queries often do not need the most detailed level of the fact table but instead require totals at certain characteristic combinations. Step 2: Understand that aggregates are created to hold these pre summarised totals for frequently used aggregation levels. Step 3: Recognise that an aggregate does not store all the detail rows from the InfoCube, only the aggregated subset defined by its design. Step 4: Compare the answer options and choose the description that explicitly states that aggregates are specialised summary tables holding pre aggregated subsets of an InfoCube for performance. Step 5: Select option a as the correct answer.

Verification / Alternative check:
Consider a Sales InfoCube that stores individual sales document line items. Queries frequently request monthly revenue by sales region and product hierarchy level two. If these queries always read from the large fact table, performance may suffer. By defining an aggregate on region, product hierarchy level two, and month, the system can pre calculate totals and store them in a smaller table. When queries ask for those totals, BW reads from the aggregate instead of the full cube, greatly improving performance. This example demonstrates how aggregates work as subsets of the InfoCube.

Why Other Options Are Wrong:
Option b is incorrect because user specific query layouts are handled by query definitions and workbooks, not by aggregates. Option c is wrong because aggregates are not full copies of the cube; they deliberately store only aggregated data. Option d confuses aggregates with database indexes; while indexes help, aggregates are separate summary tables, not automatic indexes. Option e is incorrect because characteristic text tables provide descriptions, not aggregated numeric data.

Common Pitfalls:
A common misunderstanding is to think that aggregates store every detail and simply act as another copy of the cube, which defeats their purpose. Another pitfall is to confuse aggregates with summary queries saved by users, which are only query definitions and do not store data. For exam preparation, remember that aggregates are pre aggregated subsets of an InfoCube designed to speed up queries that repeatedly request the same summarised views.

Final Answer:
In SAP BW, aggregates are specialised summary tables that hold pre aggregated subsets of an InfoCube to improve query performance for frequently used combinations of characteristics.