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

How to Model a Data Warehouse
15
When source database schemas are not yet available, ETL development can still
proceed if ETL and OLTP designers can agree on flat file data extracts. Once
OLTP have committed to provide the specified extracts on a schedule to meet BI
needs, ETL transformation and load routines can be developed to match this
source to the proactive data warehouse design target.
Challenges of Proactive Analysis for Data Warehousing
While being proactive has great potential benefits for DW/BI, the late appearance
of data on the Figure 1-6 timeline unfortunately heralds further analysis challenges
for data warehouse designers: BI requirements gathering must take place before
any real data is available. Under these circumstances proactive data modelers can
rely even less upon traditional analysis techniques to provide BI data requirements
to match their aggressive schedule.
Proactive Reporting-Driven Analysis Challenges
Traditional interviewing techniques for gathering reporting requirements are
problematic when stakeholders haven’t seen the data or applications that will fuel
their BI imagination. With no existing reports to work from, business analysts
can’t ask their preferred icebreaker question: “How can your favorite reports be
improved?” and they have nothing to point at if and ask: “How do you use this data
to make decisions?”. Even more open questions such as “What decisions do you
make and what information will help you to make them quicker/better?” can fall
flat when a new operational systems will shortly enable an entirely new business
process that stakeholders have no prior experience of measuring, or managing.
Proactive Data-Driven Analysis Challenges
IT cannot fall back on data-driven analysis: data profiling tools and database
remodeling skills are of little use when new source databases don’t exist, are still
under development, or contain little or no representative data (only test data).
Even when new operational systems are implemented using package applications
with stable, (well) documented database schemas they are often too complicated
for untargeted data profiling: it would take too long and be of little value if only a
small percentage of the database is currently used/populated and well understood
by the available IT resources.
Data then Requirements: a ‘Chicken or the egg’ Conundrum
Before there is data and users have lived with it for a time (with less than perfect BI
access) both IT and business stakeholders cannot define genuine BI requirements
in sufficient detail. Without these early detailed requirements proactive data
warehouse designs routinely fail to provide the right information on time to avoid
a BI backlog building up as soon as data is available. To solve this ‘data then re-
quirements’/‘chicken or the egg’ conundrum, proactive data warehousing needs a
new approach to database analysis and design: not your father’s data modeling, not
even your father’s dimensional modeling!
Proactive analysis
takes place before
data exists
Reporting-driven
analysis is difficult
before data exists
Data-driven analysis
is impossible with
no data to profile
Proactive DW
design requires a
new approach to
data analysis,
modeling and
design