Running aggregation process

The ODABA aggregation model stores all aggregation instances (including grouping level) in one aggregation collection. Each aggregation instance is preceded by the level identifier L , which is also the leading key component for the identifying key followed by key value K . A complete aggregation collection has instances for all level identifiers. On demand aggregation collections ( DELAYED HIERARCHY ) provide aggregation instances on grouping level, while higher aggregation levels are evaluated when being accessed. Simple aggregation collections provide aggregation levels by reducing the grouping level identifier by one for each dimension from right to left.

When working with an aggregation collection, a list containing all level identifiers with the number of aggregation instances for each level identifier ( I(L) ) ordered by level class number ( C(L) ) is provided internally. A level class list contains the offset for each level class in the level identifier list. Aggregation candidates for a level identifier L1 are all L with C(L1) < C(L) and D(L1,L) > 0 . Using the level identifier L with the minimum distance D(L1,L) and the minimum number of instances I(L) will ensure optimal aggregation in many cases.

Providing aggregation instances is not the only task in the aggregation model. In order to be able to "drill down", i.e. providing subordinated instances for an aggregation instance I and dimension i ( S(I,i) ). In order to indicate, whether a sub collection has already been created or not, s status flag SF(i) is added to each instance indicating that subset has been created ( SF(i) = true ).

Subsets S(I,i) in a delayed hierarchy are transient and created on demand. In a complete hierarchy, all subsets are persistent and will be created when running the aggregation. For simple aggregations (not complete and not delayed), subsets and aggregation levels are created when running the aggregation process.