Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Links Database Forum

» Database Journal Home
» Database Articles
» Database Tutorials
MS SQL
Oracle
DB2
MS Access
MySQL
» RESOURCES
Database Tools
SQL Scripts & Samples
Links
» Database Forum
» Sitemap
Free Newsletters:
DatabaseDaily  
News Via RSS Feed


follow us on Twitter
Database Journal |DBA Support |SQLCourse |SQLCourse2
 

Featured Database Articles

MS SQL

Posted Feb 6, 2009

Intrinsic Member Properties: The HIERARCHY_UNIQUE_NAME Property

By William Pearson

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:

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.



MS SQL Archives

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 




Latest Forum Threads
MS SQL Forum
Topic By Replies Updated
SQL 2005: SSIS: Error using SQL Server credentials poverty 3 August 17th, 07:43 AM
Need help changing table contents nkawtg 1 August 17th, 03:02 AM
SQL Server Memory confifuration bhosalenarayan 2 August 14th, 05:33 AM
SQL Server Primary Key and a Unique Key katty.jonh 2 July 25th, 10:36 AM