Cardinality

A relationship where a single record in Entity A is associated with exactly one record in Entity B, and vice versa.

Key Characteristics:

• Represents exclusive, tightly coupled data
• Often used to split a large entity for performance or security (e.g., separating sensitive profile data)
• Enforced via unique foreign key constraints

Example: A User record has exactly one UserProfile record. The UserProfile belongs to exactly one User.

The most common relationship type. A single record in Entity A can be associated with multiple records in Entity B, but a record in Entity B belongs to only one record in Entity A.

Implementation:

• Modeled with a foreign key on the 'many' side table
• The foreign key column references the primary key of the 'one' side

Example: A single Author can write many Books. Each Book has only one Author.

The inverse perspective of a One-to-Many relationship. Multiple records in Entity A reference a single record in Entity B.

Key Insight:

• Functionally identical to One-to-Many; the naming depends on the directional context of the query
• The foreign key still resides on the 'many' side table

Example: Many Employees belong to one Department. This is the same relationship as 'one Department has many Employees'.

A relationship where multiple records in Entity A can be associated with multiple records in Entity B.

Implementation Requirement:

• Requires a junction table (also called an associative or join table)
• The junction table contains foreign keys referencing both Entity A and Entity B
• The combination of these foreign keys often forms a composite primary key

Example: A Student can enroll in many Courses. A Course can have many Students. This is resolved via an Enrollment junction table.

A relationship where records in a table relate to other records within the same table. This is crucial for modeling hierarchies.

Structure:

• Uses a foreign key column that references the primary key of the same table
• The foreign key is often named parent_id or manager_id

Example: An Employee table has a manager_id column. This foreign key points to the employee_id of another employee, creating a management hierarchy.

Cardinality constraints also define whether a relationship is required. This is often expressed as minimum and maximum bounds.

Notation:

• Zero or One (0..1): An entity may or may not have a related record (optional)
• Exactly One (1..1): An entity must have exactly one related record (mandatory)
• Zero or Many (0..*): An entity can have any number of related records, including none
• One or Many (1..*): An entity must have at least one related record

Example: A BlogPost may have zero or many Comments (0..*), but a Comment must belong to exactly one BlogPost (1..1).

A cardinality constraint where a single instance of Entity A is associated with at most one instance of Entity B, and vice versa. For example, a User has exactly one Profile, and that Profile belongs to only one User. In a relational database, this is typically implemented by sharing a primary key or using a unique foreign key constraint. In JSON Schema, this is modeled as a nested object rather than an array.

The most common cardinality pattern, where a single record in one entity can relate to zero, one, or many records in another entity, but each record in the second entity relates back to only one in the first. For instance, a Customer can place many Orders, but each Order belongs to exactly one Customer. This is enforced via a foreign key in the 'many' side's table.

A cardinality where multiple instances of Entity A can associate with multiple instances of Entity B. A classic example: a Student can enroll in many Courses, and each Course contains many Students. This cannot be modeled with a single foreign key. It requires a junction table (or associative entity) that holds pairs of foreign keys, effectively decomposing the relationship into two one-to-many links.

An explicit agreement between a data producer and its consumers that defines the schema, semantics, and quality guarantees of the data being exchanged. Cardinality is a critical component of a data contract, specifying the expected volume of related records. A contract might state that an Invoice must have at least one and at most one associated BillingAddress, preventing null or duplicate violations downstream.

The specification of an individual data element within a content type or schema, including its name, data type, default value, and constraints. Cardinality is a primary constraint within a field definition. For example, a field definition for 'phoneNumbers' on a Contact entity might specify a data type of Array<String> with a cardinality of 0..3, allowing up to three phone numbers but requiring none.

The automated process of checking a data instance against a defined schema to ensure it conforms to the required structure, data types, and cardinality constraints. A validation engine will reject a JSON document if an array field contains fewer items than its minItems constraint or more than its maxItems constraint. This is the enforcement mechanism that makes cardinality a runtime guarantee rather than just documentation.