下载文档原格式
![[总结]关系数据库设计基础（函数依赖、无损连接性、保持函数依赖、范式、……）](https://uimg.taocdn.com/af34390811a6f524ccbff121dd36a32d7375c7be.webp)
[总结]关系数据库设计基础（函数依赖、⽆损连接性、保持函数依赖、范式、……）≏≎≟≗≖≍≭∼∽≁≃≂≅≊≈≉≇≳⪞⪆⋧⪊≵≲⪝⪅⋦⪉≴⊂ subset ⋐⊄⊊ ⊈⊃⊇ ⋑⊅⊋ ⊉≺⪯≼⋞≾⪷⋨⪵⪹⊀≻⪰≽⋟≿⪸⋩⪶⪺⊁ in ∋∉∌∝≬⊸函数依赖（Function Dependency）定义设关系模式R（U），属性集合U= {A1，A2，…，An}，X，Y为属性集合U的⼦集，如果对于关系模式R(U)的任⼀可能的关系r，r中的任意两个元组u、v，若有 u[X]=v[X]，就有u[Y]=v[Y]，则称X函数决定Y，或称Y函数依赖于X。
⽤符号X→Y表⽰。
其中X为决定因素，Y为被决定因素。
若对于R（U）的任意⼀个可能的关系r，r中不可能存在两个元组在X上的属性值性等，⽽在Y上的属性值不等。
(1) 函数依赖是语义范畴的概念，只能根据语义来确定⼀个函数依赖关系。
(2) 函数依赖X→Y的定义要求关系模式R的任何可能的关系r中的元组都满⾜函数依赖条件。
术语 (1)若X→Y，则X称作决定因素（Determinant） (2)若X→Y，Y→X，称作X<->Y。
(3)若Y不函数依赖于X，称作X -/-> Y。
(4)X→Y，若Y不包含X,即X ⊄ Y，则称X→Y为⾮平凡的函数依赖。
正常讨论的都是⾮平凡的函数依赖。
(5)X→Y，若Y包含X，即X ⊂ Y，则称X→Y为平凡的函数依赖。
(6)完全函数依赖(full functional dependency)：在R(U)中，设X、Y是关系模式R（U）中不同的属性⼦集(即X ⊂ U,Y ⊂ U), 若存在 X→Y，且不存在 X的任何真⼦集X'(即 X' ⊊ X)，使得 X'→Y，则称Y完全函数依赖 ( full functional dependency ) 于X。
记作 X-F->Y。
(7)部分函数依赖：在关系模式R（U）中，X、Y是关系模式R（U）中不同的属性⼦集(即X ⊂ U,Y ⊂ U), 若X→Y成⽴，如果X中存在任何真⼦集X'(即 X' ⊊ X)，⽽且有X'→Y也成⽴，则称Y对X是部分函数依赖，记作：X-P->Y。
补充讲义一、范式举例BCNF.如：课程号与学号）例4：R(X,Y,Z),F={XY->Z},R为几范式？BCNF。
例5：R(X,Y,Z),F={Y->Z，XZ->Y},R为几范式？3NF。
R的候选码为{XZ,XY}，（R中所有属性都是主属性，无传递依赖）二、求闭包数据库设计人员在对实际应用问题调查中，得到的结论往往是零散的、不规范的（直观问题好办，复杂问题难办了），所以，这对分析数据模型，达到规范化设计要求，还有差距，为此，从规范数据依赖集合的角度入手，找到正确分析数据模型的方法，以确定关系模式的规范化程度。
例1．已知关系模式R(U、F)，其中，U={A,B,C,D,E}; F={AB→ C, B→ D, EC → B , AC→B} ,求（AB）+F.解：设X(0)=AB○1计算X(1),在F中找出左边为AB子集的FD,其结果是：AB→C,B→D∴X(1)=X(0)UB=ABUCD=ABCD 显然，X(1)≠X(0)○2计算X(2),在F中找出左边为ABCD子集的FD，其结果是：C→E,AC→B∴X(2)=X(1)UB=ABCDUBE=ABCDE 显然，X(2)=U所以，（AB）+ F=ABCDE.（等于U，所以AB是唯一候选关键字）例2．设有关系模式R(U、F)，其中U={A,B,C,D,E，I};F={A→D,AB→E,B→E,CD→I,E→C},计算（AE）+解：令X={AE},X(0)=AE○1在F中找出左边是AE子集的FD,其结果是：A→D,E→C∴X(1)=X(0)UB=X(0)UDC=ACDE 显然，X(1)≠X(0)○2在F中找出左边是ACDE子集的FD，其结果是：CD→I∴X(2)=X(1)UI=ACDEI显然，X(2)≠X(1)，但F中未用过的函数依赖的左边属性已含有X(2)的子集，所以不必再计算下去，即（AE）+=ACDEI.因为，X（3）＝X（2），所以，算法结束。
数据库原理之关系数据库的模式设计课后习题及答案名词解释(1)函数依赖：FD(function dependency)，设有关系模式R(U)，X，Y是U的子集，r是R 的任一具体关系，如果对r的任意两个元组t1,t2,由t1[X]=t2[X]导致t1[Y]=t2[Y], 则称X函数决定Y,或Y函数依赖于X，记为X→Y。
X→Y为模式R的一个函数依赖。
(2) 函数依赖的逻辑蕴涵：设F是关系模式R的一个函数依赖集，X，Y是R的属性子集，如果从F中的函数依赖能够推出X→Y，则称F逻辑蕴涵X→Y,记为F|=X→Y。
(3) 部分函数依赖：即局部依赖，对于一个函数依赖W→A，如果存在X W(X包含于W)有X→A成立，那么称W→A是局部依赖，否则称W→A为完全依赖。
(4)完全函数依赖：见上。
(5) 传递依赖：在关系模式中，如果Y→X，X→A，且X Y（X不决定Y），A X（A 不属于X）,那么称Y→A是传递依赖。
(6) 函数依赖集F的闭包F+: 被逻辑蕴涵的函数依赖的全体构成的集合，称为F的闭包(closure),记为F+。
(7) 1NF：第一范式。
如果关系模式R的所有属性的值域中每一个值都是不可再分解的值, 则称R是属于第一范式模式。
如果某个数据库模式都是第一范式的，则称该数据库存模式属于第一范式的数据库模式。
第一范式的模式要求属性值不可再分裂成更小部分，即属性项不能是属性组合和组属性组成。
(8) 2NF：第二范式。
如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R的某个候选键，则称是第二范式模式；如果某个数据库模式中每个关系模式都是第二范式的，则称该数据库模式属于第二范式的数据库模式。
(注：如果A是关系模式R的候选键的一个属性，则称A是R的主属性，否则称A是R的非主属性。
)(9)3NF：第三范式。
如果关系模式R是第二范式，且每个非主属性都不传递依赖于R的候选键，则称R是第三范式的模式。
如果某个数据库模式中的每个关系模式都是第三范式，则称为3NF的数据库模式。
数据库学习摘记——关系模式的函数依赖关系与关系模式的联系：关系模式是相对稳定的，静态的，是把所有元组删去后的⼀张空表格，是对元组数据组织⽅式的结构描述，⽽关系却是动态变化的，不稳定的，是将若⼲元组填⼊关系模式后得到的⼀个取值实例。
每⼀个关系对应⼀个关系模式，每⼀个关系模式可以定义多个关系。
关系模式R(U)对应的具体关系通常⽤⼩写字母r来表⽰。
函数依赖：设R(U)是属性集U={A1, A2, …, An}上的关系模式，X和Y是U的⼦集。
若对R(U)的任⼀具体关系r中的任意两个元组t1和t2，只要t1[X]=t2[X] 就有t1[Y]=t2[Y]。
则称"X函数确定Y" 或"Y函数依赖于X"，记作X→Y，X为这个函数依赖的决定因素。
函数依赖要求R(U)的⼀切具体关系r都要满⾜的约束条件。
若X→Y且Y→X，则记作X⇿Y平凡函数依赖：X→Y，Y⊆X // 对于任⼀关系模式，平凡函数依赖必然是成⽴的⾮平凡函数依赖：X→Y，Y⊄X完全函数依赖：如果X→Y，且对于X的任何⼀个真⼦集X'，都有X不函数确定Y ，则称Y对X完全函数依赖或者X完全决定Y，记作：部分函数依赖：如果X→Y，但Y不是完全函数依赖于X，则称Y 对X部分函数依赖，记作：传递函数依赖：如果X→Y，Y→Z，且 Y→X，Y⊄X，Z⊄Y,则称Z对X传递函数依赖，记作:候选键：对关系模式R(U)，设K⊆U，且K完全函数确定U，则K为能够唯⼀确定关系中任何⼀个元组(实体)的最少属性集合，称K为R(U)的候选键或候选关键字。
【R(U，F)，U={ A，B，C，D，E，G }，F={AB→C，CD→E，E→A，A→G}，求候选键】因G只在右边出现，所以G⼀定不属于候选码⽽B，D只在左边出现，所以B，D⼀定属于候选码BD的闭包还是BD，则对BD进⾏组合，除了G以外，BD可以跟A，C，E进⾏组合先看ABDABD本⾝⾃包ABD，⽽AB→C，CD→E，A→G，所以ABD的闭包为ABDCEG=U再看BDCCD→E，E→A，A→G，BDC本⾝⾃包，所以BDC的闭包为BDCEAG=U最后看BDEE→A，A→G，AB→C，BDE本⾝⾃包，所以BDE的闭包为BDEAGC=U因为(ABD)、(BCD)、(BDE)的闭包都是ABCDEG所以本问题的候选码有3个分别是ABC、BCD和BDE主键：通常在R(U)的多个候选键中任意选定⼀个候选键作为主键，也称为主码或主关键字。
SQL中的主键，候选键，外键，主码，外码1、码=超键：能够唯⼀标识⼀条记录的属性或属性集。
标识性：⼀个数据表的所有记录都具有不同的超键⾮空性：不能为空有些时候也把码称作“键”2、候选键=候选码：能够唯⼀标识⼀条记录的最⼩属性集标识性：⼀个数据表的所有记录都具有不同的候选键最⼩性：任⼀候选键的任何真⼦集都不能唯⼀标识⼀个记录（⽐如在成绩表中（学号,课程号）是⼀个候选键，单独的学号，课程号都不能决定⼀条记录）⾮空性：不能为空候选键是没有多余属性的超键举例：学⽣ID是候选码，那么含有候选码的都是码。
少部分地⽅也有叫超级码的，但是见得不多3、主键=主码：某个能够唯⼀标识⼀条记录的最⼩属性集（是从候选码⾥⼈为挑选的⼀条）唯⼀性：⼀个数据表只能有⼀个主键标识性：⼀个数据表的所有记录都具有不同的主键取值⾮空性：不能为空⼈为的选取某个候选码为主码4、主属性包含在任⼀候选码中的属性称主属性。
简单来说，主属性是候选码所有属性的并集⾮主属性不包含在候选码中的属性称为⾮主属性。
⾮主属性是相对于主属性来定义的。
5、外键（foreign key）：⼦数据表中出现的⽗数据表的主键，称为⼦数据表的外键。
6、全码：当所有的属性共同构成⼀个候选码时，这时该候选码为全码。
（教师，课程，学⽣）假如⼀个教师可以讲授多门课程，某门课程可以有多个教师讲授，学⽣可以听不同教师讲授的不同课程，那么，要区分关系中的每⼀个元组，这个关系模式R的候选码应为全部属性构成（教师、课程、学⽣），即主码。
7、代理键：当不适合⽤任何⼀个候选键作为主键时（如数据太长等），添加⼀个没有实际意义的键作为主键，这个键就是代理键。
（如常⽤的序号1、2、3）8、⾃然键：⾃然⽣活中唯⼀能够标识⼀条记录的键（如⾝份证）。
数据库函数依赖及范式（最通俗易懂）⼀、基础概念 要理解范式，⾸先必须对知道什么是关系数据库，如果你不知道，我可以简单的不能再简单的说⼀下：关系数据库就是⽤⼆维表来保存数据。
表和表之间可以……（省略10W字）。
然后你应该理解以下概念： 实体：现实世界中客观存在并可以被区别的事物。
⽐如“⼀个学⽣”、“⼀本书”、“⼀门课”等等。
值得强调的是这⾥所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，不如说“⽼师与学校的关系”。
属性：教科书上解释为：“实体所具有的某⼀特性”，由此可见，属性⼀开始是个逻辑概念，⽐如说，“性别”是“⼈”的⼀个属性。
在关系数据库中，属性⼜是个物理概念，属性可以看作是“表的⼀列”。
元组：表中的⼀⾏就是⼀个元组。
分量：元组的某个属性值。
在⼀个关系数据库中，它是⼀个操作原⼦，即关系数据库在做任何操作的时候，属性是“不可分的”。
否则就不是关系数据库了。
码：表中可以唯⼀确定⼀个元组的某个属性（或者属性组），如果这样的码有不⽌⼀个，那么⼤家都叫候选码，我们从候选码中挑⼀个出来做⽼⼤，它就叫主码。
全码：如果⼀个码包含了所有的属性，这个码就是全码。
主属性：⼀个属性只要在任何⼀个候选码中出现过，这个属性就是主属性。
⾮主属性：与上⾯相反，没有在任何候选码中出现过，这个属性就是⾮主属性。
外码：⼀个属性（或属性组），它不是码，但是它别的表的码，它就是外码。
⼆、6个范式 好了，上⾯已经介绍了我们掌握范式所需要的全部基础概念，下⾯我们就来讲范式。
⾸先要明⽩，范式的包含关系。
⼀个数据库设计如果符合第⼆范式，⼀定也符合第⼀范式。
如果符合第三范式，⼀定也符合第⼆范式…第⼀范式（1NF）：属性不可分。
在前⾯我们已经介绍了属性值的概念，我们说，它是“不可分的”。
⽽第⼀范式要求属性也不可分。
那么它和属性值不可分有什么区别呢？给⼀个例⼦：name tel age⼤宝136****567822⼩明139****6655010－123456721Ps：这个表中，属性值“分”了。
范式分解主属性：包含在任一候选关键字中的属性称主属性。
非主属性：不包含在主码中的属性称为非主属性。
函数依赖：是指关系中一个或一组属性的值可以决定其它属性的值.函数依赖正象一个函数 y = f(x) 一样，x的值给定后，y的值也就唯一地确定了。
如果属性集合Y中每个属性的值构成的集合唯一地决定了属性集合X中每个属性的值构成的集合，则属性集合X函数依赖于属性集合Y，计为：Y→X。
属性集合Y中的属性有时也称作函数依赖Y→X的决定因素（determinant）.例:身份证号→姓名。
部分函数依赖：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集,存在X’→Y，则称Y部分函数依赖于X。
完全函数依赖：在R(U）中,如果Y函数依赖于X，并且对于X的任何一个真子集X'，都有Y 不函数依赖于X'，则称Y对X完全函数依赖.否则称Y对X部分函数依赖。
【例】；举个例子就明白了。
假设一个学生有几个属性SNO 学号 SNAME 姓名 SDEPT系SAGE 年龄 CNO 班级号 G 成绩对于（SNO,SNAME，SDEPT,SAGE，CNO,G）来说,G完全依赖于(SNO, CNO）, 因为(SNO,CNO)可以决定G，而SNO和CNO都不能单独决定G。
而SAGE部分函数依赖于(SNO，CNO），因为(SNO，CNO）可以决定SAGE,而单独的SNO也可以决定SAGE。
传递函数依赖：设R(U）是属性集U上的关系，x、y、z是U的子集，在R（U）中，若x→y，但y→x，若y→z,则x→z,称z传递函数依赖于x，记作X→TZ。
如果X-〉Y， Y—〉Z, 则称Z对X传递函数依赖。
计算X+ （属性的闭包）算法：a.初始化，令X+ = X;b。
在F中依次查找每个没有被标记的函数依赖，若“左边属性集”包含于X+ ，则令X+ = X+∪“右边属性集”，并为访问过的函数依赖设置标记。
c。
反复执行b直到X+不改变为止。
数据库函数依赖和范式总结1 函数依赖1.1 定义：一个集合R(U,F)，U为属性全集，F为函数依赖集合。
F中存在着{Xi->Yi...};对于每个X都存在着一个Y与之唯一对应。
意思就是相当于X为主键，Y由主键决定。
比如一个学生他的学号相当于X，而他的姓名与年龄这些其他信息相当于Y。
但是X有时候并不是一个值，比如一个学生他的成绩需要有两个属性才能知道他的成绩，学号+课程号->成绩1.2 平凡函数依赖与非平凡函数依赖平时我们主要讨论的是非平凡函数依赖。
平凡函数依赖概念：Y集合属性属于X集合属性的子集非平凡函数则相反1.3 逻辑蕴涵(为后面求闭包做好基础)X,Y为属性集合U的子集，且X->Y不存在于F中。
即我们需要通过F中的函数依赖推出X->Y称为函数依赖。
而所有函数依赖的集合则称为闭包1.4 函数依赖的推理规则(就是求函数依赖的逻辑蕴涵)1.4.1 几个公理1.4.1.1 公理一(自反律):Y属于X的子集，则X->Y 数学公式描述 Y?X?U1.4.1.2 公理二(增广律):X->Y成立，Z?U也成立，则 XZ?YZ1.4.1.3 公理三(传递律):X->Y成立，Y->Z成立，则 X->Z1.4.2 公理的推广1.4.2.1 推广一(合并律):X->Y,X->Z,则X->YZ1.4.2.2 推广二(伪传递律):X->Y,YW->Z,则XW->Z(证明只需要在XY两边*W)1.4.2.3 推广三(分解律):X->Y成立，Z?Y，则 X->Z1.4.2.4 推广四(复合律):X->Y,W->Z,则XW->YZ1.5 完全函数依赖与部分函数依赖(范式中基础知识)X->Y的集合中，若X的任一真子集x都能 x->Y则为部分函数依赖，若不能则的完全函数依赖，如果X没有真子集则也称为完全函数依赖。
数据库四⼤范式⼀、概念在创建⼀个数据库的过程中，必须依照⼀定的准则，这些准则被称为范式，从第⼀到第六共六个范式。
⼆、背景数据库的规范化（上⼀篇博客有写到）的程度不同，便有了这么多种范式。
数据库范式是数据库设计必不可少的知识，没有对范式的理解，就⽆法设计出⾼效率、优雅的数据库，甚⾄设计出错误误的数据库。
三、⽬标⼀般数据库设计只要遵循第⼀范式，第⼆范式，和第三范式就⾜够了，满⾜这些规范的数据库是简洁的、结构明晰的，同时，不会发⽣插⼊（insert）、删除（delete）和更新（update）操作异常。
使⽤正确的数据结构，不仅有助于对数据库进⾏相应的存取操作，还可以极⼤地简化应⽤程序中的其他内容(查询、窗体、报表、代码等)，按照“数据库规范化”对表进⾏设计，其⽬的就是减少数据库中的数据冗余，以增加数据的⼀致性。
四、概念1、候选键：唯⼀识别该表的属性或属性组。
⽽其任何、⼦集都不能再标识，则称该属性组为（超级码）候选码。
例如：在学⽣实体中，“学号”是能唯⼀的区分学⽣实体的，同时⼜假设“姓名”、“班级”的属性组合⾜以区分学⽣实体，那么{学号}和{姓名，班级}都是（超级码）候选码。
2、所谓依赖，就是函数依赖，就是映射。
可以⼀对⼀，可以⼀对多，可以多对多。
五、六⼤范式第⼀范式（1NF）：属性不可拆分或⽆重复的列⼀个属性不允许再分成多个属性来建⽴列。
事实上，在⽬前的DBMS中是不可能拆分属性的，因为他们不允许这么做。
如果出现重复的属性，就可能需要定义⼀个新的实体，新的实体由重复的属性构成，新实体与原实体之间为⼀对多关系。
第⼀范式的模式要求属性值不可再分裂成更⼩部分，即属性项不能是属性组合或是由⼀组属性构成。
简⽽⾔之，第⼀范式就是⽆重复的列。
例如，由“职⼯号”“姓名”“电话号码”组成的表(⼀个⼈可能有⼀部办公电话和⼀部移动电话)，这时将其规范化为1NF可以将电话号码分为“办公电话”和“移动电话”两个属性，即职⼯(职⼯号，姓名，办公电话，移动电话)。
3.1 名词解释(1) 函数依赖：FD(function dependency)，设有关系模式R(U)，X，Y 是U的子集， r是R的任一具体关系，如果对r的任意两个元组t1,t2,由t1[X]=t2[X]导致t1[Y]=t2[Y], 则称X函数决定Y,或Y函数依赖于X，记为X→Y。
X→Y为模式R的一个函数依赖。
(2) 平凡的函数依赖：对于FD X→Y，如果Y∈X 那么称X→Y 是一个“平凡的函数依赖”，否则称为“非平凡的FD”。
(3) 函数依赖集F的闭包F+: 被逻辑蕴涵的函数依赖的全体构成的集合，称为F的闭包(closure),记为F+。
(5) 函数依赖的逻辑蕴涵：设F是关系模式R的一个函数依赖集，X，Y是R的属性子集， 如果从F中的函数依赖能够推出X→Y，则称F逻辑蕴涵X→Y,记为F|=X→Y。
(6)依赖集的覆盖和等价：关系模式R(U)上的两个函数依赖集F和G，如果满足F+=G+，则称F和G是等价的。
如果F和G等价，则可称F覆盖G或G 覆盖F。
(7)最小依赖集：如果函数集合F满足以下三个条件：(1)F中每个函数依赖的右部都是单属性； (2)F中的任一函数依赖X→A，其F-{X→A}与F 是不等价的；(3)F中的任一函数依赖X→A，Z为X的子集，（F-{X→A}）∪{Z→A}与F不等价。
则称F为最小函数依赖集合，记为Fmin。
(8)无损联接：设R是一关系模式，分解成关系模式ρ={R1,R2...,Rk},F是R上的一个函数依赖集。
如果对R中满足F的每一个关系r都有r=πR1(r)πR2(r)...πRk(r)则称这个分解相对于F是"无损联接分解"。
(10)保持依赖集:所谓保持依赖就是指关系模式的函数依赖集在分解后仍在数据库中保持不变， 即关系模式R到ρ={R1,R2,...,R k}的分解，使函数依赖集F被F这些R i上的投影蕴涵。
(11) 1NF：第一范式。
如果关系模式R的所有属性的值域中每一个值都是不可再分解的值, 则称R是属于第一范式模式。
数据库原理--函数依赖和范式关系数据库设计范式介绍 .1 第⼀范式（1NF）⽆重复的列 所谓第⼀范式（1NF）是指数据库表的每⼀列都是不可分割的基本数据项，同⼀列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义⼀个新的实体，新的实体由重复的属性构成，新实体与原实体之间为⼀对多关系。
在第⼀范式（1NF）中表的每⼀⾏只包含⼀个实例的信息。
简⽽⾔之，第⼀范式就是⽆重复的列。
说明：在任何⼀个关系数据库中，第⼀范式（1NF）是对关系模式的基本要求，不满⾜第⼀范式（1NF）的数据库就不是关系数据库。
1.2 第⼆范式（2NF）属性完全依赖于主键[消除部分⼦函数依赖] 第⼆范式（2NF）是在第⼀范式（1NF）的基础上建⽴起来的，即满⾜第⼆范式（2NF）必须先满⾜第⼀范式（1NF）。
第⼆范式（2NF）要求数据库表中的每个实例或⾏必须可以被唯⼀地区分。
为实现区分通常需要为表加上⼀个列，以存储各个实例的唯⼀标识。
例如员⼯信息表中加上了员⼯编号（emp_id）列，因为每个员⼯的员⼯编号是唯⼀的，因此每个员⼯可以被唯⼀区分。
这个唯⼀属性列被称为主关键字或主键、主码。
第⼆范式（2NF）要求实体的属性完全依赖于主关键字。
所谓完全依赖是指不能存在仅依赖主关键字⼀部分的属性，如果存在，那么这个属性和主关键字的这⼀部分应该分离出来形成⼀个新的实体，新实体与原实体之间是⼀对多的关系。
为实现区分通常需要为表加上⼀个列，以存储各个实例的唯⼀标识。
简⽽⾔之，第⼆范式就是属性完全依赖于主键。
1.3 第三范式（3NF）属性不依赖于其它⾮主属性[消除传递依赖] 满⾜第三范式（3NF）必须先满⾜第⼆范式（2NF）。
简⽽⾔之，第三范式（3NF）要求⼀个数据库表中不包含已在其它表中已包含的⾮主关键字信息。
例如，存在⼀个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。
关系数据库中的范式
范式是关系数据库中的规范，用于定义数据库表的结构和设计。
它有以下几种类型:
1. 第一正式化范式(1NF)
定义一个关系中的每个属性都是原子性的，即不能再分解为更小的部分。
2. 第二正式化范式(2NF)
要求一个关系表中的每个非主属性都完全依赖于主键。
3. 第三正式化范式(3NF)
一个关系表中的每个非主属性都不依赖于其他非主属性, 而只依赖于主键。
4. Boyce-Codd范式(BCNF)
一个关系表中的每个函数依赖都是自包含的，即没有冗余。
5. 第四正式化范式(4NF)
要求一个关系表中的每个多值依赖都是自包含的。
6. 第五正式化范式(5NF)
一个关系表中的每个联合依赖都是自包含的，即没有多余的信息。
这些范式将数据设计成标准化形式，以减少数据冗余和不一致性，并提高了数据的存储效率和查询速度。
数据库中超键、候选键、主键的区分超键(super key):在关系中能唯⼀标识元组的属性集称为关系模式的超键多余属性的超键称为候选键候选键(candidate key):不含有多余属性主键(primary key):⽤户选作元组标识的⼀个候选键程序主键⽐如⼀个⼩范围的所有⼈，没有重名的，考虑以下属性：⾝份证、姓名、性别、年龄。
⾝份证唯⼀所以是⼀个超键姓名唯⼀所以是⼀个超键（姓名，性别）唯⼀所以是⼀个超键（姓名，性别，年龄）唯⼀所以是⼀个超键--这⾥可以看出，超键的组合是唯⼀的，但可能不是最⼩唯⼀的⾝份证唯⼀⽽且没有多余属性所以是⼀个候选键姓名唯⼀⽽且没有多余属性所以是⼀个候选键--这⾥可以看出，候选键是没有多余属性的超键考虑输⼊查询⽅便性，选择⾝份证为主键也可以考虑习惯，选择姓名为主键--主键是选中的⼀个候选键⼀题搞懂什么是候选键：在SQL Server数据库中，有⼀个学⽣信息表如下所⽰，在该表中不能作为候选键的属性集合为（）（选择⼀项）学号姓名性别年龄系别专业20020612 李辉男 20 计算机软件开发20060613 张明男 18 计算机软件开发20060614 王⼩⽟⼥ 19 物理⼒学20060615 李淑华⼥ 17 ⽣物动物学20060616 赵静男 21 化学⾷品化学20060617 赵静⼥ 20 ⽣物植物学a）{学号}b）{学号、姓名}c）{年龄、系别}d）{姓名、性别}e）{姓名、专业}可能⼤家不知道如何来选择。
如果这个题⽬我们可以正确的解答，那么对于超键以及候选键和主键的概念已经有很深刻的认识了。
透过概念，我们可以了解到，超键包含着候选键，候选键中包含着主键。
主键⼀定是惟⼀的。
为什么呢？因为他的爷爷超键就是惟⼀的。
我们分析⼀下上⾯的题⽬，abcde5个答案都可以作为超键，他们组合在⼀起的集合可以⽤来惟⼀的标识⼀个实体。
请注意我们的要求：候选键。
候选键要求是不能包含多余属性的超键，我们看⼀下答案b。
函数依赖候选键-回复什么是函数依赖？在数据库中，函数依赖是一种描述数据关系的概念。
它可以帮助我们理解和规范数据库中的数据之间的关系，并且在数据库设计和优化中扮演了重要的角色。
函数依赖基于数据库中的属性之间的相互关系。
在数据库中，属性分为左侧属性和右侧属性。
函数依赖描述了左侧属性对右侧属性的决定关系。
换句话说，当我们知道了左侧属性的值时，我们可以确定右侧属性的值。
函数依赖可以分为三种类型：完全依赖、部分依赖和传递依赖。
何为候选键？在关系数据库中，候选键是指能够唯一标识关系中元组（记录）的最小属性组合。
候选键的选取是建立数据库表的重要步骤，选取恰当的候选键可以确保数据的完整性和准确性。
候选键不仅需要能唯一标识每个元组，还要满足以下两个条件：1. 无冗余：候选键不能包含其他属性。
只有候选键中的属性组合才能唯一标识元组，其他属性是多余的。
2. 最小性：如果从候选键中删除任何一个属性，那么候选键将不再能够唯一标识元组。
候选键可以有一个或多个，但选择哪些属性作为候选键需要根据具体的需求和数据特点来确定。
如何确定函数依赖？确定函数依赖有以下两个关键步骤：步骤一：确定属性之间的关系。
在确定函数依赖之前，我们首先需要了解数据库中属性之间的关系。
可以通过观察和分析数据库表的结构和数据之间的联系。
通常情况下，属性之间的关系可以通过数据库模型和实际业务逻辑来确定。
步骤二：使用函数依赖规则进行推理。
函数依赖规则可以帮助我们推理出属性之间的函数依赖关系。
以下是常用的函数依赖规则：1. 自反规则：如果属性的集合Y 是属性的集合X 的子集，那么X 函数依赖于Y。
2. 增量规则：如果属性的集合X 函数依赖于属性的集合Y，那么X 包含Y 的任何真子集也函数依赖于Y。
3. 传递规则：如果属性的集合X 函数依赖于属性的集合Y，而属性的集合Y 又函数依赖于属性的集合Z，那么属性的集合X 函数依赖于属性的集合Z。
通过使用这些函数依赖规则，我们可以逐步推导出数据库中属性之间的具体依赖关系。
