Before you can build a working relational database, you need a plan. An Entity-Relationship (ER) diagram is that plan: a visual model that shows the things a system stores information about (entities), the facts recorded about them (attributes), and how those things connect to one another (relationships). A relational schema, by contrast, is the concrete result: the set of tables, columns, primary keys, and foreign keys that a database management system actually implements.
This topic gives you the vocabulary and notation you will rely on for the rest of the module. You will meet entity types and entity instances, simple versus composite and multivalued attributes, key attributes, cardinality and participation constraints, and the distinction between strong entities and weak entities — entities that cannot be identified on their own and depend on an owner entity for part of their identity. Every conversion rule later in the module refers back to these ideas, so time spent getting the terminology straight now pays off quickly.
As you watch the videos below, pay attention to three things: how each symbol or shape maps to a specific database concept, how cardinality (one-to-one, one-to-many, many-to-many) is expressed in the diagram, and where primary and foreign keys begin to appear. Try sketching along with the examples rather than only watching — recognizing notation is much easier than producing it, and this module will ask you to produce it.
This is the first part of Lucid Software's two-part ERD tutorial and, based on its description, it builds an entity-relationship diagram from scratch. It introduces the foundational building blocks: entities, attributes, and cardinality notation, and shows how they are drawn and connected. Expect a worked example that moves from a plain-language description of a system to a diagram.
It matches the core subtopics almost exactly — what an ER diagram is, its basic symbols, and the key terminology of entities, attributes, and relationships — and it comes from Lucid Software, the makers of a widely used diagramming tool, so the notation shown is conventional and clean.
Part 2 of the same series moves into the concepts that bridge ER diagrams and relational tables: primary keys, foreign keys, and bridge (junction) tables used to handle many-to-many relationships. The longer running time allows for more detailed worked examples than Part 1. It is described as taking database design "to the next level" with more advanced ERD concepts.
It connects diagram notation to the actual structure of a relational schema, which is the pivot point of this entire module, and it previews the key-placement and junction-table ideas you will apply in the conversion steps that follow.
Database Star's video walks through the database design process as a whole, from understanding requirements to arriving at a workable table structure. It is likely to place ER diagramming within that larger workflow rather than treating it as an isolated drawing exercise. The channel is focused on practical SQL and database design instruction.
It directly supports the subtopic on the role of ER diagrams in database design, giving you the context for why you model first and implement second, and it reinforces the ER-to-schema path from a second instructor's perspective.
These three videos supply the conceptual groundwork the module outcomes assume. The Lucid Software Part 1 tutorial establishes entity, attribute, and cardinality notation, which is what you must read correctly before you can identify table structures, primary keys, and column assignments for strong and weak entities (MO1) or recognize the one-to-many relationships that drive foreign key placement (MO2). Part 2 introduces primary keys, foreign keys, and bridge tables, giving you a first model of the junction-table construction required by MO3 and of the key-inheritance reasoning behind weak entity composite keys in MO4. The Database Star overview frames ER diagramming as one stage in a larger design process, which supports the evaluative habit in MO5 of checking a finished schema back against the original diagram. Note that the detailed conversion rules and the Third Normal Form checks in MO5 are developed in the module readings and later materials; these videos prepare you for them rather than fully covering them.
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.
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.
One-to-many is the workhorse relationship of relational database design. In an ER diagram it says that one instance of an entity can be associated with many instances of another, but each of those many is associated with at most one of the first — one department has many employees, but each employee belongs to one department. When you convert that diagram into tables, the relationship itself does not usually become its own table; instead it is captured by a foreign key.
The rule you will practice in this topic is short but easy to misapply: the foreign key goes on the 'many' side, referencing the primary key of the 'one' side. Putting it the other way around forces you either to repeat rows or to store multiple values in a single column, both of which break the relational model. You will also look at what participation constraints mean for the resulting column: total (mandatory) participation on the many side generally means the foreign key column is NOT NULL, while partial (optional) participation allows nulls.
As you watch the videos below, keep a pencil handy and sketch the tables yourself before the presenter reveals them. Watch specifically for (1) how each speaker decides which side is 'many', (2) where the foreign key column lands and what it is named, (3) how the primary key of the referenced table is reused as the foreign key's data type and domain, and (4) any mention of nullability or referential actions. If a video shows a tool or a particular SQL dialect, focus on the design reasoning rather than the exact syntax.
Database Star walks through one-to-many relationships as a step-by-step design procedure, from recognizing the relationship to producing the finished tables, using worked examples. Based on its title and description, it presents a repeatable sequence of steps for creating the relationship rather than a purely theoretical overview, which should include identifying the parent and child tables and adding the foreign key column.
It maps almost directly onto this topic's core subtopics — translating the 'one' side and the 'many' side into tables and deciding where the foreign key goes — and its explicit seven-step framing gives you a decision process you can reuse on exam problems.
This Lucid Software tutorial is the second part of an ERD series and concentrates on primary keys, foreign keys, and bridge (junction) tables. Expect clear diagram-based explanations of how keys link entities together and how different cardinalities are represented in a schema.
It comes from the makers of a widely used diagramming tool and is strong on the vocabulary and notation side, reinforcing why the foreign key must reference a primary key; the bridge-table material also previews the many-to-many case so you can see clearly what makes one-to-many different.
Matt Macarty demonstrates adding foreign key constraints in MySQL Workbench, including drawing a one-to-many relationship on an EER diagram and letting the tool generate the constraint. This is the hands-on, implementation-side view: the diagram you design becomes actual tables with enforced referential integrity.
Seeing the one-to-many relationship tool place the foreign key on the child table makes the placement rule concrete, and watching the constraint be enforced shows the practical consequence of getting the placement right or wrong.
Together these videos support MO2 most directly: each one shows the foreign key being placed on the 'many' side and referencing the primary key of the 'one' side, giving you three complementary presentations — a step-by-step design procedure, a diagram-and-key conceptual explanation, and a tool-based implementation. The ERD tutorial's treatment of primary keys and entity-to-table conversion also reinforces MO1, and its bridge-table segment gives useful background for MO3 even though many-to-many is handled elsewhere in the module. Finally, the MySQL Workbench demonstration of enforced foreign key constraints connects to MO5 by showing what referential integrity actually looks like when a schema is checked against its design.
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.
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.
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.
Translating an ER diagram into tables is only half the job. Once you have a draft schema, you need to review it deliberately: does every entity and relationship in the diagram appear somewhere in the tables? Does every table have a primary key that truly identifies one row? Does every foreign key point at an existing primary key, with a sensible rule for what happens on update or delete? Validation is the step where modeling mistakes are cheapest to fix — before data is loaded and before application code depends on the structure.
This topic walks through a repeatable review process: cross-check tables against ER entities and relationships, verify primary key integrity (including composite keys for junction tables and weak entities), validate foreign key constraints and referential integrity, enforce consistent naming conventions, apply normalization checks (typically through 3NF, sometimes BCNF), confirm that domain, NOT NULL, UNIQUE, and CHECK constraints are all present, and then iterate until the schema is stable.
As you watch the videos below, keep a draft schema in front of you and treat each one as a checklist source. In the first video, note which mistakes are detectable by inspecting a schema alone. In the normalization videos, focus on how you test a table for a given normal form rather than on memorizing definitions — the goal is to be able to look at one of your own tables and say precisely which dependency violates which rule, and how to decompose it.
Database Star reviews several common database design mistakes and, for each one, explains the problem and a recommended fix. Based on the title and description, expect issues such as poor key choices, inconsistent or unclear naming, storing multiple values in one column, and missing or misused constraints — exactly the kinds of defects a schema review is meant to catch.
It frames schema review as a practical checklist rather than theory, which maps directly onto the cross-checking, naming convention, and integrity constraint subtopics; Database Star is a well-known, design-focused channel aimed at practitioners.
Gate Smashers surveys the normal forms in a single pass — 1NF, 2NF, 3NF, BCNF, 4NF and 5NF — using real-life style examples to show what each form requires and what violating it looks like. It is a fast, exam-oriented overview that lets you place your tables on the normalization ladder.
It gives you the full vocabulary and the test for each normal form in one compact video, which is what you need when applying normalization checks to a finished schema; the channel is widely used for DBMS coursework and keeps definitions crisp.
Decomplexify provides a detailed, example-driven explanation of Boyce-Codd Normal Form: what functional dependencies and candidate keys are, when a table in 3NF still violates BCNF, and how to decompose it. The pacing is slower and more conceptual than a survey video.
BCNF is where subtle key problems surface, so this is strong support for verifying primary key integrity and refining tables; Decomplexify is known for unusually clear, carefully worked explanations of normalization.
Together these videos support the evaluation step of the module. The design-mistakes video reinforces MO1 through MO4 indirectly by showing what incorrect table structures, keys, and column assignments look like in practice, and it directly supports naming and constraint checks. The two normalization videos target MO5: the Gate Smashers overview gives you the test for each normal form so you can confirm your schema reaches 3NF, while the Decomplexify BCNF video sharpens your understanding of functional dependencies and candidate keys, which is what makes primary key and foreign key verification rigorous rather than superficial. Use all three as review tools against a schema you have already derived from an ER diagram.
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.