Question

A little background here:

I know what a data warehouse is, more or less. I’ve read several dozen guides on data warehousing, I’ve played with SSAS, I know what a star schema and a dimension table and a fact table is, I know what ETL is and how to do it. This is not a “how” question or a request for tutorials.

My issue is that all of the material I’ve read on data warehousing seems to gloss over the rationale for building a data warehouse. They all figuratively, or in some cases literally start with the phrase “so you’ve decided to build a data warehouse…” Except I haven’t made that decision yet.

So I’m hoping that SO members can point me to, or help come up with, some kind of semi-objective test. Something that I can adapt to a particular system and end up with either “yep, we need a data warehouse” or “no, the payoff today would be too small.” I think that the specific questions I should be able to answer are:

1. At what point is building a data warehouse an option worth considering? In other words, what telltale signs, metrics, or other criteria should I be looking out for that might indicate that a standard transactional environment is no longer sufficient?

2. What are the alternatives to a full-on data warehouse? Denormalization in the transactional database and the bog-standard replicated “report server” are two that come to mind; are there any others I should explore before committing to the DW?

3. Why is a data warehouse better than said alternatives? If the answer is, “it depends”, then what does it depend on?

4. When shouldn’t I attempt to build a data warehouse? I’m skeptical of anything declared as a “best practice” irrespective of context. Surely there must be some scenarios where a DW is the wrong choice – what are they?

5. Are there any practical examples I could look at of systems that were improved by introducing a data warehouse? Something that would explain to me, end-to-end, what sorts of decisions or analysis they needed the warehouse for, how they decided what to put in it, and how the warehouse ended up fitting into the larger environment? I don’t want a contrived “let’s make a cube out of the AdventureWorks database” – the implementation is irrelevant to me, I’m interested in the specifications and designs and overall thought process that were involved.

I generally try not to ask multi-parters but I think that these are all very closely-related. I’m willing to accept any answer that addresses at least the first 4 questions, although the last would really help to crystallize this in my mind. Links are fine if somebody’s already written about this, as long as they’re reasonably concise and specific (link to Ralph Kimball’s home page = not helpful).

Hope I’ve made the question clear – thanks in advance for your answers!

Answer 1

I’ll see if I can do my best to answer your questions succinctly.

1.At what point is building a data warehouse an option worth considering?
In other words, what telltale signs,
metrics, or other criteria should I be
looking out for that might indicate
that a standard transactional
environment is no longer sufficient?

a. If you find that reporting and monitoring are impairing the performance of your production system and/or an offline data store.

b. If you find that getting answers to your business questions requires building a lot of complex SQL each time.

c. If you find that every time you make a change to your transactional schema, you have to go back and rework all of your reporting queries.

d. If you want to bring together data from multiple sources.

2.What are the alternatives to a full-on data warehouse?
Denormalization in the transactional
database and the bog-standard
replicated “report server” are two
that come to mind; are there any
others I should explore before
committing to the DW?

3.Why is a data warehouse better than said alternatives? If the answer is,
“it depends”, then what does it depend
on?

I’ll answer these together. I wouldn’t think of a data warehouse as an all or nothing venture. It’s simply a concise phrase that means “storing your data in a way that allows you to more easily and quickly answer business questions.”

Transactional databases are designed to efficiently interface with applications. Data warehouses, data marts, operational data stores and reporting tables are built to efficiently interface with people, if that makes sense.

4.When shouldn’t I attempt to build a data warehouse? I’m skeptical of
anything declared as a “best practice”
irrespective of context. Surely there
must be some scenarios where a DW is
the wrong choice – what are they?

Good question. If your transactional system provides you with sufficient insight into your business, you probably do not have a need for warehousing.

If you only have one source of data and performance is not a problem, you can probably gain insight from creation of simple reporting tables.

5.Are there any practical examples I could look at of systems that were
improved by introducing a data
warehouse? Something that would
explain to me, end-to-end, what sorts
of decisions or analysis they needed
the warehouse for, how they decided
what to put in it, and how the
warehouse ended up fitting into the
larger environment? I don’t want a
contrived “let’s make a cube out of
the AdventureWorks database” – the
implementation is irrelevant to me,
I’m interested in the specifications
and designs and overall thought
process that were involved.

That’s a big question that would take far more space than I’m allotted here.

On this one, I can point you to a few places that might provide the insight you seek.

• “Implementing A Data Warehouse: A Methodology that worked” by Bruce Ullrey is a book documenting one man’s journey to building a data warehouse. It’s not highly polished, which gives it more realism. It reads like a journal with lots of models and other visuals that illustrate his efforts pretty well.
• “Business Intelligence Roadmap” by Larissa Moss. Standard fare. Walks you through the process of building a BI practice at a high level.
• “The Profit Impact of Business Intelligence” by Steve Williams gives a number of case studies that show the value of building data warehouses.