12 Codd's Rules

These rules were developed by Dr. Edgar F. Codd (E.F. Codd) in 1985, who has vast research
knowledge on the Relational Model of database Systems. Codd presents his 13 rules for a
database to test the concept of DBMS against his relational model, and if a database follows the
rule, it is called a true relational database (RDBMS). These 13 rules are popular in RDBMS,
known as Codd's 12 rules.

Rule 0: The Foundation Rule

The database must be in relational form. So that the system can handle the database through its
relational capabilities.

Rule 1: Information Rule

A database contains various information, and this information must be stored in each cell of a
table in the form of rows and columns.

Rule 2: Guaranteed Access Rule

Every single or precise data (atomic value) may be accessed logically from a relational database
using the combination of primary key value, table name, and column name.

Rule 3: Systematic Treatment of Null Values

This rule defines the systematic treatment of Null values in database records. The null value has
various meanings in the database, like missing the data, no value in a cell, inappropriate
information, unknown data and the primary key should not be null.

Rule 4: Active/Dynamic Online Catalog based on the relational model

It represents the entire logical structure of the descriptive database that must be stored online
and is known as a database dictionary. It authorizes users to access the database and
implement a similar query language to access the database.

Rule 5: Comprehensive Data SubLanguage Rule

The relational database supports various languages, and if we want to access the database, the
language must be the explicit, linear or well-defined syntax, character strings and supports the
comprehensive: data definition, view definition, data manipulation, integrity constraints, and
limit transaction management operations. If the database allows access to the data without any
language, it is considered a violation of the database.
Rule 6: View Updating Rule
All views table can be theoretically updated and must be practically updated by the database
systems.

Rule 7: Relational Level Operation (High-Level Insert, Update and

delete) Rule
A database system should follow high-level relational operations such as insert, update, and
delete in each level or a single row. It also supports union, intersection and minus operation in
the database system.

Rule 8: Physical Data Independence Rule

All stored data in a database or an application must be physically independent to access the
database. Each data should not depend on other data or an application. If data is updated or the
physical structure of the database is changed, it will not show any effect on external
applications that are accessing the data from the database.

Rule 9: Logical Data Independence Rule

It is similar to physical data independence. It means, if any changes occurred to the logical level
(table structures), it should not affect the user's view (application). For example, suppose a
table either split into two tables, or two table joins to create a single table, these changes
should not be impacted on the user view application.

Rule 10: Integrity Independence Rule

A database must maintain integrity independence when inserting data into table's cells using
the SQL query language. All entered values should not be changed or rely on any external factor
or application to maintain integrity. It is also helpful in making the database-independent for
each front-end application.

Rule 11: Distribution Independence Rule

The distribution independence rule represents a database that must work properly, even if it is
stored in different locations and used by different end-users. Suppose a user accesses the
database through an application; in that case, they should not be aware that another user uses
particular data, and the data they always get is only located on one site. The end users can
access the database, and these access data should be independent for every user to perform
the SQL queries.

Rule 12: Non Subversion Rule

The non-submersion rule defines RDBMS as a SQL language to store and manipulate the data in
the database. If a system has a low-level or separate language other than SQL to access the
database system, it should not subvert or bypass integrity to transform data.

Difference between DBMS and RDBMS

No DBMS RDBMS
.

1) DBMS applications store data as file. RDBMS applications store data in a tabular form.

2) In DBMS, data is generally stored in either In RDBMS, the tables have an identifier called
a hierarchical form or a navigational form. primary key and the data values are stored in the
form of tables.

3) Normalization is not present in DBMS. Normalization is present in RDBMS.

4) DBMS does not apply any security with RDBMS defines the integrity constraint for the
regards to data manipulation. purpose of ACID (Atomocity, Consistency, Isolation
and Durability) property.

5) DBMS uses file system to store data, so in RDBMS, data values are stored in the form of
there will be no relation between the tables, so a relationship between these data values
tables. will be stored in the form of a table as well.

6) DBMS has to provide some uniform RDBMS system supports a tabular structure of the
methods to access the stored data and a relationship between them to access the
information. stored information.

7) DBMS does not support distributed RDBMS supports distributed database.

database.

8) DBMS is meant to be for small RDBMS is designed to handle large amount of data.
organization and deal with small data. it it supports multiple users.
supports single user.

9) Examples of DBMS are file Example of RDBMS are mysql, postgre, sql
systems, xml etc. server, oracle etc.
Difference between File System and DBMS

Basics File System DBMS

The file system is a way of arranging the

DBMS is software for managing the
files in a storage medium within a
database.
Structure computer.

Data Redundant data can be present in a file

In DBMS there is no redundant data.
Redundancy system.

Backup and It doesn’t provide Inbuilt mechanism for It provides in house tools for backup
Recovery backup and recovery of data if it is lost. and recovery of data even if it is lost.

Query There is no efficient query processing in Efficient query processing is there in

processing the file system. DBMS.

There is more data consistency

There is less data consistency in the file
because of the process of
system.
Consistency normalization.

It has more complexity in handling as

It is less complex as compared to DBMS.
Complexity compared to the file system.

Security File systems provide less security in DBMS has more security mechanisms
Constraints comparison to DBMS. as compared to file systems.

It has a comparatively higher cost

It is less expensive than DBMS.
Cost than a file system.

Data There is no data independence. In DBMS data independence exists,

Independence mainly of two types:

1) Logical Data Independence.

Basics File System DBMS

2)Physical Data Independence.

Multiple users can access data at a

Only one user can access data at a time.
User Access time.

The users are not required to write The user has to write procedures for
Meaning procedures. managing databases

Data is distributed in many files. So, it is Due to centralized nature data

Sharing not easy to share data. sharing is easy

It give details of storage and It hides the internal details of

Data Abstraction representation of data Database

Integrity Integrity Constraints are difficult to Integrity constraints are easy to

Constraints implement implement

To access data in a file , user requires

No such attributes are required.
Attributes attributes such as file name, file location.

Example Cobol, C++ Oracle, SQL Server