Intrinsic Member Properties: The MEMBER_VALUE Property

Friday Sep 12th 2008 by William Pearson

Share:

MSAS Architect Bill Pearson leads hands-on exercises providing exposure to the use of the MEMBER_VALUE intrinsic member property. Join us in generating simple lists, as well as datasets to support report parameter picklists.

About the Series ...

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

Overview

In this lesson, we will examine another intrinsic member
property, MEMBER_VALUE.As many of us are aware, and as we
have confirmed in various other articles within this
series, 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. MEMBER_VALUE belongs to the second group of properties.
As a general group, intrinsic memberproperties 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 MEMBER_VALUE property is to support the return of a value
for the member with which it is associated. MEMBER_VALUE 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,
MEMBER_VALUE 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 MEMBER_VALUEproperty can be leveraged in
activities that range from generating simple lists to supporting sophisticated
presentations. It is a particularly effective tool when we need to provide parameter
picklist support and the like, as we shall see. We shall 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 MEMBER_VALUE Property

Introduction

According to the Analysis Services
Books Online, the MEMBER_VALUE property specifies the value of the
member in the original type. The MEMBER_VALUE property is set within the ValueColumn
element of the Source properties group for a given dimension
attribute, as we shall see.

As we shall see in the initial Preparation
steps of our Practice session below, the ValueColumn property
allows us to specify the column within the underlying data source from which Analysis
Services derives the value of the attribute. Within this
setting, we may findeither the None or the New option (a
third option, representing a preselected column, will exist if a column has
already been selected  not the case in our current example, but possibly
different elsewhere).

As we noted in Dimension Attributes: Introduction and Overview, Part
V, if we have specified a value in the NameColumn
property, then the same value is used as the default in ValueColumn.
If we did not specify a value in the NameColumn property, and the KeyColumns
collection of the attribute contains a single KeyColumn element
representing a key column with a string data type, the same
values are used as default values for the ValueColumn element.

MEMBER_VALUE 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. For example, as we have seen is the case with the .Name
function (among many other functions), in earlier articles of this series, MEMBER_VALUE
can also be synergistically
combined with the .CurrentMember
function; we will see an example of this specific combination within the
practice exercises below.

We will examine the syntax involved in
leveraging theMEMBER_VALUEproperty
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 MEMBER_VALUEcan
offer the knowledgeable user. Hands-on practice with MEMBER_VALUE, 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 MEMBER_VALUE
property, when acting upon a member, returns the assigned value of
the object to which it is appended with the period (.) delimiter. MEMBER_VALUE
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 MEMBER_VALUE 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 MEMBER_VALUE property returns, as we have noted, the
value contained within the column of the underlying data source from which Analysis
Services derives the value of the attribute, and can be used
for querying and display, among other, purposes. Lets look at some syntax
illustrations to further clarify the operation of MEMBER_VALUE.

Syntax

Syntactically, anytime we
employ the MEMBER_VALUE property to return the associated value,
the member for which we seek to return the value is specified to
the left of MEMBER_VALUE. The property takes the object to which
it is appended as its argument, and returns, within its original data type, the
value of the object specified. The general syntax is shown in the
following string:

<<Member_Expression>>.MEMBER_VALUE

In short, putting MEMBER_VALUE to
work couldnt be easier. When specifying theproperty to return the value
of a member or members, we simply append it to the right of the member(s)
under consideration.

As is typically the case with
MDX functions, operators and properties, the MEMBER_VALUE 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.

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

Practice

Preparation

Preparation within Analysis Services  Business
Intelligence Development Studio

To make our practice exercise more meaningful, we will make
a minor modification to the Adventure Works database sample  a sample
that is available to anyone who installs Analysis Services 2005. We
will perform our modification within the SQL Server Business Intelligence
Development Studio, in the steps that follow.

1.
Click Start.

2.
Navigate to,
and click, the SQL
Server Business Intelligence Development Studio, as appropriate.

We briefly see a splash page that lists the components
installed on the PC, and then Visual Studio .NET 2005 opens at the
Start page.

6.
Ensuring that the Connect to existing database radio button is
selected, type the Analysis Server name into the Server input box
atop the dialog.

7.
Using the
selector just beneath, labeled Database, select Adventure WorksDW,
as shown in Illustration
2.

Illustration 2: Selecting the Sample Analysis Services
Database ...

8.
Leaving other settings on the dialog at default, click OK.

SQL
Server Business Intelligence Development Studio briefly reads the database from
the Analysis Server, and then we see the Solution Explorer
populated with the database objects, as depicted in Illustration 3.

Illustration 3: The Adventure Works DW Database Objects
within the Solution Explorer

As we have noted in the introduction, the ValueColumn
property of a dimension attribute allows us to specify the column
within the underlying data source from which Analysis Services derives
the value of the attribute. ValueColumn is similar to the
NameColumn property (we get some
hands-on exposure to these and other Source property settings in my
article Dimension
Attributes: Introduction and Overview, Part V), in that it offers a
downward arrowselector button that appears to the immediate right of
theproperty label.

Lets use the selector to replace the default
selection of (none)with a column within the underlying data. For
the purposes of illustration, we will say that, in addition to specific
reporting needs that they outline below, representatives of our hypothetical
client, the Adventure Works organization, have informed us that they
wish to be able to report Postal Code values , along with City
(already the NameColumn setting for the City attribute), within the
Customer dimension of the Adventure Works UDM.

To
access these settings for the targeted attribute (City)within
the containing dimension (Customer), we will need to open that dimension
within the Dimension Designer first. We
will accomplish this using the Dimension Designer.

9.
Within the Solution Explorer, right-click the Customer
dimension (expand the Dimensions folder as necessary).

10.
Click Open
on the context menu that appears, as shown in Illustration 4.

Illustration
4: Opening the Dimension via the Dimension Designer ...

The tabs of the Dimension
Designer open.

11.
Click the Dimension Structure tab, if
we have not already arrived there by default.

12.
Examine the member
attributes that appear within the Attributes pane of the Dimension Structure tab.

The
attributes belonging to the Customer dimension
appear as depicted in Illustration 5.

Illustration 5: The Member
Attributes, Customer Dimension

We note
that twenty-one attributes appear within the Attributes pane. At
this stage, we can move to the City attribute to make the simple
modification necessary to support the practice session that follows.

13.
Within the Attributes paneof the Dimension Structure
tab, right-click the Cityattribute.

14.
Click Properties
on the context menu that appears, as shown in Illustration 6.

Illustration 6: Select Properties
from the Context Menu ...

The Properties
pane appears for the City attribute. (The Properties pane
likely appeared when we selected the City attribute within the Attributes
pane, by default, below the Solution Explorer. The design environment
can, of course, be customized in many ways to accommodate our local development
needs.) The setting with which we are concerned, at least within the context
of our preparation efforts, lies within the Source properties group,
which appears just underneath the Parent-Child properties group within
the Properties pane, as depicted (with all properties groups collapsed) in Illustration
7.

Illustration 7: The Properties Pane (Properties Groups
Collapsed)

15.
Expand the Source
properties group in the Properties pane, if necessary, by clicking
the + sign that appears to the immediate left of theSource label.

The Properties pane displays a list of properties members
of theexpanded Source properties group, as shown in Illustration 8.

Illustration 8: The Expanded Source Properties Appear ...

At the
bottom of the Source properties, we see ValueColumn, noting that
it displays a default setting of (none). We will modify this setting
to reference a column
within the underlying data source, to provide support for the business need
expressed by our client colleagues.

16.
Click the ValueColumn label, to select the property and
to activate the selector for its setting.

17.
Click the
downwardarrowselector button that appears to the immediate
right of theValueColumn label, to expose the two basic
options for selection.

The
two selection options that are available are None, and New (a
preselected column, simply a notation of the Table / Column involved,
appears as a third item, assuming a column has already been selected).

18.
Select the New
option within the selector, as depicted in Illustration 9.

The Object Binding dialog appears. We use the Object
Binding dialog box in Business Intelligence Development Studio to
define bindings between the property of an Analysis Services object and
a table / column in a data source view.

We will use the Object
Binding dialog to select Binding type, Source table and Source
column as appropriate to our clients stated needs, and then save our
changes, taking the following steps:

19.
Within the Source
column pane of the Object
Binding dialog, click PostalCode, as shown
in Illustration 10.

Having
made the modification necessary to support our practice session, we have only
to process the Analysis Services database to complete our preparation steps.

21.
Right-clickthe Adventure Works DW database within the Solution Explorer.

22.
Select Process
... from the context menu that appears, as shown in Illustration 12.

Illustration 12: Select Process ... from the Context Menu

23.
Click Yes on
the Microsoft Visual Studio message box that appears next, asking if we
wish to save changes first, as depicted in Illustration 13.

Illustration 13: Click Yes to Save Changes First ...

24.
Click the OK
button at the bottom of the Object Binding dialog box to accept the selection
and to dismiss the dialog.

We are
informed, via a message, that Analysis Services is updating information
on the server, and then the Process Database dialog appears, as shown in Illustration 14.

Illustration 14: The Process Database Dialog Appears ...

25.
Click the Run
... button in the lower right of the dialog.

The Process
Progress viewer appears, and presents updates / events as processing
proceeds. Processing completes, and a message appears in the Status
bar, indicating that the process has succeeded, as depicted in Illustration
15.

27.
Dismiss the Process
Progress viewer, as well, by clicking its Close button.

Having
completed the enhancements requested by our client colleagues, and having
processed the database / cube to reflect the update, we are ready to proceed
with the hands-on portion of our lesson.

28.
Select File
-> Exit to leave the Business Intelligence Development
Studio, when
ready.

Preparation within Analysis Services  SQL Server
Management Studio

To reinforce our understanding of the basics we have covered
so far, we will use the MEMBER_VALUE property in a couple of examples
that illustrate its operation. We will do so in simple scenarios that place MEMBER_VALUE
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 MEMBER_VALUE 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 DWAnalysis 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 continue to
work within our foregoing assumption that we have received a call 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.

Much as they have in past events, recorded in earlier
articles of this series, a group of report authors want to display the Names
of the Customer Geography Cities (the City level members of
the Customer Geography hierarchy of the Customer dimension),
alongside the respective MDX Qualified Names (their term for the Unique
Names within Analysis Services), to provide an index, or map, for a
developer who needs the Unique (MDX) Names, alongside the total
Internet Sales Amount for each, for a reporting project he has
undertaken. In addition, and unlike previous requests in this arena, our
colleagues tell us that they also want to present the newly added (in the
preparation section above) customer Postal Code information that has now
been added via the Member Value property of each Cityattribute
member. They state that they would like to present the Postal Code between
the Unique (MDX) Names and the total Internet Sales Amount
for each customer within the returned dataset. Moreover, they state that they
may choose to parameterize Postal Code within the reports at a later
time.

This represents a simple, yet practical, need that we can
readily satisfy using the associated intrinsic member properties. Just as we
did with the MEMBER_UNIQUE_NAME property (as well as others) in earlier
sessions, we will employ MEMBER_VALUE in conjunction with a relative
function, .CurrentMember. (We accomplished similar objectives using both
the MEMBER_NAME and MEMBER_UNIQUE_NAME properties in earlier
scenarios, 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 Intrinsic Member Properties: The MEMBER_UNIQUE_NAME
Property.) We will create a basic query that
returns the Citynames for each U.S. City in which we have
customers (whether we have conducted Internet Sales with them or not), together
with the Names, Unique Names and Values (the Postal Code)
for each respective U.S. City. Some of the Names, Unique Names
and Values we generate with the query will ultimately find their way
into the Dataset definition of reports that the developer intends to
construct within Reporting Services  and any of these values 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 MEMBER_NAME, MEMBER_UNIQUE_NAME, and (the primary
focus of this article) MEMBER_VALUE properties. Once our colleagues
provide an overview of the business requirements, and we conclude that MEMBER_VALUE
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 MEMBER_VALUE property (as well as confirm their previous
understanding of the MEMBER_NAME and MEMBER_UNIQUE_NAME properties)
by examining an introductory example, where our objective is to generate a
straightforward list of City member Names, Unique Names, and
Values (Postal Codes), together with corresponding Internet
Sales Amounts, in a results dataset.

Procedure: Use the MEMBER_VALUE 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 CustomerCityinformation, presenting the
Names, Unique Names, Values (Postal Codes) and Internet
Sales Amount in four, side-by-side columns, with the corresponding City
member names as rows.

We see CustomerGeographyCity names,
the output of the Customer Geography - Name calculated member,
populating the first data column. The respective Customer Geography City
Unique Name (a qualified MDX name that can, itself, be used within a
query against the Adventure Works cube) for each City occupies
the second data column (which we populate via the Customer Geography - MDX
Qual Name calculated member in the query). The Postal Codes, the
output of the Customer Geography  Postal Code calculated member,
populate the third data column, which appears to the immediate left of the
fourth column, containing the corresponding Internet Sales Amount
measure. The Customer Geography City members themselves occupy the row
axis, as the client has requested.

The Customer Geography  Postal Code calculated
member employs the MEMBER_VALUE, property (the focus of this article),
in conjunction with the relative .CurrentMember function. The
calculated members Customer Geography - Name and Customer Geography -
MDX Qual Name employ the MEMBER_NAME property and the MEMBER_UNIQUE_NAME
property, respectively, each also in conjunction with the relative .CurrentMember
function. As we can easily see from our practical example, these three
calculated members are then used together to return, via the dataset we see
above, a combination list of the names (which might be used as captions
/ labels within a given report layout), the qualified names (which
could be passed from the reporting layer to Analysis Services via
parameterization at report runtime), and the postal codes (which we
could parameterize, display, or both, within the report) of the members that we
specify in our row axis.

3.
Select File
> SaveAs, name the file MDX070-01,
and place it in a meaningful location.

Our
client colleagues express satisfaction with our initial solution, and state
that it satisfactorily displays the Postal Code values they want,
alongside the respective Names and qualified / Unique Names of
the Customer Geography Cities, together with the associated Internet
Sales Amount measure, within Analysis Services. They state that they
expect this approach to provide the desired index for the developer who needs
the Names, Unique (MDX) Names, and Postal Code values,
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 MEMBER_VALUE property in another
example to Provide Parameter Picklist Support within the Reporting Layer

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 Postal Code for a given filter, say, for one of the Customer
Geography Cities in the list we created earlier. (Cities routinely have
multiple postal codes.)

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
ServerReporting Services.

NOTE:
For details surrounding hands-on approaches (as you will see, they are Legion)
to constructing picklists in Reporting Services, see these articles in my
MSSQL Server Reporting
Servicesseries
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 ServerReporting
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 Postal Codes for the organizations
Customer list each time an information consumer runs the report  while
the Report Parameter is to reference (and thus pass) the unique, MDX
- qualified, name that corresponds to the selected Postal Code to Reporting
Services for purposes of filtering the report.

While the focus of our article is the MDX required in
meeting this request, and specifically upon the use of the MEMBER_VALUE
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 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 MEMBER_VALUE property in conjunction with a relative function, .CurrentMember.
The solution also includes the MEMBER_UNIQUE_NAME property. We will be
targeting the Postal Code column in the resulting dataset (well call it
Customer Postal Code  Postal Code) for the name that is displayed in
the selector for the parameter picklist. The Unique Name
column of the returned dataset (the qualified MDX name for each Postal
Code attributemember of the Customer dimension, Customer
Geography attribute hierarchy), which we call Customer Postal Code - 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 ad
hoc selection of a simple Postal Code upon which to filter the report
data.

Our first step is to construct a query to return the
requested Postal Code list, presenting the selector Codes and Unique
Names in two side-by-sidecolumns. The corresponding Postal Code
attribute members of the Customer dimension (Customer Geography 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 shown
in Illustration 18.

Illustration 18: 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 Metadatapane, as expected) appears in the
Query pane.

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

Illustration 19: 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 shown in Illustration 20 appears.

Illustration 20: Results Dataset  Another Use of MEMBER_VALUE
and MEMBER_UNIQUE_NAME with .CurrentMember

We see Postal Code for the
individual Customers, the output of the Customer Postal Code  Postal
Code calculated member, populating the first data column. The respective Postal
Code Unique Names (again, the qualified MDX name for the associated Postal
Code attribute members, which can be used within a query against the Adventure
Works cube) - the output of the Customer Postal Code  MDX Qual Name
calculated member - occupy the second data column. The Postal Code 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 Customer Postal Code  Postal Code and Customer
Postal Code  MDX Qual Name employthe MEMBER_VALUE 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 Postal Code
values / Qualified Names of the members that we specify in our row
axis.

5.
Select File
> SaveAs, name the file MDX070-02,
and place it in a meaningful location.

Overview: Extending the Solution to the Reporting Layer

We
will not take the steps, within this article (which occur inside the reporting
layer), to construct the picklist apparatus. 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 depicted in Illustration
21.

Illustration 21: 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 cube level, and then calling (versus defining and building) them
from the reporting layer.

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 named it PostalCode_Param), and then select Customer_Postal_Code__MDX_Qual_Name and Customer_Postal_Code__Postal_Code
within the Value
and Label
fields respectively. Illustration 22 presents a view of the way all
this would tie together in the Report Parameter dialog inside Reporting
Services.

Illustration 22: 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 Reporting Services articles I have
cited above). Executing the query then triggers the prompting action of the
new Postal Code parameter.

The selection list, displaying the regular Postal Code
value, is manifested in the parameter dropdown when we preview or execute the
report, as partially shown in Illustration 23.

Illustration 23: The Postal Code Parameter Selector in
Action ...

And so we see that our query, using the MEMBER_VALUE and
MEMBER_UNIQUE_NAME intrinsic memberproperties - in conjunction
with the relative .CurrentMember function - to present the Postal
Code valuesand Unique Names for Customers in two
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. Having demonstrated the workings of the MEMBER_VALUE 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 MEMBER_VALUE 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.

Summary ...

In
this article, we introduced the MDX MEMBER_VALUE 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 MEMBER_ VALUE.

We
examined the syntax involved with MEMBER_VALUE, and then, after
preparing the sample database to support our training needs, 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 (in Intrinsic Member Properties: The MEMBER_NAME Property) and MEMBER_UNIQUE_NAME (in Intrinsic
Member Properties: The MEMBER_UNIQUE_NAME Property)properties, which we used in
combination with other MDX functionsto 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.