Most people meet SQL as a query language — a way to ask questions of data that already exists. In this module we shift the emphasis: before anything can be queried, something has to define what tables exist, what columns they hold, what data types those columns accept, and what rules keep the data consistent. That defining work is done in SQL too, through its Data Definition Language (DDL) commands such as CREATE DATABASE, CREATE TABLE, ALTER, and DROP. In this sense SQL is not only a retrieval tool but a data modeling language — a notation for writing down a model of a problem domain in a form a relational database management system can actually execute.
This matters because it is the point where design becomes reality. A conceptual model (entities and relationships) is refined into a logical model (relations, attributes, keys, normalization), and SQL DDL is what turns that logical model into a physical structure inside a specific RDBMS such as MySQL, PostgreSQL, Oracle, or SQL Server. Every choice you made during design — identifiers, relationships, optionality, business rules — must reappear as a primary key, a foreign key, a NOT NULL, a UNIQUE, or a CHECK constraint. If it does not appear in the DDL, the database does not enforce it.
As you watch the videos below, keep three questions in mind. First, which parts of a design diagram translate directly into SQL statements, and which require judgment calls? Second, how are relationships between entities actually represented in physical SQL, given that tables cannot literally "connect" except through key columns? Third, where does each DDL command fit in the overall design workflow — what has to be decided before you are ready to type CREATE TABLE at all?
This video walks through the step of taking a finished database design and producing the SQL code that implements it, which is exactly the translation from logical model to physical structure that this topic is about. Based on its title and the channel's focus, expect coverage of turning entities and attributes into CREATE TABLE statements, choosing data types, and expressing keys and relationships in code. It is positioned as part of a larger seven-step database design process, so it also shows where code generation sits in that sequence.
Database Star is a well-known, carefully produced source for practical database design instruction, and this video targets the bridging subtopic directly — it is the clearest match for the idea that SQL is how a logical design becomes a physical schema.
This video gives an overview of the database design process itself: understanding requirements, identifying entities and attributes, establishing relationships, and refining the structure before implementation. It provides the design context that SQL DDL is meant to implement, including the staged progression from a rough conceptual picture to a workable logical model. Think of it as the upstream half of the story that CREATE TABLE statements complete.
To explain how a logical model acts as a blueprint for a SQL schema, you first need a clear picture of what that model is and how it is produced; this widely viewed Database Star overview supplies that foundation for the design-workflow subtopic.
This video takes a hands-on approach to SQL's Data Definition Language commands, the subset of SQL used to create and modify database structures rather than retrieve rows. Expect demonstrations of commands such as CREATE, ALTER, DROP, and TRUNCATE applied to databases and tables, with attention to syntax and practical usage. The practical framing means you should see statements executed rather than only described.
It isolates DDL as a distinct category of SQL, which is precisely the distinction between SQL's defining role and its querying role, and it gives you concrete command syntax to practice schema creation with.
Together these videos move from design to implementation in the same order the module does. The design overview supports MO2 and MO5 by showing what a logical model contains and how design phases follow one another, while the DDL walkthrough supports MO1 and MO3 by separating structure-defining commands from query commands and demonstrating CREATE statements in practice. The code-generation video ties the two halves together, supporting MO2, MO3, MO4, and MO5 by showing how entities, attributes, keys, and relationships from a design become tables, data types, primary keys, foreign keys, and constraints in executable SQL targeted at a relational database system.
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.
Before you can write SQL that defines a database, you need a clear mental picture of what a relational database actually is. In the relational model, data is stored in tables (also called relations), each table holds rows (records) that represent individual things or events, and each row is made up of columns (attributes) that hold a single piece of typed data. Tables are not isolated: they are connected to one another through shared key values, which is what lets you store a customer once and reference that customer from thousands of orders without repeating the data.
This matters in COP4708 because every CREATE TABLE statement you write in this module is a direct translation of these ideas. A table definition names the relation, the column list fixes the attributes and their data types, and primary and foreign key constraints encode the relationships. Schemas sit above all of this as the organizing container that groups related tables inside a database.
As you watch the videos below, pay attention to three things: the vocabulary (table, row, column, key, schema) and how consistently it is used; how the speakers describe the connection between two tables and the role keys play in that connection; and the trade-offs that make the relational model a good fit for structured, rule-governed data. Those trade-offs will help you understand why SQL's data definition features look the way they do.
An introductory explainer on the relational database model, likely walking through how data is organized into tables made of rows and columns and how separate tables are linked through key values. Expect illustrated examples that build up a small set of related tables and show why splitting data across tables avoids duplication. It should also touch on how SQL is used to work with this structure.
This is the most direct match for the core subtopics — tables, rows, columns, and relationships between tables — and IBM Technology produces accurate, whiteboard-style explainers aimed squarely at newcomers.
A broader look at what a database is: what it does, how it differs from a loose collection of files, and the role of the database management system that sits between users and stored data. It is likely to introduce general concepts such as structured storage, querying, and database organization before narrowing to specific database types.
It supplies the context layer beneath the relational model, which helps when you reach schemas and database organization and need to understand what a database management system is actually managing.
A comparison of relational and non-relational (NoSQL) database approaches, contrasting the fixed table-and-schema structure of relational systems with more flexible document, key-value, or similar models. The video should discuss when each approach fits a given workload and what you gain or give up with each.
Seeing the alternative sharpens your understanding of what is distinctive about tables, defined columns, and schemas — exactly the structural commitments that SQL data definition statements make explicit.
These videos build the conceptual vocabulary that the rest of the module depends on. Understanding tables, rows, columns, and key-based relationships is what makes a logical data model readable as a blueprint (MO2) and what makes CREATE DATABASE and CREATE TABLE statements meaningful rather than memorized syntax (MO3). The treatment of keys and links between tables prepares you to apply primary key, foreign key, and column constraints with an understanding of the integrity they protect (MO4). Seeing how SQL is used both to structure and to retrieve data, and how relational systems differ from non-relational ones, frames the distinction between SQL's data definition and data querying roles (MO1) and gives you the structural grounding needed to connect each design phase to its SQL implementation activity (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.
Before you write a single CREATE TABLE statement, someone has to decide what things the database must keep track of, what facts describe each of those things, and how those things relate to one another. That work is logical data modeling. A logical model names the entities in a business domain, lists their attributes, identifies which attribute (or combination) uniquely identifies each instance, and records the relationships and rules that connect entities — all without committing to a particular database product or SQL dialect.
In this module, the logical model is the bridge between understanding a business problem and expressing it in SQL. Entities become tables, attributes become columns, unique identifiers become primary keys, relationships become foreign keys, and business rules become constraints. Normalization — organizing attributes so each fact is stored once, in the place it belongs — is done at the logical level so that the schema you later define is free of avoidable redundancy and update problems.
As you watch the videos below, keep a translation column in your notes. For every modeling term you hear (entity, attribute, cardinality, identifier, many-to-many relationship, bridge table), write the SQL element it will become. Pay particular attention to how one-to-many and many-to-many relationships are represented, since those decisions drive the foreign key and junction-table work you will do in the hands-on portion of this module.
This tutorial introduces entity relationship diagrams from the ground up, walking through what an entity is, how attributes describe it, and how cardinality notation expresses the number of instances that can participate on each side of a relationship. Based on the title and description, it builds a simple ERD step by step rather than assuming prior modeling experience. Expect coverage of the core notation you will see throughout this module.
It maps directly onto the Entities and Attributes and Relationships Between Entities subtopics, and Lucid Software produces this material to support its widely used diagramming tool, so the notation shown is standard and clearly presented.
Part 2 moves past the basics into primary keys, foreign keys, and bridge (junction) tables. The description indicates it addresses how identifiers are chosen and how relationships are actually carried in a design, including the resolution of many-to-many relationships into an intermediate table. At roughly fifteen minutes, it is the most detailed of the three videos.
Primary keys, foreign keys, and bridge tables are exactly the modeling constructs that become key and referential integrity constraints in SQL, making this the clearest link between the logical model and the blueprint-for-SQL subtopic.
This short video compares conceptual and logical data models and explains how they differ in purpose and level of detail. Expect it to clarify where a high-level view of business concepts ends and where attribute-level, identifier-level specification begins. It is aimed at people new to data modeling who tend to blur the two.
It directly addresses the Purpose of Logical Data Models subtopic by situating the logical model within the broader design workflow, which helps you see why the logical phase exists as a distinct step before physical implementation.
Together these videos establish the modeling vocabulary that the rest of the module converts into SQL. The conceptual-versus-logical comparison supports MO5 by showing where the logical phase sits in the design workflow, while the two ERD tutorials supply the entity, attribute, and relationship concepts behind MO2 — understanding the logical model as a blueprint. The treatment of primary keys, foreign keys, and bridge tables prepares you for MO3 and MO4, since those are the structures you will declare with CREATE TABLE and enforce with key and referential constraints. None of the videos teach SQL syntax itself, which reinforces the MO1 distinction between defining structure and querying data: the modeling work shown here is entirely about definition, and the SQL readings and exercises in this module supply the statements that implement it.
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 database schema is the formal blueprint of a database: it names the tables, the columns in each table, the data type each column holds, and the rules that govern what values are allowed and how tables relate to one another. In this topic you move from the logical data model you produced earlier in the course to actual SQL statements — CREATE DATABASE to establish the container, and CREATE TABLE to define each entity as a physical table. This is SQL's Data Definition Language (DDL) side, distinct from the SELECT-oriented querying work you have done before.
Much of the care in schema creation goes into the details: choosing a data type that matches the real nature of the data (integers, decimals, fixed- and variable-length text, dates), declaring a PRIMARY KEY so every row is uniquely identifiable, declaring FOREIGN KEY references so related tables stay consistent, and adding column-level constraints such as NOT NULL, UNIQUE, DEFAULT, and CHECK to encode business rules directly in the schema. Constraints matter because they push rule enforcement into the database itself rather than relying on every application that touches the data.
As you watch the videos below, keep a few questions in mind. Which clause establishes identity (primary key) versus which clause establishes a relationship (foreign key)? What happens when you try to insert or delete a row that would break a reference? And how does the order in which you create tables matter when one table refers to another? Note that SQL syntax varies slightly across database products, so compare what you see on screen with the syntax used in your course environment.
This tutorial walks through the core building blocks of a table definition: SQL data types, primary keys, foreign keys, and constraints, as the title indicates. Expect an overview of common type categories and how key and constraint clauses are written inside a CREATE TABLE statement. It is part of a larger SQL full-course playlist, so it is pitched at learners building up DDL skills step by step.
It is the closest single match to the breadth of this topic, touching data type selection, primary keys, foreign keys, and column-level constraints in one short session, which helps you see how these pieces fit together in a single table definition.
A short, practical demonstration from CockroachDB on writing CREATE TABLE statements that include foreign key clauses. Based on the title and description, it focuses on the mechanics of declaring a reference from a child table to a parent table and on maintaining referential integrity as tables are created.
It gives you hands-on syntax for the CREATE TABLE and foreign key subtopics, and it comes from a database vendor's own educational channel, so the SQL shown reflects real product usage.
This video explains what a foreign key constraint is, why referential integrity matters, and how foreign keys differ from primary keys. It is conceptual rather than syntax-heavy, aimed at clarifying the role each kind of key plays in linking tables.
It supplies the conceptual grounding behind the syntax in the other two videos, directly supporting the subtopics on defining primary keys and establishing foreign keys and relationships.
Together these videos reinforce the DDL half of SQL that MO1 asks you to distinguish from querying, and they supply the concrete syntax you need for MO3 when turning a logical model into CREATE TABLE statements. The CockroachDB pair addresses MO4 most directly by explaining and then demonstrating primary key and foreign key constraints and the referential integrity they enforce, while the Rishabh Mishra tutorial adds data type selection and other column-level constraints. Use them alongside the module readings for MO2 and MO5, which treat the logical model as a blueprint and connect each design phase to its SQL implementation activity; the videos illustrate the implementation step rather than the full design workflow.
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.
Before you write a single CREATE TABLE statement, a database normally passes through three design phases: conceptual design (what things the business cares about and how they relate), logical design (entities, attributes, keys, and relationships expressed in the relational model), and physical design (how that model is actually built in a particular DBMS). SQL lives mostly in that third phase. It is the implementation layer — the language in which the decisions you already made on paper or in a diagram become real tables, columns, data types, and constraints.
This matters in COP4708 because the quality of your SQL schema is largely decided before you start typing. A clean logical model maps almost mechanically to SQL: each entity becomes a table, each attribute becomes a column with a data type, each identifier becomes a primary key, and each relationship becomes a foreign key. A muddled model produces a schema that fights you later. Design is also iterative — writing the SQL often exposes an ambiguity or a missing rule, sending you back to revise the model before moving forward again.
The three videos below come from Database Star, a channel focused on practical database design and SQL. As you watch, try to separate the design reasoning from the SQL syntax: notice where the presenter is making a modeling decision (what is an entity? what is the key? is this one-to-many or many-to-many?) and ask yourself what SQL statement or constraint would express that decision. Also pay attention to the moments where a design is revised mid-process — that is the iterative refinement loop in action.
A walkthrough of the overall database design process, from gathering requirements and identifying entities and attributes through to building a model that can be implemented. Based on its title and channel, it is likely to cover the progression from an initial idea to tables, keys, and relationships, including normalization-style thinking about where data belongs.
It gives you the end-to-end framing this topic is built on, so you can see where conceptual, logical, and physical work each sit and where SQL enters the picture as the implementation step.
A worked example that designs a database for a library management system, starting from the real-world requirements of books, members, and loans. Expect the presenter to identify entities, decide on attributes and keys, and resolve relationships (including the many-to-many borrowing relationship) into a concrete relational design.
Seeing a single scenario carried from requirements to a finished model makes the mapping from logical structures to SQL tables, primary keys, and foreign keys concrete rather than abstract.
A list of common database design mistakes with explanations of why each causes problems and what to do instead. Likely topics based on the title include poor naming, inappropriate data types, missing or misused keys, and structures that create redundancy or make querying difficult.
Mistakes are the clearest argument for iterative refinement: it shows you the design flaws that only surface once a schema is implemented and used, and how to correct them before they become expensive.
Together these videos support the module outcomes by supplying the design context that SQL implements. The process overview maps directly to MO5 by laying out the phases of design work you will later match to SQL activities, and it reinforces MO2 by showing the logical model as the blueprint a schema is built from. The library management example gives a complete entity-to-table translation, which is the thinking behind MO3's CREATE DATABASE and CREATE TABLE work and behind MO4's use of primary keys, foreign keys, and constraints to carry business rules into the schema. The mistakes video sharpens MO1 and MO4 by showing how definition-time choices — data types, keys, structure — differ from and constrain what you can later query, and why getting the definition right the first time matters.
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.