Manage Unknown Members in Analysis Services 2005, Part II

December 14, 2007

About the Series ...

This article is a member of the series Introduction to MSSQL Server Analysis Services. The series is designed to provide hands-on application of the fundamentals of MS SQL Server 2005 Analysis Services (“Analysis Services”), with each installment progressively presenting features and techniques designed to meet specific real-world needs. For more information on the series, please see my initial article, Creating Our First Cube. For the software components, samples and tools needed to complete the hands-on portions of this article see Usage-Based Optimization in Analysis Services 2005, another article within this series.


In Manage Unknown Members in Analysis Services 2005, Part I, we introduced our topic with discussion surrounding the fact that, when Analysis Services processes dimensions within a cube, it attempts to match each dimension key in the fact table with a corresponding dimension member in the dimension table to which it is joined. We discussed cases where we might expect to encounter a dimension key existing within the fact table with no matching key in the dimension table – examples include prototyping and other developmental scenarios, and sometimes after recurring ETL updates and other evolutions. We mentioned that Analysis Services employs the concept of an Unknown Member to define such unmatched dimension members, and then began our hands-on exploration of the management of the Unknown Member within Analysis Services.

Through discussion and hands-on procedures, we learned that the Unknown Member settings offer us capabilities, similar to those found in once dominant enterprise BI applications such as Cognos PowerPlay / Transformer, for handling scenarios involving unmatched dimension keys such as we have described. The capabilities afforded by the Unknown Member options allow us to override the processing failure that would occur in these cases of mismatch, as well is to assign a name other than “Unknown” to Unknown Members within each dimension, to control visibility of Unknown Members, and more.

Our Part I, we introduced the general concepts and properties underpinning Unknown Members, including what they define and support, as well as the mechanics that lie behind their management. After we had prepared a sample Analysis Services database and its constituent objects, with which to complete a hands-on practice session, we performed a review of Unknown Member properties settings at the dimension level. We then created new attributes within the Product dimension of our sample cube, upon which our stated objective was to establish Unknown Member management within the supporting properties.

In Part II, we will continue to gain an introduction and hands-on exposure to managing Unknown Members within our sample cube. We will resume our procedures with the sample cube that we created in Part I. Our continuing examination will include:

  • Coverage, where appropriate, of the general concepts and properties (including what they define and support, and how we can manage them) underpinning Unknown Members.
  • The establishment of Unknown Member management within the associated supporting properties for the Product dimension attributes that we added to the sample cube in the first half of our article.
  • Processing the enhanced Product dimension, and examining the mechanics behind the default, physical removal of members without corresponding key values within the underlying data.
  • Ongoing discussion of other considerations that surround our management of Unknown Members.

Manage Unknown Members in Analysis Services 2005

To briefly summarize what we learned in Manage Unknown Members in Analysis Services 2005, Part I, when Analysis Services meets with a null value within the underlying data from which it is attempting to populate a dimension’s attributes, its default reaction is to convert the null to an empty string (for string columns) or to a zero (for numeric columns). Also by default, the Analysis Server ignores the error generated by this condition, allowing processing to continue uninterrupted, removing the attribute member associated with the null through the action of the inner join performed between the tables involved. We learned that, while these default settings are made for us when we use the Dimension and Cube Wizards in constructing our dimensions, based upon a couple of conditions, we can also work with certain properties to bring about different treatment of Unknown Members within our own environments.

We discussed three property settings that dictate how the Analysis Server handles any such null values it encounters in the underlying data. The first two properties, related to the dimension itself, are UnknownMember and UnknownMemberName. (We performed an examination of these properties in our practice session in Part I.) The third property, related to the dimension's key attribute, is the NullProcessing property. The wizards set the defaults, based upon the nullability of the items we mention above, to UnknownMember for the NullProcessing property of the key attribute, Visible for the UnknownMember property, and a simple “Unknown” (which we can easily change, as we shall see, to a name more appropriate for our own environments) for the UnknownMemberName property. While a fourth property, NullKeyCovertedToUnknown, is certainly relevant to our coverage of Unknown Members, its purpose is to direct the Analysis Server in how it handles the error generated when it encounters null-valued attribute members (by default, the property is set to IgnoreError, which, as we noted earlier, directs Analysis Services to remove the offending attribute member entirely, and to continue processing).

We noted that, when we use the Dimension Designer to define a dimension (versus the wizards), and then add this dimension to our cube, or when we construct dimensions incrementally, we find that we may need to set some of the properties manually. Because this is the case, we stated in Part I that we would focus upon a selected dimension within this context in the practice sessions of both halves of this article. By taking this approach, we reasoned that we could concentrate on the properties directly (and a bit more efficiently), rather than walking through the steps of the wizard to define a dimension, and then returning to the individual settings to examine and modify them.

To summarize the general steps, once again, we direct the Analysis Server in how to manage “orphan” attribute members by enabling the UnknownMember property for the dimension, and by specifying a value for the UnknownMemberName property for the dimension (unless the default value of “Unknown” is adequate within the local environment). Other actions we might take surrounding “orphan management,” as we shall see, include setting attribute relationships to link dimension attributes appropriately, and defining custom error handling for the key column used as a basis for the joins between the fact / dimension tables supporting the dimensional structure in general.

We will continue these steps and others within the practice session that we undertake in this article.

The Network for Technology Professionals



Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers