数据库设计三范式
设计数据库表的时候所依据的规范,共三个规范:
第一范式
数据库表中不能出现重复记录,每个字段是原子性的不能再分
不符合第一范式的实例:
第一范式1.PNG
存在问题:
最后一条记录和第一条重复(不唯一,没有主键)
联系方式字段可以再分,不是原子性的
第一范式2.PNG
关于第一范式,每一行必须唯一,也就是每个表必须有主键,这是数据库设计的最基本要求,主要采用数值型或定长字符串表示,关于列不可再分,应该根据具体的情况来决定。如联系方式,为了开发上的便利可能就采用一个字段。
第二范式
第二范式是建立在第一范式基础上的,另外要求所有非主键字段完全依赖主键,不能产生部分依赖
实例:
二1.PNG
确定主键:
二2.PNG
以上虽然确定了主键,但此表会出现大量的冗余,主要涉及到的冗余字段为“学生姓名”和“教师姓名”,出现冗余的原因在于,学生姓名部分依赖了主键的一个字段学生编号,而没有依赖教师编号,而教师姓名部分依赖了主键的一个字段教师编号,这就是第二范式部分依赖。
解决:
解决.PNG
如果一个表是单一主键,那么它就是复合第二范式,部分依赖和主键有关系
以上是典型的“多对多”设计
第三范式
建立在第二范式基础上的,非主键字段不能传递依赖于主键字段(不要产生传递依赖)
三1.PNG
上表中,班级名称字段存在冗余,因为班级名称字段没有直接依赖于主键,班级名称字段依赖于班级编号,班级编号依赖于学生编号,这就是传递依赖,解决的办法就是将冗余字段单独拿出来建立表:
解决三.PNG
以上设计是典型的一对多的设计,一存储在一张表中,多存储在一张表中,在多的那张表中添加外键指向一的一方
几个经典的设计:
一对一:
一对多:
多对多:
共享主键.PNG
外键唯一.PNG
实际开发中,数据库设计尽量遵循三范式,但是还是根据实际情况进行取舍,有时可能会拿冗余换速度,最终目的是要满足客户需求
反范式化
没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。具体做法是: 在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,减少了查询时的关联,提高查询效率,因为在数据库的操作中查询的比例要远远大于DML的比例。但是反范式化一定要适度,并且在原本已满足三范式的基础上再做调整的。