Intrinsic Member Properties: The HIERARCHY_UNIQUE_NAME Property

Friday Feb 6th 2009 by William Pearson
Share:

This month's installment of "MDX Essentials" examines the HIERARCHY_UNIQUE_NAME intrinsic member property. Join SSAS Architect Bill Pearson in an introduction of this intrinsic member property, which Bill complements with hands-on exercises and sample uses.

This month, we will examine the HIERARCHY_UNIQUE_NAME intrinsic member property. Once we have briefly introduced HIERARCHY_UNIQUE_NAME, we will employ the member property, in a hands-on practice session, to meet example business needs for a hypothetical client. The primary focus of this article, like the other articles of this series, is to provide hands-on application of the fundamentals of the Multidimensional Expressions (MDX) language, doing so here specifically within the context of the HIERARCHY_UNIQUE_NAME intrinsic member property, in combination with other member properties and MDX functions.

Note: For more information about my MDX Essentials column in general, see the section entitled “About the MDX Essentials Series” that follows the conclusion of this article.

Overview

In this lesson, we will examine another intrinsic member property, HIERARCHY_UNIQUE_NAME. As many of us are aware, the intrinsic member properties supported by SQL Server 2005 Analysis Services are of two types: context sensitive member properties and non-context sensitive member properties. HIERARCHY_UNIQUE_NAME belongs to the second group of properties. As a general group, intrinsic member properties provide additional information that can be used by applications to enhance the ultimate user's experience. Support for the non-context sensitive member properties is the same for all members, regardless of individual context.

The purpose of the HIERARCHY_UNIQUE_NAME property is to support the return of the unique name of the hierarchy to which a member belongs. HIERARCHY_UNIQUE_NAME can be useful in a host of different applications. Moreover, as I have noted to be the case for other functions and properties within the MDX Essentials series, HIERARCHY_UNIQUE_NAME allows us to exercise a great deal of presentation “sleight of hand” in working with MDX in Analysis Services, as well as within Reporting Services and various other reporting applications that can access an Analysis Services cube.

The HIERARCHY_UNIQUE_NAME property can be leveraged in activities that range from generating simple lists to supporting sophisticated presentations. It can be a particularly effective tool when we need to provide parameter picklist support and the like, as we shall see. We will introduce the function, commenting upon its operation and touching upon examples of effects that we can employ it to deliver. As a part of our discussion, we shall:

  • Examine the syntax surrounding the function;
  • Undertake illustrative examples of the uses of the function in practice exercises;
  • Briefly discuss the results datasets we obtain in the practice examples.

The HIERARCHY_UNIQUE_NAME Property

Introduction

According to the Analysis Services Books Online, the HIERARCHY_UNIQUE_NAME property specifies “the unique name of the hierarchy” to which the member to which it is applied belongs. HIERARCHY_UNIQUE_NAME has many applications, including the rather obvious uses with Analysis Services members that are included in the definition, as well as its pairing with other MDX functions to leverage its power even further. As an example, as we have seen is the case with many other member properties and functions in earlier articles of this series, HIERARCHY_UNIQUE_NAME can also be synergistically combined with the .CurrentMember function; we will see an example of this specific combination within the practice exercises that follow.

We will examine the syntax involved in leveraging the HIERARCHY_UNIQUE_NAME property after our customary overview in the Discussion section that follows. After that, we will conduct practice examples within a couple of scenarios, constructed to support hypothetical business needs that illustrate uses for the property. This will afford us an opportunity to explore some of the presentation options that HIERARCHY_UNIQUE_NAME can offer the knowledgeable user. Hands-on practice with HIERARCHY_UNIQUE_NAME, where we will create expressions that leverage the function, will help us to activate what we learn in the Discussion and Syntax sections that follow.

Discussion

To restate our initial explanation of its operation, the HIERARCHY_UNIQUE_NAME property, when acting upon a member, returns the unique name (the MDX “qualified” name) of the hierarchy to which the object to which it is appended with the period (“.”) delimiter belongs. HIERARCHY_UNIQUE_NAME can be used for a great deal more than the support of simple lists of unique object names, as we have intimated. When we couple it with other functions, we can leverage HIERARCHY_UNIQUE_NAME to deliver a wide range of analysis and reporting utility. As in so many cases with the Microsoft integrated business intelligence solution, consisting of MSSQL Server, Analysis Services and Reporting Services, this function, residing within the Analysis Services layer, can be extended to support capabilities and attributes in the Reporting Services layer. Knowing “where to put the intelligence” among the various layers is critical to optimization, in many cases. For more of my observations on this subject, see Multi-Layered Business Intelligence Solutions ... Require Multi-Layered Architects.

The HIERARCHY_UNIQUE_NAME property returns, as we have noted, the unique hierarchy name with which the specified member is associated, and can be used for querying and display, among other, purposes. If the member belongs to more than one hierarchy, there is, within the returned dataset, one row for each hierarchy to which the member belongs. (Per the Analysis Services Books Online, each component of this name is delimited for providers that generate unique names by qualification.)

Let’s look at some syntax illustrations to further clarify the operation of HIERARCHY_UNIQUE_NAME.

Syntax

Syntactically, anytime we employ the HIERARCHY_UNIQUE_NAME property to return the associated hierarchy name, the member for which we seek to return the hierarchy name is specified to the left of HIERARCHY_UNIQUE_NAME. The property takes the object to which it is appended as its argument, and returns, within a string, the unique hierarchy name to which the specified object belongs. The general syntax is shown in the following string:

<<Member_Expression>>.HIERARCHY_UNIQUE_NAME

In short, putting HIERARCHY_UNIQUE_NAME to work couldn’t be easier. When specifying the property to return the hierarchy name containing a member or members, we simply append it to the right of the member(s) under consideration.

As is typically the case with the majority of MDX functions, operators and properties, the HIERARCHY_UNIQUE_NAME property can often be best leveraged by combining it with other functions, operators or properties, particularly “relative” functions, to generate lists of names, and so forth, as we shall see in short order.

NOTE: For information on several of the “relative” functions, see my article MDX Member Functions: "Relative" Member Functions, within the Database Journal MDX Essentials series.

We will practice some uses of the HIERARCHY_UNIQUE_NAME property in the section that follows.

Practice

Preparation

To reinforce our understanding of the basics we have covered so far, we will use the HIERARCHY_UNIQUE_NAME property in a couple of examples that illustrate its operation. We will do so in simple scenarios that place HIERARCHY_UNIQUE_NAME 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 HIERARCHY_UNIQUE_NAME 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:

Prepare MSSQL Server Management Studio to Query Analysis Services

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, once again, 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 hierarchy 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” (their term for the unique names within Analysis Services), to provide an index, or map, for a developer who needs these names alongside the total Internet Sales Amount for each, for a reporting project he has undertaken.

This represents a simple, yet practical, need that we can readily satisfy using the HIERARCHY_UNIQUE_NAME property in conjunction with a relative function, .CurrentMember. (We previously accomplished a similar objective using the 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 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 hierarchy 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” in client parlance)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 hierarchy and City) can be used in axes, slicers, and so forth, within queries against the Analysis Services cube under consideration.

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 HIERARCHY_UNIQUE_NAME property. Once our colleagues provide an overview of the business requirements, and we together conclude that HIERARCHY_UNIQUE_NAME 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 HIERARCHY_UNIQUE_NAME property by examining a couple of introductory examples, the objective of the first of which is to generate a straightforward list of hierarchy name, and City member names and unique names, along with the corresponding Internet Sales Amounts, in a results dataset.

Procedure: Use the HIERARCHY_UNIQUE_NAME 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 containing unique hierarchy name, member names, member unique names, and Internet Sales Amount in four, side-by-side columns, with the corresponding City member names as rows.

1.  Type (or cut and paste) the following query into the Query pane:

-- MDX075-01 Using HIERARCHY_UNIQUE_NAME, MEMBER_NAME and MEMBER_UNIQUE_NAME
--   to generate a hierarchy name / member name / member unique name list 
--      within the data grid
    
WITH
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'

MEMBER
  [Measures].[Customer Geography - Hierarchy Name]
AS
  '[Customer].[Customer Geography].CurrentMember.HIERARCHY_UNIQUE_NAME'

         
SELECT
   {[Measures].[Customer Geography - Hierarchy 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.

Our Query in the Query Pane ...
Illustration 1: Our Query in the Query Pane ...

2.  Execute the query by clicking the Execute (!) button in the toolbar.

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

Results Dataset (Partial View) – Combined Use of HIERARCHY_UNIQUE_NAME,  MEMBER_NAME and MEMBER_UNIQUE_NAME with .CurrentMember
Illustration 2: Results Dataset (Partial View) – Combined Use of HIERARCHY_UNIQUE_NAME, MEMBER_NAME and MEMBER_UNIQUE_NAME with .CurrentMember

We see the [Customer].[Customer Geography] hierarchy name, the output of the Customer Geography - Hierarchy Name calculated member, populating the first data column. The respective Customer Geography City names, the output of the Customer Geography – City Name calculated member, populate the second 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 third 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 - Hierarchy Name calculated member exploits the HIERARCHY_UNIQUE_NAME property in conjunction with the “relative” .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 practical 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.

3.  Select File > Save As, name the file MDX075-01, and place it in a meaningful location.

Our client colleagues express satisfaction with our initial solution, and state that it satisfactorily displays the hierarchy 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 hierarchy 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.

Procedure: Use the HIERARCHY_UNIQUE_NAME property (among others) in another example to Provide Parameter Picklist Support in Reporting Services

Let’s look at an example that expands upon our first, this time to meet a mechanical need within the reporting layer of an integrated BI application. As many of us are aware, enterprise reporting applications typically allow for parameterization (via what are sometimes known as “prompts” or “parameter prompts”) to enable information consumers to quickly find the information they need from a report. These parameters, whose values are physically passed to an axis specification or a slicer in the dataset query, often act to put filters into place “on the fly;” the “filters” are thus enacted when the consumer types or selects a value, or a series of values, at run time.

In general, there are two primary types of parameters, type-in and picklist, which can be mechanized through various means. Type-in parameters accept directly typed user input for the value upon which the report is based. An example of input might, for a report based upon an Analysis Services cube, consist of the unique name for a given filter, say, for one of the Customer Geography Cities in the list we created earlier.

The trouble with type-in parameters is that they are subject to input error, and thus can fail to produce the desired results if they are not precisely correct. This can be particularly cumbersome for information consumers when the report is based upon an Analysis Services cube, because, even with a list like we generated above with the unique names mapped to the “English” names for various filter selections, the precise MDX qualified name might present a typing challenge for some.

For this reason, the alternative parameter type, the picklist, provides a more user-friendly experience. A picklist presents a selection of choices to a consumer, based upon a static file, a dataset from a larger data source, or through other means. The picklist is often the tool of choice, because of its inherent elimination of typing errors. A well-constructed picklist makes selection easy for the consumer (who is not often pleased with a long scrolling process, or other cumbersome method, as the initial step in generating a commonly requested report). An investment in developing a good picklist often pays great dividends in consumer satisfaction.

The list we have generated above provides virtually all we need to support parameterization within Reporting Services and other enterprise reporting applications. Let’s do another example, this time with the primary objective of picklist support. We will construct a dataset upon which the picklist selections can be based, and then overview an illustration of the use of this dataset in MSSQL Server Reporting Services.

NOTE: For details surrounding various hands-on approaches, (the options are legion) to constructing picklists in Reporting Services, see these articles in MSSQL Server Reporting Services series here at Database Journal:

Let’s assume, as a background scenario, that, in contacting us to say that they are happy with the index we have provided for the developer as outlined in our previous example, the Reporting department with which we worked earlier asks for further assistance of a similar nature. Their next request is a common one: they want to provide picklist support within an OLAP report, which they have constructed using MSSQL Server Reporting Services. The data source is, once again, the Adventure Works sample cube that accompanies an installation of MSSQL Server Analysis Services 2005 (and with which most of us are familiar).

The consumers want the selector for the parameter picklist to display the “regular” name for the Product Categories each time an information consumer runs the report – while the Report Parameter is to reference (and thus “pass”) the unique (“MDX - qualified”) name to Reporting Services for purposes of filtering the report. Moreover, they wish to add the hierarchy name into the dataset, for inclusion primarily as a report label – although we inform them that, at a later date, we will expand upon the use of hierarchy names in the dataset to support cascading parameters that will allow us, among other options, to extend report parameterization to allow us to make choices to vary the hierarchies upon which we want to perform ad hoc prompts at runtime, to provide an even greater capacity for the report to “do more with less.”

While the focus of our article is the MDX required in meeting this request, and specifically upon the use of the HIERARCHY_UNIQUE_NAME property 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 designated OLAP report. Let’s create a query to generate the list, and then take a look at a simple example of how we might use the data returned within the reporting layer.

Our initial approach is quite similar to the previous example – it’s 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 HIERARCHY_UNIQUE_NAME property in conjunction with a relative function, .CurrentMember. The solution also includes the MEMBER_NAME and MEMBER_UNIQUE_NAME properties, as did our predecessor solution. We will be targeting the member name column in the resulting dataset (we’ll call it Product Category - Name) for the name that is displayed in the selector for the parameter picklist. The member unique name column of the returned dataset (the qualified “MDX” name for each Category member of the Product dimension, Product Categories attribute hierarchy), which we call Product Category – MDX Qual Name in the query we 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 the capability to perform ad hoc selection of a Product Category upon which to filter the report data. (We might use the value returned by the Product Category - Hierarchy Name calculated member, which relies upon the HIERARCHY_UNIQUE_NAME property, as a label somewhere within our report).

Our first step is to construct a query to return the requested Product Category list, presenting the hierarchy name, together with the respective selector member names and unique names in three side-by-side columns. The corresponding Product Category members of the Product dimension (Product Categories attribute hierarchy) will inhabit the row axis, as we shall see.

1.  Select File --> New from the main menu, once again.

2.  Select Query with Current Connection from the cascading menu that appears next, as depicted in Illustration 3.

Create a New Query with the Current Connection ...
Illustration 3: Create a New Query with the Current Connection ...

A new tab, with a connection to the Adventure Works cube (we can see it listed in the selector of the Metadata pane, as expected) appears in the Query pane.

3.  Type (or cut and paste) the following query into the Query pane:

-- MDX075-02 Using .HIERARCHY_UNIQUE_NAME, .MEMBER_NAME and 
--   .MEMBER_UNIQUE_NAME to generate a picklist selection

WITH

MEMBER
   [Measures].[Product Category - Hierarchy Name]
AS
   '[Product].[Product Categories].CurrentMember.HIERARCHY_UNIQUE_NAME'
   
MEMBER
   [Measures].[Product Category - Name]
AS
   '[Product].[Product Categories].CurrentMember.MEMBER_NAME'

MEMBER
   [Measures].[Product Category - MDX Qual Name]
AS
   '[Product].[Product Categories].CurrentMember.MEMBER_UNIQUE_NAME'

SELECT
   {[Measures].[Product Category - Hierarchy Name],
      [Measures].[Product Category - Name], 
         [Measures].[Product Category - MDX Qual Name]} 
      ON AXIS(0),
        
   {[Product].[Product Categories].[Category].MEMBERS}
     ON AXIS(1)

FROM 
[Adventure Works]  

The Query pane appears, with our input, as shown in Illustration 4.

Our Second Query in the Query Pane ...
Illustration 4: Our Second Query in the Query Pane ...

4.  Execute the query by clicking the Execute (!) button in the toolbar.

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

Results Dataset – Another Use of HIERARCHY_UNIQUE_NAME, MEMBER_NAME and MEMBER_UNIQUE_NAME with .CurrentMember
Illustration 5: Results Dataset – Another Use of HIERARCHY_UNIQUE_NAME, MEMBER_NAME and MEMBER_UNIQUE_NAME with .CurrentMember

We see the unique hierarchy name, the output of the Product Category – Hierarchy Name calculated member, populating the first data column. Additionally, the respective member names for the individual Product Categories, the output of the Product Category - Name calculated member, appear within the second data column. Finally, the associated Product Category member unique names (again, the “qualified” MDX name that can be used within a query against the Adventure Works cube) - the output of the Product Category – MDX Qual Name calculated member - occupy the third data column. The Product Category attribute hierarchy members themselves occupy the row axis, as our client colleagues have requested (the row axis will not be used in the reporting environment).

The calculated members Product Category – Hierarchy Name, Product Category - Name and Product Category - MDX Qual Name employ the HIERARCHY_UNIQUE_NAME property, the MEMBER_NAME property and MEMBER_UNIQUE_NAME property, 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 hierarchy name, and the member names and qualified names of the members that we specify in our row axis.

5.  Select File > Save As, name the file MDX075-02, and place it in a meaningful location.

We will not take the steps (which occur inside the reporting layer) to construct the picklist apparatus within this article. 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’ own Data tab to generate a dataset within the report under consideration. This query, together with the dataset it generates, would look something similar to that which is partially shown in Illustration 6.

Constructing a Dataset in Reporting Services to Support a Parameter Picklist
Illustration 6: Constructing a Dataset in Reporting Services to Support a Parameter Picklist

NOTE: This is only one approach to creating the dataset – perhaps the more obvious of several. Another might be more optimal, depending upon the reporting environment under consideration. Other options, the components of which might occupy different layers of the Microsoft integrated business intelligence solution, might include installation of the calculated members at the UDM / cube level, and then calling (versus defining and building) them from the reporting layer.

For a step-by-step procedure that demonstrates the construction of such a cube-based solution to support a picklist in Reporting Services, see Create a Cube-Based Hierarchical Picklist in my MDX in Analysis Services series, or Parameterization from Analysis Services – Cascading Picklists in my MSSQL Server Reporting Services series here at Database Journal.

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 left it named at the default of Dataset1), as shown, and then select Product Category - MDX Qual Name and Product Category - Name within the Value and Label fields respectively. Illustration 7 presents a view of the way all this would tie together in the Report Parameter dialog inside Reporting Services.

Pulling It All Together inside the Report Parameter ...
Illustration 7: Pulling It All Together inside the Report Parameter ...

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 Category parameter.

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

The Product Category Parameter Selector in Action ...
Illustration 8: The Product Category Parameter Selector in Action ...

And so we see that our query, using the HIERARCHY_UNIQUE_NAME, MEMBER_NAME and MEMBER_UNIQUE_NAME intrinsic member properties - in conjunction with the “relative” .CurrentMember function - to present the hierarchy names, member names and member unique names for the Product Categories in three side-by-side columns, can be readily used to support a picklist for a parameter within the reporting layer of the business intelligence solution of our client. (As we noted earlier, we might use the value returned by the Product Category - Hierarchy Name calculated member, which relies upon the HIERARCHY_UNIQUE_NAME property, to act as a label, to support yet another parameter, or perhaps to perform some other function, somewhere within our report).

Having demonstrated the workings of the HIERARCHY_UNIQUE_NAME, MEMBER_NAME and MEMBER_UNIQUE_NAME properties in this fashion has helped us to show our client colleagues that we have, within the current dataset query, established support for parameterization based upon underlying cube data. Our client colleagues express satisfaction with the results, and confirm their understanding of the operation of the HIERARCHY_UNIQUE_NAME property within the contexts we have presented in the practice exercises. We reiterate to the Reporting team that knowing “where to put the intelligence” within the various layers of the Microsoft integrated BI solution can mean highly tuned performance and effective solutions for consumers throughout our organizations.

6.  Select File -> Exit to leave the SQL Server Management Studio, when ready.

Summary ...

In this article, we introduced the MDX HIERARCHY_UNIQUE_NAME property, 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 HIERARCHY_UNIQUE_NAME.

We examined the syntax involved with HIERARCHY_UNIQUE_NAME, 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 examples that drew upon our earlier examinations of the MEMBER_NAME property (in Intrinsic Member Properties: The MEMBER_NAME Property), and the MEMBER_UNIQUE_NAME property (in Intrinsic Member Properties: The MEMBER_UNIQUE_NAME Property),which we used in combination with HIERARCHY_UNIQUE_NAME to create a results dataset. We then illustrated the use of a similar dataset to support a parameter picklist in a report that queried an Analysis Services data source. Throughout our practice session, we briefly discussed the results datasets we obtained from each of the queries we constructed.

About the MDX Essentials Series ...

This article is a member of the MDX Essentials series, a monthly column designed to provide hands-on application of the fundamentals of the Multidimensional Expressions (MDX) language, with each article progressively adding features designed to meet specific real-world needs.

For more information about the column in general, as well as the software and systems requirements for getting the most out of the lessons included, please see my first article, MDX at First Glance: Introduction to MDX Essentials, among others.

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

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved