Dr. Edgar. F. Codd’s 12 Rules in DBMS

Dr. E.F. Codd is an IBM Researcher who first developed the data model in 1970. In, 1985, he published a list of 12 rules that define an ideal relational database and has provided a guideline for the design of all database systems. Till today no commercial RDBMS follow all the 12 rules.

1) Information Rule: 

The information can be represented in one and only one way i.e. table format. This rule places importance on the fact that the information can be stored in rows & columns.

All data should be stored in table form only as it gives ease and flexibility.

2) Guaranteed Access: 

The access to table follows the sequence of table name, rows and then attribute. This states that at the intersection of each column and a row there should be one and only one value of data.

All data should be accessible without any confusion. Data must be logically accessible by table, primary key, and column.

3) Systematic Treatment of Null Values:  

One should be able to operate with Null values. The operation with Null values should be performed using single command. The treatment of Null values should be independent of datatype, which means that Null values must be uniformly treated as “missing information,” not as empty strings, blanks, or zeros.

Primary key does not contain Null values.

Most database implementation support the concept of a Not Null field constraints that prevents null values in specific column of the table.

4) Dynamic (Active) Online Catalogue: 

RDBMS should maintain data dictionary tables to keep track of current state of database. This table contains information about table definition, view, column definition and every other type of database objects. These objects are updated automatically when changes are made to database.

A database must provide access to its structure through same tools that are used to access the data (via SQL). This is usually accomplished by storing the definition of structure within specific system tables. Metadata (data about the database) must be stored in the database just as regular data is.

5) Comprehensive Data Sub Language Rule: 

The database must support at least one clearly define language that is able to define data, views, integrity constraints, authorisation, transactions, and data manipulation. 

All RDBMS use forms of standard SQL as their supportive comprehensive language.

6) View Updating Rule:

Data can be presented in different logical combinations called views. Each view should support the same full range of data manipulation that has direct access to the table available. It is difficult to update or delete views as some views are based on aggregating and virtual columns.

7) High Level Global Insert, Update & Delete: 

RDBMS must be capable of doing more than just retrieving the relational data. It should be able to do insert, update and delete data items with the use of single command for each operation. 

It should be able to perform these operations on single as well as multiple rows.

8) Physical Data Independence: 

The user is isolated (set apart) from the physical method of storing & retrieving information from the database. Changes can be made to underlying architecture (hardware, disk storage methods) without affecting how the user accesses it.

9) Logical Data Independence:  

The data should be independent of logic involved in programming. In case of database design is changed then the program should be independent of these changes.

Once programs are written, the effort should not be wasted as to changing the logic, depending of storage style.

This rule is difficult to satisfy.

10) Integrity Independence: 

The database language should support constraints on user input that maintain database integrity. The integrity constraints must be defined in SQL and storable in the data dictionary, not in application programs.

This rule is difficult to implement fully.

11) Distribution Independence Rule: 

The data manipulation language of the relational system should not care where or how the physical data is distributed and should not require alteration if the physical data is centralised or distributed.

A user should be totally unaware of whether or not database is distributed. (Whether parts of database exists in multiple locations). A variety of reasons make this rule difficult to implement.

12) Non Subversion Rule: 

In case, if RDBMS takes help of any low level language, it must not by pass any integrity rules or constraints of relational language. There should be no way to modify the database structure other than the multiple row database language. Thus any operation must be governed by the relational rules.