Notes: Normalization & the AI Guide

Notes on the four PDFs in the idk folder. Two are chapters (content), one is a teacher’s guide, and one is a meta-assignment that asks you to reverse-engineer the “framework” behind all of them.

database.md — the framework chapter

Everything in a database is one of two things:

  • Where facts sit (tables) → normalization

  • What moves them (queries) → SQL

Key ideas:

  • The closed map: only 6 operations ever happen to rows — keep rows, keep columns, join, group, sort, combine. Because the list is closed, one question always works: “which of these are you doing, and what did it do to your rows?”

  • Hand-simulation: one sheet per operation, real rows written out by hand, on purpose slow.

  • The hinge: rows in / rows out. Watching these two numbers is how you catch a query that’s silently wrong (e.g. a join that doubles or drops rows).

  • “Page eight”: a result that’s arithmetically perfect but answers the wrong question — no error, no warning, just wrong forever. Worse than a crash because nothing flags it.

  • Unfinished part: the “rungs” (skill ladder) are listed, not walked, in this chapter — that’s the guide’s job (see below).

Worked example: a fee total comes back as $18,400 (should be $9,200) because joining students↔clubs multiplies rows for anyone in 2+ clubs. Only “30 in, 61 out” bookkeeping catches it.

normalization.md — student chapter (the “where facts sit” half)

School club sign-up sheet → three disasters from bad design:

  • Update anomaly — a fact (room 104) repeated 3x; miss one edit, now inconsistent.

  • Insertion anomaly — can’t add a new club with no members yet.

  • Deletion anomaly — deleting Sam’s row also deletes “Mr. Lee” and “Auditorium”.

The one question that fixes all three: “What is this fact about?” Group columns by their answer → separate tables.

Five-step hand process: write the messy table → list columns → say what each is about → group → redraw as real tables.

Maps to formal terms (taught after the exercise, not before):

Did

Name

One value per box

1NF

Move out facts about only part of the key

2NF

Move out facts really about another fact (transitive)

3NF

Two tests to know you’re done:

  1. Cross-out test — delete a row, does something disappear that shouldn’t?

  2. Change test — change one fact, count boxes to fix; the answer should always be 1.

Trade-off: normalized tables are safe to change but need a JOIN to read back as one view (next chapter’s topic).

Has 4 practice exercises (pizza orders, library loans, songs/artists, field trips).

normalization-ai.md — teacher’s guide (AI-in-the-room version)

Core claim: the machine can normalize a table perfectly; it cannot know your organization. E.g. is “Cost” a fact about the trip or the destination? The data can’t say — only asking a real person can. AI will pick one, sound certain, and never mention it guessed.

Skill ladder (only the first two rungs used to be the whole course):

  1. Doing — hand in tables (now worthless, AI does this)

  2. Acquiring — recite 1NF/2NF/3NF

  3. Comprehending — do it by hand, defend it, machine off

  4. Verifying — run both tests on any design (including AI’s) and find what it silently assumed

  5. Guiding — supply the missing real-world knowledge up front and direct the design

Suggested class structure (3-way session, ~40 min): messy table → students work it alone, machine off (5 min) → compare/argue → hand to AI, read its answer → “where do we differ, and what did it assume about us?” → tell AI the missing fact, re-run, watch the design change.

Exercises that survive AI: audit (“is this AI-generated design right? what did it assume?”) and supply-the-world (“what 3 questions would you need to ask the school before you could judge this?”) — neither has an artifact a machine can produce for you.

The assignment: “Reading the Framework Through Two Chapters”

This file is a meta-exercise, not more content — it asks you to:

  1. Read database.md and extract “the framework” by answering 6 questions (two facts, closed map, hand-simulation, hinge, page eight, the unfinished part).

  2. Find each of those 6 parts in normalization.md — is it there, what shape does it take, and if absent is that a real gap or expected (because that chapter only covers half the framework)?

  3. Do the same for normalization-ai.md, plus: what’s in it that’s in neither other file? (Answer given in the doc: the teacher/third party — a chapter works alone, a guide is about an encounter with someone else in the room.)

  4. Deliverable: a table (framework parts × the two chapters, showing what’s in each box, including empty ones) + one paragraph on whether either chapter could replace the other.

The PDF includes the author’s own worked answer as a reference/model — useful to check your reasoning against once you’ve done your own pass, not before.

Biggest idea across all four docs

A database (or any tool) can be flawlessly correct and still wrong, because correctness is about the mechanism and truth requires knowing something about the real world that isn’t in the data. AI raises the stakes on this because it’s fluent and confident even when it silently guessed.