Object Role Modelling

Posted by Optimation Editor on 30 May 2013

In preparation for a consulting assignment I’m about to begin, I’ve been reading up and refreshing myself on the techniques available out there for modelling information. One of those techniques is one I first came across a few years ago called Object Role Modelling and in the intervening time, it seems to have become more widely accepted.

Object Role Modelling (ORM) is a technique for conceptual data modelling and takes a more granular and more expressive way of modelling information than more traditional techniques such as ER modelling or UML Class diagrams. Below is an example of what an ORM diagram looks like:

This particular diagram has been taken from an example on the ORM Foundation website (http://www.ormfoundation.org) - a very good place to start if you’re looking for tools or information on this technique. On first glance it doesn’t look hugely different to an ER diagram, but there are some significant differences.

The first one is that the concept of an entity has been replaced with the concept of a ‘fact type’. In the diagram above these are the Employee, Agency, Office etc and they are linked to one another via roles. For example in the diagram above, an Employee works at an Agency and reading it the other way, an Agency employs an Employee. Agency & Employee are the fact types and ‘works at/employs’ represents the roles each fact plays in the relationship.

The really important thing that this type of modelling allows you to do is to focus on the concepts and relationships without getting tied up with what is an entity and what is an attribute/column. You begin by focusing on fact types and the role they play in their relationship to one another and because you’re not bound by what is an entity and what isn’t, you can focus on modelling the concepts.

If you do decide that a fact will ultimately be represented as an attribute, you can change it to a dashed line. In the diagram above, ‘Name’ is a good example of this as it is related to an Agency, but it is ultimately a value associated with the Agency fact type.

Another important difference from traditional ER diagrams is that ORM diagrams can be easily turned into structured english sentences, that accurately describe the facts, relationships and the roles being played across the model. This is something that is much more difficult to achieve in ER diagrams, especially when you start adding constraints and rules into the mix. The ability to easily translate the diagram into english means that you have another way of communicating with your audience - especially the business oriented part of your audience.

In fact business rules and the ability to describe these in a structured manner is where ORM really comes into it’s own. Because you are modelling at a more granular level and have a rich set of modelling constructs to choose from that allow you to describe constraints as well as relationships, you can use ORM as the basis for collecting business rules in a structured manner.

If you’re involved in modelling information and data, it would be well worth your while taking a look at the wealth of information that now exists on ORM, Microsoft is well behind this approach now and as a modelling technique it has some very definite advantages over ER or Class diagrams when working at the conceptual stage of modelling.