日期维度应该是雪花的吗？

Question

每当星型模式中的某些数据在日级别可用，而其他数据在月级别可用时，我应该创建单独的月维度，还是在某些情况下更倾向于将月级别数据附加到日级别日期维度（例如总是在每月的第一天）？

示例：

假设我有一个在日期级别存储订单的事实表，附加到在日期级别存储日期的日期维度。

+---------+      +-----------+
|  Fact   |      | Dim       |
| Orders  |      | Date      |
+---------+      +-----------+
| FK Date |------| FullDate  |
+---------+      | MonthNr   |
                 | Year      |
                 +-----------+

解决方案 1：雪花日期维度，创建单独的月份维度

现在我有一些每月需要包含在模型中的销售目标。直观地说，我的反应是在月级别上创建一个维度，就像雪花一样。然后，我的日期维度将包含该月维度的 FK，因此层次结构是明确的。

+---------+      +-----------+
|  Fact   |      | Dim       |
| Orders  |      | Date      |
+---------+      +-----------+      +-----------+      
| FK Date |------| FullDate  |      | Dim Month |      +----------+
+---------+      | Year      |      +-----------+      |  Target  |
                 | Month     |      | Year      |      +----------+
                 | FK Month  |------| YearMonth |------| FK Month |
                 +-----------+      | Month     |      | Target   |
                                    +-----------+      +----------+           

请注意，事实表中的确切键集（以及日期维度中的其余列）可以通过多种方式实现，具体取决于最佳、混合或标准雪花的选择

解决方案2：将月份级别的数据附加到当月的第一天

最近我看到越来越多的人将目标附加到原始日期维度，在月初：

+---------+      +-----------+
|  Fact   |      | Dim       |      +----------+
| Orders  |      | Date      |      |  Target  |
+---------+      +-----------+      +----------+
| FK Date |------| FullDate  |------| FK Date  |
+---------+      | MonthNr   |      | Target   |
                 | Year      |      +----------+
                 +-----------+

当数据模型主要用于客户直接访问时（例如交叉表或数据透视表中的即席分析），最后一个数据模型尤其适用。对我来说，它仍然感觉违背了规律。

在月份级别上对这些目标进行建模的最佳方法是什么？选择一种方法而不是另一种方法时，有哪些重要考虑因素？

更新

正如@SebTHU 在他的回答中指出的那样，可以在 SSAS 内部建模（并且，正如 @Nick.McDermaid 在 Cognos 中所添加的那样）一个单一维度（仅限日期），其中，由于对层次结构的了解，目标与月级别相关，而订单与日级别相关，如下所示：

+---------+      +-----------+
|  Fact   |      | Dim       |
| Orders  |      | Date      |      +-------------+
+---------+      +-----------+      | Fact Target |
| FK Date |------| FullDate  |      +-------------+
+---------+      | MonthKey  |------| FK MonthKey |
                 | MonthNr   |      | Target      |
                 | Year      |      +-------------+
                 +-----------+

剩下的问题是如何在关系数据库（比如 SQL Server）中实现这一点——非唯一属性不允许使用外键。那么可以采用解决方案 2，并在多维数据集加载期间重新建模吗？还是采用解决方案 1（最终没有 Dim Month 和 Dim Date 之间的 FK 关系）并在多维数据集加载期间将两个维度“合并”为一个维度是否更好？

Answer 1

简单的答案，不。创建一个单独的月份表（不要打扰雪花）以用于第二个数据集市 - 这将使第一个数据集市的日期维度保持简单。此数据集市上的汇总和聚合就像第二个数据集市不存在一样简单。否则使用解决方案 2 ;-)。

顺便说一句，我总是喜欢在下雪时保持现有维度。

Answer 2

可以（无论如何在 SSAS2014 中）在 Date 维度中创建 Month->Day 层次结构，然后让维度在不同粒度属性上分割两个度量值组。

因此，您需要将包含订单的度量组与 Day 属性上的 Date 维度相关联，但将包含 Targets 的度量组与 Month 属性上的相同维度相关联。

结果将是目标在个别日子没有价值，但在月（以及层次结构中比月更高的任何东西，例如季度或年，如果你想要那些）。我认为通过阅读您的问题，这就是您正在寻找的结果？

编辑： SSAS 默认行为是在更高级别的维度成员上定义的度量对所有维度成员的子项显示相同的值。因此，您的每月目标 1000 也将在该月的每一天显示为 1000。使用计算成员很容易覆盖它