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