多维模型 SSAS Cube答案

【问题标题】：Multidimensional model SSAS Cube多维模型 SSAS Cube
【发布时间】：2015-09-01 09:01:42
【问题描述】：

最近开始在 SSAS 中实现多维模型。 OLTP 有一个表，它存储基于属性和实体列的多个度量。属性列有各种维度名称。如果连续属性值为 Dim1，则实体列将具有 Dim1 的值。同样，属性列可以具有任何维度名称，其值将在实体列中。我们还有一些表，其中有多个属性和实体列。例如属性 1 和属性 2。两者都是维度名称，entity1 和 entity2 存储它们各自的值。度量还取决于维度的顺序。具体而言，表格存储在不同压缩下计算的风险值（VAR）值。在基金和部门压缩计算的 VAR 与在部门和基金压缩计算的 VAR 不同。 OLTP将其存储为attribute1（Fund）、Attribute2（Sector）和Entity1（Fund's value）和Entity2（Sector's value）。使用 where caluse [where attribute1 = 'Fund' and attribute2 ='Sector'] 或 [where attribute1 = 'Sector' and attribute2 ='Fund'] 查询也很容易
如何在 Cube 中有效地建模？

我目前的方法是创建一个 Fact 表，其中每个维度都有一个单独的非空外键列。如果我需要保存维度 1 的数据，则其外键值将保存在维度 1（维度 1 表的外键）中，其他维度键（维度 2、维度 3 ..）将指向相应维度的 N/A 值。

如何改进这种方法？优点和缺点？立方体设计中如何实现维度的排序

【问题讨论】：

正如 SebTHU 所说，如果您可以编辑此内容以说明您尝试建模的各种业务概念是什么，这将很有帮助。您提到了部门、基金和 VAR——还有更多，还是只有这些？我认为当您需要建模的是业务流程和概念时，您可能过多地基于 OLTP 数据库结构，但是在讨论通用维度时很难说清楚。
另外，如果您认为了解当前表的结构会有所帮助，您能否向我们展示实际的结构（如果您需要匿名，请使用修改后的名称）而不是描述它们？
@Jo Douglass：问题已编辑。我们有几个指标，如 ImpliedVol、Vol、VAR 等，维度是 Fund、Symbol、Sector、Subsector、Country、Masterfund 等。我们需要一个事实表，这些指标可以存储用于不同的压缩，例如 Fund、Symbol、Fund 和符号、符号和基金、部门和基金。当我们进行资金压缩时，其他压缩（维度）的外键将指向该维度的 N/A 值。在获取数据时应如何维护（基金和符号）或（符号和基金）的顺序？
创建事实表时，您需要考虑粒度 - 如果您有一个存在于不同粒度的度量（当您说不同的压缩时听起来像，并且需要留下一些维度键为空），那么您将需要在不同的事实表中进行多个度量。如果您可以将每个度量拆分为最低粒度，则可以避免这种情况，仅将其保持在该级别，然后将其汇总在立方体中。您列出的业务概念之间是否存在任何自然层次结构？
@Jo Douglass：度量值不能在不同的grain之间聚合。自然层次结构确实存在。一个层次结构是基金 -> 符号。我们仍然无法将 Symbol Var 数相加得到 Fund var 数。

标签： database-design ssas cube olap-cube

【解决方案1】：

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

创建一个以所有维度作为外键的事实表指向实际维度表

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

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

从听起来你的问题是你的源系统受到数据库反模式的影响：通过允许临时添加属性来使属性“灵活”，只需使用 (AttributeName, ObjectThisIsAnAttributeOfID, AttributeValue) 创建一行，而不是将此关系定义为具有主表 FK 的表结构。

需要大量的数据分析和转换才能从这个数据结构中得到一个立方体设计结果：

有多少不同的属性值？每个不同的值都可以作为多维数据集中的一个维度。
对于每个属性，有多少不同的实体值？它们是否共享一个共同的数据类型？你知道未来的价值观是什么可能？这需要针对每个维度进行
对于每个具有属性值的“事物”（事实）：它们是否始终具有所有属性的值？或者对于一个子集属性？

您可能会发现（考虑到所涉及的工作和时间）您只能对现有属性的一小部分进行建模。

如果我误解了，请随时发表评论或回复更多详细信息。

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

【讨论】：

通过“创建一个将所有维度作为指向实际维度表的外键的事实表”，我的意思是，对于每个可能具有事实值的维度，都有一个单独的列（外键）。你也提到了这一点。大多数时候，一个或两个外键将指向一个相关值。其他外键将指向未知或 N/A 值。让大多数外键指向 Unknown 值可以吗？我为属性的每个不同值创建了单独的维度。
第 1 点：为属性的每个不同值创建了单独的维度。第 2 点：对于每个属性，我们有不同的实体值。数据类型在所有维度上都是相同的。第 3 点：没有事实不具有所有属性的值。 Facts 具有一维或二维的值，或者可能是三个。其余维度将指向未知（N/A）值。事实是针对单个维度或维度子集计算的。
有了这个模型，我又面临一个问题。事实表的数据（度量）取决于用于计算度量的维度的顺序。使用 Dimension1 然后 Dimension2 计算的度量将不同于使用 Dimension2 然后 Dimension1 计算的度量。将来，度量可能会使用三个或四个维度进行计算。应该如何捕获维度排序？我是否应该创建一个不同的表来存储维度的排序，而主事实表有一个指向订单捕获表的外键？
感谢您的澄清。根据您所写的内容，我认为大多数维度 Unknown 将正确反映您源中的数据 - 但它不会为最终用户提供非常丰富的多维数据集。这是原始数据的问题，而不是您的多维数据集设计问题。听起来好像不止一种“事物”记录在您的源“事实”表中。您是否考虑过将它们分成多个集合（一个肯定具有属性 A、B 和 C；另一个肯定具有属性 D、E 和 F）？
回应您的最后一条评论：抱歉，具有任何“顺序”的维度的概念在 OLAP 中没有意义（在关系数据库设计中，列具有有意义的顺序）。我认为您正在尝试对在 OLAP 中不起作用的东西进行建模。没有更多细节，我真的不知道该建议什么。也许编辑您的问题并返回到您的数据的具体内容？