The CODD rules

Rule (0): The system must qualify as relational, as a database, and as a management
system.
For a system to qualify as a relational database management system (RDBMS), that
system must use its relational facilities (eclusi!ely) to manage the database.
"## T$% R&#%S "R% D%R'(%D FR)M T$'S R&#%.
Rule 1: The information rule*
"ll information in a relational database (including table and column names) is
re+resented in only one ,ay, namely as a !alue in a table.
Rule 2: The guaranteed access rule*
"ll data must be accessible. This rule is essentially a restatement of the
fundamental requirement for +rimary -eys. 't says that e!ery indi!idual scalar
!alue in the database must be logically addressable by s+ecifying the name of the
containing table, the name of the containing column and the +rimary -ey !alue of
the containing ro,.
Rule 3: Systematic treatment of null values*
The DBMS must allo, each field to remain null (or em+ty). S+ecifically, it must
su++ort a re+resentation of .missing information and ina++licable information.
that is systematic, distinct from all regular !alues (for eam+le, .distinct from
/ero or any other number., in the case of numeric !alues), and inde+endent of
data ty+e. 't is also im+lied that such re+resentations must be mani+ulated by the
DBMS in a systematic ,ay.
Rule 4: Active online catalog based on the relational model*
The system must su++ort an online, inline, relational catalog that is accessible to
authori/ed users by means of their regular query language. That is, users must be
able to access the database0s structure (catalog) using the same query language
that they use to access the database0s data.
Rule 5: The comprehensive data sublanguage rule*
The system must su++ort at least one relational language that
1. $as a linear synta
2. 3an be used both interacti!ely and ,ithin a++lication +rograms,
4. Su++orts data definition o+erations (including !ie, definitions), data
mani+ulation o+erations (u+date as ,ell as retrie!al), security and integrity
constraints, and transaction management o+erations (begin, commit, and
rollbac-).
Rule 6: The view updating rule*
"ll !ie,s that are theoretically u+datable must be u+datable by the system.
Rule 7: High-level insert, update, and delete*
The system must su++ort set5at5a5time insert, update, and delete o+erators. This
means that data can be retrie!ed from a relational database in sets constructed of
data from multi+le ro,s and6or multi+le tables. This rule states that insert, u+date,
and delete o+erations should be su++orted for any retrie!able set rather than 7ust
for a single ro, in a single table.
Rule 8: Physical data independence*
3hanges to the +hysical le!el (ho, the data is stored, ,hether in arrays or lin-ed
lists etc.) must not require a change to an a++lication based on the structure.
Rule 9: Logical data independence*
3hanges to the logical le!el (tables, columns, ro,s, and so on) must not require a
change to an a++lication based on the structure. #ogical data inde+endence is
more difficult to achie!e than +hysical data inde+endence.
Rule 10: Integrity independence*
'ntegrity constraints must be s+ecified se+arately from a++lication +rograms and
stored in the catalog. 't must be +ossible to change such constraints as and ,hen
a++ro+riate ,ithout unnecessarily affecting eisting a++lications.
Rule 11: Distribution independence*
The distribution of +ortions of the database to !arious locations should be
in!isible to users of the database. %isting a++lications should continue to o+erate
successfully *
1. ,hen a distributed !ersion of the DBMS is first introduced8 and
2. ,hen eisting distributed data are redistributed around the system.
Rule 12: The nonsubversion rule*
'f the system +ro!ides a lo,5le!el (record5at5a5time) interface, then that interface
cannot be used to sub!ert the system, for eam+le, by+assing a relational security
or integrity constraint.