Edger F Codd's Rules

E.F. Codd’s 12 Rules of Relational Databases – Explained Simply

By Laxmi Parmanandani | BCA, Semester 3

If you've ever used apps that store data like contacts, shopping lists, or bookings, chances are they use something called a relational database. But how do we know if a database is truly "relational"?

That’s where E.F. Codd’s 12 Rules come in. These rules help us check if a database system follows the right principles.

Let’s understand who E.F. Codd was and what his rules mean in simple words.

Who Was E.F. Codd?

E.F. Codd was a computer scientist who worked at IBM. He came up with the idea of relational databases—a way to store data in tables with rows and columns.

He created 12 important rules (plus Rule 0) that every Relational Database Management System (RDBMS) should follow.

Rule 0: The Basic Rule

A system is a relational database only if it follows all 12 rules.

So if a system doesn’t follow these rules, it's not a real RDBMS.

 Rule 1: Information Rule

All the data in a relational database must be stored in tables, and only in tables.

For example, if we have a list of customers, all their details should be inside a table.

 Rule 2: Guaranteed Access Rule

You should be able to get any piece of data using the table name, column name, and a unique ID (primary key).

For example, to get a customer’s phone number, we use the customer ID and column name.

Rule 3: Null Values

If some data is missing or unknown, it should be clearly marked as NULL.

For example, if a customer didn’t give their middle name, that space should show NULL.

Rule 4: Online Catalog

Information about the database (called metadata) should also be stored in tables and be easy to search.

Like, we should be able to ask the system: “What tables are in the database?”

 Rule 5: One Language for Everything

The database should support one complete language to do everything—like creating tables, updating data, and running transactions.

That language is usually SQL.

 Rule 6: View Updates

If we can see data through a view (like a filtered or joined table), we should also be able to update it.

For example, if a view shows customers and their orders, we should be able to edit customer info from there.

 Rule 7: Set-Level Operations

We should be able to insert, update, or delete multiple records at once, not just one at a time.

Like updating all customers in Mumbai in one command.

 Rule 8: Access Without Worrying About Storage

Users should be able to get data without knowing how or where it is stored physically.

For example, whether the data is on one server or another shouldn’t matter to the user.

Rule 9: Logical Data Independence

If we change the structure of a table (like adding a column), existing programs should still work.

This makes the system more flexible.

 Rule 10: Physical Data Independence

If we change where or how data is stored, it shouldn’t affect the structure or the programs.

For example, moving the database to a new computer should not break anything.

 Rule 11: Integrity Rules

Rules like "a customer ID must be unique" should be defined inside the database, not just in the application.

This keeps the data clean and reliable.

 Rule 12: No Cheating with Low-Level Access

If the system allows direct access to data (like a shortcut), it must still follow all rules and not break data safety.

No backdoor tricks allowed!