统一维度模型简介[转]

最新推荐文章于 2024-05-20 20:26:39 发布

Johe_08

最新推荐文章于 2024-05-20 20:26:39 发布

阅读量1.6k

点赞数

分类专栏： SQLServer_Analysis Services 文章标签：数据库产品 web服务 sql server 工具 components

SQLServer_Analysis Services 专栏收录该内容

18 篇文章 0 订阅

订阅专栏

前言

如果用户希望直接访问类似ERP数据库之类的数据源，他们将面临下列一些很大的挑战：

·数据源的内容通常很难理解，因为它们是面向系统和开发者设计的，而没有考虑到一般用户。

·用户感兴趣的信息通常分布在多个异构数据源上。即使仅仅是处理多个不同的关系型数据库也需要用户了解它们的不同之处(例如不同的SQL语法)。更糟糕的是这些数据源可能属于不同的类型，不仅包括关系型数据库甚至还包括文件和Web服务。

·多数数据源包含大量的事务级细节，而许多情况下那些为企业决策服务的查询需要包含总结性的、聚合的信息。随着数据量的不断增大，查询这些聚合信息所需的时间越来越不能被交互式的用户分析所承受。

·数据源中通常不包含商业逻辑。用户只能自己来理解这些数据。

统一维度模型的作用就是在用户和数据源之间提供一个桥梁(图1)。统一维度模型构建在一个或多个物理数据源之上，用户可以通过类似微软Excel等的若干客户端工具中的一种向其递交查询。

图1 统一维度模型提供了用户和其数据间的桥梁

最简单的情况下统一维度模型仅仅是数据源之上的一个薄层(thin layer)，却给用户带来多种好处：一个更简单、更易理解的数据模型；屏蔽底层异构数据源；高效的聚合型查询。在某些情况下，类似这样一个简单统一维度模型的建立是完全自动的。如果仔细研究统一维度模型的创建，我们会从模型提供的丰富元数据(metadata)中得到额外的好处。

本文简要介绍了统一维度模型。首先，通过一个实例来描述统一维度模型所提供的基本客户端模型。然后，这个实例会被仔细研究以揭示统一维度模型的一些功能，包括：

怎样增强用户模型；

怎样在面对海量数据时提供高效的查询以支持交互式分析；

怎样在模型中包含商业逻辑以支持更丰富的分析；

怎样支持”闭环”(closing the loop)使用户能对其所见数据进行操作；

最后，本文概述了统一维度模型的体系结构及其安全性。

基本客户端模型

下面以一个用户希望比较不同时期产品的销售额和配额为例。

销售数据保存在主销售和仓储数据库，当然数据库中还包含很多其他的表。即使找到了相关的表，我们会发现一个实体(例如产品)的数据分布在多个表上，而且应用程序逻辑为了保证引用完整性，这些表之间没有定义关系。销售配额保存在另一个应用的数据库中。这两个数据库中都没有包含商业逻辑，例如像在比较配额和实际销售额时，应该使用发货的日期而不是其他那些订单的日期(比如订单签订日期、货物应到日期、货物安排日期等等)。

图2 包含销售和销售配额数据的数据源

直接访问数据源

首先，考虑用户直接访问数据源的情况。图3是一个使用示例工具来创建查询的例子。

图3 直接查询数据源

到此为止，用户已经取得了很大的进步。他们:

·通过筛选大量名字晦涩的表去寻找那些感兴趣的内容。

·分辨出哪些数据列可以用来进行表的连接。

·找出那些含有其感兴趣细节的列，通常这些数据列需要从海量的细节中抽取。例如，在包含产品分类信息的11个列中，只有两个名字列是真正与用户相关的。

现在用户开始考虑是使用外连接还是内连接以及怎么把细节集中起来以提供所需的聚合数据。

糟糕的事件不可避免的出现了。怎么与其他的数据源连接？即使数据库支持分布式查询，对大部分用户来说，创建所需的查询语句仍然非常困难，而一些通常的辅助工具对此也无能为力。

SELECT Quotas.QuotaAmount, Quotas.EmployeeId, ...

FROM OPENROWSET('SQLOLEDB','seattle1';

           'Sales';'MyPass',

           'SELECT * FROM Forecasts.dbo.SalesQuota' ) As Quotas

再考虑其他一些数据源，比如Web服务，用户在决定怎样进行合适的远程调用以及如何处理返回的XML并将其与其他数据连接时面临着另一个难题。

最后一个问题是尽管你对一个查询，如按类型显示总销售额和配额已经进行了这些工作，当你处理后继的查询，如将上述查询的结构按雇员划分时，大部分工作还要重做。

通过UDM访问

为比较起见，下面举一个用户使用简单的统一维度模型访问数据源时如何创建查询的例子。这里展示的用户界面(图4)是从微软SQL SERVER提供的开发工具中截取的。其他一些客户端工具，比如Excel或者Office网络组件(Office Web Components)，以及任何支持UDM的报表和分析工具都能提供这种展示。

图4 使用简单UDM访问数据源

左边的树型视图显示了UDM的内容。首先，我们注意到：

·仅仅显示了面向用户的、与用户相关的条目。那些“系统列”，比如行唯一编号(rowguid)、最后修改日期等不可见。

·命名是用户友好的，而不是来自那些应用于底层数据库的面向开发人员的命名习惯。

统一维度模型还将每个商业实体(例如产品、雇员等)的所有属性都集中到一个单独的“维度”。因而这个例子中，用户可以引用产品颜色，子类型，类型，而不需要显式地进行表连接。

对于那些表示交易数额或量度的列(比如交易金额或定额等),用户通常对它们进行聚合操作。这些列被称成“度量”(measures)。这种用“维度”和“度量”来表示数据的方法就是所说的维度建模(dimensional modeling)。这种方法已经被工业界证明是一个用户易于理解的成功的模型。

图4的右边部分显示了当前查询包含的元素。在当前情况下，用户只需简单的从左边的树型视图中拖取三个相关的条目就可以创建”将销售金额和销售定额按产品类型显示“的查询。用户没有必要取指定访问两个不同数据源的细节以及如何进行数据表的连接。

这个模型也定义了一些默认的简单格式(例如货币符号的使用)。用户也可以定义更丰富的格式，包括条件格式化(例如当一个值小于某个阈值时，将其显示成红色)。

相同的模型可以支持多种查询。例如，当向其中添加入一个来自雇员维度的属性时，数据将会根据雇员被划分。

进阶

尽管前述的例子证明了甚至通过一个非常简单的统一维度模型都可以极大的简化基本的数据浏览操作，但是我们仍面临一些额外的挑战。例如：

·如果一个UDM支持来自多个用户的多种不同查询，其自身将会变得很庞大。我们如何保证一个用户不会被一些无关信息所干扰？

·我们如何满足来自全球的用户希望看到以其母语展示报告的要求？

·我们如何使关于时间的问题很容易解决(例如，“显示与去年同期比较的销售额“)？

这部分结合这些问题来说明UDM对一些高级数据浏览操作的支持。

层次结构

尽管将一个实体所有的属性集中到一个维度极大地简化了模型的使用，但是这些属性间的一些额外的关系不能简单地通过一个列表来表示。在前述例子中，类型、子类型、SKU定义了一种可以用来组织产品的层次结构。因为用户经常需要基于这些层次结构来进行分析，例如首先根据类型查看总数，然后再下钻(drilling down)到子类型，进而到最底层的SKU，UDM允许定义这样的层次结构。每一个层次结构是一个属性的简单序列，可以被用在查询中简化下钻/上钻(drilling up)操作。