Schema Validation and Evolution for Graph Databases

Abstract

Despite the maturity of commercial graph databases, little consensus has been reached so far on the standardization of data definition languages (DDLs) for property graphs (PG). The discussion on the characteristics of PG schemas is ongoing in many standardization and community groups. Although some basic aspects of a schema are already present in Neo4j 3.5, like in most commercial graph databases, full support is missing allowing to constraint property graphs with more or less flexibility.In this paper, we focus on two different perspectives from which a PG schema should be considered, as being descriptive or prescriptive, and we show how it would be possible to switch from one to another as the application under development gains more stability. Apart from proposing concise schema DDL inspired by Cypher syntax, we show how schema validation can be enforced through homomorphisms between PG schemas and PG instances; and how schema evolution can be described through the use of graph rewriting operations. Our prototypical implementation demonstrates feasibility and shows the need of offering high-level query primitives to accommodate flexible graph schema requirements as showcased in our work. * Currently on leave at the University of Waterloo, Canada.

A mechanized formalization of GraphQL

“…To carry out the transformation the function relies on two auxiliary functions: coerce that coerces scalar values and check_scalar that checks whether the resulting values have the expected type according to the schema. 9 With this in mind, we can now define the evaluation function of selection sets. Definition 3.7.…”

Knowledge Representation and Update in Hierarchies of Graphs

“…Modern database systems are increasingly migrating towards graph-based representations as a response to the growing wealth of data-from domains as varied as social or transport networks, the semantic web or biological interaction networks-that are most naturally expressed in those terms. However, unlike traditional relational DBs or earlier graph-based formats such as RDF, most graph DBs based on the richer model of property graphs [9,2] do not provide a native notion of schema. Our notion of hierarchy provides a mathematical framework for this.…”

“…Our theory of propagation of rewriting in a hierarchy precisely captures the ways in which schema-aware DBs can be updated: a descriptive update occurs when the data is modified and the schema has to adjust accordingly; while a prescriptive update occurs when the schema is modified and the data needs to be adjusted [2]. More precisely, if we add a node to the data graph and choose not to specify that its type already exists in the schema graph, in order to maintain the homomorphism from data to schema, we must propagate this operation to the schema graph to create a new node in the schema graph to type the new node of the data graph; similarly, if we merge two nodes of different types of the data graph, we must merge the corresponding typing nodes of the schema.…”

“…Our theory thus provides a specification of how to enforce an abstraction barrier on a schema-less graph DB that provides the illusion of being schemaaware. Our Python library ReGraph implements this for the Neo4j graph DB by fixing an encoding of the data and schema graphs and the typing homomorphism within the single graph provided by Neo4j and translating any combination of clone, delete, add and merge operations into a corresponding query written in the Cypher query language used by Neo4j [2]. More importantly, our theory also provides a specification of how to enforce the abstraction barrier for an arbitrary hierarchy-modulo the need to fix the encoding into Neo4j and the translation of update operations into Cypher.…”

“…As written, this is not a bona fide rule application because x 1 is not necessarily a mono; however, this is equivalent to applying the projection of r 1 as explained in section 3. We conclude by updating G 0 , by taking the PO of m and r, and obtain the retyping h + 01 : G + 0 → G + 1 as per (2).…”