Splitting a relation can fix redundancy and still create a bad design. Two separate questions decide whether the split is safe: can the fragments be joined without inventing rows, and can every functional dependency still be enforced without joining them? GATE often puts both properties in one numerical, so test them independently.
The two properties, defined so you can test them
A decomposition has the lossless-join property when the natural join of its projections gives exactly the original relation. It loses no valid tuples and adds no spurious tuples. “Non-additive join” is another name for the same property.
A decomposition is dependency preserving when all original functional dependencies can be enforced by checking the individual fragments. More formally, project the original FD set F onto each fragment. If the closure of the union of those projected sets equals F's closure, the decomposition preserves dependencies.
These tests answer different questions. A decomposition can be lossless but not dependency preserving. Never infer one property from the other.
The binary lossless-join rule
For a two-way decomposition of R into R1 and R2, first find their common attributes:
X = R1 intersection R2
The decomposition is lossless if and only if, under F, either:
X -> R1, or
X -> R2.
In plain words, the common attributes must form a superkey of at least one fragment. Compute X+ under F and see whether it contains every attribute of R1 or every attribute of R2.
The phrase two-way is essential. This shortcut is not a general rule for a split into three or more fragments. Use a chase tableau for the general case.
Worked example A: both properties hold
Let:
R(A, B, C, D)
F = {A -> B, B -> C, C -> D}
Decompose R into R1(A, B, C) and R2(C, D).
For lossless join, the common set is R1 intersection R2 = {C}. Compute its closure:
Start with C+ = {C}.
Apply C -> D.
Therefore C+ = {C, D}.
That closure contains every attribute of R2(C, D), so C is a superkey of R2. The binary rule is satisfied. The decomposition is lossless.
Now project the dependencies. Within R1, we can check A -> B and B -> C. Within R2, we can check C -> D. Their union is:
F' = {A -> B, B -> C, C -> D}
F' is the original F, so their closures are equal. Every original dependency can be enforced locally. The decomposition is dependency preserving.
The result is plain: both properties hold.
Worked example A continued: prove losslessness by chase
The chase gives a mechanical test that also extends beyond two fragments. Create one row per fragment and one column per attribute. Put the same distinguished symbol aj in column j wherever a fragment contains that attribute. Put a fresh bij symbol where it does not.
For this decomposition, start with:
Row | A | B | C | D |
|---|---|---|---|---|
R1(ABC) | a1 | a2 | a3 | b14 |
R2(CD) | b21 | b22 | a3 | a4 |
The rows agree on C because both contain a3. Apply C -> D. Their D entries must agree, and a distinguished a-symbol wins over a b-symbol, so replace R1's b14 with a4.
Row after C -> D | A | B | C | D |
|---|---|---|---|---|
R1(ABC) | a1 | a2 | a3 | a4 |
R2(CD) | b21 | b22 | a3 | a4 |
The first row now consists entirely of its column's a-symbols. A complete a-row means the original tuple can be reconstructed, so the chase confirms that the join is lossless.
Worked example B: lossless but not dependency preserving
Let R(C, S, Z) represent City, Street and Zip, with:
F = {CS -> Z, Z -> C}
CS is a candidate key because (CS)+ = {C, S, Z}. SZ is also a candidate key because Z -> C gives (SZ)+ = {S, Z, C}. The FD Z -> C violates BCNF because Z alone is not a superkey of the original R.
Decompose on Z -> C into R1(Z, C) and R2(S, Z).
The common attribute is Z. Since Z -> C, Z+ contains {Z, C}, every attribute of R1. Thus Z is a superkey of R1 and the binary rule proves the split lossless.
Now project F. R1 preserves Z -> C. R2 has no non-trivial projected FD that can recover CS -> Z. The original dependency CS -> Z needs C, S and Z together, but no fragment contains all three. Nor can Z -> C imply CS -> Z. Therefore CS -> Z is lost and the decomposition is not dependency preserving.
This is the classic BCNF trade-off. A BCNF decomposition may lose dependency preservation. A decomposition produced by the standard 3NF synthesis algorithm can guarantee both lossless join and dependency preservation.
The traps GATE plants
Applying the binary superkey shortcut to a decomposition with three or more fragments.
Assuming any common attribute makes a split lossless. It must determine all attributes of at least one side.
Testing lossless join and then forgetting dependency preservation, or doing the reverse.
Looking only for FDs written verbatim inside fragments. An original FD is preserved if it follows from the closure of the projected union.
Assuming BCNF always preserves every dependency. Example B disproves that claim.
Computing closure under only the visibly projected FDs when the question asks for a lossless test under the original F.
Write two labels on the rough page, LJ and DP, and do not select an option until both have a result.
How the exam tests decomposition
Questions ask whether a supplied split is lossless, dependency preserving, both or neither. You may also need to complete a chase, select a correct MSQ combination or identify a relation that must be added. Confirm current DBMS coverage on the organising IIT's official GATE syllabus page.
Review the normal-form context in Normalization in DBMS: 1NF to BCNF, then use DBMS Normalization Explained Simply to connect decomposition choices to the anomalies they are meant to remove.
The short version and next step
For a two-fragment split, lossless means the common attributes form a superkey of one fragment. Dependency preserving means the union of projected FD sets recovers the closure of the original F. These are separate tests.
KnowledgeGate has about 2,000 live DBMS practice questions, including many on normalization and decomposition. Drill the checks in the GATE Test Series, build the full DBMS sequence with GATE Guidance by Sanchit Sir, and use the GATE preparation category to schedule the topic within your wider revision.
