与性能相关的SSAS多维数据集设计问题

Question

我已经确定了3个维度和1个度量表。 它将是星型模式。

我的测量组将有Count（A / C编号）。 每个维度表都有一个与A / c编号类型的一对一关系的查找表。

DIM1 ID1 CAT1

DIM2 ID2 CAT2

DIM3 ID3 CAT3

事实 A / C号码 计数（A / C） ID1 ID2 ID3 以上只是一个例子， 当然，实时有15个维度表（一对一关系），事实表和数据接近百万条记录，这就是我们需要提出最佳设计/性能的原因。

我知道FACT / Measure总是汇总或衡量业务量，在这种情况下，度量是计数（A / c号）。

问题： 1.我是否需要在事实表中添加A / c号码。 记得在事实表中添加A / C号，事实上是巨大的/大的。 好还是坏，表现明智？

1. 我是否创建了类似于事实表的其他Factless事实表，但事实表只有count（a / c数字），Factless事实表也会有实际的a / c数字，其维度值也是如此...这将是一张大桌子。 好还是坏，表现明智？

2. 我是否创建了额外的列（a / c编号）以及维度表上的查找值，因此事实表会有事实..好的还是坏的，性能明智的？

3. 此外，我需要知道，维度流程/部署更快（或应该更快）事实流程/部署更快（或应该更快）以及实时优先选择。

我想知道实时选择哪个选项，或者是否有更好的解决方案。 请让我知道!!

Answer 1

如果我理解正确的话，那你就是在谈论一个不确定的维度。

这是一种常见做法，在我看来是解决问题的正确方法。

例如，假设我们有一个订单明细表，每个订单行的粒度为一行。像这样的东西： 请访问此链接查看图片，因为我仍然无法在论坛中发布图片： http://i623.photobucket.com/albums/tt313/pauldj54/degeneratedDimension.jpg

如果您的度量是订单数量，则从上面的示例中得出结果：2 请检查以下链接：

• Creating Degenerated dimension

如果您还有其他问题，请与我们联系。

亲切的问候，

保

Answer 2

您将自己的音量描述为＆＃34;接近百万条记录＆＃34;。在过去5年中建立的任何服务器（甚至台式机或笔记本电脑）上处理这听起来都微不足道。

因此，我不会限制设计来解决想象中的性能问题。