信息集成的首要指导原则是：在用户看来，他们需要的所有数据，应该好像驻留在一个单一的数据源里一样。信息可能在不同的地方，以不同的语义、格式存储，访问方法各异，因之对信息的检索也变得极为复杂。信息集成技术实质上将信息需求者屏蔽于所有这些复杂性之外。用户或代表用户的应用程序可以通过诸如SQL或XML的标准语言或标准网络服务、内容应用程序界面（API），来对数据进行寻址。这样，用户就可以毫无障碍地查看信息，而不用考虑其物理实现过程。
做到这一点可以有两种方法，或者是两种方法的结合。信息集成的两种主要方法是：
(1)通过数据联合进行分布式数据访问；
(2)将数据移动到对应用程序更有效或更一致的位置，这种方法被称为数据合并或数据安排。
分布式访问对应的是企业信息集成（EII）技术，而数据安排对应的是ETL和复制技术。合起来，这些功能构成了信息集成所需要的核心部分。用最简单的话来解释，联合在一个地方接受一个查询，
分布式访问和数据安排都需要底层映射、转换和高速缓存功能。另外，由于同样的数据，根据企业不同的需要，有时需要被集中，有时需要被联合，所以两种方法都需要一套相同的转换和映射功能支持，以保持数据在整个企业的一致性。映射提供了理解不同数据片段之间关系的能力。转换通过对不同表述形式的数据进行转换的功能，将相关数据通过映射进行合并。缓存提供了一个暂时的数据存储，该存储能够通过透明地存储一个结果集的拷贝来改善联合的性能。
这些功能依赖于它们所处运作环境的细节描述。这种描述包括商业含义、关系、位置和技术格式等等。简言之，就是元数据。这些元数据必须是全面和一致的，而且从集成项目的发现和定义阶段，直至联合查询操作的整个过程，都必须是有用的。一套全面而具有逻辑一致性的元数据集，不管它们是物化在单个物理存储器中，还是分布于多个存储器中，对信息集成技术来说都是不可或缺的基础。
信息集成与数据仓库的关系
当今的分层式数据架构是建立在下面的前提基础上的：某个最终用户的查询或报表所需的一切数据都应该集中到单个数据中心，或至少集中到使用ETL功能的单个数据仓库环境中。这样做是为了获得数据的稳定性和一致性，以及确保对数据的访问。
但如何使新的需要（更短的数据延迟、更少的非常用数据存储、对远程和多种数据源的访问）获得支持？答案显然是分布式查询方法。联合功能提供了在不事先对所有数据进行物理移动的情况下，保持单一数据仓库或数据中心逻辑特征的可能性。
这是否意味着要抛弃传统的数据仓库方法？绝对不是！联合功能不能也不应该取代整个数据仓库方法。基于众所周知的性能、一致性和自主性方面的原因，完全联合或虚拟的数据仓库并不值得提倡。联合更应该在某些明确而有限的范围内，为解决具体的商务需要，对现有数据仓库进行扩展或增强。因此，数据仓库的信息集成方法既包括数据安排，又包括数据联合。
1．数据访问
当企业需要结合已经存在于数据仓库中的传统的、历史的或分析的数据来访问具体的实时数据条目时，联合功能可以发挥重要作用。某个主要基于数据中心可提供的历史的、合并处理过的数据的最终用户查询或报表，也需要一些最后一分钟的信息。在传统数据仓库架构中，这些实时数据必须（一般通过一个ODS）不断地送入数据中心。这不仅要求数据中心存储大量的这类信息，而且要求ETL环境必须具有持续吞吐几近实时数据的能力。
在许多情况下，联合提供一个更简单也更上乘的解决方案。当最终用户查询被运行时，对特定信息的简单请求可以被发送到运作系统，结果被返回并与从数据中心检索到的信息相连接。可用这种方式访问的运作系统包括各种基于DB2 Universal Database的关系和非关系数据库以及IBM WebSphere MQ系列和网络服务。利用此功能，不必在中心存储几近实时的数据或让ETL环境处理这种数据。
请注意一个重要的限定：发送到运作系统的查询应该是简单的，并且运
作系统是专为高效处理此类型查询并返回特定信息而设计。这样可限制对运作系统和网络性能的任何影响。联合查询使用标准SQL，标准SQL允许透明使用现有的业务智能(BI)分析工具。这样，现有的BI工具可访问本地和远程的关系和非关系数据。这保护了对现有工具的商业投资，并能充分利用IT开发人员使用这些工具及其基于SQL模式的技能和专长。联合不限于访问实时数据。任何数据都可以这样访问，而不必把数据存储到数据仓库或中心。众所周知，数据仓库中的很多数据之所以在那里，是因为可能被用到。然而，在很多部署中，许多这样的数据（20%～50%）几乎从不被访问。在数据使用不频繁而且已经存在于别处的情况下，联合查询允许在原始位置上访问这样的数据。当数据已成为历史，可能有必要把它保存在数据仓库中，因为仅有的其它副本在备份磁带上。但当所需的数据保存在运作系统数据库中时，联合可允许从数据仓库中消除此数据，而仍支持最终用户的需求。
2．访问非结构化内容
显示了联合扩展数据仓库的另一种方式。在本例中，业务需求
联合又一次显示出它的优点，即它允许在需要时、根据需要对内容进行访问。当运行报告时，子查询被发送到原始内容源并以其最新的形式仅返回所需的信息。
3．数据中心与商务数据仓库的联合
需要反复强调的是，IBM认为，转移用户查询和向纯联合基础架构层报告，从而取消数据仓库和中心，不是一个好主意。虚拟数据仓库被尝试过很多次，大都以失败而告终——未能提供最终用户所需的价值。联合不能替换数据仓库。联合只是扩展了现有的数据仓库概念。
还有第三种对数据仓库可能的扩展，它针对一种在当今业界普遍存在的情况。这就是，在一个公司中存在多个数据仓库：这十分有害，但又普遍存在。这种情况是由兼并、收购造成的，或仅仅是在不同部门中互不相干、未加协调的投资的结果。由于这些分散数据仓库的出现或增长，很快管理层就会想要比较或结合多个数据仓库中的信息。传统数据仓库架构很难满足这样的需求。在这种模式中，方案是设法把第二个数据仓库中的内容加载到第一个数据仓库中，或创建一个总数据仓库，把两个原始数据仓库中的数据都包含其中。所涉及数据的浩瀚数量姑且不论，一个根本性的难题是，要设法创建统一的数据模型，使其涵盖两个源并允许数据从一个数据仓库加载到另一个数据仓库中。
在这种情况下，联合方案又一次提供了简单得多的解决方案。联合查询仅处理需要响应管理层请求的数据子集。不必把一个数据仓库中的数据全部加载到另一个数据仓库中去，从而避免创建至少一个额外数据副本。尽管两个模型间的区别依然存在，联合方案允许随时仅对模型的一个子集，即支持联合查询的部分，逐渐增加侧重。
4．联合还是不联合 另一个潜在的问题是怎样逻辑地、正确地把数据仓库中的数据和远程系统中的数据链接起来。这与设计一个数据仓库的ETL填充流程时必须处理的问题相同。需要同样地详细分析和理解源和它们与目标的关系。正确的数据建模仍十分必要。有时，关系太复杂，或源数据质量太差，而无法进行联合访问。在一些情况下，如果一个人理解填充数据仓库的ETL流程设计，那么他就可以在建立联合查询时重新利用此设计。通常情况下，联合一点也不减少对详细分析或建模的需求。事实上，因为任何所需转换的实时、联机特性，对此过程的要求只会更加严格。 这些需要考虑的问题决定了可用联合扩展数据仓库的环境。当需要访问实时数据以及不是
但是，使用此方案的代价是什么？一个要考虑的事实是联合查询是针对远程源，包括运作系统进行的。可能会有人争辩，这会影响运作的应用程序的性能。但我们可以仅向运作系统发送简单、特定的查询，来减轻这一影响。这与向同一环境发送完整、复杂的最终用户查询是完全不同的。在联合情况下，可预测和管理对性能的可能影响。
显然，联合并不能解决所有的数据访问问题，但是完全能够解决一些众所周知的需求。也可以看到，随着联合工具的改良，企业数据环境更好的集成，使用联合的机会将扩大。我们可以明确地预测网络服务将有能力实时提供更复杂的数据转换和清理，从而扩展联合查询使用的方式。
联合允许从运作系统中将数据作为数据仓库查询的部分读取。如果您已经接受这一可能性，下一个逻辑问题便是联合是否应该用于将数据写回运作系统。解决这个问题的技术已经成熟，但是为了最小化对运行环境内的数据完整性和安全性的潜在影响，应该通过创建和维护这些运作系统中数据的应用程序来解决这个问题。
