CODD’s Twelve Rules of Relational Database

Edgar F Codd was a Computer Scientist who invented the Relational model for Database management. He is also credited with creating the foundation for relational databases as well as relational database management systems.

Codd’s twelve rules define the characteristics required by a database management system to be considered relational i.e  a relational database management system.

Rule 0: Foundation rule

For any system to be qualified as a relational database management system, it should manage its data using its relational capability.

Rule 1: Information rule

All information (including metadata) is represented in tables using rows and columns. The rows and columns have to be strictly unordered.

Rule 2: Guaranteed access rule

All values in a database should be accessible by using a combination of table name, primary key and column name. (Ability to access the data directly using a pointed is invalid according to this rule).

Rule 3: Systematic treatment of Null values

NULL values are fully supported in a database for representing absence of data or invalid data in a systematic way. NULL values are independent of data types and any operation on them must return NULL.

Rule 4: Dynamic Online Catalog

The catalog is the complete description of a database. It is stored online and gives additional information on the database. The query language that is used on the database is also used on the catalog.

Rule 5: Powerful and Well-Structured Language

A relational database may support multiple languages. However there should be at least one language that provides all types of data access, data manipulation etc. One such language is SQL.

Rule 6:View Updation rule

All the views that are updatable theoretically should also be updatable by the system.

Rule 7: Quality Insertion, Update, Deletion

There should be insertion, deletion and updation possible in terms of a single operand. This facility must be available at all level of relations.

Rule 8: Physical Data Independence

The physical changes to the system, such as change of storage space, change of access methods etc. should not affect the application programs and other activities of the system.

Rule 9: Logical Data Independence

The user view of the relational database should remain consistent even if there are changes to the logical structure. This rule is quite difficult to satisfy.

Rule 10: Integrity Independence

Integrity constraints that are particular to a relational database should be defined in that database’s language and stored in the catalog. This rule means that relational DBMS is not reliant on front end.

Rule 11: Distribution Independence

Even if the data in the database is distributed across multiple locations, the end user should see the database as an uniform entity. Also, the database should work perfectly even if it is distributed across the network.

Rule 12: Nonsubversion Rule

If low level access is allowed for the relational database, it should not be able to subvert the integrity constraints and bypass security to change the data.