What is a weak entity in entity-relationship modeling, and how does it differ from an ordinary entity that merely has a mandatory reference to another entity?
answer
- no key of its own — identity borrowed
- partial key / discriminator
- identifying relationship, total participation
- line 3 of invoice 4711
- cannot be reparented
basics
~20 sA weak entity cannot be identified by its own attributes: it is identified only together with its owner, through an identifying relationship, using a partial key that is unique only within that owner. It also depends on the owner for existence.
solid answer
~50 sTwo things define a weak entity. First, **identification dependence**: its own attributes are not enough to tell instances apart globally. An invoice line numbered 3 means nothing until you say which invoice; the line number is a *partial key* (discriminator) unique only inside its owner. Second, **existence dependence**: it cannot exist without its owner, and the relationship to the owner — the *identifying relationship* — is mandatory. An ordinary entity with a mandatory reference has the second property but not the first. A bank account must belong to a customer, yet an account number identifies the account by itself, worldwide, and can survive being reassigned. That is a strong entity with total participation, not a weak entity. So the discriminating test is: **can you identify this instance without naming its owner?** If yes, it is strong however mandatory the link is. Typical weak entities are invoice lines, seats within a screening, and dependants identified by name within an employee.
go deeper
State that a weak entity has no key of its own, is identified together with its owner via a partial key, and cannot exist without it. Invoice line is the standard example.
Separate existence dependence from identification dependence and show that only the second makes an entity weak; give the order-versus-invoice-line contrast.
Use the reassignment and external-reference tests to catch mis-classification, and connect weakness to the real business rules it encodes about uniqueness scope and deletion.
Discuss when to deliberately reject weakness — when the child may later need to be referenced externally or reparented — and the coupling that borrowed identity imposes on every consumer of the model.
## The definition A **strong (regular) entity** has a key of its own: some attribute or combination of attributes that identifies each instance among all instances of that entity, without reference to anything else. A **weak entity** has no such key. Its instances are distinguishable only within the scope of another entity, called the **owner** or **identifying entity**, and the relationship that supplies the scope is the **identifying relationship**. The attribute that separates weak instances within one owner is the **partial key** or **discriminator**. Line number 3 is not unique among all invoice lines, but it is unique within invoice 4711. ## The two dependencies, and why only one is decisive **Existence dependence** means the weak instance cannot exist without its owner: no invoice, no invoice line. It follows that participation in the identifying relationship is total — every weak instance is related to exactly one owner, always. **Identification dependence** means you cannot say which instance you mean without naming the owner too. Existence dependence alone does not make an entity weak. Plenty of strong entities are existence-dependent: an order cannot exist without a customer in many businesses, yet an order number identifies it globally. What makes an entity weak is that its identity is borrowed. That is why the sharpest interview test is the identification question, not the mandatory-link question. ## Recognising one in the wild Signals that you are looking at a weak entity: - The natural way people refer to it is compound: "line 3 of invoice 4711", "seat 12B of the 8pm screening", "the second dependant of employee 88". - Its numbering restarts inside each owner. - Deleting the owner unambiguously destroys it — nobody would ask what happens to the lines of a deleted invoice; they go. - It is never referenced from outside without the owner in the reference. Signals that you have a strong entity instead: it carries an externally meaningful identifier (an account number, an ISBN, an employee number), it can be moved between owners, or other parts of the system point straight at it. ## Notation In Chen notation a weak entity is a double rectangle, the identifying relationship is a double diamond, and the partial key is underlined with a dashed line. Crow's-foot diagrams have no dedicated weak-entity symbol; the convention there is a solid relationship line for identifying relationships versus a dashed line for non-identifying ones, with mandatory-one on the owner end. ## Why the distinction earns its keep It makes explicit two rules that would otherwise be invented ad hoc. It says the discriminator only needs to be unique per owner, which is exactly the uniqueness rule the business believes. And it says the child cannot outlive the parent nor be reassigned to another one, which is a genuine business claim and a strong hint about how deletion should behave. It also protects you from a common over-application. If you find yourself wanting to move a "weak" instance to a different owner, or to reference it from a third place by a stable identifier, then identity is not really borrowed and you have mis-classified a strong entity. Reassignment is the cleanest counter-test: weak entities cannot be reparented, because reparenting would change who they are. ## Weak entities versus multivalued attributes Both involve several dependent things per owner. The difference is description and identity: a multivalued attribute is a bare set of values with nothing more to say about each one, whereas a weak entity has its own attributes, its own discriminator, and possibly its own relationships — an invoice line has a quantity, a price and a link to a product. When a multivalued attribute starts needing attributes of its own, it is becoming a weak entity.
- Is an order a weak entity of a customer, given that every order must have a customer?No. That is existence dependence without identification dependence. An order number identifies the order on its own — support staff quote it without naming the customer — so it is a strong entity whose participation in the relationship happens to be mandatory. Weakness requires that identity itself be borrowed from the owner.
- How would you tell a weak entity from a multivalued attribute of the same owner?Ask whether each dependent item needs facts of its own. A bare set of values with nothing further to record is a multivalued attribute; once each item has its own attributes, a discriminator, or relationships to other entities, it has become a weak entity. Invoice lines qualify because they carry quantity, price and a product link.
A weak entity is like seat 12B: the label only means something once you say which flight. The flight number is part of the seat's name.
saying these in an interview costs you the question
- Defining weak purely as 'must have a parent', which also describes many strong entities
- Assuming any entity with a mandatory foreign key is weak
- Saying a weak entity has no key at all, rather than no key of its own — it has a partial key
- Claiming a weak entity can be moved to a different owner while keeping its identity
- Treating weak entity and multivalued attribute as the same thing