Changing Data Capture

Changing Data Capture (CDC) (捕获数据变化) 是设计和开发有效的 ETL 应用的前提。CDC 需要对不同的数据源、数据库进行分析以采用不同的 CDC 方案。常用的 CDC 有下面几种途径：

• Audit 字段,  一个设计良好的 Transactional 表应该包括 Audit 字段，这些 Audit 字段通常包括：EnteredDate (记录输入时间), ModifiedDate (记录修改时间), DisabledDate(记录失效时间), EnabledFlag(记录有效标志)和 UserID (用户 ID)等，这些字段可以很容易地用于 ETL 的增量处理中过滤出数据源中的最新记录。 很遗憾并不是所有的数据源都包括这些 Audit 点段，比如说文本文件、XML 文件或者其他的不是规范设计的文件等。
• Log (日志)文件，大多数的数据库系统都有操作日志文件，通过特殊的方法或者第三方软件我们可以从这些日志文件中我们可以获取对记录级别的修改记录。但是使用这种方法有两个问题：1）访问Log 文件非常的不安全，Log 文件往往很大，包含了系统恢复所需要的很多信息。2) 有些个 Log 文件设置成不包含对级别的修改。基于以上的考虑，使用 Log 文件跟踪被修改的记录不是一种特别有效和安全的方法。
• Trigger (触发器)，对于数据库管理系统来说，我们可以在表上建立 Insert, Update 或者是 Delete 的触发器，将被修改的记录存放在另一个数据库中。但是使用 Triger 也有相应的问题：1) 性能影响。使用Triger 将消耗大量的系统资源，尤其是在一个很大的表上建立触发器将会非常明显地影响系统的性能。2) 需要数据源的访问权限。在ETL 处理的数据源往往分布在不同的服务器上，我们有时候并没有用户访问权限去建立这些触发器。
• Full Compare (全部比较),  如果以上的方法都行不通，我们只好采用逐记录，逐字段的比较，对记录数不是很多，或者属性不是很多的 Dimension 表来说，这也许不是最坏的方法。

对使用　SQL Server 2008 作为数据源的 ETL 处理，可以使用它的新功能，Changing Data Capture (CDC)，它的基础虽然也是利用 SQL Log, 但要比直接存取 SQL Log 要安全的多，我会在另一篇文章中介绍这个新功能。

以上部分是转的 原URL：www.bridata.ca/blog/?p=621

其实还可以使用TASK机制 融合了Audit和Log还有Trigger的优势

需要在数据源头进行的一些小的修改 讲每次数据的灌入都PK数据映射到一张TASK表里 连带着Audit标致性字段一并输入到TASK表中 当Trigger会明显影响到数据库性能的时候 用程序来完成Trigger的动作也是一种选择。

还有这种方式在Product项目上使用中的 就是对所有的表中的ModifiedDate 进行Query 将结果集批量对DW进行 Insert/Update的操作。