8,9,10,11,12,0TH Rule

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 1

8TH Rule : The Physical Data Independence 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.

9th Rule : The Logical data Independence Rule


This rule states that applications programs must be independent of changes made
to the base tables. This means, that, this rule allows multiple database designs.
Moreover, as per this rule, the database design is dynamic without the
application/tools using the database being affected.
Thus it allows a table to be split into multiple tables and yet the previous
mechanism of accessing the data should not be affected, which is impossible.
Therefore, this 9th rule is not followed by any of the RDBMS, till date.

10th Rule : Integrity Independence Rule


It is concerned with the Primary and the foreign Key.
According this rule any data related validation should be stored within the
relational database and no other external mechanism, such as program logic, are
required for implementing such validations.
This rule has two sub rules :
1. Integrity Rule 1 : Entity Integrity Rule (Sub Rule 1)
2. Integrity Rule 2 : Referential Integrity Rule (Sub Rule 2)

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.

11th Rule : Distribution Independence Rule


This rule states that a user / application / tools should be totally unaware whether
the database is centralized or distributed (exists in multiple geographic locations)

12th Rule : Non-Subversion Rule


According to this rule there should be no other way, than SQL, to modify the
information in an RDDBMS. This rule is very stringent and very few RDBMS, like
Sybase and Oracle, follows it. Most of the RDBMS does not follow this rule, like
MS-SQL Server.
It states that the RDBMS should not provide any other means, such GUI, for
accessing and modifying the data.

0th Rule – Zeroeth Rule : (overall rule)


Any truly RDBMS must be manageable entirely by itself and through its own
relational capabilities.

You might also like