======================================
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):

.. list-table::
   :header-rows: 1

   * - 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:**

#. Cross-out test — delete a row, does something disappear that shouldn't?
#. 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):

#. Doing — hand in tables (now worthless, AI does this)
#. Acquiring — recite 1NF/2NF/3NF
#. Comprehending — do it by hand, defend it, machine off
#. Verifying — run both tests on *any* design (including AI's) and find what it
   silently assumed
#. 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:

#. Read ``database.md`` and extract "the framework" by answering 6 questions (two
   facts, closed map, hand-simulation, hinge, page eight, the unfinished part).
#. 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)?
#. 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.)
#. **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.