Please see below a section in the BI Accelerator 1.2
documentation. This is not present in the v1.1
documentation. We would like to know why this restriction
(we are forced to go to lowest level when 2 hierarchies
are included in a cube) was imposed in version 1.2.



o When a cube includes both the primary and based-on
hierarchy of a dimension, you cannot specify the level
when including both these hierarchies in a cube; the
lowest level of the dimension will be included in the
cube.

o You cannot have a based-on hierarchy in a cube
without having the primary hierarchy.

o You can have the primary hierarchy in a cube without
the based-on hierarchy, and you can specify the level for
the cube.



Thanks

Clearly, the second and third rules make sense. I wondered whether
the first rule was simply that Microsoft's Excel front-end doesn't do
sufficient checking, i.e. that the level you choose for the primary
hierarchy
to be attached to the cube is not higher than the level at which
the primary hierarchy and the "based-on" hierarchy are joined.

It looks to me as though the underlying relation structure that is
generated would support a level higher than the lowest one.

I notice too that when defining a "based-on" level you must
"... select a level from the first hierarchy that is defined for that
dimension ..." (quoted from the development guide). This is a
restriction enforced by the front-end that the underlying database
doesn't need. Without this simplification it would need to check
for circularities - perhaps they chose the easiest option.

Maybe there is a more subtle reason, but it is not obvious.

John Bates


"Joseph Ollero" <Jollero (AT) wizardsgroup (DOT) com> wrote