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';
Rule 7 – High-level Insert, Update, and Delete
UPDATE Employees SET Bonus = 1000 WHERE Department = 'Sales';
No comments:
Post a Comment