1 of 74

Introduction to Neo4j - �a hands-on crash course

dev.neo4j.com/forum

dev.neo4j.com/chat

Neo4j, Inc. CC BY-SA 4.0

2 of 74

This is an interactive session!

Tell us where you're from!

And please ask Questions

as we go along!

In any of the chats

Neo4j, Inc. CC BY-SA 4.0

3 of 74

In this session

We will cover:

What is a graph and why they are amazing
Spotting good graph scenarios
Property graph database anatomy and introduction to Cypher
Hands-on: the northwind graph on Neo4j AuraDB Free

console.neo4j.io

Continuing your graph journey

Useful reference: https://dev.neo4j.com/rdbms-gdb

Neo4j, Inc. CC BY-SA 4.0

And today we want to look at graphs in general. Why are graphs really cool? Why are they basically a really great representation of the real world? Where can we use graphs? What are scenarios or use cases for using graphs? Looking a little bit at the property graph model and a quick introduction to Cypher, our query Language. And then what we you actually want to do is we want to go hands-on. And all of you can code along with us here because we can use Neo4j AuraDB Free, which I think was already shared in the registration notes that you should have set up an account there. So it should be pretty straightforward and quick to create a database there. And I thought today also to make it a little bit more fun, we'll have a look at some Stack Overflow data to see what we can do with something where I guess most of you spent quite some time every day. And so we can look at some Stack Overflow data and then I'll show you where you can continue your graph journey and such.

4 of 74

Because it takes a few minutes to launch

Let's get started on

AuraDB Free

neo4j.com/aura

Ask in the chat if something doesn't work!

Neo4j, Inc. CC BY-SA 4.0

5 of 74

Time to have a go! With AuraDB Free

We are going to:

Go to console.neo4j.io
Register (need to verify email)
Login
Select Top Left "Start Here" Database
Click “Create Database”
Download the generated credentials - keep it safe!�(The .env file can be opened with any text editor)

Neo4j, Inc. CC BY-SA 4.0

6 of 74

Neo4j, Inc. CC BY-SA 4.0

7 of 74

Neo4j, Inc. CC BY-SA 4.0

8 of 74

Neo4j, Inc. CC BY-SA 4.0

9 of 74

Neo4j, Inc. CC BY-SA 4.0

10 of 74

Neo4j, Inc. CC BY-SA 4.0

11 of 74

What is a graph?

versus

Neo4j, Inc. CC BY-SA 4.0

12 of 74

A graph is...

...a set of discrete entities, each of which has some set of relationships with the other entities

Seven Bridges of Konigsberg problem. Leonhard Euler, 1735

Neo4j, Inc. CC BY-SA 4.0

First of all: what is a graph?��A graph is a collection of objects, each of which has a set of binary links 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. If you’re curious, we can talk about the Seven Bridges problem and Euler’s proof, but this is all deep background for the main topics of interest.��

************************************************�***** Optional: What is the Seven Bridges problem? *****

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 on the left.��The Seven Bridges problem is this: is there any possible route through the city that crosses every bridge exactly once?

Some pen-and-paper 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 landmasses, each represented by a node, and seven bridges, each represented by a relationship�

�************************************************�****** Extra Optional: What was Euler’s proof? ********

Euler observed the following:�

The route taken within each landmass is irrelevant. Only the sequence of bridges crossed matters.
Whenever you enter a landmass 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)

Ergo, for the problem to be solvable, every landmass (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 landmasses are touched by an odd number of bridges.

��

13 of 74

Anything can be a graph - do you have examples too?

the Internet

a water molecule

H

O

H

Neo4j, Inc. CC BY-SA 4.0

14 of 74

Why are graphs amazing?

Neo4j, Inc. CC BY-SA 4.0

Okay, what are graphs in general? So actually everything that you can connect is a graph. So I always say there's no such thing as disconnected pieces of information in the world, right? Or disconnected pieces, period, right? So there's people who have connections, historical events which kind of have reasons why they happen, but they also have outcomes. There is things like proteins in biology, for instance, right? There are things like markets, economic markets. Especially today, we see that a lot, like there's so many dependencies on markets. If someone cuts someone else off a market, then they have a lot of problems, right? And not just directly, but also transitively. So not just the organization that's cut off from the market, but also all their dependents, right? So things like network dependencies in software. For instance, what about my libraries and the libraries' libraries and transitive dependencies? And what about security there, right? So what happens if one of these libraries that I'm not directly depending on but I'm depending on like three steps removed has a security issue? I'm still affected by that because I transitively use this library. So there's lots of things. So here, for instance, water is a very simple molecule, but you of course know proteins and DNA and all kinds of organic molecules are complex networks. And then it's not just a body primary structure, but also a secondary and tertiary structures. For instance, for protein folding, that can also be the represented as graphs as well, right? And so transport networks, there's like information networks, there's even like data centers and all the cabling routers, switches and so on. So basically the means are endless. Whenever you can basically draw something on a whiteboard with arrows and circles, that can be represented as a graph. So I think graphs are everywhere. And I think that still holds true even 12 years later since I started in Neo4j.

15 of 74

Neo4j, Inc. CC BY-SA 4.0

16 of 74

Follow the flow - buying trainers

Neo4j, Inc. CC BY-SA 4.0

Why are they amazing? Because they can represent the data that you have pretty straightforward, right? So this, for instance, is an example of someone or some people buying trainers as a product. And so you can represent the product, but what you can also represent the people. You can say, what did they do with the trainers? They bought them, right? They didn't kind of sell them or wore them, but they bought them. So that's kind of the BUYS on the relationship. And then you can also capture when they were bought. You could also capture what was the price that they were bought at, or the location and things like that. So you can start with a simple model like this one, but then you can evolve it to a more complex model where you either have orders and transactions and like shopping baskets with multiple items and things like that. And then you can say, okay, based on what people bought, you can recommend them other things that they could buy. For instance, you know some jogging pants or running outfit that goes with the trainers. Or if they're like more trainers for fashion, then probably the appropriate fashion outfit or whatever. Or like a running course or gym membership or things like that, right? So that's kind of things that you can do with this. And this is really simple thing that you can easily draw on whiteboard. Usually you have two options. So either you draw an example on the whiteboard, like you see here where you really have like Alison, Jane and Ian as people, and certain piece of trainers, type of trainers, as a concrete example. Or you draw a meta model there where you basically have to say Person BOUGHT Product, or Person BUYS Product, right? And then that's the meta model. So that it's kind of different ways of presenting these models. And then because graphs are really flexible, so there's no fixed schema that you have to create upfront to manage a graph. You can add data from other sources, right? So someone posts a message on social media, other people rate these messages on social media. And then basically if you look at the dates here, then they actually based on reading that message, they actually go off and buy their trainers. And then they post on the next day their own message, right? And then someone else reads this and goes off and buys the other things. So that's actually social influencing in a nutshell, if you want to say so, right? So that's kind of how does like a hype product suddenly go viral, right? So there was this interesting book, "The Tipping Point," by Malcolm Gladwell, when does something become viral and you can present it as a graph. And then you can also trace why is this product suddenly selling so well. Oh, there's a lot of people talking about it or special people that have a lot of followers or influence are talking about it. And you can basically follow all these relationships in a graph. And here you already see that we have actually merged two graphs, right? So it's actually three. So we have the purchase graph with the people and the purchases, but here's also the social graph, one for Twitter and one for Facebook, for instance, or Meta. And so you can also imagine pulling data from other places to enrich your graph data, right? So then you could also add logistics and shipping information, or if you wanted to, if this is really like a sports domain, then you could add information about where people using these products and connect it to Strava and have the running loops of people all around there as well, right? And then you basically can pull in more information and because in a graph as soon as you have one connection point, one joint that you can connect things to, you need only one place where you connect a new piece of information to it, then you can grow your graph and add more information from other sources to it. So it's pretty powerful, both in its simplicity but also in it's flexibility and extensiveness as well. Which I personally still love really a lot. Right, and you can continue to extend this.

17 of 74

Panama, paradise, pandora papers:

simple model, powerful outcome

Neo4j, Inc. CC BY-SA 4.0

One other good example of where graphs have been used quite widely is journalistic investigation. So today we are living in a time where journalists and journalism, especially investigative journalism is more important than ever because many often the pieces of information that we would like to know are actually hidden away in secrecy or in shell companies or money flows somewhere where we don't want to go. And so, thanks to journalists, this kind of information coming from leaks is captured, analyzed, and they actually do the job that actually banks and governments should do basically is trace ownership. Trace ownership of companies, trace ownership of ships, planes, and other things, of money, of shares, of influence, right? And so the basic domain model of these investigations from the ICIJ, it's basically the Entity is a shell company. The Officer is someone who is kind of responsible for some part of the shell company. Either they're the owner or shareholder, or they're an director or officer, right? But what's actually really interesting is the shareholder, which is kind of usually hidden away. The director and officers are usually public, but they are usually employees of a law firm or an offshore entity that they pretend to be directors of the shell company. But sorry, but the actual original shareholders or beneficiaries or real owners of the shell companies are not in any public registries. That's why in these data leaks, this information also becomes public. And then you see kind of politicians, celebrities, and other people putting money away and then using shell companies to just trade, right? So instead of me giving you a million dollars, I just hand you a shell company that has a million dollars worth of equity. And I can do this behind the scenes. And no one knows from whom to whom something like this moves. And then Intermediaries are all the banks and in law firms that help Deutsche people basically to hide their money by working with these shell companies and offering these shell companies and such. So that's a pretty simple model and we can use this for actually drawing a lot of conclusions, right? So because through shell companies, you can connect Officers even over five or six hops, you can say from this one person A to this person B, what's the path that we can go through shell companies that reaches one to the other, for instance? Or who has been jointly investing or been shareholder of the same shell company over and over again. So those two people have a lot of connections. So they are more tightly connected and such. So we'll see an example of that in the Stack Overflow data model, you know.

18 of 74

18

The ICIJ Investigations data model...

Neo4j, Inc. CC BY-SA 4.0

19 of 74

Friends of friends

...or co-actors of co-actors

Neo4j, Inc. CC BY-SA 4.0

20 of 74

What are good graph scenarios?

Neo4j, Inc. CC BY-SA 4.0

21 of 74

Identifying good graph scenarios

Scenario 1: Does our problem involve understanding relationships between entities?

Recommendations
Fraud detection
Finding duplicates
Data lineage
Social Networks

Neo4j, Inc. CC BY-SA 4.0

Okay, a bunch of good graph use cases and scenarios. There are many more. And also if you go to neo4j.com/use-cases, there are many more listed in detail with example datasets, white papers and more detailed customers and so on. So if you want to learn more in detail about these, just go to neo4j.com/use-cases, and then you'll see those. So basically what I want to ask myself, should I use a graph database or should I not use a graph database? Of course I can represent this kind of connected information also with some other databases. Like within relational database and join tables or with a document database and basically arrays of IDs that point to another document, for instance, right? So but the question is, this kind of relationship that's kind of treated like a stepchild in many other databases, in a graph database that's kind of first class citizen. So whenever these relationships, this context, or this topology of my entities is as important as the entities themselves, and I want to use that to analyze my data or to work with my data, or to infer more insights from my data, than considering a graph database makes a lot of sense, right, so if those relationships are more than just a foreign key that I don't really care about as such, but it's really the relationships between entities are important in my domain. And I think personally in most domains, actually, the connections of entities are way more important than people interestingly, right? And here are some examples, and we look at those in more detail. Something else that's interesting is all kinds of hierarchies, you have hierarchies in product hierarchies, you have sales and purchase hierarchies, you have buildings, if you want to represent a building or a complex piece of machinery like an airplane. If you go like a BOM model, Bill of Materials model, then you have like the airplane, and then like all the parts and the parts consist of parts that it consist of parts and then so on. Or if you look at modern CPUs, for instance, right? So you have like substructures. Or geography, for instance. But typical things are HR and management hierarchies or sales hierarchies where you then want to manage referrals or things like that. So whenever you have like these kind of hierarchy of things, that something is under root and then goes down, then a graph is really good fit as well. Another good example is, for instance, source code and abstract syntax trees where you basically can say, okay, my program or my project is actually the root of the project and I have classes or files. And then within the files I have methods or fields and they use other pieces of my program. And then basically it builds up a tree of information. And whenever I have these kind of trees, which are just a special kind of graph, then a graph database makes a lot of sense. Okay. The next one is something that's used quite often when we are traveling. So everything that's routing-related. I don't know how many relationships are between two things, right, so for instance, if I want to go from A to B, what's the shortest path to get there? If I look at something like LinkedIn or other social networks, how far is this one person apart from me? Or as I mentioned before, the software depend supply chain or library dependency, is this kind of a first level dependency or a sixth level dependency. And one recent thing that I was not so much aware of is kind of the whole supply chain discussion, which is actually much broader than I thought it would be, so there's something like managing risk in supply chain, how risky are my suppliers and then also suppliers' suppliers? Or how much CO2 and greenhouse gases are emitted by not my first degree, but second degree, third degree, fourth degree, and supply chain as well, right? And things like that. And then sustainability is another supply chain example. So that's another one where you have like these transitive relationships and you can basically go from A to B to C to E. And graphs are really good at following these long chains of relationships as well.

22 of 74

Identifying good graph scenarios

Scenario 2: Does the problem involve a lot of self-referencing to the same type of entity?

Organisational hierarchies
Access management
Social influencers
Friends of friends

Neo4j, Inc. CC BY-SA 4.0

23 of 74

Identifying good graph scenarios

Scenario 3: Does the problem explore relationships of varying or unknown depth?

Supply chain visibility
Bill of Materials
Network management
Routing

Neo4j, Inc. CC BY-SA 4.0

24 of 74

Identifying good graph scenarios

Scenario 4: Does our problem involve discovering lots of different routes or paths?

Logistics and routing
Infrastructure management
Dependency tracing

Neo4j, Inc. CC BY-SA 4.0

And again, routing, so this is basically a British road network or train network, basically. They basically can say, can I do multi model transport like between a car, bike, public transport, and so on. And walking can I get from A to B? What's the shortest, what's the best? What's the most scenic route? And helping me to find that. So first presenting all of that as a complex knowledge graph, more or less, but then also having people find these routes and being more dynamic and having more information on the relationships that tell you, okay, is this like an easy route? Is just kind of accessible for people with disabilities? Is this something where I have a good view? Or is just something that's through a really bad part of town where it's always kind of, I'm stuck in rush hour or something like that? And then graphs can help you to represent this in the first place. But then, second, also to create routing information on top of that, right? And that's everything from personal travel to logistics, to ships, to shipping fleets and other things as well. So these were some examples. As I said, there are many more.

25 of 74

So what does a (property) graph look like?

Neo4j, Inc. CC BY-SA 4.0

There's also stuff like cybersecurity, network management, identity and access management and so on. So like the possibilities are almost endless, which is also one of the challenges for a graph is you can do so many things. So it's really hard to pinpoint out only this is like the killer use case because there are so many things that you can do with it, right? So there are also some things, if the question comes up, that are not so great for a graph database in the first place. So things like data warehouse, just number crunching on a lot data. That's not what a graph database is built for. Or if I want to ingest like massive volumes of event streams, that's also not what a graph database is built for. A graph database could represent for instance, the network of IoT devices and like a derived model of how much information flows from A to B to C to D to E, but like the pure events stream time series database is not something that you would use a graph database for. And then another aspect that graphs are not made for is just blob storage, right? So storing videos or images or larger volumes of text in a graph database, that's also not what you would do. But you would store this in either another database or onto some blob storage, like S3 or Google Cloud buckets, or Azure blob storage and such. And then just store the URL to the actual blob in your graph, right? Because then you can also use CDN and edge compute and distribution networks for all of this, which makes it much easier anyway. Okay.

26 of 74

Graph components

26

Node (Vertex)

The main data element from which graphs are constructed �

Jane

bike

Neo4j, Inc. CC BY-SA 4.0

So what does the property graph model actually look like? So I already mentioned it a number of times. What you have is these entities or elements that we call node, in math and science, it's often also called a vertex, but we felt that vertex is not a very friendly term and people are scared away, so we kind of call it node, which is more obvious what it means. And between nodes, there are relationships. In Neo4j, in particular, relationships are directed, but you can ignore the direction if you want to. And relationships always have a type, right? So because otherwise there would be just anonymous relationships and we all always want to have a type for a relationship, right? And really kind of the most important rule in graph database is there are no broken links. So there are no 404s in a graph database. If you have a relationship, then there's always a node on either side of the relationship, right? Or you don't have a node that points somewhere, but it's not there anymore. So that's kind of a rule of graph databases that that's kind of a core consistency attribute of a graph database. There are no broken links. There's always something that a relationship points to. And so that means I can't delete a node until unless I also delete its relationships. So as long as a node still has a relationship, I can't delete it as such.

27 of 74

Graph components

27

Node (Vertex)

The main data element from which graphs are constructed �

Relationship (Edge)

A link between two nodes. Has:

Direction
Type

A node without relationships is permitted. A relationship without nodes is not

Jane

OWNS

bike

Neo4j, Inc. CC BY-SA 4.0

28 of 74

Property graph database

28

Node (Vertex)

Relationship (Edge)

OWNS

Neo4j, Inc. CC BY-SA 4.0

29 of 74

Property graph database

29

Node (Vertex)

Relationship (Edge)

:Person

:Bike

OWNS

Label

Define node role (optional)

Neo4j, Inc. CC BY-SA 4.0

30 of 74

Property graph database

30

Node (Vertex)

Relationship (Edge)

:Person

:Vehicle�:Bike

OWNS

Label

Define node role (optional)
Can have more than one

Neo4j, Inc. CC BY-SA 4.0

31 of 74

Property graph database

31

Node (Vertex)

Relationship (Edge)

:Person

OWNS

Label

Define node role (optional)
Can have more than one

Properties

Enrich a node or relationship
No need for nulls!

name: Jane

make: Specialized

model: Crux Pro

since: 2018

:Vehicle�:Bike

Neo4j, Inc. CC BY-SA 4.0

Jane owning her bike. This is basically a person owning a bike, right? So that's kind of type Bike and type Person as such. And you can have more than one. Then you can also say, okay, that's not just a bike, it's a vehicle, and then there are other types of vehicles as well that person can own, right? And then on both on nodes and relationships, you can add arbitrary properties. So properties are just key value pairs, and you don't need to declare them upfront. You can add as many or as few properties as you want. And so you don't need to prepare a schema or something like that. So there might some might be some users where you only know the name or login. And some other users that fully filled out their profile. You have all their information here as well, right? And that's something that's quite nice about a graph database that these kind of attributes or properties are also dynamic. So you just store the ones that you have and you just leave off all the ones that you don't have. So for properties on relationships, oftentimes they qualify the relationships. So there's, for instance, something like a cost or distance or timeframe or things like that, or is it active or not active? That's what you would put on a relationship property. But of course you can also put other things there, right? But that's common usage of properties on relationships as such.

32 of 74

Retail Dataset - Northwind

Steps

Model
Import
Explore
Query
Build

Neo4j, Inc. CC BY-SA 4.0

33 of 74

Steps

Model
Import
Explore
Query
Build

Neo4j, Inc. CC BY-SA 4.0

34 of 74

Draw a graph model

Model

[Add Files]
Add Nodes

set label
add properties
select identity

Add Relationships

connect nodes
set name
optional properties

Neo4j, Inc. CC BY-SA 4.0

35 of 74

Map source data to your graph

Map

Add Files
Map data to node properties
Map to relationships (via identifiers)

Neo4j, Inc. CC BY-SA 4.0

36 of 74

Map source data to your graph

Map

Add Files
Map data to node properties
Map to relationships (via identifiers)

Neo4j, Inc. CC BY-SA 4.0

37 of 74

Draw Graph Model

Neo4j, Inc. CC BY-SA 4.0

38 of 74

Preview and Import your data

Import

Run Preview
Explore the graph (nodes, rels, properties)
Run Import

Fix any bugs and retry

Import Summary

rows, counts created
statements for constraints and import

Go to Explore

Neo4j, Inc. CC BY-SA 4.0

39 of 74

Import Add Files + Map

Neo4j, Inc. CC BY-SA 4.0

40 of 74

Import Map

Neo4j, Inc. CC BY-SA 4.0

41 of 74

Import �Preview

Neo4j, Inc. CC BY-SA 4.0

42 of 74

Import Results

Neo4j, Inc. CC BY-SA 4.0

43 of 74

Preview and Import your data

Explore

Run Preview
Explore the graph (nodes, rels, properties)
Run Import

Fix any bugs and retry

Import Summary

rows, counts created
statements for constraints and import

Go to Explore

Neo4j, Inc. CC BY-SA 4.0

44 of 74

Explore - Show me a Graph

Neo4j, Inc. CC BY-SA 4.0

45 of 74

Explore Path

Neo4j, Inc. CC BY-SA 4.0

46 of 74

Explore Path

Neo4j, Inc. CC BY-SA 4.0

47 of 74

Write Queries

Query

A Graph Console
Metadata Sidebar
Write your query

more queries

Visualize results as graph

explore, properties, style the graph

Visualize as table
Favorites

Neo4j, Inc. CC BY-SA 4.0

48 of 74

And now query the graph together!

Neo4j, Inc. CC BY-SA 4.0

49 of 74

Cypher

A pattern-matching query language made for graphs

49

Neo4j, Inc. CC BY-SA 4.0

Okay, and how would I create this graph database? Of course there are slides, but I actually want to do this with you together. So I just do the first few slides, and then we go into the real graph as such. So we query Neo4j and many other graph databases with Cypher, which is a pattern-based query language. So we looked at, initially, we looked at SQL. We looked at other query languages. We looked at SPARQL and others. But we didn't feel that any of those as really well suited for graphs. Either it's too verbose or too cumbersome or too unwieldy. We wanted to have something that's still humane, that's easy to read, easy to understand, can represent graphs really well. And so we built our own query language. Initially for Neo4j, but then open-sourced to everyone. And so now with open Cypher, everyone can use Cypher as a query language as well. And many graph databases already do as well. So it's a declarative query language like SQL. It's very expressive. I think it's pretty done good in kind of representing complex queries with a few lines of Cypher. It supports pattern-matching which is kind of the, everything is around pattern-matching in Cypher. And you'll see in a second, what I mean with pattern-matching and it has ASCII art. What else would you wish for?

50 of 74

Cypher

A pattern matching query language made for graphs�

Declarative
Expressive
Pattern-Matching

50

Neo4j, Inc. CC BY-SA 4.0

51 of 74

Cypher

A pattern matching query language made for graphs�

Declarative
Expressive
Pattern Matching

With ASCII ART ¯\_(ツ)_/¯

51

Neo4j, Inc. CC BY-SA 4.0

52 of 74

dev.neo4j.com/refcard

Neo4j, Inc. CC BY-SA 4.0

53 of 74

Use MATCH to retrieve nodes

//Match all nodes with a Product label

MATCH (n:Product)

RETURN n;

Neo4j, Inc. CC BY-SA 4.0

Okay, and with that, I actually want to leave the slides and go into our database. So as you're the remember, we have our Movies database running. I hope for all of you your Movie database also is now green and running. And what you can do is you can click on this "Open with" button and pick Neo4j browser as our interaction tool because that's like an interactive query UI that allows us to query the data. And so we have our database connection URL already filled in, username is Neo4j and the password is what I just pasted here into my browser tab. And you hopefully stored it safely somewhere, right? So now I have my connection to my database. And because we started with the Movies dataset, this database is already filled with some example data, not a lot, but it's a small, cute, light, little tiny dataset, so we have Movies, People, and a bunch of relationships here. And it's 171 nodes and 253 relationships. So it's really just an example dataset. You can start by clicking on one of these. So for instance, you can click on People and say, okay, what do we have here? We have 25 people. It's says LIMIT 25, so we have 25 people. Here on the right side we have the legend for our nodes as such. So if you hover over a node or click on a node and you see the attributes of a node here. You can also fold this in and fold this out or make it bigger or smaller depending on what you want to do. And then if I have these people here, I can, on one side, I can just play chasing nodes all the two hours today. That's kind of one thing that I can do. But I can also click on this and say, "Expand relationships", which is this little icon down Or I can double click also on it. And if I do this, then I see Keanu Reeves acted in all these movies, right? And then I can pick one of those movies, like "The Matrix", for instance, click on that and expand it from here. And then I see suddenly other actors, right? You will be viewing Carrie-Anne Moss and Emil, which is actually a fake. So it's kind of for us to get rid of Emil later on. And then we have directors. So people that have a director relationship to "The Matrix". Lilly and Lana Wachowski, and producers as well. All right, so this is kind of our basic dataset that we can either explore interactively like I did here. So I can for instance, say, okay, what else did, for instance, Lana Wachowski in our dataset at least, write or direct or produce, right? So I can just expand the relationships here and then continue from there. So you can also see that or interactively, I can follow my things like I would draw them on a whiteboard for these kind of small example datasets. Okay. But let's go back to our query language because that's what we wanted to talk about. And as I mentioned in the beginning, Cypher is a pattern-based query language. So if you, by the way, if you want to go to multi-line mode, you can just press shift and enter or shift and return, and it goes into multi-line mode. So it starts out in single-line mode, which is this one, but if I press shift and enter, then this gives me here the multi-line mode. By the way, just quickly, there's more stuff here on the sidebar, so we saw already here the overview of the database on the property keys. I can see more information here. I can store favorites here. So for instance, if I have a query that I really liked, then I just click on this favorite button here. Save as Favorite and then it adds it here. And then I can pick it up from here again and run it and then so on. There are guides. So we can also look at this interactively. So if you get lost or if you don't want to type stuff, then you can also go to the guides and click on any of these queries and it puts them into the input field over here. And then you can use them from here. There are also more guides available and then there's help links to important commands like help keys, quite important. And then other commands as well which are quite useful. Like history is an important command because if you want to look at what you've typed so far and want to save this, for instance, then you can do this. Or what you can also do is show the schema. So for instance, if I click here Run, then I see I have my schema between Person and Movie. And a Person can follow a Person, and Person can acted in, review a movie, produce a movie, write a movie, or direct a movie as well. So I can see actually visualization of my graph schema, of the data and my graph, and a bunch of other things. And then links to docs and to developer guides and GraphAcademy and many other things as well. Settings, most of them, we don't need to touch today. And there's only one that I think it should be checked for you, it's called Connect result nodes which is useful for beginners. When we start our graph database later on, you might want to disable this because that fetches additional connections between nodes that you return. So if I return a bunch of nodes, the browser actually goes and fetches additionally what connections exist between these node. Do you to have a nice graph visualized? But if I already could know what I want return then this Connect result nodes is not so helpful. And then bunch of license links over here. Okay, but what I want to do is we want to interactively look at Cypher. And for that, I just picked my query that I took from click on Person here, and go with this as a starting point. And then we go from here. So I'll turn this into a full screen frame here. So the frame is full screen, and then I can zoom in and out. That's actually a new feature that's actually just made it. So zooming in and out with just my mouse wheel is something that I've been waiting for a long time. So that's really great. And the new features also fit to zoom, which kind of fits my whole graph into the visualization. That's also nice. Okay. But what we want to do is kind of look at some of the Cypher aspects that we can do here. So I just moved us into a multi-line thing so it's easier to edit and move stuff around. So fifth thing that I wanted to show you is kind of these patterns here, right? Here I return the people and then I expanded them. But what I can also do is I can say, okay, give me all nodes, right, give me just 25 random nodes. So I just move this colon person. And then if I do this, then it returns both People and Movies at the same time. And then you see the connect result node actually goes off and creates all these connections between my People. So even by just fetching a bunch of nodes, I get all the visualization of the graph as such. If I don't add a limit, the browser gets a bit too little slower. This needs to basically in JavaScript manage all this graph visualization. There was a recent update to the graph visualization library. So it's a little bit better today, even with a larger data event. So for instance, this is like almost a whole movie database on one screen. And we see kind of clustering around nodes. Like the actors and directors clustering and around nodes. There are some nodes that have joint repeated actors and directors like here is "The Matrix" trilogy. So we don't have like the current movie in here and so on, right? So there's this kind of stuff. So this LIMIT I just say how much data is returned for my query and I just put it back to 25. And this is basically showing me a number of nodes and relationships. This "n" here is a variable, right? So I can call this whatever. I can call it foo or bar or m for movie or n for node. Whatever I want to call it, I'll spell it out. For instance, if I say, I want to just see movies, then I say Movie and then colon Movie is the label. And I just want to return movies. And so it returns 25 movies for me, right? And so whatever I call, this is not important. It's just for me. And I use this to later reference this element I found in my pattern as well. Right. So one thing that we can do with our elements is we can, I already mentioned that we can look at attributes here on in the side bar. But we can also look at the table view of our result, which then shows us the properties. So each movie has a tagline, a title, and a release here, and we can also have a nice ASCII table of this. So if you want to copy the results somewhere, then you can copy this ASCII table quickly as well. Okay. The other thing, if we return like nodes and relationships from our graph, then we see the graph visualization here immediately. But of course you can also return individual properties only. So for instance, we know that movies have titles and a year. And so I just say RETURN movie.title and movie dot, oh it's released, right? Oh, that's actually, of course, how could I forget? There's actually full Visual Studio Monaco code editing support. So you'll get also like highlighting and other things and code completion as well. If you press F1, you get even like typical VS Code commands as well, which is quite nice. So if you want to capitalize something or someone, right? So for instance, if this return was lowercase and I wanted to make it uppercase and I press F1 and then uppercase, Transform to Uppercase, and then my return is beautifully like this. Okay., and if I return this actually movie.title and movie.released, then I get the table back with just these attributes, right? So I can do this both for nodes and relationships. If I just want to return attributes then I can do this. And please come along with me and type these things and do it yourself so you get the feelings for the language. Don't just watch me doing stuff. I actually urge you to do it yourself. Okay, so we had our movies here that we had returned in our graph visualization and what I did before about like this manual expanding from movies to actors, you can actually also do in our query language as well. So for instance, if I want to say I have a person which has some kind of relationship to our movie, so I pass just basically the movie and the person. And if I had Connect result nodes, actually let me disable Connect result nodes. So it's a little bit more obvious. So I just go to settings here, I disable this. So if I return find a movie and a person as such and return them, let me call this person. Then I basically just get independent pairs of nodes, right? So I get a bunch of, let me make this full screen again. I get a bunch of people and a bunch of movies, and then it limits them to 25 as such. So we have only one person actually here. But what we actually want to do is we don't want to just see the movies and the people, but we want to have the people that had some role in the movie, right? So and what we do is basically we just add an arrow here. So if you squint a little bit, you can see that these round parentheses around nodes are actually like the circles on the whiteboard, right? So we can just complete circles. And then we have our little circles and the whiteboard, or here in our graph visualization. And you could imagine that these are like the round parentheses here. And similar for relationships, we just add two dashes and then greater than sign and then we have an arrow. So this even has fun ligatures that you can also enable and disable, I think. And so we can say people and their relationships to a movie, but right now, if I just run this, then the relationship should not be returned. I still will get the people on the movies because I here a variable.

54 of 74

Use MATCH to retrieve nodes

//Match all nodes with a Person label

MATCH (n:Product)

RETURN n;

��//Match all nodes with a Product label and property productName is "Chai"

MATCH (n:Product {name: "Chai"})

RETURN n;

Neo4j, Inc. CC BY-SA 4.0

and if you return r now as well, then we actually get Person node, Movie node, and the relationship between them and 25 of those, right? So if I do this, then we see, oh, suddenly we have a person and the movie, another person, and the third movie and the third person and the same movie as well, right. So and because I didn't specify any type for the relationship, it returns ACTED_IN and DIRECTED relationships as well, right? And the same on the other side here. So just as visualized as a graph because it can pull it all together and deduplicate the results. But if I look at the table view, actually I get one row for each movie, person relationship, movie, person relationship, right? So that's kind of what it actually returns, but then the visualization puts it together into a graphic visualization again. And if I were to restrict the types, so for instance, if I were to say, I only want to have people have acted in the movie, then I should only get actors. So this DIRECTED relationship here should go away. This one should go away and then so on. So let me run this. And now I only have ACTED_IN relationships here as such, right? And now I can also say if I want now to access attributes, I don't want to see the graphic result of this, then I can say movie.title, person.name and r.roles, because in ACTED_IN relationships there's a roles property of the roles that the person played in this movie. And if I run this, then I see movie title, person, and roles. And Emil is stored as a fake, but we'll get rid of him at some point. And then the other people with their roles as well. And some people played many roles in movies, that's why this is an array. Could also be presented with multiple ACTED_IN relationship that have just one role. Just a modeling decision that was made in this dataset. Okay. So that's that. The other thing that we can do here is if I just go back one level. So you can, by the way, with Command or Control Arrow Up and Down, you can go through history and then see previous things that you've run as well. By the way, if you call :help keys, as I said to you before, you see also the different keys that you can use in the editor, but also in the browser itself. Okay, and with Command + Up, I get back to my Cypher query. So if I run this, it gives me like the first degree network of a person, right? So the person who acted in movie and that's it. But what happens if I want to go from this movie further on? So who else acted in this movie? So other people that acted in this movie. Other. And then perhaps even the movies that they acted in, the other movies. otherMovies, that they acted in. So r3, I just give it r2, r3 and ACTED_IN. So this is now a complex pattern, right? But I can still imagine drawing this on a whiteboard, like person who acted in a movie and then other people that also acted in this movie and then those people acted in other movies as well, right? And then, because I don't want to spell out all the stuff, I can just say RETURN *, and then it returns basically every named element here. If I don't name one element and it's not returned but I actually want more, so RETURN * gives us the one, two, three, four hops out relationship from our starting point, right? So if I do this, I see that from one person, actually, I'm not sure with who was the starting person. Probably Keanu Reeves, looks like it. From Keanu Reeves to "The Matrix". From "The Matrix" to the actors that acted in "The Matrix". And then from here to another movie and then to another actor and then to another movie, right? So "V For Vendetta" and "Cloud Atlas" are actually our end points Here and probably also the two other Matrix movies as well. So that's like the third degree network of someone. They can spell out in really a single line of Cypher. If I had to write this in SQL, this would be one, two, three, four, five, six joins. And then I wouldn't actually see my query not anymore for all the join clauses as such. I can also, because I now kind of try to figure out who's the starting point. I can also look at, of course, the table representation and I would see that my start person would be Emil once and then Keanu Reeves or something like Lawrence Fishburne. But I can also say what I want to be to the start person. So there are two options. First option is I just put in curly braces here and say name "Keanu Reeves". So within JSON-like syntax where I put curly braces and then key value. And then, just for Keanu Reeves, get these results. So we have Keanu Reeves here and then you see the first degree to his movies. And then second degree is the actors that acted in those movies. And third degree would be the movies those actors acted in. Right. You can also say we wanna to start it with someone else. You want to say, for instance, Tom Hanks, It's another starting point. And then we see the third degree network. Tom Hanks is in the middle. And we see all of this around him. The other option in Cypher that we can use is not the curly brace syntax, which is just syntactic sugar for actually a WHERE clause. So WHERE clauses are very similar to other query languages. So I just say WHERE person.name equals Tom Hanks. And this is basically equivalent to what I had before here in my query. Because that's internally just prewritten by the query parser to this format, right? So then it basically returns the same as such. And for these WHERE predicates, I can do all kinds of stuff, right? So I can also say, and movie.released is greater than 1990 or something like that, right? So then probably some movies are let's say 2000 and then some movies are gone, and then my graph is much smaller 'cause this database doesn't have so many movies in here. So I can do the regular predicates and then add more and so on. And Neo4j also has support for special types and for daytime as well. So from that perspective, I can also do more complex things as well from that perspective, although like GIS point distances and bounding boxes and all of these other things as well. So that was that. Another really cool feature that exists here in, I mean, it's a feature that exists in all query languages. Let me just simplify this a little bit here, which is aggregation, right? So if I return person name here and count and it basically says, give me for each person, the number of movies that they acted in, right? As movies. So I see Tom Hanks acted in 12 movies. So if I comment out this WHERE clause, so by the way, comments are two slashes or a slash star like in many programing languages in Cypher. So then it would return this for every actor, the name and number of movies. What's really nice we don't need a group-by. So I always hated group-by. So that's why group-by didn't make it into Cypher because you only have to provide the grouping key. And then every aggregated field is. So as soon as you add one aggregation function, then all non-aggregated fields are automatically the grouping keys. So that's the proper statement, right? So you don't need group-by or stuff like this, which is really nice. There's also a really powerful aggregation function called COLLECT and which creates a list of stuff. And I can say, collect movie.title, then as titles, then I get all the titles for the movies that someone acted in, right? So you see here are the people and their titles, right? If I now want to say, okay, I want to sort this but I want to sort this by ORDER BY movies descending, then I can just add this after the return. And then it gives you the top 25 people. So Tom Hank leads this with 12 and then Keanu Reeves, Jack Nicholson and so on. If I wanted to, I can also do more complex operations. So for instance, instead of collecting just the titles of the movie, I can also say, okay, actually I want to have the title and the year, for instance, of the movie here. So I can just create a map of title, it's movie title, and year is movie.released, movie.released as movieDetails. And then I get a list of objects or dictionary or hashes, whatever you call them or maps back here. And of course this syntax is a little bit tedious, so there's a shorthand syntax. And you can just say stolen from GraphQL, basically we just say m and then .title .released and it will return the same. Movie will return the same thing, right? So I can combine these kind of things really nicely. Okay, I have one more thing without going into way more detail. So this only scratches the surface of Cypher. And there's way more that you can do. Actually, I have two more things. One is Cypher is composable. So each of these query parts here can be composed together by taking this RETURN and just turning it into a WITH clause. And let me just put change person to just to a person node here. I can basically do in-query aggregation and in-query filtering and in-query ordering and in-query sorting and limiting and so on. So for instance, if I want to get the top three people by movie count, right, I want the top three people by movie count, then I do this WITH. So I have an in between in the query aggregation and ordering and limiting. And then I can continue to do stuff with those people and all the other data, right? So now I can say, okay, and of those three people, I want to see if they also directed movies as well, right? So I can say, okay, I just get the top three, plus the movie information where they acted in, but then I want to see, okay, who of these top three also kind of directed movies? So I just add this. So this is almost like query part one and query part two. Query part two, right. And query part one. And I can chain as many of those together as I want, which also means that like all the stuff that you usually would do with HAVING or so you can actually do in the query part two as well, right? So you can have, there's no HAVING in Cypher. It's basically just chaining query parts together. And then we can just return person of name, for instance, collect directed.title as directedMovies. And then we also return movies and movie details as well, right? So I can do arbitrary other stuff that I want to do in the next query part and so on until at the end I can return other things as well. There are also subqueries, which are a more recent addition to the language. They then can do things as well. It's also possible. So we now see Tom Hanks has one directed movie here, 12 acted in movies, and then all the movie details. And I think he might be the only one of the top three people in our dataset that actually had also directed movies as well. So this MATCH is actually exclusive. So if this MATCH doesn't find anything, that's kind of basically it produces zero rows and then that person will not return results, right? If I turn this into an OPTIONAL MATCH then it's like an outer join, basically. And then if this doesn't produce anything, then directed will be null and this relationship will be null. And then this is kind of an empty list after all. So that means if I run this now with this OPTIONAL MATCH in part two, then I get all my actors, but they have no directed movies here because it's just an empty list then. And count would be zero. If I do count on direct, then this would be zero as well. Okay. Oh, there's one thing that I forgot that I also need to show.

55 of 74

Use MATCH and properties to retrieve nodes

//Return nodes with label Product and productName property is "Chai" - Inline

MATCH (p:Product {productName: "Chai"}) //Only works with exact matches

RETURN p;

Neo4j, Inc. CC BY-SA 4.0

56 of 74

Use MATCH and properties to retrieve nodes

//Return nodes with label Product and productName property is "Chai" - Inline

MATCH (p:Product {productName: "Chai"}) //Only works with exact matches

RETURN p;

//Return nodes with label Product and productName property is "Chai"

MATCH (p:Product)

WHERE p.productName = "Chai"

RETURN p;

Neo4j, Inc. CC BY-SA 4.0

57 of 74

Use MATCH and properties to retrieve nodes

//Return nodes with label Product and productName property is "Chai" - Inline

MATCH (p:Product {productName: "Chai"}) //Only works with exact matches

RETURN p;

//Return nodes with label Product and productName property is "Chai"

MATCH (p:Product)

WHERE p.productName = "Chai"

RETURN p;

//Return nodes with label Product, unitPrice property is between 10 and 20

MATCH (p:Product)

WHERE 10 < p.unitPrice < 20

RETURN p;

Neo4j, Inc. CC BY-SA 4.0

58 of 74

Extending the MATCH

//Find all the movies Tom Hanks is connected to

MATCH (:Product {productName:"Chai"})--(c:Category)

RETURN c.categoryName;

Neo4j, Inc. CC BY-SA 4.0

59 of 74

Extending the MATCH

//Find all the movies Tom Hanks is connected to

MATCH (:Product {productName:"Chai"})--(c:Category)

RETURN c.categoryName;

//Find all the products that are in the same category as Chai and return ordered by unitPrice descending

MATCH (:Product {productName:"Chai"})-[:PART_OF]->(c:Category)� <-[:PART_OF]-(p2:Product)

RETURN c.categoryName, p2.productName ORDER BY p2.unitPrice DESC;

Neo4j, Inc. CC BY-SA 4.0

60 of 74

MERGE

//Create a product node called "Cheese"

MERGE (p:Product {productName:"Cheese"});

Neo4j, Inc. CC BY-SA 4.0

So I'll do a few minutes on creating data and then we look at Stack Overflow as well. So let's start with deleting data, right? So as you remember, there's this kind of weird Emil person, our CEO kind of sneaked into the dataset. WHERE p.name equals 'Emil Eifrem' return p. So this is this Emil node, right? So who acted in "The Matrix", but he doesn't really belong here. So we want to get rid of him. So this kind of our first task is kind of how can we get rid of Emil? So we could say, we could try delete Emil but this would fail because Emil still has relationships, right, so relationship to "The Matrix". So either we now go off and say, okay, find also the relationships and delete the relationships and then delete to node. It's one thing that we could do. The other thing is there's a command that's called detach delete. So which deletes a node and its relationships. So if you run this then Emil is gone. And so if I try to find him again, he's no longer there, right? So that's how to get rid of data, but also we want to see how to create data actually. So imagine this dataset has people who have also reviewed movies, right? So there's Jessica and James, who have reviewed movies, and Angela. And I also wanted to review a movie, right? So you can pick your own favorite movie that you want to review. So first of all, I want to create a node for myself. So I just use this. So there are two ways of creating data. So one is called CREATE. CREATE like this, with a pattern, which is nice and quick, but if you run this twice it will create the data twice, which you probably don't want, right? There's another way it's called MERGE, which is like a GETALL CREATE or an UPSERT, and that's what I prefer at least in the beginnings when people learn Cypher. So I just create a person or multiple person where name equals Michael Hunger, which is my name. And I return this person, right? So it goes off and creates this node in my database. So of course, I hope you'll put in your own name, not my name. But if you put in my name, that's also fine. So now I can find this and I can run this as often as I want. There's only one Michael Hunger ever created in this database, right? So there's no multiple Michaels getting there. Which is the difference with if I ran CREATE then there will be like one, two, three, four Michaels, which I don't want. So I can now also find my Michael again. There's Michael. Nice. And now I can connect my personal node to a movie node. So pick your favorite movie. Movie title. I think "Forrest Gump" is in there. So we could return the movie and the person. "Forrest Gump" is not in here. Why is "Forrest Gump" not in here? I thought it was here. Not so nice, okay. Then I will pick "The Matrix". Okay, now it returned my node, my personal node and my movie node that I want to review. And now I can create relationships. And it's basically the same pattern thing, right? So I can find things with patterns, but I can also create things with patterns as you just saw with the movie node. And now I can actually merge a new relationship called from person called REVIEWED to the movie. And I can give it a variable, r, and set r.stars to 5. So I really like the first "Matrix" movie. So it gets stars and I could also set a comment as well. And that was 'Slow Mo', for instance, right, or weapons, neat weapons. How about I stick with Slow Mo? Right. So which basically means I find my person, I find my movie and then I create a relationship there too. I give it a type. If I leave off the type that's not allowed. But this MERGE also means I can run the statement as often as I want, it'll not create a second relationship between the two. That's kind of the nice thing about the UPSERT. If I had CREATE here, then it would create as many relationships if I were run this statement, right?. So and if I also return the r, then I now suddenly have the REVIEWED relationship between Michael and "The Matrix" and reviewed. If you click on this, so this is my name and here you see stars and the comment as well. So that's a little bit about creating data. So that's what you would use of getting data into the graph fields here. Another example of the Stack Overflow dataset in a second. Yeah. So that's for creating data. If you want to have some interactive way of creating data, there's a really cool new thing called, where my databases?

61 of 74

MERGE

//Create a product node called "Cheese"

MERGE (p:Product {productName:"Cheese"});

//Create an PART_OF relationship between "Cheese" and "Dairy Products"

MATCH (p:Product {productName:"Cheese"}),

(c:Category {categoryName:"Dairy Products"})

MERGE (p)-[:PART_OF]->(c);

Neo4j, Inc. CC BY-SA 4.0

62 of 74

Nodes and relationships at a glance

Description	Node	Relationship
Generic	()	-- --> -[]-
With a reference	(n)	-[r]-
With a node label or rel type	(:Product)	-[:PART_OF]-
With a label/type and an inline property	(:Product {name: 'Chai'})	-[:PART_OF {since: '2021'}]-
With a variable, label/type and an inline property	(p:Product {name: 'Chai'})	-[r:PART_OF {since: '2021'}]-

Neo4j, Inc. CC BY-SA 4.0

63 of 74

Query - Sidebar

Neo4j, Inc. CC BY-SA 4.0

64 of 74

Query - Pattern

Neo4j, Inc. CC BY-SA 4.0

65 of 74

Query - Table

Neo4j, Inc. CC BY-SA 4.0

66 of 74

Build a GraphQL API

Build

Use GraphQL Toolbox
Infer a GraphQL Schema

clean up a bit

Derive an API
API Queries

Neo4j, Inc. CC BY-SA 4.0

67 of 74

What Is GraphQL?

GraphQL is an API query language and runtime for fulfilling those queries.

GraphQL uses a type system to define the data available in the API, including what entities and attributes (types and fields in GraphQL parlance) exist and how types are connected (the data graph).

GraphQL operations (queries, mutations, or subscriptions) specify an entry-point and a traversal of the data graph (the selection set) which defines what fields to be returned by the operation.

graphql.org

Neo4j, Inc. CC BY-SA 4.0

68 of 74

GraphQL Toolbox - Type Definition

Neo4j, Inc. CC BY-SA 4.0

69 of 74

GraphQL Toolbox - Query

Neo4j, Inc. CC BY-SA 4.0

70 of 74

What Else is There?

Neo4j, Inc. CC BY-SA 4.0

71 of 74

Connectors

What else is there?

Drivers

Data Science

Libraries / Integrations

Spark
Kafka
JDBC

Python
JavaScript
Java
.Net
Go

Graph Data Science Library
Graph Data Science Python Client
Bloom Visualization

neo4j/graphql
Spring Data Neo4j
neosemantics (RDF)
APOC (utility)
NeoDash (dashboard)

Neo4j, Inc. CC BY-SA 4.0

what else is there? So I mentioned when answering the question, there are different connectors for Neo4j. There's BI connector, JDBC connector, the Kafka connector, the Spark connector for Neo4j. So you want to integrate Neo4j into other databases or data technologies, there are bunch of connectors. I showed you some of the drivers already. They are, these are the official drivers, but they are also drivers for other languages, like for instance, for Perl or Alexia, or Ruby, Rust and others that are contributed by the community. PHP as well. Graph Data Science is a really important topic. Where you take the graph, not just to build applications, but to get insights. And especially now with machine learning on graphs, there's a lot of really interesting stuff happening in this area. So if you're interested in that, check that out. We have visualization tool called Bloom, where we have separate trainings And then other integrations like really cool GraphQL integration for Neo4j. We have Spring for people that come from a Java ecosystem. Spring Data Neo4j has been one of my babies. GraphQL as well. Neosemantics integration with RDF data and pulling data back to Neo4j. Alex on Tuesday. And the update with, I mean help with utilities for Neo4j as well. So there's lots other cool stuff you can use to kind of build out Neo4j integration. So how can you continue from there? One is of course the Java session. So next the Bloom one, which is super powerful node visualization tool for Neo4j. GraphQL session, March 16th, and our data science team will talk about knowledge graphs and ML approaches for doing that. And if you follow this link, it gets you to this page where you to the other one as well. So please check them out and I'd look to see you there and such. Otherwise, I already mentioned GraphAcademy and we have a ton of videos on YouTube as well, both live streams, as well as webinars, graph connect talks, conference talks, and so on. And actually I have also conference coming up, just need to put in a teaser for that on graphconnect.com. Which is in person, I hope you'll make it there. And so it's on in June in Austin, Texas, and we can't wait to see perhaps some you have some of you there, if you can make it. If not, we'll stream, a number of those will be recorded as well, of course, right, so please join us there and we love to see if you can make it in Austin in June. And we are good.

72 of 74

So how do I continue my graph journey?

Neo4j, Inc. CC BY-SA 4.0

73 of 74

Continue your journey

Free online training and certification:

dev.neo4j.com/learn
dev.neo4j.com/datasets
neo4j.com/developer

How to, best practices, hands on and community stories:

dev.neo4j.com/videos

Come say hello :)

dev.neo4j.com/chat
dev.neo4j.com/forum

Neo4j, Inc. CC BY-SA 4.0

74 of 74

Stackoverflow Demo

:play auradb/stackoverflow

Neo4j, Inc. CC BY-SA 4.0

Demo https://youtu.be/h7mq1mrQIBQ?t=6087

So I'll do a few minutes on creating data and then we look at Stack Overflow as well. So let's start with deleting data, right? So as you remember, there's this kind of weird Emil person, our CEO kind of sneaked into the dataset. WHERE p.name equals 'Emil Eifrem' return p. So this is this Emil node, right? So who acted in "The Matrix", but he doesn't really belong here. So we want to get rid of him. So this kind of our first task is kind of how can we get rid of Emil? So we could say, we could try delete Emil but this would fail because Emil still has relationships, right, so relationship to "The Matrix". So either we now go off and say, okay, find also the relationships and delete the relationships and then delete to node. It's one thing that we could do. The other thing is there's a command that's called detach delete. So which deletes a node and its relationships. So if you run this then Emil is gone. And so if I try to find him again, he's no longer there, right? So that's how to get rid of data, but also we want to see how to create data actually. So imagine this dataset has people who have also reviewed movies, right? So there's Jessica and James, who have reviewed movies, and Angela. And I also wanted to review a movie, right? So you can pick your own favorite movie that you want to review. So first of all, I want to create a node for myself. So I just use this. So there are two ways of creating data. So one is called CREATE. CREATE like this, with a pattern, which is nice and quick, but if you run this twice it will create the data twice, which you probably don't want, right? There's another way it's called MERGE, which is like a GETALL CREATE or an UPSERT, and that's what I prefer at least in the beginnings when people learn Cypher. So I just create a person or multiple person where name equals Michael Hunger, which is my name. And I return this person, right? So it goes off and creates this node in my database. So of course, I hope you'll put in your own name, not my name. But if you put in my name, that's also fine. So now I can find this and I can run this as often as I want. There's only one Michael Hunger ever created in this database, right? So there's no multiple Michaels getting there. Which is the difference with if I ran CREATE then there will be like one, two, three, four Michaels, which I don't want. So I can now also find my Michael again. There's Michael. Nice. And now I can connect my personal node to a movie node. So pick your favorite movie. Movie title. I think "Forrest Gump" is in there. So we could return the movie and the person. "Forrest Gump" is not in here. Why is "Forrest Gump" not in here? I thought it was here. Not so nice, okay. Then I will pick "The Matrix". Okay, now it returned my node, my personal node and my movie node that I want to review. And now I can create relationships. And it's basically the same pattern thing, right? So I can find things with patterns, but I can also create things with patterns as you just saw with the movie node. And now I can actually merge a new relationship called from person called REVIEWED to the movie. And I can give it a variable, r, and set r.stars to 5. So I really like the first "Matrix" movie. So it gets stars and I could also set a comment as well. And that was 'Slow Mo', for instance, right, or weapons, neat weapons. How about I stick with Slow Mo? Right. So which basically means I find my person, I find my movie and then I create a relationship there too. I give it a type. If I leave off the type that's not allowed. But this MERGE also means I can run the statement as often as I want, it'll not create a second relationship between the two. That's kind of the nice thing about the UPSERT. If I had CREATE here, then it would create as many relationships if I were run this statement, right?. So and if I also return the r, then I now suddenly have the REVIEWED relationship between Michael and "The Matrix" and reviewed. If you click on this, so this is my name and here you see stars and the comment as well. So that's a little bit about creating data. So that's what you would use of getting data into the graph fields here. Another example of the Stack Overflow dataset in a second. Yeah. So that's for creating data. If you want to have some interactive way of creating data, there's a really cool new thing called, where my databases?