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 gridWITH
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.
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.
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.