您的当前位置：首页正文

高校教务管理系统的研究

来源：好走旅游网

高校教务管理系统的研究

摘要：本论文主要讨论了实体一关系数据库建模方法的局限性以及如何利用面向对象的思想进行改进，并且以我校的教务管理的实际情况为背景，对基于校园网的教务管理信息系统进行数据库建模和网络运行环境的设计，其中还涉及了中间层组件的开发方法和排课算法的初步探讨。

关键词:组件模型；实体一关系模型；数据库建模；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)信息法则。信息表现为贮存在单元中的数据。

(2)授权存取法则。每一个数据项必须通过一个“表名+行主键+列名” 的组合形式访问。例如，如果你能用数组或指针访问一个列，就违反这条规则。

(3)必须以一致的方式使用空值。如果由于缺少数字值，空值(Null) 被当作0来处理，或者由于缺少字符值而被当作一个空格处理，那么它就违反了这条规则。空值仅仅是指缺少数据而且没有任何数值。如果缺少的数据需要值，软件提供商通常提供使用缺省值的能力满足这一目的。

(4)一个活跃的、在线数据字典应作为关系型表被存储，并且该字典应该可以通过常规的数据存取语言访问。如果数据字典的任何部分贮存在操作系统文件里，就违反了这条规则。

(5)除了可能的低级存取例程外，数据存取语言必须提供所有的存取方式，并且是存取的仅有方式。如果你能通过一个实用程序而不是一个SQL接口来存取支持一个表的文件，就有可能违反了本规则。参见规则120。

(6)所有能被更新的视图应当是可更新的。例如，如果你能将三个表连结起来，作为一个视图的基础，但却不能更新这个视图，则违反本规则。

(7)必须有集合级的插入、更新和删除。目前，大多数RDBMS提供商都在某种程度上提供了这种能力。

(8)物理数据的独立性。应用不能依赖于物理结构，如果一个支持某表的文件从一张盘移动到其他盘上或重新命名，不应该对应用产生影响。

(9)逻辑数据的独立性。应用不应依赖于逻辑结构。如果一个表必须被分成两个部分，那么应该提供一个视图，以把两段连接在一起，以便不会对应用产生影响。

(10)完整性的独立性。完整性规则应该贮存在数据字典中。主键约束、外键约束、检查约束、触发器等等都应该贮存在数据字典中。

(11)分布独立性。一个数据库即使被分布，也应该能继续工作。这是规则8的一个扩展，一个数据库不仅能在一个系统(本地域)分布，也能在通过系统的网络(远程域)分布。

(12)非破坏性法则。如果允许低级存取，一定不能绕过安全性或完整性规则，这些规则是常规的数据存取语言所遵守的。如果一个DBMS能满足本章中讨论的所有基本原则和这十二条法则，那么它就可以被当作一个RDBMS. Codd用他的法则0总结了这一切:“对于一个有资格成为RDBMS的系统来说，该系统必须排他地使用它的关

系型工具来管理数据库。”

3.3数据库的建模原理

作为管理数据库的软件，数据库管理系统(Database Management System，DBMS)充当所有数据的知识库，并对它的存储、安全、一致性、并发操作、恢复和访问负责。DBMS有一个数据词典(有时被称为系统目录)，其中贮存着它拥有的每个事物的数据，例如名字、结构、位置和类型，这种关于数据的数据也被称为元数据(metadata)。在一条数据的生存周期里(从它的创建到删除)，这条数据的逻辑和物理信息都被记录在数据词典中。

在关系数据库(RDBMS)产生之前，层次(IMS)和网状(IDMS )模式是常见的。这些模式使用平面文件来建立数据库，并且使用第三代语言(3GL)访问例程。CODASYL(数据系统语言协会)是数据库任务组(Database Task Group,DBTG)创建的一种数据库标准，这是一种基于COBOL的网络数据库标准，并且INS是一个厂商的实现。

但是，从70年代起，RDBMS已经逐渐地控制了市场，如Oracle, Sybase,Informix和Ingres。永久存储的需要是促使DBMS和RDBMS的出现来替第三代语言(3GL)/基于文件的信息系统的最基本的原因之一。此外，由于多维数据库(Multi-Dimensional Database，MUD)为带有许多必须被多维存取或列表的变量(例如行为科学数据)的应用提供了高度索引化的数据，而在传统的RDBMS中，这几乎是不可能实现的，数据库只允许单独使用。RDBMS供应商提供了一些他们自己的层次产品，这些产品提供超级索引化的数据，并使用了特殊的技术，例如:位映射索引。

以上是数据库的发展的简要介绍，下面将对实体一关系的建模原理做简要概述，并讨论其局限性，以及从面向对象的思想出发对建模方法的改进。

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

1970年，E. F. Codd创立了关系模式的概念。这其中最流行的是实体关系图(Entity-Relationship Diagram，ERD )，它是P. P. Chen在1976年提出来的。这就是语义数据模型，因为它试图捕获业务要素(业务本质)的语义或正确含义。在这个模型中，实体定义为可标识的对用户重要的事物，所有给定类型的实体构成实体类，一个特定的实体称作实体实例，实体有描述她们特征的属性，一个或多个属性表示一个实体。因为关系模型本身几乎就是一个依据语法的模型，是一种主要处理结构的模型，实体一关系图(ERD )通常用于补充它。实际上，实体一关系图建模必然先于关系建模。一个实

体一关系图可以准确地映射到关系模型上，从而实体变成了表，属性变成了列，标识符属性变成了主键。

关系是指实体之间的关联，E-R模型清楚地定义了关系，每个关系都有名字，有关系实例，也有关系类。关系的元是参加关系的实体的数目，大多数关系是二元的，二元关系的三种类型分别是一对一、一对多和多对多。

在实体一关系图中，实体用长方形表示，关系用菱形表示。关系的最大基数表示在菱形内。最小基数用脉冲符或椭圆表示，连接同类实体实例的关系是递归关系，属性在实体一关系图中的表示可以在椭圆中，或用单独的表列出。

弱实体是其存在依赖于其它实体的实体。弱实体用圆角的长方形表示，实体所依赖的关系用圆角的菱形表示。

某些实体有子类，它用来定义相似的实体的子集。子类从它们的双亲，即超类继承属性。子类并非总是互斥的，也并非总是必要的。HAS一连接不同类型的实体，这些实体的标识符各不相同。工S一关系是子类关系，所连接的实体的标识符相同。

一旦数据模型开发完成，设计这就应该考虑约束实体处理的事务规则。模型中的每一个实体应该根据可能的数据添加、修改和删除进行评价，特别是删除，它经常是重要处理约束的来源。发现事务规则后应该在数据模型中进行记录。

实体一关系模型是很多CASE产品的重要组成部分，这些产品提供了构造和存储实体一关系图的工具，其中某些工具在CASE库中集成了实体一关系构件和数据构件，如PowerDesigner, ERWin等。

实体一关系模型完成之后，就应该进行评价。一种技术是列出可以用数据模型回答

的问题，接着把列出的问题给用户看，并让他们考虑一些另外的问题。设计的评价针对这些问题进行，以确保模型能回答这些问题。

数据库不是对现实世界建模，而是对用户关于其业务环境的模型建模。判断一个数据模型好坏的合适的准则是看它是否与用户模型吻合。争论那一个最符合现实世界是没有意义的。

3. 3. 2实体-关系建模的局限性

由于CASE工具使数据库建模变得更为丰富，更像一门艺术，使得对同一情况建模有了更多的方法。实体一关系建模的中心思想是，可以通过实体和它们之间的关系合理地体现一个组织的数据模型。事实上，不能通过简单地先识别实体，然后再识别这些实体之间的关系来设计，这两个过程必须同时出现。然而，许多不良数据模型却正是首先

确定所有实体，然后用关系将它们连接在一起的方法建立。这里我们主要讨论实体一关系建模的局限性。

首先，实体一关系建模存在的问题体现在的命名上。但从表面上看，这样做似乎对描述一个组织的信息过于简单化，并且词汇量也远远不足。例如，一个表的的非主键字段是由主键唯一标识的，但在主键的命名上却往往不能表示这种支配关系的含义，仅仅是作为实体的一个属性而存在的。

其次，实体一关系建模在关系数据方面仍然存在一些局限性。使用实体一关系建模存在三种可能的关系类型:基数关系、依赖关系(UID连线)和子类。使用这些关系来描述复杂数据模型的关系时没有提供充分的灵活性，下面将详细分别讨论每一种关系的局限性。

(1)基数关系:一个实体的第0, 1或N个实例与另一个实体的第0, 1或 N个实例存在关联。例如，如果业务规则是篮球队中必须有5名球员，使用实体一关系图表示这种业务规则是相当困难的。

(2)依赖关系:在实体一关系图中，通过两个一对多依赖关系的相交表来表示多对多关系。但是如果有多个交叉实体，例如，学生、自然班级和授课班级之间，授课班级即可能是单个自然班，也可能是多个自然班，还有可能是多个自然班的某一些学生，这时实体一关系图的表达是比较困难的。

(3)子类:实体一关系图中的子类是指将一个实体分成若干个相互独立而整体内容全面的子集。例如一个关于合同的类，可以用固定价格、时间与材质、属于政府的还是私有的来划分。若要查找特定的合同，就需要所有可能的子类的笛卡儿积。从层次上来看，若继承子类的层次多于3时，最底层的子类的主键将包含所有父类的主键，而当一张表的联合主键包含4个以上的列时，理论上是可行的，但实际上是不可用的。在教务管理系统中，院、系、专业、专业方向就是典型的继承关系，而每个专业方向下还有学制信息、教学计划、教学进程等相关的信息，这就是一个类似的问题。

最后，在实体一关系建模中，数据和应用的分离，使得在后期开发中的灵活性不好，在功能的扩展上有一些困难。因为我们通常是从需求分析中，提取功能要素和建模信息，但是当数据库己经建立后，在开发过程中，由于各种原因，往往会遇到系统功能和建模信息的变化，而导致小的修改或重新做起。如何使数据和应用结合的更紧密，是我们必须考虑的问题，然而实体一关系图却不能给我们提供更多关于业务流程的信息。

就关系模型本身而言，这是一种非常精巧、清楚的模型，它已经为数据库行业提供

了近20年的基础。关系理论中较少的概念已使关系数据库成为行业标准。关系数据库厂家已经能够从系统逻辑设计上孤立数据库物理实施的复杂性，由此提供了一个简单的应用开发者接口。但也正是实体一关系建模仍然存在许多局限性，使我们感觉到建模环境需要更加丰富的必要性，这种环境应该更能适应向类属建模的发展，而且，我们认识到面向对象理论的一些概念能够被引入数据库行业，甚至可以带来更高的效率，因此，下面将介绍如何采用面向对象的思想对传统建模方法的改进。

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

关系数据库方法是在一个最低级的层次上，用一系列的表、列和行处理数据，而面向对象的方法是在更高的层次上处理数据的，它处理包裹着数据的对象。从对类的定义(类是一个组织中所关心的部分或是划分感兴趣的事物的一种方法，其核心是实体或类经常用来体现真实世界中的某些事物)可以看出，同实体的定义是相同的，但是类的正确定义要比实体的定义涉及的范围更广。我们对类的定义比面向对象领域中对类的定义范围更小一些，出现这种区别的原因是，面向对象领域是从编程环境(经常是C++或SmallTalk)的角度得出这个概念，而数据库领域中考虑的是建库。从U++程序员的角度来看，类是定义的数据结构，对象是这些定义的数据结构在运行时的实例。而在数据库领域中，类与表相对应。既然得出的概念来自不同的角度且解决不同的问题，定义的内容自然就会不同。

因此，这里所讨论的，不是完全按照面向对象的思想重新建模，而是针对上节实体一关系建模的局限性来进行改进，并且，我们把实体这个概念作为建模的基本出发点，把实体及其关系看作数据模型的原子，用这些原子的结合形成用户的视图。下面就从两个方面来考虑。

首先，在面向对象中，一个重要的概念是对象标识符(OID)，它表示一个在对象创建以后唯一代表该对象的统一标识符，与关系模型中的主键和外键这些东西是不同的。然而，它在某种程度上像数据库中的主键，它们必须在表中中是唯一的。作为对传统关系方法的一种改进，就是把对象标识符和主键结合在一起，在实际的数据模型中，就以对象编号形式出现并在表中做主键。

例如:在教务管理系统中，有标准代码编号、教师编号、学生编号、入学年份编号、院系专业方向编号、学年学期编号、教研室编号、教研室开设课程编号、授课班级编号等。需要强调的是，不是所有实体的主键都是用对象编号来实现的，例如:班级和教室、

教学区就是用其名称作为主键的。因此要根据具体情况来分析确定，这种改进在带来优点的同时，也有一些不足之处。

优点在于:对于用户，整个系统从表面上看似乎是基于面向对象的，但是实际上数据是关系型的。由于采用了编号，在命名上有了更大的灵活性，可包含更多的信息，甚至业务规则，如课程编号((6位)是由教研室编号((4位)和该教研室开设的课程序号((2位)组成的，不难看出，这个列包含了开设课程和教研室这两个实体之间的继承关系，同时，编号的采用也规范了WHERE子句的写法。更重要的是，由于对联合主键(包含大于2个以上的列)的简化处理可以使其子类实体的继承联合主键的列不会太多，这样就可以大大提高数据库的性能。

缺点在于:从编号的数字位有限组合，如课程序号是2位，即每个教研室开设的课程数目不超过100门。因此，在需求分析时，必须要考虑随时间而引起的变化，增加冗余。也可以看出，确定的值域范围，对表达特殊的业务规则是很方便的，如表达一个篮球队仅有5名球员的概念。当然这些都需要相应的应用过程来保证其数据的完整性，触发器和参考完整性都无能为力。

其次，当建立一个超类/子类模型时，在标准化的前提下应用面向对象的思想。在关系模型中并没有明确的方法实施子类，要么把所有的属性放到一个表中，要么将它们分成两个或更多个表。在关系数据库中并没有明确的方法表达“概化”的意思。这里作为一种改进，是合并具有继承关系的父子类，因为有些父类是必须存在，但对于业务模型的表达并没有实际的意义。

例如:院、系、专业、方向这四个实体是典型的父子继承关系，如果按照以往的方法就是四个独立实体对应四个表，但是方向这个子类的联合主键包含院、系、方向三个实体的主键共4列，所以当派生出其它实体时，如该方向下的教学计划实体，其联合主键的列就是大于4，这样的模型理论上可行，实际上根本无法应用，因为查询需要的迪卡尔积会导致性能的低下。有些模型就把院、系作为一个父实体，专业作为子实体，取消方向这一子类，以减少联合主键所包含的列，然而，这样都没有彻底解决问题。从业务上说，院、系、专业是必须存在的实体，但我们应用时主要是专业方向这一子类及其派生的教学计划和教学进程，因此构造的对象标识符—院系专业方向编号(院编号+系编号+专业编号+专业方向编号)，虽然仅一个实体，一个列就表达了这四个实体的继承关系，从而达到设计的要求。

优点在于:这种改进方法，使我们可以表达复合对象(至少包含一个对象的属性)和

混合对象(两种类型的对象的结合)。

缺点在于:造成了数据库的冗余，并违反了标准化。

从上面的叙述可以看出，·关系和对象思想之间理论上一个主要的不同是:在关系数据库中，分开考虑数据和应用，而在对象思想中，合起来考虑数据和与它关联的操作和方法。逻辑上，数据和代码不应该分开考虑。数据对象和它们各自的操作与方法结合起来考虑的面向对象的方法是一种更自然、更符合逻辑的方法。利用这种更自然的制作模型的方法，开发与维护速度可以期望得到改进。系统与所使用工具的分离越大，开发过程就会越长。如果能够使RDBMS及其工具与面向对象的方法更加一致，那就能够更快地构造更好的系统。希望第二个改善的结果是数据模型更小了(表减少了)、更健壮了，而且更加易于开发。

当然，对实体和实体之间关系的正确识别也是数据模型的关键所在。好的模型会考虑到随时间的推移系统将可能发生的变化，因而设计时也要很容易地能适应这些变化。设计者会对同类问题提出不同的处理方法。最优数据模型不只是被模型化的情况的一个函数，它还依赖于开发组的技能、设计环境、开发环境、系统期望的生存期、项目的时间/费用压力等因素。在下一章中，我们还将详细建模过程中遇到的问题。

第四章数据库的建模实现

大约在1996年，程序设计人员开始使用面向对象的结构进行数据库的逻辑设计，使数据模型更为清晰，同时增加了系统的灵活性和可维护性。也由于面向对象方法的引入，使数据库设计的发展得到了很大的进步，特别是模型中的实体(和最终表)的数量大量减少，这就是面向对象设计的最大优点。因为增强了结构的健壮性和灵活性，当用户提出新的无法回避的要求时，则大大降低了在数据模型上作较大修改的可能性。但是，如果认为对象建模的优势在于编写数据库程序时，不必为关系的设计和规范化而烦恼，那就大错特错了，至少目前的RDBMS仍然大行其道，诸如:SQLServer, Informix, Oracle:并且在建模中规范化设计也是必不可少的。

现在，实现面向对象设计的工具不少，但是真正结合对象一关系建模的一体化开发工具就不是很多，优秀的产品诸如:Rational Rose, Oracle Designer,B1uePrint等CASE工具。当然，我们也可以用非完全面向对象工具来发，本系统的开发平台就定位于WinNT+MTS+MS SQL Server，采用PowerDesigner

进行数据库的逻辑模型和物理模型的开发。只要在思想上转变为面向对象的思考方

式，也可以设计得很好，即便是在面向对象的设计中使用传统的关系结构。面向对象软件工程的一个很大的好处就是在分析和设计之间没有什么明显的区别，更不会有传统软件工程中在分析和设计之间的语义上的鸿沟。在分析进行到一定程度时，把具体实现环境的因素考虑进来，就自然过渡到了设计阶段。从面向对象的角度来看，系统的功能是由一组对象通过相互发送消息来完成的，顺序图和协作图就是通过描述这样的对象和消息来描述系统的动态行为的，这些可以明显的从前一章的对象模型和事件跟踪的描述中看出来。在给出的状态图中，我们可以看到对象从事件导出的操作，实际执行这些操作时，对一个给定状态可以有更多的相关任务。

在第三章中，我们谈到ERD建模的局限性和对传统建模方法的改进，下面就本系统而言，将从实体之间的关系、应用逻辑的实现、参照完整性的设计、查询模型的设计四个方面加以阐明。

4.1对象之间的关系

在附录1中，给出了该数据库的物理模型，从中可以看出实体之间的关系。实体本身就是一个对象，这里的每一张表代表一个包含数据处理的对象类。它并不像需求陈述中简单的名词结构，既可能是一个简单对象类或复杂对象类，也可能是一个组合对象类，这是根据系统的功能而定。对象本身不仅要有唯一的对象标识符(OID )，而且必须实现第二范式的规则要求，使OID作为主键并决定其他属性。系统产生的OID是经过编码的值，数据库不能从用户定义的列中保证其值的唯一性，必须建立列之间的约束关系，从而带来相应的数据信息的处理。例如:编号，它不同于RDBMS的为表自动添加的唯一的自增益列，这个编号需要在开发应用说明中给出详细的定义以用于数据处理。主要好处在于它们大大简化了WHERE语句的规范。在使用ERD建模工具表达对象之间的关系时也是用编号的组合实现的。

在关系型建模中，是通过基数、依赖关系和子类/超类表达实体之间的关系，依赖关系是通过把外键作为主键的一部分来实现的，这样会带来一些意想不到的负效应。首先，如果在一个链中有多个依赖关系，主键就会变得很大。其次，如果依赖表是递归的，外键也可能会变得很庞大。这些问题对于新的对象关系结构是一样存在的。

在本数据库的逻辑设计中，并没有照搬问题域的划分，而是合并了一些问题域进行了新的模式划分，分为标准代码、教师、学籍、教学计划四个子模型。标准代码子模型是其他实体的公共属性构成对象的集合，教师子模型和学籍子模型为教学计划子模型提

供基本信息的独立问题域，教学计划子模型合并了基础数据管理、教学计划管理、排课管理、考务管理四个问题域。这样，对于应用逻辑的实现和静态数据结构的清晰都有帮助。

在标准代码子模型中，系统构造了有代码表名称的代码库组合对象及其所包含的各属性组(即各代码表)。考虑到代码库中的代码表还有增加的可能，因此设计时没有建立关系，而是在中间层的数据处理中进行了关联。

在教师子模型中，系统构造了有教师编号的教师组合对象，含有基本情况、技术职务、学历情况、工作量汇总、专利情况、考核情况、简历情况、国内进修、出国情况、论著情况、惩处情况、科研情况、奖励情况十三个属性组。对应在ERD设计中，以基本情况为父实体，其他十二个属性组为子实体，继承父实体的教师编号。教师编号是整数字段(>0)，无特殊含义，仅为序号((5位)，为教师对象的标识符，是其他子模型的引用标识。

在学生子模型中，系统构造了有学生编号的学生组合对象，含有基本情况、体检情况、注册情况、入学成绩、奖代金情况、奖励情况、家庭情况、毕业情况、简历情况、军训情况、处分情况、学生异动、学生成绩十三个属性组。对应在ER)设计中，以基本情况为父实体，其他十二个属性组为子实体，继承父实体的学生编号。学生编号是整数字段()0)，为学生对象的标识符，是其他子模型的引用标识。现有学生编号，是由入学年份((4位)和序号((6位)组成的。

在教学计划子模型中，除了引用了标准代码子模型中的一些代码表和教师、学生子模型中的基本情况，还包含教学区、教室；教研室、课程；教材表；教学进程类别；入学年份、学年学期、院系专业方向、班级、授课班级；专业方向学年学期、审核历史记录、教学进程、教学计划、教学任务。这些对象都是以编号为标识符，组合构成主键。

教学区对象是以教学区名称为主键，教学区专用标志是用来标识排课时选教学区的优先级。

教室对象以教室名称为标识符和主键，从属于教学区对象，容纳听课人数、容纳考试人数、班级专用标志、考试专用标志的属性是用于排课管理。

教研室对象以教研室编号((4位)为标识符，作为主键表示了院或部门((2位)和教研室((2位)两部分内容，若4位中的后两位为0，则该编号表示院或部门。在教师基本情况中，引用了教研室编号，实现与教研室对象的从属关系 (聚集关系，非组合关系)，这里没有采用实体关系中的父子关系，即教研室编号外键和教师编号一起做主键，因为

教师可以属于教研室，也可以不属于教研室，如:外聘教师。

课程对象以课程编号((6位)为标识符和主键，从属于教研室对象，表示了教研室((4位)和课程((2位)两部分内容。课程对象除了本身自带的属性(名称、内容及其描述)，其他属性如学分、共计学时、讲课学时、上机学时、试验学时是作为缺省值，当选择教学计划的课程时，可方便的加入该课程相关的默认信息。

教材表对象以教材编号((6位)为标识符和主键。该编号为序号，这里不用名称，是因为教材的名称一般较长，不利于检索，而在教学区对象和教室对象中，名称是由规律的，如教一楼(教学区)中的201教室就可表示为1-201, 并且长度有限符合习惯。教材管理本身就是一个子系统，本设计做了简化，只引用主对象，以后也便于扩展其他对象。

教学进程类别以教学进程标志((2位，扩展ASCI工符号)为标识符和主键。授课进程标志和实践类进程标志是用来标一记时间进程的分类属性便于统计分析、审核。

入学年份以年份((4位)为标识符和主键，表示入学年级，并赋予当前年份和目前在校年级的标志属性。

学年学期以学年学期编号(()位)为标识符和主键，由年份((4位)和春秋学期标志(1位)构成，如:xxxxl表示xxxx年春季学期，xxxx2表示xxxx年秋季学期。

院系专业方向以院系专业方向编号(12位)为标识符和主键，由入学年份(4位)、院编号((2位)、系编号((2位)、专业编号((2位)和专业方向编号((2位)构成，xxxxYY000000表示xxxx年的学院编号，xxxxYYXX00表示xxxx年的YY学院的系编号，xxxxYYXXZZ00表示xxxx年的YY学院XX系的专业编号，xxxxYYXXZZFF表示xxxx年的YY学院XX系ZZ专业的专业方向编号，YY, XX, ZZ,FF为01-99。因此该对象是复合对象，表示学院、系、专业和专业方向，在实体关系中，主要引用专业方向，学制信息表明该方向的在校时间，单位为年。之所以要从属于入学年份，是因为每年的机构设置会有变化，制定每一年级的教学总计划需要根据当前年的专业方向设置。

专业方向学期以专业方向学年学期编号(18位)为标识符和主键，由院系专业方向编号(12位)、学期号((1位)和学年学期编号((5位)组成，学期号表示该学期为在校期间第几学期。专业方向学期作为专业方向与学年学期的组合对象，是为了解决不同专业方向的学制不同而设计的，因此可以适用于大专 (3年6个学期)、本科((4年8个学期)、研究生(2.5年5个学期)不同的学制要求。也因此引入了相应的数据信息处理，即自动生成处理。到这一步时，教学计划由在校期间课程和日历的安排己细化为每个学期。

教学计划(课程安排)以专业方向学年学期编号(18位)和课程编号((6位)为标识符

和主键。该课程安排是在校期间的课程，所以可能是年级总教学计划添加的，也可能是年级分教学计划补充的，业务逻辑和操作方法见下面几节的说明。教学计划课程从属于专业方向学年学期和课程这两个对象，因此除了本身的属性(包括缺省属性)外，还有与该专业方向有关的属性，如考试方式、课程类别、考试类别、课程大类、教材编号、考试学期、学位课标志。在设计中，把毕业设计、生产实习、教学实习、课程设计作为一门课，所以毕业设计周数，生产实习周数、教学实习周数、课程设计周数、课程设计上机学时、课程设计学期这几个属性是互斥的。

教学进程(日历)以专业方向学年学期编号(18位)和半周次((3位)为标识符和主键。因为从属于专业方向学年学期对象，所以教学日历是指每个年级的每个专业方向的在校每一学期的开学第一周到学期末最后一周以半周为单位的教学进程标志(引用教学进程类别)。这里采用冗余性设计，即半周次表示101-130(上半周)和201-230(下半周)，不管每学期(加上假期)是否满30周，都按30周计算。

历史记录以专业方向学年学期编号(18位)为标识符和主键，从属于专业方向学年学期，记录每个年级的每个专业方向的在校每一学期的教学进程、教学总计划、教学分计划、教学任务的审核事件。只有教学总计划审核通过(教学日历审核标志为1和教学计划审核标志为1，未通过为o>，才能进入教学分计划审核；只有教学分计划审核通过(教学计划审核标志为2)，才能进入教学任务审核；只有教学任务审核通过(教学任务审核标志为1)，才能进入排课阶段、考务阶段。

班级以班级名称为标识符和主键，从属于每一年级的专业方向。班级人数、毕业标志是本身的属性，指定教室名称引用教室对象标识，用于排课管理中参考班级的常用教室。在学生基本情况中，引用了班级编号，实现与班级对象的从属关系(聚集关系，非组合关系)，这里没有采用实体关系中的父子关系，即学生编号外键和班级编号一起做主键，因为学生从入学到毕业还可能重新分班，跨专业或不跨专业的正常情况(非学生异动—学籍状态不正常)。

授课班级以授课班级编号(10位)为标识符和主键，表示授课单位，班数、人数为该授课单位的相关属性，具体信息需从授课班级情况中获得。因为从按专业方向划分的教学计划生成按班级划分的教学任务后，有合班和分班的操作，这里采用授课单位来实现这种操作。因此，授课班级情况以班级名称、授课班级编号、学号为标识符和主键，保存授课班级生成的信息，为减少冗余，对整班的情况，学号为空以表示全班学生均参加该授课班级。授课班级编号(10位)分两种:班级名称及合班名称—表示为:‘合’(2位)+

学年学期编号((5位)+序号xxx (3位)。班数属性为0，表示该合班为空，可插入。

教学任务以授课班级编号、学年学期编号、课程编号为标识符和主键。表示从按专业方向划分的教学计划生成的按班级划分的教学任务，保存课时分布情况(周学时、起始周—以半周为单位)和任课教师情况(教师编号)。根据教学任务及授课班级情况可以在教学计划对象中查找相应课程的情况(学分、学时、类别等)，因此没有在教学任务中重复保存课程相关信息，减少冗余。

课表对象和考试安排表对象本系统没有涉及，因为是初步研究排课算法，算法还不成熟，在初步研究时，是采用动态生成的方法，即动态建表，更新表。这一部分可以在以后算法成熟、稳定时再扩展数据结构。

以上是对象之间的自身和相互之间的关系描述，下面将讨论参照完整性的设计。

4.2参照完整性的设计

在面向对象的系统中，对象将通过对象引用和参照完整性联系起来，同时还具备触发器和方法。表可以独立构造，也可从一些父结构(称为类)继承属性和方法。当开始以面向对象的方式来思考问题，每当建立一个超类/子类模型时，面向对象的思想就得到了使用。然而，很难将这些实施到一个关系模型中，在关系模型中并没有明确的方法实施子类，要么把所有的属性放到一个表中，要么将它们分成两个或更多个表，而在关系数据库中并没有明确的方法表达“概化”、“组合”、“聚集”的意思。在关系型的依赖关系中，子对象不能脱离父对象而存在；“聚集”是一个比依赖关系要弱得多的概念，父对象不能脱离子对象而存在，而且这两个对象还可以独立存在，如:教研室和教师；“组合”是一个比依赖关系要严格一点的概念，父对象与子对象同生共灭，如:入学年份对象和院系专业方向对象。因此要维护对象之间的参照的完整性，就必须在操作(更新、删除)对象时，根据对象之间的关系确定相关对象的操作。

在确立逻辑模型后，本系统设计对更新操作采用级联更新方式，即:当主键信息更新时，同步更新外键对主键信息的引用；对于删除操作采用严格的依赖关系，即:当删除主键信息时，若外键仍存在对主键信息的引用，则不能删除主键信息。这些将在数据库中生成触发器，作为特殊的存储过程维护表与表的参照完整性。同时，检查触发器，避免递归触发。

但是，从上一节的描述中，不难发现由于采用了大量的编号，已超出了关系模型所能表达的，参照完整性的维护需要依赖于在中间层中进行维护表自身的第三范式特征以

及可能违反第一范式的数据冗余处理的操作。如:复合对象—院系专业方向、教研室的数据添加，需要一级一级从上到下逐个添加(产生数据逻辑)，不相关的属性则需要置为“空”(数字置为0>，产生冗余数据；组合对象—教学计划的课程属性中，毕业设计周数、生产实习周数、教学实习周数、课程设计周数是互斥的，并且与其他类别的课程也是互斥的，也会因此需要产生数据逻辑而置为“空”(数字置为0>；对象引用—所有表除备注字段允许为空白外，其余的都有缺省字段(置为“空”，数字置为0)，因此需要在创建数据库时，进行初始化，导入标准代码和保留空记录(对编号而言，为全0)。由此可见，对象一关系数据库的设计中，性能的原因使得必须进行非规范化，例如:一个大型的复杂数据模型在核心表中有千万行记录，可能只能通过非规范化才能够获得可接受的性能。同时，使用非规范化也可简化应用逻辑，为生成一个特定的报表或屏幕，可能必须存取多达10到20个表以检索一条特定的信息。如果在数据库的其他地方存储该信息的冗余，我们就能够极大地降低程序逻辑的复杂度。为进行非规范化，一般说来，有以下几个方面:

1)冗余总额域；

2)表中行内的冗余属性； 3)不从属的额外外键； 4)用于历史记录的冗余列；

5)递归层，在某些应用中存在树、网络、链接表等任何递归结构； 6)分类主表； 7)违反第一范式； 8)过载列； 9)多属性列； 10)冗余历史记录表；

然而，是否非规范化所产生的好处真的超过了额外编码和编制文档的成本。大多数时候，实施非规范化的目的在于通过报表生成功能所获得的性能好处。但是，从事务处理的角度而言，非规范化降低了性能。除了违反第一范式 (我们不提倡，本系统也只使用了2), 4), 6), 7), 9))，以上每一个非规范化都涉及到从一个完全规范化的第三范式数据库开始，同时加入一个临时冗余列。这对于建立好模型是一个关键概念，因为它维护了一个概念上简洁的基本模型。我们所需要做的只是向模型中增加内容，且无需牺牲任何灵活性和概念上的清晰性。通过把惯例称为非规范化来添加清晰确认的内容，

仔细记录域的出处，并且通过数据库触发器来完全实现，都会使我们得到了最好的结果:一个清晰、理论上正确的模型及其充分的性能。在付出了代价的同时得到优化的表结构(明显的表数目的减少)和概念上的清晰(简化了Where语句部分)。

4.3应用逻辑的实现

从以上描述中，我们可以发现关系和对象思想之间理论上一个主要的不同是:在关系数据库中，分开考虑数据和应用，而在对象思想中，合起来考虑数据和与它关联的操作和方法。对ER模型制作者来说，类和实体一般认为是等同的。但是，它们之间有一个重要的分别，即类和“方法”是有关系的，方法可认为是PL/SQL, Java或与表相互作用的函数。在对象扩展中，主键补充上了对象标识符(OID)，传统的参照完整性利用对象指针进行扩展，且增加了两个非第一范式结构:嵌套表和参考表。因此设计一个好的关系数据库的原则，以及规范化的合理使用，也都应当应用到对象关系模型中。逻辑数据模式体现的是数据库的设计，而物理数据模式体现的是设计的实现。

在教学计划物理子模型上，可以看到对象之间的应用逻辑，如下所述:

首先，在新年级即将入学之前，制定该年级在校期间每个学期的所有课程和教学进程安排(年级教学总计划)，教学进程一旦生成并通过审核后，将作为审核课程课时分布的重要依据，同时也对所有学期的课程进行学分、学时、课程类别等进行统计并审核；

其次，在每学期开学前一学期，从教学计划中查询在校各年级下一学期的课程，即由年级教学总计划生成年级教学分计划，根据当前的情况，补充、更新课程，也因此需进行二次统计和审核，最终生成该学期每个在校年级每个专业方向的课程设置，即教学任务；

最后，通过对该学期每个年级每个专业方向的课程设置的审核，生成该学期的排课数据，这时排课数据己由从属于每个专业方向变为从属于每个专业方向所属的班级(该班级为不可分割单位)，然后根据具有相同课程和相同课时分布的班级，生成授课单位，可以进行自动或手动合班和拆班，优化排课数据，并需要添加相应教学任务的课时分布(指定周学时、起始周和结束周)和任课教师，依靠约束条件和基础数据，排课算法寻找最佳的课时分布和最佳的教室利用，最终生成课表。由课表可以进行每学期的考试安排，并将考试结果添加到相应的学生成绩中，也因此产生教师的教学工作量。

这里需要说明的是，学生选课信息是保存在授课班级情况中，即学生选修课程还是以班级为单位参加，具体参加的学生(学号)被记录在案，整班时该学号信息为空，减少

了冗余，也就是说学生选课是在授课班级情况上操作的，该年级的每个专业方向的教学计划的课程不仅包括必修课也包括选修课，这在课程类别中做出了说明。因此，全校或院级选修课程是根据选修的学生所在班级的所属专业方向而加入该专业方向的教学计划课程，重复的就不用再次加入。

以上所述的应用逻辑过程，描述了主要事件发生的先后次序。对于基础数据的维护上，原则上是在每次新年级入校前一学期制定该年级的教学计划时进行添加和更新的。对于合班和拆班的过程，是为了根据学校的实际情况进行授课单位的重新划分和组合。授课班级编号(‘合’+5位学年学期编号++3位序号)，说明该学期合班数最多只有1000个合班，课程编号((4位教研室编号++2位序号)说明该教研室最多能开设100门课，其他编号也存在类似的问题，这是采用编号不可避免的问题，因此上述参数是在调研本校情况后，结合将来发展情况而定的。数据库设计也因为各表采用编号作为主键而没有严格使用依赖关系，仅是简单的一对多关系，因此联合主键的减少使系统的性能大大提高了。

对ER模型和关系型数据库最强烈的批评莫过于指责它们对处理过程缺少关注了，我们最终得到不好的模型的一个原因就在于设计过程是由ERD驱动的。常常我们只是在ERD完全完成的时候才开始考虑处理过程，甚至在这个时候，对与处理过程相关的信息的关注也比模型本身要少，且通常是在应用程序写完以后才真正意识到处理的需求。由于数据的不断变化，需要特别关注与时间有关的信息的数据模型，如前面的应用逻辑，为跟踪随时间变化的信息—这里是审核状态，可以采取一些策略，即当数据发生变化时，有些情况下我们需要跟踪这些变化，而另外一些情况下，我们却只需要当前值。历史日志很容易实现，因为它可以像附加在一个对象上的备注那样简单，若重建一个对象以前的映像需要大量存储，通常更难于编码。在任意一个系统中，有如下六个主要方法来处理历史记录:

1)将历史信息倒入到一个交叉表中； 2)增加属性以处理历史记录； 3)保留事务日志； 4)复制类；

5)将对象及其历史记录存储在同一个类中； 6)隐含的处理一历史记录是模型的一个固有部分；

关系型数据库中建立这些状态转换图的模型需要大量反复工作。一旦一个系统的数

据模型建好，并且逻辑上是正确的，我们就可以成功地实现这个模型，并且创建应用程序。但对实现而言，这种设计并不一定是最佳的，同时也没有理由认为现存的数据模型一定是不充分的，只有对查询模型的充分测试，才能得出正确的判断，是否要改进。

4.4查询模型的设计

结构化查询语言(Structured Query Language, SQL)是当今主要的查询语言，它主要用于管理主流类型的DBMS一关系型DBMS (RDBMS)。数据库系统管理员(DBA )使用查询语言来建立并维护数据库，用户使用查询语言来访问数据库并查看或更改数据。查询是由可以完成检索、更新、插入和删除数据等功能的语句组成的。若不能完全理解用户的需求，就不能表示出所有所需的数据:若无内容广泛的数据模型，就不知道如何最好的构造SQL语句来检索数据。由于不能预言用户将来的数据需求的范围和特点这一显而易见的原因，只能提供对己被标识并在设计过程中被建模.的数据的访问，并把用户的数据请求翻译成SQL查询。每种查询类型(如:SELECT、多表SELECT, JOIN、视图、INSERT)都会对数据库产生一定的影响。查询是根据具体情况来决定时应该由应用产生还是应该作为存储过程来执行。查询的模拟也是极为必要的，否则就必须在开发过程中去摸索。

从应用说明到数据模型、查询模型定义和数据库对象创建正如下图所示，使一个反复、审校、细化的过程。这是一个将前几节定义的数据请求变为SQL查询的过程以及确定如何在构造数据库时支持这些查询。

对本系统而言，分为对象视图((JOIN多表的复杂SELEC下命令)和编辑操作(简单检索、插入、删除、更新等)两部分。对象视图是对数据信息的只读浏览，之所以JOIN其他表，是因为对象引用都是标识符，即编号，但对用户隐含。例如:要查阅教师对象和学生对象的属性组的信息，需用教师编号或学生编号关联基本信息表和相应属性表，显示给用户的是教师的姓名或学生的姓名。编辑操作是对表的信息进行维护的事务操作，通过对象视图或简单检索，得到相关行信息，对其进行插入、删除、更新等操作。如教师、学生、院系专业方向等基本管理信息的编辑。

第五章中间层组件的开发

在系统总体设计和数据库建模之后，本章将讨论系统三层模型中界面层和中间组件层的实现。在界面层中，分为Web用户界面和内部网专用客户端界面两部分:前者是以浏览器(IE4. x+)为容器，利用网页技术，通过中间组件层提供的Web接口调用实现教

务员需要操作的功能；后者可以用Visual Basic或Visual C++等可视化工具，通过中间组件层提供的内部网专用接口调用，生成专用客户端，实现各管理子系统的功能。

但是，本系统结构有别于传统的两层结构，中间服务层把界面层应用程序的代码与数据访问方法以及基本的数据库模式分开，当用户从DAO转到RDO和ADO时，用户服务和业务服务代码不需要更新，这是因为具有模式独立的特征。同时，当数据库、表或者域名变化时，或数据库结构改动时，不再需要更新每个界面层应用程序。

下面将介绍存在于中间组件层和界面层的数据访问技术，并给出MTS中间组件的开发原则和实现方法，最后阐明本系统中间组件层如何提供的接口设计。

5.1数据访问技术概述

目前在微软的平台上连接数据源的方法有ODBC API, DAO/Jet, JDBC等。ODBC是一种C/C++应用程序编程接口(API)，无论对于任何一种C/S关系数据库管理系统(RDBMS)，还是流行的索引顺序访问方法(ISAM)数据库(Jet, xBase, FoxPro和Paradox)以及电子表格(Excel)、定界文本文件，都能找到相应的32位ODBC驱动程序；Jet数据库引擎也是一种C/C++API, DAO提供了在Jet API之上的OLE Automation封装体，这是一个复杂的可编程数据相关对象层次模型；Java数据库连接(JDBC) API是一种低层次API，它为Java程序员定义了基于SQL的RDBMS的接口和对象层次结构，JDBC类似于ODBC API，提供了跨平台能力。

然而，微软希望所有开发人员放弃数据访问对象(D AO), ODBC Direct,远程数据对象(RDO)和开放数据库连接( ODBC) API。虽然要设计一个全新一致的数据访问模型，最快也最方便的方法是利用ODBC作为访问所有数据源的中间层，此方法的缺点是ODBC依赖于6 QL去获取和更新数据。虽然SQL很适合那些带有SQL编译器或解释器的C/S和Jet数据库，但对于电子表格、Email消息和文件/目录系统之类的数据源，SQL基于集的命令方式就显得无能为力了。而面向Excel工作页面和文本文件的ODBC驱动程序必须有专用的SQL解释器。另外，SQL查询也不适合文件/目录系统之类的分层数据结构，而面向目录系统的查询能力对于Microsoft Active Directory Services(WinNT5.0主要新特性之一)来说又是非常重要的。为了适应广泛的数据源以及扩大COM的影响，微软的数据结构采用了全新的数据连接—OLE DB。

图5-1微软Universal Data Acces:结构，图中包含了典型的

OLEDB数据提供者、数据服务和数据使用者

上图显示了微软Universal Data Access结构中OLE DB数据提供者、数据使用者、数据服务之间的关系。这个结钩包含了OLE DB, ADO和远程数据服务(RDS，前身为Advanced Database Connector，通过HTTP传送一个未连接的无状态的ADOR.Recordset kj-象，从Web服务器IIS传送到服从Active的浏览器)以及非正式成员ODBC.RDS(主要用于基于浏览器的应用程序)。OLE DB规范定义了一组层次型数据对象间的接口，用C++编写的数据库前端应用程序可以和OLE DB接口直接相连，但需要函数指针和其它低层次操作，而高层次语言，如Visual Basic和Java，利用ActiveX数据对象(ADO)作为与OLE DB的COM接口的中间层。

ADO把OLE DB的四个对象(Data Source, Session, Command,Rowset)映射三个顶层Automation对象(Connection, Command,Recordset )。下图显示了OLE DB和ADO对象的关系，以及各自主要的函数和方法。三层模型的设计就是将在界面层中实现的数据访问方法，从复杂的网页和专用客户界面中转移到中间组件层，本系统中间层的数据访问方

法

就

是

基

于

OLE

和

ADO

对

象

的

。

图5-2 OLE DB对象与ADO对象、OLE DB函数和ADO方法之间的对比

在界面层中，向浏览器传送数据的方法有DHTML，它是IE4+的客户方特征，通过在客户机上运行大量的脚本代码，使每次希望改变某个页面元素的属,胜时，无需从服务器重载页面，同时，在D日TML页面请求之间，还能保持应用程序状态，即与传统HTML页不同，用户不必临时把客户状态存储在Web服务器上。当然，D日TML也是一种过渡技术，最终将被可扩展标识语言(XML)所取代，XML像日TML一样，是从标准化通用标识语言(SGML)演化而来，XML对象模型允许网页制作人员和数据库开发人员定义一些定制的标记，用来代表任意实体，如由查询返回的数据(例如结构化数据)。

以上是对Windows平台的数据访问方法的一个概述。在UNIX平台上数据访问仍是通过各数据库厂商提供的专用C Library访问，因本系统主要是在微软平台下开发，这里就不再讨论了。

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

图5-3 MTS 2. 0与主机和Unix事务处理器的连接，

以及服从OLE TX的RDBMS (SQL Server6.5+)

对中间层组件而言，运行环境主要是由MTS提供的一个代理服务器进程，它把TP和ORB的特征组合成一个单一的服务，在DCOM上依靠SQLServer 6.5+引入的分布式事务协调器(DTC)与UNIX和主机事务处理集团(X/Open DTP)的XA UNIX事务监视器进行互操作。COM事务综合程序在MTS和Microsoft SNA Server 4.0之间插入一层，把自动化对象方法映射到主机事务处理器请求或者消息序列，还把对象属性映射到IBM的客户信息控制系统(CICS)和信息管理系统(IMS)的LU6.2消息域。上图描述了MTS的基本元素，以及MTS怎样连接到主机的UNIXTP上，还描述了只是通过DTC进行OLE事务(OLE TX)的数据库。只有SQL Server 6.5是服从OLE TX的。MTS还提供了资源组合、安全性、

管理、客户发行的功能。

尽管MTS2.0是一个通用的对象请求代理(ORB)和一个事务管理工具(TM)，它的主要特征之一就是组合数据库连接的能力，可供单个工具包用户使用。MTS中间层组件主要分为面向事务(使用ObjectContext对象的Set Complete和SetAbort方法支持多重、分布式和嵌套的事务)、资源孤立(把ASP和其它Intranet或Internet组件与数据库连接)和决策支持(决策存储过程的支持)三种组件。

正确地设计MTS组件是获得MTS潜在优点的关键，以下是开发原则: .在所有的数据库操作中使用ADO 2+和本地OLE DB 2.0数据提供者； .在客户机上尽可能迟创建对象，并使用Set objName=Nothing尽快发行； .在可能的情况下，应该传送方法变元ByVal，而不是ByRef；

.应把多个方法变元作为变量数组传送，不要按单个变元值的常例表传送； .不要编写有状态组件，状态可放到数据库中实现；

.用MTS事务取代包含调用其它数据库的存储过程的分布式事务； .把组合数据库连接的所有类放到单个包中，连接组合发生在工具包级； .给所有组件增加ObjectControl，完成ObjectContext对象的创建和发行； .把只读的单向向前(游标)的Recordset作为方法变元或返回值传送； .使用INSERT, UPDATE和DELETE存储过程来修改表；

.加入Objectuontrol一anBePooled(为TRUE)，支持对象或线程组合； .利用MTS的说明和编程安全性，建立工具包级、组件级和方法级安全性； .在所有数据库访问和更新操作中使用存储过程；

除了上述通用规则，还应有必要的开发方法。“组件化应用程序”对面向对象软件的研究和开发来说，是一个重点。但是基础数据库设计和优化不足、服务器硬件资源不足、网络拥挤以及其它与现有前端无关的瓶颈，都会使面向对象的组件设计性能损失，特别是对那些返回行的过程来说更是如此因此相当少的MTS应用是从头产生的，大多数应用程序都包含现有的数据库和前端，然后把前端分解为类和界面，将类升级到MTS组件级。这种开发方法分四步:

第一步，把数据访问操作移向类，包括去处多余的客户代码、判断组件粒度、把数据访问代码改为类模块、指定方法变元、用方法调用取代存储过程调用、加入合适的错误处理过程、测试组件的执行等操作。

第二步，在测试和调试了项目内的类模块以后，就是把类作为ActiveX DLL编译，

并改动客户代码，以便使用CreateObject方法，MTS需要它来为进程内组件和COM建立例程，在本步骤中无需改动组件代码。

第三步，完成从传统的C/S应用程序到本地MTS工具包的转换，客户方代码仅需做很小的修改，以适应对象名称的变化，主要改动之处是往类模块加入适合MTS的代码，在编译了改动的类项目以后，可以把它安装为MTS本地拷贝的一个工具包，然后测试工具包的执行。

第四步，在测试了组件的本地执行后，把工具包移植到MTS产品服务器，以便从远程客户执行。

在远程组件服务器与本地服务器上的工具包性能大致相同，调度那些调用MTS的DCOM方法调用，与对本地MTS拷贝的COM方法调用的组合相比，开销要稍多一点，也比通过网络连接执行存储过程的开销要多一点。但是，目前不断提高工作频率的CPU、性价比优的内存、宽带网络都为改善组件应用程序的性能提供了有利条件。

5.3 Web接口和专用接口的实现

正如前面所论述的，由于将界面层的数据访问转入中间层，因此中间层组件需要提供界面层提交数据和查询数据的方法，其中包括:建立数据库连接，调用SQL语句(INSERT、UPDATE, DELETE, SELECT)对相关表的数据进行插入、更新、删除、查询，返回查询结果等。此外，还包括批操作的事务处理，如教学计划的提交、对教学计划的审核等，但它不同于数据库数据命令的事务处理(提交或回滚)，是对业务规则完成的成功与否的定义。

如下面所示界面层用户登录的例子，该方法运行在MTS中，通过建立数据库连接，并用获取的用户名和口令条件查询用户信息表(USER_ INFO)，如果返回的记录集的记录数为1则表明用户登录成功，为0则表明用户输入用户名和口令不正确。方法调用成功用GetObjectContext.SetUomplete实现，为0则不成功用Getubjectuontext.SetAbort实现。界面层可以从方法的返回值判断结果。

.MTS组件方法:

Public Function Verify_User(ByVal strUsername As String, ByVal strPassword As String) As Boolean

Dim cn As Connection Dim rsUserinfo As Recordset

‘建立数据库连接 Set cn = New Connection

cn.Open \"SERVER = 服务器名；UID = 用户名；PWD = 口令；DATABASE = 默认数据库名；DRIVER ={SQL SERVER}\"

‘查询数据库

Set rsUserinfo=New Recordset

rsUserinfo.Open \"Select USER_ MC,USER_ PASSWD,USER_ FLAG, USERes BZ From USER INFO\" &

\"Where USER_ MC=’ \"&strUsername&\" AND\"& \"USER_ PASSWD=’”&strPassword&\"p\"，_ cn, adOpenStatic, adLockReadOnly ‘判断记录集，为空则登录失败 If rsUserinfo.RecordCount = 0 Then

GetObjectContext.SetAbort Verify_User = False Else

GetObjectContext.SetComplete Verify_User = True ‘登录成功后的其它操作 „„ End If

Set rsUserinfo = Nothing cn. Close End Function

说明:该方法是类的其中一个方法，这个类是在服务器上用VB6. 0开发生成ActiveX DLL，并在MTS中建立软件包，导入该组件以及指定包和方法的安全级别。

.界面层调用:

.专用客户端((DCOM)

Private Sub cmmUserReg Click() Dim blReturn As Boolean

Dim MyVerify As Object ‘创建组件对象的引用

Set MyVerify = CreateOb ject (\"MTSTest. CMTSTest\服务器名\") If MyVerify Is Nothing Then

MsgBox \"Create object\"+\"MTSTest.CMTSTest\"+\" failed. \" Set MyVerify = Nothing Exit Sub End If

‘组件对象的方法调用

blKeturn = MyVerify. Verify_ User (txtUserName. Text, txtPassword. Text) If blKeturn = True Then

1buserinfo.Text =\"Login Success, welcome you! \" Else

1bUserinfo. Text =\"Login fail, try again! \" End If

Set MyVerify = Nothing End Sub

说明:专用客户界面的开发是在组件开发之后，并且运行的客户端需要安装由MTS服务器软件包发行的Package，以建立对组件的引用。

.Web客户端(HTTP)

<% strUsername = Trim (Request. Form\"用户名\")) strPassword = Trim (Request. Form\"口令\")) If strUsername = OR strPassword=\" \"Then Msg =‘请输入您的用户名及口令!” Else

‘创建组件对象的引用

Set MyVerify = Server. Cr eateOb ject (\"MTSTest. CMTSTest\") If MyVerify Is Nothing Then

Msg = \"Create object:MTSTest.CMTSTest failed! \" Else

‘组件对象的方法调用

blReturn = MyVerify. Verify_ser(strUserName, strPassword) If blReturn=True Then

Msg = \"Login Success, welcome you! \" Else Msg =\"Login fail, try again! \" End If End If

Set MyVerify = Nothing End If%>

User Login

请输入用户名和口令

说明:ASP页面的运行是在服务器上，这里Web服务器、MTS服务器和数据库服务器是在同一台机子上。从界面层的代码可以看出，数据访问和事务处理的代码已经移到中间层组件中，尤其是在Wel〕上对ASP页面调用的用户是没有权限对组件进行调用的，因而也不能直接对数据库进行访问，并且当调用组件的例程增多时，可以由MIL服务器合井在组件中建立的数据库连接，来避免遇到在页面中打开并且保持数据库连按过多而引起数据库并行访问的许可证限制问题。

第六章排课算法初探

在前面一章中，已经谈到生成排课数据的整个过程，进入排课管理阶段后，其目标是由指定学期的排课数据(数据源)生成该学期的所有年级的班级课表，即授课的时间、

地点和任课教师。本节是在假定数据源所包含的教室数据，授课班级数据及对其所开设课程的任课教师、课时分布数据(课程大类—优先级、周学时、起始周和结束周)已经完全提供并且不再发生变化的前提下，寻求课表的最佳时空解的算法。当然，在教学任务的下达中，开设课程的教研室己经对授课班级的任课教师进行了指定，但是，任课教师在某一时间只能在一个教室授课，也只能对一个授课班级授课；一个班级(不可分割的班级，即自然班)在某一时间只能在一个教室听课；这些会引起排课的教师冲突和教室冲突，而且关于授课班级的合班策略也会对排课的结果造成影响。下面就从排课原则、问题定义到算法设计，结合目前的研究成果，初步探讨课表生成算法的相关问题。

6. 1排课规则

为了便于讨论，我们把课程的每个授课班级称为课元，把课元在一周内安排的每次上课时间称为时间片，把课元的时间片及对应的上课地点合称为时空片。课表以课元为单位进行编排，每个时间片为一次讲课(允许是单l双周课)。排课的过程实质上就是对课元分配时空片的过程。在排课过程中，必须严格遵守以下三条基本原则:

(1)每位教师在一个时间片内最多只能有一门课； (2)每自然班在一个时间片内最多只能有一门必修课；

(3)每个时空片最多只能分配给一个课元，并且其教室的类型和容量能满足上课的需求。也就是说，每一个教室在一个时间片内最多只能安排一个课元；

(4)此外，每个课元的时间片还必须与教学计划中课程的学时数一致。为了使课表更优化、合理，排课时还要考虑以下五个因素: (1)尽可能使每门课在一周内的_}二课时问分布合理； (2)尽可能使学生在连续的两讲课之间更换教室所用时间少； (3)尽可能把同一课元的不同讲次安排在同一个教室； (4)尽可能使学生每天的必修课负荷趋于平衡；

(5)尽可能满足每个课元教学的客观需求排课算法，即约束条件，如: 任课教师对上课时间的要求、课程优先级、特殊时间指定、是否单节排课、是否允许教师连续排等。

6. 2算法设计

为便于描述，令Ccou表示排课课元的集合，令Ttea, Ccla, Rroo和Ssli分别表示参与排课的教师、班级、教室和时间片的集合。此外，用Cty={0,1，2,„„}表示课

元的课程类别集合，其中类型0的课元为必修课或必选课，对同一自然班，这类课的排课时间不允许与其它课冲突，其它类型的选修课按允许时间冲突的课元子集归类。

(1)课元的相关关系计算:

(2)假定用Ft:Ccou--Ttea描述课元任课教师集合，用Fc:Ccou一Ccla描述课元的自然班集合，则课元的相关关系定义如下: .定义课元关于教师的相关关系Rt : Ccou--Ccou为

.定义课元关于自然班的相关关系Rc : Ccou--Ccou为

式(1)和式((2)中:u∈Ccou , Rt(u)的物理意义表示课元u的任课教师所担任的所有课程；Rc(u)的物理意义表示课元u的上课班所上的所有课程。

由式(1)和式(2)不难得出，计算Rt(u)和Rc(u)的时间复杂性为:

O(N)(N=|Ccou|)，空间复杂性为M(1)，计算Rt和Rc全部值的时间复杂性为0 (N^)，空间复杂性为M(N). (3) 候选时空片计算:

(4) 假定用Fct:Ccou--Cty描述课元的课程类型集合，用Fcr:Ccou- Rty描述课元可选的教室类型集合，用Fcs : Ccou--Csi描述课元所需的最小教室容量，用Frt:Rro--Rty描述教室的类型，用Frs:Rroo--Rsi描述教室容量，用Fs : Ccou-Ssli表示课元己分配到的时间片集合，用Fsr Ccou--Ssli X Rro。表示课元已分配到的时空片的集合。由排课的基本原则(1)和(2)可知，课元u E Ccou可选用的时间片As(u)取决于它的相关课元己分配到的时间片及课程类型，即：

由排课的基本原则(3)可知，课元u E CCOu可选用的教室Ar(u)取决于该课元所要求的教室类型和容量，即:

所以，

课元u E CCOu可选用的时空片(候选时空片)Asr(u)为:

由式

(3)推出，计算As(u)的时间复杂性为O(N)(N=Ccou)，空间复杂性为M(1)。由式(4)推出，计算Ar(u)的时间复杂性为O(M)(M=Rroo)，空间复杂性为M(M)。所以，式(5)计算Asr(u)的时间复杂性为O(N2 X M)，空间复杂性为M(M)。在排课过程中，将对所有课元逐个计算其候选时空片并从中进行选取。所以，整个排课过程中计算课元候选时空片的时间复杂性为O(N3 x M)，空间复杂性为M(M)。

(3)其它辅助算法:

排课的其它辅助算法都是在候选时空片算法的基础上进行的，这些算法可以选用人工辅助处理或计算机自动处理的方法。人工辅助处理方法不需要建立数学模型，而是通过有经验的教务员从候选时空片中直接选取时空片来综合处理排课的各种模糊性原则；自动处理方法则需要把处理算法编成程序进行操作。下面给出其中的几个主要辅助算法:

① 排课优先级。根据教务员的排课经验，排课应当先排公共必修课，然后再按学

时数由大到小排必修课，最后排选修课。按照这一原则确定课元的排课优先级，既能使排课过程顺利进行，又能使重点课排在较好的时间片。

②时间分配模式。一个课元如果在一周内的上课时间多于一次，就应当合理地分配时间片，使上课的时间间隔恰当。为此，可以针对不同的周学时数制定相应的上课时间模式，在排课时优先选用这些模式。

③教室之间的距离。教室之间的距离，按楼间距离与教室所在楼层之和计算。如果教学区比较集中，不同教学楼之间的距离可按一常数计算。在连续两讲课之间需更换教室时可参考教室距离选取教室。

(4)排课算法的实现。

课元u关于教师的相关课元Rt(u)，是所有与课元u有相同任课教师的课元集合。因此，在课元数据库中，按教师姓名字段进行选择运算便可得出。课元u关于自然班的相关课元Rc(u)，是所有与课元u有相同的授课对象的课元集合。因此，对课元数据库按其授课对象与自身连接运算，并投影出相应的字段而得出。课元u的可选用时间片As(u)，是在时间片Ssli中去掉那些相关课元己占用的时间片所剩余的时间片的集合。课元u可选用的教室Ar(u)，是在教室数据库中按课元u所要求的教室类别和容量进行选择的结果。由As(u)与Ar(u)可得到u的候选时空片Asr(u)。

6.3其他问题的考虑

为了保证课表编排顺利实施，找到问题的一组解，仍有许多工作要做:

首先，需要收集、整理大量的数据和有关事实例。这些信息的有效性直接关系到编排算法的完备率。

其次，考虑模型在处理共性问题与特殊要求在推理、算法上的完备性。因此大学课表编排模型必须体现课程在周学时安排上的任意性；理论课、实验课在教室、时间分配上的合理性；处理合班上课，提高教室利用率的总体协调性。

最后，还必须满足一些特殊要求:上课时间的模式要求、课程和参与者对教室的约束要求以及某位教师同时授几门课的要求等。

在实际课表编排中，我们也会遇到几门相关的课程相互矛盾的制约，可以采取先排课程多的班级课表，再在同一班级中先排周学时多的课程，来最大限度地减少死锁现象的发生。同时，还应有其他措施，如:采用前链策略—根据课程的模式要求，取某条规则，然后按该规则的某时间片，进行循环推理。每次推理都要将分配的时间及教室与己记录的内容进行比较，直到一条规则被满足时，它的结论就存入该库。又如:在规则与己记录的内容比较时，记忆系统便自动跟踪。若规则遍历完，仍存在时间冲突或教室冲突且无法进行调整时，即出现死锁现象。此时应首先查找记忆库，提取从第一次出现的失效时间片开始，对参与者可用空时间片及教室进行推理。如此下去，直至找到一个有效空时间片，从而得到一个打破规则的时间片模式，完成该课程的编排。当然不可否认，确实会出现无法找到相应的时间候选片，这时就必须重新审核约束条件和授课班级的合班情况，在调整之后，重新进行推理。

以上提出的算法，是根据解决NP (nondeterministic polynomial-bounded)类问题的通用方法，即分为确定问题的所有“候选解”和对每个候选解确定是否是问题的真正解两步。对于给定的输入，可以一次产生和检查一个“候选解”，也可以同时产生和检查多个“候选解”，前者时间复杂度大，可实现，后者有利于降低时间复杂度，但实现上较困难。总之，尽管会因某些技巧而减少工作量，但还是不足以构造出多项式界算法，这里作者仅提出设计的思路，根据不同的实际情况，仍要具体情况具体分析。

第七章课题展望

近年来，在“科技兴国”战略的指导下，我国的教育事业得到了蓬勃的发展，各高

校都在提高办学质量上狠下功夫，尤其是改善教务管理的硬件和软件环境方面。校园网络的不断完善为利用网络进行教务管理已成为提高教学质量的有效手段。

然而，各高校因学科设置和历史原因都有着自己的教务管理模式，没有统一的标准，而且应用于教务管理的计算机系统软件各种各样，实用效果也参差不齐。因此，随着教学改革的深入以及教学管理的理论方法和计算机技术的迅速发展，教务管理信息系统的开发日显重要，作者从本校教务管理实际应用的角度，设计系统及对网络数据库建模，后续还有大量细致的开发任务需要努力去完成，由于加上作者水平有限，时间仓促，设计中存在着许多不足之处，有待于在实践中不断完善，敬请各位老师、专家、读者批评指正。

致谢

首先感谢我的毕业设计辅导老师。自开题报告开始到论文的完成都得到了她们的关心、帮助和监督。为我制定了很好的计划，使我每一阶段的工作都能得以顺利的完成。特别是在系统实现阶段，我遇到了难题问题，设计出来的东西与需求分析时的不一致，但是却找不到解决办法，思路完全混乱，几乎想放弃了。幸好得到陈老师的指点，让我找到了设计的重点，也使我的思路比以前清晰了许多，设计起来也就更加有自信了。感谢她从各方面给予大力支持，她那严肃认真的态度和一丝不苟的敬业精神，给了我极大的启发和帮助，将使我终身受益，在此对她表示最诚挚的谢意。

并向所有支持我、关心我和帮助我的家人、老师、同学和朋友表示衷心的感谢。

参考文献：

[1]潘蕾，《网上教务管理系统的设计与实践》，实验室研究与探索，2000.2. [2]国家教育部长春光机学院，《教务综合管理系统》，1990

[3]李明，《一个基于智能化搜索的排课表算法及其Client/Server实现》，现代计算机，总第59期，1997.6.

[4]美]Jennings R., ((Visual Basic 6数据库开发人员指南》[M]，前导工作室译，机械工业出版社，1990

[5][美]Daniel J. Worden，车敦仁等译，((S丫BASE开发者指南》，清华大学出版社，1995 [6]张海潘，《软件工程导论》(修订版)，清华大学出版社，1992 [7]汪成为等，面向对象分析、设计及应用，国防工业出版社，1992

[8]萨师宣，《数据库系统概论》(第二版)，高等教育出版社，1991 [9]吴开军，《选课系统的设计与实现》，电脑开发与应用，1996第2期。 [10]林尧瑞，张钱，石纯一，《专家系统原理与实践》，清华大学出版社，1998

[11]洪力奋，《基于人工智能原理的大学课表编排模型》，第22卷第4期，合肥工业大学学报(自然科学版1999.8) 附录

[12]方纪旋，((Client/Server模式下选课系统的开发及若干技术问题》，计算机工程与应用，1997.9

[13]魏平，熊伟清，《计算机辅助课表编排技术的研究》，甘肃工业大学学报， 1997.12 [14]王行甫，《课程管理的计算机科学化》，教育与现代化，1999.2. [15]陈月英，庄卫华，胡晓军，《基于网络环境选课系统开发中的冲突问题及研究》，南京河海大学学报，1998.7.

[16]袁莉，徐宏宇，《基于Web数据库的信息查询系统的设计与实现》，四川联合大学学报，1998.5

附录

use master go

if exists (select * from dbo.sysdatabases where name = '教务管理系统') drop database 教务管理系统 GO

create database 教务管理系统 go

use 教务管理系统 go

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[教师表]') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table [dbo].[教师表] GO

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[分工表]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)

drop table [dbo].[分工表] GO

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[学籍表]') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table [dbo].[学籍表] GO

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[成绩表]') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table [dbo].[成绩表] GO

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[考核表]') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table [dbo].[考核表] GO

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[日志表]') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table [dbo].[日志表] GO

CREATE TABLE [dbo].[教师表] (

[姓名] [nvarchar] (8) not null, [性别] [nvarchar] (2) not null, [出生年月] [nvarchar] (7), [第一学历] [nvarchar] (6), [一学历时间] [nvarchar] (7), [最终学历] [nvarchar] (6), [终学历时间][nvarchar] (7), [参加工作时间] [nvarchar] (8), [职务][nvarchar](8), [职称][nvarchar](8),

[联系电话][nvarchar](7), [联系手机][nvarchar](11), [家庭住址][nvarchar](30), [婚否][nvarchar](2), [备注][nvarchar](50), ) ON [PRIMARY] GO

CREATE TABLE [dbo].[分工表]

(

[班级] [nvarchar](3) NOT NULL,

[班主任] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS NOT NULL , [语文] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS NOT NULL , [数学] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS NOT NULL , [英语] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS NOT NULL , [物理] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS , [化学] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS , [政治] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS , [历史] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS , [地理] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS , [生物] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS ) ON [PRIMARY] GO

CREATE TABLE [dbo].[学籍表] (

[初考证号] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS NULL , [考试号] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS not NULL , [班级] [nvarchar] (3) COLLATE Chinese_PRC_CI_AS not NULL , [学号] [numeric](2, 0) not NULL ,

[姓名] [nvarchar] (6) COLLATE Chinese_PRC_CI_AS not NULL , [性别] [nvarchar] (2) COLLATE Chinese_PRC_CI_AS not NULL , [出生年月] [nvarchar] (7) COLLATE Chinese_PRC_CI_AS NULL , [家长姓名] [nvarchar] (6) COLLATE Chinese_PRC_CI_AS NULL , [联系电话] [nvarchar] (13) COLLATE Chinese_PRC_CI_AS NULL , [家庭住址] [nvarchar] (50) COLLATE Chinese_PRC_CI_AS NULL , [计外] [nvarchar] (2) COLLATE Chinese_PRC_CI_AS not NULL , [备注] [nvarchar] (50) COLLATE Chinese_PRC_CI_AS NULL , [照片] [image] NULL ) ON [PRIMARY] GO

CREATE TABLE [dbo].[成绩表] (

[考试号] [nvarchar] (8) COLLATE Chinese_PRC_CI_AS not NULL , [语文] [int] NULL , [数学] [int] NULL , [英语] [int] NULL , [物理] [int] NULL , [化学] [int] NULL , [政治] [int] NULL , [历史] [int] NULL , [地理] [int] NULL , [生物] [int] NULL ,

[总分] [int] not NULL ,

[考试性质] [nvarchar] (50) COLLATE Chinese_PRC_CI_AS not NULL ) ON [PRIMARY] GO

CREATE TABLE [dbo].[日志表] (

[时间] [smalldatetime] not NULL ,

[错误窗口] [nvarchar] (15) COLLATE Chinese_PRC_CI_AS not NULL , [错误代号] [nvarchar] (9) COLLATE Chinese_PRC_CI_AS not NULL , [错误源] [nvarchar] (50) COLLATE Chinese_PRC_CI_AS not NULL , [错误提示] [nvarchar] (150) COLLATE Chinese_PRC_CI_AS not NULL ) ON [PRIMARY] GO

CREATE TABLE [dbo].[考核表] ( [班级] [int] not NULL ,

[学科] [nvarchar] (4) COLLATE Chinese_PRC_CI_AS not NULL , [在籍数] [int] not NULL , [参考数] [int] not NULL ,

[计外] [nvarchar] (2) COLLATE Chinese_PRC_CI_AS not NULL ,

[考试性质] [nvarchar] (20) COLLATE Chinese_PRC_CI_AS not NULL , [卷面总分] [int] not NULL , [总分] [int] not NULL ,

[均分] [nvarchar] (7) COLLATE Chinese_PRC_CI_AS not NULL , [及格数] [int] not NULL ,

[及格率] [nvarchar] (7) COLLATE Chinese_PRC_CI_AS not NULL , [优秀数] [int] not NULL ,

[优秀率] [nvarchar] (7) COLLATE Chinese_PRC_CI_AS not NULL , [442] [nvarchar] (7) COLLATE Chinese_PRC_CI_AS not NULL ) ON [PRIMARY] GO