数据库技术在公文管理系统的应用

数据库技术在公文管理系统的应用

葛志春（来自CSAI）　　　　2003年03月01日

　　摘要：数据库是当前应用软件系统的重要组成部分，如何使基于数据库的应用系统安全、可靠、高效的运行一直是软件开发技术研究的难题。本文就公文管理系统产品中采用的数据库技术，从数据库的选择、数据库的设计、查询优化及安全控制等方面讨论这方面的问题。

　　关键词：Web服务器 、DBMS、查询优化、安全性。

　　随着信息化技术的发展普及，行政机关公文电子化工作正进一步展开，电子化公文管理成为政府机关的一个战略性课题，但当前公文管理技术与标准还不够成熟，为了进一步推动政府信息化的建设，必须进一步研究开发适应新时代的基于Internet和Intranet的公文管理系统，以提高机关公文办理效率，提升政府绩效。

　　在这一市场机遇下，我作为公司的一名技术骨干，主持开发了我司的公文管理系统产品--DocMan公文管理系统(以下简称：DocMan)，并参与完成了产品的规划、需求分析、设计以及部分代码的编写工作。

　　现本人就，在开发该产品时遇到的有关数据库技术方面的问题以及采用的策略介绍如下，以作交流。

　　一、系统平台及数据库管理系统选择

　　DocMan公文管理系统是面向政府机关公文处理系统，是电子政务的主要组成部分，因此，DocMan和其他电子政务子系统一样,存在跨平台分布、异构、和政府原有应用系统进行整合的问题。为了面对各类型机关的应用需要，我们DocMan公文管理系统，采用了多层B/S架构（客户端浏览器层、Web服务器层、应用服务器层、数据库层）、并采用了J2EE及EJB技术实现系统的分布异构及跨平台。为了满足各类型机关的需要，我们对流行操作系统（Win32系列，Unix系列，linux系列）、Web服务器（Tomcat4.0,IBM WebSphere4.0,BEA WebLogic 5.0）、及数据库管理系统(Oracle ,SQL Server , Sybase,Infomix,DB2等)都给予尽量的支持。在考虑大型机关应用时，我们选用了代理服务器、多并行Web服务器及多应用服务器技术实现系统的负载均衡和流量管理；但由于当前分布式数据库的应用不够成熟，我们采用了集中式数据库技术实现机关数据的存放。

　　二、数据库设计

　　1．产品跨数据库管理系统的设计

　　在系统数据库选择时由于我们有跨多数据库的需求，因此在系统数据库物理设计时对跨数据库的设计成了我们的关键问题之一。在解决该问题时我们首先对各种类型的数据库作了对比，之后，主要采用了以下策略来达到目的。

　　1）数据库字段类型的选择。为了适合各种数据库的需要，我们采用了以下三种字段类型：长整形、字符串型、二进制型。取消自动递增的字段类型。符点型，采用字符串代替；日期型用长整形代替，如果精确到天，则用一个字段8位长整形替代，如20020203，如果精确到分钟，则用2个字段8位长整形替代，第一个是精确到分钟，结构同上，第二个采用24时制并且精确到0.01秒，如：21533203。

　　2）DDL与DML的选择。由于系统在初始化时可以一次性的建好所有数据库、各种表、视图、索引等；因此我们可以对不同的数据库采用不同的DDL,也即对于DDL的使用我们并不加以限制。而对于DML,因为各种数据库厂商并没有严格的采用标准SQL-92, 所以各种数据库管理系统（DBMS）之间的互操作性存在较大的问题；对此，我们规定在对数据库操作处理时，尽量只采用标准的简单的通用的SQL语句，如果确实需要使用复杂的查询时可以采用Swithc ,Case语句，针对不同的DBMS写不同的查询语句。

　　3）数据库函数的使用。对于数据库函数的选用，我们只采用了标准通用的（各种DBMS都一样的）的函数，而非标准的不予使用。

　　4）存储过程。由于各种DBMS的存储过程处理机制都不一样，因此我们对存储过程不予采用。
通过以上规定，好像我们的数据库系统的性能并没有很好的发挥，而只仅仅取到了数据存储的作用。但这一设计，也恰好减轻了我们集中式数据库的负载。

　　2．减轻数据库管理系统负载的设计

　　由于我们的系统采用的是集中式数据库技术，对于大型机关的应用集中式数据存储将会成为系统的主要瓶颈。因此，在系统设计时我们应该考虑尽量的减轻数据库的负载。在这个方面，我们主要采用了以下策略解决。

　　1）应用计算的转移。由于我们的系统可以采用多Web服务器和多应用服务器机制，所以在系统均衡负载时，我们主要考虑将系统逻辑计算转移到应用层，尽量不把系统计算转移到数据库层。

　　2）事实上，其他数据库设计方面的考虑，也达到了减轻DBMS负载的作用。

　　3．数据库规范化与非规范化的考虑

　　数据库被规范化后，减少了数据冗余，数据量变小，数据行变窄。这样DBMS的每一页可以包括更多行，那么每一区里的数据量更多，从而加速表的扫描，改进了单个表的查询性能。但是，当查询涉及多个表的时候，需要用很多连接操作把信息从各个表中组合在一起，导致更高的CPU和I/O花销。那么，有很多时候需要在规范化和非规范化之间保持平衡，用适当的冗余信息来减少系统开销，用空间代价来换取时间代价。有订单信息表OrderDetail，它里面记录了投递员信息，收款员信息，物品信息，价格策略，客户信息…..这些信息分别在投递员信息表、收款员信息表、物品信息表、价格策略表、客户信息表中存放。如果按照规范化的要求，OrderDetail查询时就必须要与这么多个表进行连接或者嵌套查询。如果OrderDetail表中的数据量是在百万级的，那么一次查询所需要的时间可能会达到好几个小时。事实上，只要在设计时保证数据的逻辑有效性，很多信息都可以直接冗余在OrderDetail表中，这些冗余的数据能够极大的提高查询的效率，从而减少CPU和I/O操作。

　　4.数据条带化设计

　　如果一个表的记录条数超过一定的规模，那么最基本的查询操作也会受到影响，需要将该表根据日期水平划分,把最近、最经常用的数据和历史的、不经常用的数据划分开来，或是根据地理位置、部门等等进行划分。还有一种划分方式是采用垂直划分，即把一个属性列很多的表分割成好几个小表，比如把经常用到的属性放在一个表里，不经常用到的属性放在另一个表里，这样可以加快表的扫描，提高效率。如DocMan的公文表，对于公文实体而言它有三十多个属性；并且由于系统对该实体的操作是最频繁的，对于一个市级机关来说系统对该实体一天Insert操作量将达到上万笔（机关收一份文或创一份文都将产生一笔Insert操作）；因此我们首先采用了垂直划分方法，将常用于查询的属性归入一个表，不常用的属性归入一个表，然后我们将设计好的表按时间水平划分，半年的数据存入一个表，这样对于一个市级机关来说，一个公文表的记录将不会超过300万条，大大提高了操作效率。

　　5．主键设计规定

　　主键用整型会极大的提高查询效率，而字符型的比较开销要比整型的比较开销大很多，用字符型数据作主键会使数据插入、更新与查询的效率降低。数据量小的时候这点降低可能不会被注意，可是当数据量大的时候，小的改进也能够提高系统的响应速度。因此，我们在数据库设计时，都采用整形作为关键字。

　　6．索引选择的考虑　

　　索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。使用索引可以快速、直接、有序的存取数据。索引的建立虽然加快了查询，另一方面却将低了数据更新的速度，因为新数据不仅要增加到表中，也要增加到索引中。另外，索引还需要额外的磁盘空间和维护开销。因此，要合理使用索引：

　　●在经常进行连接，但是没有指定为外键的属性列上建立索引。

　　●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。按索引来排序或分组，可以提高效率。

　　●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。

　　●如果待排序的列有多个，可以在这些列上建立复合索引（compound index），即索引由多个字段复合而成。

　　三、数据查询优化

　　在系统编码阶段，程序员所写的SQL语句将对系统的性能、响应时间产生重大的影响。很难想像用户所提交的原本很糟糕的查询语句经过DBMS优化后会变得高效，因此程序在编码时所写的SQL语句的优劣至关重要。因此，我们在系统编码前作了如下的指导说明，以便程序员能尽量的写出高效率的SQL语句。

　　1．排序

　　在很多时候，应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，可以避免排序的步骤，当以下的情况发生时，排序就不能省略：

　　●索引中不包括一个或几个待排序的列；

　　●group by或order by子句中列的次序与索引的次序不一样；

　　●排序的列来自不同的表。

　　为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表，尽管有时可能影响表的规范化，但相对于效率的提高是值得的。如果排序不可避免，那么应当试图简化它，如缩小排序列的范围等。

　　2．嵌套查询

　　在SQL语言中，一个查询块可以作为另一个查询块中谓词的一个操作数。因此，SQL查询可以层层嵌套。例如在一个大型分布式数据库系统中，有订单表Order、订单信息表OrderDetail，如果需要两表关联查询：

SELECT CreateUser
FROM Order
WHERE OrderNo IN
( SELECT OrderNo
FROM OrderDetail
WHERE Price=0.5)

　　在这个查询中，找出报纸单价为0.5元的收订员名单。下层查询返回一组值给上层查询，然后由上层查询块再根据下层块提供的值继续查询。在这种嵌套查询中，对上层查询的每一个值OrderNo，下层查询都要对表OrderDetail进行全部扫描，执行效率显然不会高。在该查询中，有2层嵌套，如果每层都查询1000行，那么这个查询就要查询100万行数据。在系统开销中，对表Order的扫描占82％，对表OrderDetail的搜索占16％。如果我们用连接来代替，即：

SELECT CreateUser
FROM Order,OrderDetail
WHERE Order.OrderNo=OrderDetail.OrderNo AND Praice=0.5

　　那么对表Order的扫描占74％，对表OrderDetail的搜索占14％。
而且，一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。

　　3．通配符

　　在SQL语句中，LIKE关键字支持通配符匹配，但这种匹配特别耗费时间。例如：SELECT * FROM Order WHERE CreateUser LIKE 'M_ _ _' 。即使在CreateUser字段上建立了索引，在这种情况下也还是采用顺序扫描的方式，Order表中有1000条记录，就需要比较1000次。如果把语句改为SELECT * FROM Order WHERE CreateUser >'M' AND CreateUser <'N'，在执行查询时就会利用索引来查询，显然会大大提高速度。

　　4．Distinct

　　使用distinct是为了保证在结果集中不出现重复值，但是distinct会产生一张工作表，并进行排序来删除重复记录，这会大大增加查询和I/O的操作次数。因此应当避免使用distinct关键字。

　　5．负逻辑

　　负逻辑如!=、<>、not in等，都会导致DBMS用表扫描来完成查询。当表较大时，会严重影响系统性能，可以用别的操作来代替。

　　6.临时表

　　使用临时表时数据库会在磁盘中建立相应的数据结构，因为内存的访问速度远远大于外部存储器的访问速度，在复杂查询中使用临时表时，中间结果会被导入到临时表中，这种磁盘操作会大大降低查询效率。另外，在分布式系统中，临时表的使用还会带来多个查询进程之间的同步问题。所以，在进行复杂查询时最好不要使用临时表。另外，由于我们在数据库设计时，已考虑在系统运行过程中不执行DDL语句，所有的DDL语句在系统初始化时完成。因此，实际上我们已禁止了临时表的使用。

　　四、数据库安全性的设计

　　系统的安全性相关因素有多种，其中软件系统本身的安全是系统安全的关键因素。软件系统的安全主要依赖于应用系统本身的安全和数据库管理系统的安全。在DocMan中我们主要采用了以下几种策略来保证系统及数据的安全：

　　系统权限控制。系统权限控制分为，系统身份认证和系统授权控制2类。

　　系统身份认证，要求用户在使用DocMan系统时首先向DocMan输入用户名和密码，以便计算机确认该用户的真实身份、防止冒名顶替；并作为授权控制的基础。

　　系统授权控制，当用户已被DocMan接受并被注册登陆到系统后，要求调用程序和数据时，DocMan权限管理模块核对用户权限，根据用户对该项资源的权限控制对其进行存取。

　　系统数据的完整性约束。在DocMan中我们主要通过两个方面来保证系统数据的完整性：数据库本身的约束机制和系统实体类自身提供方法来检查数据的完整性。 保证DocMan系统配置参数不被非法更改，保护DocMan数据不被非法修改和删除。保证数据库中存在不符合语义的数据，防止错误信息的输入输出，即所谓的垃圾进垃圾出所造成的无效操作和错误结果。

　　系统数据备份。系统的数据备份主要包括数据安全备份和数据期间备份。

　　数据安全备份，DocMan系统除了可以使用数据库管理系统自身提供的数据备份/恢复机制外，系统本身还提供数据的备份/恢复功能。DocMan的数据安全备份具备两个子功能，完全备份和增量备份。完全备份可以将当前运行库的数据导入到另一备份数据库。增量备份，系统采用日志管理模块实时记录所有的数据库成功更新操作；系统管理员可以定期的将这些实时记录的更新SQL语句，在备份库重新执行；即可以达到增量备份目的。DocMan系统通过这种备份机制不但达到了安全备份功能，同时也达到了系统7*24的运行目的；当运行库挡机时，DocMan系统可以将数据库连接转到备份库继续运行。

　　数据期间备份，DocMan系统在大型政府机关运行时，系统日交易量是相当大的，一天可能达到几万笔。因此，系统在运行一段时间后数据库的数据量也是海量的；系统拖着海量的数据运行，将会严重影响系统的运行效率。而对于公文管理系统来说，公文及其办理数据只在公文办理以及对公文办理人员进行考核时有用，之后，都不在使用。因此，我们在DocMan中提供了定期备份功能；容许系统管理员进行对数据的期间备份，如 采用半年备份一次，将上一年的系统不再使用的数据转储到文件或另一数据库。

　　系统日志管理。在DocMan中我们通过系统日志管理模块，记录每一个用户对每一个数据项所做的增加、修改、删除操作，并记录操作结果。对重要的数据查询也作记录。使用户对系统数据的操作，具有不可抵赖性。

　　五、结论

　　以上主要介绍了我们在开发公文管理系统产品时采用的数据库技术。通过以上技术的应用使我们的产品实现了跨多数据库管理系统的目标，大大提高了系统的安全性、可靠性、高效性，为保证DocMan的7*24的运行提供了良好的基础。现DocMan已经取得了良好的应用，并产生了很好的社会经济价值。主要案例有：青岛保税区电子政务系统、台北市公文管理系统、台湾铁路局公文管理系统、台湾地质调查所公文管理系统、台湾东吴大学公文管理系统等。在DocMan广泛应用的同时我们也发现了其存在着一些不足之处，有待于我们进一步改善。

参考文献

[1]ORight数据库设计考虑，云集软件网络（中国）有限公司；
[2]彭文静， 基于DB2的数据库应用系统的性能优化，兰州大学信息工程学院；
[3]葛志春，Web化公文管理系统的设计与实现，云集软件网络（中国）有限公司；
[4]葛志春，公文管理系统安全需求说明书，云集软件网络（中国）有限公司；
[5]付继兵，Oracle 8入门与提高，清华大学出版社；
[6]萨师煊、王珊 ，数据库系统概论 ，高等教育出版社。