SQL is often described as a single language, but in practice it is a family of related sublanguages, each with a different job. Data Definition Language (DDL) is the part of SQL used to create and shape the structures that hold your data: tables, columns, data types, constraints, indexes, views, and schemas. Commands such as CREATE, ALTER, DROP, and TRUNCATE belong to DDL, and together they define what a database can store and what rules the stored data must obey.
This distinction matters in COP4708 because almost everything else you do depends on it. Queries written with SELECT (DQL) and data changes made with INSERT, UPDATE, and DELETE (DML) can only work within the structure that DDL has already established. Permissions (DCL) and transaction control (TCL) round out the picture. Getting comfortable naming these categories now will make the rest of the module, where you write real CREATE TABLE and ALTER TABLE statements, much easier to follow.
As you watch the videos below, keep a running list of which commands fall into which sublanguage, and notice how often DDL decisions, such as choosing a data type or adding a constraint, are decisions about data integrity rather than just syntax. Also pay attention to the commands that permanently change or remove structures, since those are the ones with the most serious consequences in a live database.
This video surveys all five categories of SQL commands: DDL, DQL, DML, DCL, and TCL. Based on its title and description, it presents each category's purpose along with syntax and short examples of the commands that belong to it. Expect a quick, structured tour rather than deep practice on any one command.
It directly addresses the "DDL vs. other SQL sublanguages" subtopic by placing DDL side by side with the other four categories, which is exactly the classification skill this topic asks you to build.
A longer, practice-oriented walkthrough of the core DDL commands from KnowHow Academy. The description indicates it explains the essential Data Definition Language commands and how to use them, so expect demonstrations of statements such as CREATE, ALTER, DROP, and TRUNCATE applied to database objects. The extra length allows for more worked examples than a short overview can offer.
It focuses specifically on DDL rather than SQL in general, giving you a concrete look at the database objects DDL defines and previewing the hands-on CREATE and ALTER work later in this module.
A fast-paced beginner crash course covering SQL fundamentals in about ten minutes. Its description promises the essential basics, which typically includes how tables and columns are structured, the common command families, and simple query syntax. It serves as general context rather than a DDL-specific lesson.
With over half a million views it is a well-tested orientation video, useful for situating DDL within SQL as a whole and for reviewing foundational vocabulary before the module's detailed DDL work.
Together these videos build the conceptual foundation the module outcomes rest on. The PyBrain overview supports MO1 most directly by sorting SQL commands into DDL, DQL, DML, DCL, and TCL according to purpose, while the Learn with Whiteboard crash course reinforces the surrounding SQL vocabulary. The KnowHow Academy DDL walkthrough previews the practical skills assessed in MO2 through MO5, showing CREATE, ALTER, and object-removal commands in action so that when you later write CREATE TABLE statements, apply PRIMARY KEY and FOREIGN KEY constraints, alter existing tables, and choose among DROP, TRUNCATE, and DELETE, the syntax and its consequences are already familiar.
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.
The CREATE statement is the starting point of SQL's Data Definition Language (DDL). While queries with SELECT read data that already exists, DDL commands build and shape the containers that hold data: databases, schemas, and tables. In this topic you will work through that hierarchy from the outside in — creating a database, organizing objects into a schema, and then defining individual tables with named columns and data types.
This matters in COP4708 because everything you have designed on paper so far — entities, attributes, relationships — eventually has to be expressed as runnable SQL. A well-written CREATE TABLE statement captures your design decisions: what each column is called, what kind of values it may hold, how wide or precise those values are, and which schema the table belongs to. Poor choices here (a text column for a date, an undersized character field, inconsistent naming) are costly to fix once data is loaded.
As you watch, pay attention to three things: the exact syntax and punctuation of a CREATE statement, how the presenter chooses a data type for each column and justifies it, and how fully qualified names (schema.table) are used. Also notice that syntax varies a little between database products such as MySQL, Oracle, SQL Server, and PostgreSQL, so confirm the dialect your course environment uses before you run anything.
A short, focused walkthrough of the CREATE TABLE statement using a worked example. Based on the title and channel, it should show the basic syntax — table name, the list of column definitions, and the data type assigned to each column — and then run the statement to produce a working table.
This is the core subtopic of the lesson delivered concisely, and Database Star is a well-established SQL instruction channel known for accurate, dialect-aware explanations. At under six minutes it gives you a template you can imitate immediately when writing your own column definitions.
This video covers CREATE DATABASE, the command that establishes the top-level container before any tables exist. Given the title and description, expect to see the basic statement, example variations, and likely supporting details such as listing or selecting a database after creating it, demonstrated in MySQL.
It directly addresses the "Creating a New Database" subtopic and sets up the database-schema-table hierarchy, so you understand what a table is being created inside of rather than treating CREATE TABLE as an isolated command.
A longer, project-style video that moves from a completed database design to the SQL code that implements it. Expect a demonstration of translating entities and attributes into CREATE statements, including decisions about table names, columns, and data types, as part of a broader design-to-implementation workflow.
It connects CREATE statements back to data modeling, which is exactly the skill this course builds, and it reinforces best practices for writing CREATE statements by showing them applied to a full design rather than a single toy table.
Together these videos build the practical foundation for the module's outcomes. The CREATE TABLE and design-to-SQL videos directly support MO2 by modeling how to write statements with appropriate column names and data types, and they illustrate DDL's distinct purpose — defining structure rather than retrieving or changing rows — which supports the classification work in MO1. The CREATE DATABASE video establishes the database and schema context in which tables and their constraints live, preparing you for the integrity rules in MO3. Because MO3, MO4, and MO5 extend beyond CREATE into constraints, ALTER TABLE, and DROP/TRUNCATE/DELETE, treat these videos as the base layer and pair them with the module readings and later topics that cover those commands.
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.
Every column in a relational table has a data type, and that type is a promise about what the column may hold. Numeric types (INT, SMALLINT, BIGINT, DECIMAL/NUMERIC, FLOAT), character and string types (CHAR, VARCHAR, TEXT), date and time types (DATE, TIME, TIMESTAMP), and boolean or binary types (BOOLEAN, BLOB/BINARY) each store values differently and allow different operations. Choosing DECIMAL instead of FLOAT for currency, or DATE instead of VARCHAR for a birthdate, is not a stylistic preference — it determines whether the database can validate, sort, compare, and compute on your data correctly.
In this module you write CREATE TABLE statements, and the column definition is where the data type lives: a column name, a type (often with a length or precision, such as VARCHAR(50) or DECIMAL(10,2)), and any column-level constraints such as NOT NULL or DEFAULT. Data types are the first line of defense for data integrity; constraints build on top of them. Keep in mind that exact type names vary by DBMS (MySQL, SQL Server, Oracle, PostgreSQL, SQLite), so expect small differences between videos and your course environment.
As you watch, note three things: which type each presenter chooses for a given kind of value and why, how length or precision is specified, and how the data type sits alongside constraints inside the parentheses of a CREATE TABLE statement. Jot down any type names that differ from the ones your course uses so you can map them later.
A focused tutorial that walks through SQL data types and then connects them to primary keys, foreign keys, and other constraints used when defining a table. Based on its title and description, it covers the main type families you will use in column definitions and shows how constraints are attached to those columns. It is part of a larger SQL full-course playlist, so the examples build on earlier lessons.
This is the most directly on-topic video in the set, pairing data types with the constraint syntax that appears in the same CREATE TABLE statement, which matches the subtopics on choosing types for data integrity and defining columns.
A fast, beginner-oriented overview of core SQL from a business intelligence instructor, using a downloadable SQLite database so you can follow along. It introduces how data is organized into tables with typed columns and demonstrates basic statements against that data. The resource pack lets you practice rather than just watch.
Its hands-on database setup gives you a concrete place to inspect real column definitions and experiment with how values of different types behave, reinforcing the storage-and-integrity rationale behind type choices.
A short introduction to SQL and relational databases from W3Schools, framing what SQL is used for and how tables, rows, and columns relate. It serves as the opening piece of a beginner tutorial series and links back to a written reference page.
W3Schools is a widely used, accurate reference, and this brief orientation supplies the vocabulary of tables and columns you need before studying types in detail; its companion pages also list data types by DBMS.
Together these videos support MO2 most directly: they show column names paired with data types inside table definitions and give you a practice database for building your own. The data-types-and-constraints tutorial also reinforces MO3 by demonstrating PRIMARY KEY, FOREIGN KEY, and NOT NULL style rules attached to typed columns, and the introductory W3Schools video provides the general SQL framing that helps you place DDL among the other SQL sublanguages for MO1. Material on ALTER TABLE (MO4) and the DROP, TRUNCATE, DELETE comparison (MO5) is covered in other resources in this module, so treat these videos as preparation for the column-definition skills those commands later modify.
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.
Constraints are the rules you attach to a table so the database itself refuses to store bad data. A PRIMARY KEY guarantees that every row can be uniquely identified (and that the key column is never empty), a FOREIGN KEY ties a column in one table to the key of another so relationships stay valid, NOT NULL forces a value to be supplied, UNIQUE blocks duplicate values in a column that is not the primary key, and DEFAULT supplies a value automatically when the INSERT statement leaves the column out. Together these are the backbone of relational integrity.
In this module you are learning Data Definition Language, and constraints are written directly into the CREATE TABLE statement alongside column names and data types. That makes them a design decision, not an afterthought: if you declare them correctly up front, the database enforces your business rules on every insert and update from then on. You will also see that constraints can be added, renamed, or dropped later with ALTER TABLE when requirements change.
As you watch the videos below, pay attention to the exact syntax and placement of each constraint (column-level versus table-level), to how a foreign key names the parent table and column it references, and to what the database actually does when a statement violates a rule. Note also that the examples come from CockroachDB, a PostgreSQL-compatible SQL database, so the ideas transfer directly but minor syntax details may vary from the DBMS you use in class.
A hands-on follow-up that walks through creating tables that include foreign key definitions in SQL. Expect to see CREATE TABLE statements in which a parent table is defined first and a child table then declares a column that REFERENCES it, illustrating referential integrity in practice.
It maps directly to the "Applying Constraints During Table Creation" subtopic by showing the constraint written inside a CREATE TABLE statement rather than discussed in the abstract.
A short conceptual explainer on what a foreign key constraint is, why it matters, and how it differs from a primary key. Based on its title and description, it covers the role of each key type in identifying rows and in linking a child table to a parent table, and explains the referential integrity the constraint protects.
Start here: it builds the vocabulary and mental model for the PRIMARY KEY and FOREIGN KEY subtopics before you write any syntax, and its large view count reflects a clear, widely used introduction from a SQL database vendor.
This video demonstrates the ADD CONSTRAINT clause, along with dropping and renaming constraints, using worked SQL examples. It shows how a constraint can be attached to a table that already exists instead of only at creation time.
It rounds out the topic by showing that constraints are maintainable objects, connecting constraint rules to the ALTER TABLE work covered elsewhere in this module.
These videos concentrate on the constraint-focused outcomes of the module. The conceptual foreign key video and the table-creation walkthrough support MO2 and MO3 by showing how PRIMARY KEY and FOREIGN KEY declarations are embedded in a CREATE TABLE statement to enforce integrity, and they model the same column-level syntax pattern you will reuse for NOT NULL, UNIQUE, and DEFAULT. The ADD CONSTRAINT video supports MO4 by demonstrating how constraints are added, renamed, or removed on an existing table without rebuilding it. Because every example is a DDL statement that defines or alters structure rather than querying or changing rows, the set also reinforces MO1; you should supplement them with your course readings for NOT NULL, UNIQUE, and DEFAULT practice and for the DROP, TRUNCATE, and DELETE comparison in 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.
Database designs rarely stay the same once an application goes live. Requirements change, new data needs to be captured, and mistakes in the original schema have to be corrected. The ALTER TABLE command is the SQL Data Definition Language tool that lets you change the structure of a table that already exists — adding a column, changing a column's data type or size, removing a column, and adding or dropping constraints such as PRIMARY KEY, FOREIGN KEY, NOT NULL, UNIQUE, and CHECK.
What makes ALTER TABLE important in this course is that it changes structure without discarding the rows already stored. That is the key difference between altering a table and dropping and recreating it. It also means you have to think about the existing data: adding a NOT NULL column to a populated table, shrinking a column's size, or adding a foreign key when some rows hold values that do not exist in the parent table can all fail or require extra steps.
As you watch the videos below, pay attention to the exact clause keywords used (ADD, ALTER COLUMN or MODIFY, DROP COLUMN, ADD CONSTRAINT, DROP CONSTRAINT), to how constraints are given names so they can be dropped later, and to any differences in syntax between SQL Server and MySQL. Try reproducing each statement on a small test table of your own so you can see what happens to the rows that were already there.
A short, focused demonstration of ALTER TABLE in SQL Server Management Studio, including how constraints are handled when modifying an existing table. Based on the title and description, expect to see the basic ADD, modify, and drop operations carried out live against a table and the results checked afterward.
It is a compact, on-topic walkthrough from an instructor-oriented channel that pairs the ALTER TABLE syntax with constraint work, covering the introduction, column changes, and constraint subtopics in one sitting.
Part of a structured SQL tutorial series, this video places ALTER TABLE alongside INSERT, UPDATE, and DELETE with worked examples and timestamps for each command. Expect to see how structural changes with ALTER differ from row-level changes made by the data manipulation statements.
Seeing ALTER next to INSERT, UPDATE, and DELETE reinforces the distinction between changing a table's design and changing its contents, which is exactly the point of evolving a table without losing data; the series is widely viewed and uses step-by-step examples. Note that the narration is in Hindi with English SQL terms and on-screen code.
A targeted MySQL tutorial showing how to add a FOREIGN KEY constraint to a column in a table that already exists, rather than declaring it at creation time. Expect the ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY ... REFERENCES pattern demonstrated against sample tables.
It drills into the subtopic students most often struggle with — attaching constraints after the fact — and does so in MySQL, giving you a second dialect to compare against the SQL Server examples.
Together these videos center on MO4: each one demonstrates ALTER TABLE operations that add, change, or remove columns and constraints on tables that already contain data. The constraint-focused material also reinforces MO3 by showing PRIMARY KEY, FOREIGN KEY, and related integrity rules being applied and named so they can later be dropped, and it builds directly on the CREATE TABLE work of MO2 by showing how an initial design is corrected or extended. The tutorial that contrasts ALTER with INSERT, UPDATE, and DELETE supports MO1 and MO5 by helping you classify which statements change structure versus which change rows, preparing you to choose correctly among DROP, TRUNCATE, and DELETE.
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.
So far in this module you have been building database objects: creating tables, defining data types, applying constraints, and altering structures that already exist. This topic looks at the other side of data definition — removing things. DROP is the DDL command that permanently deletes a database object such as a table, view, schema, or even an entire database, taking its structure and its data with it. TRUNCATE is a related command that keeps the table definition intact but removes every row in one fast operation.
The reason these two commands get their own topic is that they are easy to confuse with each other and with DELETE, a DML command that removes rows based on a WHERE condition. The three differ in what they affect (object vs. rows), how they are logged, whether they can be rolled back, how they interact with identity/auto-increment counters and foreign key references, and how quickly they run on large tables. Choosing the wrong one in a production database is one of the classic ways to lose data permanently.
As you watch the videos below, keep a comparison table in front of you and fill in columns for DROP, TRUNCATE, and DELETE: Does the table still exist afterward? Can you filter which rows go? Is it DDL or DML? Can it be undone? What happens to constraints and identity seeds? Also pay attention to the syntax each presenter types — note how short and unforgiving these statements are, which is exactly why best practices like backups, testing on a copy, and double-checking the database context matter.
A detailed walkthrough comparing the SQL DELETE and TRUNCATE commands, including their syntax and the practical differences between them. At roughly seventeen minutes it has room to demonstrate the commands against sample tables and discuss points such as filtering rows with WHERE, speed, and how each command is handled by the database engine.
This is the longest and most thorough of the three videos, and it directly addresses the TRUNCATE vs. DELETE distinction that students most often get wrong on exams and in practice.
A short, interview-style answer to the question of how TRUNCATE TABLE differs from DROP TABLE. In about three minutes it summarizes the core distinction — TRUNCATE empties a table while leaving its structure in place, DROP removes the object entirely — in the concise form an interviewer or exam question would expect.
It is a quick, focused summary of the key differences subtopic, useful as a review or memory aid after you have seen the commands demonstrated at length.
A SQL Server tutorial that walks through the object hierarchy — database, schema, table — and shows how to create and then drop each level of object. Expect to see DROP used in context rather than in isolation, so you can observe what disappears when you drop a table versus a schema or a whole database.
It supplies the DROP syntax and usage in a realistic sequence of statements, and seeing drops alongside creates reinforces how severe and irreversible the command is.
Together these videos target MO5 most directly: the DELETE vs. TRUNCATE comparison, the TRUNCATE vs. DROP summary, and the demonstration of DROP across databases, schemas, and tables give you three perspectives on how each command affects objects and data, which is exactly what you need to select the right command for a given scenario. The SQL Server walkthrough also reinforces MO1 and MO2 by placing DROP within the wider set of DDL statements and showing creation and removal as paired operations on the same objects, while the DELETE discussion helps you see where DML ends and DDL begins. Use the videos as demonstrations, then confirm the behavior for the specific DBMS used in this course, since details such as rollback support and identity reseeding vary by platform.
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 a named logical container that groups related tables, views, indexes, and other objects inside a database. Instead of dumping every table into one undifferentiated space, you can create a schema such as sales or hr and place the objects that belong to that area of the business inside it. Because object names only need to be unique within a schema, two different schemas can each hold a table called ORDERS without conflict.
In this module you will practice the statements that make this work: CREATE SCHEMA to define the container, schema-qualified names such as sales.orders to refer to an object unambiguously, CREATE TABLE statements written inside a chosen schema, and DROP SCHEMA to remove one (with care, since dropping a schema can take its contents with it). Keep in mind that different database systems treat schemas slightly differently — in Oracle a schema is tied to a user account, while in PostgreSQL and SQL Server a schema is a separate namespace you create explicitly — so always check which product you are writing for.
As you watch the videos below, pay attention to two things. First, notice how objects are named and referenced: when does the writer use a bare table name and when does a prefix appear? Second, notice how design decisions — which tables exist and how they relate — naturally suggest which objects belong together, which is exactly the organizational benefit schemas provide.
A walkthrough of Oracle Live SQL, the free browser-based environment for running SQL statements against an Oracle database without installing anything. The video is likely to show how to sign in, open a SQL worksheet, run CREATE and SELECT statements, and browse the objects that belong to your account. Since an Oracle user account is effectively a schema, the tour of your object list is a practical look at what a schema contains.
Database Star is a well-established SQL and database design channel, and this tutorial gives you a no-setup place to practice the CREATE TABLE and schema-qualified naming exercises from this topic rather than only reading about them.
An overview of the database design process, from gathering requirements and identifying entities to defining tables, columns, keys, and the relationships between them. Expect coverage of how related tables are grouped and normalized into a coherent structure before any SQL is written. The result of that process is the logical design that a schema is used to hold.
It supplies the reasoning behind the subtopic on schema benefits for database organization: once you can see which tables form a related group, it becomes clear why you would place them in a named schema together.
These videos support the module outcomes by giving you both a place to practice and a reason to care about structure. The Oracle Live SQL tutorial provides a working environment in which you can type and run the DDL statements the module requires — CREATE TABLE with columns, data types, and constraints (MO2, MO3), ALTER TABLE modifications (MO4), and DROP statements compared against TRUNCATE and DELETE (MO5) — while seeing the resulting objects appear in your own schema. The database design video reinforces MO1 and MO3 by showing how entities, keys, and relationships are decided before DDL is written, which is what the PRIMARY KEY and FOREIGN KEY constraints you code later are actually enforcing. Together they connect the design thinking behind a schema to the DDL commands that build 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.