You could probably implement it more efficiently, although that issue is
really orthogonal to how your beans map to tables.  It does seem like
you might benefit from a more loosely coupled model.  Here's a suggestion:

(a) You should have one bean each for the Employees, Address, and
Projects tables.  These beans should each manage data for one row of the
target table, having properties for the relevant columns, and the
ability to load, update, and insert rows.  It is probably useful for
each to maintain a sense of whether its data has been modified since
loading so as to judge whether it is necessary to update the DB with its
current data.

(b) You should have another bean that manages a complete set of employee
information -- an Employee bean and the associated Address and Projects
beans.  The linking tables don't need to be explicitly modeled because
the relationships they describe are implicit in this bean's structure.
Where you need more than one of the tables for a particular JSP, this
bean would manage loading related beans and presenting them to the JSP,
then storing the data when done.  It would use the other three beans to
do the dirty work.

Your JSPs could then access and manipulate individual employee, address,
or project info independantly if they need to do, or can get a broader
view if they so desire.  You maintain per-row information regarding
whether data needs to be updated, saving your database considerable
work.  The logic for managing the bean relationships remains abstracted
into a bean as it is now, relieving the JSPs from having to deal with
it.  (A Good Thing)

John Bollinger
jobollin@indiana.edu