mysql 3 --数据库设计、三大范式

数据库设计

为什么需要设计？

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

糟糕的数据库设计：

• 数据冗余，浪费空间
• 数据库插入和删除都非常麻烦、（比如外键过多），还可能会产生异常。（一般我们都屏蔽使用物理外键）
• 程序的性能差

良好的数据库设计：

• 节省内存空间
• 保证数据库的完整性
• 方便我们开发系统

具体设计

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

• 分析需求：分析业务和需要处理的数据库的需求
• 概要设计：设计关系图（即E-R图）

步骤（以个人博客网站举例）

• 收集信息，分析需求

• • 用户表、文章表、评论表等等，各种表。（这一步其实是实体分析，看都有哪些实体。然后总结属性，归成一个表）

• 标识实体（把需求落地到每个字段）

• 标识实体之间的关系

• • user -> blog
  • user -> user
  • user -> comment
  • …

三大范式

为什么需要数据规范化？

• 信息重复

• 更新异常

• 插入异常

• • 无法正常显示消息

• 删除异常

• • 丢失有效信息

三大范式

目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。

而通常我们用的最多的就是第一范式（1NF）、第二范式（2NF）、第三范式（3NF），也就是本文要讲的“三大范式”。

第一范式（1NF）：要求数据库表的每一列都是不可分割的原子数据项。

原子性：保证每一列不可再分

举例说明：

在上面的表中，“家庭信息”和“学校信息”列均不满足原子性的要求，故不满足第一范式，调整如下：

可见，调整后的每一列都是不可再分的，因此满足第一范式（1NF）；

第二范式（2NF）：在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）

第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。

每张表只描述一件事情 必须满足第一范式

举例说明：

在上图所示的情况中，同一个订单中可能包含不同的产品，因此主键必须是“订单号”和“产品号”联合组成，

但可以发现，产品数量、产品折扣、产品价格与“订单号”和“产品号”都相关，但是订单金额和订单时间仅与“订单号”相关，与“产品号”无关，

这样就不满足第二范式的要求，调整如下，需分成两个表：

第二范式为什么会存在：因为产品和订单描述的是两个事情，要是弄一个表会导致数据冗余。（比如订单时间和订单金额必须挂在每一个的产品的后面。造成数据冗余）

第三范式（3NF）：在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

举例说明：

上表中，所有属性都完全依赖于学号，所以满足第二范式，但是“班主任性别”和“班主任年龄”直接依赖的是“班主任姓名”，

而不是主键“学号”，所以需做如下调整：

这样以来，就满足了第三范式的要求。

ps:如果把上表中的班主任姓名改成班主任教工号可能更确切，更符合实际情况，不过只要能理解就行。

真正设计的时候需要考虑的 规范性和性能

转存中…(img-j2KMdLRL-1617586593336)]

这样以来，就满足了第三范式的要求。

ps:如果把上表中的班主任姓名改成班主任教工号可能更确切，更符合实际情况，不过只要能理解就行。

真正设计的时候需要考虑的 规范性和性能