Database Reference
In-Depth Information
Chapter 2. Data modeling in Neo4j
This chapter covers
• Why we need a data model for Neo4j
• Domain modeling
• Exploring additional domains
In this chapter, we're going to talk about how and why we model data in Neo4j, and discuss
approaches to data modeling in a graph database. We'll look at alternative ways to model a
given domain, making use of nodes, relationships, properties and labels in different ways.
We'll also present examples from different domains to give a sense of how flexible data
modeling in Neo4j can be.
We'll look at queries written in the Cypher query language. These are shown purely for il-
lustration,togiveanideaofhowsimpleitistoquerythemodelsshownhere:youdon'tneed
to know anything about Cypher to start modeling data, and the language will be introduced
in more detail later on.
2.1. What is a data model for Neo4j?
Unlike a traditional RDBMS (relational database management system), Neo4j is a
schema-
less
database. You don't need to define tables and relationships before you can start adding
data. A node can have any properties you like, and any node can be related to any other
node. The data model for a Neo4j database is implicit in the data it contains, rather than ex-
plicitly defined as part of the database itself. It's a description of what you want to put in
yourdatabase, ratherthanasetofprescriptions enforcedbythedatabase thatconstrain what
it will accept.
Because Neo4j data modeling is descriptive rather than prescriptive, it's easy to make
changes when your application's view of the world expands or alters. But it's also useful
to have a consistent description of the data the database will contain, so that you can frame
queriesintheexpectationthatsimilarentitieswillberepresentedinsimilarways.TheNeo4j
querylanguage,Cypher,worksbymatchingpatternsinthedata,soonewaytoseeyourdata
model is as an inventory of basic patterns. For example,
