精华内容
下载资源
问答
  • 点击上面“蓝字”关注我们 1 范式第范式是为了排除 重复组 的出现,因此要求数据库的每个列的值域都由原子值组成;每个字段的值都只能是单一值。1971年埃德加·科德提出了范式。即表中所有字段都是不可再...
    03d65dad01e2da68f76119eae6cb7149.png点击上面“蓝字”关注我们  cfe26c68d46159f6cf92654f903ac642.png

    1 第一范式

    第一范式是为了排除 重复组 的出现,因此要求数据库的每个列的值域都由原子值组成;每个字段的值都只能是单一值。1971年埃德加·科德提出了第一范式。即表中所有字段都是不可再分的。

    重复组通常会出现在会计账上,每一笔记录可能有不定个数的值。举例来说:f92f2c04ad28b35d4f966ea3ed36442b.png
    “数量”就是所谓的重复组了,而在这种情况下这份资料就不符合第一范式。想要消除重复组的话,只要把每笔记录都转化为单一记录即可:0679c73f42dc4e5f1d0caa88c7411a4a.png

    • 如下联系方式是一个复合属性,就违反了该范式,在数据库中是无法分离出来的。1b70a7d9633657a4d2f4271a76af0255.png

    • 简单改动即可6c7731912a62f8fd10f59ccf3c194a53.png

    即标准的二维表结构。

    第二范式

    前提

    标准的二维表,即第一范式成立

    表中必须存在业务主键,并且非主键依赖于全部业务主键

    例如如下博客表实例afd4e6437fd03380c14eb7b167ff82e4.png

    • 使用用户字段作为PK是否可行呢?
      显然一个用户会对应多个博客记录,且章节标题也能为多个用户编辑,所以单列字段PK失效

    • 使用的复合PK
      然而用户积分字段也只和用户字段依赖,并不依赖于整体的PK,所以依旧不符合第二范式

    • 拆分将依赖的字段单独成表0b2548a290e6d7a66a9827537e441359.png2107d976dd5eb800b0e616b2b86411ff.png

    从上面,我们也可以发现:

    • 若表的PK只有一个字段组成,那么它本就符合第二范式
    • 若是多个字段组成,则需考量是否符合第二范式

    3 第三范式

    表中的非主键列之间不能相互依赖

    依旧看看课程表e8323dade01a075c0614a33a54d1a226.png

    首先,一个字段的PK显然符合第二范式,大部分字段也只依赖于PK,然而对于讲师职称字段其实是依赖于讲师名的,所以不符合第三范式.

    • 将不与PK形成依赖关系的字段直接提出单独成表即可959e44b95bc47b5934560c076ae6b621.pngcab68385d0fd14e879d401bc51f695c4.png
    • 好文!点个好看!
    展开全文
  • 范式:英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的,范式是关系...通常所用到的只是前范式,即:范式(1NF),范式(2NF)...

    范式:英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的,范式是关系数据库理论的基础,也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式,依次是:1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF。通常所用到的只是前三个范式,即:第一范式(1NF),第二范式(2NF),第三范式(3NF)。下面就简单介绍下这三个范式。
    ◆ 第一范式(1NF):强调的是列的原子性,即列不能够再分成其他几列。
    考虑这样一个表:【联系人】(姓名,性别,电话)
    如果在实际场景中,一个联系人有家庭电话和公司电话,那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列(电话)拆分,即:【联系人】(姓名,性别,家庭电话,公司电话)。1NF 很好辨别,但是 2NF 和 3NF 就容易搞混淆。
    ◆ 第二范式(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多次重复的情况。
    ◆ 第三范式(3NF):首先是 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:非主键列是直接依赖于主键,还是直接依赖于非主键列。

    原文地址:http://blog.csdn.net/famousdt/article/details/6921622

    展开全文
  • 这里只讨论前三种范式,分别是第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。 NF是normal form 的缩写。 码:如果在一张表中,一个属性或属性组,被其他所有属性所完全依赖,则称这个属性(或属性组)为该表的...

    1、兵马未动,粮草先行

    要设计出合理的关系型数据库,就需要遵循一些规范。这些不同的规范要求被称为不同的范式,各种范式呈递次规范,要遵循后面的规范先要遵循前面的规范,越高的范式数据库冗余越小。这里只讨论前三种范式,分别是第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。
    NF是normal form 的缩写。
    :如果在一张表中,一个属性或属性组,被其他所有属性所完全依赖,则称这个属性(或属性组)为该表的码(也就是通常所说的键)。
    函数依赖:A—>B,如果根据B属性(或属性组)的值,可以唯一确定A属性的值。则称A依赖于B。例如:学生name—> 学生id,即根据学生id可以唯一确定学生姓名;课程score—> (学生id,课程id),即根据学生id和课程id可以唯一确定某学生的某课程的分数。
    完全函数依赖:A—>B, 如果B是一个属性组,则A属性值的确定需要依赖于B属性组中所有的属性值。例如:课程score—> (学生id,课程id),即只有学生id和课程id都确定了,才能唯一确定某学生的某课程的分数,缺一不可。
    部分函数依赖:A—>B, 如果B是一个属性组,则A属性值得确定只需要依赖于B属性组中某一些值即可。例如:学生name—> (学生id,课程id),即只需要学生id就可以唯一确定学生姓名。
    传递函数依赖:A—>B, B —>C . 如果通过B属性(或属性组)的值,可以唯一确定A属性的值,在通过C属性(属性组)的值可以确定唯一B属性的值,则称 A 传递函数依赖于C。例如:院系id—> 学生id,院系name—> 院系id。即根据学生id可以确定其所在院系id,再根据院系id可以确定院系名称,也就是根据学生id可以唯一确定其所在院系名称。

    2、排兵布阵

    探马来报,敌方来势汹汹信息如下。
    表1

    学生id 学生姓名 院系信息 课程信息
    10001 郭靖 1,机械系 101,计算机基础,60分
    10001 郭靖 1,机械系 102,大学数学,60分
    10002 黄蓉 2,经管系 101,计算机基础,80分
    10002 黄蓉 2,经管系 102,大学数学,99分
    10003 杨过 3,外语系 101,计算机基础,80分
    10003 杨过 3,外语系 102,大学数学,90分
    10004 小龙女 4,艺术系 101,计算机基础,99分
    10004 小龙女 4,艺术系 102,大学数学,70分
    10005 令狐冲 4,艺术系 101,计算机基础,50分
    10005 令狐冲 4,艺术系 102,大学数学,50分

    羽扇纶巾,休要惊慌。
    第一阵:名叫第一范式(1NF),即每一列都是不可再分割的原子数据项。院系信息和课程信息都不符合。
    表2

    学生id 学生姓名 院系id 院系名称 课程id 课程名称 课程分数
    10001 郭靖 1 机械系 101 计算机基础 60
    10001 郭靖 1 机械系 102 大学数学 60
    10002 黄蓉 2 经管系 101 计算机基础 80
    10002 黄蓉 2 经管系 102 大学数学 99
    10003 杨过 3 外语系 101 计算机基础 80
    10003 杨过 3 外语系 102 大学数学 90
    10004 小龙女 4 艺术系 101 计算机基础 99
    10004 小龙女 4 艺术系 102 大学数学 70
    10005 令狐冲 4 艺术系 101 计算机基础 50
    10005 令狐冲 4 艺术系 102 大学数学 50

    第二阵:名叫第二范式(2NF),即非码属性必须完全依赖于码(消除非主键对主键的部分函数依赖)。表2的码为属性组(学生id,课程id),其中课程score完全依赖于这个属性组,但学生name和院系name并不完全依赖于它。所以分拆如下表3和表4。
    表3

    学生id 课程id 课程名称 课程分数
    10001 101 计算机基础 60
    10001 102 大学数学 60
    10002 101 计算机基础 80
    10002 102 大学数学 99
    10003 101 计算机基础 80
    10003 102 大学数学 90
    10004 101 计算机基础 99
    10004 102 大学数学 70
    10005 101 计算机基础 99
    10005 102 大学数学 70

    表4

    学生id 学生姓名 院系id 院系名称
    10001 郭靖 1 机械系
    10002 黄蓉 2 经管系
    10003 杨过 3 外语系
    10004 小龙女 4 艺术系
    10005 令狐冲 4 艺术系

    对表3再次使用第二范式,课程score完全依赖于属性组(学生id和课程id),但课程name并不完全依赖于它。所以分拆如下表5和表6。
    表5 学生课程分数表

    学生id 课程id 课程分数
    10001 101 60
    10001 102 60
    10002 101 80
    10002 102 99
    10003 101 80
    10003 102 90
    10004 101 99
    10004 102 70
    10005 101 50
    10005 102 50

    表6 课程表

    课程id 课程名称
    101 计算机基础
    102 大学数学

    第三阵:叫做第三范式,即任何非主属性不依赖于其它非主属性(消除传递依赖)。看表4,这里学生id是主属性。院系id依赖于学生id,院系名称是一个非主属性,院系id也是一个非主属性,而院系名称又依赖于院系id 。所以,表4拆分为如下表7和表8。
    表7 学生表

    学生id 学生姓名 院系id
    10001 郭靖 1
    10002 黄蓉 2
    10003 杨过 3
    10004 小龙女 4
    10005 令狐冲 4

    表8 院系表

    院系id 院系名称
    1 机械系
    2 经管系
    3 外语系
    4 艺术系

    至此,表1已被完全分解为表5、表6、表7和表8,完全符合三大范式,是设计的比较合理的表。

    3、打扫战场

    表1被分解为表5、表6、表7和表8的过程,是符合三大范式的,其总的思想无外乎明确一件事,即每个表都只保存一类事物,这正符合了数据库表和Java中的实体类的ORM(Object Relational Mapping 对象关系映射)思想。

    表1的形式结果可能更多用于在应用客户端展示信息时使用。

    仍要注意,按照三大范式设计表理论上是可行的,这也大大减少了数据库中数据的冗余。但切不可固步自封,在实际开发业务场景中,有时候为了方便信息的获取与展示,有时可能还需要故意增加个别冗余字段来达到目的。因此,最终的表结构仍要根据具体问题具体分析具体设计。

    展开全文
  • 1NF:字段不可分;  2NF:有主键,非主键字段依赖主键;  3NF:非主键字段不能相互依赖;  解释:  ...不符合范式的例子(关系数据库中create不出这样的表):  表:字段1, 字段2(字段2.1, 字段2.2


    1NF:字段不可分; 

    2NF:有主键,非主键字段依赖主键; 
    3NF:非主键字段不能相互依赖; 

    解释: 
    1NF:原子性 字段不可再分,否则就不是关系数据库; 
    2NF:唯一性 一个表只说明一个事物; 
    3NF:每列都与主键有直接关系,不存在传递依赖; 

    不符合第一范式的例子(关系数据库中create不出这样的表): 

    表:字段1, 字段2(字段2.1, 字段2.2), 字段3 ...... 

    存在的问题: 因为设计不出这样的表, 所以没有问题; 

    不符合第二范式的例子: 

    表:学号, 姓名, 年龄, 课程名称, 成绩, 学分; 

    这个表明显说明了两个事务:学生信息, 课程信息; 

    存在问题: 

    数据冗余,每条记录都含有相同信息; 
    删除异常:删除所有学生成绩,就把课程信息全删除了; 
    插入异常:学生未选课,无法记录进数据库; 
    更新异常:调整课程学分,所有行都调整。 

    修正: 

    学生:Student(学号, 姓名, 年龄); 

    课程:Course(课程名称, 学分); 

    选课关系:SelectCourse(学号, 课程名称, 成绩)。 

    满足第2范式只消除了插入异常。 


    不符合第三范式的例子: 

    学号, 姓名, 年龄, 所在学院, 学院联系电话,关键字为单一关键字"学号"; 

    存在依赖传递: (学号) → (所在学院) → (学院地点, 学院电话) 

    存在问题: 

    数据冗余:有重复值; 

    更新异常:有重复的冗余信息,修改时需要同时修改多条记录,否则会出现数据不一致的情况 

    删除异常 

    修正: 
    学生:(学号, 姓名, 年龄, 所在学院); 
    学院:(学院, 地点, 电话)。 
    作者:sunxing007
    展开全文
  • 数据库范式以及举例

    千次阅读 2020-10-13 14:25:05
    三大范式什么是范式第一范式:列不可再分第二范式:属性完全依赖于主键第三范式:属性不依赖于其他非主属性 属性直接依赖于主键总结 什么是范式 范式是符合某一种设计要求的总结 要想设计一个结构合理的关系...
  • 数据库设计三范式

    2020-11-04 16:36:59
    文章目录三范式作用第一范式第二范式第三范式一对一主外键共享!外键唯一! 三范式作用 按照三范式设计的表不会出现数据冗余!! 实际开发以顾客需求为主,有时会用冗余换速度,打破设计三范式!   第一范式 ...
  •   第一范式:原子性,字段内容不可...第三范式:在第二范式的基础上,消除数据的传递性。   反三范式:增加冗余字段,以空间换时间,提高效率。   解释:(以下举例全为反例) 第一范式:内容不可拆...
  • 数据库三范式详解

    2013-09-11 19:41:25
    数据库三大范式详解 数据库范式1NF 2NF 3NF BCNF(实例) 设计范式(范式,数据库设计范式,数据库的设计范式)是符合某一种级别的关系模式的...下面我们举例介绍第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。
  • 数据库三范式

    2019-09-12 19:57:05
    第一范式:要求有主键,并且...第三范式:所有非主键字段和主键字段之间不能产生传递依赖 举例: 【 学生编号,学生姓名,联系方式 】 中,联系方式就可以再次拆分为 【 邮箱,电话号码 】,不符合第一范式的要求...
  • 目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。 注:本文只讲前三个范式 先看一下下面这样的表(可以对照...
  • 数据库三范式

    2020-06-10 03:30:35
    本文将以较为简洁的文字并举例描述范式范式(1NF)     范式是指关系表R中的每列都是原子不可分的项,即每个属性都是最基本的数据项。这里用代码举个栗子: // 员工类 typedef Employee struct {...
  • 数据库三范式

    2021-03-05 11:14:17
    第三范式(3NF):非主键字段不能相互依赖。 2. 解释 1NF:原子性。 字段不可再分; 2NF:唯一性 。每条数据具有唯一性; 3NF:每列都与主键有直接关系,不存在传递依赖。 举例说明 (1)不符合第一范式的例子 ...
  • 一、范式 理论: 1.范式的目标是确保每列的原子性。 2.如果每列都是不可再分的最小数据单元(也称为最小的原子单元),则满足范式(1NF:First Normal Form)。 举例说明: 不满足范式: 满足范式...
  • 教科书中对于数据库范式倒是都给出了学术性的定义,但实际应用中范式的应用却不甚乐观,这篇文章会用简单的语言和一个简单的数据库DEMO将一个不符合范式数据库一步步从范式实现到范式。  范式的目标 ...
  • 数据库最低标准应当是第三范式 第一范式概念: 实例: ———————————————————————————————————————— 第二范式概念: 实例: 修改实例: ——————————————...
  • 数据库作为底层的存储系统,直接影响业务层的性能,因此,为了能够让开发人员科学规范地使用数据库范式应运而生。本文将以较为简洁的文字并举例描述范式范式(1NF)范式是指关系表R中的每列都是...
  • 举例:数据库中有address这个字段,但我们常常将它分解为province,city,area,这样算是数据库第范式第二范式:在1NF的基础上,每条数据都是唯一的,也就是说每条数据都有primary key与其对应。要求实体的属性完全...
  • 数据库范式举例学习

    2008-11-23 00:43:26
    数据库太久没碰了,但笔试总是会碰上,没办法,现找些资料来学吧。   范式这部分看了半天都不是很清晰,所以找些网上的文章... 3、第三范式(3NF):关系模式R属于第一范式,且每个非主属性都不伟递领带于键码。 ...
  • 为什么需要数据库设计范式第范式(1NF):保证每一列不可再分举例说明:在上面的表中,“家庭信息”和“学校信息”列均不满足原子性的要求,故不满足范式,调整如下:可见,调整后的每一列都是不可再分的,...
  • 第三范式:先满足第二范式,实体中的属性不能是其他实体中的非主属性。即数据库中每一列数据都和主键直接相关,而不能间接相关。 下面举例来解释三大范式。 例如用户信息表中有 地址 这个属性,如果 地址 属性中 ...
  • 目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。...下面我们举例介绍第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。
  • 范式(1NF):关系中的所有分量不可再分,即数据库表中的字段都是单一属性的,不可再分。 在任何一个关系数据库中,范式(1NF)是对关系模式的基本要求,不满足范式(1NF)的数据库就不是关系型数据库...
  • 数据库三范式规则

    2020-07-12 09:22:07
    遵循三范式开发会减少数据冗余、提升系统可扩展性和查询性能。 第一范式: 确定主键字段,拆分多值字段为多列,将重复含义的几个字段...第三范式: 首先满足第二范式,若非主键字段要依赖其他非主键字段,则需要挪到新
  • 数据库设计范式

    2019-06-04 10:58:00
    目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。 而通常我们用的最多的就是第一范式(1NF)、第二范式...

空空如也

空空如也

1 2 3 4 5 ... 7
收藏数 130
精华内容 52
关键字:

数据库第三范式举例