Clay Rehm has published an article on Data Warehouse Do's and Don'ts in the IDWA Navigator magazine.  That article has been included here for your reading pleasure...

Data Warehouse Do's and Don'ts

Executive Summary:

Clay Rehm of Rehm Technology (www.rehmtech.com) provides an overview of the building of a new Data Warehouse, data mart or operational data store (ODS). Through years of actually building and maintaining successful warehouses, he provides an insightful view of tasks that are often overlooked.

DO try to leverage existing investments in software and hardware. Too many companies believe the vendor hype that they cannot accomplish their objective without purchasing the latest and greatest software and hardware. My greatest success stories revolve around using database software on the mainframe and using a combination of mainframe and PC-based query and reporting tools. The customer does not need to purchase more items, they already have trained personnel in the existing tools, and the existing tools work great! Current mainframe tools usually are more mature and have processes in place for proper backup and security. The moral here is look at what you have first before leaping.

DON'T involve negative forces in the project. A warehouse team needs customer-focused people – not people who have attitudes, who hate their jobs or who think they are smarter than anyone else is. The project team should consist of open-minded business and technical individuals that will work well as a team.

DO appoint a data trainer. This is extremely important if you want your warehouse used correctly. This person would be from a business area, and hopefully already has a good understanding of the company data. These people are usually found in Marketing Information departments, who are used to developing reports for other departments. This person or people will need to set class times and provide structured training as well as provide one on one support. Having this in place could make or break a data warehouse.

DON'T make it difficult for the user. After all, the warehouse is for the business user, not IT. Data modeling for a warehouse is different than modeling operational systems.

There are data modelers who believe warehouse tables must be normalized to the nth degree, or they haven't done their job right (those people do not belong on the team). Warehouse tables are for business users who in most cases are not familiar with relational database technology and normalization. The moral here - Keep it simple! If the design forces complex extract and load programming, then do it! Why are we here otherwise?

DO build a simple, easy to use data dictionary. This is really hard to mess up. As the project starts, start documenting business definitions in a database. This way, if there is no data dictionary available, you can provide one to your users through either client-server screens or hardcopy. This always seems to be done as a last task or not done at all. It is very important that this be started right away. As soon as your users start to use the warehouse (or even test it), they will need to know what the data means.

DON'T design the warehouse for the wrong audience. You must involve the customer from the start and during the whole process. The "customer" is ultimately the group of people who will be using the warehouse on a daily basis. Designing a warehouse for an audience that won't be using the warehouse will prove to be a costly mistake, which you will find out as the project progresses. As mentioned above about  purchasing software and hardware for the sake of technology, don't try to build a warehouse because management read about it in a magazine and thinks the company needs one. There needs to be a definite business need  that your warehouse will solve.

DO develop naming standards RIGHT AWAY to reduce the rework involved with renaming tables and columns later. And while you are at it, make the names easy to use. WHSE_CUSTOMER is much easier to understand than ABC001_CUST_TB. Develop standard abbreviations for words that will be too long to use. Every column must end with a description of what it is, such as date, text, amount, quantity, flag, code, etc.

DON'T forget that the hardest part of data warehousing is maintaining it after it has been built. The project team that builds it most likely will not be around to maintain it. It is important to select the right people for the job. The group that will maintain it must be customer service oriented, who will aspire for quick turnaround and insist on quality. These people are extremely hard to find, but the right people can be trained.

Copyright © Rehm Technology LLC. All rights reserved.