第3讲数据库设计.pptVIP

映射EER扩展结构－－类层次结构 映射处理EER图中的ISA层次结构。 假设超类C被特化为m个子类{S1 , … , Sm} Attr(C) = {k, a1 , … , an}，PK(C) = k。 方法1：映射超类和每个子类到一个不同的表。 映射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子类对应的关系表时，通常需要指定一个新的键属性--代理键(surrogate key)。 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 模式求精问题（综述） 模式求精的基本任务是基于分解技术，来处理初始关系模式中存在的问题。信息的冗余存储是引发这些问题的根源。虽然分解能删除冗余，但它也可能导致一些额外的问题，如信息损失或导致某些强制性约束丢失，必须慎重使用。 （一）冗余可能引发问题 浪费空间。 更新异常。 同样的信息被存储多份，如某份数据被更新，而其它份信息未做相应更新，就会造成DB数据的不一致。 插入异常。 如果不附带冗余存储一些相关的信息，新的信息可能无法存储到DB中。 删除异常。 删除某信息时,可能会附带删掉一些不希望删除的信息。 冗余可能引发问题举例 考虑Hourly_Emps (ssn, name, lot, rating, hourly_wages, ours_worked) 缩写为Hourly_Emps (SNLRWH) 假定小时工资主要取决于员工等级，即给定R值，就可唯一确定W值。这是一个典型的函数依赖约束关系，它会导致存储冗余，其副作用有多个方面： 同等级员工对应的元组中，R/W信息完全相同。同样的信息被存储多次，浪费存储空间。 如果删除了给定R值的所有元组，将丢失这组R/W所隐含的IC约束信息，这是一种删除异常。 无法单独记录员工等级与小时工资的R/W关系。这是一种插入异常。 （二）利用分解技术消除冗余 函数依赖约束(FDs)或其它相近的ICs可被用来识别冗余点，并给出处理冗余的指导性建议。 分解技术的核心思想 通过将原关系替换（分解）为一组更小关系，来解决冗余问题。 例如，通过将Hourly_Emps分解为如下的两个小关系，就可以很好消除原有冗余引起的相关问题。 Hourly_Emps2(ssn, name, lot, rating, hours_worked) Wages( rating , hourly_wage) （三）分解可能引发的相关问题 分解能很好解决冗余问题，但必须慎重使用，否则可能会带来其它问题。在使用分解时，须反复提问以下两个重要问题： 我们的确需要分解一个关系吗？ 对该问题，已有若干规范来帮助回答这个问题。 一个给定的分解会引起那些其它问题？ 对该问题，可借助分解的两个重要特性来帮助回答 用无损连接(lossless-join) ； 依赖保持(dependency- preservasion) 3.4.2 函数依赖(functional dependency,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}的所有合法关系实例中，通常还会隐含一些其它可从F推理获得的函数依赖。 例如，对Workers(ssn, n