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.
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, both 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 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 member properties - in conjunction
with the “relative” .CurrentMember function - to present the Postal
Code values and 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.
6.
Select File
-> Exit to leave the SQL Server Management Studio, when ready.
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 functions 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.
»
See All Articles by Columnist William E. Pearson, III
Discuss this article in the MSSQL Server 2000 Analysis Services and MDX Topics Forum.
» 
Comment and Contribute
