Data Transfer Objects (DTOs) are obsolete. Their primary purpose was to allow appliations to interact with Enterprise JavaBeans before
EJB version 3. Before Java Persistence Architecture (JPA) in EJB3, Entity EJBs (which map database tables) carries some EJB-specific freight that made them hard to use in non-EJB code such as the GUI interaction layer of a webapp. Thus, the DTO served the purpose of transporting table information from a POJO database object in the server-side GUI code to the EJBs in the persistence layer of the web application.
Since JPA Entity objects are themselves POJOs in JPA, there's no longer any need for a separate DTO.
Now in your case, you're home-brewing a persistence model doing it all with brute-force JDBC. But since you've already mapped the Entity (table) classes, you might find it easier and simpler in the long term to simply switch over to using JPA. JPA is available in 2 forms: basic JPA as implemented in systems like Hibernate and Apache OpenJPA, and EJB JPA, where you have the full power of the Enterprise JavaBean stack at your disposal. The advantage of using basic JPA is that it doesn't require an EJB container, so it can run in non-web applications (stand-alone apps) and in partial-stack webservers like
Tomcat and jetty that don't implement EJB.
The beauty of using an Object Relational Management (ORM) system such as JPA is that you don't have to worry as much about the SQL. You can create a "working set" of Entity objects related to each other, manipulate them in the GUI layer, pass them to the business layer, then in turn to the persistence layer, which can commit them to the database in a single transaction.
There is a certain learning curve to doing this, but it's a very marketable skill, especially if you can combine it with an object management framework such as the Spring Framework, which can deal with low-level "grunt work" for you.