Relationships and Cardinality
Relationships
Relationships represent the verbs of our domain — the associations between entities. In an ER diagram, relationships are drawn as diamonds connected by lines to the participating entity rectangles.
A relationship type defines a structure; relationship instances are the concrete pairings:
Martin Campbell directed GoldenEye. Guy Ritchie directed Sherlock Holmes. John McTiernan directed Die Hard.
The same relationship type (Directed) has many instances, each linking a Person entity to a Movie entity.
Cardinality: many-to-many
The cardinality of a relationship describes how many entities on each side can participate. Consider the relationship Directed between Person and Movie:
- One person can direct multiple movies.
- One movie can have multiple directors (e.g., the Wachowskis co-directing The Matrix).
This is a many-to-many relationship: any Person can be related to zero or more Movies, and any Movie can be related to zero or more Persons.
In ER diagram notation, a many-to-many relationship has no arrows — just plain lines connecting the relationship diamond to the entities:
Recursive relationships
A relationship can connect an entity set to itself. This is a recursive (or self-referencing) relationship. For example, is_sibling relates a Person to another Person:
is_sibling is symmetric: if Alice is a sibling of Bob, then Bob is a sibling of Alice. Not all recursive relationships are symmetric — is_manager_of on an Employee entity is recursive but not symmetric.
Cardinality annotations
There are numerous notations for recording cardinality on ER diagrams: arrowheads, crow’s foot notation, UML multiplicities, (min, max) pairs, and more. The detailed syntax of these notations is not examinable in the Part IA course. What matters is understanding the concept of cardinality and being able to read and reason about the nature of a relationship:
| Relationship type | Description |
|---|---|
| Many-to-many | Each entity on either side can be related to any number of entities on the other side (including zero). |
| Many-to-one | Each entity on the “many” side relates to at most one entity on the “one” side. |
| One-to-many | The inverse of many-to-one. |
| One-to-one | Each entity on each side relates to at most one entity on the other side. |
The important skill is not the precise diagramming convention but the ability to look at a relationship and determine its cardinality from the real-world rules of the domain.
Participation constraints
Beyond cardinality (how many), there is the question of participation: must an entity participate, or can it exist independently?
- Total participation (double line): every entity in the set must participate in the relationship. Example: every Module must be offered by some Department.
- Partial participation (single line): an entity may exist without participating. Example: not every Person directs a Movie.
Participation is distinct from cardinality. A relationship can be many-to-one with total participation on the “many” side, partial on the “one” side, or any combination.
Summary
- Relationships (diamonds) connect entities and represent associations in the domain.
- Many-to-many relationships have no arrows; both sides can be associated with any number of entities on the other side.
- Recursive relationships connect an entity set to itself and may or may not be symmetric.
- Cardinality notation details are not examinable, but understanding the conceptual types (many-to-many, many-to-one, one-to-one) is essential.
- Participation constraints specify whether involvement in a relationship is mandatory or optional.