ORM Basics: Entities, Values, Roles, and Facts

The building blocks of ORM

Object-role modeling is a fantastic tool that allows one to construct incredibly rich and complex information models. Because of this, it can be difficult to identify a starting point to jump in and begin learning ORM. At ProAce, we feel that identifying the primitive building blocks and working our way up is the natural way to begin teaching any new technique. For ORM, these building blocks are the fundamental types: entities, values, roles and facts.

Some definitions

A major function of ORM is to declare facts asserting that objects play roles. Objects can be either entity or value types. For example, if we are talking about data for a music library (such as iTunes) a verbalization of that data may be “The band named X performs the song titled Y”. Now, what are the facts in this sentence? To begin identifying them, it often helps to break the sentence into its most elementary components. In this case we have:

“Band performs Song”
“Band is named X”
“Song has title Y”

And thus we are able to easily identify three facts. How about the objects in each fact? Identifying the objects in a fact is somewhat akin to identifying the subjects in a sentence. So taking the first, we have Band and Song. These two objects participate (i.e. play a role) in the fact “performs.” Likewise we can identify the objects and roles in the last two facts. Summarizing these findings (with objects in bold face):
Band performs Song
Band is named Band Name
Song has title Song Title

Let’s now turn our attention to the objects in this example. Intuitively, it does not seem like these objects are on equal footing. Well, that intuition is correct. The objects Song and Band are what we call entity types, and the objects Band Name and Song Title are called value types. So what’s the difference? Simply put, value types are objects that can be described using a single value. So Band Name may be “The Ramones” or “Uncle Walt’s Amazing Polka Band.” Entity types are not as easily described; for example a Song has a title, date created, author, etc. You can think of entities as being the first class objects in our ORM model, with the values being attributes on these entities. For those readers familiar with Domain-Driven Design (DDD) parlance you may recognize the term entity. Indeed, we will address the relationship between ORM and DDD in future posts.

A simple example

Parsing our sentence

Now that we’ve identified the building blocks of ORM, let’s dive into an example. We’ll start by verbalizing our data and transforming it into an ORM model. Consider the following data:

Student Course
Joe Blow Comp. Lit.
Jane Smith Abstract Algebra

Table 1 : Student data

We will assume for the sake of argument that we already know that this is a list of students and the courses that they are enrolled in at Some University. This is an important point and a necessary requirement before modeling any information. The semantics behind a set of data points are a piece of what is known as the Universe of Discourse (UoD) and are usually acquired from the appropriate Domain Experts. Again, we will save a comparison of ORM and DDD for upcoming posts. For now let’s just take the first row of Table 1 and verbalize it:

The student named Joe Blow is enrolled in the course named Comparative Literature

So far so good. The next step in turning this into an ORM diagram is identifying the entity types in this sentence (bold face):

The Student named Joe Blow is enrolled in the Course named Comparitive Literature

Let’s now generalize the sentence and identify the value types (regular face):

The Student named Student Name is enrolled in the Course named Course Name

And finally we’ll show the facts/roles in the sentence (underlined).

The Student named Student Name is enrolled in the Course named Course Name

OK, it looks like everything is correctly identified in our sentence. How do we now turn this into an ORM diagram?

Drawing it out: Beginning to diagram

Let’s start out with our entities. An entity is drawn using a box with a solid outline and the entity name inside like so:
Entity Type
Figure 1 : Diagramming an entity type

Note the (.id) under they entity name. This is called the reference mode for the entity and roughly speaking, specifies how this type is uniquely identified. However, reference modes are inherently related to uniqueness constraints which are beyond the scope of this article. For now we’ll just accept that entity types include information on how to identify them.

A value type is drawn much the same, except with a dashed outline and no reference type:

Value Type
Figure 2 : Diagramming a value type

Facts are drawn according to the number of objects that play roles in them. For each object’s role in a fact a separate box is drawn. So in the fact “Band Member plays Instrument,” there are two objects playing roles and hence two boxes drawn. In addition, a predicate is added to each fact in order to provide semantics for the roles being played:
Fact Type
Figure 3 : Diagramming a fact type

Note that facts do not have to be confined to two roles (a binary fact), the diagram for a fact type can be generalized to n roles by simply adding boxes. So the fact:

“Student took Test on Date”

Would be diagrammed as:
Ternary Fact
Figure 4 : Diagramming a ternary fact type

With n-ary fact types, ellipses (…) will take the place of objects in that fact’s predicate.

Putting it all together

We now have all the information needed to construct a simple ORM diagram for our example:
orm-diagram
Figure 5 : Diagramming our example

Notice we have a fact type for each of the three identified facts in our original sentence as well as diagrams for our two entity and two value types.

Just the beginning

This article provides a solid foundation with which one may start reading and writing ORM diagrams. However, we’ve only scratched the surface of the power that object-role modeling provides. Next, we will begin digging into the real value of ORM when we start discussing logical constraints.

Questions? Feel free to leave them below in the comments section or email me at jpeace AT proace DOT com.

This entry was posted in Development and tagged , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

7 Comments

  1. John
    Posted March 1, 2010 at 3:06 am | Permalink

    OK this was clear. Object coult be entity or value.
    But how about terms “value object” and “entity object”? It seems to mee that in some cases they are used same way as value type ja entity type.
    And offcoures fact vs fact type?

  2. Posted March 3, 2010 at 1:27 pm | Permalink

    Good point, John. The distinction between objects and types in my mind is that types are the diagram components modeling a given object. Likewise with facts vs. fact types. So when we have a Customer object in our domain (an entity object), we can model it via an entity type in our ORM diagram. Of course, this is not a very rigorous definition and in fact I’m sometimes using the terms interchangeably in this article.

  3. Posted March 3, 2010 at 1:55 pm | Permalink

    @John,

    We must first make the distinction between Domain-Driven Design terminology and Object-Role Modeling terminology. While there are parallels between both, this is one where the differences are quite vast.

    Object Types are broken down into two types: 1) Entity and 2) Value. For sake of simplicity these are modeled with solid lines and dotted lines, respectively.

    Entity types must have reference modes while Value types cannot have them. More simplistic examples of this use single values to identify Entities (i.e., surrogate identifiers) while more complicated usages include “composite identification” (much like a composite primary-key in a database).

    As a side note, composite entities are ideal for modeling Value objects in the Domain-Driven Design world.

  4. John
    Posted March 7, 2010 at 6:43 am | Permalink

    Seems reasonable.
    By the way is ORM meant for static or dynamic modeling? In some cases I have heard also term hybrid modeling – object system is perceived as consisting of discrete actors (or objects) each of which reacts to stimuli and has a limited view of system environment.
    Can we still use ORM for modeling processes? I know that the focus of ORM conceptual modeling is towards data, since it is more stable.

  5. Posted March 9, 2010 at 4:37 pm | Permalink

    @John

    There’s a lot of talk in this particular area (modeling processes) and the role that ORM can play. I know that there was some talk about extending the BPMN spec to support the inclusion of or references to ORM models. However, I don’t think that’s going to make it passed the idea phase.

    Check out the ORM foundation (http://ormfoundation.org) for some more information on this one. I know people have been talking about it for a while now.

  6. John
    Posted March 13, 2010 at 2:06 am | Permalink

    Hey, I could not find an answer there. It seems that ORM is still meant more for static modeling. There has been some attempts for using dynamic rules (log shows that in 2007 they have done some research), but so far without great success.

  7. Posted August 9, 2010 at 3:54 am | Permalink

    I found that ORM is tightly coupled to the Neumont ORM Architect (NORMA) for Visual Studio which is used by far most ORM users to create models. There are plenty of diagram tools for ERM and UML diagrams but ORM is not very common. For this reason I wrote tkz-orm, a LaTeX package to draw ORM diagrams fully based on Free Software – maybe this helps someone.

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>