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 portion of this article, see Usage-Based Optimization in Analysis Services 2005, another article within this
series.
About the Mastering Enterprise BI Articles…
The purpose of the Mastering
Enterprise BI subset of my Introduction to
MSSQL Server Analysis Services series is to focus on techniques for implementing features in Analysis
Services that parallel – or outstrip – those found in the more “mature”
enterprise OLAP packages. In
many cases, which I try to outline in my articles at appropriate junctures, the
functionality of the OLAP solutions within well-established, but expensive,
packages, such as Cognos PowerPlay Transformer and Cognos PowerPlay,
can be met – often exceeded – in most respects by the Analysis Services /
Reporting Services combination – at a tiny fraction of the cost.
The
vacuum of documentation comparing components of the integrated Microsoft BI
solution to their counterparts among other enterprise BI vendors, to date,
represents a serious “undersell” of both Analysis Services and Reporting
Services, particularly from an OLAP reporting perspective. I hope, within
the context of the Mastering Enterprise BI articles, to demonstrate that
the ease of replicating popular enterprise BI features in Analysis Services
will be yet another reason that the integrated Microsoft solution will
commoditize business intelligence.
For
more information about the
Mastering Enterprise BI articles, see the section entitled “About the Mastering Enterprise BI
Articles” in my article Relative
Time Periods in an Analysis Services Cube, Part I.
Introduction
As I stated in my article
Introduction to SQL Server 2000 Analysis Services:
Handling Time Dimensions, it is a rare thing to
encounter an instance of an OLAP cube that does not require a Time dimension.
Throughout years of business intelligence consulting, I have only witnessed
this scenario a handful of times within a production environment. Although
there often seems to be no shortage of people to argue any side of any
statement, few of us would disagree that the measurement of activity over
time – and, hence, the Time dimension that supports this capability
– is important to both analysis and operational management in general.
As an aside, I refer to
the dimension as a “Time” dimension because my preference is to name
dimensions after the generic concepts they represent – thus “time”
versus “date.” While I can certainly live with “date” as the name of the
dimension that represents the concept of time, I do not agree with the argument
advanced by some that “date” is the more appropriate choice because, after all,
we are working with “date” hierarchies that may not subanalyze to “time” – as
in “time of day.” My response is that “date” itself is a subordinate member
within the larger concept of time, and typically a level within the Time
dimension, hence my choice of “Time” as a dimension name.
(I hope that not too
much angst is aroused by Microsoft’s decision to use terms like “time
intelligence,” “server time dimension,” “time periods,” and the like,
throughout Analysis Services and its documentation, for those who might confuse
time to mean “time of day …”. Moreover, I heartily encourage substituting
“date” for “time” as a dimension name when the latter leads to undue stress,
justified or not. This is one of the beauties of working within semantic
layers…)
The Time dimension
has several unique characteristics, relative to other dimensions within our
cube models. Among these is the fact that all businesses employ the same core calendar
time hierarchy of days (and sometimes lower levels), weeks, and months,
together with quarters and years (with various subdivisions included to meet
local business and reporting needs) – even though treatment of these various
levels can vary widely within the alternative considerations of fiscal
years and periods. Moreover, the pervasive nature of time – within and
surrounding all organizational activity – means the universal juxtaposition of
the Time dimension and the other dimensions within our cube models.
Another characteristic of time is its incremental continuation, like a
ray in geometry, from a fixed beginning to a typically indefinite end.
The Time dimension
has received special focus within the design of enterprise business
intelligence applications. Common features include capabilities ranging from
the recognition of date fields with minimal intervention to the automatic
generation of members of the Calendar time dimension as a part of cube design
and / or creation. Most of the dominant applications have even offered support
for the dynamic creation of various “relative” time periods and aggregations. (For
a discussion of some of the specific support provided by leading applications,
as well as the Analysis Services 2005 approach to meeting and exceeding
these features, see other articles within my Introduction
to SQL Server 2000 Analysis Services series here at Database
Journal).
As we
shall see in this article and its successor, Analysis Services 2005 witnesses
further enhancements with regard to supporting the Time dimension.
Moreover, in addition to these extended features, support for the creation of
virtually any “custom” relative time aggregation that we might need remains
readily available to assist developers. In this article, we will gain some
familiarity with creating a Time dimension within Analysis
Services 2005, focusing upon enhanced features as we encounter them. In
Part II, we will examine new features that support the easy addition of Time
intelligence within our cube models. Our examination of working with the Time
dimension within Analysis Services 2005 includes:
-
An introductory
discussion of the Time dimension, focusing on unique characteristics that distinguish it from other
dimensions within our cube models; -
Mention of the
special focus that has been given to the Time dimension within the
design of enterprise business intelligence applications, and features that
have been added to the applications to provide an “assist” with the Time
dimension as a part of cube design and / or creation; -
A look ahead
to our sequel article, wherein we discuss the support, offered by most of the
recently-dominant applications for the dynamic creation of various “relative”
time periods and aggregations, and how this support has been enhanced in Analysis
Services 2005; -
Creation of a
new Analysis Services Project in preparation of our practice session; -
Creation of a target
database within SQL Server Management Studio for the schema
generation procedure within our practice session; -
Ascertaining connectivity
of the relational data source, along with other preparatory procedures,
within the new Analysis Services 2005 Project; -
Creation of a rudimentary
cube, via the “top down” approach (whereby no underlying data source is in
place), containing a Time dimension, upon which to base our general
examination; -
Examination of
the structure of the new Time dimension; -
Generation of
the underlying schema for the new cube
model, including the generation of a Time table design, as well
as its subsequent population, from within the cube model that it is designed to
support; -
Review of the new
Date dimension within the Designer; and -
Review of the generated
schema, and the populated table supporting the Date dimension, within SQL
Server Management Studio.