MySQL如何实现高可用？

1. 概述

我们在考虑MySQL数据库的高可用的架构时，主要要考虑如下几方面：

关于对高可用的分级在这里我们不做详细的讨论，这里只讨论常用高可用方案的优缺点以及高可用方案的选型。

2. 高可用方案

2.1. 主从或主主半同步复制

使用双节点数据库，搭建单向或者双向的半同步复制。在5.7以后的版本中，由于lossless replication、logical多线程复制等一些列新特性的引入，使得MySQL原生半同步复制更加可靠。

常见架构如下：

通常会和proxy、keepalived等第三方软件同时使用，即可以用来监控数据库的 健康 ，又可以执行一系列管理命令。如果主库发生故障，切换到备库后仍然可以继续使用数据库。

优点：

缺点：

2.2. 半同步复制优化

半同步复制机制是可靠的。如果半同步复制一直是生效的，那么便可以认为数据是一致的。但是由于网络波动等一些客观原因，导致半同步复制发生超时而切换为异步复制，那么这时便不能保证数据的一致性。所以尽可能的保证半同步复制，便可提高数据的一致性。

该方案同样使用双节点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。

可参考的优化方案如下：

半同步复制由于发生超时后，复制断开，当再次建立起复制时，同时建立两条通道，其中一条半同步复制通道从当前位置开始复制，保证从机知道当前主机执行的进度。另外一条异步复制通道开始追补从机落后的数据。当异步复制通道追赶到半同步复制的起始位置时，恢复半同步复制。

搭建两条半同步复制通道，其中连接文件服务器的半同步通道正常情况下不启用，当主从的半同步复制发生网络问题退化后，启动与文件服务器的半同步复制通道。当主从半同步复制恢复后，关闭与文件服务器的半同步复制通道。

优点：

缺点：

2.3. 高可用架构优化

将双节点数据库扩展到多节点数据库，或者多节点数据库集群。可以根据自己的需要选择一主两从、一主多从或者多主多从的集群。

由于半同步复制，存在接收到一个从机的成功应答即认为半同步复制成功的特性，所以多从半同步复制的可靠性要优于单从半同步复制的可靠性。并且多节点同时宕机的几率也要小于单节点宕机的几率，所以多节点架构在一定程度上可以认为高可用性是好于双节点架构。

但是由于数据库数量较多，所以需要数据库管理软件来保证数据库的可维护性。可以选择MMM、MHA或者各个版本的proxy等等。常见方案如下：

MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。

MHA Node运行在每台MySQL服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。

MHA也可以扩展到如下的多节点集群：

优点：

缺点：

Zookeeper使用分布式算法保证集群数据的一致性，使用zookeeper可以有效的保证proxy的高可用性，可以较好的避免网络分区现象的产生。

优点：

缺点：

2.4. 共享存储

共享存储实现了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL的原生复制功能，而是通过磁盘数据同步的手段，来保证数据的一致性。

SAN的概念是允许存储设备和处理器（服务器）之间建立直接的高速网络（与LAN相比）连接，通过这种连接实现数据的集中式存储。常用架构如下：

使用共享存储时，MySQL服务器能够正常挂载文件系统并 *** 作，如果主库发生宕机，备库可以挂载相同的文件系统，保证主库和备库使用相同的数据。

优点：

缺点：

DRBD是一种基于软件、基于网络的块复制存储解决方案，主要用于对服务器之间的磁盘、分区、逻辑卷等进行数据镜像，当用户将数据写入本地磁盘时，还会将数据发送到网络中另一台主机的磁盘上，这样的本地主机(主节点)与远程主机(备节点)的数据就可以保证实时同步。常用架构如下：

当本地主机出现问题，远程主机上还保留着一份相同的数据，可以继续使用，保证了数据的安全。

DRBD是linux内核模块实现的快级别的同步复制技术，可以与SAN达到相同的共享存储效果。

优点：

缺点：

2.5. 分布式协议

分布式协议可以很好解决数据一致性问题。比较常见的方案如下：

MySQL cluster是官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。

优点：

缺点：

基于Galera的MySQL高可用集群， 是多主数据同步的MySQL集群解决方案，使用简单，没有单点故障，可用性高。常见架构如下：

优点：

缺点：

Paxos 算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。这个算法被认为是同类算法中最有效的。Paxos与MySQL相结合可以实现在分布式的MySQL数据的强一致性。常见架构如下：

优点：

缺点：

3. 总结

随着人们对数据一致性的要求不断的提高，越来越多的方法被尝试用来解决分布式数据一致性的问题，如MySQL自身的优化、MySQL集群架构的优化、Paxos、Raft、2PC算法的引入等等。

而使用分布式算法用来解决MySQL数据库数据一致性的问题的方法，也越来越被人们所接受，一系列成熟的产品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越来越多的被大规模使用。

随着官方MySQL Group Replication的GA，使用分布式协议来解决数据一致性问题已经成为了主流的方向。期望越来越多优秀的解决方案被提出，MySQL高可用问题可以被更好的解决。

分布式解决方案 tidb

多主 多备 master lvs做vip 读写分离中间件

8.2 规范化理论

关系数据库中关系规范化问题在1970年Godd提出关系模型时就同时被提出来,关系规范化可按属性间不同的依赖程度分为第一范式,第二范式,第三范式,Boyce-Codd范式以及第四范式.人们对规范化的认识是有一个过程的,在1970年时已发现属性间的函数依赖关系,从而定义了与函数依赖关系有关的第一,第二,第三,及Boyce-Codd范式.在1976~1978年间,Fagin,Delobe以及Zanjolo发现了多值依赖关系,从而定义了与多值依赖有关的第四范式.

范式的定义与属性间的依赖关系的发现有密切关系,在本节中我们介绍函数依赖与多值依赖这两个概念,并在此基础上定义第一范式,第二范式,第三范式,Boyce-Codd范式以及第四范式.

8.2.1 函数依赖

函数依赖(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)的非主属性集.以上建立了一系列与函数依赖有关的概念,有了它们后就可以讨论与函数依赖有关的几

个范式,它们是第一范式,第二范式及第三范式(实际上第一范式与所有依赖均无关,但为叙述方便起见,可视为与函数依赖有关).至于函数依赖的有关理论的探讨,将在本章稍后部分再作详细介绍.

8.2.2 与函数依赖有关的范式

在这节中我们讨论四种范式,他们是第一范式,第二范式,第三范式以及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的原子模型

8.2.3 多值依赖与第四范式

我们研究了函数依赖及与它有关的几个范式,但是否关系模式内属性间的依赖关系除函数依赖外就没有其他依赖关系呢 事实并不如此,函数依赖关系是一种较为明显的依赖关系,但是随着人们对关系模式了解越来越深刻后,发现尚有另外的一些依赖系存在,多值依赖就是其中的一种.我们先举一个例子,以说明多值依赖的存在.

例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.

8.2.4 小 结

我们在规范化讨论中定义了五个范式,对这些范式的认识是逐步深入的.总的说来,我们可以总结成下面几点:

(1) 规范化的目的:解决插入,修改异常以及数据冗余度高.

(2) 规范化的方法:从模式中各属性间的依赖关系(函数依依赖及多值依赖)入手,尽量做到每个模式表示客观世界中的一个"事物".

(3) 规范化的实现手段:用模式分解的方法.

实际上从第一范式到第四范式的过程是一个不断消除一些依赖关系中的弊病的过程.图8-7给出了这个过程.

读者应注意的是:规范化是一种理论,它研究如何通过规范以解决异常与冗余现象,在实际数据库设计中构作关系模式时需要考虑到这个因素.但是,客观世界是复杂的,在构作模式时尚需考虑到其他的多种因素,如模式分解过多,势必在数据查询时要用到较多的联结运算,这样就会影响查询速度.因此,在实际构作模式中,需要综合多种正反因素,统一权衡利弊得失,最后构做出一个较为适合实际的模式来.

图8-7 规范化的过程

8.3 规范化所引起的一些问题

由规范化而引起了对一些问题的进一步研究,它们是:

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

最简洁的：

Difference between 3NF and BCNF is that for a functional dependency A->B, 3NF allows this dependency in a relation if B is a ***** attribute and A is not a candidate key

稍长点的：

consider that:

It should be noted that most relations that are in 3NF are also in BCNF. Infrequently, a 3NF relation is not in BCNF and this happens only if

(a) the candidate keys in the relation are composite keys (that is, they are not single attributes),

(b) there is more than one candidate key in the relation, and

(c) the keys are not disjoint, that is, some attributes in the keys are common.

超长的：

Comparison of BCNF and 3NF

We have seen BCNF and 3NF.

It is always possible to obtain a 3NF design without sacrificing lossless-join or dependency-preservation.

If we do not eliminate all transitive dependencies, we may need to use null values to represent some of the meaningful relationships.

Repetition of information occurs.

These problems can be illustrated with Banker-schema.

As banker-name bname , we may want to express relationships between a banker and his or her branch.

Figure 7.4: An instance of Banker-schema.

（http://www.cs.sfu.ca/CC/354/zaiane/material/notes/Chapter7/node12.html）

Figure 7.4 shows how we must either have a corresponding value for customer name, or include a null.

Repetition of information also occurs.

Every occurrence of the banker's name must be accompanied by the branch name.

If we must choose between BCNF and dependency preservation, it is generally better to opt for 3NF.

If we cannot check for dependency preservation efficiently, we either pay a high price in system performance or risk the integrity of the data.

The limited amount of redundancy in 3NF is then a lesser evil.

To summarize, our goal for a relational database design is

BCNF.

Lossless-join.

Dependency-preservation.

If we cannot achieve this, we accept

3NF

Lossless-join.

Dependency-preservation.

A final point: there is a price to pay for decomposition. When we decompose a relation, we have to use natural joins or Cartesian products to put the pieces back together. This takes computational time.

---