Month Year Issue

August 2001 Issue: 21

Journal of Conceptual Modeling
www.inconcept.com/jcm

Creating Conceptual Source Components
by Patrick Hallock

Introduction

One of the major features of a conceptual model is the ability to ignore the entity versus attribute decision. The model consists of objects related to objects at the elementary level. These objects only need to exist once in the enterprise definition. This relationship is known as a fact - a statement that something is true within the model. When you get tired of recreating these relationships over and over for each model you wish, you could shortcut the approach and create reusable data components. These are sometimes offered in subject areas or at least fairly large, complete groupings.

The upcoming version of Microsoft Visual Studio .NET (Enterprise Architect edition) includes the new version of Visio and the newer ORM software. (After three years of waiting we now have a revised set of software!) One of the features is the ability to create many source documents. Each source document can be either an ORM model or an ER model or a combination of both. This article focuses on using ORM source documents to model reusable components. This article is short and simple, but it demonstrates the idea.

Conceptual Source Components

Object Role Modeling (ORM) includes the concept of co-referencing. This is used when an object has a complex identification scheme. An example is a room where it is identified by the combination of a floor number and a room number (e.g. room 321 is actually floor 3 and room 21).

As another example, suppose that a Person Name is composed of Last Name, Middle Name and Last Name. When using the component name in any ORM model, the associated roles are automatically included. Note, that the primary identifier of the component is everything within the component. Last Name and First Name are mandatory, while the Middle Name is optional. This behavior is also inherited by any fact including Person Name. The Fact Employee includes Person Name will produce a logical model that includes all parts of the Person Name (see the ORM and logical models, below).

The shaded Person Name object is not the result of using a component. The definition of Person Name is in one source model and the definition of Employee is in a second source model. When the Employee model required the Person Name it was declared external, which means the mapping routine looks for the source definition of Person Name, and then created the mapping. The resulting logical model shows the result of the mapping. Note that the names within the logical model were not mapped to a naming convention so the reader can see the full text definition of the result and compare that to the reading of the ORM model.

As a side note: Handling the component name can be awkward. In the above logical model you see some very long names. The component name "Person Name" is added to every column. In order to eliminate this issue, try using the name of "Person_Name" in the component name. Then, in the abbreviation list indicate that "Person_Name" is abbreviated by nothing (i.e. blank). Then when the mapping is done the component name will not appear as part of the column name. I have also used a name of "c_Person_Name" instead and abbreviated that to blank. However, this isn't nicely conceptual, so I went back to the first option.

Using the Room source model in two different roles: Person is located in Room and Department is located in Room, shows the same source model being used many times in the same requesting source model.

Below is a variation on the room model, which can be kept as a different source document. Either variation is available for a specific modeling purpose. Thus, you could create several different definitions of the same concept such that you can choose which one is sufficient for the specific universe of discourse (UoD) that you are modeling. For example, in one UoD a Room may only require the room number and the floor. In another UoD, building name may also be required.

This is a very short presentation on the idea, but the ability to create components as source documents, to have variations on a concept, and these components can be as small as shown or can be entire subject areas means there is the ability to create models from reusable source documents. Such source documents are something that can be shared between databases within the same or different enterprises. Maybe one modeler's source document with a few changes is readily useful to another modeler. The conceptual model source document is as useful as many other shareable resource formats.

Does anybody need a model on Time Interval? If someone created this as a document and put that out on the web, well who knows?

I just got tired of putting start date, end date and a derived elapsed number of days on too many models, actually many times on a single model as well. Note that "has elapsed" is a derived fact and is not stored.

Conclusion

Modelers need a few very basic ideas.

Only create an object once, with a single definition.
Give the object roles to play - context.
Determine the rules, or behavior, of each fact.
Determine the rules between facts.
Only declare the fact and its behavior once.
Group facts into components.
Group components and other facts into subject areas.
Group all this into the model.
Reuse components between models using a set of source documents.

Source documents permit the modeler to create several reusable conceptual models, even variations on a model, and assign them to the logical models whenever required. These ORM source documents are something that is exchangeable between modelers. If one modeler receives a model at the conceptual, the modeler can then modify the conceptual model for their purpose without having to start from scratch.

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