多维模型SSAS Cube

时间:2015-09-01 09:01:43

标签: database-design ssas cube olap-cube

最近开始在SSAS中实现多维模型。 OLTP有一个表,用于存储基于Attribute和Entity列的多个度量。属性列具有各种维名称。如果连续属性值为Dim1,则实体列将具有Dim1的值。同样,“属性”列可以具有任何维名称,其值将位于“实体”列中。我们还有一些表,其中有多个Attributes和entity列。例如Attribute1和Attribute2。两者都是维度名称,entity1和entity2存储它们各自的值。措施还取决于尺寸的顺序。具体而言,表格存储在不同压缩下计算的风险值(VAR)值。在基金和行业压缩时计算的VAR与在行业和基金压缩下计算的VAR不同。 OLTP将其存储为attribute1(Fund),Attribute2(Sector)和Entity1(Fund' s值)和Entity2(Sector' s值)。在caluse [where where attribute1 =' Fund'和attribute2 =' Sector']或[其中attribute1 =' Sector'和attribute2 ='基金']
如何在多维数据集中有效建模?

我目前的方法是创建一个Fact表,每个维度都有一个单独的非空外键列。如果我需要保存dimension1的数据,那么它的外键值将保存在dimension1(这是Dimension1表的外键)中,其他维键(dimension2,dimension3 ..)将指向相应维度的N / A值。

如何改进这种方法?优点和缺点?如何在立方体设计中实现尺寸的排序

1 个答案:

答案 0 :(得分:0)

我不确定你的意思是什么:

  

创建一个Fact表,其中所有维度都作为外键   指向实际维度表

但这听起来像是错误的方法。

对于切片事实表的每个维度,事实行应该具有单独的非NULL外键列。 (即使偶尔有一些指向特定维度中的特定“未知”成员)。换句话说,每个事实行应代表来自每个(相关)维度的特定成员的交集。

从它的声音来看,你的问题是你的源系统遭受数据库反模式:通过允许添加属性来使属性“灵活”,只需创建一个带有(AttributeName,ObjectThisIsAnAttributeOfID,AttributeValue)的行,而不是将此关系定义为具有主表的FK的表结构。

从这个数据结构中产生立方体设计结果需要进行大量的数据分析和转换:

  1. 有多少个不同的属性值?每个不同的值都是多维数据集中的维度。
  2. 对于每个属性,有多少个不同的实体值? 他们共享一个共同的数据类型吗?你知道未来的价值吗? 可能?这需要针对每个维度进行
  3. 对于具有属性值的每个“事物”(事实):做它们 一直有所有属性的值?或者是子集的 属性?
  4. 您可能会发现(考虑到所涉及的工作和时间),您只能为现有属性的一小部分建模。

    如果我误解了,请随时发表评论或回复更多细节。

    但从它的声音来看,基本问题是你的源系统没有对“事物”和它们的属性之间的关系断言任何规则。 OLAP多维数据集设计涉及在初始设计时强烈声明这些规则。