前言
数据库范式是关系型数据库设计的基本理论，好的数据库设计离不开数据库范式的支撑，数据库范式规范了数据库的设计原则，使得数据库能更加有效的应用于各种互联网系统当中。本篇文章主要通过结合实际例子给大家介绍一下数据库范式相关的知识，希望能给大家带来一些实际应用的帮助。
1、数据库范式的意义
数据库范式主要是为解决关系数据库中数据冗余、更新异常、插入异常、删除异常问题而引入的设计理念。简单来说，数据库范式可以避免数据冗余，减少数据库的存储空间，并且减轻维护数据完整性的成本。是关系数据库核心的技术之一，也是从事数据库开发人员必备知识。
2、数据库范式分类
范式是评价数据库模式规范化程度从低到高主要有：1NF、2NF、3Nf、BCNF、4NF、5NF。
2.1 1NF 第一范式
强调属性的原子性约束，要求属性具有原子性，不可再分解。
举例：
学生表(学号、姓名、年龄、性别、地址)。因为地址可以细分为国家、省份、城市、市区、街道，那么该模式就没有达到第一范式。
第一范式存在问题：冗余度大、会引起修改操作的不一致性、数据插入异常、数据删除异常。
2.2 2NF 第二范式
第二范式，强调记录的唯一性约束，数据表必须有一个主键，并且没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
举例：
版本表(版本编码，版本名称，产品编码，产品名称)，其中主键是(版本编码，产品编码)，这个场景中，数据库设计并不符合第二范式，因为产品名称只依赖于产品编码。存在部分依赖。所以，为了使其满足第二范式，可以改造成两个表：版本表(版本编码，产品编码)和产品表(产品编码，产品名称)
2.3 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、表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。
一般实际应用中不必考虑第五范式。
途傲科技为中小企业提供网站制作、网站建设、微信H5、微信小程序，多商户平台，多级分销系统，APP开发，手机网站，HTML5多端自适应网站，营销型企业站建设，及对技术人才的培养等都积累与沉淀了丰富的心得和实战经验。
如果您有想法，可以将需求提交给我们【免费提交需求，获取解决方案】
免责声明：文章部分内容收集于互联网，不代表本站的观点和立场，如有侵权请联系删除。
