Foundations — Relational model — tables, rows, columns, NULL

Before you can read the parent note Relational Model, you need to own every word and symbol it throws at you. This page builds each one from nothing, in the order they depend on each other. If a term below feels obvious — good, that means the foundation is solid.

0. What is a "set"? (the atom everything sits on)

The parent note says a table is "a set of rows." Before that sentence can mean anything, you must know what a set is.

WHY the topic needs this: the whole reason "row order is not guaranteed" and "no duplicate rows" are rules is that a relation is defined as a set. If you don't have the set picture, those rules look like arbitrary trivia. See the parent's "Set, not list" callout — this is the picture behind it.

1. Domain — the pool of allowed values

WHY the topic needs this: columns don't accept anything — each column is tied to one domain. This is the seed of Data Types and Domains. Without "domain," the word "attribute" (next) is half-defined.

2. Tuple — one row of values, in a fixed slot-order

Notice the subtlety the parent leans on:

• The collection of rows is a set (no order, no duplicates).
• But one row itself is a tuple (ordered — box 1 is always the id, box 3 is always the age).

WHY the topic needs this: "row / tuple / record" are three names for the same thing. The parent uses all three interchangeably — now you know they mean "one filled-in form."

3. Attribute (column) and Schema — naming the boxes

WHY the topic needs this: the parent's "Table (relation): a named set of rows sharing the same columns" is exactly schema + tuples. This also underlies Normalization (rearranging the boxes) and Data Types and Domains (what each box allows).

4. Relation = Table — putting it together

WHY this map: it shows the parent topic (the grid + NULL logic) sits on top of set, domain, tuple, attribute, schema. Each arrow is a "you need this first."

5. Degree and Cardinality — two counts, don't swap them

WHY the topic needs this: these are the two size numbers you'll always be asked. The parent's worked table has degree 4, cardinality 3.

6. NULL — the "no clue" marker

WHY the topic needs this: NULL is the whole reason ordinary TRUE/FALSE logic isn't enough. It feeds COALESCE and NULL handling functions and the gotchas in SQL SELECT and WHERE.

7. TRUE, FALSE, and the new value UNKNOWN

Normal logic has two values. NULL forces a third.

WHY the topic needs this: the parent's truth tables and the famous age = 20 OR age <> 20 trap only make sense once "UNKNOWN = spinning coin" is in your head. A WHERE clause keeps a row only when the coin has landed on TRUE — a still-spinning coin (UNKNOWN) means the row is dropped.

8. Reading SQL symbols the parent uses

You'll meet these tokens in the parent — here is each in plain words:

WHY: the parent writes real SQL lines assuming you can read these. The pattern to burn in: = can return UNKNOWN, but IS NULL cannot — that's the escape hatch from the NULL trap.

Equipment checklist

Hide the answers, recall each, then reveal.

Connections

• Parent: Relational Model — the topic these foundations feed
• Data Types and Domains — deepens "domain"
• Primary Keys and Uniqueness — enforces the set rule "no duplicate rows"
• SQL SELECT and WHERE — three-valued logic in action
• COALESCE and NULL handling functions — handling the NULL marker
• Normalization — rearranging the columns (attributes)
• Foreign Keys and Referential Integrity — linking tables