相互参照表の概要
相互参照は表形式で保存されます。表44-1に、様々なアプリケーションの顧客IDに関する情報を含む相互参照表を示します。
表44-1 相互参照表サンプル
| SAP | EBS | SBL |
|---|---|---|
|
|
|
|
|
|
|
|
あるアプリケーションで顧客情報が更新され、変更内容を他のアプリケーションに伝播させる必要がある場合にも、IDマッピングが必要になります。異なるIDを統合するには、相互参照表の全IDにマップする共通値統合パターンを使用する方法があります。たとえば、表44-1の相互参照表に、さらにCommonという1列を追加できます。相互参照表を更新すると、表44-2のように表示されます。
表44-2 Common列が追加された相互参照表
| SAP | EBS | SBL | Common |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
図44-1に、共通値統合パターンを使用して様々なアプリケーションのIDをマップする方法を示します。
相互参照表は、メタデータと実際のデータという2つの部分で構成されています。メタデータはOracle JDeveloperで作成された.xrefファイルとして保存され、XMLファイルとしてメタデータ・サービス(MDS)リポジトリに格納されています。実際のデータは、デフォルトでSOAインフラストラクチャ・データベース・スキーマにあるデータベースのXREF_DATA表に格納されます。相互参照エンティティごとにカスタム・データベース表を生成することもできます。データベース表は、相互参照エンティティのメタデータによって異なります。
次の2つの相互参照エンティティを考えてみます。
表44-3 ORDER表
| 列名 | SIEBEL | COMMON | EBS |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
表44-4 CUSTOMER表
| 列名 | EBS | COMMON | PORTAL |
|---|---|---|---|
|
|
|
|
|
1つの汎用表にすべてのランタイム・データを保存するように選択すると、表44-5に示すように、データはXREF_DATAコード表に保存されます。
表44-5 XREF_DATA表
| XREF_TABLE_NAME | XREF_COLUMN_NAME | ROW_NUMBER | VALUE | IS_DELETED |
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
このアプローチには、次のメリットがあります。
-
相互参照エンティティの列を追加、削除および変更するプロセスが単純です。
-
アプリケーションに対して相互参照エンティティを作成および削除するプロセスが明快です。
一方、このアプローチには次のデメリットがあります。
-
各相互参照セルはデータベースの異なる行にマップされるため、データベースに多数の行が生成されます。そのため、問合せのパフォーマンスが低下します。
-
汎用表では、
XREF_TABLE_NAME列およびXREF_COLUMN_NAME列のデータが多数の行で繰り返されます。
これらの問題を解決するために、相互参照エンティティごとにカスタム・データベース表を生成できます。カスタム・データベース表は、相互参照エンティティのメタデータによって異なります。たとえば、XREF_ORDER表およびXREF_CUSTOMER表には、表44-6および表44-7に示すようなカスタム・データベース表を生成できます。
表44-6 XREF_ORDER表
| ROW_ID | SIEBEL | COMMON | EBS |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
表44-7 XREF_CUSTOMER表
| ROW_ID | EBS | COMMON | PORTAL |
|---|---|---|---|
|
|
|
|
|
このアプローチでは、データ定義言語(DDL)スクリプトを実行してカスタム・データベース表を生成する必要があります。カスタム・データベース表の詳細は、「カスタム・データベース表の作成方法」を参照してください。