Edgar F. Codd was an IBM mathematician and researcher who, in 1970, published the paper that invented the relational model this entire course is built on. His core insight was almost radically simple: represent all data as plain tables, and let people ask direct questions about it, without ever needing to know how it's physically stored.
Why This Matters
It's worth knowing this isn't a story about a big company deciding on a standard — the relational model came from one researcher's mathematical argument about how data should be organized, published against the grain of how every major database product at the time actually worked. That context matters because it explains why the model is unusually clean and consistent: it was designed from a clear principle, not accumulated as a series of practical patches.
Real World Story
In 1970, Codd worked at IBM — a company that, at the time, sold database software built on the hierarchical model the last chapter described. He published a paper arguing that the entire industry's approach was the wrong one, and proposed replacing it with tables and set-based operations instead of pointer-following. IBM didn't immediately build products around his idea. It took years, an internal research project, and eventually a different company shipping a commercial product before the relational model actually reached the market Codd had originally written for.
Core Concept
Codd's central argument was that the physical way data is stored should be completely separate from how someone asks questions about it. Before his paper, those two things were tangled together — a program had to know the exact storage layout to navigate it. Codd proposed representing everything as Relations (what this course calls tables): a fixed set of columns, with any number of rows, where relationships between tables are expressed using ordinary shared values rather than physical pointers. This separation — meaning independent of storage — is the single idea underneath almost everything the rest of this course teaches.
Deep Dive
- Codd's 1970 paper, "A Relational Model of Data for Large Shared Data Banks", was published in a computer science journal, not shipped as a product. It was a mathematical argument first, built on set theory, and a practical proposal second.
- Years later, as relational databases started appearing on the market but often only partially following his ideas, Codd published a further set of rules — informally known as Codd's Rules — describing what a system would need to do to be considered genuinely, fully relational, rather than relational in name only. Many products that called themselves "relational" in the years after his paper didn't actually satisfy all of them.
- The gap between Codd's original, fairly strict definition and how the term "relational database" gets used casually today is still worth knowing about: in practice, the industry settled on "follows the core relational ideas closely enough to be useful," not "satisfies every one of Codd's rules to the letter."
Visual Diagram
FROM ONE PAPER TO AN INDUSTRY
1970
Codd's paper proposes the relational model
System R
IBM's research prototype, and SQL's origin
Commercial RDBMS products
Oracle and others bring it to market
Codd's Rules
a stricter definition of "truly relational"
Production Perspective
Even now, when you design a schema by thinking in terms of tables and relationships instead of pointers, you're directly using Codd's original separation between logical structure and physical storage. Every modern RDBMS still promises exactly what his paper promised first: you describe what data means and how it relates, and the database — not you — decides how to physically store and retrieve it efficiently.
Common Mistakes
Assuming every product that calls itself a "relational database" fully satisfies Codd's original, strict definition.
Why: As this chapter describes, many products called relational only follow the core ideas closely, not every one of Codd's formal rules — the popular meaning of the term has always been looser than his original definition.
Fix: Judge a database by what it actually guarantees and supports, not by whether it uses the word "relational" in its marketing.
Treating the relational model as something that arrived polished and complete.
Why: It took years of research and real commercial products after Codd's paper before the relational model became the practical, standardized thing you're learning today.
Fix: Separate the core idea (Codd's contribution) from the practical tooling built around it over the following decades — SQL, specific products, standards.
Interview Questions
Who proposed the relational model, and in what year?
Edgar F. Codd, an IBM researcher, proposed it in a 1970 paper.
What was Codd's central argument about how data should be organized?
That the physical storage of data should be completely separate from how people ask questions about it — data should be represented as simple tables (relations), with relationships expressed through shared values rather than physical pointers.
Why might it matter, in a real engineering discussion, that many "relational" databases don't fully satisfy Codd's original rules?
Because it's a reminder to evaluate a database by its actual, specific guarantees and behavior rather than by category labels — two products both calling themselves "relational" can still differ meaningfully in how strictly they enforce the ideas the term originally described.
Best Practices
Do
✓Know that "relational" originally referred to a specific, mathematically-argued proposal, not just a general style of database.
✓Separate a database's core model (the ideas) from the specific tooling and products built on top of it over time.
✓Judge any database's claims by its actual behavior, not by which category label it uses.
Don't
✗Don't assume "relational" is a strictly enforced, uniform standard across every product that uses the word.
✗Don't treat the history of an idea as separate from understanding it — Codd's original motivation is still the cleanest explanation for why the model works the way it does.
✗Don't assume foundational ideas in tech arrive complete — most, including this one, took years of real-world refinement after the original proposal.
Chapter Summary
Edgar F. Codd's 1970 paper proposed something that sounds simple today but wasn't at the time: separate how data is physically stored from how people ask questions about it, and represent everything as plain tables connected by shared values instead of pointers. That single idea — refined over the following decades into real products and standards — is the foundation for every remaining chapter in this course.