Dominant role，mandatory与dependent

1 PD 中的 CDM 阶段 ,ER 模型的三要素 :  实体型，属性和联系。

 

2  实体属性的使用

        2.1 General  项目  

               Name ：是用来在模型中标识一个实体，通常用于模型在界面中的显示（这个能够                   经过更改选项设置进行改变）。在一个模型当中，实体的名字不能重复。

               Code ：在模型转化时通常做为对象的物理名称，好比把实体属性的 Code 转化为数            据库中的列名，固然咱们如今没必要为了这个实体未来叫什么而费神，通常采起与                       Name 一致便可。

               Generate ：默认是选择状态，若是取消，则在转化为其余模型时，会忽略这个实体。  

        2.2 Attributes  项目

               M ：此属性不容许为空值  

               P ：此属性为主键标识  

               D ：为可显示属性

 

3 RelationShip 的相关参数使用

     3.1 Dominant role( 1 对1 )

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

 

　

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

 

　

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

3.2 mandatory( 1 对多或多对1)
   联系是否具备强制性，指的是实体间是否是必定会出现这种联系；或者换句话说，当咱们在谈及一个联系的应用场景的时候，联系对应的那两个实体型的实体实例的 个数可不可能为零。也许这样的解释仍是有点抽象，让咱们举两个联系的例子，一个是对两边的实体都有强制性的，另外一个则否则。
 （1 ）教师-- 学生 联系
   这个联系首先是一个多对多联系，由于每一个老师能够教多个学生，每一个学生也都有多个老师来负责他们的学业。同时，这个联系对教师和学生都是强制性的，也就是说，不存在任何一个老师，他不负责任何一个学生的教学；也不存在任何一个学生，他没有任何一个任课老师。
 （2 ）学生-- 俱乐部 联系
   这个联系也是一个多对多关系，但它对学生这个实体型而言就不是强制的（Optional, 可选的）。每一个俱乐部都有至少一个学生参加，但并非每一个学生都要去参加俱乐部的活动。彻底能够有一些学生，他们什么俱乐部都没参加。
 上面的例子主要是从概念的角度来区分了mandatory 和optional 的区别。实际上若是把这个模型对应到咱们最后生成的表，若是A-B 间的联系对 A 是mandatory 的话，那么若是在A 里面若是包含B 的外键，这个外键不能为空值，反之能够为空值。后面咱们谈到PDM 和实际数据库的时候，你们会看 到这一点。

3.3 Dependent (1 对多或多对1)

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

 

　

在实体“Holiday” 中，咱们须要设置开始日为主键标识符，开始日与其依赖实体中的雇员编号一块儿做为实体“Holiday” 的标识符，用来惟一肯定一个假期。这种依赖关系在概念图中表现以下：

 

　

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

   每个Entity 型都有本身的Identifier ，若是两个Entity 型之间发生关联时，其中一个Entity 型的Identifier 进入另外一个 Entity 型并与该 Entity 型中的Identifier 共同组成其Identifier 时，这种关联称为标定关联, 也叫依赖性关联(dependent relationship) 。一个Entity 型的Identifier 进入另外一个Entity 型后充当其非Identifier 时，这种关联称为非标定 关联, 也叫非依赖关联。
   概念的定义提及来仍是有些拗口，说白了其实就是主- 从表关系，从表要依赖于主表。
   对于依赖型联系，必须注意它不多是一个多对多联系，在这个联系中，必须有一个做为主体的实体型。一个dependent 联系的从实体能够没有本身的identifier.

3.4  多对多(n..n) 的关系

在概念模型中，通常不多看见两个实体之间是直接的n..n  的关系，通常这种状况下咱们会增长一个中间实体，在Power Designer 中，提供了一个专门的符号来对应，叫作“Association” 。请考虑如下的情形：

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

 

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

3.5 关系的取名

      通常最好为关系取一个贴切的名字，本例的业务关系描述以下：一个部门有多个员工，咱们使用“Has” 做为这个关系的名字。

一样的咱们 也能够描述为：多个员工属于一个部门，可不可使用“Belong to” 做为关系名字呢？通常不推荐这样作，在概念图中有一个约定，关系的名字采用从“1,n” 中“1” 所在的方向向“n” 所在一方进行读取的语义。本例即 “1” 在部门一方，从部门一方向雇员一方读取语义，即：部门有（Has ）多个员工。

---------------------------------------------------------

---------------------------------------------------------

从实用的角度来说，一对多和多对一没什么分别。这里你要注意的是，一对多实际上能够理解为主表和子表。主表的一条记录能够和子表的N条记录有关系。若是要想让主表的主键到子表中继续作主键，子表的记录就依赖主表的记录而存在，此时应该在(子表 to 主表)选项里面的 Dependent 上打勾，这时 Mandatory 自动被选上。若是不须要主表的主键到子表中继续作主键，主表的记录仅对子表作约束或者说是强制，这时只在(子表 to 主表)选项里面的 Mandatory 上打勾。若是不须要主表的主键到子表中继续作主键，子表里的这个字段能够是主表里的数据同时也能够为空，在(子表 to 主表)选项里面的 Mandatory 上的勾去掉。