Codd's 12 rules

Codd's 12 rules

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 jokingly referred to as "Codd's Twelve Commandments".

The relational DBMS model is based on the relational algebra devised by E.F.CODD.

The relational algebra by Codd is done through 12 rules popularly known as CODD's 12 Rules.

Some rules are controversial, specially rule three, due to the debate on three-valued logic.

The rules

Rule (0): 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.

Rule 1: The information rule:

All information in the database is to be represented in only one way, namely by values in column positions within rows of tables.

Rule 2: The guaranteed access rule:

Every pieceof data in the relational database,can be accessed by using a combination of a table name, a primary key value that identifies the row and a column that identifies the cell.The benefit of this is that user productivity is improved since there is no need to resort to using physical pointers addresses. Provides data independence.

Rule 3: Systematic treatment of null values:

The RDBMS handles that have unknown on inapplicable values in a predefined fashion.

RDBMS distinguishes between zeros,blanks and nulls in records and handles such values in a consistent manner that produces correct answers,comparisions and calculations.

Rule 4: Active online catalog based on the relational model:

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.

Rule 5: The comprehensive data sublanguage rule:

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).

Rule 6: The view updating rule:

Any view that is theoretically updatable, if changes can be made to the tables that effect the desired changes in the view. Data consistency is ensured since changes in the underlying tables are transmittedto the view they support. Logical data independence reduces maintenance cost.

Rule 7: High-level insert, update, and delete:

The system must support set-at-a-time insert, update, and delete operators. This means that data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. This rule states that insert, update, and delete operations should be supported for any retrievable set rather than just for a single row in a single table.

Rule 8: Physical data independence:

The execution of adhoc requests and application programs is not affected by changes in the physical data access and storage methods.Database administrators can make the changes to physical acccess and storage methods ,which improve performance but do not changes in the application programs or adhoc requests. This reduces maintenance costs.

Rule 9: Logical data independence:

Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence.

Logical changes in tables and view such as adding/deleting columns or changing field lenghts do not necessitate modifications in application programs or in the

format of adhoc requests.

Rule 10: Integrity independence:

Integrity constraints must be specified separately from application programs and stored in the catalog. It must be possible to change such constraints as and when appropriate without unnecessarily affecting existing applications.

The following two integrity constraints must be supported.

(a)Entity Integrity:

No component of primary key is allowed to have anull value.

(b)Referential integrity:

For each distinct non-null foreign key value in a relationaldatabase,

there must exist a matching primary key from the same range of data value.

Rule 11: Distribution independence:

The distribution of portions of the database to various locations should be invisible to users of the database. 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.

Application programs and adhoc requests are not affected by changes

in the distribution of the physical data.

Rule 12: The nonsubversion rule:

If the system provides a low-level (record-at-a-time) interface, then that interface cannot be used to subvert the system, for example, bypassing a relational security or integrity constraint.