数据库(第一范式,第二范式,第三范式)

数据库(第一范式,第二范式,第三范式)数据库(第一范式,第二范式,第三范式)范式:英文名称是NormalForm,它是英国人E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的,范式是关系数据库理论的基础,也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式,依次是:1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF。通常所用到的只是前三个范式,

大家好,又见面了,我是你们的朋友全栈君。

数据库(第一范式,第二范式,第三范式)

范式:英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的,范式是关系数据库理论的基础,也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式,依次是:1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF。通常所用到的只是前三个范式,即:第一范式(1NF),第二范式(2NF),第三范式(3NF)。

设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。
目前
关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、
第四范式(4NF)和
第五范式(5NF,又称完美范式)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了。

下面就简单介绍下这三个范式。

第一范式(1NF)

强调的是列的原子性,即列不能够再分成其他几列。 


考虑这样一个表:【联系人】(姓名,性别,电话) 

如果在实际场景中,一个联系人有家庭电话和公司电话,那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列(电话)拆分,即:【联系人】(姓名,性别,家庭电话,公司电话)。1NF 很好辨别,但是 2NF 和 3NF 就容易搞混淆。 

说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的设计基本要求,一般设计中都必须满足第一范式(1NF)。不过有些关系模型中突破了1NF的限制,这种称为非1NF的关系模型。换句话说,是否必须满足1NF的最低要求,主要依赖于所使用的关系模型

第二范式(2NF)

首先是 1NF,另外包含两部分内容,一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。 

考虑一个订单明细表:【OrderDetail】(OrderID,ProductID,UnitPrice,Discount,Quantity,ProductName)。 


因为我们知道在一个订单中可以订购多种产品,所以单单一个 OrderID 是不足以成为主键的,主键应该是(OrderID,ProductID)。显而易见 Discount(折扣),Quantity(数量)完全依赖(取决)于主键(OderID,ProductID),而 UnitPrice,ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。 

可以把【OrderDetail】表拆分为【OrderDetail】(OrderID,ProductID,Discount,Quantity)和【Product】(ProductID,UnitPrice,ProductName)来消除原订单表中UnitPrice,ProductName多次重复的情况。

 第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。简而言之,第二范式就是在第一范式的基础上属性完全依赖于主键。

第三范式(3NF)

在1NF基础上,任何非主属性不依赖于其它非主属性[在2NF基础上消除传递依赖]。

第三范式(3NF)是第二范式(2NF)的一个子集,即满足第三范式(3NF)必须满足第二范式(2NF)

首先是 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。 考虑一个订单表【Order】(OrderID,OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity)主键是(OrderID)。 

其中 OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity 等非主键列都完全依赖于主键(OrderID),所以符合 2NF。不过问题是 CustomerName,CustomerAddr,CustomerCity 直接依赖的是 CustomerID(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合 3NF。 

通过拆分【Order】为【Order】(OrderID,OrderDate,CustomerID)和【Customer】(CustomerID,CustomerName,CustomerAddr,CustomerCity)从而达到 3NF。 

第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分它们的关键点在于,2NF:非主键列是否完全依赖于主键,还是依赖于主键的一部分;3NF:非主键列是直接依赖于主键,还是直接依赖于非主键列。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/142252.html原文链接:https://javaforall.net

(0)
全栈程序员-站长的头像全栈程序员-站长


相关推荐

  • mysql数据库去重[通俗易懂]

    mysql数据库去重[通俗易懂]2019独角兽企业重金招聘Python工程师标准>>>…

    2022年10月1日
    4
  • 编译CTK「建议收藏」

    编译CTK「建议收藏」 使用ctkPluginFramework作为插件系统框架的确有着众多开发上的优势。最近收到一些站内信,大家都想使用ctkPluginFramework但是不知道如何编译,这篇教程就来讲一讲ctkPluginFramework插件系统在Windows下的编译过程。准备条件:https://wenku.baidu.com/view/83ef9e1be97101f69e3143323968011ca3…

    2022年5月3日
    76
  • 几种常用的矩阵范数表示_向量范数怎么求

    几种常用的矩阵范数表示_向量范数怎么求按道理讲,这些东西应该熟记于心的。但是自己真心不喜欢记这种东西,看到一个总结不错的博客,转载过来以便于自己查看把!原文1.几种范数矩阵X∈Rm×nX∈Rm×n,σi(X)σi(X)表示XX的第ii大奇异值(即XX′XX′的第ii大特征值的均方根){citerecht2010guaranteed}。rr表示矩阵XX的秩(R

    2025年12月4日
    5
  • 在Ubuntu 18.04上编译Linux内核

    在Ubuntu 18.04上编译Linux内核一、环境说明编译环境我选择了Ubuntu18.04的虚拟机,内核截止2018-10-14最新版为4.18.14,笔者即将编译这个版本请确保磁盘空间足够,笔者之前20G编译到最后空间不足,还得重来如果你想要查看您的空间大小或者扩充磁盘,请查看我的另一篇文章https://blog.csdn.net/qq_36290650/article/details/83057832二、编译步骤…

    2022年7月23日
    22
  • 手把手教你Python学习!(附流程图)「建议收藏」

    手把手教你Python学习!(附流程图)「建议收藏」关注公众号:Python爬虫数据分析挖掘,免费获取更多开源项目源码对于刚开始接触Python的小伙伴来说,没有思路方法,不知道从何开始学习,把软件环境安装好后就不知所措了!接下来我给大家分享下多位大

    2022年7月1日
    24
  • git添加用户名和邮箱「建议收藏」

    git添加用户名和邮箱「建议收藏」想了解更多数据结构以及算法题,可以关注微信公众号“数据结构和算法”,每天一题为你精彩解答。也可以扫描下面的二维码关注

    2025年8月28日
    5

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号