Database Design Fundamentals
BeginnerYou already write SQL queries — SELECT, JOIN, WHERE — but nobody ever taught you how to actually design the tables those queries run against. This course fixes that gap for developers, analysts, and anyone who works with data but learned SQL by trial and error rather than by studying schema design. It is engine-agnostic: every example uses standard SQL concepts that apply whether you are on PostgreSQL, MySQL, SQL Server, or SQLite. You start with data modeling basics — entities, attributes, and how to turn a set of business requirements into an entity-relationship diagram, moving from a conceptual sketch to a logical model to a physical schema. From there you learn normalization: the update, insert, and delete anomalies that come from a poorly structured table, the reasoning behind first, second, and third normal form, an intuitive feel for Boyce-Codd normal form, and, just as important, when deliberately denormalizing is the right call. Next comes the vocabulary of relationships: primary keys, foreign keys, composite and surrogate keys, and how one-to-one, one-to-many, and many-to-many relationships are actually implemented, including the junction tables that make many-to-many possible, plus the constraints that protect referential integrity. You then look under the hood at indexes — how a B-tree index actually works, how to choose which columns to index, the basics of reading a query plan, and the real trade-offs indexes introduce. The course closes with real-world schemas: patterns for e-commerce, social apps, and booking systems, plus audit trails, soft deletes, safe migrations, and the anti-patterns that quietly wreck a schema's future. You finish able to design a database, not just query one.
Course content
Certification Exam
Certification Exam
Database Design Fundamentals
🔒 Unlock the exam
Complete the requirements above to unlock the exam
Certification Exam
Database Design Fundamentals
30 Questions
All difficulty levels
45 Minutes
Auto-submits when time expires
70% to Pass
Earn your certification badge
No Going Back
Once you answer, you move forward
Tips
See allEvery schema change is a migration, never a manual edit
Track schema history the same way you track code history
created_at and updated_at are not optional
Every real table needs a history, even a rough one
Soft delete with a timestamp, not a boolean
deleted_at tells you both the fact and the moment
Read EXPLAIN before you add another index
Guessing at performance wastes indexes and write speed