我目前正在为一家金融公司设计一个数据仓库。虽然大量的流程是相当标准的，但我遇到了一个数据事件的问题(我相信只存在于金融领域(，这些问题会影响许多行及其随时可能发生的历史记录。
为了更好地解释这个问题。假设我们有一个账户 A，并且发生了其他 2 个月 4 笔影响其余额的交易，将其从 10000 更改为 20000。 当我运行该月的报告时，它将显示派生该值的活动。 现在它变得困难了，在我回溯一个影响平衡的交易一个月后，将其从 20000 更改为 15000。
运行报告 在那之前，回溯日期应该告诉我原来的 20000，但在回溯交易之后应该告诉我 15,000。
为了更好地说明，请参阅下面的数据。
9 月和 10 月的交易
10 月 28 日追溯交易，9 月 13 日 500 美元
以及 11 月 8 日为 9 月 17 日的追溯交易，以贷记 -50 美元
╔═════════════════╦═════════════════════════╦════════╦══════════════════╦═══════════════╦═════════════╦═════════╗
║ Key_Transaction ║ SK_TransactionEffective ║ Amount ║ PrincipleBalance ║ SK_ReportDate ║ SK_AsOfDate ║ Version ║
╠═════════════════╬═════════════════════════╬════════╬══════════════════╬═══════════════╬═════════════╬═════════╣
║ 1 ║ 12/09/2018 ║ -1000 ║ 20000 ║ 12/09/2018 ║ NULL ║ 1 ║
║ 6 ║ 13/09/2018 ║ -500 ║ 19500 ║ 13/09/2018 ║ 28/10/2018 ║ 2 ║
║ 2 ║ 16/09/2018 ║ -50 ║ 19950 ║ 16/09/2018 ║ NULL ║ 1 ║
║ 7 ║ 16/09/2018 ║ -50 ║ 19450 ║ 16/09/2018 ║ 28/10/2018 ║ 2 ║
║ 12 ║ 16/09/2018 ║ 50 ║ 19950 ║ 16/09/2018 ║ 8/11/2018 ║ 3 ║
║ 3 ║ 1/10/2018 ║ 250 ║ 20200 ║ 30/09/2018 ║ NULL ║ 1 ║
║ 8 ║ 1/10/2018 ║ 250 ║ 19700 ║ 30/09/2018 ║ 28/10/2018 ║ 2 ║
║ 13 ║ 1/10/2018 ║ 250 ║ 20200 ║ 30/09/2018 ║ 8/11/2018 ║ 3 ║
║ 4 ║ 6/10/2018 ║ -1200 ║ 19000 ║ 6/10/2018 ║ NULL ║ 1 ║
║ 9 ║ 6/10/2018 ║ -1200 ║ 17800 ║ 6/10/2018 ║ 28/10/2018 ║ 2 ║
║ 14 ║ 6/10/2018 ║ -1200 ║ 19000 ║ 6/10/2018 ║ 8/11/2018 ║ 3 ║
║ 5 ║ 22/10/2018 ║ 100 ║ 19100 ║ 22/10/2018 ║ NULL ║ 1 ║
║ 10 ║ 22/10/2018 ║ 100 ║ 17900 ║ 22/10/2018 ║ 28/10/2018 ║ 2 ║
║ 15 ║ 22/10/2018 ║ 100 ║ 19100 ║ 22/10/2018 ║ 8/11/2018 ║ 3 ║
║ 11 ║ 29/10/2018 ║ -1000 ║ 16900 ║ 29/10/2018 ║ NULL ║ (New)1 ║
║ 16 ║ 29/10/2018 ║ -1000 ║ 18100 ║ 29/10/2018 ║ 8/11/2018 ║ (New)2 ║
╚═════════════════╩═════════════════════════╩════════╩══════════════════╩═══════════════╩═════════════╩═════════╝
现在，当我运行 9 月份的报告(2018-09-01 至 2018-09-30(时，我应该是 V1 或当SK_AsOfDate为 NULL 时
如果我运行 10 月份的报告(2018-10-01 至 2018-10-31(，我的最新记录应该是 (11(，本金余额为 16900
而我目前的本金余额(截至2018-11-09(应计算为(16(的余额，PB为(18100(
我已经添加了尝试处理版本控制问题的SK_AsOfDate，但我仍然在努力寻找一种简单而优雅的方式来实现这一目标"截至 2018 年 9 月 30 日，我的余额是多少，将忽略 V2 和 V3 更改。
我想把这件事做好，幸运的是，我走得不太远，所以欢迎提出建议！我很乐意添加尽可能多的字段，使此过程易于从另一端报告。
在财务(和其他一些(交易数据中，你基本上有两个时间维度。
交易日期- 代表交易发生的实时时间，但由于技术原因，您可能会稍后收到交易。
预订日期- 这是交易进入您的预订系统的时间戳。有时称为输入日期。
关于交易日期，交易可能发生为延迟到达，相反的预订日期根据定义始终是最新的。
两个时间维度允许两种不同类型的报表。
预订日期报告通常用于预订目的(因为它在历史记录中永远不会更改(。交易日期报表在时间上更真实，但在上个月的两天内运行它可能会产生两个不同的结果(由于交易在第二天延迟到达(。
看起来这是迟到的事实的一些问题。 问题是您稍后要报告的内容。您想以某种方式报告新值还是只是忽略新到来的事实。
第一步是确定能够通知差异的业务密钥。 金额或本金余额Key_Transaction是否随时间变化，或者只是新记录的到来？尝试创建表的快照以找到值在时间上的差异，以创建良好的业务。
可以在这里找到一些好主意：http://www.disoln.org/2013/12/Design-Approach-to-Handle-Late-Arriving-Dimensions-and-Late-Arriving-Facts.html
什么是源数据库？在 Sql Server 中，您可以尝试使用变更数据捕获(必须在服务器上启用(或在 ETL 中创建上述机制。
我猜你提到的表不是低级颗粒，而是某种基于其他表的聚合。尝试询问技术上落后于什么，并深入挖掘以找到它的工作原理。
我认为您的情况可以通过"快照"表来解决。在金融世界中，截至 2018-10-31 或截至 2018-11-09 的详细说明很重要，您需要为每个"截至"保留一份数据副本，每个组织看起来都可能不同，就像您的每周一样。频率由您决定。当您拥有这组数据时，无论最终状态如何，您都可以返回并获得准确的报告。
创建这些"快照"表的方法基本上是在每个"截至"日期创建一个带有"快照日期"的事实数据表副本，这个快照日期又名"截至"可以在您的报告中用于查看您需要查看的数据版本。
让我知道这是否解决了您的问题。