当前位置：文档库 › 名人手稿馆元数据方案的设计

名人手稿馆元数据方案的设计

上海图书馆名人手稿数字图书馆课题组?

（上海图书馆 200031）

文摘：本文论述了上海图书馆名人手稿馆元数据方案的设计，说明了设计时的总体考虑、设计原则、设计流程及元数据方案针对的资源特点；并简要介绍了最终成型的元数据方案，包括对方案性质的定位、方案的组成、方案的属性元素集、置标方案及著录规则等内容；最后提出了一些方案制定中的问题期望能与国内同行共同商讨。

关键词：元数据；元数据应用；数字图书馆；手稿；DC元数据；上海图书馆

Abstract: This paper is a description on the implementation of a metadata profile derived from multi metadata standards and specifications for CHINA CULTURAL CELEBRITIES' MANUSCRIPTS LIBRARY. Firstly, we gave an introduction on the general considerations, principles, procedure approaches and characteristics of the resources. Secondly, we explain the whole metadata profile, including the functions, documents, elements in the metadata profile, metadata encoding schema and the rules for cataloging. At last, a few big issues in the design of metadata profile have been discussed.

Keywords: metadata, metadata application, digital library, manuscripts, Dublin Core, shanghai library

名人手稿是上海图书馆的特藏之一。上海图书馆自1992年开始恢复向社会各界征集名人文献的工作，1996年新馆开放后，更是加快步伐、增强力度进行收集整理，目前藏品逾5万2千余件。2002年12月上海市政府推出“外滩源”改造规划1，位于上海外滩黄金地段虎丘路20号的上海图书馆分部将成为名人手稿馆的新址，建设一个名人手稿数字图书馆是其中的一项重要工程。

根据实际情况，名人手稿数字图书馆的建设将分期进行。在大规模地数字化之前，名人手稿数据库的建设将先期完成，同时进行数字图书馆系统的设计和试验性数字化，形成名人手稿数字图书馆的一个原型系统，供研究、演示和进一步修改完善后投入使用。

项目开始之初，课题组从元数据标准规范和数字化项目两个角度进行了全面考察。国际上类似的项目只有近期完成的“欧洲手稿与书信网络集成(MALVINE)”2项目在需求、复杂程度和技术环境方面最为接近，于是我们与该项目的人员取得了联系，获得了其完整的元数据元素列表。但由于该项目是一个手稿与书信的联合目录项目，采用的属性元素集合没有考虑直接执行有关的元数据标准，因此我们仅仅从属性元素的选取方面参考了该项目，在体系结构和方案设计上没有太多的借鉴。

名人手稿数字图书馆的开发目的是对名人手稿馆所涉及的所有资源进行有效的管理和利用。元数据方案是数字图书馆需求分析和系统设计时需要首先考虑的因素，是数据加工制作、藏品数字化和系统设计与功能实现的基础。制定名人手稿馆元数据方案的目的是提供其

?上海图书馆名人手稿数字图书馆课题组成员有：祝均宙，刘炜，赵亮，浦纯，楼向英，张春景，夏翠娟，孙秀娣，王洪治，徐频，朱小灵，王恺顺。本文执笔：刘炜，楼向英

所涉及的所有资源类型的属性定义和置标方案（也就是相当于传统上的制定编目规则和目录格式），为名人手稿数字图书馆提供资源管理（又称为内容管理）方案。元数据方案基本上决定了系统的整个架构，以及系统设计（包括各类著录系统、检索系统、管理系统等）的需求。

名人手稿馆馆藏在许多方面不同于图书馆传统的资源，它是文献和文物的结合。其元数据方案也不同于一般博物馆的元数据方案。与通用元数据标准的制定所不同的是，后者考虑更多的是互操作性和通用性，需要进行许多妥协和折衷，会牺牲许多个性和细节，而“名人手稿馆元数据方案”必须详尽地考虑和满足资源管理、保存、揭示、检索、利用等各方面需求，同时也要在实现众多个性化的需求之外，保证与上海图书馆的整个数字图书馆架构兼容，甚至与正在制定中的国家标准兼容，并符合国际上通行的标准和做法。只有这样，才能实现较高的互操作性、灵活性和可扩展性。

总体考虑

由于名人手稿馆的馆藏资源丰富，种类繁杂，本方案所针对的对象不仅仅是名人手稿，确切地说应该是“名人手稿馆信息系统元数据方案”，包括创作手稿、信函、书画篆刻作品、照片、签名本、日记、录音/录像资料、奖状奖章等各方面的资料，并且有可能还会增加。对于这样一个复杂的系统，系统设计的开放性、灵活性、可互操作性和可扩展性就显得非常重要，而且还要兼顾其永久保存的特性和整个信息处理流程易管理性的考虑。

按照传统的方法，可以请负责系统设计的计算机专家、资源管理部门的文献专家和系统将来的用户一起，对每一种资源类型乃至整个系统提出详尽的著录、检索和其他功能需求，然后通过开发专用的数据库系统来实现。这样做的问题是，系统一俟开发出来，就可能是一个“遗留系统”，虽然能够实现名人手稿馆对于信息管理的需求，但是不具有数字图书馆所要求的开放性、互操作性和可扩展性，将对上海图书馆现有的计算机信息管理系统带来新的互操作问题，也很难在资源内容上方便地与其他“数字图书馆”系统互通互联。整个系统将成为一个典型的“封闭系统”而不是“数字图书馆”。

或者可以按照目前“数字图书馆”的一般设计方法，制定一个包含“核心”元素和所有扩展元素的并集，作为元数据方案。但这样一个方案有一个危险，它无法保证与将来的国家标准，甚至上海图书馆自身的元数据标准相统一，因为这些标准尚在讨论之中，还未定稿，但是由于项目实施尚有两年甚至更长的过程，这些标准有可能在项目实施过程中就会逐步制定出来，这个过程中碰到的兼容性和互操作性问题很难处理。

为了尽可能避免上述问题，我们考虑制定一些基本原则，依据这些原则制定具体的工作手册，以求最大限度地获得灵活性和可扩展性。首先在体系结构方面尽可能参照一些成熟的参考模型、分析模型来做，例如OAIS3所提供的信息系统参考模型在数字资源的永久保存方面提供了一个思考框架，国家图书馆已经在它的基础上有一些元数据方案的探索4；FRBR5对数字对象整个生命周期不同过程和形态的关系建立了一个思考框架，对于建立复杂的数字对象之间的ER模型以及不同阶段知识产权属性的管理非常有用，这个模型还可以看成是一个初步的名人手稿资源的本体模型。在元数据描述语义方面我们考虑尽可能“复用”现有的方案和标准，而尽可能少地“创造”新的元素；整个元数据方案按照DCMI对于元数据应用概要（Application Profile）的抽象模型6来建立。在置标方面尽可能采用标准的方案或者灵活的XML/RDF7模式。

因此名人手稿数字图书馆的元数据方案是一种“混合”型元数据应用概要的形式，即借鉴OAIS、FRBR以及DCMI目前正在形成的Abstract Model作为方法论，采用以DC-Lib8为基础的“上海图书馆元数据方案”作为核心元数据①，并从多种元数据标准、方案中“复用”

元素，对所有元素的语义强调严格遵从，但在著录规范中对在每种特定资源类型中的具体含义进行补充说明，限定或扩展方式也强调尽可能采用现有的框架、体系和规范，并充分采用XML Schema（METS9和MODS10等）和RDFs（WSDL11）提供的结构限定方式，最后再考虑增加子元素或元素。

本文是对名人手稿馆元数据方案的总体介绍，包括原则、流程、框架、模型、元素集（包括核心集和扩展集）及其置标的考虑等等，限于篇幅，不可能介绍得非常详细，规范控制和系统的需求与设计将在以后另文阐述。当然本项目是一个具体实践，限于条件和水平，在实现时必然有许多妥协和折衷，缺憾之处在所难免，敬请批评指正。

设计原则

设计原则是设计思想的具体体现，贯穿整个设计过程，对项目的后期实施也会产生巨大影响。名人手稿馆元数据方案的设计原则一部分可以是元数据方案设计的通用原则，但在具体尺度的把握上有自己的特色，另一部分属于具体原则，专门针对本项目而制定。

通用原则包括如下六项②：

1.简单性与适用性原则

简单性要求元数据方案尽可能采用精简的“核心”元素集，以便于实现，降低成本，加快实现进度，以及有利于互操作的实现；适用性要求数据元素必须“够用”，必须能够完全实现系统需求。简单性和适用性是一对矛盾，参与方案设计的各方人员往往会有不同意见，需要仔细斟酌。对于名人手稿馆元数据方案，我们以适用性原则为重点，同时从技术实现的角度删繁就简，满足最低“核心”元素集的要求。

2.专指度与通用性原则

专指度指对于特殊领域资源描述所提出的特殊要求的满足，例如名人手稿馆元数据方案中的“捐赠人”、“捐赠日期”、“书写工具”、“誊写人”等描述要求；通用性原则要求考察是否有更一般的或这些“专指概念”的上位概念能够满足描述要求，例如考虑某一“专指”元素到一个一般“核心”元素的映射或考虑如何进行“dump down”的方案；决定是用“专指”元素还是“通用”元素的过程，就是权衡专指度与通用性的过程。这两个原则也是一对矛盾，其实这也是考虑互操作问题。在名人手稿馆元数据方案中典型的例子是：如果考虑通用性，对于不同资源类型的相应元素定义统一的元素名称（如“责任者”），这样对于某些类型的资源会显得非常别扭（例如对应“书信”中的“下款名”），这就需要权衡，是增加元素，还是增加修饰，还是在系统实现时进行处理，等等。

3.互操作性与易转换性原则

因为元数据方案的立足点就是解决互操作问题，这里的许多原则实际上都是在一个侧面或从一定程度上解决互操作问题。可以看出“互操作性”原则是元数据方案设计和实现中需要遵循的最重要的原则，通过尽可能地复用标准方案、复用元素、或复用修饰词及扩展方式，以及建立映射、转换机制等方式来达成互操作性。易转换性原则指元素的含义应该尽可能符合“原子性”要求，以便于向其它元数据方案（一般是标准的或“核心”的方案）映射或转换，尽可能保证在映射和转换过程中语义不损失。

4.灵活性与可扩展性原则

强调标准性和专指性常常都意味着灵活性和可扩展性的损失。灵活性和可扩展性都是指元数据方案对于未来的适应性，常常要求总体的平衡，不能在某一方面强调过度。例如对于限定，应该支持多种限定方式，同时个别元素的限定级别不宜过深；对于现有标准的遵循，不宜过于严格以至于标准的未来版本扩展了元素而自己制定的方案却扭曲地局限在“核心元素”的限定上（有些方案将许多扩展都置于DCMES的”Description”下，以至于这个元素过

于臃肿，同时增加了限定级别，方案显得非常不灵活）。

5.用户需求原则

这一原则是不言而喻的。但是其前提是必须分清谁是用户。名人手稿馆元数据方案的用户首先是其工作人员，因为整个系统首先作为馆藏管理系统，然后是专业用户。普通读者的需求可以包含在专业用户中。

6.遵循现有标准原则

通过符合元数据标准或协议而达到“互操作”是根本意义上的互操作，因此遵循现有标准对于实现互操作是至关重要的。但是对于标准也要有所选择，元数据领域有很多“标准”或事实标准，目前大多数标准对于具体应用来说没有能立即照搬使用的，必须遵循一定的方法论和应用流程进行选择取舍，这是元数据应用的难点，也是目前研究多应用少的原因之一。

除上述通用原则之外，我们考虑的具体原则是指在元数据方案的设计和执行的具体流程中需要掌握的原则，包括资源分析原则、扩展原则（元素扩展原则和修饰限定原则）、元素定义原则、置标原则和系统实现和应用原则等，在此不作详述。

设计流程

整个设计流程以下图简略表示：

图1：名人手稿馆元数据方案设计流程图示

资源特点

名人手稿馆的收藏原则与一般图书馆和博物馆都有所不同，立足于文献，但却是“大文献”概念，具有一定历史人文价值的任何形式的载体都可能是收藏对象。名人手稿馆的馆藏资源类型可以看成是一个其特有的内部本体，包括创作手稿、书信、日记、照片、书画篆刻作品、签名本、笔记、账簿、录音录像资料、证章奖状以及各类小件实物等，将来数字化对象也会直接成为名人手稿馆的馆藏，而不需要有物理馆藏与之对应。名人手稿馆的工作人员作为领域专家，倾向于上述直观实用的分类，这种分类实际上是内容和形式两方面的属性混合起来加以区分的。系统分析人员希望要么按照内容属性区分，要么从形式上区分，当然系统可以支持多种分类方法同时存在，并提供满足上述“混合”分类的用户视图，但前提是必须彻底弄清每种资源的属性和资源之间的相互关系。由于名人手稿馆资源类型复杂的实际情况，系统必须支持分类的灵活性和可扩展性，因为谁也无法预料将来会入藏哪些藏品，馆藏极有可能超出原有的“本体”范畴。

“关于名人”的资源是名人手稿馆不同于图书馆或者博物馆馆藏的的另一个重要特点，除按照所需揭示的属性客观著录外，与名人的相关属性也应在资源描述方案中予以充分揭示，否则就失去了其作为名人手稿馆馆藏的意义。

明确定义资源类型是制定具体的元数据方案中非常重要的第一步，对于资源类型的界定和说明以资源分析报告的形式固定下来，有助于明确项目的边界，更好地理解馆藏，在提取“核心”属性方面达成一致，确定描述资源对象及其属性之间的关系，并初步形成对于著录的许多规定。资源分析通常需要确定的内容是：资源类型的定义和范围、资源对象之间的关系、对象粒度（著录级别和著录单元）、属性语义（具体内容）以及对于具体属性的检索需

求。

表1：名人手稿馆资源类型定义

资源类型定义

创作手稿名人在创作或研究过程中所产生的手书文字记录，可以是草稿、未定稿、校改稿（包括打印稿的手书校改稿）或最终的完成稿。创作手稿的体裁不限，可以是任何一种文

学作品，也可以是论文，但不包括书画作品和其他艺术作品。

信函指源自名人的各类通信，包括信件、明信片、贺卡、请帖等。

日记名人按照日期记载事物或个人感受的文字记录，包括日记本、记事本、备忘录、日历本、帐册等。

照片以摄影形式记录名人及其家属，友朋生活、工作的文献载体。

书画篆刻作

品以刀、笔等作为工具，利用墨或各类颜料，在纸、石或其它载体上创作的平面视觉艺术作品。

签名本带有名人签名、题词、印章或其它印记的纸质印刷本或出版物。

纸质资料由名人捐赠的、不带有名人签名或印章的打印或复印文献，主要是指与名人相关的，或有关名人参与的重大历史事件的打印资料或剪报、期刊资料等。

音像资料以磁光等介质记录的有关名人或名人捐赠的视频、音频资料。

笔记名人在听课、听报告、读书等情况下所做的摘抄、随想等文字记录，没有确切时间或者不是以日期作为记录顺序的。

证件名人用于各种场合、代表其身份的文件，在范围上包括了出入证、医疗证、工作证、代表证、选民证、挂号卡、小名片等

证书由机关、学校、社团等颁发给名人以表彰其成就或授予其荣誉的文件

实物由名人创建或使用过的，或其它与名人有关的物品，除已归入上述各类的之外，比如印章、证章等。

图二：名人手稿馆资源实体关系图

元数据方案

方案的性质

从整体上看，元数据对于信息系统来说，具有描述、定位、发现、证明、评估，检索等作用（FRBR③定义了元数据最主要的四个功能：查找Find、标识Identify、选择Select和获取Obtain）。元数据方案应该能够全面描述信息系统中与信息资源相关的各类特征和属性，包括静态特征、状态特征、生命周期特征、管理特征以及系统在实现功能过程中所要求的其他语义信息等等，而不仅仅是描述性信息，而实际上人们研究和使用较多的大都是描述性元数据，对于其它类型的元数据④，例如保存型元数据可以参考一些现成的参考模型或国际标准（例如OAIS），或者一些大馆的元数据方案（例如美国国会图书馆的“美国记忆”项目的方案）来制定；管理型元数据和技术性元数据，大多交给系统分析和设计人员提供解决方案，这些数据元素大都可以在系统运行过程中自动生成，或在进行数字化、数据转换、或数据装载的过程中进行机器辅助人工添加。因此，名人手稿馆的元数据方案主要是一个描述性元数据的方案。

方案的组成

制定具体的元数据方案不同于元数据标准规范的研究，后者只需要少数一些推荐文件，甚至只有一组元数据元素集就可以了，而元数据方案需要一整套指导实施的文档，可以按照前文的流程确立文档，也可以根据实际需要制定。本方案主要包括以下6个文档，然而本节主要介绍方案中最重要的元素集方案、置标方案和著录规则，其中元素集方案参考ISO11179

的要求名称，选取了14个属性进行定义。这14个属性是：中文标识、英文标识、命名域、版本、注册机构、语言、应用规则、定义、注释、数据类型、最大出现次数、元素修饰词、编码体系修饰词和最佳操作。

表2：名人手稿馆元数据方案包括的文档列表

资源分析文档：定义资源类型，确定资源类型的内涵和外延，确定著录级别和著

录单位，属性提取，确定著录对象之间以及属性之间的关系，属

性的检索要求，核心属性的支持

元数据元素集及定义：按照规范格式定义属性元素，定义限定和扩展规则，定义子元素

和编码体系，定义元素之间的关系

著录规则：元数据方案应用于具体资源类型著录时的细节描述

置标方案：采用RDF/XML置标的规则，命名域规定，标签定义，编码规则规范控制流程：人名规范档的建立、维护、更新、应用流程和规则

元数据著录系统需求：开发具体的著录系统所要求的通用和专用需求规范

属性元素集

如前文所述，本方案的核心集为以DC-Lib为基础的《上海图书馆元数据方案》，选取其中18个元素中的17个（不包括其中的“用户对象(Audience)”元素）作为核心集，但核心集并不是必备集。整个方案采用混合型的元数据概要（Metadata Profile）形式，包括核心集和扩展集两个部分，复用了CDWA12的5个元素（材料与技术、编目记录、制法、相关文本信息、题记或标记）和REACH13的1个元素（出处），并且针对名人手稿馆资源的特殊性，扩展了4个个别元素（获得方式，捐赠项，书写人，载体形态附注）。方案允许每个元素对于不同的资源类型有不同的“显示名”和不同的元素修饰词与编码体系修饰词，限定方式原则上限制在两层。由于名人手稿馆所要求的资源类型的开放性，我们考虑其属性元素集为各已知资源类型所需元素的并集（即目前的核心集和扩展集），新增的资源类型原则上只能从已有的属性元素集合中选取元素，否则增加或修改属性元素都会给已经实现的应用系统构成挑战。这样元数据方案才能保持必要的稳定性。

元素列表（其中粗斜体为核心元素）

元素名及修饰词 XML/RDF标签

题名

dc:title

交替题名dcterms:alternative

创建者dc:creator

其他责任者dc:contributor

出版者dc:publisher

日期

dc:date

创建dcterms:created

可获得dcterms:available

修改dcterms:modified

主题dc:subject

说明dc:description

类型dc:type

格式

dc:format

范围dcterms:extent

媒体dcterms:medium

标识符dc:identifier

来源dc:source

语种dc:language

关联

dc:relation

版本继承 dcterms:IsVersionOf

版本关联 dcterms:HasVersion

被替代dcterms:IsReplacedBy

替代 dcterms:Replaces

被需求 dcterms:IsRequiredBy

需求 dcterms:Requires

组成部分 dcterms:IsPartOf

部分为 dcterms:HasPar t

被参照 dcterms:IsReferencedBy

参照 dcterms:References

格式转换于dcterms:IsFormatOf

格式转换为dcterms:HasFormat

覆盖范围

dc:coverage

时间dcterms:temporal

空间dcterms:spatial

权限dc:rights

版本mods:edition

馆藏位置mods:location

材料与技术

cdwa:MaterrialandTechniques*

工具cdwa:Implement*

材料cdwa:Materrials*

颜色cdwa:Color*

编目记录

cdwa: CatalogingHistory*

编目人cdwa:CatalogerName*

编目机构cdwa:CatalogerInstitution*

编目时间cdwa:Date*

制法cdwa:Facture*

相关文本信息cdwa:RelatedTextualReferences*题记或标记

cdwa: Inscriptions/marks*

题字/描述 cdwa:TranscriptionOrDescription*

题字/标记类型 cdwa:Type*

部位/位置 cdwa:Location*

字体/字型 cdwa:Typeface/Letterform*

备注 cdwa:Remarks*

出处reach:PlaceofOrigin/Discovery*

获得方式MethodsOfAvailability*

捐赠项Donation*

捐赠者Donator*

捐赠时间DonatedDate*

书写人Scribe*

载体形态附注PhysicalDescriptionNote*

注：带有*号的XML/RDF标签为由我们自定义的置标形式；自行扩展的个别元素

尚未定义命名空间。

置标方案

元数据的置标本质上是元数据方案的形式化，主要是为了计算机对元数据信息进行存储和处理而用的，比如2709格式就是MARC属性字段的一种表达（即形式化）。与传统的机读目录应用系统所不同的是，目前以互联网技术为代表的信息处理技术非常强调开放性、可扩展性和互操作性，不像传统的系统只需考虑系统内部的问题，实现独立的功能即可。从长远看这将带来很大的好处，然而目前由于技术尚未成熟，开放环境下的一整套技术架构尚未完全建立起来，应用所需的许多标准规范也正在研究探索之中，因此实现目前的应用在采用的技术方面显得非常复杂，技术实现的每一步都是独立的，都有许多方案/标准/规范可供选择，很多时候鱼和熊掌无法兼得。

属性元素集定下来之后也可以直接采用关系数据库系统来实现具体的查询、管理功能，当然作为数字图书馆应用来说最好中间加一层基于XML的内容管理层，以便于将来独立于系统的长期保存、与其它系统的互操作等，这就有必要对元数据进行基于XML的置标。元数据方案定义的许多属性，并不是简单的采用某种置标语言就能被机器理解，不同的置标方案的能力是不同的，例如单纯的XML不支持数据类型的定义，而必须用到XML Schema，如果将来需要进行语义互操作，最好采用RDF置标等等。就目前而言，还没有哪种置标方案能够将元数据方案中所定义的所有约束表达出来，特别是语义方面的约束。这将有赖于将来基于本体的置标语言的标准化，结合多种置标标准共同实现丰富而灵活的功能。

名人手稿馆元数据的置标采用XML/RDF形式，然而由于元数据著录系统支持任何以DTD或XML Schema方式载入元数据方案及相应的约束，不同元数据格式之间的转换（不论是置标方式的转换还是元素之间的映射）变得相对容易，系统还支持XML/RDF格式与CNMARC（ISO2709）格式之间的转换，因此具体采用何种置标格式甚至是无所谓的了。当然本系统物理上存有一套基于本元数据方案的XML/RDF置标元数据，同时研制了大量基于标准的置标方案以及其相互转换的映射规范，这些“元元数据”大都以XML Schema或DTD 文件的形式存放，必要时调入著录系统。当然元数据库的存储和管理还是采用商用的关系数据库系统。

截至写稿时为止，名人手稿馆元数据著录系统尚在开发之中，具体的置标方案和映射表尚未进行有效性检验，而且篇幅很长，在这里就不一一介绍了。

著录规则

由于名人手稿馆的资源种类繁多，相互差异性较大，具体的标引人员对不同资源类型的熟悉程度一般都是不同的，因此我们在名人手稿馆元数据方案的指导下，对每种资源都编制了著录规则，每种资源个性之处可以充分说明。

问题讨论

名人手稿馆元数据方案的实现有许多独特的难点，一些已经得到解决，一些还没有很好的方案。例如同样的元素对于不同的资源具有不同的名称（如：书信的责任者为“下款名”），

而系统内部必须默认为一致，这样既保证了元数据方案的统一，又有利于专门领域工作人员的标引和用户对资源的利用。另一个相关的比较棘手的问题是不同的资源类型对同一个元素具有不同的元素修饰词与编码体系修饰词，目前我们只能同时支持此元素下所有的元素修饰词和编码体系，否则只能将元数据方案按照资源类型拆开，这与我们的设计思想是相悖的。

目前名人手稿馆的元数据方案主要考虑资源系统内部的互操作（即跨库检索），主要依靠核心元素来实现，而核心元素的互操作主要通过其支持和复用DC等元数据标准来实现，但最终名人手稿馆数字图书馆系统要实现丰富、灵活的外部勾连（例如与上海图书馆现有的书目系统或电子资源检索系统进行整合，或者与互联网上其它的手稿资源库进行勾连等），还必须考虑更多的互操作协议和技术标准。

名人手稿馆的资源是上海图书馆丰富馆藏的一部分，名人手稿馆元数据方案是上海图书馆元数据方案的一个实例和具体应用。目前上海图书馆元数据方案也还有许多不尽完善的地方，通过名人手稿馆的元数据实践能够加以补充和完善。但是如前文所述，名人手稿馆的元数据方案目前还缺少管理型元数据、保存元数据和技术性元数据等其他部分，这些元数据需要在名人手稿馆数字图书馆的实现过程中加以提炼和总结。

注释：

①这一核心集也包含了IFLA提出的10项“核心记录元素（Core Metadata Elements）”集

合（草案）。参见：https://www.wendangku.net/doc/6e13307487.html,/VII/s13/guide/metaguide03.pdf

②六项通用原则的前五项参考2003年7月《专门数字对象描述元数据规范研制工作手册（修订稿）》并

根据名人手稿馆的应用进行了扩展与细化后拟定。

③具体请参见：https://www.wendangku.net/doc/6e13307487.html,/VII/s13/frbr/frbr.pdf，即参考文献5。

④对于元数据的类型并无统一公认的划分，IFLA在一份元数据应用指南文件（Guidance on

the Structure, Content, and Application of Metadata Records for Digital Resources and Collections a draft for review, 参见https://www.wendangku.net/doc/6e13307487.html,/VII/s13/guide/metaguide03.htm)中将元数据分为管理型、描述性、分析型（Analytical）、版权管理和技术性五种，传统上可以分为管理型、描述性、保存性、技术型、使用型等五类。即参考文献14。

⑤这种技术方案借鉴了台湾的Metalogy系统的设计思想。

参考文献：

1“外滩源”保护开发全面启动．王蔚．文汇报，2003-01-10

2 MALVINE: Manuscripts and Letters via Intergrated Networks in Europe．URL：https://www.wendangku.net/doc/6e13307487.html,/

3Reference Model for an Open Archival Information System (OAIS)．Consultative Committee for Space Data Systems (CCSDS).URL：

https://www.wendangku.net/doc/6e13307487.html,/documents/pdf/CCSDS-650.0-B-1.pdf(检索日期：2004-2-1)

4中文元数据方案(征求意见稿)．国家图书馆．内部资料，2001年6月

5Functional Requirements for Bibliographic Records (FRBR)．IFLA Study Group on the Functional Requirements for Bibliographic Records.URL：

https://www.wendangku.net/doc/6e13307487.html,/VII/s13/frbr/frbr.pdf(检索日期：2004-2-1)

6 Dublin Core Abstract Model．Andy Powell．URL：

https://www.wendangku.net/doc/6e13307487.html,/documents/abstract-model/(检索日期：2004-1-14)

7 RDF V ocabulary Description Language 1.0: RDF Schema．W3C Proposed Recommendation．URL：https://www.wendangku.net/doc/6e13307487.html,/TR/rdf-schema/(检索日期：2004-2-1)

8 Library Application Profile．Rebecca Guenther．URL：

https://www.wendangku.net/doc/6e13307487.html,/documents/library-application-profile/(检索日期：2004-1-14)

9Metadata Encoding and Transmission Standard (METS)．URL：

https://www.wendangku.net/doc/6e13307487.html,/standards/mets/(检索日期：2004-1-14)

10Metadata Object Description Schema (MODS)．URL：https://www.wendangku.net/doc/6e13307487.html,/standards/mods/(检索日期：2004-2-1)

11Web Services Description Language (WSDL) 1.1．W3C Note．URL：

https://www.wendangku.net/doc/6e13307487.html,/TR/wsdl(检索日期：2004-2-1)

12Categories for the Description of Works of Art(CDWA)．URL：

https://www.wendangku.net/doc/6e13307487.html,/research/conducting_research/standards/cdwa/(检索日期：2004-2-1)

13RLG REACH Element Set for Shared Description of Museum Objects ．URL：

https://www.wendangku.net/doc/6e13307487.html,/reach.elements.html(检索日期：2004-2-1)

14.Guidance on the Structure, Content, and Application of Metadata Records for Digital

Resources and Collections．URL：https://www.wendangku.net/doc/6e13307487.html,/VII/s13/guide/metaguide03.pdf(检索日期：2004-1-14)

15.《专门数字对象描述元数据规范研制工作手册（修订稿）》．专门数字对象描述元数据规

范子项目组．内部资料，2003年7月

16.张晓林．元数据研究与应用．北京：北京图书馆出版社，2002－05

17.陈雪华, 陈昭珍, 陈光华．数位图书馆XML/Metadata管理系统．台北：文华图书馆管

理资讯公司，2001

元数据设计文档2.0

元数据管理系统

目录 1.前言 (5) 2.整体设计 (5) 2.1设计思路 (5) 2.2架构图 (6) 2.3功能图 (7) 3.功能模块 (8) 3.1元模型 (8) 3.1.1元模型维护 (9) 3.1.1.1元模型基本信息维护 (10) 3.1.1.2元模型属性维护 (10) 3.1.1.3元模型关系维护 (11) 3.1.1.4元模型索引维护 (11) 3.1.2包维护 (11) 3.1.3关系类型维护 (12) 3.1.4业务领域维护 (12) 3.1.5枚举类型维护 (12) 3.2元数据 (14) 3.2.1元数据基本信息维护 (14) 3.2.2元数据关系维护 (15) 3.2.3元数据生命周期 (15) 3.2.4元数据采集 (17) 3.2.4.1元数据导入导出 (17) 3.2.4.2CWM导入导出 (17) 3.2.4.3元数据模版导出 (17) 3.2.5版本管理 (18) 3.2.6变更订阅 (18) 3.2.7元数据检索 (19) 3.3应用 (19) 3.3.1元数据权限管理 (19) 3.3.1.1用户管理 (20) 3.3.1.2角色管理 (20) 3.3.1.3系统功能资源 (21) 3.3.1.4元数据操作权限 (21) 3.3.1.5数据库用户维护 (21) 3.3.2数据库管理 (22) 3.3.2.1表维护 (23) 3.3.2.1.1表基本信息维护 (24)

3.3.2.1.3索引维护。 (24) 3.3.2.2视图维护 (25) 3.3.2.2.1视图基本信息维护 (25) 3.3.2.2.2视图字段维护 (26) 3.3.2.3SQL语句查询 (26) 3.3.2.4存储过程维护 (27) 3.3.2.5表空间维护 (28) 3.3.2.6数据库用户维护 (29) 3.3.3血统、影响分析 (30) 3.3.3.1血统分析 (30) 3.3.3.1.1图形展示 (30) 3.3.3.1.2表格展示 (30) 3.3.3.2影响分析 (31) 3.3.3.2.1图形展示 (31) 3.3.3.2.2表格展示 (32) 3.3.4元数据使用情况统计 (33) 3.3.4.1元数据浏览用户统计（按用户） (33) 3.3.4.2元数据浏览用户统计（按元数据类型） (33) 3.3.5元数据质量管理 (33) 3.3.5.1属性填充率 (33) 3.3.5.2属性合法性 (33) 3.3.5.3名称重复性 (34) 3.3.6指标库管理 (34) 3.3.7元数据差异分析 (34) 3.3.7.1流程差异比较 (35) 3.3.7.2属性差异比较 (35) 4.内部接口调用标准 (35) 4.1元数据服务接口（M ETADATA S ERVICE） (35) 4.2元数据版本服务接口（MDR EVISION S ERVICE） (36) 4.3元数据关系服务接口（MDR ELATION S ERVICE） (37) 5.外部工具接口标准 (37) 5.1获取元数据信息 (39) 5.2新增元数据信息 (40) 5.3修改元数据信息 (42) 5.4删除元数据信息 (43) 6.实现工具使用技术 (44)

元数据管理平台

元数据管理平台技术白皮书北京亿信华辰软件责任有限公司 2018年4月

目录 1.前言 (1) 1.1.关于本白皮书 (1) 1.2.背景介绍 (1) 1.3.产品定位 (1) 2.产品架构 (2) 2.1.概述 (2) 2.2.数据源层 (2) 2.3.采集层 (2) 2.4.数据层 (3) 2.5.功能层 (3) 2.6.访问层 (3) 3.产品功能特色 (4) 3.1.规范的元模型管理 (4) 3.2.端到端的自动化采集 (5) 3.3.全面的采集适配器 (5) 3.4.可灵活定制的采集模板 (6) 3.5.便捷的元数据检索 (7) 3.6.完善的元数据管理 (7) 3.7.强大的元数据版本管理 (8) 3.8.实时的元数据变更监控 (8) 3.9.数据地图鸟瞰全局 (9) 3.10.丰富的元数据分析应用 (9) 3.10.1.血缘分析 (9) 3.10.2.影响分析 (10) 3.10.3.全链分析 (10) 3.10.4.关联度分析 (11) 3.10.5.属性差异分析 (11) 3.11.出色的元数据检核机制 (12) 3.11.1.一致性检核 (12) 3.11.2.属性填充率检核 (12) 3.11.3.组合关系检核 (12) 3.12.自助式门户 (13) 3.13.丰富的服务接口 (13) 4.产品技术优势 (13)

4.1.系统设计原则 (13) 4.1.1.先进性 (14) 4.1.2.可维护性 (14) 4.1.3.可靠性 (14) 4.1.4.易用性 (15) 4.1.5.安全性 (15) 4.1.6.扩展性 (15) 4.2.可扩展采集适配器设计 (16) 4.3.采用MOF规范 (16) 4.4.支持基于XMI的数据交换 (17) 4.5.运用REST FUL架构 (18) 5.软硬软件环境 (19) 5.1.服务器配置推荐 (19) 5.2.客户端配置 (20) 5.2.1.客户端(建议配置) (20) 5.2.2.客户端浏览器 (20)

大大数据管理系统之大大数据可视化设计

数据管理系统企业级数据可视化项目Html5 应用实践项目经理：李雪莉组员：申欣邹丽丹陈广宇陈思班级：大数据&数字新媒体一、项目背景随着大数据、云计算和移动互联网技术的不断发展，企业用户对数据可视化的需求日益迫切。用户希望能够随时随地简单直观的了解企业生产经营、绩效考核、关键业务、分支机构的运行情况，即时掌握突发性事件的详细信息，快速反应并作出决策。随着企业信息化的不断推进，企业不断的积累基础信息、生产运行、经营管理、绩效考核、经营分析等以不同形式分布在多个系统或个人电脑文档内的业务数据。如何将大量的数据进行分析整理，以简单、直观、高效的形式提供给管理者作为经营决策的依据是当前企业数据应用的迫切需求。传统的企业数据可视化方案多基于Java Applet、Flash、Silverlight 等浏览器插件技术进行开发，在当前互联网和移动互联网技术高速发展的背景下，Web技术标准也随之高速发展，用户对互联网技术安全性和使用体验的要求越来越高。Java Applet、Flash、Silverlight 等浏览器插件技术因为落后和封闭的技术架构，以及高功耗、高系统

资源占用，已经被微软、谷歌、苹果、火狐等主流操作系统和浏览器厂商逐步放弃，转而不断支持和完善基于HTML5的新一代Web技术标准对数据进行直观的拖拉操作以及数据筛选等，无需技术背景，人人都能实现数据可视化无论是电子表格，数据库还是 Hadoop 和云服务，都可轻松分析其中的数据。数据可视化是科学、艺术和设计的结合，当枯燥隐晦的数据被数据科学家们以优雅、简明、直观的视觉方式呈现时，带给人们的不仅仅是一种全新的观察世界的方法，而且往往具备艺术作品般的强大冲击力和说服力。如今数据可视化已经不局限于商业领域，在社会和人文领域的影响力也正在显现。数据可视化的应用价值，其多样性和表现力吸引了许多从业者，而其创作过程中的每一环节都有强大的专业背景支持。无论是动态还是静态的可视化图形，都为我们搭建了新的桥梁，让我们能洞察世界的究竟、发现形形色色的关系，感受每时每刻围绕在我们身边的信息变化，还能让我们理解其他形式下不易发掘的事物。二、项目简介目前，金融机构（银行，保险，基金，证劵等）面临着诸如利率汇率自由化，消费者行为改变，互联网金融崛起等多个挑战。为满足企业的发展需要，要求管理者运用大数据管理以更为科学的手段对企

元数据的构成方式

元数据的构成方式（徐枫宦茂盛）通过元数据的描述，能够使信息资源的使用者了解数据的内容、特征、作用、获取方式等信息。元数据是关于数据的数据，在建立信息资源目录体系的过程中，元数据主要是对信息资源从外部特征进行而非从内部结构进行描述。通俗地讲，元数据就是信息资源的标签或卡片，通过元数据的描述，可以使信息资源的使用者能够了解数据的内容、特征、作用、获取方式等信息，能够对信息资源是否满足特定的应用需求做出适当的评价，并根据评价的结果决定是否采取进一步的措施来获取该信息资源。元数据是信息资源目录体系建立的基础，构建一个信息资源目录体系首要和基础性的工作就是建立描述各个信息资源的元数据库，元数据库中存储的是描述各种来源、各种类型的信息资源的描述信息。无论用户以何种方式查询信息资源目录，包括以分类目录的形式进行查询、或者以多关键词的形式进行查询，其本质都是对后台元数据库的检索，只是从表现层提供了不同形式的人机查询接口。根据所描述的信息资源对象的不同，可以建立不同的元数据库，分别对各类信息资源进行描述。

元数据的组成为能够对信息资源进行准确和高效的描述，元数据本身具有自身的逻辑结构。一般来说，元数据本身是层次化、树状结构的。处于树状结构最底端的叶子节点称之为元数据元素，包含了元数据元素的节点称之为元数据实体，当然元数据实体也可以只包含元数据实体。根据实际需求，元数据实体或者元数据元素可以多次出现。例如，信息资源可以有不同的分类，可以按照信息资源的来源进行分类，也可以按照信息资源的不同应用主题进行分类，因此，“信息资源分类”元数据实体就可以出现多次。元数据一般分三个方面对信息资源进行描述。一是对信息资源基本内容的描述。包括信息资源的标题、摘要、关键词等基本信息。标题是信息资源的名称，通过标题使用者能够初步掌握信息资源的基本范围。其次，使用者可以通过摘要，了解信息资源的主要内容、用途等各种信息。一般情况下，用户主要通过摘要作为信息资源适用性评价的主要依据。所以，在信息资源元数据的著录过程中，摘要的填写一般都由专业人员完成，只有专业人员才能够对信息资源的内容有准确的把握和深入的理解，能够提供有关信息资源内容的更加权威的解释。根据信息资源对象的不同，描述信息资源基本内容的元数据实体和元数据元素还可

数据仓库主题设计及元数据设计

明确仓库的对象：主题和元数据大多数商务数据都是多维的，所以采集和表示三维以上的数据不能完全借用业务数据库设计中的方法，必须有一种新的方法来表达多维数据。现阶段流行的有2种方法，一是面向对象方法，即把商务数据抽象为对象，再使用Rational Rose等对象建模工具来表达这些对象；另一种方法就是使用信息包图，这是一种简便且高效的方法，在项目中使用的普及率很高。信息包图实际上是自上而下数据建模方法的一个很好的工具。自上而下的建模技术从用户的观点开始设计。用户的观点是通过与用户交流得到的，可以进一步明确用户的信息需求。自上而下的方法几乎考虑了所有的信息源，以及这些信息源影响商务活动的方式，它使得设计者可以围绕着一个通常的主题或商务领域进行信息包的开发。下面就详述如何通过信息打包技术建立信息包图，从而确定数据仓库中的主题和元数据。 3.4.1 信息打包技术 1．信息打包技术的基本使用信息打包法是一种自顶向下的设计方法，它从管理者的角度出发把焦点集中在企业的一个或几个主题上，着重分析主题所涉及数据的多维特性。此法具体分4个阶段：（1）采用自顶向下的方法对商务数据的多维特性进行分析，用信息打包图表示维度和类别之间的传递和映射关系，建立概念模型。其中类别是按一定的标准对一个维度的分类划分，如产品可按颜色、质地、产地和销地等不同标准分类。（2）对企业的大量的指标实体数据进行筛选，提取出可利用的中心指标。其中指标也称为关键性能指标和关键商务测量的值，是在维度空间衡量商务信息的一种方法。比如产品收入金额、原材料消耗、补充新雇员或设备运行时间等都可以叫做指标。（3）在信息打包图的基础上构造星形图，对其中的详细类别实体进行分析，进一步扩展为雪花图，建立逻辑模型。（4）在星形图和雪花图的基础上，根据所定义数据标准，通过对实体、键标、非键标、数据容量、更新频率和实体特征进行定义，完成物理数据模型的设计。信息包图可以帮助用户完成以下工作：定义某一商务中涉及的共同主题范围，例如：时间、顾客、地理位置和产品。设计可以跟踪的、确定一个商务事件怎样被运行和完成的关键商务指标。

国内外元数据

元数据格式汇总iii 1. DC(都柏林核心元数据) 2. CDWA(艺术作品描述目录) 3. V AR Core(可视资源委员会核心元数据) 4. CDF(频道定义格式) 5. ROADS元数据（主题信息服务的资源组织和发现） 6. IEEE LOM（IEEE学习对象元数据） 7. BibTex(科技文献书目资源格式) 8. GEM（教育资源网关） 9. CIMI(博物馆信息计算机交换标准框架) 10. REACH元数据格式 11. EAD(编码文档描述) 12. ONIX(在线信息交换) 13. EELS(工程电子化图书馆) 14. EEVL(爱丁堡工程虚拟图书馆) 15. FGDC(联邦地理数据委员会) 16. GILS(政府信息定位服务) 17. MARC(机读目录格式) 18. MOA2（美国的创建II） 19. MCF(元内容框架) 20. PICA+(荷兰图书馆自动化中心) 21. PICS(网络内容选择平台) 22. TEI Header(文本编码先导计划) 23. SOIF(概略对象交换格式) 24. IAFA/WHIOS++Templates(因特网匿名FTP文件库版式) 25. ICPSR SGML Codebook(政治和社会研究方面的校际联盟) 26. LDAP DIF(轻便型目录获取协议) 27. RFC 1807(书目记录格式) 28. URCs(统一资源特征) 29. SGML(通用标准标记语言) 30. Warwick Framework(Warwick框架) 31. Web Collections(网站集合) 32. XML(可扩展标记语言) 33. RDF(资源描述框架) 1.DC(都柏林核心元数据) 名称：Dublin Core Metadata,DC

企业元数据管理方案设计

一、背景大数据挑战大数据时代，饿了么面临数据管理、数据使用、数据问题等多重挑战。具体可以参考下图： ?数据问题：多种执行、存储引擎，分钟、小时、天级的任务调度，怎样梳理数据的时间线变化？ ?数据使用：任务、表、列、指标等数据，如何进行检索、复用、清理、热度Top计算？ ?数据管理：怎样对表、列、指标等进行权限控制、任务治理以及上下游依赖影响分析？元数据定义与价值

元数据打通数据源、数据仓库、数据应用，记录了数据从产生到消费的完整链路。它包含静态的表、列、分区信息（也就是MetaStore）；动态的任务、表依赖映射关系；数据仓库的模型定义、数据生命周期；以及ETL任务调度信息、输入输出等。元数据是数据管理、数据内容、数据应用的基础。例如可以利用元数据构建任务、表、列、用户之间的数据图谱；构建任务DAG依赖关系，编排任务执行序列；构建任务画像，进行任务质量治理；数据分析时，使用数据图谱进行字典检索；根据表名查看表详情，以及每张表的来源、去向，每个字段的加工逻辑；提供个人或BU的资产管理、计算资源消耗概览等。开源解决方案

WhereHows是LinkedIn开源的元数据治理方案。Azkaban调度器抓取job执行日志，也就是Hadoop的JobHistory，Log Parser后保存DB，并提供REST查询。WhereHows太重，需要部署Azkaban等调度器，以及只支持表血缘，功能局限。

Atlas是Apache开源的元数据治理方案。Hook执行中采集数据（比如HiveHook），发送Kafka，消费Kafka数据，生成Relation关系保存图数据库Titan，并提供REST接口查询功能，支持表血缘，列级支持不完善。二、饿了么元数据系统架构

元数据管理方案

元数据管理方案 1.1元数据抽取为了简化元数据生成工作，系统提供自动生成元数据的功能，即元数据抽取。通过元数据自动抽取，用户可以方便、快捷地获得大量的元数据信息。 1.1.1抽取的对象元数据抽取主要针对的对象有以下几种：已有目录：已建业务应用系统中现有的目录资源。数据库：各种数据库资源，包括关系型数据库、XML数据库等。格式化电子文件：电子文件，例如Word、PDF、XLS等文件。 1.1.2元数据抽取的流程元数据抽取的流程有4个主要步骤，分别为：数据源信息获取：解决要从哪个数据源获得元数据的问题。内容/结构分析：解决要从数据源中获得哪些元数据的问题。元数据提取：解决如何从数据源中获取元数据的问题。存储入库：解决元数据存储的问题。 1.1.3电子文档的元数据抽取对于电子文档，首先各部门的文档格式不尽相同，另外它们的安全级别也各不相同，同时由于信息化建设水平的不一致，有的部门文档分散在各处，有的部门文档是集中存放的，甚至已经建立了完善的电子系统进行管理。针对以上状况，对于电子文档的元数据抽取需要进行以下的抽取流程：整理归档对于分散在各处的电子文档(纸质文档需要先进行电子化处理)，必须由专人进行统

一整理，根据公开共享的前提进行集中，这种集中可以是物理上集中的，也可以是逻辑上集中的。但要满足以下原则，第一根据安全级别，便于外界访问；第二便于文档的增量发布；第三便于采集工具的自动化采集编目。各部门只有在文档完全整理归档的情况下，进行自动化采集才是切实可行的。在整理归档的时候，各部门根据各自情况进行归档，没有必要千篇一律，也没有必要制定繁琐和呆板的规则，只要能够满足以上的原则即可。 ●根据安全级别，建立相应的访问机制由于受到安全级别的限制，所以对于需要共享的数据要进行安全方面的限制，限制的手段可以有：用户名/密码、数字证书、物理隔断等等，根据实际情况建立安全访问机制，做到重要信息不泄露，不丢失。 ●编目处理现阶段，主流格式的电子文档，主要包含：word、excel、ppt、pdf等。对主流格式的电子文档，要提供自动采集工具进行编目处理。采集的范围主要是文档的标题和内容，对于其它的元数据内容，要提供手工配置的方式进行辅助。另外，在工具的采集效率上，要提高增量文档发布后的采集效率。对于格式特殊、内容有加密算法的文档，是很难通过抓取工具进行采集的，这些文档主要通过手工编目的方式来处理。对于存在管理库的文档，就需要对数据库来进行编目采集，详见数据库元数据抽取部分。 ●保存元数据采集后的数据要放到数据库或者保存到硬盘上，另外要根据目录体系标准，把数据分解为元数据，然后进行存储 1.1.4数据库元数据抽取数据中心需要抽取的数据库类型主要为Sql server，首先利用ETL工具从源数据库中将所需数据抽取至中心数据库基础业务库中，在利用元数据著录工具对抽取出来的数据进行元数据著录。

元数据管理方案

元数据管理方案 1.1元数据抽取为了简化元数据生成工作，系统提供自动生成元数据的功能，即元数据抽取。经过元数据自动抽取，用户能够方便、快捷地获得大量的元数据信息。 1.1.1抽取的对象元数据抽取主要针正确对象有以下几种：已有目录：已建业务应用系统中现有的目录资源。数据库：各种数据库资源，包括关系型数据库、XML数据库等。格式化电子文件：电子文件，例如Word、PDF、XLS等文件。 1.1.2元数据抽取的流程元数据抽取的流程有4个主要步骤，分别为：数据源信息获取：解决要从哪个数据源获得元数据的问题。内容/结构分析：解决要从数据源中获得哪些元数据的问题。元数据提取：解决如何从数据源中获取元数据的问题。存储入库：解决元数据存储的问题。

1.1.3电子文档的元数据抽取对于电子文档，首先各部门的文档格式不尽相同，另外它们的安全级别也各不相同，同时由于信息化建设水平的不一致，有的部门文档分散在各处，有的部门文档是集中存放的，甚至已经建立了完善的电子系统进行管理。针对以上状况，对于电子文档的元数据抽取需要进行以下的抽取流程： ●整理归档对于分散在各处的电子文档(纸质文档需要先进行电子化处理)，必须由专人进行统一整理，根据公开共享的前提进行集中，这种集中能够是物理上集中的，也能够是逻辑上集中的。但要满足以下原则，第一根据安全级别，便于外界访问；第二便于文档的增量发布；第三便于采集工具的自动化采集编目。各部门只有在文档完全整理归档的情况下，进行自动化采集才是切实可行的。在整理归档的时候，各部门根据各自情况进行归档，没有必要千篇一律，也没有必要制定繁琐和呆板的规则，只要能够满足以上的原则即可。 ●根据安全级别，建立相应的访问机制由于受到安全级别的限制，因此对于需要共享的数据要进行安全方面的限制，限制的手段能够有：用户名/密码、数字证书、物理隔断等等，根据实际情况建立安全访问机制，做到重要信息不泄露，不丢失。 ●编目处理

关于saas平台的多租户架构和元数据架构的设计

一、Saas平台的简介二、多租户架构三、元数据架构 Saas平台：软件即服务是一种通过Internet提供软件应用的模式，服务提供商将应用软件统一部署在自己的服务器上，用户无需购买、构建和维护基础设施和应用程序软件，只需根据自己实际需求定购应用软件服务，按定购的服务多少和时间长短向服务商支付费用。在多租户架构中所有用户和应用程序共享一个由中央维护的单独共用的基础设施和代码库，即多个用户共享相同的物理实体和应用程序的版本。实现多租户数据存储有三种方式：分离数据库、共享数据库，分离Schema、共享数据库，共享Schema。HiServiceCRM系统采用的是共享数据库，分离Schema的方式。主要考虑下面一些因素： ●系统要支持多少租户 ●平均每个租户要存储数据需要的空间大小 ●每个租户的同时访问系统的最终用户数量 ●是否想针对每一租户提供附加的服务，例如数据的备份和恢复等共享性越高，对技术的要求越高。元数据降低了创建应用程序的难度，用户通过简单的点击配置，不用代码就能创建复杂的应用程序。 HiServiceCRM元数据的设计采用动态表单的方式。四、HiServiceCRM是基于Saas的可配置平台 HiServiceCRM是一套基于SaaS模式的业务流程管理系统，具有灵活、便捷和高效的特点，用户可以根据企业自身的业务特点自定义数据模块、业务流程、系统用户和角色等等，系统可以最大限度的满足用户的业务需要和使用习惯。 HiServiceCRM实现了多租户架构，所有租户共享一个基础设施和代码库，而基础设施和代码库由服务提供商统一维护。多租户的实现方式上，主要考虑下面一些因素： ●系统要支持多少租户。HiServiceCRM将面对成千上万个的大量租户。 ●平均每个租户要存储数据需要的空间大小。HiServiceCRM每个租户存储数据需要的空间大小根据租户的用户数来决定，但是不能超过256M。 ●每个租户的同时访问系统的最终用户数量。 ●是否想针对每一租户提供附加的服务，例如数据的备份和恢复等综合上面这些因素之后，HiServiceCRM系统的数据存储从而采用的是共享数据库，分离Schema的方式。 HiServiceCRM元数据的设计采用动态表单的方式。当租户有新的需求之后，大部分需求是通过配置出来的，从而不需要有额外的代码开发，从而降低了实现需求的难度，缩短了开发项目的周期，使租户能够在短时间内应用新的需求。在设计方面动态表单

(整理)数据仓库与元数据管理

数据仓库与元数据管理 1. 前言在事务处理系统中的数据，主要用于记录和查询业务情况。随着数据仓库（DW）技术的不断成熟，企业的数据逐渐变成了决策的主要依据。数据仓库中的数据是从许多业务处理系统中抽取、转换而来，对于这样一个复杂的企业数据环境，如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。本文首先介绍了元数据的定义、作用和意义；然后讨论了数据仓库系统中元数据管理的现状和关于元数据的标准化情况；最后提出了建立元数据管理系统的步骤和实施方法。 2. 元数据 2.1 元数据的概念按照传统的定义，元数据（Metadata）是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据，它主要包括以下信息： ●数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容； ●业务系统、数据仓库和数据集市的体系结构和模式 ●汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、预定义的查询与报告； ●由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统

元数据管理实施方案

————————————————————————————————作者：————————————————————————————————日期：

metadata的初步设计 - 中文元数据标准框架及其应用

中文元数据标准框架及其应用北京大学数字图书馆研究所中文元数据标准研究项目组肖珑? 陈凌冯项云冯英文摘本文通过对北京大学数字图书馆中文元数据标准框架的主要内容及应用实例的介绍阐述了中文元数据标准制定的原则方法和工作流程关键词元数据元数据标准元数据标准框架中文元数据一概述元数据的广泛应用是因现代信息资源处理上的两大挑战而发展起来的一是数字资源逐渐成为信息资源的主流而这些资源从产生存档管理到使用都远远不同于传统的纸介质文献二是网络和数字化技术使信息的发表既快又便捷由此而来的海量信息要求有能与现代计算机技术和网络环境相适应的方便快捷有效的数据发现和获取方法针对各种信息资源包括传统型信息和其数字复制品或天生的数字信息分别制定适当的元数据标准为它的管理发现和获取提供一种实际而简便的方法是数字图书馆建设中首先要开展的工作为了既能兼顾不同资源的特性又能最大程度地实现各类资源在发现和获取方法上的一致性体现数字图书馆的整体性各元数据标准应当从功能数据结构格式语义语法等诸多方面保持一致这种一致性和整体性也便于在更大范围内实现不同数字图书馆或说不同系统间的互操作和数据共享国外在元数据方面的研究工作开展较早已有许多元数据标准被广泛采用我国的元数据研究与应用也取得不少成果对一些具备中国文化特色的信息资源或是直接采用现成的元数据标准通过制订详细著录规则的方法来处理或是借鉴其它元数据的成功经验制订相应的新的元数据标准北京大学数字图书馆的元数据研究项目中视具体资源对象特点的不同分别采用这两种方法来开展工作为了实现前面所说的各元数据标准间的一致性和整体性我们在对大量现行元数据标准和相关研究成果的分析吸收的基础上通过实践总结出一套规范和指导各类元数据标准的设计制定规则和方法称为中文元数据标准框架以下简称标准框架该标准框架初稿完成于2001年1 月7月又作了进一步修订现已成为北京大学数字图书馆后续一系列元数据标准制定工作的规范性文件下图简要揭示了元数据标准框架元数据标准元数据间的关系与作用图1元数据标准框架元数据标准与元数据关系图 ?本文系北京大学数字图书馆研究所中文元数据标准研究项目系列成果之二主要研究人员肖珑陈凌冯项云冯英廖三三姚晓霞执笔人肖珑陈凌

关于元数据

关于元数据 [1]葛岩，元数据DC与MARC的关系及在数字图书馆中的应用元数据，英文名称为Metadata，元数据是一种有效的信息资源组织和管理的工具，是一种编码体系，它可以帮助人们检索和确认所需要的资源，可以对数据单元进行详细的、全面的著录描述，可以支持资源的存储和使用管理，支持对资源进行长期保存 DC即都柏林核心元数据 Dublin Core。DC 元素集是由以下15 个核心元素构成：题名(Title)、主题 (Subject)、描述 (Description)、来源(Source)、语言(Language)、关联(Relation)、覆盖范围(Coverage)、创作者(Creator)、出版者(Publisher)、其他参与者 (Contributor)、权限管理 (Right)、日期(Date)、类型 (Type)、格式 (Fomat)、标识符(Identifier)。 MARC即机读目录，国内一般采用 CNMARC(中国机读目录) 和 USMARC （国际通用机读目录）两种标准分别针对中文与西文馆藏。MARC 以其详细和严谨的风格可以准确的描述图书和期刊，提供管理和检索。 DC与MARC各自的优势。MARC 是一种专属的详细描述的元数据格式，对其著录的内容有着严格规定。从一定程度上看，MARC 是目前发展最成熟的元数据格式，它是其他更新的元数据格式的重要参考依据。但 MARC 描述的书目信息方式适用于图书馆，用于描述完整的、静止的书目信息，是针对印刷型信息资源而设计的编目格式（MARC 格式），对于动态的海量的网络信息资源，其编目方法并不能完全适应；在研究 DC 时，研究人员既在一定程度上参考了 MARC 格式，又在DC 的单元内容上借鉴了 MARC 数据单元的内容，故 DC 被称为 MARC 的网络压缩版。 DC与MARC的联系。DC15 个元素的任一数据元素都是独立描述的，不依赖于具体的编码方法，与任何具体的传输结构都没有必然联系。它可以将其所包含的传统字段通过映射转换为 MARC 格式，与图书馆原有的目录联成一体，使大量已存在的 MARC 可转换为 DC 的元素集，从而实现网络存取；而且也为 MARC 的发展，提供理论和实践的广阔空间。 DC与MARC的区别。1.数据单元形式不同：MARC 采用字段与子字段作为数据单元，对必备字段和可选字段是否可以重复都有严格的规定，DC 采用元素和限定词作为数据单元，所有元素都可选择、可重复、可扩展，限定词和元素间的关系是不确定的，限定词的使用非常灵活，结构较为简单。2. 数据形式不同MARC 格式主要由 3 部分组成：头标区、目次区、数据区。3. 标识不同：机读目录 MARC 的字段采用了 3 位阿拉伯数字作为标识，子字段采用一位英文字母或阿拉伯数字作为标识，其标识不具备语义，不能直观表达；而 DC 采用单词或词组的形式作为标识，语义明确直观，具有自我解释的功能。4. 编码标准不同：机读目录（MARC）的编码标准较为特殊，采用ES022709 作为编码标识，其 MARC 在与其他元数据格式进行转换时，要克服编码不同的问题；而MARC 以 HTML （超文本置标语言）作为编码标准，著录时可使用 HTML 语言为输出结果的网络产品形式，也保留了自己的著录标识系统。5.使用环境和范围不同：MARC 只限于 ES022709 编码标准的信息系统之间传递和交换书目数据，使用范围主要限于图书、情报机构和网上的公共查

元数据管理方案

元数据管理方案元数据管理方案 1.1元数据抽取为了简化元数据生成工作，系统提供自动生成元数据的功能，即元数据抽取。通过元数据自动抽取，用户可以方便、快捷地获得大量的元数据信息。 1.1.1抽取的对象元数据抽取主要针对的对象有以下几种：已有目录：已建业务应用系统中现有的目录资源。数据库：各种数据库资源，包括关系型数据库、XML数据库等。格式化电子文件：电子文件，例如Word PDF XLS等文件。 1.1.2元数据抽取的流程元数据抽取的流程有4个主要步骤，分别为：数据源信息获取：解决要从哪个数据源获得元数据的问题。内容/结构分析：解决要从数据源中获得哪些元数据的问题。

元数据提取：解决如何从数据源中获取元数据的问题。存储入库：解决元数据存储的问题。 1.1.3电子文档的元数据抽取对于电子文档，首先各部门的文档格式不尽相同，另外它们的安全级别也各不相同，同时由于信息化建设水平的不一致，有的部门文档分散在各处，有的部门文档是集中存放的，甚至已经建立了完善的电子系统进行管理。针对以上状况，对于电子文档的元数据抽取需要进行以下的抽取流程：整理归档对于分散在各处的电子文档（纸质文档需要先进行电子化处理），必须由专人进行统一整理，根据公开共享的前提进行集中，这种集中可以是物理上集中的，也可以是逻辑上集中的。但要满足以下原则，第一根据安全级别，便于外界访问；第二便于文档的增量发布；第三便于采集工具的自动化采集编目。各部门只有在文档完全整理归档的情况下，进行自动化采集才是切实可行的。在整理归档的时候，各部门根据各自情况进行归档，没有必要千篇一律，也没有必要制定繁琐和呆板的规则，只要能够满足以上的原则即可。根据安全级别，建立相应的访问机制由于受到安全级别的限制，所以对于需要共享的数据要进行安全方面的限制，限制的手段可以有：用户名/ 密码、数字证书、物理隔断等等，根据实际情况建立安全访问机制，做到重要信息不泄露，不丢失。编目处理现阶段，主流格式的电子文档，主要包含：word、excel 、ppt 、pdf 等。对主流格式的电子文档，要提供自动采集工具进行编目处理。采集的范围主要是文档的标题和内容，对于其它的元数据内容，要提供手工配置的方式进行辅助。另外，在工具的采集效率上，要提高增量文档发布后的采集效率。对于格式特殊、内容有加密算法的文档，是很难通过抓取工具进行采集的，这些文档主要通过手工编目的方式来处理。对于存在管理库的文档，就需要对数据库来进行编目采集，详见数据库元数据抽取部分。

元大数据管理系统模块方案设计

目录 1. 现状分析 (2) 1.1 目前的困境 (2) 1.2 什么是元数据管理 (3) 2. 目标分析 (3) 2.1 建立完善的指标解释体系 (3) 2.2 建立规范的元数据管理体系 (4) 2.3 建立有效的数据稽核体系 (4) 3. 功能概述 (4) 3.1 元数据管理 (4) 3.1.1 业务元数据 (5) 3.2.2 技术元数据 (6) 3.3元数据分析 (9) 3.3.1 血统分析 (9) 3.3.2 影响分析 (10) 3.3.3 重要性分析 (11) 3.3.4 无关性分析 (12) 3.4数据稽核 (12) 3.4.1 稽核规则管理 (13) 3.4.2 稽核任务调度 (13) 3.4.3 稽核结果分析 (14) 3.4.4 数据质量评估 (14) 3.4.5 数据问题管理 (14)

元数据管理系统概述 1. 现状分析随着经营分析系统规模不断扩大，系统所积累数据量也越来越大，收集到的海量数据背后隐藏着大量珍贵重要的信息，但也同时提高了系统的数据管理难度：一方面难以对这些数据进行有效解释，缺乏对业务流程执行的实时监控和管理；另一方面各部门数据与数据整合的难度也不断加大，影响到了经营分析系统中的数据质量。如何对现有数据进行深层发掘，并揭示出埋藏在元数据中的趋势、因果关系、关联模式等核心信息？这是下一步深化经营分析系统应用的电信运营商需要解决的头等大事。构建BI，首先要保证的是数据质量。元数据管理解决的问题就是如何把业务系统中的数据分门别类地进行管理，并建立数据与数据之间的关系，为数据仓库的数据质量监控提供基础素材。 1.1 目前的困境使用者(决策层、业务分析人员)： 1) 经营分析系统中存在有很多报表，不同报表中存在一些相同的指标，这些指标往往不一致，给业务分析和决策工作造成很多困惑，必须花费很大的精力去检查核实。 2) 对于很多指标，不清楚其具体含义，不清楚其反映的问题，不清楚其具体算法和来龙去脉。数据仓库项目开发维护者： 1) 不同报表中的同一指标不一致，必须花费很大的精力去检查，目前基本上是通过手工检查表和存储过程的方式，效率较低。 2) 没有完善的开发、维护规范。比如，新增一张分析报表，开发人员根据业务人员的需求制作完成之后，往往没有整理完善相应的数据指标解释和元数据管理，造成日后检查困难。 3) 开发、维护规范的执行力较低，没有行之有效的管控手段。不严格按照

数据仓库和元数据管理

数据仓库和元数据管理在事务处理系统中的数据，主要用于记录和查询业务情况。随着数据仓库（DW）技术的不断成熟，企业的数据逐渐变成了决策的主要依据。数据仓库是一种面向决策主题、由多数据源集成、拥有当前及历史总结数据、以读为主的数据库系统，其目的是支持决策。数据仓库要根据决策的需要收集来自企业内外的有关数据，并加以适当的组织处理，使其能有效地为决策过程提供信息。数据仓库中的数据是从许多业务处理系统中抽取、转换而来，对于这样一个复杂的企业数据环境，如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。元数据是关于数据、操纵数据的进程和应用程序的结构和意义的描述信息，其主要目标是提供数据资源的全面指南。元数据不仅定义了数据仓库中数据的模式、来源以及抽取和转换规则等，而且整个数据仓库系统的运行都是基于元数据的，是元数据把数据仓库系统中的各个松散的组件联系起来，组成了一个有机的整体。本文首先介绍了元数据的定义、作用和意义；然后讨论了数据仓库系统中元数据管理的现状和关于元数据的标准化情况；最后提出了建立元数据管理系统的步骤和实施方法。建立数据仓库一个重要的工作是元数据管理。按照传统的定义，元数据（Metadata）是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。元数据使得用户可以掌握数据的历史情况，如数据从哪里来？流通时间有多长？更新频率是多大？数据元素的含义是什么？对它已经进行了哪些计算、转换和筛选等等。在需求不确定情况下，在瞬间万变的商业环境下，元数据可以更好的支持需求的变化，降低项目风险。通常把元数据分为技术元数据（Technical Metadata）和业务元数据（Business Metadata）。技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据，它主要包括以下信息：数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；业务系统、数据仓库和数据集市的体系结构和模式；汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、预定义的查询与报告；由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息：使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法以及公式和报表的信息；具体包括以下信息：

元数据管理

1.元数据管理技术及应用现状朋友老朱在最近惊喜地发现，在营业部的每周例会上，原先各部门针对每日用户数的争吵声，现在逐渐销声匿迹了。原来，老朱所在的这家电信运营商，最近刚刚验收并启用了一个元数据管理平台工具。通过这一平台，IT部门可以在那些曾经引发激烈争吵的数字后面加上详细的注解。这样，即便各部门得出的当日用户数数值不一样，也能在注解中清楚地看到具体的差异在哪里。如此，自然再没有了吵来吵去的必要。元数据，最常见的定义是：“关于数据的数据”。更准确一点说：元数据是描述流程、信息和对象的数据。这些描述涉及像技术属性（例如，结构和行为）这样的特征、业务定义（包括字典和分类法）以及操作特征（如活动指标和使用历史）。早在上世纪末，元数据的概念和相关工具就已经出现，但限于当时的数据量还不够大，而元数据本身又包含太多的内容，以至于它并未得到充分利用。而在今天看来，元数据正在成为解决诸多数据问题时必须要抓住的一个“精髓”要素。消弭争吵在此前一年中，老朱所在的那家电信运营商，各部门之间经常就每日用户数这类问题的指标数值不一致而吵得面红耳赤。其实，在其他电信公司或者其他行业中也都存在着类似问题。简单来讲，这些公司通过各个时期的IT建设，形成了很多个独立分开的系统。以电信运营商为例，就有计费系统、网络系统、OA系统、财会系统和客服系统等等。在这些系统中，存有不同的客户信息，具体体现就是不同格式的表。两年前，公司的数据仓库项目建设完成，本以为这会大步提升IT系统的“智能性”，没想到，基层的反映却是根本没法用。而其中的原因就在于，数据质量没法保证，也即：在业务逻辑上并不准确，各部门对于指标的定义不能统一。以当日用户数为例。对于这一指标,市场部、网络部、计费部等部门给出的定义并不一样。按照元数据技术的术语来讲，就是在业务元数据上，大家对于业务的认识并不统一。比如：计费部门认为，一个用户当天曾拨打电话，就可以计入到当日用户数；而财务部门则认定，只有在发生费用之后才能计入；至于网络部，则认为当天开机的用户就可以算作当日用户。如此一来，各部门的当日用户数数值自然就不一样：计费中心的系统显示，当日用户数有6000；市场部的系统显示却只有4000；到了财务部门的系统中，显示仅有3000个。在这种情况下，担负着业务压力的业务人员很可能谁也说服不了对方来接受自己的数字，导致大家对数据仓库系统本身的可信度也就打了折扣。事实上，类似问题在目前已经建成的数据仓库项目中还有很多。其中的一大难题就是，原先未能统一的定义导致了某种指标的不一致，而要搞清楚为什么不一致，就得反查数据仓库中的这些表在一开始的时候是如何定义的，表与表之间的联络关系是怎样的。这种反查工作自然要求IT部门的人员就得详细查阅原先软件的设计。但问题是，现在的软件开发一般都是迭代式开发，每个阶段都有不同的人在做。回查一个表，很可能需要涉及到这个过程中的每一个开发人员。事实上，很少有人能做到这一点。即便费尽心机终于查到了，一个月的时间也过去了。