函数依赖与范式

合集下载

04-1 关系规范化理论

04-1 关系规范化理论

消除冗余数据,但丢失数据依赖关系
7
(3)第三种分解方法
• • • • S(学号,学生姓名,学院名称,导师姓名) P(项目编号,项目名称) D(学院名称,院长) T(承担任务)
消除冗余数据,但丢失了信息。
8
(4)第四种分解方法
• • • • S(学号,学生姓名,学院名称、导师姓名) P(项目编号,项目名称) D(学院名称,院长) S_P(学号,项目编号,承担任务)
43
二、Armstrong公理系统
对于关系模式R(U,F),有 • 公理1:自反律(Reflexivity) 若Y X U,则X→Y为F所蕴含。 • 公理2:增广律(Augmentation) 若X→Y为F所蕴含,且ZU,则XZ→YZ为F所蕴 含。 • 公理3:传递律(Transitivity) 若X→Y,Y→Z为F所蕴含,则X→Z为F所蕴含。
自反律、增广律、传递律是最基本的Armstrong公理。
44
由自反律、增广律、传递律可以导出下面三条推理规则。
公理4:合并规则
由X→Y,X→Z,有X→YZ。 公理5:伪传递规则 由X→Y,WY→Z,有XW→Z 公理6:分解规则 由X→Y及 Z Y,有X→Z。
45
定理:Armstrong公理系统是有效的 (正确性)、完备的。 正确性:指公理1、2、3是正确的。 有效性:指由F出发根据Armstrong 公理推导出来的每一个函数依赖一 定在F+。 完备性:指F+中的每一个函数依赖, 必定可以由F出发根据Armstrong 公理推导出来。
10
解决方法
• 解决问题的方法就是将关系模式进一步分 解 • 将关系模式中的属性按照一定的约束条件 重新分组,争取“一个关系模式只描述一 个独立的实体”,使得逻辑上独立的信息 放在独立的关系模式中,即进行关系模式 的规范化处理。

[总结]关系数据库设计基础(函数依赖、无损连接性、保持函数依赖、范式、……)

[总结]关系数据库设计基础(函数依赖、无损连接性、保持函数依赖、范式、……)

[总结]关系数据库设计基础(函数依赖、⽆损连接性、保持函数依赖、范式、……)≏≎≟≗≖≍≭∼∽≁≃≂≅≊≈≉≇≳⪞⪆⋧⪊≵≲⪝⪅⋦⪉≴⊂ 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。

数据库-部分函数依赖,传递函数依赖,完全函数依赖,三种范式的区别

数据库-部分函数依赖,传递函数依赖,完全函数依赖,三种范式的区别

数据库-部分函数依赖,传递函数依赖,完全函数依赖,三种范式的区别要讲清楚范式,就先讲讲几个名词的含义吧:部分函数依赖:设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。

举个例子:学生基本信息表R中(学号,身份证号,姓名)当然学号属性取值是唯一的,在R关系中,(学号,身份证号)->(姓名),(学号)->(姓名),(身份证号)->(姓名);所以姓名部分函数依赖与(学号,身份证号);完全函数依赖:设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。

例子:学生基本信息表R(学号,班级,姓名)假设不同的班级学号有相同的,班级内学号不能相同,在R关系中,(学号,班级)->(姓名),但是(学号)->(姓名)不成立,(班级)->(姓名)不成立,所以姓名完全函数依赖与(学号,班级);传递函数依赖:设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。

例子:在关系R(学号 ,宿舍, 费用)中,(学号)->(宿舍),宿舍!=学号,(宿舍)->(费用),费用!=宿舍,所以符合传递函数的要求;在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。

所谓第一范式(1NF)是指数据库表的每一列(即每个属性)都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。

简而言之,第一范式就是无重复的列。

2、第二范式(2NF)第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。

第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。

为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。

6.第六章关系的规范化

6.第六章关系的规范化

第六章关系的规范化设计第六章关系的规范化设计第一节问题的提出第二节函数依赖第三节范式第四节数据依赖的公理系统第一节关系模式设计问题的提出如何设计一个合理的关系数据库模式?c3c2c1c3c1cno 77OS丁惠s283DS 丁惠s290DB 丁惠s287OS 李立s178DB 李立s1gradecname sname sno 泛关系模式泛关系:泛关系模式中存在的问题c3c2c1c3c1cno 77OS丁惠s283DS 丁惠s290DB 丁惠s287OS 李立s178DB 李立s1gradecname sname sno反映现实世界操作性能例:设计教学管理关系数据库模型sc问题分析Sno Cno Tno Sname Grade Cname Tname S1C1T1赵民90OS彭S1C2T2赵民90DS杨S1C3T3赵民85C++刘S1C4T4赵民87DB张S2C1T4李军90OS张S3C1T4陈江75OS张S3C2T2陈江70DS杨S3C4T4陈江56DB张S4C1T1魏致90OS彭S4C2T2魏致85DS杨S5C1T1乔远95OS彭S5C4T4乔远80DB张关系SCT产生问题的原因?解:sct(sno, cno, tno, sname, grade, cname, tname)属性间约束关系(即数据间的依赖关系)太强解一:(sno,(cno,tno,(tno,cno, tname (sno,cno,解二:(sno,(cno,(tno, tname (sno,cno,(tno,cno)分解关系解决问题的方法:例sc解(sno, cno, tno, sname, grade, cname, tnameS n o S n a m e S 1赵民S 2李军S 3陈江S 4魏致S 5乔远StudentsCno Cname C1OS C2DS C3C++C4DBCoursesSnoCno Grade S1C190S1C290S1C385S1C487S2C190S3C175S3C270S3C456S4C190S4C285S5C195S5C480scTno Tname T1 彭 T2 杨 T3 刘 T4 张TeachersTeachCno Tno C1T1C1T4C2T2C3T3C4T4本章要解决的主要问题理想第二节:函数依赖数据依赖函数依赖(1)、函数依赖定义X 函数决定Y Y函数依赖于XX Y例:只能根据语义来确定函数依赖性的存在与否。

关系数据库设计理论(关系模式、函数依赖、范式)

关系数据库设计理论(关系模式、函数依赖、范式)

函数依赖关系是属性间的一种多对一的关系。 函数依赖关系是属性间的一种多对一的关系。 如果X →Y, X←Y, 是一对一关系。 如果X →Y,且X←Y,则X和Y是一对一关系。
如学号与身份证号。 如学号与身份证号。
7.2
函数依赖
SQL Server 2000
三、函数依赖的几种特例
1、平凡函数依赖与非平凡函数依赖 、 如果X→Y, 如果X→Y,且Y X→Y 若Y 由于Y 由于Y 称为非平凡函数依赖。 X,则X→Y 称为非平凡函数依赖。
7.1
关系模式的评价
SQL Server 2000
教学(学号,姓名,年龄,系名,系主任,课程名,成绩) 教学(学号,姓名,年龄,系名,系主任,课程名,成绩)
学号 98001 98001 98002 98002 98003 98003 99001 姓名 李华 李华 张平 张平 陈兵 陈兵 陆莉 年龄 21 21 22 22 21 21 23 系名 计算机 计算机 计算机 计算机 数学 数学 物理 系主任 王民 王民 王民 王民 赵敏 赵敏 王珊 课程名 C语言 高等数学 C语言 高等数学 高等数学 离散数学 普通物理 成绩 90 80 65 70 95 75 85
7.1
关系模式的评价
SQL Server 2000
对于有问题的关系模式, 对于有问题的关系模式,可以通过模式分解的方法使之 规范化, 规范化,上述关系模式如果分解为如下三个关系则可以克服 以上出现的问题。 以上出现的问题。 学生(学号,姓名,年龄,系名) 学生(学号,姓名,年龄,系名) 系(系名,系主任) 系名,系主任) 选课(学号,课程名,成绩) 选课(学号,课程名,成绩) 如何分解关系模式,分解的依据是什么? 如何分解关系模式,分解的依据是什么?下二节将讨论 这些问题。 这些问题。

关系数据理论

关系数据理论
则称Z传递函数依赖于X S# SD,SD DEAN
练习:给出一个具有传递函数依赖的关系模式例子
存在传递函数依赖的例子
示例
考虑为管理职工的工资信息而设计一个关系模式
职工 赵明 钱广 孙志 李开 周祥
级别 4 5 6 5 6
工资 500 600 700 600 700
函数依赖
候选码:设K为R< U , F >的属性(组),若K f U,
消除非主属性对码的部分依赖 如S2NF,因为 (S#,C#)p SN (S#,C#)p SD
2NF
改造
非主属性有两种,一种完全依赖于码,一种部分依赖于码。 将S分解为: SC(S# , C# , G) S_SD(S# , SN , SD , DEAN)
练习
关系模式R(A,B,C,D),码为AB,给出它的一个函数 依赖集,使得R属于1NF而不属于2NF
第六章 关系数据理论
内容出处: 1.Abraham Silberschatz《数据库系统概念》第七 章
第六章 关系数据理论
教学目的
本章讨论如何进行关系数据库的逻辑设计。首先介绍函数依赖的概念,然 后利用函数依赖和其他类型的依赖定义范式,并给出利用Armstrong公理 系统确定范式级别的方法,最后介绍一些将关系模式分解为更高级范式的 模式分解算法。
问题:关系模式的形式描述?
关系模式的设计问题
关系模式的形式描述
关系模式由五部分组成,即关系模式是一个五元组: R(U,D,DOM,F)
R:关系名 U:组成该关系的属性名集合 D:属性组U中属性所来自的域 DOM:属性到域的映射 F:属性间的数据依赖集合。它限定了组成关系的各个元组
3NF
不良特性
S_SD(S# , SN , SD , DEAN)

数据库函数依赖及范式(最通俗易懂)

数据库函数依赖及范式(最通俗易懂)

数据库函数依赖及范式(最通俗易懂)⼀、基础概念 要理解范式,⾸先必须对知道什么是关系数据库,如果你不知道,我可以简单的不能再简单的说⼀下:关系数据库就是⽤⼆维表来保存数据。

表和表之间可以……(省略10W字)。

然后你应该理解以下概念: 实体:现实世界中客观存在并可以被区别的事物。

⽐如“⼀个学⽣”、“⼀本书”、“⼀门课”等等。

值得强调的是这⾥所说的“事物”不仅仅是看得见摸得着的“东西”,它也可以是虚拟的,不如说“⽼师与学校的关系”。

属性:教科书上解释为:“实体所具有的某⼀特性”,由此可见,属性⼀开始是个逻辑概念,⽐如说,“性别”是“⼈”的⼀个属性。

在关系数据库中,属性⼜是个物理概念,属性可以看作是“表的⼀列”。

元组:表中的⼀⾏就是⼀个元组。

分量:元组的某个属性值。

在⼀个关系数据库中,它是⼀个操作原⼦,即关系数据库在做任何操作的时候,属性是“不可分的”。

否则就不是关系数据库了。

码:表中可以唯⼀确定⼀个元组的某个属性(或者属性组),如果这样的码有不⽌⼀个,那么⼤家都叫候选码,我们从候选码中挑⼀个出来做⽼⼤,它就叫主码。

全码:如果⼀个码包含了所有的属性,这个码就是全码。

主属性:⼀个属性只要在任何⼀个候选码中出现过,这个属性就是主属性。

⾮主属性:与上⾯相反,没有在任何候选码中出现过,这个属性就是⾮主属性。

外码:⼀个属性(或属性组),它不是码,但是它别的表的码,它就是外码。

⼆、6个范式 好了,上⾯已经介绍了我们掌握范式所需要的全部基础概念,下⾯我们就来讲范式。

⾸先要明⽩,范式的包含关系。

⼀个数据库设计如果符合第⼆范式,⼀定也符合第⼀范式。

如果符合第三范式,⼀定也符合第⼆范式…第⼀范式(1NF):属性不可分。

在前⾯我们已经介绍了属性值的概念,我们说,它是“不可分的”。

⽽第⼀范式要求属性也不可分。

那么它和属性值不可分有什么区别呢?给⼀个例⼦:name tel age⼤宝136****567822⼩明139****6655010-123456721Ps:这个表中,属性值“分”了。

第四章 数据库规范化理论(第二节)

第四章 数据库规范化理论(第二节)
在上面的例中,关系模式:COURSE(C#, TITLE, LNAME, ROOM#)
其中存在非主属性ROOM#对码的传递依赖, 即:
C#→LNAME, LNAME→ROOM# 因此COURSE不属于3NF。
将COURSE分解为:COURSE1(C#, TITLE, LNAME) 和 LECTURE(LNAME, ROOM#),
则关系模式COURSE1和LECTURE中都没有传递函数依赖,
因此 COURSE1 和 LECTURE 都属于3NF。
16
第四章 数据库规范化理论
第二节、 范式理论
三、 第三范式(3NF)
至此,关系模式REPORT分解为下列3个属于3NF的一组关系模式:
REPORT1 (S#, C#, MARKS) COURSE1 (C#, TITLE, LNAME) LECTURE (LNAME, ROOM#)
非第一范式的例子如表4-4,可以转换为第一范式如表4-5。
表4-4
研究生
导师
专业
第一个研究生 第二个研究生
表4-5
导师 专业 第一个研究生 第二个研究生
几乎所有的商用关系DBMS都要求关系为第一范式
4
第四章 数据库规范化理论
第二节、 范式理论
一、 第一范式(1NF)
如果关系仅仅满足第一范式的条件是不够的,可能会存在更新异常。
定义:关系模式R∈1NF,若X→Y,且Y⊈ X 时,X必含有候选码,则R∈BCNF。
即 在关系模式R中,若R的每一个决定因素都包含候选码,则R∈BCNF。
由BCNF的定义可知,一个满足BCNF的关系模式有如下特性:
● 每个非主属性对每个码都是完全函数依赖;
● 所有的主属性对每一个不包含它的码,也是完全函数依赖;

数据库函数依赖和范式总结

数据库函数依赖和范式总结

数据库函数依赖和范式总结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没有真子集则也称为完全函数依赖。

数据库工程师软考 知识点总结

数据库工程师软考 知识点总结

数据库工程师软考知识点总结一、数据库基础概念。

1. 数据模型。

- 概念数据模型:如E - R模型(实体 - 联系模型),包括实体、属性、联系的概念。

实体是现实世界中可区别于其他对象的“事物”或“对象”;属性是实体所具有的某一特性;联系反映实体之间的关联关系,有一对一、一对多、多对多等类型。

- 逻辑数据模型:- 层次模型:以树形结构表示数据间的层次关系,有且只有一个根节点,根节点以外的节点有且只有一个父节点。

- 网状模型:用有向图结构表示实体和实体之间的联系,节点之间可以有多种联系。

- 关系模型:以二维表(关系)的形式组织数据,表中的行称为元组,列称为属性。

关系模型具有数据结构简单、操作方便等优点,是目前主流的数据库模型。

2. 数据库系统结构。

- 三级模式结构。

- 外模式:也称子模式或用户模式,是数据库用户(包括应用程序员和最终用户)能够看见和使用的局部数据的逻辑结构和特征的描述,是数据库用户的数据视图,是与某一应用有关的数据的逻辑表示。

- 模式:也称逻辑模式,是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。

模式描述的是数据的全局逻辑结构,外模式通常是模式的子集。

- 内模式:也称存储模式,是数据在数据库系统内部的表示,即对数据的物理结构和存储方式的描述,包括数据的组织和存储方法、索引的组织和管理、数据压缩、加密等。

- 二级映像。

- 外模式/模式映像:定义了外模式与模式之间的对应关系。

当模式改变时(如增加新的关系、改变关系的属性等),由数据库管理员对各个外模式/模式的映像做相应改变,可以使外模式保持不变,从而应用程序不必修改,保证了数据的逻辑独立性。

- 模式/内模式映像:定义了数据库全局逻辑结构与存储结构之间的对应关系。

当数据库的存储结构改变时(如选用了另一种存储结构),由数据库管理员对模式/内模式映像做相应改变,可以使模式保持不变,从而应用程序也不必修改,保证了数据的物理独立性。

数据库函数依赖关系模式范式候选键主键码

数据库函数依赖关系模式范式候选键主键码
• ACD
• 因为 AC→B • 所以 AC→ACB • 所以 ACD→ABCD • 所以R的候选码是ACD
• 设有关系模式R(U,F),其中 U={A,B,C,D,E,I} F={A->D,AB->E,BI>E,CD->I,E->C}
• 计算(AE)的闭包
• 设有关系模式R(U,F),其中 U={A,B,C,D,E,I} F={A->D,AB->E,BI>E,CD->I,E->C}
• 计算(AE)的闭包
• 在F中找出左边是AEDC子集的函数依赖, 其结果是CD->I,所以X(2)=ACDEI,但F中 未用过的函数依赖的左边属性已没有X(2)的 子集,即(AE)的闭包=ACDEI
• 设有关系模式R(A,B,C,D,E,F)其函数依 赖集为F={E→D,C→B,CE→F,B→A,求候 选码
• 设有关系模式R(A,B,C,D,E,F)其函数依 赖集为F={E→D,C→B,CE→F,B→A,求候 选码
• L: C,E
• R:A,D,F
• LR:B • N:无
• 设有关系模式R(A,B,C,D,E,F)其函数依 赖集为F={E→D,C→B,CE→F,B→A,求候 选码
候选键,且为唯一候选键。 • 对于LR类,求出其闭包,若包含所有属性,则为候选键,
若不包含,在找出其中一个属性结合。 • 对于N类,直接加至候选键即可。
• 其中U={W,X,Y,Z},F={WX→Y,W→X, X→Z,Y→W} • L:无
• R:Z • LR:w,x,y • N:无 • 先排除z • 在LR中,w的闭包为{w,y,z,x} • x的闭包为{x,z} • y的闭包为{y,w} • wx的闭包为{w,x,y,z} • wy的闭包为{w,y} • xy的闭包为{x,y,z,w} • wxy的闭包为{x,z,y,w} • 由此可见,候选键为{w,wx,xy,xyw} • 可从候选键中选取一个作为主键。

数据库系统原理第七章答案

数据库系统原理第七章答案
第二十页,编辑于星期五:九点 九分。
例子
【例】已知关系R〈U,F〉,其中U={A,B,C,D,E}, F={AB→C,B→D,C→E,EC→B,AC→B},求(AB)F+。 设X=AB ∵ XF(0)=AB XF(1)=ABCD
XF(2)=ABCDE
XF(3)= XF(2)=ABCDE ∴ (AB)F+=ABCDE={A,B,C,D,E}
XF+={ Ai | Ai∈U,X→Ai∈F+}
第十九页,编辑于星期五:九点 九分。
(2) 属性集闭包XF+的求法
1) 选X作为闭包XF+的初值XF(0)。 2) XF(i+1)是由XF(i)并上集合A所组成,其中A为F中存在 的函数依赖Y→Z,而AZ,YXF(i)。 3) 重复步骤2)。一旦发现XF(i)= XF(i+1),则XF(i)为所求 XF+。
1) 合并规则:由X→Y,X→Z,有X→YZ。 2) 伪传递规则:由X→Y,WY→Z,有XW→Z。 3) 分解规则:由X→Y及ZY,有X→Z。
第十八页,编辑于星期五:九点 九分。
3. 函数依赖集闭包F+和属性集闭包XF+
(1) 函数依赖集闭包F+和属性集闭包XF+的定义 定义:在关系模式R〈U,F〉中,为F所逻辑蕴含的函数 依赖的全体叫做F的闭包,记作F+。 定义:设有关系模式R〈U,F〉,X是U的子集,称所有 从F推出的函数依赖集X→Ai中Ai的属性集为X的属性闭 包,记作XF+。即:
第八页,编辑于星期五:九点 九分。
完全函数依赖、传递函数依赖
2) 在R〈U〉中,如果X→Y,并且对于X的任何一个真子集X’,
都有X’ Y,则称Y对X完全函数依赖,记作:X→Y;若XF →Y,

函数依赖

函数依赖

5.2 函 数 依 赖在数据依赖现象的讨论中,函数依赖是最为常见和最为基本的情形。

本节将较为详细地讨论函数依赖及其相关问题。

数据库理论及应用基础 335.2.1 函数依赖基本概念1. 函数依赖设R(U)是属性集U 上的关系模式,X 、Y 是U 的一个子集。

r 是R(U)中任意给定的一个关系。

若对于r 中任意两个元组s 和t ,当s[X] = t[X]时,就有s[Y] = t[Y],则称属性子集X 函数决定属性子集Y 或者称Y 函数依赖于X(Functional Dependence),否则就称X 不函数决定Y 或者称Y 不函数依赖于X 。

当Y 函数依赖于X 时,则记其为X →Y 。

如果X →Y ,则称X 为决定因素(Determinant),称Y 为依赖因素(Dependent)。

当Y 不函数依赖于X ,则记为X /→Y 。

如果X →Y ,且Y →X ,则记其为X ←→Y特别需要注意的是,函数依赖不是指关系模式R 中某个或某些关系满足的约束条件,而是指R 的一切关系均要满足的约束条件。

函数依赖概念实际上是候选键概念的推广。

事实上,每个关系模式R 都存在候选键,每个候选键K 都是一个属性子集,由候选键定义,对于R 的任何一个属性子集Y ,在R 上都有函数依赖K →Y 成立。

一般而言,给定R 的一个属性子集X ,在R 另取一个属性子集Y ,不一定有X →Y 成立,但是对于R 中候选键K ,R 的任何一个属性子集都与K 有函数依赖关系,K 是R 中任意属性子集的决定因素。

2. 函数依赖的3种基本情形函数依赖可以分为3种基本情形。

(1) 平凡与非平凡函数依赖如果X →Y ,但Y 不是X 的子集,则称X →Y 是非平凡函数依赖(Nontrivial Functional Dependence),否则称为平凡函数依赖(Trivial Functional Dependence)。

按照函数依赖的定义,当Y 是X 的子集时,Y 自然是函数依赖于X 的,这里“依赖”不反映任何新的语义。

数据库原理--函数依赖和范式

数据库原理--函数依赖和范式

数据库原理--函数依赖和范式关系数据库设计范式介绍 .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)、部门名称、部门简介等信息。

函数依赖理论第三讲

函数依赖理论第三讲

Boyce-Codd范式(BCNF)
• 给定关系模式r(R)及函数依赖集F,若F+中的所有函数依赖 (R,R)至少满足下列条件之一: • 是平凡函数依赖(即); • 是r(R)的一个超码(即+包含R的全部属性)。
– 即起决定作用的属性必须是超码!
则称r(R)属于Boyce-Codd范式,记为r(R)BCNF。
• 第三范式的目标是:去掉表中不依赖于主码的数据。 • 也就是说,在满足第二范式的实体中,非主属性不能依赖 于另一个非主属性,即所有的非主属性应该直接依赖于
全部的主属性(即必须完全依赖,这是2NF的要求),并
且彼此之间无相互依赖关系(即不能存在部分依赖,这是 3NF的要求)。 • 换一句话说,非主属性不能包括它们自己的属性,如果属 性不包括属性,则它们就是真正的实体。
则不一定成立。 • 3NF存在数据冗余和异常问题,而BCNF是基于函数依赖理 论能够达到的最好关系模式。 • BCNF范式分解是无损分解,但不一定是保持依赖分解;而
3NF分解既是无损分解,又是保持依赖分解。
谢谢观看!
– 没有任何属性完全函数依赖于非候选码的任何一组属 性。
• BCNF范式排除了: – 任何属性(包括主属性和非主属性)对候选码的部分依赖 和传递依赖; – 主属性之间的传递依赖。
Boyce-Codd范式判断举例
• 例1 r(R)=r(A, B, C),F={A→B, B→C}。 – r(R)的候选码为A,r(R)BCNF,因为函数依赖B→C中的决 定属性B不是超码。 • 例2 r(R)=r(A, B, C),F={AB→C, C→A}。 – r(R)的候选码为AB或BC,r(R)BCNF,因为C→A的决定属 性C不是超码。
– 显然,这两种分解得到的r1(R1)和r2(R2)都属于BCNF范式。

数据库学习笔记-函数依赖及范式判断

数据库学习笔记-函数依赖及范式判断

数据库学习笔记-函数依赖及范式判断
⼀、基本概念
1、主码:⼜称为主键、主关键字,注意:主码是个能够唯⼀标识⼀条记录的最⼩属性集(是从候选码⾥⼈为挑选的⼀条)
2、关键字:⼜称为候选码;
 3、候选关键字:候选码去掉主码剩下的部分即为候选关键字;
4、码=超键:唯⼀标识实体的属性或属性组合;
⼆、函数依赖
这⾥我选择使⽤我理解的⽅式⽤尽可能通俗的⽅式解释⼀下
完全函数依赖:码A完全依赖码B,则⽆论码B中有多少个属性,不能存在码B拆除了⼀部分还能决定码A的情况;
部分函数依赖:与完全函数依赖对应,就是码A依赖码B,把码B拆吧拆吧还能攒出来⼀个决定码A的⼩码B;
传递函数依赖:就是码A依赖码B,码C依赖码A,
类似这种可以接起来的情况:
B—> A, A —>C
如果A不决定B,那么就满⾜传递函数依赖(A决定B就变成直接依赖了)
三、关系范式基本概念
1NF:属性不可拆分——所有关系数据库中的关系都要满⾜第⼀范式
2NF:在第⼀范式基础上,
⾮主属性完全依赖主键(主码),即消除⾮主属性部分函数依赖;
3NF:在第⼆范式基础上,
⾮主属性不存在传递依赖候选键;
BCNF:在第三范式基础上,
主属性也消除掉传递依赖,即所有属性都不存在传递依赖;。

三大范式定义

三大范式定义

三大范式
1第—范式(INF):毎一列都是不可分分隔的原子数据顶
2第二范式(2NF):在1NF的基础上,非码属性必须完全依赖于码
(在1NF础上消除非主属性对主码的部分函数依赖)
3笫三范式(3NF):在2NF基础上,任何非主属性不依赖于其它非主属性
(在2NF的基础上消除传递依赖)
•几个概念:
1.函数依赖:A-->B,如果通过A属性(属性组)的值,可以确定唯一B属性的值。

则称B依赖于A
例如:学号-->姓名。

(学号,课程名称)-->分数
2.完全函数依赖:A-->B,如果A是—个属性组,
则B属性值得依赖于A属性组中所有的属性值•
例如:(学号,课程名称)分数
3.部分函教依赖:A-->B,如果A是一个属性组,
则B属性值确定只需要依赖于A属性组中某一个值即可
例如:(学号,课程名称)-- >姓名
4.传递函数依赖A -- >B, B -- >C如果通过A属性(属性组)的值,可以确定唯一B属性的值,在通过B属性(属性组)的值可以确定唯一C属性的值,则称C 传速函数依赖于A例如:学号一>系名,系名系主任•
5.码.如果在一张表中,一个属性或属性组,被其他所有属性所完全依赖,则称这个属性(属性组)为该表的码
例如:该表中码为:(学号,课程名称)
*主属性:码属性组中的所有属性. *非主属性:除去主属性的属性。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

-----------------------------------------------------------------------------------------第二范式:
定义:如果关系模式 R 是第一范式的,而且关系中每一个非主属性不部分依赖于主键,称 R 是第二范式的。
所以第二范式的主要任务就是
01
john
Male kkkk@ 222456 200401
01
mary
famale kkk@ 123455 200402
表二
ClassNo | ClassAddress 200401 A 楼 2 200402 A 楼 3 (学生上课表)
学生 课程 老师 老师职称 教材 教室 上课时间
小明 一年级语文(上) 大宝 副教授 《小学语文 1》 101 14:30
一个学生上一门课,一定在特定某个教室。所以有(学生,课程)->教室 一个学生上一门课,一定是特定某个老师教。所以有(学生,课程)->老师
一个学生上一门课,他老师的职称可以确定。所以有(学生,课程)->老师职称
一个学生上一门课,一定是特定某个教材。所以有(学生,课程)->教材 一个学生上一门课,一定在特定时间。所以有(学生,课程)->上课时间
Male kkkk@ 222456 famale kkk@ 123455
这两种情况都不满足第一范式。不满足第一范式的数据库,不是关系数据库!所以,我们在 任何关系数据库管理系统中,做不出这样的“表”来。
在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF) 的数据库就不是关系数据库。
BC 范式的定义:如果关系模式 R∈1NF,且 R 中每一个决定因素都是候选键,则 R 是满足 BC 范式的关系,记作 R∈BCNF。
当一个关系模式 R∈BCNF,则在函数依赖范畴里,已实现了分离,消除了插入、删除 的异常。
4.非 平 凡 函 数 依 赖 当 关 系 中 属 性 集 合 Y 不 是 属 性 集 合 X 的 子 集 时 , 存 在 函 数 依 赖 X→ Y, 则称这种函数依赖为非平凡函数依赖。
5.完 全 函 数 依 赖
设 X,Y 是 关 系 R 的 两 个 属 性 集 合 , X’是 X 的 真 子 集 , 存 在 X→ Y, 但 对 每 一 个 X’都 有 X’!→ Y, 则 称 Y 完 全 函 数 依 赖 于 X。
1.数 据 依 赖 数据依赖指的是通过一个关系中属性间的相等与否体现出来的数据间 的相互关系,其中最重要的是函数依赖和多值依赖。
2.函 数 依 赖 设 X,Y 是 关 系 R 的 两 个 属 性 集 合 , 当 任 何 时 刻 R 中 的 任 意 两 个 元 组 中 的 X 属 性 值 相 同 时 ,则 它 们 的 Y 属 性 值 也 相 同 ,则 称 X 函 数 决 定 Y,或 Y 函 数 依 赖 于 X。 3.平 凡 函 数 依 赖 当 关 系 中 属 性 集 合 Y 是 属 性 集 合 X 的 子 集 时 ( Y ∈X ) , 存 在 函 数 依 赖 X → Y, 即 一 组 属 性 函 数 决 定 它 的 所 有 子 集 , 这 种 函 数 依 赖 称 为 平 凡 函 数 依 赖。
3NF 去除了非主属性对主键的部分函数依赖和传递函数依赖。一般满足 3NF 的关系模式已 能消除冗余和各种异常现象,获得较满意的效果,但无论 2NF 还是 3NF 都没有涉及主属性 间的函数依赖,所以有时仍会引起一些问题。由此我们引入 BC 范式(BCNF,Boyeet 和 Codd 提出),通常认为 BCNF 是第三范式的改进。
第一范式
定义:如果关系 R 中所有属性的值域都是单纯域,那么关系模式 R 是第一范式的 那么符合第一模式的特点就有
1)有主关键字 2)主键不能为空, 3)主键不能重复, 4)字段不可以再分 例如:
StudyNo | Name | Sex | Contact
20040901 john
Male Email:kkkk@,phone:222456
小明 一年级语文(上) 大宝 101 14:30
老师 老师职称 大宝 副教授 ----------------------------------------------------------------------
BC 范式(BCNF):
符合 3NF,并且,主属性不依赖于主属性
若关系模式属于第一范式,且每个属性都不传递依赖于键码,则 R 属于 BC 范式。
因此(学生,课程)是一个码。
然而,一个课程,一定指定了某个教材,一年级语文肯定用的是《小学语文 1》,那么就有 课程->教材。(学生,课程)是个码,课程却决定了教材,这就叫做不完全依赖,或者说 部分依赖。出现这样的情况,就不满足第二范式!
有什么不好吗?你可以想想:
1、校长要新增加一门课程叫“微积分”,教材是《大学数学》,怎么办?学生还没选课,而 学生又是主属性,主属性不能空,课程怎么记录呢,教材记到哪呢? ……郁闷了吧?(插入异 常)
通常 BC 范式的条件有多种等价的表述:每个非平凡依赖的左边必须包含键码;每个决定因 素必须包含键码。
BC 范式既检查非主属性,又检查主属性。当只检查非主属性时,就成了第三范式。满足 BC 范式的关系都必然满足第三范式。
还可以这么说:若一个关系达到了第三范式,并且它只有一个候选码,或者它的每个候选码 都是单属性,则该关系自然达到 BC 范式。
20040901 john
Male kkkk@ 优秀
$1000
20040902 maryfamale kkk@ 良
$600
这个完全满足了第二范式,但是 bounsLevel 和 bouns 存在传递依赖
更改为:
StudyNo | Name | Sex | Email
20040901 john
有什么问题吗?想想:
1、 老师升级了,变教授了,要改数据库,表中有 N 条,改了 N 次……(修改异常)
2、 没人选这个老师的课了,老师的职称也没了记录……(删除异常)
3、 新来一个老师,还没分配教什么课,他的职称记到哪?……(插入异常)
那应该怎么解决呢?和上面一样,投影分解:
学生 课程 老师 教室 上课时间
所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不 能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属 性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一 对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。例如,对于图 3-2 中 的员工信息表,不能将员工信息都放在一列中显示,也不能将其中的两列或多列在一列中显 示;员工信息表的每一行只表示一个员工的信息,一个员工的信息在表中只出现一次。简而 言之,第一范式就是无重复的列。
满足第一范式的前提下,消除部分函数依赖。
StudyNo | Name | Sex | ClassAddress
Email
| Phone | ClassNo |
01
john Male kkkk@ 222456 200401
A楼2
01
mary famale kkk@ 123455 200402
20040901 mary
famale email:kkk@ phone:123455
以上的表就不符合,第一范式:主键重复(实际中数据库不允许重复的),而且 Contact 字段 可以再分
所以变更为正确的是
StudyNo | Name | Sex | Email
| Phone
20040901 john 20040902 mary
函数依赖与范式
版权所有:07 数字媒体
主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。 非主属性:与上面相反,没有在任何候选码中出现过,这个属性就是非主属性。 外码:一个属性(或属性组),它不是码,但是它别的表的码,它就是外码。 码:表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那 么大家都叫候选码,我们从候选码中挑一个出来做老大,它就叫主码。 第一范式是确定模式是符合关系关系模式的要求,即确立某关系属于关系模式。 第二范式是消除了非主属性对主码的部分函数依赖。 第三范式是消除了非主属性的传递函数依赖。 BCNF 是消除了所有属性的传递函数依赖。
A楼3
这个表完全满足于第一范式, 主键由 StudyNo 和 ClassNo 组成,这样才能定位到指定行 但是,ClassAddress 部分依赖于关键字(ClassNo-〉ClassAddress), 所以要变为两个表
表一
StudyNo | Name | Sex | Email
| Phone | ClassNo
学生 课程 老师 老师职称 教室 课时间
小明 一年级语文(上) 大宝 副教授 101 14:30 学生上课表新
课程 教材 一年级语文(上) 《小学语文 1》 课程的表
第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖 主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成 一个新的实体
-------------------------------------------------------------------------------第三范式:
满足第二范式的前提下,消除传递依赖。
例:
StudyNo | Name | Sex | Email
| bounsLevel | bouns
2、下学期没学生学一年级语文(上)了,学一年级语文(下)去了,那么表中将不存在一 年级语文(上),也就没了《小学语文 1》。这时候,校长问:一年级语文(上)用的什么 教材啊?……郁闷了吧?(删除异常)
相关文档
最新文档