MySQL（9）— 规范数据库设计

九、规范数据库设计

9-1、为什么要设计？

当数据库比较复杂时，我们就需要设计了!

糟糕的数据库设计：

• 数据冗余，浪费大量存储空间
• 使用物理外键，大量的增删改操作麻烦，异常
• 查询效率低下

良好的数据库设计：

• 节省内存空间

• 保证数据库的完整性

• 方便我们对于后台系统的开发

软件开发中，关于数据库的设计：

• 分析需求：分析业务和需要处理的数据库需求
• 概要设计：设计关系流程图 E-R图 ( 实体-联系图 : Entity Relationship Diagram )

设计阶段：

• 收集信息，分析需求，建表
• 根据需求，落实到表的每个字段
• 标识表之间的关系（我的理解：中间表，例如 选课表，关注表 等。。）

9-2、三大范式

什么需要数据规范化？

• 信息重复
  • 两张表的字段重复
• 更新异常
  • 物理外键（慎用）
• 插入异常
  • 无法正常显示信息（有些表插入了，有些落下了）
• 删除异常
  • 文章删除了，他对应的标签还在

三大范式

1. 第一范式（1NF）

   原子性：每一列的数据，不可再分。

   错误示例：此例的家庭信息

   学号	姓名	性别	家庭信息
   1	风	男	一家三口，湖南

2. 第二范式 (2NF)

   前提：第一范式！

   含义：非主属性必须对主属性 **完全依赖 **。

   我的理解：第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对 **联合主键 ** 而言）。 通俗来说就是：一张表，只描述一类事情。

   例如：成绩表

   学号	课程号	分数	姓名
   1	1	95	风

   例如此例：主键为（学号，课程号），而非主属性中，'分数'，完全依赖于主键，少了一个都不行，少了学号，你不知道他是哪一门课是95分，少了课程，你不知道哪个学生得分95；反之，姓名，只和学号有关。

   解决：细分为成绩表 (学号，课程号，分数)，学生表（学号，姓名）即可。

3. 第三范式（3NF）

   前提：第二范式！

   含义： 所有的非主键列依赖于主键列

   我的理解：非主键列中，不能有字段a推断出字段b的情况！

   例如：选课表

   学号	姓名	老师	老师职称	上课地点
   1	风	夏日荷花	教授	A-602

   问题：从选课表学号1的学生里，是可以推断出他选的课的老师，是教授；但是，从老师名字，也能推断出这位授课老师是教授，故存在传递依赖，学号=>老师=>老师职称。

   解决：把老师相关的信息，细分为一个老师表即可。

关于 规范化 和 性能的问题：

关联查询的不得超过三张表

• 考虑商业化的需求，用户的体验和成本，而数据库的性能最重要（我的理解：太多表查询，会慢）
• 在考虑性能的前提下，再适当考虑规范性
• 给某些表添加必要的冗余字段（从多表查询，变成单表查询）
• 故意增加一些计算列（从大数据量降低为小数据量的查询，我的理解：例如查询今年第xxx天生日的人，那么在设计列的时候，就可以加一列，把生日转化为那一年的第几天，查询的时候直接判断即可，少了每条记录的运算过程）