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.