Aggregate Improvement and Lost, shrunken, and collapsed Aggregate management References: Aggregate Improvement and Lost, shrunken, and collapsed Aggregates exist for performance reasons Consider aggregates as a way to speed queries Indispensable to warehouses, just as indexes are indispensable to OLTP databases. Use aggregate navigators Rules of thumb: Double storage requirement by factor of two to allow for aggregations Aggregates should be 10-20 times smaller than source fact/aggregate table Try to accelerate some queries by 1,000 times Both by Lawrence Corr March 2004 91.4904 Ron McFadyen

Dimensions in a aggregate schema can be characterized as one of: Aggregate management Dimensions in a aggregate schema can be characterized as one of: Lost Shrunken Collapsed March 2004 91.4904 Ron McFadyen

Aggregate management Lost dimension A lost dimension is one that disappears – it is in the base schema, but it does not appear in the aggregate schema e.g. March 2004 91.4904 Ron McFadyen

E.g. a month dimension replaces the date dimension Aggregate management Shrunken dimension A shrunken dimension is one where a rollup occurs, or where a dimension is replaced by a higher dimension in a snowflake design E.g. a month dimension replaces the date dimension How is this type of dimension materialized? What should be the name of the Primary Key? March 2004 91.4904 Ron McFadyen

The collapsed dimension does not exist as a table Aggregate management Collapsed dimension A collapsed dimension does not appear as a dimension in the aggregate, rather one or more of its attributes appear in the aggregate’s fact table The collapsed dimension does not exist as a table e.g. March 2004 91.4904 Ron McFadyen