The data underneath it, and what the work costs

ISOM 472 — Fall 2026/2027

Dr. Mohammad AlMarzouq Week 3

ISOM 472: Project in IS — Kuwait University

Two things today

Data and schema

Tables, keys, the one relationship you need — and who is allowed to read what.

Token economics

What the agent's work actually consumes, and how to spend it deliberately.

You should leave with your own schema drawn. Both halves come back as Phase 2.

ISOM 472: Project in IS — Kuwait University

Tables and keys

Three words, then two

ISOM 472: Project in IS — Kuwait University

Three words

Table

One kind of thing. Orders. Customers. Products.

Row

One of them. One order.

Column

One fact about it. The total. The date.

ISOM 472: Project in IS — Kuwait University

A table, drawn

id customer placed_at total status
1 Fatima Q. 09:14 4.750 new
2 Bakery Co. 10:02 12.000 recorded
  • One kind of thing: orders
  • Two rows, five columns
ISOM 472: Project in IS — Kuwait University

Primary key

  • How you name one row unambiguously
  • Never two rows with the same one
  • Usually just id

Without it, you cannot say this order. You can only say "an order that looks like this".

ISOM 472: Project in IS — Kuwait University

Foreign key

  • How one table points at another
  • The order_items table holds an order_id
  • That is the entire mechanism

A foreign key is just a column holding another table's key. Nothing more clever is happening.

ISOM 472: Project in IS — Kuwait University

One-to-many

  • An order has many items
  • An item belongs to one order
  • Two tables, and the arrow points one way

This is the only relationship most of your projects will need. Learn it properly rather than learning four badly.

ISOM 472: Project in IS — Kuwait University

If a column would hold a list, it is a second table

ISOM 472: Project in IS — Kuwait University

Repeating groups — the usual mistake

Wrong

item1, item2, item3

What happens with a fourth? What happens when you search?

Right

An order_items table. One row per item, each pointing at its order.

item1, item2, item3 is a design fault, not a shortcut. It is the single most common thing I reject.

ISOM 472: Project in IS — Kuwait University

Decide the schema before you fill in the screens

A screen is cheap to change. Data already in a table is not.

ISOM 472: Project in IS — Kuwait University

Access rules

The part that is not optional

ISOM 472: Project in IS — Kuwait University

Your key is public, and that is intended

  • The anon key sits in the page, where anyone can read it
  • That is normal and it is by design
  • It is safe only because of what comes next
ISOM 472: Project in IS — Kuwait University

Row Level Security decides who may read and write

Per table. Every table.

ISOM 472: Project in IS — Kuwait University

With RLS off

  • Anyone who opens your page can read everything
  • And change it
  • And delete it

Including your client's real data, from a browser, with no account.

ISOM 472: Project in IS — Kuwait University

Nobody will remind you

  • The agent will write a working table and not mention this
  • It is not wrong. It answered the question you asked
  • Checking it is the Data Lead's job — every sprint

"It worked when we tested it" is exactly what an unprotected table looks like.

ISOM 472: Project in IS — Kuwait University

Never real data

  • No real customer information in the repository
  • None in a prompt, ever
  • Invent test data instead

The agent is very good at generating fifty realistic fake orders. Ask it for those.

ISOM 472: Project in IS — Kuwait University

Tokens

The other thing your project spends

ISOM 472: Project in IS — Kuwait University

What a token is

  • Roughly four characters of text
  • Everything the model reads is counted
  • Everything it writes is counted

Not a mystery unit. It is a count of how much text moved, in both directions.

ISOM 472: Project in IS — Kuwait University

You pay for the reading, not just the answer

The file you attached counts. The folder you pointed at counts.

ISOM 472: Project in IS — Kuwait University

A constraint, not an annoyance

  • Every engineer builds inside limits — time, money, machines
  • This one is no different, and it does not negotiate
  • The team that ignores it is the team with nothing left the night before a delivery

Planned for early, it is a constraint. Discovered late, it is an emergency.

ISOM 472: Project in IS — Kuwait University

Cost follows the work, not the prompts

  • One long agentic run can cost far more than twenty short questions
  • What is consumed is how much the agent does, not how much you type
  • "I only sent three messages" explains nothing

Antigravity's limits refresh on roughly a five-hour cycle, and what consumes them is the work the agent performs rather than the number of prompts typed. Checked 12 Sep 2026.

ISOM 472: Project in IS — Kuwait University

What you can see, and what you cannot

Antigravity

Your own remaining limits, refreshing on roughly a five-hour cycle.

Gemini Enterprise

Nothing. An end user is shown no usage data at all — the dashboard is administrator-only.

Both checked 12 Sep 2026. Nobody is withholding a number from you; for the browser tool there is no per-user number to read.

ISOM 472: Project in IS — Kuwait University

Where the work belongs

  • Planning and writing — Gemini Enterprise, in the browser
  • Building — Antigravity, on your machine
  • Thinking done in the browser is thinking the IDE does not have to pay for

The same split you were given in week 1, now with the second reason for it.

ISOM 472: Project in IS — Kuwait University

Context is the lever

  • Cost scales with how much the model has to read
  • Two named files beats "look at the whole folder"
  • Say what done looks like before it starts, so it does not go exploring

The cheaper version is usually the better version. A narrow question gets a narrow answer you can actually check.

ISOM 472: Project in IS — Kuwait University

When the quota runs out

  1. Narrow the ask — one file, one story, one question
  2. Move the thinking to the browser, keep the machine for building
  3. Your own key — the personal fallback we set up together in class
  4. By hand, and wait for the refresh

The last rung is not a failure. Part of this work is yours to do by hand, and a team that cannot do it is a team that stops.

ISOM 472: Project in IS — Kuwait University

Before next class

What is due, and what to read

ISOM 472: Project in IS — Kuwait University

Your own key — the fallback

  • A personal key — AI Studio or OpenRouter — is your fallback when the shared quota runs out
  • We work through it together, in class
  • Once it works, record it in the ledger

Nothing here is homework. This happens live, in the room.

ISOM 472: Project in IS — Kuwait University

Phase 2 — due at the end of week 4

Stories, the schema and acceptance criteria, the split, the environment, and your token plan. 10 marks.

  • The full checklist is on the course site, and we walk it in the last lecture

Exact dates are announced in class and on the course site.

ISOM 472: Project in IS — Kuwait University

What your token plan must say

  • Where each kind of work happens — planned in the browser, built on the machine
  • Which model for which task, and why that one
  • The tactics your team will use to keep a run narrow
  • What you will watch, and what you have no way of seeing
  • What you do when the quota runs out — decided before it does

It is delivered with the rest of Phase 2. Short and specific beats long and general.

ISOM 472: Project in IS — Kuwait University

Required reading — the database

Reading Time
Supabase — Tables and Data
https://supabase.com/docs/guides/database/tables		 20 min
Supabase — Row Level Security
https://supabase.com/docs/guides/database/postgres/row-level-security		 25 min

The Row Level Security page is the most important single reading of the week. Read it slowly, and test the examples.

ISOM 472: Project in IS — Kuwait University

Required reading — tokens

Reading Time
Gemini API — Understand and count tokens
https://ai.google.dev/gemini-api/docs/tokens		 15 min
Antigravity Docs — Models
https://antigravity.google/docs/models		 10 min

Read the concept section of the first one and skip the code samples. The second is the only first-party usage signal you can actually see.

ISOM 472: Project in IS — Kuwait University

Draw the schema. Turn RLS on. Write the plan.

All three, before the end of week 4.

ISOM 472: Project in IS — Kuwait University

Session 6 of 29. Two topics, about 45 minutes of talking between them — roughly 25 on schema and 20 on tokens — and the rest of the period is team work. Teams should leave with a schema drawn. This is not a database course: it is exactly enough relational modelling to design a small schema, plus the one access rule that is not optional, and then the constraint that governs how the building itself gets paid for. Tokens sit here rather than a week later on purpose — Phase 2 asks for a token plan at the end of week 4, and a plan taught two days before it is graded is not a plan.

Say the boundary out loud on both halves. Some students have had a database course and will want normal forms; some have had nothing — the scope is set by what the project needs, and the optional reading covers normalisation. The second half is conceptual on purpose: it is about how to think about a constraint, not about arithmetic.

Go slowly. For a good part of the room this is genuinely the first time, and every later idea sits on these three. Use a table from a project in the room rather than an abstract example.

Point at each part as you name it. Note that every column holds one fact and none of them holds a list — that is the observation the repeating-groups slide depends on, so plant it here.

The practical framing is what sticks: a key is how you point at a row. Names are not keys — two customers share a name, and one customer changes theirs.

Demystify it. Students expect something structural and it is a column with a rule attached. Draw the arrow between the two tables on the board once.

Resist teaching many-to-many today. If a team genuinely needs it, it is a five-minute conversation at their table, and every minute spent on it in the room is a minute not spent drawing their own schema.

This is the rule that prevents the most common failure, and it is short enough to remember. Say it, then show the failure on the next slide.

Work one live example from bad to good on the board — take a real table from a team in the room. The two questions in the left card are what make it land: a fourth item, and searching. Neither has an answer in the wrong version.

This is why the topic sits here rather than later. Every story a team writes touches the data, so a schema decided badly in week 3 is paid for in week 9. Screens can be rebuilt in an afternoon; a wrong table with three weeks of rows in it cannot.

Say "only" with weight. Students who notice the key in the page assume a mistake has been made and either panic or ignore it. Neither is right, and the next slide is the reason.

The single most important sentence of the week and the most important reading of the week. RLS is what makes a public key safe: the key gets you to the door, the policy decides which rows you may see.

Three bullets, delivered flatly, no drama. The note is what makes it real for a team that has a live client. Let it sit for a moment before moving on.

This connects straight back to verification: the agent optimises for the thing you asked for, and you did not ask for a policy. It is the clearest example in the course of why owning what you ship is a practical rule and not a slogan.

Both halves matter and the prompt half is the one they have not considered. A client's customer list pasted into a chat window has left the building. Seeding fake data is also simply faster, which is the argument that actually works.

Keep this conceptual and short. Nobody needs to compute a token count; they need the mental model that reading is not free, because that is the one that changes how they prompt.

This is the framing the whole half-hour exists to install. Do not moralise; it lands better as a flat statement about how engineering works than as a warning.

This surprises everyone, so say it twice and let the room argue. The intuition students bring is per-message pricing from consumer chat apps, and it is wrong here in the direction that costs them a delivery.

Say the second card plainly. Students will otherwise hunt for a counter that does not exist and conclude they have missed a setting. It also explains why nothing in this course ever asks them for a Gemini Enterprise usage figure.

Connect it back rather than presenting it as new. They were told plan in the browser, build in the IDE on day two; this is why that split is also the cheapest way to work.

This is the one slide with concrete tactics on it, and it is the one to slow down for. Ask the room for a prompt they sent this week and narrow it together.

Walk down the ladder in order. Most teams reach for rung three first and skip the two rungs that cost nothing. Rung four is also the honest answer to why the version-control and hand-editing skills in week 2 were not optional.

Frame the personal key as insurance, not homework. The teams that skip it are the teams that discover the quota is gone the night before a delivery, at which point setting up a key is the last thing they want to be doing.

Point at the checklist rather than reciting a schema-shaped version of it — the full list is on the course site and is walked in the last lecture. What today delivers is the schema and access-rules line on it. Teams should leave this room with a draft on paper: three or four tables is a normal size, and a team that has drawn ten has almost certainly misunderstood the scope.

Five lines, and each one is answerable in a sentence. Teams inflate this into an essay if it is left vague. The fourth line is the one that separates a plan from a wish: it forces them to say out loud that the browser tool shows them nothing.

Two readings only, and both are first-party documentation for the tool they are actually using. Tell them to read Tables and Data first even though RLS matters more — the policies do not make sense without the tables.

Both are short. The Models page is worth opening in front of them for ten seconds so they know where the limit indicator lives before they need it.

Close on the three. Any team that has not drawn a schema by the end of today's team time should say so before leaving — that is the blocker, and it does not improve by being left alone. The plan is the shortest of the three and the one teams will leave until last.