我正在使用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和amp;的密钥。债务人。然后，我们隐藏所有这些属性，以便它们仅用于层次结构中。
因此，这使我们的维度变得更加复杂，但我们确实从查询中获得了额外性能的好处。这通常是一个显着的进步。除了复杂性之外，我们经常遇到问题，因为我们现在有多个版本的“债务人”，而且属性的关键不是债务人的身份。因此，如果我们想要更改特定级别的行为，这会影响钻取和报告操作，并使某些类型的计算更加困难。
我们使用的客户是Reporting Services，Excel和Office Web Components。
我被告知在SQL 2005的早期版本中，涉及非自然层次结构的复杂查询可能会导致服务器完全绑定，这是我们为避免不自然的层次结构而付出很大努力的另一个原因。
此外，感叹号设计警告在Visual Studio中如此引人注目，以至于拥有不自然的层次结构似乎是一件非常糟糕的事情。
其他设计师在这些情况下做了什么？你要走多远才能避免不自然的等级制度？
答案 0 :(得分：2)
在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中的维度。当然，如果要加载更新，密钥将需要保持静态，但如果您有时间进行完全刷新，则可能没有必要。