Databases Reference
In-Depth Information
To illustrate this early model, we'll use Cypher's
CREATE
clause to generate some nodes
representing users and aliases. We'll also generate a relationship that shows that Alice
is one of Bob's known aliases. (We'll assume that the underlying graph database is in‐
dexing these nodes so that we can later look them up and use them as starting points in
our queries.) Here's the Cypher query to create our first graph:
CREATE
(alice {username:
'Alice'
}),
(bob {username:
'Bob'
}),
(charlie {username:
'Charlie'
}),
(davina {username:
'Davina'
}),
(edward {username:
'Edward'
}),
(alice)-[:ALIAS_OF]->(bob)
The resulting graph model makes it easy to observe that
Alice is an alias of Bob
, as we
see in
Figure 3-7
.
Figure 3-7. Users and aliases
Now we join the users together through the emails they've exchanged:
START
bob=
node
:user(username=
'Bob'
),
charlie=
node
:user(username=
'Charlie'
),
davina=
node
:user(username=
'Davina'
),
edward=
node
:user(username=
'Edward'
)
CREATE
(bob)-[:EMAILED]->(charlie),
(bob)-[:CC]->(davina),
(bob)-[:BCC]->(edward)
At first sight this looks like a reasonably faithful representation of the domain. Each
clause lends itself to being read comfortably left to right, thereby passing one of our
informal tests for correctness. For example, it's deceptively easy to read the sentence
“Bob emailed Charlie.” The limitations of this model only emerge when it becomes
necessary to determine exactly
what
was exchanged by the potential miscreant Bob (and
his alter-ego Alice). We can see that Bob CC'd or BCC'd some people, but we can't see
the most important thing of all: the email itself.
