毕业论文-地震前兆系统元数据管理的设计与实现.doc

北京航空航天大学毕业设计(论文) 第 VI 页北京航空航天大学 本科生毕业设计（论文）任务书、毕业设计（论文）题目： 地震前兆系统元数据管理的设计与实现 、毕业设计（论文）使用的原始资料（数据）及设计技术要求： 实现地震前兆元数据管理系统，该系统要能够有效地组织与管理前兆系统中的元数据，具有元数据的有效性约束、唯一性约束与一致性约束以及完善的冲突处理机制，并且具备容灾恢复能力。 、毕业设计（论文）工作内容： 了解地震前兆元数据管理的现状和需求后，提取地震前兆系统中元数据并分析其特点，在此基础上设计地震前兆系统元数据管理的体系结构，并对各功能模块进行详细设计与实现，最后对系统进行测试分析。 、主要参考资料：1、付伟，数据网格中元信息服务系统的设计与实现，国防科技大学，2003.11 .2、Liyan Liu,Hua Li ,Zongkai Lin. Metadata Model in Grid Database and its Application 3、Oracle 官方文档：/pls/db102/homepage 4、Thomas Connolly,Carolyn Begg.数据库系统设计、实现与管理（第三版）.北京:电子工业出版社,2003 计算机学院 学院（系） 计算机科学与技术 专业 330604 班地震前兆系统元数据管理的设计与实现摘 要在地震前兆行业中，存在各级单位和机构，如何动态管理各级单位之间的关系、保证下级的元数据可以及时同步到上级和分布式系统中元数据的约束性，是地震前兆行业面临的现实问题。针对前兆行业的现状和需求，基于对现有元数据管理方案的分析，结合地震前兆系统元数据的多样性、分布性、约束性等特点，本论文提出了一个元数据管理DAR模型，并将该模型应用于前兆行业，设计并实现了前兆元数据管理系统。并在实际环境中对系统进行了测试与分析，给出系统评价。本系统基于MVC设计模式，分为展示层、业务层、逻辑层和资源层，具有平台无关性。系统采用了多重管理方式实现了元数据的有效性约束、唯一性约束与一致性约束，具有完善的冲突处理机制，并且具备容灾恢复能力，可以有效地组织与管理前兆系统中的元数据，能够满足地震前兆系统各级单位统一访问大量设备与数据资源的需求。关键词： 元数据，分布式数据库系统，MVC，约束性，DAR模型 Design and Implementation of Metadata Management for Earthquake Precursor SystemAuthor :LIU YuTutor :MA Shi-longAbstractThere are a large number of units and organizations in earthquake precursor industry. The earthquake precursor industry faces some problems, such as how to dynamic manage the relation among different units, how to synchronize the lower units metadata to upper unit in a quick way and how to manage the metadata restriction in distributed system.In this paper, aimed at the current situation and demand of earthquake precursor industry and based on the analysis of existing metadata management programs， I bring forward one metadata management model DAR Model with the consideration of the system metadatas property of diversity， distribution and restriction. With the model of DAR I design and implement a metadata management system for earthquake precursor industry. The metadata management system is tested in the practical environment and the evaluation is showed in this paper.The system is designed with four layer of view layer, business layer, logic layer and resource layer according to MVC pattern, and it is platform-independent. With the multiple managements the system implements the validity restriction, exclusion restriction and coherence restriction for metadata, implements the conflict management mechanism, and has the ability of recovery from disaster. It can effectively organize and manage the metadata in earthquake precursor system, and provide strong support to access the devices and data resources in a unified manner for all level units of earthquake precursor industry.Key words: Metadata, Distributed Database System, MVC，Restriction，DAR Model目 录第一章 绪论11.1 课题来源11.2 课题背景11.3 课题目的21.4 课题研究内容及方法31.5 论文组织结构4第二章 相关技术和内容62.1Oracle数据库基础知识62.1.1 Oracle数据库体系结构62.1.2 Oracle数据库存储过程72.1.2 Oracle数据库触发器82.2 分布式数据复制112.2.1 分布式数据库112.2.2 分布式数据复制112.2.3 分布式数据复制的Oracle实现122.3 MVC设计模式142.3.1 MVC设计思想142.3.2 MVC的优点与缺点162.4 本章小结17第三章 地震前兆元数据管理系统分析与设计183.1地震前兆系统简介183.1.1物理拓扑183.1.2逻辑拓扑193.2元数据分析213.2.1元数据内容213.2.2元数据分类223.2.3元数据的特点233.2.4元数据管理机制233.3元数据管理模型DAR模型253.4系统体系结构263.4.1资源层273.4.2逻辑层283.4.3业务层303.4.4展示层303.5 本章小结31第四章 节点管理模块设计与实现324.1 节点管理的功能324.2节点管理的设计324.2.1三级节点管理334.2.2学科节点管理414.3节点管理的实现444.3.1三级节点管理444.3.2学科节点管理474.4 本章小结48第五章 系统配置模块设计与实现495.1 系统配置的功能495.2系统配置的设计505.2.1台站配置505.2.2仪器配置525.2.3备份库配置555.3系统配置的实现565.3.1台站配置565.3.2仪器配置575.3.3备份库配置595.4 本章小结60第六章 系统测试及性能分析616.1 测试环境616.1.1测试环境说明616.1.2 测试环境物理拓扑626.1.3 测试准备626.2 功能测试636.2.1 测试过程与结果636.2.2 结果分析666.3 约束性测试676.2.1 测试过程与结果676.2.3 结果分析696.4 容灾测试696.2.1 测试过程696.2.2 测试结果706.2.2结果分析706.5 测试分析与结论706.6 本章小结70第七章 总结与展望71致谢72参考文献73附录74附录A 数据库资源74附录B 系统截图78北京航空航天大学毕业设计(论文) 第81页第一章 绪论本章是论文的开始部分，概括介绍了课题来源、课题背景和目的、课题的研究内容及方法，最后列出了论文的组织结构。1.1 课题来源本课题来源于北京航空航天大学软件开发环境国家重点实验室承担的“中国数字地震观测网络前兆数据管理系统（十五工程）” ，该项目由中国地震局和北京航空航天大学两家单位联合完成。随着地震行业的信息化发展，我国地震观测、预测、应急等技术也开始向网络化、数字化迈进。中国数字地震观测网络是主要包括监测预报、震灾预防和紧急救援三大工作体系，实现包括数据采集、传输、分析、应用在内的全业务数字化网络化，全面提高监测预报水平，达到防震减灾的目的；建立完善的全国抗震救灾指挥体系，做到信息全、决策准、指挥有序、救援响应快；利用本项目建设后获得的各类设备的数据，实现跨地区、跨平台的数据共享，为社会提供更多信息服务。1.2 课题背景中国地震局中国数字地震观测网络系统覆盖范围广，面临多种节点类型：国家中心，区域中心，重点城市，基层节点。在地震业务方面，业务跨度大，职能上，系统覆盖的业务范围包括：专业应用，应急指挥，信息服务，政务系统，由于节点物理上的分布性，为了满足综合管理各个业务对数据的不同需求，需提供一个跨业务、综合性和专业性特色的设备统一管理和数据共享与交换平台，此平台的规划和建设将完整体现地震事业服务于政府、服务于公众、服务于科学研究的重要使命。在地震前兆行业内缺乏一个有效统一的设备和数据管理系统，各个单位自行建设。这样就造成大量异构平台与异构数据的存在。同时地震前兆行业中没有形成一个有效的设备统一管理和数据统一交换的手段，造成设备访问方式异构、数据处理手段单一，跨区域处理困难的现状。因此在地震前兆行业中，各级单位与机构虽然拥有大量丰富的设备资源，但是由于缺乏一个统一有效设备和数据的访问与管理机制，形成大量孤岛。这些孤岛影响了地震前兆行业内业务进一步发展，妨碍了地震前兆行业在国民经济建设中发挥更大作用。图 1.1 地震前兆行业面临的跨行政区域数据共享难题中国数字地震观测网络前兆数据管理系统的建设是为解决地震前兆行业内设备与数据资源共享、互联互通与协同工作的需求。如何动态管理各级单位之间的关系、保证下级的元数据信息可以及时同步到上级和分布式系统中元数据的约束性，是地震前兆行业面临的现实问题。1.3 课题目的国家地震前兆数据管理系统是一个全国部署的四层拓扑的系统，系统中有着十分复杂的元数据及元数据关系。如何有效的组织并管理这些元数据，对于前兆系统的稳定运行有着重要意义。元数据管理是整个前兆系统的核心模块之一。元数据管理部分是管理与维护系统元数据，并为前兆数据管理系统其它功能模块提供元数据支持。元数据管理模块与系统其它功能模块的关系如下图所示：统一访问界面 设备资源 系统监控数据备份数据交换数据采集核心业务元数据管理系统元数据管理服务服务服务服务图1.2 元数据管理与其它模块关系本论文就是要深入挖掘系统中的元数据，提取出系统中的全部元数据，并对这些元数据按照其操作类型、操作对象类型等属性进行分类，在分类的基础上分析讨论系统中元数据的特点，并依旧地震前兆系统对元数据管理的要求及系统中元数据的特点，对提出元数据管理的需求。按照需求对元数据管理系统进行体系结构设计，并进一步对每一功能模块进行详细设计与实现，最终完成地震前兆元数据管理系统。最后对元数据管理系统进行测试并给出系统评价。本论文设计实现的元数据管理系统最终要作为国家地震前兆数据管理系统的一个功能模块进行联合测试，并最终进行全国部署运行，服务于我国地震前兆事业。于是对本系统提出了更高的要求，不但要求系统功能正确，而且要求系统具有高的容错性和容灾性，能够面对不可预期的错误操作及不可抗拒的破坏性事故，要求系统从事故中恢复后能够尽可能地将损失减小到最少。1.4 课题研究内容及方法由于本系统是一个要在全国范围内部署运行的大规模网络工程项目，所以要求从项目需求分析到设计与实现，直至最后的测试都要严格按照规范，科学安排设计与开发过程，保证高质量软件系统的生产完成。在此基础上归纳课题研究的主要内容如下：1、 元数据提取及特点归纳：地震前兆数据管理系统存在大量系统元数据及地震前兆基础元数据。要想实现元数据管理，首先必须对系统的元数据有一个整体把握。本论文的第一部分工作就是要深入研究地震前兆数据管理系统的需求，透彻分析系统的结构，提取挖掘出系统中存在的元数据，并对这些元数据进行分类比较，在分类的基础上分析得出系统元数据的特点，根据系统需求及元数据的特点提出元数据管理的需求，指导后续设计与开发工作。2、 元数据管理模型建立：针对前兆行业的现状和需求，基于对现有元数据管理方案的分析，结合地震前兆系统元数据的多样性、分布性、约束性等特点，提出了一个元数据管理模型，并将该模型应用于前兆系统。3、 元数据管理关系管理：元数据管理的核心就是元数据关系的管理，即管理系统中元数据之间的相互关系。本系统元数据的关系包括：上下级间注册注销的关系、元数据同步等。在元数据关系管理中最核心的内容是元数据约束管理、冲突管理以及操作失败后的出错处理。本论文将在这些方面展开详细讨论与设计，并最终实现这些功能。4、 数据库管理：元数据是存储在数据库中的，元数据管理不可避免的与数据库管理有着密切的关系。本系统又是一个分布式数据库系统，对数据库的管理又提出了更高的要求。数据库管理主要内容包括：主键约束、外键约束、触发器管理、存储过程管理、JOB管理、DBLINK管理等。本论文将在深入分析ORACLE数据管理原理的基础上，设计出一个高效的数据库管理方式。1.5 论文组织结构本文一共由七个章节组成，论文的组织如下：第一章：绪论，首先介绍课题的来源、背景以及目的，最后论述了课题的研究内容和方法。第二章：相关技术和内容，从Oracle数据库的体系结构出发，介绍了包括触发器、存储过程在内的Oracle基本概念及技术；接着介绍了分布式数据复制的概念与应用，并介绍了分布式数据复制在Oracle中的具体实现MaterialView与DBLink技术；最后介绍了项目中所采用的MVC设计模式的基本理论。第三章：地震前兆系统元数据管理系统分析与设计，首先对国家地震前兆数据管理系统进行了简单介绍，然后分析提取出系统中元数据的特点及对管理机制的要求，提出元数据管理模型DAR模型，并根据此模型进行了系统体系结构设计。第四章：节点管理模块设计与实现，首先阐述节点管理模块的主要功能，接着对每一功能的处理流程进行了详细设计，最后讲解了数据库的实现。第五章：系统配置模块设计与实现，从阐述系统配置模块的主要功能入手，详细设计了每一功能的处理流程，最后讲解了具体实现。第六章：系统测试及性能分析，首先搭建了一个具有四层结构的测试环境，对论文设计实现的元数据管理系统进行了功能测试、约束性测试、容灾测试，并对测试结果进行分析总结，给出评价。第七章：总结与展望，总结了整个课题设计与开发过程中的所获取的经验，对完成的系统做出了相应的评价，并为今后进一步的工作指明了方向。第二章 相关技术和内容本章主要介绍一些技术背景知识，首先介绍Oracle数据库基础知识，包括Oracle数据库体系结构、数据库触发器Trigger、存储过程Procedure等。然后介绍分布式数据复制及其在Oracle数据库中的具体实现Material View与DBLink技术。最后，简单介绍系统采用的MVC设计模式的基础理论。2.1Oracle数据库基础知识Oracle数据库是Oracle公司开发的以高级结构化查询语言(SQL)为基础的大型关系数据库，是目前世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用范围广。2.1.1 Oracle数据库体系结构Oracle数据库体系结构由物理结构、逻辑结构、内存分配、后台进程等组成。如下图所示：数据库管理系统数据库服务器客户端PGASGA用户服务DBWR数据库数据文件控制文件联机文件归档文件CKPTLGWRARCH服务器服务器服务器SMONPMON图2.1 oracle数据库体系结构 物理结构物理结构由控制文件、数据文件、重做日志文件、参数文件、归档文件组成： 逻辑结构逻辑结构包括：表空间、段、区、块； 内存分配内存分配由SGA和PGA组成：SGA：是用于存储数据库信息的内存区，该信息为数据库进程所共享。它包含Oracle 服务器的数据和控制信息, 它是在Oracle 服务器所驻留的计算机的实际内存中得以分配，如果实际内存不够再往虚拟内存中写。PGA：包含单个服务器进程或单个后台进程的数据和控制信息，与几个进程共享的SGA 正相反PGA 是只被一个进程使用的区域，PGA 在创建进程时分配在终止进程时回收 后台进程后台进程包括：数据写进程、日志写进程、系统监控、进程监控、检查点进程、归档进程、服务进程、用户进程等2.1.2 Oracle数据库存储过程存储过程是由流控制和sql语句书写的过程，经编译和优化后，存储在数据库服务器中，使用时只要调用即可。 存储过程优点 存储过程的能力大大增强了sql语言的功能和灵活性。存储过程可以用流控制语句编写，具有很强的灵活性，能够完成复杂的逻辑判断和多功能集成运算。 可保证数据的安全性和完整性。通过存储过程可以使没有权限的用户在控制之下间接地存取数据库，从而保证数据的安全。而且通过存储过程可以使相关的动作在一起发生，从而可以维护数据库的完整性。 运用存储过程可以保证数据库系统的性能。在运行存储过程前，数据库已对其进行了语法和句法分析，并给出了优化执行方案。这种已经编译好的过程可极大地改善sql语句的性能。由于执行sql语句的大部分工作已经完成，所以存储过程能以极快的速度执行。 存储过程创建 生成触发器的语法如下：CREATE OR REPLACE PROCEDURE procedure_name (parameter ,parameter) IS declaration_sectionBEGIN executable_sectionEXCEPTION exception_sectionEND； 注释：procedure_name：存储过程名parameter：存储过程的参数，可分为传入参数与传出参数两种declaration_section：变量声明部分executable_section：过程主体程序exception_section：异常处理程序2.1.2 Oracle数据库触发器触发器是一种特殊类型的存储过程，主要是通过事件进行触发而被执行的，而存储过程可以通过存储过程名字而被直接调用。当对某一表进行诸如UPDATE、INSERT、DELETE 这些操作时，ORACLE就会自动执行触发器所定义的SQL 语句，从而确保对数据的处理必须符合由这些SQL 语句所定义的规则。触发器可以解决高级形式的业务规则或复杂行为限制以及实现定制记录等一些方面的问题。 触发器作用触发器的主要作用就是其能够实现由主键和外键所不能保证的复杂的参照完整性和数据的一致性。触发器的功能主要如下： 强化约束（Enforce restriction）触发器能够实现比CHECK 语句更为复杂的约束。 跟踪变化（Auditing changes）触发器可以侦测数据库内的操作，从而不允许数据库中未经许可的指定更新和变化。 级联运行（Cascaded operation）触发器可以侦测数据库内的操作，并自动地级联影响整个数据库的各项内容。形成级联操作，进而保证数据的完整性与有效性。 触发器分类触发器主要分为：语句触发器、行触发器、INSTEAD OF 触发器、条件触发器等。 语句触发器是在表上或者某些情况下的视图上执行的特定语句或者语句组上的触发器。能够与insert、update、delete或者组合上进行关联。但是无论使用什么样的组合，各个语句触发器都只会针对指定语句激活一次。 行触发器是指为受到影响的各个行激活的触发器 INSTEAD OF 触发器了提高查询性能，分割视图通常是一个来自多个表的结果集，但是也正因此而不支持视图更新。通过instead of 触发器可以实现此类视图的更新。 系统条件触发器系统事件包括：数据库启动、关闭，服务器错误等，系统触发器即是建立在此类事件上的触发器。 用户事件触发器用户事件包括：用户登陆、注销，create / alter / drop / analyze / audit / grant / revoke / rename / truncate / logoff 等，建立在此类事件上的触发器即是用户事件触发器。 触发器创建 生成触发器的语法如下：CREATE OR REPLACE TRIGGER schema.trigger_name BEFORE | AFTER DELETE | INSERT | UPDATE OF column , column OR DELETE | INSERT | UPDATE OF column , column ON schema. table_name REFERENCING OLD AS old NEW AS new | NEW AS new OLD AS old FOR EACH ROW WHEN (condition) pl/sql_block 注释：schema：数据库方案名trigger_name：触发器对象的名称。由于触发器是数据库自动执行的，因此该名称只是一个名称，没有实质的用途。触发时间：指明触发器何时执行，该值可取：before：表示在数据库动作之前触发器执行；after：表示在数据库动作之后出发器执行。触发事件：指明哪些数据库动作会触发此触发器：insert：数据库插入会触发此触发器；update：数据库修改会触发此触发器；delete：数据库删除会触发此触发器。table_name：数据库触发器所在的表。FOR EACH ROW：对表的每一行触发器执行一次。如果没有这一选项，则只对整个表执行一次。2.2 分布式数据复制2.2.1 分布式数据库分布式数据库是由一组数据组成的，这些数据物理上分布在计算机网络的不同结点上，逻辑上是属于同一个系统的。1、分布式数据库系统的基本特点： 物理分布性：数据不是存储在一个场地上，而是存储在计算机网络的多个场地上。 逻辑整体性：数据物理分布在各个场地，但逻辑上是一个整体，它们被所有用户（全局用户）共享，并由一个DDBMS统一管理。 场地自治性：各场地上的数据由本地的DBMS管理，具有自治处理能力，完成本场地的应用（局部应用）。 场地协作性：各场地虽然具有高度的自治性，但是又相互协作构成一个整体。2、分布式数据库系统的优点 具有灵活的体系结构 适应分布式的管理和控制机构 经济性能优越 系统的可靠性高、可用性好 局部应用的响应速度快 可扩展性好，易于集成现有的系统2.2.2 分布式数据复制一个分布式数据库系统由地理上分散的数据库所组成，这些数据库通常需要进行数据共享与数据交互。针对这些共享数据，可以将其存储在某个站点上，需要的用户都从这个站点上存取。这种方案的优点是数据的一致性容易保证，但其缺点也是很突出的，那就是该站点的负载大、网络负载大，远程用户的数据响应迟缓。数据复制技术可以有效地解决这个问题，它通过将这些共享数据复制到位于不同地点的多个数据库中，从而实现数据的本地访问，减少了网络负荷，并提高了数据访问的性能，而且通过对数据库中的数据定期同步，从而确保了所有的用户使用同样的、最新的数据。该技术适用于用户数量较大、地理分布较广、而且需要实时地访问相同数据的应用环境。分布式数据复制，就是将数据库中的数据拷贝到另外一个或多个不同的物理站点上，从而保持源数据库与目标数据库中指定数据的一致性。按照数据复制的实时性，数据复制可分为同步数据复制和异步数据复制。按照复制站点的类型，数据复制可分为多主控站点复制、物化视图复制及混合复制。数据复制最基本的功能是提高数据库的性能。它通过将远程数据库中的数据复制到本地，使得应用能够就近访问数据，从而降低网络传输负载，提高效率。而且在数据复制系统中，可以提供多个站点之间的负载平衡，让这几个用户使用这个服务器，另外几个用户可以使用其他的服务器，以避免某些站点负载过重。在复制环境中，尽管在数据库和应用程序设计过程中，会尽量避免各站点间冲突的发生，但完全避免冲突的可能性还是比较小的，那么一旦冲突发生，就需要一个按照具体业务规则的冲突解决机制，来使得各站点的数据保持一致。2.2.3 分布式数据复制的Oracle实现Oracle数据库有一整套对分布式数据复制的支持机制，其中的核心技术主要是：Material View和Database Link技术。 Material View技术Oracle数据库的快照是一个表，它包含有对一个本地或远程数据库上一个或多个表或视图的查询的结果。正因为快照是一个主表的查询子集，并且是存储在本地，因此使用快照可以加快数据的查询速度；在保持不同数据库中的两个表的同步中，利用快照刷新，数据的更新性能也会有很大的改善。物化视图可以分为以下三种类型：包含聚集的物化视图；只包含连接的物化视图；嵌套物化视图。刷新（Refresh）：指当基表发生了DML操作后，物化视图何时采用哪种方式和基表进行同步。刷新的模式有两种：ON DEMAND和ON COMMIT。ON DEMAND指物化视图在用户需要的时候进行刷新，可以手工通过DBMS_MVIEW.REFRESH等方法来进行刷新，也可以通过JOB定时进行刷新。ON COMMIT指出物化视图在对基表的DML操作提交的同时进行刷新。刷新的方法有四种：FAST、COMPLETE、FORCE和NEVER。FAST刷新采用增量刷新，只刷新自上次刷新以后进行的修改。COMPLETE刷新对整个物化视图进行完全的刷新。 Material View创建的简单语法如下：CREATE SNAPSHOT schema.snapshot AS cluster REFRESH FAST | COMPLETE | FORCE START WITH date NEXT date 解释：Schema：拥有该物化视图的方案名Snapshot：物化视图名字Cluster：组成物化视图中数据的查询语句REFRESH：定义物化视图的刷新方式及刷新周期实例互联技术Database Link数据库连接串是Oracle数据库在分布式数据库系统中用于建立对远程数据库的访问方法，通过它可以直接读取或者修改远程Oracle数据库的数据。数据库连接串可以是公用连接PUBLIC或者私有连接PRIVATE。分布式数据库系统中各个独立的数据库通过DBLink连接为一个逻辑上的大数据库。用户可以通过DBLink对异地数据库中的数据进行存取，而服务器之间的协同处理对于工作站用户及应用程序而言是完全透明的：开发人员无需关心网络的链接细节、无需关心数据在网络接点中的具体分布情况、也无需关心服务器之间的协调工作过程。 Database Link创建语法如下：CREATE SHARED PUBLIC DATABASE LINK dblink CONNECT TO CURRENT_USER | user IDENTIFIED BY password USING (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = host_ip)(PORT = host_port)(CONNECT_DATA =(SERVICE_NAME = host_instance) 解释：dblink：是数据库连接串的名字。以后就通过这个名字来进行调用远程数据库的内容。user：是用来连接到远程数据库的合法Oracle用户名。password：为该用户连接到Oracle时候的合法密码。host_ip：目的Oracle数据库所在的主机上的IP。host_port：目的Oracle数据库连接端口。host_instance：目的Oracle数据库实例。2.3 MVC设计模式2.3.1 MVC设计思想MVC（Model-View-Controller），即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层模型层、视图层、控制层。 视图(View)代表用户交互界面。对于Web应用来说，可以概括为HTML 、XHTML、XML和Applet界面。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。 模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。 业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。 控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。 模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化传播机制。模型、视图、控制器三者之间的关系和各自的主要功能，如下图所示：模型封装应用程序状态响应状态查询应用程序功能通知视图改变视图解释模型模型更新请求发送用户输入给控制器允许控制器选择视图 控制器定义应用程序行为用户动作映射成模型更新选择响应的视图通知改变视图选择用户请求状态改变状态查询方法调用事件图2.2 MVC模式2.3.2 MVC的优点与缺点1、MVC的优点表现在以下几个方面： （1）可以为一个模型在运行时同时建立和使用多个视图。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。（2） 视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。（3）模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。（4） 潜在的框架结构。它有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。2、MVC的不足体现在以下几个方面：（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。（4） 目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。2.4 本章小结本章从ORACLE数据库的体系结构入手，介绍了ORACLE数据库的基础技术，接着详细介绍分布式数据库系统及分布式数据复制技术，以及Oracle数据库对分布式数据库系统的支持技术：Material View与Database Link技术。最后介绍了系统所采用的MVC设计模式的理论。本章内容为系统的开发与研究奠定了理论基础与技术支持。第三章 地震前兆元数据管理系统分析与设计本章首先介绍了地震前兆系统的物理拓扑及逻辑拓扑，分析得出系统元数据的特点，提出元数据管理DAR模型，在此基础上设计出元数据管理系统的体系结构。在论文后续章节中将具体展开主要功能模块的设计与实现。3.1地震前兆系统简介3.1.1物理拓扑国家地震前兆数据管理系统是一个在全国部署的分层次的大规模分布式应用系统，其中位于最上层的是国家中心，其下有32个省级区域中心，区域中心下辖台站，台站数量由各省实际台站数决定，由几个至几十个不等，全国共设360多个台站，台站挂接仪器，区域中心也可通过直属台站来挂接仪器。另外还有五个学科中心，进行地震前兆专项数据分析，分别是地磁学科中心、地电学科中心、流体学科中心、重力学科中心、形变学科中心。国家地震前兆数据管理系统物理拓扑如下图所示：图3.1 国家地震前兆数据管理系统物理拓扑图由上图可以看出这是一个四层的互连互通的分布式应用系统。在这样一个大型分布式系统中，存在大量的元数据。本章就是要对系统中的元数据进行分类分析，并在此基础上提出对元数据管理的几点基本需求。3.1.2逻辑拓扑元数据管理系统是前兆数据管理系统的一个重要组成部分，元数据管理为前兆系统提供节点、仪器、资源等的状态描述与关联描述信息，保证前兆数据管理系统的稳定运行。基于前兆数据管理系统的多层次树型结构，前兆元数据管理也同样的在逻辑上分为学科中心、国家中心、区域中心、台站四级结构，其中学科、国家、区域又实行应用服务器、数据库服务器、备份库服务器的分离管理。前兆元数据管理系统逻辑拓扑结构如下图所示：图3.2 元数据管理逻辑拓扑由上图可看出前兆元数据管理共分为学科、国家、区域、台站四层。1、台站台站位于地震前兆系统元数据管理逻辑拓扑结构的最底层，这里的台站是拥有独立服务器，可以自治管理内部资源的一个节点。台站应用服务器、数据库服务器位于一台服务器上，不设备份库，也不需要汇聚下层的元数据，所以台站的元数据管理是四层中最简单的一层。2、区域中心区域中心位于台站与国家中心之间，对下审批台站注册并汇聚来自隶属台站的元数据信息，对上向国家中心注册，并提供自身及隶属台站的元数据信息。同时区域中心是应用服务器、数据库服务器、备份库服务器分离管理。因此区域中心是元数据管理中的一个典型节点，几乎涉及到前兆元数据管理的所有内容。3、国家中心：国家中心是四层结构中很关键的一层，它对下汇聚来自己台站与区域的全部元数据，拥有整个系统中的完整元数据结构，对上向不同的学科中心提供相应的元数据。汇聚整个前兆数据管理系统中所有的节点、仪器信息，拥有整个系统的完整物理拓扑结构。同时与学科中心产生关联，是元数据量最多的一个节点。4、学科中心：学科中心是进行地震领域专门学科研究的节点，目前共设地磁、地电、形变、流体、重力五个学科中心。每个学科中心只从国家中心获取与其学科相关联的元数据，进行相应学科领域的研究工作。同时要保证学科的独立性，每个学科中心不能查看不属于它的学科领域的原数据。仔细分析这四层节点的特点及相互关系，可以将其分为两类：其中一类包括：国家中心、区域中心和台站，这三级节点构成一个完整的三层树型结构，其中上级节点通过同步得到其下属节点的元数据信息。在这一类节点中下属节点的数目是不确定的。另一类是学科中心节点，学科中心只跟国家中心产生联系，这一类节点的数目是确定的，五个学科中心。3.2元数据分析在本节中主要抽取地震前兆数据管理中的元数据，并对这些元数据按照相关性进行分类总结。3.2.1元数据内容元数据是结构化的描述数据的数据。用于描述数据的内容、覆盖范围、质量、管理方式、数据的所有者、数据的提供方式等信息，是数据与数据用户之间的桥梁。元数据可以为各种形态的信息资源提供规范、普遍的描述方法和检索工具，为分布的、由多种资源组成的信息体系（如地震前兆数据管理系统）提供整合的工具与纽带。离开元数据系统是不完善的，无法提供有效的服务的。元数据可以出现在：数据内部、独立于数据、伴随着数据、与数据包裹在一起。考虑地震前兆数据管理系统中各种设备资源、数据资源的规模及需求，并结合实际部署环境的要求，提取元数据如所示： 仪器元数据：仪器代码、仪器名称、仪器型号、生产厂家名称、生产厂家地址、联系方式、仪器记录方式、性能指标描述等。 台站元数据：台站代码、建台改造日期、台站名称、纬度、经度、值班电话、通讯地址等。 区域元数据：节点应用服务器IP、节点数据库服务器IP、注册到区域的台站信息、是否注册到国家、是否有备份库等。 国家中心元数据：节点应用服务器IP、节点数据库服务器IP、已注册到国家的区域与学科中心信息，备份库信息等。 学科中心元数据：节点应用服务器IP、节点数据库服务器IP、是否注册到国家、是否有备份库等。 备份数据库元数据：是否注册到主库、主库IP、本机IP等。 地震前兆基础元数据：测项分量信息表、泉信息表等。3.2.2元数据分类上节抽取出的元数据是零散的，为了方便元数据的管理，更好的为地震前兆数据管理系统提供元数据服务，根据这些元数据的类型、相互之间的相关程度及系统各功能模块的实际需求，将这些元数据分为三大类：节点管理元数据、系统配置元数据与地震前兆基础元数据，具体分类如下：1、节点管理元数据：学科中心元数据国家中心元数据区域中心元数据节点台站元数据2、系统配置元数据：仪器元数据台站配置元数据备份库元数据3、地震前兆基础元数据说明：台站分两种，一种是有独立服务器的节点台站，一种是在节点台站上配置的下属台站和在区域上配置的直属台站。从上述分类中不难看出：前兆系统元数据管理主要由节点管理与系统配置两大模块组成。3.2.3元数据的特点国家地震前兆系统属于大规模数据网格应用系统，对系统中的元数据进行抽取与分类后，分析得出前兆系统元数据的特点如下：1多样性地震前兆数据管理系统由5个学科中心、1个国家中心、32个区域中心和数百个台站，以及90多种仪器，其中包括60多种IP数字化仪器和30多种非IP数字化仪器，每个节点由应用服务器、数据库服务器、备份库组成。由此可知系统的元数据种类系繁多。2分布性地震前兆系统是一个全国部署的应用系统，区域部署到各省中心，台站部署到各区域中心，这一特点就决定了系统元数据是分散在全国各地的，元数据具有地域分布性。3自治性系统中每一个节点，都可以在实际环境中根据自身需求自主决定台站配置、仪器配置、节点注册、备份库注册等，每个节点都拥有对自己元数据的自主管理权，节点内部操作不会影响到其它节点，所以元数据又具有节点自治性。4约束性这种约束性具体包括：有效性约束、一致性约束、唯一性约束。有效性约束主要是在元数据进入系统时起作用的，保证进入系统的元数据满足特定的格式或其它特定的要求；一致性约束是指同一份元数据在分布式系统的不同节点都会有一份冗余，当其中一处改变后，其它节点也要同步修改；唯一性约束是指系统中的元数据是具有全局唯一性，不允许两份不同的元数据拥有相同的标识。3.2.4元数据管理机制国家地震前兆数据管理系统是为地震前兆提供一个实现设备访问、数据采集、数据汇聚、节点管理的网格平台。通过该系统，屏蔽网格环境中各类设备资源的异构性、分布性与多类型性，充分实现行业内资源整合。使从业人员通过地震前兆数据管理系统方便的访问各类资源、管理各类资源。基于系统的复杂性与实际环境的不确定性，前兆数据管理系统的稳定运行要求有一个高效稳定逻辑合理的元数据管理机制来做支撑。为适应地震前兆元数据的类型繁多、分布性、自治性、约束性等特点，地震前兆元数据管理系统具有以下特性：1. 自治性：应能满足每个不同的节点对自己内部的元数据拥有全部支配权，可以自主决定元数据的插入、更改、删除，并保证不同节点的操作不会相互干扰，同时不允许节点对其它节点内部的元数据进行越权操作。具体包括：同级节点完全独立；上级节点可以通过同步机制查看到下属节点的元数据信息，但不能对其进行插入、更改、删除等操作。2. 有效性：地震前兆系统是一个专业领域的系统，为方便系统管理，对系统中的元数据的格式有有效性要求。比如：仪器ID必须为12位字母或数字，每个指定的仪器ID只能配在某指定区域等等。元数据管理必须为这些元数据的格式给出有效性约束，避免非法元数据进入系统。3. 唯一性：前兆系统中的每一个资源在系统的同一个节点内部都必须拥有唯一标识，能够根据标识唯一定位系统中的一个资源。比如：一个区域下面的两个台站分别配置了同一台仪器，在台站的层面这是允许的，但是当这一仪器元数据向区域同步时，后同步的那个台站的关于这台仪器的信息产生冲突，要求系统具备冲突处理能力，保证元数据的唯一性约束。4. 一致性：前兆系统的元数据通过台站、区域、国家、学科中心层层向上级同步，同一条元数据信息可能在台站、区域、国家、学科中心都存在，这就要求在分布式数据库系统的不同节点内部的相同元数据具有一致性。当在系统的一处修改了元数据信息，系统内部其它节点的冗余元数据也必须全部更新，保证元数据的一致性约束。5. 健壮性：国家地震前兆系统由于其行业特殊性，对系统持续稳定运行性有