Database Reference
In-Depth Information
Compression and, therefore, Dynamic dimension. In Figure 7.7, the reduction is from
15.662 gb to 10.180 gb. Why not have a smaller cube that takes up less space on disk
and in memory?
usually, however, things are not so clear cut. most dimensions do need some additive
consolidation. In particular, the larger dimensions such as [Stores] in Figure 7.7 show
the greatest reduction of cube size from 10.180 gb if [measures] is chosen down to 7.094
gb. Do you really want to give up all of the Stored consolidation and aggregation on
the 239 members in [Stores]? Because of the extensive additive consolidation in the
[Stores] dimension, there is a lot to lose when selecting it for Compression, as opposed to
[measures] where there is nothing to lose and only gains from the smaller size. Besides,
[Stores] in ASosamp has two attribute dimensions associated to it and you cannot asso-
ciate an attribute dimension to a dimension tagged as Compression.
Stored consolidation is extremely powerful, and only Stored hierarchies with Stored
(+) consolidations can be Aggregated. The overriding theme of this chapter has been to
encourage the use of designs that leverage Stored hierarchies, and in Section 7.6.2 some
alternatives that are not obvious are presented.
The Compression dimension becomes the subject of our next rule:
r9: The use of a Compression dimension is not a given; consider and test alterna-
tives including not having a Compression dimension.
Finally, did the idea of using a dimension with a single Stored member as found in a
typical “Analysis” dimension, such as [time Span] or [Data view] for the Compression
dimension, occur to you as it did to me? reconsider it. For Compression to work (i.e., to
result in a smaller cube) on a single Stored member dimension, the AvL would have to
be two bytes. Even then, the [Average Compressed record Size] would only be reduced
from 8 (for an uncompressed cube) to 6. The “+ 4” in the equation for the compression
overhead ruins the idea. The ABF would, by definition, be one (one filled member per
bundle); the fact data and, therefore, the record itself either exist or does not exist when
the Compression dimension has only a single Stored member.
7.4.3.4 The Accounts Dimension Before I introduce any unnecessary confusion, let
me distinguish between a dimension tagged as “Accounts” and a dimension tagged as
“Compression.” Before version 11 there was no distinction. The dimension tagged as
“Accounts” was automatically (implicitly) tagged as “Compression.” The values of the
two tags have now been disassociated and I will refer to the tags independently.
As with the Compression dimension, tagging a dimension “Accounts” requires
that the entire dimension be dynamic. The primary advantage of tagging a dimen-
sion “Accounts” is that the “time balance,” “Skip,” and “Flow” options become avail-
able. generally, only a subset of the members in the Accounts dimension require these
options. This must be balanced against the loss of the advantage of stored consolidation
and, of course, aggregation of the stored consolidation upper-level members.
At this point, many designers will raise one of these two issues:
•  my Accounts dimensions must already be dynamic because of the inclu-
sion of pluses (+) and minuses (-) in the hierarchy, typical in accounting
applications.
 
Search WWH ::




Custom Search