| Oracle® Business Intelligence Applications Informatica PowerCenterユーザーのための構成ガイド リリース7.9.6.3 B66691-01 |
|
 前 |
 次 |
| Oracle® Business Intelligence Applications Informatica PowerCenterユーザーのための構成ガイド リリース7.9.6.3 B66691-01 |
|
前 |
次 |
この項では、Oracle Business Analytics Warehouseのカスタマイズの概要と手法について説明します。
|
注意: カスタマイズを実装する前に、Informatica PowerCenterに習熟しておいてください。 |
この章の内容は次のとおりです。
この項では、Oracle Business Intelligence Applicationsのカスタマイズの概要について説明します。この項の内容は次のとおりです。
Oracle Business Intelligence Applicationsでは、カスタマイズは、新しい情報をビジネス・インテリジェンス・ダッシュボードで分析できるようにするためのデフォルトの動作の変更として定義されます。たとえば、データをフィールドHZ_CUST_ACCOUNTS.ATTRIBUTE1から抽出し、Oracle Business Analytics WarehouseのX_ACCOUNT_LOGフィールドに格納することによって、カラムをダッシュボードに追加する必要がある場合があります。
テーブルおよび命名規則の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
この章では、ビジネス分析とテクニカル分析を実行した後に、ETL機能をカスタマイズする方法について説明します。この章では、次に示す実行する必要があるタスク以外の通常のタスクについては説明しません。
ビジネス分析: カスタマイズを開始する前に、通常、現在のBIダッシュボードを分析し、ビジネスまたは組織をサポートするために必要な変更を判別します。
テクニカル分析: ビジネス要件に同意したら、変更する必要があるソース・テーブル、ステージング・テーブル、ターゲット・テーブルおよびInformatica変換を特定して、実行する必要があるテクニカル変更を判別する必要があります。
RPD変更: ETL機能のカスタマイズを実行したら、RPDを変更して、新しいデータをダッシュボードに公開する必要があります。RPDの変更の詳細は、Oracle Business Intelligence Enterprise Editionのドキュメント・ライブラリを参照してください。
Oracle Business Analytics Warehouseのカスタマイズには、データソースのタイプに応じていくつかのシナリオがあります。
パッケージ・アプリケーションは(Siebel CRMやOracle EBSなど)、事前にパッケージ済のアダプタを使用します。
パッケージされていないデータソースは汎用アダプタを使用します。
図17-1は、サポートされているカスタマイズ・シナリオのカテゴリを、データソースに基づいて示しています。
テーブルおよび命名規則の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
図17-1は、カスタマイズの次のカテゴリーを示しています。
カテゴリー1。カテゴリー1のカスタマイズでは、事前にパッケージされているアダプタを持つソース・システムからカラムを追加し、データを既存のデータ・ウェアハウス・テーブルにロードします。
カテゴリー2。カテゴリー2のカスタマイズでは、事前にパッケージされているアダプタを使用して、新しい要素テーブルまたは次元テーブルをデータ・ウェアハウスに追加します。カテゴリー2のカスタマイズでは、通常、新しいSDEマッピングおよびSILマッピングを構築する必要があります。
カテゴリー3。カテゴリー3のカスタマイズでは、汎用アダプタを使用して、事前にパッケージされているアダプタがないソースからデータをロードします。
アップグレード時にカスタマイズを処理することは、カスタマイズの作業の中でも難しい事項の1つです。Informaticaには、顧客が加えた変更を自動的に検出して、アップグレードされたマッピングに追加する差分マージ機能がありません。したがって、カスタマイズした内容は、アップグレードされたマッピングに手動で再適用する必要があります。Oracle BI Applicationsは、アップグレード後にカスタマイズ内容を再適用する作業ができるだけ少なくなるように処理します。このカスタマイズ方法論に従えば、アップグレード時の作業が最小で済み、多くの場合、手動作業が不要になります。
この項は、次の項を含んでいます。
カテゴリー1のカスタマイズでは、事前にパッケージされているアダプタを含むソース・システム(Oracle JD Edwards EnterpriseOne、Oracleなど)から追加のカラムを抽出し、データを既存のデータ・ウェアハウス・テーブルにロードします。カテゴリー1のカスタマイズでは、パッケージされていないソースからデータが抽出される場合もありますが、この項では、ソースが汎用アダプタによってすでにマップされており、拡張して追加のカラムを取得する必要があるのみであることを前提にしています。(汎用アダプタの初期マッピングは、カテゴリー3のカスタマイズで検討します。詳細は、第17.6項「カテゴリー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では拡張が次のカテゴリーに分けられています。
公開オブジェクト。これらのオブジェクトは変更できますが、変更は拡張(追加)の形式である必要があり、既存の構成済ロジックは変更できません。これらのオブジェクトは、出荷時のマッピングに含まれており、通常、ソース、ターゲットおよび再使用できない変換です。
カプセル化されたオブジェクト。これらのオブジェクトは拡張できません。これらのオブジェクトは、できるかぎり多くの出荷済の変換ロジックを非表示にして、構成済ロジックの破損を防止しようとします。これらのオブジェクトは、出荷時のマッピングに含まれており、通常、マップレットおよび再使用できない変換です。
カスタム・オブジェクト。カスタム・オブジェクトをマッピングに追加します。(Oracleではこれらを出荷しません。)カスタム・オブジェクトは、ソース、変換(再使用可能および再使用不可能)またはマップレットです。出荷される再使用可能な変換およびマップレットは、カプセル化されたオブジェクトとみなされますが、これらのオブジェクトを既存のマッピングに追加すると、これらはそのマッピングに対するカスタム・オブジェクトとみなされます。たとえば、別の金額を要素テーブルに追加し、その金額を元の通貨からデータ・ウェアハウスの通貨に変換する必要がある場合、通常、既存の通貨変換マップレットをマッピングに追加して、この新しい金額を変換します。この場合、このマップレットは、このマッピングに対するカスタム・オブジェクトとみなされますが、カプセル化されているため、内部ロジックを変更しないでください。
|
注意: ターゲットはマッピングに追加できません。 |
アップグレード時には、カスタマイズしたマッピングを個別に配置します。既存の環境に適用されるのは、実際に変更されているマッピングのみです。つまり、変更されていないマッピングは影響を受けず、これらのマッピングに加えられたカスタマイズは維持されます。実際に変更されたマッピングのみに、カスタマイズを再適用するための作業が必要になります。お薦めするアプローチに従えば、カスタマイズの再適用に必要な作業は最小限に抑えられます。
できるだけ多くのロジックをカプセル化することにより、パッチ・リリースやアップグレードの際に、事前に構成済のロジックに加えられる変更は、拡張ロジックに影響することなく置換できるようになっています。次の図を参照してください。
公開オブジェクトに変更がある場合は、拡張ロジックよりも新しいロジックが常に優先されます。ただし、すべての拡張が破棄されるのではなく、大部分の拡張ロジックは残され、必要なのは公開オブジェクトへの再適用のみです。たとえば、ソースからのカラムを追加し、ターゲットにロードしている場合、アップグレード時には、アップグレードされたマッピングによって、追加のカラムがソースから取得され、ターゲットにロードされます。
ソースとターゲットは完全に置換されるため、これらへの拡張は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句のカラムで別名を参照する必要があります。第17.3.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は、このマッピングですでに結合されています。ソース定義からソース修飾子にATTRIB_04カラムをドラッグします。このカラムは、X_CUSTOMカラムの後に表示されます。
S_CONTACTは、最終更新者に結合されていないため、S_CONTACTのコピーをマッピングにドラッグします。(ソース修飾子が存在する場合、このソースと関連付けられた新しいソース修飾子を削除します。)
ソースの名前は、表現しているものを示すように変更することをお薦めします。この場合は、ソースの名前をS_CONTACT_LAST_UPDATE_BYに変更します。
ソース定義からソース修飾子にLOGINカラムをドラッグします。
EXP_Custom式に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 }
変更を保存します。
Informatica PowerCenter Workflow Managerで、セッションを更新および検証します。
これは、マッピングに加えた変更がセッションを無効にする場合があるため必要になります。
既存のSDEマッピングに以前含まれていなかった新しいテーブルからデータをロードしている場合、補助チェンジ・キャプチャ・マッピングを作成し、新しいテーブルで行が変更されたときに、主テーブルの対応する行が変更としてマークされるようにする必要があります。補助プロセスを作成しないと、新しいテーブルの新しいカラムが変更されてもベース・テーブルが変更されない場合、このイベントが取得されなくなる可能性があります。補助プロセスは、ETLのパフォーマンスに悪影響を及ぼす可能性があることに注意してください。したがって、関連テーブルで変更があった場合に主レコードに変更のフラグを立てる必要がない場合、このマッピングを作成する必要はありません。
この例では、会社はOracle Applicationsリリース11.5.8を使用しており、HZ_CUST_ACCOUNTS.ATTRIBUTE1フィールドを使用して、ACCOUNT_LOGに関連するデータを取り込んでいます。レコードを最後に更新した人の名前は、HZ_CUST_ACCOUNTS.LAST_UPDATE_LOGINフィールドにすでに格納されています。他のテーブルに結合する必要はありません。
Oracleデータベースで実行されるOracle Applicationsの場合、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マップレットの新しいカラムをこの式に接続します。
これらのポートの名前は、取得元のテーブルおよびカラムを示すように変更することをお薦めします。マッピングを変更し、関連する公開オブジェクトを置換する場合は、カスタム式は置換されないため、前述のように処理すると再接続しやすくなります。
ターゲット定義の対応するカラムに、これらのカラムを接続します。
変更を保存します。
Informatica PowerCenter 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に変更します。
ソース修飾子の新しいカラムをこの式に接続します。
ターゲット定義の対応するカラムに、これらのカラムを接続します。
変更を保存します。
Informatica PowerCenter 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カラムをドラッグします。
通常、既存の変換は変更しないでください。フィルタは有効な変換であるため、有効な変換を迂回してデータをルーティングし、同じデータ・フローに戻すことはできません。この場合、フィルタは公開オブジェクトとみなされ変更できますが、変更はアップグレード時に失われる危険性があります。
フィルタから式EXP_CustomにX_ACCOUNT_LOGカラムおよびX_LAST_LOGINカラムをドラッグします。変換を適用する必要がある場合は、この式で適用してください。
式から更新戦略にX_ACCOUNT_LOGカラムおよびX_LAST_LOGINカラムをドラッグします。
更新戦略は別の有効な変換であるため、フィルターと同様に公開オブジェクトとみなされます。
ターゲット定義の対応するカラムに、これらのカラムを接続します。
変更を保存します。
Informatica PowerCenter Workflow Managerで、セッションを更新および検証します。
これは、マッピングに加えた変更がセッションを無効にする場合があるため必要になります。
マッピングに対してこれらの変更を行った後、DACで変更を登録する必要があります。テーブル定義(追加のカラムまたは索引を含む)および必須の変更を含め、タスクが新しいカスタム・フォルダで変更されたセッションを実行するようにする必要があります。DACへのデータ・ウェアハウス・オブジェクトの登録の詳細は、Oracle Business Intelligenceデータ・ウェアハウス管理コンソール・ユーザーズ・ガイドを参照してください。
この項は、次の項を含んでいます。
カテゴリー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_BusinessLocationDimensionマッピングは、次のカラムを比較します。
BUSN_LOC_NAME CITY_NAME POSTAL_CODE
カテゴリー2のロジックにCOUNTYを含める場合、次のTYPE2_COLS_DIFFの式を変更します。
IIF(VAR_BUSN_LOC_NAME != VAR_LKP_BUSN_LOC_NAME, 'Y', IIF(VAR_CITY_NAME != VAR_LKP_CITY_NAME, 'Y', IIF(VAR_POSTAL_CODE != VAR_LKP_POSTAL_CODE, 'Y', 'N')))
これを次のように変更します。
IIF(VAR_BUSN_LOC_NAME != VAR_LKP_BUSN_LOC_NAME, 'Y', IIF(VAR_CITY_NAME != VAR_LKP_CITY_NAME, 'Y', IIF(VAR_POSTAL_CODE != VAR_LKP_POSTAL_CODE, 'Y', IIF(VAR_COUNTY != VAR_LKP_COUNTY, 'Y', 'N'))))
前述のとおり、参照変換を変更し、COUNTYカラムを渡してLKP_COUNTYに格納し、これをNULL評価して変数VAR_LKP_COUNTYに格納する必要があります。また、ステージ・テーブルから取得したCOUNTYカラムもNULL評価し、VAR_COUNTYという別の変数カラムに格納する必要があります。
ここで、COUNTYがカテゴリー2のロジックの一部になったため、このカラムを、まだカテゴリー1のカラムであるとみなされている他のすべてのマッピングから削除する必要があります。この想定をする他の唯一のマッピングは、SIL_BusinessLocationDimension_SCDUpdateです。このマッピングは、ソース・テーブル、ソース修飾子変換、式変換、フィルタ変換およびターゲット・テーブルから構成されます。
新しく追加されたカラムCOUNTYをSIL_BusinessLocationDimension_SCDUpdateでカテゴリー2のカラムとして処理するには、次の必須の変更を行います。
ソース修飾子変換の変更
COUNTYポートを削除します。
SQLオーバーライドで、項目「TARGET_TABLE.COUNTY」をSELECT句から削除します。
式変換の変更
入力専用ポートCOUNTYを削除します。
対応する変数ポートCOUNTY_VARを削除します。
対応する出力専用ポートCOUNTY_OUTを削除します。
フィルタ変換の変更
ポートCOUNTY_OUTを削除します。
|
注意: 前の例は、新しいカラムをカテゴリー2セットに追加する状況を説明しています。カラムをカテゴリー2セットから削除する状況では、逆の手順を実行します。たとえば、CITY_NAMEをカテゴリー2のカラムから削除すると仮定します。
|
この項では、次元(既存またはカスタム)の既存の要素への追加について説明します。この次元をポピュレートするために必要なプロセスを構築済であることが前提です。
このプロセスでは、要素ステージング・テーブルと要素データ・ウェアハウス・テーブルの両方を拡張して新しいカラムに含めます。Informaticaでは、Oracleデータベースタイプを使用してテーブルを定義することに注意してください。ステージング・テーブルは、varchar2(80)フィールドとして定義し、名前には_IDサフィックスを付ける必要があります。データ・ウェアハウス・テーブルのカラムは整数として定義し、名前には_WIDサフィックスを付ける必要があります。
SDE要素マッピングは、次元キーの一意の識別子を渡すように変更する必要があります。これは、ベース・テーブルとこの一意の識別子の間に関係があることを前提にしています。これは、ベース・テーブルにすでに格納されているか、または関連テーブルと結合して格納されます。ソース・システムに応じて、この識別子は、1つのカラムに基づくかまたは複数のカラムから導出されます。表17-1は、次元キーを識別するために使用されるINTEGRATION_IDを導出するために使用する様々なフォーマットを示しています。INTEGRATION_ID値は、要素ステージング・テーブルに渡す必要があります。
表17-1 INTEGRATION_IDを導出するフォーマット
| 次元 | 外部キー | ソースがOracleアプリケーションの場合 | ソースがSiebelアプリケーションの場合 | ソースがOracleのJD Edwards EnterpriseOneまたはJD Edwards Worldアプリケーションの場合 |
|---|---|---|---|---|
|
W_AP_TERMS_D |
- |
TO_CHAR(TERM_ID) |
該当なし |
PNPTC |
|
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 |
該当なし |
AN8 ||'~'|| CO |
|
W_CUSTOMER_LOC_D |
- |
顧客の場所のキーを取得するには、次のW_CUSTOMER_LOC_USE_Dを参照します。 |
該当なし |
AIAN8||'~'|| AICO |
|
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) |
該当なし |
AID||'~'|| SBL||'~'|| SBLT |
|
W_INT_ORG_D |
COMPANY_ORG_KEY |
COMPANY'||'~'||TO_CHAR(SET_OF_BOOKS_ID) |
S_ORG_EXT.ROW_ID |
CO |
|
W_INT_ORG_D |
*_ORG_KEY |
プレフィックスを削除して、TO_CHAR()を使用します。 |
S_ORG_EXT.ROW_ID |
MCU |
|
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_PERSON(S_ORG_EXTではない)のROW_IDです。これは、W_ORG_Dのコンタクト顧客を参照してACCOUNT_WID(CUSTOMER_WIDとして読み込まれる)を解決するために渡される新しい値です。 |
該当なし |
|
W_PAYMENT_METHOD_D |
- |
LOOKUP_CODE |
該当なし |
SY||'~'|| RT||'~'|| KY |
|
W_PAYMENT_METHOD_D |
- |
TO_CHAR(TERM_ID) |
該当なし |
SY||'~'|| RT||'~'|| KY |
|
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 |
ITM |
|
W_SALES_PRODUCT_D |
- |
TO_CHAR(INVENTORY_ITEM_ID) ||'~'||TO_CHAR(ORGANIZATION_ID) |
該当なし |
該当なし |
既存の次元を追加している場合、SILマッピングを拡張し、既存の再使用可能な参照変換をその次元に含める必要があります。次元のINTEGRATION_IDをX_CUSTOMによって識別されたパスに沿ってマッピングに渡し、フィルタ変換後にこれを参照に接続します。また、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式に接続します。適切な為替レートを使用して、金額をデータ・ウェアハウスの通貨に変換します。変換された通貨を更新戦略に渡してからターゲットに渡します。
この項は、次の項を含んでいます。
第17.5.4項「Oracle Business Analytics Warehouseのカスタマイズに関する重要な注意事項」
第17.5.8項「Oracle Business Analytics Warehouseでの新しい要素テーブルに対する新しい次元テーブルの追加」
この項では、ソース・テーブルから、抽出済ではないデータがロードされる、完全に新しいテーブルの作成について説明します。たとえば、新しいProject次元テーブルの作成が必要になる場合があります。この場合は、新しい次元テーブルとステージング・テーブルおよび新しい抽出を作成して、ETLマッピングをロードします。
新しいカスタム・テーブルを作成する場合、接頭辞WC_を使用して、オラクル社が提供するテーブルとカスタム・テーブルを区別し、オラクル社が今後同様の名前のテーブルをリリースした場合の命名競合を回避します。たとえば、プロジェクト次元に対して、WC_PROJECT_DSテーブルおよびWC_PROJECT_Dテーブルを作成できます。
新しい次元テーブルまたは要素テーブルを作成するときには、それぞれのデータ・ウェアハウス・テーブルに含まれる必須のシステム・カラムを使用して、整合性と、既存のテーブル構造への参照可能性を維持します。新しいテーブルを作成するときには、テーブルとインデックスをDACで登録する必要があります。DACでは、Informaticaの新しいワークフローに対する新しいタスクを登録してから、対応するサブジェクトエリアを再アセンブルし、対応する実行プランを再構築することも必要になります。サブジェクトエリアの構築および実行プランの構築の詳細は、Oracle Business Intelligenceデータ・ウェアハウス管理コンソール・ガイドを参照してください。
|
注意: 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」画面のプロセスIDでもあります。
Oracle Business Analytics Warehouseのスキーマのすべてのテーブルには、一意のユーザー・キーの一部としてDATASRC_NUM_IDが含まれています。通常、トランザクション・アプリケーションでは主キーが一意に維持されますが、複数のトランザクション・システム間で主キーが重複することは可能です。このデータをデータ・ウェアハウスにロードするときに問題が発生しないようにするために、ユーザー・キーの一部としてDATASOURCE_NUM_IDを含めると、一意性を維持できます。つまり、各データソースでこのカラムに異なる値が与えられている場合、それらの異なるソースの行を同じデータ・ウェアハウス・テーブルにロードできます。
|
注意: DATASRC_NUM_IDは、DACによって維持されます。各ソース・システムに一意の値が割り当てられるようにしてください。同じソース・システムの複数のインスタンスが存在する可能性があります(たとえば、同じデータ・ウェアハウスにロードされた米国ベースのSiebelトランザクション・データベースと欧州ベースのSiebelトランザクション・データベース)。2つの異なるトランザクション・データベース・システムには、DACで異なるDATASOURCE_NUM_ID値を割り当てる必要があります。DACは、Siebelに対して1つのエントリを持つように事前定義されており、DATASOURCE_NUM_IDには値1が割り当てられています。追加のSiebelトランザクション・データベース・システムから抽出し、データを同じデータ・ウェアハウスにロードする場合、異なるDATASOURCE_NUM_IDをそれぞれのSiebelトランザクション・データベース・システムに割り当てる必要があります。 |
Oracle Business Analytics Warehouseを変更する場合は、カスタム・フォルダを作成して、そのフォルダ内で変更する必要があります。同梱されているフォルダ内のオブジェクトは、オラクル社からの明確な指示がないかぎり変更しないでください。同梱されているフォルダとその中のオブジェクトは、将来のアップグレードで上書きされる場合があります。
配置済リポジトリには、カスタム・フォルダが含まれていないため、独自のフォルダを作成する必要があります。カスタマイズ用に配置したSDEフォルダごとにカスタム・フォルダを作成する必要があります。このフォルダには、各種のソースに対する抽出マッピングを格納します。また、SILOSフォルダをカスタマイズするには、別のカスタム・フォルダを作成する必要があります。カスタマイズした抽出マッピングとロード・マッピングは、同じフォルダに格納しないでください。
オブジェクトを変更する最も簡単な方法は、同梱のフォルダに入っている既存のオブジェクトを対応するカスタム・フォルダにコピーし、既存のビジネス・コンポーネント、ソースおよびターゲットの定義、変換、マップレット、およびマッピングを再利用することです。
|
注意: ソース・テーブルを拡張する場合、ソース・テーブルをInformatica PowerCenter 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 PowerCenter Designerの「Config Object」タブの「Error Handling」エリアにあります。
Informatica PowerCenter Designerで、適切なソースおよびターゲットの接続値を設定します。
ワークフローを完全ロード・コマンドに使用する場合は、バルク・モードでのロードを選択できます(OracleデータベースおよびDB2-UDBデータベースにのみ該当)。DACでワークフローを完全ロード・コマンドに使用する場合は、Informatica PowerCenter Designerの「Properties」タブで「Target Load」タイプを「Bulk」に設定します。この場合、ロード時にターゲット・テーブルにインデックスが含まれていない必要があります。DACがインデックスを自動的に削除するため、ユーザー側ではアクション不要です。
次元テーブルや要素テーブルなどのすべてのエンティティに対して、完全ロード用と増分ロード用の2つのワーフクローを作成します。両方のワークフローは、同じマッピングに基づいています。同じマッピングは、完全ロードと増分ロードの両方の実行中に実行されます。このことによって、これらのロード・シナリオのそれぞれを調整する機会が与えられます。
ワークフローが、完全モードで次元をロードするように設計されている場合は、指定されていない行の作成セッションもワークフローに含まれていることを確認してください。
DACでタスクを定義するときには、適切な切捨てオプションを選択する必要があります。これにより、テーブルのインデックスを削除および作成するかどうかをDACが決定できるようになります。
Informaticaの「truncate target」オプションを使用して、ターゲット・テーブルを切り捨てないでください。複数のソース・システムから抽出し、同じデータ・ウェアハウスにロードする場合に、DACがテーブルの切捨てを処理することが特に重要です。DACは、テーブルを切り捨てる必要があるときを動的に判定します。Informaticaワークフローで切捨てオプションを設定することによって、テーブルは常に切り捨てられ、複数のソースからデータを抽出してロードする機能が制限されます。たとえば、2つのシステムからデータを抽出し、並行して同じステージング・テーブルにロードできません。これは、Informaticaセッションが、別のセッション実行中にステージング・テーブルを切り捨てるためです。
一部のセッションを順番に実行する必要があり、かつワークフローの失敗時にすべてのセッションを再実行する必要がある場合は、セッションを順番に実行する単一のワークフローの設計を検討してください。失敗時にすべてのセッションを再実行する必要がない場合は、別々のワークフローの設計について検討し、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の実行履歴への参照キーです。同じ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で指定された単一のベース通貨コードに変換することによって維持されます。)
日付次元:W_DAY_Dに関連するデータには、再利用可能な変換EXP_DAY_DIMENSION_FK_RESOLUTIONを使用します。この変換は、入力値として日付を使用し、適切なフォーマット(YYYYMMDD)の外部キーを出力値として日付次元に返します。これにより、解決のたびに、W_DAY_D次元への余分なコストのかかる結合や参照を行う必要がなくなります。再使用可能変換をコピーして使用します。
値リスト: これは、特にカテゴリー1と2に適用されます。値リストに依存する事前構成カラムには、言語に依存するカラムと言語に依存しないカラムがあります。マップレット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」を選択して、チェンジ・キャプチャ・テーブルを作成します。手順については、第17.5.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データ・モデル・リファレンスを参照してください。システム以外のカラムでは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ワークフローに依存する必要はなく、失敗時の修復に「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マップレットに新しいソース・テーブルを追加するには:
Informatica 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マップレットは、ソース固有のデータ要素を標準フォーマットに変換し、ステージング・テーブルに格納します。次に、ソースに依存しないロード・マッピングは、すでに標準フォーマットに変換されているこれらのレコードを取得します。
図17-6は、Source Adapterマップレットのうち、データ変換を実現する3つのコンポーネントを示しています。その3つのコンポーネントとは、マップレット入力(MAPI)、式変換(EXP)、およびマップレット出力(MAPO)です。
図17-6では、入力データが変換された場合、そのデータが入力のみとして式変換(EXP)に渡されます。データが変換されると、EXT_というプレフィックスが付けられて、新しいポートを通じて出力されます。データが変換されない場合は、入力専用として入り、出力専用ポートを通じて出ていきます。
新しい変換を追加する場合には、新しいポートを追加して、データの変換に使用する式を含めます。
Source Adapterマップレットに新しいポートを追加するには:
Informatica 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サフィックスでマークされたステージング・テーブルにロードします。
図17-7は、抽出プロセスの開始例を示しています。これは、2日間のイベントのシーケンスを示しています。この期間に、ソース・テーブルの情報が変更されます。1日目、データは、ソース・テーブルから抽出され、Oracle Business Analytics Warehouseテーブルにロードされます。2日目、販売オーダー番号3が削除され、新しい販売オーダーが受信され、2つのテーブル間の販売オーダー情報の不一致が形成されます。
図17-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から物理的に削除されます(図17-8を参照)。抽出マッピングおよびロード・マッピングを実行すると、ウェアハウスに新しい販売注文が追加されます。
プライマリ抽出マッピング(*_Primary)および削除マッピング(*_IdentifyDeleteおよび*_Softdelete)は、ソース・システムから物理的に削除されたレコードを識別する際に重要な役割を果たします。ただし、プライマリ抽出マッピングおよび削除マッピングを無効または削除できる場合があります。たとえば、ソース・システムのデータベースから削除され、別のデータベースにアーカイブされたレコードをデータ・ウェアハウスに保持する場合です。
削除マッピングでは、ソースIDとキーIDを使用して、削除されたデータが識別されるため、複数のソース・システムを使用している場合には、SQLクエリー文を変更して、削除マッピングで適切なソースIDが使用されていることを確認する必要があります。プライマリ抽出マッピングおよび削除マッピングに加えて、ロード・マッピングの削除フラグの構成でも、レコードの削除の処理方法を決定できます。
データの抽出と削除は、次の方法で管理できます。
ソースがアーカイブしたレコードの構成の削除
特定のソースからのレコードの削除
削除セッションおよびプライマリ抽出セッションの有効化
レコード削除フラグの構成
レコード却下フラグの構成
ここでは、これらの管理タスクの手順について説明します。
一部のソースは、レコードを別のデータベースにアーカイブして、メイン・データベースの現在の情報のみを保持します。削除マッピングを有効にしている場合は、Oracle Business Analytics Warehouseの削除マッピングを再構成して、アーカイブされたデータを維持する必要があります。
ソースがアーカイブしたレコードをOracle Business Analytics Warehouseで保持するには、$$LAST_ARCHIVE_DATEパラメータの値を、アーカイブの日付を反映するように設定してください。削除マッピングは、アーカイブされたレコードに削除済というマークを付けません。抽出マッピングおよび削除マッピングの詳細は、第17.8.3項「プライマリ抽出マッピングおよび削除マッピングを使った作業について」を参照してください。
ソースが削除したレコードをOracle Business Analytics Warehouseで削除済というマークを付ける場合には、アプリケーションの削除タスクおよびプライマリ抽出タスクを有効にする必要があります。
次の手順に示すように、セッションを有効にする方法は、実装したモジュールに応じて、2つの異なる方法があります。
タスクでプライマリ抽出セッションおよび削除セッションを有効にするには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示します。
「Delete」と「Primary」いずれかの文字列を含むすべてのタスクにクエリーを実行します。
これらのタスクの「Inactive」チェック・ボックスの選択を解除します。
サブジェクトエリアを再アセンブルし、実行プランを再構築します。
構成タグでプライマリ抽出セッションおよび削除セッションを有効にするには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Configuration Tags」タブを表示します。
「Identify and Soft Delete」の文字列を含むすべての構成タグにクエリーを実行します。
モジュールのタグを選択し、サブタブ「Subject Areas」をクリックします。
これらのサブジェクトエリアの「Inactive」チェック・ボックスの選択を解除します。
サブジェクトエリアを再アセンブルし、実行プランを再構築します。
Oracle Business Analytics Warehouseには、カテゴリー2の緩やかに変化する次元(SCD)機能が用意されており、これによって、次元レコードの更新履歴を追跡できます。Oracle Business Analytics Warehouseのレコードに更新がある場合、更新情報が新しい行に入力され、古い情報は履歴レポートの目的で残されます。
Oracle Business Analytics Warehouseは、データが抽出され、ソースに依存しないように変換された後に、ユーザーが選択した緩やかに変化する次元のロジックを識別および適用します。ユーザーは、カテゴリー1のSCD(更新によってデータが上書きされる)とカテゴリー2のSCD(元のレコードは維持され新しいレコードには更新データが格納される)の両方をサポートするようにOracle BI Applicationsを構成できます。カテゴリー1とカテゴリー2どちらのSCDを選択するかは、履歴上重要な属性の特定によって異なります。
デフォルトでは、ほとんどの次元でカテゴリー1の更新が使用されます。次元をカテゴリー2のSCD更新に変更する必要がある場合、次の手順を実行します。
カテゴリー2のSCD更新への次元変更を有効にするには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示します。
次元をポピュレートするSILタスクに対するクエリーを実行します。
「Parameters」サブタブを表示し、$$TYPE2_FLGの値をYに設定します。
標準リポジトリにおいて、少数の次元は、デフォルトでカテゴリー2のSCDに設定されています。これらの次元は、表17-2にリストされています。
図17-2 デフォルトでカテゴリー2のSCDに設定されている次元
| 次元 | アダプタ |
|---|---|
|
W_CUSTOMER_FIN_PROFL_D |
PeopleSoft |
|
W_EMPLOYEE_D |
Oracle EBSおよびPeopleSoft |
|
W_INT_ORG_D |
PeopleSoft |
|
W_INVENTORY_PRODUCT_D |
Oracle EBS |
|
W_POSITION_D |
すべて |
|
W_PRODUCT_D |
Oracle EBS、Oracle SiebelおよびOracle JD Edwards EnterpriseOne |
|
W_Party_ORG_D |
Oracle JD Edwards EnterpriseOne |
|
W_BUSN_LOCATION_D |
PeopleSoft |
|
W_HR_POSITION_D |
すべて |
|
W_JOB_D |
すべて |
|
W_PAY_GRADE_D |
すべて |
|
W_PAY_TYPE_D |
すべて |
|
W_POSITION_DH |
すべて |
|
注意: 図17-2にリストされている任意の次元のTYPE2_FLGの選択を解除する場合、ソースに依存する抽出マッピングをカスタマイズする必要があります。次の変更を行います。
|
特定の次元に対する更新すべての履歴を残して、レポートに使用できるようにすることができます。これらの次元は、履歴上重要な属性と呼ばれます。たとえば、顧客が別の地域に移動し、その顧客に新しい地域の担当営業者およびテリトリーIDを割り当てる場合、その顧客のアカウント履歴、元の担当営業者およびテリトリーIDのレコードを保持する必要があります。この場合、担当営業者およびテリトリーIDは、履歴上重要な属性です。一方、電話番号フィールドにポピュレートするロードもできます。ビジネスで電話番号の履歴に関するデータ分析を実行しない場合、この情報は履歴上重要でない属性とみなされます。
属性が重要かどうかを特定することで、必要なSCDのカテゴリを決定できます。ただし、適切なタイプのSCDを選択できるようになるには、タイプの違いを理解しておく必要があります。
ステージング・エリアにあるすべてのテーブルの抽出ビューは、次の4種類のレコードで構成されています。
新規レコード
履歴上重要ではないデータを持つ変更済レコード
履歴上重要な変更済レコード
変更内容に重要性がなく、すべて無視される変更済レコード
4種類のレコードのうち、データ・マートで重視されるのは最初の3つのみです。それら3つのうち、まったくの新規レコードと変更がSCDとして追跡されるレコードは、両方とも新規として処理され、データ・ウェアハウスに挿入されます。変更内容が重要であっても履歴が追跡されないレコードは、プライマリキーに基づいて、データ・ウェアハウスで上書きされます。
重要な属性と重要でない属性を正しく特定したら、ユーザー要件に最も適した緩やかに変化する次元(SCD)のタイプ(カテゴリー1またはカテゴリー2)に基づいて、Oracle Business Analytics Warehouseを構成できます。
カテゴリー1のSCDは、カラムの値を上書きします。これは、Oracle Business Analytics WarehouseのデフォルトのSCDです。カテゴリー1は、履歴を保持しませんが、次元データをロードする最も簡単で最も速い方法です。カテゴリー1は、変更される次元の古い値を追跡することが重要ではないと考えられる場合、つまりその値が履歴上重要でない属性である場合に使用されます。たとえば、カラムの正しくない値を変更する場合にカテゴリー1を使用します。
図17-9では、サプライヤKMTの州名カラムがソース・テーブルSuppliersで変更されます(誤ってカリフォルニアと入力されていたため)。データ・ウェアハウス・テーブルにデータをロードするとき、履歴データは保持されず、値は上書きされます。カリフォルニアのサプライヤ値を参照してもKMTのレコードは表示されません。KMTのレコードは、最初から存在するミシガンに対してのみ表示されます。
カテゴリー2のSCDは、別のレコードを作成し、古いレコードをそのまま残します。カテゴリー2は、履歴上重要な属性を追跡できるため最も多く使用されるSCDです。古いレコードは、最新の変更よりも前の履歴をすべて指し、新しいレコードは、最新の情報を保持します。
緩やかに変化する次元は、スター・スキーマの別々の部分(要素テーブルと次元テーブル)で処理されます。図17-10は、抽出テーブル(SOURCE_CUSTOMERS)をデータ・ウェアハウスの次元テーブル(W_ORG_D)にする方法を示しています。追跡される属性は、顧客担当者など他にもありますが、この例では、履歴が追跡される属性は、セールステリトリーの1つのみです。会社は業績と報奨金を決定するために頻繁にテリトリーの統計情報を比較するため、これは履歴上重要な属性です。さらに、顧客の地域が変わった場合には、セールス活動が、収益の発生した地域に記録されます。
この例では、ある1日の抽出に限定しており、そこでは各顧客の新しいレコードが渡されます。SOURCE_CUSTOMERSから抽出されたデータは、ターゲット・テーブルW_ORG_Dにロードされ、各レコードには一意のプライマリキー(ROW_WID)が割り当てられます。
ただし、このデータは静的ではありません。次回データ抽出でW_ORG_Dの顧客の変更を表示する場合、レコードを変更する必要があります。この状況は、緩やかに変化する次元を起動するときに発生します。図17-11は、2社の顧客(ABC社およびXYZ社)のレコードの変更を示しています。ABCの顧客担当者がMaryからJaneに変更され、XYZのセールステリトリーがWestからNorthに変更されていることがわかります。
この例で前述したとおり、「顧客担当者」カラムは履歴上重要ではないため、カテゴリー1のSCDが適用されMaryがJaneに上書きされています。ABCのレコードの変更はカテゴリー1のSCDなので、新しい顧客レコードを作成する理由がありません。一方、XYZのレコードの変更では、セールステリトリーが変更されており、その属性は履歴上重要です。この例では、カテゴリー2の緩やかに変化する次元が必要です。
図17-11のとおり、XYZのレコードでは「セールステリトリー」カラムが上書きされないで、新しいレコードが追加され、W_ORG_DのXYZに新しいROW_WIDの172を割り当てています。XYZの元のレコード102は残され、XYZがWestセールステリトリーにあったときに発生した売上すべてにリンクされています。ただし、追加された新しいセールス・レコードが、NorthセールステリトリーのROW_WID 172の属性として新たに加えられています。
有効日は、レコードが有効になるタイミングを指定します。たとえば、新しい顧客の住所を2003年1月10日にロードし、その顧客が2003年1月20日に移転した場合、住所はその2つの日付の間のみ有効です。有効日は次の方法で処理されます。
ソースが発効日と失効日の両方を提供している場合は、それらの日付がウェアハウスのテーブルで使用されます。
ソースが発効日と失効日の両方を提供していない場合は、カテゴリー2のロジックによって有効日が作成されます。
ソースが2つの有効日のいずれかを提供している場合は、Oracle Business Analytics Warehouseは、ラッパー・マッピングを使用して、不足している有効日を自動的にポピュレートします。この状況については、この項で説明します。
たとえば、前述のW_ORG_DテーブルではXYZが新しいセールステリトリーに移転しました。
ソース・システムが場所の変更に関する履歴データを提供している場合、テーブルには、WestセールステリトリーのXYZのレコードに、発効日2001年1月1日と失効日3714年1月1日が含まれているとします。その翌年、XYZがNorthセールステリトリーに移転したことがソースで示された場合、表17-3に示すように、2番目のレコードが挿入され、そのレコードには、発効日2002年1月1日と失効日3714年1月1日が含まれます。
表17-3 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日のままですが、NorthテリトリーのXYZに対して2番目のレコードが追加され、新しい発効日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に設定されます。ラッパー・セッションの処理が終了した後は、表17-4のように、2つの別々のレコードではなく、XYZのカテゴリー2情報がデータ・ウェアハウスに置かれます。
表17-4 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 |
前の段落で、ラッパー・セッションは、失効日および現在のフラグを修正しました。ただし、レコードの日付が正しかった場合、ラッパー・マッピングは、現在のフラグを「必要」に設定するのみです。これは、このロジックは、日付およびフラグを確認し、不一致が含まれているカラムのみ調整するように設定されているためです。
参照変換により、参照テーブルを指定してから、コードの説明、為替レート、通貨コードなどの情報を取得できます。Oracle Business Analytics Warehouseには、事前に構成済の参照として次のタイプがあります。
次元キー参照。詳細は、第17.12項「次元キーの解決について」を参照してください。
ハード・ディスクに対してHDなどの直感的な記述であるインテリジェント・コードを使用するソース・システムがあります。また、ハード・ディスクに対して16などの直感的でないコード(番号やあいまいなディスクリプタなど)を使用するシステムもあります。コードは、情報を分析する重要なツールですが、使用されるコードおよびコードの記述が様々であるため、ソース・システム間で分析を実行する場合に問題が発生します。ソース・システムのコードに一貫性の無さを解決して、Oracle Business Analytics Warehouseのデータを統合する必要があります。
ロード・マッピングのコード参照では、インテリジェント・コードと直感的でないコードについて、コードを分けて抽出し、コード・テーブルにコードとその記述を挿入することで両方が統合されます。コード・テーブルでは、ロード・マッピングにリソースが提供されており、このリソースからコード記述への参照を自動的に実行できます。
Analytic Data Interfaceのアーキテクチャでは、要素テーブルおよび次元テーブルとともに、参照機能を支援するコンポーネントが使用されています。次のコンポーネントとプロセスが参照で使用されています。
ロード・コントロール・テーブルW_CODESは、後で参照できるようにすべてのコードを統合し、参照機能の効率化のために、それらのコードにカテゴリーと単一の言語を割り当てます。
Oracle Business Analytics Warehouseで使用されるマッピングは、ソース・システムからコードを抽出し、ロード・マッピングで使用できるように、W_CODESテーブルにポピュレートするように設計されています。
コード・マッピングの機能に関する知識を深めるには、最初にW_CODES内のカラムについて理解すると効果的です。表17-5は、それらのカラムについて説明しています。
表17-5 コード・マップレット内のカラム
| カラム | 説明 |
|---|---|
|
DATASOURCE_NUM_ID |
データの抽出元となるソース・システムの一意の識別子。 |
|
SOURCE_CODE1 |
様々なソース・システムのコード階層における最初のコード。特定のコードと記述の組合せを識別するために使用します。 |
|
SOURCE_CODE2 |
様々なソース・システムのコード階層における2番目のコード。特定のコードと記述の組合せを識別するために使用します。 |
|
SOURCE_CODE3 |
様々なソース・システムのコード階層における3番目のコード。特定のコードと記述の組合せを識別するために使用します。 |
|
SOURCE_DESC_1 |
ソース・システム・コードの簡単な説明。 |
|
SOURCE_DESC_2 |
コードの詳細な説明。 |
コード参照用に設計されたマッピングの命名規則は、SDE_[SOURCE]_CodeDimension_[CATEGORY]となります。図17-12は、Informatica PowerCenter Designerでのコード・マッピングの例を示しています。
図17-12 Informatica PowerCenter 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テーブルに存在しない場合、これらをテーブルに追加する必要があります。参照を構成するには、セッション・オーバーライドを作成します。ロード・マッピングのロード・マッピングを変更しないでください。
参照用にセッションを構成するには:
Informatica 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および参照日付を使用して次元キーを参照します。これらのカラムはすべて、ロード・マッピングで次元キーを返すために必要です。表17-6はこれらのポートについて説明しています。
表17-6 ロード・マッピングの次元キー参照で使用されるカラム
| ポート | 説明 |
|---|---|
|
INTEGRATION ID |
ソース・システム内で次元エンティティを一意に識別します。要素テーブルのSource Adapterにあるトランザクションで形成されます。 |
|
DATASOURCE_NUM_ID |
ソース・システムのインスタンスの一意の識別子。 |
|
参照日付 |
取引のプライマリ日付(受領日や販売日など)。 |
図17-3では、サプライヤ製品キー参照の変換で、ロード・マッピング参照に必要な3つの入力カラムのINTEGRATION ID、DATASOURCE_NUM_IDおよびDate(参照日付)が示されています。次に、この変換で、サプライヤ製品キー(次元キー)がデータ・ウェアハウス・テーブルW_SUPPLIER_PRODUCT_Dに出力されます。
カテゴリー2の緩やかに変化する次元が有効な場合、ロード・マッピングでは、次元レコードの更新ごとに一意の有効日が使用されます。次元キーの参照時には、要素のプライマリ日付を使用して適切な次元キーが解決されます。
有効日の範囲は、次元レコードの有効期間を指定します。カテゴリー2の緩やかに変化する次元であるため、同じエンティティで、異なる有効期間の複数のレコードを次元テーブルに持つことができます。この有効日の範囲は、次元内のレコードを正確に識別するために使用し、履歴において正確な方法で情報を表現します。図17-13に示されている従業員契約データの参照では、従業員契約の有効期間を提供するために有効日が使用されていることがわかります。
Oracle Business Analytics Warehouseの基盤は、異種のソース・システムのデータに対応するデータ・モデルで構成されています。データは、基幹業務システムから取得され、ソースに依存しないフォーマットに系統的に変えられます。データがソースに依存しないと、分析レポートの主要指標の作成に使用でき、指標の計算がソースに依存しません。この明確な分離により、ソース・システムを入れ替えたり、ソース・システムを追加するときに、各ソース・システムの要件に対応するように指標の計算を再構成する必要はありません。
ソース・データをソースに依存しないフォーマットに変換する方法の1つに、ソースから提供される値をドメイン値に変換する方法があります。ドメイン値は、パッケージされた指標を計算するために使用される一連の明確な値です。これらの値はOracle Business Analytics Warehouseによって提供されているため、ソース・システムの値と関係なく指標計算ができます。
ドメイン値変化のプロセスを理解するために、2つのソース・システム(ソース・システムAとソース・システムB)の例について考えてみます。各ソース・システムは、2つのタイプの従業員イベント(雇用と再雇用)を格納します。ソース・システムAは、雇用イベントを表すためにHを、再雇用イベントを表すためにRを使用し、ソース・システムBは、雇用イベントを表すために1を、再雇用イベントを表すために2を使用します。Oracle Business Analytics Warehouseは、データを両方のシステムから抽出するとき、データがW_EVENT_TYPE_DSステージング・テーブルのW_EVENT_GRP_CODEカラムに到達するまで抽出マッピングを使用してこれらのソース値を転送します。
次に、ロード・マッピングによって、抽出されたソース値(ソース・システムAからのHとR、およびソース・システムBからの1と2)が、Source Adapterマップレットに転送されます。Source Adapter内で、実際の業務に特有の一連のルールに基づいて、ソース値がドメイン値(HIRおよびREH)に翻訳されます。
固有のソース値を所定のドメイン値セットにマッピングする方法をSource Adapterが認識できるように、ルールを定義する必要があります。ルールを設定する前に、次の手順に従う必要があります。
すべてのソース値を分析し、事前にパッケージされたドメイン値にマッピングする方法を確認します。特定のカラムに、追加のドメイン値の作成が必要になる場合もあります。この準備作業により、各ソース値のリストと、ドメイン値にマッピングする方法が得られます。
該当するSource Adapterマップレットにこのロジックを実装します。ロジックを設定するには、影響を受けるカラムごとに、Source Adapterマップレットの式変換を変更します。ドメイン値のルールを設定する方法の詳細は、第17.15項「Informatica PowerCenter Designerを使用したドメイン値セットの構成」を参照してください。
図17-14は、ソース値がドメイン値HIRおよびREHに変換される処理を示しています。
図17-15は、レコードに雇用または再雇用のフラグを付けるソース値がレコードに含まれていない別の状況を示しています。この場合、ソース・システムは、雇用を一方のテーブルに、再雇用を他方のテーブルに格納します。この動作を行うための1つの可能な解決策は、W_EVENT_GRP_CODEカラムにHIRまたはREHをポピュレートするように抽出マッピングを変更することです。抽出マッピングのフィールドをポピュレートすると、Source Adapterマップレットを使用して、これら同じ値を備えることができます。
Source Adapterマップレットがソース固有の値をドメイン値に変換した後、そのドメイン値がOracle Business Analytics Warehouseのテーブルに挿入されます。この例では、図17-16のように、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に基づいています。ソース値がこれらのドメイン値のいずれかに変換されるレコードはすべて、図17-17に示すように、指標の計算に組み込まれます。
Oracle Business Analytics Warehouseに組み込まれた拡張性を利用すると、既存のドメイン値の定義に適さないカラムに対して、追加のドメイン値を作成できます。ただし、特定のカラムに設定されたドメイン値を変更する前に、既存の指標に対する影響を分析しておいてください。たとえば、Oracle Business Analytics Warehouseには、次の2つのイベントが事前にパッケージされています。
新規雇用。このイベントは、新規雇用時に発生します。
新規役職。役職が作成されたが既存の従業員を内部で雇用した場合に、このイベントは発生します。
新規雇用と新規役職の両方を表すイベントがある場合、両方を意味する第3のイベントを作成することもできます。この新しいイベントタイプのドメイン値を作成する場合は、該当する指標の定義に含めて、すべての雇用と役職が計算に入れられるようにする必要があります。
ドメイン値は、パッケージされた指標を計算するために使用される一連の明確な値です。これらの値はOracle Business Analytics Warehouseによって提供されているため、ソース・システムの値と関係なく指標計算ができます。Oracle Business Analytics Warehouseには、ソース・システム値をドメイン値にマッピングするCSVワークシート・ファイルが用意されています。
追加のソース・システム値が必要な場合には、ワークシート・ファイルに追加して、その値をドメイン値にマッピングできます。また、ドメイン値をカスタマイズする必要がある場合には、ワークシート・ファイルを変更することもできます。事前に構成済の指標を変更する場合には、既存のドメイン値を使用できます。それ以外の場合には、新しいドメイン値を作成し、このドメイン値に基づいて新しい指標を作成できます。
CSVワークシート・ファイルでドメイン値にマッピングされていないソース・システム値には、Oracle Business Analytics Warehouseで、ドメイン値として疑問符(?)が付いています。この値は、ドメイン値の指標には影響しません。
ソース・システム値をドメイン値にマッピングするワークシート・ファイルがない場合、Informatica PowerCenter Designerを使用してドメイン値を変更する必要があります。Informatica PowerCenter Designerを使用してドメイン値を構成する方法の詳細は、第17.15項「Informatica PowerCenter Designerを使用したドメイン値セットの構成」を参照してください。
使用しているアプリケーション用のCSVワークシート・ファイルおよびそのドメイン値の一覧については、使用しているアプリケーションの構成に関する章を参照してください。
CSVワークシート・ファイルを使用してソース値をドメイン値にマッピングするには:
ドメイン値を使用するOracle Business Analytics Warehouseテーブルのすべてのカラムを特定します。
ドメイン値を使用するカラムの一覧は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ドメイン値のいずれかへの変換に適したソース値をすべて一覧表示します。
各ソース値をドメイン値にマッピングします。
ソース・システム値のいずれかが事前にパッケージされたドメイン値にマッピングされず、ドメイン値のリストを変更する場合には、新しいドメイン値のリストを作成し、孤立したソース・システム値を新たに作成したドメイン値にマッピングします。
ドメイン値セットのなかには、変更できないものもあります。またドメイン値セットの変更によって影響を受ける指標を確認する必要があります。詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
$PMServer\LkpFilesディレクトリ(たとえば、INFA_HOME\server\infa_shared\LkpFiles)のCSVワークシート・ファイルを開きます。
ソース値を既存のドメイン値にマッピングするファイルを編集します。
または、ドメイン値を追加する場合には、このワークシート・ファイルに追加します。
ワークシート・ファイルを保存して閉じます。
ソース・システム値をドメイン値にマッピングするワークシート・ファイルがない場合、Informatica PowerCenter Designerを使用して値を変更する必要があります。CSVワークシート・ファイルでドメイン値セットを構成する方法の詳細は、第17.14項「CSVワークシート・ファイルによるドメイン値セットの構成」を参照してください。
Informatica PowerCenter Designerを使用して、特定のカラムに対してドメイン値セットを構成する場合は、次のいずれかまたは両方の操作を行います。
ドメイン値へのソース固有の値のマッピング
事前にパッケージされた値セットへのドメイン値の追加
どちらの操作を選択したかに関係なく、該当するSource Adapterマップレットの式変換では構成を行います。次に示す手順では、ドメイン値を変更するための式変換の構成方法について説明します。
Informatica PowerCenter Designerを使用してソース値をドメイン値にマッピングするには:
ドメイン値を使用するOracle Business Analytics Warehouseテーブルのすべてのカラムを特定します。
ドメイン値を使用するカラムの一覧は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ドメイン値のいずれかへの変換に適したソース値をすべて一覧表示します。
各ソース値をドメイン値にマッピングします。
ソース・システム値のいずれかが事前にパッケージされたドメイン値にマッピングされず、ドメイン値のリストを変更する場合には、新しいドメイン値のリストを作成し、孤立したソース・システム値を新たに作成したドメイン値にマッピングします。
ドメイン値セットのなかには、変更できないものもあります。またドメイン値セットの変更によって影響を受ける指標を確認する必要があります。詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
Informatica 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を変更することで変更できます。
フラット・ファイル抽出に対する製品の失効日のロジックを変更するには:
