A set is an unordered collection of distinct things. Write it with curly braces.

Two marks to learn. is said "x is in S", or "x is an element of S", and means that is one of the things in . is said "x is not in S", and means it isn't. So is true, and is true.

Two properties matter enormously later, and they are the reason a set is the right model for a database table.

Unordered. . There is no first element.

No duplicates. is just . An element is either in or out; it cannot be in twice.

The empty set is written . It has nothing in it. It is not nothing — it is a perfectly good set that happens to be empty, the way an empty table is still a table.

Saying which things, instead of listing them

Listing works for four elements. It does not work for four million. So you describe the members by a condition.

Say it: the set of all x in S such that x is greater than 3. The colon means such that. You will also see a vertical bar, , meaning exactly the same thing.

The shape is always the same three parts: where the elements come from, a colon, and which ones you keep. With that set is .

This is the `WHERE` clause. `SELECT * FROM S WHERE x > 3` and are the same thought.

Size

is how many elements a set has — say the size of S, or the cardinality of S.

Put that together with the last section and you already have `COUNT`:

The number of elements of greater than 3. That is `SELECT COUNT(*) FROM S WHERE x > 3`.

One mark more: , said A is a subset of B, means every element of is also in . So is true, and is false.

Tuples, and the Cartesian product

A tuple is an ordered list of things, written with round brackets — . Unlike a set, order matters and duplicates are allowed: . A tuple of two things is a pair, of three a triple, of things an n-tuple.

The Cartesian product , said A cross B, is the set of every pair you can make by taking one element from and one from .

Note the size: . Always. You can cross more than two, and is the set of all triples. This is the `CROSS JOIN`, and it is where the word relational comes from.

A table is a set of tuples

Here is the whole idea, and it is worth pausing on, because everything else is built on it.

A table with columns `(cust_id, name, city)`, where ids are integers and the other two are strings, is a subset of the product of its column domains:

Say it: Customer is a subset of the integers cross string cross string. That one line says every row is a triple; the first slot holds an integer and the other two hold strings; and the table holds some of the possible such triples, not all of them.

A relation is exactly that — a set of tuples. A table is a relation. That is the entire content of the phrase "relational database", and it is why the mathematics of sets applies to it without modification.

The running example

Everything from the third note onwards uses this tiny database. It is worth keeping to hand.

Customer has three rows: , and .

Order has three: , and — the second column is the customer.

Line has four: , , and — order, sku, quantity, unit price.

So , and . Note that Cy has no orders. He is deliberate, and he is how you will find out whether a formula is right.