WebSphere Application Server Network Deployment for i5/OS, Version 6.1   
             オペレーティング・システム: i5/OS

             目次と検索結果のパーソナライズ化

JDBC メディエーター生成済み照会

構造化照会言語 (SQL) SELECT ステートメントが提供されていない場合 は、データ・メディエーター・サービス (DMS) がインスタンス作成で提供されたメタデータを使用してそれを生成します。

内部照会エンジンは、メタデータ内のテーブル、列、関連、フィルター、および ORDER BY についての情報を使用して照会を構成します。 提供された照会のように、UPDATE、DELETE、および INSERT ステートメン トは、それぞれの DataObject ごとに自動的に生成され、メディエーターが DataGraph に作成された変更をデータベースに戻してコミットするときに、適用されます。

フィルター。

フィルターは、パラメーター・マーカ ーを含む可能性のある SQL WHERE 文節を定義します。 これらは DataGraph SELECT ステートメント WHERE 文節に追加されます。 フィルターは現状の ままで使用されます。どのような方法でも解析も解釈もされず、従ってエラー検査はありません。 正しくない名前、述部、または関数を使用した場合、それは検出されず、 生成された照会は無効です。 フィルター WHERE 文節がパラメーター・マーカーを含んでいる場合、対応するパラメーター名およびタイプはフィルター引数を使用して定義されます。 パラメーター DataObject は、グラフが検索される前にこれらのパラメーターを入力します。 生成された照会のためのフィルターおよびパラメーター DataObject の例が続きます。

Limitation: DataGraph のツリー状の性質のため、ブランチに あるいずれのテーブルも、すべてのパス内に表示されるルート・テーブルで 、最終共用体内の複数の副照会として表示されます。 つまり、他のすべてのパスから独立している複数のパスとして表示される テーブル上で、フィルタリングをすることは不可能であることを意味します。 特定のテーブルで定義されているすべてのフィルターは、ブール値 AND で 結合され、そのテーブルが表示されるところではどこでも使用されます。

生成された照会のためのパラメーター DataObjects

クライアン トは、パラメーター DataObject を使用して、DMS メタデータ内で提供され るフィルターに適用される引数を提供します。 パラメーター DataObject は DataObject ですが、DataGraph の一部ではありません。 クライ アントが要求したときに、JDBC DMS によって構成されます。 生成された照会のパラメーター DataObject は、メディエーターのメタデータを基にして作成されます。 すべてのテーブルのすべてのフィルターのすべての引数は、パラメーター DataObject 内に入れられます。 提供された照会パラメーター DataObject と異なり、このパラメーターに はフィルター引数によってそれらに割り当てられている名前があります。 パラメーター DataObject はこの名前を使用して、入力されるべきパラメーターへマップします。 以下のサンプル・コードは、メディエーター・メタデータ内のテーブル にどのようにフィルターが作成されるのかを表しています。 また、パラメーター DataObject を使用して、メディエーター・インスタンスにフィルター・パラメーター値を受け渡すことを示しています。 このサンプルでは、カスタマー・テーブルは既に定義されていることが前提です。
// The factory is a MetadataFactory object
Filter filter = factory.createFilter();
filter.setPredicate("CUSTSTATE = ? AND CUSTZIP = ?");

FilterArgument arg0 = factory.createFilterArgument();
arg0.setName("customerState");
arg0.setType(Column.String);
queryInfo.getFilterArguments().add(arg0);

FilterArgument arg1 = factory.createFilterArgument();
arg1.setName("customerZipCode");
arg1.setType(Column.Integer);
queryInfo.getFilterArguments().add(arg1);

// custTable is the Customer Table object
custTable.setFilter(filter);

..... // setting up mediator 


DataObject parameters = mediator.getParameterDataObject();

// Notice the first parameter is the name given to the
// argument by the FilterArgument.
parameter.setString("customerState", "NY");
parameter.setInt("customerZipCode", 12345);
DataObject graph = mediator.getGraph(parameters);

Order-by

照会結果の配列は、テーブルから 結果をソートするために列を識別する OrderBy オブジェクトを使用して指定されます。 この配列は、昇順または降順のいずれかが可能です。 OrderBy オブジェクトは、メタデータの一部で、生成された照会に自動的に適用されます。 ファーストネームによってソートされるカスタマー・テーブル結果用のこの例は、以下のようです。
// This example assumes that the custTable, a table in
// the metadata, and factory, the MetaDataFactory
// object, have already been created.
Column firstName = ((TableImpl)custTable).getColumn("CUSTFIRSTNAME");
OrderBy orderBy = factory.createOrderBy();
orderBy.setColumn(firstName);
orderBy.setAscending(true);
metadata.getOrderBys().add(orderBy);
Limitation: たとえ Order-by がメタデータ内のそれぞれのテーブル上で定義されてい るとしても、RDBMS モデルはそれらが最終照会に適用されるように要求します。 これには多くの含意があります。 例えば、テーブルを配列してそれを他のテーブルとの結合で使用し、最初 のテーブルの配列を広げるということはできません。 結果セットは DataGraph 内のすべてのテーブルの共用体であ るため、単一結果セットの性質は、特に非ルート・テーブルで order-by に影響 を与える可能性のあるヌルで埋め込まれるように要求します。 これは予期しない結果を与える可能性があります。

外部テーブル

外部テーブルは、JDBC DMS によって 戻された DataGraph 内で必要ではないメタデータ内で定義されたテーブルです。 これは、テーブルからのデータを基にした結果セットをフィルターに掛け るが、そのテーブルのデータは結果セットには必要でないときに適しています。 Customer と Order の関係でのこの例としては、結果をフィルターに掛けて、そ の年の最初のオーダー日付で品目をオーダーしたすべてのカスタマーを戻す 、などがあります。 この場合、配列情報は戻されませんが、配列情報上でフィル タリングする必要があります。 Order テーブルを外付けにするということは、DataGraph からの配列情報 を除外し、その結果 DataGraph のサイズを削減し、効率を上げます。 テーブルを外付けとして指定するには、JDBC DMS メタデータ内のテーブル・オブジェクトから setExternal(true) メソッドを呼び出します。 クライアントが、DataGraph から外部テーブルにアクセスを試みると、無効な引数例外が発生します。

Limitation: 多くの RDBMS が、orderby 列が最終結果セット に表示されることを要求しています。外部テーブルからの列は、一般には、結果セットを配列するために使用できません。 Order-by は実際には、結果セット (「セット」という単語がここでのキー です) に適用され、中間照会結果には適用されません。

生成された照会の一般制限

JDBC DMS における照会生成機 能の制限を理解するために、心に留めておく必要のあることが 2 つあります。 第 1 に、DataGraph は、ダイレクトされておらず潜在的に切断されていな いグラフ (サイクル付き) である関連モデル上で、ダイレクトされて接続され たグラフ (サイクルなし) であるモデル (つまり、ツリーであるモ デル) を設定します。 ダイレクトされる とは、開発者がルート・テーブルをピッキング することによってグラフの方向を選択するということです。 接続される とは、DataGraph のメンバーであるすべてのテーブル が、ルートから到達可能であるということです。 ルートから到達可能でないテーブルはどれも、DataGraph 内に含めることができません。 テーブルがルートから到達可能になるようにするには、DataGraph 内のそ れぞれのテーブルのペアの間に、少なくとも 1 つの定義された外部キー関係がなければなりません。 サイクルなし とは、DataGraph 内のテーブルのペアの 間に、外部キー関係が 1 つのみあるということです。 DataGraph のツリーの性質は、照会の構築の方法、および照会から戻され るデータを判別します。

心に留めておくべき 2 つめの項目は、照会生成による DataGraph のための読み取り照会の作成方法についての以下の概要です。
  1. JDBC DMS は、DataGraph が単一テーブルから構成されていても、複数 のテーブルから構成されていても、単一の結果セット (つまり、1 つの DataGraph) を作成します。
  2. DMS Metadata 内で、外部キー関係を介したルートからリーフへの各パスは、 別個のパスを表しています。 このパスのためのデータは、パス内のテーブルの間で定義された外部キーでの結合を使用して検索されます。 結合はデフォルトで内部結合です。
  3. DataGraph 内のすべてのパスは、メディエーターが生成した照会によ って単一の結果セットを作成するように相互に結合され、お互いに独立に取り扱われます。
  4. ユーザー定義のフィルタリングはどれでも、最初にテーブル上で行われます。 その後、結果はパスの残りの部分と結合されます。
  5. リレーショナル・データベースは通常、order-by が、中間結果ではなく最終結果セット全体に適用されることを要求します。



サブトピック
JDBC メディエーター・パフォーマンスの考慮および制限
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 8:28:52 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.iseries.doc/info/iseriesnd/ae/rdat_sdogquery.html