A relational DBMS must use its relational facilities exclusively to manage and interact with the database.

The rules:

These rules were defined by Codd in a paper published in 1985. They specify what a relational database must support in order to be relational. These rules have been considerably extended in reference [1].

1. Information rule

• Data are represented only one way: as values within columns within rows.
• Simple, consistent and versatile.
• The basic requirement of the relational model.

2. Guaranteed access rule

• Every value can be accessed by providing table name, column name and key.
• All data are uniquely identified and accessible via this identity.

3. Systematic treatment of null values

• Separate handling of missing and/or non applicable data.
• This is distinct to zero or empty strings
• Codd would further like several types of null to be handled.

4. Relational online catalog

• Catalog (data dictionary) can be queried by authorized users as part of the database.
• The catalog is part of the database.

5. Comprehensive data sublanguage

• Used interactively and embedded within programs
• Supports data definition, data manipulation, security, integrity constraints and transaction processing
• Today means: must support SQL.

6. View updating rule

• All theoretically possible view updates should be possible.
• Views are virtual tables. They appear to behave as conventional tables except that they are built dynamically when the query is run. This means that a view is always up to date. It is not always theoretically possible to update views. Codd himself, did not completely understand this. One problem exists when a view relates to part of a table not including a candidate key. This means that potential updates would violate the entity integrity rule.

7. High-level insert, update and delete

• Must support set-at-a-time updates.
• ie. Transactions
• eg: UPDATE mytable SET mycol = value WHERE condition;
  Many rows may be updated with this single statement.

8. Physical data independence

• Physical layer of the architecture is mapped onto the logical layer.
• Users and programs are not dependent on the physical structure of the database.
• (Physical layer implementation is dependent on the DBMS.)

9. Logical data independence

• Users and programs are independent of the logical structure of the database.
• i.e.: the logical structure of the data can evolve with minimal impact on the programs.

10. Integrity independence

• Integrity constraints are to be stored in the catalog not the programs.
• Alterations to integrity constraints should not affect application programs.
• This simplifies the programs.
• It is not always possible to do this.

11. Distribution independence

• Applications should still work in a distributed database (DDB).

12. Nonsubversion rule

• If there is a record-at-a-time interface (eg via 3GL), security and integrity of the database must not be violated.
• There should be no backdoor to bypass the security imposed by the DBMS.

Rule Zero for RDBMS:

Many new DBMS claim to be relational plus supporting extended features. eg. PostgreSQL is a RDBMS with extended Object Oriented features. Codd's rule zero specifies a criteria for RDBMS:

"For any system that is advertised as, or claimed to be, a relational database management system, that system must be able to manage databases entirely through its relational capabilities, no matter what additional capabilities the system may support." (Codd, 1990)

In Codd 1990, Codd extended the 12 rules to 18 to include rules on catalog, data types (domains), authorisation etc.