0% found this document useful (0 votes)
26 views76 pages

Dbms Chapter 4

The document discusses functional dependencies (FDs) in database design. It defines an FD as a relationship between attributes in a relation where values of one attribute determine values of another. The document outlines different types of FDs such as full, partial, transitive, and trivial. It also explains Armstrong's axioms which are rules used to infer FDs, including reflexivity, transitivity, and decomposition. Finally, it discusses closure sets which represent all attributes derivable from a given attribute based on a set of FDs.

Uploaded by

GplsHub.com
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views76 pages

Dbms Chapter 4

The document discusses functional dependencies (FDs) in database design. It defines an FD as a relationship between attributes in a relation where values of one attribute determine values of another. The document outlines different types of FDs such as full, partial, transitive, and trivial. It also explains Armstrong's axioms which are rules used to infer FDs, including reflexivity, transitivity, and decomposition. Finally, it discusses closure sets which represent all attributes derivable from a given attribute based on a set of FDs.

Uploaded by

GplsHub.com
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 76

 Database Management Systems (DBMS)

Unit-4
Constraints and Normalization

Sr. Lec. Sujan Shrestha


9801104103
[email protected]
 Outline
Looping
• Functional Dependency
• Definition and types of FD
• Armstrong's axioms (inference rules)
• Closure of FD set
• Closure of attribute set
• Decomposition and its types
• Anomaly in database design and its types
• Normalization and normal forms
• 1NF
• 2NF
• 3NF
• BCNF
• 4NF
What is Functional Dependency (FD)?
 Let R be a relation schema having n attributes A1, A2, A3,…, An.

Student
RollNo Name SPI BL
101 Raju 8 0

102 ram 7 1

103 Jay 7 0

 Let attributes X and Y are two subsets of attributes of relation R.


 If the values of the X component of a tuple uniquely (or functionally) determine the values of the Y
component, then there is a functional dependency from X to Y.
 This is denoted by X → Y (i.e RollNo → Name, SPI, BL).
 It is referred as: Y is functionally dependent on the X or X functionally determines Y.
Diagrammatic representation of Functional Dependency (FD)

X→Y {X1, X2} → Y X → {Y1, Y2}

X Y X1 X2 Y X Y1 Y2

 Example
 Consider the relation Account(account_no, balance, branch).
 account_no can determine balance and branch.
 So, there is a functional dependency from account_no to balance and branch.
 This can be denoted by account_no → {balance, branch}.

account_no balance branch


Types of Functional Dependency (FD)
 Full Functional Dependency
 In a relation, the attribute B is fully functional dependent on A if B is functionally dependent on
A, but not on any proper subset of A.
 Eg. {Roll_No, Semester, Department_Name} → SPI
 We need all three {Roll_No, Semester, Department_Name} to find SPI.
 Partial Functional Dependency
 In a relation, the attribute B is partial functional dependent on A if B is functionally dependent
on A as well as on any proper subset of A.
 If there is some attribute that can be removed from A and the still dependency holds then it is
partial functional dependancy.
 Eg. {Enrollment_No, Department_Name} → SPI
 Enrollment_No is sufficient to find SPI, Department_Name is not required to find SPI.
Types of Functional Dependency (FD)
 Transitive Functional Dependency
 In a relation, if attribute(s) A → B and B → C, then A → C (means C is transitively depends on A via B).

Sub_Fac
Subject Faculty Age
DS Shah 35
DBMS singh 32
DF Shah 35

 Eg. Subject → Faculty & Faculty → Age then Subject → Age


 Therefore as per the rule of transitive dependency: Subject → Age should hold, that makes sense because if we know
the subject name we can know the faculty’s age.
Types of Functional Dependency (FD)
 Trivial Functional Dependency
 X → Y is trivial FD if Y is a subset of X
 Eg. {Roll_No, Department_Name, Semester} → Roll_No
 Nontrivial Functional Dependency
 X → Y is nontrivial FD if Y is not a subset of X
 Eg. {Roll_No, Department_Name, Semester} → Student_Name
Functional dependency
x Y
1 1 x Y
2 1 1 1
3 2 2 1
4 3 3 2
4 3
FD : x  y 2 5
determinant dependent
If tuple1.x = tuple2.x then tuple1.y = tuple2.y FD : x  y
SID S_name Cid Cname FID Fname Salary
1 Bibek C1 DBMS F1 Sujan 130000
1 Bibek C1 DBMS F3 Bison 145000 Sid  S_name
Cid  Cname
2 Simran C2 OS F2 Ritu 70000 FID  Fname, salary
3 Sanjeev C2 OS F2 Ritu 70000
4 Rajani C1 DBMS F1 Sujan 130000
5 Sanjay C1 DBMS F3 Bison 145000
6 Bibek C3 NM F4 Dhawa 100000
Roll_no name marks dept Course
1 A 78 BCA C1
2 B 60 CS C1
3 A 78 BCT C1
4 B 60 BEX C1
5 C 80 BCT C2
6 D 80 BCA C2

FD : x  y
If tuple1.x = tuple2.x then tuple1.y = tuple2.y

Roll_no  name yes name  marks yes


Name  Roll_no no name  dept no
Roll_no  marks yes marks  dept
no
Roll_no  dept yes
Roll_no  course yes Roll_no,name  marks yes

name ,marks  dept no


Armstrong’s S.N. roll_no name Marks dept course
1 1 A 78 CS C1
Axioms/inference rules 2 2 B 60 EE C1
3 3 A 78 CS C2
4 4 B 60 EE C3
5 5 C 80 IT C2
6 6 D 81 EC C4
7

Reflexivity : X X or X Y, Y is subset of X S.N.  roll_no

transitivity : If (X Y and Y Z ) then X Z name  marks, marksdept then name dept

Augmentation: If X Y then XA YA roll_no  marks then roll_no, name  marks, name

Union : if X Y and X Z then X YZ roll_no  marks ,roll_no name then roll_no  marks, name

Decomposition/splitting : if X YZ then X Y and X Z name  (marks ,dept) then name dept, name  marks

Pseudo transitivity : if X Y and YZA then XZ A


Roll_no  marks, marks, name dept then roll_no, name  dept
composition : if X Y and AB then XA YB
Armstrong's axioms OR Inference rules
 Armstrong's axioms are a set of rules used to infer (derive) all the functional dependencies on a relational database.

Reflexivity Augmentation Self-determination

 If B is a subset of A  If A → B  If A → A
 then A → B  then AC → BC

Transitivity Pseudo Transitivity Decomposition

 If A → B and B → C  If A → B and BD → C  If A → BC
 then A → B and A →
 then A → C  then AD → C C

Union Composition

 If A → B and A → C  If A → B and C → D
 then A → BC  then AC → BD
DD
Attribute Closure/Closure set DE
R(A,B,C,D,E) DDE
DABC EE
Attribute closure of certain attribute is a set FD: {AB, BC, CD, DE} EABCD
of all attribute that can be derived by that CC
attribute. AA BB CD
AB BC CE
AC BD CCDE
AD BE CAB
AE BBCDE
AABCD BA
A+ = {A, B, C, D, E} E
B+ = {B, C, D, E}
AD+ = {A, D, B, C, E} A, AD, ACD
ACD+ = {A, C, D, B, E} CD+ ={C,D,E} B, BD, CD are not super keys

Super key - set of all attribute whose attribute closure contains all the attributes of given relation
Candidate key – proper subsets of a super key are not super keys then it is a candidate key
A doesn’t have proper subset so it is a candidate key
AD – A, D. here A is super key so AD is not a candidate key
R(A,B,C,D,E}
FD: {AB,
DE}

Attribute Closure Super key


A+ = {A, B} ABCDE+ = {A,B,C,D,E}
BC+ = {B, C}
ABDE+ = {A, B, D, E}
ABD+ = {A, B, D, E}
ACD+ = {A, C, D, B, E} ACDE+ = {A, C, D, E, B}

ADE+ = {A, D, E, B}

This is a candidate key ACD+ = {A, C, D, B, E}

AD+ = {A, D, B, E} CD+ = {C, D, E} C+ = {C}

AC+ = {A, C,B} A+ = {A, B} D+ = {D, E}


Find all candidate keys in the relation??
R(A,B,C,D,E}
FD: {AB, DE}
A B C D E + = {A, B, C, D, E} Check functional dependencies

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

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

A C D + = {A, C, D, B , E}
Now check for its proper subset
AC, AD, CD, A, C, D
Prime attributes :- those attribute which are part of candidate key
Prime attributes :- A, C, D

Find all candidate keys in the relation??


If there are no prime attribute in the right hand side of FD then there are no more candidate keys
A C D is the only candidate key
R(A, B, C, D)
FD : {AB, BC, CA}
Find all candidate keys in the relation??

Sk A B C D+ = {A, B, C, D}

Sk A B C D+ = {A, C, D, B}

Sk A C D+ = {A, D, B, C}

Sk A D+ = {A, D, B, C}
A + = {A, B, C}
D + = {D}
Prime attributes :- A D
C D
C + = {C, A, B}
C D is a candidate key B D
B + = {B, C, A}
Prime attributes :- A C D
B D is a candidate key Here, AD, BD, CD are candidate
keys and A, B, C, D are prime
Prime attributes :- A B C D
attributes
R(A, B, C, D)
F D: {AB CD, DB, CA}

Find all candidate keys and prime attributes???


Find all candidate key and prime
attributes
R(A, B, C, D, E, F}
FD: {ABC, CDE, EF, DA, CB}
R(A, B, C, D, E, F} C is a candidate key
FD: {ABC, CDE, EF, DA, CB}
Prime attributes are A, B, D, C
A B C D E F + = {A, B, C, D, E, F} C DE = CD, CE

A B C D E F + = {A, B, D, E, F, C} CB
C + ={C, D, E, F, A, B}
A B C D E F + = {A, B, F, C, D, E} C B is not a candidate key
SK A B C D E F + = {A, B, C, D, E, F} Prime attributes are A, B, D, C
A + = {A} AB
B + = {B} We don’t need to go further
A B is a candidate key
Prime attribute are A, B
DB
D + ={D, A}
Prime attributes are A, B, C, D
D B is a candidate key Non prime attributes are E and F
Prime attribute are A, B, D
AC Candidate keys are
C + ={C, D, E, F, A, B} AB, DB, C
There are all attributes so A C is a super key so AC is not a candidate key
R(ABCDEFGH)

FD :- (ABC DE, EGH, HG, GH, ABCD EF)


What is decomposition?
 Decomposition is the process of breaking down given relation into two or more
relations.
 Relation R is replaced by two or more relations in such a way that:
 Each new relation contains a subset of the attributes of R
 Together, they all include all tuples and attributes of R
 Types of decomposition
 Lossy decomposition
 Lossless decomposition (non-loss decomposition)
Lossy decomposition
 The decomposition of relation R into R1 and R2 is lossy when the join of Customer
R1 and R2 does not yield the same relation as in R.
Ano Balance Bname
 This is also referred as lossy-join decomposition.
A01 5000 kat
 The disadvantage of such kind of decomposition is that some information
is lost during retrieval of original relation. A02 5000 pok
 From practical point of view, decomposition should not be lossy
decomposition. Table-1 Table-2
Ano Balance Balance Bname
Not Same
A01 5000 5000 kat
A02 5000 5000 pok

Customer
Ano Balance Bname
A01 5000 kat
A01 5000 pok
A02 5000 kat
A02 5000 pok
Lossless decomposition
 The decomposition of relation R into R1 and R2 is lossless when Customer
the join of R1 and R2 produces the same relation as in R. Ano Balance Bname
 This is also referred as a non-additive (non-loss) decomposition.
A01 5000 kat
 All decompositions must be lossless.
A02 5000 pok

Table-1 Table-2
Ano Balance Ano Bname
A01 5000 Same A01 kat
A02 5000 A02 pok

Customer
Ano Balance Bname
A01 5000 kat
A02 5000 pok
Dependency Preserving Decomposition

Here, R1(A,B) and R2(B,C)


R = (A, B, C)
(1, 1, 1) R1= (A, B) R2= (B, C)
(2, 1, 2) (1, 1) (1, 1)
(3, 2, 1) (2, 1) (1, 2)
(4, 2, 2) (3, 2) (2, 1)
FD:- A B, A  C (4, 2) (2, 2)

FD:- A  B C
FD:- A B FD:-

FD1 union FD2

FD:- A B

This is not dependency preserving


Dependency Preserving decomposition

Here, R1(A,B) and R2(A,C)


R = (A, B, C)
(1, 1, 1) R1= (A, B) R1= (A, C)
(2, 1, 2) (1, 1) (1, 1)
(3, 2, 1) (2, 1) (2, 2)
(4, 2, 2) (3, 2) (3, 1)
FD:- A B, A  C (4, 2) (4, 2)

FD:- A  B C
FD:- A B FD:- A  C

FD1 union FD2

FD:- A B, A C

This is dependency preserving


Dependency Preserving

Here, R1(A,B,C) and R2(C, D, E)


R = (A, B, C, D, E)
R1= (A, B,C) R1= (C, D, E)
FD:- A B, B  C, C D, D A

A  BC FD:- C D, D C
A+ = {A, B, C, D} B  CA
B+ = {B,C,D,A} C AB
C+ = {C,D,A,B}
FD1 union FD2

FD:- A  BC, B  CA, C AB, C D, D C

This is dependency preserving


Lossless-join decomposition
• Lossless-join decomposition is a process in which a relation is decomposed
into two or more relations.
• This property guarantees that the extra or less tuple generation problem
does not occur and no information is lost from the original relation during the
decomposition. It is also known as non-additive join decomposition.
• When the sub relations combine again then the new relation must be the
same as the original relation was before decomposition.
• Consider a relation R if we decomposed it into sub-parts relation R1 and
relation R2.
• The decomposition is lossless when it satisfies the following statement −
•If we union the sub Relation R1 and R2 then it must contain
all the attributes that are available in the original relation R
before decomposition.
•Intersections of R1 and R2 cannot be Null. The sub relation
must contain a common attribute. The common attribute
must contain unique data.
• The common attribute must be a super key of sub relations
either R1 or R2.
Here, R1= (A, B) R2= (B, C)
R = (A, B, C) (1, 1) (1, 1)
(1, 1, 1) (2, 1) (1, 2)
(2, 1, 2) (3, 2) (2, 1)
(3, 2, 1) (4, 2) (2, 2)
(4, 3, 2)

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

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


R1 ( A, B) (1, 1) (1, 1)
R2 ( A, C) (2, 1) (2, 2)
(3, 2) (3, 1)
(4, 2) (4, 2)
R = (A, B, C) R = (A, B, C, D, E)
(1, 1, 3) (1, 1, 2, 1, 3)
(2, 1, 3) (2, 2, 2, 1, 3)
(3, 2, 6) (3, 1, 6, 3, 6)
(4, 3, 7) (4, 2, 8, 5, 7)
(5, 3, 9, 5, 7)
i) R1 ( A, B) R2 ( B, C)
i) R1 ( A, B,C) R2 ( D, E)

ii) R1 (A,B,C) R2(A,B,D,E)

iii) R1(A,B) R2(C,D) R3(D,E)


What is an anomaly in database design?
 Anomalies are problems that can occur in poorly planned, un-normalized database where all the data are
stored in one table.
 There are three types of anomalies that can arise in the database because of redundancy are
 Insert anomaly
 Delete anomaly
 Update / Modification anomaly
Insert anomaly
 Consider a relation Emp_Dept(EID, Ename, City, DID, Dname, Manager) EID as a primary key

Emp_Dept
EID Ename City DID Dname Manager
An insert anomaly occurs when certain attributes cannot be
1 Raj kat 1 CE Shah
inserted into the database without the presence of another
2 ravi pok 1 CE Shah attribute.
NULL NULL NULL 2 IT NULL
Want to insert new department detail
(IT)

 Suppose a new department (IT) has been started by the organization but initially there is no employee
appointed for that department.
 We want to insert that department detail in Emp_Dept table.
 But the tuple for this department cannot be inserted into this table as the EID will have NULL value,
which is not allowed because EID is primary key.
 This kind of problem in the relation where some tuple cannot be inserted is known as insert anomaly.
Delete anomaly
 Consider a relation Emp_Dept(EID, Ename, City, DID, Dname, Manager) EID as a primary key
Emp_Dept

EID Ename City DID Dname Manager


A delete anomaly exists when certain attributes are lost
1 Raj kat 1 CE Shah because of the deletion of another attribute.
2 ravi pok 1 CE Shah
Want to delete (Jay)
3 Jay birat 2 IT KC employee's detail

 Now consider there is only one employee in some department (IT) and that employee
leaves the organization.
 So we need to delete tuple of that employee (Jay).
 But in addition to that information about the department also deleted.
 This kind of problem in the relation where deletion of some tuples can lead to loss of some
other data not intended to be removed is known as delete anomaly.
Update anomaly
 Consider a relation Emp_Dept(EID, Ename, City, Dname, Manager) EID as a primary key
Emp_Dept

EID Ename City Dname Manager


1 Raj kat CE Sah An update anomaly exists when one or more records
(instance) of duplicated data is updated, but not all.
2 ravi pok C.E Shah

3 Jay birat Computer Shaah


Want to update manager
4 Hari kat IT KC of CE department
 Suppose the manager of a (CE) department has changed, this requires that the Manager in
all the tuples corresponding to that department must be changed to reflect the new
status.
 If we fail to update all the tuples of given department, then two different records of
employee working in the same department might show different Manager lead to
inconsistency in the database.
How to deal with insert, delete and update anomaly
Emp_Dept Emp Dept
EID Ename City DID Dname Manager EID Ename City DID DID Dname Manager
1 Raj kat 1 CE Shah 1 Raj kat 1 1 CE Shah

2 ravi pok 1 C.E Shah 2 ravi pok 1 2 IT KC


3 Jay birat 2 IT KC 3 Jay birat 2 3 EC NULL
NULL NULL NULL 3 EC NULL

Such type of anomalies in the database design can be solved by using


normalization.
Sr. Lec. Sujan Shrestha
9801104103
[email protected]
What is normalization?
 Normalization is the process of removing redundant data from tables to improve data integrity, scalability
and storage efficiency.
 data integrity (completeness, accuracy and consistency of data)
 scalability (ability of a system to continue to function well in a growing amount of work)
 storage efficiency (ability to store and manage data that consumes the least amount of space)

 What we do in normalization?
 Normalization generally involves splitting an existing table into multiple (more than one) tables, which can be re-
joined or linked each time a query is issued (executed).
How many normal forms are there?
 Normal forms:
 1NF (First normal form)
 2NF (Second normal form)
 3NF (Third normal form)
 BCNF (Boyce–Codd normal form)
 4NF (Forth normal form)

As we move from 1NF to 4NF number of tables and complexity increases


but redundancy decreases.
1NF (First Normal Form)
1NF (First Normal Form)
 Conditions for 1NF

Each cells of a table should contain a


single value.

 A relation R is in first normal form (1NF) if and only if it does not contain any composite
attribute or multi-valued attributes or their combinations.
OR
 A relation R is in first normal form (1NF) if and only if all underlying domains contain
atomic values only.
1NF (First Normal Form) [Example - Composite attribute]
Customer
CID Name Address
• In customer relation address is
C01 Raju kalimati Road, kat composite attribute which is
C02 ram kec galli, kalimati further divided into sub-attributes
as “Road” and “City”.
C03 Jay prithivi chwok, pok
• So customer relation is not in 1NF.

 Problem: It is difficult to retrieve the list of customers living in ’kalimati’ city from customer
table.
 The reason is that address attribute is composite attribute which contains road name as well
as city name in single cell.
 It is possible that city name word is also there in road name.
 In our example, ’kalimati’ word occurs in both records, in first record it is a part of road name
and in second one it is the name of city.
1NF (First Normal Form) [Example - Composite attribute]
Customer Customer
CID Name Address CID Name Road City
C01 Raju kalimati Road, kat C01 Raju kalimati Road kat

C02 ram kec galli, kalimati C02 ram kec galli kalimati

C03 Jay prithivi chwok, pok C03 Jay prithivi chwok pok

 Solution: Divide composite attributes into number of sub-attributes and insert


value in proper sub-attribute.

Exercise Convert below relation into 1NF (First Normal Form)

Person
PID Full_Name City
P01 Raju Maheshbhai singh kat
1NF (First Normal Form) [Example - Multivalued attribute]
Student
Rno Name FailedinSubjects
101 Raju DS, DBMS • In student relation FailedinSubjects
attribute is a multi-valued attribute
102 ram DBMS, DS
which can store more than one values.
103 Jay DS, DBMS, DE • So above relation is not in 1NF.
104 laxman DBMS, DE, DS

105 ravi DE, DBMS, DS

106 gaurav DE, DBMS

 Problem: It is difficult to retrieve the list of students failed in ’DBMS’ as well as ’DS’ but not
in other subjects from student table.
 The reason is that FailedinSubjects attribute is multi-valued attribute so it contains more than
one value.
1NF (First Normal Form) [Example - Multivalued attribute]
Student Student Result
Rno Name FailedinSubjects Rno Name RID Rno Subject
101 Raju DS, DBMS 101 Raju 1 101 DS
102 ram DBMS, DS 102 ram 2 101 DBMS
103 Jay DS, DBMS, DE 103 Jay 3 102 DBMS
104 laxman DBMS, DE, DS 104 laxman 4 102 DS
105 ravi DE, DBMS, DS 105 ravi 5 103 DS
106 gaurav DE, DBMS 106 gaurav … … …

 Solution: Split the table into two tables in such as way that
 the first table contains all attributes except multi-valued attribute with same primary key and
 second table contains multi-valued attribute and place a primary key in it.
 insert the primary key of first table in the second table as a foreign key.
2NF (Second Normal Form)
2NF (Second Normal Form)
 Conditions for 2NF

It is in 1NF and each table should contain a single


primary key.

 A relation R is in second normal form (2NF)


 if and only if it is in 1NF and
 every non-primary key attribute is fully dependent on the primary key
OR
 A relation R is in second normal form (2NF)
 if and only if it is in 1NF and
 no any non-primary key attribute is partially dependent on the primary key
2NF (Second Normal Form) [Example]
Customer
FD2
CID ANO AccessDate Balance BranchName
C01 A01 01-01-2017 50000 kat
CID ANO AccesssDate Balance BranchName
C02 A01 01-03-2017 50000 kat

C01 A02 01-05-2017 25000 pok

C03 A02 01-07-2017 25000 pok FD1

 FD1: {CID, ANO} → {AccesssDate, Balance, BranchName}


 FD2: ANO → {Balance, BranchName}
 Balance and BranchName are partial dependent on primary key (CID + ANO). So customer relation is not in
2NF.
2NF (Second Normal Form) [Example]
Customer
FD2
CID ANO AccessDate Balance BranchName
C01 A01 01-01-2017 50000 kat
CID ANO AccesssDate Balance BranchName
C02 A01 01-03-2017 50000 kat

C01 A02 01-05-2017 25000 pok

C03 A02 01-07-2017 25000 pok FD1

 Problem: For example, in case of a joint account multiple (more than one) customers have common (one)
accounts.
 If an account ’A01’ is operated jointly by two customers says ’C01’ and ’C02’ then data values for
attributes Balance and BranchName will be duplicated in two different tuples of customers ’C01’ and ’C02’.
2NF (Second Normal Form) [Example]
Customer Table-1 Table-2
CID ANO AccessDate Balance BranchName ANO Balance BranchName CID ANO AccessDate
C01 A01 01-01-2017 50000 kat A01 50000 kat C01 A01 01-01-2017

C02 A01 01-03-2017 50000 kat A02 25000 pok C02 A01 01-03-2017

C01 A02 01-05-2017 25000 pok C01 A02 01-05-2017

C03 A02 01-07-2017 25000 pok C03 A02 01-07-2017

 Solution: Decompose relation in such a way that resultant relations do not have any partial FD.
 Remove partial dependent attributes from the relation that violets 2NF.
 Place them in separate relation along with the prime attribute on which they are fully dependent.
 The primary key of new relation will be the attribute on which it is fully dependent.
 Keep other attributes same as in that table with the same primary key.
3NF (Third Normal Form)
3NF (Third Normal Form)
 Conditions for 3NF

It is in 2NF and there is no transitive dependency.

(Transitive dependency???) A → B & B → C then A → C

 A relation R is in third normal form (3NF)


 if and only if it is in 2NF and
 every non-key attribute is non-transitively dependent on the primary key
OR
 A relation R is in third normal form (3NF)
 if and only if it is in 2NF and
 no any non-key attribute is transitively dependent on the primary key
3NF (Third Normal Form) [Example]
Customer
FD2
ANO Balance BranchName BranchAddress
A01 50000 kat Kalmati
ANO Balance BranchName BranchAddress
A02 40000 kat Kalmati

A03 35000 pok prithivi chwok

A04 25000 pok prithivi chwok


FD1

 FD1: ANO → {Balance, BranchName, BranchAddress}


 FD2: BranchName → BranchAddress
 So AccountNO → BranchAddress (Using Transitivity rule)
 BranchAddress is transitive depend on primary key (ANO). So customer relation is not in 3NF.
3NF (Third Normal Form) [Example]
Customer
FD2
ANO Balance BranchName BranchAddress
A01 50000 kat Kalmati
ANO Balance BranchName BranchAddress
A02 40000 kat Kalmati

A03 35000 pok prithivi chwok

A04 25000 pok prithivi chwok


FD1

 Problem: In this relation, branch address will be stored repeatedly for each account of the same branch
which occupies more space.
3NF (Third Normal Form) [Example]
Customer Table-1 Table-2
ANO Balance BranchName BranchAddress BranchName BranchAddress ANO Balance BranchName
A01 50000 kat Kalmati kat Kalmati A01 50000 kat

A02 40000 kat Kalmati pok prithivi chwok A02 40000 kat

A03 35000 pok prithivi chwok A03 35000 pok

A04 25000 pok prithivi chwok A04 25000 pok

 Solution: Decompose relation in such a way that resultant relations do not have any
transitive FD.
 Remove transitive dependent attributes from the relation that violets 3NF.
 Place them in a new relation along with the non-prime attributes due to which transitive
dependency occurred.
 The primary key of the new relation will be non-prime attributes due to which transitive
dependency occurred.
 Keep other attributes same as in the table with same primary key and add prime attributes
of other relation into it as a foreign key.
BCNF (Boyce-Codd Normal Form)
BCNF (Boyce-Codd Normal Form)
Primary Determinant Dependent
 Conditions for BCNF
Key
BCNF is based on the concept of a determinant. AccountNO → {Balance, Branch}

It is in 3NF and every determinant should be primary key.

 A relation R is in Boyce-Codd normal form (BCNF)


 if and only if it is in 3NF and
 for every functional dependency X → Y, X should be the primary key of the table. OR
 A relation R is in Boyce-Codd normal form (BCNF)
 if and only if it is in 3NF and
 every prime key attribute is non-transitively dependent on the primary key OR
 A relation R is in Boyce-Codd normal form (BCNF)
 if and only if it is in 3NF and

 no any prime key attribute is transitively dependent on the primary key


BCNF (Boyce-Codd Normal Form) [Example]
Student FD1
RNO Subject Faculty • FD1: RNO, Subject → Faculty
101 DS singh RNO Subject Faculty • FD2: Faculty → Subject
102 DBMS Shah • So {RNO, Subject} → Subject (Transitivity rule)
103 DS kc FD2
104 DBMS KC
In FD2, determinant is Faculty which is not a primary key. So student table is not
105 DBMS Shah in BCNF.
102 DS singh

101 DBMS KC Problem: In this relation one student can learn more than one subject with
different faculty then records will be stored repeatedly for each student,
105 DS kc
language and faculty combination which occupies more space.

• Here, one faculty teaches only one subject, but a subject may
be taught by more than one faculty.
• A student can learn a subject from only one faculty.
BCNF (Boyce-Codd Normal Form) [Example]
Student Table-1 Table-2
RNO Subject Faculty Faculty Subject RNO Faculty
101 DS singh singh DS 101 singh • Solution: Decompose relation in such a
102 DBMS Shah Shah DBMS 102 Shah way that resultant relations do not have
any transitive FD.
103 DS kc kc DS 103 kc • Remove transitive dependent prime
attribute from relation that violets BCNF.
104 DBMS KC KC DBMS 104 KC
• Place them in separate new relation along
105 DBMS Shah 105 Shah with the non-prime attribute due to which
transitive dependency occurred.
102 DS singh 102 singh • The primary key of new relation will be this
non-prime attribute due to which transitive
101 DBMS KC 101 KC
dependency occurred.
105 DS kc 105 kc • Keep other attributes same as in that table
with same primary key and add a prime
attribute of other relation into it as a
foreign key.
Multivalued dependency (MVD)
 For a dependency X → Y, if for a single value of X, multiple values of Y exists, then
the table may have multi-valued dependency.

Student
RNO Subject Faculty
101 DS singh

101 DBMS singh

101 DS Shah

101 DBMS Shah

 Multivalued dependency (MVD) is denoted by →→


 Multivalued dependency (MVD) is represented as X →→ Y
4NF (Forth Normal Form)
4NF (Forth Normal Form)
 Conditions for 4NF
 A relation R is in fourth normal form (4NF)
 if and only if it is in BCNF and
 has no multivalued dependencies

Student Subject Faculty


RNO Subject Faculty RNO Subject RNO Faculty
101 DS singh 101 DS 101 singh
101 DBMS singh 101 DBMS 101 Shah
101 DS Shah

101 DBMS Shah

 Above student table has multivalued dependency. So student table is not in 4NF.
Functional dependency & Multivalued dependency
 A table can have both functional dependency as well as multi-valued dependency together.
 RNO → Address
 RNO →→ Subject
 RNO →→ Faculty

Student Subject Faculty Address


RNO Address Subject Faculty RNO Subject RNO Faculty RNO Address
101 kalimati Road, kat DS singh 101 DS 101 singh 101 kalimati Road, kat
101 kalimati Road, kat DBMS singh 101 DBMS 101 Shah
101 kalimati Road, kat DS Shah

101 kalimati Road, kat DBMS Shah


How to find key?
 Conditions to find key
 The attribute is a part of key, if it does not occur on any side of FD
 The attribute is a part of key, if it occurs on the left-hand side of an FD, but never
occurs on the right-hand side
 The attribute is not a part of key, if it occurs on the right-hand side of an FD, but never
occurs on the left-hand side
 The attribute may be a part of key or not, if it occurs on the both side of an FD
How to find key? [Example]
 Let a relation R with attributes ABCD with FDs C → A, B → C. Find keys for relation R.
 attribute not occur on any side of FDs (D) √
 attribute occurs on only left-hand side of an FDs (B) √
 attribute occurs on only right-hand side of an FDs (A) X
 attribute occurs on both the sides of an FDs (C) ?
 The core is BD.
 B determines C and C determines A, So using transitivity rule B determines A also.
 So BD is a key.
How to find key? [Exercise]
 Let a relation R with attributes ABCD with FDs C → D, C → A and B → C. Find keys for relation R.
 The core is B. B determines C which determines A and D, so B is a key. Therefore B is the key.

 Let a relation R with attributes ABCD with FDs B → C, D → A. Find keys for relation R.
 The core is BD. B determines C and D determines A, so BD is a key. Therefore BD is the key.

 Let a relation R with attributes ABCD with FDs A → B, BC → D and A → C. Find keys for relation R.
 The core is A. A determines B and C which determine D, so A is a key. Therefore A is the key.
Find (candidate) key & check for normal forms [Example]

 Suppose you are given a relation R with four attributes ABCD. For each of the following sets of FDs,
do the following: F = (B → C, D → A)

 Identify the candidate key(s) for R.

 Identify the best normal form that R satisfies (1NF, 2NF, 3NF or BCNF).

Candidate Key is BD

Relation R is in 1NF but not 2NF. In above FDs, there is a partial dependency
(As per FD B → C, C depends only on B but Key is BD so C is partial depends on key (BD))
(As per FD D → A, A depends only on D but Key is BD so A is partial depends on key (BD))
Find (candidate) key & check for normal forms [Example]
 Suppose you are given a relation R with four attributes ABCD. For each of the following sets of FDs,
do the following: F = (C → D, C → A, B → C)

 Identify the candidate key(s) for R.

 Identify the best normal form that R satisfies (1NF, 2NF, 3NF or BCNF).

Candidate Key is B

Relation R is in 2NF but not 3NF. In above FDs, there is a transitive dependency
(As per FDs B → C & C → D then B → D so D is transitive depends on key (B))
(As per FDs B → C & C → A then B → A so A is transitive depends on key (B))
Find (candidate) key & check for normal forms [Example]
 Suppose you are given a relation R with four attributes ABCD. For each of the following sets of FDs,
do the following: F = (A → B, BC → D, A → C)

 Identify the candidate key(s) for R.

 Identify the best normal form that R satisfies (1NF, 2NF, 3NF or BCNF).

Candidate Key is A

Relation R is in 2NF but not 3NF. In above FDs, there is a transitive dependency
(As per FDs A → B & A → C then A → BC using union rule) and
(As per FDs A → BC & BC → D then A → D so D is transitive depends on key (A))
Find (candidate) key & check for normal forms [Example]
 Suppose you are given a relation R with four attributes ABCD. For each of the following sets of FDs,
do the following: F = (ABC → D, D → A)

 Identify the candidate key(s) for R.

 Identify the best normal form that R satisfies (1NF, 2NF, 3NF or BCNF).

Candidate Key are ABC &


BCD

Relation R is in 3NF but not BCNF.


In the above FDs, both FDs have prime attribute (D and A) in dependent (right) side.
How to normalize database?
 A software contract and consultancy firm maintains details of all
the various projects in which its employees are currently
involved. These details comprise: Employee Number, Employee
Name, Date of Birth, Department Code, Department Name,
Project Code, Project Description, Project Supervisor.
 Assume the following:
 Each employee number is unique.
 Each department has a single department code.
 Each project has a single code and supervisor.
 Each employee may work on one or more projects.
 Employee names need not necessarily be unique.
 Project Code, Project Description and Project Supervisor are repeating
fields.
 Normalize this data to Third Normal Form.
How to normalize database?
 A software contract and consultancy firm maintains details of all the various projects
in which its employees are currently involved. These details comprise: Employee
Number, Employee Name, Date of Birth, Department Code, Department Name,
Project Code, Project Description, Project Supervisor.

UNF
Employee Employee Date of Department Department Project Project Project
Number Name Birth Code Name Code Description Supervisor
1 Raj 1-1-85 1 CE 1 IOT singh

2 ravi 4-4-86 2 EC 2 PHP Shah

3 Suresh 2-2-85 1 CE 1 IOT singh

1 Raj 1-1-85 1 CE 2 PHP Shah


Questions asked in TU
1. What is meant by normalization? Write its need. List and discuss various
normalization forms.
2. Consider schema EMPLOYEE(E-ID,E-NAME,E-CITY,E-STATE) and
FD = {E-ID → E-NAME, E-ID → E-CITY, E-ID → E-STATE, E-CITY → E-STATE}
 Find attribute closure for: (E-ID)+
3. Compute the closure of the following set F of functional dependencies for
relation schema R(A, B, C, D, E).
F = { A → BC, CD → E, B → D, E → A}
 List the candidate keys for R.
4. Consider schema R = (A, B, C, G, H, I) and the set F of functional dependencies
{A → B, A → C, CG → H, CG → I, B → H}. ( Use F+ )
 Prove that AG → I Holds.
Questions asked in TU
5. In the BCNF decomposition algorithm, suppose you use a functional dependency
α → β to decompose a relation schema r (α, β, γ) into r1 (α, β) and r2 (α, γ).
 What primary and foreign-key constraint do you expect to hold on the decomposed
relations?
 Give an example of an inconsistency that can arise due to an erroneous update, if
the foreign-key constraint were not enforced on the decomposed relations above.
 When a relation is decomposed into 3NF, what primary and foreign key
dependencies would you expect will hold on the decomposed schema?
6. A college maintains details of its lecturers' subject area skills. These details
comprise: Lecturer Number, Lecturer Name, Lecturer Grade, Department Code,
Department Name, Subject Code, Subject Name, Subject Level. Assume that
each lecturer may teach many subjects but may not belong to more than one
department. Subject Code, Subject Name and Subject Level are repeating
fields. Normalize this data to Third Normal Form.
Thank You

You might also like