CS PAPERS DEEP-READ · PAPER 32
E. F. Codd · IBM San Jose Research · CACM 1970
In 1970, an IBM mathematician named Edgar F. Codd proposed the relational model. In one line: put all your data into plain, tidy tables—a row is a record, a column is a field. Nearly every database you touch today (MySQL, PostgreSQL, Oracle, and whatever sits behind your bank account and your online orders) is built on this idea. It looks utterly ordinary, yet it is the "Newton's laws" of the database world.
Before this paper, data wasn't laid out as tables—it was more like beads strung on threads: a "customer" record held a pointer (a physical address) to its first order, that order pointed to the next, and so on. To find "all of Alice's orders," a program had to crawl along those pointers, one hop at a time, like walking a maze.
The killer was this: that crawling route was hard-coded into the programs. The day an administrator reorganized the data or swapped indexes to speed things up, the storage layout changed—and every program that relied on the old route broke and had to be rewritten. Data and programs were welded together.
Codd said: stop welding data together with pointers; use "tables + shared values" instead. Flatten data into clean tables; two tables are linked not by pointers but by sharing a value—every customer has a "customer id," every order records which "customer id" it belongs to, and matching ids mean the same person's order. What relates to what lives entirely in the data's own values, with nothing to do with where it sits on disk or how it's ordered.
Because linking happens by matching values rather than following pointers, asking a question becomes "state what you want" instead of "teach it, step by step, how to get there." You just say "all rows in the orders table whose customer id equals Alice's," and the system gathers them for you—you need not know where the data lives, in what order, or whether there's an index.
And so the old curse—"change the storage, rewrite the programs"—is gone at the root: you never depended on what the storage looked like in the first place. Administrators can tune, add indexes, and move data around without touching your programs. Only now do data and programs finally get to live separate lives.
The entire database industry. SQL—the "state what you want" query language—plus Oracle, DB2, PostgreSQL, MySQL… all are direct descendants of this table model. Half a century on, it is still how the vast majority of the world's data is stored. Codd won the 1981 Turing Award for it.
One honest note: this approach was much slower than the old pointer method when it first appeared, and the industry argued for a decade over whether it was worth it—until query optimizers and hardware caught up and it became both elegant and fast.
Lay data out as tidy tables; link tables not by physical pointers but by shared values. Querying becomes "state what you want" rather than "teach it how to walk there," and data finally decouples from storage details—this is the foundation of every relational database and of SQL.
Want the diagrams for "linking by value," normalization, and relational operations, plus the harder details? → Switch to the deep read
Codd proposed representing all data uniformly as mathematical relations—tidy, row-and-column tables where every cell holds a single value—and linking tables not with physical pointers but with shared values (primary keys / foreign keys). This cleanly separates the data's logical structure from its physical storage (data independence), letting programs face "what the data is" rather than "how it's stored and found," and escaping the era's network/hierarchical trap where changing storage broke every program. It is the theoretical source of relational databases and SQL.
The author, Edgar F. "Ted" Codd, was a British mathematician and researcher at IBM's San Jose Research Laboratory. His paper, "A Relational Model of Data for Large Shared Data Banks," appeared in the June 1970 Communications of the ACM. It directly challenged a landscape dominated by Charles Bachman's network model (CODASYL; Bachman had just won the 1973 Turing Award for it) and IBM's own IMS hierarchical model. Downstream it drove two landmark prototypes—IBM's System R and Berkeley's Ingres—and through them SQL, Oracle, DB2, and PostgreSQL. Codd himself received the 1981 Turing Award for the model.
Around 1970, databases welded a datum's logical meaning to its physical layout on disk. In the network model, the link between "customer" and "order" was a literal pointer: the customer record held the address of its orders, and programs retrieved data by navigation—crawling from pointer to pointer, hop by hop.
Codd broke this coupling into three dependences and named each:
The consequence: tuning storage for performance (reordering, re-indexing, rewiring pointers) almost always forced a rewrite of a swath of application programs. Data and programs were deadlocked—the system was brittle and hard to evolve. What Codd wanted was for programs to depend only on the logical content of data, walling off whatever the physical layer did. That is data independence.
Codd's answer is a few interlocking ideas, with one sentence at the core: view data as mathematical "relations," replace pointers with values, and fully separate the logical from the physical.
In mathematics a relation is a set of tuples—each tuple picks one value from each of several domains. In plain terms: a relation is a table, a row is a tuple, a column is drawn from a domain. Codd argued that however messy data looks in the real world, it should all be represented in this "tidy rows and columns, one single value per cell" form.
Because it is fundamentally a set, several handy mathematical properties follow: no duplicate rows (a set has no repeats), and no order among rows (a set is unordered—so you should never depend on physical ordering). This one uniform shape is the bedrock for everything else.
This is the paper's sharpest cut. The link between two tables is no longer a physical pointer but a shared value. Each table has a primary key that uniquely identifies each row (say the "customer id" in the customer table); another table that wants to reference it simply stores the same value in one of its columns—that column is a foreign key (say the customer id recorded on each order). To find a relationship, find rows with equal values—rather than chase an address.
This cut severs access-path dependence: the relationship is part of the data, not part of the storage layout. No matter how the two tables are stored, ordered, or indexed, "equal values are related" always holds. Programs never need to know any physical route.
Real data is often nested: one customer "contains" several orders (a so-called repeating group). Such irregular structure can't be a relation directly. Codd's fix is normalization: decompose a structure with repeating groups into several flat tables where every cell holds a single value—customers in the customer table, orders in the order table, re-linked by the foreign key (customer id).
The payoff is twofold: a uniform structure (everything is a flat table, so operations have universal rules) and less update-prone redundancy—a customer's address is stored once and changed once, instead of being scattered across many orders where it could be missed and left inconsistent. This "split tables to kill redundancy" instinct is the origin of first normal form (1NF) and of the whole normalization theory (2NF, 3NF, BCNF).
Since all data are relations (sets), you can query and combine them with set operations, and the result of an operation is itself a relation (feedable into the next step). Codd sketched several operations that later grew into a full relational algebra; the everyday intuitions are:
The point isn't the operators but the paradigm shift they enable: you state "which rows, which columns, joined to whom," instead of writing "first use this index, then follow that pointer chain." Queries go from procedural to declarative—"how to find it efficiently" is left to the system. Codd thus envisioned a universal data sublanguage that could be embedded in an ordinary programming language, which is precisely the blueprint for SQL a few years later.
To be honest: this is a theoretical paper, with no experiments and no benchmark numbers. Its "results" are conceptual arguments—Codd showed that a broad class of real data can be represented losslessly as normalized relations; that the pointer-expressed relationships of the network model can be expressed equivalently with "values + relational operations"; and that doing so severs all three dependences—ordering, indexing, and access path—at once, achieving data independence.
Its real "validation" came from the decade-plus of engineering that followed: IBM's System R (which birthed SEQUEL / SQL and cost-based query optimization) and Berkeley's Ingres (the QUEL language) proved that the relational model was not merely elegant but could yield real systems that ran, and ran fast. Relational databases then dominated commercial data processing for decades, and Codd received the 1981 Turing Award for the theory.
It founded the entire relational database industry and established a far-reaching engineering principle: separate the logical model from the physical implementation, and make the interface face "what the data is." SQL became one of the most successful declarative languages ever; "you say what you want, the system decides how to compute it" gave rise to the whole discipline of query optimization; and tables, primary keys, foreign keys, joins, and normalization became every engineer's shared vocabulary.
Deeper still, it demonstrated the power of taming an engineering mess with one clean mathematical abstraction (relational algebra)—a "find the right abstraction first" instinct whose influence reaches well beyond databases. Half a century later, the vast majority of the world's structured data still lives in Codd-style tables.
1. One line: represent all data uniformly as relations (tidy tables, one value per cell), link tables by shared values rather than pointers, and separate the logical from the physical.
2. Pain: network/hierarchical models weld data to storage; programs carry ordering, indexing, and access-path dependences, so changing storage forces rewrites.
3. Mechanism I—relation as table: it's a set, so no duplicate rows and no fixed row order; never depend on physical ordering.
4. Mechanism II—values over pointers: a primary key uniquely identifies a row, a foreign key stores the same value to reference another table; equal values are related, and the link lives in the data, not the layout.
5. Mechanism III—normalization: decompose nested structures with repeating groups into flat tables, unifying shape and reducing error-prone redundancy (the 1NF seed).
6. Mechanism IV—relational operations (selection / projection / join) turn queries from "teach it how to walk" into "state what you want": declarative, and the germ of SQL and query optimization.
7. Results: a theory paper with no experiments; its correctness was validated by System R / Ingres, SQL, and decades of industrial dominance; Codd won the 1981 Turing Award.
8. Limits: early performance was doubted (the Codd–Bachman debate); flat tables suit nested/graph data poorly (the NoSQL backlash); SQL's duplicate rows and NULLs deviate from the pure model.