假设您已经安装好Power Designer 9.5 版本，如果您还没有获得软件，请到Sybase网站下载试用版本 。

定义更复杂的关系
使用依赖关系(Dependent)
还是使用上面的例子，我们假定这样的业务描述：雇员享有假期，雇员每次休假，需要记录雇员休假的起始日与结束日，假期以天为单位，一个雇员和一个开 始日唯一确定一个假期。根据这个业务描述，我们知道，对于假期而言，其必须依存于实体“Employee”而存在，即一个休假，必定有一个主体雇员。我们 在上一个模型的基础之上，添加一个实体，名称是“Holiday”，定义假期的属性开始日与结束日，这里并不需要重复定义一个雇员编号，而是替代的，使用 依赖关系，来表示实体“Holiday”依赖于实体“Employee”，关系定义如下图：

在实体“Holiday”中，我们需要设置开始日为主键标识符，开始日与其依赖实体中的雇员编号一起作为实体“Holiday”的标识符，用来唯一确定一个假期。这种依赖关系在概念图中表现如下：

从途中可以看出，在实体“Holiday”一端多了一个朝外的三角▲箭头，这个含义就是这个实体“的依赖于三角箭头所指的另外一个实体，在转化出来 的物理模型当中，实体“Employee”的empNo，在Holiday实体中不仅会作为一个外键，还同时会作为主键出现（与startData一起作 为复合主键）。

使用Dominant role
当两个实体之间的关系是1..1 时（尽管这种关系比较少见，常见于面向对象的设计方法当中，依赖实体中的主键通常与外健重合），你需要明确指定这两个实体，哪一个是父实体，哪一个是依赖实体，否则，系统在由概念模型转化为物理模型时，将不能确定需要在哪一端生成外键，这时就需要用到“Dominant role”选项，这个选项只有在1..1 的关系中才允许进行设置。我们假定这样的业务描述，企业中的部分雇员拥有一个系统帐号，并且是唯一的一个帐号，这些雇员需要保存一些额外的信息，比如帐号名称、密码等等。我们添加了一个新的实体“User”，其与雇员之间为1..1 的关系，由于一个用户帐号必定属于一个雇员，而一个雇员则可能没有用户帐号，所以我们定义实体“Employee”支配实体“User”。同时，由于 “User”依赖于“Employee”而存在，所以再定义一个由前者到后者的依赖关系，如下图：

Dominant role 选项中，箭头所指的实体为被支配的实体，即作为依赖实体。在模型图中，支配实体的一方会出现一个用圆括号括起来的大写字母“D”。

转化出来的物理模型中，表User中，empNo作为单独的主键，同时也是引用Employee表的一个外键。

处理多对多(n..n)的关系
在概念模型中，一般很少看见两个实体之间是直接的n..n 的关系，一般这种情况下我们会增加一个中间实体，在Power Designer中，提供了一个专门的符号来对应，叫做“Association”。请考虑以下的情形：

企业中拥有帐号的雇员在系统中具有不同的操作权限，这通过用户角色来进行管理，权限已经分配给了多个不同的角色，一个用户帐号至少属于一个角色，并 且可能会同时属于多个角色，一个角色可以包含0个或多个用户帐号。根据以上描述，我们添加一个实体“Role”，它与实体“User”之间是n..n 的关系，为了表达这种关系，我们增加一个“Association”并分别使用“Association Link”与其他两个实体建立关系，表示如下：

使用一个普通的实体，合理定义关系，并选择“Dependent”选项，是可以替代“Association”的，但使用 “Association”更方便、直观，使模型更容易理解，并可以减少因不谨慎而可能导致的错误。

下载本文示例中所使用的概念模型文件
本文内容以及模型文件基于Sybase Power Designer 9.5 版本，您可以到 Sybase中国网站免费下载最新的 PowerDesigner10 试用版本，以及 PowerDesigner10的技术文档。
《Database Solution－A Step by Step Guide to Building Database》by Thomas M.Connolly, Carolyn E.Begg, 译者: 何玉洁，梁琦等