MYSQL数据库课程-关系的规范化

1. 规范化的目的

规范化：生成一组既具有所期望的特性又能满足企业数据需求的关系的技术

• 目的：
  • 确定一组合适的关系以支持企业的数据需求
• 合适的关系应该具有如下的性质：
  • 属性的个数最少，且这些属性是支持企业的数据需求所必须的
  • 具有紧密逻辑联系(描述为函数依赖)的诸属性均在同一个关系中
  • 最少的冗余，即每个属性仅出现一次，作为外部关键字的属性除外
• 规范化的好处在于：
  • 数据库易于访问
  • 数据易于维护
  • 占有较少的存储空间

2. 数据冗余与更新异常

减少数据冗余的好处：

1. 能用最少的操作完成数据库中存储数据的更新
2. 减少对存储空间的需求

• 根据下表，对异常进行举例解释

2.1 插入异常

• 第一种：在向StaffBranch中插入一个新员工的信息时，这些信息中必须包含该员工被分配到的分公司的信息，但是分公司的信息 在数据库中可能已经存在，会造成数据冗余，同时如果录入分公司信息和数据库中已存在的分公司信息不同，会造成数据不一致
• 第二种：在向StaffBranch中插入一个新的分公司的信息时，由于该分公司目前可能还没有员工，因此有必要在录入于员工相关的信息时将其设置为null

2.2 删除异常

• 在从关系StaffBranch(见上图)中删除一个元组时，若元组表示某分公司最后一名员工，则删除元组之后，该分公司的信息也从数据库中丢失了，但是实际上分公司可能还存在

2.3 修改异常

• 如果我们想要修改关系StaffBranch中某分公司的某个属性值，那么需要修改该分公司所有员工对应的元组，如果没有在该分公司所有员工对应的元组上进行修改，则会导致数据的不一致性

2.4 较大大关系的分解

可以把一个较大关系分解成两个较小关系，来解决上述更新异常

• Example: 将StaffBranch关系分解成Staff和Branch关系

  

  

• 当把较大关系分解成较小关系时，具有以下特性

  • 无损连接特性：确保了原关系的任一实例信息能通过较小关系的对应实例确定出来
  • 依赖保持特性：确保了只需简单地在较小关系上支持某些约束，就可以继续支持在原关系上存在的约束（大白话：只需要检查小关系的约束，就可以确保满足原大关系的约束）

3. 函数依赖

• 函数依赖：函数依赖描述了属性之间的联系。例如A、B都是关系R的属性，若A的每个值都和B中的一个唯一的值相对应，则称B函数依赖于A(A：定义域，B：值域)

  

  • 两个元组的属性A相同，则属性B相同，但是如果属性B相同，属性A不一定相同
  • 决定方：位于函数依赖箭头左边的属性或属性组

• 完全函数依赖：假设A和B是某一关系的属性(组)，若函数B依赖于A，但不函数依赖于A的任一真子集，则称B完全函数依赖于A，

  Example:

  • 已知：(staffNo,sName) —> branchNo，branchNo函数依赖于属性组(staff, sName)
  • 但是branchNo也函数依赖于staffNo
  • 则staffNo,sName --> branchNo确定的函数依赖是部分函数依赖
  • 而staffNo --> branchNo确定的是完全函数依赖

• 规范化时用到的函数依赖的性质：

  • 函数依赖左边的属性(组)与右边的属性(组)是一对一联系的(反过来看，则可能是一对一或者一对多的)
  • 函数依赖关系在数据库中，恒成立
  • 右边的属性(组)完全依赖于决定方
  • 函数依赖是非平凡的
    • 非平凡函数依赖：依赖关系中，右边的属性(组)不是左边属性(组)的子集

• 传递依赖：假设A、B、C是某一关系的属性，若A --> B, B --> C，则称C通过B传递依赖于A(假设A并不函数依赖于B或C)

• 函数依赖闭包：

  • 定义：由给定的函数依赖集合X，能够推导出的所有函数依赖的集合，叫做X的闭包
  • Armstrong’s axioms – 阿姆斯特朗公理
    • Reflexivity: if B is a subset of A, then A --> B
    • Augmentation: if A --> B, then A,C --> B,C
    • Transitivity: if A --> B and B --> C, then A --> C

4. 规范化过程

• 规范化是一种基于关系的主关键字(或者候选关键字)和函数依赖对关系进行分析的形式化技术

• 规范化技术设计一系列的规则，这些规则能够用来对关系进行单独测试，以保证数据库可以被规范化到任意程度。当某种规范化的要求未能得到满足时，就将违反需求的关系分解为多个关系，直至分解后的每一个关系都能满足规范化的要求为止

• 规范化的过程包括一系列的步骤，每一步都对应着某种具有已知性质的特定范式

• 随着规范化的进行，关系数量的逐渐增多，关系的形式也逐渐受限(结构越来越好)，也就越来越不容易出现更新异常

• 范式图例

  

• 规范化过程图示：

  

5. 第一范式 – 1NF

• 非范式：包含一个或多个重复组(重复组定义见下文)的表

  Example：

  

  • 重复组：一个重复组可以是一个属性或一组属性，它对应表的某个(些)关键属性的一个实例可能出现的多个值
    • 这里所说的 “关键属性” 是指非规范化的表中，那些可以唯一标识每一行的属性(组)
    • 描述有些晦涩，举个栗子，如上图中非规范化关系ClientRental，关键属性可以是 clienNo 属性，因为它可以唯一确定一个元组。重复组为(propertyNo, pAddress, rentStart, rentFinish, rent, ownerNo, oName)。对于一个关键属性的实例，例如在非规范化关系 clientRental 中的 CR56, 后面有多个重复组的实例与之匹配

• 第一范式：属于第一范式的关系，其每一行和每一列相交的位置有且仅有一个值

  Example：

  

• 为了将非规范化的表转化为第一范式，我们需要确定并删除表中的重复组

• 从非规范化的表中消除重复组的常用方法有两种：

  • 在含有重复数据的那些行的空白列上输入合适的数据

    大白话：

    • 非规范化表中的一行：
      • 关键属性(keyVal)，重复组(val1,val2,val3……)
    • 拆分为：
      • keyVal, val1
      • keyVal, val2
      • keyVal, val3
      • ……

  • 将重复数据单独移到一个新的关系中，同时也将原来关系中的关键属性(组)复制到这个新关系中

    • 新建一个表，存储重复组，同时将原表中的关键字复制到新表中作主键

6. 第二范式 – 2NF

• 定义：满足第一范式的要求并且每个非主关键字属性都完全函数依赖于主关键字的关系

• 将1NF 关系规范化为2NF 关系需要消除部分依赖。如果存在部分依赖，就要将部分依赖的属性从原关系移出，移到一个新的关系中去，同是将这些属性的决定方也复制到新的关系中(作新关系的主键)

• 举个栗子，还是ClientRental关系，

  

  • 具有下列函数依赖关系

    • clientNo, propertyNo --> rentStart, rentFinish
    • clienNo --> cName，cName部分依赖于主关键字
    • propertyNo --> pAddress, rent, owner, nName ，右边的属性组部分依赖于主关键字
    • owner --> oName，oName传递依赖于主关键字
    • clientNo, rentStart --> propertyNo, pAddress, rentFinish, rent, ownerNo, oName，左边的属性组为候选关键字
    • propertyNo,rentStart --> clientNo, cName, rentFinish，左边的属性组为候选关键字

  • 需要消除部分依赖关系，转换后如下：

    

7. 第三范式 – 3NF

• 定义：满足第一范式和第二范式的要求并且要求所有非主关键字属性都不传递依赖于主关键字的关系

• 将2NF的关系规范化为3NF需要消除传递依赖，如果存在传递依赖，就将传递依赖的属性(组)移到一个新的关系中，并将这些属性的决定方也复制到该关系中

• 举个栗子：

  

  • 该关系中，存在如下函数依赖关系：

    propertyNo --> pAddress,rent,owner,oName , 右边的属性组完全依赖于主关键字

    ownerNo --> oName，oName传递依赖于主关键字

  • 将ownerNo --> oName 移动到一个新表中消除传递依赖

    

规范化过程就是通过一系列的关系代数投影对原始关系进行分解，这是一种无损连接分解，无损连接分解是可逆的，即反向使用自然连接操作就可以得到原关系

8. 第二范式 和 第三范式的一般化定义

一般化规定需要考虑候选关键字

• 规定：
  • 属于任何一个候选关键字的属性都叫做主属性
  • 提到部份依赖、完全依赖和传递依赖时，不仅仅是基于主关键字，而是基于所有的候选关键字
• 第二范式一般定义：
  • 满足第一范式的要求并且每个非主属性都完全依赖于任何一个候选关键字的关系
• 第三范式一般定义：
  • 满足第一范式和第二范式的要求并且没有一个非主属性传递依赖于任何一个候选关键字的关系
• 对比第二、三范式的原始定义：
  • 第二范式：满足第一范式的要求，并且每个非主关键字属性都完全函数依赖于主关键字的关系
  • 第三范式：满足第一、二范式的要求，并且每个非主关键字属性都不传递依赖于主关键字的关系

9. Boyce-Codd范式 – BCNF

• 定义：当且仅当每个函数依赖的决定方都是候选关键字时，某一关系才是BCNF的
• 满足BCNF的关系一定满足3NF，但是满足3NF的关系不一定满足BCNF