アプリケーション開発の手引き
組み込み SQL インターフェースを使用するアプリケーションには、
SQL ステートメントをコードに変換するプリコンパイラーが必要で、変換後そのコードはコンパイルされ、データベースにバインドされ、実行されます。対照的に、DB2 CLI アプリケーションは、プリコンパイルまたはバインドする必要がなく、代わりに関数の標準セットを使用して実行時に SQL ステートメントおよび関連サービスを実行します。
この違いは重要です。というのはこれまでプリコンパイラーは、個々のデータベース製品に特定のものであったからです。これは効果的にユーザーのアプリケーションをその製品に結び付けるものでした。
DB2 CLI を使用すると、どの特定のデータベース製品からも独立した可搬性のあるアプリケーションを作成することが可能になります。この独立性によって、
DB2 CLI アプリケーションはさまざまな DB2 データベース (DRDA データベースを含む) にアクセスするために再コンパイルまたは再バインドする必要がなく、ただ該当するデータベースに実行時に接続するだけで済むようになります。
DB2 CLI と組み込み SQL は、次のような点でも異なります。
- DB2 CLI では、カーソルの明示宣言は必要ありません。必要に応じて DB2 CLI で生成されます。そして、アプリケーションはその生成されたカーソルを通常のカーソル取り出しモデルとして、複数行の SELECT ステートメント、および定位置 UPDATE と DELETE ステートメント用に使用します。
- OPEN ステートメントは DB2 CLI では使用しません。その代わりに、SELECT の実行によって自動的にカーソルがオープンされます。
- 組み込み SQL とは違って、DB2 CLI では、
EXECUTE IMMEDIATE ステートメントに相当するステートメント
(SQLExecDirect() 関数) でパラメーター・マーカーの使用が可能です。
- DB2 CLI の COMMIT または ROLLBACK は、
SQL ステートメントとして渡されるのではなく、
SQLEndTran() 関数呼び出しによって発行されます。
- DB2 CLI はステートメント関連情報をアプリケーションのために管理し、
ステートメント・ハンドル を提供してそれを要約オブジェクトとして参照できるようにします。このハンドルによって、アプリケーションが製品特有のデータ構造を使用する必要がなくなります。
- ステートメント・ハンドルと同様に、
環境ハンドル および接続ハンドル は、すべてのグローバル変数および接続特有の情報を参照する方法を提供します。
記述子ハンドル は、SQL ステートメントのパラメーターか、結果セットの列のどちらかの状況を記述します。
- DB2 CLI は、X/Open SQL CAE 仕様で定義された SQLSTATE 値を使用します。この形式および値のほとんどは、IBM リレーショナル・データベース製品で使用する値と一貫性がありますが、違いもあります。
(ODBC SQLSTATES と X/Open 定義の SQLSTATES の間にも違いがあります。)
- DB2 CLI はスクロール可能カーソルをサポートします。スクロール可能なカーソルを使用すると、静的カーソルによって次のようなスクロールが可能になります。
- 1 行または複数行ごとに下方へ
- 1 行または複数行ごとに上方へ
- 最初の行から 1 行または複数行ごとに
- 最後の行から 1 行または複数行ごとに
上記の違いは別にして、組み込み SQL と DB2 CLI には次の重要な共通の概念があります。
DB2 CLI は組み込み SQL で動的に作成できる SQL ステートメントを実行することができます。
注: | さらに、DB2 CLI は複合 SQL ステートメントのような、動的に準備できない一部の SQL ステートメントも受け入れることができます。
|
表 37 に各 SQL ステートメントをリストし、
DB2 CLI を使用して実行できるかどうかを示してあります。また、表には、コマンド行プロセッサーを使用してステートメントを対話式で実行できるかどうかも示してあります
(これは SQL ステートメントをプロトタイピングするのに便利です)。
各 DBMS には動的に作成できるステートメントがさらにある場合もありますが、この場合には DB2 CLI がステートメントを DBMS に渡します。
1 つの例外があります。一部の DBMS では COMMIT および ROLLBACK ステートメントを動的に準備できますが渡されることはありません。その代わりに SQLEndTran() 関数を使用して、
COMMIT または ROLLBACK ステートメントのいずれかを指定する必要があります。
DB2 CLI インターフェースには、組み込み SQL よりも優れている点がいくつかあります。
- これはクライアント・サーバー環境に理想的です。この環境では、アプリケーションの作成時には宛先データベースは不明です。アプリケーションにどのデータベース・サーバーが接続するかに関係なく、
SQL ステートメント実行用の一貫性のあるインターフェースが得られます。
- プリコンパイラーへの従属性が排除されているので、アプリケーションの移植性が高まります。
- 個々の DB2 CLI アプリケーションを各データベースにバインドする必要はなく、すべての DB2 CLI アプリケーションについて、
DB2 CLI に付いているバインド・ファイルを 1 度バインドする必要があるだけです。いったんこれを汎用にすると、アプリケーションに必要な管理の量を著しく減らすことができます。
- DB2 CLI アプリケーションを複数のデータベースに接続することができます。同一アプリケーションから同一データベースに複数接続することもできます。各接続には、各自のコミット範囲があります。アプリケーションでマルチスレッド化の使用により同一結果になる組み込み SQL を使用するよりは CLI を使用する方がずっと簡単です。
- DB2 CLI では、アプリケーション制御の、複雑になることの多いデータ域の必要がなくなります
(たとえば SQLDA や SQLCA など、一般的に組み込み SQL アプリケーションに関連しているものです)。その代わりに、DB2 CLI が必要なデータ構造を割り振って制御し、アプリケーションが参照できるようハンドル を与えます。
- DB2 CLI では、複数スレッドのスレッド保護アプリケーションの開発が可能になります。この場合、各スレッドは、独自の接続および他のスレッドとは別のコミット効力範囲を持つことができます。
DB2 CLI は、上記のデータ域を除去し、特定のハンドルでアプリケーションにアクセス可能なデータ構造のすべてを関連付けることにより、このことを成し遂げます。組み込み SQL とは違って、複数スレッドの CLI アプリケーションではコンテキスト管理の DB2 API のいずれかを呼び出す必要はありません。これは、DB2 CLI ドライバーで自動的に操作されます。
- DB2 CLI では、拡張パラメーターの入力と取り出しの機能が備えられており、データの配列が入力時に指定され、結果セットの複数行を直接配列に取り出し、複数の結果セットを生成するステートメントを実行します。
- DB2 CLI では、スキーマ (表、列、外部キー、
1 次キーなど) 情報を照会するための一貫性のあるインターフェースが与えられます。この情報はさまざまな DBMS カタログ表に入っています。返される結果セットは DBMS 間で一貫性があります。したがって、アプリケーションは、データベース・サーバーのリリース間のカタログ変更や、さまざまなデータベース・サーバー間のカタログの違いの影響を受けません。その結果、アプリケーションでは、バージョン固有およびサーバー固有のカタログ照会は書き込まれません。
- 拡張データ変換も DB2 CLI に備えられており、さまざまな SQL と C データ・タイプ間での情報の変換時にアプリケーション・コードが少なくて済みます。
- DB2 CLI には、ODBC と X/Open CLI の両方の関数が組み込まれており、両方とも業界仕様として受け入れられています。
DB2 CLI は、最新の ISO CLI 標準にも合わせています。アプリケーション開発者がこれらの仕様で得た知識は、
DB2 CLI の開発に直接応用することができ、その逆も可能です。このインターフェースは、関数ライブラリーについての知識はあるが、ホスト言語に SQL ステートメントを組み込む製品特定の方法についてはあまり知らないプログラマーにとって、直観的に理解できるものです。
- DB2 CLI には、
DB2 ユニバーサル・データベース (つまり DB2 (MVS/ESA 版) バージョン 5 またはそれ以降) のサーバーにあるストアード・プロシージャーから生成される複数行と結果セットを取り出す機能が備えられています。しかし、この機能は DataJoiner のバージョン 2 サーバーによりアクセス可能なサーバーにストアード・プロシージャーがある場合に、組み込み SQL を使用しているバージョン 5 の DB2 ユニバーサル・データベースのクライアントのために用意されているものです。
- DB2 CLI は、サーバー側でスクロール可能なカーソルをサポートし、配列出力と共に使用することが可能です。これは、「Page Up」、「Page Down」、「Home」、および「End」キーを使用するスクロール・ボックスで、データベース情報を表示する GUI アプリケーションに役立ちます。読み取り専用カーソルをスクロール可能と宣言した後、結果セットを通して 1 行または複数行単位で下方または上方に移動することができます。下記において、オフセットを指定することにより、複数の行を取り出すことも可能です。
- 現在行
- 結果セットの開始または終了位置
- 以前にブックマークで設定した特定の行
- DB2 CLI アプリケーションは、
CLI および組み込み SQL アプリケーションが結果セットを記述するのと同じように、
SQL ステートメントにパラメーターを動的に記述できます。これによって、あらかじめパラメーター・マーカーのデータ・タイプを知らなくても、パラメーター・マーカーを含む SQL ステートメントを動的に処理することが可能になります。
SQL ステートメントが準備されると、記述子情報がパラメーターのデータ・タイプの詳細と共に返されます。
どのインターフェースを選択するかは、使用するアプリケーションによって決まります。
DB2 CLI は、移植性が要求される、照会ベースのグラフィカル・ユーザー・インターフェース (GUI) アプリケーションに理想的です。前述の利点のため、
DB2 CLI の方が明らかにどんなアプリケーションにもふさわしいように見えるかもしれません。しかし、考慮しなければならない要素が 1 つあります。静的 SQL と動的 SQL の比較です。組み込みアプリケーションでは静的 SQL を使用する方がはるかに簡単です。
CLI アプリケーションでの静的 SQL の使用法については、
http://www.ibm.com/software/data/db2/udb/staticcli
にある Web ページをご覧ください。
静的 SQL には、次のようないくつかの利点があります。
- パフォーマンス
動的 SQL は実行時に準備され、静的 SQL はプリコンパイル時に準備されます。より多くの処理が必要になると同時に、準備ステップのために実行時に追加のネットワーク通信量が生じることがあります。しかし、この準備ステップ (およびネットワーク通信量) は、
DB2 CLI のアプリケーションが据え置き準備の場合には、必須ではありません。
静的 SQL が動的 SQL より常に良いパフォーマンスが得られるわけではない、というのも重要なことです。動的 SQL では、新規の索引などのデータベースに対する変更事項を利用でき、現行のデータベース統計を使って最適のアクセス・プランを選択することができます。さらに、ステートメントの事前コンパイルは、キャッシュされる場合に避けることができます。
- カプセル化およびセキュリティー
静的 SQL では、オブジェクト (表や視点など) に対する権限はパッケージに関連付けられ、パッケージのバインド時に妥当性検査されます。このため、データベース管理者は、特定のパッケージに関する実行権を 1 つのユーザーの集まりに付与する (つまり、特権をパッケージにカプセル化する) だけで済み、各データベース・オブジェクトへの明示アクセス権を付与する必要はありません。動的 SQL では、権限は実行時にステートメント単位で妥当性検査されます。したがって、ユーザーは各データベース・オブジェクトへの明示アクセス権を付与してもらわなければなりません。これによってこれらのユーザーは、アクセスする必要のないオブジェクトの部分にアクセスすることが許可されます。
- 組み込み SQL は、C または C++ 以外の言語でサポートされます。
- 固定照会の選択の場合、組み込み SQL はより簡単です。
アプリケーションで両方のインターフェースの利点が必要な場合は、静的 SQL を含むストアード・プロシージャーを作成して、
DB2 CLI アプリケーションで静的 SQL を利用できます。ストアード・プロシージャーは、DB2 CLI アプリケーション内から呼び出され、サーバーで実行されます。ストアード・プロシージャーを作成すると、どの DB2 CLI または ODBC アプリケーションでもこれを呼び出すことができます。詳細については、コール・レベル・インターフェースの手引きおよび解説書 を参照してください。
CLI アプリケーションでの静的 SQL の使用法については、
http://www.ibm.com/software/data/db2/udb/staticcli
にある Web ページをご覧ください。
DB2 CLI と組み込み SQL の両方を使う混合アプリケーションを作成して、それぞれの利点を活用することもできます。この場合、DB2 CLI を使用して基本のアプリケーションを作成し、パフォーマンスまたは機密保護上の理由のために静的 SQL を使用してキー・モジュールを作成します。このためアプリケーション設計が複雑になるので、ストアード・プロシージャーがアプリケーション要件に合わない場合に限りこの方法を使用してください。詳細については、
コール・レベル・インターフェースの手引きおよび解説書 の『組み込み SQL と DB2 CLI の混合』を参照してください。
結局、それぞれのインターフェースをいつ使用するかの判断は、
1 つの要因によるというのではなく、個々の必要性と以前の経験によって決まります。
[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]