E F Codd's Rule

Terminology of RDBMS:

Relational Model: Relational model represents data in the form of relations or tables.
Relational Schema: Schema represents the structure of a relation.

e.g.; Relational Schema of STUDENT relation can be represented as:
STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_COUNTRY, STUD_AGE)

Relational Instance: The set of values present in a relationship at a particular instance of time is known as relational instance as shown in Table 1 and Table 2.
Attribute: Each relation is defined in terms of some properties, each of which is known as attribute.

For Example, STUD_NO, STUD_NAME, etc. are attributes of relation STUDENT.

Domain of an attribute: The possible values an attribute can take in a relation is called its domain.

For Example, the domain of STUD_AGE can be from 18 to 40.

Tuple: Each row of a relation is known as tuple. e.g.; STUDENT relation given below has 4 tuples.
NULL values: Values of some attribute for some tuples may be unknown, missing or undefined which are represented by NULL.

Two NULL values in a relationship are considered different from each other.
Table 1 and Table 2 represent the relational model having two relations STUDENT and STUDENT_COURSE.

E F Codd's Rules

Dr. Edgar Frank Codd (August 19, 1923 – April 18, 2003) was a computer scientist while working for IBM.
He invented the relational model for database management.
Codd proposed thirteen rules (numbered zero to twelve) and said that if a Database Management System meets these rules, it can be called as a Relational Database Management System.
These rules are called as Codd's12 rules. Hardly any commercial product follows all.

Foundation Rule:

The system must qualify as relational, as a database, and as a management system.
For a system to qualify as a relational database management system (RDBMS), that system must use its relational facilities (exclusively) to manage the database.

Information Rule:

Data stored in Relational model must be the value of some cells of a table.
All information in the database is to be represented in one and only one way, namely by values in column positions within rows of tables.

Guaranteed Access Rule:

All data must be accessible. Every data element must be accessible by table name, its primary key, and name of the attribute whose value is to be determined.

Systematic Treatment of NULL values:

NULL value in the database must only correspond to missing, unknown or not applicable values.
The DBMS must allow each field to remain null (or empty). Specifically, it must support a representation of "missing information and inapplicable information" that is systematic, distinct from all regular values and independent of data type.

Active Online Catalog:

Structure of the database must be stored in an online catalog which can be queried by authorized users.
The system must support an online, inline, relational catalog that is accessible to authorized users by means of their regular query language.
That is, users must be able to access the database's structure (catalog) using the same query language that they use to access the database's data.

Comprehensive Data Sub-language Rule:

A database should be accessible by a language supported for definition, manipulation and transaction management operation.
The system must support at least one relational language that

1. Has a linear syntax
2. Can be used both interactively and within application programs,
3. Supports data definition operations (including view definitions), data manipulation operations (update as well as retrieval), security and integrity constraints, and transaction management operations (begin, commit, and rollback).

View Updating Rule:

Different views created for various purposes should be automatically updatable by the system.

High-level insert, update and delete rule:

Relational Model should support insert, delete, update, etc. operations at each level of relations.
Also, set operations like Union, Intersection, and minus should be supported.

Physical data independence:

Any modification in the physical location of a table should not enforce modification at the application level.

Logical data independence:

Any modification in the logical or conceptual schema of a table should not enforce modification at the application level. For example, merging of two tables into one should not affect application accessing it which is difficult to achieve.

Integrity Independence:

Integrity constraints modified at database level should not enforce modification at the application level.

Distribution Independence:

Distribution of data over various locations should not be visible to end-users.
Existing applications should continue to operate successfully :

1. when a distributed version of the DBMS is first introduced; and
2. when existing distributed data are redistributed around the system.

Non-Subversion Rule:

Low-level access to data should not be able to bypass integrity rules to change data.

More Details

Tags: DBMS