数据库应用系统设计实例

第八章数据库应用系统设计实例前面章节主要介绍数据库系统的有关理论和方法，开发应用系统是多方面知识和技能的综合运用，本章将以一个高校教学管理系统的设计过程，来说明数据库系统设计的有关理论与实际开发过程的对应关系，使读者更深入地理解理论如何指导实践，从而提高灵活、综合运用知识的系统开发能力。

本章偏重于数据库应用系统的设计，没有涉及应用程序的设计。对此，读者可参考有关开发工具和软件工程方面的相关资料。

本章学习目的和要求：

系统总体需求描述与设计；

利用DFD及DD描述系统需求；

利用ERM设计系统概念模型；

ERM向关系模型转换；

表结构设计；

数据库、表、视图、索引等的创建。

8．1系统总体需求简介

高校教学管理，在不同的高校有其自身的特殊性，业务关系复杂程度各有不同。本章的主要目的，是为了说明应用系统开发过程。由于篇幅有限，将对实际的教学管理系统进行简化，如教师综合业绩的考评和考核、学生综合能力的评价等，都没有考虑。8．1．1用户总体业务结构

高校教学管理业务，包括4个主要部分：学生的学籍及成绩管理、制定教学计划、学生选课管理以及执行教学调度安排。各业务包括的主要内容为：

①学籍及成绩管理包括：各院系的教务员完成学生学籍注册、毕业、学籍异动处理，各授课教师完成所讲授课程成绩的录人，然后由教务员进行学生成绩的审核认可。

②制定教学计划包括：由教务部门完成学生指导性教学计划、培养方案的制定，开设课程的注册以及调整。

③学生选课管理包括：学生根据开设课程和培养计划选择本学期所修课程，教务员对学生所选课程确认处理。

④执行教学调度安排包括：教务员根据本学期所开课程、教师上课情况以及学生选课情况完成排课、调课、考试安排、教室管理。

8．1．2总体安全要求

系统安全的主要目标，是保护系统资源免受毁坏、替换、盗窃和丢失。系统资源包括：设备、存储介质、软件、数据等。具体来说，应达到以下安全要求：

(1)保密性机密或敏感数据在存储、处理、传输过程中要保密，并确保用户在授权后才能访问。

(2)完整性保证系统中的信息处于一种完整和未受损害的状态，防止因非授权访问、部件故障或其他错误而引起的信息篡改、破坏或丢失。学校的教学管理系统的信息，对不同的用户应有不同的访问权限，每个学生只能选修培养计划中的课程，学生只能查询自己的成绩，成绩只能由讲授该门课程的老师录入，经教务人员核实后则不能修改。

(3)可靠性保障系统在复杂的网络环境下提供持续、可靠的服务。

8．2系统总体设计

系统总体设计的主要任务，是从用户的总体需求出发，以现有技术条件为基础，以用户可能接受的投资为基本前提，对系统的整体框架作较为宏观的描述。

其主要内容包括：系统的硬件平台、网络通信设备、网络拓扑结构、软件开发平台以及数据库系统的设计等。应用系统的构建是一个较为复杂的系统工程，是计算机知识的综合运用。这里主要介绍系统的数据库设计，为了展现应用系统设计时所考虑内容的完整性，对其他内容也将简要介绍，相关内容请参考有关参考资料。

8．2．1系统设计考虑的主要内容

应用信息系统设计需要考虑的主要内容包括：用户数量和处理的信息量的多少，它决定系统采用的结构，数据库管理系统和数据库服务器的选择；用户在地理上的分布，决定网络的拓扑结构以及通信设备的选择；安全性方面的要求，决定采用哪些安全措施以及应用软件和数据库表的结构；与现有系统的兼容性，原有系统使用的开发工具和数据库管理系统，将影响到新系统采用的开发工具和数据库系统的选择。

8．2．2系统的体系结构

现有管理信息系统采用的体系结构，可以分为两种：C／S(Client／Server)和B／S(Browser／Server)。

基于C／S二层结构的数据库应用中，应用系统分成客户端和服务器两部分，因此称

为二层结构。其工作过程为：客户端的机器执行应用程序，连接到后端的数据库服务器中，向服务器请求存取数据信息，而数据访问和事务处理由服务端完成。

这种方案实现了功能的分布，即部分处理任务交给了客户端，而数据集中在服务器端。这样可以保证数据的相对安全，并可以保证数据的同步。但是，因为企业的应用逻辑都编写在客户端的应用程序中，造成客户端非常臃肿，且当应用系统需求改变时，所有在客户端的应用程序都必须改变，使维护成本太高；另一方面，应用程序向处理服务器请求数据，并传到客户端进行处理，这需要占用大量的网络通信带宽，这样将加重网络通信负荷。

为了解决c／S结构的缺陷，基于B／S的多层数据库系统结构应运而生。它是基于Internet／Intranet的体系结构模型，由客户端、web服务器、应用服务器和数据库服务器

组成。各组成部分功能如下：

①在客户端采用浏览器，提供用户接口，主要功能是为操作人员提供交互界面，数据输入、输出处理接口；客户端不处理企业核心逻辑，最多只拥有部分不涉及企业核心的、机密的应用逻辑。这样客户端的处理负载较小，只要能运行浏览器的客户端微机即可，因而称为“瘦”客户。

②web服务器接收并处理客户端浏览器的网页请求，需要时可调用应用服务器的应

用程序，接收处理结果，并回送至客户端。

③应用服务器处理企业的业务逻辑，它是应用的主体，其功能是接受输入，处理后返回结果。

④数据库服务器用于存储企业的业务数据，负责管理对数据的读写和维护，以及数

据库的数据访问权限。

此种结构，由客户端通过浏览器向Web服务器发出请求；涉及业务逻辑时，则由web 服务器送至应用服务器，再由应用服务器向数据库服务器发出数据访问请求，接收到数据库服务器的应答后，返回给web服务器；由web服务器以页面形式回送客户端。这样，客户端不直接和数据库服务器发生关系，保证了数据的安全性。

在更复杂的多层体系结构中，“瘦”客户与远程数据库服务器之间，可以加入更多的中间应用服务器，如加入一个中间安全服务器或中间转换服务器，用于对不同平台数据进行处理。分布式多层结构，把整个应用系统的执行分成多个不同部分，并且执行在不同的机器中。其中，应用程序服务器作为中间层集中实现企业逻辑，协调多层之间的请求，并掌握数据集定义的全部细节，与远程数据库服务器进行通信。这样，客户端应用程序就重点放在显示数据和与用户交互的表示逻辑上，客户端应用程序甚至都不需要知道数据的物理位置。

总体说来，多层结构具有以下几个主要优点：

①在一个共享的中间层封装了企业逻辑，不同客户端应用程序可以共享同一个中间层，而不必由每个客户端应用程序单独实现企业逻辑。

②客户端应用程序可以做得很“瘦”，因为很多复杂的工作由应用服务器代劳，客户

端应用程序只需关注用户界面本身，“瘦”客户端应用程序更易发布、安装、配置和维护。

③实现分布式数据处理，均衡系统负载，并提高系统的可靠性。把一个应用程序分布在几个机器上运行，可以提高应用程序的性能。通过冗余配置，还可以保证不会因为局部故障导致整个应用程序崩溃。

④有利于安全。将一些敏感数据功能部分封装在中间层，并授予不同访问权限，可以保证对数据的访问限制。

⑤降低网络通信负载。客户端将系统的处理参数和请求信息，通过WeB服务器传人应用服务器，由应用服务器和数据库服务器进行处理，然后将处理结果返回到客户端，在一定程度上降低了网络的通信负载。至于应用服务器与数据库服务器之间的数据交换所带来的负载，可以通过数据库的存储过程来得到平衡。

在教学管理信息系统中，采用基于B／s的多层体系结构，对于大批量的数据处理具有较大优势；而B／S结构实现了客户端的零维护，使用起来更方便灵活，很适合数据、信息在Internet上的发布和查询，实现信息访问不受地域的限制。

8．2．3系统软件开发平台

1．数据库管理系统选择

SQL Server2000是微软开发的大型关系型数据库系统，是一个可伸缩的、高性能的数据库管理系统，专为分布式客户机／服务器环境而设计，具有丰富的开发环境和高性能数据管理能力。SQI—SerVer2000沿袭了SOL Server7．0的易操作性、易应用性，有数据库基本知识的初学者，都可以轻松上手。从系统的安装、数据库建立直到数据库维护都可以通过图形界面和向导程序完成。SQL Server2000是企业进行大量数据存储、检索、更新的重要系统，它担负着企业内部重要数据的处理，这种操作对数据库的稳定性、效率要求都很高。随着SQI—Server2000不断的发展完善，逐渐在企业的数据处理应用中取得r非常重要的位置。SQL Server2000同其他企业级数据库一样，具有数据库管理图形工具、数据库引擎、完备的帮助系统、数据导入导出、服务器网络使用工具、客户端使用工具等，还包括在IIS 中配置SQL XML的支持。相比SQL Server7．0，SQL Server2000增加了很多新特性：

①XML支持。SQL SerVer2000最吸引人的新特性应该是对XML的支持。随着电子商务的发展，XML在电子商务方面的应用，越来越得到了人们的重视。因此，数据库对XML 的支持也就成了衡量一个数据库好坏的标准。

②SQL Server2000可以从关系型数据库返回XML格式的数据，另外也支持XML格式数据在关系型数据库中的更新和删除操作。另外，通过和IIS的结合，可以直接通过URL 对数据库系统中的数据进行增、删、改操作。数据库系统的存储过程中，也同样支持对XML 数据的处理。可以使用HTTP、ADO、OLE DB处理数据库的XML功能。这些新增加的特

性，可以满足电子商务或其他系统对XMI数据处理的需求。

③图形管理功能增强。SQL Server2000对日志传送、SQL事件探查器、SQL查询分析器、复制数据库向导的图形功能进行了增强。这些增强的图形功能，使得对SQL语句的调试、SQL事件的分析，都变得更加容易，也更加方便。

④数据转换服务(Data Transfer Service，DTS)I曾强。如新的自定义任务、增强的日志设备、将DTS包保存到Visual Basic：文件中等。这些新增加的功能，使用户可以非常方便地操作数据库的数据包，也方便了VB程序员的开发工作。

从上述特征可以看出，SQL Server2000数据库系统适合于作为企业进行大量数据管理。因此，选择SQL Server2000作为高校教学管理系统的RDBMS。

2．开发工具选择及简介

1)企业业务逻辑组件开发工具

COM(Component Object Mc)del)组件是遵循COM规范编写、以Win32动态链接库(DLL)或可执行文件(EXE)形式发布的可执行二进制代码，能够满足对组件架构的所有需求。遵循COM的规范标准，组件与应用、组件与组件之间可以互操作，这为可伸缩的应用系统的建立提供了极其便利的条件。

COM是一种技术标准，其商业品牌则称为ActiveX。c0M组件并不是专为一种windows 平台而设计的，同一COM组件可以在windows95、windows98、Workstation及NT上使用。组件既可以被嵌入动态web页面，又可以在LAN或桌面环境的VB和VC等应用中使用。COM组件之间是彼此独立的。当应用需求发生变更时，可以更换中间层的个别COM组件，但这并不会影响其他组件的继续使用。COM组件具有若干对外接口，根据不同的应用需求，可以有选择地使用。COM组件可以在不同的应用环境中重复使用。COM组件及其较高的可复用性，展示了一种崭新的软件设计思路，以组件对象为中心的设计方法，使得面向对象技术从工具语言层次跃迁到系统的应用层。

Visual Basic是windows环境下面向对象的可视化程序设计语言。它既可以用来开发windows下的各种应用软件，也可以用来开发多媒体应用程序。Visual Basic6．O具有开发COM业务组件的功能。

Visual Basic可以访问多种DBMS的数据库，如Paradox、dBASE、Access等，也可以访问远程数据库服务器上的数据库，如MS SQL Server、Oracle、Sybase、Informix等，或者任何经过ODBC可以访问的RL)BMS中的数据库。

Visual Basic和数据库连接的方式多种多样，既可以通过0DBc应用程序编程接口(API)来开发数据库应用程序，也可以通过数据库存取对象(Data Access Object，DAO)、远程数据库对象(Remote Data Object，RDO)以及OIE DB和ADO(ActiveX DataObject)来开发数据库应用程序。采用Visual Basic：开发的数据库应用程序的体系结构如图8一l所示。

DA0是visual Basic默认的数据库访问方式，它使用自己的内部Jet引擎访问数据库，主要是为Visual Basic应用程序访问本地Access数据库提供数据，但也可以用来访问许多其他数据库，例如dBASE、Paradox，甚至是Oracle和SQI．Server的ODBC数据库。

RDO技术是对DAO技术的进一步完善和发展，它通过ODBC访问数据库，结合了DAO 提供的易编程性和0DBC API提供的高性能，提高了数据库访问的效率，尤其是在访问ODBC 兼容的数据库(如SQL Server)时的性能。

图8-1Visual Basic数据库应用程序体系结构

ADO是专门为使用OLE DB而设计的。OLE DB是一种全新的连接数据存储的方法，它提供了比ODBC更多的灵活性和易用性，而且OLE DB的内部设计使得它能够像存取标准SQL类型的数据那样，容易地访问非SQL的数据存储。微软公司已经将OLEDB定位为0DBC的继承者。

由于Visual Basic提供了强大的数据库访问编程功能，同时也提供了方便的组件开发工具，因此，选用Visual Basic作为教务管理系统的业务组件的开发工具。

2)ASP开发用户界面

Microsoft的动态服务器网页技术(Active Servet Pages，ASP)，是用来创建windows服务器平台上的动态Web网页，构建整个网站的Web应用页面的。

ASP是一种服务器端命令执行环境，ASP程序在服务器端工作，并且通过服务器端的编译，动态地送出HTML文件给客户端。当客户端的浏览器向服务器请求一个．asP文件时，服务器会将这个asP文件从头扫描一遍，并利用核心程序ASP．dll加以编译执行，最后送出一个标准的HTML格式文件给客户端。由于送给客户端的是标准的HTML文件，因此可以克服浏览器之间不兼容的问题。

ASP和Microsoft的web服务器软件

IIS(Internet Information Server。)相结合，可以轻

松地建立和执行动态、交互式Web服务器应用程

序。IIS中提供了一个Internet服务器应用编程接

口(Internet Server Application Programming

Interface，ISAPI)。它能够提供比原来的CGI、Perl

引擎等技术更为广泛和快速的对Web服务器和数

据库服务器的访问。ASP使得访问数据库中的数

据，创建动态网页变得更加容易。图8～2为ASP

和IIS动态页面创建技术的结构图。

8．2．4系统的总体功能模块图8-2ASP动态页面创建技术桔构在设计数据库应用程序之前，必须对系统的功能有个清楚的了解，对程序的各功能模块给出合理的划分。划分的主要依据，是用户的总体需求和所完成的业务功能。这种用户需求，主要是第一阶段对用户进行初步的调查而得到的用户需求信息和业务划分，有关调查方法，请读者参考有关软件工程方面的资料。

这里的功能划分，是一个比较初步的划分。随着详细需求调查的进行，功能模块的划分也将随用户需求的进一步明确而进行合理的调整。

根据前面介绍的高校教学管理业务的4个主要部分，可以将系统应用程序划分为对应的4个主要子系统模块。包括：学籍及成绩管理子系统、制定教学计划子系统、学生选课管理子系统以及执行教学调度子系统。根据各业务子系统所包括业务内容，还可将各子系统继续划分为更小的功能模块。划分的准则要遵循模块内的高内聚性和模块问的低耦合性。如图8—3所示为高校教学管理系统功能模块结构图。

图8-3高校教学管理系统功能模块结构图

8．3系统需求描述

数据流图(DFD)和数据字典(DD)是描述用户需求的重要工具。数据流图描述了数据的来源和去向，以及所经过的处理；而数据字典是对数据流图中的数据流、数据存储和处理的进一步描述。不同的应用环境，对数据描述的细致程度也有所不同，要根据实际情况而定。下面将用这两种工具来描述用户需求，以说明它们在实际中的应用方法。

8．3．1系统全局数据流图

系统的全局数据流图，也称第一层或顶层数据流图，主要是从整体上描述系统的数据流，反映系统数据的整体流向，给设计者、开发者和用户一个总体描述。

经过对教学管理的业务调查、数据的收集处理和信息流程分析，明确了该系统的主要功能，分别为：制定学校各专业各年级的教学计划以及课程的设置；学生根据学校对自己所学专业的培养计划以及自己的兴趣，选择自己本学期所要学习的课程；学校的教务部门对新入学的学籍进行学籍注册，对毕业生办理学籍档案的归档管理，任课教师在期末时登记学生的考试成绩；学校教务部门根据教学计划进行课程安排、期末考试时间地点的安排等，如图8—4所示。

图8-4教学管理系统的全局数据流图

8．3．2系统局部数据流图

全局数据流图，从整体上描述了系统的数据流向和加工处理过程。但是，对于一个较为复杂的系统来讲，要较清楚地描述系统数据的流向和加工处理的每个细节，仅用全局数据流图难以完成。因此，需要在全局数据流图的基础上，对全局数据流图中的某些局部进行单独放大，进一步细化，细化可以采用多层的数据流图来描述。在8．4．1小节所讲述的系统的主要功能中，教学调度处理的业务相对比较简单。下面将只对制定教学计划、学籍及成绩管理和选课等处理过程作进一步细化。

制定教学计划处理，主要分为4个子处理过程：教务员根据已有的课程信息，增补新开设的课程信息；修改已调整的课程信息；查看本学期的教学计划；制定新学期的教学计划。任课老师可以查询自己主讲课程的教学计划。其处理过程如图8—5所示。

图8-5制定教学计划的细化数据流图

学籍及成绩管理相对比较复杂，教务员需要完成新学员的学籍注册，毕业生的学籍和成绩的归档管理，任课教师录入学生的期末考试成绩后，需教务员审核认可处理，经确认的学生成绩则不允许修改。其处理过程如图8—6所示。

图8-6学籍和成绩管理的细化数据流图

选课处理中，学生根据学校对本专业制定的教学计划，录入本学期所选课程，教务员对学生所选课程进行审核，经审核的选课则为本学期学生选课。其处理过程如图8—7所示。

图8-7学生选课的细化数据流图

8．3．3系统数据字典

前面的数据流图，描述了教学管理系统的主要数据流向和处理过程，表达了数据和处理的关系。数据字典是系统的数据和处理详细描述的集合。为了节约篇幅，此处只给出如下部分数据字典。

数据流名：(学生)查询请求

来源：需要选课的学生

流向：加工3．1

组成：学生专业+班级

说明：应注意与教务员的查询请求相区别

数据流名：教学计划信息

来源：文件2中的教学计划信息

流向：加工3．1

组成：学生专业+班级+课程名称+开课时间+任课教师

加工处理：查询教学计划

编号：3．1

输入：(学生)选课请求+教学计划信息

输出：(该学生)所学专业的教学计划

加工逻辑：满足查询请求条件

数据文件：教学计划信息

文件组成：学生专业+年级+课程名称+开课时间+任课教师

组织：按专业和年级降序排列

加工处理：选课信息录入

编号：3．2

输入：(学生)选课请求+所学专业教学计划

输出：选课信息

加工逻辑：根据所学专业教学计划选择课程

数据流名：选课信息

来源：加工3．2

流向：学生选课信息存储文件

组成：学号+课程名称+选课时间+修课班号

数据文件：学生选课信息

文件组成：学号+选课时间+{课程名称+修课班号}

组织：按学号升序排列

数据项：学号

数据类型：字符型

数据长度：8位

数据构成：入学年号+顺序号

数据项：选课时间

数据类型：日期型

数据长度：10位

数据构成：年+月+日

数据项：课程名称

数据类型：字符型

数据长度：20位

数据项：修课班号

数据类型：字符型

数据长度：10位

8．4系统概念模型描述

数据流图和数据字典共同完成对用户需求的描述，它是系统分析人员通过多次与用户交流而形成的。系统所需的数据，都在数据流图和数据字典中得到表现，是后阶段设计的基础和依据。目前，在概念设计阶段，实体、联系模型(ERM)是广泛使用的设计工具。8．4．1构成系统的实体型

要抽象系统的ER模型描述，重要的一步是从数据流图和数据字典中提取出系统的。所有实体型及其属性。划分实体型和属性的两个基本标准如下：

①“属性”必须是不可分割的数据项，属性中不能包括其他的“属性”或“实体型”。

②ER图中的联系是实体型之间的关联，因而“属性”不能与其他实体型之间有关联。

由前面的教学管理系统的数据图和数据字典，可以抽取出系统的6个主要实体，包括：学生、课程、教师、专业、班级和教室。

学生实体型属性有学号、姓名、出生日期、籍贯、性别、家庭住址。

课程实体型属性有课程编码、课程名称、讲授课时、课程学分。

教师实体型属性有教师编号、教师姓名、专业、职称、出生日期、家庭住址。专业实体型属性有专业编码、专业名称、专业性质、专业简称、可授学位。班级实体型属性有班级编码、班级名称、班级简称。

教室实体型属性有教室编码、最大容量、教室类型(是否为多媒体教室)。

图8-8系统局部ER图

8．4．2系统局部ER图

从数据流图和数据字典．分析得出实体型及其属性后，进一步可分析各实体型之间的联系。

学生实体型与课程实体型存在修课的联系。一个学生可以选修多门课程，每门课程可以被多个学生选修，所以它们之间存在多对多联系(m：n)，如图8—8(a)所示。

教师实体型与课程实体型存在讲授的联系，一个教师可以讲授多门课程，每门课程可以由多个教师讲授，所以它们之间存在多对多联系(m：n)，如图8—8(b)所示。

学生实体型与专业实体型存在学习的联系，一个学生只可学习一个专业，每个专业有多个学生学习，所以专业实体型和学生实体型存在一对多联系(1：n)，如图8—8(c)所示。

班级实体型与专业实体型存在属于的联系，一个班级尽可能属于一个专业，每个专业包含多个班级，所以专业实体型和班级实体型存在一对多联系(1：n)，如图8—8(d)所示。

学生实体型与班级实体型存在属于的联系，一个学生只可属于一个班级，每个班级有多个学生，所以班级实体型和学生实体型存在一对多联系(1：n)，如图8—8(e)所示。

某个教室在某个时段分配给某个教师讲授某一门课或考试用，在特定的时段为1：1联系，但对于整个学期来讲是多对多联系(m：n)，采用聚集来描述教室与任课教师和课程的讲授联系型的关系，如图8—8(f)所示。

8．4．3合成全局ER图

系统的局部ER图，只反映局部应用实体型之间的联系，但不能从整体上反映实体型之间的相互关系。另外，对于一个较为复杂的应用来讲，各部分是由多个分析人员分工合作完成的，画出的ER图只能反映各局部应用。各局部ER图之间，可能存在一些冲突和重复的部分，例如，属性和实体型的划分不一致而引起的结构冲突，同一意义上的属性或实体型的命名不一致的命名冲突，属性的数据类型或取值的不一致而导致的域冲突。为减少这些问题，必须根据实体联系在实际应用中的语义，进行综合和调整，得到系统的全局ER图。

从上面的ER图可以看出，学生只能选修某个教师所讲的某门课程。如果使用聚集来描述学生和讲授联系型之问的关系，代替单纯的学生和课程之间的关系，相对更为适合。各局部ER图相互重复的内容比较多，将各局部ER图合并后形成的全局ER图如图8—9所示。

图8-9合成后的全局ER图

8．4．4优化全局ER图

优化全局ER图，是消除全局ER图中的冗余数据和冗余联系。冗余数据，是指能够从其他数据导出的数据；冗余联系，是从其他联系能够导出的联系。例如，学生和专业之间的“学习”联系型，可以由“组成”联系型和“属于”联系型导出。所以，应该消除“学习”联系型。经优化后的全局ER图，如图8—10所示。在实际设计过程中，如果ER图不是特别，复杂时，这一步可以和合成全局ER图一起进行。

图8-10经优化后的全局ER图

8．5系统的逻辑设计

概念设计阶段设计的数据模型，是独立于任何一种商用化的DBMS的信息结构。逻辑设计阶段的主要任务，是把ER图转化为所选用的DBMS产品支持的数据模型。由于该系统采用SQL Servetr2000关系型数据库系统，因此，应将概念设计的：ER模型转化为关系数据模型。

8．5．1转化为关系数据模型

首先，从任课教师实体和课程实体以及它们之间的联系来考虑。任课教师与课程之间的关系是多对多的联系，所以将任课教师和课程以及讲授联系型分别设计成以下关系模式：教师(教师编号，教师姓名，籍贯，性别，所学专业，职称，出生日期，家庭住址)

课程(课程编码，课程名称，讲授课时，课程学分)

讲授(教师编号，课程编码，开课年度，开课学期)

教室实体型与讲授联系型是用聚集来表示的，并且存在两种占用联系，它们之间的关系是多对多的关系，可以划分为以下3个关系模式：

教室(教室编码，最大容量，教室类型)

授课占用(教师编号，课程编码，教室编码，课表时间，授课周次)

考试占用(教师编号，课程编码，教室编码，考试时间，考场人数)

专业实体和班级实体之间的联系是一对多的联系型(1：n)，所以可以用以下两个关系模式来表示，其中联系被移动到班级实体中：

班级(班级编码，班级名称，班级简称，专业编码)

专业(专业编码，专业名称，专业性质，专业简称，可授学位)

班级实体和学生实体之间的联系是一对多的联系型(1：n)，所以可以用两个关系模式来表示。但是班级已有关系模式“班级(班级编码，班级名称，班级简称，专业编码)”，所以下面只生成一个关系模式，其中联系被移动到学生实体中：

学生(学号，姓名，出生日期，籍贯，性别，家庭住址，班级编码)

学生实体与讲授联系型的关系是用聚集来表示的，它们之间的关系是多对多的关系，可以使用以下关系模式来表示：

修课(课程编码,学号，教师编号，考试成绩)

8．5．2关系数据模型的优化与调整

在进行关系模式设计之后，还需要以规范化理论为指导，以实际应用的需要为参考，对关系模式进行优化，以达到消除异常和提高系统效率的目的。

以规范化理论为指导，其主要方法是消除各数据项问的部分函数依赖、传递函数依赖等。

首先，应确定数据间的依赖关系。确定依赖关系，一般在需求分析时就做了一些工作，ER图中实体间的依赖关系就是数据依赖的一种表现形式。

其次，检查是否存在部分函数依赖、传递函数依赖，然后通过投影分解，消除相应的部分函数依赖和传递函数依赖，来达到所需的范式。

一般说来，关系模式只需满足第三范式即可。从8．6．1小节所述关系模式可以看出，它们满足第三范式，在此就不具体分析。

在实际应用设计中，关系模式的规范化程度并不是越高越好。因为从低范式向高范式转

化时，必须将关系模式分解成多个关系模式。这样，当执行查询时，如果用户所需的信息在多个表中，就需要进行多个表间的连接，这无疑对系统带来较大的时间开销。为了提高系统处理性能，要对相关程度比较高的表进行合并，或者在表中增加相关程度比较高的属性(表的列)。这时，选择较低的第一范式或第二范式可能比较适合。

如果系统某个表的数据记录很多，记录多到数百万条时，系统查询效率将很低。可以通过分析系统数据的使用特点，做相应处理。例如，当某些数据记录仅被某部分用户使用时，可以将数据库表的记录根据用户划分，分解成多个子集放入不同的表中。

前面设计出的教师、课程、教室、班级、专业以及学生等关系模式，都比较适合实际应用，一般不需要作结构上的优化。

对于“讲授(教师编号，课程编码，开课年度，开课学期)”关系模式，既可用作存储教学计划信息，又代表某门课程由某个老师在某年的某学期主讲。当然，同一门课可能在同一学期由多个教师主讲，教师编码和课程编码对于用户不直观，使用教师姓名和课程名称比较直观，要得到教师姓名和课程名称就必须分别和“教师”以及“课程”关系模式进行连接，因而有时问上的开销。另外，要反映“授课和教学计划”的特征，可将关系模式的名字改为“授课一计划”，因此，关系模式改为“授课～计划(教师编号，课程编码，教师姓名，课程名称，开课年度，开课学期)”。

按照上面的方法，可将“授课占用(教师编号，课程编码，教室编码，课表时间，授课周次)”，“考试占用(教师编号，课程编码，教室编码，考试时间，考场人数)”两个关系模式分别改为“授课安排(教师编号，课程编码，教室编码，课表时间，教师姓名，课程名称，课周次)”，“考试安排(教师编号，课程编码，教室编码，考试时间，教师姓名，课程名称，考场人数)”。

对于“修课”关系模式，由于教务员要审核学生选课和考试成绩，因此需增加审核信息属性。因此，“修课”关系模式调整为“修课(学号,课程编码，教师编号，学生姓名，教师姓名，课程名称，选课审核人，考试成绩，成绩审核人)”。

为了增加系统的安全性，需要对教师和学生分别检查密码口令，因此需要在“教师”和“学生”关系模式中增加相应的属性。即“教师(教师编号，教师姓名，籍贯，性别，所学专业，职称，出生日期，家庭住址，登录密码，登录IP，最后登录时间)”，“学生(学号，姓名，出生日期，籍贯，性别，家庭住址，班级编码，登录密码，登录IP，最后登录时间)”。8．5．3数据库表的结构

得出数据库的各个关系模式后，需要根据需求分析阶段数据字典的数据项描述，给出各数据库表结构。考虑到系统的兼容性以及编写程序的方便性，可将关系模式的属性对应为表字段的英文名。同时，考虑到数据依赖关系和数据完整性，需要指出表的主键和外键，以及字段的值域约束和数据类型。不同的数据类型，对系统的效率有较大的影响，例如，对于SQL Server2000中的char和varchar，相同的数据，char比varchar需要更多的磁盘空间，可能需要更多的I／O和其他处理操作。

系统各表的结构，如表8—1至表8—11所示。

8．6数据库的物理设计

数据库物理设计的任务，是将逻辑设计映射到存储介质上，利用可用的硬件和软件功能尽可能快地对数据进行物理访问和维护。物理设计主要考虑的内容包括：使用哪种类型的磁盘硬件，例如，RAID(磁盘冗余阵列)设备；如何将数据放置在磁盘上；在访问数据时，使用哪种索引设计提高查询性能；如何适当设置数据库的所有配置参数，以使数据库高效地运行。

8．6．1存储介质类型的选择

RAID是由多个磁盘驱动器组成的磁盘系统，可为系统提供更高的性能、可靠性、存储容量和更低的成本。从0到5级，容错阵列共分为6个RAID等级，每个等级使用不同的算法实现容错。SQL Server2000一般使用RAID等级0、1和5。

RAlD0等级，是使用数据分割技术实现的磁盘文件系统，它将所有硬盘构成一个磁盘阵列，可以同时对多个硬盘进行读写。RAID O通过在多个磁盘内的并行操作，提高读写性能。例如，一个由两个硬盘组成的RAID0磁盘阵列，把数据的第一和二位写入第一个硬盘，第三和第四位写入第二个硬盘，这样可以提高数据读写速度。但是不具备备份及容错能力，其价格便宜，硬盘使用效率最佳，但是可靠度是最差的。

RAID1等级，使用称为镜像集的磁盘文件系统，因而也称该等级为磁盘镜像。磁盘镜像提供选定磁盘冗余的、完全一样的副本。所有写入主磁盘的数据，均写入镜像磁盘。RAID 1提供容错能力，且一般可提高读取性能，但可能会降低系统写数据的性能。

RAID5等级，也称为带奇偶的数据分割技术，是在设计中最常用的策略。该等级在阵

列内的磁盘中，将数据分割成大块，并在所有磁盘中写入奇偶信息，数据冗余由这些奇偶信

息提供。数据和奇偶信息排列在磁盘阵列上，以使二者始终在不同的磁盘上。带奇偶的数据分割技术，比磁盘镜像(RAID1)提供更好的性能。

为了提高系统的安全性，防止系统因介质的损坏而导致数据丢失的危险，基于windows 2000RAID5卷实现RAID5级磁盘阵列。带奇偶的磁盘数据分割技术，将奇偶信息添加到每个磁盘分区上。这样，可提供与磁盘镜像相当的容错保护，而存放冗余数据所需的空间要少得多。当带奇偶的磁盘块或RAID5卷的某个成员发生严重故障时，可以根据其余成员，新生成这个集成员的数据。创建RAID5卷，至少需要3个物理磁盘。因此，在该系统可以使用4个物理磁盘，为后面将介绍的创建多个数据库文件提供支持。

8．6．2定义数据库

SQL Server2000数据库文件分为3种类型：主数据文件、次数据文件和日志文件。

主数据文件是数据库的起点，指向数据库中文件的其他部分；每个数据库都有一个主

数据文件，其文件扩展名为mdf。

次数据文件包含除主数据文件外的所有数据文件；有些数据库可能没有次数据文件，而有些数据库则有多个次数据文件。次数据文件的扩展名是．ndf。这些次文件，含有不能放到主数据文件中的所有数据。如果主数据文件可以包含数据库中的所有数据，那么数据库就不需要次数据文件。有些数据库可能足够大，故需要多个次数据文件，将数据扩展到多个磁盘。

日志文件包含恢复数据库所需的所有日志信息，每个数据库必须至少有一个日志文件，但可以不止一个，日志文件的扩展名为．1df。

本系统将数据文件分成以下几个文件：一个主数据文件，存放在C：＼Educationaladministration＼data＼Teachdatl．mdf下；两个次文件，分别存放在D：＼Edtlcational administration＼data＼Teachdat2．mdf和E：＼Educational admirlistration＼data＼Teachdat3．mdf 下；日志文件，存放在F：＼Educational administration＼data＼Teachlog．1df下。

这样，系统对4个磁盘进行并行访问，提高系统对磁盘数据的读写效率。其创建数据库的语句如下：

CREATE DATABASE TeachDb

ON

PRIMATY(NAME=Teachfilel,

FILENAME=’C:、\Educational administration\data\Teachdatl mdf’

SIZE=100MB,

MAXSIZE=200,

FILEGROWTH=20),

(NAME=Teachfile2,

FILENAME=’D:\Educational administration\data\Teachdat2.mdr’,

SIZE=100MB,

MAXSIZE=200,

FELEGROWTH=20),

(NAME=Teachfile3,

FILENAME=’E:\Educational administration\data\Teachdat3.mdf’,

SIZE=100MB

MAXSIZE=200,

FILEGROWTH=20)

LOG ON

(NAME=Teacholg,

FILENAME=’F:\Educational administration\data\Teachlong.ldr’,

SIZE=100MB,

MAXSIZE=200,

FILEGROWTH=20)

8.6.3创建表及视图

使用SQL Server2000的数据定义语方,在数据库TeachDb中定义数据库表.其定义数据库表的语句如下:

CREATE TABLE Teachlnfor/*教师信息表*/

(Tcode varchar(10)Not null,/*都是编码*/

Tname varchar(10)Not null,/*教师姓名*/

Nativeplace varchar(12),/*籍贯*/

Sex varchar(4),/*性别*/

Speciality varchar(16)Not null,/*职称*/

Birthday Datetime,/*出生日期*/

Logincode varchar(10),/*家庭住址*/

LoginIP varchar(15),/*登录密码*/

Lastlogin Datetime,/*登录IP*/

Lastlogin Datetime,/*最后登录时间*/

Constraint Tcodekey PRIMARY KEY(Tcode)

)

CREATE TABLE SpeInfor/*专业信息表*/

(Specode varchar(8)Not null,/*专业编码*/

Spename varchar(30)Not null,/*专业名称*/

Spechar varchar(20)/*专业性质*/

Speshort varchar(10),/*专业简称*/

Degree varhar(10),/*可授学位*/

Costraint Specodekey PRIMARY KEY(Specode)

)

8．6．4创建索引

教学管理系统核心的任务，是对学生的学籍信息和考试成绩进行有效的管理。其中，数据量最大和访问频率较高的，是学生修课信息表。因此，需要对学生修课信息表和学生信息表建立索引，以提高系统的查询效率。

如果应用程序执行的一个查询，经常检索给定学生学号范围内的记录，则使用聚集索引可以迅速找到包含开始学号的行，然后检索表中所有相邻的行，直到到达结束学号。这样有助于提高此类查询的性能。

同样，如果对表中检索的数据进行排序时，经常要用到某一列．则可以将该表在该列上聚集(物理排序)，避免每次查询该列时都进行排序，从而节省成本。

下面给出学生修课信息表和学生信息表的聚簇索引。

CREATE CLUSTERED1NDEX StudCourseIndex

ON StudCourse(Scode,Tcode，Ccode)

CREATE CLUSTERED INDEX StudInforIndex()N StudInfor(Scode)

8．6．5数据库服务器性能优化

数据库服务器性能优化，主要包括SQL ServeI2000内存优化、I／O系统的优化以及操作系统windows Server2000性能的优化。一般说来，在系统安装时，系统自动配置了相关参数，不需要作太多的调整。

1．与内存有关的参数

1)min server memory

用于指定SQl Server启动时，内存的最小分配量，并且内存低于该值时不会释放内存。可以基于SQL Server的大小及活动，将该参数设置为特定的值。

2)max server memory

用于指定在SQL Server启动及运行时，可以分配的最大内存量。如果知道有多个应用程序与sQL Serlver同时运行所需的最大内存量，则可以将该参数设置为特定的值。如果有一些应用程序，只根据需要请求内存，并且难以估计所需内存的最大量，则SQLServer将根据需要给它们释放内存，因此不要设置该参数。

3)max worker threads

用于指定为用户连接到SQL Server提供支持的线程数。默认设置为255，该选项的大小取决于并发用户数。一般情况下，应将该参数设置为并发连接数，而最大不超过1024。

4)indeX create memory

用于创建索引时，控制排序操作所使用的内存量。一般情况下，创建索引是在系统比较空闲时进行的，增加该值可提高索引创建的性能。但是，最好将min memorory per query保持在较小的值，这样可以在内存较少时，创建索引。

5)min memory per query

用于指定执行查询时所分配的最小内存量。当系统内有许多查询并发执行时，增大min memol-y pei·query的值，有助于提高消耗大量内存的查询性能。但是，一般不要将min memoI-y pez·query设置得太高。因为，当系统较忙时，查询必须等到能确保占有请求的最小内存或等到超过query wait所指定的最大等待值。如果可用内存比执行查询所需的指定最小内存多，当查询能够有效利用现有内存时，则可以使用多出的内存。

2．I／O配置参数

recovery interval用于指定SQL Server2000在每个数据库内发出检查点的时间。默认情况下，SQL server自动确定执行检查点操作的最佳时间。更改该参数以使检查点进程较少出现，通常可以提高这种情况下的总体性能。

3．服务器性能参数

服务器性能主要与最大吞吐量、服务器任务调度优先级以及虚拟内存的大小有很大的关系。

最大系统吞吐量在系统安装时，系统自动设置为最大吞吐量，一般不要改动。SQLServer 服务器可将后台运行的应用程序，设置成与前台应用程序相同的优先级，以提高处理速度。

windows2000虚拟内存大小，应根据计算机上并发运行的服务进行配置，运行Microsoft SQL Server2000时，可考虑将虚拟内存大小设置为计算机中物理内存的1．5倍，如果另外安装了全文检索功能，并打算运行Microsoft搜索服务，以便执行全文索引和查询，将虚拟内存大小至少配置为计算机中物理内存的3倍，则可以将SQL Servet。的max server-memo)ry 设置为物理内存的1．5倍。