An Engineer's ViewIt's worthwhile to remind ourselves why we build data warehouses the way we doBased on reader feedback, I've decided to do something I haven't done for quite some time: go back to lay the foundation for what data warehouse designers do, and why they use certain techniques. Doing this also lets me restate the assumptions and techniques with the benefit of hindsight and more experience. I hope the results are tighter, more up to date, and more clearly worded. So, for the next half dozen columns, I'm going to work through the foundations of data warehousing. I'll touch on the end user's concerns, the readiness of a business to step up to data warehousing, and what it takes to manage a data warehouse project. I'll carefully define the pieces of the data warehouse and the mainstream techniques including drill across, drill down, facts and dimensions, slowly changing dimensions, surrogate keys, aggregate navigation, and many more. And finally, as much as possible, I'll avoid religious overtones. Fundamentally, I'm an engineer. I like to build things that work. I have a notebook of pretty specific techniques that I've been able to make work, and I'll use the next few columns to try to explain those techniques as clearly as possible, and why I chose them. The Data Warehouse MissionAt the outset, I want to share a perspective that I take very seriously, and in some ways is the foundation for all my work in data warehousing. It's the publishing metaphor. Imagine that you've been asked to take over responsibility for a high-quality magazine. If you approach this responsibility thoughtfully, you'll do the following 12 things: identify your readers demographically; find out what the readers want in this kind of magazine; identify the "best" readers who'll renew their subscriptions and buy products from the magazine's advertisers; find potential new readers and make them aware of the magazine; choose the magazine content most appealing to the target readers; make layout and rendering decisions that maximize the readers' pleasure; uphold high-quality writing and editing standards and adopt a consistent presentation style; continuously monitor the accuracy of the articles and the advertisers' claims; keep the readers' trust; develop a good network of writers and contributors; draw in advertising and run the magazine profitably; and keep the business owners happy. While these responsibilities may seem obvious, here are some dubious "goals" that you should avoid: build the magazine around the technology of a particular printing press; put most of your management energy into the printing press operational efficiencies; use a highly technical and complex writing style that many readers may not understand; or use an intricate and crowded layout style that's difficult to read and navigate. By building the whole business on the foundation of serving the readers, your magazine is likely to be successful. The point of this metaphor, of course, is to draw the parallel between being a conventional publisher and being a data warehouse project manager. I'm convinced that the correct job description for a data warehouse project manager is "publish the right data." Your main responsibility is to serve your readers who are your end users. While you'll certainly use technology to deliver your data warehouse, the technology is at best a means to an end. The technology and the techniques you use to build your data warehouses shouldn't show up directly in your top 12 responsibilities, but the appropriate technologies and techniques will become much more obvious if your overriding goal is to effectively publish the right data. Now let's recast the 12 magazine publishing responsibilities as data warehouse responsibilities:
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
|
