Database Reference
In-Depth Information
The [Internal Calculation ytDs] hierarchy builds [ytDd(Dec)] from the sum of
[Dec] and [ytDd(nov)]; this is in turn built from the sum of [nov] and [ytDd(oct)],
continuing down until you get to [ytDd(Jan)], which is an Implied Share and, there-
fore, de facto alias of [Jan]. The quarters are built up in a similar fashion, but go down
only three levels. This is known as a “Stacked” hierarchy (it has the look of being recur-
sive, but it is not truly recursive).
The ytD and QtD Dynamic hierarchies are used so that a user does not have to drill
down five levels from ytDd(Dec) through ytDd(nov), etc., to get to ytDd(Jun). They
are organized with a flat hierarchy of the familiar names from ASosamp ytD(Jan),
ytD(Feb), etc., and have a single Implied Share member below them with the name from
the stacked hierarchy ytDd(Jan), ytDd(Feb), etc. This technique does not even require
any actual Dynamic calculation because it simply leverages Implied Sharing and there is
no need to be concerned with Solve orders. notice that if a member formula had been used
instead of setting ytD(Jan) = ytDd(Jan), there would have been Dynamic calculation.
The cost of this redesign is to increase the bitmap for the [time] dimension from 4 to
11 bits. In this particular case, it is an unfortunate occurrence because the pre-redesign
bitmap was at 63 bits, and these changes resulted in the bitmap exceeding the 64-bit
boundary and, thus, 8 bytes of bitmap on every record in the data database. If you are
in this unusual case where the change forces you over a 64-bit boundary, you will have
to decide by testing if this change results in a net performance increase for your cube.
you should remember that the natural increase (as the business finds more things to
track) in the number of members defined in the cube will probably cause this jump in
the bitmap length. At 63 bits, it was probably going to happen soon anyway.
you might be ready to object that your user wants a separate timeSpan dimension
(they do not want [JunytD] but ([Jun], [ytD]). Stored consolidations work
only
within
one dimension. how can you make it work across two? The answer is: Do not try; do it
in one dimension and make it look like two (Figure 7.14).
here the Implied Share hierarchies ytD and QtD are removed (remember, they
are included in the outline only for user convenience anyway), but the Stacked hierar-
chies [Internal Calculation ytDs] and [Internal Calculation QtDs] remain. An addi-
tional dimension, [timeSpan], is added with the Dynamic members [ytD], [QtD], and
[Period]. [Period] means for the time period itself as queried in the time dimension
Figure 7.14
Alternative YTD and QTD design for ASOsamp using a TimeSpan dimension. (From Oracle Essbase
Administration Services. With permission.)
