写下此文,希望能深入浅出地总结【正则化】的要点

此为正则化第二部分:【数据库基础】正则化(Normalization)P2:BCNF,MVD,4NFhttps://blog.csdn.net/YFY20020109/article/details/125108477?spm=1001.2014.3001.5501


目录

各类范式(Normal Form)

一、无范式(Unnormalized Form,UNF)

二、第一范式(First Normal Form,1NF)

三、第二范式(2NF)

函数依赖(Functional Dependency)

​​

完全函数依赖(full functional dependency)

部分函数依赖(partial dependency):

四、第三范式(3NF)

传递性依赖(transitive dependency)


各类范式(Normal Form)

范式,可以消除表中过多数据冗余,让每个表更简洁;但也增大了跨表联系和索引数据的难度。以下为常用的各类范式(内层的范式可由外层的演变得来,对表中数据联系的要求也更高):


一、无范式(Unnormalized Form,UNF)

如关系(或者说 表)ClientRental所示,杂糅无章,看上去刚刚有个表样儿,每个单元格可以有一个到多个值(但不可为空),这就是UNF。


二、第一范式(First Normal Form,1NF)

保证每个单元格有且仅有一个值。可通过重新划分UNF得到(图中框红处为新拷贝出来的值):


三、第二范式(2NF)

在1NF的基础上,若所有非候选键(non-candidate key)的属性都完全函数依赖于候选键,则已经属于2NF;若依赖于候选键的部分函数依赖存在,则需要用将一张大表切分成多张小表(即分为多个关系)的方式去除此部分函数依赖,使得新生成的几个表都符合上述要求。

那什么是函数依赖?什么又是完全、部分函数依赖?


函数依赖(Functional Dependency)

如图,对于表中每一行,若知道B的值,就能唯一确定D的值。从B到D是1对1的关系,但这只是单向的(single direction),不是相互的,因为反过来知道D未必就能推出B(如:当D=w,B=b或d,不止一种可能)。所以B是“决定者”(determinant),也是“被依赖者”,D是“被决定者”,也是“依赖者”,D函数依赖于B,

记为 B --> D,(注意箭头指向,是“determination”的指向)

完全函数依赖(full functional dependency)

        直观地说,就是对于属性集 A --> B,B完完全全只依赖于A,而不依赖于A下面的任何子集。

它的严格定义:Determinants should have the minimal number of attributes necessary to maintain the functional dependency with the attribute(s) on the right hand-side.

与之相对的,就是部分函数依赖。

       部分函数依赖(partial dependency):

        即使A中部分属性被剔除,A --> B仍然成立

在同一张表中,若有函数依赖:staffNo, sName -> branchNo、staffNo -> branchNo, 则 branchNo 部分依赖于(staffNo,sName),完全依赖于staffNo。

但是从1NF变到2NF的过程中,真正要剔除部分依赖的做法与上述定义还有区别:


上文所述的关系ClientRental中,共有6个函数依赖:

其中共有3个可作为主键的候选键(candidate key): (clientNo, propertyNo),(clientNo, rentStart),(propertyNo, rentStart);

在从1NF变到2NF过程中,我们真正要剔除的部分依赖应该是以下形式:

(候选键的子属性)----> (不能单独作为候选键的属性);

(打个不恰当的比方:对于一张表中的属性,候选键就像 “当家” 一般的存在,所以候选键内部的属性应该协调一致,共同决定其他属性;若候选键内部有属性脱离其他成员,去找一些别的属性只依附于自己,那就只能离开该表出去单干了)

综上所述:属性clientNo、propertyNo、rentStart均不可单独作为 ‘determinant’,皆因它们是候选键内部的成员

fd2、fd3就是这样的例子,为了符合2NF,它们的 “依赖者属性” 会被 “请” 出这个关系,与它们一同移出的还有“决定者属性”的一份copy(本尊自然是得留下的),作为新的当家主码。由此原来的关系一分为三,各自符合2NF。

(这里copy的就是clientNo、propertyNo)


四、第三范式(3NF)

在2NF的基础上,没有非候选键属性传递性依赖于候选键本身,那么传递性依赖又是什么?


传递性依赖(transitive dependency)

       它的严格定义:If A, B and C are attributes of a relation,A → B,B → C, then C is transitively dependent on A through B. (Provided that A is not functionally dependent on B or C).
不过还是要看实际上是怎么应用的:
对于这2个函数依赖:fd1: A -> B,C,E,G,H 、fd2: G -> H,fd2即为传递性依赖,H经由G依赖于A 

之前已是2NF的三个关系,它们的函数依赖:

其中关系Client、Rental已然没有传递性依赖,都进入了3NF。只有PropertyOwner中,oName经由ownerNo依赖于主键propertyNo。

解决方案与1NF到2NF相似但略有不同:“决定者” propertyNo不动,将“中间商” ownerNo的一份copy和它的“下家” oName一并抬走,ownerNo成为新关系的主键。

三个关系变成四个,各自符合3NF。

【数据库基础】正则化(Normalization)P1:UNF、1NF、2NF、3NF相关推荐

  1. 数据库六种范式详解(1NF/2NF/3NF/BCNF/4NF/5NF)

    目录 数据库的基本概念 函数依赖 函数依赖的定义 函数依赖与属性的关系 六种范式 第一范式(1NF) 第二范式(2NF) 第三范式(3NF) 巴斯-科德范式(BCNF,Boyce-Codd Norma ...

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

    数据库设计范式是关系型数据库的设计准则.其目的在于通过规划设计使得数据库结构合理,尽量减少数据冗余,消除存储异常,方便数据的插入.更新和删除操作.目前常用范式包括1NF(第一范式).2NF(第二范式) ...

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

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

  4. 【数据库】范式理解:1NF,2NF,3NF,BCNF,4NF详析

    数据库入门(一)范式理解:1NF,2NF,3NF,BCNF,4NF详析 引言 范式种类 第一范式(1NF) 符合1NF的关系中的每个属性都不可再分 存在问题 第二范式(2NF) 在1NF基础上消除了非 ...

  5. 3nf mysql表_数据库三大范式(1NF,2NF,3NF)及ER图

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

  6. 数据库1NF 2NF 3NF范式解释

    数据库1NF 2NF 3NF范式解释 定义 范式(NF)"是什么意思.按照教材中的定义,范式是"符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度&quo ...

  7. 数据库随笔-1NF,2NF,3NF详解

    数据库随笔-1NF,2NF,3NF详解 基础概念 通过表的更新来举例说明 总结 基础概念 1. 第一范式(1NF):每一列都是不可分割的原子数据项 2. 第二范式(2NF):在1NF的基础上,非码属性 ...

  8. 数据库范式1NF 2NF 3NF详细阐述

    范式:关系数据库中的关系是要满足一定要求的,满足不同程度要求的不同范式.满足最低要求的叫第一范式,简称1NF ,在第一范式中满足进一步要求的为第二范式,其余以此类推.通俗来说是满足数据库关系表中的一套 ...

  9. 1NF | 2NF | 3NF的区分以及什么是函数依赖、部分函数依赖、值传递依赖(最详细的讲解1NF、2NF、3NF的关系)

    1NF | 2NF | 3NF的区分以及什么是函数依赖.部分函数依赖.值传递依赖 符合3NF一定符合2NF.一定符合1IF 简单区分.2NF不存在部分函数依赖,3NF不存在传递函数依赖 第一范式1NF ...

  10. 【转】关系型数据库的设计范式 1NF 2NF 3NF BCNF

    本文转载自:https://www.cnblogs.com/langdashu/p/5924082.html 一.缘由: 要做好DBA,就要更好地理解数据库设计范式.数据库范式总结概览: 为了更好地理 ...

最新文章

  1. picACG本地缓存目录_7天用Go动手写/从零实现分布式缓存GeeCache
  2. xtrabackup 9.0备份出错的解决方法
  3. python的数据库中间件_数据库中间件设计方案
  4. function 多个函数用一个_程序员如何用一个脚本每天定时给多个女友发微信暖心话...
  5. 二进制文件转成文本保存,并可以读回
  6. MySQL最好的写的_mysql中写sql的好习惯
  7. OpenCV : 投影变换
  8. Multisim 安装、破解、汉化、卸载教程
  9. 关于混合app 开发框架Ionic
  10. html比赛项目,趣味运动会项目
  11. 第12章实验1:学生成绩管理系统V5.0
  12. Torque引擎系列
  13. NLP--2 语言结构和传统pipeline
  14. 模型预测控制(MPC)的公式推导与理解 (转)
  15. Nessus介绍与安装
  16. 将电脑新建文本文档txt的默认编码从ANSI改为utf-8
  17. android 绘制正方形图片,是Android的自定义View-绘制流程-正方形图片控件(SquareImageView)...
  18. [精华] [转贴]Curses函数说明(SCO)
  19. 【分享】如何移除PDF密码?
  20. Linux 下 UltraEdit v15 破解 30 天试用限制

热门文章

  1. 创建facebook_我如何重新创建Facebook的微交互以进行功能发现
  2. 两天赚 2 千,用 Python 接私活,真香!
  3. lvs工作在第几层_四层负载均衡——LVS
  4. Glib学习笔记(1)
  5. PMP考试中常见的翻译问题
  6. 【Linux】万字总结Linux 基本指令,绝对详细!!!
  7. Qt for Android获取手机序列号
  8. 云计算考证笔记、CPU虚拟化、内存虚拟化、IO虚拟化、存储虚拟化
  9. Google新的搜索页面
  10. 1-5(中文版)听力积累