« The Extended Enterprise: Federated Data Models | Main | Yesterday's DM Radio broadcast on data federation »


Feed You can follow this conversation by subscribing to the comment feed for this post.


Very good an accurate post.

i would mention, though, that data warehouses are extremely difficult to develop/maintain if they
rely on traditional RDBMS platforms such as SQL Server, Oracle and MySQL. Not as painful when relying on column-based database technology.

Unlike in the past, there are many companies doing what you would call "real BI" (=not Excel) without a defacto data warehouse.

you may want to check out companies like sisense (http://www.sisense.com) and Green Plum (http://www.greenplum.com)

I would also mention that there are alternatives to OLAP for achieving multi-dimensional analysis. :-)


A problem (similar to case #1 above) is to base the warehouse data model on one operational system in an environment with multiple sources. I work with a DW that is fed by four different systems for the same business function. Instead of deciding what was wanted as a target and working back, one system was selected and pushed forward. The DW works reasonably well for that system. I keep pain-killers handy for when the other three need maintenance.


Laura, check this post out:


company logo design

Well don't know whats going on but its not a Good way to do this. in my opinion we have to look again about this issue

Rick Sherman


The pain killers will probably be needed at some point. Selecting one source system as the target schema was often used when people were building ODS (operational data stores). It certainly a quicker way to to build a "DW" but generally lacks the robustness needed for changes that may occur in the multiple SORs and the inevitable changes in organization, products/services and other dimensions.

In addition, this approach may cause more downstream work to support truly enterprise-wide analytics.

An ODS is often a 1st generation approach.


Rick Sherman


Thanks for the feedback. Certainly columnar databases and other OLAP alternatives have come a long way in being able to handle the scale that many Enterprise DWs require.

I generally position the non-relational alternatives for use in data marts or as a single enterprise data mart. These products were built for analytics and do a great job there.

Generally we recommend two layers (schemas/databases) for an enterprise: DW for data integration & distribution and a Data Mart(s) layer for analytics & reporting. Generally a one-size fits all either reduces the flexibility of the DW to absorb change and present an enterprise view or the DM to provide business-specific or process-specific metrics.


The comments to this entry are closed.