この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この付録は、次の内容で構成されています。
ここでは、データ マートのさまざまなスキーマ設計について説明します。
データ マート スキーマは、IBM Cognos Framework Manager 用、IBM Cognos レポート ツール(Query Studio および Report Studio。それぞれ Service Catalog Advanced Reporting モジュールでは Ad-Hoc Reports、Report Designer として表示されます)で使用するビジネス ビュー用に設計されています。 したがって、データ マートに関する章では、クエリー サブジェクトの内容と関係について概説していますが、レポートのユーザまたは設計者には公開されない基礎となるデータ モデルについては取り上げていません。
この章は、Cognos ツールで公開されているビジネス ビューの基礎となる物理データ モデルを調査する技術担当者を対象にしています。 特に、次の図に示されているデータベース オブジェクトの名前をクエリー サブジェクトの対応する名前にマッピングする際の参考にしてください。 以下に示す図の内容は、次のとおりです。
上記の図は不完全です。 すべてのファクト テーブルは、実際にはディクショナリベースおよびサービスベースのディメンション テーブルに対して 1 対多の関係になっています。 グリッド ディクショナリが含まれていないサービスの場合、関係は常に 1 対 1 になります(詳細については、DM_FDR_SERVICETABLE_n XREF を参照してください)。 これらの関係は [REQUISITIONENTRYID] 列を介して実装され、すべてのファクトおよびディメンション テーブルに存在しますが、ビジネス ビューのディメンションには表示されません。
接続されているサービスおよびタスク ファクト テーブルとともに Query Studio または Report Designer を使用してレポートを作成する際は、これらのテーブル間の 1 対多の関係が原因で、タスク データが反復されて表示される場合があります。 レポート作成ツールのグループ化機能を使用して、同一の情報を折りたたむことができます。
[ディクショナリ(Dictionaries)] フォルダおよび [サービス(Services)] フォルダの下のデータ マートに表示されるディクショナリベースおよびサービスベースのクエリー サブジェクトは、それぞれ DM_FDR_DICTIONARYTABLE_n および DM_FDR_SERVICETABLE_n という名前の物理データベース内のテーブルに対応しています。ここで、
物理テーブルとレポート可能なオブジェクトとの間のマッピングは、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 データベース内のテーブルを次の表に示します。
データ マートのクエリー サブジェクト |
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 |
データ マート ETL プロセスは、データ マート データベース内のテーブルのセットを使用して、Ad-Hoc Reports および Report Designer オプションでユーザに公開される ServiceData および DictionaryData ディメンションを設定します。 これらのテーブルは、カスタム レポート パッケージがインストールされるときに作成され、データがデータ マートにロードされたときに入力されます。
これらのメタデータ テーブルは、Cognos フレームワークでは公開されません。 これらのテーブルの内容は、カスタム レポート プロジェクト内のデータのビジネス ビューとして表示される、動的に定義されるディクショナリ ベースおよびサービス ベースのディメンションを指定するために使用します。
以下に、これらのテーブルについて説明します。 各列の説明には抽象化されたデータ タイプを使用します。実際のデータ タイプは、データ マートが置かれたデータベース(Oracle または SQLServer)によって異なります。
DM_FDR_ETLDICTIONARYMETADATA テーブルは、特定のレポート可能ディクショナリ(DictionaryID で識別)を、ディクショナリ データが格納される DM_FDR_DICTIONARY_n テーブル(DictionaryTableName)にマッピングします。 また、ディクショナリ内および対応するデータ マート テーブル内で使用されている日付型、数値型、Varchar 型のフィールドの数を追跡します。
列名 |
データ タイプ |
説明 |
---|---|---|
DictionaryID |
整数(Integer) |
ディクショナリの固有識別子。 |
DictionaryTableName |
Varchar(50) |
ディクショナリ データが格納されるデータ マート テーブルの名前。 |
LastDictionaryDateField |
整数(Integer) |
ディクショナリ テーブル内で使用された最後の日時型フィールド。 |
LastDictionaryNumericField |
整数(Integer) |
ディクショナリ テーブル内で使用された最後の数値型フィールド。 |
LastDictionaryVarcharField |
整数(Integer) |
ディクショナリ テーブル内で使用された最後の文字型フィールド。 |
DM_FDR_DICTIONARYMETADATA テーブルは、個別のディクショナリ フィールド(属性)(DictionaryID および DictionaryAttributeName で識別)と、ディクショナリ テーブルの特定の列とをマッピングします。 たとえば、ディクショナリ RC_REQUESTEDBY の属性「LastName」を、データ マート テーブル DM_FDR_DICTIONARYTABLE_10, のフィールド「Field2」にマッピングする(実際には、格納する)ことができます。
列名 |
データ タイプ |
説明 |
---|---|---|
DestinationColumnName |
Varchar(100) |
この属性が格納される、テーブルの列名 |
DestinationTableName |
Varchar(200) |
ディクショナリ情報が格納されるテーブルの名前 |
DictionaryAttributeName |
Varchar(100) |
ディクショナリ内の属性の名前 |
DictionaryAttributeType |
Varchar(100) |
ディクショナリ内の属性のデータ タイプ |
DictionaryID |
整数(Integer) |
ディクショナリ ID |
DictionaryName |
Varchar(200) |
ディクショナリ名 |
DictionaryAttributeID |
整数(Integer) |
ディクショナリ属性 ID |
DM_FDR_ETLMETADATA テーブルには、Reporting オプションのインストール時に指定されたカスタム レポート パッケージの設定についての情報と、データ抽出プロセス(ETL)および ETL プロセスのスケジュール実行用の最終更新情報が保持されます。
列名 |
データ タイプ |
説明 |
---|---|---|
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 テーブルは、レポート可能な各サービスに関する情報を格納するために使用するテーブルの情報を保持します。
列名 |
データ タイプ |
説明 |
---|---|---|
LastServiceDateField |
整数(Integer) |
サービス テーブル内で使用された最後の日付時刻型フィールド。 |
LastServiceNumericField |
整数(Integer) |
サービス テーブル内で使用された最後の数値型フィールド。 |
LastServiceVarcharField |
整数(Integer) |
サービス テーブル内で使用された最後の文字型フィールド。 |
ServiceID |
整数(Integer) |
サービスに割り当てられた固有識別子。 |
ServiceTableName |
Varchar |
サービス データが格納されるデータ マート データベース テーブルの名前。 |
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」が付加された名前になります。 各テーブルには、1 から順に番号が付けられます。 このテーブルの各インスタンスが、レポート可能ディクショナリを表します。
DM_FDR_DICTIONARYTABLE は、レポーティング ツールでは [ディクショナリ データ(DictionaryData)] フォルダ内のディメンションのセットとして表示されます。 各ディメンションの名前は、対応するディクショナリのキャプションです。 (キャプションのないディクショナリでは、ディクショナリの名前が使用されます)。ディメンションの属性は、ディクショナリを構成するフィールドです。 フィールドには、1 から順に番号が付けられます。 データ タイプ(文字、数値、日時)ごとのフィールド数は、アプリケーション インストール手順で指定します。
列名 |
データ タイプ |
説明 |
---|---|---|
DictionaryID |
整数(Integer) |
ディクショナリ ID |
RequisitionID |
整数(Integer) |
申請 ID |
RequisitionEntryID |
整数(Integer) |
申請エントリ ID |
Field1 ~ Fieldn |
Varchar(200) |
ディクショナリ データを保持する Varchar フィールド |
Fieldn+1 ~ n+m |
Numeric |
ディクショナリ データを保持する数値型フィールド |
Fieldn+m+1 ~ |
日時(Datetime) |
ディクショナリ データを保持する日時型フィールド |
レポート可能として指定された各サービスのデータをキャプチャする、一連のテーブルです。 このテーブルは、サービスで使用されるすべてのディクショナリ内のフィールドすべてを含みます。 これらのテーブルの数、およびデータ タイプ(文字、数値、日時)ごとの列数は、アプリケーション インストールの一部として設定可能です。 各テーブルには、1 から順に番号が付けられます。
各テーブルは、DM_FDR_SERVICETABLE(またはインストール手順で指定された別のパターン)に数値サフィックス「_n」が付加された名前になります。 このテーブルの各インスタンスが、レポート可能サービスを表します。
DM_FDR_SERVICETABLE は、レポート作成ツールでは [サービスデータ(ServiceData)] フォルダ内のディメンションのセットとして表示されます。 各ディメンションの名前は、対応するサービスの名前です。 ディメンションの属性は、サービス内のディクショナリすべてを構成するフィールドです。 フィールドは、サービス内でディクショナリが出現する順でこのテーブルに追加されます。 各テーブルに収容できるフィールドの数は限られているため(インストール プロシージャで指定されますが、データベース制約によって物理的に制限されます)、サービス テーブルは不完全な場合があり、一部のフィールド、実際には一部のディクショナリが切り捨てられている場合があります。 このため、DM_FDR_SERVICETABLE の扱いには注意が必要です。特に、大量のフィールドを持つディクショナリがレポート可能として指定されている場合や、同一サービス内で多数のディクショナリが使用されている場合には注意が必要です。
列名 |
データ タイプ |
説明 |
---|---|---|
ServiceID |
整数(Integer) |
サービス ID(Service ID) |
RequisitionID |
整数(Integer) |
申請 ID |
RequisitionEntryID |
整数(Integer) |
申請エントリ ID |
Field1 ~ Fieldn |
Varchar(200) |
サービス データを保持する Varchar フィールド |
Fieldn+1 ~ n+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 ディクショナリ内のいくらかのデータを持つと仮定します。 このサービスに対してサービス テーブル内にキャプチャされたフォーム データは、次のようになります。
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 データ マートに使用され、カスタム レポート パッケージによってユーザに公開されるデータベース テーブルとビューの一覧を示します。 テーブルやビューは、対応するクエリー サブジェクトに直接マッピングされます。
データ マート テーブル/ビュー |
プライマリ キー |
クエリー サブジェクト/説明 |
---|---|---|
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 |
対応するサービス フォーム データ属性情報 |
データ マートを構成するテーブルには、複数のクエリー サブジェクトからデータを取得するクエリーやレポートのパフォーマンスを最適化するためにインデックスが付けられています。 ディクショナリ ベースとサービス ベースのディメンションは動的であるため、これらのテーブルにはインデックスが追加されません。
静的に定義されたファクトおよびディメンション テーブルに提供されるインデックスの概要を次に示します。
データ マート テーブル/ビュー |
プライマリ キー |
追加インデックス |
---|---|---|
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 つを組み合わせ、いずれかのエンティティでグループ化できます。 たとえば、すべての組織についてメンバーをリストするレポートを作成できます。また、特定の人員を選択して、その人員が所属する組織をすべてリストすることも可能です。
ファクト 1 |
ファクト 2 |
関係の種類 |
---|---|---|
ServiceRequestFact |
ServiceTaskFact |
左外部結合 |
ServiceRequestFact |
DeliveryTaskFact |
内部結合 |
ServiceRequestFact |
AuthTaskFact |
左外部結合 |
ServiceRequestFact |
AllTaskFact |
左外部結合 |
AllTaskFact |
TaskEffortEntryFact |
左外部結合 |
DeliveryTaskFact |
TaskEffortEntryFact |
左外部結合 |
ServiceTaskFact |
TaskEffortEntryFact |
左外部結合 |
目次
この付録は、次の内容で構成されています。
ここでは、データ マートのさまざまなスキーマ設計について説明します。
データ マート スキーマは、IBM Cognos Framework Manager 用、IBM Cognos レポート ツール(Query Studio および Report Studio。それぞれ Service Catalog Advanced Reporting モジュールでは Ad-Hoc Reports、Report Designer として表示されます)で使用するビジネス ビュー用に設計されています。 したがって、データ マートに関する章では、クエリー サブジェクトの内容と関係について概説していますが、レポートのユーザまたは設計者には公開されない基礎となるデータ モデルについては取り上げていません。
この章は、Cognos ツールで公開されているビジネス ビューの基礎となる物理データ モデルを調査する技術担当者を対象にしています。 特に、次の図に示されているデータベース オブジェクトの名前をクエリー サブジェクトの対応する名前にマッピングする際の参考にしてください。 以下に示す図の内容は、次のとおりです。
上記の図は不完全です。 すべてのファクト テーブルは、実際にはディクショナリベースおよびサービスベースのディメンション テーブルに対して 1 対多の関係になっています。 グリッド ディクショナリが含まれていないサービスの場合、関係は常に 1 対 1 になります(詳細については、DM_FDR_SERVICETABLE_n XREF を参照してください)。 これらの関係は [REQUISITIONENTRYID] 列を介して実装され、すべてのファクトおよびディメンション テーブルに存在しますが、ビジネス ビューのディメンションには表示されません。
接続されているサービスおよびタスク ファクト テーブルとともに Query Studio または Report Designer を使用してレポートを作成する際は、これらのテーブル間の 1 対多の関係が原因で、タスク データが反復されて表示される場合があります。 レポート作成ツールのグループ化機能を使用して、同一の情報を折りたたむことができます。
[ディクショナリ(Dictionaries)] フォルダおよび [サービス(Services)] フォルダの下のデータ マートに表示されるディクショナリベースおよびサービスベースのクエリー サブジェクトは、それぞれ DM_FDR_DICTIONARYTABLE_n および DM_FDR_SERVICETABLE_n という名前の物理データベース内のテーブルに対応しています。ここで、
物理テーブルとレポート可能なオブジェクトとの間のマッピングは、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 データベース内のテーブルを次の表に示します。
データ マートのクエリー サブジェクト |
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 |
データ マート ETL プロセスは、データ マート データベース内のテーブルのセットを使用して、Ad-Hoc Reports および Report Designer オプションでユーザに公開される ServiceData および DictionaryData ディメンションを設定します。 これらのテーブルは、カスタム レポート パッケージがインストールされるときに作成され、データがデータ マートにロードされたときに入力されます。
これらのメタデータ テーブルは、Cognos フレームワークでは公開されません。 これらのテーブルの内容は、カスタム レポート プロジェクト内のデータのビジネス ビューとして表示される、動的に定義されるディクショナリ ベースおよびサービス ベースのディメンションを指定するために使用します。
以下に、これらのテーブルについて説明します。 各列の説明には抽象化されたデータ タイプを使用します。実際のデータ タイプは、データ マートが置かれたデータベース(Oracle または SQLServer)によって異なります。
DM_FDR_ETLDICTIONARYMETADATA テーブルは、特定のレポート可能ディクショナリ(DictionaryID で識別)を、ディクショナリ データが格納される DM_FDR_DICTIONARY_n テーブル(DictionaryTableName)にマッピングします。 また、ディクショナリ内および対応するデータ マート テーブル内で使用されている日付型、数値型、Varchar 型のフィールドの数を追跡します。
列名 |
データ タイプ |
説明 |
---|---|---|
DictionaryID |
整数(Integer) |
ディクショナリの固有識別子。 |
DictionaryTableName |
Varchar(50) |
ディクショナリ データが格納されるデータ マート テーブルの名前。 |
LastDictionaryDateField |
整数(Integer) |
ディクショナリ テーブル内で使用された最後の日時型フィールド。 |
LastDictionaryNumericField |
整数(Integer) |
ディクショナリ テーブル内で使用された最後の数値型フィールド。 |
LastDictionaryVarcharField |
整数(Integer) |
ディクショナリ テーブル内で使用された最後の文字型フィールド。 |
DM_FDR_DICTIONARYMETADATA テーブルは、個別のディクショナリ フィールド(属性)(DictionaryID および DictionaryAttributeName で識別)と、ディクショナリ テーブルの特定の列とをマッピングします。 たとえば、ディクショナリ RC_REQUESTEDBY の属性「LastName」を、データ マート テーブル DM_FDR_DICTIONARYTABLE_10, のフィールド「Field2」にマッピングする(実際には、格納する)ことができます。
列名 |
データ タイプ |
説明 |
---|---|---|
DestinationColumnName |
Varchar(100) |
この属性が格納される、テーブルの列名 |
DestinationTableName |
Varchar(200) |
ディクショナリ情報が格納されるテーブルの名前 |
DictionaryAttributeName |
Varchar(100) |
ディクショナリ内の属性の名前 |
DictionaryAttributeType |
Varchar(100) |
ディクショナリ内の属性のデータ タイプ |
DictionaryID |
整数(Integer) |
ディクショナリ ID |
DictionaryName |
Varchar(200) |
ディクショナリ名 |
DictionaryAttributeID |
整数(Integer) |
ディクショナリ属性 ID |
DM_FDR_ETLMETADATA テーブルには、Reporting オプションのインストール時に指定されたカスタム レポート パッケージの設定についての情報と、データ抽出プロセス(ETL)および ETL プロセスのスケジュール実行用の最終更新情報が保持されます。
列名 |
データ タイプ |
説明 |
---|---|---|
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 テーブルは、レポート可能な各サービスに関する情報を格納するために使用するテーブルの情報を保持します。
列名 |
データ タイプ |
説明 |
---|---|---|
LastServiceDateField |
整数(Integer) |
サービス テーブル内で使用された最後の日付時刻型フィールド。 |
LastServiceNumericField |
整数(Integer) |
サービス テーブル内で使用された最後の数値型フィールド。 |
LastServiceVarcharField |
整数(Integer) |
サービス テーブル内で使用された最後の文字型フィールド。 |
ServiceID |
整数(Integer) |
サービスに割り当てられた固有識別子。 |
ServiceTableName |
Varchar |
サービス データが格納されるデータ マート データベース テーブルの名前。 |
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」が付加された名前になります。 各テーブルには、1 から順に番号が付けられます。 このテーブルの各インスタンスが、レポート可能ディクショナリを表します。
DM_FDR_DICTIONARYTABLE は、レポーティング ツールでは [ディクショナリ データ(DictionaryData)] フォルダ内のディメンションのセットとして表示されます。 各ディメンションの名前は、対応するディクショナリのキャプションです。 (キャプションのないディクショナリでは、ディクショナリの名前が使用されます)。ディメンションの属性は、ディクショナリを構成するフィールドです。 フィールドには、1 から順に番号が付けられます。 データ タイプ(文字、数値、日時)ごとのフィールド数は、アプリケーション インストール手順で指定します。
列名 |
データ タイプ |
説明 |
---|---|---|
DictionaryID |
整数(Integer) |
ディクショナリ ID |
RequisitionID |
整数(Integer) |
申請 ID |
RequisitionEntryID |
整数(Integer) |
申請エントリ ID |
Field1 ~ Fieldn |
Varchar(200) |
ディクショナリ データを保持する Varchar フィールド |
Fieldn+1 ~ n+m |
Numeric |
ディクショナリ データを保持する数値型フィールド |
Fieldn+m+1 ~ |
日時(Datetime) |
ディクショナリ データを保持する日時型フィールド |
レポート可能として指定された各サービスのデータをキャプチャする、一連のテーブルです。 このテーブルは、サービスで使用されるすべてのディクショナリ内のフィールドすべてを含みます。 これらのテーブルの数、およびデータ タイプ(文字、数値、日時)ごとの列数は、アプリケーション インストールの一部として設定可能です。 各テーブルには、1 から順に番号が付けられます。
各テーブルは、DM_FDR_SERVICETABLE(またはインストール手順で指定された別のパターン)に数値サフィックス「_n」が付加された名前になります。 このテーブルの各インスタンスが、レポート可能サービスを表します。
DM_FDR_SERVICETABLE は、レポート作成ツールでは [サービスデータ(ServiceData)] フォルダ内のディメンションのセットとして表示されます。 各ディメンションの名前は、対応するサービスの名前です。 ディメンションの属性は、サービス内のディクショナリすべてを構成するフィールドです。 フィールドは、サービス内でディクショナリが出現する順でこのテーブルに追加されます。 各テーブルに収容できるフィールドの数は限られているため(インストール プロシージャで指定されますが、データベース制約によって物理的に制限されます)、サービス テーブルは不完全な場合があり、一部のフィールド、実際には一部のディクショナリが切り捨てられている場合があります。 このため、DM_FDR_SERVICETABLE の扱いには注意が必要です。特に、大量のフィールドを持つディクショナリがレポート可能として指定されている場合や、同一サービス内で多数のディクショナリが使用されている場合には注意が必要です。
列名 |
データ タイプ |
説明 |
---|---|---|
ServiceID |
整数(Integer) |
サービス ID(Service ID) |
RequisitionID |
整数(Integer) |
申請 ID |
RequisitionEntryID |
整数(Integer) |
申請エントリ ID |
Field1 ~ Fieldn |
Varchar(200) |
サービス データを保持する Varchar フィールド |
Fieldn+1 ~ n+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 ディクショナリ内のいくらかのデータを持つと仮定します。 このサービスに対してサービス テーブル内にキャプチャされたフォーム データは、次のようになります。
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 データ マートに使用され、カスタム レポート パッケージによってユーザに公開されるデータベース テーブルとビューの一覧を示します。 テーブルやビューは、対応するクエリー サブジェクトに直接マッピングされます。
データ マート テーブル/ビュー |
プライマリ キー |
クエリー サブジェクト/説明 |
---|---|---|
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 |
対応するサービス フォーム データ属性情報 |
データ マートを構成するテーブルには、複数のクエリー サブジェクトからデータを取得するクエリーやレポートのパフォーマンスを最適化するためにインデックスが付けられています。 ディクショナリ ベースとサービス ベースのディメンションは動的であるため、これらのテーブルにはインデックスが追加されません。
静的に定義されたファクトおよびディメンション テーブルに提供されるインデックスの概要を次に示します。
データ マート テーブル/ビュー |
プライマリ キー |
追加インデックス |
---|---|---|
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 つを組み合わせ、いずれかのエンティティでグループ化できます。 たとえば、すべての組織についてメンバーをリストするレポートを作成できます。また、特定の人員を選択して、その人員が所属する組織をすべてリストすることも可能です。
ファクト 1 |
ファクト 2 |
関係の種類 |
---|---|---|
ServiceRequestFact |
ServiceTaskFact |
左外部結合 |
ServiceRequestFact |
DeliveryTaskFact |
内部結合 |
ServiceRequestFact |
AuthTaskFact |
左外部結合 |
ServiceRequestFact |
AllTaskFact |
左外部結合 |
AllTaskFact |
TaskEffortEntryFact |
左外部結合 |
DeliveryTaskFact |
TaskEffortEntryFact |
左外部結合 |
ServiceTaskFact |
TaskEffortEntryFact |
左外部結合 |