ID リゾルバーを使用すると、代替 Java プロパティー・ファイルを使用して、 1 次エントリーのどの列が、1 次行の ID を必要とするテーブルの索引として使用されるべきかを記述することができます。
デフォルトのプロパティー・ファイルは IdResolveKeys.properties ですが、 必要なら ID 解決コマンドの呼び出し時にこのファイルを変更したり、ご自分のファイルを指定することが可能です。
![]()
![]()
![]()
![]()
IdResolveKeys.properties は、ID リゾルバーが呼び出されるディレクトリーにあります。
IdResolveKeys.properties を変更するには、 これを /QIBM/ProdData/WebCommerce/properties ディレクトリーからコピーし、 その後で /instroot/xml ディレクトリーに保管して、 この新規ファイルに必要な変更を行います。
注: 上記のディレクトリーは RESWCSID コマンドによって使用されるクラスパスにあります。
プロパティー・ファイルを使用して ID を生成する
以下の例では、それぞれ ADDRBOOK および ADDRESS レコードの ID である ADDRBOOK_ID および ADDRESS_ID を解決する必要があります。 MEMBER レコードの ID は既知です。 各レコードは、WebSphere Commerce データベースの有効な ID を必要とします。 さらに、ADDRESS レコード内の ADDRBOOK_ID は、外部キー制約を満たすために 1 次テーブルの ID を必要とします。
<MEMBER MEMBER_ID="100" TYPE="U" STATE="1" /> <MEMBER MEMBER_ID="101" TYPE="U" STATE="1" /> <ADDRBOOK MEMBER_ID="100" DISPLAYNAME="Friends" DISPLAYNAME 列の実際の値 DESCRIPTION="All my friends" TYPE="P" /> <ADDRESS ADDRBOOK_ID="@Friends" 索引に DISPLAYNAME を使用して、ADDRBOOK を参照します MEMBER_ID="101" NICKNAME="Bob" ADDRESS1="15 Brave Developers St." CITY="Toronto" ZIPCODE="A0A0A0" COUNTRY="Canada" STATUS="P" />
外部キー列に対する ID の解決において、1 次行のどの列が関係行によって使用されるかを識別するのにプロパティー・ファイルが必要です。 以下の手順に従って、確実に上記のファイルの構文解析が正しく進められるようにします。
IdResolveKeys.properties で、以下を指定します。
NAMEDELIMITER=@ SELECTDELIMITER=: ADDRBOOK=@DISPLAYNAME:DISPLAYNAME ADDRESS=@NICKNAME:NICKNAME
NAMEDELIMITER および SELECTDELIMITER は、 プロパティー・ファイルの全体にわたって使用される区切り文字を設定します。これらは一貫して使用される必要があります。
ADDRBOOK=@DISPLAYNAME:DISPLAYNAME は、住所録レコードを受け取ると住所録行の ID が作成されることを示しています。 DISPLAYNAME フィールドは入力レコードから抽出され、 新規 ID へのアソシエーションを形成するのに使用されます。 DISPLAYNAME ストリングを使用して、 住所録行 DISPLAYNAME と突き合わせ、外部キーに必要とされる ID を解決します。
DISPLAYNAME が Friends である直前の入力例を使用して、 このレコードに対して作成される ID が 12951 であると想定します。 DISPLAYNAME は 12951 に対するキー・ルックアサイドとして使用されます。 処理は次のレコード ADDRESS に続きます。 ここで ADDRBOOK_ID は "@..." の形式です。(これは、 区切り文字に続くものが住所録 ID の検索に使用されることを示します。) ストリングが DISPLAYNAME と一致し、したがって ADDRBOOK_ID 属性に 12951 が戻され、置換されます。
<MEMBER MEMBER_ID="100" TYPE="U" STATE="1" /> <MEMBER MEMBER_ID="101" TYPE="U" STATE="1" /> <ADDRBOOK ADDRBOOK_ID="12951" 生成済み基本キー MEMBER_ID="100" DISPLAYNAME="Friends" 未変更の ADDRBOOK DISPLAYNAME の値 DESCRIPTION="All my friends" TYPE="P" /> <ADDRESS ADDRESS_ID="13051" 生成済み基本キー ADDRBOOK_ID="12951" ADDRESS は正しい ADDRBOOK を参照します MEMBER_ID="101" NICKNAME="Bob" ADDRESS1="15 Brave Developers St." CITY="Toronto" ZIPCODE="A0A0A0" COUNTRY="Canada" STATUS="P" />
複合キーでプロパティー・ファイルを使用する
2 つの列より多い列で構成されるキーは複合キーです。 プロパティー・ファイルの複合キー検索を、 フィールド名が後に続く NAMEDELIMITER および SELECTDELIMITER の両方を指定することによって、定義することができます。 たとえば、ADDRBOOK レコードの検索基準を表示名とメンバー ID の複合とするには、プロパティー・ファイルで以下を指定します。
ADDRBOOK=@DISPLAYNAME@MEMBER_ID:DISPLAYNAME MEMBER_ID
次に、以下の XML 入力ファイル・フラグメントを指定します。
<ADDRBOOK MEMBER_ID="100" DISPLAYNAME="Friends" MEMBER 100 の ADDRBOOK "Friends" DESCRIPTION="All my friends" TYPE="P" /> <ADDRBOOK MEMBER_ID="101" DISPLAYNAME="Friends" MEMBER 101 の ADDRBOOK "Friends" DESCRIPTION="All my friends" TYPE="P" /> <ADDRESS ADDRBOOK_ID="@Friends@100" MEMBER 100 の ADDRBOOK "Friends" に対する基本キーを検索します MEMBER_ID="101" NICKNAME="Bob" ADDRESS1="15 Brave Developers St." CITY="Toronto" ZIPCODE="A0A0A0" COUNTRY="Canada" STATUS="P" />
解決後は以下のようになります。
<MEMBER MEMBER_ID="100" TYPE="U" STATE="1" /> <MEMBER MEMBER_ID="101" TYPE="U" STATE="1" /> <ADDRBOOK ADDRBOOK_ID="12951" 興味のある ADDRBOOK MEMBER_ID="100" DISPLAYNAME="Friends" DESCRIPTION="All my friends" TYPE="P" /> <ADDRBOOK ADDRBOOK_ID="12952" MEMBER_ID="101" DISPLAYNAME="Friends" DESCRIPTION="All my friends" TYPE="P" /> <ADDRESS ADDRESS_ID="13051" ADDRBOOK_ID="12951" ADDRESS は正しい ADDRBOOK を参照します MEMBER_ID="101" NICKNAME="Bob" ADDRESS1="15 Brave Developers St." CITY="Toronto" ZIPCODE="A0A0A0" COUNTRY="Canada" STATUS="P" />
カスケード 1 次キーでプロパティー・ファイルを使用する
1 次テーブル STOREENT は 1 次キー STOREENT_ID を定義します。 STOREENT を参照する外部テーブル STORE は、1 次テーブル STOREENT に対する外部キーである 1 次キー STORE_ID を指定します。 つまり、STORE_ID の値は STOREENT_ID の値のいずれかでなければなりません。 したがって、STORE_ID (外部テーブル STORE の 1 次キー) には 1 次と外部という二重の役割があります。
ここで、別のテーブル CONTRACT が STORE の外部テーブルであり、 CONTRACT の外部キーである STORE_ID が、STORE の 1 次キーである STORE_ID を参照していると想定します。 したがって、STORE テーブルは CONTRACT テーブルに対する 1 次テーブルです。
STORE テーブルの STORE_ID は、作成されるのではなく STOREENT_ID から参照されるものであるため、 ID リゾルバーを使用しても STORE テーブルへの内部別名および ID 値アソシエーションは作成されません。 CONTRACT テーブルが STORE テーブルから STORE_ID を解決しようとすると、空の値が戻されます。
このような特殊な条件のため、 プロパティー・ファイルにエントリーを作成して、内部別名を作成するよう明示的に指定する必要があります。 IdResolveKeys.properties で、以下を指定します。
"STORE=@STORE_ID:STORE_ID"
これにより、ID リゾルバーが以下を行うよう強制されます。
プロパティー・ファイルの STORE=@STORE_ID:STORE_ID エントリー、 および以下の XML 入力ファイル・フラグメントを使用します。
<STOREENT IDENTIFIER="Out Fashions" MEMBER_ID="-2000" STOREENT_ID="@storeent_id_1" TYPE="G" /> <STORE STORE_ID="@storeent_id_1" STOREGRP_ID="1" STORELEVEL="store_level" /> <CONTRACT CONTRACT_ID="@contract_id_1" STATE="0" STORE_ID="@storeent_id_1" />
解決後は以下のようになります。
<STOREENT IDENTIFIER="Out Fashions" MEMBER_ID="-2000" STOREENT_ID="10501" TYPE="G" /> <STORE STORE_ID="10501" STOREGRP_ID="1" STORELEVEL="store_level" /> <CONTRACT CONTRACT_ID="@contract_id_1" STATE="0" STORE_ID="10501" />
![]() |