DBMS - Unit-4 (Darshan) (VisionPapers - In)
DBMS - Unit-4 (Darshan) (VisionPapers - In)
GTU # 3130703
Unit-4
Relational Database
Design
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}.
Union Composition
If A → B and A → C If A → B and C → D
then A → BC then AC → BD
We have
A→B
Transitivity rule A→H
B→H
We have
CG → H
Union rule CG → HI
CG → I
We have
A→C Pseudo-
AG → I
CG → I transitivity rule
We have
A→C Augmentation rule AG → CG
AG → CG
Transitivity rule AG → I
CG → I
F+ = (A → BC, CD → EF, A → E, AD → E, AD → F)
F+ = (D → A, D → C, D → ACE)
Algorithm
Algorithm to compute α+, the closure of α under F
Steps
1. result = α
2. while (changes to result) do
for each β → γ in F do
▪ begin
• if β ⊆ result then result = result U γ
• else result = result
▪ end
Answer
A+ = ABCDE
CD+ = ABCDE
B+ = BD
BC+ = ABCDE
E+ = ABCDE
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 4 – Relational Database Design 24
Section – 4
What is extraneous attributes?
Let us consider a relation R with schema R = (A, B, C) and set of functional dependencies FDs
F = { AB → C, A → C }.
In AB → C, B is extraneous attribute. The reason is, there is another FD A → C, which means
when A alone can determine C, the use of B is unnecessary (extra).
An attribute of a functional dependency is said to be extraneous if we can remove it without
changing the closure of the set of functional dependencies.
F = {A → B, A → C}
Decomposition Rule Union Rule
Fc = {A → BC}
Customer
Ano Balance Bname
A01 5000 Rajkot
A02 5000 Surat
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.
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.
Such type of anomalies in the database design can be solved by using normalization.
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).
As we move from 1NF to 5NF number of tables and complexity increases but
redundancy decreases.
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.
Problem: It is difficult to retrieve the list of customers living in ’Jamnagar’ 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, ’Jamnagar’ 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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 4 – Relational Database Design 46
1NF (First Normal Form) [Example - Composite attribute]
Customer Customer
CID Name Address CID Name Road City
C01 Raju Jamnagar Road, Rajkot C01 Raju Jamnagar Road Rajkot
C02 Mitesh Nehru Road, Jamnagar C02 Mitesh Nehru Road Jamnagar
C03 Jay C.G Road, Ahmedabad C03 Jay C.G Road Ahmedabad
Solution: Divide composite attributes into number of sub-attributes and insert value in proper
sub-attribute.
Person
PID Full_Name City
P01 Raju Maheshbhai Patel Rajkot
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.
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.
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’.
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.
Problem: In this relation, branch address will be stored repeatedly for each account of the
same branch which occupies more space.
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 4 – Relational Database Design 59
BCNF (Boyce-Codd Normal Form)
Section – 7.4
BCNF (Boyce-Codd Normal Form)
Conditions for BCNF Primary Key Determinant Dependent
• 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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 4 – Relational Database Design 62
BCNF (Boyce-Codd Normal Form) [Example]
Student Table-1 Table-2 • Solution: Decompose relation in
RNO Subject Faculty Faculty Subject RNO Faculty such a way that resultant relations
101 DS Patel Patel DS 101 Patel do not have any transitive FD.
102 DBMS Shah Shah DBMS 102 Shah • Remove transitive dependent prime
attribute from relation that violets
103 DS Jadeja Jadeja DS 103 Jadeja
BCNF.
104 DBMS Dave Dave DBMS 104 Dave • Place them in separate new relation
105 DBMS Shah 105 Shah along with the non-prime attribute due
to which transitive dependency
102 DS Patel 102 Patel
occurred.
101 DBMS Dave 101 Dave • The primary key of new relation will be
105 DS Jadeja 105 Jadeja this non-prime attribute due to which
transitive dependency occurred.
• 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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 4 – Relational Database Design 63
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 Patel
101 DBMS Patel
101 DS Shah
101 DBMS Shah
Above student table has multivalued dependency. So student table is not in 4NF.
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.
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))
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))
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))
1NF
Employee Employee Date of Department Department Employee Project Project Project
Number Name Birth Code Name Number Code Description Supervisor
1 Raj 1-1-85 1 CE 1 1 IOT Patel
2 Meet 4-4-86 2 EC 2 2 PHP Shah
3 Suresh 2-2-85 1 CE 3 1 IOT Patel
1 2 PHP Shah
1NF
Employee Employee Date of Department Department Employee Project Project Project
Number Name Birth Code Name Number Code Description Supervisor
1 Raj 1-1-85 1 CE 1 1 IOT Patel
2 Meet 4-4-86 2 EC 2 2 PHP Shah
3 Suresh 2-2-85 1 CE 3 1 IOT Patel
1 2 PHP Shah
2NF
Employee Employee Date of Department Department Project Project Project Employee Project
Number Name Birth Code Name Code Description Supervisor Number Code
1 Raj 1-1-85 1 CE 1 IOT Patel 1 1
2 Meet 4-4-86 2 EC 2 PHP Shah 2 2
3 Suresh 2-2-85 1 CE 3 1
1 2
3NF
Thank
You