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

数据库(第一范式,第二范式,第三范式)数据库(第一范式,第二范式,第三范式)范式:英文名称是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)
全栈程序员-站长的头像全栈程序员-站长


相关推荐

  • Set集合实现有序

    Set集合实现有序今天面试问到Set集合实现有序的问题,发现集合这部分知识要补一补…. 以下所有api描述来源:https://docs.oracle.com/javase/7/docs/api/实现Set接口的类如下,其中最常见的HashSet和TreeSet。InterfaceSet<E>AllKnownImplementingClasses:AbstractSet, Concurren…

    2022年5月28日
    78
  • OllyDBG 激活成功教程入门教程「建议收藏」

    OllyDBG 激活成功教程入门教程「建议收藏」原链接:https://www.cnblogs.com/ECJTUACM-873284962/p/7653285.html一、OllyDBG的安装与配置OllyDBG版的发布版本是个ZIP压缩包,只要解压到一个目录下,运行OllyDBG.exe就可以了。汉化版的发布版本是个RAR压缩包,同样只需解压到一个目录下运行OllyDBG.exe即可:OllyDBG中各个窗口的功能如上图。简单解释一下各个窗口的功能,更详细的内容可以参考TT小组翻译的中文帮助:反汇编窗口:显示被调试

    2022年9月21日
    2
  • Android屏幕手写签名的实现-详细篇

    Android屏幕手写签名的实现-详细篇

    2021年3月12日
    246
  • java关于日期的运算等处理方法

    java关于日期的运算等处理方法

    2021年4月30日
    152
  • maven快照更新策略_eclipse更新maven包

    maven快照更新策略_eclipse更新maven包1、为什么会有快照?开发中,A项目依赖于项目B,没有快照时,B每次改动我们就需要赋予给他一个新版本号,然后在A的pom.xml中修改B的版本,这不仅浪费版本号,而且会带来很多的沟通成本。快照就是为了解决这个问题而生的,每次B发布到私服,maven都会将B打上时间戳,A更新时会检查B的时间戳,如果晚于本地仓库B的时间戳,那么就会进行更新。2、快照更新策略注意,快照并不是每次ins

    2022年10月4日
    2
  • 小旋风虚拟服务器怎么用,超级小旋风asp服务器软件使用图文教程

    小旋风虚拟服务器怎么用,超级小旋风asp服务器软件使用图文教程超级小旋风asp服务器软件是由残剑无敌[1]在NETBOX核心下开发的一套强大简洁的ASPWEB服务器软件,使用这个软件的您完全可以抛弃体积庞大的WINNT,WIN2000服务器系统及漏洞百出的IIS了。可以在任何一个系统上调试和发布ASP程序。目前测试通过的操作系统为:Windows98;Windows98SE;WindowsME;WindowsNT+IE4;Windows2000;W…

    2025年7月25日
    3

发表回复

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

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