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.
8.2 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 chapter.
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. ...