レポート設計の考慮事項

レポートおよびグリッドのデータ制限

EPM Cloudデータ・ソースではグリッドで返されるセルの最大数が決まっており、この最大数はフォームやアドホック・グリッドにも適用されます。セルの最大数はEPM Cloudビジネス・プロセスによって異なる場合があります。グリッドまたはレポートのプレビュー時にこの制限に達すると、次のエラーが発生します: 「問合せの実行中にエラーが発生しました。セルの数が最大数の<最大数>を超えています。」

レポート結果が大きすぎてブラウザにレンダリングできない場合は(グリッド・セル数の制限の180000があるHTMLまたはPDFサイズ制限の10MB)、レポートをPDFとしてダウンロードするように求めるプロンプトが表示されるため、ダウンロードする場合は「OK」を選択し、操作を終了する場合は「取消」を選択します。

チャート・オブジェクトのデータ・セット制限

チャート・データセットの最大限度は、50行X25列、つまり1,250個の値です。

問合せにおける展開されるデータ・セグメントの使用と単一のデータ・セグメントの使用

データ・セグメントとは、データベースからデータを取得する行または列のことです。展開されるデータ・セグメントとは、展開可能な行または列であるため、結果のグリッドは表示される際に2つ以上の行または列に展開されます。通常、展開されるデータ・セグメントでは、Children OfまたはDescendants Ofなどの関数が使用されます。単一のデータ・セグメントとは、ビューアに表示される際に単一の行または列のままである行または列のことです。

展開されるデータ・セグメントと単一のデータ・セグメントの同じグリッドでの使用は通常は有効ですが、大量のデータがあるグリッドを設計する際には、単一のデータ・セグメントではなく展開されるデータ・セグメントの使用を検討してください。展開されるデータ・セグメントは、パフォーマンスの点で単一のデータ・セグメントよりある程度優れています。ただし、異なるデータ行または列で詳細な書式設定を生成する場合は、単一のデータ・セグメントを使用してください。

欠落ブロックの抑制

行または列に疎ディメンションが含まれている場合は、パフォーマンスを向上させるために欠落ブロックを抑制できます。欠落ブロックを抑制すると、大きい疎ディメンションを行に配置できると同時に、問合せの密度が低い場合のレスポンス時間を改善できます。データを含むブロックのみが取得されます。たとえば、数千のメンバーで構成される従業員ディメンションを行に配置し、ページまたはPOVにエンティティを配置すると、選択したエンティティの従業員のみが取得されます。

欠落ブロックの抑制は、90%以上など、多数の行が抑制される場合に欠落データの抑制に役立ちます。ただし、抑制される欠落ブロックを含む行がないか少ない場合は、欠落ブロックの抑制を選択するとパフォーマンスが低下する可能性があります。また、特定の抑制ブロックでは、動的計算メンバーが無視される場合があります。

ディメンションおよびメンバーの名前変更

データ・ソース内のディメンションまたはメンバーの名前を変更する場合は、変更を反映するために、レポートの各レポートを手動で更新する必要があります。

パフォーマンスの考慮事項

• リレーショナルタイプのレポートの記述を回避する

  • リレーショナルタイプのレポートとは、複数の行ディメンションが含まれており、それらがメンバー選択関数(DescendantsまたはBottomレベルなど)を通じて拡張され、大量のメンバーが返されるようなものです。

  • 大規模なレポートは実行に多大な時間がかかる可能性があります。大規模なレポートとはセル数が数万個に至るようなレポートのことです。

  • レポートを大規模なデータ抽出ツールとして使用することは適切ではありません。

• 動的計算ストレージがBSOキューブ・データ・ソースの疎ディメンション親の上にある場合、計算と集約のパフォーマンスは向上しますが、取得のパフォーマンスに悪影響が生じる可能性があります。この影響は、複数のディメンションを使用している場合は顕著に現れます。このようなストレージ設定をデータ・ソース・レベルで実装している場合で、レポート取得速度が低下している場合は、ストレージ設定の使用法を再考することをお薦めします。

その他の設計に関する考慮事項

レポートを設計する場合:

• 最適なパフォーマンスのために展開されるデータ・セグメントを使用します。

  • 個別の行または列に配置されていない展開されるデータ・セグメントで関数を使用します。

  • 個別の行または列に配置されていない展開されるデータ・セグメントで複数のメンバー選択を使用します。

  • 単一のデータ・セグメントは、書式設定または計算のために必要な場合にのみ使用します。

• 効率的な算式を作成します。

  • 可能な場合は、セル式ではなく行式または列式を使用します。

  • 参照プロパティを使用します。

  • 軸間参照ではなくセル参照を使用します。

  • 必要のないカッコは算式から削除します。

• レポートをグリッド・オブジェクトに限定しないようにします。

  • テキスト・ボックスに、特定の領域を強調表示する関数を追加します。

  • グラフィックのみを強調表示するためにレポート内のデータのグリッドを非表示にします。

レポートでの丸め処理および計算

概要

データ値がスケーリング済として表示(たとえば、千でスケーリングした173,545,723は、丸められて173,546と表示)されるレポート・グリッドにデータ値を表示すると、スケーリングされた残高詳細の合計がレポート内の丸め処理された小計および合計にならない可能性があります。グリッド設計を変更し、差異を特定してそれを調整金額に含める行式または列式を使用して、丸め処理された値によって発生する計算の差異を修正できます。

このトピックでは、流動資産合計メンバーへのスケーリングおよび丸め処理された流動資産ローリングを表示する単純なグリッドに必要な更新の例を示します。例ではNarrative Reportingサンプル・アプリケーションを使用しています。

レポートの問題

次のグリッド設計では、個々の流動資産および流動資産合計が別々の行で選択されています。

• 最初の列には、Q2の元の、スケーリングされていないデータ値があります。

• 2番目の列は、Q2のセルの書式設定で千でスケーリングされています。

次はグリッド・プレビューです。2番目の列のスケーリングされた値に注意してください。また、2番目の列の値の合計は904,569になりますが、表示されているスケーリングされた合計の904,570とは"1"のスケール差異が発生します。

レポートのソリューション

ソリューションは、グリッドに式行を作成し、差異を計算してそれを調整金額として行の既存の勘定科目のいずれかに適用することです(例では前払費用)。調整金額の行式は前払費用データ行を置き換え、これは非表示になります。

レポート・グリッド式では、表示されているスケーリングされた値ではなく、基礎となるスケーリングされていないデータ値が利用され(たとえば、最初のセルにあるスケーリングされていない173,545,723と千でスケーリングされた173,546)、データ値は、調整金額の行式を適用する前に、式列を介して丸め処理を適用する必要があります。元のデータ列は非表示になります。

次の変更された設計では、最初の列にスケーリングされていないデータ値が含まれたままで、2番目の列は、次の列式を使用してデータ列の値を千で丸め処理する式列です: ROUND([A],-3)。また、最初のデータ列のメンバー名を表示するために、式列でテキスト関数が使用されていることに注意してください。

式行が前払費用データ行の直下に挿入され(メンバー名114000)、流動資産合計メンバー(110000)と、行5の前払費用データ値を除く流動資産勘定科目の合計の差異を特定します: [7] - SUM([2:4])。カスタム算式が使用され、列または行全体ではなく、選択したセルにのみ式が適用されます。

また、式行ヘッダーにカスタム見出しの前払費用が指定されました。

次に、列Aおよび行5が非表示になります。

グリッド・プレビューでは、元の差異"1"が元の前払費用値124,569に対して調整されて値124,570になり、流動資産合計金額が正しく計算されるようになりました。