基础数据平台

基础数据平台（精选十篇）

基础数据平台 篇1

近年来随着银行业的不断发展, 竞争日趋白热化。外部监管机构、银行管理层、业务部门对决策、管理信息的需求也在不断提高, 各种管理信息系统不断引入如:客户关系、绩效考核、管理会计、贷后、风险管理等。银行一方面希望通过先进的技术及管理思想提高自身的管理能力, 增强银行在市场上的竞争力, 而另一方面, 在系统的建设过程中, 内部多个业务系统之间又缺乏统一的规范和数据接口标准。因此, 在系统建设中经常需要重复建设业务数据的加载功能, 这不仅浪费了网络及存储资源, 而且会给系统造成过大的压力, 甚至产生风险。同时, 这些有针对性的数据集市很难做到面向整个银行的全面性、标准性与统一性。面对业务部门及外部监管部门各式各样的数据需求, 科技部门的数据提取工作往往会出现一团乱麻, 东拼西凑的情况。因此, 建立一套统一标准的数据平台已显得非常必要。

余姚农村合作银行是浙江省的一家区域性银行, 在浙江省农信联社实现全省核心业务系统与数据大集中后, 由省农信联社下发核心业务数据包到辖内各行社, 供行社数据分析使用。2012年, 为进一步加大对辖内农信系统行社的数据支撑, 浙江省信用联社建立了新的业务数据统一下发平台, 增加了重要的外挂系统数据源, 对下发数据结构进行了优化调整。但由于各行社的规模、管理水平参差不齐, 各行社对数据的利用程度也千差万别。我作为合作银行一名数据平台开发人员, 根据近几年的工作经验和对农村合作银行数据平台建设的了解, 从开发人员的视角提出适用中小银行统一数据平台的建设的思路, 力求建立一套全面、标准、统一的基础数据平台, 从而解决在以往的工作中所面临的诸多问题, 以供同行参考。

二、解决方案的选择

如何建设或到底建设什么样的数据平台才是真正符合小银行自身发展的数据平台, 是我们首先需要考虑的问题。明确的目标将指导我们在建设过程中正确的面对应用范围、系统架构、数据结构、开发技术、应用产品、软硬件等一系列问题。通常在明确这些需求时很多人会引入“数据仓库”这个名词, 在这之后便是很多高层次的问题, 高投入、高性能、高扩展、高冗余、面向主题模型重组、历史性等一系列的问题, 当这些问题考虑过之后你将面对的将是一个庞大的、高投入的系统, 这要求银行在这方面不单是庞大的资金投入, 同时还需要有配套的科技力量予以支撑。

一是Tear Data、IBM等都是在金融领域有着不错口碑的解决方案提供商, 国内很多软件厂商通过这些年与之在大中型银行项目中的积累对于数据仓库的解决方案也都是驾轻就熟。但通常这种概念的数据仓库却并不适用于小型银行。第一是从系统的整体资金投入出发, 通常这种系统软硬件合计动辄数百万上千万的投入让小型银行望而却步。其次是从科技投入出发, 小型银行的科技力量相对来说比较薄弱, 要想深入到数据仓库核心就必然需要有相关科技人员的深度参与, 而往往由于科技力量的不足导致系统在建设完成之后难以独立维护, 需要依赖于科技公司, 甚至被科技公司所绑架。

二是通过对国内几家大中型银行数据仓库模型的分析来看 (Tear Data或IBM解决方案) , 整个银行的数据系统构成并不单是一个数据仓库 (DW) 能够解决的。与之配套的必然有业务历史数据库系统 (Sys His) 、ODS多层次标准化后的业务数据系统等。而数据仓库建设在这些系统之上, 是将业务数据模型拆分或重组之后行成星形或雪花形的模型, 并且统计与综合业务数据之后才进入仓库。其数据仓库的建设更是着眼于若干年后, 通过Sys His+ODS+DW等多系统配合使用来完善企业整体的数据系统。如图1所示:

图1所示, 银行的整个数据系统的完善过程必定要耗费大量的人力物理投入, 小型银行在资金及人力投入上几乎不可能达到以上的程度, 很难建设一套完整的数据系统。但如果从开始就以标准的数据仓库模型架构去建设, 随着时间的推移历史数据将大大的丧失其集中的业务属性特性, 那么在以后系统的使用过程中将会非常麻烦。所以在这里我的出发点或者说目标就并不是标准的数据仓库, 而是适合小银行自身发展的基础数据平台。省去Sys His及DW部分, 而通过扩展后ODS系统 (图1中第 (2) 部分) 作为全行统一的基数数据平台。

三、数据平台建设思路

就我所看到的几家大中型银行的标准数据仓库借据方案都来自TD或IBM。从模型设计特征来看, 业务数据进入仓库后按照维度被拆分为星形或雪花状。从海量业务数据的角度出发, 这种模型设计在数据检索和响应效率上有绝对优势, 但同时也因为拆分使得原始的业务系统所下发数据的集中业务属性特征也不再存在。以往在一张数据表中存在的数据将被分拆到以事实表为主题的若干个数据表中, 从操作层面来看日后的操作效率将会大大降低。接下来我将根据自己的经验, 从系统目标和系统架构方面阐述符合小型银行特点的基础数据平台设计思路。

(一) 建设目标

区别于大中型银行, 小型银行的数据规模远远低于大中型银行。只要系统架构合理, 数据层次清晰, 数据效率和存储的问题在小型银行几乎不会存在, 我认为小型银行的系统建设重点目标要围绕着以下几点:规模全+标准化+便捷性+历史性+适当的资源投入。

1.规模全。是指系统的数据范围要涵盖各业务系统数据, 通过筛选将各业务系统中有用的数据都纳入到数据平台之中。小型银行的数据规模虽然较小, 但目前所开展的业务种类却日益丰富, 以往单纯的核心系统取数已经很难满足业务部门的需要。因此在平台建设初期就必须要考虑多业务系统并入的原则。

2.标准化。标准化要做到模型标准化、代码标准化以及开发标准化。

模型标准化:各业务系统的数据结构以及命名规范一般都不相同, 那么我们需要在数据平台内对其进行统一整改, 包括模型名称、字段名称、字段类型等, 最终所要达到的效果是在不参照数据字典的情况下能够读懂数据模型中的数据内容。

代码标准化:不同的业务系统会定义自己的代码含义, 如同样一个客户状态代码有可能在核心系统与外围业务系统中所表示的意义是不同的, 这样我们就需要定义一套标准的代码, 尽量在数据进入数据平台之后使用相同的代码。

开发标准化:开发标准化是指在开发过程中需要有一套完整并且标准的开发规范, 整个系统的建设都依照规范中定义的规则进行开发, 这样在新的人员进入后能很快的进入开发角色。

3.便捷性。便捷性是指要做到开发便捷、使用便捷、维护便捷、拓展及改造便捷。

开发便捷:最主要的是值要逻辑清晰, 等级架构层级低, 开发语言简单便捷。

使用便捷:指要求最终用户在使用系统时界面友好、操作简单、易上手。

维护便捷:通常在项目上线后能由一个后台+一个前端维护人员即可完成日常的维护工作及小量的开发工作。

拓展及改造便捷:要求能够在外部系统数据结构发生变化是只修改接口模型就能完成绝大部分的改造工作, 能便捷的向其他应用系统提供增量或全量数据以及一些基础的加工汇总数据, 如账户日均, 客户资产负债等。

4.历史性。历史性不仅要求整个系统的历史周期长, 同时还要保证历史模型对需求应用的响应效率。

5.适当的资源投入。主要指合适的资金和人力投入。整个系统的设计必须围绕资金投入去考虑, 如投入100万的软件费用就需要清晰的认识这100万 (40~50人/月) 所能够完成的工作目标。否则会对项目的既定目标产生影响。

(二) 系统架构

整体数据流向:

业务系统数据文件→到基础数据平台→各个应用系统。基础数据平台采用多层次的具有历史性的ODS系统架构思想, 在整个基础数据平台部分对上文中目标所关心的点加以实现。如下图:

1.基础模型层。如图2所示, 其中基础模型层保持与业务系统数据结构基本相同, 通常只扩展必要的业务日期及系统来源字段, 模型采用面向主题的命名规则对模型名称重新统一命名, 将各个业务系统中对应的模型划分到不同的主题下 (如账户余额、主挡、合同及签约信息、登记簿等划分到协议主题;客户相关如客户信息、地址联系信息等划分到团体主题;交易、流水相关划分到事件主题……) , 以便于以后使用。

图2中的基础模型层将所有的业务系统数据按照数据特征划分到公共、协议、团体、事件、产品、渠道、总账、其他这8大主题当中, 这种主题划分为银行业内使用较多的划分方式。各家银行也可以根据自身的需要进行相应的补充拓展。同时基础模型除数据表名称、字段名称、类型标准化外还应进行必要的代码标准化处理。代码标准化尽量以核心系统代码为主同步到其他业务系统中。以达到在不参考数据字典的前提下能够读懂大部分模型内容的效果。

2.加工模型层。加工层为整个基础数据平台的通用整合层, 合理地进行一些基础的业务汇总统计 (如账户日均、月均) 、模型整合和拆分、分户合并 (储蓄、定期存款合并) 、全行统一客户视图整合、相关交易流水整合等。完成后的加工层模型力求将常用的数据查询范围由多表向单表进行整合, 这样将极大的方便科技人员应对业务部门繁多的数据提取工作。

平台应用层为建立在平台之上的统计分析报表层。这一部分也可以独立BI应用。

3.数据交互。整个系统具有开放性, 这三个层次均可对外围应用数据及时提供数据, 出于系统整体逻辑性的考虑, 基础数据平台与外围系统的数据交互均采取落地文件交互的形式, 以避免各系统之间的依赖程度。

4.历史机制。历史性是建立基础数据平台中的关键点, 好的历史数据存储机制配合当前性能较高的服务器, 对于小型银行来说一般至少能够满足5年以上的历史数据存储。图2中基础模型层采用普通的增量数据模型保存由业务系统下发的每日增量数据, 除明细、登记簿及一些公共应用等模型以外的主挡、余额及客户相关数据采用当日模型+历史模型的形式存储, 当日模型中储存全量的最新的数据, 历史模型中保存每日增量。这样能够使正常业务处理过程中避免直接使用历史数据以保证系统的性能。加工层中尽量整合常用的数据模型后采用拉链历史存储机制进行历史数据存储。这样既能保证基础模型层与业务系统的切合度, 又能保证历史数据的使用效率。如下图:

注:拉链历史表的处理过程较为复杂, 有严格的关链开链过程, 集中使用在日常使用平率高的模型中即可。同时若数据异常重新处理的过程也比较麻烦, 建议在数据进入拉链历史表之前进行数据检核, 确保当日的数据准确性及完整性之后再入库。故上图中基础数据平台拉链历史表一般使用在模型加工层。

(三) 优势及风险

小型银行的科技信息系统正处于发展阶段, 很多银行亦在初期阶段, 我认为标准的基础数据平台的建设必须着重考虑, 无论是独立建设还是依托某一具体的系统建设都需要经过系统的分析, 其目标一定要围绕企业发展的需要开展。以上文章中所描述的设计思路的主要优势为:

1.从系统层面来吸收DW数据仓库的优点, 按主题划分数据模型, 结构清晰、业务贴合度高, 科技人员容易且比较好接受。

2.从投入成本来看因为其设计简单, 无论从资金投入还是人员投入都要比建设标准数据仓库所要投入的资源低。同时建设周期短, 能让企业很快的投入使用, 及早的完成更多管理分析系统的建设, 以体现其价值。

3.从长远使用来看其在外围业务系统发生变化之后改造成本低, 只需要改造接口基础数据层结构即可, 同时因为整个基数数据平台采用的标准化的模型设计其更能为企业打造出一套标准化后的基础数据, 为日后的DW及应用系统打下坚实的基础。

通过系统整体的实施经验来看, 在系统的建设过程中需要注意以下几点:

1.小型银行在建设企业统一数据平台的过程中切不能贪大, 在企业自身没有标准的基础数据时尽量避免业务数据模型的拆分。否则将会给日后的系统升级改造及使用埋下严重的隐患。给企业带来不必要的麻烦。

2.数据准确性的保证是整个基础数据平台至关重要的一步, 在系统建设过程中一定要有完整的数据校验机制, 如总分核对、逻辑层次间核对以及数据完整性检查等, 每日的数据批处理完成之后进行上述检查, 否则一旦出现数据丢失或完整性缺失而重新处理历史数据将会是一个漫长及痛苦的过程。

3.从系统架构上尽量降低或避免基础数据平台与其他依赖应用集市的紧密程度, 如基数数据平台所有与其他依赖的应用系统的交互都采用落地文件的形式, 这样可以保基础数据平台不受其他业务系统的影响能够按时完成业务数据处理工作。

以上内容是作者根据多年在银行数据领域所积累的经验之谈, 水平有限, 考虑问题难免有疏漏, 谨供同行参考。

名词解释

ODS:Operational Data Store, ODS具备数据仓库的部分特征, 它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。

Sys His:业务系统历史数据库。

基础数据平台 篇2

一、“数字城市”及其应用的现状分析

1、国外“数字城市”基础平台建设的现状分析

1)空间数据生产、使用的协调和管理

1994年4月13日，美国颁布了12906号总统行政令，实施国家空间数据基础设施(NationalSpatialDataInfrustructure，NSDI)计划，正式在美国政府和非政府部门中开展直接协调地理空间数据收集和管理的活动。

英国政府在认识和分析美国NSDI成功和问题的基础上，提出了国家地理空间数据框架(NGDF)发展计划。

澳大利亚联邦空间数据委员会制定了空间数据管理机构与领导机构的权利与责任、联邦公益空间数据转让等政策。

2)空间数据框架建设

美国FGDC于1995年4月提出了NDGDF实施计划，开始建立包括大地测量控制、数字正射影像、数字高程模型、交通、水文、行政单元以及公用地块地籍数据在内的.数据框架。

加拿大GeomaticsCanada负责全加拿大国家地形数据库(NTDB)，已经完成1：25万地形数据库和南部人口稠密地区的1：5万地形数据库。

欧洲大多数国家版图较小，数字地理空间数据生产基础较好。英国陆军测量局从1970年开始从事数字化制图，已正式向社会提供数字化地图。

法国地理院从1985年起建立1：5万全国地形数据库(BDTOPO)，x、y精度为2.5m，z精度为1.0m。

德国内务部原大地测量研究所(IFAG)负责完成全国1：20万DLM和1：100万DKM，各州测量局负责完成1:2.5万DLM和1:2.5万DKM，其地物精度要求为3m。

荷兰于1990年建立了地籍信息(非图形)的联网查询，有2500注册用户，完成全国地籍图数字化。

日本是亚洲地区最早开展地理信息化工作的国家。目前已能向社会提供DEM数字地图等系列产品。

3)空间数据标准建设

发达国家的地理信息管理采用国家和地方两级管理体系，在“数字城市”空间数据基础平台的建设中,通常采用自上而下的组织形式，即由中央政府组织相关机构共同推动全国范围统一数据平台的建设。政府在其中主要起到协调政策性事务、组织研究发展、统一数据标准和行业规范等作用。

2、国内“数字城市”基础平台建设的现状分析

我国“十五”计划明确提出：“大力推进国民经济和社会信息化，是覆盖现代化建设全局的战略举措。以信息化带动工业化，发挥后发优势，实现社会生产力的跨越式发展”。作为推进信息化工作的一个重要方面，党和政府的各级领导对“数字地球”给予了高度重视。

11月在首届“数字地球”国际会议上，北京市市长刘淇正式提出了启动“数字北京工程”。初，北京市信息化办公室制定了“‘数字北京’

基础数据平台 篇3

编者按：近年来，在国家的大力支持和推动下，我国的教育管理信息化建设取得了较大进展，教育管理信息化标准体系基本形成， 国家和省级教育数据中心建设稳步推进，各级教育部门的管理信息系统已经开始发挥作用，教育管理水平有了显著提高。在此过程中，教育管理信息系统建设的相关工作者积累了丰富的经验，本刊特组织专题对相关经验进行研究与推广。

摘 要：尽管浙江较早建成了同城互备的省级教育数据中心并承载了电子学籍、成长记录、普高选课、教师培训等省级自建应用及国家系统的运行，支撑了全省教育管理信息化工作，但随着信息化应用的深入也逐步暴露出一些问题。为此，作者所在单位通过建设区域性教育管理公共服务平台和基础数据库，制订信息标准，构建教育基础数据库，建立数据交换、身份认证、信息门户等一系列措施，实现了业务与数据的统一，逐步解决教育信息化过程中“数据共享”、“信息孤岛”等难题。

关键词：数据中心；教育管理；公共服务；基础数据库

中图分类号：G462 文献标志码：A 文章编号：1673-8454（2016）07-0018-03

一、背景

浙江省较早建成了同城互备的省级教育数据中心，逐步建立并完善了电子学籍、成长记录、普高选课、教师培训、装备管理、教育监管等省级信息系统。根据教育部《省级数据中心建设指南》、《国家教育管理信息系统建设总体方案》等精神，从2013-2015年，浙江省对省级数据中心进行了全面完善，承载了国家统一规划部署的校舍管理、学前管理、中职管理、学生资助等系统，有效落实了教育部“两级建设、五级应用”[1]的目标，教育管理信息化已应用到教育管理各个方面。随着应用的深入，也逐步暴露出了一些问题，主要表现在未建立有效的数据共享交换机制，基础数据重复采集，形成了大量的“信息孤岛”；未建立统一用户管理及认证平台，各级用户需登录不同平台操作各类业务，跨部门、跨层级、跨应用的业务协同无法有效进行等。

二、建设目标

基于当前状况，结合国家“十二五”教育信息化提出的建设教育管理公共服务平台，建立覆盖全国各级教育行政部门和各级各类学校的管理信息系统及基础数据库[2]。及浙江省教育信息化“十二五”提出的加强数据统计分析、综合利用和数据共享，为教育管理和宏观决策提供准确的数据支持，推进教育管理和服务的信息化，提高教育管理效率，提升教育管理公共服务能力[3]等目标，我省于2015年启动了浙江省教育管理公共服务平台及基础数据库建设，拟通过省级统筹，逐步实现以下内容：

（1）建立统一的数据采集、交换与共享的标准规范体系，形成权威数据来源，加强数据的准确性。

（2）建立统一的基础数据库，解决各业务系统间数据离散，避免基础数据重复采集，提高数据的利用率。

（3）建立统一的用户管理及认证平台，确保各类系统用户的安全和统一。

（4）建立统一信息门户，实现“一次登录，多点漫游”，提升用户体验，保障跨部门、跨层级、跨应用的业务协同。

三、建设过程管理

为做好浙江教育管理公共服务平台及基础数据库建设，本项目建设过程中充分了运用项目管理的思想，采用PDCA方法，有效地规范了整个项目的建设过程。

1.落实建设经费，统筹规划项目方案

根据前期调研结果，参照《浙江省教育信息化工程建设实施办法》，最终落实一期项目经费260万；组织制订了项目建设方案，并由教育部教育管理信息中心、省发改委、省建设厅及部分高校组成的专家组论证通过，该项目于2015年初完成政府采购并启动实施。

2.组建项目团队，做好与相关部门对接

在项目启动后，组建了由用户单位、承建单位、监理单位及安全服务机构相关人员组成的项目组，明确项目负责人并组织项目组成员分赴教育部教育管理信息中心、省政府办公厅做好与上级主管部门的业务对接；同时利用远程协作技术将杭州、宁波、绍兴、金华等教育局及部分学校用户纳入项目组，以强化对需求的准确把握并提高用户的体验。

3.纳入年度重点，加强日常检查监督

2015年初，省教育厅将该项工作纳入2015年度重点工作，由省教育技术中心组建督查组每月对项目实施情况开展重点督查，并在每月部室例会上反馈督查结果；同时还委托了专业的监理单位对项目实施全过程进行监管。

4.定期沟通协调，解决实施中存在的问题

从项目启动之初就明确了项目例会制度，项目前期每两周召开一次例会，后期缩短至每周召开一次例会，定期通报上一阶段工作执行情况并明确下阶段工作任务，有效保证了项目的范围、进度和质量。

四、当前主要成果

浙江教育管理公共服务平台及基础数据库建设当前主要成果包括：

1.建立数据标准和管理办法

在国家、行业相关标准基础上，结合我省特色，建立了包含基础代码指标设计规范、基础数据指标设计规范、门户集成开发规范、数据共享技术规范、统一监控规范、统一用户认证规范、业务环境运行指南等在内的浙江省教育数据中心信息标准规范体系，制订了《浙江省教育数据暂行管理办法》，完成了意见征求并即将正式发布。

2.建立基础数据库及管理服务平台

通过建立“U/C矩阵”，明确权威数据的生产者和使用者，并对各业务系统已有数据的全面清洗、转换及导入，建立了覆盖我省幼儿园、小学、初中、普通高中、中等职业学校、高等院校6个教育阶段的学校、教职工、学生等18个教育基础信息数据库及教育事业统计、选课过程管理等主题数据库，建立了集元数据管理、主数据管理、数据质量管理、数据服务，数据监控于一体的管理服务平台（如图1所示）。截至2015年12月底，已累计完成全省8230027名学生、483269名教职工、15569个机构数据清洗入库工作，基于入库数据开发各类统计分析报表（如图2所示）。

3.建立统一的数据共享交换体系

依托第三方数据交换中间件，秉承一体化的设计理念，按照统一的业务标准和技术规范，建立统一的数据交换平台，以标准化体系、运营维护体系、安全体系作为支撑，构建现代化公共教育数据框架体系[4]，逐步实现省级教育数据中心各业务系统间，省级与地方间，省级与平行单位间的数据共享。从2015年上半年开始，已逐步完成教师培训、电子学籍、学生资助、普高综合素质、普高选课、网络选修课等省级系统间的数据共享， 2015年9月底完成与宁波市的数据共享，有效支持了地方开展教育信息化特色应用，当前省级正在配合杭州市开展区域数据共享交换工作，此外，根据省政府要求还实现了与省人口库的数据共享。

4.建立统一的用户管理体系

本次建立了以目录服务和认证服务为基础的统一用户管理、授权管理和身份认证体系（如图3所示），将省级教育数据中心承载的各类业务系统组织信息、用户信息统一存储，进行分级授权和集中身份认证，规范应用系统的用户认证方式，提高应用系统的安全性和用户使用的方便性，并逐步实现各类应用系统的单点登录。目前已接入包括电子学籍、教师培训、学前管理、普高选课、普高综合素质评价、高校教师专业发展、教育技术支持服务、教育统计、协同办公、信息管理、邮件系统等十多个业务系统。

5.建立统一信息门户

在统一身份认证的基础上，整合现有各类业务系统，通过统一信息门户平台，把各个业务系统的信息服务按不同教育阶段有效分类，并参照Windows Merto设计风格为各类用户提供统一的信息服务入口（如图4所示），可以同时集成来自各业务系统、统计分析窗口及数据，实现在统一界面的业务协同，当前个人信息门户包括个人桌面、应用中心、数据服务、便民服务等一级菜单，而在个人桌面下包括个人信息、通知公告、待办事宜、个人邮箱、常用服务、个人应用等功能区（如图5所示）。

6.融入互联网的特色元素

为方便各类用户操作使用，参照当前互联网应用的主流登录模式支持通过短信快捷登录，并基于Portal实现用户对界面风格的个性化调整；为提高展示效果，系统首页及个人信息门户还支持在不同分辨率下的自适应显示。

7.同步开展了安全保障体系的建设

平台建设过程中，安全服务商全程参与指导，并集成了国家统一部署的应用安全监管和预警平台，实现对应用及服务的安全监控（如图6所示）；首次将等级保护工作纳入平台建设范围，将开展定级备案、测评整改作为项目验收的依据，当前已完成对该平台的定级备案和测评工作，拟抓紧开展整改工作。

五、存在问题及展望

通过建设浙江省教育管理公共服务平台及基础数据库，有效地规范了我省的教育管理信息化工作，对于贯彻落中央“教育信息化带动教育现代化”的战略精神，响应“教育治理体系和能力现代化”、“全面依法治教”的改革要求，意义重大[5]，但是由于项目建设周期较短且部分国家系统（特别如教职工系统）尚未部署应用，尚存在部分权威数据来源不准确、统计分析不全面等问题，下一阶段将在巩固并完善当前成果的同时重点做好以下工作。

1.开展大数据分析利用

继续深化教育基础数据库的建设与应用，形成多源、多维的大数据集，联合科研机构和高校开展对教育大数据的分析、研究与成果共享，为教育改革发展提供服务。

2.建设教育管理创新支持服务平台

建成集线上采购、线上部署、线上评价的一站式教育管理创新支持服务平台，提供数据共享接口和应用开发接口，建立教育管理应用商店。

3.建立移动版应用门户

基于当前PC版统一信息门户功能的基础上开发移动版应用门户，支持iOS 、Android等不同平台，方便各类用户的操作使用

参考文献：

[1]教育部.国家教育管理公共服务平台省级数据中心建设指南[Z].2013.

[2]教育部.国家教育管理信息系统建设总体方案[Z].2013.

[3]浙江省教育厅.浙江省教育信息化“十二五”发展规划[Z].2012.

[4]谢晓，刘月婕，李玉顺，胡景芳.基于CIF规范的教育数据交换平台建设实践[J].中国电化教育，2012（12）.

[5]教育部.国家教育管理公共服务平台“十三五”规划（征求意见稿）[Z].2015.

数据中心应用系统开发基础平台研究 篇4

(一) 技术架构不统一

随着人民银行重庆营管部各业务处室系统开发需求增多, 近年来科技部门开发的系统数量和规模不断增加。由于开发人员有限, 各系统均为单人独自开发完成, 未能采用统一的技术标准, 导致系统维护难度加大。

(二) 软件复用性不高

由于技术架构和开发平台不同, 大部分的开发内容均涉及各个基础性模块, 包括用户认证、权限分配、数据库访问等, 重复编码量大, 代码复用率不高, 系统开发率低, 特别在一些中小型系统开发中, 在上述基础功能开发上耗时甚至比其业务功能开发的时间还长。

二、成功搭建基础开发平台

(一) 遵循规范, 搭建平台

根据人民银行总行软件开发规范, 人行重庆营管部确定以J2EE架构为基础的开发路线, 并在遵循规范的原则上初步搭建完成通用的应用系统开发基础平台 (以下简称“基础平台”) , 为系统开发奠定了基础工作, 如图1所示。

(二) 整合框架, 完善功能

开发基础平台以组件技术为支撑, 整合了Spring, Struts2, ibatis, ext JS, dwr等应用框架, 涵盖了应用系统开发所涉及的大多数技术范畴。对用户认证、权限管理、数据库访问、静态页面布局、动态数据展示等基础功能进行进一步封装和抽象, 提供一个可高度重用的应用框架。通过该平台, 开发人员能够立即开展核心业务流程的编写, 缩短了开发工期, 保证了开发质量。

(三) 降低耦合, 方便扩展

开发基础平台是一个轻量级的J2EE集成框架, 通过控制反转和依赖注入的设计模式, 将程序的控制权从对象转移到外部容器中, 组件之间的依赖关系由容器在运行期决定, 这样就极大地提高了组件的复用性, 解决了计算机程序的耦合问题。

三、开发基础平台实践成果

(一) 统一框架、降低成本

基础平台的运用既提高了内部开发系统的标准化程度, 降低了系统整合的难度, 还为建设具有地方特色的省级数据中心提供了有力的工具。同时, 在基础平台的统一架构下, 开发人员遵循统一开发标准, 应用程序功能、界面风格一致, 用户体验反映良好。从应用程序开发效率来看, 自2009年搭建基础平台以来, 基础平台在系统开发效率提升方面作用愈加明显。

(二) 强化标准, 提升复用

在总行软件开发规范的统一指导下, 重庆营管部采用基础平台应用框架, 实现了多个应用系统的开发工作。主要项目成果包括会计核算数据分析监测系统、反洗钱风险名单管理系统、账户非现场监管数据处理系统、人事基本信息管理系统。

(三) 锻炼队伍, 推进整合

基础教育平台培训心得 篇5

本学期我有幸参加了学校组织的“基础教育资源公共服务平台”培训。在本次培训中，着重在于基础教育资源公共服务平台的使用，在培训教师悉心的教育和指导下，我们从基础开始，不断深入，逐渐了解并完成了基础教育资源公共服务平台的相关知识的学习。

基础教育资源公共服务平台的建立是对一线教师的教学活动的大力支持，对于教师的备课，讲课，教案，资源搜集等都有非常大的意义，简单易懂的操作方式，丰富多样的教学资源等，对于我们都有莫大的意义。

在培训内容方面，首先是基础教育资源公共服务平台的使用方式，从登陆平台，完善个人资料等开始，一步步由培训师引导完成，在讲解结束后，培训师给各位参加培训的教师自主使用的时间，也是为教师的理解和上手操作提供了机会。在开通平台的个人空间后，培训师再次为大家讲解了如何使用平台，并着重强调了“我的备课本”“我的网盘”的使用方式，同时介绍了“资源中心”中资源的使用，平台同时为教师们提供了各种资源“保存到我的文档”“下载”“分享”这三种方式以备各位教师的不同使用用途，而网“网络调研”“网上评课”等活动更是贴近教师的日常教学工作，同时我们可以在自己的空间中搜索其他教师的空间并关注，为与别的教师及时进行沟通和教学交流提供了机会。在之后的培训中，培训师着重强调了应用中心中的“教师助手”软件，该软件是集备课，上课为一体的极其方便的软件，在该软件中我们可以下载与本人课程相关的一系列课本，在电脑上就可以浏览课本内容，同时，该软件能支持教师在电子课本内容中添加相关资源，如图片，文档，音频，视频和课件等，能够为教师在教学中提供非常方便的作用。而在本软件中另一个亮点就是课件制作，这是一个非常有趣且简便的课件制作软件，教师可以根据自己的教学内容自主设计多种多样的课件形式，十分便捷。

经过一下午的培训，我们收获颇丰，基础教育资源公共服务平台是一项服务于一线教师的非常重要的举措，也是为了让教师的教学工作更加便捷简单而成立的非常有意义的工作，我们会好好利用该平台，为学生服务，为学校服务，更为社会服务，争取做更好的人民教师！

沙柳河镇民族寄宿制完小 2014-2015学年第二学期

实 验 教 学 开 展 情 况 统 计 表

沙柳河镇民族寄宿制完小 2014-2015学年第二学期

实 验 用 品 耗 损 记 录 表

沙柳河镇民族寄宿制完小 2014-2015学年第二学期

云基础架构平台 篇6

然而，数据中心虚拟化涵盖的范围很宽泛，包括服务器、网络、存储、应用、数据等多个技术层面。ESG认为，VMware vSphere 5所支撑的VMware智能虚拟架构，为云计算提供了一个能实现技术堆叠、透明管理的高度虚拟化的平台。

VMware vsphere 5具有的以下特性，为云计算提供了可动态扩展、安全高可用、策略驱动的、自动按特征配置资源、具有高效虚拟机保护机制且灵活的虚拟化平台。

扩展性和性能：VMware vSphere5使VMware的客户能够更轻松地实现100％的虚拟化。VMware vSphere5能够最多支持1TB内存和32个虚拟CPU。这使得其更适用于层1应用，如Microsoft Exchange和SQL服务器、Oracle 11g数据库和SAP。这种“超级虚拟机”支持对资源具有严苛要求的应用，也支持网络吞吐率超过350K IOPS的应用。并且，VMware vSphere 5还支持精简的架构(144 MB vs.2 GB)，这不仅提高了容量利用率，也简化了应用的部署和配置。

高可用性和灾难恢复：对于层1应用而言，能够确保计划内和计划外停机的安全性至关重要。VMware vSphere5采用新的高可用性(HA)架构，能够简化集群的安装和配置，实现更为卓越的监测、可靠性和可扩展性。同时新增的Site Recovery Manager 5.0能够为数据保护和数据迁移提供自动化复制和故障回复功能，以及为小型企业设计的新款vSphere存储应用，能够有效发挥vSphere HA和vMotion的效益。

智能策略管理：VMware vSphere5基于策略的管理能力能够有效提高安装、配置和持续管理的效率。VMwarevSphere 5的三个新自动化增强功能可提供云敏捷性，以帮助IT部门更迅速地响应业务需求，同时降低运营成本。这些功能所提供的智能策略管理包括：属性驱动存储和Storage DRS特性，在性能层上增添了策略管理和自动化的存储资源负载均衡；在SLA上捕捉虚拟机的存储要求，然后映射到存储层并进行分配，以加快存储规划和配置，并提升资源利用率；vSphere自动部署使IT管理员可以界定图像和主机属性，然后将它们部署到每个vSphere主机的活动内存上，实现即时的主机部署以及补丁管理。

资源的弹性：建立在扩展的资源池之上的云，可以实现有效的资源利用率和快速配置。vCloud Director 1.5(能够实现私有云的自我配置)增加了链接克隆功能，这样从模板就能够对新的虚拟机进行分配，而无需复制整个图像。此举加快了配置的时间并减少了存储资源的消耗和成本。

灵活的混合云管理：VMwarevSphere和vCloud除了能够帮助客户搭建私有云之外，公有云的服务提供商也能使用该技术。因此，应用能够在私有云和公有云之间进行迁移。VMwarevSphere 5增加了混合云管理，web浏览者和iPad用户都能够从任意浏览器进行vSphere管理。

针对云的统一的安全性策略架构：在vCenter管理架构下，vShield 5.0为主机、网络、应用、数据和终端提供了全面的安全性服务。

基础数据平台 篇7

教育基础数据是学校各类业务系统的核心, 是学校精确管理与重大决策的依据, 是数字化校园或智慧校园应用的基础, 是向公众提供教育公共服务的重要支撑。基于教育基础数据, 可以为每个学生建立个人成长档案, 可以建立基于实名制的学习空间与网络交流平台, 可以实现网络协同教研与自主学习, 可以为校园一卡通、学生综合评价、图书管理等校园核心应用提供标准化接口, 教育基础数据是学校提供优质管理、教学与服务的保障[4]。建设并完善教育基础数据, 一方面可优化管理, 为教育决策预测提供依据, 另一方面可实现精确的教育管理并推广优质的教育公共服务。

随着教育信息化应用的逐步发展, 教育信息化数据日益积累, 基础数据的建设与应用越来越得到各级教育部门的重视。目前在学校的信息化应用中, 基础数据的应用现状是什么?应用需求是什么?面临什么样的问题?怎样有效地开展基础数据的建设与应用?笔者结合在深圳教育基础数据的应用实际与建设需求, 结合云技术的应用, 就云计算环境下的基础数据的组成、基础数据的存储管理、基础数据的采集与整合、基础数据的交换与应用等方面作一些探讨。

1 教育基础数据的主要组成

教育基础数据包括学校、学生、教师和资产等信息。教育基础数据的覆盖范围囊括公办学校、民办学校、职业学校、幼儿园、高等院校等各级各类教育机构。教育基础数据主要涉及的核心业务为学生学籍管理、教师人事管理、学校资产管理等业务系统。

教育基础数据主要包含以下内容[11]:

1) 学校数据

包括学校的基本信息、班级数、学生人数、班级情况、领导班子、中层干部、教职工、专任教师、校园情况、校产情况、教学行政生活用房、学年经费收支情况等信息集。

2) 学生数据

包括学生的基本信息、学籍信息、入学信息、免费核验信息、异动情况、毕业去向、升学成绩、奖励、处分等信息集。

3) 教职工数据

包括教职工的基本信息、职位/工资、变动情况、任职情况、简历、学历学位、行政管理、党派职务、岗位证书、专业技术职务、任课、教学工作量等信息集。

4) 学校资产数据

包括学校的信息化建设、信息化装备、学校藏书、阅览室、教学仪器、体卫艺设备设施、劳动课设备配备、办公设备配备等信息集。

2 教育基础数据的应用现状

笔者收集了深圳市基础数据应用的一些情况, 目前深圳共有10个行政管理区, 截止2012年底, 共有各级各类学校约1800多所 (含民办学校与幼儿园) , 有150多万学生与10多万专职教师。

目前深圳基础数据的应用现状是:各学校已通过多年的信息化应用, 逐步积累了一些基础数据, 数据大部分是分散存储在不同的业务系统数据库中, 部分以纸质表格或EXCEL电子表格的形式进行存储, 目前还不能在数据整合的基础上开展数据的公共应用服务。存在的问题主要表现在以下三方面:

1) 基础数据采集没有与生产数据的业务系统实时对接, 学校的数据采集工作存在难度。目前基础数据采取每年两次的填报或修改工作, 数据不能与生产基础数据的业务系统进行同步对接。大部分学校的采集工作采用了数据转换方法, 即从在用的业务系统中将数据转换成相应的EXCEL表, 再将EXCEL表导入相应的基础数据管理系统, 在数据转换的过程中, 大多数学校不具备具有专业技术的数据转换工作者。

2) 生产基础数据的业务系统为数据孤岛且应用覆盖范围不全, 全市的基础数据还没有在整合的基础上提供管理应用服务。大多数公办学校, 有针对基础数据的专用业务系统, 并设专人维护。大多数民办学校、学前教育机构或职业教育机构, 信息化应用能力薄弱, 没有开展专门的业务应用, 也没有设专人对基础数据进行维护。学校基础数据分散存放在不同的业务系统中, 校方没有技术力量进行整合, 数据的跨系统应用与决策支撑服务难以实现。

3) 数据存储量逐年增长, 数据集成应用需求提升[3]。目前基础数据存储信息量快速增长, 仅以保存最基本的文本信息 (诸如姓名、家庭情况、政治面貌、获奖情况等) 以及照片信息 (学籍档案照片、毕业照、工作证照片等) 为例, 普通学校一年的数据量就将超过3 GB, 如图1所示。在市级规模, 按深圳目前约1800多所公民办学校计, 这个数字则将达到数10 TB, 如图2所示。在可预见的将来, 学生的课堂学习情况、科技活动成果、各科成绩、体检结果, 教师教学视频剪辑等信息, 都可能进入教育基础数据的处理范畴, 为数据容量带来几何级数的增长。

3 教育基础数据应用的总体需求

对基础数据实施简化而准确采集, 是基础数据应用的基础;对分散分布存放的基础数据实施安全实效的整合, 是基础数据应用的核心;提高基础数据的集成应用能力与决策分析支撑能力, 是基础数据应用的保障。

4 教育基础数据应用的设计原则

1) 加强数据规范, 统一规划, 全面实施[6]

按照统一规划、统一预算、统一标准、统一目录体系、统一元数据、集中建设、共享应用、防止重复建设的原则, 做好基础数据应用的顶层设计, 确保数据应用范围全覆盖。

2) 建立数据共享机制与存储管理机制, 实行分级管理与维护[5]

现有的行政管理体制、部门数据信息的条块分割, 造成数据共享应用的行政阻力大于技术阻力。基础数据的采集、共享、应用、维护都需要相适应的行政体制来保障, 需结合当地的财政投入与行政管理模式, 统一规划, 分级管理, 共享应用。教育基础数据以统一的数据交换平台实施整合。存储管理体系采取集中分布相结合的模式。没有开展基础数据建设的区域可在市级平台上开展分级应用, 已开展基础数据建设的单位保留原有应用与本地存储模式, 采取与市级平台同步备份与数据交换的方式开展共享应用。

3) 理清数据生产、审核与应用流程, 保障数据真实可用[4]

数据生产、审核、应用的流程是数据真实可用的基础保障。明确基础数据的来源与使用流程, 明确数据的生产部门、审核部门与应用部门, 把好数据的审核关。实施基础数据平台与数据产生的业务系统实时对接, 真正做到数据源于核心业务, 服务于教育管理。

4) 建立数据安全服务体系, 确保数据安全应用

安全服务体系包括统一的数据目录体系、统一的用户身份认证体系、完善的数据备份与灾难恢复制度、透明的资源服务体系、数据安全应用责任机制等[5]。基础数据的安全管理需与业务的行政管理相配套, 明确安全管理责任机制, 建立完善的用户权限机制, 从数据生产、存储与应用各环节确保数据安全。

5) 充分应用云技术, 提高基础数据的应用服务效益[1]

建立教育管理公共云服务平台, 在数据整合的基础上扩大基础数据的应用覆盖范围。通过云存储、云安全、云服务等的应用, 建立集中与分布为一体的基础数据云, 逐步完善基础数据的用户管理体系, 广泛服务云覆盖下的教育机构与社会公众。

5 教育基础数据的应用逻辑设计

基础数据具体有几种采集来源?基础数据提供什么应用服务?基础数据的采集与服务应用逻辑, 如图3所示。

1) 基础数据应用采取统一规划、统一开展应用服务、分级安全管理的应用模式。通过云计算模式为各区各校统一提供基础数据云服务[2]。

2) 基础数据的云服务包括:数据上报、数据统计分析、数据查询修改、数据采集录入、数据转换应用、数据业务支撑、数据决策支撑等。

3) 基础数据的采集应按照实际应用情况, 设计数据的采集方式与采集接口。

4) 基础数据的采集方式有三种:

(1) 源自于业务系统, 通过各类业务系统的接口适配器, 完成与数据生产的业务系统的实时同步对接。

(2) 源自于批量填报, 通过文本适配器, 完成与批量录入的Excel、XML文档与OCR文档的转换对接。

(3) 源自于少量手工填报, 通过采集录入云服务, 对基础数据进行单独、个别录入与修改。

5) 采集的数据需审核后, 再进入基础数据库, 以便在准确的数据基础上提供正确的应用。基础数据的审核流程为:学校审核后报区一级教育管理部门, 区一级教育管理部门审核后汇总到市一级教育管理部门。

6 教育基础数据的存储管理设计

在教育云环境下, 基础数据的存储采取集中与分布相结合的方式[5], 使用“分级存储、分级管理、安全自负、共享应用”的管理办法, 按照“平台建设单位负责数据存储安全, 数据生产单位负责数据采集安全, 数据应用单位负责数据应用安全”的原则开展应用。

市与区的存储管理逻辑如图4所示。

1) 为结合现有建设现状、建设投入模式与行政管理模式, 充分调动各区各校的基础数据建设积极性与责任心, 基础数据的存储采取分布与集中相结合的模式。

2) 基础数据在市级统一集中存储并统一集中提供应用。市级统一存储, 为全市各区设置数据逻辑存储分区, 见图4的市级云存储。区级单位实施基础数据的自主管理并负安全责任。互为同步的数据备份也增强了数据安全应用保障。

3) 已开展基础数据应用的区级单位采取本地存储管理, 与市级云存储中的逻辑分区建立实时交换与备份。

4) 没有开展基础数据应用的区级单位直接在教育云中开展区级子云的存储与应用。区级子云中的基础数据与市级云存储中的逻辑分区实时对接。

5) 数据的产生、审核、维护与应用流程, 与实际的行政管理级别相吻合。

7 教育基础数据的数据流程设计

要确保基础数据的有效应用, 核心在于:在数据的生产、交换、整合到应用的过程中, 明确各个环节的管理责任与操作权限, 确保数据生产准确性、整合有效性、审核可行性与应用实效性。

图5为通过调研, 结合实际应用与管理, 总结的基础数据的数据流程逻辑图。

1) 数据的采集 (①、④、⑤分别为三条数据生产渠道)

①、②、③为文本数据的采集渠道, ①为文本数据的复制与传输;②是文本数据批量或单次复制在传输完成后, 通过一信号文件触发文件处理与数据转换的过程;③是文本数据通过文本适配器, 与数据交换平台对接。

④为核心业务系统的数据直连渠道, 核心业务系统包括学校、学生、教师和学校资产数据的业务管理系统, 业务系统中的有效数据通过直连的方式进入基础数据库, 业务系统中的待审核数据通过直连的方式连接数据交换平台。

⑤为在教育云中开展的采集与查询修改应用, 这部分数据直接接入交换平台, 通过审核后进行整合并提供服务。

2) 数据的交换与整合

各类数据源的数据通过交换后集中整合到待审核数据库, 数据审核后提供应用与服务。

⑥数据的交换、调度与稽核。交换平台与各类数据源相连, 与各数据分布存储地相连, 实现同步交换、同步实时备份或异步触发交换备份, 交换的数据类型包括结构化数据、非结构化数据与半结构化数据。

3) 数据的审核

数据的审核由各数据的行政管理部门进行, 可分为市、区、校三级。

⑦为没通过审核的数据, 可生成统计报表, 进行数据的追溯与稽核。

⑧为通过审核的基础数据, 直接进入正式的基础数据库提供数据的应用与服务。

4) 数据的应用与服务

基础数据有三大类应用, 一是用于业务管理, 二是用于决策支持, 三是用于数据上报与查询服务。

⑨为基础数据的公共云服务, 为具备应用权限的各级各类教育管理用户或社会公众提供数据查询统计、数据提供或数据上报服务。

⑩为基础数据对教育管理业务系统的支撑, 基础数据库中的数据可为教育公共管理系统、各校园信息化管理系统等直接提供数据支撑。

11 为基础数据对各级各类教育机构的决策预测系统的支撑服务。

8 教育基础数据的集成应用设计

随着基础数据的积累与发展, 处理的数据类型将包含结构化、非结构化与半结构化数据, 而处理的数据容量将超过10TB, 向PB级发展, 处理数据的类型、数量与速度越来越趋向应用“大数据”处理技术。为满足教育基础数据可持续的发展需要, 在明确基础数据真实、安全、可用的基础上, 如何高效地实现数据集成应用, 包括数据的抽取、转换、整合、装载到基础数据平台进行再应用, 是基础数据应用平台的核心技术[9]。

教育基础数据的集成应用设计, 主要从数据架构、存储管理、集成性能、智能应用等方面考虑。在前述基础数据采集与应用的应用逻辑、存储管理与数据流程设计、基础数据采集的三种来源与三类应用服务的基础之上, 我们须进一步考虑如何利用集成平台有限的处理能力解决这一架构中数据量大、数据格式多样、传输方式多样的问题, 使基础数据系统具有较好的灵活性与可扩展性。同时, 我们还必须满足数据在实时交换、整合的过程中一定的实时性要求。为了应对这些挑战, 我们提出利用SOA、ESB、ETL与BI技术[9]搭建松耦合的系统架构, 设计了如下的集成应用平台框架, 如图6所示。

1) 实现市区两级的分级存储、分级管理与同步共享

各区基础数据与市级基础数据, 通过ESB服务总线实现数据的异步传输、同步传输与实时备份, 通过主数据管理 (MDM) 实现同一标识数据的唯一性与同步性, 确保实施按区管理、全市统一调度的存储管理策略。

2) 确保来自多种采集渠道的基础数据的整合

Camel Route这一ESB工具, 支持各种方式的系统接入, 可实现传输协议的转换、传输路由的选择与传输流程的设定, 支持目前在用的多种传输协议, 能汇总各种采集渠道的基础数据, 包括业务管理系统中的基础数据 (JDBC) 、存储在电子文档中的基础数据 (File) 、扫描纸质件中的基础数据 (OCR) 、网上采集填报的基础数据 (web service) 。

3) 通过ESB传输总线实施安全与高效的数据交换与整合

在基础数据整合平台中, 数据接入缓冲区 (In Bound Cache) 与各类数据源分别按标准定义接口 (适配器) , 数据接出缓冲区 (Out Bound Cache) 与各类数据应用系统也分别按标准定义接口 (适配器) , 接口均可复用。接入缓冲区的数据通过合并、清洗、转换后, 以唯一标识在主数据库中予以记录, 再按统一的标准规范, 流向数据接出缓冲区, 提供数据应用服务。数据源系统与数据应用系统中的数据不实时对接, 经由主数据库实现基于同一性的共享应用。当数据交换量大幅增加时, 上述模式可简化交换流程并有效提高交换效率。同时, 因数据接入缓冲区与数据接出缓冲区是分别独立的, 可有效提供数据的安全性。图中显示了通过交换平台, 将学生学籍系统中的学生数据用于学生综合评价系统的过程。

4) 通过数据的管理与控制严把数据审核与质量关

在上图的主数据管理界面, 对合并、转换与修改的数据严格定义审核流程, 与相关应用系统结合来实现数据审核, 严格确定数据的应用质量。同时完成数据交换的实时监控, 对出错的数据交换可分析并回溯, 统计分析数据交换量, 实施数据交换的日志记录。

5) 通过在Camel Route中定义传输交换的优先级别

提升整合平台的易用性与健壮性, 确保系统需要的数据按优先级别到达。在数据转换与交换的应用实际中, 需要的数据在一定的时间限制内按时到位, 是数据应用与智能分析的基础保障。

6) 实现基础数据的智能分析应用

全市基础数据库只是数据仓库中经确认的一个子集。数据智能分析, 以并行数据库、ETL技术与BI工具为技术核心, 经数据抽取、转换与加载, 分别展示为物理层面、逻辑层面与决策层面的数据, 最后在决策应用的数据上提供智能分析应用。

9 结语

本文结合深圳市教育基础数据的应用现状, 阐明目前广大学校在基础数据应用方面存在可用性不高、共享度不足、覆盖范围不广以及应用能力不强等问题。针对这些问题提出了以云服务形式对数据进行统一采集与应用的整合框架。这一框架能有效提高数据共享程度, 减少数据重复录入及维护的开销, 在更加安全稳定的前提下支持更丰富的应用, 从而提高整体服务效益和决策支撑能力。标准教育基础数据元数据的设计、各种接口适配器以及教育基础数据云中各项服务的管理支撑系统的设计, 将在下一步具体系统的实现中进行逐步细化设计和落实。其中共享的元数据模型如何建立、基础数据服务如何进行语义描述以及教育基础数据云服务如何进行安全及性能监控、自动整合等, 都是未来的重要研究方向。同时, 还须在系统投入使用后对教育系统用户的实际使用情况进行反馈调研, 考察系统是否切实改善了教育基础数据应用情况, 作为不断完善系统的依据。

摘要：基础数据是教育管理公共服务平台的核心与基础。提高基础数据的应用服务能力, 数据采集是基础、数据整合是关键、数据安全是保障、智能分析是需要。结合云计算的应用, 分析教育基础数据的组成、基础数据采集与应用中存在的问题与困难, 探讨在教育云环境下, 教育基础数据的采集与存储、交换与共享、应用与服务等过程中的挑战及其解决方案。

关键词：基础数据,教育云,数据采集,数据流程,数据交换,数据安全

参考文献

[1]Alabbadi M.Cloud Computing for Education and Learning:Education and Learning as a Service (ELaas) [C].Interactive Collaborative Learning (ICL) , 2011 14th International Conference on, 2011.

[2]Mariya S.Cloud computing—an advanced e-learning platform of school education[C].Interactive Collaborative Learning (ICL) , 2011 14th International Conference on.

[3]Wayman J, Stringfield S.Technology-Supported Involvement of Entire Faculties in Examination of Student Data for Instructional Improvement[J].American Journal of Education, 2006, 112 (4) :549-571.

[4]陈庆贵, 申屠祖斌.教育基础数据库建设的探索与应用[J].中国信息技术教育, 2009 (23) :74-76.

[5]张延松, 薛永生, 张宇, 等.电子政务建设中的基础数据库建设规划研究[J].厦门大学学报:自然科学版, 2004, 43 (B08) :293-299.

[6]杨晓北.教育综合统计信息系统建设的基本思路[J].管理信息系统, 2001 (6) :20-22.

[7]张宇, 张延松, 薛永生, 等.电子政务基础数据库建设和信息服务研究[J].计算机应用, 2005 (3) :39-41.

[8]沈晔.四大基础数据库建设瓶颈分析[J].合作经济与科技, 2008 (7) :68-69.

[9]IBM Software Group ESB、WEBSPHERE、SOA技术交流资料, 2011.

[10]探智软件科技 (上海) 有限公司.Trinity v3.7产品及功能介紹[R].2012.

基础数据平台 篇8

关键词：云计算,政务应用数据中心,基础平台,设计

近年来, 云计算等信息技术服务新模式、新业态的迅猛发展, 虚拟化等技术在数据中心建设中应用更加深入。云计算是分布式技术和网络技术融合发展的产物, 这种模式不通过本地计算机或远程服务器, 而是在大量分布式部署的计算机上实现计算, 这使得数据中心服务与互联网极为相似。

从架构的角度来看, 云计算通过一种更合理更有效的手段实现了资源调度, 这种调度方式是面向业务需求的服务方式, 而非传统的面向复杂多样的物理设施。这种方式对于解决实际工作中存在的政务应用需求与信息基础设施无法合理配置的现实问题, 具有很好的借鉴意义和应用前景。在云计算架构中交互服务层是基于服务调用的关键环节, 而数据中心基础平台就是交互服务层的具体实现, 他是底层的物理设备通过智能服务功能, 使得其上的业务层面看不到底层复杂的结构, 不用担心资源的物理调度, 从而最大化实现资源的共享、复用和合理调度。本文中我们将利用现有成熟的云计算、虚拟化技术, 结合工作实践, 提出新一代政务应用数据中心基础平台的设计方案。

1 传统政务应用数据中心存在的问题

随着信息化技术在各行业领域的深入应用, 各地区各部门对于政务信息化逐步重视, 投入逐步加大, 随着政务信息化的深入推进, 大量应用系统上线运行, 这些系统都需要服务器、存储、网络及机房等硬件基础设施的支撑, 传统的硬件设备统一托管、维护的数据中心应运而生。而这种以传统模式建设的数据中心存在以下问题:

1.1 资源利用率低下, 业务需求增加迅速

为保证政务业务系统的可用性, 系统设计中均按照业务繁忙期的峰值来采购服务器及相关设备, 各业务系统繁忙期又不尽相同, 因此大部分时间大量服务器的资源利用率均在10%以下, 大部分计算、存储资源没有得到有效利用。与此同时, 随着业务的推进、数据大集中等需求, 计算及存储的需求增长迅速, 若闲置资源无法利用, 又需要通过新增设备方式满足, 从而造成投入增加、资金浪费。

1.2 运维成本高, 管理日益复杂

传统数据中心的运维方式繁琐复杂, 现有服务器出现问题时, 运维人员往往要先重新安装操作系统, 接着还要安装程序服务软件, 最后再测试运行。这些步骤往往不是一、两个运维人员就可以解决的, 过程持续数天, 时间成本和人员投入较大, 管理不便。

1.3 扩展性、业务灵活性差

传统数据中心的一个服务器系统中往往杂糅运行数个甚至数十个政务应用系统, 各个应用系统之间存在相同中间件应用时调配起来混乱, 不能灵活的相互调整资源或者灵活的相互切换。

1.4 系统分散、安全性可用性差

政务系统之间相互独立, 不能进行统一的管控, 各自需要的安全配置无法在一个服务器上实现, 导致无法确保应用系统的病毒防护网络安全。

2 新一代数据中心基础平台的设计

2.1 设计思路

新的政务数据中心采用云计算的设计思想, 通过使用虚拟化技术将数据中心按照“池”的概念重新设计, 并将这些“资源池”进行整合, 采用该设计思路可以实现资源动态调整, 提高数据中心的灵活性。

2.2 结构

目前云计算数据中心资源池主要分为计算资源池、存储资源池和网络资源池, 同时也包括软件和数据等内容资源池。在服务提供方面主要以计算资源、存储资源提供为主, 如为业务信息系统分配虚拟服务器、有储空间, 提供应用服务器、数据库管理系统等应用系统运行环境。

按照政务工作实际, 我们将云数据中心基础平台划分为四个资源池, 分别为计算资源池、网络资源池、储存资源池和安全资源池。

2.2.1 计算资源池

计算资源池是基础平台中最核心的部分, 从硬件上来看, 日常接触的机架刀片式服务器均可作为计算资源池的一部分, 软件上, 核心则是云操作系统。目前常用的有Vmware公司的Vsphere和浪潮公司的Xen系列产品等, Vsphere专门为工作负载不足20台服务器的it环境设计, 且系统技术比较成熟, 目前使用该系统较为合适。

虚拟化软件中的HA和Vmotion技术可以确保应用的高可用性, 避免异常开关机造成的影响。

Vmotion可以使运行中的虚拟机从一台物理服务器实时迁移到另一台物理服务器, 它实现了零停机时间和连续可用的服务, 并能全面保证事务的完整性。Vmotion是一种用户创建动态、自动化、自我优化的数据中心的关键促成技术。如图1所示。

2.2.2 网络资源池

网络资源池的主要作用是将SAN、LAN、Infi niband等整合为一个统一的网络架构, 以降低网络配置的复杂性和成本, 并从技术上带来高带宽、低延迟和可管理性。

2.2.3 储存资源池

储存资源池本质上是一个可支持基于文件或数据块的NAS网络附加储存的网络化储存架构, 这些多协议系统将通过串口甚至是光纤网络接入服务器。

在云计算平台的存储中, 磁盘数据的读写速度是一个更重要的问题, 因此需要对多个磁盘进行同时读写.这种方式要求将数据分配到多个节点的多个磁盘当中。为达到这一目的, 存储技术有两个选择, 一个是使用类似于Google File System的集群文件系统, 另一个是基于块设备的存储区域网络SAN系统。

统一储存系统的使用可以提高储存设备的利用率并增强储存资源池的灵活性。

2.2.4 安全资源池

新一代的数据中心对安全问题更为关注, 新数据中心在设计时就对整个虚拟化的软硬件进行统一考虑, 在确保信息不泄密不损失的同时也保证数据的不被破坏。杀毒软件通过统一的配置保证系统不被攻击, 通过远程数据备份方案保证数据永不丢失。如图2所示。

2.3 资源池的组合

如图3所示。

3 应用效果与未来展望

新一代数据中心与传统数据中心相比有如下显著进步:

3.1 可用性和灵活性大幅度增强

经过比较, 采用传统数据中心新增一台服务器所用时间要经过1-3周, 使用新的数据中心则将时间缩短至5分钟, 管理员仅仅通过登陆后台管理界面进行虚拟机的分发即可实现。

3.2 运维复杂度大大降低

基础数据平台 篇9

关键词：Geoway数据加工平台,数据矢量化,MDB入库数据,质量检查

0 引言

地理信息数据是系统平台应用的基石, 以地理信息技术为支撑, 服务于公安业务管理、信息共享和决策支持, 对增强地区公安机关核心战斗力, 促进公安信息化建设具有十分重要的作用。警用地理信息基础平台 (PGIS平台) 在报警监控、反恐应急、抢险救灾、警力调度、群体性突发事件的处置、大型活动的安排部署、预防打击犯罪以及各级领导的指挥调度等方面发挥着巨大的作用。

1 软件及基础数据成果要求

本项目以Geoway3.6作为矢量化软件, 完成部分地区1:10000比例尺的基础地理数据7个图层的矢量化, 分类编码及属性设置须整理转换为警用平台规定的格式要求。成果数据要求:WGS-84坐标系, SHP格式按主城区拼接后的整幅数据, 并且需要有空间参考信息。影像数据采用Img格式, 并且保证各城区影像颜色一致性、无色差、无缝且清晰, 并且需要有空间参考信息。警用矢量数据要求建设城市核心区域 (含各地州、县) 且矢量数据与影像地图坐标系必须相匹配, 且与影像地图叠加完全吻合, 所有空间数据均为拼接后的整幅数据。

2 基础数据要素内容

基础要素数据库主要包括水系、交通、居民地、植被、境界五大类基础数据及元数据信息。根据实际要求, 再进一步细化, 共分为8层数据。

2.1 线状要素分层 (表1)

2.2 面状要素分层 (表2) (1) 水系数据主要包括常年河、时令河、湖泊、池塘、水库等边线, 以及其他线状要素。 (2) 交通数据主要包括铁路、城际公路、城市道路的边线及中心线、乡村道路依比例尺双线路边线和不依比例的单线路。 (3) 居民地数据主要包括街区、单幢房屋边线。

3 矢量作业基本流程

本项目的基本作业流程为:将原有独立坐标系的MDB数据转换成SHP格式导入Geoway软件按方案对各类地物进行分类;构建拓扑关系;然后将纠好的最新影像加载到工程里, 对变化较大地区进行矢量化更新, 导入地名数据、按要求进行分类;进行数据检查;导出为SHP格式的数据;进行数据坐标转换。作业流程图如图1。

4 Geoway矢量化及属性输入过程

4.1矢量交通层时, 影像上能分辨、且宽度大于3米的道路全部依比例表示且注意中心线位置。高速公路的名称 (总名和分段名) 及编号全部表示, 县乡道以上的道路和编号应全部表示, 所选取的居民地一般都应有道路连接, 做到路路连通, 路路成网, 在不影响清晰的情况下应尽量详细表示。矢量时注意不能贯穿房屋, 面状道路要注意与其它层的拓扑关系, 不能存在重叠及压盖。

4.2 矢量水系时, 要注意成网成片, 有名字的需在属性项标注出来, 不能出现无头渠但干沟除外。

4.3 居民地矢量时, 注意同一小区勾画标准需统一, 若遇高地房屋需进行分割, 如图2所示, 因为测区影像特殊性, 需将房屋移至地基处, 相对应的道路及植被也应作相应改正。

4.4 植被勾画时要注意线条的圆滑, 在遇单线道路时要露出道路路面, 若遇面状的道路则此道路参与造区与植被面区共线。

5 Geoway下矢量数据的检查及处理

5.1 线层正确性检查主要包括线打折及自相交、重叠线、线交汇处拓扑关系、悬挂点/伪节点、长度小于1碎线等的检查及错误处理 (质量检查—图形检测-显示悬挂点/显示伪节点-属性检测-长度) 。因道路已对照影像修改过, 要注意检查路交汇处拓扑关系正确性;同名称道路及水系的连通性;以及道路与居民地、水系线面是否有压盖、不合理穿越等空间相互关系错误, 如单线道路不能贯穿房屋, 水渠 (质量检查—逻辑关系检测-线落入面/线穿越面) 。

5.2 面层检查处理, 面标识点、拓扑面、面悬挂线检查处理, 相邻相同拓扑面检查与合并处理 (专业功能-拓扑-拓扑检查-拓扑点、面、线检查-拓扑面重叠检查) , 尤其是面状层不能有空面此是重大缺陷。面构好后还要检查是否有路边出现很小或很长很细的不合理细长面情况, 如果有则要进行处理 (可参考影像综合判定修改的合理性) , 此外各面层之间需进行逻辑关系检查不能有重叠压盖。

5.3 甲方要求名称 (MC) 属性字段中的地名、路名不能有括号, 因此须将括号中的内容放入备注 (BZ) 字段中。

6 Geoway下FLDM、GBDM属性赋值

点击“专业功能->数据整理->固有属性整理”工具, 赋FLDM, 选用对照表文件:FLDM赋值.txt。 (图3)

赋GBDM采用“属性编辑”下的“固有属性转出”功能即可。 (图4) 检查FLDM、GBDM、GXSJ这几个必填属性是否都赋值正确。

7 数据导出

经检查无问题后导出地理坐标系WGS-84的MDB格式实体数据。需导出空层, 选用对照表文件:“导出MDB对照表”。导出后的数据在ARCGIS下检查是否有缺层、属性丢失等错误。将MDB格式转换为SHP格式。检查好后, 按规定格式上交数据。

参考文献

[1]GB/T 15660-1995, 国家测绘局测绘标准化研究所.1:5000、1:10000、1:25000、1:50000、1:1000000地形图要素系列和基本要求[S].

[2]北京吉威数据源软件开发有限公司.Geoway3.6用户手册.

基础数据平台 篇10

经过多年的信息化建设, 我国供电企业的信息化水平有了显著提高, 大量业务应用系统 (如营销业务应用系统、营销稽查监控、用电信息采集以及客户服务系统等) 的建设和推广, 极大地提升了供电企业的工作效率和服务水平。对现有系统而言, 根据不同业务需求, 在不同时期由不同生产厂商开发的业务系统的数据结构以及实现技术各不相同, 自成体系, 系统之间的数据共享、传输和交换也十分复杂。由于数据模型和接口没有统一的标准或规范, 彼此之间的信息共享程度较低, 数据交互存在困难, 出现了“信息孤岛”现象。相对独立的各业务系统难以实现对数据资源的深度加工和集中利用, 影响系统间的信息交换, 进而导致信息资源利用率低下和各相关业务系统的重复建设, 造成人力、物力和财力的极大浪费。

为解决电力领域各相关业务系统间信息资源集成问题, 国际电工委员会在输电网领域制定了IEC61970系列标准, 在配电网领域制定了IEC61968标准, 这2套标准一直在不断地发展和完善之中[1]。IEC61970标准由国际电工委员会第57技术委员会第13工作组负责意见征集、标准拟定、征求意见以及标准发布, 它定义了能量管理系统应用程序接口标准。IEC61968标准由国际电工委员会第57技术委员会第14工作组制定, 定义了电力企业应用集成-配电管理的系统接口。其中, 公共信息模型 (Common Information Model, CIM) 部分 (包含IEC61970-301和IEC61968-11) 定义了应用程序接口的语意[2,3], 组件接口规范 (Component Interface Specification, CIS) 部分 (包含IEC61970-401-407) 定义了信息交互的内容[4,5,6,7]。

遵循IEC61970/61968标准, 即使是不同开发者在不同时期开发的能量管理系统 (Energy Management System, EMS) 、配电管理系统 (Distribution Management System, DMS) , 也可以非常方便地集成在一起, 实现不同业务系统间的信息交互。因此, 研究IEC61970/61968标准具有非常重要的意义。本文依据营销基础数据平台, 对CIS中的通用数据访问 (General Date Access, GDA) 进行深入研究, 并结合公共对象请求代理体系结构 (Common Object Request Broker Architecture, CORBA) 技术, 实现了即插即用特性的GDA接口规范[4,5]。

1 CIM模型建立

CIM是一个抽象模型, 是电力领域、计算机领域及其他相关领域专家对电力企业中所有主要对象的高度概括和抽象。CIM模型通过包、类、属性、包之间关系以及类之间关系等方式来描绘电力系统相关资源以及资源之间的联系。通过定义包含语义和语法的CIM公共语言, 不同应用或系统之间能够不依赖其内部表示而实现数据访问和信息交换[8]。IEC61970/61968标准中采用统一建模语言 (Unified Modeling Language, UML) 来实现对电力系统中涉及的有关设备、器件、虚拟实体以及配网领域相关实体进行面向对象建模, 通过绘制一系列类图及它们之间的关系来表示电力系统中类与类之间的复杂关系。CIM绘制过程中主要涉及到的包、类、属性、数据类型以及关系等基本概念, 这里不再赘述。

IEC61970/61968 CIM标准能够涵盖电力系统的主要资源, 但是不可能包含不同国家所特有的一些对象资源[9]。因此, 每个国家在实际应用时应根据自身业务需求, 对标准中不存在的类或属性进行相应扩展。在扩展过程中遵循从最简单到最复杂的原则:根据业务需求, 梳理并分析IEC CIM数据模型中已有的类、属性以及关联关系, 如果IEC61970-301和IEC61968-11中现有的类能够满足我国营销业务需求, 直接使用此类及其属性;如果IEC61970-301和IEC61968-11中的某个类能够部分满足智能营销业务需求, 则选择此类, 并创建一个新类, 所创建的新类继承所选择的类, 根据业务需求在所建新类中添加属性, 然后根据实际业务关系添加关联关系;如果IEC61970-301和IEC61968-11中的类不满足智能营销业务需求, 则创建一个新类, 新创建的类要继承其他类或直接继承基类Identified Object, 然后根据智能营销实际业务向新类中添加新属性, 根据业务需求与其他类进行关联。IEC CIM模型扩展流程如图1所示。

根据IEC CIM扩展原则建立模型后, 需要对扩展后的CIM模型进行正确性、完整性和一致性检查, 主要包括: (1) 对业务对象关系图进行正确性和一致性检查; (2) 对重复关系进行删除, 对遗漏关系进行补充; (3) 检查对象关系图是否完整, 所绘制图形能否满足用户业务需求, 若仍不满足用户相关业务需求则需进一步修改, 对满足要求的CIM模型映射转换成物理模型, 映射过程主要包括类、继承关系、关联关系、聚合/组合关系等映射及主键选择。

2 CIM到物理模型的映射

采用CIM模型可以更加直观准确地描述电力系统, 与国际通用标准接轨, 便于不同电力系统厂商在不同时期开发的应用系统间集成, 便于模型扩展和维护。CIM模型是一种概念数据模型, 从用户的角度出发, 此模型便于用户理解现实世界, 与实际实现无关。因此, 下一步关键技术是如何将CIM模型映射到现有数据库。

数据库是依照某种数据模型组织起来并存放在二级存储器中的数据集合, 主要分为关系数据库、实时数据库、分布式数据库以及面向对象数据库等。基于IEC61970/61968标准的智能营销数据模型一般采用技术比较成熟的关系型数据库来实现对营销CIM模型的存储。在采用关系型数据库存储CIM模型时, 要体现CIM模型的相关有用信息, 尽量遵循CIM的类结构, 即通过数据库能够展现整个CIM模型, 包括类、属性以及类与类之间的关系等。

当前存储CIM数据主要采用关系型数据库, 在将CIM模型存储到关系型数据库的过程中, 主要工作是建立CIM模型中类和属性与关系型数据库中的表和字段之间的映射关系, 即在关系数据库中通过建立有关表来实现对CIM模型的完整描述, 其映射基本原则为:类映射成表;对象映射成记录;属性映射成字段;关联通过Resource ID实现;继承为表的扩充。

2.1 继承关系映射

继承关系表示一个一般类 (父类) 与一个特殊类 (子类) 之间的关系。特殊类可以继承一般类的属性、操作和关系。另外, 特殊类可以具有自身所特有的属性和关系。

在关系数据库中要表达这种继承关系, 可以通过以下2种方式来实现。

1) 子类映射成实体物理表, 父类的属性和关系下落到子类中。

2) 父类和子类都映射成实体物理表, 父类与子类之间的关系是一对一关系。

继承关系映射如图2所示。

2.2 关联关系映射

关联关系主要分3种: (1) 一对一关系, 包括 (0..1, 0..1) 和 (0..1, 1) ; (2) 一对多关系, 包括 (0..1, 0..*) 、 (0..1, 1..*) 、 (1, 0..*) 和 (1, 1..*) 4种关系; (3) 多对多关系, 包括 (0..*, 0..*) 和 (0..*, 1..*) 和 (1..*, 1..*) 。从本质上来讲, 一对一关系是特殊的一对多关系。

1) 一对一关系中, 对于 (0..1, 1) 的情况, “1”端表的Resource ID应该放入“0..1”端表的对外关联字段中 (见图3) ;对于 (0..1, 0..1) 的情况, 应根据实际业务需求来进行选择。

2) 一对多关系中, 对于一对多情况, 应该把“一”端表的Resource ID放到“多”端表的对外关联字段中。

3) 多对多关系中, 对于多对多的情况, 需要建立一个中间表来实现多对多关联, 然后把2个表的Resource ID放入中间表中。

3 基于CORBA的GDA实现

基于IEC CIM/CIS国际标准构建的营销基础数据平台是营销口径内各业务系统间数据共享的信息基础设施, 可以很好地支撑营销各相关系统的业务, 在营销基础数据平台中, GDA得到了很好的应用。

3.1 CORBA

CORBA是由对象管理组织 (Object Management Group, OMG) 制订的一种标准。CORBA基于面向对象技术, 是真正跨平台、与具体编程语言无关的体系结构, 能够解决远程对象之间的互操作问题。CORBA的核心体系结构是对象请求代理 (Object Request Broker, ORB) , ORB是一种能够实现客户应用程序调用远端对象方法的机制, ORB能够使在分布环境中的对象透明地生成请求以及接收响应。单个ORB体系结构如图4所示[4]。

ORB具有代理功能, 通过ORB客户端和服务器端只需关心功能上的实现, 不需要考虑二者之间的通信协议等相关问题。ORB是一个中间件, 用来连接网络上处于不同位置的对象, 能够实现对象的定位和方法的调用。

3.2 GDA接口

IEC61970 CIS主要包括GDA、高速数据访问 (High Speed Data Access, HSDA) 、时间序列数据访问 (Time Series Data Access, TSDA) 以及通用事件和订阅 (Generic Eventing and Subscription, GES) 等接口, 本文以GDA接口为例, 来说明其实现过程。IEC61970-403中对GDA进行了详细的描述, 按照CIM模型扩展原则建立符合我国国情的CIM模型, 并把CIM模型映射到关系数据库中, 然后调用GDA提供的访问公用数据的所有API服务, 采用请求/应答访问机制实现对数据的存取。由于采用CIM建模思想, 应用或组件无需知道数据提供方数据库中的数据存储方式就可以获取其感兴趣的数据, 这也是CIM的突出优点之一。

GDA主要由读访问、写访问和更新事件通知3部分组成。营销基础数据平台主要提供查询功能, 因此, 本文只对涉及查询的有关方法进行相关说明。

1) get_reource_ids () 方法。 (1) 参数:URISe quence uris; (2) 返回:Resource IDSequence; (3) 抛出:Lookup Error; (4) 功能:通过对象的通用资源标识符 (Universal Resource Identifier, URI) 得到其对应的Resource ID, 实现URI与Resource ID之间的相互转换。Resource ID是URI的一个紧凑、定长的替代物, 引入它是为了能高性能地实现GDA, 因为从语法上说明、比较和查询URI的代价可能太大, Resource ID也可以简化某些GDA实现。

2) get_uris () 方法。 (1) 参数:Resource IDSequence ids; (2) 返回:URISequence; (3) 抛出:Lookup Error; (4) 功能:将一组Resource ID标识符翻译成对应的URI。返回URI序列的长度和元素顺序与输入Resource ID序列的长度和顺序完全一致, 否则报错。如果传入的Resource ID未标识任何资源, 则在其对应位置上返回一个空URI资源标识符 (空字符串) 。

3) get_values () 方法。 (1) 参数:Resource ID resource, Resource IDSequence properties; (2) 返回:Resource Description; (3) 抛出:Unknown Resource, Query Error; (4) 功能:给定一个资源的资源标识符, 查询此资源对应表中指定属性的值。如果数据提供者不知道resource资源标识符, 则会引发Unknown Resource异常。

4) get_extent_values () 方法。 (1) 参数:Resource IDSequence properties, Resource ID class_id; (2) 返回:Resource Description Iterator; (3) 抛出:Unknown Resource, Query Error; (4) 功能:给定一个类, 查询这个类及其子孙类的所有资源描述。如果Resource ID解析后没有相应的URI与之对应, 则产生UnknownResource异常;如果在查询过程中出现异常, 则抛出Query Error异常。

5) get_related_values () 方法。 (1) 参数:Resource IDSequence properties, Association associ, Resource ID source; (2) 返回:Resource Description Iterator; (3) 抛出:Unknown Resource, Unknown Association, Query Error; (4) 功能:查询与给定资源相关联的某个资源的所有资源描述, 可以在Association结构体中对查询结果进行筛选。给定资源用Resource ID指定, 而关联由Association结构指定。

6) get_descendent_values () 方法。 (1) 参数:Resource IDSequence properties, Association Sequence path, Resource IDSequence sources, Association Sequence tail; (2) 返回:Resource Description Iterator; (3) 抛出:Unknown Resource, Query Error; (4) 功能:这种复杂的查询方式是一种更为普遍化方式, 上面所述get_values () 、get_extent_values () 和get_related_values () 3种查询方式是get_descendent_values () 方式的特殊情形。通过重复调用get_related_values () 查询即可实现get_descendent_values () 查询。即当get_descendent_values () 中关联链的长度为1时, get_descendent_values () 等价于get_related_values () , 此查询请求能够对实现关联链对端资源某些属性的查询。

4 测试结果

在本文的实验数据中, 以自行编写的测试数据为例, 验证GDA各接口是否满足CIS规范。部分GDA测试结果如图5所示。

5 结语

本文基于营销业务有关信息, 采用IEC61970/61968国际标准, 对营销业务进行CIM建模, 然后将所建CIM模型映射到关系数据库中, 采用CORBA中间件技术全面支持GDA接口。由于在营销领域首次采用IEC61970/61968标准, 并且IEC61970/61968也在不断的完善和改进之中, 因此, 基础数据平台是一个逐步完善和提高的过程。随着这种新思想、新技术的应用, 必将会使电力营销相关系统产生重大变革, 促进电力营销系统向着标准化、国际化的方向发展, 能够更好地与国际接轨。

参考文献

[1]吴维宁, 辛耀中, 姚建国, 等.IEC TC57 2011年会和SAC/TC82工作近况[J].电力系统自动化, 2011, 36 (1) :1–5.WU Wei-ning, XIN Yao-zhong, YAO Jian-guo, et al.Introduction to recent work of IEC TC57 2011 plenary and SAC/TC82[J].Automation of Electric Power Systems, 2011, 36 (1) :1–5.

[2]吴文传, 孙宏斌, 张伯明, 等.基于IEC61970标准的EMS/DTS一体化系统的设计与开发[J].电力系统自动化, 2005, 29 (4) :53–57.WU Wen-chuan, SUN Hong-bin, ZHANG Bo-ming, et al.Design of integrated EMS/DTS system based on IEC61970[J].Automation of Electric Power Systems, 2005, 29 (4) :53–57.

[3]叶清华, 张代新, 胡继芳, 等.基于CIM的CIS应用研究及实现[C]//第29届中国电网调度运行会收录论文全集, 2005.

[4]陈树勇, 李健, 白晓民.基于CORBA的应用软件标准接口的研究[J].中国电机工程学报, 2002, 22 (6) :17–19.CHEN Shu-yong, LI Jian, BAI Xiao-min.Research on standardized application program interface based on CORBA[J].Proceedings of the CSEE, 2002, 22 (6) :17–19.

[5]方烁, 梁成辉, 徐庆平, 等.IEC61970标准中CIS的Web服务定义与实现[J].电力系统自动化, 2006, 30 (15) :81–84.FANG Shuo, LIANG Cheng-hui, XU Qing-ping, et al.Using web services to implement component interface specification in IEC61970[J].Automation of Electric Power Systems, 2006, 30 (15) :81–84.

[6]毛鹏, 李晓露, 秦红, 等.公共信息平台的数据访问服务设计[J].电力自动化设备, 2010, 30 (10) :121–125.MAO Peng, LI Xiao-lu, QIN Hong, et al.Design of data access services for common information platform[J].Electric Power Automation Equipment, 2010, 30 (10) :121–125.

[7]王志南, 吴文传, 张伯明, 等.基于IEC61970的CIS服务与SVG的研究和实践[J].电力系统自动化, 2005, 29 (22) :60–63.WANG Zhi-nan, WU Wen-chuan, ZHANG Bo-ming, et al.Study and implementation of CIS and SVG based on IEC61970[J].Automation of Electric Power Systems, 2005, 29 (22) :60–63.

[8]樊荣.基于CIM-DAF的电力系统模型数据交互的研究[D].武汉:华中科技大学, 2007.