MDX in Analysis Services: Retrieve Data from Multiple Cubes

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.