Vertex Schema

The vertex label is a mandatory, categorical tag that defines the type of an entity (e.g., Person, Product, Organization). It is the primary mechanism for grouping vertices and is essential for type-based queries and schema constraints.

• Example Labels: Customer, Invoice, Sensor
• Function: Enables queries like MATCH (p:Person) RETURN p.
• Constraint Basis: Uniqueness and property constraints are typically scoped to a specific label.

Property keys define the named attributes a vertex can possess, each with an enforced data type (e.g., String, Integer, Float, Boolean, Date). This ensures data consistency and enables type-safe operations.

• Key Examples: name (String), employeeId (Integer), createdAt (DateTime)
• Type Enforcement: Prevents invalid data like assigning a string to an integer property.
• Optional vs. Required: Schemas can define if a property is mandatory or optional for a given vertex label.

A uniqueness constraint ensures that the value of a specified property (or composite set of properties) is unique across all vertices with a given label. This prevents duplicate entities and is critical for entity resolution.

• Example: A Person vertex label might have a uniqueness constraint on ssn.
• Composite Uniqueness: Enforces uniqueness on a combination, like (firstName, lastName, dateOfBirth).
• Index Creation: Implementing a uniqueness constraint typically creates a supporting index for fast lookups.

An existence constraint (or mandatory property constraint) specifies that a vertex of a certain label must have a value for a given property key. It enforces data completeness at the point of creation or update.

• Example: All Product vertices must have a sku property.
• Data Quality: Guarantees that critical attributes are never null for a vertex type.
• Schema Rigor: Contrasts with the flexible, schema-less nature of some graph databases.

While defined in an edge schema, relationship type constraints are referenced by the vertex schema. They specify which vertex labels can be the source or target of a specific relationship type, enforcing graph connectivity rules.

• Example: A PURCHASED edge schema may specify its source must be a Customer vertex and its target must be a Product vertex.
• Referential Integrity: Ensures semantically valid connections (e.g., a Person cannot IS_A a Transaction).
• Cardinality: Can be combined with rules limiting the number of allowed connections.

Indices are data structures that accelerate the retrieval of vertices based on property values. While not a constraint, they are a critical performance component of a physical vertex schema.

• Composite Index: Indexes multiple properties together (e.g., (lastName, firstName)).
• Index Types: Common types include B-tree (for exact matches and ranges) and full-text (for textual search).
• Trade-off: Indices speed up reads but add overhead to write operations and storage.

A vertex schema is the formal definition for a category of nodes in a property graph. It specifies:

• The label (e.g., Person, Product) that categorizes the vertex type.
• The allowed property keys (e.g., name, employeeId, price) and their data types (String, Integer, DateTime).
• Constraints, such as which properties are mandatory or unique.

It is directly analogous to a CREATE TABLE statement in SQL, providing the blueprint for data integrity and enabling efficient queries.

Vertex schemas act as a contract, ensuring data quality at write-time in a schema-on-write system. Key enforcement mechanisms include:

• Uniqueness Constraints: Guarantee that a property value (e.g., email) is unique across all vertices of that type, preventing duplicate entities.
• Property Type Enforcement: Reject writes where a birthDate property receives a string value if the schema defines it as a Date.
• Mandatory (NOT NULL) Properties: Ensure critical attributes like productSKU are always populated.

This is a primary differentiator from schema-on-read approaches used in some NoSQL databases.

A vertex schema does not exist in isolation; it is intrinsically linked to edge schemas. An edge schema defines valid relationship types (e.g., PURCHASED, WORKS_FOR) and specifies:

• The permitted source vertex label (e.g., Customer).
• The permitted target vertex label (e.g., Product).
• Properties allowed on the relationship itself (e.g., purchaseDate, quantity).

Together, vertex and edge schemas form a complete graph schema that models the entire domain, enabling cardinality constraints (e.g., a Person can have only one EMPLOYS relationship to a Company).

Business requirements change, necessitating schema evolution. Safe practices for modifying a vertex schema include:

• Additive Changes: Introducing a new optional property (e.g., middleName) is generally safe.
• Backwards-Compatible Modifications: Changing a property type from String to Integer requires a data migration plan for existing values.
• Breaking Changes: Removing a property or making an optional property mandatory requires careful coordination with application code and may involve writing default values for existing vertices.

Tools for schema validation (like SHACL for RDF or native database utilities) are critical for verifying data conforms to the new schema after migration.

A defined vertex schema enables the database to build efficient graph indexes. For example, if a Person vertex has a unique userId property, the database can create an index on Person(userId). This allows queries like MATCH (p:Person {userId: 123}) to execute in constant O(1) time via an index lookup, rather than a full graph scan.

Indexes are essential for fast lookups when starting a traversal and are a direct benefit of a well-designed schema. The schema informs the database which property combinations are frequently queried and should be optimized.

The concept of a vertex schema exists at two levels:

• Logical Schema: An abstract, implementation-independent model. It defines what the Product vertex is, its properties (name, category), and its allowed relationships to Supplier vertices. This is often designed using a graph schema language or diagramming tool.
• Physical Schema: The concrete implementation within a specific graph database (e.g., Neo4j, Amazon Neptune). It defines how Product vertices are stored on disk, how properties are encoded, and which indexes or partitioning strategies are used.

Schema mapping is the process of transforming a source data model (e.g., from a CSV or relational database) into the target logical and physical graph schema.

An Edge Schema defines the structure, allowed properties, and data types for a category of relationships (edges) within a property graph. It specifies the permitted source and target vertex types, establishing the valid connections in the data model.

• Key Role: Governs relationship semantics and integrity.
• Example: An EMPLOYS edge schema might define properties like start_date and department, and constrain its source to a Company vertex and its target to a Person vertex.

A Label is a tag attached to a vertex or edge that categorizes it into a specific type. It is the primary mechanism for grouping entities and is central to defining a vertex or edge schema.

• Function: Enables type-based queries (MATCH (p:Person)) and schema constraints.
• Multiple Labels: A single vertex can have multiple labels (e.g., :Person:Customer), supporting flexible classification.

A Property Key is the name or identifier for a specific attribute that can be assigned a value on a vertex or edge. The set of allowed property keys and their data types (e.g., String, Integer, DateTime) is a fundamental part of a vertex or edge schema.

• Examples: name, age, email, timestamp.
• Schema Enforcement: A schema may mandate required properties (e.g., Person must have a name) and define optional ones.

A Graph Schema Language is a formal syntax used to define the structure, constraints, and types for vertices, edges, and properties within a graph database. It provides a declarative way to express the data model.

• Native vs. Standard: Some databases use proprietary DDL (Data Definition Language), while others support standards like PG-Schema for property graphs or SHACL for RDF.
• Components: Typically includes statements for creating vertex/edge types, defining properties, and applying constraints.

A Uniqueness Constraint is a schema rule that ensures the value of a specified property (or combination of properties) is unique across all vertices or edges of a given type. It is crucial for preventing duplicate entities and ensuring data integrity.

• Common Use: Enforcing that a Person vertex has a unique employee_id or that a Product has a unique sku.
• Implementation: Often creates an underlying index to enforce the constraint efficiently.

Schema Evolution is the process of modifying a graph database's schema over time to accommodate changing application requirements. This includes adding new vertex/edge types, properties, or constraints while managing data compatibility and migration.

• Challenges: Requires careful planning for backward/forward compatibility, data migration scripts, and versioning.
• Best Practice: Use additive changes (new types, optional properties) where possible to minimize breaking existing queries and applications.