The designers of JDBC had several objectives when they created their specifications. They wanted to give developers the maximum amount of flexibility when coding their applications and making their SQL requests. They also wanted to hide the details of creating and managing a connection to a DBMS to the maximum degree possible. This is in keeping with the "write once, run anywhere" philosophy of Java.

JDBC provides two services to a Java application.

1. One is the database access task--here SQL commands are composed and sent to the database.
2. The second is the messy business of connecting to the database system itself and providing the information needed to deal with that process.

Since nearly all relational DBMS use SQL for database management, the JDBC designers decided to adopt a model that would allow developers to pass SQL requests, untranslated, directly to the DBMS being used. These SQL commands are composed by a developer, packaged as a text string, and sent to the database for processing. The underlying connection that transports the SQL request is separated from that process and managed through a different layer of software.

That connection layer manages the details about what is required to connect to a specific DBMS system. This is called a database driver and is handled and loaded by a driver manager class.
This separation of work makes JDBC very powerful. It makes it easier to write applications that are not as tightly tied to a specific database system as they might otherwise be. This helps preserve the portability of the application.
It also limits and places bounds on the "non-object orientedness" introduced into a Java application. The JDBC wraps access to the non-object oriented world of a relational database in an object-oriented format. This keeps JBDC methods consistent with the style and strengths of Java applications.

Click the Exercise link below to analyze where JDBC could be used to solve your client's business problem.
Understanding JDBC - Exercise