mysql-六大范式

数据库的六大范式，你都知道吗？

前言

​ 数据库范式是关系型数据库设计的基本理论，好的数据库设计离不开数据库范式的支撑，数据库范式规范了数据库的设计原则，使得数据库能更加有效的应用于各种互联网系统当中。本篇文章主要通过结合实际例子给大家介绍一下数据库范式相关的知识，希望能给大家带来一些实际应用的帮助。

1、数据库范式的意义

​ 数据库范式主要是为解决关系数据库中数据冗余、更新异常、插入异常、删除异常问题而引入的设计理念。简单来说，数据库范式可以避免数据冗余，减少数据库的存储空间，并且减轻维护数据完整性的成本。是关系数据库核心的技术之一，也是从事数据库开发人员必备知识。

2、数据库范式分类

​ 范式是评价数据库模式规范化程度从低到高主要有：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般来说，数据库只需满足第三范式(3NF）就行了。

2.1 1NF 第一范式--无重复的列

　　所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。
　　说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

​ 强调属性的原子性约束，要求属性具有原子性，不可再分解。

​ 第一范式存在问题：冗余度大、会引起修改操作的不一致性、数据插入异常、数据删除异常。

举例：

​ 学生表(学号、姓名、年龄、性别、地址)。因为地址可以细分为国家、省份、城市、市区、街道，那么该模式就没有达到第一范式。

不符合：

符合：

2.2 2NF 第二范式--属性完全依赖于主键[消除部分子函数依赖]

　　第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。

​ 第二范式，强调记录的唯一性约束，数据表必须有一个主键，并且没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。

举例：

​ 版本表（版本编码，版本名称，产品编码，产品名称），其中主键是（版本编码，产品编码），这个场景中，数据库设计并不符合第二范式，因为产品名称只依赖于产品编码。存在部分依赖。所以，为了使其满足第二范式，可以改造成两个表：版本表（版本编码，产品编码）和产品表（产品编码，产品名称）

判断一个范式是否符合第二范式

2.3 3NF 第三范式--属性不依赖于其它非主属性[消除传递依赖]

​ 满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

​ 例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

​ 第三范式，强调数据属性冗余性的约束，也就是非主键列必须直接依赖于主键。也就是消除了非主属性对码的传递函数依赖。

举例：

​ 订单表（订单编码，顾客编码，顾客名称），其中主键是（订单编码），这个场景中，顾客编码、顾客名称都完全依赖于主键，因此符合第二范式，但顾客名称依赖于顾客编码，从而间接依赖于主键，所以不能满足第三范式。如果要满足第三范式，需要拆分为两个表：订单表（订单编码，顾客编码）和顾客表（顾客编码，顾客名称）。

​ 说明：3NF的模式肯定满足2NF。产生冗余和异常的两个重要原因是部分依赖和传递依赖。3NF模式中不存在非主属性对码的部分函数依赖和传递函数依赖，性能较好。1NF、2NF一般不适合作为数据库模式，通常需要转换为3NF或者更高级别的范式，这种变换过程称为关系模式规范化处理。

2.4 BCNF（Bovce Codd Normal Form 巴克斯范式）

​ 属于修正的第三范式，是防止主键的某一列会依赖于主键的其他列。当3NF消除了主属性对码的部分函数依赖和传递函数依赖称为BCNF。

​ 特性：

​ 1、所有主属性对每一个码都是完全函数依赖

​ 2、所有主属性对每一个不包含它的码，也是完全函数依赖

​ 3、没有任何属性完全函数依赖与非码的任何一组属性

​ 举例：库存表（仓库名，管理员名，商品名，数量），主键为（仓库名，管理员名，商品名），这是满足前面三个范式的，但是仓库名和管理员名之间存在依赖关系，因此删除某一个仓库，会导致管理员也被删除，这样就不满足BCNF。

2.5 4NF 第四范式

​ 非主属性不应该有多值。如果有多值就违反了第四范式。4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。

​ 举例：用户联系方式表（用户id，固定电话，移动电话），其中用户id是主键，这个满足了BCNF,但是一个用户有可能会有多个固定电话或者多个移动电话，那么这种设计就不合理，应该改为（用户id，联系方式类型，电话号码）。

​ 说明：如果只考虑函数依赖，关系模式规范化程度最高的范式是BCNF；如果考虑多值依赖则是4NF。

2.6 5NF 第五范式

​ 第五范式属于最终范式，消除了4NF中的连接依赖，第五范式需要满足以下要求：

​ 1、必须满足第四范式

​ 2、表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。

​ 3、一般实际应用中不必考虑第五范式。