Database Reference
In-Depth Information
• ([Price Paid], [Prev year], [1 to 13 years])
• ([Price Paid], [Prev year], [14 to 19 years])
• ([Price Paid], [Prev year], [50 to 64 year
A view
aggregated
only at level-1 of the [Age] dimension would have records for:
• ([original Price], [Curr year], [teens])
• ([Price Paid], [Prev year], [teens])
• ([Price Paid], [Prev year], [Senior])
how many records would be in the resulting set overall? That is hard to determine,
unless we make a few assumptions: That data had existed for all 9 level-0 members of
[Age] and that any combination of the other dimensions that existed, existed equally
(i.e., there were the same combinations of all other dimensions) for all 9 members, then
we can say that the size of the Aggregated set would have been 3/9 of the size of the
original (3 for the three members of level-1 and 9 for the level-0 members). Without
these assumptions, there is little we can do to estimate the actual size as measured by
the record count.
In this example, I have aggregated only on the [Age] dimension. ASo is not limited
to a single dimension at a time. What is important to realize here is that an Aggregated
view is really a set of records, essentially a small cube without any of the lower-level
detail in the aggregated levels in each dimension.
next, as mentioned above, the Bitmap can represent only one hierarchy per dimen-
sion at a time. Furthermore, assuming that attributes were associated at level-0, an
Aggregated view above level-0 loses the association to the attribute. If we were to query
in ASosamp on the [Stores] dimension to get a report of [Computer outlets] by [Square
Footage], the query could not use any Aggregated view of the [Stores] dimension above
level-0. Depending on the levels of the other dimensions of the query, it could make use
of Aggregated views of upper levels in those dimensions.
Let us stop and learn about the Aggregated view notation; it might help us to
understand.
7.5.2 What Is the Meaning of Those Numbers in the Recommended View?
Ignoring for the moment how ASo determines what are the most advantageous queries to
be saved as Aggregated views, let us look at what is being aggregated. In the ASosamp cube
we have been using (the one seen in Figure 7.6 that notes the slight difference to the deliv-
ered ASosamp) when we run the initial recommended Design Aggregations (after loading
the delivered dataload.txt file) we get the results found in Figure 7.10.
twenty six views are recommended … well, actually, 25 because the first one out-
lined in the Level Info column is the input-level data also known as the level-0 data
view or the level-0 Aggregated view. The database size column shows the cumulative
size of the cube including level-0 view and each of the views on that particular row and
the rows above it. The size of any one view would be the difference between it and the
row immediately above it. We see that the memory requirement for this cube started
out at 6.5 mb, and 30 mb of aggregations were added in the 26 views, for a total of 36.5
mb. In fact, two of the views (those circled in the Database Size column), view 15 and
view 25 (on the 16
th
and the 26
th
rows), are nearly as large as the original level-0 view,
remembering that the size of the view is equal to current row less prior row of the
Database Size column.
