About the Series ...
This is the fourth tutorial article of the
series, MDX in Analysis Services. The series is designed to
provide hands-on application of the fundamentals of MDX from the perspective of
MS SQL Server 2000 Analysis Services (to which I will refer in most
cases as simply "Analysis Services," to
save time and space). Our primary focus is the manipulation of multidimensional
data sources, using MDX expressions in a variety of scenarios designed to meet
real-world business intelligence needs.
For more information on the series, as well as the hardware /
software requirements to prepare for the tutorials we will undertake, please
see Tutorial
1: MDX Concepts and Navigation.
Note: At the time of writing, Service
Pack 3 updates
are assumed for MSSQL Server 2000, MSSQL Server 2000 Analysis
Services, and the related Books Online and Samples.
Introduction
In our
last tutorial, we expanded further the intermediate topics we introduced in Tutorial
Three of the
series. We undertook practice examples where we explored handling hierarchical
relationships in our expressions. We also discussed one of multiple ways to
identify empty members, illustrating why this is important in building
expressions.
In this
lesson, Retrieving Values from Multiple Cubes, we will examine how we can use MDX within
Analysis Services to retrieve values from multiple cubes simultaneously,
offering us the often useful option of accessing multiple OLAP data sources
together for analysis and reporting. We will discuss an example real-world
scenario in which a need for this capability commonly occurs: We will
demonstrate how we can compute a per-unit average, within the context of
providing a Revenue Per Unit Sold value, based upon values retrieved
from two separate OLAP data sources.
Accessing Multiple
Cubes Simultaneously
In this lesson, we will extend our
evolving use of calculated members to add the retrieval of data from another
cube, by creating an expression to "look up" a value from the
secondary data source. While truly sophisticated uses of this capability are
possible, we will undertake a simple instance to illustrate that we can rely on
data from other sources to enhance the end product that we deliver to the
targeted information consumers. (Indeed, optimal cube design principles
dictate that we do not replicate data that we can easily entrain from other
sources in creating new ones).
To set a scenario, let's say that we
want to bring Sales Units data into our information product. We know
that our primary Sales data source for purposes of this lesson, the Budget
cube, does not contain this information, not only because its designers would
have wanted to restrict its size, but also to limit its focus to the business requirements
of the Budgeting consumers, who we will assume did not express an interest in
unit quantity information as a part of the business requirements collection
phase of design. A quick review of the measures data in the Budget
cube confirms that, indeed, unit information does not exist in the cube.
Over time, let's say an ad-hoc need
arises to be able to access Sales Units data that corresponds to the
respective sales information that we store in the Budget cube. We will
say, for this example that we need to compare some rough revenue per-unit
calculations between stores. This will also give us an opportunity to expand
our integrated practice exercise to include the calculation of some high-level
per-unit average costs.
We add the foregoing considerations to
our list of requirements, and set out to design our model to meet the newly
expressed needs. We will use these example business
requirements within an integrated practice example to flesh out a solution that
incorporates the objectives of our lesson.
» 
Comment and Contribute
