Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
In the late 1960s, Edgar F. Codd, an Oxford-educated mathematician working at IBM’s research lab in San Jose looked at the way data was being stored and thought “…this is far too messy” (probably). Back then, data lived in hierarchical and network databases, which worked, but only if you were willing to wrestle with rigid structures, cryptic access methods, and endless bespoke code.
It was a world where every new query must have felt like reinventing the wheel. Codd imagined something radical. A model where data could be described logically, queried in a consistent language and manipulated without caring about the messy physical storage underneath.
This vision became the relational model, the foundation for SQL and almost every modern database.
A system must manage its data entirely through relational capabilities. No cheating with non-relational workarounds.
Think of it as the “if you call yourself relational, be relational” rule.
Rule 1: Information Rule
All information is represented as values in tables. Rows and columns are the only way data should appear.
Rule 2: Guaranteed Access Rule
Every piece of data is accessible by table name, primary key, and column name. No hidden access paths, no black boxes.
Rule 3: Systematic Treatment of Nulls
Missing information should be handled consistently – with a defined representation (NULL), not just blank spaces or special codes.
Rule 4: Dynamic Online Catalog
The database’s own structure (schema, metadata) should be stored as data and queryable using the same language you use for business data.
Modern metadata management tools still chase this ideal.
Rule 5: Comprehensive Data Sublanguage Rule
There must be a single, well-defined language (hello again SQL) to define, query, and manipulate data, not a mix of APIs, scripts, and magic incantations.
Rule 6: View Updating Rule
You should be able to update views (derived tables) when it makes logical sense – not just look at them.
Rule 7: High-Level Insert, Update, Delete
No one should have to manually traverse data structures to change data. One statement should be able to affect many rows at once.
Rule 8: Physical Data Independence
Changing how data is stored physically (on disk, in memory, in the cloud) should not require rewriting applications.
Rule 9: Logical Data Independence
Changes to the logical structure (adding a column, splitting a table) should not break existing applications.
Rule 10: Integrity Independence
Constraints such as primary keys and foreign keys should be definable in the database, not buried in application code.
Rule 11: Distribution Independence
It shouldn’t matter whether your data is all in one place or spread across multiple locations; queries should still work the same way.
Rule 12: Non-Subversion Rule
If you can bypass the relational system with low-level operations, you must not be able to break its integrity rules.
Codd’s rules weren’t just a product spec — they were a philosophical stance: data should be self-describing, independent, and accessible through a consistent language. While no commercial database has ever fully met all 12 rules, they remain a north star for database design. Even in today’s world of NoSQL, graph databases, and data lakes, the principles behind these rules – abstraction, consistency, independence, underpin how we build and trust modern data systems.
Edgar Codd didn’t just invent a new way to store data. He gave us a universal language for talking to it. Without his 12 rules, there would be no SQL, no modern analytics, and no data-driven businesses as we know them.
You must be logged in to post a comment.