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

我正在使用Analysis Services，并且在设计维度时，我不知道构建自然层次结构有多远。设计维度层次结构：自然或不自然

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

该场景正在追踪作业。这项工作有许多属性都是静态的，但债务人属性（即支付发票的人）可以在工作过程中改变。因此，层次结构是这样的

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

所以维度中有一些与工作随后由债务人（至极缓慢变化）进行作业名称（维键）的静态属性（S）开始多层次的底端。

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

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

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

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

此外，惊叹号设计警告在Visual Studio中如此戏剧化，以至于看起来非常不正常。

其他设计师在这些情况下做什么？你走多远以避免不自然的层次？

来源

2010-02-04 Craig

伟大的问题！ – ajdams 2010-02-05 22:43:08

我不确定要理解你的例子，但是你的设计是否可以简化为在其维度中排除债务人？ – momobo 2010-02-06 09:44:37

由于他们希望层次结构通过债务人，因此无法将债务人真正分解到新维度。债务人真的是工作的一个属性，所以从建模的角度来看，它需要在维度上。 – Craig 2010-02-09 00:08:23

在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中的维度。当然，如果你想加载更新，密钥将需要保持静态，虽然如果你有时间做一个完整的刷新，这可能不是必需的。

来源

2010-02-16 22:12:01 ConcernedOfTunbridgeWells

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

回答

相关问题