oracle - 日期维度的代理键？

Question

有两种思想流派:

1. 使用代理键，最好采用以下格式:YYYYMMDD，因为这将始终是连续的。

2. 消除日期维度代理键并使用实际日期。

我向专家提出的有关维度建模的问题是:

1> Which design would you prefer and why?

2> How should we handle unknown values in each of the cases, Can we simply place 
   NULL in Fact table for unknown dates as Foreign Key can be NULL (if not why)?

3> If we need to partition fact table on date column, how would we achieve that 
   in case 1.

我倾向于使用实际日期并使用 NULL 来表示事实表中的未知日期，因为可以在不需要查看维度表的情况下完成与日期相关的事实验证。

Answer 1

按照你问的顺序:

1. Kimball 对日期的代理键大加赞赏，但我还没有看到支持这种方式的令人信服的技术论据。转换为 YYYYMMDD 格式意味着您必须转换日期或连接日期维度才能进行日期算术。这两种方法都有多种方式可以通过 来破坏查询计划。
   日期时间在 SQL Server 上为 8 个字节，在 Oracle 上为 (IIRC) 7 个字节，因此它比整数代理项要宽一些，但我不知道除非你有非常大的数据量，否则你不会再看到这个论点的优点。优化器只是在幕后将日期视为数值。

2. 我对一种或另一种类型的“特殊”值有要求。根据您希望它们如何排序，您可以使用不同的值。过去我曾多次使用过这个方案:

   • 1800-01-01 代表“上一个”。除非您需要早于此日期的日期，否则这将在开头排序。
   • 9000-01-01 表示“正在进行”。这将在最后排序。
   • 9100-01-01 表示“未知”。这将在最后排序。
   • 9200-01-01 表示“错误”。这将在最后排序。
     

3. 任何支持范围分区的 DBMS 平台(包括几乎所有主流 RDBMS 平台)都可以在日期或整数分区键上正常工作。

我不建议对数据仓库中的未知值使用 NULL，因为它需要外连接才能使用数据。这会影响查询计划的效率，并且给没有经验的玩家带来数据陷阱。数据仓库中的 NULL 键在很多方面都是不好的。

NULL 键值的另一个问题是大多数临时报告工具不能很好地处理连接中的 null 键。通常，他们会使用内部联接，因此键列中包含 NULL 的行将会中断。

对于大多数其他维度，您将使用代理。这将维度与源数据解耦，并允许您将新数据源引入系统，而不会破坏现有数据。

在某些情况下，使用自然键作为维度键可能会很有用。例如，ISO 货币代码或帐号。在前一种情况下，3 字母代码足够小，因此将其用作 key 的开销很小，并且编码方案(通常)在所有数据源中通用。在后一种情况下，代码通常是数字且足够短，无论如何都可以容纳一个整数，并且通常在整个组织中通用。

这样做的主要好处是报告专家可以使用他们自己的查询来操作数据。它使直接处理数据的人员更容易阅读表格。