Object Role Model (ORM) Diagrams: An Agile Introduction
ORM diagrams, thoroughly described in Information Modeling and Relational Databases and at www.orm.net, are in my opinion an incredibly effective way to explore domain concepts with your stakeholders. An ORM diagram depicts objects (entity types), the relationships (fact types) between them, the roles that the objects play in those relationships, constraints within the problem domain, and optionally examples (called fact type tables). Figure 1 depicts a simple example of an ORM diagram. The ovals represent entity types/objects and the rectangles roles that the objects play in relationships. Notice how the roles are described in both directions, in the top relationship the Student is in the takes role and Seminar is in the is taken by role. The double arrowhead above the roles indicates uniqueness constraints. Because the arrowhead is above both the takes/is taken by roles it indicates that the combination of student/seminar must be unique in this relationship – a student can take many seminars and a seminar is taken by many students, but a student can take a given seminar once and once only. Consider the other relationship. In this case the double arrowhead is only above the assisted by role, indicating that a seminar may only appear once in the fact type table (in other words this is a one-to-many relationship). As you can see in the fact table each seminar appears once yet Sally Jones appears twice – there’s no uniqueness constraint over the assists role so this is allowed. Had there been individual arrowheads over each role this would model a one-to-one relationship because each object could only appear at most once in each role. Where there are no arrowheads at all above the roles that indicates an unrestricted many-to-many relationship (e.g. a student could take the same seminar several times).In Figure 1 each object has an attribute listed in the oval – name for Student and number for Seminar – indicating the example information listed in the fact type tables immediately below the roles. This style of ORM diagram is often referred to as a knowledgebase diagram although for the sake of simplicity I don’t bother to differentiate between various styles of ORM diagrams. Knowledgebases are used to provide examples of the relationships that the entity types experience when they are fulfilling the given roles, enabling you to easily and explicitly explore the relationship with your stakeholders. I will often draw a knowledgebase when the relationship isn’t clear, particularly when we’re trying to explore the multiplicity of the relationship.Figure 1. Simple ORM Diagram. Figure 2 presents a more complex example. It doesn’t include fact type tables and as a result explores a wider range of concepts – you can only fit so much on a white board, and AM recommends that you Model in Small Increments regardless. The relationships between Student and Seminar have been fleshed out a bit. The top relationship has evolved from a binary relationship to a ternary relationship which involves three entity types (Mark was added). It is possible to model n-ary relationships on ORM diagrams simply by adding more roles to the relationship although I rarely find the need to do so. You see that there is an exclusive or (XOR) relationship, depicted by the dotted circle with the X through it, between the takes role and the assists role, indicating that a student can either take a seminar or they can assist it but not both. A dotted circle without the X would indicate a simple OR relationship.Figure 2. More complex ORM Diagram.
You see that there is a large black dot on the line between Professor and the teaches role, indicating that it is mandatory for a professor to teach a seminar. The dot can appear at either end of the line, although I prefer to place it on the object end (sometimes an object will be involved in many mandatory relationships which can clutter your object symbols so it’s good to have the option to move the dot to the other end of the line).The dashed oval represents an attribute of an object, showing a more detailed way to represent the concept that seminars have seminar numbers than the short form that we used in Figure 1. I prefer to follow the Depict Models Simply practice and use the short form but I wanted to provide an example of the long form for you.Another interesting concept is the recursive/self relationship that Professor is involved with. One professor may mentor other professors and a professor may be junior to several professors that mentor her.How do you remain agile when working with ORM diagrams? I prefer to use ORM diagrams with my stakeholders, modeling around a whiteboard with them in order to explore the problem domain. Although the notation is rather complex I’ve found that stakeholders quickly pick up the basics, particularly when fact tables are used frequently at the beginning. Once we understand the issue that we’re exploring with an ORM diagram I typically capture the information in another artifact, such as a UML class diagram or source code, and erase the diagram once I’m through with it.
