数据库范式

注:

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

字段在定义中被称作属性

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

粗体是关键字的意思

斜体为外键

 

第一范式

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

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

1)有主关键字

2)主键不能为空，

3)主键不能重复,

4)字段不可以再分

例如：

 StudyNo   |   Name   |   Sex   |   Contact

20040901      john         Male      Email:[e-mail],phone:222456

20040901      mary         famale   email:[e-mail] phone:123455

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

所以变更为正确的是

 StudyNo   |   Name   |   Sex   |      Email         |      Phone

20040901      john         Male       [e-mail]  222456

20040902     mary         famale    [e-mail]    123455

 

第二范式：

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

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

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

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

01                  john        Male       [e-mail]     222456      200401            A楼2

01                   mary       famale    [e-mail]       123455      200402            A楼3

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

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

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

所以要变为两个表

表一

StudyNo   |   Name   |   Sex   |      Email         |      Phone |   ClassNo 

      01            john         Male       [e-mail]  222456   200401      

      01           mary         famale    [e-mail]    123455      200402     

表二

 ClassNo  | ClassAddress

 200401      A楼2

 200402      A楼3

 

 

第三范式：

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

例:

StudyNo   |   Name   |   Sex   |      Email         |      bounsLevel   |   bouns

20040901      john         Male       [e-mail]   优秀                    $1000

20040902     mary         famale    [e-mail]       良                         $600

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

更改为：

StudyNo   |   Name   |   Sex   |      Email         |      bouunsNo

20040901      john         Male       [e-mail]   1

20040902     mary         famale    [e-mail]       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

 

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

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

而且方便管理数据