本篇内容主要讲解“数据库的六大范式知识是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“数据库的六大范式知识是什么”吧!
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、表必须可以分解为较小的表,除非那些表在逻辑上拥有与原始表相同的主键。
一般实际应用中不必考虑第五范式。
到此,相信大家对“数据库的六大范式知识是什么”有了更深的了解,不妨来实际操作一番吧!这里是亿速云网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。