in Databases
1,142 views
1 vote
1 vote

Relation R (A,B,C,D,E,F)

Functional dependency:  ABC -->DEF,    BC-->EF,  EF-->D.

Decomposition: R1 (ABCDF), R2 (BCDE).  Is this decomposition lossy?

Is this decomposition preserve functional dependency?

Plz explain how to check functional dependency is preserved or not in decomposition.

 

in Databases
1.1k views

22 Comments

$R(A,B,C,D,E,F)$ decompose into $R_{1}(\underline{A,B,C},D,F)$ and $R_{2}(\underline{B,C},D,E)$ are lossless decomposition,but not fd preserving.
1
1

@Lakshman Patel RJIT I think it is both Lossless Decomposition as well FDs are preserved!

Which FDs do you think is lost in this decomposition?

0
0

@  how can you explain?

0
0
R1(A,B,C,D,E,F) will have ABC->DEF, BC->EF, and EF->D as well

R2(B,C,D,E) will have BC->E and BC->D

and all the FDs of R(A,B,C,D,E,F)  are directly preserved!
0
0
brother see relation $R_{1}(A,B,C,D,F)$ carefully?
0
0

@Lakshman Patel RJIT

BCD is the key in $R_2$.===> Lossless

 

@Shivam Kasat

there is no FD like BC --> D.

So it looses the FD: EF -> D ===> FD not preserving

2
2

@Lakshman Patel RJIT Sorry Brother My fault! Yes the Given relation decomposition is lossless and FDs are not preserved as due to this decomposition we are losing the Functional dependency EF->D,

0
0

@Shaik Masthan BC->EF and EF->D => BC->D 

so R2 can have the FD BC->D

Correct me if I am wrong

0
0

@

In $R_{1}(\underline {A,B,C},D,F)$

             $ABC\rightarrow DF$

and in  $R_{2}(\underline{B,C},D,E)$

            $BC\rightarrow DE$

1
1

@ Shivam Kasat

for R1:     FD :-  ABC--> DF,  BC-->F,  

for R2:  FD:-   BCD--> E (trivial BC --> E) 

How will we get  FD   EF---> D  from the set of FD of R1 and R2? That's why i think decomposition is not functionally preserve.

If i am wrong plz comment

0
0
i apologies 😑

it's my mistake !

But why it is lossless ?

BCD common attributes and it is a superkey in R2 ( need not to be candidate key only to ensure loss-less)
0
0
the not super key, it should be candidate key.
0
0
why ?
0
0
The common attribute should be candidate key one of the relation.
0
0

The common attribute should be candidate key one of the relation.

that what i am asking, why it should be candidate key but why not Super Key ?

0
0
because of lossless decomposition.
0
0

@Shaik Masthan Because it is necessary and sufficient that the common attributes must be a candidate key,

Since any one of the relations will have common attributes as candidate key on joining these two decomposed relation neither we will loss any of the tuple nor redundant tuples will get generated,

1
1

@Raj Kumar 7 Yes brother You are right! I didn't noticed relation R1 correctly

0
0

it is from korth Book,

Now read my statement

0
0

what you want to conclude @Shaik Masthan

0
0

@Shaik Masthan I think  it is Lossless and dependency EF-->D not preserved.

0
0

@Shivam Kasat

the conclusion is

common attributes are need to be candidate key or super key

0
0

Please log in or register to answer this question.

Related questions

0 votes
0 votes
1 answer
3