Content area
Full text
People involved in business intelligence (BI) and data warehousing (DW) projects are very familiar with terms such as facts, dimensions, attributes, surrogate keys and slowly changing dimensions. But knowing the terms is not enough. Increasingly, there appears to be a significant disconnect between how BI or DW systems are actually built versus the best practices described in books and articles. Clients point out that the concepts in some books and articles are esoteric because they are not connected to real-life situations. They teach the how but not the why. Two best practices that people think they are implementing but often fall short of are dimensional modeling and the hub-and-spoke architecture.
When you don't know why you should design a DW a certain way, it's easy to make the common mistake of designing DW and BI systems to look like your source systems.
Granted, the target systems (DW, data marts and cubes) contain the data obtained from the source systems, so it does make sense that the content is similar. Similar content is not the problem; a similar physical design, however, is. Rather than applying the best practice design techniques they've learned to support DW and BI, people copy the underlying enterprise applications' designs to the DW. This process propagates the limitations of the enterprise applications for reporting and analysis without taking advantage of DW best practices such as dimensional models or the hub-and-spoke...