标签:
附:
PowerDesigner12.0下载地址:
http://download.sybase.com/eval/PowerDesigner/powerdesigner12_eval.exe
破解补丁http://www.cnblogs.com/Files/polugen/PD12.rar

1.mandatory 联系是否具有强制性,指的是实体间是不是一定会出现这种联系;或者换句话说,当我们在谈及一个联系的应用场景的时候,联系对应的那两个实体型的实体实例的个数可不可能为零。也许这样的解释还是有点抽象,让我们举两个联系的例子,一个是对两边的实体都有强制性的,另一个则不然。 (1)教师--学生 联系 这个联系首先是一个多对多联系,因为每个老师可以教多个学生,每个学生也都有多个老师来负责他们的学业。同时,这个联系对教师和学生都是强制性的,也就是说,不存在任何一个老师,他不负责任何一个学生的教学;也不存在任何一个学生,他没有任何一个任课老师。 (2)学生--俱乐部 联系 这个联系也是一个多对多关系,但它对学生这个实体型而言就不是强制的(Optional,可选的)。每个俱乐部都有至少一个学生参加,但并不是每个学生都要去参加俱乐部的活动。完全可以有一些学生,他们什么俱乐部都没参加。 上面的例子主要是从概念的角度来区分了mandatory和optional的区别。实际上如果把这个模型对应到我们最后生成的表,如果A-B间的联系对A是mandatory的话,那么如果在A里面如果包含B的外键,这个外键不能为空值,反之可以为空值。后面我们谈到PDM和实际数据库的时候,大家会看到这一点。 2.dependent 每一个Entity型都有自己的Identifier,如果两个Entity型之间发生关联时,其中一个Entity型的Identifier进入另一个Entity型并与该 Entity型中的Identifier共同组成其Identifier时,这种关联称为标定关联,也叫依赖性关联(dependent relationship)。一个Entity型的Identifier进入另一个Entity型后充当其非Identifier时,这种关联称为非标定关联,也叫非依赖关联。 概念的定义说起来还是有些拗口,说白了其实就是主-从表关系,从表要依赖于主表。比如在我们系统里要记录教师休假的情况,有一个实体型Holiday,其属性包括休假的开始时间和天数,每次有教师休假的时候,都要在这个表留下记录。从我们的场景描述中可以看到,实体型假期必须依附于实体型教师,即对于每一个假期实例,必须指向某一个教师实例。 对于依赖型联系,必须注意它不可能是一个多对多联系,在这个联系中,必须有一个作为主体的实体型。一个dependent联系的从实体可以没有自己的identifier. 3.dominant 这个联系属性是最为简单的,它仅作用于一对一联系,并指明这种联系中的主从表关系。在A,B两个实体型的联系中,如果A-->B被指定为dominant,那么A为这个一对一联系的主表,B为从表,并且在以后生成的PDM中会产生一个引用(如果不指定dominant属性的话会产生两个引用)。比如老师和班级之间的联系,因为每个班级都有一个老师做班主任,每个老师也最多只能做一个班级的班主任,所以是一个一对一关系。同时,我们可以将老师作为主表,用老师的工号来唯一确定一个班主任联系。
上图中所有标红的部分是我们最应该关注的内容,因为他们都是由于我们对实体型间的关系的定义而产生的,下面给出一些简单的说明。 1. “师生关系”和“学生俱乐部”这两个表是由于我们的多对多关系而产生的。 2. “假期”表的“工号”字段是由于我们将教师-假期关系指定为dependent而产生的。 3. “班级”表的“工号”字段是由于我们将教师-班级关系制定为dominant而产生的。 4. “家访”表中的“工号”和“学号”字段是由于家访是教师和学生实体型的association而产生的。 另外,记得我们在提到dominant属性的时候说过,一个没指定dominant方向的一对一联系将产生两个引用,下面我们就把原本的CDM中的教师-班级关系进行一个小小的修改,去掉这个relationship的dominant定义,那么最终产生的PDM中教师表和班级表将互相包含对方的主键(由于我们的班级表没有自己的主键,所以只能在班级表中看到多出来的列),截图如下:
对照这个PDM截图和上一个PDM截图之间的区别,大家可以很容易得看出dominant属性对一个一对一关系的作用。标签:
原文地址:http://www.cnblogs.com/liangxiaofeng/p/5798626.html