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

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

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

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

(上海图书馆 200031)

名人手稿是上海图书馆的特藏之一,上海图书馆自1992年开始恢复向社会各界征集名人文献的工作,1996年新馆开放后,更是加快步伐、增强力度进行收集整理,目前藏品已逾5万2千余件。建设一个名人手稿数字图书馆是上海图书馆数字图书馆建设的一项重要工程。

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

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

名人手稿数字图书馆的开发目的是对名人手稿馆所涉及的所有资源进行有效的管理和利用。元数据方案是数字图书馆需求分析和系统设计时需要首先考虑的因素,是数据加工制作、藏品数字化和系统设计与功能实现的基础。制定名人手稿馆元数据方案的目的是提供其所涉及的所有资源类型的属性定义和置标方案(也就是相当于传统上的制定编目规则和目录格式),为名人手稿数字图书馆提供资源管理(又称为内容管理)方案。元数据方案基本上决定了系统的整个架构,以及系统设计(包括各类著录系统、检索系统、管理系统等)的需求。

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

总体考虑

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

1本课题成员有:祝均宙,刘炜,赵亮,浦纯,楼向英,张春景,夏翠娟,孙秀娣,王洪治,徐频,朱小灵,王恺顺。本文执笔:刘炜,楼向英,张春景

2参见:https://www.360docs.net/doc/4e8081173.html,/

重要,而且还要兼顾其永久保存的特性和整个信息处理流程易管理性的考虑。

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

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

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

因此名人手稿数字图书馆的元数据方案是一种“混合”型元数据应用概要的形式,即借鉴OAIS、FRBR以及DCMI目前正在形成的Abstract Model作为方法论,采用以DC-Lib8为基础的“上海图书馆元数据方案”作为核心元数据9,并从多种元数据标准、方案中“复用”元素,对所有元素的语义强调严格遵从,但在著录规范中对在每种特定资源类型中的具体含义进行补充说明,限定或扩展方式也强调尽可能采用现有的框架、体系和规范,并充分采用XML Schema(METS10和MODS11等)和RDFs(WSDL12)提供的结构限定方式,最后再考虑增加子元素或元素。

本文是对名人手稿馆元数据方案的总体介绍,包括原则、流程、框架、模型、元素集(包括核心集和扩展集)及其置标的考虑等等,限于篇幅,不可能介绍得非常详细,规范控制和系统的需求与设计将在以后另文阐述。当然本项目是一个具体实践,限于条件和水平,在实

3Reference Model for an Open Archival Information System (OAIS).Consultative Committee for Space Data Systems (CCSDS).URL:https://www.360docs.net/doc/4e8081173.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.360docs.net/doc/4e8081173.html,/VII/s13/frbr/frbr.pdf(检索日期:2004-2-1)

6Dublin Core Abstract Model.Andy Powell.URL:https://www.360docs.net/doc/4e8081173.html,/documents/abstract-model/(检索日期:2004-1-14)

7 RDF V ocabulary Description Language 1.0: RDF Schema.W3C Proposed Recommendation.URL:

https://www.360docs.net/doc/4e8081173.html,/TR/rdf-schema/(检索日期:2004-2-1)

8 Library Application Profile.Rebecca Guenther.URL:

https://www.360docs.net/doc/4e8081173.html,/documents/library-application-profile/(检索日期:2004-1-14)

9这一核心集也包含了IFLA提出的10项“核心记录元素(Core Metadata Elements)”集合(草案)。参见:https://www.360docs.net/doc/4e8081173.html,/VII/s13/guide/metaguide03.pdf

10 Metadata Encoding and Transmission Standard (METS).URL:https://www.360docs.net/doc/4e8081173.html,/standards/mets/(检索日期:2004-1-14)

11Metadata Object Description Schema (MODS).URL:https://www.360docs.net/doc/4e8081173.html,/standards/mods/(检索日期:

2004-2-1)

12 Web Services Description Language (WSDL) 1.1.W3C Note.URL:https://www.360docs.net/doc/4e8081173.html,/TR/wsdl(检索日期:2004-2-1)

现时必然有许多妥协和折衷,缺憾之处在所难免,敬请批评指正。

设计原则

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

通用原则包括如下六项13:

1.简单性与适用性原则

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

2.专指度与通用性原则

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

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

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

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

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

5.用户需求原则

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

13六项通用原则的前五项参考2003年7月《专门数字对象描述元数据规范研制工作手册(修订稿)》并根据名人手稿馆的应用进行了扩展与细化后拟定。

6.遵循现有标准原则

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

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

设计流程

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

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

资源特点

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

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

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

求。

资源类型

通过资源分析报告可以归纳出每种资源类型的特点,从而确定满足其需求的属性元素,元素之间的关联以及结构,从而确定每种资源类型的元数据方案,达到对名人手稿馆资源细致揭示的目的。下面就以上各方面对每种资源类型进行说明。

创作手稿

创作手稿指的是名人在创作或研究过程中所产生的手书文字记录,可以是草稿、未定稿、校改稿(包括打印稿的手书校改稿)或最终的完成稿。创作手稿的体裁不限,可以是任何一种文学作品,也可以是论文,但不包括书画作品和其他艺术作品。鉴于创作手稿是未出版的公开发表物,具有不确定性,所以创作手稿的每一次修订都作为一个版本,因此名人手稿馆对其著录到每一种创作手稿的修订稿。创作手稿的价值就在于名人的笔迹和手稿所作的一系列修改,所以我们将打印稿不算作创作手稿的一部分,在重点揭示创作手稿的作者的同时,并对在创作手稿的过程中所使用的书写工具,文字色泽和稿件的修订作为描述的重点。手稿的抄写人虽然对手稿的“内容”没有贡献,但鉴于手稿的抄写人与手稿作者之间的关系一般会比较密切,因此我们将手稿的抄写人作为“誊抄者”元素放入元数据方案。创作手稿中有一部分是翻译稿,即翻译国外作品的稿件,针对此类手稿,我们还特别描述了稿件的原作题名,原作的作者,原作的语种等内容。

信函

信函指的是指源自名人的各类通信,包括信件、明信片、贺卡、请帖等。我们将每一份信函作为一个著录单位,普通信件可以包括信封、信纸或附件。信件同时包含信封与信纸者,作为一个完整的著录单位著录。仅有信封或仅有信纸者,信封或信纸作为一个单位著录。对于一个信封包含多封信件,著录时要在“关联”字段说明关系。并把信封和每封信件都作为单独的著录单位。收信人对写信人的回信,这个过程中两封信件之间存在一定的继承关系,两者的关系也需在“关联”字段中说明。信函也是名人的手迹,因此信函的描述中也包括了书写工具和文字色泽元素,由于信封和信纸会出现使用不同的书写工具和不同的文字色泽,因此我们将信纸和信封都分别用书写工具和文字色泽进行了描述,并对信纸的风格特征也进行了揭示。由于信封是作为信函整体整体的一个部分,因此除了对信纸内容进行充分揭示以外,还增加了收信人地址栏,寄信人地址栏,收信人邮编,寄信人邮编,寄信邮戳日期,收信邮戳日期,收信人,寄信人这些元素。

日记

日记指的是名人按照日期记载事物或个人感受的文字记录,包括日记本、记事本、备忘录、日历本、帐册等。每册日记,每本记事本和记帐本都单独作为一个著录单位。日记总册中包含若干本单册日记,所以在著录时,需要对单册日记著录的同时也需对日记总册进行著录,并说明两者之间的关系。

照片

照片是指以摄影形式记录名人及其家属,友朋生活、工作的文献载体。每张照片为一个著录单位。对于照片总集中包含若干照片的情况,原则是对每张照片著录的同时也对照片总集进行著录,并在著录时,在“关联”字段说明单张照片出自哪一本照片总集。而对于来自原照或者报刊的模拟照和翻拍照,杂志,著录时原照和模拟照,翻拍照分别著录,并说明模拟照和翻拍照的出处;还存在照片与底片的衍生关系,著录时对底片不予著录,只说明底片的类别和规格。由于照片的著录不是针对照片本身,而是针对照片中的人物,因此我们重点揭示的是照片中的人物,从而设置了人物和位置元素,由于人物和位置是一一对应的关系,

所以在著录时,人物和位置需要成组出现。

书画篆刻作品

书画篆刻作品是指以刀、笔等作为工具,利用墨或各类颜料,在纸、石或其它载体上创作的平面视觉艺术作品。每幅书画、每件作品都单独作为一个著录单位。书画篆刻作品是名人手稿馆资源中描述和著录难度最大的一类资源,由于书画篆刻的组成部分比较多,如一幅书画篆刻作品主要由书,画,题记和印章四部分组成,所以描述的元素也很多,不仅要描述书法的行款,书体,内容,书写工具和文字色泽,还要描述画的技法,画的材质,题记的作者,题记内容,题记的类别,印章所有者,印章的位置,印章的类型,印章的印文,印章的印文类型等。并且一副书画作品中可能有多个题记者,多个题记,也可能有多个印章,所以题记的所有内容都需要成组出现,印章所有者,印章类型,印章位置,印章印文,印章印文类型也需要成组出现。

签名本

签名本指的是带有名人签名、题词、印章或其它印记的纸质印刷本或出版物。对于正式的签名本,著录时以“种”为单位,即一位名人捐赠的一套书为一种,捐赠的单本书也可以为一种,对于一套书可以做一条单独的记录,但包括的书籍需做分析著录。由于签名本在名人手稿馆的价值主要在于其签名部分,并且上图馆藏中已经有其相应的书目记录,所以在描述时,我们主要描述签名部分,此处跟书画篆刻的题记部分比较类似,主要有题记,藏书票和印章三部分,并且由于存在一一对应关系,每个部分都各自成为一组。题记主要有题记作者,题记全文,题记位置,题记类别等元素,藏书票主要有藏书票尺寸,藏书票文字,藏书票图案描述三个元素,印章有印章所有者,印章类型,印章位置,印章印文,印章印文类型五个元素。

纸质资料

纸质资料指由名人捐赠的、不带有名人签名或印章的打印或复印文献,主要是指与名人相关的,或有关名人参与的重大历史事件的打印资料或剪报、期刊资料等。每一种纸质资料为一个著录单位。这些与名人有关的打印资料,剪报或者期刊资料一般都是由与名人关系比较密切的朋友或者名人的晚辈收集、捐赠,因此在元数据方案中我们增加了“收集者”这一元素。

音像资料

音像资料指以磁光等介质记录的有关名人或名人捐赠的视频、音频资料。鉴于音像资料比较特殊,比如一个采访内容可以分几个光盘,一个采访内容可以有光盘,磁带,录像等多种载体形式,所以音像资料的著录级别不以音像资料的存储介质来划分,而是以一个完整的内容为一个著录级别,不同的存储介质可在复本管理中进行说明。一个长达半小时的完整的音像资料有可能只有当中的几分钟是最关键的,因此我们在描述时,设立了关键片断开始码,关键片断结束码,关键片断描述等元素对关键的内容进行描述。一部音像资料的完成所涉及的人物也是较多的,例如有采访者,口述者,解说者,制作者等,因此对这些人物的说明非常重要,为此我们设立了“人物”和“出现时码”元素,并且这两个元素是一一对应的关系,需要成组出现。

笔记本

笔记指的是名人在听课、听报告、读书等情况下所做的摘抄、随想等文字记录,没有确切时间或者不是以日期作为记录顺序的。每册笔记都单独作为一个著录单位。笔记资源类型中也存在与日记类似的总册的情况,所以有包含关系,可以在关联字段中予以说明。笔记也是名人手迹的一种体现,因此在描述笔记时,我们也使用了“书写工具”和“文字色泽”元素。

实物

实物指由名人创建或使用过的,或其它与名人有关的物品,除已归入上述各类的之外,比如印章、证章等。每件实物单独作为一个著录单位。实物是比较特殊的一类资源,对它的描述就有点类似博物馆对其馆藏的描述,由于我们不是专业的博物馆,所以只选择了一些与名人很相关的元素来对其描述。由于实物可能是名人自己制作,也可能是名人出于爱好收集,也可能是一个名人(或团体)赠与另外一个名人,因此我们除了设立“创建者”元素外,还设立了“收集者”、“颁发者”、“颁发对象”等元素,并同时对实物本身的“材质”和“色泽”进行说明。

证件指名人用于各种场合、代表其身份的文件,在范围上包括了出入证、医疗证、工作证、代表证、选民证、挂号卡、小名片等。每个证件都单独作为一个著录单位。

证书指由机关、学校、社团等颁发给名人以表彰其成就或授予其荣誉的文件。每张证书单独作为一个著录单位。

图2:名人手稿馆资源实体关系图

元数据方案

方案的性质

从整体上看,元数据对于信息系统来说,具有描述、定位、发现、证明、评估,检索等作用(FRBR14定义了元数据最主要的四个功能:查找Find、标识Identify、选择Select和获取Obtain)。元数据方案应该能够全面描述信息系统中与信息资源相关的各类特征和属性,

14参见:https://www.360docs.net/doc/4e8081173.html,/VII/s13/frbr/frbr.pdf

包括静态特征、状态特征、生命周期特征、管理特征以及系统在实现功能过程中所要求的其他语义信息等等,而不仅仅是描述性信息,而实际上人们研究和使用较多的大都是描述性元数据,对于其它类型的元数据15,例如保存型元数据可以参考一些现成的参考模型或国际标准(例如OAIS),或者一些大馆的元数据方案(例如美国国会图书馆的“美国记忆”项目的方案)来制定;管理型元数据和技术性元数据,大多交给系统分析和设计人员提供解决方案,这些数据元素大都可以在系统运行过程中自动生成,或在进行数字化、数据转换、或数据装载的过程中进行机器辅助人工添加。因此,名人手稿馆的元数据方案主要是一个描述性元数据的方案。

方案的组成

制定具体的元数据方案不同于元数据标准规范的研究,后者只需要少数一些推荐文件,甚至只有一组元数据元素集就可以了,而元数据方案需要一整套指导实施的文档,可以按照前文的流程确立文档,也可以根据实际需要制定。本方案主要包括以下6个文档,然而本节主要介绍方案中最重要的元素集方案、置标方案和著录规则,其中元素集方案参考ISO11179的要求名称,选取了14个属性进行定义。这14个属性是:中文标识、英文标识、命名域、版本、注册机构、语言、应用规则、定义、注释、数据类型、最大出现次数、元素修饰词、编码体系修饰词和最佳操作。

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

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

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

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

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

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

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

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

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

属性元素集——核心集及基本扩展

如前文所述,本方案的核心集为以DC-Lib为基础的《上海图书馆元数据方案》,选取其中18个元素中的17个(不包括其中的“用户对象(Audience)”元素)以及多种资源类型共有的元素作为核心集,但核心集并不是必备集。整个方案采用混合型的元数据概要(Metadata Profile)形式,包括核心集和扩展集两个部分,复用了CDWA16的4个元素(材料与技术、制法、相关文本信息、题记或标记)和REACH17的1个元素(出处),并且针对名人手稿馆资源的特殊性,扩展了5个个别元素(获得方式,捐赠日期,捐赠者,书写人,载体形态附注)。方案允许每个元素对于不同的资源类型有不同的“显示名”和不同的元素修饰词与编码体系修饰词,限定方式原则上限制在两层。由于名人手稿馆所要求的资源类型的开放性,我们考虑其属性元素集为各已知资源类型所需元素的并集(即目前的核心集和扩

15对于元数据的类型并无统一公认的划分,IFLA在一份元数据应用指南文件(Guidance on the Structure, Content, and Application of Metadata Records for Digital Resources and Collections a draft for review, 参见https://www.360docs.net/doc/4e8081173.html,/VII/s13/guide/metaguide03.htm)中将元数据分为管理型、描述性、分析型(Analytical)、版权管理和技术性五种,传统上可以分为管理型、描述性、保存性、技术型、使用型等五类。

16Categories for the Description of Works of Art(CDWA).URL:

https://www.360docs.net/doc/4e8081173.html,/research/conducting_research/standards/cdwa/(检索日期:2004-2-1)

17RLG REACH Element Set for Shared Description of Museum Objects .URL:

https://www.360docs.net/doc/4e8081173.html,/reach.elements.html(检索日期:2004-2-1)

展集),新增的资源类型原则上只能从已有的属性元素集合中选取元素,否则增加或修改属

性元素都会给已经实现的应用系统构成挑战。这样元数据方案才能保持必要的稳定性。

1.核心集

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

标识符dc:identifier

索取号 callNo

排架号shelvingControlNumber

题名 dc:title

交替题名dcterms:alternative

创建者 dc:creator

责任方式creator.role

其他责任者 dc:contributor

责任方式contributor.role

出版者 dc:publisher

版本 dc:edition

日期 dc:date

创建日期 dcterms:created

修改日期 dcterms:modified

格式 dc:format

大小 dcterms:extent

媒体dcterms:medium

主题 dc:subject

说明内容提要dc:description

来源 dc:source 覆盖范围 dc:coverage 语种 dc:language

类型 dc:type

权限 dc:rights

关联 dc:relation

参照dcterms:reference

馆藏位置 mods:location 获取方式 marc:availability

载体形态附注marc:notesPertainingToPhysica

lDescription

工具 cdwa:implement 颜色 cdwa:color

创作地 reach:placeoforigin/discovery

个人名称 person 团体名称 corporate 重要事件主题 events

地名主题 place

个人捐赠者 personaldonator 团体捐赠者 corporatedonator

捐赠日期 donated 装订形式

descriptionOfBinding

2. 扩展集

表2:

资源类型

著录单位 扩展元素 XML/RDF 标签是否必备

是否可重复 誊抄者

Scribe

供选择 可重复 创作手稿

手稿的每一个版次。

学科名称主题topicOfSubject 供选择 可重复 发送邮戳日期postmarkFrom 供选择 可重复 接收邮戳日期postmarkTo 供选择 可重复 信函完整性附注integralityAnnot

ation 供选择 可重复 信纸风格特征styleOfLetter 供选择 可重复 信封收信者 acceptor 供选择 可重复 信封寄信者

sender

供选择 可重复 寄信人地址栏addressOfSender 供选择 可重复 寄信地邮编

postalcodeOfSen

ding 供选择 可重复

收信人地址栏addressOfAccept

or

供选择 可重复

信函

单一信函

收信地邮编

postalcodeOfAcc

epting 供选择

可重复

日记

每册日记,每

本记事本和记帐本

丛编题名

dc:isPartOf 有则必备 不可重复

拍摄质量 quality 有则必备 不可重复 底片类别

typeOfFilm 有则必备 可重复 底片规格 sizeOfFilm 有则必备 可重复 人物 person 必备 可重复 位置 location 必备 可重复 照片

每张照片

照片总集名

dc:isPartOf 有则必备 不可重复 签名者 signatory 有则必备 可重复 印章所有者 ownerOfSeal 有则必备 可重复 行款 NumberOfRows

有则必备 不可重复 技法 facture 有则必备 可重复 题记位置 cdwa:inscription s/marks.location 有则必备 可重复 印章位置 locationOfSeal 供选择 可重复 书画篆刻作品

每幅书画、每件作品

题记类别 cdwa:inscription s/marks.type

供选择

可重复

印文类型InscriptionsType

OfSeal

供选择可重复

印章类型供选择可重复

书体cdwa:inscription

s/marks.typeface

供选择可重复

下款内容subscript 供选择可重复

印章印文 inscriptionsOfSe

al

供选择可重复

上款内容superscript 供选择可重复

题记全文cdwa:inscription

s/marks.transcrip

tionOrDescriptio

n

供选择可重复

材质cdwa:materialsA

ndTechniques.m

aterials

供选择可重复

签名者signatory 有则必备可重复印章所有者ownerOfSeal有则必备可重复

藏书票文字inscriptionsOfSt

amp

有则必备不可重复

藏书票图案描述descriptionOfSta

mp

有则必备可重复

藏书票尺寸sizeOfStamp

题记位置cdwa:inscription

s/marks.location

有则必备可重复

印章位置locationOfSeal供选择可重复

印文类型InscriptionsType

OfSeal

供选择可重复

印章类型供选择可重复

印章印文inscriptionsOfSe

al

供选择可重复

题记全文cdwa:inscription

s/marks.transcrip

tionOrDescriptio

n

供选择可重复

签名本每一种签名

本和捐赠本

丛编题名dc:isPartOf 有则必备不可重复

纸质资料每种纸质资

收集者collector 有则必备可重复

开始时码timeOfStart有则必备可重复

结束时码timeOfEnd有则必备可重复

出现时码

timeOfApperanc

e

有则必备可重复

音像资料一个完整的

内容

关键片断描述descriptionOfKe供选择可重复

ysegment

关键片断开始码startOfKeysegm

ent

供选择可重复

关键片断结束码endOfKeysegme

nt

供选择可重复

声音描述descriptionOfV oi

ce

供选择可重复

笔记每册笔记

证件每本证件

证书每张证书

收集者collector 有则必备可重复

实物每件实物

材质cdwa:materialsA

ndTechniques.m

aterials

有则必备可重复

置标方案

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

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

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

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

著录规则

由于名人手稿馆的资源种类繁多,相互差异性较大,具体的标引人员对不同资源类型的

熟悉程度一般都是不同的,因此我们在名人手稿馆元数据方案的指导下,对每种资源都编制

了详细的著录规则,对每种资源的个性之处和揭示要求进行了详细充分的说明。

规范档

利用规范档进行规范控制在情报检索中属于事先控制行为,如果进行得彻底,能够按照

概念语义组织信息资源,通过概念的联系建立资源之间的关系,一方面大幅度提高信息系统

的查准率和查全率,另一方面启发和引导用户的查询行为。然而“先组式”情报检索系统所

花费的代价也是非常大的。首先建立一个准确的规范档需要领域专家们呕心沥血的工作,其

次利用规范档进行标引工作也是非常费时耗力的工作,即使经过大量的培训,其一致性也难

以把握。在名人手稿馆著录系统中,规范档的主要作用在于对元数据库进行规范控制,以保

证元数据库的一致性,同时在未来的系统中起到聚集、规范、扩展、关联的作用。由于名人

手稿馆的目标就是收集关于“名人”的各种资源,因此名人手稿馆著录系统目前只实现了关

于人名的规范档控制,包括规范名,出处,国籍,民族,生年,卒年,籍贯,出生地,性别,

小传,专长,著作,职衔,关系人等字段。在以后的工作中,根据实际情况将逐步实现对团

体名称,地理名称,主题,作品,事件等的规范控制。这将是一个漫长而细致的过程。

编码体系

编码体系是对元数据取值的约束和规范,是修饰词的一种,用来说明元素所表达属性的

值,包括控制词表及正式的符号体系或解析规则两类。用某一编码体系表示值意味着这个值

来自于某一控制词表(包括控制词表的语义符号,如分类体系或主题词表中的术语),或者

其格式符合某种正式编码标准的字符串(如“2000-01-01"作为一个日期的标准表达)。

编码体系的采用有助于提高数据的质量、通用性和互操作性。从一个更广泛的意义上看

前文所述的规范档也是一种编码体系,例如人名规范档就在人名取值时作为规范名使用。在

名人手稿馆的各类资源中我们经过研究和讨论,自定义了大量的编码体系,如下表所示。其

中有一些复用了相应的标准,但更多的则因为没有现成的标准,我们不得不从实用的角度出

发进行定义,没有作严格的规范,可能在今后的应用中还需要修改。

Scheme中文名称 Scheme英文名称 Scheme

获取方式 Availability 捐赠/翻制/自拍/移交/购买/竞拍/原存/

征集奖励/不详

权限 Rights 公开/绝密/机密/秘密/内部 装订方式 descriptionOfBinding 精装/平装/线装/未装订

创作手稿文献类

型 typeOfScript

原稿/校改稿/复写稿/清样校勘/手写复

印件/打印稿/复制件/抄稿

书写工具 Implement 毛笔/钢笔/圆珠笔/铅笔/水笔/油画笔

/硬笔

文字色泽 color 黑色/蓝色/红色/蓝黑色/绿色/紫色

书写工具 Implement 毛笔/钢笔/圆珠笔/铅笔/水笔 /油画

笔/硬笔

日记文献类型 typeOfDiary 日记/记事本/帐册/备忘录/日历

书体 styleOfCalligraphy

隶/篆/楷/行/草/鸟虫

材质 materials 绢/宣纸/绵纸/卡纸/油光纸/彩画纸/书

写纸/其他纸/竹/布 装裱形式 Mount

立轴/手卷/屏/横批/扇面/册页/对联/镜

片/斗方/无装裱 载体形态附注 notesPertainingToPhysical

Description

册面/函套/木盒/纸盒/布套/夹板 题记类别 typeOfInscriptions

一般题记/题识/题端/题跋/外题签/内

题签

印章类型 typeOfSeal 名章/斋馆印/别号印 印章印文类型

typeOfInscriptions

朱文/白文/朱白文 按是否原件分:原件/复制件 书法 按书体分为:隶/篆/楷/

行/草/鸟虫 绘画按技法分为:国画/版画/油画/素描速写/水粉水

彩画/其他 书画文献类型 typeOfDrawing

按体裁分:书法 /绘画/设计稿/篆刻作品/书画综合作品

绘画按用途分:宣传画/漫画/年画/连环画/其他

按内容分:友朋/家书/公事/公函/情书

按载体分:一般信函/贺卡/明信片/请

柬 信函文献类型

typeOfLetter

按形式分:手写/复写/打印/复印 按内容分:口述历史/名人传记/文献

展览/名人活动

按形式分:视频/音频 音像文献类型 typeOfAV

按是否原件分:原件/复制件

拍摄质量 quality 优/一般/差 照片颜色 PictureColor 黑白/彩色 底片类别 typeOfFilm 正片/负片/反转片/数码 底片规格 sizeOfFilm

120/135/127/APS

按人物数量分:单人照/双人照/多人照按人物关系分:友朋照/夫妻照/家庭成

员照/师生照/同 照片文献类型

typeOfPicture

按照片内容分:学照/政要照/大型团

体照/同事照

本馆采访照/社会活动照/学术活动照/生活照/旅游观光照/出访照/采访照/工作照/会议照/展览会照/学位照/证件照/演员造型照/艺术照/生日照/结婚照/悼念照/历史事件照/舞台设计照/剧照/学术资料照/建筑照/模拟照

按是否原件分:原照/翻拍照

证件文献类型 typeOfPaper 出入证/医疗证/工作证/代表证/选民证/挂号卡/名片/其他证件

证书文献类型 typeOfCertificate 获奖证书/聘书/委任书/毕业肆业证书/

其他证书

责任方式 role 著/编/译/书/画/篆刻

实物文献类型 typeOfPracticality 第一层分类:

证章/其他实

第二层分类:证章按

照类别:奖章/纪念章

/徽章

签名本文献类型 typeOfSignatureFile 签名本/捐赠本

技法 skill 国画/版画/油画/素描速写/水粉水彩画

/其他

异名类别 typeOfNickname 原名/笔名/字/号/曾用名/初名/又名/室名/昵称/绰号/简称/谥号/化名/外文名

与个人标目之关

系 relationOfPerson

友/父/母/兄/弟/姐/妹/子/女/夫/妻/媳/

师/一般亲戚/

国别 nation 国别scheme表

地区 region 地区scheme表

语种 language 汉语,英语,日语,德语,法语,俄语,朝语

民族 race 汉,蒙,满,回,藏

ISO8601 ISO8601 类似2001-08-07或20010807国际标准书号 ISBN 国际标准书号说明

名人手稿馆元数据著录系统

名人手稿馆元数据著录系统项目于2004年5月开始启动,一边研究一边开发,数据加工也同期开展,而确定元数据方案和元数据加工管理的功能需求是该系统开发的核心工作。基于此系统的重点在对馆藏内容的揭示,元数据方案的广度和深度方面有较高要求,因此元数据元素及其修饰词和编码体系的设定和配置是方案的难点,项目的设计、开发和使用者如果不能就这个方面尽快达成一致,必然会影响到系统的开发进度。事实证明在整个开发过程中研究开发与应用实施是互相牵制而又互相促进的。

名人手稿馆著录系统的整个系统架构分著录流程和管理流程两大功能。著录系统的著录过程支持TCP/IP及HTTP协议的因特网WEB环境,即著录为WEB方式,属浏览器/服务器结构(B/S);系统后台采用MS SQL或功能相当的关系型数据库为管理系统,前端采用WEB服务器加JSP方式的应用模式,同时辅之以采用JA V A等开发的系统工具程序,构

成一个完整的支持多种元数据应用规范的联机元数据著录系统。著录系统的客户端为标准的浏览器,主要为微软的IE浏览器。但是由于多种元数据应用规范维护上的复杂性,对元数据维护,采用专用的客户端软件形式。

由于此项目的定位是不仅要满足对名人手稿馆现有十三种资源的著录,而且可以满足将来上海图书馆所有资源的著录。基于以上目标,名人手稿馆著录系统中有一个重要的模块:元数据模式(Metadata Schema,指经过XML或RDF等形式化语言编码的元数据方案)的管理工具,此工具可以支持任意多种元数据方案,支持对任意多种资源的著录。因此使用此工具不仅可以任意增加元素和修饰词,任意配置不同元素组成的多个组,任意添加索引字段,还能支持元素和组之间的任意排序。而针对每个元素可以规定其上级元素,可以添加元素的默认值,可以规定元素属于字符串还是长文本,可以规定元素是否必备,规定元素在某个数量区域内重复添加,并且可以指定该元素是否连接人名规范档,是否给读者浏览的权限,等等。

利用此工具还可以实现元数据模式的导入导出,通过元数据模式导入功能把一个XML/RDF Schema导入到能够进行Schema转换的功能模块中,以便与元数据著录、存储进行映射;对导入的元数据模式进行系统设定,在导入元数据模式的基础上设定其他参数,并转换成系统内部元数据存储、元数据著录等操作相关的数据结构及其他内容;还可以进行系统中元数据模式的格式转换,并且可选择同时导出与XML schema相关联的数据。

图三即为名人手稿馆著录系统的schema管理工具的配置界面。

图三:schema管理工具配置界面

对schema管理工具对某种资源的元数据方案进行配置以后,还需要对元数据方案中所涉及到的编码体系进行配置。在本项目中,为了便于管理,将值列表和编码体系用统一的模式进行管理。由于系统支持任意多个schema的配置,从而导致scheme和值列表必定是不断增加的,并且对应于一个元素,可能有多种编码体系和值列表对其进行修饰,每一种编码体系和值列表都有自己的数据验证方式,因此名人手稿馆著录系统的编码体系管理可以实现对scheme和值列表的手工添加、修改、删除、查找等功能。

下图即为编码体系管理的系统界面

图四:编码体系管理界面

在schema管理工具和编码体系管理中对某种资源的元数据方案进行配置以后,就可以利用著录界面进行著录了,在系统的整个著录过程中,除了提供主要进行著录的著录界面功能以外,还提供了“编目树”功能,如果要全屏显示著录界面,可以将该编目树关闭。

在著录界面中,用红色星号显示了必须著录的必备字段,否则无法保存,并且还提供任何字段的无限重复添加,字段的删除,字段的成组添加,成组删除功能,对于著录人名的字段,可以直接将其著录内容链接到人名规范档。著录工作结束后,系统提供保存和临时保存功能,点击临时保存,则该条记录存入临时库,经校对人员校对后正式保存入库。系统在此还提供工作单的载入功能和对整条记录的密级管理的功能。系统中的编目树功能,可以提供点击编目树的任何一个字段,系统就将此字段添加到著录界面中的相应的元素下方,而且该编目树还可以反应该资源的元数据方案元素和修饰词,元素和编码体系修饰词之间的层级关系。

图五:著录界面

名人手稿馆著录系统作为一个专门管理各种名人资源而开发的系统,具有其独特性,名人和名人之间,名人和资源之间,具有复杂的关系。因此需要提供一种在名人与资源间的浏览功能,即名人导航功能。名人导航界面主要分三大块,分别是:“当前人物”,“关系人”和“与当前人物相关的资源”。系统在此提供两大功能,第一:系统首先在界面的导航栏显示名人手稿馆中的重要名人,点击任何一个名人姓名后,该名人成为“当前人物”,并显示和其有关系的其他名人及和相关资源。当前人物除了能浏览界面提供的规范名,职衔,小传,点击当前人物的规范名可以对整条规范档数据进行浏览,并提供当前人物的大头照。也可以点击与该名人有关系的其他名人,并以被选择的名人作为一个基准点进行下一步的信息显示;点击相关资源的题名时,则显示资源中的详细内容。第二:界面提供用于人名检索的检索框,进行检索后,页面显示该名人及其与该名人有关的其他名人和资源的关系图。此后的操作与第一项功能相同。这样可以层层叠套,将名人手稿馆的整个资源囊括和串联起来,形成名人手稿馆信息系统的一个特点。

存在的问题和未来发展

名人手稿馆元数据方案的实现有许多独特的难点,一些已经得到解决,一些还没有很好的方案。例如同样的元素对于不同的资源具有不同的名称(如:书信的责任者为“下款名”),而系统内部必须默认为一致,我们的解决方案是为每一个元素设立三个名称,即中文标识,英文标识和显示名称,中文标识保证了元数据方案的统一,英文标识有利于与国外元数据方案的互操作,显示名称又有利于专门领域工作人员的标引和用户对资源的利用。另一个相关的比较棘手的问题是不同的资源类型对同一个元素具有不同的元素修饰词与编码体系修饰词,目前我们只能同时支持此元素下所有的元素修饰词和编码体系,否则只能将元数据方案

按照资源类型拆开,这与我们的设计思想是相悖的。

目前名人手稿馆的元数据方案主要考虑资源系统内部的互操作(即跨库检索),主要依靠核心元素来实现,而核心元素的互操作主要通过其支持和复用DC等元数据标准来实现,在名人手稿馆著录系统的各个资源类型子库的基础上对各子库中的名人信息进行勾连,即名人手稿馆著录系统中已经实现的“名人导航”功能,此外还可以与上图的馆藏书目数据库进行链接,更大范围之外可以与档案馆、陈列馆、文化馆、博物馆、纪念馆和其他图书馆的相关书目进行链接,例如国家图书馆的名人手稿馆,收藏有300多位名人的约5000多种手稿,书目记录采用MARC格式。目前名人手稿馆著录系统已经实现了元数据方案与MARC的映射,因此通过Z39.50网关与上海图书馆、国家图书馆乃至全国其它图书馆进行链接没有任何问题,将来通过开发OAI接口与互联网上其它的手稿资源库进行链接也是有可能的。但要实现丰富、灵活的外部勾连还必须考虑更多的互操作协议和技术标准,关注这些标准规范的发展动态。

完整的名人手稿数字图书馆系统是一个包含数字化加工制作、元数据生成加工处理、元数据存储转换检索发布管理、数字资源对象管理等各个部分,如下图所示。最近上海图书馆初步完成了“数字资源服务平台”项目,整合了上海图书馆内大部分数字资源和数据库系统,能够为用户提供一个统一的资源整合平台,实现了统一用户登录。使用此系统,用户只需要一次登录便可以随便查询里面整合的数据库,逻辑上实现了统一检索的功能。名人手稿数字图书馆系统也将作为这个数字图书馆的组成部分,集成到这个数字图书馆门户中去。名人手稿数字图图书馆系统在元数据加工处理方面为上图数字图书馆提供了一个样板,即核心元数据采用上图资源集合元数据方案,但每种资源都保留自己相对独立的元数据方案。目前在解决多种元数据模式的管理问题时采用一张融合大表的方式,可以看成将多个元数据方案的XML Schema合并成一个大的XML Schema,而没有采用多模式映射或多模式表层级管理的方式,主要考虑到现有软件工具和技术条件下实现起来较为简单。

数据库管理系统课程设计

“k数据库管理系统B”课程设计要求 一、课程设计基本步骤 1.提出问题。首先确定用户对象,描述用户业务现状。 2.数据库设计。设计E_R模型,设计关系数据。 3.系统实现。基于SQL SERVER环境,建立数据库,建立相应的表和视图,建立表间联系,实现各种数据约束。 4.调试运行。输入测试数据,进行调试分析,纠正错误。 二、课程设计文档要求 根据课程设计基本步骤组织文档。 1、封面。 2、系统开发目的。确定系统应用环境,及统开发目的。 3、系统概述。确定用户对象,描述用户业务现状,确定系统功能。 4、数据模型设计。由用户业务需求得出数据E_R模型。 5、数据库设计。由E_R模型转换成数据表,建立表间联系。规范表设计至3NF (如有特殊情况未达到3NF需说明理由)。 6、数据库实现。基或SQL SERVER环境,建立数据库,建立数据表,建立表间 联系,实现各种数据约束。 7、调试运行说明。输入测试数据进行调试分析,给出调试运行的有关情况说明。 8、总结。总结个人在本次课程设计中遇到的问题和心得体会。 9、成绩评定表。 三、课程设计具体实施办法 1、第16周由任课老师给出数据库课程设计题目,同学在选题时,每人一题。。 2、18周结束前将所有设计结果交任课老师。 3、课程设计提交的具体内容:课程设计文档(每人一份打印稿+电子档,文件 命名规则:学号+姓名,如"100322011李响.doc")、课程设计数据库文件(文件命名规则:学号+姓名)。由课代表将所有打印稿和电子档(全班刻一张光盘,含文档和数据库)收齐后在规定时间内统一交任课老师。逾期不交者视为弃考,按学校相关规定参加重修或者重新分配题目参加补考。 4、期终考核成绩构成:总计100分,课程设计占70%,平时成绩占30%。 四、课题设计选题题目 题目姓名学号题目姓名学号 1书店购销管理数据库41城市人口消费水平子系统 2高校人事管理子系统42农村人口收支状况子系统 3高校工资管理子系统43某地区人力资源统计子系统 4高校设备管理子系统44某地区水资源统计子系统

元数据设计文档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 和云服务,都可轻松分析其中的数据。 数据可视化是科学、艺术和设计的结合,当枯燥隐晦的数据被数据科学家们以优雅、简明、直观的视觉方式呈现时,带给人们的不仅仅是一种全新的观察世界的方法,而且往往具备艺术作品般的强大冲击力和说服力。如今数据可视化已经不局限于商业领域,在社会和人文领域的影响力也正在显现。 数据可视化的应用价值,其多样性和表现力吸引了许多从业者,而其创作过程中的每一环节都有强大的专业背景支持。无论是动态还是静态的可视化图形,都为我们搭建了新的桥梁,让我们能洞察世界的究竟、发现形形色色的关系,感受每时每刻围绕在我们身边的信息变化,还能让我们理解其他形式下不易发掘的事物。 二、项目简介 目前,金融机构(银行,保险,基金,证劵等)面临着诸如利率汇率自由化,消费者行为改变,互联网金融崛起等多个挑战。为满足企业的发展需要,要求管理者运用大数据管理以更为科学的手段对企

元数据的构成方式

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

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

数据库管理系统的设计与实现

数据库管理系统的设计与实现 1.DBMS的目标 (1)用户界面友好对一个实用DBMS来说,用户界面的质量直接影响其生命力。DBMS的用户接口应面向应用,采用适合最终用户的交互式、表格式、菜单式、窗口式等界面形式,以方便使用和保持灵活性。一般地说,用户界面应具有可靠性、简单性、灵活性和立即反馈等特性。 (2)功能完备DBMS功能随系统的规模的大小而异。大型DBMS功能齐全,小型DBMS功能弱一些。DBMS主要功能包括数据定义、数据库数据存取、事务控制、数据库组织和存储管理、数据库安全保护等等。我们在下面讨论这些功能的内容。 (3)效率高系统效率包括三个方面:一是计算机系统内部资源的使用效率。能充分利用资源(包括存储空间、设备、CPU等),并注意使各种资源负载均衡以提高整个系统的效率,二是DBMS本身的运行效率。三是用户的生产率。这是指用户学习、使用DBMS和在DBMS基础上开发的应用系统的效率。 2.DBMS的基本功能 (1)数据库定义对数据库的结构进行描述,包括外模式、模式、内模式的定义;数据库完整性的定义;安全保密定义(如用户口令、级别、存取权限);存取路径(如索引)的定义。这些定义存储在数据

字典(亦称为系统目录)中,是DBMS运行的基本依据。为此,提供数据定义语言DDL。 (2)数据存取提供用户对数据的操纵功能,实现对数据库数据的检索、插入、修改和删除。一个好的DBMS应该提供功能强易学易用的数据操纵语言(DML)、方便的操作方式和较高的数据存取效率。DML有两类:一类是宿主型语言,一类是自含型语言。前者的语句不能独立使用而必须嵌入某种主语言,如C语言、COBOL语言中使用。而后者可以独立使用,通常以供终端用户交互使用和批处理方式两种形式使用。 (3)数据库运行管理这是指DBMS运行控制、管理功能。包括多用户环境下的并发控制、安全性检查和存取权限控制、完整性检查和执行、数据加密、运行日志的组织管理、事务的管理和自动恢复(保证事务的正确性),这些功能保证了数据库系统的正常运行。 (4)数据组织、存储和管理DBMS要分门别类地组织、存储各类数据,包括数据字典(亦称系统目录)、用户数据、存取路径等等。要确定以何种文件结构和存取方式在存储级上组织这些数据,如何实现数据之间的联系。数据组织和存储的基本目标是提高存储空间利用率,选择合适的存取方法确保较高存取(如随机查找、顺序查找、增、删、改)效率。 (5)数据库的建立和维护包括数据库的初始建立、数据的转换、数据库的转储和恢复、数据库的重组织和重构造以及有性能监测分析等功能。

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

明确仓库的对象:主题和元数据 大多数商务数据都是多维的,所以采集和表示三维以上的数据不能完全借用业务数据库设计中的方法,必须有一种新的方法来表达多维数据。现阶段流行的有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

数据库管理系统设计

1.1、功能特点 ?前台基本功能 进货管理:进行商品采购入库,采购退货,进/退单据和当前库存查询,与供货商的往来帐务。 销售管理:进行商品销售,顾客退货,销/退单据和当前库存查询,POS 销售统计,与客户的往来帐务。 库存管理:包括库存之间商品调拔,商品的报损溢,强大的库存盘点功能,库存商品报警查询。 统计报表:完整的统计查询功能,每张单据每次收款付款都可以清楚的反映。 日常管理:对供货商,客户,业务员综合管理,对日常收入支出管理,客户借货坏帐管理,合同管理。 基本设置:商品信息,商品调价,供货商,客户,员工,会员,仓库等基本参数的设置。 系统维护:数据库备份/恢复,系统初始化,操作员修改密码,年终结算,查看日志,打印条码,赠品管理。 ?后台基本功能 商品销售:进行商品的销售工作,用户可以通过输入商品的条码,编号来选择商品。 销售退货:进行已销售商品的顾客退货工作,同样可以通过商品条码和编号来选择商品。 打印设置:设置小票的标题和脚注以及要选择的打印机。 兑换赠品:有关会员用积分兑换赠品的管理工作。 赠送赠品:有关赠品的赠送管理工作。 修改密码:修改当前收银员的密码。 快捷键设置:设置 POS 中各功能的快捷键。 出入款管理:管理有关收银员的出入款工作。 1.2、系统要求 1、计算机硬件在586等级以上. 2、软件要求操作系统为中文WIN98,WIN2000,WINXP.WIN2003 3、装有microsoft数据库驱动程序 4、屏幕分辨率800X600以上.

二、快速入门

后台主界面及功能说明: 图1 2.1、基本设置:在基本设置中可以对商品信息、商品调价、供货商、客户、员工、操作员、会员、仓库进行设置 2.1.1、商品信息 在基本设置模块中点击“商品信息”进入商品信息界面如图2

企业元数据管理方案设计

企业元数据管理方案设计

一、背景 大数据挑战 大数据时代,饿了么面临数据管理、数据使用、数据问题等多重挑战。具体可以参考下图: ?数据问题:多种执行、存储引擎,分钟、小时、天级的任务调度,怎样梳理数据的时间线变化? ?数据使用:任务、表、列、指标等数据,如何进行检索、复用、清理、热度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 元数据简介 元数据被定义为:描述数据的数据,对数据及信息资源的描述性信息。 元数据(Metadata)是描述其它数据的数据(data about other data),或者说是用于提供某种资源的有关信息的结构数据(structured data)。元数据是描述信息资源或数据等对象的数据,其使用目的在于:识别资源;评价资源;追踪资源在使用过程中的变化;实现简单高效地管理大量网络化数据;实现信息资源的有效发现、查找、一体化组织和对使用资源的有效管理。 元数据的基本特点主要有: 1、元数据一经建立,便可共享。元数据的结构和完整性依赖于信息资源的价值和使用环境;元数据的开发与利用环境往往是一个变化的分布式环境;任何一种格式都不可能完全满足不同团体的不同需要; 2、元数据首先是一种编码体系。元数据是用来描述数字化信息资源,特别是网络信息资源的编码体系,这导致了元数据和传统数据编码体系的根本区别;元数据的最为重要的特征和功能是为数字化信息资源建立一种机器可理解框架。 元数据体系构建了企业业务的逻辑框架和基本模型,从而决定了企业业务的功能特征、运行模式和系统运行的总体性能。企业业务的运作都基于元数据来实现。其主要作用有:描述功能、整合功能、控制功能和代理功能。 由于元数据也是数据,因此可以用类似数据的方法在数据库中进行存储和获取。如果提供数据元的组织同时提供描述数据元的元数据,将会使数据元的使用变得准确而高效。用户在使用数据时可以首先查看其元数据以便能够获取自己所需的信息。

在数据仓库领域中,元数据按用途分成技术元数据和业务元数据。首先,元数据能提供基于用户的信息,如记录数据项的业务描述信息的元数据能帮助用户使用数据。其次,元数据能支持系统对数据的管理和维护,如关于数据项存储方法的元数据能支持系统以最有效的方式访问数据。具体来说,在数据仓库系统中,元数据机制主要支持以下五类系统管理功能: (1)描述哪些数据在数据仓库中; (2)定义要进入数据仓库中的数据和从数据仓库中产生的数据; (3)记录根据业务事件发生而随之进行的数据抽取工作时间安排; (4)记录并检测系统数据一致性的要求和执行情况; (5)衡量数据质量。 1.2 元数据管理平台体系结构 图1 元数据管理平台体系结构 关键特性

元数据管理方案

元数据管理方案 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、需求分析 (2) 1.1 信息要求: (2) 1.2 处理要求: (2) 1.3 安全性与完整性要求: (2) 1.4 系统功能的设计和划分 (2) 第一部分:用户管理部分 (3) 第二部分:管理员管理部分 (3) 2、概念设计 (3) 2.1概念模型(E-R图): (3) 2.2数据字典: (5) a.数据项 (5) b、数据结构 (5) c、数据流 (5) d、数据存储 (6) e、处理过程 (6) 2.3 数据流图 (7) 3、逻辑结构设计 (7) 3.1 E-R图向关系模型的转换(关系的码用下横线表出) (7) 3.2 设计用户子模式 (8) 4、物理设计 (8) 4.1 选择存取方法 (8) 4.2 确定数据库的存储结构 (8) 4.3 评价物理结构 (9) 5、系统实施 (9) 6、运行维护 (10)

1、需求分析 1.1 信息要求: 教务管理系统涉及的实体有: ●教师——工作证号、姓名、职称、电话等; ●学生——学号、姓名、性别、出生年月等; ●班级——班号、最低总学分等; ●系——系代号、系名和系办公室电话等; ●课程——课序号、课名、学分、上课时间及名额等。 这些实体之间的联系如下: ●每个学生都属于一个班,每个班都属于一个系,每个教师也都属于一个系。 ●每个班的班主任都由一名教师担任。 ●一名教师可以教多门课,一门课可以有几位主讲老师,但不同老师讲的同一门课其课序号是不同 的(课序号是唯一的)。 ●一名同学可以选多门课,一门课可被若干同学选中。 ●一名同学选中的课若已学完,应该记录有相应成绩。 ●本单位学生、教师都有重名,工作证号、学号可以作为标识。 1.2 处理要求: 教学系统主要提供数据维护、选课和信息查询。其中常见的查询有:系统中各对象的基本信息查询。查询指定班、系的学生信息(名单、人数等)。查询学生的成绩、学分情况。查询教师授课情况和学生选课情况……。 1.3 安全性与完整性要求: ●安全性要求: 1.系统应设置访问用户的标识以鉴别是否是合法用户,并要求合法用户设置其密码,保证用户身份不被盗用; 2.系统应对不同的数据设置不同的访问级别,限制访问用户可查询和处理数据的类别和内容; 3.系统应对不同用户设置不同的权限,区分不同的用户,如学生,教师,系统管理员。 ●完整性要求: 1.各种信息记录的完整性,关键信息记录内容不能为空; 2.各种数据间相互的联系的正确性; 3.相同的数据在不同记录中的一致性。 1.4 系统功能的设计和划分 根据如上得到的用户需求,我们将本系统按照所完成的功能分成以下几部分:

元数据管理

1.前言 数据仓库中的数据是从许多业务处理系统中抽取、转换而来,对于这样一个复杂的企业数据环境,如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。元数据是关于数据、操纵数据的进程和应用程序的结构和意义的描述信息,其主要目标是提供数据资源的全面指南。元数据不仅定义了数据仓库中数据的模式、来源以及抽取和转换规则等,而且整个数据仓库系统的运行都是基于元数据的,是元数据把数据仓库系统中的各个松散的组件联系起来,组成了一个有机的整体。2.元数据 2.1 元数据的概念 按照传统的定义,元数据(Metadata)是关于数据的数据。在数据仓库系统中,元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据;元数据是描述数据仓库内数据的结构和建立方法的数据,可将其按用途的不同分为两类:技术元数据(Technical Metadata)和业务元数据(Business Metadata)。 技术元数据是存储关于数据仓库系统技术细节的数据,是用于开发和管理数据仓库使用的数据。

业务元数据从业务角度描述了数据仓库中的数据,它提供了介于使用者和实际系统之间的语义层,使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息:使用者的业务术语所表达的数据模型、对象名和属性名;访问数据的原则和数据的来源;系统所提供的分析方法以及公式和报表的信息。 2.2 元数据的作用 在数据仓库系统中,元数据机制主要支持以下五类系统管理功能:(1)描述哪些数据在数据仓库中;(2)定义要进入数据仓库中的数据和从数据仓库中产生的数据;(3)记录根据业务事件发生而随之进行的数据抽取工作时间安排;(4)记录并检测系统数据一致性的要求和执行情况;(5)衡量数据质量。 与其说数据仓库是软件开发项目,还不如说是系统集成项目[1],因为它的主要工作是把所需的数据仓库工具集成在一起,完成数据的抽取、转换和加载,OLAP分析和数据挖掘等。 3.数据仓库元数据管理现状 元数据管理的主要任务有两个方面:一是负责存储和维护元数据库中的元数据;二是负责数据仓库建模工具、数据获取工具、前端工具等之间的消息传递,协调各模

元数据管理方案

元数据管理方案

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

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

仓库管理系统数据库设计

仓库管理系统数据库设计 1概述(设计题目与可行性分析) 1.1设计题目 设计一个仓库数据库管理系统,要求实现入库、出库、库存和采购等功能。 随着经济的飞速发展,,仓库管理变成了各大公司日益重要的内容。仓库管理过程的准确性和高效性至关重要。影响着公司的经济发展和管理。利用人工管理强大而数据烦琐的数据库显的效率过于低。利用计算机高效、准确的特点能够很好的满足公司的管理需要。提高公司各个员工的工作效率和公司的运做效率。利用计算机对仓库数据信息进行管理具有着手工管理所无法比拟的优点。目前一个现代化的仓库管理系统已经成为仓库管理不可缺少的管理手段。 1.2 可行性研究 可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。可行性研究的目的不是解决问题而是分析问题能不能解决;至少从下面三个方面分析可行性研究。 1.2.1技术可行性 该仓库数据库管理系统不不是很复杂,设计实现该数据库技术难度不是很大,利用目前现有的技术和工具能在规定的时间内做出该系统。该系统利用SQL2000和 visual studio 工具就能很好的实现该系统。 1.2.2经济可行性 当今世界是经济时代,一个公司的员工工作效率的高低直接影响着这个公司的发展。因此利用计算机进行信息管理有着无可比拟的好处,该系统相对较小,代码行较少,数据库设计不是很麻烦,开发周期较短。而且便于维护。但其带来的经济效益远远高于其开发成本。在经济上是可行的。 1.2.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)。 技术元数据是存储关于数据仓库系统技术细节的数据,是用于开发和管理数据仓库使用的数据,它主要包括以下信息: ●数据仓库结构的描述,包括仓库模式、视图、维、层次结构和导出数据的定义, 以及数据集市的位置和内容; ●业务系统、数据仓库和数据集市的体系结构和模式 ●汇总用的算法,包括度量和维定义算法,数据粒度、主题领域、聚集、汇总、 预定义的查询与报告; ●由操作环境到数据仓库环境的映射,包括源数据和它们的内容、数据分割、数 据提取、清理、转换规则和数据刷新规则、安全(用户授权和存取控制)。 业务元数据从业务角度描述了数据仓库中的数据,它提供了介于使用者和实际系统

人事信息管理系统后台数据库设计

《数据库管理系统》 课程设计报告 题目:人事信息管理系统的后台数据库设计 院(系):信息科学与工程学院 专业班级:计算机科学与技术****班 学生姓名:****** 学号:*********** 指导教师:陈颉 20 一三年 1 月 7 日至20 一三年 1 月一八日 华中科技大学武昌分校制

数据库管理系统课程设计任务书 一、设计(调查报告/论文)题目 人事信息管理系统的后台数据库设计 二、设计(调查报告/论文)主要内容 内容:完成人事信息的管理工作,实现各部门的信息化管理,满足员工与管理者的办公需求,例如员工查询信息、管理员修改信息等,要求设计并实现人事信息管理系统的后台数据库。 基本功能与要求: 1.在人事管理过程中,实现信息的自动化管理。 2.实现各种信息的修改、插入、删除功能(对管理员而言)。 3.实现对各种信息的查询、统计,支持模糊查询(对员工和管理员均可)。 4.按照年份月份统计某个员工的出勤情况。 5.按照某年某月某日统计查询某部门的迟到和早退人数。 6.按年统计各部门的调入调出人数信息。 分工任务:1 需求分析 2 数据库物理实现 3系统后台功能测试 三、原始资料 1.《数据库管理系统课程设计》指导书 2. 数据库系统设计课件 四、要求的设计(调查/论文)成果 1.课程设计报告 2.课程设计作品

五、进程安排 序号课程设计内容学时分配备注 1 选题、需求分析1天 2 数据库设计2天 3 数据库表及相关约束、视图实现2天 4 数据库的存储过程、触发器实现2天 5 数据库后台功能测试2天 6 验收答辩、撰写课程设计报告1天 合计10天 六、主要参考资料 [1] 顾兵.数据库技术与应用(SQL Server).北京:清华大学出版社,2010. [2] 马晓梅.SQL Server实验指导.第3版.北京:清华大学出版社,2009. [3] 范立南等.SQL Server 2005实用教程.北京:清华大学出版社,2009. [4] 李丹.SQL Server 2005数据库管理与开发.北京:机械工业出版社,2010. 指导教师(签名): 20 年月日

2018年系统元数据管理系统分析

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

数据仓库项目开发维护者: 1) 不同报表中的同一指标不一致,必须花费很大的精力去检查,目前基本上是通过手工检查表和存储过程的方式,效率较低。 2) 没有完善的开发、维护规范。比如,新增一张分析报表,开发人员根据业务人员的需求制作完成之后,往往没有整理完善相应的数据指标解释和元数据管理,造成日后检查困难。 3) 开发、维护规范的执行力较低,没有行之有效的管控手段。不严格按照规范执行,随着项目的发展和时间的推移,导致数据仓库项目的健壮性和可维护性呈几何级数下降,给数据仓库的建设带来大量的重复工作。 1.2 什么是元数据管理 元数据最本质,最抽象的定义为:data about data (关于数据的数据)。而对于经营分析数据仓库而言,形象的定义为:元数据就是数据仓库的规范。这些规范包括对各种指标的定义、解释;包括对各表中数据的来龙去脉、数据的大小和格式的定义。 元数据管理,就是要建立一套行之有效的规范以及该规范的管控体系,实现从管理到查询到综合分析的全面管控,管理层次从接口到ETL处理、业务逻辑处理、结果展现处理和指标分析的方方面面,构成数据仓库应用系统的核心和基础。做到开发者能严格遵守规范,维护者和使用者有规范可查,有力的保障数据仓库项目的健壮性和可维护性。

相关文档
最新文档