G 業種固有のAnalytics Applications用Oracle BIリポジトリのアップグレード

この付録では、Pharma Analytics、Consumer SectorおよびVehicle Sales用Oracle BIリポジトリをアップグレードする手順について説明します。

Oracle BI Applicationsリリース7.9.4では、Pharma AnalyticsビジネスモデルとCoreビジネスモデルがマージされました。Oracle BI Applicationsリリース7.9.5では、Consumer SectorおよびVehicle Sales AnalyticsビジネスモデルとCoreビジネスモデルがマージされました。このマージにより、Oracle BIリポジトリをアップグレードするためのプロセスには、Oracle BIリポジトリをアップグレードするための標準的なプロセスとは異なる手順があります。

この章の内容は次のとおりです。

• 第G.1項「共通次元」

• 第G.2項「Siebel AnalyticsとOracle BIのリポジトリのマージ」

• 第G.3項「リポジトリファイルのマージ後における共通次元の置換」

G.1 共通次元

表G-1、表G-2および表G-3に、Pharma、Consumer SectorおよびVehicle Sales Analyticsの共通次元と、それらの状況を示します。特定の要件により、次元には他のCoreモジュールと共有しない次元もあります。

表G-1 共通のPharma Analytics次元

リリース7.9.4より前のリリースにおける次元	リリース7.9.4における次元	状況	備考
Dim - Accounts	Dim - Customer	共有される	なし
Dim - Contacts	Dim - Contact	共有される	新しい名前は単数形です。
Dim - Security Dimension	Dim - Position Security	共有される	なし
Dim - Time Period	Dim - Date	共有される	なし
Dim - Geography	Dim - Pharma Geography	共有されない	CoreにおいてPharma特有の次元を使用してください。
Dim - Geography_Account	Dim - Pharma Geography_Account	共有されない	CoreにおいてPharma特有の次元を使用してください。
Dim - Geography_Contact	Dim - Pharma Geography_Contact	共有されない	CoreにおいてPharma特有の次元を使用してください。
Dim - Products	Dim - Pharma Products	共有されない	CoreにおいてPharma特有の次元を使用してください。

表G-2 共通のConsumer Sector Analytics次元

リリース7.9.5より前のリリースにおける次元	リリース7.9.5における次元	状況	備考
Dim - Account Geography	Dim - Account Geography	共有される	なし
Dim - Accounts	Dim - Customer	共有される	なし
Dim - Accounts Hierarchy	Dim - Accounts Hierarchy	共有される	なし
Dim - Employees	Dim - Employees	共有される	なし
Dim - End Date	Dim - End Date	共有される	なし
Dim - Position Hierarchies	Dim - Position	共有される	7.9.5におけるDim - Positionでは、PositionとPosition Hierarchyの両方が組み合わされます。
Dim - Positions	Dim - Position	共有される	7.9.5におけるDim - Positionでは、PositionとPosition Hierarchyの両方が組み合わされます。
Dim - Product Categories Hierarchy	Dim - CS Product Category Hierarchy	共有されない	CoreにおいてCS特有の次元を使用してください。
Dim - Products	Dim - CS Product	共有されない	CoreにおいてCS特有の次元を使用してください。
Dim - Start Date/Date	Dim - Start Date	共有される	なし

表G-3 共通のVehicle Sales Analytics次元

リリース7.9.5より前のリリースにおける次元	リリース7.9.5における次元	状況	備考
Dim - Accounts	Dim - Customer	共有される	なし
Dim - Accounts Geography	Dim - Account Geography	共有される	なし
Dim - Contacts Geography	Dim - Person Geography	共有される	なし
Dim - Date	Dim - Date	共有される	なし
Dim - Households	Dim - Households	共有される	なし
Dim - Individuals	Dim - Contact	共有される	なし
Dim - Lease/Loan Expiry	Dim - End Date	共有される	なし
Dim - Product Hierarchy	Dim - Product Hierarchy	共有される	なし
Dim - Products	Dim - Product	共有される	なし
Dim - Vehicle	Dim - Asset	共有される	なし

G.2 Siebel AnalyticsとOracle BIのリポジトリのマージ

Pharma、Consumer SectorおよびVehicle Sales Analyticsのアップグレード・プロセスでは、以前のリリースのSiebel AnalyticsやOracle BIのリポジトリにおけるカスタマイズ内容を、現行リリースのOracle BIのリポジトリにマージする作業が必要です。このプロセスでは、Coreのアップグレード・プロセスと同じ原則に従いますが、追加の手順もいくつかあります。

この項では、Pharma Analyticsを7.9.4より前のリリースからリリース7.9.4以降にアップグレードするプロセスを例として使用します。Consumer SectorおよびVehicle Sales Analyticsを7.9.5より前のリリースからリリース7.9.5以降にアップグレードするプロセスは、Pharma Analyticsをリリース7.9.4以降にアップグレードするプロセスと同じです。

図G-1に示すように、Pharma Analyticsのアップグレード・プロセスにはフェーズが2つあります。

図G-1 Pharma Analyticsにおいてリポジトリをマージするためのフェーズ

フェーズ1

図G-1に示すように、Pharma Analyticsのアップグレード・プロセスにはフェーズが2つあります。フェーズ1では、リリース7.x用Coreベースのオリジナル・リポジトリ（現在実行しているSiebel AnalyticsやOracle BIのリリースに付属しているリポジトリ）、リリース7.x用のCoreカスタマイズ・リポジトリおよび新しいベース・リポジトリを、1つの出力リポジトリにマージします。

フェーズ2

フェーズ2では、フェーズ1の出力リポジトリを、リリース7.x用Pharma Analyticsベースのオリジナル・リポジトリとリリース7.x用のPharma Analyticsカスタマイズ・リポジトリとをマージします。フェーズ2の出力リポジトリは、PharmaリポジトリとCoreリポジトリがマージされたリポジトリで、以前のリリースからのカスタマイズ内容と新しいデータ・モデルが含まれているリポジトリです。

注意: 現在使用しているカスタマイズ・リポジトリに、CoreモデルとPharmaモデルの両方があり、Coreモデルがカスタマイズされている場合は、アップグレード・プロセスの両方のフェーズを実行する必要があります。 現在使用しているカスタマイズ・リポジトリにCoreモデルが含まれていない場合や、Coreモデルは含まれているがCoreモデルはカスタマイズされていない場合は、フェーズ2のみを実行する必要があります。 フェーズ2のみを実行する場合、Coreがマージされた新しいrpdファイル（図G-1を参照）はありません。Coreがマージされた新しいrpdファイルのかわりに、新しいベースrpdファイルを使用します。 様々なrpdファイル名の詳細は、表G-4と表G-5を参照してください。

この項に記載している作業では、複数のバージョンのSiebel AnalyticsリポジトリやOracle BIリポジトリについて言及しています。表G-4には、フェーズ1で使用しているリポジトリの名前と説明が記載されています。表G-5には、フェーズ2で使用しているリポジトリの名前と説明が記載されています。

表G-4 フェーズ1のリポジトリファイル

リポジトリファイル	説明
7x_original_Core_base.rpd	アップグレード元リリース用の標準Oracle BIリポジトリ（調整済でオリジナルのリポジトリ）です。
7x_custom_Core.rpd	リリース7.x用の調整済カスタマイズ・リポジトリ（Coreモデルのカスタマイズが含まれているリポジトリ）です。
New_base.rpd	新しい調整済リポジトリ（関連したCoreモジュールとPharmaモジュールが1つのCoreモデル（論理フォルダ）に含まれているリポジトリ）です。

表G-5 フェーズ2のリポジトリファイル

リポジトリファイル	説明
New_Core_merged.rpd	フェーズ1からの出力リポジトリです。 フェーズ1を実行しなかった場合、Coreがマージされた新しいrpdファイルのかわりに、新しいベースrpdファイルを使用します。
7x_original_Pharma_base.rpd	リリース7.x用の調整済オリジナル・リポジトリ（カスタマイズされていないPharmaモデルが含まれているリポジトリ）です。
7x_custom_Pharma.rpd	調整済カスタマイズ・リポジトリ（カスタマイズされたPharmaモデルが含まれているリポジトリ）です。
New_Core_Pharma_merged.rpd	マージされた新しい最終リポジトリ（単一のCoreモデル（論理フォルダ）が含まれているリポジトリ）で、カスタマイズされた内容がすべて含まれています。

G.2.1 作業フォルダの作成

マージ・プロセスの様々なステージを実行したら、リポジトリファイル格納用作業フォルダを使用します。

マージ・プロセス用のフォルダ（\OracleBIPharmaUpgradeなど）を作成してから、次のサブフォルダを作成します。

• Original

• AfterTrimDown

• AfterEqualize

• AfterMerge

• AfterManualWork

• AfterRegressions

G.2.2 リポジトリファイルの調整

使用している内容のみアップグレードするようにリポジトリを調整すると、アップグレード対象を限定してマージ・プロセスを単純にすることができます。

プロジェクトを抽出したり手動でリポジトリオブジェクトの数を減らすことで、リポジトリファイルを調整できます。

注意: Security Groupプロパティは、抽出されるプレゼンテーション・カタログを制御します。抽出対象のプレゼンテーション・カタログがプロジェクトに追加されても、そのプロジェクト内のいずれのグループもカタログを表示できない場合、そのカタログは、抽出済のリポジトリファイル内に表示されません。

G.2.2.1 オリジナルのベース・リポジトリファイルの調整

ビジネス要件を満たすには、オリジナルのベース・リポジトリファイルを調整する必要があります。

オリジナルのベース・リポジトリファイルを調整するには:

1. アップグレード・プロセスのフェーズ1を実行した場合、オリジナルのCore用ベース・リポジトリファイルを調整します。

2. このファイルを7x_original_Core_base.rpdの名前でAfterTrimDownサブフォルダに保存します（ファイル名の7xは、Siebel AnalyticsかOracle BIのリリース番号を示す文字にします）。

3. オリジナルのPharmaベース・リポジトリファイルを調整します。

4. このファイルを7x_original_Pharma _base.rpdの名前でAfterTrimDownサブフォルダに保存します。

G.2.2.2 新しいベース・リポジトリファイルの調整

現行リリースのOracle BI Applicationsに付属していた新しいベース・リポジトリファイルには、Coreモデル（論理フォルダ）が含まれています。これにはPharma用とCore用のリポジトリオブジェクトが格納されています。

新しいベース・リポジトリファイルを調整するには:

1. 新しいベース・リポジトリファイルを調整します。

2. このファイルをNew_base.rpdの名前でAfterTrimDownサブフォルダに保存します。

G.2.2.3 カスタマイズ・リポジトリファイルの調整

アップグレード・プロセスのフェーズ1を実行した場合、リリース7.x用Coreのカスタマイズ・リポジトリファイル（7x_custom_core.rpd）が存在することになります。このファイルには、リリース7.x用Coreベースのオリジナルの内容とカスタマイズ内容が含まれています。

また、リリース7.x用Pharmaのカスタマイズ・リポジトリファイル（7x_custom_Pharma.rpd）も存在することになります。このファイルには、リリース7.x用Pharmaベースのオリジナルの内容とカスタマイズ内容が含まれています。

これらのファイルをAfterTrimDownサブフォルダに保存します。

G.2.3 Pharmaベースのオリジナル・リポジトリファイルにおけるオブジェクト名の変更

リリース7.x用Pharmaベースのオリジナル・リポジトリファイルとリリース7.x用Pharmaベースのカスタマイズ・リポジトリファイルでは、新しいデータモデルとの互換性を実現するために、名前の変更が必要なリポジトリオブジェクトがあります。

Pharmaリポジトリファイルにおいてオブジェクト名を変更するには:

1. Server Administration Toolで、7x _original_Pharma_base.rpdファイルを開きます。

2. Business Model and Mappingレイヤーで、Business Model Pharmaの名前をCoreに変更します。

3. Physicalレイヤーで、次を実行します。

   1. Database Pharma Data Warehouseの名前をOracle Data Warehouseに変更します。

   2. Connection Poolの名前がOracle Data Warehouse Connection Poolになっていることを確認します。

   3. Catalogエントリ（Connection Poolエントリの下）の名前がCatalogになっていることを確認します。

   4. Schemaエントリ（Catalogエントリの下）の名前がdboになっていることを確認します。

4. 7x_custom_Pharma.rpdファイルを使用して、手順1〜3を繰り返します。

G.2.4 Oracle BIリポジトリの同等化

Oracle BIリポジトリにおける標準的なアップグレードの同等化プロセスでは、以前のリリースのオリジナルのベース・リポジトリを基準として使用します。このタイプの同等化は、下位同等化と呼ばれます。Pharmaアップグレードでは上位同等化と呼ばれる手法が使用されます。この手法では、現行リリースのリポジトリファイルを基準として使用して、7xベースのリポジトリファイルと7xベースのカスタマイズ・リポジトリファイルを同等化します。

同等化を実行する前に、最初に上位同等化用MAPファイルを準備する必要があります。

表G-6には、使用できるMAPファイルとファイルに関連するSiebel AnalyticsリリースやOracle BI Applicationsリリースの一覧が記載されています。

表G-6 様々なリリースに使用されるMAP名前変更ファイル

Siebel AnalyticsリリースまたはOracle Business Intelligence Applicationsリリース（DWリリースからのアップグレード）	使用されるMAP名前変更ファイル
Siebel Business Analytics Applications 7.0.x	利用できない
Siebel Business Analytics Applications 7.5.x	利用できない
Siebel Business Analytics Applications 7.7.x（リリース7.7.0より前のリリースのSiebel CRM OLTP）	Rename77-7962.map
Siebel Business Analytics Applications 7.7.x（Siebel CRM OLTPリリース7.7.0）	Rename771-7962.map
Siebel Business Analytics Applications 7.8.2、およびこのリリースより前のすべての7.8.xリリース	Rename782-7962.map
Siebel Business Analytics Applications 7.8.3、およびこのリリースより後のすべての7.8.xリリース	Rename783-7962.map
Oracle BI Applications 7.9.0	Rename79x-7962.map
Oracle BI Applications 7.9.1	Rename79x-7962.map
Oracle BI Applications 7.9.2	Rename79x-7962.map
Oracle BI Applications 7.9.3	Rename793to7962.map
Oracle BI Applications 7.9.4	Rename794to7962.map
Oracle BI Applications 7.9.5	Rename79x-7962.map
Oracle BI Applications 7.9.5.1	Rename7951to7962.map
Oracle BI Applications 7.9.5.2	Rename7951to7962.map
Oracle BI Applications 7.9.6	Rename79x-7962.map
Oracle BI Applications 7.9.6.2	利用できない

上位同等化用MAPファイルを準備するには:

1. 適切なMAPファイルをOracleBI\Upgradeフォルダからequalizerpds.exe実行用フォルダにコピーします。

   
   

   注意: MAPファイルのネーミング規則は、rename<アップグレード元リリース番号>-<アップグレード先リリース番号>.mapです。 たとえば、リリース7.8.4からリリース7.9.5にアップグレードする場合、rename784_795.mapファイルを使用する必要があります。

   
   

2. MAPファイルをExcelで開きます。

3. 「テキスト ファイル ウィザード - 1 / 3」ダイアログでデフォルト値のままにして「次へ」をクリックします。

4. 「テキスト ファイル ウィザード - 2 / 3」ダイアログで、次を実行します。

   1. 「区切り文字」領域で「タブ」チェック・ボックスが選択されていることを確認します。

   2. 「文字列の引用符」リストで、「なし」を選択します。

   3. 「次へ」をクリックします。

5. 「テキスト ファイル ウィザード - 3 / 3」ダイアログで「完了」をクリックします。

   ファイルがExcelのスプレッドシート・ウィンドウで開き、3列で表示されます。

6. 3番目の列を切り取って2番目の列として挿入することで、2番目の列と3番目の列を入れ替えます。

7. ファイルを保存します。

8. 文字列のフォーマットが正しいことを確認します。

リポジトリファイルの同等化を行うには:

1. equalizerpds.exeを実行します。

   equalizerpdsコマンドの例を次に示します。

   equalizerpds -A Administrator -B SADMIN
   -C \OracleBIPharmaUpgrade\AfterTrimDown\New_base.rpd
   -D Administrator -E SADMIN
   -F \OracleBIPharmaUpgrade\AfterTrimDown\7x_custom_Pharma.rpd
   -O \OracleBIPharmaUpgrade\AfterEqualize\7x_custom_Pharma.rpd
   -X -J rename784-795.map
   

   equalizerpds.exe実行可能ファイルが正常に実行されると、返されるエラーはありません。

2. 手順1を繰り返して、AfterTrimDownフォルダにある各ファイルをNew_base.rpdに同等化します。

3. プロセスが正常に完了したことを確認するには、リポジトリのサイズを比較します。出力リポジトリ（-O）のサイズは、同等化（-F）を行ったリポジトリのサイズに近似した値になります。

G.2.5 Coreリポジトリファイルのマージ

注意: カスタマイズ・リポジトリにCoreモデルとPharmaモデルの両方があり、Coreモデルがカスタマイズされている場合は、この項の手順を実行する必要があります。カスタマイズ・リポジトリにCoreモデルが含まれていない場合や、Coreモデルは含まれているがCoreモデルがカスタマイズされていない場合は、この項の手順を実行する必要はありません。

この項の手順では、Coreリポジトリに対して3段階でマージします。この項の手順でマージするファイルの詳細は、第G.2項「Siebel AnalyticsとOracle BIのリポジトリのマージ」を参照してください。

Coreリポジトリファイルをマージするには:

1. 7x_original_Core_base.rpd、7x_custom_Core.rpdおよびNew_base.rpdをAfterMergeフォルダにコピーします。

2. Server Administration Toolで、New_base.rpdファイルを開きます。

3. Administration Toolのメニュー・バーで、File→Mergeを選択します。

4. Select Original Repositoryダイアログで、7x_original_Core_baseを選択します。

5. パスワードを入力してから「OK」をクリックします。

6. Select for the Modified Repository fieldをクリックします。

7. Select Modified Repositoryダイアログで、7x_custom_Core.rpdを選択します。

8. Openをクリックしてパスワードを入力し、「OK」をクリックします。

9. Decisionリストで、リポジトリ変更に対応する操作を選択するか、デフォルト操作を受け入れます。

   意思決定の詳細は、第G.2.7項「Server Admin Toolにおけるマージ関連の意思決定」を参照してください。

10. Decisionフィールドが空の後続の行を検出するには、Decisionヘッダー・セルをクリックします。

    すべての行のDecisionフィールドに値が入力されると、Mergeボタンが有効になります。

11. Mergeをクリックします。

    作業しているリポジトリのサイズによっては、このプロセスの所要時間が最大40分になる場合があります。マージが完了すると、メッセージにより通知が行われます。

12. 一貫性チェックを実行する場合は、「はい」をクリックします。

    一貫性チェックで返されたエラーの数により、マージ・プロセスの実行結果を判定します。発生したエラーの数が多い場合（たとえば、300個以上）、エラーの原因を分析する必要があります。マージ・プロセスにおいて別々のオブジェクトが同等であるとの認識に失敗したとき、名前変更ファイルの編集が必要になる場合があります。また、多くのオブジェクトの名前を変更したが、アップグレード・エンジンでそれらを元のオブジェクトに関連付ける処理が失敗した場合、独自の名前変更ファイルを追加する必要が発生する場合があります。

    また、マージを再実行する前に、Decisionドロップダウン・リストで選択した操作の変更が必要になる場合もあります。これによって、手作業での対処が必要なエラーの数が減少して、時間を節約できる場合があります。

    マージの結果が満足できる水準に達しても、残りのエラーを手作業で対処する必要があります。次の手順に進む前に、すべてのエラーに対処することが重要です。このリポジトリは、次のステージの入力として使用します。

    また、カスタマイズしたオブジェクトのすべてが存在していることと、重複した物理テーブルが存在しないことも確認する必要があります。重複した物理テーブルの有無を確認するには、次のようなクエリーを使用して物理テーブルを検索します。

    where name like '*#1'
    

13. マージしたリポジトリをNew_Core_merged.rpdの名前で保存します。

G.2.6 Pharmaリポジトリファイルのマージ

この項の手順では、Pharmaリポジトリに対して3段階でマージします。この項の手順でマージするファイルの詳細は、第G.2項「Siebel AnalyticsとOracle BIのリポジトリのマージ」を参照してください。

注意: アップグレード・プロセスのフェーズ1を実行しなかった場合、New_Core_merged.rpdファイルはありません。New_Core_merged.rpdファイルのかわりに、New_new_base.rpdファイルを使用する必要があります。

Pharmaリポジトリファイルをマージするには:

1. New_Core_merged.rpd、7x_original_Pharma_base.rpdおよび7x_custom_Pharma.rpdをAfterMergeフォルダにコピーします。

2. Server Administration Toolで、New_Core_merged.rpdファイルを開きます。

3. Administration Toolのメニュー・バーで、File→Mergeを選択します。

4. Select Original Repositoryダイアログで、7x_original_Pharma_baseを選択します。

5. パスワードを入力してからOKをクリックします。

6. Select for the Modified Repository fieldをクリックします。

7. Select Modified Repositoryダイアログで、7x_custom_Pharma.rpdを選択します。

8. Openをクリックしてパスワードを入力し、OKをクリックします。

9. Decisionリストで、リポジトリ変更に対応する操作を選択するか、デフォルト操作を受け入れます。

   意思決定の詳細は、第G.2.7項「Server Admin Toolにおけるマージ関連の意思決定」を参照してください。

10. Decisionフィールドが空の後続の行を検出するには、Decisionヘッダー・セルをクリックします。

    すべての行のDecisionフィールドに値が入力されると、Mergeボタンが有効になります。

11. Mergeをクリックします。

    作業しているリポジトリのサイズによっては、このプロセスの所要時間が最大40分になる場合があります。マージが完了すると、メッセージにより通知が行われます。

12. 一貫性チェックを実行する場合は、「はい」をクリックします。

    一貫性チェックで返されたエラーの数により、マージ・プロセスの実行結果を判定します。発生したエラーの数が多い場合（たとえば、300個以上）、エラーの原因を分析する必要があります。マージ・プロセスにおいて別々のオブジェクトが同等であるとの認識に失敗したとき、名前変更ファイルの編集が必要になる場合があります。また、多くのオブジェクトの名前を変更したが、アップグレード・エンジンでそれらを元のオブジェクトに関連付ける処理が失敗した場合、独自の名前変更ファイルを追加する必要が発生する場合があります。

    また、マージを再実行する前に、Decisionドロップダウン・リストで選択した操作の変更が必要になる場合もあります。これによって、手作業での対処が必要なエラーの数が減少して、時間を節約できる場合があります。

    マージの結果が満足できる水準に達しても、残りのエラーを手作業で対処する必要があります。次の手順に進む前に、すべてのエラーに対処することが重要です。このリポジトリは、次のステージの入力として使用します。

    また、カスタマイズしたオブジェクトのすべてが存在していることと、重複した物理テーブルが存在しないことも確認する必要があります。重複した物理テーブルの有無を確認するには、次のようなクエリーを使用して物理テーブルを検索します。

    where name like '*#1'
    

13. マージしたリポジトリをNew_Core_Pharma_merged.rpdの名前で保存します。

G.2.7 Server Admin Toolにおけるマージ関連の意思決定

リポジトリオブジェクトをServer Admin Toolでマージするときに意思決定を行う際、次の事項を考慮する必要があります。

• 新しいベース・リポジトリに表示されないオブジェクトの場合、一般的にCurrentを選択する必要があります。これによって、新しいベース・リポジトリに変更が取り込まれます。

• 新しいベース・リポジトリに追加されたオブジェクトの場合、一般的にCurrentを選択する必要があります。これによって、変更が保持されます。

• オリジナルのリポジトリにおいて新しいオブジェクトで置換されたオブジェクトがある場合、古いオブジェクトを現在のリポジトリから削除して新しいオブジェクトを追加する決断が妥当である場合があります。Currentを選択すると、古いオブジェクトが置換されます。

• リポジトリに追加された新しいカスタマイズがある場合、Modifiedを選択して変更を保持します。

• カスタマイズされたリポジトリと新しいベース・リポジトリの両方でオブジェクトが変更された場合、両方が変更されていることを示す説明が表示される場合があります。その場合、Currentを選択して新しいベース・リポジトリのオブジェクトをそのまま保持するか、Modifiedを選択して、カスタマイズされたリポジトリのオブジェクトをそのまま保持します。

G.3 リポジトリファイルのマージ後における共通次元の置換

リポジトリファイルをマージしたら、事前構成済のプレゼンテーション次元テーブルとプレゼンテーションカラムは、すべて適切にマージされ、Coreモデルの新しい論理次元がソースになります。たとえば、AccountプレゼンテーションテーブルのAccount Nameは、"Core"."Dim - Customer"."Account Name"がソースとなります。また、ProductプレゼンテーションテーブルのGross Marginは、"Core"."Dim - Pharma Products"."Gross Margin"がソースとなります。

ただし、カスタマイズされたプレゼンテーションテーブルとプレゼンテーションカラムは、古い次元がソースとなる場合があります。表G-7、表G-8および表G-9に、新しいリリースで名前が変更された共通次元を示します。表G-7、表G-8および表G-9に記載されている古い次元のプレゼンテーションテーブルまたはカラムをカスタマイズした場合は、古い論理ソース・テーブルまたはテーブル・カラムを新しいもので置き換える必要があります。

問題があると思われるそれらのプレゼンテーションテーブルまたはカラムをすばやく割り当てる方法は、次のとおりです。

1. 表G-7、表G-8または表G-9に記載された古い次元名（たとえば、Dim - Accounts）を、Core論理フォルダにおいてServer Admin Toolで検索します。

2. 古い次元名を右クリックしてから、Display Related→Presentation Columnをクリックします。

3. 新しい論理次元の同じカラム（たとえば、Dim - Customer）でプレゼンテーションカラムを置換します。

4. プレゼンテーションカラムが適切に置換されたことを確認するには、Core論理次元でプレゼンテーションカラム（たとえば、Core - Accounts）を検索します。検索結果が空の場合、古い次元（たとえば、Dim - Accounts）を削除しても安全です。

7.xにおける次の共通次元は、確認して削除する必要があります。

表G-7 リリース7.9.4より前のリリースにおける共通Pharma Analytics次元の名前

リリース7.9.4より前のリリースにおける次元の名前	リリース7.9.4における次元の名前	状況	備考
Dim - Accounts	Dim - Customer	共有される	なし
Dim - Contacts	Dim - Contact	共有される	新しい名前は単数形です。
Dim - Time Period	Dim - Date	共有される	なし

表G-8 リリース7.9.5より前のリリースにおける共通Consumer Sector Analytics次元の名前

リリース7.9.5より前のリリースにおける次元の名前	リリース7.9.5における次元の名前	状況	備考
Dim - Accounts	Dim - Customer	共有される	なし
Dim - Position Hierarchies	利用できない	共有される	Dim - Position in Coreにマージされました。
Dim - Positions	Dim - Position	共有される	Dim - Positionでは、PositionとPosition Hierarchyの両方が組み合わされます。
Dim - Start Date/Date	Dim - Start Date	共有される	なし

表G-9 リリース7.9.5より前のリリースにおける共通Vehicle Sales Analytics次元の名前

リリース7.9.5より前のリリースにおける次元の名前	リリース7.9.5における次元の名前	状況	備考
Dim - Accounts	Dim - Customer	共有される	なし
Dim - Accounts Geography	Dim - Account Geography	共有される	なし
Dim - Contacts Geography	Dim - Person Geography	共有される	なし
Dim - Individuals	Dim - Contact	共有される	なし
Dim - Lease/Loan Expiry	Dim - End Date	共有される	なし
Dim - Products	Dim - Product	共有される	なし
Dim - Vehicle	Dim - Asset	共有される	なし