Lec1-数据集成概述(企业数据集成背景)
1. 数据集成的需求
1.1. 应用环境图例
- 多应用系统共存,系统或者交叉互连,或者相互孤立
- 多操作系统、多数据库系统、多技术平台共存
- 用户需要在不同系统中切换
- 数据集成是有不同层次的,下图中的系统是随着企业的发展而不断进行的,也会导致数据的不一致等出现问题。
- 每一个烟囱意味着一个系统,一个烟囱的信息并不会和其他的烟囱有关系。
- 右图的含义是指将烟囱的底部打通,而使得数据可以互操作并且交互。
- 将信息孤岛的问题通过数据集成的方案来完成打通。
1.4. 信息化环境的变化
- 应用软件通过Internet或WAN分布在世界范围
- 数以百万/千万计的用户,可能存在的突发事件:用户可以在互联 上自由的注册或者登陆,典型的突发事件有双十一抢购等等。
- 用户和应用程序间的连接是非持久性的和低速的:在强的服务器端也不可能让所有的用户进行同时请求,更多的是将部分逻辑前移到客户端而客户端和服务器端只进行必要的数据连接交换即可。
- 千差万别的数据表示设备:比如不同硬件设备、操作系统等等
- 应用程序所需的数据可能分布在不同的机器上:数据在不同的服务器上。
- 全球化的协同工作:数据在全球各地。
- 因此很难通过传统的方式来做应用,更多的还要选择进行数据集成。
1.5. 数据集成案例
1.5.1. 集成案例1(并购)
- 美国家庭互联 接入公司FullServe收购欧洲信用卡供应商EuroCard
- 在最开始的时候以效率为导向,以流程为核心,只有尽快(效率)让流水线转起来才能产生出价值。
- 之后以管理为导向,以平台为核心,生产流水线逐渐增多会导致有大量的数据出现,也就会出现数据的交叉和冗余。各个平台也就更需要定期进行数据的一致化处理与集成。
- 再之后则是以集成为导向,以供应链为核心,体量比较大后则需要对外进行集成(向上集成分销商和向下集成供应商,集成可以理解为有很多个)
- 最后以规模为导向:规模越大,覆盖面越广,占据市场越大,以 络为核心
1.7. 商业集成的需要
- SCM:供应链管理是一种集成的管理思想和方法,它执行供应链中从供应商到最终用户的物流的计划和控制等职能。从单一的企业角度来看,是指企业通过改善上、下游供应链关系,整合和优化供应链中的信息流、物流、资金流,以获得企业的竞争优势。
- ERP:ERM系统是企业资源计划(Enterprise Resource Planning) 的简称,是指建立在信息技术基础上,集信息技术与先进管理思想于一身,以系统化的管理思想,为企业员工及决策层提供决策手段的管理平台。
- CRM:客户关系管理(Customer Relationship Management)是一种企业与现有客户及潜在客户之间关系互动的管理系统。通过对客户数据的历史积累和分析,CRM可以增进企业与客户之间的关系,从而最大化增加企业销售收入和提高客户留存。
- EAM 是Enterprise Asset Management 的缩写,EAM系统是指企业资产管理系统。EAM系统是在资产比重较大的企业,在资产建设、维护中减少维护成本,提高资产运营效率,通过现代信息技术减少停机时间,增加产量的一套企业资源计划系统。EAM企业资产管理系统即是面向资产密集型企业的信息化解决方案的总称,也是以企业资产管理为核心的商品化应用软件。
1.11. 常见的EAI需求
- 信息门户
- 数据复制
- 共享的业务功能
- 面向服务的体系结构
- 分布式的业务过程
- 企业到企业的集成
1.12. Automated Business Processes
企业数据集成的三个层面
- 络集成(互连,指 络互连):能够看到彼此存在;语法:协议
- 数据集成(互通):彼此交换和理解数据,调用时则需要知道约束;语义:组织格式和含义
- 应用集成(互连,指应用互连):可以对业务逻辑做调用,上下文是保留的,调用的时候可以满足结果获得即可;语用:每个语言可所保留有的上下文和场景(成语的背后)
- 信息安全和 络爬虫
2.4. 技术要求
- 能提供应用间的互操作性
- 信息的有意义交换
- 功能服务:资源的动态发现,动态类型检查(对调用参数进行调整)
- 能提供分布式环境中应用的可移植性
- 不会破坏应用所提供的或正在使用的服务:移植过程不应该影响服务的运行
- 静态的系统重新部署以及动态的系统重构:需要可以根据情况做动态的重构。
- 能提供系统中应用分布的透明性:考虑到异构的情况(企业的系统是在不同的时候部署的,不同地区的情况也是不同的),不应当知道底层的细节
- 实现细节:屏蔽底层 络等实现细节
- 复杂性
2.5. 应用集成的历史
- 60年代到70年代:从信息系统开始
- 80年代:点到点(point-to-point)的集成,信息和数据共享
- 80年代末和90年代初:基于框架的集成:CORBA、DCOM、MOM
- 90年代中后期:业务流程集成技术BPI
- 21世纪以来:B2B与B2C、XML、Web Service(也不能满足大规模调用)、SOA
3. 集成模型
3.1. 集成模型的描述
- 集成软件的特定方法和结构
- 对集成模型的关注点(差异点)
- 集成难度:实现集成简单性
- 可重用性:对于不同配置集成的可重用性
- 广泛性:可用集成方法的广泛度
- 技术难度:在执行集成的过程中要求的专门技术
3.2. 集成模型种类
- 表示集成:软件用户界面
- 数据集成:
- 表结构的数据集成
- 直接访问软件创建、维护并存储的信息
- 功能集成:代码级别的软件集成
- 业务流程集成(强相关的业务逻辑):商务逻辑
- B2B集成(弱相关的业务逻辑):不同贸易协议
3.2.1. 表示集成模型
- 此时要完成的集成是一个新的逻辑段,不需要用到原本的界面
- 直接访问对应的数据的数据库接口
3.2.2.3. 应用场景
- 多个信息源综合数据进行分析和决策
- 向多个应用软件提供公共信息源的只读权限:只需要对一个认证方进行沟通,一般是只读,否则修改可能导致不一致性。
- 以一个信息源的信息来更新另一个数据源:关联更新
- 案例
- 综合sybase、DB2和SAP P/3数据库中的数据
- 使用大型机和Oracle的可执行信息系统
- 允许其他应用程序在peoplesoft和定制的Oracle数据库中获取数据
3.2.2.4. 数据集成的特点
- 更广泛的数据访问:文件的数据也是可以(文件方式也是有ODBC的访问接口的)
- 简化数据库访问:避免从多源多位置访问
- 方便新数据源的集成
- 系统逻辑演变的维护工作:原有应用对新系统没有影响,对新系统是透明的,数据集成的应用需要自己维护演化的逻辑。
3.2.3. 功能集成模型
- 工作引擎
- 业务管理中心的Activity会映射到企业内外部的应用
- 在业务流程中,商务规则或者表现为条件和限制,或者表现为实施并发、串行等流程中的行为(Activity)节点
3.2.4.1. 业务流程
- 为在一定时期内达到特定的商业目标,而按照各种商务规则连接起来的业务功能集
- 具体实现受限于业务功能运行所必须的可用资源,包括业务人员,IT业务应用系统,客户,和商务交往及贸易伙伴等
- 在工作流的基础上做这个部分
3.2.4.2. 业务流程集成的技术成分
- 业务流程引擎
- 资源管理工具
- 调度工具
- 审计管理工具
- 错误管理工具
- 资源库:业务流程集成层资源库中可存储多种数据对象
3.2.4.3. 应用场景
- 通过子流程来实现业务流程共享:把预定的子流程作为Activity节点供多个流程使用,优先搭建逻辑,之后进行微调。
- 支持技术和商务标准协议:方便进行规范化。
- 支持快速实施
- 帮助企业获得全面业务透视能力,从而让企业可以全面掌控业务
3.2.5. 流程集成应用开发模式
3.3.1. B2B模式
3.3.3. B2B集成解决方案(宏观)
- 接收及验证发往外部信息系统以获取一些业务数据的请求消息
- 选择某个外部信息系统(商家)来获得请求的数据
- 运行一些可能针对具体请求环境的业务规则
- 创建命令,规定适合于所选择的外部信息系统的格式
- 通过商家支持的传输协议,把含有商家数据格式命令的请求消息传送给对方
- 对外部信息系统的响应采用的步骤类似对出站命令请求采用的步骤(譬如验证和数据转换)
- 管理与外部信息系统的联系以及定义事务
3.3.4. B2B系统的主要部分
- 用于接收客户请求和外部信息系统响应的事件侦听器
- 服务器小程序
- 定义集成工作流中逻辑步骤的流程定义
- 用隐式方式拥有事务管理逻辑
- 流程定义用来执行该步骤的支持组件
- 数据验证、转换和业务规则执行
3.4. 技术组成(了解)
- 通信模式
- 集成方法
- 中间件技术
- 服务
3.4.1. 通信模式
- 同步通信
- 请求/应答
- 同步轮询
- 异步通信
- 消息传送通信
- 发布/订购通信
- 广播通信
3.4.2. 集成方法
- 消息传递
- 接口调用
3.4.3. 中间件技术
- 远程过程调用
- 数据库访问的中间件
- 面向消息的中间件
- 分布式对象技术
- 事务处理监控器
3.4.4. 服务
- 目录
- 生存周期
- 安全
- 变换和转换
- 连续性
- 事件
- 通知
- 工作流
3.5. 一致性问题
- 异构性
- 设置映射关系解决子模块间不一致的命名、取值、格式、描述以及调用序列问题
- 提供触发机制以维持模块间的依赖关系并保证限制条件
- 子系统的自治性
- 集成和透明
3.6. EAI面临的障碍
- 混乱的体系结构
- 技能欠缺
- 安全问题
4. Web数据集成 WDI
- 早期的集成更强调流程的调用,但是大数据时代更关心结果数据的集中化。
- 参考数据集成原理的例子
4.1. 集成案例2

- 左侧和右侧的填写方式不同
- 在某个第三方 站上发布自己的数据后应该在其他同样数据源的 站中有对应的数据,而不需要多次填写个人或请求信息(为同一个目的)
4.2. Web数据集成
- Web数据集成(WDI)是将来自不同 站的数据聚合和管理到单个同类工作流程的过程。该过程包括数据访问,转换,映射,质量保证和数据融合
- 数据访问:使用爬虫的方式爬取,部分数据使用表单获取,可能是深 数据,爬取是困难的
- 数据转换:对数据进行转换为目标格式
- 络数据集成对决策支持和关联分析有一定的作用
- 络数据是最大的数据源
- 络中包含数百万的数据库,其中一些数据在 页中,其他一些可通过Web表单来访问
- 数据呈指数级增长且不断变化,从2013年的4. 4兆字节增长到2020年的预测的44兆字节f(或44万亿GB)
- 络数据信息可用于决策制定、提供替代数据集、提供启发灵感
- 特别对于股权、金融研究、零售、制造、旅游酒店业
- 数据爬取(爬虫)、数据转换(清洗)
4.3. Web数据集成步骤
- 提取显示或隐藏的数据
- 清理并准备数据:使用一些指标去衡量数据质量,直到数据质量达标后才可以使用,构造需要重复之前的步骤。
- 数据分析挖掘
- 数据可视化:部分情况只是做一些可视化的工作
4.4. Web数据集成难点
- 超大规模数据库集合的模式异构性
- 提取数据的困难
- 页表单数据理解
- 通过表单来访问深层 络(DeepWeb)或隐式 络(Invisible Web)
- Web上的数据往往是错的、过时的,甚至是矛盾的。因此,从这些数据源获得答案,需要不同的方法来对数据进行组合和排序
5. 数据集成面临的挑战
- 挑战:数据库理论中,两个人面对相同的数据需求时往往会设计出不同的模式
- 往往使用上面这个挑战来检查数据库是否是生成的。
5.1. 系统原因
- 如何使不同的系统之间无缝交流
- 虽然SQL是一种用于关系数据库的标准查询语言,但不同供应商的实现方式也有差异,在集成过程中,这些差异就需要进行协调
- 天然的数据类型不一致,有的允许伪列,而有的则没有。
- 如何有效地执行跨系统的查询
- 在数据集成中,而临的是已经存在的数据源,而数据的结构往往非常复杂,并且不一定是已知的
- 每个数据源提供的查询处理能力也大不相同
5.2. 逻辑原因
- 多个数据源集成的语义异构问题
- 结构化的数据源根据模式组织数据
- 关系数据库:表
- 其他数据模型:特定的标签、类和属性
- Full Serve和EuroCard的差异
- 数据表示和语义的差异
- EuroCard公司数据库
- Employee 数据库
- Emp(ID,firstNameMiddielnitial,lastName. Salary)
- Hire(ID,hireDate,recruiter)
- Resume数据库
- Interviews(ID,date,location,recruiter)
- CVs(candID,resume)
- Credit Card数据库
- Cards(CustID,cardNum,expiration,currentBalance)
- customers(CustID,name,address)
- HelpLine数据库
- Calls(date,agent,custID,description,followup)
- Employee 数据库
- FulIServe的数据库
- Employee数据库
- FullITimeEmps(ssn,emplD,firstName,middleName,lastName)
- Hire(emplD,hireDate,recruiter)
- TempEmployees(ssn,hireStart,hireEnd ,name ,hourlyRate)
- Resume数据库
- Interviews(interviewDate,plD,recruiter,hireDecision,hireDate)
- CVs(ID,resume)
- Training数据库
- Courses(courselD,name ,instructor)
- Enroliments(courselD,date)
- Services数据库
- Services(packName,textDescription)
- Customers(name,ID,zipCode,streetAdr,phone)
- Sales数据库
- Products(prodName,prodID)
- Sales(prodID,customerD ,custName ,address)
- HelpLine数据库
- Calls(date,agent ,text ,action)
- Employee数据库
5.3. 会和管理原因
- 数据源难以获得
- EuroCard可能根本就没有保存员工的电子简历
- 出于法律上的原因,不能共享数据
- 数据的所有者也可能不愿意配合数据的整合
- 数据关系到企业的一些关键业务,允许来自数据集成系统的额外查询可能会给他们的系统带来难以承受的高负荷
- 数据只能被企业内部特定的人员看到,数据的所有者有理由担心数据集成系统无法强制执行这些限制
- 对数据的访问意味着在组织内拥有更多的权力
5.4. 设定预期
- 数据集成问题难以彻底解决
- 两个较为实际的目标
- 构建工具来减少整合一组数据源所需要付出的努力。例如,这些工具应该易于添加新的数据源、将模式关联到其他数据源、自动调整数据集成系统以获得更好的性能
- 提高系统在不确定环境下回答用户查询的能力。在数据集成应用时,减少用户的负担和提高准确性不能两全
- 用户以较小的代价从数据集成系统中获得更好的结果
文章知识点与官方知识档案匹配,可进一步学习相关知识MySQL入门技能树数据库组成表32225 人正在系统学习中
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!