Links:

1. For free development platform

https://neo4j.com/cloud/platform/aura-graph-database/?ref=nav-get-started-cta

2. For Cypher query language

https://neo4j.com/developer/cypher/

3. Getting started with graph database

https://neo4j.com/developer/graph-database/

Graph Database Construction and Querying using Neo4j and Cypher

Content
1. What is graph database?
2. Why graph database?
3. The property graph model.
4. What is Neo4J?
5. Cypher query language.
a. Getting Started
b. Querying with cypher
c. Updating with cypher
6. sas

(1) What is Graph Database?

A Neo4j graph database stores nodes and relationships instead of tables or documents.
Data is stored just like you might sketch ideas on a whiteboard. Your data is stored without
restricting it to a pre-defined model, allowing a very flexible way of thinking about and using
it.

(2) Why Graph Databases?

We live in a connected world, and understanding most domains requires processing rich sets
of connections to understand what’s really happening. Often, we find that the connections
between items are as important as the items themselves.

1
How else do people do this today? While existing relational databases can store these
relationships, they navigate them with expensive JOIN operations or cross-lookups, often
tied to a rigid schema. It turns out that "relational" databases handle relationships poorly. In
a graph database, there are no JOINs or lookups. Relationships are stored natively alongside
the data elements (the nodes) in a much more flexible format. Everything about the system
is optimized for traversing through data quickly; millions of connections per second, per core.
Graph databases address big challenges many of us tackle daily. Modern data problems
often involve many-to-many relationships with heterogeneous data that sets up needs to:
• Navigate deep hierarchies,
• Find hidden connections between distant items, and
• Discover inter-relationships between items.
Whether it’s a social network, payment networks, or road network you’ll find that everything
is an interconnected graph of relationships. And when we want to ask questions about the
real world, many questions are about the relationships rather than about the individual data
elements.

(3) The Property Graph Model

2
Nodes are the entities in the graph.
• Nodes can be tagged with labels, representing their different roles in your domain.
(For example, Person).
• Nodes can hold any number of key-value pairs, or properties. (For example, name)
• Node labels may also attach metadata (such as index or constraint information) to
certain nodes.
Relationships provide directed, named, connections between two node entities (e.g.
Person LOVES Person).
• Relationships always have a direction, a type, a start node, and an end node, and
they can have properties, just like nodes.
• Nodes can have any number or type of relationships without sacrificing
performance.
• Although relationships are always directed, they can be navigated efficiently in any
direction.

(4) What is Neo4j?

Neo4j is an open-source, NoSQL, native graph database that provides an ACID-compliant
transactional backend for your applications that has been publicly available since 2007.

Neo4j is offered as a managed service via AuraDB.

But you can also run Neo4j yourself with either Community Edition or Enterprise Edition. The
Enterprise Edition includes all that Community Edition has to offer, plus extra enterprise
requirements such as backups, clustering, and failover abilities. Neo4j is written in Java and
Scala, and the source code is available on GitHub.

Neo4j is a native graph database, which means that it implements a true graph model all
the way down to the storage level.

The data isn’t stored as a "graph abstraction" on top of another technology, it’s stored just
as you whiteboard it. This is important because it’s the reason why Neo4j outperforms other
graphs and stays so flexible. Beyond the core graph, Neo4j provides what you’d expect out
of a database; ACID transactions, cluster support, and runtime failover. This stability and
maturity is why it’s been used in production scenarios for large enterprise workloads for
years.

(5) Cypher query language

Cypher is Neo4j’s graph query language that lets you retrieve data from the graph. It is like
SQL for graphs, and was inspired by SQL so it lets you focus on what data you want out of
the graph (not how to go get it). It is the easiest graph language to learn by far because of
its similarity to other languages, and intuitiveness.

3
Cypher is unique because it provides a visual way of matching patterns and relationships.
Cypher uses an ASCII-art type of syntax where

(nodes)-[:ARE_CONNECTED_TO]->(otherNodes)

using rounded brackets for circular (nodes), and -[:ARROWS]-> for relationships. When
you write a query, you draw a graph pattern through your data.

Neo4j users use Cypher to construct expressive and efficient queries to do any kind of create,
read, update, or delete (CRUD) on their graph, and Cypher is the primary interface for Neo4j.

Like Neo4j itself, Cypher is open source! The openCypher project provides all of the specs needed.
Cypher is backed by a number of companies all of which benefit from cypher.

5.1 Introduction to Cypher

Neo4j’s developer pages cover the basics of the language, which you can explore by topic
area below, starting with basic material, and building up towards more complex material.

Getting Started with Cypher Learn what cypher is, and important concepts for graph
Querying with Cypher How to write Cypher code to query the graph
Updating with Cypher How to change data in a graph
Filtering Cypher Query Trim results by criteria, focusing only on the data you want.
Results
Controlling Query Processing Counting results, grouping data by values, finding minimum,
maximums, and aggregations.
Cypher Dates Working with temporal information
Cypher Subqueries Running queries within queries for more accurate and focused
results
Cypher Style Guide Recommended style for writing easy to read, easy to maintain
Cypher queries
From SQL to Cypher Similarities and Differences between SQL and Cypher
User-Defined Procedures and Extending Cypher with powerful additional functionality for
Functions special scenarios
APOC: Neo4j’s Standard
Utility Library

5.1.a) Getting Started with Cypher

4
Why Cypher?
We already know that Neo4j’s property graph model is composed of nodes and
relationships, which may also have properties associated with them. However, nodes and
relationships are the simple components that build the most valuable and powerful piece of
the property graph model - the pattern. Patterns are comprised of node and relationship
elements and can express simple or complex traversals and paths.

Pattern recognition is fundamental to the way that the brain works. Because of this, humans
are very good at working with patterns (think of visual diagrams or even memory-matching
games). Cypher is also heavily based on patterns and is designed to recognize various
versions of these patterns in data, making it a simple and logical language for users to learn.

Cypher Syntax

Since Cypher is designed to be human-readable, it’s construct is based on English prose and
iconography to make syntax visual and easily understood. For example, take a look at the
simple graph data in the image below. How would you represent this data in English? NOTE:
the answer is in the paragraph below

Jennifer likes Graphs. Jennifer is friends with Michael. Jennifer works for Neo4j.

Cypher syntax will build upon this English-language structure we just created. In the next
section, we will see exactly how to write this example in Cypher.

Cypher Comments
You can add comments by starting a line with // and putting text after the slashes.

5
This is especially helpful to use in Neo4j Browser when saving queries. If you add a comment before
the query, the comment automatically becomes the name of the saved query!

Representing Nodes in Cypher

Since Cypher uses ASCII-Art for patterns, we need a visual way to represent each
component of our pattern above.

We know that the main components of the property graph model are nodes and
relationships.

Remember that nodes are the data entities in your graph and that you can often identify
nodes by finding the nouns or objects in your data model.

In our example, Jennifer, Michael, Graphs, and Neo4j are our nodes.

To depict nodes in Cypher, we surround the node with parentheses, e.g. (node). Notice how
the parentheses look similar to the circles that the visual representation uses for nodes in
our data model.

Node Variables
If we later want to refer to the node, we can give it a variable like (p) for person or (t) for
thing. In real-world queries, we might use longer, more expressive variable names
like (person) or (thing). Just like in programming language variables, you can name your
variables what you want and reference them by that same name later in a query.

If the node is not relevant to your return results, you can specify an anonymous node using
empty parentheses (). This means that you will not be able to return this node later in the
query.

Node Labels
If you remember from the property graph data model, you can also group similar nodes
together by assigning a node label. Labels are kind of like tags and allow you to specify
certain types of entities to look for or create. In our example, Person, Technology,
and Company are the labels.
You can kind of think of this like telling SQL which table to look for the particular row. Just
like to tell SQL to query a person’s information from

6
a Person or Employee or Customer table, you can also tell Cypher to only check those
labels for that information.

This helps Cypher distinguish between entities and optimize execution for your queries. It
is always better to use node labels in your queries, where possible.

Example: Nodes in Cypher

Using our graph example above, let’s see how we could specify our nodes.

() //anonymous node (no label or variable) can refer to any node in the database
(p:Person) //using variable p and label Person
(:Technology) //no variable, label Technology
(work:Company) //using variable work and label Company

Representing Relationships in Cypher

To fully utilize the power of a graph database, we also need to express the relationships
between our nodes.

Relationships are represented in Cypher using an arrow --> or <-- between two nodes.
Notice how the syntax looks like the arrows and lines connecting our nodes in the visual
representation. Additional information, such as how nodes are connected (relationship type)
and any properties pertaining to the relationship, can be placed in square brackets inside of
the arrow.

In our example, the lines with LIKES, IS_FRIENDS_WITH, and WORKS_FOR between nodes
are our relationships.

Undirected relationships are represented with no arrow and just two dashes --. This means
that the relationship can be traversed in either direction.

While a direction must be inserted to the database, it can be matched with an undirected
relationship where Cypher ignores any particular direction and retrieves the relationship and
connected nodes, no matter what the physical direction is.

7
This allows the queries to be flexible and not force the user to know the physical direction
of the relationship stored in the database.

If data is stored with one relationship direction, and a query specifies the wrong direction, Cypher
will not return any results. In these cases where you may not be sure of direction, it is better to use
an undirected relationship and retrieve some results.
//data stored with this direction
CREATE (p:Person)-[:LIKES]->(t:Technology)

//query relationship backwards will not return results

MATCH (p:Person)<-[:LIKES]-(t:Technology)

//better to query with undirected relationship unless sure of direction

MATCH (p:Person)-[:LIKES]-(t:Technology)

Relationship Types
Relationship types categorize and add meaning to a relationship, similar to how labels group
nodes. In our property graph data model, relationships show how nodes are connected and
related to each other. You can usually identify relationships in your data model by looking
for actions or verbs.

You can specify any type of relationship you want between nodes, but we recommend good
naming conventions using verbs and actions. Poor relationship type names make it more
difficult to both read and write Cypher (remember, it should sound like English!).

For example, let us look at the relationship types from our example graph.
• [:LIKES] - makes sense when we put nodes on either side of the relationship
(Jennifer LIKES Graphs)
• [:IS_FRIENDS_WITH] - makes sense when we put nodes with it (Jennifer
IS_FRIENDS_WITH Michael)
• [:WORKS_FOR] - makes sense with nodes (Jennifer WORKS_FOR Neo4j)
•
Relationship Variables
Just as we did with nodes, if we want to refer to a relationship later in a query, we can give
it a variable like [r] or [rel].
We can also use longer, more expressive variable names like [likes] or [knows]. If you
do not need to reference the relationship later, you can specify an anonymous relationship
using two dashes --, -->, <--.

As an example, you could use either -[rel]-> or -[rel:LIKES]-> and call

the rel variable later in your query to reference the relationship and its details.

8
If you forget the colon in front of a relationship type like this -[LIKES]->, it represents a variable
(not a relationship type). Since no relationship type declared, Cypher will search all types of
relationships.

Node or Relationship Properties

We have talked about how to write Cypher for nodes, relationships, and labels. The last
piece of our property graph data model is for properties. Remember that properties are
name-value pairs that provide additional details to our nodes and relationships.

To represent these in Cypher, we can use curly braces within the parentheses of a node or
the brackets of a relationship. The name and value of the property then go inside the curly
braces. Our example graph has both a node property (name) and a relationship property
(since).
• Node property: (p:Person {name: 'Jennifer'})
• Relationship property: -[rel:IS_FRIENDS_WITH {since: 2018}]->

Properties can have values with a variety of data types. To see the full list that Cypher offers,
see the manual section on values and types.

Patterns in Cypher

Nodes and relationships make up the building blocks for graph patterns. These building
blocks can come together to express simple or complex patterns.

Patterns are the most powerful capability of graphs. In Cypher, they can be written as a
continuous path or separated into smaller patterns and tied together with commas.

9
To show a pattern in Cypher, we need to combine the node and relationship syntaxes we
have learned so far. Let us use our example of Jennifer likes Graphs.

In Cypher, this pattern would look like the code below.

(p:Person {name: "Jennifer"})-[rel:LIKES]->(g:Technology {type: "Graphs"})

This bit of Cypher tells the pattern we want, but it does not tell whether we want to find
that existing pattern or insert it as a new pattern. To tell Cypher what we want it to do with
the pattern, we need to add some keywords.

5.1.b) Querying with Cypher

Cypher Keywords
Just like with most programming languages, there are a few words in Cypher reserved for
specific actions in parts of a query. We need to be able to create, read, update, or delete data
in Neo4j, and keywords help us accomplish that functionality. Let us look more in detail at
two common keywords (more will be covered in upcoming guides).

MATCH
The MATCH keyword in Cypher is what searches for an existing node, relationship, label,
property, or pattern in the database. If you are familiar with SQL, MATCH works pretty much
like SELECT in SQL.

You can find all node labels in the database, search for a particular node, find all the nodes
with a particular relationship, look for patterns of nodes and relationships, and much more
using MATCH.

RETURN

The RETURN keyword in Cypher specifies what values or results you might want to return
from a Cypher query. You can tell Cypher to return nodes, relationships, node and
relationship properties, or patterns in your query results. RETURN is not required when doing
write procedures, but is needed for reads.

The node and relationship variables we discussed earlier become important when
using RETURN. In order to bring back nodes, relationships, properties, or patterns, you need
to have variables specified in your MATCH clause for the data you want to return.

10
Cypher Examples
Let us look at some examples of the syntax we have learned so far
using MATCH and RETURN keywords. Each example will start with an explanation of what
we are trying to achieve and have an image below of the results of the query run in Neo4j
Browser.

• Example 1: Find the labeled Person nodes in the graph. Note that we must use a
variable like p for the Person node if we want retrieve the node in
the RETURN clause.

MATCH (p:Person)
RETURN p
LIMIT 1

• Example 2: Find Person nodes in the graph that have a name of 'Tom Hanks'.
Remember that we can name our variable anything we want, as long as we
reference that same name later.

MATCH (tom:Person {name: 'Tom Hanks'})

RETURN tom

• Example 3: Find which `Movie`s Tom Hanks has directed.

Explanation: we know we need to find Tom Hanks' Person node, and we need to find
the Movie nodes he is connected to. To do that, we need to follow
the DIRECTED relationship from Tom Hanks' Person node to the Movie node. We have
also specified a label of Movie so that the query will only look at nodes with that label.
Since we only care about returning the movie in this query, we need to give that node a
variable (movie) but do not need to give variables for the Person node
or DIRECTED relationship.

MATCH (:Person {name: 'Tom Hanks'})-[:DIRECTED]->(movie:Movie)

RETURN movie

• Example 4: Find which Movie Tom Hanks has directed, but this time, return only
the title of the movie.

Explanation: this query is very similar to Example 3. Example 3 returned the

entire Movie node with all its properties. For this example, we still need to find Tom’s
movies, but now we only care about their titles. We will need to access the
node’s title property using the syntax variable.property to return the name value.

MATCH (:Person {name: 'Tom Hanks'})-[:DIRECTED]->(movie:Movie)

RETURN movie.title

11
Aliasing Return Values
Not all properties are simple like our movie.title example above. Some properties have
poor names due to property length, multi-word descriptions, developer jargon, and other
shortcuts. These naming conventions can be difficult to read, especially if they end up on
reports and other user-facing interfaces.

//poorly-named property

MATCH (tom:Person {name:'Tom Hanks'})-[rel:DIRECTED]-(movie:Movie)

RETURN tom.name, tom.born, movie.title, movie.released

Just like with SQL, you can rename return results by using the AS keyword and aliasing the
property with a cleaner name. We can look at a mocked-up example to list a customer’s
orders and the number of items in the order.

//cleaner printed results with aliasing

MATCH (tom:Person {name:'Tom Hanks'})-[rel:DIRECTED]-(movie:Movie)
RETURN tom.name AS name, tom.born AS `Year Born`, movie.title AS title,
movie.released AS `Year Released`

Code Challenge
Now that you know the basics, use the parts below to build a cypher statement to to find
the title and year of release for every :Movie that Tom Hanks has :DIRECTED.

5.1.c) Updating with Cypher

Create, Update, and Delete Operations

In the last guide, we learned how to represent nodes, relationships, labels, properties, and
patterns in Cypher for read queries.

This guide will add another level to your knowledge by introducing how to write create,
update, and delete operations in Cypher.

12
While these are the standard CRUD operations, some things function a bit differently in a
graph than in other types of databases. You will probably recognize some of the similarities
and differences as we go along.

Inserting Data with Cypher

Adding data in Cypher works very similarly to any other data access language’s insert
statement. Instead of the INSERT keyword like in SQL, though, Cypher uses CREATE.

You can use CREATE to insert nodes, relationships, and patterns into Neo4j.

Let us look at an example that we used in our last guide. To review, we had Person node
(Jennifer) who liked graphs, was friends with Michael, and worked at Neo4j.

What if we wanted to add another of Jennifer’s friends to the graph? We can add Jennifer’s
friend Mark using the Cypher statement below.

CREATE (friend:Person {name: 'Mark'})

RETURN friend

It is not required to include the RETURN clause in the Cypher statement above. If you do not want
to return any results, simply run this statement instead: CREATE (friend:Person {name:
'Mark'}

Great! Now we added Mark to the database. However, Mark is all alone with no relationships
because we just created his node and did not specify any connections. We know he is friends
with Jennifer (same as Michael),

so we can add a new IS_FRIENDS_WITH relationship between the existing Jennifer and
Mark nodes. The Cypher to do that would look like this.

MATCH (jennifer:Person {name: 'Jennifer'})

MATCH (mark:Person {name: 'Mark'})
CREATE (jennifer)-[rel:IS_FRIENDS_WITH]->(mark)

13
Notice that we run two MATCH queries before we create a relationship between the nodes.
Why is that? The reason we do a match for Jennifer’s node and a match for Mark’s node first
is because the CREATE keyword does a blind insert and will create the entire pattern,
regardless if it already exists in the database.

This means that running the Cypher statement below will insert duplicate Jennifer and Mark
nodes. To avoid this, our previous query first found the existing nodes, and then created a
new relationship between them.

//this query will create duplicate nodes for Mark and Jennifer
CREATE (j:Person {name: 'Jennifer'})-[rel:IS_FRIENDS_WITH]->(m:Person {name:
'Mark'})

Updating Data with Cypher

Maybe you already have a node or relationship in the data, but you want to modify its
properties. You can do this by matching the pattern you want to find and using
the SET keyword to add, remove, or update properties.

Using our example thus far, we could update Jennifer’s node to add her birthday. The next
Cypher statement shows how to do this. First, we need to find our existing node for Jennifer.
Next, we use SET to create the new property (with syntax variable.property) and set its
value. Finally, we can return Jennifer’s node to ensure that the information was updated
correctly.

MATCH (p:Person {name: 'Jennifer'})

SET p.birthdate = date('1980-01-01')
RETURN p

If we now wanted to change her birthday, we could use the same query above to find
Jennifer’s node again and put a different date in the SET clause.

14
We could also update Jennifer’s WORKS_FOR relationship with her company to include the
year that she started working there. To do this, you can use similar syntax as above for
updating nodes.

MATCH (:Person {name: 'Jennifer'})-[rel:WORKS_FOR]-(:Company {name: 'Neo4j'})

SET rel.startYear = date({year: 2018})
RETURN rel

Deleting Data with Cypher

Another operation for us to cover is how to delete data in Cypher. For this operation, Cypher
uses the DELETE keyword for deleting nodes and relationships. It is very similar to deleting
data in other languages like SQL, with one exception.

Because Neo4j is ACID-compliant, you cannot delete a node if it still has relationships. If you
could do that, then you might end up with a relationship pointing to nothing and an
incomplete graph. We will walk through how to delete a disconnected node, a relationship,
as well as a node that still has relationships.

Delete a Relationship

To delete a relationship, you need to find the start and end nodes for the relationship you
want to delete and then use the DELETE keyword, as shown in the statement below. Let
us go ahead and delete the IS_FRIENDS_WITH relationship between Jennifer and Mark for
now.

We will add this relationship back in a later exercise.

MATCH (j:Person {name: 'Jennifer'})-[r:IS_FRIENDS_WITH]->(m:Person {name: 'Mark'})

DELETE r

Delete a Node
To delete a node that does not have any relationships, you need to find the node you want
to delete and then use the DELETE keyword, just as we did for the relationship above. We
can delete Mark’s node for now and add him back in a later exercise.

MATCH (m:Person {name: 'Mark'})

DELETE m

15
Delete a Node and Relationship

Instead of running the last two queries to delete the IS_FRIENDS_WITH relationship and
the Person node for Mark, we can actually run a single statement to delete the node and
relationship at the same time. As we mentioned above, Neo4j is ACID-compliant so it
doesn’t allow us to delete a node if it still has relationships. Using the DETACH
DELETE syntax tells Cypher to delete any relationships the node has, as well as remove the
node itself.

The statement would look like the code below. First, we find Mark’s node in the database.
Then, the DETACH DELETE line removes any existing relationships Mark has before also
deleting his node.

MATCH (m:Person {name: 'Mark'})

DETACH DELETE m

Delete Properties
You can also remove properties, but instead of using the DELETE keyword, we can use a
couple of other approaches. The first option is to use REMOVE on the property. This tells
Neo4j that you want to remove the property from the node entirely and no longer store it.

The second option is to use the SET keyword from earlier to set the property value to null.
Unlike other database models, Neo4j does not store null values. Instead, it only stores
properties and values that are meaningful to your data. This means that you can have
different types and amounts of properties on various nodes and relationships in your graph.
To show you both options, let us look at the code for each.

//delete property using REMOVE keyword

MATCH (n:Person {name: 'Jennifer'})
REMOVE n.birthdate

//delete property with SET to null value

MATCH (n:Person {name: 'Jennifer'})
SET n.birthdate = null

Avoiding Duplicate Data Using MERGE

We briefly mentioned in an earlier section that there are some ways in Cypher to avoid
creating duplicate data. One of those ways is by using the MERGE keyword. MERGE does a
"select-or-insert" operation that first checks if the data exists in the database. If it exists,
then Cypher returns it as is or makes any updates you specify on the existing node or

16
relationship. If the data does not exist, then Cypher will create it with the information you
specify.

Using Merge on a Node

To start, let us look at an example of this by adding Mark back to our database using the
query below. We use MERGE to ensure that Cypher checks the database for an existing node
for Mark. Since we removed Mark’s node in the previous examples, Cypher will not find an
existing match and will create the node new with the name property set to 'Mark'.

If we run the same statement again, Cypher will find an existing node this time that has the
name Mark, so it will return the matched node without any changes.

MERGE (mark:Person {name: 'Mark'})

RETURN mark

Using Merge on a Relationship

Just like we used MERGE to find or create a node in Cypher, we can do the same thing to
find or create a relationship. Let’s re-create the IS_FRIENDS_WITH relationship between
Mark and Jennifer that we had in a previous example.

MATCH (j:Person {name: 'Jennifer'})

MATCH (m:Person {name: 'Mark'})
MERGE (j)-[r:IS_FRIENDS_WITH]->(m)
RETURN j, r, m

Notice that we used MATCH here to find both Mark’s node and Jennifer’s node before we
used MERGE to find or create the relationship. Why did we not use a single
statement? MERGE looks for an entire pattern that you specify to see whether to return an
existing one or create it new. If the entire pattern (nodes, relationships, and any specified
properties) does not exist, Cypher will create it.

Cypher never produces a partial mix of matching and creating within a pattern. To avoid a
mix of match and create, you need to match any existing elements of your pattern first before
doing a merge on any elements you might want to create, just as we did in the statement
above.

Just for reference, the Cypher statement that will cause duplicates is below. Because this
pattern (Jennifer IS_FRIENDS_WITH Mark) does not exist in the database, Cypher creates
the entire pattern new - both nodes, as well as the relationship between them.

17
//this statement will create duplicate nodes for Mark and Jennifer
MERGE (j:Person {name: 'Jennifer'})-[r:IS_FRIENDS_WITH]->(m:Person {name: 'Mark'})
RETURN j, r, m

Handling MERGE Criteria

Perhaps you want to use MERGE to ensure you do not create duplicates, but you want to
initialize certain properties if the pattern is created and update other properties if it is only
matched. In this case, you can use ON CREATE or ON MATCH with the SET keyword to handle
these situations.

Let us look at an example.

MERGE (m:Person {name: 'Mark'})-[r:IS_FRIENDS_WITH]-(j:Person {name:'Jennifer'})
ON CREATE SET r.since = date('2018-03-01')
ON MATCH SET r.updated = date()
RETURN m, r, j

5.1.d) Filtering Cypher query results

5.1.e) Controlling query processing

////////////////////////////////////////////////////////////

Tutorial: Build a Recommendation Engine

With Cypher structure and syntax covered in the sections above, you can dive into building
your own recommendation engine to use graph data and Cypher to recommend movies,
colleagues, cuisines, and more.

Tutorial: Build a Recommendation Engine will walk through using queries and filtering that
takes advantage of the relationships in a graph in order to lend insight into habits and hidden
connections and provide valuable recommendations.

18