Saturday, April 29, 2023
Thursday, April 27, 2023
Tuesday, April 25, 2023
E. F. Codd’s 12 rules in DBMS
E. F. Codd’s 12 rules in DBMS
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).
Rule
0: Foundation Rule
Any
relational database management system that is propounded to be RDBMS or
advocated to be a RDBMS should be able to manage the stored data in its
entirety through its relational capabilities.
Rule
1: Rule of Information
The
information can be represented in one and only one way i.e., tables (also known
as Relations). This rule emphasizes the fact that the information can be stored
in rows and columns, whenever the data has to be stored or represented, it has
to be in tabular form only.
Rule
2: Rule of Guaranteed Access
Every
data entity which is atomic in nature should be accessed logically by using a
right combination of the name of table, primary key represented by a specific
row value and column name represented by attribute value.
Rule
3: Rule of Systematic Null Value Support
Null
values are completely supported in relational databases. They should be
uniformly considered as ‘missing information’. Null values are independent of
any data type. They should not be mistaken for blanks or zeroes or empty
strings. Null values can also be interpreted as ‘inapplicable data’ or ‘unknown
information.’.
Rule
4: Rule of Active and online relational Catalog
RDBMS
should maintain data dictionary tables to keep track of current state of the
database. These are special tables which keep track of the current state of the
database. These tables contain information about table definitions, views,
column definitions and other types of database object updated automatically
when changes are made to database.
Rule
5: Rule of Comprehensive Data Sub-language
RDBMS
should have comprehensive transactional data definition language, data
manipulation language & data control language. All the operations on
database should be supported by the data language which is a part of the
package.
Rule
6: Rule of Updating Views
One
can feel that any view can be updated, but in real practice, one cannot update
all the views as some views are based on aggregating and virtual columns.
Rule
7: Rule of Set level insertion, update and deletion
A
single operation should be sufficient to retrieve, insert, update and delete
the data.
Rule
8: Rule of Physical Data Independence
A
change in the storage strategy should not affect the performance of data.
Rule
9: Rule of Logical Data Independence
The
data should be independent of logic involved in programming, in case the
database design is changed then the programs should be independent of these
changes.
Rule
10: Rule of Integrity Independence
Integrity
constraints should be available and stored as metadata in data dictionary.
Rule
11: Rule of Distribution Independence
A
database should work properly regardless of its distribution across a network.
Even if a database is geographically distributed, with data stored in pieces,
the end user should get an impression that it is stored at the same place. This
lays the foundation of distributed database.
Rule
12: Rule of Non Subversion
Any
row should obey the security and integrity constraints imposed. No special
privileges are applicable.
Subscribe to:
Posts (Atom)
