Many-to-One, One-to-Many, and One-to-One

Many-to-one relationships

A many-to-one relationship is shown with an arrow in the ER diagram. The arrow points from the “many” side to the “one” side: each entity on the “many” side is related to at most one entity on the “one” side.

Consider the relationship Works_In between Employee and Department:

The arrow points to Department, meaning every Employee is related to at most one Department. A Department, however, can have many Employees — the relationship is many-to-one.

Formally: a relationship $R$ is many-to-one between $T$ (the source) and $S$ (the target) when an arrow points from $T$ to $S$. For each entity $t \in T$, there is at most one entity $s \in S$ such that $(t, s) \in R$.

One-to-many relationships

One-to-many is simply the inverse of many-to-one. If Works_In is many-to-one from Employee to Department, then it is one-to-many from Department to Employee. No new concept is needed — the arrow just points in the opposite direction.

In practice, you usually orient the arrow to match the natural reading: “an Employee works in one Department” (arrow to Department), “a Department contains many Employees” (no arrow from Department).

One-to-one relationships

If a relationship is both many-to-one between $S$ and $T$ and many-to-one between $T$ and $S$ (that is, two arrows, one on each side), then it is one-to-one:

Each Person has at most one Passport; each Passport belongs to at most one Person.

One-to-one relationships seldom occur in well-designed databases because they often suggest that the two entities could reasonably be merged into a single table. Why separate Person and Passport if every Person has exactly one Passport and vice versa? A legitimate reason might be:

• Access control: passport data is more sensitive and stored in a separately encrypted table.
• Optionality: not every Person has a Passport, and storing many NULL columns is wasteful.
• Modularity: the Passport table is managed by a different subsystem or microservice.

What “one-to-one” does NOT mean

A common confusion: “one-to-one cardinality” does not mean a 1-to-1 correspondence in the mathematical sense (a bijection). It does not require that every entity on one side must correspond to exactly one entity on the other side. Participation is separate from cardinality.

Consider this valid database instance under the Has relationship (one-to-one between Person and Passport):

Person	Passport
Alice	P-001
Bob	P-002
Carol	— (no passport)
— (no person)	P-003 (cancelled passport, unassigned)

The constraint enforced by “one-to-one” is: no Person maps to more than one Passport, and no Passport maps to more than one Person. It does not enforce that every Person has a Passport, nor that every Passport has a Person.

A violation of one-to-one cardinality would be:

Person	Passport
Alice	P-001
Alice	P-002

Alice has two passports — this breaks the rule that each Person relates to at most one Passport.

Formal notation

There are many competing diagrammatic notations for cardinality. The Part IA course does not require memorising any particular convention in detail. Here is a brief survey for awareness:

Notation	Many-to-many	Many-to-one	One-to-one
Arrow style	No arrows	Arrow to “one” side	Arrows on both sides
Crow’s foot	──0< or `──	<`	`──
UML	*..*	1..* on “many” side	1..1
(min, max)	(0, N)──(0, M)	(0, N)──(1, 1)	(1, 1)──(1, 1)

The detailed syntax of crow’s foot, UML multiplicities, and (min, max) notation is not examinable. What matters is the ability to read a diagram, identify the nature of the relationship, and reason about whether a given database instance satisfies the cardinality constraints.

Summary

• Many-to-one: an arrow points from the “many” side to the “one” side. Each source entity relates to at most one target entity.
• One-to-many: the inverse of many-to-one.
• One-to-one: arrows on both sides. Rare in practice; often signals entities that could be merged.
• One-to-one cardinality does not imply a bijection — participation is separate.
• Diagrammatic notations vary, but the conceptual understanding of cardinality is what matters for schema design.