Intro to Graph Databases Episode #3 – Property Graph Model
Articles,  Blog

Intro to Graph Databases Episode #3 – Property Graph Model


Hello, my name is Ryan Boyd and this is your
Intro to Graph Databases series, episode three on graph modeling. The first question you
probably have when talking about graph modeling is, what does a graph look like? Well, this
is very simple. A graph looks like the real world. We like to say with Neo4j and graph
databases that the whiteboard model is the physical model. When your business folks gather
in a conference room, the same thing that they draw up on the whiteboard to represent
your business objects is the exact same thing that a developer codes in the application,
and the same way that the data is stored in the underlying database on disc. This lack
of translation friction between the different parties here makes it a lot faster to build
your applications, and a lot easier to maintain them. So let’s start off with a very simple
relationship. Let’s say that we have Ann loves Dan. In this case, we actually have two nodes.
We have a node representing Ann and a node representing Dan. And we have the loves relationship
in between the two. Now, relationships are directional. So when Ann loves Dan, if Ann
is lucky enough, Dan loves Ann back. And because this isn’t always true, we would likely represent
this as two separate relationships. One for Ann loving Dan and one for Dan loving Ann.
We’ll talk later about the case where the relationships are always bidirectional, and
how you might want to represent those. But first, let’s give you a little bit more information
about the property graph. So the property graph is named as such because it allows you
to store properties along with your nodes and relationships. Let’s start off with a
simple graph that we already did where we have Ann loving Dan and Dan loving Ann. We
can easily, on the fly, add a new relationship. So Ann lives with Dan. We can add this relationship
quite easily because Neo4j is schema optional. You can easily adapt to your business in an
agile way to add new relationships and properties. Okay so we have these three relationships.
Now, what’s next? Well, I called it the property graph, so let’s add some properties. In this
case here, we want to represent the name of Ann and the name of Dan in addition to their
birth date. But you can see here we have a third property on Ann, which is her Twitter
handle. This property only exists on Ann and that’s fine. You can have a property just
existing on a single node. Now let’s show you how we add an additional relationship
and an additional node. In this case here, we want to represent that Dan owns this car,
and we can represent some properties on this car as well, like the make and the model.
Now what happens if we want some additional relationships? Well, we easily just add them.
In this case, we add the relationship that Ann drives this car and Dan also drives this
car. But these relationships can have properties as well, so we can add a very simple property
as to when Dan started owning the car and when Ann started driving the car. All right.
Well, that is a very simple property graph for you. You have the nodes, you have the
relationships and you have the properties on both the nodes and the relationships. We
also call it a labeled property graph for a reason, because we can have labels on each
of our nodes. These labels are kind of like types. It allows you to indicate what type
of node we are representing. So in this case here, Dan and Ann are both person nodes, and
Dan also has this car that we’re going to call a car node. But we can also add a more
generic label to the car that is a vehicle. So in the case of multiple different types
of vehicles you might have trucks, or cars, or boats, and you might put all of those with
the label vehicle in addition to having their more specific label. We’ve reviewed now our
nodes, our relationships, the properties on each of the nodes and relationships, as well
as the labels on the nodes. Now how does this map to the English language? Well, quite easily.
We like to say that you’re representing the real world with your graph model. And because
you’re representing the real world you can use the English language – or whatever other
spoken language that you have – to talk about these objects. So in this case here, we have
our nodes and those nodes are the nouns in our language. Very simple here. And then we
have our properties. And those properties are the adjectives that describe those nouns.
And then we have our relationships. Those relationships are our verbs. And then we have
the properties on the relationships, and those are our adverbs. This is a quite simple way
to think about how you should model your data. Is making sure as you walk the graph, as you
traverse the graph that you’ve modeled, can you speak about it using either the English
language or the language of your choice? Now I’m going to give you a very basic tutorial
on using Cypher with this graph. Now Cypher, if you remember from the earlier videos, is
our declarative query language which you used to work with the graph. You can use Cypher
both for creating things in the graph, as well as for querying them. Now let’s give
you an example. Let’s say that we wanted to create this data that represents that Ann
loves Dan. This is quite a simple Cypher statement. We simply say create, and we say the label
of our node – in this case it is a person-labeled node. And we say the property – sort of like
in JSON syntax – in this case, name is Ann. And then we say that that node loves another
node – a person whose name is Dan. It’s very simple to create this in one single line of
Cypher. Now if we did want to represent bidirectionality; if we had something like a Facebook friend
relationship, where if you know– a Facebook friend relationship always exists in both
directions. In that case, we’d probably represent it in the graph, just in a single direction,
as – in this case – Ann FB friends Dan. And that is just indicating perhaps that Ann was
the one that initiated the friend request. Now we can match that relationship just in
that direction by saying person name is Ann, arrow FB friends, another arrow, the person
whose name is Dan. And you can notice here that Cypher uses what we call ASCII art for
graphs. You’re literally drawing the pattern of the graph in your query through ASCII characters,
like the greater than symbol. But what if we want to find the relationships, regardless
of who initiated the relationship? We just want to find all people who are friends in
our graph. Well, you can easily do that by omitting the greater than symbol. By omitting
the directionality of the relationship when querying the data. So the relationship always
has to exist in a specific direction when you create it in Cypher, but when you query
it, you can match regardless of the direction. Well, that’s all for today. Thank you very
much for enjoying this episode three of the Intro to Graph Databases series. Up next,
we’re going to go into some more detail about graphs and how, perhaps, they map to your
existing knowledge about relational databases. Thank you very much, and have a fantastic
day.

17 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *