统一维度模型

希望直接从诸如企业资源规划 (ERP) 数据库这样的数据源中检索信息的用户会面临几个重要挑战：

• 此类数据源的内容通常非常难于理解，因为它们的设计初衷是针对系统和开发人员，而不是用户。
• 用户所关心的信息通常分布在多个异类数据源中。即使只是使用其他关系数据库，用户也必须了解每个数据库的详细信息（例如，所用的 SQL 方言）。更糟糕的是，这些数据源的类型可能各不相同，不仅包括关系数据库，而且还包括文件和 Web 服务。
• 尽管许多数据源都倾向于包含大量事务级别的详细信息，但是，支持业务决策制订所需的查询经常涉及汇总信息和聚合信息。随着数据量的增加，最终用户为进行交互式分析而检索此类汇总值所需的时间也会过长。
• 业务规则通常并不封装在数据源中。用户需要自行理解数据。

统一维度模型 (UDM) 的作用是在用户和数据源之间搭建一座桥梁。UDM 构造于一个或多个物理数据源之上。用户使用多种客户端工具（例如，Microsoft Excel）向 UDM 发出查询。

即使 UDM 只是作为数据源上的瘦层来构造，对于最终用户而言也有益处：更简单、更容易理解的数据模型，与异构的后端数据源相隔离，并且汇总类型查询的性能也有所提高。在某些方案中，可以自动构造简单的 UDM。如果在构造 UDM 的过程中再增加一些投资，则可以从该模型提供的丰富元数据中获得其他收益。

UDM 具有下列优点：

• 极大地丰富了用户模型。
• 提供了支持交互式分析的高性能查询，即使是数据量非常大也不例外。
• 捕获模型中的业务规则，以支持更丰富的分析。
• 支持“关闭循环”：允许用户按照所看到的数据进行操作。

基本的最终用户模型

现在考虑一个示例，在该示例中，用户希望比较不同时间段的销售额和配额。

销售额数据存储在主数据库“销售额和库存”，其中包含许多其他的表。甚至在标识出了相关表之后，该用户也可能发现单个实体（例如，产品）的数据分散在很多表中。由于引用完整性由应用程序逻辑强制实施，因此没有定义这些表之间的关系。销售配额存储在另一个应用程序的数据库中。这两个数据库都不会捕获任何业务规则，例如以下事实：为比较配额和实际销售额，必须使用订单发货日期，而不能使用与订单有关的其他日期（订单日期、订单到期日期、计划日期等）。

直接访问数据源

首先考虑用户直接访问数据源的情况。下图显示了一个使用示例工具构造的查询示例。

到目前为止，用户已经完成了大量的工作。其中包括：

• 从大量名称隐晦的表中筛查出所需的表。
• 确定了应将哪些列用于联接表。
• 从很多包含大量针对系统的详细信息的表中，选择那些包含所需详细信息的列。例如，在存储了有关产品类别的详细信息的表中的 11 个列中，只有两个名称列与用户实际相关。

现在用户专注于定义应当在哪里使用“外部”联接与“内部”联接，以及如何对详细信息进行分组以提供所需的聚合。

然而，用户还要面对更艰巨的任务。例如，用户如何联接来自其他数据源的数据？即使其中的一个数据库支持分布式查询，大多数用户仍然无法构造所需查询，而且在此任务中工具可能无法向用户提供足够的支持。代码示例显示了一个查询外部数据的方法。

SELECT Quotas.QuotaAmount, Quotas.EmployeeId, ?FROM OPENROWSET('SQLOLEDB','seattle1';
'Sales';'MyPass',
   'SELECT * FROM Forecasts.dbo.SalesQuota?) As Quotas

如果使用其他数据源（如 Web 服务），则在确定如何执行正确的远程调用，然后又如何处理返回的 XML 以将其与其他数据合并时，用户将遇到另一个巨大的障碍。

最后还有一点：对一个查询执行此项工作之后，进行下一个查询时，此工作的很大一部分又将重复一遍。

使用 UDM 访问数据源

与前面的情形相反，以下关系图例示了如何为访问某个基于这些数据源而构造的简单 UDM 的用户生成查询。

Microsoft SQL Server 2005 附带的开发工具提供了此示例中显示的设计界面。但可以使用支持 UDM 的任何接口，包括客户端工具，例如，Office Excel 或 Office Web 组件 (OWC)，或很多报表和分析工具中的一种。

左边的树视图显示了 UDM 的内容。注意该示例中的以下几点：

• 只为用户显示面向用户的相关项目。系统列（例如，行 GUID 或最后修改日期）是不可见的。
• 所用的名称为友好名称，而没有使用基础数据库中采用的面向开发人员的命名约定。

UDM 还将每个业务实体的所有属性分组为单独的“维度”，如产品或雇员。因此，客户端便可引用该示例中的“产品颜色”、“子类别”以及“类别”，而无需在所涉及的大量表之间显式执行联接。

这些表示事务值或度量值的列随后将显示为“度量值”。例如，用户通常都喜欢对销售量或销售配额之类的列进行聚合。这种将数据显示为“度量值”和“维度”的方法称为“维度建模”。

右边的关系图显示了当前查询中包含的元素。在这种情况下，为了请求“按产品类别分类的销售额和配额”，用户只需通过从树视图中将三个相关项目拖动到右侧设计界面中，即可定义查询。用户不必指定实际访问两个不同数据源时所需的详细信息，或在很多相关表之间执行正确的联接。

模型定义了简单的默认格式：例如，使用货币符号。还可以定义更复杂的格式，包括条件格式，例如，如果某个值低于特定的阈值，则以红色显示该值。

同一模型可支持多种查询。例如，只需通过拖动雇员维度中的一个属性便可按雇员对结果进行细分。

扩展基本模型

虽然上面的示例阐释了即使简单的 UDM 也可以显著地简化基本的数据浏览。但是，当用户访问数据时，还会遇到更多的挑战。例如：

• 支持来自不同用户的众多不同类型查询的 UDM 的规模可能会变得非常庞大。如何才能确保处理特定任务的用户不会受到与之无关的信息的干扰？
• 如何满足全球用户希望看到以其自己的母语显示的报表的要求？
• 如何才能简化所有与时间相关的常见问题？例如，用户可能希望显示与上一年同期进行比较的销售额。

本部分探讨了上述部分问题，说明 UDM 如何支持对基本模型进行扩展以帮助用户实现更高级的数据浏览操作。

层次结构

虽然将一个实体的所有属性合并为一个维度可以显著简化用户的模型，但是，还有一些属性关系是用简单列表所无法表达的。在前面的示例中，“类别”、“子类别”以及 SKU 定义了其中一种可用于组织产品的层次结构。由于用户经常希望基于此类层次结构执行分析，因此 UDM 允许定义此类层次结构。例如，按“类别”查看总计之后，用户可能要深入到“子类别”，然后深入到最低的 SKU 级别。每个层次结构都是一序列属性，可以在查询中使用这些属性来简化这种向下深化和向上深化的情形。

以下关系图示例显示了层次结构可能以何种形式出现在最终用户的界面中。该模型包含若干种不同的层次结构，产品便是按照这些层次结构来组织的。这里显示的查询回答了这个问题：“显示以产品类别分组的销售额和配额，然后细分到子类别。”该查询是通过将“按类别分类的产品”层次结构拖到网格中来定义的。为了查看详细数据，该用户双击“自行车”类别以展开子级别。

UDM 处理如何在层次结构的级别之间进行移动的详细信息。UDM 还处理诸如配额在“子类别”级别不可用而只在“类别”级别可用这样的详细信息。

其中一种特殊的层次结构是父子层次结构，这种结构中包含相互之间具有复杂关系的实体。在下一个图中，“雇员”维度具有名为“按组织结构分类的雇员”层次结构。使用此层次结构，您可以更容易地在组织的每个级别浏览父子关系并分析汇总值。例如，主管销售的 Charles Marshall 的销售配额包括其所有员工的销售配额总和再加上与其直接相关的所有销售配额。

分类

用户通常会为其数据应用分类。例如，用户可能说“这些属性包含了雇员个人详细信息的方方面面”或“此属性是电子邮件地址”。UDM 提供有两种机制，专用于根据此分类来提供其他值：

• 维度、属性和其他对象可以放在语义上有意义的类别中，以便于客户端工具更加合理地使用它们。例如，属性可以标记为 URL。然后，包含此属性的报表便可根据 URL 的值进行导航。另一个属性可能标记为电子邮件地址。在这种情况下，报表客户端就可能根据某些用户的操作自动打开新的电子邮件。
• 度量值、层次结构和其他对象都可以分组到对用户有意义的文件夹中。使用此分组，报表工具能够以更易于管理的方式显示大量属性。例如，可能有一组标签为“Customer Demographics”的属性。

时间

时间信息通常使用“日期时间”或“日期”数据类型记录在基础数据源中。尽管精通 SQL 或 XPath 的用户可以提取按年度总计数据所需要的日期信息，但即使是这样的用户也可能会发现很难基于时间的其他方面来为问题编写查询，例如“按星期几显示销售额”或“从七月一日开始，按会计年度显示明细。”

但是，UDM 有内置的时间知识，包括以下日历：

• 自然
• 会计
• 报告（“445”等）
• 生产（13 个期间）
• ISO8601

因此，该模型可能包括一个时间维度，该时间维度提供了一组丰富的属性用于定义每日的详细信息。下图显示了当用户选择查看 2001 会计年度的销售量和配额时的结果。若要执行此操作，用户只需将相关项从树拖到筛选区域。UDM 知道如何将该用户操作翻译为日期范围，此外，它还了解业务规则，即查询中必须包括在这些日期发货的订单，而不是在这些日期到期的订单或在这些日期定购的订单。由 UDM 隐式执行正确的联接。

此外，UDM 为回答与时间相关的常见问题提供了特定的支持，这些问题包括诸如“本月与上一年度同一月份的比较”这样的同期比较。

翻译

在上面的示例中，模型内容和数据都以一种语言显示。但是，国际用户通常需要查看以他们本地语言显示的元数据。

为了解决此问题，UDM 允许将元数据翻译为其他任何语言。使用特定区域设置连接的客户端应用程序便可接收以相应语言显示的所有元数据。

该模型还可以进行数据翻译。属性可以映射到数据源中的其他元素，并且可以为这些元素提供不同语言的翻译。例如，如果用户在连接时使用了我们在上一示例中一直使用的相同工具，但这是从采用法语区域设置的客户端计算机上执行的，则 UDM 和查询结果都会以法语显示，如图所示。

透视

虽然此处所用的示例模型的大小非常适度，但是，真实的模型可能涉及更广的范围，包含数十种度量值和维度，并且每个维度都包含数十种或数百种属性。执行特定任务的用户通常不必查看完整的模型。为了避免模型的完整大小对用户产生干扰，我们需要定义一个视图来显示该模型的一个子集。

UDM 提供了这种称为透视的视图。一个 UDM 可以具有多个透视，每个透视都只表示一个与特殊用户组相关的特定模型子集（度量值、维度、属性等）。然后，每个透视都可与用户安全角色（定义应当看到该透视的用户）进行关联。

例如，名为“西雅图库存”的透视可以定义为只包含来自库存度量值组的度量值，隐藏“按位置分类的仓库”层次结构，并将默认的“城市”设置为“西雅图”。

属性语义

UDM 提供了属性的其他语义。这些语义的目标是为了使信息更容易使用。下面是可以应用于属性的语义的某些示例：

• 名称与键：查看关系数据库时，可能无法理解 EmployeeID 是一个系统生成的无意义的唯一键。UDM 解决此问题的方法是让“雇员”属性同时具有键（唯一的 EmployeeID）和名称（例如，名称由 FirstName 和 LastName 串联而成）。诸如“显示雇员”这样的查询便可通过使用其唯一 ID 来正确地区分同名雇员，但是显示对用户有意义的名称。
• 排序：属性的值通常必须以某个固定顺序显示，而该顺序并不是简单的字母或数值顺序。UDM 允许定义默认的排序设置以管理此要求。例如：
  • 按星期日、星期一、星期二等星期日期出现。
  • 顺序中的优先级显示为高、中、低。
• 离散化：对于数值属性，显示属性的每个非重复值通常毫无意义。例如，查看某个产品所有不同价格 ($9.97, $10.05, $10.10,…) 的销售额与查看每一价格范围 ( <$10, $10 - $15,…) 的销售额相比，后者更有用。UDM 允许使用各种条件将属性离散到上述范围中。

关键性能指标 (KPI)

企业通常会定义关键性能指标 (KPI)，这些指标是用于衡量业务发展状况的重要标准。UDM 允许创建这样的 KPI，以便企业可以按更易于理解的方式分组和呈现数据。KPI 还可以使用图形来显示状态和走向，例如，表示好、一般或糟糕的指示灯。

UDM 中的每个 KPI 可以为每个性能指标最多定义四个表达式：

• 实际值
• 目标值
• 状态 一个介于 -1 和 1 之间的规范化值，表示实际状态与目标的比率（-1 表示“非常差”，1 表示“非常好”）
• 走向 一个介于 -1 和 1 之间的规范化值，表示一段时间的走向（-1 表示“显著变差”，1 表示“显著变好”）

使用 KPI，客户端工具可以用一种用户更容易理解的方式来提供相关的度量值。下图中的示例显示了客户端工具如何显示三个 KPI（已组织到显示文件夹）。

性能

用户执行的交互式浏览需要具有快速的响应时间。由于这种数据浏览频繁进行，而它所涉及的数据集又非常大，因此这个要求给人们提出了一道难题。

为了提高性能，UDM 提供了缓存服务。缓存可以存储从基础数据源读取的详细数据，以及基于该数据预先计算的聚合值。然而，使用这些缓存值可能会暗示数据在某种程度上有些陈旧。业务要求决定对信息的时效性要求。在某些情况下，要求必须显示最新的数据；而在其他情况下，显示已存在两小时甚至两天的数据也是完全可以的。

为了反映这种指定数据状态的策略，UDM 既允许显式管理缓存（例如，可以将计划定义为在每天凌晨 2 点刷新缓存），也允许使用“主动缓存”进行透明管理。用户可以指定对数据的时效性要求，而 UDM 将自动创建和管理缓存，以尽可能提高对查询的响应速度。

分析

前面的部分解决了 UDM 如何支持交互式数据浏览的问题。但是，只是使信息可从基础数据源中获得，即使以更容易理解和易用的形式，也显然不符合将业务逻辑并入用户模型中这一目标。因此，UDM 提供了用来定义对数据执行简单和复杂计算的功能。

基本分析

查询通常返回聚合数据。例如，典型的查询将按类别显示销售额，而不是逐一显示每个销售订单。但是，并没有可以定义应当如何聚合特定度量值的基础关系数据。例如，可以明显地对销售量进行汇总，但单位价格应当是平均值。UDM 添加了这种语义。

可以使用多种方案定义聚合的方法：

• 可以使用简单的聚合函数，比如 Sum、Count、Distinct Count、Max 或 Min 等。
• 可以将聚合定义为半累加。这表示将使用诸如 Sum 这样的简单函数来计算除“时间”（在其中使用了“最后期间”）外的所有维度。例如，虽然可以从“产品”到“产品类别”对库存级别进行求和，但是“月份”的库存级别不是每天库存级别之和；相反，该月的库存级别是该月最后一天的库存级别。
• 聚合可以基于帐户类型（如收入与支出）。
• 可以自定义聚合以满足任何特殊的要求。

UDM 还可以包含计算成员。这些成员未与源数据直接关联，但是派生自源数据。例如，计算成员（方差）可以定义为计算销售额和配额之间的差异。

同样，UDM 可以定义用户关心的实体集：例如，按销售量排名的前 10 名客户或最重要的产品。然后可以轻松使用这些集将查询范围限制到特定的实体集。

高级分析

有时，用户需要的计算比前面给出的“方差”示例更复杂。下面是复杂计算的一些示例：

• 显示每个时间段的本三个月移动平均值。
• 比较此时间段和上一年相同时间段的逐年增长率。
• 如果销售额以基本货币进行报告，请使用销售时的当天平均汇率将销售额转换为原始货币。
• 按照比今年销售额增长 10% 条件计算下一年每个类别的预算销售额，然后根据过去 3 年的相对平均销售额将该预算销售额向下分配给每个产品。

UDM 提供了一个完备的模型用于定义上述计算，与多维度电子表格类似，它可以基于其他单元中的值来计算某个单元的值。但是，甚至上述比喻也不足以描述 UDM 中计算的丰富性。某个单元中的值可能不仅根据其他单元中的值进行计算，而且还根据该单元过去的值进行计算。因此，它可以支持联立方程；例如，利润等于收入减去支出，但是奖金（包括在支出中）来自利润。

除了提供专用于编写此类计算的功能强大的多维度表达式 (MDX) 语言以外，UDM 还启用了与 Microsoft .NET 的集成。此集成允许以任何可验证的 .NET 语言（例如，C#.NET 或 Visual Basic .NET）编写存储过程和函数。然后，可以从 MDX 调用存储过程或函数，以便在计算中使用。

客户端不能查看此类计算的详细信息。对于客户端应用程序，这只意味着模型现在有了更有用的度量值。在下面的示例中，用户要查看在美国销售的利润最高的产品的各种计算度量值（基于销售额）。

与数据挖掘的集成

能够以丰富、容易理解的形式显示数据很重要，但用户还需要能通过数据推导出新的信息。

UDM 紧密集成了数据挖掘技术，允许对数据进行挖掘，并在以后使用发现的模式执行预测。

使数据可操作

对于用户而言，查看数据通常会立即引发更多的问题，或者引起采取某种操作的需要。例如：

• “加入该编号的详细销售额包括哪些？”
• “配额太低 - 我必须增加配额。”
• “这有些不正常 - 我想要使用注释对该编号进行标记。”
• “我们在网站上针对该促销提供了哪些详细信息？”

通过易于理解的方式为用户提供数据是不够的。还需要使用户能够更容易地根据他们所看到的数据执行操作。

UDM 通过下列两种方式提供这种支持：

• 允许将更改写回数据中
• 使操作与数据关联。

写回

UDM 不是只读的。也可以通过 UDM 更新数据。在使用度量值的情况下，更新可以像这些值的增量那样，与原始值分开存储。

此外，还可以更新汇总数字。例如，请考虑预算方案。虽然预算量可能最终在详细级别（例如，按组和帐户）上公开，但是值可能首先在汇总程度较高的级别（按部门和帐户类型）上公开。

操作

UDM 支持的操作包括数据和基于该数据执行的操作之间的链接。主要的操作种类包括：

• URL：转到指定的 URL。此类型的操作支持将用户引向某些 URL，以获得进一步的信息，并将用户引向允许执行新任务的某些基于 Web 的应用程序。例如：
  • 对于产品，转到说明该产品的公司网站。
  • 对于产品/仓库组合，转到基于 Web 的库存管理应用程序（将产品/仓库作为参数进行传递）以允许提高安全存货水平。
• 报表：执行指定的报表。例如，对于给定产品，该操作可以执行一个参数化产品报表，以用来提供产品说明和当前的订单状态。
• 钻取：钻取到可用详细信息的最低级别。例如，按产品和客户查看总销售额的用户可以钻取查看构成总销售额的所有销售事务。

操作可以与特定区域的数据进行关联。例如，导航到网页的操作可能应用于每个产品，但是查看详细存货转移事务的操作将应用于每个产品和仓库的数量值。

虽然操作已定义为 UDM 的一部分，但是客户端应用程序应当负责检索适用操作的详细信息，并将操作提供给用户，然后根据需要启动操作。

安全性

对 UDM 的访问是可控制的。安全性的主要功能包括：

• UDM 提供基于角色的安全性。可以定义角色，可以将权限授予这些角色以及作为每个角色的成员的用户。用户的实际权限是授予用户所属每个角色的权限的联合。角色的权限也可包括“强拒绝”，是指删除与用户可能所属的其他角色无关的权利。
• 管理权限（例如，更改 UDM）可以独立于数据访问权限而进行授予。而且，可以为读取对象的元数据，以及为数据的读/写访问权，定义单独的权限。
• 可以在直至单个单元的粒度级别上对数据进行安全设置。例如，可以将查看产品“器材”销售额的用户限制为客户“ACME”。安全性也可以是有条件的：例如，只有当某个部门具有五名以上的雇员时才允许某个角色查看该部门的薪金总额。
• 权限可以定义是否应使用直观合计（在这种情况下，合计只反映用户对其具有权限的较低级别的成员）。单元访问也可以是有条件的，这表示只有当其他所有单元也是可查看的时，从其他单元派生的单元才是可查看的。例如，如果利润派生自收入和成本，则用户只能查看他们有权同时查看其收入和成本的产品的利润。

请参阅

其他资源

Analysis Services 概念

帮助和信息

获取 SQL Server 2005 帮助