首页 > 代码库 > 一看就懂的数据库范式介绍(1NF,2NF,3NF,BC NF,4NF,5NF)

一看就懂的数据库范式介绍(1NF,2NF,3NF,BC NF,4NF,5NF)

原文:http://josh-persistence.iteye.com/blog/2200644

一、基本介绍

 

设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。

目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了。

范式的包含关系。一个数据库设计如果符合第二范式,一定也符合第一范式。如果符合第三范式,一定也符合第二范式…

 

数据库基本概念

       要理解范式,首先必须对知道什么是关系数据库,简单的说:关系数据库就是用二维表来保存数据。表和表之间可以……(省略10W字),如果对数据库很熟悉,可以不用理会下面的概念。

 

      实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”,它也可以是虚拟的,不如说“老师与学校的关系”。

      属性:教科书上解释为:“实体所具有的某一特性”,由此可见,属性一开始是个逻辑概念,比如说,“性别”是“人”的一个属性。在关系数据库中,属性又是个物理概念,属性可以看作是“表的一列”。

     元组:表中的一行就是一个元组。

     分量:元组的某个属性值。在一个关系数据库中,它是一个操作原子,即关系数据库在做任何操作的时候,属性是“不可分的”。否则就不是关系数据库了。

      码:表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那么大家都叫   候选码,我们从候选码中挑一个出来做老大,它就叫主码。

     全码:如果一个码包含了所有的属性,这个码就是全码。

     主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。

     非主属性:与上面相反,没有在任何候选码中出现过,这个属性就是非主属性。

 

     外码:一个属性(或属性组),它不是码,但是它别的表的码,它就是外码。

 

     候选码: 若关系中的某一属性或属性组的值能唯一的标识一个元组,而其任何真子集都不能再标识,则称该属性组为(超级码)候选码。

 

 

二、6种范式

       前面说到,范式越高,数据的冗余度越小。其实没有冗余的数据库设计是可以做到的。但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,允许冗余。(最典型的就是在一些数据表中不仅存作为外键的user_id,同样存user_name,这样虽然违反数据库范式增加了user_name字段,但是却提高了效率,减少了获取user_id后再去user表中获取user name的操作)

      所以实际中,我们只需要考虑数据库满足第三范式就可以了,下面以最通俗的方式来解释数据库的范式。

 

第一范式(1NF):属性不可分

          (1NF是对属性的原子性约束,要求属性具有原子性,不可再分解)

name       tel                                                   age

                手机                   座机

Josh        13612345678    021-9876543      22

 

Wang      13988776655    010-1234567      21

   很明显,tel这个属性还可以进行分解,分解成手机和座机这两个属性,不满足第一范式的数据库,不是关系数据库!所以,我们在任何关系数据库管理系统中,做不出这样的“表”来。

 

第二范式(2NF):符合1NF,并且非主属性完全依赖于码。

          (2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性,更通俗说有主键ID)

如果这都不能理解,只能看看如下科学的解释了:

      一个候选码中的主属性也可能是好几个。如果一个主属性,它不能单独做为一个候选码,那么它也不能确定任何一个非主属性。给一个反例:我们考虑一个小学的教务 管理系统,学生上课指定一个老师,一本教材,一个教室,一个时间,大家都上课去吧,没有问题。那么数据库怎么设计?(学生上课表)

 

学生       课程                       老师    老师职称         教材                     教室      上课时间

小明       一年级语文(上)  大宝     副教授          《小学语文1》      101        14:30

 

一个学生上一门课,一定在特定某个教室。所以有(学生,课程)->教室

一个学生上一门课,一定是特定某个老师教。所以有(学生,课程)->老师

一个学生上一门课,他老师的职称可以确定。所以有(学生,课程)->老师职称

一个学生上一门课,一定是特定某个教材。所以有(学生,课程)->教材

一个学生上一门课,一定在特定时间。所以有(学生,课程)->上课时间

因此(学生,课程)是一个码。

 

        然而,一个课程,一定指定了某个教材,一年级语文肯定用的是《小学语文1》,那么就有课程->教材。(学生,课程)是个码,课程却决定了教材,这就叫做不完全依赖,或者说部分依赖。出现这样的情况,就不满足第二范式!有什么不好吗?你可以想想:

       1、校长要新增加一门课程叫“微积分”,教材是《大学数学》,怎么办?学生还没选课,而学生又是主属性,主属性不能空,课程怎么记录呢,教材记到哪呢? ……郁闷了吧?(插入异常)

       2、下学期没学生学一年级语文(上)了,学一年级语文(下)去了,那么表中将不存在一年级语文(上),也就没了《小学语文1》。这时候,校长问:一年级语文(上)用的什么教材啊?……郁闷了吧?(删除异常)

       3、校长说:一年级语文(上)换教材,换成《大学语文》。有10000个学生选了这么课,改动好大啊!改累死了……郁闷了吧?(修改异常)

那应该怎么解决呢?投影分解,将一个表分解成两个或若干个表

 

学生     课程                      老师     老师职称     教室      上课时间

小明     一年级语文(上) 大宝      副教授        101       14:30

 

学生上课表

课程                           教材

一年级语文(上)     《小学语文1》

 

第三范式(3NF):符合2NF,并且,消除传递依赖。

      (3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余)

正如前面所说:没有数据冗余的数据库并不一定是最好的数据库,所以有没有冗余的设计,要综合来考虑。

 

上面的“学生上课表”符合2NF,可以这样验证:两个主属性单独使用,不用确定其它四个非主属性的任何一个。但是它有传递依赖!在“老师”和“老师职称”这里,一个老师一定能确定一个老师职称。

如果不消除这种传递依赖,有可能会出现:

1、老师升级了,变教授了,要改数据库,表中有N条,改了N次……(修改异常)

2、没人选这个老师的课了,老师的职称也没了记录……(删除异常)

3、新来一个老师,还没分配教什么课,他的职称记到哪?……(插入异常)

那应该怎么解决呢?和上面一样,投影分解:

学生      课程                        老师    教室        上课时间

小明      一年级语文(上)   大宝    101         14:30

 

老师      老师职称

大宝      副教授

 

BCNF:符合3NF,并且,主属性不依赖于主属性。

若关系模式属于第二范式,且每个属性都不传递依赖于键码,则R属于BC范式。

 

通常

BC范式的条件有多种等价的表述:每个非平凡依赖的左边必须包含键码;每个决定因素必须包含键码。

 

BC范式既检查非主属性,又检查主属性。当只检查非主属性时,就成了第三范式。满足BC范式的关系都必然满足第三范式。

还可以这么说:若一个关系达到了第三范式,并且它只有一个候选码,或者它的每个候选码都是单属性,则该关系自然达到BC范式。

 

一般,一个数据库设计符合3NF或BCNF就可以了。

 

第四范式:要求把同一表内的多对多关系删除。

 

第五范式:从最终结构重新建立原始结构。

一看就懂的数据库范式介绍(1NF,2NF,3NF,BC NF,4NF,5NF)