When a relationship itself carries data — the date an employee was assigned to a project, or the quantity on an order line — which table does that data end up in once the model is mapped to relational tables, and how does the answer depend on the relationship's cardinality?

## What a relationship attribute is In a conceptual model, a relationship can carry attributes of its own — facts true of the association rather than of either participant. The date an employee joined a project, the quantity of a product on an order, the role a person holds in a team. The mapping question is where those facts end up when the diagram becomes tables. ## The rule: follow the relationship Relationships map to different structures depending on cardinality, and their attributes follow. **Many-to-many.** The relationship becomes a junction table with one row per pair. That row is the pair, so the attributes are columns on it. Quantity and unit price on an order line; grade and enrolment date on an enrolment; role and joined-on for a person in a project. **One-to-many.** The relationship is represented by the foreign key on the many side. Each row on that side has exactly one association, so the attributes become columns on that same row. If an employee belongs to exactly one department, the date they joined that department is a column on employee. **One-to-one.** Same principle: the attributes accompany the foreign key on whichever side holds it. **Ternary and higher.** The relationship has its own table containing all participants' keys, and its attributes are columns there. ## The determinant test The reliable check is to ask what the value depends on. Write down the attribute and ask which participants you must name before the value is fixed. - Depends on both participants → a genuine relationship attribute; it must live where the pair lives. - Depends on only one → it belongs to that entity, and putting it in the junction table lets the same fact be stored many times with different values. - Depends on more than the participants — say, on the pair *and* a period → the relationship has a time dimension, and both the key and the attribute placement need rethinking. That last case is common and easy to miss. "The price of a product for a customer" is a pair attribute; "the price of a product for a customer this quarter" is not, and forcing it into a pair-keyed row destroys history. ## The two symmetric mistakes **Pushing a pair attribute onto a parent.** A grade column on Student forces one grade for every course; a quantity column on Product forces one quantity for every order. Both are obviously broken once written down, yet they appear whenever someone resists creating the junction table. **Pulling an entity attribute into the junction.** Copying the product's name or list price into the order line "for convenience" creates a value that can drift from its source and must be maintained. There is one important exception: values deliberately frozen at transaction time — the price actually charged, the address actually shipped to — are genuinely attributes of the association, because they record what was true at that moment. The test is whether the business means "the product's current price" (entity attribute, do not copy) or "the price paid on this line" (relationship attribute, store it). ## Attributes on the relationship as a promotion signal When the relationship starts carrying a lot — status, approver, effective dates, its own history — the association has become an entity in its own right, and naming it (Assignment, Enrolment, OrderLine) makes the model easier to talk about. Structurally the table already exists; what changes is that it acquires its own identity and can be referenced from elsewhere. ## A note on one-to-many Candidates sometimes claim a relationship attribute always needs its own table. It does not: for one-to-many, the many-side row already represents the single association it participates in, so an extra table would add a join and store the same information. What is true is that if you later discover the relationship can repeat over time — the employee moves between departments and you must keep the history — the relationship is no longer one-to-many at all, and only then does it get a table of its own.