Ralph Kimball

Bob Becker

Data warehousing is a mature discipline with well-established best practices. But these best practices are useless or even harmful if they are described inaccurately or incompletely. One such set of best practices, based on dimensional modeling, known specifically as the Kimball Method, is a very specific set of design guidelines and procedures, often described down to the level of individual database fields and detailed, sequential steps.

In the "Kimball University" series in Intelligent Enterprise, we have published more than 100 articles describing various aspects of the Kimball Method. We are greatly indebted to Intelligent Enterprise for providing this resource to the data warehouse community. Yet every year or two we encounter serious misrepresentations made especially by speakers at training organizations where hundreds of students are given misleading information about our approach. These speakers recommend a homogeneous, raise-no-objections approach that combines many different techniques, leaving the designer to wonder how to make actual design choices.

This article addresses major points of misunderstanding and vagueness by providing guidelines that business intelligence/data warehouse (BI/DW) professionals can tuck into their project notebooks and refer to as unassailable facts and best practices of the Kimball Method.

1. Take an Enterprise Approach

The Kimball Method is specifically intended to deliver large-scale enterprise business intelligence/data warehouse solutions. Occasionally it has been described as a "bottoms-up approach," but it's more accurately described as a blended approach starting with an enterprisewide, top-down view. At the same time, it's tempered with the bottoms-up realities of real data sources.

We teach an enterprise point of view, starting with horizontal, cross-department gathering of requirements. This involves the executive team, senior managers and data analysts identifying and prioritizing high-value needs. The next step is to create the "enterprise bus matrix," a pivotal design document and powerful tool for understanding and creating the appropriate enterprise data architecture to support the business requirements. As we've said many times, real data sources in their atomic form are the "data marts" of the enterprise, a definition that differs from other designers who define data marts only as aggregated releases from a centralized data store. When we then say (correctly) that the enterprise data warehouse is the sum of these data marts, other observers sometimes miss the point of our architecture (see The Bottom-Up Misnomer for more details).

2. Embrace Business Intelligence

Business Intelligence is a term that has emerged and evolved over the past few years and is now often used to describe all the systems and processes an enterprise uses to gather, process, provide access to and analyze business information. The term "data warehouse" is now used to mean the platform for all forms of business intelligence.

Since we have been writing on this topic for more than fifteen years, we are beholden to our legacy of books, articles and design tips. In fact, "data warehouse" is included in the title of all of our books! Nonetheless, changing industry vernacular does not change the core concepts and methodologies described by the Kimball Method. Our approach has always embraced the entire, end-to-end process as critical to an organization's success.

3. Incorporate Dimensional Schemas

The Kimball Method is predicated on the principle that all business-user access to data is supported via dimensional schemas. Thus, what we call the "presentation area" of the overall business intelligence solution is comprised of a number of granular, atomic fact tables decorated with a rich set of descriptive, conformed dimension tables. We specifically avoid summarized, departmental data marts supported by a large, normalized data warehouse providing access to atomic data. We believe that such a centralized and normalized view of a data warehouse is responsible for many of the failures of data warehousing to support business intelligence applications.