Table of Contents
Codd’s 12 Rules
Codd’s 12 Rules are a set of thirteen (yes, thirteen — numbered 0 through 12) principles defined by computer scientist Edgar F. Codd in 1985 to determine whether a database management system can truly be called “relational.” More than four decades later, these rules remain the theoretical backbone of every major relational database — PostgreSQL, MySQL, Oracle, SQL Server, and beyond.
If you’ve ever wondered what actually makes a database “relational” — instead of just a system that stores tables — this guide breaks down every rule, why it matters, and how it applies to the databases you use today.
Table of Contents
- Who Was E.F. Codd?
- Why Codd Created These Rules
- Rule Zero: The Foundation Rule
- Codd’s 12 Rules Explained
- Do Any Databases Fully Satisfy Codd’s Rules?
- Why Codd’s Rules Still Matter in 2026
- FAQ: Codd’s Rules
Who Was E.F. Codd?
Edgar Frank “Ted” Codd was a British computer scientist working at IBM who, in 1970, published the paper “A Relational Model of Data for Large Shared Data Banks.” This paper introduced the relational model, replacing the hierarchical and network database systems of the era with a model based on mathematical set theory and predicate logic.
By the early 1980s, vendors were slapping the word “relational” onto almost any database product, regardless of whether it followed Codd’s actual model. In response, Codd published “Is Your DBMS Really Relational?” in ComputerWorld in 1985, laying out twelve (plus one foundational) rules a system must follow to earn the “relational” label.
Why Codd Created These Rules
Codd’s rules weren’t academic gatekeeping for its own sake. They existed to solve a real problem: marketing departments were calling non-relational products “relational” because the term had become a buzzword. Codd wanted an objective, testable checklist — not a vague marketing claim — that separated genuine relational systems from imitators.
The rules address core capabilities every relational database should have:
- Structured, tabular data storage
- Data access exclusively through relational operations
- Independence between physical storage and logical structure
- Data integrity enforced by the system itself, not by applications
Rule Zero: The Foundation Rule
Before the twelve numbered rules, there’s Rule Zero, sometimes called the foundation rule:
A system must qualify as relational, as a database, and as a management system. For any system claiming to be a relational database management system (RDBMS), that system must be able to manage databases entirely through its relational capabilities.
In short: the entire system — not just parts of it — must operate on relational principles. You can’t be “relational” for some queries and something else for others.
Codd’s 12 Rules Explained
Rule 1: The Information Rule
All information in the database — including table data, column names, and metadata — must be represented explicitly as values stored in tables (rows and columns). There’s no hidden data structure outside the relational model.
In practice: A well-designed RDBMS stores its own schema (table names, column types, constraints) in system tables you can query with SQL, just like your regular data.
Rule 2: The Guaranteed Access Rule
Every single piece of data must be accessible by specifying the table name, primary key value, and column name — no exceptions.
In practice: If data exists, you should be able to retrieve it with a combination of table_name, a unique row identifier, and column_name. There’s no data trapped in a format that logic alone can’t reach.
Rule 3: Systematic Treatment of NULL Values
NULL values must be supported to represent missing or inapplicable data, and they must be handled consistently and separately from all “regular” values, such as zero or an empty string.
In practice: This is why NULL in SQL behaves so distinctly — it’s neither true nor false in boolean logic, and comparisons with NULL return “unknown,” not a hard true/false.
Rule 4: Dynamic Online Catalog Based on the Relational Model
The database’s own description (its schema/metadata) must be stored in tables, and it must be queryable using the same query language used for regular data.
In practice: In PostgreSQL, you can run SELECT * FROM information_schema.tables; — the catalog is itself relational data.
Rule 5: The Comprehensive Data Sublanguage Rule
The system must support at least one language with a well-defined syntax that can handle data definition, data manipulation, integrity constraints, transaction control, and view definitions — all expressible as strings.
In practice: SQL is the real-world answer to this rule, covering DDL (CREATE), DML (INSERT, UPDATE), constraints, and transactions in one unified language.
Rule 6: The View Updating Rule
All views that are theoretically updatable must be updatable by the system.
In practice: This is one of the hardest rules to satisfy fully. Simple views (based on one table) are usually updatable in modern databases; complex views involving joins or aggregations often aren’t — which is why this rule is frequently only partially met.
Rule 7: High-Level Insert, Update, and Delete
The system must support inserting, updating, and deleting data as single set-based operations — not just row-by-row.
In practice: Writing UPDATE employees SET salary = salary * 1.1 WHERE department = 'Sales'; updates every matching row in one statement, rather than looping through rows individually.
Rule 8: Physical Data Independence
Changes to physical storage — how data is stored on disk, indexing methods, file organization — must not require changes to applications or how users interact with the data.
In practice: A DBA can rebuild indexes, move tablespaces, or change storage engines without breaking application queries.
Rule 9: Logical Data Independence
Changes to the logical structure of tables (adding columns, splitting or merging tables) should be possible without forcing changes to applications, as long as the underlying data hasn’t been removed.
In practice: This is why views exist — they let you restructure underlying tables while keeping a stable “shape” for applications to query against.
Rule 10: Integrity Independence
Integrity constraints (like primary keys, foreign keys, and business rules) must be definable in the relational language and stored in the catalog — not hardcoded into application programs.
In practice: FOREIGN KEY, CHECK, NOT NULL, and UNIQUE constraints are defined directly in the database schema, so integrity holds regardless of which application touches the data.
Rule 11: Distribution Independence
The data manipulation language must work the same whether the database is centralized on one server or distributed across multiple physical locations.
In practice: Modern distributed SQL databases (like CockroachDB or distributed PostgreSQL setups) aim to let you write the same queries whether data lives on one node or is sharded across ten.
Rule 12: The Non-Subversion Rule
If the system offers a low-level (record-at-a-time) interface, that interface must not be able to bypass or subvert the integrity rules and constraints enforced by the higher-level relational language.
In practice: You shouldn’t be able to sneak around a FOREIGN KEY constraint just because you’re using a lower-level API instead of SQL.
Do Any Databases Fully Satisfy Codd’s Rules?
Not perfectly — and Codd himself acknowledged this. Most production databases, including Oracle, PostgreSQL, MySQL, and SQL Server, satisfy the spirit of nearly all twelve rules but fall short of literal, 100% compliance, particularly on:
- Rule 6 (updating all theoretically updatable views)
- Rule 11 (true distribution independence across heterogeneous systems)
This is normal. Codd’s rules function more as a north star for relational design than a pass/fail certification. No commercial RDBMS has ever claimed full, unqualified compliance with all thirteen rules.
Why Codd’s Rules Still Matter in 2026
Even in an era of NoSQL, distributed ledgers, and vector databases, Codd’s rules remain relevant because they define the guarantees a relational system gives you:
- Predictable data integrity enforced by the database itself, not scattered across application code
- A single, standardized query language (SQL) for structure, manipulation, and constraints
- Independence between how data is stored and how it’s accessed, letting systems scale and evolve without breaking applications
Understanding these rules also helps when evaluating newer database paradigms — many “NewSQL” and distributed relational systems are explicitly measured against how closely they honor Codd’s original principles, especially Rules 8, 9, and 11.
FAQ: Codd’s Rules
How many rules did Codd actually write? Thirteen — Rule Zero (the foundation rule) plus Rules 1 through 12. It’s commonly shortened to “Codd’s 12 Rules,” but Rule Zero is essential to the full definition.
Who created Codd’s rules and when? E.F. Codd published them in 1985 in the article “Is Your DBMS Really Relational?”, building on his original 1970 relational model paper.
Does SQL fully comply with Codd’s rules? SQL as a language satisfies most of the intent behind the rules, but strict academic critics note that SQL’s handling of NULLs, duplicate rows, and certain view limitations means it doesn’t perfectly match Codd’s original mathematical relational model.
Is MongoDB or another NoSQL database relational per Codd’s rules? No. Codd’s rules apply specifically to relational database management systems. Document, key-value, and graph databases follow different models entirely and aren’t evaluated against these rules.
Why is Rule 6 (the view updating rule) so hard to satisfy? Because not every view has a mathematically unambiguous way to map an update back to its underlying base tables — especially views involving joins, aggregations, or computed columns. Most databases support updating simple views but restrict or disallow updates on complex ones.