A relational database organizes information into tables, where each row represents one instance of something (a customer, an order, a course section) and each column represents one attribute of that thing. What makes the model "relational" is that tables are not isolated: a primary key uniquely identifies each row in a table, and a foreign key stored in another table points back to that key, letting you connect related facts without copying them everywhere.
This topic matters because every later idea in this module depends on it. Normalization, anomalies, and the warning signs of bad table design only make sense once you can look at a schema and say what entity each table describes, what identifies a row, and how the tables link together. Poorly structured data, where one table tries to hold several unrelated entities or repeats the same fact in many rows, is what creates the update and deletion problems you will study next.
As you watch, keep three questions in mind for every example shown: What single thing does this table describe? What column or combination of columns uniquely identifies a row? And where does one table reference another? Sketch the tables and draw the links yourself rather than only watching; the habit of diagramming structure is what you will be graded on later in the module.
A short conceptual overview from IBM that introduces the relational model: data stored in tables of rows and columns, how keys identify records, and how tables relate to one another. Based on the title and description, it also situates relational databases against other ways of storing data and touches on SQL as the language used to query them.
It is a concise, vendor-neutral explanation from a major database producer, and it maps directly onto the first four subtopics here: what a relational database is, tables as rows and columns, keys, and relationships between tables.
Part one of Lucid Software's ERD tutorial covers the building blocks of database diagrams: entities, the attributes that describe them, and cardinality, which expresses how many rows on one side of a relationship can connect to rows on the other. It walks through building a diagram from scratch rather than only defining terms.
Thinking in entities and attributes is exactly the discipline that keeps a table focused on one logical thing, so this video gives you a visual vocabulary for discussing relationships before you meet normalization.
Part two moves into primary keys, foreign keys, and bridge (junction) tables used to resolve many-to-many relationships. Expect worked examples showing how a key in one table is referenced from another and how an extra table is introduced when two entities relate in both directions.
This is the most direct treatment of primary keys and inter-table relationships among the three videos, and bridge tables preview the restructuring moves you will apply when you break a poorly designed table apart.
Together these videos build the structural vocabulary required by MO1: the IBM overview names tables, rows, columns, and keys, while the two Lucid tutorials show primary and foreign keys at work in concrete diagrams. The ERD videos' emphasis on entities, attributes, and cardinality gives you the lens needed for MO3 and MO5, since spotting mixed entity types or deciding that a table should describe a single logical entity depends on being able to identify entities in the first place. The videos do not themselves cover anomalies or normal forms (MO2 and MO4); treat them as the foundation that the module's readings and exercises on anomalies and normalization will build upon.
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.