A constraint is an explicit rule about what a graph may contain. Define constraints when designing a graph dataset so its structure can be tested and, when needed, changed deliberately. A schema records the rules for graph elements; an entity-relationship (ER) diagram can show entities, relationships, and their constraints. section 8.2.2
Constraints can describe structure or data values. In a bipartite graph, for example, nodes belong to two sets and edges do not connect nodes within the same set. A rule may also limit each node to at most two connections. These statements give a graph-processing pipeline something specific to check. section 8.2.2 section 8.2.4
At left is the relationship nomenclature for ER diagrams. At right is an example of a conceptual schema using an ER diagram.
Use the ER-diagram notation and conceptual-schema example to identify where relationship constraints belong before implementing a graph. section 8.2.2
Turn a rule into a check against an instance model:
- Store the instance model in a graph database or processing system, then write queries or functions for the rule. section 8.2.4
- Check required node attributes for non-null values, permitted edge types, and unique node identifiers. section 8.2.4
- Run the checks, inspect the results, adjust the model, and validate again. Cypher, SPARQL, or Python with NetworkX are possible ways to query the graph. section 8.2.4
Keep the rules aligned with the data and the chosen system. Poorly matched modeling and software choices can create expensive workarounds; changes that overlook compatibility can create technical debt. A written constraint supports a test, but the test must still be run as the graph evolves. section 8.2.4
