Database Reference
In-Depth Information
back to the punched cards in the physical data cube described above, it should be
apparent that:
r3: All queries against the same aggregation level take the same time.
With punched cards, it takes the same amount of time to run the sorting-needle
through the hole for an upper-level member as for several lower-level members (with the
multiprocessor model of the sorting-needle as in Figure 7.4). Similarly, each query of the
data at the same level of aggregation requires the same time to query.
7.3.4.4 Compression Dimension
The concept and use of dimension tag “Compression”
is an important factor in ASo performance and is related to the physical example of
how data is stored on the card. Since tagging a dimension as Compression forces it to be
Dynamic, let us touch on it briefly and then return to it in Section 7.4.3.3 when we have
the tools to delve into it more fully.
The Compression dimension allows multiple pieces of fact data to be grouped
together and identified when they have common metadata; essentially placed together
on the same card and categorized by a common set of holes and notches. The members
grouped together in a dimension tagged as “Compression” may or may not be consoli-
dated in a hierarchy (which would have to be a Dynamic hierarchy), and they may or
may not be referenced by mDx. returning to the analogy of the physical cards, the
level-0 members of the Compression dimension operate like multiple pieces of fact data
on the face of the same data card. These different pieces of fact data share the same
notches and holes (metadata) of the other dimensions, thus avoiding having multiple
cards with identical metadata.
In ASo terms, the level-0 members of the Compression dimension share the same
bitmap identifying them in the outline. As I will show, the metadata for the small out-
line ASosamp requires a bitmap of 8-bytes (the key Length on the Statistics page). That
means 8 bytes of overhead for each set of fact data. ASo requires 8 bytes for each ele-
ment of fact data in the fact data set. Without Compression, there is only one piece of
fact data in the set, so the overhead is 8 bytes of metadata for each 8 bytes of fact data,
or 100%. With Compression, the five level-0 members of [measures] (40 bytes) share the
same 8 bytes of metadata, so only a 20% overhead.
remember that this savings comes at the cost of giving up on any possible Stored
hierarchy (i.e., additive) consolidations that might be possible in the dimension. The
dimension tagged as Compression
must
not only be Dynamic, but it must be Dynamic
in its entirety; i.e., it cannot have “multiple hierarchies Enabled.”
This tradeoff will be considered in more detail in Section 7.4.3.3. For now, I would ask
that you ignore the issue of Compression on performance until the bitmap construction
is addressed.
7.3.5 Is It Really That Simple?
With all your experience with computers and databases, etc., I know you realize that
there are always more issues, and you probably have already thought of a few of them.
many of the ones I suspect you have thought of, such as alternate hierarchies and attri-
butes, will be addressed. It is important to understand that if the basic rules to be learned
