Functional-Dependency Analysis and Normalization of R(A, B, C, D, E, F)

Functional-Dependency Analysis and Normalization of R(A, B, C, D, E, F)

Verified Sources
Sep 11, 2026

This section develops a systematic solution for

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

with functional dependencies

F={ABCD, ABDE, CDF, CDFB, BFD}.\mathcal{F}=\{ABC\to D,\ ABD\to E,\ CD\to F,\ CDF\to B,\ BF\to D\}.

A functional dependency XYX\to Y means that any two tuples agreeing on XX must also agree on YY. The central tool is the Attribute closure:

XF+.X^+_{\mathcal F}.

If X+X^+ contains every attribute of RR, then XX is a superkey. If no proper subset of XX is a superkey, then XX is a candidate key.

The analysis has three goals:

  1. Find every candidate key.
  2. Determine whether RR is in BCNF or 3NF.
  3. Find a smaller equivalent dependency set, or minimal cover.

Footnotes

  1. Functional Dependencies and Finding a Minimal Cover - Defines functional dependencies and discusses equivalent dependency sets.

  2. Functional Dependencies: Part 2 - Defines attribute closure, candidate keys, and minimality.

Notation and closure rule

When computing X+, begin with X and repeatedly apply every dependency whose left-hand side is already contained in the current closure. Stop when no new attributes can be added. A set X is a candidate key exactly when X+ = {A, B, C, D, E, F} and no proper subset has the same closure.

1. Structural observations before computing keys

The right-hand sides of the dependencies are:

  • DD from ABCDABC\to D
  • EE from ABDEABD\to E
  • FF from CDFCD\to F
  • BB from CDFBCDF\to B
  • DD from BFDBF\to D

Thus, attribute AA never appears on the right-hand side of any dependency. Therefore, no set that omits AA can derive AA. Every key must contain AA.

Also, CC never appears on the right-hand side. Therefore, every key must contain CC.

Consequently, every candidate key contains ACAC. We only need to determine which additional attributes must accompany ACAC.

This “attributes absent from all right-hand sides” observation is a standard key-search shortcut: such attributes must occur in every candidate key.

Footnotes

  1. Functional Dependencies: Part 2 - Defines attribute closure, candidate keys, and minimality.

Finding all candidate keys using attribute closures

  1. 1
    Step 1

    Attributes A and C never occur on any right-hand side, so every candidate key must contain AC.

  2. 2
    Step 2

    Start with (ACD)+ = {A, C, D}. From CD → F, add F. From CDF → B, add B. From ABD → E, now that A, B, and D are present, add E. Therefore (ACD)+ = {A, B, C, D, E, F}.

  3. 3
    Step 3

    AC is not a superkey because no dependency can fire from AC. AD cannot derive C, and CD cannot derive A. Hence no proper subset of ACD determines all attributes. ACD is a candidate key.

  4. 4
    Step 4

    Start with (ABE)+ = {A, B, E}. No dependency can fire: ABC → D lacks C, ABD → E lacks D, CD → F lacks C and D, CDF → B lacks C and D, and BF → D lacks F. Thus (ABE)+ = {A, B, E}.

  5. 5
    Step 5

    Start with (ABF)+ = {A, B, F}. From BF → D, add D. From ABD → E, add E. However, C is never obtained. Thus (ABF)+ = {A, B, D, E, F}, not all attributes.

  6. 6
    Step 6

    Start with (ACE)+ = {A, C, E}. No dependency can fire because D and B are unavailable. Thus (ACE)+ = {A, C, E}.

  7. 7
    Step 7

    Start with (ACF)+ = {A, C, F}. No dependency can fire because D is unavailable and BF → D lacks B. Thus (ACF)+ = {A, C, F}.

  8. 8
    Step 8

    Start with (ABC)+ = {A, B, C}. From ABC → D, add D. From CD → F, add F. From ABD → E, add E. Therefore (ABC)+ = {A, B, C, D, E, F}, and ABC is a candidate key.

  9. 9
    Step 9

    This set contains the candidate key ABF only after D is derived from BF → D; however, it is not minimal because ABF itself does not derive C, and any successful key must include C. It is therefore not a candidate key.

  10. 10
    Step 10

    "The candidate keys are ABC and ACD. Both contain the mandatory attributes A and C, and each is minimal." ]

2. Detailed closure derivations

Closure of ABCABC

Start with

(ABC)+={A,B,C}.(ABC)^+=\{A,B,C\}.

Apply ABCDABC\to D:

{A,B,C}{A,B,C,D}.\{A,B,C\}\Rightarrow \{A,B,C,D\}.

Apply CDFCD\to F:

{A,B,C,D}{A,B,C,D,F}.\{A,B,C,D\}\Rightarrow \{A,B,C,D,F\}.

Apply ABDEABD\to E:

{A,B,C,D,F}{A,B,C,D,E,F}.\{A,B,C,D,F\}\Rightarrow \{A,B,C,D,E,F\}.

Therefore,

(ABC)+={A,B,C,D,E,F}=R.(ABC)^+=\{A,B,C,D,E,F\}=R.

So ABCABC is a superkey. Its proper subsets cannot be superkeys:

  • (AB)+={A,B}(AB)^+=\{A,B\}
  • (AC)+={A,C}(AC)^+=\{A,C\}
  • (BC)+={B,C}(BC)^+=\{B,C\}

Hence ABCABC is a candidate key.

Closure of ACDACD

Start with

(ACD)+={A,C,D}.(ACD)^+=\{A,C,D\}.

Apply CDFCD\to F:

{A,C,D}{A,C,D,F}.\{A,C,D\}\Rightarrow \{A,C,D,F\}.

Apply CDFBCDF\to B:

{A,C,D,F}{A,B,C,D,F}.\{A,C,D,F\}\Rightarrow \{A,B,C,D,F\}.

Apply ABDEABD\to E:

{A,B,C,D,F}{A,B,C,D,E,F}.\{A,B,C,D,F\}\Rightarrow \{A,B,C,D,E,F\}.

Therefore,

(ACD)+=R.(ACD)^+=R.

Its proper subsets are not superkeys:

  • (AC)+={A,C}(AC)^+=\{A,C\}
  • (AD)+={A,D}(AD)^+=\{A,D\}
  • (CD)+={C,D,F,B}(CD)^+=\{C,D,F,B\}

In particular, CDCD cannot derive AA or EE. Thus ACDACD is a candidate key.

Why there are no other candidate keys

Every candidate key must contain AA and CC. The possible minimal supersets of ACAC are obtained by adding one or more of B,D,E,FB,D,E,F.

  • Adding BB gives ABCABC, which is a key.
  • Adding DD gives ACDACD, which is a key.
  • Adding only EE gives ACEACE, which is not a key.
  • Adding only FF gives ACFACF, which is not a key.

Any larger set containing ABCABC or ACDACD is not minimal. Therefore, the complete set of candidate keys is

{ABC, ACD}.\boxed{\{ABC,\ ACD\}}.

The prime attributes are

A, B, C, D.\boxed{A,\ B,\ C,\ D}.

The non-prime attributes are

E, F.\boxed{E,\ F}.

Attribute participation in candidate keys

Attributes A, B, C, and D are prime; E and F are non-prime.

3. Visualizing the dependency propagation

The key derivations can be viewed as two principal routes:

The two candidate keys exploit different dependency chains:

  • ABCABC first produces DD, then FF and EE.
  • ACDACD first produces FF, then BB and EE.

The dependency BFDBF\to D is not needed for either candidate-key derivation, but it remains relevant when testing normal forms and when constructing an equivalent minimal cover.

Key-finding shortcut

Because A and C never occur on any right-hand side, every candidate key must contain AC. This reduces the search from all 2^6 attribute subsets to supersets of AC only.

4. BCNF analysis

A relation is in Boyce–Codd normal form (BCNF) if, for every nontrivial dependency

XYX\to Y

that holds in the relation, XX is a superkey.

Check the given dependencies:

DependencyIs the left side a superkey?Reason
ABCDABC\to DYesABCABC is a candidate key
ABDEABD\to EYesABDABD contains candidate key ABCABC? No; but ABD+ABD^+ does not contain CC, so not a superkey
CDFCD\to FNo(CD)+={B,C,D,F}(CD)^+=\{B,C,D,F\}
CDFBCDF\to BNo(CDF)+={B,C,D,F}(CDF)^+=\{B,C,D,F\}
BFDBF\to DNo(BF)+={B,D,E,F}(BF)^+=\{B,D,E,F\}

The first dependency has a superkey determinant. However, ABDEABD\to E is also not a superkey dependency because ABDABD cannot derive CC. More importantly, CDFCD\to F, CDFBCDF\to B, and BFDBF\to D have determinants that are not superkeys.

For example,

(CD)+={B,C,D,F}R.(CD)^+=\{B,C,D,F\}\neq R.

Therefore,

R is not in BCNF.\boxed{R\text{ is not in BCNF}.}

A single valid counterexample, such as CDFCD\to F, is sufficient to disprove BCNF.

Footnotes

  1. Boyce-Codd Normal Form (BCNF) - Describes the BCNF requirement that every determinant be a superkey.

5. 3NF analysis

A relation is in third normal form (3NF) if, for every nontrivial dependency XAX\to A, at least one condition holds:

  1. XX is a superkey; or
  2. AA is a prime attribute.

The prime attributes are A,B,C,DA,B,C,D. The non-prime attributes are E,FE,F.

Check each dependency:

DependencyDeterminant is a superkey?Right-hand attribute prime?3NF status
ABCDABC\to DYesYesSatisfies
ABDEABD\to ENoNo, EE is non-primeViolates
CDFCD\to FNoNo, FF is non-primeViolates
CDFBCDF\to BNoYes, BB is primeSatisfies
BFDBF\to DNoYes, DD is primeSatisfies

The dependency

ABDEABD\to E

violates 3NF because:

  • ABDABD is not a superkey, since C(ABD)+C\notin (ABD)^+;
  • EE is non-prime because it belongs to no candidate key.

The dependency CDFCD\to F also violates 3NF because:

  • CDCD is not a superkey;
  • FF is non-prime.

Therefore,

R is not in 3NF.\boxed{R\text{ is not in 3NF}.}

Since BCNF is stricter than 3NF, failure of 3NF also implies failure of BCNF. In this case, the relation is not even in 3NF.

Footnotes

  1. Third Normal Form - States the 3NF condition involving superkeys and prime attributes.

Normal-form decision details

6. Simplifying the dependency set

The original set is

F={ABCD, ABDE, CDF, CDFB, BFD}.\mathcal F= \{ ABC\to D,\ ABD\to E,\ CD\to F,\ CDF\to B,\ BF\to D \}.

To simplify it without changing F+\mathcal F^+, test:

  1. Whether any left-hand-side attribute is extraneous.
  2. Whether any entire dependency is redundant.

A dependency set GG is equivalent to F\mathcal F when

G+=F+.G^+=\mathcal F^+.

The usual procedure is to replace right-hand sides by single attributes, test left-side attributes using closures, and then test each dependency for redundancy.

Footnotes

  1. Minimal Cover - Explains extraneous attributes and tests for dependency simplification.

Constructing a minimal equivalent cover

  1. 1
    Step 1

    Use F = {ABC → D, ABD → E, CD → F, CDF → B, BF → D}.

  2. 2
    Step 2

    Removing A gives BC, whose closure is {B, C}; removing B gives AC, whose closure is {A, C}; removing C gives AB, whose closure is {A, B}. None derives D, so no attribute is extraneous.

  3. 3
    Step 3

    Removing A gives BD, whose closure is {B, D, E}; it derives E, so A is extraneous. Removing B from the original left side gives AD, whose closure is {A, D}; it does not derive E. Removing D gives AB, whose closure is {A, B}; it does not derive E. Therefore ABD → E can be reduced to BD → E.

  4. 4
    Step 4

    Removing C gives D, whose closure is {D}; removing D gives C, whose closure is {C}. Neither derives F. Thus CD → F has no extraneous left-side attribute.

  5. 5
    Step 5

    Removing C gives DF, whose closure is {D, F}; removing D gives CF, whose closure is {C, F}; removing F gives CD, whose closure is {B, C, D, F}, which contains B. Therefore F is extraneous, and CDF → B reduces to CD → B.

  6. 6
    Step 6

    Removing B gives F, whose closure is {F}; removing F gives B, whose closure is {B}. Neither derives D. Thus BF → D has no extraneous left-side attribute.

  7. 7
    Step 7

    After reducing the left sides, the set is {ABC → D, BD → E, CD → F, CD → B, BF → D}. None of these dependencies can be removed while preserving its own consequence. In particular, CD → B is needed to derive B from CD, and CD → F is needed to derive F from CD.

  8. 8
    Step 8

    "The two dependencies CD → F and CD → B can be combined as CD → BF. This produces an equivalent compact cover." ]

7. Closure calculations for extraneous attributes

7.1 Reducing ABDEABD\to E

Test whether AA is extraneous by computing (BD)+(BD)^+ under the original dependencies.

Start with

(BD)+={B,D}.(BD)^+=\{B,D\}.

Apply the original dependency ABDEABD\to E? Its left side requires AA, so it cannot be applied. No other dependency can fire. Thus, under the original set alone, (BD)+(BD)^+ would not contain EE.

However, the correct extraneous-attribute test must be performed against the dependency set with the target dependency removed and the proposed reduced dependency inserted, or equivalently by checking whether the dependency is implied by the remaining dependencies after the reduction process. Here, we must be precise: AA is not extraneous in ABDEABD\to E under the original set because BDBD does not derive EE from the remaining dependencies.

Therefore, the initial apparent reduction

ABDE⇏BDEABD\to E \quad\not\Rightarrow\quad BD\to E

is invalid.

7.2 Corrected minimal-cover testing

The left-side reductions must be recomputed carefully:

  • For ABDEABD\to E, testing AA requires (BD)+(BD)^+ under F{ABDE}\mathcal F-\{ABD\to E\}. This is {B,D}\{B,D\}, so AA is not extraneous.
  • Testing BB requires (AD)+(AD)^+. This is {A,D}\{A,D\}, so BB is not extraneous.
  • Testing DD requires (AB)+(AB)^+. This is {A,B}\{A,B\}, so DD is not extraneous.

Thus, ABDEABD\to E cannot be reduced.

7.3 Reducing CDFBCDF\to B

Test FF by computing (CD)+(CD)^+ using the other dependencies, excluding CDFBCDF\to B:

(CD)+={C,D}.(CD)^+=\{C,D\}.

From CDFCD\to F, add FF:

(CD)+={C,D,F}.(CD)^+=\{C,D,F\}.

Without CDFBCDF\to B, there is no way to derive BB. Therefore, FF is not extraneous under the standard test.

Likewise:

  • (DF)+={D,F}(DF)^+=\{D,F\}, which does not derive BB;
  • (CF)+={C,F}(CF)^+=\{C,F\}, which does not derive BB.

Therefore, CDFBCDF\to B cannot be reduced.

7.4 Redundant dependency testing

Now test each complete dependency by removing it:

  • Without ABCDABC\to D, ABCABC cannot derive DD.
  • Without ABDEABD\to E, ABDABD cannot derive EE.
  • Without CDFCD\to F, CDCD cannot derive FF.
  • Without CDFBCDF\to B, CDFCDF cannot derive BB.
  • Without BFDBF\to D, BFBF cannot derive DD.

Therefore, no dependency is redundant.

The original set is already a minimal cover, apart from the conventional step of splitting right-hand sides—which is unnecessary here because every right-hand side already contains one attribute.

Hence,

F cannot be simplified by removing dependencies or left-side attributes.\boxed{\mathcal F\text{ cannot be simplified by removing dependencies or left-side attributes}.}

It is already a minimal equivalent cover.

Important correction in minimal-cover testing

A left-side attribute is extraneous only if the reduced left side still determines the original right side using the appropriate dependency set. It is not enough that the reduced set appears in a larger closure after the original dependency has already fired.

8. Final answer to part (iii)

The answer is no: there is no proper simplification of the given set that preserves the full closure F+\mathcal F^+.

The set

{ABCD, ABDE, CDF, CDFB, BFD}\boxed{ \{ABC\to D,\ ABD\to E,\ CD\to F,\ CDF\to B,\ BF\to D\} }

is already minimal because:

  • Every right-hand side is a single attribute.
  • No attribute on any left-hand side is extraneous.
  • No entire dependency is implied by the remaining dependencies.

For example:

(CD)F{CDF}+={C,D},(CD)^+_{\mathcal F-\{CD\to F\}}=\{C,D\},

so CDFCD\to F is necessary.

Similarly,

(CDF)F{CDFB}+={C,D,F},(CDF)^+_{\mathcal F-\{CDF\to B\}}=\{C,D,F\},

so CDFBCDF\to B is necessary.

And

(BF)F{BFD}+={B,F},(BF)^+_{\mathcal F-\{BF\to D\}}=\{B,F\},

so BFDBF\to D is necessary.

Thus, removing any listed dependency changes the closure.

Functional-dependency analysis review

1 / 9
Question · Term

What is the closure of ABC?

Click to reveal
Answer · Definition

(ABC)+=A,B,C,D,E,F(ABC)+ = {A, B, C, D, E, F}, so ABC is a candidate key.

9. Consolidated solution

(i) All keys

The candidate keys are

ABC and ACD.\boxed{ABC\text{ and }ACD}.

The prime attributes are

A,B,C,D.\boxed{A,B,C,D}.

The non-prime attributes are

E,F.\boxed{E,F}.

(ii) Normal forms

The relation is not in BCNF because, for example,

CDFCD\to F

holds while CDCD is not a superkey.

The relation is not in 3NF because, for example,

ABDEABD\to E

holds while ABDABD is not a superkey and EE is non-prime. The dependency CDFCD\to F independently gives another 3NF violation.

Therefore,

R is neither in BCNF nor in 3NF.\boxed{R\text{ is neither in BCNF nor in 3NF}.}

(iii) Simplification

No dependency can be removed, and no attribute can be removed from a left-hand side without changing F+\mathcal F^+. Therefore,

F is already a minimal cover.\boxed{\mathcal F\text{ is already a minimal cover}.}

Knowledge Check

Question 1 of 5
Q1Single choice

Which of the following is a candidate key of R?

Explore Related Topics

1

Evaluating ER-to-Relational Mapping Statements

The content explains how standard ER‑to‑relational mapping rules validate three statements about weak entities, partial keys, and many‑to‑many relationships, and shows that the fourth claim—every generated relation has only one candidate key—is false.

  • Weak entities depend on a strong owner and are identified by the owner’s primary key plus a partial (discriminator) key.
  • A partial key is allowed for weak entities, forming a composite primary key with the owner key.
  • Binary M:NM:N relationships are mapped to a separate associative relation containing the participating primary keys.
  • A generated relation may have multiple candidate keys; one is chosen as the primary key, so statement (iv) is false.
2

Requirement Analysis in Software Engineering: Primary Goal, Rationale, and Exam Interpretation

Requirement analysis’s primary goal is to understand and document stakeholder and user needs, creating a clear specification that drives design, coding, and testing.

  • Defined as “identifying, refining, and documenting what a system must do,” it yields an SRS, user stories, or use cases.
  • Core steps: elicit needs, analyze/refine, document, validate, and baseline for downstream work (Requirement AnalysisClear RequirementsBetter Design, Coding, and Testing\text{Requirement Analysis}\rightarrow\text{Clear Requirements}\rightarrow\text{Better Design, Coding, and Testing}).
  • It answers “What does the user need?” unlike design (“How will it be built?”) (Analysis asks "What is needed?"Design asks "How will it be built?"\text{Analysis asks } "What\ is\ needed?" \neq \text{Design asks } "How\ will\ it\ be\ built?").
  • Coding, architecture, and testing are downstream activities; the exam answer is option (ii) – understanding and documenting user needs.
3

Lossless vs Lossy Decomposition for Given Functional Dependencies (D1 and D2)