The Relational Model & SQL

Difficulty
Importance

The problem

Applications need to store structured data durably and query it flexibly — not just 'get this one record' but 'get every record matching these conditions, combined with related records from elsewhere' — without writing custom retrieval code for every possible question in advance.

Why now

Sets and logic already gave the vocabulary for describing collections and conditions precisely; the relational model is that vocabulary made literal — a table is a set of rows, and a SQL query is a logical proposition selecting a subset of it. This is why SQL reads like formal logic once you know what to listen for.

Mental model

A table is a set of rows, each row a tuple of values; a query is a proposition over that set — WHERE is a filter (set restriction by a predicate), JOIN is a combination of two sets by a matching condition, and the whole relational model is set theory and predicate logic wearing a database's clothes.

Requires

Unlocks

Used in

Projects

  • Design a small relational schema (e.g. books and authors) and write SELECT, INSERT, UPDATE, and DELETE queries against it
  • Write the same data-retrieval question as both a SQL query and an equivalent set-theory statement, and confirm they say the same thing

Examples

  • SELECT * FROM users WHERE age > 18 is a set restriction — keep only the tuples satisfying the predicate age > 18
  • SELECT * FROM a UNION SELECT * FROM b is literally the set union of two relations

Resources

Mastery checklist