【发布时间】：2013-04-07 20:20:25
【问题描述】：
我正在尝试在确切的时间点重新创建客户的状态。例如，每个客户都有许多可以随时更改的属性（例如，风险评分、最新账单、客户满意度）。
每次客户提交信用申请时，我都希望在提交时查看所有这些特征的价值。随后，我想使用这些值来开发预测模型。
我的第一个想法是创建一个带有有效和到期日期/时间戳的 Type-2 缓变维度，并使用半开连接 time_effective
但是，这些属性中的大多数都是行为维度，需要使用事实表中的历史数据进行复杂的计算。此外，计算值也不能使用范围（0-500 美元、500-750 美元等）进行分组。跟踪每个维度的所有这些属性会导致它爆炸。注意：有些值每天都在变化，有些则在任意时间点变化。
我理想的数据提取如下：
- 信用申请ID#
- 提交时间
- 提交时属性 1 的值
- 属性 2 的值...
- 属性 N 的值
除了信用申请之外，还有其他事实表，我想在其中找到在该事件发生时有效的特征。
有什么建议来处理这个问题？我看到了几种方法：
- 允许维度爆炸
- 创建具有一个或多个属性的单独表，并分别查询具有我感兴趣的属性的特定表
- 在信用申请事实表中追加一列，其中包含我感兴趣的所有属性的“快照”。
其中一些问题在 Kimball 的 ETL 工具包书籍 (pp 190-192) 和他的数据仓库工具包书籍 (187-191) 中进行了讨论。在第 154-157 页，有一个关于“快速变化的怪物维度”的讨论，这似乎非常相关。不过，我在执行这些建议时遇到了麻烦。
【问题讨论】：
-
我真的很喜欢#3。将这些属性视为专门与该应用程序相关的“退化维度”，而不是客户的一般属性。我不确定这个问题是否会在 SO 上得到一个很好的答案，因为它实际上取决于您的最终游戏用例以及您的 DBMS 的强大程度。 DW 应用程序可能会在一段时间内处理 #1（尽管如果您为每个客户存储每日风险评分，它真的会爆炸）...
-
如果源系统（在 OLTP 期间）在事务发生时无法记录值，#3 是否仍然是一个不错的选择？换句话说，它必须在构建事实表时在后处理 ETL 期间添加。你对#2有什么想法吗？这样做的一个可能好处是您可以潜在地以模块化方式构建属性。
-
如果源系统在申请时没有跟踪属性，那么是的，它必须在 ETL 期间添加。 #2 基本上只是为有趣的属性创建一个“独立”的 SCD 表或一组表。在任何情况下，无论您采用哪种方式，无论该快照是对 SCD 的更新还是将数据添加到事实表，您都将在 ETL 过程中生成数据“快照”......
标签： database database-design data-warehouse etl