学生选课管理系统的数据库设计

第六章（续） 数据库设计的典型案例本章要点学生选课管理系统的数据库设计本章学习目标学生选课管理系统的需求分析学生选课管理系统的ER 图学生选课管理系统的关系数据库模式学生选课管理系统数据库的建立第六章（续）数据库设计典型案例在第 6 章里我们已经学习了有关数据库设计的基本理论和方法。本章通过学生选课管理系统数据库设计案例，实际讲授数据库的设计方法，加深对第七章的理解，提高我们的综合设计的能力。6.1案例的系统需求简介6.1.1 总体需求简单介绍需求分析阶段是数据库应用系统开发的最重要阶段。需求分析要求应用系统的开发人员按照系统的思想，根据收集的资料，对系统目标进行分析，对业务的信息需求、功能需求以及管理中存在的问题等进行分析，抽取本质的、整体的需求，为设计一个结构良好的数据库应用系统的逻辑模型奠定坚实的基础。高等学校的学生选课管理系统，在不同的学校会有不同的特点，因为作为教务工作部分它和学校本身的行政制度有关。本章的目的在于，作为数据库设计和应用开发的运用对象，对业务进行适度的简化，突出比较核心的成分，如院系算作一个级别的概念而且直接管理班(跳过专业一级的设置)，学生的免修重修等情况处理、教师的管理没有细化等。6.1.2 用户总体业务构造学生选课管理业务，包括 4 个主要部分：学生的学籍及成绩管理、制定教学计划、学生选课管理以及教学调度。各部分具体的内容：（ 1） 学籍及成绩管理包括：各院系的教务员完成学生学籍注册、毕业、转学等处理，各授课教师完成所讲授课成绩的录入，然后教务员进行学生成绩的审核认可。（ 2）制定教学计划包括：由教务部门完成指导性教学计划、培养方案的确定，开设课程的注册和调整。（ 3）学生选课包括：学生根据开设课程和培养计划(和自己的状况)选择自己本学期所选修课程，教务员对学生所选修课程的确认处理。(注意：一般的必修课程是由教务员统一处理，只有辅修的课程才经过学生的选择过程)（ 4） 执行教学调度包括： 教务员根据本学期所开设的课程、 教师上课的情况以及学生选课情况完成排课、调课等。6.1.3 其它要求如安全性，系统环境要求 (根据现有的设备情况进行系统运行 )等，这些不是本章的核心内容，所以就不再进一步叙述。第六章（续）数据库设计的典型案例6.1.4 系统功能设想这里的功能划分，是根据第一阶段需求调查基础上进行的初步划分。随着需求调查的深入，功能模块随着对需求了解的明确得到调整。教务管理业务的4 个主要部分，可以将系统应用程序划分为对应得4 个子模块：包括学籍及成绩管理子系统、教学计划管理子系统、学生选课管理子系统以及教学调度子系统。根据各业务子系统所包括业务内容,还可以将各个子系统继续细化划分为更小的功能模块。划分的准则主要遵循模块的内聚性要求和模块间的低聚合性。如图所示表示一个教务管理系统功能模块结构图。应用系统基础数据和辅助管理用户登录及其验证登出及退出系统教学计划管理学籍和成绩管理学生选课管理教学调度录 教课及选入程学成学选课教教入 学毕和和资籍绩生课数学学和 计业调修料注管转输据安调修 划处整改的册理学入审排整改 的理录核图 6. 1 选课管理系统功能结构图6.1.5 业务流程分析一个简化的选课系统业务流程如图6.2 所示：第六章（续）数据库设计典型案例教学计划各院系教务处教学计划编辑原始开课生成教学计划原始开课任课教师名单学生选课 (选课情况 )实际开课生成实际开课教师学生成绩细表成绩录入毕业、转学学生信息审核休学等图 6. 2选课管理系统业务流程6.2需求描述本阶段的成果的内容形式主要包括数据流图(Data Flow Diagram) 和数据字典 (DataDictionary) 。数据流图和数据字典是描述用户需求的重要工具以及阶段成果表达形式。它作为需求分析的成果和用户交流的主要手段和依据，是后续数据库设计的前提。设计人员从数据流图中可以比较充分地了解软件的结构，所以也是软件设计的重要依据。调查了解用户的需求后，需要进一步表达用户的需求，分析和表达用户需求的方法很多，目前最常用的还是结构化分析法。该方法是基于数据流的需求分析方法，它利用了图形的方式进行表达，容易学习和运用。结构化分析法采用的是自顶向下、逐层分解的方式分析系统，即将系统的功能从宏第六章（续）数据库设计的典型案例观层面逐渐细化，达到最终的结构化分析方法主要使用以下几个工具：数据流图(DataFlow Diagram 简称 DFD) 、数据字典 (Data Dictionary 简称 DD) 、判定表和判定树等。数据流图描述了数据的来源和去向，以及所经过的处理；而数据字典是对数据流图中的数据流、 数据存储和处理的明细描述。判定树和判定表用来描述据加工的逻辑构造。不同的应用环境，对数据描述的细化程度会有所不同，常常应实际情况而定。下面就使用这两种工具来描述本例的用户需求，体现他们在实际中的应用方法。6.2.1数据流图数据流图是通过系列符号及其组合来描述系统功能的输入、 输出、处理或加工构造。数据流图中使用的符号在各种书籍和资料上表达不尽相同，目前许多常用的一些流行的数据库辅助设计工具如MicrosoftVisio 、Sybase PowerDesigner、 Oracle Designer、Rational Rose、 Erwin 等符号都不统一，我们这里以比较容易上手的Visio 工具为例，针对 Gane-Sarson 模板中的符号作为参考：数据源点或终点，数据流加工或处理数据存储或者外部实体图 6. 3 Gane-Sarson 模板中数据流图的基本元素注意： DFD 表示数据被加工或处理的过程，箭头只是表示数据流动的方向，不能有分支、循环的情况。数据流图命名规则之一：数据流图的中加工、处理过程一般采用动词及其短语；数据源点或终点、 数据存储 (数据文件或表单形式 )、数据流 (一项或多项数据 )等一般为名词或名词短语。数据流图命名规则之二：流图中的命令所使用的语言要基本上反映实际的情况，在整个 DFD 中必须要唯一，尽量避免含有像加工、处理、存储这样的元名称。1。系统的全局数据流图系统的全局数据流图，在具体的设计工具中往往也称为第 0 层或顶层数据流图，主要是从整体上描述系统的数据流，反映系统中数据的整体流向，是设计者针对用户和开发者表达出来的一个总体描述。我们经过对教学管理业务的调查、数据的收集和信息流程分析处理，明确了该系统的主要功能，分别为：制定学校各专业各年级的教学计划以及课程的设置；学生根据学校对所学专业的培养计划以及自己的兴趣，选择自己本学期所要学习的课程；学校的教第六章（续）数据库设计典型案例务部门对新入学的学生进行学籍注册，对毕业生办理学籍档案的归档工作，任课教师在期末时登记学生的考试成绩；学校教务部门根据教学计划进行课程安排、期末考试时间地点的安排等，如图所示。教学计划处理信息课程处理信息P1教学计划和课课程数据变更信息程管理S3课程信息课程数据清单教务员安排信息教学计划变更信息选课审核S6排课信息S2教学计划信息教学计划数据课表P3选课管理学生选课请求学生P4教学安排排课单任课老师排课信息学生选课数据S5教师业务数据学生选课信息S4学生学籍信息S1教师档案学生学籍信息学生课程选择数据院系信息成绩审核命令学籍变更信息考试成绩P2学籍和成绩管理学生成绩数据S7学生成绩信息图 6. 4 简化的选课管理系统0 层数据流图2。系统局部数据流图全局数据流图，从整体上描述了数据流向和加工处理过程。但是一个较为复杂的系统来讲，要清楚地描述系统数据的流向和加工处理的每一个细节，仅用全局数据流图难第六章（续）数据库设计的典型案例以完成。因此需要在全局数据流图的基础上，对全局数据流图的某些局部单独放大，进一步细化，细化可以采用多级方式进行，便是所谓的分级数据流图来描述。这里以制定教学计划 / 学籍及成绩管理和选课等处理功能作细化的分析对象。制定教学计划处理，主要分为 4 个子处理过程：教务员根据自己已有的课程信息，增补新开设的课程信息；调整课程信息；查询本学期的教学计划；制定新学期的教学计划。任课教师可以查询自己的教学计划。其处理过程如图6.5 所示。课程查询请求P1.1课程信息S3课程信息查询课程信息要修改的课程信息课程处理信息教务员教学计划查询请求P1.2课程数据变更信息修改课程信息P1.3教学计划信息S2教学计划查询教学计划信息要修改的教学计划教学计划处理信息P1.4教学计划变更信息教学计划修改图 6. 50 层 P1 的 1 层数据流图：制定教学计划学籍及成绩管理相对比较复杂，教务员需要新生的学籍注册，毕业生的学籍和成绩的归档管理，任课教师输入学生的考试成绩后，需教务员审核并作认可处理，经确认的学生成绩不允许他人修改。其处理过程如图6.6 所示。P2.1学籍信息查询要求变更的学生学籍信息查询条件P2.2学籍状态处理学籍变更信息教务员课程成绩查询条件P2.3课程成绩查询未经审核成绩单第六章（续）数据库设计典型案例学生学籍信息S4学生学籍信息状态变更成绩查询请求学生返回成绩信息成绩审核命令P2.4审核更改数据课程成绩审核任课老师考试成绩P2.5学生成绩数据S7课程成绩录入学生成绩信息图 6. 60层 P2 的 1 层数据流图：学籍和成绩管理选课管理中，学生根据学校对其专业制定的教学计划，录入本学期所选课程，教务员对学生选课记录进行审核， 经审核得到的选课就为本学期的选课。 其处理过程如图 6.7 所示。第六章（续）数据库设计的典型案例S2( 学生) 教学计划查询请求教学计划信息学生P3.1教学计划数据查询教学计划针对的教学计划S3P3.2课程数据清单课程信息选课信息录入选课信息查询教务员学生课程选择数据S5选课信息学生选课信息P3.3选课信息查询没经确认的选课P3.4经确认的选课信息选课审核选课信息确认图 6. 7 0 层 P3 的 1 层数据流图：选课管理0 层 P4 的 1 层数据流图请读者自行描述。我们可以使用许多的设计工具完成数据流图的创建，这些工具不但可以实现常用的数据流图的绘制，而且可以对多层的数据流图中的元素及其关系的正确性实现有效的检验，能帮助我们学习和理解数据流图的实现技术。本章有关的数据流图均使用MicrosoftVisio 工具进行绘制，相关的工具还有 Sybase公司的 Power Designer 以及 Oracle 的 Designer 等，有兴趣的可以参考相关的资料或者下载试用版。第六章（续）数据库设计典型案例6.2.2数据字典数据流图表达了数据与处理的关系， 数据流图作为直观的了解系统运行机理的手段，并没有具体描述各类数据的细节，只有通过数据字典进一步细化才能对系统的需求得到具体而确切的了解。 数据字典用来说明数据流图中出现的所有元素的详细的定义和描述，包括数据流、加工处理、数据存储、数据的起点和终点或外部实体等。数据字典包括的项目有：数据项、数据结构、数据流、数据存储、加工逻辑和外部实体。可使用一些符号来表示数据结构、数据流和数据存储的组成。由于本实例涉及的数据字典项目较多， 此处列举 P3 选课管理 处理功能中包含的几个对象加以描述。1。数据流表 6. 1 P3 中数据流的描述序号数据流名来源流向组成说明1( 学 生 ) 教 学 计 需要选课的学生P3.1班级号或学号注 意 查 询 类划查询请求别的区别2教学计划数据S2 教 学 计划 信 P3.1班级号 +课程编号 + 开课学年 +息开课学期3学 生 课 程 选 择 P3.2S5 学生课程编号 + 年号 +学期号数据选课信息4选课信息查询教务员P3.3班级号 +课程号 +学年 + 学期2。数据存储表 6. 2 P3 中数据存储的描述序数据文件文件组成关键标识号组织S2 教学计划信息班级号 +课程编号 +开课 全部按开课学年 ,学期 ,班级降序1学年 +开课学期S3 学生选课信息学号 + 课程编号 + 开课学 全部按开课学年 ,学期 ,班级降序2年 +开课学期S5 课程数据清单课程编号 +课程名称 +课 课程编号课程编号排序3程说明3。处理过程逻辑表 6. 3 P3 中处理过程逻辑的描述序号处理过程编号输入输出处理逻辑第六章（续）数据库设计的典型案例1查询教学计划P3.1学生选课查询请求 + 教学计 针对的教学计划针对 选 课请 求进划数据行查询2选课信息录入P3.2针对的教学计划学生课程选择数据根据 学 生对 应的教学 计 划选 择课程3选课信息查询P3.3选课信息查询 +选课数据没经确认的选课根据 班 级和 课程号检 查 对应 的未确 认 的 选课 清单清单4选课信息确认P3.4选课审核 +没经确认的选课经确认的选课信息选择 选 课清 单进行确认4。数据项表 6. 4 P3 中数据项的说明序号数据项数据对象说明数据构成1学号1 英文 |数字 10入学年号+ 班级序号+顺序号2 选课时间 4 数字 -2 数字 -2 数字 年 +月 +日3 课程名称 1 汉字 |英文 |数字 204 班级号1 英文 |数字 65 教师编号 1 英文 |数字 106 开课学年 4 数字 7 开课学期 1|26 课程说明 0 汉字 |英文 |数字 100英文 = a z| A Z数字 = 0 96.3概念设计上述的数据流图和数据字典共同构成了对用户需求的表达，它们是系统分析员(数据库管理员 ) 在需求调查过程中和用户反复交互得到的。建设系统实际要处理的数据基本上已经在数据流图中得到体现，整个设计过程的后续步骤提供基础和依据。概念设计就是通过对需求分析阶段所得到的信息需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型，主要的手段为ER 图。第六章（续）数据库设计典型案例在概念设计阶段， 主要采用的设计手段目前还是实体联系模型 (E-R Model) 。绘制图的关键是确定 E-R 图的各种结构，包括实体、属性和联系。大部分的流行建模工具E-R(Power Designer 、 Oracle Designer、 ERwin等 )也都包含了对E-R设计手段的支持。6.3.1实体要建立系统的E-R 模型的描述，需进一步从数据流图和数据字典中提取系统所有的实体及其属性。这种提出实体的指导原则如下：属性必须是不可分的数据项，即属性中不能包含其它的属性或实体E-R 图中的关联必须是实体之间的关联，属性不能和其它实体之间有关联由前面分析得到的数据流图和数据字典，可以抽象得到实体主要有5 个：学生、教师、课程、院系、班级。(1) 学生实体属性有：学号、姓名、出生年月、性别、电话、系编号。(2) 教师实体属性有：教师编号、教师姓名、性别、职称、出生年月、电话、电子邮件。(3) 课程实体属性有：课程编号、课程名称、课程学时、课程学分。(4) 院系实体属性有：系编号、系名称、负责人。(5) 班级实体属性有：班级编号、班级名称。6.3.2系统局部 E-R 图在需求分析阶段我们采用的是自上而下的分析方法，那么要在其基础上进一步作概念设计我们面临的是细化的分析数据流图以及数据字典，分析得到实体及其属性后，进一步可分析各实体之间的联系。学生实体和课程实体存在选修的联系，一个学生可以选修多门课程，而每门课也可以被多个学生选修，所以它们之间是多对多的联系(n:m), 如图 6.6。教师实体和课程实体存在讲授的联系，一名教师可以讲授多门课程，而每门课也可以被多个教师讲授，所以它们之间是多对多的联系(n:m), 如图 6.9。学生实体和班级实体存在归属的联系，一个学生只能属于一个班级，而每个班级可以包含多个学生，所以班级和学生之间是一对多的联系(1:n), 如图 6.10。班级实体和系之间存在归属的联系，一个班级只能属于一个系，而每个系可以包含多个班级，所以班级和系之间是一对多的联系(1:n),如图 6.11。教师实体和系实体之间存在归属的联系，一个教师只能属于一个系，而每个系可以拥有多名教师，所以教师和系之间是一对多的联系(1:n), 如图 6.12，但是教师中会有一位充当该系的主任(正 )，可见教师和系之间也存在一种一对一的领导关系(1:1),如图 6.12。第六章（续）数据库设计的典型案例图 6. 8“学生 -课程”选课关系图 6. 9“教师 -课程”实体间的关系图 6. 10“学生 -班级”的组成关系第六章（续）数据库设计典型案例图 6. 11“班级 -系”的属于关系图 6. 12“教师 -系”实体间的关系6.3.3系统全局 E-R 图系统的局部E-R 图，仅反映系统局部实体之间的联系，但无法反映系统在整体上实体间的相互联系。而对于一个比较复杂的应用系统来说，这些局部的E-R 图往往有多人各自分析完成的，只反映局部的独立应用的状况，在系统整体的运作需要时，他们之间有可能存在重复的部分或冲突的情况，如实体的划分、实体或属性的命名不一致等，属性的具体含义 (包括数据类型以及取值范围等不一致)问题，都可能造成上述提到的现象。为解决这些问题，必须理清系统在应用环境中的具体语义，进行综合统一，通过调整消除那些问题，得到系统的全局E-R 图。从实际的情况以及上述的局部E-R 图我们可以得知，学生实际修学某门课时必须只能对应一位老师的该门课。因此，可以使用一个聚集来表达学生参加实际授课课程的学习关系，会更加切合实际。各局部E-R 存在不少的重复的实体，经过上述聚集分析和合第六章（续）数据库设计的典型案例并得到系统全局的 E-R 图如图 6-13 所示。该全局 E-R 图基本上不存在关系的冗余状况，因此它已经是一个优化的。开课年度开课学期N1N讲授M教师课程教师编号电子邮件课程学时领导课程编号性别出生年月电话教师姓名课程名称课程学分属于职称1班级编号班级名称M1选课成绩1属于N系班级负责人1N系编号系名称组成N学生系编号学号性别电话姓名出生年月图 6. 13选课管理系统的全局ER 图6.4逻辑设计逻辑设计就是把E-R 图转换成关系模式，并对其进行优化。6.4.1ER 图到关系模式的转换在概念设计阶段得到的数据模型，是独立于具体DBMS 产品的信息模型。在逻辑设计阶段就是将这种模型进一步转化为某一种（某些类） DBMS 产品支持的数据模型。目前大部分的流行的数据库管理系统 (SQL Server 、Sybase 、Oracle 、DB2 等 )基本上都是基于关系的数据模型，包括该系统将采用的SQL Server2000 数据库系统，因此，应将概念第六章（续）数据库设计典型案例设计阶段的E-R 图模型转化为关系数据模型。首先，课程实体以及他们的联系。任课教师与课程之间的是多对多的联系类型，因此，将任课教师、课程以及讲授联系分别设计成如下的关系模式：教师 (教师编号 ,教师姓名 ,性别 ,职称 ,电话 ,系编号 )课程 (课程编号 ,课程名称 ,课程学分 ,课时 )讲授 (教师编号，课程编号，课程编号，开课年度，开课学期)院系实体和班级之间是一对多的联系类型，所以只要两个关系模式就可表示，其中联系可以放到班级的实体中：系 (系编号、系名称、系主任)班级 (班级编号，班级名称，系编号)班级实体和学生实体之间是一对多的联系类型，所以也可以只使用两个关系模式来表示。由于“班级”关系模式在上面已经给出，因此，只要再给出一个学生的关系模式，它们间的联系则被放在该关系模式中：学生 (学号，姓名，性别，出生年月，电话，班级编号)学生实体与讲授是聚集方式的联系类型，它们之间的关系是多对多的关系，可以使用如下关系模式来表示：学生选课 ( 课程编号，学号，教师编号，开课年度，开课学期，成绩)6.4.2关系模式的规范及 调整在提出关系模式后，我们必须在规范化和实际要求进行优化，这实际上是一个权衡的过程。 如果设计没有完全规范化， 如可能用于决策支持 (与需要大量更新的事务处理相对 )的数据库 (如数据仓库 )则可能没有冗余更新，而且可能对查询更易于理解和更高效。不过，在数据库应用程序内，未规范化的数据在设计过程更需要注意。一般的策略是以规范化设计为出发点， 然后出于特定因素有条件地非规范化某些表 ,以达到系统总体的优化目的。首先，需要我们确定上面建立的关系模式中的函数依赖，一般在作需求分析时就了解到一些数据项的依赖关系，如教师的编号决定了教师的姓名和其它的数据项信息，而实体间的联系本身也是反映了一种函数依赖关系，但是这不是研究的对象，我们针对的是在一个关系模式中的函数依赖对象。其次，对上一步确立的所有函数依赖进行检查，判别是否存在部分函数依赖以及传递函数依赖，针对有的依赖通过投影分解，消除在一个关系模式中存在的部分函数依赖和传递函数依赖。大部分数据库系统只要满足第三关系范式就可以，这也是我们这里规范化的基本要求。由于需求分析阶段的方法得当，经过简单的分析可以看出，上述所有关系中每个数据项都是基本的，任何非主属性都不存在对主码的部分依赖，也不存在非主属性存在着对主码的传递依赖。可见，以上所有的关系模式都属于3NF。第六章（续）数据库设计的典型案例在实际的应用中，关系模式的规范化程度并不是越高越好，因为在关系模式的规范化提升过程中，必须进行着将一个关系模式分解成为多个关系模式的过程。这样，在以后执行查询时，如果需要相关的信息，就必须作多个表的连接方能达到查询的目的，这无疑给系统增加一定的开销，特别存在很多用户同时访问或者关系中存在许多元组等因素其负担会越加明显。为了兼顾性能的需要，在适当的时候可能需要对相关程度比较高的一些关系模式进行合并处理，或者在关系模式中增加相关程度比较高的属性等。这是有可能选择第二范式甚至第一范式。如果系统存在很多的元组数(记录数 )，特别当记录达到百万甚至千万条记录时，系统的查询效率可能会受到明显的影响，分析关系模式的特点，可以根据某些关键属性不同将关系模式分解为多个关系模式，模式之间通过共同的主键一一对应起来。前面设计出的教师、课程、班级、院系和学生等关系模式基本上是实际应用中事物的直接对应，一般不需要优化。由于实际讲授安排都是后于学生选课行为之后进行的，因此“讲授”关系模式尽管是单独地放映了某一门课在某一个学期由某一个老师讲授，而一门课在一个学期也可以有多个老师主讲，关键还在于老师的讲课针对哪个(些 )班级进行。“授课”关系的有关信息其实完全由课程学习关系模式中得到反映。所以可以合并“授课”到“课程学习”中去，实际上去除“授课”关系模式便可。对于“课程学习”关系模式，在上述需求分析阶段已经指出，选课后和成绩记录后都需经过教务员的审核确认方生效，对应需要增加审核信息属性。因此，对于“课程学习”关系模式修改为：课程学习(课程编号，学号，教师编号，开课年度，开课学期，成绩，课程审核，成绩审核)。对于分析中提及的学生状态处理( 转学、退学、休学或者毕业等的情况)，为了简单化，不妨给关系模式增加一个“状态”的属性，成为：学生(学号，姓名，性别，出生年月，电话，班级编号，状态) 。为了满足实际应用对系统的系统要求，必须对使用系统的用户如教师和学生增加登录的验证口令，因此需要在“教师”和“学生”的关系模式中增加口令属性。自然地，如果根据其它的安全应用要求，还可以设置学生的登录地点如通过增加IP 属性来达到目的等。6.4.3各个数据表的表结构设计在上述经由E-R 模型得到关系模式并且得到适当的调整后，我们可以结合在需求表述中数据字典包含的数据项信息，得到数据库的表结构。我们应该根据6.4.1 节的内容，具体设计各个数据表的表结构，包括表名，表中各列的字段名、数据类型、数据长度和表的主键和外键；还要考虑应该建立哪些索引以及索引的类型。需要指出的是，考虑到系统的统一兼顾如对数据库管理员和后续软件开发中对数据库管理以及编程引用的便利，表名和字段名的命名应该由表名的英文含义的词语为主或以其缩写字母构成；同时要为各个表名和字段名作出完整的中文文档说明。第六章（续）数据库设计典型案例表 6.1 至表 6.6 给出了数据库中各个数据表的表结构。表 6. 5 数据库中表清单数据库表名关系模式名称备注Teacher教师教师信息表Student学生学生学籍信息表Course课程课程基本信息表Class班级班级基本对照表StuCourse学生选课选课 -授课合成信息表Department系院系基本信息表Schedule教学计划教学计划安排表表 6. 6 学生信息表Student 字段信息列表字段名称含义属性类型长度备注Snum学号char10主键 ,也可以作为登录标识Sname学生姓名nvarchar6Not nullSsex性别nchar2男、女 (M/F)Sbirth出生年月datetimeClnum班级号varchar6所在班级编号 ,外键 Classes.ClnumEmail电子邮件nvarchar40支持中文邮箱Passwd密码varchar20密码，可以是数字英文和符号等Status状态nvarchar6表示在校或毕业或转学等表 6. 7教师基本信息表Teacher 字段信息列表字段名称含义属性类型长度备注Tnum教师编号char10主键 ,也可以作为登录标识Tname教师姓名nvarchar6Not nullTsex性别nchar2男、女 (M/F)Title职称nvarchar6教授、副教授 Tphone联系电话char15Email电子邮件nvarchar40支持中文邮箱Tbirth出生年月datetimePasswd密码varchar20密码，可以是数字英文和符号等Dnum系编号varchar6外键 Depart.Dnum第六章（续）数据库设计的典型案例表 6. 8系基本信息表Depart 字段信息列表字段名称含义类型长度备注Dnum系编号varchar6主键Dname系名称nvarchar10Not nullDirector系主任varchar10外键 Teacher.Tnum表 6. 9班级信息表Classes 字段信息列表字段名称含义类型长度备注Clnum班级编号varchar6主键Cname班级名称nvarchar10Not nullDesscription 班级说明nvarchar100如专业 ,本专科Dnum系编号varchar6外键Depart.Dnum表 6. 10课程基本信息Course 字段信息列表字段名称含义类型长度备注Cnum课程编号varchar10主键Cname课程名称varchar20Not nullCredit学分numeric3,1Period课时int3表 6. 11 学生选课信息表StuCourse 字段信息列表字段名称含义类型长度备注Snum学号varchar10外建Student.SnumCnum课程编号varchar10外建Course.CnumTnum教师编号varchar10外建Teacher.TnumYnum开课年度int4例如： 2006Term开课学期int11|2Grade成绩numeric4,10 100 注意考查课的数字化CAuditor选课审核者nvarchar6直接取其姓名Gauditor成绩审核者nvarchar6直接取其姓名第六章（续）数据库设计典型案例表 6. 12 教学计划 信息表 Schedule 字段信息列表字段名称含义类型长度备注Cnum课程编号varchar10外建Course.CnumClnum班级编号varchar6外建Classes.ClnumYnum开课年度int4例如： 2006Term开课学期int1如 1|2 针对一个学年只有两个学期情形6.5数据库的物理设计数据库的物理设计任务，主要是将逻辑设计映射到存储介质上，利用可用的硬件和软件条件能可靠地、高效地对数据进行物理访问和维护。存储介质及其存储模式是任何关系数据库的关键组件。数据库的成功执行通常需要在工程的前期阶段精心设计。关系数据库的存储设计在此数据库设计过程中占了很大份量，其中主要考虑的内容：使用哪种类型的磁盘硬件，如RAID （独立磁盘冗余阵列）设备；数据在磁盘上如何放置即数据的分配策略；从访问性能的角度采用适当的索引技术和设计具体的索引项；以及基于特定数据库有关的参数配置以使数据库很好地运行。6.5.1 存储介质类型的选择RAID （独立磁盘冗余阵列）是由多个磁盘驱动器（一个阵列）组成的磁盘系统，可提供更高的性能、可靠性、存储容量和更低的成本。容错阵列分为从0 到 5 共6 个RAID等级。每个等级使用不同的算法实现容错。SQL Server 一般使用RAID等级0、1 和 5(注 :RAID 仅在 Windows NT 4.0、Windows 2000及 Windows 2003 等系统上配合使用)。RAID0 由于该等级使用数据分割技术(称为条带集 )的磁盘文件系统，数据分成块并在阵列内的所有磁盘中按固定顺序展开。RAID 0通过在多个磁盘内的独立而同时地数据的读 /写操作 ,具备非常高的读写性能。但是这种组合方式和普通计算机上硬盘使用的模式一样没有任何容错机制，如果一个磁盘发生故障，则需要的所有数据将不可访问。因此关键数据不能安放在RAID0 中。常用的关系数据库管理系统安装技术是在RAID 0驱动器上配置数据库， 然后将事务日志放置在镜像驱动器上(RAID 1) 。通过镜像事务日志，可以为数据库获取最佳的磁盘I/O 性能并维护数据可恢复性（假定执行定期数据库备份）。RAID1 也称为镜像集的磁盘文件系统或称磁盘镜象系统。磁盘镜像提供选定磁盘的冗余的、 完全一样的复本。所有写入主磁盘的数据均写入镜像磁盘。RAID 1 提供容错能第六章（续）数据库设计的典型案例力，如一个磁盘数据的损坏总是可以从另一个磁盘得到恢复。这种级别的RAID基本上能保证数据读取的性能，但是由于在写数据时需要将相同的数据同时写到两个硬盘上，因而 RAID1 会降低数据的写性能。RAID5 等级，也称带奇偶校验的数据分割技术，是目前设计中常用的策略。该等级在陈列内的磁盘中，将数据分成大块，并在所有的磁盘中写入奇偶校验信息，数据冗余有这些奇偶信息提供。数据和奇偶信息排列在磁盘阵列上，而且两者始终错开存放在不同的磁盘上，所以 RAID 5 提供阵列上的所有数据冗余，在大多数情况下允许单个磁盘发生故障并被替换， 而不会中断系统运行(指所谓的热插拔)。RAID 5 提供的性能比RAID0 或RAID 1要低一些，但提供更高的可靠性和更快的恢复能力。相对RAID1，RAID5在同样保证数据可靠性前提下，实现更高的性能和存储量。RAID 具体运行控制机制主要分两种,其一 :磁盘的输入 /输出操作在RAID 内置的电路中得到高效地处理，这种所谓硬件的RAID 可以显著地提高I/O 性能；其二，基于操作系统的RAID使成本较低但要占用较长的处理器周期。当成本是考虑因素之一而且需要冗余和高性能时，我们可以选择Windows 2000 RAID-5卷的解决方案， 该系统启用4 个物理磁盘，为后面的数据分配中涉及的多文件存放提供条件。在经过前面几节的分析和设计之后，就可以得到数据库的关系模式。创建学生选课管理系统的数据库。这一节给出了在SQL Server 2000 中实现该系统的数据库关系模式(SQL DDL) 。6.5.2数据库“学生选课”的建立SQL Server2000 使用一组操作系统文件映射数据库。数据库中的所有数据和对象（如表、存储过程、触发器和视图）都存储在下列三种文件类型的操作系统文件中：（ 1） 主文件 这些文件包含数据库的启动信息。主文件还用于存储数据。每个数据库都包含一个主文件。（ 2） 次要文件 这些文件含有不能置于主要数据文件中的所有数据。如果主文件足够大，能够容纳数据库中的所有数据，则该数据库不需要次要数据文件。有些数据库可能非常大，因此需要多个次要数据文件，或可能在各自的磁盘驱动器上使用次要文件，以便在多个磁盘上存储数据。其扩展名一般为ndf 。（ 3）事务日志这些文件包含用于恢复数据库的日志信息。每个数据库必须至少有一个事务日志文件（但是可以有多个）。日志文件最小为512 KB, 其扩展名一般为 ldf 。创建简单的一个数据库demo时，可以只使用一个包含所有数据和对象的主文件和一个包含事务日志信息的日志文件。另一种情况是，创建更复杂的数据库mis 时，可以使第六章（续）数据库设计典型案例用一个主文件和五个辅助文件，数据库内的数据和对象扩展到所有的六个文件中，另外有四个日志文件包含事务日志信息。文件组允许对文件进行分组，以便于管理和数据的分配放置。例如，可以分别在三个硬盘驱动器上创建三个文件（ Data1.ndf 、Data2.ndf 和 Data3.ndf ），并将这三个文件指派到文件组 fgroup1 中。然后，可以明确地在文件组 fgroup1 上创建一个表。对表中数据的查询将分散到三个磁盘上， 因而性能得以提高。 在 RAID （独立磁盘冗余阵列）上创建单个文件也可以获得相同的性能改善。然而，文件和文件组使得我们可以在新磁盘上轻易地添加新文件。假定系统的逻辑盘 C、 D、 E、 F 是对应于 RAID 上的四个物理硬盘。我们将数据文件分成三个 ， 主数据文件 C:cssdatacsmain.mdf ，两个次数据文件分别为：主数据文件D:cssdatacssecnd1.ndf和 主 数 据 文 件E:cssdatacssecnd2.nmdf ； 日 志 文 件F:cssdatacslog.ldf 。首先，我们为系统开发的需要分别在C:、D 、E、 F 上建立四个文件夹分别用于存放上述三个数据文件和一个日志文件。这样系统由于可以对四个磁盘实现并行访问而达到高效的读写效率。创建数据库的语句如下：-创建学生选课管理系统的数据库“学生选课”CREATE DATABASE学生选课ONPrimary(NAME=css_Data1, FILENAME= C:cssdatacsmain.mdf ),(NAME=css_Data2, FILENAME= D:cssdatacssecd1.ndf ),(NAME=css_Data3, FILENAME= E:cssdatacssecd2.ndf )LOG ON(NAME=css_Log, FILENAME= F:cssdatacslog.ldf )6.5.3各个数据表 (视图 )的建立建立数据库“学生选课”中各个数据表的SQL 语句如下：-创建系基本信息表DepartCREATE TABLE Depart(Dnum varchar(6) PRIMARY KEY,Dname nvarchar(10)not null,Director varchar(10)第六章（续）数据库设计的典型案例-创建班级基本信息表ClassesCREATE TABLE Classes(Clnum varchar(6) PRIMARY KEY,Clname nvarchar(10) not null,Dnum varchar(6),Bdate datetime