A composition relationship makes a part fully dependent on its containing whole. The part cannot conceptually exist independently, although objects may navigate the relationship in both directions. section 1.2 section 6.2
Use composition to decide identity, ownership, and persistence behavior:
- Treat the contained object as a value type when it cannot be shared and does not need independent identity, as with Address owned by User. section 5.1.3
- Promote a composed part to an entity when future associations create shared references, as Bid may require if users expose their bids. section 5.1.3
- Bind collections of components to the owner’s lifecycle; an Item’s Image components belong to the Item and are not independent entities. section 8.2
Embedding a composed Address
A User can contain homeAddress and billingAddress as value-type components. The USERS table stores the User and all address columns in one row; saving or deleting the User saves or deletes the component without separate SQL. section 6.2.1
User and BillingDetails
A User may own many BillingDetails objects. A BILLINGDETAILS.USERNAME foreign key references USERS.USERNAME, preserving the containment relationship in the relational schema. section 1.2
Use the UML diagram to identify the whole, the composed part, and the direction of lifecycle dependence. section 6.2
