数据库范式

数据库范式

一般情况下，范式越高，表拆的越多，冗余数据越少，新增数据方便，但是查询时会越麻烦（需要联表查询）

三范式

人人都能看懂的数据库六大范式-CSDN博客

(三)MySQL之库表设计篇：一、二、三、四、五范式、BC范式与反范式详解！_数据库 bc 范式-CSDN博客

实例：

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

第一范式：一列的数据不可分

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

第二范式：要求表中的所有列，其数据都必须依赖于主键。不能有任何一列数据与主键没有关系

SELECT * FROM `zz_student`; 
 | student_id | name | sex | height | department | dean | 
 | 1          | 竹子  | 男   | 185cm | 计算机系    | 竹子老大 |
 | 2          | 熊猫  | 女   | 170cm | 金融系      | 熊猫老大 | 
 
 SELECT * FROM `zz_course`;
 | course_id | course_name |
 | 1 | 语文 |
 | 2 | 数学 |
 | 3 | 英语 |

 SELECT * FROM `zz_score`;
 +----------+------------+-----------+-------+ 
 | score_id | student_id | course_id | score |
 | 1 | 1 | 1 | 95 | 
 | 2 | 1 | 2 | 100 |
 | 3 | 1 | 3 | 88 | 
 | 4 | 2 | 1 | 99 | 
 | 5 | 2 | 2 | 90 | 
 | 6 | 2 | 3 | 95 |

第三范式：要求表中每一列数据不能与主键之外的字段有直接关系。

比如这张学生表zz_student，目前即符合第一范式，也符合第二范式，但看最后的两个字段，department表示当前学生所属的院校，dean则表示这个院系的院长是谁。一般来说，一个学生的院长是谁，首先是取决于学生所在的院系的，因此最后的dean字段明显与department字段存在依赖关系，因此需要进一步调整表结构：

SELECT * FROM `department`;
| department_id | department_name | department_dean |
| 1             | 计算机系          | 竹子老大 | 
| 2             | 金融系            | 熊猫老大 |
SELECT * FROM `zz_student`;
| student_id | name | sex | height | department_id |
| 1          | 竹子  | 男  | 185cm  | 1             | 
| 2          | 熊猫  | 女  | 170cm  | 2             | 

数据库三范式小结

第一范式：确保原子性，表中每一个列数据都必须是不可再分的字段。
第二范式：确保唯一性，每张表都只描述一种业务属性，一张表只描述一件事。
第三范式：确保独立性，表中除主键外，每个字段之间不存在任何依赖，都是独立的。

经过三范式的示例后，数据库中的表数量也逐渐多了起来，似乎设计符合三范式的库表结构，反而更加麻烦了对吗？答案并非如此，因为在没有按照范式设计时，会存在几个问题：

①整张表数据比较冗余，同一个学生信息会出现多条。
②表结构特别臃肿，不易于操作，要新增一个学生信息时，需添加大量数据。
③需要更新其他业务属性的数据时，比如院系院长换人了，需要修改所有学生的记录。

但按照三范式将表结构拆开后，假设要新增一条学生数据，就只需要插入学生相关的信息即可，同时如果某个院系的院长换人了，只需要修改院系表中的院长就行，学生表中的数据无需发生任何更改。

因此，经过三范式的设计优化后，整个库中的所有表结构，会显得更为优雅，灵活性也会更强。