基于SSM框架的某高校教室管理信息系统的设计实现（4）

第四章 教室管理信息系统的总体设计

        通过第三章的需求分析可知，教室管理信息系统用来管理某高校教室资源的申请、审批、缴费和使用，使该高校的教室资源管理更加规范化和合理化。为了更好地进行系统设计，本章将介绍系统的设计原则、系统的架构设计、主要功能模块划分及系统的数据库设计。

4.1系统设计原则

        高校教室管理信息系统负责管理高校教室资源的申请、审批、缴费和使用。针对教室资源的类型和借用方式的多样性以及管理流程的复杂性问题，在进行系统设计时，遵循如下原则:
1、可靠性
        高校教室管理信息系统需要保证系统运行的高可靠性。教室是学生上课的场所教室资源的管理是高校教学管理的重要组成部分，一旦系统出现故障，必将影响学校教学的正常进行。同时将会影响教务系统、排课系统的正常运行，给相关部门的工作带来很大的不便。
可靠性原则是本系统设计所遵循的一个重要原则。在开发过程中，如果某个实现涉及到数据对象的级联操作，都需要将这些代码放到一个事务中去执行，保证所有的功能要么被执行成功，要么都不执行，避免系统数据的不一致。系统在设计过程中采用了操作的撤销处理，以便能够减轻出于误操作而造成的后果。

2、高效性
        高校教室管理信息系统用来进行教室的申请、分配和使用。系统数据具有如下特点:课程信息涉及到教务系统计划内课程排课:教室的借用涉及到校内人员及校外人员的借用而且借用类型多样;教室处理流程涉及到学校多个部门，数据操作量较大数据处理的高效性是本系统设计所要遵循的又一重要原则。在开发过程中，通过对数据库表结构进行优化、建立索引、对 SOL 语句进行优化、对JAVA 代码进行优化等几个方面来提高数据处理效率。

3、可维护性
        软件系统运行后，需要进行长期的维护。尤其对于校园信息化项目，更是一个持续和长久的过程，因此系统需求分析的好坏尤为重要。本系统在需求分析的基础上设计了原型系统，并通过与实际用户的不断沟通之后，最终确立了实现方案。通过使用SSM 框架技术来实现面向接口编程，从技术上保证了软件的可靠性，降低了系统维护的成本。

4、经济性
        在满足系统性能要求的前提下，硬件配置尽量考虑利用学校现有的设备资源，降低系统成本。尽量在软件层面确保软件开发的质量，提高软件的运行效率，而不是一味依赖于硬件设备的性能。

4.2系统的架构设计

        通过第三章的系统需求分析可知，高校教室管理信息系统具有系统数据操作量大、数据实时性要求高、用户与数据库交五频繁、系统用户多而且对计算机的操作水平参差不齐等特点。选择合适的系统架构及实现技术进行系统开发很重要。

4.21B/S架构的选择

        C/S架构与 B/S架构是常用的两种系统架构。C/S 架构即客户机一服务器架构。C/S架构充分利用客户端和服务器端的硬件环境，将任务合理分配到客户端和服务器端来实现，降低了系统的通讯开销。B/S 架构即浏览器一服务器结构。在这种架构下用户工作界面通过浏览器来实现，事务逻辑在服务器端实现。下文将简要的介绍两种框架的优缺点。
1、C/S的优缺点
1）优点
        服务器运行时的数据负荷轻。C/S 架构的体系结构出客户端应用程序和数据库服务器程序组成。客户端应用程序运行于用户自己的电脑，当需要数据操作时，客户端程序自动寻找服务器程序并发送请求。服务器程序按照规则作出应答，返回结果。该过程简单，服务器的数据负荷低。
2）缺点

        系统维护量大。在系统运行时，需要在客户端和服务器端建立数据同步，因此，需要在两者之间建立实时的通讯连接，维持两地的数据库服务器在线运行。网络管理人员既要对服务器维护管理，又要对客户端维护管理，同时还需要较高的投资和技术支持，维护成本高。
2、B/S架构的优缺点
1）优点
        系统维护量少，软件升级方便。B/S 架构的软件系统只需管理服务器即可，客户端使用浏览器，一般不需要做维护。随着系统版本的不断升级，浏览器的升级和维护也越来越容易，使用起来越来越简单。
2）缺点
        服务器运行时的数据负荷重。B/S 架构的系统软件安装在服务器端，事务逻辑在服务器端来实现，所有应用服务器运行数据负荷较重。一旦发生服务器“崩溃”，后果不堪设想，因此需要备有备份数据库的服务器。
通过以上两种架构的优缺点的比较，可以发现:
1)B/S架构的系统维护工作量比 C/S 架构的少
2)B/S 架构降低了客户端电脑负荷，降低了总成本
3)从数据一致性和实时性方面考虑，B/S 架构优于C/S架构
高校教室管理信息系统使用 B/S 架构即浏览器一服务器架构。这种方式降低了客户端计算机的负荷，减轻了系统维护工作量，降低了用户的成本。

4.22SSM框架的选择

        通过2.2.4节可知，基于J2EE的SSM框架给Web应用系统的开发带来了诸多好处。SSM 框架是由 Struts2、Spring 和MyBatis 三层框架集成的。该框架将整个用户请求处理划分在四个不同的层次，降低了层层之间的耦合度。为系统的开发和实现提供了很大的自由空间。现阶段，SSH 框架是一种比较流行的集成框架，被大型商业项目广泛使用。SSM框架与SSH框架的不同在于数据持层的实现框架。
        2.1.4小节介绍了数据持层框架 Hibernate 和 MyBatis 的特点及其应用场合Hibernate 对数据库结构提供了较为完整的封装，提供了从对象到数据库表的全套映射机制。Hibernate 根据制定的存储逻辑，自动生成对应的SQL并调用JDBC接口加以执行，这种实现无需开发人员熟练掌握 SQL 语句，只需设定好对象与表结构之间的映射关系。Hibernate 适用于对象模型要求高、数据表结构确定的大型商业项目MyBatis把SQL语句的参数(parameter)和返回结果(result)映射至实体类(或JavaBean)更好地分离了数据库和对象模型，相对降低了两者之间的耦合。MyBatis 框架对数据库的设计要求不高，而且支持存储过程和SOL优化，是一种“半自动”式的ORM实现方案。MyBatis 适用于表结构多变、数据处理量大的系统的开发。
        高校教室管理信息系统中涉及的教室信息数据量大，性能要求较高，采用基于MyBatis 数据持久层框架有利于系统的拓展。开发人员可以通过 SQL语句优化以及存储过程的使用来提高系统的性能。本系统采用基于J2EE的SSM 集成框架技术采用面向接口编程，实现接口复用，从而提高项目开发效率。

4.3系统的模块划分

        教室管理信息系统主要包括教室的申请、审批、使用以及基础信息维护等四大模块，其结构如图 4.1 所示。3.2 节已经对教室的申请、审批、使用等三大模块的需求及其实现功能进行了详细的描述，下文将对这三大模块进行简单介绍并重点描述基础信息维护模块。

        在教室申请模块中，教室的申请被划分为5种类型，临时教室借用(最常用的借用类型)、考试借用申请、调停补课申请、调换教室申请和假期借用申请等。每种类型都有各自的特点，该模块设计的重点是查询出符合申请要求的空教室。申请人需要填写申请单，然后将申请单发送给本部门领导审批或者由于特殊情况直接转发给教室调度员。申请单需要根据不同的借用类型来设计，便于个性化的教室借用。
        在教室的审批模块中，主要包括各级部门的审批以及财务处的缴费。本模块的设计重点是能够实现教室审批流程的自由流转,每次流转能够详细的查看其他审批人的意见以及处理详情，有利于教室申请者能够查看各审批人的意见和想法并查看教室审批进度，同时审批人之间能够相五了解各自的观点和意见，有利于信息共享。
        申请人员发送教室申请之后，如果该申请被审批通过，就可以使用教室。教室使用模块主要是针对于后勒处的教学楼管理员，该模块能够将所有教学楼的教室使用情况展示给楼管，楼管能够通过日期来查询本楼和其他教学楼的上课信息，以便无需通过纸质凭条就能提供各项教室使用服务。

        基础信息维护模块主要负责管理教室管理信息系统中的基本数据。如用户基本信息维护、流转信息维护、角色菜单信息维护、教室价格设定、虚拟币维护、教室资源维护等等，这些基础信息保证了系统的正常运行。下文将介绍用户基本信息、流转信息、角色菜单信息等部分的设计。

1、用户基本信息维护

        用户基本信息包括用户的基本信息、联系方式以及登录信息。用户基本信息维护包括两方面，一方面指管理员对用户信息的维护,另一方面指用户对个人信息的维护管理员对用户的维护包括用户信息的添加、删除、修改和查询。针对系统用户的复杂性问题，本文从用户登录和用户权限两个方面设计了系统的安全策略。所以在用户基本信息维护中需要维护好用户的角色、部门以及用户名等信息。
        用户对个人信息的维护包括基本信息、联系方式以及登录信息的修改维护。用户可以按照个人意愿来修改登录密码及其他联系方式。这些信息的维护保证了用户数据的安全，为用户的操作提供了方便。
2、流转信息维护

        流转信息维护主要提供流程流转信息的添加、删除、修改和查询。教室管理信息系统的流程流转通过提交申请者角色编号与审核者角色编号之间的对应来实现。管理员可以按照需求来控制流程的流转即申请单的流向。该信息的维护实现了流程流转的规范化、秩序化，保证了系统的正常运行。
3、角色菜单信息维护
        角色菜单信息提供了角色与菜单之间的对应。教室管理信息系统中，用户的角色比较多，每位用户的权限也不一样。权限不同体现在系统中即为不同的用户登录到系统之后，使用的菜单是不一样的。角色菜单信息维护实现了角色与菜单之间的对应关系的添加、删除、修改和查询。角色菜单信息维护实现了用户权限的划分。
4、教室价格维护
        教室的价格出教室的容量和教室的类别决定。教室的容量指教室所能容纳的上课人数。教室的类别包括一般教室、多媒体教室、语音室和机房等种类。教室价格信息的维护即教室容量、教室类别与教室价格的对照信息维护。管理员能够实现教室价格的设定和修改。系统通过读取教室价格来实现教室费用的计算。
5、维护
        为了使教室使用更加合理地进行度量，在教室管理信息系统中，每个学年会给各个院系预分配一定数额的教室使用经费，简称为虚拟币。虚拟币的维护包括院系虚拟币的余额查询以及虚拟币的充值。财务处秘书通过虚拟币的维护来实现各教室使用单位对虚拟币的充值及余额不足提醒。虚拟币维护保证了教室的正常借用。

教室管理信息系统的信息维护界面包括角色信息维护、使用对象信息维护、费用类型维护等，其设计过程与教室价格信息维护的设计类似，不在一一赘述。
基础信息维护模块提供了教室管理信息系统的基本数据的维护，保证了系统的正常运行，同时为管理员及用户对数据信息的处理和查看提供了方便

4.4数据库的设计

        数据库是管理信息系统能够正常运行的基础，系统操作都是基于数据的操作。数据库设计的目的是为了构造最优的数据库模式，建立数据库应用系统，使之能够有效地存储数据，来满足用户的应用需求。数据库的设计细节会直接影响到系统开发的效率、数据库的可扩展性及数据库运行的效率等。

4.4.1数据库设计原则

数据库设计应遵循以下五个原则:
1、一致性则
保证系统数据的有效性和一致性。在教室管理信息系统中，存在大量的数据信息。这些信息除了各模块内部特有的信息外，还有某几个模块共有的信息，这样形成了数据交叉现象。不但造成了大量数据重复，而且难以统一更新，产生数据混乱，容易造成数据不一致。所以在数据库设计的时候，需要对数据信息进行统一的分析与设计，组织好各数据源，减少数据冗余;通过设置外键来约束数据操作。
2、规范化原则
规范的数据库设计能够提高开发效率，便于维护。教室管理信息系统的表结构较多，每张表的字段类型也很多，我们采取了以下方法来实现数据库设计的规范性。对数据库对象规范命名，遵循统一的命名规则:为每张表设置主键:表中尽量避免可为空的列;数据表只存储单一数据类型的数据。为避免可能存在的插入、删除、修改错误及数据冗余等问题，数据库的设计应遵循规范化的原则。

3、安全性原则
数据库系统的崩溃对管理信息系统是灾难性的，因此必须保证数据库系统的安全性。为了提高数据库系统的安全可靠性，我们采取以下措施:做好数据库备份，随时可以恢复数据:使用生产数据库和测试数据库镜像;对数据库操作权限进行严格管理实行专人负责、统一集中管理，防止合法用户非法使用数据库或非法用户使用数据库而造成数据泄漏、更改或破坏。
4、扩展性原则
实现教室管理信息系统与后勤其他信息化系统乃至整个高校信息化系统的互通互联是高校信息化建设的必然趋势。本系统的数据涉及到教务处的排课系统和财务处的收费系统等大量数据，因此保证数据库良好的伸缩性、可扩展性和适度的冗余是非常必要的。
5、通用性原则
出于教室管理信息系统是后勤系统的一个子系统，良好的数据通用性能够更好的实现系统之间的数据共享。所以在数据库设计时必须对数据结构进行详细的分析和设计，分析各种可能出现的情况，集中处理具有统一模式的数据组织结构，对于特殊情况做到单独处理。

4.4.2表结构设计

按照上节的数据库设计原则,根据系统要实现的各项功能,进行数据库表的设计。教室管理信息系统共建表 52 张，包括基础信息表及业务信息表等。下面介绍空教室查询需要使用的教室基本信息表、计划内课程排课表、教室预约表、教室借用表以及流程流转需要使用的流程流转记录表和流程流向表等主要的表的设计。
1、空教室查询的数据库设计
空教室查询的数据库设计体现数据库设计的一致性、扩展性和通用性。根据业务需求，空教室查询涉及到以下4 张数据表
1)教室基本信息表。该表存储教室的基本属性，包括所有教室的教室代码、名称、容量、校区、类型等基本条件，本表是教室总表。
2)计划内课程排课表。该表存储计划内课程使用的教室的信息。在每学期初教务处会对全校课程上课时间(不包括中午和晚间)和教室地点进行统一编排，该表数据一经产生便相对固定，改动不大。如果改动则需要使用调停补课模块进行调换。计划内排课表中数据来自教务处的排课表，记录每个学期排课教室的使用情况。

3)教室预约表。该表存储已被教室申请者申请，等待被审批的教室的信息。在教室借用过程中，如果用户申请了某一时间段内的某一批教室，但是领导还未审批通过或批示，那么这批教室将作为被预约而被锁定，其它用户不能查询到。
4)教室借用表。该表存储已被教室审批者审核通过，等待被用的教室的信息。在教室借用过程中，如果用户申请了某一时间段内的某一批教室，如果已被领导审批通过，那么这批教室将作为已使用而被锁定，其它用户不能再查询到这四张表通过教室代码(JSDM)字段进行关联，如图4.2所示。

        为了更好的实现数据共享，满足系统需求，我们对计划内排课表进行了修改，将每次教室借用按照节次来存储。比如原计划内排课表中开始节次为 1 结束节次为 2的一条教室借用信息，在修改后的计划内排课表中存储两条记录，分别是第 1 节课和第2节课教室的借用记录。
原计划内排课表结构如图 4.3 所示。

该表结构来源于目前的教务处排课系统，在空教室查询中，对于该表结构的使用有如下毽杳拖漱安拌堡臂扳癌瓷彼驳瘩搬奥摆厨粹摆蔼草碍阿岗要考虑:
        1)上课周、上课时间没有和具体的学期对应的期相对应，对于查询使用将会不直观;
        2)分别存放开始节次和结束节次，对于存在交集的时间或者是节次查的情况页面处理逻辑和 SOL 语句处理逻辑过于复杂，特别是加入了中午和晚间时段后，出于节次编号不连续(参考 1.1.1 节需求分析)，造成预处理逻辑很复杂针对上述两点问题，我们采取了以下两点解决措施:
        1)将中午节次和晚间节次单独进行处理，且不能单独和其他节次进行简单的使用交集查询(解决方法是使用节次段来查询)
        2)改进计划内课程排课表表结构，建立专门的查询精简表结构。将周次、星期统一转化为学期对应的时间(系统初始化即进行设置)，使用节次单独进行处理，每一节次即存储一条记录，同时去掉其它与空教室查询无关的字段信息。这样处理是为了减轻交集查询时的复杂逻辑，同时对于中午和晚间的处理逻辑也变得简单。因为无论中午和晚间节次是否增减，由于是一节课存储一条数据，对于查询逻辑不需要任何改变，在很大程度上提高了系统的扩展性。
修改后的计划内排课表结构如图4.4 所示
        同理，教室预约表和教室借用表也采用同样的表结构模式。唯一的区别是这些记录中包含该次借用的申请单号信息(必须要记录该教室是哪一次被借用的)。如图4.5所示。

        空教室查询专用计划内排课表、教室预约表和教室借用表用来记录被使用的教室的信息。空教室的教室代码应表示为符合条件的所有教室与被使用的所有教室的差集。
2、流程流转记录表的设计
        教室申请单的流转信息表设计体现数据库设计的一致性和扩展性。教室的处理流转信息表主要记录教室申请单的处理情况。流程流转记录表来管理流程的流转，用户可以查询到申请单的详细流转用户可以查看整个处理过程的详情以及其他用户的处理意见。

3、流程流向表的设计
        流程流向表的设计体现了数据库设计的通用性和一致性原则。在教室审批过程中，灵活的流程流转过程是通过流程流向表来实现的。该表的主键是流水号，该表提供的功能是通过提交申请单的角色编号 TJRJSBH 字段，来查询出下一个将要流转的处理者的角色编号SHZJSBH字段。每个TJRJSBH字段会对应一个或多个SHZJSBH字段，从而实现了流程流转的自出化。

        我们可以根据当前用户的角色，通过这张表来决定下一个将要流转的角色，从而查询出一个或多个下一个处理者的角色编号，然后通过用户基本信息表中对应的角色编号和部门编号查询到具体的用户。
        系统管理员可以通过设置这张表来设定每个角色下一个处理者的角色，从而来实现流程的自出流转。教室管理信息系统共建表 52 张，包括基础信息表以及业务信息表等，在此不一一赘述

4.4.3存储过程设计

        存储过程是指一组为了完成特定功能的 SOL 语集，经编译后存储在数据库中用户通过指定存储过程的名字并给出参数(如果该存储过程带有参数)来执行。存储过程以已编译形式封装复杂的数据逻辑，应用程序在将 SOL请求发送到DBMS时DBMS不用重新解析 SQL语句，就可以立即执行。

存储过程的使用具有如下优点:
1)实现了模块化编程。
2)减少了网络流量。
3)提高了数据库的安全性。
教室管理信息系统共设计了 16 个存储过程，包括审批处理、最终同意申请、最终拒绝申请、调课处理的存储过程。它的实现是将多个 SOL 语句绑定在一个块中，作为一个单元发送到DBMS，减少了网络流量，提高了数据库的安全性。下面将以空教室查询、申请单提交为例来描述存储过程的设计。
1、空教室查询
空教室查询的存储过程设计如下:
1)在教室基本信息表中查出满足教室基本属性条件的所有教室集合，将其放入到一个临时表TableA 中。

2)根据借用时间段或者是借用时间点、借用节次或者是借用节次段提供的参数查询出该区域内在计划内排课表、教室预约表和教室借用表中已经被占用的教室(首先需要对时间段进行循环，然后对节次段进行循环，查找出其中已经被占用的教室),并将结果集依次放入临时表 TableB 中。此时 TableB 中的数据可能有余，为了提高效率，对 TableB 进行一次 SQL级别的 distinct 操作。

2、教室申请单的提交
教室申请单的提交需要完成以下操作
1)由于存在多用户对同一间教室的借用情况，所以在教室申请单的提交的时候需要检验教室是否被借用。
2)将教室借用信息插入到教室借用申请表和教室预约表
3)将教室借用记录插入到流程流转记录表中。
4)更新院系虚拟币表中的余额。
当以上所有操作都完成之后才能完成教室的申请，任何一步的错误操作都将造成数据的不一致，这种数据的不一致错误不容易被发现而且很难恢复。具体实现参照5.1.3 的发送申请的数据处理，在此不再赘述
存储过程能够将多个操作封装在一起，与数据库提供的事务处理联合一起使用实现了模块化编程。使用存储过程能够提高数据执行效率及安全性，同时也减少了代码实现。

4.5本章小结

本章是根据第三章的系统需求分析，对高校管理信息系统进行总体架构设计、功能模块划分以及相应的数据库设计。
在总体架构方面，阐述了 B/S 架构和 SSM 集成开发架的特点、系统的设计原则以及系统的整体结构设计方案。在系统的功能模块划分部分，分别描述了教室的申请、审批、使用以及基础信息维护等模块的作用及其设计，重点介绍了基础信息维护模块的设计。在数据库设计方面，描述了数据库的设计原则以及具有代表性的表结构和存储过程的设计。以上三方面的详细设计为系统的具体实现做了铺垫。