A weak entity is one that cannot be identified on its own. Its existence and its identity both depend on another entity — the owner, or identifying, entity. Classic examples include a Dependent that only makes sense in relation to an Employee, or an Apartment Unit that only makes sense within a particular Building. Because a weak entity has no attribute that is unique across the whole table, it carries only a partial key (sometimes called a discriminator): a value that distinguishes it among the other weak entities belonging to the same owner, but not globally.
When you map a weak entity to a relational table, you follow the usual steps — create a table, add the simple attributes as columns — and then do two extra things. First, bring in the primary key of the owner entity as a foreign key. Second, build the table's primary key as a composite of that foreign key plus the partial key. The identifying relationship itself does not become a separate table; it is absorbed into this foreign key. Finally, because the weak entity has no independent existence, the foreign key is normally declared NOT NULL and the deletion behavior is typically ON DELETE CASCADE, so removing an owner row removes its dependents rather than leaving orphans.
The videos below approach this from two directions. The Lucid Software ERD tutorials give you the diagram-side vocabulary — entities, attributes, keys, and how primary and foreign keys connect tables — while the kudvenkat video shows the actual SQL for declaring a primary key over two columns, which is exactly the mechanic you need for the weak entity's composite key. As you watch, keep translating: when you see a key being described in a diagram, ask yourself what the CREATE TABLE statement would look like, and when you see SQL, ask which part of the ER diagram produced it.
This is the second part of Lucid Software's ERD tutorial series, focused on keys and the structural glue between tables. Based on its title and description, it covers primary keys, foreign keys, and bridge (junction) tables as the mechanism for linking entities in a relational design. It is pitched as the step beyond the basics, where diagram elements start turning into concrete table structures.
The identifying relationship of a weak entity is mapped entirely through a foreign key that is also part of the primary key, so a solid grounding in how primary and foreign keys interact is the prerequisite for this topic. The bridge-table discussion also previews the idea of a table whose key is made of inherited keys, which is structurally very close to a weak entity's table.
Part 1 of the same Lucid Software series builds an entity relationship diagram from the ground up, covering entities, attributes, and cardinality. It is a short, visual orientation to ERD notation and how relationships between entities are expressed on a diagram.
Before you can recognize a weak entity and its partial key on a diagram, you need fluency in the basic ERD vocabulary this video establishes. It is a useful refresher if the distinction between an entity, an attribute, and a relationship is still not automatic for you.
Kudvenkat demonstrates how to define a primary key across two columns in SQL Server, which is the composite (multi-column) primary key. The video shows the syntax for declaring such a constraint and works through an example of when a single column is not sufficient to identify a row.
This is the direct implementation of the central skill in this topic: the weak entity's primary key is a composite of the owner's foreign key plus the partial key. Kudvenkat's step-by-step SQL style makes the constraint syntax concrete rather than theoretical.
Together these videos move you from diagram to schema. The two Lucid Software tutorials support MO1 and MO2 by reinforcing how entities, attributes, and cardinalities are read from an ER diagram and how primary and foreign keys are assigned when those diagrams become tables, with the bridge-table material also feeding MO3. The kudvenkat video directly serves MO4 by showing the SQL for a multi-column primary key, which is precisely the construction used when a partial key is combined with an inherited foreign key. All three contribute to MO5, since checking a finished schema means verifying that every primary key is genuinely unique and every foreign key resolves to a real parent row — exactly the constraints these videos demonstrate.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.