Dimension Attributes: Introduction and Overview, Part I

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 quick and easy questions, and achieve
  rapid results datasets.

In this, the
third of several articles focusing upon dimensional model component
structures as they are implemented within Analysis Services 2005, we
will introduce attributes, another key component. Our examination will
include:

• An
  introduction to dimension attributes from a conceptual perspective;
• Coverage of
  the general characteristics of attributes;
• An examination
  of the Advanced properties (including what they define and support, and
  how we can manage them) underpinning attributes;
• A look ahead
  to Part II of this article, where we explore the Basic, Misc, Parent-Child and
  Source groups of attribute properties.

Dimensions in Analysis Services: Attributes

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 will learn in later articles of this subseries, two types of hierarchies
exist within Analysis Services: attribute hierarchies and user
(sometimes called “multi-level”) hierarchies. For purposes of
our 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.

In
addition to a few key values, several properties (each of which
has, in its own right, multiple possible values) are associated with
each attribute residing in a given model. We will get some hands-on
exposure to these key values and properties 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.

Preparation: Locate and Open the Sample Basic UDM Created Earlier

In
Dimensional Model Components: Dimensions Part I, we created a sample basic UDM within which to perform the steps of
the practice sessions we set out to undertake in the various articles of this
subseries. Once we had ascertained that the new practice database appeared to
be in place, and once we had renamed it to ANSYS065_Basic AS DB, we
began our examination of dimension properties. We will perform our
examination of attributes within the same practice environment, which we
will access using the following steps within the SQL Server Business
Intelligence Development Studio, as we did within Dimensional
Model Components: Dimensions Part I.

We
briefly see a splash page that lists the components installed on the PC, and
then Visual Studio .NET 2005 opens at the Start page.

The Connect
to Database dialog appears.

SQL
Server Business Intelligence Development Studio briefly reads the database from
the Analysis Server, and then we see the Solution Explorer
populated with the database objects. Having overviewed dimension attributes,
we will get some hands-on exposure to properties for an example
attribute, from within our sample UDM.