Codd's 12 Rules for Relational Databases.

When E.F. Codd introduced the Relational Model in 1970, he also defined a set of 12 rules (numbered 0 to 12) that any Relational Database Management System (RDBMS) must satisfy to be considered truly relational. These rules serve as the foundation of relational databases, ensuring data integrity, independence, and consistency across systems.

Codd's Rules in DBMS.

Let’s explore each rule in simple words with examples.

Rule 0 – Foundation Rule.

"For a system to be considered relational, it must use its relational capabilities exclusively to manage the database."

Explanation: This is the baseline rule. It means the system must fully support all relational principles to qualify as a true RDBMS. Partial implementation (e.g., supporting SQL but not integrity rules) isn't enough.

Rule 1 – The Information Rule.

"All information in a relational database is represented explicitly at the logical level and in exactly one way – by values in tables."

Explanation: Every piece of data, including table names, column names, and actual data, should be stored in rows and columns. No hidden data, no pointers.

Example: A student’s name, age, and ID are stored in a Students table, not embedded in application logic.

Rule 2 – Guaranteed Access Rule.

"Each data item must be logically accessible by using a combination of table name, primary key, and column name."

Explanation: You should be able to retrieve any value in the database using a simple query, without needing to know the underlying storage structure.

Example: To get a student's name:

SQL Query: SELECT Name FROM Students WHERE StudentID = 101;

Rule 3 – Systematic Treatment of Null Values.

"Null values (distinct from zero or empty string) are supported for representing missing or inapplicable information."

Explanation: Nulls must be consistently treated and distinguishable from other values. They represent unknown or not applicable data.

Example: If a professor doesn't have an office assigned yet, the Office field should be NULL.

Rule 4 – Active Online Catalog (Data Dictionary)

"The database description is represented at the logical level in the same way as ordinary data, so authorized users can use the same relational language to access it."

Explanation: Metadata (like schema, tables, and columns) should be stored in tables and be queryable.

Example: This returns a list of tables in many RDBMS systems.

SQL Query: SELECT * FROM INFORMATION_SCHEMA.TABLES;

Rule 5 – Comprehensive Data Sub-language Rule.

"A relational system may support several languages and various modes of terminal use. But there must be one well-defined language that supports all of the following: data definition, data manipulation, data integrity constraints, and transaction control."

Explanation: There should be one powerful language (like SQL) that can handle everything: DDL, DML, constraints, and transactions.

Rule 6 – View Updating Rule

"All views that are theoretically updatable must be updatable through the system."

Explanation: If it’s logically possible to update a view, the system should allow it.

Example:

CREATE VIEW StudentNames AS SELECT Name FROM Students;
UPDATE StudentNames SET Name = 'Jane' WHERE Name = 'Janet';
Note: Not all views are updateable (e.g., ones with JOIN, GROUP BY, etc.).

Rule 7 – High-level Insert, Update, and Delete

"The system must support set-level inserts, updates, and deletes."

Explanation: You should be able to perform operations on multiple rows at once, not just one record at a time.
Example:
UPDATE Employees SET Bonus = 1000 WHERE Department = 'Sales';

Rule 8 – Physical Data Independence

"Changes to the physical storage of data should not require changes to applications that access that data."

Explanation: If you move your database from HDD to SSD or change the indexing method, your SQL queries should still work the same way.

Rule 9 – Logical Data Independence

"Changes to the logical structure (tables, views) should not affect how users interact with data."

Explanation: Applications should continue working even if the logical layout of data is modified.

Example: Splitting one large Employee table into CurrentEmployee and FormerEmployee shouldn’t break your application if views are maintained properly.

Rule 10 – Integrity Independence

"Integrity constraints must be stored in the catalog and not in application code."

Explanation: Rules like PRIMARY KEY, FOREIGN KEY, and CHECK constraints should be enforced by the database, not external applications.

Rule 11 – Distribution Independence

"The user should not be aware of whether the database is distributed."

Explanation: Whether your data is stored in one server or spread across many locations (distributed DB), it should be transparent to users.

Rule 12 – Non-subversion Rule

"If a system provides low-level access, it should not bypass the integrity rules or constraints."

Explanation: Even if there’s a “back door” or admin-level access, it must not allow data corruption or constraint violations.

Codd’s 12 Rules were visionary guidelines that laid the groundwork for modern relational databases. While few systems meet all of them perfectly, most modern RDBMSs strive to comply with them as much as possible to ensure scalability, security, and data integrity.

⚡ Please share your valuable feedback and suggestion in the comment section below or you can send us an email on our offical email id ✉ algolesson@gmail.com. You can also support our work by buying a cup of coffee ☕ for us.

Similar Posts

No comments:

Post a Comment


CLOSE ADS
CLOSE ADS