Sql server 设计维度层次结构：自然还是非自然

我使用的是AnalysisServices，在设计维度时，我不知道要构建自然层次结构要走多远

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

场景是跟踪作业。作业有许多属性，这些属性都是静态的，但债务人属性（即谁支付发票）可以在作业过程中更改。所以层次结构是这样的

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

因此，在维度中有许多层次结构，它们从作业的静态属性开始，然后是债务人（慢慢变化），作业名称（维度键）位于底部

因此，我们现在要做的是“归化”这些层次结构，为每个出现在层次结构中的债务人创建“假”属性，该层次结构是其上属性的组合。e、 g.对于上面的第一个示例，Debtor-level属性的键为Manager和Debtor-id。对于最后一个示例，经理级别的键为Manager和Office，而债务人级别属性的键为Office、Manager和Debtor。然后我们隐藏所有这些属性，以便它们仅在层次结构中使用

因此，这使我们的维度变得更加复杂，但我们确实从查询的额外性能中获益。这通常是一个明显的进步。除了复杂性之外，我们经常遇到问题，因为我们现在有“债务人”的多个版本，属性的关键不是债务人的id。因此，如果我们想改变某些级别的行为，这会影响钻取和报告操作，并使某些类型的计算更加困难

我们使用的客户端是Reporting Services、Excel和Office Web组件

有人告诉我，在SQL 2005的早期版本中，涉及非自然层次结构的复杂查询可能会导致服务器完全陷入困境，这也是我们竭尽全力避免非自然层次结构的另一个原因

另外，感叹号设计警告在VisualStudio中是如此引人注目，以至于使用不自然的层次结构似乎是一件非常糟糕的事情

---

在这种情况下，其他设计师会怎么做？如何避免不自然的层次结构？

在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中的维度。当然，如果您想加载更新，密钥需要保持静态，但如果您有时间进行完全刷新，则可能没有必要这样做。

我不确定是否理解您的示例，但是，您的设计是否可以简化，将债务人分解到其自己的维度中？无法将债务人分解到新维度，因为他们希望层次结构通过债务人。债务人是工作的一个真正属性，所以从建模的角度来看，它需要在维度中。我刚刚在MS论坛上找到了以下线索，这至少表明我并不孤单！