信息孤岛问题数据库层优化解决方案设计-毕业论文

本科毕业论本科毕业论文文 (科研训练、毕业设计) 题题 目：目： 信息孤岛问题数据库层优化解决方案设计信息孤岛问题数据库层优化解决方案设计 姓 名： 学 院： 软件学院 系： 专 业： 软件工程 年 级： 学 号： 指导教师（校内）： 职称： 指导教师（校外）： 职称： 年 月 日 信息孤岛问题数据库层优化解决方案设计 1 信息孤岛问题数据库层优化解决方案设计信息孤岛问题数据库层优化解决方案设计 摘要 通过对信息孤岛问题的现状和目前流行的数据库层解决方案进行详实的分析，提出 了一种分布式规划、联邦式过渡的数据库优化架构设计方案，以高等院校数据孤岛问题为实 例，详细阐述了中央分布式数据库逻辑设计，以及对现存异构数据库的联邦式整合方案。对 整合方案中涉及的数据转换移植需求进行分析，提出开发 TransBuilder 数据库通用转换移 植工具的设想，使用面向过程的软件设计方法对 TransBuilder 进行了完整的功能流程设计。 关键词 信息孤岛 分布式数据库系统 联邦式数据库系统 数据转换 校园信息化 信息孤岛问题数据库层优化解决方案设计 2 Database layer optimization solution for Isolated Information Island Abstract This thesis analyzes the exiting issue- Isolated Information Island and the popular solutions. Later, this thesis advances an optimized solution whose ultimate aim is distributed database but adopt federated database as a transition. This thesis takes Isolated Information Island in campus computing as an example, illustrates the logical design of distributed database and the federated integration solution for Heterogeneous Databases. After analyzing the requirements of data migration in integration solution, this thesis put forward the idea of designing a database migration tool and presents the design schema of Data migration tool. Key Words Isolated Information Island; Distributed Database System; Federated Database System; Data transform; Campus Computing 信息孤岛问题数据库层优化解决方案设计 3 目 录 第第 1 1 章章 引言引言4 4 1.1研究背景4 1.2本研究的理论和实际意义4 1.3相关领域的研究进展和成果5 1.4主要研究内容5 1.5本文的组织5 第第 2 2 章章 信息孤岛的产生和目前一般的解决方案信息孤岛的产生和目前一般的解决方案6 6 2.1信息孤岛的产生、现状和危害6 2.2信息孤岛目前一般的数据库层解决方案7 第第 3 3 章章 信息孤岛问题实际案例信息孤岛问题实际案例1111 3.1A 高校的信息孤岛问题 .11 3.2信息化项目组的成立和所面对的问题.13 第第 4 4 章章 分布式规划联邦式过渡的数据库优化架构方案设计分布式规划联邦式过渡的数据库优化架构方案设计1414 4.1设计原理.14 4.2中央数据库设计.14 4.3联邦式过渡典型案例：人事处系统整合.17 4.4数据库转换移植工具的需求.19 第第 5 5 章章TRANSBUILDERTRANSBUILDER 设计设计 2020 5.1功能需求.20 5.2面向过程的软件设计.20 5.3存在问题及解决方案.25 5.4TRANSBUILDER的应用前景和展望 26 致谢致谢2727 参考文献参考文献 2828 信息孤岛问题数据库层优化解决方案设计 4 第 1 章引言 1.1 研究背景 “信息化校园计划”（The Campus Computing Project）最早是 1990 年由美国克莱蒙特 大学教授凯尼斯格林（Kenneth Green）发起并主持的一项大型科研项目。 高校信息化建设的目标是建设一个数字校园，以网络为基础，利用先进的信息化手段和 工具，实现从环境（包括设备、教室等）、资源（如图书、讲义、课件等）到活动（包括教、 学、管理、服务、办公等）的全部数字化，在传统校园的基础上构建一个数字空间，以拓展 现实校园的时间和空间维度，提升传统校园的效率，扩展传统校园的功能，最终实现教育过 程的全面信息化。从而达到提高教育管理水平和效率的目的。 原有的在缺乏统一规划的情况下建设的各种应用系统，由于信息无法共享，形成了一个 个“信息孤岛”（图一），大大妨碍了信息化建设的进程，解决数据孤岛问题是信息化建设 起步面对的首要问题。 图一 连在一起的信息孤岛 1.2 本研究的理论和实际意义 理论意义：信息孤岛的根源在数据源共享问题，目前解决该问题的方法主要有两种：分 布式或联邦式数据库系统架构，本研究旨在对两种系统架构模式进行探讨，指出其优点，揭 露其缺陷，通过比较性研究和实际案例实践，在理论上提出一种新的分布式规划、联邦式过 渡的数据库系统架构优化方案。 实际意义：本文作者隶属于厦门大学校园信息化建设项目组，该项目组成立于 2004 年 5 月，本人所在科研管理系统开发团队由七人组成，其组织结构如图二所示。本人在其中主 要致力于信息孤岛问题的解决方案的设计和实现，完成数据库转换移植工具的设计。 通过实践中考察到信息孤岛问题在企事业单位信息化中存在的普遍性，作者对相关方面 的问题进行了广泛的思考和实践，从理论到实现，为信息孤岛问题的解决设计了整套切实可 行的方案。 解决方案实施关键工具 TransBuilder 的设计和实现填补了当前可配置数据移植工具的 信息孤岛问题数据库层优化解决方案设计 5 空白。 图二 科研管理系统开发团队协作图 1.3 相关领域的研究进展和成果 信息孤岛问题的解决方案在数据库层主要集中在分布式和联邦式之争。本文将在第三章 详细客观的介绍这两种数据库系统架构方案。 数据移植领域，主要由数据库开发商提供开发了一些移植工具，如：微软随 SQL Server 附送的 Data Transformation Services（DTS），Oracle 的移植工作台等，这些工 具的设计目的多为将数据库从其他数据库供应商的产品上复制到自己的产品上，以及作为数 据备份工具使用，其功能要点集中在复制上，对异构数据库之间的转移支持并不良好，甚至 不支持。 1.4 主要研究内容 数据库系统架构 可配置数据移植工具 TransBuilder 的设计和实现 1.5 本文的组织 第一部分 研究简介（第 1 章） 第二部分 信息孤岛的含义和目前数据库层解决方案概述（第 2 章） 第三部分 描述具体典型案例，清晰信息孤岛问题（第 3 章） 第四部分 数据库架构方案设计（第 4 章） 第五部分 数据库移植方案和工具设计（第 5 章） 信息孤岛问题数据库层优化解决方案设计 6 第 2 章信息孤岛的产生和目前一般的解决方案 2.1 信息孤岛的产生、现状和危害 2.1.1 信息孤岛的产生 在构建某个应用系统时，目前大多采用“独立解决方案”，开发者和需求部门应用逻辑 相结合，在特定的操作系统平台上、特定的集成开发环境下、基于特定的数据表达格式，进 行特定数据库设计和应用软件系统的开发，很少考虑应用的可集成性、可重用性、可定制性、 可移植性，造成了众多软硬件平台、各类应用系统并存的局面。 图三 系统接口数量 N（N1） 当众多系统间需要信息共享时，往往以某一个或某几个关键应用系统为主，基于系统提 供接口进行二次开发，在需要共享信息的系统间由特定的程序员提供复杂的访问接口，与其 它系统进行整合，是一种复杂系统对接的模式。假定企业中有 N 个系统需要共享数据资源， 那么需要特定的程序员开发复杂的单向接口就是 N（N1）个（图三）。于是，企业不得不 为每套应用配置特有的专业技术维护人员（至少是数据库管理员），并保持与不同技术供应 商的密切联系，接口的复杂性和大量化以及不同技术供应商之间的工作协调往往使企事业单 位望而生畏，结果往往形成了众多的信息孤岛和小规模的紧密集成。 2.1.2 信息孤岛的现状 随着现代信息技术和 Internet 技术的飞速发展，企事业单位的管理方式也一直发生着变 革，基于网络的管理模式已成为优化企事业单位管理的有效途径和发展趋势。网络化管理通 常涉及多个部门甚至多个单位，具有异地工作环境、异构工作平台、并行协同工作等特点， 其实施的基础是企事业单位应用系统的有机集成与管理信息的有效共享。 目前，我国很多企事业单位通过市场采购或自主开发，拥有了多种 OA 和 MIS 系统软 信息孤岛问题数据库层优化解决方案设计 7 件，这些都为管理信息化积累了一定的经验。可是由于没有统一的架构和管理，以及传统应 用开发模式的局限和系统集成方法的落后，形成了众多的数据源孤岛或紧耦合应用，严重阻 碍了企事业单位信息的流通和信息化的进一步发展。 2.1.3 信息孤岛的苦果 信息孤岛的产生让不少信息化走在前沿的企事业单位尝尽了苦果，尤其突出表现在以下 五个方面： 数据的一致性无法保证。由于信息定义与采集过程彼此独立，单位中同一数据可 能在不同的应用中不一致。 信息及时共享、反馈难。信息不能及时充分共享的矛盾突出，单位中“信息孤岛” 林立。 企业存冗余垃圾信息。 由于各个系统独立，存在大量不必要数据，使访问数据库 的速度降低。 信息需要重复多次的输入。对信息的多次采集不仅仅是额外的劳动，数据失真也 是重复输入的恶果之一。 信息化进程遇到障碍。无法对信息孤岛进行联机分析处理（OLAP）、数据仓库 （DW）建设，妨碍了对企业附加值的数据挖掘（DM）和决策支持系统（DSS）的构 建。 2.2 信息孤岛目前一般的数据库层解决方案 多应用系统集成是目前最流行也是使用和探讨最广泛的信息孤岛解决方案。现行的多数 据库应用系统集成方案，主要分为前台应用层解决方案和后台数据库层解决方案，其中，数 据库层是人们最关心的，治病治根，信息孤岛的根就在数据库上，因此，如何解决好数据库 层是整个集成方案的关键。目前，对数据库层的集成一般有两种方案：分布式数据库系统、 联邦式数据库系统。 2.2.1 分布式数据库架构 图四 DDBS 环境2 信息孤岛问题数据库层优化解决方案设计 8 多应用系统必然对数据有分布式存储需要，对分布式数据的管理和访问就成为必须解决 的问题。由于一个事务所涉及的数据可能分布在多个结点上（如图四），这就要求数据库系 统具备一个优化的分布查询策略。对于这种分布执行的事务，系统要保证事务执行的原子性 和可串行化，以及解决分布环境下的安全问题、恢复问题、分布透明性、节点自治、全局命 令空间、分布式查询、分布式更新、数据分布与复制、两阶段提交(2PC)、网络数据字典 (NDD)等关键问题。分布式数据库系统正是为解决上述问题而设计的。 一个分布式数据库系统由一个逻辑数据库组成，这个逻辑数据库的数据存储在一个或多 个结点的物理数据库上，通过两阶段提交(2PC)协议来提供透明的数据访问和事务管理。分 布式数据库系统在系统结构上的真正含义是指物理上分布、逻辑上集中的分布式数据库结构。 数据在物理上分布后，由系统统一管理，使用户不感到数据的分布。用户看到的似乎不是一 个分布式数据库，而是一个数据模式为全局数据模式的集中式数据库。分布式数据库有性能 高、可扩充性好、可用性好以及具有自治性等优点。 分布式数据库系统仍存在不足：由于数据库系统的应用通常是逐步发展的，起先是建立 各种孤立的数据库，而管理这些数据库的计算机系统和 DBMS 包括数据模型很可能是不同的， 也就是异构的(Heterogeneous)。当应用需要转向分布式数据处理时，抛弃原有的系统另砌 炉灶显然是不合理的，这就需要解决异构数据库的集成问题。这在技术上有一定的复杂性， 而且目前还很难用一个通用的 DBMS 来解决这样的问题。我们希望一种新的数据库技术 联邦数据库系统(Federated Database System)能解决这一问题。此外分布式数据库系统虽 然有利于改善性能，但如果数据库设计不好，数据分布不合理，使远距离访问过多，特别是 当分布连接操作过多时，都会降低系统的性能。 2.2.2 联邦式数据库架构 分布式数据库系统不能很好解决的异构数据库的集成问题，可以通过建立联邦数据库系 统来解决。通常称相互独立运行的数据库系统为单元数据库系统(Component DBS)。它是原 本存在的、在局部地区应用的数据库系统，它们是联邦数据库系统的一部分。所谓联邦式数 据库系统是一种物理上分布、逻辑上分布的分布式数据库结构。 这种分布式数据库结构的特点是结点自治(Site Autonomy)和没有全局数据模式(Global Data Schema)。每个结点所看到的数据模式仅仅限于该结点所用到的数据。它一般由两部分 组成：一是本结点的数据模式，二是供本结点共享的其他结点上的有关的数据模式。结点间 的数据共享由双边协商确定。如果一个新的结点要加入系统，它开始时可先用本结点的数据， 然后与有关结点协商，共享其他结点的有关数据；本结点的数据同样可被其他结点共享。这 种扩展完全是渐进的，不会影响原有系统的运行。由于每一个结点所看到的数据模式是不一 样的，就好像系统中有多个逻辑数据库，因而在逻辑上这种数据库结构也是分布式的（图五） 。 信息孤岛问题数据库层优化解决方案设计 9 图五 联邦式数据库系统扩展方式 由于无全局数据模式，一个结点的数据模式的修改甚至一个结点的加入或撤离，仅仅影 响有关的结点。一个结点在给数据对象命名时，只要求在本结点的数据模式内唯一，无需考 虑与其它无关数据对象的重名问题。每个结点好像拥有一个满足自己需要的集中式数据库一 样，而不受制于全局数据模式，甚至不必有“全局观念”，结点具有很高的自治性。 联邦式数据库结构有利于数据库的集成、扩展和重新配置，但因为现有网络系统并不具 备够大的延展性，可以在大量资料上做平行运算，所以其性能不如集中式数据库高，而且实 现代价较高，技术上也很复杂，如不同数据系统的数据模式转换，全局事务的管理及其串行 性等。 信息孤岛问题数据库层优化解决方案设计 10 分布式分布式联邦式联邦式 数据库设计复杂性数据库设计复杂性复杂，需要详细规划较复杂，对规划要求不高 共享复杂性共享复杂性较简单 较复杂，每个新系统加入 都要调整共享 反映了组织结构反映了组织结构是是 本地自主权本地自主权高极高，完全自主权 可用性可用性较高稍低 可靠性可靠性高中上 性能性能中上较低 成本成本中中 可扩张性可扩张性强很强 复杂性复杂性中上高 完整性完整性高单个高，全局低 实施经验实施经验较多较少 表一 分布式和联邦式数据库架构比较表 信息孤岛问题数据库层优化解决方案设计 11 第 3 章信息孤岛问题实际案例 高等院校具有实施信息化建设的优势： 对共享数据/计算资源/存储资源/应用资源的内在需求 复杂的计算环境和提供更大计算能力的需求 充足且对新技术十分敏感的技术力量 所以，高校也就首当其冲的成为信息孤岛问题的受困者，当然，这为我们研究和解决信 息孤岛问题提供了一个良好的平台。下面就 A 高校的信息孤岛问题为例形象的说明该问题的 状况和该校的从行政上采取的可供大家参考的措施。 3.1 A 高校的信息孤岛问题 我国大多数高校已广泛建设和拥有了校园网络，并且成立了诸如网络中心类机构来统一 管理硬件设施，A 高校作为站在时代先锋的国家重点高等院校，其管理方式也一直发生着变 革，网络化、电子化正一步步渗透到学校工作、生活的方方面面，校内一些需求比较迫切的 部门（如：财务处、人事处等）或研发能力较强的单位（计算机系、软件学院等），已经通 过市场采购或自主研发，拥有了多套 OA 和 MIS 系统软件，但是由于整个校园信息化建设缺 乏统一规划和标准，各单位认识不一致，发展不平衡，各单位的应用系统是在不同时间由不 同人群研发完成，应用系统间的数据共享还有赖于落后的磁盘甚至是纸介质等低效率的方式， 缺乏协调，形成了网络环境下大量的“信息孤岛”，为学校的管理带来了实际的不便。 下面用一些实际问题简述一下该校的信息孤岛问题状况： 3.1.1 数据一致性问题： 表二四 为该校财务处、人事处、后勤集团数据库人员信息统计对照表，表五 显示了 财务处和人事处因为缺乏统一的规范，对校内同一单位的不同命名，这些表充分反映了该校 各部门应用系统存在着数据一致性问题； 简单统计简单统计在职在职离退离退合计合计 财务处财务处346417595223 人事处人事处370219785680 后勤集团后勤集团252 252 表二 财务处、人事处、后勤集团人员总数统计表3 在职在职财务处财务处人事处人事处后勤集团后勤集团 财务处财务处34643422(-280)121(-131) 人事处人事处3702221(-31) 后勤集团后勤集团252 表三 财务处、人事处、后勤集团在职人员数量比较表 “（）”内为差额3 信息孤岛问题数据库层优化解决方案设计 12 离退休离退休财务处财务处人事处人事处 财务处财务处17591758（-220） 人事处人事处 1978 表四 财务处、人事处离退休人员数量比较表 “（）”内为差额3 编号编号人事处在职人员单位人事处在职人员单位财务处在职人员单位财务处在职人员单位 1 发展规划办公室校办公室 2 人事处人才中心 4 学校办公室校办公室 5 招生办公室招生办 6 科学技术处科研处 7 社会科学研究处科研处 8 学生工作部(处)学生处 9 国际合作与交流处外事办 10 离退休工作部(处)离退休处 11 人文学院人类所 12 经济学院经济研究 13 艺术教育学院艺术学院 14 生命科学学院生命学院 15 数学科学学院数学系 16 医学院抗癌中心 17 化学化工学院化工学院 18 海洋与环境学院海洋环境 19 信息科学与技术学院信息学院 20 物理与机电学院物理学院 21 建筑与土木工程学院建筑系 22 马列主义理论部马列室 23 体育教学部体育室 24 南洋研究院南洋所 26 教育研究院高教所 27 现代教育技术中心现代中心 28 自然科学版学报自然学报 29 哲学社会科学版学报哲社学报 30 计算机网络中心网络中心 32 资产经营有限公司经营公司 33 资产与后勤事务管理处资产后勤 34 实验室与设备管理办公室实验办 35 公共事务学院公共学院 表五 财务处、人事处同单位异名表3 3.1.2 数据无实时共享 经过实地调查研究发现，该高校校内各部门系统之间共享基本停留在人工拿介质拷贝层 次，基本没有数据共享实时性可言。 信息孤岛问题数据库层优化解决方案设计 13 3.1.3 冗余代码表侵吞系统资源 考察发现各部门系统都在不同程度上有代码表冗余现象，一些已废弃不用的代码表长期 占据着大量的存储空间。 3.1.4 信息的重复输入 该校有一名姓林的同学，因为入学时教学秘书的疏忽，将名字输入错误，导致该生在校 期间在招生办、教务处、学生处等部门重复递交申请修改姓名，这都是在数据不能共享情况 下出现的异常现象。 3.1.5 统计报表的参考价值令人置疑 简单举例来说，人事处、财务处统计来的职工人数，领导该相信哪一个？ 3.2 信息化项目组的成立和所面对的问题 A 高校领导会同管理学、计算机等方面专家经过反复的研讨协商，酝酿多年后，成立了 由主管校长领衔，计算机、管理等方面专家共同组成顾问团的校园信息化领导机构，并与 2004 年 5 月成立了校园信息化项目组，专职负责根据信息化建设的特点，按照科学、规范、 标准化的原则开展，从全校全局出发，建立信息化建设的总体规划。信息化项目组作为学校 的信息化核心机构，参与实施和协调所有校园信息化相关项目的建设。 信息化项目组目前直面的主要问题是以下几点4： 整个校园信息化建设缺乏统一规划和标准，对于不同的应用系统，用户需要在不 同位置逐个进入访问，缺乏统一的访问资源和应用接口，不方便用户使用； 各单位认识不一致，发展不平衡，各单位的应用系统是在不同时间由不同人群研 发完成，应用系统间的数据共享还有赖于落后的磁盘甚至是纸介质等低效率的方 式，缺乏协调，形成了网络环境下大量的“信息孤岛”； 重硬件轻软件，仅购置大量的硬件设备，缺乏功能好质量高的应用系统，没有充 分发挥信息系统在管理教学科研方面的作用； 校园网上应用系统和信息资源越来越多，缺乏有效的组织和管理，经常出现的信 息安全问题、人员管理问题影响着信息系统真正为教学科研和管理工作服务。 为信息孤岛问题寻求解决方案，实现校园内所有部门的信息共享成为信息化项目组面对 的首要问题。 下面两章都将在此案例的基础上进行探讨。 信息孤岛问题数据库层优化解决方案设计 14 第 4 章分布式规划联邦式过渡的数据库优化架构方案设计 4.1 设计原理 A 高校的计算机系统是逐步发展的，先在各个地理上分散的部门建立一些孤立的数据库 系统。现在对这些己运行的而且基本都是异构的数据库之间提出数据流通的需求。立刻将这 些己存在的系统完全集成为一个分布式数据库是困难的甚至是不可能的。联邦式数据库系统 是“信息孤岛”问题很好的概念解决，但其实现代价高，技术上也很复杂，在性能上和分布 式数据库有较大差距。 在综合考虑以上因素，我们提出分布式规划、联邦式过渡的数据库系统优化解决方案， 所谓分布式规划是从长远的角度考虑，高校可以通过成立信息中心或数据库中心参与管理， 对新建设的系统进行统一规划，都要求集成到采用分布式架构的中央数据库中，而对老系统 暂时采用联邦式集成作为一种低成本的过渡性手段，随着时间的推移旧系统逐步淘汰后，最 终形成纯分布式集中数据库架构。 图六 分布式规划、联邦式过渡架构示意图 4.2 中央数据库设计 中央数据库为分布式架构，基本原则：对用户来说，分布式系统看起来应当就像非分布 式系统一样。 分布式系统的 Data 12 条规则5： 本地自主性 对中心结点没有依赖性 连续操作 位置独立 分段独立性 复制独立性 分布式查询处理 信息孤岛问题数据库层优化解决方案设计 15 分布式事务处理 硬件独立性 操作系统独立性 网络独立性 数据库独立性 除了最后四条是较理想化的，其他规则都是我们必须完成的设计目标。 4.2.1 物理设计 图七 校园信息化数据库服务器架设图6 根据分布式数据库系统的需要，我们对校园内数据库服务器的架设做了如图七的配置， 其中中央数据库采用多主体同步复制，各院系服务器则与中心数据库进行异步实体化视图复 制，物理设计相关内容请参考相关文献，因其不是本文主旨，在此不多予以赘述。 4.2.2 逻辑设计 如图八所示，新建分布式中央数据库由三部分组成：部门（院系）表、代码库及映 射代码库。该设计具有如下几个特点： 新建部门数据库使用实体表。由于新建分布式数据库系统最终将替代现存数据库， 所以对中央数据库设计采用实体表，而非纯联邦式的虚拟表。 数据标准化。设计严格的遵守国家教育部编制的教育管理信息化标准。标准代码 库包括：共享代码库，即：整个信息化管理系统都可能用到的标准化代码；私有 代码库，即：只有某些部门需要使用的标准化代码；其他代码库，即：已经存在， 但尚未使用的标准化代码。经过数据标准化之后，数据库中数据均以标准化的代 码格式储存。 高安全性。从数据库安全角度考虑，实行数据屏蔽，将数据库分成三类库保存， 部门实体表中表名、字段名、字段内容基本都用代码表示。通过程序控制实体表 和代码表的对应关系，发生数据库泄漏时，拿到任何一个代码库固然无用，拿到 实体库也会因为无法识别其中代码涵义而保证数据的秘密性，大大降低了因数据 库泄漏而引发的安全性问题。代码库又分为三种：共享代码库，私有代码库和其 信息孤岛问题数据库层优化解决方案设计 16 他代码库，除了共享代码库，各部门只能访问自己相关的私有和其他代码库，进 一步提高了系统的安全性。 高契合度。为了方便使用，映射库包含了表名映射库、字段名映射库和字段内容 映射库，用于处理各种对象名称和代码的映射过程。映射代码库的建设为现存数 据库和新数据库的衔接提供了充分的支持，使得新旧数据库间联邦式对接成为可 能。 开发复杂性较高。高安全性通常意味着高复杂性，本设计也未能例外，在程序开 发过程中要求对实体表和代码库之间进行详细的定义，这对应用程序开发人员和 数据库设计人员都是一个挑战，唯有二者齐心协力方能拨云见日。 映射代码库建设任务艰巨。映射代码库是新旧数据库衔接的关键，两者需要映射 的内容成山成海，为使二者畅顺对接，数据库整理人员工作量难以估量。 图八 分布式规划、联邦式过渡系统架构逻辑结构 信息孤岛问题数据库层优化解决方案设计 17 4.3 联邦式过渡典型案例：人事处系统整合 4.3.1 人事处现有数据库系统架构分析 图九 人事处现存数据库系统结构拓扑图 A 校人事处现存应用系统为客户端服务器（CS）架构，数据库使用 Microsoft SQL Server 2000，架设在人事处机房的一台 HP NETSERVER2000 服务器上，经过多次调研，基本 确认了人事处数据库系统逻辑架构，如图九所示，人事处实体表内容由多重数据字典表定义。 首先，实体表名由两部分组成成分类别、集合，分别由 SR_Unittype 和 SR_SourceCollect 定义，其中 SR_sourceCollect 中的 SetId 又关联到 SR_SourceItem，后 者定义了实体表中字段名称、长度以及所涉及字段内容代码集 CodeId，在 SR_CodeCollect 中可以找到 CodeId 的含义，最终 sr_codeitem 和 sr_depertment 的 50000 多条记录明确了 字段内容的含义，在这两张表中 code 和 description 对上了号，CodeId 在这里将 code 分 类，同时避免了代码重名。 不用细述就可以看出，人事处现行数据库结构与新建中央数据库是格格不入的，在不能 马上重建新系统的情况下，如何解决仍在使用中的人事处数据库与中央及其他部门之间的数 据共享？联邦式数据库系统架构为我们提供了一条道路。 4.3.2 联邦式数据库整合面对问题 联邦式数据库整合过程一般分三步走： 根据中央分布式数据库设计规范设计新部门数据库； 设计共享同步策略； 信息孤岛问题数据库层优化解决方案设计 18 时机成熟时，建设新系统，对旧数据库进行彻底数据库移植，淘汰旧数据库。 这个过程在上一节中已有介绍，现在仅就新数据库设计完毕后，新旧数据库同步、移植 相关问题进行探讨。 4.3.2.1 数据共享同步 联邦式数据库架构中，异构数据库之间共享和同步的并不是分离的概念，共享是由同步 实现的，如何同步更新本地（旧）数据库和中央（新）扩展的数据库是必须要解决的问题。 图十 带准备态的状态转移图7 联邦式数据同步需要在两个层次上采取措施： 应用层：两阶段提交。对应用程序进行双向提交修改，在此过程中需要考虑事务 阻塞等的情况下的处理方案，这方面比较成熟的方案是如图十所示的两阶段提交 方案，详细资料请参考魏昕路在年做的研究报告。 数据库层：数据转换复制。两阶段提交解决了数据同步的实时性问题，但因其涉 及到应用程序修改，实现困难较大，根据现存信息孤岛除了部分实时性要求较高 的如财务相关部门，其他有很多同步共享对实时性要求并不高，半天同步一次或 一天甚至一星期同步一次也可，向这类同步需求，对其也进行两阶段提交的应用 层修改，复杂性和成本都过高，必须提出一种较经济的解决方案，数据库层数据 复制勿庸置疑的成为了一种首选的方案。它有两个明显的优点：复杂性稍低、通 用性高。不仅可以直接用来独立完成同步，而且可以为两阶段提交提供周期性同 步，增加两阶段提交的可靠性。不过，由于异构数据库之间数据缺乏统一的规范， 因此复制时必需要对数据进行转换。转换完毕才能将数据加载到新数据结构中去， 基本上就是说，在数据转换复制过程中需要增加一个数据清洗式的步骤。 4.3.2.2 数据一致性 由于使用了不同的代码标准（旧数据库系统未必使用国标编码），对新旧数据库之间进 行共享同步必须面对不同的编码标准带来的数据一致性问题。如：人事处性别代码，女为 1、男为 2，而新标准代码男为 1、女为 2；设计方案中必须考虑对这种情况的处理。 4.3.2.3 数据库移植 当旧数据库彻底报废时，移植遗留数据是一个主要问题，数据的移植首先需要的也是数 据转换，他主要涉及到三个步骤： 信息孤岛问题数据库层优化解决方案设计 19 备份遗留数据 转换遗留数据到新格式 加载数据到新数据库 4.4 数据库转换移植工具的需求 上一节中提到了进行联邦式数据库整合必须面对的问题，显然要实现联邦式整合，我们 必须设计一种方式来转换数据，进行数据库复制、移植，因为要联邦解决的信息孤岛不止一 个，频繁的接口设计必然耗费大量的工作和时间，设计一种通用的数据转换移植工具成为必 要的措施。 4.4.1 现有市场上通用数据库转换复制方案 现有市场上异构数据库移植工具，主要是由几家大型数据库厂商在其主流数据库产品同 构复制的基础上，进一步地提出的。他们的异构数据库复制方案，最有影响的包括 Oracle 主张通过数据库转换器，Sybase 利用 LTM (日志传输器)，IBM 使用数据变化表 （Consistent-Change Data Table），微软则提出出版者/订阅者方案等。这些方案各有所 长，但在一定程度上还存在着局限性。各个数据库厂商由于要体现自己产品的特点及其他一 些原因，由他们各自提出的方案都采用与 DBMS 核心关系紧密的实现技术，因此不一定适用 于其它 DBMS，彼此之间的兼容性较差。再者，各方案普遍存在着符合某种体系结构或标准 的前提，因此导致对系统资源的要求较高而应用范围却受到限制。总体说来目前的状况是不 能让人满意的。 4.4.2 TransBuilder 的提出：针对优化数据库架构方案开发通用数据库转 换复制工具 由于市场上没有适用的成熟产品，而联邦式架构中有大量的异构数据库数据转换移植的 需求，信息化项目组与年 3 月 24 日决定开发针对分布式架构、联邦式过渡的优化数据库架 构方案开发通用数据库转换复制工具 TransBuilder。 根据联邦式数据库架构的需要，TransBuilder 必须具有如下特点： 支持完全异构。除支持一对一复制外，支持从几张表中抽取字段复制入另一张表。 支持代码实值间转换配置。数据库中存在大量字典表、代码表，在数据复制过程 中由于源数据库和目标数据库代码规范未必相同，所以，必须将数据进行代码实值 之间转换，可配置性是必然的要求。 支持详细错误记录。在转移过程中，可能出现源数据库的实值无法和目标数据库中 的字典内容完全相同，如表四.4 中所示的同单位异名，对于这种情况计算机是无法 直接识别处理的，生成详细错误记录，可以帮助中央数据库中映射表的建立，从而 最后协助计算机进行异值识别和转换。 支持保存转换复制配置信息。需要转换复制的不止两三个数据库，每两个数据库之 间的复制也并不一定只有一个，配置任务本身又是一项相当繁琐的工作，每次转换 前都需要配置一次的话，情况是难以想象的，所以对每次配置完的结果进行保存是 非常必要的。 支持定期执行。未来，起码在旧数据库系统淘汰之前，异构数据库之间的转换复制 将是经常性需求，比如一天一次的复制级同步，任务能定期自动执行将节省大量人 力物力。 信息孤岛问题数据库层优化解决方案设计 20 第 5 章TransBuilder 设计 5.1 功能需求 TransBuilder 主要需要提供的功能就是：数据转换和数据复制。 第五章第 5 节中已经在描述 TransBuilder 的提出中介绍了数据库转换移植工具的详细 需求。 5.2 面向过程的软件设计 TransBuilder 的功能需求基本上都属于过程性的，包括它本身都是一个过程。因此， 对该软件的功能设计我们采取了模块化的面向过程的设计模式。下面我将用流程图的形式详 细的介绍 TransBuilder 的功能设计。 5.2.1 四大模块 如图十一所示，TransBuilder 整体上可分为两个内容：任务创建，任务执行。 其中任务创建又可以细分为取得源表模块、打开目标表模块和导入导出内容设置模块。 因此，整个软件共有四大模块。 图十一 TransBuilder 的四大模块 信息孤岛问题数据库层优化解决方案设计 21 5.2.1.1 打开源表模块 图十二 打开源表模块 信息孤岛问题数据库层优化解决方案设计 22 数据在数据库中以表的形式存储，上面已经提到，在数据转换复制过程中有多对一复制 的要求，因此，打开源表模块中，程序必须提供打开多个源表，在这个过程中我们为了保证 清晰性，将程序设置为打开一个取出需要的字段完毕后，再打开另一张表开始取。 数据库中表、字段繁多，数据库设计人员一般会用代码标识列名，而将列名描述另存与 代码表中。因此，为了后面导入导出配置时可以自动识别，同时使配置人员不至于身陷列海 不能自拔，在选择了列后将对列对应的代码表进行配置，以取得列名描述备后面使用需要。 此外，对于列名代码表中数据内容错误进行判断，检查是否有缺失性错误，如果存在该 类错误则进行记录，弹出错误报告。 最后，在该模块设计中，我们为将来有完整映射表存在时预留了自动拟合模块的接口。 5.2.1.2 打开目标表模块 图十三 打开目标表模块 打开目标数据库表模块配置思想和取得源表模块类似，但为了降低设置复杂性我们不进 行一对多、或者多对多复制，所以对于目标表的打开，只对一张表进行处理。 在此模块设计中同样预留了自动拟合接口。 信息孤岛问题数据库层优化解决方案设计 23 5.2.1.3 数据转换设置模块 图十四 源与目标字段对应关系设置模块 该模块操作位于源和目标表打开之后，由两个分模块共同组成：源与目标字段对应关系 设置模块（图十四）及数据转换设置模块（图十五）。 源与目标字段对应关系设置模块：异构数据库复制必须首先设置源和目标的字段 对应关系，对于这种配置当然可以通过人工指定来实现，当然这种指定操作是大 量而枯燥的，为了将配置人员从繁复的指定操作中解放出来，我们在设计中加入 了自动拟合功能，利用前两个模块中取得的字段名描述，对相同描述的进行自动 匹配。配置人员只需对无描述或描述不同字段进行手动指定。 数据转换设置模块： 本模块分为两个部分实现：对源数据字段集中部分以代码存储字段进行代码与对应 实值转换设置，以及，对目标数据库表中需要以代码存储的字段进行实值转代码方式配 置。 对这两个部分的操作基本都是：指定代码所对应字典表及代码表，指定代码对应列， 指定实值所在列。因为每个数据库机构不同，所以这部分的所有操作包括判断都是需要 配置人员自行识别完成的。 最后，每次配置完，配置信息都会被保存下来。 信息孤岛问题数据库层优化解决方案设计 24 图十五 数据转换设置模块 5.2.1.4 转换测试及执行模块 完成了以上的所有配置后，就可以进行测试和执行。 为了保证数据库的转换过程的正确性和完整性，在执行前必须对所有转换复制工作进行 测试，测试完全通过后才能进行执行。 整个测试过程和配置流程相似，先对源数据字段内容转换进行测试，主要考察是否有缺 失值、多值对应等类型匹配问题，如发现存在匹配问题，将记录下来，全部检查完毕后给出 错误记录。 通过了源转换测试，就可以进入目标数据内容测试，此时主要对源数据字段中需要在目 标表中保存为代码的字段进行测试，对目标字段内容代码表中源取出的实值的进行存在性检 查。一旦发现有不存在情况，同样，系统会记录下来，测试结束后给出错误记录。 错误记录有两个作用：1）帮助配置人员发现错误设置；2）帮助源和目标数据库管理员 就错误项进行协商更正。 执行：只有在前两项检测全部通过后，系统才会进入执行状态，将数据按照配置从源数 据库转换复制到目标数据库中去。 信息孤岛问题数据库层优化解决方案设计 25 图十六 转换测试及执行模块 5.3 存在问题及解决方案 上面介绍了 TransBuilder 的设计方案，下面就其设计中存在的问题及解决方案进行一 定的探讨。基本上来说，TransBuilder 存在的问题在 3 个方面： 信息孤岛问题数据库层优化解决方案设计 26 效率：由于使用的复制方法是完全复制，而不是通过监视变化进行的增量复制， 这使得复制效率稍低。 数据弱一致性：使用定时复制技术，在进行两次复制之间的这段时间内，不能 保证多个数据副本之间的数据一致性，称这种一致性为弱一致性。 处理时间滞后：由于是定时复制技术，所以在主数据库中新增加或修改的信息 不能立即反映到从数据库中，数据传送的滞后就会造成事务处理时间的滞后。 根据存在问题的情况，我们设计了如下的解决方案： 对实时性要求较高的需求，采用应用层和数据库层双重同步。前文已经提过， 由于采用数据库层同步的同步面向的都是实时性要求不高的需求，所以采取 完全复制对效率的影响并没有想象中严重。对于实时性要求较高的需求，可 以参考使用应用层和数据库层双重同步。 系统提供手动复制。在获知复制源数据已经发生改变，但复制周期还未到的 时候，而确实有需要的情况下，可以启动手动复制。 科学的设置复制周期。这种由定时进行数据复制引起的事务处理时间的滞后， 在多大程度上可以让使用者接受，这是设置复制操作周期的重要依据。 5.4 TransBuilder 的应用前景和展望 TransBuilder 是为解决信息孤岛中联邦式过渡问题开发的，但它的使用范围大大超过 了它的起源，由于在设计和开发过程中，始终考虑到系统的通用性问题，使得它对数据库同 步特别是异构数据库相关领域有广泛的支持，应用前景广阔。 信息孤岛一天不解决，信息化就只能原地踏步。笔者在研究信息孤岛问题时，参考了许 多企业案例，发现这些遇到问题的企事业单位，无一不曾经对信息化满腔热血、充满憧憬， 而如今又无一不被信息孤岛困扰的鼻青脸肿，每念及此，心