The four tables you have queried for five chapters were not handed down; they were designed. This chapter shows the craft: how a blank page becomes tables, why one fact gets exactly one home, and how the schema itself learns to enforce the rules. It ends where every real database lives — with change, managed instead of feared.
5 topics
The Marquee's schema has carried every query in this book, and so far you have taken its shape on faith. Films in one table, screenings in another, a junction table in the middle — it worked, but nobody explained why the data was cut along exactly those lines. This chapter pays that debt. Design is the part of database work that happens before any SQL runs, and it decides whether the next five years with a schema are calm or miserable.
Five topics make up the craft. First the method: turning a business described in plain sentences into tables, one home per fact. Then the disease that method prevents, watched live in a deliberately wrecked table, and the name it goes by: normalization. Then constraints, the rules a schema enforces on its own, including the single line that makes double-selling a seat impossible. Then the honest negotiation about when copying data on purpose is worth the risk. And finally change itself, because no schema survives contact with a growing business unaltered.
The same Marquee data, two ways to keep it
One wide table one fact, many places
Film titles repeated in every booking row · prices drifting between copies · fix one row, miss its twins · convenient today, contradictory by Friday
The four-table schema one fact, one place
films · screenings · customers · bookings · every fact stored exactly once · a correction lands everywhere at once, because there is only one copy to correct