Monday, August 16, 2010


Codd's 12 Rules For The Relational Model
Dr. Edgar Frank Codd (August 23, 1923 – April 18, 2003) known as “Ted” and in his published articles known as E. F. Codd was a British computer scientist and the original developer of the relational data model back in 1970 while he was working for IBM as a researcher. He is also known as the father of the relational database.

In 1985 Dr. Codd published a list of 12 rules to define a relational database in Computerworld magazine that still stand today as a “Guide” to Relational Database Management Systems (RDBMS) such as Microsoft SQL.


Note: Dr. Codd actually defined 13 rules 0 – 12 but they are referred to as Codd's 12 Rules for the relational model.

Codd's 12 Rules For The Relational Model

0.) A relational DBMS must be able to manage databases entirely through its relational capabilities.

1.) Information rule-- All information in a relational database (including table and column names) is represented explicitly as values in tables.

2.) Guaranteed access--Every value in a relational database is guaranteed to be accessible by using a combination of the table name, primary key value, and column name.

3.) Systematic null value support--The DBMS provides systematic support for the treatment of null values (unknown or inapplicable data), distinct from default values, and independent of any domain.

4.) Active, online relational catalog--The description of the database and its contents is represented at the logical level as tables and can therefore be queried using the database language.

5.) Comprehensive data sublanguage--At least one supported language must have a well-defined syntax and be comprehensive. It must support data definition, manipulation, integrity rules, authorization, and transactions.

6.) View updating rule--All views that are theoretically updatable can be updated through the system.

7.) Set-level insertion, update, and deletion--The DBMS supports not only set-level retrievals but also set-level inserts, updates, and deletes.

8.) Physical data independence--Application programs and ad hoc programs are logically unaffected when physical access methods or storage structures are altered.

9.) Logical data independence--Application programs and ad hoc programs are logically unaffected, to the extent possible, when changes are made to the table structures.

10.) Integrity independence--The database language must be capable of defining integrity rules. They must be stored in the online catalog, and they cannot be bypassed.

11.) Distribution independence--Application programs and ad hoc requests are logically unaffected when data is first distributed or when it is redistributed.

12.) Nonsubversion--It must not be possible to bypass the integrity rules defined through the database language by using lower-level languages.