Scribd
Upload
78 views4 pages

Codd's Rule

E.F Codd invented the relational model for database management and relational databases. Codd proposed 12 rules known as Codd's rules to define what qualities a database management system requires to be considered relational. The rules cover topics like data storage, access, NULL values, data dictionaries, querying languages, updating views, and independence from applications and distribution.

Uploaded by

Palak Rathore
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
78 views4 pages

Codd's Rule

E.F Codd invented the relational model for database management and relational databases. Codd proposed 12 rules known as Codd's rules to define what qualities a database management system requires to be considered relational. The rules cover topics like data storage, access, NULL values, data dictionaries, querying languages, updating views, and independence from applications and distribution.

Uploaded by

Palak Rathore
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

E.

F Codd was a Computer Scientist who invented the Relational model for
Database management. Based on relational model, the Relational database was
created. Codd proposed 13 rules popularly known as Codd's 12 rules to test
DBMS's concept against his relational model. Codd's rule actualy define what
quality a DBMS requires in order to become a Relational Database Management
System(RDBMS).
Rule 1: Information Rule
The data stored in a database, may it be user data or metadata, must be a value of
some table cell. Everything in a database must be stored in a table format.

Rule 2: Guaranteed Access Rule


Every single data element (value) is guaranteed to be accessible logically with a
combination of table-name, primary-key (row value), and attribute-name (column
value). No other means, such as pointers, can be used to access data.

Rule 3: Systematic Treatment of NULL Values


The NULL values in a database must be given a systematic and uniform
treatment. This is a very important rule because a NULL can be interpreted as one
the following − data is missing, data is not known, or data is not applicable.

Rule 4: Active Online Catalog


The structure description of the entire database must be stored in an online
catalog, known as data dictionary, which can be accessed by authorized users.
Users can use the same query language to access the catalog which they use to
access the database itself.

Data dictionary: a set of information describing the contents,

format, and structure of a database and the relationship between its

elements, used to control access to and manipulation of the

database.
Rule 5: Comprehensive Data Sub-Language Rule
A database can only be accessed using a language having linear syntax that
supports data definition, data manipulation, and transaction management
operations. This language can be used directly or by means of some application. If
the database allows access to data without any help of this language, then it is
considered as a violation.

Rule 6: View Updating Rule


All the views of a database, which can theoretically be updated, must also be
updatable by the system.

Rule 7: High-Level Insert, Update, and Delete Rule


A database must support high-level insertion, updation, and deletion. 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


The data stored in a database must be independent of the applications that access
the database. Any change in the physical structure of a database must not have any
impact on how the data is being accessed by external applications.

Rule 9: Logical Data Independence


The logical data in a database must be independent of its user’s view
(application). Any change in logical data must not affect the applications using it.
For example, if two tables are merged or one is split into two different tables,
there should be no impact or change on the user application. This is one of the
most difficult rule to apply.
Rule 10: Integrity Independence
A database must be independent of the application that uses it. All its integrity
constraints can be independently modified without the need of any change in the
application. This rule makes a database independent of the front-end application
and its interface.

Rule 11: Distribution Independence


The end-user must not be able to see that the data is distributed over various
locations. Users should always get the impression that the data is located at one
site only. This rule has been regarded as the foundation of distributed database
systems.

Rule 12: Non-Subversion Rule


If a system has an interface that provides access to low-level records, then the
interface must not be able to subvert the system and bypass security and integrity
constraints.

You might also like