时间：2022-03-19 20:50:46
导语：在数据库技术论文的撰写旅程中，学习并吸收他人佳作的精髓是一条宝贵的路径，好期刊汇集了九篇优秀范文，愿这些内容能够启发您的创作灵感，引领您探索更多的创作可能。
目前，著名数据库管理系统有Oracle、Sybase、Informix、Microsoft、MicrosoftAccess、VisualFoxPro等,这些产品各以自己特有的功能，在数据库市场上占有一席之地。下面简要介绍几种常用的数据库管理系统。
1.Oracle。Oracle是一个最早商品化的关系型数据库管理系统，也是应用广泛、功能强大的数据库管理系统。Oracle作为一个通用的数据库管理系统，不仅具有完整的数据管理功能，还是一个分布式数据库系统，支持各种分布式功能。Oracle使用PL/SQL语言执行各种操作，具有可开放性、可移植性、可伸缩性等功能。
2.Sybase。最新版本的SybaseAdaptiveServer与以前的版本相比，具有更丰富的功能设置，Sybase比较强大的地方在于它对资源的低占有率上。在这一方面，Sybase15还引入了新的“专利查询过程技术”，显示了增强的性能和降低的硬件资源消耗。
3.MicrosoftSQLServer。MicrosoftSQLServer是一种典型的关系型数据库管理系统，可以在许多操作系统上运行，它使用Transact-SQL语言完成数据操作。由于MicrosoftSQLServer是开放式的系统，其它系统可以与它进行完好的交互操作。
4.MicrosoftOffice。作为MicrosoftOffice组件之一的MicrosoftAccess是在Windows环境下非常流行的桌面型数据库管理系统。Access既拥有用户界面(VB可以用来开发用户界面)；也拥有逻辑、流程处理，即VBA语言(VB也可以用来做逻辑处理)；又可以存储数据，即在“表”中存储数据。使用MicrosoftAccess无需编写任何代码，只需通过直观的可视化操作就可以完成大部分数据管理任务。在MicrosoftAccess数据库中，包括许多组成数据库的基本要素。这些要素是存储信息的表、显示人机交互界面的窗体、有效检索数据的查询、信息输出载体的报表、提高应用效率的宏、功能强大的模块工具等。
5.VisualFoxPro。VisualFoxPro是Microsoft公司VisualStudio系列开发产品之一，简称VFP是Xbase数据库家族的成员，可以运行于Windows9X/2000和WindowsNT平台的32位的数据库开发系统。VisualFoxPro提供了一个功能强大的集成化开发环境，采用可视化和面向对象的程序设计方法，使数据管理和应用程序的开发更加简便。VisualFoxPro是数据库管理软件，可实现数据与应用程序独立。
二、如何选择适合自己的数据库软件
1.按性能应从以下几个方面予以考虑：
(1)构造数据库的难易程度；(2)程序开发的难易程度；(3)数据库管理系统的性能分析；(4)对分布式应用的支持；(5)并行处理能力；(6)可移植性和可扩展性；(7)数据完整性约束；(8)并发控制功能；(9)容错能力；(10)安全性控制；(11)支持汉字处理能力。
2.按需求来选择
选择一个数据库的主要理由就是它的功能是否可以很好地支持你的应用程序。人们通常使用数据库来完成的任务有：支持Web、事务处理、文本搜索，有的情况下复制也是一个重要的要求。在事务处理方面，Oracle看上去更有领先优势，接下来是微软的SQLServer。没有一个开源数据库具有可以与Oracle相媲美的事务处理功能。
3.按易用性和管理来选择；
4.按支持性来选择；
5.按成本因素来选择。
三、结论
Oracle是商业数据库的代表，具有非常丰富的功能、广泛的平台支持和大量的附加功能。目前Access更常用一些，Access不是一种存储格式，是一种软件。ACCESS这个软件本身就具有开发者使用的界面和适合于“最终用户”的界面。但学习FoxPro可为学型数据库管理软件大典基础。微软的SQLServer只可以运行在其Windows操作系统平台上。不过由于Windows操作系统的广泛普及，缺乏对其他系统的支持并没有阻挡SQLServer的市场份额的增长。SQLServer是真正的中大型数据库,VFP是桌面数据库,使用方便、易学，但实际上牺牲了真正数据库的一些功能，如安全性；此外，VFP既是数据库又是编程语言（开发工具）。SQLServer是中大型数据库,VFP是带有自身数据库的编程语言。
总体来说，选择什么样的数据库要看你的应用程序的需要。如果它是以阅读数据库为主的Web应用，MySQL无疑是最佳选择。而如果需要那些事务处理和复杂的数据库功能，那么可选择Oracle和微软的SQLServer。如果你需要一些商业数据库的高级功，但又不想支付授权费用，那么可以考虑PostgreSQL或Ingres。对于嵌入式数据库应用，MySQL和Sybase所占有的系统资源最少。总之，最适合的才是最好的！
参考文献：
[1]刘守根.数据库管理系统的现状和发展方向初探.内江科技，2006，(2).
[2]陈业斌.分布式数据库管理系统的设计与实现.安徽工业大学学报(自然科学版)，2005,(3).
[3]姬志刚.计算机、网络与信息社会.科技咨询导报，2006，(20).
[4]薛向阳.数据库管理系统的开发与程序的设计.渭南师范学院学报，2005,(2)
[5]竺洪平.数据库管理系统的设计与程序的开发.中小学电教，2005，(6).
一、开放数据库连接
ODBC(OpenDataBaseConnectivity,开放数据库连接)是微软开放服务结构中有关数据库的一个组成部分。它建立了一组规范,并提供了一组应用程序调用接口。用这样一组接口建立的应用程序,对数据库的操作不依赖于任何数据库管理系统,不直接与任何DBMS打交道,由此可实现应用程序对不同DBMS的共享。数据库操作的“数据源”对应用程序是透明的,所有的数据库操作由对应DBMS的ODBC驱动程序(ODBCDriver)完成。有了ODBC驱动程序,数据源就变得十分广泛,它可以是本机的某种数据库格式的文件(如本机DOS目录下的Access文
件*.mdb),也可以是远程数据库文件(如MicrosoftSQLServer);它可以是目前已知的某种DBMS格式,也可以是一种全新的数据库格式。总之,它取决于提供了什么数据库类型的驱动程序。
VisualC++中的ODBC主要是实现基于Windows的关系数据库的应用的共享。
二、ODBC管理器
在ODBC中,数据源是一个重要的概念,它是数据库位置和数据库类型等连接信息的总和。数据源在使用前必须通过ODBC管理器(Administrator)进行登录。在登录数据源时,要搞清数据源名(Datasourcename)、数据库文件名(Databasename)和数据表格名(Tablename)这三者的概念和相互关系:数据源实际是一种数据连接的抽象,数据源名是登录时赋予的“连接”的名称,以供应用程序使用,至于该数据源下连接的是哪一个数据库,则由数据库文件名指出(如Access2.0forMSOffics中的.mdb文件);一个数据库文件中可以包括若干个数据表格(table)和其他内容。在关系@@09A05900.GIF;图1ODBC层次关系图数据库中,数据是以二维表格的方式存在于数据库@@文件中,应用程序最终的操作目标即是这些表格中的行(row记录)和列(columns字段)数据。对于foxprow数据源,数据库文件名是“路径名”,而该路径下的所有数据文件(*.dbf)都属于该“数据库文件”名下的数据表格(table)。
ODBC管理器被装在ControlPanel里(ODBCINST.CPL)。通过该工具可以增添、修改或删除数据源,也用来增添、删除ODBC驱动程序,ODBC管理器把数据源和它们的连接信息保存在ODBC.INI、ODBCINST.INI和ODBCISAM.INI中。当需要共享应用程序时,只需按新的数据文件的类型和位置重新登录即可。
三、ODBC应用程序接口
ODBCAPI是一组标准的ODBC函数库,除了一般的数据库操作函数外,还包括一组函数(如SQLExec或SQLExecdirect)能够内嵌标准SQL查询语句。SQL(StructuredQueryLanguage结构化查询语言)是一种存取关系型数据库的标准语言,能够定义、查询、修改和控制数据,简单的语句能够作用于整个数据表格,具有很强的功能。
同Windows3.1SDK中API类似,ODBCAPI也是基于句柄(handle)进行操作的。API函数按功能可分为以下几类:
·数据源连接函数,设置/获取有关信息的函数;
·准备/提交执行SQL查询语句的函数和获得数据的函数;
·终止函数和异常处理函数。
上述函数的顺序也表示了进行数据库操作的一般顺序。两个问题需要特别说明,一是数据类型问题:数据源中的数据所具有的数据类型称为SQL数据类型,这些数据类型在其数据源中可能比较特殊,不一定和ODBCSQL数据类型存储方式一致,驱动程序把这些数据类型同ODBCSQL数据类型进行相互转换,每一个ODBCSQL数据类型都相当于一个ODBCC语言数据类型;二是函数的调用级别问题,并不是每一个ODBC驱动程序都支持所有的ODBCAPI函数调用,在应用程序中,可以调用有关函数获取驱动程序以支持层次方面的信息。
四、ODBC应用编程
在VisualC++中,MFC(MicrosoftFoundationClass基本类库)是经过对Windows应用程序中各个部件进行类的抽象而建立的一组预定义的类,如窗口基类(CWnd)、各种窗口派生类等等,这些类在应用程序中可直接使用,不需要重新定义。在MFC中,也为ODBC预定义了几个类,其中主要的是数据库类(CDatabase)和记录集合类(CRecoredset)。这两个类既有联系又有区别,在应用程序中,可以分别使用,也可以同时使用,每一类也可以同时存在多个对象。CDatabase的每一个对象代表了一个数据源的连接,CRecordset的每一个对象代表了从一
个数据表中按预定的查询条件获得的记录的集合,一般说来,前者适宜于对数据源下的某个数据表格进行整体操作,后者用于对所选的记录集合进行处理。
同Windows类与SDKAPI函数的关系一样,CDatabase类与ODBCAPI函数也有类似的关系,但CDatabase类中并不包含所有的ODBCAPI函数,大部分操作功能仍须直接调用ODBCAPI函数,如目录功能函数,用于获得数据源下的数据表格信息,如表格名,字段名等。
在应用编程时,一般使用CDatabase和CRecordset的派生类。假设派生类分别为CUserdb和CUserset,而在应用类CUserClass中,使用了一个CUserdb对象(m-db)和一个Cuserset对象(m-recset),图2给出了用户应用类与ODBC类的相互关系示意图。
@@09A05901.GIF;图2CDatabaseCRecordset类与应用类及数据源关系图@@
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语句方式进行,可直接通过ODBCAPI函数,或者CDatabase类成员函数ExecuteSQL。数据表名在SQL语句中指定,如下语句则在所在的数据源中的clerk表中插入一个记录,记录的name字段值为"chen"。
m-db.ExecuteSQL("insertintoclerk(name)value(’chen’)");3.m-recset连接数据m-recset在构造时,可传入一个CDatabase对象指针,作为m-recset的数据源,当为NULL时,必须重载CRecordset的函数GetDefaultConnect,以提供数据源连接字符串(相当于m-db.Open中的lpszConnect)。如下则表示连接名为COMPANY的数据源(当传入了合法的CDatabase对象指针时,该函数将不被调用)。
CStringCUserset::GetDefaultConnect()
{
return"ODBC;DSN=COMPANY;";
}4.m-recset选取记录和字段
m-recset在调用打开函数时,即获得了符合条件的一组记录,条件语句在Open函数中的lpszSQL中给出,如果lpszSQL为NULL,则必须重载CRecordset的函数以提供该语句。该语句是一个SELECT语句,带或不带where和orderby子句(如果不带,where和Orderby的条件也可在CRecordset的两个预定义成员变量m-strFilter和m-strSort中给出)。lpszSQL也可以只是一个数据表名(table-name),也可以是对内嵌在数据库文件中的查询程序的调用语句。所选择的一系列字段名,在成员函数DoFieldExchange中由一系列RFX-函数指定。RFX-(RecordFieldExchange)函数,使字段和成员变量一一建立类型对应关系。另外,m-strFilter中也可以带变量参数(用"?"表示,如"fieldl>=?ANDfield2<=?"),参数与成员变量的对应关系也在DoFieldExchange中由RFX-函数指定(串中的"?"将被参数变量值逐一替换)。
voidCUserset::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);
...
}其中,???为ODBCSQL数据类型名,如RFX-Double,RFX-Text等。
综合上述,选取记录和字段实际是由下列语句完成:
SELECTrfx-field-listFROMtable-name[WHEREm-strFilter][ORDERBYm-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();
m-mitTrans();
if(catcherror)
m-db.RollBack();
}
}
对于AddNew和Edit,修改字段变量后一定要调用函数Update(),否则更新将丢失,而Delete操作则不必进行字段值修改和调用Update()。
上述的CDatabase的四个函数是ODBC为保证数据操作的可靠性而提供的“批”处理函数,即在BeginTrans和CommitTrans之间的数据修改如果出现任何异常,可通过函数RoolBack来恢复所做的修改。
在多用户系统使用时,每一个数据源可以被多个用户的多个任务连接,不同的任务可同时修改相同的数据源。ODBC提供了两种数据表更新的同步机制(在m-recset.Open函数中指定),“静态”的(snapshot)和动态的(dynaset)。前者是一组静态的记录集合,当建立后不会改变,除了反应自己的添加/删除外,不反应别的用户的修改,除非调用了Requery重新建立。后者是一组动态的记录集合,自己或别的用户所作的修改随时反应到集合中来(当然也可用Requery重建),以保持记录与数据源的同步。在应用中,应根据需要确定使用哪一种方式。
五、结束语
1.1有效避免资源浪费现象的发生
对于计算机软件系统而言，数据库作为其中的核心内容，需要得到人们的重点关注。在数据库设计的过程中，需要通过对软件工程的定义分析，实现对不同软件工程项目的认识及理解，满足数据库编程的基本需求，从而有效避免了数据资源浪费现象的发生。在软件设计中，设计人员需要提高对软件数据库编程的重视，通过对数据库资源的综合性分析，避免数据库出现使用性能不高的问题，解决数据故障限制因素。对于不良的数据库而言，其后期系统的维护频率会不断增多，从而造成了计算机软件维修中资源浪费的现象。
1.2提高计算机软件系统运行速度
在计算机系统设计及分析中，需要通过对软件系统的运用，实现对程序功能的稳定发挥，为数据资源的系统运行提供有效支持。而且，在高性能数据软件系统运用中，可以通过对计算机系统的操作分析，进行准确、快速的信息传输，全面提高软件系统的运行速度。同时，在计算机软件系统使用的过程中，通过对数据库资源的拓展分析，可以为用户提供便利性的服务支持，减少数据资源浪费现象的发生。通過计算机软件数据库的构建，可以实现对数据库资源的合理革新，从而为数据资源的储存软件系统的管理提供有效支持。
2计算机软件工程中的数据库建立
开展计算机软件工程建设过程中，首先要针对数据库系统进行完善，设计构建基础的框架，计算机软件通常是在网络环境下运行使用的，因此在建设期间，也要考虑是否存在影响因素，通过各个系统之间的相互配合，来实现软件功能，数据库中的信息安全性也能够得到保障。对于软件工程中针对数据库编程管理问题，在建立初期要有明确的使用方向，完成基础框架设计后需要针对功能方面采取完善措施，不断的补充其中的功能，并提升软件自身防御能力，这样即使是在网络运行使用环境下，也能最大限度的避免受到病毒攻击，确保数据信息安全，同时数据库中信息的更新速率也能够达到使用需求标准。数据库建立是基于编程技术基础上来开展的，对于一些技术性问题，通过功能之间的协调使用，可以更好的避免出现技术性问题，同时在软件工程投入使用后最大限度的利用数据库资源，在网络环境中也能够实现软件的自动更新检测。建立过程中要选择适合的程序汇编语言，通过语言来完成功能框架编写，选择适合的汇编语言，针对不同的功能模块也可以做出区分，这样可以更好的帮助提升设计效果。
3对数据库文件的应用
3.1面向对象的数据库存储模式选择
数据库存储模式选择，需要在分区后进行，存储功能中可能会出现不同程度的功能隐患问题。这种数据库存储模式选择也是对用户访问权限的定义，在软件使用过程中，为确保内部重要信息的安全性，会对用户的访问权限进行定义，这样不同级别的用户所能够登陆到的界面也存在差异，数据库信息也都得到安全保障。基于文件类型选择基础上所进行的文件访问，也更高效合理，实现上述功能在程序编写期间要重点设计，根据所存储的信息类型来对数据库做出选择，避免出现更深层次的问题，并帮助合理优化资源，利用过程中达到更理想的效果。不同资源在使用时需要根据所接收到的指令来调动数据库内部信息，实现资源利用方面的优化。
3.2数据库文件的加密保护
文件加密保护主要是针对基础信息来进行的，这部分信息关系到使用者的个人隐私，一旦泄露会造成严重的影响，因此在所开展的数据库文件加密保护中，要根据不同信息的重要程度来设置等级，采用登陆口令以及密码加密的形式来进行保护，登陆到数据库文件内部需要输入相应的加密密匙，这样工作人员可以根据常见问题来探讨解决加密措施，以免文件应用过程中受到网络病毒的影响，造成数据库使用期间瘫痪问题。对于文件加密期间的数据信息选择，通过各个系统之间的文件加密选择，如果出现功能方面的冲突问题，可以通过系统的框架结构优化来达到更理想的优化使用模式。为各个系统之间的功能优化创造有利环境。
3.3数据存储模式使用方法比较
存储功能使用性能是否稳定，要从使用方法对比过程中来进行探讨，观察运行状态下的软件是否存在功能不稳定的现象，并从技术性角度来深入探讨预防措施。设计期间的功能选择直接关系到后续网络访问所选择的形式，以及工作任务开展期间可能会遇到的相关问题，帮助提升系统投入使用后的功能稳定性，通过这种工作模式上的创新利用，可以帮助避免网络环境中软件使用受到计算机病毒的入侵，并最大程度的保护数据库中信息的安全性，对于一些比较常见的技术性问题，对于这种配合方法的选择也能够达到更理想的运行效果。系统在运行过程中会对所接收到的信息快速筛选，将其中的有用信息进行归类，这样可以根据使用需求快速的调动数据库内的信息，软件投入使用后也可以根据操作需求对功能进行更新处理，这种方法的实现也需要各个系统之间的相互配合。对存储模式进行对比，观察其中所存在的问题，更有利于下一阶段软件功能设计的实现。
3.4开发设计中的编程技术选择
编程技术选择过程中，要以软件功能的稳定性来进行探讨，观察在系统设计中对资源的利用是否优化，以及可能会出现的功能不稳定现象。针对比较常见的系统功能问题，在编程阶段的技术选择可以采用对比的方法来进行，观察系统功能的稳定性，发现数据传输不准确的现象要及时采取解决控制措施，预防软件的功能出现大面积瘫痪，影响到正常工作使用。程序检测工作开展也是针对这些技术选择问题来进行的，对所开发设计出的软件进行稳定性检测，为系统的运行创造出安全适合的环境，在这样的环境下才能够解决运行稳定性问题，并达到系统需求的工作环境。软件功能稳定性与编程技术的选择之间有很大关系，因此在选择编程方法时要考虑是否可以解决这一技术优化利用的问题。开发初期阶段出现问题可以重新优化基础框架结构，这样后续的建设计划也可以顺序开展，在这样的环境下，计算机程序汇编面临着功能实现与网络环境安全防护的双重任务，实现各项工作任务也是十分复杂的。
1.建立学籍档案数据库使学籍档案的管理效率、检索速度和查准率有了明显的提高。面对日积月累的档案，沿用传统的手工目录查询档案已经不能适应形势的要求，传统的案卷目录检索点单一，不支持模糊查询，检索起来费劲费时，而且查全率和查准率很难得到保障。以复旦大学1960年以后形成的学生学籍档案为例，如本专科生的学生成绩表、毕业生登记表，不以个人为单位立卷的，而是以年度、院系或专业为单位装订成册，学生的学籍变更如休学、退学、复学、转学不能在案卷目录上体现出来，这样难免会降低档案的查准率。我们将学生的个人信息输入计算机，建立学生信息数据库，只要定义任一检索条件或组合查询，即可迅速准确地筛选出符合条件的记录。
2.采用学籍档案数据库管理缓解了档案保存与利用之间的矛盾。学籍档案的形成年度跨度较大，尤其是具有百年历史的高校，学籍档案对于研究高校教育史具有重要的参考价值，而档案不同于一般的历史文物，具有记录性和原始性的特点，随着社会的发展，学籍档案的利用率在不断提高，档案的破损速度也在加快，这样就产生了学籍档案“保存”与“利用”之间的矛盾。将学籍档案原文数字化，存入数据库，不仅可以解决“保存”与“利用”的矛盾，而且还大大提高了查检速度。
3.学籍档案数字化是档案信息上网的基础。网络化已成为时代的主旋律，网络技术的应用更推动了档案事业迈上新的层次。档案信息是重要的信息资源，档案信息只有上网才能体现它的价值，才能为更多人所利用。大量的档案信息寓于纸质的案卷、文件之中，虽然电子文件已经达到相当程度的普及，但大量较早时期形成的档案都还是纸质的，这是档案信息上网的一大障碍。只有将这些纸质档案转化为电子文件，才能真正成为电子信息。
2、建设学籍档案数据库
1.学生信息数据库的基本结构
学生信息数据库由10个输入字段组成，分别是：学号、姓名、字、号、籍贯、院、系、专业、入学年月、毕业年月，同时，这些字段又是多途径组合查询的检索入口。
我们用Access2000来开发学籍档案信息管理系统，Access是一种关系型数据库，它为用户提供了数据库管理的工具集和应用程序开发环境，是中小型数据库应用领域中最通用的数据库软件。由于Access数据库和VB(VisualBasic)语言结合得比较好，对于数据库开发人员，利用VB语言以及Access数据库提供的可视化工具和向导，便可以设计出具有一定规模、功能强大的数据库应用系统。Access还具有数据访问的功能，可以创建用来添加、编辑、查看、处理学籍档案数据库当前记录的Web页，也可以通过电子邮件发送数据。
2.制作扫描文件
采用扫描录入方式将学籍档案按原貌逐页存储为图像文件，学籍档案原件有5项基本内容：毕业照、学生学籍表、分年课程学分表、毕业资格审查表、中学毕业证书，以学号作为文件名标识，例如某人学号为13561，那么他的扫描文件分别为13561a、13561b、13561c、13561d、13561e，依次类推。
计算机图像文件的格式很多，常见的图像格式有：BMP、JPEG、TIFF等，使用上各有长短。不同的格式其文件大小、打开速度、支持颜色、压缩耗损等参数均不相同。BMP格式的图像没有压缩、最能体现实物的原貌，大多数浏览器如IE、Netscape等都支持这种格式。然而其文件大，占用系统资源最多，打开速度慢，特别是在网络上传输时，其打开和下载速度更难适应要求。因此在图像格式的选择上必须考虑Web图像的要求。JPEG格式的图像压缩比例大，图像文件做得小，网络下载速度也最快，支持颜色也多。TIFF格式的文件适合做动态图形，但是色彩层次的还原性比较差。所以，建设大量图片形式的扫描文件库选择以*.JPG格式保存比较好。
经过比较和测试，用100dpi的扫描分辨率扫描的图像在清晰度和文件大小之间达到较好的平衡。
3.学籍档案数据库系统的设计
对所有的扫描文件编制目录索引，目录索引用数据库方式建立，每一图像文件以其存储地址与其在目录索引中的记录相链接。利用目录索引可检出所需档案之图像文件的存放地址，通过地址借助链接显示该档案原文的图像。
我们设计的复旦大学学生学籍档案信息管理系统由数据库文件，扫描文件，超文本文件及程序文件组成。分别开设四个子目录存放这四部分的文件。
数据库文件即学籍信息数据库，由手工录入的学生信息组成，一人一条记录，是检索的依据，也是链接的基础。
扫描文件即学籍档案的原文扫描件，由于数量多，必需用一个大容量的硬盘来存放，为了保证数据的安全，还应分期分批进行数据备份。
超文本文件即*.html文件，通过程序生成，通过学号建立超文本链接。
程序文件由输入界面、查询界面组成，并分别嵌入IE控件。程序启动后，历读学籍档案文件夹中的扫描图形文件，依学号自动编写相应的HTML文件，供输入、查询中的浏览器阅读。
系统采用先扫描后输入的方式。在输入界面内，选择学号，程序调用对应的HTML文件，浏览器显示对应学籍表，依据学籍表输入相关信息，使数据库的输入工作简洁直观，可方便完成数据的保存、编辑和打印等工作。
在查询界面内，可按各字段进行独立或组合检索，并在网页内给出结果集合。点击学号，浏览器给出该学生的全部档案资料。并可直接打印，邮寄各文件。
3、建设学籍档案数据库的难点和解决办法
1.学籍档案具有原始性的特点。虽然文档一体化管理在信息系统技术上已逐步走向成熟，但是大量归档后的文件却不能做到全部数字化。自动文字识别软件OCR技术的应用大大提高了数字化的效率，但是这种软件要求印刷体的规范化文字，而对历史档案原始资料中大量形形的手写字体很难识别。由于时代所限，早期形成的历史档案都是纸质的，这也是实现档案数字化的瓶颈。所以，通过扫描技术，将原始的学籍档案材料，转换为图像文件存储在计算机中，是一种比较现实可行的办法。通过学籍档案数据库可以快速调用原文数据库即扫描文件库中的文件，也省却了调卷的繁复。
2.学籍档案材料不统一。学籍档案是散页的，各种材料大小不一，有些材料甚至有缺损，在扫描时需要对有残缺和破损的照片在进行修补，我们可以用图像处理技术对扫描的图像文件进行加工，使之达到满意的效果。
一、实验情境设计
某小型企业已建立采用B/S结构设计的销售管理系统，其后台数据库名称为example，products表和orders表是example数据库中的两张表。要求用户a～e能登录数据库服务器并按照设计的访问控制权限访问相应的服务器及数据库资源，访问用户及权限设置如表1所示：表1用户及访问权限设置表
二、实验技术分析
本实验主要实现在SQLSERVER中对数据库安全性的管理问题。首先明确SQLServer中身份验证的种类和实现步骤，然后再熟悉为用户分配登录账号和权限的操作方法，对于SQLServer安全性的各种管理，尤其是对数据库访问控制操作有深入要求。要管理数据库安全性，必须了解各种账号和权限，因为安全性就是通过它们的分配来实现的。所以掌握它们的区别和用处非常重要。（一）SQLSERVER身份验证模式SQLSERVER身份验证模式指SQLSERVER如何处理用户名和密码的问题，SQLSERVER提供两种身份验证模式。1、Windows身份验证模式，在这种方式下，用户只可以使用Windows身份登陆连接到SQLServer，由Windows操作系统对客户端进行身份验证。我们知道，SQLServer和Windows同属于微软公司的产品。当使用Windows身份验证连接到SQLServer时，SQLServer使用Windows操作系统中的信息验证账户名和密码，用户不必重复提交登录名和密码。这种验证方式的弊端在于若采取B/S结构服务器，远程客户机无法连接到服务器，这时须使用混合验证模式。2、混合验证模式，即可以同时使用Windows身份验证和SQLServer身份验证。使用具体验证方式取决于在最初通信时使用的网络库。如果一个用户使用TCP/IP进行登录验证，则使用SQLServer身份验证；如果用户使用命名管道，则登录时将使用Windows身份验证。[1]图1SQLServer安全性决策树通过以上两种身份验证模式，用户如果想使用指定的登录名称和密码连接到SQLServer，SQLServer会按照图1所示的安全性决策树进行安全身份验证。本实验中要实现在采用B/S结构设计的销售管理系统中让不同的客户端用户能访问服务器的数据库资源，所以身份验证模式可以设置为“SQLServer和Windows身份验证模式”。（二）账号和权限1、登录帐户登录账户是让用户登录到SQLServer服务器中用的账号，如果用户不能登录SQLServer的服务器，也就不能访问该服务器上的数据库资源。在实验中，需要创建登录帐户logina～logine，让这些帐户都能登录数据库服务器。2、数据库用户一个SQLServer服务器下面可以建多个数据库。能登录到SQLServer服务器，不一定能访问到服务器中的数据库。在实验中，需要创建数据库用户userb～usere，使这些数据库用户都能访问sample数据库。3、角色为了便于管理数据库的的权限，SQLServer提供了若干“角色”，“角色”就是用一种方法来把用户集中到一个单元中，并在此单元上应用权限。SQLServer提供了预定义的服务器角色和数据库角色，也可以在数据库中创建用户自定义的数据库角色。在实验中，用到如下两个固定的服务器角色和数据库角色：sysadmin固定服务器角色的成员可以在数据库引擎中执行任何活动。db_backupoperator固定数据库角色的成员可以备份数据库。由于本实验中用户a需要访问控制全部服务器资源，即用户a要求完全的数据库服务器访问权限，所以用户a应设置为固定服务器角色sysadmin的成员之一，使之成为服务器的超级管理员。用户a的安全访问流程如图2所示。图2用户a安全访问流程用户b要能备份数据库，可以将其添加到数据库角色db_backupoperator中，用户b的安全访问流程如图3所示。用户c与用户d都要访问数据库中的表，所不同的是具体的访问对象及访问权限，在实验中可以创建两个自定义的数据库角色R1和R2，将用户userc、用户userd分别添加到R1角色R2角色中。4、权限在为用户和角色分配登录帐户后，还必须为他们分配权限以增强数据库的安全性。权限详细地说明了可以让用户使用哪些数据库对象，并可以对它们进行哪些处理。用户在数据库内的权限取决于用户帐户的权限和该用户所属的角色成员。在实验中为R1角色授予查询、修改products表的权限，为R2角色授予查询orders表的权限，为用户usere添加访问products表、orders表的权限。用户c～用户d访问数据库资源的控制方式如图4所示。图4用户c～用户e安全访问流程
三、实验过程
该实验需要每人PC机一台，操作系统为Win－dowsxp或win7，实验的数据库管理系统软件为SQLServer2005或SQLServer2008。请学生务必用每个用户的身份进行登录、比较操作以校验数据库安全访问控制实验过程的正确性。
四、实验总结
摘要分析了几种网络计算模式的特点，针对客户机/服务器模式设计了一个地理信息系统(GIS)访问数据库的结构框架——客户端分为GIS功能层和数据库请求层两层，服务器存放数据，并将此结构与ESRI公司的空间数据库引擎(SDE)作了对比；通过比较几种数据库访问的程序实现方式，认为ODBCAPI在开放性方面是良好的.最后给出的MAPGIS实例表明：采用上述设计思路的应用系统不但利用了原有MAPGIS的研究成果，实现了GIS访问网络数据库的功能，而且还具有良好的开放性.
关键词地理信息系统，数据库访问，空间数据库引擎(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的效率.
参考文献
1/base/common/userconf/proc96/TO100/PAP094/P94A.HTM.1998.4
关键词：古典文献数据库 公共古典文献数据库 文献检索服务系统
计算机技术的飞速发展，为古典文献研究的现代化提供了坚实的基础，其贡献是有目共睹的。然而，计算机技术在古典文献研究中的运用仍然存在着极为严重的缺陷也是不容回避的。笔者近几年来主持并直接参加设计“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字库兼容，那么古代文献的文字识别问题是可以得到解决的。应该强调的是，古代文献以繁体字导入数据库，但应该允许在数据库中自由进行繁简转换，换句话说，若需要使用繁体字时，文本可以保留繁体字，而需要简体时，可以十分方便地转换成简体，这样就适应用户对繁简体的不同需要了。
其四，彻底解决古典文献版权问题。这是困挠计算机古典文献数据库建设的重要难题之一。自然，这一问题要真正得到落实确实存在相当困难的，因为版权保护工作任重道远！不过，即使困难再大，古籍文献数据化的发展的潮流是不可能停止的。笔者以为，有关出版社在维护自身法定的版权权益的前提下，应该从大局出发，在收取一定数量的报酬前提下，允许制作有关古典文献的数据库，以利学术研究的发展。至于报酬多少可以也应该实事求是地酌情商定，国家有关部门应该主动与那些出版社协调，亦可将目前大量分散投入到各课题中的资金中抽出部分来补偿有关出版社，双赢互利，以求突破版权瓶颈，早日解决这一棘手的问题。
与此相关的是古典文献电子文本的版权问题，这也是个极难处理的问题。因为用户若贪图小利，版权意识不强，不愿化费代价使用电子文本，就容易产生“盗版”问题，如此就使得制作古典文献电子文本者的正当利益大受损失。按笔者设想，如果真正能够由国家有关部门主管古典文献数据库建设工作，那么就可以设想建立公共古典文献数据库规定导入数据库的文献文本都给予一个“统一编号”，没有统一编号的文献就不能直接导入公共古典文献数据库和个人使用的文献检索服务系统中，也就是说，个人使用古典文献电子文献必须化费一定的代价才能取得使用权，这样就可以保证制作古典文献电子文本者的一定收益，防止版权意识不强者侵权使用。同时由于古典文献电子文本都有了统一编号，那么也就可以防止某一具体文献文本重复录入的问题。即使有部分重复，古典文献电子文本也可以在用户选择过程中优胜劣汰。
其五，建立公平的交易平台。建立庞大的公共古典文献数据库当然需要投入巨大的资金，而这种古典文献数据库自然不是每一个普通研究者购买得起的。在笔者看来，大专院校、科研机构应该在经济允许的前提下购买有关数据库，以供教学、研究之需。当然也应该允许个人在交纳一定数量的经费后，自由上网使用这一数据库，并允许购买（下载）一定数量的古典文献文本，自行导入各自的文献检索服务系统，以利建立个性化的有实用价值的数据库。如果真能做到这样的话，那么就将会促进学术研究的迅速发展。
>> 基于Web的数据库远程自主实验平台 基于Web的远程数据库管理探究 基于 SQL Server的煤矿应急救援平台数据库研究 基于Web数据库的考务管理平台方案 基于Linux平台Apache\PHP\MySQL数据库的WEB商务系统设计 基于Web平台的数据库加密技术应用探究 基于PHP技术的基因数据库Web平台设计 基于Web数据库的数据库挖掘技术探究 基于Web数据库的数据库挖掘技术研究 浅谈基于ASP的WEB数据库访问技术 基于XML数据库的Web应用研究 基于数据库应用的WEB结构分析 基于的WEB数据库应用 基于Web的数据库技术分析 基于WEB数据库安全的访问技术 基于WEB的数据库访问技术 基于Web的数据库技术探究 浅谈基于JSP的数据库Web访问技术 基于Web数据库的安全问题探析 基于Web的数据库技术浅析 常见问题解答 当前所在位置：
范茂魁.2009.制约特勤队伍地震救援专业化发展因素及对策[J].消防科学与技术，28（3）：217-222.
何少林，李佐唐，姚子文.2006.甘肃省地震应急基础数据库管理服务软件系统研制[J].西北地震学报，28（2）：149-153.
吉雍慧.2008.数字图书馆中的检索结果聚类和关联推荐研究[J].情报分析与研究， （2）：69-75.
雷秋霞，陈维锋，黄丁发等.2011.地震现场搜救力量部署辅助决策系统研究[J].地震研究，34（3）：385-388.
李东平，姚远，2009.浙江省地震应急基础数据库建设研究[J].科学技术与工程，9（9）：2474-2479.
刘红桂，王建宇，徐桂明.2005.基于GIS的江苏省地震应急基础数据库与震害快速评估技术[C]// 江苏省测绘协会.2005数字江苏论坛――电子政务与地理信息技术论文专辑.江苏：《现代测绘》编辑部，10-12.
聂高众，陈建英，李志强等.2002.地震应急基础数据库建设[J].地震，22（3）：105-112.
王东明.2008.地震灾场模拟及救援虚拟仿真训练系统研究[D].哈尔滨：中国地震局工程力学研究所.
王东明.2013.中国地震救援废墟安全评估综合管理系统[J].土木工程学报，46（2）：301-306.
【论文摘 要】分析了城市绿化管理的评价指标，在此基础上分析了地理信息系统（GIS）在城市绿化管理中的作用，分别介绍了GIS、数据库技术和.NET技术三种技术在城市绿化管理中的应用，最后提出基于信息管理技术的城市绿化管理的对策与建议。
城市绿地作为城市结构中的自然生产力主体，对城市系统和生态发展起着至关重要的作用，是改善城市生态质量，调节城市生态平衡的主要载体。我国城市绿地的破碎化程度很高，采取人工手段提前绿地信息的难度自然就变得非常大，运用信息系统对城市绿地进行规划管理能够推进城市绿地管理的现代化水平，提高绿地管理效率。城市绿化管理信息系统的减轻城市绿化的规划设计、建设施工和养护管理等各项管理工作复杂程度的有效方式，同时能够合理地利用人力、物力和财力等资源，提高城市绿化管理质量，实现科学管理。城市绿化管理信息系统为园林绿化管理部门提供数据信息，以便于统计部门进行规划，实现内部管理标准化和城市绿化管理条理化。
一、城市绿化评价指标
城市绿化系统的概念仍在不断完善中，与此同时，关于城市绿化的指标体系也在不断调整和完善。国际上关于城市绿化的评价指标有很多，例如，联合国在1996年提出市区公园绿地定额为60m2/人，而实际上，无论是在发达国家还是在发展中国家，很多城市都超过了这一指标。其他国家也都根据本国的实际情况提出了不同的城市绿化评价指标，我国基本建设委员会于1980年颁布了《城市规划定额指标暂行规定》，确定了城市绿地定额近期3-5m2/人，远期7-11m2/人，跟地区根据此指标也规定了本地区的绿地系统指标。
二、城市绿化信息管理技术
城市绿化信息涉及到大量的地理空间数据，因此对城市绿化管理与评价体系在技术方面提出了很大的挑战，随着信息技术发展，信息管理系统相关技术应用于城市绿化管理，较为明显的是地理信息系统技术的使用，关键技术包括地理信息系统技术（GIS），数据库技术和.NET技术。
（一）GIS技术
GIS最早出现在60年度，是从国外引进的一种数据管理技术，与传统的分析方法相比，GIS将传统分析方法中单一、静态的数据进化为多数据源、多时相以及时空结合的综合分析方式，能够进行数据综合和模拟分析，并且能够得到传统方法难以得到的重要信息，因此，这一技术已经应用到绿地管理的各个领域，成为各城市进行规划的必要工具。目前，国际上大多数的GIS软件公司已经把开发组件式软件作为重要的发展战略，因为组件式的GIS技术成为现在各城市进行城市绿化管理主要应用的信息管理技术软件。国际上主要的组件式GIS商用软件的分类包括MapObjects和ArcObjects。MapObjects 技术能够实现人性化和清晰化的数据分析，并实现地图操作相关功能，ArcObjects是一个非常重要的组件平台，也是目前功能最强、组件最全、结构最复杂的平台。GIS在国内一些地理信息系统研究机构得到了很好的发展，例如中国地质大学和武汉大学地理信息系统研究中心都对这一软件进行了深入的研究，为我国发展GIS组件技术做出了很大的贡献。
（二）数据库技术
数据库技术能够将数据集合按照一定的结构、组织和描述性特点进行储存，具有较小的冗余度，而且数据的独立性非常高，具有易扩展性，能够为多种用户进行共享，非常适合我国城市绿地管理中的信息系统管理与应用。在城市绿地管理过程中，数据库管理系统在确保数据安全可靠的同时，能够提高用户使用数据的方便性和简单性，用户对数据的操作能够通过数据库进行运行。数据库技术有很多，配合Windows服务器版操作系统进行使用能够提高其在城市绿地管理中的应用效率。
（三）系统开发平台（.NET技术平台）
NET开发平台是完全不同于传统应用开发的技术架构，包含很多组件，主要可简化且规范应用系统的开发与部署，进而可以提高城市绿化管理数据的可移植性，安全性和可再利用价值。.NET开发平台包含的各类组件、服务架构及技术层次都有共同的标准和规格，存在较好的兼容性，能够解决过去城市绿化管理中使用的信息管理软件无法使信息产品彼此实现兼容的问题。这一开发平台在我国各城市的绿地管理中有着广泛的应用，并有大量的成功案例。
三、构建城市绿化管理数据库的建议
建设城市绿化数据库，是一个系统性的工程，既包括信息管理软件的应用与管理，又包括数据的分析与维护。因此，在进行城市绿化管理数据库建设的过程中，要注意基础地理空间数据的建设，绿化规划数据库的建设以及元数据库的建设，确保空间和非空间的数据能够通过信息管理软件实现一体化集成。第一，空间数据库，包括基础地理空间数据库、绿化规划数据和绿化现状数据库；第二是属性数据库，主要包括植被规划目标、系统资源的属性数据和有关城市绿地规划和管理的元数据。
建设城市绿化管理信息系统能够实现城市植被地理分别的信息管理，提高城市绿化管理效率，在城市绿化管理中，很多管理内容和管理任务都是与地理分布有关的，在各项管理中存在大量杂乱的、分散的资料和数据，因此建立城市绿化管理信息系统，并通过GIS技术和数据库技术的结合能够有效地分析如此庞大的数据，并为城市绿化管理提出建议奠定基础。
参考文献
[1]赵爱华，杨凤海.基于GIS的城市绿化管理信息系统设计与研究[J].微计算机信息，2007，23（8）.
[2]姜文峰，郑文刚，王彦文，赵春江.城市绿地自动化节水灌溉系统的研究[J].节水灌溉，2005，（1）.
购物车(0)