Skip to main content

Lossless and dependency preserving check 3

Short answer

The decomposition is lossless because common attribute A is a key of R. It is not dependency preserving: F1 ∪ F2 yields only A→B and A→C, so B→C is lost.

R (A, B, C), R1 (A, B), R2 (A, C). F = {A → B, B → C}. Check whether the decomposition is lossless and dependency preserving.

R = (A, B, C), R1 = (A, B), R2 = (A, C), F = {A → B, B → C}.

Lossless join test

R1 ∩ R2 = {A}. A⁺ = {A, B, C} = R (A → B, then B → C). So A is a key of R, and hence A → R1 and A → R2.

Chase table:

ABC
R1aab
R2aba

A → B: both rows have A = a, so B in R2 becomes a. Then B → C: both rows have B = a, so C in R1 becomes a. Both rows are now all "a".

The decomposition is lossless.

Dependency preservation test

Projections:

  • F1 on (A, B): A → B
  • F2 on (A, C): A → C (obtained from A → B, B → C)

Together F1 ∪ F2 = {A → B, A → C}.

  • A → B: in F1. Preserved.
  • B → C: B and C are in different relations. Test: Z = {B}; R1: B⁺ ∩ {A, B} = {B}; R2: Z ∩ R2 = ∅. C is never reached. Under {A → B, A → C}, B⁺ = {B}. Lost.

The decomposition is NOT dependency preserving.

Answer: lossless, but not dependency preserving. Example: R1 can hold (a1, b1), (a2, b1) and R2 can hold (a1, c1), (a2, c2). Each table is consistent with A → B and A → C, but the join has b1 with both c1 and c2, violating B → C, and no single table can detect it.

✓ Answer checked by Claude Opus 5.5 (high effort)

Related questions

All Database Management System chapter 4 questions →