A strong entity can exist independently and can be uniquely identified without relying on another entity. In an E-R diagram, recognizing strong entities helps clarify dependency relationships and refine the database design. section 5.8
Movie and ticket
In a movie theater database, movie is strong because a movie can exist independently. Ticket is weak because identifying a ticket depends on its movie. A ticket may therefore use a composite primary key containing movie_id and other attributes that distinguish tickets for the same movie. section 5.8
Use these checks when deciding whether an entity should remain strong:
- Keep an entity strong when its own primary key identifies each instance and changing it to weak would not simplify the design or improve accuracy. section 5.9
- Treat a dependent entity as weak when it cannot be uniquely identified by its attributes alone and must use the related strong entity's key. section 5.8
- Compare both designs when either strong or weak modeling is possible, considering business demands, data representation, maintenance, and performance. section 5.8
- Remember that a junction table linking two strong entities is weak by nature and uses both entity keys as its composite primary key. section 5.9
Refining an application database
In The Sci-Fi Collective design, purchase and product are strong entities, while purchase_product is weak because it links them in a many-to-many relationship. user_address can instead become weak when email alone identifies each address belonging to a user, removing the separate address_id foreign-key arrangement. section 5.9
