The relational model: Math at the heart of tables
In 1970, Edgar Codd proposed a revolutionary approach: store data not as tangled lists but as “relations.” In development we call them tables. The main strength of this model is predictability and strict structure that protects data from chaos.
Files vs database
Click a card for details
📄
Storage in files
🗃️
Relational model
Core terms
Relational model glossary
These terms follow the mathematical tradition: relation, tuple, attribute, domain. In SQL they become CREATE TABLE, rows and columns with types.
A relation is a table.
A tuple is a row (record).
An attribute is a column (field).
A domain is the allowed type of values (e.g., only numbers or only dates).
Atomicity — a cell holds one indivisible value: not two phones in one row without a separate table.
How do relationships work?
Relationships in the relational model are supported through keys. A primary key (PK) is the unique “passport” of a row in its table. A foreign key (FK) references a PK in another table: the child points to the parent.
Click to see how tables reference the main parent
Students (students table)
📊Grades
✅Attendance
🪪Profiles (personal data, 1:1)
Implementation in SQL
Click a line with a marker for an explanation
sql
1
-- Parent table
▼
2
CREATE TABLE students (
▼
3
id SERIAL PRIMARY KEY,
▼
4
name VARCHAR(100) NOT NULL
▼
5
);
▼
6
-- Child table with a relationship
▼
7
CREATE TABLE grades (
▼
8
id SERIAL PRIMARY KEY,
▼
9
student_id INT REFERENCES students(id), -- Foreign key
▼
10
subject VARCHAR(50),
▼
11
score INT
▼
12
);
▼
Remember the properties of a “proper” relational table: there should be no fully duplicate rows, row order does not change the meaning of the data, and each column has a unique name within the table.