Building web applications with Python and Neo4j

Every database has its own query languages; for example, RDBMS leverages SQL and conforms to SQL-92 (http://en.wikipedia.org/wiki/SQL-92). Similarly, Neo4j also has its own query language—Cypher. The syntax of Cypher has similarities with SQL, though it still has its own unique characteristics, which we will discuss in the upcoming sections.

Neo4j leveraged the concept of patterns and pattern matching, and introduced a new declarative graph query language, Cypher, for the Neo4j graph database. Patterns and pattern matching are the essence and core of Neo4j, so let's take a moment to understand them. We will then talk about the similarities between SQL and Cypher.

Patterns are a given sequence or occurrence of tokens in a particular format. The act of matching patterns within a given sequence of characters or any other compatible input form is known as pattern matching. Pattern matching should not be confused with pattern recognition, which usually produces the exact match and does not have any concept of partial matches.

Pattern matching is the heart of Cypher and a very important component of the graph databases. It helps in searching and identifying a single or a group of nodes by walking along the graph. Refer to http://en.wikipedia.org/wiki/Pattern_matching for more information on the importance of pattern matching in graphs. Let's move forward and talk about Cypher, and it's similarities with SQL.

Cypher is specifically designed to be a human query language, which is focused on making things simpler for developers. Cypher is a declarative language and implements "What to retrieve" and not "how to retrieve", which is in contrast to the other imperative languages, such as Java and Gremlin (refer to http://gremlin.tinkerpop.com/).

Cypher borrows much of its structure from SQL, which makes it easy to use/understand for SQL developers. "SQL familiarity" is another objective of Cypher.

Let's refer to the following illustration, which defines the Cypher constructs and the similarity of Cypher with SQL constructs:

The preceding diagram defines the mapping of the common SQL and Cypher constructs. It also depicts the examples stating the usage of these constructs.

For instance, FROM is similar to MATCH or START and produces the same results. Although the way they are used is different but the objective and concept remains the same.

We will talk about Cypher in detail in Chapter 2, Querying the Graph with Cypher and Chapter 3, Mutating Graph with Cypher, but without getting into the nitty-gritty and syntactical details. The following is one more illustration that briefly describes the similarities between the Cypher and SQL constructs:

In the preceding illustration, we are retrieving the data using Cypher pattern matching. In the statement shown in the preceding diagram, we are retrieving all the nodes that are labeled with FEMALE in our Neo4j database. This statement is very similar to the SQL statement where we want to retrieve some specific rows of a table based on a given criteria, such as the following query:

SELECT * from EMPLOYEE where GENDER = 'FEMALE'

The preceding examples should be sufficient to understand that SQL developers can learn Cypher in no time.

Let's take one more example where we want to retrieve the total number of employees in the company X:

The preceding Cypher query shows the usage of aggregations such as count, which can also be replaced by sum, avg, min, max, and so on.

Let's move forward and discuss the transformation of the SQL data structures into the graph data structures.

The relational models are the simplest models to depict and define the entities and the relationship between those entities. It is easy to understand and you can quickly whiteboard with your colleagues and domain experts.

A graph model is similar to a relational model as both models are focused on the domain and use case. However, there is a substantial difference in the way they are created and defined. We will discuss the way the graph models are derived from the relational models, but before that, let's look at the important components of the graph models:

Let's take an example of a relational model, which is about an organization, and then understand the process of converting this into a graph model:

In the preceding relational model, we have employee, department, and title as entities, and Emp-Dept and Emp-Title as the relationship tables.

Here is sample data within this model:

The preceding screenshot depicts the sample data within the relational structures. The following are the guidelines to convert the preceding relational model into the graph model:

Now, let's follow the preceding guidelines and convert our relational model into the graph model, which will look something like the below image:

The preceding illustration defines the complete process and the organization of data residing in the relational models into the graph models. We can use the same guidelines for transforming a variety of relational models into the graph structures.

In this section, we discussed the similarities between SQL and Cypher. We also talked and discussed about the rules and processes of transforming the relational models into graph models. Let's move forward and understand the licensing and installation procedure of Neo4j.

Community Edition is a single node installation licensed under General Public License (GPL) Version 3 (http://en.wikipedia.org/wiki/GNU_General_Public_License) and is used for the following purposes:

You can benefit from the support of the whole Neo4j community on Stack Overflow, Google Groups, and Twitter.

Enterprise Edition comes with three different kinds of subscription options and provides the distributed deployment of the Neo4j databases, along with various other features, such as backup, recovery, replication, and so on.

Each of the subscription is subject to its own license and pricing. Visit http://neo4j.com/subscriptions/ for more information about available subscriptions with Enterprise Edition.

In this section, we will talk about the Neo4j installation on the Linux/Unix operating system. At the end of this section, you will have a fully-functional Neo4j instance running on your Linux/Unix desktop/server.

Let's perform the following common steps involved in the Neo4j installation on Linux/Unix:

Neo4j can be installed and executed as a Linux service, or it can also be downloaded as the .tar file, where, after installation, it needs to be started manually.

Let's talk about the steps involved in installing Neo4j as a service, and then we will also talk about the standalone archive.

High availability, fault tolerance, replication, backup, and recovery are a few of the notable features provided by Neo4j Enterprise Edition. Setting up a cluster of Neo4j nodes is quite similar to the single node setup, except for a few properties which need to be modified for the identification of node in a cluster.

Let's perform the following steps for installing Neo4j Enterprise Edition on Linux:

In order to prevent unauthorized access to endpoints, Neo4j 2.2.x, by default, provides token-based authorization and authentication for all the REST endpoints.

Therefore, before running any CRUD operations, we need to get the security token so that every request is authenticated and authorized by the Neo4j server.

Let's perform the following steps for getting the token:

The preceding screenshot shows the format of the request along with all the required parameters for authorizing the REST-based request to the Neo4j server.

You can also switch off the authentication by modifying dbms.security.authorization_enabled=true in $NEO4J_HOME/conf/neo4j-server.propoerties. Restart your server after modifying the property.

Now, as we have a valid token, let's move ahead and execute various CRUD operations.

Create, read, update, and delete are the four basic and most common operations for any persistence storage. In this section, we will talk about the process and syntax leveraged by Neo4j to perform all these basic operations.

Perform the following steps for creating, searching, and deleting data in the Neo4j database:

In this section, we walked through the process of executing the Cypher queries with one of the REST endpoints, /db/data/transaction/commit, which is known as Transactional Cypher HTTP Endpoint. There are various other REST endpoints exposed by Neo4j for performing traversals, search, CRUD, administration, and a health check of the Neo4j server. Refer to http://neo4j.com/docs/stable/rest-api.html for a complete list of available endpoints, or you can also execute another REST point exposed by Neo4j, /db/data, which is known as the service root and the starting point to discover the REST API. It contains the basic starting points for the database along with some version and extension information.