Object-Role Modeling is a type of graphical conceptual modelling that is semantically rich. Object-Role Modeling is arguably the most semantically expressive conceptual modelling language available. Being semantically verbose, it is easy to translate ORM diagrams into Entity Relationship Diagram or Property Graph Schemas, but not so easy to go the other way.
An Object-Role Model in Boston
Indeed it is impossible to express some things in ERD and PGS diagrams, for which expressing them in ORM is standard practice. In logical terms, it is easy to map an injection or surjection from ORM to other modelling languages, but (in many cases) 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 more expressive than most other conceptual modelling languages, both from a natural business 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 who know quality when they see it.
This does not detract from the utility of ERDs/PGS’, but merely asserts the utility of ORM.
FactEngine believes that languages like Entity-Relationship Diagramming and Property Graph Schemas are important from a broader utility perspective; because more people understand them and can easily relate to them. For instance, it is undeniable that ERDs and PGS diagrams map directly to widely used database structures (relational and graph databases).
We also believe that ORM is 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). Modern multi-model databases (e.g. SQL Server 2017) require modelling of relational and graph models. Boston allows you to model for either or both at the same time.
When you learn ORM, you can model for relational databases, object-relational databases, and graph databases, all within one modelling language.
A simple example will demonstrate the utility of working with ORM that cannot be done in nearly all other conceptual modelling languages.
Take the following conceptual model, expressed as a Property Graph Schema.
NB In the 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:
"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"
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:
Subset Constraint Symbol in ORM
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.
Verbalisations in Boston
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.
NB The original version of the model expressed in this article is copyright to DataConstellation and is shared under the ActiveFacts project on GitHub: https://github.com/cjheath/activefacts