ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Business Intelligenceアップグレード・ガイド
11g リリース1(11.1.1.7.0)
B63034-05
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

1 Oracle BI 10gからBI 11gへのアップグレードの計画

この章では、Oracle Business Intelligence 10gシステムをOracle Business Intelligence 11gシステムに正しくアップグレードするための計画方法について説明します。項目は次のとおりです。


注意:

このドキュメントの記載内容は執筆時点において正確です。このドキュメントは、ソフトウェアのリリース後に定期的に更新されます。このドキュメントの最新情報および追加情報は、次のOracle Technology Networkサイトを参照してください。

http://www.oracle.com/technetwork/indexes/documentation/index.html


1.1 Oracle Business Intelligenceのアップグレードおよびパッチ適用のプロセスについて

Oracle Business Intelligenceの新たなリリースを検討する際、アップグレードを実行するか、パッチセット、バンドルパッチもしくは個別パッチを適用するかにより、必要となるツールやドキュメントは異なります。

パッチ適用とアップグレードの相違点の詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』のインストール、パッチ適用およびアップグレードの用語に関する項を参照してください

特にSiebel Analytics 7.8以降のOracle Business Intelligenceについて、あるリリースから別のリリースに移行するために必要な手順を図1-1に示します。

図1-1 Oracle Business Intelligence 11gのアップグレードおよびパッチ適用のプロセス

図1-1の説明が続きます
「図1-1 Oracle Business Intelligence 11gのアップグレードおよびパッチ適用のプロセス」の説明

図1-1に示した各操作の詳細は、次を参照してください。

1.2 BIアップグレード戦略の作成

Oracle Business Intelligence 10gシステムをOracle Business Intelligence 11gにアップグレードするには、注意深く準備、計画およびテストを行う必要があります。Oracleでは大部分のアップグレード・プロセスを自動化するツールおよびテクノロジを提供しています。ただし、採用する厳密な戦略は、既存の10gシステムの構成、およびアップグレードされる11gシステムの必要な構成によって異なります。

重要なポイントは、本番環境の10gシステムはアップグレード・プロセスに影響されないということです。既存の10gシステムは、11gシステムのロールアウトの準備ができるまで使用し続けることができます。

効率的なアップグレード戦略を作成するために、次の手順を実行することをお薦めします。

最終的に決定したアップグレード戦略は、たいてい使用している環境に固有になります。重要なポイントの1つは、システムの最適化です。最適化には、不要なコンテンツ、重複するコンテンツ、使用されてないコンテンツの削除が含まれます。また、類似のコンテンツのマージおよび連結やパフォーマンス最適化が最適化に含まれる場合もあります。10gのデプロイの最適化が貧弱だと、11gでさらにそれが悪化するため、アップグレード・アシスタントの作業が本来の処理より煩雑になる場合があります。

アップグレード戦略の適切性を判断する際に、次の2つの例が有用です。ただし、これらは単なる例にすぎません。このほかにも様々な戦略が考えられ、選択する戦略は、固有のトポロジや組織の要件によって異なります。

例1   Oracle BI 10gシステムの11gへのアップグレード - アップグレード前に実行する最適化

この例では、既存のシステムを分析した結果、不要なリクエストと不正なユーザーが多数存在することが判明しています。その場合の最も有効的なアップグレード戦略は、アップグレードする前に既存の10gシステムを最適化するということです。一般的には、次の手順に従ってそのような戦略を実装します。

  1. 本番のOracle Business Intelligence 10gシステムを10gテスト環境にコピーします。

  2. 10gテスト環境で、Oracle Business Intelligence 10gシステムをアップグレードできるように最適化します。

  3. 新しいテスト環境で、Oracle Business Intelligence 11gをインストールします。

  4. 新しい11gテスト環境で、11gアップグレード・アシスタントを実行して、インポートおよびアップグレードするシステムとして10gテスト環境の10gシステムを指定します。

  5. 11gテスト環境で、新しい11gシステムのアップグレード後の手順をすべて実行します。

  6. 11gテスト環境で、新しい11gシステムが想定どおりに実行されるかテストし、必要に応じて、アップグレード後の追加構成を実行します。

  7. システムを11gテスト環境から11g本番環境へ移行します。

この例のアップグレード戦略を、図1-2「アップグレード戦略の例: BI 10gシステムの11gへのアップグレード: アップグレード前に実行する最適化」に示します。

図1-2 アップグレード戦略の例: BI 10gシステムの11gへのアップグレード: アップグレード前に実行する最適化

図1-2については周囲のテキストで説明しています。
例2   Oracle BI 10gシステムの11gへのアップグレード - アップグレード後に実行する最適化

この例では、既存のシステムを分析した結果、システムはすでに最適化されていることが判明しています。その場合の最も効果的なアップグレード戦略は、まず既存の10gシステムをアップグレードしてから、11gシステムの最適化を実行した後、本番環境に移行します。一般的には、次の手順に従ってそのような戦略を実装します。

  1. 新しいテスト環境で、Oracle Business Intelligence 11gをインストールします。

  2. 新しい11gテスト環境で、11gアップグレード・アシスタントを実行して、インポートおよびアップグレードするシステムとして10g本番環境の10gシステムを指定します。

  3. 11gテスト環境で、新しい11gシステムのアップグレード後の手順をすべて実行します。

  4. 11gテスト環境で、新しい11gシステムを最適化します。

  5. 11gテスト環境で、新しい11gシステムが想定どおりに実行されるかテストし、必要に応じて、アップグレード後の追加構成を実行します。

  6. システムを11gテスト環境から11g本番環境へ移行します。

この例のアップグレード戦略を、図1-3「BI 10gシステムの11gへのアップグレード - アップグレード後に実行する最適化」に示します。

図1-3 BI 10gシステムの11gへのアップグレード - アップグレード後に実行する最適化

図1-3については周囲のテキストで説明しています。

1.2.1 ステップ1: アップグレードの準備段階における既存の10gシステムの分析および最適化

既存のOracle BI 10gシステムをアップグレードするには、時間とリソースが必要です。そのため、既存の10gシステムを分析して、アップグレードを実行する前に、不要なコンテンツ、重複するコンテンツおよび使用されていないコンテンツを削除して、既存のシステムを最適化することをお薦めします。

既存の10gシステムを分析する場合、現在稼働しているハードウェアおよびオペレーティング・システム環境を考慮してください。ハードウェアおよびソフトウェア要件、プラットフォーム、データベースなどのシステム要件および動作保証に関するドキュメントを参照して、それらと現在の環境を比較します。場合によっては、11gで要件が変更されていることがあります。たとえば、Oracle BI 11gで異なるバージョンのオペレーティング・システムが必要になる場合があります。詳細は、次を参照してください。


注意:

アップグレード・プロセスの一部で、プラットフォームまたはアーキテクチャを変更しないでください。

たとえば、既存の10gシステムが32ビットのWindowsプラットフォームで稼働している場合、Oracle BI 11gを64ビットのLinuxプラットフォームにインストールし、64ビットのLinuxのアップグレード・アシスタントを実行して既存の10gシステムをアップグレードしないでください。

同じプラットフォームおよびアーキテクチャ上で要件を満たすために、Oracle BI 11gを既存の10gシステムと同じハードウェアにインストールすることができます。ただし、10gと11gのリリースの共存は、本番環境には適切ではありません。このような共存環境では、十分なハードウェア・リソースを使用できる必要があり、ポート管理を注意深く行う必要があります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』を参照してください。


既存の10gシステムの分析の一環として、関連する次の詳細情報をすべて記録します。

  • リポジトリの名前およびサイズ

  • Oracle BI Presentation Catalogの名前およびサイズ

  • 既存のセキュリティ・モデルの詳細

  • データソース

  • スケジュールされたジョブの数

  • 外部システムへのすべてのリンク

アップグレードする前に10gシステムを最適化することで、次のようになります。

  • アップグレード・プロセスがより速く確実に実行されます。

  • アップグレードされたシステムのテストにより多くの時間をかけることができます。

  • 新しくアップグレードされた11gシステムは、効率的に動作します。

既存の10gシステムのアップグレードを準備する際に最適化するには、次のタスクを実行します。

  • 整合性チェッカを実行して10gリポジトリの妥当性をチェックし、問合せの失敗の原因となりうる文法またはセマンティック上のエラーおよび警告を特定および修正します。

  • 使用されていない初期化ブロックをすべて削除します。

  • 不要になったためアップグレードする必要がなくなったユーザーおよびグループを特定して削除します。

  • ダッシュボードおよび分析プロンプトで使用される日付形式をカスタムで指定している場合、日付形式に関する問題について説明されている次の2つのSupport Tech Noteに使用する形式が準拠していることを確認してください。

    https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1108451.1

    https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1108594.1

    これらのNoteには、10g環境で使用される正しい形式の仕様に関する重要な情報が記載されています。これらのNoteの指示に従って、日付形式を使用するプロンプトが正しくアップグレードされるようにします。

  • 不要になったためにアップグレードする必要がなくなったリポジトリおよびOracle BI Presentation Catalogのオブジェクトを特定して削除します。

    Oracle BI Server使用状況トラッキング機能を使用している場合は、使用状況トラッキング・データを確認して、使用されていないオブジェクトを特定します。使用状況トラッキングを使用しておらず、すぐにアップグレードを行う予定がない場合は、データをアップグレード前に明確に把握しておく手段として、使用状況トラッキングの有効化を検討してください。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の使用状況トラッキングを参照してください。

    Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のカタログの検証に関する項の説明にあるように、検証機能を使用してカタログをクリーンします。

1.2.2 ステップ2: アップグレードの対象とそのアップグレード方法について

Oracle BI 11gでは、既存の機能の多くが強化されています。場合によっては、これらの機能強化で以前の機能を置き換えたり、様々な方法でそれを再実装しています。

以前の10gの機能は、可能なかぎり対応する(かつ多くの場合、機能強化された)11g機能にアップグレードされます。表示や動作が異なる場合もありますが、最終的な結果は機能的に同じことが期待できます。

効率的なアップグレード方針では、元の10gシステムの外観および動作を、アップグレードされたシステムで正確に再現しようとはしません。正確に再現させようとすると、時間がかかり、場合によっては(不可能でなくても)非常に困難になることがあります。たとえば、既存のダッシュボードおよびプロンプトは11gでは異なる方法でレンダリングされ、10gの外観を再作成するには、大量の人手の介入が必要になります。10gの外観および動作を正確に再現しようとすると、そもそものアップグレードの原理が損なわれることもあります。つまり、11gに導入された拡張機能が利用できなくなります。

そのため、何をどのようにアップグレードするかを理解することは非常に重要になります。詳細は、次の項を参照してください。

スキン、カスタマイズされたJavaScriptファイル、および構成ファイルなどの一部の要素は自動的にはアップグレードされないので注意してください。

1.2.3 ステップ3: アップグレードを検証するテスト計画の定義

何をどのようにアップグレードするかを理解したら、10gシステムが想定どおりにアップグレードされたかを検証するためのテスト計画を定義します。

一般的には、テスト計画で次を特定します。

  • テスト・アップグレードとして使用する既存の10gシステムの代理サブセット。

  • テスト・アップグレードが正常に終了したかを検証する際に使用するキー・インジケータの数。

  • 完全アップグレードが正常に終了したかを検証する際に使用する追加のキー・インジケータ。


重要:

アップグレードの成否の確認に使用するキー・インジケータを特定する場合、アップグレードされたシステムの外観および動作は元の10gシステムと異なる場合があるので注意してください。そのため、アップグレードされたシステムと10gシステムの違いを見いだすよりも、検証作業によりアップグレードの前後で機能的に等しいことを確認することに専念することの方が重要になります。

11gへのアップグレード後に予想される外観の違いの例については、第1.4.2項「Oracle BI Presentation Catalog: その他のアップグレードの考慮事項」を参照してください。


定義するテスト計画は、使用する状況に固有になります。次の例は有用であることは明らかですが、単なる例にすぎません。最終的に決定するテスト計画は、多くの場合異なるものになります。

例1   テスト計画の例

この例では、アップグレード・アシスタントを使用して、段階的に既存の10gシステムをアップグレードしています。各段階でアップグレード・アシスタントを実行した後に、システムのアップグレードされた部分を検証し、手動で追加手順を実行します。

表1-1 アップグレード・テスト計画の例

ステージ 説明 検証手順 手動手順

ステージ1

アップグレード・アシスタントを実行して、10gのスケジューラ・スキーマを11gにアップグレードします。

  1. iBots(エージェント)が正しく11gにアップグレードされていることを確認します。

  2. エージェントが新しい11gスキーマに対して実行されていることを確認します。

  3. エージェントが適切な権限でアップグレードされていることを確認します。

  1. 必要に応じて、アップグレードされたエージェントのスケジュールおよび権限を手動で設定します。

ステージ2

データソース接続を再構成します。

  1. Oracle BI Serverがすべてのバックエンド・データソースに接続できることを確認します。

  1. Oracle Databaseの場合、ORACLE_HOME/network/adminにtnsnames.oraファイルがあることを確認します。

  2. Essbaseの場合、ORACLE_HOME/clients/epm/Essbase/EssbaseRTCでOracle BI EE 11gにバンドルされている推奨のクライアント・バージョン(11.1.2.x)が使用されていることを確認します。

  3. Windows上のTeradataの場合、必要なTeradata変数がopmn.xmlに追加されていることを確認します。詳細は、Oracle Fusion Middlewareのリリース・ノートを参照してください。

11gのデータソースへの接続設定の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。

ステージ3

アップグレード・アシスタントを実行して、10gリポジトリをアップグレードします。

  1. リポジトリの整合性を検証します。

  2. リポジトリに、正しい結合、列および変数があることを確認します。

  1. 手動で整合性エラーを修正します。

  2. 手動でリポジトリのその他のエラーを修正します。

  3. 11gリポジトリの接続プールを手動で構成します。

ステージ4

アップグレード・アシスタントを実行して、10g Oracle BI Presentation Catalogをアップグレードします。

  1. カタログ・アップグレード・ログに記録されたエラーを検証します。

  2. カタログの分析およびダッシュボード・ページを検証します。

  1. 手動で分析、プロンプト、ダッシュボードを修正します。

ステージ5

アップグレード・アシスタントを実行して、BI Publisher 10gカタログを11gにアップグレードします。

  1. アップグレードされたBI Publisherレポートを検証します。

  1. アップグレードされたリポジトリのxmlp-server-config.xmlファイルに11gのBIサーバーおよびプレゼンテーション・サービスの正しいコンピュータ名があることを確認します。このファイルで、10gのセキュリティ・モデルを「BIサーバー」と指定している場合、10gからアップグレードされた後もBIサーバーおよびプレゼンテーション・サービスの名前は保持されます。

    xmlp-server-config.xmlファイルは、アップグレードされたリポジトリのAdmin\Configurationフォルダにあります。BI_SERVER_SECURITY_URLおよびSAW_SERVERのコンピュータ名を変更します。

ステージ6

アップグレード・アシスタントを実行して、BI Publisher 10g Schedulerを11gにアップグレードします。

  1. スケジュールされたレポートが正しく機能しているかを検証します。

なし


1.2.4 ステップ4: 既存の10gシステムの代理サブセットのテスト・アップグレードの実行

テスト・アップグレードを実行することで、次の処理を行います。

  • 既存の10gシステムのアップグレードが成功する可能性が高いかを迅速に検証します。

  • 既存の10gシステムとアップグレードされた11gシステム間で発生しうる差異を詳細に検証します。

テスト・アップグレードを極力効率的に実行するために、次の処理を行います。


ヒント:

10gに付属のSample SalesアプリケーションまたはPaintアプリケーションで、アップグレード・プロセスをテストできます。このアップグレードにより、限定的なサンプルでそのプロセスを学習できます。


第5章「Oracle Business Intelligence Enterprise Editionのアップグレード」の指示に従って、テスト・アップグレードを実行します。要約すると、次のような処理を実行します。

  1. Oracle Business Intelligence 11gソフトウェアをインストールします。

  2. 新しい11gシステムで、アップグレード・アシスタントを実行します。

    アップグレード・アシスタントは、既存の10gリポジトリ・ファイルおよびOracle BI Presentation Catalogから新しい11gシステムにメタデータをインポートして、必要に応じて、それが11g環境で機能するようにアップグレードします。

  3. スケジューラ・スキーマをアップグレードします。

  4. インストール後の手順を実行します。

アップグレード・プロセスが完了した後も、10gシステムはそのまま残ります。

前に作成したテスト計画を使用して、テスト・アップグレード・プロセスが正常に完了し、アップグレードされたシステムが想定どおりに要件を満たしていることを確認します。

前に説明しているように、アップグレードされたシステムの外観および動作は元の10gシステムと異なる場合があるので注意してください。そのため、アップグレードされたシステムと10gシステムの違いを見いだすよりも、検証作業によりアップグレードの前後で機能的に等しいことを確認することに専念することの方が重要になります。

テストにより、外観の違い以外に、元の10gシステムとアップグレードされた11gシステムとの間で重大と考えられる差異が明らかになることがあります。その場合、アップグレードの内容とその理由を再確認することをお薦めします。詳細は、「ステップ2: アップグレードの対象とそのアップグレード方法について」を参照してください。

テスト・アップグレードでは、アップグレード・プロセスの検証のほかに、11gで追加または強化された機能の一部をテストできる理想の環境を提供します。目的の新しい機能の詳細は、次の各項を参照してください。

1.2.5 ステップ5: 実際のアップグレードの実行

テスト・アップグレードを実行して、アップグレードされたシステムが要件を満たされていたら、続けてOracle BI 10gシステム全体の完全アップグレードを実行できます。

第5章「Oracle Business Intelligence Enterprise Editionのアップグレード」の指示に従って、完全アップグレードを実行します。要約すると、次のような処理を実行します。

  1. Oracle Business Intelligence 11gソフトウェアをインストールします。

  2. 新しい11gシステムで、アップグレード・アシスタントを実行します。

    アップグレード・アシスタントは、既存の10gリポジトリ・ファイルおよびOracle BI Presentation Catalogから新しい11gシステムにメタデータをインポートして、必要に応じて、それが11g環境で機能するようにアップグレードします。

  3. スケジューラ・スキーマをアップグレードします。

  4. インストール後の手順を実行します。

アップグレード・プロセスが完了した後も、10gシステムはそのまま残ります。

完全アップグレードを実行したら、前に作成したテスト計画を使用して、アップグレード・プロセスが正常に完了し、アップグレードされたシステムが想定どおりに要件を満たしていることを確認します。

前に説明しているように、アップグレードされたシステムの外観および動作は元の10gシステムと異なる場合があるので注意してください。そのため、アップグレードされたシステムと10gシステムの違いを見いだすよりも、検証作業によりアップグレードの前後で機能的に等しいことを確認することに専念することの方が重要になります。

テストにより、外観の違い以外に、元の10gシステムとアップグレードされた11gシステムとの間で重大と考えられる差異が明らかになることがあります。その場合、アップグレードの内容とその理由を再確認することをお薦めします。詳細は、「ステップ2: アップグレードの対象とそのアップグレード方法について」を参照してください。

完全アップグレード・プロセスを検証したら、使用する予定の11gの追加機能および拡張機能を実装できます。

1.2.6 ステップ6: 11gの新機能および拡張機能の実装

アップグレードされた11gシステムと元の10gシステムは、機能的に等しくても、外観および動作が異なる場合があります。

多くの場合、既存の10gの機能は、アップグレード時に11gで導入された同等の機能を使用して再実装されます。ただし、アップグレード・プロセスでは、元の10gに存在していた機能のみをアップグレードします。11gで導入された新しい機能を使用して11gシステムを改善するように示唆することは特にはしません。

11gの新しい機能を使用してアップグレードされたシステムの向上を確認するには、次の項を参照してください。

1.3 リポジトリ・メタデータのアップグレードについて

Oracle BI EE 11gで作業する前に、Oracle BI EE 11gリポジトリ・ファイルをアップグレードする必要があります。アップグレード・プロセス時に、アップグレード・アシスタントを使用して、リポジトリ・ファイルをアップグレードします。

ただし、アップグレード・アシスタントを実行する前に、特に注意する必要がある領域が多数あります。詳細は、第1.3.1項「リポジトリ・メタデータ: 主なアップグレードの考慮事項」を参照してください。

第1.3.1項で説明されている主なアップグレードの考慮事項のほかに、リポジトリ・メタデータのアップグレードを計画する際に考慮する必要がある要素は多数あります。詳細は、第1.3.2項「リポジトリ・メタデータ: その他のアップグレードの考慮事項」を参照してください。

元の10gシステムとアップグレードされた11gシステムとでは様々な点が変更されています。また、Oracle BI 11gには新しい機能も多数導入されているため、アップグレードされたシステムでこれらの機能の実装を検討してみてもよいでしょう。詳細は、第1.3.3項「BIリポジトリ・メタデータ: 11gの注目の新機能」を参照してください。

1.3.1 リポジトリ・メタデータ: 主なアップグレードの考慮事項

この項では、Oracle BIリポジトリ・メタデータに関するアップグレードの考慮事項について説明します。内容は次のとおりです。

1.3.1.1 強化されたリポジトリの整合性チェック

10gでは、整合性チェッカを通っていながら実行時に想定外の問合せの動作を引き起こしたり、MUDチェックアウト時に整合性がとれなくなるモデリング構造がいくつかありました。11gでは、整合性チェック・マネージャはリポジトリの一貫性の確認に役立つ追加の検証ルールを実施することでこの問題に対処しています。さらに、以前のリリースで存在していたいくつかのルールは整合性チェック時に表示できるようになりました。次の表に、それらのルールの要約を示します。

検証ルールの例 タイプ 説明

[14031] 論理表FACT_TABLE_NAMEのソースの索引フィルタは、複数のディメンションを参照します。

エラー

特定の論理表に複数のディメンションを参照するWHERE句フィルタを含む論理表ソースがあります。複数のディメンションを含むWHERE句は無効です。

[38126] 'Logical Table' '"Technology - WFA"."Fact WFA WO "'の名前の先頭または末尾にスペースがあります。

エラー

オブジェクト名の先頭または末尾にスペースがあります。

リポジトリ・オブジェクト名の先頭または末尾をスペースにすることはできなくなりました。オブジェクト名の先頭または末尾にスペースがあると、問合せまたはレポートで問題が発生する場合があります。

[38012] 論理列DIM_Start_Date.YEAR_QUARTER_NBRには物理データ型のマッピングがなく、派生列でもありません。

[38001] 論理列DIM_Start_Date.YEAR_QUARTER_NBRに物理データ・ソースのマッピングが含まれていません。

エラー

いずれの論理表ソースにもマップされていない論理列は、論理表ソース・マッピングが無効であり問合せの失敗の原因となるため、整合性エラーとしてレポートされます。

両方の特定の検証ルールは、同じ問題に関連しています。

[39028] データベース'MyDB'の機能がデフォルトと一致しません。この結果、問合せ問題が発生する可能性があります。

警告

一部のデータベース機能のデフォルトは、Oracle BI EE 11gで変更されました。機能セットに特定のカスタマイズがなければ、データベース機能を新しいデフォルトにリセットすることをお薦めします。

[39003] 列DIM_Offer_End_Date.CREATE_DTの機能依存結合が見つかりません。

警告

この警告は、特定の列が無効な論理表ソースにマップされていることを示しています。デフォルトの動作が不適切な場合、警告によってこの問題についてリポジトリ開発者に注意しています。

[39055] ファクト表"HR"."FACT - HC Budget"は論理ディメンション"HR"."DIM - HR EmployeeDim"の表と結合していません。これにより、プロジェクトの抽出時に問題が発生します。

警告

この警告は、特定のファクトとディメンション・ソースの間に物理結合があるものの、ファクト表とディメンション表の間に相応の論理結合がないことを示しています。

[39059] 論理ディメンション表MY_DIMのレベルDailyに、上位レベルのファクト・ソースMY_FACT_SUM.MTHLY_SUMと結合するソースMY_DIM_DAILYがあります

警告

このファクト論理表ソースにこのディメンションで設定された集計のマス目がありますが、このディメンションの論理表ソースに接続する結合が見つかりませんでした(または潜在的に不正な結合が見つかりました)。

これは、結合が存在しないか、存在しているが高レベルのファクト・ソースと低レベル次元ソースを接続しているため、潜在的に不正であることを意味します。このような結合は、実行すると問合せの回答でダブル・カウントが発生する可能性があるため、潜在的に不正になります。

たとえば、「Select year, yearlySales」という問合せについて考えます。monthTable表とyearlySales表との間にyearIdでの結合が存在していても、この結合により結果が12の倍数(各年の月数)に増加するため、これを使用しないでください。

アップグレード後に39059警告が発生したら、結合が仕様どおりに機能しているか、および結果が不正にダブル・カウントされていないかどうかを確認します。結合が仕様どおりであれば、39059警告は無視してください。

[39054] ファクト表"Sales - STAR"."Fact - STAR Statistics"は論理ディメンション表"Sales - STAR"."Dim - Plan"と結合していません。これにより、プロジェクトの抽出時に問題が発生します。

警告

この警告は、ファクト表の論理表ソースの集計コンテンツ・フィルタ「Group by Level」が、そのファクト表に結合されていない論理ディメンション表を参照していることを意味します。ファクト表がextract/MUDプロセスで抽出されない場合、結合されていないディメンションは抽出されません。その場合、抽出される論理表ソースの集計コンテンツは、元の論理表ソースと同じにはなりません。

[39057] 論理表ソース""HR"."Dim - Schedule"."SCH_DEFN""には、列マッピングまたは式で使用されていない物理表がマップされています。

警告

この警告は、特定の論理表ソースにマッピングで使用されていない無関係の表が追加されていることを示しています。この状況でエラーが発生することはありません。


前の表で説明した検証ルールのほかに、次の点に注意してください。

  • 整合性チェック・マネージャでは、同じ接続プールが問合せと初期化ブロックの両方に使用されている場合、警告を発行するようになりました。この構成はお薦めしません。そのかわりに、初期化ブロックに専用の接続プールを作成します。そうしないと、問合せのパフォーマンスが低下したり、認証の初期化ブロックを実行できずにユーザー・ログインがハングする可能性があります。これらの警告は、次のように表示されます。

    [39062] Initialization Block 'Authorization' uses Connection Pool '"My_DB".
    "My_CP"' which is used for report queries. This may impact query performance.
    
  • 無効なオブジェクトは、整合性チェック時に削除されるようになりました。この動作により、論理表ソースおよび論理列で式およびフィルタが削除されてしまうことがあります。不正な参照は、物理レイヤーでオブジェクトが削除され、ビジネス・モデルおよびマッピング・レイヤー・オブジェクトで参照が正しく考慮されていないときに発生する可能性があります。

1.3.1.2 Oracle BI Server問合せの変更

この項では、Oracle BI Serverの問合せに対する変更について説明します。

1.3.1.2.1 整数の除算

整数の除算では、次の点に注意してください。

  • 10gでの2つの整数を使用した除算の動作は、式が内部で評価されたか、またはANSI標準の整数の除算に準拠したデータソースに送信されたかどうかによって、整合性がありませんでした。

    • Microsoft SQL Serverに送信されるか、内部で評価された場合(問合せがOracle BI Server結果キャッシュから返された場合など)、7/2は3になりました。

    • Oracle Databaseに送信されると、7/2は3.5でした。

  • 11gでの2つの整数による除算は、Oracle Databaseに除算が送信されても、常に整数値になります(結果は切り捨てられます)。小数の除算が必要な場合は、付録B「アップグレード後に予想されるOracle BI Enterprise Editionの外観と動作の変化」の指示に従って、値をキャストします。

1.3.1.2.2 10gでのダブル・カウントを引き起こす不正な結合

結合では、次の点に注意してください。

  • 10gのOracle BI Serverでは、ファクト論理表ソース(Monthレベルなど)と低レベルのディメンション論理表ソース(Dayレベルなど)との結合が可能でした。通常、このように結合すると、ダブル・カウントが発生します。

  • 11gでは、ファクト論理表ソースが低レベルのディメンション論理表ソースと結合して潜在的に不正な結合になると、新しい整合性チェックで警告(39059)が表示されます。アップグレード後に39059警告が表示されたら、結合が仕様どおりに行われ不正にダブル・カウントされていないかどうかを確認してください。結合が仕様どおりであれば、39059警告は無視してください。

1.3.1.2.3 月と日の名前が大文字/小文字混在で返される

Oracle BI EE 11g(11.1.1.7)以降では、デフォルトで月と日の名前が大文字/小文字混在で返されます。月や日の名前が大文字で返されることを想定している既存の式がある場合は、式を調整するか、NQSConfig.INIのパラメータUSE_UPPERCASE_MONTH_NAMESおよびUSE_UPPERCASE_DAY_NAMESYESに設定する必要があります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のNQSConfig.INIファイルの構成設定に関する項を参照してください。

1.3.1.2.4 EVALUATEデータベース分析関数を含む分析のアップグレード

システム・セキュリティを保つため、次のデータベース分析関数を使用する分析の機能はデフォルトで無効になっています。

  • EVALUATE

  • EVALUATE_ANALYTIC

  • EVALUATE_AGGR

  • EVALUATE_PREDICATE

これらの関数の使用は、NQSConfig.INIファイルのEVALUATE_SUPPORT_LEVELパラメータの設定で管理されています。

10gシステムでは、以前はOracle BI Answersでこれらの関数が使用可能でしたが、がアップグレード時(または以前の11gシステムからの移行時)には、EVALUATE_SUPPORT_LEVELパラメータをNQSConfig.INIファイルに手動で追加し、パラメータを適切に設定する必要があります。EVALUATE_SUPPORT_LEVELパラメータの設定の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のNQSConfig.INIファイルの構成設定に関する項を参照してください。

次の点に注意してください。

  • NQSConfig.INIのEVALUATE_SUPPORT_LEVELパラメータは、分析内でのデータベース関数のEVALUATEファミリの使用を制御します。分析内でこれらの関数が使用されないように、EVALUATE_SUPPORT_LEVELはデフォルト値の0のままにすることをお薦めします。EVALUATE_SUPPORT_LEVELの値を1または2にすると、ユーザーが分析エディタを使用して任意でSQL式を分析に挿入できるようになるため、データ・アクセスのセキュリティに問題が生じる可能性があります。EVALUATE_SUPPORT_LEVELパラメータの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。

  • NQSConfig.INIのEVALUATE_SUPPORT_LEVELパラメータは、メタデータ・リポジトリ内でデータベース関数のEVALUATEファミリの使用を制御しません。

1.3.2 リポジトリ・メタデータ: その他のアップグレードの考慮事項

リポジトリをアップグレードする際は、次の考慮事項に注意してください。

1.3.2.1 Oracle BI 11gでのFusion Middleware Controlの使用に関する変更

Oracle BI 11gでのFusion Middleware Controlの使用に関して、次の変更点があるので注意してください。

  • デフォルトの公開リポジトリを含め、リポジトリの開発に影響する多くの構成設定は、Fusion Middleware Controlで一元管理されるようになりました。これらの構成設定は、NQSConfig.INIで手動で変更することはできなくなります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。

  • オンライン・モードで管理ツールを使用してOracle BI Serverを再起動することはできなくなります。かわりに、Fusion Middleware Controlを使用してOracle BI Serverやその他のシステム・コンポーネントを再起動できます。

    また、BIシステム管理APIを使用して、プログラムによってOracle BI EEを起動および停止することもできます。

    詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceの起動と停止に関する項およびBIシステム管理APIを使用したOracle Business Intelligenceの起動と停止に関する項を参照してください。

1.3.2.2 セキュリティに関する変更

Oracle BI 11gでは、セキュリティに関して次の変更点があるので注意してください。

  • 次のセキュリティ関連の変更点に注意してください。

    • リポジトリは、リポジトリ固有のパスワードを使用してリポジトリ・コンテンツを暗号化します。リポジトリ・パスワードは、Oracle BI Serverがパスワードを取得してリポジトリをロードできるように、Fusion Middleware Controlでリポジトリを公開するときに、外部資格証明ストアに保存されます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のリポジトリ・パスワードの変更に関する項を参照してください。

      11gでは、リポジトリ・パスワードを空にすることはできません。

    • リポジトリにはオブジェクトとしてのグループがなくなりました。かわりに、ユーザーが属するアプリケーション・ロールに基づいて、データ・アクセス・セキュリティを実装します。

      アプリケーション・ロールは、外部ポリシー・ストアで管理されます。アプリケーション・ロール・オブジェクトはリポジトリに存在しますが、これらのオブジェクトは外部で管理されるロールへのポインタ(参照)になります。

    • ユーザーは外部認証プロバイダで管理され、リポジトリで管理されることはなくなりました。ユーザー・オブジェクトはリポジトリに存在しますが、これらのオブジェクトは外部で管理されるユーザーへのポインタ(参照)になります。

    これらを含めたセキュリティの変更の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。また、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のデータ・アクセス・セキュリティのリポジトリ・オブジェクトへの適用に関する項も参照してください。

1.3.2.3 ODBC DSNに関する変更

Oracle BI ServerのデフォルトのODBC DSNの接続パラメータはFusion Middleware Controlで一元管理され、手動で変更できなくなりました。

また、Oracle BI EEはデフォルトではクラスタ化された構成でデプロイされるようになりました。そのため、Oracle BI ServerのデフォルトのODBC DSNは、Oracle BI Serverではなく、クラスタ・コントローラを指しています。

Oracle BI ServerのODBC DSNの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイド』の他のクライアントとOracle Business Intelligenceとの統合に関する項を参照してください。

1.3.2.4 稼働中のシステムへの依存性に関する変更

Oracle BI EE 11gには、稼働中のシステムに対して、次のような追加的な依存性があります。

  • インストール時に指定されたリレーショナル・データベースが稼働している必要があります。このデータベースには、リポジトリ作成ユーティリティ(RCU)を使用してロードされた必要なOracle BI EEスキーマが格納されます。

  • 11gのインストール時に簡易インストール・オプションを選択した場合、Oracle WebLogic Serverで管理サーバーを実行してから、アップグレード・アシスタントを起動する必要があります。エンタープライズ・インストール・オプションを選択した場合は、アップグレード・アシスタントを起動する前に管理サーバーおよびいずれかの管理対象サーバーが稼働している必要があります。

1.3.2.5 コマンドライン・ユーティリティの実行に関する変更

任意のOracle BI Serverコマンドライン・ユーティリティを実行する前に、bi-init.cmd(UNIXの場合はbi-init.sh)を実行して、Oracleインスタンスに対して初期化されるコマンド・プロンプトまたはシェル・ウィンドウを起動する必要があります。

このユーティリティは次の場所にあります。

ORACLE_INSTANCE/bifoundation/OracleBIApplication/coreapplication/setup

詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のbi-initの実行によってOracleインスタンスに対して初期化されるシェル・ウィンドウの起動に関する項を参照してください。

1.3.2.6 データソースの接続性に関する変更

この項では、11gでのデータソースの接続性に対する変更について説明します。

Oracle Databaseデータソースの設定: Oracle Databaseデータソースの接続プールのネット・サービス名を使用する場合、Oracle BI Serverでエントリを特定できるように、Oracle BI EE環境内の次の場所でtnsnames.oraファイルを設定する必要があります。

ORACLE_HOME/network/admin

Essbaseデータソースの設定: 11gでEssbaseとの接続に推奨されるクライアントのバージョンは、次のディレクトリのOracle BI EEにバンドルされた11.1.2.xクライアントです。

ORACLE_HOME/clients/epm/Essbase/EssbaseRTC

管理ツールに接続するためのbi-init.cmdでのEssbase変数の追加などの追加手順の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。

Teradataデータソースの設定: WindowsでTeradataに接続する場合、opmn.xmlを編集して必要なTeradata変数を含める必要があります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。

1.3.2.7 管理ツールの変更

Oracle BI 11gでは、管理ツールに関して次の変更点があるので注意してください。

  • 管理ツールは、リポジトリ・ファイルをダブルクリックして開くことができなくなりました。そのように開くと、Oracleインスタンスに対して管理ツール・ウィンドウは初期化されず、セッションの後半でエラーが発生します。そのかわりに管理ツールは、必ず「スタート」メニューから開くか、コマンドラインでbi-init.cmdを使用して起動します。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』の管理ツールの起動に関する項を参照してください。

  • 物理モデルおよびビジネス・モデルのダイアグラムでは、結合の「一」の方に矢印がある線で表されます。以前のリリースでは、結合の「多」の方にカラスの足跡のような形を使用した線で表していました。

    たとえば、以前のリリースのダイアグラムで示されていた結合を次の図に示します。

    ダイアグラムでカラスの足跡で表された結合(古いリリース)

    11gリリース1では、この結合が次のように表されます。

    ダイアグラムで矢印で表された結合(新しいリリース)
  • 物理モデルおよびビジネス・モデルのダイアグラムで結合を作成する場合、まず結合の「多」の方を選択してから「一」の方を選択するようになりました。以前のリリースでは、ダイアグラムで最初に結合の「一」の方を選択して結合が作成されていました。

    この新しい(多対一の)動作は、前の箇条書きで説明されている新しい結合の矢印の方向と一致します。

  • プレゼンテーション・レイヤーのプレゼンテーション・カタログは、サブジェクト・エリアと呼ぶようになりました。

1.3.2.8 リポジトリ・モデリングの変更

Oracle BI 11gでは、リポジトリ・モデリングに関して次の変更点があるので注意してください。

  • ブリッジ表は、リポジトリ・モデリング・テクノロジを使用して識別されるようになりました。以前のリリースに存在していた「論理表」ダイアログの「ブリッジ表」オプションを使用して識別することはなくなりました。リポジトリをチェックして、ブリッジ表が適切にモデリングされているか確認してください。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のブリッジ表のモデリングに関する項を参照してください。

  • 一部の問合せである結果を返していたが、このリリースで異なる結果を返すようになる場合があります。問合せに使用される論理表ソースが厳密に順序付けて決定されるようになったため(以前のリリースでは無作為に決定)、このような動作が発生します。モデリングを検証および調整して、動作を修正します。

  • 10gでは、同じ論理表の2つの論理表のソースが同一の物理表にマップされており、問合せに両方の論理表のソースが使用され、両方の論理表のソースにWHERE句フィルタがある場合、これらの論理表のいずれかのソースのみのフィルタが適用されていました。もう一方のWHERE句フィルタは無視されていました。

    11gでは、このような状況が発生すると、両方の論理表ソースのWHERE句フィルタが問合せに適用されます。一般的には、この動作により適切な結果が得られます。この問題に関するエラーが発生した場合、物理表の別名を使用して同じ物理表が別のレベルで同じ論理表にマップされないようにすることでそれを修正できます。

1.3.2.9 ライトバックへの変更

以前のリリースのOracle Business Intelligenceでライトバック機能を構成していた場合、このリリースではライトバックを有効にする各論理列で明示的に「書込み可能」オプションを選択する必要があります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』の列でのライトバックの有効化に関する項を参照してください。

1.3.2.10 静的変数への変更

静的リポジトリ変数は、定数値のデフォルトのイニシャライザを持ちます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のリポジトリ変数に関する項を参照してください。

1.3.2.11 Oracle Business Intelligence 11gで必要なMUD履歴の手動アップグレード

Oracle BI管理ツールのマルチユーザー開発(MUD)環境により、ユーザーは次のようにリポジトリの変更に関する履歴情報を取得できます。

  • マージ前のサブセットの変更は、変更されたサブセット・リポジトリに保存されます。

  • MUDの場所の各バージョンは、repository_name.version_numberに保存されます。

Oracle BI 11gでは、リポジトリ・ファイルはユーザーが指定したリポジトリ・パスワードで暗号化されます。そのため、管理ツールは完全にアップグレードされ、暗号化されたリポジトリ・ファイルのみを開くことができます。

バージョン管理されたMUDリポジトリ・ファイルを管理ツールで開いてMUD履歴にアクセスできるようにするには、MUDディレクトリ内のすべてのリポジトリをアップグレードします。次のネーミング・パターン(dddはバージョン番号)を使用して、MUDディレクトリ内のすべてのリポジトリ・ファイルをアップグレードします。

  • repository_name.dddの変更されたサブセット

  • repository_name.ddd


注意:

obieerpdmigrateutilコマンドライン・ツールを使用して、バージョニング済MUDリポジトリ・ファイルをアップグレードします。アップグレード・アシスタントを使用してバージョニング済MUDリポジトリ・ファイルをアップグレードしないでください。

また、obieerpdmigrateutilツールを使用して本番リポジトリ・ファイルをアップグレードしないでください。本番リポジトリはアップグレード・アシスタントを使用してアップグレードする必要があります。


MUD履歴にアクセスできるようにMUDリポジトリをアップグレードするには:

  1. bi-init.cmd(UNIXの場合はbi-init.sh)を実行して、Oracleインスタンスに対して初期化されるコマンド・プロンプトまたはシェル・ウィンドウを起動します。このユーティリティは、次の場所にあります。

    ORACLE_INSTANCE/bifoundation/OracleBIApplication/coreapplication/setup
    
  2. 起動したシェル・ウィンドウから、次のように適切なオプションを使用してobieerpdmigrateutilを実行します。

    obieerpdmigrateutil -I input_repository_path -O output_repository_path
    -L ldif_output_path -U 10g_administrator_username
    

    説明:

    input_repository_pathは、アップグレードおよび暗号化するリポジトリの名前および場所です。

    output_repository_pathは、リポジトリをアップグレードおよび暗号化する先の名前および場所です。この値は、入力リポジトリのパスと同じにすることができます。

    ldif_output_pathは、ユーティリティで生成されるLDIF出力ファイルのパスです。これには、古いリポジトリからLDAPアイデンティティ・ストアにインポートするユーザーおよびグループが含まれます。

    10g_administrator_usernameは、以前のリリースのリポジトリの管理者ユーザー名です。

    例:

    obieerpdmigrateutil -I C:\mud_dir\my_repos.001 -O C:\upgr\my_repos.001
    -L C:\upgr\ldif\my_ldif.ldif -U Administrator
    
  3. 入力を促されたら、10g管理者パスワードと新しいリポジトリの暗号化パスワードを入力します。リポジトリ・パスワードがないとリポジトリを開けないので、これを忘れないでください。エラーを回避するには、MUD環境ですべてのリポジトリ・ファイルに同一のリポジトリ・パスワードを使用します。


    ヒント:

    大量のMUDリポジトリがある場合、MUDリポジトリの移行タスクを自動化するスクリプトを作成することもできます。


1.3.2.12 環境変数に関する変更

Oracle BI 11gでは、環境変数に関して次の変更点があるので注意してください。

  • 環境変数OBIS_Essbase_CustomGroup_Generation: Essbaseでカスタム・グループ構文の使用をカスタマイズするために以前のリリースで使用されていました。これは、PERF_CUSTOM_GROUP_GENERATION_MODEという新しいデータベース機能に置き換えられました。このデータベース機能は、Essbaseやその他の多次元ソースでのカスタム・グループ構文の生成方法に影響します。有効な値のセットは、環境変数と同じです(0~2)。

  • 環境変数OBIS_Essbase_NonEmptyTuples_Generation.Database.Catalog.CubeTable: 大きな問合せセットで問題を解決するために以前のリリースで使用されていました。これは、PERF_PREFER_SUPPRESS_EMPTY_TUPLESという新しいデータベース機能に置き換えられました。このデータベース機能で、空のセル値を持つ空のタプルを削除するかどうかを制御します。このデータベース機能によって、最終結果セットでnullの抑制の動作が変更されることはありません。

1.3.3 BIリポジトリ・メタデータ: 11gの注目の新機能

Oracle BI EE 11g (11.1.1.7.0)のOracle BIリポジトリ・メタデータに関して、次の機能を使用できます。

  • Oracle BIサマリー・アドバイザでのメジャー・サブセットの推奨: Oracle BIサマリー・アドバイザで、特定のメジャーを含む集計のみを推奨するようになりました。それらのメジャーは、分析済の問合せワークロードに存在し、集計が作成されると問合せワークロードを最適化できるものです。

  • モデル・チェック・マネージャの強化: パフォーマンスを向上させるため、モデル・チェック・マネージャでデータベースに対してパラレル問合せを実行できるようになりました。さらに、validaterpdユーティリティを-Lオプションとともに使用して、コマンドラインからモデルをチェックできるようになりました。

  • マルチユーザー開発環境でのバージョンの整合性を強化するための新しいオプション: マルチユーザー開発(MUD)オプション・ファイルにオプションを追加して、MUD開発者間での管理ツール、MUDプロトコルおよびRPDのバージョンの整合性を強化できるようになりました。

  • コマンドラインからのリポジトリ・パスワードの変更: obieerpdpwdchgユーティリティを使用して、コマンドラインからリポジトリ・パスワードを変更できるようになりました。

  • Apache Hadoopデータ・ソースへのアクセス: Oracle BI EEではデータ・ソースとしてApache Hadoopがサポートされるようになりました。

Oracle BI EE 11g (11.1.1.6.2)では、次のOracle BIリポジトリ・メタデータに関する機能も使用できます。

  • ネストされたフォルダを実現するための改良: 「プレゼンテーション表」ダイアログの「子プレゼンテーション表」タブを使用して子プレゼンテーション表を指定して、アンサーおよびBIコンポーザでネストされたフォルダを表示できるようになりました。

  • プレゼンテーション・レイヤー・オブジェクトの表示の制御機能: 個々のサブジェクト・エリア、プレゼンテーション表、プレゼンテーション列およびプレゼンテーション階層に対して「オブジェクト非表示の条件」フィールドに式を指定して、アンサーおよびBIコンポーザでそれらのオブジェクトを非表示にできるようになりました。

  • 集計の作成および削除プロセスの機能強化: このリリースでは、集計の永続性で次のような機能強化が行われています。

    • 一連の集計が作成されるとき、1つの集計の作成が失敗すると、集計の永続性エンジンは、失敗した集計(およびその依存性)の作成をスキップし、すべての変更をロールバックするのではなくリストの次の集計に進むようになりました。

    • Delete aggregates文を使用して、孤立ディメンション表(他のどのファクト表にも結合されていないディメンション表)を削除できるようになりました。

  • 集計の永続性に影響を及ぼすモデリングの問題のチェック機能: リリース11.1.1.6.2、バンドル・パッチ1では、モデル・チェック・マネージャを使用して、一意でないレベル主キーの特定など、Oracle BIサマリー・アドバイザと集計の永続性エンジンの正常な実行に影響を及ぼす可能性のある問題についてリポジトリ・メタデータをチェックできるようになりました。

Oracle BI EE 11g (11.1.1.6)では、次のOracle BIリポジトリ・メタデータに関する機能も使用できます。

  • 管理ツールとサード・パーティのソース・コントロール管理システムとの統合: MUD環境を使用するかわりに、リポジトリをMDS XML形式で保存して、管理ツールとサード・パーティのソース・コントロール管理システムを統合することもできます。

  • Oracle BIサマリー・アドバイザによる問合せ候補の特定: Oracle Exalytics MachineでOracle Business Intelligenceを実行している場合、Oracle BIサマリー・アドバイザ機能を使用して、問合せのパフォーマンスが向上する集計を特定できます。サマリー・アドバイザは、問合せパターンに基づいて集計表の最適なリストをインテリジェントにお薦めします。このリストを使用すると、特定のリソース制約を満たしながら、問合せのパフォーマンスが最大限に向上します。

  • 返される行の制限およびオフセット機能: FETCH句を使用すると、SELECT文によって返される行数を制約でき、OFFSET句を使用すると、返された行を指定した数でオフセットできます。両方の句ともオプションで、組み合せて使用することも、単独で使用することもできます。

  • 効率化されたMUDマージ・プロセス: マルチユーザー開発(MUD)環境を使用するリポジトリ開発者は、ローカルの変更内容のマージと変更内容の公開を2つの個別の手順として行うのではなく、変更内容のマージと公開を単一の手順で行えるようになりました。また、サブセットのリフレッシュを実行して、ローカルの増分をマスター・リポジトリにマージすることもできます。

  • 自動化されたリポジトリのパッチ適用プロセス: patchrpdコマンドライン・ユーティリティで、ユーザーからの入力を必要とせずに、自動でパッチ適用を行えるオプションを使用できるようになりました。また、パッチのマージ中に、パッチ適用固有の新しいルールが適用されます。

  • クラスタ環境における集計の永続性のサポート: クラスタ環境で集計の永続性機能を使用できるようになりました。

Oracle BI EE 11g (11.1.1.5)では、次のOracle BIリポジトリ・メタデータに関する機能も使用できます。

  • Oracle OLAPデータソースへのアクセス: Oracle BI EEはデータソースとしてOracle OLAPをサポートするようになりました。

  • TimesTenデータソース: Oracle BI EEはデータソースとしてOracle TimesTen In-Memory Databaseをサポートするようになりました。

  • SAP/BWデータソース上のネイティブ接続: SAP BW Native接続オプションを使用して、BAPI上でSAP/BWデータソースに接続できるようになりました。

  • Oracle Business Intelligence Metadata Web Service: Oracle BI Metadata Web Serviceは、Oracle BI Serverストアド・プロシージャをコールするためのWebサービス・インタフェースを提供します。これらのストアド・プロシージャを使用して、メタデータに関する情報を取得してメタデータを変更します。

Oracle BI EE 11g (11.1.1.3)では、次のOracle BIリポジトリ・メタデータに関する機能も使用できます。

  • プレゼンテーション・レイヤーの階層オブジェクト: プレゼンテーション・レイヤーでプレゼンテーション階層およびプレゼンテーション・レベルを定義できるようになりました。これらのオブジェクトではOracle BI Answersで多次元モデルを公開する明示的な方法を提供し、ユーザーは階層ベースの問合せを作成できます。プレゼンテーション階層は、メンバーの選択、カスタム・メンバー・グループ、非対称型問合せなどの分析機能を公開します。

  • 不規則階層およびスキップ・レベル階層のサポート: Oracle BI EEでは、不規則階層およびスキップ・レベル階層をサポートするようになりました。不規則階層とは、リーフ(子を持たないメンバー)が必ずしも同じ深さを持つ必要のない階層のことです。スキップ・レベル階層とは、特定の祖先レベルに値がないメンバーがある階層のことです。

  • 親子階層のサポート: Oracle BI EEでは、親子階層をサポートするようになりました。親子階層(値階層とも呼ばれます)には、すべて同じタイプを持つメンバーが含まれます。たとえば、組織チャートには明確な親子階層がありますが、すべてのメンバーは従業員になります。

  • XMLパッチ・ファイルの生成および適用: リポジトリへの変更のみを含むXMLパッチ・ファイルを生成できるようになりました。そのパッチを古い(元の)バージョンのリポジトリに適用して新しいバージョンを作成できます。これは開発から本番への移行のシナリオに非常に有用で、Oracle BI Applicationsカスタマがリポジトリのアップグレードに使用することもできます。

    また、Oracle BI Server XMLユーティリティを使用して、サポートされている任意のOracle BI Serverオペレーティング・システム上で、Oracle BIリポジトリ・メタデータの一般的なXMLベース表現を作成することもできます。

  • 複数通貨のサポート: Oracle BI EEユーザーは、分析およびダッシュボードで通貨列に表示する通貨を選択できるように、論理列を構成できます。

  • Essbaseデータソース: Oracle BI EEはデータソースとしてEssbaseをサポートするようになりました。

  • Hyperion Financial Managementデータソースへのアクセス: Oracle BI EEはデータソースとしてHyperion Financial Managementをサポートするようになりました。

  • ADF Business Componentデータソースへのアクセス: Oracle BI EEはデータソースとしてADF Business Componentsの使用をサポートするようになりました。この機能により、ユーザーはADF Frameworkの最上位に構築される任意のアプリケーションに運用レポートを統合できます。

11gリポジトリ・メタデータで使用できるその他の新機能の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』の新しい機能に関する項を参照してください。

1.4 Oracle BI Presentation Catalogのアップグレードについて

11gで作業をする前に、10g Oracle BI Presentation Catalogからファイルをアップグレードする必要があります。アップグレード・プロセス時に、アップグレード・アシスタントを使用して、カタログ・ファイルをアップグレードします。

ただし、アップグレード・アシスタントを実行する前に、特に注意する必要がある領域が多数あります。詳細は、第1.4.1項「Oracle BI Presentation Catalog: 主なアップグレードの考慮事項」を参照してください。

第1.4.1項で説明されている考慮事項のほかに、BI Presentation Catalogのアップグレードを計画する際に考慮する必要がある要素は多数あります。詳細は、第1.4.2項「Oracle BI Presentation Catalog: その他のアップグレードの考慮事項」を参照してください。

元の10gシステムからアップグレードされた11gシステムへの外観および動作の変更に加えて、アップグレードされたシステムで実装の検討が必要な、Oracle BI 11gに新しく導入された機能が多数あります。詳細は、第1.4.3項「Oracle BI Presentation Catalog: 11gの注目の新機能」を参照してください。

1.4.1 Oracle BI Presentation Catalog: 主なアップグレードの考慮事項

Oracle BI EE 11gでは、既存の機能を強化する多数の機能が導入されました。これらの機能向上によって、以前の機能が不要になる場合もあります。アップグレード時に、不要になった機能を含むレポートおよびダッシュボードは、新しい機能を使用するように意図的にアップグレードおよび改善されます。

10gのレポートおよびダッシュボードの外観および動作を11gで完全に再現しようとはせずに(そのような取組みは適切でなく、ほぼ不可能です)、新しい機能をどのように使用したら最適か検討することをお薦めします。

また、次の考慮事項に留意してください。

  • クラスタ環境でカタログに影響する多くの構成設定が変更されました。たとえば、以前のCatalogCacheTimeoutSecs要素は、CacheおよびCatalogAttributes要素の中のMaxAgeMinutes要素になりました。プレゼンテーション・サービスがクラスタ化されている場合、以前のクラスタの構成設定をすべて新しい設定に置き換える必要があります。

    これらの設定の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。

  • 多くのカタログ・オブジェクトは、アップグレード・プロセスの一部で発行されたすべての警告が修正され、カタログ検証レポートのエラーがなくなるまで、仕様どおりに動作しない場合があります。

    たとえば、アップグレード・プロセスでは入力カタログがすべて正しいことを前提としており、未定義の動作があると不正な結果が生じます。この前提をもとに、アップグレード・プロセスですべてのオブジェクトが体系化され、最初のアップグレード・ログを使用して不正にアップグレードされたオブジェクトがあったかどうかを判断できます。この前提により、11gにアップグレードする前に10gの破損したオブジェクトを修正する必要がなくなります。

    カタログを修正するには、検証レポートを生成し、オブジェクトを修正してから、アップグレードを実行するという手順を何回か繰り返す必要があります。ごく一部のオブジェクトは、手動の編集が必要になる場合もあります。

    検証の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。

  • 各ユーザーの独自のカタログ・コンテンツのローカライズされたテキスト(ダッシュボード名やグラフ・タイトルなど)は、表示されない場合があります。これは、以前の10gバージョンではText要素を使用していましたが、より最近の10gバージョンおよび11gバージョンではすべて大文字のTEXT要素を使用しているためです。Windowsシステムでは、次のコマンドを使用してこの問題を解決します。

    runcat.cmd -localize -cleanup

    UNIXシステムでは、runcat.shを使用します。このコマンドは次のディレクトリにあります。

    ORACLE_INSTANCE\bifoundation
         \OracleBIPresentationServicesComponent
         \coreapplication_obipsn
         \catalogmanager
    

    -localize -cleanupオプションの詳細を確認するには、Windowsシステムで次のコマンドを入力します。

    runcat.cmd -localize -cleanup -help

  • サードパーティのftpプログラムを使用すると、ディスク上の一部の物理アイテム名が不正になる場合があります。アイテムの読取りの失敗に関するカタログ・エラーを見つけたり、WindowsシステムでFile Explorerなどのツールを使用していると、この問題が発見されることがあります。たとえば、正しくは「/system/privs/sa%2esales」というファイル名が「/system/privs/sa%252esales」となってしまう場合があります。ftpプログラムがエスケープ文字を「%」から「%25」に変更してしまっているのです。このftpプログラムを何回か使用すると、エラーが繰り返されてファイル名は「sa%2525252525252esales」のようになります。

    不正なファイル名を修正するには、Windowsシステム上で次のコマンドを実行してからアップグレードを実行します(UNIXシステムでは、runcat.shを使用します)。ファイルによっては、手動で名前を変更する必要がある場合もあります。

    runcat.cmd -cmd repair

    repairオプションの詳細を確認するには、Windowsシステムで次のコマンドを入力します。

    runcat.cmd -cmd repair -help

  • カタログをアップグレードした後、11gで一部の分析が実行されずSQLエラーが発生する場合があります。

    11gのOracle BI Serverでは、表名と列名の先頭または末尾に空白を入れることはできません。それらのカタログのオブジェクト名の先頭または末尾に空白が使用されている場合は、それをすべて取り除く必要があります。カタログ・マネージャのXML検索と置換機能またはsedなどのテキスト置換ツールを使用できます。

    たとえば、分析で「 Product Sales .Unit Price 」に対するSQL問合せを実行する場合(「 Product Sales 」は表、「 Unit Price 」は列)、このSQLコードは「Product Sales.Unit Price」に変更する必要があります。

    このような置換は、SQLおよびHTMLコードで表名および列名の処理に様々なエスケープ処理のルールがあるため煩雑になります。sqlExpressionノードでの分析では、XMLファイルの表現は次のようになります。

        "   " \" Product Sales \" "  .  " \" Unit Price \" "  "
    

    これは、次のように変更する必要があります。

        ""Product Sales"."Unit Price""
    

    \"文字は、実際は名前の一部ではありませんが、別の引用レベルとして機能します。

  • 11gの機能を最大限に使用するために、Webサーバーの構成を検討してください。Oracle BI Webクライアントのパフォーマンスを向上させるには、すべての静的ファイルを処理するWebサーバーを構成し、静的リソースも動的リソースも圧縮を有効化します。Webサーバー上でキャッシュおよびコンテンツの有効期限を有効にすると、Webブラウザでサーバーから静的ファイルをリロードする頻度を指定できます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle BI Webクライアントのパフォーマンスの向上に関する項を参照してください。

  • 10gでは、大きなデータセット(10000行を超えるデータセット)をExcel形式にエクスポートする場合がありました。11gでは、Excel形式に直接エクスポートすることも引き続き可能ですが、最初にCSVにエクスポートしてからそのファイルをExcelにインポートすると、多数の行をエクスポートする際のパフォーマンスが向上することに気付くことがあります。Oracle Business Intelligenceが32ビット・オペレーティング・システムのコンピュータにインストールされている場合、パフォーマンスを改善するには、CSV形式にエクスポートする必要があります。

    64ビット・オペレーティング・システムのコンピュータでCSV形式を使用せずに大きなデータセットをエクスポートする必要がある場合、メモリー不足によるエラーを経験することがあります。このエラー・メッセージが表示される場合、JavaHostサービスのヒープ・サイズを大きくする必要があります。デフォルトのヒープ・サイズは1024MBです。コンピュータの利用可能なメモリーに応じて、次の手順を使用してJavaHostサービスのヒープ・サイズを大きくすることができます。

    1. opmn.xmlファイルを開いて編集します。opmn.xmlは次の場所にあります。

      ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml

    2. JavaHostシステム・コンポーネントのias-componentタグを探します。

      例:

      <ias-component id="coreapplication_obijh1">

    3. <data id="start-args" value="-server -Xmx1024Mで始まる行で、次の操作を行います。

      -Xmxパラメータを2048M(または必要に応じてそれ以上。システムにおける使用可能なメモリーや必要とするExcelエクスポートのサイズによる)に設定します。

      32ビットのWindowsオペレーティング・システムを実行しているコンピュータでは、このパラメータを大きな値に設定しないでください。そうでないとJava仮想マシンが起動しません。

    4. ファイルを保存して閉じます。

    5. com.siebel.analytics.javahost.io.ChannelWithTimeoutクラスからSocketTimeoutExceptionについてのエラー・メッセージが表示される場合は、JavaHostサービスのためのSocketTimeoutパラメータを更新します。

      ORACLE_INSTANCE\config\OracleBIJavaHostComponent\coreapplication_obijhnディレクトリで、JavaHostシステム・コンポーネント用のconfig.xmlファイルを開きます。

      MessageProcessorセクションとSocketTimeoutパラメータを見つけます。コメント・アウトされている可能性もあります。必要に応じてSocketTimeoutを非コメント化し、大きな値を指定します。たとえば、最小でも300000ミリ秒を指定します。

      config.xmlファイルとその設定は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle BI Presentation ServicesのJavaHostサービスの使用の項で説明しています。

    6. ファイルを保存して閉じます。

    7. OPMNを再起動します。

    8. Fusion Middleware Controlを使用して、またはOPMNを使用してコマンドラインから、JavaHostシステム・コンポーネント・プロセスを再起動します。

    9. クラスタ化されたシステムで、後からスケールアウト時にJavaHostプロセスを追加する場合、JavaHostプロセスを実行するそれぞれのコンピュータでこれらの手順を繰り返します。ias-componentタグは、デプロイされるコンピュータ毎に異なることに注意してください(たとえば、<ias-component id="coreapplication_obijh2">)。

1.4.2 Oracle BI Presentation Catalog: その他のアップグレードの考慮事項

Oracle BI Presentation Catalogをアップグレードする際は、次の考慮事項に注意してください。詳細は、付録B「アップグレード後に予想されるOracle BI Enterprise Editionの外観と動作の変化」を参照してください。

1.4.2.1 アクションのアップグレード

アクションは次のようにアップグレードされます。

  • iBot定義の「詳細設定」タブで10g iBotにアタッチされたカスタム・スクリプト・アクションは、「サーバー・スクリプトの起動」アクションにアップグレードされます。

  • カスタムJavaプログラム・アクションは、Javaジョブの起動アクションにアップグレードされ、以前と同様に実行されます。ただし、これらのアクションは読取り専用です。サーバーで実行する新規カスタム・コードには、Javaメソッド(EJB)の起動アクションまたはWebサービスの起動アクションを使用します。

  • Siebel運用アプリケーションにリンクされたアクションは、「Siebel CRMにナビゲート」アクションにアップグレードされません。

  • Siebelワークフロー・アクションはアップグレードされません。以前のリリース(11gより前のリリース)でワークフローを起動していたアクションと同様の機能を実現するには、ワークフローをWebサービスとして公開し、Webサービスの起動アクションを作成することをお薦めします。

また、トレリスの内部の可視化に含まれる列上のアクション・リンクは、内部の可視化内で左クリックすることで使用可能になります。

アクションの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』のアクションの使用に関する項を参照してください。

1.4.2.2 合計とアクションを含む分析のアップグレード

アップグレードする場合、分析に合計または総計が含まれていて、関連する属性列または階層列にアクション・リンクや条件付きアクション・リンクが含まれている場合、そのアクション・リンク(または条件付きアクション・リンク)はその列と、合計または総計の両方に適用されます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』の「アクションとは」と「アクションの条件による有効化について」を参照してください。

1.4.2.3 高度なSQLを使用する分析のアップグレード

「詳細設定」タブで編集されたSQL文の分析をアップグレードした場合、階層列、選択またはグループを分析に追加できません。アップグレードされた分析にこれらの機能を含めようとすると、機能が使用できないことを示すメッセージが表示されます。

詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』の分析用の論理SQLの検証に関する項を参照してください。

1.4.2.4 計算項目のアップグレード

計算項目の以前のリリースからのアップグレードには、アップグレードするバージョンについて様々な影響があります。次の例を前提として、特定のアップグレードに予想される動作を箇条書きリストに記します。

例: 2つのピボット表と1つの棒グラフを含む分析があるとします。基準には、Products列と、calcItem1という計算項目があるpivotTable1というピボット表が含まれます。2つ目のピボット表はpivotTable2という名前で、Products列にcalcItem2という計算項目があるとします。

  • リリース10gから11.1.1.7.0にアップグレードする場合、詳細の非表示オプションが選択されていなければ、計算項目はそれぞれのビュー専用となります。詳細の非表示オプションが選択されている場合は、計算項目はすべてのビューに適用されます。11.1.1.7.0へのアップグレード後は、各ピボット表のビューにはそれぞれ独自の計算項目が含まれます。そのため、pivotTable1にはcalcItem1、pivotTable2にはcalcItem2が含まれます。棒グラフには計算項目は含まれません。

  • リリース11.1.1.3、11.1.1.5または11.1.1.6.xから11.1.1.7.0にアップグレードする場合、影響はありません。

  • リリース10gから11.1.1.3、11.1.1.5または11.1.1.6.xにアップグレードしてから11.1.1.7.0にアップグレードする場合、分析は、リリース10gから11.1.1.7.0に直接アップグレードした場合と同様にはなりません。

1.4.2.5 非表示のダッシュボードのアップグレード

10gでは、内部属性を設定してダッシュボードを非表示にします。11gでは、ダッシュボード・フォルダをその上位レベルのフォルダ内で非表示フォルダにすることでダッシュボードを非表示にします。カタログのアップグレード時および移行時には、非表示のダッシュボードを含む子フォルダに「非表示」属性が適用されています。

1.4.2.6 ダッシュボードのアップグレード

ダッシュボードをアップグレードする際は、次の点に注意してください。

  • 新規のデフォルト・スタイルはFusionFxになります。アップグレード後は、ダッシュボードの編集および「ダッシュボードのプロパティ」ダイアログの「スタイル」ボックスの設定、またはinstanceconfig.xmlファイルの編集によって、ダッシュボートのスタイルを変更できます。

  • 以前のリリースでは、ダッシュボード・ページはブラウザ・ウィンドウいっぱいに広がるようなサイズでした。このリリースには、ダッシュボード・ページ上での列およびセクションの位置とサイズの制御を可能にする新しいオプションが含まれています。ダッシュボードのアップグレード時は、次のようになります。

    • ページは以前と同様にブラウザ・ウィンドウいっぱいに広がるサイズになり、「ダッシュボードのプロパティ」ダイアログで新しい「ブラウザ・ウィンドウまで最大サイズ化」オプションが選択されます。

    • 列またはセクションに対して、幅、高さあるいは両方が指定されている場合、その列またはセクションは指定のサイズとなり、新しい「最小サイズ」オプションが「列のプロパティ」または「セクションのプロパティ」ダイアログで選択されます。

1.4.2.7 iBotsのアップグレード

iBotsをアップグレードする際は、次の点に注意してください。

  • 以前のリリース(11gより前のリリース)では、ただちに起動するよう設定されたiBot(現在のエージェント)を作成できました。この設定のiBotをアップグレードすると、スケジュール設定が現在のリリースにインポートされません。他のすべてのエージェントのスケジュール設定はインポートされます。

    ただちに起動するよう設定されたiBotをアップグレードする場合、「エージェント」エディタの「スケジュール」タブの「頻度」設定は「なし」になります。「すぐに開始」スケジュールからの実際の開始時間は必ず過去になるため、無効になります。

  • 以前のリリース(11gより前のリリース)では、「自分」オプションを選択すると、iBotの所有者としてコンテンツを配信するiBotを作成できました。「自分」オプションが選択されたiBotをアップグレードすると、11gでは、エージェントの所有者は次のいずれかになります。

    • エージェントが公開される場合は、登録者。

    • エージェントが公開されない場合は、受信者。

  • 以前のリリース(11gより前のリリース)では、リクエストの結果(現在の分析)に基づいた条件下でトリガーされるiBotを作成できました。

    このリリースでは、条件付きでトリガーされるエージェントを作成するには、条件を使用します。使用時に定義し、Oracle BI Presentation Catalogに保存しないインライン条件を使用することも、カタログに名前を付けて保存した名前付き条件を使用することもできます。条件の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』の条件の使用に関する項を参照してください。

    以前のリリース(11gより前のリリース)で条件付きでトリガーされたiBotは、デフォルト名のAgentCondition1とインライン条件を使用するようアップグレードされます。このインライン条件では、選択されたリクエストによって返される行の数が0より大きいかどうかが評価されます。(これらの条件をエージェント内から編集したり、ベースになっている分析の場所を確認したり、カタログ内の任意の場所に保存できることに注意してください。)

  • 以前のリリース(11gより前のリリース)では、特定のiBotが完了したらカスタムJavaプログラム・アクションを実行するように指定できました。このリリースでは、カスタムJavaプログラム・アクションは、Javaジョブの起動アクションにアップグレードされ、以前と同様に実行されます。ただし、これらのアクションは読取り専用です。サーバーで実行する新規カスタム・コードには、Javaメソッド(EJB)の起動アクションまたはWebサービスの起動アクションを使用します。

1.4.2.8 ピボット表のアップグレード

ピボット表をアップグレードする際は、次の点に注意してください。

  • 10gでは、デフォルトでは、ピボット表のすべての行が表示されていました。11gでは、必要に応じて表ビューでデータをページごとに表示できます。デフォルトでは、最初の25行が表示されます。ピボット表エディタで「グラフのピボット結果」をクリックすると、ピボット表に現在表示されている内容を表示するのみがグラフに表示されます。ピボット表にはセクションごとのグラフが表示されます。ユーザーはテープ・デッキ・コントロールを使用してグラフをページごとに表示できます。

    ピボット表のデフォルトの表示行数は、instanceconfig.xmlファイルのDefaultRowsDisplayed設定を使用して変更できます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者』の第18章を参照してください。

  • ピボット・ページ・プロンプトでは、列を1つのドロップダウン・リストに組み込みません。そのかわり、各列に独自のドロップダウン・リストがあります。

  • ピボット表には、行見出しラベルの列ヘッダーに追加の行があります。行または列に列がない場合、追加の列領域または行領域もあります。

  • 10gでは、メジャー・データを何も持たない行も表示されます。11gでは、このような空白行は表示されません。そのため、ピボット表の行が消失する可能性があります。

1.4.2.9 ビューでの相互作用のアップグレード

ビューでの相互作用のアップグレード時には、次のことに注意してください。

  • 以前のリリース(11gより前のリリース)では、チャートやゲージの相互作用をビュー・レベルで作成でき、基準レベルで設定された相互作用をオーバーライドできました。このリリースでは、左クリック相互作用を基準レベルで作成します。以前のリリース(11gより前のリリース)からアップグレードする場合、すべての左クリック相互作用は基準レベルのメジャーに移動され、すべてのビューで有効になります。

    10gのチャートでチャートの相互作用が定義されている場合、基準列がさらに追加される場合があります。列が繰り返し表示されることがあります。チャートの相互作用は、「基準」タブに含まれている列の「列のプロパティ」ダイアログの「相互作用」タブに移行されます。他のビューへの影響を回避するために、アップグレード・プロセスによって、チャート・レベルの相互作用を含む各チャートの基準に新しい列が追加されます。

    たとえば、基準が、地域、地区、売上金額および売上数量として定義された分析を以前のリリース(11gより前のリリース)で作成したとします。また、チャート・ビューに相互作用を作成してあります。このリリース用に相互作用をアップグレードするために、追加の売上金額と売上数量列が基準レベルで追加され、相互作用は、基準レベルでこれら追加された売上金額と売上数量の両方に移動されます。

  • 11gでは、複数のリンクへのナビゲーションをサポートする分析にポップアップ・メニューが表示されることがあります。リンクが1つしかない場合は、「列のプロパティ」ダイアログの「相互作用」タブでこのメニューをオフに設定できます。

  • このリリースより以前は、すべての右クリック相互作用(実行時にビューで右クリックしたときに分析に対して使用可能)はデフォルトで有効になっていました。このリリースでは、限定された相互作用のセットのみ(具体的には「ドリル(プライマリ相互作用でない場合)」、「列の移動」、「列のソート」および「列を含める/除外」)がデフォルトで有効になります。アップグレード時、これらのデフォルトを使用中の分析は、限定された相互作用のセットのみを使用するようにアップグレードされます(組織がデフォルト設定を変更している場合を除く)。組織でデフォルト設定を変更している場合は、その組織のデフォルト設定がかわりに使用されます。デフォルト設定の変更方法は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイドのビューの相互作用の手動構成に関する項を参照してください。分析に対してどの右クリック相互作用が使用可能であるかを変更することもできます。方法については、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』のビューでの右クリック相互作用に関する項を参照してください。

1.4.2.10 条件付き書式のアップグレード

11gでは、分析エディタ: 「基準」タブに追加された条件付き書式は表とピボット表ビューの両方に適用されます。10gでは、別の列に基づく条件付き書式は表ビューにのみ適用されていました。

たとえば、Product列とSales列の両方を使用する分析を作成したとします。Productに条件付き書式を設定して、Salesがある値より大きいProductに書式を指定した場合、条件が満たされると、Product列を含む表ビューおよびProductを含むピボット・ビューにこの書式が適用されます。

属性列の条件付き書式は、表ビューに表示される10gの条件付き書式と一致するために、列プロパティの編集ダイアログ: 「列書式」タブで列の「値の抑制」オプションを「繰返し」に設定する必要がある場合があります。これは、列が表ビューで使用され、条件付き書式がメジャーに基づいて設定されている場合にのみ適用されます。基準の列の「値の抑制」オプションを変更すると、この列を使用する分析でその他の表またはピボット・ビューのレイアウトに影響する場合があります。

条件付き書式の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』の条件付き書式の表およびピボット表への適用に関する項を参照してください。

1.4.2.11 メジャー列のアップグレード

以前のリリース(11gより前のリリース)では、メジャー列は属性列として容易に処理できたため、ビューのエッジ間を自由に移動できました。

リリース11gでは、メジャー列がエッジに移動したときに詳細をすべて表示せずに、メジャー列をエッジのマス目に集計する機能が導入されました。

アップグレード時には、すべてのメジャー列に「列式の編集」ダイアログ: 「列式」タブで選択された「属性列として処理」チェック・ボックスがあります。これによって、ピボット表のエッジまたはグラフの「グループ化」に移動したメジャーを含むレポートをアップグレードしても、10gと同様に機能します。新しい11gの分析には、「属性列として処理」オプションがあります(メジャーはデフォルトではfalseに設定されます)。


注意:

属性列として処理」オプションを選択しながら、(1行当たり1つのメジャーの値を表示し、列エッジでの列による値の繰り返しを回避するときなどに)列の値の強制グループ化が意味をなさないエッジにメジャー列を移動すると、エラーが発生することがあります。この問題を解決するには、「属性列として処理」オプションを選択解除します。


1.4.2.12 レポートを基準にした合計のアップグレード

以前のリリース(11gより前のリリース)には、表やピボット表のビューでレポートを基準にした合計を作成する機能がありました。レポートを基準にした合計の扱いが、このリリースでは多少異なるため、合計に関する次のような違いに注意してください。

  • 以前の表に、レポートを基準にした合計がすべて含まれていた場合、アップグレードされた表内のすべてのメジャー列と属性列では、レポートを基準にした合計オプションとともに「デフォルト」オプションが使用されます。

  • 以前の表ビューに、レポートを基準にした合計とレポートを基準にしていない合計が含まれていた場合、アップグレードされた表内のすべてのメジャー列と属性列では、レポートを基準にした合計オプションとともに「デフォルト」オプションが使用されます。

    アップグレードされた合計に手動で対処することができます。以前のリリース(11gより前のリリース)と同じメジャー列を使用する場合、表内のメジャー列を複製し、「集計ルール」メニューを使用して、レポートを基準にしていない合計を指定します。

  • 以前の表ビューに、レポートを基準にしていない合計がすべて含まれていた場合、アップグレードされた表内のすべてのメジャー列と属性列で、レポートを基準にしていない合計が引き続き使用されます。

1.4.2.13 ソートのアップグレード

ソートをアップグレードする際は、次の点に注意してください。

  • 以前のリリース(11gより前のリリース)では、「基準」タブの列に追加されたソートはすべてのビューに適用されていました。以前のリリース(11gより前のリリース)からアップグレードする場合、表、ピボット表またはグラフ・ビューで異なるソートが適用されていることに気付くことがあります。アップグレードされたレポートでは、基準列で指定されたソートが維持されます。ただし、11gでは、基準列で指定されたソートは、ビューにその列が含まれている場合にのみそのビューに適用されます。

    引き続きビューにない列でソートする場合、列を非表示列として含めることで10gの動作を再現できます。

    列を非表示列として含めるには:

    1. 「結果」タブで目的のビューの「ビューの編集」ボタンをクリックします。

    2. 「レイアウト」ペインの目的の列で「詳細オプション」ボタンをクリックして「非表示」を選択します。

    11gのグラフも、ソートをエミュレートするユーザー・インタフェース要素を備えていません。引き続きグラフ・ビューにないメジャー列に基づいてグラフをソートする場合は、次の回避策を使用してください。

    1. 追加メジャーを外部グループとしてグラフの「グループ化」ドロップ・ターゲット領域に加えてください。

      「列式の編集」ダイアログの「列式」タブで、「属性列として処理」オプションを選択する必要があることに注意してください。(アップグレード時、このオプションはデフォルトで選択されます。)

    2. 「列のプロパティ」ダイアログの「列書式」タブの「非表示」オプションを使用する分析では、追加メジャーを非表示にしてください。

  • 以前のリリース(11gより前のリリース)で、「基準」タブのメジャー列でソートが指定されている場合、分析をアップグレードしても、そのソートは同じメジャー列を使用するピボット表またはグラフに適用されません。

  • ピボット表は、デフォルトでは常に外側のレイヤーから内側のレイヤーに各エッジがソートされます。これは、以前のリリース(11gより前のリリース)の動作と異なります。以前のリリースでは、ピボット表のデフォルトのソートとして、基準列で指定されたソートによって決定される表ソートが使用されていました。

1.4.2.14 表、ピボット表および拡張トレリスのスクロールのアップグレード

前のリリース(11.1.1.7.0より前)では、表、ピボット表および拡張トレリスのデータの参照にページ・コントロールが使用されていました。リリース11.1.1.7.0では、表、ピボット表および拡張トレリスが強化され、データを参照する方法としてスクロールまたはページ・コントロールのいずれかを使用できるようになりました。新規の表またはピボットの場合、デフォルトの方法はスクロールです。既存の表、ピボット表および拡張トレリスは、方法を変更しないかぎり、ページ・コントロールを引き続き使用します。「表のプロパティ」ダイアログ: 「スタイル」タブ、「ピボット表のプロパティ」ダイアログおよび「トレリスのプロパティ」ダイアログ: 「一般」タブの「データ表示」コンポーネントを設定することで方法を変更できます。

1.4.2.15 プロンプトを持つビューのアップグレード

以前のリリースでは、プロンプト・エッジを含むビュー(たとえば、ピボット表プロンプトを含むピボット表)はプロンプトの周りの枠線とともに表示されました。このリリースでは、プロンプト・エッジを含むビューをアップグレードすると、プロンプトの周りの枠線はなしで表示されます。

1.4.2.16 プロンプトのアップグレード

プロンプトをアップグレードする際は、次の点に注意してください。

  • プロンプトをアップグレードする場合、その外観および動作が元の10gシステムのものと正確に一致しないことがあります。10gの外観を再現しようとすると大量の労力を要し、手動で更新すると、11gに導入された拡張機能を利用できなくなる場合があります。アップグレードされたプロンプトは以前のリリースと同様に機能しますが、表示が多少異なる場合があります。たとえば、複数のプロンプトが含まれる2つの積上げ行を持つダッシュボードがある場合、アップグレードされたプロンプトは、それぞれのプロンプトの幅が120ピクセルに増加されるため、配置が異なります。

  • 以前のリリース(11gより前のリリース)では、プロンプト・フィールドの幅や、プロンプト・ページでプロンプト・ラベルをラップするかどうかを指定することはできませんでした。以前のリリースからプロンプトをアップグレードする場合、次の点に注意してください。

    • 「新規プロンプト」ダイアログでは、「選択リストの幅」フィールドは、instanceconfig.xmlファイルのDefaultPromptWidth要素で指定されたデフォルトの幅(ピクセル値)に設定されます(デフォルトでは、120ピクセル)。

    • 「ページ設定の編集」では、次のようになります。

      • ラベルをラップして合せる」オプションは選択されません。

      • すべてのプロンプトの幅を次に設定」フィールドは、instanceconfig.xmlファイルのDefaultPromptWidth要素で指定されたデフォルトの幅(ピクセル値)に設定されます(デフォルトでは、120ピクセル)。

  • 10gでは、ダミー列に対してダッシュボード・プロンプトを使用して変数を設定できました。ダミー列のデータ型は、それを入力するSQL文の値のデータ型と異なる場合がありました。それでも、10g変数はすべて文字列であったため、機能していました。

    11gにアップグレードしたら、プロンプトに使用したダミー列はSQL戻り値と同じデータ型を持つ必要があります。同じでないと、実行時にデータ型検証エラーが発生します。

    アップデート・プロセス時は、SQL文を実行してデータ型が判断されることはないので、エラーは発生しません。この問題が顕在化するのは、11gでプロンプトが実行された場合のみです。必ず実行前に変数の設定に使用された任意のダミー列・プロンプトのデータ型が一致していることを検証してください。

    11gでは、新しい変数プロンプト・タイプを使用して変数を作成および設定することをお薦めします。これを使用することで、ダミー列を使用する必要がなくなり、それに伴うデータ型の不整合も解消されます。

1.4.2.17 カスタム・ファイルのアップグレード

以前のリリース(11gより前のリリース)でローカルに保存され、fmap関数を使用して参照されていたカスタム・ファイル(イメージ・ファイルやヘルプ・ファイルなど)は、11gで次のディレクトリに手動でコピーする必要があります。

ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent
     /coreapplication_obipsn/analyticsRes

1.4.2.18 カスタムのスタイルとスキンのアップグレード

Oracle BI 11gでアーキテクチャおよびユーザー・インタフェースの要素に大きな変更があったため、以前のスキンおよびスタイルから11gインスタンスへの移行には新しい取組みが必要です。カスタム・スタイルおよびスキンはアップグレードされません。10gでカスタム・スタイルおよびスキンを使用していた場合、11gでそれらを手動で再作成する必要があります。

XMLテンプレート・カスタマイズを使用したカスタマイズのタイプは、10gでは可能だったが11gでは使用できなくなるものがあるので注意してください。

リリース11.1.1.7.0では、FusionFXと呼ばれる新しいスタイルが導入されました。その結果として、以前のリリース用に作成したカスタム・スタイルが、引き続き11.1.1.7.0および将来のリリースで想定どおりに機能するよう、修正する必要があります。

1.4.2.19 チャートのアップグレード

表1-2に、チャートが11gのグラフにアップグレードされる際の相違点を示します。

表1-2 チャートが11gのグラフにアップグレードされる際の相違点

変化 説明

軸ラベルの範囲の変化

10gと11gでは、自動軸範囲計算エンジンの違いから、グラフの数字軸ラベルの範囲が異なります。

棒グラフ・サービス・ダッシュボードのデータの相違

11gでは、データの書式が拡張され、doubleデータ型とintegerデータ型の違いが示されるようになりました。この問題は、10gではintegerデータ型で11gではdoubleデータ型になった列のデフォルトの書式をオーバーライドすることによって、手動で解決できます。

11gでの軸値の相違

10gでは、列に対する基準レベルの書式や他のグローバルなデータ書式が守られないことがあります。データ・ラベルおよび数値軸ラベルがこのような書式設定に従わないことがあります。この問題は、11gで解決されました。

グラフでのドリルダウンで異なる結果が表示されることがある

アップグレード中、10gの既存の相互作用はメジャーに配置され、軸と凡例では利用不能になります。アクションを起動するには、軸ラベルまたは凡例ではなく、グラフのメジャーをクリックする必要があります。軸または凡例に配置された列にアクション・リンクを直接追加するには、基準内でその列にアクション・リンクを追加します。それにより、追加したアクション・リンクが軸ラベルまたは凡例で表示されるようになります。

グラフ・エンジンが応答しない

11gでは、JavaHostからプレゼンテーション・サービスに送られるグラフ・データのデフォルト値は4MBです。グラフのサイズが大きい場合、グラフ・エンジンが応答していないことを通知するメッセージが表示されることがあります。この問題を回避するには、instanceconfig.xmlファイルでグラフのデータ・サイズを大きくします。次の例は、グラフのデータ・サイズを6MBに増やす方法を示しています。構成ファイルの編集の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。

<Views>
   <Charts>
 <JavaHostReadLimitInKB>6144</JavaHostReadLimitInKB>
   </Charts>
</Views>  

グラフのラベルがなくなることがある

11gで使用されているラベルの自動レイアウト・アルゴリズムの影響で、一部の軸ラベル(数値軸とカテゴリ軸の両方)がスキップされることがあります。

Y軸のグラフのラベルを回転できない

Y軸のグラフのラベルについては、0から90度または-90度の回転のみ可能です。45度の回転は実行できません。

面グラフのグリッド線の動作

11gの面グラフでは、面マーカーの上にグリッド線が描画されます。つまり、描画された面の上にグリッド線が表示されます。10gでは、グリッド線は面マーカーの上には描画されません。

折れ線グラフが積み上げられる

10gの積上げ折れ線グラフでは、同じ軸に複数のメジャーが折れ線として表示され、積上げは行われません。

  • 11.1.1.7より前の11gリリースでは積上げが行われます。

  • 11.1.1.7以降の11gリリースでは積上げが行われません。

折れ線としてレンダリングされていた一部のメジャーが棒としてレンダリングされる

10gの線-棒グラフでは、一部のメジャーがランダムに選択され、棒ではなく折れ線として表示されます。11gでは、メジャーの描画は分析のグラフ定義に依存し、その描画方法が考慮されます。棒として表示するように定義されているメジャーは、棒として表示されます。

グラフでの不明列の消失

10gでは、現在レイアウトに存在する列でグラフ定義が未完了になっているものは、それぞれ不明列としてグラフに追加されます。11gではこの動作が修正されたため、グラフから列が消失することがあります。追加の列がレイアウトに含まれることはなくなり、かわりにメッセージ・ボックスが表示されます。10gから11gへのアップグレード時、このような不明列は、無効、つまり分析の問合せまたは基準のXMLファイルに存在しないとみなされ、分析から削除されます。

10gで単一円グラフだったものが11gで複数円グラフになる

Oracle BI EE 10gでは複数円グラフはサポートしていませんが、11gではすべての列に対して円グラフをサポートしています。この拡張の影響で、アップグレード後に複数の円グラフが表示されるようになる場合があります。

グラフでのナビゲーションの変更

11gでは、グラフのナビゲーションが変わりました。10gで軸ラベルまたは凡例にナビゲーションを設定していた場合、そのナビゲーションは基準レベルに移動するため、利用できなくなります。

円グラフの負の値がレンダリングされない

10gの円グラフでは、負の値も含めて絶対値が表示されます。負の値は正の値として解釈され、それに対応する区分が表示されます。11gでは、負の値に対応する区分は表示されません。すべての値が負の場合、グラフ自体が表示されません。11gでは、凡例は負の値に対しても表示されます。

円グラフにミニ円グラフ付きの凡例が表示される

凡例でグラフを使用することを選択した場合に、グラフのサイズが縮小されあまりに小さくなると、10gではグラフ全体が表示されません。それに対し11gのエンジンは最小スペースでグラフを表示しようとします。レイアウト・アルゴリズムによって、使用できる最大領域のグラフへの割当てが試みられます。凡例に含まれる項目数が多すぎる場合は、グラフに割り当てられた領域を侵さないようにスクロール・バーが追加されます。

右側のスケールがグラフから消失することがある

11gのグラフ・エンジンは、線-棒グラフのY2軸を折れ線にマップします。そのため、軸が同期化されていなくても、折れ線のデータがないため、Y2軸は表示されません。

11gでの凡例とグラフの不一致の可能性

10gの積上げ棒グラフを11gにアップグレードすると、系列の順序または位置が変わる場合があります。しかし、凡例ビューは何の変更もなくアップグレードされます。その結果、凡例ビューに表示される凡例と、グラフに表示される色の不一致が発生する可能性があります。この問題を解決するには、グラフの色を変更するか、またはグラフの色に合うように凡例を更新します。

また、「色変更方法」で列を追加すると、棒グラフの積上げ順序が変わります。その他のケースでは、順序と色は維持されます。「色変更方法」で列に対して条件付き書式設定を指定すると、凡例が正しくないものになったり、一致しなくなります。

パレート・グラフの動作が異なる

このリリースのパレート・グラフでは、縦軸2の範囲は0%から100%までです。したがって、スケールとデータ・ラベルに使用される略記は変更できません(たとえば、Million(m)に変更できません)。データ・ラベルが現在表示されているデフォルトの数値書式をオーバーライドすることもできません。

散布図の動作が異なる

このリリースの散布図では、以前のリリース(11gより前のリリース)と異なり、グループ化軸に1つ以上の属性列は必要ありません。

積上げ縦棒グラフおよび積上げ横棒グラフの積上げ順序が異なる

このリリースの積上げ縦棒グラフおよび積上げ横棒グラフでは、積上げ順序が以前のリリース(11gより前のリリース)の順序と逆です。

対数スケールの動作が異なる

このリリースでは、対数スケールは次のように動作します。

  • スケール制限を指定する場合、対数スケールのスケール制限は10の累乗である必要があります。指定した数値が10の累乗でない場合、指定した数値に最も近い10の累乗が使用されます。

  • システムでスケールを決める場合、使用されるメジャーに基づき、下限が動的に変わります。

以前のリリース(11gより前のリリース)では、対数スケールは次のように動作しました。

  • スケール制限を指定する場合、対数スケールのスケール制限は10で割り切れる数でした。指定した数値が10で割り切れない場合、指定した数値に最も近い、10で割り切れる数値が使用されました。

  • システムでスケールを決める場合、下限は常に1で始まり、上限は使用されるメジャーに基づいて変わりました。


1.4.2.20 エージェント・フォルダのアップグレード

アップグレード時、-ibotsという名前の非表示のフォルダはAgentsという名前に変更され、非表示でなくなります。My FoldersフォルダとShared Foldersフォルダに格納されます。

1.4.2.21 ゲージのアップグレード

以前のリリース(11gより前のリリース)では、ゲージを使用したユーザー・インタフェースで範囲の最大値と最小値を入力していました。不連続の範囲も指定できました(たとえば、Range1: 0-200、Range2: 400-500、Range3: 200-400など)。

リリース11gでは、ゲージの範囲は連続しています(たとえば、範囲1: 1から200、範囲2: 200から400、範囲3: 400から500など)。ゲージの範囲ダイアログでは、範囲を計算するしきい値のみを指定できます。しきい値を入力した結果、ゲージの範囲が不正になると、ゲージはレンダリングされず、エラー・メッセージが表示されます。

図1-4 ゲージの範囲のしきい値

図1-4の説明が続きます
「図1-4 ゲージの範囲のしきい値」の説明

リリース11gは、図1-4に示すように、しきい値に基づいています。アップグレード時に、それぞれの範囲で指定された「低」/「最小」値が考慮され、範囲のアップグレードを試行して可能なかぎり連続にしようとします。範囲を正しくアップグレードできない場合、アップグレードが終了した後、範囲を修正する必要があります。

次のシナリオでは、アップグレードされたゲージのレンダリングについて説明します。

  1. 範囲が昇順に指定されないが連続な場合(重複やネストもなし)

    Oracle BI EE 10gでの範囲を表1-3に示します。

    表1-3 昇順に指定されないゲージの範囲(10g)

    Range1

    最小 = 0

    最大 = 200 (赤)

    Range2

    最小 = 400

    最大 = 500 (緑)

    Range3

    最小 = 200

    最大 = 400 (黄)


    アップグレードされた11gのグラフを表1-4に示します。

    表1-4 昇順に指定されないゲージの範囲(11g)

    Range1

    最小 = 0

    最大 = 200 (赤)

    Range2

    最小 = 200

    最大 = 400 (黄)

    Range3

    最小 = 400

    最大 = 500 (緑)


    範囲は、論理的に正しければ、その最小値に基づいて決定されます。

    アップグレードされた11gのゲージは、レンダリングされると10gのゲージと同じになります。

  2. 範囲の最小値または最大値が指定されない場合、ゲージは次のように10gのゲージに基づいて設定されます。最終的に得られた範囲が連続で有効であれば、アップグレードされたゲージはレンダリングされます。

    1. 指定された最初の範囲の最小値がない場合、表1-5に示すような最小のスケール制限が使用されます。

      表1-5 最小値または最大値が指定されない場合のゲージの範囲

      Range1

      最小 = ? (0) (値がない場合にこの値が使用されます)

      最大 = 200 (赤)

      Range2

      最小 = 200

      最大 = 400 (黄)


    2. その他の範囲で(最初の範囲以外で)最小値がない場合、表1-6に示すように、前の範囲で指定された最大値が使用されます。

      表1-6 最小値がない場合のゲージの範囲

      Range1

      最小 = 0

      最大 = 200 (赤)

      Range2

      最小 = ? (200) (値がない場合にこの値が使用されます)

      最大 = 400 (黄)


    3. 指定された最後の範囲に最大値がない場合、表1-7に示すように、最小値に前の範囲の幅が加算された値が使用されます。

      表1-7 最後の範囲に最大値がないゲージの範囲

      Range1

      最小 = 0

      最大 = 200

      Range2

      最小 = 200

      最大 = 500

      Range3

      最小 = 500

      最大 = ? ((500-200) + 500 = 800)


    4. その他の範囲で(最後の範囲以外で)最大値がない場合、表1-8に示すように、次の範囲で指定された最小値が使用されます。

      表1-8 その他の範囲に最大値がないゲージの範囲

      Range1

      最小 = 0

      最大 = 200

      Range2

      最小 = 200

      最大 = 600

      Range3

      最小 = 600

      最大 = 700


  3. 範囲が結び付いていない場合、表1-9を参照してください。

    表1-9 結付きのないゲージの範囲(10g)

    Range1

    最小 = 0

    最大 = 100 (赤)

    Range2

    最小 = 200

    最大 = 300 (黄)

    Range3

    最小 = 400

    最大 = 500 (緑)


    アップグレードされたゲージは、指定された「最小」/「低」の値に基づいてレンダリングされます。

    アップグレードされたゲージの範囲については、表1-10を参照してください。

    表1-10 結付きのないゲージの範囲(g)

    Range1

    最小 = 0

    最大 = 200 (赤)

    Range2

    最小 = 200

    最大 = 400 (黄)

    Range3

    最小 = 400

    最大 = 500 (緑)


  4. 指定された範囲に重複がある場合、表1-11を参照してください。

    表1-11 重複が指定されたゲージの範囲(10g)

    Range1

    最小 = 0

    最大 = 200

    Range2

    最小 = 100

    最大 = 500


    表1-12に示すように、アップグレードされた範囲は10gのゲージと同じにならない場合があります。

    表1-12 重複が指定されたゲージの範囲(11g)

    Range1

    最小 = 0

    最大 = 100

    Range2

    最小 = 100

    最大 = 500


  5. 指定された範囲がネストされている場合、表1-13を参照してください。

    表1-13 ネストされたゲージの範囲(10g)

    Range1

    最小 = 0

    最大 = 500

    Range2

    最小 = 100

    最大 = 200


    表1-14に示すように、アップグレードされた範囲は10gのゲージと同じにならない場合があります。

    表1-14 ネストされたゲージの範囲(11g)

    Range1

    最小 = 0

    最大 = 100

    Range2

    最小 = 100

    最大 = 200


  6. 最小値が最大値より大きい値に指定されている場合、表1-15を参照してください。

    表1-15 最大値より大きい最小値のゲージの範囲(10g)

    Range1

    最小 = 500

    最大 = 200

    Range2

    最小 = 100

    最大 = 200


    表1-16に示すように、アップグレードされた範囲は10gのゲージと同じにならない場合があります。

    表1-16 最大値より大きい最小値のゲージの範囲(11g)

    Range2

    最小 = 100

    最大 = 500 (同期化)

    Range1

    最小 = 500

    最大 = 200 (無視)


1.4.2.22 名前変更済のビューの更新

11gリリース1(11.1.1.6.0)より前のリリースでは、ビュー名の変更に、ビュー・セレクタ・ビューの「名前の変更」ボタンを使用していました。この名前の変更は、ビュー・セレクタ・ビュー内でのみ有効でした。11gリリース1(11.1.1.6.0)以降では、ビュー・エディタのツールバーにある新しい「名前の変更」ボタンを使用してビュー名を変更します。この名前の変更はグローバルに有効です。

前のリリースで名前が変更されているビューをアップグレードすると、その変更はグローバルに適用されます。2つのビュー・セレクタ・ビューがあり、それぞれに同じビューの名前を変更している場合は、最初のビュー・セレクタ・ビューの名前が使用されます。

1.4.2.23 その他の動作の変更

ビューのデータの表示に影響する構成設定に様々な変更が実装されました。たとえば、MaxVisibleRows要素により、その他すべての行の設定の最大値を管理します。これらの変更の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のビューのデータの表示および処理の構成に関する項を参照してください。

1.4.3 Oracle BI Presentation Catalog: 11gの注目の新機能

Oracle BI EE 11gのカタログに関して、次の機能を使用できます。

  • 階層列: リリース11gでは階層列が導入されました。この列のタイプには、名前付きレベルおよび親子関係の両方を使用して編成されたデータ値を保持します。この列は、ツリー状の構造を使用して表示されます。個々のメンバーは概要が表示されます。階層では、データをより深くドリルダウンして分析すると、より詳細な情報を表示できます。

  • 選択ステップ: 「選択ステップ」を作成して分析の列を連携できます。これらのステップは、分析の各ビューに横断的に実行され、分析の列のメンバー内で直感的で強力なグループ化、計算および選択が可能になります。列の値を含む計算は、分析時に容易に展開でき、カタログに単一の要素として保存できます。これらの保存された計算または選択は、カタログの分析間で即座に再利用できます。

  • カタログ・オブジェクト: 選択ステップ、条件およびアクションをカタログ・オブジェクトとして保存できるようになりました。これらはカタログ・オブジェクトとして保存することで、複数の分析の間で使用できます。

  • 複数のサブジェクト・エリア: 複数のサブジェクト・エリアからの列を含む分析を作成できます。

  • 計算関数: 分析内の中で新しい関数を使用できます。たとえば、リポジトリに設定されたメトリック集計ルールに従って、分析の特定のレベルで任意のメトリックを集計する集計対象関数を使用できます。また、動的時系列関数を使用すると、時間レベルを指定せずに時系列データを取得できます。

  • ズームおよびスライダ: グラフィックが強化され、インタラクティブなズームが導入されました。「セクション・スライダ」を使用すると、1つ以上の属性列または階層列のメンバーを長方形の棒上の値として表示し、値を選択するメカニズムを活用できます。セクション・スライダを使用して、グラフまたはゲージに表示されるデータを限定します。

Oracle BI Presentation Catalogの11gバージョンで使用できるその他の新機能の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』の新機能に関する項を参照してください。

1.5 BI Publisherのアップグレードについて

BI Publisherをアップグレードするには、2つの手順でアップグレード・アシスタントを実行します。BI Publisherリポジトリを1回アップグレードして、BI Publisherのスケジューラ・スキーマを1回アップグレードします。この項では、これらの2つのプロセスの概要について説明します。

BI Publisherリポジトリのアップグレード(レポートおよび構成ファイル)

BI Publisherリポジトリをアップグレードする場合、10gのレポートはアップグレードされて11gのリポジトリに配置されます。11gでのレポート定義の最も大きな変更はデータ・モデルがカタログの個別のオブジェクトとして独立したことです。10gから11gにアップグレードすると、10gのレポート・オブジェクトはレポート定義ファイル(.xdo)とデータ・モデル・ファイル(.xdm)に分割されます。分割されたオブジェクトを図1-5に示します。

図1-5 10gから11gへのレポートのアップグレード

図1-5の説明が続きます
「図1-5 10gから11gへのレポートのアップグレード」の説明

すべてのユーザーおよびロール、データソース定義、配信サーバー構成、システム・プロパティ設定などを含む管理ファイルは、11gインストールの新しい場所にコピーされ、リポジトリをアップグレードするときにすべての構成設定が保持されます。図1-6では、管理ファイルのアップグレードについて説明しています。

図1-6 管理ファイルのアップグレード

図1-6の説明が続きます
「図1-6 管理ファイルのアップグレード」の説明

スケジューラ・スキーマのアップグレード

アップグレード・アシスタントでは、10gのスケジュール・ジョブおよびジョブ履歴を、リポジトリ作成ユーティリティで作成された新しい11gのスケジューラ・スキーマにコピーします。図1-7では、スケジューラ・スキーマのアップグレードについて説明しています。

図1-7 スケジューラ・スキーマのアップグレード

図1-7の説明が続きます
「図1-7 スケジューラ・スキーマのアップグレード」の説明

アップグレード・アシスタントを実行する前に、特に注意する必要がある領域が多数あります。詳細は、第1.5.1項「BI Publisher: 主なアップグレードの考慮事項」を参照してください。

BI Publisherのアップグレードを計画する際に考慮する必要がある要素は前述のもの以外にも多数あります。詳細は、第1.5.2項「Oracle BI Publisher: その他のアップグレードの考慮事項」を参照してください。

元の10gシステムからアップグレードされた11gシステムへの外観および動作の変更に加えて、アップグレードされたシステムで実装の検討が必要な、Oracle Publisher 11gに新しく導入された機能が多数あります。詳細は、第1.5.3項「Oracle BI Publisher: 11gの注目の新機能」を参照してください。

1.5.1 BI Publisher: 主なアップグレードの考慮事項

次の項では、主なアップグレードの考慮事項について説明します。

1.5.1.1 Oracle WebLogic Serverへのデプロイ

Oracle Business Intelligence 10gと11gの機能的な違いは、Oracle WebLogic Serverにデプロイすることと、Oracle Business IntelligenceをOracle Fusion Middlewareに統合することです。詳細は、第4.1項「Oracle Business Intelligence 11gとOracle WebLogic Server」を参照してください。

1.5.1.2 セキュリティ・モデルの変更

BI Publisherのスタンドアロン・インストールをアップグレードする場合、アップグレード後もセキュリティ・モデルは変更されません。10gからのセキュリティ・モデルを保持できます。ただし、11gでは、Oracle Fusion Middleware Securityを実装することをお薦めします。このセキュリティ・モデルでは、Oracle WebLogic管理コンソールからユーザーおよびロールを管理します。セキュリティ・モデルの実装の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Publisher管理者ガイドのOracle Fusion Middlewareのセキュリティ・モデルの構成に関する項を参照してください。

BI PublisherをOracle BI EEに統合する場合、ユーザーおよびグループは10gのリポジトリ・ファイルからデフォルトの11gのアイデンティティ・ストア(Oracle WebLogic Serverが組み込まれたLDAPサーバー)に移行されます。10gのセキュリティ・モデルがBI Serverであった場合、アップグレード・アシスタントによりBI Serverは11gのセキュリティ・モデルとして保持されます。ただし、Oracle BI EEをOracle Fusion Middlewareのセキュリティ・モデルに移行する必要がある場合は、BI Publisher Administrationインタフェースのセキュリティ・モデルは、Oracle Fusion Middleware Securityにアップグレードする必要があります。詳細は、第1.6項「Oracle Business Intelligenceセキュリティのアップグレードについて」を参照してください。


注意:

BI Serverのセキュリティを引き続き使用する場合、11gで導入された共有のユーザー・インタフェース機能は、10gの初期化ブロックベースのセキュリティ・モデルには連携されません。


1.5.1.3 Oracle Business Intelligence Presentation Servicesとの共有カタログ

BI PublisherとOracle BI EEの統合されたバージョンでは、11gのカタログは完全にプレゼンテーション・サービスと共有されます。そのためには、BI PublisherカタログからPresentation Servicesカタログにアップロードする必須のアップグレード手順を一度だけ実行する必要があります。引き続きBI Publisherアプリケーションにも独立でアクセスすることはできますが、共有のインタフェースによりBusiness Intelligenceの機能が完全に統合されます。このアップグレード後の手順の詳細は、第8.2項「BI Publisherのアップグレード後のタスクと考慮事項」を参照してください。

1.5.1.4 レポートのアーキテクチャへの変更

11gでは、次のオブジェクトをカタログに独立に配置できます。

  • レポート

  • データ・モデル

  • サブ・テンプレート

  • スタイル・テンプレート(11gの新しいコンポーネント)

10gでは、データ・モデルはレポートに埋め込まれていました。11gでは、データ・モデルは独立のオブジェクトになり、複数のレポートで再利用できます。図1-8に、11gでのレポートとデータ・モデル・オブジェクトとの関係を示します。

図1-8 BI Publisher 11gのレポートとデータ・モデル

11gのレポートとデータ・モデルの図
「図1-8 BI Publisher 11gのレポートとデータ・モデル」の説明

次の点に注意してください。

  • 単一のデータ・モデルは、複数のレポートで使用することはできません。

  • データ・モデルからのパラメータはレポート・レベルでカスタマイズできます。

  • データ・モデルに複数のバースト定義を作成してからレポート・レベルで選択できます。

10gでは、サブ・テンプレートはBI Publisherリポジトリの外側に配置されていました。11gでは、サブ・テンプレートはカタログ内のオブジェクトとして保持されます。詳細は、第1.5.3.8項「カタログのサブ・テンプレートの管理」を参照してください。

スタイル・テンプレートは11gで導入された特別なテンプレートであり、スタイルシートと同様に複数のレポートでのスタイルの管理が簡略化されます。詳細は、第1.5.3.7項「スタイル・テンプレートを使用した一貫性ルック・アンド・フィール」を参照してください。

1.5.1.5 強化されたカタログ・オブジェクト・セキュリティ

10gでは、カタログ・オブジェクトへのアクセス権の付与は「管理」のロールと権限ページで実行されていました。レポートを実行するユーザー・ロール・アクセス権を付与するには、管理者がロールと権限ページでレポートが存在するフォルダをロールにマップします。そのロールを持つユーザーはすべてそのフォルダの任意のレポートを表示する権限があります。

11gでは、権限の付与は権限タスクを使用してカタログ内で実行されます。新しい一連の権限は、ユーザーができることをより詳細に定義できるようになりました。次のような権限があります。

  • 読取り

  • 書込み

  • 削除

  • オンラインでのレポートの実行

  • レポートのスケジュール

  • レポート出力の表示

レポート・カスタマがレポートを正常に実行するためには、レポートが参照するすべてのオブジェクトに対してそのユーザーに読取り権限を付与する必要があります。たとえば、10gでは、従業員給与レポートを実行するためにユーザーに必要なのは、そのレポートが存在するフォルダへのアクセス権のみでした。11gでは、データ・モデルは独立のオブジェクトになったため、ユーザーはそのデータ・モデル・オブジェクトの読取り権限も必要になります。レポートで参照するオブジェクトが追加された場合(スタイル・テンプレートやサブ・テンプレートなど)、それらのオブジェクトの読取り権限も付与する必要があります。

また、11gでは、データソースにアクセスする必要があるすべてのロールは、レポートを表示するだけであっても、そのデータソースへのアクセス権を付与する必要があります。そのためには、BI Publisher管理ページでデータソースにロールを割り当てる必要があります。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Publisher管理者ガイドのデータ・アクセス権の付与に関する項を参照してください。

1.5.2 BI Publisher: その他のアップグレードの考慮事項

次の項では、その他のアップグレードの考慮事項について説明します。

1.5.2.1 BI PublisherファイルベースのカタログまたはOracle BI Presentation Catalogのサポート

リリース11gでは、次のカタログ・タイプがサポートされます。

  • Oracle BI Publisher - ファイル・システム。スタンドアロン実装用

  • Oracle BI Presentation Catalog。統合実装用

10gのオプションのXML DBリポジトリ・タイプは、11gのオプションではありません。

1.5.2.2 Discovererワークブックがデータセット型としてサポートされない

10gの実装にデータソースとしてDiscovererワークブックを使用するレポートが含まれている場合、それらのレポートは11gでは実行できません。引き続きレポートのDiscovererデータを使用するためには、BI PublisherでSQL文を直接発行してデータを取得できるように、DiscovererワークブックからSQL問合せを手動でコピーしてBI Publisherに新しいデータ・モデルを作成します。

1.5.2.3 10gと11gのレポートの互換性

次の一覧は、レポートの互換性についてまとめたものです。

  • 10gからレポートをダウンロードして、それを単純に新しい11g環境にアップロードして実行することはできません。10gのレポートはすべて最初にアップグレード・アシスタントでアップグレードする必要があります。

  • 11gからレポートをダウンロードして、それを単純に10g環境にアップロードして実行することはできません。下位互換性はありません。

  • 10gで作成されたテンプレートを11gで作成するレポートで使用することはできません。

  • Template Builderを下位互換モードで実行する場合、BI Publisher Template Builder for Word 11gを使用して10gのレポートを設計できます。下位互換モードは、Template Builderの「オプション」ダイアログから設定できます。

1.5.2.4 アップグレードされたデータ・モデルが編集できない

10gのレポート・データ・モデルでデータソース・タイプとしてSQL問合せまたはBI Answersを使用している場合、アップグレード後はデータセットにデータ・モデル・エディタの列情報が表示されなくなります。これは、10gのデータセット・タイプが新しい11gデータ・モデルの列への移入に必要な情報を取得できないために発生します。このデータ・モデルは、アップグレード後も変更せずに機能し続けますが、将来このデータ・モデルを編集することが困難になる場合があります(たとえば、計算された列の追加やその他のデータセットへのリンクの作成ができなくなります)。

データセットをアップグレードされたまま保持するようにしても、後で必要に応じてそれを編集して、元のデータセットから同じSQL問合せをコピーしてその元のデータセットを削除することができます。新しいデータセットを作成する場合、生成されたXML構造と要素名は、そのレポートのデータ・モデルを使用するテンプレートと一致する必要があります。RTFテンプレートを更新する作業は手間がかかるので、かわりにデータ・モデル・エディタの「構造」ペインを使用してXML要素名に更新できます。

1.5.2.5 11gにアップグレードされたデータ・テンプレートで検証エラーが発生する

データ・モデル・エディタには、10gにはなかったデータ・モデルの制限が導入されています。そのため、10gで有効であったデータ・テンプレートベースのデータ・モデルを保存しようとすると、警告メッセージが表示される場合があります。次の2つの新しい制限に注意する必要があります。

  • 大文字/小文字の区別

    10gのデータ・テンプレートでは、データ・テンプレート内の要素は、大文字/小文字に関係なく参照できました。そのため、"G_EMP.salary"でも'G_EMP.SALARY'でも参照が可能でした。11gでは、参照するアイテムの大文字/小文字は一致する必要があります。

  • 独立した要素

    10gでは、データ・テンプレートでSQL問合せに存在しない列を参照する要素名を宣言することができました。10gでは、このような状況でその要素にnull値を返していました。11gでは、このような構造が存在すると、不正な警告が発生します。この問題を修正するには、データ・モデル・エディタを使用して列を削除します。

1.5.2.6 10gの統合用Webサービスを使用したアプリケーションに必要なアプリケーション・コードの変更

BI Publisherと統合するためのWebサービスAPIを使用するアプリケーションがある場合、カスタム・アプリケーションでBI Publisher機能を実装し続けるようにアプリケーション・コードを更新する必要があります。11gのWebサービスの詳細は、Oracle Fusion Middleware Oracle Business Intelligence Publisher開発者ガイドを参照してください。

1.5.2.7 10gと11gのサブ・テンプレートの実装の違い

10gにサブ・テンプレートを使用するレポートがある場合、使用されていたインポート・プロトコルがHTTPまたはFTPであれば、11gにアップグレード後もそれらのサブ・テンプレートは機能し続けます。Fileプロトコルを使用していた場合、サブ・テンプレートを手動で11gのサーバーにコピーして10gと同じ相対パスを指定する必要があります。11gのBI Publisherでは、サブ・テンプレートはカタログ・オブジェクトとして導入されています。10gのサブ・テンプレートをカタログに移行して、強化されたセキュリティおよび管理機能を使用することをお薦めします。また、この移行では、テンプレートをコールする際のimport構文を更新する必要があります。詳細は、第1.5.3.8項「カタログのサブ・テンプレートの管理」を参照してください。

1.5.3 BI Publisher: 11gの注目の新機能

次の項で11gの新機能について説明します。

1.5.3.1 グラフィカルWebベースのレポート設計ツール

図1-9にBI Publisherのレイアウト設計ツールを示します。

図1-9 BI Publisherのレイアウト・エディタ

図1-9の説明が続きます
「図1-9 BI Publisherのレイアウト・エディタ」の説明

レイアウト・エディタの利用対象者はビジネス・ユーザーおよびレポートの開発者です。このレイアウト・エディタは、PDF、RTF、Excel、PowerPointおよびHTMLでピクセル・パーフェクトのレポートを作成するための、直感的なドラッグ・アンド・ドロップ・インタフェースを提供する新しいブラウザベースのグラフィカル設計ツールです。これは、ブラウザを介して軽量な相互作用をサポートする動的HTML出力も提供します(第1.5.3.2項「レポートの相互作用性」を参照)。データ・モデルのサンプル・データを使用すると、コンポーネントをレイアウトに追加したときに、レイアウト・エディタにより設計がそのデータで即座に更新されるため、最終製品の外観を正確に把握できます。

1.5.3.2 レポートの相互作用性

図1-10にインタラクティブ・ビューアを示します。

図1-10 BI Publisherのインタラクティブ・ビューア

図1-10の説明が続きます
「図1-10 BI Publisherのインタラクティブ・ビューア」の説明

レイアウト・エディタで設計されたレポートは、ピクセル・パーフェクトな形式で出力が生成されるだけでなく、より深い洞察力を得るためのデータの相互作用もサポートします。レポート内のチャートまたはピボット表をクリックすると、そのアイテムに応じてレポートに表示されるすべてのデータが自動的に更新およびフィルタ処理されます。インタラクティブ・ビューアにより、1つのレポートを、印刷可能な出力およびオンラインの相互作用性の両方の要件を満たすように作成できます。

1.5.3.3 データ・モデル・エディタによるデータの取得および構造化

図1-11に、データ・モデル・エディタを示します。

図1-11 BI Publisherのデータ・モデル・エディタ

図1-11の説明が続きます
「図1-11 BI Publisherのデータ・モデル・エディタ」の説明

BI Publisher 11gでは、レポート・データ・モデルを作成するためのデータ・モデル・エディタが導入されました。データ・モデル・エディタにより、SQL、Excelファイル、Webサービス、HTTPフィード、その他のアプリケーションなど、様々なデータソースの複数のデータセットから単一のXML構造にデータを組み合せることができます。データ・モデルのWebユーザー・インタフェースで、問合せの作成、データのリンク、計算の作成、データ構造の定義をすべて実行できます。データ・モデル・エディタでは、複数のレポートで使用できる独立のカタログ・オブジェクトとしてデータ・モデルを保存します。

1.5.3.4 追加のデータソースのサポート

BI Publisher 11gのデータ・モデル・エディタでは、10gで使用できなかった次のソースからデータを取得することができます。

  • Excelワークブック

    ExcelワークブックをBI Publisherが接続できる中央の場所にアップロードするか、単純にワークブックをローカル・クライアント・ディレクトリからデータ・モデル・エディタにアップロードします。ワークブックのデータをその他のデータセットのデータにリンクしたり、出力構造を変更することができます。

  • LDAPディレクトリ

    このリリースでは、Lightweight Directory Access protocol(LDAP)データソースに対する問合せがサポートされます。LDAPディレクトリに保存されているユーザー情報を問い合せて、データ・モデル・エディタを使用してその他のデータソースから取得したデータとそのユーザー情報をリンクできます。

  • ビュー・オブジェクト

    BI Publisherでは、Oracle Application Development Frameworkで構築されたカスタム・アプリケーションに接続して、レポートのデータソースとしてアプリケーションでビュー・オブジェクトを使用できます。

  • CLOB XML

    データ・エンジンは、キャラクタ・ラージ・オブジェクト(CLOB)データ型としてデータベース列に保存されている整形式XMLデータを抽出して、その構造を保持できるようになりました。この機能により、個々のプロセスで生成され、BI Publisherデータ・モデルへの入力としてデータベースに保存されているXMLデータを使用することができます。

1.5.3.5 スケジュールされたジョブ管理の強化

BI Publisher Schedulerの最新のアーキテクチャでは、Java Messaging Service(JMS)キュー・テクノロジを使用します。このアーキテクチャを使用して、複数のBI Publisherサーバーをクラスタに追加してから各サーバーを特定の機能専用のサーバーに指定することができます(レポート生成、ドキュメント生成、特定の配信チャンネルなど)。そのようにすることで、大量のスケジュールされたジョブに応じてPublisherをスケールアップすることができるため、柔軟性が高まります。さらに、Scheduler Diagnosticsツールを使用して、すべてのプロセッサのステータスおよび現在の負荷をリアルタイムで表示することができます。

1.5.3.6 監査および監視機能

11gの監査フレームワークにより、管理者はデータを収集してユーザー・アクティビティおよびBI Publisherとの相互作用を監査および監視できます。また11gには、BI Publisherを使用してデータを表示および分析できるように、すべてのデータをデータベース表に格納する新しいフレームワークが含まれます。強化された監査機能を使用して、管理者はユーザーがしたいこと、ユーザーがレポートにアクセスおよび表示する方法、および使用時間のピークを理解することで、コンプライアンス要件を上回るまでにカスタマ・サービスを向上させることができます。

1.5.3.7 スタイル・テンプレートを使用したルック・アンド・フィールの一貫性

スタイル・テンプレートとは、エンタープライズ・レポート全体でルック・アンド・フィールの一貫性を実現するための、複数のRTFレイアウトに適用するスタイル情報を定義するRTFテンプレートです。スタイル・テンプレートは、レポート定義でレポート・レイアウトに関連付けます。また、レポートを横断して一貫性のあるスタイルを簡単に適用するために、ヘッダーおよびフッター・コンテンツを定義することもできます(たとえば、複数のレポートにわたって適用され単一のテンプレートに保持できる会社ロゴ、見出し、ページ番号など)。

1.5.3.8 カタログでのサブ・テンプレートの管理

RTFテンプレートでサブ・テンプレートを使用する場合、サブ・テンプレートをカタログのオブジェクトとして保持できるようになりました。既存のサブ・テンプレートでこの新機能を利用するには、プライマリRTFテンプレートでコールする構文を、BI Publisherがサブ・テンプレートの新しい場所を指すように変更する必要があります。11gのサブ・テンプレートの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Publisherレポート・デザイナーズ・ガイド』のサブ・テンプレートの作成および実装に関する項を参照してください。

1.6 Oracle Business Intelligence Securityのアップグレードについて

Oracle Business Intelligence 11gのセキュリティ・ポリシーでは、個々のユーザーおよび特定のアプリケーション・ロールを持つユーザーがアクセスできるオブジェクトおよび実行できる作業を定義します。Oracle Business Intelligence 11gでは、セキュリティ・ポリシーの定義は次のように分割されます。

Oracle Business Intelligence10gと11gのセキュリティ・モデルは、次の領域で異なります。

Oracle Business Intelligence 10gのセキュリティ・モデルの次の部分は、11gでも維持されています。

Oracle Business Intelligenceのセキュリティの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。

アップグレード・プロセス時に、既存の10gのセキュリティ・メカニズムはアップグレードされます。

アップグレード・プロセスでは、10gでサポートされるセキュリティ・メカニズム(リポジトリ・ユーザーおよびグループ、認証を初期化ブロック、カタログ・グループ、SAシステム・サブジェクト・エリアなど)を任意に組み合せて処理します。

ただし、アップグレード・アシスタントを実行する前に、注意する必要があるOracle BIのセキュリティ領域が多数あります。詳細は、第1.6.1項「Oracle BI Security: 主なアップグレードの考慮事項」を参照してください。

第1.6.1項で説明されている領域のほかに、BIのセキュリティを計画する際に考慮する必要がある要素は多数あります。詳細は、第1.6.2項「Oracle BI Security: その他のアップグレードの考慮事項」を参照してください。

1.6.1 Oracle BI Security: 主なアップグレードの考慮事項

次の一覧に示すように、ユーザー、グループおよび資格証明が定義および保存される方法および場所に関するセキュリティ・モデルに大きな変更がありました。セキュリティの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。

  • ユーザー、パスワードおよびグループは、デフォルトの10gリポジトリ・ファイルからデフォルトの11gアイデンティティ・ストア(Oracle WebLogic Serverが組み込まれたLDAPサーバー)に移行されます。リポジトリ・グループはポリシー・ストアの一致するアプリケーション・ロールを受け取ります。その他すべての認証メカニズムは、10gと同様です。

    10gで別のLDAPサーバーを使用していた場合、アップグレードされた11gシステムでも初期化ブロックを介して引き続き10gで指定されていたLDAPサーバーを指定します。条件によっては、それらの初期化ブロックをWebLogic認証プロバイダに置き換えることができます。

    Oracle Identity Management(OID)などの別のLDAPサーバーを使用する場合は、まず組込みのLDAPサーバーをアップグレードしてから、本番のLDAPサーバーに移行します。実際はアップグレード前に11g環境を別のセキュリティ・モデルに構成することは可能ですが、環境は組込みのLDAPサーバーにアップグレードされてしまいます。

    プレゼンテーション・サービス・グループ(「カタログ・グループ」および「Webグループ」ともいいます)は下位互換性の目的でのみ使用し、新しいインストールにはアプリケーション・ロールを使用することをお薦めします。

  • 接続プールやLDAPサーバーなどのその他のリポジトリ・オブジェクトのパスワードは、リポジトリに維持され、暗号化されます。リポジトリ自身も暗号化されます。

  • Administratorユーザーはデフォルトの10gリポジトリ・ファイルからデフォルトのアイデンティティ・ストアに移行され、BIAdministratorsグループのメンバーになります。BIAdministratorsグループはBIAdministratorロールが付与され、その関連付けによりシステム管理者の権限を持ちます。

  • Oracle BI Presentation Catalogの古いグループおよびユーザーへの参照は更新されます。

  • ROLES、PERMISSIONS、USERGUIDおよびROLEGUIDSという変数名は、11gシステムで予約された変数名になります。10gのリポジトリ・ファイルをアップグレードする前に、それらの名前が存在していたら、それを変更する必要があります。ほかにもレポートなどにそれらの変数名への参照があった場合、一貫性を維持するためにその名前を変更する必要があります。

  • 「全員」プレゼンテーション・サービス・グループは、AuthenticatedUserロールに置き換えられました。これは、認証済ロールのApplication Roleと同じです。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のダッシュボードおよび分析のセキュリティの管理に関する項を参照してください。

  • 10gの「プレゼンテーション・サービス管理者」というプレゼンテーション・サービス・グループを引き続き使用する場合、それに属するユーザーをこのプレゼンテーション・サービス・グループに再割当てする必要があります。かわりに、それらのユーザーには既存の最適なApplication Roleを使用するか、新しいApplication Roleを作成することをお薦めします。

  • USER、GROUPまたはROLESセッション変数を設定する初期化ブロックは、Fusion Middlewareのセキュリティ機構を通じてシステムにログインするユーザーの11g環境では実行されなくなります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のOracle Business Intelligenceのセキュリティ設定の詳細な手順に関する項を参照してください。

1.6.2 Oracle BI Security: その他のアップグレードの考慮事項

11gにアップグレードする際は、セキュリティに関する次の考慮事項に注意してください。

1.6.2.1 アイデンティティ・ストアに影響する変更

アップグレード・アシスタントでは、ターゲット・システムのOracle WebLogic Serverが組み込まれたLDAPサーバーに次のエントリを作成します。

  • リポジトリの各グループに対応するLDAPグループ。これには、以前のリリースに存在していたAdministratorsグループは含まれません。Administratorsグループに存在していたユーザーは、BIAdministrators LDAPグループに追加されます。

  • リポジトリ・グループ階層に一致するLDAPグループ階層。

  • Administratorユーザーは移行されて、BIAdministratorsグループの一部になります。

指定されたリポジトリのAdministratorsグループのメンバーであるAdministratorユーザー以外のすべてのユーザーは、組込みのLDAPサーバーのBIAdministratorsグループに追加されます。インストール時に指定した情報から作成した11gのAdministratorユーザーも組込みのLDAPサーバーのBIAdministratorsグループに追加されます。

1.6.2.2 ポリシー・ストアに影響する変更

アップグレード・アシスタントでは、ターゲット・システムのファイルベース・ポリシー・ストアに次のエントリを作成します。

  • 指定されたリポジトリの各グループに対応するApplication Role。これには、以前のリリースに存在していたAdministratorsグループは含まれません。Application Roleは同じ名前を持つグループに付与されます。

  • リポジトリ・グループ階層に一致するApplication Role階層

1.6.2.3 リポジトリ・ファイルに影響する変更

アップグレード・アシスタントでは、指定されたOracle BIメタデータ・リポジトリを自動的にアップグレードして、次の変更を行います。

  • 指定された10gリポジトリのすべてのグループは、アップグレード時にポリシー・ストアに作成されたApplication Role参照(プレースホルダ)に変換されます。

  • すべてのユーザーは、アップグレード時に指定されたリポジトリから削除され、ターゲット・システムの組込みのLDAPサーバーに作成されたLDAPユーザーへの参照(名前とGUID)に置き換えられます。

11gシステムにアップグレードされたリポジトリには、次の特徴があります。

  • アップグレードされたリポジトリは、アップグレード時に入力されたパスワードで保護され暗号化されるようになりました。

  • リポジトリ・ファイルは、アイデンティティ・ストアに存在すると想定されるユーザーへの参照、およびポリシー・ストアに存在すると想定されるApplication Rolesへの参照が含まれるようにアップグレードされます。

  • アップグレードされたリポジトリ・ファイルの名前に、数字の接尾辞が追加されます。追加された数字は、ファイルがアップグレードされた回数を示します。

アップグレードされたリポジトリは、通常どおり、Oracle BI管理ツールでオフライン・モードで開くことができ、オンライン・モードで開くOracle BI Serverにデプロイできます。

1.6.2.4 Oracle BI Presentation Catalogに影響する変更

アップグレード・アシスタントでは、自動的にOracle BI Presentation Services Catalogに次のような変更を行います。

  • カタログはスキャンされて、古いセキュリティ表現は新しいものに変換されます。10gに存在していた権限は移行されます。アップグレードされたOracle BI Presentation Catalogの各ユーザーは、ユーザー名および新しいGUID属性を使用して参照されます。この属性は各ユーザーで一意の値を持ちます。GUID属性の値は、Oracle BI EEが使用するアイデンティティ・ストアから継承されます。そのため、後でアイデンティティ・ストアを切り替える場合、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』の指示に従ってGUIDを更新してください。

  • アップグレード・プロセスでは、10gのカタログ・グループをアップグレードされたカタログにそのまま残し、同じ権限、アクセス権、およびメンバーシップを割り当てます。

1.6.2.5 既存のSSL環境のアップグレード

SSL設定などの構成設定は、アップグレード・ソースから引き継がれません。

Oracle BI EE 11g(11.1.1.7)以上では、NQSConfig.INIファイルのSSL_VERIFY_PEERパラメータが非推奨となりました。10gシステムのアップグレード時(または以前の11gシステムからの移行時)には、SSL_VERIFY_CLIENTSおよびSSL_VERIFY_SERVERSパラメータで、以前はSSL_VERIFY_PEERパラメータによって制御されていた同等の機能を置き換えることに注意してください。SSL_VERIFY_CLIENTSおよびSSL_VERIFY_SERVERSパラメータは、Fusion Middleware Controlによって集中管理されています。システムがアップグレードまたはパッチ適用され、管理対象サーバーが再起動されると、次のようになります。

  • SSL_VERIFY_CLIENTSおよびSSL_VERIFY_SERVERSパラメータは、NQSConfig.INIファイルに含められます。

  • SSL_VERIFY_PEERパラメータはファイルから削除されます。

SSLの構成に関する詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のOracle Business IntelligenceのSSLの構成に関する項を参照してください。

1.6.2.6 既存のSSO環境のアップグレード

シングル・サインオン(SSO)設定などの構成設定は、アップグレード・ソースから引き継がれません。SSOの構成に関する詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のSSO認証の有効化に関する項を参照してください。

1.6.3 Oracle BI Security: 11gの注目の新機能

Oracle BI EE 11gでは、次のセキュリティ機能を使用できます。

  • Fusion Middlewareセキュリティ・モデル

  • LDAPサーバーへの直接アクセス

  • 簡素化されたSSL構成

  • 強化された管理権限を管理するモデル

  • リポジトリの保護および暗号化

新機能の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のOracle Business Intelligenceセキュリティの新機能に関する項を参照してください。

1.7 11.1.1.3、11.1.1.5または11.1.1.6から11.1.1.7への移行

Oracle BI EE 11.1.1.3、11.1.1.5または11.1.1.6から11.1.1.7への移行は、10gから11gへの移行とは異なります。たとえば、Oracle Fusion Middlewareアップグレード・アシスタントを使用するかわりに、パッチセット・アシスタントなど様々なツールを使用します。

その他の重要な違いは、10gから11gへのアップグレードが「アウトオブプレース・アップグレード」と呼ばれているのに対し、別の11gリリースへの移行は「インプレース・アップグレード」と呼ばれていることです。これは、既存のファイルに対して新しいソフトウェアを適用することに起因しています。また、ある11g リリースから別の11g リリースへの移行は、パッチセットの適用とも呼ばれます。

詳細な手順は、『Oracle Fusion Middlewareパッチ適用ガイド』を参照してください。表1-17に手順の概要を示します。

11gリリース1(11.1.1.5.0)または以降のリリースから開始する場合は、必ずしも表1-17のすべての手順が必要ではないことに注意してください。詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』の参照先情報を参照してください。

表1-17 Oracle BI 11.1.1.7パッチセットの適用手順の概要

ステップ 説明 実行する場合 手動で実行する、またはコンフィギュレーション・アシスタントを使用する 手動手順に関する情報

1

次の一般的なアップグレード前のタスクを実行します。

  • アップグレードする必要があるMiddlewareホームを使用するすべてのOracle BIドメインを構成するすべてのWebLogic Server、ノード・マネージャ、OPMN、およびOPMN管理のシステム・コンポーネントを停止します。

    Windowsシステムでは、Oracle WebLogic NodeManager(名前)というコンポーネントも停止します。

  • ディレクトリをバックアップします。

アップグレードするBIドメインの一部である各コンピュータでこの手順を実行します。

手動手順のみ。

Oracle Fusion Middlewareパッチ適用ガイド』の一般的なパッチ適用前タスクの実行に関する項を参照。

2

適切な製品インストーラをダウンロードします。

このインストーラのファイルを取得する手順を1回実行します。複数回使用することもできます。

手動手順のみ。

Oracle Fusion Middlewareパッチ適用ガイド』のインストーラのダウンロードに関する項を参照。

3

Oracle WebLogic Serverにパッチを適用し最新バージョンにします。

リリース11.1.1.3から移行する場合、Oracle WebLogic Serverにパッチを適用していることを確認します。

アップグレードするBIドメインを構成する各コンピュータでこの手順を実行します。Middlewareホームが共有されている場合は、この手順を1回のみ実行します。

手動手順のみ。

『Oracle Fusion Middlewareパッチ適用ガイド』の最新のOracle Fusion Middlewareパッチ・セットの適用に関する項を参照。

4

Oracle BI Product Installerを実行してから、ソフトウェアのみのインストールを実行します(パッチを適用する既存のMiddlewareホームを指定します)。

アップグレードするBIドメインを構成する各コンピュータでこの手順を実行します。Middlewareホームが共有されている場合は、この手順を1回のみ実行します。

手動手順のみ。

Oracle Fusion Middlewareパッチ適用ガイド』のインストーラの起動に関する項を参照。

5

次のリストにあるように、RCUで作成されたそれぞれのOracle BIスキーマでパッチ・セット・アシスタントを実行します。最初にMDSスキーマを更新します。

  • MDS

  • BIPLATFORM

ドメインごとにこの手順を1回実行します。

手動手順のみ。

Oracle Fusion Middlewareパッチ適用ガイド』のパッチ・セット・アシスタントの使用開始前の処理に関する項、および更新後のスキーマ・バージョン番号の検証に関する項を参照。

6

様々なシステム・コンポーネントをアップグレードします。

ドメインごとにこの手順を1回実行します。

手動手順またはコンフィギュレーション・アシスタントのどちらかを使用します。

Oracle Fusion Middlewareパッチ適用ガイド』のシステム・コンポーネントのアップグレードに関する項を参照。

7

ライブラリを更新します。

ドメインごとにこの手順を1回実行します。

手動手順またはコンフィギュレーション・アシスタントのどちらかを使用します。

Oracle Fusion Middlewareパッチ適用ガイド』のFusion Middlewareの共有ライブラリの更新に関する項を参照。

8

構成およびストアを更新します。

ドメインごとにこの手順を1回実行します。

手動手順またはコンフィギュレーション・アシスタントのどちらかを使用します。

Oracle Fusion Middlewareパッチ適用ガイド』の構成およびストアの更新に関する項を参照。

9

Oracle BI EEのコード付与(セキュリティ・ポリシー・アーティファクト)をアップグレードします。

ドメインごとにこの手順を1回実行します。

手動手順またはコンフィギュレーション・アシスタントのどちらかを使用します。

Oracle Fusion Middlewareパッチ適用ガイド』のOracle Business Intelligenceコード付与のアップグレードに関する項を参照。

10

カタログをアップグレードします(Oracle BI EEがインストールされている場合のみ適用されます)。

ドメインごとにこの手順を1回実行します。

手動手順またはコンフィギュレーション・アシスタントのどちらかを使用します。

Oracle Fusion Middlewareパッチ適用ガイド』のOracle Business Intelligence Catalogsの更新に関する項を参照。

11

bicontentserver機能を有効化します(リリース11.1.1.5.0から移行する場合のみ適用されます)。

ドメインごとにこの手順を1回実行します。

手動手順またはコンフィギュレーション・アシスタントのどちらかを使用します。

Oracle Fusion Middlewareパッチ適用ガイド』のbicontentserver機能の有効化に関する項を参照。

12

BIコンポーザの機能をインストールおよび構成します

ドメインごとにこの手順を1回実行します。

手動手順またはコンフィギュレーション・アシスタントのどちらかを使用します。

第1.7.2章「BIコンポーザの手動による有効化」を参照してください。

Oracle Fusion Middlewareパッチ適用ガイド』のOracle Business Intelligenceコンポーザの機能の有効化に関する項を参照。

13

Oracle Business IntelligenceのSmart Viewクライアント用JBIPS構成テンプレート機能を有効化します。

ドメインごとにこの手順を1回実行します。

手動手順またはコンフィギュレーション・アシスタントのどちらかを使用します。

Oracle Fusion Middlewareパッチ適用ガイド』のJBIPS機能の有効化に関する項を参照。

14

サーバーおよびプロセスを起動します。

ドメイン内のコンピュータごとにこの手順を1回実行します。

手動手順またはコンフィギュレーション・アシスタントのどちらかを使用します。

『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceの起動と停止に関する項を参照。

15

Oracle Real-Time Decisionsインストールした場合は更新します。

ドメインごとにこの手順を1回実行します。

手動手順のみ。

Oracle Fusion Middlewareパッチ適用ガイド』のOracle Real-Time Decisionsの更新に関する項を参照。

16

Oracle BI EEがインストールされている場合、それを起動してアップグレードされたインストールを検証します。

インストール全体に対してこの手順を1回実行します。

手動手順のみ。

Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』のOracle BI Enterprise Editionへのサインインに関する項を参照。


表1-17で説明されているすべての手順を手動で実行できます。手順については『Oracle Fusion Middlewareパッチ適用ガイド』で説明しています。

表1-17は、コンフィギュレーション・アシスタントを使用して以前の11gリリースからリリース11.1.1.7.0に移行するための手順の多くを実行できることを示しています。コンフィギュレーション・アシスタントを実行すると、1つの操作で多くのタスクを完了してBIドメインをアップデートできます。詳細は、第1.7.1章「コンフィギュレーション・アシスタントを実行してドメインをアップデートする」を参照してください。

1.7.1 コンフィギュレーション・アシスタントを実行してドメインをアップデートする

コンフィギュレーション・アシスタントを使用すると、以前の11gリリースからリリース11.1.1.7.0に移行するための手順の一部を1つの操作で実行できます。これらのタスクの詳細は、表1-17を参照してください。

コンフィギュレーション・アシスタントを実行してBIドメインをアップデートするには、次の手順を実行します。

  1. 表1-17の手順1から5を手動で実行します。

  2. ノード・マネージャおよび管理サーバーを起動します。

  3. コマンドラインで、次を入力します。

    UNIXの場合:

    ORACLE_HOME/bin/config.sh

    Windowsの場合:

    ORACLE_HOME\bin\config.bat

  4. 「ようこそ」画面および「前提条件チェック」画面で、「次へ」をクリックします。

  5. 「作成」、「スケール・アウト」または「拡張」画面でBIドメインの更新を選択します。

  6. アップグレードするシステムの管理サーバーのホスト名、ポート番号、ユーザー名およびパスワードを指定します。

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

  8. BIドメイン詳細の更新画面で、それぞれの「ホーム」フィールドに適切なディレクトリが指定されていることを確認します。

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

    アップグレード・プロセスの進捗情報が構成プロセス画面に表示されます。

  10. アップグレード・プロセスが完了したら、「終了」をクリックします。

コンフィギュレーション・アシスタントを使用してBIドメインをアップデートするときは、次の点に注意してください。

  • 「簡易インストール」タイプで作成したOracle Business IntelligenceシステムのBIドメインの更新には、コンフィギュレーション・アシスタントを使用できません。

  • 適用される変更が有効になるよう、コンフィギュレーション・アシスタントによって適切な時点でシステムが再起動されます。

  • コンフィギュレーション・アシスタントは、クラスタ化されたOracle Business Intelligenceシステムのプライマリ・ノードのアップグレードにのみ使用できます。後で管理サーバーを再起動したときに、すべての変更がセカンダリ・ノードに伝播されます。

  • 対話形式でコンフィギュレーション・アシスタントを使用して以前の11gリリースからアップグレードできるほか、レスポンス・ファイルに次の行を追加することでコンフィギュレーション・アシスタントをサイレント・モードで実行することもできます。

    UPDATE_BIDOMAIN=true

    コンフィギュレーション・アシスタントのサイレント・モードでの実行の詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』を参照してください。

1.7.2 BIコンポーザの手動による有効化

コンフィギュレーション・アシスタントまたは構成ウィザードを実行すると、BIコンポーザに必要なファイルが自動的にインストールされます。ユーザーによるBIコンポーザの実行を可能にする前に、MBeanを使用するBIコンポーザを手動で有効化する必要があります。

BIコンポーザを手動で有効化するには

  1. Fusion Middleware Control MBeanブラウザを表示し、ドメインをロックします。

  2. 次のフォルダにナビゲートします。

    Application Defined MBeans, oracle.biee.admin, Domain:bifoundation_domain, BIDomain.BIInstance.PresentationConfiguration

  3. 次のMBeanを探します。

    oracle.biee.admin:type=BIDomain.BIInstance.PresentationConfiguration,biInstance=coreapplication,group=Service

  4. BIComposerEnabled属性の値を"true"に設定します。

  5. 変更をコミットし、システムを再起動します。

MBeanの更新の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のFusion Middleware Control MBean Browserの使用による構成設定の更新に関する項を参照してください。

1.8 Oracle BI Applicationsカスタマに関する考慮事項

Oracle BI Applicationsシステムの一部として使用するOracle BI EE 11gにアップグレードする前に、アップグレード対象のOracle BI Applicationsリリースに付属のOracle Business Intelligence Applicationsアップグレード・ガイドを必ず参照して、実行する手順を確認してください。たとえば、アップグレード元のOracle BI Applicationsのリリースに応じて、Oracle BI Applicationsの新しいリリースへのアップグレードの最初の手順は、使用しているOracle BI EEのリリースをアップグレードすることになる場合があります。

Oracle BI Applicationsリリースには、ETLテクノロジ・コンポーネントがあります。ハードウェア、プラットフォーム、およびサポートされるデータベースは、Oracle BI EEでサポートされるもの(通常はそのサブセット)と異なる場合があります。必ずOracle BI Applicationsの動作保証およびシステム要件の情報を調べて、特定のリリースのOracle BI ApplicationsにはどのリリースのOracle BI EE 11gの動作が保証されているか確認してください。動作要件とシステム要件のドキュメントの場所の詳細は、第1.2.1章を参照してください。

Oracle BI Applicationsリリース7.9.6.4(このガイドの公開日時点で最新の利用可能なBI Applicationsリリース)はOracle BI EEリリース11g (Oracle BI EE 11.1.1.6.4以降)上で動作保証されています。7.9.6.4より前のOracle BI Applicationsリリースを使用している場合は、Oracle BI EEリリース11gの現在の情報について、動作保証およびシステム要件のドキュメントを参照してください。

通常のアップグレードと同様に、現在Oracle BI EE 10gを使用しているOracle BI Applicationsカスタマは、Oracle BI EE 11gの新機能を利用することで得られるビジネス利益を勘案して、Oracle BI EE 11gにアップグレードするタイミングを検討し、Oracle BI Applicationsおよびカスタム・コンテンツを移行するために最適なアップグレード・プロジェクトを計画してください。推奨される戦略は、同じプロジェクトの一環としてOracle BI Applications 7.9.6.4とOracle BI EE 11gにアップグレードすることです。

11gのBI Serverはメタデータ妥当性チェックがより厳密になり、以前のOracle BI Applicationsリリースからアップグレードされたリポジトリでは多数の警告が発生するので、Oracle BI ApplicationsカスタマがOracle BI EE 11gにアップグレードする際は注意してください。Oracle BI Applicationsリリース7.9.6.3ではこの警告の対策がとられており、カスタマがOracle BI Applicationsをリリース7.9.6.4以降にアップグレードする際に表示されない場合があります。