Relational
DB basics
Tables, unique IDs, and the relations between them: how structured data is really organized. What the AI does to access it.
Scroll, click, or use the arrow keys to move through.Scroll, or use the arrows and dots to move through.
A relational database is tables that know about each other.
Most of the world’s business data lives in relational databases: tables of rows and columns, like disciplined spreadsheets. The power is not in any single table. It is in the unique IDs that make every row findable and the relations that connect the tables into one picture.
A table holds one kind of thing.
Each table stores one kind of record: customers, orders, products. The columns are the facts you track, and every row is one instance. Unlike a spreadsheet, the rules are enforced: every column has a type, and a row cannot leave out what the table requires.
| id | name | city |
|---|---|---|
| 1042 | Megan | Nashville |
| 1043 | Frank | Memphis |
Every row gets an ID that never changes.
Each row carries a unique identifier, usually a number or a code, that is issued once and never reused. Names change, emails change, companies rename themselves; the ID does not. It is the one handle the rest of the system can always use to point at exactly this row and no other.
Tables point at each other with IDs.
An order does not repeat the customer’s name. The relation lives in IDs: here a join table pairs a customer ID with an order ID, and those two numbers connect everything the two outer tables know. One customer, many orders: the rows in the middle hold them together.
| id | name |
|---|---|
| 1042 | Megan |
| 1043 | Frank |
| customer_id | order_id |
|---|---|
| 1042 | 501 |
| 1042 | 502 |
| 1043 | 503 |
| order_id | order_no |
|---|---|
| 501 | A-1180 |
| 502 | A-1181 |
| 503 | A-1182 |
The middle table is nothing but the relation: each row pairs one customer ID with one order ID.
Store each fact once.
One giant table
The customer’s name copied onto every order. When the name changes you fix it in fifty places, miss three, and now the data disagrees with itself.
Related tables
The name lives in one row, and every order points at it by ID. Change it once and every part of the system sees the change, instantly and consistently.
One fact, one place, pointed at by ID everywhere else.
SQL is how you ask.
SQL is the standard language for asking questions of relational data, and it reads close to English: select these columns, from this table, where this is true. Joins are how a question spans two related tables at once. You do not need to write it fluently; being able to read it tells you what any system is really doing.
SELECT name, city FROM customers WHERE id = 1042;
| name | city |
|---|---|
| Megan | Nashville |
AI speaks fluent SQL.
Models read and write SQL very well. Hand an AI the layout of your tables and it can write the query, run it through a tool, and answer from the exact rows instead of from memory. Precise questions get precise answers. A program will use SQL to read and write information to and from a database. Databases support access control, so you can limit what an account can do.
The database answers with facts. Let the AI ask it.
One kind of thing per table, an ID that never changes, and relations that connect them.
That is the relational model. Every CRM, billing system, and order book you have ever used is built on it, and a little SQL is enough to see through all of them.