数据库设计三范式
数据库表设计的时候有一定的科学规范,就是三范式
一、第一范式
数据库表中不能出现重复记录,每个字段是原子性的不能再分
理解:记录没有重复的,即使业务信息是重复的,主键不一样,也认为是不同记录;每个字段记录的信息是最小粒度
二、第二范式
第二范式是建立在第一范式基础上的,另外要求所有非主键字段完全依赖主键,不能产生部分依赖
理解:第二范式可以理解不能有联合主键,存在联合主键的时候必然是非主键字段依赖于联合主键中的一个
三、第三范式
建立在第二范式基础上的,非主键字段不能传递依赖于主键字段。(不要产生传递依赖)
例:
学生编号(PK) |
学生姓名 |
班级编号 |
班级名称 |
1001 |
张三 |
01 |
一年一班 |
1002 |
李四 |
02 |
一年二班 |
1003 |
王五 |
03 |
一年三班 |
1004 |
六 |
03 |
一年三班 |
班级名称字段存在冗余,因为班级名称字段没有直接依赖于主键,班级名称字段依赖于班级编号,班级编号依赖于学生编 号,那么这就是传递依赖,解决的办法是将冗余字段单独拿出来建立表
四、几个经典的设计
一对一:第一种方案:分两张表存储,共享主键
第二种方案:分两张表存储,外键唯一
一对多:分2张表存储,在多的一方添加外键,这个外键字段引用一方中的主键字段
多对多:分3张表存储,两张事实表加一个关系表
四、三范式总结
第一范式:有主键,具有原子性,字段不可分割
第二范式:完全依赖,没有部分依赖
第三范式:没有传递依赖
数据库设计尽量遵循三范式,但是还是根据实际情况进行取舍,有时可能会拿冗余换速度,最终用目的要满足业务需求。
五、个人思考
看到数据库三范式就想到了数据仓库,两者的思路基本完全相反,数据仓库没有主键概念,且会刻意制造信息冗余,基本是完全违背了数据库的三范式,毕竟两者的实际应用场景不一样。不过知道了设计的三范式可以更科学的思考一些数据构建问题。
本文地址:https://blog.csdn.net/huobumingbai1234/article/details/85954511