Property Graph Model

A node (or vertex) is the fundamental unit representing a discrete entity within the graph. Each node is a container for properties and can be categorized with one or more labels.

• Primary Function: Represents entities like a Person, Product, City, or Event.
• Properties: Stores attributes as key-value pairs (e.g., name: "Alice", employeeId: 12345).
• Labels: Tags like :Customer or :Employee that group nodes by type, enabling efficient queries and schema enforcement.

An edge (or relationship) is a directed, typed connection that defines a specific link between two nodes. Relationships are first-class citizens that can also hold properties.

• Direction: Always goes from a source node to a target node (e.g., (Alice)-[:WORKS_FOR]->(Company)).
• Type: Defines the nature of the connection, such as :KNOWS, :PURCHASED, or :LOCATED_IN.
• Properties: Can store contextual attributes about the relationship itself, like a since: 2020 property on a :WORKS_FOR edge.

Properties are key-value pairs attached to both nodes and edges, storing the descriptive attributes of the graph elements. They are the mechanism for storing structured data within the flexible graph model.

• Structure: A property key (name) paired with a value of a specific data type (e.g., String, Integer, Boolean, Array).
• Example: A Product node may have properties {sku: "A1B2C3", price: 29.99, inStock: true}.
• Flexibility: Different nodes/edges of the same type can have different sets of properties, supporting schema-on-read flexibility.

A label is a tag or type assigned to a node, serving as a coarse-grained classification mechanism. Labels are central to querying, indexing, and applying schema constraints.

• Categorization: A node can have multiple labels (e.g., :Person:Customer:VIP), representing overlapping roles or types.
• Query Optimization: Labels enable the database engine to quickly filter nodes by type, making queries like MATCH (p:Person) efficient.
• Schema Foundation: Used to define uniqueness constraints (e.g., :Person(id) must be unique) and property existence constraints.

The relationship type is a mandatory, named classifier for an edge that semantically defines the nature of the connection between two nodes. It is analogous to a verb in a sentence.

• Semantic Meaning: Types like :OWNS, :REPORTED_TO, or :CONTAINS make the graph's structure self-describing.
• Query Patterns: Essential for expressive graph pattern matching (e.g., (a)-[:SENT]->(message)<-[:RECEIVED]-(b)).
• Traversal Specificity: Allows traversals to follow only specific types of connections, navigating the graph with intent.

A graph schema defines the allowed structure of a property graph, including node labels, relationship types, property keys, and their associated data types and constraints. It brings governance to the flexible model.

• Components: Typically includes vertex schemas and edge schemas.
• Constraint Examples:
  • Uniqueness: Ensure a :Product(sku) is unique.
  • Cardinality: Enforce that a :Person can have only one :HAS_SSN relationship.
  • Property Type: Mandate that a :createdOn property is a DateTime.
• Evolution: Schemas can evolve over time to accommodate new data requirements.

These define the structure for nodes and relationships in a property graph.

• Vertex Schema: Specifies the allowed labels, property keys, and data types for a category of nodes, analogous to a table definition.
• Edge Schema: Defines the relationship type, permitted source/target vertex labels, and the properties the edge can carry. Together, they enforce data integrity and enable efficient query planning.

Declarative languages for querying and manipulating property graphs.

• GQL: The International Organization for Standardization (ISO) standard language for property graphs, designed to unify graph querying.
• Cypher: A pioneering, expressive language (used by Neo4j) that uses ASCII-art syntax (e.g., (p:Person)-[:LIVES_IN]->(c:City)) to intuitively match graph patterns. Both allow for creating, reading, updating, and deleting graph data.

Fundamental identifiers for categorizing and describing graph elements.

• Label: A tag attached to a vertex or edge (e.g., Person, WORKS_FOR) that defines its type. Enables queries like MATCH (p:Person).
• Property Key: The name of an attribute (e.g., name, since, amount) on a vertex or edge. The associated value can be a string, number, boolean, or list. This key-value flexibility is central to the model's semi-structured nature.

A native graph storage and processing principle where connected nodes hold direct physical pointers or references to each other.

• Mechanism: A traversal from one node to its neighbors proceeds by following these stored pointers, not by looking up an external index.
• Benefit: This provides constant-time O(1) traversal between connected nodes, making connectedness queries (e.g., "friends of friends") extremely fast, as performance is proportional to the size of the subgraph traversed, not the overall graph.

Schema rules that enforce data quality and business logic within the property graph.

• Uniqueness Constraint: Ensures a property value (e.g., userId) is unique across all vertices of a given label, preventing duplicate entity creation.
• Cardinality Constraint: Restricts the number of relationships of a type a vertex can have. Examples include:
  • One-to-one: A Person has exactly one PASSPORT.
  • One-to-many: A Department has many EMPLOYEES.
  • Many-to-many: Students enroll in many COURSES.

Processes for managing changes and ensuring data conformity over time.

• Schema Evolution: The practice of modifying a graph schema (adding new vertex/edge types, properties) to meet changing application needs without requiring downtime or complex migrations, thanks to the model's inherent flexibility.
• Schema Validation: The act of verifying that graph data instances comply with the defined schema. Tools like SHACL (Shapes Constraint Language) or native database constraints are used to check property types, required fields, and relationship patterns.