Course Overview

A team gives you a new feature to build. It stores orders for a food delivery app.

You already know SQL. You can create a table and read rows from it. But first you have to decide something else: which tables should exist at all?

Where does the customer address go? Should it sit in the orders table, or in a table of its own? What happens when a customer moves to a new city? Do all the old orders then show the new address?

This course answers questions like those. The skill has a name: data modeling. Data modeling means turning real world facts into a set of tables, columns, and links between them.

Why this skill is worth learning

A schema is the list of tables and columns in a database. Application code is easy to change. A schema is not.

Once a table holds ten million rows, changing its shape needs a migration script, a careful rollout, and often some downtime. A weak design keeps costing the team for years.

Interviewers know this. Database design questions come up for backend engineers, data engineers, and data analysts. A common one sounds like this: "Design the tables for a hotel booking system."

That question has a method behind it. This course teaches the method, step by step.

The path this course follows

The course moves in one straight line. It starts with a plain English description of a business. It ends with a finished set of tables that a database can run.

Fundamental Concepts. What a database is, what a database management system does, and how relational databases differ from non-relational ones.

Data Modeling. The three levels of a data model: conceptual, logical, and physical. You also learn the steps of the modeling process and the common mistakes.

Entity-Relationship Data Modeling. The drawing language for a design. You learn entities, attributes, relationships, cardinality, participation, and weak entities. Then you draw a complete ER diagram for an employee management system.

The Relational Data Model. The rules of tables themselves: relations, tuples, attributes, and keys. You learn the integrity constraints a database enforces for you. Then you convert an ER diagram into real tables.

Functional Dependency. A precise way to say "this column decides that column". It is the tool that makes the next chapter exact instead of a matter of opinion.

Normalization. First normal form through fifth normal form, each with a worked example. Two exercises close the chapter, with full solutions.

Case Studies. Six complete designs, built end to end: a hospital, a hotel, a bank, Instagram, an e-commerce platform, and an online food delivery system.

Who this course is for

You are a student getting ready for coding and system design interviews, and database questions are the part you are least sure about.

You are a working engineer who writes queries every day but has never designed a schema alone. You want to know why the tables around you look the way they do.

You are a data analyst or data engineer who reads other people's schemas. You want to judge whether a design is sound before you build reports on top of it.

What you need before you start

You need to know what a table, a row, and a column are. You need to have written a simple SELECT query at least once.

You do not need to know any normal form. You do not need ER notation, set theory, or a particular database product. Every term is defined in the sentence where it first appears.

The examples use standard SQL. They run on MySQL, PostgreSQL, SQL Server, and Oracle with little or no change.

How to use this course

Read the chapters in order. Each one uses the one before it. Normalization needs functional dependency. Functional dependency needs keys. Keys need the relational model.

Draw as you read. Keep paper or a drawing tool open. An ER diagram is a skill of the hand as much as the head, and reading about one is not the same as drawing one.

Do each exercise before you read its solution. The two normalization exercises and the six case studies are where the learning actually happens. Give each one a real attempt first, even a wrong one.

Say your reasoning out loud in the case studies. In an interview you have to explain why a column sits in one table and not another. Practising that explanation is part of the work.

Key Takeaways

• Data modeling turns real world facts into tables, columns, and the links between them.
• A schema is expensive to change later, so the design decisions you make early matter for years.
• The course runs in one line: concepts, then modeling, then ER diagrams, then tables, then dependencies, then normalization, then six full case studies.
• You need only basic SQL to start. Every other term is defined where it appears.
• The exercises and case studies carry most of the value. Attempt each one before reading its solution.

By the end you will be able to read a description of a business and ask the questions that matter. You will draw an ER diagram, turn it into tables, and defend each choice you made. That is the same work a database design interview asks for. Let us begin with what a database actually is.