Dimensional和cube developme数据模型

Question

我创建了一个结构与AdventureworksDW环境中的财务报告设计类似的维度模型，其中每个帐户的值在事实表中保存为单个值列，维度为数据提供其语义。

该模型中有超过一千个列，因此适用于添加或删除其他列。这是一个非常好的设计博客：http://garrettedmondson.wordpress.com/2011/10/26/dimensional-modeling-financial-data-in-ssas/

虽然这个模型适用于查询维度模型，并且有支持这个模型的维度分析的例子，但我担心这个模型不是标准的多维数据集开发或数据挖掘，似乎喜欢更宽的表格。

问题： 此设计是否被归类为Entity-Attribute-Value（EAV）？

使用多个事实表的设计会更好吗？如此多的宽事实表（最多10个），每个列最多200-300列，但行数更少。

我应该期望更宽泛的表更多的性能问题？

Answer 1

你说得对，特定的设计被认为是EAV模型。

通过使用这样的设计，您可以轻松地添加新的帐户，层次结构等。您不需要更新您的模型。

我不会推荐每一项措施一列。大部分行中的大多数帐户都为空。也有这样的设计，即使只需要检索其中的一个，也需要阅读所有措施。

我们在我们的立方体中大量使用帐户维度。不幸的是像共享成员这样的东西在EASbase中很难像SSAS那样处理。

您需要创建一个父子维度的帐户维度，并且您还需要像平常一样在事实表中拥有此维度的维度。 通过使用帐户维度，您可以很好地支持时间平衡功能。使用SSAS的时间平衡功能应该比自定义MDX代码更快。

我们正在将一元运算符和父子关系转换为公式。 所以基本上我们有正常的公式，并且层次结构中的父母也可以用作公式。 最后，我们正在扁平化层次结构。所以不可能在帐户维度中向下钻取。我们仅将帐户维度用作计算引擎。 也可能有适当的层次结构，但我们决定不同时混合自定义汇总成员和一元运算符。

共享成员以及作为自定义汇总成员实现的所有公式。