レポートデザインのベストプラクティス

このトピックでは、Application Studio を使って OLAP キューブ上にレポートを作成する際に考慮すべき主要な要素について説明します。

フロントエンドでの考慮事項

次の表は、フロントエンドのレポート設計で重要となる考慮事項を示しています:


考慮事項	説明
レポートにネストされたハイパーブロックは含まれていますか？	スライスに基づくレポートで、ハイパーブロックが null 値を除外するようにフィルタリングされている場合、パフォーマンスが向上します。スライスの使用には学習コストがあり、一部の望ましい機能はありませんが、利用可能な機能で約 80% のユースケースをカバーできます。
レポートに垂直スクロールが必要ですか？	必要であれば、ページング用の Web 拡張をレポートのフッターに追加してください。それによりユーザー体験とパフォーマンスが向上します。
レポートは条件付き書式を使用していますか？	条件付き書式は強力ですが、評価時にパフォーマンスへ影響するため、使いすぎないようにしてください。数値フォーマットを利用し、データベースに定義された書式に依存することで、条件付き書式を使わずに済みます。Application Studio は、OLAP データベースへ送信される数式のデータ要求をクラスタリングします。その結果、複数の単一セルクエリではなく、1 つの総合クエリになります。クラスタ化されたクエリは、単一セルへのアクセスより高速です。条件付き書式内のデータ読取式やレポートジャンプはクラスタ化できず、常に単一セル要求として処理されます。
スタイルシートを使ったレポートが過剰設計になっていませんか？	新しいスタイルシートを作成する際はシンプルさを意識し、既存のスタイルシートに不要な要素を追加しないようにしてください。スタイル数が多いほど、レポートのサイズは大きくなります。
レポートのエンティティに初期選択を設定していますか？	ユーザーが最後に表示したエンティティが保存されている場合、レポートはより速くロードされます。たとえば「全エンティティ」レベルでロードする場合、取得データ量が増えるため、レポートのロードに時間がかかります。
リストビューを基にしたコントロールではなく、ルックアップのようなステートレスコントロールを使っていますか？	コンボボックスなどのリストビュー型コントロールは、レポートのロード時にエレメントリストを取得します。ステートレスコントロールはエレメントリストを取得しないため、ロードが速くなります。
レポートを十分にテストしていますか？	文字列を連結してエレメント ID を生成するレポートを作成できますが、存在しないエレメントに対して OLAP サーバーへ要求を送信すると、エラーやタイムアウトのリスクがあります。テストでは常に、エンドユーザーのセキュリティ設定を考慮する必要があります。
リストフィルター	フィルターの種類によって速度が異なり、たとえば属性フィルターは値フィルターより遅くなります。一般的に、フィルターは構造選択よりも処理が遅くなります。フィルターで大きなデータ範囲を扱うのは避けてください。1 つの次元で選択するエレメントが多いほど、フィルターは遅くなります。
グローバルアクション	個別レポートの計算負荷を減らすために、グローバルアクションの利用を検討してください。グローバルアクションは、ユーザーのログイン時、リポジトリモデル作成後、エンジン作成前に実行されます。グローバル変数の値は、レポートのロードが開始される前にすでに設定されています。
レポート変数	変数に長い文字列を入れるのは避けてください。

バックエンド、環境要因、人間関係的な配慮

成功するプロジェクトでは、レポート開発者とキューブ作成者の間にフィードバックループがあります。パフォーマンス低下の最大の原因は、設計の悪いキューブである可能性が高いです。次の表は考慮すべき重要な係数を示しています:


考慮事項	説明
実際的なデータセットを使ったレポートの作成とテスト	レポートで扱う次元が最大 30 エレメントまで含まれ、キューブが数百のデータポイントを含む場合、動作は可能ですが、大規模データセットのために維持が難しくなります。現実的なデータセットを用いてテストを行うことが重要です。
正しい OLAP ルールを記述します。悪い書き方の例： [収益] = [価格] * [数量] または [勘定科目 1] = [勘定科目 2] + [勘定科目 3] + [勘定科目 4]	最適な OLAP ルールを書くためのベストプラクティスに慣れておいてください。ガイダンスについてはオンラインドキュメントを参照してください。
構造が悪い次元	トップエレメントが「全製品」で、その下に 10,000 の子エレメントがあるような製品次元。どこかのタイミングでユーザーは OLAP サーバーに要求をトリガーすることになり、すべてのエレメントを取得して表示する必要が生じます。中間レベルを設けることで、階層に基づくレポートのパフォーマンスは向上します。
ユーザー数が多い場合	ユーザーがピークの時間帯に次元へ変更を加えることは避けてください。
たとえば、合計年エレメントなど、次元に親エレメントがない場合	隠し列のデイリーデータを集計して年度合計として表示するレポートは、OLAP データベースで合計を計算するレポートよりも圧倒的に遅くなります。
属性の誤用	属性は自由に定義でき、レポートの絞り込みにも使えますが、フィルターレポートは属性値ごとにエレメントをまとめた階層を使う場合よりも性能が低くなります。
OLAP サーバーに十分な RAM があることを確認します。	OLAP はインメモリデータベースです。クエリの書き方が悪いと、RAM が大量に消費されます。OLAP サーバーがページングを行っている場合、パフォーマンスの低下が予想されます。
キューブにはトランザクションデータを入れないでください。	Infor OLAP は、残高レベルのレポートに最適化されています。アプリケーションは非効率なレポートの作成を防いではくれません。たとえば、購買オーダーの明細レベルで詳細キューブを作ることはできますが、性能の面では非効率である可能性が高いです。
短期的な対処として質の悪いレポートを書くこと	プロジェクトの圧力に負けて、パフォーマンスを損なうレポートを作ってしまわないようにしましょう。懸念点を文書にまとめ、代替案を提示しましょう。
キューブにゼロを格納しないでください。	ゼロは、OLAP メモリに保存され、ルール計算で評価される数値ですが、NULL はその対象になりません。キューブ内のゼロを NULL に置き換える Application Engine プロセスを作成できます。
計算を行う最適な場所	これは、計算された値がどの程度の頻度で必要かなど、複数の要因によって異なります。以下は、計算を行う場所の例を、推奨順に示したものです: ソースシステム内データロードプロセスの一部として Application Engine により計算され、OLAP に保存されます。 OLAP では、動的ルールを使用しますリポジトリの計算 (セッションメンバー) としてレポートの一部として Application Studio 内で行います。
特定のデフォルトエレメントの設定	階層型の次元で特定のデフォルトエレメントを選択しない場合、最上位エレメントがデフォルトとして選択されます。これには、デフォルトエレメントを再設定するため、より多くの時間が必要です。現在、デフォルトエレメントは次元の拡張プロパティに設定されています。
XML インターフェースの使用は、バージョン 11 におけるビルトインインターフェース経由の通信よりも遅くなります。	通信を高速化するため、単一セル単位で値を読み取るのではなく、1 回または少数回のリクエストにまとめて OLAP に送信することをお勧めします。これは、キューブ読み取り要求に複数の `CellCoordinate` タグを追加することで実現できます。
サーバーサイドのページングを使用して、表示されている値のみをクエリするレポートを作成します。	ハイパーブロックのページングはクライアント側で行われます。すべてのセルがサーバーから返されますが、1 ページのみ描画されます。 OLAP リストでは、サーバー側でページングを行うためにサブセット関数を使用します。リレーショナルリストでは、クエリ内の詳細手法を使用してサブセットを作成します。
次元内のすべてのエレメントを問い合わせないよう、クエリにフィルターを設定します。	NULL 抑制を使用して入力済みセルのみを表示し、次元全体ではなく特定の親エレメント配下のすべてのエレメントを表示します。スライスおよびリストの初期展開レベルを下げます。
多数の次元を軸に配置することは避けます。	最適な構成は、行軸に 3 次元、列軸に 1 次元です。