原文: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)的更多相关文章

  1. 数据库范式(1NF/2NF/3NF)

    本文转载自数据库范式(1NF/2NF/3NF) 概述 范式:英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的,范式 ...

  2. 数据库范式(1NF 2NF 3NF BCNF)

    http://blog.csdn.net/xuxurui007/article/details/7738330 http://www.cnblogs.com/laodao1/archive/2009/ ...

  3. 【转】数据库范式(1NF 2NF 3NF BCNF)

    范式判断流程图 1. 四种范式之间关系 2.第二范式.第三范式.BCNF区别: 2NF:非主键列和主键列之间,是完全依赖于主键,还是依赖于主键的一部分(只依赖某个主键): 3NF:非主键列之间,不存在 ...

  4. 【转】数据库范式(1NF 2NF 3NF BCNF)详解一

    以下内容转自:http://jacki6.iteye.com/blog/774866 --------------------------------------------分割线---------- ...

  5. 数据库范式(1NF 2NF 3NF BCNF)详解一

    数据结构设计模式编程制造 数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的.结构明晰的,同时,不会发生插入(insert).删除(delete)和更新(update)操作异常 ...

  6. 数据库范式(1NF 2NF 3NF BCNF)详解

    数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的.结构明晰的,同时,不会发生插入(insert).删除(delete)和更新(update)操作异常.反之则是乱七八糟,不仅给 ...

  7. 转:数据库范式(1NF 2NF 3NF BCNF)

    数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的.结构明晰的,同时,不会发生插入(insert).删除(delete)和更新(update)操作异常.反之则是乱七八糟,不仅给 ...

  8. 【转】数据库范式(1NF 2NF 3NF BCNF)详解二

    以下内容转自:http://jacki6.iteye.com/blog/774889 -------------------------分割线----------------------------- ...

  9. 数据库三大范式(1NF,2NF,3NF)及ER图

    数据库三大范式(1NF,2NF,3NF)及ER图 百度官方解释: 设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据 ...

随机推荐

  1. hdu3685(几何重心与凸包结合)

    题意:给一个多边形(有可能是凹多边形).问有多少种可以使得它稳定放置的方式.当然稳定的原则就是重心做垂线在支撑点之内. 解法:由于有可能是凹多边形,所以先求出多边形的凸包,这是在放置时候会接触地面的全 ...

  2. linux 登陆key生成

    1.登录A机器 2.ssh-keygen -t rsa,将会生成密钥文件和私钥文件 id_rsa,id_rsa.pub或id_dsa,id_dsa.pub Generating public/priv ...

  3. hdu 5371 Hotaru's problem【manacher】

    题目链接: http://acm.hdu.edu.cn/showproblem.php? pid=5371 题意: 给出一个长度为n的串,要求找出一条最长连续子串.这个子串要满足:1:能够平均分成三段 ...

  4. [译]GLUT教程 - 修改菜单

    Lighthouse3d.com >> GLUT Tutorial >> Pop-up Menus >> Modifying Menus 肯定会有菜单需要被修改的状 ...

  5. 【Python web自动化】之读取配置文件参数,利用cookie返回值进行跳过验证码进行登录操作

    当进行Python的Web自动化时,会涉及到验证码问题,该如何跳过执行呢,下面请看代码: 1.首先新建配置文件*.ini格式 config.ini [db] #基础地址: baseurl = http ...

  6. StarUML破解教程

    StarUML破解教程 StarUML官方下载地址:http://staruml.io/download StarUML是一个非常好用的画UML图的工具,但是它是收费软件,以下是破解方法: 1.使用E ...

  7. 【智力题】IO——行测、笔试、面试中遇到的

    昨天(05.23)下午去参加了明源软件的暑期实习宣讲+笔试,第一次听说这个行业,行业和笔试风格完全不一样啊,5道行测智力题+1个问答+ 斐波那契数列 + 洗牌算法(思想.流程图.代码),今年回来后线上 ...

  8. mysql如何监测是否命中索引?

    使用执行计划. 什么是执行计划? EXPLAIN SELECT …… 变体: 1. EXPLAIN EXTENDED SELECT …… 将执行计划“反编译”成SELECT语句,运行SHOW WARN ...

  9. Wooden Sticks(hdu1051)

    Wooden Sticks Time Limit:1000MS     Memory Limit:32768KB     64bit IO Format:%I64d & %I64u Submi ...

  10. EasyNVR结合阿里云/腾讯云CDN实现微信/小程序直播的方案

    背景需求: 许多客户有这样的需求:微信公众号做为平台来对摄像机进行直播:可以让用户随时随地打开公共号就可以观看:保证画面的流畅性:保证视频的并发访问量等. 问题分析: 虽然需求看似很简单,其实真正实现 ...