Professional Documents
Culture Documents
8,9,10,11,12,0TH Rule
8,9,10,11,12,0TH Rule
8,9,10,11,12,0TH Rule
User access to database, using any tool or application, must remain logically
consistent, whenever any changes to the storage representation or access methods
to the data are changed.
Sub Rule 1 : A/c to this rule, in every relation, in an RDBMS, there must be at-
least one attribute (or combination of attributes) which will uniquely identify each
tuple of that relation. Such attribute is referred as the Primary Key attribute.
Therefore, the primary key attribute cannot contain and should not allow, duplicate
entries for any two tuples. Also it cannot contain and should not allow NULL as its
value.
According to Codd, :-
If the attribute A of relation R is a prime attribute in R, then ‘A’ cannot accept null
and duplicate values.
Sub Rule 2 : It is concerned with foreign key attribute(s) of a relation that are
primary key of related (master) relation.
According to this rule there are following two constraints that must be followed in
case of such related relations :
In the master table, i.e., the relation containing the primary key
attribute, no such tuples can be deleted that has corresponding
matching tuples in the related relation, containing the foreign key.
Similarly, user cannot insert any such tuples in the related relation
for which there does not exists the matching primary key value in
the master relation
The above two together forms the base for the referential integrity between the
related relations. The relation containing the primary key is referred as the Master
or the Parent relation, whereas the relation containing the foreign key (matching
attribute) is referred as the Transaction or the Child relation.