Fix terminology consistencies (vertex to node and relationship to edge)
Reviewers: buda, mtomic Reviewed By: buda Differential Revision: https://phabricator.memgraph.io/D1526
This commit is contained in:
parent
23d4391c29
commit
4d3c0a2fa5
@ -21,7 +21,7 @@
|
||||
* [Enterprise Ed.] Improve Cartesian support in distributed queries.
|
||||
* [Enterprise Ed.] Improve distributed execution of BFS.
|
||||
* [Enterprise Ed.] Dynamic graph partitioner added.
|
||||
* Static vertices/edges id generators exposed through the Id Cypher function.
|
||||
* Static nodes/edges id generators exposed through the Id Cypher function.
|
||||
* Properties on disk added.
|
||||
* Telemetry added.
|
||||
* SSL support added.
|
||||
@ -83,7 +83,7 @@
|
||||
|
||||
* CASE construct (without aggregations).
|
||||
* Named path support added.
|
||||
* Maps can now be stored as vertex/edge properties.
|
||||
* Maps can now be stored as node/edge properties.
|
||||
* Map indexing supported.
|
||||
* `rand` function added.
|
||||
* `assert` function added.
|
||||
|
@ -63,7 +63,7 @@ with total cost of `11`. Obviously, the second query can find the true shortest
|
||||
path because it has no restrictions on the length.
|
||||
|
||||
To handle cases when the length restriction is set, *weighted shortest path*
|
||||
algorithm uses both vertex and distance as the state. This causes the search
|
||||
algorithm uses both node and distance as the state. This causes the search
|
||||
space to increase by the factor of the given upper bound. On the other hand, not
|
||||
setting the upper bound parameter, the search space might contain the whole
|
||||
graph.
|
||||
|
@ -24,15 +24,15 @@ session = driver.session()
|
||||
# After each query, call either `consume()` or `data()`
|
||||
session.run('CREATE (alice:Person {name: "Alice", age: 22})').consume()
|
||||
|
||||
# Get all the vertices from the database (potentially multiple rows).
|
||||
vertices = session.run('MATCH (n) RETURN n').data()
|
||||
# Get all the nodes from the database (potentially multiple rows).
|
||||
nodes = session.run('MATCH (n) RETURN n').data()
|
||||
# Assuming we started with an empty database, we should have Alice
|
||||
# as the only row in the results.
|
||||
only_row = vertices.pop()
|
||||
only_row = nodes.pop()
|
||||
alice = only_row["n"]
|
||||
|
||||
# Print out what we retrieved.
|
||||
print("Found a vertex with labels '{}', name '{}' and age {}".format(
|
||||
print("Found a node with labels '{}', name '{}' and age {}".format(
|
||||
alice['name'], alice.labels, alice['age'])
|
||||
|
||||
# Remove all the data from the database.
|
||||
|
@ -14,19 +14,19 @@ to model this data as a graph and demonstrate a few example queries.
|
||||
|
||||
#### Data Model
|
||||
Each TED talk has a main speaker, so we
|
||||
identify two types of nodes — `Talk` and `Speaker`. Also, we will add
|
||||
an edge of type `Gave` pointing to a `Talk` from its main `Speaker`.
|
||||
Each speaker has a name so we can add property `name` to `Speaker` node.
|
||||
Likewise, we'll add properties `name`, `title` and `description` to node
|
||||
`Talk`. Furthermore, each talk is given in a specific TED event, so we can
|
||||
create node `Event` with property `name` and relationship `InEvent` between
|
||||
identify two node labels — `Talk` and `Speaker`. Also, we will add
|
||||
an edge labelled `Gave` pointing to a node labelled `Talk` from its
|
||||
main `Speaker`. Each speaker has a name so we can add property `name` to
|
||||
`Speaker` node. Likewise, we'll add properties `name`, `title` and `description`
|
||||
to node `Talk`. Furthermore, each talk is given in a specific TED event, so we
|
||||
can create a node `Event` with property `name` and an edge `InEvent` between
|
||||
talk and event.
|
||||
|
||||
Talks are tagged with keywords to facilitate searching, hence we
|
||||
add node `Tag` with property `name` and relationship `HasTag` between talk and
|
||||
add a node `Tag` with property `name` and an edge `HasTag` between talk and
|
||||
tag. Moreover, users give ratings to each talk by selecting up to three
|
||||
predefined string values. Therefore we add node `Rating` with these values as
|
||||
property `name` and relationship`HasRating` with property `user_count` between
|
||||
predefined string values. Therefore we add a node `Rating` with these values as
|
||||
property `name` and an edge `HasRating` with property `user_count` between
|
||||
talk and rating nodes.
|
||||
|
||||
#### Example Queries
|
||||
@ -171,7 +171,7 @@ ORDER BY Speaker;
|
||||
### Football Example
|
||||
|
||||
[Football](https://en.wikipedia.org/wiki/Association_football)
|
||||
(soccer for the heathens) is a team sport played between two teams of eleven
|
||||
is a team sport played between two teams of eleven
|
||||
players with a spherical ball. The game is played on a rectangular pitch with
|
||||
a goal at each and. The object of the game is to score by moving the ball
|
||||
beyond the goal line into the opposing goal. The game is played by more than
|
||||
@ -189,7 +189,7 @@ Two of the nodes will represent the teams that have played the match, while the
|
||||
third node will represent the game itself. Both edges are directed from the
|
||||
team nodes to the game node and are labeled as `:Played`.
|
||||
|
||||
Let us consider a real life example of this model—Arsene Wenger's 1000th.
|
||||
Let us consider a real life example of this model—Arsene Wenger's 1000th
|
||||
game in charge of Arsenal. This was a regular fixture of a 2013/2014
|
||||
English Premier League, yet it was written in the stars that this historic
|
||||
moment would be a big London derby against Chelsea on Stanford Bridge. The
|
||||
@ -426,17 +426,17 @@ than 200 km in one go.
|
||||
|
||||
```opencypher
|
||||
MATCH p = (:City {name: "Zagreb"})
|
||||
-[:Road * bfs (e, v | e.length <= 200)]->
|
||||
-[:Road * bfs (e, n | e.length <= 200)]->
|
||||
(:City {name: "Paris"})
|
||||
RETURN nodes(p);
|
||||
```
|
||||
|
||||
"What is this special syntax?", you might wonder.
|
||||
|
||||
`(e, v | e.length <= 200)` is called a *filter lambda*. It's a function that
|
||||
takes an edge symbol `e` and a vertex symbol `v` and decides whether this edge
|
||||
and vertex pair should be considered valid in breadth-first expansion by
|
||||
returning true or false (or nil). In the above example, lambda is returning
|
||||
`(e, n | e.length <= 200)` is called a *filter lambda*. It's a function that
|
||||
takes an edge symbol `e` and a node symbol `n` and decides whether this edge
|
||||
and node pair should be considered valid in breadth-first expansion by
|
||||
returning true or false (or Null). In the above example, lambda is returning
|
||||
true if edge length is not greater than 200, because we don't want to bike more
|
||||
than 200 km in one go.
|
||||
|
||||
@ -446,7 +446,7 @@ time. We just have to update our filter lambda.
|
||||
|
||||
```opencypher
|
||||
MATCH p = (:City {name: "Zagreb"})
|
||||
-[:Road * bfs (e, v | e.length <= 200 AND v.name != "Vienna")]->
|
||||
-[:Road * bfs (e, n | e.length <= 200 AND n.name != "Vienna")]->
|
||||
(:City {name: "Paris"})
|
||||
RETURN nodes(p);
|
||||
```
|
||||
@ -461,15 +461,15 @@ shortest path from Zagreb to Paris along with the total length of the path.
|
||||
|
||||
```opencypher
|
||||
MATCH p = (:City {name: "Zagreb"})
|
||||
-[:Road * wShortest (e, v | e.length) total_weight]->
|
||||
-[:Road * wShortest (e, n | e.length) total_weight]->
|
||||
(:City {name: "Paris"})
|
||||
RETURN nodes(p) as cities, total_weight;
|
||||
```
|
||||
|
||||
As you can see, the syntax is quite similar to breadth-first search syntax.
|
||||
Instead of a filter lambda, we need to provide a *weight lambda* and the *total
|
||||
weight symbol*. Given an edge and vertex pair, weight lambda must return the
|
||||
cost of expanding to the given vertex using the given edge. The path returned
|
||||
weight symbol*. Given an edge and node pair, weight lambda must return the
|
||||
cost of expanding to the given node using the given edge. The path returned
|
||||
will have the smallest possible sum of costs and it will be stored in the total
|
||||
weight symbol. A limitation of Dijkstra's algorithm is that the cost must be
|
||||
non-negative.
|
||||
@ -480,7 +480,7 @@ more that 200 km in one go for our bike route.
|
||||
|
||||
```opencypher
|
||||
MATCH p = (:City {name: "Zagreb"})
|
||||
-[:Road * wShortest (e, v | e.length) total_weight (e, v | e.length <= 200)]->
|
||||
-[:Road * wShortest (e, n | e.length) total_weight (e, n | e.length <= 200)]->
|
||||
(:City {name: "Paris"})
|
||||
RETURN nodes(p) as cities, total_weight;
|
||||
```
|
||||
@ -489,7 +489,7 @@ RETURN nodes(p) as cities, total_weight;
|
||||
|
||||
```opencypher
|
||||
MATCH (:City {name: "Zagreb"})
|
||||
-[:Road * wShortest (e, v | e.length) total_weight]->
|
||||
-[:Road * wShortest (e, n | e.length) total_weight]->
|
||||
(c:City)
|
||||
RETURN c, total_weight
|
||||
ORDER BY total_weight DESC LIMIT 10;
|
||||
|
@ -670,7 +670,7 @@ functions.
|
||||
`keys` | Returns a list keys of properties from an edge or a node. Each key is represented as a string of characters.
|
||||
`labels` | Returns a list of labels from a node. Each label is represented as a character string.
|
||||
`nodes` | Returns a list of nodes from a path.
|
||||
`relationships` | Returns a list of relationships from a path.
|
||||
`relationships` | Returns a list of relationships (edges) from a path.
|
||||
`range` | Constructs a list of value in given range.
|
||||
`tail` | Returns all elements after the first of a given list.
|
||||
`abs` | Returns the absolute value of a number.
|
||||
|
@ -228,9 +228,10 @@ CREATE (u:User {name: "Alice"})-[:Likes]->(m:Software {name: "Memgraph"});
|
||||
|
||||
The above will create 2 nodes in the database, one labeled "User" with name
|
||||
"Alice" and the other labeled "Software" with name "Memgraph". It will also
|
||||
create a relationship that "Alice" *likes* "Memgraph".
|
||||
create an edge labeled "Likes". Those three graph elements jointly represent
|
||||
the fact that "Alice" *likes* "Memgraph".
|
||||
|
||||
To find created nodes and relationships, execute the following query:
|
||||
To find created nodes and edges, execute the following query:
|
||||
|
||||
```opencypher
|
||||
MATCH (u:User)-[r]->(x) RETURN u, r, x;
|
||||
@ -261,7 +262,7 @@ Telemetry is an automated process by which some useful data is collected at
|
||||
a remote point. At Memgraph, we use telemetry for the sole purpose of improving
|
||||
our product, thereby collecting some data about the machine that executes the
|
||||
database (CPU, memory, OS and kernel information) as well as some data about the
|
||||
database runtime (CPU usage, memory usage, vertices and edges count).
|
||||
database runtime (CPU usage, memory usage, node and edge count).
|
||||
|
||||
Here at Memgraph, we deeply care about the privacy of our users and do not
|
||||
collect any sensitive information. If users wish to disable Memgraph's telemetry
|
||||
|
Loading…
Reference in New Issue
Block a user