元数据注册系统

元数据注册系统（精选9篇）

元数据注册系统 篇1

摘要：统一建模语言UML是一个可视化并能提供面向对象开发全程支持的工具, 可以精确地描述软件开发过程产生的文档, 本文以元数据注册系统为例, 阐述了UML及用例驱动的建模过程, 在软件架构中结合了面向切面编程的思想, 提高了系统的可扩展性和松耦合性, 使用UML建立起来的模型指导软件开发, 有助于处理软件开发中存在的风险。

关键词：统一建模语言,元数据注册系统,用例驱动,面向切面编程

引言

数据处理和电子数据交换较大程度上依赖于数据库中数据的准确性、可靠性、规范性, 如何定义数据的特征或属性, 使得数据的使用者和提供者在数据的含义和表达上取得一致的认识, 是元数据产生和存在的根本原因[1]。元数据是描述数据的数据, 其本身也是数据, 因此元数据也可以存储在一个数据库中, 支持注册功能的一个元数据的数据库就是一个元数据注册系统。当前元数据注册系统的开发研究一般是利用面向对象编程 (OOP) 的思想设计实现各个模块, 由于OOP无法彻底解决软件开发中的维护、复用和扩展等问题。比如, OOP忽略了类与类之间的横向联系, 导致类之间的一些共同的方面分布在各个模块的实现中, 从而导致代码混乱, 如权限认证、时间要求、QoS监测及系统日志等, 正是由于这些非功能单元弥散在整个系统模块实现, 导致系统维护和扩展等方面带来了一系列问题。

针对面向对象思想在非功能单元 (如权限认证) 横向管理存在的缺陷, 本文融入了面向切面编程的设计思想, 使用统一建模语言UML对元数据注册系统进行系统分析 (用例建模、用例实现、软件架构) , 灵活选用UML所提供的多种模型, 较大提高代码的质量, 并有效避免软件实现偏离最初的需求, 有助于处理软件开发中存在的风险。

一、元数据注册系统

元数据注册系统是对元数据的定义信息及其编码、转换、应用等规范进行发布、登记、管理、检索的系统, 支持开放环境下元数据规范的发现、识别、调用以及在此基础上的元数据转换、挖掘和复用[2]。在GB/T18391中给出了元数据注册系统的总体模型, 包含了两个主要的组成部分:概念层与表示层, 概念层是从元数据定义者的角度, 表示层则侧重于数据元的使用者, 一个完整的数据元定义是一个数据元概念和表示 (值域) 的集合体。

二、UML建模

UML是面向对象领域内占主导地位的标准建模语言, 是一个通用的可视化建模语言, 用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。UML从面向对象编程语言的实现和长期的面向对象软件开发方法的实践中逐渐发展成熟, 成为目前面向对象建模技术的标准建模语言。UML包括概念的语义、表示法和说明, 提供了静态、动态、系统环境及组织结构的模型, 是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模方法。

本文采用UML建模工具UMLet对元数据注册系统进行建模分析, UMLet是一个开放源代码轻量级UML建模工具, 使用UMLet能够快速建模, 同时支持将模型导出其他多种格式, 如BMP、JPG、GIF、SVG等。

三、MDR系统建模

按照UML建模方法对一个系统完整的从获取需求到测试, 首先需要确定业务目标、分析涉众、确定系统边界等, 接下来获取业务用例、业务建模、领域建模、业务构架、确定系统用例和用例实现, 分析软件构架等等, 直至最后的系统设计、开发、测试, 限于篇幅下面仅挑选出几个重要的阶段对元数据注册系统进行建模分析。

3.1业务用例

通过整理建立元数据注册系统的意义和目的, 可以得到如下系统目标:

(1) 提交组织完成元数据 (包括数据元、值域、概念域、对象类等) 的注册。

(2) 普通用户能够浏览、检索、导出已经注册 (标准化) 的数据元。

(3) 规范元数据的注册流程, 管理已经注册 (标准化) 的元数据。

通过分析系统目标, 若以“提交组织服务”为边界可得到图1的业务用例。在该边界内包含主管组织、注册机构、专家等业务工人。

业务用例场景业务用例在实际过程中是如何做的, 为了强调各个参与者在业务中所执行的活动, 即强调业务参与者的职责[4]。在此使用带泳道的活动图来描述业务用例场景。图2为提交组织注册元数据场景活动图。

3.2系统用例

业务用例是从客户业务视角描述一个用例, 系统用例则是采用系统视角来看待用例。图3从业务用例“BIZ_注册元数据”获取系统用例。

确定系统用例后, 系统用例确定了系统应该做什么, 用例实现是跨越系统需求到设计的桥梁, 图4给出SYS_登记元数据为例给出用例实现。

3.3软件构架

元数据注册系统采用MVC框架Struts, 按照MVC的思想系统整体架构可以分为三层。

即表示层、业务层 (服务层) 和持久层, 每个层在处理程序上都有一项明确的责任, 防止在功能上与其他层混合, 只给各层之间放一个通信接口。通过软件分层可以很好地控制应用的复杂度、模块之间的耦合度, 更加有利于应用的变更与扩展。图5给出了“SYS_填写元数据表单”的框架实现示意图, 其中在业务控制层加入AOP思想, 即在控制层中, 将权限认证 (即切面) 织入到控制层对象中, 生成控制层代理对象。

四、结束语

本文以元数据注册系统设计开发为背景, 给出了使用UML建模工具完成对元数据注册系统建模的过程, 充分发挥UML建模语言的优点, 分别从业务建模、系统用例建模以及软件构架角度, 给出相关分析手段和结论, 同时, 运用AOP的思想解决面向对象方法在非功能单元横向管理存在的缺陷, 提高了系统的可扩展性, UML与平台无关的分析有利于模型的伸缩性[5], 便于对系统在高的抽象层次上进行维护, 通过UML建立起来的模型与用户沟通更为高效。

参考文献

[1]GB/T1839.信息技术元数据注册系统 (MDR) [S].

[2]张晓林.元数据研究与应用[M.北京图书馆出版社, 2002, 5.

[3]邓惠敏, 张立臣, 邓建波.基于面向方面和UML的实时系统建模研究[J].计算机技术与发展, 2010, 20 (12) .

[4]李志强, 邵培南, 朱辉.基于UML顺序图的测试用例生成[J].计算机工程, 2010, 36 (22) .

[5]张谋喆, 仲梁维.基于UML的销售合同管理系统[J].计算机系统应用, 2011, 20 (3) :23-26.

元数据注册系统 篇2

摘要：对基于XML的多源异构数据融合、遥感数据存储、数据持久化以及用户访问控制技术进行了分析和设计；讨论了元数据管理系统的实现技术、设计思想和系统构架，注重系统的可移植性、可维护性和可扩展性；实现了基于J2EE技术的元数据管理系统。

关键词：Java 2平台企业版；元数据管理；扩展标记语言

随着信息技术的发展，产生了海量的信息。如何有效地管理和组织这些海量信息已经成为一个突出的问题。元数据机制是解决这一问题的有效手段。一些部门已经针对数据在行业内部的应用特点来开发自己的管理系统[1]。目前，在元数据管理系统的建设中存在的主要问题是：基于不同操作系统和数据库的管理平台不可移植、安全性差、难以维护和扩展、缺乏统一的建设模式与内容服务提供方式[2，3]。

以J2EE平台为基础的各项技术的成熟为这些问题提供了良好的解决方案。J2EE是一种利用Java2平台来简化诸多与多级解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE的核心技术是Java2平台的标准版，具有Java语言的特性，是一个开放的、跨平台的结构，提供了健全的意外事件处理机制，具有良好的可移植性和扩展性。

基于J2EE的元数据管理系统具有高效、稳定、可复用、易维护的特点；独立于平台，可以部署于Microsoft Windows、Linux、UNIX等操作系统之上；可对Oracle、SQL Server 2000、MySQL等多种数据库进行操作。但是J2EE涉及的技术种类繁多，在实际应用中要根据需要准确使用，而且基于J2EE的系统需要具有良好的系统设计结构，才能最大限度地发挥优势。尽管基于J2EE平台的系统具有诸多优点，但目前J2EE还没有被广泛应用在元数据管理中。本文提出的基于J2EE架构的元数据管理系统建设方法和应用实例，是将J2EE引入元数据管理的一个初步尝试。

1关键技术研究

1．1基于XML的多源异构数据融合

各个部门采用了不同的元数据存储方式。由于缺乏统一的标准，很难对这些元数据进行有效的管理和发布。必须实现多源异构数据的融合。

采用简单文本文件作为中间介质的信息交换方法不能描述数据的结构，不适合用来进行复杂的元数据交换。XML技术实现信息交换与共享已经成为一种发展趋势。孙君明等人[4]对基于XML的数据交换技术进行了研究。XML是采用线性语法描述树状结构的标志语言。作为一种数据交换的中间件，XML具有跨平台、结构化和自描述性强的特点。

用XML实现多源异构数据融合的过程如图1所示。

在图1中，首先各地的数据提供者通过浏览器将数据传送给服务器，由服务器端的XML引擎将这些数据转换成标准的XML文档；再由一些服务组件根据需要对XML文档进行处理，如建立索引等。这样，多源异构数据就被转换成了具有统一标准的XML文档；通过对这样具有固定结构的XML中间件的解析，实现从XML文档到数据库的转换，完成了多源异构数据的统一存储[4，5]。进行信息发布时，根据客户端的查询条件在数据库中提取相应的结果集，形成XML文档，将该文档发送至客户端；由客户端的格式化工具解析该XML文档，显示在客户端。

1．2遥感数据的分块存储

遥感数据（如DEM、TM、ASTER等）具有数据量庞大的特点，应用数据库中的大数据类型存储，如Oracle 9i中的Blob、SQL Server 2000中的Image。但是如果将它们直接存入数据库中会造成系统效率低下;可采用一种分块存储的策略，将原始数据分割成大小一致的若干块，一块一块地进行存储。分块大小要根据磁盘的读写性能和网络的传输性能确定，过大或过小都会导致系统运行效率低下[6]。每块数据以一条记录的方式进行存储，包含数据的编号、经纬度、步长、时间等信息，并且建立索引。

1．3数据持久化

为了能使系统部署在任意数据库系统上，加入了一个持久化层，作为连接Java应用和关系数据库的通道。为数据库中的每张表建立一个Java对象，定义好对象与表之间的对应关系，只需对Java对象进行操作，不用关心SQL语句和系统最终使用的数据库。持久层作为一个中间件，封装对数据库的操作，提供接口，隐藏数据访问的细节[7]。

1．4用户访问控制

元数据的使用人员级别复杂，用户管理困难。使用RBAC(Role－Based Access Control，基于角色的访问控制)模型，可以提高管理的效率和安全性。RBAC在传统的用户——权限模型中引入了角色的概念。角色是一组用户的集合，也是一个授权的集合，它将一组用户与权限联系起来。一个角色可以与多个用户对应，一个用户可以拥有多个角色，每个角色可以执行多种权限，每个权限可以被多个角色共享。对一个用户授予相应的角色，使用户可以进行相应的操作[8]。引入角色可以使系统的安全机制具有很大的灵活性，减少了权限管理的负担和代价，同时也增强了系统的可维护性。

2元数据管理系统的设计

使用本系统的各部门实际情况不同，系统可能被部署到不同的平台上，而且需要对该系统进行一定的扩展和改进。所以在系统设计上，需要充分考虑到系统的可移植性和可扩展性。

2．1系统设计

本系统基于J2EE平台，是一个浏览器/服务器（B/S）结构的系统，具有J2EE平台可以跨系统使用的特性，采用MVC（Model－View－Controller）应用框架。MVC设计框架的内部原理比较复杂，将MVC运用到应用程序中会带来大量的额外工作，增加应用的复杂性。但是MVC可以轻松地实现程序代码与HTML的分离，而且MVC的三个模块相互独立，可以构造良好的松耦合构件，提高应用系统的可维护性、可扩展性、可移植性和可复用性。从长远的应用考虑，应使用ＭＶＣ设计框架[9]。

本系统在传统的B/S三层结构上作了一定的改进。

（1）表现层。在该层使用Struts框架。Struts是一个MVC模式的表现层应用框架。浏览器向Web服务器提出请求后，Web服务器会把请求交给控制器处理。ActionServlet控制器根据请求的不同，将它们转发给不同的Action实例。Action实例在这里充当了用户请求与业务处理逻辑之间的适配器，它只负责控制整个程序的流程，不关心具体业务的实现，实现了请求与业务逻辑的分开。本系统使用一个高效的Action类——DispatchAction类。只要继承该类，就可以在一个Action中集成多个业务方法，有利于系统的维护。在视图显示方面，其大量使用了Struts标签，用来控制显示的逻辑和内容。由于不同平台采取的编码方式不同，在进行系统移植时很容易出现中文乱码问题。在这里使用一个可插拔式的过滤器，实现对请求和响应的预处理及后处理，很好地解决了字符编码问题，使系统可以在不同的平台上进行移植。

用户请求和应用逻辑。在处理之前，将所有涉及到表现层的数据结构替换成更加通用的数据结构类型；使用通用的、与表现层无关的数据结构在这两层之间传递参数。表现层方法提交的参数类型主要是HttpServletRequest和HttpServletResponse；使用这样的参数会增加系统的耦合性，不利于代码的重用，所以要将它们处理成通用的数据类型，如数组。这一过程在Action适配器进行转发之前完成，提供给业务层的参数是通用的数据类型[10]。业务层方法之间的通信也通过通用的参数类型进行，使得每个业务方法均独立存在于系统之中，在很大程度上减少了系统的耦合，提高了可复用性。

（3）数据层。为了实现数据库访问细节与业务层的分离，引入持久化层。

为了使系统具有较好的可维护性、可移植性和可复用性，采用以上的设计思想，以搭建一个逻辑清楚、功能明确、模块化程度高的元数据管理系统。

2．2工作流程

用户通过浏览器（IE/Netscape）向服务器提交请求，请求经过过滤器处理后再提交给控制器ActionServlet；控制器根据请求的类别将它们转发给不同的DispatchAction类。该类中的方法对参数进行处理后调用不同的业务逻辑对请求进行分析处理，处理后得到的信息通过视图显示在用户浏览器上。

3基于J2EE的元数据管理系统的实现

根据本文提出的设计思想，实现了一个元数据管理系统——基于J2EE的小城镇元数据管理平台。本实例以J2EE平台为基础，Tomcat 5.0为服务器，可以使用Oracle 9i、SQL Server 2000、MySQL数据库，使用了ORM（Object－Relation Mapping）模式的持久化层中间件Hibernate，以Eclipse 3.0为开发平台。在系统实现过程中，使用了以J2EE平台为基础的各项技术，遵循Java2标准平台的编码标准，注重系统的可扩展性和可维护性。系统的XML引擎采用了DOM（Document Object Model）和SAX（Simple API for XML）。DOM负责XML文档的生成和修改；SAX对XML进行解析。

小城镇元数据管理平台的功能主要分为管理与检索两部分，可以实现对矢量数据、栅格数据、文档数据、原始试验数据、报表数据和模型数据的管理与检索；用户管理可以对用户进行权限设置；系统管理功能可以提供系统运行的日志和帮助文件。

4结束语

基于J2EE的元数据管理平台，具有良好的跨平台特性；解决了多源异构数据的融合、遥感数据的存储、数据持久化和用户控制访问问题；在设计和实现过程中遵循J2EE的设计模式，具有良好的扩展性和维护性；功能模块具有低耦合的特点，极大地提高了代码的可复用性；可对元数据进行有效管理，实现信息的共享发布，广泛地应用在各个领域。在如何提高系统的安全性方面还有待于对其进行进一步的研究。

参考文献：

［1］吴洪桥，何建邦，池天河，等.基于Internet的元数据管理模式研究[J].计算机科学,2003,30(4)：89－91.[2]李广乾.小城镇信息化建设的基本思路[J].信息化建设,2005(Z1)：24－26.

[3]赵春江，杨信廷.加强信息技术研究和开发促进小城镇健康发展[J].小城镇建设,2005(1)：22－23.

[4]孙君明，郭红.基于XML的异构信息交换技术研究[J].计算机应用研究，2003,20(1)：70－72.

[5]李德冠，陈梦东.一种基于XML的数据交换系统的设计和实现[J].微机发展,2005,15(12)：12－14.

[6]朱雷，潘懋，李丽勤，等.GIS中海量栅格数据的处理技术研究[J].计算机应用研究，2006,23(1)：66－68.

[7]孙卫琴.精通Hibernate：Java对象持久化技术详解[M].北京：电子工业出版社,2005.

[8]范会联，李献礼.基于Struts框架的Web信息系统中RBAC的实现[J].计算机时代，2005(12)：33－34.

[9]孙卫琴.基于MVC的Java Web设计与开发[M].北京：电子工业出版社,2004.

元数据注册系统 篇3

关键字:元数据,信息资源,电子政务,数据库

近年来,我国电子政务信息化建设取得了巨大进展,信息资源总量不断增加,质量逐步提高,在现代化建设中日益发挥重要作用。但随着电子政务信息资源的膨胀,政务信息资源的管理和共享大都是建立在各自独立的领域和范围内,系统的应用仅以满足各自领域的信息获取为目的,相互之间没有联系,造成了政府部门之间所谓“信息孤岛”的问题。在信息化社会里,信息已成为一种重要战略资源。信息资源是与物质、能量同等重要的现代战略资源。信息资源的开发利用是国家信息化的核心任务,其开发利用水平直接关系国民经济社会信息化的全局,政府信息资源是国家资源,是全社会的公共资源和公共财富,政府信息共享是促进当前我国信息资源开发利用的重点。将元数据应用在政务领域,从各政府部门的信息系统中采集信息资源可以形成用户资源视图,通过元数据描述和管理技术可以构建政务信息资源元数据库,元数据是描述某一资源的结构化数据。它提供有关资源存储、资源分类、资源交换、资源访问等方面的信息,便于用户查询、检索和访问相关信息资源。

1元数据库在政务信息资源注册管理系统中的应用

1)注册流程和注册规范

政务信息资源注册的流程如下所述:提交机构按照政务信息资源提取规范收集、发现、提取本部门的政务信息资源,形成资源视图;提交机构按照《政务信息资源统一描述规范》对注册的政务信息资源进行元数据描述;由主管部门对政务信息资源元数据进行内容审查;提交机构将政务信息资源元数据提交到注册机构并申请注册;注册机构验证注册申请,并决定是否受理此申请。如果受理了申请,注册机构就给资源分配临时的资源标识符,将注册状态注上“已受理”,并通知提交机构受理的情况;受理后注册中心对政务信息资源元数据进行测试和审核,如果元数据的格式或者内容没有通过测试和审核,注册机构通知提交机构相关的出错信息和处理意见;审核通过后,注册中心给注册资源分配正式的资源标识符,并将注册状态注上“合格”,注册机构将政务信息资源注册标识符及注册元数据信息,录入政务信息资源注册数据库,并通知提交机构和主管机构注册成功;提交机构与其主管机构收到注册成功通知后,要求对项目进行检查,确认政务信息资源有效,如果查出有错,应立即通知注册机构。如果核实无误,政务信息资源的注册状态注上“有效”,表示此申请注册的政务信息资源处于可用状态。对审核通过且确认有效的政务信息资源,注册机构通过政务信息资源目录服务系统对外发布。政务信息资源注册管理中主要有资源提交者、注册管理者和资源使用者分别完成信息资源提交、资源注册管理和资源的检索利用。资源提交者从本部门业务系统和数据系统中提取信息资源,编目形成资源描述元数据:资源注册者将受理的资源元数据信息注册到政务信息资源元数据库中,并通过目录服务平台生成资源目录,提供查询服务。资源使用者通过政务信息资源目录交换平台对政务信息资源进行检索、查询和获取。

2)元数据库对注册过程的要求

注册过程的目的是为了将信息资源注册保存到信息资源元数据库中,注册系统和元数据库是相互支持的模块,为了更好的管理元数据,在注册过程中就应该做好下列工作。

(1)政务信息资源的分类分级

政务信息资源涉及面广,覆盖了几乎一切国民经济部门,跨社会各行各业,所以其数量巨大,种类繁多。为了对政务信息资源进行有效地管理,对政务信息资源进行合理的分类是至关重要的。对政务信息资源有很多种分类方法,例如根据政务信息资源所属的政府部门划分,根据政务信息资源服务的对象划分,根据政务信息资源的安全等级划分等。为了方便对政务信息资源进行注册和管理,在政务信息资源的注册管理系统中,采用一定的分类方案对政务信息资源进行分类,具体的分类方案可以参考国家标准《政务信息资源目录体系第四部分》中提供的三种分类方案:按主题的分类方案,按行业的分类方案,按服务的分类方案和按资源形态的分类方案。

(2)电子政务信息资源的验证与测试

注册机构要对已受理的政务信息资源的元数据进行验证和测试,验证工作主要是进行一些基本的检查,以减轻审核阶段的工作,测试主要是对元数据的语法、格式进行检查。其工作大致包括:检查各个描述元素的名称和属性是否符合规范;检查资源实例XML文档元素的层次结构是否符合标准规范;检查元素的取值是否符合标准中规定的编码体系方案;验证网络资源是否可以通过信息资源元数据提供的访问方式获取;验证不合格或者测试不通过,通知提交机构测试结果和修改意见,并要求提交机构修改后重新提交。

(3)电子政务信息资源的审核

对“已受理”的政务信息资源,注册机构要进行审核。审核要作如下工作:检查资源存放地址是否正确,即检查资源是否存在;资源描述信息中的题目等属性与资源实体中的属性是否相符;资源描述信息中的关键字是否符合规范;审核通过,分配正式的资源标识符,并将注册状态注为“合格”;审核没通过,将注册状态注为“不合格”,并通知提交机构审核结果和修改意见,由提交机构修改以后重新提交。

经过上述过程,注册机构将通过验证和测试的政务信息资源描述元数据存储到政务信息资源元数据库中,政务信息资源处于“有效”状态。

2元数据库在目录交换系统中的应用

在政务信息律源目录交换体系中,元数据库担负着及其重要的作用,公共资源目录和交换目录都是建立在相应的元数据库上的。在元数据操作的基础上将提供者所注册的信息资源信息表示成目录形式为使用者服务。借助信息资源目录体系,就可以实现在政府部门分布式海量数据中的信息定位、发掘和提取,迅速地从其所涵盖的各委办局的信息中发现与其需求匹配的信息资源,进而获取并利用,实现决策支持、协同办公和信息上传下达等作用,实现信息资源的有效整合;通过目录体系中对各类信息资源进行描述、引用等,为分散异构(各委、办、局)的各类信息资源的共享交换提供基础性支撑;按照统一的规格和方式实现对不同类型的各类信息资源的分类描述。

参考文献

[1]赵亮,楼向英,张春景等,元数据应用:语义、结构与句法.图书馆杂志.2004, 7:49-55

元数据注册开放论坛即将召开 篇4

由ISO/IEC JTC1/SC32主办,国家标准化管理委员会承办的JTC1 2010年会将于2010年5月19～28日在我国昆明市召开。会上,将召开ISO/IEC JTC1/SC32(数据管理与交换)全会、SC32/WG1(电子业务)、SC32/WG2(元数据)、SC32/WG3(数据库语言)、SC32/WG4(SQL/多媒体和应用包)等SC32全会和工作会议。

在SC32全会之前,中国电子技术标准化研究所将于5月1 7～1 8日承办第十三届元数据注册开放论坛(OFMR2010),论坛主题是“元数据和云计算”。目前已有来自于美、英、法、德、加拿大、澳大利亚等国家的1 00余名专家和代表注册参加开放论坛。

元数据注册系统 篇5

元数据(metadata) 是用户访问和使用数据的依据,元数据管理是数据管理和服务过程中的重要组成部分。海洋领域的观测数据多依赖不同的观测仪器和平台, 往往空间分布零散、时间不连续,对海洋观测数据的管理更是离不开与之对应的元数据。简而言之,元数据是 “描述数据的数据”,它给出了数据的内容、 质量、状况及其他特性的信息。海洋观测元数据与数据本身具有同等重要的意义,清晰完整的元数据可以准确地描述数据的获取信息,有力的保证数据的可追溯性,对于海洋和大气领域的数据交换和科学研究具有极为重要的价值。

海洋学和海洋气象学联合技术委员会(JCOMM)的数据管理协调组(DMCG) 非常重视海洋学和海洋气象学资料元数据信息的管理。在海洋气候学数据管理方面,数据管理协调组曾明确要求海洋气候学专家组(ETMC) 考虑数据获取系统(包括系泊浮标、漂流浮标、 海上平台等)的综合元数据库的开发,该元数据库要用于气候档案库已有的海洋数据获取系统观测数据的充分而准确的解读,以支持全球气候研究以及广泛的海洋气候应用[1]。

2 ODAS元数据管理中心(ODASMS)

2.1建立背景

在2001年6月召开的JCOMM-I第一次会议上,在对JCOMM职权范围的志愿观测船(VOS)、全球温盐剖面计划(GTSPP),以及各类浮标数据的管理活动进行审查之后,委员会决定海洋气候观测的海洋数据获取系统采用由联合国以前的海洋气象委员会(CMM)起草的元数据格式。海洋数据获取系统(ODAS)元数据主要是针对海洋资料获取系统,如系泊浮标、 漂流浮标、海上平台等获取资料的元数据描述, 侧重于描述观测资料的原始特性,尤其是数据本身在采集时的环境特征,如采用的观测平台特征、仪器特征(精度、技术指标、环境和状态等)、数据传输特征、传感器运行环境和参数等。该格式已由数据浮标协调组(DBCP)进行了广泛的审查,并在该小组第八次会议上最终通过。 大会请求JCOMM资料管理协调组(DMCG)负责这项任务的实施。

在2002年3月召开的JCOMM资料管理协调组第一次会议上,小组考虑ODAS的综合元数据库的开发,该元数据库要用于气候档案库已有的ODAS观测数据的充分而准确的解读, 以支持全球气候研究以及广泛的海洋气候应用。 会议指出,为了有效地管理ODAS元数据,充分发挥元数据的作用,并保持元数据格式随观测发展而及时更新,实现使JCOMM元数据的业务化管理和服务,需要尽快成立ODAS元数据管理中心(ODAS Metadata Service)。在这次会议上,国家海洋信息中心代表中国主动承担了ODAS元数据管理中心建设任务。小组要求ODAS元数据管理中心与国际海洋数据交换委员会(IODE) 数据交换技术专家组(GETA- DE)密切协作开展ODAS元数据格式和现有的IODE海洋环境数据目录(MEDI)元数据以及其他几种元数据格式比较研究,并在JCOMM资料工作组的协调下,建立ODAS元数据的管理机制,开展元数据的收集、处理、管理和服务,制订相关标准和代码,为JCOMM数据管理和应用提供元数据信息和相关技术的支持。

多年来,国家海洋信息中心承办的JCOMM元数据管理中心在JCOMM资料工作组的协调下,建立了ODAS元数据的管理机制,制订了相关标准和代码, 开展了多种元数据的收集、 处理、管理和服务工作,为JCOMM数据管理和应用提供元数据信息和相关技术的支持。

2.2 ODAS元数据管理

ODAS元数据管理的目标是实现ODAS数据元数据信息的统一管理,保证ODAS元数据的规范性、完整性、有效性和实时性,为资料用户提供统一的访问平台获取资料元数据信息, 并为访问资料本身提供相关导航服务,提高资料的访问效率、使用效率和准确度。

ODAS元数据管理的主要任务是收集全球范围内的各国资料管理机构、国际组织和国际合作项目获取的海洋资料元数据信息, 以ODAS元数据标准为基础进行海洋资料获取系统元数据的处理和管理,建立元数据库,开发元数据处理、管理和服务相关工具,开展长期的维护和更新;建立和维护ODAS元数据管理服务网站,开展元数据发布服务和导航服务。

ODAS元数据管理工作在JCOMM资料管理组协调下进行, 由指定的国家级资料中心(国家海洋信息中心)建立ODAS元数据管理中心,实施ODAS元数据的统一管理和服务。各部分之间的关系见图1。

JCOMM成员和成员国以及国际组织、国际合作项目应按ODAS标准和ODAS元数据管理中心提供的格式进行海洋资料获取系统的元数据收集和整理,并向ODAS元数据管理中心提供。元数据提供方式有两种:一是形成元数据集(多条元数据形成的文件) 通过发送EMAIL、FTP上传和光盘邮寄等方式到ODAS元数据管理中心;二是通过ODAS元数据服务网站提供的操作工具, 直接输入元数据信息, 传输到ODAS元数据管理中心。

在海洋可扩展标记语言(XML)技术还没有统一标准之前,元数据提供者可以根据自己的具体情况确定统一的格式, 如文本文件(txt)、xls电子表格、word表格或DBF等,但要求格式统一。在解决XML标准之后,将实现XML的统一标准和统一格式。

元数据的提供者也是元数据管理中心的主要用户, 可以通过服务网站实时获取所有的ODAS元数据信息,并实现ODAS资料的导航访问,ODAS管理中心将定期向元数据提供者分发元数据目录(FTP、EMAIL或光盘分发), 一般用户则通过网站享用ODAS的元数据信息, 但在数据导航服务过程中会受到权限的控制。

3 ODAS参考数据格式

ODAS元数据标准是由海洋气候学专家组研究开发,主要是针对海洋资料获取系统,如系泊浮标、漂流浮标、海上平台等获取资料的元数据描述,侧重于描述观测资料的原始特性, 尤其是数据本身在采集时的环境特征,如采用的观测平台特征、仪器特征(精度、技术指标、 环境和状态等)、数据传输特征、传感器运行环境和参数等,所以ODAS元数据适用于实时观测数据的信息描述。

ODAS元数据格式采用两层结构的描述方式(图2)。第一层是标题记录,主要是描述数据集源的总体特征和获取环境;第二层是对各类传感器工作环境的详细描述,不同的传感器有不同的描述方式,而且可以根据观测平台的传感器情况,扩展第二层的记录类型。ODAS元数据格式对各种名称都采用代码方式,需要时可以进行代码的扩充和修改。

根据ODAS元数据格式,ODAS元数据库由12个基表构成, 其中一个为标题信息基表,其余的均为数据信息基表。 各基表中的数据项名称和含义与原格式中的完全一致。 在各基表中仅增加一项唯一标志。本研究中仅给出标题信息表的具体格式(表1), 各数据信息表以其数据要素类型而各不相同, 在此不一一累述。

4 ODAS元数据产品的研制和发布

自2003年至今,国家海洋信息中心一直承担着JCOMM/ODAS元数据管理中心的建设和业务化运行服务的任务。为实现ODAS元数据的有效管理和服务,并保持其连续性,国家海洋信息中心建立了ODAS元数据收集、处理、 管理和服务的业务化运行机制,成立业务化系统建设和运行小组,采用SQL/SERVER关系型数据库管理系统,按照ODAS元数据格式, 设计和建立ODAS元数据库结构,并利用SQL/ SERVER操作工具建立了ODAS元数据库和业务化运行系统。

在ODAS元数据管理方案基础上完成了JCOMM/ODAS元数据管理中心运行方案设计, ODAS元数据信息管理数据库和元数据管理中心网站的设计开发。2004年JCOMM/ODAS元数据管理中心网站正式开通并提供元数据发布和导航服务(www.odas.org)。网站发布内容主要包括:ODAS元数据管理中心介绍;元数据相关标准和格式;元数据库在线查询、检索和浏览,数据导航服务;JCOMM元数据信息管理和服务工作动态;JCOMM成员国相关海洋、 气象网站的友情链接等。

在JCOMM管理委员会的协调和资料管理协调组的支持下,首先将数据浮标协调组(DB- CP) 全球漂流浮标计划的元数据信息由JCOMM海上观测平台支持中心JCOMMOPS通过FTP方式在JCOMM网站发布,每月更新一次。JCOMM/ODAS元数据管理中心在深入研究DBCP元数据和ODAS元数据标准的基础上, 2005年9月,完成DBCP元数据信息提取的详细工作流程设计,同时完成了DBCP元数据信息的下载、质量控制、信息提取和分析软件系统开发,并投入业务化运行,实现了DBCP元数据信息的业务化提取和发布服务。与此同时, 利用中国Argo资料中心的有利条件,进行深入研究之后又成功将Argo浮标观测平台的有关元数据信息进行提取,并针对较为复杂的处理过程程序设计,实现了从Argo浮标观测元数据到ODAS元数据转换的业务化运行,网上发布服务。JCOMM/ODAS元数据管理中心积极扩展元数据信息源, 利用全球海平面观测计划(GLOSS)成员国的有利条件,2007年又完成了从GLOSS资料提取ODAS元数据信息并通过该中心网站发布服务的工作。

目前JCOMM/ODAS元数据管理中心共提取和发布的元数据量已超过1.2万个平台的元数据记录,包括剖面浮标、漂流浮标、锚系浮标和海上平台等。在此基础上,业务化制作和网站动态发布ODAS元数据可视化产品, 包括ODAS最新状态图,ODAS分布图(按国家或观测平台类型分类)等。

5 JCOMM/ODAS元数据管理面临的挑战和机遇

JCOMM/ODAS元数据管理中心旨在收集JCOMM各成员国、国际组织和国际合作计划/ 项目的ODAS元数据,但在运行的多年间一直面临ODAS元数据信息源收集渠道不通畅,元数据信息量不足的问题。至今仅实现了Argo计划的元数据业务化运行;JCOMM DBCP元数据信息业务化运行服务截至2006年2月, 此后DBCP元数据信息源不再更新;GLOSS元数据信息源提取了包括观测平台和仪器特征等信息, 但还没有包括GLOSS计划的较完整系统的元数据信息,收集不够完整,使用价值低。加拿大海洋环境数据中心非漂流ODAS元数据也只有2003年以前的元数据信息。JCOMM-III大会虽然要求成员国提供ODAS元数据, 并明确JCOMM/ODAS元数据管理中心应加大收集相关国际合作项目的元数据信息[2],但到目前为止尚未获取到机会船(SOOP)、 志愿观测船(VOS)、国际综合海洋大气数据集(ICOADS)、 OceanSITES等JCOMM重要国际合作项目元数据。至今没有JCOMM成员及成员国向JCOMM/ODAS元数据管理中心提供水温仪器元数据,也没有收集到水温以外的其他要素的元数据信息。JCOMM第三次大会形成了有利于ODAS元数据发展的建议,但实施起来仍然有一定的难度,因此,上述存在的问题仍未得到有效解决。

2011年,JCOMM提出了一个新的设想, 即发展一个全球范围的海洋气候数据系统(MCDS)[3],将全球的海洋气象和海洋气候数据有效整合起来,并通过建立10个左右的全球海洋和海洋气象资料中心(CMOC) 来实现数据和数据产品的业务化处理和发布服务。 根据JCOMM新提出的海洋气候数据系统10年规划, JCOMM/ODAS元数据服务系统(ODASMS) 已经成为MCDS的重要组成部分,并已提出有意将ODAS元数据管理中心与MCDS的一个全球海洋和海洋气象资料中心合并运行的设想。 2012年2月,国家海洋信息中心正式向联合国教科文组织政府间海洋学委员会提交了志愿承担全球海洋和海洋气象资料中心的承诺声明[4]。 在2012年5月的JCOMM第四次大会上,委员会宣布ODASMS计划停止,并同意国家海洋信息中心作为CMOC中心试运行,将原ODAS元数据工作并入CMOC中心一并运行[5]。这一举措,将实现数据和元数据的同时处理和管理, 可以从根本上解决多年来ODASMS的元数据信息源收集、管理和服务的问题。

我们有理由相信,在全球海洋气候数据系统的框架下,ODAS元数据服务将迎来新的春天。元数据管理将得到巩固和流线化发展,其业务服务将通过CMOC网络实现与全球海洋气象和海洋气候数据、元数据、相关产品的直接连接, 真正意义上实现数据与元数据的统一管理。

摘要：海洋元数据的重要性越来越受到全球海洋界的认可。文章介绍了由世界气象组织(WMO)和联合国教科文组织政府间海洋学委员会(IOC)海洋和海洋气象联合技术委员会(JCOMM)发起的海洋数据获取系统(ODAS)元数据服务计划发展始末,及其在新的海洋气候数据系统(MCDS)框架下的未来展望,详细给出了ODAS元数据的标准格式以及国家海洋信息中心作为ODAS元数据管理中心所制作的产品和提供的服务。

元数据注册系统 篇6

本文简要介绍元数据的概念和它在数据仓库中的应用，提出了一个新的基于元数据的数据仓库的组织形式，并结合Agent技术将这种数据仓库应用于智能决策支持系统中，使之更有效地进行决策。

1 元数据概述

元数据最本质、最抽象的定义为：关于数据的数据(data about data)。元数据是可以用来定义存储在数据库中的数据形式的数据。换句话说，元数据包括了对系统自身有用的各种对象的细节信息。它是一种广泛存在的现象，在许多领域中有其具体的定义和应用。

在数据仓库领域中，元数据被定义为：描述数据及其环境的数据。一般来说，它有两方面的用途。首先，元数据能提供基于用户的信息，如记录数据项的业务描述信息的元数据能帮助用户使用数据。其次，元数据能支持系统对数据的管理和维护，如关于数据项存储方法的元数据能支持系统以最有效的方式访问数据。从数据仓库管理人员来看，元数据是在数据仓库中所有内容和所有处理过程的一个全面的仓库和文件;从最终用户的观点来看，元数据是数据仓库中所有信息的路标。只要是支持和管理数据仓库操作的任何所需的信息，元数据都将包括。具体来说，在数据仓库系统中，元数据机制主要包含以下内容：(1)描述哪些数据在数据仓库中;(2)定义要进入数据仓库中的数据和从数据仓库中产生的数据;(3)记录根据业务事件发生而随之进行的数据抽取工作时间安排;(4)记录并检测系统数据一致性的要求和执行情况;(5)衡量数据质量。

元数据是抽象的数据，但元数据的重要性也正体现在其所包含的信息中。例如，元数据用作目录，可以帮助DSS分析者对数据仓库的内容定位;当数据由操作环境到数据仓库环境映射时，作为数据映射指南;对于用在当前细节数据与低度综合的数据之间及低度综合的数据和高度综合的数据之间的汇总算法。如果没有元数据，数据仓库中的数据是完全孤立着的，元数据正如一座桥梁将他们联系起来。

2 基于元数据的数据仓库模型

本模型在将元数据应用于数据仓库的同时，设计了5种功能Agent对数据进行查找和获取，使之更有效地将元数据与数据仓库中的数据进行匹配。

2.1 基于元数据的数据信息查找与获取

为了更有效地管理数据仓库中大量的数据，本文设计了一种基于元数据的数据仓库模型，在这个模型中，设计了5种功能Agent来完成对数据的查找获取任务：数据读取Agent，数据读取控制Agent，数据映射Agent，位置查找Agent，位置查找控制Agent。

位置查找Agent和数据读取Agent接收数据查询请求，将其解释成一个计算机可识别、可比较的数据请求任务，前者将该任务传递给位置查找控制Agent，而后者则将该任务传给数据读取控制Agent。

位置查找控制Agent得到数据请求任务后，根据元数据信息，连接到元数据库，在元数据库中查找匹配目标数据的组成及其位置信息，并将获得的目标数据的组成和位置信息交给数据读取控制Agent。

数据读取控制Agent得到目标信息的组成及其位置信息后，再将所得结果交给数据映射Agent。数据映射Agent根据数据的位置信息及相关要求，与数据仓库进行交互，得到目标数据并返回给数据读取控制Agent。由于目标数据可能分布在不同的数据仓库中，数据读取控制Agent可以按照位置信息将数据按照所属的数据仓库进行归类，并据此将数据读取任务进行划分，将这些数据读取子任务交给不同的数据映射Agent分别访问不同的数据仓库以获得目标数据。这些数据映射Agent可以并行地执行，从而提高了数据读取的效率。

2.2 元数据管理的实现

在数据仓库中元数据不是一成不变的，元数据管理器执行对元数据的管理和维护。元数据管理的主要任务是负责存储和维护元数据库中的元数据，一般来说除了数据源监视器产生的元数据外，其他模块或工具产生的元数据都是通过元数据管理器存入元数据库的。

2.2.1 数据源及数据源监视器

数据仓库的数据来自于多个异构的数据源，它们可以是各种类型的数据库、文本文件，甚至是Web数据。因此对各个数据源的描述是最基本的元数据，主要是在数据仓库建模工具中定义。在数据仓库的运行过程中，数据源中的数据可能会发生变化，这就会使得数据仓库中的数据过期，因此必须进行定期或不定期的更新。

2.2.2 数据仓库建模工具

建模工具帮助用户通过需求分析创建数据仓库的数据模式，同时还要定义模式中各个表的数据来源、数据转换规则、有关的聚集操作等信息，与元数据管理的关系较密切。数据转换的基本规则有：一对一抽取;多对一抽取;混合抽取。

2.2.3 元数据浏览器

元数据管理的目的就是为了给数据仓库的各有关模块或人员提供元数据服务。元数据浏览器可以分门别类地组织和显示各种元数据，供数据仓库管理员或最终用户根据需要浏览或查看他所关心的元数据。当然，并不是每个用户都能浏览所有的元数据，通过用户授权规定每个用户的级别，借此控制每个用户所能看到的元数据。

3 基于数据仓库的智能决策支持系统

基于数据仓库的智能决策支持系统是将数据仓库技术和人工智能技术应用于决策支持系统中，以更加有效地进行决策。以往建立的决策支持系统，大多数都是以关系数据库为基础的，使得数据缺乏组织性，分析效率低下并无法支持灵活多变的分析需求。数据仓库作为一种管理技术，旨在通过通畅、合理、全面的信息管理达到有效的决策支持。

接口Agent与用户进行交互，接受用户决策任务，并将任务交给问题求解Agent;最后再与用户进行交互，对问题的中间结果或最终解决方案予以选择或确认。

信息管理与协作Agent负责协调与控制Agent之间的交互与通讯。

问题求解Agent根据用户决策任务，对任务进行分解，组织各种其他Agent完成各子任务，并对各个Agen的完成结果进行综合，最终形成问题的解决方案。

模型库管理Agent根据具体的决策子任务，从决策模型库中选择一个适当的模型进行解释执行。模型的完整执行可能需要其他Agent进行协作。

知识库管理Agent根据决策任务或模型执行的需要，利用知识或规则进行推理，以获得完成决策任务所需的目标知识或应采取的动作。在此过程中，也需要与其他Agent协作。

数据库管理Agent获取模型执行或推理过程中所需的数据以及元数据。

从上述体系结构可以看出，使用Agent技术，DSS的功能还是一样的，但是在系统的结构、工作方式以及实现的方法等方面，更加简单、清晰，各Agent之间相对独立性比较高，相互之间的关系可以在运行阶段进行设定，而不是在系统设计时预先确定。

4 总结

数据仓库系统可将来自各个数据库的信息进行集成，从事物的历史和发展的角度来组织和存储数据，供用户进行数据分析，并辅助决策支持，为决策者提供有用的决策支持信息与知识。因此，基于这一技术的决策支持系统提供了可取的数据组织方式，为决策人员提供了强有力的支持工具，能有力地推动决策的现代化进程。本文初步提出了一个基于元数据的数据仓库在IDSS中的应用模型，由于系统设计和实现技术的局限性，此模型还需要进一步完善。

摘要：将人工智能理论引入决策支持系统,构成智能决策支持系统。数据库是智能决策支持系统的重要组成部分,本文介绍了元数据的基本概念,将基于元数据的数据仓库技术运用到智能决策支持系统中,提出一个新的智能决策支持系统框架。

关键词：元数据,Agent,数据仓库,决策支持系统

参考文献

[1]Anne J Gilliland-Swetland.Setting the Stage[M]//Murtha Baca(Eds).Introduction to Metadate:Pathways to Digital Information.Los Angels,CA:Getty Publications,2000.

[2]Jill Dyche.Data Warehouse,Metadata and Middleware[J].EAI Journal,2000(9):71-76.

[3]徐立臻,刘安,等.数据仓库系统中的元数据管理[J].计算机工程与应用,2002,38(24):193-196.

[4]史忠植.智能主体及其应用[M].北京:科学出版社,2000.

元数据注册系统 篇7

关键词：元数据,管理信息系统,用户需求,灵活性,可扩展性

1 引言

传统的管理信息系统开发大多从建立数据表结构开始, 然后根据数据表的内容设计窗体并完成各窗体访问数据库的代码编写。这种模式的开发过程, 一方面无法包含项目的全部需求设计, 例如系统的状态无法统一设计, 最终导致每个程序员都可以直接操控系统的状态, 导致整个系统状态运行混乱;同时还非常容易将实体表和关系混合在一起, 造成分析者视觉混乱, 无法正确分析出系统的真正基本实体;另外还会导致软件系统以数据库为中心的编码架构, 进而产生传统过程化编程风格, 难于维护和拓展, 甚至性能低下。

元数据主要描述管理信息系统的数据结构及其界面显示模型。在系统的开发过程中, 通过建立一个元数据管理表管理元数据内容, 通过界面静态生成法和动态生成法, 探讨了基于元数据开发管理信息系统的优缺点。

2 结构

根据系统开发的需要, 本系统大体分为三层结构:模型层、驱动层和应用层。

其中, 模型层主要包括:界面模型、业务流程模型及数据模型。界面模型主要描述界面元素各种物理属性, 如位置信息、大小信息、布局方式、对齐方式、间距控制、垂直间距、字体信息、颜色设置、图片信息;业务流程模型主要描述业务功能相关的各种操作及相互之间的关系;数据模型描述系统中各种资源相关的数据属性及逻辑关系。上述模型的描述全部通过元数据的方式存储在元数据管理表中。

驱动层包括:界面代码生成引擎、业务操作代码生成引擎和数据库操作代码生成引擎。界面代码生成引擎根据界面模型元数据通过中间件技术在运行期生成系统界面;业务操作代码生成引擎根据业务流程模型元数据通过中间件技术完成系统业务功能;数据库操作代码生成引擎根据数据模型元数据在运行期动态生成查询语句和数据操作语句, 实现与数据库的交互访问。

应用层则是在以上两层的基础上, 根据各个功能模块组成的系统单元。

3 实现

3.1 元数据管理

本系统基于Access进行开发, 为方便管理元数据, 特建立元数据表, 元数据表结构如表1所示。

其中, 元数据编码采用层次码, 将数据库中的各表按逻辑关系进行区分, 其部分数据如表2所示。

3.2 实现思路

静态界面生成法的基本思路是:按照元数据表中的内容, 根据Delphi源程序文件的格式自动生成单元文件和窗体文件, 并将生成的这些文件引用到工程文件中, 然后通过手工调整界面元素, 再对源文件进行编译, 生成可执行文件。

Delphi是以工程为中心来开发应用程序的, 即每个应用程序都是一个工程, 由一个或多个文件及工程文件组成。组成工程的几种文件包括:工程文件、单元文件、窗体文件、资源文件、工程选项及桌面配置文件、中间编译单元、备份文件、包文件等。与界面相关的文件主要包括单元文件和窗体文件, 但作为一个完整的工程项目, 在工程文件中对所包含的单元文件要进行指定。因此, 与静态界面生成法相关的文件主要包括工程文件、单元文件和窗体文件。

为保证上述3个文件的自动生成, 首先建立一个文件基类, 并在此基础上派生3个文件类, 如图1所示。

文件基类的定义如下:

其实现代码如下:

3.3 工程文件生成

工程文件以关键字program标识, 工程文件的扩展名为.dpr。为实现工程文件的自动生成, 将工程文件分为4大部分。第一部分为文件的头部, 内容较少且没有什么变化, 详情见头部初始化函数InitialHead;第二部分为单元引用部分, 主要是将工程中引用的文件全部罗列出来, 因此, 在静态界面生成过程中每生成一个单元文件, 就要加入到工程文件的单元统战部分;第三部分可以称为窗体生成部分, 若需要将静态生成的窗体在程序运行时自动创建, 则需要将生成的界面窗体置于窗体生成部分;第四部分为结尾部分, 该部分比较简单, 而且是不变的, 只有两个语句, 详情见工程文件类的文件尾部初始化函数InitialFileEnd。

建立的工程文件类TProgramFileClass, 其定义如下:

其实现代码如下:

3.4 单元文件生成

工程文件以关键字unit标识, 工程文件的扩展名为.pas。单元文件的主要任务是申明本窗体中引用的各个控件, 并实现相关的功能, 文中仅对界面生成的各个控件进行申明。从单元文件的实现过程来说, 可以将单元文件切割为三部分。第一部分为单元文件引用Delphi自带或本工程生成的有关文件, 变化相对较少;第二部分为控件申明部分, 当在窗体中添加一个控件时, 需要在控件申明部分进行申明;第三部分为文件的结尾部分, 变化也较少。为实现单元文件的生成, 建立单元文件类TUnitFileClass, 其定义如下:

其实现代码如下:

3.5 窗体文件生成

窗体文件的扩展名为.dfm, 它的主要功能是控制窗体中各控件的排列布局, 每当添加一个控件时, 需要在适当的位置对该控件的属性进行描述。由于描述控件布局的参数较多, 若全部以参数的形式调用函数的话, 会显得比较复杂, 为此, 建立一个数据结构TComponentParameter, 其定义如下:

为实现窗体文件的自动生成, 建立窗体文件类TFormFileClass, 其定义如下:

其实现代码如下:

3.6 主控程序的实现

主控程序负责读取元数据表中的内容, 并通过上述类的接口, 实现相关界面元素的自动生成, 其实现流程如图2所示。

其实现代码如下:

4 总结

元数据注册系统 篇8

1 数据库操作自动化型元数据

无论是对数据库的信息系统还是对数据仓库的信息系统, 对数据库的操作都是最最核心的部分。对于数据库自动化型元数据给出以下概念:信息系统中实现数据操作动态化、智能化、个性化、交互化的元数据。动态化既包括数据表空间内容进行修改后的动态变化, 也包括用户操作集管理、用户管理、数据表空间结构等一些动态修改。智能化涉及到输入、输出、综合查询等信息系统中所包含的各个层面。个性化主要指的是针对不同用户的要求、权限设定不同的输入输出界面。交互化既包括系统之间的交互也包括系统内部的交互。

2 数据库操作自动化型元数据的特点

从文件系统开始到数据仓库技术这一整个的发展过程中元数据始终贯穿其中, 在信息系统的应用、开发中元数据发挥的作用举重若轻。作为一类元数据, 数据库操作自动化型元数据具有以下几方面的特点:

2.1 可重用性

这一特点是元数据在系统中发挥的主要功能, 元数据通过为系统提供可以重复使用的程序包和工具, 从而减小工作量。

2.2 可扩展性

一方面元数据驱动应用具有很强的自身扩展性, 另一方面元数据可以非常方便的加入到新的领域或者应用之中。如:为了扩展一项新的系统功能, 不须要技术人员改变程序代码, 只须要在原有操作树中添加新的组件功能。

2.3 可互相操作性

在需要存取多个元数据先关信息结构上开发综合借口, 或者应用统一接口在多个系统中, 这样可以大大降低交互操作相关的工作量, 从而提升整个系统的工作效率。例如:一个公司的办文管理、行政监督、领导决策等操作都可以建在一个相同的操作集上, 这样在系统中这些操作就有了一个统一的交互接口。

3 数据库操作自动化型元数据在信息系统中的应用研究

无论是通过理论还是经过实践, 现都已经证实了元数据发挥着重要的作用在实现数据复杂并且规模大的系统的过程中。为了充足的体现在实际操作系统中数据库操作自动化型元数据的表示与应用, 该文参照系统功能实现方面的角度将数据库操作自动化型元数据进行分类, 主要对以下三方面的应用进行详细论述。

3.1 实现系统交互的元数据

信息系统全部解决方案中第一需要解决的问题就是如何实现系统之间的交互, 在处理系统之间交互操作问题时元数据的作用、元数据在操作交互过程中的表示都是目前专家们研究的热点问题。传统的系统交互方法降低了系统的高效性、灵活性、通用性, 为解决这个问题, 我们在信息系统中引入了可视化动态映射的一种方式来表示和管理系统交互的元数据, 该方式方便扩展、便于存取, 且后期维护简便, 只需要维护映射表。通常, 在系统之间发生交互时, 此时应用程序会自动选调与之相对应的属性映射表, 数据转换算子作为一个媒介完成数据的交换功能。在系统中表示交互元数据采用映射表的方式, 体现了元数据可扩展性强、表示方法简单的特点

3.2 管理和维护基础数据的元数据

基础数据是系统实现功能的依据, 这样高效灵活的管理基础数据就成为了系统设计的一个主要目标, 所以我们引入了元数据管理机制的概念。在这个机制中所有与基础业务有关联的元数据最终都采用面向对象三元组的方式来表示, 采用这种元数据的管理和表示方式, 一方面可以大大降低数据库访问的工作量, 另一方面可以实现动态表管理, 这样就方便了系统之间元数据重用和共享的实现。

3.3 控制数据流转的元数据

在信息系统中, 不仅要对数据进行管理, 而且还有一个更主要的是控制数据流 (包含系统和用户两个数据流) 。从用户操作的角度出发, 不同的用户权限不同, 且操作各异。如果将用户的数据操作规则以及操作信息在程序中固化, 那么当用户的规则或者操作变化时, 程序就不可避免的需要变动, 所以提出了控制数据流转的元数据。元数据集就像一个可以扩展的大树, 每一个元数据在树的每一个节点的表示方式采用可变数组的方式。

4 结论

该文提出了数据库操作自动化型元数据, 并对这一概念进行了描述, 同时总结了这一概念的特点, 最后从信息系统开发实践这一角度对数据库操作自动化型元数据在信息系统中的应用进行了详细的阐述。最终表明:在信息系统中引入数据库操作自动化型元数据, 一方面可以很大程度上提升整个信息系统的通用性、灵活性, 另一方面还能够提高信息系统开发的效率。

摘要：近几年来, 随着互联网技术的快速发展以及数据仓库技术的不断进步, 元数据相关方面的研究受到越来越多的学术专家的关注。作者以自己系统开发的实践经验为基础, 在通过对元数据理论的深入研究, 提出了信息系统中数据库操作自动化型元数据的基本概念, 并对它的特点进行了概括, 最后介绍了数据库操作自动化型元数据在信息系统中的应用。

元数据注册系统 篇9

关键词：卫生监督,数据元,标准化

1 背景

2003年SARS的爆发,暴露了当时公共卫生信息系统在信息共享上的诸多弊端,卫生机构因此留下了"信息不畅、决策延误、指挥不灵"的深刻教训。这一教训使我们更加认识到国内的公共卫生信息系统之间存在着严重的信息孤岛现象。为解决这一问题,卫生部发布了卫办发[2003]212号文件--《卫生部关于国家公共卫生信息系统建设工作有关问题的通知》。该文件指出,"卫生监督执法信息系统是目前卫生信息化建设的薄弱环节,也是公共卫生信息系统建设的重要内容",故此卫生监督信息系统的数据元标准化建设,已经作为刻不容缓的工作被提上议事日程。

2 卫生监督信息系统数据元标准化实施

国家卫生部信息中心于2009年6月6日由发布了我国首部关于卫生监督数据集的文献-《中华人民共和国卫生行业标准--卫生监督基本数据集标准(征求意见稿)》。该标准分为《卫生行政许可与登记数据集标准》、《卫生监督检查与行政处罚数据集标准》、《卫生监督机构与人员数据集标准》三部分内容。其规范性的获得了专家的认同,并认为:数据集标准是信息化建设的基础;《卫生监督基本数据集标准》是实现各地卫生监督信息系统的互联互通、信息共享和业务协同的重要保障;同时,《标准》的出台,有助于对全国各地卫生监督信息化建设起到规范和引导作用,避免重复建设和浪费[1]。

数据标准化工作是信息系统建设的基础工作。数据工作的无规则性,必然会导致系统的低效能和资源的浪费。长期以来,我国公共卫生信息系统的建设缺乏整体规划,缺乏对公共卫生数据的标准定义与规范,导致了不同系统之间的数据难以交换、共享,也造成了资源的极大浪费。公共卫生数据元的标准化,不仅要对数据自身进行"名、型、值"的定义,还要找出数据之间内在与外在间的关联关系,这将对构建高效稳健的公共卫生数据模型起到积极的作用[2]。

课题组在开发中山市卫生监督信息系统时,尝试执行了《中华人民共和国卫生行业标准-卫生监督基本数据集标准(征求意见稿)》,并严格遵守国际和国内标准化组织已经颁布的各项数据元和代码标准。由于各项数据自身在"名、型、值"几个方面都实行了标准化参见图1,使得系统的后续模块开发和与其他信息系统的链接平滑方便,特别是在综合查询和数据分析阶段,基本消灭了字段名和字段值域的不确定性。

3 卫生监督基本数据集标准"应用及扩展

2009年7月,中山市卫生监督行政处罚子系统项目组将《卫生监督基本数据集标准》作为数据库开发标准。遵照"基本数据集"已经确立的一系列的数据元及其值域,在数据库建立过程中,根据卫生监督执法文书的业务逻辑对数据元进行仔细的分类,然后把标准数据元用作数据表中对应数据项的字段。另外为每一个已规定值域的标准数据元制作一张对应的字典表,把所有值域作为记录录入字典表中。在标准的指引下,提高了数据库建立的效率,同时也避免了重新设计字段所需花费的时间,实现了国家所提倡的避免重复定义。

作者在开发过程中发现《卫生监督基本数据集标准》并不能完全覆盖行政处罚子系统中的所有所需字段。在行政处罚各类文书中均存在很大一部分的所需字段未能与国家标准匹配。因此,有必要对国家《卫生监督基本数据集标准》进行扩展。

首先,从行政处罚各类文书中通过建模分析、确立关心"对象"。通过对象类的特性以及相关表示的分析、归纳和整理,提取具有共性的数据元。根据各数据元的通用属性和特有属性对数据元进行分类。根据分类以及数据元的属性对数据元进行以及命名。

然后根据《卫生监督基本数据集标准》制定扩展的编码规则如下:(1)内部标识符使用HIB02开头,代表卫生监督行政处罚标识符;(2)后三位中的第一位为分类标识位(标识位具体规则见表1),后两位为流水号。(3)数据元值的数据类型、表示格式以及数据元允许值参照《卫生监督基本数据集标准》制定。

最后对制定的数据元进行整理、修正,得出最后用于系统中的扩展数据元(部分扩展内容见表2)。

五、结束语

数据元标准化是避免出现信息孤岛现象的有效方法。虽然卫生监督信息系统的数据元标准化研究才刚刚起步,但也已经具有全国的标准。在中山市卫生监督信息系统项目实施中体现了《卫生监督基本数据集标准》应用的初步效果,同时项目中也根据实际对标准进行了扩展。希望以上工作能促进卫生监督信息系统的数据元标准化普及。

参考文献

[1]科学数据共享工程办公室.数据元标准化的基本原则与方法[M].北京:中国标准出版社.2006.2.