Stage 2 · L12

Read one-to-many, one-to-one and many-to-many designs

Core · original Session 2; extended normalization/cardinality visuals

Rental relationships are implemented. Optional profile/tag/warehouse/price designs are conceptual comparisons.

Cardinality describes how many related rows can belong to each side. One equipment item can have many rental rows; each rental references exactly one equipment row. That is one-to-many from Equipment to Rental and many-to-one from Rental to Equipment. The foreign key is stored on the many side so each rental can name its one item.

User to Rental has the same shape: one customer profile can own many rental records. A one-to-one profile extension would put a unique foreign key user_id on a profile table. A scalar ORM annotation alone does not prove uniqueness in PostgreSQL. The unique constraint establishes that at most one profile row can point to a given user.

A many-to-many tag design needs an association table: one item can have several tags, and one tag can describe several items. A composite primary key (equipment_id, tag_id) prevents duplicate links. Adding a comma-separated tag string to Equipment would make referential integrity and independent tag queries difficult. If the link itself has facts such as assigned_at, model that association as an entity rather than hiding those facts in a relationship.

These one-to-one and tag examples are design exercises, not fields secretly added to the running Equipment Rental API. Its implemented model remains Equipment → Rental ← User. Draw each example and place the stored foreign key on the owning table. Predict which insert a missing referenced row or duplicate unique link would reject.

lazy='raise' on Equipment.rentals and Rental.equipment makes accidental lazy database work visible. Accessing an unloaded relationship raises instead of quietly issuing another SELECT during serialization. That is a query-load policy, separate from cardinality. Stage 05 teaches joins and deliberate eager loading; do not remove this guard merely to make a template print successfully.

Equipment 1 ─── many Rental
User      1 ─── many Rental

Design only:
Profile(user_id UNIQUE FK → users.id)
EquipmentTag(equipment_id FK, tag_id FK, PRIMARY KEY pair)

Rental stores equipment_id and owner_id on the many side. A proposed Profile needs a UNIQUE user_id foreign key; a scalar ORM attribute alone is insufficient. A proposed tag link needs the composite key to reject a duplicate pair. Those extra tables are design comparisons and are not installed.