时间：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).
本文以面向文档的NoSQL作为数据持久层，面向文档的NoSQL数据库的数据结构设计相对于关系型数据库来说容易许多，在对数据进行查询、数据库操作接口方面都有很大的优势］。因为面向文档的NoSQL数据库不支持多张表的JOIN操作，因此在对面向文档的NoSQL数据集合进行设计的时候需要考虑到这方面的因素。本监测系统主要的业务功能可以分为3个模块，分别是小区信息查询模块、报表统计模块和用户、终端管理模块，因此，数据集合的设计同样从这三个方面进行设计。各个数据集合之间的关系如图1所示。考虑到在对数据表进行设计所依据的原则基本一致，因此以下仅对小区信息查询模块的数据表设计进行着重分析。设计数据模型需要结合系统的特点进行分析。此系统主要实现的功能是对小区天线参数信息进行保存、管理，并以友好的界面展示给用户，并响应用户的各种操作。因此，在大部分的操作中，存储天线实时参数的ANTENNAARGS表会产生大量的插入操作，本文根据各个表的不同读写比进行了设计，如图2所示。本文将天线表、区域表以内嵌的形式放入了小区表，将天线参数表设计成单独的集合，并以引用的方式指向了小区表主要是考虑到天线参数集合是被访问最频繁的表，会产生大量的读写操作，因此在小区集合与天线参数集合之间采用的是范式化的模式。其中，天线工参表(ANTENANARGS表)用来存储从各个采集终端传输至管理系统的小区天线实时数据信息，具体如表1所示。小区信息表(CELL表)用来存储各个小区的地址、天线相关参数详细信息，如表2所示。除了上述表之外还有采集终端表(TERMI-NAL)、天线信息表(ANTENNA)和告警表(ALARM-REPORT)等。数据库运行时，自动将所对应的数据存入相应表中。
2数据库自动分片设计
管理系统在运行中会产生大量的写操作，进而带来频繁的磁盘I/O操作，在大数据下，最好采用将数据库分布在多台服务器上，即分片［7］。本文采用Auto-Sharding(自动分片)及Replic-Set(复本集)相结合的方式来减轻单个数据库服务器的负载，即在每台Server上各自运行一个实例，组成一个Replic-Set，最后再各运行一个实例，组成ConfigServer。直接执行Addshard操作即可增加分片以缓解服务器的压力，实现动态扩展。分片的实现重点在于片键设计。本文将保存天线参数信息的集合声明了一个复合片键{Lacci:1，Day:1}。当来自不同的小区(可以根据Lacci进行判断)向集群系统插入数据时，可以预计到在大部分情况下，同一小区的数据会落在单个块或片上。
3数据库查询的实现
数据查询功能为本数据库设计的重要功能之一。数据库将小区信息、天线参数等相关的数据信息根据用户的要求，以界面或报表的形式全部或部分的显示给用户。基于本数据库的设计，用户通过数据查询菜单进入相应查询界面，获取小区信息、终端信息及告警信息等。实现“天线工程参数查询”功能的工作流程如图3所示。为了实现小区天线参数查询功能，客户端需要向数据库发送2次请求，用户根据需求，向控制器发送查询请求，控制器处理查询命令，对相应的小区进行信息查询，待小区返回信息后，将用户的查询命令发送至对应小区，根据需求读取有用信息，并返回给用户。跟关系型数据库相比，由于省去了大量的多表连接操作，实际上查询的效率要高于基于关系型数据库的多表连接查询。查询工作的SQL语句如下。
4数据库备份与恢复
数据安全在数据库设计中有很重要的地位。在各种意外情况下，如计算机硬件故障等，对数据库进行备份和恢复能够保障数据的完整性和安全性，使得数据损失降到最小［8］。本数据库设计的备份选用的是副本集的方式［7］:在主节点上进行操作，写入的数据被一步地同步到所有的从节点上，并从主节点或从节点上读取数据，如果主节点由于某些原因断线，会自动将一个从节点提升为主节点。在查询分析器中运用SQL语句完成数据库的备份和恢复。在数据库管理界面中，用户通过数据库备份与恢复功能进行相应操作，确保数据的正确行和完整性。
5结束语
1.1有效避免资源浪费现象的发生
对于计算机软件系统而言，数据库作为其中的核心内容，需要得到人们的重点关注。在数据库设计的过程中，需要通过对软件工程的定义分析，实现对不同软件工程项目的认识及理解，满足数据库编程的基本需求，从而有效避免了数据资源浪费现象的发生。在软件设计中，设计人员需要提高对软件数据库编程的重视，通过对数据库资源的综合性分析，避免数据库出现使用性能不高的问题，解决数据故障限制因素。对于不良的数据库而言，其后期系统的维护频率会不断增多，从而造成了计算机软件维修中资源浪费的现象。
1.2提高计算机软件系统运行速度
在计算机系统设计及分析中，需要通过对软件系统的运用，实现对程序功能的稳定发挥，为数据资源的系统运行提供有效支持。而且，在高性能数据软件系统运用中，可以通过对计算机系统的操作分析，进行准确、快速的信息传输，全面提高软件系统的运行速度。同时，在计算机软件系统使用的过程中，通过对数据库资源的拓展分析，可以为用户提供便利性的服务支持，减少数据资源浪费现象的发生。通過计算机软件数据库的构建，可以实现对数据库资源的合理革新，从而为数据资源的储存软件系统的管理提供有效支持。
2计算机软件工程中的数据库建立
开展计算机软件工程建设过程中，首先要针对数据库系统进行完善，设计构建基础的框架，计算机软件通常是在网络环境下运行使用的，因此在建设期间，也要考虑是否存在影响因素，通过各个系统之间的相互配合，来实现软件功能，数据库中的信息安全性也能够得到保障。对于软件工程中针对数据库编程管理问题，在建立初期要有明确的使用方向，完成基础框架设计后需要针对功能方面采取完善措施，不断的补充其中的功能，并提升软件自身防御能力，这样即使是在网络运行使用环境下，也能最大限度的避免受到病毒攻击，确保数据信息安全，同时数据库中信息的更新速率也能够达到使用需求标准。数据库建立是基于编程技术基础上来开展的，对于一些技术性问题，通过功能之间的协调使用，可以更好的避免出现技术性问题，同时在软件工程投入使用后最大限度的利用数据库资源，在网络环境中也能够实现软件的自动更新检测。建立过程中要选择适合的程序汇编语言，通过语言来完成功能框架编写，选择适合的汇编语言，针对不同的功能模块也可以做出区分，这样可以更好的帮助提升设计效果。
3对数据库文件的应用
3.1面向对象的数据库存储模式选择
数据库存储模式选择，需要在分区后进行，存储功能中可能会出现不同程度的功能隐患问题。这种数据库存储模式选择也是对用户访问权限的定义，在软件使用过程中，为确保内部重要信息的安全性，会对用户的访问权限进行定义，这样不同级别的用户所能够登陆到的界面也存在差异，数据库信息也都得到安全保障。基于文件类型选择基础上所进行的文件访问，也更高效合理，实现上述功能在程序编写期间要重点设计，根据所存储的信息类型来对数据库做出选择，避免出现更深层次的问题，并帮助合理优化资源，利用过程中达到更理想的效果。不同资源在使用时需要根据所接收到的指令来调动数据库内部信息，实现资源利用方面的优化。
3.2数据库文件的加密保护
文件加密保护主要是针对基础信息来进行的，这部分信息关系到使用者的个人隐私，一旦泄露会造成严重的影响，因此在所开展的数据库文件加密保护中，要根据不同信息的重要程度来设置等级，采用登陆口令以及密码加密的形式来进行保护，登陆到数据库文件内部需要输入相应的加密密匙，这样工作人员可以根据常见问题来探讨解决加密措施，以免文件应用过程中受到网络病毒的影响，造成数据库使用期间瘫痪问题。对于文件加密期间的数据信息选择，通过各个系统之间的文件加密选择，如果出现功能方面的冲突问题，可以通过系统的框架结构优化来达到更理想的优化使用模式。为各个系统之间的功能优化创造有利环境。
3.3数据存储模式使用方法比较
存储功能使用性能是否稳定，要从使用方法对比过程中来进行探讨，观察运行状态下的软件是否存在功能不稳定的现象，并从技术性角度来深入探讨预防措施。设计期间的功能选择直接关系到后续网络访问所选择的形式，以及工作任务开展期间可能会遇到的相关问题，帮助提升系统投入使用后的功能稳定性，通过这种工作模式上的创新利用，可以帮助避免网络环境中软件使用受到计算机病毒的入侵，并最大程度的保护数据库中信息的安全性，对于一些比较常见的技术性问题，对于这种配合方法的选择也能够达到更理想的运行效果。系统在运行过程中会对所接收到的信息快速筛选，将其中的有用信息进行归类，这样可以根据使用需求快速的调动数据库内的信息，软件投入使用后也可以根据操作需求对功能进行更新处理，这种方法的实现也需要各个系统之间的相互配合。对存储模式进行对比，观察其中所存在的问题，更有利于下一阶段软件功能设计的实现。
3.4开发设计中的编程技术选择
编程技术选择过程中，要以软件功能的稳定性来进行探讨，观察在系统设计中对资源的利用是否优化，以及可能会出现的功能不稳定现象。针对比较常见的系统功能问题，在编程阶段的技术选择可以采用对比的方法来进行，观察系统功能的稳定性，发现数据传输不准确的现象要及时采取解决控制措施，预防软件的功能出现大面积瘫痪，影响到正常工作使用。程序检测工作开展也是针对这些技术选择问题来进行的，对所开发设计出的软件进行稳定性检测，为系统的运行创造出安全适合的环境，在这样的环境下才能够解决运行稳定性问题，并达到系统需求的工作环境。软件功能稳定性与编程技术的选择之间有很大关系，因此在选择编程方法时要考虑是否可以解决这一技术优化利用的问题。开发初期阶段出现问题可以重新优化基础框架结构，这样后续的建设计划也可以顺序开展，在这样的环境下，计算机程序汇编面临着功能实现与网络环境安全防护的双重任务，实现各项工作任务也是十分复杂的。
关键词：dbms复制联邦数据库
1.引言
随着经济的发展，企业的规模越来越大，其积累的信息也越来越多。存在着各部门所处理的信息多数只对本部门有效，仅有少数信息需给其它某些部门共享的问题。这种信息的分布性和独立性要求对所处理的数据进行分类，使各部门既能独立地处理本部门大多数数据，也使部门间能协调处理跨部门的事务。在这种情况下，对整个企业建立一个完全的紧密耦合的分布式数据库是很困难的，也是没必要的，特别是大型企业，这样的数据库的效率往往是很低的。
为解决这个问题，我们采用以下策略：每个部门使用一套紧密耦合的数据库系统，而在存在跨部门事务处理的数据库系统间用一个协调器联起来。这样就组成了一个横跨整个企业，各部门高度自治的联邦数据库系统。
dm2是由华中理工大学数据库多媒体技术研究所研制的数据库管理系统。它采用客户/服务器模型，客户机与服务器，服务器与服务器均通过网络互连，通过消息相互通讯，组成一个紧密耦合的分布式数据库系统。它的工作流程如下：客户机登录到一台服务器上，这台服务器便成为它的服务器；它接收来自客户机的消息，然后根据全局数据字典决定是自己独立完成该操作，还是与其它服务器协作处理这条消息，处理完成之后，再由服务器将处理结果返回给客户机。
而数据字典，作为记录数据库所有元数据的系统表，它向以上过程中提供各类有用的信息，引导它们向正确的方向运行，起着“指南针”的作用。它分为局部数据字典和全局数据字典。其中，局部数据字典用于记录一个服务器站点中数据库的控制信息，如表的模式，视图的模式及各个数据区的的文件名等信息。全局数据字典用于记录分布式数据库系统中各个服务器站点上有关全局数据的控制信息，如服务器站点信息，各服务器站点的全局表名及表内码记录，各服务器站点上的全局数据视图名及视图内码记录，用户名及口令记录，用户权限记录等信息。各个局部数据字典可以各不相同，但为了保证在各个服务器上所看到的全局数据库是一致的，因此，全局数据字典必须一致。我们所关心的是全局数据字典中的基表控制块tv_ctrl_block，它的内容主要包括：全局基表总数，每个全局基表名和其对应的表内码，该基表所在的服务器站点的编号等信息。它的功能是将各个服务器站点号与存储在其上的表名及表内码联系起来。这样，服务器从客户消息中找到被处理的表名，然后通过查询基表控制块tv_ctrl_block,就能知道该表存在哪个服务器上，以便将相关消息发给该服务器。
由于dm2上各个服务器站点的全局字典完全相同，任何全局表的信息都会记入全局字典。若用它来构建一个企业的数据库系统，则大量只对企业某部门有用的信息将会充斥在各部门所有服务器的全局字典中，增加了冗余。而且，当对全局表进行ddl操作时，为了确保全局字典的一致性，须对所有服务器的全局字典进行加锁。dm2对全局字典的封锁方式是采用令牌环方式，即令牌绕虚环（非实环）传输，某个服务器想对全局字典进行操作，必须等令牌到达该服务器才可以执行。每个部门建立的全局表绝大多数只对本部门有用，当对这些表进行ddl操作时，却要对所有服务器的全局字典进行封锁，通过令牌来实现对全局字典的互斥访问。假如，两个部门都要分别对本部门的内部表进行ddl操作，这应该是可以并行处理的操作，现在却只能串行执行。而且，当服务器数目庞大时，每个服务器等待令牌的时间将会很长。这严重损害了数据库的效率。
为弥补以上不足，在dm2的改进版本dm3中增加了协调器，用以联接各个独立的dm3数据库子系统，并协调各子系统间的各种关系，使各子系统既能高度自治地工作，又能进行有效的信息共享。
2.体系结构
本系统可看作多个数据库子系统被协调器联起来的，高度自治的一个联邦数据库系统。其中，每个子系统独立处理本系统内部的事务，而子系统间的信息共享由复制技术提供，副本间的一致性由协调器协调处理，处理所需的信息在初始化时写入协调器的组间数据字典中。当对某子系统中的一份数据副本进行修改时，该子系统会将修改通知协调器，由协调器对该数据的其它副本进行修改，从而保证了所有副本的一致性。
由以上可知，子系统彼此并不直接接触，而是各自都与协调器直接相联，由协调器统一管理子系统间的通信。这样，当子系统对副本进行修改时，不必关心相应的子系统处于何种状态，也不必等待回应消息，以及异常处理，所有这些都由协调器进行管理。因此，既提高了系统运行的效率，也保证了子系统的独立性。其体系结构如下图所示。
协调器主要有三大功能，首先，它对协调器和服务器进行初始化，并将有关信息存入组间字典；其次，它管理不同子系统间的通信，维护副本的一致性；最后，它在子系统出现崩溃时，进行异常管理及恢复工作。
dm3多数据库系统体系结构
3.主要策略
多个dm3系统间的信息共享是通过副本实现的，副本的一致性是由协调器来维持的，是一种弱一致性。通常，多数据库系统间的一致性是通过协调器周期性地访问服务器的日志来完成的。由于副本的更新带有随机性，因此，若采用这种方法，可能数据被修改多次，但其相对应的副本仍未被修改，这样就损害了数据的一致性；也可能数据并未被修改，但协调器已多次访问了服务器的日志了，这样就降低了系统的效率。
所以，本系统采用的方法是当数据被修改时，由服务器通知协调器有关信息，再由协调器通知相关系统，修改相关数据。这样，数据的修改及时（仍然是弱一致性），而协调器也不会在数据未被修改的情况下访问服务器，提高了准确性。
为了使协调器正常工作，我们对底层数据库管理系统dm2进行了修改。在基表控制块tv_ctrl_block中增加一项isreplication。建表时，该项初始化为false；当为该表建立一个副本时，该项赋值为true。具体算法如下。
3.1初始化算法。
协调器：
从用户或应用程序接收待连接的两个系统中的服务器名，需复制的表名；
分别登录到两个系统的服务器上；
向存有待复制表的服务器发预复制消息；
等待服务器消息；
若失败，发一条失败的消息给服务器和用户或应用程序，转11）；
若成功，从消息中取出待复制表的有关信息，根据这些信息，发一条建表消息给另一个系统的服务器；
等待服务器消息；
若失败，发一条失败的消息给服务器和用户或应用程序，转11）；
若成功，调数据转移程序，进行数据复制；
将有关信息写入组间字典。
退出。
服务器：
当服务器收到预复制消息后，将基表控制块tv_ctrl_block中的isreplication赋为true。同时，取出待复制表的有关信息，组成应答消息发给协调器。
当服务器收到失败的消息后，将基表控制块tv_ctrl_block中的isreplication赋为false。
3.2维护算法。
协调器：
从组间字典读出相关信息，根据这些信息，登录到相应系统上；
等待消息；
从某系统的服务器上收到一条修改消息后，通过查找组间字典，确定该消息的目的地，然后将它转发过去；
若失败，定时重发；
转2）；
服务器：
1）等待消息；
2）当收到某客户或应用程序的消息后，检查它是否是修改数据的操作（如delete，update或insert等）；
若不是，转7）；
若是，检查基表控制块tv_ctrl_block中的isreplication是否为true；
若不是，转7）；
若是，向协调器发修改消息；
继续执行服务器程序的其它部分。
3.3恢复算法。
若协调器所联接的系统中有一个跨掉了，则对副本的修改无法及时地反映到跨掉的系统中来。这时，需要恢复算法来进行处理。
协调器：
当协调器发现有一个系统已经崩溃后，采取以下步骤。
将与该系统相关的变量open赋值为false；
打开记时器；
等待消息；
若收到的消息是其它系统发出的修改崩溃了的系统上的副本的命令，则依次将这些消息存储起来，转3）；
若收到的消息是记时器发出的时间到的消息，则向崩溃的系统发登录命令；
若登录成功，将open的值改为true；
将存储的消息依次发送过去，转9）；
若登录失败，转3）；
退出。
4.结论
我们曾在三个dm3数据库系统上，用两个协调器进行联接。结果，运行情况良好，各副本最终都能保证一致，且各副本间存在差异的时间间隔很短。另外，在出现异常的情况下，协调器也能正常工作。
主要参考文献
1.周龙骧等，分布式数据库管理系统实现技术，科学出版社，1998。
一、实验情境设计
某小型企业已建立采用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)