Computing and Candidate Keys for
We are given relation schema and a set of functional dependencies (FDs)
.
We will:
- Compute the attribute closure for sets of attributes using the standard FD-closure procedure (based on Armstrong-style reasoning).
- Use closures to derive the full closure (i.e., all FDs implied by ).
- List all candidate keys of .
Key notions: attribute closure, functional dependency closure, superkey, candidate key.
Note: Exact computation of can be large; we will compute systematically by finding which single attributes imply which others, then expanding via transitivity.
type="info" title="Strategy overview" content="Compute closures (e.g., , , , ) to identify which attributes become determined. Then convert those reachability results into implied FDs, building up . Finally, enumerate minimal attribute sets whose closure is ."
Compute key attribute closures from $F$
- 1Step 1
Initialize . Use to add . Then use to add . Then adds . With , use (already have ). So .
- 2Step 2
Initialize . From , add . With alone we cannot use (need too). Also doesn’t apply (need ). So .
- 3Step 3
Initialize . There is no FD with alone on the left (only ). So .
- 4Step 4
Initialize . There is no FD with alone on the left. So .
- 5Step 5
Initialize . From , add . Then adds . Then adds . Then confirms (already have it). So .
- 6Step 6
We have and . Also , , .
From the step-by-step closures:
- is a superkey because .
- is also a superkey because .
- is not a superkey since misses .
- and are not superkeys.
This already suggests candidate keys will be among minimal subsets of .
type="warning" title="Beware: computing is not the same as listing only original FDs" content="The closure contains all implied FDs (including ones with left-hand sides like even if not listed). We must derive implications via repeated use of FDs."
1) Compute the closure (all implied FDs)
We proceed by deriving, from each relevant determinant, which attributes it forces.
A. All FDs with left side
We know , so determines every other attribute:
Additionally, because is given, we keep:
- and we can combine:
- (Any superset on the right that does not add new info beyond is implied.)
A compact way: since , for any , we have .
B. All FDs with left side
Similarly , so determines every other attribute:
- (given)
And combinations:
- (careful: determines and separately, hence is implied)
- In general, for any , holds (and any nonempty subset of is implied).
C. FDs with left side
We found . Therefore:
- (given)
- is redundant; the meaningful ones are: . No other attribute is forced by alone, so there are no implied FDs like or (unless or are derivable—which they are not from ).
So the only nontrivial right-side implications from are those involving :
- (and thus is the only new FD with left ).
D. FDs with left side
, so there are no nontrivial FDs of the form with .
E. FDs with left side
, so there are no nontrivial FDs of the form with .
F. FDs with left side
We have (given). From that:
- Since , we get .
- Since , we get and (already have ).
- Since , we get (already have ).
Therefore , meaning:
- (given)
- (any subset of ) In particular, etc. are implied.
Also note: is the “seed” that makes a superkey.
G. FDs with left side , , etc.
In principle, once the closure of a left-hand set is , then any FD from that left-hand set to any subset of the remaining attributes is implied. For example:
- is already because already closes everything. Hence etc. But enumerating every possible left-hand set would be exhaustive; typically in database courses, is described by the closure computation rules plus all derived FDs at the level of single attributes and given minimal determinants.
To keep the course section precise, we’ll list the core implied FDs (single-attribute and the original multi-attribute ones) that arise necessarily from the closures above.
Core implied dependencies (a practical representation of )
From the closure results:
- From :
- plus the given (and therefore is implied, etc.)
- From :
- (given)
- plus any combined forms such as etc. (implied)
- From :
- (given)
- no implied
- From :
- (given)
- and thus any subset of
- No nontrivial implications from or alone:
- no additional FDs of the form ()
- no additional FDs of the form ()
2) List the candidate keys for
A candidate key is a minimal superkey.
We already computed:
- so is a superkey.
- so is a superkey.
- Any set containing is a superkey, but itself is minimal (cannot remove ).
- Any set containing is a superkey, but itself is minimal.
Also, sets without or :
- cannot reach or .
- , .
- is a superkey (because then closure reaches all), but it is not minimal because neither nor alone is a superkey, and for candidate key minimality, we check whether can be reduced to a smaller superkey. Any smaller subset of is either or , neither of which is a superkey. So is minimal among its subsets—however, candidate keys are minimal superkeys overall: since neither nor is a superkey, qualifies as a candidate key.
So candidate keys are:
Closure-to-candidate-key workflow
Compute single-attribute closures
1Find ."
Identify superkeys
2Any with is a superkey."
Enforce minimality
3Candidate keys are superkeys whose proper subsets are not superkeys."
Enumerate candidates
4Conclude minimal superkeys: , , and ."
Closure sizes for single attributes
How many attributes each single attribute determines under .
FAQ: common pitfalls
Knowledge Check
Which of the following is true under ?