Codds Rule of DBMS

Codd’s Rule of DBMS

Database having certain constraints and tables, need not to be a relational database system always. For perfect database management system, there are certain rules for the database, popularly known as Codd’s 13 (0 to 12) rules. These rules were proposed by Dr Edgar Frank Codd (EF Codd) in 1985 to define a perfect relational database system. For a relational database to be a perfect, it has to follow its rules. But, no RDBMS can follow or obey all its rules. Oracle database only obeys 8.5 rules out of 13.
A database management system that satisfies Codd’s rules is called a fully relational database management system.

The Codd’s 13 rules (0 to 12) for the relational databases are as follows:

Rule 0: Foundation Rule
This rule defines that for a system to qualify as an RDBMS, it must be able to manage the database entirely through the relational capabilities.

Rule 1: Information Rule
This rule defines that the data stored in the relational model is in the form of rows and columns of tables.

Rule 2: Guaranteed Access Rule
This rule defines that every data should be logically accessible through the combination of a table name, primary key, and name of the attribute or column.

Rule 3: Systematic Treatment of NULL values
In a relational database, NULL values represent the missed and inapplicable information in a systematic way. A NULL value is a special value, which is neither zero nor empty string. All the database systems support the NULL value concept.

Rule 4: Dynamic On-Line catalog based on the relational model
This rule defines that the structure of the database must support online relational catalog that is accessible to authorized users using its regular query language.

Rule 5: Comprehensive Data sub-language Rule
This rule states that the database system should be accessible by language support for data definition, data manipulation, and transaction management operation (begin, commit, rollback, etc.).

Rule 6: View Updating Rule
This rule states that all the views which are theoretically updated must be updated by the system (i.e. practical).

Rule 7: High-level Insertion, Updation and Deletion
This rule states that the relational database model must support insert, delete, and update operation on multiple rows.

Rule 8: Physical Data Independence
This rule states that the application program should remain unchanged whenever any change occur either in access methods or storage representation.

Rule 9: Logical Data Independence
This rule states that any changes in the conceptual or logical schema of a table should not enforce modification at application programs or External schema.

Rule 10: Integrity Independence
This rule states that a relational database system should support different constraints on data for data integrity. All the database system should support primary key constraint and foreign key constraint.

Rule 11: Distributed Independence
This rule implies that the user need not to be aware of whether a database is distributed over multiple locations or not. The user can access the data without any ambiguity from the different server.

Rule 12: Non-Subversion Rule
If the system provides a low-level interface, that interface cannot be used to subvert or not be able to bypass integrity rule to change data. This can be achieved by some encryption techniques.