On this page

Block 1 · Week 3 · Databases and domain modelling · Practice lab

The Modelling Lab

Your app can think. Now teach it to remember. Eight short sections, all in this tab. Each ends with a checkpoint.

About 90 minutesNothing to installSaves on this device

Where you are

You built the app. Aarav is your first customer: an analyst who pastes his Monday workflow and gets back a plan. It works, he closes the tab, and on Tuesday everything is gone. Before any tool is opened, you answer three questions about his world: what are the things what does each have how do they connect. In the next lesson these answers become tables in Supabase.

0/8

CheckpointsSaved on this device

00Feel it: the app forgets

Be Aarav. Send a message, close the app, reopen it. Then switch saving on and do it again.

app runningin memory: 0 messages save to a table

The table

Pause and think

With saving on, what did the table need to know about each message to bring it back?

Reveal

Who said it, what was said, and when. One row per message, one column per fact. Everything a running app holds lives in memory, and memory dies when the app stops. Storage is a place outside the app that keeps rows after the app is gone. But a table is useless until you know the shape of what goes in it. That shape is what you model next.

Checkpoint: I saw messages vanish, then saw them come back from rows

01Question 1: what are the things?

Nouns are clues. The test is Create, Read, Update, Delete: can the app make one, find one, change one, remove one, on its own, and can there be many? If yes, it is a thing and gets its own table. If it only describes a thing, it is a fact. Tap each underlined word in Aarav's chat and say which.

signed in as Aarav

Monday's conversation

this bubbleHere is my weekly workflow: every Monday I open Jira to check my to-dos. I pick the high-priority ones, pull the numbers from our dashboard, write a short report for each, and send it to my manager on Slack.

9:12 am

jira-board.png

this bubbleHere is your plan: 1. Let Jira list the to-dos (saved filter) 2. You pick what matters 3. Export the dashboard the same way each week 4. Draft the report with the app 5. Send on Slack yourself, for now

Tuesday's conversation

Can you redo the plan in a more casual tone?

Quick version: let Jira do the listing, you do the picking. Export the dashboard the same way, draft with the app, keep the Slack send in your hands until you trust the draft.

Tap a word to begin.

0 / 16 placed

The things you have found

Checkpoint: all six things found, and I can say why "high-priority" is not one

02Question 2: what does each thing have?

A fact is what you need to recreate one of the thing. Facts become the columns of its table. Tap a card, then tap the table it describes. One card does not fit in any cell: hold it.

users

conversations

messages

workflows

diagnoses

hold for section 4

Every table already has an id: section 3 says why.

0 / 9 placed

Pause and think

Aarav picks a tone for each plan. Today, tone is a fact on the diagnosis. What would have to change in the product for tone to become a thing with its own table?

Reveal

If users could save named tones and reuse them across plans, a tone would be created, found, edited and deleted on its own. It would gain identity and a life, so it would become a thing. The word does not decide. What the product needs to do with it decides. That is the whole skill: drawing the line between a thing and a fact, for this app.

Checkpoint: every fact placed, and the tone answer written

03Question 3: how do they connect?

A spreadsheet stores facts about one thing. A database stores facts and how things link. Every link has one of three shapes:

one-to-one

Each side has exactly oneRare. Worth a second look: it may be one table.

one-to-many

One parent, many childrenMost of every model. The many side carries a pointer back.

many-to-many

Both sides have manyNo single cell can hold "many". A third table does, one row per pairing.

Pick the shape for each pair in Aarav's app. When it is right, place the pointer: every row has an address called id (its key), and a link is just a column on the many side holding the other row's key. The convention is the other table's name, singular, plus _id.

0 / 5 linked · Trace a message back to its owner:

workflowmanyworkflow_toolsmanytool

The third table is where the facts of a pairing live. Not on either side.

Checkpoint: five links placed, and the trace lights up end to end

04Rows or files?

Pause and think

Aarav attaches a screenshot of his Jira board. Can it go in a column?

Reveal

No. A cell holds a value you can type: text, a number, a date, yes or no. A screenshot is bytes. It goes in file storage, and the row keeps the link to it, plus the facts about it: which message it came with, its name, when it arrived. Rows for facts, files for everything large or binary, and a pointer between them.

Tap a card, then tap where it belongs.

A cell in a rowText, numbers, dates, yes or no.

A file in storage, with its link in a rowImages, documents, audio, video.

Eight cards.

0 / 8 placed

So Aarav's model gains one more table: attachments, with a pointer to its message, the file's link and the file's name. In Supabase, in the next lesson: tables for rows, a storage bucket for files.

Checkpoint: all eight sorted, and I can say what the row keeps about a file

05Aarav's model, from your own placements

Nothing below is pre-drawn. Each box is a thing you tagged in section 1, each column a fact you placed in section 2, each line a pointer you placed in section 3, and the attachments table comes from section 4. Dashed pieces link back to where they are placed.

The bridge to your API table

Your API table from the practice set for The second interface: APIs, beside the tables it lands on. Every noun in an address is a thing here. That is not a coincidence: the API is how a request reaches a row.

Action	Method	Address	Table
Create	POST	/workflows	workflows
Read	GET	/workflows/{id}	workflows
Create	POST	/workflows/{id}/diagnoses	diagnoses
Read	GET	/workflows/{id}/diagnoses	diagnoses

Can the model answer the product's questions?

A model is done when it can answer what the product must ask. Three questions for Aarav's app. Tick each only when you can point at the exact tables and pointers that answer it.

"Show me Aarav's last conversation, with every message in order"users → conversations by user_id, then messages by conversation_id, ordered by created_at.
"Show every plan this workflow ever got, oldest first"diagnoses by workflow_id. History exists because a diagnosis is a row, not a cell on the workflow.
"Which screenshot went with which message?"attachments by message_id; the file itself behind file_url.

Close the tab now. Nothing is lost.Next: the Arena, six briefs that drill one move each. Then your own app.

Checkpoint: every piece placed, and the three questions ticked

06The Arena 0 / 6 done

Six briefs, one move each, starting with the app you are building. Build the tables, then Check my model. Every check is a tick or a cross; done means every structural check is a tick. Column suggestions do not count.

Checkpoint: six briefs done

07Your model

The same three questions, pointed at the app you are actually building. Path A: a real process you observed yourself. Path B: load Aarav's model and add one table of your own.

In one line, what does your app do?

Three questions your data must answer

1 2 3

1 · the things

Collect candidate nounsKeep the ones the app must create, find, change and delete on their own, and can have many of.

2 · what each has

The facts to recreate oneThose are its columns. A fact that only describes something else is not a table.

3 · how they connect

Name the shape of every pairA pointer on the many side; unique if one-to-one; a third table if many-to-many.

pointers go on the many side

Rows or files, for your app

Which files does your app store, and which column holds the link to each?Write "none" if your app stores no files. That is a valid answer.

The bridge, for your app

Your API table from the APIs practice set, with a table name written beside every addressOne address per line. If an address has no table, say what it does instead.

Before calling it done

My tables can answer question 1Point at the tables and pointers that answer it.
My tables can answer question 2
My tables can answer question 3
Every pointer is on the many side, and every many-to-many has a third table
I tried to create a wrong state and the model refuses itA message with no conversation, two plans overwriting each other, the same pairing twice.

Checkpoint: my model drawn, three questions answered, files and bridge written

You cannot store what you cannot describe.Now finish the practice set. Next lesson: these tables, typed into Supabase, and a row that survives a refresh.