1、本科毕业论 文(科研训练、毕业设计)题 目：信息孤岛问题数据库层优化解决方案设计姓 名： 学 院： 软件学院 系：专 业： 软件工程年 级： 学 号： 指导教师（校内）： 职称： 指导教师（校外）： 职称：年 月 日信息孤岛问题数据库层优化解决方案设计 1信息孤岛问题数据库层优化解决方案设计摘要 通过对信息孤岛问题的现状和目前流行的数据库层解决方案进行详实的分析，提出了一种分布式规划、联邦式过渡的数据库优化架构设计方案，以高等院校数据孤岛问题为实例，详细阐述了中央分布式数据库逻辑设计，以及对现存异构数据库的联邦式整合方案。对整合方案中涉及的数据转换移植需求进行分析，提出开发 TransBuil
2、der 数据库通用转换移植工具的设想，使用面向过程的软件设计方法对 TransBuilder 进行了完整的功能流程设计。关键词 信息孤岛 分布式数据库系统 联邦式数据库系统 数据转换 校园信息化信息孤岛问题数据库层优化解决方案设计 2Database layer optimization solution for Isolated Information IslandAbstract This thesis analyzes the exiting issue- Isolated Information Island and the popular solutions. Later, this
3、 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 soluti
4、on 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 Syste
5、m; Federated Database System; Data transform; Campus Computing信息孤岛问题数据库层优化解决方案设计 3目 录第 1 章 引言 .41.1 研究背景 .41.2 本研究的理论和实际意义 .41.3 相关领域的研究进展和成果 .51.4 主要研究内容 .51.5 本文的组织 .5第 2 章 信息孤岛的产生和目前一般的解决方案 .62.1 信息孤岛的产生、现状和危害 .62.2 信息孤岛目前一般的数据库层解决方案 .7第 3 章 信息孤岛问题实际案例 .113.1 A 高校的信息孤岛问题 .113.2 信息化项目组的成立和所面对的问题 .
6、13第 4 章 分布式规划联邦式过渡的数据库优化架构方案设计 .144.1 设计原理 .144.2 中央数据库设计 .144.3 联邦式过渡典型案例：人事处系统整合 .174.4 数据库转换移植工具的需求 .19第 5 章 TRANSBUILDER 设计 .205.1 功能需求 .205.2 面向过程的软件设计 .205.3 存在问题及解决方案 .255.4 TRANSBUILDER的应用前景和展望 .26致谢 .27参考文献 .28信息孤岛问题数据库层优化解决方案设计 4第 1章 引言1.1 研究背景“信息化校园计划”（The Campus Computing Project）最早是 199
7、0 年由美国克莱蒙特大学教授凯尼斯格林（Kenneth Green）发起并主持的一项大型科研项目。高校信息化建设的目标是建设一个数字校园，以网络为基础，利用先进的信息化手段和工具，实现从环境（包括设备、教室等）、资源（如图书、讲义、课件等）到活动（包括教、学、管理、服务、办公等）的全部数字化，在传统校园的基础上构建一个数字空间，以拓展现实校园的时间和空间维度，提升传统校园的效率，扩展传统校园的功能，最终实现教育过程的全面信息化。从而达到提高教育管理水平和效率的目的。原有的在缺乏统一规划的情况下建设的各种应用系统，由于信息无法共享，形成了一个个“信息孤岛”（图一），大大妨碍了信息化建设的进程，解
8、决数据孤岛问题是信息化建设起步面对的首要问题。图一 连在一起的信息孤岛1.2 本研究的理论和实际意义理论意义：信息孤岛的根源在数据源共享问题，目前解决该问题的方法主要有两种：分布式或联邦式数据库系统架构，本研究旨在对两种系统架构模式进行探讨，指出其优点，揭露其缺陷，通过比较性研究和实际案例实践，在理论上提出一种新的分布式规划、联邦式过渡的数据库系统架构优化方案。实际意义：本文作者隶属于厦门大学校园信息化建设项目组，该项目组成立于 2004 年5 月，本人所在科研管理系统开发团队由七人组成，其组织结构如图二所示。本人在其中主要致力于信息孤岛问题的解决方案的设计和实现，完成数据库转换移植工具的设计
9、。通过实践中考察到信息孤岛问题在企事业单位信息化中存在的普遍性，作者对相关方面的问题进行了广泛的思考和实践，从理论到实现，为信息孤岛问题的解决设计了整套切实可行的方案。解决方案实施关键工具 TransBuilder 的设计和实现填补了当前可配置数据移植工具的信息孤岛问题数据库层优化解决方案设计 5空白。图二 科研管理系统开发团队协作图1.3 相关领域的研究进展和成果信息孤岛问题的解决方案在数据库层主要集中在分布式和联邦式之争。本文将在第三章详细客观的介绍这两种数据库系统架构方案。数据移植领域，主要由数据库开发商提供开发了一些移植工具，如：微软随 SQL Server 附送的 Data Tran
10、sformation Services（DTS），Oracle 的移植工作台等，这些工具的设计目的多为将数据库从其他数据库供应商的产品上复制到自己的产品上，以及作为数据备份工具使用，其功能要点集中在复制上，对异构数据库之间的转移支持并不良好，甚至不支持。1.4 主要研究内容 数据库系统架构 可配置数据移植工具 TransBuilder 的设计和实现1.5 本文的组织第一部分 研究简介（第 1 章）第二部分 信息孤岛的含义和目前数据库层解决方案概述（第 2 章）第三部分 描述具体典型案例，清晰信息孤岛问题（第 3 章）第四部分 数据库架构方案设计（第 4 章）第五部分 数据库移植方案和工具设计（
11、第 5 章）信息孤岛问题数据库层优化解决方案设计 6第 2章 信息孤岛的产生和目前一般的解决方案2.1 信息孤岛的产生、现状和危害2.1.1 信息孤岛的产生在构建某个应用系统时，目前大多采用“独立解决方案”，开发者和需求部门应用逻辑相结合，在特定的操作系统平台上、特定的集成开发环境下、基于特定的数据表达格式，进行特定数据库设计和应用软件系统的开发，很少考虑应用的可集成性、可重用性、可定制性、可移植性，造成了众多软硬件平台、各类应用系统并存的局面。图三 系统接口数量 N（N1）当众多系统间需要信息共享时，往往以某一个或某几个关键应用系统为主，基于系统提供接口进行二次开发，在需要共享信息的系统间由
12、特定的程序员提供复杂的访问接口，与其它系统进行整合，是一种复杂系统对接的模式。假定企业中有 N 个系统需要共享数据资源，那么需要特定的程序员开发复杂的单向接口就是 N（N1）个（图三）。于是，企业不得不为每套应用配置特有的专业技术维护人员（至少是数据库管理员），并保持与不同技术供应商的密切联系，接口的复杂性和大量化以及不同技术供应商之间的工作协调往往使企事业单位望而生畏，结果往往形成了众多的信息孤岛和小规模的紧密集成。2.1.2 信息孤岛的现状随着现代信息技术和 Internet 技术的飞速发展，企事业单位的管理方式也一直发生着变革，基于网络的管理模式已成为优化企事业单位管理的有效途径和发展趋
13、势。网络化管理通常涉及多个部门甚至多个单位，具有异地工作环境、异构工作平台、并行协同工作等特点，其实施的基础是企事业单位应用系统的有机集成与管理信息的有效共享。目前，我国很多企事业单位通过市场采购或自主开发，拥有了多种 OA 和 MIS 系统软信息孤岛问题数据库层优化解决方案设计 7件，这些都为管理信息化积累了一定的经验。可是由于没有统一的架构和管理，以及传统应用开发模式的局限和系统集成方法的落后，形成了众多的数据源孤岛或紧耦合应用，严重阻碍了企事业单位信息的流通和信息化的进一步发展。2.1.3 信息孤岛的苦果信息孤岛的产生让不少信息化走在前沿的企事业单位尝尽了苦果，尤其突出表现在以下五个方面
14、： 数据的一致性无法保证。由于信息定义与采集过程彼此独立，单位中同一数据可能在不同的应用中不一致。 信息及时共享、反馈难。信息不能及时充分共享的矛盾突出，单位中“信息孤岛”林立。 企业存冗余垃圾信息。 由于各个系统独立，存在大量不必要数据，使访问数据库的速度降低。 信息需要重复多次的输入。对信息的多次采集不仅仅是额外的劳动，数据失真也是重复输入的恶果之一。 信息化进程遇到障碍。无法对信息孤岛进行联机分析处理（OLAP）、数据仓库（DW）建设，妨碍了对企业附加值的数据挖掘（DM）和决策支持系统（DSS）的构建。2.2 信息孤岛目前一般的数据库层解决方案多应用系统集成是目前最流行也是使用和探讨最广
15、泛的信息孤岛解决方案。现行的多数据库应用系统集成方案，主要分为前台应用层解决方案和后台数据库层解决方案，其中，数据库层是人们最关心的，治病治根，信息孤岛的根就在数据库上，因此，如何解决好数据库层是整个集成方案的关键。目前，对数据库层的集成一般有两种方案：分布式数据库系统、联邦式数据库系统。2.2.1 分布式数据库架构图四 DDBS 环境 2信息孤岛问题数据库层优化解决方案设计 8多应用系统必然对数据有分布式存储需要，对分布式数据的管理和访问就成为必须解决的问题。由于一个事务所涉及的数据可能分布在多个结点上（如图四），这就要求数据库系统具备一个优化的分布查询策略。对于这种分布执行的事务，系统要保
16、证事务执行的原子性和可串行化，以及解决分布环境下的安全问题、恢复问题、分布透明性、节点自治、全局命令空间、分布式查询、分布式更新、数据分布与复制、两阶段提交(2PC)、网络数据字典(NDD)等关键问题。分布式数据库系统正是为解决上述问题而设计的。一个分布式数据库系统由一个逻辑数据库组成，这个逻辑数据库的数据存储在一个或多个结点的物理数据库上，通过两阶段提交(2PC)协议来提供透明的数据访问和事务管理。分布式数据库系统在系统结构上的真正含义是指物理上分布、逻辑上集中的分布式数据库结构。数据在物理上分布后，由系统统一管理，使用户不感到数据的分布。用户看到的似乎不是一个分布式数据库，而是一个数据模式
17、为全局数据模式的集中式数据库。分布式数据库有性能高、可扩充性好、可用性好以及具有自治性等优点。分布式数据库系统仍存在不足：由于数据库系统的应用通常是逐步发展的，起先是建立各种孤立的数据库，而管理这些数据库的计算机系统和 DBMS 包括数据模型很可能是不同的，也就是异构的(Heterogeneous)。当应用需要转向分布式数据处理时，抛弃原有的系统另砌炉灶显然是不合理的，这就需要解决异构数据库的集成问题。这在技术上有一定的复杂性，而且目前还很难用一个通用的 DBMS 来解决这样的问题。我们希望一种新的数据库技术联邦数据库系统(Federated Database System)能解决这一问题。此
18、外分布式数据库系统虽然有利于改善性能，但如果数据库设计不好，数据分布不合理，使远距离访问过多，特别是当分布连接操作过多时，都会降低系统的性能。2.2.2 联邦式数据库架构分布式数据库系统不能很好解决的异构数据库的集成问题，可以通过建立联邦数据库系统来解决。通常称相互独立运行的数据库系统为单元数据库系统(Component DBS)。它是原本存在的、在局部地区应用的数据库系统，它们是联邦数据库系统的一部分。所谓联邦式数据库系统是一种物理上分布、逻辑上分布的分布式数据库结构。这种分布式数据库结构的特点是结点自治(Site Autonomy)和没有全局数据模式(Global Data Schema)
19、。每个结点所看到的数据模式仅仅限于该结点所用到的数据。它一般由两部分组成：一是本结点的数据模式，二是供本结点共享的其他结点上的有关的数据模式。结点间的数据共享由双边协商确定。如果一个新的结点要加入系统，它开始时可先用本结点的数据，然后与有关结点协商，共享其他结点的有关数据；本结点的数据同样可被其他结点共享。这种扩展完全是渐进的，不会影响原有系统的运行。由于每一个结点所看到的数据模式是不一样的，就好像系统中有多个逻辑数据库，因而在逻辑上这种数据库结构也是分布式的（图五）。信息孤岛问题数据库层优化解决方案设计 9图五 联邦式数据库系统扩展方式由于无全局数据模式，一个结点的数据模式的修改甚至一个结点的加入或撤离，仅仅影响有关的结点。一个结点在给数据对象命名时，只要求在本结点的数据模式内唯一，无需考虑与其它无关数据对象的重名问题。每个结点好像拥有一个满足自己需要的集中式数据库一样，而不受制于全局数据模式，甚至不必有“全局观念”，结点具有很高的自治性。联邦式数据库结构有利于数据库的集成、扩展和重新配置，但因为现有网络系统并不具备够大的延展性，可以在大量资料上做平行运算，所以其性能不如集中式数据库高，而且实现代价较高，技术上也很复杂，如不同数据系统的数据模式转换，全局事务的管理及其串行性等。
