第3章_数据库设计说明

《第3章_数据库设计说明》由会员分享，可在线阅读，更多相关《第3章_数据库设计说明（56页珍藏版）》请在金锄头文库上搜索。

1、第1部分数据库系统基础第3章数据库设计 高级数据库系统及其应用 第3章数据库设计 ER数据模型 3 1 EER数据模型 3 2 逻辑数据库设计 映射ER EER模式到关系模式 3 3 关系模式求精与规范化 3 4 DB应用 DB应用定义 一个特定的数据库 加上实现此数据库查询 更新的相关程序 概念设计是成功设计DB应用的一个环节 实体 关系模型 Entity Relationmodel 简称ER模型 是一种非常流行的概念数据模型 EER是基于ER的扩展模型 EnhancedERmodel ER EER已被广泛应用于DB概念设计 它们均以图形化方式描述和捕获用户需求 基于ER EER进行概念设计

2、的输出为一组ER EER图 基于概念模型的设计 最终都必须变换 转换到可在DB中实现的逻辑数据模型 借助RDB设计有关规范理论 不仅可对转换后的逻辑数据模式进行规范 而且可对ER EER图进行求精 DB设计的主要阶段与过程 DB设计的基本步骤 1 1 需求分析2 概念DB设计利用需求分析获得的信息 建立DB数据的一个抽象描述 这一步通常利用ER EER模型 或其它高级数据概念模型 如UML类图 来实现 3 逻辑DB设计转换DB概念设计模式到指定DBMS逻辑模式 由于需求信息本身带有很大主观性 故基于需求信息构造的ER EER图只能提供数据的一个近似描述 4 模式细化5 物理DB设计6 安全设计

3、 DB设计的基本步骤 2 1 需求分析2 概念DB设计3 逻辑DB设计4 模式细化分析关系数据库模式的关系集 检查潜在问题并进行优化 与需求分析和概念设计的主观性特点不同 细化可得到强有力的规范理论支持 5 物理DB设计考虑应用必须支持的一些典型预期负荷 并以此为基础进一步求精DB设计 确保它能满足预期的性能要求 这个步骤可能包括为一些表建立索引 或指定聚集存储方式等 6 安全设计 3 1ER数据模型 3 1 1实体类型 实体集 属性和键 3 1 2关系 关系类型和关系集 3 1 3ER模型的其他特性 ER模型简介 1 构成ER模型的基本概念实体与属性实体类型 实体集与键实体类型 定义了具有相

4、同属性的实体模式结构 由名和属性来描述 实体集 具有相同实体类型的所有实体集合 实体类型描述了相同结构实体集的模式或内涵 实体集则描述了实体类型的外延 ER图中不区分实体类型和实体集 被视为同义词 关系 关系类型和关系集ER模型的其它概念 ER图表示规定实体集 用加矩形外框的名字来表示 属性名 则用椭圆框起 并用直线与实体集相连 多值属性 用双线椭圆框起 复合属性 用名字后加注结构成份表示 键属性 通过属性名加下划线来标识 ER图表示规定关系集 用名字外加菱形框表示 并用直线将其与参与实体集的矩形框相连 ER图设计举例 1 ER图设计举例 2 ER模型的其它概念 关系属性关系集也可以有自己的描

5、述属性 用来刻画关系集本身的性质 而不是某个参与实体集的性质 关系约束指与关系集相关的约束 通过约束表达可限制参与关系各实体的可能组合 主要类型 基数词约束 键约束和参与约束 弱实体集指只能附属其它实体集而存在的实体集 在ER图中表达关系基数词和参与约束 弱实体集的几种ER建模方法 图3 5 3 2EER数据模型 3 2 1EER模型核心概念的形式定义 3 2 2子类 超类与类层次结构 3 2 3特化与泛化 3 2 4利用union子类建模 3 2 5值集属性与复合结构属性的建模表示 3 2 6EER与UML类图比较 3 2 7EER作为知识表示模型 3 2 8为大型企业 组织进行DB概念设计

6、 EER核心概念 1 类指实体的集合或实体集 这包括可对DB应用域实体分组的任何EER模式构造 如实体类 型 子类 超类和类别 EER中 任何类都允许参与一个关系 子类 超类子类S是一个类 子类中的实体必然是其超类C中实体的一个子集 即有关系 S C成立超类 子类关系也称为ISA关系 记做C S 子类实体除了可以从超类实体中继承所有的属性外 还可以有自己专有的属性和关系 EER核心概念 2 特化特化Z S1 S2 Sn 是具有相同超类G的一个子类集合 每个G Si是一个超类 子类关系 G被称为泛化实体类型 用 特化 指代由特化过程所获得的 特化子集 特化的种类 约束 完全特化与部分特化 不相交

7、特化与重叠特化 两类约束相互独立 可以组合出四种约束 泛化是特化的逆过程 允许我们忽略多个实体集之间的性质差异 找出它们的共同点 抽象出超类 特化是概念上的求精 而泛化则是概念上的综合 显然 由泛化获得超类方法 易得到完全特化的子集 特化及其约束的EER表示 EER核心概念 3 类别 category 类别有时也被称为union子类 类别T是一个类 它是n个判定超类D1 D2 Dn n 1 并集的一个子集 其形式表示为 T D1 D2 Dn union子类的约束完全约束 子类包含了其所有超类并集中的所有成员 部分约束 子类只包含并集的一个子集 UNION子类及其约束的EER表示 图3 8 基本

8、ER模型与UML类图的特性对比 CompanyDB模式的EER表示 CompanyDB模式的UML表示 3 3逻辑数据库设计 映射ER EER模式到关系模式 3 3 1映射常规实体集到关系表 3 3 2映射关系集到关系表 3 3 3映射弱实体集 3 3 4映射带有聚集关系的ER图 3 3 5映射EER扩展结构 3 3 6ER模型至关系模型映射小结 3 3映射ER EER模式到关系模式 ER EER模型适合于初始阶段 抽象层次较高的DB概念设计 给定一个概念设计模式 ER EER图 现已有一套标准方法可将它们映射到关系DB模式 但这种转换还只是近似的 DB模式 一组表 约束集 基于SQL 92

9、我们尚无法捕获隐含在ER EER设计中的所有约束 本节我们将介绍从ER EER模式创建关系模式的方法和过程 映射常规实体集到关系表 一个常规实体集可直接地映射到一个关系表 将实体集的每个属性 作为关系表的一个属性 用SQL 92DDL建表语句基本上可以完全捕获这些信息 包括域约束和主键约束 映射关系集到关系表 一 映射含键约束的关系集方法1 独立关系表法映射关系集R到独立的关系表R 映射关系集到关系表 一 映射含键约束的关系集方法1 独立关系表法方法2 外键方法将关系集的相关信息合并到具有键约束的参与实体集中 一对多关系的 一 端 映射关系集到关系表 一 映射含键约束的关系集方法1 独立关系表

10、法方法2 外键方法方法3 合并关系法若关系集的所有参与实体集都有键约束且都是完全参与 这时 也可合并所有参与实体集到一个关系 二 在映射关系集时考虑参与约束图3 9 a 中的Manages 除了键约束 每部门至多有一经理 外 还含有一完全参与约束 每部门至少需要有一经理 考虑到这一点 Dept Mgr ssn应设置NOTNULL 三 无键约束和参与约束的关系集映射对这类关系集 一般只能用独立关系表法 方法1 进行映射 映射弱实体集 弱实体集总是参与一对多的二元关系 且有一个键约束和完全参与约束 前面讨论的映射关系方法2 外键法 是一种较理想的转换方法 但要考虑弱实体中只含有部分键这个情况 映射

11、EER扩展结构 多值 复合结构属性 关系模式不支持多值属性 必须为关系模式中的每个多值属性 分别创建一个独立的关系 令关系模式为R MA是R的一个多值属性 为MA创建的关系表为M M的属性应包含R的主键属性k 以便关联到R 原关系模式R中可去掉多值属性MA 令关系模式为R CA是R的一个复合属性 对于CA 有两种建模方法 方法1 将复合属性的每个结构成份 分别作为一个属性 加到所属的关系表中 方法2 为复合属性CA单独建立一个关系表 映射EER扩展结构 类层次结构 映射处理EER图中的ISA层次结构 假设超类C被特化为m个子类 S1 Sm Attr C k a1 an PK C k 方法1 映

12、射超类和每个子类到一个不同的表 映射EER扩展结构 类层次结构 方法1 映射超类和每个子类到一个不同的表 方法2 仅创建子类关系表 为每个子类Si 1 i m 创建一个关系Li 且有属性Attr Li k a1 an Si的其它专有属性 PK Li k 该方法只适用于超类完全参与的特化类型 方法3 仅创建含1个类标志属性的单个关系 方法4 仅创建含m个类标志属性的单个关系 该方法能适应子类有重叠特化的情况 但会产生大量的null值 映射EER union子类 1 1 对超类实体集有各自不同键的情况在创建与union子类对应的关系表时 通常需要指定一个新的键属性 代理键 surrogatekey

13、 2 对超类实体集有有相同键的情况这时 无需使用代理键 ER模型至关系模型映射小结 步骤1 映射常规实体集 步骤2 映射弱实体集 步骤3 映射ER模式中的关系集 步骤4 映射ER模式中的聚集关系集 步骤5 映射与EER模型相关的扩展结构 3 4关系模型求精与规范化 3 4 1模式求精问题 3 4 2函数依赖 3 4 3基本规范范式 3 4 4无损分解与依赖保持分解 3 4 5分解与规范化关系模式 3 4 6多值依赖与第四规范 3 4 1模式求精问题 综述 模式求精的基本任务是基于分解技术 来处理初始关系模式中存在的问题 信息的冗余存储是引发这些问题的根源 虽然分解能删除冗余 但它也可能导致一些

14、额外的问题 如信息损失或导致某些强制性约束丢失 必须慎重使用 一 冗余可能引发问题浪费空间 更新异常 同样的信息被存储多份 如某份数据被更新 而其它份信息未做相应更新 就会造成DB数据的不一致 插入异常 如果不附带冗余存储一些相关的信息 新的信息可能无法存储到DB中 删除异常 删除某信息时 可能会附带删掉一些不希望删除的信息 冗余可能引发问题举例 考虑Hourly Emps ssn name lot rating hourly wages ours worked 缩写为Hourly Emps SNLRWH 假定小时工资主要取决于员工等级 即给定R值 就可唯一确定W值 这是一个典型的函数依赖约束

15、关系 它会导致存储冗余 其副作用有多个方面 同等级员工对应的元组中 R W信息完全相同 同样的信息被存储多次 浪费存储空间 如果删除了给定R值的所有元组 将丢失这组R W所隐含的IC约束信息 这是一种删除异常 无法单独记录员工等级与小时工资的R W关系 这是一种插入异常 二 利用分解技术消除冗余 函数依赖约束 FDs 或其它相近的ICs可被用来识别冗余点 并给出处理冗余的指导性建议 分解技术的核心思想通过将原关系替换 分解 为一组更小关系 来解决冗余问题 例如 通过将Hourly Emps分解为如下的两个小关系 就可以很好消除原有冗余引起的相关问题 Hourly Emps2 ssn name

16、lot rating hours worked Wages rating hourly wage 三 分解可能引发的相关问题 分解能很好解决冗余问题 但必须慎重使用 否则可能会带来其它问题 在使用分解时 须反复提问以下两个重要问题 我们的确需要分解一个关系吗 对该问题 已有若干规范来帮助回答这个问题 一个给定的分解会引起那些其它问题 对该问题 可借助分解的两个重要特性来帮助回答用无损连接 lossless join 依赖保持 dependency preservasion 3 4 2函数依赖 functionaldependency FD 函数依赖 是DB中两组属性间存在的一种约束 是一类更广义的键概念约束 其形式定义如下 令R代表一个关系模式 r是R的一个任意合法实例 X和Y是R的两个非空属性子集 如果对r中每个元组对t1和t2有t1 X t2 X 则必有t1 Y t2 Y 这时 我们就称Y函数依赖于X 记为 X Y 两类特殊的函数依赖完全函数依赖与部分函数依赖通常 模式设计者会显式指定一组函数依赖 常用F表示在关系R上显式指定的一组 FDs 函数依赖推理 1 在满足F FDs 的所