When would you model an association among three entities as a single three-way (ternary) relationship rather than as three separate two-way relationships, and what does each choice assert about the data?
answer
- degree = number of participating entities
- can the triple be rebuilt from the pairs?
- supplier-part-project quantity
- attributes at two scopes = two relationships
- name it -> reify as an entity
basics
~20 sUse a ternary relationship when a fact is only meaningful as a triple — supplier supplies part to project — and cannot be reconstructed from the three pairs. Use separate binary relationships when each pair is an independent fact. Ternary asserts more; binaries assert less.
solid answer
~60 sThe test is whether the three-way fact **decomposes without loss**. Ask: if I record only the pairs — supplier-part, part-project, supplier-project — can I always rebuild exactly which supplier supplies which part to which project? If joining the pairs invents combinations that were never true, the fact is irreducibly ternary and must be one three-way relationship. If it rebuilds exactly, three binary relationships say the same thing more simply and let each pair exist independently. The practical signal is where the relationship's own attributes and constraints live. A quantity that only makes sense per (supplier, part, project) triple belongs on a ternary relationship; a contract date that depends only on (supplier, project) belongs on a binary one. Two attributes with different determinants are usually two relationships, not one. Ternary relationships are also harder to constrain and reason about, so I reach for one only when a genuine three-way dependency exists, and I check whether the triple is really an entity in disguise — an Assignment or a Booking the business names, tracks and gives a lifecycle.
go deeper
Knowing that degree means how many entities participate, and that most relationships are binary, is enough at this level.
Give the supplier-part-project example and the reconstruction test, and note that splitting a genuine ternary into binaries loses information.
Drive the decision from the decomposition test and from where the relationship's attributes are determined; call out that ternary constraints are harder to state and enforce.
Frame it as expressiveness versus enforceability, and treat reification as the default once the triple acquires a lifecycle, attributes or external references.
## Degree The **degree** of a relationship is how many entity types take part. Most are **binary** (degree 2). A **unary or recursive** relationship connects one entity to itself. A **ternary** relationship connects three, and higher degrees exist but are rare and usually a sign the model is under-analysed. ## The decomposition test The only rigorous way to choose is to ask whether the three-way fact can be reconstructed from its projections onto pairs. Take the textbook case: supplier S supplies part P to project J. Suppose the truth is that Acme supplies bolts to the Bridge project and nuts to the Tunnel project. Project the fact onto pairs: Acme-bolts, Acme-nuts, bolts-Bridge, nuts-Tunnel, Acme-Bridge, Acme-Tunnel. Now try to rebuild the triples by joining: the pairs also permit "Acme supplies bolts to Tunnel", which was never true. Information has been lost — the fact is irreducibly ternary and needs a single three-way relationship. Now a different case: a doctor works at a clinic, a doctor is qualified in a speciality, and a clinic offers a speciality. Each of those is independently true and none constrains the others; there is no three-way fact at all. Three binary relationships are correct, and forcing them into a ternary would over-assert — it would claim a doctor-clinic-speciality fact the business never records. So the two choices assert different things. A ternary asserts the existence of a fact about a triple. Three binaries assert three independent pair facts and, crucially, allow each pair to exist without the other two. ## Where attributes and constraints land The cleanest practical test is to look at the relationship's own data. If a quantity is a quantity *of a part, from a supplier, for a project*, it cannot be attached to any pair without losing meaning — that is a ternary. If a rate depends only on supplier and project regardless of part, it belongs on a binary relationship between those two, and if you had modelled everything as one ternary you would now be repeating that rate across every part and inviting contradictions. A model with a ternary relationship and attributes at two different scopes is telling you it is really two relationships. Splitting by scope is the fix. ## Cardinality in a ternary is different Cardinality on a ternary relationship is stated per participant *given the other two*: "for a given supplier and project, how many parts?" This is genuinely harder to elicit and easy to state loosely, which is one reason ternaries attract errors. Expect to write the constraints out in words, and expect that some of them will not be expressible structurally later — they become rules that something has to check. ## Promote it to an entity when the business names it Often the right move is not to argue about degree but to notice the triple is a thing the business already talks about: an Assignment, a Booking, a Supply Contract, an Enrolment. Once it has a name, a status, a start date, an approver, or a lifecycle, model it as an entity related to the three participants rather than as a relationship among them. This is called reification, and it buys you a place to hang attributes, the ability to reference the fact from elsewhere, and room for the fact to gain history. The cost is one more entity in the model, usually a bargain when the alternative is a relationship carrying five attributes. ## A pragmatic rule Default to binary. Reach for a ternary only when the decomposition test actually fails, and when it does, check immediately whether the business has a name for the triple — if it does, reify. Higher degrees than three should trigger a hard look: four-way facts are usually a missing entity plus some binaries. ## Watch for the false ternary The most common mistake is drawing a ternary because three entities happen to be mentioned in the same sentence of the requirements. "Employees in departments work on projects" is two binaries in most companies. Run the reconstruction test before committing; if joining the pairs reproduces exactly the intended facts and nothing more, the ternary is not just unnecessary, it is a claim the business never made.
- How do you state cardinality for a ternary relationship?Per participant, holding the other two fixed: 'for a given supplier and project, how many parts may be supplied?' Each of the three questions is asked that way, which is why ternary constraints are harder to elicit and to check than binary ones. Many of the resulting rules cannot be expressed structurally and end up as explicit checks.
- When would you turn a ternary relationship into an entity instead?When the business names the triple and manages it — an assignment, a booking, a supply contract. Reification gives the fact a place for its own attributes, a status and a lifecycle, lets other parts of the model reference it, and makes room for history. The cost is an extra entity, which is cheap relative to a relationship weighed down with attributes.
saying these in an interview costs you the question
- Drawing a ternary because three entity names appeared in the same requirements sentence
- Assuming every ternary can be safely split into three binary relationships
- Putting attributes with different determinants on a single ternary relationship
- Stating ternary cardinality as if it were binary, without fixing the other two participants
- Never considering reification, so a relationship ends up carrying status, dates and an approver