Codd's Rule in DBMS

Codd’s rule in DBMS also known as Codd's 12 rules/commandments is a set of thirteen rules (numbered 0 to 12) that define a database to be a correct Relational Database Management System (RDBMS). If a database follows Codd's 12 rules, it is called a True relational database management system.

These rules were originally set out in 1970 by Edgar F. Codd and were developed further by him in 1985.

What is the Use of Codd’s Rule in DBMS?

Codd's 12 rules are used to determine whether a relational database management system is a true relational database management system or not.

Codd's 12 rules

Rule 0: The Foundation Rule

For a system to be qualified as a relational database management system, it must be able to manage databases entirely through its relational capabilities.

Rule 1: The Information Rule

The information in a relational database must be stored in columns or rows of a table, i.e., a cell.

Rule 2: The Guaranteed Access Rule

Each and every datum in a relational database must be logically accessible using the combination of the table name, primary key value, and column name.

Rule 3: Systematic Treatment Of NULL Values

NULL values are fully supported in a relational database and represent missing information or inapplicable information in a systematic way, independent of the data type. NULL values are different from empty strings, blank spaces, and $0$.

Rule 4: Active/Dynamic Online Catalog Based On The Relational Model

Database Description (Catalog) of a complete database must be stored online. The rules of the rest of the database must also apply to the Catalog. The query language used to query the database should be used for the catalog also.

Rule 5: The Comprehensive Data Sublanguage Rule

Relational systems can support multiple languages and different modes of using terminals, such as fill-in-the-blanks mode. However, there must be at least one language whose statements are expressible according to a well-defined syntax.

Rule 6: The View Updating Rule

Theoretically, updatable views are also practically updatable by the database system.

Rule 7: High-Level Insert, Update & Delete Rule

The database system must follow high-level relational operations such as insertion, updation, and deletion at each level or row by row. It also supports the union, intersection, and subtraction operations in database systems.

Rule 8: Physical Data Independence

The working of a database system should be independent of the physical storage of its data. If a file is modified (renamed or moved to another location), it should not interfere with the working of the system.

Rule 9: Logical Data Independence

If there is a change in the logical structure (table structure) of the database, the user view of the data must not change.
Say a table is partitioned into two tables, the new view should give the result as the join of the two tables.

Rule 10: Integrity Independence

Integrity constraints specific to a particular relational database must be defined in the relational data sub-language and stored in the catalog and not in the application.

Rule 11: Distribution Independence

A database should work properly regardless of its distribution across a network. The end-user should not be able to see that the data is distributed over many locations, they should always get the impression that the data is located at a single site only.

Rule 12: The Non-subversion Rule

If a relational system allows low-level access, that low cannot be used to subvert or bypass the integrity rules to modify the data. This can be achieved with some sort of looking or encryption.

Read More:

• Views in DBMS.
• Data Independence in DBMS.