统一数据库（精选10篇）
统一数据库 篇1
1 引言
在地震勘探中,采集软件需要进行参数论证、观测系统设计及野外施工、质量监控等环节,在单机的软件版本中MySQL等中小型开销和规模的数据库,既可以满足生产使用条件,也可以达到高性能。但在正演模拟等大计算量,模型等数据及相应的索引信息有时需要存放在一个大型的数据库服务器(ORACLE)中;并且在地震资料采集、处理、解释一体化软件中,根据数据及相应计算结果的高效访问、安全级别等要求,需要使用不同级别的数据库管理软件来统一管理数据。这些都会带来同一个数据模型可能会访问不同的数据库的情况。
本文根据地震勘探软件一体化[1]的要求,以数据为驱动,以模型为中心,统一数据模型访问接口和平台无关性为目标,设计了一套对任意数据库访问的统一接口模型。
2 设计思想
各种数据库为了满足应用程序的调用,都提供了一组跨平台的、语言绑定的数据库API(应用程序编程接口),MySQL与C绑定的有MySQL Connector/C[2],ORACLE与C++绑定的有OCI[3],这些API此处简称为数据库驱动。一个基于数据库统一接口模型的应用程序,在数据库访问时,只要指定数据库驱动便可以使用数据库统一接口模型进行数据库操作。这些操作包括:①打开/关闭数据库;②SQL语句的直接执行;③事务的控制/回滚等。基于此模型的应用程序对数据库的操作不直接与DBMS(数据库管理系统)打交道,所有的数据库操作由统一接口模型完成。即不论是MySQL、ORACLE还是其他的数据库数据,都可用统一接口进行访问。
数据库统一接口模型位于数据库应用程序和具体的数据库驱动的中间层,他既为上层的数据库应用程序提供服务,又为下层的具体数据库驱动提供服务。数据库统一接口模型为处理下层不同数据库的差异,提供了一个不同数据库驱动的抽象接口;为上层应用也提供了一个抽象的、易使用的应用层接口及应用层需要的数据库查询结果集、数据库控制、数据库状态监控、数据库索引等信息的统一管理和操作的平台。因此数据库统一接口模型即包含了3方面内容:①面向数据库驱动的抽象接口层;②面向应用程序的统一接口;③数据库各种操作及结果集的管理平台。对于数据库驱动抽象接口层,本文实现了ORACLE的OCI数据库驱动和MySQL的MySQL Connector/C数据库驱动。
2 数据库统一接口模型设计
2.1 总体框架设计
数据库统一接口模型框架主要围绕以下两个要点进行设计。
(1)对各种数据库驱动的封装。这一层的设计目标是:数据库各种操作的抽象定义,达到隔离各种数据库驱动;设计原则是:不损失数据库访问的性能;
(2)提供应用层调用的统一接口。这一层首先需要提供数据库的连接管理功能,它可以管理多个数据库连接。其次,在应用程序连接数据库成功后,需要提供数据库统一的操作接口。如:数据库连接,数据库查询,SQL位置/参数绑定,数据结果集操作,数据库异常管理等接口。最后,在应用程序数据操作的过程,需要提供数据库操作的管理,及结果集的管理。如:数据库SQL语句执行管理,操作结果集管理,数据库操作异常管理,数据库字段管理,数据库索引管理等。
根据以上两个主要的设计要点,数据库统一接口模型框架可设计为数据库驱动抽象层和应用程序统一的调用接口层两部分。前者实现底层各种数据库驱动的隔离,为统一接口层提供统一的数据库驱动接口;后者实现数据库各种连接、操作及结果集的管理,既为应用层提供统一的接口和高效的操作管理,也使得应用层可以简易的设计出视图模型——通过绑定查询结果集到视图。
2.2 数据库驱动抽象层的设计
数据库驱动抽象层,封装了各种数据库操作的数据类型、语句类型、驱动接口等。由数据库的常用操作分析可得到两大类统一的数据库抽象接口:
(1)和数据库驱动支持的特性有关的:数据库打开/关闭、各种表获取、把字段值格式转换成指定数据库能识别的数据类型、主键索引、记录获取、开始事务、提交事务、回滚事务、获取数据库操作异常码、获取数据库表、字段值精度设置、获取数据库句柄、数据库支持特性(如事务)查询等接口。
(2)和数据库的操作结果有关的:SQL查询/操作、直接SQL语句、ODBC或ORACLE风格的SQL语句绑定相关的操作、结果集操作等接口。
有以上分析可设计出如图2的数据库驱动抽象层类图。类图把数据库驱动层分成两大部分,图2左边部分实现的是和数据库驱动支持特性相关的类图,右边部分为SQL操作及结果集有关的类图。其中MYSQLDriver是对抽象类SqlDriver的MySQL驱动的实现,在MYSQLDriver中封装了MYSQL*等MySQL驱动的句柄,它们是建立数库连接时会产生的实例,它记录了连接网络参数、服务器地址等信息。其次MYSQLResult是对抽象类SqlResult的MySQL驱动的实现,在MYSQLResult中封装了MYRES*和MYSQL_ROW*等MySQL驱动句柄[4],它们分别记录了一个查询的结果和一个行数据的安全类型表示。通过这两个抽象类,就可以封装数据库驱动,也达到隔离各个数据库的不同实现方式,ORACLE的数据库驱动[5]实现类似于此处的MySQL。当然,还有数据库数据类型的抽象,通过boost库提供的any类[6]作为可变数据类型,在设置和获取数据时,通过具体的数据类型判断,分配数据类型的数据空间给any类实例就可以实现。
2.3 应用程序统一接口设计
应用程序统一接口的设计目标是,通过指定数据库驱动及服务器地址或机器名、数据库名、用户名、用户密码和其他的可选项,然后打开数据库,如果打开成功,就可以使用sql执行函数执行,并返回结果集。如果需要位置或参数绑定的,则可以位置或参数绑定,然后在每次执行sql之前,指定绑定处的具体值,就可执行sql并返回结果集。而且这些结果集的操作可以通过统一的接口获取。这就封装了使用原始数据库驱动需要的频繁初始化及各种操作句柄的管理工作。以下是统一接口中的主要接口定义:
(1)指定数据库驱动的接口:AddDatabaseDriver(const string &dbDriver),其中dbDriver是数据库驱动的类型,是SqlDatabase(数据库连接管理类)中的一个接口,在此类实例初始化时,会根据指定的数据库驱动类型实例化相应的数据库驱动。
(2)指定数据库连接信息接口:SetHostName(const string &name),SetDatabase-Name(const string &name),SetUserName(const string &name),SetPassword(const string &pd);上面四个接口分别设置连接服务器地址、数据库名、用户名、用户密码,一般有这些信息就可以成功登录到数据库服务器。
(3)位置/参数绑定的sql查询接口:Prepare(const string &sql),AddBindValue(const any & val, ParamType paramType),Exec();Prepare接口使用位置/参数绑定接口,AddBindValue接口为相应的绑定处指定具体值,Exec()就是执行此次设置的sql,如需要绑定其它值,只需重新绑定有意义的具体值,然后再执行Exec()即可实现。如想直接执行sql,只要使用重载的Exec(const string &sql)接口即可。
(4)结果集操作接口:判断Next()的调用为true,就可以使用Value(int index)函数返回当前记录在index处的字段值。
2.4 连接、操作及结果集的管理
数据库驱动和应用程序统一接口必须通过连接及操作和结果集的管理平台联系在一起。根据架构设计,主要有以下两类管理元素:数据库连接管理;数据库操作及结果集管理[7]。数据库连接管理主要有:数据库的连接的建立、删除;驱动的类型的添加、记录;事务开始、结束和回滚的控制[8]。操作及结果集管理主要有:直接sql的执行;位置/参数绑定及此种sql的执行;结果集中的记录个数、记录内容及记录内容访问等的管理。图3说明了数据库驱动和应用程序统一接口通过SqlDatabase和SqlQuery两个管理类连接起来的时序图。图3中完成了一次从数据库驱动的指定到位置绑定参数并执行sql,最后对返回的sql结果集进行字段值访问的过程。前4步实例化指定的数据库驱动SqlMYSQLDriver;第5步是设置连接数据的信息,图中只画了设置服务器名;第6步到第9步打开指定驱动和服务器信息的数据库;第10到第13步创建了sql操作管理类SqlQuery的实例,并创建1到4所指定的数据驱动的SqlMYSQLResult实例部分;第14到第18步参数绑定、设置绑定处具体值并执行;第18到24步,使用Next()判断结果集是否存在,如果存在就可以使用Value()获取字段值。
3 结束语
以上设计的数据库统一接口模型,通过测试,可以很好的运行在Window和Linux平台上。它有以下几个优点:①为应用层的模型/UI设计人员带来了方便;②实现了应用程序操作系统平台无关性,移植到不同的平台上,只要重新编译链接一次应用程序即可;③较好的数据库操作和结果集的管理平台,为模型绑定视图类的实现,提供了便利。本文只实现了基于OCI和MySQL Connector/C++两种数据库驱动的接口,其他数据库驱动的实现可以参照数据库驱动的统一接口设计,来提供更多的数据库驱动的支持。
参考文献
[1]赵贤正等,高精度三维地震采集处理解释一体化勘探技术与管理[J].中国石油勘探2010,(2):
[2]MySQL 5.5 Reference Manual,http://dev.mysql.com/doc/.
[3]B10778-01,Oracle?C++Call Interface Programmer's Guide 10g Release 1(10.1),http://otn.oracle.com/tech/oci/occi/index.html.
[4]W.Jason Gilmore,Beginning PHP and MySql(3th Edtion)[M].2009.6
[5]朱宏玮,徐晓梅,张飞飞.Oracle C++调用接口[J].中国科技信息,2005,(14):15-16
[6]Kevlin Henney,Boost 1.48.0 Library Documentation.http://www.boost.org/doc/libs/1_48_0.
[7]Abraham Silberschatz,Henry F.Korth S.Sudarshan,Database System Conncepts(6th Edition),2009.11.
[8]Stephens,R.K.and Plew.R.R.,Database Design,2001.09
统一数据库 篇2
哈佛结构的微处理器通常具有较高的执行效率。
哈佛结构是为了高速数据处理而采用的，因为可以同时读取指令和数据（分开存储的）。大大提高了数据吞吐率，缺点是结构复杂。对外围设备的连接与处理要求高，十分不适合外围存储器的扩展。所以早期通用CPU难以采用这种结构。
通用微机（冯）指令和数据是混合存储的，结构上简单，成本低。
单片机，由于内部集成了所需的存储器，所以采用哈佛结构也未尝不可。处理器，依托CACHE的存在，已经很好的将二者统一起来了。
统一数据库 篇3
然而，越来越多的资源只用于满足每年的数据管理和法规遵从需求。要满足企业利用数据和信息创造价值的目标和策略变得非常困难。而且，许多企业的IT预算可能会持平或下降。对于要实现各种在IT基础上实现更高价值目标的企业而言，IT部门不仅要确保基础设施的利用率和管理效率，还需要更多信息挖掘和管理方式，以便助力业务部门的更高要求。
通过融合提高效率和易用性
通过多年的服务器与管理程序的整合以及存储与SAN的整合，许多容易实现的目标目前已实现整合。下一波整合浪潮将为通用容量池（common capacity pool）带来多种可根据需要提供的数据类型。
统一存储系统，亦称多协议存储（MPS）系统，是解决数据增长问题的一种常见方法。统一存储系统使用户能够通过在单一系统中存储基于模块和文件的数据来提高其存储系统的利用率和功效。更值得一提的是，这类系统还支持对象数据。由于数据容量已持续爆炸性增长到拍字节（Petabytes）和艾字节(Exabytes)，具备智能地存储、复制和搜索的能力对高效数据存储具有战略性意义。
传统的统一管理关注的是如何在通用的低端存储平台上管理文件和模块数据。而大客户真正需要的，是能够满足其关键业务应用的严苛服务水平要求的企业级统一存储平台。
理想的统一存储系统特征
企业希望统一存储系统具备一系列主要特征。挑选统一存储系统的一个关键要素是具备高性能的可扩展性和成本效益。不同平台混合使用时，一些统一存储系统可能无法提供所承诺的性能并有可能产生无法预料的兼容问题。优秀的统一存储系统不会导致性能下降，而且，随着统一存储系统不断扩展以及驱动器数量的增加，统一存储系统应提供接近线性的性能改进效果。其带来的效果是，扩展不会影响性能。
挑选统一存储系统的另外一个关键要素是支持基于对象存储的能力。增长幅度最大的数据是非结构化数据，这些数据将通过互联网协议以文件或对象的形式提供。非结构化数据可增长至成百上千的拍字节和数十亿个对象，这必然需要更大的文件系统和可扩展的模块存储系统，但这并不能完全解决问题。
非结构化数据的增长需要对文件、模块和对象数据存储进行融合。通过消除数据保护的备份成本，数据分析的ETL（提取、转换和加载）成本，以及文件、模块和对象存储孤岛的管理成本来提高存储效率。这就是应对重大数据挑战要求支持对象存储的原因所在。
此外，当企业能够以有限的人力资源来有效管理IT基础设施时，能够提供单一软件管理平台的统一存储系统会使其具有更大的优势。
重新定义统一存储
以Hitachi Command Suite（HCS）为单一管理框架的Hitachi Unified Storage（HUS）恰好对客户管理模块、文件和对象数据的方式带来了革命性的变化，无须在性能、可扩展性或成本效益方面做出妥协。与传统只能扩展容量的解决方案所不同的是，HUS能够按照可预测的性能、复制的数据、模块卷大小和文件系统大小进行扩展。HUS平台为客户带来的好处是使用寿命比竞争产品长，而且投资效益更佳。
HUS借助基于对象的独特文件系统为每个文件智能地添加元数据，从而来支持对象数据。此外，HUS还支持Hitachi Content Platform（HCP）利用自定义元数据真正存储对象数据，并确保其遵从性。
HCP可以与来自相同存储池的文件和模块应用程序共享HUS容量。与单独孤立的对象存储实施方案相比，该解决方案为客户提供了更高的空间使用效率和成本效益。
HUS的目标市场以拥有多种微软办公应用软件和文件共享服务器，并习惯于采购和使用中端企业存储解决方案的传统中型企业为主。HUS之所以具备独特的魅力，是因为它能够把这些服务器的存储整合到一个平台上，这有利于管理，提高容量利用率并节省环境成本（电力/空调/空间）。
对统一数据库安全增强系统的思考 篇4
关键词：UDS,数据库管理,认证
0 引言
UDS系统提供了一种在数据库管理系统外围增加一套安全控制机制的方式, 有针对性地解决了数据库连接密码固定不变的问题, 能够根据用户制定的密码保护等级的要求周期性地随机生成新的合法密码, 使得在不影响数据库信息和较少影响数据库访问及基于数据库的应用系统的开发这些前提下能够充分保障数据库中数据信息的机密性和有效性, 并且能够支持多种关系数据库产品。
1 UDS的组成及应用架构
如图1.1, UDS系统由以下组件构成:
1) UDS服务器
UDS服务器是UDS系统的核心部件, 实现了对主流数据库系统的数据源管理、用户管理、安全策略管理、权限管理和安全审计等功能, 同时也为UDS系统的其它部件提供操作对象。
2) UDS控制台
UDS控制台是UDS系统自身的安全管理控制台。UDS系统管理员通过UDS控制台对UDS服务器进行操作和管理, 完成数据源管理、数据库用户管理、数据库权限管理、数据库安全审计以及UDS系统自身的安全管理。UDS控制台采用IE等浏览器, 为UDS管理员提供简洁、易用的操作界面。
3) UDS数据库管理终端
UDS数据库管理终端是一个支持不同关系数据库的数据库管理工具, 针对组织内部不同类型、不同数量的数据库系统, 可以为DBA提供一个集中的、统一的、安全的、简便易用的运行管理界面。不同权限的DBA可以在获得UDS管理员授权后, 基于UDS服务器提供的虚拟数据库平台, 利用UDS数据库管理终端完成不同的工作任务。
4) UDS认证代理
UDS系统提供UDS认证代理, 为数据库管理员提供一种更安全可靠的登录数据库的方式。UDS认证代理采用USB KEY存储数据库用户的认证信息, 当验证数据库用户对USB KEY的访问权限后, 自动从USB KEY中读取用户的认证信息, 帮助数据库用户完成认证。
5) UDS应用接口
UDS系统对数据库系统的一个重大安全性改进是对所有数据库帐号密码进行定期或不定期更新, 为此UDS系统为数据库应用系统 (简称DBAS) 提供了API接口, 该接口可以从UDS系统中获取该数据库帐号的当前密码, 完成与数据库的连接。采用UDS应用接口, 只需要在数据库应用中对数据库连接部分的程序进行改造, 对系统用户来说完全透明, 而且不影响应用性能。
在上述系统结构下, 我们设计了如图1.2所示的系统架构, 从而保证UDS设计目标的实现。
UDS系统为了在较少影响用户日常使用的前提下提高现有关系数据库系统的安全性, 通过以下主要功能来保证:支持不同关系数据库, 并通过数据库权限申请审批流程控制相应用户具有的数据库权限;能够灵活配置安全策略来设置系统中不同对象的安全等级, 并根据安全等级定期更改密码等安全凭据;采用USBKEY对UDS系统用户进行鉴别, 并通过安全审计模块和灵活备份模块来共同保证系统本身的安全性和可靠性;能够管理基于数据库的应用程序并提供了相应接口;支持不同加密算法和工具的通用加密接口;具有可控的数据库管理工具, 以对数据库进行管理和维护。如图3所示:
2 结论
UDS系统通过接管数据库系统的管理权, 成为实际意义上的数据库管理员, 并通过其安全框架对数据库进行管理维护, 消除了数据库用户密码长期固定不变的安全隐患;提供应用程序接口, 确保应用程序能够获取定期和不定期变化的数据库连接用户密码, 较少影响应用程序的性能, 并且控制应用程序是否能够使用;UDS系统通过申请、审核、激活、收回的流程控制数据库用户权限的分发, 加入了强制控制的特征;此外, 对于系统的重要功能及操作环节均加入了审计点, 便于事后检查审计日志, 发现安全隐患。
参考文献
[1]许卓明, 苏文萍.关系数据库模式信息的提取[J].河海大学学报 (自然科学版) , 2005, 33 (2) :202-206.
高校信息化统一数据平台建设探讨 篇5
关键词：高校信息化；统一数据平台；信息孤岛
中图分类号：TP274.2文献标识码：A文章编号：1007-9599 (2013) 06-0000-02
随着信息技术和网络技术的发展，当今高校信息化进程得以高速推进，各大高校采用先进的信息技术，结合根据本校具体需求构建数字化校园，如教学管理系统、设备管理系统、实验室管理系统、人事管理系统、财务系统、科研项目管理系统等等，这些管理系统的部署切实提高了高校教学科研和服务管理水平，但存在的一些问题还是显而易见的，这些系统建设相对独立分散，软硬件协调问题突出，各系统间数据信息未实现共享，产生信息孤岛现象，以及信息安全问题等等。这些问题已经在实际运行过程中体现出来，影响到高校信息化建设的进一步发展。研究通过统一平台集成的方法，构建高校信息化系统统一数据平台，已成为高校信息化建设的迫切需求和发展趋势。
1高校信息化建设的现状
国内高校信息化建设普遍开始于20世纪90年代，各高校普遍重视信息化管理机制建设，从规划制定、经费保障、人才培养等方面加以支持，在不到20年的时间里进展显著，尤其在校园网基础设施建设、教学科研基础信息建设和管理信息系统建设方面取得很大发展，具体表现为：
1.1目前国内各高校已经全部建成校园网络，在我国自主研发的中国教育科研网（CERNET）系统支撑下，校园内各楼宇建筑和学生宿舍均已接通百兆/千兆有线网络，公共区域无线网络（wifi）覆盖率也不断提高，信号也得到有效改善。网络化校园的普及，为教学科研和服务管理提供有力保障。
1.2教学科研基础信息数据库建设也逐渐完善，形成校、院、系三级资源管理体系，对教学和科研资源形成了有效积累。校级信息资源一般以图书馆、档案馆和各职能部门管理系统组成，院、系两级则通常以内部服务器的形式保存信息资源。
1.3当今的数字化校园已普遍采用先进信息技术应用于教学科研和管理流程，多媒体教学、网络（辅助）教学的比重不断提高，基本建立了学校官网、校级电子邮件系统和校园卡系统等，服务于教学、科研、人事、财务等各方面的电子校务系统规范了办事流程，提高了办事效率，提升了管理水平。
2高校信息化建设存在的问题
国内高校信息化建设整体发展势头良好，但由于整体引入时间较短，一些理论和实践尚不成熟，存在的问题不容忽视。只有充分认识到问题所在，积极寻求解决问题的方法，教育信息化才能取得可持续发展。存在问题主要有：
2.1部分高校竞争意识淡薄，固守传统的管理理念和思维方式，没有认识到信息化建设对高校发展的积极作用。在信息化建设方面热情不高，投入较少，无法切实将信息化作为教学、科研和管理的重要组成部分，同时受主、客观条件的限制，已有信息资源的利用率地下，严重制约高校信息化的建设和发展。
2.2由于在信息化建设过程中缺乏统一指导和总体规划，各部门系统相对独立，各自为政，所部属的应用系统虽能解决部门内部业务需求，但由于缺少统一应用平台和数据交换渠道，信息孤岛现象日益严重。校内各部门的管理信息系统和数据资源类型各异，来源不一，导致相当一部分可共享的数据重复录入。而各项应用的认证入口和操作界面不统一，也无形中提高了管理维护成本。
2.3当前高校在信息化建设中对硬件设施投入较大，而对信息资源（软件平台）建设则相对薄弱。原因是前者投入见效快，成果明显。往往等到硬件环境建设好之后，才发现相应的软件支持不到位，而软件建设需要一个长期的过程，等软件开发基本完成，硬件又需要更新换代，形成了一个不良循环，造成严重的资源浪费。
2.4随着信息技术的飞速发展，信息安全问题日益突出，如黑客、病毒、恶意程序等，一旦发生这样的问题，高校各类信息资源将面临严重威胁，甚至导致数据丢失毁灭，造成的损失不可估量。必须不断探索和研究防止威胁信息系统安全的手段和方法，确保校园信息系统安全正常地运转。
3高校信息化平台建设规划
综上分析，现阶段要有效实施高校信息化建设任务，必须要重视三大平台的搭建和集成，分别是门户平台、数据交换平台和统一身份认证平台。登录数字化校园门户系统的用户可以访问门户连接的应用系统，可以通过访问鉴权来实现，通过统一资源系统中存储的用户系统登录和授权信息来完成单点登录各应用系统。
3.1门户平台
（1）门户平台系统集成是核心，系统集成按照集成深度可分为：界面集成、数据集成、应用集成。其中：
界面集成如不同业务系统的界面统一集成为门户界面；
数据集成典型的如基于全局库(共享库)开发查询类应用，如一卡通查询；
应用集成往往涉及多个应用，并基于这些应用进行流程重编排。
（2）门户平台提供服务包括：
信息门户的作用在于为数字化校园提供以下三个方面的服务：
整合数据：搜集和组织大量的、未相互连接的、分散数据；
发布信息：将这些数据以一种易用的、可定制的、基于浏览器的界面呈现给各类用户。
信息访问：通过多种访问机制，使用户可以不受时间、地点的约束进行访问。
3.2数据交换平台
数据交换平台是校园应用的基础，它是对校园网应用各种平台的数据收集、整理、存储和展示的重要基础平台，是数字化校园实现的前提和基础。数据交换平台是把不同来源、格式、特点性质的数据在逻辑上或物理上有机地集中，从而为高校提供全面的数据共享。它不但能解决各种应用系统的“数字孤岛”效应，保证数据的一致性，还能够为学生、老师提供完整的数字档案，并且能够为领导提供管理决策信息的重要功能。
数据交换平台建设中要确定各个职能部门和应用系统的权限分配，部署数据访问服务，严格进行权限分配。同时要形成一个中间层的数据交换平台，避免对于数据库的直接采集和访问，保证数据中心安全稳定。数据集成平台通过统一的全局数据模型来访问异构的数据库、遗留系统、Web资源等。它位于异构数据源系统（数据层）之间，向下协调各数据源系统，向上可以为访问集成数据的应用提供统一数据模式和数据访问的通用接口。
（1）信息编码需求：
1）按照国家对高校的标准前提下，参照学院各个系统的具体字段要求来设计数据中心数据库结构。具体标准包括：信息技术相关国家标准、《教育管理信息化标准-学校管理信息标准》。2）方便共享数据平台和各个应用系统的信息交互、保证基于数据平台数据的一致性。
（2）设计过程：
1）根据全校业务特征，确定共享库的实施阶段，根据各阶段的共享库覆盖范围分析部门之间和系统之间的信息共享范围。2）结合学校具体情况，定义数据库设计规范。3）基于全校信息编码规范，遵循分析的UC矩阵，分阶段对数据库进行结构设计。
（3）实施步骤：
1）建立学校级的数据交换中心；2）和学校信息建设小组确定需要进行数据交换的部门；3）对每一个部门进行数据交换规则调研，并确定交换规则；4）对原有系统进行调研，并确认不同系统之间的数据接口；5）改造数据接口；6）整合各个部门数据，并按照交换规则进行数据交换；7）完成数据交换后和原有系统并行试用一段时间，确定交换准确性和可行性。
统一数据库 篇6
随着校园信息化建设的不断深入,以及各业务部门应用系统的开发和投入应用,校园信息化建设中的问题也不断暴露出来。主要有以下问题:
(1)信息孤岛问题的形成。各业务部门各自为政,部门之间的信息交互和流通变得困难,形成了一个个的信息孤岛。
(2)没有统一的数据标准与规范。各业务系统中数据的定义和使用规范不统一,给进一步的数据共享造成困难,各个业务系统中,数据需要标准化、规范化。比如教师编码、学生学号、组织机构代码、专业代码等。
(3)全局信息应用困难。由于各个信息系统没有形成共享,所以全局信息无法形成。
为了避免上述情况的存在,各应用系统必须做到数据共享,形成统一的数据库平台。统一数据库平台就是基于信息标准体系,建立统一业务数据的数据管理和服务平台。平台应该提供统一的数据访问、交换和展现服务;支持第三方系统数据集成,实现信息共享;应该提供基于主题的综合查询服务,并可按照学校的具体业务需求扩展业务主题及查询服务;平台还应该提供基于主题的灵活报表工具,可以灵活生成各类报表。
1 统一数据库平台安全保障体系
(1)人员和机构保障
首先领导重视,按照三个层次建立组织结构,包括网络信息安全领导小组,网络信息安全工作小组,安全工作执行人员。安全领导小组由信息办主任、副主任、各中心主任组成;安全工作小组由信息办从各中心抽调对网络、信息系统安全技术比较精通的技术骨干组成安全工作虚拟团队。网络信息安全领导小组职责:把握信息安全的管理方向,制定并发布信息安全规划;参与信息安全方案的制定和评审,对方案的发布执行进行确认;强化及宣传信息安全意识,使信息办每位成员意识到信息安全的重要性,并按安全规范进行工作。
(2)健全保障体系
规范管理制度:安全方案评审、安全审计制度、各应用系统安全运行管理方案、各应用系统紧急情况备案、密码安全管理办法、故障恢复及安全维护流程、数据安全规范管理办法、校园网信息安全应急处置预案。
(3)依托先进技术
充分利用先进技术,保障校园网及数据库安全。使用具备旁路监听技术的设备过滤、限制访问不良网络信息;按照杀毒软件、专用漏洞扫描软件定期对系统进行漏洞扫描,并生成报告,提醒管理员对存在漏洞的系统进行整改。建立校园网络信息安全服务网站发布计算机病毒预报和安全漏洞等安全公告,分发安全补丁,并提供WSUS服务等;同时建立了异地数据备份和容灾方案、Log Server日志记录和NTP服务器等。
2 统一数据库平台的建设思路
统一数据库平台应关注从数据整合、数据管理使用到数据服务等多个层面的问题。平台对全校范围内分散异构的各类数据进行标准化,在数据一致、规范的基础上进行数据共享,并提供层次丰富的数据服务,打通全校数据流,盘活学校信息资产;同时积累历史数据,进一步支持深层次的挖掘、分析、辅助决策。具体统一数据库平台建设的思路应从以下几个方面着手。
(1)实现全校信息编码的统一和一致。统一数据库平台为信息标准的载体,不仅提供对信息标准的维护管理,还提供对平台数据进行标准化的手段。信息标准在数据平台中是有形的可执行体,应实现全校信息编码的统一和一致。
(2)实现任何两个异构业务系统之间的数据共享。统一数据库平台需要连通分散孤立的业务系统所形成的“信息孤岛”,无论何种系统结构、存储形式,均能整合至统一数据库平台中。即使无系统维护的电子文档数据,也可纳入平台。平台提供丰富的数据接口,实现全面的数据整合及共享。
(3)既要集成、整合现存数据,又要兼顾未来新系统建设
统一数据库平台是全校基础性平台,支持学校数据的整个生命周期。平台应包含一系列通用的API接口、数据接口,并提供简便易行的配置功能,未来新系统能够方便接入数据平台。
(4)不是简单数据存储,而要充分考虑业务关联。仅仅对数据进行存储而没有实际的业务关联是无意义的。统一数据库平台应按照学校业务主题组织数据,从业务数据逻辑出发,提供具有充分信息含义的存储及数据服务。
(5)严格基于授权管理,遵循“谁产生、谁维护”的原则
统一数据库平台在提供数据共享的同时,必须考虑数据管控,对数据的访问、使用均有严格的权限控制,采用分级授权机制,将权限的分配控制到细粒度。遵循“谁产生、谁维护”的原则,保证数据的一致性与权威性。
(6)基于全局数据视图实现数据的管理和利用。统一数据库平台以业务主题组织全校共享数据,建立全局数据视图,在管理和利用数据时均基于此视图,纲举目张。
(7)提供丰富、可定制的综合数据服务。在数据整合基础上,统一数据库平台提供多种形式的数据服务,并可自由定制,满足各种用户角色对不同数据的关注角度及粒度。
3 统一数据库平台的架构
统一数据库平台的总体架构采用分层结构设计理念,具体包括:信息服务层、数据访问服务层、公共数据库层三个层次。平台总体架构如图1 所示。在整个架构中,各层次之间在逻辑上相对独立。其中,各层次所解决的具体问题如下:
3.1 信息服务层
该层面向最终使用者,为校内用户提供个性化服务,包括应用系统(学生服务、教务服务、人事服务、科研服务、学籍服务、设备服务、办公服务、外事服务等)、对外数据服务、共享数据的统计查询及报表服务、和没有业务系统对应的共享数据管理等服务。
3.2 数据访问服务层
信息服务层的各种服务不能直接操作数据库,必须通过调用统一的数据访问模块实现对数据库中数据的操作。
3.3 公共数据库层
该层的数据是学校一切活动所涉及的、用于共享的公共数据集,来源于学校的各个业务部门,并基于“谁产生,谁维护”的原则,由对应的业务部门管理。从数据来源上分。
3.4 统一数据库平台架构的特点
统一数据库平台架构的特点可以归纳为:区别对待现存老系统和新系统。老系统需要通过数据整合器将原有的数据进行标准化后入库。新系统的数据自然共享,无需再次集成或整合;数据访问服务层保证了所有对共享数据库的访问能够受到严格的权限控制。它对共享数据的共享信息实现可视的控制;在信息服务层中提供了公共数据库中无对应系统的数据的和公共代码的管理功能。用户可以通过公共数据库平台自带的数据管理模块管理权限允许范围内的数据。
4 结束语
高校信息化建设是一项艰巨、复杂而富有挑战的系统工程,实施统一数据库平台,是高校信息化建设的基石。统一数据库平台解决了信息安全隐患、标准不统一、数据不共享、业务流程不规范等问题,消除校内信息孤岛,实现教学、科研、管理和服务的各种资源的共享,保证信息化建设的可持续性发展,促进教学、科研、管理过程及模式的全面信息化。
参考文献
[1]郭玉龙.高校信息化建设存在的问题及对策研究[J].网络安全技术与应用,2014.
[2]曹超,孔琳俊.高校信息化建设的研究与思考[J].软件,2014.
[3]詹必胜,王宏宾,韩冰.统一数据库与管理信息标准[J].中山大学学报(自然科学版),2009.
浅谈企业数据治理及其统一流程 篇7
数据治理是将数据视为一项企业资产,它涉及以企业资产的形式对数据进行优化、保护和利用的决策权利,并对组织内的人员、流程、技术和策略进行编排,以期从企业数据中获取最优的价值。从一开始,数据治理就在协调不同的、孤立的且常常冲突的策略的过程中扮演着重要角色。
类似于客户关系管理(CRM)诞生之初,组织开始任命全职或兼职数据治理负责人。典型的组织虽拥有其客户、供应商和产品相关的信息,但这些组织可能不清楚这些数据出于何处。
非结构化数据治理的一个不错示例是设置记录管理策略。许多公司都被要求将电子和纸张记录保留一段时间,遵守为特定的文档制订保留计划,从而有助于公司在使用过程中能迅速、经济、高效地查询到这些信息资料。一些组织将该保留计划称之为“信息治理”。以下是如今最重大的数据治理挑战:①不一致的数据治理可能导致业务目标与IT计划脱节;②治理策略未与结构化的需求收集和报告相链接;③未从生命周期角度解决常见的数据存储库、策略、标准和计算流程中的风险等问题;④元数据和业务术语库未用于弥合全球化企业中多个应用程序之间存在的语义区别;⑤如今很少存在能链接安全、隐私和合规的数据资产价值评估技术;⑥控件和架构在建模长期后果发生之前就已部署;⑦跨不同数据领域和组织边界的治理可能难以实现;⑧需要治理的内容常常不明确;⑨数据治理包含战略和战术元素,它们缺乏明确定义。
2 数据治理统一流程
2.1 定义业务问题
数据治理计划失败的主要原因是,它们无法识别实际的业务问题。组织急需围绕一个特定的业务问题,定义数据治理计划的初始范围。一旦数据治理计划开始解决已识别的问题,业务职能部门将给予支持并将范围扩展到更多区域。
2.2 获取高层支持
得到关键IT和业务高层对数据治理计划的支持很重要。获得此支持的最佳方式是以业务案例和“快捷区域”的形式建立价值。与任何重要的计划一样,组织需要任命数据治理的整体负责人。无论该工作分配给哪位负责人,该负责人都必须在高层评分中足够高,以确保数据治理计划能顺利进行。
2.3 执行成熟度评估
每个组织需要对其数据治理成熟度执行一项评估,最好每年执行一次。数据治理组织需要评估其当前的成熟度水平和未来成熟度水平,通常时间为12~18个月后。此时间设置条件为:该时间必须长到足够生成结果,短到确保关键利益相关者的持续支持。
2.4 创建路线图
数据治理组织需要开发一个路线图,来填补数据治理成熟度类别的当前状态与未来状态之间的空白,例如:数据治理组织可以检查“照管”的成熟度空白,确定企业需要任命数据照管人来专门负责目标主题区域,比如客户、供应商和产品。
2.5 建立组织蓝图
数据治理组织需要建立一种章程来治理其操作,确保它拥有足够的成熟度在关键形势下担当决胜者。数据治理组织最好在一种3层格式下操作。顶层是数据治理委员会,它由企业资产的关键职能和业务领导组成。中间层是数据治理工作组,它由经常会面的中层经理组成。最后一层由数据照管社区组成,它负责每天的数据质量。
2.6 创建数据字典
业务词汇的有效管理可帮助确保相同的描述性语言适用于整个组织。数据字典或业务术语库是一个存储库,包含关键词汇的定义。它用于在组织的技术和业务端之间实现一致性。一旦实现,数据字典可应用到整个组织,确保业务词汇通过元数据与技术词汇相关联,而且组织拥有单一、共同的理解。
2.7 理解数据
如今很少有应用程序是独立存在的。它们由系统和“系统的系统”组成,包含散落在企业各个角落但却已被整合或至少相互关联的应用程序和数据库。关系数据库模型实际上令情况更糟糕,它使业务实体的存储分散化,数据治理团队需要发现整个企业中关键的数据关系。数据查询时可能涉及简单但难以发现的关系,以及企业IT系统内的敏感数据。
2.8 创建元数据存储库
元数据是描述数据的数据,它是有关数据属性的信息。在查询阶段,数据治理计划将从数据字典生成大量业务元数据和大量技术元数据。此元数据需要存储在一个存储库中,保证它可以在多个项目之间共享和利用。
2.9 定义度量指标
数据治理需要拥有合理的指标来度量和跟踪进度。数据治理团队必须认识到在度量某个东西时,其性能就会改进。因此,数据治理团队必须挑选一些关键性能指标(KPI)来度量计划的持续性能,例如:一家银行评估行业的整体信贷风险,数据治理计划可以选择空的标准行业分类(SIC)代码的百分比作为KPI,跟踪风险管理信息的质量。
2.1 0 治理主数据
统一数据库 篇8
发电、输电和配电基础架构通常由公用事业公司的技术部门进行管理和操作。AMI最初由计量与客户服务部门发起并受到信息技术部门的支持,因为这些计划的初衷就是满足该部门所管理的计费和客户服务要求。但所有公用事业公司都意识到,实际的智能电网管理将需要端到端的可见性和数据访问。正是这一主要因素促使OSIsoft实时基础架构成为满足集中计量和事件数据中心(以AMI的Meter Data Unification System系统为代表)需求的理想之选。
AMI不仅仅是采集和管理计量表数据,它还改变了公用事业公司与客户业务往来的方式,也改变了围绕计量表所展开的运营活动,它实现了计量表和后台系统之间的双向通信,多方面改变了业务流程(例如,远程连接/断开连接、按需读取、远程迁入/迁出、自动防窃电检测等)。AMI必须融入重要的业务流程(例如计量表的部署、使用数据的验证和估算、计费系统及客户信息系统)中。现在,计量技术被视为一种提高能源效率的有效方式,因而可以推迟对发电和输电基础架构的投资。OSIsoft已与SAP携手合作将业务流程与计量集成融合在一起。目前,OSIsoft提供从AMI系统的前置系统(Head End System,HES)到SAP的集成解决方案。
SAP发起组建了灯塔委员会(Lighthouse Council,LHC),这是一个由公用事业公司和供应商组成的联盟,致力于定义从HES到SAP的技术集成要求。OSIsoft参与了此项包含实际案例的开发以及集成产品的测试活动。OSIsoft重心完全放在数据管理方面。OSIsoft自1980年开始从事实时和事件数据管理业务。
OSIsoft MDUS经过专门设计,可以完全融入有关执行重要任务的Web Services规范,这些任务包括计费行列式数据计算、交付部署(计量表部署)点、远程断开连接/重新连接、远程迁入/迁出以及AMI数据同步。OSIsoft和SAP合作,针对业务中的计量表部署提供最彻底、最强健的集成。这些标准产品提供了足够灵活的可持续解决方案,可以满足当前和未来的要求。
为了协助应对复杂的IT监管及业务挑战,OSIsoft计量表数据统一系统(MDUS)包含有重要的规划、部署及支持服务。
OSIsoft利用其深厚的公用事业专业技术帮助企业实现真正的智能电网功能。OSIsoft是为发电、配电和输电行业提供实时数据和事件管理系统的领先供应商。能源管理系统(Energy Management System,EMS)、配电自动化(Distribution Automation,DA)和SCADA (监控和数据采集)结合OSIsoft MDUS,可提供完整的电力价值链,这也是智能电网中最重要的要素。
1 产品组件
(1)接口(OSIsoft AMI Interface):支持多供应商前置系统,数据收集速率可轻松满足用户要求,自动发现计量表,数据验证,高度可用,无单点故障。
(2) PI Server:行业领先的实时和事件数据管理基础架构。单个服务器上的计量表数量可扩展到数百万,轻松联合多台服务器,支持世界上最大的公用事业。数据输入速率支持计量表每分钟读取一次甚至更快,可轻松满足计费要求。支持需求响应等更为复杂的应用程序,可与智能电网集成,可全面了解整个电力价值链。Slsoft MDUS可实现发电、C&I消费者、分布式发电、输电、配电以及住宅区的可见性,高度可用,无单点故障,支持高级分析,这些分析用于处理所有估算规则和其他计算。
(3) PI Data Directory:背景层;组织所有计量表数据,将计量表数据与SAP EAM计量表引用关联起来,计量表记录由PI Interface自动生成,高度可用,无单点故障。高级计算引擎工具(ACE Advanced Computing Engine) PI Server组件用于数据估算。
(4)OSIsoft Utilities Gateway:全面支持所有SAP forUtilities AMI MDUS Web Services。通过严格的SAP鉴定流程获得SAP认证,在业务计量表背景层和前端背景层之间建立连接,保证服务运营的交付和计划。
2 服务组件
(1)售前咨询和建议:系统易于扩展,OSIsoft将向您的IT团队或系统集成商建议最佳的自定义集成实践,推荐体系结构。
(2)支持:现场服务,行业领先的全天候支持,该支持与SAP的解决方案管理器支持系统相集成。
(3)企业级软件:软件许可专为适应企业而设计,包括开发、测试和部署系统等全部许可。
3 OSIsoft MDUS产品
(1)接口(OSIsoft AMI Interface):OSIsoft AMIInterface连接AMI前置系统(HES)和OSIsoft MDUS。OSIsoft AMI Interface是先进的自我维护和支持系统,它们会自动检测计量表并创建所有必需的配置记录。
这些Interface大多都是自我配置和维护的。它们与AMI前置系统(HES)通信,从而全面识别所有与HES相关联的计量表。记录是在OSIsoft MDUS的组件PI Data Directory Server中创建的。这些记录包括所有静态计量表信息,例如:计量表序列号、Ull和计量表制造商信息。同时还会创建所有数据收集配置。在OSIsoft MDUS中,这表示数据点的创建以及读取所有计量表数据的适当计划(见图1)。
通过AMI Interface可以与HES进行双向通信。当然,智能计量表耗电量数据、电力质量和事件都会读取并写入OSIsoft MDUS。同时也支持从业务到计量表的数据流。支持范围可以从计量表验证Ping到全面需求响应集成。
最重要的是,OSIsoft MDUS支持很多计量表前端供应商。由于供应商的技术原因,每个公用事业AMI的安装都可能涉及多个AMI供应商。每个公用事业AMI的部署活动都可能需要在多项竞争技术中寻求一种最佳方案。OSIsoft MDUS可为此提供全面支持。目前我们拥有很多前置系统,且我们的开发团队还将继续创建新的Interface Conductor。
Interface安装在基于Windows的一般计算机上。OSIsoft部署服务将提供有关系统规模的建议。该系统通常安装在数据中心或邻近前置系统的NOC中。Interface会与前置系统进行通信以确定当前所有的计量表配置信息。该信息将被解释并转换为OSIsoft MDUS的配置信息,并会以计量表记录的形式写入PI Data Directory Server。该信息还会用于计算计费行列式数据和其他计量表时序数据(例如PI Server中的计量表运营状况、篡改标记以及电压和频率等电力质量值)。OSIsoft PI MDUS详细信息如图2所示。
(2) PI Server:PI Server由PI Data Directory和PI Data Archive两大主要组件构成,前者充当背景数据库,而后者用于存储和管理计量表耗电量和事件数据。
(3) PI Data Archive:PI Data Archive负责存储所有周期性的计量表读数,这包括以下所有计量表数据:耗电量、电压和其他电力质量、状态和其他寄存器、篡改等标记。
所有读数都通过CIM的模型连接点标存储在PI Data Archive中,命名规则与CIM IEC 61968-9标准一致。
PI Server可以有效存储所有此类数据,且精确度极高。如有必要,即使最大的客户群也能够实现快速读取。PI Server具有高度的可扩展性,它构建在Windows Server 2008 64位多核平台之上,允许单个服务器支持数百万个计量表。联合少数几个PI Server即可支持世界上最大的公用事业。
PI Data Archive的安全性极佳。系统通过安全的开发方法构建而成。PI Data Archive与Windows Active Directory完全集成,可进行身份验证和授权。访问控制列表粒度达到了点级别,这意味着您可以授权对每个计量表或单个计量表属性进行特定访问。
PI Server具有高度可用性。我们支持多服务器集合,以确保无单点故障并通过用户和应用程序负载分配实现更进一步的扩展。
PI Server还可以将数据同时提供给数千个用户和应用程序。数据存取速率足以保证轻松地向SAP for Utilities提供数据,可以用于计费、客户门户网站或您的其他任何业务需求。数据访问通过各类技术(例如,SQL—JDBC或OLEDB、OPC、Web Services以及基于COM和.NET的高速接口、PI Data Access)实现。数据访问技术灵活多样,可驱动趋向图绘制、构建甚至分析和汇总访问等各种应用程序。
(4)数据目录(PI Data Directory):PI Data Directory是PI Server的资产和设备数据库。它可以定义资产架构,如特定计量表模型的架构。最重要的是,它旨在为每个计量表创建、存储和组织条目。由于其扩展性极佳,所以也可为其他结构创建条目。
在PI AMI Interface自动创建的技术计量表定义中,所有寄存器都根据IEC 61968-9标准进行命名。分配给计量表的唯一ID是业务计量表和技术计量表之间的映射键。
OSIsoft Utilities Gateway为业务计量表构建Data Directory结构。业务计量表的公用事业设备产品唯一ID用于映射到技术计量表的唯一ID。
(5)网关(OSIsoft Utilities Gateway):OSIsoft UtilitiesGateway由31种SAP EhP4 Web Services构成,而且还将继续更新以支持更多的SAP AMI集成功能增强包。这些服务包含了大多数与AMI集成有关的客户关系业务流程(见图3)。例如:计量表数据与前置系统同步、计费时序间隔读取、服务连接与断开连接、计量表Ping。
SA P中的业务流程将发出多个服务请求以完成业务流程。例如,完整的安装会创建计量表、创建寄存器赋值、执行POD赋值并执行寄存器的初始读取。所有这些服务请求由OSIsoft Utilities Gateway安排完成。
所有服务都以可扩展到最大公用事业的方式实施。为了确保正确实施和良好的性能,这些服务经过了严格的SAP鉴定和认证流程。OSIsoft Utilities Gateway利用了先进的软件技术,例如数据缓存、并发利用多核平台以及横向扩展策略。而且,这些服务还支持高级计划功能及其他编排方法。
集成的范围非常广泛,不仅仅是简单的数据访问服务。这些服务将通过Interface接口的全部服务完全集成到OSIsoft MDUS中。从SAP for Utilities到前置系统的直接通信实现,然后您将作为HES再将命令直接发送到智能计量表。服务连接器包中的模块包括用于实施OSIsoft MDUS中服务的业务逻辑。这些模块可完成以下业务流程:创建计量表并与前置系统同步,执行测量任务以实现寄存器同步,计划计量表计费数据收集的时序,迁入和迁出计量表读取的数据收集。
(6)可视化和门户网站支持:我们的MDUS可视化通过增加使用OSIsoft可视化产品来实现。智能计量表数据的呈现则可通过OSIsoft的各种工具而执行。这些都是基于Web的备选方案,支持Microsoft SharePoint Portal和SAP Enterprise Portal。另外还有丰富的客户端工具可供选择,可用于显示数据和制作基于Web的图形内容。借助这些工具可以显示智能计量表数据和AMI网络示意图。
(7)其他数据收集:OSIsoft向各种不同的数据收集系统提供了400多个接口。PI System提供了一种机制,可用于进行在线数据存储以及从影响智能电网的多个数据源中快速检索基于时间的数据。您可以对AMI基础架构进行扩展,与其他PI System互相连接,从而为您的公司提供智能电网的完整视图。
(8)智能电网:PI System用于发电、输电和配电;AMI可帮助实现计量表级别的可视性。通过提供整个电网的全面视图,PI System可帮助启用智能电网应用程序。
4 OSIsoft PI是AMI的基础架构
PI System在过去29年的时间里一直是值得信赖的行业标准企业实时数据和事件基础架构。PI System是发电、输电和配电等行业中的关键任务运营基础架构。这种经过验证的技术可以完美地应对AMI和智能电网的数据管理挑战。
OSIsoft MDUS是处理异构计量环境的理想系统,可作为所有计量表数据的集中位置。从一开始,OSlsoft在行业中的表现就很突出,所提供的接口技术可通过超过4 0 0个接口和计数功能将来自PI的实时数据连接到几乎所有企业系统。我们已经对接口技术进行了增强,可支持任何AMI前置系统。
OSIsoft MDUS专为在数据流量极大(在AMI运行和应用程序中很常见)的情况下运行而设计。PI System拥有经过验证的长期跟踪记录,可在输电和配电等数据流量较大的行业中可靠运行。
AMI计量表数据需求给当前处理系统的功能带来了挑战。典型的公用事业计量表需求经常超过一百万个计量表和交付点(POD)。在大型公用事业中可能会超过数百万。每个计量表都有很多数据通道,例如耗电量、电力质量和状态数据。PI System支持每秒大量读数的数据采集速率,甚至在最大型的系统上也能够轻松支持5分钟间隔的数据采集。PI System能够以每秒超过数百万个读数的速率向多个应用程序提供数据,可轻松满足计费、中断管理和需求响应等应用程序要求。
统一数据库 篇9
关键词：数据统一应用,数据中心,医院信息平台,信息标准,大数据
1 背景与目的
广州医科大学附属第二医院信息化建设自1998年开始以来, 在his信息系统建设的基础上, 各类业务应用系统逐步完善并建立起来, 医院信息化程度日益提高。借助多个系统供应商参与了医院五十多个业务系统建设, 业务信息系统主要以满足业务人员日常业务处理的信息化, 大多都是按照业务执行科室的需求建立, 更多关注于面向业务环节的实现。借助大量业务信息系统的建立实现了各个业务中信息化的逐步深入与渗透。随之而来的不断积累的海量临床、管理、运营数据, 这些数据分散在各个业务系统中, 业务系统对数据进行了部门级业务所及范围内的种种数据利用, 而如何使数据之间进行协同并发挥更大的作用成为我们需要进一步思考的问题。
信息中心在日常信息系统维护的基础上, 为各个业务部门、职能管理部门、院领导决策需求提供大量的数据统计方面的服务。随着信息化建设的逐步深入各个管理部门对业务数据的综合应用需求日益凸显。从数据应用方式到数据分析方法等方面的需求也越来越高。加之上级管理部门针对医院整体考核开展的如三级综合医院评审标准, 医院三好一满意等活动, 也对信息系统的数据综合应用能力提出了新的更高的要求。业务信息数据逐渐演变成支撑医院、科室、个人、项目成本核算要求, 医保结算要求, 新医改下的新的结算支付体系建立, 管理监控、质量控制、经营决策、临床科研等发展的重要依据。
对业务数据进行更为深入的、综合的利用。将这些数据更为密切的关联起来, 形成以病人为基本单元的医院数据中心, 并根据经营、管理、临床业务和科研等不同需要, 对这些数据进行统一的、实时的应用, 对行政、财务和临床业务起到辅助决策支持的效果, 这将是未来很长一段时间我院信息化建设任务的重点。医院信息化建设的重点将进行由业务支撑信息系统建设为主的建设模式向业务支撑与数据综合利用信息系统并重的模式转变。
2 数据综合应用面临的问题
在医院快速发展和新医改政策的要求下, 临床科室和管理科室对数据的再利用需求越来越多, 各业务科室对系统的协同操作程度也越来越高, 暴露出来的问题也越来越明显, 主要表现在:
2.1 业务信息共享不充分
各个业务子系统之间缺乏信息共享的渠道, 绝大多数的业务数据交换时仅限于满足业务协同的数据交换, 导致各个业务系统之间信息共享不充分, 有机会成为信息孤岛。而在数据综合利用的需求下, 业务信息共享往往需要实现基于业务事件相关的完整的信息数据的共享。
2.2 数据来源多样交叉
目前院内多个业务信息系统围绕患者、工作人员、科室、临床事件不断的产生个海量的临床、运营数据, 不同数据按照业务维度分布在各个业务系统的数据库中。而医院未来业务的扩展, 以及新设备、新检查产生的将会继续扩展产生新类型数据。传统方式下的业务系统对数据的分析与展示局限在单个系统的数据库系统中。而医疗流程的复杂, 使得数据的应用需求将面向多个系统多数据源。
2.3 数据综合利用度难
由于大量的业务数据存在与各个不同的业务信息系统中, 不同业务系统之间通过自然方式进行了仅限与业务协同类的数据交换, 使业务信息系统数据难以以医院整体综合应用的方式进行数据利用。各个层级的用户对数据的应用已经不仅仅局限在业务信息系统内的数据, 用户迫切的需要以患者为中心将各个相关的临床运营数据进行按照临床事件、文档逻辑相关的方式进行数据的组织与利用, 有效的数据综合组织将给用户带来更好的业务辅助。
3 医院数据统一应用平台实现架构
在医院基础业务数据采集日臻完善的基础上, 通过建设基于医院信息平台的数据统一应用平台的建设, 加强医院各业务信息系统产生数据的获取能力, 提高业务信息系统数据的可利用性, 提升医院基于数据分析的辅助决策能力, 逐步实现业务数据完整采集、数据集中统一存储、信息利用有序高效。
(1) 通过数据统一适配器与面向服务的接口方式对提升业务系统将数据进行面向临床事件数据的共享与交换能力。
基于临床事件的业务信息系统改造:现有的各个业务系统在技术实现时, 只在系统内进行了数据的记录与存储, 而平台数据交换往往对事件信息的数据利用具备一定实时性要求, 所以需要建立基于临床事件的消息交换机制将帮助业务系统实现数据的及时有效的共享与交换。
(2) 通过数据统一协调层接入多个业务域的临床业务数据, 解决数据来源的多样性的统一。
基于临床事件信息交换平台的建立:建立医院信息平台通过SOA的平台交换技术架构, 帮助业务系统之间面向业务协同的消息交换, 同时也帮助平台面向数据中心的业务数据的集中统一存储, 帮助业务系统在完成信息数据交换共享的同时, 沉淀和积累业务数据。
(3) 建立临床数据中心运营数据中心。
建立临床数据中心与运营数据中心, 将平台中交换与共享的业务数据按照以患者为中心以及以医院参与者为中心的数据统一集中存储。通过不同维度的数据组织方式, 面向数据应用主题预置一些统计与数据加工模型, 为快速的数据应用夯实基础。
(4) 数据统一应用集成可视化的数据展现。
基于平台的业务应用数据应用建立:随着事件信息交换共享平台与数据中心统一集中存储的完成。跨业务系统的高端业务应用、对院外的数据交换与共享、数据统一与集中的应用与展示将可以建立起来。结合先进的软硬件技术, 实现分析数据的动态、精确、有效的展现。这些信息将按照提供者、使用者、使用场景等多种因素进行自动的调整, 展现在电脑终端、壁挂式大屏幕、手持信息终端等各种恰当的设备上, 供不同的信息使用者使用。
4 医院数据统一应用平台技术实现方法
卫生部2010年11月发布了《基于电子病历的医院信息平台建设技术解决方案》, 我院选取了门诊实时流量监控数据展示与医院综合运营数据展示作为数据统一应用的首个切入点, 参考《基于电子病历的医院信息平台建设技术解决方案》搭建了我院数据统一应用平台的应用原型。
4.1 医院数据统一应用平台采用的开发技术
数据统一应用平台采用跨平台的J2EE技术进行实现, 服务器采用Windows Server 2008系统, 数据存储采用了开源的MySQL数据库进行运营数据的临床事件数据与运营数据监测分析统计数据的存储。数据统一适配器 (DUA) 、数据统一协调层 (DUAC) 、运营数据分析存储引擎 (DUAC2ODS) 、运营数据展现服务均采用J2EE进行开发。数据统一协调层 (DUAC) 基于消息中间件技术构建, 借助JMS、消息队列实现用于预约挂号业务的数据整合, 并保证业务数据准实时协同。为满足在分布式计算环境下企业应用对性能、安全性、稳定性等方面的要求, 基于消息中间件 (Message-Oriented Middleware, MOM) 的数据通信系统能够异步传递消息, 将彼此独立的计算机连接起来组成松耦合的系统, 并且可以有效地屏蔽异构细节对外提供统一服务。
Java消息服务 (Java Message Service, JMS) 应用程序接口是一个Java平台中关于面向消息中间件 (MOM) 的API, 用于在两个应用程序之间, 或分布式系统中发送消息, 进行异步通信。Java消息服务是一个与具体平台无关的API, 绝大多数MOM提供商都对JMS提供支持。Java消息服务的规范包括两种消息模式, 点对点和发布者/订阅者。这些操作将具有不同面向消息中间件产品的可移植性。Java消息服务支持同步和异步的消息处理, 在某些场景下, 异步消息是必要的;在其他场景下, 异步消息比同步消息操作更加便利。在本次建设中我们选用了异步的消息处理模式。而具体实现JMS的消息中间件我们选择了基于开源协议的ActiveMQ。
在终端的数据综合战展现上我们借助Adobe Flex的强大的数据展现能力打造出数据集成可视化富客户端 (RIA) , 通过Flex的实时数据刷新能力实现终端数据的实时动态展示。
4.2 数据统一适配器实现临床事件准实时获取
借助数据统一应用平台的数据统一适配器实现了门急诊挂号数据、就诊数据、处方数据、门诊交费数据、门诊药房取药数据、入院登记数据、在院病人数据、出院登记数据、出院结算数据分布在门急诊挂号系统、门诊医生工作站系统、门诊交费系统、门诊药房发药系统、入出院登记系统、出院结算系统六大系统, 九类临床事件的准实时数据向临床事件的模型转换。通过9个临床事件所对应的九个数据统一适配器完成了各个临床事件的准实时获取, 实时获取的时间延迟不超过5秒。
数据统一适配器 (DUA Data Unifier Adaptor) 采用J2EE的JDBC以及Oracle数据库的物化视图技术实现对业务数据记录变更的实时获取, 通过业务数据的变化还原临床事件的发生过程。以患者基本信息数据整合适配器为例, 通过JDBC从数据库层面将his信息系统中的患者数据读取出来, 通过患者数据标准模型封装, 按照JMS规范将标准模型封装的患者对象按照数据产生的状态发送给ActiveMQ搭建的消息队列中。
4.3 运营数据基于临床事件与运营数据分析模型的集中存储
运营数据存储库 (Operation Data Storage ODS) 是一个面向主题的、集成的、可变的、当前的细节数据集合, 用于支持医院对于即时性的、操作性的、集成的全体运行于运营信息的需求。
在医院数据统一应用平台HDUAP中, ODS是医院运营数据的统一集中存储。ODS将医院的门急诊、住院、物资供应、设备等运行数据进行时间维度、物资设备类别、消耗、业务发生、财务资金维度的统一集中存储。
本次运营数据存储库根据门诊实时流量监控数据展示与医院综合运营数据展示需求, 后台生成15分钟、小时、日为维度的不同时间密度的运营统计数据支持前端的数据展现需求。
4.4 集成可视化运营数据展现
门诊实时流量监控数据展示分别展示了我院每日门诊流量的实时变化情况。动态展示了门诊各窗口的准实时流量分布情况。
医院综合运营数据展示反映了当日医院门急诊、住院的整体运营情况, 包括门诊就诊日次、费用情况;住院入出院人次、在院数据、危重患者人数、住院结算情况等。
5 项目建设总结与讨论
借助基于医院信息平台的医院数据统一应用两个应用主题建设过程中的经验积累, 我们发现进行医院数据统一应用平台建设时需要注意三大内容。一是要做好医院数据统一应用的主题分析, 做到分层分级应用, 满足各层级的数据综合应用的需求;二是要注意应用过程中的数据一致性保障过程, 使应用数据做到有效、准确、可靠;三是要使用好海量数据以及大数据分析的信息技术。
5.1 医院数据统一应用的主题分析
通过以病人为核心的数据统一应用。使平台服务于医生、护士、临床辅助人员, 以病人病例数据为中心, 围绕临床数据、运营数据、以及临床数据所涉及的知识库辅助数据、费用分析数据, 进行概要性的数据集中展示、详细的数据分析展示、指导、预警数据的及时展示。服务于患者, 以病人病例数据为中心, 提供在院门诊和住院期间的各项自助服务, 如:检验检查报告自助查询、自助分诊、自助排队、自助导医等。通过数据集中统一应用提升服务品质。
通过以部门应用为核心的数据统一应用。使平台服务于病房、临床科室、医技科室及其他辅助科室, 以部门的数据应用需求为中心, 围绕临床事务数据、运行数据、运营数据、科研数据、服务数据以及类似个案的组病例数据, 进行概要性的数据集中展示、详细的数据分析展示、实时指导、预警数据的有效展示。
通过以全院管理为核心的数据统一应用。使平台服务于全院级的管理部门, 如医务部、医保办、护理部、经营管理办公室、财务处等职能科室。以各个全院管理部门的数据应用需求为中心, 围绕临床事务数据、临床过程数据、运营数据、科研数据、服务数据, 进行概要性的数据集中展示、详细数据的分析展示、实时指标预警数据的有效展示。
通过以决策服务为核心的数据统一应用。使平台服务于院领导等决策层, 以决策层的数据统一应用需求为中心, 围绕临床事务数据、临床该过程数据、运营数据、科研数据、服务数据进行概要性的数据集中展示、详细数据的分析展示、实时指标预警数据的有效展示。
5.2 医院数据统一应用的数据一致性保障
患者的身份识别, 各个业务系统间患者的身份识别问题将成为完成医院业务信息系统数据统一共享的主要问题, 只有正确识别出各个临床事件的参与者, 才能将业务数据进行有效的组织, 并建立相互之间的有效联系。
信息交换标准问题, 平台所需交换信息的规范化和标准化, 是保障信息有效共享的前提。当前, 医疗信息的可用标准十分有限, 如何保证所涉及的厂商遵从通行的标准和规范是一大挑战。此外, 角色、事务和流程的标准化亦不可忽视。信息的交换与共享除了要有符合标准定义的文档内容、文档格式、传输通信协议和语义外, 还需要多个角色通过有序的多个事务配合才能完成。
5.3 海量数据以及大数据分析
数据中心构建和海量数据的分析处理, 各个业务信息数据的统一集中存储后, 所有数据集中将会带来数据中心构建以及海量数据分析处理的问题, 进行数据综合利用时, 患者个案数据的分析、临床智能质控、大样本的数据特征分析等等将实实在在的摆在我们面前, 应用和利用好现有的大数据存储与应用信息技术将是数据应用的新方向。
参考文献
[1]卫生部.基于电子病历的医院信息平台建设技术解决方案.2010-10
[2]翁盛鑫, 庄严, 陈祁.基于数据整合应用的预约挂号平台设计与实现.中国数字医学2012年07卷03期
统一数据库 篇10
关键词：水务数据,统一交换,共享平台,管理平台
0 引言
近年来上海水务部门陆续开展了大量信息化建设工作,实现了与国家防总、水利部、全市水务系统、气象、海洋和海事等多个部门互联的水务专网;建成了涵盖供水,排水,水利3大行业,用于防汛抗旱指挥、水资源管理、水环境治理、水务工程管理等不同业务目标的近50余套信息系统;累积了从1998年以来超过1TB数据量的多比例尺、多时相的数字地形图和遥感影像资料。这些系统的建成,为开展“智能水网”建设提供了必备网络条件和大量数据资料。而“智能水网”的建设离不开跨单位、部门、系统的数据交换和信息共享。
结合上海水务信息化发展实际情况,运用满足水务一体化管理工作需求的多目标、任务和层次的统一数据交换与共享管理技术,设计了水务数据统一交换管理平台,支持水务数据在多源、异构的不同系统间实现数据交换、信息流转。对水务数据实现有机整合、共享共用进行了有益研究和实践。
1 问题的提出
上海水务现有各单位信息系统及数据库建设受当时信息技术限制和建设理念局限,各系统存在系统架构多样,数据库结构不同,数据格式不同等问题:各系统由于建设年代不同,存在C/S与B/S架构并存,Java,.Net与其他工业组态软件并存,各应用系统独立开发,很难有效整合;数据库同时存在SQL Server,Oracle,SyBase,DB2等多种类型;数据表设计不同、数据多源异构、技术路线差异极大,难以实行高效的数据交换及共享;各系统应用目标单一、缺乏信息共享与联动,难以满足行业管理决策的支持需求。
同时,在水务数据统一交换管理平台未建设之前,各单位信息系统及数据库之间所采用的数据交换主要是传统的“点对点交换模式”,即应用系统之间数据库直连的紧耦合交换模式。由于这种数据交换模式需要对2端系统进行源码级开发,在对原有系统稳定性产生一定影响的同时,随着交换单位需求越来越多样,其数据交换复杂度也会与日俱增,数据交换将由一对一变成一对多甚至是多对多,相应的数据交换规则和程序开发量将呈几何倍数增长,最后形成蛛网状。这种交换模式既难以开发也难以维护,改动一点,可能导致数据交换甚至业务系统的瘫痪,将很难适应水务发展需求。
因此建设1套行之有效的能够满足全市水务行业需求的水务数据统一交换管理平台,解决“信息孤岛”现象,实现水务行业内各部门之间,以及与其它行业之间的数据共享和联动,形成数据及时有效的更新机制,成为当前水务部门亟待解决的课题。
2 方案的设计
水务数据统一交换管理平台设计目的是满足市水务局层面政府决策、综合管理工作对数据集成、数据挖掘和综合业务分析应用的需求。在市水务局已完成水务数据中心框架构建的基础上,建立1个统一的数据交换平台,简化规范行业条线应用对数据交换共享和管理的操作,协调信息资源的共享共用,满足供水,排水,水利3大行业间对数据综合调用的块状应用需求,实现面向应用的数据监控,集中管理和运行维护,提供高灵活、稳定、可用和易扩展性的功能支持。
水务数据统一交换管理平台位置示意如图1所示,连接了水务数据中心和应用系统、各行业基础数据库等,主要提供数据库连接和中间层服务。水务数据交换系统通过对各行业基础数据库进行数据抽取,异构处理和数据归并等方式,将数据传输、汇聚和存储到水务数据中心,并提供相关单位之间的数据交换和共享;为水务数据中心中面向专题应用的数据仓库提供数据统一访问和交换接口,为各类应用系统提供数据支持和应用服务支持。
根据上海水务综合管理中存在静态,实时和资源目录3大类数据的情况,我们设计了能够实现统一汇聚、规范整合、规范发布的基于数据总线技术的数据交换平台。在这种模式下,所有应用系统或行业基础数据库不直接连接中心数据库进行数据交换,而是连向数据交换平台,由交换平台统一维护各个信息系统之间的接口、协调信息资源、对各个信息系统做数据交换共享。随着参与的系统增加和数据量的不断加大,其可扩展和稳定性等方面的表现就越来越突出,更能适应信息系统规模的扩大和业务工作的不断发展。
水务数据交换平台结构示意如图2所示,虚线框内所示的水务数据统一交换管理平台主要由数据交换和管理2大部分组成。
2.1 数据交换部分
主要基于数据总线技术来实现对水务数据中心的基础、实时、政务、业务和元数据类数据与各单位信息系统之间的统一数据交换。在上海水务数据交换应用中,我们基于IBM Message Broker中间件平台,根据数据更新的不同要求进行了数据交换的二次开发和定制,有针对性地设计了水务数据实时和静态交换方式,并设计了用于获取水务数据中心中存储数据的信息资源检索接口。
2.1.1 实时数据交换
主要针对由实时采集信息系统生成的数据及部分以数据记录形式存储在数据库中并及时更新的政务类数据,采用统一的数据交换中间件平台进行实时数据交换。在不改变原有系统的情况下,支持数据在多源异构的系统和数据库之间交换,实现各类水务实时数据的无缝流转,实现对实时数据的集中、发布、路由、交换与同步,将经过汇聚,整合,规范后的水务核心数据集中存储到水务数据中心,并能为将来构建其它信息系统提供数据规范接口。
2.1.2 静态数据交换
针对数据更新频率不高且以文件或图片形式(如基础数字地形图、遥感影像数据、行政许可的附件资料等)保存的基础类和部分政务类数据,通过数据总线采用统一的文件数据定期拷贝形式进行数据交换。
2.1.3 信息资源检索接口
基于XML设计,用于水务数据监控管理部分与水务数据中心、数据统一交换平台之间协调通信,实现对水务数据中心存储的数据的编目、审核、目录检索、统计分析等功能,为数据需求单位,数据管理单位及时掌握水务数据的供需需求提供了索引指南和资源目录。通过创新信息资源编目、资源公开属性审核、目录交换管理、目录检索及其统计分析,实现信息资源目录的共享。
2.2 水务数据监控与管理部分
主要用于满足不同层面水务从业人员对数据的管理和应用需求,分接入、交换和应用层3个层面进行应用设计,水务数据统一交换管理平台数据管理功能架构如图3所示。
2.2.1 接入层
主要针对市水务局各局属单位和行业管理部门的信息技术专业人员进行设计。设计能够满足信息技术专业人员对各自单位信息系统及其数据库运行维护管理需求的一系列实用便捷的功能,实现对数据库运行状态、连接情况、交换状态、异常报警等监控管理;提供交换监控、数据管理、故障报警、异常预警等应用服务,为信息技术专业人员及时掌握信息系统及其数据库运行状态提供有效、实时的监控和管理手段,减轻对系统及数据库的运维工作量,缓解人工检查信息系统及数据库状态的劳动强度。
2.2.2 交换层
主要针对市水务局信息化主管部门负责数据中心运行的专业管理人员进行设计。设计能够提供对全局供水,排水,水利3大行业相关信息系统与水务数据中心之间数据汇集、路由、订阅与发布、整合与质量管控等交换全过程的可视化监控,管理和配置等应用服务;提供无关计算机技术、简化、便捷、可视化的交换配置工具,实现随需随用、灵活调整的数据交换策略,有效降低对数据中心管理人员计算机专业技能水平的要求;此外还提供对数据交换过程中所发现的传输延时、交换中断、数据异常等情况进行在线监控和预警,一旦发现异常情况,通过短信等即时通讯手段及时告知数据中心管理人员。
2.2.3 应用层
主要面向市水务局机关和相关行业管理单位的领导和业务人员,基于面向水务专题应用的数据挖掘技术,提供能够满足各种行业管理应用和政府管理应用的数据报表、统计分析、趋势预测、评价评估等功能。该决策层面针对水务行业从业人员多而水务信息化从业人员少的特点,功能设计应实现与信息技术的无关性,力求降低水务行业从业人员运用本平台的门槛。
3 关键技术
3.1 基于消息中间件的统一数据交换技术
为了解决以往局属各单位之间网状数据交换带来的管理混乱和资源浪费,我们采用了基于消息中间件的统一数据交换技术进行数据交换,并以数据服务的形式提供了对JSON,XML和Web Service数据服务的标准接口支持,在上海水务行业中规范了同构、异构系统间进行信息共享、数据交换的方法,形成了系统之间数据交换的标准,规范并统一了数据交换中数据采集、发布、交换、路由、同步等各环节。
1)数据采集:各单位实时数据通过该平台经由数据抓取、甄别、汇聚、规范和整合等过程以统一规范的格式汇集到水务核心数据库。
2)数据发布:各单位可以根据各自需要定制所需业务数据,该平台按照数据属性、目的地、归属单位等条件,进行相关组合,并根据这些定制信息进行数据发布。
3)数据交换:通过统一消息中间件建立数据订阅和发布的单位之间的信息隧道,支持同步和异步交换2种方式,实现各单位之间多源异构数据的业务逻辑、数值转换、数据统计和规范整合,使各信息系统之间的信息能够更方便地共享和交互。
4)信息路由:水务业务流程复杂,会涉及多个单位的协同。这些流程对协同办公要求都比较高。在这些流程里,在不同环节调用不同来源的、存放在不同数据库中的数据,就需要交换系统具备信息路由功能,在具体业务流程的运行中,配合相应的1个或多个系统,在不同的环节采集、提供、处理并发布各类定制信息,实现数据的交互流转。
5)数据同步:由于数据源众多且分散布设,当某单位采集的某个信息发生变化时,相关单位都需要尽早根据这个信息更新自己数据库中的数据。数据同步可以根据不同的业务数据的实时性需求,设置同步参数,保证关键业务数据的实时性,不会让关键数据被淹没在海量的数据流中。为了减少网络故障对数据同步的影响,数据交换系统能够在网络恢复后自动恢复同步,保证数据同步的及时稳定。
3.2 基于J2EE框架的数据监控与进程管理技术
运用基于J2EE框架的跨平台开发技术,降低了对多源异构系统开发数据监控和管理模块的复杂性,实现了对XML,WCF,J S O N等标准数据接口的支持,提供了对现有系统的无缝集成。由于采用了MVC系统开发模式,把业务逻辑代码从表现层中清晰的分离出来,避免了表现层与业务逻辑层的代码混叠,实现了数据监控与管理平台功能扩充的易扩展和可持续性,简化了开发与后期维护的复杂度,拥有高性能、可靠及可扩展性的优势,能够满足未来不断增加的水务数据交换的监控和管理需求。
同时,为了减轻该平台后期运维中所需要投入的大量人力成本,我们基于J2EE框架开发了针对数据交换进程的智能管理程序。在该进程管理程序中模拟系统运维人员对数据交换关键环节的状态判断,对各种数据交换事件的状态情况进行智能研判,及时修正并恢复数据交换作业,最大限度减轻了系统运维人员在数据交换环节中的运维工作量。
4 系统功能的实现
4.1 统一数据交换与共享
基于统一消息中间件构成的数据总线,实现了市水务局及其局属单位、区县水务局、太湖局、国家防总、气象局等其他行业单位共27家单位52套应用系统与水务数据中心之间的数据交换与共享。
防汛数据交换方面实现了潮位预报、报汛水情、实时雨情、风速风向、积水监测、台风信息、闸泵工况、下立交积水、水务热线灾情、防洪工程数据、太湖水情、气象信息等数据的订阅和发布。
水资源数据交换方面实现了水资源取供用排多个环节相关的原水水厂、供水管网、供水测压点、供水水质、供水水量等数据的订阅和发布。
4.2 集中数据监管
为满足水务数据统一交换、集中数据监管的应用需要,基于B/S架构,设计了水务数据统一交换和共享管理平台,完成了交换平台、数据中心等功能模块。
在交换平台模块中,实现了对数据源端,交换端,目的端3个关键环节的数据采集、数据发布、交换效率、故障统计、数据交换情况统计、数据完整性、数据奇异性预警等功能。
数据中心模块中,实现对数据中心涉及的数据库运行状态、数据库配置、用户权限管理、数据交换节点注册等集中管理功能。
4.3 智能交换监控
为减轻数据中心管理人员的运行维护工作强度,专门设计了具有智能监控系统交换进程的守护程序,用于在线智能判断数据交换平台的运行情况,一旦发现数据交换平台中某一交换进程停止响应或出现其它问题,守护进程会采取相应措施,自动终止有问题的交换进程,并重新启动该交换进程程序,最大限度地保证相关数据交换的顺利进行。
4.4 面向应用的数据服务
以防汛、水资源应用为试点,针对防汛业务专题进行数据挖掘,实现了雨量、水位、风速风向、道路积水、水闸工况、泵站运行情况等相关数据的图表显示,单因子统计查询,多因子趋势分析等功能;针对水资源业务专题,实现了对水量日报、水质日报、水厂监测、供水泵站监测、管网监测、骨干河道水质评价、水功能区达标评价、河道综合指数评价等功能。面向水务业务应用提供了统一标准的数据服务和应用接口。
5 应用效果
水务数据交换和监控管理平台的建设,简化了市水务局与局属各单位之间、与区县水务局之间、与行业相关单位之间多源,异构的数据交换与共享;有效推动了信息资源的整合、共享、交换与应用;避免了由于规范标准不一、数据接口不一所带来的行业之间,部门之间的信息孤岛现象;辅助政府部门大大降低了信息化建设运维成本。
通过对水务数据交换和监控管理平台设计,对提炼出科学合理,行之有效的适合水务一体化管理需求的水务数据中心建设规范、水务行业基础数据库及其管理系统建设导则、水务公共信息平台运行维护规程等标准规范,具有促进的意义。
6 结语
本文提出的水务数据交换和监控管理平台的建设,在上海水务系统中探索了基于统一数据交换的数据总线模式实现资源整合和信息共享的新路子,对提升水务行业基础管理,提高各部门各单位的工作协同,提升政府公共服务水平起到很好的辅助作用。
参考文献
[1]潘大四.基于XML的异构数据库数据集成的关键技术研究[D].重庆:重庆大学,2004:1-74.
[2]曹成,舒坚,蔡轲,等.一种基于ebXML的数据交换系统架构[J].江西:江西师范大学学报(自然科学版),2007(3):316-320.
[3]徐俊杰.基于XML的数据交换模型研究[D].黑龙江:哈尔滨工程大学,2006:1-62.
[4]李冬睿.基于XML与Web Service的电子政务数据交换模型的设计与实现[D].广西:广西师范大学,2008:23-47.
[5]杨剑.基于XML的异构数据交换系统的研究与实现[D].四川:西南交通大学,2005:19-74.