DBMS Codds Rules

DBMS Codd's 12 Rules

After his extensive research into the Relational Model of Database Systems, Dr. Edgar F. Codd came up with twelve rules of his own that, according to him, must be followed by a database in order to be called a true relational database.

These rules can be applied to any database system that only uses its relational features to handle stored data. This is a rule of foundation that acts as a basis for all the other rules.

Rule 1: Information Rule

The data stored in a database must be the value of a table cell, whether it is user data or metadata. It is important to store everything in a database in a table format.

Rule 2: Guaranteed Access Rule

A combination of table-name, primary-key (row value), and attribute-name (column value) is guaranteed to make every single data element (value) logically accessible. For accessing data, no other means can be used, such as pointers.

Rule 3: Systematic Treatment of NULL Values

Systematic and uniform treatment must be provided for the NULL values in the database. This is a very important rule since it is possible to interpret a NULL as one of the following: data is missing, data is not known or data is not applicable.

Rule 4: Active Online Catalog

The description of the structure of the whole database must be stored in an online catalogue, known as a data dictionary, available by authorized users. The same query language can be used by users to access the database that they use to access the database itself.

Rule 5: Comprehensive Data Sub-Language Rule

Only a language with linear syntax that supports data definition, data manipulation, and transaction processing operations can be used to access a database. It is possible to use this language directly or through any application. If, without any help from this language, the database requires access to data, then it is considered a violation.

Rule 6: View Updating Rule

All database views, which can theoretically be updated, must be updated by the system as well.

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

High-level insertion, updating, and deletion must be supported by a database. This must not be limited to a single row, which means that union, intersection and minus operations must also be supported in order to generate data record sets.

Rule 8: Physical Data Independence

The data contained in the database must be independent of the database-accessing applications. Any change in the physical structure of a database does not impact how external applications access the data.

Rule 9: Logical Data Independence

Logical data in a database must be independent of the view (application) of its user. The applications that use it must not be affected by any change in logical data. For instance , if two tables are merged or one is split into two separate tables, there should be no user application impact or change. This is one of the hardest laws to apply.

Rule 10: Integrity Independence

A database must be independent from the software that uses it. Without the need for some change in the application, all of its integrity constraints can be changed independently. A database is made independent of the front-end application and its interface by this rule.

Rule 11: Distribution Independence

The end-user must not be able to see that the information is distributed over different locations. Users should always get the impression that only one site is located with the data. The foundation of distributed database systems has been known to be this rule.

Rule 12: Non-Subversion Rule

If a system has an interface that provides access to records at a low level, the interface must not be able to subvert the system and bypass the limitations of security and integrity.