Databases Reference
In-Depth Information
insist that these conditions be met before you begin work. In any case, be sure to clearly communicate
your concerns and the associated risks.
Solution Scope
Reports often have many dependencies on other parts of a solution and if these pieces aren't in place
before reports are designed, this can hold up the report work and waste considerable time and money.
Reporting solutions require that the right type of database is in place, that it has been populated with all
of the data necessary to build the reports, and that the user and business report requirements are well
defined and documented.
The scope of the solution should be understood before report work begins. Without a clear understand-
ing of all the related components of the solution, the project can easily spin out of control, with more
work being started than finished.
Common examples of solution scope challenges include:
❑
Report performance problems prompt database schema changes or the constructing denormal-
ized fact tables containing duplicate data.
❑
Realizing that changing transactional data doesn't support reporting scenarios, the database is
redesigned while in production.
❑
Database and report features are added as you go and not according to a predefined plan, caus-
ing each report to take on different behavior and features.
The process of periodic data extraction to populate the reporting database system is known as ETL
(Extract, Transform, and Load). A separate data mart or data warehouse is created to store preaggre-
gated decision-support data. A complex ETL process is created to periodically copy new data into the
decision-support database.
Needless to say, if these kinds of issues aren't mitigated and managed, even simple projects may be
doomed before they start. Ideally, a report designer should be on the receiving side of business require-
ments and should participate in helping to clarify the details rather than making up new requirements
as the project moves along.
Reporting on Existing Data Sources
If you are walking into an environment where the databases already exist, you should carefully review
and discuss the long-term viability of the solution with your project sponsor. If this is a small, simple
database that isn't likely to grow significantly over its useful life, then you may be in good shape.
However, small-database reporting solutions that perform well in test and design scenarios may not fare
so well when loaded up with truckloads of data and accessed by many concurrent users.
The system should have a defined capacity and a plan to scale up when you need to support large vol-
umes of data and high workloads.
Reporting on Transactional Sources
In even moderately sized systems, reporting on live data can often be challenging. If user applications
are locking data rows and inserting new records while reports run, this creates resource contention and
Search WWH ::
Custom Search