Search

レポートおよびビューのクエリーおよび生成を改善するためのヒント

以下の原則を適用して、レポートのパフォーマンスを向上させることができます

• 使用するテーブルをできるだけ少なくします。たとえば、アカウント・テーブルが不要な場合、レポートまたはビューからそれを削除します。
• テーブルを結合する場合、可能なかぎり外部結合でなく内部結合を使用します。
• テーブル間の結合が1対多の結合の場合、「1」のレコードを持つテーブルを最初のテーブルとして使用し、「多」のレコードを持つテーブルをそれに結合します。
• テーブル間の結合が1対1の結合の場合、レコード数の少ないテーブル(使用する予定のフィルタリングに基づく)を最初のテーブルとして使用し、レコード数の多いテーブルを2番目のテーブルとして使用します。
• 可能なかぎり固定フィルタを使用します。
• 構成のできるだけ早期にデータをフィルタします。すなわち、固定フィルタの方がノード・フィルタまたはグループ・フィルタよりも優先されます。
• 実行時フィルタを変更しない場合、それを固定フィルタにします。
• 実行時フィルタに対して特定のデフォルト値を選択します。
• データセットを興味のあるレコードに縮小するために、適切なフィルタをすべて含めます。たとえば、トランザクション・テーブルを結合するとき、tbl_idおよびtrans_typeを固定フィルタとして含めることで、データセットを特定のテーブル用の特定のトランザクション・タイプに制限します。
• 可能なかぎりインデックスでフィルタします。テーブル・インデックスの決定についてはデータ辞書を参照してください。To access Oracle B2C Service manuals and documentation online, refer to the Documentation for Oracle B2C Service Products.
• レコード数を数えるには、count(*)の代わりにcount(1)を使用します。同様に、count(answers.ans_id)のように特定のデータ要素またはフィールドをカウントする場合と同じ結果を与える場合、count(1)を使用します。
• 絶対に必要でない出力フィールドをすべて削除します。
• レポートまたはビューに出力する内容を制限することの重要性をスタッフが理解するようにします。

レポートに関する追加の考慮事項: 次の項目も、レポートのパフォーマンスの向上に当てはまります。

• 大きいレポートを小さいレポートに分割し、ダッシュボードまたはコンテナ内のすべてのレポートを表示するのにコンテナを使用します。
• between演算子を使用する日付フィルタを変更して、2つの別個のフィルタ(1つのフィルタで日付>値を使用し、別のフィルタで日付<値を使用する)を使用するようにします。クエリーは類似していますが、処理を大幅に削減できます。
• 可能であれば、フィルタ間でORコネクタ(|)を使用しないようにします。レポートでは多くの場合、OR結合を2つのレポートに変換し、コンテナを使用して両方のレポートを表示することができます。
• 初回の検索および自動更新は、レコードが1000件未満などの限定されたレコード数しか返されないビューでのみ使用します。
• レポートまたはビューが、主にキーワードまたはフレーズなどのテキスト検索に使用される場合、実行時フィルタに「検索文字をここに入力」などのデフォルトのテキスト文字列を追加します。その結果、数千件の項目を返すデフォルト構成を行う代わりに0件の項目を返す特定項目に関する初期検索が実行されます。

追加の考慮事項

レポートおよびビューの編集: レポートまたはビューを編集するときは、構成を検討して不要なテーブル、フィルタまたは出力列を削除します。レポートまたはビューを編集してフィルタまたは出力列を削除した場合、残りのフィルタまたは出力列を定義するためにすべてのテーブルがやはり必要かどうかを確認します。

アカウント・テーブル: アカウント・テーブルには特別な考慮が必要です。アカウント・テーブルから必要な情報が「担当者」スタッフの表示名のみの場合、アカウント・テーブルに実際に結合を含める必要はありません。

たとえば、レポートがインシデントに基づく場合、インシデント・テーブルのincidents.assign_acct_idフィールドを使用してアカウントの表示名をリストします。　アカウント表示名はアカウントの表示名の設定に従い表示されます。　アカウント・テーブルのaccounts.full_nameフィールドを使用する必要はありません。

使用する結合のタイプの評価: レポートまたはビューの内部のテーブルを結合するには、可能なかぎり内部結合を使用します。デフォルトでは、テーブルは内部結合で結合されます。ビューで外部結合を使用することが必要な場合もありますが、可能なかぎり内部結合を使用して、ビューに含まれるレコードがさらに制限されるようにします。

たとえば、連絡先テーブルをインシデント・テーブルに結合するとき、各インシデントには連絡先レコードが必要なため、内部結合を使用して2つのテーブルを関係づけることができます。つまり、インシデントごとに、内部結合を使用できる対応する連絡先レコードがあります。

内部結合および外部結合の詳細は、レポートで使用されるテーブル結合タイプを参照してください。

以下の原則を適用して、レポートのパフォーマンスを向上させることができます: レポートまたはビューで初期検索を実行すると、レポートまたはビューを最初に選択するときにクエリーが実行されます。固定フィルタおよび実行時フィルタのデフォルト設定によっては、初期検索で、すべてのインシデントまたは連絡先レコードなどのデータベース・テーブル全体についてクエリーを実行する場合があり、膨大な数になることがあります。

したがって、フィルタに基づいて返されるレコードの数が、100レコード程度と比較的少ないことがわかっている場合のみ、初期検索を有効にしてください。

初期検索は、「プロパティ」>「レポート・オプション」パネルで、「検索パラメータ用のプロンプトを表示せずにレポートを開く」チェック・ボックスをオンまたはオフにすることによって設定できます。

自動更新オプション: 初期検索オプションと同様に、十分な固定フィルタまたは実行時フィルタが配置されていることで、クエリーが実行されるたびに返されるレコード数が限定される場合にかぎり、レポートおよびビューで自動更新機能を使用する必要があります。

自動更新機能は、「プロパティ」タブ>「レポート・オプション」パネルの「このレポートから開始されたアクションによる変更を反映するためにレポートをリフレッシュしてください。」から有効または無効にします。

固定フィルタの使用: 可能な場合、特定の値または範囲にレコードを制限するために固定フィルタを使用します。たとえば、今日解決または更新されたすべてのインシデントをリストするレポートまたはビューは、ステータス・フィールドおよび最終更新フィールドについて固定フィルタを使用できます。複数のインタフェースを備えたサイトについては、インタフェースまたは言語についての固定フィルタを追加し、そのインタフェースからのレコードにのみアクセス可能になるようにすることを検討してください。

実行時フィルタに対する具体的なデフォルトの設定: 固定フィルタが望ましくない場合でも、実行時フィルタに対して優先的なデフォルト値またはデフォルト範囲を設定することができます。たとえば、ビューでインシデントについて作成された日をフィルタとして使用する場合、デフォルト範囲を先週中または先月中に設定することで、デフォルト検索によって、通常は最も関心が高い最新のインシデントが返されます。

実行時フィルタに具体的なデフォルト値を含めることで、クエリーが評価する必要がある行数が削減されます。また、「検索テキストをここに入力」のようなテキスト実行時フィルタを使用して、デフォルト検索値を含めることもできます。これにより、スタッフは検索を行う前に、実際に検索する内容を入力することを強制されます。

フィルタを効果的に使用するためのスタッフの研修: レポートまたはビューをできるかぎり合理化することができても、ユーザーが検索を実行するときに、すべての実行時フィルタ値を選択して、具体的な検索テキストを入力しない場合、依然として問題が発生します。つまり、スタッフが選択可能なすべてのオプションを検索するための実行時フィルタを設定し、具体的な検索テキストによる検索を行わない場合、クエリーは、必ずしも興味があるとは限らない数千行を依然として評価する必要があります。

したがって、ビューのパフォーマンスを向上させる方法の一部として、スタッフが責任を持って検索フィルタを使用するよう研修することと、スタッフがアクセス可能なビューを制限することがあります。一部のスタッフは、レコードを管理するために少数のレコードを返すのではなく、データベース内のレコードの全般的な概要を取得しようとして、レポートを使用する場合と同じようにビューを使用する傾向があります。