Database Reference
In-Depth Information
• hybrid BSo/ASo reporting (the desired result is a single cube to be used for
comparative analysis) is achieved by partitioning a BSo cube with budgeting
and forecasting data to an ASo reporting cube that is also partitioned to an
ASo cube containing actuals data.
The one solitary fact that should be emerging from the haze is that the combination
of these two storage kernels allows you to create a myriad of different design combi-
nations to meet the requirements of your users. hybrid solutions are becoming more
common as developers and architects become more familiar with the strengths of ASo
cubes. The decision on which technology should ultimately be used should be based
on the requirements. The technology combination that will fulfill the requirements
and requested functionality in the least amount of development time is what should
be selected. Speed to market is becoming more critical in every reporting solution,
especially in vertical industries like retail where the competition is stiff. Due to rapid
shifts in market demands, solutions must be developed and implemented quickly. This
makes the use of ASo cubes ideal in most designs.
5.5 what great things Can i only Do with aso CuBes?
5.5.1 Making a Cube Smarter through Use: Training a Cube
During the requirements-gathering phase, one of the areas for extensive consideration
and exploration is: “how will this cube be queried?” While the developer does not care
how the BSo cube will be queried because everything is aggregated during the default
or custom calculations, this is not true of an ASo cube. unlike a BSo calc script that
creates the cube aggregations, ASo aggregations are created through a Wizard that is
assisted by any one of many methods described in this chapter. If the developer knows
the usage behaviors, the aggregations can be designed and implemented in a very opti-
mal manner. Thus, it is helpful to try to gather hardcore detailed information on usage
patterns and expectations. This is most useful if it can be related to hierarchical terms.
Will most users (80/20 rule) query the most granular levels (level-0) of the data, or will
querying summary information be more common and the querying of details will be
the exception? This distinction is important because it affects what kind of work is done
initially to determine appropriate aggregate views. It also determines the ongoing strat-
egy recommendations for aggregating the cube (if any). Sometimes, no one seems to
know this information. one cause for lack of concrete knowledge may be that the sub-
ject area is new, and no one understands exactly how the new information will be used.
Another cause for lack of information might be that the correct group of individuals
has not been interviewed. Someone knows the answer to these questions , just not the
“someone” that has been interviewed up to this point in time.
There are several methods available to optimize query performance in ASo cubes
(even if it is not known exactly what needs to be optimized). It is vital to state that these
strategies are not an excuse or replacement for poor design. review Pressman's excellent
chapter (Chapter 7) on how ASo works to determine the best usage of these features
within your cube design. That being said, utilization of one or more of these methods
can assist the developer in achieving required performance Service Level Agreements
(SLA) in addition to creating easily maintained high-performing aggregate processes.
one of the more significant, but greatly underutilized, features of an ASo cube is its
ability to become smarter through use and training. I am, of course, referring to Query
