CHAPTER 13 CREATING REPORTS USING REPORT BUILDER 1.0, 2.0, AND 3.0
Getting feedback: Since we have worked alongside developers for many years,
we know that one of the biggest problems with delivering a new application is
that sometimes users get the application and expect it to do more than it does,
or expect it to do something in a different way than delivered. The expectation
from a user’s perspective is that the system should do exactly what the user
needs. But for a developer, if it doesn’t do it in version 1, it will have to do it in
version 2. You can avoid this conflict by implementing standard design
practices, which always take user feedback into consideration up front. This
process is especially important when the same application will be delivered to
different companies with users from different backgrounds, each with their
own interpretations of how a process should work. In the past few decades, a
system analyst would take information from groups of users and translate this
to a technical design that the developer could slowly digest. Today, most system
analysis work is done directly by the developer, who interacts with users during
the design phase of the project. Before we cover how to build a report model to
be used by report designers, we will provide a sampling of some of the feedback
we have received about the kinds of reports users would like to see.Building the report model: The report model is the heart of Report Builder 1.0.
Report models serve as semantic descriptions of the underlying data source.
Because the report model can simplify a potentially complex overall database
schema by selecting individual tables, fields, and values, it can be likened to a
SQL Server view. Indeed, a key component of the report model, as you will see
in this chapter, is a data source view. Once DBAs or developers have created a
report model that contains the data to meet the requirements of the users, they
can publish it to the report server where it can be used by Report Builder 1.0,
which is the client-side report designer. All the data provided to Report Builder
1.0 come from published report models. We will show how to create and
publish models in this chapter based on user feedback.Using Report Builder 1.0: Report Builder 1.0 is one of several design applications
that can be used to create and publish SSRS reports without requiring a full
development environment like Visual Studio or BIDS. Report Builder 1.0 relies
on pre-published report models as its data sources. As you will see, the
interface for Report Builder 1.0 is intuitive; in fact, it is ideal for users who need
to quickly create reports based on predefined report templates. Report Builder
1.0 not only allows users to design reports, but also serves as the publishing tool
to deploy the completed report directly to the report server.When we begin talking about Report Builder 2.0, where users have more control of the data they are
accessing, you’ll see that much of the same concepts that you learned with respect to Report Builder 1.0
still apply. Developers may find themselves still creating views and stored procedures based on feedback
from a user who will ultimately be designing the reports. Likewise, many developers may decide that
Report Builder 2.0 has all of the features they need and will select it as their preferred development
environment.Getting User Feedback
At this point in the book, you have built a report, Employee Service Cost, which breaks down the cost of
health-care visits at several levels. You designed this report using BIDS, and it contains several grouping
levels, interactive sorting, and drill-down functionality. The dataset for this report is a stored procedure