Codd’s 12 Rules in DBMS


Dr. Edgar F. Codd, after his in-depth research on the Relational Model of database systems, came up with 13 rules popularly known as Codd’s 12 rules to test DBMS’s concept against his relational model, which according to him, a database must obey in order to be considered as a true relational database.

 EF Codd rules can be applied to any database system that manages stored data using only its relational capabilities. This is a fundamental rule, which serves as the basis for all other rules. These rules are sometimes jokingly called “Codd’s Twelve Commandments.”

Rule 0: The foundation rule

This rule states that for a system to qualify as an RDBMS, it must be able to manage databases entirely through its relational capabilities.

Rule 1: The information rule

All information stored in a database, whether it be user data or metadata, must be a value of a table cell. Everything in a database must be stored in a tabular format.

Rule 2: The guaranteed access rule

Each and every data element (atomic value) is guaranteed to be logically accessible with a combination of table-name, primary key (value of row), and attribute name (value of column). No other means, such as pointers, can be used to obtain data.

Rule 3: Systematic treatment of null values

The NULL values in a database must be handled consistently. This is a very important rule because a NULL can be interpreted as missing data, not applicable, or no value.

Rule 4: Active Online Catalog

The structural description of the entire database must be stored in an online database dictionary (catalog) accessible by authorized users. Users can use the same query language to access the catalog that they use to access the database itself.

Rule 5: Comprehensive Data Sub-Language Rule

A database is only accessible using a language with a linear syntax that supports data manipulation, data definition, authorization, and transaction management. This language can be used directly or by means of an application. If the database allows access to the data without any help from that language, this is considered a violation.

Rule 6: View Updating Rule

All views in a database, which theoretically can be updated, must also be updatable by the system.

Rule 7: High Level Insert, Update, and Delete Rule

The database must support insert, update, and delete operations at every relationship level. It should not be limited to a single line, that is, it should also support union, intersection, and minus operations to generate sets of data records.

Rule 8: Physical Data Independence

The data stored in a database should be independent of the applications that access the database, that is, any change in the physical structure of a database should not have any impact on how the data is accessible by external applications.

Rule 9: Logical Data Independence

The user view of the data should not be changed if the logical structure of the database is changed, for example, if a table is split into two different tables, there should be no impact or change on the application user.

Rule 10: Integrity Independence

A database must be independent of the application it is using. All of its integrity constraints can be changed independently without the need of modifying the application. This rule makes the database independent of its interface.

Rule 11: Distribution Independence

The user must not be able to see the data being distributed over the network. Users should always get the impression that the data is only on one site. This rule laid the foundation of distributed database systems.

Rule 12: Non-Subversion Rule

If low-level access to a system is allowed, then the system must not be able to subvert the system and bypass security and integrity constraints.

Leave a Comment

Your email address will not be published. Required fields are marked *