Introduction to the Relational Model

The relational model, introduced by Edgar F. Codd in 1970, organizes data as a collection of relations — what we usually draw as tables. Each relation is a set of tuples (rows), and each tuple is a set of attribute values (columns). The radical idea was not the table itself but what Codd removed: there are no pointers, no nesting, and no fixed access path baked into the data. Everything a program needs to know lives in the values, and you ask for data by describing what you want rather than spelling out how to fetch it.

That single decision — separating the logical shape of data from its physical storage — is why the model has lasted. The applications on top do not break when the engine changes how rows are laid out on disk or which index it uses; this is the property Codd called data independence.

Why this matters

• Values, not pointers. Two rows are related because they share a value (a key), not because one holds the memory address of the other.
• Set-at-a-time, declarative access. A query names a result set; the system chooses the procedure. This is what makes a query optimizer possible.
• A mathematical backbone. Relations are sets, and relational algebra gives a small, closed set of operators over them — every operator takes relations in and returns a relation out, so operations compose.
• Enforceable integrity. Because relationships are values, the system can guarantee them with declared constraints (primary keys, foreign keys) rather than trusting application code.

A worked query, two ways

Suppose we want the titles of the courses student S2 is enrolled in, given these two relations:

• Enrollment(student_id, course_id) with rows (S1, C1) and (S2, C2).
• Course(id, title) with rows (C1, Databases), (C2, Compilers), and (C3, Algebra).

In relational algebra the query is a composition of three operators — select, join, project:

π_title ( σ_student_id = 'S2' (Enrollment)  ⋈_{course_id = id}  Course )

Read it inside-out: σ keeps S2's enrollment row, the join ⋈_{course_id = id} pairs it with the matching Course row, and π keeps only the title column. The trace below follows each step.

A subtlety worth pausing on: the join is written ⋈_{course_id = id}, a theta join with an explicit condition, and not the bare natural join ⋈. Under the standard textbook convention, a bare ⋈ joins on attributes that share the same name. Our schema has Enrollment.course_id and Course.id — different names, no shared attribute — so σ_student_id='S2'(Enrollment) ⋈ Course would degenerate into a full Cartesian product. That product would pair S2's row with every course and project to {Databases, Compilers, Algebra}, which is not what we asked for. Writing the condition out (or, equivalently, renaming id to course_id before a natural join) is what pins the algebra to the same meaning as the SQL.

The equivalent SQL states the same three operations declaratively:

SELECT c.title
FROM   Enrollment e
JOIN   Course c ON e.course_id = c.id
WHERE  e.student_id = 'S2';

The WHERE clause is the selection, the ON e.course_id = c.id is exactly the join condition course_id = id, and SELECT c.title is the projection. Both forms return {Compilers} — they are genuinely the same query, expressed in two notations that the relational model proves equivalent.

The significance

Codd's 1970 paper, "A Relational Model of Data for Large Shared Data Banks," turned data management from a craft of hand-tuned access paths into a discipline with a mathematical foundation. The declarative query, the optimizer that exploits it, and the integrity constraints the engine can enforce on your behalf all flow from that one move. From 1970 to today (2026) the model is 56 years old, and it still anchors the databases most of the world runs on. The lessons that follow build directly on the pieces introduced here — relations and tuples, then the keys that make joins meaningful, and the integrity constraints that keep the data honest.

Source

Adapted and expanded from E. F. Codd, "A Relational Model of Data for Large Shared Data Banks," Communications of the ACM, 13(6):377–387, 1970; with relational-algebra and SQL conventions following Silberschatz, Korth & Sudarshan, Database System Concepts (7th ed.), McGraw-Hill, 2019.