Cisco Prime Service Catalog 11.0 レポート ガイド
DataMart について
DataMart について

目次

DataMart について

この付録は、次の内容で構成されています。

カスタム レポート データ モデル

ここでは、データ マートのさまざまなスキーマ設計について説明します。

データ マート スキーマ設計およびビジネス ビュー

データ マート スキーマは、IBM Cognos Framework Manager 用、IBM Cognos レポート ツール(Query Studio および Report Studio。それぞれ Service Catalog Advanced Reporting モジュールでは Ad-Hoc Reports、Report Designer として表示されます)で使用するビジネス ビュー用に設計されています。 したがって、データ マートに関する章では、クエリー サブジェクトの内容と関係について概説していますが、レポートのユーザまたは設計者には公開されない基礎となるデータ モデルについては取り上げていません。

この章は、Cognos ツールで公開されているビジネス ビューの基礎となる物理データ モデルを調査する技術担当者を対象にしています。 特に、次の図に示されているデータベース オブジェクトの名前をクエリー サブジェクトの対応する名前にマッピングする際の参考にしてください。 以下に示す図の内容は、次のとおりです。

  • Queue クエリー サブジェクトは V_DM_PERSON データベース ビューを基にしており、QUEUEID 列を介してタスク ビューに接続されています。
  • また、Performer クエリー サブジェクトは V_DM_PERSON.PERSONID ビジネス ビューを基にしており、PERFORMERID 列を介してタスク ビューと接続されています。
  • また、Customer クエリー サブジェクトおよび Requestor クエリー サブジェクト(ディメンション)は V_DM_PERSON データベース ビューを基にしており、それぞれ CUSTOMERID および REQUESTORID を介して申請ビューに接続されています
  • すべての日付ディメンション(CalendarStartedDate、CalendarDueDate、CalendarClosedDate、および CalendarScheduledDate)は V_DM_DATE ビジネス ビューを基にしています。 これらのディメンションは、それぞれ STARTEDDATEKEY、DUEDATEKEY、COMPLETEDDATEKEY および SCHEDULEDSTARTDATEKEY によってタスク ビューおよび申請ビューと接続されています。
  • また、すべてのファクト テーブルには、V_DM_SERVICEBUNDLE にある Bundled Service データへの接続(図には記述されていない)が含まれています。

AllTaskFact(すべてのタスク)のスター スキーマ設計

図 1. AllTaskFact のスキーマ設計

AuthTaskFact(承認タスク)のスター スキーマ設計

図 2. AuthTaskFact のスキーマ設計

DeliveryTaskFact(提供タスク)のスター スキーマ設計

図 3. DeliveryTaskFact のスキーマ設計

ServiceRequestFact(申請)のスター スキーマ設計

図 4. ServiceRequestFact のスキーマ設計

ディクショナリベースおよびサービスベースのディメンション

上記の図は不完全です。 すべてのファクト テーブルは、実際にはディクショナリベースおよびサービスベースのディメンション テーブルに対して 1 対多の関係になっています。 グリッド ディクショナリが含まれていないサービスの場合、関係は常に 1 対 1 になります(詳細については、DM_FDR_SERVICETABLE_n XREF を参照してください)。 これらの関係は [REQUISITIONENTRYID] 列を介して実装され、すべてのファクトおよびディメンション テーブルに存在しますが、ビジネス ビューのディメンションには表示されません。

接続されているサービスおよびタスク ファクト テーブルとともに Query Studio または Report Designer を使用してレポートを作成する際は、これらのテーブル間の 1 対多の関係が原因で、タスク データが反復されて表示される場合があります。 レポート作成ツールのグループ化機能を使用して、同一の情報を折りたたむことができます。

[ディクショナリ(Dictionaries)] フォルダおよび [サービス(Services)] フォルダの下のデータ マートに表示されるディクショナリベースおよびサービスベースのクエリー サブジェクトは、それぞれ DM_FDR_DICTIONARYTABLE_n および DM_FDR_SERVICETABLE_n という名前の物理データベース内のテーブルに対応しています。ここで、

  • n は 1 から始まる連続した数です。また、
  • 各タイプのテーブル数は Advanced Reporting オプションが設定されるときに指定する数によって決定されます。

物理テーブルとレポート可能なオブジェクトとの間のマッピングは、DM_FDR_DICTIONARYMETADATA テーブルおよび DM_FDR_SERVICEMETADATA テーブルで管理されます。 これらのテーブルには、オブジェクトがレポート可能として指定された時点でデータが入力され、ETL プロセスで、レポート可能なオブジェクトを組み込むためにデータ マートのビジネス ビューを動的に調整する際に使用されます。

Advanced Reporting の Ad-Hoc Reports および Report Designer モジュールで提供されているビジネス ビューをバイパスすることによって IBM Cognos Business Intelligence ツールの使用を補完する場合は、それらの METADATA テーブルを調査し、ディクショナリベースおよび/またはサービスベースのクエリー サブジェクトに一致するデータベース ビューを構築します。 次に、MemoryDetails ディクショナリのデータベース ビューを作成するためのサンプル(SQLServer 固有の)SQL 文を示します。 これは(言うまでもなく)作業の出発点にすぎません。

SELECT distinct 'CREATE VIEW ' + dictionaryname + ' (' AS SQLColumn,
       'A 0' AS DestinationColumnName
  FROM dm_fdr_dictionarymetadata
 WHERE dictionaryname = 'MemoryDetails'
UNION
SELECT '  ' + dictionaryattributename, 'A ' + DestinationColumnName
  FROM dm_fdr_dictionarymetadata
 WHERE dictionaryname = 'MemoryDetails'
   AND DestinationColumnName = 'FIELD1'
UNION
SELECT ', ' + dictionaryattributename, 'A ' + DestinationColumnName
  FROM dm_fdr_dictionarymetadata
 WHERE dictionaryname = 'MemoryDetails'
   AND DestinationColumnName <> 'FIELD1'
UNION
SELECT ', REQUISITIONENTRYID, REQUISITIONID, SERVICEID', 'A Y'
UNION
SELECT ') AS SELECT' , 'A Z'
UNION
SELECT '  ' + DestinationColumnname, 'B ' + DestinationColumnName
  FROM dm_fdr_dictionarymetadata
 WHERE dictionaryname = 'MemoryDetails'
   AND DestinationColumnName = 'FIELD1'
UNION
SELECT ', ' + DestinationColumnname, 'B ' + DestinationColumnName
  FROM dm_fdr_dictionarymetadata
 WHERE dictionaryname = 'MemoryDetails'
   AND DestinationColumnName <> 'FIELD1'
UNION
SELECT ', REQUISITIONENTRYID, REQUISITIONID, SERVICEID', 'B Y'
UNION
SELECT distinct 'FROM ' + DestinationTableName, 'B Z'
  FROM dm_fdr_dictionarymetadata
 WHERE dictionaryname = 'MemoryDetails'
ORDER BY DestinationColumnName

この SQL 文を実行すると、次のような SQL コマンドになります。

CREATE VIEW MemoryDetails (
  CurrentMemorySize
, MemoryType
, MemorySizeNeeded
, Reason
, REQUISITIONENTRYID, REQUISITIONID, SERVICEID
) AS SELECT
  FIELD1
, FIELD2
, FIELD3
, FIELD4
, REQUISITIONENTRYID, REQUISITIONID , SERVICEID
FROM DM_FDR_DICTIONARYTABLE_18

データ マートの管理

この項は、Service Catalog レポート ソリューションの技術的実装の詳細について知る必要がある方を対象としたものです。 これには、レポート作成環境に責任を持つレポート管理者、Cisco TAC に問題を報告するサポート担当者、レポート作成オプションのカスタマイズや機能強化のためのコンポーネントのオプションについて調査するアナリストや設計者が含まれます。

データ マートのソース データ

データ マート内のデータが正確で、欠落がないことは非常に重要です。 これらの品質を評価するために、データ マート内のデータのソースについて文書化しておくことが大切です。 カスタム データ マートで使用可能なクエリー サブジェクトにあるデータに関与する OLTP データベース内のテーブルを次の表に示します。

表 1 データ マートのソース データ テーブル

データ マートのクエリー サブジェクト

OLTP データベース テーブル

ディクショナリ データ(ユーザ固有のレポート可能なディクショナリ)

DefDataDictionary

DefObjectDictionaries

TxRequisitionEntry

サービス フォーム データ(ユーザ固有のレポート可能なサービス)

DefService

DefServiceExtension

DefDataDictionay

DefObjectDictionaries

DefData

TxRequisionEntry

サービス

DefService

DefArea

DirOrganizationalUnit

ディクショナリ

DefDataDictionary

DefDictionaryGroup

キーワード

DefKeyword

グループ

DirGroup

マニュアルの構成

DirOrganizationalUnit

カスタマー

要求元(Requestor)

実行者

Person

キュー(Queue)

DirPerson

DirOrganizationalUnit

DirNetworkInfo

DirLocation

DirAddress

ServiceRequestFact

TxRequistionEntry

TxRequisition

ServiceTaskFact

TxRequisitionEntry

TxActivity

RequisitionTaskFact

TxRequisition

TxActivity

TaskEffortEntryFact

TxBilling

DefExpenditureType

DefBillingClass

DefUnitType

DirOrganizationalUnit

DirPerson

サービス フォームの Reporting メタデータ

データ マート ETL プロセスは、データ マート データベース内のテーブルのセットを使用して、Ad-Hoc Reports および Report Designer オプションでユーザに公開される ServiceData および DictionaryData ディメンションを設定します。 これらのテーブルは、カスタム レポート パッケージがインストールされるときに作成され、データがデータ マートにロードされたときに入力されます。

これらのメタデータ テーブルは、Cognos フレームワークでは公開されません。 これらのテーブルの内容は、カスタム レポート プロジェクト内のデータのビジネス ビューとして表示される、動的に定義されるディクショナリ ベースおよびサービス ベースのディメンションを指定するために使用します。

以下に、これらのテーブルについて説明します。 各列の説明には抽象化されたデータ タイプを使用します。実際のデータ タイプは、データ マートが置かれたデータベース(Oracle または SQLServer)によって異なります。

DM_FDR_ETLDICTIONARYMETADATA

DM_FDR_ETLDICTIONARYMETADATA テーブルは、特定のレポート可能ディクショナリ(DictionaryID で識別)を、ディクショナリ データが格納される DM_FDR_DICTIONARY_n テーブル(DictionaryTableName)にマッピングします。 また、ディクショナリ内および対応するデータ マート テーブル内で使用されている日付型、数値型、Varchar 型のフィールドの数を追跡します。

表 2 DM_FDR_ETLDICTIONARYMETADATA テーブル

列名

データ タイプ

説明

DictionaryID

整数(Integer)

ディクショナリの固有識別子。

DictionaryTableName

Varchar(50)

ディクショナリ データが格納されるデータ マート テーブルの名前。

LastDictionaryDateField

整数(Integer)

ディクショナリ テーブル内で使用された最後の日時型フィールド。

LastDictionaryNumericField

整数(Integer)

ディクショナリ テーブル内で使用された最後の数値型フィールド。

LastDictionaryVarcharField

整数(Integer)

ディクショナリ テーブル内で使用された最後の文字型フィールド。

DM_FDR_DICTIONARYMETADATA

DM_FDR_DICTIONARYMETADATA テーブルは、個別のディクショナリ フィールド(属性)(DictionaryID および DictionaryAttributeName で識別)と、ディクショナリ テーブルの特定の列とをマッピングします。 たとえば、ディクショナリ RC_REQUESTEDBY の属性「LastName」を、データ マート テーブル DM_FDR_DICTIONARYTABLE_10, のフィールド「Field2」にマッピングする(実際には、格納する)ことができます。

表 3 DM_FDR_DICTIONARYMETADATA テーブル

列名

データ タイプ

説明

DestinationColumnName

Varchar(100)

この属性が格納される、テーブルの列名

DestinationTableName

Varchar(200)

ディクショナリ情報が格納されるテーブルの名前

DictionaryAttributeName

Varchar(100)

ディクショナリ内の属性の名前

DictionaryAttributeType

Varchar(100)

ディクショナリ内の属性のデータ タイプ

DictionaryID

整数(Integer)

ディクショナリ ID

DictionaryName

Varchar(200)

ディクショナリ名

DictionaryAttributeID

整数(Integer)

ディクショナリ属性 ID

DM_FDR_ETLMETADATA

DM_FDR_ETLMETADATA テーブルには、Reporting オプションのインストール時に指定されたカスタム レポート パッケージの設定についての情報と、データ抽出プロセス(ETL)および ETL プロセスのスケジュール実行用の最終更新情報が保持されます。

表 4 DM_FDR_ETLMETADATA テーブル

列名

データ タイプ

説明

DictionaryTablePattern

Varchar(50)

ディクショナリ テーブルの名前のパターン。デフォルトでは DM_FDR_DICTIONARY_ です。Advanced Reporting のインストールにより指定されます。 ディクショナリ テーブルには、指定された名前の後に数値が付加された名前が付けられます。

Field Pattern

Varchar(50)

ディクショナリとサービス テーブルの両方で使用するフィールド パターン。デフォルトでは FIELD_ です

LastDictionaryTableSequence

整数(Integer)

現在データ マートで使用されている最後のディクショナリ テーブルのシーケンス番号。

LastDictRequisitionID

整数(Integer)

データがディクショナリ テーブルに書き込まれた最後の申請 ID。

LastProcessedTime

日時(Datetime)

カスタム レポート パッケージをロードする ETL が最後に実行された日付と時刻。

LastServiceTableSequence

整数(Integer)

データ マートで使用された最後のサービス テーブルのシーケンス番号。

LastSvcRequisitionID

整数(Integer)

サービス データの最後の申請 ID。

ServiceTablePattern

Varchar(50)

サービス テーブルの名前のパターン。デフォルトでは DM_FDR_SERVICE_ です。Advanced Reporting インストールにより指定されます。

DictionaryTotalDateField

整数(Integer)

ディクショナリおよびサービス テーブルに使用された日付型フィールドの総数。

DictionaryTotalNumericField

整数(Integer)

ディクショナリおよびサービス テーブルに使用された数値型フィールドの総数。

DictionaryTotalVarcharField

整数(Integer)

ディクショナリおよびサービス テーブルに使用された文字型フィールドの総数。

ServiceTotalDateField

整数(Integer)

サービス テーブルに使用された日付型フィールドの総数。

ServiceTotalNumericField

整数(Integer)

サービス テーブルに使用された数値型フィールドの総数。

ServiceTotalVarcharField

整数(Integer)

サービス テーブルに使用された文字型フィールドの総数。

DM_FDR_ETLSERVICEMETADATA

DM_FDR_ETLSERVICEMETADATA テーブルは、レポート可能な各サービスに関する情報を格納するために使用するテーブルの情報を保持します。

表 5 DM_FDR_ETLSERVICEMETADATA テーブル

列名

データ タイプ

説明

LastServiceDateField

整数(Integer)

サービス テーブル内で使用された最後の日付時刻型フィールド。

LastServiceNumericField

整数(Integer)

サービス テーブル内で使用された最後の数値型フィールド。

LastServiceVarcharField

整数(Integer)

サービス テーブル内で使用された最後の文字型フィールド。

ServiceID

整数(Integer)

サービスに割り当てられた固有識別子。

ServiceTableName

Varchar

サービス データが格納されるデータ マート データベース テーブルの名前。

DM_FDR_SERVICEMETADATA

DM_FDR_SERVICEMETADATA テーブルは、サービス テーブルのどの列でどのサービス属性が入力されたかについてのメタデータ情報、および各列の使用名を保持します。

表 6 DM_FDR_SERVICEMETADATA テーブル

列名

データ タイプ

説明

DestinationColumnName

Varchar(100)

この属性が格納される、テーブルの列名

DestinationTableName

Varchar(200)

サービス情報が格納されるテーブルの名前。

ServiceAttributeName

Varchar(100)

サービス内の属性の名前。

ServiceAttributeLabel

Varchar(200)

サービス内の属性のキャプション。

ServiceAttributeType

Varchar(100)

Attribute type

ServiceAttributeID

整数(Integer)

サービスの属性の ID。

ServiceID

整数(Integer)

サービス ID(Service ID)

ServiceName

Varchar(200)

サービスの名前

動的に定義されるディメンション

カスタム レポート パッケージに追加されるディクショナリの性質と数、およびその属性は動的に決定されるため、Service Catalog のインストールごとに大きく異なる場合があります。 必要とされる柔軟性をサポートするために、カスタム レポート パッケージをサポートするデータベースには、ディクショナリとその属性およびディクショナリ(フォーム)データを使用したサービス設定に対応するディメンショナル データを保持する、抽象的データ構造が含まれています。 ディクショナリの内容は、前述の DM_FDR メタデータ テーブルによってこれらのテーブルにマッピングされます。

DM_FDR_DICTIONARYTABLE_n

アプリケーション内の各レポート可能ディクショナリの属性(フィールド)をキャプチャする、一連のテーブルです。 これらのテーブルの数、およびデータ タイプ(文字、数値、日時)ごとの列数は、アプリケーション インストールの一部として設定可能です。

各テーブルは、DM_FDR_DICTIONARYTABLE(またはインストール手順で指定された別のパターン)に数値サフィックス「_n」が付加された名前になります。 各テーブルには、1 から順に番号が付けられます。 このテーブルの各インスタンスが、レポート可能ディクショナリを表します。

DM_FDR_DICTIONARYTABLE は、レポーティング ツールでは [ディクショナリ データ(DictionaryData)] フォルダ内のディメンションのセットとして表示されます。 各ディメンションの名前は、対応するディクショナリのキャプションです。 (キャプションのないディクショナリでは、ディクショナリの名前が使用されます)。ディメンションの属性は、ディクショナリを構成するフィールドです。 フィールドには、1 から順に番号が付けられます。 データ タイプ(文字、数値、日時)ごとのフィールド数は、アプリケーション インストール手順で指定します。

表 7 DM_FDR_DICTIONARYTABLE_n テーブル

列名

データ タイプ

説明

DictionaryID

整数(Integer)

ディクショナリ ID

RequisitionID

整数(Integer)

申請 ID

RequisitionEntryID

整数(Integer)

申請エントリ ID

Field1 ~ Fieldn

Varchar(200)

ディクショナリ データを保持する Varchar フィールド

Fieldn+1n+m

Numeric

ディクショナリ データを保持する数値型フィールド

Fieldn+m+1 ~

日時(Datetime)

ディクショナリ データを保持する日時型フィールド

DM_FDR_SERVICETABLE_n

レポート可能として指定された各サービスのデータをキャプチャする、一連のテーブルです。 このテーブルは、サービスで使用されるすべてのディクショナリ内のフィールドすべてを含みます。 これらのテーブルの数、およびデータ タイプ(文字、数値、日時)ごとの列数は、アプリケーション インストールの一部として設定可能です。 各テーブルには、1 から順に番号が付けられます。

各テーブルは、DM_FDR_SERVICETABLE(またはインストール手順で指定された別のパターン)に数値サフィックス「_n」が付加された名前になります。 このテーブルの各インスタンスが、レポート可能サービスを表します。

DM_FDR_SERVICETABLE は、レポート作成ツールでは [サービスデータ(ServiceData)] フォルダ内のディメンションのセットとして表示されます。 各ディメンションの名前は、対応するサービスの名前です。 ディメンションの属性は、サービス内のディクショナリすべてを構成するフィールドです。 フィールドは、サービス内でディクショナリが出現する順でこのテーブルに追加されます。 各テーブルに収容できるフィールドの数は限られているため(インストール プロシージャで指定されますが、データベース制約によって物理的に制限されます)、サービス テーブルは不完全な場合があり、一部のフィールド、実際には一部のディクショナリが切り捨てられている場合があります。 このため、DM_FDR_SERVICETABLE の扱いには注意が必要です。特に、大量のフィールドを持つディクショナリがレポート可能として指定されている場合や、同一サービス内で多数のディクショナリが使用されている場合には注意が必要です。

表 8 DM_FDR_SERVICETABLE_n テーブル

列名

データ タイプ

説明

ServiceID

整数(Integer)

サービス ID(Service ID)

RequisitionID

整数(Integer)

申請 ID

RequisitionEntryID

整数(Integer)

申請エントリ ID

Field1 ~ Fieldn

Varchar(200)

サービス データを保持する Varchar フィールド

Fieldn+1n+m

Numeric

サービス データを保持する数値型フィールド

Fieldn+m+1 ~

日時(Datetime)

サービス データを保持する日時型フィールド

レポート可能グリッド ディクショナリなしで設定されたサービスの場合、サービスに対する各要求(申請エントリ)は ETL プロセスによってキャプチャされ、対応する DM_FDR_SERVICETABLE に 1 行のデータとして挿入されます。 ただし、1 つ以上のレポート可能グリッド ディクショナリが設定されたサービスの場合、ETL プロセスは DM_FDR_SERVICETABLE テーブルに複数行のデータを挿入します。 挿入される行の数は、レポート可能グリッド ディクショナリのうち最大の行数に対応します。

たとえば、レポート可能非グリッド ディクショナリ 1 つ(Employee)と、レポート可能グリッド ディクショナリ 2 つ(Contact、Address)を持つサービスがあるとします。 このサービスに対する要求が、Contact 内のデータ 3 行、Address 内のデータ 2 行、Employee ディクショナリ内のいくらかのデータを持つと仮定します。 このサービスに対してサービス テーブル内にキャプチャされたフォーム データは、次のようになります。

表 9 サービス テーブル内のフォーム データ

RequisitionEntryID

Employee. FirstName

Employee. LastName

Contact. タイプ(Type)

Contact. 詳細(Details)

Address. 回線(Line)

Address. 市区町村郡(City)

Address. 状態

Address. 国(Country)

NNN

John

Smith

セル

650-123-4567

3333 Third St.

San Mateo

CA

USA

NNN

(NULL)

(NULL)

作業

408-765-4321

1111 First St.

San Jose

CA

USA

NNN

(NULL)

(NULL)

E メール

jsmith@company.com

(NULL)

(NULL)

(NULL)

(NULL)

データ マートのデータベース オブジェクト

次の表に、Service Catalog データ マートに使用され、カスタム レポート パッケージによってユーザに公開されるデータベース テーブルとビューの一覧を示します。 テーブルやビューは、対応するクエリー サブジェクトに直接マッピングされます。

表 10 データ マートのデータベース オブジェクト テーブル

データ マート テーブル/ビュー

プライマリ キー

クエリー サブジェクト/説明

DM_DEFSERVICE

ServiceID

サービス情報(サービス グループおよびサービス チームの情報を含む)

DM_DEFDICTIONARY

DictionaryID

ディクショナリ情報

DM_PERSON

PersonID

個人の情報

DM_DATE

DateID

カレンダー情報

VIEW_CUSTOMER

CustomerID

顧客情報

VIEW_REQUESTOR

RequestorID

要求元(イニシエータ)情報

VIEW_PERFORMER

PerformerID

タスクを実行する個人についての情報

VIEW_QUEUE

QueueID

タスクが割り当てられたキュー

VIEW_CALENDARCLOSEDDATE

ClosedDateID

タスクまたは申請がクローズされた日付および付随する日付階層

VIEW_CALENDARDUEDATE

DueDateID

タスクまたは申請の期限となる日付および付随する日付階層

VIEW_CALENDARSCHEDULEDDATE

ScheduledDateID

タスクまたは申請を開始するようスケジュールされた日付および付随する日付階層

VIEW_CALENDARSTARTEDDATE

StartedDateID

タスクまたは申請が開始された日付および付随する日付階層

DM_REQUISITIONENTRYFACT

RequisitionEntryID

オーダーされた個別の申請エントリ(サービス)

DM_SERVICETASKFACT

ServiceTaskID

サービス(申請エントリ)レベルで実行されるタスク(提供タスク、追加タスク、サービス グループの承認およびレビューを含む)

DM_REQUISITONTASKFACT

RequisitionTaskID

申請レベルで実行されるタスク(財務承認、組織単位の承認とレビューを含む)

DM_TASKEFFORTENTRYFACT

EffortEntryID

提供タスクの実行に費やされた工数

DM_FDR_DICTIONARY_n(n=1、2、3、...)

RequisitionEntryID

対応するディクショナリ属性情報

DM_FDR_SERVICE_n

(n=1、2、3、...)

RequsitionEntryID

対応するサービス フォーム データ属性情報

データ マートを構成するテーブルには、複数のクエリー サブジェクトからデータを取得するクエリーやレポートのパフォーマンスを最適化するためにインデックスが付けられています。 ディクショナリ ベースとサービス ベースのディメンションは動的であるため、これらのテーブルにはインデックスが追加されません。

静的に定義されたファクトおよびディメンション テーブルに提供されるインデックスの概要を次に示します。

表 11 ファクトおよびディメンション テーブルのインデックス

データ マート テーブル/ビュー

プライマリ キー

追加インデックス

DM_DEFSERVICE

ServiceID

SERVICENAME

DM_DEFDICTIONARY

DictionaryID

DICTIONARYNAME

DM_PERSON

PersonID

PERSONFIRSTNAMEPERSONLASTNAME

ISQUEUE

DM_DATE

DateID

(なし)

DM_REQUISITIONENTRYFACT

RequisitionEntryID

SERVICEID

REQUESTORID

CUSTOMERID

STARTEDDATE

CLOSEDDATE

DUEDATE

DM_SERVICETASKFACT

ServiceTaskID

REQUISITIONENTRYID

PERFORMERID

SERVICEID

STARTEDDATE

COMPLETEDDATE

DUEDATE

QUEUEID

DM_REQUISITONTASKFACT

RequisitionTaskID

PERFORMERID

STARTEDDATE

COMPLETEDDATE

DUEDATE

QUEUEID

ファクトとディメンションの関係

申請(ServiceRequestFact)は、関連するすべてのディメンション(前に記載したスター スキーマに表示)に「内部結合」されます。 これは、申請とディメンションの両方からのクエリー項目の使用を試みると、ディメンション内に対応する行を持つ申請だけが表示されることを意味しています。 一般に、静的に定義されたすべてのディメンションについては、これは要素とはなりません。すべての申請には、静的に定義されたディメンションが必要であるためです。 たとえば、申請には基本的に、カスタマーとイニシエータ、要求されるサービス、およびそれらの申請の提供に関するすべての日付が必要です。

これは、レポートの作成に密接に関係しています。 たとえば、レポートの定義を開始して、カスタマーのセットを選択してから特定の期間でフィルタリングした申請データを追加する場合、その期間にサービスをオーダーしていないカスタマーはレポートから消えることになります。

動的に定義される、ディクショナリ ベースのディメンションでは、これは非常に重要になります。 あるディクショナリが特定のサービスで使用されていない場合、そのディクショナリ ベースのディメンションからのクエリー項目を含むレポートには、そのサービスに対する申請が表示されません。

同様に、提供タスク(ServiceTaskFact)およびサービス レベルの承認(RequisitionTaskFact)の場合、内部結合によってファクトがキューを除くすべてのディメンション テーブルに関連付けられます。 これらのファクトは、自由な関連付けをサポートする「外部結合」によってキュー ディメンションに結合されます。 これにより、サービス設計者はタスクをキューではなく特定の個人や役職に割り当てることができます。 タスクがキューに割り当てられなかった場合、レポートには引き続き表示されるものの、キューは空白になります。

要求レベルの承認(AuthTaskFact)の場合も、キューはオプションです。 また、承認は要求を構成する個別のサービスに対してではなく要求レベルで実行されるため、サービスは無関係です。

組織データ内の関係

[組織(Organizations)] フォルダでは、人、組織、グループについてのレポートを作成できます。 Service Catalog は、これらのエンティティ間の多対多関係をサポートしています。 たとえば、1 人の人員が複数の組織(営業部門や複数のサービス チーム)のメンバーである場合があります。また、1 つの組織は多数の人員で構成されます。 これらの関係はデータ マート設計に反映されるため、レポート上でこれらのエンティティ 2 つを組み合わせ、いずれかのエンティティでグループ化できます。 たとえば、すべての組織についてメンバーをリストするレポートを作成できます。また、特定の人員を選択して、その人員が所属する組織をすべてリストすることも可能です。

ファクト間の関係

表 12 ファクト間の関係テーブル

ファクト 1

ファクト 2

関係の種類

ServiceRequestFact

ServiceTaskFact

左外部結合

ServiceRequestFact

DeliveryTaskFact

内部結合

ServiceRequestFact

AuthTaskFact

左外部結合

ServiceRequestFact

AllTaskFact

左外部結合

AllTaskFact

TaskEffortEntryFact

左外部結合

DeliveryTaskFact

TaskEffortEntryFact

左外部結合

ServiceTaskFact

TaskEffortEntryFact

左外部結合