Database Reference
In-Depth Information
It is important to realize that the percentage size relative to the level-0 view will
change depending on the distribution of your data, even though the view definition
does not change. The wizard bases its analysis on ASoSAmPLESIzEPErCEnt con-
figuration setting. The default value for this setting is whatever percent equals 1,000,000
cells. So, with a large cube, running the wizard multiple times will yield varying results
based on where the random sampling done by the wizard falls.
The DBAg warns that editing of this file is unsupported. how could we edit to elimi-
nate the eight “half ” views (marked with asterisks in Figure 7.10 and Figure 7.12)? We
could simply let the Design Aggregation Wizard create and save this CSC file without
materializing the views. We then could edit out the appropriate pairs of rows (which
appear in the order they were in, in the wizard). The DBAg actually does not say that
the editing of this file is totally unsupported; it says that editing without knowing the
estimated percentage view size is unsupported. We have the view size calculated by the
wizard for the remaining rows, so it should be fine.
The remaining question is: have the relative costs of our remaining views changed
as a result of the deletions? to answer this we would have to go through the full set of
rule r12 analysis to ensure that none of our remaining views were dependent on one
of the views we have eliminated. I have gone through that process and at least for the 25
Aggregated views dataset in the small Figure 7.10 dataset, there is no such dependency.
I have not analyzed the 35 Aggregated views in Figure 7.11 for the effect of elimination
of the (coincidentally) eight “half ” views presented there by the wizard. I will leave that
as an exercise for you, the reader.
What would the cost be, however, if we had eliminated a dependent view/row
of one of the remaining views/rows? The time to compute that view would increase.
This section started out with my declaration that “a detailed discussion of aggrega-
tions …” is beyond the scope of this chapter. nevertheless, a chapter entitled “how ASo
Works and how to Design for Performance” warrants a few remarks about aggregations.
By now you are wondering, if he said he was going to include only a “few” comments
on Aggregation, what would “not a few” have looked like? Well, I hope it has been inter-
esting and informative.
7.6 Design alternatives anD their Costs
In Section 7.4.3 (Primary Lessons from the Bitmap), I implicitly defined cost as the
increase in the number of bits in the bitmap attached to each input-level cell. The rules
derived there were those where the balance would not have been affected by other types
of cost. In this section, we will look at design alternatives and possibly some new rules
where these other costs should be considered.
7.6.1 Other Types of Cost
First of all, increases in the bitmap to accommodate more opportunities that take advan-
tage of Stored hierarchies and consolidations have very little cost. given the requirement
to round the key-length up to the nearest 64-bit boundary, the odds are that there already
are unused bits and, therefore, there will be no cost because the size of the database will
not increase. Some people have asked whether this would increase the time required to
compute Aggregated views. This should not be an issue. more opportunities to aggre-
gate do not mean that more aggregation is required. Instead, by limiting the Aggregated
views, the same time can be spent in materializing more useful Aggregated views.
