MySQL的三大范式:

发布于:2025-08-17 ⋅ 阅读:(21) ⋅ 点赞:(0)

目录

键和相关属性的概念:

第一范式:

第二范式:

第三范式:

总结:

反范式化:


在关系型数据库中,关于数据表设计的基本原则,规则就称为范式。

范式是关系数据库理论的基础,也就是在设计数据库结构过程中所要遵循的规则和指导方法。

关系数据库常见的六种范式,按照范式级别从低到高是:第一范式、第二范式、第三范式、巴斯-科德范式、第四范式和第五范式(完美范式)。

范式的设计越高阶,冗余度越低,同时高级的范式一定符合低阶的范式要求。

有时候为了提高某些查询性能,可能会破坏范式规则,也就是反规范化。

键和相关属性的概念:

数据库中的键右一个或者多个属性组成。数据库中常用的几种键和属性的定义。

超键:

能唯一标识一条记录的任意属性组合。

候选键:

不含多于属性的最小超键,一个表可由多个候选键。

主键:

从候选键中选定,唯一标识记录且不允许为空值。

外键:

关联另一表主键的属性,也就是在一个表中为主键,而在另一个表中为非主键。

唯一键:

保证列值唯一但允许为空,一个表可有多个唯一键。

索引:

提高查询速度的数据结构。

主属性:

包含在任一候选键中的属性。

非主属性:

不包含在任何候选键中的属性。

第一范式:

第一范式主要是确保表中每个字段必须具有原子性,也就是每个字段不可再次拆分的最小数据单元。每个属性必须具有单个值。能否拆分是具有主观性的,根据需求来进行判断。

第二范式:

第二范式要求,在满足第一范式的基础上,还需要满足数据表里的每一条数据记录,都是可唯一标识的。而且所有非主键字段,都必须完全依赖主键的所有属性,不能只依赖主键的一部分。通过主键就能知道所有的对应行的的所有字段的值。每张表只能描述一种数据实体。

如果存在不完全依赖的字段可以将这些字段和依赖主关键字重新形成一个表。新表与旧表之间是一对多的关系。

第三范式:

第三范式在第二范式的基础上,确保数据表中的每一个非关键字段都和主键字段直接相关,也就是数据表中所有非主键字段不能依赖于其他非主键字段。非主键之间不能有依赖关系,必须相互独立。

总结:

第一范式(1NF):确保每列的值都是不可分割的原子值。确保每个字段只存储一个值。

第二范式(2NF):在满足第一范式的基础上,确保每个非主属性完全依赖于主键。消除部份依赖,确保数据的完整性。

第三范式(3NF):在满足第二范式的基础上,确保每个非主属性不传递依赖于主键。消除传递依赖,确保数据的独立性。

范式有助于消除数据库中的数据冗余,但是有可能会降低查询的效率,设计出的数据表越多,冗余度越低,在进行查询时需要进行关联多张表,可能会导致索引无效。

反范式化:

如果数据库中数据量比较大,完全按照范式设计数据表,读取数据会产生大量的关联查询,在一定程度上会影响数据库的读性能。可能会为了性能和读取效率违反范式原则,通过增加少量的冗余来提高数据库的读性能,减少关联查询,实现空间换取时间的目的。

比如说:如果经常通过表A和表B通过关联查询查询某个字段,那么可以在表A中添加这个字段,就不用进行关联查询。

反范式虽然能通过空间换时间,提升效率查询,但是也会造成:

存储空间变大。一个表中进行修改,另一个表中的冗余字段也需要进行修改。采用存储过程来支持数据的更新、删除等操作,会非常消耗系统资源。数据量小的情况下,不能体现出性能的优势,反而会让数据库的设计更加复杂。

只有当冗余信息有价值或者能大幅度提升查询效率,可以采取反范式进行优化。

在增加冗余字段时,尽量添加不需要经常修改且查询时不可获取。

注意:

在实际设计中需要权衡范式规范和查询效率,所以根据数据量和查询需求可以结合范式规范和反范式来设计表中的字段信息。


网站公告

今日签到

点亮在社区的每一天
去签到