Consider a relation R(A, B, C, D, E, F) with the following functional…

Concept — 3NF synthesis algorithm:

To decompose a relation into 3NF, take a minimal cover of its functional dependencies (FDs) and create one relation schema per distinct left-hand side, grouping together every FD that shares it. Because each original FD now lives inside some relation, dependency preservation holds by construction. If none of these grouped relations contains a full candidate key of the original relation, the algorithm adds exactly one extra relation whose schema equals a candidate key — this single addition is what makes the overall join lossless.

Concept — candidate key via attribute closure:

A candidate key is a minimal attribute set K whose closure K+ (computed by repeatedly applying the FDs) equals every attribute of the relation, while no proper subset of K reaches all attributes. Any attribute that never appears on the right-hand side of any FD must belong to every candidate key, since nothing else can ever produce it.

Application to this relation:

1. List the attributes that never appear on a right-hand side: scanning A → C, BD → F, EF → A, D → B, only D and E never occur on any right-hand side, so D and E must belong to every candidate key.

2. Compute the closure {D, E}+ : start with {D, E}. D → B adds B, giving {B, D, E}. BD → F adds F (both B and D are present), giving {B, D, E, F}. EF → A adds A, giving {A, B, D, E, F}. A → C adds C, giving all six attributes {A, B, C, D, E, F}. Since {D, E}+ is everything and neither D nor E alone reaches all six attributes, (D, E) is a candidate key.

3. Reduce to a minimal cover before grouping: test whether B is extraneous in BD → F by checking D+ against the whole FD set. D → B gives {B, D}; with B and D both present, BD → F now applies and adds F, giving D+ = {B, D, F}. Since F is already reachable from D alone, B is extraneous — BD → F collapses to D → F. The FDs D → B and D → F now share the same left-hand side D, so a minimal cover is {A → C, D → B, D → F, EF → A}.

4. Group the minimal-cover FDs by left-hand side to build the synthesized relations: R1(A, C) for A → C; R2(D, B, F) for D → B and D → F; R3(E, F, A) for EF → A.

5. Check whether any of these three relations already contains the full candidate key (D, E): R1 has neither D nor E, R2 has D but not E, and R3 has E but not D. No relation contains both, so the algorithm adds one more relation, R4(D, E), to guarantee the lossless join.

6. Count the relations produced: R1, R2, R3 and R4 — four relations in total.

Cross-check — why three relations are never enough here:

None of R1(A, C), R2(D, B, F), R3(E, F, A) contains the full candidate key (D, E): R1 has neither D nor E, R2 has D but not E, and R3 has E but not D. So the ONLY way a three-relation decomposition could still be lossless is by merging two of these three into one relation whose schema finally contains both D and E — and since only R2 carries D and only R3 carries E, R2 and R3 are the only pair whose merge can possibly supply the complete key; merging R1 with either R2 or R3 still leaves the key incomplete; and merging all three collapses to R itself, which retains every original violation. So R2 ∪ R3, on schema (A, B, D, E, F), is the only candidate worth testing. The FDs still holding on it are D → B, D → F and EF → A, and its own candidate key is again (D, E) (same closure computation, just without C). Test D → B against this merged relation: D alone closes to {B, D, F} — not a superkey, since A and E are missing — and B is not part of the merged relation’s candidate key (D, E), so B is not a prime attribute either. D → B therefore violates 3NF inside the merged relation (the same failure recurs for D → F), so this merge is illegal — and it was the only merge that could have worked. Four relations — one holding the standalone candidate key (D, E) plus one per grouped FD — is therefore both necessary and sufficient.

Result: minimum number of relations required = 4.