Is it necessary to do all the mapping of all the tables with hibernate?

It all depends on the configuration of your project, hibernate at the end is an abstraction layer based on data that you can decide to exploit or not. That already depends on each company and each project, you can follow several approaches with hibernate that depend on the configuration in the application.properties or the .yml of your project:

spring.jpa.hibernate.ddl-auto

This value is what defines how restrictive it is to hibernate in your project and can take several values:

create: Hibernate manages the database, that is, when you lift the project, what you have in your database is deleted and hibernate creates your schema data based on entities.

update: Hibernate checks your database and your entities, the database does not touch or delete anything. Then Hibernate reviews the entities and checks if each entity and each field exist in the database, if they do not exist, it creates them but respecting what already exists. In this approach, your entities do not have to match the database, if you have an entity with fewer columns than in the database, absolutely nothing happens.

validate: Hibernate never creates anything in the database, the only thing it does is to check that the data types and names in your entities are correct with the database. if you have a field like Integer in your entity but that is varchar2 in bbdd, hibernate will generate an error and will not let you lift the project.

So the answer to your question is that hibernate accepts several approaches and it is a decision of the architecture of the application which one you want to adopt.

In hibernate you must have a Class for each Table that you will persist and that will not generate more dependencies to other tables. Once you have all the tables that you are going to persist in database, if there are too many there is the Hibernate Reverse Engineering and with that hibernate generates all the classes and mappings for what you are going to persist. If there are tables that you do not use, do not generate those mappings.

There are as many solutions as colors. You must understand that hibernate allows you to "model" your database with java objects. But this model does not have to be a reflection of reality and, even if it is, there are several ways to do it. I'll give you an example: If we want to model a "n to n" relationship, we can model it:

• With 2 entities and some @manytomany annotations
• With 3 entities and annotations @ManyToOne (modeling the middle table)
• Modeling the relationship not as objects but as an attribute of type ID

And these are just some of the possibilities. There are many more. We may not even want our application to know about the existence of the relationship, or any of the tables. We usually think that when we create an application the database is ours, but keep in mind that maybe you are making an application that only uses a part of the database, because the system is huge and you only manage part of it. .

That said:

• Should you have an entity for each table to take advantage of Hibernate? No. You can do many things (bad and good). You can have several entities by a single table. You can not have any if you're never going to use it. I can have an entity that models the table Users without relationships for quick queries with 2 or three fields and another one that models the relationships with roles so that they are always linked (this would prevent you from having to ask at runtime if the list of roles has come from database or not). If the question is when I do one thing or another ... That is the master question !! It depends a lot on what you are doing, what is bad practice in one environment is advisable in others. The best thing to do is to ask the question with a specific problem.

• Is there specifically something in the documentation that deals with this? No. The Hibernate documentation is going to explain how and what you can do, but as I've already left you between-see what you do with that information is up to you. You will find thousands of articles that explain how to model certain problems, generally based on modeling everything with the least number of classes, having many relationships in all classes. From my humble opinion it is best to model what you need, if you use a table in 2 different ways you may have to think about modeling it in two different ways (or change the database, but I will not go into that). To know how to decide the best is the experience that in the previous project you modeled things in one way and it worked well, or ended up generating problems, unclear logics, etc ...