我目前正在设计一个基于星型模式的仓库，并对处理未来和过去数据的技术有一些疑问。
源系统中的某些事件也可能是将来的事情。例如，某位雇员正在申请将来的假期。该企业希望看到将来的数据以进行规划，但是从本质上来说，这可能会发生变化。
- Q1：您是否将未来的数据带入仓库？
- 第二季度：如何在更新发生变化时管理更新？
如果过去的数据发生变化，例如，由于几天后发生的错误而对销售进行修改，您以类似的方式处理仓库中的数据吗？
bingning128 回答：数据仓库更新数据
将其视为“过去的”和“未来的”数据有点误导-因为正如您所说的，有充分的理由说明，在初次上传到数据仓库后，可能需要更新这两种类型的数据。
我建议将这些数据视为“计划中”和“实际”休假。希望这样做，将使两种类型都可能与数据仓库中的加载以及稍后的更新有关变得更加清楚。
这是因为计划休假和实际休假可能都需要报告和分析（因此将两种类型的数据加载到DW中都是相关的）。此外，您的计划休假可能会发生变化，并且在初始上传后可能需要在源系统中更正您的实际休假（因此在DW中更新这两种类型也很重要）。
计划休假数据应该进入数据仓库吗？
这是主观的，并且完全取决于您的用例。
广义上讲，数据仓库的目的是有效地存储和查询大量数据。实际上，这通常是出于业务报告（例如，月末，年末）和分析的目的。
因此，请假休假数据是否与上述内容相关，取决于您的组织和用户的背景，以及对将数据存储在数据仓库中有（或没有）业务价值的理解。
当源数据更改时如何管理更新？
已阅读this blog post by James Serra。尽管过时了（发布于2011年），但总体上这些概念仍然是最新的，并且确实很好地解释了一些关键概念。
文章中有两种将数据加载到数据仓库中的方法：
- 完全提取：所有数据完全从源系统中提取。由于此提取反映了源系统上当前可用的所有数据，因此自上次成功提取以来，无需跟踪源数据的更改。
- 增量提取：仅提取历史中特定时间点发生更改的数据。该时间点可以是上一次提取的时间，也可以是业务事件，例如会计期间的最后一天。为了识别这种增量变化，必须有可能标识出自该特定时间点以来的所有变化信息。
完全提取很简单，但是对于大量数据而言效率很低。
增量提取更为有效，但需要一种方法来识别增量-即源数据中的条目是新的，或者自上次上传以来已更改或删除。詹姆斯的文章概述了一些解决方法。这个article on change tracking in SQL Server可能也有帮助。