信息孤岛问题数据库层优化解决方案设计汇编.docx

信息孤岛问题数据库层优化解决方案设计汇编.docx

《信息孤岛问题数据库层优化解决方案设计汇编.docx》由会员分享，可在线阅读，更多相关《信息孤岛问题数据库层优化解决方案设计汇编.docx（36页珍藏版）》请在冰豆网上搜索。

信息孤岛问题数据库层优化解决方案设计汇编

本科毕业论文

（科研训练、毕业设计）

题目：

信息孤岛问题数据库层优化解决方案设计

姓名：

茅晓白

学院：

软件学院

系：

专业：

软件工程

年级：

2003级复合型

学号：

99100033

指导教师（校内）：

姜青山职称：

教授

指导教师（校外）：

职称：

2005年6月1日

信息孤岛问题数据库层优化解决方案设计

[摘要]通过对信息孤岛问题的现状和目前流行的数据库层解决方案进行详实的分析，提出了一种分布式规划、联邦式过渡的数据库优化架构设计方案，以高等院校数据孤岛问题为实例，详细阐述了中央分布式数据库逻辑设计，以及对现存异构数据库的联邦式整合方案。

对整合方案中涉及的数据转换移植需求进行分析，提出开发TransBuilder数据库通用转换移植工具的设想，使用面向过程的软件设计方法对TransBuilder进行了完整的功能流程设计。

[关键词]信息孤岛分布式数据库系统联邦式数据库系统数据转换校园信息化

DatabaselayeroptimizationsolutionforIsolatedInformationIsland

[Abstract]Thisthesisanalyzestheexitingissue---IsolatedInformationIslandandthepopularsolutions.Later,thisthesisadvancesanoptimizedsolutionwhoseultimateaimisdistributeddatabasebutadoptfederateddatabaseasatransition.ThisthesistakesIsolatedInformationIslandincampuscomputingasanexample,illustratesthelogicaldesignofdistributeddatabaseandthefederatedintegrationsolutionforHeterogeneousDatabases.Afteranalyzingtherequirementsofdatamigrationinintegrationsolution,thisthesisputforwardtheideaofdesigningadatabasemigrationtoolandpresentsthedesignschemaofDatamigrationtool.

[KeyWords]IsolatedInformationIsland;DistributedDatabaseSystem;FederatedDatabaseSystem;Datatransform;CampusComputing

目录

第1章引言4

1.1研究背景4

1.2本研究的理论和实际意义4

1.3相关领域的研究进展和成果5

1.4主要研究内容5

1.5本文的组织5

第2章信息孤岛的产生和目前一般的解决方案6

2.1信息孤岛的产生、现状和危害6

2.2信息孤岛目前一般的数据库层解决方案7

第3章信息孤岛问题实际案例11

3.1A高校的信息孤岛问题11

3.2信息化项目组的成立和所面对的问题13

第4章分布式规划联邦式过渡的数据库优化架构方案设计14

4.1设计原理14

4.2中央数据库设计14

4.3联邦式过渡典型案例：

人事处系统整合17

4.4数据库转换移植工具的需求19

第5章TransBuilder设计20

5.1功能需求20

5.2面向过程的软件设计20

5.3存在问题及解决方案25

5.4TransBuilder的应用前景和展望26

致谢27

[参考文献]28

第1章

引言

1.1研究背景

“信息化校园计划”（TheCampusComputingProject）最早是1990年由美国克莱蒙特大学教授凯尼斯·格林（KennethGreen）发起并主持的一项大型科研项目。

高校信息化建设的目标是建设一个数字校园，以网络为基础，利用先进的信息化手段和工具，实现从环境（包括设备、教室等）、资源（如图书、讲义、课件等）到活动（包括教、学、管理、服务、办公等）的全部数字化，在传统校园的基础上构建一个数字空间，以拓展现实校园的时间和空间维度，提升传统校园的效率，扩展传统校园的功能，最终实现教育过程的全面信息化。

从而达到提高教育管理水平和效率的目的。

原有的在缺乏统一规划的情况下建设的各种应用系统，由于信息无法共享，形成了一个个“信息孤岛”（图一），大大妨碍了信息化建设的进程，解决数据孤岛问题是信息化建设起步面对的首要问题。

图一连在一起的信息孤岛

1.2本研究的理论和实际意义

理论意义：

信息孤岛的根源在数据源共享问题，目前解决该问题的方法主要有两种：

分布式或联邦式数据库系统架构，本研究旨在对两种系统架构模式进行探讨，指出其优点，揭露其缺陷，通过比较性研究和实际案例实践，在理论上提出一种新的分布式规划、联邦式过渡的数据库系统架构优化方案。

实际意义：

本文作者隶属于厦门大学校园信息化建设项目组，该项目组成立于2004年5月，本人所在科研管理系统开发团队由七人组成，其组织结构如图二所示。

本人在其中主要致力于信息孤岛问题的解决方案的设计和实现，完成数据库转换移植工具的设计。

通过实践中考察到信息孤岛问题在企事业单位信息化中存在的普遍性，作者对相关方面的问题进行了广泛的思考和实践，从理论到实现，为信息孤岛问题的解决设计了整套切实可行的方案。

解决方案实施关键工具TransBuilder的设计和实现填补了当前可配置数据移植工具的空白。

图二科研管理系统开发团队协作图

1.3相关领域的研究进展和成果

信息孤岛问题的解决方案在数据库层主要集中在分布式和联邦式之争。

本文将在第三章详细客观的介绍这两种数据库系统架构方案。

数据移植领域，主要由数据库开发商提供开发了一些移植工具，如：

微软随SQLServer附送的DataTransformationServices（DTS），Oracle的移植工作台等，这些工具的设计目的多为将数据库从其他数据库供应商的产品上复制到自己的产品上，以及作为数据备份工具使用，其功能要点集中在复制上，对异构数据库之间的转移支持并不良好，甚至不支持。

1.4主要研究内容

1数据库系统架构

2可配置数据移植工具TransBuilder的设计和实现

1.5本文的组织

第一部分研究简介（第1章）

第二部分信息孤岛的含义和目前数据库层解决方案概述（第2章）

第三部分描述具体典型案例，清晰信息孤岛问题（第3章）

第四部分数据库架构方案设计（第4章）

第五部分数据库移植方案和工具设计（第5章）

第2章

信息孤岛的产生和目前一般的解决方案

2.1信息孤岛的产生、现状和危害

2.1.1信息孤岛的产生

在构建某个应用系统时，目前大多采用“独立解决方案”，开发者和需求部门应用逻辑相结合，在特定的操作系统平台上、特定的集成开发环境下、基于特定的数据表达格式，进行特定数据库设计和应用软件系统的开发，很少考虑应用的可集成性、可重用性、可定制性、可移植性，造成了众多软硬件平台、各类应用系统并存的局面。

图三系统接口数量N（N－1）

当众多系统间需要信息共享时，往往以某一个或某几个关键应用系统为主，基于系统提供接口进行二次开发，在需要共享信息的系统间由特定的程序员提供复杂的访问接口，与其它系统进行整合，是一种复杂系统对接的模式。

假定企业中有N个系统需要共享数据资源，那么需要特定的程序员开发复杂的单向接口就是N（N－1）个（图三）。

于是，企业不得不为每套应用配置特有的专业技术维护人员（至少是数据库管理员），并保持与不同技术供应商的密切联系，接口的复杂性和大量化以及不同技术供应商之间的工作协调往往使企事业单位望而生畏，结果往往形成了众多的信息孤岛和小规模的紧密集成。

2.1.2信息孤岛的现状

随着现代信息技术和Internet技术的飞速发展，企事业单位的管理方式也一直发生着变革，基于网络的管理模式已成为优化企事业单位管理的有效途径和发展趋势。

网络化管理通常涉及多个部门甚至多个单位，具有异地工作环境、异构工作平台、并行协同工作等特点，其实施的基础是企事业单位应用系统的有机集成与管理信息的有效共享。

目前，我国很多企事业单位通过市场采购或自主开发，拥有了多种OA和MIS系统软件，这些都为管理信息化积累了一定的经验。

可是由于没有统一的架构和管理，以及传统应用开发模式的局限和系统集成方法的落后，形成了众多的数据源孤岛或紧耦合应用，严重阻碍了企事业单位信息的流通和信息化的进一步发展。

2.1.3信息孤岛的苦果

信息孤岛的产生让不少信息化走在前沿的企事业单位尝尽了苦果，尤其突出表现在以下五个方面：

1数据的一致性无法保证。

由于信息定义与采集过程彼此独立，单位中同一数据可能在不同的应用中不一致。

2信息及时共享、反馈难。

信息不能及时充分共享的矛盾突出，单位中“信息孤岛”林立。

3企业存冗余垃圾信息。

由于各个系统独立，存在大量不必要数据，使访问数据库的速度降低。

4信息需要重复多次的输入。

对信息的多次采集不仅仅是额外的劳动，数据失真也是重复输入的恶果之一。

5信息化进程遇到障碍。

无法对信息孤岛进行联机分析处理（OLAP）、数据仓库（DW）建设，妨碍了对企业附加值的数据挖掘（DM）和决策支持系统（DSS）的构建。

2.2信息孤岛目前一般的数据库层解决方案

多应用系统集成是目前最流行也是使用和探讨最广泛的信息孤岛解决方案。

现行的多数据库应用系统集成方案，主要分为前台应用层解决方案和后台数据库层解决方案，其中，数据库层是人们最关心的，治病治根，信息孤岛的根就在数据库上，因此，如何解决好数据库层是整个集成方案的关键。

目前，对数据库层的集成一般有两种方案：

分布式数据库系统、联邦式数据库系统。

2.2.1分布式数据库架构

图四DDBS环境[2]

多应用系统必然对数据有分布式存储需要，对分布式数据的管理和访问就成为必须解决的问题。

由于一个事务所涉及的数据可能分布在多个结点上（如图四），这就要求数据库系统具备一个优化的分布查询策略。

对于这种分布执行的事务，系统要保证事务执行的原子性和可串行化，以及解决分布环境下的安全问题、恢复问题、分布透明性、节点自治、全局命令空间、分布式查询、分布式更新、数据分布与复制、两阶段提交（2PC）、网络数据字典（NDD）等关键问题。

分布式数据库系统正是为解决上述问题而设计的。

一个分布式数据库系统由一个逻辑数据库组成，这个逻辑数据库的数据存储在一个或多个结点的物理数据库上，通过两阶段提交（2PC）协议来提供透明的数据访问和事务管理。

分布式数据库系统在系统结构上的真正含义是指物理上分布、逻辑上集中的分布式数据库结构。

数据在物理上分布后，由系统统一管理，使用户不感到数据的分布。

用户看到的似乎不是一个分布式数据库，而是一个数据模式为全局数据模式的集中式数据库。

分布式数据库有性能高、可扩充性好、可用性好以及具有自治性等优点。

分布式数据库系统仍存在不足：

由于数据库系统的应用通常是逐步发展的，起先是建立各种孤立的数据库，而管理这些数据库的计算机系统和DBMS包括数据模型很可能是不同的，也就是异构的（Heterogeneous）。

当应用需要转向分布式数据处理时，抛弃原有的系统另砌炉灶显然是不合理的，这就需要解决异构数据库的集成问题。

这在技术上有一定的复杂性，而且目前还很难用一个通用的DBMS来解决这样的问题。

我们希望一种新的数据库技术——联邦数据库系统（FederatedDatabaseSystem）能解决这一问题。

此外分布式数据库系统虽然有利于改善性能，但如果数据库设计不好，数据分布不合理，使远距离访问过多，特别是当分布连接操作过多时，都会降低系统的性能。

2.2.2联邦式数据库架构

分布式数据库系统不能很好解决的异构数据库的集成问题，可以通过建立联邦数据库系统来解决。

通常称相互独立运行的数据库系统为单元数据库系统（ComponentDBS）。

它是原本存在的、在局部地区应用的数据库系统，它们是联邦数据库系统的一部分。

所谓联邦式数据库系统是一种物理上分布、逻辑上分布的分布式数据库结构。

这种分布式数据库结构的特点是结点自治（SiteAutonomy）和没有全局数据模式（GlobalDataSchema）。

每个结点所看到的数据模式仅仅限于该结点所用到的数据。

它一般由两部分组成：

一是本结点的数据模式，二是供本结点共享的其他结点上的有关的数据模式。

结点间的数据共享由双边协商确定。

如果一个新的结点要加入系统，它开始时可先用本结点的数据，然后与有关结点协商，共享其他结点的有关数据；本结点的数据同样可被其他结点共享。

这种扩展完全是渐进的，不会影响原有系统的运行。

由于每一个结点所看到的数据模式是不一样的，就好像系统中有多个逻辑数据库，因而在逻辑上这种数据库结构也是分布式的（图五）。

图五联邦式数据库系统扩展方式

由于无全局数据模式，一个结点的数据模式的修改甚至一个结点的加入或撤离，仅仅影响有关的结点。

一个结点在给数据对象命名时，只要求在本结点的数据模式内唯一，无需考虑与其它无关数据对象的重名问题。

每个结点好像拥有一个满足自己需要的集中式数据库一样，而不受制于全局数据模式，甚至不必有“全局观念”，结点具有很高的自治性。

联邦式数据库结构有利于数据库的集成、扩展和重新配置，但因为现有网络系统并不具备够大的延展性，可以在大量资料上做平行运算，所以其性能不如集中式数据库高，而且实现代价较高，技术上也很复杂，如不同数据系统的数据模式转换，全局事务的管理及其串行性等。

分布式

联邦式

数据库设计复杂性

复杂，需要详细规划

较复杂，对规划要求不高

共享复杂性

较简单

较复杂，每个新系统加入都要调整共享

反映了组织结构

是

是

本地自主权

高

极高，完全自主权

可用性

较高

稍低

可靠性

高

中上

性能

中上

较低

成本

中

中

可扩张性

强

很强

复杂性

中上

高

完整性

高

单个高，全局低

实施经验

较多

较少

表一分布式和联邦式数据库架构比较表

第3章

信息孤岛问题实际案例

高等院校具有实施信息化建设的优势：

1对共享数据/计算资源/存储资源/应用资源的内在需求

2复杂的计算环境和提供更大计算能力的需求

3充足且对新技术十分敏感的技术力量

所以，高校也就首当其冲的成为信息孤岛问题的受困者，当然，这为我们研究和解决信息孤岛问题提供了一个良好的平台。

下面就A高校的信息孤岛问题为例形象的说明该问题的状况和该校的从行政上采取的可供大家参考的措施。

3.1A高校的信息孤岛问题

我国大多数高校已广泛建设和拥有了校园网络，并且成立了诸如网络中心类机构来统一管理硬件设施，A高校作为站在时代先锋的国家重点高等院校，其管理方式也一直发生着变革，网络化、电子化正一步步渗透到学校工作、生活的方方面面，校内一些需求比较迫切的部门（如：

财务处、人事处等）或研发能力较强的单位（计算机系、软件学院等），已经通过市场采购或自主研发，拥有了多套OA和MIS系统软件，但是由于整个校园信息化建设缺乏统一规划和标准，各单位认识不一致，发展不平衡，各单位的应用系统是在不同时间由不同人群研发完成，应用系统间的数据共享还有赖于落后的磁盘甚至是纸介质等低效率的方式，缺乏协调，形成了网络环境下大量的“信息孤岛”，为学校的管理带来了实际的不便。

下面用一些实际问题简述一下该校的信息孤岛问题状况：

3.1.1数据一致性问题：

表二～四为该校财务处、人事处、后勤集团数据库人员信息统计对照表，表五显示了财务处和人事处因为缺乏统一的规范，对校内同一单位的不同命名，这些表充分反映了该校各部门应用系统存在着数据一致性问题；

简单统计

在职

离退

合计

财务处

3464

1759

5223

人事处

3702

1978

5680

后勤集团

252

252

表二财务处、人事处、后勤集团人员总数统计表[3]

在职

财务处

人事处

后勤集团

财务处

3464

3422（-280）

121（-131）

人事处

3702

221（-31）

后勤集团

252

表三财务处、人事处、后勤集团在职人员数量比较表“（）”内为差额[3]

离退休

财务处

人事处

财务处

1759

1758（-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数据无实时共享

经过实地调查研究发现，该高校校内各部门系统之间共享基本停留在人工拿介质拷贝层次，基本没有数据共享实时性可言。

3.1.3冗余代码表侵吞系统资源

考察发现各部门系统都在不同程度上有代码表冗余现象，一些已废弃不用的代码表长期占据着大量的存储空间。

3.1.4信息的重复输入

该校有一名姓林的同学，因为入学时教学秘书的疏忽，将名字输入错误，导致该生在校期间在招生办、教务处、学生处等部门重复递交申请修改姓名，这都是在数据不能共享情况下出现的异常现象。

3.1.5统计报表的参考价值令人置疑

简单举例来说，人事处、财务处统计来的职工人数，领导该相信哪一个？

3.2信息化项目组的成立和所面对的问题

A高校领导会同管理学、计算机等方面专家经过反复的研讨协商，酝酿多年后，成立了由主管校长领衔，计算机、管理等方面专家共同组成顾问团的校园信息化领导机构，并与2004年5月成立了校园信息化项目组，专职负责根据信息化建设的特点，按照科学、规范、标准化的原则开展，从全校全局出发，建立信息化建设的总体规划。

信息化项目组作为学校的信息化核心机构，参与实施和协调所有校园信息化相关项目的建设。

信息化项目组目前直面的主要问题是以下几点[4]：

1整个校园信息化建设缺乏统一规划和标准，对于不同的应用系统，用户需要在不同位置逐个进入访问，缺乏统一的访问资源和应用接口，不方便用户使用；

2各单位认识不一致，发展不平衡，各单位的应用系统是在不同时间由不同人群研发完成，应用系统间的数据共享还有赖于落后的磁盘甚至是纸介质等低效率的方式，缺乏协调，形成了网络环境下大量的“信息孤岛”；

3重硬件轻软件，仅购置大量的硬件设备，缺乏功能好质量高的应用系统，没有充分发挥信息系统在管理教学科研方面的作用；

4校园网上应用系统和信息资源越来越多，缺乏有效的组织和管理，经常出现的信息安全问题、人员管理问题影响着信息系统真正为教学科研和管理工作服务。

为信息孤岛问题寻求解决方案，实现校园内所有部门的信息共享成为信息化项目组面对的首要问题。

下面两章都将在此案例的基础上进行探讨。

第4章

分布式规划联邦式过渡的数据库优化架构方案设计

4.1设计原理

A高校的计算机系统是逐步发展的，先在各个地理上分散的部门建立一些孤立的数据库系统。

现在对这些己运行的而且基本都是异构的数据库之间提出数据流通的需求。

立刻将这些己存在的系统完全集成为一个分布式数据库是困难的甚至是不可能的。

联邦式数据库系统是“信息孤岛”问题很好的概念解决，但其实现代价高，技术上也很复杂，在性能上和分布式数据库有较大差距。

在综合考虑以上因素，我们提出分布式规划、联邦式过渡的数据库系统优化解决方案，所谓分布式规划是从长远的角度考虑，高校可以通过成立信息中心或数据库中心参与管理，对新建设的系统进行统一规划，都要求集成到采用分布式架构的中央数据库中，而对老系统暂时采用联邦式集成作为一种低成本的过渡性手段，随着时间的推移旧系统逐步淘汰后，最终形成纯分布式集中数据库架构。

图六分布式规划、联邦式过渡架构示意图

4.2中央数据库设计

中央数据库为分布式架构，基本原则：

对用户来说，分布式系统看起来应当就像非分布式系统一样。

分布式系统的Data12条规则[5]：

1本地自主性

2对中心结点没有依赖性

3连续操作

4位置独立

5分段独立性

6复制独立性

7分布式查询处理

8分布式事务处理

9硬件独立性

10操作系统独立性

11网络独立性

12数据库独立性

除了最后四条是较理想化的，其他规则都是我们必须完成的设计目标。

4.2.1物理设计

图七校园信息化数据库服务器架设图[6]

根据分布式数据库系统的需要，我们对校园内数据库服务器的架设做了如图七的配置，其中中央数据库采用多主体同步复制，各院系服务器则与中心数据库进行异步实体化视图复制，物理设计相关内容请参考相关文献，因其不是本文主旨，在此不多予以赘述。

4.2.2逻辑设计

如图八所示，新建分布式中央数据库由三部分组成：

××部门（院系）表、代码库及映射代码库。

该设计具有如下几个特点：

1新建部门数据库使用实体表。

由于新建分布式数据库系统最终将替代现存数据库，所以对中央数据库设计采用实体表，而非纯联邦式的虚拟表。

2数据标准化。

设计严格的遵守国家教育部编制的教育管理信息化标准。

标准代码库包括：

共享代码库，即：

整个信息化管理系统都可能用到的标准化代码；私有代码库，即：

只有某些部门需要使用的标准化代码；其他代码库，即：

已经存在，但尚未使用的标准化代码。

经过数据标准化之后，数据库中数据均以标准化的代码格式储存。

3高安全性。

从数据库安全角度考虑，实行数据屏蔽