信息孤岛问题数据库层优化解决方案设计软件工程课程设计.docx

1、信息孤岛问题数据库层优化解决方案设计软件工程课程设计信息孤岛问题数据库层优化解决方案设计软件工程课程设计第1章 引言1.1 研究背景“信息化校园计划”（The Campus Computing Project）最早是1990年由美国克莱蒙特大学教授凯尼斯格林（Kenneth Green）发起并主持的一项大型科研项目。高校信息化建设的目标是建设一个数字校园，以网络为基础，利用先进的信息化手段和工具，实现从环境（包括设备、教室等）、资源（如图书、讲义、课件等）到活动（包括教、学、管理、服务、办公等）的全部数字化，在传统校园的基础上构建一个数字空间，以拓展现实校园的时间和空间维度，提升传统校园的效率

2、，扩展传统校园的功能，最终实现教育过程的全面信息化。从而达到提高教育管理水平和效率的目的。原有的在缺乏统一规划的情况下建设的各种应用系统，由于信息无法共享，形成了一个个“信息孤岛”（图一），大大妨碍了信息化建设的进程，解决数据孤岛问题是信息化建设起步面对的首要问题。图一 连在一起的信息孤岛1.2 本研究的理论和实际意义理论意义：信息孤岛的根源在数据源共享问题，目前解决该问题的方法主要有两种：分布式或联邦式数据库系统架构，本研究旨在对两种系统架构模式进行探讨，指出其优点，揭露其缺陷，通过比较性研究和实际案例实践，在理论上提出一种新的分布式规划、联邦式过渡的数据库系统架构优化方案。实际意义：本文作

3、者隶属于厦门大学校园信息化建设项目组，该项目组成立于2004年5月，本人所在科研管理系统开发团队由七人组成，其组织结构如图二所示。本人在其中主要致力于信息孤岛问题的解决方案的设计和实现，完成数据库转换移植工具的设计。通过实践中考察到信息孤岛问题在企事业单位信息化中存在的普遍性，作者对相关方面的问题进行了广泛的思考和实践，从理论到实现，为信息孤岛问题的解决设计了整套切实可行的方案。解决方案实施关键工具TransBuilder的设计和实现填补了当前可配置数据移植工具的空白。图二 科研管理系统开发团队协作图1.3 相关领域的研究进展和成果信息孤岛问题的解决方案在数据库层主要集中在分布式和联邦式之争。

4、本文将在第三章详细客观的介绍这两种数据库系统架构方案。数据移植领域，主要由数据库开发商提供开发了一些移植工具，如：微软随SQL Server附送的Data Transformation Services（DTS），Oracle的移植工作台等，这些工具的设计目的多为将数据库从其他数据库供应商的产品上复制到自己的产品上，以及作为数据备份工具使用，其功能要点集中在复制上，对异构数据库之间的转移支持并不良好，甚至不支持。1.4 主要研究内容1 数据库系统架构2 可配置数据移植工具TransBuilder的设计和实现1.5 本文的组织第一部分 研究简介（第1章）第二部分 信息孤岛的含义和目前数据库层解决

5、方案概述（第2章）第三部分 描述具体典型案例，清晰信息孤岛问题（第3章）第四部分 数据库架构方案设计（第4章）第五部分 数据库移植方案和工具设计（第5章）第2章 信息孤岛的产生和目前一般的解决方案2.1 信息孤岛的产生、现状和危害2.1.1 信息孤岛的产生在构建某个应用系统时，目前大多采用“独立解决方案”，开发者和需求部门应用逻辑相结合，在特定的操作系统平台上、特定的集成开发环境下、基于特定的数据表达格式，进行特定数据库设计和应用软件系统的开发，很少考虑应用的可集成性、可重用性、可定制性、可移植性，造成了众多软硬件平台、各类应用系统并存的局面。图三 系统接口数量N（N1） 当众多系统间需要信息

6、共享时，往往以某一个或某几个关键应用系统为主，基于系统提供接口进行二次开发，在需要共享信息的系统间由特定的程序员提供复杂的访问接口，与其它系统进行整合，是一种复杂系统对接的模式。假定企业中有N个系统需要共享数据资源，那么需要特定的程序员开发复杂的单向接口就是N（N1）个（图三）。于是，企业不得不为每套应用配置特有的专业技术维护人员（至少是数据库管理员），并保持与不同技术供应商的密切联系，接口的复杂性和大量化以及不同技术供应商之间的工作协调往往使企事业单位望而生畏，结果往往形成了众多的信息孤岛和小规模的紧密集成。2.1.2 信息孤岛的现状随着现代信息技术和Internet技术的飞速发展，企事业单

7、位的管理方式也一直发生着变革，基于网络的管理模式已成为优化企事业单位管理的有效途径和发展趋势。网络化管理通常涉及多个部门甚至多个单位，具有异地工作环境、异构工作平台、并行协同工作等特点，其实施的基础是企事业单位应用系统的有机集成与管理信息的有效共享。目前，我国很多企事业单位通过市场采购或自主开发，拥有了多种OA和MIS系统软件，这些都为管理信息化积累了一定的经验。可是由于没有统一的架构和管理，以及传统应用开发模式的局限和系统集成方法的落后，形成了众多的数据源孤岛或紧耦合应用，严重阻碍了企事业单位信息的流通和信息化的进一步发展。2.1.3 信息孤岛的苦果信息孤岛的产生让不少信息化走在前沿的企事业

8、单位尝尽了苦果，尤其突出表现在以下五个方面：1 数据的一致性无法保证。由于信息定义与采集过程彼此独立，单位中同一数据可能在不同的应用中不一致。 2 信息及时共享、反馈难。信息不能及时充分共享的矛盾突出，单位中“信息孤岛”林立。 3 企业存冗余垃圾信息。 由于各个系统独立，存在大量不必要数据，使访问数据库的速度降低。 4 信息需要重复多次的输入。对信息的多次采集不仅仅是额外的劳动，数据失真也是重复输入的恶果之一。5 信息化进程遇到障碍。无法对信息孤岛进行联机分析处理（OLAP）、数据仓库（DW）建设，妨碍了对企业附加值的数据挖掘（DM）和决策支持系统（DSS）的构建。2.2 信息孤岛目前一般的数

9、据库层解决方案多应用系统集成是目前最流行也是使用和探讨最广泛的信息孤岛解决方案。现行的多数据库应用系统集成方案，主要分为前台应用层解决方案和后台数据库层解决方案，其中，数据库层是人们最关心的，治病治根，信息孤岛的根就在数据库上，因此，如何解决好数据库层是整个集成方案的关键。目前，对数据库层的集成一般有两种方案：分布式数据库系统、联邦式数据库系统。2.2.1 分布式数据库架构图四 DDBS 环境2多应用系统必然对数据有分布式存储需要，对分布式数据的管理和访问就成为必须解决的问题。由于一个事务所涉及的数据可能分布在多个结点上（如图四），这就要求数据库系统具备一个优化的分布查询策略。对于这种分布执行

10、的事务，系统要保证事务执行的原子性和可串行化，以及解决分布环境下的安全问题、恢复问题、分布透明性、节点自治、全局命令空间、分布式查询、分布式更新、数据分布与复制、两阶段提交(2PC)、网络数据字典(NDD)等关键问题。分布式数据库系统正是为解决上述问题而设计的。一个分布式数据库系统由一个逻辑数据库组成，这个逻辑数据库的数据存储在一个或多个结点的物理数据库上，通过两阶段提交(2PC)协议来提供透明的数据访问和事务管理。分布式数据库系统在系统结构上的真正含义是指物理上分布、逻辑上集中的分布式数据库结构。数据在物理上分布后，由系统统一管理，使用户不感到数据的分布。用户看到的似乎不是一个分布式数据库，

11、而是一个数据模式为全局数据模式的集中式数据库。分布式数据库有性能高、可扩充性好、可用性好以及具有自治性等优点。分布式数据库系统仍存在不足：由于数据库系统的应用通常是逐步发展的，起先是建立各种孤立的数据库，而管理这些数据库的计算机系统和DBMS包括数据模型很可能是不同的，也就是异构的(Heterogeneous)。当应用需要转向分布式数据处理时，抛弃原有的系统另砌炉灶显然是不合理的，这就需要解决异构数据库的集成问题。这在技术上有一定的复杂性，而且目前还很难用一个通用的DBMS来解决这样的问题。我们希望一种新的数据库技术联邦数据库系统(Federated Database System)能解决这一

12、问题。此外分布式数据库系统虽然有利于改善性能，但如果数据库设计不好，数据分布不合理，使远距离访问过多，特别是当分布连接操作过多时，都会降低系统的性能。2.2.2 联邦式数据库架构分布式数据库系统不能很好解决的异构数据库的集成问题，可以通过建立联邦数据库系统来解决。通常称相互独立运行的数据库系统为单元数据库系统(Component DBS)。它是原本存在的、在局部地区应用的数据库系统，它们是联邦数据库系统的一部分。所谓联邦式数据库系统是一种物理上分布、逻辑上分布的分布式数据库结构。这种分布式数据库结构的特点是结点自治(Site Autonomy)和没有全局数据模式(Global Data Sch

13、ema)。每个结点所看到的数据模式仅仅限于该结点所用到的数据。它一般由两部分组成：一是本结点的数据模式，二是供本结点共享的其他结点上的有关的数据模式。结点间的数据共享由双边协商确定。如果一个新的结点要加入系统，它开始时可先用本结点的数据，然后与有关结点协商，共享其他结点的有关数据；本结点的数据同样可被其他结点共享。这种扩展完全是渐进的，不会影响原有系统的运行。由于每一个结点所看到的数据模式是不一样的，就好像系统中有多个逻辑数据库，因而在逻辑上这种数据库结构也是分布式的（图五）。图五 联邦式数据库系统扩展方式由于无全局数据模式，一个结点的数据模式的修改甚至一个结点的加入或撤离，仅仅影响有关的结点

14、。一个结点在给数据对象命名时，只要求在本结点的数据模式内唯一，无需考虑与其它无关数据对象的重名问题。每个结点好像拥有一个满足自己需要的集中式数据库一样，而不受制于全局数据模式，甚至不必有“全局观念”，结点具有很高的自治性。联邦式数据库结构有利于数据库的集成、扩展和重新配置，但因为现有网络系统并不具备够大的延展性，可以在大量资料上做平行运算，所以其性能不如集中式数据库高，而且实现代价较高，技术上也很复杂，如不同数据系统的数据模式转换，全局事务的管理及其串行性等。分布式联邦式数据库设计复杂性复杂，需要详细规划较复杂，对规划要求不高共享复杂性较简单较复杂，每个新系统加入都要调整共享反映了组织结构是是

15、本地自主权高极高，完全自主权可用性较高稍低可靠性高中上性能中上较低成本中中可扩张性强很强复杂性中上高完整性高单个高，全局低实施经验较多较少表一 分布式和联邦式数据库架构比较表第3章 信息孤岛问题实际案例高等院校具有实施信息化建设的优势：1 对共享数据/计算资源/存储资源/应用资源的内在需求2 复杂的计算环境和提供更大计算能力的需求3 充足且对新技术十分敏感的技术力量所以，高校也就首当其冲的成为信息孤岛问题的受困者，当然，这为我们研究和解决信息孤岛问题提供了一个良好的平台。下面就A高校的信息孤岛问题为例形象的说明该问题的状况和该校的从行政上采取的可供大家参考的措施。3.1 A高校的信息孤岛问题我

16、国大多数高校已广泛建设和拥有了校园网络，并且成立了诸如网络中心类机构来统一管理硬件设施，A高校作为站在时代先锋的国家重点高等院校，其管理方式也一直发生着变革，网络化、电子化正一步步渗透到学校工作、生活的方方面面，校内一些需求比较迫切的部门（如：财务处、人事处等）或研发能力较强的单位（计算机系、软件学院等），已经通过市场采购或自主研发，拥有了多套OA和MIS系统软件，但是由于整个校园信息化建设缺乏统一规划和标准，各单位认识不一致，发展不平衡，各单位的应用系统是在不同时间由不同人群研发完成，应用系统间的数据共享还有赖于落后的磁盘甚至是纸介质等低效率的方式，缺乏协调，形成了网络环境下大量的“信息孤岛

17、”，为学校的管理带来了实际的不便。下面用一些实际问题简述一下该校的信息孤岛问题状况：3.1.1 数据一致性问题：表二四 为该校财务处、人事处、后勤集团数据库人员信息统计对照表，表五 显示了财务处和人事处因为缺乏统一的规范，对校内同一单位的不同命名，这些表充分反映了该校各部门应用系统存在着数据一致性问题；简单统计在职离退合计财务处346417595223人事处370219785680后勤集团252252表二 财务处、人事处、后勤集团人员总数统计表3在职财务处人事处后勤集团财务处34643422(-280)121(-131)人事处3702221(-31)后勤集团252表三 财务处、人事处、后勤集团

18、在职人员数量比较表 “（）”内为差额3离退休财务处人事处财务处17591758（-220）人事处1978表四 财务处、人事处离退休人员数量比较表 “（）”内为差额3编号人事处在职人员单位财务处在职人员单位1发展规划办公室校办公室2人事处人才中心4学校办公室校办公室5招生办公室招生办6科学技术处科研处7社会科学研究处科研处8学生工作部(处)学生处9国际合作与交流处外事办10离退休工作部(处)离退休处11人文学院人类所12经济学院经济研究13艺术教育学院艺术学院14生命科学学院生命学院15数学科学学院数学系16医学院抗癌中心17化学化工学院化工学院18海洋与环境学院海洋环境19信息科学与技术学院信

19、息学院20物理与机电学院物理学院21建筑与土木工程学院建筑系22马列主义理论部马列室23体育教学部体育室24南洋研究院南洋所26教育研究院高教所27现代教育技术中心现代中心28自然科学版学报自然学报29哲学社会科学版学报哲社学报30计算机网络中心网络中心32资产经营有限公司经营公司33资产与后勤事务管理处资产后勤34实验室与设备管理办公室实验办35公共事务学院公共学院表五 财务处、人事处同单位异名表33.1.2 数据无实时共享经过实地调查研究发现，该高校校内各部门系统之间共享基本停留在人工拿介质拷贝层次，基本没有数据共享实时性可言。3.1.3 冗余代码表侵吞系统资源考察发现各部门系统都在不同程

20、度上有代码表冗余现象，一些已废弃不用的代码表长期占据着大量的存储空间。3.1.4 信息的重复输入该校有一名姓林的同学，因为入学时教学秘书的疏忽，将名字输入错误，导致该生在校期间在招生办、教务处、学生处等部门重复递交申请修改姓名，这都是在数据不能共享情况下出现的异常现象。3.1.5 统计报表的参考价值令人置疑简单举例来说，人事处、财务处统计来的职工人数，领导该相信哪一个？3.2 信息化项目组的成立和所面对的问题A高校领导会同管理学、计算机等方面专家经过反复的研讨协商，酝酿多年后，成立了由主管校长领衔，计算机、管理等方面专家共同组成顾问团的校园信息化领导机构，并与2004年5月成立了校园信息化项目

21、组，专职负责根据信息化建设的特点，按照科学、规范、标准化的原则开展，从全校全局出发，建立信息化建设的总体规划。信息化项目组作为学校的信息化核心机构，参与实施和协调所有校园信息化相关项目的建设。信息化项目组目前直面的主要问题是以下几点4：1 整个校园信息化建设缺乏统一规划和标准，对于不同的应用系统，用户需要在不同位置逐个进入访问，缺乏统一的访问资源和应用接口，不方便用户使用；2 各单位认识不一致，发展不平衡，各单位的应用系统是在不同时间由不同人群研发完成，应用系统间的数据共享还有赖于落后的磁盘甚至是纸介质等低效率的方式，缺乏协调，形成了网络环境下大量的“信息孤岛”；3 重硬件轻软件，仅购置大量的

22、硬件设备，缺乏功能好质量高的应用系统，没有充分发挥信息系统在管理教学科研方面的作用；4 校园网上应用系统和信息资源越来越多，缺乏有效的组织和管理，经常出现的信息安全问题、人员管理问题影响着信息系统真正为教学科研和管理工作服务。为信息孤岛问题寻求解决方案，实现校园内所有部门的信息共享成为信息化项目组面对的首要问题。下面两章都将在此案例的基础上进行探讨。第4章 分布式规划联邦式过渡的数据库优化架构方案设计4.1 设计原理A高校的计算机系统是逐步发展的，先在各个地理上分散的部门建立一些孤立的数据库系统。现在对这些己运行的而且基本都是异构的数据库之间提出数据流通的需求。立刻将这些己存在的系统完全集成为

23、一个分布式数据库是困难的甚至是不可能的。联邦式数据库系统是“信息孤岛”问题很好的概念解决，但其实现代价高，技术上也很复杂，在性能上和分布式数据库有较大差距。在综合考虑以上因素，我们提出分布式规划、联邦式过渡的数据库系统优化解决方案，所谓分布式规划是从长远的角度考虑，高校可以通过成立信息中心或数据库中心参与管理，对新建设的系统进行统一规划，都要求集成到采用分布式架构的中央数据库中，而对老系统暂时采用联邦式集成作为一种低成本的过渡性手段，随着时间的推移旧系统逐步淘汰后，最终形成纯分布式集中数据库架构。图六 分布式规划、联邦式过渡架构示意图4.2 中央数据库设计中央数据库为分布式架构，基本原则：对用

24、户来说，分布式系统看起来应当就像非分布式系统一样。分布式系统的Data 12条规则5：1 本地自主性2 对中心结点没有依赖性3 连续操作4 位置独立5 分段独立性6 复制独立性7 分布式查询处理8 分布式事务处理9 硬件独立性10 操作系统独立性11 网络独立性12 数据库独立性除了最后四条是较理想化的，其他规则都是我们必须完成的设计目标。4.2.1 物理设计图七 校园信息化数据库服务器架设图6根据分布式数据库系统的需要，我们对校园内数据库服务器的架设做了如图七的配置，其中中央数据库采用多主体同步复制，各院系服务器则与中心数据库进行异步实体化视图复制，物理设计相关内容请参考相关文献，因其不是本

25、文主旨，在此不多予以赘述。4.2.2 逻辑设计如图八所示，新建分布式中央数据库由三部分组成：部门（院系）表、代码库及映射代码库。该设计具有如下几个特点：1 新建部门数据库使用实体表。由于新建分布式数据库系统最终将替代现存数据库，所以对中央数据库设计采用实体表，而非纯联邦式的虚拟表。2 数据标准化。设计严格的遵守国家教育部编制的教育管理信息化标准。标准代码库包括：共享代码库，即：整个信息化管理系统都可能用到的标准化代码；私有代码库，即：只有某些部门需要使用的标准化代码；其他代码库，即：已经存在，但尚未使用的标准化代码。经过数据标准化之后，数据库中数据均以标准化的代码格式储存。3 高安全性。从数据

26、库安全角度考虑，实行数据屏蔽，将数据库分成三类库保存，部门实体表中表名、字段名、字段内容基本都用代码表示。通过程序控制实体表和代码表的对应关系，发生数据库泄漏时，拿到任何一个代码库固然无用，拿到实体库也会因为无法识别其中代码涵义而保证数据的秘密性，大大降低了因数据库泄漏而引发的安全性问题。代码库又分为三种：共享代码库，私有代码库和其他代码库，除了共享代码库，各部门只能访问自己相关的私有和其他代码库，进一步提高了系统的安全性。4 高契合度。为了方便使用，映射库包含了表名映射库、字段名映射库和字段内容映射库，用于处理各种对象名称和代码的映射过程。映射代码库的建设为现存数据库和新数据库的衔接提供了充

27、分的支持，使得新旧数据库间联邦式对接成为可能。5 开发复杂性较高。高安全性通常意味着高复杂性，本设计也未能例外，在程序开发过程中要求对实体表和代码库之间进行详细的定义，这对应用程序开发人员和数据库设计人员都是一个挑战，唯有二者齐心协力方能拨云见日。6 映射代码库建设任务艰巨。映射代码库是新旧数据库衔接的关键，两者需要映射的内容成山成海，为使二者畅顺对接，数据库整理人员工作量难以估量。图八 分布式规划、联邦式过渡系统架构逻辑结构4.3 联邦式过渡典型案例：人事处系统整合4.3.1 人事处现有数据库系统架构分析图九 人事处现存数据库系统结构拓扑图A校人事处现存应用系统为客户端服务器（CS）架构，数

28、据库使用Microsoft SQL Server 2000，架设在人事处机房的一台HP NETSERVER2000服务器上，经过多次调研，基本确认了人事处数据库系统逻辑架构，如图九所示，人事处实体表内容由多重数据字典表定义。首先，实体表名由两部分组成成分类别、集合，分别由SR_Unittype和SR_SourceCollect定义，其中SR_sourceCollect中的SetId又关联到SR_SourceItem，后者定义了实体表中字段名称、长度以及所涉及字段内容代码集CodeId，在SR_CodeCollect中可以找到CodeId的含义，最终sr_codeitem和sr_depertme

29、nt的50000多条记录明确了字段内容的含义，在这两张表中code和description 对上了号，CodeId在这里将code分类，同时避免了代码重名。不用细述就可以看出，人事处现行数据库结构与新建中央数据库是格格不入的，在不能马上重建新系统的情况下，如何解决仍在使用中的人事处数据库与中央及其他部门之间的数据共享？联邦式数据库系统架构为我们提供了一条道路。4.3.2 联邦式数据库整合面对问题联邦式数据库整合过程一般分三步走：1 根据中央分布式数据库设计规范设计新部门数据库；2 设计共享同步策略；3 时机成熟时，建设新系统，对旧数据库进行彻底数据库移植，淘汰旧数据库。这个过程在上一节中已有介

30、绍，现在仅就新数据库设计完毕后，新旧数据库同步、移植相关问题进行探讨。4.3.2.1 数据共享同步联邦式数据库架构中，异构数据库之间共享和同步的并不是分离的概念，共享是由同步实现的，如何同步更新本地（旧）数据库和中央（新）扩展的数据库是必须要解决的问题。图十 带准备态的状态转移图7联邦式数据同步需要在两个层次上采取措施：1 应用层：两阶段提交。对应用程序进行双向提交修改，在此过程中需要考虑事务阻塞等的情况下的处理方案，这方面比较成熟的方案是如图十所示的两阶段提交方案，详细资料请参考魏昕路在2005年做的研究报告。2 数据库层：数据转换复制。两阶段提交解决了数据同步的实时性问题，但因其涉及到应用程序修改，实现困难较大，根据现存信息孤岛除了部分实时性要求较高的如财务相关部门，其他有很多同步共享对实时性要求并不高，半天同步一次或一天甚至一星期同步一次也可，向这类同步需求，对其也进行两阶段提交的应用层修改，复杂性和成本都过高，必须提出一种较经济的解决方案，数据库层数据复制勿庸置疑的成为了一种首选的方案。它有两个明显的优点：复杂性稍低、通用性高。不仅可以直接用来独立完成同步，而且可