预订系统的事实表/加载解决方案是什么类型？

Question

背景

我正在使用 SQL Server 2012 和 SSIS 设计数据仓库。源系统处理酒店预订。保留在两个表之间拆分，即标题和标题行项目。事实表将位于行项目级别，其中包含标题中的一些数据。

问题

我面临的挑战是预订（及其订单项）会随着时间而改变。

一个例子是：

• 预订已创建。
• 房间被添加到预订中（作为标题行项目）。
• 客户到达并将食物/饮料添加到他们的预订中（更多订单项）。
• 将付款添加到预订中（作为行项目）。
• 房间随后可能会被取消并从预订中移除（订单项被删除）。
• 房间中的人数可能会发生变化，从而影响该订单项。
• 预订状态在其生命周期的某个时刻从“临时”变为“已确认”。

最后三点是关键，我不确定如何在不查找记录和更新记录的情况下保持该行的更新。企业希望跟踪更新和删除。

我拒绝更新，因为：

1. 根据我所读到的有关 Fact 表的内容，一旦将行写入表中，重新访问它们并不是一个好习惯。
2. 我可以使用查找组件执行此操作，但行数超过 4500 万行，这是最好的方法吗？

问题

1. 我应该选择哪种类型的 Fact 表或加载解决方案？
2. 我是否应该更新记录，如果是的话，我怎样才能最好地做到这一点？

我愿意接受任何建议！

其他问题（根据 ElectricLlama 的回答）：

1. 事实确实与来源有 1:1 的关系。您谈到了未来发展可能受到的限制。您能否详细说明我将面临的限制类型？
2. 每个订单项都有一个修改（和创建日期）。您是说我应该从事实表中删除自上次导入以来已修改的所有记录并重新添加它们（听起来合乎逻辑）？
3. 如果对 2 的回答是“是”，那么出于审计目的，我会在删除当前事实记录之前将它们写入单独的表吗？
4. 在第一点中，您提到根据预订日期删除/插入最近 x 天的预订。我可以理解插入新预订。我只是想了解我为什么要删除？

Answer 1

如果您在源代码行和事实之间实际上具有 1:1 的比例，并且您将源系统预订代码存储在事实中（没有针对此的维度建模规则），那么我建议您采用两步加载过程。

1. 根据预订日期（或您认为是主要事实日期的任何日期）删除/插入最近 x 天的预订，

2. 根据所有已更改的源预订代码删除/插入（您当然必须事先知道这一点）

您只需要考虑这会对未来的开发造成什么限制，即当您要添加额外的源系统时，您需要保持与源线的 1:1 事实关系，以保持加载过程的一致性。

我从未在数据加载过程中更新过事实记录，但总是删除/插入某个数据域（即，该域可能落后 20 天或源系统预订代码）。这实际上与更新相同，但也负责删除。

关于审计源中的更改，我建议您将其完全写到不同的表中，而不是主要事实，因为它的目的是审计，而不是分析。

识别源中更改的记录（用于数据加载和审计）的要求意味着您需要在源中创建触发器和日志表，或者如果可能启用本机 SQL Server CDC。

不惜一切代价避免使用 SSIS 查找组件，因为它完全无效，而且肯定无法对 4500 万行进行操作。

坚持使用“插入/删除数据部分”方法，因为它使 SSIS 能够插入/删除（并且无法有效地更新或查找）

回答后续问题：

1. 实际上是 1:1 的关系 我的意思是，您对未来需要集成的任何系统一无所知，也不知道对现有源系统的未来升级可能会做什么。这种 1:1 映射引入了设计约束（它不是真正的约束，更多的是框架）。想一想，任何新系统都不需要遵循这种特定的负载设计，只要它的数据始终如一地到达即可。我认为实施这种 1:1 设计是一个好主意，只是尝试考虑任何缺点。

2. 如果您的来源有可靠的修改日期，那么您很幸运，因为您可以进行差异加载 - 仅加载更改的记录。我建议你：

   1. 将所有最近修改的记录（最近 5 天？）加载到临时表中
   2. 根据记录键执行删除/插入。在执行 SQL 任务中在 SSIS 中进行删除，不要将数据流输入到逐行删除语句中。

3. 审核表：

最简单、最准确的方法是在源系统中实现触发器和日志，并将其与星型模式完全分开。

如果您确实希望将此捕获作为加载过程的一部分，我建议您在暂存表和现有审计表之间进行比较，并且只写入新的审计行，即审计表中的保留 X 上次修改日期为 2 4 月，但暂存表中的预留 X 上次修改日期是 4 月 4 日，因此将此更改作为新记录写入审计表。请注意，如果您执行每日加载，则不会记录两者之间的任何更改，这就是我建议在源中使用触发器和日志的原因。

1. 事实上删除/插入记录

这更多是为了确保您在加载过程中有一个重叠的窗口，这样如果该过程失败了几天（就像他们总是那样），您会有一些意外情况，它会无缝地选择该过程一旦它再次工作。这在您的情况下并不重要，因为您有一个修改日期来识别差异更改，但通常例如我会选择一个交易日期并删除，比如 7 个尾随天。这意味着我的加载过程可能会中断 6 天，如果我在第 7 天修复它，一切都会正确重新加载，而无需额外干预来加载中间天。

Answer 2

我建议有一个已删除的标志并更新它而不是删除。你的表现也会更好。

这将使您能够对预订在一段时间内的变化情况进行分析。您需要确保在所有分析中都使用此标志，以确保没有混淆。