计算机中级-数据库系统工程师-关系规范化

一、规范化

1. 关系规范化

1）第一范式

• 基本定义
  • 不可再分原则：若关系模式R的每一个分量都是不可再分的数据项，则R属于第一范式，记为R∈1NF
    。例如"学院名称"属性不能拆分为"院系"和"专业"两个子属性存储在同一单元格中。
  • 普遍性：关系数据库中的所有关系模式至少需要满足1NF，这是关系数据库的基本要求。
• 示例分析
  • 关系模式：学生（学号，姓名，学院编号，学院名称，课程号，成绩）
  • 函数依赖集：

    • F={学号→姓名，学号→学院编号，学院编号→学院名称，（学号，课程号）→成绩}

  • 主码确定：
    • 候选码是（学号，课程号）的组合，因为只有它能决定所有属性
    • 由于是唯一候选码，直接作为主码
• 存在问题
  • 数据冗余：
    • 学生选修30门课程时，姓名会出现30次
    • 学院有100名学生时，学院名称会出现100×30=3000次
  • 更新异常：
    • 修改学院名称（如"计算机学院"改为"计算机科学与技术学院"）需要修改所有3000条相关记录
    • 容易遗漏导致数据不一致
  • 插入异常：
    • 新生入学时若未确定选修课程（课程号为空），由于主码不能为空，无法插入学生信息
    • 必须等到课程确定后才能录入
  • 删除异常：
    • 删除某学院最后一名学生时，会意外删除该学院信息
    • 即使学院客观存在，也会因无学生记录而丢失学院信息
• 考试重点
  • 必考题型：每年下午案例题必考范式判断及问题分析
  • 答题要点：
    • 判断关系模式属于第几范式
    • 说明该范式可能存在的问题（必须完整回答上述四个问题）
    • 可能需要将关系模式分解为更高阶范式

2）第二范式

• 第二范式的定义
  • 基本定义: 若关系模式R∈1NF，且每一个非主属性完全依赖于码，则关系模式R∈2NF。
  • 等价表述: 当1NF消除了非主属性对码的部分函数依赖时，称为2NF。
  • 关键概念:
    • 非主属性: 不包含在任何候选码中的属性
    • 完全函数依赖: 若X→Y，且对于X的任何真子集X′，X′→Y不成立
    • 部分函数依赖: 非主属性依赖于码的一部分而非全部
• 第一范式与第二范式的关系
  
  • 转换条件:
    • 1NF必须消除非主属性对码的部分函数依赖才能达到2NF
    • 示例中学生关系模式：
      • 函数依赖集F={学号→姓名，学号→学院编号，学院编号→学院名称，(学号，课程号)→成绩}
      • 存在问题：
        • 数据冗余（如学院信息重复存储）
        • 更新异常（修改学院名称需更新多条记录）
        • 插入异常（无法单独插入学院信息）
        • 删除异常（删除学生可能丢失学院信息）
• 例题1：学生关系模式的第二范式分析
  
  • 原始模式:
    • 学生（学号，姓名，学院编号，学院名称，课程号，成绩）
    • 码：（学号，课程号）
    • 存在问题：姓名、学院编号等非主属性部分依赖于码中的学号
  • 分解方案:
    • 学生1（学号，姓名，学院编号，学院名称）∈2NF
      • 函数依赖：学号→姓名，学号→学院编号，学院编号→学院名称
    • 学生2（学号，课程号，成绩）∈2NF
      • 函数依赖：(学号，课程号)→成绩
  • 分解效果:
    • 消除部分函数依赖（如姓名不再部分依赖于复合码）
    • 减少数据冗余（学院信息不再随每门课程重复存储）
    • 但仍存在传递依赖（学院名称通过学院编号依赖于学号）
  • 注意事项:
    • 分解后的关系需要通过外键保持数据完整性
    • 学生2中的学号应作为引用学生1的外键
    • 这种分解解决了部分冗余，但学院信息仍可能重复（如多个学生属于同一学院）

3）范式进阶

• 遗留问题:
  • 第二范式仍可能存在传递函数依赖
  • 示例中学生1关系存在学号→学院编号→学院名称的传递依赖
  • 这提示需要进一步向第三范式(3NF)转化

4）第三范式

• 第三范式的定义
  • 形式化定义：若关系模式

  • R(U,F)中不存在这样的码X，属性组Y及非主属性Z（Z⊈Y）使得X→Y，(Y↛X)Y→Z成立，则R∈3NF$。

  • 通俗理解：当2NF消除了非主属性对码的传递函数依赖时，称为3NF。即要求非主属性必须直接依赖于码，不能存在间接依赖关系。
• 第三范式与第二范式的关系
  
  • 核心区别：3NF在2NF基础上进一步消除传递依赖。2NF只要求消除非主属性对码的部分函数依赖，而3NF要求同时消除传递函数依赖。
  • 关键特征：
    • 2NF允许存在"学号→学院编号→学院名称"这类传递链
    • 3NF必须拆解为"学号→学院编号"和"学院编号→学院名称"两个直接依赖
• 例题1：学生关系模式的范式判断与分解
  
  • 原始模式：学生(学号，姓名，学院编号，学院名称)∈2NF但∉3NF
    • 存在传递依赖：学号→学院编号→学院名称
    • 导致数据冗余：同一学院名称被多个学生重复存储
  • 规范化分解：
    • 学生11(学号，姓名，学院编号)∈3NF
    • 学生12(学院编号，学院名称)∈3NF
  • 外键设计：学院编号作为学生11表的外键，保持关联关系
  • 优化效果：
    • 消除数据冗余：学院信息只需存储一次
    • 避免更新异常：修改学院名称只需更新单条记录
    • 保持关联性：通过外键维护学生与学院的对应关系

5）巴克斯范式(BCNF)

• BCNF的定义与性质
  • 形式化定义：关系模式R∈1NF，若X→Y且Y⊈X时，X必含有码，则R∈BCNF。
  • 本质要求：当3NF消除了主属性对码的部分函数依赖和传递函数依赖时，称为BCNF。
  • 三大性质：
    • 所有非主属性对每一个码都是完全函数依赖
    • 所有主属性对每一个不包含它的码也是完全函数依赖
    • 没有任何属性完全函数依赖于非码的任何一组属性
• BCNF与3NF的区别
  • 考察对象不同：
    • 3NF考察非主属性对码的依赖关系
    • BCNF考察主属性对码的依赖关系
  • 层级关系：BCNF⊂3NF⊂2NF⊂1NF，形成严格的金字塔结构
  • 关键区别点：BCNF要求主属性也不能部分或传递依赖于码
• 例题：零件关系模式分解
  • 原始模式：
    • 函数依赖：(Pname,Mname)→Pno
    • 候选码：(Pname,Mname)或(Pno,Mname)

  • R(Pno,Pname,Mname)

  • 问题分析：
    • 存在主属性Pname对码(Pname,Mname)的传递依赖
    • Pno对码(Pname,Mname)存在部分函数依赖
  • BCNF分解：

    • R1(Pno,Pname)∈BCNF

    • R2(Pno,Mname)∈BCNF

  • 分解效果：
    • 消除主属性对码的部分和传递依赖
    • 每个分解后的关系都满足BCNF要求

6）第四范式

• 定义: 关系模式R∈1NF，若对于R的每个非平凡多值依赖X→Y且Y⊈X时，X必含有码，则关系模式(U,F)∈4NF。
• 核心限制: 4NF限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。
• 规范化程度:
  • 仅考虑函数依赖时，最高规范化程度是BCNF
  • 考虑多值依赖时，最高规范化程度是4NF
• 判断标准
  • 情况一:
    • 条件: 关系模式中完全不存在多值依赖
    • 结论: 不需要考虑4NF，最高达到BCNF
  • 情况二:
    • 条件: 存在多值依赖
    • 判断步骤:
      • 检查多值依赖数量
      • 分析多值依赖属性间的关联性
• 典型案例分析
  • 学生关系模式
    • 结构: 学生(学号，选修课程，兴趣爱好)
    • 多值依赖:
      • 学号→选修课程
      • 学号→兴趣爱好
    • 属性关系: 选修课程与兴趣爱好相互独立
    • 规范化处理:
      • 学生1(学号，选修课程)∈4NF
      • 学生2(学号，兴趣爱好)∈4NF
  • 书目关系模式
    • 结构: 书目(ISBN,书名，作者，排名，出版社)
    • 依赖关系:
      • ISBN→书名 (函数依赖)
      • ISBN→出版社 (函数依赖)
      • ISBN→作者 (多值依赖)
      • 作者↔排名 (一一对应)
    • 规范化处理:
      • 书目1(ISBN,作者，排名)∈4NF
      • 书目2(ISBN,书名，出版社)∈BCNF
• 分解原则
  • 原则一: 将相互独立的多值依赖分解为独立关系模式
    • 例：学生关系分解为学号-选修课程和学号-兴趣爱好两个关系
  • 原则二: 将相关联的多值依赖属性保留在同一关系模式
    • 例：书目中的作者和排名保持在同一关系模式
  • 原则三: 与多值依赖无关的属性单独处理
    • 例：书目中的书名和出版社作为单独关系模式
• 考试重点
  • 常见题型: 判断给定关系模式是否属于4NF
  • 解题步骤:
    • 识别所有多值依赖关系
    • 分析多值依赖属性间的关联性
    • 检查是否存在非平凡且非函数依赖的多值依赖
    • 判断是否需要分解及如何分解
  • 易错点:
    • 混淆多值依赖与函数依赖
    • 忽略属性间的关联性分析
    • 错误保留与多值依赖无关的属性

2. 总结

• 规范化过程：通过分解，可以将一个低一级范式的关系模式转换成若干个高一级范式的关系模式
• 范式层级关系：
  • 满足第四范式(4NF) → 必满足BC范式(BCNF)
  • 满足BC范式 → 必满足第三范式(3NF)
  • 满足第三范式 → 必满足第二范式(2NF)
  • 满足第二范式 → 必满足第一范式(1NF)
• 各范式消除的依赖关系：
  • 1NF：属性不可再分（原子性）
  • 2NF：在1NF基础上消除非主属性对码的部分函数依赖
  • 3NF：在2NF基础上消除非主属性对码的传递函数依赖
  • BCNF：在3NF基础上进一步消除主属性对码的部分和传递函数依赖
  • 4NF：在BCNF基础上消除非平凡且非函数依赖的多值依赖
• 记忆要点：
  • 判断范式等级时必须清楚每个范式消除了什么依赖
  • 若无多值依赖情况，最高可达BC范式
  • 若有多值依赖且满足4NF条件，则可达第四范式

3. 应用案例

1）例题:关系模式范式判断

• 题目解析：
  • 候选码确定方法：能函数决定所有属性的最小属性组合
  • 主键判断过程：
    • 检查(学生,课程)：能决定成绩，但无法决定时间/教室 → 非候选码
    • 检查(时间,教室)：能决定课程，但无法决定学生 → 非候选码
    • 检查(时间,教师)：能决定教室，但无法决定学生/成绩 → 非候选码
    • 检查(时间,学生)：
      • 可决定教室
      • 结合(时间,教室)→课程
      • 结合(学生,课程)→成绩
      • 通过课程→→教师（多值依赖）
      • 可推出全属性 → 唯一候选码
  • 规范化程度判断：
    • 存在传递依赖：时间学生→教室→课程（非子集关系）
    • 故R最高达到2NF（未消除非主属性对码的传递依赖）
  • 分解后R2的范式：
    • R2(学生,课程,成绩)中：
      • 主键：(学生,课程)
      • 无部分依赖和传递依赖
      • 无多值依赖 → 达到BCNF
• 答案：
  • (1) D.(时间,学生)
  • (2) B.2NF
  • (3) C.BCNF
• 易错点：
  • 传递依赖判断时需注意：Y不能是X的子集且Y不能决定X
  • 多值依赖与函数依赖的区别（4NF与BCNF的区分关键）
  • 分解后的关系模式需要单独进行范式判断

二、知识小结