Project REAL分析服务技术探讨

结论

总的来说，数据源视图在分析服务中有两个重要的角色。

首先，它们是在分析服务使用对象和数据源之间一个抽象的层。这允许你创建类似命名查询和计算列这样的对象，这些对象也能在数据源中直接创建（例如，关系型视图）。这很重要，因为分析服务的管理员可能没有必要的权限去改变源系统上的元数据。例如，源系统可能是一个保留了主要的私人信息的组织级的SAP系统。作为组织的资源，管理分析服务服务器的DBA可能没有权限在这个源系统中实现添加、移除或者改变视图这些操作。但如果把这些改变放到数据源视图中，DBA就能从一个抽象的层获得好处，而不必再去改变源系统上任何信息。

数据源视图允许你在那些不在物理数据库上或者不可能位于不同的数据库上的表和视图之间创建关联。例如，你不能在两个存储在不同数据库上的表创建外部关键字约束。这个关联对于那些从3NF或者OLTP数据库构建的维度是很重要的。

不要让数据源视图失去自控能力。毕竟它们只是一个工具，而不是一个万能药。如果你开发了一个很好的多维度设计，你可能会发现它们不仅仅是很有趣的工具。

维度(dimensions)

在Project REAL中，我们有大量的、复杂的维度。这也是带我们到这个特殊应用程序的内容之一。这有大量的分析是基于厂商所扮演的角色。这里有许多半可加性的度量，例如库存数量以及其它类型的库存数据。这种多维度设计对于那些已经开发或者正在维护零售数据库的人员是非常熟悉的。

维度键

维度包含的内容主要是用来过虑或者考虑真实表的各种度量。Cube中的维度都会映射到一个关系型的维度表。

逻辑模式有两种类型的键：代理键（Surrogate keys）或者业务键。代理键被用来表示表之间的内部关系。业务键（Business keys，有时也称为natural keys）是为了从业务本身中标识一个实体。因此，例如，尽管厂商被代理键(使用一个标识的属性，例如1-n)指定的时候，但在外部世界，它们自然键(natural keys)是一个厂商编号－例如，厂商#7233703。对于真实的表，ETL过程都会将业务键映射到代理键，因此，当记录被暴露到分析服务的时候，事务就已经发生。

在我们的案例中，代理键被用来跟踪第二种类型缓慢变化维度。你将发现，所有的维度键属性都使用了代理键列。我们在维度键属性上不使用自然业务键，因为多个第二种变化类型记录可能会有相同的业务键。尽管各种类型和缓慢变化维度的使用已经超出了本文的范围，但数据模型本身还是在推断的成员中使用了第一种类型和第二种类型缓慢变化维度用来插入，可以参见Project REAL: Business Intelligence ETL Design Practices 白皮书。我们也推荐在http://search.barnesandnoble.com/ booksearch/isbnInquiry.asp?isbn=0471200247网站上的Ralph Kimball的书籍《The Data Warehouse Toolkit, Wiley, 2nd edition》

层次（hierarchies）

尽管维度在报表中给出了度量的上下文和意思，但终端用户实际使用的分析对象是层次（hierarchies）。SQL Server 2005分析服务中，提供了两种类型的层次：属性层次（attribute hierarchies）和用户定义层次（user-defined hierarchies）。

在层次中是各个级别的集合。层次中每个Drilldown就是一个级别。例如Time层次中包含Year、Quarter、Month、Week和Day几个级别。在Book层次中（Project REAL中还用Item来表示）有Type、Subject、Category、SubCategory和Item级别。

报告层次（Reporting hierarchies）

第一个用户定义层次类型是报告层次。这个层次仅仅是用来报告的。潜在的数据并不支持各个级别上的关联信息。例如，我们有一个报告层次被设置成ALL->Author->Item。这样报告的目的仅仅是因为一个Item能够决定一本书，而其它的却不行。在层次中将作者放到Item前面，将产生一个多对多的关系。

自然层次（Natural hierarchies）

另外一种层次类型是自然层次，也被称为强层次（strong hierarchy）。在自然层次中，层次中的数据和其它的层次都有一个多对一的关系。日上 滚到周；周上滚到月；月上滚到季；季上滚到年。这将允许系统能够预先计算一个上滚动作或者是集合，例如为获得根据City的Store Sale的子集，然后根据City计算State；根据State计算Region；根据Region计算国家（这些求和都是基于层次的）。你能够重新打破或者再细分这些自然层次，因为每个成员都有且只有一个父亲。

自然用户定义层次不是SQL Server 2005新带的属性。它们在分析服务的早先版本中就存在。新的在于一种报高层次，它们是使用属性层次来构建的。

属性层次（Attribute hierarchies）

属性层次是SQL Server 2005中一个新的层次类型。它是基于维度表中的属性或者列。本质上任何数据库中的列都能成为维度的属性。当一个属性被定义到一个维度，一个属性层次就生成了。这意味着，如果时间维度表有一个Holiaday列，它只使用0或者1来表示某天是否是假期，然后你能够基于这个列创建一个Holiday属性层次。属性层次是平直的（Flat）。当一个层次只有两个级别的时候，我们称它为平直的。这两个级别是：所有的级别（把属性的所有值都加起来得到一个总的值）；另外一个就是它自己。由于Holiday作为一个在用户定义层次中的独立的层次存在并使用，因此终端用户能够通过Holiday实现销售情况的分析。SQL Server 2000分析服务中有一个类似的概念，叫做虚拟维度(virtual dimension)。尽管使用虚拟维度，你能够基于每个成员属性创建一个维度，但虚拟维度在范围和伸缩性上都有很大的局限性。

基于层次系统（hierarchie-based systems）和基于属性系统（attribute-based systems）的对比

这是两个SQL Server 发布版本重要的、基础性的区别。

SQL Server 2000分析服务是一个基于层次的系统。内部结构都导向层次或者级别。这包括了，像集合，是级别的一个捆绑，每个都针对一个维度；像虚拟维度，将成员属性提升为维度。一个维度智能有一个层次。多层次是一个命名惯例。两个时间层次，例如Time.Calendar 和Time.Fiscal，看上去，它们都和Time相关，但在内部，这是两个不同的维度，只是恰好它们的名字上都有Time。一个名称为Product的维度也有可能是名称为Product的层次。在维度和层次之间没有严格的差别。

SQL Server 2005 分析服务是一个基于属性的系统。属性是构建对象的基础。集合是捆绑属性的求和。默认情况下，属性层次会自动的为属性创建。一个维度能有多个层次。在一个时间维度中，Time.Calendar和Time.Fiscal是两个层次(Calendar和Fiscal)。用户定义层次（例如Calendar和Fiscal）纯粹的用来导航实体。它们存在不仅仅是为了辅助属性的组织。你马上将会看到，这样的概念将在整个文章中被反复的出现。

维度中使用了如此多的逻辑结构。现在，让我们来看看维度的一些物理特性。在这里，我们首先讨论它们使用的内存。

共20页: 5 下一页

【内容导航】

原文：Project REAL分析服务技术探讨(5)