1. Graph databse
  2. the power of graph database
  3. A labeled Property Graph model
  4. Cypher Philosophy
    1. Cypher Clauses

Graph databse

underlying storage & process Engine
labels & relationships are first class citizens in Graph database.

the power of graph database

performance flexibility agility


A labeled Property Graph model

nodes labels property relationships

  • Think of nodes as documents that store properties in the form of arbitrary key-value pairs
  • Labels group nodes together, and indicate the roles they play within the dataset.
  • Relationships connect nodes and structure the graph
  • The ability to add properties to relationships is particularly useful for providing additional metadata for graph algorithms, adding additional semantics to relationships (including quality and weight), and for constraining queries at runtime.

Cypher Philosophy

Cypher Clauses

creat merge returen where delete foreach union with start

Relationships are the royal road into the graph. Differentiating by relationship name
is the best way of eliminating large swathes of the graph from a traversal. Using one
or more property values to decide whether or not to follow a relationship incurs extra
I/O the first time those properties are accessed

We use fine-grained relationships whenever we have a closed set of relationship names

Identifiers remain available for the duration of the current query scope, but no longer. Should we wish to give long-lived names to nodes, we simply create an index for a particular label and key property combination.

We can modify the graph at a later point in time in two different ways. We can, of course, continue using CREATE statements to simply add to the graph. But we can also use MERGE, which has the semantics of ensuring that a particular subgraph structure of nodes and relationships—some of which may already exist, some of which may be missing—is in place once the command has executed. In practice, we tend to use CREATE when we’re adding to the graph and don’t mind duplication, and MERGE when duplication is not permitted by the domain.

it’s bad practice to try to conflate data elements at write time to preserve query-time efficiency.

if we model in accordance with the questions we want to ask of our data, an accurate representation of the domain will emerge.

Further, graph modeling removes the need to normalize and denormalize data using complex data management code.

The real strength of the property graph lies in its ability to encode patterns of connected nodes and relationships。A single node or relationship typically encodes very little information, but a pattern of nodes and relationships can encode arbitrarily complex ideas.
Specifically, patterns are used to match desired graph structures. Once a matching structure has been found or created, Neo4j can use it for further processing.

--Write by Marcustar,关关雎鸠,在河之洲
Download 相册