この節では、DB2 連合システムに関連した各要素の概要と、 このシステムの管理者およびユーザーが実行するタスクの概要とを示します。 また、それらのタスクに関連した概念についても説明します。
DB2 連合システム は、 以下のもので構成される分散コンピューティング・システムです。
DB2 インストール・システムでは、 DB2 インスタンスをいくつでも連合サーバーとして構成することができます。
各データ・ソースは、 関係データベース管理システムのインスタンス 1 つと、 そのインスタンスがサポートするデータベース (複数可) とで構成されます。 DB2 連合システム内のデータ・ソースには、 Oracle インスタンスや DB2 ファミリー・メンバーのインスタンスを含めることができます。
データ・ソースは半自立的です。 たとえば、Oracle アプリケーションが Oracle データ・ソースにアクセスしている最中でも、 連合サーバーはそれらの Oracle データ・ソースに照会を送信できます。 DB2 連合システムは、(保全性やロックの制約を無視してまでも) Oracle などのデータ・ソースへのアクセスを独占したり制限することはありません。
エンド・ユーザーやクライアント・アプリケーションの側から見ると、 データ・ソースは単一の集合的なデータベースです。 実際、ユーザーやアプリケーションとのインターフェースには、 連合データベース と呼ばれるデータベースが使用されます。 このデータベースは連合サーバーの中に置かれます。 データ・ソースからデータを取得するには、 連合データベースに対して DB2 SQL 形式の照会を出します。 それから DB2 は、出された照会を適切なデータ・ソースに配布します。 DB2 は照会を最適化するためのアクセス・プランも提供します。 (これらのプランは、データ・ソースではなく、 連合サーバーで照会を処理するよう求める場合もあります。) 最後に、DB2 は要求データを収集し、それをユーザーやアプリケーションに渡します。
連合サーバーからデータ・ソースに出される照会は、読み取り専用でなければなりません。 データ・ソースに書き込みを行う必要がある場合 (たとえば、データ・ソース表を更新する場合)、 ユーザーやアプリケーションはそのデータ・ソース専用の SQL を、 パススルー と呼ばれる特殊モードで使用しなければなりません。
この節では、 連合システムを確立および使用する際にユーザーが実行するタスクに関連した概念を紹介します。 (この節と以降の節では、ユーザーという用語は、 連合システムに関連した作業を行うすべての人を指します。 たとえば、データベース管理者、アプリケーション・プログラマー、 エンド・ユーザーはすべてユーザーです。)
これから紹介する一連のタスクでは、 それらのタスクを一般に実行するのはどのタイプのユーザーであるかが明らかにされています。 とはいえ、他のタイプに属するユーザーもそれらのタスクを実行できることに注意してください。 たとえば、連合データベースへのアクセス許可とデータ・ソースへのアクセス許可との間のマッピングを行うのは、 一般的に DBA であることが示されています。 しかし、アプリケーション・プログラマーやエンド・ユーザーが、 このタスクを実行できないわけではありません。
DB2 連合システムを確立し、使用する方法:
照会を処理するときに、連合サーバーは DB2 SQL ではサポートされているものの、 データ・ソースの SQL ではサポートされていない操作を実行することができます。 (この能力のことを補償 といいます。 詳細については、補償を参照してください。)
以降の節では、ここまで紹介してきたタスクの概念について、紹介したのと同じ順序で説明します。 節によっては、関連する他の概念についても説明します。
ラッパーとは、データ・ソースと通信したり、 データ・ソースのデータを検索するために、連合サーバーが使用する機構のことです。 ラッパーを実装するために、 サーバーはラッパー・モジュール と呼ばれる、 ライブラリーに含まれているルーチンを使用します。 これらのルーチンを使用することにより、 サーバーはデータ・ソースへの接続やデータ・ソースのデータの検索といった繰り返しの操作を実行します。
次の 3 つのラッパーがあります。
ラッパーは、CREATE WRAPPER ステートメントを使用して連合サーバーに登録します。 詳細については、CREATE WRAPPERを参照してください。
DBA がラッパーを登録し、連合サーバーがデータ・ソースと対話できるようになると、 DBA は次にそれらのデータ・ソースを連合データベースに定義します。 この節の内容は以下のとおりです。
連合データベースにデータ・ソースを定義する際、 DBA はそのデータ・ソースの名前と情報を提供します。 この情報には、そのデータ・ソースがインスタンスとなっている RDBMS のタイプとバージョン、 およびそのデータ・ソース用の RDBMS の名前が含まれます。 その RDBMS に特有のメタデータも含まれます。 たとえば、DB2 ファミリー・データ・ソースには複数のデータベースを含めることができますが、 データ・ソースの定義には、 連合サーバーがそれらのデータベースのうちどれに接続できるのかを指定しなければなりません。 一方、Oracle データ・ソースは 1 つのデータベースにだけ関連付けられます。 連合サーバーはそのデータベースの名前が分からなくても接続することができます。 したがって、Oracle データ・ソースの連合サーバー定義に名前を含める必要はありません。
DBA が提供する名前と情報のことを一括してサーバー定義といいます。 この用語は、データ要求に応答するという役割ゆえにデータ・ソースが実質的にサーバーであるという事実を反映しています。 他の用語もこの事実を反映しています。 たとえば、次のとおりです。
サーバー・オプションに値を割り当てるには、 CREATE SERVER、ALTER SERVER、および SET SERVER OPTION ステートメントを使用します。
CREATE SERVER ステートメントと ALTER SERVER ステートメントは、 データ・ソースに正常に接続されている間は持続する値をサーバー・オプションに設定します。 これらの値はカタログに保管されます。 次のようなシナリオを考えてみましょう。 連合システムの DBA が、CREATE SERVER ステートメントを使用して、 新しい Oracle データ・ソースをその連合システムに定義しようとしています。 この新しいデータ・ソースのデータベースには、 連合データベースが使用しているのと同じ照合順序を使用させます。 パフォーマンスを向上させるため、DBA は最適化プログラムに、 この一致について認識させたいと考えています。 そのために DBA は、 CREATE SERVER ステートメントで COLLATING_SEQUENCE というサーバー・オプションを 'Y' (はい、 データ・ソースと連合データベースの照合順序は同じです) に設定します。 'Y' という設定がカタログに記録され、 ユーザーやアプリケーションが Oracle データ・ソースにアクセスしている間は有効です。
数か月後、Oracle の DBA は Oracle データ・ソースの照合順序を変更することにしました。 それに応じて、連合システムの DBA は COLLATING_SEQUENCE を 'N' (いいえ、 データ・ソースと連合データベースの照合順序は異なります) にリセットします。 DBA は ALTER SERVER ステートメントを使用してこの更新を行います。 カタログも更新されます。 新しい設定はユーザーやアプリケーションがデータ・ソースにアクセスし続けている限り有効です。
SET SERVER OPTION ステートメントは、連合データベースへの単一接続が行われている間、 サーバー・オプションの値を一時的にオーバーライドします。 オーバーライドしている値がカタログに保管されることはありません。
例を挙げて説明しましょう。PLAN_HINTS というサーバー・オプションを設定すれば、 DB2 は Oracle データ・ソースにプラン・ヒントと呼ばれるステートメントの断片を提供することができます。 このプラン・ヒントは、Oracle 最適化プログラムのジョブを援助します。 たとえば、表へのアクセスにどの索引を使用したらよいか、 また結果セットを生成するためにデータを検索するときにどの表結合順序を使用したらよいかを決定する上で、 このプラン・ヒントは最適化プログラムを援助します。
データ・ソース ORACLE1 と ORACLE2 について、 PLAN_HINTS サーバー・オプションがデフォルトの 'N' (いいえ、 これらのデータ・ソースにプラン・ヒントを提供しません) に設定されているものとします。 その後、プログラマーは ORACLE1 と ORACLE2 のデータに対する分散要求を作成することになりましたが、 そのときにプラン・ヒントに最適化プログラムを援助させることにより、 このデータにアクセスするための戦略を向上させたいと考えました。 そのため、このプログラマーは SET SERVER OPTION ステートメントを使用して、 'N' を 'Y' (はい、プラン・ヒントを提供します) でオーバーライドしました。 要求を含んでいるアプリケーションが連合データベースに接続している間だけ、 この 'Y' 設定は有効です。この設定はカタログには保管されません。
詳細については、CREATE SERVER、ALTER SERVER、 および SET SERVER OPTIONを参照してください。 すべてのサーバー・オプションとその設定値の説明については、 サーバー・オプションを参照してください。
サーバー定義 および サーバー・オプション という用語において、 また前節で説明した SQL ステートメントにおいては、 サーバー という用語はデータ・ソースだけを指します。 連合サーバーや DB2 アプリケーション・サーバーのことではありません。
とはいえ、DB2 アプリケーション・サーバーの概念と連合サーバーの概念とは重なり合う部分があります。 分散リレーショナル・データベースでも説明したとおり、アプリケーション・サーバーとは、 アプリケーション・プロセスが接続し、要求を出す、 データベース・マネージャー・インスタンスのことです。 このことは連合サーバーにもあてはまります。 したがって、連合サーバーはアプリケーション・サーバーの一種といえます。 しかし、次の 2 つの点で連合サーバーは他のアプリケーション・サーバーと大きく異なります。
以下のどちらかの条件が存在する場合、 連合サーバーは許可ユーザーまたは許可アプリケーションの分散要求をデータ・ソースに送信できます。
ユーザー・マッピングを定義するには、CREATE USER MAPPING ステートメントを使用します。 ユーザー・マッピングを変更するには、ALTER USER MAPPING ステートメントを使用します。 この 2 つのステートメントには、 ユーザー・オプション と呼ばれるパラメーターが含まれています。 ユーザー・オプションには、許可に関連した値が割り当てられます。 たとえば、あるユーザーが連合データベースとデータ・ソースについて、 ユーザー ID は同じものを持っているものの、パスワードは別々であるとします。 そのユーザーがデータ・ソースにアクセスするためには、 パスワードを相互にマッピングする必要があります。 これを行うには CREATE USER MAPPING ステートメントを使用して、 データ・ソースのパスワードを、REMOTE_PASSWORD というユーザー・オプションに値として割り当てます。
詳細については、CREATE USER MAPPING、ALTER USER MAPPING、 および 管理の手引き を参照してください。 ユーザー・オプションとその設定値の説明については、 ユーザー・オプションを参照してください。
連合サーバーがデータ・ソース表や視点の列からデータを検索するためには、 そのデータ・ソースの列のデータ・タイプを、連合データベースにあらかじめ定義されている対応するデータ・タイプにマッピングしなければなりません。 DB2 はデフォルトのマッピングを用意しており、 それらは多くのデータ・タイプをサポートしています。 たとえば、Oracle のタイプ FLOAT は、 デフォルトでは DB2 のタイプ DOUBLE によってマッピングされます。 また、DB2 ユニバーサル・データベース (OS/390 版) のタイプ DATE は、 デフォルトでは DB2 のタイプ DATE によってマッピングされます。 DB2 連合サーバーがマッピングをサポートしないデータ・タイプは、 LONG VARCHAR、LONG VARGRAPHIC、DATALINK、ラージ・オブジェクト (LOB) タイプ、 およびユーザー定義タイプです。
デフォルトのデータ・タイプ・マッピングのリストについては、 デフォルト・データ・タイプ・マッピングを参照してください。
データ・ソース列から値が戻されるとき、その列に対して実施されるマッピングによって、 それらの値は DB2 のタイプに完全に規格合致します。 このマッピングがデフォルトのものである場合、 それらの値はデータ・ソース・タイプにも、マッピングによって完全に規格合致します。 たとえば、FLOAT 列を含む Oracle 表を連合データベースに定義すると、 Oracle FLOAT から DB2 DOUBLE へのデフォルト・マッピングが自動的にその列に対して実施されます (オーバーライドされていない限り)。 結果として、列から戻される値は FLOAT にも DOUBLE にも完全に規格合致します。
戻される値の形式や長さを変更することは、 それらの値が規格合致していなければならないと定める DB2 タイプを変更すれば可能です。 たとえば、Oracle のタイプ DATE は、タイム・スタンプ用のタイプです。 このタイプは、デフォルトでは DB2 のタイプ TIMESTAMP にマッピングされます。 いくつかの Oracle 表列にデータ・タイプ DATE が含まれており、 ユーザーがそれらの列を照会することによって時刻部分だけを戻したいと考えているとしましょう。 そうするためには、デフォルトをオーバーライドして、 Oracle のタイプ DATE を DB2 のタイプ TIME にマッピングします。 このようにしてから列を照会すれば、タイム・スタンプの時刻部分が戻されます。
CREATE TYPE MAPPING ステートメントを使用すれば、1 つ以上のデータ・ソースだけに適用される、 独自のデータ・タイプ・マッピングを作成することができます。 ALTER NICKNAME ステートメントを使用すれば、特定の表の特定の列についてのみ、 データ・タイプ・マッピングを変更することができます。
詳細については、CREATE TYPE MAPPING、ALTER NICKNAME、 およびアプリケーション開発の手引き を参照してください。
連合サーバーがデータ・ソース関数を認識するためには、その関数と、 サーバーにすでに存在しているそれに対応する DB2 関数との間でのマッピングが必要となります。 DB2 は、既存の組み込みデータ・ソース関数と、 組み込み DB2 関数との間でデフォルト・マッピングを提供します。 連合サーバーが認識していないデータ・ソース関数 (たとえば、 新しい組み込み関数やユーザー定義関数) を使用したいと考えている場合、 ユーザーはその関数と、 連合データベースでそれに対応する関数との間で行われるマッピングを作成する必要があります。 対応する関数が存在しない場合には、 以下の要件を満たす関数をユーザーが作成しなければなりません。
対応する側の関数は、完全な関数でも関数テンプレートでも構いません。 関数テンプレート とは、 実行可能コードを含まない部分的な関数のことです。 関数テンプレートを単独で呼び出すことはできません。 関数テンプレートの目的はデータ・ソース関数とのマッピングに参加することだけなので、 連合サーバーからデータ・ソース関数を呼び出すことが可能になります。
関数マッピングを作成するには、CREATE FUNCTION MAPPING ステートメントを作成します。 このステートメントには、 関数マッピング・オプション と呼ばれるパラメーターが含まれています。 このパラメーターには、新しく作成するマッピングに適用する値、 またはマッピング内のデータ・ソース関数に適用する値をユーザーが割り当てます。 たとえば、データ・ソース関数を呼び出したときに生じるかもしれないオーバーヘッドについての見積統計を、 それらの値に含めることができます。 関数を呼び出すときの戦略を開発する際に、最適化プログラムはそれらの見積もりを参考にします。
関数テンプレートの作成について詳しくは、CREATE FUNCTION (ソースまたはテンプレート)を参照してください。 関数マッピングの作成について詳しくは、CREATE FUNCTION MAPPINGを参照してください。 関数マッピングとその設定値の説明については、関数マッピング・オプションを参照してください。 データ・ソース関数の呼び出しを最適化するためのガイドラインについては、 アプリケーション開発の手引き を参照してください。
クライアント・アプリケーションが連合サーバーに分散要求を出すと、 サーバーはその要求を適切なデータ・ソースに分配します。 要求がデータ・ソースを指定する必要はありません。 代わりに、要求はニックネームによってデータ・ソース表や視点を参照します。 ニックネームは、データ・ソースでの表名および視点名にマッピングされます。 このマッピングのおかげで、ニックネームをデータ・ソース名によって修飾する手間が省けます。 表および視点がある場所はクライアント・アプリケーションには分かりません。
別名とは異なり、ニックネームは表や視点の代替名ではありません。 ニックネームは、連合サーバーがそれに関連しているオブジェクトを参照するときのポインターです。 ニックネームを定義するには、CREATE NICKNAME ステートメントを使用します。 詳細については、CREATE NICKNAMEを参照してください。
表または視点にニックネームを作成すると、 最適化プログラムが表や視点へ簡単にアクセスできるようにするためのメタデータがカタログに提供されます。 たとえば、表または視点の列のデータ・タイプがマッピングされた後の DB2 データ・タイプの名前がカタログに提供されます。 索引付きの表にニックネームを作成した場合は、索引に関連した情報もカタログに提供されます。 たとえば、索引キーの各列の名前などです。
ニックネームを作成すると、ユーザーは最適化プログラムが使用するためのメタデータをカタログにさらに提供できるようになります。たとえば、 ニックネームが参照している表または視点の特定の列に含まれている値を記述するメタデータなどを提供できます。 ユーザーは、列オプション と呼ばれるパラメーターにこのメタデータを割り当てます。 例を挙げて説明しましょう。表列に数値ストリングだけが含まれている場合、 NUMERIC_STRING という列オプションに値 'Y' を割り当てると、ユーザーはそのことを示すことができます。 結果として、 最適化プログラムはそれらのストリングがデータ・ソースでソートされる戦略を確立できるようになるため、 それらのストリングを連合サーバーに移植してそこでソートするというオーバーヘッドを減らすことができます。 特に、値を含むデータベースの照合順序が連合データベースの照合順序とは異なる場合には、 オーバーヘッドを大きく減らすことができます。
列オプションを定義するには、ALTER NICKNAME ステートメントを使用します。 このステートメントの詳細については、ALTER NICKNAMEを参照してください。 列オプションとその設定値の説明については、列オプションを参照してください。
データ・ソース表のニックネームを作成すると、 連合サーバーはその表に含まれている索引についての情報をカタログに提供します。 最適化プログラムはこの情報を活用することにより、表データを容易に検索できるようにします。 表に索引がない場合でも、索引定義に一般に含まれている情報をユーザーが提供することは可能です。 たとえば、情報を短時間で検索できるようにするために、 表のどの列を検索すべきかを指定したりできます。 これを行うためには、情報を含み、 表のニックネームを参照している CREATE INDEX ステートメントを実行します。
連合サーバーが認識できない索引を含んでいる表についても、 ユーザーは最適化プログラムに上記と同じような情報を提供できます。 たとえば、現時点では索引がないものの、あとで取得する予定のある表に対して、 ニックネーム NICK1 を作成するとしましょう。 また、索引を含む表を参照している視点に対して、ニックネーム NICK2 を作成するとしましょう。 どちらの場合にも、連合サーバーは索引を認識できません。 しかし、ユーザーが CREATE INDEX ステートメントを使用すれば、 索引が存在していることをサーバーに通知することができます。 1 つのステートメントには NICK1 を参照させ、 NICK1 が参照している表の索引に関する情報を含めます。 もう 1 つのステートメントには NICK2 を参照させ、 NICK2 が指し示している視点の背後にある基礎表の索引に関する情報を含めます。
ここで説明したような状況の場合、CREATE INDEX ステートメントの情報は、 索引指定と呼ばれるメタデータのセットとしてカタログに提供されます。 ステートメントがニックネームを参照しているときは、索引指定だけが生成され、 実際の索引は生成されないことに注意してください。 詳細については、CREATE INDEXおよび管理の手引き: パフォーマンス を参照してください。
分散要求では副照会や結合副選択などの装置を使用できるため、 どの表または視点の列にアクセスするかを指定したり、 どのデータを検索するか指定することができます。
この節では、以下に示すシナリオの文脈に含まれている例を示します。 このシナリオにおいて、連合サーバーは DB2 ユニバーサル・データベース (OS/390 版) データ・ソース、DB2 ユニバーサル・データベース (AS/400 版) データ・ソース、 および Oracle データ・ソースにアクセスすることを念頭に置いて構成されています。 各データ・ソースには、従業員情報を含む表が格納されています。 連合サーバーは、それらの表をニックネームによって参照します。 ニックネームは、表がどこに存在しているかを指し示します。 それぞれのニックネームは UDB390_EMPLOYEES、AS400_EMPLOYEES、および ORA_EMPLOYEES です。 Oracle データ・ソースには、従業員情報を含む表だけでなく、 各従業員が在住している国に関する情報を含む表もあります。 この 2 番目の表のニックネームは ORA_COUNTRIES です。
表 AS400_EMPLOYEES の中には、アジア地区に在住している従業員の電話番号が含まれています。 この表の中には、それらの電話番号に関連した国別コードも含まれていますが、 そのコードが表す国がどこであるかは示されていません。 表 ORA_COUNTRIES には、コードとそれが表す国の両方が示されています。 以下に示す照会は、中国を表している国別コードを調べるための副照会を使用しています。 この照会は SELECT 文節と WHERE 文節を使用することによって、 AS400_EMPLOYEES に登録されている従業員のうち、 中国を表す国別コードが必要な電話番号を持っている従業員をリストします。
SELECT NAME, TELEPHONE FROM DJADMIN.AS400_EMPLOYEES WHERE COUNTRY_CODE IN (SELECT COUNTRY_CODE FROM DJADMIN.ORA_COUNTRIES WHERE COUNTRY_NAME = 'CHINA')
上記のような分散要求をコンパイルすると、 その分散要求はコンパイラーの書き直し機能によって、 より簡単に最適化できるような形式へと変換されます。
関係結合を行うと、結果セットには複数の表から取り出された列が含まれます。 結果セットの行サイズを制限するための条件を必ず指定してください。
下記の照会は、2 つの表に示されている国別コードを比較することによって、 従業員名とそれに対応する国名とを結合します。 各表は、別々のデータ・ソースに存在しています。
SELECT T1.NAME, T2.COUNTRY_NAME FROM DJADMIN.UDB390_EMPLOYEES T1, DJADMIN.ORA_COUNTRIES T2 WHERE T1.COUNTRY_CODE = T2.COUNTRY_CODE
補償とは、RDBMS が SQL ステートメントをサポートしていない場合の SQL ステートメントの処理のことです。 各タイプの RDBMS (DB2 ユニバーサル・データベース (AS/400 版) 、DB2 ユニバーサル・データベース (OS/390 版)、Oracle など) は、 SQL の国際規格のサブセットをサポートしています。 また、一部のタイプの RDBMS は、この規格外の SQL 構成もサポートしています。 RDBMS がサポートするタイプの SQL のことを一括して SQL ダイアレクト といいます。 SQL 構成が DB2 の SQL ダイアレクトには含まれているものの、 データ・ソースのダイアレクトには含まれていない場合は、 連合サーバーがデータ・ソースの代わりにこの構成を実装できます。
例 1: DB2 の SQL には共通表式が含まれています。 この文節には、全選択内のすべての FROM 文節が結果セットを参照できるようにするための名前を指定できます。 連合サーバーは、Oracle の SQL ダイアレクトに共通表式が含まれていない場合でも、 Oracle データベースの共通表式を処理します。
例 2: アプリケーション内に複数のオープン・カーソルがあることをサポートしないデータ・ソースに接続する場合、 連合サーバーはそのデータ・ソースへの同時接続を 1 つずつ確立することによって、 この関数をシミュレートできるようにします。 この関数を提供しないデータ・ソースについても、 連合サーバーは同様の方法で CURSOR WITH HOLD 機能をシミュレートできるようにします。
補償を適用すれば DB2 の SQL ダイアレクトだけを使用して、 連合サーバーがすべての照会をサポートするようにできます。 DB2 以外の RDBMS に固有のダイアレクトを使用する必要はありません。
パススルー関数を使用すれば、ユーザーは、 各データ・ソースに固有の SQL ダイアレクトの中のデータ・ソースとも通信できるようになります。 パススルーでは、照会だけでなく、DML ステートメントや DDL ステートメントを出すこともできます。 パススルー・セッション中に出されたステートメントの処理を、 DB2 やデータ・ソースがどのように管理するかについては、 パススルー・セッションにおける SQL 処理を参照してください。
連合サーバーは、パススルー・セッションを管理するために次の SQL ステートメントを提供します。
パススルーの使用には、いくつかの制限があります。 たとえば、パススルー・セッション内では、 データ・ソース・オブジェクトに対してカーソルを直接オープンすることはできません。 すべての制限が示されたリストについては、考慮事項と制約事項を参照してください。