博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
数据库范式
阅读量:7009 次
发布时间:2019-06-28

本文共 1019 字,大约阅读时间需要 3 分钟。

 数据库范式那些事:  

 

 

 

对表进行第一范式(1NF)

    如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF。

    简单的说,第一范式就是每一个属性都不可再分。不符合第一范式则不能称为关系数据库。对于上表,不难看出Address是可以再分的,比如”北京市XX路XX小区XX号”,着显然不符合第一范式,对其应用第一范式则需要将此属性分解到另一个表,如下:

对表进行第二范式(2NF)

若关系模式R∈1NF,并且每一个非主属性都于R的码,则R∈2NF

简单的说,是表中的属性必须完全依赖于全部主键,而不是部分主键.所以只有一个主键的表如果符合第一范式,那一定是第二范式。这样做的目的是进一步减少插入异常和更新异常。在上表中,departmentDescription是由主键DepartmentName所决定,但却不是由主键EmployeeID决定,所以departmentDescription只依赖于两个主键中的一个,故要departmentDescription对主键是部分依赖,对其应用第二范式如下表:

对表进行第三范式(3NF)

R<U,F> 中若不存在这样的码X、属性组Y及非主属性Z(Z  Y), 使得X→Y,Y→Z,成立,则称R<U,F> ∈ 3NF。

简单的说,第三范式是为了消除数据库中关键字之间的依赖关系,在上面经过第二范式化的表中,可以看出jobDescription(岗位职责)是由job(岗位)所决定,则jobDescription依赖于job,可以看出这不符合第三范式,对表进行第三范式后的关系图为:

上表中,已经不存在数据库属性互相依赖的问题,所以符合第三范式

 

下面我将比较第二范式和第三范式,以其找出共同点和异同点。

下面以《》中的例子进行比较。

可以看到第二范式和第三范式的共同点是:表中的属性必须完全依赖于全部主键。

异同点:第二范式要求表中的属性必须完全依赖于全部主键,而不是部分主键

第三范式要求是表中的属性必须完全依赖于全部主键,不能依赖于部分主键,更不能依赖部分属性

所以,第三范式是对第二范式的进一步规范化。

作者: 
出处: 
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

转载:http://www.cnblogs.com/kissazi2/archive/2012/05/03/2977137.html

你可能感兴趣的文章
我的友情链接
查看>>
纯靠内链提权重
查看>>
linux因环境变量修改错误,造成命令查找不到,且无法登陆系统解决办法
查看>>
元芳,你怎么看,网络为何会如此流行!
查看>>
计算机运行命令全集
查看>>
Android项目之旅三 简易Mp3播放器从获取服务器端Mp3信息
查看>>
将一个数组中的奇元素全部移到数组的前半部分,即将奇偶元素分开
查看>>
无需SDK的统计工具,让哥赚了个iphone6
查看>>
没有做数据备份 网站随时毁于一旦
查看>>
Python学习笔记
查看>>
js中json与字符串转换小例子
查看>>
学习笔记-实验楼项目课(Linux桌面字典)
查看>>
Spring基础问答
查看>>
iOS8 相机拍照问题 Snapshotting a view
查看>>
comparable 接口的使用示例
查看>>
剑指Offer之重建二叉树(题6)
查看>>
strace-跟踪进程执行时的系统调用
查看>>
三个数找最大 1.0
查看>>
判断大端与小端
查看>>
计算机科学技术基础知识之多媒体知识
查看>>