JDBC メディエーター生成済み照会
Structured Query Language (SQL) SELECT ステートメントが提供されていない場合 は、データ・メディエーター・サービス (DMS) がインスタンス作成で提供されたメタデータを使用してそれを生成します。
内部照会エンジンは、メタデータ内のテーブル、列、関連、フィルター、および ORDER BY についての情報を使用して照会を構成します。提供された照会のように、UPDATE、DELETE、および INSERT ステートメン トは、それぞれの DataObject ごとに自動的に生成され、メディエーターが DataGraph に作成された変更をデータベースに戻してコミットするときに、適用されます。
フィルター
フィルターは、パラメーター・マーカ ーを含む可能性のある SQL WHERE 文節を定義します。 これらは DataGraph SELECT ステートメント WHERE 文節に追加されます。 フィルターは現状の ままで使用されます。どのような方法でも解析も解釈もされず、したがってエラー検査はありません。 正しくない名前、述部、または関数を使用した場合、それは検出されず、 生成された照会は無効です。 フィルター WHERE 文節がパラメーター・マーカーを含んでいる場合、対応するパラメーター名およびタイプはフィルター引数を使用して定義されます。 パラメーター DataObject は、グラフが検索される前にこれらのパラメーターを入力します。 生成された照会のためのフィルターおよびパラメーター DataObject の例が続きます。
生成された照会のためのパラメーター DataObjects
// 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
// 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);
外部テーブル
外部テーブルは、JDBC DMS によって 戻された DataGraph 内で必要ではないメタデータ内で定義されたテーブルです。 これは、テーブルからのデータを基にした結果セットをフィルターに掛け るが、そのテーブルのデータは結果セットには必要でないときに適しています。 Customer と Order の関係でのこの例としては、結果をフィルターに掛けて、そ の年の最初のオーダー日付で品目をオーダーしたすべてのカスタマーを戻す 、などがあります。 この場合、配列情報は戻されませんが、配列情報上でフィル タリングする必要があります。 Orders テーブルを外部テーブルにすると、DataGraph から配列情報が除外されるため、DataGraph のサイズが縮小され、効率が向上します。テーブルを外付けとして指定するには、JDBC DMS メタデータ内のテーブル・オブジェクトから setExternal(true) メソッドを呼び出します。クライアントが、DataGraph から外部テーブルにアクセスを試みると、無効な引数例外が発生します。
生成された照会の一般制限
JDBC DMS における照会生成機 能の制限を理解するために、心に留めておく必要のあることが 2 つあります。 第 1 に、DataGraph は、ダイレクトされておらず潜在的に切断されていな いグラフ (サイクル付き) である関連モデル上で、ダイレクトされて接続され たグラフ (サイクルなし) であるモデル (すなわち、ツリーであるモ デル) を設定します。 ダイレクトされる とは、開発者がルート・テーブルをピッキング することによってグラフの方向を選択するということです。 接続される とは、DataGraph のメンバーであるすべてのテーブル が、ルートから到達可能であるということです。 ルートから到達可能でないテーブルはどれも、DataGraph 内に含めることができません。 テーブルがルートから到達可能になるようにするには、DataGraph 内のそ れぞれのテーブルのペアの間に、少なくとも 1 つの定義された外部キー関係がなければなりません。 サイクルなし とは、DataGraph 内のテーブルのペアの 間に、外部キー関係が 1 つのみあるということです。 DataGraph のツリーの性質は、照会の構築の方法、および照会から戻され るデータを判別します。
- JDBC DMS は、DataGraph が単一テーブルから構成されていても、複数 のテーブルから構成されていても、単一の結果セット (すなわち、1 つの DataGraph) を作成します。
- DMS Metadata 内で、外部キー関係を介したルートからリーフへの各パスは、 別個のパスを表しています。 このパスのためのデータは、パス内のテーブルの間で定義された外部キーでの結合を使用して検索されます。 結合はデフォルトで内部結合です。
- DataGraph 内のすべてのパスは、メディエーターが生成した照会によ って単一の結果セットを作成するように相互に結合され、お互いに独立に取り扱われます。
- ユーザー定義のフィルタリングはどれでも、最初にテーブル上で行われます。 その後、結果はパスの残りの部分と結合されます。
- リレーショナル・データベースは通常、order-by が、中間結果ではなく最終結果セット全体に適用されることを要求します。