企业经常需要把数据集成到很多操作系统中，可以通过以下两个技术实现：

　　提取、转换和加载过程(ETL)：采用这种方法，企业首先要建立一个集中式数据仓库，然后为利益相关的数据构建一个全局模式。对于每一个操作系统，企业将采用某种形式的ETL过程把数据实例转换成全局模式，然后再把他们加载到集中式数据仓库中。

　　数据联合(Federate)：这是数据集成的另一种方法，企业也需要像ETL方法所述的那样构建一个全局模式，只是把数据保留在它原来的存储位置。企业会采用MetaMatrix或Aqualogics这样的数据联合器，而不再自己构建一个集中式数据仓库。查询(包括更新)可以提交给联合器进行处理。反过来，联合器会计算出哪些查询或更新操作需要运行在哪个操作系统，才能对提交的命令反馈回来正确的结果。

　　接下来，我们来看看这两种处理方法都有哪些优缺点，而我们应该采用哪一种方法才能高效达到我们的目的。

　　数据元素: ETL更适合频繁查询的“热数据”

　　如果使用ETL过程进行数据集成，当一个数据元素被提取出来时，数据转换过程才开始了。而在数据联合过程中，数据转换是发生在查询时间里。如果某个数据元素经常要被查询，只进行一次转换的成本显然要低的多，所以用ETL过程更合适。反过来，如果某个数据元素从来不会被查询或者查询的次数很少时，使用联合过程择更明智。总之，对于经常发生查询更新的“热数据”最好采用ETL的解决方案。

　　索引：数据联合更难优化

　　联机事务处理对于数据索引的要求往往与数据仓库对查询索引的要求明显不同。因此，在ETL处理方法中，数据仓库作业负荷的优化可以与联机事务处理的优化分离开，在不同的硬件上进行。而数据联合处理方法中，数据库管理员必须在同一个数据库中平衡两者的作业负荷，这要比分别优化各自的作业负荷更复杂。

　　资源管理：想要商业智能查询响应更快捷就用ETL过程

　　在数据仓库中，商业智能用户可以享用到专门用于优化索引查询的工具。相比之下，数据联合技术对联机处理事务执行的优先程度没有那么高，这导致了对商业智能查询的反应很慢，建议你在等待某个查询结果时可以先出去喝杯茶吃个饭。

　　模式转换的复杂性：ETL过程的连接处理更少

　　很多数据仓库都采用星型模式或雪花模式。而大部分的联机事务处理系统都采用非雪花模式。因此，全局模式随着操作模式的不同而发生显著变化。这种情况下，全局模式中的某个记录很可能时来自操作模式中的几个不同的记录。因此，联接器必须在每次查询的时候都执行该连接。而ETL系统则只是在加载时进行一次连接。所以，在模式映射过程变得复杂的时候，ETL处理方法表现更优异。

　　并发控制：数据联合冲突面临挑战

　　在ETL系统中，必须定期从操作系统抽取数据元素。这些数据元素一旦加载到中央数据仓库，其存储属性就变为只读了。因此，在ETL过程中基本上不会有锁争用的情况发生。而数据联合过程会在操作系统中把商业智能查询和事务处理混合起来执行，其结果就是导致出现锁争用和其他资源冲突。

　　时效性：ETL过程必须处理过时数据问题

　　数据仓库加载过程有一半时间其数据基本都是过时的。而联合器却能够随时更新信息。为了解决这个缺陷，一些新的数据仓库系统(如，Vertica)允许数据加载过程和查询过程并行处理，这个程序称为trickle loading。

　　映射：数据联合无法处理某些转换

　　对于操作型数据库来说，常常要获取客户信息，例如客户姓名等。在ETL过程中，无论你什么时候需要某个客户资料，你总能在某个包含了从操作系统名到全局模式名映射的稳定增长表中找到其资料。如果某个客户名不存在，就可以添加关于该客户的新记录。因此，姓名映射是由一个映射表所支持的一种全局性操作。不过，这难以保证能够把相同的映射应用到每个操作系统，除非各个系统保留和更新相同的映射表。而联合器没有相应的工具进行来对状态信息来说必须的映射功能。因此，很难同时执行某些转换。

　　总结：ETL过程在很多情况下更胜一筹

　　总而言之，几乎所有企业都使用ETL方法来进行数据集成。数据联合市场相对来说要小得多。当数据源非常多(例如，有超过5000个数据源)而且商业智能用户在任何特定时间里只会用到其中很小的一部分时，数据联合应用才显出优势。在极端情况下，凭据每个数据元素在更新或删除之前的访问量为零，这时我们最好让数据保留在它来源地。相反，当大部分的数据元素都会被利用若干次时，这也是更常见的情形，ETL过程还是我们的首选。