Functional Dependencies and Candidate Keys in
In the relation schema with functional dependency set , the correct statement is:
(iv) Neither nor is a key.2
A candidate key must determine every attribute in the relation, including .2 Here, determines , and determines , so and are mutually determining attributes. However, there is no functional dependency involving on the right-hand side, so neither nor can include under the given FD set.2
Thus:
Since neither closure equals , neither nor is a superkey, and therefore neither can be a candidate key.2
A useful rule of thumb is that if an attribute such as is not derivable from other attributes, then any key must include it. So the actual candidate keys are:
Footnotes
-
Determining candidate keys with functional dependencies simple - Explains key-finding heuristics, including that attributes not derivable from others must appear in every key. ↩ ↩2 ↩3 ↩4
-
Closure of a Set of Functional Dependencies - Describes attribute closure computation and use of Armstrong-derived inference rules. ↩ ↩2 ↩3
-
Candidate key - Wikipedia - Defines candidate keys as minimal sets whose closure contains all attributes of the relation. ↩ ↩2 ↩3
-
Candidate Keys (LSU PDF) - Defines superkeys and candidate keys using attribute closure over the full relation schema. ↩ ↩2
-
Normalization – Relational Databases - Notes that if also holds, then and can both be candidate keys only when they determine the remaining attributes as well. ↩
Attribute Closure and Candidate Keys in DBMS
Correct Option
For with and , the true statement is (iv) Neither nor is a key because neither determines .2
Footnotes
-
Determining candidate keys with functional dependencies simple - Explains key-finding heuristics, including that attributes not derivable from others must appear in every key. ↩
-
Closure of a Set of Functional Dependencies - Describes attribute closure computation and use of Armstrong-derived inference rules. ↩
To understand why, we use attribute closure.2 The closure of a set , written , contains every attribute that can be inferred from using the given functional dependencies.
For this problem:
| Attribute set | Start | Apply FDs | Closure |
|---|---|---|---|
| gives | |||
| gives | |||
| gives | |||
| gives |
Because a key must determine all attributes of , both and fail, but and succeed.2
This also illustrates minimality: although determines all attributes, neither nor alone does, so is minimal and hence a candidate key.2
Footnotes
-
Candidate key - Wikipedia - Defines candidate keys as minimal sets whose closure contains all attributes of the relation. ↩ ↩2 ↩3
-
Candidate Keys (LSU PDF) - Defines superkeys and candidate keys using attribute closure over the full relation schema. ↩ ↩2 ↩3
-
Determining candidate keys with functional dependencies simple - Explains key-finding heuristics, including that attributes not derivable from others must appear in every key. ↩
How to Solve This Question Systematically
- 1Step 1
List the full schema as . A key must determine all three attributes: , , and .2
Footnotes
-
Candidate key - Wikipedia - Defines candidate keys as minimal sets whose closure contains all attributes of the relation. ↩
-
Candidate Keys (LSU PDF) - Defines superkeys and candidate keys using attribute closure over the full relation schema. ↩
-
- 2Step 2
Use the FD set . These show mutual determination between and only.
Footnotes
-
Normalization – Relational Databases - Notes that if also holds, then and can both be candidate keys only when they determine the remaining attributes as well. ↩
-
- 3Step 3
Start with . By reflexivity, determines itself. Using , add . No dependency adds , so .2
Footnotes
-
Closure of a Set of Functional Dependencies - Describes attribute closure computation and use of Armstrong-derived inference rules. ↩
-
Candidate Keys (LSU PDF) - Defines superkeys and candidate keys using attribute closure over the full relation schema. ↩
-
- 4Step 4
Start with . By reflexivity, determines itself. Using , add . No dependency adds , so .2
Footnotes
-
Closure of a Set of Functional Dependencies - Describes attribute closure computation and use of Armstrong-derived inference rules. ↩
-
Candidate Keys (LSU PDF) - Defines superkeys and candidate keys using attribute closure over the full relation schema. ↩
-
- 5Step 5
Since neither nor equals , neither nor is a superkey.
Footnotes
-
Candidate key - Wikipedia - Defines candidate keys as minimal sets whose closure contains all attributes of the relation. ↩
-
- 6Step 6
Because neither single attribute determines all attributes, the correct answer is (iv) Neither nor is key.2
Footnotes
-
Determining candidate keys with functional dependencies simple - Explains key-finding heuristics, including that attributes not derivable from others must appear in every key. ↩
-
Closure of a Set of Functional Dependencies - Describes attribute closure computation and use of Armstrong-derived inference rules. ↩
-
Common Exam Trap
Students often see and and conclude both are keys. That is incorrect unless they also determine . A key must cover the entire relation schema, not just part of it.2
Footnotes
-
Candidate key - Wikipedia - Defines candidate keys as minimal sets whose closure contains all attributes of the relation. ↩
-
Candidate Keys (LSU PDF) - Defines superkeys and candidate keys using attribute closure over the full relation schema. ↩
A deeper conceptual point is that and are equivalent with respect to each other, but not with respect to the whole relation. In other words, they can replace each other when deriving or , yet neither can generate .2
Using Armstrong's axioms such as reflexivity and transitivity, we can derive:
- by reflexivity
- by reflexivity
- given
- given
But there is still no derivation of or .2 Therefore, remains outside both single-attribute closures.
This is why many database design heuristics note that an attribute not derivable from others often must appear in every key. Here, must be included in any candidate key, yielding and as the minimal keys.2
Footnotes
-
Normalization – Relational Databases - Notes that if also holds, then and can both be candidate keys only when they determine the remaining attributes as well. ↩ ↩2 ↩3
-
Closure of a Set of Functional Dependencies - Describes attribute closure computation and use of Armstrong-derived inference rules. ↩ ↩2
-
Determining candidate keys with functional dependencies simple - Explains key-finding heuristics, including that attributes not derivable from others must appear in every key. ↩ ↩2
-
Candidate key - Wikipedia - Defines candidate keys as minimal sets whose closure contains all attributes of the relation. ↩
To test whether is a key, compute . Since and does not contain , is not a key. Similarly, , so is not a key.2
Footnotes
-
Candidate key - Wikipedia - Defines candidate keys as minimal sets whose closure contains all attributes of the relation. ↩
-
Candidate Keys (LSU PDF) - Defines superkeys and candidate keys using attribute closure over the full relation schema. ↩
Closure Coverage of Attribute Sets
How many attributes each set determines in
Clarifications and Edge Cases
Reasoning Roadmap for FD-Based Key Questions
List Attributes
Step 1Identify the complete schema, here ."
Footnotes
-
Candidate key - Wikipedia - Defines candidate keys as minimal sets whose closure contains all attributes of the relation. ↩
Read FDs Carefully
Step 2Note that the only dependencies are and ."
Footnotes
-
Normalization – Relational Databases - Notes that if also holds, then and can both be candidate keys only when they determine the remaining attributes as well. ↩
Compute Closures
Step 3Find and to test whether either determines the full schema."
Footnotes
-
Candidate Keys (LSU PDF) - Defines superkeys and candidate keys using attribute closure over the full relation schema. ↩
Test for Full Coverage
Step 4Observe that both closures miss , so neither is a key.2"
Footnotes
-
Determining candidate keys with functional dependencies simple - Explains key-finding heuristics, including that attributes not derivable from others must appear in every key. ↩
-
Closure of a Set of Functional Dependencies - Describes attribute closure computation and use of Armstrong-derived inference rules. ↩
Find Minimal Keys
Step 5Add and test and ; both become candidate keys.2"
Footnotes
-
Determining candidate keys with functional dependencies simple - Explains key-finding heuristics, including that attributes not derivable from others must appear in every key. ↩
-
Candidate key - Wikipedia - Defines candidate keys as minimal sets whose closure contains all attributes of the relation. ↩
Fast Key Detection Heuristic
If an attribute never appears as derivable from other attributes, suspect that it must be included in every candidate key. In this problem, must appear in every key.
Footnotes
-
Determining candidate keys with functional dependencies simple - Explains key-finding heuristics, including that attributes not derivable from others must appear in every key. ↩
Final Answer
For the relation with :
Neither closure contains , so neither nor is a key.3
Therefore, the correct option is:
The actual candidate keys are:
Footnotes
-
Determining candidate keys with functional dependencies simple - Explains key-finding heuristics, including that attributes not derivable from others must appear in every key. ↩
-
Closure of a Set of Functional Dependencies - Describes attribute closure computation and use of Armstrong-derived inference rules. ↩
-
Candidate key - Wikipedia - Defines candidate keys as minimal sets whose closure contains all attributes of the relation. ↩
Knowledge Check
For with , what is ?
Explore Related Topics
Algorithm Property for Clear, Unambiguous Steps: Definiteness
The course clarifies that definiteness is the algorithm property requiring every step to be precise and have exactly one interpretation, distinguishing it from finiteness, effectiveness, and generality.
- Definiteness: each instruction is specified so precisely that only one meaning is possible.
- Finiteness concerns termination, effectiveness concerns executability, and generality concerns applicability to all valid inputs.
- Example: “repeat 3 times” is definite, while “repeat several times” is not.
- Exam tip: associate words like “clear,” “precise,” or “unambiguous” with definiteness.
- Algorithm quality can be expressed as .
Hierarchy and Power of Bottom-Up Parsers: SLR, LALR, and CLR
Bottom‑up LR parsers form a strict hierarchy of power: LR(0) < SLR < LALR < CLR, with each level able to handle all grammars of the lower levels.
- SLR uses LR(0) items and resolves conflicts with FOLLOW sets; it is the weakest but simplest LR parser.
- LALR builds full LR(1) items then merges states that share the same core, keeping the same number of states as SLR while adding look‑ahead precision.
- CLR (canonical LR) retains all LR(1) states and look‑aheads, giving it the highest grammar coverage at the cost of many more states.
- Merging CLR states to form LALR can introduce reduce‑reduce conflicts (never shift‑reduce), making LALR strictly less powerful than CLR.
- In practice, tools like Yacc/Bison prefer LALR because it balances power with manageable memory usage.
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.
