Mastering OLAP Reporting: Meet Business Needs with Matrix Dynamics, Part 1
February 21, 2006
About the Series ...
This article 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 will be using one of the AdventureWorks sample reports in the practice section, to save time and focus for the subject matter of the article. The AdventureWorks sample reports are a set of prefabricated report definition files that use the AdventureWorks databases (both relational and Analysis Services) as data sources. The sample reports are highly useful to many new report authors and other practitioners, for whom they serve as a tool to assist in learning the capabilities of Reporting Services, as well as templates for designing new reports. For this reason, we typically make a copy of any report(s) we modify within our lessons.
The samples are not automatically installed. Before we can install the Reporting Services samples, we must have already copied the sample installation program to the PC with which we are working, in accordance with the instructions found in the SQL Server 2005 Books Online and elsewhere. We then run the sample installation program to extract and copy the reports (and other) samples to the computer. The sample installation program also installs the AdventureWorks databases (both Database Engine and Analysis Services varieties)..
The samples come packaged within a Report Server project file, which we will open and use in many lessons, rather than creating a new project file. Please make sure that the samples and the project file are installed before beginning the practice section of this article, so as to provide an environment in which to complete the exercises effectively.
Note: Current Service Pack updates are assumed for the operating system, along with the applications and components listed above and the related Books Online and Samples. Images are from a Windows 2003 Server environment, but the steps performed in the articles, together with the views that result, will be quite similar within any environment that supports MSSQL Server 2005 and its component applications.
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 arena more accessible to everyone, and to share my implementation and conversion experiences as the series evolves. In the meantime, rest assured that the OLAP 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, 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. As I convert existing enterprise business intelligence to the Microsoft BI solution, I come across opportunities to meet diverse needs on a virtually daily basis. 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.
Foremost in the challenges that I find in the field are those that arise based upon the need to replicate features that exist in previously created reports, often in tandem with a requirement to enhance the reports to provide new capabilities and presentation options. These replication efforts often come as a part of converting the reports of a predecessor enterprise reporting system (for example, converting Cognos PowerPlay or Cognos Impromptu reports to Reporting Services). They also come about through a need to duplicate early efforts within Reporting Services itself into enhanced reports that offer more flexibility, additional features, and so forth, to information consumers, as we do within the Practice session of this article.
As most who have worked with Reporting Services know, authoring reports in the application consists largely of associating controls within the report body with fields that are created within one or more DataSets within the report file (.rdl). Sometimes we can associate controls with other controls to achieve results that might otherwise be difficult. One of my favorite controls in Reporting Services, for OLAP reporting in general, and for its synergistic qualities when working with other objects within Reporting Services, is the matrix data region.
One certainly finds that the table data region seems the clear favorite, among the few Reporting Services books on the market as of this writing. This is perhaps because the table data region closely resembles the functionality found in the those (largely) relational reporting applications that were dominant before Reporting Services appeared. Indeed, the vast majority of current writing continues to surround relational reporting (see my comments in the About the Mastering OLAP Reporting Articles ... section above), mostly because the majority of the current Reporting Services writers have previously written books on the relational enterprise reporting tools to which I refer, and have adapted much of their teaching approach with those applications to Reporting Services. Even among the sample reports that ship with MSSQL Server 2005 Reporting Services, one finds the vast majority to surround relational reporting of this sort.
Among many attributes that I like within the matrix data region, is the fact that its rows and columns can be dynamic, unlike those of a table data region, which are static. We can define matrices with either or both of static and dynamic rows and columns, and thereby support meeting business requirements in many environments where static columns and rows might limit consumers. When we couple the capability for dynamic columns with the behavior we can obtain when nesting other data regions within the matrix, we begin to see how we can produce a far more robust presentation for our employers and clients.
In this article, we will examine a scenario where the dynamic nature of the matrix helps us to meet the expressed needs of a hypothetical group of information consumers, both directly and (to some extent, a bit less intuitively) from a more indirect perspective. In this two-part session, we will: