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 / Crystal, MicroStrategy, Hyperion, 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
Sample Files
For purposes of the
practice exercises within this series, we will be working with samples that are
provided with MSSQL Server 2005. The samples with which we are
concerned include, predominantly, the Adventure Works DW database. This
database and companion samples are not installed by default in MSSQL Server
2005. The samples can be installed during Setup, or at any time
after MSSQL Server has been installed.
The topics "Running
Setup to Install AdventureWorks Sample Databases and Samples" in SQL
Server Setup Help or "Installing AdventureWorks Sample Databases and
Samples" in
the Books Online (both of which are included on the installation CD(s), and
are available from www.Microsoft.com and other sources, as well),
provide guidance on samples installation. Important information regarding the
rights / privileges required to accomplish samples installation, as well as to
access the samples once installed, is included in these references.
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 BlackBelt Articles ...
As we
have stated in earlier BlackBelt articles, one of the greatest
challenges in writing tutorial / procedural articles is creating each article
to be a freestanding document that is complete unto itself. This is important,
because it means that readers can complete the lesson without reference to
previous articles or access to objects created elsewhere. When our objective
is the coverage of a specific technique surrounding one or more components of a
report, a given administrative function surrounding all reports, and other
scenarios where the focus of the session is not the creation of reports,
per se, challenges can arise because a report or reports often has to be in
place before we can begin to cover the material with which the article concerns
itself.
The BlackBelt
articles represent an attempt to minimize the setup required in simply getting
to a point within an article where we can actually perform hands-on practice
with the component(s) under consideration. We will attempt to use existing
report samples or other "prefabricated" objects that either come
along as part of the installation of the applications involved, or that are
readily accessible to virtually any organization that has installed the
application. While we will often have to make modifications to the samples
involved (we will actually create a copy, to allow the original sample to
remain intact), to refine it to provide the backdrop we need to proceed with
the object or procedure upon which we wish to concentrate, we will still save a
great deal of time and distraction in getting to our objective. In some cases,
we will still have to start from scratch with preparation, but my intention
with the BlackBelt articles will be to avoid this, if at all
possible.
For
more information about the BlackBelt articles, see the section
entitled "About the BlackBelt Articles" in BlackBelt
Components: Manage Nulls in OLAP Reports.
Overview
As I have discussed in many
past articles, ad hoc reporting capabilities are highly valued by
information consumers. While we have, up until this article, focused on adding
interactive features, such as parameterization, and ad hoc sorting and other
conditional formatting features in the reports we develop within Reporting
Services, one feature of Reporting Services 2005 is bound to meet
with popularity among administrators, as well as among analysts and other
information consumers: the Report Builder.
Report Builder provides a means for consumers to
explore and find information without having to understand the underlying data
source structures. Report Builder is fully integrated with SQL Server
Reporting Services and delivers ad hoc reporting support quite similar to
that found in Cognos Query, among other enterprise reporting offerings.
Because it uses familiar Microsoft Office paradigms, the learning curve
for using Report Builder is relatively minimal. In effect, end users
leverage a report layout template that contains predefined data regions,
in combination with the Report Model, which contains report items
such as data fields, which are ideally designed into the model based
upon business requirements gathering. The users drag and drop the report
items onto the data regions within the template, apply filters, and
so forth to refine the eventual report display to fit their needs.
Consumers can create new
fields / calculations based on the data in the Report Model, and
preview, print, and publish their reports. They can also export them to Microsoft
Office Excel and several other formats - retaining formatting, etc., in a
way I have yet to see even approximated within the export capabilities of Cognos,
or other enterprise applications.
Report Builder can also be used in an "Explorer"
mode, whereby consumers can interactively browse the related data within the Report
Model. In this mode, Report Builder generates "clickthrough
reports" automatically, allowing consumers to follow navigation paths that
exist within the Report Model. As long as a relationship exists from a
given "current position," consumers can continue to click through.
Clicking through triggers the automatic generation of queries (information is
passed about the data items the consumer is placing in the report) based upon
the "context" of the location of the data that the user selects to
use in the report.
Because Report Builder
reports are saved as RDL, they can be opened and modified using the advanced
programming capabilities in Reporting Services' Report Designer, if
required, and Report Builder reports are managed, secured, and delivered
using the same methods and APIs used to manage, secure, and deliver other Reporting
Services reports. It is easy to control who can use or access a given
report, and, if Reporting Services' role-based security is implemented
correctly, we can effectively manage who can create and edit reports in Report
Builder (we can create customized roles for other considerations).
In this article, we will focus largely upon the design and
creation of the Report Model. We will concentrate on the use of the Report
Builder from the consumer perspective in articles where we focus
specifically within that context. It is in those articles that we will focus
upon end user access and use, including report creation and publication using
the tool. Our purpose in this session will be to get some hands-on exposure to
the creation of a Report Model. As a part of our examination of the steps involved, we will:
-
Create a new Report Model
Project within the Business Intelligence Development Studio;
-
Define a Data
Source containing the information Report Builder needs to connect to
a database;
-
Create a Data
Source View containing schema information upon which we will base the Report
Model;
-
Define the Report
Model within the Report Model Project;
-
Publish the Report
Model to make it available to select information consumers;
-
Discuss, at
appropriate junctures, the results obtained within the development techniques
that we exploit throughout our practice session.
» 
Comment and Contribute
