MDX Essentials: String Functions: The .UniqueName Function - Page 3

September 6, 2005

Let's assume, as a background scenario, that the Reporting department with which we worked earlier contacts us to say that they are happy with the "map" we have provided for the developer as outlined in our previous example. Their next request is a common one: they want to provide picklist support within an OLAP report, FoodMart Sales, which they have constructed using MSSQL Server Reporting Services. The data source is the Sales sample cube that accompanies an installation of MSSQL Server Analysis Services (and with which most of us are familiar). The consumers want the selector for the picklist to display the regular Name for the Product Department, the left-most, top level in a drill-down presentation.

While the focus of our article is the MDX required to meet this request, and specifically upon the use of the .UniqueName functions within an MDX query, the dataset that this query generates would be added in Reporting Services' Report Designer, among other steps, to meet the requirement for parameterization within the FoodMart Sales report. Let's create a query to generate the list, and then take a look at how we might use the data returned.

Our initial approach is quite similar to the previous example – it is in the intended end use of the returned data where we do something different. We again have a need that we can readily answer using the .UniqueName function in conjunction with a relative function, .CurrentMember. The requirement also includes the .Name function. We will be targeting the Name column in the resulting dataset (let's call it ProdDept_DisplayName) for the Name that is displayed in the selector for the parameter picklist. The Unique Name column of the returned dataset (the qualified "MDX" name for each Product Department), which we will call ProdDept_UniqueName in the query we will construct, will serve as the value that is actually passed to the cube in the MDX of the query. The happy result is that we insulate report consumers from the MDX altogether, while providing them ad hoc selection of a Product Department upon which to filter the report data.

Our first step is to construct a query to return the requested Product Department list, presenting the Names and Unique Names in two side-by-side columns. The corresponding Product Department members will inhabit the row axis.

-- MDX035-02  Using .Name  and .UniqueName to generate a picklist selection
WITH
MEMBER
     [Measures].[ProdDept_DisplayName]
AS
     '[Product].CurrentMember.NAME'
MEMBER
     [Measures].[ProdDept_UniqueName]
AS
     '[Product].CurrentMember.UNIQUENAME'
SELECT
     {[Measures].[ProdDept_DisplayName], [Measures].[ProdDept_UniqueName]} 
         ON COLUMNS,
     {DESCENDANTS([Product].[All Products], [Product].[Product Department])} 
         ON ROWS
FROM 
     [Sales]  

The Results pane is populated by Analysis Services, and the dataset depicted in Illustration 2 appears.

We see Product Department Names, the output of the ProdDept_DisplayName calculated member, populating the first data column, with the respective Product Department Unique Names (again, the "qualified" MDX name that can be used within a query against the Sales cube) for each occupying the second data column. The Product Department members themselves occupy the row axis, as we requested, although the row axis will not be used in the reporting environment. The calculated members ProdDept_DisplayName and ProdDept_UniqueName employ the .Name and .UniqueName functions, respectively, in conjunction (again) with the "relative" .CurrentMember function, which, as we can easily see from our practical example, results in a combination list of the Names / Qualified Names of the members that we specify in our row axis.

We will not take the steps, within this article, which occur inside the reporting layer to construct the picklist apparatus. However, let's take a look at one approach to assembling the parts in Reporting Services (or, similarly, in another OLAP reporting application). First, we would transfer the query to Reporting Services' Data tab to generate a Dataset within the FoodMart Sales report. This query, together with the dataset it generates, would look something similar to that which is partially shown in Illustration 3.

Once we have created the Dataset, the next step is to add a parameter to the report. Inside the Report Parameter definition, we would reference the new Dataset (in the example I created for my illustrations I named it pX_ProductDept), as shown, and then select ProdDept_UniqueName and ProdDept_DisplayName as the Value and Label fields respectively. Illustration 4 presents a view of the way all this would tie together in the Report Parameter dialog inside Reporting Services.

At this point all that remains is to return to the primary Dataset underneath the report and to insert the parameter variable within an axis specification or a slicer, where it acts as a filter (there are examples of this, and all other steps, in the articles I have cited above). Executing the query then triggers the "prompting" action of the new Product Department parameter.

The selection list, displaying the regular Product Department name, is manifested in the parameter dropdown when we preview or execute the report, as partially depicted in Illustration 5.

And so we see that our query, using the .Name and .UniqueName functions to present the Names and Unique Names for the Product Departments in two side-by-side columns, can be readily used to support a picklist for a parameter in the reporting layer of our business intelligence solution.

Summary ...

In this article, we explored the MDX .UniqueName function, which can be called upon in activities that range from generating simple lists to supporting parameters in the reporting layer, as well as more sophisticated uses. We introduced the function, commenting upon its operation and touching upon the datasets we can deliver using .UniqueName.

We examined the syntax involved with .UniqueName, and then undertook a couple of illustrative practice examples of business uses for the function, generating queries that capitalized on its primary features. Our exercises included an example that drew upon our earlier examination of the .Name function, which we used in combination with .UniqueName to create a results dataset. We then illustrated using the dataset to support a parameter picklist in a report that queried an Analysis Services cube. Throughout our practice session, we briefly discussed the results datasets we obtained from each of the queries we constructed.

» See All Articles by Columnist William E. Pearson, III

Discuss this article in the MSSQL Server 2000 Analysis Services and MDX Topics Forum.