Functional-Dependency Analysis and Normalization of R(A, B, C, D, E, F)
This section develops a systematic solution for
with functional dependencies
A functional dependency means that any two tuples agreeing on must also agree on . The central tool is the Attribute closure:
If contains every attribute of , then is a superkey. If no proper subset of is a superkey, then is a candidate key.
The analysis has three goals:
- Find every candidate key.
- Determine whether is in BCNF or 3NF.
- Find a smaller equivalent dependency set, or minimal cover.
Footnotes
-
Functional Dependencies and Finding a Minimal Cover - Defines functional dependencies and discusses equivalent dependency sets. ↩
-
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:
- from
- from
- from
- from
- from
Thus, attribute never appears on the right-hand side of any dependency. Therefore, no set that omits can derive . Every key must contain .
Also, never appears on the right-hand side. Therefore, every key must contain .
Consequently, every candidate key contains . We only need to determine which additional attributes must accompany .
This “attributes absent from all right-hand sides” observation is a standard key-search shortcut: such attributes must occur in every candidate key.
Footnotes
-
Functional Dependencies: Part 2 - Defines attribute closure, candidate keys, and minimality. ↩
Finding all candidate keys using attribute closures
- 1Step 1
Attributes A and C never occur on any right-hand side, so every candidate key must contain AC.
- 2Step 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}.
- 3Step 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.
- 4Step 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}.
- 5Step 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.
- 6Step 6
Start with (ACE)+ = {A, C, E}. No dependency can fire because D and B are unavailable. Thus (ACE)+ = {A, C, E}.
- 7Step 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}.
- 8Step 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.
- 9Step 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.
- 10Step 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
Start with
Apply :
Apply :
Apply :
Therefore,
So is a superkey. Its proper subsets cannot be superkeys:
Hence is a candidate key.
Closure of
Start with
Apply :
Apply :
Apply :
Therefore,
Its proper subsets are not superkeys:
In particular, cannot derive or . Thus is a candidate key.
Why there are no other candidate keys
Every candidate key must contain and . The possible minimal supersets of are obtained by adding one or more of .
- Adding gives , which is a key.
- Adding gives , which is a key.
- Adding only gives , which is not a key.
- Adding only gives , which is not a key.
Any larger set containing or is not minimal. Therefore, the complete set of candidate keys is
The prime attributes are
The non-prime attributes are
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:
- first produces , then and .
- first produces , then and .
The dependency 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
that holds in the relation, is a superkey.
Check the given dependencies:
| Dependency | Is the left side a superkey? | Reason |
|---|---|---|
| Yes | is a candidate key | |
| Yes | contains candidate key ? No; but does not contain , so not a superkey | |
| No | ||
| No | ||
| No |
The first dependency has a superkey determinant. However, is also not a superkey dependency because cannot derive . More importantly, , , and have determinants that are not superkeys.
For example,
Therefore,
A single valid counterexample, such as , is sufficient to disprove BCNF.
Footnotes
-
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 , at least one condition holds:
- is a superkey; or
- is a prime attribute.
The prime attributes are . The non-prime attributes are .
Check each dependency:
| Dependency | Determinant is a superkey? | Right-hand attribute prime? | 3NF status |
|---|---|---|---|
| Yes | Yes | Satisfies | |
| No | No, is non-prime | Violates | |
| No | No, is non-prime | Violates | |
| No | Yes, is prime | Satisfies | |
| No | Yes, is prime | Satisfies |
The dependency
violates 3NF because:
- is not a superkey, since ;
- is non-prime because it belongs to no candidate key.
The dependency also violates 3NF because:
- is not a superkey;
- is non-prime.
Therefore,
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
-
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
To simplify it without changing , test:
- Whether any left-hand-side attribute is extraneous.
- Whether any entire dependency is redundant.
A dependency set is equivalent to when
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
-
Minimal Cover - Explains extraneous attributes and tests for dependency simplification. ↩
Constructing a minimal equivalent cover
- 1Step 1
Use F = {ABC → D, ABD → E, CD → F, CDF → B, BF → D}.
- 2Step 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.
- 3Step 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.
- 4Step 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.
- 5Step 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.
- 6Step 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.
- 7Step 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.
- 8Step 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
Test whether is extraneous by computing under the original dependencies.
Start with
Apply the original dependency ? Its left side requires , so it cannot be applied. No other dependency can fire. Thus, under the original set alone, would not contain .
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: is not extraneous in under the original set because does not derive from the remaining dependencies.
Therefore, the initial apparent reduction
is invalid.
7.2 Corrected minimal-cover testing
The left-side reductions must be recomputed carefully:
- For , testing requires under . This is , so is not extraneous.
- Testing requires . This is , so is not extraneous.
- Testing requires . This is , so is not extraneous.
Thus, cannot be reduced.
7.3 Reducing
Test by computing using the other dependencies, excluding :
From , add :
Without , there is no way to derive . Therefore, is not extraneous under the standard test.
Likewise:
- , which does not derive ;
- , which does not derive .
Therefore, cannot be reduced.
7.4 Redundant dependency testing
Now test each complete dependency by removing it:
- Without , cannot derive .
- Without , cannot derive .
- Without , cannot derive .
- Without , cannot derive .
- Without , cannot derive .
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,
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 .
The set
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:
so is necessary.
Similarly,
so is necessary.
And
so is necessary.
Thus, removing any listed dependency changes the closure.
Functional-dependency analysis review
9. Consolidated solution
(i) All keys
The candidate keys are
The prime attributes are
The non-prime attributes are
(ii) Normal forms
The relation is not in BCNF because, for example,
holds while is not a superkey.
The relation is not in 3NF because, for example,
holds while is not a superkey and is non-prime. The dependency independently gives another 3NF violation.
Therefore,
(iii) Simplification
No dependency can be removed, and no attribute can be removed from a left-hand side without changing . Therefore,
Knowledge Check
Which of the following is a candidate key of R?
Explore Related Topics
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 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.
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 ().
- It answers “What does the user need?” unlike design (“How will it be built?”) ().
- Coding, architecture, and testing are downstream activities; the exam answer is option (ii) – understanding and documenting user needs.
Lossless vs Lossy Decomposition for Given Functional Dependencies (D1 and D2)