备注型。
access的数据类型是关系数据库。备注型用来保存长度较长的文本及数字,允许字段能够存储长达65535个字符的内容。但Access不能对备注字段进行排序或索引,却在备注字段中虽然可以搜索文本,但却不如在有索引的文本字段中搜索得快。
在Access数据库中,一种用于建立同步复制唯一标识符的 16 字节字段。GUID用于标识副本,副本集,表,记录和其他对象。在 Access 数据库中GUID 是同步复制 ID。)
扩展资料:
注意事项:
1、Access数据库的通配符为号,一般数据库为%号。
2、Access数据库的日期查询需要在日期前后需要加#号,一般数据库用单引号括起来即可。
3、Access数据库日期的转换使用CDate函数,其他数据库有相应函数,一般不需要转换成日期类型时可以使用单引号括起来即可。
4、连接字符串,可以使用相对路径,也可以使用绝对路径:Provider=MicrosoftJetOLEDB40;Data Source=data\MiddleResultmdb。
参考资料来源:百度百科-access
关系模型不能表示实体之间多对多的关系是错的。
关系实际上就是关系模式在某一时刻的状态或内容。其最基本的组成要素是实体,关系和属性 。也就是说,关系模式是型,关系是它的值。关系模式是静态的、稳定的,而关系是动态的、随时间不断变化的,因为关系 *** 作在不断地更新着数据库中的数据。但在实际当中,常常把关系模式和关系统称为关系,读者可以从上下文中加以区别。
定义:关系数据模型是以集合论中的关系概念为基础发展起来的。关系模型中无论是实体还是实体间的联系均由单一的结构类型——关系来表示。在实际的关系数据库中的关系也称表。一个关系数据库就是由若干个表组成。关系模型是指用二维表的形式表示实体和实体间联系的数据模型。
优点: 数据结构单一,关系模型中,不管是实体还是实体之间的联系,都用关系来表示,而关系都对应一张二维数据表,数据结构简单、清晰。关系规范化,并建立在严格的理论基础上,构成关系的基本规范要求关系中每个属性不可再分割,同时关系建立在具有坚实的理论基础的严格数学概念基础上。
概念简单, *** 作方便,关系模型最大的优点就是简单,用户容易理解和掌握,一个关系就是一张二维表格,用户只需用简单的查询语言就能对数据库进行 *** 作。
一、概念
(1)关系数据库的表采用二维表格来存储数据,是一种按行与列排列的具有相关信息的逻辑组,它类似于Excle工作表。一个数据库可以包含任意多个数据表。
(2)关系数据库:在一个给定的应用领域中,所有实体及实体之间联系的集合构成一个关系数据库。它是一种以关系模式为基础存储数据以及用数字方法处理数据库组织的方法,是目前最为流行的一种数据组织形式。
(3)元组(记录)。表中的一行即为一个元组,或称为一条记录。
(4)字段,数据表中的每一列称为一个字段,表是由其包含的各种字段定义的,每个字段描述了它所含有的数据的意义,数据表的设计实际上就是对字段的设计。创建数据表时,为每个字段分配一个数据类型,定义它们的数据长度和其他属性。字段可以包含各种字符、数字、甚至图形。
二、关系
一个数据库可以包含若干张表;一张表有若干个字段;每张表又有若干条记录(元组),每条记录(元组)对应每个字段都有一个值。
扩展资料
关系数据库,是建立在关系数据库模型基础上的数据库,借助于集合代数等概念和方法来处理数据库中的数据。
同时也是一个被组织成一组拥有正式描述性的表格,该形式的表格作用的实质是装载着数据项的特殊收集体,这些表格中的数据能以许多不同的方式被存取或重新召集而不需要重新组织数据库表格。
关系数据库的定义造成元数据的一张表格或造成表格、列、范围和约束的正式描述。每个表格(有时被称为一个关系)包含用列表示的一个或更多的数据种类。 每行包含一个唯一的数据实体,这些数据是被列定义的种类。
参考资料来源:百度百科-关系数据库
82 规范化理论
关系数据库中关系规范化问题在1970年Godd提出关系模型时就同时被提出来,关系规范化可按属性间不同的依赖程度分为第一范式,第二范式,第三范式,Boyce-Codd范式以及第四范式人们对规范化的认识是有一个过程的,在1970年时已发现属性间的函数依赖关系,从而定义了与函数依赖关系有关的第一,第二,第三,及Boyce-Codd范式在1976~1978年间,Fagin,Delobe以及Zanjolo发现了多值依赖关系,从而定义了与多值依赖有关的第四范式
范式的定义与属性间的依赖关系的发现有密切关系,在本节中我们介绍函数依赖与多值依赖这两个概念,并在此基础上定义第一范式,第二范式,第三范式,Boyce-Codd范式以及第四范式
821 函数依赖
函数依赖(functional dependency)是关系模式内属性间最常见的一种依赖关系,例如在关系模式S中,S#与Sd间有一种依赖关系即S#的值一经确定后Sd的值也随之唯一地确定了,此时即称S#函数决定Sd或称Sd函数依赖于S#,它可用下面符号表示:
S# → Sd
同样,我们还可以有:
S# → Sa
S# → Sn
但是关系模式SC中的S#与G间则没有函数依赖关系,因为一个确定的学号S#可以允许有多个成绩(它们分别对应于不同的课程),因此成绩G并不能唯一地确定,但是(S#,C#)与G间则存在着函数依赖关系,即有:
(S#,C#)→G
函数依赖这个概念是属语义范畴的,我们只能根据语义确定属性间是否存在这种依赖,此外别无它法可循
定义8-1 设有关系模式R ( U ),X,Y是U的子集,若对于任一个关系R中的任一元组在X中的属性值确定后则在Y中的属性值必确定,则称Y函数依赖于X或称X函数决定Y, 并记作X→Y,而其中X称为决定因素,Y称为依赖因素对于函数依赖,我们一般总是使用一种叫非平凡的函数依赖,在本章中如无特殊声明,凡提到函数依赖时总认为指的是非平凡的函数依赖下面我们对非平凡函数依赖下一个定义
定义8-2 一个函数依赖关系X→Y如满足Y(X,则称此函数依赖是非平凡的函数依赖
为了对函数依赖作深人研究,也为了规范化的需要,我们还得引入几种不同类型的函数依赖
首先;引入一种完全函数依赖的概念,这个概念为真正的函数依赖打下基础例如在S申我们有S#→Sd,因而我们同样也会有:
(S#,Sn) →Sd
(S#,Sa) →Sd
比较这三种函数依赖后我们会发现,实际上真正起作用的函数依赖是:
S#→Sd
而其他两种函数依赖都是由它派生而成的,即是说在函数依赖中真正起作用的是S#,而不是Sn或Sa等这样,我们在研究函数依赖时要区别这两种不同类型的函数依赖,前一种叫完全函数依赖,而后一种叫不完全函数依赖
定义8-3 R( U )中如有X,Y(U,满足X→Y且对任何X的真子集X',都有X'→Y',则称Y完全函数依赖于X并记作:
X Y
定义8-4 在R( U )中如有X,Y(U且满足X→Y,但Y不完全函数依赖于X,则称Y部分依赖于X,并记作:
X Y
由上所述可知,Sd完全函数依赖于S#,但Sd不完全函数依赖于(S#,Sn),亦即有:
S# Sd
(S#,Sn) Sd
(S#,Sa) Sd
在函数依赖中还要区别直接函数依赖与间接函数依赖这两个不同的概念,例如S#→Sd中Sd是直接函数依赖于S#,但如果在属性中尚有系的电话号码DT(假如每个系有唯一的一个电话号码),则有:Sd→DT,从而由S#→Sd及Sd→DT可得到:
S# →DT
在这个函数依赖中,DT并不直接函数依赖于S#,而是经过中间属性Sd传递而依赖于S#,亦即是DT直接依赖于Sd,而Sd又直接依赖于S#,从而构成了DT依赖于S#这种函数依赖关系,是一种间接依赖关系,或叫传递依赖关系我们可以对它定义如下
定义8-5在R( U )中如有X,Y,Z(U且满足:
X→Y,(Y(X ) Y / X,Y→Z
则称Z传递函数依赖于X,否则,称为非传递函数依赖
注意,在这里传递函数依赖与非传递函数依赖仅作概念上区别, 在形式表示上不作任何区别,即Z传递函数依赖于X或Z非传递函数依赖于X都用X→Z表示,这样做的目的也是为了从全局考虑使得表示尽量简单与方便
定义了几种不同的函数依赖关系后,我们在此基础上继续定义一些十分重要的基本概念即有关关键字(keY)的一些概念
定义8-6 在R(U )中如有K(U且满足:
K U
则称K为R的关键字
一个关系模式可以有若干个关键字,我们在使用中选取其中的一个就够了,这个被选中的关键字叫做这个关系模式的主关键字(Prime key),而一般的关键字叫候选关键字(candidate key)
在关系模式S,C,SC中,S的关键字是S#,C的关键字是C#,而SC的关键字是(S#,C#),因为我们有:
S# (S#,Sn,Sd,Sa)
C# (C#,CN,P#)
(S#,C#) (S#,C#,G)
而S中,(S#,Sn),(S#,Sd)等均不是关键字,因为我们有:
(S#,Sn) (S#,Sn,Sd,Sa)
(S#,Sd) (S#,Sn,Sd,Sa)
在一个关系模式中,所有关键字中的属性构成一个集合,而所有其余的属性则构成另一个集合,这两个集合分别叫做这个关系模式的主属性集与非主属性集主属性集中的属性叫做主属性(prime attribute),非主属性集中的属性则叫非主属性(nonprime attribute)例如在关系模式S (S#,Sn,Sd,Sa)中, 主属性集为:
(S#)
而非主属性集为:
(Sn,Sd,Sa)
在SC(S#,C#,G)中,主属性集为:
{ S#, C# }
而非主属性为:
{G}
下面我们给出它们的定义:
定义8-7 R ( U )中所有关键字中的属性构成的集合P称为R(U )的主属性集
定义8-8 在R ( U )中所有非关键字中的属性构成的集合N称为R(U)的非主属性集以上建立了一系列与函数依赖有关的概念,有了它们后就可以讨论与函数依赖有关的几
个范式,它们是第一范式,第二范式及第三范式(实际上第一范式与所有依赖均无关,但为叙述方便起见,可视为与函数依赖有关)至于函数依赖的有关理论的探讨,将在本章稍后部分再作详细介绍
822 与函数依赖有关的范式
在这节中我们讨论四种范式,他们是第一范式,第二范式,第三范式以及Boyce-Codd范式
先介绍第一范式第一范式是关系模式所要遵循的基本条件,即关系中的每个属性值均必须是一个不可分割的数据量如一个关系模式满足此条件则称它属于第一范式(first normal form,或简写成lNF),一个关系模式R如满足第一范式,则可记为R∈lNF
第一范式规定了一个关系中的属性值必须是一个不可分割的数据,它排斥了属性值为元组,数组或某种复合数据等的可能性,使关系数据库中的所有关系的属性值均是最简单的,这样可以做到结构简单,讨论方便一般说来,每个关系模式均要满足第一范式,因为这是对每个关系的最基本要求
下面开始讨论真正与函数依赖有关的三个范式为了讨论这几个范式,我们一般对一个关系模式除了要确定其属性外,还要根据它的语义确定在这个模式上的所有函数依赖设有关系模式R,它有属性集U,而在它上的函数依赖集是F,则此时一个关系模式可由三元组R,U,F确定,它可以写成为:
R ( U,F )
注意,这个表示式仅表示一个三元组而已,它并不表示谓词或关系例如前面所提到的学生关系模式S,它可表示为:
S ({S#,Sn,Sd,Sa},{S#→Sn,S#→Sd,S#→Sa})
又如有一个关系模式叫SCG',它由属性S#,Sn,Sd,Sa, C#, G 组成,其中Ss表示学生所学专业,其他含义同前在这个关系模式中有一些语义信息,它们是:
(1 ) 每个学生均只属一个系与一个专业;
(2 ) 每个学生修读之每门课有且仅有一个成绩;
(3 ) 各系无相同专业
根据上述语义信息以及其他的一些基本常识,我们可以将它们用函数依赖形式表示出来,它们是:
S#→Sn
S#→Sd
S#→Ss
Ss→Sd
(S#,C#)→G
因此,这个关系模式的有关信息可写成为:
SCG'({S#,Sn,Sd,Ss,C#,G},{ S#→Sn,S#→Sd,S#→Ss, Ss S#→Sd, (S#,C# ) →G}
关系模式有了函数依赖后就可以讨论规范化的问题了关系中的每一级范式均提出了关系模式所要遵循的约束条件,目的是为了使得关系模式具有较少异常性与较小的冗余度,即是说使关系模式更"好"一些
下面讨论第二范式
定义8-9 设有R(U)∈lNF且其每个非主属性完全函数赖于关键字,则称R(U)满足第二范式(可简写为2NF)或写为R∈2NF
实际上并不是每个满足第一范式的关系模式必满足第二式,如前面例子中的关系模式SCG'即不满足第二范式这是因在SCG'中,它的关键字是(S#,C#),而它的非主属性集是:
(Sd,G,Sn,Ss)
虽然我们有:
(S#,C#) G
但是Sn,Sd,Ss均并不完全依赖(S#,C#),因此不满足第二范式的条件
一个关系模式若满足第二范式,则它必须具有较少异常与较小冗余度因此,一个关系模式若仅满足第一范式还不够,它必须满足第二范式,其方法是将一个关系模式分解成几个关系模式,使分解后的关系模式能满足第二范式如关系模式SCG'可分解成两个关系模式,它们是:
SCG'l ({S#,C#,G},{( S#,C#)→G})
SCG'2 ({S#,Sn,Sd,Ss},{S#→Sn,S#→Sd,S#→Ss→Sd})
这两个模式SCG'均可用图8-1所示的示意图表示之
模式SCG'I与SCG'2均满足第二范式,它们均有较少异常与较小冗余度,而SCG'l还可以做到无插人与删除异常的出现,而SCG'由于不满足第二范式,因此插入异常,删除异常均有存在,且数据冗余度也很大关于这方面的验证请读者自己去做
(a) SCG'示意图 (b)SCG'1及SCG'2示意图
图8-1 三个关系模式函数依赖示意图
但是,第二范式还不能完全避免异常现象的出现,如SCG'2虽满足第二范式,但仍会出现插入异常与删除异常如在SCG'2中,它有如表8-4所示的模式
表8-4 SCG'2的关系模式
S#
Sn
Sd
Ss
SCG'2:
在这个模式中,如果我们要登记一个尚未招生的系的专业设置情况,要插入这个情况在模式中是较为困难的这样,如果要删除一些学生,有可能会将有关系的专业设置情况一起删除究其原因,不外是因为Sd既函数依赖于S#又函数依赖于Ss,同时Ss又函数依赖于S#,并且由此引起了传递函数依赖的出现因此,看来要消除异常现象,必须使关系模式中无传递函数依赖现象出现,这样就产生了第三范式
第三范式要求关系模式首先得满足第二范式,同时每个非主属性都非传递依赖于关键字由此可以看出,如满足第三范式则每个非主属性既不部分依赖也不传递依赖于关键字
定义8-10 若关系模式R(U)的每个非主属性都不部分依赖也不传递依赖于关键字,则称R满足第三范式(可简写为3NF),并记作R∈3NF
第三范式将关系模式中的属性分成为两类,一类是非主属性集,另一类是主属性集,而非主属性集的每个属性均完全,不传递依赖于主属性集中的关键字,从而做到在关系模式中理顺了复杂的依赖关系,使依赖单一化与标准化,进而力求达到避免异常性的出现,其示意图可见图8-2,在图中可将关系模式比拟成一个原子,其中主属性集是这个原子的原子核,而非主属性集中的属性则是这个原子中的电子,它们紧紧依赖于主属性集构成一个紧密整体
一个关系模式如果不满足第三范式,可以通过模式分解使分解成若干个模式,使分解后的模式能满足第三范式例如关系模式SCG'中,SCG'2满足第二范式,但不满足第三范式,此时可将其分解成下面两个模式:
SCG'21(S#,Sn,Ss)
SCG'22 (Ss,Sd)
图8-2 第三范式的"原子"模型
其依赖示意图见图8-3
(a)SCC'l (b)SCG'21 (c)SCG'22
图8-3模解分解图
在SCG'中经过几次分解后,得到三个关系模式:
SCG'l,SCG'21,SCG'22
这三个模式均满足第三范式且没有异常现象出现,同时冗余度小
1972年Boyce,Codd等从另一个角度研究了范式,发现了函数依赖中的决定因素与关键字间的联系与范式有关,从而创立了另一种第三范式,称为Boyce-Codd范式
Boyce-Codd范式的大概意思是:如果关系模式中,每个决定因素都是关键字,则满足Boyce-Codd范式我们知道,一般而言,每个函数依赖中的决定因素不一定都是关键字,因此,只有当R中决定因素都是关键字时才能认为满足Boyce-Codd范式
定义8-1l 如R(U )中X,Y(U,假定满足R∈lNF,且若X→Y(Y(X)时X必含关键字,则称R满足Boyce-Codd范式(可简记BCNF)并记以R∈BCNF
下面一个问题我们需要研究BCNF与3NF间究竟有什么关系 经过仔细研究后,我们认为BCNF比3NF更为严格下面的定理给出了这个回答
定理8-1关系模式R(U)若满足BCNF,则必定满足3NF
这个定理的证明请读者设法自行证得(注:可以用BCNF及3NF的定义而求得)
这个定理告诉我们:一关系模式满足BCNF者必满足3NF但是,一关系模式满足3NF是否满足BCNF呢 即是说,定理8-1的充分条件是否成立呢 回答是否定的,即必存在一R(U)满足3NF,但不满足BCNF,这只要用一例即可说明
例8-1设有关系模式R(S, C,T),其中S, C含义同前, T表示教师,R有下列语义信息: (1)每个教师仅上一门课;
(2)学生与课程确定后,教师即唯一确定
这样,R就有如下函数依赖关系:
(S, C ) →T
T→C
这个关系模式满足3NF,因为它的主属性集为(S,C )非主属性集为 (T ),而T完全依赖于(S,C )且不存在传递依赖但这个关系模式不满足BCNF,因为T是决定因素,但T不是关键字
这个模式的示意图见图8-4
图8一4 例8一1示意图
从这个例子中也可以看出,实际上第三范式也避免不了异常性,如某课程本学期不开设,因此就无学生选读,此时有关教师固定开设某课程的信息就无法表示因此,要避免此种异常性,还需要进一步将关系模式分解成BCNF如在此例中可将R进一步分解成:
R1 (S, T )
R2 (T, C )
其示意图如图8-5所示而R1, R 2则为BCNF,这两个模式均不会产生异常现象
R1 R 2
图8-5 R分解成两个BCNF
从上面所述可以看出,BCNF比3NF更为严格,它将关系模式中的属性分成两类,一类是决定因素集,另一类是非决定因素集非决定因素集中的属性均完全,不传递地依赖于决定因素集中的每个决定因素关于这种比喻的一个示意图见图8-6
到此为止,由函数依赖所引起的异常现象,只要分解成BCNF即可获得解决在BCNF中每个关系模式内部的函数依赖均比较单一和有规则,它们紧密依赖而构成一个整体,从而可以避免异现象出现以及冗余量过多的现象
图8-6 BCNF的原子模型
823 多值依赖与第四范式
我们研究了函数依赖及与它有关的几个范式,但是否关系模式内属性间的依赖关系除函数依赖外就没有其他依赖关系呢 事实并不如此,函数依赖关系是一种较为明显的依赖关系,但是随着人们对关系模式了解越来越深刻后,发现尚有另外的一些依赖系存在,多值依赖就是其中的一种我们先举一个例子,以说明多值依赖的存在
例8-2设有一个课程关系C,它可用表8-5表示此表表示高等数学这门课的任课教师可以有3个,它的参考书可以有2本;普通物理这门课的任课教师也可以有3个,它的参考书可以有3本如用关系的形式表示,见表8-6
表8-5 关系C的示意图
课程名C
教师名T
选用参考书L
高等数学
李华民
王天华
林 静
高等数学
高等数学教程
普通物理
吴铁钢
谢晓芳
徐秋芳
物理学
普通物理
普通物理基础
表8-6 C的关系
C
T
L
高等数学
李华民
高等数学
高等数学
李华民
高等数学教程
高等数学
王天华
高等数学
高等数学
王天华
高等数学教程
高等数学
林 静
高等数学
高等数学
林 静
高等数学教程
普通物理
吴铁钢
物理学
普通物理
吴铁钢
普通物理
普通物理
吴铁钢
普通物理基础
普通物理
谢晓芳
物理学
普通物理
谢晓芳
普通物理
普通物理
谢晓芳
普通物理基础
普通物理
徐秋芳
物理学
普通物理
徐秋芳
普通物理
普通物理
徐秋芳
普通物理基础
从这个关系中可以看出两点
(1 ) 这个关系的数据冗余很大
(2 ) 这个关系的属性间有一种有别于函数依赖的依赖关系存在
我们仔细分析这种特殊依赖关系后发现它有两个特点:
(1)设如R(U)中X与Y有这种依赖关系,则当X的值一经确定后可以有一组Y值与之对应如确定C为高等数学,则有一组T的值:李华民,王天华,林静与之对应同样C与L也有类似的依赖
(2 ) 当X的值一经确定后,其所对应的一组Y值与U一X一Y无关如在C中,对应高等数学课的一组教师与此课程的参考书毫无关系,这就表示C与T有这种依赖,则T的值的确定与U一C一T= L无关
上述这种依赖显然不是函数依赖,我们称之为多值依赖(multi-valued dependency),如Y多值依赖于X,则可记为X→→Y
从上面所描述的多值依赖X→→Y的特点看,其第一个特点表示X与Y的对应关系是很随便的,X的一个值所对应的Y值的个数可不作任何强制性规定,即Y的值可以是从0到任意多个,其主要起强制性约束的是第二个条件,即X所对应的Y取值与U一X一Y无关,说得确切些,如有R(U)且如存在X→→Y,则对R(U)的任何一个关系R,如有元组s,t∈R,有s[X]=t[X](表示s与t在X的投影相等),如将它们在U一X一Y的投影(记为s[U一X一Y], t [U一X一Y],交换后所得元组称为u, v则必有u, v∈R
关于这个情况可以用表8-7表示
表8-7多值依赖示意图
X
Y
U-X-Y
s s [X]
t t [X]
s [Y]
t [Y]
s[U-X-Y]
t[U-X-Y]
s [X]
t [X]
s [Y]
t [Y]
t[U-X-Y]
s[U-X-Y]
…………
…………
…………
…………
…………
…………
对多值依赖有了充分了解后,我们可对它定义如下:
定义8-12 设R(U)中有X,Y(U,若对R(U)的任何一个关系,对X的一个确定值,存在Y的一组值与之对应,且Y的这组值又与Z=U一X一Y中的属性值不相关,此时称Y多值依赖于X,并记为X→→Y
在多值依赖中若X→→Y且Z=U一X一Y≠O,则称X→→Y为非平凡多值依赖,否则称为平凡多值依赖
多值依赖可有下面的一些性质:
(1) 在R(U)中如有X→→Y,则必有X→→U一X一Y
(2) 在R(U)中如有X→Y,则必有X→→Y
读者要注意,我们在R(U)中讨论多值依赖时并不意味着R(U)中已不需要讨论函数依赖
了,恰恰相反,我们一般不仅要在R(U)找出所有多值依赖关系来,而且还要找出所有的函数依赖关系来因此,一个完整的R(U)应该包含一个函数依赖集F'以及一个多值依赖集F',它可以用R(U, F,F')表示
前面已经讲过,具有多值依赖的关系,它们的数据冗余量特别大,如何设法减少数据冗余呢 从例8-2中的关系C中可以看出,如果将C(C, T, L)分解成两个关系C1,C2后,它们的冗余度会明显下降
C1 (C,T )
C2 (C,L )
C1,C2这两个关系可用表8-8表示
表8-8关系C分解成关系C1和C2
C
T
高等数学
高等数学
高等数学
普通物理
普通物理
普通物理
李华民
王天华
林 静
吴铁钢
谢晓芳
徐秋芳
C
L
高等数学
高等数学
普通物理
普通物理
普通物理
普通物理
高等数学
高等效学教程
物理学
普通物理
普通物理基础
(a) 关系C1 (b) 关系C2
从表8-8可以看到,数据冗余的减少是极其明显的
从多值依赖的观点看,在C1,C2中各对应一个多值依赖C→→T与C→→L,它们都是平凡多值依赖因此,在多值依赖时,减少数据冗余的方法是使关系分解成为仅有平凡多值依赖
这样,我们就可以规定一个比BCNF更高的范式,它叫第四范式,可简记为4NF这个范式的特点是,在关系模式中它必须满足:
(1) 只允许出现平凡多值依赖(不允许出现非平凡多值依赖);
(2) 函数依赖要满足BCNF
由于函数依赖是多值依赖的特例,因此统一可以用多值依赖概念定义第四范式
定义8-13 R(U)中如果X→→Y是非平凡多值依赖,则X:必含有关键字,此时称R满足第四范式,并记作R∈4NF
由这个第四范式定义可以看出,前面所定义的关系C,它虽是BCNF,但不是4NF,因为在C(C, T )中有:
C→→T
C→→L
而它的关键字是(C,T,L)
虽然C∈BCNF,但C不是关键字,所以C(4NF对它作分解后所产生的C1及C2显然因为C1(C,T)有C→→T,故不存在非平凡多值依赖,因此有C1∈4NF,同理有C2∈4NF
824 小 结
我们在规范化讨论中定义了五个范式,对这些范式的认识是逐步深入的总的说来,我们可以总结成下面几点:
(1) 规范化的目的:解决插入,修改异常以及数据冗余度高
(2) 规范化的方法:从模式中各属性间的依赖关系(函数依依赖及多值依赖)入手,尽量做到每个模式表示客观世界中的一个"事物"
(3) 规范化的实现手段:用模式分解的方法
实际上从第一范式到第四范式的过程是一个不断消除一些依赖关系中的弊病的过程图8-7给出了这个过程
读者应注意的是:规范化是一种理论,它研究如何通过规范以解决异常与冗余现象,在实际数据库设计中构作关系模式时需要考虑到这个因素但是,客观世界是复杂的,在构作模式时尚需考虑到其他的多种因素,如模式分解过多,势必在数据查询时要用到较多的联结运算,这样就会影响查询速度因此,在实际构作模式中,需要综合多种正反因素,统一权衡利弊得失,最后构做出一个较为适合实际的模式来
图8-7 规范化的过程
83 规范化所引起的一些问题
由规范化而引起了对一些问题的进一步研究,它们是:
1函数依赖理论的研究
属性间的函数依赖与多值依赖是规范化的基本依据,因此有必要对它们作进一步研究,这些研究包括:
(1)可由关系模式上的一些函数依赖通过一些公理系统(叫Armstrong公理)而获得关系模式上的所有函数依赖由此可知:一个关系模式上的所有函数依赖可由两部分组成:基础部分是直接由语义获取,其他部分可由公理系统推演而得
(2)引入了函数依赖集的等价概念与最小函数依赖集,即如果两函数依赖集能推演出相同的集来,则称它们是等价的,而等价的函数依赖集之最小者称为最小函数依赖集
这些研究为规范化提供了更多的基础信息
2模式分解的研究
规范化的实施主要依靠不断地进行模式分解在模式分解中需要研究下列问题:
(1)分解后关系中的信息是否会丢失 这叫无损联接性(lossless join)
(2)分解后关系中的函数依赖是否会丢失 这叫依赖保持性
(3)在满足无损联接性与依赖保持性下可分解到第几范式
经过研究我们可以得到下面几个事实:
若要求满足无损联接性,则模式分解一定可以达到BCNF
若要求满足依赖保持性,则模式分解一定可以达到3NF,但不一定能达到BCNF
若既要求满足无损联接性又要求满足依赖保持性,则模式分解一定可以达到
3NF,但 不一定能达到BCNF
上述三点均可通过三个算法获得实现
由于规范化所引起的这两个问题的研究的详细探讨均比较复杂,故本书中不拟详述,仅将结果陈述于上,供读者参考
习 题 8
1请给出下列术语的含义:
函数依赖;(2)关键字;(3)主属性集;(4)多值依赖;(5)2NF;(6)3NF;
(7)BCNF;(8)4NF
2在关系SC(S#, C#, G)中S#((C#正确吗 请说明其理由
3是不是规范化最佳的模式结构是最好的结构 为什么
4试证明若R(BCNF,则必有R(3NF
5试问下列关系模式最高属第几范式,并解释其原因
R (A, B, C, D),F: {B(D, AB(C};
R (A, B, C),F: {A(B, B(A, A(C};
R (A, B, C, D),F: {A(C, D(B};
R (A, B, C, D),F: {A(C, CD(B}
s
t
f
p
f
p
p
f
f
f
f
p
p
f
G
S#
C#
Sd
Ss
Sn
S#
C#
G
S#
Sd
Ss
Sn
非主属性集N
○
○
主属性集p
K1
K2
K3
K4
○
○
○
S#
c#
G
S#
Sn
Ss
Ss
Sd
S
C
T
C
T
T
S
非决定因素
决定
因素
R:
消除决定因素非关键字的非平凡多值依赖
1NF
消除非主属性对关键字的部分依赖
2NF
消除非主属性对关键字的传递依赖
3NF
消除主属性对关键字的部分与传递依赖
BCNF
消除非平凡且非函数依赖的多值依赖
4NF
数据库中能存储数据之间的联系。根据查询相关资料信息显示,数据库不仅能存储数据,而且能存储数据之间的联系。在关系数据库中,通过表与表之间所包含的公共属性实现数据之间的联系。利用这种联系能够将数据冗余度限定在最小范围之内,实现数据完整性约束和数据一致性控制。
以上就是关于在Access的下列数据类型中,不能建立索引的数据类型是______全部的内容,包括:在Access的下列数据类型中,不能建立索引的数据类型是______、关系模型不能表示实体之间多对多的关系、关系数据库中数据库,表,字段及元组的概念及相互之间的关系等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)