Relational Graphs — Pt1

Redefining the Relational Database and its DDL

Victor Morgante
5 min readMay 29


FactEngine’s mission is to radically change how people envision databases and knowledge graphs. Every database can be viewed as either a graph or relational database and FactEngine exploits this.

FactEngine pioneered this notion with the release of the Boston multi-model conceptual modelling software:

Click to enlarge — Interlinked/Morphing Multi-Model Conceptual Modelling. Image by author.

Relational Graphs / Graph Relational Databases

The vision is expanded to develop software and standards that can be applied to any relational database to treat that database as if it were a graph database.

How? By putting money where our mouth is.

Here’s a video of using an SQLite relational database as if it were a graph database:

Going One Step Further — Redefining DDL for Relational Databases

For relational databases to recover market share, vendors need to radical ly rethink how relational databases are defined at the metamodel level.

For instance, a simple internet search will show that there are at least two projects to convert graph-based Cypher (and/or OpenCypher) queries to operate over a relational database with SQL.

FactEngine believes this should be standard for any database. All databases should include SQL and the likes of OpenCypher.

What FactEngine proposes is that the Database Definition Language (DDL) for relational databases be redefined such that the predicates and/or labels that would otherwise conceptually make the relational database a graph database be defined along with the table/column definition.

This means no special graph-included-SQL-language…databases support both SQL and languages like OpenCypher. Much as you can have a JDBC driver over Neo4j….future databases will support SQL and OpenCypher.



Victor Morgante

@FactEngine_AI. Manager, Architect, Data Scientist, Researcher at