Database Reference
In-Depth Information
7.3.4.1 Stored Dimensions/Hierarchies
The punched card description/analogy and bit-
map mask comparison (or sorting-needle-like processing) applies
only
to Stored dimen-
sions, and only Stored dimensions take advantage of aggregation. This yields the second
Rule of ASO Designing for Performance:
r2: Wherever possible, data should be calculated from Stored dimensions.
This is the single most important rule and the one most often overlooked in cube design.
In Essbase terms, the dynamically calculated nonadditive data must be members of a
Dynamic hierarchy. In fact, returning to our button example, suppose we had an outline
where both the radius r and the area were level-zero members. Because we are not calcu-
lating the area πr
2
before the data load, there must be a formula on the area member calcu-
lating it as a function of the (stored) member r. When you look in EAS, the area's member
property appears as “stored” and, in this case, it also is a level-0 member. It is really level-0
in name only, and only because it has no children below it. In reality, it does have a lower-
level member on which it depends for its value: the radius r, which is a level-0 member
elsewhere in the dimension. If the area had been precalculated and the result loaded, then
it truly would be a stored level-0 member. As we continue to look at Essbase outlines, you
will often see this distinction made in references to “Stored level-0 nonformula members.”
It is these “Stored level-0 nonformula members” that are represented in the bitmap.
Actually, let us take a few moments to discuss the terms “Stored” and “Dynamic,” par-
ticularly for those who are used to BSo Essbase cubes. In BSo, “Stored” and “Dynamic”
refer to members. Stored upper-level BSo members have their values determined when
the database is calculated; Dynamic BSo members have their values determined during
retrieval. In contrast, both Stored and Dynamic upper-level ASo members have their
values determined at retrieval time. This is actually a curiosity that comes from looking
at the member level storage properties for upper-level members. They always appear as
stored. one might say that all upper-level Stored
ASo members are
dynamically calcu-
lated
by summation of the lower-level stored members
.
The “Stored” term for upper-level Stored hierarchy ASo members refers to the fact
that they are
storable using an aggregation
or summation of lower-level Stored members.
This “selective” summing is performed by comparison of the data's bitmap or key with
a bitmap mask as defined by the query.
For now let me sum up the discussion of Stored dimensions by saying that they are
the key to ASo performance and design alternatives are presented in Section 7.6.2 to
facilitate the use of Stored dimensions and avoid the use of mDx (which is, of course,
a dynamic operation) where possible. The summary in Section 7.9 provides strategies
for organizing and thinking about your mDx in ways that leverage Stored hierarchies.
An Exercise for the Reader:
Think about how the bitmap mask is used. Why is
the addition (+) consolidation operation the only operator that can be used in
Stored hierarchies?
you may have noticed that I just switched from using the term “Stored dimension” to
“Stored hierarchies.” By enabling “multiple hierarchies” (outline: member Properties
