The LEVEL_NUMBER Member Property - Page 2

Practice

Preparation

To reinforce our understanding of the basics we have covered so far, we will use the LEVEL_NUMBER property in a couple of examples that illustrate its operation. We will do so in simple scenarios that place LEVEL_NUMBER within the context of meeting business requirements similar to those we might encounter in our respective daily environments. The intent, of course, is to demonstrate the operation of the LEVEL_NUMBER property in a straightforward, memorable manner.

We will turn to the SQL Server Management Studio as a platform from which to construct and execute the MDX we examine, and to view the results datasets we obtain. If you do not know how to access the SQL Server Management Studio in preparation for using it to query an Analysis Services cube (we will be using the sample Adventure Works cube in the Adventure Works DW Analysis Services database), please perform the steps of the following procedure, located in the References section of my articles index:

This procedure will take us through opening a new Query pane, upon which we can create our first query within the section that follows.

Procedure: Satisfy Business Requirements with MDX

As a basis for our practice example, we will assume that we have received a call, as so often in the past, from the Reporting department of our client, the Adventure Works organization, requesting our assistance in meeting a specific report presentation need. The client has implemented the integrated Microsoft BI solution - in addition to using Analysis Services as an OLAP data source, they use Reporting Services as an enterprise reporting solution. The MDX we explore together, we are told, will thus be adapted and extended for ultimate use within Reporting Services, in multiple parameterized reports.

A group of report authors want to display the level number, together with the level name of the Customer Geography Cities (the City level members of the Customer Geography hierarchy of the Customer dimension), alongside the respective member names and “MDX qualified names” (the unique names within Analysis Services). Their objective, we are told, is to provide an index, or map, for a developer who needs these names alongside the total Internet Sales Amount for each, as a part of an internal reporting project he has undertaken.

This represents a simple, yet practical, need that we can readily satisfy using the LEVEL_NUMBER property in conjunction with a relative function, .CurrentMember. (We previously accomplished a similar objective using each of the LEVEL_UNIQUE_NAME, MEMBER_NAME, and MEMBER_UNIQUE_NAME properties, so our example will also serve, to a small extent, as a review of what we covered in The LEVEL_UNIQUE_NAME Intrinsic Member Property, Intrinsic Member Properties: The MEMBER_NAME Property and in Intrinsic Member Properties: The MEMBER_UNIQUE_NAME Property, respectively, as well as other earlier articles within this series.) We will create a basic query that returns the containing level number and level name, together with the City name, for each U.S. City in which we have customers (whether we have conducted Internet Sales with them or not), and the unique name (“MDX qualified name”) for each respective U.S. City. Much of the information we generate with the query will ultimately find its way into the Dataset definition of reports that the developer intends to construct within Reporting Services. In addition to populating report captions and the like, some of the data elements (such as the “MDX name” for the level and City) can be used in axes, slicers, and so forth, within queries against the Analysis Services cube under consideration.

The “level number” portion of the requests relayed by the client representatives evidence a need to present multidimensional data in a manner that we think might best be served with the LEVEL_NUMBER property. Once our colleagues provide an overview of the business requirements, and we together conclude that LEVEL_NUMBER is likely to be a key component of the option we offer, we provide the details about the function and its use, much as we have done in the earlier sections of this article. We convince the authors that they might best become familiar with the LEVEL_NUMBER property by examining a couple of introductory examples, the objective of the first of which is to generate a straightforward list of level number, level name, City member name and City unique name, along with the corresponding Internet Sales Amounts, in a results dataset.

Procedure: Use the LEVEL_NUMBER Property within the Generation of a Simple List of Members with a Measure in a Results Dataset

Let’s construct a simple query, therefore, to return the requested Customer City information, presenting the level numbers, alongside the unique level names, member names, member unique names, and Internet Sales Amount in four, side-by-side columns, with the corresponding City member names as rows.

-- MDX077-01 Using LEVEL_NUMBER, LEVEL_UNIQUE_NAME, MEMBER_NAME and MEMBER_UNIQUE_NAME
--   to generate a hierarchical level number, level unique name,
--     member name, and member unique name list within the data grid
    
WITH

MEMBER
  [Measures].[Customer Geography - Level No.]
AS
  '[Customer].[Customer Geography].CurrentMember.LEVEL_NUMBER'

MEMBER
  [Measures].[Customer Geography - Level Name]
AS
  '[Customer].[Customer Geography].CurrentMember.LEVEL_UNIQUE_NAME'

MEMBER
  [Measures].[Customer Geography - City Name]
AS
  '[Customer].[Customer Geography].CurrentMember.MEMBER_NAME'

MEMBER
   [Measures].[Customer Geography - MDX Qual Name]
AS
   '[Customer].[Customer Geography].CurrentMember.MEMBER_UNIQUE_NAME'
         
SELECT
   {
      [Measures].[Customer Geography - Level No.],
         [Measures].[Customer Geography - Level Name],
            [Measures].[Customer Geography - City Name], 
         [Measures].[Customer Geography - MDX Qual Name], 
      [Measures].[Internet Sales Amount]
   } 
   
ON AXIS(0),
   
   {
      DESCENDANTS( 
         [Customer].[Customer Geography].[Country].&[United States], 
      [Customer].[Customer Geography].[City])
   } 
ON AXIS(1)

FROM    
       [Adventure Works]  

The Query pane appears, with our input, as depicted in Illustration 1.

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

We see the [Customer].[Customer Geography] level number (“3”), the output of the Customer Geography - Level No. calculated member, populating the first data column. The [Customer].[Customer Geography] level name ([Customer].[Customer Geography].[City]), the output of the Customer Geography - Level Name calculated member, populates the second data column. The respective Customer Geography City names, the output of the Customer Geography – City Name calculated member, populate the third data column. Finally, the associated Customer Geography City Unique Name (a “qualified” MDX name that can, itself, be used within a query against the Adventure Works cube) for each occupies the fourth data column (which we populate via the Customer Geography - MDX Qual Name calculated member in the query), alongside the corresponding Internet Sales Amount measure. The Customer Geography City members themselves occupy the row axis, as the client has requested.

The Customer Geography - Level No. calculated member exploits the LEVEL_NUMBER property in conjunction with the “relative” .CurrentMember function. In like manner, the Customer Geography - Level Name calculated member exploits the LEVEL_UNIQUE_NAME property in conjunction with the .CurrentMember function. Moreover, the calculated members Customer Geography – City Name and Customer Geography - MDX Qual Name employ the MEMBER_NAME property and the MEMBER_UNIQUE_NAME property, respectively, in conjunction with .CurrentMember in similar fashion, which, as we can easily see from our practice example, results in a combination list of the unique hierarchy names and member names (either of which might be used as captions / labels within a given report layout), together with member qualified names for the members that we specify in our row axis. (Similarly, if we had specified the Customer Geography State - Province or Customer Geography Country levels in the row axis instead, we would have obtained a list of the hierarchy / members of those levels as a result). Intersecting the calculations with the members under consideration can be leveraged, in similar fashion, to produce sophisticated results within more elaborate structures and processes.

Our client colleagues express satisfaction with our initial solution, and state that it satisfactorily displays the hierarchical level numbers and names, alongside the respective member names and qualified / unique names, of the Customer Geography Cities. They state that they expect this approach to provide the desired index for the developer who needs the level numbers and names, member names and unique member (“MDX”) names, alongside the total Internet Sales Amount for each of the Customer Geography Cities, and that this “map” will equip him to complete the reporting project he has undertaken.