Table of Contents

Type 1: Find all the candidate keys: .............................................................................................................. 2

Type 2: Normalization ................................................................................................................................... 5
Type 3: Find whether the given decomposition is Lossless or lossy decomposition ................................. 10
Type 4: Minimal/Canonical Cover (Irreducible Set) .................................................................................. 11
Type 5: Dependency Preserving Decomposition ........................................................................................ 13
Background:

Algorithm:

The following algorithm will help us in finding the closure of an attribute;

Example:
Assume a relation schema R = (A, B, C) with the set of functional dependencies F = {A → B,
B → C}. Now, we can find the attribute closure of attribute A as follows;
Step 1: We start with the attribute in question as the initial result. Hence, result = A.
Step 2: Take the first FD A → B. Its left hand side (i.e, A) is in the result, hence the right hand
side can be included with the result. This lead to result = AB.
Step 3: Take the second FD B → C. Its left hand side (i.e, B) is in the result (or subset of result),
hence the right hand side can be included with the result. Now, result = ABC.
We have no more attributes. Hence the algorithm exits. As the result, A+ includes all the attributes
of relation R. now we would say A+ is ABC. And, A is one of the keys of the relation R.

Type 1: Find all the candidate keys:

Question:
Consider a relation with schema R(A,B,C,D) with functional dependencies (FD’s):
BC → A, AD → B, CD → B, AC → D.
Find all the candidate keys of R.

Solution:

Let us find the closure for the left hand side (LHS) attributes of given set of functional
dependencies.

Let us take the FD BC → A to check whether the LHS BC forms a candidate key or not.
 We know Result = How? Description
BC BC Given
BC BCA BC→ A If we know BC,
then we can
derive A
uniquely as per
the reflexivity
rule, hence
result = BCA
BCA BCAD AC→D From the
previous step
we know
attribute A,
and by the FD
AC → D the
result becomes
ABCD which is
equal to R.
Hence, BC is a
candidate key

We derived all the other candidate keys in the same way as stated above and given in the table
below:
BC, AC, and CD are the candidate keys for the given relation.

Question 2:
For the following relation schema R and set of Functional Dependencies F:
R(A,B,C,D,E), F = {AC → E, B → D, E → A}
List all candidate keys.

Answer: From the given set F of functional dependencies, it is very evident that B and C must be
in the candidate key as they are not present in the Right Hand Side (RHS) of the given set of FDs.
Hence, at first we can check for BC as the candidate key as follows;
If you know B, then you know B and D through FD B → D. Along with this, if you know C, then
you know BCD. That is, BC → BCD. B and C together cannot determine A and E, so BC cannot
be a candidate key.
Then we can try with the attributes that are present in the LHS like B and C. First let us take A.
Then we have,
ABC → ABCDE. So, ABC is a candidate key.

Now we shall try with the other LHS attribute E. Then we have,
BCE → ABCDE. So, BCE is another candidate key.
Checking BCA and BCE, we see that both of them are candidate keys.

Type 2: Normalization
Question: Normalize upto 3NF.

 Is this table in First Normal Form?

Yes. All the attributes contain only atomic values.

 Is this table in Second Normal Form?

To verify this property, we need to find all the functional dependencies which are holding in
User_Personal table, and have to identify a Primary key.
Let us do that by using the sample data. This leads to the following set of FDs;
F = {UserID → U_email Fname Lname City State Zip,
Zip → City State }
As UserID attribute can uniquely determine all the other attributes, we can have UserID as the
Primary key for User_Personal table.
The next step is to check for the 2NF properties;
Property 1 – The table should be in 1NF.
Property 2 – There should not be any partial key dependencies.

Our table is in 1NF, hence property 1 is holding.

Primary key of our table is UserID and UserID is single simple attribute. As the key is not
composite, there is no chance for partial key dependency to hold. Hence property 2 is also
holding.
User_Personal table is in 2NF.

 Is User_Personal in 3NF?
To verify this we need to check the 3NF properties;
Property 1 – Table should be in 2NF.
Property 2 – There should not be any Transitive Dependencies in the table.

Table User_Personal is in 2NF, hence property 1 is satisfied.

User_Personal table holds the following Transitive dependency;

UserID → Zip,
Zip → City State

Hence, property 2 is not satisfied and the table is not in 3NF.

Solution:
Decompose User_Personal. For this, we can use the functional dependencies Zip → City State and
UserID → U_email Fname Lname City State Zip.

As a result, we can have the following tables (primary keys are underlined);

User_Personal (UserID, U_email, Fname, Lname, Zip)

City (Zip, City, State)
Question:
The following relation schema can be used to register information on the repayments on micro
loans.

Repayment (borrower_id, name, address, loanamount, requestdate, repayment_date,

repayment_amount)

A borrower is identified with an unique borrower_id, and has only one address. Borrowers can
have multiple simultaneous loans, but they always have different request dates. The borrower can
make multiple repayments on the same day, but not more than one repayment per loan per day.
a) State a key (candidate key) for Repayment.
b) Make the normalization to BCNF. Show the steps.

Answer:
Answer a):

From the given information, we can derive the following set of functional dependencies;
Borrower_id → name [given: every borrower is identified with an unique id]

Borrower_id → address [given: each borrower has only one address]

Borrower_id, Requestdate → loanamount [given: more than one loan cannot be requested by a
single borrower]

Borrower_id, requestdate, repayment_date → repayment_amount [given: a borrower can make

multiple repayments on a single day, but not on a single loan]

From the above set of FDs, it is evident that we can uniquely identify all the other attributes of
Repayment table, if we know the values of (borrower_id, requestdate, repayment_date). That is,

Borrower_id, requestdate, repayment_date → name, address, loanamount, repayment_amount.

Hence, attributes (Borrower_id, requestdate, repayment_date) together forms a candidate key.

Answer b):

Is the given relation Repayment is in 1NF?

Yes. It has a key. Hence, we can make unique identification of records.

Is the given relation is in 2NF?

No. We have the following partial key dependencies.

1. We can easily derive name and address of every borrower if we know the borrower_id from the
FDs Borrower_d → name, and Borrower_id → address.

2. We can derive the loanamount if we know borrower_id, and requestdate from the FD
Borrower_id, Requestdate → loanamount.

Hence, the relation Repayment is not in 2NF. To convert it into a 2NF relation, we can decompose
Repayment into the following relations;

Borrower (Borrower_id, Name, Address)

Borrower_loan (Borrower_id, Requestdate, Loanamount)
Repayment (Borrower_id, Requestdate, Repayment_date, Repayment_amount)

From the derived FDs, we know that all these tables are in 2NF.

Are these tables in 3NF?

Yes. There are no transitive dependencies present in the above tables’ set of functional
dependencies. Hence, we would say that all these tables are in 3NF.

Are these tables in BCNF?

Yes. There are no more than one candidate keys present in the above set of tables. Hence the
following decomposed tables are in Boyce-Codd Normal Form.
Borrower (Borrower_id, Name, Address)
Borrower_loan (Borrower_id, Requestdate, Loanamount)
Repayment (Borrower_id, Requestdate, Repayment_date, Repayment_amount)

Question: A table has fields F1, F2, F3, F4, and F5, with the following functional dependencies:
F1->F3
F2->F4
(F1,F2)->F5
in terms of normalization, this table is in
(a) 1NF (b) 2NF (c) 3NF (d) None of these

Ans: option (a)

Explanation:
Since the primary key is not given we have to derive the primary key of the table. Using the
closure set of attributes we get the primary key as (F1,F2). From functional dependencies, "F1-
>F3, F2->F4", we can see that there is partial functional dependency therefore it is not in 2NF.
Hence the table is in 1NF.
Question:
Which of the following is TRUE?
(a) Every relation in 2NF is also in BCNF
(b) A relation R is in 3NF if every non-prime attribute of R is fully functionally dependent on
every key of R
(c) Every relation in BCNF is also in 3NF
(d) No relation can be in both BCNF and 3NF

Ans: option (c)

Question:
Let R(A,B,C,D,E,P,G) be a relational schema in which the following FDs are known to hold:
AB->CD
DE->P
C->E
P->C
B->G
The relation schema R is
(a) in BCNF (b) in 3NF, but not in BCNF
(c) in 2NF, but not in 3NF (d) not in 2NF

Ans: option (d)

Explanation:
From the closure set of attributes we can see that the key for the relation is AB. The FD B->G is
a partial dependency, hence it is not in 2NF.

Type 3: Find
whether the given decomposition is Lossless or lossy
decomposition

Question:

Suppose you are given a relation R(A,B,C,D). let us assume that set of functional dependencies F
= { B → C, D → A} and R is decomposed into R1(B,C), and R2(A,D).
(a) Find the candidate key(s) for R. (b) State whether or not the proposed decomposition of R into
smaller relations is a good decomposition and briefly explain why or why not.

Solution:

a) To find the candidate keys, we have to find the closure of attributes of LHS (left hand side) of
all functional dependencies. If the closure includes all the attributes of the given relation, then that
attribute (or set of attributes) is the candidate key.
B+ = BC. It does not include all attributes of R.
D+ = DA. It does not include all attributes of R.
(BD)+ = BCDA. It includes all attributes of R, hence BD is the candidate key.

b) The decomposition of R into R1 and R2 is lossy because there is no common attribute between
R1 and R2 (R1∩R2 = ∅). Hence, the join of R1 and R2 will result in Cartesian product of these
two relations which is not the base relation R.
Type 4: Minimal/Canonical Cover (Irreducible Set)

Find the minimal cover of the set of functional dependencies given; {A → BC, B → C, AB → D}

Solution:
Minimal cover:

Definition 1:

A minimal cover of a set of FDs F is a minimal set of functional dependencies Fmin that is
equivalent to F. There can be many such minimal covers for a set of functional dependencies
F.

Definition 2:

A set of FDs F is minimum if F has as few FDs as any equivalent set of FDs.

Simple properties/steps of minimal cover:

1. Right Hand Side (RHS) of all FDs should be single attribute.

2. Remove extraneous attributes.

3. Eliminate redundant functional dependencies.

Let us apply these properties to F = {A → BC, B → C, AB → D}

1. Right Hand Side (RHS) of all FDs should be single attribute. So we write F as F1, as follows;

F1 = {A → B, A → C, B → C, AB → D}

2. Remove extraneous attributes.

Extraneous attribute is a redundant attribute on the LHS of the functional dependency. In the set
of FDs, on AB → D has more than one attribute in the LHS. Hence, we check one of A and B is
extraneous or not.

First we check whether A is extraneous or not. To do that, we need to find the closure of the
remaining attribute B with respect to F1.
 B+ = BC.

This does not include D, so A is not extraneous.

Now we check whether B is extraneous or not. To do that, we need to find the closure of the
remaining attribute A with respect to F1.

A+ = ABCD.

This includes D, so B is extraneous, ie., we can identify D without B on the LHS.

Now, we can write the new set of FDs, F2 as follows;

F2 = {A → B, A → C, B → C, A → D}

3. Eliminate redundant functional dependency.

If A → B, and B → C, then A → C is true (according to transitive rule). Hence, the FD A → C is

redundant. We can eliminate this and we get final set of FDs F3 as follows;

F3 = {A → B, B → C, A → D}

The set of FDs F3 is the minimal cover of F.