Codd's Rules for Relational Databases

The inventor of the relational database model, E. F. Codd [1985a, 1985b], listed twelve
rules to determine if a database is truly relational. Most commercial databases are no
longer truly relational because they have added capabilities such as objects that go
beyond the relational model. Nevertheless, understanding Codd's rules helps to better
understand the relational database model:
1. Information Specification: All information in a relational database is logically
specified in exactly one way as values in tables. Physical details such as the
storage layout on disk are not specified.
2. Guaranteed Access: Every value in a table is guaranteed to be logically
accessible by specifying the table name and the primary key value (and the name
of the primary key column).
3. Systematic Treatment Of Null Values: Null values which are distinct from
zero values such as the empty character string, a string of blank characters, a zero,
or any other number, must be supported in a fully relational database for
representing missing or inapplicable information in a manner that is data type
independent.
4. Catalog Based On The Relational Database Model: The data description, that
is, the catalog, should be represented like ordinary data, so that authorized users
can use the same relational language to query both the catalog and ordinary data.
5. Comprehensive Data Language: A relational database must support at least
one text-based language that provides capabilities for
6. data definition,
7. view definition,
8. data manipulation (interactively and via an application),
9. integrity constraints,
10. authorization, and
11. transaction boundaries (begin, commit, and rollback).
12. View Updates: All theoretically updateable views should be updateable. (This
is difficult to implement in practice.)
13. High-Level Insert, Update, And Delete Operations: The ability to specify a
table as a single operand should apply not only to data retrieval but also to the
insert, update, and delete operations.
14. Physical Data Independence: The logical view of the database should not be
affected by changes made to the storage representation or other physical details.
Such changes should not affect interactions with the database.
15. Logical Data Independence: Interaction with the database should not be
logically affected when theoretically permitted information-preserving changes
are made to tables.
 16. Integrity Independence: Integrity constraints must be definable in the
relational database language, such as SQL, and should be storable in the database.
17. Distribution Independence: Users should not have to know that a database is
distributed.
18. Non Subversion Rule: If a relational database system has a low-level (single
record at a time) language, then this language cannot be used to subvert or bypass
the integrity rules and constraints expressed in the higher level relational database
language (such as SQL that deals with multiple records at a time).
In practice, the "relational portions" of commercial relational database systems violate
one or more of these rules. Rules that tend to be violated are 6 (view updates), 9 (logical
data independence), 11 (distribution independence), and 12 (non subversion). With the
incorporation of objects and non-relational capabilities into relational databases, more
rules are now violated.