My first Publication Agile-Data-Warehouse-Design-eBook | Page 34

How to Model a Data Warehouse
13
future information needs beyond the ‘next reports’, because these needs are de-
pendent upon the answers the ‘next reports’ will provide, and the unexpected new
business initiatives those answers will trigger. The ensuing steps of collating re-
quirements, feeding them back to business stakeholders, gaining consensus on data
terms, and obtaining sign off can also be an extremely lengthy process.
Over-reliance on reporting requirements has lead to many initially successful data
warehouse designs that fail to handle change in the longer-term. This typically
occurs when inexperienced dimensional modelers produce designs that match the
current report requests too closely, rather than treating these reports as clues to
discovering the underlying business processes that should be modeled in greater
detail to provide true BI flexibility. The problem is often exasperated by initial
requirement analysis taking so long that there isn’t the budget or willpower to
swiftly iterate and discover the real BI requirements as they evolve. The resulting
inflexible designs have led some industry pundits to unfairly brand dimensional
modeling as too report-centric, suitable at the data mart level for satisfying the
current reporting needs of individual departments, but unsuitable for enterprise
data warehouse design. This is sadly misleading because dimensional modeling has
no such limitation when used correctly to iteratively and incrementally model
atomic-level detailed business processes rather than reverse engineer summary
report requests.
Focusing too closely
on current reports
alone leads to
inflexible
dimensional models
Proactive DW/BI Analysis and Design
Historically, data warehousing has lagged behind OLTP development (in technol-
ogy as well as chronology). Data warehouses were built often long after well estab-
lished operational systems were found to be inadequate for reporting purposes,
and significant BI backlogs had built up. This reactive approach is illustrated on the
example timeline in Figure 1-5.
Early DWs were
reactive to OLTP
reporting problems
Figure 1-5
Reactive DW
timeline
Today, DW/BI has caught up and become proactive. The two different worlds of
OLTP and DW/BI have become parallel worlds where many new data warehouses
need to go live/be developed concurrently with their new operational source
systems, as shown on the Figure 1-6 timeline.
The lag between
OLTP and DW roll-
out is disappearing