Start with something familiar. A spreadsheet of books might look like this:
| Title | Author | Genre | Price |
|---|---|---|---|
| The Salt Road | Ada Okonkwo | Fiction | 499.00 |
| Quiet Machines | Rohan Mehta | Science Fiction | 649.00 |
A database table looks almost the same. The vocabulary is different and the rules are stricter, and both differences are the point.
The three words you need
- A table holds things of one kind. Books in one table, customers in another. Not both in one.
- A row is one of those things. One book. One customer. One order.
- A column is one fact about every thing in the table. Every book has a title. Every book has a price.
Say it out loud once: a row is a thing, a column is a fact about it. Almost every confusion later — especially with joins and grouping — comes from losing track of which rows exist.
The rules a spreadsheet does not have
In a spreadsheet you can type "ask us" into a price cell. Nothing stops you. Three months later a total is wrong and nobody knows why.
A database column has a declared type. price is declared as a number, so "ask us" is rejected the moment you try. This sounds like bureaucracy until the first time it saves you. The type is not there to annoy you; it is there so that when you add up a column, the answer means something.
The strictness is the feature. A spreadsheet lets you be wrong quietly. A database makes you be wrong loudly, immediately, at the point where you can still fix it.
Why "relational"
Our bookshop keeps five tables: authors, books, customers, orders, order_items. Why not one big table with everything on each row?
Because you would repeat yourself. If every book row carried the author's full name and country, then Ada Okonkwo's country would be stored once per book she wrote. Correcting it means finding every copy — and missing one leaves the database contradicting itself.
So each fact is stored once, in the table it belongs to, and rows point at each other. A book row does not carry the author's name; it carries an author_id that says which author. That pointing is the "relational" part, and section 7 is about following those pointers.
SQL is a request, not a recipe
This is the idea that trips up people who arrive from programming languages. You do not tell the database how to find your data — no loops, no "check this index first". You describe the result you want, and the database works out how to produce it.
That is why a query reads almost like a sentence, and why two people can write the same request differently and get identical results at identical speed. You are stating a requirement, not issuing instructions.