In the simplest cases, yes, you will have one pojo per table.
However, that is somewhat the point of object/relational mapping. If your table space (schema) does not match your business derived space (objects) then you may "fix" it in the mapping. Look at a Hibernate "component" as an example.
There are all sorts of issues/tradeoffs here so if you are just getting your feet wet, then you will most likely find tutorials that map a table to a pojo. Also, if you are dealing with a mature database schema, then you will find a lot of one to one correspondence. However, if the schema has been heavily normalized, you may end up with too many pojos that don't make sense in your object world.
Actually, you will find that you want your Objects to be as OO like as possible, if you do a one to one relationship between tables and objects, you are most likely not being completely OO. I say most likely, because if you have a small amount of tables, it might come out to 1 to 1. But with Inheritence and Value Types, you can find you will have more Java objects than tables.
The other reason I say that, is you are designing your object model based on the tables, instead of designing your obects thinking in OO, which is not a great idea.