Codd's 12 rules
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.
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
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.
