数据库三范式
:数据库三范式是指关系型数据库设计中的三种规范化设计原则,旨在减少数据冗余、提高数据一致性和可维护性。
第一范式:规定表中的每一列都应该是不可分割的最小单元。
为什么要这样实现呢?
:举个栗子,大家可能都用过淘宝,京东,在填写收件地址的时候,是不是都要逐一填写 :省、市、区、详细地址。以上其实就是数据库中的某个字段。这就是第一范式的具体应用,如果某一天,政府下了批文,修改了某个区的名字,这样就可以直接在该字段上修改即可。如果全部都写到一起的话,修改就比较麻烦,可能会涉及正则表达式。
第二范式:是在满足第一范式的基础上,规定表中的非主键列不存在对主键的部分依赖。
在满足第一范式的基础上,表中不存在部分依赖,非主键列要完全依赖于主键。(主要是说在联合主键的情况下,非主键列不能只依赖于主键的一部分)
如下学生成绩表(score):
stu_id(学生id)、course_id(课程id)、score(分数)、course_name(课程名)
primary key(stu_id, course_id)
stu_id | course_id | score | course_name |
---|---|---|---|
001 | 1011 | 88 | 高数3-1 |
001 | 1022 | 69 | 计算机组成原理 |
002 | 1011 | 92 | 高数3-1 |
表中主键为stu_id和course_id组成的联合主键。满足1NF;非主键列score完全依赖于主键,stu_id和course_id两个值才能决定score的值;而course_name只依赖于course_id,与stu_id没有依赖关系,它不完全依赖于主键,只依赖于主键的一部分,不符合2NF。
修改使表满足2NF后:
成绩表(score) primary key(stu_id)
stu_id | course_id | score |
---|---|---|
001 | 1011 | 88 |
001 | 1022 | 69 |
002 | 1011 | 92 |
课程表(kc) primary key(course_id)
course_id | course_name |
---|---|
1011 | 高数3-1 |
1022 | 计算机组成原理 |
将原来的成绩表(score)拆分为成绩表(score)和课程表(kc),而且两个表都符合2NF。
第三范式是在满足第一范式和第二范式的基础上,规定表中的列不存在对非主键列的传递依赖。
传递依赖关系指的是:指的是在一个关系(表)中,一个非主键列依赖于另一个非主键列,而那个被依赖的列本身依赖于主键。
该表中,订单编号为主键,顾客名称依赖于顾客编号,这就是对非主键列的传递依赖。
修改之后应该如下: