この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章は次のトピックで構成されています。
カスタマーの各サイトは当然異なるディクショナリおよびサービスのセットを持っているため、これらの中からレポート可能にするオブジェクトを決定する方法について厳格なルールは存在しません。 ただし、データ マートに含めるオブジェクトを決定する際は、次のガイドラインが役立つ場合があります。 詳細については、データ マートの設定を参照してください。
日付または数値を含むディクショナリは、データ マートに含める有力な候補です。
ディクショナリのすべて、またはその一部が、説明を保持するために設計された非常に大きなサイズのフィールドで構成されている場合、そのディクショナリはデータ マートに含めるのに適した候補ではありません。このようなフィールドは、データ マートが作成されるときに指定した最大文字サイズで切り捨てられます。
ビジネス ニーズにとって重要だと考えられるディクショナリは含める必要があります。 このため、対応する個人ベースのディメンションには存在せず、Organization Designer に存在していた情報よりも新しい情報を含んでいる Customer ディクショナリおよび Initiator ディクショナリを含めるのが一般的です。
サービスを含めることで、基本的に各ディクショナリを識別することなく(つまり、個別のディメンションまたはクエリー サブジェクトとして)サービス内のすべてのディクショナリに関してレポートを作成できるショートカットが提供されます。これは特に 1 つのサービスのみを取り扱うユーザや、クエリー ツールの使用頻度が低く、対象の項目に関するレポートを手っ取り早く必要としているユーザにとって役立ちます。
サービスをレポート可能にすることには、次の欠点があります。それにより、データ マートのサービスからディメンションを取得するハードルを下げる可能性があります。
任意のディクショナリまたはサービスをレポート可能として指定できます。
レポート可能なディクショナリは、Service Catalog データ マートの [ディクショナリ データ(DictionaryData)] フォルダにクエリー サブジェクトとして表示されます。 ディクショナリ フィールドは、ディクショナリ内で指定した順序でディクショナリ ディメンションに表示されます。 各フィールド タイプ(文字、日付、数値)の制限数を超過しているフィールドは、データ マートから除外されます。 データ マートのクエリー項目名は、ディクショナリが定義されるときに指定したフィールド名と一致します。
ディクショナリをレポート可能にすることで、複数のサービスで使用されるディクショナリに基づいたレポートを非常に柔軟に作成できます。 ディクショナリ、必要なファクト テーブル、および任意の関連するディメンションのデータを含むレポートを自由に作成できます。
レポート可能なディクショナリとそのコンポーネント フィールドの名前を付ける際は、次のガイドラインに従います。
ディクショナリをレポート可能になるように構築するには、次のガイドラインに従います。
ディクショナリがレポート可能になった後、最初は編集不可として Service Designer に表示されます。 ディクショナリの定義を編集するには、[レポート可能(Reportable)] 値を [いいえ(No)] に変更します。 この動作は、レポート可能になったディクショナリの定義を変更する際の影響を確実に認識してもらうための再確認です。
サービスをレポート可能にすると、そのサービスは [サービスデータ(ServiceData)] フォルダにクエリー サブジェクトとして表示されます。 サービス レコードは、そのサービスのすべてのレポート可能なディクショナリから構成されます。 各フィールド タイプ(文字、日付、数値)の制限数を超過しているフィールドは、データ マートから除外されます。 データ マートのクエリー オブジェクト名は、サービス用のフォームを設計するときに指定したフィールド ラベルから取得されます。 レポート可能なサービスに同じラベルの 2 つのフィールドが含まれている場合、ETL プロセスはそれらのディクショナリ フィールドを Dictionary_Label_1、Dictionary_Label_2 というクエリー項目名でデータ マートに追加します。
サービス バンドルはレポート可能として指定できます。 サービス バンドルをレポート可能にすると、そのサービス バンドルは [サービスデータ(ServiceData)] フォルダにクエリー サブジェクトとして表示されます。 サービス バンドル レコードは、子サービスとサービス バンドル自体に関連付けられたすべてのディクショナリから構成されます。
また、サービス バンドルに接続された子サービスがレポート可能である場合、子サービス レコードは各子サービスに関連付けられたディクショナリから構成されます。
レポート可能なサービスを構築する際は、レポート可能なディクショナリに関するガイドラインに加えて、次のガイドラインに従います。
サービス設計手順では、以前に導入したディクショナリおよびサービスの変更を収容するのに最適な方法も検討する必要があります。 これらの考慮事項には、Service Catalog トランザクション システムへの影響と、データ マートへの影響の両方が含まれている必要があります。
次を前提としてください。
ディクショナリへの変更がデータ マートの設定に与える影響にはどのようなものがあるでしょうか。 これらの影響は次の 2 つの形で現れます。
データ マートのロード プロセスが次回実行されるときに、レポート作成モデル(メタデータ)を作成するジョブにより、ディクショナリに対応するクエリー サブジェクトに、フィールドがクエリー項目として追加されます。 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 プロセスでは、削除された子サービスに対応するフィールドにはデータがロードされません。
目次
この章は次のトピックで構成されています。
カスタマーの各サイトは当然異なるディクショナリおよびサービスのセットを持っているため、これらの中からレポート可能にするオブジェクトを決定する方法について厳格なルールは存在しません。 ただし、データ マートに含めるオブジェクトを決定する際は、次のガイドラインが役立つ場合があります。 詳細については、データ マートの設定を参照してください。
日付または数値を含むディクショナリは、データ マートに含める有力な候補です。
ディクショナリのすべて、またはその一部が、説明を保持するために設計された非常に大きなサイズのフィールドで構成されている場合、そのディクショナリはデータ マートに含めるのに適した候補ではありません。このようなフィールドは、データ マートが作成されるときに指定した最大文字サイズで切り捨てられます。
ビジネス ニーズにとって重要だと考えられるディクショナリは含める必要があります。 このため、対応する個人ベースのディメンションには存在せず、Organization Designer に存在していた情報よりも新しい情報を含んでいる Customer ディクショナリおよび Initiator ディクショナリを含めるのが一般的です。
サービスを含めることで、基本的に各ディクショナリを識別することなく(つまり、個別のディメンションまたはクエリー サブジェクトとして)サービス内のすべてのディクショナリに関してレポートを作成できるショートカットが提供されます。これは特に 1 つのサービスのみを取り扱うユーザや、クエリー ツールの使用頻度が低く、対象の項目に関するレポートを手っ取り早く必要としているユーザにとって役立ちます。
サービスをレポート可能にすることには、次の欠点があります。それにより、データ マートのサービスからディメンションを取得するハードルを下げる可能性があります。
任意のディクショナリまたはサービスをレポート可能として指定できます。
レポート可能なディクショナリは、Service Catalog データ マートの [ディクショナリ データ(DictionaryData)] フォルダにクエリー サブジェクトとして表示されます。 ディクショナリ フィールドは、ディクショナリ内で指定した順序でディクショナリ ディメンションに表示されます。 各フィールド タイプ(文字、日付、数値)の制限数を超過しているフィールドは、データ マートから除外されます。 データ マートのクエリー項目名は、ディクショナリが定義されるときに指定したフィールド名と一致します。
ディクショナリをレポート可能にすることで、複数のサービスで使用されるディクショナリに基づいたレポートを非常に柔軟に作成できます。 ディクショナリ、必要なファクト テーブル、および任意の関連するディメンションのデータを含むレポートを自由に作成できます。
レポート可能なディクショナリとそのコンポーネント フィールドの名前を付ける際は、次のガイドラインに従います。
ディクショナリをレポート可能になるように構築するには、次のガイドラインに従います。
ディクショナリがレポート可能になった後、最初は編集不可として Service Designer に表示されます。 ディクショナリの定義を編集するには、[レポート可能(Reportable)] 値を [いいえ(No)] に変更します。 この動作は、レポート可能になったディクショナリの定義を変更する際の影響を確実に認識してもらうための再確認です。
サービスをレポート可能にすると、そのサービスは [サービスデータ(ServiceData)] フォルダにクエリー サブジェクトとして表示されます。 サービス レコードは、そのサービスのすべてのレポート可能なディクショナリから構成されます。 各フィールド タイプ(文字、日付、数値)の制限数を超過しているフィールドは、データ マートから除外されます。 データ マートのクエリー オブジェクト名は、サービス用のフォームを設計するときに指定したフィールド ラベルから取得されます。 レポート可能なサービスに同じラベルの 2 つのフィールドが含まれている場合、ETL プロセスはそれらのディクショナリ フィールドを Dictionary_Label_1、Dictionary_Label_2 というクエリー項目名でデータ マートに追加します。
サービス バンドルはレポート可能として指定できます。 サービス バンドルをレポート可能にすると、そのサービス バンドルは [サービスデータ(ServiceData)] フォルダにクエリー サブジェクトとして表示されます。 サービス バンドル レコードは、子サービスとサービス バンドル自体に関連付けられたすべてのディクショナリから構成されます。
また、サービス バンドルに接続された子サービスがレポート可能である場合、子サービス レコードは各子サービスに関連付けられたディクショナリから構成されます。
レポート可能なサービスを構築する際は、レポート可能なディクショナリに関するガイドラインに加えて、次のガイドラインに従います。
サービス設計手順では、以前に導入したディクショナリおよびサービスの変更を収容するのに最適な方法も検討する必要があります。 これらの考慮事項には、Service Catalog トランザクション システムへの影響と、データ マートへの影響の両方が含まれている必要があります。
次を前提としてください。
ディクショナリへの変更がデータ マートの設定に与える影響にはどのようなものがあるでしょうか。 これらの影響は次の 2 つの形で現れます。
データ マートのロード プロセスが次回実行されるときに、レポート作成モデル(メタデータ)を作成するジョブにより、ディクショナリに対応するクエリー サブジェクトに、フィールドがクエリー項目として追加されます。 ETL プロセスで、そのフィールドが含まれるようになりました。 ディクショナリに変更が加えられた後に送信された申請に対してはフィールド値が設定され、変更された日付より前に送信されたすべての申請に対しては空欄が設定されます。
このシナリオの唯一の注意点は、ディクショナリがディクショナリ ベースまたはサービス ベースのディメンション内の各データ タイプに割り当てられたフィールドの最大数を超過していると、フィールドを追加できないという点です。 (フィールド数は Advanced Reporting がインストールされる際に指定されます。 システム管理者は、各ディクショナリのデフォルト値である 60 個の文字フィールド、10 個の日付フィールド、および 10 個の数値フィールド、および各サービスのデフォルト値である 80 個の文字フィールド、20 個の日付フィールド、および 20 個の数値フィールドをカスタマイズできます。 確信がない場合は、必ずシステム管理者に確認してください)。
いずれの場合も、現在のソフトウェアは、ディクショナリまたはサービスを表すクエリー サブジェクト内の最後のクエリー項目としてフィールドを追加します。 これは、サービス フォーム上にフィールドが表示される箇所には対応しません。
ディクショナリは新しいクエリー サブジェクトとなり、そのすべてのフィールドはクエリー項目になります。 ディクショナリがレポート可能になった日付の時点から、ディクショナリにデータがロードされます。
既存のサービスに対して、ディクショナリの追加をまたぐ期間の要求に関するレポートを作成することは困難です。 レポートに新しいディクショナリのフィールドを含める場合は、そのディクショナリを含む申請のみが含まれます。 新しいディクショナリおよび変更の期間をまたぐ古いディクショナリからのデータを含むレポートを生成するには、サービスベースのクエリー サブジェクトを使用するしかありません。 これとは逆に、既存のディクショナリにフィールドを追加した場合は、変更よりも前から存在する申請もレポートに表示され、新しいフィールドは空欄になります。
データ マートのビジネス ビューは変化しません。つまり、フィールドはディクショナリに対応するクエリー サブジェクトでクエリー項目として引き続き表示されます。 ただし、ETL プロセスでは、そのフィールドにデータがロードされなくなります。
データ マートに与える影響は、フィールドを非表示にする場合と同じです。つまり、データ値はサービス要求で提供されなくなり、データ マートにも表示されなくなります。 ただし、サービス設計の観点(ディクショナリを新しいサービスに含めるたびにフィールドを非表示にする必要がなくなる)およびデータ マートの観点(ETL プロセスがデータをフィールドにロードする必要がなくなる)からは、フィールドを削除すると効率性が高まる場合があります。 もちろん、フィールドをディクショナリから削除する前に、副作用がないことを確認するために十分なテストを実施する必要があります。たとえば、ISF コードがそのフィールドを参照していないことや、削除されるフィールドに Service Link エージェント パラメータがバインドされていないことを検証する必要があります。
結果は、フィールドをディクショナリから削除する場合の結果と同様です。 ディクショナリはクエリー サブジェクトとして引き続き表示されます。 ただし、基礎となるディメンションに行は追加されません。 そのディクショナリからのデータでレポートを作成しようとすると、論理的にはサービス定義にそのディクショナリが含まれていたときにオーダーされた申請のみが含まれます。
レポート可能なディクショナリの数は、Advanced Reporting 設定の一環として指定した最大数以下に制限されます。 この数はデータ マートを作成するときに入力しますが、データ マートの運用中に、システム管理者が増やすこともできます。 ただし、レポート可能なディクショナリを削除してもデータ マートからディクショナリは削除されないため、このディクショナリは許容されるディクショナリの 1 つとしてカウントされます。 ディクショナリを使用する申請がデータ マートにロードされた後に、データ マートからディクショナリを削除することはできません。
通常は、いったんディクショナリをレポート可能として指定した後に、ディクショナリ名を変更しないでください。 データ マートの対応するクエリー サブジェクトの名前が変更されてしまいます。 また一方で、ディクショナリのフィールドを使用して保存されたレポートまたはクエリーは、無効になって実行されなくなります。 (このようなレポートを修復するには、パブリック フォルダ内のレポートの書き込み権限を持つレポート オーナーまたはユーザがレポート定義を編集する必要があります)。
ここでは、フィールド定義パラメータについて説明します。
フィールド名の変更は、ディクショナリ名の変更に似ています。いったんフィールドがレポート可能ディクショナリまたはレポート可能サービスに含められた後の変更は可能ですが、推奨されません。 データ マートの対応するクエリー項目の名前が変更されてしまいます。 また一方で、前のフィールド名を使用して保存したレポートまたはクエリーは無効になります。
フィールドのデータ タイプ(数値、日付、文字など)は、変更しないでください。 ディクショナリに対応するディメンションが初めて作成されると、すべてのディクショナリ フィールドが適切なデータ タイプのカラムにマッピングされます。 このマッピングは変更できません。
新規フィールドを適切なタイプの同じディクショナリ内に作成して、場合によっては古いフィールドを削除する方法が可能です。 変更前後の両方のデータが必要なレポートには、両方のフィールドを含める必要があります。
フィールドの HTML 表現(表示タイプ)の変更に制限はありません。 たとえば、最初に一連のチェックボックスとして表示されていたテキスト フィールドは、データ マートに影響を及ぼすことなくドロップダウン リストとして表示できます。
数値フィールドの長さを変更すると、データ マートにその変更が適用されます。 副作用の可能性は最小限です。 たとえば、フィールドの新しい許容値に対応するように、レポート内の項目に割り当てられている形式を調整しなければならない場合があります。
テキスト フィールドの長さを変更しても、その影響は最小限です。 長さが増加されて、データ マート内のテキスト フィールドに割り当てられた文字数(デフォルトでは 200)を超過した場合、フィールド内のデータが切り捨てられます。 テキスト フィールドが短くされた場合、その副作用として考えられるのは、ユーザが別の形式で以前入力された値を省略するか、あるいは短くすることです。 レポートまたはクエリーがそのフィールドに基づいたグループまたはセクション見出しを使用して設計されている場合は、行が期待どおりにグループ化されない可能性があります。
アクティブ フォーム コンポーネントにディクショナリを追加する際に、サービス設計者は、アクティブ フォーム コンポーネント内のディクショナリの各フィールドに対してキャプションを指定できます。 これらのキャプションはサービス フォームのフィールド ラベルとして表示されます。 Service Designer は、フィールド キャプションの一意性の制約を強制しません。これは、Service Catalog サービス フォーム内で許可されているためです。 ただし、サービスをレポート可能にする場合は、同じキャプションを同じディクショナリ内の複数のフィールドに使用しないでください。 結果として、同じ名前のクエリー項目が 2 つになります。これはサポートされていません。