02_关系型数据库设计

《02_关系型数据库设计》由会员分享，可在线阅读，更多相关《02_关系型数据库设计（28页珍藏版）》请在金锄头文库上搜索。

1、1 第2章关系数据库设计 2 要点 本章将从学生成绩管理数据库实例入手介绍关系数据库的设计方法和相关理论 1 数据库系统需求分析 2 数据库设计 3 数据库的设计规范 4 关系数据库设计示例 5 数据库设计小结 2 1数据库系统需求分析2 1 1系统功能分析2 1 2数据库需求分析 2 2数据库的设计2 2 1用户需求分析2 2 2概念结构设计2 2 3逻辑结构设计2 2 4物理结构设计 2 3数据库的设计规范2 3 1第一范式2 3 2第二范式2 3 3第三范式2 3 4第四范式 2 4关系数据库设计示例2 4 1系统功能分析2 4 2系统需求分析2 4 3数据库功能分析2 4 4数据库设计

2、 2 5数据库设计小结 3 2 1数据库系统需求分析 1 数据库系统的系统功能分析数据库设计的最初阶段 必须对用户的需求有十分清楚的了解 针对未来用户对数据的要求是什么这一问题 设计前必须与用户进行深入的沟通 与有经验的设计人员交流是十分重要的 2 数据库需求分析数据库的需求分析是建立在整个系统的需求基础上的 所以前期的系统需求调研十分重要 4 2 2数据库设计 数据库设计的步骤包括用户需求分析 概念结构设计 逻辑结构设计和物理结构设计四个阶段 用户需求分析就是对现实世界的了解 概念结构设计是根据用户需求设计的数据库模型 也称它为概念模型 概念模型可用实体联系模型 E R模型 表示 逻辑结构设

3、计是将概念模型转换成某种数据库管理系统 DBMS 支持的数据模型 转换为关系数据库的二维表 物理结构设计是为数据模型在设备上选定合适的存储结构和存取方法 5 只要将所有的属性表示为不可分的数据项 转化后的关系即符合第一范式 即下图所示 第一范式示意图 2 3数据库的设计规范 1 第一范式 1NF 在一个关系中 要满足关系模型的基本性质 消除重复字段 且各字段都是不可分的基本数据项 如图 6 2 第二范式 2NF 所谓第二范式 指的是一种关系不仅满足第一范式 而且所有非主关键字完全依赖于其主关键字 例 P28表2 5 用符号 来表示依赖关系 例如 学号 院系 就表示院系依赖于学号 课程号 学分

4、就表示学分依赖于课程号 选择题 一个关系模式为Y X1 X2 X3 X4 假定该关系存在如下函数依赖 X1 X2 X1 X3 X1 X4 则该关系属于第二范式 因为它存在着完全依赖关系 即所有的非主属性x2 x3 x4都完全依赖于任一个候选关键字x1 7 带来问题的原因是 非主属性 学分 仅仅依赖于 课程号 也就是说只是部分依赖于主关键字 学号 课程号 而不是完全依赖 出现冗余等诸多问题 改造成下图后 为第二范式 8 第二范式 表的关系不仅满足第一范式 即最基本不可再分字段 且所有非主关键字完全依赖于其主关键字 主关键字 复合主关键字 上图中 除去学分 和学号无关 却完全依赖于课程代码 及综合

5、成绩 其他项派生的 字段后 全部非学号字段 均和复合主关键字段有关系 或者说 全都完全依赖复合主关键字 右图中 课程名称和学分是完全依赖于课程代码这个主关键字的 所以这两个图所表示的关系都是属于第二范式的情况 删除此两项内容 看我们在下面给出的数据库表中 将课程专门做为一个表来进行一个设计 就是为保证满足第二范式的要求 9 3 第三范式 3NF 关系模型在第二范式的基础上 如果关系模式中的所有非主属性对任何候选关键字都不存在传递依赖 则称这个关系就是第三范式 分解关系 院系名称和地址属于院系编号 而后者又依赖于学号 第三范式必须消除这种传递依赖 固分解 看我们在下面所设计的数据库表中 将院系表

6、 专业表都专门做为一个表来设计 就是为保证满足第三范式的要求 10 4 第四范式这个范式也被称为Boyce Codd范式 在关系数据库中 除了函数依赖之外还有多值依赖 联接依赖的问题 这就是第四范式所要规范的问题 如果关系模式R U F 的所有属性 包括主属性和非主属性 都不传递依赖于R的任何候选关键字 那么称关系R是属于BCNF的 如果不符合第四范式的规则 会给插入和删除元组等操作带来麻烦 示例如下图 11 学生和选课表 学生表 选课表 我们再进行数据表设计时 往往都将学生基本情况表做为一个表 将学生成绩表做为单独的专门的另一个表 同理还再设计一个单独的 专门的学生健康表 而这几张表间的联系

7、就是学号 12 总结范式 第一范式 每个属性都是不可再分的 即 每个属性必须包含可能的最小数据元素 第二范式 关系首先满足第一范式 所有的其他属性还必须完全依赖于主键 而不仅仅是只依赖组合主键的一部分 第三范式 关系必须满足第一范式和第二范式 所有的其他属性之间必须相互独立 但都和组合主属性有关 但可以是和组合主属性其中的部分有关 取消任何和主属性无关的属性 第四范式 一定不能存在有依赖于非主属性的属性 即使这个被依赖的非主属性是依赖于主属性的 即 不允许有传递依赖 联接依赖存在 结论 四个范式要求依次提高 应满足的约束条件也依次更加严格 1NF到BCNF的四种范式之间有如下关系 BCNF包含

8、了3NF 3NF包含了2NF 2NF包含了1NF 13 P44 选择题 1 一个关系模式为Y X1 X2 X3 X4 假定该关系存在如下函数依赖 X1 X2 X1 X3 X1 X4 则该关系属于第二范式 因为它存在着完全依赖关系 有一个学生关系 其关键字为学号 一个课程关系 其关键字为课程号 另有一个选修关系 其关键字为 学号和课程号的组合 则学号和课程号分别为选修关系的外键 包含在任何一个候选关键字中的属性称为主属性 不包含在任何一个候选关键字中的属性称为非主属性 4 一个学生可以同时借阅多本图书 一本图书只能由一个学生借阅 学生和图书之间为一对多的联系 5 关系中的元组和属性分别对应二维表

9、中的行和列 数据库表设计 14 2 4 关系数据库设计示例 P27 建立学生成绩管理系统的主要目的是通过系统 1 系统介绍及应有的功能分析 1 进行学生成绩录入 2 修改与管理 3 方便地查询到各种分析报告和成绩单 4 系统还要考虑对成绩管理严格的权限分配 有输入数据 录入成绩功能 有编辑 修改数据功能 数据检索功能及输出功能 例如 查询出个人分数 整体分数分布 最高 最低分数等情况 保证数据的安全性 15 2 系统需求分析 录入和维护学生的各种成绩 生成数据库数据 对不及格学生的处理信息 按照各种方式方便的浏览成绩 如按科目 按班级 按院系 按专业和按个人等 对各科考试进行统计分析 例如 进

10、行总分 平均分 最高 最低分数 优秀率 及格率的统计分析 能够输出各种成绩单和统计报表 以及成绩走势图等 重修成绩管理 根据重考的成绩刷新相关课程的成绩 相关课程的教师和管理员对成绩进行维护 成绩的维护应有严格的时间限制 例如 一定的时间后 教师不能修改学生成绩 如果必须要修改 只能通过管理员修改 并详细记录修改结果 修改原因 修改时间等 16 3 数据库需求分析 因为要做数据分析和统计 所以需要学生的基本信息 例如学号 姓名 性别 班级 照片 简历 专业和院系等信息 是统计数据的基本信息来源 学生相关表 考虑对数据库的操作需要 设置课程 院系和专业数据信息 它们分别包括课程代码及名称 课程学

11、分 院系代码及名称 电话 以及专业代码及名称 说明 课程 专业 院系相关表 还要做成绩录入 为以后的成绩分析做好前期数据信息的准备 所以成绩要保存在数据库中 数据信息应包括学生的学号 考试课程代码和成绩属性 对成绩有约束条件 不得超过100分 成绩表 考虑给学生补考的机会 所以需要学生补考的信息 应该包含学号 课程代码和补考成绩 补考库 17 4 数据库设计 1 实体集的设计 共需设计6个实体 或者说表 学生基本信息实体 学生基本信息 实体具有的属性学号 姓名 性别 籍贯 出生年月 班级 专业 院系 还可以增加备注 照片和简历 成绩实体 成绩 实体具有学号 课程代码 期中成绩 平时成绩 期末成

12、绩 综合成绩和学分等属性 补考成绩实体 补考 成绩实体具有学号 课程代码 分数和学分等属性 专业实体 专业 实体具有专业代码 专业名称和专业介绍属性 院系实体 院系 实体具有院系代码 名称等属性 还可以增加办公位置 联系电话等属性 课程实体 课程 实体具有课程代码 名称 学分等属性 18 2 建立E R图实体和属性E R图 一个实体具有多个属性 实体和联系E R图 如 学生通过浏览和成绩建立联系 学生通过补考和成绩建立某种联系 属性 实体 19 实体间联系学生与成绩之间的关系 一对多 一名学生有几门考试成绩 补考成绩和成绩间关系 一对一 一个不及格成绩对一个补考成绩 课程与成绩间的关系 一对多

13、的关系 一门课程有多个成绩 课程与补考成绩间的关系 一对多的关系 一门课程有多个补考成绩 学生和专业间的关系 多对一的关系 多名学生就读一个专业 学生与院系间的关系 多对一的关系 多名学生隶属于一个学院或系 20 3 E R模式到二维表的转换 数据模式转化为表的结构 21 E R模式到二维表的转换实例 成绩表 22 4 检查数据库的规范性 应用第一范式检验学生成绩管理中的表在学生基本信息关系中 没有可再分的属性 满足第一范式要求 在其他关系中 没有可再分的属性 应用第二范式再检验学生成绩管理中的表成绩关系 学号 课程代码 平时成绩 期中成绩 期末成绩 综合成绩 学分 其中 主键为组合关键字 学

14、号 课程代码 学分不完全依赖于这个组合主键 只依赖于主键的部分内容 课程代码 这个关系就不符合第二范式 23 使用以上关系模式至少存在以下几个问题 产生数据冗余 更新异常 插入异常 删除异常 解决方法 见P8 将原有关系分成两个关系模式 分别是成绩关系 学号 课程代码 平时成绩 期中成绩 期末成绩 综合成绩 和课程关系 课程代码 课程名称 学分 新的成绩关系和课程关系之间通过成绩中的外码 外关键字 课程代码与课程的课程代码相联系 在需要时进行自然联接 可以恢复原有的关系 补考成绩关系也存在同样问题 24 改进的E R图 改进的关系表 25 应用第三范式检查学生成绩管理的设计 在成绩表中主键 关

15、键字 为组合关键字 学号 课程代码 平时成绩 期中成绩 期末成绩依赖于主键 而综合成绩不依赖于主键 而依赖于平时成绩 期中成绩 期末成绩 为了满足第三范式 可以删除综合成绩属性 第四范式是属性的多值依赖范式学生成绩管理中的关系相对简单 不存在多值依赖关系 不再讨论 26 2 5数据库设计小结 主要步骤如下 数据库系统需求分析 数据需求分析 设计数据模式 E R图 数据模式转化为表 对表和模式进行第一范式规范 检查是否符合第二范式并修正关系 用第三范式规范关系 如果存在组合多值依赖传递关系 还要规范其满足第四范式 27 P44 选择题 1 一个关系模式为Y X1 X2 X3 X4 假定该关系存在

16、如下函数依赖 X1 X2 X1 X3 X1 X4 则该关系属于第二范式 因为它存在着完全依赖关系 有一个学生关系 其关键字为学号 一个课程关系 其关键字为课程号 另有一个选修关系 其关键字为 学号和课程号的组合 则学号和课程号分别为选修关系的外键 包含在任何一个候选关键字中的属性称为主属性 不包含在任何一个候选关键字中的属性称为非主属性 4 一个学生可以同时借阅多本图书 一本图书只能由一个学生借阅 学生和图书之间为一对多的联系 5 关系中的元组和属性分别对应二维表中的行和列 请看 新的上机题布置 及第一 二章基本概念题 28 第2章章节内容总结 2 1数据库系统需求分析2 1 1系统功能分析2 1 2数据库需求分析 2 2数据库的设计2 2 1用户需求分析2 2 2概念结构设计2 2 3逻辑结构设计2 2 4物理结构设计 2 3数据库的设计规范2 3 1第一范式2 3 2第二范式2 3 3第三范式2 3 4第四范式 2 5数据库设计小结 2 4关系数据库设计示例2 4 1系统功能分析2 4 2系统需求分析2 4 3数据库功能分析2 4 4数据库设计