Before you can normalize anything, you must be able to read a table the way a database designer reads it: not as rows of data, but as a web of arrows. This page builds every symbol, word, and picture the parent note leans on — starting from "what is a table" and ending at "what is a superkey." Nothing here assumes you have seen databases before.
WHAT it looks like: columns run across the top as headings; rows stack downward, one thing per row.
WHY the topic needs it: every anomaly (insert / update / delete) is a thing that goes wrong when you add, change, or remove a row. You cannot talk about row-bugs without first seeing the grid the rows live in. This is the same grid ER Modeling turns real-world "things" into.
WHAT it looks like: picture one cell. If it holds 9991 it is atomic (one phone). If it holds 9991, 9992 it is not atomic — it is a tiny list smuggled into one box.
WHY the topic needs it: the very first normal form, 1NF, is entirely the demand "every cell is atomic." You cannot check 1NF until you can point at a cell and say "one value, or a list?"
This is the single most important symbol in the whole topic. Everything after this is bookkeeping about arrows.
WHY an arrow, and why this direction? We want a symbol for one-way decision. Knowing a student's ID tells you their name — so StudentID→StudentName. But knowing a name does not reliably tell you the ID (two students can share a name). The arrow points from the decider to the decided, and it is not automatically reversible. That one-directional-ness is exactly why we need a directed symbol → instead of an equals sign.
WHAT it looks like: in the figure, all rows with the same X value are boxed together; inside every box, the Y column shows the same value. If even one box has two different Y values, the arrow is broken — X does not determine Y.
Now we build keys, which are just special determinants.
WHAT it looks like: picture a set of columns whose value combination never repeats — each combination fingerprints exactly one row.
WHY the topic needs it: BCNF's entire rule is "every determinant must be a superkey." So "superkey" is the yardstick every arrow is measured against. See Candidate Keys and Superkeys.
WHAT it looks like: imagine a superkey {StudentID, name}. If StudentID alone already fingerprints the row, then name is dead weight — the set is not minimal, so it is a superkey but not a candidate key. Strip name: {StudentID} is the candidate key.
WHY the topic needs it: 2NF and 3NF phrase their rules in terms of whether the dependent attribute is prime. In the parent's BCNF example, Subject is prime (it's inside the key {Student, Subject}), and that primeness is the exact loophole that lets a table be 3NF but not BCNF. You literally cannot understand that loophole without this word.
WHY the topic needs it: 2NF forbids a non-prime attribute depending on a proper subset of a key. A "part" of a key can only exist if the key has ≥ 2 columns — this is exactly why 2NF can only be violated by composite (multi-column) keys, and why a single-column-key table is automatically in 2NF.
WHAT it looks like: three dots connected by two arrows, and a faint third arrow curving from the first dot to the last — the "for free" link. The parent's EmpID → DeptID → DeptCity is exactly this shape.
Read it top-down: the grid and the arrow are the two roots; keys grow out of the arrow; the normal forms sit at the bottom feeding into the parent topic Normalization. The decomposition machinery you'll need later lives in Decomposition — Lossless Join and Dependency Preservation, and the performance trade-off in Denormalization for Performance.
