我正在使用SQL Server 2012和SSIS设计数据仓库。源系统处理酒店预订。预订分为两个表，标题和标题行项。事实表将位于订单项级别，其中包含标题中的一些数据。
我面临的挑战是预订（及其订单项）会随着时间的推移而改变。
一个例子是：
最后三点是关键，我不确定如何在不查找记录并更新记录的情况下更新该行。该公司希望跟踪更新和删除。
我拒绝更新，因为：
我愿意接受任何建议！
其他问题（以下来自ElectricLlama的回答）：
答案 0 :(得分：2)
如果您在源代码行和事实之间有效地存在1：1，并且您将源系统预订代码存储在事实中（没有针对该系统的维度建模规则），那么我建议您进行两步加载过程。
根据预订日期（或您认为是主要事实日期的任何内容）删除/插入最近x天的预订，
根据所有已更改的来源预订代码删除/插入（您当然必须事先知道）
您只需要考虑这对未来开发的约束，即当您需要添加其他源系统时，您需要保持1：1的事实来源线关系，以保持您的加载过程一致。
我从未更新dataload进程中的事实记录，但始终删除/插入某个数据域（即该域可能落后20天或源系统预订代码）。这实际上与更新相同，但也负责删除。
关于审核来源的变化，我建议你把它写到一个不同的表中，而不是主要的事实，因为它的目的是审计，而不是分析。
识别源中已更改记录的要求（用于数据加载和审计）意味着您需要在源中创建触发器和日志表，或者如果可能，则需要启用本机SQL Server CDC。
不惜一切代价避免使用SSIS查找组件，因为它完全无效，肯定无法在4500万行上运行。
坚持使用'插入/删除数据部分'方法，因为它有助于SSIS插入/删除（以及无法有效更新或查找）
回答后续问题：
实际上是1：1的关系 我所得到的是，您对未来需要集成的系统没有任何可见性，或者对未来升级到现有源系统的可能性有任何可见性。这种1：1映射引入了设计约束（它实际上不是约束，更像是框架）。考虑到这一点，任何 new 系统都不需要遵循这种特定的负载设计，只要它的数据一致地到达事实。我认为实施这个1：1设计是一个好主意，只是试图考虑任何缺点。
如果您的来源有可靠的修改日期，那么您很幸运，因为您可以进行差异加载 - 仅加载更改的记录。我建议你：
审核表：
最简单，最准确的方法是在源系统中实现触发器和日志，并将其与星型模式完全分开。
如果您确实希望将此捕获作为加载过程的一部分，我建议您在临时表和现有审计表之间进行比较，并仅编写新的审计行，即审计表中的预约X最后修改日期为2 4月，但是登台表中的预约X最后修改日期是4月4日，因此将此更改作为新记录写入审计表。请注意，如果您执行每日加载，则不会记录其间的任何更改，这就是我在源中建议触发器和日志的原因。
这更多的是确保你的加载过程中有一个重叠的窗口，这样如果过程失败了几天（就像他们一直这样），你就会有一些意外情况，它会无缝地选择回程一旦它再次运作起来。这在您的情况下并不是那么重要，因为您有一个修改日期来识别差异变化，但通常我会选择一个交易日期并删除，比如说7个结束日。这意味着我的加载过程可以持续6天，如果我在第7天修复它，一切都将正确重新加载，无需额外的干预来加载中间日。
答案 1 :(得分：0)
我建议删除一个标志并更新而不是删除。你的表现也会更好。
这将使您能够分析预订在一段时间内的变化情况。您需要确保在所有分析中使用此标志，以确保不会产生混淆。