Fact Modeling

Good information system design and development depends on a well-designed database. Furthermore, good, efficient database design depends upon the modeling scheme you use. The dominant scheme used in most organizations today is some variant of ER or Relational Data Modeling. However, record-based modeling has some serious problems and limitations (see "Tableitis"). You probably think about "records" or "tables" when you design databases, that is, entities with attributes. If so, you had better have a thorough understanding of normalization techniques (even most professional data modelers don't always get it right), or your organization may be at risk. Normalization is the Achilles heel of data modeling. Fact Modeling with ORM is a high-level, conceptual data modeling scheme. ORM makes normalization unnecessary because there are no entity tables in the initial design stage. With its associated design tools, you can automatically generate a relational database design which is guaranteed to be fully normalized! Then, you can automatically generate the relational database definition (DDL) for your favorite DBMS. There is an open source software tool to support ORM called NORMA which runs as a plugin to Visual Studio (http://sourceforge.net/projects/orm). If you use MS Visual Studio team edition, you may already have an ORM modeling tool in Visio.

A Brief History of Fact Modeling -- my personal view.

I had the privilege of getting in on the ground floor. This “Movement” began with Sjir Nijssen, 1976, though others made significant contributions as well. In 1975 Sjir and I were on the “faculty” of a two week “school” held in Germany primarily for IS teachers. There, I and Mike Senko reviewed drafts of two papers Sjir had written on work he was doing then. They were subsequently published in 1976. He called it "binary modeling"; it became known as NIAM. I returned to add that material to my advanced database course at the U of MN. I became convinced that there was something to this idea of fact modeling, and am even more so today. In 1983 Sjir took a chaired position at U of Queensland.

There Terry Halpin (a logician) teamed up with him also recognizing the significance of fact modeling. Together they published a book (1989, P-H), renaming it Object Role Modeling (ORM). A software tool to support ORM followed shortly after. Halpin’s 2008 book is effectively the third edition of ORM. You could argue that Sjir birthed the movement, and Terry gave it more substance and rigor.

Bill Kent was another major contributor to this “movement” with his book “Data and Reality”- a classic. Steve Hoberman recognized this and republished it recently with Technics, his publishing arm. Ron Ross, dominant mover in Business Rules, speaks of “verbish” in data modeling. Today there are multiple flavors of Fact Modeling – FOM, FCO, …, particularly in Europe. I now use the term “Fact Modeling” as generic for all of these, rather than just ORM.

Only recently have I realized the fundamental difference with relational - we model relationships before attributes, some call it "attribute free" modeling. Fact modeling treats all domains as objects, whether entity or attribute. So what is an attribute? AN ATTRIBUTE IS AN OBJECT PLAYING A ROLE IN A RELATIONSHIP WITH SOME OBJECT. The relationship comes first.

I am utterly convinced that fact modeling is a much better way to approach “data” modeling. My Advanced Data Modeling course has evolved with about half of it now devoted to ORM. With “early” retirement, I was able to devote my full attention to getting that course wholly online. After 4 years of recorded lectures, I “flipped” the class -- Students watch all lectures online. If you are so inclined, you can sign up for the full course which starts in January each year.

Today, with the ER/relational approach, due to Ted Codd and Chris Date, being so pervasive in our thinking (database textbooks, DBMS, and Data modeling tools), it is an uphill battle to convince practitioners to think in terms of fact modeling. People steeped in the Relational approach suffer from "Tableitis." They don’t realize that most of their data modeling problems stem from TABLE THINK, and are solved in Fact Modeling.