Tables, Rows, and Columns

Everything a relational database holds lives in tables, and a table is stricter than it looks. Its columns are declared up front — each with a name and a kind of value it accepts — and every row fits that exact set of columns, no more and no fewer. Nothing arrives shapeless. The Marquee's first table, films, turns Lora's poster wall into exactly four declared columns, and nothing else will ever fit into it.

If your mental picture right now is "so, a spreadsheet grid" — hold that thought, because this page exists to replace it. The grid look is the same; the rules are opposite. A spreadsheet lets any cell hold anything. A table enforces its declared shape on every single row, forever, and that strictness is a feature, not bureaucracy: it is the "structured" from Chapter 1, made real.

A Table Is a Declared Shape

The order of events is the whole idea. With a spreadsheet you open a blank grid and start typing. With a table you decide the columns first — the named slots every fact must fill — and only then do rows arrive. For films, Lora decides: every film has a title, a running time in minutes called runtime_min, and an age rating. Plus one more column, film_id, a number that names each row — it earns a full page of its own two topics from now, so let it sit quietly for the moment.

Think of a printed form. The designer of the form decides the blanks — name, date of birth, signature — before anyone fills one in, and every filled copy answers every blank. Columns are the blanks; a row is one filled copy. Map the analogy and let it go: from here on, columns and rows are the real words.

Once the shape is declared, it is enforced. You cannot add a film with a fifth value the table has no column for, and you cannot leave a declared column out and hope nobody notices. A spreadsheet would shrug at both. The table refuses — and Chapter 1 already taught you to hear that refusal as the system working.

Rows Are Facts

A row is one complete fact: one film, one customer, one booking. The row for Night Bus holds everything the table knows about Night Bus — its id, its title, its 98 minutes, its rating — and nothing about any other film. When Lora adds a fourth film to the program, that is one new row; the columns don't change at all.

Here is the films table with the Marquee's current program, exactly as the database would show it:

Three rows, four columns, twelve values — and one detail the grid hides: the rows have no built-in order. Night Bus is not "third" in any meaningful sense; the database is free to hand the rows back in any arrangement it finds convenient. If you want an order, you will ask for one explicitly when you query — that is Chapter 3's business. For now, remember that "the first row" is not a thing a table knows.

Reading a Table Out Loud

A skill worth practicing deliberately: turning a row back into the sentence it encodes. The row for Night Bus says: "the film Night Bus runs 98 minutes and is rated PG-13." The row for The Long Rain says: "the film The Long Rain runs 112 minutes and is rated PG." Every row in every table you will ever meet is a sentence in disguise — the column names are the grammar, the values are the words.

This is why "one row = one fact" is the reading skill that makes unfamiliar databases legible. Show a professional a table they have never seen, and the first thing they do is read one row out loud to themselves: what is this table one-row-per-of? One row per film, per order, per patient, per payment. Answer that, and you understand the table.

How the Shape Gets Declared

Declaring a table is itself done in SQL, with a statement called CREATE TABLE. You are not expected to memorize the syntax yet — just to read it and recognize what it does:

CREATE TABLE films (
  film_id      INTEGER,
  title        TEXT,
  runtime_min  INTEGER,
  rating       TEXT
);

Read it as the sentence it is: create a table named films, with a column film_id holding whole numbers, a column title holding text, a column runtime_min holding whole numbers, and a column rating holding text. Each line names a column and states what kind of value it accepts. Those "kinds" — INTEGER, TEXT, and their relatives — are called types, and they are the entire subject of the next page.

Notice what the statement does not contain: any data. CREATE TABLE builds the empty declared shape — the blank form, printed and ready. The rows come later, one INSERT at a time (Chapter 5 handles that verb properly). Shape first, facts second: that ordering is the relational model's signature move, and you have now seen it written down.