February 1999        Issue: 7

Journal of Conceptual Modeling
www.inconcept.com/jcm

In the Beginning...
By Patrick Hallock

Introduction

Object Role Modeling (ORM) speaks of the 'Universe of Discourse' (UoD) which is the test for including or excluding any proposed assertions. A UoD about an ordering system includes an assertion of "Customer completed payment on Date" but would probably not include "Student prefers morning scheduled Class". Determining the UoD is a basic step in beginning a conceptual model.

In the beginning: our UoD is empty (Figure 1). We as modelers or subject matter experts (SME) may have a lot of assertions in out heads as we start. Regardless of that mental baggage we always start a new model with an empty UoD. This is a comforting and exciting thought - just maybe we can do it right this time and fix the glitches of our past efforts. Of course, we could always borrow from a similar UoD -- this is a case where plagiarism is an art form - but we call it patterns.

Figure 1: A blank UoD

So, what is fundamental building block of the UoD?

"Conceptualization on any considerable scale is inseparable from language, and our ordinary language of physical things is about as basic as language gets."

"Word & Object"
Willard van Orman Quine

Since we are in the conceptual modeling business, the above quote has a good feel to it. Quine does go on to include things that are things that are not only physical. We often refer to things that are not physical, such as "corporation", which is defined as a "legal person" in most places.

Here is a basic UoD with one object: "Country". It fits the basic language tests and could qualify as a complete sentence. If asked what do those lines and colors represent on a map, I could respond, "Country".

Figure 2: A basic UoD

In the UoD I have now asserted that "Country Exists!" I can even give examples to help prove my case - 'Canada', 'Mexico', and 'Spain' are either countries or they are not. Since they currently are, we can continue. Here the ellipse is used to represent a set of countries with 'Canada', 'Mexico', and 'Spain' as members of this country set.

Figure 3: A set of countries

In ORM, we assume that objects play roles with other objects, but for the moment Country merely exists. The assertion that 'Country Exists' can support an entire model. Here are the results of such a model. I do have to include a reference mode for country since we cannot put the actual country in the model. Here is the conceptual model followed by the logical model and then the data definition language script to create the physical model.

create database Country

create table Country
("Country name" varchar(25) not null)

alter table Country
add constraint Country_PK primary key ("Country name")

Figure 4: The conceptual model, the logical model, and the SQL script for the UoD

We can now add, delete, update or display Country Name. We can determine if a given name is a Country Name. We also have behavior or constraints on the Country population. There can be no duplicate Country Names; this is covered in the last 2 lines of our script shown above.

And now for something completely different

It seems that as I read other subject areas, such as physics or biology leading to medicine, I am always struck by their desire to learn more and more about smaller and smaller things -- the building blocks. It has only been possible to create genetically engineered drugs to cure or manage human medical conditions because physicists and biologists have constantly maintained this effort. Part of this understanding included how these objects behave by themselves, with other like objects, or with unlike objects. As larger objects are constructed from these basic objects, they found a different behavior. They, as scientists, also agreed to offer their work to the community for review. This can be a very trying time but it is the reason why we can accept some things are reasonable and other as not reasonable. I prefer that they behave this way prior to injecting me with some new drug. In another area -- on the bright side -- this is also why my computer is faster than ever. The message is: determine the most basic objects, understand their behaviors, and then use that to build larger objects with more complex behaviors.

Remember this construction and behavior is subject to review or otherwise your system may behave poorly. Also, remember that the initial constructs may be modified to allow for new and novel behaviors.

Now, back on track

Our conceptual model is based on what we assert to exist in our UoD. Below are some other things that could exist in our UoD.

Figure 5: A few more objects in the UoD

We have a new set of assertions about what exists within the UoD; now it includes Country, Person, Last Name, First Name and Date. Each has a behavior unto itself. Just as in the Country example, we can add to, delete from, update, or display any of these objects. Each object cannot have any duplicates in its population. Last Name cannot have two strings that say "Becker", nor can it contain a string that is not a Last Name. Date cannot include the same Date twice nor can it contain anything that is not a Date. The model is larger but it has limited usefulness. It possesses a very simple behavior; the behavior of any one object's population has nothing to do with the population of another.

Some may note that Last Name looks very much like an attribute of Person. This may be true in the final analysis, but at this stage, the object Last Name merely exists. What Last Name does -- and eventually becomes -- can be postponed until we are done with the conceptual model.

A quick side-note: It is usually the case that children learn the names of things before the behavior of things. This is also true of adults learning a foreign language (one technique is to put notes on everything in the house with the foreign language name).

Having collected some objects, we can create some sentences that use these objects. It is usually the case that we start here in modeling, but it was fun to look at the existence of objects first. The experts in the UoD may say such things as:

Person was born in Country.
Person has Last Name.
Person has First Name.
Person was born on Date.
Country was founded on Date.

This is language in form of Object <predicate> Object. Other patterns are possible, but not today. These are also assertions, or 'facts', about our UoD. They are also assumed to exist. Our proof that Country as an object existed depended on knowing some Country Names -- we can only prove our 'facts' if we can provide examples of each fact. If we cannot provide an example of someone being born in a country, then the fact is rejected from the UoD. Thus, it is useful to improve on the sentence; for example, something along the line of:

The person with the ID 'p01' has the Last Name 'Anderson'.

Here is an instance of the fact and is in itself is adequate to allow the existence of the fact. However, this is not sufficient to determine the behavior of the fact. It is easier to determine the behavior of Last Name by itself but facts using Last Name require some more work. Here is a larger set of examples:

The person with the ID 'p01' has the Last Name 'Anderson'.
The person with the ID 'p02' has the Last Name 'Anderson'.
The person with the ID 'p03' has the Last Name 'Benson'.
The person with the ID 'p04' has the Last Name 'Carter'.

If this is a representative set of examples for the UoD then we can imply the following:

Each person can only play in this fact once.
A Last Name can play in this fact more than once.

In a little more friendly way: A person can have only one Last Name or, at least, a Person can have only one Last Name at a time. Here is the graphic representation of the fact and its behavior:

Figure 6: A fact

The arrow over the Person side of the role box enforces the rule, 'Person can only play in this fact once', while the Last Name side of the role box is open allowing any Last Name to play this role repeatedly. The conceptual model insists that the behavior of Person and Last Name are still intact and the 'fact' is a new object that also has behavior that must remain intact as we go forward. The current behavior also allows a Person without a Last Name to be entered. Here is an example of a change to the 'fact': Each Person must have a Last Name.

Figure 7: The fact in Figure 5 with an additional rule

Here we see a 'dot' on the role connect between person and the remainder of the fact -- this enforces the rule, "Each person must has a Last Name". The behavior is now different for Person: no Person can be added to the system without a Last Name. In addition, no Last Name can be totally removed from a Person (changed yes, but not removed).

Repeat as needed, about 1000 to 2000 times for a large model (if you are lucky, under 500 times).

This could go on but, as I have always wanted to write, I leave the rest for the reader. Here is the model for the facts provided above:

Figure 8: The whole UoD

Notice that Date is used twice. Once the object exists there is no need to make it exist again. I might like a clone of myself, but probably no one else would. The Date merely plays two different roles. This is useful since Date can always be the same throughout the model.

Conclusion

If you want to have more fun, go to Borders, or your favorite bookstore. Head to the Philosophy section and get some books on "objects", "things", and "references". This has been an interesting puzzle for mankind for many years. Remember that the minimum amount to spend is greater than $200 per trip or else they take down your picture from behind the counter. [Editor's Note: Those of you in the vicinity of the Border's in York, PA will find two such pictures, of the author and myself, prominently displayed under the sign "Customers of the Decade". Mention our names and they will probably assign you a personal shopper who will follow you around and hold your purchases while you spend your paycheck.] Then, find a spot by the fireplace, start the music that improves your mind -- they actually sell it that way now -- and enjoy.

Remember, when it comes to building blocks small is better.

Patrick Hallock is a Senior Partner and Principal Consultant for InConcept. He has over 20 years of ORM/NIAM experience and is  a certified ORM consultant, trainer/train the trainer and a certified Visio trainer.

Contact Information:

Patrick Hallock
President and Co-Founder
InConcept
8171 Hidden Bay Trail N
Lake Elmo, MN 55042
path@inconcept.com
(651) 777-8484
fax: (651) 777-9634
http://www.inconcept.com

© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement.
ISSN: 1533-3825