adb03_2_数据库设计_数据库设计过程.pptVIP

（2）扩展ER模型转换到关系模型 弱实体转换 每个强实体转换为一个关系模式，强实体的属性成为关系模式的属性，实体标识成为主码 每个弱实体转换为一个关系模式，并加入所依赖的强实体的标识，关系模式的主码为弱实体的标识加上强实体的标识 子类转换 父类实体和子类实体都各自转换为关系模式，并在子类关系模式中加入父类的主码，子类关系模式的主码设为父类的主码 ER模型转换例子 转换实体 实体转换为关系模式： 1、部门（部门号，部门名） 2、职工（职工号，姓名） 3、项目（项目号，项目名） 4、领导者（奖金，车型） 5、子女（姓名，出生日期） 先考虑弱实体“子女”，加入“职工号”，并修改主码为“职工号＋姓名” 5、子女（姓名，出生日期，职工号） 在考虑子类“领导者”，加入父类标识“职工号”作主码 4、领导者（奖金，车型，职工号） 转换联系 实体转换得到关系模式： 1、部门（部门号，部门名） 2、职工（职工号，姓名） 3、项目（项目号，项目名） 4、领导者（奖金，车型，职工号） 5、子女（姓名，出生日期，职工号） 考虑每个联系： 1、部门:领导者（1:1）：领导者（奖金，车型，职工号，部门号，任职时间） 或者 部门（部门号，部门名，职工号，任职时间） 2、部门:职工（1:N）：职工（职工号，姓名，部门号） 3、职工:项目（1:1）：项目（项目号，项目名，职工号） 4、职工:项目（M:N）：增加模式：职工_项目（项目号，职工号，天数） 得到初步的关系数据库模式 部门（部门号，部门名） 职工（职工号，姓名，部门号） 项目（项目号，项目名，职工号） 领导者（奖金，车型，职工号，部门号，任职时间） 子女（姓名，出生日期，职工号） 职工_项目（项目号，职工号，天数） 3、关系数据库模式的规范化 确定范式级别 实施规范化处理 （1）确定范式级别 范式级别的确定 根据数据依赖确定已有的范式级别 根据需求写出数据库模式中存在的所有函数依赖 消除冗余数据依赖，求出最小的依赖集 确定范式级别 （1）确定范式级别 范式级别的确定 根据实际应用的需要（处理需求）确定要达到的范式级别 时间效率和模式设计问题之间的权衡 范式越高，模式设计问题越少，但连接运算越多，查询效率越低 如果应用对数据只是查询，没有更新操作，则非BCNF范式也不会带来实际影响 如果应用对数据更新操作较频繁，则要考虑高一级范式以避免数据不一致 实际应用中一般以3NF为最高范式 （2）规范化处理 确定了初始数据模式的范式，以及应用要达到的范式级别后 按照规范化处理过程，分解模式，达到目标范式 4、模式评价 检查规范化后的数据库模式是否完全满足用户需求，并确定要修正的部分 功能评价：检查数据库模式是否支持用户所有的功能要求 必须包含用户要存取的所有属性 如果某个功能涉及多个模式，要保证无损连接性 性能评价：检查查询响应时间是否满足规定的需求。 由于模式分解导致连接代价 如果不满足，要重新考虑模式分解的适当性 可采用模拟的方法评价性能 5、模式修正 根据模式评价的结果，对已规范化的数据库模式进行修改 若功能不满足，则要增加关系模式或属性 若性能不满足，则要考虑属性冗余或降低范式 合并：若多个模式具有相同的主码，而应用主要是查询，则可合并，减少连接开销 分解：对模式进行必要的分解，以提高效率 水平分解 垂直分解 （1）水平分解 80/20原则：一个关系经常被使用的数据只占20% 如果多个处理存取关系R的数据集不相交，则可将R水平分解为多个关系，每个关系的模式名不同，但属性集相同 减少了应用处理的数据量，提高效率 （1）水平分解 学号 …… 所在系 01 1 02 2 03 6 …… …… 学号 …… 所在系 01 1 12 1 13 1 …… …… 学号 …… 所在系 02 2 18 2 45 2 …… …… （2）垂直分解 把关系模式按属性集垂直分解为多个模式 在实际中，应用可能经常存取的只是关系的某几个列，可考虑将这些经常访问的列单独拿出组成一个关系模式 若一个关系中，某几个属性的值重复较多，并且值较大，可考虑将这些属性单独组成关系模式，以降低存储空间 （2）垂直分解 职工号 …… 住房平面图 住房平面图编号 住房平面图 职工号 …… 住房平面图 编号 6、设计用户子模式（视图） 根据局部应用的需求，设计用户子模式 外模式1 外模式2 外模式3 概念模式 用户1 用户2 用户3 （1）设计用户子模式（视图）的考虑 使用更符合用户习惯的别名 ER图集成时要消除命名冲突以保证关系和属性名的唯一，在子模式设计时可以重新定义这些名称，以符合用户习惯 给不同级别的用户定义不同的子模式，以保证系统安全性 产品(产品号，产品名，规格，单价，产品成本，产品合格率) 为一般顾客建立子模式：产品1(产品号，