第六章关系数据库设计理论

第6章关系数据库设计理论本章要点1．深入理解函数依赖和键码的概念。学会计算属性的封闭集。2．模式设计是本章的重点。了解数据冗余和更新异常产生的根源；理解关系模式规范化的途径；准确理解第一范式、第二范式、第三范式和BC范式的含义、联系与区别；深入理解模式分解的原则；熟练掌握模式分解的方法，能正确而熟练的将一个关系模式分解成属于第三范式或BC范式的模式。3.了解多值依赖和第四范式的概念，掌握把关系模式分解成属于第四范式的模式的方法。•学生关系Student的实例如下：•SnoSNSDMNCNG•99230贺小华计算机周光OS96•99239金谦计算机周光OS90•99239金谦计算机周光编译92•99851陈刚建筑王勇建筑89•SnoSN•SnoSD•SDMN•SnoCNG6.1函数依赖——6.1.1定义•如果关系R的两个元组在属性A1，A2，…An上一致（也就是，两个元组在这些属性所对应的各个分量具有相同的值），则它们在另一个属性B上也一致。那么就说在关系R中属性B函数依赖于属性A1A2…An。A1A2…AnB，“A1，A2，…，An函数决定B”。A1A2…An称为决定因素。6.1.2关系的键码如一个或多个属性的集合{A1，…，An}满足如下条件，称该集合为关系R的键码：1．这些属性函数决定该关系的所有其它属性。2.{A1，…，An}的任何真子集都不能函数决定R的所有其它属性，键码必须是最小的。6.1.3超键码包含键码的属性集称为“超键码”。因此，每个键码都是超键码。某些超键码不是（最小的）键码。每个超键码都满足键码的第一个条件：函数决定它所在的关系的所有其它属性。超键码不必满足键码的第二个条件：最小化条件。6.1.4函数依赖规则分解/合并规则可以把每个函数依赖右边的属性分解，从而使其右边只出现一个属性。也可以把左边相同的依赖的聚集用一个依赖来表示，该依赖的左边没变，而右边则为所有属性组成的一个属性集。两种情况下，新的依赖集都等价于旧的依赖集。平凡依赖规则对于函数依赖A1A2…AnB来说，如果B是A中的某一个，就称之为“平凡的”。对于函数依赖A1A2…AnB1B2…Bm，·如果B是A的子集，则称该依赖为平凡的。·如果B中至少有一个属性不在A中，则称该依赖为非平凡的。·如果B中没有一个属性在A中，则称该依赖为完全非平凡的。·函数依赖A1A2…AnB1B2…Bm等价于A1A2…AnC1C2…Ck，其中C是B的子集，但不在A中出现。我们称这个规则为“平凡依赖规则”。传递规则传递规则使我们能把两个函数依赖级联成一个新的函数依赖。·如果A1A2…AnB1B2…Bm和B1B2…BmC1C2…Ck，在关系R中成立，则A1A2…AnC1C2…Ck在R中也成立。这个规则就称为传递规则。6.1.5计算属性的封闭集假设{A1，A2，…，An}是属性集，记为A，S是函数依赖集。属性集A在依赖集S下的封闭集是这样的属性集X，它使得满足依赖集S中的所有依赖的每个关系也都满足AX。也就是说，A1A2…AnX是蕴含于S中的函数依赖。用{A1，…，An}+表示属性集A1…An的封闭集。允许出现平凡依赖，所以A1，…，An在{A1，…，An}+中。下面我们进一步理解封闭集的实际含义：对于给定的函数依赖集S，属性集A函数决定的属性的集合就是属性集A在依赖集S下的封闭集。学会计算某属性集的封闭集，还可以根据给定的函数依赖集推导蕴含于该依赖集的其他函数依赖。已知：关系模式R（A，B，C，D）函数依赖ABC，CD，DA求：蕴含于给定函数依赖的所有非平凡函数依赖。首先考虑各种属性组合的封闭集。然后，依次分析各属性集的封闭集，从中找出该属性集所具有的新的函数依赖。单属性：A+=A，B+=B，C+=ACD，D+=AD新依赖：CA（1）ABC，CD，DAABC，CD，DA双属性：AB+=ABCD，AC+=ACD，AD+=AD,BC+=ABCD，BD+=ABCD，CD+=ACD新依赖：ABDACDBCABDACDABCDBDC(7)三属性：ABC+=ABCD，ABD+=ABCD，ACD+=ACD，BCD+=ABCD新依赖：ABCDABDCBCDA(3)四属性：ABCD+=ABCD无新依赖_____键码（3）____超键码（4）6.2模式设计——6.2.1问题的提出•设计关系数据库模式时，特别是从面向对象的ODL设计或从E/R设计向关系数据库模式转换时，很容易出现的问题是冗余性，即一个事实在多个元组中重复。•造成冗余的最常见的原因是，企图把一个对象的单值和多值特性包含在一个关系中。当我们企图把太多的信息存放在一个关系时，就会出现数据冗余和更新异常等问题。主要表现如下：1．数据冗余。2．修改异常。3．删除异常。4．插入异常。6.2.2问题的根源•关系的键码函数决定该关系的所有其它属性。由于键码能唯一确定一个元组，所以关系的键码函数决定该关系的所有属性。一个关系中的所有属性都函数依赖于该关系的键码。不同的属性在关系模式中所处的地位和扮演的角色是不同的。把键码所在的属性称为主属性，而把键码属性以外的属性称为非主属性。•不同的属性对键码函数依赖的性质和程度是有差别的。有的属于直接依赖，有的属于间接依赖（通常称为传递依赖）。•当键码由多个属性组成时，有的属性函数依赖于整个键码属性集,有的属性只函数依赖于键码属性集中的一部分属性。·完全依赖与部分依赖对于函数依赖WA，如果存在VW（V是W的真子集）而函数依赖VA成立，则称A部分依赖于W；若不存在这种V，则称A完全依赖于W。当存在非主属性对键码部分依赖时，就会产生数据冗余和更新异常。非主属性对键码完全依赖，则不会出现类似问题。·传递依赖对于函数依赖XY，如果YX（X不函数依赖于Y）而函数依赖YZ成立，则称Z对X传递依赖。如果XY，且YX，则X，Y相互依赖，这时Z与X之间就不是传递依赖，而是直接依赖了。我们以前所讨论的函数依赖大多数是直接依赖。6.2.3解决的途径•部分依赖和传递依赖有一个共同之处，这就是，二者都不是基本的函数依赖，而都是导出的函数依赖：•部分依赖是以对键码的某个真子集的依赖为基础•传递依赖的基础则是通过中间属性联系在一起的两个函数依赖。•导出的函数依赖在描述属性之间的联系方面并没有比基本的函数依赖提供更多的信息。在一个函数依赖集中，导出的依赖相对于基本的依赖而言，虽然从形式上看多一种描述方式，但从本质上看，则完全是冗余的。•正是由于关系模式中存在对键码的这种冗余的依赖导致数据库中的数据冗余和更新异常。•解决的途径——消除关系模式中各属性对键码的冗余的依赖。•由于冗余的依赖有部分依赖与传递依赖之分，而属性又有主属性与非主属性之别，把解决的途径分为几个不同的级别，以属于第几范式来区别。范式是符合某种级别的关系模式的集合。主要有六种范式：第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。第一范式需满足的要求最低，在第一范式基础上满足进一步要求的为第二范式：1NF2NF3NFBCNF4NF5NF通过分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合称为规范化。第一范式（1NF）•如果一个关系模式R的所有属性都是不可分的基本数据项，则这个关系属于第一范式。•在任何一个关系数据库系统中，第一范式是对关系模式的一个最起码的要求。•不满足第一范式的数据库模式不能称为关系数据库。第二范式（2NF）–若关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码，则R属于第二范式。–第二范式就是不允许关系模式中的非主属性部分函数依赖于键码。•学生关系模式Student（Sno，Sname，Sdept，Mname，Cname，Grade）。•该关系模式存在如下部分依赖：Sno，CnameSname，Sdept，Mname显然不满足“每个非主属性都完全函数依赖于键码”的条件。所以学生关系模式不属于第二范式。P关系分解的含义•关系R的分解包括两个方面，一方面是把R的属性分开，以构成两个新的关系模式：另一方面是通过对R的元组进行投影而产生两个新的关系。分解的过程给定一个模式为{A1，A2，…，An}的关系R，我们可以把R分解为两个关系S和T，模式分别为{B1，B2，…，Bm}和{C1，C2，…，Ck}，使得：1．{A1，…，An}={B1，…，Bm}∪{C1，…，Ck}2．关系S中的元组是R的所有元组在{B1，…，Bm}上的投影。对于R的当前实例的每个元组t，取t在属性B1，B2，…，Bm上的分量。这些分量构成一个元组，它属于S的当前实例。3．类似地，关系T中的元组是R的当前实例中的元组在属性集{C1，C2，…，Ck}上的投影。第三范式（3NF）•若关系模式R属于第一范式，且每个非主属性都不传递依赖于键码，则R属于第三范式。•这里应说明一点：属于第三范式的关系模式必然属于第二范式。因为可以证明部分依赖蕴含着传递依赖。•关系模式•S1（Sno，Sname，Sdept，Mname）•由于存在传递依赖而不属第三范式.•S1分解成两个关系模式•S11（Sno，Sname，Sdept）S12（Sdept，Mname）BC范式（BCNF）•若关系模式R属于第一范式，且每个属性都不传递依赖于键码，则R属于BC范式。•通常BC范式的条件有多种等价的表述：每个非平凡依赖的左边必须包含键码；每个决定因素必须包含键码。•BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。满足BC范式的关系都必然满足第三范式。•关系模式STC（SN，TN，CN，G）SN，CNTN，GSN，TNCN，GTNCN键码为：{SN，CN}和{SN，TN}。关系模式STC分解成SC（SN，CN，G）ST（SN，TN）•关系模式STC的实例SNTNCNG杨紫兰文松程序设计90杨紫兰孙兰竹数据库88魏红孙兰竹数据库92魏红田梅程序设计86•分解后关系模式ST的实例如下:SNTN杨紫兰文松杨紫兰孙兰竹魏红孙兰竹魏红田梅SNCNG杨紫兰程序90杨紫兰数据库88魏红数据库92魏红程序86•ST和SC以SN为公共属性进行连接:•SNTNCNG（真/伪）•杨紫兰文松程序90√•杨紫兰文松数据库88ו杨紫兰孙兰竹程序90ו杨紫兰孙兰竹数据库88√6.2.4分解的原则主要涉及两个原则：·无损连接（LosslessJoin）如果对新的关系进行自然连接得到的元组的集合与原关系完全一致，则称为无损连接。无损连接反映了模式分解的数据等价原则。·保持依赖（PreserveDependency）如果分解后总的函数依赖集与原函数依赖集保持一致，则称为保持依赖。保持依赖反映了模式分解的依赖等价原则。依赖等价保证了分解后的模式与原有的模式在数据语义上的一致性。6.2.5分解的方法•关系模式分解的基础是键码和函数依赖。当我们对关系模式中属性之间的内在联系做了深入、准确的分析，确定了键码和函数依赖之后，模式分解因有章（规则）可循，有法（方法）可依而显得简单明了。模式分解的两个规则（1）·公共属性共享要把分解后的模式连接起来公共属性是基础。若分解时模式之间未保留公共属性，则只能通过笛卡尔积相连，导致元组数量膨胀，真实信息丢失，结果失去价值。保留公共属性，进行自然连接是分解后的模式实现无损连接的必要条件。·相关属性合一把以函数依赖的形式联系在一起的相关属性放在一个模式中，从而使原有的函数依赖得以保持。这是分解后的模式实现保持依赖的充分条件。然而，对于存在部分依赖或传递依赖的相关属性则不应放在一个模式中，因为这正是模式分解所要解决的问题。模式分解的三种方法•部分依赖归子集；完全依赖随键码。要使不属于第二范式的关系模式“升级”，就要消除非主属性对键码的部分依赖。解决的办法就是对原有模式进行分解。分解的关键在于：找出对键码部分依赖的非主属性所依赖的键码的真子集，把这个真子集与所有相应的非主属性组合成一个新的模式；对键码完全依赖的所有非主属性则与键码组合成另一个新模式。•学生选课SC（Sno，Sname，Ssex，Sage，Cno，Cname，Grade）•CnoCname•SnoSname