Database Reference
In-Depth Information
memory is indeed cheap nowadays, but it seems that even if memory is not a constraint
in your implementation, the combined 12 mb of these two queries could be better used for
other, more beneficial Aggregated views. remember that the dataset loaded into this cube
is the demo dataset. It is quite small and might not be representative. This is an important
consideration. The selection of the most advantageous views cannot be made except on
a live dataset, and it must be reviewed periodically as the content of the dataset changes.
now let us look at the data in the column “Level Info.” Looking at the view in the
fifth row (view 4) view we see [0, 0, 2/0, 0, 1, 0, 2, 1, 0/0, 2/0, 3/0]. This notation indi-
cates the aggregation level for each dimension of the view in the order in which the
dimensions appear in the outline. Dimensions marked with the #/# notation are for
dimensions with multiple hierarchies, with the first number representing the aggrega-
tion level and the second number representing the hierarchy to which the aggregation
level refers (again, in the order in which they appear in the outline and starting at 0).
note that this notation is only based on the physical outline order. If the second hier-
archy (that is numbered as hierarchy 1) were to have the longest bitmap and, therefore,
be deemed the primary hierarchy, it would, in this notation, remain numbered as 1.
The bitmap and any single view can refer to only one hierarchy per dimension at a
time. This view, at its lowest level, has records with the following members:
•  [measures]: All stored, nonformula level-0
•  [years]: All stored, nonformula level-0
•  [time]: [1st half] and [2nd half] onLy
•  [transaction type]: All stored level-0
•  [Payment type]: Dimension top Level
•  [Promotions]: All stored, nonformula level-0
•  [Age]: top Level onLy
•  [Income Level]: top Level onLy
•  [Products]: All stored level-0
•  [Stores]: [Brick & mortar] AnD [online] onLy
•  [geography]: [Central], [mid West], [north East], [South], [South West] and
[West] on Ly
Note: The bitmap found in this view would allow retrieval by upper-level members of
the same hierarchy as those shown above (e.g., [mDx] in the time dimension), but the
lower-level members could not be queried from this view (e.g., [Jan], [Feb] … in the
time dimension).
Let us look at a fairly important observation we can make in view 4. notice, in par-
ticular, the aggregation level for [time]. It is at level-2, which includes the upper-level
members [1st half] and [2nd half]. how often do your users really report at the half
level? In fact, 8 of the 26 views are half views that exist to speed up reporting at the half
level (all have been marked with an asterisk). This would seem to be a good candidate for
a hint, such as “never aggregate to intermediate levels.”
now, let us consider view 4 for the dimension [Products]. If you remember from
Figure  7.6, there were two hierarchies [high End merchandise] that contained two
shared members and one unique unshared member ingloriously named [Stored
member] and the incorrectly named hierarchy [All merchandise] (incorrectly named
because it lacks the [Stored member]). This extra member can be found in the hierarchy
0 bitmap even though it is not in the primary hierarchy. An extra bit from the formula
Search WWH ::




Custom Search