气象数据元管理系统设计与实现

贾松林 王颖 薛蕾 王博

（国家气象信息中心，北京 100081）

0　引言

数据元是通过标识、定义、表示以及允许值等一系列属性描述的数据单元，在特定的语义环境中被认为是不可再分的最小数据单元[1]。针对数据元的注册管理维护问题，国内部分行业已经开展了数据元管理系统的研究和设计实现。交通运输部针对交通信息基础数据元已建成了交通信息基础数据元管理与服务系统。方文亮[2]以陕西省交通信息基础数据元字典编制项目为背景开展了对数据元的结构研究，开发了基于Web的数据元管理系统。姚远等[3]介绍了基于网络的卫生信息数据元管理平台设计、管理流程。文必龙等[4]给出了基于语义的石油勘探开发数据元管理架构，提出了数据元质量控制模型、数据元分类模式、数据元搜索服务等管理技术。

气象数据元是气象数据中不可再分的最小数据单元，可分为33个大类，每类包含几十到数百个数据元，每个数据元包含16个属性。建设一套管理系统对这些气象数据元进行有效规范的管理具有重要的业务现实意义：该系统的建设将为实现气象数据元在气象业务全流程环节共享、确保数据元“全局”一致提供支撑平台，为业务管理人员提供高效便捷的气象数据元管理和维护工具，并为业务用户和公众呈现出直观的数据元查阅和使用窗口。本文简要介绍了气象数据元的标准与分类，重点阐述了气象数据元管理系统的功能结构、技术框架和一些关键技术的实现。

1　气象数据元标准与分类

我国部分行业陆续对本行业的数据元进行了标准化研究工作，发布了一系列行业范围内的相关标准[5-8]，建立了各自领域范围内的标准化数据元目录，对于本行业的数据标准化及国家的数据元标准化工作发展都起到积极的推动作用。

在气象领域，气象数据元标准系列是气象信息化标准体系中的基础数据标准，由34个部分组成，包括总则部分和33类数据元各自对应的部分。气象数据元标准用于规范相关数据元在元数据和数据格式中的统一标识和表示，填补了气象信息化业务流程中对于数据规范表示标准的缺失，可支撑气象数据在气象信息化系统中的高效流通和应用。气象数据元标准适用于气象数据的采集、传输、分析、加工、存储、发布、以及应用（天气、气候等业务应用、政务管理应用）和服务（公共气象服务等）等各业务环节，以解决目前相同数据元在不同业务环节中代码、特征值等表示规则不统一的问题。

国家气象信息中心发布的“气象数据元—第1部分：总则”（以下简称为“总则”）根据世界气象组织（WMO）基本系统委员会发布的气象数据通用二进制表示格式（BUFR编码格式）和气象要素分类与编码[9]将气象数据元分为33类，其中28个类型码与BUFR表B一致，4个是本地扩展的类型码。具体包括测站/平台标识、仪器、时间、纬向水平位置、经向水平位置、垂直位置、意义限定符、高度与气压、风和湍流、温度、湿度/降水/蒸发、辐射、大气成分、天气系统特征、天气现象、雷达气象、海洋气象、释放与输送、放射性辐射、处理信息、时间（非坐标位置）、纬向水平位置（非坐标位置）、经向水平位置（非坐标位置）、地图数据、图像、质量信息、数据监测信息、卫星气象、空间天气、灾害、农业与生态气象、大气诊断物理量和其他。每个气象数据元有16个属性，包括中文名称、代码、英文名称、简称、定义、数据类型、提交机构、状态、版本、计量单位、数据精度、特征值、学科种类、参数种类、参数编号和备注。上述16个气象数据元属性中，前9个（中文名称等）必选，后7个（计量单位等）可选。

2　系统功能设计

根据总则，气象数据元的维护工作应包括数据元生命周期管理、数据元的添加、删除、更新等工作，这些工作应由数据元注册机构负责。另外数据元编制完成并发布后应能被行业用户和公众用户方便地检索发现和使用。据此确定了气象数据元管理系统的功能模块由数据元查询、提交、管理和用户管理四部分组成，具体功能划分如系统功能结构图1所示；而用户角色则由普通用户、业务维护人员和系统管理人员三类用户组成。

图1　气象数据元管理系统功能结构Fig. 1 Functional structure of meteorological data element administration system

数据元查询功能为用户提供了多种发现数据元的查询方式，并可导出所需数据元到Excel数据文件中，包括数据元目录导航、关键词查询、条件查询、详细信息查看、导出数据元到Excel文件。数据元提交功能主要为业务人员向系统中新增与修改气象数据元提供方便，包括数据元新增、导入、更新、校验。数据元管理功能主要供业务维护人员决定是否发布、删除提交的数据元，并对数据元的类型和特征值进行管理，包括数据元发布、删除、类型管理、特征值管理。用户管理主要用于所有用户的注册与登录，并可供系统管理员对注册用户进行审核授权，包括用户注册、登录与退出、用户信息查看与修改、用户审核与删改。

气象数据元管理系统的三类用户根据角色权限的不同可使用的系统功能也不同。普通用户是指公众用户和行业内用户，这些用户仅能使用系统的数据元查询功能，可以查询系统中已发布数据元的信息，导出选定的数据元。业务维护人员是指气象数据元的编制和管理人员，主要对系统中的气象数据元进行相关的提交维护工作，能够使用系统中与数据元业务维护相关的查询、提交、管理功能。系统管理人员负责系统用户的审核管理和整个系统网站的运行维护，能够使用系统所有的功能。

3　技术框架

气象数据元管理系统采用B/S架构，后台主要用Java语言开发，前端主要使用jsp+js+css技术，系统的开发框架采用Spring MVC与MyBatis的整合，数据库根据业务需求与其他业务系统共用Oracle数据库。

总体技术框架基于Spring MVC采用数据访问层、业务服务层、控制层和视图层分层开发的模式，具体如图2所示。该框架纵向上采用分层的设计，横向上则按系统的业务功能划分相应页面、接口和类。控制层对服务层的调用以及服务层对数据访问层的调用一方面采用了面向接口的方式而不关心具体的接口实现，另一方面采用Spring注解注入的方式来获取实现接口的实体类对象。

图2　气象数据元管理系统技术框架Fig. 2 Technical framework of meteorological data element administration system

数据访问层基于MyBatis的DAO 接口组件和SQL Mapper组件实现：DAO接口是数据访问接口的一系列声明，数据服务层对数据库的操作只是面向这些接口进行，而不用关心这些接口的具体实现；SQL Mapper则是DAO数据访问接口的具体实现，并将具体的SQL操作语句配置在XML格式的配置文件中，便于以后的维护。

4　关键技术实现

4.1　气象数据元目录

如第1节所述，气象数据元共包括33类，每个类别中包含的数据元数少则几十多则数百，对这些数据元进行分类管理对于数据元的存储管理和查找发现都至关重要。

气象数据元管理系统使用了目录导航的形式对数据元进行分类管理和检索发现。系统使用了EasyUI的Tree组件以实现数据元目录树结构，使用Datagrid组件以实现数据元查询结果列表展示和翻页，实现效果如图3所示。

具体的实现逻辑是：当点击目录树的非叶子节点时，后台控制器从数据元类型表中检索出数据元的所有类型信息，如类型标识、名称等，每个类型封装成Tree组件的节点对象并转换为JSON格式，之后由后台控制器返回给前端Tree组件加以显示；当点击目录树的叶子节点时，后台控制器从气象数据元信息表中查询出属于该节点类型的数据元记录，使用MyBatis分页插件PageHelper对查询结果进行分页后封装成JSON格式，之后由后台控制器返回给前端Datagrid组件展示。

图3　气象数据元目录Fig. 3 Catalog of meteorological data elements

4.2　气象数据元校验

根据第1节所述，气象数据元属性共16个，总则对这些属性的编制规则做了具体规定，通过管理系统的导入和增加功能提交的数据元应确保符合这些规定。为此，对这些属性编制规则进行总结并确定出便于程序校验实现的正则表达式如表1所示，并针对导入和增加两种不同的提交方式，相应采用了两种不同的属性校验方法。

表1　气象数据元属性编制规则及对应正则表达式Table 1 Rules and regular expressions of attributes of meteorological data elements

由于导入功能是基于数据元Excel数据文件的上传和解析，所以其检验方式是通过java后台代码实现。具体主要是通过实现Spring的Validator接口进行的，首先实现了该接口的函数public boolean supports（Class clazz）以支持要校验的数据元类DataElement，然后实现该接口的函数public void validate（Object target,Errors errors）以利用表 1总结的正则表达式依次校验数据元类对象各个属性的格式。

而增加功能是基于网页的交互式提交方法，因此其校验方式主要是通过js前端代码实现。具体主要是通过jQuery Validate校验插件进行的，对于数据元属性简单规则的校验直接使用了该校验插件提供的检验规则，如required:true以校验必选属性、range:[0,4]以校验状态属性取值、digits:true和rangelength:[5,5]以校验代码属性取值等。而对于格式要求复杂的数据元属性的校验，如简称、版本，则采用js单独编写校验函数并嵌入到jQuery Validate校验插件中进行校验。

另外对气象数据元唯一性的校验则主要是在入库前根据代码和版本判断数据库中是否已存在相同代码和版本的记录，如果已存在则不能入库，否则正常入库存储。

通过以上校验方法的实现确保了用户提交到管理系统的气象数据元的格式正确性和在数据库中的唯一性。

4.3　权限控制

如第2节所述，气象数据元管理系统的用户分三类：普通用户、业务维护人员和系统管理人员，这三类用户访问系统的权限是不同的，因此应对不同用户的访问做权限控制。具体的权限控制可分为对于前端JSP页面的显示控制和对于URL的访问控制。在实施这两种权限控制方式之前，应对三类用户分配不同的权限代码，并在用户登录的时候在会话Session变量中记录用户名和权限代码。

对于前端JSP页面的显示控制是通过JSP标准标签库（JSTL）的if标签获取Session变量存储的用户信息，并根据用户信息对象是否为空及用户的权限代码值来决定该用户是否能够访问相应内容。

对于URL访问的控制是通过使用拦截器结合权限注解的方式进行的。具体实现逻辑是：创建一个权限注解FireAuthority，该注解包含一个整型int的属性authorityType，该属性的取值应分别对应系统三类用户的权限代码。在要控制访问URL请求映射的控制器方法上进行权限注解，以确定该URL允许什么角色的用户访问。创建一个权限注解拦截器AuthorityAnnotationInterceptor以拦截该URL请求，该拦截继承自HandlerInterceptorAdapter，并重写其中的方法preHandle（HttpServletRequest request,HttpServletResponse response, Object handler）throws Exception，在该方法中获取handler的权限注解对象FireAuthority和Session中的登录用户对象，通过判断登录用户对象的角色与注解对象FireAuthority的属性值是否相符决定是否允许用户访问该URL。

通过以上两种方式的权限控制使得同一页面被不同角色的用户访问时能够显示不同的内容，特定的URL只能被有相应权限的用户访问，从而对气象数据元管理系统的用户访问做了有效的权限控制。

5　小结

目前，通过气象数据元管理系统提交发布的气象数据元包括温度、纬向水平位置、经向水平位置、气压、降水等，通过该系统实现了这些数据元在气象业务全流程环节中的共享，确保了这些数据元的“全局”一致。对于要新增的气象数据元，可通过系统提供的“数据元增加”功能逐条地录入，也可以通过“批量导入”功能快捷地批量导入数据元到系统中。

该系统的建设完成为业务管理人员提供了高效便捷的气象数据元管理和维护工具，并为业务用户和公众呈现了直观的数据元查阅和使用窗口。但该系统也有待改进之处：虽然系统基本功能都已开发完成，但系统界面设计仍有进一步美化改善的地方；另外，随着以后各个数据元标准的编写和发布，相应的数据元数据需要及时导入到系统中以便管理和服务。

[1]中国标准化研究中心. 信息技术数据元的规范与标准化(GB/T18391). 北京: 中国国家标准化管理委员会, 2003.

[2]方文亮. 数据元结构研究及其管理系统的设计与实现. 西安: 长安大学硕士学位论文, 2009.

[3]姚远, 李林, 冯丹. 数据元管理及其网络化管理平台的设计. 中国卫生信息管理杂志, 2012, 9(1): 59-61.

[4]文必龙, 肖波, 陈新荣. 石油勘探开发数据元管理技术. 大庆石油学院学报, 2012, 36(1): 83-88.

[5]中国标准化与信息分类编码研究所. 用于行政、商业和运输业电子数据交换的数据元目录(GB/T 17699—1999). 北京: 国家质量技术监督局, 1999.

[6]科学数据共享工程办公室.公用数据元目录(SDS/T 2131—2004).北京: 中国科学技术部基础研究司, 2004.

[7]中国标准化研究院. 电子政务数据元—第1部分: 设计和管理规范(GB/T 19488.1—2004). 北京: 中国国家标准化管理委员会, 2004.

[8]中交水运规划设计院. 交通基础数据元—第1部分：总则(JT/T 697.1—2007). 北京: 中华人民共和国交通部, 2007.

[9]国家气象信息中心. 气象要素分类与编码(QX/T 133-2011). 北京:中国气象局, 2011.