Codd's 12 Rules: The Relational Database Litmus Test

WHY IT EXISTS: Before Edgar F. Codd, databases were often tightly coupled to their physical storage, making applications brittle. Codd proposed the relational model to separate the logical representation of data (tables, rows, columns) from its physical implementation (files, pointers), a concept called data independence. The 12 rules were created to formally define what a system must do to truly achieve this separation.

THE MENTAL MODEL: Think of Codd's rules as a constitution for a database. This constitution dictates that every interaction with the nation's data—querying, updating, or even changing the laws (the schema)—must happen through a single, well-defined public language (like SQL). It explicitly forbids secret back-channels or low-level access that could bypass the system's integrity and rules.

HOW IT WORKS: The set actually contains thirteen rules, numbered 0 to 12. They collectively require a database management system (DBMS) to manage everything through its relational capabilities. Key principles include: the Information Rule (all data is in tables), the Guaranteed Access Rule (every value is addressable via table, primary key, and column), a comprehensive data sublanguage (like SQL), and an active online catalog (the schema is also stored in queryable tables). The most important is arguably the Nonsubversion Rule.

WHEN TO USE IT: The rules are a theoretical benchmark, not a practical shopping list. Use them to understand the philosophy behind relational database design and to appreciate why features like data independence and queryable schemas exist. They are an academic tool for evaluating the purity of a system's design.

WHEN NOT TO USE IT: Do not use the rules as a strict vendor comparison tool. In the real world, performance, features, and cost often lead to pragmatic compromises that violate one or more rules. The industry has favored practicality over theoretical purity for decades.

ONE CANONICAL EXAMPLE: The Nonsubversion Rule (Rule 12) is the ultimate enforcement clause. It states that if the system has a low-level, record-at-a-time interface, that interface must not be able to bypass the integrity constraints (like NOT NULL or foreign keys) defined in the high-level relational language. You can't use a back door to corrupt the data.