PowerDesigner概念模型实体关系说明

在PowerDesigner的概念模型中，实体之间的关系是非常重要的，也决定了从概念模型转化到物理模型时的表现形式，所以有必须深究其中的相关设置。做数据库重要的就是表与表之间的关系，而这个关系是连接所有数据库系统的纽带，所以即使我们不用PD，也应该重视表与表之间的关系。这也是关系型数据库的由来。

PD中的表与表之间的关系有四种，分别是one-one(一对一)，one-many(一对多)，many-one（多对一），many-many（多对多）。在实际中使用得最多的只有前面两种，而多对一和一对多其实没有什么区别，只是二者关系的反向描述，所以其可以看成是一种类型。而多对多在实际的数据库设计中也是时有出现的，这种情况下，我们一般不直接处理多对多的关系，而是通过一种技巧，将多对多转化为多对一，和一对多的关系，这样可以简化数据库关系的复杂性。将多对多转化为多对一，再一对多意思是通过提供一个关联关系表，来使多对多的关系表与该关联关系表发生关系，而不让其直接发生多对多的关系，这样就可以简化这样的关系。前面文章中已经说明如何创建这种关联表了。这里也就不再说多对多的关系。后面只重点说明一对一，一对多的关系。

在CDM中，实体之间的关系更符合现实情况一些，以一对多的关系来说，如果一个实体对应多个实体，通常含有“包含，拥有”等这样的意思在里面。比如一个部门拥有多个员工，一个企业拥有多个部门等。而如果多个实体对应一个实体，则通常含有“属于，包含于”等这样的意思。比如多个员工属于一个部门，多个部门包含于一个企业等。在PDM中就很具体了，且与实际的有些区别了，这主要是由于在软件的实现角度上的体现，比如一对多的关系，比如T1与T2的关系为T1一对多个T2，在PDM中，通常表现在T2中有一个外键，用来存储T1的主键，这样就叫一对多，而这样的表现与实际上具有一定的差别。当然这是没有什么问题的，因为PDM才是我们真正在软件实现时所采用的方式。我只是想说的是CDM中这种关系的描述，可能更和实际情况接近一些，也就更加容易明白一点。

好了，下面分别说明一下一对多和一对一的关系详细说明：

1.对于一对多的说明

当两个实体需要进行一对多的关联时（比如T1与T2的关系为T1一对多个T2，T1和T2为两个实体），我们通过Relationship，从T1拉至T2时，二者关系就建立起来了。默认情况下就是个一对多的关系，即T1为1，T2为多。

双击拉的关系线，则弹出二者关系描述的对话框，我们就可以在这个弹出的属性对话框里进行我们所需要的设置了。在弹出来的默认属性为General属性选项。我们可以在这个属性页里面修改关系名称以及对这个关系的描述等。点击Cardinalities属性页，在上面默认显示的就是一对多的关系，我们现在是描述一对多的关系，所以不修改它。在关系下面有个Dominant role，这个右边有个下拉框，不过是被置灰了，不可操作，这里先不管，后面在说一对一时再说说这里。

在T1 to T2的内容里面，有个Role name，在其右边有个输入框，可以输入T1表的角色名字，这里就可以用前面提到的比如“拥有，包含”等这样的内容，可以用来说明T1表的职能。在Role name下面的Dependent默认是置成灰色，意即不可操作，这里我们就不管了。然后是Mandatory，这个是什么意思呢？这个是否选择决定了某个东西是否为空。是什么东西呢？指的是和本实体发生关系的对方实体的主键在本实体的外键字段是否为空。比如现在有种情况是T1中某个字段，如par1，该字段为外键，它将存储T2中的主键，则如果Mandatory被选中，则par1不为空，意即它必须存储某一个T2的值，而如果不选上，则表示该字段值可以为空。在现在的情况下T1与T2是一对多的关系，我们知道在PDM中，出现的情况是T2中会生成一个外键，用来存储T1表的主键，而T1表不会有任何字段来存储T2的主键 ，所以这个Mandatory是否被选择上，不会对关系造成任何影响，所以这里我们就不用管它了。当然，我们从实际的描述中，可以这样来说明这个值的选取相关的情况，比如现在T1指的是部门，而T2指的是员工，当你选择了该值，则在后面的Cardinality中会变成1,n，即如果选择这个值，则表示一个部门至少有一个员工，而如果不选，则表示一个部门至少有0至n个员工，就这个区别，因为为一对多，T1表中不会存储T2表中的主键，即使你选择了Cardinality，用于说明是部门至少含有1个员工，但是，T2表此时仍为空，没有任何员工，也不会出现问题的（这是因为一对多这个关系，导致T1表中不会有T2的任何相关信息造成的，当然在一对一的关系中，则不一样的，后面会说到）。

现在再说说T2到T1的内容里面的东西，其中的role name仍可以加入你所描述的T2的角色职责，比如“属于，包含于”等。在其下面，我们发现Dependent没有置灰了，是可以勾选的。我们先不管它，先趁热把Mandatory再说清楚点，此时由于我们已经知道T2表中会含有T1的主键的了，因为一对多的关系，则在生成的T2表时，会生成一个外键，用来单独存储T1的主键的，现在有个问题出现了，就是T2的存在是否依赖于T1，即说白一点就是一个员工是否一定要属于某一个部门？如果你的数据库系统中要求一定属于，那么你就把Mandatory选择上。反之，如果你认为新来的员工还没有分配好部门，可以暂时不让其属于某一个部门，到后面在人为的选择某一个部门，那么你就可以不用选择上Mandatory了。Cardinality会根据你是否选择Mandatory来决定其值是0,1还是1,1，意思很明确，就是是否T2一定属于T1，即一个员工是否一定属于一个部门。为这进一步确认Mandatory是否选中对PDM的实际表现造成的影响，可以通过CDM转化为PDM，查看其中的外键字段是否允许为空就可以明确了，如果你选择了Mandatory，则在PDM中T2生成的外键中将不允许为空，即必须含有T1的某一主键，而如果不选择Mandatory，则在PDM中T2生成的外键是可以允许为空的。

好了，现在来说说Dependent的意思，如果其不选，则没有什么变化，如果其被选择中了，则会在PDM中对T2中生成的用于存储T1主键的那个外键（FK）将会成为T2的另外一个主键，这就是这个值的意思，如果你不需要T2中的外键同时成为主键，则不用选择该值。通常情况下，都不需要选择这个。

2.一对一的关系说明

在两个实体表中的关系中，如果一个表和另一个表是一对一的关系，这种一对一的关系有两种形式，以T1表和T2表为例。一种是T1中有个字段（外键）是T2表的主键，T2中有一个字段（外键）是T1表的主键，另一种情况是只有其中的一个表含有另一个表的主键，而另一个表不含有前一个表的主键。前面说的第一种情形是指两个实体互相感知，互相拥有对方的信息，另一种情况是指二者含有一定的依赖关系。某一个实体的存在依赖于另一个实体的存在。

相对来说，在软件领域中，第二种情形更常见一些，完全平等的两个实体在现实中存在的意义不大，毕竟社会是一个充满着各种联系的实体，实体之间存在的着一定的依赖关系，就象孩子依赖于父母，员工依赖于企业，当然存在着两个互相感知的实体，这样带来的一个好处是在查询时非常迅速。下面说一下一对一关系的某些属性的改变带来的变化。

当T1和T2实体建立好了关系之后，正如前面所言，默认情况下是个一对多的关系，我们这次就要改变这种关系了。在关系线的属性中，在Cardinalities属性页，我们将one-many修改为one-one，当我们选中one-one后，下面的Dominant role由原来的置灰不可操作状态变为可操作状态了。Dominant role的意思是占支配地位的角色，在其右边的下拉框中默认值为none，这里要求我们选择的是两个实体，谁占支配地位，谁占被支配地位。即谁支配谁。默认值中的none表示二者双方都不占支配地位，意即二者地位平等，则就是前面所述的第一种情况，即二者互相感知。这种情况下，在PDM中会发现T1表和T2表中都会生成一个外键，用于存储对方的主键。而下面的Dependent和Mandatory和前面描述一对多的关系时表现是一样的。这里就不再赘述了，只是需要注意的一点是如果你的关系是二者互相平等的话，在选择Mandatory中，不要将T1和T2都同时选择上，不然就会出现互斥现象，永远不成立。

现在我重点说一下关于第二种情形，现在假设我们需要T2中的外键来存储T1的主键，那么这种情况下谁是支配地位的角色呢？在Dominant role中是选择T1->T2还是T2->T1呢？在->前面的是支配地位，后面的是被支配地位。想一下，为什么T2需要用一个外键来存储T1的主键呢？是因为T2需要T1的信息，需要T1来支持T2的存在，即T2依赖于T1，则说明T1应该是支配地位角色，那么在Dominant role项中，我们就需要选择T1->T2。明白了这个，就明白了为什么在一对多的关系里，这个Dominant role是置灰的呢？原因很简单，不需要我们指定这种支配角色，因为一对多的关系中，为一的那个必定是支配地位的角色，不需要我们改变。

好了，关于实体之间的关系就结束了。如果你不是很确定关系的选项对后来的PDM造成的影响，你可以通过试验，通过简单的两个实体表，从CDM转化为PDM，实际看一下二者关系的表现，就明确了，这是我在实际的使用过程中，所用的方法。