Object-Role Modeling
Object-Role Modeling (ORM) is a type of conceptual modelling that helps to capture the essential semantics of a domain and represent it in a clear and concise manner. Object-Role Modeling is arguably the most semantically expressive conceptual modelling language available and is a type of Fact-Based Modelling.
ORM offers a number of benefits, including the ability to clearly express data structures, improve communication between stakeholders, better understand business rules and requirements, and improve data quality. 
An Object-Role Model in Boston
Being semantically verbose, it is easy to translate ORM diagrams into natural business language statements that are easily ratified by stakeholders.
For instance, quality ORM software, such as FactEngine's Boston, provides a Glossary View of your conceptual model providing a natural language verbalisation of each of the constraints of the data structure captured in the conceptual model (as below). An ORM model is interpreted as a structure that satisfies a set of constraints, and the structure and constraints can be expressed in formal business language.
Read more about natural language and formal logic.
Entity Relationship Diagram (ERD) or Property Graph Schemas (PGS) may also be extracted as views of an Object-Role Model. Object-Role Models become important when 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.
Fact-Based Modelling and ORM
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).
Object-Role Modeling is important from the perspective of modelling professionals who want the best that there is when it comes to conceptual modelling.
Multi-Model Databases
When the world is moving towards embracing Relational Knowledge Graphs and Multi-Model Databases that incorporate Relational Models (adequately served by ER Diagrams) and Graph Models (adequately served by Property-Graph Schemas), FactEngine feels it is pointless trying to dominate mind-share with one language or another. This, especially when ORM diagrams can easily be viewed as ERD or PGS diagrams.
Object-Role Modeling and FactEngine's Boston conceptual modelling tool allow you to model in any of ORM, ERD and PGS at the same time, exploiting the underlying potential of ORM. For example, modern multi-model databases such as SQL Server 2017 require modelling of relational and graph models.
When you learn ORM, you can model for relational databases, object-relational databases, and graph databases, all within one modelling language.
Example
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:
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.
ORM Verbalisations in the Boston Conceptual Modelling Software
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