篇一：数据库设计三大范式
数据库设计三大范式
为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式
在实际开发中最为常见的设计范式有三个：
1．第一范式(确保每列保持原子性)
第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。
实例：如以下订单表，买家地址列并不符合第一范式，需要继续拆分
拆分后
上表所示的订单遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。
2．第二范式(确保表中的每列都和主键相关)
第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
将上述订单表拆分成多张表，拆分后如下图
3．第三范式(确保每列都和主键列直接相关,而不是间接相关)
第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。要求一个关系中不包含已在其它关系已包含的非主关键字信息
上述表中，虽然单价和订购数量可以计算出总价，但是单价是直接和商品相关，并不和订单直接相关，所以不满足第三范式，需要继续拆分
篇二：数据库三范式(六范式)--通俗易懂
数据库三范式（六范式）--通俗易懂
数据库范式是数据库设计中必不可少的知识，没有对范式的理解，就无法设计出高效率、优
雅的数据库。甚至设计出错误的数据库。而想要理解并掌握范式却并不是那 么容易。教科
书中一般以关系代数的方法来解释数据库范式。这样做虽然能够十分准确的表达数据库范
式，但比较抽象，不太直观，不便于理解，更难以记忆。
本文用较为直白的语言介绍范式，旨在便于理解和记忆，这样做可能会出现一些不
精确的表述。但对于初学者应该是个不错的入门。我写下这些的目的主要是为了加强 记忆，
其实我也比较菜，我希望当我对一些概念生疏的时候，回过头来看看自己写的笔记，可以快
速地进入状态。如果你发现其中用错误，请指正。
下面开始进入正题：
一、基础概念
要理解范式，首先必须对知道什么是关系数据库，如果你不知道，我可以简单的不
能再简单的说一下：关系数据库就是用二维表来保存数据。表和表之间可以??（省略10W
字）。
然后你应该理解以下概念：
实体：现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”
等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚
拟的，不如说“老师与学校的关系”。
属性：教科书上解释为：“实体所具有的某一特性”，由此可见，属性一开始是个逻辑概念，
比如说，“性别”是“人”的一个属性。在关系数据库中，属性又是个物理概念，属性可以
看作是“表的一列”。
元组：表中的一行就是一个元组。
分量：元组的某个属性值。在一个关系数据库中，它是一个操作原子，即关系数据库在做任
何操作的时候，属性是“不可分的”。否则就不是关系数据库了。
码：表中可以唯一确定一个元组的某个属性（或者属性组），如果这样的码有不止一个，那
么大家都叫候选码，我们从候选码中挑一个出来做老大，它就叫主码。
全码：如果一个码包含了所有的属性，这个码就是全码。
主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。
非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。
外码：一个属性（或属性组），它不是码，但是它别的表的码，它就是外码。
二、6个范式
好了，上面已经介绍了我们掌握范式所需要的全部基础概念，下面我们就来讲范式。首先要
明白，范式的包含关系。一个数据库设计如果符合第二范式，一定也符合第一范式。如果符
合第三范式，一定也符合第二范式?
第一范式（1NF）：属性不可分。
在前面我们已经介绍了属性值的概念，我们说，它是“不可分的”。而第一范式要求属性也
不可分。那么它和属性值不可分有什么区别呢？给一个例子：
name tel age
大宝 13612345678 22
小明 13988776655 010－1234567 21
Ps：这个表中，属性值“分”了。
name tel age
手机 座机
大宝 13612345678 021－9876543 22
小明 13988776655 010－1234567 21
Ps：这个表中，属性 “分”了。
这两种情况都不满足第一范式。不满足第一范式的数据库，不是关系数据库！所以，我们在
任何关系数据库管理系统中，做不出这样的“表”来。
第二范式（2NF）：符合1NF，并且，非主属性完全依赖于码。
听起来好像很神秘，其实真的没什么。
一 个候选码中的主属性也可能是好几个。如果一个主属性，它不能单独做为一个候选码，
那么它也不能确定任何一个非主属性。给一个反例：我们考虑一个小学的教务 管理系统，
学生上课指定一个老师，一本教材，一个教室，一个时间，大家都上课去吧，没有问题。那
么数据库怎么设计？（学生上课表）
学生 课程 老师 老师职称 教材 教室 上课时间
小明 一年级语文（上） 大宝 副教授 《小学语文1》 101 14：30
一个学生上一门课，一定在特定某个教室。所以有（学生，课程）－>教室
一个学生上一门课，一定是特定某个老师教。所以有（学生，课程）－>老师
一个学生上一门课，他老师的职称可以确定。所以有（学生，课程）－>老师职称
一个学生上一门课，一定是特定某个教材。所以有（学生，课程）－>教材
一个学生上一门课，一定在特定时间。所以有（学生，课程）－>上课时间
因此（学生，课程）是一个码。
然而，一个课程，一定指定了某个教材，一年级语文肯定用的是《小学语文1》，那么就有
课程－>教材。（学生，课程）是个码，课程却决定了教材，这就叫做不完全依赖，或者说
部分依赖。出现这样的情况，就不满足第二范式！
有什么不好吗？你可以想想：
1、校长要新增加一门课程叫“微积分”，教材是《大学数学》，怎么办？学生还没选课，而
学生又是主属性，主属性不能空，课程怎么记录呢，教材记到哪呢? ??郁闷了吧?(插入异
常)
2、下学期没学生学一年级语文（上）了，学一年级语文（下）去了，那么表中将不存在一
年级语文（上），也就没了《小学语文1》。这时候，校长问：一年级语文（上）用的什么教
材啊？??郁闷了吧?(删除异常)
3、校长说：一年级语文（上）换教材，换成《大学语文》。有10000个学生选了这么课，改
动好大啊！改累死了??郁闷了吧？（修改异常）
那应该怎么解决呢？投影分解，将一个表分解成两个或若干个表
学生 课程 老师 老师职称 教室 上课时间
小明 一年级语文（上） 大宝 副教授 101 14：30
学生上课表新 课程 教材
一年级语文（上） 《小学语文1》
课程的表 第三范式（3NF）：符合2NF，并且，消除传递依赖
上面的“学生上课表新”符合2NF，可以这样验证：两个主属性单独使用，不用确定其它四
个非主属性的任何一个。但是它有传递依赖！
在哪呢？问题就出在“老师”和“老师职称”这里。一个老师一定能确定一个老师职称。
有什么问题吗？想想：
1、老师升级了，变教授了，要改数据库，表中有N条，改了N次??（修改异常）
2、没人选这个老师的课了，老师的职称也没了记录??（删除异常）
3、新来一个老师，还没分配教什么课，他的职称记到哪？??（插入异常）
那应该怎么解决呢？和上面一样，投影分解：
学生 课程 老师 教室 上课时间
小明 一年级语文（上） 大宝 101 14：30
老师 老师职称
大宝 副教授
BC范式（BCNF）：符合3NF，并且，主属性不依赖于主属性
若关系模式属于第一范式，且每个属性都不传递依赖于键码，则R属于BC范式。
通常
BC范式的条件有多种等价的表述：每个非平凡依赖的左边必须包含键码；每个决定因素必
须包含键码。
BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。满足BC
范式的关系都必然满足第三范式。
还可以这么说：若一个关系达到了第三范式，并且它只有一个候选码，或者它的每个候选码
都是单属性，则该关系自然达到BC范式。
一般，一个数据库设计符合3NF或BCNF就可以了。在BC范式以上还有第四范式、第五
范式。
第四范式：要求把同一表内的多对多关系删除。
第五范式：从最终结构重新建立原始结构。
但在绝大多数应用中不需要设计到这种程度。并且，某些情况下，过于范式化甚至会对数据
库的逻辑可读性和使用效率起到阻碍。数据库中一定程度的冗余并不一定是坏事情。如果你
对第四范式、第五范式感兴趣可以看一看专业教材，从头学起，并且忘记我说的一切，以免
对你产生误导。
[ 本帖最后由 七月十五 于 2008-3-19 11:14 编辑 ]
最新回复
七月十五 at 2008-3-19 11:31:50
数据库范式
2007-01-18 14:00
原文地址: http://blog.csdn.net/fantasylu/archive/2004/07/20/45794.aspx
注:
表在定义中被称为关系,记作R
字段在定义中被称作属性
模式:数据库中有三种模式,外模式,内模式,模式
粗体是关键字的意思
斜体为外键
第一范式
定义：如果关系R 中所有属性的值域都是单纯域，那么关系模式R是第一范式的
那么符合第一模式的特点就有
1)有主关键字
2)主键不能为空，
3)主键不能重复,
4)字段不可以再分
例如：
StudyNo|Name|Sex|Contact
20040901johnMaleEmail:kkkk@ee.net,phone:222456
20040901maryfamaleemail:kkk@fff.net phone:123455
以上的表就不符合，第一范式：主键重复(实际中数据库不允许重复的)，而且Contact字段
可以再分
所以变更为正确的是
StudyNo|Name|Sex|Email|Phone
20040901johnMale kkkk@ee.net 222456
20040902 maryfamale kkk@fff.net 123455
第二范式：
定义：如果关系模式R是第一范式的，而且关系中每一个非主属性不部分依赖于主键，称R
是第二范式的。
所以第二范式的主要任务就是
满足第一范式的前提下，消除部分函数依赖。
StudyNo|Name|Sex|Email|Phone |
ClassNo | ClassAddress
01john Male kkkk@ee.net 222456200401A楼2
02 mary famale kkk@fff.net 123455200402A楼3
这个表完全满足于第一范式,
主键由StudyNo和ClassNo组成，这样才能定位到指定行
但是,ClassAddress部分依赖于关键字(ClassNo-〉ClassAddress),
所以要变为两个表
表一
StudyNo|Name|Sex|Email|Phone |ClassNo
01johnMale kkkk@ee.net 222456200401
02 maryfamale kkk@fff.net 123455200402
表二
ClassNo | ClassAddress
200401A楼2
200402A楼3
第三范式：
满足第二范式的前提下，消除传递依赖。
例:
StudyNo|Name|Sex|Email|bounsLevel|bouns
20040901johnMale kkkk@ee.net优秀$1000
20040902 maryfamale kkk@fff.net 良$600
这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖
更改为：
StudyNo|Name|Sex|Email|bouunsNo
20040901johnMale kkkk@ee.net1
20040902 maryfamale kkk@fff.net 2
bounsNo|bounsLevel|bouns
1 优秀 $1000
2 良 $600
这里我比较喜欢用bounsNo作为主键，
基于两个原因
1）不要用字符作为主键。可能有人说：如果我的等级一开始就用数值就代替呢？
2）但是如果等级名称更改了，不叫 1，2 ，3或优、良，这样就可以方便更改，所以我一
般优先使用与业务无关的字段作为关键字。
一般满足前三个范式就可以避免数据冗余。
第四范式：
主要任务：满足第三范式的前提下，消除多值依赖
product| agent | factory
CarA1 F1
Bus A1F2
CarA2F2
在这里，Car的定位，必须由 agent 和 Factory才能得到（所以主键由agent和factory组成）,
可以通过 product依赖了agent和factory两个属性
所以正确的是
篇三：数据库三大范式
数据库设计三大范式
为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
在实际开发中最为常见的设计范式有三个：
1．第一范式(确保每列保持原子性)
第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。
第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。
上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。
2．第二范式(确保表中的每列都和主键相关)
第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。
订单信息表
这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。
而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。
这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。
3．第三范式(确保每列都和主键列直接相关,而不是间接相关)
第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。
这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。
《数据库三大范式》
由：免费论文网互联网用户整理提供,链接地址：
http://m.csmayi.cn/show/195529.html
转载请保留,谢谢!
- 上一篇：写校园一角的作文
- 下一篇：国学热英语作文
