数据集成系统是为用户访问多个有效的、异构的数据源提供统一的应用系统，从而使用户真正将注意力集中在他们想要的特定结果上，而不必关心如何获得这些结果。
数据集成系统是一个三元组，其中：G是全局模式，S是数据源模式, M为全局模式和数据源模式之间的映射。在数据集成系统中，在创建虚拟的全局模式及其与下层数据源模式之间的“映射关系”后，用户在全局模式上提出“查询请求”，系统将查询请求按照映射关系转换为对应下层数据源模式的“子目标” (称之为“查询重写”)，而后进入子目标的“执行”，重写和执行过程中都可能存在“优化”，子目标并不是直接运行在下层数据源系统内，而是通过一个“封装器”间接地和下层数据源交流，最后系统将每个子目标执行结果整合为统一结果，按照用户要求或系统设置格式提供给用户。
二、主要问题
数据集成系统遇到的主要问题集中在建立语义联系，查询重写，查询优化和查询执行中，核心和基础是建立语义联系。
语义联系是多模式应用(数据集成、语义Web、数据移植、实体整合等)中的一个基础性问题, 在数据集成系统中它是用户查询和下层数据源数据建立联系的唯一桥梁。
使用最多的语义联系方式是采用映射, 其终极目的就是获得一个正确的、满足应用要求的映射。映射语义就是对两个模式之间的元组所实施的约束，决定了在给定映射下哪些元组对可以共存。一个映射能否满足特定的主题要求必须具备三个条件：清晰语义，对不完整信息的适应性和允许模式异构。映射有三个重要的属性：查询回答能力，映射推理能力和映射整合能力。
显然，实际中的映射是不精确的，也是不确定的。因此目标就是要找到一个“最好”的映射，或者“最有效”的映射。这个研究结论对于指导寻找映射非常有价值。目前对于映射性质的研究，主要是基于有明确定义的模式之间的映射，对于在集成应用系统中存在音乐、拓片、电影等无具体的模式定义的情况仍然需要进一步研究。
模式只是一个象征性符号，并不能完全表达出它所代表对象的全部含义，所以完全自动地建立语义联系是不可能的。建立语义联系在现实中大多通过人工完成，但这个过程是一个劳动力密集型且容易出错的工作。
模式是指和某个结构联系的元素的集合，映射是两个模式中有映射关系的规则集合，意味着一个模式中某些特定的元素映射到另一个模式中某些特定的元素。一个映射关系必须存在两个部分：映射的元素和映射元素之间的映射描述。
匹配就是找到分布在两个不同模式中的元素之间的某种映射关系的行为，可以理解为将两个模式作为参数输入，输出结果是它们之间的映射关系的函数，输出的结果为匹配结果，每个匹配结果中的元素都表示一个输入参数中有特定的元素和另一个输入参数中某些特定的元素存在逻辑上的对应关系，这些对应关系的语义就是通过映射元素的映射描述来表达的。所以关键是寻找匹配方法，而这个方法的目标应该是自动的、精确的、广泛适应的。映射可以分为两个阶段：首先找到下层数据源模式与全局模式之间的映射；其次在全局模式中描述这些映射。
显然无法利用数学公式或者数学方法来对两个模式之间的对应关系进行计算，只能利用模式本身所蕴涵的语义和数据来寻找二者之间的对应关系。尽可能多地挖掘这些信息，并对这些信息正确加以运用是匹配的核心。从目前研究看，使用到的信息可以分为几类：1)模式信息, 包括模式的结构、关系类型、注释和描述、元素名称、元素数据类型、约束条件、关键字属性、外键属性、命名空间、所在域等；2)实例/内 容信息；3)辅助信息, 包括字典、先前的成功映射、用户输入、应用领域规范等。
匹配算法除了利用不同种类的信息外，也对这些信息采用了两种不同的使用方式：一种只根据单一信息标准完成匹配，如以名字的相似程度作为标准；另一种则综合多种信息标准来完成匹配。这些匹配算法找到的匹配结果就是映射，考虑到精度问题，多数作为候选映射供手工选择或调整，它们可能带有0 ～ 1之间的某个权值作为匹配精度。为了提高匹配的精确度，有些匹配方案会将多个不同匹配算法得到的匹配结果再进行综合整理后提供给用户。
查询重写
查询重写是利用语义联系，将建立在全局模式上的查询用(且仅用)下层数据源的资源描述来重新表述。全局模式采用不同的描述方式对应着不同的查询重写方式，前面提到LAV方式引入了一个关键难题：利用视图来回答查询的问题。该问题在不同的应用领域有不同的侧重点, 它有三种输出结果:最终查询结果、查询计划和查询重写形式。
数据集成中的查询重写有几个特点需要注意：第一是涉及的视图数量非常多；其次视图定义中可能包含非常复杂的谓词逻辑；第三数据源的数据往往是不完整的，即数据源只包含部分满足视图定义的数据。
查询算法主要如下：
（1）Bucket algorithm：算法主要的想法是先单独考虑每个子目标，确定哪些视图和子目标相关，从而达到显著减少重写个数的目的。算法分为两个阶段，第一阶段确定bucket中的视图；第二阶段根据bucket中的视图写出查询重写表达式。在第一阶段中算法为每个子目标创建一个bucket存放与该子目标相关的视图。算法通过两个步骤确定视图和子目标相关：1)检查视图定义和子目标参数表是否存在某种一致性；2)检查查询和视图是否兼容。两个条件均满足则把视图放到bucket中，重复数据只出现一次。第二阶段中组合这些bucket中的视图。每次从每个bucket中取出一个视图组合形成一个候选的查询重写(不重复)，检测它是否为查询的重写形式，最后将所有检测通过的重写结果联合起来就是原查询的最大包含查询重写，但不一定是等价重写。Bucket算法的优点是在算法的早期就充分利用信息去掉了很多后面需要考虑的候选重写，其缺陷是第二阶段所产生的笛卡儿乘积数仍然很多，而对每个重写均要进行包含检测。
（2）Inverse rules algortihm：算法思想是构建一个由反转视图定义后形成特殊规则的集合。反转规则是将LAV的描述方式变换成GAV的描述方式，查询可以按照反转规则直接展开，返回的是最大包含重写。算法最大的优点是概念非常清楚而且很容易模型化，另外获得最大包含重写的时间开销是相对于视图和查询大小的多项式。该算法的缺点有两个：反转规则会包含一些对查询没有意义的视图，需要在算法中利用单独过程来消除无用视图；没有充分利用已经物化的视图，从而丧失了很多计算上的优势。
数据集成系统的下层数据源有几个特点：
1)下层数据源的数据可能冗余，相互覆盖，甚至冲突；
2)数据源是自治的,其状态是动态变化的，故优化器不能获取足够的统计信息，而且历史统计数据很难具有直接的参考价值；
3)数据源分布在广阔地理空间中，其传输延迟、异常等无法把握，即使采用了最好的执行方案，也完全可能因为数据延迟而变得不可行；
4)下层数据源数据表现形式多样结构化，半结构化，甚至无结构，故其执行查询的能力也大不相同等。
正是这些特点使得查询优化和执行变得非常困难，传统的优化技术已经无法适应这样的环境。另外，数据集成的查询优化和传统数据库查询优化目标并不相同，后者是从整体上来优化查询的执行，而前者由于应用了大量的数据源，重写后形成的子查询数量非常多，对这些计划评估的开销巨大，不是每一个计划都去执行，可能在执行的过程中用户对已经返回的结果满意了就会终止执行，或者计划执行过程中达到了某种资源限制或阈值而结束执行，所以尽快获得第一批结果非常重要，优化的目标不是要求整个查询的代价最小，而是要尽可能快地返回尽可能多的结果。这也造成了数据集成的优化和传统数据库优化有着本质上的区别。
查询优化是非常关键的步骤，一个没有优化的计划也许根本就不能获得结果，优化方法可分为本地执行方案和分布式(多节点)执行方案两类，这两类又可细分为适应性优化策略和非适应性优化策略。
由于数据集成环境中数据源的远程分布、自治等特点，使得非适应性优化并不能从根本上提高执行效率，优化方案必须随着环境变化而作出相应调整，这就是适应性优化方案，是目前研究得最多的，也应该是最有前途的方案。不管是本地执行的优化还是分布在网络中多个节点执行的优化均可以采用适应性策略。
三、发展方向
近来研究者们已经将优化的目光放在网络分布式执行方面了，但几个方面仍然需要足够重视：第一是主动优化的概念。除了被动利用各数据资源的数据和能力，也需要主动挖掘网络和数据资源的潜力，如将部分数据内容复制到其他节点以加速访问(数据分布问题)，或者对某些功能强大而且持久有效的节点赋予更多的访问优先级等。第二是挖掘传统技术潜力。比如建立辅助手段来保证传统优化数据的可用性。第三是运用分布式计算。比如异地计算将结果传回本地而不是把数据取回本地等。
有更多idea，欢迎关注公众号（老司机聊数据），评论区给我们留言！
一文讲透数据治理难点与应对策略（建议收藏）
Web3.0 到底是什么？
全国一体化政务大数据体系建设指南（建议收藏）
关于SAP-MDG的主数据治理理论概述
区块链技术对数据治理的一些思考及启发
数据治理CDGA考试重点70条（吐血整理！建议收藏！）
主数据治理工作八大难点
什么是数据供应链管理
浅谈数据分析中的数据清洗方法策略