Attribute Member Keys – Pt II: Composite Keys

About the Series …

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 Analysis Services (“Analysis
”), 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


In Dimensional Model Components: Dimensions Parts I and II, we introduced the dimensional
in general, noting its wide acceptance as the preferred structure for
presenting quantitative and other organizational data to information
consumers. We then began our examination of dimensions, the analytical “perspectives”
upon which the dimensional model relies in meeting the primary
objectives of business intelligence, including its capacity to support:

  • the presentation
    of relevant and accurate information representing business operations and
  • the rapid and
    accurate return of query results;
  • “slice and
    dice” query creation and modification;
  • an environment
    wherein information consumers can pose questions quickly and easily, and achieve
    rapid results datasets.

learned, in Dimensional Model Components:
Dimensions Parts I
and II, that dimensions form the
foundation of the dimensional model. They represent the perspectives
of a business or other operation, and reflect the intuitive ways that
information consumers need to query and view data. We noted that we might
consider dimensions as nouns that take part in, or are otherwise
associated with, the verbs (or actions / transactions undertaken by the
business) that are represented by the facts or measures contained
within our business intelligence systems.

discovered in earlier articles that, within the Analysis Services model,
database dimensions underlie all other dimensions, whose added
properties distinguish them from the database dimensions they reference,
within the model. Each dimension within our model contains one or more hierarchies.
As we learn in other articles of this series, two types of hierarchies
exist within Analysis Services: attribute hierarchies and user
(sometimes called “multi-level”) hierarchies. For purposes of
this article, the term “attribute” means the same thing as “attribute
”. (We will examine user hierarchies, to which we will
simply refer as “hierarchies,” in a subsequent article.)

To extend
the metaphor we used earlier in describing dimensions as nouns
and measures as verbs, we might consider attributes as
somewhat similar to adjectives. That is, attributes help us to
define with specificity what dimensions cannot define by themselves. Dimensions
alone are like lines in geometry: they don’t define “area” within
multidimensional space, nor do they themselves even define the hierarchies
that they contain. A database dimension is a collection of related
objects called attributes, which we use to specify the coordinates
required to define cube space.

the table underlying a given dimension (assuming a more-or-less typical
star schema database) are individual rows supporting each of the members
of the associated dimension. Each row contains the set of attributes
that identify, describe, and otherwise define and classify the member
upon whose row they reside. For instance, a member of the Patient
dimension, within the Analysis Services implementation for a healthcare
provider, might contain information such as patient name, patient ID, gender,
age group, race, and other attributes. Some of these attributes
might relate to each other hierarchically, and, as we shall see in subsequent
articles of this subseries (as well as within other of my articles), multiple
hierarchies of this sort are common in real-world dimensions.

Dimensions and dimension attributes
should support the way that management and information consumers of a given
organization describe the events and results of its business operations.
Because we maintain dimension and related attribute information
within the database underlying our Analysis Services implementation, we
can support business intelligence for our clients and employers even when these
details are not captured within the system where transaction processing takes
place. Within the analysis and reporting capabilities we supply in this manner,
dimensions and attributes are useful for aggregation, filtering,
labeling, and other purposes.

Having covered the general characteristics and purposes of attributes
in Dimensional Attributes: Introduction and Overview Parts I through V, we fixed our focus upon the properties underlying
them, based upon the examination of a representative attribute within
our sample cube. In this article, we will continue our extended examination of
attributes to yet another important component we have touched upon earlier,
the attribute member key, with which we will continue to get some
hands-on exposure in the practice session below. Before we get started
working within a sample cube clone, we will need to prepare the local
environment for the practice session. We will take steps to accomplish this
within the section that follows.

In Part I of this article, we introduced Attribute Member Keys, continuing our recent group of
articles focusing upon dimensional model components, with an objective
of discussing the associated concepts, and of providing hands-on exposure to
the properties supporting them. We reviewed our initial introduction to
the dimensional model and summarized its role in meeting the primary
objectives of business intelligence. Next, we provided a brief overview of dimension
in general, referencing a subseries of articles, within my Introduction to MSSQL Server Analysis Services series, where we explore the properties
underlying them in detail.

As a part of our exploration of Attribute Member Keys,
we first discussed the three Attribute usage types that we can define
within a containing dimension. We then narrowed our focus to the Key
usage type (a focus that we develop throughout Parts I
and II of this article), discussing its role in meeting our
business intelligence needs. We next followed with a discussion of the role of
the Key attribute from a technical perspective, including its purpose
within a containing dimension within Analysis Services.

We then introduced the concepts of simple and composite
, narrowing our exploration in Part I
to the former. We
reviewed the Properties associated with a simple key, based upon
the examination of a representative dimension attribute, Geography,
within our sample UDM. Finally, we looked ahead to this, the second
half of the article, where we will explore the Properties associated
with a composite key, and gain hands-on exposure within a sample cube.
Our examination will include:

  • A review of
    the three attribute usage types that we can define within each
    containing dimension.
  • A review of
    the nature of the attribute member key and its role in meeting the
    primary objectives of business intelligence.
  • A review of
    the role of the attribute member key from a technical perspective,
    including its purpose within its containing dimension within Analysis
  • A discussion
    of the differences between simple and composite keys, and an
    explanation as to why composite keys are sometimes required to uniquely
    identify attribute members.
  • A review of the
    Properties associated with a composite key, based upon the
    examination of a representative dimension attribute within our
    sample UDM.
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.

Get the Free Newsletter!

Subscribe to Cloud Insider for top news, trends & analysis

Latest Articles