Intermediate Cypher.pdf

© 2022 Neo4j, Inc. All rights reserved.
Wednesday, March 22
11:00 EDT 15:00 GMT
16:00 CET 20:30 IST
Intermediate Cypher
& Data Modelling

Today we will cover
● Recap: Fundamentals of Graph Databases & Cypher
● How Cypher Queries Work
● Data Modeling Fundamentals
● Advanced Cypher Techniques
● Bring your questions!

Follow along with AuraDB Free
● Sign in or Register at console.neo4j.io
● Click the New Instance button
● Choose the Empty instance option
● Copy your password or download your credentials.env ﬁle
● When the instance has started, click the Open button to open
Workspace

Graph Database
Fundamentals

Macbook
Graph Database
Fundamentals
Nodes

Macbook
Graph Database
Fundamentals
Nodes
Nodes represent things

Macbook
Product
Graph Database
Fundamentals
Nodes
Nodes can be identiﬁed by
one or more labels

Macbook
Product
Graph Database
Fundamentals
Nodes
one or more labels
Fragile

Macbook
Product
name: Macbook Pro
price: 2699.00
Graph Database
Fundamentals
Nodes
one or more labels
Nodes can hold properties
as key/value pairs
Fragile

Customer
name: Adam
email: adam@neo4j.com
Graph Database
Fundamentals
Relationships
Product
name: Macbook Pro
price: 2699.00

Customer
name: Adam
Graph Database
Fundamentals
Relationships
Relationships connect two nodes
Product
name: Macbook Pro
price: 2699.00

Customer
name: Adam
Graph Database
Fundamentals
Relationships
Relationships have a type
Product
name: Macbook Pro
price: 2699.00
RATED

Relationships have a direction
Customer
name: Adam
Graph Database
Fundamentals
Relationships
Product
name: Macbook Pro
price: 2699.00
RATED

Relationships have a direction
Customer
name: Adam
Graph Database
Fundamentals
Relationships
Product
name: Macbook Pro
price: 2699.00
RATED
stars: 3
createdAt: 2023-03-22
Relationships can hold properties
as key/value pairs

Graph Database
Fundamentals
Cypher
Introduction to Cypher
Cypher is a declarative language that allows
you to identify patterns in your data using
an ASCII-art style syntax consisting of
brackets, dashes and arrows.

Graph Database
Fundamentals
Cypher
Product
RATED
Customer

Graph Database
Fundamentals
Cypher
Product
RATED
Customer
(c:Customer)-[r:RATED]->(p:Product)

name: Adam
Graph Database
Fundamentals
The MATCH clause
Product
name: Macbook Pro
price: 2699.00
RATED
stars: 3
createdAt: 2023-03-22
MATCH (c:Customer)-[r:RATED]->(p:Product)
RETURN c.name AS customer, p.name AS product, r.stars
AS rating
Customer

MATCH
(c:Customer)-[:PURCHASED]->(o:Order),
(o)-[:ORDERS]->(p:Product),
(p)-[:PART_OF]>(cc:Category),
(cc)<-[:HAS_CHILD*0..3]-(cat:Category)
WHERE c.customerId = “ANTON”
AND cat.name = “Electronics”
RETURN *
The MATCH clause

MATCH
(c:Customer)-[:PURCHASED]->(o:Order),
(o)-[:ORDERS]->(p:Product),
(p)-[:PART_OF]->(cc:Category),
(cc)<-[:HAS_CHILD*0..3]-(cat:Category)
WHERE c.customerId = “ANTON”
AND cat.name = “Electronics”
RETURN *
The MATCH clause

• CREATE - Create a pattern in the graph
• MERGE - Find or create a pattern in the graph
• SET - Add a new label to a node or property to a node or relationship
• REMOVE - Remove a label from a node or property from node or
relationship
• DELETE - Delete a node or relationship from from the graph
Writing to Neo4j

AS A
Customer
I WOULD LIKE TO
Register for the website
SO THAT I CAN
Buy my groceries online
A CREATE Example

CREATE (c:Customer {
customerID: randomUuid(),
contactName: “Adam Cowley”,
address: “182-194 Union Street”,
city: “London”,
postalCode: “SE1 0LH”,
country: “United Kingdom”
})
A CREATE Example

• The CREATE statement is used to create new nodes and relationships
• The MERGE statement will ﬁrst search for the pattern, and if not found,
will attempt to create it
• You should MERGE when a node or relationship may not exist
• The whole pattern will be created if not found, so it is best to break the
pattern up into smaller pieces
CREATE or MERGE?

A MERGE Example
// ❌ BAD
MERGE (p:Product {name: "Beavertown Neck Oil IPA"})
-[:PART_OF]->(cat1:Category {categoryName: "Beverages"})

A MERGE Example
// ❌ BAD
If the category already exists
but the product doesn’t, Neo4j
will attempt to create both
nodes and the relationship

A MERGE Example
// ❌ BAD
// ✅ GOOD
MERGE (cat1:Category {name: “Beverages”})
MERGE (cat2:Category {name: “Alcohol”})
MERGE (p:Product {name: “Beavertown Neck Oil IPA”})
MERGE (p)-[:PART_OF]->(cat1)
MERGE (p)-[:PART_OF]->(cat2)

ON CREATE SET p.createdAt = datetime()
ON MATCH SET p:RestockedProduct
SET p.updatedAt = datetime()
REMOVE p:OutOfStock
SETting Properties and Labels

REMOVE p:OutOfStock
Set a property when the node is ﬁrst created

REMOVE p:OutOfStock
Set a property if the node already exists

REMOVE p:OutOfStock
Set a property regardless

REMOVE p:OutOfStock
The REMOVE keyword will remove a label or property

Data Modeling

Derive your data model from your use case
Data Modeling

AS A
Customer
I WOULD LIKE TO
Order a new Laptop and accessories
SO THAT I CAN
Build a website using a graph database
Nouns, Verbs and Adjectives

AS A
Customer
I WOULD LIKE TO
SO THAT I CAN
Product.

Intermediate Nodes

Intermediate Nodes
Knowing this fact might be
enough for your use case

Intermediate Nodes
The order information can now
be linked to multiple nodes
Knowing this fact might be
enough for your use case

Property, Relationship or Node - it depends…

{
"customer": {
"CustomerID": "ALFKI",
"CompanyName": "Alfreds Futterkiste",
"ContactName": "Maria Anders",
"ContactTitle": "Sales Representative",
"Phone": "030-0074321",
"Fax": "030-0076545",
"email": "maria.anders@alfreds.de"
},
"address": {
"Address": "Obere Str. 57",
"City": "Berlin",
"Region": null,
"PostalCode": "12209",
"Country": "Germany"
},
"order": {
"OrderID": 10248,
"EmployeeID": 5,
"OrderDate": "1996-07-04T00:00:00",
"RequiredDate": "1996-08-01T00:00:00",
"ShippedDate": "1996-07-16T00:00:00",
"ShipVia": 3,
"Freight": 32.38,
"ShipName": "Alfreds Futterkiste",
"ShipAddress": {
"City": "Berlin",
"Region": null,
}
}
}

● Many databases will duplicate data for
read-time performance
● Address is read-only? Store as a property
● Are billing and shipping addresses saved as
part of the checkout process? Store in a Node
● Are offers served to ﬁrst-time customers that
are limited by address? Store in a Node
● Is the graph used to optimise delivery routes?
Store as a Node
{
"customer": {
"CompanyName": "Alfreds Futterkiste",
"ContactName": "Maria Anders",
"ContactTitle": "Sales Representative",
"Phone": "030-0074321",
"Fax": "030-0076545",
"email": "maria.anders@alfreds.de"
},
"address": {
"City": "Berlin",
"Region": null,
},
"order": {
"OrderID": 10248,
"EmployeeID": 5,
"OrderDate": "1996-07-04T00:00:00",
"RequiredDate": "1996-08-01T00:00:00",
"ShippedDate": "1996-07-16T00:00:00",
"ShipVia": 3,
"Freight": 32.38,
"ShipName": "Alfreds Futterkiste",
"ShipAddress": {
"City": "Berlin",
"Region": null,
}
}
}

The easy way, RDBMS to Graph
Data Modeling

The Northwind
Database

Relational
to Graph

Relational
to Graph
Table names become
labels, individual records
become nodes

Relational
to Graph
Foreign keys become
relationships
(:Supplier)-[:SUPPLIES]->(:Product)
(:Customer)-[:PURCHASED]->(:Order)
(:Shipper)-[:SHIPS]->(:Order)

The Northwind
Database
Many-to-Many
Relationships

The Northwind
Database
Many-to-Many
Relationships
��

The Northwind
Database
Many-to-Many
Relationships
Order
C
O
N
T
A
I
N
S
PRODUCT

The Northwind
Database
Many-to-Many
Relationships
Order
C
O
N
T
A
I
N
S
PRODUCT
u
n
i
t
P
r
i
c
e
:
n
u
m
b
e
r
q
u
a
n
t
i
t
y
:
n
u
m
b
e
r
d
i
s
c
o
u
n
t
:
f
l
o
a
t

SQL to Cypher
SELECT o.ShipName, o.ShipAddress, o.ShipCity,
o.ShipRegion, o.ShipPostalCode, o.ShipCountry,
o.CustomerID, c.CompanyName AS CustomerName,
c.Address, c.City, c.Region,
c.PostalCode, c.Country,
(e.FirstName + ' ' + e.LastName) AS Salesperson,
o.OrderID, o.OrderDate, o.RequiredDate,
o.ShippedDate, s.CompanyName As ShipperName,
od.ProductID, p.ProductName,
od.UnitPrice, od.Quantity,
od.Discount, o.Freight,
(CONVERT(money,(od.UnitPrice*Quantity*(1-Discount)/100))*100) AS ExtendedPrice
FROM Customers c
INNER JOIN Products p ON p.ProductID = od.ProductID
INNER JOIN Orders o ON c.CustomerID = o.CustomerID
INNER JOIN OrderDetails od ON o.OrderID = od.OrderID
INNER JOIN Employees e ON e.EmployeeID = o.EmployeeID
INNER JOIN Shippers s ON s.ShipperID = o.ShipVia
WHERE c.customerID = "ANTON"
MATCH (c:Customer {customerID: "ANTON"})
-[:PURCHASED]->(o:Order), (o)-[od:ORDERED]->(p:Product),
(p)<-[:SHIPS]-(s:Shipper)
RETURN o.shipName, o.shipAddress, o.shipCity,
o.shipRegion, o.shipPostalCode, o.shipCountry,
c.customerID, c.companyName AS CustomerName,
c.address, c.city, c.region,
c.postalCode, c.country,
e.firstName +" "+ e.lastName AS Salesperson,
o.shippedDate, s.companyName AS ShipperName,
p.productID, p.productName,
od.unitPrice, od.quantity,
od.discount, od.freight,
od.unitPrice * od.quantity
* (1.0-od.discount)/100 * 100 AS ExtendedPrice
https://raw.githubusercontent.com/microsoft/sql-server-samples/master/samples/databases/northwind-pubs/instnwnd.sql

SQL to Cypher
FROM Customers c

SQL to Cypher
FROM Customers c
MATCH (c:Customer)

Graph Refactoring

● The graph as modeled does not answer all of the use cases.
● A new use case has come up that you must account for in your data
model.
● The Cypher for the use cases does not perform optimally, especially
when the graph scales
Why Refactor?

● Create an Index or Constraint
● Adding a new label
● Extracting a property into a Node
● Speciﬁc relationship types
Methods of Refactoring

Adding a label
Graph Refactoring

AS A
Sales Representative
I WOULD LIKE TO
Recommend alternatives to discontinued stock
SO THAT I CAN
Ensure Customers have a viable alternative to their favorite products
Adding a label

● MATCH all (:Product {discontinued: true}) nodes
● Use the SET keyword to add a new label
● Measure the results
Adding a Discontinued label

Extracting a property into a Node
Graph Refactoring

Refactoring Addresses to Nodes
AS A
Operations Manager
I WOULD LIKE TO
Find customers that live at the same address
SO THAT I CAN
Reduce driver workloads and improve delivery times by optimising delivery
routes

● Create a Unique Constraint on (:Address)
● Use a MATCH statement to ﬁnd Customer address details
● Use a MERGE statement to Find or Create an (:Address) Node
● MERGE a -[:HAS_ADDRESS]-> relationship between (:Customer) and
(:Address) Node

Speciﬁc Relationship Types
Graph Refactoring

Speciﬁc Relationship Types

AS A
Head of Electronic Sales
I WOULD LIKE TO
Find customers who have purchased electricals
SO THAT I CAN
Meet my sales targets by recommending them similar products

AS A
Warehouse Manager
I WOULD LIKE TO
Predict which products will be purchased in a given month
SO THAT I CAN
Maintain stock levels and manage customer expectations
Real-time Recommendations

MATCH (c:Customer)-[:PURCHASED]->(o:Order)-[:ORDERS]->(p:Product)
RETURN c.customerID, p.productName, [ (p)-[:PART_OF]->(ct) |
ct.categoryName ], count(*) AS count ORDER BY count DESC

Fun with Cypher

● Aggregation functions / min, max, count, collect - employee -> order ->
customer, then sum() to get amount, order by total in descending
● List expression to get products [0..5]
●
● WITH
● Sub Queries - customers other orders
● Who bought biscuits
○ Text search - STARTS WITH / ENDS WITH / CONTAINS
○ Exists patterns - where category isn’t in the biscuit
Reading Data

AS A
Sales Manager
I WOULD LIKE TO
Find the most customers who have the highest spend
SO THAT I CAN
Reward their loyalty with personalised offers

AS A
Regional Sales Manager
I WOULD LIKE TO
Identify our most active customers in my territory
SO THAT I CAN
Provide them with a personalised offer

AS A
Warehouse Manager
I WOULD LIKE TO
What customers who purchase biscuits also buy
SO THAT I CAN
Shift a palette of biscuits that are near the end of their shelf life

AS A
Warehouse Manager
I WOULD LIKE TO
Find a list of
SO THAT I CAN
Reward their loyalty with personalised offers

● Find the top 10 orders by total value
● Use a subquery to ﬁnd their most purchased
products
○ Aggregation
● Use exits
WITH
Aggregation functions / min, max,
count, collect
Text search - STARTS WITH /
ENDS WITH / CONTAINS
Exists patterns
Profiling
Pattern comprehension
List expressions
Variable length paths
Sub Queries
Parameters

AS A
Customer
I WOULD LIKE TO
Receive personalised offers
SO THAT I CAN
Save money on my weekly shop

AS A
Warehouse Manager
I WOULD LIKE TO
Sell excess stock as quickly as possible
SO THAT I CAN
Avoid wastage and increase proﬁts

Intermediate Cypher.pdf

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Intermediate Cypher.pdf

Similaire à Intermediate Cypher.pdf (20)

Plus de Neo4j

Plus de Neo4j (20)

Dernier

Dernier (20)

Intermediate Cypher.pdf