As you can probably imagine from the structural differences discussed above, the data models for relational versus graph are very different.
The straightforward graph structure results in much simpler and more expressive data models than those produced using traditional relational or other NoSQL databases.
If you are used to modeling with relational databases, remember the ease and beauty of a well-designed, normalized entity-relationship diagram - a simple, easy-to-understand model you can quickly whiteboard with your colleagues and domain experts.
A graph is exactly that - a clear model of the domain, focused on the use cases you want to efficiently support.
Let’s compare the two data models to show how the structure differs between relational and graph.
Relational - Person and Department tables (click to zoom)
In the above relational example, we search the Person table on the left (potentially millions of rows) to find the user Alice and her person ID of 815. Then, we search the Person-Department table (orange middle table) to locate all the rows that reference Alice’s person ID (815). Once we retrieve the 3 relevant rows, we go to the Department table on the right to search for the actual values of the department IDs (111, 119, 181).
Now we know that Alice is part of the 4Future, P0815, and A42 departments.
Graph - Alice and 3 Departments as nodes (click to zoom)
In the above graph version, we have a single node for Alice with a label of Person.
Alice belongs to 3 different departments, so we create a node for each one and with a label of Department.
To find out which departments Alice belongs to, we would search the graph for Alice’s node, then traverse all of the BELONGS_TO relationships from Alice to find the Department nodes she is connected to.
That’s all we need - a single hop with no lookups involved.
