2022年电子公文管理系统设计与实现

1、高品质文档2022年电子公文管理系统设计与实现 1 引言 公文是政府军队等各类部门请示汇报、命令下达等工作中的重要部分。传统的公文归档以纸质原件为主，存放在档案局等部门，当归档公文数目渐渐增多时，公文的查找就存在效率较低等缺点。尤其是当用户记不清晰公文的详细年份、标题等内容时，在纸质归档公文中进行基于内容的模糊查询几乎无法实现。另外，纸质公文的管理、维护、防腐等，也需要大量的人力物力支持。 随着计算机硬件、局域网设施的普及以及用户计算机水平的不断提高，当前公文的撰写基本都是先完成电子版本，然后再打印传达。因此，将公文的电子版进行归档成为可能1-2。实施电子公文的归档管理3-4，与传统方法相结合

2、，可以在几乎不增加额外劳动量的前提下，对公文的管理、查找、维护工作起到大大的改善效果。 2 系统设计 电子公文管理系统就是在这样的背景下产生的。其目的是在不转变用户公文撰写流程的前提下，完成电子公文的归档、查询等功能。此外，对历史公文的充分借鉴，还可以提高用户公文撰写格式的规范以及公文内容风格的全都性等。 系统采纳标准的客户端-服务器模式（c-s模式），由oracle数据库服务器5对电子公文的存储、查询供应支持。客户端软件由delphi实现，包括公文模板管理、公文归档、公文撰写、临时公文管理、公文查询和系统设置六大模块，如图1所示。 “公文模板管理”可以将常用的空白公文模板存储到数据库中，用户

3、可以据此撰写新的公文。“公文撰写”模块可以依据公文模板或已经归档的历史公文，撰写新的公文。用户只需修改其中的内容即可，而不用再过多关怀其格式等内容，提高公文撰写的效率。“临时公文管理”对新撰写的公文以及尚未定稿的公文进行管理，支持同一公文的多个不同版本，并可以将临时公文准时上传备份到服务器以防丢失，同时能够便利地从其它机器阅读修改公文。“公文归档”对于已经完成的公文，可以归档录入数据库，以便利将来查阅。系统供应单个公文归档、批量归档等多种归档方式，并能够通过“公文自动分析”功能解析出公文中的项目，如标题、关键字等，削减公文归档的工作量，提高系统可用性和效率；同时还可以将领导签字照片等附件一同录

4、入，以提高公文归档的完整性可用性。“公文查询”模块能够对全部已归档的公文进行高效查询。除了支持敏捷的根据各种项目自定义条件查询外，还支持基于内容的查询，即可以查找内容中包含指定文字的全部公文。最终，“系统设置”模块包括不同部门、不同级别用户的用户管理及权限掌握功能，敏捷的数据库连接参数配置功能等。 3 关键技术 系统实现的主要难点和创新包括以下几个方面：1）公文在oracle数据库中的存取掌握；2）公文内容的自动解析和批量归档；3）基于公文内容的全文检索查询；4）本地文档与数据库备份文档的比较及版本掌握。 3.1 公文在数据库中的存取 一个公文由许多元素组成，如标题、发文机关、公文种类、年份、

5、主题词、引发说明、承办说明、正文等等2。在数据库中的存取有两个方案：一是将各种元素分开存储，用户预览全文时再根据公文格式要求合并成一个文档。该方案的好处是分开存储便于用户的查询；不足是当合成新文档是需要考虑公文的格式要求。因为公文类型繁多，因此恢复新文档的操作简单，而且往往难以完全恢复原样。第二个方案是将整个文档采纳二进制方式存储在数据库中。这样的好处是文档的恢复比较简洁，但是由于各个元素没有分别，因此在公文的查询方面存在不足，需要解析文档内容并逐个分别出元素信息，效率较低，难以满意快速、敏捷的查询需求。 通过分析比较，系统采纳了一个折中方案：对于除正文以外的其它元素，如标题、发文机关、年份等

6、，在数据库中分别在不同字段中分别存储，以便利用户的查询；同时又将文档本身进行存储，以便于公文的恢复。该方案以肯定的存储开销为代价，较好地照看了查询操作和公文恢复操作。因为除正文以外的其它元素内容很少，通过数据库中的日期型字段、 varchar字段等即可满意要求，因此引入的额外开销特别小。试验部分证明白该方法的有效性。 公文文档存放在oracle中的blob字段中，详细是通过delphi中tblobfield类的loadfromfile()和savetofile()方法实现了数据库的存入和读出。 3.2 公文内容的自动解析和批量归档 为了解决在公文归档过程中手工输入各种元素信息的效率问题，系统实

7、现了公文内容的自动解析。依据公文格式规定，通过程序对指定的公文进行自动分析，解析出各种元素的内容，然后自动填入数据库。 delphi供应了两个类：twordapplication和tworddocument3。前者可以连接到ms word应用程序中，后者可以连接到一个word文档。公文中的每一段、每一行以及每一个表格，都可以通过tworddocument对应的如paragraph、line 以及table对象等获得。依据公文承办规定中对相关元素位置、格式的定义，协作识别元素的关键词信息，通过逐段逐行分析，就可以解析得到元素内容。 实现了对一个公文的解析功能，再协作findfirst、findn

8、ext以及findclose等windows的api函数的递归调用，就可以查找指定路径下（包括子名目）的全部word文档，然后逐一对之进行解析并将分析结果入库，就可以实现公文批量归档的功能。 公文内容自动解析及批量归档功能的实现，简化了公文归档的工作量，用户只需指定文件或者路径，系统即可自动完成剩余工作，大大提高了公文归档的效率。 3.3 基于内容的全文检索查询 指定通过公文标题、发文机关等元素内容，查找满意条件的公文，是基本的数据库查询操作，比较简单实现。但是在公文的查找中存在一类需求，即用户只记得公文的大致内容，如公文内容中包含的几个关键词，但是关于公文更具体的内容如发文时间、发文机关名称

9、等并不清除。在这种状况下需要对公文进行基于内容的全文检索查询。 该功能的实现流程如图2所示。对数据库中的每条记录，均先将对应的word文档保存到本地，然后用delphi的tworddocument类打开。tworddocument类的content属性为range对象，调用其find.execute()方法可以在该范围内进行文本查找，功能与word应用程序中调用“编辑-查找”功能菜单一样，不仅可以进行基本的查找，还可以通过参数掌握在查找过程中是否区分大小写、是否使用通配符等。假如匹配胜利，则该方法返回true，系统为该条记录做好标记，作为查询结果中的一条进行显示。当数据库中全部的记录都处理完后

10、，查询处理结束，全部被标记的记录均为满意条件的结果，即内容中包含指定关键词的公文。 3.4 文档版本掌握 “临时公文管理”模块主要是将正在撰写尚未正式定稿的公文存放到数据库中进行备份，同时支持同一稿件在撰写修改过程中产生的多个不同版本维护功能。文档修改前后的比较、版本掌握是这一模块的主要技术点。 版本掌握主要是通过猎取文件最近修改时间来实现的。详细来说包括以下步骤：1）系统启动时，通过oracle中的sysdate函数取得数据库服务器的当前时间，并将客户端时间与服务器时间进行自动同步；2）临时公文上传到服务器进行备份时，获得文件的最近修改时间并保存在数据库中的updatetime字段中；3）检

11、查本地文件与数据库备份文件是否全都时，再次获得本地文件的最近修改时间，通过与数据库中保存的时间进行比 较完成。 猎取文件最近修改时间功能实现，主要是通过windows的api函数findfirstfile()获得文件属性数据，该数据的ftlastwritetime属性即为文件的最终修改时间。值得留意的是，该属性获得的是用32位表示的文件时间戳，为操作系统使用。要想转换为用户能看懂的本地系统时间，需要通过filetimetolocalfiletime()、filetimetosystemtime()以及systemtimetodatetime()函数进行转换。 4 测试验证 为了验证依据上述分析

12、设计的有效性，对已实现的公文管理系统进行了测试验证。 4.1 试验设置 试验在2台pc机组成的局域网内进行。数据库服务器的基本配置为piv 2.0g cpu，1g内存，120g硬盘，其上安装了oracle 9i；客户端pc机配置为piii 1g cpu，512m内存，80g硬盘，安装了oracle客户端和office XX软件。 试验数据集为某单位XX-XX.6产生的500个实际公文文件，大小从50k到500k不等，平均大小约为200k。在其上进行了存储开销比较、查询性能、自动归档性能以及全文检干脆能的试验。 4.2 试验结果 采纳三种存储方案对公文进行存储，考查随公文数增加不同方案存储开销之

13、间的差异，如图3所示。其中方案一为全部元素均分别存储；方案二为仅存储完整的公文文件；方案三为本文实行的折中方案。 可以看出，方案一所需空间最小，方案二其次，方案三所需空间最大。这是因为，方案一仅保存了必需的文本内容，而且不同元素之间相互无重叠冗余；而方案二存储的完整文件除了包含字符格式、字体等信息外，还包含doc文件必需的文件格式头等内容，因此所需空间较大。方案三在方案二的基础上还冗余存储了一些元素内容，因此所需空间最大。但总体看来，方案三与方案二相比，额外所需的存储空间并不是很大，约占文件大小的0.51%左右。 三种存储方案下一般查询的效率和原文档恢复所需时间分 比较别如图4、图5所示。可以

14、看出，方案三一般查询的效率与方案一几乎没有差别，受益于oracle数据库管理系统的查询性能，在试验数据规模上返回结果的时间为毫秒级；而方案二由于需要还原文件后再进行全文检索，所需时间较长，尤其随着数据库中记录数增加所需时间也线性增加，当数据规模较大时难以满意用户需求。而在文档恢复方面，方案一需要将全部内容进行重组，并根据公文承办规定设置相关元素的格式等，所需时间为秒级，而且恢复效果较差；而方案二和方案三直接从数据库中读取完整文档并恢复，所需时间仅为毫秒级。 在采纳第三种存储方案实现的系统中，随归档文档数的增加，系统自动归档所需时间状况如图6所示。可以看出，系统具有较高的自动分析和批量归档功能，平均每个文档所需的分析归档时间不足1秒。因此能够较好满意归档需求。 系统全文检索效率如图7所示。可以看出，全文检索所需时间与随公文数