Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
180 views

Assignment 5

This tutorial covers normalization of database relations by: 1) Identifying functional dependencies for sample schemas and real-life examples. 2) Finding candidate keys and attribute closures for functional dependencies. 3) Decomposing relations into BCNF and 3NF based on functional dependencies.

Uploaded by

Ram Prasad Reddy Sadi
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
180 views

Assignment 5

This tutorial covers normalization of database relations by: 1) Identifying functional dependencies for sample schemas and real-life examples. 2) Finding candidate keys and attribute closures for functional dependencies. 3) Decomposing relations into BCNF and 3NF based on functional dependencies.

Uploaded by

Ram Prasad Reddy Sadi
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 4

This tutorial has several parts.

In the first part we work on basic manipulation of functional


dependencies. Next, we use functional dependencies to normalize some toy relations into
BCNF/3NF. And finally, we take a real life example and figure out the functional
dependencies involved, and develop a normalized database design.
1. Functional dependencies: For each of the following sets of functional
dependencies on a schema r(A, B, C, D, E)
o Find a candidate key for this schema

o Find the attribute closure of AB

1. AB --> C, D --> E, B --> E

2. A --> CD, B --> DE

3. AB --> C, C --> D

Sol: Answers (all use the schema R(A,B,C,D,E)

1. For AB --> C, D --> E, B --> E


 A, B and D are not on the RHS of any FD, so they have to be part of
any candidate key. (ABD)+ contains all attributes, so it is a superkey,
and it is easy to see it is minimal. So ABD is a candidate key. In this
case it is the only candidate key.
Candidate key : ABD
Note: another way is to start with superkey ABCDE, and delete
attributes till no more attributes can be deleted without making it not
be a superkey. The result would be identical in this case.

 Closure of AB :first we add C, then E, final result is ABCE

2. For A --> CD, B --> DE

 Again A and B are not on the RHS of any functional dependency, so


they have to be part of every superkey/candidate key. (AB)+ includes
all attributes. Thus:
Candidate key : AB

 Closure of AB : first we add CD, then DE, to get final result of ABCDE

3. For AB --> C, C --> D

 A, B and E are not part of RHS of any FD, so they have to be part of
every superkey/candidate key. (ABE)+ contains all attributes. Thus:
Candidate key : ABE

 Closure of AB : First add C, then D to get final result of ABCD

2. Normalization 1: For each of the above set of functional dependencies, decompose


relation r into BCNF
Sol: 1. For AB --> C, D --> E, B --> E
First, AB-->C demonstrates violation of BCNF, so we decompose into ABC and ABDE.
After this there are two options:

o B-->E shows that ABDE needs to be decomposed to ABD and BE. Final tables
are: ABC,ABD,BE
o D-->E shows that ABDE needs to be decomposed to ABD and DE. Final tables
are: ABC,ABD,DE

2. For A --> CD, B --> DE:


There are two options:

1. First we decompose using A-->CD, to get ACD and ABE. Using B-->E
(inferred from B-->DE), we decompose ABE into AB and BE. 
Final tables are: ACD,BE, AB

2. First we decompose using B-->DE to get BDE and ABC. Using A-->C, we
decompose ABC into AC and AB. 
Final tables are: BDE, AC,AB

2. For AB --> C, C --> D: There are two options:

1. Using ABC to decompose, we get ABC and ABDE. Now from AB-->C and C--
>D we can infer AB-->D (or do the same by computing (AB)+ to get ABCD,
and intersecting with ABDE to get ABD). Using this functional dependency we
decompose again to get ABD and ABE.
Final tables are: ABC,ABD,ABE

2. Using C-->D to decompose, we get CD and ABCE. Using AB-->C, we get ABC
and ABE
Final tables: ABC, ABE and CD.

3. Normalization 2: For each of the following sets of functional dependencies on a


schema r(A, B, C, D, E), 

o Find the canonical cover by eliminating all extraneous attributes

o Decompose relation r into 3NF based on the canonical cover

1. A --> CD, B --> DE, C --> D

2. A --> B, B --> C, A --> C, D --> E, B --> E, AD --> E 

Sol: 1. For A --> CD, B --> DE, C --> D:


First, we find D extraneous in A-->CD, to get A-->C, B-->DE, C-->D.
Nothing more is found to be extraneous, so we get: 
Canonical cover : A->C,B->DE,C->D
From this canonical cover, we first create tables: AC,BDE,CD. We find none of the tables
includes a candidate key. Since A and B are not on the RHS of any FD, they have to be in
any candidate key, and further AB is easily checked to be a superkey. Thus, candidate
Key:AB.
We then add table AB to the above set of tables. 
The final set of tables is: AC, BDE, CD, AB 
Candidate Key:AB.

1. For A --> B, B --> C, A --> C, D --> E, B --> E, AD --> E 


First we merge A-->B and A-->C, and then we find C is extraneous, since we can use
A-->B and B-->C to infer A-->C. At this stage we have
A-->B, B-->C, D-->E, B-->E, AD-->E. Next, we find A is extraneous in AD-->E
(since we already have D-->E), and the result of deleting it is D-->E, which is
already present. Nothing more is extraneous. We union B-->C and B-->E, to get B--
>CE.
Thus, the canonical cover : A-->B,B-->CE,D-->E
From this we create tables:AB,BCE,DE. We compute closure of each of these sets of
attributes, but none of these contains all attributes of R. Thus we need to add a
candidate key. Now, A and D do not appear on the RHS of any FD, and have to be in
each candidate key. Also (AD)+ contains all attributes, so AD is a super key and a
candidate key. 
The final set of tables is: AB,BCE,DE,AD
Candidate Key:AD

4. Real life example 1: Consider a database 


student(ID, name, courseID, year, semester, grade)
instructor(ID, name, deptname, deptbudget)
List the functional dependencies you would expect to hold on the above relations,
and decompose them into BCNF.

Sol: 1. student(ID, name, courseID, year, semester, grade)


instructor(ID, name, deptname, deptbudget)

Functional Dependencies:

2. student:
ID-->name
ID,courseID,semester,year-->grade

3. instructor:
ID-->name
deptname-->deptbudget

Tables:

1. student: (ID,name) 
2. takes (ID,courseID,semester,year,grade)

3. instructor: (ID,name,deptname) 

4. department(deptname,deptbudget)
5. (Do this if you finish the preceding steps early): Real life example 2: Create a
relational model for any application of your choice without first creating an ER
model; list the functional dependencies you would expect would hold, and make sure
your design satisfies BCNF or 3NF. 

You might also like