Synopsis: Join Business Intelligence Architect Bill Pearson as he kicks off an exploration of Attribute Member Keys, a continuation of a body of articles surrounding significant components of the Analysis Services dimensional model. In this article we introduce Attribute Member Keys, focusing upon the simple keys and their properties.
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 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 Dimensional
Model Components: Dimensions Parts I and II, we introduced the dimensional
model 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
events; -
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.
We
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.
We
discovered in the earlier two 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
hierarchy”. (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.
Within
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 extend our examination of attributes
to yet another important component we have touched upon earlier, the attribute
member key, with which we will 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 this, Part
I of a two-part article, we will gain an introduction to attribute
member keys, with hands-on exposure within a sample cube. Our examination
will include:
-
A discussion
of the three attribute usage types that we can define within each
containing dimension. -
A focus upon
the Key attribute usage type (within both Parts I and II of this article). -
An
introduction to the attribute member key and a discussion of its role in
meeting the primary objectives of business intelligence. -
A discussion
of the role of the attribute member key from a technical perspective,
including its purpose within its containing dimension within Analysis
Services. -
A discussion
of the role of the attribute member key from a technical perspective. -
An
introduction to the concepts of simple and composite keys. -
A review of
the Properties associated with a simple key, based upon the
examination of a representative dimension attribute within our
sample UDM. -
A look ahead
to Part II of this article, where we explore the Properties
associated with a composite key.
