给定1 TB关系数据库，当前位于SQL Server中。数据仓库需要数据库主要部分的“复制”。仓库数据不应超过24小时。关系数据库的大小使得每晚完成全部负载是不切实际的。我应该如何设计我的关系数据库以支持仓库的增量装载？用于向数据仓库增量“导出”的数据库设计
数据库的一小部分（< 0.1％）在一天内发生变化，主要是插入。日内更改不是必需的，只是最终的快照。
保持关系数据库的性能是首要关注的问题，其次是不浪费不必要的空间。
有很多方法可以处理增量拉动。有各种方法和场景写的卷，所以我可以给你一个方法的例子。
对于插入，使用单调增加键来追踪每次拉动的高水位标记。在提取数据之前，请检查目标表中是否存在最大值，然后从值大于此值的源中提取值。
对于更新，将您的增量以“上次修改”时间戳为基础。在每批结束时，您需要记下最新的时间戳，并将其存储在可供您为下一批次提取的位置。
删除在增量中更难。我建议您为每个可删除表保留一个简单的审计表，您可以在其中跟踪那些已删除行的键值。对于每个批次，根据上一批次的高水位标记进行提取，然后在目标系统中采取适用的措施。在某些情况下，如安全港行为，您可以选择从目标系统物理删除行。您可以选择简单地将目标记录标记为不活动。这取决于你设定的规则。
当然，这不是唯一的方法。但希望它为您提供了一些适用的上下文。
您是否需要捕捉日内变化，或者您是否需要每天结束时的当前状态快照？
如果快照可以接受，那么可以在更新每行时为其标记时间，以便您可以识别更改。如果您需要所有日内更改，请查看某种更改数据捕获（CDC）解决方案。有些DBMS具有内置的CDC /日志记录功能，还有第三方工具也可以执行相同的工作。通常他们会在不访问表的情况下直接删除重做日志，从而最大限度地减少源系统上的资源争用。
我同意，CDC这是一个不错的选择。对于Sql Sever 2008 Enterprise或更高版本，请参阅http://www.mssqltips.com/tip.asp?tip=1474 – 2011-03-31 08:06:37
这是一个棘手的领域 - 通常被称为“提取，转换，加载”或ETL。没有正确的答案，我发现的书都没有让人信服 - 拉尔夫金博似乎写出了最有用的书。
作为一个开始，我建议看看为关系系统添加时间戳列;然后您可以创建夜间查询来提取比上次成功运行更年轻的数据。您可能需要创建额外的表来存储传输状态 - 因此源表中的记录应该在传输表中有对应的记录;如果该记录不存在，则表示该记录尚未转出。
如果您的事务数据模型严重标准化，管理依赖关系可能会非常棘手 - 您必须首先迁移所有外键值，这可能导致长依赖链。
如果性能受到影响，您可能需要考虑使用事务数据库的镜像来运行ETL任务 - 这是一个全新的复杂层面。
我会先阅读Kimball的书籍，看看有没有什么想法直接适用。
为什么不简单地在源表中保留两个附加字段：日期时间和记录应该被删除的标志。然后..我正在加载所有来自上一次ETL操作的新记录，新记录插入，修改..修改，以及那些标记为'已删除'的删除，同时在源表中删除。 – John 2012-03-28 12:48:21
@John。如果我理解了你的想法，你可以在其上设置一个逻辑删除标志，并且有一个到期日期，为ETL过程提供足够的窗口来提取已删除的记录。这是一个好方法。我试图找出您是否建议ETL过程也负责删除源记录。如果是这样，我认为在那些外键可能导致删除失败的情况下会有点棘手。相反，我会选择一个意识到源系统的RI结构的收获过程。 – 2012-08-09 07:17:37