You Already Did Relational Data

The moment the idea sneaks in

Anyone who has spent a quiet evening in Google Sheets trying to pull a value from one sheet into another has, without realizing it, done relational data. VLOOKUP is relational data. Data validation pointing at a list in another sheet is relational data. Cross-sheet references in general are the same idea databases were invented to handle.

The instinct is the same in both worlds: instead of repeating the same information in every sheet (every row, every place it appears), keep it in one sheet and point at it from anywhere it's needed. That single instinct, made formal, is the entire foundation of relational databases.

What "relating" two sheets actually means

Imagine a contacts sheet and a separate appointments sheet. The contacts sheet has the full information about each person. The appointments sheet doesn't need to repeat the name, email, and phone for every appointment, because that information already exists in the contacts sheet. The appointments sheet just needs a way to say this appointment is for the person whose id is 2.

| id | name        | email             |
| -- | ----------- | ----------------- |
|  1 | Alex Rivera | alex@example.com  |
|  2 | Jamie Liu   | jamie@example.com |
|  3 | Sam Patel   | sam@example.com   |

| id | contact_id | service      | starts_at           |
| -- | ---------- | ------------ | ------------------- |
|  1 |          2 | Haircut      | 2026-04-22 11:30:00 |
|  2 |          1 | Consultation | 2026-04-22 10:00:00 |
|  3 |          3 | Consultation | 2026-04-23 09:00:00 |

The contact_id column in the appointments sheet is the pointer. It doesn't say "Jamie Liu," it says 2. To see who appointment 1 is actually for, the spreadsheet (or a database, or code, or VLOOKUP) goes to the contacts sheet, finds the row where id equals 2, and pulls back "Jamie Liu."

That move (stashing the full record once and pointing at it everywhere else) is what relational data is. The pointer column has a specific name in database vocabulary: a foreign key. Foreign because it refers to a row in a foreign table, key because the value it stores is the id (the key) of that other row.

Why this matters more than it might seem

Picture an app like Opsette without this idea. Every appointment row would need to store the full contact info for the client. Every message would need to store the full sender info. Every order would need to store the full buyer info. Now picture one of those clients changing their email. There would be hundreds or thousands of rows scattered across the database that all hold the old copy of that email, and every one of them would have to be tracked down and updated.

With relational data, that email lives in one place: the contacts table, in one row. Every appointment, message, and order just points at that contact by id. The client changes their email, the one row updates, and every reference in the entire system is instantly correct, because nothing was ever copied.

This is also why apps feel consistent. When the same person's name shows up in five different places in an app, it's the same name because all five places are looking at the same single row. There's no "version of Jamie Liu in the appointments view that might disagree with the version in the messages view." There's one Jamie Liu, in one place, referenced everywhere.

What's coming next

Module 2 is SQL: the language code uses to actually ask a database for things. SELECT, INSERT, UPDATE, WHERE. The grammar of database conversations.

Module 3 picks up relational data in full: foreign keys, joins (the database version of VLOOKUP), and the design choices that go into deciding which information lives in which table. The instinct will already be familiar. The vocabulary and the mechanics are what's coming.

What this module set up

By the end of this page, the floor underneath everything else in this unit is in place. Data lives in a hierarchy from RAM to browser storage to a real database on a server. A database is shaped like a stack of spreadsheets, with rows, columns, and ids. The spreadsheet model captures the shape but misses the speed, scale, and rules a real database brings. And the trick that turns a collection of separate tables into a coherent system is the simple idea of pointing at rows by id instead of copying them.

That's the foundation. Module 2 picks up the language piece next.