第5讲 需求分析阶段-规范化.ppt

数据库系统设计 需求分析阶段 规范化 概述 虽然一个数据模型有效地沟通了数据库需求 但它不一定就代表了一个好的数据库设计 其中的某些结构特征可能会降低模型的灵活性和扩展性 或者产生不必要的冗余 所以 我们必须为数据库设计和实现准备好具有完整属性的数据模型 好的数据模型的标准好的数据模型是简单的 好的数据模型基本上是无冗余的 好的数据模型应该是灵活的而且对未来的需求具有可适应性 概述 考虑以下的实体定义 courseregistration courseregistrationnumber PK courseregistrationdate studentidnumber FK studentname studentmajor 一个或多个coursenumber 概述 好的数据模型是简单的 作为一条通用规则 描述任何实体的数据属性应该仅仅描述那个实体 属性studentname和studentmajor真的描述了courseregistration 课程注册 的一个实例吗 或者它们仅仅描述了一个不同的实体 即student 同样的理由可以应用到属性studentidnumber上 经过进一步考察 studentidnumber属性仍是需要的 它用来 指出 对应的student实体实例 概述 好的数据模型是简单的 简单性的另一个方面是这样陈述的 一个实体实例的每个属性只能有一个值 再看前的例子 对应一个courseregistration实体 属性coursenumber可以多个有值供学生选择 概述 好的数据模型基本上是无冗余的 这意味着每个数据属性 除了外键 最多在一个实体中描述 在前面的例子中 发现属性studentname和studentmajor实际上描述一个student实体并不困难 故合乎逻辑的选择将是添加student实体 在数据模型中还可能存在更细微的冗余 例如 相同的属性可能以不同的名称 同义词 被多次记录 概述 好的数据模型应该是灵活的而且对未来的需求具有可适应性 没有这条评价准则 我们往往会设计仅实现目前业务需求的数据库 然后 当一个新的需求产生时 我们若不重写许多或者所有使用那些数据库的程序就无法方便地修改数据库 虽然我们不能改变这个现实 大多数项目都是应用驱动的 但是我们可以使数据模型做到尽可能地与应用无关 以鼓励采用不影响当前程序扩展或修改的数据库结构 概述 数据分析 是为将数据模型实现成数据库而改进数据模型的技术 数据分析是为实现简单的 无冗余的 灵活的并可扩展的数据库而准备数据模型的过程 其专门的技术称为规范化 规范化 是一种数据分析技术 该技术组织数据属性怪便它们可以组合起来形成无冗余的 稳定的 灵活的并具有适应性的实体规范化是一种包括三个步骤的技术 该技术把数据模型规范成1NF 2NF和3NF 所有的范式都是基于表中的列之间的关系的 概述 规范化理论是研究如何将一个不好的关系模式转化为好的关系模式的理论 规范化理论是围绕范式而建立的 规范化理论认为 一个关系数据库中所有的关系 都应满足一定的规范 约束条件 规范化理论把关系应满足的规范要求分为几级 满足最低要求的一级叫做第一范式 1NF 在第一范式的基础上提出了第二范式 2NF 在第二范式的基础上又提出了第三范式 3NF 以后又提出了BCNF范式 4NF 5NF 范式的等级越高 应满足的约束集条件也越严格 规范的每一级别都依赖于它的前一级别 例如若一个关系模式满足2NF 则一定满足1NF 数据冗余和更新异常 更新异常引起数据冗余的错误的结构化表的问题叫做更新异常错误的结构化表可能产生于最初的ER模型或在将ER模型转化成表时出现错误 有冗余数据的表可能有的问题叫做更新异常 它分为插入 删除和更改异常 数据冗余和更新异常 数据应该尽可能少地冗余 这意味着重复数据应该减少到最少比如 一个部门雇员的电话就不应该被存储在不同的表中 因为这里的电话号码是雇员的一个属性 如果存在过多的冗余数据 这就意味着要占用了更多的物理空间 同时也对数据的维护和一致性检查带来了问题当这个员工的电话号码变化时 冗余数据会导致对多个表的更新动作 如果有一个表不幸被忽略了 那么就可能导致数据的不一致性 关系数据库设计的主要目的是把列分组成表 以便最小化数据冗余并减少基表所需的文件存储空间 数据冗余和更新异常 StaffBranch表 冗余数据 因为分公司的细节信息在分公司的每个员工那里被重复了一遍 PK 数据冗余和更新异常 为说明与数据冗余有关的问题 我们来进行个比较 只有分公司编号被重复 每个分公司的详细信息只出现一次 更新异常 插入异常 有两种主要的插入异常潜在的不一致性 为了插入一新员工到StaffBranch表中 必须包括分公司的详细信息 这个信息决定新员工所属的分公司 而在输入时无法保证输入的信息不出错 StaffBranch表 StaffBranch表 如 要插入在B003分公司工作的新员工 必须输入B003分公司的正确的细节情况使得与StaffBranch表中其他分公司的记录信息一致 更新异常 插入异常 避免不一致性问题出现 此时就不存在潜在的不一致性 因为对于每一个员工我们仅需加入正确的分公司号到Staff表中就可以了 另外 B003分公司在Branch表中作为单独的记录在数据库中仅记录一次 更新异常 插入异常 有两种主要的插入异常违反实体完整性 如果要在StaffBranch表中插入一个新的 目前还没有员工的分公司的详细信息 需要在与员工有关的列 如staffNo 输入空值 但由于StaffNo在StaffBranch表中是主键 输入null给StaffNo就违反了实体完整性 因此 不允许为空 这就违反了实体完整性 StaffBranch表 StaffBranch表 更新异常 插入异常 避免违反实体完整性问题出现 Staff表和Branch表的设计就避免了这个问题的出现 因为在Branch表中插入分公司情况与员工内容是分开的 在有了分公司之后 就可以在以后插入员工到Staff表中 更新异常 删除异常 如果从StaffBranch表中删除一个记录 而它又是一个分公司的最后一名员工 或唯一的一名 那么关于该分公司的有关信息也被从数据库中删除了 StaffBranch表 例如 如果我们从StaffBranch表中删除员工S0415的记录 那么与B003分公司相关的情况也从数据库丢失了 更新异常 删除异常 避免出现删除异常 Staff表和Branch表的设计就避免了这个问题的出现 因为在Branch表中插入的分公司情况与员工内容是分开的 仅仅是用BranchNo列把两个表关联起来 如果从Staff表中删除员工S0415的记录 那么B003分公司的情况在Branch表中依旧存在 不受影响 更新异常 更新异常 如果想要改变表中一个特定分公司的一个列的值 如分公司B001的电话号码 就必须更改在那个分公司的所有员工的记录 如果此次更改没有在该表中的所有记录正确进行 那么数据库就变得不一致了 StaffBranch表 从而会出现分公司的不同员工有不同的电话号码的问题 更新异常 删除异常 避免出现更新异常 Staff表和Branch表的设计就避免了这个问题的出现 因为此时只需要更新Branch表中分公司的电话号码就可以了 第一范式 1NF FirstNormalForm 1NF对于关系数据库来说 只有第一范式 1NF 在创建适当的表中是关键的 所有接下来的范式都是可选的 实体的所有属性对于实体的单个实例都只具有一个值 每个列和记录包含一个且仅含一个值的表实体的所有属性对于实体的单个实例 记录 都只具有一个值 任何可以有多个值的属性实际上描述了一个独立的实体 也可能是一个实体和关系 第一范式 1NF Branch表不是1NF的一个例子 Branch表的主键为BranchNo 可以看到BranchNo表中除了TelNo列之外 其他的列都遵守1NF的定义 因为对于每一个记录的TelNo列有多个值 如 分公司号为B001的分公司有三个电话电码 因此Branch表不属于1NF 第一范式 1NF 将Branch表转换为1NF 为了把Branch表转换成1NF 我们创建一个单独的表 叫做BranchTelephone 此表用来保存分公司的电话电码 此表是把TelNo列从Branch表中去掉 同时把Branch表的主键复制到新表中 新表BranchTelephone的主键是TelNo 从而得到两个1NF的表 因为符合每一个表的每一个记录的每一列都有单独的值这一标准 第二范式 2NF SecondNormalForm 2NF2NF只应用于具有复合主键的表具有单列主键的表自动成为2NF不属于2NF的表可能会有更新异常问题一个1NF的表 在该表中的每个非主键列的值都可以由组成主键的全部的列的确定实体的所有非主键属性的值都依赖于主键任何仅仅部分依赖主键的非主键属性应该被移到另一个实体中 这可能需要在模型中创建一个新实体和关系 第二范式 2NF TempStaffAllocation表不是2NF 将TempStaffAllocation表转换为2NF 第三范式 3NF ThirdNormalForm 3NF一个已经是第一和第二范式的表 并且所有的非主键的值都只可以从主键列得到 而不能从其它的列得到 实体已经是2NF实体的非主键属性的值不依赖于任何其它非主键属性任何依赖于其它非主键属性的非主键属性必须去掉或删除新的实体和关系可能要被加到新的数据模型中 StaffBranch表不是3NF 将StaffBranch表转换成3NF NF NF和 NF总结 如果每个非主键属性都依赖于主键 整个主键 而且除了主键以外再不依赖于任何属性 这个实体就被称为是第三范式的 规范化步骤 专门订单文档模型 仔细检查专门订单文档 会注意到两种情况 在这两种情况中 单个专门订单实例中同样的属性捕获多个值 第一种违反是客户书的爱好 就是那种客户喜欢看的书 属性的复数形式让我们以为每个订单的实例包含了很多种不同爱好 就时爱好就是重复属性 需要建立一个新的包含更多爱好信息的实体去解决这个问题 还要在专门订单和爱好之间添加一个关系 此外 专门订单文档捕获了单个专门订单中多本书的信息 这也违反了1NF 这时 每当下一次订单 关于书本的一组信息就会被重复记录 这被叫做组重复 它可以通过创建一个叫书的实体并把所有关于该书的属性放入其中来解决问题 第一范式 规范化步骤 第二范式要求模型首先是第一范式 还要求数据模型的实体包含依赖于整个主键的属性 这意味着所有作为主键的属性值可以决定实体的一个实例中所有其他属性的值 有时非主键属性只依赖于部分主键 如 部分依赖 这些属性属于其他实体 注意到在最初 专门订单实体有 个用作主键的属性 订单日期 客户姓和客户名 问题在于有一些属性依赖客户的姓和名 但是不依赖于专门订单日期 为了解决这个问题 一个叫客户的新实体被创建 客户的属性都移到新实体中 客户和专门订单之间存在1 N的关系 同时注意到 我们把与爱好有关的关系移到了新的客户实体 逻辑上说 爱好应该和客户相关联 而不是与专门订单 第二范式 规范化步骤 第三范式出现在当一个模型是第一范式又是第二范式 并且最终的实体中没有一个属性依赖非主键属性时 如 传递依赖 第三范式 书实体的问题在于作者的大学依赖作者 而不是ISBN 换句话说 知道一本书的ISBN 你并不能自动知道作者当前的大学 但你可以通过使用作者的名字找到那个值 一个非主键属性 因而 我们建立另个一个叫作者的实体并把作者的属性移到新实体中 同理 商店经理和位置依赖商店名字的程度 它不是专门订单的主键 这种传递的关系可以通过创建包含商店属性的商店实体来解决 第三范式 3NF同样是用于解决由继承或计算属性引起的问题 继承属性的值没必要存储在数据库中 因而可以从数据模型中排除 因为它们可以从其他属性中继承下来 如 一个系统不会捕获一个人的年龄 如果系统已经包括了他的生日 年龄可以从他的生日和当天的日期的比较中推算出来 专门订单已发出的天数