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

Question

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

示例：

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

+---------+      +-----------+
|  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   |
                                    +-----------+      +----------+

请注意，事实 table 中的确切键集（以及日期维度中的其余列）可以根据最佳选择以多种方式实现，混合或标准雪花

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

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

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

只要数据模型主要用于客户直接访问（例如交叉或数据透视 table 中的临时分析），就会特别使用最后一个数据模型。对我来说，还是有违背常理的感觉。

在月级为这些目标建模的最佳方法是什么？选择一种方法而不是另一种方法的重要考虑因素是什么？

更新

正如@SebTHU 在他的回答中指出的那样，可以在 SSAS 内部建模（并且，@Nick.McDermaid 补充说，在 Cognos 中也是如此）一个单一的维度（只有日期），由于了解层次结构，目标与月级相关，而订单与日级相关，如下所示：

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

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

Answer 1

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

顺便说一句，我总是喜欢在雪花化时保持现有尺寸。

Answer 2

可以（无论如何在 SSAS2014 中）在您的日期维度中创建月->日层次结构，然后让维度在不同的粒度属性上切分两个度量值组。

因此，您会将其中包含订单的度量组与 Day 属性中的 Date 维度相关联，但将带有 Targets 的度量组与 Month 属性中的相同维度相关联。

结果将是目标 ~~在个别日期~~ 没有值，但在月（以及层次结构中高于月的任何事物，例如季度）上有值或几年，如果你想要的话）。通过阅读您的问题，我认为这就是您要寻找的结果？

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

覆盖它很容易

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

Should a Date Dimension be snowflaked?

sql

ssas

date

dimensional-modeling

示例：

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

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

更新