GETTING THE FACTS RIGHT

Recently I received the following email from a reader about a Ron Ross article published on this web site:

What about this text Ron Ross wrote in the third part of his series, The Business Rule Approach: Changing the Face of IT Methodology? It is unbelievable that he still doesn't understand that the fact model is the conceptual model. That it is nothing new. His definition now almost fits yours. This article is again full of debunking stuff. Can you understand what is he talking about, type codes and instances and all those fuzzy words? Why is it possible that his opinion is "printed" on and on?

The reader refers to my two articles, Something to Call One’s Own and The Name Game, both titles and content of which refer to the penchant in the industry for “new approaches” or “paradigms”. Alas, the Codd caliber is extremely rare (to understate the case), and an inspection of many of the industry’s “paradigm shifts” reveals numerous attempts to coin “new approaches” that not only lack soundness, but are not even new. Often they prove to be old relabeled stuff (discredited to boot, witness the hierarchic data model underlying XML, rendered obsolete more than three decades ago). Those Who Don’t Know the Past Are Doomed to Repeat It.

The “business rules approach” is another such attempt. I am not going to repeat a third time all that I already questioned twice. I will just selectively debunk a few of the pronouncements in Ross’s TDAN article to prove my point.

A fact model is a diagrammatic representation of a structured business vocabulary, which is essential for expressing large numbers of rules in a consistent fashion. A fact model is central, business-oriented deliverable of the business rules approach.

The “fact model” is practically indistinguishable from the good old conceptual model (or business model, as it is sometimes referred to). Indeed, as we state in Business Modeling for Database Design, the conceptual model can have a graphic representation, but in its non-graphic form, it is a collection of business rules (formally predicates) expressed informally in natural language (see also The Logic of Business Rules).

Note: The graphic form has a weakness: there are many business rules that cannot be represented graphically.

How does a fact model differ from a logical data model? We view a fact model as part of the business model a project should develop, whereas a logical data model is part of the system model it should develop. A fact model provides a business-based starting point—a blueprint—for subsequent development of a logical data model or database design. A good fact model can be easily transformed into a first-cut logical data model.

There are naturally significant differences in perspective, purpose, and success criteria between fact models and logical data models. In contrast to a fact model, a logical data model generally places emphasis on the following areas.

The term “logical data models” reveals confusion of levels of representation and models (see “Universal Data Models”, Levels of Representation, and the Importance of Thinking Precisely ).

The concept of a data model was invented by Codd, as follows:

[A data model] is a combination of three components:

1. a collection of data structure[s]…

2. a collection of operators or inferencing rules, which can be applied to any valid instances of the [pertinent structures] listed in 1, to retrieve or derive data from any parts of those structures in any combinations desired;

3. a collection of general integrity constraints *, which implicitly or explicitly define the set of consistent database states or changes of states, or both…

--E. F. Codd, Data Models in Database Management, IBM Research Laboratory, 1980

* We prefer the term integrity constraint to Codd’s integrity rule, which is the representative in logical models of the business rule in conceptual models.

As we explain in paper #4, conceptual and logical models are enterprise-specific; they are models at the business and database levels, respectively, of specific enterprises of interest. Conceptual models are more or less what Ross calls “fact models”; they are informal and consist of business rules—which are nothing but generalized facts—and, as such, are the user-understood meaning of databases. Logical models are the formal database representations of fact models, consisting of integrity constraints, the DBMS-understood meaning of databases. The data model (not models!) is not of enterprises, but of data in general! It is the “translation language”, so to speak, that makes the mapping of informal conceptual models to formal logical models possible.

Because of confusion between the three types of model, Ross’s notions of ‘differences in perspective’ and ‘relative emphasis’ are not worth getting into.

A fact model and a logical data model also often have very different perspectives on the best handling of what is commonly known as type codes. Remember that the emphasis in fact models is on standardizing the business terminology and then capturing rules. The emphasis in a logical data model, in contrast, is often on achieving the most flexible data design possible—usually the best design for accommodating change.

Frankly, I don’t know what “type codes” are, but if “fact models” are “about standardizing the business terminology and then capturing rules”, and if they are new, what have we been doing without them up until now? Let’s be serious.

The typical approach for logical data models therefore features special data objects or tables to handle type codes. The instances of such a data object or table represent valid type code values. This data object or table is related to any data object that is to be given one (or more) of those valid types. Creating a table for the codes in this fashion allows changes to the set of codes without impact on the database design. The logical data model itself, however, does not concern itself too much (if at all) with what the actual type code values might be.

We will not try to make sense out of this; we invoke Date’s Principle of Incoherence. So often in the industry proposed “new approaches” pay lip service to currently fashionable buzzwords, in this case objects. Tables—and we remind the reader, of a special kind!—is not an object in the OO sense, and confusing the two is misleading. Unlike relational concepts, object terminology is fuzzy and, what is more, it is at best For Application Development, Not Data Management.

In particular, a fact model focuses on assertions (called facts) involving core concepts of the business. In a 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 defined above.

A fact model focuses on the knowledge part of a business problem—that is, on how knowledge underlying business operations (the “flow”) is organized. Literally, the fact model indicates what you need to know in order to do what you do.

More fuzzy and undefined terms. A conceptual model consisting of business rules does not require new terminology, certainly not an imprecise one. Again, does Ross suggest that we have not been doing this, waiting for him to come up with his “fact models”?

Fundamental Goal for Fact Models: One fact, one place, one name.

See what I mean? How new is that? It is only new to those lacking foundation knowledge, who do not bother to acquire it, knowing that the audience doesn’t either.

In the aforementioned Something to Call One’s Own article I included an exchange that followed my submission of a proposal for a presentation of the Business Rule Forums. I rest my case.

Posted 7/2/04