设计维度层次结构：自然或非自然

Question

我正在使用 Analysis Services，在设计维度时，我永远不确定要构建自然层次结构要走多远。

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

该场景正在跟踪作业。该作业有许多属性，这些属性都是静态的，但债务人属性（即谁支付发票）可以在作业过程中发生变化。因此，层次结构看起来像这样

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

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

因此，我们目前要“自然化”这些层次结构所做的就是为出现在层次结构中的每个债务人创建“假”属性，该层次结构是其上方属性的组合。例如，对于上面的第一个示例，债务人级别属性将具有管理者和债务人 ID 的密钥。对于最后一个示例，经理级别将具有“经理”和“办公室”键，而“债务人”级别属性将具有“办公室”、“经理”和“办公室”键。债务人。然后我们隐藏所有这些属性，以便它们仅在层次结构中使用。

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

我们使用的客户端是 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 中的维度。当然，如果您想加载更新，密钥将需要保持静态，但如果您有时间进行完全刷新，这可能没有必要。