About the Series …
This
article, Part Two of
Mastering
OLAP Reporting: Meet Business Needs with Matrix Dynamics, is a member of the series MSSQL Server Reporting
Services. The series is designed to introduce MSSQL Server Reporting
Services ("Reporting Services"), with the objective of presenting
an overview of its features, together with tips and techniques for real-world
use. For more information on the series, please see my initial Database Journal article, A New
Paradigm for Enterprise Reporting.
As I
have stated since the charter article of the series, published about the time Reporting
Services was first publicly released, my conviction is that Reporting
Services will commoditize business intelligence, particularly in its role
as a presentation component within an integrated Microsoft BI solution.
Having been impressed from my first exposure to this exciting application, when
it was in early beta, my certainty in its destiny grows stronger by the day, as
I convert formerly dominant enterprise business intelligence systems, such as Cognos,
Business Objects, MicroStrategy, Crystal, and others, to the Reporting Services
architecture. I receive constant requests to conduct strategy sessions about
these conversions with large organizations in a diverse range of industries –
the interest grows daily as awareness of the solution becomes pervasive. Indeed,
the five- to six-plus figures that many can shave from their annual IT budgets
represent a compelling sweetener to examining this incredible toolset.
Note: To follow along with the steps we
undertake within the articles of this series, the following components, samples
and tools are recommended, and should be installed / accessible, according to
the respective documentation that accompanies MSSQL Server 2005:
Server Requirements
-
Microsoft SQL
Server 2005 Reporting Services -
Microsoft SQL
Server 2005 Database Services -
The
AdventureWorks sample databases -
Microsoft SQL
Server 2005 Analysis Services -
The
AdventureWorks OLAP cube
Client Requirements
-
Microsoft
Internet Explorer 6.0 with scripting enabled -
Business
Intelligence Development Studio (optional)
Sample Files
We noted in Part One of this article that we would
be using one of the AdventureWorks sample reports in the practice
sections, to save time and focus for the subject matter of the article. For
more information on the AdventureWorks sample reports, and their
installation, as well as other application and component considerations, please
see Mastering
OLAP Reporting: Meet Business Needs with Matrix Dynamics, Part 1.
About the Mastering OLAP Reporting Articles …
One of
the first things that become clear to "early adopters" of Reporting
Services is that the "knowledgebase" for OLAP reporting with this
tool is, to say the least, sparse. As I stated in my article, Mastering OLAP
Reporting: Cascading Prompts, the
purpose of the Mastering OLAP Reporting subset of my Reporting
Services series is
to focus on techniques for using Reporting Services for OLAP
reporting. In many
cases, which I try to outline in my articles at appropriate junctures, the
functionality of the reporting solutions of well-established, but expensive,
solutions, such as Cognos PowerPlay, can be met in most respects by Reporting
Services – at a tiny fraction of the cost.
The
vacuum of documentation in this arena, to date, represents a serious "undersell"
of Reporting Services, from an OLAP reporting perspective. I
hope to contribute to making this subject matter area more accessible to
everyone, and to share my implementation and conversion experiences as the
series evolves. In the meantime, rest assured that the combined relational and
OLAP reporting potential in Reporting Services will be yet another
reason that the application commoditizes business intelligence.
For
more information about the Mastering OLAP Reporting articles, see
the section entitled "About the Mastering OLAP
Reporting Articles" in my
article Ad Hoc
TopCount and BottomCount Parameters.
Overview
As I have shown in many
past articles, including Part
One of this session, the Microsoft Integrated BI Solution,
consisting of the MSSQL Server 2005 Database Engine, Analysis
Services 2005 and Reporting Services 2005, provides
unprecedented flexibility in helping implementers and developers to meet client
and employer needs. My ongoing conversion of existing enterprise business
intelligence applications to the Microsoft BI solution place me in a rather
unique position to meet diverse needs with features to which my clients have
become accustomed in working within once-dominant business intelligence
applications. Reporting Services is particularly strong in the
flexibility department: Presentation nuances are legion, and one discovers,
with constant use of Reporting Services to meet a wide range of
reporting needs, how truly flexible the application can be.
As I discussed in Part
One, when one is in the business of performing conversions (for
example, converting Cognos PowerPlay or Cognos Impromptu reports
to Reporting Services), and even when implementing an evolving body of
reports for the first time, the foremost challenges that we encounter are those
that arise based upon the need to replicate features that exist in
previously created reports, quite often in tandem with a requirement to
enhance the reports to provide new capabilities and presentation options. Whether as a part of converting the reports of a
predecessor enterprise reporting system, or to meet a need to duplicate early
efforts within Reporting Services itself within enhanced reports that
offer more flexibility, additional features, and so forth (as is the scenario within
the Practice sessions of this article), we will consistently find that Reporting
Services not only allows the knowledgeable designer / developer to exceed
the capabilities of traditional reporting, but affords an environment within
which development can become rapid and "Edison-esque" in its "assembly-line"
nature.
In Part
One, we began
the examination of a scenario
where the dynamic nature of the Reporting Services matrix data region
makes it the "object of choice" for enabling us to meet the expressed
needs of a hypothetical group of information consumers. Part of the
requirement was to replace a somewhat limited data region with a matrix
data region that returned identical data. Creating the new matrix data
region within the same .rdl file as the original matrix data
region upon which it was based afforded us several advantages, both in
rapid development and in ongoing "side-by-side" contrast as we "converted"
the original data region to a new region, from which we could
launch development of the enhancements we examine in this article. Having the
two regions physically parallel made verification of comparability
between them easy, as we finished the first half of our examination by ensuring
that both regions gave us identical results.
In
this article, we will further evolve the matrix, which we have already
determined to be correct as a part of preparation, to meet the less intuitive
components of the business requirements of the information consumers with which
we are working. First, we will add the requested parameterization (with multivalue input
capabilities) that they have requested for Sales Territory Groups, using
a multivalue parameter. Next, we will make further structural changes
to the report, to meet their somewhat innovative business requirements for
presenting independent matrices based upon a geographical parameter
to be selected by the consumers at runtime. As is our tendency throughout the
body of our hands-on articles, we will discuss the results obtained within the development
techniques that we exploit throughout the steps of our practice exercise.
Finally, we will conclude
with a preview of the report to ascertain
the effectiveness of our solution.
In the
foregoing sections, we will continue our examination of a scenario where the
dynamic nature of the matrix helps us to meet the expressed needs of a
hypothetical group of information consumers. In this, the second half of a two-part session, we
will:
-
Add parameterization
(with multivalue input capabilities) for Sales Territory Groups to
the new report, using a multivalue parameter; -
Make structural
changes to the report, to meet the business requirements of a hypothetical
group of information consumers for presenting independent matrices based
upon a geographical parameter they select at runtime; -
Continue to incrementally
preview the report to ascertain the effectiveness of our solution; -
Extend the
ongoing discussion that we began interjecting in Part One, at appropriate junctures, surrounding the results
obtained within the development techniques that we exploit throughout our second
practice session.
