资源数字化的数据库设计与实现_第1页
资源数字化的数据库设计与实现_第2页
资源数字化的数据库设计与实现_第3页
资源数字化的数据库设计与实现_第4页
资源数字化的数据库设计与实现_第5页
已阅读5页,还剩32页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、1 资源数字化的数据库设计与实现本章主要叙述图书馆自动化管理系统如何针对给定的软件、硬件环境,根据图书馆数字化的实际要求,设计出一个合理的数据模型,从而建立其应用系统。该过程为概念模型设计、物理模型设计、规范化设计、模型优化设计、完整性设计。1.1 概念设计使用IDEF1X建模进行概念设计如下:(1)标识相关实体地方文献数字化工作涉及到大连市地方出版物、地方作家作品等一系列地方文献的数字化工作。初步确定地方出版物全文库有以下几个实体类型:图书基本信息、目录信息、文摘信息、全文信息、全文索引信息、责任者信息、出版发行信息、著录人员信息、著录单位信息、著录部门、地方文献上传记录信息。(2)编号与命

2、名实体经过上一步的工作,得到初步的实体。对这些实体进行编号和命名,以实体表的形式记录下来。地方文献实体表形式如表3.1所示。其中编号为统一编号,实体名要符合约定的规则。表3.1 地方文献实体表实体编号实体名称实体描述1234567891011LLBookLLMLLLWJLLQWLLdbLLWritLPubLLlbLLRecLLPartLLUp描述文献基本信息描述文献目录信息描述文献文摘信息描述文献全文信息描述文献所在数据表名称描述文献责任者的基本信息描述文献出版发行信息描述文献类别基本信息描述著录文献录入的记录信息描述著录单位基本信息描述上传地方文献纪录在这个阶段中,可以初步识别出大部分的实体

3、,随着建模工作的进行,会增加新的实体或删除原先识别的实体。(3)定义联系采用IDEF1X模型建模不可能将地方文献数字化中所有实体可能的联系表达出来,只能通过已经存在的依赖性来定义实体间的相互联系。每个关系模式可能为一对一、一对多(多对一)、多对多(n:m)的不同形式22,23。例如每一个著录者可以著录多种文献,而每一种文献只能由一个著录者完成,这是典型的一对多的联系。在地方文献数字化的建模初期,允许存在非确定性的联系。非确定性联系也就是n:m,表示两个实体之间的关系,在以后的建模过程中,可以逐步地将n元联系转换为n个二元的联系来表示24,25。为了标识各实体之间的关系,采用联系矩阵工具。该联系

4、矩阵是一个有水平和垂直轴线的二维数组,两条轴线表示相同的实体,也就是由实体名组成,实体与实体间关系表示是由它们之间的联系符号组成,“*”表示两个实体之间可能存在联系,由于这种方法是上下对称的,只需表示这个矩阵的上半部分。如表3.2所示。表3.2 标识地方文献联系矩阵LLBookLLMLLLWJLLQWLLdbLLWritLLPubLLlbLLRecLLPartLLUpLLBook-*LLML-LLWJ-LLQW-*LLdb-LLWrit-LLPub-LLlb-*LLRec-*LLPart-LLUp-为了表示文献实体之间的依赖,必须从两个方向来检查两个实体之间的依赖关系。为了明确对于实体A与实体

5、B之间的依赖关系,先确定对于实体A来说,有多少实体B与之相对应,然后再从反方向来检查,重复这一步骤。举例来说:考虑文献基本信息LLBook实体与文献目录信息LLML之间的联系。一个目录只能存在一种文献的信息中,而一种文献可以有多个目录。因此实体LLBook与实体LLML之间的关系是一对多的关系,这是一个确定型的联系。而实体LLBook与实体LLWrit责任者基本信息项之间的联系则有所不同,一个责任者可以写一种或多种文献作品,一种文献作品可以由一个或几个责任者完成。所以LLBook实体与LLWrit实体之间的关系是多对多的关系,这是一个非确定型的联系,这种非确定型的联系必须在建模的过程中逐步消除

6、。在明确了联系的形式后,为联系命名。如:LLBook和LLWrit实体之间的联系名为由著/著。(4)构造实体级图在定义了联系后,构造地方文献数字化实体图作为一个初始的IDEF1X图。图中的方盒子表示在初始图中,允许存在非确定型联系。如图3.1所示的是一个关于地方作家文献的部分实体级图。图3.1 一种文献的部分实体级图Fig. 3.1 The part entity level figure of one kind of literature(5)转换不确定型联系概念模型的设计不允许存在非确定型的联系,要依照多元联系转换为多个二元联系的规则进行非确定的转换。将不确定联系转换为确定型联系,可以通过

7、引入连接实体的方法将多元的不确定联系转换为二元的确定型联系26。由于描述文献基本信息的LLBook实体和描述责任者基本信息的LLWrit实体的联系属于不确定型联系,也就是多对多(多元)联系:一本图书可以存在着多个著者,一名著者也可以写多本图书,对该联系转化的方法为在转换的过程中引入一个新的相交实体LLWriteBook,该实体的引入是为了描述特定的某种文献和是由特定的某位责任者写的。通过这样的转换,完成了实体LLBook、实体LLWriteBook之间和实体LLWriteBook与实体LLWrit之间的确定型的联系。经过改造的实体LLBook、实体LLWriteBook之间和实体LLWrite

8、Book与实体LLWrit之间的确定型的联系如图3.2所示:图3.2 改造非确定联系示意图Fig. 3.2 The changed non-confirm correlative figure(6)定义实体的主键码定义实体键码也就是定义每个实体的主键码与次键码27。这里只给出主键码的表示,如图3.3所示:图3.3 主键码、次键码的表示Fig. 3.3 The express of primary key and secondary key(7)键码迁移依照依赖关系确定实体的外键码,如LLBook实体的主键码LLBookID移到LLML中,图3.4为LLPub的主键码LLPubID迁移到了LLB

9、ook中。图3.4 键码迁移Fig. 3.4 The key code shift(8)绘制键级图如图3.5所示。图3.5 地方文献全文资源加工键级图 Fig. 3.5 The processing key level figure of local literature whole-length resources(9)定义属性在定义实体属性阶段中,对地方文献全文资源加工的全部实体属性进行定义,最后形成含有实体属性的建模属性表。这要求属性的建立必须紧紧围绕着地方文献全文资源的实际使用背景和收集到的需求信息来展开28。例如实体LLBook的非键码属性包括有描述价格的LLPrice,描述载体形态

10、的LLPage属性,描述出版发行项的LLPubID属性,描述责任者ID的LLWritID,描述文献附注信息的LLadd。下列实体属性表为地方文献全文资源加工的IDEF1X的各个实体的属性表。表3.3 LLBook实体属性表属性编号属性名称属性描述键码说明1LLBookID文献编号主键码2LLPubID出版发行项代码号外键码3LllbID文献所属类别代码号外键码4LLDBID文献创建数据库表的名称外键码5LLWritID责任者代码号外键码6UserID著录者ID号外键码7LLBookName文献名称项8LLIndexNum文献所引号9LLISBN文献ISBN号10LLPage文献载体形态项11L

11、ladd文献副注信息12LLKeword文献关键词信息13LLPrice文献价格信息表3.4 LLPub出版发行项实体属性表属性编号属性名称属性描述键码说明1LLPubID出版发行项代码号主键码2LLPubName出版社名称信息3Lladdress出版地名称信息4LLPrint印刷信息5LLPubDate出版日期表3.5 LLlb文献所属类别实体属性表属性编号属性名称属性描述键码说明1LllbID类别代码号主键码2LLlbName类别名称表3.6 LLBD数据库表实体属性表属性编号属性名称属性描述键码说明1LldbID数据库表代码号主键码2LLdbname表名称表3.7 LLML目录实体属性表

12、属性编号属性名称属性描述键码说明1LlmlID文献目录ID号主键码2LLBookID文献编号外键码3LLmlName文献目录名称表3.8 LLqw全文实体属性表属性编号属性名称属性描述键码说明1LlqwID文献全文编号主键码2LlmlID文献目录编号外键码3LLqwName文献全文文件名称4LlqwSY文献全文索引信息5LLqwSB识别是否为目录、封面、封底信息表3.9 LLwj文摘信息实体属性表属性编号属性名称属性描述键码说明1LLBookID文献编号外键码2LLwjDiscri文献内容信息表3.10 LLWrit责任者信息实体属性表属性编号属性名称属性描述键码说明1LLWritID责任者编

13、号主键码2LLBookID文献编号外键码3LLWriter文献责任者姓名4LLWritPic文献责任者照片信息5LLWritJJ文献责任者简介6LLWritAdd文献责任者附注表3.11 LLWriteBook中间连接实体属性表属性编号属性名称属性描述键码说明1LLBookID文献编号主键码2LLWritID文献责任者代码主键码表3.12 LLRec著录者信息实体属性表属性编号属性名称属性描述键码说明1UserID著录者ID号主键码2LLBookID文献编号外键码3LLunit文献著录者部门4LLunitLD文献著录者部门领导5LLDate_LR文献著录时间6LLPartID文献著录者所属单位

14、代码信息外键码表3.13 LLPart著录单位实体属性表属性编号属性名称属性描述键码说明1LLPartID单位代码信息主键码2LLPartName单位名称3LLPartAdress著录单位地址4LLPartTel文献著单位电话与系统操作有关的文献文摘、目录、全文的数据回收站实体由于与其对应的实体结构雷同,这里不再叙述。由于有的单位需要上传数据库,由服务器监控模块自动识别上传的数据库纪录,并自动将数据倒入中央临时库中,这需要LLup实体完成相关纪录的数据库写入,该上传的数据库中的实体与前述实体相同。在数据审核人员完成数据的审核之后,执行相应的操作,数据就会录入到中央库中。1.2 物理数据模型由于

15、在地方出版物的IDEF1X模型中,虽然涉及到了实体、联系、属性、键码等元素,但由于在建模过程中已经考虑了信息冗余,键码的迁移等一系列的问题,所以将IDEF1X图转换成为关系模式过程就比较简单。需要做的工作就是把IDEF1X图中各种实体转换为相应的关系模式。以下为对应的关系模式(1) LLBook(LLBookID,LLPubID,LllbID,LLDBID,LLWritID,UserID,LLBookName,LLIndexNum,LLISBN,LLPage,Lladd,LLKeword,LLPrice)(2) LLPub(LLPubID,LLPubName,Lladdress,LLPrint

16、,LLPubDate)(3) LLlb(LLlbID,LllbName)(4) LLdb(LLdbID,LLdbname)(5) LLml(LLmlID,LLBookID,LLmlName)(6) LLQW(LLqwID,LLmlID,LLqwName,LLqwSY,LLqwSB)(7) LLWj(LLBookID,LLwjDiscri)(8) LLWrit(LLWritID,LLBookID,LLWriter,LLWritPic,LLWritJJ,LLWritAdd)(9) LLWriteBook(LLBookID,LLWritID)(10) LLRec(UserID,LLBookID,LL

17、unit,LLunitLD,LLDate_LR,LLPartID)(11) LLPart(LLPartID,LLPartName,LLPartAdress,LLPartTel)(12) LLBookback(LLBookBackID,LLBookID,LLPubID,LllbID,LLDBID,LLWritID,UserID,LLBookName,LLIndexNum,LLISBN,LLPage,Lladd,LLKeword,LLPrice)(13) LLPubback(LLPubBackID,LLPubID,LLPubName,Lladdress,LLPrint,LLPubDate)(14)

18、 LLlbBack(LllbBaceID,LLlbID,LllbName)(14) LLdbBack(LldbBack,LLdbID,LLdbname)(15) LLmlBack(LlmlBack,LLmlID,LLBookID,LLmlName)(16) LLQWBack(LLQWBackID,LLqwID,LLmlID,LLqwName,LLqwSY,LLqwSB)(17) LLWjBack(LLWjBackID,LLBookID,LLwjDiscri)(18) LLWritBack(LLWritBackID,LLWritID,LLBookID,LLWriter,LLWritPic,LLW

19、ritJJ,LLWritAdd)(19) LLWriteBookBack(LLBookID,LLWritID)(20) LLRecBack(UserID,LLBookID,LLUserName,LLunit,LLunitLD,LLDate_LR,LLPartID)以上主键采用粗体加下滑线的形式,外键采用粗体字的形式,一般说来,一个数据库表的外键数目是不确定的,为了减少数据库连接运算的开销,避免降低数据库的性能,尽量少用外键。在设计字段的数据类型时,整数如文献代码,责任者代码等为了表示更多丰富的信息,采用Int类型;字符型的字段采用Varchar类型,数值的大小尽量在符合应用的前提下不必取值过大

20、;文摘、全文索引及附注采用ntext类型,可以自动分配存储空间;时间类型则采用datetime类型。1.3 模型的规范化1.3.1 关系模式设计异常关系数据库设计的核心问题是关系模式的设计,按照一定的原则从数量众多而又相互关联的数据中,构造出一组即能反映实际情况又具有良好的可操作性能的关系模式29。如地方全文资源的LLBook关系模式实例为:LLBook(LLBookID,LLPubID,LllbID,LLDBID,LLWritID,UserID,LLBookName,LLIndexNum,LLISBN,LLPage,Lladd,LLKeword,LLPrice)由于一种文献存在多个责任者,如

21、大连地方作家A与另一大连地方作家B合著的一本出版物,由于每个地区著名作家必须有相关的简历、获奖情况等基本信息。同一种文献存在重复录入的情况,会出现LLBookName,LLIndexNum,LLISBN,LLPage,Lladd,LLKeword等表示相同信息的数据在关系的多个实例中大量重复出现,这将修改异常、插入异常、删除异常等异常现象。(1) 修改异常修改异常使得系统维护人员在维护系统数据时只修改了重复数据中的一组或多组的数据,由于粗心往往会忘记修改别的重复的数据。比如:尤金这种文献的责任者为A、B、C,而这种文献的价格原来是15.00元,需要改为16.00元,由于疏忽,维护人员只修改了A

22、、B责任者的价格,没有修改C责任者的所在元组的价格,这就出现了修改异常。(2)插入异常的含义是当著录人员插入一组数据时由于未知的数据而很难在关系中正确的插入。例如文献代码、书名、价格等但不知道该书的责任者,而该字段的属性不能为空,这就出现了插入异常问题。(3)删除异常的含义是如果A责任者有多种著作a、b、c,在删除A责任者信息时,也相应的把a、b、c三种文献的信息删除了,这也是一种不正常现象。1.3.2 关系模式的分解消除前述关系模式中数据异常的方法是采用分解关系式。将属性分开,构成两个新的关系模式。依照模式分解的定义:关系模式R<U,F>的分解是指R为它的一组子集=R1<U

23、1,F1>,R2<U2,F2>,Rn<Un,Fn>所替代的过程29。依据定义,为了能够保证分解能够正常进行,可选择下面两个关系:LLBooKFirst(LLBookID,LLPubID,LllbID,LLDBID,UserID,LLBookName,LLIndexNum,LLISBN,LLPage,Lladd,LLKeword,LLPrice)LLWrtName(LLBookID,LLWritID)由于上述分解在LLBookFirt表中没有LLWritID属性,所以这种分解避免了前面提到过的冗余、修改异常、插入异常和删除异常等现象的出现。这样在我们修改LLBook

24、First表中一种文献价格,就不会出现有的元组由于维护人员的疏忽而造成同一文献价格不一致的异常情况出现。1.3.3 模型的规范化关系模型的规范化指的是关系模型要满足不同范式的要求。最低要求是满足的每个分量必须是不可分的数据项,这叫做第一范式。以下是其余范式的定义:(1)若关系模式R属于1NF,且每一个非主属性完全函数依赖于码,则R属于2NF。(2)若关系模式R属于2NF,其每一个非主属性都不传递依赖于码,则R属于3NF。(3)若关系模式R属于1NF,XY,且对于每一个非平凡的函数依赖Y,都有X包含码,则R属于BCNF。(4)关系模式R<U,F>属于1NF,如果对于R的每个非平凡多值

25、依赖XY,X都含有码,则称R属于4NF30。对地方文献全文资源进行关系模式分解的最终目的是使用非异常的关系模式取代异常的关系模式。判断异常的方法可使用BCNF范式。依据BCNF的定义可以理解为:必须每一个非平凡依赖的左边必须包含超键码。举例如下:LLBooKFirst(LLBookID,LLPubID,LLlbID,LLdbID,UserID,LLBookName,LLIndexNum,LLISBN,LLPage,Lladd,LLKeword,LLPrice)LLWrtName(LLBookID,LLWritID)LLBookID为唯一超键码且LLBookIDLLPubID LLlbID Ll

26、dbID同理,LLWrtName也为BCNF在模式分解过程中需要保证信息不丢失并且在建立新的连接后,所有的函数依赖都能够保持不变,这样可以使关系模式符合BCNF条件。但在本系统的设计中放宽了BCNF条件限制,模式分解到第三范式就可以了,地方文献全文资源所有表也必须满足第三范式。第三范式指的是在满足第二范式的关系模式基础上,消除由于非主属性之间可能存在函数依赖关系。我们依据范式规范理论,以LLRec实体为例:其非主属性UserID,LLBookID,LLunit,LLunitLD,LLDate_LR,LLPartID之间存在对主键部分关系依赖和非主属性的函数依赖关系,因此不符合第二、三范式的要求

27、,必须进行规范化,使其满足第三范式的要求。一条录入记录的主键由UserID,LLBookID共同来决定。而Llunit LL LLPartID依赖于UserID,是对主键的部分依赖,这不符合第二范式的规定。因此必须加以分解如下:LLRecFirst(LLRecFirstID,UserID,LLBookID)LLRec(UserID,LLunit, LLDate_LR, LLunitLD,LLPartID)以上的分解消除了对主键的部分依赖,已经满足了第二范式的要求,但还存在着非主属性的函数依赖。假如作为某部门领导(LLunitLD)调走了,则必须更新所有该部门的纪录,如果只改变其中一部分记录,就

28、会产生不一致的数据,出现了更新异常的现象。同理,也可以出现添加异常的情况。这些问题的存在是因为非主属性对主属性的传递依赖。UserID决定LLunit,LLunit决定LLunitLD,最后得出UserID决定LLunitLD的结论,解决上述问题的方法也是将关系分解,这样就不会出现更新、删除异常的情况。分解结果如下所示:LLRecFirst(LLRecFirstID,UserID,LLBookID)LLRec(UserID,LLunit, LLDate_LR)LLUnit(LLunit,LlunitLD,LLPartID)LLPart(LLPartID,LLPartName,LLPartAdr

29、ess,LLPartTel)至于别的模块三范式的规范原理相同,这里就不再陈述。1.4 模型的优化(1)使用数字代码替代一些信息。如建立出版社库,录入单位库等,为每个出版社、录入单位建立代码,定期更新,在需要使用的时候,直接提取相关信息,这样就显著地提高数据库的运行效率。(2)采用特殊的逻辑结构提高查询速度。一般情况下,数据库的冗余度和数据库查询的效率总是一对矛盾,数据的冗余度越小,数据越规范,数据库的查询效率也会随之下降。但是在某些特殊的情况下,采用甚至连1NF都不满足的表模式却能获得高得多的查询效率。一个地方文献的数据库,包括地方出版物全文资源库、大连地方书法库、大连地方法规全文库、大连外文

30、原版期刊联合目录库。将这些数据录入到读者查询模块的数据库中,进行统一检索。如果把一对一的信息做一个表,将其有可能有多项关联的数据单独设计成另一个表,它们之间用外键的形式连接起来,针对各种不同的表顺序检索。我们假设一共有10万条文献数据,平均每条数据有2个表与之相关联,则查询出包括一条数据在内的关联表的所有信息所需的循环次数不超过100000+100000×4500000次。如果我们采用下面的设计模式:将特殊特征信息采用“属性值1”分隔符“属性值2”+分隔符+“属性值3”+分隔符+的方式拼在一起作为一列,和其它一对一的信息一起放在一个单表中,显然,这种模式是不满足要求的(所有的属性均为

31、简单属性,即每个属性都是不可再分的),但是在这种模式当中,查询出的所有信息所需的最大循环次数是 100000次,仅仅是上一种符合规范模式的1/5。上述关系模式在含有多个有连接关系的表的情况下效率得到显著提高。采用这种关系模式,虽然编程复杂,但由于读者查询模块的日常工作主要是对数据进行查询,而不是修改,所以读者查询模块采用上述设计模式大有裨益。1.5 完整性设计1.5.1 实体完整性实体完整性是任何数据库设计和实现的基础。并且能够标识表中的任一行,且不能存在二义性。这种完整性通过定义一个主键来保证,主键包含一列或一些列的组合,对于每一行他们的取值在表中都是唯一的,一次可以用来定义各行。实体完整性

32、的规则是:(1)所有的主键都不能取Null值。(2)所有的修改能都不能导致主键为空。实体完整性的设计在概念模型设计的过程中就已经考虑到,比如LLBook实体中的LLBookID为其主键,用来区分不同的文献基本信息,只有LLPubID,LllbID,LLDBID,LLWritID,UserID,LLBookName,LLIndexNum,LLISBN,LLPage,Lladd,LLKeword,LLPrice信息完全一致的时候才可以认为这是同一种信息。1.5.2 参照完整性在删除被参照关系的元组时采取的做法有三种,分别是:级联删除、受限删除、置空删除。级联删除对数据的破坏性较大。比如说,当操作者

33、只想删除LLPart著录单位实体表中“沙河口图书馆”该条记录时,与沙河口图书馆相关联的其他表中所有参照该记录的其他记录均被删除了。显然这不是期望的。若设计为受限删除,由于LLBook表中的记录需要参照该条记录而无法进行删除操做,假设在责任者信息表中有某一责任者A,当从责任者信息表中删除该条记录时,由于该记录同时被LLBook表中的若干文献参照,只有将LLBook表中所有参照该条记录的文献删除,才能从责任者信息表中删除责任者A的记录,显然这也不是我们在应用中所期望的。我们选择在相关表中加入一个“删除标志”字段的方法,对于信息相对变化不大的表,如LLPart表,就可以采用该办法。对某个表而言,删除

34、操作较添加操作和修改操作使用的概率小。在进行删除操作时,通过代码控制将“删除标志”字段设置为1,这样不仅“被删除”(实际并未删除,只是用户看不到该记录,无法对该记录进行操作)的记录在相关表中的数量不大,而且当对其他参照该表的信息进行检索时,仍然可检索到所谓的被删除信息的相关记录。鉴于其他模块设计与地方出版物全文资料库的设计大致相同,这里不再叙述。2 图书馆自动化管理信息系统的办公自动化设计与实现尽管办公自动化(OA)概念的提出已经有很长一段时间了,但是在图书馆的日常办公管理中,仍停留于单机的文档管理,没有实现真正的业务流程的网络化、自动化,因而办公效率不高,重要文档丢失严重,在管理方式上极不科

35、学。近年来随着图书馆局域网络建设的需要及对工作人员高效协同工作、方便交换业务信息、降低办公成本要求日益增长,开发出一套适合图书馆内使用的办公自动化软件势在必行。2.1 办公自动化需求分析2.1.1 办公自动化总体设计原则图书馆自动化管理子系统的各个目标可以依据需求分析逐步细化确定,并用一定的指标来衡量,本系统开发的总体目标可大致表达如下:通过构建综合办公系统,消除目前办公自动化具有涉及信息量大、复杂,涉及岗位、人员众多,处理流程烦琐、多变等缺点,使领导随时可以审批公文,办公人员随时可以处理公务,从而提高办公效率。其次,它将实现网上发布公文,因而无需派专人复印分发公文,节约了大量纸张。第三,它将

36、充分利用计算机、数据通信、多媒体等现代化先进技术,取代原始办公事务处理进程中一般性、重复性的工作;充分合理地利用已有的教育和经济、科技信息,提高工作效率、工作质量及事务管理水平,增强信息资源管理和利用能力,适应信息化社会发展的需要,为图书馆办公管理探索一条新路,为其进一步发展提供参考。具体目标如下: (1)能够满足领导高效率处理日常事务的需要,提供邮件服务、会议组织、日程安排、公文发送、个人办公、议题讨论、人事管理等功能,有效的协助领导顺利完成各项工作。(2)采用合理的工作流程方式处理影响工作效率的各个环节,最大限度地避免人工传送实物的工作,提高办公人员的工作效率。(3)提供自动监督工作功能,

37、为部门之间实现真正的协同工作提供保证,促使部门之间的工作流程由过去一环接一环的松散结构向紧凑的工作流结构迁移,摆脱以往多个部门协作时经常出现的互相等待的状况,确保办公自动化系统能够真正提高图书馆的行政管理水平。实施图书馆办公自动化管理是一项复杂的系统工程。它涉及到的因素很多,既要满足一般办公自动化的需求,又要达到图书馆的特殊需要;它既着手于硬件设施的配备,又要兼顾计算机软件的开发与维护。因此实现图书馆办公自动化需要全馆上下从各级领导到一般工作人员的通力协作,将人力资源和物质资源重新整合,创造崭新的办公环境。为了确保上述局面设计的实现,我们采用如下策略:(1)总体规划 按照图书馆办公自动化的要求

38、,对图书馆的所有信息进行细分,必要时进行编码。 办公自动化系统的实施工作要集中管理,避免多头管理,力量分散。 由于办公自动化的工程庞大,不可能一蹴而就,应该有计划、有步骤地分批进行。(2)规范先行首先确定本行业、本单位的办公规范。这些规范反映了使用单位实际工作的需求,又是办公自动化系统设计和开发的依据,更是验收所开发的办公自动化系统时的依据。(3)系统的实用性坚持以需求为导向,以便于业务办公和业务应用为出发点,以用户使用友好为设计原则。系统操作平台简明直观、符合Windows规范,使用方便。对熟悉各自原来业务的操作人员,只需经过一定的计算机基础知识和应用系统操作的培训,就可自如操作应用31。2

39、.1.2 办公自动化需求分析根据图书馆办公和现有的办公自动化系统的特点,在仔细调查研究基础上,将图书馆办公自动化最终需求明确为:(1)个人办公管理 电子邮件管理列出手法电子信件的显示与查询,消除馆内或馆外通信瓶颈,支持SMTP协议与附件功能。根据用户密码和口令判断接收的Email或发送Email。用户Email信息的输入到收件箱,包括发信人邮件ID号、用户名、接收人用户名、信件标题、信件内容、发送时间、信件所处状态、附件名称、附件大小。用户Email信件草稿箱功能,包括接收人用户名、信件标题、信件内容、拟稿时间、信件所处状态、附件名称、附件大小。邮件的分类管理功能,包括邮件分类管理ID号、邮件

40、类别代码、用户名、接收人用户名、信件标题、信件内容、发送时间、信件所处状态、附件名称、附件大小。自定义邮件的分类代码,包括邮件分类代码ID号、分类代码、分类名称。回收站功能,包括发信人用户名、接收人用户名、信件标题、信件内容、发送时间、信件所处状态、附件名称、附件大小。电子邮件查询功能,查询结果分页显示。 代办事宜列出并可处理所有等待处理的公文及其他信息。 工作日志显示当天工作内容、个人办公活动的具体时间、日程及活动内容。日程安排主要用于提供活动时间表,确保按时参加各项活动。可以根据安排自动提醒今日要进行的各项活动,管理人员可方便地浏览所有用户在本日、本周、下周、本月所有历史和未来的活动。个人

41、工作日志为用户个人录入的用户名、工作日历信息,包括工作日历时间、工作安排题录、工作安排内容、录入时间、工作安排备注。集体工作日志为管理人员录入的集体活动、工作的信息,包括发文人、发文部门、接收人用户名、录入时间、工作日历时间、工作安排题录、工作安排内容、工作安排备注。名片夹管理用于管理个人通讯信息的通讯信息,方便客户及合作伙伴彼此之间的沟通。用户可以按姓名和单位两种方式分类显示通讯信息。名片夹信息录入,包括客户姓名、移动电话、宅电、办公电话、Email、所在单位、职称、录入时间、备注。可根据时间、姓名、电话等信息查询,有修改删除功能。(2)行政办公 公文浏览根据用户本身的权限、角色和发文单位、

42、文件标题、文号、日期、编号、起草人等条件检索。 发文管理执行发文拟稿、核稿、发文核签、归档后,进入自定义流程程序,分配其余用户角色权限的功能。发文拟稿、核稿的接收功能,包括拟、核稿编号;拟、核稿发送人;核稿接收人;标题、备注、文件状态、区分标注、插入日期、发送者的IP地址。拟、核稿公文表的插入,包括拟、核稿公文编号;拟、核稿文件名;文件路径。公文签发功能,只有经过签发的公文才能够进入归档、自定义流程,包括拟、核稿编号,签发标志。经过签发的公文录入档案库的功能,包括档案编号、分类号、档案状态(有无借出、归还状态)、档案名称、建档人、建档日期、修改人、修改日期。公文流程的录入,包括流程ID号、档案

43、编号、标题、公文描述、公文类别、公文状态、发送日期、截止日期、备注。流程定义、权限角色分配功能。包括文件名、文件路径、发送人、接收人、接收人角色。公文类别的自定义功能,包括公文类别代码、公文类别名称。 公文回收通过流程管理确认公文已经被用户浏览后,由管理人员将该公文回收至公文回收站,有清空回收站、公文浏览数据的插入功能。 流程管理每一个浏览公文的操作,系统都应该将相应的浏览数据插入到数据库中,为管理者提供公文回收数据。(3)辅助办公 档案管理档案的分类录入。档案申请纪录,显示未经批准的申请纪录和已批准的申请纪录,包括档案分类号、申请人、批复人、申请日期、批复日期、档案批准的标志。档案借用纪录,

44、包括档案分类号、借用人员、借用日期,应归还日期、备注。档案归还纪录,档案编号、档案名称、归还人、归还日期、备注。档案分类资料的修改和删除功能。档案申请、借用、归还纪录的修改、删除和查询功能。 考勤工资管理应到考勤日和上下班时间设定功能,在进行考勤统计之前要首先设定参数,作为统计迟到、早退、旷工的依据。馆员出勤录入,出勤信息由出勤卡在计算机上扫描录入,生成标准格式数据纪录,为应付紧急情况,也可以直接录入出勤信息、出入时间,记录编号自动生成。馆员加班信息录入,包括记录编号(自动生成)、馆员编号、加班时间、加班日期。馆员出差、请假信息录入功能。在规定的时间范围内,对馆员考勤信息进行总的统计功能。奖金

45、、福利、津贴和扣发项的录入功能。工资计算参数设置,利用此参数进行工资的计算。在设定的时间段内,根据考勤结果、奖金、福利、津贴和扣发信息进行馆员工资计算功能。 会议管理计划内会议管理临时会议的管理(4)公共信息管理公共信息模块主要提供各种公用信息的发布、查询功能。它由馆情通告、电子公告、电子论坛、规章制度、值班管理模块构成。针对电子公告和电子论坛具有发布、回复、采集、维护、显示等功能。电子公告功能需求如下: 信息编辑:将要发布的各类信息编辑成相关文档。 信息审批:只有通过审批的信息才可以发布出去。 信息发布:通过网络将信息文档发布到公告牌。 信息回复:对公告牌上的信息的答复(回复到公告牌或直接将

46、回复信息发 给发布人)。其中电子论坛要求为全体馆员提供完整的信息交流方式,使得单位内部交流信息的发布可以面向群体,馆员可以提出问题并讨论一定的话题。访问者能够在电子论坛中浏览各种信息,答复其他人的问题。(5)系统工具系统工具用于管理本系统的所有机构和用户的注册,定义各用户的身份和权限,定义系统所有模块所需的各项参数。用户单位的系统管理员通过系统工具可以方便的实现对自动化系统进行定制和管理。2.1.3 组织结构分析按照单位的设置,可面向馆总机室、馆长室、副馆长室(含馆长助理)、馆长办公室、计划财务科、保卫科、行政管理科、物业管理中心、信息网络中心、总服务台、青少部、计算机中心、白云书院、展览部、

47、业务辅导培训部、财政局分馆、采访部、编目中心、报刊部、社会科学部、自然科学部、古籍部22个部门。其关系如图4.1所示。图4.1 组织结构图Fig. 4.1 The structure configuration从上图我们可以认为:大连图书馆的行政管理是实行馆长、副馆级领导、部门主任和馆员的三级管理模式。而对于特殊部门则有着特殊的要求。比如说,馆长办公室有公文拟稿、核稿的权限,对于各部门领导及馆员虽然与馆长办公室同属于第三级管理,却仅有拟稿权限。因此在本系统可以将办公室划作第二级用户统一管理。2.1.4 办公自动化模块划分办公自动化模块的划分有多种方法,可按业务处理的功能进行划分、按业务处理的顺

48、序进行划分、按职能部门的构成进行划分等。根据大连图书馆办公自动化的基本业务和各部门职能的要求,本着各业务子系统之间相对独立性,并以用户实用为原则,将大连图书馆自动化系统划分为五个子系统。它们分别是:个人办公子系统;辅助办公子系统;行政办公子系统;公共信息子系统;系统工具子系统。如图4.2 所示:图4.2 图书馆办公自动化系统功能结构图Fig. 4.2 The function configuration figure of library OA system其中Email管理功能结构如图4.3所示:图4.3 Email管理功能结构图Fig. 4.3 The function configura

49、tion figure of Email management发文管理功能结构图如图4.4所示:图4.4 档案管理功能结构图Fig. 4.4 The function configuration figure of archives management档案管理功能结构细分如图4.5所示:图4.5 档案管理功能结构图Figure 4.5 The function configuration figure of archives management考勤工资管理功能结构细分如图4.6所示:图4.6 考勤工资管理功能结构图Fig. 4.6 The function configuration fi

50、gure of check on work attendance2.1.5 业务流程下面以行政办公、辅助办公为例说明图书馆管理系统的办公自动化业务流程。行政办公行政办公为整个图书馆自动化管理信息系统办公自动化子系统的核心,主要体现在发文管理及其流程的自定义管理。其中发文流程如图4.7所示。图4.7 发文流程图Fig. 4.7 The flow figure of send document通过发文的业务流程图可以看出,当办公文档传递到某个系统标识用户手中时,即该用户是该文档的作者,有且只有该系统标识用户具有对文档编辑、修改的权利,而其他用户不具有对该文档的编辑等权限,因此不予考虑。(1)公文发

51、文的拟稿、核稿发文管理机关负责对外发文的起草、批转、审核和正式发文整个过程。在发文的批转过程中,每个接收人员对文件正文的修改都将保存在系统中,直到形成最后文件。拟稿人提交拟稿数据至拟稿公文表和公文接收表中,核稿人通过个人办公中的待办事宜接收公文,将修改后的文件和修改意见等提交至拟稿公文表和公文接收表,反复修改,直至形成最后的文档。参照关系以及外键的设计:(2)流程自定义流程自定义模块是发文管理子系统中的一个重要组成部分,权限的分配、角色的定义皆由该模块完成。在核稿完毕并且由领导核签后,交由办公室统一定义该文件的安全级别、完成公文归档、创建传递流程(顺序浏览、群发该文件、或自定义该公文流程)、监

52、控该文件传递中的整个流程纪录,办理完毕后由系统自动归档从而完成整个自动流转过程管理。当办公文档传递到某个系统标识用户手中时,即该用户是该文档的授权者者,有且只有该标识用户具有对文档编辑、修改的权利,而其他用户不具有对该文档编辑权限。流程定义是根据办公室人员对文件、数据的多级访问权限设定,保证其他用户在其权限范围内使用,系统同时也确保完成该用户的要求。用户在浏览公文时,系统会判断下一接收者并修改公文流程定义表状态值,通知公文接收者有新公文需要接受。而群发时,不必经过任何上一级阅览者同意直接向公文接收表插入数据。公文的安全级别与用户的权限级别相对应,只有当权限级别大于或等于公文安全级别的用户才能浏

53、览或下载该公文。保证文件不被未授权的人处理。(1)档案管理档案管理工作主要包括四项内容:公文归档管理、档案申请、档案借阅、档案归还。 公文归档管理:档案管理员根据文档类别可创建、删除、添加、重命名文档文件。 档案申请借阅管理:由借阅人提出申请,提交的申请信息经办公室同意后用户方有权限在规定的时间内借阅。 档案借阅管理:用户需要察看某档案详细内容或借阅档案时,可以进行“借阅”操作,进入档案借阅流程。 档案归还:用户可以自己归还档案也可以到期后由系统自动取消该用户浏览此公文档案的权限。普通用户和办公室档案管理员的权限不同,普通用户只可以借阅已封卷的档案文件。而办公室档案管理员拥有档案管理模块的全部权限。如图4.8所示。图4.8 档案借阅流程业务流程图Fig. 4.8 The operation flow figure of archives sending(2)工资考勤管理考勤管理由办公室负责,工资的管理和发放由财会科完成。考勤工资管理子系统要系统化、规范化、自动化,以提高员工考勤和工资管理的效率,完成员工出勤、加班、出差和请假等情况的录入统计。考勤统计结果作为员工工资评定的主要参考依据,加上员工奖金、津贴和扣发等统计结果,最终形成员工工资报表。由办公室和财会科分别录入基本考勤、财会参数,馆员出勤信息由考勤机自动录入并生成标准格式文件,以此为依据

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论