【BYQ】数据库讲：数据库设计理论.docVIP

数据库设计理论 引言 如何设计数据库模式 凭经验设计？ 什么是好的关系数据库模式？ 好的关系数据库模式应该包括多少关系模式？ 每个关系模式应该包含哪些属性？ 设计数据库模式的理论和方法——规范化 学生管理数据库设计实例 事实情况 一个系有若干名学生 一个学生只属于一个系 一个系只有一名系主任 一个学生可以选修多门课程 一门课程可由多名学生选修 每个学生学了每门课程有一个成绩 属性 学生SNO 系DN 系主任DM 课程CN 成绩G 单一关系模式 UN(SNO,DN,DM,CN,G) 关系键、候选键、主键 (SNO,CN) 存在的问题 插入异常 删除异常 修改异常 冗余太大 模式分解 S(SNO,DN) D(DN,DM) SC(SNO,CN,G) 关系规范化 关系模式的分解 用几个结构简单的关系模式→结构复杂的关系模式 关系数据库模式：“不好”→“好” 函数依赖 关系模式中的数据依赖 描述关系模式的五元组R(U,D,DOM,F) F：属性间数据的依赖关系集合 描述关系模式的简化三元组R(U,F) 函数依赖示例 学生关系Student(学号Sno,姓名Sn,所在系Dn) 一旦学号确定，姓名和所在系也就唯一地确定下来了 属性间的这种依赖关系类似于数学中的函数 Sno函数决定Sn和Dn Sn和Dn函数依赖于Sno 记作Sno→Sn，Sno→Dn 函数依赖的定义 X,Y是R的两个属性集合(子集) 当任何时刻R中的任意两个元组中的X属性值相同时，则它们的Y属性值也相同 R中不存在两个元组，它们在X上的属性值相同，而在Y上的属性值不同 X函数决定Y Y函数依赖于X 记作X→Y X叫做决定因素(决定属性集) 函数依赖与属性间的联系类型有关 一对一联系：X←→Y 多对一联系：X→Y 多对多联系：不存在依赖关系 可从属性间的联系类型来分析属性间的函数依赖 R(U,F)的实例 U={Sno,Dn,Dm,Cn,G} F={Sno→Dn,Dn→Dm,(Sno,Cn)→G} 几种函数依赖 平凡函数依赖 当属性集合Y是属性集合X的子集时(Y(X) 存在函数依赖X→Y 一组属性函数决定它的所有子集 非平凡函数依赖 Y不是X的子集(Y !( X) 但X→Y 完全函数依赖 定义 X’是X的真子集 X必须是组合属性 X→Y 对每一个X’都有X’ !→ Y 则函数X完全函数决定Y Y完全(Full)函数依赖于X X f→ Y 例子 SC(SNO,CNO,G) (SNO,CNO)→G SNO !→ G CNO !→ G (SNO,CNO) f→ G 部分函数依赖 定义 X’是X的真子集 X→Y 存在一个X’，有X’→Y Y不完全依赖于X Y对X的函数依赖是部分(Part)的 X p→ Y 例子 UN(SNO,CN,G,DN,DM) (SNO,CN)→DN SNO→DN (SNO,CN) p→ DN 传递函数依赖 定义 X,Y,Z是R互不相同的属性集合 X→Y（但Y !→ X） Y→Z 则称属性集合Z传递(Transfer)函数依赖于X X t→ Z 例子 UN(SNO,CN,G,DN,DM) SNO→DN（DN !→ SNO） DN→DM SNO t→ DM 关系键的形式化定义 定义 关系模式R(A1,A2,…,An) X是属性的集合，X({A1,A2,…,An} 若X f→ {A1,A2,…,An}，即全体属性完全函数依赖于X 则X是R的候选关系键(候选键) 关系键的性质 唯一性 最小性 每个关系必有键 全键：整个属性组合是关系键 属性键 主属性(键属性) 包含在任何一个候选键中的属性 非主属性(非键属性) 不包含在任何候选键中的属性 例子 S(SNO,SN,AGE,SEX,DEPT) 若姓名不重名 SNO,SN是主属性 AGE,SEX,DEPT是非主属性 SC(SNO,CNO,G) SNO,CNO是主属性 G是非主属性 PWA(演奏者P,作品W,听众A) 之间为多对多关系，无函数依赖 全属性集(P,W,A)是键、主键、全键 P,W,A都是主属性 规范化过程 范式(NF, Normal Formula) 定义 符合某种级别的关系模式的集合 如果一个关系满足某个特定的约束值，则称它属于某种特定的范式 各级范式的要求 第一范式：关系满足只包含原子值的约束 第二范式：每个非主属性都完全函数依赖于R的每个键 第三范式：每个非主属性都不传递依赖于R的任何键 BC范式：R中每个决定因数都是候选键 第四范式 第五范式 各级范式的关系 5NF(4NF(BCNF(3NF(2NF(1NF 如果关系满足某个范式要求，也会满足级别较低的所有范式的要求 较高层次的范式比较低层次的范式具有更合乎要求 规范化 将一个低一级范式的关系模式 通过投影运算 转化为若干个高一级范式的关系模式的集合 的过程