1장
이장에서는 일반적인 데이터베이스 이론 중 JDBC API를 이용한 어플리케이션 프로그래밍에 맞추어 필요한 부분을 설명한다. 세부적으로는 데이터베이스 시스템의 의미와 DBMS의 등장과 데이터베이스 시스템 개념의 변화, 그리고 어플리케이션과의 관계에 따른 데이터베이스 시스템의 위치와 역할에 대한 이야기들이다. 물론 어플리케이션 프로그래머로써 이해하고 있어야 할 기본적인 내용을 다루게 되므로 깊이있는 이론적인 내용은 생략하기로 하겠다.

2장
이 장에서는 어플리케이션 개발자들이 흔히 접하는 데이터베이스 설계 모델이 도출되는 과정에 대한 간략한 이야기를 하게 될 것이다. 데이터베이스 설계는 전체 어플리케이션 시스템 개발에 많은 영향을 끼친다. 잘 정리된 데이터베이스 설계는 전체 프로젝트 개발을 편하게 하는 것뿐 아니라, 개발된 시스템의 유지 보수를 매우 효율적이게 하는 것이다. 이것은 곧 확장성과 독립성에 대한 이야기가 될 것이다.

3장
어플리케이션이 개발될 때 반드시 먼저 수행되어야 하는 것 중 하나가 어플리케이션이 사용할 SQL에 대한 정의이다. 물론 미리 정의된 SQL는 완벽한 완료 시점의 SQL 정의와 차이가 있을 수 밖에 없지만, 최소한 어플리케이션 개발의 영역을 편리하고 간편하게 제한할 수 있는 방법이 될 수 있다. 이장에서는 이러한 SQL을 사용하는 문법적인 이야기를 하게 될 것이다.

4장
4장부터 9장까지는 JDBC 3.0 API에 대한 이야기를 하게 될 것이다. 물론 JDBC 3.0 API는 이전에 발표된 JDBC API를 모두 포함하고 있다. 몇몇 코드들은 실제 해당 DBMS의 JDBC 3.0 API를 지원하는 드라이버를 찾지 못한 이유로 테스트를 거치지 못하고 Sun의 명세나 문서를 참고하여 작성하였다. 따라서 이 장에서 제시하는 Savepoint와 같은 오브젝트를 이용한 코드를 여러분이 테스트하려고 한다면 Exception이 발생하게 될 것이다.

5장
DriverManager와 DataSource는 모두 Connection 객체를 획득하기 위하여 사용되는 객체들이다. 이 두 객체는 용도는 같지만 시스템에 있어서 그 위치와 사용 방식은 전혀 다르다. 혹시 여러분이 아직 DriverManager를 사용하고 있다면 DataSource로 Connection을 획득하는 객체를 바꾸라고 권하고 싶다. 아마도 상당한 고생을 해야 할 것이며, 결론적으로 어플리케이션의 수행성능상 별다른 영향을 주지는 않을 것이다. 하지만 이러한 과정을 통해 커버린 여러분의 능력은 이러한 모든 것을 감싸고도 남을 만큼이 될 것이다.

6장
직장에서 유니폼을 입어야 할 때, 여러분은 한 벌의 유니폼을 입고 더러워져 세탁을 하게 될 때 또 구입하는가? 몇 벌의 유니폼을 구입하여 돌려 입는 것이 가장 효율적일까? 이러한 문제는 ConnectionPool을 구성함에 있어서 동일한 고민으로 등장한다(물론 ConnectionPool을 구성하면 어플리케이션의 수행 속도는 눈에 뛸 정도로 향상된다). 이장에서는 ConnectionPool을 구성하기 위한 고려사항이나, 해결 방법이 제시되지 않는다. 주로 JDBC 3.0 API에서 제시한 ConnectionPool을 위한 몇몇 객체들에 대한 이야기와 이들을 사용함에 있어서 어플리케이션의 코드가 어떻게 변하게 되는지에 대한 이야기들이 될 것이다.

7장
JDBC API에서 SQL문을 실행시켜 주는 객체가 바로 Statement 객체이다. Statement 객체에는 DBMS의 기능을 이용하여 어플리케이션의 수행 성능을 향상시킬 수 있도록 여러 가지 형태가 존재한다. PreparedStatement와 CallableStatement가 그것인데, 이들이 어플리케이션 수행 성능에 미치는 영향에 대한 이야기들은 아직도 많은 개발자들 사이에서 논의 중이다. 확실한 것은 여러분이 여러분의 어플리케이션의 성격에 맞추어 사용해야만 성능의 향상이라는 결론을 도출할 수 있다는 것이다. 이장에서는 앞에 제시된 3가지 Statement의 사용법과 특징에 대하여 알아보게 될 것이다.

8장
SQL 문의 수행은 3가지 결과를 만들어 낸다. 테이블과 같은 형태의 결과값 집합이 될 수 도 있고, 수행한 SQL 문장이 해당 테이블에 존재하는 몇 개의 로우에 영향을 미쳤는가에 대한 로우 값이 될 수도 있을 것이며, 주어진 SQL 문장을 성공적으로 수행하였는지 아닌 지로 결과를 나타낼 수 도 있을 것이다. 이와 같은 결과 값에 대한 처리를 담당하는 객체가 ResultSet 객체이다. 이장에서 여러분은 ResultSet 객체에 대한 자세한 이야기를 듣게 될 것이다.

9장
흔히 JDBC 드라이버를 이용한 코드에서 보기 힘든 것이 조건에 따른 Rollback과 Commit 시점의 정의이다. 이장에서는 DBMS 내의 데이터들의 일괄성과 무결성을 유지하기 위하여 사용하는 Batch Update와 Transaction 그리고 Savepoint에 대한 이야기를 하게 될 것이다. 또 이장의 끝에서는 JDBC 3.0에서 준비한 SQL 99 표준에 따른 Data Type 객체들과 DBMS에 정의된 사용자 정의 객체(Data Type)를 사용하기 위한 방법에 대한 이야기를 보게 될 것이다.

10장
개발 방법론은 특정 기업 단위로 가지고 있어야 하거나, 프로젝트의 제안서에나 존재하는 것이 아니다. 개발자들의 몸에 배어 있어야 하는 버릇이며, 전체 프로젝트 수행 단계에 있어서. 또 수행완료 후 유지보수에 있어서 다음 단계에 존재하는 사람들에 대한 최소한의 예의이며 프로젝트 수행 비용 절감의 필수 요소이다. 저자는 이론과 문서가 개발자의 기초적인 소양이라고 본다. 이것은 얄팍한 스킬로 물고기를 잡는 것이 아니라 어떻게 하면 물고기를 잡을 수 있는지에 대한 방법이라고 할 수 있기 때문이다.

11장
이장에서는 여러분이 실무에 적용할 수 있는 ConnectionPool을 개발하기 위한 고려사항에 대한 이야기와 설계에 대한 이야기를 다루게 될 것이다. 물론 이 책에서 완성된 ConnectionPool을 적용할 것인지, 또는 개선할 것인지에 대한 것과 그에 따른 책임은 전적으로 여러분에게 달려 있음을 명시한다. 하지만 여기서 보여주는 설계 방법과 ConnectionPool을 구현하면서 보여지는 문제 해결방식은 저자가 앞에서 이야기한 얄팍한 스킬로써 여러분에게 도움이 될 것이다.

12장
어플리케이션을 완료하고 개발된 어플리케이션을 테스트하기 위한 테스트 프로그램을 만드는 일을 게을리하지 말자. 이것은 여러분이 만든 어플리케이션에서 발생할 수 있는 에러 중 최소한의 에러만을 걸러 줄뿐이지만, 이 후 발생할 수 있는 많은 에러에 대한 예측을 할 수 있는 도구로서 충분한 역할을 해준다. 이장에서는 앞서 개발된 ConnectionPool을 테스트하고 적용하여 사용하기 위한 방법들이 제공된다.

13장
프로젝트를 수행하다 보면 여러분이 구성한 SQL의 수행을 테스트하기 위한 SQL 실행기가 절실히 필요할 때가 있다. 프로젝트를 수행 중이거나 완료 후 버그를 잡아야 할 때도 DBMS 서버에 대한 접근은 완벽하게 통제되기 때문에 몇몇 프로젝트는 이 장에서 제시된 SQL 실행기와 같은 툴을 임시로 사용하는 경우가 있다.
가장 간편하게 접근할 수 있는 방법이 Web 기술을 이용하는 것인데, 이장에서는 Web 어플리케이션을 개발할 때 여러분이 선택할 수 있는 최선의 설계 방법 중 한가지인 Web용 SQL 실행기를 소개해 줄 것이다.