A Word on Recasting

Aggregates and MQTs that are based on facts and dimensions are impacted by three types of changes:

1. New facts and dimensions
2. Update or deletion of existing facts
3. Existing dimension member updates requiring recasting of affected aggregations

The first two are caused by changes to the fact table and incur cost proportional to the volume of such change. The third type is caused by change in the dimensions, and requires recasting of all affected aggregates and MQTs. The tricky thing about dimension updates is that even a single record change may affect an enormous portion of an MQT. Because of this lack of proportionality, DB2 automatic MQT maintenance coupled with volatility in dimensions has an unpredictable and occasionally devastating impact on dimension maintenance. To remedy this problem, VDM recasting templates have been designed to be used with user-maintained MQTs. The methodology is based on three simple ideas that fits most situations:

• Separation of volatile current facts from history,
• Make History base fact insert-only
• Retain accurate historical versions of the dimensions to compute adjustment corrections

Periodically facts are moved from the current to the history fact, while in the same unit of recovery current aggregates and MQTs are merged into history. InfoKarta customers may check the VDM Aggregation Strategy pages for more related information.