Graph Query Language: Difference between revisions

Revision as of 12:18, 11 November 2019

Revision as of 12:26, 11 November 2019

Line 10:

==The property graph data model==

A property graph closely resembles a conceptual data model expressed in an Entity Relationship model or in a UML class diagram. Entities or concepts are modelled as nodes, and relationships as edges, in a graph. Nodes and edges, collectively known as elements, have attributes. Those attributes may be data values, or labels (tags). Values of properties cannot be elements of graphs, nor can they be whole graphs: these restrictions intentionally force a clean separation between the topology of a graph, and the attributes carrying data values in the context of a graph topology. Each property graph may have a set of labels and a set of properties that are associated with the graph as a whole. Current graph database products and projects often support a limited edition of the model described here. For example, Apache Tinkerpop<ref naemname="Tinkerpop">{{cite web|url=http://tinkerpop.apache.org/|title=Apache Tinkerpop|last=|first=|date=|website=|publisher=Apache Software Foundation|accessdate=November 11, 2019}</ref> forces each node and each edge to have a single label; Cypher allows nodes to have zero to many labels, but relationships only have a single label (called a reltype). Neo4j's database supports undocumented graph-wide properties, Tinkerpop has graph values which play the same role, and also supports "metaproperties" or properties on properties. Oracle's PGQL supports zero to many labels on nodes and on edges, whereas SQL/PGQ supports one to many labels for each. The GQL project will define a standard data model, which is likely to be the superset of these variants, and at least the first version of GQL is likely to permit vendors to decide on the cardinalities of labels in each implementation, as does SQL/PGQ.

The property graph data model therefore deliberately prevents nesting of graphs, or treating nodes in one graph as edges in another. Additional aspects of the ERM or UML models (like generalization or subtyping, or entity or relationship cardinalities) may be captured by schemas or types that describe possible instances of the general data model.