文档章节

Dominant role,mandatory与dependent

china008
 china008
发布于 2014/10/08 10:51
字数 2403
阅读 57
收藏 0

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


本文转载自:http://blog.csdn.net/amwiacel/article/details/4575050