2021-数据集成-Lec1-数据集成概述(企业数据集成背景)

Lec1-数据集成概述(企业数据集成背景)

1. 数据集成的需求

1.1. 应用环境图例

1. 多应用系统共存，系统或者交叉互连，或者相互孤立
2. 多操作系统、多数据库系统、多技术平台共存
3. 用户需要在不同系统中切换
4. 数据集成是有不同层次的，下图中的系统是随着企业的发展而不断进行的，也会导致数据的不一致等出现问题。

1.2. 两类集成场景

1. 企业异构数据库范畴下的数据集成
   1. 信息系统应用发展到一定阶段积累了大量封闭、完备的异构数据库
   2. 基于封闭世界的假设
   3. 长时间可能会导致数据库中的数据不一致从而导致脏数据
2. Web多源异构数据源范畴下的数据集成
   1. 随着Web的出现，积累了大量开放、多源异构的数据源
   2. 基于开放世界的假设
3. 集成主要应对的是信息孤岛问题

1.3. 信息孤岛

1. 缺乏不同系统之间的互操作性
2. 交叉公共数据的冗余和一致性问题
3. 各系统的异构性使得难以全局信息分析和处理：每一个接口都是针对自己的应用，而并不会估计其他的应用
4. 数据和数据处理紧密绑定，缺乏柔性，不能快速适应变化

1. 每一个烟囱意味着一个系统，一个烟囱的信息并不会和其他的烟囱有关系。
2. 右图的含义是指将烟囱的底部打通，而使得数据可以互操作并且交互。
3. 将信息孤岛的问题通过数据集成的方案来完成打通。

1.4. 信息化环境的变化

1. 应用软件通过Internet或WAN分布在世界范围
2. 数以百万/千万计的用户，可能存在的突发事件：用户可以在互联网上自由的注册或者登陆，典型的突发事件有双十一抢购等等。
3. 用户和应用程序间的连接是非持久性的和低速的：在强的服务器端也不可能让所有的用户进行同时请求，更多的是将部分逻辑前移到客户端而客户端和服务器端只进行必要的数据连接交换即可。
4. 千差万别的数据表示设备：比如不同硬件设备、操作系统等等
5. 应用程序所需的数据可能分布在不同的机器上：数据在不同的服务器上。
6. 全球化的协同工作：数据在全球各地。
7. 因此很难通过传统的方式来做应用，更多的还要选择进行数据集成。

1.5. 数据集成案例

1.5.1. 集成案例1(并购)

1. 美国家庭互联网接入公司FullServe收购欧洲信用卡供应商EuroCard

2. 上面的公司代表FullServe，下面的公司代表EuroCard
3. 需要数据和业务逻辑的拟算
4. 数据分散的原因以及其影响
   1. 部门或者公司合并时难以及时调整相应的数据库
   2. 当创建数据库时并不能预见公司未来的所有信息需求以及他们今天存储的数据将来可能会有其他的用途
   3. 业务需求扩展：FullServe现有的培训(Training) 数据库在最开始的时候可能是由少数员工发起的一个小项目，用来记录谁参加了某些培训课程。但是，随着公司的发展以及培训和发展部门的创建，这些数据库就需要进行相应的扩展
   4. 大型企业通常有几十个到数百个数据库
5. 关联查询的需求
   1. 员工信息查询
   2. 针对客户服务热线，客户打电话咨询他们从公司获取的任何服务和产品，客户代表需要掌握全部的信息
   3. FullServe要建立一个网站，现有的和潜在的客户应该能够看到FullServe提供的所有产品和服务，并可以选择捆绑式服务
   4. 假设FullServe与其他厂商一起提供一套品牌服务。需要为其他网站提供一个Web服务，单点登录服务
   5. 应对政府的法律法规的改变。FullServe需要知道他们的员工在加入公司之前是否在其竞争对手或合作伙伴工作过：这就需要将用户数据库和简历数据库合并起来
6. 数据分析利用
   1. 把客户服务热线(Helpline)数据库和销售(Sales)数据库中的数据结合起来
      1. 帮助FullServe在早期发现他们的产品和服务中的问题。
      2. 发现不同产品的使用趋势可以使FullServe积极主动地设定和维持库存水平。
   2. 结合培训数据库、客户服务热线数据库和服务(Services)数据库：可能会发现某一地区接到的有关他们服务故障的呼叫超乎寻常得多。分析数据发现，安装服务的代理商并没有参加应有的培训课程。

1.6. 企业信息化发展阶段

1. 在最开始的时候以效率为导向，以流程为核心，只有尽快(效率)让流水线转起来才能产生出价值。
2. 之后以管理为导向，以平台为核心，生产流水线逐渐增多会导致有大量的数据出现，也就会出现数据的交叉和冗余。各个平台也就更需要定期进行数据的一致化处理与集成。
3. 再之后则是以集成为导向，以供应链为核心，体量比较大后则需要对外进行集成(向上集成分销商和向下集成供应商，集成可以理解为有很多个)
4. 最后以规模为导向：规模越大，覆盖面越广，占据市场越大，以网络为核心

1.7. 商业集成的需要

1. 在规模比较大后则需要在功全球化、成本及周期、电子商务和公司间的竞争等方面开展商业集成。

1.8. 信息系统开发工具的选择

1. 基于VB、Delphi、PowerBuilder等开发工具
   1. 数据处理能力强、访问速度快、适用范围广
   2. 可伸缩性和扩展性较差，而且开发工作量大
2. 基于Domino/Notes、Exchange等群件系统
   1. 完善的通信手段和非结构化数据支持能力，可伸缩性和扩展性好，提供安全权限和工作流管理机制，易于安装和维护
   2. 处理结构化数据能力较弱，开发工具缺乏灵活性，不擅长数据的计算、分析、统计，运行效率较低，可开发性差，不利于进行多种复杂应用的集成
3. 基于.net或Java技术，采用Browser/WebServer软件结构(现行主流)

1.9. 企业信息化的挑战

1. 保护已有的投资
2. 将来的不确定性
3. 价值链的集成
4. 技术的整合：基于组件和构件的开发(之前)
5. 重用和团队的开发
6. 多种技术的需求：有限的经验
7. 对于上千万用户的可扩展性

1.10. EAI的优势

1. 增进与客户的联系
2. 增强供应链间的联系
3. 改善内部流程
4. 减少市场化周期

1. SCM：供应链管理是一种集成的管理思想和方法，它执行供应链中从供应商到最终用户的物流的计划和控制等职能。从单一的企业角度来看，是指企业通过改善上、下游供应链关系，整合和优化供应链中的信息流、物流、资金流，以获得企业的竞争优势。
2. ERP：ERM系统是企业资源计划(Enterprise Resource Planning) 的简称，是指建立在信息技术基础上，集信息技术与先进管理思想于一身，以系统化的管理思想，为企业员工及决策层提供决策手段的管理平台。
3. CRM：客户关系管理（Customer Relationship Management）是一种企业与现有客户及潜在客户之间关系互动的管理系统。通过对客户数据的历史积累和分析，CRM可以增进企业与客户之间的关系，从而最大化增加企业销售收入和提高客户留存。
4. EAM 是Enterprise Asset Management 的缩写，EAM系统是指企业资产管理系统。EAM系统是在资产比重较大的企业，在资产建设、维护中减少维护成本，提高资产运营效率，通过现代信息技术减少停机时间，增加产量的一套企业资源计划系统。EAM企业资产管理系统即是面向资产密集型企业的信息化解决方案的总称，也是以企业资产管理为核心的商品化应用软件。

1.11. 常见的EAI需求

1. 信息门户
2. 数据复制
3. 共享的业务功能
4. 面向服务的体系结构
5. 分布式的业务过程
6. 企业到企业的集成

1.12. Automated Business Processes

1. 业务流程自动化

2. 企业应用集成(EAI)

2.1. 企业应用集成(EAI)

1. 实现在组织内、外的各种异构系统，应用和数据之间共享和交换信息和协作的途径，方法学，标准和技术
2. 集成是一种把多个系统的数据和功能组合或连接成一个具有凝聚力的集合的方法
3. 多个系统之间各种互操作的一致性：完全一致也是做不到的。
4. 应用集成是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。
5. 应用集成为应用提供了一种一致无缝的认知和操作模型

2.2. 应用集成的前提

1. 多个模块组成的复合应用，其中的这些模块可以相互调用或进行合作：Java和Python之间等等
2. 理解并保持应用系统之间相互关联和操作：使用转换器来完成转换
3. 数据共享和通讯

2.3. 三个目标

1. 对不同应用中的数据提供访问接口
2. 保证相关信息之间的依赖关系和约束条件
3. 程序互操作：调用对方服务和接口

企业数据集成的三个层面

1. 网络集成(互连，指网络互连)：能够看到彼此存在；语法：协议
2. 数据集成(互通)：彼此交换和理解数据，调用时则需要知道约束；语义：组织格式和含义
3. 应用集成(互连，指应用互连)：可以对业务逻辑做调用，上下文是保留的，调用的时候可以满足结果获得即可；语用：每个语言可所保留有的上下文和场景(成语的背后)
4. 信息安全和网络爬虫

2.4. 技术要求

1. 能提供应用间的互操作性
   1. 信息的有意义交换
   2. 功能服务：资源的动态发现，动态类型检查(对调用参数进行调整)
2. 能提供分布式环境中应用的可移植性
   1. 不会破坏应用所提供的或正在使用的服务：移植过程不应该影响服务的运行
   2. 静态的系统重新部署以及动态的系统重构：需要可以根据情况做动态的重构。
3. 能提供系统中应用分布的透明性：考虑到异构的情况(企业的系统是在不同的时候部署的，不同地区的情况也是不同的)，不应当知道底层的细节
   1. 实现细节：屏蔽底层网络等实现细节
   2. 复杂性

2.5. 应用集成的历史

1. 60年代到70年代：从信息系统开始
2. 80年代：点到点(point-to-point)的集成，信息和数据共享
3. 80年代末和90年代初：基于框架的集成：CORBA、DCOM、MOM
4. 90年代中后期：业务流程集成技术BPI
5. 21世纪以来：B2B与B2C、XML、Web Service(也不能满足大规模调用)、SOA

3. 集成模型

3.1. 集成模型的描述

1. 集成软件的特定方法和结构
2. 对集成模型的关注点(差异点)
   1. 集成难度：实现集成简单性
   2. 可重用性：对于不同配置集成的可重用性
   3. 广泛性：可用集成方法的广泛度
   4. 技术难度：在执行集成的过程中要求的专门技术

3.2. 集成模型种类

1. 表示集成：软件用户界面
2. 数据集成：
   1. 表结构的数据集成
   2. 直接访问软件创建、维护并存储的信息
3. 功能集成：代码级别的软件集成
4. 业务流程集成(强相关的业务逻辑)：商务逻辑
5. B2B集成(弱相关的业务逻辑)：不同贸易协议

3.2.1. 表示集成模型

1. 原本企业已经以后两个信息系统(遗留应用和封装式应用)，每一个信息系统包含数据库和界面(表示)
2. 集成：在这些界面上再添加一个界面(通用表示，信息门户 Window GUI等)

3.2.1.1. 应用场景

1. 为原来基于终端的应用软件提供PC界面
2. 提供一个由多组件合成的应用软件
3. 案例
   1. 为大型机提供windows界面
   2. 为SAP R/3与大型机程序提供统一的HTML界面
   3. 为多个大型机应用程序提供统一的基于Java的界面

3.2.1.2. 表示集成的特点

1. 易于实现：将URL进行嵌套即可
2. 结构简单清楚
3. 性能瓶颈：本来有n个10万的访问量，那么现在新的界面则会有10*n万的访问量。
4. 屏蔽原有接口
5. 功能有限：集成实现不了功能上的扩展

3.2.2. 数据集成

3.2.2.1. 数据集成的目的

1. 批量文件传输：一个一个将数据导入到几种的数据库
2. 开放式数据连接ODBC：如果访问量不大的话，可以使用ODBC的方式直接访问，好处是开放连接可以对数据源进行更新(参数更新)
3. 数据库访问中间件：不是一个数据源，需要屏蔽底层数据库差异
4. 数据转换：部分数据需要转换后才可以入库(规则等)

3.2.2.2. 数据集成模型

1. 此时要完成的集成是一个新的逻辑段，不需要用到原本的界面
2. 直接访问对应的数据的数据库接口

3.2.2.3. 应用场景

1. 多个信息源综合数据进行分析和决策
2. 向多个应用软件提供公共信息源的只读权限：只需要对一个认证方进行沟通，一般是只读，否则修改可能导致不一致性。
3. 以一个信息源的信息来更新另一个数据源：关联更新
4. 案例
   1. 综合sybase、DB2和SAP P/3数据库中的数据
   2. 使用大型机和Oracle的可执行信息系统
   3. 允许其他应用程序在peoplesoft和定制的Oracle数据库中获取数据

3.2.2.4. 数据集成的特点

1. 更广泛的数据访问：文件的数据也是可以(文件方式也是有ODBC的访问接口的)
2. 简化数据库访问：避免从多源多位置访问
3. 方便新数据源的集成
4. 系统逻辑演变的维护工作：原有应用对新系统没有影响，对新系统是透明的，数据集成的应用需要自己维护演化的逻辑。

3.2.3. 功能集成模型

1. 调用远程应用的接口，则需要设计相应的适配器来完成调用
2. 一般是通过消息中间件和分布式对象技术(DOT，Distributed Object Technology)、分布式事务管理(TPM)技术等
3. 不需要了解底层的逻辑

3.2.3.1. 分布式处理中间件

1. 面向消息的中间件：MOM：IBM.MQSeries
2. 分布式对象技术：OMG.CORBA；COM+；J2EE
3. 事务处理监控器：BEA.Tuxedo

3.2.3.2. 应用场景

1. 能够解决前两种方法可解决的问题
2. 要求新软件具有其他程序的功能：新的需求驱动的
3. 在集成中暗含工作流
4. 确保应用间的事务完整性
5. 案例
   1. 获取用户信息，对java程序、大型机程序、Oracle数据库作更新
   2. 把供应商的系统集成到采购系统中

3.2.3.3. 功能集成的特点

1. 集成能力强
2. 更高的重用性
3. 复杂度增加

3.2.4. 业务流程集成模型

1. 工作引擎
2. 业务管理中心的Activity会映射到企业内外部的应用
3. 在业务流程中，商务规则或者表现为条件和限制，或者表现为实施并发、串行等流程中的行为（Activity）节点

3.2.4.1. 业务流程

1. 为在一定时期内达到特定的商业目标，而按照各种商务规则连接起来的业务功能集
2. 具体实现受限于业务功能运行所必须的可用资源，包括业务人员，IT业务应用系统，客户，和商务交往及贸易伙伴等
3. 在工作流的基础上做这个部分

3.2.4.2. 业务流程集成的技术成分

1. 业务流程引擎
2. 资源管理工具
3. 调度工具
4. 审计管理工具
5. 错误管理工具
6. 资源库:业务流程集成层资源库中可存储多种数据对象

3.2.4.3. 应用场景

1. 通过子流程来实现业务流程共享：把预定的子流程作为Activity节点供多个流程使用，优先搭建逻辑，之后进行微调。
2. 支持技术和商务标准协议：方便进行规范化。
3. 支持快速实施
4. 帮助企业获得全面业务透视能力，从而让企业可以全面掌控业务

3.2.5. 流程集成应用开发模式

3.3. B2B电子商务

1. 企业与企业之间通过网络进行产品、服务及信息的交换
   1. 信息标准化、身份验证
   2. 流程相对不多，但更重要的是标准化信息接口的调用
   3. EDI(Electronic Data Interchange)电子数据交换
2. 将买方和卖方集中到一个市场上进行信息交流、广告、拍卖竞标、交易、库存管理

3.3.1. B2B模式

3.3.2. B2B集成场景

1. 企业内部的多个应用系统与多个外部信息系统进行交互
2. M×N交互场景（M个内部系统与N个外部系统进行交互）：
   1. 微软公开了白皮书方案(标准的B2B的集成方案)，结合方案进行服务发现和调用，后来发现没有办法提供统一的安全保证。
   2. 后期的成本太高，微软放弃了
   3. 公司做领域的B2B集成方案还是可行的
3. 每个系统都有各自的数据交换格式，这些格式不一定需要被外部系统所理解。

3.3.3. B2B集成解决方案（宏观）

1. 接收及验证发往外部信息系统以获取一些业务数据的请求消息
2. 选择某个外部信息系统（商家）来获得请求的数据
3. 运行一些可能针对具体请求环境的业务规则
4. 创建命令，规定适合于所选择的外部信息系统的格式
5. 通过商家支持的传输协议，把含有商家数据格式命令的请求消息传送给对方
6. 对外部信息系统的响应采用的步骤类似对出站命令请求采用的步骤（譬如验证和数据转换）
7. 管理与外部信息系统的联系以及定义事务

3.3.4. B2B系统的主要部分

1. 用于接收客户请求和外部信息系统响应的事件侦听器
   1. 服务器小程序
2. 定义集成工作流中逻辑步骤的流程定义
   1. 用隐式方式拥有事务管理逻辑
3. 流程定义用来执行该步骤的支持组件
   1. 数据验证、转换和业务规则执行

3.4. 技术组成(了解)

1. 通信模式
2. 集成方法
3. 中间件技术
4. 服务

3.4.1. 通信模式

1. 同步通信
   1. 请求/应答
   2. 同步轮询
2. 异步通信
   1. 消息传送通信
   2. 发布/订购通信
   3. 广播通信

3.4.2. 集成方法

1. 消息传递
2. 接口调用

3.4.3. 中间件技术

1. 远程过程调用
2. 数据库访问的中间件
3. 面向消息的中间件
4. 分布式对象技术
5. 事务处理监控器

3.4.4. 服务

1. 目录
2. 生存周期
3. 安全
4. 变换和转换
5. 连续性
6. 事件
7. 通知
8. 工作流

3.5. 一致性问题

1. 异构性
   1. 设置映射关系解决子模块间不一致的命名、取值、格式、描述以及调用序列问题
   2. 提供触发机制以维持模块间的依赖关系并保证限制条件
2. 子系统的自治性
3. 集成和透明

3.6. EAI面临的障碍

1. 混乱的体系结构
2. 技能欠缺
3. 安全问题

4. Web数据集成 WDI

1. 早期的集成更强调流程的调用，但是大数据时代更关心结果数据的集中化。
2. 参考数据集成原理的例子

4.1. 集成案例2

1. 左侧和右侧的填写方式不同
2. 在某个第三方网站上发布自己的数据后应该在其他同样数据源的网站中有对应的数据，而不需要多次填写个人或请求信息(为同一个目的)

4.2. Web数据集成

1. Web数据集成(WDI)是将来自不同网站的数据聚合和管理到单个同类工作流程的过程。该过程包括数据访问，转换，映射，质量保证和数据融合
   1. 数据访问：使用爬虫的方式爬取，部分数据使用表单获取，可能是深网数据，爬取是困难的
   2. 数据转换：对数据进行转换为目标格式
   3. 网络数据集成对决策支持和关联分析有一定的作用
2. 网络数据是最大的数据源
   1. 网络中包含数百万的数据库，其中一些数据在网页中，其他一些可通过Web表单来访问
   2. 数据呈指数级增长且不断变化，从2013年的4. 4兆字节增长到2020年的预测的44兆字节f(或44万亿GB)
3. 网络数据信息可用于决策制定、提供替代数据集、提供启发灵感
   1. 特别对于股权、金融研究、零售、制造、旅游酒店业
4. 数据爬取(爬虫)、数据转换(清洗)

4.3. Web数据集成步骤

1. 识别信息所在的Web来源
2. 提取显示或隐藏的数据
3. 清理并准备数据：使用一些指标去衡量数据质量，直到数据质量达标后才可以使用，构造需要重复之前的步骤。
4. 数据分析挖掘
5. 数据可视化：部分情况只是做一些可视化的工作

4.4. Web数据集成难点

1. 超大规模数据库集合的模式异构性
2. 提取数据的困难
   1. 网页表单数据理解
   2. 通过表单来访问深层网络(DeepWeb)或隐式网络(Invisible Web)
3. Web上的数据往往是错的、过时的，甚至是矛盾的。因此，从这些数据源获得答案，需要不同的方法来对数据进行组合和排序

5. 数据集成面临的挑战

1. 挑战：数据库理论中，两个人面对相同的数据需求时往往会设计出不同的模式
2. 往往使用上面这个挑战来检查数据库是否是生成的。

5.1. 系统原因

1. 如何使不同的系统之间无缝交流
   1. 虽然SQL是一种用于关系数据库的标准查询语言，但不同供应商的实现方式也有差异，在集成过程中，这些差异就需要进行协调
   2. 天然的数据类型不一致，有的允许伪列，而有的则没有。
2. 如何有效地执行跨系统的查询
   1. 在数据集成中，而临的是已经存在的数据源，而数据的结构往往非常复杂，并且不一定是已知的
   2. 每个数据源提供的查询处理能力也大不相同

5.2. 逻辑原因

1. 多个数据源集成的语义异构问题
   1. 结构化的数据源根据模式组织数据
   2. 关系数据库:表
   3. 其他数据模型:特定的标签、类和属性
2. Full Serve和EuroCard的差异
3. 数据表示和语义的差异
4. EuroCard公司数据库
   1. Employee 数据库
      1. Emp(ID,firstNameMiddielnitial,lastName. Salary)
      2. Hire(ID,hireDate,recruiter)
   2. Resume数据库
      1. Interviews(ID,date,location,recruiter)
      2. CVs(candID,resume)
   3. Credit Card数据库
      1. Cards(CustID,cardNum,expiration,currentBalance)
      2. customers(CustID,name,address)
   4. HelpLine数据库
      1. Calls(date,agent,custID,description,followup)
5. FulIServe的数据库
   1. Employee数据库
      1. FullITimeEmps(ssn,emplD,firstName,middleName,lastName)
      2. Hire(emplD,hireDate,recruiter)
      3. TempEmployees(ssn,hireStart,hireEnd ,name ,hourlyRate)
   2. Resume数据库
      1. Interviews(interviewDate,plD,recruiter,hireDecision,hireDate)
      2. CVs(ID,resume)
   3. Training数据库
      1. Courses(courselD,name ,instructor)
      2. Enroliments(courselD,date)
   4. Services数据库
      1. Services(packName,textDescription)
      2. Customers(name,ID,zipCode,streetAdr,phone)
   5. Sales数据库
      1. Products(prodName,prodID)
      2. Sales(prodID,customerD ,custName ,address)
   6. HelpLine数据库
      1. Calls(date,agent ,text ,action)

5.3. 社会和管理原因

1. 数据源难以获得
   1. EuroCard可能根本就没有保存员工的电子简历
2. 出于法律上的原因，不能共享数据
3. 数据的所有者也可能不愿意配合数据的整合
   1. 数据关系到企业的一些关键业务，允许来自数据集成系统的额外查询可能会给他们的系统带来难以承受的高负荷
   2. 数据只能被企业内部特定的人员看到，数据的所有者有理由担心数据集成系统无法强制执行这些限制
   3. 对数据的访问意味着在组织内拥有更多的权力

5.4. 设定预期

1. 数据集成问题难以彻底解决
2. 两个较为实际的目标
   1. 构建工具来减少整合一组数据源所需要付出的努力。例如，这些工具应该易于添加新的数据源、将模式关联到其他数据源、自动调整数据集成系统以获得更好的性能
   2. 提高系统在不确定环境下回答用户查询的能力。在数据集成应用时，减少用户的负担和提高准确性不能两全
3. 用户以较小的代价从数据集成系统中获得更好的结果