Cisco Prime Service Catalog 11.0 レポート ガイド
レポートの設計
レポートの設計

目次

レポートの設計

この章は次のトピックで構成されています。

サービス設計でのレポート作成計画

カスタマーの各サイトは当然異なるディクショナリおよびサービスのセットを持っているため、これらの中からレポート可能にするオブジェクトを決定する方法について厳格なルールは存在しません。 ただし、データ マートに含めるオブジェクトを決定する際は、次のガイドラインが役立つ場合があります。 詳細については、データ マートの設定を参照してください。

ディクショナリ

日付または数値を含むディクショナリは、データ マートに含める有力な候補です。

ディクショナリのすべて、またはその一部が、説明を保持するために設計された非常に大きなサイズのフィールドで構成されている場合、そのディクショナリはデータ マートに含めるのに適した候補ではありません。このようなフィールドは、データ マートが作成されるときに指定した最大文字サイズで切り捨てられます。

ビジネス ニーズにとって重要だと考えられるディクショナリは含める必要があります。 このため、対応する個人ベースのディメンションには存在せず、Organization Designer に存在していた情報よりも新しい情報を含んでいる Customer ディクショナリおよび Initiator ディクショナリを含めるのが一般的です。

サービス

サービスを含めることで、基本的に各ディクショナリを識別することなく(つまり、個別のディメンションまたはクエリー サブジェクトとして)サービス内のすべてのディクショナリに関してレポートを作成できるショートカットが提供されます。これは特に 1 つのサービスのみを取り扱うユーザや、クエリー ツールの使用頻度が低く、対象の項目に関するレポートを手っ取り早く必要としているユーザにとって役立ちます。

サービスをレポート可能にすることには、次の欠点があります。それにより、データ マートのサービスからディメンションを取得するハードルを下げる可能性があります。

  • サービスに(異なるディクショナリにある)同じ名前の 2 つのフィールドが含まれている場合は、サービスに基づくクエリー サブジェクトに Dictionary1_FieldName および Dictionary2_FieldName として表示されます。 紛らわしくない名前のフィールドには、フィールド名が設定されます。
  • 非常に多くのフィールドが存在する非常に多くのディクショナリを含むサービスでは、許容されるフィールド数のデフォルトから、サービスディメンションの設定を大幅に増やす必要があります。 通常、この調整により、サービスをレポート可能にするために必要な文字、日付、または数値フィールドの数が非常に大きくなってしまいます。 SQLServer マニュアルでは、これにより「行の連鎖」が引き起こされるために、パフォーマンスに悪影響が生じる可能性を警告しています。

サービス項目をレポート可能にする

任意のディクショナリまたはサービスをレポート可能として指定できます。

レポート可能なディクショナリの設定

レポート可能なディクショナリは、Service Catalog データ マートの [ディクショナリ データ(DictionaryData)] フォルダにクエリー サブジェクトとして表示されます。 ディクショナリ フィールドは、ディクショナリ内で指定した順序でディクショナリ ディメンションに表示されます。 各フィールド タイプ(文字、日付、数値)の制限数を超過しているフィールドは、データ マートから除外されます。 データ マートのクエリー項目名は、ディクショナリが定義されるときに指定したフィールド名と一致します。

ディクショナリをレポート可能にすることで、複数のサービスで使用されるディクショナリに基づいたレポートを非常に柔軟に作成できます。 ディクショナリ、必要なファクト テーブル、および任意の関連するディメンションのデータを含むレポートを自由に作成できます。

レポート可能なディクショナリとそのコンポーネント フィールドの名前を付ける際は、次のガイドラインに従います。

  • ディクショナリ名とフィールド名はより多くのユーザに公開されることになるため、これらの名前を標準化します。
  • 大文字と小文字の使用方法およびスタイルに関するサイト全体の基準を作成し、この基準を忠実に守ります。
  • 複数のフォームで使用されるディクショナリのフィールド ラベルは一貫している必要があります。 実際に、フィールド ラベルはフィールド名に非常に近い名前にする必要があります。 フィールド名はディクショナリ ディメンションに公開されます。 フィールド ラベルを使用している場合は、サービス ディメンションに公開されます。

ディクショナリをレポート可能になるように構築するには、次のガイドラインに従います。

  • ディクショナリがレポート可能である場合は、さまざまなサービスで非表示になっているフィールドを含めて、すべてのコンポーネント フィールドがデータ マートに表示されます。 すべてのコンテキストにおいて、非表示になっているフィールドをユーザに対して非表示のままにする必要がある場合は、レポート可能ではない別のディクショナリにフィールドを配置してください。
  • 必ず、予約済みのディクショナリ(Customer および Initiator)がサービスで使用されるフィールドのみを含むように設定してください。 これらのディクショナリに含まれているフィールドはすべてデータ マートに表示されます。
  • フィールド名はその内容と一致させてください。 たとえば、フィールドが「date」という名前の場合、データ タイプは日付とし、有効な日付または日時のみをフィールド値として許容するようにしてください。 そうしないと、わかりにくいユーザ インターフェイスになります。 たとえば、フィールドに無効な日付値が存在すると、ユーザは Cognos レポート作成およびクエリー ツールで日付の計算を適用できなくなります。
  • 同様に、数値を含むフィールドは数値データ タイプとして格納し、適切なサイズと 10 進数精度を適用する必要があります。 これにより、確実に数値計算を適用することができ、レポート作成またはクエリー ツールでフィールドをフォーマットする必要がなくなるため、使いやすく一貫した表示を実現できます。

ディクショナリがレポート可能になった後、最初は編集不可として Service Designer に表示されます。 ディクショナリの定義を編集するには、[レポート可能(Reportable)] 値を [いいえ(No)] に変更します。 この動作は、レポート可能になったディクショナリの定義を変更する際の影響を確実に認識してもらうための再確認です。

  • 追加されたフィールドはデータ マートのディクショナリ データに追加されます。 フィールドが追加される前に送信されたサービス要求には、そのフィールドの値は存在しません。
  • 削除されたフィールドは、データ マートの対応するクエリー サブジェクトに残ります。 フィールドの削除後の日付に送信した要求では、フィールド値は空欄になります。
  • 任意のフィールドに割り当てられたフィールド長を自由に変更できます。
  • フィールドに割り当てられたデータ タイプは変更できません。 データ タイプが変更されると、データ マートをロードする ETL プロセスが失敗します。 どうしてもデータ タイプを変更する必要がある場合は、データ マートのフォーム データ コンポーネントを再作成し、すべてのデータをリロードする必要があります。 この手順については、Cisco Technical Assistance Center(TAC)から入手できます。

レポート可能なサービスの設定

サービスをレポート可能にすると、そのサービスは [サービスデータ(ServiceData)] フォルダにクエリー サブジェクトとして表示されます。 サービス レコードは、そのサービスのすべてのレポート可能なディクショナリから構成されます。 各フィールド タイプ(文字、日付、数値)の制限数を超過しているフィールドは、データ マートから除外されます。 データ マートのクエリー オブジェクト名は、サービス用のフォームを設計するときに指定したフィールド ラベルから取得されます。 レポート可能なサービスに同じラベルの 2 つのフィールドが含まれている場合、ETL プロセスはそれらのディクショナリ フィールドを Dictionary_Label_1、Dictionary_Label_2 というクエリー項目名でデータ マートに追加します。

サービス バンドルはレポート可能として指定できます。 サービス バンドルをレポート可能にすると、そのサービス バンドルは [サービスデータ(ServiceData)] フォルダにクエリー サブジェクトとして表示されます。 サービス バンドル レコードは、子サービスとサービス バンドル自体に関連付けられたすべてのディクショナリから構成されます。

また、サービス バンドルに接続された子サービスがレポート可能である場合、子サービス レコードは各子サービスに関連付けられたディクショナリから構成されます。

レポート可能なサービスを構築する際は、レポート可能なディクショナリに関するガイドラインに加えて、次のガイドラインに従います。

  • 同じサービスの異なるディクショナリにある 2 つのフィールドに同じラベルを割り当てないでください。 ラベルはデータ マートの対応するクエリー項目の名前を付けるのに使用されるため、同じサービスで使用されるフィールドのラベルは一意である必要があります。

以前に導入したディクショナリおよびサービスの更新

サービス設計手順では、以前に導入したディクショナリおよびサービスの変更を収容するのに最適な方法も検討する必要があります。 これらの考慮事項には、Service Catalog トランザクション システムへの影響と、データ マートへの影響の両方が含まれている必要があります。

次を前提としてください。

  • ディクショナリはレポート可能で、オーダーされたサービスで使用されている。
  • データ マート(およびそのメタデータ)はすでに作成され、要求に対する設定が完了している。

ディクショナリへの変更がデータ マートの設定に与える影響にはどのようなものがあるでしょうか。 これらの影響は次の 2 つの形で現れます。

  • レポート作成メタデータへの変更。つまり、Ad-Hoc Reports および Report Designer でクエリー サブジェクトおよびクエリー オブジェクトとして利用できるディクショナリベースおよびサービスベースのディメンション、およびそのコンポーネント フィールドへの変更。
  • Extract-Transform-Load(ETL)プロセスによってデータ マートにロードされるデータへの変更。

レポート可能なディクショナリへのフィールドの追加

データ マートのロード プロセスが次回実行されるときに、レポート作成モデル(メタデータ)を作成するジョブにより、ディクショナリに対応するクエリー サブジェクトに、フィールドがクエリー項目として追加されます。 ETL プロセスで、そのフィールドが含まれるようになりました。 ディクショナリに変更が加えられた後に送信された申請に対してはフィールド値が設定され、変更された日付より前に送信されたすべての申請に対しては空欄が設定されます。

このシナリオの唯一の注意点は、ディクショナリがディクショナリ ベースまたはサービス ベースのディメンション内の各データ タイプに割り当てられたフィールドの最大数を超過していると、フィールドを追加できないという点です。 (フィールド数は Advanced Reporting がインストールされる際に指定されます。 システム管理者は、各ディクショナリのデフォルト値である 60 個の文字フィールド、10 個の日付フィールド、および 10 個の数値フィールド、および各サービスのデフォルト値である 80 個の文字フィールド、20 個の日付フィールド、および 20 個の数値フィールドをカスタマイズできます。 確信がない場合は、必ずシステム管理者に確認してください)。

いずれの場合も、現在のソフトウェアは、ディクショナリまたはサービスを表すクエリー サブジェクト内の最後のクエリー項目としてフィールドを追加します。 これは、サービス フォーム上にフィールドが表示される箇所には対応しません。

レポート可能な新しいディクショナリの追加

ディクショナリは新しいクエリー サブジェクトとなり、そのすべてのフィールドはクエリー項目になります。 ディクショナリがレポート可能になった日付の時点から、ディクショナリにデータがロードされます。

既存のサービスに対して、ディクショナリの追加をまたぐ期間の要求に関するレポートを作成することは困難です。 レポートに新しいディクショナリのフィールドを含める場合は、そのディクショナリを含む申請のみが含まれます。 新しいディクショナリおよび変更の期間をまたぐ古いディクショナリからのデータを含むレポートを生成するには、サービスベースのクエリー サブジェクトを使用するしかありません。 これとは逆に、既存のディクショナリにフィールドを追加した場合は、変更よりも前から存在する申請もレポートに表示され、新しいフィールドは空欄になります。

レポート可能なディクショナリからのフィールドの削除

データ マートのビジネス ビューは変化しません。つまり、フィールドはディクショナリに対応するクエリー サブジェクトでクエリー項目として引き続き表示されます。 ただし、ETL プロセスでは、そのフィールドにデータがロードされなくなります。

データ マートに与える影響は、フィールドを非表示にする場合と同じです。つまり、データ値はサービス要求で提供されなくなり、データ マートにも表示されなくなります。 ただし、サービス設計の観点(ディクショナリを新しいサービスに含めるたびにフィールドを非表示にする必要がなくなる)およびデータ マートの観点(ETL プロセスがデータをフィールドにロードする必要がなくなる)からは、フィールドを削除すると効率性が高まる場合があります。 もちろん、フィールドをディクショナリから削除する前に、副作用がないことを確認するために十分なテストを実施する必要があります。たとえば、ISF コードがそのフィールドを参照していないことや、削除されるフィールドに Service Link エージェント パラメータがバインドされていないことを検証する必要があります。

レポート可能なディクショナリの削除

結果は、フィールドをディクショナリから削除する場合の結果と同様です。 ディクショナリはクエリー サブジェクトとして引き続き表示されます。 ただし、基礎となるディメンションに行は追加されません。 そのディクショナリからのデータでレポートを作成しようとすると、論理的にはサービス定義にそのディクショナリが含まれていたときにオーダーされた申請のみが含まれます。

レポート可能なディクショナリの数は、Advanced Reporting 設定の一環として指定した最大数以下に制限されます。 この数はデータ マートを作成するときに入力しますが、データ マートの運用中に、システム管理者が増やすこともできます。 ただし、レポート可能なディクショナリを削除してもデータ マートからディクショナリは削除されないため、このディクショナリは許容されるディクショナリの 1 つとしてカウントされます。 ディクショナリを使用する申請がデータ マートにロードされた後に、データ マートからディクショナリを削除することはできません。

ディクショナリ名の変更

通常は、いったんディクショナリをレポート可能として指定した後に、ディクショナリ名を変更しないでください。 データ マートの対応するクエリー サブジェクトの名前が変更されてしまいます。 また一方で、ディクショナリのフィールドを使用して保存されたレポートまたはクエリーは、無効になって実行されなくなります。 (このようなレポートを修復するには、パブリック フォルダ内のレポートの書き込み権限を持つレポート オーナーまたはユーザがレポート定義を編集する必要があります)。

フィールド定義の変更

ここでは、フィールド定義パラメータについて説明します。

フィールド名の変更

フィールド名の変更は、ディクショナリ名の変更に似ています。いったんフィールドがレポート可能ディクショナリまたはレポート可能サービスに含められた後の変更は可能ですが、推奨されません。 データ マートの対応するクエリー項目の名前が変更されてしまいます。 また一方で、前のフィールド名を使用して保存したレポートまたはクエリーは無効になります。

フィールド タイプの変更

フィールドのデータ タイプ(数値、日付、文字など)は、変更しないでください。 ディクショナリに対応するディメンションが初めて作成されると、すべてのディクショナリ フィールドが適切なデータ タイプのカラムにマッピングされます。 このマッピングは変更できません。

新規フィールドを適切なタイプの同じディクショナリ内に作成して、場合によっては古いフィールドを削除する方法が可能です。 変更前後の両方のデータが必要なレポートには、両方のフィールドを含める必要があります。

フィールドの HTML 表現(表示タイプ)の変更に制限はありません。 たとえば、最初に一連のチェックボックスとして表示されていたテキスト フィールドは、データ マートに影響を及ぼすことなくドロップダウン リストとして表示できます。

フィールドの長さの変更

数値フィールドの長さを変更すると、データ マートにその変更が適用されます。 副作用の可能性は最小限です。 たとえば、フィールドの新しい許容値に対応するように、レポート内の項目に割り当てられている形式を調整しなければならない場合があります。

テキスト フィールドの長さを変更しても、その影響は最小限です。 長さが増加されて、データ マート内のテキスト フィールドに割り当てられた文字数(デフォルトでは 200)を超過した場合、フィールド内のデータが切り捨てられます。 テキスト フィールドが短くされた場合、その副作用として考えられるのは、ユーザが別の形式で以前入力された値を省略するか、あるいは短くすることです。 レポートまたはクエリーがそのフィールドに基づいたグループまたはセクション見出しを使用して設計されている場合は、行が期待どおりにグループ化されない可能性があります。

フィールド キャプションの指定

アクティブ フォーム コンポーネントにディクショナリを追加する際に、サービス設計者は、アクティブ フォーム コンポーネント内のディクショナリの各フィールドに対してキャプションを指定できます。 これらのキャプションはサービス フォームのフィールド ラベルとして表示されます。 Service Designer は、フィールド キャプションの一意性の制約を強制しません。これは、Service Catalog サービス フォーム内で許可されているためです。 ただし、サービスをレポート可能にする場合は、同じキャプションを同じディクショナリ内の複数のフィールドに使用しないでください。 結果として、同じ名前のクエリー項目が 2 つになります。これはサポートされていません。

サービス バンドルからの子サービスの削除

データ マートのビジネス ビューは変更されません。つまり、子サービスのフィールドは、サービス バンドルに対応するクエリー サブジェクトのクエリー項目として引き続き表示されます。 ただし、ETL プロセスでは、削除された子サービスに対応するフィールドにはデータがロードされません。