Data Modeling with Graphs - Graph Databases - page 46

START theater= node :venue(name= 'Theatre Royal' ),
newcastle= node :city(name= 'Newcastle' ),
bard= node :author(lastname= 'Shakespeare' )
This START clause identifies all nodes with a property key name and property value
Theatre Royal in a node index called venues . The results of this index lookup are bound
to the identifier theater . (What if there are many Theatre Royal nodes in this index?
We'll deal with that shortly.) In a second index lookup, we find the node representing
the city of Newcastle; we bind this node to the identifier newcastle . Finally, as with our
earlier Shakespeare query, to find the Shakespeare node itself, we look in the authors
index for a node with a lastname property whose value is Shakespeare . We bind the
result of this lookup to bard .
From now on in our query, wherever we use the identifiers theater , newcastle , and
bard in a pattern, that pattern will be anchored to the real nodes associated with these
identifiers. In effect, the START clause localizes the query, giving us starting points from
which to match patterns in the surrounding nodes and relationships.
Declaring Information Patterns to Find
The MATCH clause in Cypher is where the magic happens. Much as the CREATE clause
tries to convey intent using ASCII art to describe the desired state of the graph, so the
MATCH clause uses the same syntax to describe patterns to discover in the database. We've
already looked at a very simple MATCH clause; now we'll look at a more complex pattern
that finds all the Shakespeare performances at Newcastle's Theatre Royal:
MATCH (newcastle)<-[:STREET|CITY*1..2]-(theater)
<-[:VENUE]-()-[:PERFORMANCE_OF]->()-[:PRODUCTION_OF]->
(play)<-[:WROTE_PLAY]-(bard)
This MATCH pattern uses several syntactic elements we've not yet come across. As well
as including bound nodes based on index lookups (discussed earlier), it uses pattern
nodes, arbitrary depth paths, and anonymous nodes. Let's take a look at these in turn:
• The identifiers newcastle , theater , and bard carry over from the START clause,
where they were bound to nodes in the graph using index lookups, as described
previously.
• If there are several Theatre Royals in our database (the cities of Plymouth, Bath,
Winchester, and Norwich all have a Theatre Royal, for example), then theater will
be bound to all these nodes. To restrict our pattern to the Theatre Royal in New‐
castle, we use the syntax <-[:STREET|CITY*1..2]- , which means the theater node
can be no more than two outgoing STREET and/or CITY relationships away from the
node representing the city of Newcastle. By providing a variable depth path, we
allow for relatively fine-grained address hierarchies (comprising, for example,
street, district or borough, and city).