Content deleted Content added
Refs |
|||
Line 10:
==The property graph data model==
GQL is a query language specifically for property graphs. A property graph closely resembles a conceptual data model, as 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. Property graphs are ''multigraphs'': there can be many edges between the same pair of nodes. GQL graphs can be ''mixed'': they can contain directed edges, where one of the endpoint nodes of an edge is the tail (or source) and the other node is the head (or target or destination), but they can also contain undirected (bidirectional or reflexive) edges.
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 name="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. ▼
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. The property graph data model therefore deliberately prevents nesting of graphs, or treating nodes in one graph as edges in another.
▲
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, and to choose whether to support undirected relationships.
Additional aspects of the ERM or UML models (like generalization or subtyping, or entity or relationship cardinalities) may be captured by GQL schemas or types that describe possible instances of the general data model.
==Managed alongside SQL by JTC 1/SC32 Working Group 3 (WG3) ==
| |||