The first set of FDs is thus equivalent to the following irreducible cover:
A → B
A → C
D → A
D → E
The second given set of FDs
A → BC
D → AE
is clearly also equivalent to this same irreducible cover. The two given sets are thus equivalent.
7.9 The set is clearly reducible, since C → J and CJ → I together imply C → I . As for keys: An obvious
superkey is ABCDGJ (the combination of all attributes mentioned on the left sides of the given FDs). We can drop J
from this set because C → J , and we can drop G because AB → G . Since none of A , B , C , D appears on the right
side of any of the given FDs, it follows that ABCD is a key.
8.1 This exercise is (deliberately) a repeat in different words of Exercise 4.6. The claim is incorrect, as was
shown in the answer to that earlier exercise.
Here are some of my own responses to the views expressed:
“Many queries are much easier to understand if the data is denormalized”: I suspect that understand here
ought really to be formulate (for instance, understanding the query “Get all supplier details” has nothing to
do with how the database is designed). If I'm right, then the claim might be valid. But the opposite claim is
valid too!─many queries are easier to formulate if the data isn't denormalized, as I showed in the body of the
The interviewer suggests that denormalization can cause integrity problems and can reduce flexibility in
supporting unanticipated queries. I agree with these suggestions.
“Normalization, and its emphasis on elimination of redundant storage, is purely a transaction processing
issue”: Normalization is about reducing redundancy , not reducing redundant storage ─though I suppose the
consultant might be forgiven for conflating the two, given the implementations most widely available today.
But it's certainly not “a transaction processing issue”! As I put it in Chapter 1, when we do database design
in general, and when we do normalization in particular, we're concerned primarily with what the data is , not
with how it's going to be used.
“When users view data, they see it in a redundant form”: Sometimes they do, sometimes they don't. But
even if they do, that's not an argument for a denormalized design; for example, the user could be presented
with a denormalized perception of the data by means of the conventional view mechanism, while the
underlying database remains properly normalized.