Manage Learn to apply best practices and optimize your operations.

Data Warehouse Design Review Checklist

To ensure a quality data warehouse, you need a thorough design review. This chapter from the W.H. Inmon book "Building the Data Warehouse," offers steps for an effective review.

The following is excerpted from the W.H. Inmon book "Building the Data Warehouse," courtesy of Wiley. In Chapter 10, 'A Data Warehouse Design Review Checklist,' Inmon explains in detail how a proper review can make or break your data warehouse. To go directly to Inmon's 98 steps for a typical data warehouse design review, click here. To purchase the book, click here.

Introduction

One of the most effective techniques for ensuring quality in the operational environment is the design review. Through a design review, errors can be detected and resolved prior to coding. The cost benefit of identifying errors early in the development life cycle is enormous.

In the operational environment, a design review is usually done on completion of the physical design of an application. The types of issues around which an operational design review centers are the following:

  • Transaction performance
  • Batch window adequacy
  • System availability
  • Capacity
  • Project readiness
  • User requirements satisfaction

Done properly in the operational environment, a design review can save significant resources and greatly increase user satisfaction. Most importantly, when a design review has been properly executed, major pieces of code do not have to be torn up and rewritten after the system has gone into production.

A design review is as applicable to the data warehouse environment as it is to the operational environment, with a few provisos. have to be torn up and rewritten after the system has gone into production.

A design review is as applicable to the data warehouse environment as it is to the operational environment, with a few provisos.

One proviso is that systems are developed in the data warehouse environment in an iterative manner, where the requirements are discovered as a part of the development process. The classical operational environment is built under the well-defined system development life cycle (SDLC). Systems in the data warehouse environment are not built under the SDLC. Other differences between the development process in the operational environment and the data warehouse environment are the following:

  • Development in the operational environment is done one application at a time. Systems for the data warehouse environment are built a subject area at a time.
  • In the operational environment, there is a firm set of requirements that form the basis of operational design and development. In the data warehouse environment, there is seldom a firm understanding of processing requirements at the outset of DSS development.
  • In the operational environment, transaction response time is a major and burning issue. In the data warehouse environment, transaction response time had better not be an issue.
  • In the operational environment, the input from systems usually comes from sources external to the organization, most often from interaction with outside agencies. In the data warehouse environment, it usually comes from systems inside the organization where data is integrated from a wide variety of existing sources.
  • In the operational environment, data is nearly all current-value (that is, data is accurate as of the moment of use). In the data warehouse environment, data is time-variant (that is, data is relevant to some one moment in time).
  • There are, then, some substantial differences between the operational and data warehouse environments, and these differences show up in the way the design review is conducted.

When to do a design review

A design review in the data warehouse environment is done as soon as a major subject area has been designed and is ready to be added to the data warehouse environment. It does not need to be done for every new database that goes up. Instead, as whole, new major subject areas are added to the database, a design review becomes an appropriate activity.

Who should be in the design review?

The attendees at the design review include anyone who has a stake in the development, operation, or use of the DSS subject area being reviewed. Normally, this includes the following parties:

  • The data administration (DA)
  • The database administration (DBA)
  • Programmers
  • The DSS analysts
  • End users other than the DSS analysts
  • Operations
  • Systems support
  • Management

Of this group, by far the most important attendees are the end users and the DSS analysts.

One important benefit from having all the parties in the same room at the same time is the opportunity to short-circuit miscommunications. In an everyday environment where the end user talks to the liaison person who talks to the designer who talks to the programmer, there is ample opportunity for miscommunication and misinterpretation. When all the parties are gathered, direct conversations can occur that are beneficial to the health of the project being reviewed.

What should the agenda be?

The subject for review for the data warehouse environment is any aspect of design, development, project management, or use that might prevent success. In short, any obstacle to success is relevant to the design review process. As a rule, the more controversial the subject, the more important it is that it be addressed during the review.

The questions that form the basis of the review process are discussed later in this chapter.

Administering the review

A data warehouse design review has three results:

  • An appraisal to management of the issues, and recommendations as to further action
  • A documentation of where the system is in the design, as of the moment of review
  • An action item list that states specific objectives and activities that are a result of the review process

The review is led by two people -- a facilitator and a recorder. The facilitator is never the manager or the developer of the project being reviewed. If, by some chance, the facilitator is the project leader, the purpose of the review -- from many perspectives -- will have been defeated.

To conduct a successful review, the facilitator must be someone removed from the project for the following reasons:

  • As an outsider, the facilitator provides an external perspective -- a fresh look -- at the system. This fresh look often reveals important insights that someone close to the design and development of the system is not capable of providing.
  • As an outsider, a facilitator can offer criticism constructively. The criticism that comes from someone close to the development effort is usually taken personally and causes the design review to be reduced to a very base level.

A typical data warehouse design review (in 98 steps!)

Click here for the complete list of steps to follow in a typical data warehouse design review.

To purchase the W.H. Inmon book "Building the Data Warehouse," click here

This was last published in January 2006

Dig Deeper on SQL Server Data Warehousing

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchBusinessAnalytics

SearchDataCenter

SearchDataManagement

SearchAWS

SearchOracle

SearchContentManagement

SearchWindowsServer

Close