Codd’s 12 Rules
CODD’s Rules
Dr Edgar F. Codd, after his extensive research on the
Relational Model of database systems, came up with
twelve rules of his own, which according to him, a
database must obey in order to be regarded as a true
relational database.
These rules can be applied on any database system
that manages stored data using only its relational
capabilities. This is a foundation rule, which acts as a
base for all the other rules.
Rule 1: The Information Rule
All information in a relational database
is represented explicitly at the logical
level in exactly one way – By values in a
table.
Rule 2: Guaranteed Access
Each and every datum (atomic value) in
a relational database is guaranteed to
logically accessible by resorting to a
combination of table name, primary key
value and column name.
Rule 3: Systematic Treatment
of Null Values
Null values (distinct from the empty
character string or string of blank
characters or any other number) are
supported in the fully relational DBMS
for representing missing information in
a systematic way, independent of data
type.
Rule 4: Dynamic Online
Catalog
The database description is represented
at the logical level in the same way as
ordinary data, so that authorized users
can apply the same relational language
to its interrogation as they apply to
regular data.
Rule 5: Data Sub language
A relational system may support several
languages and various modes of
terminal use (for example, fill-in-the-
blanks mode). However, there must be
at least one language whose
statements are expressible, per some
well-defined syntax, as character strings
and that is comprehensive in support of
all the following items:
Rule 5 Continued
Data Definition
View Definition
Data Manipulation
Integrity Constraints
Transaction boundaries
Rule 6: View Updating
All views that are theoretically
updatable are also updatable by the
system.
Rule 7: High-level Insert,
Update, Delete
The capability of handling a base
relation or a derived relation as a single
operand applies not only to the retrieval
of data but also to the insertion, update
and deletion of data.
Rule 8: Physical Data
Independence
Application programs and terminal
activities remain logically unimpaired
whenever any changes are made in
either storage representation or access
methods.
Rule 9: Logical Data
Independence
Application programs and terminal
activities remain logically unimpaired
when information-preserving changes of
any kind that theoretically permit
unimpairment are made to the base
tables.
Rule 10: Integrity
Independence
Integrity constraints specific to a
particular relational database must be
definable in the relational data
sublanguage and storable in the
catalog, not in the application
programs.
Rule 10 Continued
A minimum of the following two integrity
constraints must be supported:
Entity Integrity: No component of a primary
key is allowed to have a null value
Referential Integrity: For each distinct
nonnull foreign key value in a relational
database, there must exist a matching
primary key value from the same domain.
Rule 11: Distribution
Independence
A relational DBMS has distribution
independence
Rule 12: Nonsubversion Rule
If a relational system has a low-level
(single record at a time) language, that
low-level language cannot be used to
subvert or bypass the integrity rules or
constraints expressed in the higher level
relational language (multiple records at
a time)