Mapping strong entities to tables is the first and most fundamental step in turning an ER diagram into a working relational schema. A strong entity is one that exists independently and has its own key attribute, so it becomes a table in its own right: each simple attribute becomes a column, and the key attribute becomes the primary key. Once you can do this reliably, the harder cases — weak entities, relationships, and junction tables — build directly on the same habits.
The details matter. Composite attributes such as Address are normally flattened into their component columns (Street, City, Zip) rather than stored as one blob. Multi-valued attributes such as PhoneNumbers cannot live in a single column at all; they require a separate table keyed in part by the owning entity's primary key. Derived attributes such as Age are usually left out of the table entirely and computed when needed, since storing them invites inconsistency.
As you watch the videos below, keep a running checklist: Which boxes in the diagram are entities? Which attribute is underlined (the key)? Which attributes are composite, multi-valued, or derived, and what does each case force you to do to the table design? Try sketching the resulting CREATE TABLE statements on paper as the videos talk through examples — the mapping rules stick much faster when you write them out.
A compact introduction to ER diagrams from Lucid Software, covering the core building blocks: entities, attributes, and cardinality notation. It walks through constructing a diagram from scratch, which is the exact artifact you will later convert into tables. Expect clear visual notation and vocabulary for entity types and attribute types.
You cannot map a strong entity until you can read one off a diagram, and this video establishes that vocabulary clearly; Lucidchart is a widely used, reliable source for standard ERD notation.
This tutorial introduces multivalued fields — attributes that can hold more than one value for a single entity instance — and explains why they are a problem in a relational table. It then demonstrates how to resolve them, typically by splitting the values into a separate table linked back to the original entity. Expect a worked example rather than abstract theory.
It targets the multi-valued attribute subtopic directly, which is the one case where a strong entity's attributes do not simply become columns in its own table.
Very Academy approaches design from the opposite direction: given a flat list of attributes, work out which entities they belong to. The video shows how to group attributes, spot which ones identify an entity, and separate independent entities from dependent data. This is essentially the reasoning behind assigning columns and choosing a primary key.
It reinforces the link between attributes and the tables that own them, giving useful practice for identifying key attributes and avoiding columns placed in the wrong table.
Together these videos support MO1 most directly: the Lucid Software tutorial gives you the ERD notation needed to read entities, attributes, and keys from a diagram, while the Very Academy videos build the judgment required to assign attributes to the correct table and to choose a primary key. The multivalued-fields video previews the table-splitting logic that recurs in MO3's junction tables and MO4's weak entity keys, since both rely on a separate table whose key includes a reference back to the owning entity. The attribute-grouping video also lays groundwork for the normalization checks in MO5, where misplaced or repeating columns are the usual sources of error. Use them as preparation for the relationship-mapping rules in MO2, which assume you can already produce correct tables for strong entities.
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.