12 Codd’s Rules in Relational Database Management System
12 Codd’s Rules in
Relational Database Management System
Introduction
Codd's twelve rules are
a set of thirteen rules (numbered zero to twelve) proposed
by Edgar F. Codd, a pioneer of the relational model for databases, designed to define what is required from a database management system in order for it to be considered relational,
i.e., a relational database management system (RDBMS). They are sometimes referred to as
"Codd's Twelve Commandments".
History
Codd
originally set out the rules in 1970, and developed them further
in a 1974 conference paper. His aim was to prevent the vision of the original
relational database from being diluted, as database vendors scrambled in the
early 1980s to repackage existing products with a relational veneer. Rule 12 was particularly designed to counter such a positioning.
In 1999 a textbook stated
"Nowadays, most RDBMSs pass the test". However, in 2007 another textbook stated "no
database system complies with all twelve rules. He later expanded these
original 12 rules to an
outstanding 333 in 1990. Because the original 12 are an
ambitious lot, it's doubtful that any RDBMS will ever comply with 333 rules
Overview
v 1985 Dr. Edgar F. Codd the originator.
v There are 12 Rules of his own, which according to him, a database must obey
in order to be regarded as a true relational database.
v These rules can be applied on any database system that manages
stored data using only its relational capabilities.
v
 |
This is a foundation rule, which acts as a base for all the other rules.
Rule 0:
The Foundation Rule
v Rule 0: The Foundation Rule
v This is a foundation rule, which acts as a base for all the
other rules.
v For any system that is advertised as, or
claimed to be, a Relational Database Management System, the system must be able
to manage databases entirely through its relational capabilities.
Rule 1:
Information Rule
v The data stored in a database, may it be
user data or metadata, must be value of some table cell.
v Everything in a database must be stored
in a table format.
v A database contains various information,
and this information must be stored in each cell of a table in the form of rows
and columns.
v All information in a relational data
base is represented explicitly at the logical level.
Rule
2:
The Guaranteed Access Rule
v
Each and every datum(atomic value) in a relational database is
guaranteed to be logically accessible by resorting to a combination of table
name, primary key value and attribute name.
v
No other means, such as pointers, can be used to access data.
Rule
3:
Systematic Treatment of Null Values
v
This rule defines the systematic
v
records.
v
The NULL values in a database must be given a systematic and uniform
treatment.
v
The is a very important rule because a NULL can be interpreted as one of
the following data is missing, data is not known, or data is not applicable.
v
Null values (distinct from the empty character string or a string of
blank characters and distinct from zero or any other number) are supported in
fully relational DBMS for representing missing information and inapplicable
information in a systematic way, independent of data type.
Rule
4:
Dynamic Online Catalog
v
It represents the entire logical structure of the descriptive database
that must be stored online and is known as a database dictionary.
v
It authorizes users to access the database and implement a similar query
language to access the database.
v
The data base 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 the regular data.
Rule
5:
Comprehensive Data Sub Language Rule
v
A relational system may support several languages and various modes of
terminal use (for example, the 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 supporting all of the
following items
Ø Data definition.
Ø View definition.
Ø Data manipulation (interactive and by
program).
Ø Integrity constraints.
Ø Authorization.
Ø Transaction boundaries (begin, commit
and rollback).
v
If the database allows access to the data without any language, it is
considered a violation of the database.
Rule
6:
View Updating Rule
All views table can be theoretically
updated and must be practically updated by the database systems.
Rule
7:
Relational Level Operation Rule
v
A database system should follow high-level relational operations.
v
It also supports union, intersection and minus operation in the database
system.
v
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.
v
This must not be limited to a single row, that is, it must also support
union, intersection and minus operations to yield sets of data records.
Rule
8:
Physical Data Independence Rule
v
All stored data in a database or an application must be physically
independent to access the database.
v
Each data should not depend on other data or an application.
v
If data is updated or the physical structure of the database is changed,
it will not show any effect on external applications that are accessing the
data from the database.
v
Application programs and terminal activities remain logically unimpaired
whenever any changes are made in either storage representations or access
methods.
Rule
9:
Logical Data Independence Rule
v
It is similar to physical data independence. It means, if any changes
occurred to the logical level (table structures), it should not affect the
user's view (application).
v
Application programs and terminal activities remain logically unimpaired
when information-preserving changes of any kind that theoretically permit un
impairment are made to the base tables.
v
Any change in logical data must not affect the applications using it.
Rule 10: Integrity
Independence
v
A database must be independent of the application that uses it.
v
All its integrity constraints can be independently modified without the
need of any change in the application.
v
This rule makes a database independent of the front-end application and
its interface.
v
A database must maintain integrity independence when inserting data into
table's cells using the SQL query language.
v
Integrity constraints specific to a particular relational data base must
be definable in the relational data sublanguage and storable in the catalog,
not in the application programs.
Rule11:
Distribution Independence Rule
v
The distribution independence rule represents a database that must work
properly, even if it is stored in different locations and used by different
end-users.
v
Suppose a user accesses the database through an application; in that
case, they should not be aware that another user uses particular data, and the
data they always get is only located on one site.
v
The end users can access the database, and these access data should be
independent for every user to perform the SQL queries.
v
The end-user must not be able to see that the data is distributed over
various locations.
Rule 12: Non Subversion Rule
v
The non-submersion rule defines RDBMS as a SQL language to store and
manipulate the data in the database.
v
If a system has a low-level or separate language other than SQL to
access the database system, it should not subvert or bypass integrity to
transform data.
v
If a relational system has a low-level (single-record-at-a-time)
language, that low level cannot be used to subvert or bypass the integrity
rules and constraints expressed in the higher level relational language
(multiple-records-at-a-time).
Conclusion
These are the 12 Codd’s Rules of Dr. Edgar F. Codd (E.F. Codd) in the concept of RDBMS.There is an unspoken rule in the jargon of Database Management Systems. As the databases that implement all the E.F.Codd’s rules are scare, the unspoken rule has been gaining traction.
Reference
https://en.wikipedia.org/wiki/Codd%27s_12_rules
https://www.tutorialspoint.com/dbms/dbms_codds_rules.htm
https://www.tutorialspoint.com/e-f-codd-s-12-rules-for-rdbms
https://www.javatpoint.com/12-codds-rules
Comments
Post a Comment