设计维度层次结构:自然或不自然

Question

我正在使用Analysis Services,在设计维度时,我无法确定构建自然层次结构还有多远.

我的意思是我添加了所有真正的属性关系.因此,大多数层次结构都是自然的,但最常请求的层次结构是3个或更多级别,中间级别是缓慢变化的属性.

该方案是跟踪工作.该工作有许多属性都是静态的,但债务人属性(即谁支付发票)可以在工作过程中发生变化.所以层次结构看起来像这样

 - Manager -> Debtor -> Job Name
 - Director -> Debtor -> Job Name 
 - Office -> Debtor -> Job Name 
 - Office -> Manager -> Debtor -> Job Name

因此,在维度内,有许多层次结构以作业的静态属性开始,后面是债务人(缓慢变化),底部是作业名称(维度键).

因此,我们目前所做的"自然化"这些层次结构的是为每个债务人创建"假"属性,这些属性出现在层次结构中,该层次结构是其上方的属性的组合.例如,对于上面的第一个示例,Debtor级别属性将具有Manager和Debtor id的密钥.对于最后一个示例,Manager级别将具有Manager和Office的密钥,而Debtor级别属性将具有Office,Manager和Debtor的密钥.然后,我们隐藏所有这些属性,以便它们仅用于层次结构中.

因此,这使我们的维度变得更加复杂,但我们确实在查询中获得了额外性能的好处.这通常是一个显着的进步.除了复杂性之外,我们经常遇到问题,因为我们现在有多个版本的"债务人",而属性的关键不是债务人的身份.因此,如果我们想要更改某些级别的行为,这会影响钻取和报告操作以及使某些类型的计算更加困难.

我们使用的客户端是Reporting Services,Excel和Office Web Components.

有人告诉我,在SQL 2005的早期版本中,涉及非自然层次结构的复杂查询可能会导致服务器完全绑定,这是我们为避免不自然的层次结构而付出很大努力的另一个原因.

此外,感叹号设计警告在Visual Studio中如此引人注目,以至于拥有不自然的层次结构似乎是一件非常糟糕的事情.

在这些情况下,其他设计师会做些什么？你要走多远才能避免不自然的等级制度？

Answer 1

在 SSAS 多维数据集上缓慢变化的维度中进行层次结构的方法是合成一个伪层次结构，其中实际的键隐藏在幕后，但只是将属性显示为键一样。

Office     Manager    DebtorKey  Debtor      JobKey   Job Name    From        To
Scunthorpe Bloggs     101        Scarper&Co  2001     Fixit       2010-01-01  2010-01-31
Scunthorpe Bloggs     102        Bodgett     2002     Fixit       2010-02-01  9000-01-01

该层次结构是在原始缓慢变化的维度上构建的，并用于建立属性关系。您确实希望层次结构中的级别具有正确的属性关系。IIRC 这些对于多维数据集进行“自动存在”优化（在命中事实表之前纯粹从维度解决非空性）是必要的 - 这就是为什么当未建立这些关系时多维数据集会很慢。

在构建多维数据集之前，您可能必须将层次结构应用于 SQL 中的维度。当然，如果您想加载更新，密钥将需要保持静态，但如果您有时间进行完全刷新，这可能没有必要。