Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

Twelve rules of CODD

There are twelve rules formulated by E.F. Codd for RDBMS in 1970. If an RDBMS satisfies all these twelve rules, then only full benefits of the relational database can bring out results. 

Twelve rules of Codd

  1. Information Representation
  2. Guaranteed Access
  3. Systematic Treatment of Null Values 
  4. Database Description Rule
  5. Comprehensive Data Sub-Language
  6. View Updating
  7. High-Level Update, Insert, Delete 
  8. Physical Data Independence 
  9. Logical Data Independence
  10. The Distribution Rule
  11. Non-Subversion
  12. Integrity Rule

1. Information Representation rule

In the relational model, all information should be explicitly and logically represented by entering the data values in the form of tables. The information such as table, view and column names should all be in table form. Data stored in data dictionary should also be in tabular form.

2. Guaranteed Access rule

This rule refers to the fact that the table can be taken as a storage structure and at the inter section of each column and row, there will necessarily be only one specific value of data item (or null). Every value of data item must be logically addressable by using a combination of table-name, primary-key- value and column-name.

3. Systematic Treatment of Null Values rule

In relational database management system null values should be supported for the representation of missing and inapplicable information. The database management system must have a consistent method for representing null values. For example, null values for numeric data must be distinct from zero or any other numeric value and for character data, it must be different from a string of blanks.

4. Database Description rule

The description of a database is stored and maintained in the form of tables. This allows the users with appropriate authority to query information using similar ways and using the same languages. This implies that a data dictionary should be present within the RDBMS that is constructed of tables and/or views that can be examined using the structured query language (SQL). 3.5.5 Comprehensive Data Sub-Language.

5. Comprehensive Data Sub-Language

The RDBMS must be completely manageable through its own extension of SQL. The SQL should support Data Definition, Views, Data Manipulation, Integrity Constraints and Transaction Boundary.

6. View Updating rule:

Any view that can be defined using combination of base tables, and theoretically updatable, must also be capable of being updated by the RDBMS.

7. High-Level Updates Insert, Delete rule

An RDBMS must do more than just be able to retrieve relational data sets. It must also be possible to insert, update and delete data as a relational set.

8. Physical Data Independence rule

Changes made to physical storage, representation or access methods do not require changes to be made to the application programs used to manipulate data in tables.

9. Logical Data Independence rule

Application programs should not be affected by the changes made to the base tables. Changes made to tables should not require changes to be made to application programs.

10. The Distribution rule

An RDBMS package must have distribution independence. Thus, RDBMS package must make it possible for the database to be distributed across multiple computers even though they are having heterogeneous platforms both for hardware and operating system. This is one of the most attractive aspects of the RDBMS. Database systems built on the relational framework are well suited for today’s Client/Server database design.

11. Non-Subversion rule

If the RDBMS supports facilities allowing application programs to operate on tables a row at a time, then an application program using this type of database access is prevented from bypassing entity-integrity or referential- integrity constraints that may be defined for the database.

12. Integrity rule

Integrity constraints specific to a particular relational database must be definable in SQL or some other data sub-language. These integrity constraints must be storable in the catalogue and not in the application programs.