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
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
samples and tools needed to complete the hands-on portions of this article, see
Optimization in Analysis Services 2005, another article within this
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:
of relevant and accurate information representing business operations and
the rapid and
accurate return of query results;
dice” query creation and modification;
wherein information consumers can pose questions quickly and easily, and achieve
rapid results datasets.
Attributes: Introduction and Overview, Part I, the first of a multi-part
article introducing dimension attributes, we continued our
current subseries focusing upon dimensional model components, with an
objective of discussing the associated concepts, and of providing hands-on
exposure to the properties supporting each. 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 attributes in general.
Having covered the general characteristics and purposes of attributes,
we began our focus upon the properties underlying them, based upon the
examination of a representative attribute within our sample cube. We
discussed the Advanced group of properties, looking forward to subsequent
parts of our introduction and overview of dimension attributes, where we explore the remaining attribute
properties. In this part of our overview of attributes, our examination will include:
of our introduction to dimension attributes from a conceptual
discussion surrounding the general characteristics of attributes;
of the Basic group of attribute properties (including what these properties
define and support, and how we can manage them) underpinning attributes.
Dimensions in Analysis Services: Attributes (continued …)
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 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.)
our introduction in Dimension
Attributes: Introduction and Overview, Part I, we might extend the metaphor we
used earlier in describing dimensions as nouns and measures
as verbs, and 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.
discussed in Part I, 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 conceptual hierarchies of this sort are
common in real-world dimensions.
further discussed in Part I, 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 looking forward to our practice session in Part I, we stated that, 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 got some hands-on exposure to some of these key
values and properties in the practice session – focusing upon
the Advanced properties group of attribute properties
(including what they define and support, and how we can manage them)
underpinning attributes. We will examine, in like manner, the Basic,
Misc, Parent-Child and Source groups of attribute
properties in the practice section of this (where we focus upon the Basic
properties) and subsequent articles. 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.
NOTE: Please access the UDM which we
prepared in Dimensional
Model Components: Dimensions Part I before proceeding with this
article. If you have not completed the preparation to which I refer in the
previous article, or if you cannot locate / access the Analysis Services
database with which we worked there, please consider taking the preparation
steps provided in Dimensional Model
Components: Dimensions Part I before continuing, and prospectively saving the objects
with which you work, so as to avoid the need to repeat the preparation process
we have already undertaken for subsequent related articles within this subseries.
and click, the SQL
Server Business Intelligence Development Studio, as appropriate.
briefly see a splash page that lists the components installed on the PC, and
then Visual Studio .NET 2005 opens at the Start page.
Close the Start
page, if desired.
––> Open from the main menu.
Services Database … from the cascading menu, as depicted in Illustration
Illustration 1: Opening
the Analysis Services Database …
to Database dialog appears.
the Connect to existing database radio button is selected, type the Analysis
Server name into the Server input box atop the dialog.
selector just beneath, labeled Database, select ANSYS065_Basic AS DB,
as shown in Illustration
Selecting the New Basic Analysis Services Database …
settings on the dialog at default, click OK.
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.
Procedure: Examine Further Attribute
Properties in Analysis Services 2005
Having begun an examination of the
properties that define and support a representative attribute in Dimension Attributes: Introduction and Overview, Part I, we focused upon the Advanced group of attribute properties within our
practice session. In the practice procedures that follow, we will examine
the properties that are classified within the Basic group of the
same attribute with which we worked in Part I, namely Geography
Key, one of the attributes
belonging to the Geography dimension.
We will conduct our practice
sessions within the SQL Server Business Intelligence Development Studio,
from which we will perform our examination of attribute properties within
our Analysis Services database, ANSYS065_Basic AS DB. In Dimension Attributes: Introduction and Overview, Part I, we noted that, to
access the properties settings for
attributes within a representative dimension, we needed to open
that dimension within the Dimension Designer first. (Because database
dimensions, and not cube dimensions, contain attributes, we
access properties supporting dimension attributes via the Dimension
Designer, and not the Cube Designer.)
Within the Solution
Explorer, right-click the Geography dimension (expand the Dimensions
folder as necessary).
on the context menu that appears, as depicted in Illustration 3.
3: Opening the Dimension via the Dimension Designer …
tabs of the Dimension Designer open.
Click the Dimension
Structure tab, if we have not already arrived there by default.
We noted in Part
I that five attributes appear
within the Attributes pane of the Dimension
Structure tab. The attributes belonging to
the Geography dimension appear as shown in
4: The Member Attributes, Geography Dimension
will continue our examination of the properties associated with attributes by re-entering the Geography
Key attribute, as before.