Mastering OLAP Reporting: Meet Business Needs with Matrix Dynamics, Part II
March 20, 2006
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:
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.
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: