This
month, we will examine the LEVEL_UNIQUE_NAME intrinsic
member property. Once we have briefly introduced LEVEL_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 LEVEL_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, LEVEL_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. LEVEL_UNIQUE_NAME belongs to the latter
group of properties. As a general group, intrinsic member properties
provide additional information that can be used by applications to enhance the ultimate
user experience. Support for the non-context sensitive member properties is
the same for all members, regardless of individual context.
The purpose of the LEVEL_UNIQUE_NAME
property is to support the return of the unique name of the hierarchical
level to which a member belongs. LEVEL_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, LEVEL_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 LEVEL_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 LEVEL_UNIQUE_NAME Property
Introduction
According to the Analysis Services
Books Online, the LEVEL_UNIQUE_NAME property specifies “the unique
name of the level to which the” member to which it is applied belongs. LEVEL_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, LEVEL_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 LEVEL_UNIQUE_NAME property after our customary overview
in the Discussion section that follows. Having completed the
introduction, 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 LEVEL_UNIQUE_NAME can offer the knowledgeable
user. Hands-on practice with LEVEL_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 LEVEL_UNIQUE_NAME
property, when acting upon a member, returns the unique name (the
MDX “qualified” name) of the level to which the object – to which it is
appended with the period (“.”) delimiter – belongs.
LEVEL_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 LEVEL_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 scenarios. For
more of my observations on this subject, see Multi-Layered
Business Intelligence Solutions … Require Multi-Layered Architects.
The LEVEL_UNIQUE_NAME property
returns, as we have noted, the unique level name with which
the specified member is associated, and can be used for querying and display,
among other, purposes. (Per the Analysis
Services Books Online, each component of this name is delimited for
providers that generate unique names by qualification.)
Let’s discuss syntax considerations to further clarify the
operation of LEVEL_UNIQUE_NAME.
Syntax
Syntactically, anytime we
employ the LEVEL_UNIQUE_NAME property to return the associated level
name, the member for which we seek to return the level name
is specified to the left of LEVEL_UNIQUE_NAME. The property takes the object
to which it is appended as its argument, and returns, within a string,
the unique level name to which the specified object belongs.
The general syntax is shown in the following string:
<<Member_Expression>>.LEVEL_UNIQUE_NAME
In short, putting LEVEL_UNIQUE_NAME to
work couldn’t be easier. When specifying the property to return the level
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 LEVEL_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 LEVEL_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 LEVEL_UNIQUE_NAME property in a couple of
examples that illustrate its operation. We will do so in simple scenarios that
place LEVEL_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 LEVEL_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 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” (their term for 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 a reporting project he has undertaken.
This represents a simple, yet practical, need that we can
readily satisfy using the LEVEL_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 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” 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 level 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 LEVEL_UNIQUE_NAME property. Once our colleagues provide
an overview of the business requirements, and we together conclude that LEVEL_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 LEVEL_UNIQUE_NAME property by examining a couple of
introductory examples, the objective of the first of which is to generate a straightforward
list of level name, and City member names and unique
names, along with the corresponding Internet Sales Amounts, in a
results dataset.
Procedure: Use the LEVEL_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 level 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:
— MDX076-01 Using LEVEL_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 – Level Name]
AS
‘[Customer].[Customer Geography].CurrentMember.LEVEL_UNIQUE_NAME’SELECT
{[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.
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 LEVEL_UNIQUE_NAME, MEMBER_NAME and MEMBER_UNIQUE_NAME with .CurrentMember
We see the [Customer].[Customer
Geography] level name ([Customer].[Customer Geography].[City]), the
output of the Customer Geography – Level 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 – Level Name calculated
member exploits the LEVEL_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 MDX076-01,
and place it in a meaningful location.
Our
client colleagues express satisfaction with our initial solution, and state
that it satisfactorily displays the hierarchical level 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
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.