Weak Entities and Discriminators

Definition

A weak entity is an entity whose existence depends on the existence of another entity, called its identifying entity (or owner entity). A weak entity cannot be uniquely identified by its own attributes alone; it requires the identifying entity’s key as part of its identification.

In ER diagrams:

• Weak entities are drawn as double-bordered rectangles.
• The identifying relationship is drawn as a double-bordered diamond.
• The weak entity’s partial key (discriminator) is underlined with a dashed line.

Example: AlternativeTitle

Consider a film database. A Movie has a unique movie_id. The same movie might be released under different titles in different territories:

Movie (identifying)	AlternativeTitle (weak)
The Avengers (2012)	“Avengers Assemble” (UK)
The Avengers (2012)	“Marvel’s The Avengers” (US marketing)
Harry Potter and the Philosopher’s Stone	”Harry Potter and the Sorcerer’s Stone” (US)

An AlternativeTitle does not exist independently; it exists only in relation to a specific Movie. If the Movie is deleted, all its alternative titles should be deleted too.

The attribute alt_id (e.g., 1, 2, 3 within each movie) is a discriminator, not a key. To uniquely identify an AlternativeTitle, you need both:

$(\text{movie\_id}, \text{alt\_id})$

Neither attribute alone suffices:

• alt_id = 1 could refer to the first alternative title of any movie.
• movie_id = tt0848228 tells you which movie, but not which of its several alternative titles.

The discriminator is unique only within the scope of a single identifying entity. The ER diagram looks like:

The double border on AlternativeTitle and the double diamond on HasAltTitle signal the weak entity pattern.

Relational implementation

When a weak entity is mapped to a relational schema, its table includes the identifying entity’s primary key as part of its own composite primary key, plus a foreign key constraint:

CREATE TABLE AlternativeTitle (
    movie_id    INTEGER NOT NULL,
    alt_id      INTEGER NOT NULL,
    alt_title   TEXT NOT NULL,
    territory   TEXT,
    PRIMARY KEY (movie_id, alt_id),
    FOREIGN KEY (movie_id) REFERENCES Movie(movie_id)
        ON DELETE CASCADE
);

The composite primary key (movie_id, alt_id) enforces uniqueness of alternative titles within each movie. The ON DELETE CASCADE clause reflects the existential dependency: when the parent Movie is deleted, all its AlternativeTitles are automatically removed.

Identifying vs. non-identifying relationships

Not every foreign key relationship implies a weak entity. A non-identifying relationship is one where the child entity has its own independent primary key and the foreign key is just an attribute:

CREATE TABLE Employee (
    employee_id  SERIAL PRIMARY KEY,
    name         TEXT NOT NULL,
    dept_id      INTEGER REFERENCES Department(dept_id)  -- non-identifying
);

Here, Employee is a strong entity: it is identified by employee_id alone. The dept_id foreign key merely records which department the employee belongs to, but Employee could exist even if Department were deleted (assuming nullable foreign key or ON DELETE SET NULL).

When to use weak entities

Weak entities are appropriate when:

1. Existential dependency: the entity cannot meaningfully exist without the owner.
2. Identification dependency: the entity’s own attributes are insufficient for a global unique key.
3. Cascade semantics: deletion of the owner should logically delete the owned entities.

Common examples:

Domain	Strong entity	Weak entity	Discriminator
Film	Movie	AlternativeTitle	alt_id
E-commerce	Order	LineItem	line_number
University	Module	ExamPaper	paper_number
Healthcare	Patient	Appointment	visit_date

In each case, the weak entity makes no sense without its owner — a LineItem without an Order is meaningless, and its line_number = 1 is only meaningful within the scope of a specific order.

Summary

• A weak entity depends on an identifying (owner) entity for its existence and identification.
• Drawn with double borders; the identifying relationship uses a double diamond.
• A discriminator (partial key) is unique only within the scope of one owner.
• In SQL, the weak entity’s table uses a composite primary key (owner’s key + discriminator) with a foreign key constraint.
• Weak entities differ from ordinary foreign-key relationships: the owner’s key is part of the weak entity’s own identity, not just an attribute.