How to model a schema for a graph database?

Question

I am looking for a general aproach to realize a restrictional schema on a graph database.

I am familiar with relational database systems where one defines tables with specific columns. All incoming data is then stored exactly like one modeled in the schema of the database. All incoming data is automatically validated, i.e. one cannot store a record with missing required column values.

Graph databases, like neo4j, allow unrestricted and freestyle storage of nodes and relations. I am wondering if there is something like a schema for graph databases. I am looking for an established notation / definition or general aproach for modelling restrictive schemas in graph databases, which corresponds to table schema definitions in relational table based databases.

An example restriction could be: A node representing a "User" always needs to have at least one relation to a node representing a "Department".

I am not particularly looking for a neo4j way, but rather a general formalism or notation. Does something like this exists?

---

In meantime I have found a suggestion to add nodes to the database that define a meta model here. But I hope to find answers that can point me to established best practices, research papers or mathematical definitions like, say, A database schema is a subgraph of the overall graph and forms a bipartite graph with the nodes containing the actual data.

Answer 1

A node representing a "User" always needs to have at least one relation to a node representing a "Department"

This constrains sounds like -- orphan (isolated) vertex are now allowed -- Every vertex must be attached with a relation.

Or, is it reasonable to model "Department: string" as a property field of vertex "User" type (table).

Answer 2

Not all graph database are "schema-less". Objectivity/DB is an object-oriented and graph database that uses schema. The schema is then used, as you would expect, to constrain the data that is assigned to the fields of the object. Nodes and edges are objects.

Because Objectivity/DB is used in large object and graph databases, the schema is also used to support a "placement model", i.e. where different objects are placed in the database. The placement model speeds retrievals because the system only looks for an object of type X in those placement locations where X's have been stored.

Also, Objectivity/DB supports "schema evolution" where defined schema types can be altered and the database understands how to interpret those alterations on existing data.

Answer 3

My understanding: For the relational data model, we should try to convert it into a description of the natural language, and then convert the description of the natural language into a graph model or other model.

For example, the user table user_id is the external construction of the annotation table, then the expression is the natural language is the "user's notes", but the records in the user table are also the attributes of the user, and the records of the annotation table are the attention of itself. Attribute, both are nodes, and the relationship is an external relationship