| Oracle® Business Intelligence Applications新機能ガイド リリース7.9.6.2 B61365-01 |
|
 前 |
 次 |
この章の内容は次のとおりです。
「バックデート変更」とは、すでに処理され、ウェアハウスにロードされたOLTPレコードに生じた変更を意味します。役割階層は、従業員と管理者の報告関係を表し、この関係はOracle BI Applicationsのデータ・ウェアハウスで維持されます。この階層は、HRでは管理者階層に、CRMでは役割階層になります。役割階層は、現行の階層行の現行マークを使用して、階層の履歴バージョンをサポートします。役割階層は、履歴の追跡が有効化された状態で配信されます。従業員の組織と管理者は、タイプ2の緩やかに変化する属性です。また、CRMの役割階層では、従業員の役割の変更もタイプ2の緩やかに変化する属性として追跡されます。
以前のリリースでは、役割階層は、従業員の管理者、組織に対するバックデート変更やその他の情報に対する削除をサポートするように設計されていませんでした。ウェアハウスで管理者階層構造を構築する際にソースとなるOLTPのプライマリ駆動表や補助表で修正や削除が行われると、最後のETL実行日付よりも前の有効な変更が、修正としてではなく新規レコードとしてウェアハウスにロードされます。これにより、索引の作成処理でレコードが重複するため、ETLが異常終了していました。今回のリリースでは、管理者階層および役割階層に影響を及ぼすOLTPでのバックデート変更や削除でも、ウェアハウスでは変更が遡及的に反映されるように、ETLで適切に処理されます。
役割階層は列がフラット化した構造をしており、役割次元からロードされます。またこの役割階層では親子関係が維持されています。この項に記載されているシナリオでは、バックデート変更によって役割次元が受ける影響について、また、それにより役割階層が受ける影響について説明します。
Oracle EBSなどのOLTPソース・システムでは、履歴行または現行行に対して修正を行うことができます。修正は、データ・ウェアハウスのプライマリ・データソースとなるOLTP表、またはETLプロセスで補助参照用として機能する表に対して行うことができます。修正は、次の属性に影響する可能性があります:
履歴を収集せず、タイプ1の緩やかに変化する次元(SCD)としてデータ・ウェアハウスで処理される属性。
履歴を収集し、タイプ2のSCDとしてデータ・ウェアハウスで処理される属性。
役割階層は、様々な表におけるバックデート変更の影響を受けます。これにより、ETLプロセスも直接的または間接的な影響を受けます。たとえば、OLTPソース・システムで過去に遡って部署名を変更し、これに対応する従業員の割当てを変更しなかった場合、この部署名のバックデート変更によって役割階層に対する履歴の更新が発生します。
管理者階層または役割階層に影響を及ぼすOLTP表は、主に3つのタイプに分かれます。次の例は、OLTPソース・システムの表を表しています。
タイプA: すべての割当て履歴データが格納されるプライマリ駆動表です(PER_ALL_ASSIGNMENTS_Fなど)。この表は、データ・ウェアハウスの従業員割当て履歴に対するプライマリ・ドライバになります。
タイプB: OLTPには履歴が保持されない補助ソース表(タイプ1のSCD)ですが、ウェアハウスではタイプ2のSCDとして属性変更が追跡されます(HR_ORGANIZATION_UNITSなど)。この表は、ウェアハウスで履歴が追跡される属性のソースになります
タイプC: OLTPには履歴が保持されず、ウェアハウスでも属性の変更履歴が保持されない(タイプ1のSCD)補助ソース表です(PER_JOBSなど)。この表は、ウェアハウスで履歴が追跡されない属性のソースになります。
Oracle BI Applicationsリリース7.9.6の機能では、次のことを前提とします。
役割階層は、データ・ウェアハウス内ではタイプ2のSCDとして履歴の追跡が行われます。
部署名は、データ・ウェアハウス内ではタイプ2の緩やかに変化する属性として履歴の追跡が行われます。
従業員名(タイプ1の緩やかに変化する属性)は、データ・ウェアハウス内で履歴の追跡が行われません。
ジョブ(タイプ1の緩やかに変化する属性)は、ウェアハウス内で履歴の追跡が行われません。
次の表は、ウェアハウス内にある、バックデート変更前の従業員P1の割当て履歴の例です。
表8-1 バックデート変更前の従業員P1の割当て履歴の例
| 行 | 従業員 | 部署 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
|
行1 |
P1 |
CRM |
Mgr1 |
2006 |
2008 |
|
行2 |
P1 |
マイ部署 |
Mgr2 |
2008 |
2009 |
|
行3 |
P1 |
マイ部署 |
Mgr3 |
2009 |
4712 |
この項では、役割階層に影響を与えるOLTPでのバックデート変更のタイプと、そのバックデート変更シナリオへの対応としてウェアハウスに用意されているソリューションについて説明します。
ある部署名が、現行のレコードに対する修正として変更されました。たとえば、部署名「マイ部署」が、2010年に「マイ新規部署」に変更されたような場合です。異動の結果、従業員の部署は変更されませんでした。この場合、ソース表では部署名の履歴が追跡されないため、タイプBの変更、つまりタイプ2のウェアハウス内で緩やかに変化する属性になります。
オプション1
このオプションは、タイプ2 (SCD)の変更として処理され、ウェアハウスにはタイプ2 (SCD)の新規行が導入されます。このオプションは、DACパラメータUPDATE_CORRECTIONS_FLGが「N」に設定されている場合に有効です。
| 従業員 | 部署 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|
| P1 | CRM | Mgr1 | 2006 | 2008 |
| P1 | マイ部署 | Mgr2 | 2008 | 2009 |
| P1 | マイ部署 | Mgr3 | 2009 | 2010 |
| P1 | マイ新規部署 | Mgr3 | 2010 | 4712 |
オプション2
このオプションは、修正として処理されるため、ウェアハウスではタイプ2の新規行は追加されず、履歴データのみが変更されます。このオプションは、DACパラメータUPDATE_CORRECTIONS_FLGが「Y」に設定されている場合に有効です。
| 従業員 | 部署 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|
| P1 | CRM | Mgr1 | 2006 | 2008 |
| P1 | マイ新規部署 | Mgr2 | 2008 | 2009 |
| P1 | マイ新規部署 | Mgr3 | 2009 | 4712 |
部署名が履歴レコードに対する修正として変更されました。たとえば、部署名「マイ部署」が、過去の2008年に遡って「MD」に変更されたような場合です。異動の結果、従業員の部署は変更されませんでした。この場合も、部署名の履歴がOLTPソース・システムでは追跡されず、データ・ウェアハウスではタイプ2のSCDとして追跡されるため、タイプBの変更になります。
オプション
該当する履歴レコードで、変更内容に応じて名前を更新します。
| 従業員 | 部署 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|
| P1 | CRM | Mgr1 | 2006 | 2008 |
| P1 | MD | Mgr2 | 2008 | 2009 |
| P1 | マイ新規部署 | Mgr3 | 2009 | 4712 |
補助表の変更: ウェアハウスの履歴データから参照されるジョブ情報が、OLTPソース・システムで変更されました。たとえば、ジョブ名が小文字に変更されたような場合です。この場合、OLTPでもデータ・ウェアハウスでも履歴の変更が追跡されないため、タイプCの変更になります。
オプション
新しいジョブは、すべての履歴行に伝播されます。
| 従業員 | 部署 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|
| P1 | CRM | Mgr1, job2 | 2006 | 2008 |
| P1 | マイ部署 | Mgr2, job2 | 2008 | 2009 |
| P1 | マイ部署 | Mgr3, job2 | 2009 | 4712 |
異動の結果、従業員の割当て部署が変更されました。たとえば、従業員P1が2010年に部署「GRC」に異動になり、Mgr4の部下となったような場合です。この場合、メインのOLTP駆動表で変更が発生し、履歴の追跡も行われるため、タイプAの変更になります。
オプション
ある従業員に新しい管理者が追加され、その従業員を追跡するために、データ・ウェアハウスに新規行が挿入されます。これは標準のケースです。
| 従業員 | 部署 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|
| P1 | CRM | Mgr1 | 2006 | 2008 |
| P1 | マイ部署 | Mgr2 | 2008 | 2009 |
| P1 | マイ部署 | Mgr3 | 2009 | 2010 |
| P1 | GRC | Mgr4 | 2010 | 4712 |
これはシナリオ3のバリエーションです。たとえば、従業員が「CRM」から「マイ部署」に異動したのが、実際には2008年ではなく2007年だったような場合です。この場合は、割当て履歴レコードに対する修正になります。駆動側であるOLTP履歴表のeffective_fromとeffective_toの日付に対してバックデート変更が行われます。
オプション1
ウェアハウスで履歴データを更新します。このとき、ファクト表の更新は必要ありません。このオプションは、DACパラメータUPDATE_CORRECTIONS_FLGが「Y」に設定されている場合に有効です。
| 行 | 従業員 | 部署 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
| 1 | P1 | CRM | Mgr1 | 2006 | 2007 |
| 2 | P1 | マイ部署 | Mgr2 | 2007 | 2009 |
| 3 | P1 | マイ部署 | Mgr3 | 2009 | 4712 |
オプション2
このオプションでは、変更の追跡対象となる新規行がウェアハウスに導入されます。このオプションは、DACパラメータUPDATE_CORRECTIONS_FLGが「N」に設定されている場合に有効です。
| 行 | 従業員 | 部署 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
| 1 | P1 | CRM | Mgr1 | 2006 | 2007 |
| 4 | P1 | マイ部署 | Mgr2 | 2007 | 2008(新規) |
| 2 | P1 | マイ部署 | Mgr2 | 2008 | 2009 |
| 3 | P1 | マイ部署 | Mgr3 | 2009 | 4712 |
バックデート変更前の状態では、ファクト表には階層表の行1を参照しているトランザクションや行2への外部キーを持つトランザクションがありました。行1への外部キーを持つファクト行は、トランザクション日付に応じて、引き続き同じ外部キーを使用するか、行2または行4のいずれかに一致するように外部キーが更新されます。
OLTPソース・システムでバックデート変更を行うと、レコードが分割されます。たとえば、従業員の2007年の管理者をMgr1からMgr5に変更したような場合です。OLTPソース・システムでは、元のMgr1の情報を持つ割当てレコードの終了日に新しく2007が使用されます。また、2007年の管理者Mgr5には新規レコードが追加され、従業員が新しく割り当てられます。ウェアハウスは、OLTPソースの変更に応じて次の表のようになります。
オプション
| 行 | 従業員 | 部署 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
| 1 | P1 | CRM | Mgr1 | 2006 | 2007 |
| 4 | P1 | CRM | Mgr5 | 2007 | 2008(新規) |
| 2 | P1 | マイ部署 | Mgr2 | 2008 | 2009 |
| 3 | P1 | マイ部署 | Mgr3 | 2009 | 4712 |
行1への外部キーを持つファクト行では、トランザクション日付に応じて、その外部キーが引き続き使用されるか、または行4に対する外部キーとなるように更新されます。
バックデート変更は、特定の日付を基点としてすべてのレコードにカスケードされます。たとえば、行3のMgr2はMgr4になり、2008年以降のすべての行では、管理者も変更されます。従業員割当ての現行レコードは、データ・ウェアハウスでは次のようになります。
| 行 | 従業員 | 部署 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
| 1 | P1 | CRM | Mgr1 | 2006 | 2007 |
| 2 | P1 | CRM | Mgr5 | 2007 | 2008(新規) |
| 3 | P1 | マイ部署 | Mgr2 | 2008 | 2009 |
| 4 | P1 | マイ部署 | Mgr3 | 2009 | 4712 |
オプション
ウェアハウスの履歴レコードおよび現行レコードを次のように更新します。
| 行 | 従業員 | 部署 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
| 1 | P1 | CRM | Mgr1 | 2006 | 2007 |
| 2 | P1 | CRM | Mgr5 | 2007 | 2008(新規) |
| 3 | P1 | マイ部署 | Mgr4 | 2008 | 2009 |
| 4 | P1 | マイ部署 | Mgr4 | 2009 | 4712 |
この項では、役割階層でのバックデート変更のサポートに伴い変更されたオブジェクトについて説明します。
データ・モデルに対して次の変更が行われました。
W_POSITION_DおよびW_POSITION_DHへのSCD1_WIDの追加
W_POSITION_DHへのDELETE_FLGの追加
新規表W_POSITION_DH_BAK、W_POSITION_DH_PRE_CHG_TMP、W_POSITION_DH_POST_CHG_TMPの追加
W_POSITION_DH_BASE_TMPへの新規列SCD_TYPE1B_FLGおよびSCD_TYPE2B_FLGの追加
この項では、Informaticaのコード変更について説明します。
新たに次のマッピングが追加されました。
SIL_PositionDimensionHierarchy_SoftDelete
SIL_PositionDimensionHierarchy_IdentifyBaseModified_TypeB
SIL_PositionDimensionHierarchy_PreChangeTemp
SIL_PositionDimensionHierarchy_PostChangeTemp
SIL_PositionDimensionHierarchy_CopyDelete
SIL_PositionDimensionHierarchy_Delete
次のマッピングが更新されています。
SIL_PositionDimensioHierarchy
SIL_PositionDimensioHierarchy_Full
SIL_PositionDimensionHierarchy_IdentifyBaseModified
次のセッション/ワークフローがInformaticaに追加されました。
SIL_PositionDimensionHierarchy_SoftDelete
SIL_PositionDimensionHierarchy_IdentifyBaseModified_TypeB
SIL_PositionDimensionHierarchy_PreChangeTemp
SIL_PositionDimensionHierarchy_PostChangeTemp
SIL_PositionDimensionHierarchy_CopyDelete
SIL_PositionDimensionHierarchy_Delete
次のタスクがDACに追加されました。
SIL_PositionDimensionHierarchy_SoftDelete
SIL_PositionDimensionHierarchy_IdentifyBaseModified_TypeB
SIL_PositionDimensionHierarchy_PreChangeTemp
SIL_PositionDimensionHierarchy_PostChangeTemp
SIL_PositionDimensionHierarchy_CopyDelete
SIL_PositionDimensionHierarchy_Delete
