- xrath.com 에서 번역됨

[목차] [전의 항목] [다음의 항목]

## 처음에

주: 이 장의 내용은, Addison Wesley 사부터 Java 시리즈의 1 권으로서 출판된 「JDBCTM API Tutorial and Reference, Second Edition:Universal Data Access for the JavaTM 2 Platform」(ISBN 0-201-43328-1)에 근거해 작성한 것입니다.

JDBCTM API 는, JavaTM 프로그램 언어를 위한 일반적인 데이터 액세스를 제공하는 어플리케이션 프로그래밍 인터페이스입니다. 데이터 액세스의 기본적인 기능을 제공하는 JDBC 1.0 API 를 포함하고 있습니다. JDBC 2.0 API 는, 보다 진보한 기술로 기본 API 를 추가합니다. 또, 오늘의 RDB 관리 시스템에 의해 지원되고 있는, 최신의 객체 릴레이셔널 기능에 액세스 하는 표준적인 방법을 제공합니다. 게다가 이 새로운 API 에는, 스크롤 및 갱신이 가능한 결과 세트의 기능이 추가되어 퍼포먼스의 향상이 더해지고 있습니다. 또, 접속 풀 및 분산 트랜잭션(transaction)에 의해, 클라이언트로부터 서버에 액세스 할 수가 있습니다.

### 1.1 JDBC 2.0 API 에 포함되는 API

JDBC 2.0 API 에는, Java SE 의 일부인 API 의 모두와 JDBC 표준 확장 기능 API 에 포함되는 API 가 포함됩니다. 다음의 일람에서는, JDBC API 의 설명에 사용되는 다양한 용어에 대해 정의합니다.

- JDBC 2.0 API - 완전한 JDBC API. `java.sql` 패키지 (JDBC 2.0 코어 API) 및 `javax.sql` 패키지 (JDBC 표준 확장 기능 API)를 포함하고 있습니다. J2EE 에는 완전한 JDBC 2.0 API 가 포함되어 있습니다.
- JDBC 2.0 코어 API - 패키지 `java.sql` (Java SE 에 포함되는 JDBC API). 이 패키지에는, JDBC 1.0 API 에 가세해`java.sql` 패키지에 새롭게 추가된 JDBC API 가 포함되어 있습니다. 이 패키지에는, 스크롤 가능한 결과 세트, 배치 갱신, 프로그램에 의한 갱신, SQL3 의 새로운 데이터형의 지원등의 신기능이 추가되고 있습니다.
- JDBC 표준 확장 기능 API - `javax.sql` 패키지. `http://java.sun.com/products/jdbc` 로부터 다운로드할 수 있습니다. 이 패키지는, 접속 풀링 및 복수 데이터 베이스 서버-에 걸치는 분산 트랜잭션(transaction)를 지원하는 오픈 아키텍쳐(architecture)의 제공에 의해, Java 플랫폼을 스펙 한 서버측 어플리케이션의 구축을 용이하게 합니다. `DataSource` API 는, 이러한 기능의 핵심입니다. Java Naming and Directory InterfaceTM (JNDI)와 함께 사용하면(자), 이식성이 향상해, 코드의 보수를 간단하게 실시할 수가 있습니다. 또,`javax.sql` 패키지에서는,`RowSet` API 도 제공됩니다. 이 패키지를 사용하면(자), 거의 모든 데이터 소스의 데이터 세트를, JavaBeansTM 컴퍼넌트로서 간단하게 조작할 수 있습니다.
- `java.sql` 패키지 - JDBC 2.0 코어 API. JDBC 1.0 API, 및 J2SE 에 추가된 새로운 API 가 포함됩니다.

- `javax.sql` 패키지 - JDBC 표준 확장 기능 API

하위 호환성이 확보되고 있기 (위해)때문에, JDBC 1.0 API 를 사용해 작성된 어플리케이션은, 지금까지와 같게, Java SE, 및 J2EE 상에서 실행할 수가 있습니다. JDBC 1.0 API 는, 완성도가 높기 때문에, 기본적으로는 변경되고 있지 않습니다. 다만, JDBC 2.0 API 에 추가된 기능을 사용하고 있는 어플리케이션은, 그러한 기능이 지원되고 있는 드라이버를 사용해 실행할 필요가 있습니다.

코어 API 의 일부인 `java.sql` 패키지는, Java SE 의 다운로드시에 자동적으로 받아들여집니다. `javax.sql` 패키지를 드라이버의 벤더가 드라이버에 짜넣는 일도 있습니다. 드라이버에 패키지가 짜넣어지지 않은 경우는, 다음의 URL 의 JDBC 의 Web 사이트로부터 다운로드할 수 있습니다.

>     http://java.sun.com/products/jdbc

또,`javax.sql` 패키지는, J2EE 를 다운로드해 취득할 수도 있습니다. J2EE 에는,`java.sql` 및 `javax.sql` 패키지가 포함되어 있습니다. Enterprise JavaBeanstm (EJB)의 컴퍼넌트 또는 그 외의 서버 코드를 작성하지 않은 경우는, 사용하는 디스크 용량을 제한하기 위해서, J2EE 는 아니고 Java SE 를 다운로드하는 것을 추천합니다.

### 1.2 JDBC API 란

JDBC API 는, 거의 모든 테이블 형식의 데이터에 액세스 할 수 있는 Java API 입니다. (덧붙여 JDBC 는, 약호는 아니고 상표입니다만, 「Java Database Connectivity」의 약어라고 생각되는 일이 자주 있습니다. ) JDBC API 는, Java 프로그램 언어로 기술된 클래스 및 인터페이스세트로 구성됩니다. JDBC API 에 의해, 툴 및 데이타베이스 개발자를 위한 표준 API 가 제공되기 (위해)때문에, 모두 Java 로 기술된 API 를 사용해, 업계에서 강력한 데이타베이스 어플리케이션을 작성할 수가 있습니다.

JDBC API 는, SQL 문을 RDB 시스템에 간단하게 송신할 수가 있고 그리고 모든 SQL 구문을 지원하고 있습니다. 그러나, SQL 이외에도, 테이블 형식의 데이터를 포함한 파일 등, 그 외의 종류의 데이터 소스라고 대화할 수 있습니다.

JDBC API 의 가치는, 어플리케이션으로부터 거의 모든 데이터 소스에 액세스 할 수 있어 Java Virtual Machine 가 가동하고 있는 모든 플랫폼상에서 어플리케이션을 실행할 수 있는 것입니다. 즉, JDBC API 를 사용하면, Sybase 데이타베이스, Oracle 데이타베이스, IBM DB2 데이타베이스 등에 액세스하기 위한 프로그램을 개별적으로 작성할 필요가 없습니다. JDBC API 를 사용해 프로그램을 1 개 작성하면, 그 프로그램이 SQL 또는 그 외의 문장을 적절한 데이터 소스에 송신할 수가 있습니다. 게다가, Java 프로그램 언어로 쓰여진 어플리케이션을 사용하면(자), 다른 플랫폼에서 실행하는 경우에도, 다른 어플리케이션을 작성할 걱정은 필요 없습니다. Java 플랫폼과 JDBC API 를 조합하는 것으로, 프로그래머는 한 번 작성하면, 임의의 장소에서 실행할 수가 있습니다.

Java 프로그램 언어는, 강고해 안전, 사용하기 쉽게 이해하기 쉬운 데다가, 네트워크상에서 자동적으로 다운로드할 수 있는, 데이타베이스 어플리케이션을 위한 매우 뛰어난 기반 언어입니다. 필요한 것은, Java 어플리케이션이 다른 다양한 데이터 소스와 교환하기 위한 방법입니다. JDBC 는, 이것을 행하기 위한 기구입니다.

JDBC 2.0 API 에 의해, Java 플랫폼의 기능이 확장됩니다. 예를 들어, JDBC API 에서는, 원격 데이터 소스로부터 취득한 정보를 사용하는 애플릿이 포함되는 Web 페이지를 발행할 수가 있습니다. 또, 기업은 JDBC API 를 사용해, 사원 전원을 인트라넷 경유로 1 개 이상의 내부 데이타베이스에 접속할 수가 있습니다 (Windows, Macintosh, 및 UNIX 머신이 혼재하고 있는 경우에서도 같이). Java 언어를 사용하는 프로그래머가 증가하는 것에 따라, Java 로부터 범용성이 있는 데이터 액세스를 용이하게 실시할 필요가 계속 증가하고 있습니다.

Java 플랫폼과 JDBC 테크놀러지를 조합하면(자), 정보의 배포가 용이하고 경제적으로 되므로, MIS 매니저는 Java 와 JDBC 테크놀러지의 편성을 좋아합니다. 기업은, 자사에서 인스톨 끝난 데이타베이스를 계속해 사용하면서, 다른 데이타베이스 관리 시스템 또는 그 외의 데이터 소스에 포함되고 있는 경우에서도, 정보에 용이하게 액세스 할 수가 있습니다. 신규 어플리케이션의 개발 시간도 단축됩니다. 인스톨과 버젼 관리는 큰폭으로 간소화됩니다. 프로그래머가 어플리케이션의 작성이나 갱신을 한 번만 행해 서버에 두는 것만으로, 누구나가 최신 버젼에 액세스 할 수 있게 됩니다. 또, 정보 서비스를 판매하는 기업에 있어, Java 와 JDBC 테크놀러지의 편성은, 외부의 커스터머에 최신 정보를 배포하는, 보다 좋은 방법을 제공합니다.

#### 1.2. 1 JDBC API 로 무엇이 가능할까

간단하게 정리하면(자), JDBC 테크놀러지 베이스의 드라이버 ( 「JDBC 드라이버」)를 사용해 다음의 3 개의 조작을 실시할 수가 있습니다.

1. 데이터 소스와의 접속의 확립
2. 데이터 소스에의 쿼리 및 갱신문의 송신
3. 실행 결과의 처리

   다음에 나타내는 코드의 일부분은, 이러한 3 개의 스텝의 간단한 예입니다.

>     Connection con = DriverManager.getConnection(
>     					"jdbc:myDriver:wombat", "myLogin", "myPassword");
>     Statement stmt = con.createStatement();
>     ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1");
>     while (rs.next()) {
>     	int x = rs.getInt("a");
>     	String s = rs.getString("b");
>     	float f = rs.getFloat("c");
>     	}

#### 1.2. 2 그 외의 API

JDBC API 는, SQL 커멘드를 직접 호출할 때 사용합니다. 그 점에서 매우 자주(잘) 기능하고 있으므로, 그 외의 데이타베이스 접속 API 보다 사용하기 쉽게 되어 있습니다만, 한층 더 대체의 인터페이스 및 툴을 작성하기 위한 기초가 되도록(듯이)도 설계되고 있습니다. 대체의 인터페이스는, 내부에서 JDBC API 에 변환되는, 보다 알기 쉽고보다 편리한 API 를 사용하는 것에 의해 「사용자 플렌들리」가 되어 있습니다. 왜냐하면, JDBC API 는 기반으로서 사용되는데 충분히 완전하고 강력하고, 다양한 대체의 API 가 JDBC API 위에 벌써 개발되고 있기 때문입니다. 예를 들어 다음의 대체 API 가 있습니다.

1. Java 용 편입 SQL. Oracle, IBM, Sun 등으로 구성되는 컨소시엄에 의해, 이 API 를 제공하기 위한 SQLJ 스펙이 정의되고 있습니다. JDBC 에서는, 기본적으로, SQL 문을 미해석의 캐릭터 라인으로서 Java 메소드에 건네줄 필요가 있습니다. 편입 SQL 프리프로세서에 의해, 컴파일시에 형태 체크를 하기 (위해)때문에, 프로그래머는 SQL 문과 Java 프로그램 언어의 문장을 혼합할 수 있습니다. 예를 들어, SQL 문 중(안)에서 Java 변수를 사용해, SQL 치의 수수를 실시할 수가 있습니다. SQLJ 프리프로세서는, 실제로는 이러한 Java 와 SQL 의 혼재 코드를, JDBC 호출을 포함한 Java 프로그램 언어로 변환합니다.
2. RDB 테이블의 Java 클래스에의 직접 매핑. Java Software 는, 이 기능을 제공하기 위해서 Java BlendTM 제품을 발표하고 있습니다. 또, 그 외의 벤더도, 같은 제품을 제공하고 있습니다. 이 「객체/릴레이셔널」매핑에서는, 1 개의 테이블이 1 개의 클래스가 되어, 테이블의 각 행이 그 클래스의 인스턴스가 되어, 각 열의 값이 그 인스턴스의 속성에 대응합니다. 따라서, 프로그래머는, Java 객체를 직접 조작할 수가 있습니다. 데이터를 페치 하거나 스토어 하거나 하는데 필요한 SQL 호출은, 「수면 아래에서」에 자동적으로 생성됩니다. 또, Java Blend 에 의해, 보다 정교한 매핑, 예를 들어 복수의 테이블의 행이 1 개의 Java 클래스에 짜 합쳐진다라고 하는 매핑도 제공되고 있습니다.

JDBC 테크놀러지에의 관심이 높아지는 것에 따라, 프로그램의 작성을 용이하게 하기 위해서, 그 외의 JDBC 베이스의 툴도 개발되어 왔습니다. 예를 들어, 어느 어플리케이션은, 선택할 수 있는 데이타베이스 태스크의 메뉴를 표시합니다. 태스크가 선택되면(자) 어플리케이션은, prompt, 및 선택한 태스크를 실행하기 위해서 필요한 정보를 입력하는 공백을 표시합니다. 요구된 정보를 입력하면(자), 어플리케이션은 자동적으로 필요한 JDBC 커멘드를 기동합니다. 사용자는, SQL 구문을 거의 또는 전혀 몰라도, 이러한 어플리케이션의 도움에 의해 데이타베이스 태스크를 실행할 수가 있습니다.

#### 1.2. 3 JDBC API 와 ODBC 및 UDA 와의 대비

JDBC API 가 개발될 때까지는, Microsoft 의 ODBC (Open DataBase Connectivity) API 가, RDB에 액세스 하기 위해서 가장 넓게 사용되고 있던 프로그래밍 인터페이스였습니다. 이것은, 거의 모든 플랫폼의 거의 모든 데이타베이스에 접속하는 능력을 갖추고 있습니다. 그럼, Java 로부터 직접 ODBC 를 사용하지 않는 것은 왜입니까.

그것은, ODBC 를 Java 로부터 사용하는 것은 가능합니다만, JDBC-ODBC 브릿지의 형식에서 JDBC API 를 사용해 실시하는 것이 최선의 방법이기 때문입니다. 거기서, 다음에 나오는 질문은, 「왜 JDBC API 가 필요한가」라고 하는 것입니다.

이 질문에 대해서는, 다음과 같이 몇개의 대답이 있습니다.

1. ODBC 는 C 인터페이스를 사용하고 있으므로, Java 프로그램 언어로부터 직접 사용하기에는 적절하지는 않습니다. Java 로부터 네이티브 C 코드에의 호출은, 시큐리티, 구현, 견뢰함, 및 어플리케이션의 자동 이식성 위에서 많은 결점이 있습니다.
2. ODBC C API 를 Java API 에 리터럴로 변환하는 것은 바람직하지는 않습니다. 예를 들어, Java 에서는 포인터 (주소 변수)는 사용됩니다만, ODBC 에서는 에러가 발생하기 쉬운 일로 악명 높은 총칭 포인터 void * 를 포함 포인터가 빈번하게 사용됩니다. JDBC 는, Java 프로그램 언어를 사용하는 프로그래머에게 있어 자연스럽다 높은 수준의 객체 지향 인터페이스로 번역된 ODBC 로서 생각할 수가 있습니다.
3. ODBC 는 학습이 곤란합니다. 이것에는 간단한 기능과 고도의 기능이 혼재해, 또 간단한 쿼리에도 복잡한 옵션이 있습니다. 한편, JDBC API 는, 간단한 (일)것은 간단한 그대로에 유지하면서, 필요한 경우에는 고도의 기능을 사용할 수 있도록(듯이) 설계되고 있습니다. 또, JDBC API 는, Java API 이므로, 프로그래머는 메모리 메니지먼트 및 데이터 바이트의 배열을 고려할 필요가 없습니다.
4. JDBC 와 같은 Java API 는, 「Pure Java」솔루션을 가능하게 하기 위해서 Java API 만을 이용한 솔루션이 필요하게 됩니다. ODBC 를 사용하는 경우, ODBC 드라이버 매니저와 드라이버를, 모든 클라이언트 머신에 수동으로 인스톨 할 필요가 있습니다. 그러나, JDBC 드라이버가 완전하게 Java 로 쓰여져 있으면(자), JDBC 코드는, 네트워크 컴퓨터로부터 메인프레임에 이르는 모든 Java 플랫폼에의 자동 인스톨이나 이식이 가능하고, 안전합니다.

요약하면(자), JDBC API 는 SQL 를 사용해 동작시키기 위한 자연스러운 Java 인터페이스입니다. 이것은, 제로로부터 작성되고 있는 것이 아니라 ODBC 상에 작성되고 있으므로, ODBC 에 익숙해 있는 프로그래머는, JDBC API 를 매우 학습하기 쉽다고 느끼겠지요. JDBC API 는 ODBC 의 기본 설계의 특징의 일부를 남기고 있어 실제, 어느 쪽의 인터페이스도 Open Group (이전의 X/Open) SQL CLI (Call Level Interface)를 기초로 하고 있습니다. 큰 차이는, JDBC API 가 Java 의 스타일과 장점에 근거해 구축되고 그리고, 그것들이 강화되고 있는 것입니다. 이것은, 단지 SQL 분을 RDB 관리 시스템에 보내는 만큼 머물고 있지 않습니다.

Microsoft 는, OLE (Object Linking and Embedding) DB, ADO (ActiveX Data Objects), RDS (Remote Data Service)등의 ODBC 보다 뛰어난 새로운 API 를 도입하고 있습니다. 이러한 API 는, JDBC API 와 많은 점으로써 공통점이 있습니다. 예를 들어, OLE DB 및 ADO 도, 데이타베이스용의 객체 지향의 인터페이스로, SQL 문을 실행할 수 있습니다. 다만, OLE DB 는, 툴을 위해서(때문에) 설계된 저레벨의 인터페이스로, 개발자전용이 아닙니다. ADO 는, 보다 새로운 인터페이스로, JDBC API 와의 공통점도 많이 존재합니다만, Pure Java 가 아닙니다. RDS 는, JDBC API 의 `RowSet` 기능에 유사한 기능을 제공하고 있습니다만, Java 프로그램 언어로 기술되지 않고, 이식성은 없습니다.

최근, Microsoft 는, OLE DB, ADO, RDS, 및 ODBC 를 포함 하는 용어로서 UDA (Universal Data Access)를 도입했습니다. JDBC 2.0 API 에는, UDA 의 중요한 기능이 모두 포함되어 있어 SQL3 지원등의 UDA 에는 없는 기능이 포함되어 있습니다.

#### 1.2. 4 2 층 모델과 3 층 모델

JDBC API 는, 데이타베이스 액세스의 2 층 모델과 3 층 모델의 양쪽 모두를 지원합니다.

그림 1.1: 는, 2 층 아키텍쳐(architecture)의 데이터 액세스를 나타냅니다.

2 층 모델에서는, Java 의 애플릿 또는 어플리케이션은 데이터 소스와 직접 교환합니다. 이것에는, 액세스 하고 있는 특정의 데이터 소스와 교환할 수 있는 JDBC 드라이버가 필요합니다. 사용자의 커멘드는 데이타베이스 또는 그 외의 데이터 소스에 전달되어 그러한 문장의 결과가 사용자에게 돌려 보내집니다. 그 때, 데이터 소스를, 네트워크 경유로 사용자가 접속하고 있는 것 외의 머신에 두는 일도 가능합니다. 이것은, 클라이언트/서버 구성으로 불려 사용자의 머신이 클라이언트, 데이터 소스를 가지는 머신이 서버로 불립니다. 네트워크는, 예를 들어 사내에서 사원끼리를 잇는 인트라넷에서도, 인터넷으로도 괜찮습니다.

3 층 모델에서는, 커멘드가 서비스의 「중간층」에 송신되어 중간층이 커멘드를 데이터 소스에 송신합니다. 데이터 소스는, 커멘드를 처리해 결과를 중간층에 돌려 보내, 중간층이 그것을 사용자에게 보냅니다. 3 층 모델에서는 중간층이 기업 데이터에 대해서 실시할 수 있는 액세스 및 갱신의 종류에 대해 제어를 유지할 수가 있으므로, MIS 의 책임자는 이 모델을 매우 매력적이라고 생각하고 있습니다. 또, 어플리케이션의 개발이 간단하게 됩니다. 마지막으로, 많은 경우, 3 층 아키텍쳐(architecture)가 퍼포먼스상의 이점이 있습니다.

그림 1.2: 는, 3 층 아키텍쳐(architecture)의 데이터 액세스를 나타냅니다.

최근까지, 중간층은 일반적으로 C 또는 C++ 와 같은 고속의 퍼포먼스를 제공하는 언어로 작성되어 왔습니다. 그러나, Java 바이트 코드를 효율적인 머신 고유 코드로 변환하는 최적화 컴파일러, 및 Enterprise JavaBeans 등의 테크놀러지가 도입되었기 때문에, Java 플랫폼이 중간층의 개발용의 표준 플랫폼으로서 급속히 보급하고 있습니다. 이것은 큰 진보로, Java 의 견뢰함, multi-thread 처리, 및 시큐리티 기능을 이용할 수 있게 됩니다.

서버 코드를 작성할 경우에 Java 프로그램 언어를 사용하는 기업이 증가하고 있어, JDBC API 가 3 층 아키텍쳐(architecture)의 중간층으로 사용되는 것이 많아지고 있습니다. JDBC 를 서버 테크놀러지로 하고 있는 기능은, 접속 풀, 분산 트랜잭션(transaction), 및 절단행 세트가 지원되게 되었습니다. 또, Java 의 중간층으로부터 데이터 소스에 액세스 할 수가 있습니다.

#### 1.2. 5 SQL 의 호환성

SQL 는, RDB에 액세스하기 위한 표준 언어입니다. 그러나, SQL 는 아직 당초 예측된 표준으로서 다루어지고 있지 않습니다.

곤란한 일면은, 다른 DBMS (DataBase Management System)로 사용되는 데이터형이 때로는 다양하고, 그 차이가 중대하게 될 수 있는 것입니다. JDBC 에서는, 이 문제에 대해서,`java.sql.Types` 클래스내에서 총칭 SQL 의 형태 식별자세트를 정의하는 것으로써 대처하고 있습니다. 본서로 사용되도록(듯이), 「JDBC SQL 형」, 「JDBC 형」, 및 「SQL 형」은, 모두 같은 의미로 사용되고 있어 이러한 용어는,`java.sql.Types` 로 정의되고 있는 총칭 SQL 의 형태 식별자를 나타내고 있습니다. 데이터형의 적합성의 상세한 것에 대하여는, 「SQL 와 Java 의 형태의 매핑」을 참조해 주세요.

SQL 적합성에 대한 이제(벌써) 1 개의 문제는, 대부분의 DBMS (데이타베이스 관리 시스템)는, 기본 기능에 표준 형식의 SQL 를 사용하고 있습니다만, 보다 고도의 기능에 대해서 최근 정의된 표준 SQL 구문이나 시멘틱스에 적합하지 않은 것입니다. 예를 들어, 모든 데이타베이스가 스트아드프로시쟈나 외부 결합을 지원하고 있는 것은 아니고, 또 지원하고 있는 것 같은 종류에 서로 항상 일관성이 없습니다. 또, SQL3 의 기능 및 데이터형의 지원도 크게 다릅니다. SQL 의 정말로 표준적인 부분이, 보다 많은 기능을 가지도록(듯이) 확장되는 것이 바람직합니다. 그러나, 당분간은, JDBC API 가 SQL 를 그대로 지원할 필요가 있습니다.

JDBC API 가 이 문제에 대처하는 1 개의 방법은, 모든 쿼리캐릭터 라인을, 기반이 되는 DBMS 드라이버에 건네줄 수 있도록(듯이) 하는 것입니다. 즉, 어플리케이션은, 바라는 한 SQL 기능을 자유롭게 사용할 수가 있습니다만, DBMS 로부터 에러를 받는 위험이 있습니다. 실제, 어플리케이션의 쿼리는 SQL 이외의 것에서도 자주(잘), 특정의 DBMS 를 위해서(때문에) 설계된 SQL 의 특별한 형식 (문서 또는 화상 쿼리 등)에서도 괜찮습니다.

JDBC 가 SQL 의 적합성의 문제에 대처하는 2 번째의 방법은, ODBC 스타일의 이스케이프구를 사용하는 것입니다. 이스케이프 구문은, 표준의 JDBC 구문에, 보다 일반적으로 이용되는 SQL 의 확장 기능을 몇개인가 제공합니다. 예를 들어, 일자 리터럴 및 스트아드프로시쟈 호출을 위한 이스케이프가 있습니다.

복잡한 어플리케이션에서는, JDBC 는 3 번째의 방법으로 SQL 의 적합성에 대처합니다. JDBC 는, 어플리케이션이 각 DBMS 의 필요 조건이나 기능에 적합하도록(듯이),`DatabaseMetaData` 인터페이스를 사용해 DBMS 에 대한 기술 정보를 제공합니다. 다만, 표준적인 최종 사용자는, 메타데이타에 대해 걱정할 필요는 없습니다.

JDBC API 는, 데이타베이스 액세스 툴 및 그 외의 API 를 개발하기 위한 기본 API 로서 사용되므로, 그 위에 구축되는 것에 대한 적합성의 문제에도 언급할 필요가 있습니다. JDBC 드라이버는, ANSI SQL-92 이상의 엔트리 레벨을 지원하고 있지 않으면 안됩니다. (ANSI SQL-92 는, 1992 년에 미국 규격 협회가 채용한 표준입니다. 엔트리 레벨은, 특정의 SQL 기능입니다. ) 다만, JDBC 2.0 API 에서는 SQL3 및 SQLJ 가 지원되고 있습니다만, JDBC 드라이버에서의 지원는 요구되지 않습니다.

JDBC API 는, 데이타베이스 벤더, 접속 벤더, 인터넷 서비스 벤더, 및 어플리케이션 작성자에게 더욱 더 넓게 받아들여지게 되었기 때문에, 벌써 Java 프로그램 언어에 의한 데이터 액세스의 표준이 되어 있습니다.

#### 1.2. 6 JDBC 제품

JDBC API 를 사용하면(자), Java 의 어플리케이션 및 애플릿으로부터 데이타베이스에 대해서 간단하게 액세스 할 수 있기 (위해)때문에, JDBC API 는 Java 플랫폼을 사용하고 있는 사용자에게 있어 자연스러운 선택이 됩니다.

이 문서가 작성된 시점에서는, 몇개의 JDBC 베이스의 제품이 벌써 출하 끝나 또는 개발중입니다. 이러한 제품 상태는 빈번하게 변화하므로, 최신의 정보에 대해서는, JDBC 의 Web 페이지를 참조해 주세요. 이 Web 사이트는 다음의 URL 에 있습니다.

>     http://java.sun.com/products/jdbc

#### 1.2. 7 Java Software 시스템

Java Software 는, 이하의 3 개의 JDBC 제품 컴퍼넌트를 제공하고 있습니다.

- JDBC 드라이버 매니저 (Java 2 플랫폼에 편입이 끝난 상태)
- JDBC 드라이버 테스트 스위트 (JDBC Web 사이트로부터 입수 가능)

- JDBC-ODBC 브릿지 (Solaris 및 Windows 버젼의 Java 2 플랫폼에 편입이 끝난 상태)

`DriverManager` 클래스는 전통적으로 JDBC 아키텍쳐(architecture)의 신념이 되고 있습니다. 이것은 매우 작고 간단한 클래스입니다. 그 주된 기능은, Java 어플리케이션을 올바른 JDBC 드라이버에 접속해, 또 그것을 없애는 것입니다. 표준 확장 기능 패키지의 `javax.naming` 및 `javax.sql` 를 사용할 수 있기 (위해)때문에, Java Naming and Directory InterfaceTM (JNDI) 네임 서비스에 등록된 `DataSource` 객체를 사용해 데이터 소스와의 접속을 확립할 수 있게 되었습니다. 어느 방법에서도 접속할 수 있습니다만, 가능한 경우에는 `DataSource` 객체의 사용을 추천합니다.

JDBC 드라이버 테스트 스위트하게보다 , JDBC 드라이버가 사용자의 프로그램을 실행할 때의 신뢰성이 어느 정도 얻을 수 있습니다. 이 테스트는, 종합 테스트 또는 상세 테스트가 아닙니다만, JDBC API 의 중요한 기능의 대부분을 테스트할 수 있습니다.

JDBC-ODBC 브릿지에 의해, ODBC 드라이버를 JDBC 드라이버로서 사용할 수 있습니다. 이것은, JDBC 를 곧바로 사용하기 위한 방법으로서 구현되고 있습니다. 장래적으로는, JDBC 드라이버가 구현되어 있지 않은 데이터 소스의 몇개인가에 액세스 하는 방법도 제공할 예정입니다.

#### 1.2. 8 JDBC 드라이버의 타입

그림 1.3: 는, 다양한 드라이버 구현의 예입니다.

[D]

JDBC 테크놀러지 베이스의 드라이버는, 일반적으로, 다음의 4 개의 카테고리의 어떤 것인가에 해당합니다.

1. JDBC-ODBC 브릿지와 ODBC 드라이버의 편성. Java Software 의 브릿지 제품은, ODBC 드라이버 경유의 JDBC 액세스를 가능하게 합니다. ODBC 바이너리코드, 및 많은 경우의 데이타베이스 클라이언트 코드는, 이 드라이버를 사용하는 클라이언트 머신에 둘 필요가 있습니다. 결과적으로, 이런 종류의 드라이버는, 클라이언트의 인스톨이 큰 문제는 되지 않는 기업 네트워크나, Java 로 3 층 아키텍쳐(architecture)에 작성된 어플리케이션 서버 코드에 최적입니다.
2. 일부가 Java 드라이버인 네이티브 API. 이런 종류의 드라이버는, JDBC 호출을 Oracle, Sybase, Informix, IBM DB2, 또는 그 다른 DBMS 를 위한 클라이언트 API 에서의 호출에 변화시킵니다. 이 스타일의 드라이버를 사용하는 경우, 브릿지 드라이버와 같이, 일부의 operating system 고유의 바이너리코드를 각 클라이언트 머신에 로드할 필요가 있습니다.
3. JDBC-넷 Pure Java 드라이버:이 드라이버는, JDBC 호출을 DBMS 에 의존하지 않는 넷 프로토콜로 변환합니다. 그 후로 서버에 의해 DBMS 프로토콜에 변환됩니다. 이 넷 서버 미들웨어는, 그 Pure Java 클라이언트를 많은 다른 데이타베이스에 접속할 수 있습니다. 사용되는 이 특유의 프로토콜은 벤더에 의존합니다. 일반적으로, 이것이 가장 유연한 JDBC 의 대체입니다. 이 솔루션의 벤더는 모두, 인트라넷에서의 사용에 맞은 제품을 제공하려고 하고 있는 것 같습니다. 이러한 제품이 인터넷 액세스도 지원하기 위해서는, Web 가 부과하는 시큐리티나 방화벽(fire wall)를 통한 액세스등의 요구를 취급할 필요가 있습니다.
4. 네이티브 프로토콜 Pure Java 드라이버. 이런 종류의 드라이버는, JDBC 호출을 DBMS 가 사용하는 네트워크 프로토콜에 직접 변환합니다. 이것에 의해, 클라이언트 머신으로부터 DBMS 서버에의 직접 호출이 가능하게 됩니다. 인트라넷 액세스를 위한 뛰어난 솔루션이라고 할 수 있습니다. 이러한 프로토콜의 상당수는 소유권에 근거하고 있으므로, 데이타베이스 벤더 자신이 주된 공급원이 됩니다. 현재, Oracle, Sybase, Informix, IBM DB2, Inprise InterBase, 및 Microsoft SQL Server 를 포함해 따분한가의 데이타베이스로 사용할 수 있습니다.

드라이버의 카테고리 3 으로 4 는, JDBC API 를 사용해 데이타베이스에 액세스 하는데 적합합니다. 카테고리 1 으로 2 의 드라이버는, 직접 Pure Java 드라이버가 아직 사용 가능하지 않은 동안의 과도기적인 솔루션입니다. 카테고리 1 으로 2 에는 (이하의 테이블에는 가리키지 않았다) 미들웨어를 필요로 하는 종류의 것이 가능합니다만, 일반적으로는 바람직한 솔루션의 레벨에는 도달하고 있습니다. 카테고리 3 으로 4 가, 자동 인스톨을 시작해로 한, Java 테크놀러지의 모든 이점을 제공합니다 (예를 들어, JDBC 드라이버를, 그것을 사용하는 애플릿과 함께 다운로드하는 등).

표 1.1 에, 4 개의 카테고리와 그 프로퍼티을 나타냅니다. 이 표에서는, 네트워크 접속의 종류에 대해, 다음의 정의를 사용하고 있습니다.

- 직접 - JDBC 클라이언트가 DBMS 서버에 대해서 직접 행하는 접속. 원격 접속의 경우도 있다
- 간접 - JDBC 클라이언트가, DBMS 서버에 대한 브릿지로서 기능하는 미들웨어 프로세스에 대해서 실시하는 접속

  드라이버의 카테고리 | 모두 Java 화도인가 | 네트워크 접속
  --- | --- | ---
  1 - JDBC-ODBC 브릿지 | 아니오 | 직접
  2 - 기본적으로 네이티브 API | 아니오 | 직접
  3 - JDBC-Net | 클라이언트 - 네 서버 - Java 가 아닌 것도 있다 | 간접
  4 - 기본적으로 네이티브 프로토콜 | 네 | 직접

#### 1.2. 9 JDBC 드라이버의 입수

이 문서가 작성된 시점에서는, Java Software 의 브릿지와 함께 사용할 수 있는 카테고리 1 의 ODBC 드라이버가 많이 있습니다. DBMS 용의 네이티브 API 위에 구축되고 있는 카테고리 2 의 드라이버는 약 12 있습니다. 카테고리 3 의 드라이버는, 다수 이용할 수 있습니다. 주요한 DBMS 에는, 카테고리 4 의 드라이버가 존재합니다.

드라이버에 대한 최신의 정보를 가져오려면 , 다음에 나타내는 JDBC 의 Web 페이지를 참조해 주세요.

>      http://java.sun.com/products/jdbc

Java Software 및 주요한 데이타베이스 접속 벤더인 Intersolv 는, 협력해 JDBC-ODBC 브릿지와 JDBC 드라이버의 테스트 스위트의 개발에 임하고 있습니다.

#### 1.2. 10 Java 릴레이셔널 DBMS

Java 릴레이셔널 DBMS 로 불리는, Java 대응의 차세대 DBMS 가 발표될 예정입니다. 이 새로운 DBMS 에는, 새로운 데이터형이 짜넣어지고 있어 Java 프로그램 언어의 객체를 데이타베이스 테이블의 열의 값으로 해서 사용할 수가 있습니다. JDBC 2.0 의 신기능에서는, 이 차세대의 DBMS 가 지원되고 있습니다. 또, 복수의 데이타베이스 벤더가, Java 릴레이셔널 기능을 사용한 제품을 개발중입니다. 다만, 이 2.0 의 기구는 옵션입니다. DBMS 로 이 기능이 지원되어 있지 않은 경우, JDBC 2.0 드라이버에서는 이 기능을 구현할 필요는 없습니다.

#### 1.2. 11 그 외의 제품

다양한 JDBC 어플리케이션의 개발이 진행중입니다. 최신 정보에 대해서는, Java Software 의 페이지를 참조해 주세요.

[목차] [전의 항목] [다음의 항목]

Copyright © 1999, Sun Microsystems, Inc. All rights reserved.