Databases Reference
In-Depth Information
In addition to using real data, it's important to work with a manageable set of data so reports run quickly.
Large data volumes can slow report design significantly. To design a bug-free report typically takes sev-
eral iterations of testing after adding each feature. If it takes several minutes to render a report, this can
slow the process by hours and days. When it takes a long time to test a report, I often find myself trying
to use this downtime more effectively by working on other tasks. In the end, I find myself starting (more
than finishing) multiple things on a slow-running machine. It's tough to keep track of all the loose ends,
especially when queries are timing out and reports are crashing with errors.
Report Specifications
Work with your users and project sponsor to design a report specification template that addresses your
unique business needs. Some reports may query data from multiple tables and users may not be familiar
enough with the data structures to specify column names and keys for joins. In this case, you may need to
involve a database expert to help with these requirements. Other reports may get their data from existing
views or stored procedures, making this part of the process a whole lot easier.
I find that in some cases, where the project sponsor and users aren't familiar with the data structures, I am
left to make assumptions about how the tables should be joined and queried. In these cases, the report
specification becomes more of a checklist and a forum to validate assumptions and to answer questions.
Ultimately, the burden must be left to the project sponsor to provide and approve the specific requirements
for each report. This, of course, should be performed with the assistance and cooperation of the report
designer as you discuss each feature. Remember that the key to success is effective communication. On
larger projects or when reporting on more complex databases, you may need to separate the business
requirements of the report from the technical specification, perhaps by using two separate documents to
gather these requirements. In any case, the key is to involve users and business stakeholders in obtaining
buy-off and validating the results.
The following sample report specification should work for most report projects and can be embellished
for special needs. Replace the italicized text with appropriate responses and complete one complete copy
for each report.
Report Specification for Description
(Full Report Name)
Report Category or Group
(Reports are often grouped by business function, features, or user
audience.)
Priority
(1 = High, 2 = Medium, 3 = Low)
Business Problems/Questions
Answered
Data Source
[Database, table(s), stored proc., cube, etc.]
Fields
Schema Field Name
Column Title
Format
(Table columns and cube dimension
(Actual table column
(Report column
(Currency, percent,
members and measures are collectively
or member name)
heading title)
date — short/long,
called fields in Reporting Services. List
decimal places, etc.)
all fields by name with the related
report column title and data format.)
Table continued on following page
Search WWH ::
Custom Search