Neo4j is a Graph Database
About this module
Neo4j enables developers to create applications that are best architected as graphpowered systems that are built upon the rich connectedness of data.
At the end of this module, you will be able to:

Describe what a graph is.

Describe what a graph database is.

Describe some common use cases for using a graph database.

Describe the Neo4j property graph model.

Whiteboard a graph data model.
What is a graph?
A graph is set of discrete objects, each of which has some set of relationships with the other objects.
Graphs are a useful way to model data for the purposes of mathematical analysis, and they have been around for quite a long time. The first use of graphs was by Leonhard Euler in 1735; he used graph theory to prove that the famous Seven Bridges of Konigsberg problem had no solution.
Konigsberg, Prussia (now Kaliningrad, Russia) is a city spanning the Pregel River. It includes two large islands, which are connected to one another and to the river banks by seven bridges. A map of this arrangement is pictured here.
The Seven Bridges problem is this: Is there any possible route through the city that crosses every bridge exactly once? Some penandpaper experimentation will quickly suggest that there is no such route. However, PROVING that there is no solution is much more difficult; Euler invented Graph Theory as a tool to aid this proof. The graph representation of the problem is on the right: four land masses, each represented by a node, and seven bridges, each represented by a relationship.
Euler observed the following:

The route taken within each landmass is irrelevant. Only the sequence of bridges crossed matters.

Whenever you enter a land mass via a bridge, you must leave it by a different bridge.

…except at the start (where you leave but do not enter) and at the end (where you enter but do not leave). *Thus, for the problem to be solvable, every land mass (except the start and end) must be touched by an even number of bridges.

Based on the above observations, the problem has no solution, because all four of the land masses are touched by an odd number of bridges.
Anything can be a graph
If graphs are an abstract mathematical tool, why do we care about them?
We care because any dataset can be represented as a graph. Any structure or concept, no matter how simple or complex, can be broken down into a set constituent parts that have some relationship to one another.
For example, the Internet can be modeled as a network of computers.
At the other extreme of complexity, a single molecule can be represented as a graph of its constituent atoms—or an atom represented as a graph of subatomic particles.
And, as Euler showed, there are some clear benefits to representing data in this way. We will discuss many of these as we go. But mainly, graphs are uniquely useful when answering a question that involves following a path along a chain of related items.
You will frequently hear Neo4j people refer to such questions as graph problems—and they are surprisingly common in the real world.
Neo4j’s property graph
The components of A Neo4j graph include:

Nodes

Relationships

Labels

Properties
Graph terminology and Neo4j’s property graph

Node = Vertex

Relationship = Edge
Let’s start by defining the terms vertex and edge. A vertex is an object in a graph. An edge is a connection between two vertices which could be an ordered pair of vertices
Node and Relationship are the Neo4j terms for vertex and edge.
We use these nodes and relationships in Neo4j since we find them more intuitive in representing and communicating  how vertices and edges are used in a property graph.
Nodes

Represent objects or entities.

Can be labeled.
There are two kinds of data that can be associated a node, labels and properties.
Labels provide categorical information. For example, here we have two Person nodes and one Car node.
These labels categorizes these nodes, as a Person or a Car, but they don’t provide any specific information about a given node.
Specific information for a node is represented as a properties which you will learn about soon.
Node properties

Represent objects or entities.

Can be labeled.

May have properties.
Properties are used to associate specific information with individual nodes.
As shown here, the Person nodes now each have name property, One node has a name property with a value, Dan, and the other Person node has a name property with a value, Ann. The name property provides a way to differentiate the nodes. And the Car node has several properties providing details about this particular car.
Nodes do not need to have a label or any properties. However, in practice, a node almost always has at least one label and one or more properties.
This is why we call Neo4j a property graph since it associates data with nodes. As we’ll see, having properties in the graph provides value to our application.
Relationships

Must have a type.

Must have a direction.
Next, let’s talk about relationships. Relationships must have both a type and a direction.
Types are similar to labels since types provide a general category for each relationship.
For example, as we see here, the relationships have the types  DRIVES, OWNS, and LOVES. Each of these types captures how a relationship is used to relate two nodes.
Again, along with a type, each Neo4j relationship must have a direction.
Following the direction shown in this graph we see that “Ann owns a Volvo”. If the relationship direction were reversed, it relays a VERY different concept, which is “The Volvo owns Ann.”
Relationship properties

Must have a type.

Must have a direction.

May have properties.
Just like nodes, relationships can have properties that express specific attributes.
Here we see the property ‘since’  for the DRIVES relationship. This indicates how long Dan has been driving this particular car.
Multiple relationships

Must have a type.

Must have a direction.

May have properties.

Nodes can share multiple relationships.
Because relationships are specific, each node can have many relationships with other nodes to fully capture their context.
This is a good thing, otherwise Ann would love Dan, but not vice versa!
A property graph model

Nodes

Represent objects or entities.

Can be labeled.

May have properties.


Relationships

Must have a type.

Must have a direction.

May have properties.


Nodes can share multiple relationships.
Here’s complete, although very simple, property graph for this example.
Mathematically, a node is defined as “a point where two or more edges (relationships) meet.”
This is not at all intuitive! However, it does provide an important insight into how graphs are used.
Since the entire point of modeling data as a graph is to traverse a chain of linked nodes. One useful way of thinking about nodes is that they are waypoints along the traversal route. They contain the information needed to decide which links are good ones to follow, and which can be ignored. Relationships are those links.
The support for properties on both nodes and relationships is what makes Neo4j a property graph. This provides a flexible way of defining varying amounts of data.
Traversing a graph
A very important concept within graph theory is traversal. An important feature of graphs is to follow a chain of nodes and relationships.
The process of finding such routes is the definition of traversal.
We’ll be looking at 3 different ways that traversal can be done:

Walk

Trail

Path
Traversing a graph: Walk
A walk is an ordered, alternating sequence of nodes and relationships where the nodes and relationships can be repeated.
A walk is the most basic type of traversal. A walk is an ordered alternating list of nodes and relationships. For example, in the graph shown here, we could define a walk starting at node 1, hopping to 2, then 3, back to 2, on to 6, and back to 2. There are no restrictions here.
You can traverse relationships multiple times and visit the same node as many times as you wish.
Traversing a graph: Trail
A trail is a walk where no relationships are repeated, but nodes can be visited more than once.
For example, remember the Seven Bridges problem? It uses a trail. You can visit each landmass as many times as you’d like, but you can only cross each bridge once.
The walk we just performed (123262) is not a valid trail, because we traversed the relationship between 2 and 3 twice.
Instead, a valid trail, as shown here, could start at 1, go to 2, 6, and back to 2. This is permitted since there are two relationships between 6 and 2, and we use each of them once.
Traversing a graph: Path
A path is a trail where no nodes are repeated. That is, all items are unique.
The trail we just followed (1262) is not a valid path because it visits node 2 twice. By dropping that last hop, it becomes a valid path.
The problems we solve with Neo4j are almost exclusively done by traversing trails and paths. Each of these terms mean something very specific in the context of graphs.
For example, there are several special kinds of paths that are extremely useful for solving certain problems. Shortest path (the path containing the fewest elements) is the most common of these. A couple of more esoteric examples include:

Longest path, Hamiltonian path (visits every node in the graph)

Cycle (“path” that ends at the same node it started on)
What is a graph database?
A graph database is an online database management system with Create, Read, Update, and Delete (CRUD) operations working on a graph data model.
Graph databases are often used as part of an Enterprise online transaction processing (OLTP) system. Accordingly, they are normally optimized for transactional performance, and engineered with transactional integrity and operational availability in mind.
Unlike other databases, relationships take first priority in graph databases. This means your application doesn’t have to infer data connections using foreign keys or outofband processing, such as MapReduce. By assembling the simple abstractions of nodes and relationships into connected structures, graph databases enable us to build sophisticated models that map closely to our problem domain. Data scientists can use the relationships in a data model to help enterprises make important business decisions.
Neo4j is a native graph database
In this video, you will see the benefits of using the native graph database, Neo4j.
Querying using Cypher is intuitive
If you have ever tried to write a SQL statement with a large number of JOINs, you know that you quickly lose sight of what the query actually does, due to the number of tables that are required to connect the data.
SQL statement  listing the employees in the IT Department:
SELECT name FROM Person
LEFT JOIN Person_Department
ON Person.Id = Person_Department.PersonId
LEFT JOIN Department
ON Department.Id = Person_Department.DepartmentId
WHERE Department.name = "IT Department"
Cypher statement  clean and focused since queries are expressed visually:
MATCH (p:Person)<[:EMPLOYEE](d:Department)
WHERE d.name = "IT Department"
RETURN p.name
Use cases for graph databases
The biggest value that graphs bring to an application is their ability to store relationships and connections as firstclass entities.
For instance, the early adopters of graph technology built their businesses around the value of data relationships. These companies have now become industry leaders: LinkedIn, Google, Facebook, and PayPal.
There are many uses for graph databases in an enterprise. Here are some of them:
You can read more about how customers are using Neo4j here.
Training data model for this course
For this training, we will use a Movies graph to get you started with accessing the data in a Neo4j database.
The data model is very simple, it includes entities such as:

Movie

Person/Actor/Director
that are implemented as nodes in the graph.
People are related to Movies using these relationships:

DIRECTED

ACTED_IN

WROTE

REVIEWED
People, who have reviewed movies, are related to each other using the FOLLOWS relationships.
Initial whiteboard the data model
You can use a whiteboard to better understand the graph data model. Stakeholders for an application typically communicate their ideas about how the data will be modeled by drawing bubbles for the entities and directed arrows for the relationships between the entities.
Here we see that people such as Tom Hanks and Hugo Weaving have acted in the movie, Cloud Atlas.
Implementation of the graph data model
Once the graph data model has been agreedupon, developers then create the nodes with the relationships. When nodes and relationships are added to the graph, additional properties are set for nodes and relationships using the property graph modeling capabilities of Neo4j. Some properties for nodes can be unique such as the name of a person or the title of a movie.
Here is the partial implementation of this graph data model. Notice that some nodes not only have a Person label, but also have a Actor or Director label on them. A Person node has a name property and some Person nodes have a born property. A Movie node has title and released properties. The ACTED_IN relationship has a roles property.
As you learn Cypher in this course, you will explore all of these node and relationship types in the graph.
Exploring graphgists
As a developer just learning Neo4j and Cypher, you will use the very simple Movies graph data model. If, however, you are curious about how other developers have created graph data models for Neo4j, you can explore the graphgists page.
Graphgists are developed by a wide range of developers from Neo4j and from the Neo4j user community. You can explore this site to see how other applications have modeled their data and get an appreciation for what can be done in Neo4j.
Example graphgist
For example, here is the Exploring a Conference graphgist that has a description of the model, how to load the sample data, and how to query the data.
As you gain experience with Cypher and think about modeling your application, check out some of these graphgists for ideas for how to model your data. We recommend that you take our training course, Graph Data Modeling for Neo4j, which introduces you to the best practices for modeling data and implementing graph data models in Neo4j.
Check your understanding
Summary
You can now:

Describe what a graph is.

Describe what a graph database is.

Describe some common use cases for using a graph database.

Describe the Neo4j property graph model.

Whiteboard a graph data model.
Need help? Ask in the Neo4j Community