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 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.
• 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.
 Functional Dependency
• The functional dependency is a relationship
that exists between two attributes. It typically
exists between the primary key and non-key
attribute within a table.
• X -> Y
• The left side of FD is known as a determinant,
the right side of the production is known as a
dependent.
• Functional Dependency (FD) is a constraint that
determines the relation of one attribute to
another attribute in a Database Management
System (DBMS).
• Functional Dependency helps to maintain the
quality of data in the database. It plays a vital role
to find the difference between good and bad
database design.
• A functional dependency is denoted by an arrow
"→". The functional dependency of X on Y is
represented by X → Y.
Types of Functional dependency
• Trivial functional dependency
• Non-Trivial functional dependency
• Multivalued functional dependency
• Transitive functional dependency
• Fully functional dependency
 Trivial functional dependency

• In Trivial functional dependency, a dependent

is always a subset of the determinant. In other
words, a functional dependency is called trivial
if the attributes on the right side are the
subset of the attributes on the left side of the
functional dependency.
• X → Y is called a trivial functional dependency
if Y is the subset of X.
 For example, consider the Employee
table below.
Here, { Employee_Id, Name } → { Name } is a
Trivial functional dependency, since the
dependent Name is the subset of determinant {
Employee_Id, Name }.
• { Employee_Id } → { Employee_Id }, { Name }
→ { Name } and { Age } → { Age } are also
Trivial. Employee_Id Name Age

1 Zayn 24
2 Phobe 34
3 Hikki 26
4 David 29
 Non-Trivial Functional Dependency

• It is the opposite of Trivial functional dependency.

Formally speaking, in Non-Trivial functional
dependency, dependent if not a subset of the
determinant.
• X → Y is called a Non-trivial functional dependency
if Y is not a subset of X. So, a functional dependency X
→ Y where X is a set of attributes and Y is also a set of
the attribute but not a subset of X, then it is
called Non-trivial functional dependency.
• For example, consider the Employee table below.
•
 Employee_Id Name Age
1 Zayn 24
2 Phobe 34
3 Hikki 26
4 David 29

• Here, { Employee_Id } → { Name } is a non-trivial functional dependency

because Name(dependent) is not a subset of Employee_Id(determinant).
• Similarly, { Employee_Id, Name } → { Age } is also a non-trivial functional dependency
 Multivalued Functional Dependency

• In Multivalued functional dependency, attributes in

the dependent set are not dependent on each other.
• For example, X → { Y, Z }, if there exists is no functional
dependency between Y and Z, then it is called
as Multivalued functional dependency.
• For example, consider the Employee table below.
• Here, { Employee_Id } → { Name, Age } is a Multivalued
functional dependency, since the dependent
attributes Name, Age are not functionally
dependent(i.e. Name → Age or Age → Name doesn’t
exist !).
Transitive Functional Dependency
 Fully functional dependency

• A functional dependency X->Y is a fully functional dependency if Y is

functionally dependent on X and Y is not functionally dependent on
any proper subset of X.
• Example –
In the relation ABC->D, attribute D is fully functionally dependent
on ABC and not on any proper subset of ABC. That means that
subsets of ABC like AB, BC, A, B, etc cannot determine D.
• In full functional dependency, the non-prime attribute is
functionally dependent on the candidate key.
• in fully functional dependency, if we remove any attribute of
X, then the dependency will not exist anymore.
• Full Functional Dependency equates to the normalization standard
of Second Normal Form.
 Partial Functional Dependency :
• A functional dependency X->Y is a partial
dependency if Y is functionally dependent on
X and Y can be determined by any proper
subset of X.
For example, we have a relationship AC->B,
A->D, and D->B.
 Inference Rule (IR):

• The Armstrong's axioms are the basic inference

rule.
• Armstrong's axioms are used to conclude
functional dependencies on a relational database.
• The inference rule is a type of assertion. It can
apply to a set of FD(functional dependency) to
derive other FD.
• Using the inference rule, we can derive additional
functional dependency from the initial set.
 The Functional dependency has 6
types of inference rule:
1. Reflexive Rule (IR1)
• In the reflexive rule, if Y is a subset of X, then X
determines Y.
• If X ⊇ Y then X → Y
Example:
• X = {a, b, c, d, e}
• Y = {a, b, c}
2. Augmentation Rule (IR2)
• The augmentation is also called as a partial
dependency. In augmentation, if X determines
Y, then XZ determines YZ for any Z.
• If X → Y then XZ → YZ
Example:
• For R(ABCD), if A → B then AC → BC
3. Transitive Rule (IR3)
• In the transitive rule, if X determines Y and Y
determine Z, then X must also determine Z.
1. If X → Y and Y → Z then X → Z
4. Union Rule (IR4)
• Union rule says, if X determines Y and X
determines Z, then X must also determine Y and
Z.
1. If X → Y and X → Z then X → YZ
5. Decomposition Rule (IR5)
• Decomposition rule is also known as project
rule. It is the reverse of union rule.
• This Rule says, if X determines Y and Z, then X
determines Y and X determines Z separately.
• If X → YZ then X → Y and X → Z
6. Pseudo transitive Rule (IR6)
• In Pseudo transitive Rule, if X determines Y
and YZ determines W, then XZ determines W.
• If X → Y and YZ → W then XZ → W