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