电子文件管理系统的设计与实现

1、 4/4电子文件管理系统的设计与实现1导言公文是政府、军队等部门请示和发布命令工作的重要组成部分。传统的文件归档主要以纸质原件为主，存放在档案馆等部门。当归档文档的数量逐渐增加时，文档搜索的效率较低。特别是当用户记不清公文的具体年份、标题等内容时，很难实现基于纸质文档中内容的模糊查询。此外，纸质文件的管理、维护和防腐也需要大量的人力和物力支持。随着计算机硬件和局域网设施的普及以及用户计算机水平的不断提高，目前公文的电子版基本上是先完成，再打印传送。因此，可以将正式文件的电子版本存档1-2。实施电子公文的归档管理3-4，结合传统方法，可以在不增加额外劳动的情况下，大大提高公文的管理、检索和维护。

2、2系统设计电子公文管理系统就是在这样的背景下产生的。其目的是在不改变用户文档编写流程的情况下，完成电子文档的归档和查询功能。此外，充分利用历史文档还可以提高用户文档书写格式的规范性和文档内容风格的一致性。系统采用标准的客户端-服务器模式(c-s模式)，oracle数据库服务器5支持电子公文的存储和查询。客户端软件采用delphi实现，包括文档模板管理、文档归档、文档编写、临时文档管理、文档查询和系统设置六个模块，如图1所示。“文档模板管理”可以在数据库中存储常见的空白文档模板，用户可以据此编写新文档。“文档编写”模块可以根据文档模板或归档的历史文档编写新文档。用户只需对内容进行修改，而不必过于

3、关注格式和其他内容，从而提高文档编写的效率。“临时文档管理”管理新编写的文档和尚未定稿的文档，支持同一文档的多个版本，可以及时将临时文档上传和备份到服务器，防止丢失。同时方便从其他机器读取和修改文档。“文件归档”是指已完成的文件，可以归档到数据库中备查。系统提供了单文档归档、批量归档等多种归档方式，通过“自动文档分析”功能，可以对公文中的标题、关键词等项目进行分析，减少了文档归档的工作量，提高了系统的可用性和效率；同时，领导签字的照片等附件可以一起录入，提高文件归档的完整性和可用性。“文档查询”模块可以高效地查询所有存档的文档。除了支持根据各种项目的自定义条件进行灵活查询外，还支持基于内容的查

4、询，即可以找到所有内容包含指定字符的公文。最后，“系统设置”模块包括针对不同部门、不同级别用户的用户管理和权限控制功能，以及灵活的数据库连接参数配置功能。3.关键技术系统实施中的主要难点和创新点包括以下几个方面：oracle数据库中公文的访问控制；2)文件内容的自动分析和批量归档；3)基于文档内容的全文检索；4)本地文档和数据库备份文档的比较和版本控制。3.1数据库中正式文件的访问一份文件由许多要素组成，如标题、签发机关、文件类型、年份、主题词、启动说明、承诺说明、文本等。数据库中有两种访问方案：一种是将各种元素分别存储，然后在用户预览全文时根据文档格式要求合并成一个文档。该方案的优点是方便用

5、户单独存储查询；缺点是在合成新文档时，需要考虑公文的格式要求。由于公文种类繁多，恢复新文档的操作比较复杂，往往很难完全恢复原始文档。第二种方案是将整个文档以二进制方式存储在数据库中。这样做的好处是文档恢复比较简单，但是因为每个元素没有分开，所以在文档查询上有缺点。需要对文档内容进行分析，逐个分离元素信息，效率低下，难以满足快速灵活的查询要求。通过分析比较，系统采用了折中方案：对于除文本以外的其他要素，如标题、颁发机关、年份等。它们分别存储在数据库的不同字段中，以方便用户查询；同时，文档本身被存储，以便于官方文档的恢复。该方案以一定的存储开销为代价，兼顾了查询操作和文档恢复操作。因为除了文本之外

6、几乎没有其他元素，所以数据库中的日期字段和varchar字段可以满足要求，所以引入的额外开销非常小。实验部分证明了该方法的有效性。官方文档存储在oracle中的blob字段中，数据库的存储和读取是通过delphi中T BLOBFILE类的loadfromfile()和savetofile()方法实现的。3.2文件内容的自动分析和批量归档为了解决文件归档过程中人工输入各种要素信息的效率问题，系统实现了文件内容的自动分析。根据文档格式的规定，由程序自动分析指定的文档，解析各种元素的内容，然后自动填充到数据库中。Delphi提供了两个类：网络应用和网络文档3。前者可以连接到ms word应用程序，而

7、后者可以连接到word文档。公文中的每一段、每一行、每一张表格都可以用网络文档来显示，如段落、行等和表对象。根据公文承办规定中相关要素的位置和格式的定义，结合识别要素的关键词信息，逐段逐行分析即可得到要素内容。实现了一个文档的分析功能，通过findfirst、findnext、findclose等windows api函数的递归调用，可以找到指定路径下(包括子目录)的所有word文档，然后对所有文档进行逐一分析，并将分析结果存入存储器，从而实现文档批量归档的功能。文件内容自动分析和批量归档的实现，简化了文件归档的工作量。用户只需指定文件或路径，系统就可以自动完成剩余的工作，大大提高了文档归档的

8、效率。3.3基于内容的全文检索查询通过文档标题、文档发布权限等元素查找符合条件的文档是一个基本的数据库查询操作，易于实现。但是在公文的搜索中有一种需求，就是用户只记住公文的大概内容，比如公文中包含的几个关键词，而对于公文中比较详细的内容，比如发文时间、发文机关名称等，则不清理。这种情况下，需要对公文进行基于内容的全文搜索。该功能的实现流程如图2所示。对于数据库中的每条记录，首先在本地保存相应的word文档，然后用delphi的tworddocument类打开。tworddocument类的content属性是一个range对象，调用它的find.execute()方法可以搜索该范围内的文本。功

9、能和在word应用中调用Edit-Find功能菜单一样，既可以进行基本搜索，又可以通过参数控制搜索过程中是否区分大小写，是否使用通配符。如果匹配成功，该方法返回true，系统标记该记录并将其显示为查询结果之一。当数据库中的所有记录都处理完毕后，查询处理结束，所有标记的记录都是符合条件的结果，即内容包含指定关键字的公文。3.4文件版本控制“临时文档管理”模块主要是将正在编写的尚未正式定稿的正式文档存储在数据库中进行备份，同时支持同一稿件在编写和修改过程中生成的多个不同版本的维护功能。文档修改前后的对比和版本控制是本模块的主要技术要点。版本控制主要通过获取文件的最新修改时间来实现。具体包括以下步骤

10、：1)系统启动时，通过oracle中的sysdate函数获取数据库服务器的当前时间，客户端时间自动与服务器时间同步；2)临时公文上传到服务器备份时，获取文件的最新修改时间，保存在数据库的updatetime字段中；3)在检查本地文件是否与数据库备份文件一致时，再次获取本地文件的最新修改时间，并与数据库中保存的时间进行比较更完整。获取文件最新修改时间的功能主要是通过windows的api函数findfirstfile()获取文件属性数据来实现的，数据的ftlastwritetime属性是文件的最后修改时间。值得注意的是，这个属性获取32位表示的文件时间戳，操作系统使用。为了转换成用户可以理解的本

11、地系统时间，我们需要使用filetimetolocalfiletime()，filetimetosystemtime()和systemtimetodatetime()函数来转换。4测试验证为了验证基于上述分析的设计的有效性，对实现的文档管理系统进行了测试和验证。4.1实验设置实验是在由两台电脑组成的局域网中进行的。数据库服务器的基本配置是piv 2.0g cpu，1g内存，120g硬盘，上面安装了Oracle9i。客户端电脑配置piii 1g cpu，512m内存，80g硬盘，安装oracle客户端和office XX软件。实验数据集由某公司XX-XX.6生产的500份实际官方文档组成，大小从

12、50k到500k不等，平均大小约为200k。对存储开销比较、查询性能、自动归档性能和全文检索性能进行了实验。4.2实验结果使用三种存储方案存储公文，考察不同方案的存储成本随公文增加的差异，如图3所示。在第一种方案中，所有元素都是分开存储的；方案二只存储完整的公文；方案3是本文采用的折中方案。可以看出，方案1需要的空间最小，方案2次之，方案3需要的空间最大。这是因为第一种方案只保存了必要的文本内容，不同元素之间没有重叠冗余；在第二种方案中，完整的文件不仅包含字符格式、字体等信息，还包含doc文件所需的文件格式，因此所需空间较大。方案三也是在方案二的基础上冗余存储一些元素内容，所以需要的空间最大。

13、但一般来说，相比方案2，方案3所需的额外存储空间不是很大，约占文件大小的0.51%。三种存储方案下常用查询的效率和恢复原始文档所需的时间对比见图4和图5。可以看出，方案3中普通查询的效率与方案1中几乎相同。得益于oracle数据库管理系统的查询性能，实验数据规模返回结果的时间为毫秒级；而第二种方案需要在全文检索之前恢复文件，耗时较长，尤其是随着数据库中记录数量的增加，在数据规模较大时很难满足用户的需求。在公文回收方面，方案一需要按照公文承办规定对所有内容进行重组，设置相关要素的格式，耗时数秒，回收效果差；但是方案2和方案3直接从数据库中读取完整的文档并还原，只需要几毫秒。在第三种存储方案实现的系统中，随着归档文档数量的增加，自动归档所需的时间如图6所示。可以看出，系统具有很高的自动分析和批量归档功能，每个文档的平均分析和归档时间不到1秒。所以可以很好的满足备案要求。系统的全文检索效率如图7所示。可以看出，全文检索所需时间随着正式文件数量的增加而线性