| Oracle Business Intelligence Applicationsインストレーションおよび構成ガイド リリース7.9.4 E06112-01 |
|
 戻る |
 次へ |
この章では、Oracle Business Analytics Warehouseのカスタマイズの概要と手法について説明します。
|
注意: カスタマイズを実装する前に、Informatica PowerCenterに習熟しておいてください。 |
この章の内容は次のとおりです。
Oracle Business Analytics Warehouseのカスタマイズには、データソースのタイプに応じていくつかのシナリオがあります。
パッケージ・アプリケーションは（Siebel CRMやOracle EBSなど）、事前にパッケージ済のアダプタを使用します。
パッケージされていないデータソースは汎用アダプタを使用します。
次の図は、サポートされているカスタマイズ・シナリオのカテゴリーを、データソースごとに示しています。
テーブルと命名規則の詳細は、『Oracle Business Analytics Warehouse Data Model Reference』を参照してください。
図6-1「データソースごとにサポートされているカスタマイズ」は、次のカスタマイズのカテゴリーを示しています。
カテゴリー1: カテゴリー1のカスタマイズでは、事前にパッケージされたアダプタが存在するソース・システムからカラムを追加し、既存のデータ・ウェアハウス・テーブルにデータをロードします。
カテゴリー2: カテゴリー2のカスタマイズでは、事前にパッケージされたアダプタを使用して、新しい要素テーブルまたは次元テーブルをデータ・ウェアハウスに追加します。カテゴリー2のカスタマイズでは通常、新しいSDEマッピングおよびSILマッピングを構築する必要があります。
カテゴリー3: カテゴリー3のカスタマイズでは、汎用アダプタを使用して、事前にパッケージされたアダプタが存在しないソースからデータをロードします。
アップグレード時にカスタマイズを処理することは、カスタマイズの作業の中でも難しい事項の1つです。Informaticaには、顧客が加えた変更を自動的に検出して、アップグレードされたマッピングに追加する差分マージ機能がありません。したがって、カスタマイズした内容は、アップグレードされたマッピングに手動で再適用する必要があります。Oracle BI Applicationsは、アップグレード後にカスタマイズ内容を再適用する作業ができるだけ少なくなるように処理します。このカスタマイズ方法論に従えば、アップグレード時の作業が最小で済み、多くの場合、手動作業が不要になります。
この項の内容は次のとおりです。
カテゴリー1のカスタマイズでは、事前にパッケージされたアダプタが含まれているソース・システム（SiebelやOracleなど）から追加のカラムを抽出し、既存のデータ・ウェアハウス・テーブルにデータをロードします。カテゴリー1のカスタマイズの場合、データはパッケージされていないソースからも入力されますが、この項では、このソースはすでに汎用アダプタでマッピングされ、追加のカラムを取り込むための拡張のみが必要であると想定しています（汎用アダプタの初期マッピングは、カテゴリー3のカスタマイズで検討します。詳細は、第6.5項「カテゴリー3のカスタマイズ: 標準的な次元テーブルに新しいデータを行全体として追加」を参照）。
データ・ウェアハウスで追加のカラムを参照するには、まずそのカラムがETLプロセスで渡されている必要があります。既存のマッピングとテーブルは拡張可能です。サンプルのプレースホルダは、追加データを渡して格納する方法を示しています。Oracle BI Applicationsでは、事前に構成済のマッピングを拡張し、これらのカラムを追加して、既存のテーブルにデータをロードする方法論が提供されています。
Oracle BI Applicationsには、拡張と変更という2種類のカスタマイズがあります。サポートされている拡張ロジックにより、既存オブジェクトに追加できます。たとえば、ソースから追加のカラムを抽出し、既存のマッピングを使用して追加のカラムを渡し、既存のテーブルに新しいカラムを追加ポピュレートできます。一般的に、Oracle BI Applicationsでは、既存のロジックまたはカラムを変更することはできません。別のカラムを使用するために既存の計算を変更することはできません。また、既存のカラムを別のソースからロードするように再マッピングすることもできません。
たとえば、既存のロジックと異なる方法で売上を計算する場合は、新しい変換を作成して、X_REVENUEなどの新しいカラムにその計算を接続する必要があります。その後、Oracle Business Intelligenceリポジトリを再マッピングして、新しいX_REVENUEカラムを指すようにできます。
ほとんどのマッピングには、マッピングによる安全な経路を示すX_CUSTOMという名前のプレースホルダ・カラムが1つあります。すべての拡張ロジックは、マッピングを使用してX_CUSTOMと同じ経路をたどる必要があります。マッピングに変換を追加することはできますが、マッピングを使用してX_CUSTOMと同じ経路をたどる必要があります。
次の図では、事前に構成済のロジックがグレーで表示されています。これらのオブジェクトの内容には、どのような変更もできません。既存のマッピングにカスタマイズ部分を追加する必要があり、これにより既存のロジックとパラレルで追加部分を実行できます。
一部のオブジェクトは拡張可能になるように変更する必要があるため、Oracle BI Applicationsでは拡張が次のカテゴリーに分けられています。
公開ソース: これらのオブジェクトは変更可能ですが、変更は拡張（オプション）の形態をとる必要があり、事前に構成済の既存ロジックは変更できません。これらのオブジェクトは出荷時点でマッピングに含まれており、通常は、ソース、ターゲット、再利用できない変換などになります。
カプセル化されたオブジェクト: これらのオブジェクトは拡張できません。事前に構成済のロジックが壊されないように、出荷時点で組み込まれた変換ロジックは可能なかぎり隠されています。これらのオブジェクトは出荷時点でマッピングに含まれており、通常は、マップレットや再利用可能な変換などです。
カスタム・オブジェクト: マッピングにはカスタム・オブジェクトを追加します（カスタム・オブジェクトは同梱されていません）。カスタム・オブジェクトとして作成できるのはソース、（再利用可能または再利用不能な）変換またはマップレットです。同梱されている再利用可能な変換とマップレットは、カプセル化されたオブジェクトとみなされますが、既存のマッピングにこれらのオブジェクトを追加すると、特定のマッピングに対するカスタム・オブジェクトとみなされます。たとえば、要素テーブルに別の金額を追加し、その金額を元の通貨からデータ・ウェアハウスの通貨に変換する必要がある場合、通常は既存のCurrency Exchangeマップレットをマッピングに追加して、この新しい金額を変換します。この場合、このマップレトはカスタム・オブジェクトとみなされます。ただし、このマップレットもカプセル化されているため、内部ロジックは変更できません。
|
注意: ターゲットはマッピングに追加できません。 |
アップグレード時には、カスタマイズしたマッピングを個別に配置します。既存の環境に適用されるのは、実際に変更されているマッピングのみです。つまり、変更されていないマッピングは影響を受けず、これらのマッピングに加えられたカスタマイズは維持されます。実際に変更されたマッピングのみに、カスタマイズを再適用するための作業が必要になります。お薦めするアプローチに従えば、カスタマイズの再適用に必要な作業は最小限に抑えられます。
できるだけ多くのロジックをカプセル化することにより、パッチ・リリースやアップグレードの際に、事前に構成済のロジックに加えられる変更は、拡張ロジックに影響することなく置換できるようになっています。次の図を参照してください。
公開オブジェクトに変更がある場合は、拡張ロジックよりも新しいロジックが常に優先されます。ただし、すべての拡張が破棄されるのではなく、大部分の拡張ロジックは残され、必要なのは公開オブジェクトへの再適用のみです。たとえば、ソースからのカラムを追加し、ターゲットにロードしている場合、アップグレード時には、アップグレードされたマッピングによって、追加のカラムがソースから取得され、ターゲットにロードされます。
ソースとターゲットは完全に置換されるため、これらへの拡張はInformaticaでは失われます（データベース内ではカラムが維持されます）。ただし、拡張ロジック自体は、アップグレード後も残されます。ソースとターゲットは、再度拡張してから拡張ロジックに再接続する必要があります。
マッピングを拡張した場合、マッピングの状態に応じて次のように処理されます。
アップグレード時に変更されなかった場合は、すべての拡張が維持されます。
カプセル化されたロジックに変更があった場合は、すべての拡張が維持されます。
公開オブジェクトに変更があった場合は、それらのオブジェクトへの拡張は失われますが、基礎となる拡張ロジックは残されます。公開オブジェクトの拡張は、手動で再適用する必要があります。
カプセル化されたオブジェクトは、オラクル社より指示のないかぎりカスタマイズしないでください。カプセル化されたオブジェクトは通常、マップレットや再利用可能な変換です。
公開オブジェクトは拡張可能ですが、それ以外の変更はできません。公開オブジェクトは、アップグレードで完全に置換される場合があります。
カスタム・オブジェクトは、アップグレード時に変更されません。
アップグレードに必要な作業を最小限に抑えるには、カスタム・オブジェクトを使用して、公開オブジェクトへの変更数をできるだけ少なくしてください。たとえば、ソース修飾子にテーブルを追加して関連テーブルのカラムを渡すのではなく、マッピング内にそのテーブルへの参照を追加してください。
オブジェクトのカスタマイズでは、それぞれの選択肢を評価して、使用環境に最適なアプローチを決定する必要があります。カスタム・オブジェクトのアプローチで、許容可能な時間内にETLを実行できることがわかった場合には、これが好ましいアプローチとなります。カスタム・オブジェクトが原因でETLプロセスに時間がかかる場合には、公開オブジェクトに拡張を組み込むアプローチを検討してください。
Oracle Business Analytics Data Warehouseにカスタム・カラムを追加するときには、チェンジ・キャプチャ・ビューを手動で追加する必要はありません。DACでは、実行時にすべてのカラム（新しいカラムを含む）に対してチェンジ・キャプチャ・ビューが自動的に作成されます。
|
注意: SDEアダプタのほとんどのフォルダでは、Business Componentマップレットの概念が使用されています。これは抽出マップレットであり、リレーショナル、アプリケーションまたはフラット・ファイルのソースが含まれている場合があります。Siebelアダプタのフォルダでは、Business Componentマップレットが使用されません。ソースはマッピングで直接公開されます。通常の場合、Business Componentマップレットは公開オブジェクトとして操作でき、さらに変更が必要な唯一のマップレット・オブジェクトです。 |
データ・ウェアハウスを拡張するときに最も一般的なシナリオは、ソースから既存のカラムを抽出して、データ・ウェアハウスの既存テーブル（要素または次元）に渡すことです。このタイプの変更では通常、SILマッピングの拡張が必要になります。パッケージ化されたソースからデータが取得される場合は、該当するSDEアダプタのマッピングも拡張する必要があります。パッケージ化されていないソースからデータが取得される場合は、汎用アダプタのマッピングを使用する必要があります（該当する汎用アダプタのマッピングが存在しない場合には、作成する必要があります）。
Oracle Business Analytics Warehouseでマッピングを拡張するには:
カスタム・フォルダにマッピングをコピーします。
データベース内のテーブルを変更することにより、ソースおよびターゲットのテーブルを拡張します。次に、ソースおよびターゲットの定義をカスタム・フォルダにインポートするか（既存の定義と置換されます）、または既存の定義を手動で編集します。
カスタム・カラムの名前には「X_」というプレフィックスを付けることをお薦めします。これにより、既存のテーブルに追加されたカスタム・カラムの区別が容易になり、将来オラクル社がテーブルにどのようなカラムを追加しても、名前の競合が発生しなくなります。
追加のカラムを渡すことでSDEマッピングを拡張します。
ソース修飾子（公開オブジェクト）を変更してSQLオーバーライドにカラムを含めるか、または参照（カスタム・オブジェクト）を追加します。
プレースホルダ変換Exp_Customにオブジェクトを接続します。
ターゲット・テーブルにプレースホルダ変換を接続します。
追加のカラムを渡すことでSILマッピングを拡張します。
ソース修飾子（公開オブジェクト）を変更してSQLオーバーライドにカラムを含めます。
ソース修飾子にカラムを追加し、フィルターを通して、Exp_Custom変換、Update Strategyさらにターゲットにカラムを渡します。
カスタム・フォルダにワークフローをコピーします。
必要な変更を反映してDACを更新します。
このシナリオでは、既存のソースからデータ・ウェアハウスの既存テーブルにデータを渡します。この例の会社は、基本テーブルの追加フィールドのうち、データ・ウェアハウスのテーブルW_ORG_Dに追加する必要があるフィールドをすでに特定しています。また、ACCOUNT_LOGという名前の拡張フィールドを使用して、組織に関連する情報を取り込んでいます。さらにこの会社は、レコードを最後に更新した従業員の名前を組織の属性に含めようと考えています。
このシナリオは、サポートされている各種のソースタイプにあてはまります。このソースタイプには、事前にパッケージされたSiebel用アダプタ、事前にパッケージされたSiebel以外のアプリケーション・ソース、およびパッケージされていないデータがあります。
この項の内容は次のとおりです。
ソース修飾子とSQLオーバーライドで、接続済カラムが同じ順序で表示されるようにすることが重要です。ソース修飾子とSQLオーバーライドで、ポートの表示順序が異なるようにしてしまうというミスがよく発生しています。
テーブルの別名が使用されている場合は、SELECT句のカラムで別名を参照する必要があります。第6.2.4.2項「Siebelソースからのデータの抽出例」の例では、新しいカラムLOGINの実際のソースはS_CONTACTですが、SELECT句は別名のLAST_UPDATE_BYを参照しています。
SELECT句では新しいカラムの前に、FROM句では新しいテーブルの前に、コンマを挿入してください。
新しいテーブルは常に、LEFT OUTER結合の構文を使用して定義する必要があります。INNER結合またはRIGHT OUTER結合の構文は、レコードが失われる可能性があるため使用しないでください。
結合は、一意の値セットと一致するように定義してください。一意の関係を持つ結合を定義しないとデカルト積が発生する場合があり、粒度が変わったり、ダウンストリームでエラーが重複します。一意の結合を定義できない場合には、参照変換によってデータを渡す必要があります。これにより、多くても1つのレコードが返されます。
導入したカスタム・コードにはコメントを付けることをお薦めします。コメントには、少なくとも開発者の名前とコードの追加日付を含める必要があります。
この例では、会社はSiebel Business Analyticsリリース7.8を使用しており、S_ORG_EXT拡張テーブルのS_ORG_EXT_X.ATTRIB_04フィールドを使用して、ACCOUNT_LOGに関連するデータを取り込んでいます。レコードを最後に更新した人の名前は、S_CONTACTテーブルのS_ORG_EXT.LAST_UP_BYへの結合によって取得されます。
|
注意: Siebelアダプタのフォルダでは、Business Componentマップレットが使用されません。ソースはマッピングで直接公開されます。 |
Siebelソースからデータを抽出するには:
CUSTOM_SDE_SBL_78_adapterという名前の新しいフォルダを作成します。
このフォルダにSDE_OrganizationDimensionマッピングとワークフローをコピーします。
次のカラムを含めるようにターゲット定義W_ORG_DSを編集します。
| カラム名 | データタイプ |
|---|---|
| X_ACCOUNT_LOG | VARCHAR2(10) |
| X_LAST_LOGIN | VARCHAR2(10) |
|
注意: ソース・テーブルがカスタマイズされている場合は、そのソース・テーブルをカスタム・フォルダに再インポートして、現在のテーブルと置き換える必要があります。この例では、ソース・テーブルは変更されていません。 |
拡張テーブルS_ORG_EXT_Xは、このマッピングですでに結合されています。「Source Definition」から「Source Qualifier」にATTRIB_04カラムをドラッグします。このカラムは、X_CUSTOMカラムの後に表示されます。
S_CONTACTは、最後に更新した人に対してまだ結合されていないため、S_CONTACTのコピーをマッピングにドラッグします（ソース修飾子が存在する場合には、このソースに関連付けられた新しいソース修飾子を削除します）。
ソースの名前は、表現しているものを示すように変更することをお薦めします。この場合は、ソースの名前をS_CONTACT_LAST_UPDATE_BYに変更します。
「Source Definition」から「Source Qualifier」にLOGINカラムをドラッグします。
EXP_Custom ExpressionにATTRIB_04およびLOGINをドラッグします。
これらのポートの名前は、取得元のテーブルおよびカラムを示すように変更することをお薦めします。
マッピングを変更し、関連する公開オブジェクトを置換する場合は、カスタム式は置換されないため、前述のように処理すると再接続しやすくなります。
適切なポートをターゲット定義に接続します。
ソース修飾子でSQLオーバーライドを編集します。
SELECT句のX_CUSTOMの直後に、ATTRIB_04カラムおよびLOGINカラムを追加します。
FROM句にテーブルを追加します。
結合基準を追加します。
Siebelアプリケーションは、複数のデータベース・プラットフォームで実行可能です。データベースの独立性を維持するには、Informaticaの結合構文でSQLを記述する必要があります。これにより、実行時に適切なデータベース構文に自動的に変換されます。テーブルの追加時には、結合を定義するときにInformaticaの構文に必ず従ってください。
次のSQLの例では、変更されたコードが太字フォントで表示されています。
S_ADDR_ORG.LAST_UPD, S_ORG_EXT_T.LAST_UPD, 0 AS X_CUSTOM - Added by J.Smith on 1/10/2007 ,S_ORG_EXT_X.ATTRIB_04 ,LAST_UPDATE_BY.LOGIN FROM V_ORG_EXT S_ORG_EXT, S_ORG_EXT BU_NAME, ... S_ORG_EXT_T, S_ORG_EXT_X, S_ADDR_ORG, … S_MKT_SEG PRTNR_MKTSEG, S_MKT_SEG TRGT_MKTSEG -Added by J.Smith on 1/10/2007 ,S_CONTACT LAST_UPDATE_BY WHERE { V_ORG_EXT S_ORG_EXT LEFT OUTER JOIN S_ORG_EXT_X ON S_ORG_EXT.ROW_ID = S_ORG_EXT_X.PAR_ROW_ID … LEFT OUTER JOIN S_MKT_SEG TRGT_MKTSEG ON ORG.PR_ORG_TRGT_MKT_ID = TRGT_MKTSEG.ROW_ID - Added by J.Smith on 1/10/2007 LEFT OUTER JOIN S_CONTACT LAST_UPDATE_BY ON S_ORG_EXT.LAST_UPD_BY = LAST_UPDATE_BY.ROW_ID }
変更を保存します。
Workflow Managerで、セッションを更新および検証します。
これは、マッピングに加えた変更がセッションを無効にする場合があるため必要になります。
既存のSDEマッピングに以前は含まれていなかった新しいテーブルのデータを渡す場合は、補助的なチェンジ・キャプチャ・マッピングを作成することが必要になる場合があります。これにより、新しいテーブルの行が変更されたときに、メイン・テーブルの対応する行に変更済というマークが付けられます。補助的なプロセスを作成しないと、新しいテーブルの新しいカラムが変更されても、基本テーブルに変更がなければ、このイベントは処理されません。なお、補助的な処理により、ETLのパフォーマンスが低下する可能性があることに注意してください。そのため、関連するテーブルに変更があった場合に、メイン・レコードに変更済というフラグを付ける必要がないときには、このマッピングの構築は省略してください。
この例では、会社はOracle Applicationsリリース11.5.8を使用しており、HZ_CUST_ACCOUNTS.ATTRIBUTE1フィールドを使用して、ACCOUNT_LOGに関連するデータを取り込んでいます。レコードを最後に更新した人の名前は、HZ_CUST_ACCOUNTS.LAST_UPDATE_LOGINフィールドにすでに格納されています。他のテーブルに結合する必要はありません。
Oracle Applicationsは常にOracleデータベースで実行されるため、SQLオーバーライドで結合を定義するときにはInformaticaのSQL構文を使用する必要はありません。他のテーブルを追加する必要がある場合は、Oracleの標準的な構文を使用して結合を定義できます。
ソースとして別のテーブルを追加する場合は、結合の定義に加えて、次の構文でWHERE句にテーブルのLAST_UPDATE_DATEも含める必要があります。
OR TABLE_NAME.LAST_UPDATE_DATE > TO_DATE('$$LAST_EXTRACT_DATE', 'MM/DD/YYYY HH24:MI:SS')
)
AND
…
これにより、テーブルのレコードに加えた変更で、抽出がトリガーされます。このテーブルのみに更新があり、それ以外のテーブルが更新されなかった場合は、この変更は検出されません。
|
注意: SDEアダプタのほとんどのフォルダでは、Business Componentマップレットの概念が使用されています。これは抽出マップレットであり、リレーショナル、アプリケーションまたはフラット・ファイルのソースが含まれています。通常の場合、Business Componentマップレットは公開オブジェクトとして操作でき、さらに変更が必要な唯一のマップレット・オブジェクトです。公開オブジェクトは変更できますが、アップグレード時に変更内容が失われる可能性があるというリスクを伴います。 |
パッケージされたSiebel以外のソースからデータを抽出するには:
CUSTOM_SDE_ORA1158_adapterという名前の新しいフォルダを作成します。
このフォルダにSDE_ORA_OrganizationDimension_Customerマッピングとワークフローをコピーします。
次のカラムを含めるようにターゲット定義W_ORG_DSを編集します。
| カラム名 | データタイプ |
|---|---|
| X_ACCOUNT_LOG | VARCHAR2(10) |
| X_LAST_LOGIN | VARCHAR2(10) |
|
注意: ソース・テーブルがカスタマイズされている場合は、そのソース・テーブルをカスタム・フォルダに再インポートして、現在のテーブルと置き換える必要があります。この例では、ソース・テーブルは変更されていません。 |
マッピングを開きます。
Business Componentのmplt_BC_ORA_OrganizationDimension_Customerマップレットを右クリックして、「Open Mapplet」を選択することにより、このマップレットを編集します。
Business Componentマップレットは、通常編集できる唯一のマップレットです。これ以外のマップレットは、オラクル社より指示のないかぎり編集しないでください。
「Source Qualifier」にLAST_UPDATE_LOGINカラムおよびATTRIBUTE1カラムをドラッグしてから、これらのカラムを「Mapplet Output」にドラッグします。
次のようにソース修飾子を編集して、新しいカラムを含めます。
SELECT … HZ_PARTIES.SIC_CODE - Added by J.Smith on 1/10/2007 , HZ_CUST_ACCOUNTS.LAST_UPDATE_LOGIN , HZ_CUST_ACCOUNTS.ATTRIBUTE1 FROM HZ_CUST_ACCOUNTS, HZ_PARTIES WHERE …
マッピングに戻ります。
新しい式を追加して、名前をX_CUSTOMに変更します。
Business Componentマップレットの新しいカラムをこの式に接続します。
これらのポートの名前は、取得元のテーブルおよびカラムを示すように変更することをお薦めします。マッピングを変更し、関連する公開オブジェクトを置換する場合は、カスタム式は置換されないため、前述のように処理すると再接続しやすくなります。
ターゲット定義の対応するカラムに、これらのカラムを接続します。
変更を保存します。
Workflow Managerで、セッションを更新および検証します。
これは、マッピングに加えた変更がセッションを無効にする場合があるため必要になります。
この例では、会社には旧来のメインフレームがあり、そのデータをデータ・ウェアハウスに組み込もうと考えています。このためには、FILE_ORGのソース定義と一致するように、データを事前にフォーマットしておく必要があります。既存のソース定義には、会社が必要とする追加データのカラムが含まれていないため、ソース定義を変更してそれらのカラムを含める必要があります。
|
注意: 汎用アダプタのフォルダでは、Business Componentマップレットが使用されません。ソースはマッピングで直接公開されます。 |
汎用ソースからデータを抽出するには:
CUSTOM_SDE_Universal_adapterという名前の新しいフォルダを作成します。
このフォルダにSDE_Universal_OrganizationDimensionマッピングとワークフローをコピーします。
次のカラムを含めるようにソース定義を編集します。
| カラム名 | データタイプ |
|---|---|
| ACCOUNT_LOG | String(10) |
| LAST_LOGIN | String(10) |
次のカラムを含めるようにターゲット定義W_ORG_DSを編集します。
| カラム名 | データタイプ |
|---|---|
| X_ACCOUNT_LOG | VARCHAR2(10) |
| X_LAST_LOGIN | VARCHAR2(10) |
マッピングを開きます。
「Source Qualifier」にLAST_UPDATE_LOGINカラムおよびATTRIBUTE1カラムをドラッグします。
新しい式を追加して、名前をEXP_CUSTOMに変更します。
ソース修飾子の新しいカラムをこの式に接続します。
ターゲット定義の対応するカラムに、これらのカラムを接続します。
変更を保存します。
Workflow Managerで、セッションを更新および検証します。
これは、マッピングに加えた変更がセッションを無効にする場合があるため必要になります。
必要なデータを抽出してステージングしたら、データ・ウェアハウス内の既存のターゲット・テーブルにロードする必要があります。
データ・ウェアハウス内の既存のターゲット・テーブルにデータをロードするには:
CUSTOM_SILOSという名前の新しいフォルダを作成します。
このフォルダにSIL_OrganizationDimensionマッピングとワークフローをコピーします。
次のカラムを含めるようにソース定義W_ORG_DSを編集します。
| カラム名 | データタイプ |
|---|---|
| X_ACCOUNT_LOG | VARCHAR2(10) |
| X_LAST_LOGIN | VARCHAR2(10) |
次のカラムを含めるようにターゲット定義W_ORG_Dを編集します。
| カラム名 | データタイプ |
|---|---|
| X_ACCOUNT_LOG | VARCHAR2(10) |
| X_LAST_LOGIN | VARCHAR2(10) |
マッピングを開きます。
「Source Qualifier」にX_ACCOUNT_LOGカラムおよびX_LAST_LOGINカラムをドラッグします。
「Source Qualifier」から「Filter」にX_ACCOUNT_LOGカラムおよびX_LAST_LOGINカラムをドラッグします。
通常は、既存の変換を変更しないでください。フィルターは有効な変換です。データを有効な変換に転送したり、同じデータ・フローに戻すことはできません。この場合、フィルターは公開オブジェクトとみなされ変更可能ですが、アップグレード時に変更内容が失われるリスクがあります。
「Filter」から「Expression」のEXP_CustomにX_ACCOUNT_LOGカラムおよびX_LAST_LOGINカラムをドラッグします。変換を適用する必要がある場合は、この式で適用してください。
「Expression」から「Update Strategy」にX_ACCOUNT_LOGカラムおよびX_LAST_LOGINカラムをドラッグします。
更新戦略は別の有効な変換であるため、フィルターと同様に公開オブジェクトとみなされます。
ターゲット定義の対応するカラムに、これらのカラムを接続します。
変更を保存します。
Workflow Managerで、セッションを更新および検証します。
これは、マッピングに加えた変更がセッションを無効にする場合があるため必要になります。
マッピングをこのように変更したら、DACで変更を登録する必要があります。追加のカラムやインデックスとともに、テーブル定義を含める必要があります。さらに、新しいカスタム・フォルダで変更したセッションをタスクが実行するために必要となる変更を含める必要があります。DACへのデータ・ウェアハウスのオブジェクト登録の詳細は、『Oracle Business Intelligence Applicationsデータ・ウェアハウス管理コンソール・ガイド』を参照してください。
この項の内容は次のとおりです。
すべての次元は、最初にインストールしたときに、カテゴリー1の次元として構成されています。変更履歴を取り込む場合には、カテゴリー2の変更を取り込むように次元を有効化する必要があります。ただし、一般的なカスタマイズ方法としては、次元でカテゴリー2の変更をトリガーする基準を変更します。次元の変更の大半は、カテゴリー1の変更として処理され、既存のカラムには新しい値が単純に上書きされます。次元を有効にすると、ごく一部のカラムがカテゴリー2の変更をトリガーするようになります。カテゴリー2の変更をトリガーするロジックを拡張するには、カテゴリー2の変更を追跡するロジックにカラムを追加します。さらに、このタイプの変更でカテゴリー2の変更をトリガーしないようにする場合には、このロジックからカラムを削除することもできます。同梱されているロジックは変更しないというルールがありますが、カテゴリー2の追跡ロジックの変更はその例外です。カテゴリー2の変更を追跡するロジックは、カテゴリー2の変更をサポートする各SIL次元マッピングの公開オブジェクトに含まれています。
ソース修飾子とフィルター間には参照が存在します。この参照は、ターゲットにすでにレコードが存在しているかどうか、つまり他のシステム・カラムとともに更新する必要があるかどうかを判定するために使用します。カテゴリー2の変更を追跡するカラムは、この参照で返され、次の式に渡されます。参照によって返されたカラムは、ステージング・テーブルから渡されたカラムと比較されます。これらのカラムのいずれかに違いがある場合には、そのレコードにカテゴリー2の変更というフラグが付けられます。
この式には、TYPE2_COLS_DIFFという名前の変数ポートが含まれています。このポートのフラグがYになっている場合は、カテゴリー2の変更がトリガーされます。フラグがNになっている場合は、カテゴリー1の変更がトリガーされます。
カテゴリー2の変更を判定するために使用するカラムを変更するには、カテゴリー2の変更を評価する追加カラムを渡すように参照を変更します。次に、評価時にこのカラムを含めるように変数ポートTYPE2_COLS_DIFFを変更します。
たとえば、SIL_BOMHeaderDimensionマッピングは、次のカラムを比較します。
BOM_HEADER
BOM_VERSION
BASE_QTY
ACTIVE_FLG
カテゴリー2のロジックにBOM_VERSIONを含める場合には、次のTYPE2_COLS_DIFFのロジックを変更します。
IIF(BOM_NUMBER != LKP_BOM_NUMBER, 'Y', IIF(BOM_VERSION != LKP_BOM_VERSION, 'Y', IIF(BASE_QTY != LKP_BASE_QTY, 'Y', IIF(ACTIVE_FLG != LKP_ACTIVE_FLG, 'Y', 'N'))))
これを次のように変更します。
IIF(BOM_NUMBER != LKP_BOM_NUMBER, 'Y', IIF(BOM_VERSION != LKP_BOM_VERSION, 'Y', IIF(BASE_QTY != LKP_BASE_QTY, 'Y', IIF(ACTIVE_FLG != LKP_ACTIVE_FLG, 'Y', IIF(BOM_VERSION!= LKP_ BOM_VERSION, 'Y', 'N')))))
この項では、（事前に存在しているか、またはカスタムの）次元を既存の要素に追加する方法について説明します。ここでは、この次元のポピュレートに必要なプロセスが構築済であると想定しています。
このプロセスでは、要素ステージング・テーブルと要素データ・ウェアハウス・テーブルの両方を拡張して新しいカラムに含めます。Informaticaでは、Oracleデータベースタイプを使用してテーブルを定義することに注意してください。ステージング・テーブルは、varchar2(80)フィールドとして定義し、名前には_IDサフィックスを付ける必要があります。データ・ウェアハウス・テーブルのカラムは整数として定義し、名前には_WIDサフィックスを付ける必要があります。
SDE要素のマッピングは、次元キーの一意の識別子を使用して渡すように変更する必要があります。ここでは、基本テーブルと一意の識別子の間になんらかの関係があると想定しています。また、すでに基本テーブルに格納されているか、関連テーブルへの結合によって格納されている場合もあります。ソース・システムに応じて、この識別子は1つのカラムを基準にするか、複数のカラムから導出できます。表6-1は、INTEGRATION_IDの導出に使用する様々なフォーマットを示しています。このIDは次元キーの識別に使用します。INTEGRATION_IDの値は、要素ステージング・テーブルに渡す必要があります。
表6-1 INTEGRATION_IDを導出するフォーマット
| 次元 | 外部キー | ソースがOracleアプリケーションの場合 | ソースがSiebelアプリケーションの場合 |
|---|---|---|---|
|
W_AP_TERMS_D |
TO_CHAR(TERM_ID) |
該当なし |
|
|
W_BUSN_LOCATION_D |
ASSET_LOC_WID |
ASSET_LOC~' || LOCATION_ID |
該当なし |
|
W_BUSN_LOCATION_D |
EMP_LOC_WID |
EMP_LOC~' || LOCATION_ID |
該当なし |
|
W_BUSN_LOCATION_D |
INVENTORY_LOC_WID |
STORAGE_LOC' || '~' || ORGANIZATION_ID || '~' || SUBINVENTORY_CODE || '~' || INVENTORY_LOCATION_ID |
該当なし |
|
W_BUSN_LOCATION_D |
PLANT_LOC_WID |
'PLANT' || '~' || TO_CHAR(ORGANIZATION_ID) |
該当なし |
|
W_BUSN_LOCATION_D |
RECEIVING_LOC_WID |
'RECIPIENT_LOC' || '~' || TO_CHAR(LOCATION_ID) |
該当なし |
|
W_BUSN_LOCATION_D |
STORAGE_LOC_WID |
'STORAGE_LOC' || '~' || ORGANIZATION_ID || '~' || SECONDARY_INVENTORY_NAME || '~' |
該当なし |
|
W_CUSTOMER_FIN_PROFL_D |
CUSTOMER_FIN_PROFL_WID |
P'||'~'||TO_CHAR(CUSTOMER_ID) ||'~' || TO_CHAR(SITE_USE_ID) ||'~' || CURRENCY_CODE - CUSTOMER_ID is CUST_ACCOUNT_ID from HZ_CUST_ACCOUNTS and CURRENCY_CODE is from HZ_CUST_PROF_CLASS_AMTS |
該当なし |
|
W_CUSTOMER_LOC_D |
顧客の場所のキーを取得するには、次のW_CUSTOMER_LOC_USE_Dを参照します。 |
該当なし |
|
|
W_CUSTOMER_LOC_USE_D |
TO_CHAR(SITE_USE_ID) - HZ_CUST_ACCOUNT_ROLESからサイトのユーザーIDを取得します。 |
該当なし |
|
|
W_FREIGHT_TERMS_D |
LOOKUP_CODE |
該当なし |
|
|
W_GL_ACCOUNT_D |
to_char(ccid) |
該当なし |
|
|
W_INT_ORG_D |
COMPANY_ORG_KEY |
COMPANY'||'~'||TO_CHAR(SET_OF_BOOKS_ID) |
S_ORG_EXT.ROW_ID |
|
W_INT_ORG_D |
*_ORG_KEY |
プレフィックスを削除して、TO_CHAR()を使用します。 |
S_ORG_EXT.ROW_ID |
|
W_ORG_D |
CUSTOMER_WID |
TO_CHAR(CUSTOMER_ID) - CUSTOMER_IDは、HZ_CUST_ACCOUNTSのCUST_ACCOUNT_IDです。 |
UNION OF S_ORG_EXT AND S_CONTACT。ソースがS_ORG_EXTのときには、ROW_IDが渡されます。ソースがS_CONTACTのときには、''C-'||ROW_IDを使用します。ROW_IDは（S_ORG_EXTでなく）S_PERSONのROW_IDです。これは、（CUSTOMER_WIDとして読み取る）ACCOUNT_WIDを解決するために、W_ORG_Dの顧客担当者の参照用に渡す新しい値です。 |
|
W_PAYMENT_METHOD_D |
LOOKUP_CODE |
該当なし |
|
|
W_PAYMENT_METHOD_D |
TO_CHAR(TERM_ID) |
該当なし |
|
|
W_PERSON_D |
CUST_CONTCT_WID |
TO_CHAR(PARTY_ID) - HZ_PARTY_RELATIONSのPARTY_ID |
S_CONTACT.ROW_ID |
|
W_PRODUCT_D |
PRODUCT_WID |
TO_CHAR(INVENTORY_ITEM_ID) |
S_PROD_INT.ROW_ID |
|
W_SALES_PRODUCT_D |
TO_CHAR(INVENTORY_ITEM_ID) ||'~'||TO_CHAR(ORGANIZATION_ID) |
該当なし |
既存の次元を追加する場合には、SILマッピングを拡張して、事前に存在している再利用可能な参照変換をその次元に含める必要があります。X_CUSTOMカラムで識別されたパスのマッピングによって、次元のINTEGRATION_IDを渡し、フィルター変換後に参照に接続します。さらに、参照にDATASOURCE_NUM_IDを接続します。緩やかに変化する次元の場合は、要素テーブルの標準または基準となる日付も参照に渡す必要があります。これは、次元がカテゴリー2の変更を取り込むように有効化されていない場合でも同様です。
参照のROW_WIDをX_CUSTOM変換に接続し、参照からレコードが返されない場合にこの値を0にデフォルト設定するロジックを含めてください。このカラムを更新戦略に渡してからターゲットに渡します。
DACを更新して、要素テーブルの定義内のこの次元に外部キーを含めます。この要素テーブルのロードを開始する前にDACがこの次元テーブルにポピュレートするように、サブジェクトエリアを再アセンブルし、実行プランを再構築する必要があります。
要素テーブルに日付次元を追加する場合は、SDEマッピングによって、ステージング・テーブルに日付自体を渡すことのみが必要になります。SILマッピングでは、X_CUSTOMと同じパスで日付を渡します。フィルターの後ろに、再利用可能な式EXP_DAY_DIMENSION_FK_RESOLUTIONを追加します。日付を任意の入力に接続し、対応する出力をEXP_Custom変換に接続します。次に更新戦略に接続し、最後にターゲットに接続します。
金額は、元の通貨からデータ・ウェアハウスの通貨に変換する必要があります。マッピングで接続済ではない場合には、金額とともに通貨コードを渡す必要があります。ソース・システムによっては、複数の通貨コードが存在する場合もあります。
ソースがSiebelの場合、通常は1つの通貨タイプしか存在しません。
他のソースには、複数の通貨タイプが存在する場合があります。この操作方法の理解を深めるには、通貨コードの構成に関する項を参照してください。
SILマッピングがまだ含まれていない場合には、フィルターの後ろにマップレットMPLT_CURCY_CONVERSION_RATESを追加し、すべての必須入力ポートに接続します。
適切な為替レートをEXP_Custom式に接続します。適切な為替レートを使用して、金額をデータ・ウェアハウスの通貨に変換します。変換された通貨を更新戦略に渡してからターゲットに渡します。
この項の内容は次のとおりです。
第6.4.4項「Oracle Business Analytics Warehouseのカスタマイズに関する重要な注意事項」
第6.4.8項「Oracle Business Analytics Warehouseでの新しい要素テーブルに対する新しい次元テーブルの追加」
この項では、ソース・テーブルから、抽出済ではないデータがロードされる、完全に新しいテーブルの作成について説明します。たとえば、新しいProject次元テーブルの作成が必要になる場合があります。この場合は、新しい次元テーブルとステージング・テーブルおよび新しい抽出を作成して、ETLマッピングをロードします。
新しいカスタム・テーブルを作成するときには、WC_というプレフィックスを使用します。これにより、オラクル社から提供されているテーブルとカスタム・テーブルが区別しやすくなり、今後オラクル社が類似する名前のテーブルをリリースした場合にも、名前が競合しなくなります。たとえば、Project次元の場合には、WC_PROJECT_DSとWC_PROJECT_Dテーブルを作成できます。
新しい次元テーブルまたは要素テーブルを作成するときには、それぞれのデータ・ウェアハウス・テーブルに含まれる必須のシステム・カラムを使用して、整合性と、既存のテーブル構造への参照可能性を維持します。新しいテーブルを作成するときには、テーブルとインデックスをDACで登録する必要があります。DACでは、Informaticaの新しいワークフローに対する新しいタスクを登録してから、対応するサブジェクトエリアを再アセンブルし、対応する実行プランを再構築することも必要になります。サブジェクトエリアのアセンブルおよび実行プランの構築の詳細は、『Oracle Business Intelligence Applicationsデータ・ウェアハウス管理コンソール・ガイド』を参照してください。
|
注意: DB2-UDBデータベースでテーブルを作成する場合には、DACでテーブルを登録するときに、「Not Logged Initially」オプションを有効にしてください。 |
カスタム・ステージング・テーブルに必要なカラムは次のとおりです。
INTEGRATION_ID: ソース・テーブルに、レコードの主キーまたは一意の識別子を格納します。
DATASRC_NUM_ID: データの抽出元のデータソースを格納します。
次元テーブルおよび要素テーブルには、INTEGRATION_IDカラムとATASRC_NUM_IDカラムのほかに、次のカラムも必要です。
ROW_WID: ETLプロセスで生成される順序番号。データ・ウェアハウスの一意の識別子として使用されます。
ETL_PROC_WID: ETLプロセス情報のIDを格納します。ETLプロセスの詳細は、データ・ウェアハウス側のW_ETL_RUN_Sテーブルに格納されます。これは、DACの「Current Run/Run History」画面に表示される「Process ID」でもあります。
Oracle Business Analytics Warehouseのスキーマのすべてのテーブルには、一意のユーザー・キーの一部としてDATASRC_NUM_IDが含まれています。通常、トランザクション・アプリケーションでは主キーが一意に維持されますが、複数のトランザクション・システム間で主キーが重複することは可能です。このデータをデータ・ウェアハウスにロードするときに問題が発生しないようにするために、ユーザー・キーの一部としてDATASOURCE_NUM_IDを含めると、一意性を維持できます。つまり、各データソースでこのカラムに異なる値が与えられている場合、それらの異なるソースの行を同じデータ・ウェアハウス・テーブルにロードできます。
|
注意: DATASRC_NUM_IDは、DACで維持されます。ソース・システムごとに一意の値が割り当てられていることを確認してください。同じソース・システムに対して複数のインスタンスを作成することもできます（米国ベースと欧州ベースのSiebelトランザクション・データベースを同じデータ・ウェアハウスにロードするなど）。2つの異なるトランザクション・データベース・システムには、DACで異なるDATASOURCE_NUM_ID値を割り当てる必要があります。DACは、Siebelの1つのエントリに事前定義されており、DATASOURCE_NUM_IDの値には1が割り当てられています。別のSiebelトランザクション・データベース・システムからデータを抽出し、同じデータ・ウェアハウスにデータをロードする場合には、Siebelトランザクション・データベース・システムごとに異なるDATASOURCE_NUM_IDを割り当てる必要があります。 |
Oracle Business Analytics Warehouseを変更する場合は、カスタム・フォルダを作成して、そのフォルダ内で変更する必要があります。同梱されているフォルダ内のオブジェクトは、オラクル社からの明確な指示がないかぎり変更しないでください。同梱されているフォルダとその中のオブジェクトは、将来のアップグレードで上書きされる場合があります。
配置済リポジトリには、カスタム・フォルダが含まれていないため、独自のフォルダを作成する必要があります。カスタマイズ用に配置したSDEフォルダごとにカスタム・フォルダを作成する必要があります。このフォルダには、各種のソースに対する抽出マッピングを格納します。また、SILOSフォルダをカスタマイズするには、別のカスタム・フォルダを作成する必要があります。カスタマイズした抽出マッピングとロード・マッピングは、同じフォルダに格納しないでください。
オブジェクトを変更する最も簡単な方法は、同梱のフォルダに入っている既存のオブジェクトを対応するカスタム・フォルダにコピーし、既存のビジネス・コンポーネント、ソースおよびターゲットの定義、変換、マップレット、およびマッピングを再利用することです。
|
注意: ソース・テーブルが拡張されている場合は、Informatica Designerでソース・テーブルを手動で編集する必要があります。テーブルは、データベースからリポジトリにインポートしないでください。インポートすると、Oracle Business Analytics Warehouse全体のソース・テーブル定義が変更されてしまいます。 |
データベースからカスタム・フォルダに新しいテーブルをインポートするときには、Oracle Business Analytics Warehouseとトランザクション・データベースのODBCデータベース接続を使用して（データベース・ベンダーが提供するODBCドライバを使用）、ソースとターゲットのデータベースに接続します。
新しいテーブル定義をインポートしたら、使用しているデータベース・プラットフォームに関係なく、Informaticaリポジトリ内のデータベースタイプをOracleに変更します。この変更は、リレーショナル・データベースの選択には影響しません。この手順は重要です。Informaticaでは、ソース・テーブルのデータベースタイプが同一でない場合、ソース・テーブルを参照するマッピングとワークフローがすべて無効になるためです。
カスタム・ワークフローは、カスタマイズされたすべてのマッピングに対して作成する必要があります。カスタム・ワークフローを作成するときの一般的な要件は次のとおりです。
各ワークフローが1つのテーブルのみをロードするように作成します。これにより、ワークフローをDACに統合できるようになります。
ワークフロー名は、ワークフロー内で使用されているセッション名と一致している必要があります。これにより、DACでも特定の統計情報が収集できるようになります。
ワークフロー内のすべてのセッションに対して、フラグ「Fail parent if this task fails」を選択する必要があります。
ワークフロー内のすべてのセッションに対して、フラグ「Fail parent if this task does not run」を選択する必要があります。
ワークフロー内のすべてのセッションに対して、「Stop on Errors」パラメータを「1」に設定する必要があります。このパラメータは、Informatica Designerの「Config Object」タブの「Error Handling」エリアにあります。
Informatica Designerで、適切なソースおよびターゲットの接続値を設定します。
ワークフローを完全ロード・コマンドに使用する場合は、バルク・モードでのロードを選択できます（OracleデータベースおよびDB2-UDBデータベースにのみ該当）。DACでワークフローを完全ロード・コマンドに使用する場合は、Informatica Designerの「Properties」タブで「Target Load」タイプを「Bulk」に設定します。この場合、ロード時にターゲット・テーブルにインデックスが含まれていない必要があります。DACがインデックスを自動的に削除するため、ユーザー側ではアクション不要です。
次元テーブルや要素テーブルなど、すべてのエンティティに2つのワークフローを作成します。1つは完全ロードに使用し、もう1つは増分ロードに使用します。両方のワークフローは、同じマッピングに基づきます。完全ロードと増分ロードの両方で、同じマッピングが実行されます。これにより、2つのロード方法のそれぞれで調整が可能になります。
ワークフローが、完全モードで次元をロードするように設計されている場合は、指定されていない行の作成セッションもワークフローに含まれていることを確認してください。
DACでタスクを定義するときには、適切な切捨てオプションを選択する必要があります。これにより、テーブルのインデックスを削除および作成するかどうかをDACが決定できるようになります。
ターゲット・テーブルを切り捨てるときに、Informaticaの「truncate target」オプションは使用しないでください。複数のソース・システムから抽出して同じデータ・ウェアハウスにロードするとき、DACが切捨てを処理することは特に重要です。DACは、テーブルを切り捨てる必要があるのがいつなのかを動的に決定します。Informaticaワークフローで切捨てオプションを設定すると、テーブルは常に切り捨てられるようになり、複数のソースからデータを抽出してロードする機能が制限されます。たとえば、Informaticaセッションでは別のセッションの実行時にステージング・テーブルが切り捨てられるため、2つのシステムからデータを抽出して同じステージング・テーブルにロードする処理をパラレルに実行できなくなります。
一部のセッションを順番に実行する必要があり、かつワークフローの失敗時にすべてのセッションを再実行する必要がある場合は、セッションを順番に実行する単一のワークフローの設計を検討してください。失敗時にすべてのセッションを再実行する必要がない場合は、別々のワークフローの設計について検討し、DACで依存性を定義してください。
カスタム・ワークフローは、DACで登録することによりETLプロセスに組み込むことができます。新しいタスクはすべてDACで登録し、プロパティを適切に設定する必要があります。また、DACでは、ソース・テーブルおよびターゲット・テーブル、タスク定義、および依存性を登録する必要があります。
すべてのカスタマイズ作業は、特に指定がないかぎりカスタム・フォルダで実行し、Informaticaリポジトリのアップグレード時にカスタマイズ作業が維持されるようにする必要があります。標準フォルダでは、できるかぎり作業しないでください。Informaticaリポジトリのアップグレードは、標準フォルダに加えた変更より優先されます。
Informaticaでのテーブル定義: 外部データソースからテーブル定義をインポートするときには、SQLのスタイルをOracleに設定してください。これは、実際のデータソースが、DB2やMSSQLなど別のデータベースタイプの場合でも、データのロード方法のロジックには影響しません。
更新戦略: 新しい要素テーブルおよび次元テーブルをロードするときには、ソース側でカスタム・プロセスを設計して、新規または変更されたレコードが検出されるようにします。SDEプロセスは、変更されたデータ（新規または変更済）のみをロードするように設計する必要があります。データが増分プロセスなしにロードされた場合、それ以前にロードされたデータが再度更新され、余分なコストのかかるプロセスになります。たとえば、事前に構成済のSILマッピング内のロジックは、INTEGRATION_IDおよびDATASRC_NUM_IDに基づいてロード先のテーブルを参照し、これらの組合せが存在する場合にはROW_WIDを返します。その場合、レコードが更新されます。参照でNULLが返された場合は、レコードが挿入されます。場合によっては、前述のカラムとともに、ターゲット・テーブルに格納されている最終更新日も比較され、挿入または更新が決定されます。詳細は、事前に構成済のフォルダ内の同様のマッピングを参照してください。
ETLプロセス: データ・ウェアハウスに対して複数のソースを使用するときには、すべてのソースから同時にロードするか、別々の実行プランを使用して異なる頻度でロードするかを決定できます。
ターゲット・テーブルの切捨て: 切捨てはDACで実行する必要があります。1つのタスクには、完全ロード用のプレースホルダと増分ロード用のプレースホルダがあります。
SDEワークフローの場合、完全ロードと増分ロードでコマンドは同一です。これらのコマンドには、DACで「Truncate Always」フラグが選択されている必要があります。この種類のタスクでは、完全ロードと増分ロードのコマンドは、同じマッピングに基づいています。
SILワークフローの場合、完全ロードと増分ロードで別々のコマンドを使用するようにできます。これらのコマンドには、DACで「Truncate For Full Load」オプションが選択されている必要があります。テーブルが切り捨てられると、データがロードされた後にインデックスが自動的に削除および作成されます。完全ロード・コマンドに関連付けられたワークフローでは、データを高速で挿入する最適版のマッピングに対して、「Bulk Load」オプションを選択できます。テーブルにインデックスがあると、バルク・ロードが失敗する場合があります。このため、インデックスはDACで登録し、バルク・ロード・オプションを使用する場合は、完全ロード時にこのテーブルのインデックスをすべて削除することが重要です。
ソースに補助タスクが必要な場合には、増分モードでのみ実行する必要があります。そのため、これらのタスクについては、完全ロード・コマンドが空になります。切捨てオプションは設定しないでください。
ETL_PROC_WID: カスタム・マッピングでは、W_PARAM_Gテーブルにある同じETL_PROC_WIDを使用します。ETL_PROC_WIDは、DACの「Run History」への参照キーです。同じETL_PROC_WIDを使用するには、SILOSフォルダに定義されている再利用可能な参照（LKP_ETL_PROC_WID）をコピーします。参照への入力は定数です（「1」にハード・コーディングされています）。
DATASRC_NUM_ID: パラメータを使用して、マッピングにこの値を定義します。DACは、正しいDATASOURCE_NUM_IDが設定されたパラメータ・ファイルを自動的に作成します。このIDはマッピングのパラメータによって取得されます。これにより、トランザクション・データベースタイプの同じインスタンスが複数存在するときに、同じマッピングのコピーを複数作成できます。DACでソースを登録する以外に、別途ハード・コーディングを行う必要はありません。
インデックスと命名規則の作成: ステージング・テーブルには通常、インデックスは不要です。ステージング・テーブルにインデックスが必要かどうかは、慎重に判断してください。ETLで次元と要素に使用されるすべてのカラムにインデックスを作成します(たとえば、次元と要素のROW_WID、INTEGRATION_IDとDATASRC_NUM_ID、およびフラグ）。どのカラムまたはカラムの組合せのフィルター条件が必要かを慎重に検討し、クエリーのパフォーマンス向上につながるインデックスを定義します。参考用にOTBオブジェクトを検査します。新しく作成したすべてのテーブルに、WC_という名前を付けます。これにより、新しいテーブルとOTBテーブルを見た目で区別できます。行ったカスタマイズの内容をきちんとドキュメントに残してください。データ・ウェアハウスをアップグレードするときに役立ちます。インデックスが決定したら、手動で、または特定のテーブルで右クリックして「Import Indices」コマンドを呼び出して、DACで登録します。
通貨: 通貨に関連するデータの場合、基本通貨と（データを適切に変換するための）換算日付フィールドをテーブルにポピュレートします。通貨変換用のデータは、メインのデータソースに保持する必要があります（通貨データは、すべての通貨情報をDACで指定されている1つの基本通貨コードに変換することで保持されます）。
日付次元: W_DAY_Dに関連するデータには、再利用可能な変換EXP_DAY_DIMENSION_FK_RESOLUTIONを使用します。この変換は、入力値として日付を使用し、適切なフォーマット（YYYYMMDD）の外部キーを出力値として日付次元に返します。これにより、解決のたびに、W_DAY_D次元への余分なコストのかかる結合や参照を行う必要がなくなります。再使用可能変換をコピーして使用します。
値リスト（LOV）: この項目は特に、カテゴリー1およびIIに適用されます。値リストに依存する事前に構成済のカラムには、言語に依存するカラムと言語に依存しないカラムがあります。マップレットMPLT_LOV_TRANSLATIONを使用して、言語に依存するカラムおよび依存しないカラムを次元テーブルにポピュレートします。要素テーブルの場合は、MPLT_LOV_D_ROW_WIDを使用し、LOV次元に対して新しい外部キーを作成します。また、変換をSQLオーバーライドで直接処理して、パフォーマンスを改善することもできます。
この手順は、Siebelソース・テーブルにのみ該当します。
チェンジ・キャプチャ・プロセスにソース・テーブルを組み込むには:
ソース・テーブルがDACで登録されているかどうかを確認します。
DACにエントリがない場合には、テーブルに新しいレコードを作成してイメージ・サフィックスを割り当てます。
テーブルが登録されている場合には、このテーブルに割り当てられているイメージ・サフィックスがあることを確認します。
ソース・テーブルにイメージ・サフィックスが存在していない場合には、ここで割り当てます。
イメージ・サフィックスは、3文字以内にする必要があります。Cで始まる命名規則にすることをお薦めします。たとえば、C1、C2、CA1、CA2などを使用します。
このイメージ・サフィックスが他のテーブルで使用されていないことを確認するには、DACのテーブル・リストでそのイメージ・サフィックスにクエリーを実行します。
DACクライアントでは、データ入力時にこの情報は検証されません。
Siebelトランザクション・データベースでイメージ・テーブルを作成します。
DACクライアントでテーブルのレコードを右クリックして、「Generate Change Capture Scripts」を選択します。
この操作は、トランザクション・データベースで削除を追跡するように計画している場合に、イメージ・テーブル、必要なインデックス、およびトリガーの作成に役立ちます。
適切な権限がある場合には、これらのスクリプトをトランザクション・データベースで実行します。適切な権限がない場合には、OLTPのデータベース管理者に権限を作成するように依頼します。
抽出プロセス用に作成するタスクには、「Build Image」フラグを「True」に設定し、新しいテーブルを補助テーブルまたはプライマリ・テーブルとして選択します。
|
注意: チェンジ・キャプチャ・プロセスの終了時には、DACによって、実際のソース・テーブルのビューが作成されます。すべての抽出手順で、このビューをメインのソース・テーブルとして使用してください。たとえば、新しいソース・テーブルがS_COMPENSATIONの場合、デフォルトのビュー名はV_COMPENSATIONになります。 |
次の手順に従って、Oracle Business Analytics Warehouseに新しい次元を追加します。
新しい次元を追加して、既存の要素テーブルで使用するには:
（適切なシステム・カラムがある）標準的な構造に基づいて、新しい次元のDDLを作成します。この次元のステージング・テーブルを作成します。
新しいソース・テーブルとそのステージング・テーブル（まだ存在していない場合）をDACリポジトリに登録し、適切なデータベース接続に関連付けます。
新しいカスタム・マップSDE_XYZを作成して、次元ステージにポピュレートします。実際のソース・テーブル（例、S_ABC）ではなく、SQLでチェンジ・キャプチャ・プロセスによって生成されるビュー（例、V_ABC）を使用して、増分データのみを抽出するようにします。システム・カラムのポピュレート方法の例として、既存の参照マップを使用してください。対応するタスクでは、ステージ・テーブルを切り捨ててください。
新しいカスタム・マップSIL_XYZを作成して、ステージ・テーブルから新しい次元をポピュレートします。システム・カラムのポピュレート方法の例として、前述の参照マップを使用してください。
新しい次元テーブルをDACで登録し、適切なデータベース接続に関連付けます。
新しい次元を増分で構築するように計画している場合は、ソース・テーブルにイメージ・サフィックスを割り当てます。
ワークフローをタスクとしてDACで登録します。
次元のSDEマッピングについては、「Build Imag」フラグを「True」に設定し、「Truncate Always」オプションを「True」に設定します。ソース・テーブルのリストで、この次元のプライマリ・ソースおよび補助ソースにマークを付けます。
次元のSILワーフクローについては、「Truncate for Full Load」オプションのみを「True」に設定します。
SDE_XYZのターゲット・テーブルがSIL_XYZのソース・テーブルとして定義されていることを確認します。
次の手順に従って、Oracle Business Analytics Warehouseに新しい要素テーブルを追加します。
新しい要素テーブルを追加するには:
（適切なシステム・カラムがある）標準的な構造に基づいて、新しい要素のDDLを作成します。この要素のステージング・テーブルを作成します。
新しいソース・テーブル（まだ存在していない場合）をDACリポジトリに登録し、データベース接続に関連付けます。
右クリックして「Generate Change Capture Scripts」を選択して、チェンジ・キャプチャ・テーブルを作成します。手順については、第6.4.5項「チェンジ・キャプチャ・プロセスへのソース・テーブルの組込み」を参照してください。
SDEマッピングを作成して、カスタム・ステージ・テーブルにポピュレートします。チェンジ・キャプチャによって作成されたビューをSQLのメイン・テーブルとして使用し、増分データのみを抽出するようにします。システム・カラムのポピュレート方法の例として、（前述の）参照マップを使用してください。対応するワークフローでは、ステージ・テーブルを切り捨ててください。
SILマッピングを作成して、カスタム要素テーブルにポピュレートします。システム・カラムのポピュレート方法の例として、参照マップを使用してください。
次元テーブルへの参照またはSQLオーバーライド結合を使用して、既存の次元を指す次元外部キー（ROW_WID）をポピュレートします。
DACでは、ターゲット・テーブルを登録します。
ワークフローの新しいタスクを作成します。
SDEタスクについて、「Build Image」フラグを「True」に設定し、クエリー元のすべてのソース・テーブルをすべて一覧表示します。1つ以上のテーブルを、プライマリまたは補助として選択します。ターゲット・テーブルに対して、ステージング・テーブルを選択します。「Truncate Always」フラグを「True」に設定します。
SILタスクについて、ソース・テーブルで必要になる次元をすべて一覧表示します。
新しい次元テーブルを作成する手順は、増分チェンジ・キャプチャの手順とほぼ同じです。
新しい要素テーブルに新しい次元テーブルを追加するには:
新しいカスタム要素のロード・マッピング（SIL）で、新しい次元への外部キーを取得するための参照を使用します。
例として既存のマップを使用してください。
次の手順に従って、Oracle Business Analytics Warehouseの標準的な次元テーブルに、新しいデータを行全体として追加します。
標準的な次元テーブルに、新しいデータを行全体として追加するには:
ステージング・テーブルの既存の構造を特定して理解します。テーブル構造については、『Oracle Business Analytics Warehouse Data Model Reference』を参照してください。システム以外のカラムではNULL値を使用できます。
カスタムSDEマッピングを作成して、この目的のために作成されたカスタム・フォルダのステージング・テーブルにデータをロードします。パフォーマンス上の理由により、ステージング・テーブルには、増分データ（ETLの最終更新プロセス以後に追加または変更された行）をポピュレートする必要があります。
INTEGRATION_IDカラムに、レコードの一意の識別子をポピュレートします。
INTEGRATION_IDとDATASRC_NUM_IDの組合せは一意です。データのインポート時には、外部データソースの一意の識別子をDATASRC_NUM_IDカラムに挿入してください。Siebelトランザクション・データベースをデータ元とするマッピングには、DATASRC_NUM_IDが「1」に設定されます。これは予約値で、すべての標準マッピングに使用されています。たとえば、カスタムSDEマッピングのDATASRC_NUM_IDの値には「2」を定義できます。標準的なSDEマッピングは、次元ステージング・テーブルのINTEGRATION_IDカラムにポピュレートします（次元のSiebelトランザクション・データベースのROW_ID値を解決するために使用されます）。同じカラムに外部データソースから一意の識別子をポピュレートするには、カスタム・プロセスを使用する必要があります。
ステージング・テーブルにデータがポピュレートされたら、標準的なSILマッピングを使用して次元ターゲット・テーブルにポピュレートします。
関連するすべての要素テーブル（この次元にリンクする必要がある要素テーブル）のSDEマッピングおよびSILマッピングを変更します。
カスタム要素SDEマッピングでは、変更された次元の外部キー・カラムにポピュレートする必要があります（カスタム・マップ・テーブル・プロセスを使用して、Siebelの行IDを外部データソースの行IDに変換します）。カスタムSILマッピングは、適切なDATASRC_NUM_IDを使用するように変更する必要があります。これは、標準的なSILマッピングが、次元のDATASRC_NUM_IDが要素テーブルのDATASRC_NUM_IDと同じと想定するためです。
データをロードするタイミングを決定することは重要です。Siebelソース・データとともにロードする場合は、失敗時の修復を慎重に処理する必要があります。事前に構成済のワークフローは、ロード前にターゲットのステージング・テーブルを切り捨てます。失敗時にDACサーバーがタスクを再実行すると、すべてのデータが切り捨てられ、すべてのデータが再度ロードされます。
外部ソースのデータが同じステージング・テーブルにロードされる場合は、切り捨てられたテーブルの機能を使用できないため、この状況に慎重に対処する必要があります。ステージング・テーブルに移行されるデータは増分ロードされないため、このテーブルの再ロードの前にクリーンアップする必要があります。
このような場合、Informaticaワークフロー内の両方のソースから抽出された部分をカプセル化することをお薦めします。いずれかの抽出に失敗した場合には、ワークフロー全体が再実行されます。両方のソースのデータは、常に同時に実行する必要があることに注意してください。
データを異なる頻度でロードするように決定した場合には、新しいSDEワークフローを、事前に構成済のSDEワークフローに依存しないように構成する必要があります。また、新しいSDEワークフローでは、失敗の修復に「Truncate Table」オプションを使用できます。この場合、DACの「Design」ビューでは、「Execution Plans」タブで新しい実行プランを定義し、「Database Connections」子タブで新しいデータソースを定義します。共有SILプロセスが、両方のソースのSDEプロセスに依存するようにしてください。
各アプリケーションには、特定のソースから特定のデータを抽出するための、事前にパッケージ済のロジックがあります。この項では、レポートおよびアドホック・クエリーに対応するデータをすべて取り込む方法について説明します。そのために、データ・ウェアハウスにロードするレコードとロードしないレコードのタイプを扱います。この項の内容は次のとおりです。
Oracle Business Analytics Warehouseでは、抽出マッピングおよび抽出マップレットを構成して、追加のソース・データに対応できます。たとえば、会社が地域に基づいて顧客情報を別々のテーブルに分けている場合は、これらのテーブルからデータを抽出するように抽出マッピングを設定する必要があります。
抽出マッピングは通常、ソース・テーブルまたはBusiness Component、式変換およびステージング・テーブルで構成されています。既存のマッピングを使用して新しいデータを抽出する場合には、次のタスクを実行して、新しいデータを含めるように抽出マッピングを変更する必要があります。
既存のマッピングを変更して新しいデータを含めるには:
既存のBusiness Componentを変更して、ソースから情報を抽出し、対応する拡張カラムに追加します。
|
ヒント: 抽出マッピングのBusiness ComponentマップレットまたはSource Adapterマップレットでは、計算の変換を実行できます。ただし、抽出では処理量の多い計算は使用しないでください。これは、この計算によって、ソースのトランザクション・システムが停滞する恐れがあるためです。このタイプの計算は、Source Adapterマップレットで実行することをお薦めします。 |
必要な変換を実行するように式変換を変更します。
抽出マッピング内の入力ポートおよび出力ポートをすべて接続し、ソースまたはBusiness Componentのデータが、Source Adapterマップレットを経由して式変換に移動し、最終的にステージング・テーブルの対応する拡張カラムに移動するようにします。
ステージング・テーブル内で、どのタイプの拡張カラムにデータをマッピングするかを決定する必要があります。抽出マッピングを変更したら、対応するロード・マッピングも変更して、追加した拡張カラムがステージング・テーブルからウェアハウス・テーブルまでずっと接続されるようにする必要があります。
Business Componentは、マップレットとしてパッケージされており、リポジトリ内のソース固有のフォルダに配置されています。Business Componentは、ソース・システムからのデータ抽出に使用します。このマップレットは、次の処理を実行するように構成できます。
新しいソース・テーブルからのデータの抽出
増分抽出ロジックの設定
次の手順では、Business Componentに新しいテーブルを追加する方法について説明します。この手順では、新しいソース定義の追加、ソース修飾子へのポートの接続、ソース修飾子の編集、出力変換へのポートの接続、および出力変換の編集を行います。
既存のBusiness Componentマップレットに新しいソース・テーブルを追加するには:
PowerCenter Designerで、該当するソース・システムの構成フォルダを開きます。
Mapplet Designerツールを開きます。
Business ComponentマップレットをMapplet Designerにドラッグして、Business Componentを構成する変換を表示します。
Sourcesフォルダを展開し、Mapplet Designerにソース・テーブルをドラッグ・アンド・ドロップして、そのマップレットにコピーします。
対応するポートを新しいソース定義からソース修飾子に接続するために、新しいソース・テーブル内のポートをクリックして、ソース修飾子内の接続先ポートにドラッグします。
「Source Qualifier」をダブルクリックして、「Edit Transformations」ボックスを開きます。
「Ports」タブで、新しいポートのデータタイプ、精度、スケール、またはこれらのすべての数値を必要に応じて変更します。
対応するポートを「Source Qualifier」から「Mapplet Output transformation (MAPO)」に接続します。
|
注意: Business Componentには、ソース修飾子とMAPOの間の式変換が含まれる場合があります。 |
「Properties」タブで、必要に応じてSQL文を変更します。
変更を確認し、リポジトリに保存します。
CSVファイルで使用されているデリミタがソース・データに含まれていないことを確認する必要があります。Oracle Business Analytics Warehouseでは、ソース・ファイルのデリミタにコンマが事前構成されています。データにコンマが含まれている場合は、データセットに存在しない文字を使用してデータ・フィールドを囲む必要があります。たとえば、データを囲む文字には一重引用符や二重引用符が一般的です。
ソース・ファイルのデリミタを設定するには:
CSVファイルを開きます。
あらかじめ定めた文字でデータ・フィールドを囲みます。
囲み文字は、ソース・データに存在しない文字を特定することによって定めることができます。データを囲む文字には一重引用符や二重引用符が一般的です。
CSVファイルを保存して閉じます。
変更されたファイルに関連付けられているソース定義をすべて特定します。
囲み文字を使用するように、これらのソース定義それぞれのプロパティを変更します。
変更を確認し、リポジトリに保存します。
ソース固有の変換の大部分は、Source Adapterマップレットで発生します。ソースに依存しない変換は通常、Analytic Data Interface（ロード・マッピング）で発生します。Source Adapterマップレットは、ソース固有のデータ要素を標準的なフォーマットに変換してからステージング・テーブルに格納します。次に、ソースに依存しないロード・マッピングによって、標準的なフォーマットに変換済のこれらのレコードが取得されます。
次の図は、Source Adapterマップレットのうち、データ変換を実現する3つのコンポーネントを示しています。その3つのコンポーネントとは、マップレット入力（MAPI）、式変換（EXP）、およびマップレット出力（MAPO）です。
前述の図では、入力データが変換された場合、そのデータが入力のみとして式変換（EXP）に渡されます。データが変換されると、EXT_というプレフィックスが付けられて、新しいポートを通じて出力されます。データが変換されない場合は、入力専用として入り、出力専用ポートを通じて出ていきます。
新しい変換を追加する場合には、新しいポートを追加して、データの変換に使用する式を含めます。
Source Adapterマップレットに新しいポートを追加するには:
PowerCenter Designerで、該当するソース・システムの構成フォルダを開きます。
適切なSource Adapterマップレットを開きます。
マップレットのMAPIコンポーネントをダブルクリックして、INP_*の命名規則に従って新しい入力ポートを追加します。
新しい入力ポートをMAPIから式変換にコピーします。
新しいポートをMAPIから式変換に接続します。
式変換で、新しい入力ポートの「Output indicator」の選択を解除します。このポートの値は変換式で使用します。
式変換内で必要な変換を実行します。
変換されたデータは、EXT_*の出力専用ポートから外部へ渡されます。
ポートを式変換からMAPOに接続します。
内容を確認してリポジトリに保存します。
Oracle Business Analytics Warehouseには、あらゆるデータ・ウェアハウス・テーブルのロード・マッピングが事前にパッケージされています。
|
注意: この項は、Oracle Siebelソースには該当しません。 |
標準的な実装では、ソース・システムからレコードが削除されても、そのレコードはOracle Business Analytics Warehouseからは削除されません。ソース・システムのデータベースから削除され別のデータベースにアーカイブされたレコードに、データ・ウェアハウスで削除済というマークを付ける場合は、プライマリ抽出マッピングおよび削除マッピングを有効にする必要があります。
プライマリ抽出マッピングは、データ・ウェアハウスから削除されたレコードにフラグを付けます。削除マッピングは、ウェアハウス・テーブル内のこれらのレコードに対してDELETE_FLGカラムを「Y」に設定します。プライマリ抽出マッピングおよび削除マッピングが有効になっていると、ソース・システムのデータベースから削除されたレコードがデフォルトで検出されます。これらのマッピングは、データベースに存在しなくなったレコードを検出すると、データ・ウェアハウスでそれらに削除済というマークを付けます。
|
注意: 削除マッピングおよびプライマリ抽出マッピングは、常に両方とも無効にする必要があることに注意してください。1つのタイプのみを無効にすることはできません。 |
|
注意: この項は、プライマリ抽出マッピングのないOracle Siebelアダプタには該当しません。 |
プライマリ抽出セッションおよび削除セッションの有効化を決定するときは、あらかじめOracle Business Analytics Warehouse内でそれらのマッピングが果たす機能について理解しておくことが重要です。分析システムでは、プライマリ抽出マッピングおよび削除マッピングによって、ソース・システムから削除されるレコードを判別できます。この処理は、プライマリ抽出ステージング・テーブルと最新のOracle Business Analytics Warehouseテーブルの比較によって行われます。
プライマリ抽出マッピングは、ソース・システムからプライマリキーの完全抽出を実行します。多くの行がこの抽出によって生成されますが、ソース・テーブルから抽出されるデータはキーIDおよびソースIDの情報のみです。プライマリ抽出マッピングは、これら2つのカラムを*_PEサフィックスでマークされたステージング・テーブルにロードします。
次の図は、抽出プロセスの開始の例です。ソース・テーブルの情報が変更された2日間に発生したイベントの順序を示しています。1日目に、ソース・テーブルからデータが抽出され、Oracle Business Analytics Warehouseテーブルにロードされます。2日目に、販売注文番号3が削除されて新しい販売注文が受領されます。そのため、2つのテーブルの販売注文情報に差異が生じます。
図6-8は、2日目の情報が抽出され、ソースからOracle Business Analytics Warehouseにロードされたときに発生するプライマリ抽出プロセスおよび削除プロセスを示しています。最初の抽出で、レコード4がOracle Business Analytics Warehouseに渡されます。次に、プライマリ抽出マッピングを使用して、キーIDとソースIDがソース・テーブルから抽出され、プライマリ抽出ステージング・テーブルにロードされます。
抽出マッピングは、プライマリ抽出ステージング・テーブルのキーと最新のOracle Business Analytics Warehouseテーブルのキーを比較します。このマッピングは、Oracle Business Analytics Warehouseには存在するが、ステージング・テーブルには存在しないレコード（前述の例ではレコード3）を検出し、Source Adapterマップレットの削除フラグを「Y」に設定します。これにより、対応するレコードに削除済というマークが付けられます。
抽出マッピングは、ソースには追加されたが、Oracle Business Analytics Warehouseにはまだ存在していない新しいレコード（この場合はレコード4）もすべて検出します。ステージング・テーブルの情報に基づいて、販売注文番号3がOracle Business Analytics Warehouseから物理的に削除されます（図6-8を参照）。抽出マッピングおよびロード・マッピングを実行すると、ウェアハウスに新しい販売注文が追加されます。
プライマリ抽出マッピング（*_Primary）および削除マッピング（*_IdentifyDeleteおよび*_Softdelete）は、ソース・システムから物理的に削除されたレコードを識別するうえで重要な役割を果たします。ただし、プライマリ抽出マッピングおよび削除マッピングを無効化または削除できる場合もあります。これには、ソース・システムのデータベースから削除され、別のデータベースにアーカイブされているレコードをデータ・ウェアハウスに保持する場合などがあります。
削除マッピングでは、ソースIDとキーIDを使用して、削除されたデータが識別されるため、複数のソース・システムを使用している場合には、SQLクエリー文を変更して、削除マッピングで適切なソースIDが使用されていることを確認する必要があります。プライマリ抽出マッピングおよび削除マッピングに加えて、ロード・マッピングの削除フラグの構成でも、レコードの削除の処理方法を決定できます。
データの抽出と削除は、次の方法で管理できます。
ソースがアーカイブしたレコードの構成の削除
特定のソースからのレコードの削除
削除セッションおよびプライマリ抽出セッションの有効化
レコード削除フラグの構成
レコード却下フラグの構成
ここでは、これらの管理タスクの手順について説明します。
一部のソースは、レコードを別のデータベースにアーカイブして、メイン・データベースの現在の情報のみを保持します。削除マッピングを有効にしている場合は、Oracle Business Analytics Warehouseの削除マッピングを再構成して、アーカイブされたデータを維持する必要があります。
ソースがアーカイブしたレコードをOracle Business Analytics Warehouseで保持するには、$$LAST_ARCHIVE_DATEパラメータの値を、アーカイブの日付を反映するように設定してください。削除マッピングは、アーカイブされたレコードに削除済というマークを付けません。抽出マッピングおよび削除マッピングの詳細は、第6.7.3項「プライマリ抽出マッピングおよび削除マッピングを使った作業について」を参照してください。
ソースが削除したレコードをOracle Business Analytics Warehouseで削除済というマークを付ける場合には、アプリケーションの削除タスクおよびプライマリ抽出タスクを有効にする必要があります。
プライマリ抽出セッションおよび削除セッションを有効にするには:
DACにログインします。
使用するコンテナに移動します。
「Tasks」タブを選択します。
「Delete」と「Primary」いずれかの文字列を含むすべてのタスクにクエリーを実行します。
これらのタスクの「Inactive」チェック・ボックスの選択を解除します。
Oracle Business Analytics Warehouseには、タイプIIの緩やかに変化する次元（SCD）機能が用意されており、これによって、次元レコードの更新履歴を追跡できます。Oracle Business Analytics Warehouseのレコードに更新がある場合、更新情報が新しい行に入力され、古い情報は履歴レポートの目的で残されます。
Oracle Business Analytics Warehouseは、データが抽出され、ソースに依存しないように変換された後に、ユーザーが選択した緩やかに変化する次元のロジックを識別および適用します。ユーザーは、更新によってデータが上書きされるタイプIのSCDと、元のレコードは維持され、新しいレコードには更新されたデータが格納されるタイプIIのSCDの両方をサポートするようにOracle BI Applicationsを構成できます。タイプIとタイプIIどちらのSCDを選択するかは、履歴上重要な属性の特定によって異なります。
デフォルトでは、すべての次元でタイプIの更新が使用されます。次元をタイプIIのSCD更新に変更する必要がある場合は、次の手順に従います。
タイプIIのSCD更新への次元変更を有効にするには:
Informatica PowerCenter 7.1.4\Server\SrcFilesにあるパラメータ・ファイルparameterfileDW.txtを開きます。
パラメータ・セクションで、この次元をロードするSIL_*マッピングを見つけます。
$$TYPE2_FLGに「Y」を設定します。
特定の次元に対する更新すべての履歴を残して、レポートに使用できるようにすることができます。これらの次元は、履歴上重要な属性と呼ばれます。たとえば、ある顧客が別の地域に移転し、その顧客に新しい地域のセールス担当者とテリトリーIDを割り当てた場合、元のセールス担当者とテリトリーIDで記録されたその顧客のアカウント履歴のレコードを維持できます。この場合、元のセールス担当者とテリトリーIDが履歴上重要な属性になります。一方、電話番号フィールドにポピュレートするロードもできます。会社が電話番号履歴に関するデータ分析を実行していない場合は、その情報は履歴上重要でない属性です。
属性が重要かどうかを特定することで、必要なSCDのタイプを決定できます。ただし、適切なタイプのSCDを選択できるようになるには、タイプの違いを理解しておく必要があります。
ステージング・エリアにあるすべてのテーブルの抽出ビューは、次の4種類のレコードで構成されています。
新規レコード
履歴上重要ではないデータを持つ変更済レコード
履歴上重要な変更済レコード
変更内容に重要性がなく、すべて無視される変更済レコード
4種類のレコードのうち、データ・マートで重視されるのは最初の3つのみです。それら3つのうち、まったくの新規レコードと変更がSCDとして追跡されるレコードは、両方とも新規として処理され、データ・ウェアハウスに挿入されます。変更内容が重要であっても履歴が追跡されないレコードは、プライマリキーに基づいて、データ・ウェアハウスで上書きされます。
重要な属性と重要でない属性を正しく特定したら、ユーザー要件に最も適した緩やかに変化する次元（SCD）のタイプ（タイプIまたはタイプII）に基づいて、Oracle Business Analytics Warehouseを構成できます。
タイプIのSCDでは、カラムの値が上書きされます。このタイプが、Oracle Business Analytics WarehouseでデフォルトのSCDになります。タイプIでは、履歴が維持されませんが、最も単純かつ高速に次元データをロードできます。タイプIは、変更された次元の古い値が、追跡で重視する必要がないか、履歴上重要ではない属性とみなされるときに使用します。たとえば、カラム内の不正確な値を変更したときにはタイプIを使用できます。
次の図では、ソース・テーブルSuppliersでサプライヤKMTの「State Name」カラムが変更されています。これは、「California」と誤って入力されていたためです。このデータがデータ・ウェアハウス・テーブルにロードされると、履歴データは保持されず、値は上書きされます。「California」でサプライヤの値を参照した場合、KMTのレコードは表示されません。KMTのレコードは、最初から登録されている「Michigan」で参照した場合にのみ表示されます。
タイプIIのSCDは、別のレコードを作成し、古いレコードをそのまま残します。タイプIIは、履歴上重要な属性を追跡できるため最も多く使用されるSCDです。古いレコードは、最新の変更よりも前の履歴をすべて指し、新しいレコードは、最新の情報を保持します。
緩やかに変化する次元は、スター・スキーマの別々の部分（要素テーブルと次元テーブル）で処理されます。次の図は、抽出テーブル（SOURCE_CUSTOMERS）をデータ・ウェアハウスの次元テーブル（W_ORG_D）にする方法を示しています。この例では、顧客担当者などの属性も追跡されていますが、履歴が追跡される属性はセールステリトリーの1つだけです。会社は業績と報奨金を決定するために頻繁にテリトリーの統計情報を比較するため、これは履歴上重要な属性です。さらに、顧客の地域が変わった場合には、セールス活動が、収益の発生した地域に記録されます。
この例では、ある1日の抽出に限定しており、そこでは各顧客の新しいレコードが渡されます。SOURCE_CUSTOMERSから抽出されたデータは、ターゲット・テーブルW_ORG_Dにロードされ、各レコードには一意のプライマリキー（ROW_WID）が割り当てられます。
ただし、このデータは静的ではありません。次回のデータ抽出でW_ORG_Dに顧客の変更があると、レコードは変更される必要があります。この状況は、緩やかに変化する次元を呼び出したときに発生します。次の図は、2つの顧客ABC Co.とXYZ inc.のレコードが、前述の図と比較して変更された様子を示しています。ABCの「Customer Contact」がMaryからJaneに変更され、XYZの「Sales Territory」がWestからNorthに変更されていることを確認してください。
この例で前述したとおり、「Customer Contact」カラムは履歴上重要ではないため、タイプIのSCDが適用されMaryがJaneに上書きされています。ABCのレコードの変更はタイプIのSCDなので、新しい顧客レコードを作成する理由がありません。一方、XYZのレコードの変更では、セールステリトリーが変更されており、その属性は履歴上重要です。この例では、タイプIIの緩やかに変化する次元が必要です。
次の図のとおり、XYZのレコードでは「Sales Territory」カラムが上書きされないで、新しいレコードが追加され、W_ORG_DのXYZに新しいROW_WIDの172を割り当てています。XYZの元のレコード102は残され、XYZがWestセールステリトリーにあったときに発生した売上すべてにリンクされています。ただし、追加された新しいセールス・レコードが、NorthセールステリトリーのROW_WID 172の属性として新たに加えられています。
有効日は、レコードが有効になるタイミングを指定します。たとえば、新しい顧客の住所を2003年1月10日にロードし、その顧客が2003年1月20日に移転した場合、住所はその2つの日付の間のみ有効です。有効日は次の方法で処理されます。
ソースが発効日と失効日の両方を提供している場合は、それらの日付がウェアハウスのテーブルで使用されます。
ソースが発効日と失効日の両方を提供していない場合は、タイプIIのロジックによって有効日が作成されます。
ソースが2つの有効日のいずれかを提供している場合は、Oracle Business Analytics Warehouseでラッパー・マッピングを使用して、不足している有効日をポピュレートするように設定できます。この状況については、この項で説明します。デフォルトでは、これらのラッパー・セッションは無効になっており、実行するために有効化する必要があります。
たとえば、前述のW_ORG_DテーブルではXYZが新しいセールステリトリーに移転しました。
ソース・システムが場所の変更に関する履歴データを提供している場合、テーブルには、WestセールステリトリーのXYZのレコードに、発効日2001年1月1日と失効日3714年1月1日が含まれているとします。その翌年、XYZがNorthセールステリトリーに移転したことがソースで示された場合には、表6-2のように、2番目のレコードが挿入され、そのレコードには、発効日2002年1月1日と失効日3714年1月1日が含まれます。
表6-2 W_CUSTOMERでのラッパー・セッション前のレコード
| 顧客名 | セールステリトリー | 顧客担当者 | 発効日 | 失効日 | 現在 |
|---|---|---|---|---|---|
|
ABC |
East |
Jane |
1/1/2001 |
1/1/3714 |
Y |
|
XYZ |
West |
John |
1/1/2001 |
1/1/3714 |
Y |
|
XYZ |
North |
John |
1/1/2002 |
1/1/3714 |
Y |
XYZの最初のレコードは、依然として有効期間が2001年1月1日から3714年1月1日までになっています。一方、XYZの2番目のレコードがNorthテリトリーに追加され、発効日が2002年1月1日に更新されています。この2番目のレコードでは、失効日は3714年1月1日のままです。
ラッパー・セッションを実行するようにスケジュールすると、XYZの最初の有効日が（2001年1月1日から2002年1月1日に）修正され、Analytic Data Interface（ロード・マッピング）で現在のフラグが調整されて、2番目のレコード（2002年1月1日から3714年1月1日)のみがYに設定されます。ラッパー・セッションの処理が終了した後は、表6-3のように、2つの別々のレコードではなく、XYZのタイプII情報がデータ・ウェアハウスに置かれます。
表6-3 W_CUSTOMERでのラッパー・セッション後のレコード
| 顧客名 | セールステリトリー | 顧客担当者 | 発効日 | 失効日 | 現在 |
|---|---|---|---|---|---|
|
ABC |
East |
Jane |
1/1/2001 |
1/1/3714 |
Y |
|
XYZ |
West |
John |
1/1/2001 |
1/1/2002 |
不要 |
|
XYZ |
North |
John |
1/1/2002 |
1/1/3714 |
Y |
前の段落では、ラッパー・セッションによって失効日と現在のフラグが修正されました。ただし、レコードの日付が正しかった場合、ラッパー・マッピングは必要に応じて現在のフラグを設定しただけです。これは、ラッパー・マッピングのロジックが日付とフラグをチェックし、不一致のあるカラムのみを調整するように設定されているためです。最後に、ソース・システムがタイプIIの情報を提供していない場合は、ラッパー・セッションを完全に無効にすることもできます。その場合は、タイプIIの処理はすべて、Analytics Data Interfaceマップレットによって実行されます。
参照変換により、参照テーブルを指定してから、コードの説明、為替レート、通貨コードなどの情報を取得できます。Oracle Business Analytics Warehouseには、事前に構成済の参照として次のタイプがあります。
次元キー参照。詳細は、第6.11項「次元キーの解決について」を参照してください。
一部のソース・システムでは、ハード・ディスクをHDと記述するなど、内容が直感的にわかるインテリジェント・コードが使用されます。また、それ以外のシステムでは、ハード・ディスクを16と記述するような、直感的ではないコード（番号や不明確な記述子など）が使用されます。コードは、情報を分析するために重要なツールですが、様々なコードやコード記述を使用すると、ソース・システム間で分析を実行するときに問題が生じます。ソース・システムのコードの不統一を解決しておかないと、Oracle Business Analytics Warehouseにデータを統合できません。
ロード・マッピングのコード参照では、インテリジェント・コードと直感的でないコードについて、コードを分けて抽出し、コード・テーブルにコードとその記述を挿入することで両方が統合されます。コード・テーブルでは、ロード・マッピングにリソースが提供されており、このリソースからコード記述への参照を自動的に実行できます。
Analytic Data Interfaceのアーキテクチャでは、要素テーブルおよび次元テーブルとともに、参照機能を支援するコンポーネントが使用されています。次のコンポーネントとプロセスが参照で使用されています。
ロード・コントロール・テーブルW_CODESは、後で参照できるようにすべてのコードを統合し、参照機能の効率化のために、それらのコードにカテゴリーと単一の言語を割り当てます。
Oracle Business Analytics Warehouseで使用されるマッピングは、ソース・システムからコードを抽出し、ロード・マッピングで使用できるように、W_CODESテーブルにポピュレートするように設計されています。
コード・マッピングの機能に関する知識を深めるには、最初にW_CODES内のカラムについて理解すると効果的です。表6-4は、それらのカラムについて説明しています。
表6-4 コード・マップレット内のカラム
| カラム | 説明 |
|---|---|
|
DATASOURCE_NUM_ID |
データの抽出元となるソース・システムの一意の識別子。 |
|
SOURCE_CODE1 |
様々なソース・システムのコード階層における最初のコード。特定のコードと記述の組合せを識別するために使用します。 |
|
SOURCE_CODE2 |
様々なソース・システムのコード階層における2番目のコード。特定のコードと記述の組合せを識別するために使用します。 |
|
SOURCE_CODE3 |
様々なソース・システムのコード階層における3番目のコード。特定のコードと記述の組合せを識別するために使用します。 |
|
SOURCE_DESC_1 |
ソース・システム・コードの簡単な説明。 |
|
SOURCE_DESC_2 |
コードの詳細な説明。 |
コード参照用に設計されたマッピングの命名規則は、SDE_[SOURCE]_CodeDimension_[CATEGORY]となります。次の図は、PowerCenter Mapping Designerでのコード・マッピングの例を示しています。
ソースに依存しないロード・マッピングに備えて、コード・マッピングをサポートするマップレットがいくつかあります。それらは次のとおりです。
Source Adapterマップレット: Source Adapterマップレットは、CODESのソース固有の入力属性、およびコントロール・テーブルまたはウェアハウス・テーブルの属性を、式変換に接続してマッピングします。Source Adapterコード・マップレットの命名規則は、MPLT_SA_CODESとなります。
Business Componentマップレット: Business Componentマップレットは、CODES_CUST_CLASSのソース・システムの属性を抽出マッピングで使用できるようにします。Business Componentコード・マップレットの命名規則は、MPLT_BC_CODES_[CATEGORY]となります。
ADIマップレット: Analytic Data Interface（ロード・マッピング）マップレットは、ソース・システムに依存しないで、ターゲット・テーブルのコードを解決します。ロード・マッピング・コード・マップレットの命名規則は、MPLT_ADI_CODESとなります。
ロード・マッピングでは、1つのソース・システムのインスタンスをマッピングのマスターに指定することで、複数のソース・システム・コードが統合されます。次に、他のすべてのソース・システム・コードがマスターにマッピングされます。ロード・マッピングは、定義を必要とするコードを検出すると、ロード・コントロール参照テーブルを参照して、ソース・システム・コードと、Oracle Business Analytics Warehouseのソースに依存しないコードを照合します。このソースに依存しないコードは、ソース・システム・コードの元の機能をすべて維持します。
ソース・システムのインスタンスをマスター・ソース・システムに指定するときに使用するカラムは、次のとおりです。
MASTER_ID: マスターとして指定されたソース・システムのコード。
DATASOURCE_NUM_ID: ソース・システムの一意の識別子。
次元と要素のロード・セッションを構成することで、特定の参照を実行できます。これには、W_CODESテーブルから抽出するデータのカテゴリーを編集し、コード情報をターゲット・テーブルにロードします。コードとコード名がW_CODESテーブルに存在しない場合には、それらをテーブルに追加する必要があります。参照を構成するには、セッション・オーバーライドを作成します。ロード・マッピング内のロード・マッピングは変更しないでください。
参照用にセッションを構成するには:
PowerCenter Workflow Managerで、適切なソース・システムの構成フォルダを開きます。
「Edit Tasks」ボックスを開きます。
「Transformations」タブで、参照用のSQL文を編集します。
たとえば、次の参照を編集できます。
MPLT_ADI_SUPPLIERS.LKP_SPLR_ATTR1
目的のコード・カテゴリーを使用するようにSQL文を編集します。
SQL文を編集して、GENERICを、参照に使用するカテゴリーに変更します。
デフォルトでは、次元キーの解決は、Oracle Business Analytics Warehouseのロード・マッピングで実行されます。ロード・マッピングは、事前にパッケージされた再利用可能な参照変換を使用して、事前にパッケージされた次元キーの解決を実現します。この項では、次元キーの参照方法および解決方法について説明します。
次元キーの解決には、一般に2種類の方法が使用されます。1つ目の方法は、最も使用される方法であり、次元キーへの参照を実行することです。2つ目の方法は、要素ロード・マッピングに直接次元キーを提供することです。
ロード・マッピングで、データベース結合によって次元キーを使用できない場合には、ロード・マッピングで次元テーブル内への参照を実行します。ロード・マッピングでは、事前にパッケージされた参照変換を使用してこの処理を実行します。
ロード・マッピングでは、統合ID、DATASOURCE_NUM_IDおよび参照日付を使用して次元キーを参照します。これらのカラムはすべて、ロード・マッピングで次元キーを返すために必要です。表6-5はこれらのポートについて説明しています。
表6-5 ロード・マッピングの次元キー参照で使用されるカラム
| ポート | 説明 |
|---|---|
|
INTEGRATION ID |
ソース・システム内で次元エンティティを一意に識別します。要素テーブルのSource Adapterにあるトランザクションで形成されます。 |
|
DATASOURCE_NUM_ID |
ソース・システムのインスタンスの一意の識別子。 |
|
参照日付 |
取引のプライマリ日付（受領日や販売日など）。 |
次の図では、サプライヤ製品キー参照の変換で、ロード・マッピング参照に必要な3つの入力カラムのINTEGRATION ID、DATASOURCE_NUM_IDおよびDate（参照日付）が示されています。次に、この変換で、サプライヤ製品キー（次元キー）がデータ・ウェアハウス・テーブルW_SUPPLIER_PRODUCT_Dに出力されます。
タイプIIの緩やかに変化する次元が有効な場合、ロード・マッピングでは、次元レコードの更新ごとに一意の有効日が使用されます。次元キーの参照時には、要素のプライマリ日付を使用して適切な次元キーが解決されます。
有効日の範囲は、次元レコードの有効期間を指定します。タイプIIの緩やかに変化する次元であるため、同じエンティティで、有効日の異なる複数のレコードを次元テーブル内に持つことができます。この有効日の範囲は、次元内のレコードを正確に識別するために使用し、履歴において正確な方法で情報を表現します。次の図に示されている従業員契約データの参照では、従業員契約の有効期間を提供するために有効日が使用されていることがわかります。
Oracle Business Analytics Warehouseの基盤は、異種のソース・システムのデータに対応するデータ・モデルで構成されています。データは、基幹業務システムから取得され、ソースに依存しないフォーマットに系統的に変えられます。データがソースに依存しないフォーマットになると、分析レポートの主要指標の作成に使用できるようになり、指標の計算がソースに依存することもありません。この明確な分離により、ソース・システムを入れ替えたり、新しいソース・システムを追加するときに、各ソース・システムの要件に対応するように指標の計算を再構成する必要はありません。
ソース・データをソースに依存しないフォーマットに変換する方法の1つに、ソースから提供される値をドメイン値に変換する方法があります。ドメイン値は、パッケージされた指標を計算するために使用される一連の明確な値です。これらの値はOracle Business Analytics Warehouseによって提供されているため、ソース・システムの値と関係なく指標計算ができます。
ドメイン値の変換プロセスを理解する最もよい方法は、2つのソース・システム（ソース・システムAとソース・システムB）の例について考えることです。それぞれのソース・システムには、雇用と再雇用という、2種類の従業員イベントが格納されています。ソース・システムAは、雇用イベントを表すためにHを、再雇用イベントを表すためにRを使用しています。これに対し、ソース・システムBは、雇用イベントを表すために1を、再雇用イベントを表すために2を使用しています。Oracle Business Analytics Warehouseは両方のシステムからデータを抽出すると、抽出マッピングを使用してそれらのソース値を転送し、TF_EVENT_TYPESステージング・テーブルのW_EVENT_GRP_CODEカラムまでデータが渡るようにします。
次に、ロード・マッピングによって、抽出されたソース値（ソース・システムAからのHとR、およびソース・システムBからの1と2）が、Source Adapterマップレットに転送されます。Source Adapter内で、実際の業務に特有の一連のルールに基づいて、ソース値がドメイン値（HIRおよびREH）に翻訳されます。
固有のソース値を所定のドメイン値セットにマッピングする方法をSource Adapterが認識できるように、ルールを定義する必要があります。ルールを設定する前に、次の手順に従う必要があります。
すべてのソース値を分析し、事前にパッケージされたドメイン値にマッピングする方法を確認します。特定のカラムに、追加のドメイン値の作成が必要になる場合もあります。この準備作業により、各ソース値のリストと、ドメイン値にマッピングする方法が得られます。
該当するSource Adapterマップレットにこのロジックを実装します。ロジックを設定するには、影響を受けるカラムごとに、Source Adapterマップレットの式変換を変更します。ドメイン値のルールを設定する方法の詳細は、第6.14項「PowerCenter Designerを使用したドメイン値セットの構成」を参照してください。
図6-14は、ソース値がドメイン値HIRおよびREHに変換される処理を示しています。
次の図は、それとは別の状況を示しています。ここでは、HireまたはRehireのフラグをレコードに付けるソース値が、レコードに含まれていない場合があるとしています。この場合は、ソース・システムでは雇用が1つのテーブルに格納され、再雇用が別のテーブルに格納されます。この状況に対応する1つの方法は、抽出マッピングを変更して、W_EVENT_GRP_CODEカラムにHIRまたはREHをポピュレートすることです。抽出マッピングでフィールドにポピュレートされた場合には、同じ値をSource Adapterマップレットで転送することもできます。
Source Adapterマップレットがソース固有の値をドメイン値に変換した後、そのドメイン値がOracle Business Analytics Warehouseのテーブルに挿入されます。この例では、次の図のように、HIRとREHの値がW_EVENT_TYPESテーブルにポピュレートされます。
W_EVENT_TYPESテーブルの値は、フロントエンドで指標を作成するために使用します。一部の指標は、ドメイン値を使用して定義します。たとえば、HIRおよびREHのイベント・グループ・コードを計算に使用する指標が7つあります。その7つの指標と説明および計算式を、次に示します。
この指標は、指定した期間内に雇用された人数をカウントします。計算式は次のとおりです。
SUM(CASE WHEN (CMMNEVTP.W_EVENT_GRP_CODE IN ('HIR','REH')) THEN EVNT.EVENT_CNT ELSE 0 END)
この指標は、指定した期間内に採用されたすべての従業員に対する再雇用率を算出します。計算式は次のとおりです。
CASE WHEN SUM(CASE WHEN CMMNEVTP.W_EVENT_GRP_CODE IN ('REH','HIR') THEN EVNT.EVENT_CNT ELSE 0 END) = 0 THEN 0 ELSE SUM(CASE WHEN CMMNEVTP.W_EVENT_GRP_CODE IN ('REH') THEN EVNT.EVENT_CNT ELSE 0 END)/SUM(CASE WHEN CMMNEVTP.W_EVENT_GRP_CODE IN ('REH','HIR') THEN EVNT.EVENT_CNT ELSE 0 END) END
この指標は、フルタイムの正社員として採用された人数をカウントします。計算式は次のとおりです。
SUM(CASE WHEN CMMNEMPT.FULL_TIME_FLAG = 'Y' AND CMMNEMPT.EMP_CAT_CODE = 'R' AND (CMMNEVTP.W_EVENT_GRP_CODE = 'HIR' OR CMMNEVTP.W_EVENT_GRP_CODE = 'REH') AND EVNT.EVENT_DK >= (CMMNDATE.DATE_KEY - 365) AND EVNT.EVENT_DK <= CMMNDATE.DATE_KEY THEN EVNT.EVENT_CNT ELSE 0 END)
この指標は、過去12か月間に採用された、このカテゴリーの退役軍人に該当するフルタイムの正社員とパートタイムの従業員をカウントします。計算式は次のとおりです。
SUM(CASE WHEN CMMNEMPD.VETERAN_STAT_CODE = '4' AND CMMNEMPT.EMP_CAT_CODE = 'R' AND (CMMNEVTP.W_EVENT_GRP_CODE = 'HIR' OR CMMNEVTP.W_EVENT_GRP_CODE = 'REH') AND EVNT.EVENT_DK >= (CMMNDATE.DATE_KEY - 365) AND EVNT.EVENT_DK <= CMMNDATE.DATE_KEY THEN EVNT.EVENT_CNT ELSE 0 END)
この指標は、このカテゴリーの退役軍人に該当するフルタイムの正社員とパートタイムの従業員をカウントします。計算式は次のとおりです。
SUM(CASE WHEN CMMNEMPD.VETERAN_STAT_CODE = '3' AND CMMNEMPT.EMP_CAT_CODE = 'R' AND (CMMNEVTP.W_EVENT_GRP_CODE = 'HIR' OR CMMNEVTP.W_EVENT_GRP_CODE = 'REH') AND EVNT.EVENT_DK >= (CMMNDATE.DATE_KEY - 365) AND EVNT.EVENT_DK <= CMMNDATE.DATE_KEY THEN EVNT.EVENT_CNT ELSE 0 END)
この指標は、過去12か月間に採用された、このカテゴリーの退役軍人に該当するフルタイムの正社員とパートタイムの従業員をカウントします。計算式は次のとおりです。
SUM(CASE WHEN CMMNEMPD.VETERAN_STAT_CODE = '1' AND CMMNEMPT.EMP_CAT_CODE = 'R' AND (CMMNEVTP.W_EVENT_GRP_CODE = 'HIR' OR CMMNEVTP.W_EVENT_GRP_CODE = 'REH') AND EVNT.EVENT_DK >= (CMMNDATE.DATE_KEY - 365) AND EVNT.EVENT_DK <= CMMNDATE.DATE_KEY THEN EVNT.EVENT_CNT ELSE 0 END)
この指標は、過去12か月間に採用された、このカテゴリーの退役軍人に該当するフルタイムの正社員とパートタイムの従業員をカウントします。計算式は次のとおりです。
SUM(CASE WHEN CMMNEMPD.VETERAN_STAT_CODE = '2' AND CMMNEMPT.EMP_CAT_CODE = 'R' AND (CMMNEVTP.W_EVENT_GRP_CODE = 'HIR' OR CMMNEVTP.W_EVENT_GRP_CODE = 'REH') AND EVNT.EVENT_DK >= (CMMNDATE.DATE_KEY - 365) AND EVNT.EVENT_DK <= CMMNDATE.DATE_KEY THEN EVNT.EVENT_CNT ELSE 0 END)
これらの指標計算はそれぞれ、ドメイン値HIRとREHに基づいています。ソース値がこれらのドメイン値のいずれかに変換されるレコードはすべて、次の図に示すように、指標の計算に組み込まれます。
Oracle Business Analytics Warehouseに組み込まれた拡張性を利用すると、既存のドメイン値の定義に適さないカラムに対して、追加のドメイン値を作成できます。ただし、特定のカラムに設定されたドメイン値を変更する前に、既存の指標に対する影響を分析しておいてください。たとえば、Oracle Business Analytics Warehouseには、次の2つのイベントが事前にパッケージされています。
新規雇用: このイベントは、新しい従業員が雇用されたときに発生します。
新規役職: このイベントは、ある役職が作成されたが、既存の従業員が内部で採用される可能性がある場合に発生します。
新規雇用と新規役職の両方を表すイベントがある場合、両方を意味する第3のイベントを作成することもできます。この新しいイベントタイプのドメイン値を作成する場合は、該当する指標の定義に含めて、すべての雇用と役職が計算に入れられるようにする必要があります。
ドメイン値は、パッケージされた指標を計算するために使用される一連の明確な値です。これらの値はOracle Business Analytics Warehouseによって提供されているため、ソース・システムの値と関係なく指標計算ができます。Oracle Business Analytics Warehouseには、ソース・システム値をドメイン値にマッピングするCSVワークシート・ファイルが用意されています。
追加のソース・システム値が必要な場合には、ワークシート・ファイルに追加して、その値をドメイン値にマッピングできます。また、ドメイン値をカスタマイズする必要がある場合には、ワークシート・ファイルを変更することもできます。事前に構成済の指標を変更する場合には、既存のドメイン値を使用できます。それ以外の場合には、新しいドメイン値を作成し、このドメイン値に基づいて新しい指標を作成できます。
CSVワークシート・ファイルでドメイン値にマッピングされていないソース・システム値には、Oracle Business Analytics Warehouseで、ドメイン値として疑問符（?）が付いています。この値は、ドメイン値の指標には影響しません。
ソース・システム値をドメイン値にマッピングするワークシート・ファイルがない場合には、PowerCenter Designerを使用してドメイン値を変更する必要があります。PowerCenter Designerを使用してドメイン値を構成する方法の詳細は、第6.14項「PowerCenter Designerを使用したドメイン値セットの構成」を参照してください。
使用しているアプリケーション用のCSVワークシート・ファイルおよびそのドメイン値の一覧については、使用しているアプリケーションの構成に関する章を参照してください。
CSVワークシート・ファイルを使用してソース値をドメイン値にマッピングするには:
ドメイン値を使用するOracle Business Analytics Warehouseテーブルのすべてのカラムを特定します。
ドメイン値を使用するカラムの一覧は、『Oracle Business Analytics Warehouse Naming Conventions and Domain Values』を参照してください。
ドメイン値のいずれかへの変換に適したソース値をすべて一覧表示します。
各ソース値をドメイン値にマッピングします。
ソース・システム値のいずれかが事前にパッケージされたドメイン値にマッピングされず、ドメイン値のリストを変更する場合には、新しいドメイン値のリストを作成し、孤立したソース・システム値を新たに作成したドメイン値にマッピングします。
ドメイン値セットのなかには、変更できないものもあります。また、ドメイン値セットの変更によって影響を受ける指標を確認する必要があります。詳細は、『Oracle Business Analytics Warehouse Naming Conventions and Domain Values』を参照してください。
...\Informatica\SrcFilesフォルダにあるCSVワークシート・ファイルを開きます。
ソース値を既存のドメイン値にマッピングするファイルを編集します。
または、ドメイン値を追加する場合には、このワークシート・ファイルに追加します。
ワークシート・ファイルを保存して閉じます。
ソース・システム値をドメイン値にマッピングするワークシート・ファイルがない場合には、PowerCenter Designerを使用して値を変更する必要があります。CSVワークシート・ファイルでドメイン値セットを構成する方法の詳細は、第6.13項「CSVワークシート・ファイルによるドメイン値セットの構成」を参照してください。
PowerCenter Designerを使用して、特定のカラムに対してドメイン値セットを構成する場合は、次のいずれかまたは両方の操作を行う必要があります。
ドメイン値へのソース固有の値のマッピング
事前にパッケージされた値セットへのドメイン値の追加
どちらの操作を選ぶかに関係なく、該当するSource Adapterマップレットの式変換では構成が必要になります。次に示す手順では、ドメイン値を変更するための式変換の構成方法について説明します。
PowerCenter Designerを使用してソース値をドメイン値にマッピングするには:
ドメイン値を使用するOracle Business Analytics Warehouseテーブルのすべてのカラムを特定します。
ドメイン値を使用するカラムの一覧は、『Oracle Business Analytics Warehouse Naming Conventions and Domain Values』を参照してください。
ドメイン値のいずれかへの変換に適したソース値をすべて一覧表示します。
各ソース値をドメイン値にマッピングします。
ソース・システム値のいずれかが事前にパッケージされたドメイン値にマッピングされず、ドメイン値のリストを変更する場合には、新しいドメイン値のリストを作成し、孤立したソー ス・システム値を新たに作成したドメイン値にマッピングします。
ドメイン値セットのなかには 、変更できないものもあります。またドメイン値セットの変更によって影響を受ける指標を確認する必要があります。詳細は、『Oracle Business Analytics Warehouse Naming Conventions and Domain Values』を参照してください。
PowerCenter Designerで、該当するSource Adapterマップレットを開きます。
式変換を開きます。
変更可能な該当するポートの式を見つけます。
ソース値を既存のドメイン値にマッピングするポートの式を編集します。
または、ドメイン値を追加する場合には、この同じ式に追加します。
変更内容を確認してリポジトリに保存します。
この項では、複数のアプリケーションに該当するオブジェクトの構成手順について説明します。この項の内容は次のとおりです。
この項では、汎用ビジネス・アダプタを使用してロードされる次元の変更手順について説明します。
Oracle Business Analytics Warehouseでは、製品の発効日（SRC_EFF_TO_DT）および失効日（SRC_EFF_FROM_DT）が、Products次元テーブルW_PRODUCTSに格納されています。さらに、Products次元には、サポート終了日カラムSPRT_WITHDRAWN_DTが格納されています。
デフォルトでは、サポート終了日が、製品の失効日よりも優先されます。この優先順位によって、フラット・ファイル・アップロードのサポート終了日カラムに値を指定した場合、Oracle Business Analytics Warehouseではその値が製品の失効日の値としても使用され、SRC_EFF_TO_DTカラムのすべての値が上書きされます。このデフォルト動作は、汎用ソースのProducts抽出マッピングでProducts Expressionを変更することで変更できます。
フラット・ファイル抽出に対する製品の失効日のロジックを変更するには:
