Month Year Issue

May 1998 Issue: 2

Journal of Conceptual Modeling
www.inconcept.com/jcm

Elementary Facts
by John M. Miller

I've taken the title of this column from a famous line in the old radio drama and TV series. Dragnet. A witness would be spilling their guts and Sgt. Friday would calmly say, "just the facts" and the witness would calm down and begin to tell Sgt. Friday only the pertinent information.

Sometimes I feel just like Sgt. Friday.

A client of mine that writes custom software calls me and tells me their most important customer has asked for changes in their sales order system. They proceeded to tell me how important it is, how much more complex the changes make things, how difficult it is going to be and how little time they have to finish.

When I arrived at the first design meeting the person in charge of the account explains in general terms how the current software was designed and in general terms what he thinks the customer wants the software to do instead. Very interesting, of course <s>, but nothing that can be used to design a system. I've grown accustom to these initial meetings. You have to attend them before you can get to work, but the information content would fit on an index card. At the end of the meeting it was agreed that I would talk with the project leader and would do what I could to help with the new system.

The project leader and I decided that we'd go to lunch and talk about the issues over a bite to eat. During lunch, I in essence asked the project leader to "just give me the facts" and using the responses I started creating an ORM model. By the end of lunch we had the beginnings of a design that met all the major requirements of the new system. As a bonus the project leader had the beginnings of an understanding of ORM.

Ever since I learned ORM this happens all the time. I almost never get asked to create an ORM model, I create ORM models to help clients understand what they want. The key to the whole process is getting the facts straight.

But what is a fact?

Dr. Terry Halpin, the horse's mouth, so to speak, in the glossary of Conceptual Schema & Relational Database Design defines a fact as:

A relationship that is not a primary reference.

Hmmm…

Not exactly "user friendly" if you know what I mean.

The Merriam-Webster Dictionary defines a fact as:

fact \"fakt\ n 1 : DEED; esp : CRIME <accessory after the ~> 2 : the quality of being actual 3 : something that exists or occurs 4 : a piece of information

The most common definition, "after the fact", would certainly make sense to Sgt. Friday, but in ORM a fact is not a deed. The second, "and that's a fact", is more of a state mind. The third definition, "the fact is", is close. The fourth, and least used, definition is closest to what a fact is in ORM.

A fact is a piece of information. For example, John is wearing blue shorts, is a fact. Although this may no longer be a fact by the time you read this, although it could be said that someone named John is wearing blue shorts somewhere in the world at all times. But I digress.

ORM works by building an inventory of all the facts pertinent to a problem. If we are interested in people and the types and colors of the clothes we wear, then this fact is pertinent and we can model this fact in ORM.

Each fact in ORM involves one or more objects. An object is something that may be seen or felt, or something that may be perceived or examined mentally. Generally, an object is something that has a name or can be referred to in some way. In our example, John, Blue and Shorts are all objects.

It is important for ORM that each fact be elementary. By elementary it is meant that a fact cannot be broken down into multiple simpler facts without losing meaning. In our case the fact John is wearing Blue Shorts is not elementary, for John and Blue have nothing to do with each other. John is not Blue, the Shorts are Blue. Blue is a describing the shorts and can describe the short independently of John. Our fact can be broken down into two facts, John is wearing Shorts, and the Shorts are Blue.

These two facts are considered fact instances. The John, Shorts and Blue objects are instances of types or classes of objects. For examples John is an instance of a Person, Shorts is an instance of Clothing and Blue is a Color.

In ORM you model fact types not fact instances. So is we substitute the types for the instances, John is wearing Shorts becomes Person wears Clothing and the Shorts are Blue becomes Clothing has Color. Notice that both fact types share a common object, Clothing.

In ORM each fact type is autonomous and is independent of any other fact type. The importance of this can't be over emphasized. It allows the removal or addition of any fact type without affecting any other fact type. This makes ORM models very stable. You can start with a simple model that contains the core concepts of an idea and then gradually add complexity and detail fact type by fact type until you've solved the case!

John M. Miller is an information systems consultant. His company, Perpetual Data Systems, uses ORM as a part of their application development methodology.

jMiller@pdata.com
http://www.pdata.com