Property Graph Schema…n-to-n

Part of The Future of Graph Databases Series — Pt. 1

Victor Morgante

--

Property Graph Schema. Image by author.

My business, FactEngine, makes a software tool for the development of Property Graph Schema (PGS) for the design of graph databases, and I have a vested interest in the future of graph databases.

One of the biggest problems with current trends in Property Graph Schema development is the lack of standards and especially when it comes to expressing many-to-many relationships.

Take the schema above, for example. An industry standard (?) PGS, it uses directed graphs, where each edge is represented by a directed arrow, supposedly indicating either ownership, the primary use case, how the database should store the data, an even how you should query the database.

Putting aside the lack of attempt at formal semantics and that every relationship is otherwise a binary relationship, a current-standard PGS lacks the ability to inform of whether any of the relationships/edges represent a many-to-many relationship.

The schema above is for a cinema booking database, where information is stored on how people can make a booking for one or more seats to watch a film in a session at that cinema.

The problem arises when we consider the directed graph edge between the Booking node type and the Seat node type. Is a booking for one seat or many? The current standard would express something blithe and along the lines of “Well, most graph databases are schemaless so you’ll have to put whatever rule you choose in the code that operates over the database.”

So on the one hand you have the notion of a Property Graph Schema, easily looked up on your favourite search engine…returning many resulting images, operating over something which is effectively schemaless. Surely this is a paradox not lost on business analysts, IT professionals and in the “we better do something about this” conversations happening behind closed doors of graph database vendors. At least that is a conversation I would be having.

In our example we are equally oblivious as to whether in our database we should store only one film that a person likes, or have a many-to-many relationship where a person can like many films and vice versa.

--

--