この付録では、Pharma Analytics用Oracle BIリポジトリをアップグレードする手順について説明します。
Oracle Business Intelligence Applicationsリリース7.9.4では、Pharma AnalyticsビジネスモデルとCoreビジネスモデルがマージされています。このマージにより、Oracle BIリポジトリをアップグレードするためのプロセスには、Oracle BIリポジトリをアップグレードするための標準的なプロセスとは異なる手順があります。
この章の内容は次のとおりです。
Pharma Analyticsリリース7.9.4では次に示す変更が行われました。
Pharma Analytics物理テーブルは、Oracle Business Analytics Warehouseに組み込まれました。
Pharma Analytics論理テーブル(要素テーブルと次元テーブル)は、Coreビジネスモデルに組み込まれました。
Pharma Analyticsでは、Coreモジュールとしていくつかの共通次元(日付、顧客、担当者、セキュリティなど)が他のCoreモジュールと共有されます。
表A-1に、共通のPharma Analytics次元と次元状況を示します。特定のPharma要件により、Pharma次元には他のCoreモジュールと共有しない次元もあります。
表A-1 共通のPharma Analytics次元
| リリース7.9.4より前のリリースにおける次元 | リリース7.9.4における次元 | 状況 | 備考 |
|---|---|---|---|
|
Dim - Accounts |
Dim - Customer |
共有される |
値はありません。 |
|
Dim - Contacts |
Dim - Contact |
共有される |
新しい名前は単数形です。 |
|
Dim - Security Dimension |
Dim - Security Dimension |
共有される |
値はありません。 |
|
Dim - Time Period |
Dim - Date |
共有される |
値はありません。 |
|
Dim - Geography |
Dim - Pharma Geography |
共有されない |
CoreにおいてPharma特有の次元を使用してください。 |
|
Dim - Geography_Account |
Dim - Geography_Account |
共有されない |
CoreにおいてPharma特有の次元を使用してください。 |
|
Dim - Geography_Contact |
Dim - Pharma Geography_Contact |
共有されない |
CoreにおいてPharma特有の次元を使用してください。 |
|
Dim - Products |
Dim - Pharma Products |
共有されない |
CoreにおいてPharma特有の次元を使用してください。 |
Pharma Analyticsのアップグレード・プロセスでは、以前のリリースのSiebel AnalyticsやOracle BIのリポジトリにおけるカスタマイズ内容を、現行リリースのOracle BIのリポジトリにマージする作業が必要です。このプロセスでは、Coreのアップグレード・プロセスと同じ原則に従いますが、このプロセスに固有な手順もあります。
図A-1に示すように、Pharma Analyticsのアップグレード・プロセスにはフェーズが2つあります。
フェーズ1
図A-1に示すように、Pharma Analyticsのアップグレード・プロセスにはフェーズが2つあります。フェーズ1では、リリース7.x用Coreベースのオリジナル・リポジトリ(現在実行しているSiebel AnalyticsやOracle BIのリリースに付属しているリポジトリ)、リリース7.x用のCoreカスタマイズ・リポジトリおよびリリース7.9.4用の新しいベース・リポジトリを、1つの出力リポジトリにマージします。
フェーズ2
フェーズ2では、フェーズ1の出力リポジトリを、リリース7.x用Pharma Analyticsベースのオリジナル・リポジトリとリリース7.x用のPharma Analyticsカスタマイズ・リポジトリとをマージします。フェーズ2の出力リポジトリは、PharmaリポジトリとCoreリポジトリがマージされたリポジトリで、以前のリリースからのカスタマイズ内容とリリース7.9.4の新しいデータモデルが含まれているリポジトリです。
|
注意: 現在使用しているカスタマイズ・リポジトリに、CoreモデルとPharmaモデルの両方があり、Coreモデルがカスタマイズされている場合は、アップグレード・プロセスの両方のフェーズを実行する必要があります。現在使用しているカスタマイズ・リポジトリにCoreモデルが含まれていない場合や、Coreモデルは含まれているがCoreモデルはカスタマイズされていない場合は、フェーズ2のみを実行する必要があります。 フェーズ2のみを実行する場合、リリース7.9.4用Coreがマージされたrpdファイル(図A-1を参照)はありません。リリース7.9.4用Coreがマージされたrpdファイルのかわりに、リリース7.9.4用の新しいベースrpdファイルを使用します。 |
この項に記載している作業では、複数のバージョンのSiebel AnalyticsリポジトリやOracle BIリポジトリについて言及しています。表A-2には、フェーズ1で使用しているリポジトリの名前と説明が記載されています。表A-3には、フェーズ2で使用しているリポジトリの名前と説明が記載されています。
表A-2 フェーズ1のリポジトリファイル
| リポジトリファイル | 説明 |
|---|---|
|
7x_original_Core_base.rpd |
アップグレード元リリース用の標準Oracle BIリポジトリ(調整済でオリジナルのリポジトリ)です。 |
|
7x_custom_Core.rpd |
リリース7.x用の調整済カスタマイズ・リポジトリ(Coreモデルのカスタマイズが含まれているリポジトリ)です。 |
|
794_new_base.rpd |
リリース7.9.4用の調整済リポジトリ(関連したCoreモジュールとPharmaモジュールが1つのCoreモデル(論理フォルダ)に含まれているリポジトリ)です。 |
表A-3 フェーズ2のリポジトリファイル
| リポジトリファイル | 説明 |
|---|---|
|
794_Core_merged.rpd |
フェーズ1からの出力リポジトリです。 フェーズ1を実行しなかった場合、リリース7.9.4用Coreがマージされたrpdファイルのかわりに、リリース7.9.4用の新しいベースrpdファイルを使用します。 |
|
7x_original_Pharma_base.rpd |
リリース7.x用の調整済オリジナル・リポジトリ(カスタマイズされていないPharmaモデルが含まれているリポジトリ)です。 |
|
7x_custom_Pharma.rpd |
調整済カスタマイズ・リポジトリ(カスタマイズされたPharmaモデルが含まれているリポジトリ)です。 |
|
794_Core_Pharma_merged.rpd |
リリース7.9.4用のマージされた最終リポジトリ(単一のCoreモデル(論理フォルダ)が含まれているリポジトリ)で、カスタマイズされた内容がすべて含まれています。 |
マージ・プロセスの様々なステージを実行したら、リポジトリファイル格納用作業フォルダを使用します。
マージ・プロセス用のフォルダ(\OracleBIPharmaUpgradeなど)を作成してから、次のサブフォルダを作成します。
Original
AfterTrimDown
AfterEqualize
AfterMerge
AfterManualWork
AfterRegressions
使用している内容のみアップグレードするようにリポジトリを調整すると、アップグレード対象を限定してマージ・プロセスを単純にすることができます。
プロジェクトを抽出したり手動でリポジトリオブジェクトの数を減らすことで、オリジナルのベース・リポジトリファイル(Core用とPharma用)を調整できます。
オリジナルのベース・リポジトリファイルを調整するには:
アップグレード・プロセスのフェーズ1を実行した場合、オリジナルのCore用ベース・リポジトリファイルを調整します。
このファイルを7x_original_Core_base.rpdの名前でAfterTrimDownサブフォルダに保存します(ファイル名の7xは、Siebel AnalyticsかOracle BIのリリース番号を示す文字にします)。
オリジナルのPharmaベース・リポジトリファイルを調整します。
このファイルを7x_original_Pharma _base.rpdの名前でAfterTrimDownサブフォルダに保存します。
現行リリースのOracle BI Applicationsに付属していた新しいベース・リポジトリファイルには、Coreモデル(論理フォルダ)が含まれています。これにはPharma用とCore用のリポジトリオブジェクトが格納されています。
新しいベース・リポジトリファイルを調整するには:
新しいベース・リポジトリファイルを調整します。
このファイルを794_new_base.rpdの名前でAfterTrimDownサブフォルダに保存します。
アップグレード・プロセスのフェーズ1を実行した場合、リリース7.x用Coreのカスタマイズ・リポジトリファイル(7x_custom_core.rpd)が存在することになります。このファイルには、リリース7.x用Coreベースのオリジナルの内容とカスタマイズ内容が含まれています。
また、リリース7.x用Pharmaのカスタマイズ・リポジトリファイル(7x_custom_Pharma.rpd)も存在することになります。このファイルには、リリース7.x用Pharmaベースのオリジナルの内容とカスタマイズ内容が含まれています。
これらのファイルをAfterTrimDownサブフォルダに保存します。
リリース7.x用Pharmaベースのオリジナル・リポジトリファイルとリリース7.x用Pharmaベースのカスタマイズ・リポジトリファイルでは、新しいデータモデルとの互換性を実現するために、名前の変更が必要なリポジトリオブジェクトがあります。
Pharmaリポジトリファイルにおいてオブジェクト名を変更するには:
Server Administration Toolで、7x _original_Pharma_base.rpdファイルを開きます。
「Business Model and Mapping」レイヤーで、すべてのPharmaインスタンスの名前をCoreに変更します。
「Physical」レイヤーで、次を実行します。
すべてのPharmaインスタンスの名前をCoreに変更します。
すべてのPharma Data Warehouseインスタンスの名前をOracle Data Warehouseに変更します。
接続プールの名前がData Warehouse Connection Poolになっていることを確認します。
Catalogとdboが接続プール・エントリの下に表示されることを確認します。
7x_custom_Pharma.rpdファイルを使用して、手順1〜3を繰り返します。
Oracle BIリポジトリにおける標準的なアップグレードの同等化プロセスでは、以前のリリースのオリジナルのベース・リポジトリを基準として使用します。このタイプの同等化は、下位同等化と呼ばれます。Pharmaアップグレードでは上位同等化と呼ばれる手法が使用されます。この手法では、現行リリースのリポジトリファイルを基準として使用して、7xベースのリポジトリファイルと7xベースのカスタマイズ・リポジトリファイルを同等化します。
同等化を実行する前に、最初に上位同等化用MAPファイルを準備する必要があります。
上位同等化用MAPファイルを準備するには:
適切なMAPファイルをOracleBI\Upgradeフォルダからequalizerpds.exe実行用フォルダにコピーします。
|
注意: MAPファイルのネーミング規則は、rename<アップグレード元リリース番号>-<アップグレード先リリース番号>.mapです。現行リリースにアップグレードするには、アップグレード先リリース番号として79を選択します。たとえば、リリース7.8.4からリリース7.9.4にアップグレードする場合、rename784_79.mapファイルを使用する必要があります。 |
MAPファイルをExcelで開きます。
「テキスト ファイル ウィザード - 1 / 3」ダイアログでデフォルト値のままにして「次へ」をクリックします。
「テキスト ファイル ウィザード - 2 / 3」ダイアログで、次を実行します。
「区切り文字」領域で「タブ」チェック・ボックスが選択されていることを確認します。
「文字列の引用符」リストで、「なし」を選択します。
「次へ」をクリックします。
「テキスト ファイル ウィザード - 3 / 3」ダイアログで「完了」をクリックします。
ファイルがExcelのスプレッドシート・ウィンドウで開き、3列で表示されます。
3番目の列を切り取って2番目の列として挿入することで、2番目の列と3番目の列を入れ替えます。
ファイルを保存します。
文字列のフォーマットが正しいことを確認します。
リポジトリファイルの同等化を行うには:
equalizerpds.exeを実行します。
equalizerpdsコマンドの例を次に示します。
equalizerpds -A Administrator -B SADMIN -C \OracleBIPharmaUpgrade\AfterTrimDown\794_new_base.rpd -D Administrator -E SADMIN -F \OracleBIPharmaUpgrade\AfterTrimDown\7x_custom_Pharma.rpd -O \OracleBIPharmaUpgrade\AfterEqualize\7x_custom_Pharma.rpd -X -J rename784-79.map
equalizerpds.exe実行可能ファイルが正常に実行されると、返されるエラーはありません。
手順1を繰り返して、AfterTrimDownフォルダにある各ファイルを794_new_base.rpdに同等化します。
プロセスが正常に完了したことを確認するには、リポジトリのサイズを比較します。出力リポジトリ(-O)のサイズは、同等化(-F)を行ったリポジトリのサイズに近似した値になります。
|
注意: カスタマイズ・リポジトリにCoreモデルとPharmaモデルの両方があり、Coreモデルがカスタマイズされている場合は、この項の手順を実行する必要があります。カスタマイズ・リポジトリにCoreモデルが含まれていない場合や、Coreモデルは含まれているがCoreモデルがカスタマイズされていない場合は、この項の手順を実行する必要はありません。 |
この項の手順では、Coreリポジトリに対して3段階でマージします。この項の手順でマージするファイルの詳細は、第A.3項「Pharma AnalyticsにおけるSiebel AnalyticsとOracle BIのリポジトリのマージ」を参照してください。
Coreリポジトリファイルをマージするには:
7x_original_Core_base.rpd、7x_custom_Core.rpdおよび794_new_base.rpdをAfterMergeフォルダにコピーします。
Server Administration Toolで、794_new_base.rpdファイルを開きます。
Administration Toolのメニュー・バーで、「File」→「Merge」を選択します。
「Select Original Repository」ダイアログで、7x_original_Core_baseを選択します。
パスワードを入力してから「OK」をクリックします。
「Select for the Modified Repository field」をクリックします。
「Select Modified Repository」ダイアログで、7x_custom_Core.rpdを選択します。
「Open」をクリックしてパスワードを入力し、「OK」をクリックします。
「Decision」リストで、リポジトリ変更に対応する操作を選択するか、デフォルト操作を受け入れます。
意思決定の詳細は、第A.3.7項「Server Admin Toolにおけるマージ関連の意思決定」を参照してください。
「Decision」フィールドが空の後続の行を検出するには、「Decision」ヘッダー・セルをクリックします。
すべての行の「Decision」フィールドに値が入力されると、「Merge」ボタンが有効になります。
「Merge」をクリックします。
作業しているリポジトリのサイズによっては、このプロセスの所要時間が最大40分になる場合があります。マージが完了すると、メッセージにより通知が行われます。
一貫性チェックを実行する場合は、「はい」をクリックします。
一貫性チェックで返されたエラーの数により、マージ・プロセスの実行結果を判定します。発生したエラーの数が多い場合(たとえば、300個以上)、エラーの原因を分析する必要があります。マージ・プロセスにおいて別々のオブジェクトが同等であるとの認識に失敗したとき、名前変更ファイルの編集が必要になる場合があります。また、多くのオブジェクトの名前を変更したが、アップグレード・エンジンでそれらを元のオブジェクトに関連付ける処理が失敗した場合、独自の名前変更ファイルを追加する必要が発生する場合があります。
また、マージを再実行する前に、「Decision」ドロップダウン・リストで選択した操作の変更が必要になる場合もあります。これによって、手作業での対処が必要なエラーの数が減少して、時間を節約できる場合があります。
マージの結果が満足できる水準に達しても、残りのエラーを手作業で対処する必要があります。次の手順に進む前に、すべてのエラーに対処することが重要です。このリポジトリは、次のステージの入力として使用します。
また、カスタマイズしたオブジェクトのすべてが存在していることと、重複した物理テーブルが存在しないことも確認する必要があります。重複した物理テーブルの有無を確認するには、次のようなクエリーを使用して物理テーブルを検索します。
where name like '*#1'
マージしたリポジトリを794_Core_merged.rpdの名前で保存します。
この項の手順では、Pharmaリポジトリに対して3段階でマージします。この項の手順でマージするファイルの詳細は、第A.3項「Pharma AnalyticsにおけるSiebel AnalyticsとOracle BIのリポジトリのマージ」を参照してください。
|
注意: アップグレード・プロセスのフェーズ1を実行しなかった場合、794_Core_merged.rpdファイルはありません。794_Core_merged.rpdファイルのかわりに、794_new_base.rpdファイルを使用する必要があります。 |
Pharmaリポジトリファイルをマージするには:
794_Core_merged.rpd、7x_original_Pharma_base.rpdおよび7x_custom_Pharma.rpdをAfterMergeフォルダにコピーします。
Server Administration Toolで、794_Core_merged.rpdファイルを開きます。
Administration Toolのメニュー・バーで、「File」→「Merge」を選択します。
「Select Original Repository」ダイアログで、7x_original_Pharma_baseを選択します。
パスワードを入力してから「OK」をクリックします。
「Select for the Modified Repository field」をクリックします。
「Select Modified Repository」ダイアログで、7x_custom_Pharma.rpdを選択します。
「Open」をクリックしてパスワードを入力し、「OK」をクリックします。
「Decision」リストで、リポジトリ変更に対応する操作を選択するか、デフォルト操作を受け入れます。
意思決定の詳細は、第A.3.7項「Server Admin Toolにおけるマージ関連の意思決定」を参照してください。
「Decision」フィールドが空の後続の行を検出するには、「Decision」ヘッダー・セルをクリックします。
すべての行の「Decision」フィールドに値が入力されると、「Merge」ボタンが有効になります。
「Merge」をクリックします。
作業しているリポジトリのサイズによっては、このプロセスの所要時間が最大40分になる場合があります。マージが完了すると、メッセージにより通知が行われます。
一貫性チェックを実行する場合は、「はい」をクリックします。
一貫性チェックで返されたエラーの数により、マージ・プロセスの実行結果を判定します。発生したエラーの数が多い場合(たとえば、300個以上)、エラーの原因を分析する必要があります。マージ・プロセスにおいて別々のオブジェクトが同等であるとの認識に失敗したとき、名前変更ファイルの編集が必要になる場合があります。また、多くのオブジェクトの名前を変更したが、アップグレード・エンジンでそれらを元のオブジェクトに関連付ける処理が失敗した場合、独自の名前変更ファイルを追加する必要が発生する場合があります。
また、マージを再実行する前に、「Decision」ドロップダウン・リストで選択した操作の変更が必要になる場合もあります。これによって、手作業での対処が必要なエラーの数が減少して、時間を節約できる場合があります。
マージの結果が満足できる水準に達しても、残りのエラーを手作業で対処する必要があります。次の手順に進む前に、すべてのエラーに対処することが重要です。このリポジトリは、次のステージの入力として使用します。
また、カスタマイズしたオブジェクトのすべてが存在していることと、重複した物理テーブルが存在しないことも確認する必要があります。重複した物理テーブルの有無を確認するには、次のようなクエリーを使用して物理テーブルを検索します。
where name like '*#1'
マージしたリポジトリを794_Core_Pharma_merged.rpdの名前で保存します。
リポジトリオブジェクトをServer Admin Toolでマージするときに意思決定を行う際、次の事項を考慮する必要があります。
新しいベース・リポジトリに表示されないオブジェクトの場合、一般的に「Current」を選択する必要があります。これによって、新しいベース・リポジトリに変更が取り込まれます。
新しいベース・リポジトリに追加されたオブジェクトの場合、一般的に「Current」を選択する必要があります。これによって、変更が保持されます。
オリジナルのリポジトリにおいて新しいオブジェクトで置換されたオブジェクトがある場合、古いオブジェクトを現在のリポジトリから削除して新しいオブジェクトを追加する決断が妥当である場合があります。「Current」を選択すると、古いオブジェクトが置換されます。
リポジトリに追加された新しいカスタマイズがある場合、「Modified」を選択して変更を保持します。
カスタマイズされたリポジトリと新しいベース・リポジトリの両方でオブジェクトが変更された場合、両方が変更されていることを示す説明が表示される場合があります。その場合、「Current」を選択して新しいベース・リポジトリのオブジェクトをそのまま保持するか、「Modified」を選択して、カスタマイズされたリポジトリのオブジェクトをそのまま保持します。
リポジトリファイルをマージしたら、事前構成済のプレゼンテーション次元テーブルとプレゼンテーションカラムは、すべて適切にマージされ、Coreモデルの新しい論理次元がソースになります。たとえば、AccountプレゼンテーションテーブルのAccount Nameは、"Core"."Dim - Customer"."Account Name"がソースとなります。また、ProductプレゼンテーションテーブルのGross Marginは、"Core"."Dim - Pharma Products"."Gross Margin"がソースとなります。
ただし、カスタマイズされたプレゼンテーションテーブルとプレゼンテーションカラムは、古い次元がソースとなる場合があります。表A-4には、リリース7.9.4において新しい次元名がある共通次元が記載されています。表A-4に記載された次元をカスタマイズした場合、古い次元名を新しい次元名で置換する必要があります。
表A-4 共通のPharma Analytics次元の新しい次元名
| リリース7.9.4より前のリリースにおける次元の名前 | リリース7.9.4における次元の名前 | 状況 | 備考 |
|---|---|---|---|
|
Dim - Accounts |
Dim - Customer |
共有される |
値はありません。 |
|
Dim - Contacts |
Dim - Contact |
共有される |
新しい名前は単数形です。 |
|
Dim - Time Period |
Dim - Date |
共有される |
値はありません。 |
古い共通次元名をリリース7.9.4用の新しい名前で置換するには:
表A-4に記載された古い次元名(たとえば、Dim - Accounts)を、Core論理フォルダにおいてServer Admin Toolで検索します。
古い次元名を右クリックしてから、「Display Related」→「Presentation Column」をクリックします。
新しい論理次元の同じカラム(たとえば、Dim - Customer)でプレゼンテーションカラムを置換します。
プレゼンテーションカラムが適切に置換されたことを確認するには、Core論理次元でプレゼンテーションカラム(たとえば、Core - Accounts)を検索します。検索結果が空の場合、古い次元(たとえば、Dim - Accounts)を削除しても安全です。