Data models are not always as successful as data modelers hope. That is an unfortunate fact of life. One of the most significant reasons, I believe, is that data modelers usually try to accomplish two goals at once -- often unknowingly.

On the one hand, they attempt to use the data model to explore business requirements with users,

while at the same time, to develop system requirements and database designs.

This is not only hard, but also tends to address the wrong questions at the wrong times. To put it bluntly, it just doesn't work very well.

The solution is to stop using Data Models for developing business requirements. (I hope I have your attention now!) No, I do not mean that literally. What I actually mean is to sort out clearly what's what. In our practice, we no longer use the term "Data Model" in doing Business Analysis. Instead, we use it only for the System Model Phase.

Our new term for the Business Analysis Phase is Fact Model. In this column and the next, I will explain what we mean by "Fact Model" -- and also how it differs from a Data Model.

What is a Fact Model?

A Fact Model, as we see it, structures basic knowledge about business operations from a business perspective. "Basic" means that the knowledge it represents cannot be derived or computed from any other knowledge. It that sense, a Fact Model is a crucial starting point for developing more advanced forms of business knowledge, including measures and rules.

In particular, a Fact Model focuses on logical connections (called "Facts") between core concepts of the business. In the Fact Model, concepts are represented by Terms. Facts connect those Terms in a manner that should reflect the "real world." Both Terms and Facts in the Fact Model should be "basic" in the sense above.

A Fact Model focuses on "knowing" -- that is, on how you organize your knowledge about the business process. Specifically, it indicates what you need to know about the business operations in order to support (or actually "do") those operations. In contrast to a Fact Model, process-oriented deliverables such as Workflow Models and Task definitions target only the "doing" of the business process.

A good Fact Model therefore tells you how to structure your basic thinking (or "knowledge") about the business process based on a standard vocabulary.

This ensures that you can communicate effectively about that knowledge with other project participants. It also allows you to exploit this "standardized" knowledge and vocabulary to express other types of requirements, especially Rules -- and to communicate about those effectively too.

There should be only a single, consolidated Fact Model within the entire scope of a Project or problem domain. The goal is to unify basic business knowledge within that scope, and to express each element of that basic business knowledge uniquely. This can be expressed as a fundamental goal for Fact Models: "one fact, one place, one name."

Fact Model vs. Data Model

Another purpose of a Fact Model is to provide a business-based starting point -- a blueprint -- for the subsequent development of a Data Model or database design. A good Fact Model can be easily transformed into a first-cut Data Model.

However, you should not think of a Fact Model as merely a high-level Data Model. A Fact Model is part of the Business Model, whereas a Data Model is part of the System Model. There are significant differences in perspective, purpose and success criteria.

In contrast to a Fact Model, a Data Model focuses on delineating the data and its proper format to support system-level requirements development.

It looks ahead toward the database environment, and introduces features appropriate for database design in the given technical environment. It also addresses the complexities of organizing historical data.

None of that is appropriate for the Fact Model. In short, the primary audiences for the Fact Model and the Data Model are different. The primary audience for the Fact Model is Business Analysts and Subject Matter Experts (users), whereas the primary audience for the Data Model is System Designers and DBAs.

© 2000, Ronald G. Ross.