部署 Service Manager 数据仓库并查看其报表后，可以自定义报表中的信息，以更好地适合组织。 例如，你可能想要使用 Service Manager 重新创建过去用于其他信息系统的报表。 或者，你可以为事件管理或变更管理的内部业务流程自定义报表。
本节中的信息有助于你确定如何扩展和自定义数据仓库以便能够进行深入分析。
使用星型架构进行数据仓库维度建模
Service Manager 中的数据仓库是一组数据库和进程。 进程会将信息自动添加到数据库。 简而言之，数据仓库旨在将信息添加到数据市场，在数据市场中，你和其他用户可以运行报表并执行分析以便于管理业务。 Service Manager 将数据仓库数据存储在仓库中的时间比 Service Manager 数据库中更长，因为数据在趋势和分析方面的有用性。 此外，数据仓库数据存在的时间通常比用于满足普通事务处理需求所需的时间更长。
针对以多种似乎无法预测的方式一次性聚合和分析大量数据，数据仓库已经过优化。 这种行为与事务处理系统有所不同，事务处理系统针对在任何特定事务中对少量记录进行写访问权限的优化，使这些事务的行为更加可预测。
为了优化数据仓库的性能和易用性，Service Manager 使用 Kimball 方法进行维度建模。 （有关 Kimball 方法的详细信息，请参阅 维度建模。）这意味着，DWDataMart 数据库中的表在图表中布局时按逻辑分组为类似于星形的主题区域。 因此，这些组通常称为星型架构，它们包括下列各项：
- 位于星中央的事实数据表。 事实数据表表示关系、度量值和关键性能指标 (KPI)。 事实数据表通常较长，列相对较少，但包含大量交易。
- 事实数据表连接到表示类、属性和枚举的维度表。 维度表所包含的行数通常比事实数据表少得多，但它们更宽，因为它们具有报表用户用来多维分析报表的属性。 这些属性可以包括类的状态、分类和日期属性（例如创建日期或解决日期）。
- 子维度是出于性能和可用性原因而悬挂在其他维度表上的特殊维度表。
当你考虑星型架构时，设想适合咖啡店的星型架构会是怎样。 如果交易表示咖啡购买，则维度可能包括下列各项：
- 日期维度，它用于按公历和会计日历整合事务
- 客户维度，它指示谁买了咖啡
- 员工维度，它指示谁泡咖啡
- 产品维度，它指示咖啡类型，例如浓咖啡、滴滤咖啡、拿铁或布雷卫咖啡。
- 存储维度
在你考虑事实数据表可能包括的度量值时，列表可能包括下列各项：
- 销售量
- 单价
- 总销售额
- 总折扣
设计维度模型时，信息技术（IT）流程与咖啡店示例不同。 发生的一些事务（例如事件的创建、解决和关闭）可以生成一些有趣且有用的指标，例如解决时间、遵循解决目标的情况、分析人员产生的计费时间以及状态中的持续时间。
当你考虑扩展和自定义数据仓库时，请考虑你要回答的业务问题，并调查维度建模以获得有用的信息和最佳方案。 有关自定义数据仓库的详细信息，请参阅本文中的其他部分。
数据仓库中的事实数据表
本部分介绍如何在 Service Manager 的数据仓库中定义关系事实。 Service Manager 数据仓库中的关系事实类似于 Service Manager 中的关系。 关系事实可用来帮助回答查询，例如下列查询：
- 当前哪些工作项分配给了用户 John Smith，以便你确定其状态？
- 当前安装了 Windows 10 的所有计算机的列表是什么，以便你可以将其更新到最新版本？
- 将 Samantha Smith 列为审阅者的所有审阅活动有哪些，以便在其因休假而不在时能够重新分配这些活动？
在上述每个方案中，都有一个源实例和一个目标实例，这些实例由关系联接在一起。 如果没有关系事实，很难确定实例之间的关联。 在下列示例中考虑 Microsoft.Windows.Library 管理包的 Microsoft.Windows.ComputerHostsOperatingSystem 中的关系：
<RelationshipType ID="Microsoft.Windows.ComputerHostsOperatingSystem" Accessibility="Public" Base="System!System.Hosting">
<Source ID="Computer" Type="Microsoft.Windows.Computer" />
<Target ID="OperatingSystem" Type="Microsoft.Windows.OperatingSystem" MaxCardinality="1" />
</RelationshipType>
在 Service Manager 关系中，源和目标始终由管理包类建模。 在此关系中，Microsoft.Windows.Computer 为源类，Microsoft.Windows.OperatingSystem 为目标类。 下列信息根据 Microsoft.Windows.ComputerHostsOperatingSystem 关系定义相应的关系事实：
<RelationshipFact ID="ComputerHostsOperatingSystemFact" Accessibility="Public" Domain="Domain.ConfigurationManagement" TimeGrain="Daily" SourceType="Windows!Microsoft.Windows.Computer" SourceDimension="ComputerDim">
<Relationships RelationshipType="Windows!Microsoft.Windows.ComputerHostsOperatingSystem" TargetDimension="OperatingSystemDim" />
</RelationshipFact>
注意关系事实定义源维度和目标维度的方式。 你可能会注意到，源维度和目标维度将构建关系事实所依据的原始关系中的源类和目标类设定为目标。
通过将两个维度关联在一起可使用关系事实，这样报表便可使用这一关联来显示每个维度中与另一个维度相关的重要信息。 例如，可以使用 WorkItemAssignedToUser 关系来显示事件的有关信息或更改报表中特定用户的请求。 这使你能够在数据中进行导航来找到特定于需求的信息。 这只是关系事实的一个示例，该示例介绍了在报表中创建专用数据视图时关系事实的有用性。
在下表中，包含了用于<RelationshipFact> 标签的用户定义管理包中关系事实建模所需的属性和子元素标记的描述。
| 属性 | 描述 |
|---|---|
| 身份证件 | 关系事实元素的唯一标识符。 这也是关系事实在数据仓库和数据市场中的表名。 |
| 辅助功能 | 由于部署流程创建的系统派生管理包在自动转换的生成过程中会引用此子维度，因此该元素应始终设置为“公共”。 |
| 域 | 关系事实的范围。 可能的值如下所示：实例管理/活动管理、事件管理/更改管理和问题管理。 此属性的值必须是 Microsoft.SystemCenter.Datawarehouse.Base 管理包中所定义的父域枚举值的一个子枚举值。 |
| TimeGrain | 关系事实的详细信息级别。 值必须为下列值之一：每小时、每天、每周或每月。 |
| 来源类型 | 关系的源的管理包类。 |
| SourceDimension | 将源类设定为目标的维度。 这是一个可选字段。 如果未指定 SourceDimension，Service Manager 会自动查找直接面向源类本身或类层次结构中源类最近的父类的维度。 |
在一个多重关系事实中，源维度始终不变。 但是，目标维度可以更改，具体取决于特定的关系。 多重关系事实中的每个关系类型属性都必须是唯一的。 下面是“WorkItemAssignedToAndCreatedByUser”管理包中一个关系事实示例：
<RelationshipFact ID="WorkItemAssignedToAndCreatedUserFact" Accessibility="Public" Domain="Domain.InstanceManagement" TimeGrain="Daily" SourceType="WorkItem!System.WorkItem" SourceDimension="WorkItemDim">
<Relationships RelationshipType="WorkItem!System.WorkItemAssignedToUser" TargetDimension="UserDim" />
<Relationships RelationshipType="WorkItem!System.WorkItemCreatedByUser" TargetDimension="UserDim" />
</RelationshipFact>
在本例中，你会看到尽管两种关系的目标维度相同，但关系本身是唯一的。 因此，关系事实有效。 有关子维度、维度和关系事实的更多示例，你可以检查 Service Manager 中包含的任何数据仓库管理包。 名为 Microsoft.SystemCenter.Datawarehouse.Base 的基本数据仓库管理包就是一个很好的示例。
数据仓库中的子维度
Service Manager 数据仓库中的子维度本质上是一个可以在逻辑上将一组值分组的列表。 下列表格展示两个示例，这些示例展示用于指示优先级和 Windows 操作系统的值的逻辑分组。
| 优先级 |
|---|
| 低 |
| 中等 |
| 高 |
| Windows 操作系统 |
|---|
| Windows 7 |
| Windows 8操作系统 |
| Windows 10 |
舷外支架有两种用途：
- 在 Service Manager 控制台中创建和查看报表时，可以使用来自扩展装置的离散值作为报表参数的下拉选项。
- 你可使用子维度值将数据在报表中分组以进行高级分析。
数据仓库中的支架可以针对一个或多个类属性，并将它们统一整合为一组离散值。 这些属性只能是字符串或 ManagementPackEnumeration 数据类型。 当基于枚举时，子维度还会保留层次结构。 Service Manager 不支持在 String 或 ManagementPackEnumeration 以外的数据类型上定义的子维度。
虽然定义枚举子维度的好处较为明显，但将子维度定义在字符串列上也有一个优势，即数据仓库基础设施能够将实例空间中属性的不同值合并成一个小列表。 然后，你可以在报表中以易用的下拉列表形式使用该清单。 例如，基于字符串的子维度有 Manufacturer Computer 类的 属性，它作为 Service Manager 数据库中的字符串建模。 通过定义该属性的子维度，Service Manager 将使你能够从下拉列表中选择值，而非让你在所采购的计算机的制造商中搜索。
要查看子维度在参数标题的报表中如何使用的示例，请打开 Service Manager 控制台；导航到“报表，活动管理”；然后运行“活动分布”报表。 接下来，审阅“状态” 列表以查看子维度的值。 在下列示例中，你可以看到如何在管理包中对外伸支架进行建模。 请注意 System.WorkItem.Activity类，它在 System.Workitem.Activity.Library 管理包中定义：
<ClassType ID="System.WorkItem.Activity" Accessibility="Public" Base="WorkItem!System.WorkItem" Hosted="false" Abstract="true">
< Property ID="SequenceId" Type="int" />
<Property ID="Notes" Type="richtext" MaxLength="4000" />
<Property ID="Status" Type="enum" EnumType="ActivityStatusEnum" />
<Property ID="Priority" Type="enum" EnumType="ActivityPriorityEnum" />
<Property ID="Area" Type="enum" EnumType="ActivityAreaEnum" />
<Property ID="Stage" Type="enum" EnumType="ActivityStageEnum" />
</ClassType>
接着，建议你定义基于枚举属性 Status的子维度。 以下示例展示了如何在自选的管理包中定义一个桁架：
<Outrigger ID="ActivityStatus" Accessibility="Public">
<Attribute ID="Status" PropertyPath="$Context/Property[Type='CoreActivity!System.WorkItem.Activity']/Status$" />
</Outrigger>
如前所述，作为管理包作者，你可以在一个或多个类属性上定义子维度。 每个类属性均按子维度中相应的特性建模。 基于枚举的子维度的可视化示例如下。 在此示例中，活动状态基于 ActivityStatusEnum：
<EnumerationTypes>
<EnumerationValue ID="ActivityStatusEnum" Accessibility="Public" />
<EnumerationValue ID="ActivityStatusEnum.Ready" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="5.0" />
<EnumerationValue ID="ActivityStatusEnum.Active" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="10.0" />
<EnumerationValue ID="ActivityStatusEnum.OnHold" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="15.0" />
<EnumerationValue ID="ActivityStatusEnum.Completed" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="20.0" />
<EnumerationValue ID="ActivityStatusEnum.Failed" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="25.0" />
<EnumerationValue ID="ActivityStatusEnum.Cancelled" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="30.0" />
<EnumerationValue ID="ActivityStatusEnum.Rerun" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="35.0" />
...
</EnumerationTypes>
每个值都包含在子维度的离散值集中。 下表列出了来自 ActivityStatus 子维度的列 ID 和 ActivityStatusValue，其中包含 ActivityStatusEnum 的所有枚举值。
| 身份证件 | ActivityStatusValue |
|---|---|
| ActivityStatusEnum.Completed | 已完成 |
| ActivityStatusEnum | 活动状态 |
| ActivityStatusEnum.Active | 正在进行 |
| ActivityStatusEnum.OnHold | 暂停 |
| ActivityStatusEnum.Rerun | 重播 |
| ActivityStatusEnum.Failed | 已失败 |
| ActivityStatusEnum.Ready | 挂起 |
| ActivityStatusEnum.Cancelled | 已取消 |
在上一个表中，子维度的 ID 列包含 ActivityStatus 枚举类型的所有 EnumerationValue ID。 ActivityStatusValue 是在报表下拉菜单中出现的用户友好的实际显示名称。
下列示例提供了关于如何构建和建模桁架的更多详细信息。 再次使用 outrigger ActivityStatus 作为示例：
<Outrigger ID="ActivityStatus" Accessibility="Public">
<Attribute ID="Status" PropertyPath="$Context/Property[Type='CoreActivity!System.WorkItem.Activity']/Status$" />
</Outrigger>
下表描述了标记的属性 <Outrigger> 。
| 属性 | 描述 |
|---|---|
| 身份证件 | 子维度元素的唯一标识符。 这也是子维度在数据仓库和数据市场中的表名。 |
| 辅助功能 | 该元素应始终设置为“公共”。 |
每个 <Outrigger> 父标记都包含一个或多个 <Attribute> 子元素标记。 下表描述此标记的属性。
| 属性 | 描述 |
|---|---|
| 身份证件 | 每个子维度属性的唯一标识符 |
| PropertyPath | PropertyPath 语法必须唯一标识制导属性所指向的类和属性。 |
数据仓库中的维度
Service Manager 数据仓库中的维度大致类似于管理包类。 每个管理类都具有一个属性列表，而每个维度都包含一个特性列表。 每个维度特性都对应于类中的一个属性。
假设用户希望 Service Manager 中的某一报表显示特定域中计算机的属性的一些有关信息。 例如，用户可能想要知道每台计算机的 IP 地址、逻辑处理器的个数和域名系统 (DNS) 名称。 使用维度，用户可将数据从 Service Manager 带到数据仓库，在这里报表可查询并显示每台计算机的这些数据。
在 Service Manager 数据仓库中，一个维度始终以单个类为目标。 然后，维度属性映射到目标类的属性。 在此示例中，若要从计算机获取有关属性的信息，有一个以 Microsoft.Windows.Computers 类为目标的计算机维度。
在本文中进一步详细介绍的某些情况下，维度也可能映射到目标类的基类和派生类的属性。 因此，虽然维度可能大致类似于管理包类，但它也可以包含该管理包类层次结构中的属性。
你可以查看“活动分发”报表中维度的使用示例。 在报告中，在选择受影响的配置项（可选）下，选择添加时，选择维度对象框会打开，您可以在 ConfigItemDim 维度中搜索维度实例。 你可以对“显示名称” 属性进行筛选。 选择“所有 Windows 计算机” 作为维度对象时，系统会用所选的筛选值更新报表页眉。 运行报表时，仅显示影响所选配置项目“所有 Windows 计算机” 的活动。
若要查看维度的建模方式，你可以查看在 System.Library 管理包中定义的 System.Entity 和 System.ConfigItem 类：
<ClassType ID="System.Entity" Accessibility="Public" Hosted="false" Abstract="true" Singleton="false">
<Property ID="DisplayName" Type="string" MinLength="0" Key="false" CaseSensitive="false" MaxLength="4000" />
</ClassType>
<ClassType ID="System.ConfigItem" Base="System.Entity" Accessibility="Public" Hosted="false" Abstract="true">
<Property ID="ObjectStatus" Type="enum" EnumType="System.ConfigItem.ObjectStatusEnum" DefaultValue="System.ConfigItem.ObjectStatusEnum.Active" />
<Property ID="AssetStatus" Type="enum" EnumType="System.ConfigItem.AssetStatusEnum" />
<Property ID="Notes" Type="richtext" MaxLength="4000" />
</ClassType>
若要修改配置项目维度以将 System.ConfigItem 的 ObjectStatus 和 AssetStatus 属性和基类 System.Library 的 DisplayName 属性设定为目标，你可以将下列三个属性作为特性来定义维度：
<Dimension ID="ConfigItemDim" Accessibility="Public" Target="System!System.ConfigItem" InferredDimension="true" HierarchySupport="Exact" Reconcile="true">
<InclusionAttribute ID="DisplayName" PropertyPath="$Context/Property[Type='System!System.Entity']/DisplayName$" SlowlyChangingAttribute="false" />
<InclusionAttribute ID="ObjectStatus" PropertyPath="$Context/Property[Type='System!System.ConfigItem']/ObjectStatus$" SlowlyChangingAttribute="false" />
<InclusionAttribute ID="AssetStatus" PropertyPath="$Context/Property[Type='System!System.ConfigItem']/AssetStatus$" SlowlyChangingAttribute="false" />
</Dimension>
下表通过检查 <Dimension> 的 XML 架构元素和属性，提供了有关如何构造维度和对维度建模的详细信息。
| 属性 | 描述 |
|---|---|
| 身份证件 | 维度元素的唯一标识符。 这也是维度在数据仓库和数据市场中的表名。 |
| 辅助功能 | 此元素应始终设置为“Public”。 |
| 目标 | 维度要以之为目标的管理包类名。 |
| InferredDimension | 此值始终为 true。 |
| HierarchySupport | 用于帮助定义将包含在维度中的属性的类层次结构。 有三种可能的值： 1. 精确 2. IncludeExtendedClassProperties 3. IncludeDerivedClassProperties 有关这些值的详细信息，请参阅本文的下一部分。 |
| Extends | 可选的布尔型标志，用于指明该维度是基本维度还是要扩展其他维度。 定义维度后，可以使用 Service Manager 数据仓库“扩展”维度，并在以后的时间点添加更多属性。 如果 Extends 标志设置为 true，则 HierarchySupport 必须设置为 Exact，并且必须列出所有扩展属性。 默认情况下，此标志设置为 false。 |
| 调和 | 可选布尔标志，用于指示是否应将两个实例合并为一行数据，这些实例在其他方面相同，仅数据来源不同。 默认情况下，此标志设置为 false。 与配置项目相关的维度应将此标志设置为 true，而与工作项相关的维度应将此标志设置为 false。 |
HierarchySupport 属性可确定处理哪些类以及维度中包括哪些特定属性。 下列部分中将描述每个可能值的详细信息。
Exact
当 HierarchySupport 属性为 Exact 时，必须使用标记手动定义应包含在维度 <InclusionAttribute> 中的每个属性。 这些属性可以是来自目标类或任何目标类的基类和派生类。 每个包含特性对应于一个类属性。 下表描述了标记中的每个 <InclusionAttribute> 属性。
| 属性 | 描述 |
|---|---|
| 身份证件 | 属性元素的唯一标识符。 |
| PropertyPath | PropertyPath 语法必须唯一地标识维度属性所针对的类和属性。 |
| SlowlyChangingAttribute | 此属性应始终为 false。 |
前面的 ConfigItemDim 维度示例的 HierarchySupport 值为“Exact”。 因此，在转换过程中仅处理列出的被纳入的属性（DisplayName、ObjectStatus、AssetStatus），并且这些属性会被包括在数据仓库存储库和数据集市的维度表中。
HierarchySupport 的“Exact”值要求你手动列出维度中所需的每个属性。 不过，建议你将某个类的所有属性，以及其基类和派生类中的属性包括在维度中。 在这些情况下，明确列出每个属性需要很大的工作量。 为了提供帮助，Service Manager 包括了两个其他 HierarchySupport 值用以自动为你处理这些情况。 下列部分中将描述这些值。
IncludeExtendedClassProperties
对于 HierarchySupport 为 IncludeExtendedClassProperties 的维度，目标类及其所有基类的所有属性都包括在维度表和转换中。 下图显示了一个示例：CarDimension，以类“汽车”为目标并具有值为 IncludeExtendedClassProperties 的属性 HierarchySupport。
由于 CarDimension 以类“汽车”为目标并具有值为 IncludeExtendedClassProperties 的属性 HierarchySupport，因此它将处理类“汽车”及其基类“车辆”。 产生的表和转换包含下表中的属性。
| CarDimension 属性 |
|---|
| 颜色 |
| 制造商 |
| 型号 |
| NumDoors |
| NumCupHolders |
| 马力 |
| CargoSpace |
IncludeDerivedClassProperties
对于 HierarchySupport 为 IncludeExtendedClassProperties 的维度，目标类及其基类和派生类的所有属性都包括在维度表及其关联的转换中。
稍微修改前面的示例，CarDimension 现具有值为 IncludeDerivedClassProperties 的属性 HierarchySupport 如下。 因为它同时处理目标类的基类和派生类，因此维度现在处理三个类的属性：车辆、汽车和跑车，如下图所示。
CarDimension 维度表和转换包含下表中的属性。
| CarDimension 属性 |
|---|
| 颜色 |
| 制造商 |
| 型号 |
| NumDoors |
| NumCupHolders |
| 马力 |
| CargoSpace |
| TopSpeed |