Dominant role，mandatory与dependent

2019独角兽企业重金招聘Python工程师标准>>>

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 上的勾去掉。

转载于:https://my.oschina.net/china008/blog/324837