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

这是同层的实体表是不能将标识关系属性设为主键的，所以不会发生创建过程中的死锁问题。然后在建立平行关系中的这种象PIPEHOLE类型的实体表。这时虽然它的主键设置即有从属关系的分段式编码，又有标识关系的属性，但是不会发生问题了，因为这时上下层的实体关系模块已经建立。 还有一种关系是递归关系。也就是某张实体表中可能存在自身对自身的关系，我们看一个在机架管理子系统中的例子：即局站实体表。 ● 局站号 交换局局站号 因为一个主局站可以包含4种类型的局站，而这其他的四种局站一般是属于某个主局站的。所以在这个实体表中，我们要设置一个内容上与主属性同一性质的属性来与自身发生联系。在局站的例子中，该外键名取为交换局名。5．1．4 连接关系和交叉关系 这里分析的两种关系在性质上是有共性的，也就是不论是同一层次的实体间的连接关系还是不同层次间的交叉连接关系。它们的主属性 或关键字 都是若干个实体关系的主属性的组合。这种组合本身作为一个实体关系而存在。它也有它的属性，例如电缆线对之间的连接，端子之间以及管道之间的连接关系，都形成了一个有序或无序的组合，这种组合关系应该从实体关系中分开，即进行投影分解。 如果我们仍然将连接或交叉关系与个层次的实体合并到一起，会有什么样的结果呢 I．连接关系或交叉关系中的属性是由实体间的主属性组合来共同决定的。

如果我们 将它也并在各层实体的属性中，因为连接本身作为一种实体有它子集的属性，而这中 属性是由多个实体的主属性的组合连决定的，所合并后的实体表的主键应该也是这种 主属性的组合。比如在管道．井的连接表如果并入井的实体表后，主键应是： PIPE_PATHNUM；WELL--NUM；PIPE_NUMl；PIPE_NUM2。 这里后两个主属性是WELL所连接的两个管道的主键编码。这样一来，原来的井 的实体表中的属性实际上只由上述主键中的一部分唯一决定，所以会出现不符合第二 范式的情况。这与我们规范设计关系是不符的。所以应当将这种连接关系的属 性独立分解出来，形成单独的实体关系。 37 2．有一种特殊的极端情况，即连接本身是实体间的l对l的芙系，这时能否将连接 关系和实体本身的关系模式合并在一起呢 比如电缆子系统中，电缆线对之间有一个连接的关系，但是这种连接关系是1对1 的连接，所以我们在建立电缆线对连接实体表时，就可以仅将连接的某一方的主属性 作为连接表的主属性： Cable_Connect实体表 Code子缆代码 C—Cable c—Line—Num子缆线对号 MCableCode母缆代码 MLineNum母缆线对号 那么这张连接表与电缆线对的实体表的主键设置是一样的，是不是能够将连接表和电缆线对实体表合并成一张表呢 我认为在这里虽然这种连接关系是1对1的，但是实际上连接的属性还是不能简单地理解为被某一方的连接实体为确定，事实上还应该由连接双方的主属性组合所唯一确定的．因为在连接关系确定之间，仅仅由连接的单方并不能确定它所连接的另一方实体是什么，所以也更不能确定连接实体关系的属性。

因此这里的主键确定是因为有l对1的关系，所以为了使得主键定义更简化，才只选定连接的一方作为主属性，但是这并不意味着可以由此将连接关系和实体本身相结合。如果采取这种方案，那么势必会引发一些数据操作上的问题： 电缆连接表 c_cable_Code子缆代码 Num于缆线对号 C—Line lU缆线对非土属性 M—Cable_Code母缆代码 M—Line_Num母缆线对号 线对连接非主属性 1．一方面子缆信息在这里应该和所有的电缆线对信息一致。也就是说有多少电缆线 对，就同时应该有多少子缆连接信息，而这里连接关系由于是1对1的，所以实 际上这种连接关系只要有连接关系的一方 即子缆 作为主键的元组来反映就可 以，所以这里如果采取合并成一个实体关系表就会增加信息量，造成数据的冗余。 2．因为实际上电缆线对的连接属性还是依赖于子缆和母缆的组合信息，所以在上述 的合并表中仍然存在。类似传递函数依赖的现象。这会带来以下的问题：当我们 要删除某一个电缆连接关系时，实际上就要将子缆的信息也删除掉，这是不合理 的。也就是说，如果采取这种方式，同样会带来因为违反了第三范式而产生的问 题。 实际上，连接关系和交叉关系这两种组合关系作为实际存在的一类实体关系有必要作为一种与实体关系本身相独立的关系而存在。

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