什么是数据第一、二、三范式？作用是什么？

构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求，即满 足不同的范式。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六 范式（6NF）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。一般说 来，数据库只需满足第三范式（3NF）就行了。下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

3.4.1 第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如 果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一 个实例的信息。例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表 中只出现一次。简而言之，第一范式就是无重复的列。

3.4.2 第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。如
图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部 分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式 就是非主属性非部分依赖于主关键字。

3.4.3 第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2
的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

 

简单的解释：

最基本的数据库范式有三个，第一范式(1NF)，第二范式(2NF)和第三范式(3NF)，分别定义如下，

1NF：如果关系模式R中的每个属性都是单值的，则称R∈1NF。

2NF：如果关系模式R∈1NF，且所有的非主属性完全函数依赖于(每一个候选)码，则称R∈2NF。

3NF：如果关系模式R∈2NF，且不存在非主属性传递函数依赖于码的情况，则称R∈3NF。

 

 

其他人的声音：

数据库设计范式解释(转载)

第一范式（ 1NF ）：在关系模式 R 中的每一个具体关系 r 中，如果每个属性值都是不可再分的最小数据单位，则称 R 是属于第一范式的关系。

第二范式（ 2NF ）：如果关系模式 R （ U ， F ）中的所有非主属性都完全依赖于任意一个候选关键字，则称 R 是属于第二范式的。

第三范式（ 3NF ）：如果关系模式 R （ U ， F ）中的所有非主属性对任何候选关键字都不存在传递信赖，则称 R 是属于第三范式的。

第一范式是关系数据库的最小要求

比如

 

姓名                     性别                     身高

Billy                    Male               180CM

这就是第一范式 .

如果改成

                                                        三                                  围     

姓名                     性别                     胸围          臀围          腰围

这个就不是第一范式了 .

 

第二范式说通俗一点就是不存在部分依赖 , 举例如下 :

促销员的销量表 , 字段为促销员 OID, 产品 OID, 产品颜色 , 产品重量

业务上主键应该为 促销员 OID 和产品 OID

但是产品颜色和产品重量显然依赖于产品 OID, 不能因为某个促销员长得漂亮产品颜色就艳丽一些 .

所以产品颜色和产品重量就部分依赖于候选主键促销员 OID 和产品 OID, 这样就满足第二范式 .

 

 

第三范式说通俗一点就是不存在传递依赖 . 举例如下 :

促销员表 , 字段为促销员 OID, 所属销售部 OID, 销售部地址 .

那么促销员 OID 是业务主键 , 由于只有一个字段做主键 , 所以肯定不存在部分依赖

但是这个存在传递依赖

促销员 OID 决定了所属销售部 OID, 而所属销售部又能决定销售部地址 .

所以销售部地址间接依赖于销售部 OID

于是存在传递依赖 .

 

 

由于我们采用 OID 一个字段做表的主键 , 所以肯定满足第二范式 . 至于满不满足第三范式就要分析一下了 .

但是有些情况下是需要保存历史信息的

比如销售部的地址变动了

这些另当别论 , 打破第三范式就好了

另外联合查询的性能损失很大 , 有时候破坏范式来换取报表的运行效率也是值得的 .

 

 

其他人的声音二：

数据库范式（转）

关键字: 数据库 范式

注:

表在定义中被称为关系,记作R

字段在定义中被称作属性

模式:数据库中有三种模式,外模式,内模式,模式

粗体是关键字的意思

斜体为外键

 

第一范式

定义：如果关系R 中所有属性的值域都是单纯域，那么关系模式R是第一范式的

那么符合第一模式的特点就有

1)有主关键字

2)主键不能为空，

3)主键不能重复,

4)字段不可以再分

例如：

 StudyNo   |   Name   |   Sex   |   Contact

20040901      john         Male      Email:kkkk@ee.net,phone:222456

20040901      mary         famale   email:kkk@fff.net phone:123455

以上的表就不符合，第一范式：主键重复(实际中数据库不允许重复的)，而且Contact字段可以再分

所以变更为正确的是

 StudyNo   |   Name   |   Sex   |      Email         |      Phone

20040901      john         Male       kkkk@ee.net  222456

20040902     mary         famale    kkk@fff.net    123455

 

第二范式：

定义：如果关系模式R是第一范式的，而且关系中每一个非主属性不部分依赖于主键，称R是第二范式的。

所以第二范式的主要任务就是

满足第一范式的前提下，消除部分函数依赖。

StudyNo   |   Name   |   Sex   |         Email         |      Phone    |   ClassNo  | ClassAddress

01                  john        Male       kkkk@ee.net     222456      200401            A楼2

01                   mary       famale    kkk@fff.net       123455      200402            A楼3

这个表完全满足于第一范式,

主键由StudyNo和ClassNo组成，这样才能定位到指定行

但是,ClassAddress部分依赖于关键字(ClassNo-〉ClassAddress),

所以要变为两个表

表一

StudyNo   |   Name   |   Sex   |      Email         |      Phone |   ClassNo 

      01            john         Male       kkkk@ee.net  222456   200401      

      01           mary         famale    kkk@fff.net    123455      200402     

表二

 ClassNo  | ClassAddress

 200401      A楼2

 200402      A楼3

 

 

第三范式：

满足第二范式的前提下，消除传递依赖。

例:

StudyNo   |   Name   |   Sex   |      Email         |      bounsLevel   |   bouns

20040901      john         Male       kkkk@ee.net   优秀                    $1000

20040902     mary         famale    kkk@fff.net       良                         $600

这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖

更改为：

StudyNo   |   Name   |   Sex   |      Email         |      bouunsNo

20040901      john         Male       kkkk@ee.net   1

20040902     mary         famale    kkk@fff.net       2

bounsNo   |   bounsLevel   |   bouns

1                   优秀                $1000

 2                 良                   $600

这里我比较喜欢用bounsNo作为主键，

基于两个原因

1）不要用字符作为主键。可能有人说：如果我的等级一开始就用数值就代替呢？

2）但是如果等级名称更改了，不叫 1，2 ，3或优、良，这样就可以方便更改，所以我一般优先使用与业务无关的字段作为关键字。

 

一般满足前三个范式就可以避免数据冗余。

 

第四范式：

主要任务：满足第三范式的前提下，消除多值依赖

product   | agent |  factory

Car            A1        F1

Bus           A1         F2

Car            A2         F2

在这里，Car的定位，必须由 agent 和 Factory才能得到（所以主键由agent和factory组成）,可以通过 product依赖了agent和factory两个属性

所以正确的是

表1                              表2：

product   |   agent            factory  |   product

Car            A1                  F1            Car

Bus            A1                  F2            Car

Car            A2                  F2             Bus

 

第五范式：

定义: 如果关系模式R中的每一个连接依赖, 都是由R的候选键所蕴含, 称R是第五范式的

看到定义，就知道是要消除连接依赖,并且必须保证数据完整

例子

A   |   B  |   C

a1      b1   c1

a2      b1   c2

a1      b2  c1

a2      b2   c2

如果要定位到特定行，必须三个属性都为关键字。

所以关系要变为 三个关系，分别是A 和B,B和C ，C和A

如下：

表1                      表2                  表3

A   |   B               B   |   C         C    |    A

a1      b1            b1      c1         c1      a1            

a1      b2            b1      c2         c1      a2

 

         范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦，但是操作难，因为需要联系多个表才能得到所需要数据，而且越高范式性能就会越差。要权衡是否使用更高范式是比较麻烦。

      一般我在做项目中都，用得最多的也就是第三范式，我认为使用到第三范式也就足够了，性能好

而且方便管理数据