Database Reference
In-Depth Information
should not hurt. The simplest way to test this is by changing all of the alternate Stored
hierarchies to Dynamic and then switch them back to Stored one at a time and see
if one makes the key length jump. Suggestion: Do this on a cube without any data
loaded.
7.4.3.7 Analysis or View Dimensions As some people have seen, the addition of anal-
ysis dimensions, such as [timeSpan] or [time view], [Datatype] or [Data view] or
[variance], can make a spreadsheet or report much easier to design, but it may take a bit
of training for your users to get used to the new design. These dimensions, which gener-
ally have only one stored member and the remainder dynamic with formulas, add noth-
ing to the bitmap. If the mDx is written well, they are very fast. Examples of Analysis
or view dimensions:
•  timeSpan: Instead of having Jun, Jun QtD, Jun htD, and Jun ytD all in one
month dimension, just include the 12 months. Add a second dimension with
month (the only stored member), QtD, htD, and ytD.
•  variance: What about members such as [vs Prior yr], [Prior mo], [vs Plan], etc.,
and [vs Prior yr %], [vs Prior mo %], [vs Plan %], etc., where should you put
these? In the year, the month, or the Scenario dimension? That becomes con-
fusing and soon multiplies the combinations out of control. Instead, a variance
dimension with [novar] (the only stored member), [vs Prior yr], [Prior mo],
[vs Plan], will be much easier to use. In fact, as users have sometimes objected
to seeing [novar] on a column heading next to [vs Prior year], I have found
that renaming the member [I I] reduces these objections because it appears to
be blank.
•  Datatype: Data (the only stored member), [per case], [per some other unit] [% of
acct dimension parent], [% of product dimension parent], etc.
This is important enough to become our next rule:
r11: Analysis dimensions are cheap or free, use them.
An example of an analysis dimension for timeSpan will be shown in Section 7.6.2
(Designing to maximize use of Stored hierarchies).
7.5 unDerstanDing aggregations anD sliCes
As I stated in the Introduction, the purpose of this chapter is to design a cube
that performs maximally, minimizing the need for extensive aggregations by
maximizing the opportunities for powerful, highly leveraged aggregations that
work over the widest number of queries. A detailed discussion of aggregations,
including hinting or related options, is beyond the scope of this chapter. For
information of this type, the reader is referred to tim german's excellent presen-
tation at kaleidoscope 2011, Essbase ASO: Optimizing Aggregations , which can be
found at http://www.odtug.com/apex/f?p=500:595:1219041880560478::no::P595_
ContEnt_ID:5348.
 
Search WWH ::




Custom Search