SQLマッピング

SQLマッピング機能は複雑なマッピング要件に使用でき、複数のワイルドカード「*から*へ」マッピング・ルールをデータベースの単一パスに置き換えるために使用することもできます。

この例では、マッピングに約3分かかりますが、単一のSQLマッピング・ルールを使用すると約30秒しかかかりません。単一のSQLマッピング・ルールを使用してすべての類似ルールを置き換えることができ、次のようになります:

生成されて実行される実際のSQLは次のとおりです:

この場合、SQLマッピングはACCOUNTディメンションで定義され、他の「*から*へ」マッピング・ルールは削除されました。この1つのSQLマッピング・ルールの合計時間は29秒で、他のマッピング・ルールは必要ありませんでした。

ACCOUNTおよびENTITYディメンションはそれらの名前で参照できますが、他のディメンションはUDディメンションにマップされます。SQLマッピングに必要なディメンションのセットを見つけるには、アプリケーション定義またはログ・ファイルを調べて、使用するディメンションを確認する必要があります。この例では、ProductとScenarioがUD1とUD3にマップされます。ソース・ディメンション・メンバーはXのない列を使用し、マップされた値は接尾辞としてXが付いた列にあります。ACCOUNTディメンションの場合、ソース・ファイルからの値はACCOUNTという名前の列にあり、マップされた値はACCOUNTX列に格納されます。SQLマッピングは各ディメンションのX列を設定するために使用されます。

これらの同じタイプのマッピングをAccount Reconciliationで使用できますが、ProfileディメンションはACCOUNTとして分類されるため、ProfileディメンションのSQLマッピングはACCOUNTディメンションで指定する必要があることに注意してください。Account Reconciliationの他のディメンションは、アプリケーション定義で定義されたマッピングに基づいて参照する必要があります。

マッピングのタイプごとにリソースの使用方法が異なり、マッピングのパフォーマンスは次の順序となります。Explicitが最も速く、Multi-Dimが最も遅くなります:

1. EXPLICIT
2. IN
3. BETWEENおよびLIKE
4. MULTI-DIM

Multi-dimマッピングは最も遅いマッピングであり、EXPLICITとLIKEマッピングの組合せを使用する必要がある複雑な使用事例ではmulti-dimのルールを制限しようとします。たとえば、ENTITY = 100 AND ACCOUNT LIKE 4*などです。

追加のチューニング戦略として、ソース・ディメンションを組み合せることで、multi-dimマッピングをexplicitマッピングに置き換えることができる場合があります。たとえば、ENTITY=100 AND ACCOUNT=4100の場合、ENTITYとACCOUNTをソースとして連結し、100-4000のEXPLICITマッピングを定義できます。