Data Source Design Best Practices / 数据源设计最佳实践

Do use only supported OLEDB providers in a Data Source
在数据源中仅仅使用被支持的OLEDB提供程序。

Analysis Service在设计和测试的时候都是以特定的OLE DB提供程序作为基准的。虽然其他的OLE DB提供程序也可以使用，而且选择数据源向导也允许你自由选择其他兼容的提供程序，但是不同提供程序之间的能力和行为是有一些微妙的不同之处的，即使连接到同一个数据库也可能存在不同。所以你应该尽可能地去使用那些被Analysis所支持的提供程序。要查看所有支持的提供程序，请访问：http://msdn2.microsoft.com/en-us/library/ms175608.aspx。

Do not use the .Net SqlClient Data Provider to connect to a SQL Server data source
忌用.NET SqlClient 数据提供者连接SQL Server数据源。

Analsysi Services使用本地代码运行（这样效率更高），因此如果使用的是本地提供程序的话，你可以获得更不错的性能。因此，不要使用.Net SqlClient数据提供程序，而是使用SQL Server的Microsoft OLE DB提供程序或者SQL Native Client提供程序作为替代。

Dimension Design Best Practices / 维度设计最佳实践

好的维度设计往往是一个好的Analysis Service OLAP数据库设计的一个重要组成部分。虽然Analysis Service向导已经为你做了很多工作，但是还是有必要重新审视下用向导生成的设计，确认属性、关联还有维度层次是否正确反应了底层数据，并且满足终端客户的需求。

Do create attribute relationships wherever they exist in the data
尽量创建属性关联(Attribute Relationships)如果它们的数据存在关联

属性关联是维度设计中最为重要的一部分。它们帮助服务器对数据的存储进行优化，对维度内的完整性进行检查，为成员提供了成员属性的特性，并且决定了MDX查询中一个维度层次的数据如何影响另外一个维度层次的数据。出于这些考虑，你需要花多一些时间在属性关联的设计上面，保证其正确反映了底层数据之间关系。

Avoid creating attributes that will not be used
避免创建不被使用的属性

属性增加了维度的复杂性和存储开销，一个维度中的属性的数量会对其性能产生比较显著的影响。特别是对于那些设置了AttributeHierarchyEnabled=true的属性。虽然SQL Server 2005 Analysis Service支持一个维度中添加很多的属性，但是设计过多不必要的属性往往会降低系统性能，使到改善终端用户体验变得更为困难。通常我们无需为维度表中的每个字段都建立一个属性。虽然Analysis Service向导总是会自动帮你选出维度表中所有的字段甚至关联表中的所有字段作为属性，但是一个好的设计是在开始的时候先把确定会使用到的字段添加为属性，以后如果有需要的话再向维度中添加其他的属性。为适应新需求而添加属性总比预先把所有潜在的属性都加上去然后再一个个删除更高效。

Do not create hierarchies where an attribute of a lower level contains fewer members than an attribute of the level above

不要创建子级别属性成员数少于父级别属性成员数的维度层次

如果存在这样的维度层次，那么通常意味着你的维度层次设计中，级别放置的顺序有问题。例如，City放置在State级别之上。也有可能是因为子级别的关键列缺少必要的字段，例如在[Quarter Number]级别之上的Year级别而不是在把Year设置在[Quarter with Year]之上。任何这些情况都会引起终端用户在使用和理解多维数据集时的困惑。

Do not include more than one non-aggregatable attribute per dimension
在同一个维度中切勿包含一个以上的非聚合属性

对于非聚合属性，没有了All成员，因此对于每个非聚合属性默认情况下都会选中一个非“AlL "的成员，即使在查询过程中没有显式指定该成员。因此，如果你在一个维度中包含了两个以上的非聚合属性，那么选取的属性之间就会产生冲突，最终得到的聚合指标可能就不是我们所期望的。

例如，在时间维度中，可能对[Calendar Year]或者[Fiscal Year]的成员进行sum聚合不是很有意义，但如果把两个属性同时设置为非聚合属性，那么当用户查询一个指定的[Calendar Year]的数据的时候，这个数据就会被[Fiscal Year]属性下的默认成员预先过滤了，除非用户同时显式指定了[Fiscal Year]的成员。糟糕的是，这两个属性之间不是并列的关系，而是重叠的关系。也就是说，这两个属性之间是互相影响的，我们很难保证显式指定的[Fiscal Year]成员和[Calendar Year]属性的成员之间有重叠，因而查询在查询其中一个属性时，我们很难得到该属性的全部数据的聚合值。

Do use key columns that completely and correctly define the uniqueness of the members in an attribute
正确使用关键列来保证成员在属性上的唯一性

通常情况下，一个简单的关键列就足够了，但有时候，我们需要使用多个列来同时决定属性的成员的唯一性。例如，我们很熟悉的时间维度中，[Month]属性就是使用了[Year]和[Month Name]作为关键列集合。这也是我们常说的复合主键，它将 “January of 1997”和“January of 1998”当作两个不同的成员。当你在时间维度层次中同时使用[Month]属性和[Year]属性时，“January of 1997”和“January of 1998”之间的区别就变得非常重要了。

Do perform Process Index after doing a Process Update if the dimension contains flexible AttributeRelationships or a parent-child hierarchy
如果维度上含有Flexible的属性关系或者含有父子层次，在做处理更新时候需要重做Process Index

一个聚合，若其中包含一个属性使用柔性关系直接或者间接的关联到关键属性上，那么这个聚合也被视为是柔性的。包含父子层次关系的聚合也被视为是柔性的。

当使用“Processing Update ”选项对维度进行处理时，所有涉及到此维度的柔性于聚合可能都会被丢弃，这取决于新维度数据的内容。这些聚合默认情况下是不会重建，因此必须显式的使用“Process Index ” 选项去重建这些聚合。

Do use numeric keys for attributes that contain many members (>1 million)
给属性列使用数字类型，尤其含有百万记录成员的属性

使用数字属性列而不用字符串或者复合关键列会大大提高那些那些包含大量成员的属性。这个最佳实践类似于我们在关系型数据库中常常使用代理主键（通常是自增长数字主键）来替代业务主键，以使索引性能更佳，理念是类似的。你可以使用数字型列作为属性关键列，然后使用文本型列作为该属性的名字列，以展示给最终用户。一个指导原则就是，当你属性包含有超过一百万个成员时，一定要考虑使用数字型列作为属性关键列。

Do not create redundant attribute relationships
不要创建多余的属性关联，比如A->B, B->C, 则A->C不必手工创建

如果两个属性之间已经存在间接的关系，那么就不需要再为其建立多余的直接关联。多余的关联路径会对服务器处理造成问题，而且也不会对维度有任何好处。例如，如果我们已经创建了A->B, B->C的关联路径，那么 A->C 之间的路径就是多余的，应该删除掉。

Do include the key columns of snowflake tables joined to nullable foreign keys as attributes that have NullProcessing set to UnknownMember
如果维度表外键关联可能为NULL的列，则设置NullProcessing为UnknownMember

如果维度中用到的表的主键可能会被其他表当作外键引用，而其他表中的此外键字段可能为null，那么你最好要在维度设计中包含此主键作为一个属性，否则的话，OLAP服务器会在处理维度时会对这两张表发起一次Join查询。这会使到处理速度更慢。更重要的是，OLAP服务器默认用到的Join查询会排除掉任何外键字段包含null的行记录。因此对于此属性，一定要记住设置其NullProcess选项为UnknownMember。因为默认情况下，null字段在引擎处理属性时会被转化成0或者空值。这有时会造成错误，因为0可能指向一个合法的主键，所以可能会产生不正确的结果。为了更合适的处理null字段，你必须设置维度的UnknownMember属性为visible。多维数据集和维度向导已经帮你自动设置好此选项。但是，维度向导当遇到雪花型表结构时，允许你手动去除雪花结构表中的主键，如果此主键相关的外键可能为null，那么你千万要勾选这个主键。

如果你不想此属性展示给最终用户，那么你可以将其AttributeHierarchyVisible的选项设置为false。但是AttributeHierarchyEnabled选项必须设置为true，因为其他属性可能直接或者间接的关联到这个属性上，从而避免在维度处理过程中产生的不必要的join查询。

Do set the RelationshipType property appropriately on AttributeRelationships based on whether the relationships between individual members change over time
根据成员属性的不同特点设置合适的RelationshipType(Flexible或者Rigid)

不同属性之间的成员的关系，例如给定一个日期，看它的月份，或者给定一个用户，看它的性别，这些属性成员直接的关系一般都是不会发生变化的。其他属性关系，如给定一个区域，看它的销售人员，或者用户的婚姻状况，这些确实很可能随着时间的变化而发生改变。你应该将关系不会发生变化的属性之间设置。

正确设置这些关系类型，服务器可以对数据仓库的改变的处理流程和聚合的重建过程进行优化。默认情况下，此选项被设置为Flexible。

Avoid using ErrorConfigurations with KeyDuplicate set to IgnoreError on dimensions
为了检测数据唯一完整性，有的时候需要改变KeyDuplicate的默认值

当错误处理中的KeyDuplicate选项被设置为IgnoreError时，我们可能很难发现因为错误的关键列，错误的AttributeRelationships或者数据一致性问题导致的问题。因此大多数情况下，你最好修正你的设计，使到数据更可靠。IgnoreError对于原型设计可能比较有用，因为这样比较省事，默认的设置也是IgnoreError。因此，如果你已经完成原型设计了，那么最好改变KeyDuplicate的设置，以保证数据的完整性。

Do define explicit default members for non-aggregatable Attributes
对于非聚合属性定义默认成员

默认情况下，All成员被用作所有可聚合属性的默认成员。对于可聚合属性，这是没问题的，但是对于不可聚合属性，因为没有All成员，服务器就无法确定选择哪个成员作为默认成员，然后它就会随便的选择一个成员作为默认成员。这个默认成员会被应用在所有使用到这个属性维度层次但是却有没有显式指定成员的Mdx查询中。为了避免这种情况的发生，对于非聚合属性，我们要显式的制定一个默认成员。我们可以再属性的属性面板中设置，也可以通过cube脚本设置。

Avoid creating user-defined hierarchies that do not have attribute relationships relating each level to the level above
不要创建子级别和父级别没有关联关系的自定义层次

定义维度层次中级别之间的关系可以使服务器对其进行更有效的优化。

Avoid creating diamond-shaped attribute relationships
避免创建钻型属性关联

钻型关系指的是关系图中先分开又合并但又不存在冗余的这种情况。例如Day->Month->Year 和Day->Quarter->Year这两条关系线都使用的同一个起点和同一个终点，但是关系并没有重叠。这种关系也被称作多重路径关系，对于服务器而言，这样会造成二义性。如果实在需要保留这种设计，那么你可以通过定义包含每条关系路径的自定义维度层次来解决二义性的问题。

(关于钻行关联，可以参考这篇Blog以及AS2008可能会去除这个限制：http://sqlblog.com/blogs/mosha /archive/2007/06/07/katmai-june-ctp-attribute-relationships-tab.aspx )

Consider setting AttributeHierarchyEnabled to False on attributes that have cardinality that closely matches the key attribute
对于那些表间关系和关键列很接近的属性，考虑设置AttributeHierarchyEnabled属性为false来禁用属性层次

虽然维度属性只能包含一个关键列，这样才能唯一标识一个值，但维度属性可以拥有其他属性作为附加的标识信息或细节信息。这些维度属性通常并不会被用作分组或者中心来查看聚合数据，例如电话号码之类的维度属性，通常人们更倾向于将其作为例如用户的附加属性来查看，而不会看从每个电话号码的维度层次去看聚合数据。因此将这些维度属性的AttributeHierarchyEnabled选项设置为False可以降低终端用户查看维度时的复杂性，同时对性能也有一定的提升。

如果你希望可以浏览这些维度属性，那么你可以设置AttributeHierarchyEnabled=true，然后将AttributeHierarchyOptimized设置为NotOptimized，将GroupingBehavior设置为DiscourageGrouping。这样，你还是可以提升性能，并且指示终端用户，此维度属性不建议用作分组聚合。

Consider setting AttributeHierarchyVisible to False on the key attribute of parent-child dimensions
设置父子维度的key attribute的AttributeHierarchyVisible为False

已经放置到父子维度层次结构中的关键属性默认情况下也会再生成一个属性层次，这通常没有什么必要，而且也会造成终端用户的迷惑。

Avoid setting UnknownMember=Hidden
避免设置UnknownMember=Hidden

如果你隐藏了unknownmember，那么可能会隐藏掉潜在的关系型数据库的一致性问题。而且隐藏的UnknownMember可能包含有聚合数据，因此展示给终端用户的数据加起来和OLAP服务器通过All成员聚合得到的数值可能就会不一致。因此，除非是原型设计，否则不推荐隐藏UnknownMember。

Do use MOLAP storage mode for dimensions with outline calculations (custom rollups, semi-additive measures, and unary operators)
对含有outline计算的维度记得使用MOLAP存储模式

包含自定义Rollups或者一元操作符的维度使用MOLAP存储模式可以显著提高性能。下面这些类型的维度也会受益：对于通过帐户维度进行聚合的指标时，帐户维度性能会所有提升；包含半可加性指标的分组中的第一个时间维度。

Do use a 64 bit server if you have dimensions with more than 10 million members
如果维度下成员含有千万个数量级，需要考虑使用64位的服务器了

如果维度下包含有千万数量级的成员，那么出于性能考虑，就必须使用到64位或者基于IA-64的服务器了。

Do set the OrderBy property for time attributes and other attributes whose natural ordering is not alphabetical
对于那些不是数字类型的属性(Attribute)，比如时间，记得设置它的OrderBy属性(Property)

默认情况下，服务器对于维度属性的成员使用按名字的进行字母排序。这种排序对于时间属性来说是特别不合适的。为了得到期望的排序行为，我们需要显式指定OrderBy和OrderByAttributes的选项。对于时间相关的属性，通常我们会设置date或者一个数值类型的列作为其排序依据。

Do expose a DateTime MemberValue for date attributes
对于日期属性，尽量暴露它的MemberValue属性（有些客户端会根据这个属性来对待日期时间）

有一些客户端如Excel，会使用日期成员的MemberValue属性来获取相关的具体日期。当Excel发现其属性值为DateTime类型的话，Excel会将此成员作为DateTime类型来处理，这样就可以应用Excel的一些函数，同时也可以由Excel来对其作格式化和过滤。如果该维度属性对应的关键列只有一个，并且是DateTime类型的，同时命名列也没有设置，那么MemberValue会自动继承关键列。这种情况下，你不需要做任何额外的操作。但是，在其他情况下，你必须通过显式指定ValueColumn选项对应的列从而正确设置MemberValue属性。

Do set AttributeHierarchyEnabled to False, specify a ValueColumn and specify the MimeType of the ValueColumn on attributes that contain images
对于图片属性，应该要设置AttributeHierarchyEnabled为False,并且设置它的MimeType为图片类型

因为在浏览一个包含图片信息的属性时没有值可以显示，因此你需要将该属性的属性维度层次设为隐藏，以避免用户直接浏览。为了帮助客户端识别并展示这些包含图片信息的属性，我们需要设置属性的值列，同时还需要将mime类型设置为相应的图片类型。

Avoid setting IsAggregatable to False on any attribute other than the parent attribute in a parent-child dimension
除了父子维度的parent属性外，不要设置属性的IsAggregatable为false

非聚合属性都包含一个不是All的默认成员，这些默认成员会影响到那些没有显式指定维度层次成员的Mdx查询。因为父子层次通常代表着用户非常感兴趣的浏览路径，因此在这种情况下用到非聚合属性是必要的，其他情况，尽量要避免非聚合属性的使用。

Do set dimension and attribute Type properties correctly for Time, Account, and Geography dimensions
对于时间，帐户，地理维度记得设置他们的维度和属性类型

对于时间维度，一定要注意正确设置每个维度属性的类型，因为时间相关的Mdx函数还有和时间维度相关的商业智能都会用到这些维度属性，正确设置其类型可以保证这些函数和商业智能得到你期望的结果。对于帐户维度，如果你用到了使用帐户进行聚合的指标，那么一定要注意正确设置账户维度的类型。地理类型虽然服务器没有提供内置的支持，但是正确设置其类型可以为客户端程序提供更多有用的信息。

一个常见的错误就是设置了维度的类型，但是没有设置维度属性的类型，或者反过来。另外一个常见的错误是不清楚这些类型的意义，从而设置错误。例如本该设置为[Month]类型的，结果设置成[Month of Year]类型。

Consider creating user-defined hierarchies whenever you have a chain of related attributes in a dimension

如果维度中属性有一系列的关联关系，记得创建自定义层次

维度属性关系链通常代表着用户感兴趣的浏览路径，而且将其定义成用户自定义维度层次可以带来性能的提升。

Do include all desired attributes of a logical business entity in a single dimension instead of splitting them up over several dimensions
尽量在一个维度中把描述一个业务实体所有必要关联属性，而不是分到多个维度中

在Analysis Services 2000中，每一个维度层次事实上就是一个独立的维度，像性别，年龄这样的维度属性也被视作一个独立的维度。在Analysis Services 2005中，维度可以并且也应该包含一个业务实体的完整信息，包含相关的维度层次还有维度属性。但是这也不是说所有信息都必须塞到一个维度里面去，而是说，描述一个业务实体的完整信息应该包含在一个维度中，而不是分隔到多个维度里面。

对于此指导原则，有两个例外：

1. 因为一个维度只能包含一个父子结构的维度层次，因此如果你有多个父子层次，那么需要放到不同维度中。

2. 要在一个维度中用到多重join到某一个查询表，你必须创建一个独立的基于这个查询表的维度，然后将其作为一个引用维度。

Do not combine unrelated business entities into a single dimension
也不要把没有关联的多个业务实体放到同一个维度中

将独立的业务实体，例如客户和产品或者仓库和时间，放置到一个单一的维度中去，不但会使到模型容易让人迷惑，而且会造成查询性能的降低，因为auto-exist的特性会应用到维度内的任意两个属性之间。

换种说法，一个维度的关键属性需要唯一标识一个业务实体，而不是一个合并之后的业务实体。一般情况下，这要求对于关键属性只能有单一的关键列（非复合关键列）。

Do set NullKeyConvertToUnknown to IgnoreError on the ErrorConfiguration on any measure groups that contain a dimension referenced through a nullable column
对于任何度量组含有的维度如果引用含有NULL值，记得设置NullKeyConvertToUnknown为IgnoreError，并且UnknownMember设为Visible

默认情况下，当引擎在处理粒度属性的时候，null会被转化成0或者空字符串。这有时候会造成错误，因此0可能对应着一个合法的值，这样一来，结果可能就不是你想要的。为了避免这样的问题，你需要显式设置维度的UnknownMember为Visible，同时设置指标分组错误处理中的NullKeyConvertToUnknown选项为IgnoreError。

Consider setting AttributeHierarchyVisible to False for attributes included in user-defined hierarchies
考虑设置AttributeHierarchyVisible为false如果该属性在自定义的层次中被使用

如果一个属性已经被放到一个用户自定义的维度层次中去了，那么就没有必要再将其另起一个维度层次，这会让最终用户感觉到复杂。

一个常见的例子就是时间维度。向用户展示同一个属性的不同角度这是可以的。我们从Month的维度层次去看数据和从[Month-Quarter-Year]的维度层次去看数据都是很有价值的，不过，这两个维度层次中用到的Month其实是两个不同的属性。第一个显示的是“一月”这样的数据，而第二个显示的是“1998年一月”类似这样的数据。

o not use proactive caching settings that put dimensions into ROLAP mode
考虑性能不要使用Proactive caching设置维度为ROLAP模式（可设置OnlineMode为OnCacheComplete）

考虑到性能的原因，我们强烈建议在配置维度主动缓存策略时不要让其进入ROLAP模式。你需要设置OnlineMode属性为OnCachComplete（在存储选项面板中将“Bring online immediately”的勾去掉）。

Avoid making an attribute non-aggregatable unless it is at the end of the longest chain of attribute relationships in the dimension
避免设置维度的属性（Attribute）为non-aggregatable除非它在一个相当长的属性关联关系链的末端

非聚合型属性会有一个非“All”的默认成员，这会影响到查询中那些没有显式指定这些非聚合属性成员的单元格的值。因此，你应该避免使用非聚合属性，除非这个属性很少被用到。因为长的属性链通常意味着用户非常感兴趣的分析路径，因此最好避免将非聚合型属性放置在人家不感兴趣的属性链上。

Consider creating at least one user-defined hierarchy in each dimension that does not contain a parent-child hierarchy
为非父子结构的维度创建至少一个自定义层次

大多数（但也不是全部）维度都会包含一些有价值的层次结构用来更好的展示数据。经常多维数据集向导或者维度向导没能检测到这些层次结构，在这种情况下，你就必须手动建立这些层次结构。

Do set the InstanceSelection property on attributes to help clients determine the best way to display attributes for member selection
设置Attribute的InstanceSelection属性，这样客户端工具可以在用户选择成员时候显示正常的属性值

如果在一个列表中有太多的成员需要显示，那么客户端工具可以使用其他办法，如使用过滤类型的列表，来更好的展示这些成员。通过设置InstanceSelection属性，你可以根据列表中期望的成员数目来提示客户端程序使用合适的方式来展示这些成员

下面是一些指导性原则：

None

不要展示选择列表，让用户直接输入值。

<100 成员，使用DropDown

成员数目比较小，适合直接使用下拉列表框展示。

< 500 成员，使用List

成员数目过多，但是还不至于需要用到过滤的功能。

< 5000 成员， 使用FilteredList

成员数目已经很多了，需要用户进行过滤之后再展示。

> 5000 成员，MandatoryFilter

成员数目非常庞大，必须得过滤之后再展示。

下面的C#代码演示了如何动态设置这个属性：

if ( estimatedCount < 100 )     attribute.InstanceSelection = InstanceSelection.DropDown;
else if ( estimatedCount< 500 )     attribute.InstanceSelection = InstanceSelection.List;
else if ( estimatedCount< 5000 )     attribute.InstanceSelection = InstanceSelection.FilteredList;
else     attribute.InstanceSelection = InstanceSelection.MandatoryFilter;

Cube Design Best Practices / 立方体设计最佳实践

1. Avoid including unrelated measure groups in the same cube

避免在一个立方体中包含不关联的度量组

2. Avoid having too many parent-child dimensions in a cube, especially when the dimension contains custom rollups or unary operators

避免在一个立方体中含有大量父子维度，尤其是维度含有自定义的Rollup或者一元操作符(?)

3. Do set AttributeHierarchyEnabled to False on any cube attributes that are below the level of granularity of all measure groups in the cube

当Attribute比立方体中所有度量组的粒度层次还要低的时候，可以设置它的AttributeHierarchyEnabled为false

4. Avoid having very big intermediate measure groups or dimensions of many-to-many dimensions

在多对多的维度中不要含有过大的度量组或者维度

5. Consider using a processing query when using the scheduled polling option of proactive caching

当使用定时Proactive caching时候考虑使用processing query

6. Avoid creating multiple measure groups that have the same dimensionality and granularity

不要创建相同广度和力度的度量组

7. Do put each distinct count measure into a separate measure group

在每个度量组中创建各自的计算度量

8. Do set any explicit default members of role-playing dimensions directly on the cube dimensions

在立方体维度上直接设置role-playing维度的默认成员

9. Do reuse dimensions multiple times in a cube instead of creating duplicates of a dimension

在立方体中重复利用已有的维度而不复制一个相同维度

10. Avoid having cubes with a single dimension

切勿创建只有一个维度的立方体

11. Do use the smallest numeric data type possible for measures

尽可能为度量使用最小数据类型

12. Do ensure that the Collation property of OLAP objects is consistent with the collation of the relational source data when dealing with multilingual data

使用多语言数据时候，保持OLAP对象中的Collation和对应数据源中设置是一致的

13. Do materialize referenced dimensions

物化(?)引用维度

14. Avoid using linked dimensions, especially if your cube has outline calculations (custom rollups, semi-additive measures, or unary operators) or scripts

避免使用外接维度，尤其是立方体含有计算成员或者脚本

Partition Design Best Practices / 分区设计最佳实践

1. Avoid having partitions with more than 20 million rows

分区数据控制在2000万条以内

2. Avoid having many small partitions in a measure group

同一度量组内不要含有太多小分区

3. Do set the Slice property on partitions that are ROLAP or partitions that use proactive caching

如果使用ROLAP模式或者Proactive caching，设置Slice属性进行切片

4. Consider partitioning a distinct count measure group along the dimension used most often to query the distinct count measure

如果分区的度量组含有计算度量，记得同时包含使用次数最多的维度

Aggregation Design Best Practices / 聚集(聚合)设计最佳实践

1. Consider having aggregations for each partition of significant size

对每个分区进行合适大小的聚集

2. Do include the granularity attribute of the time dimension in aggregations for measure groups with semi-additive measures

对含有semi-additive度量的度量组，记得聚集时包含时间维度上的相关粒度的属性

3. Do not build too many aggregations

不要建立太多聚集（< 500）

4. Consider sharing aggregation designs between partitions of similar size and usage

对相似大小和使用特性的分区上使用公用相同的聚集（一般每个度量组有三种聚集即可）

5. Consider creating separate aggregation designs for partitions with significantly different size or usage

对不同大小不同使用的分区，创建单独的不同策略的聚集

6. Do use a lower performance gain with regular aggregation design and a higher performance gain with usage-based optimization

一般聚集设计的时候，采用获取较低性能的方式，而对基于使用率优化时选择高性能获取方式

7. Consider setting AggregationUsage to Unrestricted on high-use attributes that are not the key of a dimension and not in a hierarchy

对于不是key或者不在层次中的属性，设置它的AggregationUsage为Unrestricted以便系统在聚集时会优先考虑它

8. Avoid Setting AggregationUsage to Full on Large Attributes

在大属性上避免设置AggregationUsage属性为Full

9. Do set member and row counts accurately for the partition when designing aggregations

设计聚集时候精确提供成员和记录行总数

10. Consider including the granularity attribute of the intermediate dimensions of many-to-many dimensions in aggregations

在含有多对对的维度设计聚集时候，考虑包含中间维度上的粒度属性

11. Do include in aggregations the granularity attribute of dimensions that contain unary operators or custom rollups

如果在维度上包含一元操作符或者自定义Rollup，在聚集时候要考虑它的粒度属性

12. Avoid creating aggregations that are larger than one-third the size of the fact data

聚集大小不要超过事实表大小的三分之一

13. Do remove aggregation designs that are not applied to any partitions

删除不适合任何分区的聚集

14. Do not create aggregations that contain multiple attributes from the same attribute relationship chain

不要给来自同一属性关联组内的多个属性重复创建聚集

15. Consider including in aggregations only those attributes with rigid relationships to their dimension keys

只包含那些刚性的维度建立聚集

你可能对下面的文章感兴趣

• Analysis Services 2005 OLAP设计最佳实践
• 为WordPress博客加速——清理你的主题文件
• 非常喜欢现在Google主页的设计