Martin Mason (4/7/2011)
magarity kerns (4/7/2011)
I think the first assertion needs a slight modification; a first version DW should produce one reporting subject area, not just one report. From there, it's a question of how many reports are needed, which may be only one but could be several.I totally agree with you. Start with one subject area, not one report. If you begin with one subject area and use the Kimball four step process, (1) identify the business process, (2) explicitly state the grain or level of detail required, (3) identify the dimensions or business actors acting in that process, and (4) identify the metrics used in the analysis of that business process, you're well on your way to success. Plus, your building the blocks for additional subject areas to be integrated by sharing conformed dimensions. If you're guided by a report, you're much more likely to build a data silo that will be much more difficult to extend and maintain.
The problem is that in most cases the business doesn't start out by saying "we need a datawarehouse, so let's put our heads together and figure out the best way to go about doing that"
The initital build of the datawarehouse typically stems from a request coming from uppermost management for an enterprise level report or dashboard that shows them X, Y, Z and the IT department just sort of figures out at some point (hopefully before the first deployment) that a datawarehouse of some type would be essential.
Not unless they bring in an outside consultant, or at least one person on the project is up to speed on database architecture, would the initial phase of development ever involve a discussion of Kimball, Inmon, OLAP cubes, or even data replication.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho