About the Series …
This
article is a member of the series Introduction to MSSQL Server 2000
Analysis Services. The series is designed to provide hands-on
application of the fundamentals of MS SQL Server 2000 Analysis Services,
with each installment progressively adding features and techniques designed to
meet specific real – world needs. For more information on the series, as well
as the hardware / software requirements to prepare for the exercises we
will undertake, please see my initial article, Creating Our First Cube.
Note: Service Pack 3 updates are assumed for MSSQL Server 2000, MSSQL
Server 2000 Analysis Services, and the related Books Online
and Samples. Images are from a Windows 2003 Server
environment, upon which I have also implemented MS Office 2003, but the
steps performed in the articles, together with the views that result, will be
quite similar within any environment that supports MSSQL Server 2000 and MSSQL Server 2000 Analysis Services ("Analysis
Services" or "MSAS"). The same is generally true,
except where differences are specifically noted, when MS Office 2000 and
above are used in the environment, in cases where MS Office components
are presented in the article.
Overview
Most of the measures
with which we work in our daily Analysis Services environments are additive,
and include various options for easy aggregation, comprised of the
ever-familiar SUM, MAX, MIN and COUNT. Most base
measures involving transactions, such as sales or direct expenses, are
inherently additive. We typically find additive measures simple and useful in
our work within analysis and reporting systems, because there are no inherent
restrictions on how they are used in our cubes. Such measures can be sliced and
diced in any "direction," for example. Using the four aggregation
types to derive aggregates from previously aggregated results is only one
example of how we can easily leverage the power of OLAP as implemented in
MSAS. With additive measures, aggregation is applied consistently to all
dimensions: the measures roll up equally well, within the same aggregation type,
across all.
However, as most of us
are aware, semi-additive measures exist in the business environment, as
well. Periodic measurements, such as account balances (for example, the
daily balance of a bank account), level measurements (such as on-hand inventory
quantities or personnel headcounts), and the like, do not share the qualities
of fully additive measures. Semi-additive measures are additive across some
dimensions within the cubes they inhabit, but are not additive across
one or more of the dimensions of the cube.
As an illustration, an inventory
level might be additive along the Product, Store and Warehouse
dimensions of a cube, but would be non-additive across the Time
dimension of the cube. Alternatively, a daily bank account balance might
certainly be aggregated usefully in an average over Time
(a common case would be an average daily balance), and perhaps in minimum
and maximum contexts, but summing the daily balance over time would
present a meaningless result.
In
this article, we will explore the management of semi-additive measures,
creating a calculated measure (a calculated member that belongs to the Measures
dimension) that is not fully additive, to meet the business requirements
of a hypothetical group of information consumers. Within our exploration of
the semi-additive
measures, we will accomplish the following:
-
Create a copy
of the Warehouse sample cube for use in our practice exercise; -
Prepare the
cube further by processing; -
Perform a
practice exercise, using an illustrative set of business requirements as a
specification for creating a semi-additive measure (a calculated measure)
in our practice cube; -
Explore an
initial approach to creating the simple inventory balance calculated measure,
and explain its shortcomings as a fully additive measure; -
Modify the calculated
measure to cause it to exhibit the appropriate semi-additive behavior; -
Discuss the
results datasets obtained within the steps of our practice example.
