6关系数据库设计理论.ppt

Chapter 6 Relational Database Design关系数据库设计 本章内容 问题提出 函数依赖定义 函数依赖理论 范式 模式分解算法 数据库模式求精 问题提出 本节学习目的： 学会分析一下设计“不好”的数据库可能带来的问题及解决方法 掌握一个设计“好”的关系模式的基本原则 学习重点：数据冗余引起的问题及其解决方法 学习难点：插入异常、删除异常问题的分析 问题提出 数据库设计后得到的一个关系模型 问题提出 数据冗余关系的实例 问题提出 数据冗余关系导致的问题 数据冗余是指同一信息在数据库中存储了多个副本，它可能引起下列问题： 冗余存储：信息被重复存储，导致浪费大量存储空间 问题提出 数据冗余关系导致的问题 更新异常：一个副本被修改，所有副本都必须修改，否则会面临数据不一致的危险 如：当修改某学生姓名或某课程名时，可能只修改了部分副本的信息 问题提出 数据冗余关系导致的问题 插入异常：只有当一些信息事先已经存放在数据库中时，另外一些信息才能存入数据库中 如：如果某学生没有选修课程，则该学生不能存入数据库，因为主码值不能为空 问题提出 数据冗余关系导致的问题 删除异常：删除某些信息时可能丢失其他信息 如：当一学生的所有信息被删除时，则他选修的课程信息将丢失 问题提出 数据冗余关系导致的问题—另一举例 Lending-schema = (branch-name, branch-city, asset, customer-name, loan-number, amount) 存在以下4个问题： 插入异常：例如要插入一个新的银行信息，如果该银行没有客户，就无法插入该银行信息。 删除异常：如果删除某银行的所有客户信息，则该银行的信息（branch_name, branch-city, asset ）记录就要被删除。（ 因为customer_name是主属性，删除了客户名称，整个元组就不存在了。） 数据冗余：一个branch-name就可以唯一地确定一个branch-city和asset 。而在该关系模式中，如果一个银行有1万个客户，该银行的branch-city和asset就要重复1万次。 修改复杂：假设某银行有5万客户，如果该银行的branch-city和asset branch-city和asset变动的话，则需要对5万个元组中全部的branch-city和asset信息进行修改。 问题提出 数据冗余产生的原因 关系模式中描述一个实体属性时同时关联其他实体属性 如：定义学生信息时也定义了课程信息 上述例子中模式某些属性之间存在依赖关系 问题提出 解决办法 将原有的关系模式进行分解，方法如下 不同实体的属性应分解在不同的关系模式中 应保持原有的依赖关系 分解为三个关系模式 能否消除冗余带来的四个问题？ 问题提出 解决办法 在关系模式的设计有缺陷时，我们通过更详细地分析这些缺陷引起地问题，引入“分解”的思想，即把一个关系模式分解成两个更小的模式来消除某些问题。 例： Lending-schema 分解为: Branch-schema = (branch-name, branch-city,assets) Loan-info-schema = (customer-name, loan-number, branch-name, amount) 从以上分解中，我们不难看到：如此将一个关系模式分解成两个关系模式后： 减少了冗余 消除了插入异常 消除了删除异常 修改简单 模式分解导致的问题 将一个关系模式分解为较小关系模式集可解决冗余问题。但可能产生两个新问题 什么样的关系模式需要进一步分解为较小的关系模式集 根据范式要求决定(后面讨论) 是否所有的模式分解都是有益的？ 例：设一关系模式STU(sno,sname,ssex,birthday,native,classno)设将其分解为以下两个子模式STU1(sno,sname)STU2 STU(sname,ssex,birthday,native,classno)分解后会发生什么问题？ 模式分解导致的问题 模式分解导致的问题 模式分解存在的问题： 有损分解：两个分解后的关系通过连接运算还原得到的信息与原来关系的信息不一致 无损分解：如果通过连接后所得到的较小关系完全还原被分解关系的所有实例，称之为无损分解也称该分解具有无损连接特性 模式分解导致的问题 模式分解存在的问题： 实例分析 设一关系模式STU(sno,sname,ssex,birthday,native,classno)设将其分解为以下两个子模式STU1(sno,sname)STU2 STU(sname,ssex,birthday,native,clas