JDBC とODBCの違い
1.1 JDBCTMとは
JDBCTM は、SQL 文を実行するための JavaTM API です (参考までに、JDBC は登録名であって略語ではありません。しかし、JDBC は「Java Database Connectivity」の略だと思われることがよくあります)。これは、Java プログラミング言語で書かれたクラスとインタフェースのセットから構成されます。JDBC は、ツール/データベース開発者のための標準 API を提供し、Pure Java API を使用したデータベースアプリケーションの作成を可能にします。
JDBC を使用すると、SQL 文を実質的には任意のリレーショナルデータベースに送ることが容易になります。すなわち、JDBC API を使用すると、Sybase データベースにアクセスするためにプログラムを 1 つ作成し、Oracle データベースにアクセスするために別のプログラムを作成し、Informix データベースにアクセスするためにまた別のプログラムを作成するという必要がありません。JDBC API を使用してプログラムを 1 つ作成すれば、そのプログラムが SQL 文を適切なデータベースに送信することができます。その上、Java アプリケーション言語で書かれたアプリケーションを使用すると、異なるプラットフォームで実行する場合にも、異なるアプリケーションを作成する必要がありません。Java と JDBC を組み合わせることにより、プログラマはプログラムを 1 つ作成して、それをどこででも実行することができるようになります。
Java は強固で安全、使いやすく理解しやすい上に、ネットワーク上で自動的にダウンロードできる、データベースアプリケーションのための非常に優れた基盤言語です。必要なのは、Java アプリケーションが異なる多様なデータベースとやり取りするための方法です。JDBC は、これを行うための機構です。
JDBC は、Java の機能を拡張します。たとえば、Java や JDBC API では、リモートデータベースから取得した情報を使用するアプレットが入った Web ページを発行することができます。また、企業は JDBC を使用して、社員全員をイントラネット経由で 1 つ以上の内部データベースに接続することができます (Windows,、Macintosh、および UNIX マシンが混在している場合でも同様)。Java 言語を使用するプログラマが増加するにつれて、Java からデータベースに容易にアクセスする必要が増え続けています。
Java と JDBC を組み合わせると、情報の配布が容易かつ経済的になるので、MIS マネージャは Java と JDBC の組み合わせを好みます。企業は自社ですでにインストール済みのデータベースを引き続き使用しながら、異なるデータベース管理システムに格納されている場合でも、その情報に容易にアクセスすることができます。新規アプリケーションの開発時間も短縮されます。インストレーションとバージョン制御は大幅に簡素化されます。プログラマはアプリケーションを作成し、またはそれを 1 度更新してサーバに置くだけで、誰もが最新バージョンにアクセスできるようになります。また、情報サービスを販売する企業にとって、Java および JDBC は、外部のカスタマに最新情報を配布する、よりよい方法を提供します。
1.1.1 JDBC で何ができるか
簡単にいえば、JDBC によって以下の 3 つのことができるようになります。
# データベースとの接続の確立
# SQL 文の送信
# SQL 文実行結果の処理
以下のコードの一部分は、これらの 3 つのステップの簡単な例を示します。
Connection con = DriverManager.getConnection (
"jdbc:odbc:wombat", "login", "password");
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.1.2 JDBC は下位 API であり、上位 API の基礎である
JDBC は、「下位」インタフェース、すなわち SQL コマンドを直接起動する (または「呼び出す」) ために使用されるインタフェースです。これはこの能力において非常によく機能し、ほかのデータベース接続 API より使いやすいだけでなく、上位インタフェースおよびツールを作成するための基礎となるようにも設計されています。上位インタフェースとは、よりわかりやすくより便利な API を使用した「ユーザフレンドリ」なインタフェースのことで、その背後で JDBC のような下位インタフェースに翻訳されます。このガイドを書いている時点では、以下の 2 種類の上位 API が JDBC の上に開発中です。
1. Java 用埋め込み SQL。少なくとも 1 つのベンダーがこれを作成しようとしています。DBMS は、データベースに使用するために特に設計された言語である SQL を実装します。JDBC では、SQL 文が Java メソッドへの文字列として渡されることが必要です。埋め込み SQL プロセッサにより、プログラマはこの代わりに SQL 文を Java に直接混在させることができます。たとえば、Java 変数は SQL 文の中で使用して、SQL 値の受け渡しを行うことができます。すると、埋め込み SQL プリプロセッサは、この Java/SQL ミックスを JDBC 呼び出しを持つ Java に翻訳します。
2. リレーショナルデータベーステーブルの Java クラスへの直接マッピング。Java ソフトウェアなどがこれを実装する計画を発表しています。この「オブジェクト/リレーショナル」マッピングでは、テーブルの各行がそのクラスのインスタンスとなり、各カラムの値がそのインスタンスの属性に対応します。したがってプログラマは、Java オブジェクトを直接操作することができます。データをフェッチしたりストアしたりするのに必要な SQL 呼び出しは、「カバーの下」に自動的に生成されます。より精巧なマッピング、たとえば複数のテーブルの行が 1 つの Java クラスに組み合わされるというようなマッピングも提供されています。
JDBC への関心が高まるにつれて、プログラムの作成を容易にする JDBC ベースのツールに取り組む開発者も増えてきました。プログラマはまた、エンドユーザがデータベースに容易にアクセスできるアプリケーションも作成しています。たとえば、あるアプリケーションは、そこから選択できるデータベースタスクのメニューを表示するというようにです。タスクを選択すると、アプリケーションはプロンプトと選択したタスクを実行するために必要な情報を入力するブランクを表示します。要求された情報を入力すると、アプリケーションは自動的に必要な SQL コマンドを起動します。ユーザは、SQL 構文をほとんどまたはまったく知らなくても、このようなアプリケーションの助けによってデータベースタスクを実行することができます。
1.1.3 JDBC 対 ODBC およびほかの API
現時点では、Microsoft の ODBC (Open DataBase Connectivity) API が、リレーショナルデータベースにアクセスするためにもっとも広く使用されているプログラミングインタフェースでしょう。これは、ほとんどすべてのプラットフォームのほとんどすべてのデータベースに接続する能力を備えています。それでは、ODBC を Java から使用しないのはなぜでしょうか。
それは、ODBC を Java から使用することは可能ですが、このあとで説明するJDBC-ODBC ブリッジの形で JDBC の力を借りて行うのが最良の方法であるためです。そこで次に出てくる質問は、「なぜ JDBC が必要なのか?」です。この質問に対しては、以下のようにいくつかの答えがあります。
1. ODBC は C インタフェースを使用しているので、Java から直接使用するには適切ではありません。Java からネイティブ C コードへの呼び出しは、セキュリティ、実装、堅牢さ、およびアプリケーションの自動移植性の上で多くの欠点があります。
2. ODBC C API を Java API にリテラルに翻訳することは好ましくありません。たとえば、Java がポインタを持たない場合に ODBC がそれらを頻繁に使用すると、エラーを生じやすいことで悪名高い汎用ポインタ void * が取り込まれます。JDBC は、Java プログラマにとって自然なオブジェクト指向インタフェースに翻訳された ODBC と考えることができます。
3. ODBC は学習が困難です。これには簡単な機能と難解な機能が混在し、また簡単なクエリーにも複雑なオプションがあります。一方、JDBC は、簡単なことは簡単なままでありながら、必要な場合には高度な機能が使用できるように設計されています。
4. Java API は JDBC と同様、「Pure Java」ソリューションを可能にするために必要です。ODBC を使用すると、ODBC ドライバマネージャとドライバを、すべてのクライアントマシンに手動でインストールする必要があります。しかし、JDBC ドライバが完全に Java で書かれていると、JDBC コードは、ネットワークコンピュータからメインフレームに至るすべての Java プラットフォームへの自動インストールや移植が可能であり、安全です。
要約すると、JDBC API は基本的な SQL の概要と概念への自然な Java インタフェースです。これは、ゼロから作成されているのではなく ODBC の上に作成されているので、ODBC に慣れているプログラマは、JDBC を非常に学習しやすいと感じることでしょう。JDBC は ODBC の基本設計の特徴を残しており、実際、インタフェースはどれも X/Open SQL CLI (Call Level Interface) を基礎としています。大きな相違点は、JDBC が Java のスタイルと長所の上に構築され、それを強化している点と、使いやすい点です。
最近、Microsoft は、RDO、ADO、および OLE DB という、ODBC を超える新規の API を発表しました。これらの設計は、JDBC と多くの点において同じ方向、すなわち、ODBC 上に実装可能なクラスを基礎としたオブジェクト指向データベースインタフェースへと移行しています。しかし、特に ODBC 市場が成熟していることを考えると、これらのインタフェースのどれにも ODBC に代わる基礎となるような魅力的な機能は見られません。これらはほとんど ODBC の上に薄い化粧板を貼ったようなものです。しかし、これは JDBC が最初のリリースから発展する余地がないという意味ではありません。ほとんどの新機能は、前の項で述べたオブジェクト/リレーショナルマッピングおよび埋め込み SQL のような上位 API に属すると考えられます。
1.1.4 2 層モデルと 3 層モデル
JDBC API は、データベースアクセスの 2 層モデルと 3 層モデルの両方をサポートします。
2 層モデルでは、Java アプレットまたはアプリケーションはデータベースと直接やり取りします。これには、アクセスしている特定のデータベース管理システムとやり取りできる JDBC ドライバが必要です。ユーザの SQL 文はデータベースに配信され、それらの文の結果がユーザに送り返されます。データベースは、ユーザがネットワーク経由で接続されているほかのマシンに置くことも可能です。これは、クライアント/サーバ構成と呼ばれ、ユーザのマシンがクライアント、データベースを持つマシンがサーバと呼ばれます。ネットワークは、たとえば社内で社員同士をつなぐイントラネットでも、インターネットでもかまいません。
3 層モデルでは、コマンドがサービスの「中間層」に送信され、中間層が SQL 文を データベースに送信します。データベースは SQL 文を処理して結果を中間層に送り返し、中間層がそれをユーザに送ります。3 層モデルでは中間層が企業データに対して行えるアクセスおよび更新の種類について制御を維持することができるので、MIS の責任者はこのモデルを非常に魅力的だと考えています。そのほかの利点として、中間層があると、中間層によって適切な下位呼び出しに翻訳された使いやすい上位 API を利用することができます。最後に、多くの場合、3 層アーキテクチャの方がパフォーマンス上の利点があります。
現在までのところ、中間層は通常 C または C++ のような高速なパフォーマンスを提供する言語で作成されてきました。しかし、Java バイトコードを効率的なマシン固有コードに翻訳する最適化コンパイラが導入されて、Java で中間層を実装することが現実的になっています。これは大きな進歩で、Java の堅牢さ、マルチスレッド処理、およびセキュリティ機能を利用できるようになります。JDBC は、Java の中間層からのデータベースアクセスを可能にするのに重要です。
1.1.5 SQL の適合性
Structured Query Language (SQL) は、リレーショナルデータベースにアクセスするための標準言語です。困難な面は、1 つにはほとんどの DBMS (データベース管理システム) は、基本機能に標準形式の SQL を使用するにもかかわらず、高度機能のために最近定義された標準 SQL 構文やセマンティクスに適合していないことです。たとえば、すべてのデータベースがストアドプロシージャやアウタジョインをサポートしているわけではなく、またサポートしているもの同士に互いに一貫性がありません。SQL の本当に標準的な部分が、より多くの機能を持つように拡張することが望まれます。しかし、当分の間は、JDBC API が SQL をそのままサポートする必要があります。
JDBC API がこの問題に対処する 1 つの方法は、すべてのクエリー文字列を基盤の DBMS ドライバに渡せるようにすることです。すなわち、アプリケーションは、望む限りの SQL 機能を自由に使用することができますが、DBMS からエラーを受け取る危険があります。実際、アプリケーションのクエリーは SQL である必要すらなく、特定の DBMS のために設計された SQL の特別な形式 (たとえば、ドキュメントまたは画像クエリー) でもかまいません。
JDBC が SQL の適合性の問題に対処する 2 番目の方法は、「4.1.5 Statement オブジェクト内の SQL エスケープ構文」で説明する ODBC スタイルのエスケープ節を使用することです。
エスケープ構文は、標準の JDBC 構文に、より一般的に利用される SQL の拡張機能をいくつか提供します。たとえば、日付リテラルやストアドプロシージャ呼び出しのためのエスケープがあります。
複雑なアプリケーションでは、JDBC が 3 番目の方法で SQL の適合性に対処します。JDBC は、アプリケーションが各 DBMS の必要条件や機能に適合するように、DatabaseMetaData インタフェースを使用して、DBMS についての記述情報を提供します。
JDBC API は、上位データベースアクセスツールおよび API を開発するための基本 API として使用されるので、ここでもその上に構築されるものについての適合性の問題に対処する必要があります。ユーザが頼ることができる標準レベルの機能性を設定するために、JDBC COMPLIANTTM という指定が作成されました。この指定を使用するためには、ドライバが最低 ANSI SQL-2 エントリレベルをサポートする必要があります (ANSI SQL-2 は、1992 年に米国規格協会が採用した標準を指す)。ドライバ開発者は、JDBC API に付属のテストスイートを使用して、自分が開発したドライバがこの標準に適合することを確認できます。
JDBC COMPLIANTTM 指定は、ベンダーの JDBC 実装が Java ソフトウェアの提供する適合性テストに合格したことを示します。この適合性テストは、JDBC API に定義されたすべてのクラスとメソッドが存在することを確認し、および SQL エントリレベル機能が使用可能であることをできる限り確認します。このテストは完璧なものではなく、Java ソフトウェアは現在、ベンダーの実装を認定することはしていませんが、この適合性定義により、JDBC の実装にある程度の信頼が与えられます。JDBC API がデータベースベンダー、接続ベンダー、インターネットサービスベンダー、およびアプリケーション作成者にますます広く受け入れられるにつれて、JDBC は早くも Java データベースアクセスの標準となりつつあります。
1.2 JDBC 製品
このドキュメントが作成された時点では、いくつかの JDBC ベースの製品がすでに出荷済みまたは開発中です。この項の情報はすぐに時代遅れになるので、最新の情報については、JDBC の Web ページを参照してください。これは以下の URL から探すことができます。
http://java.sun.com/products/jdbc
1.2.1 Java ソフトウェアの構造
Java ソフトウェアは、Java Developer's Kit (JDK) の一部として、以下の 3 つの JDBC 製品構成要素を提供します。
* JDBC ドライバマネージャ
* JDBC ドライバテストスイート
JDBC ドライバマネージャは、JDBC アーキテクチャのバックボーンです。これは実際は非常に小さくて簡単です。その主な機能は、Java アプリケーションを正しい JDBC ドライバに接続し、またそれを取り除くことです。
JDBC ドライバテストスイートにより、JDBC ドライバがあるプログラムを実行することがある程度信頼できます。JDBC ドライバテストスイートに合格したドライバだけが、JDBC COMPLIANTTM として指定されます。
JDBC-ODBC ブリッジにより、ODBC ドライバを JDBC ドライバとして使用できます。これは、JDBC をすぐに使用できるようにするための方法として実装されます。将来的には、あまり一般的でない DBMS に JDBC ドライバが実装されていない場合、それらの DBMS のいくつかにアクセスする方法も提供する予定です。
1.2.2 JDBC ドライバのタイプ
現時点で認識している JDBC ドライバは、以下の 4 つのカテゴリのどれかにあたります。
1. JDBC-ODBC ブリッジと ODBC ドライバの組み合わせ: Java ソフトウェア ブリッジ製品は、ODBC ドライバ経由の JDBC アクセスを可能にします。ODBC バイナリコード、および多くの場合のデータベースクライアントコードは、このドライバを使用するクライアントマシンに置く必要があります。結果として、この種のドライバは、クライアントのインストールが大きな問題にはならない企業ネットワークや、Java で 3 層アーキテクチャに作成されたアプリケーションサーバコードに最適です。
2. 一部が Java ドライバであるネイティブ-API: この種のドライバは、JDBC 呼び出しを Oracle、Sybase、Informix、DB2、またはそのほかの DBMS のためのクライアント API での呼び出しに変化させます。このスタイルのドライバはブリッジドライバと同様、一部のバイナリコードを各クライアントマシンにロードする必要があります。
3. JDBC-ネット Pure Java ドライバ: このドライバは、JDBC 呼び出しを DBMS 独立のネットプロトコルに変換し、それがサーバによって DBMS に変換されます。このネットサーバミドルウェアは、その Pure Java クライアントを多くの異なるデータベースに接続することができます。使用されるこの特定のプロトコルはベンダーに依存します。一般的に、これはもっとも柔軟な JDBC の代替です。このソリューションのベンダーはすべて、イントラネットでの使用にあった製品を提供しようとしているようです。これらの製品がインターネットアクセスをもサポートするためには、Web が課するセキュリティやファイヤウォールを通じたアクセスなどの必要条件も処理する必要があります。ベンダーによっては、JDBC ドライバを自社の既存のデータベースミドルウェア製品に追加しようとしているところもあります。
4. ネイティブプロトコル Pure Java ドライバ: この種のドライバは、JDBC 呼び出しを DBMS が使用するネットワークプロトコルに直接変換します。これにより、クライアントマシンから DBMS サーバへの直接呼び出しが可能になるので、イントラネットアクセスのための実質的なソリューションといえます。これらの多くは固有のプロトコルなので、データベースベンダー自身がプライマリソースであり、複数のデータベースベンダーがこれらを開発中です。
結局、3 と 4 のカテゴリが JDBC からデータベースにアクセスする好ましい方法だと考えられます。カテゴリ 1 と 2 のドライバは、直接 Pure Java ドライバがまだ使用可能でない間の過渡的なソリューションです。カテゴリ 1 と 2 には (以下のテーブルには示していない) コネクタを必要とする種類のものが可能ですが、一般的には望ましいソリューションのレベルには到達していません。カテゴリ 3 と 4 が自動インストールを始めとし、Java のすべての利点を提供します (たとえば、JDBC ドライバを、それを使用するアプレットとともにダウンロードすること)。
以下の表に、4 つのカテゴリとそのプロパティを示します。
ドライバのカテゴリ すべて JAVA かどうか ネットプロトコル
1 - JDBC-OCBC ブリッジ いいえ 直接
2 - 基本的にネイティブ API いいえ 直接
3 - JDBC ネット はい コネクタが必要
4 - 基本的にネイティブプロトコル はい 直接
1.2.3 JDBC ドライバの入手
これを書いている時点では、Java ソフトウェアのブリッジとともに使用できるカテゴリ 1 のドライバが数多くあります。DBMS 用のネイティブ API の上に構築されているカテゴリ 2 のドライバは約 12 あります。カテゴリ 3 のドライバは少数です。現在、カテゴリ 4 のドライバは最低 2 つありますが、1997 年末には、主要な DBMS のすべてについてカテゴリ 4 のドライバが登場する予定です。
ドライバについての情報を取得するには、http://java.sun.com/products/jdbc の JDBC の Web ページを参照してください。カテゴリ 3 のドライバが用意できる最初のベンダーは、SCO、Open Horizon、Visigenic、および WebLogic です。Java ソフトウェアおよび主要なデータベース接続ベンダーである Intersolv は、協力して JDBC-ODBC ブリッジと JDBC ドライバテストスイートの開発にあたっています。
1.2.4 そのほかの製品
さまざまな JDBC アプリケーションの開発が進行中です。最新情報については、Java ソフトウェアのページを参照してください。
