Explain a Cardinality in Two Lines, Not a Story

Every cardinality worked out so far, Show to Auditorium, ShowSeat to Seat, ShowSeatType to SeatType, came from the same two questions, asked in order.

Two Questions Are All a Cardinality Ever Needs

Overthinking a cardinality is what causes wrong answers, not underthinking it. Every mistake made while working through Show-Auditorium, ShowSeat-Show, and ShowSeatType-Show earlier came from reaching for a longer explanation instead of just asking those two plain questions directly.

A long explanation doesn't make a cardinality more convincing, it makes it look less certain. In an interview specifically, stretching two lines of reasoning into a paragraph reads as someone still trying to convince themselves, not someone who already knows the answer.

Why a Mapping Class Can Never Be Many-to-Many With Either Side

Here's a question worth sitting with directly, because it looks like a contradiction at first: a mapping class exists specifically to represent a many-to-many relationship, so how can its own relationship to each side always be many-to-one?

Take a genuinely many-to-many relationship: an assignment can hold many questions, and one question can appear on many different assignments. Represent that with a mapping class, one row per assignment-question pairing, and this new question is really about that mapping class itself, not about the two original entities.

The two original entities, Assignment and Question, really are many-to-many with each other. But AssignmentQuestion, the mapping class, is a different thing entirely, and every object of it holds exactly one assignment and exactly one question, never a list of either. That's the exact same mechanism already shown twice this series: one ShowSeat object holds one show and one seat, one ShowSeatType object holds one show and one seat type.

Many mapping-class objects, together, are what actually builds the many-to-many relationship between the two real entities. Any single one of those objects, taken on its own, is many-to-one with each side it connects, because it can only ever point at one of each.

The One Exception: When the Real Relationship Is Already One-to-One

That many-to-one result isn't a fixed law of mapping classes on its own. It's a direct consequence of the relationship actually being mapped, and it only comes out many-to-one because a genuinely many-to-many (or one-to-many) relationship demands that from each side.

Picture a HusbandWife mapping class instead, holding a marriage date between one Husband and one Wife. Assuming no divorce, one husband belongs to exactly one HusbandWife object, and one wife does too. That mapping class ends up one-to-one with each side, because the real relationship it's mapping was already one-to-one to begin with. The mapping class's cardinality with each side always matches the real relationship underneath it — many-to-one when that relationship is many-to-many, and one-to-one only in the special case where it already was.