(三)MySQL之库表设计篇:一、二、三、四、五范式、BC范式与反范式详解!

引言

作者✍️:熊猫爱竹子

MySQL的库表设计,在很多时候我们都是率性而为,往往在前期的设计中考虑并不全面,同时对于库表结构的划分也并不明确,所以很多时候在开发过程中,代码敲着敲着会去重构某张表结构,甚至大面积重构多张表结构,这种随心所欲的设计方式,无疑给开发造成了很大困扰。

但实际上设计DB库表结构时,也有一些共同需要遵守的规范,这些规范在数据库设计中被称为“范式”,理解并掌握这些设计时的规范,能让咱们在项目之初,设计的库表结构更为合理且优雅。数据库范式中,声名远扬的有三大范式,但除此之外也有一些其他设计规范,如:

  • ①数据库三大范式(1NF、2NF、3NF

  • ③第四范式(4NF)和第五范式:完美范式(5NF

  • ②巴斯-科德范式(BCNF

  • ④反范式设计

不过对于上述的几种设计范式,大部分小伙伴应该仅了解过三范式,对于其他的应该未曾接触,那在本篇中会重点阐述库表设计时,会用到的这些范式。

一、数据库三大范式

范式(Normal Form)在前面也提到过,它就是指设计数据库时要遵守的一些原则,而数据库的三大范式,相信诸位在学习数据库知识时也定然接触过。三大范式之间,它们是递进的关系,也就是后续的范式都基于前一个范式的基础上推行,就好比下面这句话:

今天我要先炒菜,然后吃饭,最后洗碗。

炒菜、吃饭、洗碗三者也属于递进关系,后者都建立在前者之上,其顺序不能颠倒,比如先吃饭再炒菜,这必然是行不通的。数据库的三大范式也一样,第二范式必须建立在第一范式的基础之上,如若设计的库表第一范式都不满足,那定然是无法满足第二范式的。

写在前面的话:其实对于数据库三范式相关的资料,网上也有很多很多,但大部分资料都涉及了太多的概念,通篇看下来也很难让人理解,因此下述的三范式则会结合具体的设计实例来让诸位彻底理解三范式。

1.1、第一范式(1NF)

库表设计时的第一范式,主要是为了确保原子性的,也就是存储的数据具备不可再分性,这话咋理解呢?上个案例:

SELECT * FROM `zz_student`;
+
| student              | course | score |
+
| 竹子,男,185cm      | 语文   |    95 |
| 竹子,男,185cm      | 数学   |   100 |
| 竹子,男,185cm      | 英语   |    88 |
| 熊猫,女,170cm      | 语文   |    99 |
| 熊猫,女,170cm      | 数学   |    90 |
| 熊猫,女,170cm      | 英语   |    95 |
+

在上述的学生表中,其中有一个student学生列,这一列存储的数据则明显不符合第一范式:原子性的规定,因为这一列的数据还可以再拆分为姓名、性别、身高三项数据,因此为了符合第一范式,应该将表结构更改为:

+
| student_name | student_sex | student_height | course | score |
+
| 竹子         | 男          | 185cm          | 语文   |    95 |
| 竹子         | 男          | 185cm          | 数学   |   100 |
| 竹子         | 男          | 185cm          | 英语   |    88 |
| 熊猫         | 女          | 170cm          | 语文   |    99 |
| 熊猫         | 女          | 170cm          | 数学   |    90 |
| 熊猫         | 女          | 170cm          | 英语   |    95 |
+

student这一列数据,分别拆分为姓名、性别、身高三列,然后分别存储对应的数据才合理,通过这样的优化后,此时zz_student这张表则符合了数据库设计的第一范式。

那此刻思考一下:如果不去拆分列满足第一范式,会造成什么影响呢?

  • 客户端语言和表之间无法很好的生成映射关系。

  • 查询到数据后,需要处理数据时,还需要对student字段进行额外拆分。

  • 插入数据时,对于第一个字段的值还需要先拼装后才能进行写入。

简单来说,如果按照原本那张形式去做业务开发,显然操作起来会更加麻烦且复杂一些,但第一范式的原子性,除开对列级别生效之外,行级别的数据也是同理,也就是每一行数据之间是互不影响的,都是独立的一个整体。

1.2、第二范式(2NF)

上述的第一范式还是比较容易理解,紧接着来看看第二范式,第二范式的要求表中的所有列,其数据都必须依赖于主键,也就是一张表只存储同一类型的数据,不能有任何一列数据与主键没有关系,还是上面的那张表数据为例:

+
| student_name | student_sex | student_height | course | score |
+
| 竹子         | 男          | 185cm          | 语文   |    95 |
| 竹子         | 男          | 185cm          | 数学   |   100 |
| 竹子         | 男          | 185cm          | 英语   |    88 |
| 熊猫         | 女          | 170cm          | 语文   |    99 |
| 熊猫         | 女          | 170cm   &nbs
<think>好的,用户现在想了解数据库设计中的第、第、第范式的条件。我需要根据提供的引用内容来组织回答,同时参考之前的对话历史。之前用户问过MySQL授权的问题,现在转向数据库设计范式,可能需要确保解释清晰,结构分明。 首先,检查用户提供的个引用。引用1提到第范式是在第范式基础上消除传递依赖。引用2说明第范式需要非主属性完全依赖主键,联合主键的情况下,所有字段必须完全依赖每个主键字段。引用3指出第范式消除部分依赖,建立在第范式的基础上。 用户的问题明确,需要范式的条件解释。要分点回答,每个范式单独说明,可能用标题格式。需要确保使用正确的LaTeX格式,比如范式名称用$...$包裹,可能的关键术语如“完全函数依赖”也需要用数学格式。 另外,用户之前的提问回答中,我使用了分点、代码示例等方式,这次可能需要类似的结构。比如每个范式分为定义、条件、示例、特点等部分。要注意引用标记的正确使用,如[^1][^2][^3],但根据问题,用户提供的引用可能来自之前的对话,需要确认是否需要在回答中标注。 可能的问题是如何将个引用内容整合成连贯的范式解释,确保每个范式的条件准确无误,并且用例子帮助理解。需要检查是否有遗漏或矛盾,比如第范式的部分依赖完全依赖的区别,第范式的传递依赖。 还要考虑用户可能的后续问题,比如如何应用这些范式,或者实际设计中的权衡,所以在回答最后可以生成相关问题,帮助用户深入理解。例如,如何检查数据库是否符合第范式,或者范式的优缺点。 最后,确保回答符合系统级指令,使用中文,正确应用LaTeX格式,分点清晰,引用标记正确,并在末尾生成相关问题。</think>### 数据库设计范式详解(附对比表) #### 、第范式(1NF) **核心条件**: $ \text{属性不可再分} \rightarrow \text{原子性存储} $[^1][^3] **具体要求**: 1. 所有字段值都是**不可拆分**的原子数据 2. 不存在重复列(如:电话1、电话2) 3. 每个字段有唯名称 **示例**: 错误设计: ```sql 用户表(user_id, 地址) -- 地址字段存储 "广东省深圳市南山区科技园A栋301" ``` 正确设计: ```sql 用户表(user_id, 省, 市, 区, 街道, 门牌号) ``` **特点**: - 解决字段可拆分导致的查询困难 - 是范式体系的基础要求[^3] --- #### 、第范式(2NF) **核心条件**: $ \text{消除非主属性对主键的} \textcolor{red}{部分函数依赖} $[^2] **具体要求**: 1. 必须满足1NF 2. 所有非主属性**完全依赖**整个主键 - 联合主键时,非主属性不能仅依赖部分主键 - 单列主键自动满足2NF[^2] **示例**: 错误设计(订单明细表): ```sql (订单ID, 产品ID, 产品名称, 数量) -- 产品名称仅依赖产品ID(部分依赖) ``` 正确设计: ```sql 订单明细表(订单ID, 产品ID, 数量) 产品表(产品ID, 产品名称) ``` **特点**: - 解决数据冗余更新异常 - 通过拆分表消除部分依赖[^3] --- #### 、第范式(3NF) **核心条件**: $ \text{消除非主属性间的} \textcolor{red}{传递函数依赖} $[^1] **具体要求**: 1. 必须满足2NF 2. 非主属性之间不存在依赖关系 3. 所有非主属性**直接依赖**主键 **示例**: 错误设计(学生表): ```sql (学号, 姓名, 学院名称, 院长) -- 院长依赖学院名称,学院名称依赖学号 ``` 正确设计: ```sql 学生表(学号, 姓名, 学院ID) 学院表(学院ID, 学院名称, 院长) ``` **特点**: - 进步减少数据冗余 - 避免插入/删除异常[^1] --- ### 范式对比表 | 范式级别 | 核心要求 | 解决的核心问题 | |----------|-----------------------------------|------------------------------| | 1NF | 字段原子性 | 数据存储结构混乱 | | 2NF | 消除部分函数依赖 | 数据冗余更新异常 | | 3NF | 消除传递函数依赖 | 复杂依赖导致的维护困难 | --- ### 设计建议 1. 至少满足3NF是OLTP系统的常规要求 2. 数据仓设计可适当降低范式级别(星型/雪花模型) 3. 实际开发中需平衡范式查询效率
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

技术小羊

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值