关系模式

模式分解 模式S-C-M （S 学号，C 班级，M 班主任） 该模式设计不好，存在数据冗余、插入异常、删除异常和更新异常 p1 = {S-C(学号，班级)，C-M(班级，班主任)} p2 = {S-C(学号，班级)，C-M(学号，班主任)} p3 = {S-C(学号，班主任)，C-M(班级，班主任)} 规范化理论： 检测是否在一个表中聚集了过多的属性的过程 模式分解来消除违反范式规则而带来的影响（插入、更新、删除异常，冗余大），构造合适的(更好的)数据模式 概念建模过程中规范化用于检验却总是很有帮助 数据依赖 一个关系内部属性与属性之间的一种约束关系（属性值时候相同） 现实世界属性间相互联系的抽象 数据内在性质 语义的体现 函数依赖FD Sno Sname Ssex Sage a value b1 value c value d value a2 value b2 value c2 value d2 value … … … … an value bn value cn value dn value 定义： 设 R(U) 是一个属性集 U 上的关系模式， X 和 Y 是 U 的子集。若对于 R(U) 的任意一个可能的关系 r ， r 中不可能存在两个元组在 X 上的属性值相等， 而在 Y 上的属性值不等， 则称“ X 函数确定 Y ”或“ Y 函数依赖于 X ”，记作 X → Y 若

　　关系数据库设计的方法之一就是设计满足适当范式的模式，通常可以通过判断分解后的模式达到几范式来评价模式规范化的程度。范式有1NF,2NF,3NF,BCNF,4NF,5NF，其中1NF的级别最低。这几种范式之间，5NF⊂4NF⊂BCNF⊂3NF⊂2NF⊂1NF成立。通过分解，可以将一个低一级范式的关系模式转化成若干个高一级范式的关系模式，这个过程为规范化。下面我们来看一个栗子（好吃），有错误的地方希望读者可以提出改正。 　　供应者和它所提供的零件信息，关系模式FIRST和函数依赖集F如下： 　　FIRST(Sno,Sname,Status,City,Pno,Qty)（公司编号，名称，状态，城市，产品编号，数量） 　　F={Sno->Sname,Sno->Status,Status->City,(Sno,Pno->Qty)} 　　可以很明显的看出，该关系中不含有可以再分的数据项（什么是可以再分的数据项？想象一张table，不应存在两个相同的字段，即两个相同的数据项。如果存在了，就说明他有了可以再分的数据项，就不是关系模式的数据库了。存在了可再分的数据项，就要考虑新增实体，将两个数据项分别放到两个实体上），所以该关系满足第一范式的条件。 　　 1NF 第一范式 　　　　定义：若关系模式R的每一个分量是不可再分的数据项，则关系模式R属于第一范式 　　　　第一范式有四个缺点：（1）冗余度大

数据：描述事物的符号记录。 数据库：长期存储在计算机内、有组织的、可共享的统一管理的数据集合。 数据库系统：带有数据库的计算机应用系统，因此不仅包括数据库本身，即实际存储在计算机中的数据，还包括相应的硬件支撑环境、软件系统和各类相关人员。也就是说，数据库系统是一个由使用和维护人员、软硬件和数据资源等构成的完整计算机应用系统。 数据库管理系统：是位于用户与操作系统之间的具有数据定义、数据操纵、数据库的运行管理、数据库的建立和维护功能的一层数据管理软件。 外模式：用户模式，是数据库用户和数据库系统的接口，是数据库用户的数据视图,是数据库用户可以看见和使用的局部数据的逻辑结构和特征的描述，是与某一应用有关的数据的逻辑表示。外模式是保证数据库安全的重要措施。每个用户只能看见和访问所对应的外模式中的数据，而数据库中的其他数据均不可见。 模式：又可细分为概念模式和逻辑模式，是所有数据库用户的公共数据视图，是数据库中全部数据的逻辑结构和特征的描述。 内模式：又称为存储模式，是数据库物理结构和存储方式的描述，是数据在数据库内部的表示方式。 外模式/模式映像：对于每一个外模式，数据库系统都一个外模式/模式映像，它定义了该外模式与模式之间的对应关系。如果数据库的模式改变，则对外模式/模式映像作相应改变，使外模式保持不变，从而不必修改外模式的应用程序，保证了数据与程序的逻辑独立性。 模式/内模式映像

作者：知乎用户 链接：https://www.zhihu.com/question/24696366/answer/29189700 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 ============ 2015-1-6 更新，补充了 BCNF 的解释 ============ 国内绝大多数院校用的王珊的《数据库系统概论》这本教材，某些方面并没有给出很详细很明确的解释，与实际应用联系不那么紧密，你有这样的疑问也是挺正常的。 我教《数据库原理》这门课有几年了，有很多学生提出了和你一样的问题，试着给你解释一下吧。 （基本来自于我上课的内容，某些地方为了不过于啰嗦，放弃了一定的严谨，主要是在“关系”和“表”上） 首先要明白”范式（NF）”是什么意思。按照教材中的定义，范式是“ 符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度 ”。 很晦涩吧？实际上你可以把它粗略地理解为 一张数据表的表结构所符合的某种设计标准的级别 。就像家里装修买建材，最环保的是E0级，其次是E1级，还有E2级等等。 数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。 一般在我们设计关系型数据库的时候，最多考虑到BCNF就够 。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。

关系数据库的结构 ·关系（relation）： 关系用来指代表。关系数据库由表（table）的集合构成，每个表有唯一的名字。表中的一行代表一组值之间的一种联系，一个表就是这种联系的一个集合。 ·元组（tuple）： 指代表中的一行。元组是一组值的序列，n个值之间的一种联系可以用一个n元组来表示。 关系是元组集合，元组在关系中出现的顺序无关紧要。 ·属性（attribute） ：指代表中的列。 ·关系实例（relation instance）： 指代一组特定的行，表示一个关系的特定实例。 ·域（domain）： 对于关系的每个属性，都存在一个允许取值的集合。 数据库模式 数据库模式（database schema）是数据库的逻辑设计，而数据库实例（database instance）是给定时刻数据库中数据的一个快照。 关系模式（relation schema）由属性序列及各属性对应域组成，还可能包括属性类型和关系上的约束，对应程序设计语言中的类型定义（不常变化）。 关系实例对应程序设计语言中变量的值，可能随时间变化、更新）。 e.g. department关系的关系模式：department(dept_name, building, budget) student关系的关系模式：student(ID, name, dept_name, tot_cred) 码 码（不论是主码

首先理解几个概念， 函数依赖：设R（U）是属性集上的关系模式，X,Y是U的子集。若对于R(U)的任意一个可能的关系r，r中不能存在两个元组在X上的属性值星等，而在Y上的属性值不等，即是说这里X可以唯一确定Y，则称，X函数确定Y或Y函数依赖于X，记作X–>Y。 完全函数依赖：在R(U)中，如果X–>Y，并且对于X的任何一个真子集X‘，都有X’-/->Y，记作 X-f->Y; (f为箭头的上标) 部分函数依赖：若X–>Y，但Y不完全依赖于X，则称Y对X部分函数依赖。X-p->Y 传递函数依赖：在R(U)中，如果X–>Y(Y不真含于X，也即X不真包含Y)，Y-/->X， Y–>Z，Z不真含于Y，则称Z于X传递函数依赖。记作，X-传递->Z 另外码（键）的概念，参考 https://blog.csdn.net/liushuijinger/article/details/12832017 几种范式定义： 2NF，若R属于1NF，且每一个非主属性完全函数依赖于任何一个候选码，则R属于2NF。 3NF，设关系模式R<U,F>属于1NF，若R中不存在这样的码X，属性Y以及非主属性Z（Z不真包含Y）使得X-->Y，Y-->Z成立，Y-/->X，则R<U,F>属于3NF。 BCNF，关系模式R<U,F>属于1NF，若X-->Y且Y不真包含于X时X必含有码，则R<U,F>属于BCNF

1.关系模式应当是一个五元组 R（U,D,DOM,F） 关系名R U为一组属性 D为属性组U中的属性所来自的域 DOM为属性到域的映射 F为属性组U上的一组数据依赖（数据依赖是关系内部属性与属性之间的一种约束关系，这种约束关系是通过属性间值的相等与否体现出来的数据间相关联系） 2.数据依赖： ①函数依赖（FD）：学号确定后，学生的姓名及所在系的值也被唯一地确定了,类似于y=f(x) 对于关系模式R（U）的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不相等，记作X->Y 非平凡的函数依赖：X->Y，但是Y不属于X 平凡的函数依赖：X->Y，但Y属于X，对于任一关系模式，平凡依赖都是必然成立的。 完全函数依赖：X->Y，并且对于X的任何一个真子集X'，X‘不能推出Y。（s#,c#）->Grade,s#和c#必须同时存在，才能推出G 部分依赖：X->Y，但是Y不完全依赖于X。（s#,c#）->Sname，c#不是必须的，s#单独也可以推出Sname属性值。 传递函数依赖：X->Y（Y不属于X），Y->Z(Z不属于Y)，可以的得到Z->X。 ②多值依赖（MVD）:关系模式R（U），U是属性集，在U（X,Y,Z）中，当一对（X,Z）值可以对应一组Y值时，Y值仅仅取决于X值，而与Z值无关。即表示为，X->->Y。 3.码 候选码： 定义①

转自： https://www.cnblogs.com/yijiahao/p/11707183.html E-R模型如何转换成关系模型，这里我们分成三种情况进行讲解，分别是一对一，一对多和多对多。 1.一对一的情况： 　　有两种方法解决这个问题。 第一个方法： 可以单独对应一个关系模式，由各实体的主码构成关系模式，而关系模式的主码可以是任一个实体集的主码。而实体中属性照常写就可以了。 第二个方法： 实体中的属性照常写，然后将一方实体集的主码加到另一方实体集对应的关系模式中。下面举个例子我们来看一下： 在这个例子中，利用方法一，先将两个实体正班长和班级的属性照着写下来，然后将关系模式“属于”的属性写出来——即两边实体的主码，其中关系模型“属于”的主键可以是两端实体集的任一主码。利用方法二，也是先将两端实体的属性照着写下来，然后注意这一点，将一端实体的主码加到另一端实体的主码中，图例中就是将“班级”实体的主码加入到“正班长”关系属性中。 2.一对多的情况： 　　这种情况可以跟一对一的情况对比着学习。 第一个方法： 同一对一的方法一是差不多的，只是对应的关系模式中，其主码不再是任一实体的主码就可以，而是必须指定n端的主码为关系模式的主码。 第二个方法： 同一对一的方法二也是差不多的，但是值得强调的是，必须将1端的主码加到n端的关系模式中，而且n端的主码仍然为该关系模式中的主码。同样

数据库知识 　　数据库模型（概念模式、外模式、内模式） 　　数据模型，ER 图，规范化 　　数据操作 　　数据库语言 　　数据库管理系统的功能和特征 　　数据库的控制功能 　　数据仓库和分布式数据库基础知识 　　 范式： 　　 第一范式（1NF） ：在关系模式R中，当且仅当所有域只包含原子值，即每个分量都是不可再分的数据项，则称实体E是第一范式。 　　 第二范式（2NF） ：当且仅当实体E是第一范式（1NF），且每一个非键属性完全依赖主键（没有不完全依赖）时，则称实体E是第二范式。 　　 第三范式（3NF） ：当且仅当实体E是第二范式（2NF），且E中没有非主属性传递依赖于码时，则称实体E是第三范式。 　　 BCNF ：如果关系模型R∈1NF，且R中每一个函数依赖关系中的决定因素都包含码，则R是满足BC范式的关系，记作BCNF。 　　设有关系模式R (课程，教师，学生，成绩，时间，教室），其中函数依赖集F如下：F=｛课程→→教师，（学生，课程）→成绩，（时间，教室）→课程，（时间，教师）→教室，（时间，学生）→教室｝关系模式R的一个主键是__(1)__，R规范化程度最高达到__(2)__。若将关系模式R分解为3个关系模式R1（课程，教师）、R2（学生，课程，成绩）、R3（学生，时间，教室，课程），其中R2的规范化程度最高达到__(3)__。 　　（1）A．（学生，课程）　B．（时间

求候选键/候选码要先会 求闭包 ，如果不会可以参考我的 这篇文章 。 下面给出一个方法，我称它为“LRN法”。 对于给定的关系R（A1，A2，…, An）和函数依赖集F，可将其属性分为四类： L类： 仅出现 在F的函数依赖 左部 的属性； R类： 仅出现 在F的函数依赖 右部 的属性； N类：在F的函数依赖 左右两边均未出现 的属性； LR类：在F的函数依赖 左右两边均出现 的属性。 这里还有几个定理，非常有用(我一般用定理1/2/3和推论1)。 定理1：对于给定的关系模式R及其函数依赖集F，若X（X属于R）是 L类 属性，则X必为R的 任一候选关键字的成员 。 推论1：对于给定的关系模式R及其函数依赖集F，若X（X属于R）是 L类 属性，且 X + 包含了R的全部属 性，则X必为R的 唯一候选关键字 。 定理2：对于给定的关系模式R及其函数依赖集F，若X（X属于R）是 R类 属性，则X 不在任何候选关键字 中。 定理3：对于给定的关系模式R及其函数依赖集F，若X（X属于R）是 N类 属性，则X必为R的 任一候选关键字的成员 。 推论2：对于给定的关系模式R及其函数依赖集F，若X（X属于R）是 N类和L类 组成的属性集，且 X + 包含了R的全部属性 ，则X必为R的 唯一候选关键字 。 例： 关系模式R（U，F），其中U={A，B，C}，F={AB→C，C→A}，试求此关系的候选键