Read a small table as a collection of real-world records: each row is one thing, each column is one kind of fact about it, and each cell holds a value. Notice why row order, column order, and spreadsheet-style formatting are not the meaning of the data.

Compare a table’s definition with the rows currently stored in it. Use column names, data types, NULL rules, and constraints to tell what kind of values belong in each place and what the database is meant to protect.

Apply the previous explanations in a guided problem.

Find the column or columns that can identify exactly one row. Reason about uniqueness, required values, stable identifiers, and the tradeoff between natural keys like email and surrogate keys like customer_id.

Trace how a value in one table can point to a row in another table. Use parent and child tables, matching key values, optional references, and orphan records to understand what a foreign key protects.

Apply the previous explanations in a guided problem.

Check your understanding with a short quiz.

Look at key columns to recognize one-to-many, one-to-one, and many-to-many relationships. See why many-to-many connections usually need a separate link table with foreign keys to both sides.

Spot common spreadsheet habits that do not fit relational tables, such as lists in one cell, repeated columns like phone1 and phone2, mixed meanings in one column, and summary rows. Practice reshaping them into consistent rows, columns, and keys.

Apply the previous explanations in a guided problem.

Check your understanding with a short quiz.

Review this chapter with practice based on your mistakes.