"One class per table" is a rule of thumb, good to start with. But it's not carved into stone. You can (and should) assess the needs of your app, the forecasted usage patterns of your data etc. It is not uncommon to map several tables to a single class, neither the opposite: to represent a single table to multiple classes.
It is recommended to design your classes based on the OO paradigm (as opposed to just trying to map them to your table structure). If needed, you then fine-tune your class design to match the requirements from your data layer.
In your concrete case, it depends on whether you foresee the need to fetch book data alone (without author & category), or is it more typical that you need all 3 at once. It is also a question how many properties the author and category have.
If you often fetch only the book data and/or the author & category have many properties, it makes more sense to keep them in separate classes. If you keep them in one class, you will have lots of duplicated data (because many books will have the same category or author data), and you will always need to unnecessary load 3 rows with a join from DB, so you pay a performance penalty for nothing in most of the cases.
OTOH if you usually fetch data from all 3 tables at once, it might make sense to keep them in a single class. Even then, I would opt for separate classes though, to avoid duplication of category data. Moreover, you may even be able to cache your categories & authors better if these are in separate entities rather than part of the Book class.
A lot depends on your development language and tools as well; e.g. in Java with an ORM tool like Hibernate, it is much easier to set these mappings, use lazy fetching and fine-tune the fetch plan as you learn more about your application, then e.g. using JDBC.