The beauty of Relational Database design is partly due to the notion that any piece of data need only be stored once and then accessed as needed in many contexts. Primary and Foreign Keys can not be truly described as "redundancies". You don't specify whether or not Product ID ISBN and Author number are used as keys. Generally a table should contain the match field and whatever data fields directly and necessarily relate. No more or less.
Not using the relational abilities of Filemaker would be a terrible shame. It could be that the Access guy has simply used the wrong term - the fields you name don't strike me as 'redundant'. The nearest I can think of to make sense, and to involve the 'speed' word, is that if data is copied from one table to another and stored twice then it can be searched more quickly in both tables. In that sense, one copy of the data is considered 'redundant', in that is is available elsewhere. However the speed difference is seldom an issue, and the other huge benefits you lose, and other problems of synchronisation you create, are a considerable loss.
I believe your understanding is the better practice, by a long way.
Rick and Sorbsbuster,
Product ID is the primary key in his DB design. I didn't stop to analyse the word "redundancy" but you're both spot on. None of the fields in his assesment are exactly a redundancy. He's just splitting the fields into several tables with very few fields on them.
Can't see any benefit with this approach. I'll keep working as usual. Many thanks for shinnning a light unto me!