高校教务管理系统的研究

高校教务管理系统的研究

摘要：本论文主要讨论了实体一关系数据库建模方法的局限性以及如何利用面向

对象的思想进行改进，并且以我校的教务管理的实际情况为背景，对基于校园

网的教务管理信息系统进行数据库建模和网络运行环境的设计，其中还涉及了

中间层组件的开发方法和排课算法的初步探讨。

关键词:组件模型；实体一关系模型；数据库建模；DCOM/COM；MTS组件；

教务管理；排课算法。

Abstract：In this thesis，the Entity-Relationship method of database modeling is introduced and it‘s limitation is pointed out so clearly that we can find the

way to improve it with the Object-Oriented thinking. As an application of this

way，the database modeling of educational administration information

system and the running environment on the campus intranet are designed on

what is actually happening to our university. Further more，the arithmetic of autogeneration of curriculum schedule and the methods of how to develop

software component in middle-tier is given simply in relation to the research

achievement abroad and home.

keywords:Component model；Entity-Relationship model；Database；modeling；

DCOM/COM；M TS component；Educational administation；Arithmetic of autogeneration of curriculum schedule.

目录

第一章绪论................................. . (2)

1.1来源........................ ...... .. .. .. . (3)

1.2国内研究成果综述.............. ...................... .. (3)

1.3本论文研究的主要内容...... .................. .. .. (3)

第二章系统总体设计........................ .. .. .. .. ........ . (5)

2.1系统分析.................... (5)

2.1.1需求陈述 ............. ....................... .. .. 5

2.1.2数据流图................ .................... .. .. ..6

2.1.3问题域划分................. ................... .. . 6

2.2系统的网络运行环境.. .. .. .. .. .. .. (11)

2.2.1组件模型概述..... .. .. .. .. .. .. .. .. .. .. .. .. ..11 2.2.2模型设计....................... ............... .. .15

第三章数据库的建模原理........................................ ..17

3.1数据库开发流程.......................... .. ....... .. .. ..17

3.2数据库的标准化.. .. .. ............................ .. . (19)

3.3数据库的建模原理........................... ........ (21)

3.3.1实体一关系建模原理概述.................... .. .. .. .22

3.3.2实体一关系建模的局限性..................... .. .. (23)

3.3.3用面向对象思想对传统建模方法的改进............ .. ..24

第四章数据库的建模实现 (27)

4.1对象之间的关系......................... ............. . (28)

4.2参照完整性的设计..................... .. (32)

4.3应用逻辑的实现.......................... ..... .... .... ..34

4.4查询模型的设计........................ .... ..... .... . (36)

第五章中间层组件的开发....................................... (37)

5.1数据库访问技术概述........ . (38)

5.2 MTS中间层构件的开发原则和实现方法... ....... ........... ..40

5.3 Web接口和专用接口的实现............ (42)

第六章排课算法初探................................ ... ... ... (46)

6.1排课规则....................................... .. .. .. ..46

6.2算法设计.. .. .. . .. ........................... .. .. .. ..47 6.3其他问题的考虑.. (49)

第七章课题展望....................................... .. (50)

致谢..................................... .. (51)

参考文献....................... ..... ..... ............. .. (51)

附录............. ..... ............. ..... ............. ...... .. (52)

第一章绪论

1.1题目来源

从大多数高校目前的教务管理业务流程上来看：

首先，某一年级的总教学计划(在校期间的教学课程和教学进程)由各院教务员按照各学院各学科专业方向提出，主要是必修课或学位课以及任选课的总学分和总学时。

其次，在每一学期开课前一学期由各院教务员根据实际情况添加该学期的教学分计划(从审核后的总教学计划提取)，主要补充院级任选课或非学位课。

最后，审核后的教学分计划为该学期的教学任务，即排课的源数据，经资源(上课的时间和教室)的统一分配产生课表。

此外，校级任选课也是在每一学期开课前一学期由各院系向教研科申请，并提交审核后加入选修学生的学期课表中；校级任选课是单独排课，与教学分计划分开排课，学生每学期的课表因此包含校级选修课课表和由教学任务生成的课表。在业务中，还包含学生成绩、学籍的管理，教师教学工作量、评估等管理，学生的校级选修课的管理。

但是，目前的操作方式仍然是教务员递交到教研科，教研科汇总后统一录入，审核通过手工校验，工作量太大，数据的完整性也不能得到充分保证。我校目前采用的教务管理软件，是基于单用户的桌面数据库管理模式，无论是从信息量的存储、数据库的性能上，还是从系统的功能、安全和维护上，不能切合我校的教务管理的日常业务流程。

随着计算机的日益普及，网络的快速发展和数据库的广泛应用，使得利用校园Intranet进行教务管理已成为可能。不但可以降低工作量、提高办公效率，而且使目前分散的教务信息得到集中管理。然而，仅仅从某一环节去实现计算机的信息管理并不能解决所有的问题，需要从整个业务流程上考虑，基于三层网络计算体系结构，利用校园网构造我校的教务管理信息系统模型，这样才能做到事务的分布式处理，数据的集中式管理，信息的真正共享。

当然，从计算机诞生的那个时代到依照摩尔定律飞速前进的今天，关于教务管理信息系统的研究也有几十年的历史，但不是一劳永逸。技术的发展、环境的变化、时代的要求，都为此带来了新的挑战和引起问题的再研究。

1.2国内研究成果综述

关于教务管理系统的研究已经很长时间了，同时也产生了丰硕的成果。由于教学管理模式的不同，不再介绍国外关于教务管理的研究成果。在国内，由于各种原因，各高

校的教务管理系统都有自身的特点，不尽相同。条件好的高校，依托校园网，围绕本校教务管理实际情况开发各管理模块；条件差一些的高校，就采用单机版的教务管理系统，仅实现其中一些相关的模块，并不是全部教务管理环节，都采用计算机信息管理。因此这里主要将近几年国内各高校教务管理系统的具有代表性的运行模式、功能特点作简要的概述:

在运行模式上，教务管理系统的基于网络使信息管理集中化，如浙江师范大学的教务管理系统，采用Client/Server网络结构，利用网络数据库存储信息，通过专用客户端界面，实现各院系与教务科的业务往来；又如由长春光机学院开发的教务管理系统，采用文件共享的网络结构，利用桌面数据库存储信息，教务科内各模块管理人员通过专用客户端界面对各模块进行操作，但在各院系与教务科之间没有提供信息交互的手段。

在功能上，教务管理系统的模块划分大同小异，都是为了保证信息的充分共享。如浙江师范大学的教务管理系统主要包含辅助模块、学籍模块、成绩模块、教学计划模块组、课室模块组、选课模块组、考试模块组；如由长春光机学院开发的教务管理系统主要包含数据维护、基本数据管理、教学计划管理、开课管理、学籍管理、教室管理、排课管理、考务管理、毕业管理、教材管理。各模块的功能划分又体现了开发者对数据库的建模思路，主要是把基本信息(如教室、班级、院系专业方向、教研室、开设课程等)集中管理，模块的划分映射到相应表对信息的划分。在排课策略上，并没有对问题进行数学建模，把课表求解看作NP问题，选取求近似解的方法，即:根据排课的约束条件，检测所有可能的候选解，从而得出最佳排课方案。

1.3本论文研究的主要内容

本论文就是在充分吸取以上这些研究成果的基础上，围绕性能，安全和维护这三大要素，基于三层网络计算体系结构，从我校的实际出发，构造教务管理信息系统模型，对数据库的进行分析和设计，使我校的教务管理更加科学化，规范化和标准化。

由于在校园网上面对的用户是各院教务员，可以实现教学计划的提交和审批，教学任务的下达和提交，学生成绩录入和管理，课表的查询，校级选修课的学生选课管理等功能；在教务内部网上面对的用户是教学各环节的管理员，可以实现基本数据的录入和更新，教学计划的审核，课表的生成等功能。在系统的设计中，还应将校级选修课和教学分计划合并，对课程、教师、教室、课时分布资源统一分配，生成课表。当然，这样的要求同时也带来了相应的问题，如下所述:

(1)由于教学计划是以专业方向划分的，因而是针对每个专业方向所属的班级，但校级选修课是针对个别学生的，如何在数据库中设计教学计划的课程信息的表达，避免过分冗余，是数据库建模必须考虑的问题。如果采用学位课制，则对非学位课的选择也会面临同样的问题。本论文在第四章第一节给出了数据库的设计.

(2)在校级选修课中，由于学生选课的制约关系比较复杂，也会存在学生之间竞争课程、各门课程的先行后续、学生各门课程上课时间冲突等问题。这些需要在查询学生相关信息后给出判断，才能保证学生选课信息的有效性。这些有效性规则都需要中间层构件来实现校验。本论文在第五章第二节给出了中间层组件的设计规则。

(3)课程表问题又称为时间表问题，课程表的编排就是解决对时间和空间资源争夺而引起的冲突.虽然排课表问题极其复杂，但可以采用一种分而治之(Divide & Conquer)的观点来看待它，将其分为确定候选解—时空片和求取最佳方案两个不同的部分，分阶段地来解决它。本论文在第六章进行了初步探讨，并结合应用逻辑给出了设计思路。

(4)任课教师提交学生成绩到各院教务员，审核后各院教务员通过校园网录入到数据库中，由此产生如何保证对数据库进行安全访问和数据一致性问题。采用三层网络体系结构，不仅仅是网络结构的设计，还必须设计相应的数据库构件，对Web 用户和内部网用户提供统一的数据访问接口以保证一致性和安全性。本论文在第一章第二节和第五章第三节讨论了安全性问题。

当然，系统模型的建立和数据库的建模遇到的不只是上述几个问题，更重要的在于，使用面向对象的方法建立关系数据库以包含整个业务流程的数据信息，通过对三层网络体系结构的理解，构造中间事务层，为用户提供管理的方法和途径。

第二章系统总体设计

本章首先介绍了高校教务信息管理系统的基本需求，并概述了目前流行的三种软件组件模型。在此基础上，根据校园网上教务科与各院系之间的业务关系，对系统运行的网络计算环境进行模型设计。

2.1系统分析

关于高校教务信息管理研究己有多年的历史，各高校在不断实践的基础上又形成了自己的风格，但基本管理模式都大同小异。它们都是以教务管理决策部门(如教务处、教务科、教材科等部门)为控制中心，对所涉及的所有数据进行集中的、统一的管理。

其它部门(如各分院、系、专业等)分设教务员，在主管部门的授权下可以对数据进行录入、修改、查询、统计、打印等操作。这样就将教务管理部门的绝大部分工作(如学籍数据录入与变更、教师管理、工作量计算、教师评估、教学计划、教材计划、学生选课、成绩录入与查询、课表查询、考试查询等)分解到各基层单位，从而能够及时、高效地进行数据处理。其数据处理模型是以教学计划为中心，结合学生学籍数据、教师数据自动生成开课数据、教材计划数据，并生成排课数据及考试安排数据。

下面将从需求陈述、数据流图、问题域划分逐步对系统进行分析。

2.1.1需求陈述

教务信息管理系统是由基于三层模型的内部网和外部网组成的网络信息系统。内部网由教务处(控制中心)的各子系统管理员组成，通过专用客户端软件进行数据库操作:外部网由各院教务员组成，通过浏览器进行数据的提交和查询；内部网与外部网之间由路由器做网关构建防火墙。

对于内部网来说，基础数据管理员将负责每一年的院系、专业方向、教研室、课程、教学区、教室以及每一年级的入学信息、学年学期的数据添加和更新；学籍管理员将负责每一年的学生信息的添加和更新；教师管理员将负责每一年的教师信息的添加和更新；教学计划管理员将负责每一年级的教学总计划的制定和审核，并为排课管理提供每一学期的教学分计划的制定和审核；排课管理员将负责每一学期的排课约束条件的制定及课表的生成；考务管理员将负责每一学期的结业课程的考试时间、考试地点、监考教师的安排以及学生成绩管理。

对于外部网来说，各院教务员将负责向教学计划管理员提交本学院的每一年级的教学总计划，补充每一学期的教学分计划，接受每一学期的教学分计划(教学任务)并提交任课教师，查询课表、考试安排，学生成绩的录入和查询，公告栏的信息查询和信息发布。

除了对运行环境和功能的要求外，还必须在数据安全性、存储容量、事务处理的响应、数据维护等方面有所考虑。

2. 1.2数据流图

从对上述的需求陈述的分析，可以导出整个业务详细的逻辑模型，如下面的数据流图所示。

图

2-1教务信息管理系统的数据流图

2. 1. 3问题域划分

用传统的生命周期方法(SA-S D-S P)开发的软件在稳定性、可重用性和可维护性方面比较差，而面向对象方法学的基本原则，是按照人们习惯的思维方式建立问题域的模型，开发出尽可能直观、自然地表现求解方法的软件系统。它基于构造问题域的对象模型，以对象为中心构造软件系统。基本方法是使用对象模拟问题域中的实体，以对象间的联系刻画实体间的联系，从静态结构的五个层次(主题层、类一&一对象层、结构层、属性层、服务层)划分问题域，确定关联及交互次序，定义服务，最终完成数据交换和处理的功能。

为了在需求分析的基础上，对数据库进行建模，这里采用面向对象的分析方法。由

上面的需求陈述，可以把系统分为以下几个主题:

.基础数据管理

.学籍管理

.教师管理

.教学计划管理

.排课管理

.考务管理

问题域之间的关联如下图:

图2-2问题域之间的关联

从以上问题域之间的关系，可以看出每个问题域都不是独立的，其划分是从用户需求的角度出发的。面向对象的开发也是围绕用户的需求来做的，在开发的各个阶段也不同于传统的软件开发方法。传统的软件开发方法可以用“瀑布”模型来描述，这种方法强调自顶向下按部就班地完成软件开发工作，对软件的需求在用户和系统分析员之间反复讨论，力图使之逐步趋于完善。事实上，人们认识客观世界解决现实问题的过程，是一个渐进的过程，人的认识需要在继承以前的有关知识的基础上，经过多次反复才能逐步深化。用面向对象方法开发软件时，阶段的划分是十分模糊的，通常在分析、设计和实现等阶段件多次迭代来完成开发，上面给出的问题域的划分和关联也是参考已有的经验经过一个反复的过程得出的。在这里，系统把各院教务员和教务内部管理员一视同仁，因为都是通过服务器端基于MTS的组件访问数据库，不同的是前者需使用HTTP协议经网关由IIS调用组件，而后者是在内部网中通过DCOM远程调用(RPS)调用组件。

从对数据流图的分析可以得出的对象模型，但可以看出，在每个对象中列出很少几个最核心的服务。必须把对象的行为以及数据处理，转换成由适当的对象所提供的服务，也正如前面指出的那样，“对象”就是由描述其属性的数据即可以对这些数据施加的操作(即服务)封装在一起构成的独立单元。下面给出确定操作的目标对象(即应该在该对象所属的类中定义这个服务)的一些规则:

1)如果某个处理的功能是从输入流中抽取一个值，则该输入流就是目标对象。

2)如果某个处理具有类型相同的输入流和输出流，而且输出流实质上是输入流的另一种形式，则该输入/输出流就是目标对象。

3)如果某个处理从多个输入流得出输出值，则该处理是输出类中定义的一个服务。

4)如果某个处理把对输入流处理的结果输出给数据存储或动作对象，则该数据存储或动作对象就是目标对象。

当一个处理涉及多个对象时，为确定把它作为那个对象的服务，必须判断那个对象是否在这个处理中起主要作用。通常在起主要作用的对象中定义这个服务。一般情况下，如果处理影响或修改了一个对象，则最好把该处理与处理的目标(而不是触发者)联系在一起；同时考查处理涉及的对象及这些对象之间的关联，从中找出处于中心地位的对象，如果其他对象围绕这个中心对象构成星型，则这个中心对象就是处理的目标。如:学生基本情况和教师基本情况。

对本系统而言，各对象从事件导出的服务定义可以从每个事件的描述动词中得到，因涉及许多数据表项，所以在第四章的数据库建模实现中给出详细的说明。

下面是各对象的状态图:

图2-3系统对象状态图

在教学计划管理中，实际上包含各教务员与教学计划管理员，教务员向管理员无论是提交年级各专业方向的所有学期的教学计划(课程安排)，还是添加某个学期各年级各专业方向的教学分计划的课时分布表及任课教师，都需要从基础管理和教师管理中提取数据，并接受管理员的审核。因此，这些事件可以看作是其他对象提供的服务，而事件引发的状态将成为某些对象的属性(如审核历史记录)，通过状态记录决定是否提供服务。

下面同时也给出了系统的事件跟踪图，时间从上向下递增。必须要说明的是，下面的事件跟踪仅是在正常情况下发生的，对异常情况的处理将加入系统的安全处理中，如在基础数据不完整的情况下的异常处理，在年级教学总计划未建立或未审核时操作教学分计划的异常处理等等，体现在中间层组件中就是对整个事务过程进行判断，对未成功的事务提供回滚。

由以上的分析，同时也给出了系统运行的功能模型。

以上是采用面向对象的方法对系统的业务流程及功能进行分析，下面将介绍该系统的网络运行环境。

2.2系统的网络运行环境

2. 2. 1组件模型概述

从某种程度上说，让标准软件组件分布到网络上相互调用是企业级计算期待的解决方案。而在我们朝着增加组件化、装配式生成应用的方向发展时，企业级计算的合理方向则应是让各种混合平台上的不同类型对象之间采用一个标准通信界面。基于对象的分布式计算所面临的挑战是建立一个系统让软件对象间透明地进行通信，彼此使用对方的服务，而不管这些对象是处于同一编址空间，还是不同的编址空间，或是根本不同的机

器上。当然，如果没有一种方法让对象在网络间可相互调用(借助于对象通道)，应用就

会被限定在某一桌面上。

三层应用一般使用一个事务处理监控器(TPM)实用程序。TPM运行在中间层应用服务器上，支持对数据库的大容量事务处理。TPM通常有以下几个特征:

(1)原子性全部事务不是全部提交就是回滚。

(2)一致性可以把多个事务(例如一个贷方和一个相关的借方)作为一个集合来提交或回滚。

(3)隔离性即使最终结果变化一致，多个相关的事务也好像是串联执行，看不到中间步骤。

(4)持久性一旦一个事务被提交，更新改变就在数据库内固定下来，不会因为通信故障、进程故障和服务器系统崩溃而失败。

在一个三层环境中，事务监视器(TM)是TP应用程序的一个分支，最初是主框架数据库管理系统中用来管理大量并发事务的工具，比起单独的客户/服务器RDBMS更加强壮并且可以处理更多的并发事务。对于许多第三方YM—需要高额的许可费用—可用于UN工X, Netware和WindowsNT的数据库服务器无疑是很有应用价值的。基于UURBA的UTS和基于DCUM的MTS都可以帮助建立和管理三层客户/服务器应用程序的中间层，同时作为一个URB存在，实现资源组合(Pooling)，安全性，管理和客户发行。

CUBAse- CORBA(Common Object Request Broker Architecture)组件模型的底层结构为对象请求代理ORB(object request broker)。一个CORBA组件采用界面定义语言(IDL)进行描述。CORBA提供了IDL到C,C++, Java, COBOL等语言的映射机制—IDL编译器。IDL编译器可以生成Server方的Skeleton和Client方的Stub代码，通过分别与客户端和服务端程序的联编，即可得到相应的Server和Client程序。同时提供了一系列的公共服务规范(COSS )，其中包括名字服务、永久对象服务、生命周期服务、事务处理服务、对象事件服务和安全服务等，它们相当于一类用于企业级计算的公共组件。此外，CORBA还针对电信、石油等典型的应用行业提供了一系列的公共设施。CORBA是一种语言中性的软件组件模型，可以跨越不同的网络、不同的机器和不同的操作系统，实现分布对象之间的互操作。

JAVA- Java对于软件组件的观点与CORBA中的组件观点存在一定的区别。在CORBA 中，CORBA/ORB相当于一根软总线，组件可以即插即用。也就是说，从CORBA的观点看来，所有组件的地位相当，完全是一种平行的关系。而在Java中，软件组件是能够进行可视化操作的可重用软件，它满足一定的特征要求，并可以根据需要进行定制和组装。

Java的软件组件称为JavaBean，是能够在构造工具中进行可视化操作的可重用软件。Java Bean的组件模型包含组件和容器两个基本要素，作为一种典型的组件模型，具有属性、方法、事件、自我检查、定制和永久性等6个方面的特征。Java Bean组件的本地活动是在与其容器相同的地址空间内进行的。在网络上，Java Bean组件可以以三种方式进行活动:JDBC使Bean组件能够访问SQL数据库，可以实现给定数据库中的表操作，完成相应的业务逻辑；Java RMI(远程方法调用)使分布在网络不同地址上的两个组件之间实现互操作，组件之间的调用方式采用经典的Client/Server计算模型；Java IDL

可以实现一个Java Bean和一个COR BA服务之间的互操作。

DCOM— DCOM(Distributed Component Object Model)是Microsoft与其他业界厂商合作提出的一种分布组件对象模型。DCOM是COM在分布计算方面的自然延续，它为分布在网络不同节点的两个COM组件提供了互操作的基础结构，而所有以OLE为标志的技术如今也已挂上了Active标志。COM(Component Object Model)规定了对象模型和编程要求，使COM对象可以与其他对象相互操作。这些对象可以用不同的语言实现，其结构也可以不同。当用户和组件不是那么靠近—在另一个线程中，在另一个程序中或者在地球另一面的一台机器中时情况又是怎样的昵?Cum将它的远程过程调用(RPC)框架代码放到远程注册表中，然后将每个方法调用打包放到一个标准的缓冲器结构中，这个缓冲器结构将被发送给组件，组件打开包并且重新运行最初的方法调用。从这方面来说，COM 提供了一个面向对象的RPC机制。在公共服务方面，微软提出了自己的事务服务器MTS(Microsoft Transaction Server)和消息队列服务器MSMQ(Microsoft Message Queue Server)。前者与CORBA对象事务服务目标类似，后者则是为了保证应用之间进行可靠的消息通讯和管理。

这三种组件模型都各有优点和缺点，但在 Windows平台上，使用Microsoft提供的强大的工具支持，开发基于COM的组件会比较容易。下面在远程过程调用(RPC )、提供服务、安全、事务等方面对比二者，并在之后分别详细讨论。

DCOM包含在WindowsNT4.0中，可作为一个附件下载到Windows9x， Windows 2000直接内置。但从服务的角度来看，它只能在NT下使用，将Unix对象放置到链路上则很困难。相反，CORBA的对象请求代理 ORB (Object RequestBroker)在几乎所有现行服务器、客户机平台下都可用，但必须遵从CORBAIIOP(Internet Inter-ORB Protocol)协议。同CORBA一样，DCOM也是采用面向对象的方法，所有应用都被看作是一个对象。在DCOM 环境下，客户应用与COM组件的通信从表面上看只需通过包含指向该对象可用函数的指

针的界面，组件是界面的具体实现，一个组件可以被支持相同界面的另一个组件透明地删除和替换。DCOM支持界面继承，即一个界面可以从另一个界面中导出，但导出的界面不能继承原始界面上的组件。DCOM允许你使用现存组件，这可通过在应用界面中插入指向该组件的指针来实现。每一个对象必须在本地机上进行注册，以便客户能通过注册上的对象唯一标识找到该对象。DCOM同CORBA一样也允许现存的客户机和服务器应用通过在主机上注册和配置分布到网络上。

CORBA和DCOM都支持动态和静态两种对象调用，但实现上稍有不同。在CORBA下，不管哪种调用方法，实现界面是一样的；而DCOM则提供了两种界面，不同的调用方法需要不同的界面来实现，对于静态调用，要定义一个界面和它的组件，让M工DL (Microsoft工DL)编辑程序自动产生连接这些组件的代理占位模块(Proxy-Stub)代码。DCOM是通过类库来支持动态调用的，类库中包含了描述组件的文件，客户应用在运行期间通过一个被称为Dispatch的COM界面来获取这些界面，优点是无需手工定义界面、让M工DL产生Proxy-Stub代码了，我们可以使用缺省的工Dispatch代理占位模块代码。

CORBA和DCOM也都支持多线程服务。在CORBA中，创建一个线程前不必进行初始化，所有的工作都是由ORB通过一个对象适配器来处理的。而DCOM则要求对线程上使用的Cum库进行初始化。

DCOM采用的是Windows NT的安全体制而自己没有提供。对于非Windows平台，DCOM 将使用这些平台上的安全机制(即激活安全性，使用访问控制表ACL来定义拥有类的优先权的角色)，同时提供了一个与WindowsNT兼容的安全措施(身份认证、授权、数据完整性、数据保密性)。此外，DCOM还提供了一些应用界面，组件可以使用它们来进行自己的安全检查。如果服务器和客户机上的组件都没有执行任何安全检查，系统将使用缺省的安全检查。DCOM下没有提供自动的容错和负载平衡服务，需要微软的事务处理服务器MTS提供了事务处理回滚和负载平衡功能，或者采用一个让客户检测与服务器的连接是否还存在的迂回协议:如果探测到服务器己死或连接已被中断，周密设计的客户程序在必要时能重新连接服务器，并处理丢失或破坏的数据。

综上所述，我们正在面对的是一个新的环境:在瘦客户机环境中我们真正具有Web 计算能力。网络计算时代已经向我们走来，如果我们确实希望实现这种潜在的技术，必须迎之以全新的姿态。

2. 2. 2模型设计

在系统分析的基础上，可以看出，整个管理具有数据集中式、操作分布式的特点，非常适合基于校园网的Web管理模式，即网络计算体系结构(NetworkComputing Architecture，缩写为NCA)。正如其名字所隐含的意义，是在网络环境下创建和集成应用的体系结构。与基于两层体系结构的客户/服务器模型不同的是，NCA体系结构是三层结构，包括:

(1)用户界面层，负责信息的表示。

(2)中间组件层，负责所有的商业规则。

数据服务层，负责数据(文本、数字、即时视频)的储存和操纵。

NCA设想的环境是数据库服务器、应用服务器和瘦客户机都用网络联系在一起。将表示层从应用层中分离出来，可使PC的功能驻留在一个瘦客户机上，应用层驻留在与数据库服务层相同或不同的一台服务器上。应用层服务器和数据库服务器可以移至一台有更多资源的机器上，或许是一个强大的UNIX机器。这些机器放在一个中心位置并由训练有素的专家进行管理。终端用户可以免除所有的复杂问题。

传统上，两层的客户机/服务器结构往往会导致客户机的维护费用偏高。大部分情况下，客户机维护费用高是由于客户机操作系统的复杂性造成的。如果不需要客户机服务于应用程序并且不把重点放在客户机的联网能力上，就可以创建一个非常“瘦的”、廉价且便于维护的客户机。任何一台能与网络连接的机器都可以作为客户机使用。客户机不再需要是一台具有大量资源的机器。近来，许多公司都把重点放在工nternet或工ntranet上，所以现在都要求瘦客户机能包括一个像Microsoft Internet Explorer或Netscape Communicator那样的互联网浏览器。如果客户机非常简单，它以前所担负的任务就必须在其他地方执行，把应用任务集中起来还有助于减少应用程序和系统的维护费用。应用服务器使用通信线程来提供查询并从后端数据库服务器获得结果。在客户机/服务器环境中，客户机通过ODBC或专用接口直接连接到位于服务器的数据库上，并在全部事务完成之前一直保持连接状态。即使没有出现处理操作，客户机也要保持连接。而占用资源不太多的方案是使用一个应用服务器来担任客户机请求和服务器响应的中介器，使用生成HTML页面的SQL软件包来写客户机、应用服务器和后端数据库之间的交互操作。应用服务器接收从客户机通过Web浏览器或其他界面软件发来的信息请求，并连接到服务器上。接着对请求进行处理并从服务器返回信息。然后，应用服务器与服务器断开并把请求的信息返回客户机。使用这种方法时，客户机不与数据库保持连接，应用服务器只有在进行请求并接收请求的结果时才与数据库保持连接。空闲进程并不占

用网络资源，网络流量显著减少，可以更快地进行查询处理并且响应时间得到了改善。如果许多客户机都在频繁请求，可以对这种配置进行更改，使应用服务器能预先与数据库连接，以降低每次处理客户机查询请求时建立连接所需的开销时间量。多线程服务器和连接管理器用于保持与服务器的固定预先连接，这样连接就一可以重复使用。

如上图所示，教务处内部管理员和各系教务员通过DCOM或日TTP远程调用服务器端组件对数据库进行操作以完成特定的功能，在平台上选择基于WinNT的IIS+MTS+MS SQLServer实现。

面向Internet, NCA在用户服务(GUI前端)和数据服务(RDBMS)之间

图2-6

教务信息管理系统模型

插入商业服务层的体系结构，使许多企业级Web设计人员尽可能的把他们的代码由HTML, DHTML. XML或服务器端脚本(诸如VBScript, JavaScript, ASP,Perl, php )转入中间层的组件以实现复杂的数据访问和事务操作，增加可维护性和可扩展性。可以看出，这是一个允许插入一系列软组件和选项的体系结构，其核心是可插入的中间层(应用服务器)和可选择的上层(数据库服务器)。这些组件是以组件为基础的软件，都是用SQL, C++, Java甚至Visual Basic开发。在使用时，必须安装并注册，应用组件将安装在应用服务器上，而数据库组件将安装在数据库服务器上。这些组件使得应用具有很好的扩展性，开发者可以通过编写另外的组件和利用其他组件的服务来增加更多的特色。由于开发者对组件驻留的位置具有选择性，故可以对不同的层面进行控制。联系组件之间的交换是整个体系结构的中枢，这是使一些组件能够同其他组件对话的渠道。由于有合适的中枢，在网络任何地方的组件都可以利用其他组件的服务。

第三章数据库的建模原理

3.1数据库开发流程

尽管有时强调灵活性和创新，犹如金字塔一样古老的项目管理技术仍然是行之有效

的。每一个结构化的系统开发方法都包括一个关于功能的描述。这些功能按照不同的职员角色有不同的职员去完成，同时还要定义与每个角色相应的职责。下面列举了这些角色。

项目中的角色与职责

角色职责

项目投资人批准并支持系统的管理人员

项目经理负责系统总体职责的管理人员

项目领导技术队伍的协调者

技术人员所有指派到项目中的开发人员和技术职员

最终用户那些作为他们的日常工作来操作该系统的人

最终用户开发者来自最终用户组参加开发队的非系统人员

系统设计师总体技术设计人员

应用分析员复审最终用户需求并定义系统说明的人

数据库管理员数据库的管理人员

数据管理员负责命名和控制数据元素名和内容的人

界面设计者决定最佳人一机接口方法和风格的专业技术人员

网络设计师负责通过数据通讯工具和协议来集成所有系统成份的专业技术

人员

文档人员开发用户手册、帮助程序和系统的技术说明的专业技术人员每个这样的角色都是唯一的、彼此不同的。多数情况下，应用不能运行或不能达到预期目标是因为开发队忽视或过低地估计了某个关键角色和职责集的重要性。如下图所示，可以看到每个角色和职责在何处对系统做出贡献。

图3. 1角色及它们建的关系和对开发过程的影响当然，并不需要每一个角色自始至终都全时工作，关键是要保证与每个角色关联的职责被指派和满足。从项目管理的角度看，成为一个系统应用开发者包含的内容不只是掌握CASE工具和应用开发工具，区分并且把每个应用参与人纳入到开发过程中是任何系统项目成功的关键。

3.2数据库的标准化

标准化是关系模型的改良或扩展，标准化也是依照第一个关系模型草案并在此基础

上采用一定具体方法进行改进的进程，和关系模型一样，标准化的基础是数学，它是建

立在被称为函数相关性(functional dependency, FD)的概念上的。为了保持数据完整性、建立一个尽可能与应用无关并减少存储需求的模型，标准化的主要目的就是消除关系模型中不是主键造成的所有函数相关。在进行和建立数据库之前，需要了解逻辑数据库设计和标准化背后的基本原则。以下是标准化的三个主要范式:

第一范式:第一范式(1NF)不包含重复组，这等于说贮存在一个单元里的数据必须是一个单一、简单值，而且不能保留一条以上的信息。为了清晰，信息原则不允许在一个列中有重复组，而1NF额外要求在一行中不能有重复组，不管是重复的列还是列中含有的重复信息都不允许。本质上，一个表的列集合可以看作是由一个主键和剩余项组成，剩余项的任意一部分都是非键列。

第二范式:第二范式(2NF)没有不完全相关，每个非键列都依赖于全主键，如果主键是复合键，则包括它所有的列。

第三范式:第三范式(3NF)没有传递的相关性。没有依赖于其他非键列的非键列，如果一个表所用的非键列都依赖于键、全键，并且只依赖于键，那么这个表就是3NF形式的表。如果消除重复组后，每个非主键列都依赖于键和全键，这是2NF，只依赖于键则是3NF。

Boyce Codd范式(Boyce Codd Normal Form, BCNF)包括不反转的不完全相关(有时不太正规地称之为3 1/2NF)，主键和它的任何部分都不依赖一个非键属性。因为你取的是非键的严格定义，3NF考虑候选键问题，而且你的表总是BCNF形式的。还有第四范式和更高级范式。在学术上，标准化理论己超出BCNF许多级了，通常数据库分析和设计的相关书籍己达到5NF的高度。4NF处理多值相关(MVD)问题，而5N1 T处理连接相关(JD)问题。尽管这些范式的理论稍稍超出了本书的范围，但你应该知道如果每个MVD都是一个FD，那么这个表是4NF形式的表；如果每个JD都是它的关系键的结果，那么这个表是5NF形式的表。第七、第八范式等在一些论著中有介绍。另外，可供选用的范式例如域键范式(Domain Key Normal Form, DKNF)己经被发展，与当前标准化理论并行，或包含了当今的标准化理论。如果可能，研究第四范式和第五范式，设法通过努力达到这些级别的标准化。作为一个数据库系统管理员的目标就是尽可能地提高标准化程度，然而使用尽可能少的实体来实现它们。这是一个挑战，因为，通常标准形式越高，产生的实体越多。

DBMS也应该遵循Codd提出的十二条法则，才能被分类到完全关系型:

(1)信息法则。信息表现为贮存在单元中的数据。