数据库技术论文合集12篇

时间:2023-02-11 22:33:56

数据库技术论文

数据库技术论文篇1

二、计算机数据库在信息管理中的应用现状

就目前技术的发展结构而言,在计算机数据库技术实际运行过程中,整体技术维度和技术运行机制也在发生改变。第一,计算机数据库技术的应用范围在逐渐扩展。在实际生产生活中,应用计算机数据库技术的频率和市场前景越来越大,无论是工业、农业以及文化产业等,都将其视为有效的信息处理工具[2]。因此,计算机数据库技术的安全性和适配性尤为重要,各行业也在自身发展进程中不断摸索和技术优化,真正建立切实有效的管控模型和管理机制,确保管理维度的实效性,也为信息结构优化奠定坚实基础[3]。第二,计算机数据库技术的安全性也在探索中逐渐得到强化,也突显出计算机数据管理项目的具体要求,只有优化其安全价值,才能更好的建构高度机密性以及敏感性数据管理维度,保证了信息备份管理以及恢复功能的有效性,对于数据信息的复制和备份,要在优化信息维度的基础上,真正实现了数据库的安全性升级。

三、计算机数据库技术在信息管理中的应用优化路径

(一)优化计算机数据库技术在信息管理中的安全性

要保证数据完整性,就要从安全应用以及安全管控模型出发,建构系统化管理维度和管控要求,保证数据在得到共享的同时,相应的数据信息也是安全准确的。因此,技术人员要结合计算机数据库技术的相关要求,提升信息完整度和安全性[4]。

(二)优化计算机数据库技术在信息管理中的实践性

在实际信息管理和信息控制过程中,要积极落实理论和实践的融合机制,确保管理维度和管理效果的最优化。伴随着计算机技术的高速发展,将数据库原理和数据库管理技术模型进行深度管控,是提升数据科学性以及合理性的重要路径,也是研究数据分析机制以及计算机数据库技术应用模型的重要参数,因此,要保证理论联系实践,建构计算机数据库技术应用整体。

(三)优化计算机数据库技术在信息管理中的技术性

对于计算机数据库技术来说,最基本的就是技术参数,因此,要保证计算机数据库技术在信息管理中得到推广,最基本的就是要保证技术模型的安全性和准确性,并且积极落实计算机共享体系。计算机数据库技术最根本的要求就是要规避数据库被非法入侵,确保其技术安全和信息共享安全。但是,在实际管理机制中,信息的绝对安全存在风险。提升计算机数据库技术的技术安全性,能更好的落实信息应用价值,确保信息维度得到有效优化。因此,相关项目技术人员要利用加密技术对非共享信息进行系统化管控,提高管控效果的同时,积极落实技术性管理要求,借助权限管理机制、数据加密技术以及强制存取控制技术等措施,进一步优化计算机数据库技术的技术安全性[5]。

四、结束语

总而言之,在信息管理过程中积极应用计算机数据库技术,能在满足共享需求的基础上,充分发挥信息的实用性价值,确保信息得到充分利用,也为实践优化提供动力,确保技术模型以及信息管理维度之间形成有效的控制机制,也为数据应用研究奠定坚实基础,保证计算机数据库技术和信息管理之间的优化契合。

作者:陈文杰 单位:

参考文献:

[1]王瑜.探究计算机数据库安全管理与实现途径[J].建筑工程技术与设计,2016,15(11):2074-2074.

[2]温林芝.试析计算机数据库安全管理技术与方法[J].数字技术与应用,2015,15(04):183-183.

数据库技术论文篇2

引言

近年来,网络技术得到迅速的发展,这就为信息资源的共享提供了技术上的可能.作为信息密集型的地理信息系统(GIS)上升到网络平台可谓适逢其时.但从目前的应用情况来看,除了国外极少的公司拥有网络版的GIS之外,在国内还处于试验研制的阶段.因此,尽快地研制出我国自主版权的网络GIS的原型和产品,并在技术手段上达到国际先进水平,是摆在我们面前的一项迫切的任务.

1网络计算的几种模式及特点

(1)传统的集中式.这是一种主机-终端模式,所有的计算任务和数据管理任务都集中在主机上,终端只是主机输入/输出设备的延长.这种模式的优点是容易管理,缺点是对主机的性能要求很高,也浪费了作为终端的计算机的计算能力,并且从性能价格比来看,在购置费用相当的情况下,一台主机的性能往往比不上几台计算机所组成网络的性能;因此这种模式已逐渐退出主流.

(2)客户机/服务器(client/server,简称C/S)模式.一般说来,在这种模式下,服务器只集中管理数据,而计算任务分散在客户机上,客户机和服务器之间通过网络协议来进行通讯.客户机向服务器发出数据请求,服务器将数据传送给客户机进行计算,计算完毕,计算结果可返回给服务器.这种模式的优点充分利用了客户机的性能,使计算能力大大提高;另外,由于客户机和服务器之间的通讯是通过网络协议进行的,是一种逻辑的联系,因此物理上在客户机和服务器两端是易于扩充的.它是目前占主流的网络计算模式.

(3)浏览器/服务器(browser/server)模式.在这种模式下,用户端只需一通用的浏览器,如Netscape或Explore,便代替了形形的各种应用软件.服务器则为Web服务器.浏览器和服务器之间通过TCP/IP这一通讯协议进行连接.浏览器发出数据请求,由Web服务器向后台取出数据并计算,将计算结果返回给浏览器.这种模式的优点是:由于用户端所用软件只是一个简单的浏览器,用户基本上无需培训,用户端软件也无需维护;软件的升级与修改只在服务器端进行,对用户透明;服务器与浏览器可处于不同的操作系统平台.其缺点为:Web动态技术不够成熟,各种标准有待统一,如各厂家的动态协议互不支持、浏览器之争等.总之,它是一种先进的但发展还未成熟的技术.

基于以上的分析,应选择客户机/服务器模式作为GIS访问网络数据库的实现模式.

2C/S模式下的GIS访问网络数据库的结构设计

设计在总体上分为C/S两层(见图1),以充分利用C/S模式的跨平台、易扩充、数据独立等优点.在client端又分两层来进行设计——GIS功能层和数据请求层,GIS功能层是GIS的功能实现部分,数据请求层是GIS的数据实现部分.数据请求层作为一中间层,起到数据转换的作用,对上是具有GIS特点的数据文件,对下是标准的数据库记录.这种分层设计的形式一方面充分利用了现有的单机版本GIS研究成果;另一方面,GIS功能层和数据请求层的开发可同时进行,只要接口标准不变,本层的变动不会影响到另一层.

Fig.1ThegeneralframeworkofGISaccessingdatabasebasedonC/Smodel

值得一提的是ESRI公司的空间数据库引擎(spatialdatabaseengine,简称SDE)的设计方案(见图2).它是目前国际上领先的GIS数据处理的网络计算模型.其数据的访问形式为:由用户的应用程序(userapplication)通过SDE应用编程接口(SDEAPI)向SDE服务器提出空间数据请求,SDE服务器内存放有空间对象模型,并依据空间对象的特点在本地完成空间数据的搜索,并将搜索结果通过网络向用户的应用程序返回.

对比图1和图2可以看出两者采用的都是C/S模式,并且都将GIS功能实现与数据请求进行分层处理;所不同的是面向数据库的数据请求实现的位置:图1在客户机端实现,图2在服务器端实现.在服务器端实现的主要优点为:(1)对于空间对象模型及相关的计算模式的升级可以只在服务器端实现,而且对客户机端透明;(2)由于SDE服务器与数据库ORACLE7.2的结合非常紧密,因此数据的搜寻速度非常快.对于图1来说,把数据请求层放在客户机端,对数据库的依赖程度就不同于SDE服务器,后者对数据库的选型有极强的依赖性(目前SDE服务器只在ORACLE7.2实现),相反,它是一种非常开放的结构,它所支持的服务器不但可跨数据库系统平台,而且还可跨操作系统平台.可以说,图1和图2两种设计模式的优缺点是相互对应的.

3数据库访问方式的比较

基于程序的访问数据库的几种方法如下.

(1)专用的数据库访问工具.如PowerBuilder,Delphi等,它偏向于对数据库中数据的管理和显示,具有限的计算功能.既不适于用它来开发GIS应用系统,也难以将它们的数据操纵功能与现有的GIS应用系统紧密结合.

(2)嵌入数据库语言的常规语言.各数据库厂家为了让用户程序能直接访问自已的数据库,基本上都提供了专有的面向C语言的预编译头和静态库,如Sybase公司的OPENCLIENT和ORACLE的PRO*C.

(3)开放数据库互连性应用编程接口(opendatabaseconnectivityapplicationprogramminginterface,简称ODBCAPI)[2,3].它是微软(Microsoft)公司提出的数据库访问形式.它通过确保所有的应用系统遵循标准的调用层接口,提供对特定数据源命令进行解释的驱动程序来保持应用系统的互用性.这样的应用系统是开放的,只要有相应数据源的ODBC的驱动,它就无需改变代码而可访问相应的数据库.

在确定访问数据库的方式时,ODBCAPI的开放性的优势是不言而喻的,但这种方式在效率上不如第二种访问形式.应说明的是:ODBCSQL语法分为3层,即最小层、核心层和扩展层,尽管目前的大型数据库都能支持到扩展层,但为了保证应用系统的开放性,在具体编程实现时,尽量只使用最小层和核心层的语法.

4某电信局配线系统的实现

客户机为MAPGIS/ODBC/WINDOWS95,服务器为SQLSERVER/WINDOWSNT,要访问的相关表中记录约为13万条.要求从地理底图上选中某一DP,在数据库中寻找出从这一DP到配线架的可用通路,并在数据库中作相应配线修改.如图3所示.结果表明:(1)程序实现了MAPGIS访问网络数据库的功能;(2)客户机和服务器均为PC机(主频166MHz),每次操作反应时间为数秒,换机观察,发现服务器的性能是整个网络计算的瓶颈.

5结论

(1)C/S模式为目前网络平台GIS的首选,将GIS功能与数据库访问分层实现有利于保护现有的开发成果;(2)将数据请求层放在客户端和以ODBC作为数据库的访问方式保证了应用系统的开放性,其访问可跨越数据系统和操作系统平台;(3)实例表明,应用系统的反应速度更多取决于服务器的性能,而不是ODBC的效率.

参考文献

数据库技术论文篇3

[关键词]SCI;学术影响力;引文分析

[中图分类号]G250.74[文献标志码]A

[文章编号]1005-6041(2012)04-0017-004

SCI(Science Citation Index)是由美国科学信息研究所(ISI)1961年创办出版的引文数据库,是世界著名的三大科技文献检索系统之一,也是国际公认的进行科学统计与科学评价的主要检索工具。国际上的科学计量机构及国际性组织在对国家或科研机构的科研能力及绩效评估工作中,常用SCIE(SCI-EXP ANDED,即SCI网络版)数据库作为依据[1]。本文利用检索式Address =(guangxi or nanning or guilin or liuzhou or yulin or hechi or baise or beihai or qinzhou or wuzhou)在美国科学信息研究所SCI网络版(SCI-EXPANDED)数据库中进行机构(Institutions)精炼检索,并对作为广西重要科研机构的10大高校近10年(2001—2011)来科技论文产出和学术影响力进行统计分析。

1 科技论文产出数量与增长趋势

从检索结果 (检索日期为2012年4月18日)统计来看,10年来,广西10所高校共有6 563篇论文被SCI收录,其中专业期刊研究论文6 295篇,约占96%,会议论文230篇,综述94篇,发文量排名见表1。10年来从科技论文产出数量来看,广西高校科技研究事业发展迅速,论文产出量呈逐年递增趋势(见图1)。科技论文产出量10年同比增长率为115%。近年来,我国科技事业发展迅猛,论文产出量逐年增加,作为重要科研机构的高校增长率更高。广西高校的科技论文产出的增长速度高于全国平均增长水平,但与全国高校(以中南六省为例)同水平相比,广西高校科研论文产出仍相对薄弱(见表2)。

2 学科分布和热点论文

通过SCI数据库对广西高校的科技论文检索结

[CM(81mm]果分析显示,化学、物理、材料科学等学科领域研究

[CM)]比较活跃,论文数量约占总数的一半(见表3),其他较活跃的领域有数学、结晶学、生物分子科学、工程技术、计算机科学、航空科学等。统计结果显示,广西师范大学物理、化学等基础研究学科比较活跃。广西大学是一所综合性教学研究型大学,在各学科领域研究占比重较大,尤其是在生物科学和材料科学等领域。桂林理工大学和广西民族大学的科学研究也初见繁荣。来源出版物是研究人员的研究基地,来源出版物在学科专业领域的地位从一定程度上反映研究人员的研究水平,其中化学学科研究主要来源出版物2010年影响因子分别为2134和0798(期刊影响因子来自JCR,国外来源出版物中文名称来源于谷歌学术搜索)。从主要来源出版物来看,在国内专业刊物上发表占比例较大,国外高影响因子的刊物较少。这从一定程度上反映广西高校科技专业研究水平与层次上还应进一步加强国际合作,从而提高学术影响力。

3 科技合作与学术影响力

学术交流与合作是学术影响力的重要体现,从论文检索结果分析来看,广西高校科技论文研究的主要科研合作伙伴遍布全球50个国家和地区,与美国、俄罗斯、日本等国家合作比较频繁,其中与美国合作研究502次,与俄罗斯合作达148次。学术影响力还可以从引用机构来说明[2],通过分析施引文献可以发现,广西高校科学研究10年来受到110个国家和地区的科研人员关注,美国、德国和日本引用约占国外引用的一半,美国引用达2 728次,占国外总引用的35%。从不同级别的基金资助机构资助来看,广西高校10年来共有1 243篇论文由国家自然科学基金资助,约占19%,高于国家自然科学基金国内资助率15%, 各学科内国家自然科学基金资助率也明显高于国内平均水平(见表4)。这说明广西高校科技发展学科水平与国内同水平相比发展迅速,国家支持力度较高。

4 科技论文的引用情况和学术影响力

论文的引用情况是衡量一个机构的学术影响力的重要标准[3],为此,对10年来广西高校SCI收录6 563篇论文的引用情况进行统计分析,可以看出近年来被引用情况呈逐年活跃趋势(如图4)。广西高校10年来的研究论文被引频次总计达24 793次(去除自引,被引次数检索截止日期为2012年4月19日),去除自引的施引文献共计19 736篇,每篇平均引用次数为 465次,H指数为54,即有 54 篇论文至少被引用 54 次。通过对19 736篇施引文献进行分析,在引文的学科范围中,化学、物理、材料科学为引用最活跃的学科范围(表4),这与论文产出的学科范围基本一致,引用机构比较活跃的主要有中科院、南京大学、中山大学、北京大学等,引用的国家多达100多个,其中美国、德国、日本的引用约占国外引用的一半,引用中他引率比较高,但单篇被引的最高值与同学科国内引用水平相比仍然存在较大差距(被引次数检索截止日期为2012年4月19日)。

5 小 结

广西近10年来科研活动发展迅速,学术影响力逐年上升,从科技合作发展及基金资助机构层次来看学科发展水平与国内保持一致,但与国内同水平高校相比论文产出相对较薄弱,在论文被关注即引用率和主要来源出版物的层次上仍略显薄弱,科研机构与部门应该加大投入,提高科研产出,鼓励加强部级基金资助项目申报,并投入配套设施,加大研

究人员的研究动力,并加强科研规范管理,从而加快广西科技事业发展。

[参考文献]

[1] 邓秀林基于引文分析法的期刊栏目的学术影响力评价[J] 现代情报,2007(5)154—155 

[2] 查永军学术影响力大学学术权力张扬的内在力量[J] 江苏高教,2007(6)16—18

[3] 周 薇,张 燕,韦 焘 基于SCIE的我国肝胆外科学术影响力分析[J] 中华医学图书情报杂志,2011(1)70—12 

[4] 徐云清,甘朝鹏,姚玮华,等 河南省高校CSSCI论文的产出与学术影响力的比较研究[J] 河南工业大学学报(社会科学版),2009(4)72—74

[5] 雷 燕《科学引文索文》(SCI)数据库的检索技巧[J] 情报科学,1999(1)75—77

[6]方红玲 2007~2009年SCI数据库收录中、日、印、韩四国科技期刊自引率比较研究[J] 中国科技期刊研究,2011(3)360—363

[7]SCI科学引文数据库[DBOL].[2012-04-19] httpwwwwebofknowledgecom.

数据库技术论文篇4

关键词地理信息系统,数据库访问,空间数据库引擎(SDE),C/S模式,ODBC.

引言

近年来,网络技术得到迅速的发展,这就为信息资源的共享提供了技术上的可能.作为信息密集型的地理信息系统(GIS)上升到网络平台可谓适逢其时.但从目前的应用情况来看,除了国外极少的公司拥有网络版的GIS之外,在国内还处于试验研制的阶段.因此,尽快地研制出我国自主版权的网络GIS的原型和产品,并在技术手段上达到国际先进水平,是摆在我们面前的一项迫切的任务.

1网络计算的几种模式及特点

(1)传统的集中式.这是一种主机-终端模式,所有的计算任务和数据管理任务都集中在主机上,终端只是主机输入/输出设备的延长.这种模式的优点是容易管理,缺点是对主机的性能要求很高,也浪费了作为终端的计算机的计算能力,并且从性能价格比来看,在购置费用相当的情况下,一台主机的性能往往比不上几台计算机所组成网络的性能;因此这种模式已逐渐退出主流.字串5

(2)客户机/服务器(client/server,简称C/S)模式.一般说来,在这种模式下,服务器只集中管理数据,而计算任务分散在客户机上,客户机和服务器之间通过网络协议来进行通讯.客户机向服务器发出数据请求,服务器将数据传送给客户机进行计算,计算完毕,计算结果可返回给服务器.这种模式的优点充分利用了客户机的性能,使计算能力大大提高;另外,由于客户机和服务器之间的通讯是通过网络协议进行的,是一种逻辑的联系,因此物理上在客户机和服务器两端是易于扩充的.它是目前占主流的网络计算模式.

(3)浏览器/服务器(browser/server)模式.在这种模式下,用户端只需一通用的浏览器,如Netscape或Explore,便代替了形形的各种应用软件.服务器则为Web服务器.浏览器和服务器之间通过TCP/IP这一通讯协议进行连接.浏览器发出数据请求,由Web服务器向后台取出数据并计算,将计算结果返回给浏览器.这种模式的优点是:由于用户端所用软件只是一个简单的浏览器,用户基本上无需培训,用户端软件也无需维护;软件的升级与修改只在服务器端进行,对用户透明;服务器与浏览器可处于不同的操作系统平台.其缺点为:Web动态技术不够成熟,各种标准有待统一,如各厂家的动态协议互不支持、浏览器之争等.总之,它是一种先进的但发展还未成熟的技术.字串4

基于以上的分析,应选择客户机/服务器模式作为GIS访问网络数据库的实现模式.

2C/S模式下的GIS访问网络数据库的结构设计

设计在总体上分为C/S两层(见图1),以充分利用C/S模式的跨平台、易扩充、数据独立等优点.在client端又分两层来进行设计——GIS功能层和数据请求层,GIS功能层是GIS的功能实现部分,数据请求层是GIS的数据实现部分.数据请求层作为一中间层,起到数据转换的作用,对上是具有GIS特点的数据文件,对下是标准的数据库记录.这种分层设计的形式一方面充分利用了现有的单机版本GIS研究成果;另一方面,GIS功能层和数据请求层的开发可同时进行,只要接口标准不变,本层的变动不会影响到另一层.

Fig.1ThegeneralframeworkofGISaccessingdatabasebasedonC/Smodel

值得一提的是ESRI公司的空间数据库引擎(spatialdatabaseengine,简称SDE)的设计方案(见图2).它是目前国际上领先的GIS数据处理的网络计算模型.其数据的访问形式为:由用户的应用程序(userapplication)通过SDE应用编程接口(SDEAPI)向SDE服务器提出空间数据请求,SDE服务器内存放有空间对象模型,并依据空间对象的特点在本地完成空间数据的搜索,并将搜索结果通过网络向用户的应用程序返回.字串2

对比图1和图2可以看出两者采用的都是C/S模式,并且都将GIS功能实现与数据请求进行分层处理;所不同的是面向数据库的数据请求实现的位置:图1

在客户机端实现,图2在服务器端实现.在服务器端实现的主要优点为:(1)对于空间对象模型及相关的计算模式的升级可以只在服务器端实现,而且对客户机端透明;(2)由于SDE服务器与数据库ORACLE7.2的结合非常紧密,因此数据的搜寻速度非常快.对于图1来说,把数据请求层放在客户机端,对数据库的依赖程度就不同于SDE服务器,后者对数据库的选型有极强的依赖性(目前SDE服务器只在ORACLE7.2实现),相反,它是一种非常开放的结构,它所支持的服务器不但可跨数据库系统平台,而且还可跨操作系统平台.可以说,图1和图2两种设计模式的优缺点是相互对应的.

3数据库访问方式的比较

基于程序的访问数据库的几种方法如下.

(1)专用的数据库访问工具.如PowerBuilder,Delphi等,它偏向于对数据库中数据的管理和显示,具有限的计算功能.既不适于用它来开发GIS应用系统,也难以将它们的数据操纵功能与现有的GIS应用系统紧密结合.

(2)嵌入数据库语言的常规语言.各数据库厂家为了让用户程序能直接访问自已的数据库,基本上都提供了专有的面向C语言的预编译头和静态库,如Sybase公司的OPENCLIENT和ORACLE的PRO*C.字串5

(3)开放数据库互连性应用编程接口(opendatabaseconnectivityapplicationprogramminginterface,简称ODBCAPI)[2,3].它是微软(Microsoft)公司提出的数据库访问形式.它通过确保所有的应用系统遵循标准的调用层接口,提供对特定数据源命令进行解释的驱动程序来保持应用系统的互用性.这样的应用系统是开放的,只要有相应数据源的ODBC的驱动,它就无需改变代码而可访问相应的数据库.

在确定访问数据库的方式时,ODBCAPI的开放性的优势是不言而喻的,但这种方式在效率上不如第二种访问形式.应说明的是:ODBCSQL语法分为3层,即最小层、核心层和扩展层,尽管目前的大型数据库都能支持到扩展层,但为了保证应用系统的开放性,在具体编程实现时,尽量只使用最小层和核心层的语法.

4某电信局配线系统的实现

客户机为MAPGIS/ODBC/WINDOWS95,服务器为SQLSERVER/WINDOWSNT,要访问的相关表中记录约为13万条.要求从地理底图上选中某一DP,在数据库中寻找出从这一DP到配线架的可用通路,并在数据库中作相应配线修改.如图3所示.结果表明:(1)程序实现了MAPGIS访问网络数据库的功能;(2)客户机和服务器均为PC机(主频166MHz),每次操作反应时间为数秒,换机观察,发现服务器的性能是整个网络计算的瓶颈.

字串8

5结论

(1)C/S模式为目前网络平台GIS的首选,将GIS功能与数据库访问分层实现有利于保护现有的开发成果;(2)将数据请求层放在客户端和以ODBC作为数据库的访问方式保证了应用系统的开放性,其访问可跨越数据系统和操作系统平台;(3)实例表明,应用系统的反应速度更多取决于服务器的性能,而不是ODBC的效率.

参考文献

数据库技术论文篇5

1.公共网关接口CGI(CommonGatewayInterface)

CGI是较早实现的技术。适用于多种服务器平台,如UNIX、WINDOWS等,但CGI的开发成本高、维护困难、功能有限、不具备事务处理功能、占用服务器资源较多。

2.INTERNET数据库连接器IDC(InternetDatabaseConnector)

IDC集成在ISAPI(InternetServerAPI)中,充分利用了DLL技术,易扩充,但编程较CGI更为复杂,只适用于小型数据库系统。

3.先进数据库连接器ADC(AdvanceDatabaseConnector)

ADC提供了ActiveXControl来访问数据库,它的主要特点是数据查询由用户端浏览器执行,因而需将服务器端数据库中的部分记录下载到用户端,系统开销较大、响应慢,只适用于特别频繁的数据库查询操作。

4.JAVA/JDBC语言编程

JAVA语言是一种面向对象、易移植、多线程控制的语言,可通过JDBC去连接数据库。用JAVA/JDBC编写的软件可移植性强,适用于多种操作系统,但其执行效率和执行速度还不理想,目前无法建立高效、高速的应用。

5.动态服务器页面ASP(ActiveServerPage)

ASP是微软公司最新推出的WEB应用开发技术,着重于处理动态网页和WEB数据库的开发,编程灵活、简洁,具有较高的性能,是目前访问WEB数据库的最佳选择。

二.ASP简介

1.ASP访问数据库的原理

ASP是服务器端的脚本执行环境,可用来产生和执行动态的高性能的WEB服务器程序。

当用户使用浏览器请求ASP主页时,WEB服务器响应,调用ASP引擎来执行ASP文件,并解释其中的脚本语言(JScript或VBScript),通过ODBC连接数据库,由数据库访问组件ADO(ActiveXDataObjects)完成数据库操作,最后ASP生成包含有数据查询结果的HTML主页返回用户端显示。

由于ASP在服务器端运行,运行结果以HTML主页形式返回用户浏览器,因而ASP源程序不会泄密,增加了系统的安全保密性。此外,ASP是面向对象的脚本环境,用户可自行增加ActiveX组件来扩充其功能,拓展应用范围。

2.ASP页面的结构:

ASP的程序代码简单、通用,文件名由.asp结尾,ASP文件通常由四部分构成:

1)标准的HTML标记:所有的HTML标记均可使用。

2)ASP语法命令:位于<%%>标签内的ASP代码。

3)服务器端的include语句:可用#include语句调入其它ASP代码,增强了编程的灵活性。

4)脚本语言:ASP自带JScript和VBScript两种脚本语言,增加了ASP的编程功能,用户也可安装其它脚本语言,如Perl、Rexx等。

3.ASP的运行环境

目前ASP可运行在三种环境下。

1)WINDOWSNTserver4.0运行IIS3.0(InternetInformationServer)以上。

2)WINDOWSNTworkstation4.0运行PeerWebServer3.0以上。

3)WINDOWS95/98运行PWS(PersonalWebServer)。

其中以NTserver上的IIS功能最强,提供了对ASP的全面支持,是创建高速、稳定的ASP主页的最佳选择。

4.ASP的内建对象

ASP提供了六个内建对象,供用户直接调用:

1)Application对象:负责管理所有会话信息,可用来在指定的应用程序的所有用户之间共享信息。

2)Session对象:存贮特定用户的会话信息,只被该用户访问,当用户在不同WEB页面跳转时,Session中的变量在用户整个会话过程中一直保存。Session对象需cookie支持。

3)Request对象:从用户端取得信息传递给服务器,是ASP读取用户输入的主要方法。

4)Response对象:服务器将输出内容发送到用户端。

5)Server对象:提供对服务器有关方法和属性的访问。

6)ObjectContext对象:IIS4.0新增的对象,用来进行事务处理。此项功能需得到MTS(MicrosoftTranscationServer)管理的支持。

5.ASP的主要内置组件:

1)AdRotator组件:用来按指定计划在同一页上自动轮换显示广告,用于WWW上日益重要的广告服务。

2)BrowserCapabilities组件:确定访问WEB站点的用户浏览器的功能数据,包括类型、性能、版本等。

3)DatabaseAccess组件:提供ADO(ActiveXDataObjects)来访问支持ODBC的数据库。

4)FileAccess组件:提供对服务器端文件的读写功能。

5)ContentLinking组件:生成WEB页内容列表,并将各页顺序连接,用于制作导航条。

此外,还可安装Myinfo、Counters、ContentRotator、PageCount等组件,用户也可自行编制Actiive组件,以提高系统的实用性。

6.DatabaseAccess组件ADO

WWW上很重要的应用是访问WEB数据库,用ASP访问WEB数据库时,必须使用ADO组件,ADO是ASP内置的ActiveX服务器组件(ActiveXServerComponent),通过在WEB服务器上设置ODBC和OLEDB可连接多种数据库:如SYBASE、ORACLE、INFORMIX、SQLSERVER、ACCESS、VFP等,是对目前微软所支持的数据库进行操作的最有效和最简单直接的方法。

ADO组件主要提供了以下七个对象和四个集合来访问数据库。

1)Connection对象:建立与后台数据库的连接。

2)Command对象:执行SQL指令,访问数据库。

3)Parameters对象和Parameters集合:为Command对象提供数据和参数。

4)RecordSet对象:存放访问数据库后的数据信息,是最经常使用的对象。

5)Field对象和Field集合:提供对RecordSet中当前记录的各个字段进行访问的功能。

6)Property对象和Properties集合:提供有关信息,供Connection、Command、RecordSet、Field对象使用。

7)Error对象和Errors集合:提供访问数据库时的错误信息。

三.ASP访问数据库步骤

在ASP中,使用ADO组件访问后台数据库,可通过以下步骤进行:

1.定义数据源

在WEB服务器上打开“控制面板”,选中“ODBC”,在“系统DSN”下选“添加”,选定你希望的数据库种类、名称、位置等。本文定义“SQLSERVER”,数据源为“HT”,数据库名称为“HTDATA”,脚本语言采用Jscript。

2,使用ADO组件查询WEB数据库

1)调用Server.CreateObject方法取得“ADODB.Connection”的实例,再使用Open方法打开数据库:

conn=Server.CreateObject(“ADODB.Connection”)

conn.Open(“HT”)

2)指定要执行的SQL命令

连接数据库后,可对数据库操作,如查询,修改,删除等,这些都是通过SQL指令来完成的,如要在数据表signaltab中查询代码中含有“X”的记录

sqlStr=“select*fromsignaltabwherecodelike‘%X%’”

rs=conn.Execute(sqlStr)

3)使用RecordSet属性和方法,并显示结果

为了更精确地跟踪数据,要用RecordSet组件创建包含数据的游标,游标就是储存在内存中的数据。

rs=Server.CreateObject(“ADODB.RecordSet”)

rs.Open(sqlStr,conn,1,A)

注:A=1读取

A=3新增、修改、删除

在RecordSet组件中,常用的属性和方法有:

rs.Fields.Count:RecordSet对象的字段数。

rs(i).Name:第i个字段的名称,i为0至rs.Fields.Count-1

rs(i):第i个字段的数据,i为0至rs.Fields.Count-1

rs("字段名"):指定字段的数据。

rs.Record.Count:游标中的数据记录总数。

rs.EOF:是否最后一条记录。

rs.MoveFirst:指向第一条记录。

rs.MoveLast:指向最后一条记录。

rs.MovePrev:指向上一条记录。

rs.MoveNext:指向下一条记录。

rs.GetRows:将数据放入数组中。

rs.Properties.Count:ADO的ResultSet或Connection的属性个数。

rs.Properties(item).Name:ADO的ResultSet或Connection的名称。

rs.Properties:ADO的ResultSet或Connection的值。

rs.close():关闭连接。

4)关闭数据库

conn.close()

四.查询WEB数据库举例

下面这段示例程序是访问SQLSERVER数据库的signaltab表,表中有三个字段:code(代码字段,字符型,3位),class(分类字段,字符型,10位),memo(备注字段,字符型,20位)。程序中数据源DSN:HT、用户名:client、口令:passwd。

屏幕输入页面input.asp

数据库技术论文篇6

计算机技术的飞速发展,为古典文献研究的现代化提供了坚实的基础,其贡献是有目共睹的。然而,计算机技术在古典文献研究中的运用仍然存在着极为严重的缺陷也是不容回避的。笔者近几年来主持并直接参加设计“e书库”数据库的过程中,感到有必要将自己的一些想法提供给正在设计有关软件的计算机专业人员、愿意使用该类软件的专家学者们参考。

一、我国古典文献数据库建设的历程

自古以来,历代学者对古典文献整理与研究一直沿袭手工操作的方式,然而自上世纪80年代后,计算机技术开始涉入到古典文献研究中,对传统的古典文献整理与研究方法(自然也对一切需要使用古典文献资料的专业研究)起到了极大冲击。

首先简单回顾一下计算机技术在古典文献研究领域内发展的历程。上世纪80年代初,我国一些图书馆、大专院校及科研机构陆续开始大规模地利用计算机设计并建立数据库。大致说来有两类数据库,一类是书目数据库,一类是文献数据库。南京图书馆于90年代初率先建立书目数据库,对读者检索有关书目起到了极大的帮助。之后,各地图书馆纷纷效尤,类似的书目数据库很快就普及了。虽说至今各地图书馆的书目数据库的检索方式,仍存在机读编码格式不统一的问题,然而书目数据库提供的方便快捷的查询功能,对读者来说无疑是一件大好事,具体到学术研究来说,至少为研究者提供了一个比较方便的查找有关古典文献的实用工具。

在建立书目数据库的同时,一些大专院校与科研机构开始研发各自的文献数据库。从数据制作格式来说,大致可以区分为两类,一类是图像格式,即将按原著内容扫描成PDF图像文本,另一类是元数据格式,即录入文献文本内容(或扫描并转化为电子文本)导入数据库,并转换成可阅读与检索的数据库机读格式。一般说来,无论是PDF格式还是元数据格式,它们数据库容量都较大,也提供了较为原始的检索方式,为学术研究提供了不小的帮助。从上述两类制作格式的数据库来说,PDF图像文本可以直接阅读图像文字,但总体说来不太适应古典文献整理与研究的需要。而元数据格式较为精致,初步具备了较为方便的常用的功能,可以检索、作卡片等等。

古典文献数据库从收录的文献内容来说,大致可以分为两类:一类是类目数据库,即按“类”收录有关图籍,如经学类、史学类、文学类以及甲骨文、金文或出土文献资料、石刻资料等等,另一类是综合数据库,如《四库全书》、《四部丛刊》、《国学宝典》之类数据库。

大陆最早的古典文献数据库是河南大学的《宋人笔记检索系统南宋主要历史文献》,建立于1987年。之后,各种数据库纷纷涌现,比较重要的有南京大学、河南大学、苏州大学联合研制的《计算机甲骨文信息处理系统》、中国社会科学院《全唐诗》、《先秦魏晋南北朝诗》、《全上古三代秦汉三国六朝文》、《十三经》、《全唐文》、《诸子集成》等数据库、北京大学《全宋诗》数据库、南京师范大学《全唐五代宋词》数据库、四川大学《宋会要辑稿》数据库(与海外合作)等等。港台古籍数字化起步较早,均采用繁体字形式。1984年台湾中央研究院历史语言研究所开始研发《汉籍全文资料库》,香港中文大学则有《汉及以前全部传世文献》、《魏晋南北朝全部传世文献》、《竹简帛书出土文献》数据库等等。其中《竹简帛书出土文献》收录《马王堆汉墓帛书》、《武威汉简》、《睡虎地秦墓汉简》、《银雀山汉简》、《居延汉简释文合校》及其它散见简牍共140多万字的竹简帛书出土文献,价值颇高。

值得注意的是,这些数据库主要是提供给本单位研究人员使用的,当然也有部分数据库对外开放,为其他研究者提供一定帮助。虽然这些数据库有种种限制,但它们无疑为古典文献的研究(当然包括其它专业的学术研究)提供了方便。之后,随着网络技术的发展,各科研机构、大专院校、各地方的图书馆、以及其它数以百计的网站向用户提供收费或不收费的古籍文献检索服务,甚至还提供古籍文献的下载服务。显然,这些工作的开展,为学术研究的现代化提供了极为有力的支持。至今为止,据笔者所查索到的除科研机构、大专院校、各地图书馆数据库之外,提供各种文献下载的中文网站至少在200个以上,其中就有不少古籍文献下载的网站。这些古典文献数据库或有关网站的建立,确实为古典文献整理与研究乃至其它学术研究提供了极有价值的帮助。

二、目前存在的问题

当然,我们也应该清醒地看到,在古典文献数据库大量涌现的同时,一些潜在的问题与数据库本身的缺陷严重地制约着古典文献数据库的正常发展。

从古典文献数据库技术发展角度来说,笔者认为大致经过三个发展阶段。第一阶段是PDF图像文本数据库,其数据来源主要是以扫描方式获得,形成PDF图像文本。这种图像文本优点是直观,与原书分毫不差,但它的缺点是功能极其单一,仅可供浏览图像和简单地检索书目。虽然第一阶段的数据库功能极少,但毕竟能方便而直观地阅读文献了,因此引起了学者们广泛的兴趣。必须指出的是,由于功能太少,这类数据库难以进一步发展。

第二阶段是元数据数据库,以香港迪志公司投资、书同文数字化技术有限公司设计、上海人民出版社出版的《四库全书》、书同文数字化技术有限公司设计、万方数据电子出版社的《四部丛刊》、尹小林《国学宝典》、南开大学永川公司的《二十四史》,以及大陆、港台等大专院校或科研机构制作的较大型的数据库为代表。它们的优点是具有较多的基本功能,如检索、卡片、打印等功能,有些还附加了日历查询、字典、音乐背景等附加功能。然而,它们都不允许对数据库内的文本错误进行修订、没有图表处理能力、不提供功能升级服务(某些软件提供所谓新版本,实际上只是增加一些文献文本,并未真正提升软件服务功能)。而且由于各自为政,开发者大都采取自定义方法来自造非常用的生僻词,因此各种数据库之间字库不能相互兼容。这一阶段的古典文献数据库也有吸收第一阶段数据库有图像的优点,如上述提及的《四库全书》就附有图像,以利研究者核对文字。该阶段绝大多数数据库注意到版权问题,但仍有一些数据库在版权上出现较大问题,乃至引起法律纠纷。

计算机技术广泛地涉入文科研究领域,各种古典文献数据库纷纷建立,当然给古典文献整理与研究的现代化提供了极其有利的帮助,然而,在笔者看来,目前计算机技术在这一领域中的运用形成纷乱无序的“战国时代”,有许多亟待解决的问题,否则将会影响或说削弱计算机技术在古典文献研究(乃至其它学术研究)中巨大作用。对此弊病,笔者拟作一概述,企望引起有关部门、数据库开发者及使用者的重视,以期真正使计算机技术对古典文献整理与研究起到更大的促进作用。大致说来,主要问题有以下几个方面:

其一,缺乏整体领导与规划,国家投资与收益不对称。当然,首先应该看到,国家有关部门已经着手做了一些规划,也实施建立一些比较大的古典文献数据库,如2002年10月,国家科技图书文献中心受科技部的委托,牵头联合中国科技信息研究所、国家图书馆、上海图书馆、中科院图书馆、北京大学图书馆等单位,启动了我国数字图书馆标准规范建设项目。这一项目的目的就是力图建立我国比较统一和规范的数字图书馆标准,自然也会对建立古典文献数据库有较大的借鉴与参考的价值。又如北京大学《中国基本古籍库》、上海图书馆《古籍影像光盘制作及检索系统》等等,也由国家有关部门投入大量资金,而且已经启动并完成了部分内容。不过也应该强调,由于国家没有制定出一个比较符合国内数据库发展状况的真正有价值的规范体系,因此这些项目的承担者仍是各自为政,数据库之间并不能兼容,不可能形成技术“合力”。再从所取得的社会效益或说实际使用价值来看,也不尽人意。因为至今为止建立的各种数据库仍人为地设置许多障碍,无法使它们实现较大的使用价值。数据库由国家投资,收益自然应该归国家,或者成为不收费的公益数据库,但目前收益既不归国家,又未能成为公益数据库,这不能不说是个极大的遗憾。实际上,数据库制作者无偿利用国家投资进行了开发,制作完成后却获得相当丰厚的收益,使人感到有“国家投资,个别单位图利”的印象。笔者不反对交纳一定使用费用,但收费单位一定应该说明收费后去向,绝不允许产生国家投资而由个别单位乃至某些个人得利的情况。

其二,开发商嗜利忘义,数据库错误严重。除上述由国家投资开发的古典文献数据库外,还有一些有一定技术实力的软件开发商加入到古典文献数据库的开发中来了。比较而言,各科研机构、大专院校及各地图书馆建立的古典文献数据库质量较高,而开发商则很少关注数据库中的文献质量。我们承认确有少量开发商制作的数据库质量较高,如迪志公司开发的《四库全书》之类,然而象《四库全书》这样的数据库确实凤毛麟角,难以寻觅。我们发现,甚至有些开发商仅仅是把文本进行文字扫描导入,疏于校对,因此文本错误百出,难以卒读。由于利益驱使,绝大多数开发商都以“独自开发”为己任,数据库设计相互保密,互不兼容,使用户深感不便。这些问题已严重地影响到古典文献数据库的正常发展了。

其三,热门文献数据重复,冷门文献数据罕见。虽说目前数据库品种繁多,但由于考虑到使用者对文献内容的需求,因此许多开发者热衷于开发那些热门数据,而一些比较冷门的文献则鲜有人问津。实际上,冷门的文献并非是没有学术价值的文献,只是使用人较少而已。因而,目前不但数据库中文献内容重复现象极为普遍,甚至同名同姓的数据库也有不少,如《四库全书》就出现了武汉大学版、上海人民出版社版等数种不同版本。且不说那些数量繁多、质量也不甚高的数据库浪费了多少人力物力,其实也使用户陷入无可适从、欲舍不能的境地。用户往往为了某些少量文献内容不得不购买和安装整个数据库操作系统,而且这些庞大的数据库大量占据硬盘空间,导致计算机运行速度大为减慢。而那些允许网上检索的文献数据库又往往容量极大,上网检索者多,导致“交通阻塞”!

其四,技术关卡重重,难以互相兼容。各开发者既鉴于不同开发目的与技术条件,又为防止他人解密,因此在开发过程中在数据库某些程序中人为设置技术障碍,以保障自己利益不受损害。自然,开发者需要投入大量人力物力,保障本身利益不受损害是无可非议的。然而也由于人为地设置了障碍,却使各种文献数据库之间不能兼容,无法形成合力,先进的技术反而成为技术壁垒。实际上,这一情况大大浪费了宝贵的人力资源与财力,对古典文献的开发与利用有百害而无一利。另外,由于技术壁垒,在古典文献数据库的文字方面更导致许多问题。我国古籍常用汉字大约为4万余个,这还不包括超过2万个异体字及数千甲骨文、金文等古文字。然而我国目前在计算机上采纳的国标字库(GB)和扩展字库(GBK),两者相加也只有27000余字,这与我国古籍常用汉字数量相比,实在差距太大。因此,如此小的字库与需求相比确实是捉襟见肘。为了弥补这一缺陷,一些软件设计者就采取在自定义区自造字(乃至占据字库中扩展B的位置)、有些也用图片方式来填字。而这些自造字、图片字,拷贝到WORD文本之后,由于内码位置的差异就变成其它字了,从而导致文本错误。

其五,功能单调,难以真正为科研服务。建立较早的古典文献数据库功能比较单调,只能做些简单检索、拷贝,没有更为先进的功能,不能适应学术研究的需要。后来的一些古典文献数据库也存在类似问题,例如《四库全书》的检索功能,虽说可以采用添加“作者”、“书名”等限定条件,但检索结果只是罗列一排出处,无法直观地了解检索到的具体内容。而且《四库全书》也没有提供更多的功能给用户,因此这一巨大的工程仍远远不能满足用户的需求。况且这一数据库目前已经“定型”,不再继续开发,使用户对此深感遗憾。而其它古典文献数据库设计者的思维大多仍停留在“文本之争”当中,重复着原来设计思想的错误,没有更多地开发为科研服务的有效功能,因此在笔者看来,这一做法显然不可能真正摆脱古典文献数据库目前面临着的困境。

其六,学术圈地,使人心有余而力难用。解放后,一些部级出版社化费了极大的精力,组织专家点校了不少重要古籍,为学术研究的发展作出了极大贡献。然而时至计算机时代的来临,却出现了“版权”的问题。一些制作者忽视了国家有关版权法规,直接利用了一些出版社的成果来牟取经济利益,理所当然地会产生版权纠纷。笔者以为,保护版权是每个学者乃至每个公民应尽的责任,根本毫无讨价还价的余地。然而问题是,现在一些出版社由于各种原因,没有对自己已出版的点校过的古籍进行开发,而愿意开发这些古籍资源者却无法涉入其中,导致他们处于既想开发这一宝藏又无法回避版权问题的尴尬境地,这就使众多需要使用者望洋兴叹。如果有关出版社不愿授权,那么想要开发这些古籍者只能返回到没有标点的原始文本中去。这种情况确实使每一个希望使用古典文献数据库的用户感到极其失望,而且严重影响了古典整理与研究的现代化进度。

上述种种现实情况,已经是制约计算机技术对古典文献整理与研究支持的瓶颈了,如果不解决这些问题,计算机技术即使再发达,恐怕也难以对古典文献整理与研究予以真正意义上的支持与帮助。

转贴于 三、如何解决古典文献数据库存在的问题

古典文献数据库存在的问题是十分明显的,那么如何解决这些问题,以利学术研究(当然包括文献研究)的迅速发展?笔者以为现在应该设计和开发出新一代文献数据库的软件。按照笔者设想,这代软件应该以建立能自由升级的公共古典文献数据库为目的,是一种以提供强大功能为主、彻底解决版权问题的数据库,实际上是建立一个规模巨大的功能相对完善的学术研究资源库。所谓公共古典文献数据库是综合性数据库,只能由国家有关部门作为主要规划者,它应该尽可能地包罗我国传世古典文献、碑刻资料和出土文献等。在此基础上允许建立适应每个研究者研究范围的个性化的文献检索服务系统。个性化的文献检索服务系统是指每个具体研究者所拥有的安装在各自计算机上的文献检索服务系统,它拥有一定数量的适合自己研究的范围的古典文献文本。其实,各个研究者并不需要一个“包罗万象”的规模极其巨大的数据库,即使象占据6至7个G硬盘的《四库全书》,具体到一个研究者真正需要的内容并不是全部,而是其中一部分内容。

问题的关键在于公共古典文献数据库与个性化文献检索服务系统两者之间的技术“契合”,即两者互相兼容的程度。公共古典文献数据库应该与个性化文献检索服务系统有所区别,公共古典文献数据库应该侧重于文献数量的完善、完备,而个性化文献检索服务系统则应该考虑其功能强大。因此,从本质上说,公共古典文献数据库应该是一个统一的设计比较周密、与其它个性化数据库在技术上能实现良好兼容的的数据库;而个性化文献检索服务系统应该是“百花齐放”式的但必须能与公共古典文献数据库兼容而非各自为政的小型数据库。两者关系是源与流的关系。鉴于此,笔者以为目前应该从两个层次上来解决问题,一是尽快建立公共古典文献数据库;一是继续开发个性化文献检索服务系统。

根据笔者近几年的实践,感到要解决这些问题并非不可能的。其实只要认真对目前计算机技术在古典文献整理与研究中存在的问题作一分析与梳理,重点突破一些瓶颈问题,应该说是能解决上述这些问题的。那么怎么才能突破上述这些瓶颈呢?笔者以为以下几个方面是值得考虑的。

其一,加强总体规划,建立公共古典文献数据库。作为一个具体单位来说,谁也没有可能建立一个包罗万象的古典文献数据库,因此,这只能由国家有关部门组织人力物力来完成。其实,就目前来说,国家投入资金并不少,但由于制度原因,只是向某些重点院校或科研单位、向重点项目投入巨资,而这些单位建立起各自为政的古典文献数据库、期刊数据库,虽然也为学术研究作了一些贡献,但不可否认的是,由于各自设计思路不同,相互之间不能兼容,已经妨碍到数据库进一步发展了。以笔者愚见,国家有关部门应该主动负起责来,加强领导,重新考虑古典文献数据库的立项问题,组织力量、投入资金,真正建立起一个规模巨大、能为绝大多数研究者利用的公共古典文献数据库。同时也应该考虑所立项的古典文献数据库与其它数据库(如现代文献数据库、当代文献数据库、期刊数据库等)之间的兼容关系,只有这样,或许若干年之后就能建立起一个价值极大的能真正为学术服务的公共古典文献数据库,乃至包罗一切文献的数据库。当然,就公共古典文献数据库来说,可以进行适量收费服务,但主要仍应该定位在“公益”上,不以“利”为主,这样才能真正建立一个有价值的公共古典文献数据库来。

其二,数据库内容与文献检索服务系统分离。这个问题与上述问题是紧密关联在一起的,如果不能真正做到数据库内容与文献检索服务系统分离,那么目前“列国纷争”的面貌是不可能真正解决的。

我们知道,一个古典文献数据库实际上是两大部分组成的,一是古典文献数据库内容,即数据库所包括的文献文本,二是对这些数据进行管理的文献检索服务系统。其实目前所见有关古典文献数据库都是“两者合一”,即既包含一些文献数据内容,又有具体的操作服务系统。事实上,这些古典文献数据库在功能上明显存在缺陷的。就目前古典文献数据库管理形式来说,一是网络管理,一是个人管理。前者是网络数据库,一般是单位所拥有的数据库,即我们所说的网络版,后者是安装在个人电脑中的个人版。就功能来说,网络版没有必要具有卡片、文本修订、书签等个性化的功能,个人版应该具有做卡片、文本修订、书签、文献管理等个性化的功能。就文献数量来说,网络版自然力求文献内容丰富,尽可能包罗文献文本,而个人版实际所需要的文献数量是根据各自研究需要而定的,因而强行“规定”使用所有文献内容并不值得肯定。就文献内容来说,网络版与个人版都应该允许不断地增加其数据库文献内容,但不同的是,网络版应该是只增不减,而个人版应该允许用户根据研究需要自由增减文献内容。

在笔者看来,应该从单纯的文本内容竞争的思维中解脱出来,进入以文献检索服务系统竞争为主,文本竟争为辅的体系,或许是解决古籍文献数据库的出路。也就是说,擅长计算机技术的开发者(开发商)应该注重文献检索服务功能的开发与完善,而具体文本的整理可由研究学术的专业人士来完成。这样,开发者就可能开发出比较成功的文献检索服务系统,而数据库中的文本也由于专业人士的加入而能大大提高文本的准确率,然后合成为一个规模较大的公共古典文献数据库。当然,输入和整理古典文献文本可以采用投标(或以申报项目形式)来确定,规定统一格式,要求保证文本的正确率达到一定比例,完成后再分别导入这一公共古典文献数据库中;经过若干年努力,最终能形成一个规模巨大、适应于学术研究的公共古典文献数据库。我想,采取这种措施不但节省了大量重复投资,真正做到人尽其才,物尽其用,而且一旦建立起这个规模巨大的公共古典文献数据库,可以解决了目前数据库泛滥、文本错误太多、重复劳动等弊病,而且真正能做到广大学者对古典资源“共享共有”。

在此基础上,各个开发商可以力求开发学者们个性化的文献检索服务系统,它无须考虑文献文本内容,但必须功能强大、操作方便,并与公共古典文献数据库完全兼容,学者们通过“购买”文本或其它方式来方便地组建自己的数据库,这样或许会给学术研究带来真正的方便。

还须补充的是,我国的古典文献中有大量表格与图片,而由于技术原因,目前所有古典文献数据库都没有导入原著的表格与图片,极个别数据库有少量图片也是不能检索,这是目前众多古典文献数据库的重大失误之一。其实只要真正化力气去探索,这个问题是不难解决的。因为笔者曾作过设计并反复试验,只要设计合理,图片与表格不但可以导入数据库,而且都是可以在数据库中进行检索。

其三,加速确定字库方案,以利数据库健康发展。当然,要真正解决公共古典文献数据库问题,还必须解决字库问题。目前,国家虽然组织专家在论证有关字库问题,然而由于进程不快,远远落后于当今计算机技术发展的需要。按照笔者的看法,应该建立一个以Unicode字库为基础的、适应汉语古籍需要的、并与国际接轨的真正有中国特色的字库。这就需要抓紧工作,迅速落实扩展字库B的内码。同时根据我国汉字的具体特点,对自定义区域的6400字的内码配置也应该有所规范,这样才能使汉语字库统一问题落实到实处。如果真能做到如此,那么就能真正解决目前古典文献数据库之间字库互不兼容问题。

与字库相关联的是字体问题。古典文献数据库应该考虑到古代文献对文字的特殊需要,笔者以为凡是古代文献数据库中的文本应该保留繁体字,以防繁简不分而导致文义偏差。就目前计算机技术来说,解决这一问题是毫无困难的。其实用繁体字输入文本早已不是问题,而扫描古籍文本再转换成文字的技术也十分成熟,如北京书同文公司的“数码翰林”OCR识别系统,应该说是极有价值的识别软件,对绝大多数繁体文字能够正确识别。如果能再进一步加以改进,使扩充字库数量并与Unicode字库兼容,那么古代文献的文字识别问题是可以得到解决的。应该强调的是,古代文献以繁体字导入数据库,但应该允许在数据库中自由进行繁简转换,换句话说,若需要使用繁体字时,文本可以保留繁体字,而需要简体时,可以十分方便地转换成简体,这样就适应用户对繁简体的不同需要了。

其四,彻底解决古典文献版权问题。这是困挠计算机古典文献数据库建设的重要难题之一。自然,这一问题要真正得到落实确实存在相当困难的,因为版权保护工作任重道远!不过,即使困难再大,古籍文献数据化的发展的潮流是不可能停止的。笔者以为,有关出版社在维护自身法定的版权权益的前提下,应该从大局出发,在收取一定数量的报酬前提下,允许制作有关古典文献的数据库,以利学术研究的发展。至于报酬多少可以也应该实事求是地酌情商定,国家有关部门应该主动与那些出版社协调,亦可将目前大量分散投入到各课题中的资金中抽出部分来补偿有关出版社,双赢互利,以求突破版权瓶颈,早日解决这一棘手的问题。

与此相关的是古典文献电子文本的版权问题,这也是个极难处理的问题。因为用户若贪图小利,版权意识不强,不愿化费代价使用电子文本,就容易产生“盗版”问题,如此就使得制作古典文献电子文本者的正当利益大受损失。按笔者设想,如果真正能够由国家有关部门主管古典文献数据库建设工作,那么就可以设想建立公共古典文献数据库规定导入数据库的文献文本都给予一个“统一编号”,没有统一编号的文献就不能直接导入公共古典文献数据库和个人使用的文献检索服务系统中,也就是说,个人使用古典文献电子文献必须化费一定的代价才能取得使用权,这样就可以保证制作古典文献电子文本者的一定收益,防止版权意识不强者侵权使用。同时由于古典文献电子文本都有了统一编号,那么也就可以防止某一具体文献文本重复录入的问题。即使有部分重复,古典文献电子文本也可以在用户选择过程中优胜劣汰。

数据库技术论文篇7

计算机技术的飞速发展,为古典文献研究的现代化提供了坚实的基础,其贡献是有目共睹的。然而,计算机技术在古典文献研究中的运用仍然存在着极为严重的缺陷也是不容回避的。笔者近几年来主持并直接参加设计“e书库”数据库的过程中,感到有必要将自己的一些想法提供给正在设计有关软件的计算机专业人员、愿意使用该类软件的专家学者们参考。

一、我国古典文献数据库建设的历程

自古以来,历代学者对古典文献整理与研究一直沿袭手工操作的方式,然而自上世纪80年代后,计算机技术开始涉入到古典文献研究中,对传统的古典文献整理与研究方法(自然也对一切需要使用古典文献资料的专业研究)起到了极大冲击。

首先简单回顾一下计算机技术在古典文献研究领域内发展的历程。上世纪80年代初,我国一些图书馆、大专院校及科研机构陆续开始大规模地利用计算机设计并建立数据库。大致说来有两类数据库,一类是书目数据库,一类是文献数据库。南京图书馆于90年代初率先建立书目数据库,对读者检索有关书目起到了极大的帮助。之后,各地图书馆纷纷效尤,类似的书目数据库很快就普及了。虽说至今各地图书馆的书目数据库的检索方式,仍存在机读编码格式不统一的问题,然而书目数据库提供的方便快捷的查询功能,对读者来说无疑是一件大好事,具体到学术研究来说,至少为研究者提供了一个比较方便的查找有关古典文献的实用工具。

在建立书目数据库的同时,一些大专院校与科研机构开始研发各自的文献数据库。从数据制作格式来说,大致可以区分为两类,一类是图像格式,即将按原著内容扫描成PDF图像文本,另一类是元数据格式,即录入文献文本内容(或扫描并转化为电子文本)导入数据库,并转换成可阅读与检索的数据库机读格式。一般说来,无论是PDF格式还是元数据格式,它们数据库容量都较大,也提供了较为原始的检索方式,为学术研究提供了不小的帮助。从上述两类制作格式的数据库来说,PDF图像文本可以直接阅读图像文字,但总体说来不太适应古典文献整理与研究的需要。而元数据格式较为精致,初步具备了较为方便的常用的功能,可以检索、作卡片等等。

古典文献数据库从收录的文献内容来说,大致可以分为两类:一类是类目数据库,即按“类”收录有关图籍,如经学类、史学类、文学类以及甲骨文、金文或出土文献资料、石刻资料等等,另一类是综合数据库,如《四库全书》、《四部丛刊》、《国学宝典》之类数据库。

大陆最早的古典文献数据库是河南大学的《宋人笔记检索系统南宋主要历史文献》,建立于1987年。之后,各种数据库纷纷涌现,比较重要的有南京大学、河南大学、苏州大学联合研制的《计算机甲骨文信息处理系统》、中国社会科学院《全唐诗》、《先秦魏晋南北朝诗》、《全上古三代秦汉三国六朝文》、《十三经》、《全唐文》、《诸子集成》等数据库、北京大学《全宋诗》数据库、南京师范大学《全唐五代宋词》数据库、四川大学《宋会要辑稿》数据库(与海外合作)等等。港台古籍数字化起步较早,均采用繁体字形式。1984年台湾中央研究院历史语言研究所开始研发《汉籍全文资料库》,香港中文大学则有《汉及以前全部传世文献》、《魏晋南北朝全部传世文献》、《竹简帛书出土文献》数据库等等。其中《竹简帛书出土文献》收录《马王堆汉墓帛书》、《武威汉简》、《睡虎地秦墓汉简》、《银雀山汉简》、《居延汉简释文合校》及其它散见简牍共140多万字的竹简帛书出土文献,价值颇高。

值得注意的是,这些数据库主要是提供给本单位研究人员使用的,当然也有部分数据库对外开放,为其他研究者提供一定帮助。虽然这些数据库有种种限制,但它们无疑为古典文献的研究(当然包括其它专业的学术研究)提供了方便。之后,随着网络技术的发展,各科研机构、大专院校、各地方的图书馆、以及其它数以百计的网站向用户提供收费或不收费的古籍文献检索服务,甚至还提供古籍文献的下载服务。显然,这些工作的开展,为学术研究的现代化提供了极为有力的支持。至今为止,据笔者所查索到的除科研机构、大专院校、各地图书馆数据库之外,提供各种文献下载的中文网站至少在200个以上,其中就有不少古籍文献下载的网站。这些古典文献数据库或有关网站的建立,确实为古典文献整理与研究乃至其它学术研究提供了极有价值的帮助。

二、目前存在的问题

当然,我们也应该清醒地看到,在古典文献数据库大量涌现的同时,一些潜在的问题与数据库本身的缺陷严重地制约着古典文献数据库的正常发展。

从古典文献数据库技术发展角度来说,笔者认为大致经过三个发展阶段。第一阶段是PDF图像文本数据库,其数据来源主要是以扫描方式获得,形成PDF图像文本。这种图像文本优点是直观,与原书分毫不差,但它的缺点是功能极其单一,仅可供浏览图像和简单地检索书目。虽然第一阶段的数据库功能极少,但毕竟能方便而直观地阅读文献了,因此引起了学者们广泛的兴趣。必须指出的是,由于功能太少,这类数据库难以进一步发展。

第二阶段是元数据数据库,以香港迪志公司投资、书同文数字化技术有限公司设计、上海人民出版社出版的《四库全书》、书同文数字化技术有限公司设计、万方数据电子出版社的《四部丛刊》、尹小林《国学宝典》、南开大学永川公司的《二十四史》,以及大陆、港台等大专院校或科研机构制作的较大型的数据库为代表。它们的优点是具有较多的基本功能,如检索、卡片、打印等功能,有些还附加了日历查询、字典、音乐背景等附加功能。然而,它们都不允许对数据库内的文本错误进行修订、没有图表处理能力、不提供功能升级服务(某些软件提供所谓新版本,实际上只是增加一些文献文本,并未真正提升软件服务功能)。而且由于各自为政,开发者大都采取自定义方法来自造非常用的生僻词,因此各种数据库之间字库不能相互兼容。这一阶段的古典文献数据库也有吸收第一阶段数据库有图像的优点,如上述提及的《四库全书》就附有图像,以利研究者核对文字。该阶段绝大多数数据库注意到版权问题,但仍有一些数据库在版权上出现较大问题,乃至引起法律纠纷。

计算机技术广泛地涉入文科研究领域,各种古典文献数据库纷纷建立,当然给古典文献整理与研究的现代化提供了极其有利的帮助,然而,在笔者看来,目前计算机技术在这一领域中的运用形成纷乱无序的“战国时代”,有许多亟待解决的问题,否则将会影响或说削弱计算机技术在古典文献研究(乃至其它学术研究)中巨大作用。对此弊病,笔者拟作一概述,企望引起有关部门、数据库开发者及使用者的重视,以期真正使计算机技术对古典文献整理与研究起到更大的促进作用。大致说来,主要问题有以下几个方面:

其一,缺乏整体领导与规划,国家投资与收益不对称。当然,首先应该看到,国家有关部门已经着手做了一些规划,也实施建立一些比较大的古典文献数据库,如2002年10月,国家科技图书文献中心受科技部的委托,牵头联合中国科技信息研究所、国家图书馆、上海图书馆、中科院图书馆、北京大学图书馆等单位,启动了我国数字图书馆标准规范建设项目。这一项目的目的就是力图建立我国比较统一和规范的数字图书馆标准,自然也会对建立古典文献数据库有较大的借鉴与参考的价值。又如北京大学《中国基本古籍库》、上海图书馆《古籍影像光盘制作及检索系统》等等,也由国家有关部门投入大量资金,而且已经启动并完成了部分内容。不过也应该强调,由于国家没有制定出一个比较符合国内数据库发展状况的真正有价值的规范体系,因此这些项目的承担者仍是各自为政,数据库之间并不能兼容,不可能形成技术“合力”。再从所取得的社会效益或说实际使用价值来看,也不尽人意。因为至今为止建立的各种数据库仍人为地设置许多障碍,无法使它们实现较大的使用价值。数据库由国家投资,收益自然应该归国家,或者成为不收费的公益数据库,但目前收益既不归国家,又未能成为公益数据库,这不能不说是个极大的遗憾。实际上,数据库制作者无偿利用国家投资进行了开发,制作完成后却获得相当丰厚的收益,使人感到有“国家投资,个别单位图利”的印象。笔者不反对交纳一定使用费用,但收费单位一定应该说明收费后去向,绝不允许产生国家投资而由个别单位乃至某些个人得利的情况。

其二,开发商嗜利忘义,数据库错误严重。除上述由国家投资开发的古典文献数据库外,还有一些有一定技术实力的软件开发商加入到古典文献数据库的开发中来了。比较而言,各科研机构、大专院校及各地图书馆建立的古典文献数据库质量较高,而开发商则很少关注数据库中的文献质量。我们承认确有少量开发商制作的数据库质量较高,如迪志公司开发的《四库全书》之类,然而象《四库全书》这样的数据库确实凤毛麟角,难以寻觅。我们发现,甚至有些开发商仅仅是把文本进行文字扫描导入,疏于校对,因此文本错误百出,难以卒读。由于利益驱使,绝大多数开发商都以“独自开发”为己任,数据库设计相互保密,互不兼容,使用户深感不便。这些问题已严重地影响到古典文献数据库的正常发展了。

其三,热门文献数据重复,冷门文献数据罕见。虽说目前数据库品种繁多,但由于考虑到使用者对文献内容的需求,因此许多开发者热衷于开发那些热门数据,而一些比较冷门的文献则鲜有人问津。实际上,冷门的文献并非是没有学术价值的文献,只是使用人较少而已。因而,目前不但数据库中文献内容重复现象极为普遍,甚至同名同姓的数据库也有不少,如《四库全书》就出现了武汉大学版、上海人民出版社版等数种不同版本。且不说那些数量繁多、质量也不甚高的数据库浪费了多少人力物力,其实也使用户陷入无可适从、欲舍不能的境地。用户往往为了某些少量文献内容不得不购买和安装整个数据库操作系统,而且这些庞大的数据库大量占据硬盘空间,导致计算机运行速度大为减慢。而那些允许网上检索的文献数据库又往往容量极大,上网检索者多,导致“交通阻塞”!

其四,技术关卡重重,难以互相兼容。各开发者既鉴于不同开发目的与技术条件,又为防止他人解密,因此在开发过程中在数据库某些程序中人为设置技术障碍,以保障自己利益不受损害。自然,开发者需要投入大量人力物力,保障本身利益不受损害是无可非议的。然而也由于人为地设置了障碍,却使各种文献数据库之间不能兼容,无法形成合力,先进的技术反而成为技术壁垒。实际上,这一情况大大浪费了宝贵的人力资源与财力,对古典文献的开发与利用有百害而无一利。另外,由于技术壁垒,在古典文献数据库的文字方面更导致许多问题。我国古籍常用汉字大约为4万余个,这还不包括超过2万个异体字及数千甲骨文、金文等古文字。然而我国目前在计算机上采纳的国标字库(GB)和扩展字库(GBK),两者相加也只有27000余字,这与我国古籍常用汉字数量相比,实在差距太大。因此,如此小的字库与需求相比确实是捉襟见肘。为了弥补这一缺陷,一些软件设计者就采取在自定义区自造字(乃至占据字库中扩展B的位置)、有些也用图片方式来填字。而这些自造字、图片字,拷贝到WORD文本之后,由于内码位置的差异就变成其它字了,从而导致文本错误。

其五,功能单调,难以真正为科研服务。建立较早的古典文献数据库功能比较单调,只能做些简单检索、拷贝,没有更为先进的功能,不能适应学术研究的需要。后来的一些古典文献数据库也存在类似问题,例如《四库全书》的检索功能,虽说可以采用添加“作者”、“书名”等限定条件,但检索结果只是罗列一排出处,无法直观地了解检索到的具体内容。而且《四库全书》也没有提供更多的功能给用户,因此这一巨大的工程仍远远不能满足用户的需求。况且这一数据库目前已经“定型”,不再继续开发,使用户对此深感遗憾。而其它古典文献数据库设计者的思维大多仍停留在“文本之争”当中,重复着原来设计思想的错误,没有更多地开发为科研服务的有效功能,因此在笔者看来,这一做法显然不可能真正摆脱古典文献数据库目前面临着的困境。

其六,学术圈地,使人心有余而力难用。解放后,一些部级出版社化费了极大的精力,组织专家点校了不少重要古籍,为学术研究的发展作出了极大贡献。然而时至计算机时代的来临,却出现了“版权”的问题。一些制作者忽视了国家有关版权法规,直接利用了一些出版社的成果来牟取经济利益,理所当然地会产生版权纠纷。笔者以为,保护版权是每个学者乃至每个公民应尽的责任,根本毫无讨价还价的余地。然而问题是,现在一些出版社由于各种原因,没有对自己已出版的点校过的古籍进行开发,而愿意开发这些古籍资源者却无法涉入其中,导致他们处于既想开发这一宝藏又无法回避版权问题的尴尬境地,这就使众多需要使用者望洋兴叹。如果有关出版社不愿授权,那么想要开发这些古籍者只能返回到没有标点的原始文本中去。这种情况确实使每一个希望使用古典文献数据库的用户感到极其失望,而且严重影响了古典整理与研究的现代化进度。

上述种种现实情况,已经是制约计算机技术对古典文献整理与研究支持的瓶颈了,如果不解决这些问题,计算机技术即使再发达,恐怕也难以对古典文献整理与研究予以真正意义上的支持与帮助。

三、如何解决古典文献数据库存在的问题

古典文献数据库存在的问题是十分明显的,那么如何解决这些问题,以利学术研究(当然包括文献研究)的迅速发展?笔者以为现在应该设计和开发出新一代文献数据库的软件。按照笔者设想,这代软件应该以建立能自由升级的公共古典文献数据库为目的,是一种以提供强大功能为主、彻底解决版权问题的数据库,实际上是建立一个规模巨大的功能相对完善的学术研究资源库。所谓公共古典文献数据库是综合性数据库,只能由国家有关部门作为主要规划者,它应该尽可能地包罗我国传世古典文献、碑刻资料和出土文献等。在此基础上允许建立适应每个研究者研究范围的个性化的文献检索服务系统。个性化的文献检索服务系统是指每个具体研究者所拥有的安装在各自计算机上的文献检索服务系统,它拥有一定数量的适合自己研究的范围的古典文献文本。其实,各个研究者并不需要一个“包罗万象”的规模极其巨大的数据库,即使象占据6至7个G硬盘的《四库全书》,具体到一个研究者真正需要的内容并不是全部,而是其中一部分内容。

问题的关键在于公共古典文献数据库与个性化文献检索服务系统两者之间的技术“契合”,即两者互相兼容的程度。公共古典文献数据库应该与个性化文献检索服务系统有所区别,公共古典文献数据库应该侧重于文献数量的完善、完备,而个性化文献检索服务系统则应该考虑其功能强大。因此,从本质上说,公共古典文献数据库应该是一个统一的设计比较周密、与其它个性化数据库在技术上能实现良好兼容的的数据库;而个性化文献检索服务系统应该是“百花齐放”式的但必须能与公共古典文献数据库兼容而非各自为政的小型数据库。两者关系是源与流的关系。鉴于此,笔者以为目前应该从两个层次上来解决问题,一是尽快建立公共古典文献数据库;一是继续开发个性化文献检索服务系统。

根据笔者近几年的实践,感到要解决这些问题并非不可能的。其实只要认真对目前计算机技术在古典文献整理与研究中存在的问题作一分析与梳理,重点突破一些瓶颈问题,应该说是能解决上述这些问题的。那么怎么才能突破上述这些瓶颈呢?笔者以为以下几个方面是值得考虑的。

其一,加强总体规划,建立公共古典文献数据库。作为一个具体单位来说,谁也没有可能建立一个包罗万象的古典文献数据库,因此,这只能由国家有关部门组织人力物力来完成。其实,就目前来说,国家投入资金并不少,但由于制度原因,只是向某些重点院校或科研单位、向重点项目投入巨资,而这些单位建立起各自为政的古典文献数据库、期刊数据库,虽然也为学术研究作了一些贡献,但不可否认的是,由于各自设计思路不同,相互之间不能兼容,已经妨碍到数据库进一步发展了。以笔者愚见,国家有关部门应该主动负起责来,加强领导,重新考虑古典文献数据库的立项问题,组织力量、投入资金,真正建立起一个规模巨大、能为绝大多数研究者利用的公共古典文献数据库。同时也应该考虑所立项的古典文献数据库与其它数据库(如现代文献数据库、当代文献数据库、期刊数据库等)之间的兼容关系,只有这样,或许若干年之后就能建立起一个价值极大的能真正为学术服务的公共古典文献数据库,乃至包罗一切文献的数据库。当然,就公共古典文献数据库来说,可以进行适量收费服务,但主要仍应该定位在“公益”上,不以“利”为主,这样才能真正建立一个有价值的公共古典文献数据库来。

其二,数据库内容与文献检索服务系统分离。这个问题与上述问题是紧密关联在一起的,如果不能真正做到数据库内容与文献检索服务系统分离,那么目前“列国纷争”的面貌是不可能真正解决的。

我们知道,一个古典文献数据库实际上是两大部分组成的,一是古典文献数据库内容,即数据库所包括的文献文本,二是对这些数据进行管理的文献检索服务系统。其实目前所见有关古典文献数据库都是“两者合一”,即既包含一些文献数据内容,又有具体的操作服务系统。事实上,这些古典文献数据库在功能上明显存在缺陷的。就目前古典文献数据库管理形式来说,一是网络管理,一是个人管理。前者是网络数据库,一般是单位所拥有的数据库,即我们所说的网络版,后者是安装在个人电脑中的个人版。就功能来说,网络版没有必要具有卡片、文本修订、书签等个性化的功能,个人版应该具有做卡片、文本修订、书签、文献管理等个性化的功能。就文献数量来说,网络版自然力求文献内容丰富,尽可能包罗文献文本,而个人版实际所需要的文献数量是根据各自研究需要而定的,因而强行“规定”使用所有文献内容并不值得肯定。就文献内容来说,网络版与个人版都应该允许不断地增加其数据库文献内容,但不同的是,网络版应该是只增不减,而个人版应该允许用户根据研究需要自由增减文献内容。

在笔者看来,应该从单纯的文本内容竞争的思维中解脱出来,进入以文献检索服务系统竞争为主,文本竟争为辅的体系,或许是解决古籍文献数据库的出路。也就是说,擅长计算机技术的开发者(开发商)应该注重文献检索服务功能的开发与完善,而具体文本的整理可由研究学术的专业人士来完成。这样,开发者就可能开发出比较成功的文献检索服务系统,而数据库中的文本也由于专业人士的加入而能大大提高文本的准确率,然后合成为一个规模较大的公共古典文献数据库。当然,输入和整理古典文献文本可以采用投标(或以申报项目形式)来确定,规定统一格式,要求保证文本的正确率达到一定比例,完成后再分别导入这一公共古典文献数据库中;经过若干年努力,最终能形成一个规模巨大、适应于学术研究的公共古典文献数据库。我想,采取这种措施不但节省了大量重复投资,真正做到人尽其才,物尽其用,而且一旦建立起这个规模巨大的公共古典文献数据库,可以解决了目前数据库泛滥、文本错误太多、重复劳动等弊病,而且真正能做到广大学者对古典资源“共享共有”。

在此基础上,各个开发商可以力求开发学者们个性化的文献检索服务系统,它无须考虑文献文本内容,但必须功能强大、操作方便,并与公共古典文献数据库完全兼容,学者们通过“购买”文本或其它方式来方便地组建自己的数据库,这样或许会给学术研究带来真正的方便。

还须补充的是,我国的古典文献中有大量表格与图片,而由于技术原因,目前所有古典文献数据库都没有导入原著的表格与图片,极个别数据库有少量图片也是不能检索,这是目前众多古典文献数据库的重大失误之一。其实只要真正化力气去探索,这个问题是不难解决的。因为笔者曾作过设计并反复试验,只要设计合理,图片与表格不但可以导入数据库,而且都是可以在数据库中进行检索。

其三,加速确定字库方案,以利数据库健康发展。当然,要真正解决公共古典文献数据库问题,还必须解决字库问题。目前,国家虽然组织专家在论证有关字库问题,然而由于进程不快,远远落后于当今计算机技术发展的需要。按照笔者的看法,应该建立一个以Unicode字库为基础的、适应汉语古籍需要的、并与国际接轨的真正有中国特色的字库。这就需要抓紧工作,迅速落实扩展字库B的内码。同时根据我国汉字的具体特点,对自定义区域的6400字的内码配置也应该有所规范,这样才能使汉语字库统一问题落实到实处。如果真能做到如此,那么就能真正解决目前古典文献数据库之间字库互不兼容问题。

与字库相关联的是字体问题。古典文献数据库应该考虑到古代文献对文字的特殊需要,笔者以为凡是古代文献数据库中的文本应该保留繁体字,以防繁简不分而导致文义偏差。就目前计算机技术来说,解决这一问题是毫无困难的。其实用繁体字输入文本早已不是问题,而扫描古籍文本再转换成文字的技术也十分成熟,如北京书同文公司的“数码翰林”OCR识别系统,应该说是极有价值的识别软件,对绝大多数繁体文字能够正确识别。如果能再进一步加以改进,使扩充字库数量并与Unicode字库兼容,那么古代文献的文字识别问题是可以得到解决的。应该强调的是,古代文献以繁体字导入数据库,但应该允许在数据库中自由进行繁简转换,换句话说,若需要使用繁体字时,文本可以保留繁体字,而需要简体时,可以十分方便地转换成简体,这样就适应用户对繁简体的不同需要了。

其四,彻底解决古典文献版权问题。这是困挠计算机古典文献数据库建设的重要难题之一。自然,这一问题要真正得到落实确实存在相当困难的,因为版权保护工作任重道远!不过,即使困难再大,古籍文献数据化的发展的潮流是不可能停止的。笔者以为,有关出版社在维护自身法定的版权权益的前提下,应该从大局出发,在收取一定数量的报酬前提下,允许制作有关古典文献的数据库,以利学术研究的发展。至于报酬多少可以也应该实事求是地酌情商定,国家有关部门应该主动与那些出版社协调,亦可将目前大量分散投入到各课题中的资金中抽出部分来补偿有关出版社,双赢互利,以求突破版权瓶颈,早日解决这一棘手的问题。

与此相关的是古典文献电子文本的版权问题,这也是个极难处理的问题。因为用户若贪图小利,版权意识不强,不愿化费代价使用电子文本,就容易产生“盗版”问题,如此就使得制作古典文献电子文本者的正当利益大受损失。按笔者设想,如果真正能够由国家有关部门主管古典文献数据库建设工作,那么就可以设想建立公共古典文献数据库规定导入数据库的文献文本都给予一个“统一编号”,没有统一编号的文献就不能直接导入公共古典文献数据库和个人使用的文献检索服务系统中,也就是说,个人使用古典文献电子文献必须化费一定的代价才能取得使用权,这样就可以保证制作古典文献电子文本者的一定收益,防止版权意识不强者侵权使用。同时由于古典文献电子文本都有了统一编号,那么也就可以防止某一具体文献文本重复录入的问题。即使有部分重复,古典文献电子文本也可以在用户选择过程中优胜劣汰。

数据库技术论文篇8

ODBC(Open DataBase Connectivity,开放数据库连接)是微软开放服务结构中有关数据库的一个组成部分。它建立了一组规范,并提供了一组应用程序调用接口。用这样一组接口建立的应用程序,对数据库的操作不依赖于任何数据库管理系统,不直接与任何DBMS打交道,由此可实现应用程序对不同DBMS的共享。数据库操作的“数据源”对应用程序是透明的,所有的数据库操作由对应DBMS的ODBC驱动程序(ODBC Driver)完成。有了ODBC驱动程序,数据源就变得十分广泛,它可以是本机的某种数据库格式的文件(如本机DOS目录下的Access文

件*.mdb),也可以是远程数据库文件(如Microsoft SQL Server);它可以是目前已知的某种DBMS格式,也可以是一种全新的数据库格式。总之,它取决于提供了什么数据库类型的驱动程序。

Visual C++中的ODBC主要是实现基于Windows的关系数据库的应用的共享。

二、ODBC管理器

在ODBC中,数据源是一个重要的概念,它是数据库位置和数据库类型等连接信息的总和。数据源在使用前必须通过ODBC管理器(Administrator)进行登录。在登录数据源时,要搞清数据源名(Datasource name)、数据库文件名(Database name)和数据表格名(Table name)这三者的概念和相互关系:数据源实际是一种数据连接的抽象,数据源名是登录时赋予的“连接”的名称,以供应用程序使用,至于该数据源下连接的是哪一个数据库,则由数据库文件名指出(如Access 2.0 for MS Offics中的.mdb文件);一个数据库文件中可以包括若干个数据表格(table)和其他内容。在关系@@09A05900.GIF;图1 ODBC层次关系图数据库中,数据是以二维表格的方式存在于数据库@@文件中,应用程序最终的操作目标即是这些表格中的行(row记录)和列(columns字段)数据。对于foxprow数据源,数据库文件名是“路径名”,而该路径下的所有数据文件(*.dbf)都属于该“数据库文件”名下的数据表格(table)。

ODBC管理器被装在Control Panel里(ODBCINST.CPL)。通过该工具可以增添、修改或删除数据源,也用来增添、删除ODBC驱动程序,ODBC管理器把数据源和它们的连接信息保存在ODBC.INI、ODBCINST.INI和ODBCISAM.INI中。当需要共享应用程序时,只需按新的数据文件的类型和位置重新登录即可。

三、ODBC应用程序接口

ODBC API是一组标准的ODBC函数库,除了一般的数据库操作函数外,还包括一组函数(如SQLExec或SQLExecdirect)能够内嵌标准SQL查询语句。SQL(Structured Query Language结构化查询语言)是一种存取关系型数据库的标准语言,能够定义、查询、修改和控制数据,简单的语句能够作用于整个数据表格,具有很强的功能。

同Windows 3.1 SDK中API类似,ODBC API也是基于句柄(handle)进行操作的。API函数按功能可分为以下几类:

·数据源连接函数,设置/获取有关信息的函数;

·准备/提交执行SQL查询语句的函数和获得数据的函数;

·终止函数和异常处理函数。

上述函数的顺序也表示了进行数据库操作的一般顺序。两个问题需要特别说明,一是数据类型问题:数据源中的数据所具有的数据类型称为SQL数据类型,这些数据类型在其数据源中可能比较特殊,不一定和ODBC SQL数据类型存储方式一致,驱动程序把这些数据类型同ODBC SQL数据类型进行相互转换,每一个ODBC SQL数据类型都相当于一个ODBC C语言数据类型;二是函数的调用级别问题,并不是每一个ODBC驱动程序都支持所有的ODBC API函数调用,在应用程序中,可以调用有关函数获取驱动程序以支持层次方面的信息。

四、ODBC应用编程

在Visual C++中,MFC (Microsoft Foundation Class基本类库)是经过对Windows应用程序中各个部件进行类的抽象而建立的一组预定义的类,如窗口基类(CWnd)、各种窗口派生类等等,这些类在应用程序中可直接使用,不需要重新定义。在MFC中,也为ODBC预定义了几个类,其中主要的是数据库类(CDatabase)和记录集合类(CRecoredset)。这两个类既有联系又有区别,在应用程序中,可以分别使用,也可以同时使用,每一类也可以同时存在多个对象。CDatabase的每一个对象代表了一个数据源的连接,CRecordset的每一个对象代表了从一

个数据表中按预定的查询条件获得的记录的集合,一般说来,前者适宜于对数据源下的某个数据表格进行整体操作,后者用于对所选的记录集合进行处理。

同Windows类与SDK API 函数的关系一样,CDatabase类与ODBC API函数也有类似的关系,但CDatabase类中并不包含所有的ODBC API函数,大部分操作功能仍须直接调用ODBC API函数,如目录功能函数,用于获得数据源下的数据表格信息,如表格名,字段名等。

在应用编程时,一般使用CDatabase和CRecordset的派生类。假设派生类分别为CUserdb和CUserset,而在应用类CUserClass中,使用了一个CUserdb对象(m-db)和一个Cuserset对象(m-recset),图2给出了用户应用类与ODBC类的相互关系示意图。

@@09A05901.GIF;图2 CDatabase CRecordset类与应用类及数据源关系图@@

1.m-db连接数据源

m-db在完成定义构造后,要调用CDatabase的打开(Open)函数以进行数据源的实际连接:

m-db.Open(lpszDSN, bExclusive, bReadOnly, lpszConnect);

打开函数需要输入四个参数。lpszDSN:要连接的数据源的名字,如果lpszDSN=NULL且lpszConnect中也没有指明数据源名,则该调用会自动出现一个对话框列出所有可用的数据源(名),让用户选择。bExclusive:只支持“假”(False)值,表示为共享(share)方式连接。因此,应用程序在运行前,一定要装入share.exe或在Windows的system.ini中装入vshare.386。 ReadOnly:指明数据源操作方式是“只读”还是可以修改。lpszConnect: 指明连接字符串,包括数据源名、用户标识码、口令等信息。该字符串必须以“ODBC;”开头,表示该连接是与一个ODBC数据源的连接(考虑以后版本支持非ODBC数据源)。

m-db打开后,其指针可以传给m-recset作为其数据源。m-db关闭后,将关闭所有CRecordset对它的连接,m-db也可以重新打开。

2.m-db操作数据

数据源打开后,即可对数据库文件中的数据表格进行操作,操作以调用SQL语句方式进行,可直接通过ODBC API函数,或者CDatabase类成员函数ExecuteSQL。数据表名在SQL语句中指定,如下语句则在所在的数据源中的clerk表中插入一个记录,记录的name字段值为"chen"。

m-db.ExecuteSQL("insert into clerk(name) value(’chen’)");3.m-recset连接数据m-recset在构造时,可传入一个CDatabase对象指针,作为m-recset的数据源,当为NULL时,必须重载CRecordset的函数GetDefaultConnect,以提供数据源连接字符串(相当于m-db.Open中的lpszConnect)。如下则表示连接名为COMPANY的数据源(当传入了合法的CDatabase对象指针时,该函数将不被调用)。

CString CUserset::GetDefaultConnect()

{

return"ODBC;DSN=COMPANY;";

}4.m-recset选取记录和字段

m-recset在调用打开函数时,即获得了符合条件的一组记录,条件语句在Open函数中的lpszSQL中给出,如果lpszSQL为NULL,则必须重载CRecordset的函数以提供该语句。该语句是一个SELECT语句,带或不带where和order by子句(如果不带,where和Order by的条件也可在CRecordset的两个预定义成员变量m-strFilter和m-strSort中给出)。lpszSQL也可以只是一个数据表名(table-name),也可以是对内嵌在数据库文件中的查询程序的调用语句。所选择的一系列字段名,在成员函数DoFieldExchange中由一系列RFX-函数指定。RFX-(Record Field Exchange)函数,使字段和成员变量一一建立类型对应关系。另外,m-strFilter中也可以带变量参数(用"?"表示,如"fieldl>=? AND field2<=?"),参数与成员变量的对应关系也在DoFieldExchange中由RFX-函数指定(串中的"?"将被参数变量值逐一替换)。

void CUserset::DoFieldExchange(CFieldExchange* pFX)

{

pFX->SetFieldType(CFieldExchange::outputColumn);

/*以下为字段连接 */

RFX-???(pFX,"field1",m-var1);

RFX-???(pFX,"field2",m-var2);

...

RFX-???(pFX,"fieldn",m-varn);

pFX->SetFieldType(CFieldExchange::param);

/*以下为参数连接*/

RFX-???(pFX,field1,m-param1);

RFX-???(pFX,field2,m-param2);

...

}其中,???为ODBC SQL数据类型名,如RFX-Double,RFX-Text等。

综合上述,选取记录和字段实际是由下列语句完成:

SELECT rfx-field-list FROM table-name[WHERE m-strFilter][ORDER BY m-strSort]

字段变量和参数变量的个数一定要在调用打开函数前(如构造函数中)准确地赋值给成员变量m-nFields和m-nParams。m-recset在打开后的任何时候调用Requery()函数,将根据新的查询条件(例如修改了参数变量值)重新选取记录。

5.m-recset操作数据

记录集合生成后,其当前记录的各字段值被保存在前述的各字段变量中,如果调用CRecordset的滚动(scroll)函数,如MoveFirst(),MoveNext(),MovePrev(),MoveLast()等,字段变量的值将自动跟随“当前”记录的位置的变化而变化。IsBOF(),IsEOF()用于判别是否移动到记录的头或尾。

数据操作主要包括删除(Delete),添加(AddNew)和更改(Edit),一般流程为:

if(m-recset.CanUpdate()) /*是否允许修改*/

{

if (m-db.CanTransact()) /*是否支持“批”处理*/

{

m-db.BeginTrans();

m-recset.AddNew();

/* 修改字段变量值 */

. . .

m-recset.Update();

mitTrans();

if(catch error)

m-db.RollBack();

}

}

对于AddNew和Edit,修改字段变量后一定要调用函数Update(),否则更新将丢失,而Delete操作则不必进行字段值修改和调用Update()。

上述的CDatabase的四个函数是ODBC为保证数据操作的可靠性而提供的“批”处理函数,即在BeginTrans和CommitTrans之间的数据修改如果出现任何异常,可通过函数RoolBack来恢复所做的修改。

在多用户系统使用时,每一个数据源可以被多个用户的多个任务连接,不同的任务可同时修改相同的数据源。ODBC提供了两种数据表更新的同步机制(在m-recset.Open函数中指定),“静态”的(snapshot)和动态的(dynaset)。前者是一组静态的记录集合,当建立后不会改变,除了反应自己的添加/删除外,不反应别的用户的修改,除非调用了Requery重新建立。后者是一组动态的记录集合,自己或别的用户所作的修改随时反应到集合中来(当然也可用Requery重建),以保持记录与数据源的同步。在应用中,应根据需要确定使用哪一种方式。

数据库技术论文篇9

2对数据仓库模型设计

数据仓库作为一个面向主题的、集成的系统,其属于动态变换。因此,在对整体进行设计之后,必须对数据仓库的边界和功能进行定义。本文主要从税收的收入、税收监控信息和队伍建设入手,因此,将功能划分为以下部分,具体如图2.

3纳税评估模型构建

3.1纳税评估概述以及流程设计在完成对监控系统的统一设计之后,可实现对数据的收集和分析。而所谓的纳税评估是指税务机关通过纳税人提交的申报资料,日常的征管信息等进行综合的审核分析,并及时对税务缴纳进行评定和处理。而为了设计的方便,我们采用企业税负率这个指标来对模型进行设计。因为企业税负率在会计中的定义是指企业应缴纳的税费和企业的应税销售收入的比率。纳税评估的流程设计具体如图3所示。

3.2数据挖掘技术算法的确定数据挖掘是针对特定的数据而进行的分析和处理的一个过程。因此,选择不同的数据挖掘技术,其根据是对所选取的结果的挖掘。本文选用Apriori算法,来实现对企业税负率和企业违规等之间的关联挖掘。APrfori算法是有R.Agrawal等人在上个世纪90年代提出的,其主要用在大型数据库上的数据快速挖掘。其主要采用逐层迭代的搜索方式,使用候选项集来找频繁项集的过程。其基本的思路是首先找出所有频繁1-项集,然后用找出频繁2-项集,在利用找出,这样反复找到的K,在第K+1项集是不能找到的过程,并且在这其中利用最小支持度进行筛选,再通过最小置信度与频繁项集产生的关联规则。在选择上述的数据挖掘算法之后,对其参数进行设置。所谓的参数主要是指min_conf与min_sup。并通过模型对进行挖掘。

3.3算法的验证通过模型计算我们可以得出以下的结果:批发行业中为退税企业并且其税负率小于2.5的主要集中在类1;退税企业并且其税负率大于2.5主要集中在类2;不是退税企业and税负率小于2.5的企业主要分布在类3;不是退税企业and税负率大于2.5的企业主要分布在类4.同时我们采用收集不同行业样本,对评估模型进行验证,从而得出其平均的阀值为2.57,误差为2.8%说明评估模型有效。

数据库技术论文篇10

1、综合信息的查询

目前,随着工具软件的发展和广泛采用,使数据库应用系统的开发如虎添翼,其中PowerBuilder以其独特的数据窗口(DataWindow)倍受欢迎。

PowerBuider是美国著名的数据库应用开发工具生产厂家Powersoft公司于1991年6月推出的功能强大、性能优异的开发工具,它是一种面向对象的、具有可视图形界面的、快速的交互开发工具。智能化的数据窗口对象是其精华所在。利用此对象可以操作关系数据库的数据而无需写入SQL语句,即可以直接检索、更新和用多种形式表现数据源中的数据。但要注意,必须使数据窗口成为窗口(Window)下数据窗口控制的一个连接对象,数据窗口才能使用户在应用执行期间访问数据库中的数据。

利用PowerBuilder提供的内部查询机制,我们即可以让数据窗口作为查询条件的输入,又可以让该数据窗口作为查询结果的输出,这样就可以使数据窗口中的所有数据项进行自由组合的查询。例如:在窗口W_que上建立两个数据窗口控制dw_1和dw_2,分别连接两个数据窗口对象dw_que1与dw_que2,其中dw_1用于输入查询条件,而dw_2用于显示满足查询条件的所有元组。事实上条件的输入及元组的显示完全可以在一个数据窗口中实现,考虑到这两种操作的差别(例:条件输入可编辑,而元组显示不可编辑;条件输入可为某一范围,而元组显示仅为满足条件的所有纪录……)将其用两个数据窗口控制来实现。这就要求dw_2与dw_1数据共享,即要求dw_que1与dw_que2两数据窗口的数据源完全相同。

用这种方法实现查询优点突出,例:通过设置数据窗口中对应列的编辑风格(EditStyles)为相应的下拉式数据窗口(DropDownDataWindow),使显示的元组文字化。注意,这要事先建好下拉式数据窗口。设置数据窗口中对应列的编辑风格同样可满足其它显示需要。利用数据窗口的风格特点:查询表的列宽、列序可自由改变,甚至可以覆盖掉一些列,以达到更满足查询显示的需要。综合查询的信息来自多个表,改变数据窗口的数据源,采用多表连接的数据源即可实现。但是如我们问题的描述,如果我们需要的查询项随机地来自这43张表中的数据项,显示项也是随机地。这种任意条件的组合,可选输出项的显示称为动态查询(DynamicQuery)依然采用上述方法,数据窗口dw_que1与dw_que2的数据源将是这43张表的连接,先不说效率问题,单从这426个项中输入查询条件,又显示这426个项,就使人敬而远之。因为,在每一次查询前,都不了解此次查询的要求是什么,这样,每张表中的每一个数据项都缺一不可;另一方面,每一次的查询,一旦查询条件确定、显示条目也确定后,我们会发现,每一次有意义的查询并不是需要全部的43张表,换言之,每一次查询没有必要将43张表全部连结,而应只连接那些被选中数据项所在的表,即数据源是动态产生的。由于数据源不确定,数据窗口就无法设计,动态查询无法用这种方法实现。

2、计算机动态查询的实现

在某些实际的应用系统开发中,由于用户在开发前提不出查询的需求,而在系统运行中希望能够对所有的数据项任意组合进行查询,以满足来自多方的需求,实现动态地查询(即随机地从43张表中选择数据项进行组合作为查询条件并任意地选择数据项作为显示条目)。对于此类查询的实现要利用PowerBuilder通过编程的方式在运行时动态地创建数据窗口,并动态地控制数据窗口。

动态地创建一个数据窗口,应用程序需要执行下列任务:

•动态地构造SQL语句。

•用符合数据窗口语法的字符串,为现在的数据窗口控制创建一个数据窗口对象。具体实现如下:超级秘书网

2.1动态地生成SQL语句,根据SQL的语法:SELECTstringaFROMstringbWHEREstringc也就是动态地生成stringa,stringb,stringc.由用户输入要显示的列,一旦输入完毕,列名就随之确定,将所有列名拼成一个“串”,中间用“,”分隔,形如“columm1,column2,column3,...,columnr”,则动态地生成stringa;同样由用户输入查询条件,包括相应的列、满足的条件或范围、逻辑关系等,将这些条件拚成一个串,即为stringc,显然,所有的列名都确定了,他们所在的表名也确定了,按照stringb的语法规则即可构造。

注意:上面的stringc由两部分(表间关系stringc1及查询条件stringc2)组成;表名串stringb与表间关系stringc1、查询条件stringc2及显示条目stringa均有关。

在实现的过程中:为贴近实际应用,习惯上,先输入查询条件,再输入显示条目。即在输入查询条件后,生成strinc2,stringb,stringc1;然后,再在输入显示条目后生成stringa,并修改stringc1,stringb。最后形成SQL语法:

str="select"+stringa+"from"+stringb+"where"+stringcl+stringc2

2.2在现在的事物对象里利用相关的SyntaxFromSQL()函数生成符合数据窗口语法的字符串:

exp=syntaxfromsq1(sq1ca,str,strsty,error)生成数据窗口的源代码

其中:strsty为数据窗口的显示风格,例:

strsty="style(type=grid)datawindow(units=lcolor=12632256)text(font.face=''''system'''')"

2.3创建数据窗口对象

dw_que.create(exp)

这样就实现了用户要求的随机查询。

在真实系统中,用户在输入查询条件时希望通过选项方式录入查询信息,由于库表中存放的大量信息为代码,这就需要在程序中先把录入的文字信息转化成相应的代码再连接到查询条件中。为简化输入,提高准确性,可采用代码输入,即动态地嵌套下拉式数据窗口。在显示查询结果的数据窗口中,事先不能嵌套下拉式数据窗口,可预先做一个函数,在程序运行中根据所选的列把代码转化成所对应的汉字显示,这样更完善了用户要求的随机查询。

数据库技术论文篇11

一、研究背景

会议文献是指在各类学术会议上宣读的论文、论述、总结等形式的文献,包括会议前参加会议者预先提交的论文文摘、在会议上宣读或散发的论文、会上讨论的问题、交流的经验和情况等经整理编辑加工而成的正式出版物[1]。文献是进行学术交流的重要知识资源,大多数会议文献都具有独到的学术见解和新颖的学术观点,学术质量较高。许多会议文献还公布科研人员取得的新进展与新成果,并提出新的研究课题和新的研究设想。因此,会议文献往往具有专业性强、学术水平高、内容新颖、信息量大、可靠性强、出版速度快及发行方式灵活等特点[2]。

会议论文作为仅次于科技报告的十大情报源之一,代表了一个国家或地区在某一时期,在相关学术领域内取得的最高学术水平,是进行科学研究的文献信息保障,具有较高的学术价值和情报价值,是推动人类社会发展、科技进步的必备文献之一。

近年来,随着数字化加工、处理技术及信息检索技术的迅猛发展,各大图书馆以及数据库商开始将会议论文数字化,以期为受众提供更加便捷的数据服务。目前,国内综合性学术会议论文数据库主要有三个:CNKI的 《中国重要会议论文全文数据库》、万方数据的《中国学术会议文献数据库》、上海图书馆的《全国学术会议篇名数据库》。

本文通过对这三个数据库的统计调查,对国内主要学术会议论文数据库的建设和利用状况进行了初步分析,特别关注了所面临的共同问题,分析其产生原因并给出了相应对策与展望。

二、国内主要学术会议论文数据库开发所处的环境

(一)政治环境

近年来,政府在工作报告中指出,要“引导科研机构、高等院校的科研力量为企业研发中心服务,提高原始创新能力”。坚定不移地实施“国家知识产权战略”“倡导学术诚信、鼓励独立思考、保障学术自由、弘扬科学精神”。在政策的保障和推动下,学界的主动性明显增强,学术交流活动日见活跃,呈现出蓬勃发展的态势。

(二)经济环境

目前,整个市场经济正步入转型升级的阶段,各领域之间的渗透交融越来越明显。科研人员、教育界人士、政府机构对学术会议转化的成果需求日益旺盛,愿望日益迫切。传统图书情报机构对于会议文献的揭示已经难以满足受众的需求,需要寻求更为高效、精确的揭示途径和呈现模式。

(三)社会环境

《中国重要会议论文全文数据库》和《中国学术会议文献数据库》的总部在北京,《全国学术会议篇名数据库》总部在上海。京沪两地历史悠久,文化积淀深厚,在上海能感受到海纳百川的思想碰撞,北京更是汇聚了大量优质的教育文化资源,国内高质量的学术会议有很大部分都选择在这两地召开,办会条件成熟度高,具备明显的资源优势。

(四)技术环境

数字化加工技术的进步,互联网技术的快速发展为会议文献的揭示和服务提供了良好的支持,数据库开发者得以运用这些成熟的技术,来构建会议论文资源,成为采集、加工、保存、服务的技术平台。并通过互联网向全国乃至全世界提供学术会议论文数据服务,实现资源共享。

三、学术会议论文数据库建设和利用的现状

《全国学术会议篇名数据库》由上海图书馆上海科技情报所制作。该库建库时间早,早在1958年零星的资料收集就已出现。该数据库正式始建于1982年,最初以微缩胶片形式全文,1998年开始建立光盘及网络版数据库。《中国学术会议文献数据库》由北京万方数据有限公司制作,始于1983年,于1995年建光盘库,1997年通过Chinainfo出网络版文摘库,2002年网络版全文库。万方数据有限公司成立于1993年,是一家以中国科技信息研究所为基础,直属科技部的股份制高新技术有限公司。《中国重要会议论文全文数据库》由清华同方知网(北京)技术有限公司制作,教育部主管,该数据库始于1999年,能实现多库并行检索,具有强大的综合优势。(参见表1)

(一)会议论文收录量

万方《中国学术会议文献数据库》以250多万篇的数据量独占鳌头,CNKI《中国重要会议论文全文数据库》以200多万篇紧随其后,上图《全国学术会议篇名数据库》为120万篇,数据量较少。

(二)z索功能比较

基本的字段检索、高级检索和专业检索功能均无太大差异。万方和CNKI 均提供相似文献推荐服务,万方还提供与互动百科的词条链接服务;CNKI的分类导航、论文集导航和会议导航均做得较为出色,使用体验较佳。

(三)全文服务

万方和CNKI 均提供会议论文全文下载,会议论文索引免费获取,上图库仅提供篇名服务,需线下联系以获取全文。

学科导航(大类数量) 基本按照中图法,A大类不单列 分为十大专辑:基础科学、工程科技Ⅰ、工程科技Ⅱ、农业科技、医药卫生科技、哲学与人文科学、社会科学Ⅰ、社会科学Ⅱ、信息科技、经济与管理科学。十专辑下又分为168个专题。 无

(四)数据库收录会议情况抽样比较

通过对三个数据库5年内的收录数据进行统计,在此基础上对相关类目进行抽样比较分析得出如下结果。

(五)会议论文收录情况比较(参见表2)

2008~2012年,万方收录论文集12593种,年均2546个会议;CNKI收录7897种,年均1379个会议;上图收录3076种,年均613个会议。

(六)会议论文收录学科分布情况比较

万方会议论文收录科技类占总量的83.58%,其中工业技术比例最大,占39.07%;CNKI科技类占总量的73.80%,其中工业技术占30.00%;上图科技类占总量的68.40%,工业技术占30.92%。万方会议论文科技类占比是三个库中最高的,工业技术也是三个库占比最高的大类。上图会议论文中社科类占比为三个库中最高。

(七)收录会议重复情况比较

从5年内的抽样统计结果看,万方收录的会议论文集数量与上图收录的论文集数量重复率在大约是上图的50%。同时,万方和CNKI的重复量也基本上占CNKI的二分之一。

从上述调研及统计中发现,在建设力度方面,公益机构(上图)对会议文献数字资源的建设力度并不大,开展的服务力度非常有限,利用率不高;在加工深度方面,仅仅停留在对文献的数字化扫描的数字化还原层面,远未达到资源的深度揭示。相比较公益机构的迟缓,嗅觉灵敏的商业机构却在资金技术人力方面加大投入,采用全文扫描识别技术,力图深度揭示文献内容的内在关联,为受众提供更加人性化、个性化的服务。

四、存在的问题与对策

通过以上分析比较,我们发现,目前三个国内主要会议论文数据库之间数据体量差异较大,有一定的重复率。同时,因为数据库制作者的不同,制作标准不一,对同一种会议文献,不同的单位可能按不同的文献类型来处理,规范程度也不尽如人意[3]。由此影响了会议论文数据的查全率和查准率,给受众的正常使用带来诸多不便。学术会议是新研究成果的重要场所。据统计,有近1/3的学术成果是在相关会议上首次公布的;学术会议对本学科领域重大事件的首次报道率也是最高的。可以这么说,只参考期刊文献,不参考会议文献,科研的开创性将不复存在。因此,各大数据库应以读者的利益为出发点,达成共识,分工协作,不断提高兼容性,才能更好地为读者提供优质服务。

(一)增进沟通,统筹规划

会议文献数量巨大,任何一家机构都不可能独立收全所有的学术会议文献。这就首先需要全国各文献情报机构精诚协作,整合分布在各高校图书馆、公共图书馆、情报机构、数据公司中的会议文献资源,将资源进行充分的梳理、组合;其次要借鉴运作模式相对成熟的数据公司的力量,依托公益机构专业的分类标引手段,将公众资源和商业力量进行统一的运作规划,联合共建从而合理分配使用社会资源。如此,必然可以减少重复建设,从而提供更丰富优质的服务。

(二)规范制作,深度揭示

在数据库建设过程中,有必要建立规范的会议文献数据库,将不同出版形式的会议文献统一纳入该数据库,按照会议文献的特征和著录规范进行著录。同时,对会议文献的开发不能停留在全文提供的层面,应认真调研,做好深层次开发的准备,以深度标引为基础,提高资源揭示的深度与内在关联性,进一步完善会议文献的数字化建设工作。在服务平台相关功能上,论文数据的精准定位、深度标引以及全文的可检索途径已成为服务平台不可或缺的功能之一,必须充分考虑并挖掘这一功能。

(三)丰富内容,深化服

新一代的会议论文服务平台,不应当仅仅是提供论文检索的数据库,更应当以满足用户多样化需求为着力点,将服务延伸至会前、会中和会后。从会议预告到相关新闻,从篇目揭示到文献传递,从单向提供会议信息到支持用户相关信息,资源共享、开放协作将是未来会议文献数据库的发展趋势。

【参考文献】

数据库技术论文篇12

中图分类号:TP311.13

随着科学技术的飞速进步与发展,计算机技术已经发展到了一个新的阶段。各类信息极度丰富,数字化信息技术和网络技术高速发达,使得在计算机应用已经普及并不断发展的今天,掌握计算机基本技术和具备应用计算机技术的能力是当今人们必须具备的基本素质之一。而计算机数据库技术是计算机科学技术中发展最快、应用最广的技术之一,它已成为计算机信息系统与应用系统技术的核心和基础,本文就计算机数据库管理技术中存在的问题进行了分析与讨论。

1 计算机数据库管理技术存在的问题

计算机数据库系统是实现数据存储、组织和管理的有效形式,而计算机数据库管理可以实现数据库的建立和使用,是数据库系统安全使用的保障。但是,在使用数据库的过程中其安全性至关重要,在一个网络化和信息化的系统中,数据很容易被用户非法越权使用、盗取、更改甚至破坏险,无论发生哪一项,都将严重损害数据库的安全性并造成严重的后果。所以,保证数据库的安全使用是数据库管理技术中至关重要的问题。下面从三方面阐述计算机数据库系统的安全问题。

1.1 操作系统的问题

数据库操作系统的主要风险来源之一就是计算机操作系统,计算机病毒和木马程序、服务器操作系统后门以及操作系统和数据库系统的关联方面都是操作系统中存在风险的地方。

第一,病毒是最常见的风险,由于操作不当可能会导致木马程序的产生,这种病毒会对数据库的安全性构成极大的威胁。木马程序可能会修改计算机程序的密码,这样系统的新密码可以随时被入侵者盗走,进而篡改数据库信息,大大地破坏了数据库的信息内容。

第二,我们在设置操作系统时,不可避免地会在在服务器操作系统中留有一个后门,这是伴随着数据库系统的特征参数设置的,它使得数据库的信息通过这个途径可以被电脑黑客们盗取,极大程度地破坏了数据库的安全性。

第三,数据库系统和操作系统有着很大的关联性,因为硬件设备和操作系统所提供的环境在一定程度上决定了数据库系统的安全性,所以一旦问题出现在操作系统环节上,例如操作系统允许直接存取数据库文件,这样子无论数据库管理系统采用怎样的措施都无法保证数据库的安全。

1.2 管理方面的问题

一般网络用户只注意获得网络资源的时候网络是否方便、高效,这样的情况下当使用数据库管理系统的用户缺少网络信息安全意识时,也就是保密意识薄弱,且对实际存在的风险与后果不能够正确认识,从而忽视了网络安全问题。这样子一旦安全管理方面出现问题,又或者安全防范措施落实的不够充分,就会发生安全事件,都是管理工作失职的表现。

1.3 数据库系统自身的问题

随着时代的进步和发展,关系数据库的特征已经取得了一定的发展与应用,近十几年已广泛被人们所使用,各方面技术已趋于成熟。但是在如今的计算机时代,存在的网络信息安全问题与十几年已经不可同日而语,如今的网络操作环境和应用系统对于数据库安全提出了更高的要求。显然,关系数据库系统所具备的安全特征不够充分,系统的安全特征还不能得到有效发挥与实现,这也是数据库系统中不成熟的一部分。

2 计算机数据库管理技术分析

本文从以下三个方面对数据库管理技术进行了技术分析,来解决数据库管理系统存在的问题。

2.1 加密技术

现今数据库里存储着重要的机密数据,一些网络黑客却出于特殊目的,通过非常规手段非法窃取他人的用户名和密码,越权打开其偷取数据库文件和篡改信息,这样尤为重要的机密文件与信息就会外露,造成不必要的损失进而可能会导致严重的后果发生。针对上述情况,可以采用的数据库技术―加密技术,通过对重要数据的加密处理,就可以保护数据库里存储的数据。当一些重要的信息数据存储在数据库后,加密技术可以阻止数据在未授权下被访问,这样子就算数据库管理系统崩溃了,数据的安全性也不会受到影响与威胁。例如,一些重要文件如商业机密、金融数据或是网络游戏的虚拟财产等,在数据库系统中对它们进行加密,这样就能防止数据在未授权的情况下被访问,哪怕整个系统崩溃了,也不用担心其安全性,因为加密技术在保护着数据的安全致使不会被非法盗取。

2.2 存取管理技术

存取管理技术是数据库技术的重要组成部分,包括访问控制技术和用户认证技术两大部分。其中访问控制技术是指对已经进入系统的用户的控制,涵盖了数据的修改控制和浏览控制,在计算机系统处理功能方面对数据进行保护,在最前方保护数据的安全性。数据库管理系统一般采用两种方法进行访问控制:第一种是将数据库系统的使用权限交给用户,一般使用的是基于角色的访问控制,以达到加强访问控制和身份认证的效果;第二种是利用数据功能模块设置用户使用权限,并且针对不同的用户设置不同的使用权限。而用户认证技术相对访问控制技术而言是由系统提供的最外层安全保护方式,来达到是阻止用户的越权访问的目的,因此系统必须在用户每次请求进入数据库前对用户身份进行合法身份的识别和认证以确保安全性。目前,最常用的方法是设置口令法,近几年也发展出像指纹、虹膜、智能卡认证技术等高技术身份验证方法,达到了更高的安全标准。

2.3 备份与恢复技术

计算机系统发生故障是不可避免的,经常会损坏或丢失数据,这样以来提前做好数据库备份,即使系统突然发生故障或崩溃,数据库中的文件与信息也不会遭到破坏,数据库还是可以完整地恢复到原来的水平和状态。数据库常用的备份方法主要有三种:一是逻辑备份,即通过软件实现原始数据的镜像拷贝;二是静态备份,即在结束数据库系统时将其备份;三是动态备份,即在数据库系统使用过程中将其备份。

4.结论

数据库管理技术如今已经得到了广泛的发展与应用,几乎涉及社会各行各业,为人们的生活和工作带来了很大的方便,与此同时,数据库管理技术也有着它的不成熟性正待提高与改善,数据库系统安全问题一直是数据库管理技术最为重要的核心问题,是计算机数据库管理技术亟待重点解决与提高的地方。本文对数据库管理技术的安全问题和应对技术进行了分析与讨论,相信不久的将来,计算机数据库技术将会更加成熟与完善,为人们带来更多的便利与服务。

参考文献

友情链接