关系是通过什么来实现关系之间的关联的_关系一个关系_关系中实现实体(10)

另外如果要修改某一供应商的城市值，通常需要修该多个元组，这就容易产生不一致。例如供应商s1从LoNDON迁移到AMsTERD埘，就需要修改多个元组。这里的原冈是该关系中将CITY属性和s1编在一个实体关系中，这样就造成每一个CITY信息都与s1对应起来．所以当修改CITY信息时，就要求修改多条元组。 上述的种种弊端，是因为在定义实体关系模式时，没有作合理的投影分解，将许多相关的属性编在同一个关系模式中，造成在属性中有非关键字非完全依赖于主键字属性，比如在上述例子中的CITY属性就非完全依赖于主关键字 S#，P莓 ，这样就造成上述的问题。 所以我们可以根据第二范式的概念对原来的实体的关系模型作如下的改进：把原QTY ，这样处理的结果，克服了s#和cITY存储操作中的问题。因为我们现在就可以把供销商的在某个城市的信息直接插入到SECONG关系中，即使这个供销商并没有提供任何生产零件。真正的原因是我们将原来的关系模式中的关键字作了合理的分解，即将原来的违反第二范式的关系模式分解为两个关系，使得非主属性与关键字之间没有了非完全依赖关系。 按照定义，如果一个关系是第一范式。而不是第二范式。那么经过适当的投影分解，总可以将它投影化为一组等价的第二范式的关系模式集合。

这种投影后的关系等价于原来的关系，即原来的关系能够通过这些投影关系的适当连接而恢复。 而且这种分解过程不会丢失信息，所以原关系中的任何信息都能从这个新的关系中导出，但新的关系中包含了原关系中无法表示的某种信息。例如在上述的例子中，供廊商位于某个城市的信息实际上是作为一个新的信息存在的，这种信息在原来的关系模式中是不能提供的。所以说，经过适当的投影分解过程之后，新的关系模式更能准确地反映这个客观世界。 但是实际上上述的例子中经过分解后的第二范式的关系模式中SECOND在存储操作上还是存在异常的现象，比如我们并不能够将某一个城市具有某～状态的信息存进SECOND实体表中，当然在不知道某供应商在某一城市的前提之下。原因和上面第一范式的是一样的，即都是没有适当的关键字值。在删除操作中，例如我们删去了SECOND关系中关键字为某一供应商的元组，则实际上我们也就失去了一类关键字为该供应商的所有的某个城市为某种状态的信息。又比如如果要将某一个城市具有某一种状态的信息进行修改，那么需要作修改的元组就不止一个，因为很可能有很多供应商都在该城市里，这样我们对所有的包含这个城市的元组都要进行修改，否则就会出现数据的不一致了。

那么出现上述问题的原因实际上是SECOND实体表中属性STATUS关于属性s#的依赖性，它具有传递性，实际上是因为CITY属性的传递作用而造成的。即s#—氅ITY，CITY嘲TATUS。 为了解决这个问题，我们再将关系模式SECOND投影分解成两个关系模式。即sc S t，CITY ，和产生CS CITY，STATUS ，即： 通过上述的分解过程后，就达到了消除非主关键字传递依赖于关键字属性。 3NF 如果关系模式R是第二范式，并且每个非关键字的属性，不是传递依赖于关键字，则称关系模式为第三范式。 这个范式定义的提出，就可以避免上述例子中出现的问题。 值得提出的是：我们所讨论关系模式的规范化级别，是一个语义方面的问题，不能只从某一特定时间关系的值来看，因此的设计者必须清楚了解数据的意义和语义，才能讨论它的规范化。 这里再顺便介绍一下BCNF和4NF的概念： BCNF：若关系模式R中的每个决定因素，是R的一个候选关键字，则称关系模式R是BCNF。 这里决定因素的定义是：关系模式R，x和Y是属性集的两个子集，且x和Y无公共属性，Y完全函数依赖于X，那么称x为R的决定因素。 4NF：在一个规范化关系中，如果存在一个多值依赖，例如 H卜+Y，而且R的其他所有属性都函数依赖于X，那么R就是第四范式。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-37192-10.html