Process
the Product Dimension, and Examine the Mechanics behind the Removal of Members
without Corresponding Key Values within the Underlying Data
Let's
process the Product dimension, and take a look “under the hood” to gain
an understanding of the mechanics behind the elimination of Products
that do not have values within the respective ProductSubcategoryKey
column within the underlying data.
1.
From our
current position within the Dimension Designer for the Product dimension,
select Dimension -> Process
from the main menu, as depicted in Illustration 31.
Illustration 31: Processing
the Product Dimension ...
2.
Click Yes
on the dialog box that appears next, asking if we wish to save all changes
before building, deploying and processing the dimension, as shown in Illustration
32.
Illustration 32: Click
Yes to Save All Changes
3.
Click Run on
the Process Dimension - Product dialog that appears next, as depicted in
Illustration 33, to process the Product dimension.
Illustration 33: Click
Run to Process the Product Dimension
4.
When
processing has successfully completed, expand Processing Dimension 'Product'
completed successfully in the Process Progress event viewer.
5.
Expand Processing
Dimension Attribute 'Product Name' completed successfully, appearing
underneath the entry we expanded in the last step.
6.
Click the SELECT
DISTINCT query.
7.
Click the View
Details button on the Process Progress event viewer.
Within the View Details viewer, at the end of the
SQL query, we see a WHERE clause, as shown in Illustration 34.
Illustration 34: The
WHERE Clause Removes Keyless Members
The
clause reads as follows:
WHERE
(
(
[dbo_DimProduct].[ProductSubcategoryKey] =
[dbo_DimProductSubcategory].[ProductSubcategoryKey]
)
)
As is somewhat obvious, the WHERE clause has been
added to the SELECT DISTINCT clause to remove those Product
members that have no matching value in the ProductSubcategoryKey column.
8.
Click Close
to dismiss the View Details viewer.
9.
Click Close
to dismiss the Process Progress viewer.
10.
Click Close
to dismiss the Process Dimension-Product dialog.
And so we see how Product members that are
referenced within the fact table, but which have no corresponding key matches
in the respective dimension table, are removed as a part of processing.
Elimination of these unmatched members from inclusion within the cube allows
processing to continue uninterrupted for the members that are otherwise
acceptable.
11. Click the Browser tab in Dimension
Designer for the Product dimension.
12. Click the Reconnect button,
as depicted in Illustration 35.
Illustration 35: Click
the Reconnect Button
13. Select Product Model Lines
in the Hierarchy selector atop the Browser tab.
14. Expand All Products within
the hierarchy tree by clicking the “+” sign to its immediate
left.
15. Expand Components within
the Product Line level, as we did in our earlier browse, to arrive at
the results shown in Illustration 36.
Illustration 36: Product
Model Lines Hierarchy, Reflecting the Absence of Keyless Members
We note the absence of the unlabelled level that we saw
earlier (recall that it contained assembly components for the client’s Products).
The WHERE clause we have examined within the SELECT DISTINCT
statement above explains why the blank level has disappeared: the members of
the blank level no longer exist within the cube, as they have been “passed
over” by the modified SQL statement.
16. Select Product Categories in
the Hierarchy selector atop the Browser tab.
17. Expand All Products within
the hierarchy tree, as we did earlier.
18. Expand Components within
the Category level, as we did in our earlier browse, to arrive at the
results depicted in Illustration 37.
Illustration 37: Product
Categories Hierarchy, Reflecting the Absence of Keyless Members
We note the absence of the unlabelled level, once again,
confirming our understanding of the effect of the WHERE clause within
the modified SQL statement.
In Part II of this article, we will examine the
steps involved in modifying the behavior we have noted thus far, with regard to
the Analysis Server’s default management of Unknown Members.
Conclusion
In this, the first of a two-part article, we embarked upon an
examination of the management of Unknown Members within Analysis
Services. We noted that the Unknown Member property settings offer
us capabilities, similar to those found in once dominant enterprise BI
applications such as Cognos PowerPlay / Transformer, for handling
unmatched dimension keys. The capabilities afforded by the Unknown Member options
allow us to override the processing failure that would occur in these cases of
mismatch, to assign a name other than “Unknown” to the Unknown Member
within each dimension, to control visibility of the Unknown Member, and
more.
In the
first half of our article, we gained some exposure to the default management of
Unknown Members by Analysis Services. Our examination included a discussion surrounding the general concepts and
properties underpinning Unknown Members, including what they define and
support, as well as the mechanics behind their management. We then prepared a
sample Analysis Services database with related objects, and began a hands-on
practice session. We first reviewed Unknown Member properties settings
at the dimension level. Next we created new attributes within the Product
dimension, upon which we based a user-defined hierarchy, and upon which to establish,
in Part II of this article, Unknown Member management within the
supporting properties. Finally, we processed the enhanced Product dimension
and examined the mechanics behind the exclusion of members without
corresponding key values within the underlying data.
»
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
