Object-Role Modelling (ORM) is a semantic conceptual modelling language designed for high-fidelity data/ontology modelling.
Unfortunately, over the last 40 years, ORM has garnered little traction in the ITC sector; with people preferring to use methodologies like Entity-Relationship Diagrams, Property-Graph Schemas and UML (Unified Modelling Language) Class Diagrams.
I propose that that state is because it is easier to communicate ideas with other people using the latter.
That is why we developed Boston; conceptual modelling software that lets you create conceptual models as Object-Role Models and easily translate those models into Entity-Relationship Diagrams and Property-Graph Schemas.
Natural questions to ask are, “Why learn Object-Role Modelling at all? Why do the model in ORM first?”
The reasons for that are varied, but the most useful answer is that ORM is more semantically expressive than nearly all other conceptual modelling languages in existence today. Being more semantically verbose, it is easy to translate ORM diagrams into ERD or PGS diagrams, but not so easy to go the other way. Indeed it is impossible to express some things in ERD and PGS diagrams, but standard practice in ORM.
In logical terms, it is easy to map an injection or surjection from ORM to other modelling languages, but impossible the other way around.
ORM is a type of Fact-Based Modelling (FBM), a family of conceptual modelling languages which includes FCO-IM (popular in the Netherlands, the home of logic).
FBM languages are simply more expressive than other conceptual modelling languages, both from a natural language and logic-based perspectives.
In layman terms, you can do much more with ORM than you can with other modelling languages, and that is why ORM and other Fact-Based Modelling languages are popular with conceptual modelling professionals.
This does not detract from the utility of ERDs/PGS’, which I acknowledge heartily, but merely asserts the utility of ORM.
At Viev (www.viev.com), we believe that languages like Entity-Relationship Diagramming and Property-Graph Schemas are more important from a utility perspective; because more people understand them and can easily relate to them. We also believe that ORM is more important from the perspective of modelling professionals who want the best that there is when it comes to conceptual modelling.
We feel that it is pointless trying to dominate mind-share with one language or another, when the world is moving towards embracing Multi-Model Databases that incorporate Relational Models (adequately served by ER Diagrams) and Graph Models (adequately served by Property-Graph Schemas).
It just so happens that if you learn ORM, you can model for relational databases, object-relational databases, and graph databases, all within one modelling language.
That is why we feel it important to learn Object-Role Modelling.
A simple example of what I am talking about will demonstrate the kind of thing you can do in ORM that you cannot do in nearly all other conceptual modelling languages.
Take the following conceptual model, expressed as a Property-Graph Schema. NB In our Boston modelling software, you [Control]-Click on a Node Type to see its properties.
The model is of a Universe-of-Discourse (UoD) where we are looking at a seat-booking facility for a cinema.
The cinema has rows of seats (in sections) and sessions when films are shown at the cinema. A person can book one or more seats at the cinema, so that they can go and watch the film booked (within a session).
The same model is displayed below as an Entity-Relationship Diagram:
Important information is missing from both the PGS and ERD models, and that is a constraint that says:
i.e. It is pointless booking a seat at a cinema that is not showing the film that the person wants to watch (within a session).
This constraint is trivially created within an ORM diagram as a Subset Constraint (shown by the subset constraint symbol: ).
The corresponding ORM diagram is shown below.
We believe that any reasonable person would say that the Property-Graph Schema is the easiest to visualise (in terms of the concepts analysed). Next in line is the Entity-Relationship Diagram. But neither the PGS or ERD can capture the critical constraint that “If some booking has some seat, then that booking is for some session that is at some cinema that contains some row that contains that seat”.
Such critical constraints can save valuable time when developing and testing an IT system to serve our booking requirements for the cinema.
Because ORM is based on natural language and a specialised predicate logic, and while the diagram is useful, clicking on the constraint and letting ORM-based software express the meaning of the constraint in natural language is priceless.
Business analysts can develop models in ORM and have the requirements of a system expressed in natural language.
Subset Constraints are one of eight different constraints that can be expressed in ORM. Some constraints in ORM have many variants, and which cover a wide range of scenarios, beyond the eight primary types.
The example provided in this article gives an idea of why it is that you may like to learn Object-Role Modelling. With software like Boston, your desire to express models as Property-Graph Schemas or Entity-Relationship Diagrams is respected, and if you are working with a multi-model database, Boston is designed expressly for your needs.
I hope this has been helpful. As time permits I will write more articles on ORM, ERDs and PGS’.
NB The original version of the model expressed in this article is copyright to DataConstellation and is shared under the ActiveFacts project on GitHub: