[范式]数据库-范式
目录
范式
1.第一范式（1NF）:列不可再分
2.第二范式（2NF）属性完全依赖于主键
3.第三范式（3NF）属性不依赖于其它非主属性 属性直接依赖于主键
4.BCNF（Boyce Codd Normal Form）是由Boyce与Codd提出的，比上述的3NF又进了一步，所以通常认为BCNF是修正的第三范式，有时也成为扩充的第三范式
5.第四范式（4NF）-限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖
6.第五范式（5NF）
多值依赖
传递函数依赖
多值依赖
范式
1.第一范式（1NF）:列不可再分
1.每一列属性都是不可再分的属性值，确保每一列的原子性
2.两列的属性相近或相似或一样，尽量合并属性一样的列，确保不产生冗余数据
例：
有一个学生表，假设有两个字段分别是 name,address,而address内容写的是：江苏省南京市浦口区xxx街道xxx小区。如果这时来一个需求，需要按省市区分类，显然不符需求，这样的表结构也不是符合第一范式的。
应该设计成 name,province(省)，city(市)，area(区)，address
2.第二范式（2NF）属性完全依赖于主键
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一的区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。这个唯一属性列被称为主键
每一行的数据只能与其中一列相关，即一行数据只做一件事，只要数据列中出现重复的数据，那么就要把表拆分开来。
例：
有一个订单表如下：
orderId(订单编号)，roomId(房间号), name(联系人), phone(联系电话)，idn(身份证)
如果这时候一个人同时订了好几个房间，就会变成一个订单编号对应多条数据，这样子联系人都是重复的，就会造成数据冗余，这时我们应该把拆分开来。
如：
订单表：
orderId(订单编号)，roomId(房间号)， peoId(联系人编号)
联系人表：
peoId(联系人编号)，name(联系人), phone(联系电话)，idn(身份证)
3.第三范式（3NF）属性不依赖于其它非主属性 属性直接依赖于主键
第二范式（3NF）是在第一范式（2NF）的基础上建立起来的，即满足第三范式（3NF）必须先满足第二范式（2NF）。
简单点意思就是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。
例：
假设有一个员工(employee)表，它有九个属性：id(员工编号)、name(员工名称)、mobile(电话)、zip(邮编)、province(省份)、city(城市)、district(区县)、deptNo(所属部门编号)、deptName(所属部门名称)
员工表的province、city、district依赖于zip，而zip依赖于id，换句话说，province、city、district传递依赖于id，违反了 3NF 规则。为了满足第三范式的条件，可以将这个表拆分成employee和zip两个表，如下：
employee
| id | name | zip |
|---|---|---|
| 101 | 张三 | 100001 |
| 102 | 李四 | 200001 |
| 103 | 王五 | 510001 |
地区表area
| zip | province | city | district |
|---|---|---|---|
| 100001 | 北京 | 北京 | 海淀区 |
| 200001 | 上海 | 上海 | 静安区 |
| 51000 | 广东省 | 广州 | 白云区 |
4.BCNF（Boyce Codd Normal Form）是由Boyce与Codd提出的，比上述的3NF又进了一步，所以通常认为BCNF是修正的第三范式，有时也成为扩充的第三范式
如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字（而不是被关键字所包含），则BCNF的关系模式。 例：配件管理关系模式 WPE（WNO，PNO，ENO，QNT）分别表仓库号，配件号，职工号，数量。有以下条件 a.一个仓库有多个职工。 b.一个职工仅在一个仓库工作。 c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。 d.同一种型号的配件可以分放在几个仓库中。 分析：
- （1）由以上得 PNO 不能确定QNT，由组合属性（WNO，PNO）来决定，存在函数依赖（WNO，PNO） -> ENO。
- （2）由于每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有组合属性（WNO，PNO）才能确定负责人，有（WNO，PNO）-> ENO。
因为 一个职工仅在一个仓库工作，有ENO -> WNO。由于每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有 （WNO，PNO）-> QNT。 找一下候选关键字，因为（WNO，PNO） -> QNT，（WNO，PNO）-> ENO ，因此 （WNO，PNO）可以决定整个元组，是一个候选关键字。根据ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能决定整个元组，为另一个候选关键字。属性ENO，WNO，PNO 均为主属性，只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。 分析一下主属性。因为ENO->WNO，主属性ENO是WNO的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字（ENO，PNO）的部 分依赖，因为（ENO，PNO）-> ENO但反过来不成立，而PNO->WNO，故（ENO，PNO）-> WNO 是传递依赖。 虽然没有非主属性对候选关键字的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。
- 解决办法：分成管理EP（ENO，PNO，QNT），关键字是（ENO，PNO）工作EW（ENO，WNO）其关键字是ENO
- 缺点：分解后函数依赖的保持性较差。
1NF直到BCNF的四种范式之间有如下关系： **BCNF包含了3NF包含2NF包含1NF **
5.第四范式（4NF）-限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖
定义：限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。
理解： 显然一个关系模式是4NF，则必为BCNF。也就是说，当一个表中的非主属性互相独立时（3NF），这些非主属性不应该有多值，若有多值就违反了4NF。
四种范式之间存在如下关系
6.第五范式（5NF）
第五范式有以下要求：
（1）必须满足第四范式；
（2）表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。
第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况，而第五范式则处理相互依赖的多值情况。
多值依赖
提出多值依赖前，我们先提出依赖是什么。
函数依赖
车牌→车
完全函数依赖、平凡函数依赖
完全函数依赖：( 经 度 , 纬 度 ) → 地 点 (经度,纬度)\to 地点(经度,纬度)→地点
部分函数依赖、完全函数依赖
传递函数依赖
用户→权限等级，权 限 等 级 → 权 限 权限等级\to权限权限等级→权限
用户⟶传递权限
多值依赖
课程→→教师
多值依赖的性质：
1. 多值依赖具有对称性。即若X → → Y，则X → → Z，其中Z=U-X-Y。
2. 多值依赖具有传递性。即若X → Y，Y → Z，则X → Z。
3. 函数依赖可以看作是多值依赖的特殊情况。即若X → Y，则X → →Y。这就是因为当X →Y时，对X的每一个值x，Y有一个确定的值y与之对应，所以X → →Y。
4. 若X → →Y，X → →Z，则X → →YZ。
5. 若X → →Y，X → →Z，则X → →Y∩Z。
6. 若X → →Y，X → →Z，则X → →Y-Z，X → →Z-Y。
为什么需要范式
数据库范式为数据库的设计、开发提供了一个可参考的典范，在许多教学材料中也是作为关键的课程内容。 那么范式的提出是为了解决什么问题？
- 第一范式，要求将列尽可能最小的分割，希望消除某个列存储多个值的冗余的行为比如用户表中的地址信息，拆分为省、市这种明确的字段，可以按独立的字段检索、查询
- 第二范式，要求唯一的主键，且不存在对主键的部分依赖，希望消除表中存在冗余(多余)的列，比如订单表中的商品分类、详情信息，只需要由商品信息表存储一份即可。
- 第三范式，要求没有间接依赖于主键的列，即仍然是希望消除表中冗余的列比如用户表中不需要存储额外的 其所在城市的人口、城市特点等信息。
很明显，这些范式大都是为了消除冗余而提出的，即尽可能的减少存储成本。
[范式]数据库-范式相关推荐
- 什么是数据库范式（NF）？从一范式到五范式分别是什么？
什么是数据库范式(NF)?从一范式到五范式分别是什么? 什么是数据库范式(NF)? 为了建立冗余较小.结构合理的数据库,设计数据库时必须遵循一定的规则.在关系型数据库中这种规则就称为范式.范式是符合某 ...
- (转载)数据库范式及宽表窄表理解
1.数据库设计的三大范式,转载地址:http://www.cnblogs.com/linjiqin/archive/2012/04/01/2428695.html 为了建立冗余较小.结构合理的数据库, ...
- 数据库范式解析（1NF 2NF 3NF BCNF）
数据库设计范式是关系型数据库的设计准则.其目的在于通过规划设计使得数据库结构合理,尽量减少数据冗余,消除存储异常,方便数据的插入.更新和删除操作.目前常用范式包括1NF(第一范式).2NF(第二范式) ...
- 数据库范式1NF 2NF 3NF BCNF
设计范式(范式,数据库设计范式,数据库的设计范式)是符合某一种级别的关系模式的集合.构造数据库必须遵循一定的规则.在关系数据库中,这种规则就是范式.关系数据库中的关系必须满足一定的要求,即满足不同的范 ...
- 【转载】数据库范式那些事
数据库范式那些事 简介 数据库范式在数据库设计中的地位一直很暧昧,教科书中对于数据库范式倒是都给出了学术性的定义,但实际应用中范式的应用却不甚乐观,这篇文章会用简单的语言和一个简单的数据库DEMO将一 ...
- 数据库范式的思考以及数据库的设计
数据库范式--通俗易懂[转] 数据库范式是数据库设计中必不可少的知识,没有对范式的理解,就无法设计出高效率.优雅的数据库.甚至设计出错误的数据库.而想要理解并掌握范式却并不是那 么容易.教科书中一般以 ...
- 数据库范式5nf_第四范式（4NF）| 数据库管理系统
数据库范式5nf Fourth normal form (4NF) is a normal form used in database normalization, in which there ar ...
- 从第一范式(2nf)到第二范式(3nf)_啥是数据库范式
前言: 关于数据库范式,时常有听说过,一直没有详细去了解.一般数据库书籍或数据库课程会介绍范式相关内容,范式也经常出现在数据库考试题目中.不清楚你是否对范式有比较清晰的了解呢?本篇文章我们一起来学习下 ...
- 【Oracle】数据库范式
为了规范化关系型数据模型,关系型数据库系统在设计时必须遵循一定的规则,这种规则称为关系型数据库系统范式.范式的主要目的是降低数据冗余,设计结构合理的数据库. 1. 第一范式(1NF):字段必须具有唯一 ...
最新文章
- python解析雷达数据_【学习笔记】使用python带时间戳提取rosbag中的图像和雷达数据...
- Facebook API使用经验分享
- 【转】Java：String、StringBuffer和StringBuilder的区别
- C#的多线程机制探索1
- java保护表格_读密码保护的工作表（版本 - Excel中95,97-2003）的Java
- 【网易游戏面试题】.NET中强引用和弱引用是什么
- Solaris 10 x86 Mono 三次折腾准备休战了
- 三台服务器的时间同步-Linux
- Grails Quartz插件，定时调度任务
- FX DocuPrint M268 dw打印机硒鼓清零
- 计算机很多文件无法删除,电脑有文件删不掉怎么办？电脑有文件删不掉解决方法介绍...
- excel表格怎么画斜线_怎么画出漂亮的Excel表格线？
- oracle添加redo,添加redolog组成员
- win7怎么更改浏览器主页？win7浏览器主页更改教程
- ctfshow-菜狗杯-web（一）
- openresty 与 java RSA加解密
- 苹果AppStore审核规则标准指南！
- 树莓派sd卡格式化_利用树莓派和移动硬盘搭建下载机，常见视频网站都可下载...
- 线程分离pthread_detach、pthread_attr_setdetachstate (attr, PTHREAD_CREATE_DETACHED);
- 拼多多之所以壮大，在于淘宝对利益过度痴迷