A weak entity depends on a related strong entity. The strong entity can exist independently, but the weak entity cannot and cannot be uniquely identified by its own attributes alone. section 5.8
Identify a weak entity by checking these design questions:
- Can the entity exist without the related entity? If not, it may be weak. section 5.8
- Can its attributes uniquely identify each instance? If not, combine its distinguishing attributes with the strong entity’s primary key. section 5.8
- Choose the weak-entity representation only when it simplifies the E-R diagram, improves data accuracy, or improves efficiency. section 5.10 section 5.9
Movie tickets
A movie is strong because it can exist independently. A ticket is weak because the movie helps identify it. The ticket’s composite primary key combines movie_id with attributes that distinguish tickets for the same movie; those distinguishing attributes are partial keys. If tickets must be managed independently for reselling and refunds, represent ticket as a strong entity instead. section 5.8
Junction tables and user addresses
A junction table such as purchase_product is weak by nature: its composite primary key contains the primary keys of purchase and product. A user_address table can also become weak when the related user’s key, email, uniquely identifies each address instance; in that case, the separate address_id and foreign key are unnecessary. section 5.9 section 5.9
Use the E-R figure to visualize the strong–weak dependency and the weak entity’s composite-key relationship. section 5.10
