ER图中三元联系

       软考的下午题里，第二道大题是画ER图，对于二元联系大家都比较熟练了，但是对于三元联系大家可能还有些迷惑，我来给大家论述一下。

        那么，在画ER图时，何时给两个实体建立联系，何时给三个实体建立联系？

        个人经验：如果在这道题的论述里，在同一句话中，同时涉及两个实体，并且，后面紧接着论述这两个实体之间的关系，这就要建立二元联系了。同理，在同一句话中，同时涉及三个实体，并且，后面紧接着论述这三个实体之间的关系，这就要建立三元联系了，这里着重讲解三元联系之间多重度的确定。

       这里，先用一句话来阐述多重度的确定规则。不论是二元联系，三元联系，还是n元联系。如果要确定某一段实体的多重度，就令其它各端实体的多重度的值为1.这就是多重度的确定规则，记住这句话就可以了，简单吧。

下面看看它的具体阐述吧。

三元关系（Ternary Relationships）

当通过二元关系无法准确描述三个实体间的联系时，我们需要使用三元关系。

三元关系中“连通数”的确定方法：

a) 以三元关系中的一个实体作为中心，假设另两个实体都只有一个实例

b) 若中心实体只有一个实例能与另两个实体的一个实例进行关联，则中心实体的连通数为“一”

c) 若中心实体有多于一个实例能与另两个实体实例进行关联，则中心实体的连通数为“多”

注：什么时候需要使用三元关系的实例请参看：数据库设计 Step by Step (3)中的“关系的度（Degree of a Relationship）”小节。关系的“连通数”概念请参看：数据库设计 Step by Step (3)中的“关系的连通数（Connectivity of a Relationship）”小节。

我们来看几个三元关系的实例，注意各个图中关系的度，并理解其中的语义。

图4  技术员在项目中使用手册的关系

图4中蕴含的语义为：

a) 一名技术员对于每一个项目使用一本手册

b) 每一本手册对于每一个项目属于一名技术员

c) 一名技术员可能在做多个项目，对于不同的项目维护不同的手册

用数学中的函数依赖表示图4的关系：

a) emp-id, project-name -> notebook-no

b) emp-id, notebook-no -> project-name

c) project-name, notebook-no -> emp-id

图5  员工被分配不同地点的项目之间的关系

图5中蕴含的语义为：

a) 每一个员工在一个地点只能被分配一个项目，但可以在不同地点做不同的项目

b) 在一个特定的地点，一个员工只能做一个项目

c) 在一个特定的地点，一个项目可以由多个员工来做

用数学中的函数依赖表示图5的关系：

a) emp-id, loc-name -> project-name

b) emp-id, project-name -> loc-name

图6  经理管理项目与工程师的关系

图6中蕴含的语义为：

a) 一名经理手下的一名工程师可能参与多个项目

b) 一名经理管理的一个项目可能会有多名工程师

c) 做某一个项目的一名工程师只会有一名经理

用数学中的函数依赖表示图6的关系：

a) project-name, emp-id -> mgr-id

图7  员工在项目中使用技能的关系

图7中蕴含的语义为：

a) 一名员工在一个项目中可以使用多种技能

b) 一名员工的一种技能可以在多个项目中使用

c) 一种技能在一个项目中可以被多名员工使用

图7各实体之间没有函数依赖

上述4种形式的三元关系，连通数为“一”的实体数量与该三元关系反映的函数依赖语义的数目一致。

三元关系也能有属性。属性值由三个实体的键的组合唯一确定。

 

n元关系（General n-ary Relationships）

三元关系可以扩展到n元关系，描述n个实体之间的关系。

一般而言，n元关系中每一个连通数为“一”的实体的键都会出现在一个函数依赖表达式的右侧。

对于n元关系，使用语言来表达其中的约束相对较为困难。建议使用数学形式即函数依赖（FD）来表现。

n元关系的函数依赖条目数量与关系图中“一”端实体的数量相同（0～n条）。

n元关系的函数依赖表达式包含n个元素，n-1个元素出现在表达式左侧，1个元素出现在右侧。

图8  n元关系图例