Data modeling in Neo4j - Neo4j in Action - page 39

You've seen labels used in the Cypher query examples given in this chapter: an expression
like (u:User) matches a node with the User label, and it will ignore any other nodes.
Ultimatelywhatshoulddecidetherepresentationyou'regoingtouseistheeasewithwhich
the patterns it contains can be queried and traversed. If it's difficult to see how two pieces
of information are connected, but in reality their relationship is very straightforward, then
consider linking them more directly in your graph. If you have nodes whose only purpose
is to hold pieces of information belonging to other entities, consider moving that informa-
tion into a property on that entity.
Don't be too worried, at this stage, about finding the right model. It's easy to refactor
graphs using Cypher later on, to make explicit relationships that are only implicit in your
currentmodel.There'snosuchthingasanormalformforagraphdatabase—onlytheform
that best suits your application.
2.3. Further examples
We'll conclude this chapter with a couple of examples from different domains, both to il-
lustrate the range of situations that can be modeled in Neo4j and to illustrate two pairs of
opposing concepts: whether elements in the model are represented implicitly or explicitly
in the graph, and whether data is generally invariant or variable .
To begin, let's revisit the underground stations example mentioned earlier.
2.3.1. Underground stations example
Our first example deals with the question of when you should model a particular aspect
of your data explicitly , representing that aspect directly using nodes and relationships, and
when you should allow that aspect to remain implicit in the data (but recoverable through
querying). In this example, we'll model the stations, lines, and connections in the London
underground system. We're interested in two things: which stations are directly connected
to each other, and which stations are on which lines.