数据库原理与数据仓库技术_4数据库设计.pptVIP

第3范式 定义： 如果一个关系模式 RU,F中每一个非平凡的函数依赖 X→Y，都有X是R的码，或者Y的每个属性都是主属性，那么称R是3NF的模式 含义： 符合第3范式的关系模式R中的每一个非主属性既不部分依赖也不传递依赖于码。 举例：学生所属：SL(Sno,Sdept,Sloc) Sloc传递依赖于码（Sno） 第3范式 解决方法：分解关系 举例：学生所属：SL(Sno,Sdept,Sloc) 分解结果 关系模式SD（Sno,Sdept） 关系模式DL(Sdept,Sloc) BC范式 定义： 设R是一个关系模式，如果对于每个非平凡的函数依赖X→Y，X都含有码，则称关系模式R满足Boyce-Codd范式，简称BC范式，记为R∈BCNF。 含义： 所有的非主属性都完全函数依赖于每个候选码 所有主属性都完全函数依赖于每个不包含它的候选码 没有任何属性完全函数依赖于非主属性 BC范式可以理解成修正的第3范式 BC范式 举例： 设有关系模式SCT（S,C,T），其中，S表示学号，C表示课程号，而T表示教师。 SCT中有以下语义： 每个教师仅上一门课程； 学生与课程的关系确定之后，教师即唯一确定。 因此 （S,C）与（S,T）都是候选码 SCT中存在部分函数依赖关系（S，C）→T 解决方法：分解关系 分解结果：关系SC(S,C)和关系CT(C,T) 第4范式 举例： 雇员关系模式中employees(ID,skill,language) 关系employees ? BC范式，因为该关系的候选码是全码（ID,skill,language）。 问题： 数据冗余很多 数据操作复杂 原因：存在新的数据依赖：多值依赖 雇员 技能 语言 Brown 烹调 法语 Brown 烹调 德语 Brown 打字 法语 Brown 打字 德语 第4范式 多值依赖： 定义：设R(U)是一个属性集U上的关系模式，X,Y和Z是U的子集，并且Z=U-X-Y。多值依赖X →→Y成立,当且仅当对R的任一关系r,r在（X,Z）上的每个值对应一组Y值，这组值仅仅决定于X值而与Z值无关。 举例： 雇员关系模式中employees(ID,skill,…) 一个雇员可能具有多种技能，一个ID对应多个skill。称skill多值依赖于ID,即 ID →→ skill 若X→→Y,而Z=?，则称X→→Y为平凡的多值依赖；否则称X→→Y为非平凡的多值依赖。 第4范式 定义： 若关系模式R（U,F）∈1NF,如果对应R的每一个非平凡多值依赖X→→Y（Y?X），X都含有候选码，称R（U,F）∈4NF 含义：满足4NF的关系模式至少有以下之一成立 X→→Y是一个平凡的多值依赖 X是关系模式R的超码（含有候选码） 本质： 就是关系中不能包含关于一个实体的两个或者更多独立的多值事实。 第4范式 举例： 雇员关系模式中employees(ID,skill,language) 由于： ID →→ skill是非平凡多值依赖 ID不是关系R的候选码 因此： 雇员关系模式employees不符合4NF 雇员 技能 语言 Brown 烹调 法语 Brown 烹调 德语 Brown 打字 法语 Brown 打字 德语 第4范式 解决方法：分解关系 雇员技能关系 Employee_skill 雇员语言关系 Employee_language 雇员 技能 语言 Brown 烹调 法语 Brown 烹调 德语 Brown 打字 法语 Brown 打字 德语 雇员 技能 Brown 烹调 Brown 打字 雇员 语言 Brown 法语 Brown 德语 规范化实质 一个属于低级范式的关系可以分解转换成若干个高一级范式的关系模式 规范化可以消除数据依赖中不合适的部分 规范化是利用单一的概念进行关系模式设计 一个关系描述一个概念 规范化过程 1NF ↓ 消除非主属性对码的部分依赖 2NF ↓ 消除非主属性对码的传递依赖 3NF ↓ 消除主属性对码的部分依赖与 传递依赖 BCNF ↓ 消除非平凡且非函数依赖的多值依赖 4NF 数据库设计要点 1.E-R模型和规范化 由E-R图生成的关系模式应该不需要太多的规范化 不太好的E-R图设计容易引起实体的属性之间可能存在函数依赖 一个多对多的联系或者实体集的一个多值属性容易引起产生不符4NF的关系模式 2.属性和联系的命名 每个属性名有唯一的含义 避免不同关系中的属性取相同的属性名 例如：避免贷款编号同客户账户号进行连接误操作。 采用统一的命名规则 数据库设计要点 3.规范化的解除 为了性能（冗余可以提高性能） 反规范化在需要高性能的只读数据库