In an ER diagram, a many-to-many relationship says that each instance of entity A can be associated with many instances of entity B, and vice versa — a student enrolls in many courses, and each course enrolls many students. The relational model has no way to express this directly: a single foreign key column can only hold one value, so you cannot place a foreign key on either side without either losing data or repeating rows. The standard solution is a junction table (also called a bridge, associative, or link table) that sits between the two entity tables.
The junction table holds one foreign key column referencing each parent table's primary key. Together those foreign keys usually form a composite primary key, which guarantees that the same pairing is never recorded twice. If the relationship itself carries attributes — an enrollment grade, a quantity ordered, a start date — those columns belong in the junction table, because they describe the pairing rather than either entity alone. Mapping the ER diagram then becomes mechanical: two entity tables, one junction table, two foreign keys, one composite key, plus any relationship attributes.
As you watch the videos below, keep three questions in front of you. First, how does the presenter decide a relationship is truly many-to-many? Second, which columns become the primary key of the intermediate table, and why does a composite key solve the duplication problem? Third, where do relationship attributes end up? Note the differences in vocabulary between sources — "bridge table," "junction table," "link table," and "composite key" versus "multi-column primary key" — since you will meet all of these terms in practice.
This is the second part of Lucid Software's ER diagram tutorial series, focused on primary keys, foreign keys, and bridge (junction) tables. Based on its title and description, it builds from basic ERD notation into the more advanced structures needed to turn a diagram into real tables, including how foreign keys connect related tables and why an intermediate table is required for many-to-many relationships. Expect worked diagram examples drawn in a modeling tool rather than SQL code.
It is the closest single match to this topic, covering the key-placement rules and the bridge table idea in one place, and it comes from Lucid Software, the makers of a widely used diagramming tool with a strong track record of clear, accurate database-modeling tutorials.
Kudvenkat demonstrates how to define a primary key on two columns in SQL Server — that is, a composite primary key. The video is likely to show the CREATE TABLE and ALTER TABLE syntax for declaring a multi-column key and to illustrate how the combination of values, rather than either column alone, must be unique.
The composite primary key is the mechanism that makes a junction table work, and this short, implementation-focused video shows you exactly how to declare one in SQL, complementing the conceptual diagram-level treatment in the other videos.
Gareth Pronovost walks through linking two tables correctly in Airtable, using a "can both sides have many?" test to decide whether a third junction table is needed. The stated takeaways indicate it addresses many-to-many situations directly and shows what goes wrong when you try to link two tables without an intermediate one.
It gives you a practical decision test for recognizing a many-to-many relationship and a visible, hands-on demonstration of why a third table is required — useful reinforcement even though the platform is a no-code database rather than SQL.
Together these videos target MO3 most directly: the Lucid Software tutorial explains why many-to-many relationships need a bridge table and how foreign keys are placed, the Airtable video provides a practical test for identifying such relationships and shows the junction table being built, and the kudvenkat video supplies the SQL mechanics for declaring the composite primary key that locks the pairing. The key-placement and referential-integrity material in the Lucid video also reinforces MO1, MO2, and MO5, while the composite-key technique demonstrated by kudvenkat transfers directly to MO4, where a weak entity's partial key is combined with its owner's foreign key.
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.