Hierarchy options

In order to influence the aggregation result and processing type, different hierarchy options may be defined. Usually, aggregation results are stored in transient collections. In order to make an aggregation result persistent, a VIEW definition has to be provided and assigned to a persistent extent definition as data type.

In order to provide all possible aggregation levels, one may define hierarchy option COMPLETE, which means that all hierarchy paths fro grouping level to total will be created:

• 111 - sex, age_group, income_group

• 110 - sex, age_group

• 101 - sex, income_group

• 011 - age_group, income_group

• 100 - sex

• 010 - age_group

• 001 - income_group

• 000 - total

In case of having level dimensions (e.g. birth_date(IDate)), where IDate contains three attributes (year, month, day), birth_date dimension will create three different hierarchy levels and grouping level identifier is 131. This would be reflected in a simple aggregation hierarchy by following aggregation levels:

• 131 - sex, birth_date.day, income_group

• 130 - sex, birth_date.day
• 120 - sex, birth_date.month
• 110 - sex, birth_date.year
• 100 - sex
• 000 - total

The content of the result collection depends on different options. Usually, the result collection does not contain aggregation instances for dimension combinations that do not have references. In case of having dimensions (grouping attributes) personId, projectId and iDate, projects, persons or days that have not got time sheets will not appear in aggregation instance keys. In order to get also "empty" hierarchy instances, ALL has to be defined as HIERARCHY option. Then, empty hierarchy instances are also created with empty attribute values. The option only applies to dimensions with defined value domains (enumerations).

By default, the result collection contains all aggregation levels defined by dimension sequence (SIMPLE hierarchy). In case of having dimensions (grouping attributes) personId, projectId and iDate, following aggregation levels are created for a simple hierarchy:

• 113 - personId, projectId, iDate(year, month, day)

• 112 - personId, projectId, iDate(year, month)

• 113 - personId, projectId, iDate(year)

• 110 - personId, projectId

• 100 - personId

• 000 - total

A complete aggregation hierarchy evaluates all possible aggregation paths.

It becomes obvious, that hierarchy level will explode when there are four or more dimensions. In order to avoid unnecessary overhead, one may define hierarchy option DELAYED, which creates the grouping aggregation level (113 in the example), only, and adds other hierarchy levels and subsets on demand trying to optimize required access. When following hierarchy levels have been created:

• 113 - personId, projectId, iDate(year, month, day)

• 112 - personId, projectId, iDate(year, month)

• 113 - personId, projectId, iDate(year)

• 110 - personId, projectId

• 100 - personId

• 000 - total

requesting the hierarchy level projectId(010), will create the aggregation level from hierarchy level (110 -personId, projectId) on the fly. In case of persistent aggregation result, requested aggregation levels are also stored for later use.