Constraints in DBMS | Types of Constraints in DBMS

 Relational constraints are the restrictions imposed on the database contents and operations.
 They ensure the correctness of data in the database.

Types of Constraints in DBMS-

In DBMS, there are following 5 different types of relational constraints-

1. Domain constraint
2. Tuple Uniqueness constraint
3. Key constraint
4. Entity Integrity constraint
5. Referential Integrity constraint

1. Domain Constraint-

 Domain constraint defines the domain or set of values for an attribute.

 It specifies that the value taken by the attribute must be the atomic value from its domain.

Example-
Consider the following Student table-

STU_ID Name Age

S001 Akshay 20

S002 Abhishek 21

S003 Shashank 20

S004 Rahul A

Here, value ‘A’ is not allowed since only integer values can be taken by the age attribute.

2. Tuple Uniqueness Constraint-

Tuple Uniqueness constraint specifies that all the tuples must be necessarily unique in any relation.

Example-01:

Consider the following Student table-

STU_ID Name Age

S001 Akshay 20

S002 Abhishek 21

S003 Shashank 20

S004 Rahul 20
 This relation satisfies the tuple uniqueness constraint since here all the tuples are unique.

Example-02:

Consider the following Student table-

STU_ID Name Age

S001 Akshay 20

S001 Akshay 20

S003 Shashank 20

S004 Rahul 20

This relation does not satisfy the tuple uniqueness constraint since here all the tuples are not unique.

3. Key Constraint-

Key constraint specifies that in any relation-

 All the values of primary key must be unique.

 The value of primary key must not be null.

Example-

Consider the following Student table-

STU_ID Name Age

S001 Akshay 20

S001 Abhishek 21
 S003 Shashank 20

S004 Rahul 20

This relation does not satisfy the key constraint as here all the values of primary key are not unique.

4. Entity Integrity Constraint-

 Entity integrity constraint specifies that no attribute of primary key must contain a null value in any relation.
 This is because the presence of null value in the primary key violates the uniqueness property.

Example-

Consider the following Student table-

STU_ID Name Age

S001 Akshay 20

S002 Abhishek 21

S003 Shashank 20

Rahul 20

This relation does not satisfy the entity integrity constraint as here the primary key contains a NULL value.

5. Referential Integrity Constraint-

 This constraint is enforced when a foreign key references the primary key of a relation.
 It specifies that all the values taken by the foreign key must either be available in the relation of the primary key or be
null.

Read more- Foreign Key in DBMS

Important Results-

The following two important results emerges out due to referential integrity constraint-

 We can not insert a record into a referencing relation if the corresponding record does not exist in the referenced
relation.
 We can not delete or update a record of the referenced relation if the corresponding record exists in the referencing
relation.

Example-

Consider the following two relations- ‘Student’ and ‘Department’.

Here, relation ‘Student’ references the relation ‘Department’.

Student

STU_ID Name Dept_no

S001 Akshay D10

S002 Abhishek D10

S003 Shashank D11

 S004 Rahul D14

Department

Dept_no Dept_name

D10 ASET

D11 ALS

D12 ASFL

D13 ASHS

Here,

 The relation ‘Student’ does not satisfy the referential integrity constraint.
 This is because in relation ‘Department’, no value of primary key specifies department no. 14.
 Thus, referential integrity constraint is violated.

Handling Violation of Referential Integrity Constraint-

To ensure the correctness of the database, it is important to handle the violation of referential integrity constraint
properly.

Closure in DBMS | Steps to Find Closure

Database Management System
Closure of an Attribute Set-

 The set of all those attributes which can be functionally determined from an attribute set is called as a closure of that
attribute set.
 Closure of attribute set {X} is denoted as {X}+.

Steps to Find Closure of an Attribute Set-

Following steps are followed to find the closure of an attribute set-

Step-01:

Add the attributes contained in the attribute set for which closure is being calculated to the result set.

Step-02:

Recursively add the attributes to the result set which can be functionally determined from the attributes already
contained in the result set.

Example-

Consider a relation R ( A , B , C , D , E , F , G ) with the functional dependencies-

A → BC

BC → DE

D→F

CF → G

Now, let us find the closure of some attributes and attribute sets-

Closure of attribute A-

A+ = { A }

={A,B,C} ( Using A → BC )

={A,B,C,D,E} ( Using BC → DE )

={A,B,C,D,E,F} ( Using D → F )

={A,B,C,D,E,F,G} ( Using CF → G )

Thus,

A+ = { A , B , C , D , E , F , G }

Closure of attribute D-

D+ = { D }

= { D , F } ( Using D → F )
 We can not determine any other attribute using attributes D and F contained in the result set.

Thus,

D+ = { D , F }

Closure of attribute set {B, C}-

{ B , C }+ = { B , C }

={B,C,D,E} ( Using BC → DE )

={B,C,D,E,F} ( Using D → F )

={B,C,D,E,F,G} ( Using CF → G )

Thus,

{ B , C }+ = { B , C , D , E , F , G }

Finding the Keys Using Closure-

Super Key-

 If the closure result of an attribute set contains all the attributes of the relation, then that attribute set is called as a
super key of that relation.
 Thus, we can say-
“The closure of a super key is the entire relation schema.”

Example-

In the above example,

 The closure of attribute A is the entire relation schema.

 Thus, attribute A is a super key for that relation.

Candidate Key-

 If there exists no subset of an attribute set whose closure contains all the attributes of the relation, then that attribute
set is called as a candidate key of that relation.

Example-

In the above example,

 No subset of attribute A contains all the attributes of the relation.

 Thus, attribute A is also a candidate key for that relation.

PRACTICE PROBLEM BASED ON FINDING CLOSURE OF AN ATTRIBUTE SET-

Problem-

Consider the given functional dependencies-

AB → CD

AF → D

DE → F

C→G

F→E

G→A

Which of the following options is false?

(A) { CF }+ = { A , C , D , E , F , G }

(B) { BG }+ = { A , B , C , D , G }

(C) { AF }+ = { A , C , D , E , F , G }

(D) { AB }+ = { A , C , D , F ,G }

Solution-

Let us check each option one by one-

Option-(A):

{ CF }+ = { C , F }

={C,F,G} ( Using C → G )

={C,E,F,G} ( Using F → E )

={A,C,E,E,F} ( Using G → A )

={A,C,D,E,F,G} ( Using AF → D )

Since, our obtained result set is same as the given result set, so, it means it is correctly given.

Option-(B):
{ BG }+ = { B , G }

={A,B,G} ( Using G → A )

={A,B,C,D,G} ( Using AB → CD )

Since, our obtained result set is same as the given result set, so, it means it is correctly given.

Option-(C):

{ AF }+ = { A , F }

={A,D,F} ( Using AF → D )

={A,D,E,F} ( Using F → E )

Since, our obtained result set is different from the given result set, so,it means it is not correctly given.

Option-(D):

{ AB }+ = { A , B }

={A,B,C,D} ( Using AB → CD )

={A,B,C,D,G} ( Using C → G )

Since, our obtained result set is different from the given result set, so,it means it is not correctly given.

Thus,

Option (C) and Option (D) are correct.

Keys in DBMS
Database Management System
Keys in DBMS-

A key is a set of attributes that can identify each tuple uniquely in the given relation.

Different Types Of Keys in DBMS-

There are following 10 important keys in DBMS-

1. Super key
2. Candidate key
3. Primary key
4. Alternate key
5. Foreign key
6. Partial key
7. Composite key
8. Unique key
9. Surrogate key
10. Secondary key

NOTE-

Before proceeding further, Kindly note-

 The terms ‘relation’ and ‘table’ are used interchangeably.

 The terms ‘tuple’ and ‘record’ are used interchangeably.
So, don’t get confused!

1. Super Key-

 A super key is a set of attributes that can identify each tuple uniquely in the given relation.
 A super key is not restricted to have any specific number of attributes.
 Thus, a super key may consist of any number of attributes.

Example-

Consider the following Student schema-

Student ( roll , name , sex , age , address , class , section )

Given below are the examples of super keys since each set can uniquely identify each student in the Student table-

 ( roll , name , sex , age , address , class , section )

 ( class , section , roll )
 (class , section , roll , sex )
 ( name , address )

NOTE-

All the attributes in a super key are definitely sufficient to identify each tuple uniquely in the given relation but all of
them may not be necessary.

2. Candidate Key-

A minimal super key is called as a candidate key.

OR

A set of minimal attribute(s) that can identify each tuple uniquely in the given relation is called as a candidate key.

Example-

Consider the following Student schema-

Student ( roll , name , sex , age , address , class , section )

Given below are the examples of candidate keys since each set consists of minimal attributes required to identify
each student uniquely in the Student table-

 ( class , section , roll )

 ( name , address )

NOTES-

 All the attributes in a candidate key are sufficient as well as necessary to identify each tuple uniquely.
 Removing any attribute from the candidate key fails in identifying each tuple uniquely.
 The value of candidate key must always be unique.
 The value of candidate key can never be NULL.
 It is possible to have multiple candidate keys in a relation.
 Those attributes which appears in some candidate key are called as prime attributes.

3. Primary Key-

A primary key is a candidate key that the database designer selects while designing the database.

OR

Candidate key that the database designer implements is called as a primary key.

NOTES-

 The value of primary key can never be NULL.

 The value of primary key must always be unique.
 The values of primary key can never be changed i.e. no updation is possible.
 The value of primary key must be assigned when inserting a record.
 A relation is allowed to have only one primary key.

Remember-

4. Alternate Key-

Candidate keys that are left unimplemented or unused after implementing the primary key are called as alternate
keys.
 OR

Unimplemented candidate keys are called as alternate keys.

5. Foreign Key-

 An attribute ‘X’ is called as a foreign key to some other attribute ‘Y’ when its values are dependent on the values of
attribute ‘Y’.
 The attribute ‘X’ can assume only those values which are assumed by the attribute ‘Y’.
 Here, the relation in which attribute ‘Y’ is present is called as the referenced relation.
 The relation in which attribute ‘X’ is present is called as the referencing relation.
 The attribute ‘Y’ might be present in the same table or in some other table.

Example-

Consider the following two schemas-

Here, t_dept can take only those values which are present in dept_no in Department table since only those
departments actually exist.

NOTES-

 Foreign key references the primary key of the table.

 Foreign key can take only those values which are present in the primary key of the referenced relation.
 Foreign key may have a name other than that of a primary key.
 Foreign key can take the NULL value.
 There is no restriction on a foreign key to be unique.
 In fact, foreign key is not unique most of the time.
 Referenced relation may also be called as the master table or primary table.
 Referencing relation may also be called as the foreign table.
 6. Partial Key-

 Partial key is a key using which all the records of the table can not be identified uniquely.
 However, a bunch of related tuples can be selected from the table using the partial key.

Example-

Consider the following schema-

Department ( Emp_no , Dependent_name , Relation )

Emp_no Dependent_name Relation

E1 Suman Mother

E1 Ajay Father

E2 Vijay Father

E2 Ankush Son

Here, using partial key Emp_no, we can not identify a tuple uniquely but we can select a bunch of tuples from the
table.

7. Composite Key-

A primary key comprising of multiple attributes and not just a single attribute is called as a composite key.

8. Unique Key-

Unique key is a key with the following properties-

 It is unique for all the records of the table.

 Once assigned, its value can not be changed i.e. it is non-updatable.
 It may have a NULL value.
 Example-

The best example of unique key is Adhaar Card Numbers.

 The Adhaar Card Number is unique for all the citizens (tuples) of India (table).
 If it gets lost and another duplicate copy is issued, then the duplicate copy always has the same number as before.
 Thus, it is non-updatable.
 Few citizens may not have got their Adhaar cards, so for them its value is NULL.

9. Surrogate Key-

Surrogate key is a key with the following properties-

 It is unique for all the records of the table.

 It is updatable.
 It can not be NULL i.e. it must have some value.

Example-

Mobile Number of students in a class where every student owns a mobile phone.

10. Secondary Key-

Secondary key is required for the indexing purpose for better and faster searching.

Functional Dependency in DBMS

Database Management System
Functional Dependency-

In any relation, a functional dependency α → β holds if-

Two tuples having same value of attribute α also have same value for attribute β.

Mathematically,

If α and β are the two sets of attributes in a relational table R where-

α⊆R
β⊆R
Then, for a functional dependency to exist from α to β,

If t1[α] = t2[α], then t1[β] = t2[β]

 α β

t1[α] t1[β]

t2[α] t2[β]

……. …….

fd : α → β

Types Of Functional Dependencies-

There are two types of functional dependencies-

1. Trivial Functional Dependencies

2. Non-trivial Functional Dependencies

1. Trivial Functional Dependencies-

 A functional dependency X → Y is said to be trivial if and only if Y ⊆ X.

 Thus, if RHS of a functional dependency is a subset of LHS, then it is called as a trivial functional dependency.

Examples-
 The examples of trivial functional dependencies are-

 AB → A
 AB → B
 AB → AB

2. Non-Trivial Functional Dependencies-

 A functional dependency X → Y is said to be non-trivial if and only if Y ⊄ X.

 Thus, if there exists at least one attribute in the RHS of a functional dependency that is not a part of LHS, then it is
called as a non-trivial functional dependency.

Examples-

The examples of non-trivial functional dependencies are-

 AB → BC
 AB → CD

Inference Rules or Armstrong axioms:

Reflexivity-

If B is a subset of A, then A → B always holds.

Transitivity-
If A → B and B → C, then A → C always holds.

Augmentation-
If A → B, then AC → BC always holds.

A->B

A->AB(AUGMENT BY A)

Decomposition-
If A → BC, then A → B and A → C always holds.

UNION OR Composition-
If A → B and C → D, then AC → BD always holds.

Additive-
If A → B and A → C, then A → BC always holds.
 Rules for Functional Dependency-

Rule-01:

A functional dependency X → Y will always hold if all the values of X are unique (different) irrespective of the values
of Y.

Example-

Consider the following table-

A B C D E

5 4 3 2 2

8 5 3 2 1

1 9 3 3 5

4 7 3 3 8

The following functional dependencies will always hold since all the values of attribute ‘A’ are unique-

A→B
 A → BC
 A → CD
 A → BCD
 A → DE
 A → BCDE
In general, we can say following functional dependency will always hold-

A → Any combination of attributes A, B, C, D, E

Similar will be the case for attributes B and E.

 Rule-02:

A functional dependency X → Y will always hold if all the values of Y are same irrespective of the values of X.

Example-
Consider the following table-

A B C D E

5 4 3 2 2

8 5 3 2 1

1 9 3 3 5

4 7 3 3 8

The following functional dependencies will always hold since all the values of attribute ‘C’ are same-

A→C
 AB → C
 ABDE → C
 DE → C
 AE → C

In general, we can say following functional dependency will always hold true-

Any combination of attributes A, B, C, D, E → C

Combining Rule-01 and Rule-02 we can say-

In general, a functional dependency α → β always holds-

 If either all values of α are unique or if all values of β are same or both.

Rule-03:

For a functional dependency X → Y to hold, if two tuples in the table agree on the value of attribute X, then they must
also agree on the value of attribute Y.

Rule-04:

For a functional dependency X → Y, violation will occur only when for two or more same values of X, the
corresponding Y values are different.

Equivalence of Two Sets of Functional Dependencies

Database Management System
Equivalence of Two Sets of Functional Dependencies-

Before you go through this article, make sure that you have gone through the previous article on Functional
Dependency.

In DBMS,

 Two different sets of functional dependencies for a given relation may or may not be equivalent.
 If F and G are the two sets of functional dependencies, then following 3 cases are possible-

Case-01: F covers G (F ⊇ G)

Case-02: G covers F (G ⊇ F)

Case-03: Both F and G cover each other (F = G)

Case-01: Determining Whether F Covers G-

Following steps are followed to determine whether F covers G or not-

Step-01:

 Take the functional dependencies of set G into consideration.

 For each functional dependency X → Y, find the closure of X using the functional dependencies of set G.
 Step-02:

 Take the functional dependencies of set G into consideration.

 For each functional dependency X → Y, find the closure of X using the functional dependencies of set F.

Step-03:

 Compare the results of Step-01 and Step-02.

 If the functional dependencies of set F has determined all those attributes that were determined by the functional
dependencies of set G, then it means F covers G.
 Thus, we conclude F covers G (F ⊇ G) otherwise not.

Case-02: Determining Whether G Covers F-

Following steps are followed to determine whether G covers F or not-

Step-01:

 Take the functional dependencies of set F into consideration.

 For each functional dependency X → Y, find the closure of X using the functional dependencies of set F.

Step-02:

 Take the functional dependencies of set F into consideration.

 For each functional dependency X → Y, find the closure of X using the functional dependencies of set G.

Step-03:

 Compare the results of Step-01 and Step-02.

 If the functional dependencies of set G has determined all those attributes that were determined by the functional
dependencies of set F, then it means G covers F.
 Thus, we conclude G covers F (G ⊇ F) otherwise not.

Case-03: Determining Whether Both F and G Cover Each Other-

 If F covers G and G covers F, then both F and G cover each other.

 Thus, if both the above cases hold true, we conclude both F and G cover each other (F = G).

PRACTICE PROBLEM BASED ON EQUIVALENCE OF FUNCTIONAL DEPENDENCIES-

 Problem-

A relation R (A , C , D , E , H) is having two functional dependencies sets F and G as shown-

Set F-
A→C

AC → D

E → AD

E→H

Set G-
A → CD

E → AH

Which of the following holds true?

(A) G ⊇ F

(B) F ⊇ G

(C) F = G

(D) All of the above

Solution-

Determining whether F covers G-

Step-01:

 (A)+ = { A , C , D } // closure of left side of A → CD using set G

 (E) = { A , C , D , E , H }
+
// closure of left side of E → AH using set G

Step-02:

 (A)+ = { A , C , D } // closure of left side of A → CD using set F

 (E) = { A , C , D , E , H }
+
// closure of left side of E → AH using set F

Step-03:
 Comparing the results of Step-01 and Step-02, we find-

 Functional dependencies of set F can determine all the attributes which have been determined by the functional
dependencies of set G.
 Thus, we conclude F covers G i.e. F ⊇ G.

Determining whether G covers F-

Step-01:

 (A)+ = { A , C , D } // closure of left side of A → C using set F

 (AC) = { A , C , D }
+
// closure of left side of AC → D using set F
 (E) = { A , C , D , E , H }
+
// closure of left side of E → AD and E → H using set F

Step-02:

 (A)+ = { A , C , D } // closure of left side of A → C using set G

 (AC) = { A , C , D }
+
// closure of left side of AC → D using set G
 (E)+ = { A , C , D , E , H } // closure of left side of E → AD and E → H using set G

Step-03:

Comparing the results of Step-01 and Step-02, we find-

 Functional dependencies of set G can determine all the attributes which have been determined by the functional
dependencies of set F.
 Thus, we conclude G covers F i.e. G ⊇ F.

Determining whether both F and G cover each other-

 From Step-01, we conclude F covers G.

 From Step-02, we conclude G covers F.
 Thus, we conclude both F and G cover each other i.e. F = G.

Thus, Option (D) is correct.

Canonical Cover in DBMS

Database Management System
Canonical Cover in DBMS-

Before you go through this article, make sure that you have gone through the previous article on Functional
Dependency in DBMS.
 In DBMS,

 A canonical cover is a simplified and reduced version of the given set of functional dependencies.
 Since it is a reduced version, it is also called as Irreducible set.

Characteristics-

 Canonical cover is free from all the extraneous functional dependencies.

 The closure of canonical cover is same as that of the given set of functional dependencies.
 Canonical cover is not unique and may be more than one for a given set of functional dependencies.

Need-

 Working with the set containing extraneous functional dependencies increases the computation time.
 Therefore, the given set is reduced by eliminating the useless functional dependencies.
 This reduces the computation time and working with the irreducible set becomes easier.

Steps To Find Canonical Cover-

Step-01:

Write the given set of functional dependencies in such a way that each functional dependency contains exactly one
attribute on its right side.

Example-

The functional dependency X → YZ will be written as-

X→Y

X→Z

Step-02:

 Consider each functional dependency one by one from the set obtained in Step-01.
 Determine whether it is essential or non-essential.

To determine whether a functional dependency is essential or not, compute the closure of its left side-

 Once by considering that the particular functional dependency is present in the set
 Once by considering that the particular functional dependency is not present in the set
 Then following two cases are possible-

Case-01: Results Come Out to be Same-

If results come out to be same,

 It means that the presence or absence of that functional dependency does not create any difference.
 Thus, it is non-essential.
 Eliminate that functional dependency from the set.

NOTE-

 Eliminate the non-essential functional dependency from the set as soon as it is discovered.
 Do not consider it while checking the essentiality of other functional dependencies.

Case-01: Results Come Out to be Different-

If results come out to be different,

 It means that the presence or absence of that functional dependency creates a difference.
 Thus, it is essential.
 Do not eliminate that functional dependency from the set.
 Mark that functional dependency as essential.

Step-03:

 Consider the newly obtained set of functional dependencies after performing Step-02.
 Check if there is any functional dependency that contains more than one attribute on its left side.

Then following two cases are possible-

Case-01: No-

 There exists no functional dependency containing more than one attribute on its left side.
 In this case, the set obtained in Step-02 is the canonical cover.

Case-01: Yes-

 There exists at least one functional dependency containing more than one attribute on its left side.
 In this case, consider all such functional dependencies one by one.
 Check if their left side can be reduced.

Use the following steps to perform a check-

 Consider a functional dependency.

 Compute the closure of all the possible subsets of the left side of that functional dependency.
 If any of the subsets produce the same closure result as produced by the entire left side, then replace the left side
with that subset.
After this step is complete, the set obtained is the canonical cover.

PRACTICE PROBLEM BASED ON FINDING CANONICAL COVER-

Problem-

The following functional dependencies hold true for the relational scheme R ( W , X , Y , Z ) –

X→W

WZ → XY

Y → WXZ

Write the irreducible equivalent for this set of functional dependencies.

Solution-

Step-01:

Write all the functional dependencies such that each contains exactly one attribute on its right side-

X→W

WZ → X

WZ → Y

Y→W

Y→X

Y→Z

Step-02:

Check the essentiality of each functional dependency one by one.

For X → W:
 Considering X → W, (X)+ = { X , W }
 Ignoring X → W, (X)+ = { X }

Now,

 Clearly, the two results are different.

 Thus, we conclude that X → W is essential and can not be eliminated.

For WZ → X:

 Considering WZ → X, (WZ)+ = { W , X , Y , Z }
 Ignoring WZ → X, (WZ)+ = { W , X , Y , Z }

Now,

 Clearly, the two results are same.

 Thus, we conclude that WZ → X is non-essential and can be eliminated.

Eliminating WZ → X, our set of functional dependencies reduces to-

X→W

WZ → Y

Y→W

Y→X

Y→Z

Now, we will consider this reduced set in further checks.

For WZ → Y:

 Considering WZ → Y, (WZ)+ = { W , X , Y , Z }
 Ignoring WZ → Y, (WZ)+ = { W , Z }

Now,

 Clearly, the two results are different.

 Thus, we conclude that WZ → Y is essential and can not be eliminated.

For Y → W:

 Considering Y → W, (Y)+ = { W , X , Y , Z }
 Ignoring Y → W, (Y)+ = { W , X , Y , Z }

Now,

 Clearly, the two results are same.

 Thus, we conclude that Y → W is non-essential and can be eliminated.

Eliminating Y → W, our set of functional dependencies reduces to-

X→W

WZ → Y

Y→X

Y→Z

For Y → X:

 Considering Y → X, (Y)+ = { W , X , Y , Z }
 Ignoring Y → X, (Y)+ = { Y , Z }

Now,

 Clearly, the two results are different.

 Thus, we conclude that Y → X is essential and can not be eliminated.

For Y → Z:

 Considering Y → Z, (Y)+ = { W , X , Y , Z }
 Ignoring Y → Z, (Y)+ = { W , X , Y }

Now,

 Clearly, the two results are different.

 Thus, we conclude that Y → Z is essential and can not be eliminated.

From here, our essential functional dependencies are-

X→W

WZ → Y

Y→X

Y→Z
 Step-03:

 Consider the functional dependencies having more than one attribute on their left side.
 Check if their left side can be reduced.

In our set,

 Only WZ → Y contains more than one attribute on its left side.

 Considering WZ → Y, (WZ)+ = { W , X , Y , Z }

Now,

 Consider all the possible subsets of WZ.

 Check if the closure result of any subset matches to the closure result of WZ.
(W)+ = { W }

(Z)+ = { Z }

Clearly,

 None of the subsets have the same closure result same as that of the entire left side.
 Thus, we conclude that we can not write WZ → Y as W → Y or Z → Y.
 Thus, set of functional dependencies obtained in step-02 is the canonical cover.

Finally, the canonical cover is-

X→W

WZ → Y

Y→X

Y→Z

Canonical Cover

Decomposition in DBMS | Lossless | Lossy

Database Management System
Decomposition of a Relation-

The process of breaking up or dividing a single relation into two or more sub relations is called as decomposition of a
relation.

Properties of Decomposition-

The following two properties must be followed when decomposing a given relation-
 1. Lossless decomposition-

Lossless decomposition ensures-

 No information is lost from the original relation during decomposition.

 When the sub relations are joined back, the same relation is obtained that was decomposed.
Every decomposition must always be lossless.

2. Dependency Preservation-

Dependency preservation ensures-

 None of the functional dependencies that holds on the original relation are lost.
 The sub relations still hold or satisfy the functional dependencies of the original relation.

Types of Decomposition-

Decomposition of a relation can be completed in the following two ways-

1. Lossless Join Decomposition-

 Consider there is a relation R which is decomposed into sub relations R1 , R2 , …. , Rn.

 This decomposition is called lossless join decomposition when the join of the sub relations results in the same
relation R that was decomposed.
 For lossless join decomposition, we always have-

R1 ⋈ R2 ⋈ R3 ……. ⋈ Rn = R

where ⋈ is a natural join operator

Example-

Consider the following relation R( A , B , C )-

A B C

1 2 1

2 5 3

3 3 3

R( A , B , C )

Consider this relation is decomposed into two sub relations R1( A , B ) and R2( B , C )-

The two sub relations are-

A B

1 2

2 5

3 3

R1 ( A , B )
 B C

2 1

5 3

3 3

R2 ( B , C )

Now, let us check whether this decomposition is lossless or not.

For lossless decomposition, we must have-

R1 ⋈ R 2 = R

Now, if we perform the natural join ( ⋈ ) of the sub relations R1 and R2 , we get-

A B C

1 2 1

2 5 3

3 3 3

This relation is same as the original relation R.

Thus, we conclude that the above decomposition is lossless join decomposition.

NOTE-

 Lossless join decomposition is also known as non-additive join decomposition.

 This is because the resultant relation after joining the sub relations is same as the decomposed relation.
 No extraneous tuples appear after joining of the sub-relations.
 2. Lossy Join Decomposition-

 Consider there is a relation R which is decomposed into sub relations R1 , R2 , …. , Rn.

 This decomposition is called lossy join decomposition when the join of the sub relations does not result in the same
relation R that was decomposed.
 The natural join of the sub relations is always found to have some extraneous tuples.
 For lossy join decomposition, we always have-

R1 ⋈ R2 ⋈ R3 ……. ⋈ Rn ⊃ R

where ⋈ is a natural join operator

Example-

Consider the following relation R( A , B , C )-

A B C

1 2 1

2 5 3

3 3 3

R( A , B , C )

Consider this relation is decomposed into two sub relations as R1( A , C ) and R2( B , C )-

The two sub relations are-

 A C

1 1

2 3

3 3

R1 ( A , B )

B C

2 1

5 3

3 3

R2 ( B , C )

Now, let us check whether this decomposition is lossy or not.

For lossy decomposition, we must have-

R1 ⋈ R 2 ⊃ R

Now, if we perform the natural join ( ⋈ ) of the sub relations R1 and R2 we get-

A B C

1 2 1

2 5 3
 2 3 3

3 5 3

3 3 3

This relation is not same as the original relation R and contains some extraneous tuples.

Clearly, R1 ⋈ R2 ⊃ R.

Thus, we conclude that the above decomposition is lossy join decomposition.

NOTE-

 Lossy join decomposition is also known as careless decomposition.

 This is because extraneous tuples get introduced in the natural join of the sub-relations.
 Extraneous tuples make the identification of the original tuples difficult.

Determine Decomposition Is Lossless Or Lossy

Database Management System
Decomposition in DBMS-

Before you go through this article, make sure that you have gone through the previous article on Decomposition in
DBMS.

We have discussed-

 Decomposition is a process of dividing a single relation into two or more sub relations.
 Decomposition of a relation can be completed in the following two ways-
1. Lossless Join Decomposition
2. Lossy Join Decomposition

In this article, we will learn how to determine whether the decomposition is lossless or lossy.

Determining Whether Decomposition Is Lossless Or Lossy-

Consider a relation R is decomposed into two sub relations R1 and R2.

Then,

 If all the following conditions satisfy, then the decomposition is lossless.

 If any of these conditions fail, then the decomposition is lossy.

Condition-01:

Union of both the sub relations must contain all the attributes that are present in the original relation R.

Thus,

R1 ∪ R2 = R

Condition-02:

 Intersection of both the sub relations must not be null.

 In other words, there must be some common attribute which is present in both the sub relations.
Thus,

R1 ∩ R2 ≠ ∅

Condition-03:

Intersection of both the sub relations must be a super key of either R1 or R2 or both.

Thus,

R1 ∩ R2 = Super key of R1 or R2

PRACTICE PROBLEMS BASED ON DETERMINING WHETHER DECOMPOSITION IS LOSSLESS OR LOSSY-

 Problem-01:

Consider a relation schema R ( A , B , C , D ) with the functional dependencies A → B and C → D. Determine

whether the decomposition of R into R1 ( A , B ) and R2 ( C , D ) is lossless or lossy.

Solution-

A B C D

R1 A1 A2 B13 B14

R2 B21 B22 A3 A4

A->B(NO CHANGE)

C->D(NO CHANGE)

AS NO ROW HAS ONLY Ai then the decomposition is lossy.

To determine whether the decomposition is lossless or lossy,

 We will check all the conditions one by one.

 If any of the conditions fail, then the decomposition is lossy otherwise lossless.

Condition-01:

According to condition-01, union of both the sub relations must contain all the attributes of relation R.

So, we have-

R1 ( A , B ) ∪ R2 ( C , D )

=R(A,B,C,D)

Clearly, union of the sub relations contain all the attributes of relation R.
Thus, condition-01 satisfies.

Condition-02:

According to condition-02, intersection of both the sub relations must not be null.

So, we have-

R1 ( A , B ) ∩ R2 ( C , D )

=Φ

Clearly, intersection of the sub relations is null.

So, condition-02 fails.

Thus, we conclude that the decomposition is lossy.

Problem-02:

Consider a relation schema R ( A , B , C , D ) with the following functional dependencies-

A→B

B→C

C→D

D→B

Determine whether the decomposition of R into R1 ( A , B ) , R2 ( B , C ) and R3 ( B , D ) is lossless or lossy.

A B C D

R1 a1 a2 b13 b14

R2 b21 a2 a3 b24

R3 b31 a2 b33 a4

A->B (NO CHANGE)

B->C

A B C D

R1 a1 a2 a3 b14

R2 b21 a2 a3 b24

R3 b31 a2 a3 a4
 C->D

A B C D

R1 a1 a2 a3 a4

R2 b21 a2 a3 a4

R3 b31 a2 a3 a4

D->B(NO CHANGE)

As row R1 has all ai then the decomposition is lossless.

Solution-

Strategy to Solve

When a given relation is decomposed into more than two sub relations, then-

 Consider any one possible ways in which the relation might have been decomposed into those sub relations.
 First, divide the given relation into two sub relations.
 Then, divide the sub relations according to the sub relations given in the question.
As a thumb rule, remember-

Any relation can be decomposed only into two sub relations at a time.

Consider the original relation R was decomposed into the given sub relations as shown-
 Decomposition of R(A, B, C, D) into R'(A, B, C) and R 3(B, D)-

To determine whether the decomposition is lossless or lossy,

 We will check all the conditions one by one.

 If any of the conditions fail, then the decomposition is lossy otherwise lossless.

Condition-01:

According to condition-01, union of both the sub relations must contain all the attributes of relation R.

So, we have-

R‘ ( A , B , C ) ∪ R3 ( B , D )

=R(A,B,C,D)

Clearly, union of the sub relations contain all the attributes of relation R.

Thus, condition-01 satisfies.

Condition-02:

According to condition-02, intersection of both the sub relations must not be null.

So, we have-

R‘ ( A , B , C ) ∩ R3 ( B , D )

=B

Clearly, intersection of the sub relations is not null.

Thus, condition-02 satisfies.

Condition-03:

According to condition-03, intersection of both the sub relations must be the super key of one of the two sub relations
or both.

So, we have-

R‘ ( A , B , C ) ∩ R3 ( B , D )

=B

Now, the closure of attribute B is-

B+ = { B , C , D }

Now, we see-
 Attribute ‘B’ can not determine attribute ‘A’ of sub relation R’.
 Thus, it is not a super key of the sub relation R’.
 Attribute ‘B’ can determine all the attributes of sub relation R3.
 Thus, it is a super key of the sub relation R3.

Clearly, intersection of the sub relations is a super key of one of the sub relations.

So, condition-03 satisfies.

Thus, we conclude that the decomposition is lossless.

Decomposition of R'(A, B, C) into R1(A, B) and R2(B, C)-

To determine whether the decomposition is lossless or lossy,

 We will check all the conditions one by one.

 If any of the conditions fail, then the decomposition is lossy otherwise lossless.

Condition-01:

According to condition-01, union of both the sub relations must contain all the attributes of relation R’.

So, we have-

R1 ( A , B ) ∪ R2 ( B , C )

= R’ ( A , B , C )

Clearly, union of the sub relations contain all the attributes of relation R’.

Thus, condition-01 satisfies.

Condition-02:

According to condition-02, intersection of both the sub relations must not be null.

So, we have-

R1 ( A , B ) ∩ R2 ( B , C )

=B

Clearly, intersection of the sub relations is not null.

Thus, condition-02 satisfies.

Condition-03:
 According to condition-03, intersection of both the sub relations must be the super key of one of the two sub relations
or both.

So, we have-

R1 ( A , B ) ∩ R2 ( B , C )

=B

Now, the closure of attribute B is-

B+ = { B , C , D }

Now, we see-

 Attribute ‘B’ can not determine attribute ‘A’ of sub relation R1.
 Thus, it is not a super key of the sub relation R1.
 Attribute ‘B’ can determine all the attributes of sub relation R2.
 Thus, it is a super key of the sub relation R2.

Clearly, intersection of the sub relations is a super key of one of the sub relations.

So, condition-03 satisfies.

Thus, we conclude that the decomposition is lossless.

Conclusion-
Overall decomposition of relation R into sub relations R1, R2 and R3 is lossless.

Normalization in DBMS | Normal Forms

Database Management System
Normalization in DBMS-

In DBMS, database normalization is a process of making the database consistent by-

 Reducing the redundancies

 Ensuring the integrity of data through lossless decomposition
Normalization is done through normal forms.

Normal Forms-

The standard normal forms used are-

1. First Normal Form (1NF)
2. Second Normal Form (2NF)
3. Third Normal Form (3NF)
4. Boyce-Codd Normal Form (BCNF)

There exists several other normal forms even after BCNF but generally we normalize till BCNF only.

First Normal Form-

A given relation is called in First Normal Form (1NF) if each cell of the table contains only an atomic value.

OR

A given relation is called in First Normal Form (1NF) if the attribute of every tuple is either single valued or a null
value.

Example-

The following relation is not in 1NF-

Student_id Name Subjects

100 Akshay Computer Networks, Designing

101 Aman Database Management System

 102 Anjali Automata, Compiler Design

Relation is not in 1NF

However,

 This relation can be brought into 1NF.

 This can be done by rewriting the relation such that each cell of the table contains only one value.

Student_id Name Subjects

100 Akshay Computer Networks

100 Akshay Designing

101 Aman Database Management System

102 Anjali Automata

102 Anjali Compiler Design

Relation is in 1NF

This relation is in First Normal Form (1NF).

NOTE-

 By default, every relation is in 1NF.

 This is because formal definition of a relation states that value of all the attributes must be atomic.

Second Normal Form-

A given relation is called in Second Normal Form (2NF) if and only if-

1. Relation already exists in 1NF.

2. No partial dependency exists in the relation.
 Also read- Functional Dependency in DBMS

Partial Dependency

A partial dependency is a dependency where few attributes of the candidate key determines non-prime attribute(s).

OR

A partial dependency is a dependency where a portion of the candidate key or incomplete candidate key determines non-prime
attribute(s).

In other words,

A → B is called a partial dependency if and only if-

1. A is a subset of some candidate key

2. B is a non-prime attribute.
If any one condition fails, then it will not be a partial dependency.

NOTE-

 To avoid partial dependency, incomplete candidate key must not determine any non-prime attribute.
 However, incomplete candidate key can determine prime attributes.

Example-

Consider a relation- R ( V , W , X , Y , Z ) with functional dependencies-

VW → XY

Y→V

VWXY → Z

The possible candidate keys for this relation are-

VW , WX , WY

From here,

 Prime attributes = { V , W , X , Y }
 Non-prime attributes = { Z }

Now, if we observe the given dependencies-

 There is no partial dependency.
 This is because there exists no dependency where incomplete candidate key determines any non-prime attribute.

Thus, we conclude that the given relation is in 2NF.

Third Normal Form-

A given relation is called in Third Normal Form (3NF) if and only if-

1. Relation already exists in 2NF.

2. No transitive dependency exists for non-prime attributes.

Transitive Dependency

A → B is called a transitive dependency if and only if-

1. A is not a super key.

2. B is a non-prime attribute.
If any one condition fails, then it is not a transitive dependency.

NOTE-

 Transitive dependency must not exist for non-prime attributes.

 However, transitive dependency can exist for prime attributes.

OR

A relation is called in Third Normal Form (3NF) if and only if-

Any one condition holds for each non-trivial functional dependency A → B

1. A is a super key
2. B is a prime attribute

Example-

Consider a relation- R ( A , B , C , D , E ) with functional dependencies-

A → BC

CD → E

B→D
 E→A

B->C

The possible candidate keys for this relation are-

A , E , CD , BC

From here,

 Prime attributes = { A , B , C , D , E }
 There are no non-prime attributes

Now,

 It is clear that there are no non-prime attributes in the relation.

 In other words, all the attributes of relation are prime attributes.
 Thus, all the attributes on RHS of each functional dependency are prime attributes.

Thus, we conclude that the given relation is in 3NF.

Boyce-Codd Normal Form-

A given relation is called in BCNF if and only if-

1. Relation already exists in 3NF.

2. For each non-trivial functional dependency A → B, A is a super key of the relation.

Example-

Consider a relation- R ( A , B , C ) with the functional dependencies-

A→B

B→C

C→A

The possible candidate keys for this relation are-

A,B,C

Now, we can observe that RHS of each given functional dependency is a candidate key.

Thus, we conclude that the given relation is in BCNF.

 Normal Forms in Database | Important Points
Database Management System
Normal Forms in DBMS-

Before you go through this article, make sure that you have gone through the previous article on Normalization in
DBMS.

We have discussed-

 Database normalization is a process of making the database consistent.

 Normalization is done through normal forms.
 The standard normal forms generally used are-

In this article, we will discuss some important points about normal forms.

Point-01:

Remember the following diagram which implies-

 A relation in BCNF will surely be in all other normal forms.

 A relation in 3NF will surely be in 2NF and 1NF.
 A relation in 2NF will surely be in 1NF.
 Point-02:

The above diagram also implies-

 BCNF is stricter than 3NF.

 3NF is stricter than 2NF.
 2NF is stricter than 1NF.

Point-03:

While determining the normal form of any given relation,

 Start checking from BCNF.

 This is because if it is found to be in BCNF, then it will surely be in all other normal forms.
 If the relation is not in BCNF, then start moving towards the outer circles and check for other normal forms in the
order they appear.

Point-04:

 In a relational database, a relation is always in First Normal Form (1NF) at least.

Point-05:
 Singleton keys are those that consist of only a single attribute.
 If all the candidate keys of a relation are singleton candidate keys, then it will always be in 2NF at least.
 This is because there will be no chances of existing any partial dependency.
 The candidate keys will either fully appear or fully disappear from the dependencies.
 Thus, an incomplete candidate key will never determine a non-prime attribute.

Also read- Types of Keys in DBMS

Point-06:

 If all the attributes of a relation are prime attributes, then it will always be in 2NF at least.
 This is because there will be no chances of existing any partial dependency.
 Since there are no non-prime attributes, there will be no Functional Dependency which determines a non-prime
attribute.

Point-07:

 If all the attributes of a relation are prime attributes, then it will always be in 3NF at least.
 This is because there will be no chances of existing any transitive dependency for non-prime attributes.

Point-08:

 Third Normal Form (3NF) is considered adequate for normal relational database design.

Point-09:

 Every binary relation (a relation with only two attributes) is always in BCNF.

Point-10:

 BCNF is free from redundancies arising out of functional dependencies (zero redundancy).

Point-11:

 A relation with only trivial functional dependencies is always in BCNF.

 In other words, a relation with no non-trivial functional dependencies is always in BCNF.

Point-12:
 BCNF decomposition is always lossless but not always dependency preserving.

Point-13:

 Sometimes, going for BCNF may not preserve functional dependencies.

 So, go for BCNF only if the lost functional dependencies are not required else normalize till 3NF only.

Point-14:

 There exist many more normal forms even after BCNF like 4NF and more.
 But in the real world database systems, it is generally not required to go beyond BCNF.

Point-15:

 Lossy decomposition is not allowed in 2NF, 3NF and BCNF.

 So, if the decomposition of a relation has been done in such a way that it is lossy, then the decomposition will never
be in 2NF, 3NF and BCNF.

Point-16:

 Unlike BCNF, Lossless and dependency preserving decomposition into 3NF and 2NF is always possible.

Point-17:

 A prime attribute can be transitively dependent on a key in a 3NF relation.

 A prime attribute can not be transitively dependent on a key in a BCNF relation.

Point-18:

 If a relation consists of only singleton candidate keys and it is in 3NF, then it must also be in BCNF.

Point-19:

 If a relation consists of only one candidate key and it is in 3NF, then the relation must also be in BCNF.