陈颖颖， 陈秉塬

(东北大学秦皇岛分校图书馆， 秦皇岛 066004)

电子资源(electronic resources，ER)，也称为电子信息资源、数字资源，具有规模大、数量多、类型丰富、可共享、便于检索与利用等优势，已经成为高校文献资源保障体系的重要组成部分，在图书馆服务依托中占重要作用，各大高校馆藏体系也逐渐向以电子资源馆藏为主的方向发展[1-2]。目前高校图书馆电子资源采购、揭示、利用等实际工作中，主要是以“数据库”作为主体。如何对电子资源进行有效管理成为高校图书馆馆藏资源管理的重要研究领域。对电子资源的管理研究主要集中在电子资源元数据描述、基于元数据的电子资源整合和基于元数据的电子资源共建共享等方面。在电子资源元数据描述规范方面研究较为成熟，已经产生许多针对具体电子资源和针对业务流程的元数据描述规范，例如针对网络资源描述的都柏林核心集(Dublin core，DC)规范，针对数字资源长期保存的《图书馆数字资源长期保存元数据规范》(WH/Z 1—2012)[3-4]；基于元数据的电子资源整合是元数据的具体应用之一，将异构的电子资源通过元数据映射、收割形成元数据仓库，进而实现电子资源的一站式检索和计量统计，如刘金玲[5]提出了基于DC元数据来整合各商业电子资源的图书馆联盟电子资源揭示系统的构想，随着第三代图书馆服务平台的兴起，元数据的整合甚至覆盖所有馆藏资源，最有代表性的FOLIO图书馆服务平台，以DC元数据为参考，设计了以Codex为核心的元数据管理方案[6]；基于元数据的共建共享研究集中在元数据如何实现在不同的系统间共享和跨机构维护，这是目前元数据领域研究的热点。欧洲图书馆共同体提出欧洲资源描述与检索(resource description and access,RDA)标准以改善各图书馆之间的互操作性，并致力于RDA的国际化推广[7]，萨拉曼卡大学的格雷多斯机构库项目，通过DC元数据构建满足开放存取需求的元数据收割协议(open archives initiative protocol for metadata harvesting，OAI-PMH)，向学术界和社会提供萨拉曼卡大学和其合作单位的电子资源[8]。而在图书馆界，越来越多的图书馆引入Alma 资源管理框架，支持MARC21、CNMARC、DC等多种元数据标准，把图书馆的各类资源，包括纸质资源、电子资源等纳入统一管理框架，并可实现用户间共建共享[9-10]。

作为高校图书馆采购、揭示、统计主体的电子资源数据库研究主要集中在数据库导航和数据库描述两个方面。目前学界普遍认为基于数据库的导航系统是提升电子资源利用率、优化图书馆服务体系的重要举措，陆雪梅[11]提出通过收集、整合、序化已购买或拥有的数据库、网络资源，形成数据库导航与学科导航两种主要的资源整合方式，为读者提供个性化和精准化服务；各高校图书馆对数据库的描述存在许多问题，杨小玲[12]通过调研财经教育资源共享联盟院校的数据库描述发现，各高校数据库在名称设计、标准规范、层级管理、文字表达等方面均存在问题。

基于以上分析，基于元数据的电子资源描述理论和共建共享应用已经较为成熟，为图书馆数据库元数据描述方法和共建共享提供实现路径。现拟在定义图书馆数据库的基础上，参考电子资源元数据描述和共享策略，利用元数据对图书馆数据库进行标准化描述，并搭建图书馆数据库元数据共享平台，以解决图书馆数据库定义不清、揭示各异、统计不规范、数据不完整等实际工作中存在的问题。该研究对于图书馆电子资源的揭示、统计、推广、整合和共享均有重要意义。

1 高校图书馆数据库定义

在全国高校图书馆数字资源采购联盟(Digital Resource Acquisition Alliance of Chinese Academic Libraries，DRAA)中，各高校采购的电子资源主要以数据库作为采购单位，如国际水协会(the International water association，IWA)数据库、科学引文索引扩展版(Web of Science-science Citation Index Expanded)数据库等；在各高校电子资源揭示中，也是以数据库作为揭示主体，如数据库导航系统中的数据库列表；在《高等学校图书馆数字资源计量指南(2007年)》对电子资源的计量中，除电子图书和电子期刊外，其他电子资源的计量均以数据库个数为计量单位。但很明显图书馆电子资源领域的数据库与计算机领域的数据库是完全不同的两个概念。现拟通过电子资源的概念，引申出图书馆数据库的概念。

DRAA采购联盟对电子资源的定义为：电子资源，通常指数字信息资源，即一切以数字形式生产和发行的信息资源，其信息包括文字、图片、声音、动态图像等，并以硬盘、磁带、光盘等介质及网络形式展现[13]。国际图书馆协会联合会(International Federation of Library Associations and Institutions，IFLA)在《电子资源馆藏发展的关键问题：图书馆指南》中也给出电子资源的分类包括各类数据库。结合电子资源定义和IFLA对电子资源的分类，把图书馆数据库定义为：在图书馆电子资源领域中，以相同或相近的电子资源组成的一个或多个集合称为数据库，并作为电子资源采购和揭示的主体，也可称为电子资源包或电子资源集。

2 高校图书馆数据库元数据描述模型

元数据是一种结构化数据，通过描述数据的属性，为数据揭示、数据共享提供基础。用元数据来定义和组织描述不同类别资源是一种非常简洁的数据结构化过程，在图书馆领域应用广泛，图书馆纸质资源和电子资源均有种类繁多的元数据规范，并在流通、共享、检索、统计等方面发挥重大作用。

2.1 高校图书馆数据库元数据描述的理论基础

对于电子资源元数据的描述规范使用最广泛的当属DC，DC元数据规范通过基本元数据元素集合来描述资源对象的语义信息，目前已成为IETF RFC2413、ISO15836、CEN/CWA13874、Z39.85等国际标准的基础[3]。在图书馆界，IFLA也对电子资源的描述和编目做出具体指导和应用规范。

从广义上看，图书馆“数据库”是一种特殊的网络资源，因此高校图书馆数据库元数据描述可参考电子资源元数据描述和网络资源元数据描述。现试图从实际应用需求出发，参考元数据描述方法，在DC核心合集、《高等学校图书馆数字资源计量指南(2007年)》统计选项和DRAA中的资源百科对电子资源的描述字段的基础上，结合工作需求，提出一种可满足统计、揭示、推荐、聚合需求的高校图书馆数据库元数据描述模型。

DC元数据定义了可扩展的15个核心元素集，通过修饰词和限定词全面概括了电子资源的主要特征。DRAA高校图书馆数字资源采购联盟的资源百科栏目中，对数据库的揭示主要包括数据库简介、数据库资源内容、提供的用户服务、组团情况、使用统计、永久使用及存档、许可协议以及其他等8个数据项，各数据项下有若干个子项，其中数据库资源内容下的总体收录情况挂接了2个扩展数据项。各高校图书馆在电子资源揭示中主要用到数据库名称、访问地址、学科类型、数据类型、收录年限、简介、使用帮助等字段。现基于以上理论基础和实际应用需求，设计高校图书馆数据库元数据描述模型。

2.2 高校图书馆数据库元数据描述模型

根据高校图书馆数据库元数据揭示需求，结合DC元素的语义，选取其中10个核心元素，作为高校图书馆数据库核心元数据集。结合统计、推广、评估需求，定义两个扩展元数据集：数据库电子资源明细元数据集用来存储数据库的电子资源明细；数据库附件元数据集用来存储数据库的帮助指南、宣传材料、培训信息、活动信息等。根据DC元素、修饰词和推荐编码体系，结合数据库元数据管理需求，制订高校图书馆数据库核心元数据集、高校图书馆数据库电子资源明细扩展元数据集和高校图书馆数据库附件扩展元数据集，各元数据集关系如图1所示，数据库元数据集明细如表1～表3所示。

图1 高校图书馆数据库元数据集关系Fig.1 Metadata set relationship of university library database

表1 高校图书馆数据库核心元数据集

表2 电子资源明细扩展元数据集

表3 数据库附件扩展元数据集

高校图书馆数据库元数据描述模型的设计初衷是为了实现基于元数据的共享和系统间的协作，进而提升高校图书馆数据库管理规范，解决数据库阅读推广、数据统计等业务的数据标准化问题。表1～表3给出了一个完整的高校图书馆数据库元数据描述模型，模型元素基本覆盖了数据库揭示、数据库阅读推广、电子资源计量统计所需字段。三个元数据模型的元素均符合DC元数据描述，易于与其他系统实现数据共享。通过主—从扩展模式设计，简化了每一个对象的元素集，便于实际操作和共享。

3 高校图书馆数据库元数据共享平台设计

3.1 数据库元数据共享平台框架设计

高校图书馆数据库元数据共享平台是高校图书馆数据库元数据共建共享的支撑平台，主要提供数据库元数据的聚合和数据库元数据的使用。数据库元数据的聚合是指各参与图书馆、各数据商根据高校图书馆数据库元数据模型，对数据库的元数据进行编目和维护，使共享平台尽可能多地聚合数据库元数据；数据库元数据的使用是指各高校图书馆通过应用程序编程接口(application programming interface, API)服务或平台直接查询，在电子资源揭示、使用、计量统计等工作中使用标准的数据库元数据。基于此，现依据模型-视图-控制器(model-view-controller,MVC)软件分层设计思想，设计高校图书馆数据库元数据共享平台的系统框架，如图2所示。

图2 高校图书馆数据库元数据共享平台系统框架Fig.2 System framework of university library database metadata sharing platform

整个共享平台由应用层、服务层和数据层组成。应用层由Web端和API端构成，Web端主要实现共建功能，即用户通过Web端实现元数据的编目、查询、导入导出元数据等功能，API端主要实现共享功能，即通过API接口服务为其他系统和平台提供访问接口；服务层将平台的各业务逻辑抽象为业务逻辑类库和模型扩展中间件，由服务接口和服务中间件组成，服务接口为平台的外部接口，主要完成元数据编目、前端模板、数据转换、共享接口等核心功能类库集合，服务中间件为平台的内部接口，主要完成系统辅助的单一特定功能；数据层由元数据存储的元数据仓库和文件存储的文件服务器组成。

3.2 数据库元数据共享平台功能模块设计

数据库元数据共享平台要满足各参与馆的元数据编目和元数据的共享需求，基于该需求和系统框架，设计如图3所示的功能模块。

图3 高校图书馆数据库元数据共享平台功能结构图Fig.3 Functional structure of university library database metadata sharing platform

(1)用户管理和权限管理模块。该模块实现各参与馆的账号注册、管理工作，平台管理员可以为每个账号设置元数据编目的增删改权限，并对各元数据的Web和API访问权限进行细粒度的设置。

(2)元数据模型管理和元数据管理模块。元数据模型管理模块实现元数据模型字段的增删改操作，即元数据模型可以根据实际需求进行平滑扩展变更。元数据管理模块主要实现元数据栏目的增删改操作和元数据的编目操作，同时利用元数据版本管理实现元数据编目可追溯。

(3)API接口管理模块。该模块主要实现各授权的API接口密钥和开放的API接口维护和数据维护，确保各参与馆能在安全可控环境下获取到真实有效的数据。

(4)消息管理模块。消息管理是元数据全流程管理的关键，如果元数据发生变更(如元数据发生了编辑、变更、删除等操作)，则消息管理负责根据元数据版本信息将消息推送给用户。

3.3 数据库元数据共享平台技术架构

共享平台基于B/S架构，协议为HTTP，系统开发语言为PHP7.4，开发框架为CodeIgniter3.1，数据库服务器为MySQL5.7，接口服务采用基于CI的RESTful Web Service扩展。系统具有开发成本低、跨平台、易于扩展等优点，且超文本预处理器(hypertext preprocessor,PHP)具有高效率的特点，较少的服务器资源就可满足系统的正常运行。

4 高校图书馆数据库元数据共享平台关键技术

数据库元数据共享平台业务逻辑清晰，功能复杂度不高，PHP+CI框架技术架构能较好完成开发任务，其中元数据的编目中的版本控制和基于CI的RESTful Web Service接口开发是本平台的重点和难点。

4.1 带有版本管理的元数据编目存储算法

常规的数据库创建-检索-更新-删除(create- retrieve -update-delete，CRUD)操作如图4所示。

图4 常规CRUD操作流程Fig.4 General CRUD operation process

在数据库元数据共享平台中，因采用Wiki式的多人协作创作模式，则元数据的CRUD操作必须考虑元数据的版本管理和管理员版本审核，以利于后期使用时可追溯历史数据，因此需设计一种带有版本管理的元数据编目存储算法。

带有版本管理的元数据编目存储算法实现方法为：在元数据模型中新增关联(relation)字段和删除(IsDel)字段，超级用户的CRUD操作与常规操作流程一致，普通用户在插入一条新的编目数据时，初始化relation为1，代表版本1，IsDel为0，代表未删除，并记录操作日志；该条数据第n次编辑时(n>1)，获取n-1条记录的relation，利用回调函数插入一条新记录，并设relation为n，代表版本n，并记录操作日志，依此形成一条元数据编目数据的1～n的历史数据；查询一条编目数据时，先按title进行group by分组，然后再按relation DESC倒序排序，并获取每个分组的最新的一条记录，同时根据操作日志给出版本索引；删除一条编目数据时只是将IsDel字段更新为1，并记录操作日志。普通用户的CRUD具体流程如图5所示。

图5 带有版本管理的CRUD操作流程Fig.5 CRUD operation process with version management

4.2 基于CI框架的元数据共享RESTful Web Service接口设计

元数据共享有效途径就是规范的接口，用户和客户端通过授权访问接口即可共享规范的元数据。

目前Web接口规范主流技术有Web Service和RESTful Web Service，二者区别在于：① Web Service开发面向方法，而RESTful Web Service面向资源；②Web Service通过SOAP封装方法信息，而RESTful Web Service直接通过HTTP协议进行传输，利于GET缓存；③从安全性考虑，因Web Service采用SOAP封装了方法，不具备安全控制条件，而RESTful Web Service可通过URL和请求方法来实施安全控制策略；④从客户端角度考虑，Web Service要求客户端必须支持SOAP协议，而RESTful Web Service只需客户端满足HTTP协议。

在元数据共享平台中，考虑到用户使用元数据共享的场景大都为基于Web的系统集成，为降低用户端的开发成本，提高共享简易度，其接口技术采用RESTful Web Service接口技术，服务器屏蔽“Post、Put、Delete”等关键词，只保留Get关键词，确保平台数据安全。接口的UML实现类图如图6所示。

图6 RESTful Web Service接口UML类图Fig.6 UML class diagram of RESTful Web Service interface

在元数据共享平台的接口设计中，采用CodeIgniter(CI)框架开发RESTful Web Service接口，主要原因有：CI的MVC架构适合进行RESTful Web Service接口开发，其中控制器处理客户端的请求并返回内容，模型进行增删改查操作，视图用来处理资源的表现格式；接口实现重用Web端的业务逻辑，接口只需要识别用户请求，并调用Web端的业务逻辑完成资源抽取，所有的安全控制由Web端的业务逻辑完成。

在客户端请求资源的多格式支持上，根据REST服务规范，通过在客户端添加头部(header)信息"Accept: application/(xml/pdf/vcard/json)"来指定返回数据的格式，服务端接口根据header信息转换资源数据，以全面支持不同的客户端请求。

5 高校图书馆数据库元数据共享平台系统测试

5.1 Web端功能测试

在Web端主要实现了数据库元数据共享平台的元数据编目以及配套的用户管理、权限设置、元数据模型设计等功能，因篇幅所限，这里仅展示元数据类型管理、元数据编目管理、元数据API接口授权管理等核心功能，如图7～图9所示。

5.2 API端功能测试

API端功能测试采用客户端curl命令，构建接口查询语句，并返回所需结果。以请求“id=1的数据库元数据详情、并以json作为返回数据”为例，其请求命令为：

$ curl -H "Accept: application/json" -X GET http://localhost/index.php/httpapi/detail/1

其中，-H "Accept: application/json"代表返回的资源结果为json格式(平台支持xml、pdf、csv、json格式)，-X GET指定HTTP动词为GET，后面的url代表资源的访问地址。返回结果如下：

HTTP/1.1 200 OK

Status: 200

Content-Type: application/json

{"1":{"id":1,"title":"Wiley Online Library Journals ","description":"Wiley Online Library是一个新的综合性的网络出版及服务平台",},……}。

5.3 平台性能测试

(1)单页响应时间。通过访问平台Web端的42个页面，利用CI框架的调试工具记录页面的响应时间，并计算各页面平均响应时间，如表4所示。

单页响应时间排除网络传输因素，只表征程序自身的性能。通过表4统计可以看出，平台的单页平均响应时间为107.08 ms，界面的响应迅速，几乎没有等待感，满足使用需求，从单页的时序上看，页面的响应时间主要在控制器上，原因是系统的业务逻辑依赖CI框架，需要消耗一部分资源；模型层响应时间最短，说明平台的数据结构合理，查询次数较少，且数据库响应速度较快。

图7 元数据类型管理界面Fig.7 Metadata type management interface

图8 元数据接口授权管理界面Fig.8 Metadata interface authorization management interface

图9 元数据编目管理界面Fig.9 Metadata catalog management interface

(2)平台压力测试。平台选用阿里云的2核CPU/4G内存/5 M带宽的云服务器，并安装LNMP服务器软件，选用Apache JMeter为压力测试工具，设置线程数为20，循环次数为50次，对首页请求、列表页请求、详情页请求、HTTPAPI请求和编目页编辑等功能进行压力测试，测试结果如表5所示。

在测试服务器的配置和带宽条件下，其平均响应时间为580 ms，最小值为172 ms，最大值为2 400 ms，

表4 单页响应时间统计表

表5 平台压力测试统计表

无异常响应，平均吞吐量为12.04次/s，且在编目页编辑和HTTPAPI请求等核心功能的吞吐量达到15.25次/s，说明平台对服务器资源要求较低，可以满足图书馆区域性协作共享需求。

6 结论

数据库的管理是图书馆电子资源管理的重要内容，现提出一种简单的数据库元数据描述模型，并通过MVC设计模式设计并实现了一个数据库元数据共享支撑平台，该项工作将大大提升数据库元数据管理水平，对图书馆电子资源揭示、阅读推广、学科文献保障评估、计量统计等工作起到重要的促进作用。同时通过元数据描述和数据库元数据共享平台，将极大改善各高校图书馆对免费数据库和OA数据库的利用，丰富各高校图书馆对教学科研的文献支撑。