元数据管理

元数据管理（通用12篇）

元数据管理 篇1

0 引 言

近年来, 随着蛋白质组学技术的普及和基础研究的深入, 生物信息学正面临一系列新的挑战。对高度复杂的海量蛋白质组学实验数据进行存储、共享与整合即是其中最重要的问题之一。各个数据源在物理上的分布、结构上的互异以及语义上的差异成为了对实验数据进行共享与整合的三大瓶颈。

各个数据源的元数据不仅包含了数据的名称、类型等信息, 还提供了数据的上下文描述信息, 如果将各数据源的元数据按照一个统一的标准提取出来集中存放在一个元数据库中, 将集成的元数据信息与用户建立的用户模式的相应字段进行关联, 就能够通过解析用户模式得到对应的各数据源数据信息;将获得的各数据源查询结果进行连接、合并等操作, 并按用户模式进行输出, 就能够实现数据的共享和整合。根据以上分析, 课题组提出了基于元数据的蛋白质组学数据资源共享与整合方案, 并在此基础上已经实现了针对关系数据库中各异域异构的源数据库中的元数据信息集成到CWM的元仓库模型中。但是元仓库的管理员并不能控制源数据库 (以下的源数据库均为关系数据库) 中的元数据的变化, 如果源数据库的元数据信息发生了改变, 而元仓库不能进行及时更新同步的话, 就有可能造成元数据的悬挂, 对用户的查询结果产生不可估量的影响。如何捕获源数据库中的结构变化信息, 并将该元数据追加到元数据仓库中去, 成为解决问题的重点。

1 现有同步策略的分析与选择

目前关于数据同步策略的研究大多针对数据库中数据的变化, 而不是针对源数据库结构的变化, 但其思想可以借鉴。数据同步的基础是对象变化捕获, 它直接决定了数据同步的更新方式和选时方式。变化捕获不仅要获得复制对象的变化序列或当前映像, 还要在对等式复制时提供尽可能详细的控制信息。通过对当前使用捕获方法的综合分析, 目前主要有6种基本变化捕获形式, 它们是:基于快照法;基于触发器法;基于日志法;基于API法;影子表法;变更轨迹表法。由于基于快照发、影子表法和变更轨迹法的核心思想是变化后的数据库信息与原数据库信息进行比较, 最终得出变化的结果, 这种方法效率比较低下, 而且主流的数据库管理系统并没有提供关于数据库结构的快照信息, 因此这三种方式不太适合对数据库结构变化的捕捉;基于API法主要适用于小型的非关系型的数据库, 并且其是无法捕捉到的那些不经过API的操作;基于触发器法和基于日志法这两种方法运行的效率和通用性都比较高, 但基于日志法的实现方法相对而言更加复杂。在综合分析上述6种方法的基础上, 考虑到目前课题组主要考虑关系数据库的集成, 并且各主流的RDBMS如SQL Server, Oracle, MySQL, DB2等都提供了DDL (该触发器主要在响应数据定义语言语句时执行存储过程) 的触发器, 这里选择基于触发器法来捕获数据库结构的变化信息。这样可以利用DDL触发器来捕捉类似“用户建立新表”这类结构变化操作。

2 基于DDL触发器的元数据同步策略设计

经过以上分析, 最终设计了一个基于DDL触发器的元仓库与源数据库的元数据信息同步策略, 其基本思想如图1所示。该方法首先通过各关系数据库的DDL触发器捕获到其元数据的变化信息并保存到源数据库结构变化信息表中, 当元仓库的管理者向各数据源发送同步请求时, 将信息表中的信息经过SQL语句清理缓冲器整理后, 通过网络传送到管理元仓库的服务器中, 元仓库服务器最终经过词法分析器将源数据库的结构变化信息更新到元仓库中。

2.1 DDL触发器介绍

DDL触发器是一种特殊的触发器, 它在响应数据定义语言 (DDL) 语句时触发。它们可以用于在数据库中执行管理任务, 例如, 审核以及规范数据库操作。使用DDL触发器, 可以达到以下几种目的:第一, 要防止对数据库架构进行某些更改。 第二, 希望数据库中发生某种情况以响应数据库架构中的更改。 第三, 要记录数据库架构中的更改或事件。与标准的DML触发器一样, DDL触发器在响应事件时执行存储过程。 但与标准的DML触发器不同的是, 它们并不在响应对表或视图的UPDATE, INSERT或DELETE语句时执行存储过程。 它们主要在响应数据定义语言 (DDL) 语句执行存储过程。 这些语句包括 CREATE, ALTER, DROP, GRANT, DENY, REVOKE和UPDATE STATISTICS等语句, 然而这些语句正是引起源数据库的元数据信息改变的操作, 所以通过DDL触发器就能够方便地获得源数据库的结构变化信息。

2.2 源数据库变化捕捉器的设计

首先根据源数据库不同的DBMS编写相应的模块, 通过该模块调用DDL触发器, 将源数据库中的结构变化的信息保存到源数据库结构变化信息表中。以关系数据库中的SQLServer为例, 可以通过在其内部建立DDL触发器捕获捕获其的结构变化信息, 例如:特定数据库中某些表的信息变化, 表的删除、添加和表的属性字段的更新等, 都可以通过DDL触发器捕获到。在数据库中建立好一个DDL触发器后, 调用SQLServer系统自带的函数 ChangeCatch () , 就可以捕获有关激发 DDL 触发器的事件的信息, 并将其保存到ChangeInfor日志表中。但是ChangeCatch () 函数捕捉到的是xml 值, 而这里需要的是SQL脚本, 因此要采用以下的命令对其进行解析:

SET@cmd=LTRIM (RTRIM (REPLACE (@cmd, ″, ″) ) )

这样当对源数据库进行修改时, DDL触发器就会将修改的信息捕捉, 并保存到数据库的ChangeInfor的数据库结构变化信息表中。下面的数据, 是通过以上方法在SQLServer数据库中捕获到的结构变化信息的SQL脚本, 其结果如图2所示。

以上的示例展示了该方法在关系数据库SQLServer中的实现方法, 在其他的关系数据库中, 也可以效仿上面的方法, 实现数据库结构信息变化的捕获, 这里不再赘述。

2.3 SQL语句清理缓冲器的设计

由DDL触发器捕获的数据库的结构变化信息是将源数据库中所有的结构变化信息, 都以SQL语句的形式存储到相应的表格信息中。由于这些信息没有经过筛选和清理, 因此这些数据信息是杂乱无章的, 如果直接用这些数据信息对元仓库进行更新的话, 有可能会造成一些操作的冗余和无效的操作, 浪费元仓库服务器的资源。例如:在一个源数据库中, 由于某种需要, 对库中的某个表格A的结构进行了一些相应的改动后, DBA又将该表删除。那么无疑DDL触发器会将对表格A的改动操作和删除操作的SQL语句都进行了保存, 如果直接通过DDL触发器得到的信息与元仓库中的元数据进行同步一致的话, 那么原来对表A的修改操作, 使得在元仓库中相应的元数据也应进行修改。毋庸置疑这些操作基本上对元仓库的最终结构来说是无用的。因为最终该表在源数据库中被删除。以上这种情况在源数据库与元仓库的一致性过程中还有很多。为了避免这些无用的操作, 这里设计一个源数据库的SQL缓冲清理器。设计的基本原则是:首先将DDL触发器捕捉到的源数据库的变化信息保存到一张临时的信息表中, 当元仓库的管理者向源数据库提出获得变化信息的请求时, 先对这些信息进行清理, 拿上面表A的例子来说, 通过缓冲清理器的分析处理之后, 只需要最终把表A删除的信息传送到元仓库的服务器的相应模块中进行处理即可。这样不但解决了元仓库更新时无效操作等问题, 还减少了网络间数据的传送量。源数据库结构变化捕捉器的总体结构如图3所示。

2.4 元仓库更新的设计

当元仓库的管理者决定对元仓库进行更新时, 首先通过Internet获得源数据库的结构变化信息, 然后利用语法分析器对这些结构变化的SQL语句进行语法分析, 提取变化的元数据, 对元仓库进行相应修改。一般与关系数据库结构变化相关的SQL语句主要有表1所列情况。

SQL通常不提供修改模式定义、修改视图定义和修改索引定义等操作。用户如果想修改这些对象, 只能先将他们删除掉, 然后再进行重建。此外, SQL语言用Alter Table 语句修改基本表, 修改的内容一般有以下几种情况:

故此, 只需设计语法分析器, 分析上述SQL语句, 一种结构变化对应一个模块函数。提取函数是按照SQL脚本的BNF范式进行提取的。例如, 当语法分析器分析得到某条SQL语句中包含“Create Table”, 则自动调用CreateTable () , 将此新建的表及其所属的内容的元数据信息提取出来, 并把这些元数据信息转换成元仓库中对应类的对象。其他的操作方式也是通过类似的方法, 遇到Drop时调用删除模块进行提取, 遇到Alter时则需要根据其对表的不同的操作, 采取不同的应对措施。

当元数据提取完毕并通过完整性检查后, 元数据以对象的形式存在于缓存模块中, 根据元数据的更新情况将其分成两组, 一组为需要添加的元数据, 另一组为需要删除的元数据。由于修改操作被分成了删除和添加两部分, 为了避免添加过程的冗余, 先对元仓库中的元数据进行删除, 然后再进行添加。元仓库的更新流程如图4所示。

为了更好地支持数据信息的查询, 在元仓库中的元数据上建立了用户模式和语义元数据, 因此在元数据删除的过程中要对其进行判断是否建立了映射关系, 如果已经建立了映射关系的则提示映射关系的建立者该元数据已经不存在, 然后再将元数据删掉。

元数据之间存在若干依赖性 (或称相关性) , 它们制约着元数据提取与导入的先后顺序:被依赖的元数据必须先于依赖的元数据进行提取与导入。因此将要添加的元数据分成两类:基本元数据和相关元数据。因此导入的时候需要分成两步, 第一步首先向平台元数据库导入基本元数据, 即各种实体类的对象, 遍历每种实体类的实体对象 (实现时用链表管理) , 将其依次导入平台元数据库。第二阶段待所有基本元数据导入完成后, 便可以导入相关元数据, 即通过遍历每种关联类的关联对象 (实现时用关联对象中的引用属性管理) 依次导入平台元数据库。这种导入顺序确保了导入相关元数据时平台元数据库中已经存放了该数据可能用到的基本元数据, 有效解决了元数据相关性问题。经过以上过程, 最终达到了元仓库与源数据库的元数据的同步。

3 结 语

本文给出了在当源数据库的结构发生变化时, 如何对相应的元仓库中的元数据进行更新的方法, 并解决了因此种情况而引起的元数据悬挂的问题。课题组的最终目的是:通过本体标注元数据和用户模式的形式对各源数据信息进行智能化的查询。通过本体标注元数据后, 元仓库发生变化时, 智能地解决本体标注和用户模式悬挂的问题也在考虑解决中, 相关工作会在后续的文章中介绍。

元数据管理 篇2

对数据仓库、元数据等进行了简单介绍,并针对地理信息系统中元数据的作用、内容进行了阐述,在此基础上,对地理信息系统中元数据的管理方法提出了建议.

作 者：刘越 刘国忠 LIU Yue LIU Guo-zhong 作者单位：刘越,LIU Yue(吉林省地理信息工程院,吉林,长春,130051)

刘国忠,LIU Guo-zhong(国家测绘局第二大地测量队,黑龙江,哈尔滨,150086)

数字校园建设中的元数据管理研究 篇3

摘 要：目前高校数字校园进入到系统集成与信息集成阶段，构建一个集成的数据环境是深入集成的基础。本文分析了数据集成过程中所面临的元数据管理问题，为解决这些问题，本文结合西安交通大学数字校园建设的实际，提出了一套元数据管理体系，包括：元数据建模、元数据管理系统和运行保障机制，为数字校园建设的数据集成提供了有力保障。

关键词：数字校园 元数据 元数据管理 数据集成

中图分类号：TP311 文献标识码：A 文章编号：1673-8454（2009）05-0025-02

目前数字校园建设处于系统集成与信息集成的阶段，集成的数据环境需要高效率的元数据管理。[1] 西安交通大学在数字校园建设过程中面临严峻的数据集成问题：由于以前的系统建设缺乏统一的规划，建成了一批孤立的彼此不关联的系统。同时，学校的管理又要和教育部、人事部、科技部、卫生部等管理部门的信息系统相集成，例如完成各种信息统计和填报等工作。学校迫切需要有效地提高与这些外部系统信息交换的自动化程度。而进行数据仓库的建设和数据挖掘分析，元数据的有效管理和共享是必不可少的。本文分析了目前元数据管理面临的一些问题，并提出了一个有效的解决方案。

一、数字校园建设中对元数据管理的迫切需求

在数字校园建设中，开发、运行维护人员关注技术元数据，通过它们掌握数据流动规则，制定数据清洗、粒度策略，建立新的数据抽取、聚合、发布过程，跟踪数据增量运行过程。业务人员关注业务元数据，通过它们掌握数据的全局视图，了解需要数据的位置、意义、关联关系、统计口径，生成需要的报表，展开多维分析、相关分析，辅助数据挖掘过程。[2]

因此元数据必须是可靠的、一致的、最新的，但是在数字校园建设过程中发现，我们能够得到的元数据并不是我们想象的那么完美，很多遗留系统存在着如下问题：

1.元数据的描述缺乏统一的标准，描述的方式多种多样。有的用E-R图，有的用数据字典，而且大多只停留在数据层面，而对系统本身和维护人员的描述基本没有。有的学生开发的系统很不规范，甚至没有元数据描述。

2.各个应用系统自己维护自己的元数据，元数据的管理是封闭的，许多系统的数据字典还只停留在设计阶段，随着系统运行时间的延长，实际的元数据已经和设计时的元数据大相径庭了。

3.有些系统开发和设计人员已经流失，变成了不可维护的“烟囱系统”。[3] 没有人能说清楚系统的元数据，这给系统的集成和改造带来了巨大的麻烦。

4.由于元数据都是各系统分别管理，因此在系统变化的时候也不会通知其他使用该系统资源的相关系统，这样经常会造成其他系统在不知情的情况下发生故障。

为了解决上述问题，保证数字校园数据交换平台的平稳运行，以及数据仓库建设的数据装载能够顺利的进行，有必要建设一个全局的元数据管理系统来规范全校各应用系统的元数据。为了有效地管理元数据，我们设计了一个全局的元数据管理体系：首先建立一个元数据描述的模型，其次建立一套元数据管理的系统，最终通过一套制度来保证全局元数据管理得到实施。

二、元数据建模

为了能更好地做到全局元数据管理，参考《都柏林核心元数据标准》和《中国科学院科学数据库核心元数据标准》，专门制定了《西安交通大学元据标准》，采用XML作为元数据的描述方式。[4] [5] 对于所有新建立的应用系统我们要求其必须提供符合元数据描述标准的元数据。对于旧的系统则通过人工的方式整理出符合标准的元数据，并作为元数据管理系统采集、对比和维护的数据对象。

在模型中根据学校实际情况简化了《都柏林核心元数据标准》中的定义，定义了最核心的基本的元数据的描述方式。例如，图1表示的是对“数据集结构描述”的定义。

有了元数据的描述标准，我们就可以通过元数据记录有关数据的建立、结构以及维护等方面的信息，数据管理者可以通过这些元数据对数据资源进行有效的管理，数据使用者也可据此了解数据资源的背景资料；其次，元数据的使用能够在一定程度上消除数据资源之间的语义独立性和异构性，帮助实现数据资源的整合和交换。

三、元数据管理系统

只有元数据的描述标准是远远不够的，我们还需要建立一套的元数据管理系统来注册、抽取和存储元数据，以及对元数据做版本控制和血统分析，这样才能充分保护和利用元数据，使其发挥更大的价值。

我们设计的元数据管理系统的架构如图2所示。

1.系统把符合元数据标准的系统元数据以XML方式存储在原生数据库中。

2.系统可以通过注册的方式把应用系统的元数据注册进来，一旦基本元数据注册成功，系统就可以主动地抓取应用系统中的元数据到版本库，版本库中的源数据也是以XML方式进行存储。

3.系统管理员可以调度抽取元数据的周期，元数据的抽取按照调度自动执行。

4.每次调度而抽取出的元数据都被保存在版本库中，任何版本的元数据都可以被调出来以便做对比和系统分析，我们在系统中集成优秀的版本管理软件Subversion作为版本控制的引擎，利用其丰富的二次开发接口来实现我们的需求。[6]

5.系统提供对于XML元数据的自动对比功能。XML的比较是一个目前比较困难问题，我们参考了世界上比较通用的一些算法，由于我们的XML的schema基本固定，最后我们使用了通过客户端进行比较的策略，取得了比较好的效果。

6.其他的应用系统的管理员可以登录到元数据管理系统中根据授权查询使用系统中的元数据，并可以查阅元数据变化的历史。

7.提供一套基于Web service 的开放的编程接口（OpenAPI）,方便其他系统可以通过编程自动地感知元数据的变化，完成一些自动化的增值功能。

有了这样一套系统，元数据不再孤立，可以在最大限度上实现元数据的共享，为各系统的数据集成和数据仓库的建设提供强有力的支撑。

四、元数据管理的保障机制

有了良好的元数据标准，建立了完善的元数据管理系统依然不能保证元数据能够得到有效的管理和使用。为此必须要有一套管理机制来保证标准可以得到真正的贯彻执行，为此，我们专门制定了一些有关元数据的规章制度和管理办法，主要有这样两个方面：

1.对于任何新的软件系统的招标和建设，把遵循元数据标准和公开其元数据写到标书中去，约束软件开发商必须贯彻元数据管理规范，这样就能保证新建立的系统可以纳入到全局的元数据管理体系中来。

2.对于已有的系统，如果需要通过学校的数据共享平台使用其他部门的数据，那么首先要按照元数据标准注册他自己的系统，然后再根据需求整理目标系统的元数据，这样随着系统运行的不断深入，旧系统中的数据也源源不断地纳入到元数据管理体系中来。

五、结束语

西安交通大学通过制定元数据标准，建立元数据管理系统，实施元数据管理保障机制，打破了“信息孤岛”，目前已经建立了基于数据共享的全校的用户管理中心等多个大型共享数据的信息系统，元数据得到有效的管理和开放共享，为顺利地进行数据和信息的集成起到了关键作用。目前，基于元数据的深度的信息集成正在紧锣密鼓的进行中，元数据将在今后数字校园的发展中起到更大的作用。

参考文献：

[1]蒋东兴,许庆红,刘启新,陈怀楚.信息集成阶段新一代数字校园建设探讨[J].教育信息化,2006(10):1-7.

[2]潘定,沈钧毅.数据仓库中实时元数据管理的研究[J].西安交通大学学报(自然科学版),2005(6):566.

[3]William J. Brown 、Raphael C. Malveau 、Hays W. McCormick III、Thomas J. mowbray.反模式-危机中的软件、架构和项目重构[M].北京:人民邮电出版社,2008.1:106.

[4]都柏数林核心元数据标准.http://dublincore.org/

[5]中国科学院科学数据库核心元数据标准.http://www.nsdc.cn/

元数据互操作透视 篇4

信息资源的内容、管理机制、实现信息资源共享的应用协议,涵盖了信息资源管理研究的主要内容。因此从这三个方面切入研究,是探索各部分涉及的元数据互操作问题、各异构数据系统间统一检索利用问题的有效途径。这三方面涉及的元数据互操作主要体现在三个层面:元数据格式层面上的互操作;元数据体系结构层面上的互操作;检索应用协议层面上的互操作。

1 元数据格式层面上的互操作

元数据格式层面上互操作的形式主要是元数据映射,即两种不同格式元数据之间的转换。转换可分两种形式:一对一的转换,通过源元数据的元素、语义、语法向目标元数据的元素、语义、语法的映射实现互操作,例如MARC向DC的转换;另一种形式有多种元数据参与,通过设定中心元数据格式,其他元数据格式通过向中心元数据的映射转换,最终实现多种元数据间的互操作,例如OAI就选用DC做为中心元数据格式,各异构元数据系统都向DC映射转换实现互操作。

元数据转换涉及单向转换和双向转换。单向转换只允许从源元数据向目标元数据的映射,不允许此过程逆向。双向转换允许逆向转换。各种元数据结构和语义上的不同,造成了元数据在映射过程会出现不同差异,主要分为结构映射差异和语义/描述规则映射差异。

结构映射差异可分为以下2种情况:1)一对多关系,即源元数据的一个元素与目标元数据的多个元素相对应,从而在映射时造成差异,如DC的subject元素与MARC中的多个6XX字段对应这种情况。在双向转换中,又表现出多对一的关系;2)无对应关系,即源元数据的一个或多个元素在目标元数据中找不到对应的元素造成的映射差异,如DC中date的modified元素在MARC21中就没有对应的元素等。

语义/描述规则差异主要有以下4种情况:1)某些元素在源元数据中是可选元素,在目标元数据中是必备元素带来的差异。如源元数据中的可选元素缺省,目标元数据无法赋值,从而导致映射操作出错;2)可重复元素带来的差异,如源元数据中是可重复元素,目标元数据中为不可重复元素,从而带来元素无法取值,导致映射出错;3)有无子元素带来的差异,即如何解析源元数据元素的子元素向没有子元素的目标元数据元素的映射问题;4)元素层次错位问题,一般来说这是因为元素的语义差异造成的,会涉及语义的解析规则问题。

为了降低这些问题导致的元数据转换过程中的信息丢失,通过对元数据的“附注”、“提示”等保留字段的操作,及在转换过程中加入补充数据、规范转换过程的解析规则等措施,可在一定程度上解决映射差异带来的影响。

2 元数据体系结构层面上的互操作

从对元数据互操作的理解上来说,我们可以把元数据的元素映射看作是微观层面的工作,对体系结构层面的互操作可考虑为宏观层面上的问题。XML由于描述能力、高度结构化、扩展能力等方面的优势,为许多元数据互操作模式提供了基础语法支持。很多元数据互操作方案都基于XML。XML-DTD模式、XML Schema模式、RDF模式是三个典型实例。

2.1 XML-DTD 模式

DTD是XML标准的文档类型定义方式,每种格式的元数据都可以由XML-DTD定义。只要能够解读XML语言的系统都可以对被DTD统一定义的元数据格式予以辨识,从而解决异构元数据格式的解析。DTD包含定义元素的元素声明和属性列表,元素声明中的元素组成了词汇表,元素的属性列表指出了元素的属性。也就是说,可以通过对各元数据格式的统一定义,形成一个元数据的重用机制,扩展元数据格式适用范围,兼容不同元数据,促进元数据间的互操作。DTD在简单的文档结构定义方面是较为出色的,但由于DTD本身的局限性,实践中问题较多。DTD仅支持自己的特殊语法,使编写DTD和XML文档需要两套不同的规则。DTD只支持字符型数据,不支持Name Space,扩展性不强,不具开放性,以及DTD格式书写、理解困难,不易用程序进行自动化处理等都是其不足。

2.2 XML Schema 模式

与XML-DTD相比,XML Schema本身即是规范的XML文档。它利用XML的基本语法规则来定义XML文档的结构,实现了由内向外的统一,易于编辑,且能用XML工具解析。这是区别于DTD的一个本质变化。XML Schema有良好的扩展性,在简单数据类型基础上允许用户扩展数据类型;主持属性分组,属性的应用范围多样,可以针对不同元素进行;支持Name Space,能在同一文档中加载多个schema定义;具互换性、规范性,可利用高层次的数据转换约束XML文档中标识的使用。显然,XML Schema可看作是DTD的延伸,包含了DTD能实现的所有功能。Schema也有其不足,例如可读性不如DTD,需要高版本浏览器支持等。许多研究表明,在DTD和Schema的转换中,推荐由前者向后者的转换,以实现“完全转换”,以便充分利用Schema的优点。

2.3 RDF 模式

RDF是W3C提出的用于描述WEB资源的标准,现已成为Semantic Web研究的核心概念之一。用RDF描述元数据格式,意味着只要能够解析这个标准描述框架,就能够解读相应的元数据格式,进而实现互操作。具体实践中,RDF是间接利用了元数据复用机制,通过把所有格式的元数据集中到一起,交换对WEB资源服务的描述,实现多种元数据在异构系统间的共享。实际上,RDF并不直接定义具体元数据,而是通过一个“资源——属性——值”的三元组来提供元数据的基本使用模式,并通过XML Name Space机制引用已有的元数据格式中的元素定义,从而直接使用合适的元数据元素做为三元组中的属性来描述相应资源。这也是RDF被认为是间接利用了元数据复用机制的原因,它并没有真正直接定义具体元数据。DTD和Schema都对具体元数据进行了定义。对各资源描述团体(如DC)来说,RDF也并不为他们规定语义,而是为其提供了据需要定义元数据单元的能力,这也是它的高明之处。作为一种WEB资源描述通用框架,RDF以计算机容易理解的方式表示,可以很方便的进行数据交换,提供了WEB数据集成的元数据互操作方案。

此外,RDF用XML表达只是方式之一,通常表述为RDF/XML。还有另外两种方式,即Notation 3和图形。因为计算机目前无法理解RDF的图形表示,Notation3相比RDF/XML虽然更为简洁,但时下对它们的研究还不是太成熟,在元数据互操作方面的意义有待进一步研究。

3 应用协议层面上的互操作

在应用协议层面上,元数据互操作可通过定义一个公认的、相互支持的协议实现。OAI和Z39.50就是两个这样协议。

3.1 基于 OAI-PMH 的互操作

Open Archive Initiative,是一个应用于交互平台上的检索、发布数字化信息资源的协议,最早源于电子出版界的互操作计划。其简单,灵活,平台独立,在许多领域都有应用。OAI制定有元数据采集标准OAI-PMH,其利用元数据开放搜寻机制来实现元数据的互操作。

OAI-PMH采取元数据收割模式,提供了独立于应用的互操作框架。基于OAI-PMH的元数据互操作框架主要包含三个组成部分:数据提供者(DP),服务提供者(SP),元数据搜寻协议。OAI协议是数据提供者和服务提供者之间的通信应用协议,架构于HTTP协议之上,提供六个核心的操作指令。服务提供者通过这六个指令向数据提供者获取元数据资源,并向用户提供增值的检索服务。

OAI定义了两个主要参与者:数据提供者、服务提供者。当服务提供者定期或定量的通过OAI协议向数据提供者发送收集元数据的“请求”,以向用户提供统一资源检索服务时,数据提供者需要将其元数据格式统一转换为所要求的DC格式,并经过XML编码,反馈给服务提供者。之后,服务提供者将收集到的元数据存储到本地数据库,然后通过统一的检索界面为用户提供服务。过程中,DC起到了中介元数据的作用,各种格式的元数据通过到DC的映射转换实现互操作。严格来讲,OAI-PMH只是一个元数据采集标准,只采集元数据,不采集信息内容。任何一个数据提供者都可以向多个服务提供者提供元数据,一个服务提供者也可以向多个数据提供者获取元数据;对于一个组织来说,它即可以是数据提供者也是可以是服务提供者。

3.2 基于 Z39.50 的互操作

Z39.50是“开放系统互联参考模型”(OSI-RM)的应用层协议,涉及面向连接的、程序间的通信问题,它使得用户在一台客户机上检索存储在另一台计算机(服务器)上的信息,而不必关心这些信息的存储和组织结构。被图书情报界广泛的作为一种访问分布式数据库的方法使用,成为检索远程图书馆书目信息的国际标准。

Z39.50在互操作问题上呈现为一种检索转换机制。它将异构系统的检索指令和结果按照一种公共方式表达,从而支持异构系统间的检索,保证互操作实现。在检索中,检索者使用本地机系统及自己熟悉的菜单和命令输入查询提问,驻于本地系统中的Z39.50源模块将提问请求翻译,转换成由Z39.50定义的标准格式,并发送给有着Z39.50目标模块的数据库系统,目标模块将转换过的检索提问和命令提交给数据库进行检索,并将检索结果以标准格式返回给源系统,而源系统又以其格式和方式将结果输出给用户。从而实现用户用其所熟悉的指令、格式来检索任意异构系统数据的目的。一个检索系统可同时装入Z39.50的源模块和目标模块,既可作为客户机向其他系统提出请求,又可作为服务器回应其他系统的请求。

海洋水色遥感元数据及其系统设计 篇5

海洋水色遥感元数据及其系统设计

在参考国内外元数据标准的基础上,提出了一个海洋水色遥感元数据框架,可以用来对海洋水色遥感数据进行描述、组织、存储和管理;在此基础上,利用XML Schema对此元数据框架进行描述,从而可以用于规范海洋水色遥感元数据.其次,从元数据的访问接口、存储系统及其安全体系结构方面设计元数据系统,实现对海洋水色遥感元数据的有效存储和管理.最后,对海洋水色遥感元数据系统进行功能和性能评价.

作 者：李学荣 李莎 LI Xue-rong LI Sha 作者单位：中国科学院南海海洋研究所,广东,广州,510301刊 名：热带海洋学报 ISTIC PKU英文刊名：JOURNAL OF TROPICAL OCEANOGRAPHY年，卷(期)：26(1)分类号：P7关键词：水色遥感 元数据 元数据框架 XML 系统

元数据管理 篇6

关键词：档案； 元数据； 电子文件； 保管期限； 自动鉴定

1 电子文件鉴定研究综述

随着电子文件的出现及其对传统纸质档案鉴定理论的冲击，国内外许多学者对电子文件的鉴定理论进行了研究。刘越南认为电子文件自动鉴定的方法是在系统中纳入并维护电子文件保管期限表。[1]于慧敏提出可以根据机关或部门的职能重要程度编写程序由系统自动鉴定，自动给文件保管期限。[2]谭琤培和章丹指出要建立元数据系统与制定元数据标准，通过系统自动记录与手工记录获取档案元数据。[3]由于电子文件的迅速增长，关于电子文件鉴定的迫切性在业内已经达成了共识，而大家期盼的最理想的目标是对电子文件实行自动鉴定。从综述看现有的理论研究并未达成共识，没有形成电子文件自动鉴定相对成熟的理论体系，需要相关研究不断地总结与完善。目前的研究成果大都集中在电子文件鉴定内容、程序、方法、原则等宏观方面的研究，缺乏微观方面的研究。

对电子文件的鉴定主要包括价值鉴定和保管期限的鉴定。价值鉴定十分复杂，需要考虑的内容很多，而且容易受鉴定者的主观影响，因此本文对价值鉴定不做过多的阐述。档案的鉴定同样可以通过保管期限来完成，在实际鉴定保管期限时，目前还是参照国家档案局出台的文书档案保管期限表进行判断，由于保管期限表条款划分过粗、加之人为的因素或者判断标准不统一的情况，使得电子文件的保管期限判断不够准确。笔者试图从电子文件的部分元数据内容入手来判断电子文件的保管期限。

本文以元数据为切入点，主要采用在文献调查的基础上，通过统计方法构建元数据库，将元数据内容信息作为电子文件保管期限自动鉴定的依据。笔者通过选取文件标题、主题词这两个能反映文件全貌的元数据内容项目进行了实证分析，对自动鉴定结果进行了验证。

2 电子文件元数据库的内容创建

元数据是指描述文件背景、内容、结构及其整个管理过程的数据。档案元数据描述的内容有以下三方面：（1）内容信息：如标题、档号、分类号、主题词等；（2）结构信息：如段落层次、文体、发（收）文者等；（3）背景信息：如形成文件的机构及其职能、业务活动等。[4]通过观察，档案元数据描述的内容中除了文件标题和主题词能反映文件全貌，其他元数据项目难以用来判断一份文件的保管期限。因此本文只选用了文件标题和主题词这两个项目来判断一份电子文件的保管期限。适当的情况下，在判断保管期限时，还可以加入责任者项目。

为了使电子文件自动鉴定具有可操作性，笔者根据国家档案局发布的第10号令《企业文件材料归档范围和档案保管期限规定》，将其中涉及的元数据内容抽取出来，该元数据库要嵌入档案管理系统自动鉴定模块中。部分元数据库如表1所示：

表格说明：

（1）一级标识限定了电子文件的内容方向，二、三、四级标识隶属于一级标识，只有同时满足一级标识、二级标识、三级标识或四级标识才能判断某份电子文件的保管期限。

（2）由于政策的变化，长期、短期、永久划分没有绝对的标准，各单位依据自身具体情况，参照国家档案局出台的保管期限划分等相关规定进行区分，短期可能是3年、5年、10年或15年不等，长期可能是15年或30年不等。

3 电子文件自动鉴定规则、流程与实例

3.1 电子文件自动鉴定规则。要使电子文件实现自动鉴定，只有元数据库是不够的，还需要一些规则对其进行规约，笔者归纳出以下鉴定规则：

3.1.1 元数据库中的元数据项目彼此之间存在从属或并列的关系，因此在设计数据库的时候，要把元数据项目之间的这种关系表达清楚，能提高自动鉴定的准确度。如下所示：

1党政企事业单位设立、变更、解散

1.1筹办申请、设立申请、批准设立永久

表中内容是永久元数据库中的项目，一级标识是代表党政企事业单位在设立、变更或解散过程中形成的文件材料；二级标识是代表在满足一级标题的情况下，如果涉及筹办申请、设立申请和批准设立的文件要永久保存。每一级标识里的元数据之间是并列的关系，而上一级标识和下一级标识之间是从属的关系。

3.1.2 当判断一份归档文件的保管期限时，系统自动从档案著录系统中提取专业人员拟定的主题词、文件标题等元数据，然后与元数据库进行匹配，可以设置精确匹配、模糊匹配、前向匹配等多种匹配方法。

3.1.3 当抽取的电子文件元数据与元数据库进行匹配时，匹配的内容之间可能存在同一关系、同涵关系、包含关系、参照关系。因此从电子文件中抽取元数据的时候要依据概念关联规则，寻求蕴含关系，力求匹配准确和全面。

3.1.4 如果匹配记录为0的话，就需要相关档案专业人员结合国家档案局对电子文件保管期限的相关规定确定该元数据项目的保管期限，并参照表1及时将新增加的元数据添加到元数据库中。

3.1.5 在档案管理系统中设定归档电子文件到期自动检测功能，根据电子文件归档时间和保管期限，将到期的电子文件筛选出来以方便档案人员对其鉴定。

3.1.6 标题相同的两份文件，在添加和删除的时候，可以根据责任者、主题词、文件形成时间等其他元数据项目进行判断，以防重复添加或误删重要文件。

3.1.7 通过对抽取出来的元数据进行分析，发现大部分元数据的词性均为动词或名词，因此在抽取词汇的时候，首先应当过滤掉名词与动词以外的词汇，以减少计算的复杂度。此外，考虑到抽取出来的元数据还有一少部分是副词词性，主要有重大、重要和一般三种。鉴于此，笔者认为需要编一个例外词库，将这三个副词分别标明代码为1，2，3。对于某些三级、四级标识中的一般、重要以及二级标识中重复的词可以放到例外词库中，减少重复判断的次数。将一、二、三级标识中不重复的名词和动词放入元数据词库中。当判断一份电子文件的保管期限时，将抽取出来的关键词与元数据词库和例外词库中的词进行匹配即可。

3.1.8 对于事先有保管期限的电子文件，当自动鉴定完成后，要将自动鉴定结果和原有的保管期限进行匹配。如果匹配结果不一致，系统将文件的保管期限修正为自动鉴定保管期限。

3.1.9 规则说明：例如，表中15.2.10职工培训，一般的为短期保存，重要的为永久保存；15.5综合治理工作一般的为长期保存，重要的为永久保存。此外表中二级标识中多次出现通知、请示、批复、报告、总结、决议、决定等词语，可以将其放入例外词库中。

3.2 电子文件自动鉴定流程。将表征电子文件内容的元数据项目抽取出来，如：文件题名、主题词、责任者等项目。然后判断鉴定模块中的元数据库中是否存在该元数据，若存在，则进行匹配；若不存在，则人工判断该元数据是否需要添加到元数据库中。流程如图1所示：

3.3 电子文件自动鉴定实例。为了证明该方法的合理性和易操作性，笔者选取了部分电子文件，来验证该方法的可行性。笔者以建国后山西省×××局部分档案为例进行说明，如表2所示：

由表2可以看出第5份和第7份文件保管期限的鉴定结果与原有的不符，究其原因可能是鉴定人员缺乏相应的专业理论知识、各组织单位为了丰富馆藏、领导对档案鉴定工作不重视，等等。对于新产生的电子文件，可通过将元数据库嵌入档案管理系统中一次完成保管期限的鉴定。总的来说，该方法具有很强的适用性和准确性。

4 电子文件自动鉴定的实施

笔者认为电子文件鉴定需要经过三个步骤：事前鉴定、事中鉴定和事后鉴定。

4.1 事前鉴定。对原有的电子文件，首先由各职能部门档案人员对其进行初次鉴定；若是新产生的电子文件，直接转到第二步。

4.2 事中鉴定。当电子文件由部门传输到内部档案室时，需要档案室人员对其进行二次鉴定。对于原有的电子文件，为了避免人为判断造成的影响，要使用档案管理系统中的元数据库对其进行自动鉴定，来修正保管期限。对新产生的电子文件直接使用自动鉴定模块来确定保管期限。此外，档案人员应对电子文件自动鉴定过程进行记录和实时监控，以防设备出现异常。

4.3 事后鉴定。为了减轻档案管理系统的负荷量，当电子文件到期后，档案人员应该使用元数据库重新判断到期电子档案是否需要继续保管，如果需要，保管期限是什么。对于没有保存价值的到期档案，档案人员应该做好销毁记录，将需要销毁的电子档案导出到销毁清单中，经领导和各部门同意后方可进行销毁。

参考文献

[1]刘越南.关于档案价值鉴定的理论与实践（五） ——对电子文件鉴定问题的思考[J].档案学通讯，2001（5）.

[2]于慧敏.国外电子文件的鉴定理论分析及启示[J].兰台世界，2003（3）.

[3]谭琤培，章丹.档案元数据在电子文件鉴定中的运用——元数据研究之三[J].浙江档案，2002（6）.

[4]冯惠玲主编.电子文件管理教程[M].中国人民大学出版社.

一种双向元数据管理系统 篇7

1.1 研究的背景

随着数据大集中的完成，各家银行都在研究适合银行信息分析处理的数据仓库解决方案，并建立相应的数据仓库系统，提高分析数据和挖掘信息的能力，以提升银行自身品牌和潜在竞争力。整个银行数据仓库的组织结构是由元数据来组织的，它是“关于数据的数据”，元数据至少应包含如下一些信息：数据结构、数据综合算法、从基于OLTP的业务环境到银行数据仓库环境的规划等，元数据在数据仓库的建设中起着重要的作用。元数据管理系统必须成为集中了企业级数据仓库所有管理和运行信息的一个统一的知识库，才能够为庞大的企业级数据仓库的开发、运行和管理提供足够的信息，提升企业级数据仓库的生产效率，保证企业级数据仓库的稳定运行。因此，要求元数据库中的信息必须是集成的、准确的和保留历史的。然而对于目前那些具有元数据管理系统的数据仓库来说，存在着一个很大的体系架构缺陷，就是企业级数据仓库只采用了单向的元数据管理体系架构，即元数据信息只从外部流向元数据库，而元数据库无法在运行时为数据仓库提供支持。

企业级数据仓库中包含多个子系统，每个子系统都具有与其开发、运行相关的元数据。元数据管理系统从这些子系统中提取元数据，形成数据仓库统一的元数据视图。但是如果元数据只是单向地从各个子系统流向元数据管理系统，虽然可以将元数据集成，为数据仓库的开发和管理提供一定帮助，但很可能造成以下的缺陷：

1)元数据库逐渐演变成一个元数据的查询工具，无法发挥出作为数据仓库核心知识库的总控作用;

2)元数据信息不会从访问接口流向其他子系统，则无法促进元数据的及时更新，难以从根本上保证元数据的保证准确性;

3)元数据库不提供运行时所需信息，各个子系统需要维护自己的一套元数据以支持自己的运行，造成了元数据的冗余;

4)元数据库无法保证其内容的准确性，则无法成为数据仓库运行时的核心部件，造成相关的各系统之间需要进行直接信息交互，大大增加了子系统之间的通信成本，难以管理。

1.2 研究的目的

本文描述的元数据系统建设方法，克服了现有技术中的缺点，提供了一种基于双向体系架构的元数据管理系统，能够支持从企业级数据仓库的其他子系统抽取元数据存储到元数据管理系统，同时也支持向企业级数据仓库其他子系统提供其所需的元数据信息，解决上述的诸多元数据和数据仓库的运行管理问题，大大减少了数据仓库的管理难度、保证了元数据的准确性、使得各子系统能高效地通信和稳定运行。

2 双向体系架构

2.1 框架简述

本文提供了一种具有双向互动特征的元数据管理系统，通过元数据提取装置将数据仓库各子系统的元数据提取到元数据运行库装置中，并采用通用的关系型元数据模型存储元数据;通过通用桥接器，可将关系型元模型的元数据提取到对象型元模型的元数据知识库装置中，形成分析结果供用户查询;通过数据库视图，可以向其他子系统提供其所需的元数据信息。最终实现了元数据的统一管理，为子系统的运行和它们之间的交互提供了统一平台。其中，

1)通用的元数据模型是通过对各子系统的元数据进行概括形成的、能满足各子系统要求的统一的元模型;

2)通用桥接器是可以灵活定制同步任务和数据映射的元数据同步程序;

元数据管理系统采用数据库视图的方式提供元数据访问接口，实现子系统之间的元数据交互。

2.2 框架组成

本系统中主要由4部分组成：包含元数据运行库装置、元数据提取装置、元数据服务接口装置、元数据知识库装置(如图1所示)。

其中，“元数据运行库装置”与“元数据提取装置”连接，负责存储数据仓库统一的关系型元模型，将其它子系统的元数据集成于统一的元模型中;“元数据提取装置”连接着“元数据运行库装置”和其他子系统，负责将其他子系统中未经加工的最基础最为明细的元数据，提取存储到元数据运行库装置中;“元数据服务接口装置”连接着“元数据运行库装置”与“元数据知识库装置”以及其他子系统，元数据服务接口装置负责将元数据运行库装置中的基础元数据变换成满足其他系统应用需要的元数据，向其他子系统提供元数据;还负责将“元数据运行库装置”中基于关系型元模型的元数据，提取到基于对象型元模型的“元数据知识库元装置”。“元数据知识库装置”与“元数据服务接口装置”连接，负责将元数据进行分析，形成满足特定要求的分析结果，提供用户查询使用。

2.3 框架子模块详述

2.3.1 元数据运行库装置

“元数据运行库装置”，其包含关系型数据库的元模型，存储了元数据的结构以及具体的元数据，其所包含的内容如下：

1)源系统数据结构表，用于存放数据仓库源系统表的注释和数据库属性。

2)源系统字段描述表，用于存放数据仓库源系统表中字段的注释和数据库属性。

3)源系统表索引描述表，用于存放数据仓库源系统表中索引的字段和数据库属性。

4)上游接口文件与源系统表关系描述表，用于存放数据仓库与源系统的文件接口的描述。

5)数据加工关系表，用于存放数据仓库中的各数据对象的加工关系。

2.3.2 元数据提取装置

“元数据提取装置”包括SQL桥接器单元、SDM桥接器单元、Excel桥接器单元、XML桥接器单元。“元数据提取装置”负责将其他子系统中的元数据信息提取至元数据运行库中。这是双向元数据体系架构中元数据流动的一个方向，即从其它子系统->元数据库的方向，其分类提取情况如下：

1)XML桥接器单元负责从其他子系统提取源系统数据结构，存放到元数据运行库装置的源系统数据结构表中。源系统数据结构表描述了数据仓库上游系统的数据结构和接口结构，是数据仓库加载源系统文件的依据。源系统数据结构是通过从源系统的统一接口下载的XML获得;然后通过元数据的桥接器解析并加载到元数据库中。

2)SQL桥接器单元、SDM桥接器单元提取数据映射关系。元数据运行库装置中的数据加工关系表所存放的数据映射关系，是通过SQL桥接器单元解析ETL加载脚本中的SQL、以及SDM桥接器单元解析SDM开发文档而获得。

3)Excel桥接器单元负责提取数据仓库逻辑模型。Excel桥接器通过解析ERWIN格式的数据仓库LDM(Logical Data Model逻辑数据模型)设计文档获得相关数据，存储到元数据运行库装置中的LDM模型属性表、LDM模型实体表、LDM模型主题表中。

2.3.3 元数据服务装置

元数据服务接口装置，包含通用桥接器单元，数据库视图层单元。

其中，通用桥接器单元是一种数据库桥接器，连接着元数据运行库装置以及元数据知识库装置。通用桥接器单元通过访问配置文件描述的数据映射关系，将基于关系型元模型的元数据运行库装置里的元数据，提取到基于对象型元模型的元数据知识库装置，这属于元数据库内部的元数据流动。

数据库视图单元是根据不同的元数据应用和需求，在基础元数据之上定义的一系列数据库视图的集合，其连接着元数据运行库装置和其他子系统，负责向其他子系统提供其所需的元数据信息。这是双向元数据体系架构中元数据流动的另一个方向，即从元数据库->其它子系统的方向。元数据库支持其他子系统的运行内容包括：

1)源系统数据加载。源系统数据加载运行时从元数据库提供的数据视图中获得的数据结构和接口信息。

2)DQ检查。DQ子系统通过数据库视图获得接口加载描述信息，并在安装时将该信息静态配置到DQ的检查配置表中，运行时以配置信息为依据对接口的加载情况进行检查。

3)ETL作业调度。ETL作业调度的依据是数据加工的流程，即系统中数据的流向和顺序。元数据运行库装置中的数据加工关系表所存放的数据映射关系，正是描述了这种加工流程。因此ETL作业调度必须以元数据为依据，进行作业运行顺序和依赖关系的配置。

4)元数据浏览、分析。从各种途径获得的元数据信息最终都会通过元数据的前端界面为业务用户和技术用户展现，并基于基础元数据进行数据分析，是一种基于元数据的信息挖掘。通过元数据的浏览、分析，业务用户和技术用户都能从各自关心的角度了解到数据仓库。

2.3.4 元数据知识库装置

元数据知识库装置，包含元模型单元、元数据分析引擎、元数据查询单元。

其中，元模型单元连接着通用桥接器单元，接收通用桥接器单元从元数据运行库单元中提取的元数据，存储为对象型元模型。

元数据分析引擎连接着元模型单元和元数据查询单元，其负责对元模型单元中存放的元数据进行查找、汇总、比对，形成满足特定要求的分析结果，返回给元数据查询单元。其所负责的分析包括以下几种：

1)血缘分析。对元数据管理系统中的某要素进行数据血缘分析，即已知某一数据项，查找到该数据项从源系统到应用的若干ETL过程相关的数据项，计算方法，计算公式，形成该报表元素(或指标)的族谱图，从而了解产生该数据项的流程。

2)影响分析。数据仓库系统涉及多个子系统，各个子系统之间的数据有着紧密的联系，任何一个子系统的数据变更需要相关子系统的同时的变更，否则，将会影响到整个数据仓库系统的数据质量。影响分析模块将向用户提供完整的受变更影响对象列表，并产生影响分析报告，依照该报告，用户可以评估数据变更的影响程度，确定是否需提交变更请求。

3)活力分析。对于企业级数据仓库中的物理模型，不同的实体被用户使用的情况是不一样的，实体的使用程度也是元数据重要性指标之一，我们可以通过设置指定用户对指定实体或者全部实体的访问类型统计，来判断模型中的实体的活力情况。

4)孤儿分析。用户可以对元数据管理系统中的某要素进行数据孤儿分析，确定数据加工过程中的数据“孤岛”。

5)元数据浏览和查询。根据用户输入的查询界面提供单体查询功能;通过知识库中元数据对象之间的连接，进行元数据关联性的查询。

元数据查询单元连接着元数据分析引擎，其负责提供用户查询界面，接收用户的查询指令，通过访问元数据分析引擎的分析结果，向用户反馈查询结果。

3 双向体系的应用实例

3.1 从子系统提取元数据

图2为本系统的一个实施例，描述了从其他子系统提取元数据的流程。系统启动元数据提取流程,元数据维护人员统一收集管理脚本以及开发文档;接着，SQL桥接器、SDM桥接器从开发脚本以及开发文档提取元数据映射关系，将开发脚本和文档描述的转换逻辑解析成数据映射的描述;随后，桥接器将各自提取的映射关系等信息，传送给元数据运行库，存储为关系型元模型。

3.2 向其他子系统提供元数据

图3为本系统的另一个实施例，描述了元数据系统向其他子系统提供元数据的流程。系统启动ETL流程调度配置,数据库视图层接口程序读取元数据库中的数据映射关系;数据库视图层接口将数据映射关系转换为脚本的运行顺序和依赖关系;ETL子系统中的流程配置工具将脚本的运行顺序和依赖关系存放至ETL运行配置库。这种各子系统均通过元数据库获得运行配置信息的配置方式,是基于本系统中集成和统一元数据信息这个前提的。由此可减少信息的冗余,保证了信息的一致和准确。

4 结束语

本文提供的一种具有双向互动特征的元数据管理系统，实现了元数据的统一管理，为子系统的运行和它们之间的交互提供了统一平台，既保证了元数据的准确性，也真正发挥了数据仓库中统一的元数据视图的价值，与现有的技术相比，其效果和优点体现在以下几个方面：

1)避免了各个子系统需要维护自己的一套元数据所造成的元数据的冗余，节省了计算机资源。

2)通过其他子系统向元数据库的灵活加载，使上游系统的变化对数据仓库的影响最小化;

3)通过元数据库向其他子系统提供元数据，实现了各子系统元数据内容的准确性与一致性;

4)支持数据仓库元数据分析，充分发挥了元数据的可用价值。

参考文献

[1]KenRudin W.数据仓库管理[M].北京:电子工业出版社,2000.

[2]Inmon W H.数据仓库[M].4版.北京:机械工业出版社,2006.

网格环境下教学资源元数据管理 篇8

“网格”(Grid)一词来源于人们熟悉的电力网(PowerGrid)。[1]网格是利用互联网将地理上广泛分布的各种资源连成一个逻辑整体[2],就像一台超级计算机一样为用户提供一体化信息和应用服务,最终实现在这个虚拟环境上进行资源共享和协同工作,彻底消除资源孤岛,让人们使用网格上的资源像用电一样简单。基于对网格重要性的认识,2003年4月,教育部启动了中国教育网格计划(China Grid),中国教育科研网格是迄今为止由政府推出的最宏大的网格工程[3],该项目由12所大学联合推出。教育部希望利用网格技术将网上的教学资源有效地聚合起来,实现网上教学资源的广泛共享,为中国高等院校(特别是部分研究型大学)的科学研究提供先进的计算手段。

目前,教育网格研究方向和任务主要集中在提供一种通信管理的网格平台或架构,重点在网格计算能力上。[4,5,6,7]而对于教学与研究人员关注使用的基于网格的教学资源管理及其在网格环境中的深层次应用方面没有太多的研究。为屏蔽不同课程内容上的多样性和差异性,将知识点作为原子资源,并采用元数据进行描述,原子资源间的结构和逻辑规律遵循人的认识规律和教学规律,采用统一的模式进行结构化存储和管理。在此基础上,可以开发教学资源库,提供资源搜索、资源共享、资源组织管理等功能。

教学资源库建设规划

教学资源主要是指教学过程中教师和学生使用的课程资源,可以理解为教学过程中的软资源。教学资源的元数据可分为两个层次:直接对教学资源进行描述的元数据,称为教学资源信息ERI(Education ResourcesInformation);对教学资源的组织目录进行描述的元数据,称为教学资源目录信息ERII(Education ResourcesIndex Information)。其中ERII根据资源规模可抽象为多个层次。元数据是指描述数据的数据,是指与业务技术过程及企业使用数据有关的所有物理数据以及包含知识的信息,是指来自企业内外所有(软件或其他介质含有的)物理数据和(员工和各种媒介中含有的)知识,包括物理数据的格式、技术和业务过程、数据的规则和约束以及企业使用数据的结构。教学资源中的元数据是指描述教学资源的类型、规格、属性、联系、约束等信息的数据。教学资源库建设规划如下。

(1)提取教学资源知识单元,结合教学资源本身及其应用的特点,确定元数据的基本数据结构。知识单元是教学资源中可应用于交流使用并能完整描述一个知识点的最小单元。目前在知识单元划分上还没有具体的规范标准。一般由课程专家和教学专家参照教育部课程建设规范中的要求对教学资源进行三级划分,将划分得到的第三级资源作为知识单元进行管理,并向上逐层扩展,得到相应层次的粗粒度资源。

(2)构建教学资源目录树。目录树从根节点开始,包含一个对其所有数据的层次视图,并提供基于树形的搜索系统。教学资源目录信息ERII根据资源规模可抽象为多个层次。按照目前的惯例和一般使用情况,将课程资源按内容及其关系,划分成大的章,章内再划分小节,小节中又可包含若干更细分的知识单元。这种结构可以看作是教学资源目录信息ERII的外在显现,即教学资源目录树。

(3)教学资源服务。在教学资源使用过程中,系统存在三种角色:资源提供者、资源管理者、资源消费者。资源消费者是指教师或学生,他们提出资源消费请求,包括对资源质和量上的要求;资源管理者即资源中介,是系统管理中心,主要管理ERI或ERII,并根据资源消费者提出的请求进行必要的计算,反馈消费者信息,满足其需求;资源提供者是教学资源存储中心,主要负责资源的存储,并按接收到的指令为消费者提供相关资源。按照信息流动的不同方式,分析他们之间的工作模式,相应地设置层次代理结构。将资源与其元数据适当分隔存储管理,在资源服务时采取资源信息处理和资源实体传递两条线的方式,减轻资源代理的负担,平衡网格环境的负载,有利于提高系统的整体性能。

关键技术

1.元数据结构设计

本文拟采用的元数据基本结构如右表所示。

需要说明的是,该元数据结构根据教育部课程教学及大纲规范要求,结合本学科方向课程及教学实践,以及资源管理和软件开发的需要,并综合其他相关因素形成。

2.教学资源目录树构建

目录树是指存储有关网络资源信息的特殊数据库,把网络环境中的各种资源都作为目录信息,在目录树结构中分层存储、访问、管理和使用。目录树将分布式系统中的用户和资源,以及其他对象统一组织起来,提供一个单一逻辑视图,允许用户透明地访问网络上的资源。一个由目录树支持的网络系统是一个集成、网络化、统一的系统,而不是各个独立功能部分的简单聚合。

目录的内容称为对象类(ObjectClass)和项(Entry)。对象类描述什么信息可存储在目录中,而项把相关信息组合在一起,也可以理解为对象为抽象约束,项为信息内容。ERI之上的ERII逐层抽象或封装生成,下层的ERII是上次ERII的一个项,这是逐层递归或递推的过程,因此它们采用一致的管理操作方式,软件算法具有可复用性。元数据信息采用数据库方式存储,方便检索管理,而资源本身仍以文件方式存储于磁盘。为了管理的方便和统一,资源库的物理存储与资源管理的目录树结构基本保持一致。通过目录树方式记录存储教学资源数据信息,与资源库本身的层次结构(树型结构)相统一,同时也与Internet及各种管理中的层次结构相一致,为教学资源管理提供方便,易于使用现有技术手段进行管理。

3.教学资源服务

在教学资源库中,资源建设是基础,资源管理是关键,要对资源进行深层次的应用,就需要对资源进行规范化建设和管理。资源提供者对资源进行存储、传输等控制管理,资源的搜索、协调传输等任务主要由资源管理者完成。网格资源管理的目的是有效调度、管理、配置可利用资源,将实际上的异构环境转换成一个虚拟的同构环境。基于网格的教学资源管理是网格资源管理的进一步延伸,需要完成资源寻址和定位,找到特定的教学资源。教学资源本身也属于网格资源的一部分,教学资源节点与网格节点也是统一的。在基于网格的教学资源管理中,选择基于代理的网格资源管理方法,满足教学资源访问中的结构关系,能够方便地搜索到资源及资源信息所在的服务器,与Internet和网格层次管理结构一致,而且层次化的代理体系也有利于系统的维护和管理。代理系统在用户和资源之间架起了一座桥梁。基于网格的教学资源体系,通过代理的方式将异构、分布的大型教学资源库中的资源进行提取共享。通常一个资源请求任务被派分给一组Agent,这些Agent根据被请求资源特征,在构造层各计算节点间自主地移动,寻找资源信息,获得资源服务,完成自身的任务,满足用户在广域范围内对教学资源的个性化请求。代理结构由三部分组成,如下图所示。

上面是用户(消费者),提供资源服务请求;下面是资源提供者,提供教学资源;中间是代理服务系统。消费者通过就近代理(或网格结点)提出资源服务请求,代理通过当前获得的资源信息ERI以及资源目录信息ERII,进行分析计算,并根据结果将请求任务分发到相关的代理,进一步处理;最后根据获得的教学资源分布信息,按照一定的模式交付给用户。

结束语

元数据管理 篇9

随着数据仓库及其相关技术的不断成熟,基于数据仓库的各种工具也层出不穷。为了支持整个数据仓库环境的无缝集成,这些工具需要彼此协作,使数据流能在各个工作环节中顺利流动,同时尽量保证信息的完整性和正确性,为了做到这一点,数据仓库中的元数据必须有统一良好的定义。

元数据管理和集成是数据仓库和商业智能中首要的问题。目前,元数据管理结构有两种,一种是集中式的元数据管理结构,即整个系统只有一个元数据仓储,所有工具和数据仓库直接访问中心元数据库,但这种结构只适合中小规模的企业。对于大型企业数据环境较为复杂的应用场景,集中管理几乎不可能,所以通常采用分散式的管理结构,这种结构是建立若干个分布的、相对自治的元数据仓储,全局元数据由共享元数据模型来管理,这种结构虽然分散管理元数据,但在共享元数据部分还是要解决元数据异构的问题,而且这些分布的、自治的元数据仓储间的集成不可避免的要用到元数据交换协议,因此也延长了开发周期[1]。

本文针对分布、异构系统间的集成问题,使用了一种基于模型驱动的方法,并通过使用CWM交换技术来减少数据交换的工作量,使得元数据仓储间能方便地交换数据仓库和商务智能元数据,使得基于CWM模型开发的元数据管理系统有很好的通用性。

1 相关工作

目前,不同开发商的数据仓库工具所基于的元模型基本都是私有的,即它们对待自己元数据的内容结构有不同的表示和解释。这样,如果这些工具和元数据仓储需要集成,相互的映射会十分复杂,各种数据仓库工具两两间必须建立“元数据桥”才能协同工作。当工具数量较大时,“理解”的代价将是巨大的[2]。而且,各种元模型在表达力上也会有差异,这就会导致映射的不完整。因此,如果存在一种通用的数据仓库元模型许多问题就能简化。

对于元数据管理的研究国内外都有一些成果,在国内,由中国科学院提出的“核心元数据标准”。该标准的目标是为科学数据库数据集提供一套通用的描述元素和规范,以及为服务提供一套通用的描述模型和规范,从而在不同层面上为科学数据库数据资源的检索、整合、交换及其他应用提供支持。

而在国外元数据管理出现一种新方法,即模型管理。它将提供比现有技术更高抽象层次的程序设计接口,其主要抽象概念是模型(如对象图、接口定义等)和模型间的映射(mapping)。模型管理通过算子对模型和映射进行操作,实现每次按模型处理(model-at-a-time)方式,从而提高系统开发人员的工作效率。元数据管理在支持数据仓库处理流程中涉及到大量模式匹配、集成和进化操作。模型管理试图将这些目前必须由手工完成的操作实现部分自动化。模型管理的研究和实现仍处于初始阶段,未来的研究将集中在合并、组合等算子的语义和实现上等。

本文就是基于模型管理的思想并结合CWM模型,针对关系数据源运用CWM进行深入讨论和建模,使得所有支持CWM标准的数据源都具有很好的通用性。

2 CWM介绍

2.1 CWM的概念

CWM是基于模型驱动的思想,并在此基础上制定的一个使用共享元数据的集成数据仓库和业务分析工具的开放式行业标准,它完整地描述了数据仓库和业务分析领域的各个方面,为元数据定义公共元模型和基于XML的交换格式。作为一个元模型,CWM提供构建元数据所需的语法和语义,其目的是将数据仓库和业务智能领域共享元数据交换格式标准化,将访问元数据的编程语言API标准化,描述一个完整的数据仓库系统的所有组成部分。CWM是基于以下三个工业标准[3]:UML(Unified Modeling Language)统一建模语言;MOF(Meta Object Facility)元对象工具以及XMI(XML Metadata Interchange)XML元数据交换。

2.2 CWM的结构

从总体结构上看,CWM 共分5层、22个包和204个类。几乎每个层、每个包和每个类都有自己独立的功能,然而彼此之间又是紧密联系的。在包的内部结构方面,上层包中的类和关联继承下层包中的类和关联,或者直接使用下层包中定义的类或关联,这样组织既使CWM在功能层次上清晰有序,又控制了整个元模型的复杂性和规模。其中,资源层的对象包不是独立存在的,这是因为利用对象包来实现对象模型的功能,在对象模型层中已经完全实现。在其余的21个包中,有20个包要求在实现中存在一个或多个其他包,唯一不需要其他包支持的是核心包,其他所有的包都依赖于这个包[4]。CWM元模型的5层结构如图1所示。

CWM的元模型框架,从上到下依次为对象模型层 (Object Model)、基础层(Foundation)、资源层(Resource)、分析层(Analysis)和管理层(Management)。每层又由若干块组成,每块代表CWM的一个元模型或元模型包。下面分别对图1中CWM每一层的功能进行介绍[5]。

1) 对象模型层

对象层包含定义基本元模型的概念、关系和约束的基础包。这些概念为定义其它的CWM包创造了一个清晰、良好的环境,使得它们能够专注于各自的任务,而将与系统基础结构和细节处理交互的部分减少到最小。对象模型层与UML关系密切,是UML的一个子集。

2) 基础层

基础层的元模型是对对象层模型的扩展,用以表示数据仓库系统中所有组件所需要的公共服务,具有通用性。

3) 资源层

描述各种类型数据源的数据结构。例如,面向对象数据库或者应用、关系数据库管理系统、文件或记录模型数据库管理系统、多维数据库以及XML数据流等。

4) 分析层

在分析层中最重要元模型是转换元模型。不仅可以定义数据资源模型之间源和目标的映射及转换,还可以定义数据资源模型和各种分析模型之间源和目标的映射及转换。分析层还提供其它一些元模型来对面向分析的元数据进行建模

5) 管理层

CWM的管理层定义了两个重要的元模型:数据仓库处理元模型和数据仓库操作元模型。数据仓库处理元模型主要用于对某些特定的数据仓库处理过程进行建模。数据仓库操作元模型定义了周期性例程操作的元数据,这些元数据对于ETL工具、基于时间的高度工具具有十分重要的作用。

3 CWM的应用

本文通过一个实例来说明如何将二维表中的数据进行建模,所选择的实例数据来自上海市浦东数据中心项目中如表1所示。

将物理关系表进行建模,我们需要用到CWM关系元模型。表1中包含四个字段,BM(主键)、SNAME(站名)、NAME(出口)、LINE(地铁线名)。为了对这样的关系表建模,我们需要知道用到哪些包。在图1中我们可以看到这些包的结构,每个包都是独立的,而且每个包的元模型都是唯一存在的。同时,前面提到了上层的包依赖于下层中的某些包(但不是所有的包),这样使得我们在解决问题时只用几个包就可以。一个特定的CWM元模型只依赖于块状图中位于它下方的包,即只需要它所依赖的那些元模型包辅助实现,而与其他包的实现无关。因此,这个实例用到的包只是所有包的子集,如图2所示灰色的部分就是我们使用到的包。

在这个实例中,我们选择关系型包,因为关系型包描述了访问关系数据所涉及的所有方面,包括:关系数据库的总体结构;表、列和数据类型;数据类型与扩展;关键字、索引、触发器、存储过程以及关系实例的构成规则。另外,我们需要定义表中的主键,所以用到了基础层中的键和索引包。

对象层的核心包是建立任何模型都要用到的,因为核心包中包括了所有其他CWM包使用的基本类和关联,它不依赖于任何其他的包。核心包包括UML基础结构,用来定义非面向对象的数据存储,如:关系型数据库和记录文件。核心包也支持其他包使用的类和数据类型。

根据二维表字段的描述,我们得到实际的用例如图3所示。地铁出入口表中包含4列:SM、SNAME、NAME、LINE,其中SubwayKey是地铁出入口表的唯一约束,用来唯一标识不同的数据行。这个例子说明CWM元模型可以将关系表描述成设计元素。

这样描述二维表也许还对CWM如何将二维表建模并且实现这一过程比较模糊,我们使用时序图来说明一下CWM元模型,时序图中描述了系统中对象间信息交互的过程,并且描述CWM元模型的API如何工作,我们根据这个例子做出的时序图,如图4所示。

图4中的时序图是使用CWM元模型的API,建立和关联关系对象。CWM规范不包含这样的API,这些API是第三方根据规范提出的。关系表的时序图对图3建立的关系表实例图进行了小的修改,在CWM元模型中不存在RelationalObjectFactory对象,这是我们自己定义的,所以我们首先要创建这样的对象,来使用它里面的方法。在这一过程中,信息通过factory对象传递。后面的create方法用来建立关系对象,而使用addFeature方法是因为在CWM元模型中关系表是分层的结构,而在关系元模型中,每一列都是一种属性。图中的UniqueCostraint类在关系包中,它的类型是UniqueKey这个在键和索引包中已经定义了。UniqueKey对象定义了一些结构特性,这样关系包中的UniqueConstraint可以以继承关系来关联关系列。

以上实例,只需要CWM相关包以及连接数据库的部署文件即可,表名作为Table类的属性,列名作为Column类的属性,这样就建立了表与类的映射。

4 结 语

元数据集成的问题是元数据管理的重点问题,而CWM作为一种通用的元模型很好的解决了由于元数据描述不一致而带来的数据集成的问题,同时提高了元数据管理系统的复用性。本文通过模型驱动的方式并结合CWM元模型,将元数据描述规范化,从而解决了数据集成过程中元数据异构的问题。

参考文献

[1]戴超凡,刘青宝,黄宏斌,等.数据仓库中的元数据管理[J].计算机工程与科学,2003(4):54-57.

[2]Doug Tolbert.CWM:A Model-based Architecture For Data Warehouse Interchange[EB/OL].http://www.isr.uci.edu/events/wesas2000/position-papers/tolbert.pdf.

[3]OMG Common Warehouse Metamodel(CWM)Specification.2003:17,2.

[4]夏秀峰,林桐,宋晓燕,等.基于CWM的ODS元模型设计技术的研究与实践[J].小型微型计算机系统,2008(1):99.

数据仓库中多维元数据的组织研究 篇10

数据模型是对现实事物的反映和抽象, 它可以帮助我们更加清晰地了解客观世界。多维元数据是任何数据仓库应用的必要组成部分。它用来描述应用的许多方面, 包括等级之间的关系, 存储的公式, 数据在聚合前还是聚合后被存储, 经常改变的信息, 时间系列的信息, 项的描述和报表的注释, 安全性和访问控制, 数据更新状态, 格式信息, 数据来源, 预计算表的可用性, 以及数据存储的参数等[1]。缺乏这些信息, 实际的多维元数据将是不可理解的, 并且不能灵活地查看和更新。

近年来, 多维数据的相关技术引起了学术界的关注。目前为止, 国外学者们研究成果中比较有代表性的多维元数据组织模型考虑了如何表示多维元数据集合的维层次结构的问题, 提出的多维元数据组织模型只是部分的间接支持维层次结构的表示, 而不能直接地表示多维元数据集合的完整维层次结构[2]。国内对多维元数据组织的形式化等研究工作才刚刚起步, 陈微、李琪等人在这个领域进行了一些有益的探索。陈微等提出了一种对多维元数据和在多维数据库上进行的查询/统计模型化的方法, 给出了模型化的形式定义。着重讨论了多维元数据库维的划分问题, 以函数依赖为主要依据, 提出各维应满足正交限制条件, 并给出了维的划分算法。李琪、白英彩等提出了一种基于关系数据库的SQL的多维元数据组织概念模型, 该模型的层次链、层次树、维的定义支持不平衡、异构的维层次结构, 并在此基础上对SQL作了相应的扩充以支持多维的定义、多维层次比较、多维的引用和多维聚集层次的指定[3]。

本文就是主要研究数据仓库中的多维元数据, 提出了一种数据仓库的多维元数据组织模型, 提供了复杂多维层次结构表达机制, 能够很好地表达数据仓库的各种复杂层次数据结构和语义。

2. 数据仓库中多维元数据的设计

2.1 多维元数据的结构设计

多维元数据作为数据的数据, 可对数据仓库中的各种数据进行详细的描述, 说明每个数据的上文关系, 使每个数据具有符合现实的真实含义, 使最终用户了解这些数据之间的关系。数据仓库中多维元数据的主要工作是把所需的数据仓库工具集成在一起, 完成数据的抽取、转换和加载, OLAP分析和数据挖掘等[4]。如图1所示, 它的典型结构由操作环境层、数据仓库层和业务层等组成。

其中, 第一层 (操作环境层) 是指整个企业内有关业务的OLTP系统和一些外部数据源;第二层是通过把第一层的相关多维元数据抽取到一个中心区而组成的数据仓库层;第三层是为了完成对业务多维元数据的分析而由各种工具组成的业务层。图1中左边的部分是元数据管理, 它起到了承上启下的作用, 具体体现在多维元数据是进行数据集成所必需的;多维元数据定义的语义层可以帮助最终用户理解数据仓库中的数据;多维元数据是保证数据质量的关键;多维元数据可以支持需求。

在数据仓库环境中的多维元数据所扮演的角色和在操作型环境中数据所扮演的角色是不同的。在操作型环境中, 元数据几乎被当成文档来处理并且降低到同样的重要性级别。然而, 在数据仓库环境中, 多维元数据的重要性提高了。因为数据仓库多维元数据是给DSS分析者用的, 在DSS分析者计划该怎样去做信息型/分析型处理时, 他们要首先去看多维元数据。

2.2 多维元数据的维度建模

在数据仓库的整个设计过程中, 始终围绕的概念是元数据的维度。一般地, 元数据的维是关于一个组织想要纪录或透视的实体, 每一个维都有一个表与之相关联, 该表称为元数据的维表, 它进一步描述维。维度建模用于数据仓库数据库的设计中, 其目的是组织元数据以提高在分析和汇总大量元数据的查询效率。

元数据的维度建模针对零散的业务进程创建个别的模型。例如, 销售信息可以创建为一个模型, 库存可以创建为另一个模型, 而客户也可以创建为另一个模型。每个模型捕获事实数据表中的事实, 以及那些事实在链接到事实数据表元数据的维度表中的特性。元数据的维度建模将信息组织到结构中, 这些结构通常对应于分析者希望对数据仓库数据使用的查询方法。

元数据的维度表包含描述事实数据表中的事实记录的特性。元数据的维度表包含帮助汇总数据的特性的层次结构。例如, 包含产品信息的维度通常包含将产品分为食品、饮料、非消耗品等若干类的层次结构, 这些产品类中的每一类进一步多次细分, 直到各产品达到最低级别[5]。元数据的维度建模产生维度表, 在元数据的维度表中, 每个表都包含独立于其它维度的事实特性。例如, 客户维度表包含有关客户的数据, 产品维度表包含有关产品的信息, 而商店维度表包含有关商店的信息。查询使用元数据维度中的特性来指定对事实信息的查看。

3. 数据仓库中多维元数据的操作

与关系数据库不同, 数据仓库并没有严格的数学理论基础, 它更偏向于工程。由于数据仓库

的这种工程性, 因而可以根据它的工作过程分为:多维元数据的抽取、转换、存储和管理三个方面。建立好数据仓库之后, 还应该通过OLAP (联机分析处理) 建立起多维数据集, 然后通过一定的分析工具, 得出最后的分析结果, 整个设计如图2所示:

3.1 多维元数据的抽取

多维元数据的抽取是数据进入数据仓库的入口。由于数据仓库是一个独立的数据环境, 它需要通过抽取过程将数据从联机事务处理系统、外部数据源、脱机的数据存储介质中导入到数据仓库。多维元数据抽取在技术上主要涉及互连、复制、增量、转换、调度和监控等几个方面。数据仓库的数据并不要求与联机事务处理系统保持实时的同步, 因此多维元数据抽取可以定时进行, 但多个抽取操作执行的时间、相互的顺序、成败对数据仓库中信息的有效性则至关重要。

3.2 多维元数据的转换

针对多维元数据的转换操作, 本文以SQL Server为例进行研究。SQL Server数据库可以有6种多维元数据转换的方法:通过DTS设计器、利用Bcp工具、利用备份和恢复、直接拷贝数据文件、在应用程序中定制和通过SQL Server的复制功能。我们采用DTS设计器对多维元数据进行转换。

多维元数据转换服务 (DTS) 通过提供一组工具, 将来自完全不同的源的数据抽取、转换和合并到DTS连通性所支持的单个或多个目的, 以满足需求。通过使用SQL Server可以创建数据转换服务 (DTS) 包。具体步骤

分为:

(l) 选择源、选择目的;

(2) 在源和目的之间建立连接;

(3) 指定要移动的多维元数据以及希望使用的转换方法;

(4) 保存包、执行包。

在具体的应用中, 可以将需要的多维元数据从不同的数据库中提取并转移到指定的数据库, 以建立数据仓库。其具体是事实表和维度表的建立和转换。

3.3 多维元数据的存储和管理

数据仓库遇到的第一个问题是对大量多维元数据的存储和管理。这里所涉及的多维元数据量比传统事务处理大得多, 且随时间的推截而累积。从现有技术和产品来看, 只有关系数据库系统能够担当此任。关系数据库经过近30年的发展, 在数据存储和管理方面已经非常成熟, 非其他数据管理系统可比。目前不少关系数据库系统已支持多维元数据分割技术, 能够将一个大的数据库表分散在多个物理存储设备中, 进一步增强了系统管理大量多维元数据的扩展能力。

4. 结语

将数据仓库中的海量数据引入到多维元数据模型中, 并对其进行OLAP操作面临着巨大的技术挑战, 同时也是非常有意义的。目前, 面对数据膨胀和信息相对贫乏的局面, 多维元数据模型的引入使得从大量空间数据中获得信息变得更快捷, 同时也为进一步挖掘空间知识提供了坚实的基础。

参考文献

[1]王奕, 范通让.多级元数据查询系统体系架构的设计与优化[J].现代图书情报技术, 2007, (12) .

[2]L.Cabibbo, R.Torlone.Querying Multidimensional Databases.In:S.Cluet, R.Hull, eds.Database Proceeding Language, 6th International Workshop.Estes Park, Colorado, USA:Springer, 2007, 319-335.

[3]Coliat G.OLAP, Relational, and multidimensional database system.SIGMOD Record, 2006, 25 (3) :64-69.

[4]曾瑞, 陶跃华.数据仓库中多维数据模型的设计[J].云南师范大学学报 (自然科学版) , 2006, (06) .

新的管理模式:元服务系统的构建 篇11

物联网是近年来出现的一种信息技术，它提出的物质信息之间的联系，信息的可靠传输以及智能管理等丰富了信息化管理的内容，同时，也提出了很多新的问题，如云计算等，这些方面的研究在参考文献[1]中得到了很好的总结。然而，物联网主要是从技术角度提出的信息化管理模式，而在城市管理中，人的因素是非常重要的。笔者曾经提出的GBCP管理模式[2][3]是一种既考虑了信息化管理，又考虑了人的因素的管理模型。在经典的GBCP理论中，我们考察了政府（G）、企业（B）、公众（C）与公共物品（P）之间的动态关系，建立了静态、动态两种模型，并在此基础上，讨论了物质信息系统的基本性质[4]，然而，这些讨论的一个前提假设是所有的公共物品都可以看成是点，即不考虑形状和位置，并且考虑的重点为单个GBCP环的性质和规律，这样与实际应用还有一定的距离。为此，在原有GBCP理论的基础上，本文提出了一种新的管理模式：“网元化服务系统”。这种管理模式借鉴了物联网的基本思想，即物质信息的对应、转换关系，智慧管理（包括机器和人的智能管理）等，又兼顾人的因素，实现了“以人为本”的管理目标。

在网元化服务系统中，主要考虑的因素有：物质所存在的环境，即三维现实空间、时间因素以及网元系统运行所需要的金钱等成本，我们称之为能量。于是由三维现实空间、时间、能量这五个相对独立的因素，构成了一个五维空间，并在这五维空间中，讨论网元系统的运行。

二、网元的构建与运行模式

（一）网元的构建

首先，适用网元化服务的系统范围，即哪些系统适合网元化管理，称之为元系统，一般具有以下特征：

1.系统中有物质、信息和人，物质和信息存在着对应关系，在一定条件下可以转化，信息可以传递（用一句话概括，就是高度信息化）；

2.系统在正常运行下，具有某种功能，这种功能服务于人；

3.如果系统中的物质的属性发生改变，从而影响功能的话，系统自身有能力修复此物质的属性，使之重新具有原功能。

比如城市管理系统中，以道路照明的路灯为例，所有维护路灯照明的企业、主管部门以及公众就可以形成一个元系统，这里路灯是物质，系统的功能是照明，为公众服务。如果路灯属性改变（坏了），那么就会产生对应的信息的改变，信息可以传递，最终结果为路灯修好了（信息与物质转换）。这个过程就是经典的GBCP模式所描述的过程。由此可见，如果在城市部件都已经信息化的假设下，城市管理系统就可以看成是一个元系统，笔者研究的重点，不在于元系统的构建和如何运行，而是如果系统的物质的性质发生改变，影响到系统的功能时，系统如何更好地修复此功能。

为了研究方便，可以给出如下概念：

（1）元系统的稳定：是指元系统能够保证功能正常运行；（2）事件：影响元系统功能的物质变化；（3）服务：系统所需处理的目标事件；（4）子服务：为了完成这个目标事件，可以把完成的过程分为若干个步骤或若干个子目标事件；（5）单位子服务：不能再分解的子服务；（6）网元：为了提供单位子服务，所需要的系统中元素的最小集合。

这里提出的不能再分解，主要依赖于元系统，是指在元系统中物质不能再分解了。比如城市管理系统就是一个大的元系统，可能有路灯坏了，可能有井盖丢了，等等，这些事件需要服务。如果有多个井盖丢了，那么每修复一个的过程就可以看成是一个网元。而如何制造、安装这个井盖，就不是城市管理系统所关心的范围了，因此可看成是一个网元。很明显，元系统中可能有多个网元，这些网元可以相互作用，但每个网元是相对独立的。

有了网元的概念，可以给出网元化管理的描述。所谓网元化管理，就是针对每个网元，利用GBCP的管理模式，利用物质、信息、人的相互作用与影响，完成单位服务，再经过服务的叠加，完成整个服务，使元系统恢复功能的过程。

这里要回答两个问题，一是为什么要选择GBCP管理模式；二是如何应用GBCP管理模式。

首先，可以看到，元系统是一个物质信息系统，同时，这个物质信息系统又有反馈的作用，即在处理事件的过程中，元系统的某组成部分（比如说“人”）会对事件的处理的进程和结果有作用；同时，每处理完一个事件之后，本次处理的结果都会对下一个事件有作用。正是通过对这种具有反馈作用的物质信息系统的研究，提出了GBCP管理模式，并指出GBCP模式可以很好的达到管理的目的（参见文献[5]，第六章）。

其次，如何应用GBCP管理模式的问题。在城市管理中，对于公共部件，我们给出了GBCP模式的理论和算法。那么在元系统中，其核心思想同样适用。因为在元系统中，三个重要的组成部分，物质（M）、信息（I）、人（M），构成一个MIM系统，而这个系统中最重要的还是人的作用。因为元系统的一个重要的功能就是“以人为本”，正是为了满足人的需求，一旦物质的属性发生改变（M>0），利用“物质-信息”相互转换这个工具，完成对物质属性的修复。这和GBCP理论中的产生带动整个GBCP环的形成的原理是一致的。所不同的是，元系统中的物质更为复杂，研究好元系统中物质的属性是建立网元化管理的关键所在，解决的办法就是利用五维空间中的三维现实子空间。

为了更精确表达网元化管理的过程和优势，要借助于数学模型。由于考虑元系统中物质属性的改变，物质属性中下列两个属性对于网元模式是很重要的：

几何属性：物质在现实三维空间中呈现的维数特征；功能属性：物质是否正常，即该物质能否保证元系统功能正常运行。

比如，在城市管理的元系统中，电线杆、井盖就可以看成是点状物质，即0维；公路、各种线路可以看成是线状物质，即1维；停车场、湖泊可看成是面状物质，即2维；商城、高层建筑等可看成体状物质，即3维。于是，在t时刻，物质的属性可表示为Mat(p,k,s,t)，其中p表示物质的位置信息；k为物质的几何属性，取值范围为（0,1,2,3）；s为物质的状态，s=0，表示物质功能正常，s=1表示物质功能不正常；t为时刻。

一般来说，对于高维（维数大于等于1）的物质，其状态不能简单地表示成正常或非正常，因为还要进一步确定非正常的部分（看成一个点），在高度信息化的假设下，用向量（或矩阵）的方法给出表达，比如对于1维物质（公路，河流等），可以采取的信息采集方式为：

简记为

其中，p为物质的位置信息，k=2为物质的维数，共mn个信息点，s(i,j)的取值为0或1，为第(i,j)个信息采集点的状态，t为时刻。

以此类推，3维物质在t时刻对应的信息为：

简记为

其中，p为物质的位置信息，k=3为物质的维数，共nml个信息点，s(i,j,h)的取值为0或1，为第（i,j,h）个信息采集点的状态，t为时刻。

以上笔者给出了从Mat(p,k,s,t)到Inf(p,k,s(i,j,h),t)的过程，然而，为了以GBCP管理模式进行网元化管理，还必须引入“人”的因素。首先，从Mat(p,k,s,t)到Inf(p,k,s(i,j,h),t)，信息的采集可能靠传感器，也可能是人，对于人，或者说信息的采集者（对应GBCP中的C），用Man(p,k,C(i,j,h),t)表示，即在t时刻，对物品Mat(p,k,s,t)的部分(i,j,h)进行信息采集的人；如果采集的结果出现异常，要对这个异常信息进行处理，于是就要有具有管理职能的人（对应GBCP中的G），即Man(p,k,G(i,j,h),t)，把信息传递到提供或修复物品的人或企业（对应GBCP中的B），最终使物品Mat(p,k,s,t)中(i,j,h)部分的属性从s(i,j,h)=1变成s(i,j,h)=0。

于是可以看出，网元系统是按照物质(Mat)——信息（Inf）——人员（Man）的形式建立起来的，为一个MIM系统。

物质流，信息流，人员流的概念如下：

物质流：描述物质的属性在一段时间内随时间改变而变化的集合，用数学表达式给出为：{Mat(p,k,s,t)｜t(t0,t1)}，其中t0、t1分别表示首末时间点；

信息流：描述物质对应的信息在一段时间内随时间改变而变化的集合，用数学表达式给出为：{Inf(p,k,s(i,j,h),t)｜t(t0,t1)}，其中t0、t1分别表示首末时间点；

人员流：描述人员在一段时间内随时间改变而变化的集合，用数学表达式给出为：{Man(p,k,G(i,j,h),t)｜t(t0,t1)}，{Man(p,k,B(i,j,h),t)｜t(t0,t1)}，{Man(p,k,C(i,j,h),t)｜t(t0,t1)}，其中t0、t1分别表示首末时间点。

（二） 网元化管理的运行方式

网元化管理的运行方式，即GBCP模式、物质、信息、人员流互动模式，以及五维系统空间模式。对于一个网元，首先要注意它是提供单位子服务的，因此，这里的物质属性发生改变时，其对应的Inf(p,k,s(i,j,h),t)中，有且仅有一个s(i,j,h)=1,其余均为0。换句话说，就只有一处出现故障。

1.网元化管理的GBCP运行方式。（见图1）

首先，触发网元管理的原因是物质Mat(p,k,s,t)的s=1，因此由前述有且仅有一个s(i,j,h)=1，此信息由Man(p,k,C(i,j,h),t)获取，于是得到影射：TC:Mat→inf，TC(Mat(p,k,s,t1))=inf(p,k,s(i,j,h),t2)，这里s(i,j,h)=1。

第二步，此信息经由管理者Man(p,k,G(i,j,h),t)传递到物质的提供者Man(p,k,B(i,j,h),t)。

TG:Inf→inf，TG(Inf(p,k,s(i,j,h),t2))=Inf(p,k,s(i,j,h),t3)

第三步，物质的提供者Man(p,k,B(i,j,h),t)生产此物质，

TB:Inf→Mat,TB(Inf(p,k,s(i,j,h),t3))=Mat(p,k,s,t4)

此时，新的物质Mat(p,k,s,t4)的属性s=0。

这里的映射同样满足TCTGTB=I，即去掉时间因素外，复合映射为恒等映射。

2.网元管理的物质信息流模式（见图2）

图2为典型的物质信息流相互作用模型。从GBCP模式可以看出，网元化管理起始于物质状态的改变，即△s=1，终止也是物质状态的改变△s=-1，在这期间，物质、信息可以相互转变，即TC:Mat→inf，TB:inf→Mat，信息可以传输TG:inf→inf，最终形成物质流、信息流的相互影响，完成网元化管理。

这里还有人员流的概念，但在图中没有给出，事实上，人员流相对稳定，但其存在的必要性是：确保物质流、信息流能够顺利地形成并相互作用。

至此，笔者认为，单个网元的模型和GBCP模型基本一致。

三、网元系统的构建与运行模式

在元系统中，一旦功能出现问题，涉及的网元往往不止一个，那么在多网元情形下，如何确定管理模式呢。为此，笔者考虑了以下几种可能出现的情形。既然网元系统的核心思想是提供服务，因此，多网元系统的划分必然也是按照服务来划分的。首先，如果服务可以分解成若干个子服务，并且由这些子服务确定的网元中涉及的G、B、C都是互不重叠的，于是就可以简单的分析这些子服务是否有先后顺序，如没有，就可用并行式；若有，就是串行式；

（一） 网元系统的基本模式

1.并行式

在一个元系统中，若需要提供的服务可以分解为若干个子服务，且这些子服务确定的网元中Man(p,k,C(i,j,h),t)，Man(p,k,G(i,j,h),t)，Man(p,k,B(i,j,h),t)互不相同，那么就可以同时进行网元管理，最终提供系统的服务。

例如：在城市管理系统中，井盖和路灯同时坏了，用物质流、信息流可表示如图3。

2.串行式

在一个元系统中，若需要提供的服务可以分解为若干个子服务；且这些子服务确定的网元中Man(p,k,C(i,j,h),t)，Man(p,k,G(i,j,h),t)，Man(p,k,B(i,j,h),t)互不相同，但服务之间有先后次序，那么就要按子服务次序进行网元管理，最终提供系统的服务。

例如：井盖丢了，但在送新井盖的途中，交通发生了拥堵，这样，必须先解决交通拥堵问题，再解决井盖丢失问题，用物质流、信息流可表示如图4。

（二） 网元系统的其他模式

如果在一个元系统中，需要提供的服务可以分解为若干个子服务，且这些子服务确定的网元中Man(p,k,C(i,j,h),t)，Man(p,k,G(i,j,h),t)，Man(p,k,B(i,j,h),t)有相同的元素，可采用以下方式处理。

1.共享G式

如果在元系统中，若干个子服务共享Man(p,k,G(i,j,h),t)，那么可以按照并列式网元系统模型进行考虑，因为G是管理者，其在网元系统中主要起信息传递、监督的作用，因此，当两个网元在G处重叠时，可按并行处理。采用并行式管理模式。

2.共享B、C式

如果在元系统中，若干个子服务共享Man(p,k,C(i,j,h),t)，Man(p,k,B(i,j,h),t)，那么，可以按串行式网元系统模型处理，因为B、C承担着物质、信息转换的功能，如果上一个网元没有完成，下一个网元无法继续，因此，可以按串行式模型提供服务。

3.共享物质式

如果在系统中，对于同一个物质，若物质的几何属性为0，那么它的功能属性要么是0，要么是1。但是对于高维物质，可能发生同一物质在两个以上不同点同时功能属性为1的情形，比如，同一条公路上发生两处以上事故，同一个小区内出现多处垃圾污染等等，那么就需要根据物质的类型判断是并列式还是串行式了，比如，如果是公路拥堵问题，往往是串行式，但如果小区污染问题，又可以采用并行式了。

参考文献：

[1] C. Floerkemeier.The Internet of Things［M].springer, 2008.

[2]李立明，程永强，曹鹏.信息化城市管理和谐模型建模初探[J].城市管理与科技，2005，7（5）：183-185.

[3]李立明，程永强，曹鹏，等.信息化城市管理和谐模型建模再探[J].城市管理与科技，2005，7（6）:227-230.

[4]李立明，程永强，曹鹏.信息化城市管理和谐模式评价体系[J].城市管理与科技，2006，8（2）：51-53.

[5]李立明，等著.奥运城市运行系统设计与实现[M].北京：科学出版社，2009.

（责任编辑：黄荔）

元数据管理 篇12

在我国, 关系型数据库理论已广泛应用于零售超市营销数据管理。但是, 与沃尔玛、家乐福、麦德龙等国际零售巨头的先进的管理模式相比, 关系型数据库管理模式明显表现出对市场的预测和决策能力的欠缺。

企业管理决策的迫切需要, 使数据仓库理论应运而生。数据仓库技术是当前用于企业决策支持的、先进的有效方法。在国外大型超市的决策管理中, 已取得不菲的经济效益。

将“数据仓库”理论运用于我国大型连锁超市的决策管理, 是学习运用国内外先进的管理模式提高行业竞争能力的必然选择。

元数据是数据仓库的灵魂。元数据支撑了数据仓库开发应用的全过程, 成为连接数据仓库各部分的纽带。元数据管理是数据仓库项目成败的关键。

随着数据仓库技术的迅速发展, 对元数据的研究也步步深入。本文提出利用关系型数据库建立一个以CWM标准为基础的集中式的元数据库管理模式。使所建元数据库既保持CWM面向对象的基础, 又能充分利用SQL的成熟技术对数据仓库元数据进行有效管理。

二、CWM元模型

CWM公共仓库元模型是国际对象管理集团OMG推出的数据仓库元数据管理规范。CWM提出了一种共享公共元模型的思想交换元数据。它采用UML作为模型描述标准, 使用MOF作为元建模和元数据存储标准, 使用XMI作为元数据交换标准。CWM的主要目的是在分布异构环境下, 使数据仓库工具、工作平台和元数据存储库之间易于进行数据仓库元数据的交换。

基于CWM模型的三个标准, CWM为数据仓库工具之间共享元数据, 制定了一整套关于模式、语法和语义的规范。

CWM使用包机制来组织元模型, 每个包代表CWM的一个元模型。图1描述了CWM元模型的构成。所有的包按功能和抽象层次组织成5层, 每层都涉及一个独立的领域, 有自己独立的功能, 然而彼此之间又紧密联系。

1. 对象模型层:定义了基本元模型的概念、关系和约束。

2. 基础层:包含了所有包共享的概念、结构和通用服务。

3.资源层:资源层上的数据包描述了基于CWM的元数据交换中的各种数据资源的元模型。用来创建那些定义关系数据库、面向记录数据库、多维服务器和基于XML文档的数据资源的元数据。

4.分析层:业务分析概念, 是数据仓库和信息供应链的核心和目标。

5.管理层:主要描述了支持数据仓库日常操作和管理的通用服务。

UML、MOF、XMI、CWM等一系列标准提供了一个能够全面描述数据仓库元数据的框架。CWM已成为了业界统一开放的元数据集成标准。为数据仓库元数据的规范管理平了道路。

三、建立基于关系型数据库的元数据库

CWM元模型是一系列面向对象的UML类图;关系数据库管理系统是当前成熟的主流数据库。建立基于关系型数据库的CWM元数据库, 关键问题是实现CWM对象元模型到关系模型的映射。

CWM中共有204个类, 154个关联, 三种数据类型属性。只要能将CWM元模型中所有的类、关联和数据类型属性的逻辑结构完全映射转化成关系型数据库可用的存储结构, 就可以利用关系数据库的一切方法和技巧对元数据进行管理。

首先, 用T-SQL语言建立一个关系型数据库。用以存储经过映射转换的CWM元模型。

1. CWM类的映射

CWM类的映射是构建元数据库的核心。实现CWM类的映射的基本方法是:

为CWM元模型的204个类分别在关系型数据库中建立一个映射关系表, 这个表称为每个类的固定表。为便于对固定表的识别和调用, 需要统一各个固定表的各组成部分的命名规则。每个固定表的表名由被映射的类所属的包名-类名构成。每个固定表中都有一个整数型的字段, 字段名为“IDn”, 作为固定表的主键, 标识不同的对象。“ID”后加的“n”是一个任意的不重复的整数, 其作用是在建立两个固定表的关联时, 便于区别不同固定表的ID。类的每一个属性映射到该类所对应的固定表的一个列。其属性名作为固定表的列名。列的数据类型同类的属性的数据类型保持一致。表中的每一行存放对应于映射到固定表上的该类的一个实例, 即该类的一个元数据。行中的列值记录的是实例的单值属性的当前值, 如图2所示。

至此, 对于单值属性的类得到了完全映射。以此为基础, 可以实现非单值属性类的映射。

CWM非单值属性类包括多值属性、枚举属性和基于类的继承属性, 如果将这些信息全部映射到一个表中, 会带来大量的存储冗余, 也不方便管理。针对这些情况, 可通过增加另外的独立表——附加表, 将每个多值属性映射到一个附加表中, 这些表使用外键的标识值连接到类的固定表上。同固定表一起组成表集来表示CWM类。

在CWM中大量使用了UML的继承特性, 为保证类的继承结构映射到元数据库不变, 将层次结构中的每个类映射到独立的表上, 通过一个共享标识值“IDn”与它的超类和子类相互链接。从而静态地反映类之间的继承关系。

2. CWM关联映射

CWM元模型中共有154个关联, 其中包括5个“一对一”关联, 101个“一对多”关联, 48个“多对多”关联。通过映射已经建立了CWM元模型204个类的固定表, CWM元模型中类的关联就体现在元数据库中已建立的固定表的关联。关系数据库中表的关联依赖于表中匹配的主键和外键。

一对一的关联映射:可通过直接向关联的类的固定表中增加一个列, 该列存放关联表的主键, 且列名和数据类型不变, 并设为关联表的侯选主键, 同一实例在相互关联的基本表中的ID值相同。如图3所示。

一对多关联是关系数据库中最普遍的关系。建立一对多关联映射, 需要在“多”方固定表中增加一个字段, 把“一”方固定表的主键添加到“多”方的固定表中, 作为“多”方固定表的外键, 并建立普通索引。“一”方对应的“多”方重复的记录, 具有同一外键值。通过对外键的普通索引, 实现两表一对多关联。如图4所示。如果关联的多端有序, 则在多端的固定表中增加一列用于存储多端实例次序的顺序值。

对于多对多关联, 解决办法是:在多对多关系表之间创建第三个表, 称为“中间表”。将两个相关联的固定表的主键都添加到中间表中。其作用效果是把一个“多对多”关系分解成为两个“一对多”关系。通过中间表实现“多对多”关联。如图5所示。而对于有序的关联则增加一列用来存储实例的顺序值。

3. CWM数据类型映射

CWM共有三种数据类型:简单数据类型、枚举类型和对象类型。这三种数据类型需要用不同的方法映射到关系数据库中。在处理好了CWM类的映射和关联映射的基础上, CWM数据类型映射就容易实现了。

简单数据类型映射:CWM中的8个CWM简单数据类型, 可直接与关系数据库的对应的数据类型建立映射。

枚举数据类型映射:为每种枚举类型建立一张附表, 该表仅有一列, 用来记录该枚举类型所有可能的取值。

对象数据类型:使用外键约束, 将基础列与基于类的类型实例相关联。

固定表、中间表、附表和关联表共同组成元数据库的主体部分。为管理方便, 可再建一个汇总表。

汇总表列出CWM元模型全部类所映射生成的固定表的清单。该表的主要字段有:ID、固定表表名、关联、属性及实例等。通过简单查询就可以得到每个固定表所对应的CWM元模型的包、类、关联、属性及实例等相关信息。

四、建立基于CWM的数据仓库元数据转换模式

存储在元数据库中的元数据, 应当是符合CWM规范的元数据。因此, 入库前, 所在元数据都需要通过规范的转换。

根据CWM提供的数据仓库元数据管理规范和工作机制, 建立基于CWM的数据仓库元数据转换模式, 如图6所示。在建立该模式之前, 我们已经通过映射, 建立了关系型的元数据库。从图中可以看出该模式的工作原理:

通过支持CWM规范的元数据采集工具, 在数据仓库开发应用的全过程中, 实时地扫描采集各类元数据。这些元数据包括:从数据仓库的数据模型获取的元数据;从数据仓库的结构获取的元数据;从多种数据源中获取的元数据;通过数据仓库ETL过程获取的元数据;从多种业务指标中获取的元数据;通过数据仓库中的数据流及其处理过程获取的元数据;从数据仓库的端展现工具、CASE工具和数据挖掘工具等工具中获取的元数据, 以及为用户的访问权限设计产生的元数据。把获取的各个层次的异构的元数据, 经过CWM元模型的分类、映射和转换, 通过CWM XML、CWM DTD、CWM IDL三个规范, 转化为XML文档, 成为CWM元模型中类的实例。

这里特别要强调的是, CWM元模型分析层中的转换包在本模式中的重要作用。

转换包是CWM分析层中最重要的元模型。是整个CWM元模型的中心。从各个方面获取的元数据, 经过转换包的处理, 它定义的建模元素指定了源和目标元数据的映射及转换。这个转换通过资源层和管理层共同实现。

资源层定义了描述各种不同类型的数据资源元数据的模型, 这些元模型的实例描述了转换源数据存储格式和目标数据存储格式的元数据;管理层定义了数据转换的调度和执行方面的元数据模型。包括用来描述数据转换工具的元数据的类和关联。

从各个方面获取的元数据, 作为CWM元模型类的实例, 存储在该类所映射的固定表中, 完成了元数据库的基本建设。至此, 我们就能利用SQL的一切功能来对元数据库进行有效管理。在本模式中, 利用了SQL Server中的一个重要组件DTS (Data Transformation Services) 作为元数据库接口。DTS是SQL Server中导入导出数据的核心, 它除有具有SQL和命令行工具bcp相应的功能外, SQL Server为DTS提供了图形用户接口。使DTS成为用户使用多种方式访问和利用元数据库的通道。

五、结论

数据仓库元数据管理, 是一项重要而复杂的工作。本文以业界认同的CWM元模型为基础, 通过映射, 把对象型的数据模型转换为关系型数据模型来处理。以便利用关系型数据库的方法和工具对数据仓库元数据进行管理、调用、交换和访问。这种模式, 实用性强, 作为数据仓库元数据管理的一种方法, 具有进一步研究、完善的价值。

参考文献

[1]刘中蔚陈红:用基于元数据库的工作流调度数据仓库的更新[J].计算机应用研究, 2006, 23 (3) :178-180

[2]雷启明周利平:连锁超市数据集市的数据模型设计研究[J].商场现代化, 2008.7.30-31