在线.等..关系数据库规范化理论

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

数据库课程设计

题目：小型超市管理系统

1、项目计划

11系统开发目的

（1）大大提高超市的运作效率；

（2）通过全面的信息采集和处理，辅助提高超市的决策水平；

（3）使用本系统，可以迅速提升超市的管理水平，为降低经营成本， 提高效益，增强超市扩张力， 提供有效的技术保障。

12背景说明

21世纪，超市的竞争也进入到了一个全新的领域，竞争已不再是规模的竞争，而是技术的竞争、管理的竞争、人才的竞争。技术的提升和管理的升级是超市业的竞争核心。零售领域目前呈多元发展趋势，多种业态：超市、仓储店、便利店、特许加盟店、专卖店、货仓等相互并存。如何在激烈的竞争中扩大销售额、降低经营成本、扩大经营规模，成为超市营业者努力追求的目标。

13项目确立

针对超市的特点，为了帮助超市解决现在面临的问题，提高小型超市的竞争力，我们将开发以下系统：前台POS销售系统、后台管理系统，其中这两个子系统又包含其它一些子功能。

14应用范围

本系统适应于各种小型的超市。

15 定义

（1）商品条形码：每种商品具有唯一的条形码，对于某些价格一样的商品，可以使用自定义条形码。

（2）交易清单：包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号。

（3）商品积压：在一定时期内，远无法完成销售计划的商品会造成积压。

（4）促销：在一定时期内，某些商品会按低于原价的促销价格销售。

库存告警提示：当商品的库存数量低于库存报警数量时发出提示。

（5）盘点：计算出库存、销售额、盈利等经营指标。

16 参考资料

《数据库原理及设计》 陶宏才编 清华大学出版社

《SQL Server 2000 实用教程》范立南编 清华大学出版社

《SQL Server 2000 编程员指南》李香敏编 北京希望电子出版社

《轻松搞定 SQL Server 2000 程序设计》Rebecca MRiordan编

《软件工程规范》Watts SHumphrey编 清华大学出版社

《软件工程理论与实践》 Shari Lawrence Pfleeger编 清华大学出版社

《软件需求分析》 Swapna Kishore编 机械工业出版社

《软件工程思想》 林锐编

2、逻辑分析与详细分析

21系统功能

（1）、零售前台（POS）管理系统，本系统必须具有以下功能：

 商品录入：根据超巿业务特点制定相关功能，可以通过输入唯一编号、扫描条形码、商品名称等来实现精确或模糊的商品扫描录入。该扫描录入方法可以充分保证各种电脑 *** 作水平层次的人员均能准确快速地进行商品扫描录入。

 收银业务：通过扫描条形码或者直接输入商品名称（对于同类多件商品采用一次录入加数量的方式）自动计算本次交易的总金额。在顾客付款后，自动计算找零，同时打印交易清单（包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号）。如果顾客是本店会员并持有本人会员卡，则在交易前先扫描会员卡，并对所购物品全部实行95折优惠，并将所购物品的总金额累计到该会员的总消费金额中。 会员卡的有效期限为一年，满一年未续卡者，该会员卡将被注销。

 安全性：OS登陆、退出、换班与 *** 作锁定等权限验证保护；断电自动保护最大限度防止意外及恶意非法 *** 作。

 独立作业：有的断网收银即在网络服务器断开或网络不通的情况下，收银机仍能正常作业

(2)、后台管理系统，本系统必须具备以下功能

 进货管理： 根据销售情况及库存情况，自动制定进货计划（亦可手工制定修改），可以避免盲目进货造成商品积压。 按计划单有选择性地进行自动入库登记。 综合查询打印计划进货与入库记录及金额。

 销售管理： 商品正常销售、促销与限量、限期及禁止销售控制。 综合查询各种销售明细记录、各地收银员收银记录以及交结账情况等。 按多种方式统计生成销售排行榜，灵活察看和打印商品销售日、月、年报表。

 库存管理： 综合查询库存明细记录。 库存状态自动告警提示。如库存过剩、少货、缺货等。软件为您预警，避免库存商品积压损失和缺货。 库存自动盘点计算。

 人员管理： 员工、会员、供货商、厂商等基本信息登记管理。 员工 *** 作权限管理。 客户销售权限管理。

（3）系统结构

系统总体结构

模块子系统结构

功能描述：商品录入子系统要求能快速录入商品，因此必须支持条形码扫描。

功能描述：收银业务子系统能计算交易总额，打印交易清单，并根据会员卡打折。

功能描述：进货管理子系统可以根据库存自动指定进货计划，进货时自动等级，以及提供查询和打印计划进货与入库记录的功能。

功能描述：销售管理子系统可以控制某商品是否允许销售，查询每种商品的销售情况并产生年、月、日报表，同时可以生成销售排行榜。

功能描述：库存管理子系统提供查询库存明细记录的基本功能，并根据库存的状态报警，以及自动盘点计算。

功能描述：人员管理子系统提供基本信息登记管理，员工 *** 作权限管理，客户销售权限管理的功能。

22、流程图

前台管理系统

顶层DFD图

第0层DFD图

第1层DFD图

23、户类型与职能

（1）、员工（营业员）：

 通过商品条形码扫描输入商品到购买清单

 *** 作软件计算交易总金额

 *** 作软件输出交易清单

 对会员进行会员卡扫描以便打折

（2）、：超市经理

 *** 作软件录入商品，供货商，厂商

 *** 作软件制定进货计划

 查询打印计划进货与入库记录

 *** 作软件控制商品销售与否

 查询打印销售情况

 *** 作软件生成销售排行榜

 查询库存明细记录

 根据软件发出的库存告警进行入货

 *** 作软件进行盘点计算

（3）、总经理：

 基本信息登记管理

 员工 *** 作权限管理

 客户销售权限管理

24、统开发步骤

 确定参与者和相关的用况

 为每个用况设计过程

 建立顺序图，确定每个脚本中对象的协作

 创建类，确定脚本中的对象

 设计, 编码, 测试, 集成类

 为过程编写系统测试案例

 运行测试案例，检验系统

25、系统环境需求

 系统模式

本系统采用C/S模式作为开发模式

 硬件环境

服务器端：

高性能的计算机一台，

普通的双绞线作为连接。

客户端： 普通的计算机或者工作站，

普通的双绞线作为连接。

 软件环境

服务器端：安装SQL Server 2000的服务器版本，

安装windows 2000服务器版本，

配置了诺顿等必须的防毒软件。

客户端： 安装SQL Server2000的服务器版本，

安装了VB等可视化开发工具软件，

安装windows2000服务器版本。

26、系统安全问题

信息系统尽管功能强大，技术先进，但由于受到自身体系结构，设计思路以及运行机制等限制，也隐含许多不安全因素。常见因素有：数据的输入，输出，存取与备份，源程序以及应用软件，数据库， *** 作系统等漏洞或缺陷，硬件，通信部分的漏洞，企业内部人员的因素，病毒，“黑客”等因素。因此，为使本系统能够真正安全，可靠，稳定地工作，必须考虑如下问题：为保证安全，不致使系统遭到意外事故的损害，系统因该能防止火，盗或其他形式的人为破坏。

 系统要能重建

 系统应该是可审查的

 系统应能进行有效控制，抗干扰能力强

 系统使用者的使用权限是可识别的

3、基于UML的建模

31语义规则

用例模型（use cases view）（用例视图）的基本组成部件是用例（use case）、角色(actor)和系统(system)。用例用于描述系统的功能，也就是从外部用户的角度观察，系统应支持哪些功能，帮助分析人员理解系统的行为，它是对系统功能的宏观描述，一个完整的系统中通常包含若干个用例，每个用例具体说明应完成的功能，代表系统的所有基本功能（集）。角色是与系统进行交互的外部实体，它可以是系统用户，也可以是其它系统或硬件设备，总之，凡是需要与系统交互的任何东西都可以称作角色。系统的边界线以内的区域（即用例的活动区域）则抽象表示系统能够实现的所有基本功能。在一个基本功能（集）已经实现的系统中，系统运转的大致过程是：外部角色先初始化用例，然后用例执行其所代表的功能，执行完后用例便给角色返回一些值，这个值可以是角色需要的来自系统中的任何东西。

UML：是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示；它不是一种可视化的程序设计语言而是一种可视化的建模语言；不是工具或知识库的规格说明而是一种建模语言规格说明是一种表示的标准；不是过程也不是方法但允许任何一种过程和方法使用它。

用例（use case）：

参与者（actor）：

32、UML模型

321、系统UML模型

322、子系统UML模型

（1）零售前台（POS）管理系统用例视图

（2）后台管理系统用例视图

33、系统实现图

4、超市销售系统概念设计文档

（1）、系统ER图

（2）、系统ER图说明

1) 商店中的所有用户（员工）可以销售多种商品，每种商品可由不同用户（员工）销售；

2) 每个顾客可以购买多种商品，不同商品可由不同顾客购买；

3) 每个供货商可以供应多种不同商品，每种商品可由多个供应商供应。

（3）、视图设计

1) 交易视图(v_Dealing)——用于查询交易情况的视图；

2) 计划进货视图(v_PlanStock)——用于查询进货计划的视图；

3) 销售视图(v_Sale)——用于查询销售明细记录的视图；

4) 入库视图(v_Stock)——用于查询入库情况的视图。

5、逻辑设计文档

（1）、系统关系模型

a) 商品信息表（商品编号，商品名称，价格，条形码，促销价格，促销起日期，促销止日期，允许打折，库存数量，库存报警数量，计划进货数，允许销售，厂商编号，供货商编号）

b) 用户表（用户编号，用户名称，用户密码，用户类型）

c) 会员表（会员编号，会员卡号，累积消费金额，注册日期）

d) 销售表（销售编号，商品编号，销售数量，销售金额，销售日期）

e) 交易表（交易编号，用户名称，交易金额，会员卡号，交易日期）

f) 进货入库表（入库编号，入库商品编号，入库数量，单额，总额，入库日期，计划进货日期，入库状态）

g) 供货商表（供货商编号，供货商名称，供货商地址，供货商电话）

h) 厂商表（厂商编号，厂商名称，厂商地址，厂商电话）

（2）、系统数据库表结构

数据库表索引

表名 中文名

MerchInfo 商品信息表

User 用户表

Menber 会员表

Sale 销售表

Dealing 交易表

Stock 进货入库表

Provide 供货商表

Factory 厂商表

商品信息表(MerchInfo)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

MerchID int 4 P Not null 商品编号

MerchName Varchar 50 Not null 商品名称

MerchPrice Money 4 Not null 价格

MerchNum Int 4 Not null 库存数量

CautionNum Int 4 Not null 库存报警数量

PlanNum Int 4 null 计划进货数

BarCode Varchar 50 Not null 条形码

SalesProPrice Money 4 促销价格

SalesProDateS Datetime 8 促销起日期

SalesProDateE Datetime 8 促销止日期

AllowAbate Int 4 Not null 允许打折

AllowSale Int 4 Not null 允许销售

FactoryID Varchar 10 F Not null 厂商编号

ProvideID Varchar 10 F Not null 供货商编号

用户表(User)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

UserID varchar 10 P Not null 用户编号

UserName Varchar 25 Not null 用户名称

UserPW Varchar 50 Not null 用户密码

UserStyle Int 4 Not null 用户类型

会员表(Menber)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

MemberID Varchar 10 P Not null 会员编号

MemberCard Varchar 20 Not null 会员卡号

TotalCost Money 4 Not null 累积消费金额

RegDate Datetime 8 Not null 注册日期

销售表(Sale)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

SaleID Varchar 10 P Not null 销售编号

MerChID Varchar 10 F Not null 商品编号

SaleDate Datetime 8 Not null 销售日期

SaleNum Int 4 Not null 销售数量

SalePrice Money 4 Not null 销售单额

交易表(Dealing)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

DealingID Varchar 10 P Not null 交易编号

DealingPrice Money 4 Not null 交易金额

DealingDate Money 4 Not null 交易日期

MemberID Varchar 10 会员卡号

UserName Varchar 10 F Not null 用户名称

入库纪录表(Stock)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

StockID Varchar 10 P Not null 入库编号

MerchID Varchar 10 F Not null 入库商品编号

MerchNum Int 4 Not null 入库数量

MerchPrice Money 4 Not null 单额

TotalPrice Money 4 Not null 总额

StockDate Datetime 8 Datetime 入库日期

PlanDate Datetime 8 Datetime 计划进货日期

StockState Int 4 Not null 入库状态

供货商表(Provide)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

ProvideID varchar 10 P Not null 供货商编号

ProvideName Varchar 50 Not null 供货商名称

ProvideAddress Varchar 250 供货商地址

ProvidePhone Varchar 25 供货商电话

厂商表(Provide)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

FactoryID varchar 10 P Not null 厂商编号

FactoryName Varchar 50 Not null 厂商名称

FactoryAddress Varchar 250 厂商地址

FactoryPhone Varchar 25 厂商电话

6、物理设计文档

/----------创建数据库----------/

create database SuperMarketdb

on primary

(

name=SuperMarketdb,

filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdbmdf',

size=100MB,

maxsize=200MB,

filegrowth=20MB

)

log on

(

name=SuperMarketlog,

filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdbldf',

size=60MB,

maxsize=200MB,

filegrowth=20MB

)

go

/----------创建基本表----------/

use [SuperMarketdb]

go

/创建交易表/

CREATE TABLE Dealing (

DealingID int identity(1,1) Primary key ,

DealingDate datetime NOT NULL ,

DealingPrice money NOT NULL ,

UserName varchar(25) NULL ,

MemberCard varchar(20) NULL

)

GO

/创建厂商表/

CREATE TABLE Factory (

FactoryID varchar(10) Primary key ,

FactoryName varchar(50) NOT NULL ,

FactoryAddress varchar(250) NULL ,

FactoryPhone varchar(50) NULL

)

GO

/创建会员表/

CREATE TABLE Member (

MemberID varchar(10) Primary key ,

MemberCard varchar(20) NOT NULL ,

TotalCost money NOT NULL ,

RegDate datetime NOT NULL

)

GO

/创建商品信息表/

CREATE TABLE MerchInfo (

MerchID int identity(1,1) Primary key ,

MerchName varchar(50) Unique NOT NULL ,

MerchPrice money NOT NULL ,

MerchNum int NOT NULL ,

CautionNum int NOT NULL ,

PlanNum int NOT NULL ,

BarCode varchar(20) Unique NOT NULL ,

SalesProPrice money NULL ,

SalesProDateS datetime NULL ,

SalesProDateE datetime NULL ,

AllowAbate int NOT NULL ,

AllowSale int NOT NULL ,

FactoryID int NOT NULL ,

ProvideID int NOT NULL

)

GO

/创建供应商表/

CREATE TABLE Provide (

ProvideID varchar(10) Primary key ,

ProvideName varchar(50) NOT NULL ,

ProvideAddress varchar(250) NULL ,

ProvidePhone varchar(25) NULL

)

GO

/创建销售表/

CREATE TABLE Sale (

SaleID int identity(1,1) Primary key ,

MerChID int NOT NULL ,

SaleDate datetime NOT NULL ,

SaleNum int NOT NULL,

SalePrice money NOT NULL

)

GO

/创建入库表/

CREATE TABLE Stock (

StockID int identity(1,1) Primary key ,

MerchID int NOT NULL ,

MerchNum int NOT NULL ,

MerchPrice money NULL ,

TotalPrice money NULL ,

PlanDate datetime NULL ,

StockDate datetime NULL,

StockState int NOT NULL

)

GO

/创建用户表/

CREATE TABLE User (

UserID varchar(10) Primary key ,

UserName varchar(25) NOT NULL ,

UserPW varchar(50) NOT NULL ,

UserStyle int NOT NULL ,

)

GO

/----------创建表间约束----------/

/商品信息表中厂商编号、供应商编号分别与厂商表、供应商表之间的外键约束/

ALTER TABLE MerchInfo ADD

CONSTRAINT [FK_MerchInfo_Factory] FOREIGN KEY

(

[FactoryID]

) REFERENCES Factory (

[FactoryID]

),

CONSTRAINT [FK_MerchInfo_Provide] FOREIGN KEY

(

[ProvideID]

) REFERENCES Provide (

[ProvideID]

)

GO

/销售表中商品编号与商品信息表之间的外键约束/

ALTER TABLE Sale ADD

CONSTRAINT [FK_Sale_MerchInfo] FOREIGN KEY

(

[MerChID]

) REFERENCES MerchInfo (

[MerchID]

) ON DELETE CASCADE

GO

/入库表中商品编号与商品信息表之间的外键约束/

ALTER TABLE Stock ADD

CONSTRAINT [FK_Stock_MerchInfo] FOREIGN KEY

(

[MerchID]

) REFERENCES MerchInfo (

[MerchID]

) ON DELETE CASCADE

GO

/----------创建索引----------/

/在交易表上建立一个以交易编号、交易日期为索引项的非聚集索引/

CREATE nonclustered INDEX IX_Dealing ON Dealing(DealingID, DealingDate)

GO

/在商品信息表上建立一个以商品编号为索引项的非聚集索引/

CREATE nonclustered INDEX IX_MerchInfo ON MerchInfo(MerchID)

GO

/在销售表上建立一个以销售编号、销售日期为索引项的非聚集索引/

CREATE nonclustered INDEX IX_Sale ON Sale(SaleID, SaleDate)

GO

/在入库表上建立一个以入库编号、入库日期、商品编号为索引项的非聚集索引/

CREATE nonclustered INDEX IX_Stock ON Stock(StockID, StockDate, MerchID)

GO

/----------创建视图----------/

/创建用于查询交易情况的视图/

CREATE VIEW v_Dealing

AS

SELECT DealingDate as 交易日期,

UserName as 员工名称,

MemberCard as 会员卡号,

DealingPrice as 交易金额

FROM Dealing

GO

/创建用于查询进货计划的视图/

CREATE VIEW v_PlanStock

AS

SELECT StockStockID as SID,

MerchInfoMerchName as 商品名称,

MerchInfoBarCode as 条形码,

FactoryFactoryName as 厂商,

ProvideProvideName as 供货商,

StockMerchNum as 计划进货数量,

StockPlanDate as 计划进货日期

FROM Stock,MerchInfo,Provide,Factory

Where StockMerchID = MerchInfoMerchID

and ProvideProvideID=MerchInfoProvideID

and FactoryFactoryID=MerchInfoFactoryID

and StockStockState=0

GO

/创建用于查询销售明细记录的视图/

CREATE VIEW v_Sale

AS

SELECT MerchInfoMerchName as 商品名称,

MerchInfoBarCode as 条形码,

MerchInfoMerchPrice as 商品价格,

SaleSalePrice as 销售价格,

SaleSaleNum as 销售数量,

SaleSaleDate as 销售日期

FROM Sale INNER JOIN

MerchInfo ON SaleMerChID = MerchInfoMerchID

GO

/创建用于查询入库情况的视图/

CREATE VIEW v_Stock

AS

SELECT MerchInfoMerchName as 商品名称,

MerchInfoBarCode as 条形码,

FactoryFactoryName as 厂商,

ProvideProvideName as 供货商,

StockMerchPrice as 入库价格,

StockMerchNum as 入库数量,

StockTotalPrice as 入库总额,

StockStockDate as 入库日期

FROM Stock,MerchInfo,Provide,Factory

Where StockMerchID = MerchInfoMerchID

and ProvideProvideID=MerchInfoProvideID

and FactoryFactoryID=MerchInfoFactoryID

and StockStockState=1

GO

7、小结

和传统管理模式相比较，使用本系统，毫无疑问会大大提高超市的运作效率，辅助提高超市的决策水平，管理水平，为降低经营成本， 提高效益，减少差错，节省人力，减少顾客购物时间，增加客流量，提高顾客满意度，增强超市扩张能力， 提供有效的技术保障。

由于开发者能力有限，加上时间仓促，本系统难免会出现一些不足之处，例如：

 本系统只适合小型超市使用，不能适合中大型超市使用；

 超市管理系统涉及范围宽，要解决的问题多，功能复杂，实现困难，但由于限于时间，本系统只能做出其中的一部分功能；

对于以上出现的问题，我们深表歉意，如发现还有其它问题，希望老师批评指正。

请采纳。

一个关系数据库模式由一组关系模式组成，一个关系模式由一组属性名组成。关系数据库设计，就是如何把已给定的相互关联的一组属性名分组，并把每一组属性名组成关系的问题。然而，属性的分组不是唯一的，不同的分组对应着不同的数据库应用系统，它们的效率往往相差很远。

为了使数据库设计合理可靠，简单实用，长期以来，形成了关系数据库设计的理论——规范化理论。

61 关系规范化的作用

规范化，就是用形式更为简洁，结构更加规范的关系模式取代原有关系模式的过程。

如果将两个或两个以上实体的数据存放在一个表里，就会出现下列三个问题：

Ø 数据冗余度大

Ø 插入异常

Ø 删除异常

所谓数据冗余，就是相同数据在数据库中多次重复存放的现象。数据冗余不仅会浪费存储空间，而且可能造成数据的不一致性。

插入异常是指，当在不规范的数据表中插入数据时，由于实体完整性约束要求主码不能为空的限制，而使有用数据无法插入的情况。

删除异常是指，当不规范的数据表中某条需要删除的元组中包含有一部分有用数据时，就会出现删除困难。

（以P98工资表为例）

解决上述三个问题的方法，就是将不规范的关系分解成为多个关系，使得每个关系中只包含一个实体的数据。

（讲例子解）

当然，改进后的关系模式也存在另一问题，当查询职工工资时需要将两个关系连接后方能查询，而关系连接的代价也是很大的。

那么，什么样的关系需要分解？分解关系模式的理论依据又是什么？分解完后能否完全消除上述三个问题？回答这些问题需要理论指导。下面，将加以讨论：

62 函数依赖

621属性间关系

实体间的联系有两类：一类是实体与实体之间联系；另一类是实体内部各属性间的联系。数据库建模一章中讨论的是前一类，在这里我们将学习第二类。

和第一类一样，实体内部各属性间的联系也分为1:1、1:n和m:n三类：

例：职工（职工号，姓名，身份z号码，职称，部门）

1、 一对一关系（1:1）

设X、Y是关系R的两个属性（集）。如果对于X中的任一具体值，Y中至多有一个值与之对应，反之，对于Y中的任一具体值，X中也至多有一个值与之对应，则称X、Y两属性间是一对一关系。

如本例职工关系中职工号与身份z号码之间就是一对一关系。

2、一对多关系（1:n）

设X、Y是关系R的两个属性（集）。如果对于X中的任一具体值，Y中可以找到多个值与之对应，而对于Y中的任一具体值，X中至多只有一个值与之对应，则称属性X对Y是一对多关系。

如职工关系中职工号与职称之间就是一对多的关系。

3、多对多关系（m:n）

设X、Y是关系R的两个属性（集）。如果对于X中的任一具体值，Y中有n个值与之对应，而对于Y中的任一具体值，X中也有m个值与之对应，则称属性X对Y是一对多（m:n）关系。

例如，职工关系中，职称与部门之间就是多对多的关系。

上述属性间的三种关系，实际上是属性值之间相互依赖与相互制约的反映，因而称之为属性间的数据依赖。

数据依赖共有三种：

Ø 函数依赖（Functional Dependency，FD）

Ø 多值依赖（Multivalued Dependency，MVD）

Ø 连接依赖（Join Dependency，JD）

其中最重要的是函数依赖和多值依赖。

622 函数依赖

函数依赖，是属性之间的一种联系。在关系R中，X、Y为R的两个属性或属性组，如果对于R的所有关系r 都存在：对于X的每一个具体值，Y都只有一个具体值与之对应，则称属性Y函数依赖于属性X。或者说，属性X函数决定属性Y，记作X→Y。其中X叫作决定因素，Y叫作被决定因素。

上述定义，可简言之：如果属性X的值决定属性Y的值，那么属性Y函数依赖于属性X。换一种说法：如果知道X的值，就可以获得Y的值，则可以说X决定Y。

若Y函数不依赖于X，记作：X→Y。

X Y

若X→Y，Y→X，记作：

前面学习的属性间的三种关系，并不是每种关系中都存在着函数依赖。

u 如果X、Y间是1:1关系，则存在函数依赖 X←→Y

u 如果X、Y间是1:n关系，则存在函数依赖： X→Y或Y→X（多方为决定因素）

u 如果X、Y间是m:n关系，则不存在函数依赖。

注意，属性间的函数依赖不是指R的某个或某些关系子集满足上述限定条件，而是指R的一切关系子集都要满足定义中的限定。只要有一个具体的关系r（R的一个关系子集）不满足定义中的条件，就破坏了函数依赖，使函数依赖不成立。

这里的关系子集，指的是R的某一部分元组的集合，例如：地测学院的学生关系中只包含了地测学院学生的数据，所以它是长安大学学生关系的一个子集。

623 码的定义

前面，我们对码进行了直观化的定义，下面用函数依赖的概念对码作出较为精确的形式化的定义：

设K是关系模式R（U，F）中的属性或属性组，K’是K的任一子集。若K→U，而不存在K’→U，则K为R的候选码（Candidate Key）

Ø 若候选码多于一个，则选其中的一个为主码（Primary Key）；

Ø 包含在任一候选码中的属性，叫做主属性（Primary Attribute）；

Ø 不包含在任何码中的属性称为非主属性（Nonprime Attribute）或非码属性（Nonkey Attribute）

Ø 关系模式中，最简单的情况是单个属性是码，称为单码（Single Key）；最极端的情况是整个属性组是码，称为全码（All－Key）。

前面已多次遇到单码的情况，下面是一个全码的例子：

签约（演员名，制片公司，**名）

外码：设有两个关系R和S，X是R的属性或属性组，并且X不是R的码，但X是S的码（或与S的码意义相同），则称X是R的外部码（Foreign Key），简称外码或外键。

如：职工（职工号，姓名，性别，职称，部门号）

部门（部门号，部门名，电话，负责人）

其中职工关系中的“部门号”就是职工关系的一个外码。

在此需要注意，在定义中说X不是R的码，并不是说X不是R的主属性，X不是码，但可以是码的组成属性，或者是任一候选码中的一个主属性。

如：学生（学生号，姓名，性别，年龄…）

课程（课程号，课程名，任课老师…）

选课（学生号，课程号，成绩）

在选课关系中，（学生号，课程号）是该关系的码，学生号、课程号又分别是组成主码的属性（但单独不是码），它们分别是学生关系和课程关系的主码，所以是选课关系的两个外码。

关系间的联系，可以通过同时存在于两个或多个关系中的主码和外码的取值来建立。如要查询某个职工所在部门的情况，只需查询部门表中的部门号与该职工部门号相同的记录即可。所以，主码和外码提供了一个表示关系间联系的途径。

624 函数依赖和码的唯一性

由上述码的形式化定义，我们可以说：码是由一个或多个属性组成的，可唯一标识元组的最小属性组。

码在关系中总是唯一的，即一个码函数唯一地决定一行。如果码的值重复，则整个元组都会重复。否则，违反了实体完整性规则。而元组的重复则表示存在两个完全相同的实体，这显然是不可能的，所以码是不允许重复取值的。

所以，只有当某个属性或属性组能够函数决定关系中的每一个其它的属性，且该属性组的任何一个真子集都做不到这一点时，该属性或属性组才是该关系的码。

函数依赖是一个与数据有关的事物规则的概念。如果属性B函数依赖于属性A，那么若知道了A的值，则完全可以找到B的值。这并非是可以由A的值计算出B的值，而是逻辑上只能存在一个B的值。

63 关系模式的规范化

一、非规范化的关系

当一个表中存在还可以再分的数据项时，这个表就是非规范化的表。非规范化表存在两种情况：

Ø 表中具有组合数据项（P102表6-4）

Ø 表中具有多值数据项（P103表6-5）

例：

职工号

姓名

工资

基本工资

职务工资

工龄工资

1002

张三

1000

800

200

职工号

姓名

职称

系名

系办地址

学历

毕业年份

001

张三

教授

计算机

1305

大学

研究生

1963

1982

那么什么是规范化关系呢？

当一个关系中的所有分量都是不可再分的数据项时，该关系是规范化的。即当表中不存在组合数据项和多值数据项，只存在不可分的数据项时，这个表是规范化的。

二维表按其规范化程度从低到高可分为5级范式（Normal Form），分别称为1NF、2NF、3NF（BCNF）、4NF、5NF。规范化程度较高者必是较低者的子集，即：

1NF 2NF 3NF BCNF 4NF 5NF

二、第一范式（1NF）

定义1：如果关系模式R中不包含多值属性，则R满足第一范式（First Normal Form），记作：

R∈1NF

1NF是对关系的最低要求，不满足1NF的关系是非规范化的关系。

非规范化关系转化为规范化关系1NF方法很简单，只要上表分别从横向、纵向展开即可。如下表：

职工号

姓名

基本工资

职务工资

工龄工资

1002

张三

1000

800

200

1005

李四

1200

900

150

职工号

姓名

职称

系名

系办地址

学历

毕业年份

1002

张三

教授

计算机

1305

大学

1963

1002

张三

教授

计算机

1305

研究生

1982

1005

李四

讲师

信电

2206

大学

1989

上表虽然符合1NF，但仍是有问题的关系，表中存在大量的数据冗余和潜在的数据更新异常。原因是（职工号，学历）是右表的码，但姓名、职称、系名、系办地址却与学历无关，只与码的一部分有关。所以上表还需进一步地规范化。

三、第二范式（2NF）

定义1：设X、Y是关系R的两个不同的属性或属性组，且X → Y。如果存在X的某一个真子集X’，使X’ → Y成立，则称Y部分函数依赖于X，记作：X P→ Y（Partial）。反之，则称Y完全函数依赖于X，记作：X F→ Y （Full）

定义2：如果一个关系 R∈1NF，且它的所有非主属性都完全函数依赖于R的任一候选码，则R属于第二范式，记作：R∈2NF。

说明：上述定义中所谓的候选码也包括主码，因为码首先应是候选码，才可以被指定为码。

例如关系模式：

职工（职工号，姓名，职称，项目号，项目名称，项目角色）中

（职工号，项目号）是该关系的码，而职工号→姓名、职工号→职称、项目号→项目名称…

所以（职工号，项目号）P→ 职称、（职工号，项目号）P→ 项目名称

故上述职工关系不符合第二范式要求。它存在三个问题：插入异常、删除异常和修改异常。

其中修改异常是这样的，当职工关系中项目名称发生变化时，由于参与该项目的人员很多，每人一条记录，要修改项目信息，就得对每一个参加该项目的人员信息进行修改，加大了工作量，还有可能发生遗漏，存在着数据一致性被破坏的可能。

可把上述职工关系分解成如下三个关系：

职工（职工号，姓名，职称）

参与项目（职工号，项目号，项目角色）

项目（项目号，项目名称）

上述三个关系都符合定义2的要求，所以都符合2NF

推论：如果关系模式R∈1NF，且它的每一个候选码都是单码，则R∈2NF

符合第二范式的关系模式仍可能存在数据冗余、更新异常等问题。如关系

职工信息（职工号，姓名，职称，系名，系办地址）

虽然也符合2NF，但当某个系中有100名职工时，元组中的系办地址就要重复100次，存在着较高的数据冗余。原因是关系中，系办地址不是直接函数依赖于职工号，而是因为职工号函数决定系名，而系名函数决定系办地址，才使得系办地址函数依赖于职工号，这种依赖是一个传递依赖的过程。

所以，上述职工信息的关系模式还需要进一步的规范化。

四、第三范式（3NF）

定义1：在关系R中，X、Y、Z是R的三个不同的属性或属性组，如果X→Y，Y→Z， 但Y→X，且Y不是X的子集，则称Z传递函数依赖于X。

定义2：如果关系模式R∈2NF，且它的每一个非主属性都不传递依赖于任何候选码，则称R是第三范式，记作：R∈3NF

推论1：如果关系模式R∈1NF，且它的每一个非主属性既不部分依赖、也不传递依赖于任何候选码，则R∈3NF

推论2：不存非主属性的关系模式一定为3NF

五、改进的3NF——BCNF（Boyee－Codd Normal Form）

定义：设关系模式R（U，F）∈1NF，若F的任一函数依赖X→Y（Y X）中X都包含了R的一个码，则称R∈BCNF。

换言之，在关系模式R中，如果每一个函数依赖的决定因素都包含码，则R∈BCNF

推论：如果R∈BCNF，则：

Ø R中所有非主属性对每一个码都是完全函数依赖；

Ø R中所有主属性对每一个不包含它的码，都是完全函数依赖；

Ø R中没有任何属性完全函数依赖于非码的任何一组属性。

定理：如果R∈BCNF，则R∈3NF一定成立。

证明：（结合传递依赖的定义，用反证法）

注意：当R∈3NF时，R未必属于BCNF。因为3NF比BCNF放宽了一个限制，它允许决定因素不包含码。例如：

通讯（城市名，街道名，邮政编码）中：

F＝｛（城市名，街道名）→邮政编码，邮政编码→城市名｝

非主属性邮政编码完全函数依赖于码，且无传递依赖，故属于3NF，但邮政编码也是一个决定因素，而且它没有包含码，所以该关系不属于BCNF。

又如：

Teaching（Student，Teacher，Course） 简记为Teaching（S，T，C）

规定：一个教师只能教一门课，每门课程可由多个教师讲授；学生一旦选定某门课程，教师就相应地固定。

F＝｛T→C，（S，C）→T,(S，T) →C｝

该关系的候选码是（S，C）和（S，T），因此，三个属性都是主属性，由于不存在非主属性，该关系一定是3NF。但由于决定因素T没包含码，故它不是BCNF。

关系模式Teaching仍然存在着数据冗余问题，因为存在着主属性对码的部分函数依赖问题。

确切地表示：F＝｛T→C，（S，C）P→T,(S，T) P→C｝

所以Teaching关系可以分解为以下两个BCNF关系模式：

Teacher（Teacher，Course） Student（Student，Teacher）

3NF的“不彻底”性，表现在可能存在主属性对码的部分依赖和传递依赖。

一个关系模式如果达到了BCNF，那么，在函数依赖范围内，它就已经实现了彻底的分离，消除了数据冗余、插入和删除异常。

64 多值依赖和第四范式

一、多值依赖（Multivalued Dependency）

课程C

教员T

参考书B

物理

李勇

普通物理学

物理

李勇

光学原理

物理

李勇

物理习题集

物理

王军

普通物理学

物理

王军

光学原理

物理

王军

物理习题集

数学

李勇

数学分析

数学

李勇

微分方程

数学

李勇

高等代数

数学

张平

数学分析

数学

张平

微分方程

数学

张平

高等代数

计算数学

张平

数学分析

计算数学

张平

计算数学

计算数学

周峰

数学分析

计算数学

周峰

计算数学

课程C

教员T

参考书B

物理

李勇

王军

普通物理学

光学原理

物理习题集

数学

李勇

张平

数学分析

微分方程

高等代数

计算数学

张平

周峰

数学分析

计算数学

例：学校中某一门课程由多个教员讲授，他们使用相同的一套参考书，每个教员可以讲授多门课程，每种参考书可以供多门课程使用。下列是用一个非规范化的表来表示教员T，课程C和参考书B之间的关系。

把上表变换成一张规范化的二维表Teaching，如右表

关系模式Teaching（C，T，B）的码是（C，T，B），即All－Key。因而Teaching∈BCNF。按照上述语义规定，当某门课程增加一名讲课教员时，就要向Teaching表中增加与相应参考书等数目的元组。同样，某门课程要去掉一本参考书时，则必须删除相应数目的元组。

对数据的增、删、改很不方便，数据的冗余也十分明显。如果仔细考察这类关系模式，会发现它具有一种称之为多值依赖的数据依赖关系。

定义：设R（U）是属性集U上的一个关系模式，X，Y，Z是U的子集，且Z＝U-X-Y。如果对R（U）的任一关系r，给定一对（x，z）值，都有一组y值与之对应，这组y值仅仅决定于x值而与z值无关。则称Y多值依赖于X，或X多值决定Y，记作：X→→Y。――

例如，在关系模式Teaching中，对于一个（C，B）值（物理，普通物理学），有一组T值｛李勇，王军｝，而这组值仅仅决定于课程C上的值（物理）。即对于另一个（物理，光学原理），它对应的T值仍然是｛李勇，王军｝，所以T的值与B的值无关，仅决定于C的值，即C→→T 。

多值依赖的另一个等价的形式化定义为：

设关系模式R（U），X、Y、Z是U的子集，Z＝U-X-Y，r是R的任意一个关系，t1、t2是r的任意两个元组。如果t1[X]=t2[X]，并在r中存在两个元组t3、t4，使得：

t3[X]=t4[X]=t1[X]

t3[Y]=t1[Y]，t3[Z]=t2[Z]，

t4[Y]=t2[Y]，t4[Z]=t1[Z]

成立，则X→→Y。

换句话说：如果X→→Y在R（U）中成立，则只要在R的任一关系r中存在两个元组t1、t2在X属性上的值相等，则交换这两个元组在Y（或Z）上的值后得到的两个新元组t3、t4也必是关系r中的元组。

定义中如果Z＝Ф（空集），则称X→→Y为平凡的多值依赖，否则为非平凡的多值依赖。

多值依赖具有如下性质：

1 对称性：若X→→Y，则X→→Z，其中Z＝U-X-Y

2 传递性：若X→→Y，Y→→Z，则X→→Z-Y

3 若X→→Y，X→→Z，则X→→YZ

4 若X→→Y，X→→Z，则X→→Y∩Z

5 若X→→Y，X→→Z，则X→→Y-Z，X→→Z-Y

多值依赖与函数依赖相比，具有下面两个基本区别：

（1）多值依赖的有效性与属性集的范围有关

若X→→Y在U上成立，则在V（XY V U）上一定成立；反之则不然，即X→→Y在V(V U)上成立，在U上并不一定成立。这是因为多值依赖的定义中不仅涉及属性组X、Y，而且涉及U中的其余属性Z（Z＝U-X-Y）。

一般地说，在R（U）上若有X→→Y在V（V U）上成立，则称X→→Y为R（U）的嵌入型多值依赖。

而在关系模式R（U）中函数依赖X→Y的有效性，仅决定于X和Y这两个属性集的值。只要在R（U）的任何一个关系r中，元组在X和Y上的值使得X→Y成立，则X→Y在任何属性集V（XY V U）上也成立。

（2）若函数依赖X→Y在R（U）上成立，则对于任何Y’ Y 均有X→Y’ 成立。而多值依赖X→→Y若在R（U）上成立，却不能断言对于任何Y’ Y有X→→Y’ 成立。

多值依赖的约束规则：在具有多值依赖的关系中，如果随便删去一个元组，就会破坏其对称性，那么，为了保持多值依赖关系中的“多值依赖”性，就必须删去另外的相关元组以维持其对称性。这就是多值依赖的约束规则。目前的RDBMS尚不具有维护这种约束的能力，需要程序员在编程中实现。

函数依赖可看成是多值依赖的特例，即函数依赖一定是多值依赖。而多值依赖则不一定就有函数依赖。

二、第四范式（4NF）

定义：如果关系模式R∈1NF，对于R的每个非平凡的多值依赖X→→Y（Y X），X含有码，则称R是第四范式，即R∈4NF

课程C

教员T

参考书B

物理

李勇

普通物理学

物理

李勇

光学原理

物理

李勇

物理习题集

物理

王军

普通物理学

物理

王军

光学原理

物理

王军

物理习题集

数学

李勇

数学分析

数学

李勇

微分方程

数学

李勇

高等代数

数学

张平

数学分析

数学

张平

微分方程

数学

张平

高等代数

计算数学

张平

数学分析

计算数学

张平

计算数学

计算数学

周峰

数学分析

计算数学

周峰

计算数学

Teaching关系

关系模式R∈4NF时，R中所有的非平凡多值依赖实际上就是函数依赖。因为每一个决定因素中都含有码，所以R一定属于BCNF。

4NF实际上就是限制关系模式的属性间不允许有非平凡，而且非函数依赖的多值依赖存在。反过来说，4NF所允许的非平凡多值依赖实际上是函数依赖。

例题中的Teaching关系属于BCNF，但它不属于4NF。因为它的码是（C，T，B），关系中存在非平凡多值依赖C→→T ，C→→B，但C不包含码，而只是码的一部分。

课程C

参考书B

物理

普通物理学

物理

光学原理

物理

物理习题集

数学

数学分析

数学

微分方程

数学

高等代数

计算数学

数学分析

计算数学

计算数学

CB关系

课程C

教员T

物理

李勇

物理

王军

数学

李勇

数学

张平

计算数学

张平

计算数学

周峰

CT关系

要使Teaching关系符合4NF，必须将其分解为CT（C，T）和CB（C，B）两个关系模式。如右表：

从表中显而易见，符合BCNF的关系Teaching仍然存在着数据冗余，而分解后的关系CT和CB中只有平凡多值依赖，所以符合4NF，它们已经消除了数据冗余。可以说：BCNF是在只有函数依赖的关系模式中，规范化程度最高的范式，而4NF是在有多值依赖的关系模式中，规范化程度最高的范式。

如果关系模式中存在连接依赖，即便它符合4NF，仍有可能遇到数据冗余及更新异常等问题。所以对于达到4NF的关系模式，还需要消除其中可能存在的连接依赖，才可以进一步达到5NF的关系模式。

关于连接依赖和5NF的内容，已超出了本课程教学大纲的要求，在此不再介绍。

解答如下：完整性有三类：实体完整性，参照完整性，用户定义完整性。(1)实体完整性：规定基本关系R的主属性A不能取空值，如：Create Table 学生( 学号CHAR(10) PRIMARY KEY, 姓名 CHAR(20), );(2)参照完整性：规定若F是基本关系的外码，它与基本关系S的住吗相对应，则对于R中每一个远足在F上的值必须取空值（F的每一个属性值均为空值），或等于S中某一个远足的主码值。如：Create Table 学生( 学号 CHAR(10) PRIMARY KEY, 姓名 CHAR(20), 课程号 CHAR(10), FOREIGN KEY(课程号)REFERENCES 课程(课程号) );Create 课程( 课程号 CHAR(10) PRIMATY KEY, );(3)用户定义完整性：就是针对某一具体的关系数据库的约束条件，反映某一具体应用所涉及的数据必须满足的语义要求，由应用环境决定，即属性值限定，包括：列值非空(NOT NULL), 列值唯一(UNIQUE),检查列值是否满足一个布尔表达式。如：Create Table 学生_课程( 学号 CHAR(10) NOT NULL, 课程号 CHAR(10) NOTNULL, 成绩 SMALLINT NOT NULL, PRIMARY KEY(学号，课程号)， );

例如关系模式test(课程,参考书),课程->->参考书，即参考书多值依赖于课程，例如课程物理可以有参考书普通物理学或光学物理等。

这种依赖是属于平凡的多值依赖。

2NF消除了非主属性对码的部分函数依赖；

3NF消除非主属性对码的传递函数依赖；

BCNF消除主属性对码的部分和传递函数依赖；

4NF消除非平凡且非函数依赖的多值依赖。

上面的关系模式test主码是（课程、参考书），是一个全码；

没有非主属性，属于2NF和3NF；

除了码本身没有其它主属性，属于BCNF；

没有非平凡且非函数依赖的多值函数依赖，只有一个平凡的多子函数依赖，所以属于4NF。

1、第一范式（1NF）

所谓第一范式（1NF）是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。

即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。

说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。

不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。

2、第二范式（2NF）

在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。

第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。

例如在员工表中的身份z号码即可实现每个一员工的区分，该身份z号码即为候选键，任何一个候选键都可以被选作主键。

在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份z号进行存储，而姓名可能会在数据库运行的某个时间重复。

无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。（该主键的添加是在ER设计时添加，不是建库时随意添加）

第二范式（2NF）要求实体的属性完全依赖于主关键字。

所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。

3、第三范式（3NF）

在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）

第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。

简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。

那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。

如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。

简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。

扩展资料

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。

满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。

以上就是关于在线.等..关系数据库规范化理论全部的内容，包括:在线.等..关系数据库规范化理论、数据库课程设计实例、关系数据库规范化理论的基础和内容等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！