Information Technology Reference
In-Depth Information
requires proficiency in the query preparation — both syntactic and seman-
tic. To expect managers, who may not be able to distinguish between the
various types of indexes or an outer join from an inner join, to handle
all kinds of queries, especially when many an experienced developer has
sometimes gone wrong, is unreasonable. Thus, the adoption of such
interfaces has been limited to simple ad hoc queries.
This difficulty, compounded with the general tendency of users that
they do not have time to “create” reports, often makes report generation
a continued “IT” activity.
In some cases, product manufacturers and their vendors have them-
selves used query interfaces for their convenience. Instead of creating
new reports, which may be cumbersome to do, they have written complex
database queries through these interfaces that end users can run. These
should not be considered replacements for reports.
Queries versus Reports
Queries and reports are different; but because they appear similar, reports
are often treated as query outputs and little else. From the software
person's point of view, they are data retrieval mechanisms. If one has the
query correctly formulated, one has a report. As explained previously, a
report should be goal oriented, formally organized, and more than a query
output on paper or the screen.
Needless to say, reports, as well as most information shown on the
screen, are the result of queries being fired on the database. Is the
difference then in the degree of formality? Is it that a report brings with
it elements of style, format, color, pagination, etc. that are missing in a
database query?
Reports are much more than formatted query dumps and must be
approached that way. The objective of the report is not to get the data
out of the database (data orientation), but to present useful information
to the report reader (user orientation). The operative word is “useful.”
The report creator is expected to go beyond any data model limitations
that the application may be perceived to have. A complex set of queries
may have to be written, intermediate data stores may have to be created,
or new business logic may have to be introduced in the application if the
user needs to see some data that is otherwise not being captured or
computed. A considerable amount of post-processing — such as statistical
analysis, risk and sensitivity analysis, and multi-dimensional scaling —
may be needed on the query data. Useful also implies that the user's need
has been well understood and an appropriate report type chosen. The
report designer must recommend when a trend analysis report is better
