第5章：关系数据库设计理论

5.1基本概念数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系是现实世界属性间相互联系的抽象是数据内在的性质是语义的体现5.1基本概念数据依赖的类型函数依赖（FunctionalDependency，简记为FD）多值依赖（MultivaluedDependency，简记为MVD）其他5.1.1函数依赖定义5.1设R(U)是一个属性集U上的关系模式，X和Y是U的子集。若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称“X函数确定Y”或“Y函数依赖于X”，记作X→Y。Y=f(x)说明1.函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件，而是指R的所有关系实例均要满足的约束条件。2.函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖。例如“药品名称→零售价”这个函数依赖只有在不允许有同名药的条件下成立3.数据库设计者可以对现实世界作强制的规定。例如规定不允许同名药品出现，函数依赖“药品名称→零售价”成立。所插入的元组必须满足规定的函数依赖，若发现有同名药存在，则拒绝装入该元组。说明4.一般情况下函数依赖没有可逆性。即药品代码→药品名称，不能得出药品名称→药品代码。但是如果假定药品不同名，上述函数依赖关系成立。5.函数依赖中可以包含属性组。在库存表中，表中每个元组的意思是哪个药房存放了哪个批次的药品数量是多少、有效期是多少。因此数量和有效期必须结合前面三个字段才能确定。因此该函数依赖记作：（库存地点、批号、药品代码）→数量，（库存地点、批号、药品代码）→有效期。6.X→Y，则X称为这个函数依赖的决定属性组，也称为决定因素(Determinant)平凡函数依赖与非平凡函数依赖在关系模式R(U)中，对于U的子集X和Y，如果X→Y，但YX，则称X→Y是非平凡的函数依赖若X→Y，但YX,则称X→Y是平凡的函数依赖若X→Y，并且Y→X,则记作X←→Y。若Y不函数依赖于X，则记作X→Y平凡函数依赖与非平凡函数依赖（续）于任一关系模式，平凡函数依赖都是必然成立的，它不反映新的语义，因此若不特别声明，我们总是讨论非平凡函数依赖。完全函数依赖与部分函数依赖定义5.2在关系模式R(U,F)中，如果X→Y，并且对于X的任何一个真子集X’，都有X’Y,则称Y完全函数依赖于X，记作XｆY。若X→Y，但Y不完全函数依赖于X，则称Y部分函数依赖于X，记作XpY。完全函数依赖与部分函数依赖（续）例：在关系库存表（库存地点、批号、药品代码，数量，有效期）中，由于库存地点→数量，批号→数量，药品代码→数量，因此，（库存地点、批号、药品代码）ｆ数量。如果在此关系中加入一个属性：药库主任。则库存地点→药库主任。因此药库主任部分依赖于（库存地点、批号、药品代码）。传递函数依赖定义5.3在关系模式R(U,F)中，如果X→Y，Y→Z，且YX，Y→X，则称X传递Z。注:如果Y→X，即X←→Y，则Z直接依赖于X。例：在关系病房计费表（病人号，床位号，费用）中，规定此表只用于存放当前病人所在病床费用信息。显然，该表的主码是“病人号”，病人所住的“床位号”依赖于“病人号”，而不同的床位有不同的价格，也就是说病人号→床位号、床位号→费用，此时“费用”便传递依赖于“病人号”。码定义5.4设K为关系模式RU,F中的属性或属性组合。若KｆU，则K称为R的一个侯选码（CandidateKey）。若关系模式R有多个候选码，则选定其中的一个做为主码（Primarykey）。主属性与非主属性ALLKEY外部码定义5.5关系模式RU，F中属性或属性组X并非R的码，但X是另一个关系模式的码，则称X是R的外部码（Foreignkey）也称外码主码和外部码一起提供了表示关系间联系的手段。讨论函数依赖的必要性例：假设有描述病人信息及就诊情况的关系模式如下：P-D（病人号，姓名，性别，年龄，医生号，职称，就诊时间，科室，科室位置）关系模式的主码为（病人号，医生号，就诊时间）讨论函数依赖的必要性（续）语义：⒈一个病人可以找不同的医生看病，一个医生可以诊治不同的病人，但是一个病人一天对同一个医生只能就诊一次；⒉一个医生属于一个科室；⒊每个科室有固定的位置；关系模式P-DU,F中存在的问题⒈数据冗余太大浪费大量的存储空间例：每一个病人的信息重复出现⒉更新异常（UpdateAnomalies）数据冗余，更新数据时，维护数据完整性代价大。例：某一个医生调离的原先的科室，那么不但要修改此医生的科室属性值，而且还要修改科室位置值关系模式P-DU,F中存在的问题⒊插入异常（InsertionAnomalies）该插的数据插不进去例，如果成立一个新的科室，尚无病人，我们就无法把这个科室及其位置的信息存入数据库。⒋删除异常（DeletionAnomalies）不该删除的数据不得不删例，如果一个医生离职了，那么就要删除医生的信息，恰巧有病人只在这个医生这里看过病，那么删除医生信息的同时也把病人的信息一起删除了数据依赖对关系模式的影响（续）结论：P-D关系模式不是一个好的模式。“好”的模式：不会发生插入异常、删除异常、更新异常，数据冗余应尽可能少。原因：由存在于模式中的某些数据依赖引起的解决方法：通过分解关系模式来消除其中不合适的数据依赖。5.1.2范式范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。范式的种类：第一范式(1NF)第二范式(2NF)第三范式(3NF)BC范式(BCNF)第四范式(4NF)第五范式(5NF)5.1.2范式各种范式之间存在联系：某一关系模式R为第n范式，可简记为R∈nNFNF5NF4BCNFNF3NF2NF15.2规范化第一范式第二范式第三范式BC范式1NF定义5.6如果关系RU，F中每一个属性均是原子项（即每一个属性的域都只包含单一的值），则称R属于第一范式（1NF）。第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库但是满足第一范式的关系模式并不一定是一个好的关系模式。1NF科室各职称人数普通医师副主任医师主任医师骨科342皮肤科431五官科432儿科3222NF2NF的定义定义5.7若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于R的码，则R∈2NF。前面所示的P-D（病人号，姓名，性别，年龄，医生号，职称，就诊时间，科室，科室位置）就不是一个第二范式关系。2NF其函数依赖关系为：病人号→姓名，病人号→性别，病人号→年龄，医生号→职称，医生号→科室，科室→科室位置，……关系模式的主码为（病人号，医生号，就诊时间），那么就存在：（病人号，医生号，就诊时间）P姓名；（病人号，医生号，就诊时间）P职称，……即存在非主属性对主码的部分函数依赖关系，前文介绍了这个关系存在一些异常操作，而这些操作异常产生的一个原因就是因为存在部分函数依赖。2NF（续）可以用模式投影分解的办法将非第二范式的关系模式分解为多个第二范式的关系模式。去掉部分函数依赖关系的分解过程为：首先，用组成主码的属性集合的每一个子集，用它作为主码构成一个关系模式。然后，将依赖于这些主码的属性放置到相应的关系模式中。最后，去掉只由主码的子集构成的关系模式。2NF（续）对P-D（病人号，姓名，性别，年龄，医生号，职称，就诊时间，科室，科室位置），首先分解为如下形式的七个关系模式：（病人号，…）（医生号，…）（就诊时间，…）（病人号，医生号，…）（病人号，就诊时间，…）（医生号，就诊时间，…）（病人号，医生号，就诊时间，…）2NF（续）然后，将依赖于这些主码的属性放置到相应的表中，形成如下七个关系模式：P（病人号，姓名，性别，年龄）D（医生号，职称，科室，科室位置）T（就诊时间，…）PD（病人号，医生号，…）PT（病人号，就诊时间，…）DT（医生号，就诊时间，…）PDT（病人号，医生号，就诊时间，…）2NF（续）最后，去掉只由主码的子集构成的关系模式，也就是去掉T（就诊时间，…）、PD（病人号，医生号，…）、PT（病人号，就诊时间，…）、DT（医生号，就诊时间，…）关系模式。P-D关系模式最终分解的形式为：P（病人号，姓名，性别，年龄）D（医生号，职称，科室，科室位置）PDT（病人号，医生号，就诊时间）2NF（续）函数依赖图：2NF（续）对分解后对得到的关系模式进行分析。P（病人号，姓名，性别，年龄）关系模式，这个关系模式的主码是“病人号”，只有一个属性，并且姓名、性别、年龄均完全函数依赖于主码，因此P关系模式属于第二范式。D（医生号，职称，科室，科室位置）关系模式，这个关系模式的主码是“医生号”，只有一个属性，并且职称、科室，科室位置均完全函数依赖于主码，因此D关系模式属于第二范式。PDT（病人号，医生号，就诊时间）关系模式，这个关系模式的主码是（病人号，医生号，就诊时间）即全码，因此PDT关系模式也属于第二范式。2NF（续）采用投影分解法将一个1NF的关系分解为多个2NF的关系，可以在一定程度上减轻原1NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。并不能完全消除关系模式中的各种异常情况和数据冗余。第二范式的关系模式可能还不是最优模式，因此还需要对此关系模式进一步进行分解。3NF3NF的定义定义5.8关系模式RU，F中若不存在这样的码X、属性组Y及非主属性Z（ZY）,使得X→Y，Y→X，Y→Z，成立，则称RU，F∈3NF。若R∈3NF，则R的每一个非主属性既不部分函数依赖于候选码也不传递函数依赖于候选码。如果R∈3NF，则R也是2NF。3NF（续）关系模式P没有传递依赖，而关系模式D因为有：医生号→科室，科室→科室位置，得到科室位置传递依赖于医生号，从前面分析可知，当关系模式中存在传递函数依赖时，这个关系模式仍然有操作异常，因此关系模式P∈3NF，而关系模式D∈3NF，对于D还需要进行进一步分解，使其成为3NF关系。3NF（续）去掉传递函数依赖关系的分解过程为：对于不是候选码的每个决定因子，从关系模式中删去依赖于它的所有属性新建一个关系模式，新关系模式中包含在原关系模式中所有依赖于该决定因子的属性将决定因子作为新关系模式的主码3NF（续）D分解后的关系模式为：D-A(医生号，职称，科室)，主码为医生号。D-O(科室，科室位置)，主码为科室。对D-A，有：医生号→职称，医生号→科室，因此D-A是3NF。对D-O，有：科室→科室位置，因此D-O也是3NF。3NF（续）由于模式投影分解之后，使原来在一个关系模式中表达的信息被分解在多个关系模式中，因此，为了能够表达分解之前的关系的语义，在分解完之后除了要标识主码之外，还要标识相应的外码。采用投影分解法将一个2NF的关系分解为多个3NF的关系，可以在一定程度上解决原2NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。将一个2NF关系分解为多个3NF的关系后，并不能完全消除关系模式中的各种异常情况和数据冗余。BC范式（BCNF）定义5.9设关系模式RU，F∈1NF，如果对于R的每个函数依赖X→Y，若Y不属于X，则X必含有候选码，那么R∈BCNF。若R∈BCNF每一个决定属性集（因素）都包含（候选）码R中的所有属性（主，非主属性）都完全函数依赖于码R∈3NF（证明）若R∈3NF则R不一定∈BCNFBCNF的关系模式所具有的性质所有非主属性都完全函数依赖于每个候选码所有主属性都完全函数依赖于每个不包含它的候选码没有任何属性完全函数依赖于非码的任何一组属性BCNF例：关系模式R（CITY，DISTRICT，ZIP），三个属性分别代表“城市”、“区”和“邮政编码”。假定有依赖关系集{（CITY，DISTRICT）→ZIP，ZIP→CITY}，显然，