《数据库原理与应用 教学课件 ppt 作者 陆慧娟 主编 吴达胜 刘建平 黄长城 副主编 第8章 数据库设计的典型案例》由会员分享，可在线阅读，更多相关《数据库原理与应用 教学课件 ppt 作者 陆慧娟 主编 吴达胜 刘建平 黄长城 副主编 第8章 数据库设计的典型案例（61页珍藏版）》请在金锄头文库上搜索。
1、第八章 数据库设计的典型案例,本章对象： 学生选课管理系统数据库设计 本章目的： 实际讲授数据库的设计方法，提高数据库综合设计的能力。 本章内容： 需求分析、需求描述、概念设计、逻辑设计、物理设计,8.1 案例的系统需求简介,8.1.1总体需求 8.1.2用户总体业务构造 8.1.3其它要求 8.1.4系统功能设想 8.1.5业务流程分析,8.1.1总体需求,需求分析要求应用系统的开发人员按照系统的思想，根据收集的资料，对系统目标进行分析，对业务的信息需求、功能需求以及管理中存在的问题等进行分析，抽取本质的、整体的需求，为设计一个结构良好的数据库应用系统的逻辑模型奠定坚实的基础。,8.1.2用
2、户总体业务构造,学生选课管理业务，包括4个主要部分： 学籍及成绩管理： 各院系的教务员完成学生学籍注册、毕业、转学等处理，各授课教师完成所讲授课成绩的录入，然后教务员进行学生成绩的审核认可。 制定教学计划： 由教务部门完成指导性教学计划、培养方案的确定，开设课程的注册和调整。,学生选课： 学生根据开设课程和培养计划(和自己的状况)选择自己本学期所选修课程，教务员对学生所选修课程的确认处理。(注意：一般的必修课程是由教务员统一处理，只有辅修的课程才经过学生的选择过程) 执行教学调度： 教务员根据本学期所开设的课程、教师上课的情况以及学生选课情况完成排课、调课等。,8.1.4系统功能设想,图8.
3、1选课管理系统功能结构图,8.1.5业务流程分析,8.2 需求描述,需求描述的主要形式： 数据流图(Data Flow Diagram) 数据字典 (Data Dictionary) 判定表和判定树等 需求描述的主要作用： 用户交流的主要手段和依据 后续数据库设计的前提 数据流图-可以了解软件的结构，是软件设计的重要依据。,8.2.1 数据流图,通过系列符号及其组合来描述系统功能的输入、输出、处理或加工构造。 Visio工具为例，针对Gane-Sarson模板中的符号作为参考：,1)流图分析方法说明：,流图分析采用的传统的结构化分析法，它采用的是自顶向下、逐层分解的方式分析系统，即将系统的功能
4、从宏观层面逐渐细化，达到最终的结构 从全局数据流图逐渐细化得到多层(级)局部数据流图,2)数据流图命名规则,规则1： 数据流图的中加工、处理过程一般采用动词及其短语； 数据源点或终点、数据存储(数据文件或表单形式)、数据流(一项或多项数据)等一般为名词或名词短语。 规则2： 流图中的命令所使用的语言要基本上反映实际的情况，在整个DFD中必须要唯一，尽量避免含有像加工、处理、存储这样的元名称。,3)系统的全局数据流图,系统的全局数据流图，在具体的设计工具中往往也称为第0层或顶层数据流图 从整体上描述系统的数据流 反映系统中数据的整体流向 设计者针对用户和开发者表达出来的一个总体描述,简化的选课管
5、理系统0层数据流图,2.系统局部数据流图,较为复杂的系统来讲，要清楚地描述系统数据的流向和加工处理的每一个细节，仅用全局数据流图难以完成。 要在全局数据流图的基础上，对全局数据流图的某些局部单独放大，进一步细化，细化可以采用多级方式进行，便是所谓的分级数据流图来描述。 这里以制定教学计划/学籍及成绩管理和选课等处理功能作细化的分析对象。,制定教学计划处理,主要分为4个子处理过程： 教务员根据自己已有的课程信息，增补新开设的课程信息； 调整课程信息； 查询本学期的教学计划； 制定新学期的教学计划。 任课教师可以查询自己的教学计划,图8. 5 0层P1的1层数据流图：制定教学计划,图8. 6 0层
6、P2的1层数据流图：学籍和成绩管理,图8.7 0层P3的 1层数据流图：选课管理,图8. 13 选课管理系统的全局ER图,数据字典,项目包括： 数据项 数据结构 数据流 数据存储 加工逻辑和外部实体 表达形式 使用一些符号来表示数据结构、数据流和数据存储的组成。,“P3选课管理“处理功能中包含的几个对象描述列举,1.数据流,2.数据存储,3.处理过程逻辑,4.数据项,8.3 概念设计,8.3.1 实体 8.3.2 系统局部E-R图 8.3.3 系统全局E-R图,要建立系统的E-R模型的描述，需进一步从数据流图和数据字典中提取系统所有的实体及其属性。这种提出实体的指导原则如下： 属性必须是不可分
7、的数据项，即属性中不能包含其它的属性或实体 E-R图中的关联必须是实体之间的关联，属性不能和其它实体之间有关联,本实例涉及的实体,5个：学生、教师、课程、院系、班级。 学生实体属性有：学号、姓名、出生年月、性别、电话、系编号。 教师实体属性有：教师编号、教师姓名、性别、职称、出生年月、电话、电子邮件。 课程实体属性有：课程编号、课程名称、课程学时、课程学分。 院系实体属性有：系编号、系名称、负责人。 班级实体属性有：班级编号、班级名称。,8.3.2 系统局部E-R图,在需求分析阶段我们采用的是自上而下的分析方法，分析得到实体及其属性后，进一步可分析各实体之间的联系。 为此分别找出上述5个实体之
8、间的一切联系： 学生实体和课程实体存在选修的联系 教师实体和课程实体存在讲授的联系 学生实体和班级实体存在归属的联系 班级实体和系之间存在归属的联系 教师实体和系实体之间存在归属的联系,学生实体和课程实体的联系,学生实体和课程实体存在选修的联系，一个学生可以选修多门课程，而每门课也可以被多个学生选修，所以它们之间是多对多的联系(n:m),如图。,教师实体和课程实体的联系,教师实体和课程实体存在讲授的联系，一名教师可以讲授多门课程，而每门课也可以被多个教师讲授，所以它们之间是多对多的联系(n:m),如图。,学生实体和班级实体的联系,学生实体和班级实体存在归属的联系，一个学生只能属于一个班级，而每
9、个班级可以包含多个学生，所以班级和学生之间是一对多的联系(1:n),如图8.10。,班级实体和系实体的联系,班级实体和系之间存在归属的联系，一个班级只能属于一个系，而每个系可以包含多个班级，所以班级和系之间是一对多的联系(1:n),如图8.11。,教师实体和系实体的联系,教师实体和系实体之间存在归属的联系，一个教师只能属于一个系，而每个系可以拥有多名教师，所以教师和系之间是一对多的联系(1:n),如图8.12，但是教师中会有一位充当该系的主任(正)，可见教师和系之间也存在一种一对一的领导关系(1:1),如图8.12。,8.3.3 系统全局E-R图,局部的E-R图往往有多人各自分析完成的，只反映
10、局部的独立应用的状况，在系统整体的运作需要时，这些局部E-R图之间有可能存在重复的部分或冲突的情况，如： 实体的划分、实体或属性的命名不一致 属性的具体含义(包括数据类型以及取值范围等不一致)问题等,8.4 逻辑设计,逻辑设计就是把E-R图转换成关系模式，并对其进行优化。 8.4.1 ER图到关系模式的转换 8.4.2 关系模式的规范及调整 8.4.3 各个数据表的表结构设计,8.4.1 ER图到关系模式的转换,在概念设计阶段得到的数据模型，是独立于具体DBMS产品的信息模型。 在逻辑设计阶段就是将这种模型进一步转化为某一种（某些类）DBMS产品支持的数据模型。 目前流行的是基于关系模型的数据
11、库管理系统，如SQL Server、Sybase 、Oracle、DB2等，本文以SQL Server2000数据库系统环境为例，将概念设计阶段的E-R图模型转化为关系数据模型。,E-R图模型转化,针对上述最终合成的E-R图 对E-R图中的每个实体分别转化为对应的一个关系，共有5个实体,5个实体转化成对应的关系模式：,教师(教师编号,教师姓名,性别,职称,电话,系编号) 课程(课程编号,课程名称,课程学分,课时) 系(系编号、系名称、系主任) 班级(班级编号，班级名称，系编号) 学生(学号，姓名，性别，出生年月，电话，班级编号),全局的E-R图中共包含6个联系,其中一对多的有3个 院系实体和班
12、级之间是一对多的联系类型，所以只要两个关系模式就可表示，其中联系可以放到班级的实体中的连接属性(外键) 其它两个都按如此处理 一对一的有1个 和上述的一对多的处理模式类似 多对多的有2个 学生实体与讲授是聚集方式的联系类型，它们之间的关系是多对多的关系，可以使用如下关系模式来表示： 学生选课(课程编号，学号，教师编号，开课年度，开课学期，成绩),8.4.2 关系模式的规范及调整,任课教师与课程之间的是多对多的联系类型，因此，将任课教师、课程以及讲授联系分别设计成如下的关系模式： 讲授(教师编号，课程编号，课程编号，开课年度，开课学期) 在提出关系模式后，我们必须在规范化和实际要求进行优化，这实
13、际上是一个权衡的过程。 一般的策略: 以规范化设计为出发点，然后出于特定因素有条件地非规范化某些表,以达到系统总体的优化目的。,实际中其它因素的影响：,由于实际讲授安排都是后于学生选课行为之后进行的，因此“讲授”关系模式尽管是单独地放映了某一门课在某一个学期由某一个老师讲授。“授课”关系的有关信息其实完全由课程学习关系模式中得到反映。所以可以合并“授课”到“课程学习”中去，实际上去除“授课” 关系模式便可。 对于“课程学习”关系模式，在分析阶段已经指出，选课后和成绩记录后都需经过教务员的审核确认方生效，对应需要增加审核信息属性。因此，对于“课程学习”关系模式修改为：课程学习(课程编号，学号，教
14、师编号，开课年度，开课学期，成绩，课程审核，成绩审核)。,实际中其它因素的影响：,对于分析中提及的学生状态处理(转学、退学、休学或者毕业等的情况)，为了简单化，不妨给关系模式增加一个“状态”的属性，成为：学生(学号，姓名，性别，出生年月，电话，班级编号，状态)。 为了满足实际应用对系统的系统要求，必须对使用系统的用户如教师和学生增加登录的验证口令，因此需要在“教师”和“学生”的关系模式中增加口令属性。自然地，如果根据其它的安全应用要求，还可以设置学生的登录地点如通过增加IP属性来达到目的等。,表8. 数据库中表清单,表8. 学生信息表Student字段信息列表,表8. 教师基本信息表Teach
15、er字段信息列表,表8. 系基本信息表Depart字段信息列表,表8. 班级信息表Classes字段信息列表,表8. 课程基本信息Course字段信息列表,表8.11学生选课信息表StuCourse字段信息列表,表8.12教学计划信息表Schedule字段信息列表,8.5 数据库的物理设计,8.5.1存储介质类型的选择 8.5.2 数据库“学生选课”的建立,数据库的物理设计,物理设计主要任务是将逻辑设计映射到存储介质上，利用可用的硬件和软件条件能可靠地、高效地对数据进行物理访问和维护。 存储介质及其存储模式是任何关系数据库的关键组件。关系数据库的存储设计在此数据库设计过程中占了很大份量，其中主
16、要考虑的内容： 使用哪种类型的磁盘硬件，如 RAID（独立磁盘冗余阵列）设备； 数据在磁盘上如何放置即数据的分配策略； 从访问性能的角度采用适当的索引技术和设计具体的索引项； 以及基于特定数据库有关的参数配置以使数据库很好地运行。,基于SQL Server实现数据库的物理结构：文件说明,SQL Server2000 使用一组操作系统文件映射数据库。数据库中的所有数据和对象（如表、存储过程、触发器和视图）都存储在下列三种文件类型的操作系统文件中： 主文件 这些文件包含数据库的启动信息。主文件还用于存储数据。每个数据库都包含一个主文件。 次要文件 这些文件含有不能置于主要数据文件中的所有数据。如果主文件足够大，能够容纳数据库中的所有数据，则该数据库不需要次要数据文件。有些数据库可能非常大，因此需要多个次要数据文件，或可能在各自的磁盘驱动器上使用次要文件，以便在多个磁盘上存储数据。其扩展名一般为ndf。 事务日志 这些文件包含用于恢复数据库的日志信息。每个数据库必须至少有一个事务日志文件（但是可以有多个）。日志文件最小为 512 KB, 其扩展名一般
