A relational database organizes information into tables made up of rows (records) and columns (fields). Each table describes one kind of thing — customers, orders, patients, courses — and a defined schema states what columns exist, what type of data each holds, and what rules the data must follow. Tables are connected to one another through keys: a primary key uniquely identifies each row in a table, and a foreign key in one table points to the primary key of another, creating a relationship the database itself can enforce.
This structure matters for the rest of the course because it is the baseline against which every other database model is compared. When we later look at NoSQL and hierarchical systems, the questions we ask — how rigid is the schema, how are relationships represented, how easily can we query across data sets, how well is data integrity protected — are questions that come directly from the relational model. SQL, the language used to define and query relational data, is also the common point of reference for discussing query capability.
As you watch, keep a running vocabulary list: table, row, column, schema, primary key, foreign key, constraint, join, normalization. Pay attention to why designers split data across multiple tables instead of storing everything in one large table, and notice how the videos illustrate relationships (one-to-one, one-to-many, many-to-many) and what a foreign key constraint prevents from happening.
An overview video from IBM Technology that introduces what a relational database is and how data is arranged in tables of rows and columns. Based on its title and description, it should cover the basic structure and terminology of the relational model and connect it to SQL and to real relational database products. It serves as the conceptual starting point before the key-focused videos.
It is a short, vendor-produced explainer from a major database provider that directly addresses the "What Is a Relational Database?", "Tables and Schema", and "Querying with SQL" subtopics in plain language suitable for a first exposure.
Part two of Lucid Software's entity relationship diagram tutorial, focused on primary keys, foreign keys, and bridge (junction) tables. The description indicates it moves into more advanced ERD concepts, so expect worked diagram examples showing how entities are linked and how many-to-many relationships are resolved with an intermediate table. It is the longest of the three videos and the most design-oriented.
Lucidchart's tutorial series is a widely used reference for database design, and this installment maps closely onto the "Primary Keys" and "Foreign Keys and Relationships" subtopics while showing the visual modeling that underlies good table and schema design.
A brief, focused explainer from CockroachDB on foreign key constraints. Per its title and description, it defines what a foreign key is, contrasts it with a primary key, and explains why the constraint is important for keeping related data consistent. Its short length makes it a useful review or reinforcement after the ERD tutorial.
It isolates the single idea students most often confuse — primary key versus foreign key — and frames it as a constraint, which ties the key vocabulary directly to the data integrity criterion used later in the module.
Together these videos build the vocabulary and structural understanding the module requires. The IBM overview and the Lucidchart tutorial supply the terms in MO1 — records, fields, tables, schema, primary keys, foreign keys — in the context where they are actually used, while the CockroachDB video sharpens the primary-versus-foreign-key distinction and introduces constraints. Because the relational model is the reference point for MO2 and MO3, seeing clearly how tables, fixed schemas, keys, and SQL queries work gives you a concrete basis for contrasting relational systems with NoSQL and hierarchical models on schema flexibility, query capability, scalability, and data integrity. That comparison, in turn, is what you will draw on when selecting and justifying a database type for an application scenario (MO4) or identifying the model likely used in a given industry (MO5).
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.