MySQL之数据库三大范式
一、什么是范式？
范式是数据库遵循设计时遵循的一种规范，不同的规范要求遵循不同的范式。
（范式是具有最小冗余的表结构）
数据库有六种范式（1NF/2NF/3NF/BCNF/4NF/5NF）
标题为什么是三大范式呢？？
首先我们最常用的就是第一范式、第二范式、第三范式
并且数据库设计时只需遵循这三个范式即可。
二、 三大范式
第一范式(1NF)
－列都是不可再分第一范式的目标是确保每列的原子性:如果每列都是不可再分 的最小数据单元（也称为最小的原子单元），则满足第一范式（1NF）
第二范式(2NF)
－每个表只描述一件事情
首先满足第一范式，并且表中非主键列不存在对主键的部分依赖第二范式要求每个表只描述一件事情
第三范式(3NF)
－ 不存在对非主键列的传递依赖
第三范式定义是，满足第二范式，并且表中的列不存在对非主键列的传递依赖。也就是（要求每一列数据都和主键直接相关而不能间接相关）优点：
- 减少数据冗余：避免相同数据在多个地方重复存储，减少存储空间需求。
- 确保数据一致性：通过消除传递依赖，减少因数据更新不一致导致的错误。
- 简化数据管理：使数据库结构更清晰，便于维护和扩展。
primary key(id)
| id | name | sex_code | sex_desc | phone | address |
|---|---|---|---|---|---|
| 001 | 张三 | 0 | 男 | 17835201234 | 山西省运城市xx村 |
| 002 | 李四 | 0 | 男 | 17735204567 | 山西省吕梁市yy村 |
| 003 | 王五 | 1 | 女 | 18835207890 | 山西省太原市zz村 |
表中sex_desc依赖于sex_code，而sex_code依赖于id(主键)，从而推出sex_desc依赖于id(主键)；sex_desc不直接依赖于主键，而是通过依赖于非主键列而依赖于主键，属于传递依赖，不符合3NF。
修改表使满足3NF后：
学生表(student) primary key(id)
| id | name | sex_code | phone | address |
|---|---|---|---|---|
| 001 | 张三 | 0 | 17835201234 | 山西省运城市xx村 |
| 002 | 李四 | 0 | 17735204567 | 山西省吕梁市yy村 |
| 003 | 王五 | 1 | 18835207890 | 山西省太原市zz村 |
性别代码表(sexcode) primary key(sex_code)
| sex_code | sex_desc |
|---|---|
| 0 | 男 |
| 1 | 女 |
将原来的student表进行拆分后，两个表都满足3NF
三、三大范式的缺点
数据冗余消除过度：三大范式的设计原则是尽量消除数据冗余，使每个数据项只在数据库中存储一次。然而，过度消除冗余可能导致数据库的关系复杂化，增加了查询和维护的复杂性。有时候，在某些情况下，一些冗余数据可能会提高查询性能或简化数据处理逻辑，但三大范式的设计原则不允许这种冗余存在。
查询性能受影响：三大范式的设计原则使得数据库中的数据被分解为多个关系表，这样在进行复杂查询时需要进行多个表的连接操作。这样的查询操作可能会增加数据库的负载，导致查询性能下降。尤其是在大型数据库中，复杂的查询可能需要花费大量的时间来执行。
数据更新复杂：三大范式的设计原则使得数据库中的数据被分解为多个关系表，这样在进行数据的插入、更新和删除操作时需要同时更新多个表。这样的操作可能会增加数据更新的复杂性，容易出现数据不一致的问题。同时，由于多表更新的复杂性，可能需要使用事务来保证数据的一致性，进一步增加了数据库的负载和复杂性。
数据完整性限制：三大范式的设计原则强调数据的一致性和完整性，要求每个关系表中的数据项必须符合某种规范或约束条件。这些约束条件可能会限制某些特殊情况下的数据录入，使得数据库的灵活性受到了一定的限制。有时候，为了满足特定的需求，可能需要违反某些范式的设计原则。
难以理解和维护：三大范式的设计原则使得数据库中的数据被分解为多个关系表，这样数据库的结构变得更加复杂。这对于数据库管理员和开发人员来说可能会增加理解和维护的难度。尤其是在数据库规模较大、关系较复杂的情况下，可能需要更多的时间和精力来理解和维护数据库的结构。