What Are Fact Models and Why Do You Need Them (Part 2)

by Ronald G. Ross

In Part 1 of this two-part series, Mr. Ross explained what Fact Models are, and how they differ from traditional Data Models. He continues these lines of thought in the following discussion.

What is important — and what is not important — when you create a Fact Model?  Obviously what is not important is how you will organize the "data" or design the database.  Putting those things aside is often difficult for professionals trained in that difficult discipline.

Nonetheless, the key to success with the Fact Model is keeping the model focused squarely on the business perspective.  That means all specifications and the graphic model are aimed at structuring how business people need to think and communicate about the business process in an organized fashion.  Everything in the Fact Model is about the business vocabulary they need in order to do that effectively.  Consequently, the Fact Model is really about creating diagrams of simple sentences — nothing more and nothing less — sentences that link core business concepts to one another in basic ways.

Success in that regard has a big additional benefit.  You will find that focusing on how core business concepts relate to another one another helps highlight clear alternatives about how the business itself can be best structured to meet its goals.  Such questions, of course, are ones that should be answered by business users.  They are also clearly ones your project should answer before you move into system design — especially if any re-engineering is to be done.

Relationships to other Architectural Products in the Business Model

We believe a Fact Model relates to other key deliverables in the Business Model Phase in the following ways.

• Policy Charter:  This is your battle plan outlining the business solution.^[1]  Every Business Tactic and Core Business Rule it contains should be based on Terms and Facts found in the Fact Model.  Examine the Tactics and Core Business Rules for basic knowledge that needs to be structured and "standardized."
  
  
• Workflow Model:  The Workflow model outlines the business process, and shows who does what.  Execution of the Tasks in the Workflow Model (i.e., "doing" the business process) create or transform instances of the Terms and Facts in the Fact Model.  In other words, actually doing the Tasks either creates the actual instances of what we "know" about the business process, and/or exploits those instances in some way.
  
  
• Rule Book:  A central deliverable of the Business Rule Approach is the Rule Book.  The Rules in the Rule Book will directly depend on the Terms and Facts developed during Fact Modeling.  The Fact Model provides re-usable sentence patterns (the Facts) for expressing the Rules.  These sentence patterns are ready-made building blocks for the expression of the Rules.  Across a large set of Rules, following standard sentence patterns ensures consistency and commonality in the interpretation and analysis of the Rules.

Fact Model vs. Data Model: What are the Differences?

As discussed earlier, Fact Models and Data Models address the needs of different primary audiences.  Consequently, they have different characteristics and areas of emphasis.  It is very important to keep these distinctions in mind, especially since Data Models may use graphic conventions similar to the Fact Model (i.e., boxes and box-to-box connections).

In contrast to a Fact Model, a Data Model generally places emphasis on the following areas.

• Delineating the data and its proper format to support system-level requirements development.

  In a Fact Model, a box represents a Term and the business concept it stands for.  In a Data Model, a box generally represents a collection of attributes or fields that are structured to retain the appropriate data for storage and manipulation by applications.

• Looking ahead toward the database environment, and introducing features appropriate for database design in the given technical environment.

  Examples include normalization (or possibly de-normalization), cardinality, associative entity types to support many-to-many relationship types, mandatory-ness, etc.

• Addressing the complexities of organizing historical data.

  In general, Fact Models do not concern themselves with "history."  They simply identify what should be known about the basic business process.  A Data Model, in contrast, must concern itself with the "points-over-time" aspect of data — so the business (and its rules) can know about the past (and the future).  Modeling this points-over-time structure of data is one of the most important (and difficult) challenges in Data Modeling.

A Fact Model and a Data Model often also have very different perspectives on the best handling of what is commonly known as "type codes."  Remember that the emphasis in the Fact Model is on standardizing the business terminology.  The emphasis in a Data Model is often on achieving the most flexible data design — usually meaning 'best for accommodating change.'

A Data Model, therefore, often features special data objects or tables to handle type codes.  The instances of this data object or table are the actual valid type code values.  This data object or table is then related to any data object that is to be given one (or more) of those valid types.  Creating a table of the codes in this fashion allows changes to the set of codes without impact on the database design.

This is not the best approach for the Fact Model, however, since in that arena, the focus is on capturing and standardizing the business terminology in a design-independent fashion.  Remember too, that the "type" information is likely to be highly-relevant to product/service-type rules of the business.  Therefore the following recommendations are made:

• If there are fewer than 3-5 "types," show them as subsets (ISA Facts).
  
  
• If there are more than that, or if that approach clutters the Fact Model unduely, then create a separate Instance Model for the various "types."

Instance Models are something else we have found essential for developing business rules — but that's another topic for another day.

[1]  For information on developing a policy charter, see Business Knowledge — Packaged in a Policy Charter, by Gladys S. W. Lam.  

[2]  This is an excerpt from The BRS Fact Modeling Practitioner's Guide:  Developing the Business Basis for Data Models, (2000).

©2000, Ronald G. Ross