実装に関する重要な考慮事項
更新 : 2009-04-30
PerformancePoint Planning の実装を計画する際には、いくつかの重要な決定を下す必要があります。アプリケーションの構築を開始する前に、以下の項目について分析し、意思決定を行ってください。
必要なアプリケーションの数 : 1 つまたは複数
計画に関する多くの考慮事項が、作成する Microsoft Office PerformancePoint Server 2007 アプリケーション数の決定に影響します。最も重要な考慮事項は、メタデータ定義とビジネス オブジェクト定義をどの程度共有するかということです。複数のアプリケーションの方が拡張性と柔軟性はありますが、個々のアプリケーションはデータの独立したコンテナと考えることができ、アプリケーション間でデータを共有することはできません。
PerformancePoint Server では、アプリケーションごとに 1 つのカレンダーしか使用できないので、カレンダーが異なる複数のビジネスがある場合、このような組織構造に対応するには複数のアプリケーションを作成する必要があります。アプリケーション カレンダーがビジネス プロセスと正確に一致するように注意してください。カレンダーは変更できません。その場合は、新しいアプリケーションを作成する必要があります。
アプリケーションのモデル サイトを計画するときは、組織のプロセスとデータが中央に集中しているか、または組織内にビジネスの種類が大きく異なる複数の部門が含まれるかを判断してください。
組織が中央に集中している場合、複数のモデル サイトは必要ない可能性があります。組織が中央に集中していなくても、プロセスに一貫性があり、本社に報告されるデータが業務が違っても標準化されている場合は、会社レベルでデータを集約する複数のモデル サイトにできる可能性があります。
これに対し、組織が中央に集中しておらず、データが部門間で一貫していない場合は、共通性のない部分ごとに異なるモデル構造が必要になる可能性があります。そのためには、複数のアプリケーションを作成することが必要な場合があります。
会社のルートのモデル サイトを、部門または部署のモデル サイトから分離すると、ユーザー ベースおよびロール ベースでのデータ アクセスも可能になります。これは、計画プロセスで使用される前提データ モデルに対し、会社によるコントロールを維持するために重要です。
セキュリティに関する考慮事項も、サイトの計画の決定に影響を与えます。モデル管理者ロールのメンバにさまざまなアクセス許可を指定するには、モデル サブサイトを作成し、モデル サイト レベルでアクセス許可を設定します。
その他の考慮事項は以下のとおりです。
異なるプロジェクト スケジュール : 計画、予算編成、予測、または実績の担当者が使用するタイムテーブルは異なる可能性があります。その場合、最初から 1 つのアプリケーションにプロジェクトを実装することは難しくなります。
小規模なアプリケーションから開始 : 1 つの大規模なアプリケーションへの移行を長期的目標として、まずは複数のアプリケーションからスタートする方法が、ベストな展開方法である場合があります。この方法を使用すると、ビジネス チーム間の調整が少なくて済み、チームごとに個別のスケジュールを使用できます。
支店や子会社ごとに異なる要件 : 地方の支店や子会社が独自の項目を追跡する場合は、支店や子会社専用のサブサイトを使用する場合があります。これにより、支店や子会社はデータを共有できますが、カスタマイズも行うことができます。
複数地域の扱い : 1 つの場所 (本社など) に Planning Server をインストールしてリモート ユーザーはリモート接続できるようにする方法と、離れた拠点用にサブサイトを作成する方法があります。後者の場合、リモート サイトでは、PerformancePoint Server のデータ統合機能を使用して定期的にデータを本社に移動できます。データが常に会社のサイト要件満たすようにすることは、サブサイト側の責任です。
スケーラビリティ : すべてのユーザーが同じアプリケーションを共有する場合は、スケーラビリティがプロジェクトの計画サイクルで重要な考慮事項になります。
モデル タイプの選択
PerformancePoint Server アプリケーションでモデルを作成する場合は、グローバル前提モデル、為替レート モデル、株式計算を使用する財務モデル、株式計算を使用しない財務モデル、および汎用モデルの 5 つのモデル タイプから選択できます。
アプリケーションに組み込むモデル タイプを決定するときは、作成するのがビジネス モデルであるか、または前提データ モデルであるかなど、モデルとそのデータの活用法を第一に考慮します。また、エンド ユーザーによって必要とするデータのレベルはさまざまであるため、初期計画において幅広いユーザーを考慮することも重要です。
たとえば、レポートで表示するデータは、財務レポートのためだけに使用されるデータとは異なる方法でモデル化される必要があります。財務レポートで主に使用されるモデルには、営業担当者のデータが含まれていなかったり、営業担当者レベルのレポートとして適切なレベルではない場合がありますが、このデータは営業スコアカードには不可欠です。このシナリオでは、詳細な売上データを提供するモデルを設計し、そのデータを財務レポートに要約できると便利です。
また、特定のモデル タイプのモデルを 1 つ作成したり、目的に応じて同一タイプのモデルを複数作成できるので、この方法でも上記シナリオに対応できます。
モデル タイプ
| モデル タイプ | 説明 |
|---|---|
汎用モデル |
最も基本的なモデル タイプです。必要なあらゆるモデル タイプに使用できます。また、会計ロジックの定義済みのルールは含まれていません。 |
グローバル前提モデル |
人員数や価格リスト情報など、企業全体に適用される基準データ用として、また収益と経費前提データなどの財務モデルのビジネス ドライバ用として使用できます。 |
為替レート モデル |
システムのすべての通貨について、期間および換算の種類別に外国為替値を追跡する専用の前提データ モデルです。 為替レート モデルでの重要な考慮事項の 1 つは、日次、月次、および年次などの複数の頻度で為替レートを追跡する必要があるかどうかということです。為替レート モデルには集計機能がないため、為替レート前提データを使用するアプリケーションでは、頻度ごとに別々の為替レート モデルが必要です。 |
株式計算を使用しない財務モデル |
連結を実行するための組み込みロジックが含まれています。ただし、株式計算は含まれていません。1 つの会計主体を使用している場合、または個別に分析される複数の会計主体を使用している場合は、このモデル タイプを使用します。たとえば、このモデルを使用すると、人事が専用に使用するモデルなど、企業のコスト モデルや部門別モデルを作成できます。 |
株式計算を使用する財務モデル |
株式計算を含み、会社間消去の計算も行う連結を実行する組み込みロジックが含まれています。たとえば、複数の会計主体を使用し、企業レベルの連結レポートを提供する場合、または完全所有でない複数の会計主体がある場合は、このモデルを使用します。このモデル タイプを使用して、戦略的計画モデルを作成することもできます。 |
ディメンションの計画に関する考慮事項
PerformancePoint Planning のディメンションには、定義済みディメンションとユーザー定義ディメンションという 2 つのカテゴリがあります。定義済みディメンションは、そのままでも使用できますが、通常は、現在のデータ構造および名前付け規則に対応するように、なんらかの変更が必要です。定義済みディメンションのカスタマイズ範囲は、ユーザー定義ディメンションよりも限定されています。
アプリケーションを計画するときは、各ディメンションに含まれるディメンション メンバの数を検討することも重要です。ディメンションに含まれるディメンション メンバが多い場合は、追加のディメンション メンバ セットを作成してモデルあたりの勘定数を制限すると、アプリケーションのパフォーマンスを向上させることができます。
計算
PerformancePoint Planning におけるビジネス計算は、サーバー側の計算またはクライアント側の計算を使用して実行できます。Planning Server では、サーバー側の計算はビジネス ルールとして提供されます。ビジネス ルールは PerformancePoint 記述言語 (PEL) を使用してユーザーが必要とする計算を定義します。クライアント側の計算をは、Excel 用 PerformancePoint アドインに組み込まれた計算機能を使用して実行します。
サーバー側の計算
PEL で定義されるサーバーのビジネス ルールの計算は、実際には Microsoft SQL Server エンジンまたは SQL Server 2005 Analysis Services (SSAS) エンジンによって行われます。SQL Server エンジンで計算を行うには、ルールをコンパイルして SQL ストアド プロシージャを作成する必要があります。次に、そのプロシージャを実行して計算を行います。Analysis Services エンジンで計算を行うには、ルールをコンパイルして MDX クエリ ステートメントまたは MDX 計算スクリプトを作成する必要があります。次に、それらを SSAS エンジンに送信して計算を行います。
一般に、ルールは、上記の 3 つ (SQL Server エンジン、MDX クエリを使用する SSAS エンジン、または MDX スクリプトを使用する SQL Server Analysis Services エンジン) のいずれかのプラットフォームによって実行します。パフォーマンスと動作の特性は、計算プラットフォームごとに異なります。次の表は、これらの特性を示しています。
| 実行プラットフォーム | 動作特性 | パフォーマンス特性 | 推奨事項 |
|---|---|---|---|
SQL Server エンジン |
計算は、エンド ユーザーによって明示的に呼び出されるか、または再処理イベントによって呼び出されます。 計算後のデータは具現化され、ファクト テーブルに書き戻されます。 一部の複雑な式はサポートされていません。 |
計算ではデータの分散度が適切に処理されます。つまり、実行時間は計算範囲ではなくファクト データのサイズに比例します。 |
ほとんどの場合、計算をオンデマンドで呼び出すことができるときや、再処理イベントによってトリガできるときに適しています。 注意する必要があるのは、SQL Server の処理能力を超えるデータの増加や複雑な式です。 |
MDX クエリを使用する SQL Server Analysis Services エンジン |
計算は、エンド ユーザーによって明示的に呼び出されるか、または再処理イベントによって呼び出されます。 計算後のデータは具現化され、ファクト テーブルに書き戻されます。 すべての PEL 式をサポートします。 |
計算では、特定の種類の分散度が正しく処理されません。広い領域を対象とする計算がある場合は、実際の (null 以外の) 計算結果が比較的少なくてもパフォーマンスが低下する可能性があります。 |
狭い範囲を対象とする計算に適しています。計算のテストおよびデバッグする場合は、最も簡単な方法です。この式の機能は、SQL Server エンジンよりも強力です。 注意する必要があるのは、広い計算範囲、データの増加、およびパフォーマンスの低下です。 |
MDX スクリプトを使用する SQL Server Analysis Services エンジン |
計算は、SSAS エンジンによって自動的に呼び出され、管理されます。計算を行うには、ユーザーの呼び出しまたは Microsoft Office PerformancePoint Server 2007 がトリガするイベントは必要がありません。 計算結果が具現化されないため、バックエンドでのデータの増加に関する問題は発生しません。 |
計算の特性としては、分散度が低いことが挙げられます。複数の計算があり、そのどちらかが広い計算領域をトリガする場合は、パフォーマンスが特に低下します。 |
計算をリアルタイムで自動的に行う場合にこのプラットフォームを使用します。 この種類の計算がある場合にクエリのパフォーマンスが低下します。 |
単純な比率計算は、SQL Server エンジンまたは MDX スクリプトを使用する SSAS エンジンによって簡単に行うことができます。この 2 つの違いは、データの増加および実行時のクエリのパフォーマンス低下のどちらが発生するかです。
MDX スクリプトを使用する SSAS エンジンで広範囲のリーフ レベルのみの計算を行うのは効率的ではありません。これは、より高度な集計レベルでの単純なクエリは、発行のたびに広範囲の自動計算をトリガするためです。これにより、クエリのパフォーマンス全体に大きな影響を与える可能性があります。
クライアント側の計算
Planning Server ユーザーは、ブックの作成中にセルに数式を入力できます。Planning では、これらの数式を "デザイン時間式" と呼んでいます。デザイン時間式は、Microsoft Office Excel のさまざまな計算機能を使用してクライアント側の計算を実現します。デザイン時間式は、ルート レベルで定義でき、下位レベルに自動的に継承されます。デザイン時間式は、フォーム作成時にビジネス ルールを実装するための便利な手段です。
.gif "メモ") メモ : |
|---|
デザイン時間式を使用しすぎると、フォームの表示とデータ送信の速度が低下することがあります。 |
Excel の数式を使用する場合、企業では既存のスプレッドシートに定義済みの既存のビジネス ルールを活用できます。重要な数式を Planning Server に移行する際に増分移行を使用することにより、数式を集中管理できます。
データ入力時に、ユーザーが書き込み可能な領域に数式を入力することもできます。Planning Server では、これらの数式を "実行時式" と呼んでいます。実行時式は、ビジネス ルールを適用し、データの整合性を確保するために使用できます。
Analysis Services の書き戻し
Planning では、Analysis Services の "書き戻し" 機能を使用してパフォーマンスの結果を予測します。提案されたパフォーマンスの結果に満足できない場合は、ローカルに割り当てることで SSAS サーバーの負荷を減らすことをお勧めします。詳細については、次の「ローカル キューブ (オフライン割り当て)」を参照してください。
ローカル キューブ (オフライン割り当て)
PerformancePoint Planning は、ユーザーがデータ入力タスクを実行するときに、オンライン、オフライン、または混在モードで作業できるように構成できます。この構成は、モデル レベル、またはユーザー レベル単位で設定できます。
Planning のモデル管理者は、Planning Business Modeler で "AllowOffline" モデル フラグを設定することにより、大規模モデルまたは機密データを含むモデルのオフライン キャッシュを有効にすることができます。
Planning の共同作成者は、Excel 用 PerformancePoint アドインで "割り当てを自動的にキャッシュする" オプションを設定することにより、実行時環境でオフライン キャッシュのオンとオフを切り替えることができます。既定では、両方のオプションがオンになっています。
オンライン モード : いずれかのオプションを "オフ" に設定すると、Planning ユーザーはオンライン モードで作業します。データは、ユーザーのコンピュータにダウンロードされません。
ローカル モード : 両方のオプションを "オン" に設定すると、データがユーザーのコンピュータにダウンロードされた後に、Planning ユーザーは自動的にローカル モード (混在モード) に切り替えられます。計算はローカル コンピュータにキャッシュされた情報に基づいて実行されるため、オンライン モードの場合よりも計算時間が短縮される可能性があります。
オフライン モード : データがユーザーのコンピュータにダウンロードされた後に、ユーザーは完全にオフラインで作業する (つまり、Planning Server とのアクティブな接続を切断する) ことを選択できます。このモードを使用するのは以下のような場合です。
オフィス外にいるため、Planning Server が動作しているコンピュータに接続できない場合。
Planning Server が動作しているコンピュータが保守のために使用できない場合。
ユーザーがオンラインに戻ってフォームを送信するまで、変更は Planning Server データベースに保存されません。
サブキューブ
レポート作成者は、レポートおよびフォームを作成するときにサブキューブの使用を検討する必要があります。データ セット全体のサイズは大きいことがあり、オフライン データのダウンロードに時間がかかり、SSAS サーバーの負荷が増える場合があります。レポート作成者は、レポートを設計するときに、オフライン割り当て用のサブキューブを定義できます。これにより、ユーザーがオフライン作業用に割り当てをダウンロードするとき、データベースの該当する部分のみがユーザーのコンピュータにダウンロードされます。
データ読み込みに関する考慮事項
Planning Server は、完全な抽出、変換、および読み込み (ETL) プロセスではないため、複数のデータ ソースからデータの抽出、変換、および読み込みを行うジョブの作成には使用できません。
データ ソース、および Planning モデルへとソース データのマッピングを定義する必要があります。ディメンションとメンバの種類は、Planning の種類と一致する必要があります (たとえば、勘定科目の種類は勘定メンバにマップする必要があります)。また、変換が可能であるかどうかを確認し、ETL プロセスの担当者を決定して、データの移動スケジュールを定義する必要があります。
データ統合は次の手順で行います。
Planning ステージング データベースを作成します (この手順は 1 回だけ実行します)。
Planning ステージング データベースを PerformancePoint Planning と同期します。これは、構造が変更されるたびに行う必要があります。
外部 ETL ツールを使用して、データ ソースのデータを Planning ステージング データベースに読み込みます。
参照 (ディメンションと階層) データとファクト データを検証して、エラーを修正します。
Planning ステージング データベースのデータを、Planning アプリケーション データベースに読み込みます。
PPSCmd とスクリプトを使用すると、このプロセスを自動化できます。
Planning では、勘定科目のデータを借方および貸方としてそのまま格納します。たとえば、貸方残高のある貸方勘定は正の値として格納され、借方残高のある貸方勘定は負の値として格納されます。また、借方残高のある借方勘定は正の値として格納され、貸方残高のある借方勘定は負の値として格納されます。
このため、ソース システムがデータの種類に応じた符号付きでデータを格納している場合、これらの勘定科目の符号を、データが読み込まれる前に変更する必要があります。Planning のデータ統合にはデータの読み込み時にこの処理を行う機能が用意されていますが、処理されるのは負の数として格納された貸方のソースの勘定科目だけです。ソースのシステムが別の規則を使用している場合は、ソース システムから Planning ステージング データベースへのデータ転送で使用する ETL プロセスで符号の変更を行う必要があります。
データ読み込みプロセスを正しく計画しておかないと、モデル、ディメンション、および関連するメンバ セット間でデータが調整されないため、慎重に計画することが重要です。
データ読み込み時の主要な考慮事項には、データの読み込み頻度、完全なデータ読み込みまたは増分データ読み込みの選択、関与するデータの量、およびパフォーマンスがあります。
データ読み込みのタイミングと頻度、および、これらのプロセスに対してユーザーが何を担当するかを検討します。これは、マルチサイトのマルチモデル実装で重要になることがあります。
ビジネス プロセスに関する考慮事項
ビジネス プロセスにおけるデータの共同作成者、レビュー担当者、および承認者間の共同作業を調整するために、Planning Server ではプロセス サイクルおよびデータ入力フォームを使用します。プロセス管理は Planning Business Modeler を使用して実行されますが、フォームの作成およびデータ送信は Excel 用 PerformancePoint アドインを使用して実行されます。
データの共同作業の計画には、ビジネスおよびプロセス計画に関する考慮事項に加えて、システム計画およびワークフロー計画があります。
システムに関する考慮事項およびワークフロー
PerformancePoint Server アプリケーションを計画する場合は、ユーザーの地理的位置に関連したロジスティクスを考慮する必要があります。たとえば、データの共同作成、レビュー、および承認を行うユーザーが世界中に分散しているかどうかなどです。
このシナリオに対応するためには、割り当てに期限を設定するときのタイム ゾーンの違いや、複数の地域のユーザーがシステムを同時に使用する時間帯のシステム帯域幅、複数通貨の計画に関する問題などを考慮する必要があります。
ビジネスおよびプロセス計画に関する考慮事項
ビジネス プロセスの実装計画を開始するにあたっては、データの流れを考慮することが重要です。計画の 1 つの手順として、プロセス全体、プロセスのユーザーと各ユーザーのロール、およびデータの流れを文書化すると役に立ちます。
もう 1 つの重要な考慮事項は、プロセスの種類です。Planning Server で使用されるいくつかの代表的なビジネス プロセスの種類を次に示します。
四半期予測などの定期的または繰り返しのプロセス
予算プロセスなどのトップダウンまたはボトムアップの目標設定
連結などのより大きな財務プロセスにおけるステップ
他のプロセスをサポートするための一般的なデータ送信
また、ビジネス プロセスを実装する場合、データ セキュリティも重要な考慮事項です。Planning Server では、ユーザー単位、およびプロセス サイクルの一部として、データが保護されます。そのため、データの表示、編集、レビュー、および承認を必要とするユーザーの特定は、ビジネス プロセス計画の重要な要素です。
為替換算、財務連結など、ビジネス プロセスに影響を与える可能性のある各国固有の会計規則も計画時に考慮する必要があります。
ビジネス プロセスで使用するデータ入力フォームの種類を計画する場合には、次に挙げるいくつかの項目を考慮する必要があります。
フォームでの計算の使用
ユーザーごとに毎月自動更新される動的フォームの作成
ユーザーのスキル セット
フォームの複雑度
さらに、複雑な計算または多くのユーザーを含むプロセスはパフォーマンスに影響を与える可能性があります。フォーム構成、計算定義、モデル設計、およびデータ フロー計画を慎重に行うことにより、パフォーマンスを改善できます。さらに、Excel 用 PerformancePoint アドイン のオフライン機能の活用は、パフォーマンスとスケーラビリティの向上に役立ちます。
アプリケーションで作成するフォーム数を計画する場合は、データのライフ サイクルも考慮する必要があります。これは、データ入力フォームには複数のモデルのデータを表示できますが、同じフォームのデータを入力する部分は 1 つのモデルにしかリンクできないためです。複数のモデル データ入力が必要な場合、複数のモデル サイトまたは複数のフォームのいずれかを作成する必要があります。
Planning Server にはデータのレビューと承認のプロセスが用意されており、この機能は、レビューと承認のワークフローの基本的な要件を満たすものです。より複雑な共同作業では、Windows SharePoint Services Web パーツをを統合することをお勧めします。
セキュリティに関する考慮事項
Planning Server のセキュリティ モデルはロールに基づいています。ユーザーはロールに割り当てられます。Planning Server システムにおけるユーザーのアクセス許可レベルは、ユーザーが属しているロールによって決定します。管理者ロールとビジネス ロールの 2 つのロールの種類があります。
ビジネス ロール
ビジネス ロールは、実際のビジネス データを操作するユーザーに対して定義されます。データ管理者ロールとモデル管理者ロールのメンバは、アクセス許可が制限されているビジネス ロールに属している場合でも、モデル サイト内のすべてのビジネス データに無制限にアクセスできます。
明示的なアクセス許可が指定されていない場合は、既定のアクセス許可が、モデル サイト内のすべてのメンバ セットおよびビジネス ロール内のすべてのユーザーに適用されます。
明示的なアクセス許可は既定のアクセス許可より優先されます。特定のメンバ セットまたはメンバに、読み取りまたは書き込みのアクセス許可を明示的に指定できます。
既定では、あるビジネス ロールに属するすべてのユーザーは同じアクセス許可を継承します。カスタムのユーザー アクセス許可機能がメンバ セットに対して有効になっている場合は、アクセス許可を制限できます。このオプションを使用する場合、メンバ セットに対する読み取りまた書き込みのアクセス許可を必要とするユーザーに対しては、個別にアクセス許可を構成する必要があります。
ビジネス ロールは、ビジネス データへの同様のアクセスを必要とするユーザー用に設計してください。ロールを作成する前に、ロール メンバが共有するアクセス許可のセットを特定し、共通のアクセス要件に最も適した既定のアクセス許可および明示的なアクセス許可レベルを選択します。この設定をデータの明示的なアクセス許可を定義するための開始点として使用すれば、ロール定義に加える変更を最小限にすることができます。セキュリティのベスト プラクティスとして、適用される最も制限の厳しい設定を使用してください。
最適なパフォーマンスを実現するには、ビジネス ロールを定義するときに、カスタムのユーザーアクセス許可の必要性を最小限に抑えることです。ユーザーのアクセス許可をカスタマイズする際には、新しい Analysis Services ロールを作成します。ロールの数は、モデル サイトの展開などの一部のタスクを実行するために必要な時間に影響します。
ロールは割り当て定義用のユーザー グループとして使用できるため、ビジネス ロールを使用するとプロセス管理がより臨機応変になり、設定も簡単になります。割り当て定義で使用されるロールにユーザーを追加すると、そのユーザーは、該当するプロセス管理タスクにも追加されます。
管理者ロール
管理者ロールは、グローバル管理者、ユーザー管理者、データ管理者、およびモデル管理者です。グローバル管理者は、別の管理者ロールにも属していない限り、Planning Business Modeler でサーバーに接続することはできません。ユーザー管理者には、ビジネス データに対する読み取りまたは書き込みアクセス許可がありません。モデル管理者とデータ管理者には、アクセス許可が制限されているビジネス ロールに属している場合でも、モデル サイト内のすべてのビジネス データに対する無制限の読み取りおよび書き込みアクセス許可があります。
展開アカウント
PerformancePoint Server を展開する際に考慮する必要のある 2 つのアカウントがあります。Planning Server サービス ID (SI) アカウントとデータベース管理者が使用するアカウントです。SI アカウントは、システム データベースおよびソース データとの通信に使用されます。データベース管理者は、Planning Server データベースの作成と構成を担当します。詳細については、『PerformancePoint Server 2007 展開ガイド』を参照してください。
| メモ : |
|---|
多くの概念実証システムでは、単一サーバー インストールを使用してすべてを実装し、コンピュータにユーザー アカウントを追加すると便利です。ただし、Analysis Services がインストールされているコンピュータの管理者ロールに Planning のユーザーを追加する場合、既定では、Planning Server で作成されたデータベースを含む、Analysis Services データベース内のすべてのデータへの完全なアクセス権がこれらのユーザーに与えられます。このため、コンピュータにユーザー アカウントを追加する場合は、最小限の特権の原則に従う必要があります。 |
管理者ロールとビジネス ロールの設定の詳細については、Planning Business Modeler オンライン ヘルプを参照してください。
その他の考慮事項
メンバ セットとメンバ ビューがパフォーマンスに与える影響 : メンバ セットは Analysis Services の親子階層に変換され、メンバ ビューはレベル化された階層に変換されます。Analysis Services ではメンバが事前集計されるため、親子階層よりもレベル化された階層の方が効率的に処理されます。メンバ セットが非常に大規模な場合や、メンバ セットの階層が非常に深い場合は、パフォーマンスの問題が発生することがあります。この場合、レポートの設計時にメンバ ビューの使用を検討する必要があります。
Analysis Services : Analysis Services がパフォーマンスのボトルネックになっていると判断した場合は、SSAS サーバーをクラスタ化する方法のガイダンスとして『SQL Server 2005 Analysis Services Performance Guide』(https://go.microsoft.com/fwlink/?LinkId=103090&clcid=0x411) を参照してください。
階層 : 時間の経過と共に変化する階層や再編成される階層がある場合は、複数のメンバ セットを作成し、異なるモデルで使用できます。
カスタム拡張機能
PPSCMD
Planning コマンド ユーティリティ (PPSCmd.exe) は、Planning Server の管理と限定的な変更に役立つツールです。このツールは 12 個のコマンドで構成されており、Planning Server でアクションのスクリプト化を可能にします。たとえば、PPSCMD を使用すると、データ読み込みプロセスを自動化できます。
PPSCMD の詳細については、『PerformancePoint Server 2007 操作ガイド』を参照してください。
クライアント側のマクロ
Excel 用 PerformancePoint アドインでは、Excel のマクロ機能を使用してマクロを作成および実行できます。マクロを作成する場合は、Visual Basic for Applications (VBA) を使用して、モジュールに格納されているコマンドと機能を指定できます。
| メモ : |
|---|
モジュールを Excel 用 PerformancePoint アドイン内のイベントから呼び出すには、モジュールのタイトルを "PerformancePoint" にする必要があります。 |
以下の Excel 用 PerformancePoint アドイン イベントを使用して PerformancePoint モジュールを呼び出すことができます。
AfterRefresh : このマクロは、ワークシート、ブック、またはマトリックスが更新された後か、ページ フィルタが変更されたときに実行されます。
BeforeAssignmentAction : このマクロは、[移動] ボタン ([アクション] ボックスの横にある矢印ボタン) をクリックしたときに、指定した割り当てアクションを実行する前に実行されます。
既定では、AfterRefresh イベントおよび BeforeAssignmentAction イベントが発生したときにマクロを実行する機能は、無効になっています。このオプションは、システム管理者が Planning 管理コンソールで有効または無効にすることができます。詳しくはシステム管理者に問い合わせてください。また、これらのイベントについて、Excel 用 PerformancePoint アドインは Excel マクロのセキュリティ モデルを採用し、署名付きのマクロの実行だけが許可されます。
Analysis Services でのカスタマイズ
カスタム MDX または計算済みメジャーを直接 Analysis Services キューブに追加できます。これらのカスタム変更は、モデル サイトを展開するたびにを適用する必要があります。
カスタム SQL ストアド プロシージャと MDX スクリプト (ネイティブ ルール)
上級ユーザーにとって PerformancePoint 記述言語 (PEL) の制約が多すぎる場合、Planning ではカスタムのネイティブ SQL または MDX スクリプトも記述できます。これらの実装ではセキュリティ リスクが発生する可能性があるため、Planning ではルールの承認が必要です。Microsoft Office PerformancePoint Server 2007 では、これらのルールを低特権ユーザーとして実行します。
この種のルールを有効にする方法については、『PerformancePoint Server 2007 操作ガイド』を参照してください。
サンプル アプリケーション
PerformancePoint Server アプリケーションの計画時に参考となるもう 1 つのリソースに、『Alpine Ski House (ASH) サンプル アプリケーション ガイド』があります。『ASH サンプル アプリケーション ガイド』には、架空の Alpine Ski House Corporation のプロファイルが記載されています。また、ASH が PerformancePoint Server ソリューションへの移行を決定した背景要因、およびサンプル アプリケーションを作成したときに ASH が採用したアプリケーション構造についても説明します。また、ASH で実施されたアプリケーション実装プロセスの概要についても説明します。ASH サンプル アプリケーションを使用したサンプルの予算プロセスも含まれています。『ASH サンプル アプリケーション ガイド』へのリンクは、「Documentation map for Microsoft Office PerformancePoint Server 2007」(https://go.microsoft.com/fwlink/?LinkId=103091&clcid=0x411) を参照してください。