Codds Rule of DBMS
Codd’s Rule of DBMS
Database having certain constraints and tables, need not to be a
relational database system always. For perfect database management system,
there are certain rules for the database, popularly known as Codd’s 13 (0 to 12) rules. These rules
were proposed by Dr Edgar Frank Codd (EF
Codd) in 1985 to define a
perfect relational database system. For a relational database to be a perfect, it
has to follow its rules. But, no RDBMS can follow or obey all its rules. Oracle database only obeys 8.5 rules
out of 13.
A database management system that satisfies Codd’s rules is called a fully relational database management
system.
The Codd’s 13 rules (0 to 12) for the relational databases are as follows:
Rule 0: Foundation
Rule
This
rule defines that for a system to qualify as an RDBMS, it must be able to
manage the database entirely through the relational capabilities.
Rule 1: Information
Rule
This
rule defines that the data stored in the relational model is in the form of rows
and columns of tables.
Rule 2: Guaranteed
Access Rule
This
rule defines that every data should be logically accessible through the
combination of a table name, primary key, and name of the attribute or column.
Rule 3: Systematic
Treatment of NULL values
In a
relational database, NULL values represent the missed and inapplicable
information in a systematic way. A NULL value is a special value, which is
neither zero nor empty string. All the database systems support the NULL value
concept.
Rule 4: Dynamic
On-Line catalog based on the relational model
This rule defines that the
structure of the database must support online relational catalog that is
accessible to authorized users using its regular query language.
Rule 5: Comprehensive
Data sub-language Rule
This
rule states that the database system should be accessible by language support
for data definition, data manipulation, and transaction management operation
(begin, commit, rollback, etc.).
Rule 6: View Updating
Rule
This
rule states that all the views which are theoretically updated must be updated
by the system (i.e. practical).
Rule 7: High-level
Insertion, Updation and Deletion
This
rule states that the relational database model must support insert, delete, and
update operation on multiple rows.
Rule 8: Physical Data
Independence
This
rule states that the application program should remain unchanged whenever any
change occur either in access methods or storage representation.
Rule 9: Logical Data
Independence
This rule states
that any changes in the conceptual
or logical schema of a table should not enforce modification at application
programs or External schema.
Rule 10: Integrity Independence
This rule states that a relational database system should support different
constraints on data for data integrity. All the database system should support
primary key constraint and foreign key constraint.
Rule 11: Distributed
Independence
This
rule implies that the user need not to be aware of whether a database is
distributed over multiple locations or not. The user can access the data
without any ambiguity from the different server.
Rule 12:
Non-Subversion Rule
If
the system provides a low-level interface, that interface cannot be used to
subvert or not be able to bypass integrity rule to change data. This can be
achieved by some encryption techniques.