2.

sds

2.7 CODD RulesDBMS

Dr. Edgar F. CODD proposed a set of rules that are necessary for a system to

qualify as a Relational Database Management System. The CODD’s rules are as

follows:

The Codd’s rules can be applied to any DB system that merely has relational capabilities for

managing stored data. This is a fundamental rule that serves as the foundation for all other rules.

Table of Contents

The Foundation Rule

 Rule 1: The Information Rule

 Rule 2: The Guaranteed Access Rule

 Rule 3: The Systematic Treatment of Null Values

 Rule 4: The Dynamic/Active Online Catalog on the basis of the

Relational Model

 Rule 5: The Comprehensive Data SubLanguage Rule

 Rule 6: The View Updating Rule

 Rule 7: The Relational Level Operation (or High-Level Insert,

Delete, and Update) Rule

 Rule 8: The Physical Data Independence Rule

 Rule 9: The Logical Data Independence Rule

 Rule 10: The Integrity Independence Rule

 Rule 11: The Distribution Independence Rule

  Rule 12: The Non-Subversion Rule

What are the Codd’s Rules in DBMS?

Constraints can’t be referred to as a system of relational DBs because every DB has tables. A DB

that solely contains a relational data model cannot be called a Relational DB Management System

or RDBMS. Some rules determine if a DB is the correct RDBMS. Dr Edgar F. Codd, who has

extensive knowledge on the DB system’s Relational Model, proposed these principles in 1985.

Codd presents his 13 criteria for a DB to evaluate the concept of a DB Management System (DBMS)

against the relational model. A DB that follows the rule is referred to as a real relational DB

management system (RDBMS). Codd’s rules are a set of rules that are widely used in relational

DBs.
Rule 0: The Foundation Rule

The DB must be structured in a relational manner so that the system’s relational capabilities can

manage the DB.

Rule 1: The Information Rule

A DB comprises a variety of data, which must be recorded in the form of columns and rows in each

and every cell of a table.

Rule 2: The Guaranteed Access Rule

A relational DB’s primary key value, column name, and table name can be used to conceptually

retrieve any single or precise data (the atomic value).

Rule 3: The Systematic Treatment of Null Values

The treatment of Null values in DB records is defined by this rule. No value in a cell, missing data,

unsuitable information, unknown data, the primary key that should not be null, etc., are all

examples of null values in DBs.

Rule 4: The Dynamic/Active Online Catalog on the basis of the

Relational Model

A DB dictionary is a logical representation of the whole logical structure of a descriptive DB that

needs to be stored online. It grants users access to the DB and uses a query language that is

comparable to that of the DB.

Rule 5: The Comprehensive Data SubLanguage Rule

The relational DB supports a variety of languages, and in order to access the DB, the language has

to be linear, explicit, or a well-defined syntax, character strings. It must support the following

operations: view definition, integrity constraints, data manipulation, data definition, as well as limit

transaction management. It is considered a DB violation if the DB permits access to the data and

information without the use of any language.

Rule 6: The View Updating Rule

A view table can theoretically be updated, and DB systems must update them in practice.

Rule 7: The Relational Level Operation (or High-Level Insert, Delete, and

Update) Rule

In each level or single row, a DB system should adhere to high-level relational operations (for

example, update, insert, and delete). The DB system also includes operations like intersection,

union, and minus.

Rule 8: The Physical Data Independence Rule

To access a DB or an application, all stored data must be independent physically. Each piece of

data should not be reliant on another piece of data or an application. External applications that

access data from the DB will have no effect if data is altered or the physical structure of a given DB

is modified.

Rule 9: The Logical Data Independence Rule

It’s similar to the independence of physical data. It indicates that any modifications made at the

logical level (or the table structures) should not have an impact on the user’s experience

(application). For example, if a table is split into two separate tables or into two table joins in order

to produce a single table, the application at the user view should not be affected.

Rule 10: The Integrity Independence Rule

When we are using SQL to put data into table cells, a DB must guarantee integrity independence.

All the entered values must not be changed, and the integrity of the data should not be reliant on

any external component or application. It’s also useful for making each front-end app DB-

independent.

Rule 11: The Distribution Independence Rule

This rule denotes that a DB must function properly even if it’s stored in multiple locations and used

by various end-users. Let’s say a person uses an application to access the DB. In such a case, they

must not be aware that another user is using the same data, and thus, the data they always obtain

is only available on one site. The DB can be accessed by end-users, and each user’s access data

must be independent in order for them to run SQL queries.

Rule 12: The Non-Subversion Rule

RDBMS is defined by this rule as a SQL language for storing and manipulating data in a DB. If a

system uses a low-level or different language to access the DB system other than SQL, it should

not bypass or subvert data integrity.