Summary of E. F. Codd’s 12 rules for relational databases

Codd's 12 rules are summarized and in some cases paraphrased here. I've also added some notes and interpretations based on current commercial implementations. Codd's ideas are good ones; any inconsistencies or errors introduced by my summarization of them are entirely my fault! -Jim Janossy, 1/28/2006

1. All data should be presented to the user in table form.

2. All data should be accessible without ambiguity. This means each data item can be uniquely identified using the table name, primary key, and column name.

3. A column should be allowed to remain empty. "Empty" means containing absolutely nothing, in other words, a null value, which is distinct from a spaces or a number with a value of zero.

4. The DBMS must provide access to its structure through the same tools that are used to access the data. This is accomplished by storing the structure definition within tables, the same as data is stored.

5. The DBMS must support a clearly defined language that includes functionality for data definition, data manipulation, data integrity, and database transaction control. Relational databases use forms of standard SQL as their supported comprehensive language.

6. Data can be presented to the user in different logical combinations called views. Each view should support the same full range of data manipulation that direct-access to a table has available. (This is only partially fulfilled in current implementations since update and delete access through logical views conflicts with the common use of logical views to provide read-only access for query and reporting. There is no universally agreement that it is a good idea in any case.)

7. Data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. This rule states that insert, update, and delete operations should be supported for any retrievable set rather than just for a single row in a single table.

8. The user is isolated from the physical method of storing and retrieving information from the database. Changes can be made to the underlying hardware and storage arrangements without affecting how the user accesses it.

9. How a user views data should not change when the logical structure (tables structure) of the database changes. This is hard to implement practically, but database implementation do make some types of changes “transparent” to data users. For example, adding columns to a table does not affect existing uses of columns already present.

10. Constraints on user input must be provided to maintain database integrity. Database implementations at least must insure that no part of a primary key is missing (null) and that if a foreign key is defined in one table, the value in it must exist as a primary key in another table.

11. A user should be totally unaware of whether or not the database is housed on one computer or distributed across several computers. This is actually a subcategory of rule 8. Implementation of this is inconsistent between commercial DBMS’s but is not a major concern in many applications.

12. Users should be no way to modify the database structure other than through the multiple row database language (SQL). In actual commercial implementations database tables are still accessible to direct manipulation by systems personnel in many implementations, but most end-users are denied access to this type of capability.