数据库范式.docx

资源描述

数据库范式.docx

《数据库范式.docx》由会员分享，可在线阅读，更多相关《数据库范式.docx（15页珍藏版）》请在冰豆网上搜索。

数据库范式.docx

数据库范式

前言

为什么要写这篇文章呢，从去年年底开始，就和很多做技术的朋友交流过，从数据库设计到数据库架构各个方面的内容。

有一些朋友执着于ORM，执着于所谓的数据库设计，却忘记了一切技术是要为业务服务这个基石。

当然这文章里也有一些自己的理解，想向大家表达。

范式是什么

范式是符合某一种级别的关系模式的集合。

关系数据库中的关系必须满足一定的要求，即满足不同的范式。

目前关系数据库有六种范式：

第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。

满足最低要求的范式是第一范式（1NF）。

在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。

一般说来，数据库只需满足第三范式（3NF）就行了。

范式的原理

∙第一范式（1NF）无重复的列

所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。

如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。

在第一范式（1NF）中表的每一行只包含一个实例的信息。

简而言之，第一范式就是无重复的列。

说明：

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

∙第二范式（2NF）属性完全依赖于主键[消除部分子函数依赖]

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。

第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。

为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。

例如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。

这个惟一属性列被称为主关键字或主键、主码。

第二范式（2NF）要求实体的属性完全依赖于主关键字。

所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。

简而言之，第二范式就是属性完全依赖于主键。

∙第三范式（3NF）属性不依赖于其它非主属性[消除传递依赖]

满足第三范式（3NF）必须先满足第二范式（2NF）。

简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。

那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。

如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。

简而言之，第三范式就是属性不依赖于其它非主属性。

范式的说明

∙第一范式：

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

通俗的理解是字段还可以再分吗？

如过不能，则是符合1NF的设计。

∙第二范式：

2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；

简单的解释，比如你和一个女生约会建立一张表，不用每条约会记录都记录她的身高、体重，将身高体重单独的存在一张表中供查询即可。

∙第三范式：

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

打个比方，比如评论表，如果你将用户ID，用户头像都放在这留言表中，就是不合适的了。

用户头像是依赖于用户ID，而不依赖该评论。

我对范式的理解

一个严格恪守数据库设计范式来进行数据库设计的人，必定是个傻球；

一个没有研究过数据库设计范式就进行数据库设计的人，必定也是个傻球；

在现代数据库设计中，尤其是web2.0的系统中的数据库设计，我可以断言，大多数都是违反2NF、3NF的，少数设计甚至是违反1NF的。

数据库设计范式只是对数据库惯用设计的一些说明，并不能定性为标准。

而从数据库的发展来看，以MySQL举例，随着MySQL实现越来越多的功能，它的宣传材料上会越来越多的出现以前被MySQL所摒弃的复杂设计理念，并且宣称这是MySQL所独创或一贯倡导的。

这是一个数据库系统发展所必然经历的过程。

而这却会给MySQL的使用者以极大的误导，从而忽视了是否新特性是业务所真正需要的。

数据库设计不是一种编程语言这么简单，与面向对象、面向过程无关。

数据库设计代表的是一种与应用开发语言完全不同的思想。

现在绝大多数的程序，无论任何人采用什么方式进行程序开发，其最终还是会回归到对数据库的操作上（当然如果你的程序只是个教学演示则不在此范围内）。

数据库发展

各种缓存方案，说到底是以key为基础的数据解决方案，而数据库与应用层之间的中间件，为了实现逻辑的简单和高性能，更多的也会是基于key的实现。

比如我所使用过的腾讯的TTC。

从下面的列表可以看出当前SNS的网站对于高并发、高性能的数据库解决方案有多么渴求，Facebook贡献了Cassandra、Linkedin贡献了Voldemort、mixi.jp贡献了TokyoCabinet和TokoyTyrant、green.jp贡献了Flare、甚至包括Google的BigTable。

总结

写到这里，我发现单单是这些新的数据库解决方案就有太多可写的内容，而这些已经超过了本文所要说明的主要内容，而现在所写的内容就全当是个引子吧，我写的很意犹未尽。

后面会就反范式设计实例，内存缓存方案、NoSQL数据库等逐渐展开。

数据库三范式，轻松理解

来源：

互联网作者：

古嗣小井发表于：

2009-09-2910:

59　点击：

36889

网上搜罗了一大堆关于数据库范式理解的文章，都是千律一篇的复制粘贴，连例子都是一模一样，拜托有点创意好不，实在看不下去，自己写一篇个人理解三范式的文章。

如果有理解上的不正确之处，请联系我：

279537592＃（#=@）官方定义：

第一范式（1NF）：

数

如果有理解上的不正确之处，请联系我：

279537592＃（#=>@）

官方定义：

第一范式（1NF）：

数据库表中的字段都是单一属性的，不可再分。

我的理解：

第一范式这个不用說了，只要是关系数据库都满足第一范式

官方定义：

第二范式（2NF）：

数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖

我的理解：

在第二范式中组合主键（AB）【注明：

也叫做复合主键】里面的A或者B与其他字段不能存在组合重复，为解决这个问题，通常的做法是咱们不用组合主键，添加一个ID，做为单一主键即可满足第二范式。

如果不想添加ID，请满足组合主键（AB）里面的A或者B与其他字段不能存在组合重复。

如:

不满足第二范式,复合主键中的A与字段C组合重复

+------------+-----------+-------------------+

pkpkrow

+------------+-----------+-------------------+

ABC

+------------+-----------+-------------------+

ADC

+------------+-----------+-------------------+

AEC

+------------+-----------+-------------------+

改为这样满足第二范式（但是不满足第三范式,字段A与字段C是组合重复）:

+---------+------------+-----------+-------------------+

pkrowrowrow

+---------+------------+-----------+-------------------+

1ABC

+---------+------------+-----------+-------------------+

2ADC

+---------+------------+-----------+-------------------+

3AEC

+---------+------------+-----------+-------------------+

官方定义：

第三范式（3NF）：

在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。

我的理解：

在第三范式中字段与字段之间不能存在组合重复

如:

不满足第三范式,字段A与字段C组合重复

+---------+------------+-----------+-------------------+---------------+

pkrowrowrowrow

+---------+------------+-----------+-------------------+---------------+

1ABCF

+---------+------------+-----------+-------------------+---------------+

2ADCG

+---------+------------+-----------+-------------------+---------------+

3AECK

+---------+------------+-----------+-------------------+---------------+

改为这样满足第三范式:

表1

+---------+------------+-----------+

pkrowrow

+---------+------------+-----------+

1AB

+---------+------------+-----------+

2AD

+---------+------------+-----------+

3AE

+---------+------------+-----------+

和表2

+---------+-------------------+------------+

pkrowrow

+---------+-------------------+------------+

1CF

+---------+-------------------+------------+

2CG

+---------+-------------------+------------+

3CK

+---------+-------------------+------------+

原则:

当出现字段与字段的组合重复,如上的A和C的组合重复,首先要考虑的就是把他们拆分为2个表,具体是C拆到表1,还是A拆到表1,看情况而定.

关键要理解定义这种范式标准的主要目的是为了减少数据冗余，数据冗余产生的本质就是在一个表中存在字段与字段之间的一对多，或者多对多关系。

解决这个几对几的关系问题，就能轻易实现满足第三范式的数据库设计。

详解数据库范式：

第三范式与第五范式

2009年01月16日星期五8:

53A.M.

1NF：

一个table中的列是不可再分的（即列的原子性）

2NF：

一个table中的行是可以唯一标示的，（即table中的行是不可以有重复的）

3NF：

一个table中列不依赖以另一个table中的非主键的列，还是不通俗！

巨寒！

！

举个例子吧：

有一个部门的table，我们叫它tbl_department,它有这么几列（dept_id（pk）,dept_name,dept_memo...）

有一个员工table，我们叫它tbl_employee,在这个table中有一列dept_id（fk）描述关于部门的信息，若tbl_employee要满足3NF，

则在tbl_employee中就不得再有除dept_id列的其它有关部门信息的列！

一般数据库的设计满足3NF即可！

（个人觉得应该尽可能的满足3NF，一家之言^_^）

BCNF：

通常认为BCNF是修正的第三范式，它比3NF又进一步！

4NF：

5NF：

将一个table尽可能的分割成小的块，以排除在table中所有冗余的数据

范式简介

为了回答上述问题，了解3NF、BCNF、4NF和5NF之间的区别很重要。

以下为每个范式的准确定义。

第一范式（1NF）

每个表必须有一个首要键，即最少的一组属性，它与每条记录一一对应。

通过适当定义键属性和非键属性，删除重复的组（不同记录似乎需要不同次重复的数据种类）。

注：

每个属性必须包含单独一个值，而非一组值。

第二范式（2NF）

数据库必须满足1NF的所有要求。

另外，如果一个表有一个复合键，所有属性必须与整个键相关联。

而且，在表的多行之间多余重复的数据被移动一个单独的表中。

第三范式（3NF）

存储在表中的数据不得依赖表的任何域，必须唯一依赖于首要键。

数据库必须满足2NF的所有要求。

既依赖首要键，又依赖其它域的数据被移动到一个单独的表中。

Boyce-Codd范式（BCNF）

除对一个候选键扩展集（称作一个超级键）存在属性函数依赖外，不存在其它非平凡函数依赖。

第四范式（4NF）

除对一个候选键扩展集存在属性组函数依赖外，不存在其它非平凡多值函数依赖。

如果且只有一个表符合BCNF，同时多值依赖为函数依赖，此表才符合第四范式。

4NF删除了不必要的数据结构：

多值依赖。

第五范式（5NF）

不得存在不遵循键约束的非平凡连接依赖。

如果且只有一个表符合4NF，同时其中的每个连接依赖被候选键所包含，此表才符合第五依赖。

数据库范式

注:

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

字段在定义中被称作属性

模式:

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

粗体是关键字的意思

斜体为外键

第一范式

定义：

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

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

1）有主关键字

2）主键不能为空，

3）主键不能重复,

4）字段不可以再分

例如：

StudyNo | Name | Sex | Contact

20040901 john Male Email:

kkkk@,phone:

222456

20040901 mary famale email:

kkk@phone:

123455

以上的表就不符合，第一范式：

主键重复（实际中数据库不允许重复的），而且Contact字段可以再分

所以变更为正确的是

StudyNo| Name | Sex | Email | Phone

20040901 john Male kkkk@ 222456

20040902 mary famale kkk@ 123455

第二范式：

定义：

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

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

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

01 john Malekkkk@ 222456 200401 A楼2

01 maryfamalekkk@ 123455 200402 A楼3

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

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

但是,ClassAddress部分依赖于关键字（ClassNo-〉ClassAddress）,

所以要变为两个表

表一

01 john Male kkkk@ 222456 200401

01 mary famale kkk@ 123455 200402

表二

ClassNo|ClassAddress

200401 A楼2

200402 A楼3

第三范式：

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

例:

20040901john Male kkkk@ 优秀 $1000

20040902mary famalekkk@ 良 $600

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

更改为：

StudyNo | Name | Sex | Email | bouunsNo

20040901 john Male kkkk@ 1

20040902 mary famale kkk@ 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

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

要权衡是否使用更高范式是比较麻烦。

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

而且方便管理数据

I、关系数据库设计范式介绍

1.1第一范式（1NF）无重复的列

如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。

在第一范式（1NF）中表的每一行只包含一个实例的信息。

简而言之，第一范式就是无重复的列。

说明：

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

1.2第二范式（2NF）属性完全依赖于主键

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。

第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。

为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。

例如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。

这个惟一属性列被称为主关键字或主键、主码。

第二范式（2NF）要求实体的属性完全依赖于主关键字。

为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。

简而言之，第二范式就是属性完全依赖于主键。

1.3第三范式（3NF）属性不依赖于其它非主属性

满足第三范式（3NF）必须先满足第二范式（2NF）。

简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。

那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信

展开阅读全文