Why learn Object-Role Modeling — Part II
Object-Role Modeling is a type of conceptual modelling that is semantically verbose, capturing a wide range of semantic information and constraints.
In an earlier article I wrote about some of the key reasons why you would want to learn Object-Role Modeling (ORM). That article focused on the semantic richness of ORM and the benefit of the constraints ORM supports.
The level of detail in an Object-Role Modeling is informative and daunting at the same time. You might well ask yourself why you would want to capture so much information within your domain model.
As an example, let us look at the following Object-Role Model:
The ORM diagram above captures the type of information we might store for each Lecturer as part of a larger model that ranges over an information system for a university.
Contrast the ORM diagram with similar information captured in an Entity Relationship Diagram:
The information in the ORM diagram speaks of things like “Lecturer has EmailAddress”. This might, on the face of it, seem like overkill, as it may be intuitively easy enough to look at a Lecturer entity in an Entity Relationship Diagram and surmise that the attribute, EmailAddress, is something that the lecturer has.
While that may be true, there are three benefits to having extra information at your fingertips in an ORM diagram.
- You can generate the ER Diagram from the ORM diagram;
- You will not easily forget what the relationship between Lecturer and EmailAddress is within your model; and
- You can perform natural language queries over your database based on the semantic richness of your ORM model:
Mapping the has relationship in Lecturer has EmailAddress lets us understand that EmailAddress on our corresponding Entity Relationship Diagram does not mean Lecturer once had EmailAddress, or such like.
So the benefits are multi-fold.
The same can be said for Property Graph Schemas, as for Entity Relationship Diagrams. They do not contain the level of granularity required to be truly informative about what the schema speaks of:
Even where a property graph schema does show property information for nodes, the information dearth is palpable.
I am the first to say that ER Diagrams and Property Graph Schemas are easier to look at than ORM diagrams, but putting in the extra work of an ORM diagram allows you to generate the ER Diagrams and Property Graph Schemas…so do the hard work once and enjoy the benefits.
A Natural Affiliation with Graph Schemas and Graph Queries
Object-Role Models have a natural affiliation with Property Graph Schemas and make it easy to query a database with graph queries in natural language.
Indeed, when you range an Object-Role Model over your database you can envisage and treat your database as a graph database regardless of whether it is a relational database, a multi-model database, a key/value store or hierarchical database. Object-Role Modeling is database agnostic.
These are key reasons why I believe that Object-Role Modeling is a powerful tool in your arsenal as a data architect, data scientist, business intelligence professional or as a business analyst who needs to communicate with others about your schema.
- Business analysts and data architects can capture the model in Object-Role Modelling.
- Engineers can create the database as a graph/relational/hierarchical/multi-model/document store database.
- Data scientists and business intelligence analysts can query the database in natural language.
With Object-Role Modeling you do the hard work once, and then make life easy by converting your ORM model to the desire of your stakeholder. Sometimes you do not even know who your ultimate stakeholder is until after you have prepared your model…how better to prepare for the unexpected?
Thank you for reading. I hope this is helpful in deciding over learning Object-Role Modeling as a transferable skill. As time permits I will write more on ORM and natural language/graph-based queries based on an Object-Role Modeling architecture.
========================================
