04-数据库范式

一、总结

1、概念

  在设计关系型数据库时,需要遵从不同的规范要求,设计出合理的数据库,这些不同的规范要求称为不同的数据库范式;

  范式:是离散数学中的知识,是为了解决数据存储与优化的问题,数据保存之后,凡是能通过关系寻找出来的数据,坚决不再重复存储,最终的目的是为了减少数据的冗余;

2、目前的关系型数据库范式有六种:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF,又称完美范式);

3、满足最低要求的范式是第一范式,越高的范式数据库冗余越小,数据库一般只需要满足第三范式就行了;

4、范式是一种分层结构的规范,分为六层,每一层都比上一层更加严格,若要满足下一层范式,前提是满足了上一层范式,1NF是最底层的,要求最低,5NF是最高层,最严格;

5、在数据库设计中,范式要解决的问题就是节省存储空间,但是数据库不单是要解决空间存储的问题,还要保证数据库的效率,所以数据库的设计不可能完全按照范式的要求实现,所以一般情况下,只要满足3NF即可,所以范式在数据库设计当中只有指导意义,不是强制的规范;

6、简单的理解就是:

  第一范式(1NF)要求属性不可分割,每个字段都应该是不可拆分的;

  第二范式(2NF)要求表中要有主键,表中其他字段都依赖主键;

  第三范式(3NF)要求表中不能有其他表中存在的的相同字段的信息,通常通过外键关联,或者ID去联查;

二、几种范式的介绍

1、第一范式(1NF)

  第一范式要求表的字段具有原子性(不可再拆),意思就是在表设计时,字段存储的数据,在取出来使用之前如果还需要额外的拆分处理才能使用,那么就说表的设计不满足第一范式;

例如:

不满足第一范式的表:

 满足第一范式的表:

 2、第二范式(2NF)

  第二范式不允许表中出现部分依赖,在表设计的过程中,如果有复合主键,且表中有其他字段并不是由整个主键来确定,而是依赖主键中的某个字段,存在字段依赖主键的部分的问题,称为部分依赖,第二范式就是要解决这个问题;

例如:

不满足第二范式的表:

 注:例如上表中,复合主键是老师名称和班级,但是表中的性别只是依赖老师,教室只是依赖班级,性别并不依赖班级,教室也不依赖讲师,这就出现了性别和教室依赖主键的一部分,也就是部分依赖,这就不符合第二范式了;

解决办法:

(1):拆表,将性别和讲师单独成表,班级和教室也单独成表

(2)取消复合主键,使用逻辑主键(比如ID,没有实际意义的字段)

3、第三范式(3NF)

要满足第三范式,必须要满足第二范式,理论上讲,一张表中的字段都应该直接依赖主键,如果表中存在一个字段,是通过某个非主键字段来实现最终依赖主键的,这种关系称为传递依赖,第三范式就是要解决传递依赖的问题的;

例如:

不满足第三范式的表

  注:以上表的设计中,ID是逻辑主键(没有业务主键),性别依赖老师存在,老师依赖主键,教室依赖班级,班级依赖主键,所以性别和教室都存在传递依赖,不满足第三范式;

解决办法:把存在传递依赖的字段,以及依赖字段本身单独取出来形成一个表,然后再需要的时候,使用ID映射join查出来;

对于关系型数据库来说,满足第三范式就已经足够了,巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)在数据库博主还不清楚有什么实际意义,如下做简单介绍

4、巴斯-科德范式(BCNF)

定义: 关系模式R<U,F>中,若每一个决定因素都包含码,则R<U,F>属于BCFN。

理解: 根据定义我们可以得到结论,一个满足BC范式的关系模式有:

(1)所有非主属性对每一个码都是完全函数依赖;
(2)所有主属性对每一个不包含它的码也是完全函数依赖;
(3)没有任何属性完全函数依赖于非码的任何一组属性。

5、第四范式(4NF)

定义: 限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。

理解: 显然一个关系模式是4NF,则必为BCNF。也就是说,当一个表中的非主属性互相独立时(3NF),这些非主属性不应该有多值,若有多值就违反了4NF。

6、第五范式(5NF)

要求:

(1)必须满足第四范式;
(2)表必须可以分解为较小的表,除非那些表在逻辑上拥有与原始表相同的主键;

第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况,而第五范式则处理相互依赖的多值情况。

参考网址:

https://blog.csdn.net/weixin_43433032/article/details/89293663

原文地址:https://www.cnblogs.com/jialanyu/p/13433157.html