The first Object-Role Modeling hypergraph database
Version 5.5 of the Boston Object-Role Modeling conceptual modelling tool marks the first time a database can be created, modified and queried over using Object-Role Modeling and a hypergraph query language.
Object-Role Modeling (ORM) was first formalised as a conceptual modelling language for database analysis and design in 1989 as output of Terry Halpin’s doctoral thesis. Originally called Niam (Natural-language Information Analysis Method), ORM was viewed as a separate from but necessary for the manifestation of a well structured database. When Halpin moved to Microsoft to work with their database teams in the 1990s, there was a glimmer of hope that ORM would make its way into SQL Server. This did not eventuate.
Now in 2021 we can say that ORM has found its way into a database product.
Boston was first released in 2015 as an ORM conceptual modelling tool and in 2018 supported automatic generation of Entity-Relationship Diagrams (for relational databases) and Property Graph Schemas for graph databases. Boston, incorporating FactEngine, now supports the creation, modification and querying of a database as a hypergraph/graph database, using the automatic relational/graph schema generation to manage the metamodel ranging over the database, as a hypergraph.
32 years after its advent, ORM has now moved from a conceptual modelling language to having been integrated into a database product. Many databases support a visual conceptual modelling language, now you can create your conceptual model using Object-Role Modeling.
Why has it taken so long?
Object-Role Modeling is a verbose conceptual modelling language. With insight into the efforts of other teams, and in writing Boston, it takes 10 man years effort to create a useful Object-Role Modeling tool. Boston, at last count, is close to 300,000 lines of code. This is an extraordinary amount of code, and so vendors would need to either assign someone to the task for 10 years, or successfully guide a team of 10 people for a year to produce a decent Object-Role Modeling software.
So the time to market is a product of the effort required and the commercial realities of actually getting a product to market.
The first Object-Role Modeling database…is over SQLite
For the first Object-Role Modeling database I chose SQLite as the database engine to act as a hypergraph. The FactEngine/Boston architecture is generic, so that it can operate over any database engine, but SQLite was chosen as the first because:
- SQLite is the most widely used database in the world;
- SQLite supports recursive queries for graph based queries.
- Customers, students and researchers can be up and running in no time at all with no server to set up. SQLite is embeddable.
Object-Role Modeling Database Architecture
In an earlier article I introduced the FactEngine architecture, also described pictorially below. In essence, the first Object-Role Modeling database is a two-layer metamodel database, with a knowledge representation layer in Object-Role Modeling as a metamodel over the metamodel of the database within the database management system.
And that is it, what was once a dream is now reality. As the project moves forward the database will implement more of ORM’s constraints and the query language will mature.
The Query Language
FactEngine uses a graph based query language, which looks like the following:
Hypergraphs and Object-Role Modeling
You can read more about Object-Role Modeling and hypergraphs here.
The Theory behind Boston and the FactEngine
Because Object-Role Models have a tightly coupled homomorphism with Entity-Relationship Diagrams and Property Graph Schemas, it is conceptually trivial to associate an Object-Role Model with an extant physical database. Boston exploits this to now being able to create and modify the database as the Object-Role Model is manipulated within Boston.
Thank you for reading. As time permits I will write more on using Boston and FactEngine as a database in its own right, and more on hypergraph databases and hypergraph queries in FactEngine Query Language.
— — — — — — — -End — — — — — — — — — — — — — — — — — -