Manage Unknown Members in Analysis Services 2005, Part II

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.

Introduction

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.

William Pearson
William Pearson
Bill has been working with computers since before becoming a "big eight" CPA, after which he carried his growing information systems knowledge into management accounting, internal auditing, and various capacities of controllership. Bill entered the world of databases and financial systems when he became a consultant for CODA-Financials, a U.K. - based software company that hired only CPA's as application consultants to implement and maintain its integrated financial database - one of the most conceptually powerful, even in his current assessment, to have emerged. At CODA Bill deployed financial databases and business intelligence systems for many global clients. Working with SQL Server, Oracle, Sybase and Informix, and focusing on MSSQL Server, Bill created Island Technologies Inc. in 1997, and has developed a large and diverse customer base over the years since. Bill's background as a CPA, Internal Auditor and Management Accountant enable him to provide value to clients as a liaison between Accounting / Finance and Information Services. Moreover, as a Certified Information Technology Professional (CITP) - a Certified Public Accountant recognized for his or her unique ability to provide business insight by leveraging knowledge of information relationships and supporting technologies - Bill offers his clients the CPA's perspective and ability to understand the complicated business implications and risks associated with technology. From this perspective, he helps them to effectively manage information while ensuring the data's reliability, security, accessibility and relevance. Bill has implemented enterprise business intelligence systems over the years for many Fortune 500 companies, focusing his practice (since the advent of MSSQL Server 2000) upon the integrated Microsoft business intelligence solution. He leverages his years of experience with other enterprise OLAP and reporting applications (Cognos, Business Objects, Crystal, and others) in regular conversions of these once-dominant applications to the Microsoft BI stack. Bill believes it is easier to teach technical skills to people with non-technical training than vice-versa, and he constantly seeks ways to graft new technology into the Accounting and Finance arenas. Bill was awarded Microsoft SQL Server MVP in 2009. Hobbies include advanced literature studies and occasional lectures, with recent concentration upon the works of William Faulkner, Henry James, Marcel Proust, James Joyce, Honoré de Balzac, and Charles Dickens. Other long-time interests have included the exploration of generative music sourced from database architecture.

Latest Articles