Meet Marquee
Every idea in this book will be taught on the same small business: the Marquee, Lora's two-screen neighborhood cinema — the one that lost a Saturday booking to a spreadsheet two pages ago. This page is a proper introduction, because the Marquee is not decoration. Its data is exactly the data every real business keeps, small enough to hold in your head and rich enough to need every tool this course teaches.
By the end of the book you will have watched this cinema's data go from that spreadsheet to a live booking system a website can trust. Everything accumulates: the tables built in Chapter 2 are the ones queried in Chapter 3, redesigned in Chapter 6, and defended against double-booking in Chapter 7. Nothing resets. So let's meet the data.
What the Marquee Remembers
Strip the cinema down to the facts it cannot afford to forget, and there are four kinds. First, the films — the poster wall: The Long Rain, Paper Lanterns, Night Bus, each with a running time and an age rating. Second, the screenings — the showtimes board: which film plays on which screen at which time, and what a ticket costs. A cinema with two screens runs several of these a day.
Third, the customers — the regulars: names, emails for the newsletter, when they joined. And fourth, the bookings — the reason the whole system exists: who reserved which seat for which screening, and when they did it. Four kinds of facts. That's the entire cast.
Facts Point at Each Other
Now the important observation — the one this whole course is secretly about. These four kinds of facts are not independent. A booking mentions a customer, and it mentions a screening: "Anna reserved seat G7 for the Friday 8 p.m. show." A screening, in turn, mentions a film: "the Friday 8 p.m. show on screen 1 is Night Bus."
The facts point at each other, and the pointing is not clutter — it is the information. A booking that doesn't say which screening it belongs to is just a name and a seat number, useless for filling a room. When we start building tables in the next chapter, this pointing gets a precise mechanism and a name, and "relational" — the word in this book's subtitle, so far unexplained — will finally mean something exact.
The Questions Lora Actually Asks
Data earns its keep by answering questions, so here are the ones Lora asks in a normal week — each one a preview of a query you will write. "What's on tonight after seven?" — that's a filtered list, Chapter 3. "How full is the Friday 8 p.m. show?" — that's counting bookings per screening, Chapter 3 again. "Who's coming to Night Bus on Friday, in which seats?" — that touches all four kinds of facts at once, and reassembling them is Chapter 4's whole subject.
And the quiet ones that decide the business: "which film sold best this month?", "which regulars haven't been in since spring?" By the end of Chapter 4 every question in this paragraph is one you can answer yourself, with a query short enough to fit on a napkin.
Why a Cinema, of All Things
Not for the popcorn. Look at the shape of the Marquee's data: a catalog of things on offer, a schedule of events, a set of people, and a record of purchases connecting people to events. Now look at a clothes shop: catalog, stock, customers, orders. A clinic: doctors, appointment slots, patients, appointments. An airline: routes, flights, passengers, tickets. Same four-part shape, different nouns.
That is the real reason the Marquee carries this book. Learn to model, query, and protect one catalog-events-people-purchases business properly, and you can read almost any real schema on sight — because most of them are this shape wearing different costumes. There is no analogy on this page for exactly that reason: the cinema is already the concrete thing, and no metaphor would improve on it.
- "Example data is toy data — real jobs will be different." The Marquee's four entities — catalog, events, people, purchases — are the same shape as a shop, a clinic, or an airline. Only the nouns change; the structure and the problems are identical.
- "I need to memorize this schema." You don't. It reappears on nearly every page for ten chapters; it will memorize itself long before you notice.
- "The story is what matters." Only the data matters. Lora exists so that every table has a reason to exist and every query has a question behind it — there is no plot to follow.
- "Bookings are just a detail of customers." A booking is its own fact — it connects a customer to a screening and carries its own information (the seat, the time it was made). Treating it as its own thing turns out to be one of the deepest ideas in the book (Chapter 2 gets there).
- One accumulating example beats fifty disconnected ones: every new idea in this book lands on data you already know, so the effort goes into the idea, not into learning a new cast each chapter.
- The catalog-events-people-purchases pattern is a professional superpower in disguise — recognize it, and unfamiliar schemas at real jobs open up on sight.
Knowledge Check
Which four kinds of facts does the Marquee keep?
- Films, screenings, customers, and bookings
- Films, staff on shift, snack sales, and outside suppliers
- Screens, prices, tickets, and reviews
- Invoices, receipts, refunds, and taxes
A booking "points at" a customer and a screening. What does that pointing mean?
- The booking contains a full copy of the customer's and the screening's own details
- The booking's meaning comes from naming which customer and screening it connects
- The booking is stored on the same part of the disk as the customer
- If the customer is deleted, the booking is automatically deleted too
A clinic keeps doctors, appointment slots, patients, and appointments. Why does this book claim you'll find that schema familiar?
- Because clinics and cinemas are in similar businesses
- Because it's the same catalog-events-people-purchases shape with different nouns
- Because all businesses are legally required to structure their own data the same way
- Because SQL forces every business into identical tables
The page insists a booking is its own fact, not just a detail of a customer. Why?
- Because it links a customer to a screening and carries its own details, like the seat
- Because customers matter less to the cinema than the bookings they make on a busy night
- Because each customer is allowed to hold only one booking in the system at any time
- Because the database keeps bookings on faster storage than it keeps the customer records
You got correct