Information Technology Reference
In-Depth Information
The lack of sensible and sufficient data.
The inability to verify that the report is generating the correct
results. Because reports can use complex logic to arrive at their
content, it may not be possible to have a second path to generate
the same results without writing complex SQL or small programs.
In the case of parameter-driven reports, the number of permuta-
tions and combinations that the user can input is enor mous.
Without understanding some business context, one does not know
how to assign priorities to the test cases for reports.
Queries
The industry has been presenting users with query tools to get to the data
that they have spent money in storing. The hope has always been that
the end users will, given the right tool and attitude, create their own
queries, run their own reports, and eliminate a useless load from IT.
Most application vendors provide an interface through which database
queries can be written. Vendors often add a layer on top of the interface
to hide the details of the database schema, cross table joins, and query
language syntax. While these masking layers might be adequate or inad-
equate, sophisticated (natural language interfaces) or not, the problem
lies deeper.
Any software application, simple or complex, has a
under-
lying it. A data model aims to identify the attributes of data elements and
organize the relationships between them, both logically and physically. It
should be based on business rules surrounding the data. Writing mean-
ingful queries requires a very good understanding of the model. Apart
from the formal normalization rules that should be followed in defining
a data model, it is important to keep simplicity in mind. Avoid using
cryptic field names and labels for data elements. Furthermore, one should
understand the business definitions of the concepts underlying the model.
If there is any confusion over definitions such as the “number of employ-
ees” example above, it will be difficult to write queries that fetch the
correct result. For example, if a manager wants to determine how many
widgets were sold on a particular day, one must not only agree on the
definition of a sale, but also on the definition of daily sale (i.e., should
one subtract returns of widgets bought earlier, should one include those
ordered earlier but paid for the day before, etc.). If the definition in the
manager's mental model of the real world — “a sale is when such and
such an event happens” — does not match the designer's model, the
query tool cannot solve this problem. Even if the definitions were aligned,
the actual task of getting values may involve complex processing that
data model
