数据库第章数据库物理模型PPT课件.ppt

第五章数据库物理模型设计 学习概念数据模型或逻辑数据模型转换为物理数据模型的方法 了解如何将实体的1 1 1 N和N M关系表示为表关系了解数据库设计范式和规范化通过实践案例学习从概念数据模型转换物理数据模型的一般步骤 学习目标 一 数据库模型转换 5 1数据库设计模型转换 数据库设计分为概念数据模型设计 逻辑数据模型设计 物理数据模型设计三个层次 在常规的数据库设计中 将依次对这三种模型进行转换设计 各个模型之间的元素对应关系如下表 二 数据模型转换方案 数据模型转换设计有两种方案一种是由概念数据模型生成对应的逻辑数据模型 再从逻辑数据模型转换生成物理数据模型 另一种是从概念数据模型直接转换为对应的物理数据模型 数据模型之间转化 概念数据模型 CDM 物理数据模型 PDM 现实世界 转化 逻辑数据模型 LDM 转化 转化 抽取 当使用关系数据库时 物理数据模型即为关系模型 其基本转换原理如下 1 将每一个实体转换成一个表 实体的属性转换为表的列 实体的标识符转换为表的主键2 将实体关系转化为表间的参照完整性约束 即通过设置外键来参照主键 根据关系的不同类型 通过外键参照主键的方式有所不同 数据模型转换 表 表是数据库中用来保存信息的一种数据结构 由数据模型中的实体转化而来 一个表中记录着关于实体的信息 它是数据库组织的基本对象 2 列 列是组成表的基本单位 由数据模型中的属性转化而来 一个表由多个列组成 每个列都有一个数据类型 三 将实体转化为表 主键是用来唯一标识表中每个记录的一个或多个列的集合 由数据模型中的主标识符转化而来 在物理数据模型中 每张表必须有一个主键 主键通常用pk表示 候选键也是用来唯一标识表中记录的一个或多个列的集合 通常由数据模型中的次标识符转化而来 候选键通常用ak表示 3 主键与候选键 外键是与其它表连接的公共列 这个列通常是其它表的主键 外键一般是由数据模型中的实体关系产生 外键通常用fk表示在系统物理数据模型设计中 对上述基本数据库对象进行设计外 还包括数据库的存储过程 触发器 视图 索引 约束规则等设计 4 外键 将实体转换为表 首先 为每个实体定义一个表 表名与实体名相同 将实体的标识符作为表的主键 然后 实体的属性转换为表中的列 实体的标识符转换为表的主键 确定代理键 在关系数据库设计中 当数据表中的候选键都不适合当主键时 例如 候选键的内容太大或者复合候选键包含的属性太多 就会定义代理键作为主键 代理键由DBMS自动生成数字键值 且永不改变 定义列的特性 实体属性转换为表的列后 必须为每个列指定其特性 包括数据类型 空值状态 默认值及数值的约束 数据类型 每个DBMS都有自己的数据类型定义 对于每一列 应指明在该列中存储何种类型的数据 空值状态 在表中插入新行时 某些列必须有值 对于这样的列 将其标注为NOTNULL 某些列允许不输入值 将其标注为NULL 默认值 默认值是指当插入新行时 如果用户没有显式输入某个列的值 则由DBMS自动设置为预先设定的值 数值的约束 一些列中的数据值可能有限制 这些限制称为数据约束 数据模型转换数据库设计步骤 为每个实体创建一个表 规范化所有表 创建表之间的主外键约束 概念模型 关系模型 物理模型 第1步 第2步 第3步 四 弱实体的转换表示 前面描述的实体转换为表的过程适用于所有的实体类型 但弱实体有时候需要特别的处理 弱实体在逻辑上依赖于另一个实体 非ID依赖弱实体 ID依赖弱实体的标识符应该含有它所依赖实体的标识符 因此需要将被依赖实体的标识符放入ID依赖弱实体转换生成的表中 和ID依赖弱实体的标识符共同转换成复合主键 ID依赖弱实体 五 实体关系的转换表示 1 1实体关系的转换 我们可以有两种转换方案 一种是将学生表的主键 学号 放入助研金账号表中做外键 另一种是将助研金账号表的主键 账号 放入学生表中做外键 这两种方案均是可行的 由设计者根据应用情况自主做出选择 1 N实体关系的转换 1 N实体关系的转换方法很简单 两个实体分别转换为表 然后将父实体表的主键放入子实体表中做外键 将图5 9所示的实体关系转换为表参照约束 M N实体关系的转换 N M实体关系不能像1 1和1 N实体关系那样直接转换 将任一个实体表的主键放置到另一个实体表中做外键都是无法实现的 必须要重新产生一张新表 用于表示两个实体之间的关系 新表的名称通常有两种命名方法 一种是以N M关系的名称命名 一种是用下划线连接N M关系两侧的实体名称作为新表的名称 实体继承关系的转换 当实体继承关系转换到物理数据模型时 首先父实体和子实体都各自转换为表 其属性均转换为表的列 在处理继承关系转换时 将父表中的主键放置到子表中 既做主键又做外键 实体递归关系的转换 对于1 N的实体递归关系转换 首先将递归实体转换为表 其属性转换为列 标识符转换为主键 这些处理方式和前面描述的两个实体间的转换时一致的 实体递归关系处理的特殊性在于关系连接的是同一个实体 我们可以理解为要在同一个表对象间去实现这种关系 因此 在逻辑上将顾客表看做两张表 按照前面阐述的1 N实体关系处理方法 将1侧表的主键放入N侧表中做外键 对于M N的实体递归关系 是指在同一个实体间所发生的多对多关系 例如 医生 实体间的M N实体递归关系 每个医生都可能会给其他医生看病 自己也可能接受其他医生的治疗 这是一个多对多的实体递归关系 按照前面对N M实体关系的转换处理 将关系两侧的实体分别转换为表 还要派生出一个新的关联表 其表名是关系的名称 5 2数据库表规范化设计 数据库表规范化设计是指在数据库中减少数据冗余和定义一个规范的表间结构 实现数据完整性与一致性 所谓数据冗余是指一组数据重复出现在数据库的多个表中 在数据库设计中 尽量避免表间的重复数据列 规范化数据库设计为数据库系统带来如下益处 冗余数据被消除 同一数据在数据库中仅保存一份 有效降低维护数据一致性的工作量 设计合理的表间依赖关系和约束关系 便于实现数据完整性和一致性 设计合理的数据库结构 便于系统对数据高效访问处理 一 函数依赖理论 函数依赖 FunctionalDependency 是数据依赖的一种 它反映属性或属性组之间相互依存 互相制约的关系 即反映现实世界的数据约束关系 在函数依赖理论中 定义下列符号 R表示一个关系的模式 U A1 A2 An 是R的所有属性的集合 F是R中函数依赖的集合 r是R所取的值 t X 表示元组t在属性X上的取值 函数依赖的定义 定义 设有一关系模式R U X和Y为其属性U的子集 即 设t s是关系R中的任意两个元组 如果t X s X 则t Y s Y 那么称Y函数依赖于X 或X函数决定Y 也可称在关系模式R U 上成立 一个函数依赖要能成立 不但要求关系的当前值都能满足函数依赖条件 而且还要求关系的任一可能值都能满足函数依赖条件 对于当前关系r的任意两个元组 如果X值相同 则要求Y值也相同 即有一个X值就有一个Y值与之对应 或者说 Y值由X值决定 因而这种依赖称为函数依赖 2020 1 27 31 部分函数依赖 属性传递依赖 多值依赖 二 规范化范式 范式 NormalForma NF 是指关系表的规范程度状态 范式的种类与数据依赖有着直接的联系 在关系模式中存在函数依赖时就有可能存在数据冗余 引出数据操作异常现象 数据冗余不仅浪费存储空间 而且会使数据库难以保持数据的一致性 范式可以用于确保数据库模式中没有各种类型的异常和不一致性 规范化是把一组有异常的关系分解成更小的 结构良好的关系的过程 使得这些关系有最小的冗余或没有冗余 规范化是决定关系中属性如何分组的一个形式化过程 理论上讲 关系数据库有六种范式 第一范式 1NF 第二范式 2NF 第三范式 3NF 巴斯 科德范式 BCNF 第四范式 4NF 和第五范式 5NF 满足最低要求的范式是第一范式 1NF 在第一范式的基础上进一步满足更多要求的称为第二范式 2NF 其余范式以次类推 高级范式总是包含了低级范式的全部要求 第1规范式 1NF 如果关系中的属性不可再细分 该关系满足第1范式 第2规范式 2NF 如果关系满足第1范式 并消除了关系中的属性部分依赖 该关系满足第2范式 例有一个关系 A B N O P 其复合主键为 A B 那么N O P这三个非键属性都不存在只依赖A或只依赖B情况 则该关系满足第2范式 反之 不满足第2范式 第3规范式 3NF 如果关系满足第2范式 并切断了关系中的属性传递依赖 该关系满足第3范式 例若有一个关系 A N O P 主键为 A 那么非键属性N O或P都不能由单个的N O或P或它们的组合所确定 该关系满足第3范式 BCNF范式 在关系中 所有函数依赖的决定因子都是候选键 该关系满足BCNF范式 例 关系STUDENT StudentNum Name Email 中 决定因子StudentNum也是候选键 该关系满足BCNF范式 第4规范式 4NF 如果关系满足BCNF范式 并消除了多值依赖 该关系满足第4范式 多值依赖 假设关系模式为R A B C 其中A B为主键属性 如果在A取特定值 而在B上取值的集合与在C上取值的集合无关 则称多值依赖 例 设学校中某一门课程由多个教师讲授 他们使用相同的一套参考书 用关系模式Teaching Course Teacher Book 来表示课程 教师和参考书之间的关系 该关系Teaching Course Teacher Book 属于BCNF范式 但是它存在以下问题 1 数据冗余度大 有多少名任课教师 课程名 参考书名就要存储多少次 2 增加操作复杂 当某一课程增加一名任课教师时 该课程有多少本参考书 就必须插入多少个元组 3 修改操作复杂 某一门课程要修改一门参考书 该课程有多少名教师 就必须修改多少个元组 产生这些问题的原因是参考书和教师的取值彼此独立 它们都只取决于课程名 也就是存在多值依赖 练习 学生关系规范化 问题 它满足第1范式 第1规范式 如果关系中的属性不可再细分 该关系满足第1范式 学生关系现在满足第1范式 本关系不满足1范式 因为 联系方式 属性可以再细分 电话 电子邮件 等 问题 它满足第2范式吗 第2规范式 如果关系满足第1范式 并消除了关系中的属性部分依赖 该关系满足第2范式 分析 主键 学号 课程号 学号 系名 学号 住址存在部分依赖 不满足第2范式处理办法 对学生关系进行分解 学生 关系和 课程成绩 关系均满足第2范式 问题 它满足第3范式吗 第3规范式 如果关系满足第2范式 并切断了关系中的属性传递依赖 该关系满足第3范式 分析 学号 系名 系名 住址 故 学号 住址 存在传递依赖 不满足第3范式 处理办法 对学生关系再进行分解 学生 系信息 课程成绩 关系均满足第3范式 问题 它满足BCNF范式吗 学生 系信息 课程成绩 关系均满足BCNF范式 问题 它满足第4范式吗 BCNF范式 在关系中 所有函数依赖决定因子都是主键 该关系满足BCNF范式 分析 系编号 办公电话 系编号 学生住址 而系办公电话与学生住址不相关 学生住址可能有多处 故存在多值依赖 不满足第4范式处理办法 对 系信息 关系进行分解 第4规范式 如果关系满足BCNF范式 并消除了多值依赖 该关系满足第4范式 各关系均满足第4范式 三 反规范化处理 规范化减少了数据冗余 易于保证数据的完整性 但规范化也会导致数据库性能降低 因此 在利用规范化设计数据库时要平衡两者的关系 规范化带来结构的完整和精确性 但同时也可能带来负面的效果 也正是基于此 人们提出了反规范化设计的基本思想 所谓的反规范化 就是适当降低甚至抛弃范式约束 不再要求一个表只表述其表自身 而是适当冗余性添加带有某种依赖关系的数据 反规范化处理的主要手段有如下2种 1 增加冗余列或派生列如果应用系统的常用操作需要关联其他表中的数据 则在进行表设计时 应直接将该列融入当前表中 使其冗余存在 称为冗余列 2 表的合并和分割 执行反规范化设计 表的数量往往也就会减少 而这也就降低了表连接运算的压力 可以有力提升性能 但反规范化的使用也会带来以下问题 1 数据冗余的存在 2 降低了数据库的完整性 反规范化是把双刃剑 并不具有普遍意义 需要就事论事 用不好会伤及自身 5 3PowerDesigner项目实践 在第四章中我们设计并完成了图书馆管理系统概念模型设计 最终得到如下的概念数据模型设计图 一 CDM到LDM转换设计 在PowerDesigner建模工具中 点取 Tools GenerateLogicDataModel 菜单 可以实现将当前概念数据模型自动转换为逻辑数据模型 由建模工具将CDM模型自动转换得到的LDM模型 并不一定是理想的逻辑数据模型设计 系统设计者还需要对自动转换得到的LDM模型进行完善设计 二 CDM到PDM转换设计 在PowerDesigner建模工具中 点取 Tools GeneratePhysicalDataModel 菜单 可以实现将当前LDM模型 或CDM模型 自动转换为物理数据模型 三 系统PDM模型设计检查 在将系统物理