One-to-One (1:1) Cardinality

In Entity-Relationship modeling, cardinality specifies the numerical constraints on entity participation in relationships. It answers a fundamental question: How many entities from one set can associate with how many entities from another set through a given relationship?

Cardinality is not merely a modeling formality—it is the formal mechanism by which database designers encode real-world business rules into the schema itself. A correctly specified cardinality constraint prevents invalid data from ever entering the database, shifting enforcement from application logic to the data layer where it belongs.

Among all cardinality types, one-to-one (1:1) represents the most restrictive form. It enforces a strict bijective mapping between participating entities: each entity on one side associates with at most one entity on the other side, and vice versa. This constraint captures rare but critical real-world scenarios where such exclusivity is fundamental to the domain's integrity.

Let us establish the formal semantics of one-to-one cardinality with mathematical precision. Consider a binary relationship R between entity sets E₁ and E₂.

Definition:

A relationship R between entity sets E₁ and E₂ has one-to-one (1:1) cardinality if and only if:

1. For every entity e₁ ∈ E₁, there exists at most one entity e₂ ∈ E₂ such that (e₁, e₂) ∈ R
2. For every entity e₂ ∈ E₂, there exists at most one entity e₁ ∈ E₁ such that (e₁, e₂) ∈ R

This definition imposes a symmetric constraint: the restriction applies from both directions. Neither side can participate with multiple partners through R.

The Mapping Function Perspective:

We can view a 1:1 relationship as defining two partial functions:

f: E₁ → E₂    (maps each E₁ entity to at most one E₂ entity)
g: E₂ → E₁    (maps each E₂ entity to at most one E₁ entity)

These functions are inverses of each other on their domains:

• If f(e₁) = e₂, then g(e₂) = e₁
• If g(e₂) = e₁, then f(e₁) = e₂

This inverse property is unique to 1:1 relationships and does not hold for 1:N or M:N cardinalities.

Constraint Enforcement:

The 1:1 constraint can be enforced through several mechanisms in the relational implementation:

1. UNIQUE constraint on foreign key: The most common approach—placing a unique constraint on the referencing column ensures no two parent entities reference the same child

2. Primary key on foreign key: Making the foreign key itself the primary key (merged table approach) guarantees uniqueness by definition

3. Application-level enforcement: Checking constraints before insertion (discouraged as it's prone to race conditions and bypasses)

4. Trigger-based enforcement: Database triggers that reject violations (useful when constraint logic is complex)

The choice of enforcement mechanism affects both performance and the flexibility to handle participation changes over time.

One-to-one relationships are relatively rare in database design compared to their 1:N and M:N counterparts. When they do occur, they typically reflect strict real-world exclusivity requirements. Let's examine several canonical examples:

The User-Profile Paradigm:

One of the most common 1:1 patterns in modern systems is the separation of authentication data from profile data:

USER ENTITY:
├── user_id (PK)
├── email
├── password_hash
├── created_at
└── last_login

PROFILE ENTITY:
├── profile_id (PK)
├── user_id (FK, UNIQUE) → enforces 1:1
├── display_name
├── avatar_url
├── bio
└── preferences (JSON)

Why separate what could be one table?

1. Access pattern optimization: Authentication queries (frequent, security-critical) don't load profile data

2. Security isolation: Profile data can have different access controls than credentials

3. Schema evolution: Profile fields change often; auth schema rarely changes

4. Caching strategies: Profile data can be cached aggressively; auth data requires freshness

5. Microservice decomposition: Each entity can be owned by a different service

Medical Record Example:

Consider a hospital system modeling patients and their medical records:

PATIENT ↔ MEDICAL_RECORD (1:1 if consolidated record model)

In this model, each patient has one master medical record that aggregates all their health information. The 1:1 constraint ensures data consolidation and prevents fragmentation.

However, this model has evolved. Modern healthcare increasingly uses:

PATIENT ↔ ENCOUNTERS (1:N)
ENCOUNTER ↔ OBSERVATIONS (1:N)

The shift from 1:1 to 1:N reflects changing understanding of medical data—encounters are discrete events, not a monolithic record. This evolution illustrates how domain understanding affects cardinality choices.

Different ER notation styles represent one-to-one cardinality in distinct ways. Understanding these variations is essential for reading diagrams from diverse sources and communicating with colleagues who may use different conventions.

Chen Notation Details:

In Peter Chen's original ER notation:

[ENTITY_A]──1──<RELATIONSHIP>──1──[ENTITY_B]

Example:
[EMPLOYEE]──1──<ASSIGNED>──1──[COMPANY_CAR]

The numbers '1' on each side indicate that:

• Each employee is assigned to at most 1 company car
• Each company car is assigned to at most 1 employee

The relationship diamond (<ASSIGNED>) contains the verb describing the association.

Crow's Foot Notation Details:

In Crow's Foot notation, the 1:1 relationship appears as:

[ENTITY_A] ||─────────|| [ENTITY_B]

The || symbol (two vertical lines) means "exactly one" or "at most one"
No crow's feet (the three-pronged fork) appear on either side

Some variations distinguish between:

• || = exactly one (mandatory)
• |o = zero or one (optional)

This allows expressing participation constraints alongside cardinality.

Min-Max (Structural) Notation Details:

The (min, max) notation explicitly states the minimum and maximum number of participations:

[ENTITY_A]──(0,1)──<RELATIONSHIP>──(0,1)──[ENTITY_B]

Or with total participation:
[ENTITY_A]──(1,1)──<RELATIONSHIP>──(1,1)──[ENTITY_B]

Interpretation:

• (0,1): Optional participation, at most one partner
• (1,1): Mandatory participation, exactly one partner

For the Employee-CompanyCar example:

[EMPLOYEE]──(0,1)──<ASSIGNED>──(0,1)──[COMPANY_CAR]

This reads as:

• Each employee can be assigned to 0 or 1 company car (optional)
• Each company car can be assigned to 0 or 1 employee (optional)

If all company cars must be assigned:

[EMPLOYEE]──(0,1)──<ASSIGNED>──(1,1)──[COMPANY_CAR]

Now each company car MUST have exactly one employee assigned.

A natural question arises when encountering 1:1 relationships: If two entities are always in a strict one-to-one correspondence, why not combine them into a single entity?

This is a legitimate design consideration. Indeed, some 1:1 relationships are artifacts of overmodeling and should be merged. However, there are several principled reasons to maintain separate entities even with 1:1 cardinality:

Decision Framework:

When evaluating whether to keep a 1:1 as separate entities:

Most real-world 1:1 relationships justify separation for at least one of these reasons. If none apply, merging is likely the better choice.

Case Study: Splitting a Large Entity

Consider a poorly designed EMPLOYEE table:

CREATE TABLE employee (
    employee_id     INT PRIMARY KEY,
    -- Personal info
    first_name      VARCHAR(50),
    last_name       VARCHAR(50),
    date_of_birth   DATE,
    ssn             CHAR(11),           -- Sensitive!
    -- Employment info  
    hire_date       DATE,
    department_id   INT,
    salary          DECIMAL(10,2),      -- Sensitive!
    -- Profile info
    bio             TEXT,               -- Large, rarely accessed
    profile_photo   BYTEA,              -- Very large!
    preferences     JSONB,              -- Frequently updated
    -- Audit info
    created_at      TIMESTAMP,
    updated_at      TIMESTAMP,
    last_login      TIMESTAMP
);

Problems:

1. Every SELECT * retrieves potentially large photo data
2. Department listing queries unnecessarily read salary data
3. Profile updates lock rows that payroll is also accessing
4. Security policies must cover the entire row

Better Design (1:1 Decomposition):

[EMPLOYEE_CORE] ──1:1── [EMPLOYEE_SENSITIVE]
                ──1:1── [EMPLOYEE_PROFILE]

Each 1:1 relationship enables targeted access, independent locking, and appropriate security policies. The 1:1 cardinality is maintained—each core record has exactly one sensitive record and one profile record. But the practical benefits are substantial.

When translating a 1:1 ER relationship into a relational database schema, three principal strategies exist. Each has distinct characteristics that suit different scenarios:

Strategy 1: Foreign Key Approach

Place a foreign key in ONE of the two tables, constrained with UNIQUE:

CREATE TABLE employee (
    employee_id     INT PRIMARY KEY,
    name            VARCHAR(100),
    department_id   INT
);

CREATE TABLE company_car (
    car_id          INT PRIMARY KEY,
    make            VARCHAR(50),
    model           VARCHAR(50),
    employee_id     INT UNIQUE,         -- UNIQUE enforces 1:1
    FOREIGN KEY (employee_id) REFERENCES employee(employee_id)
);

The UNIQUE constraint on employee_id ensures no two cars reference the same employee. Combined with the foreign key, this enforces:

• Each car → at most one employee (via FK + UNIQUE)
• Each employee → at most one car (since UNIQUE prevents duplicates)

Which table gets the FK?

• Place FK in the table with optional participation (if partial participation exists)
• Place FK in the table with total participation (fewer NULLs)
• If both equal, consider query patterns—FK side has the "child" semantics

Strategy 2: Merged Table

Combine both entities into a single table:

CREATE TABLE employee_with_car (
    employee_id     INT PRIMARY KEY,
    name            VARCHAR(100),
    department_id   INT,
    -- Car attributes (nullable if optional)
    car_make        VARCHAR(50),
    car_model       VARCHAR(50),
    car_license     VARCHAR(20)
);

Advantages:

• No JOIN required for combined access
• Simpler queries for fully associated entities
• Atomic updates to both aspects

Disadvantages:

• NULL proliferation if participation is partial
• Violates conceptual distinction between entities
• Schema changes affect a larger table
• May complicate security policies

Strategy 3: Same Primary Key

Both tables share the same primary key value (the dependent table's PK is also a FK):

CREATE TABLE user_account (
    user_id         INT PRIMARY KEY,
    email           VARCHAR(255) UNIQUE,
    password_hash   CHAR(60)
);

CREATE TABLE user_profile (
    user_id         INT PRIMARY KEY,   -- Same PK value as user_account
    display_name    VARCHAR(100),
    bio             TEXT,
    avatar_url      VARCHAR(500),
    FOREIGN KEY (user_id) REFERENCES user_account(user_id)
);

The profile's user_id is both its primary key (ensuring uniqueness) and a foreign key referencing user_account. This guarantees:

• Each profile has exactly one user (PK constraint + FK reference)
• Each user has at most one profile (since profile PK = user's ID)

This pattern is elegant for strong 1:1 relationships where the dependent entity has no meaning without the independent entity.

Despite their apparent simplicity, one-to-one relationships harbor several traps that can undermine data integrity, query performance, or schema evolution. Understanding these pitfalls helps you avoid them:

Case Study: The Missing UNIQUE Constraint

A developer models the Employee-CompanyCar relationship:

CREATE TABLE company_car (
    car_id          INT PRIMARY KEY,
    model           VARCHAR(50),
    employee_id     INT,
    FOREIGN KEY (employee_id) REFERENCES employee(employee_id)
    -- Missing: UNIQUE (employee_id)
);

This allows:

INSERT INTO company_car VALUES (1, 'Tesla Model 3', 101);
INSERT INTO company_car VALUES (2, 'BMW i4', 101);      -- Same employee!

Now employee 101 has two cars—the 1:1 constraint is violated. The database didn't enforce what the ER diagram specified.

The fix is simple but essential:

ALTER TABLE company_car 
ADD CONSTRAINT unique_employee UNIQUE (employee_id);

Now the second insert fails with a unique constraint violation, preserving the 1:1 invariant.

We have deeply explored one-to-one cardinality—the most restrictive relationship constraint in ER modeling. Let's consolidate the essential takeaways:

What's Next:

One-to-one relationships, while important, are the least common cardinality in practice. The next page explores one-to-many (1:N) cardinality—by far the most prevalent relationship type in database design. You'll see why 1:N captures the hierarchical nature of most real-world associations and how its mapping strategies differ fundamentally from 1:1.