Cardinality & ER Notation

Two diagrams sit in front of you. Both say Student — enrolls in — Course. They look identical.

One of them needs three tables to build. The other needs two.

Nothing in either picture tells you which is which. Something is missing.

Why & what

What's missing is how many.

A diamond only says "these two are connected." It doesn't say whether one student connects to one course or to fifty. And that single fact decides how many tables you end up building. So a relationship without it isn't finished — it's half a drawing.

Cardinality means: for one instance of this entity, how many instances of the other entity can it connect to? There are three cases — one-to-one (1:1), one-to-many (1:N), and many-to-many (M:N).

How it works

You already know how to draw boxes and diamonds. Now we add numbers to the line between them.

For each case, ask the same question in both directions.

1. 1:1 — Student and Locker. One student gets one locker. One locker holds one student. Both answers are "one." So: Aisha ↔ locker L-12.
2. 1:N — Instructor and Course. Prof. Rao teaches DBMS 101 and DBMS 202 — that's many. But DBMS 101 has exactly one instructor — that's one. One direction says many, the other says one. This is the most common case in real systems.
3. M:N — Student and Course. Aisha takes DBMS 101 and OS 101. And DBMS 101 has both Aisha and Ben in it. Many in both directions.
4. Mark it on the line. ER diagrams write 1 and N on the connecting line. Some styles draw a split "crow's foot" on the many side instead. Same meaning.
5. See what it costs you. 1:1 and 1:N fit in two tables — the "many" side just stores a pointer back to the "one" side. M:N does not fit in two tables. You need a third table in the middle. That's exactly why your Enrollment table exists: it's the bridge for a many-to-many.

Common confusion

Direction confuses almost everyone.

"One-to-many" isn't a label for the whole relationship. It depends on which side you read from. Instructor → Course is 1:N. The exact same relationship read as Course → Instructor is N:1.

Nothing changed except your starting point.

So don't argue about which one is right. Just say the direction out loud — "one instructor teaches many courses" — and the confusion disappears.

Second thing people mix up: how many vs is it required.

• Cardinality = how many? (one, or many)
• Participation = is it compulsory? (must have one, or can have none)

A student might have zero lockers. Still 1:1 for cardinality — but optional for participation.

Interviewers like this one, because most candidates treat them as the same thing.

Interview angle

1. "How would you implement a many-to-many relationship?" — With a third table in the middle (called a junction or bridge table), holding a pointer to each side: Enrollment(roll_no, course_code). Say why too: neither original table can hold a list of unknown length.
2. "Give a real 1:1 example — and why would you even split it into two tables?" — Student and locker. Or a user and their login password. Reasons to split: keep sensitive data separate, or keep rarely-used bulky columns out of the main table.
3. "Difference between cardinality and participation?" — Cardinality is how many, participation is whether it's required. One example each beats any definition.

Recap

Cardinality (1:1, 1:N, M:N) says how many instances connect, and it decides your table count — only M:N forces a third, junction table.