What is a cardinality constraint?
A cardinality constraint defines the maximum number of relationship instances an entity can take part in — in plain terms, how many entities on one side of a relationship can be linked to entities on the other side. It is what turns a vague “these two things are related” into a precise rule like “one department, many employees.”
Cardinality comes in four types. The notation reads left-to-right as (left side : right side), where 1 means “at most one” and M or N means “many”:
- One-to-one (1:1)
- One-to-many (1:N)
- Many-to-one (M:1)
- Many-to-many (M:N)
One-to-One (1:1)
In a one-to-one relationship, each entity on one side is linked to exactly one entity on the other side, and vice versa. A person has exactly one passport, and each passport belongs to exactly one person. Other everyday examples are a country and its capital city, or an employee and their assigned desk.
- One person holds exactly one passport, and each passport belongs to one person.
- Examples: a country and its capital city; an employee and their assigned desk.
One-to-Many (1:N)
In a one-to-many relationship, one entity on the left can be linked to many entities on the right, but each of those many links back to just one. One department has many employees, yet every employee belongs to a single department. A mother and her children, or a customer and the orders they place, follow the same pattern. This is the most common relationship in real database schemas.
- One department has many employees; each employee belongs to one department.
- Examples: a mother and her children; a customer and the orders they place.
Many-to-One (M:1)
Many-to-one is the exact same relationship as one-to-many — just read from the other direction. Many employees belong to one department. Whether you call a link one-to-many or many-to-one depends only on which side you start from, so in a schema they describe the very same connection.
- Many employees map to one department - the same link read from the other side.
- Examples: many students in one school; many orders from one customer.
Many-to-Many (M:N)
In a many-to-many relationship, both sides can link to many of the other. Each student enrolls in many courses, and each course has many students; authors and books work the same way. A relational database cannot store a many-to-many link directly, so it is implemented with a junction (join) table — for example an Enrollment table holding pairs of student_id and course_id.
- Each student enrolls in many courses, and each course has many students.
- Needs a junction table like Enrollment with student id and course id.
- Examples: authors and books; products and orders.
The four cardinalities at a glance
Put side by side, the four types are simply the combinations of “one” and “many” on each end of a relationship:
| Cardinality | What it means | Example | Notation |
|---|---|---|---|
| One-to-One | Each side maps to exactly one of the other | Person — Passport | 1 : 1 |
| One-to-Many | One on the left links to many on the right | Department — Employees | 1 : N |
| Many-to-One | Many on the left link to one on the right | Employees — Department | M : 1 |
| Many-to-Many | Many on both sides (needs a junction table) | Students — Courses | M : N |
This article was drafted with AI assistance and reviewed by a human editor before publishing.