How It All Connects

An interviewer asks one question: "Walk me through how you'd design a database."

You know ER models. You know normalization. You know indexes. But right now they're seven separate boxes in your head, and the question needs one line of thinking.

Why & what

Here's the thing nobody tells you: the modules aren't a list. Each one exists because the previous one caused a problem.

Once you see that chain, you can start anywhere and walk in either direction — which is exactly what an interview requires.

The whole course is one pipeline: model the world, turn it into tables, split the tables, query them, protect them from each other, then make them fast.

How it works

Follow one fact — Aisha got an A in DBMS 101 — through every module.

1. Module 2 gave you the picture. Student and Course are entities, "enrolls in" is a relationship, and it's many-to-many. The problem it created: a picture can't store anything.
2. Module 3 turned it into tables. Student, Course, Enrollment — with roll_no as a primary key and foreign keys linking them, plus constraints refusing roll 999. The problem it created: nothing yet stops you putting everything in one wide table.
3. Module 4 split them properly. Prof. Rao's name lives in one place, so renaming him is one update. The problem it created: the data you want is now scattered across four tables.
4. Module 5 put it back together on demand. Joins reassemble the scattered pieces; GROUP BY answers "how many per course." The problem it created: 900 students are running these queries simultaneously.
5. Modules 6 and 7 handled the crowd and the clock. Transactions and locks stop concurrent users corrupting each other. Indexes stop every query reading every block.

Read backwards and it works too: "Why do we need an index?" → because tables got big → because we split them properly → because one big table caused anomalies.

In one sentence each, why does normalization make joins necessary, and why do joins make indexes matter?

Normalization splits one table into several, so the data you want lives in more than one place joins put it back. And joins match rows across tables, so without an index each match means scanning every block.

Notice: every module answers a problem the previous module created.

Common confusion

Students treat these as unrelated exam topics and get stuck the moment a question crosses a boundary — like "how does normalization affect performance?"

That question has an easy answer once you see the chain: normalization removes repeated data, which means more tables, which means more joins, which means more reads — so you add indexes to pay that cost back, or denormalize deliberately if you've measured that you must. That answer touches Modules 4, 5 and 7 in one breath. That's what a strong candidate sounds like.

Interview angle

1. "How does normalization affect query performance?" — More tables, more joins, slower reads — repaid with indexes, or with deliberate denormalization when measurement justifies it.
2. "Why does a primary key make lookups fast?" — Because databases build an index on it automatically, so it's a B+ tree lookup rather than a full table scan. This connects Modules 3 and 7.
3. "What's the relationship between an ER diagram and the tables you finally build?" Entities become tables, attributes become columns, M:N relationships become their own junction table.

Recap

The course is one chain — model, tabulate, normalize, query, protect, optimise where each module solves the problem the one before it created.