规范化问题的提出

在规范化理论出现以前,层次和网状数据库的设计只是遵循其模型本身固有的原则,而无具体的理论依据可言,因而带有盲目性,可能在以后的运行和使用中发生许多预想不到的问题。

在关系数据库系统中,关系模型包括一组关系模式,各个关系不是完全孤立的,数据库的设计较层次和网状模型更为重要。

如何设计一个适合的关系数据库系统,关键是关系数据库模式的设计,一个好的关系数据库模式应该包括多少关系模式,而每一个关系模式又应该包括哪些属性,又如何将这些相互关联的关系模式组建一个适合的关系模型,这些工作决定了整个系统运行的效率,也是系统成败的关键所在,所以必须在关系数据库的规范化理论的指导下逐步完成。

要求设计教学管理数据库,其关系模式SCD如下:

SCD(SNO,SN,AGE,DEPT,MN,CNO,SCORE)

其中,SNO表示学生学号,SN表示学生姓名,AGE表示学生年龄,DEPT表示学生所在的系别,MN表示系主任姓名,CNO表示课程号,SCORE表示成绩。

根据实际情况,这些数据有如下语义规定:

  1. 一个系有若干个学生,但一个学生只属于一个系;
  2. 一个系只有一名系主任,但一个系主任可以同时兼几个系的系主任;
  3. 一个学生可以选修多门功课,每门课程可有若干学生选修;
  4. 每个学生学习课程有一个成绩。

在此关系模式中填入一部分具体的数据,则可得到SCD关系模式的实例,即一个教学管理数据库,如下图所示。

根据上述的语义规定,并分析以上关系中的数据,我们可以看出:(SNO,CNO)属性的组合能唯一标识一个元组,所以(SNO,CNO)是该关系模式的主键(思考:没有主键行不行?) 。

但在进行数据库的操作时,会出现以下几方面的问题。

  1. 数据冗余。

    每个系名和系主任的名字存储的次数等于该系的学生人数乘以每个学生选修的课程门数,同时学生的姓名、年龄也都要重复存储多次,数据的冗余度很大,浪费了存储空间。(思考:如果不重复记录学生非主属性,会出现什么情况?)

  2. 插入异常。

    如果某个新系没有招生,尚无学生时,则系名和系主任的信息无法插入到数据库中。

    因为在这个关系模式中,(SNO,CNO)是主键。根据关系的实体完整性约束,主键的值不能为空,而这时没有学生,SNO和CNO均无值,因此不能进行插入操作。

    另外,当某个学生尚未选课,即CNO未知,实体完整性约束还规定,主键的值不能部分为空,同样不能进行插入操作。

  3. 删除异常。

    某系学生全部毕业而没有招生时,删除全部学生的记录则系名、系主任也随之删除,而这个系依然存在,在数据库中却无法找到该系的信息。

    另外,如果某个学生不再选修C1课程,本应该只删去C1,但C1是主关系键的一部分,为保证实体完整性,必须将整个元组一起删掉,这样,有关该学生的其它信息也随之丢失。

  4. 更新异常。

    如果学生改名,则该学生的所有记录都要逐一修改SN;

    又如某系更换系主任,则属于该系的学生记录都要修改MN的内容,稍有不慎,就有可能漏改某些记录,这就会造成数据的不一致性,破坏了数据的完整性。

由于存在以上问题,我们说,SCD是一个不好的关系模式。产生上述问题的原因,直观地说,是因为关系中“包罗万象”,内容太杂了。

在SCD中,既存在完全函数依赖,又存在部分函数依赖和传递函数依赖。这种情况往往在数据库中是不允许的,也正是由于关系中存在着复杂的函数依赖,才导致数据操作中出现了种弊端。克服这些弊端的方法是用投影运算将关系分解,去掉过于复杂的函数依赖关系,向更高一级的范式进行转换。

好的关系模式:

把关系模式SCD分解为下面三个结构简单的关系模式,如下图所示。

学生关系S(SNO,SN,AGE,DEPT)

选课关系SC(SNO,CNO,SCORE)

系关系D(DEPT,MN)

在以上三个关系模式中,实现了信息的某种程度的分离,

  • S中存储学生基本信息,与所选课程及系主任无关;
  • D中存储系的有关信息,与学生无关;
  • SC中存储学生选课的信息,而与学生及系的有关信息无关。

与SCD相比,分解为三个关系模式后,数据的冗余度明显降低。

  • 当新插入一个系时,只要在关系D中添加一条记录。
  • 当某个学生尚未选课,只要在关系S中添加一条学生记录,而与选课关系无关,这就避免了插入异常。
  • 当一个系的学生全部毕业时,只需在S中删除该系的全部学生记录,而关系D中有关该系的信息仍然保留,从而不会引起删除异-常。
  • 同时,由于数据冗余度的降低,数据没有重复存储,也不会引起更新异常。

从而得出结论,一个好的关系模式应该具备以下四个条件:

  1. 尽可能少的数据冗余。
  2. 没有插入异常。
  3. 没有删除异常。
  4. 没有更新异常。

主要内容

函数信赖

范式(Normal Form)

模式设计

函数信赖起着核心的作用,是模式分解和模式设计的基础,范式是模式分解的标准。

函数依赖

关系模式中的各属性之间相互依赖、相互制约的联系称为数据依赖。数据依赖一般分为函数依赖、多值依赖和连接依赖。其中,函数依赖是最重要的数据依赖。

函数依赖(Functional Dependency)是关系模式中属性之间的一种逻辑依赖关系。

例如关系模式SCD中,SNO与SN、AGE、DEPT之间都有一种依赖关系。由于一个SNO只对应一个学生,而一个学生只能属于一个系,所以当SNO的值确定之后,SN,AGE,DEPT的值也随之被唯一的确定了。这类似于变量之间的单值函数关系。设单值函数Y=F(X),自变量X的值可以决定一个唯一的函数值Y。在这里,我们说SNO决定函数(SN,AGE,DEPT),或者说(SN,AGE,DEPT)函数依赖于SNO。

函数依赖的定义

设关系模式R(U,F),U是属性全集,F是U上的函数依赖集,X和Y是U的子集,如果对于R(U)的任意一个可能的关系r,对于X的每一个具体值,Y都有唯一的具体值与之对应,则称X决定函数Y,或Y函数依赖于X,记作X→Y。我们称X为决定因素,Y为依赖因素。当Y不函数依赖于X时,记作:X-/->Y。当X→Y且Y→X时,则记作:X<–>Y。

对于关系模式SCD

U={SNO,SN,AGE,DEPT,MN,CNO,SCORE}

很显然:SNO→SN,SNO→AGE,SNO→DEPT

一个SNO有多个SCORE的值与其对应,因此SCORE不能唯一地确定,即SCORE不能函数依赖于SNO,所以有: SNO-/->SCORE。但是SCORE可以被(SNO,CNO)唯一地确定。所以可表示为:(SNO,CNO)→SCORE。

(SNO,CNO,AGE)→SCORE

有关函数依赖的几点说明:

  1. 平凡的函数依赖与非平凡的函数依赖。

    当属性集Y是属性集X的子集时,则必然存在着函数依赖X→Y,这种类型的函数依赖称为平凡的函数依赖。 (SNO,CNO)→SNO

    • 如果Y不是X的子集,则称X→Y为非平凡的函数依赖。
    • 若不特别声明,我们讨论的都是非平凡的函数依赖。
  2. 函数依赖是语义范畴的概念。

    我们只能根据语义来确定一个函数依赖,而不能按照其形式化定义来证明一个函数依赖是否成立。

    例如,对于关系模式S,当学生不存在重名的情况下,可以得到:

    SN→AGE

    SN→DEPT

    这种函数依赖关系,必须是在没有重名的学生条件下才成立的,否则就不存在函数依赖了。

    所以函数依赖反映了一种语义完整性约束。

  3. 函数依赖关系的存在与时间无关。

    因为函数依赖是指关系中的所有元组应该满足的约束条件,而不是指关系中某个或某些元组所满足的约束条件。当关系中的元组增加、删除或更新后都不能破坏这种函数依赖。因此,必须根据语义来确定属性之间的函数依赖,而不能单凭某一时刻关系中的实际数据值来判断。

    例如,对于关系模式S,假设没有给出无重名的学生这种语义规定,则即使当前关系中没有重名的记录,也只能存在函数依赖SNO→SN,而不能存在函数依赖SN→SNO,因为如果新增加一个重名的学生,函数依赖SN→SNO必然不成立。

    所以函数依赖关系的存在与时间无关,而只与数据之间的语义规定有关。

  4. 函数依赖可以保证关系分解的无损连接性。

    设R(X,Y,Z),X,Y,Z为不相交的属性集合,如果X→Y或X→Z,则有R(X,Y,Z)=R[X,Y]*R[X,Z],

    其中,R[X,Y]表示关系R在属性(X,Y)上的投影,即R等于其投影在X上的自然连接,这样便保证了关系R分解后不会丢失原有的信息,称作关系分解的无损连接性。

    例如,对于关系模式SCD,有SNO→(SN,AGE,DEPT,MN),SCD(SNO,SN,AGE,DEPT,MN,CNO,SCORE)=SCD[SNO,SN,AGE,DEPT,MN]*SCD[SNO,CNO,SCORE],也就是说,用其投影在SNO上的自然连接可复原关系模式SCD。

    这一性质非常重要,在后一节的关系规范化中要用到。

函数依赖的基本性质

1.投影性。

根据平凡的函数依赖的定义可知,一组属性函数决定它的所有子集。

例如,在关系SCD中,(SNO,CNO)→SNO和(SNO,CNO)→CNO。

2.扩张性。

若X→Y且W→Z,则(X,W)→(Y,Z)。

例如,SNO→(SN,AGE),DEPT→MN,则有(SNO,DEPT)→(SN,AGE,MN)。

3.合并性。

若X→Y且X→Z则必有X→(Y,Z)。

例如,在关系SCD中,SNO→(SN,AGE),SNO→(DEPT,MN),则有SNO→(SN,AGE,DEPT,MN)。

4.分解性。

若X→(Y,Z),则X→Y且X→Z。很显然,分解性为合并性的逆过程。

完全函数依赖与部分函数依赖

设关系模式R(U),U是属性全集,X和Y是U的子集:

  • 如果X→Y,并且对于X的任何一个真子集X′,都有X′–/->Y,则称Y对X完全函数依赖(Full Functional Dependency),记作 X–f–> Y。
  • 如果对X的某个真子集X′,有X′→Y,则称Y对x部分函数依赖(Partial Functional Dependency),记作X–p–>Y。

由上述定义可知:

  • 只有当决定因素是组合属性时,讨论部分函数依赖才有意义,
  • 当决定因素是单属性时,只能是完全函数依赖。

传递函数依赖

设有关系模式R(U),U是属性全集,X,Y,Z是U的子集,

若X→Y,但Y-/->X,而Y→Z(Y∉X,Z∉Y),则称Z对X传递函数依赖(Transitive Functional Dependency),记作:X–t-->Z。

如果Y→X,则X<—>Y,这时称Z对X直接函数依赖,而不是传递函数依赖。

综上所述,函数依赖分为完全函数依赖、部分函数依赖和传递函数依赖三类,它们是规范化理论的依据和规范化程度的准则。

范式

规范化的基本思想是消除关系模式中的数据冗余,消除数据依赖中的不合适的部分,解决数据插入、删除时发生异常现象。

这就要求关系数据库设计出来的关系模式要满足一定的条件。

我们把关系数据库的规范化过程中为不同程度的规范化要求设立的不同标准称为范式(Normal Form)。

规范与非规范关系->1NF->2NF->3NF->BSNF->4NF->5NF

第一范式(First Normal Form)

如果关系模式R,其所有的属性均为简单属性,即每个属性域都是不可再分的,则称R属于第一范式,简称1NF,记作R∈1NF。

在讨论关系的性质时,我们把满足这个条件的关系称为规范化关系。

在关系数据库系统中只讨论规范化的关系,凡是非规范化的关系模式必须化成规范化的关系。

在非规范化的关系中去掉组合项就能化成规范化的关系。

每个规范化的关系都属于1NF,这也是它之所以称为“第一”的原因。

然而,一个关系模式仅仅属于第一范式是不适用的,其中可能具有大量的数据冗余,具有插入异常、删除异常、更新异常等弊端。

第二范式(Second Normal Form)

如果关系模式R∈1NF,且每个非主属性都完全函数依赖于R的每个关系键,则称R属于第二范式(Second Normal Form),简称2NF,记作R∈2NF。

关系键的定义

设关系模式R的属性集是U,X是U的一个子集。如果X→U在R上成立,那么称X是R的一个超键。如果X→U在R上成立,但对于X的任一真子集X1都有X1→U不成立,那么称X是R上的一个候选键。可任意指定一个候选键为主键。在任一候选键中出现过的属性成为主属性。

SD(SNO,SN,AGE,DEPT,MN),描述学生实体;

SC(SNO,CNO,SCORE),描述学生与课程的联系。

1.从1NF关系中消除非主属性对关系键的部分函数依赖,则可得到2NF关系。

2.如果R的关系键为单属性,或R的全体属性均为主属性,则R∈2NF。

2NF规范化

2NF规范化是指把1NF关系模式通过投影分解转换成2NF关系模式的集合。

分解时遵循的基本原则就是“一事一表”,让一个关系只描述一个实体或者实体间的联系。如果多于一个实体或联系,则进行投影分解。

下面对2NF规范化作形式化的描述。

设关系模式R(X,Y,Z),R∈1NF,但R不是2NF,其中,X是键属性,Y,Z是非键属性,且存在部分函数依赖,

X–p–>Y。设X可表示为X1、X2,其中

X1–f–>Y。则R(X,Y,Z)可以分解为R[X1,Y]和R[X,Z]。

因为X1→Y,所以R(X,Y,Z)=R[X1,Y]*R[X1,X2,Z]=R[X1,Y]*R[X,Z],即R等于其投影R[X1,Y]和[X,Z]在X1上的自然连接,R的分解具有无损连接性。

由于X1–f–>Y,因此R[X1,Y]∈2NF。若R[X,Z]不属于2NF,可以按照上述方法继续进行投影分解,直到将R[X,Z]分解为属于2NF关系的集合,且这种分解必定是有限的。

2NF的缺点

2NF的关系模式解决了1NF中存在的一些问题,2NF规范化的程度比1NF前进了一步,但2NF的关系模式在进行数据操作时,仍然存在着一些问题:

1.数据冗余。每个系名和系主任的名字存储的次数等于该系的学生人数。

2.插入异常。当一个新系没有招生时,有关该系的信息无法插入。

3.删除异常。某系学生全部毕业而没有招生时,删除全部学生的记录也随之删除了该系的有关信息。

4.更新异常。更换系主任时,仍需改动较多的学生记录。

第三范式(Third Normal Form)

如果关系模式R∈2NF,且每个非主属性都不传递依赖于R的每个关系键,则称R属于第三范式(Third Normal Form),简称3NF,记作R∈3NF。

SCD规范到3NF后,所存在的异常现象已经全部消失。

3NF只限制了非主属性对键的依赖关系,而没有限制主属性对键的依赖关系。

如果发生了这种依赖,仍有可能存在数据冗余、插入异常、删除异常和修改异常。

这时,则需对3NF进一步规范化,消除主属性对键的依赖关系,为了解决这种问题,Boyce与Codd共同提出了一个新范式的定义,这就是Boyce-Codd范式,通常简称BCNF或BC范式。它弥补了3NF的不足。

BC范式(Boyce-Codd Normal Form)

如果关系模式R∈1NF,且所有的函数依赖X→Y(Y ∉X),决定因素X都包含了R的一个候选键,则称R属于BC范式(Boyce-Codd Normal Form),记作R∈BCNF。

如果R属于BCNF,则R属于3NF一定成立。反之不一定成立,因为3NF的不彻底性(可能存在主属性对码的部分依赖和传递依赖)。

例:(S,J)→T,(S,T)→J,T→J。候选码为(S,J)、(S,T),T是决定因素,但T不包含码。

关系模式的规范化

一个低一级范式的关系模式,通过模式分解转化为若干个高一级范式的关系模式的集合,这种分解过程叫作关系模式的规范化(Normalization)。

关系模式规范化的目的和原则

一个关系只要其分量都是不可分的数据项,就可称作规范化的关系,但这只是最基本的规范化。

这样的关系模式是合法的。

但人们发现有些关系模式存在插入、删除、修改异常、数据冗余等弊病。

规范化的目的就是使结构合理,消除存储异常,使数据冗余尽量小,便于插入、删除和更新。

规范化的基本原则就是遵从概念单一化“一事一表”的原则,即一个关系只描述一个实体或者实体间的联系。

若多于一个实体,就把它“分离”出来。

因此,所谓规范化,实质上是概念的单一化,即一个关系表示一个实体。

一般情况下,我们说没有异常弊病的数据库设计是好的数据库设计,一个不好的关系模式也总是可以通过分解转换成好的关系模式的集合。

但是在分解时要全面衡量,综合考虑,视实际情况而定。

对于那些只要求查询而不要求插入、删除等操作的系统,几种异常现象的存在并不影响数据库的操作。这时便不宜过度分解,否则当要对整体查询时,需要更多的多表连接操作,这有可能得不偿失。

在实际应用中,最有价值的是3NF和BCNF,在进行关系模式的设计时,通常分解到3NF就足够了。

关系模式规范化的步骤

规范化就是对原关系进行投影,消除决定属性不是候选键的任何函数依赖。具体可以分为以下几步:

1.对1NF关系进行投影,消除原关系中非主属性对键的部分函数依赖,将1NF关系转换成若干个2NF关系。

2.对2NF关系进行投影,消除原关系中非主属性对键的传递函数依赖,将2NF关系转换成若干个3NF关系。

3.对3NF关系进行投影,消除原关系中主属性对键的部分函数依赖和传递函数依赖,也就是说使决定因素都包含一个候选键。得到一组BCNF关系。

无损连接性和函数依赖性

无损连接性(Lossless Join):如果对分解后的新关系进行自然连接得到的元组的集合与原关系完全一致,则称为无损连接。

损失是数据出错的。

函数依赖保持性(Preserve Dependency):依赖关系未发生变化,如果F上的每一个函数依赖都在其分解后的某一个关系上成立,则这个分解是保持函数依赖的(注意:这是一个充分条件)。也就是产生关联的属性要分到一起。

依赖未保持是繁琐的。

判断对关系模式的一个分解是否与原关系模式等价:分解既要具有无损连接性,又要具有函数依赖保持性。

如果一个分解具有无损连接性,则能够保证不丢失信息。如果一个分解具有函数依赖保持性,则可以减轻或解决各种异常情况。

分解具有无损连接性和函数依赖保持性是两个相互独立的标准。具有无损连接性的分解不一定具有函数依赖保持性。同样,具有函数依赖保持性的分解也不一定具有无损连接性。

规范化理论提供了一套完整的模式分解方法,按照这套算法可以做到:如果要求分解既具有无损连接性,又具有函数依赖保持性,则分解一定能够达到3NF,但不一定能够达到BCNF。

所以在3NF的规范化中,既要检查分解是否具有无损连接性,又要检查分解是否具有函数依赖保持性。

只有这两条都满足,才能保证分解的正确性和有效性,才既不会发生信息丢失,又保证关系中的数据满足完整性约束。

举个例子讲,很简单:

对于关系模式SD(SNO,SN,AGE,DEPT,MN),规范到3NF,可以有以下三种不同的分解方法:

第一种:

S(SNO,SN,AGE,DEPT)

D(DEPT,MN)

SD(SNO,SN,AGE,DEPT,MN)=S[SNO,SN,AGE,DEPT]*D[DEPT,MN],

也就是说,用其两个投影在DEPT上的自然连接可复原关系模式SD。也就是说这种分解具有无损连接性。

对于分解后的关系模式S,有函数依赖SNO→DEPT,对于D,有函数依赖DEPT→MN,这种分解方法保持了原来的SD中的两个完全函数依赖SNO→DEPT,DEPT→MN。分解既具有无损连接性,又具有函数依赖保持性。

前面已经给出详细的论述,这是一种正确的分解方法。

第二种:

S1(SNO,SN,AGE,DEPT)

D1(SNO,MN)

存在着一些问题因为分解得到的两个关系模式不是相互独立的。函数依赖DEPT→MN既没有投影到关系模式S1上,也没有投影到关系模式D1上,而是跨在这两个关系模式上,也就是说这种分解方法没有保持原关系中的函数依赖,却用了原关系隐含的传递函数依赖SNO–t-->MN。分解只具有无损连接性,而不具有函数依赖保持性。因此,“弊病”仍然没有解决。

第三种:

S2(SNO,SN,AGE,MN)

D2(DEPT,MN)

MN–/–>SNO,MN–/–>DEPT,所以S2*D2≠SD,此分解方法丢失了信息,其分解是不可恢复的。分解既不具有无损连接性,也不具有函数依赖保持性。

非规范化设计

许多数据库应用强调性能优先

规范化设计有时会导致数据库运行效率的下降

非规范化设计

在特殊条件和要求下,适当地降低甚至抛弃关系模式的范式,不再要求一个表只描述一个实体或者实体间的一种联系。其主要目的在于提高数据库的运行效率。

一般认为,在下列情况下可以考虑进行非规范化处理:

  • 大量频繁的查询过程所涉及的表都需要进行连接;
  • 主要的应用程序在执行时要将表连接起来进行查询;
  • 对数据的计算需要临时表或进行复杂的查询。

非规范化处理的主要技术包括增加冗余或派生列,对表进行合并、分割或增加重复表。

增加冗余列是指在多个表中具有相同的列,它常用来在查询时避免连接操作。增加冗余列可以在查询时避免连接操作,但它需要更多的磁盘空间,同时增加表维护的工作量。

增加派生列指增加的列来自其它表中的数据,由它们计算生成。它的作用是在查询时减少连接操作,避免使用集函数。派生列也具有与冗余列同样的缺点。

重新组表指如果许多用户需要查看两个表连接出来的结果数据,则把这两个表重新组成一个表来减少连接而提高性能。这样可提高性能,但需要更多的磁盘空间,同时也损失了数据在概念上的独立性。

有时对表做分割可以提高性能。

表分割有两种方式:

  • 水平分割
  • 垂直分割

根据一列或多列数据的值把数据行放到两个独立的表中。

水平分割通常在下面的情况下使用。

  • 表很大,分割后可以降低在查询时需要读的数据和索引的页数,同时也降低了索引的层数,提高查询速度。
  • 表中的数据本来就有独立性,例如表中分别记录各个地区的数据或不同时期的数据,特别是有些数据常用,而另外一些数据不常用。
  • 需要把数据存放到多个介质上。

水平分割会给应用增加复杂度,它通常在查询时需要多个表名,查询所有数据需要union操作。在许多数据库应用中,这种复杂性会超过它带来的优点。

垂直分割:把主键和一些列放到一个表,然后把主键和另外的列放到另一个表中。

如果一个表中某些列常用,而另外一些列不常用,则可以采用垂直分割加快查询速度。其缺点是需要管理冗余列,查询所有数据需要join操作。

非规范化设计的主要优点

  • 减少了查询操作所需的连接
  • 减少了外部键和索引的数量
  • 可以预先进行统计计算,提高了查询时的响应速度

非规范化存在的主要问题

  • 增加了数据冗余
  • 影响数据库的完整性
  • 降低了数据更新的速度
  • 增加了存储表所占用的物理空间

闭包

  • 属性集的闭包(A+A^+A+):由属性A通过依赖关系所能推导出的所有属性构成的集合

    • 用途

      判断α是否为超码,通过计算α+(α在F下的闭包),看α+ 是否包含了R中的所有属性。若是,则α为R的超码。

      通过检验是否β∈α+,来验证函数依赖是否成立。也就是说,用属性闭包计算α+,看它是否包含β。

  • 函数依赖的闭包(F+F^+F+): 若F为关系模式R(U)的函数依赖集,我们把F以及所有被F逻辑蕴涵的函数依赖的集合称为F的闭包。规定:若X为U的子集,X→Φ 属于F+。

属性集闭包的用途:

  • 判断α是否为超码,通过计算α+(α在F下的闭包),看α+ 是否包含了R中的所有属性。若是,则α为R的超码。
  • 通过检验是否β∈α+,来验证函数依赖是否成立。也就是说,用属性闭包计算α+,看它是否包含β。

There are scenarios where redundancy in schema design is actually desired

范式等级,说明是否为该等级和为什么,分解为某范式

函数依赖集

无损分解

计算

函数依赖是否蕴含于原函数依赖:若 (导出) ∈ (被依赖)+,则函数依赖成立

  1. 若XY->Z,则X->Z,Y->Z(F)
  2. 若X->Y,Z∈Y,则X->Z(T)

求候选关键字:画出依赖关系,将没有入度的点加入候选关键字中,并在属性集中去掉其闭包,在剩下的属性中进行类似挑选直到所有属性都被去掉。如果没有入度为0的点则分类讨论,从哪个点开始就先去掉进入它的路径。

最高属于的范式:看是否符合2(部分p)3(传递t)BC(主属性)条件,从2开始看会快一些。

范式的分解:先找出候选关键字,画出关系图,根据关键字及相关等级范式要求进行分割。

无损连接性:1.R1或R2部分依赖于R1∩R2 2.(所得表的依赖关系)–>(原有表的依赖关系)

Data Management Technology(4) -- 关系数据库理论的更多相关文章

  1. Data Management Technology(1) -- Introduction

    1.Database concepts (1)Data & Information Information Is any kind of event that affects the stat ...

  2. Data Management Technology(5) -- Recovery

    Recovery Types of Failures Wrong data entry Prevent by having constraints in the database Fix with d ...

  3. Data Management Technology(3) -- SQL

    SQL is a very-high-level language, in which the programmer is able to avoid specifying a lot of data ...

  4. Data Management Technology(2) -- Data Model

    1.Data Model Model Is the abstraction of real world Reveal the essence of objects, help people to lo ...

  5. MySQL vs. MongoDB: Choosing a Data Management Solution

    原文地址:http://www.javacodegeeks.com/2015/07/mysql-vs-mongodb.html 1. Introduction It would be fair to ...

  6. [Windows Azure] Data Management and Business Analytics

    http://www.windowsazure.com/en-us/develop/net/fundamentals/cloud-storage/ Managing and analyzing dat ...

  7. Intel Active Management Technology

    http://en.wikipedia.org/wiki/Intel_Active_Management_Technology Intel Active Management Technology F ...

  8. 场景3 Data Management

    场景3 Data Management 数据管理 性能优化 OLTP OLAP 物化视图 :表的快照 传输表空间 :异构平台的数据迁移 星型转换 :事实表 OLTP : 在线事务处理 1. trans ...

  9. Data Management and Data Management Tools

    Data Management ObjectivesBy the end o this module, you should understand the fundamentals of data m ...

随机推荐

  1. Spring Cloud Config实现集群配置中心

    Spring Cloud Config为分布式系统提供了配置服务器和配置客户端,可以管理集群中的配置文件.使用Git.SVN等版本管理系统存放配置文件,配置服务器会到版本管理系统获取配置,集群中的配置 ...

  2. ORACLE spool打印

    问题描述:spool让我想起来了spooling假脱机,但是这个spool是oracle下的命令,将select查询出来的数据打印出来 1.linuxi下 spool +路径+文件名,这里的文件如果不 ...

  3. inux 网络监控分析

    一.sar -n:查看网卡流量 -n 参数,他有6个不同的开关:DEV | EDEV | NFS | NFSD | SOCK | ALL .DEV显示网络接口信息,EDEV显示关于网络错误的统计数据, ...

  4. Nginx安装与运行

    目录 Nginx安装与运行 安装Nginx 运行 注意事项 Nginx安装与运行 安装Nginx 在Nginx官网下载对应的nginx包(推荐使用稳定版[Stable version]) 上传ngin ...

  5. Python连载56-发送带有附件、正文为HTML的邮件

    一.HTML格式怎么发送右键 1.准备HTML代码作为内容 2.把邮件的subtype设置为html 3.发送 4.举个例子:自己发给自己一个HTML格式的文件 from email.mime.tex ...

  6. C# 32位程序 申请大内存

    后期生成事件命令行代码: cd /d $(DevEnvDir)cd..cd..cd VC\bineditbin /largeaddressaware $(TargetPath)

  7. GitLab-怎样使用GitLab托管项目

    场景 Docker Compose部署GitLab服务,搭建自己的代码托管平台(图文教程): https://blog.csdn.net/BADAO_LIUMANG_QIZHI/article/det ...

  8. 44.QT-安装MySQL、测试连接MySQL

    在上章学习了42.QT-操作SQLite数据库后,发现MySQL和SQLite的语句都大致相同,所以本章只测试MySQL是否能使用 MySQL安装参考链接:https://blog.csdn.net/ ...

  9. 验证apk签名方式(V1 || V2)

    进入SDK\build-tools\28.0.2目录(或者其他版本),该目录有apksigner.bar脚本,我们可以利用它来验证. 在此目录打开命令行. 命令为:apksigner verify - ...

  10. 5G技术发展迅猛,亚博电竞(yabo055)搭上科技快车

    要说当前互联网科技最为令人期待的当属yabo055点康母的5G技术了.自2018年5G标准确定以来,民众就对5G非常的期待,而亚博电竞早已意识到了5G时代的来临势不可挡,早已着手将5G运用于网站和游戏 ...