Name:是用来在模型中标识一个实体,一般用于模型在界面中的显示(这个可以通过更改选项设置进行改变)。在一个模型当中,实体的名字不能重复。
Code:在模型转化时一般作为对象的物理名称,比如把实体属性的Code转化为数据库中的列名,当然我们现在不必为了这个实体将来叫什么而费神,一般采取与Name一致即可。
Generate:默认是选择状态,如果取消,则在转化为其他模型时,会忽略这个实体。
2、添加实体属性按“Crtl+U”呼出“定制列过滤器”的窗口,可以根据自己的喜好和实际需要选择那些列出现在窗口中,那些隐藏。使用快捷键 “Crtl+E”可以允许或者禁止当前过滤器。
2)在上图所示窗口中,点击插入属性按钮,弹出属性对话框,如下图所示。
参数 | 说明 |
Minimum | 属性可接受的最小数 |
Maximum | 属性可接受的最大数 |
Default | 属性不赋值时,系统提供的默认值 |
Unit | 单位,如公里、吨、元 |
Format | 属性的数据显示格式 |
Lowercase | 属性的赋值全部变为小写字母 |
Uppercase | 属性的赋值全部变为大写字母 |
Cannot modify | 该属性一旦赋值不能再修改 |
List Of Values | 属性赋值列表,除列表中的值,不能有其他的值 |
Label | 属性列表值的标签 |
3)选择"Attributes"选项卡,再点击“Add Attributes”工具,弹出如图所示窗口,选择某个属性作为标识符就行了。
1、 建立联系
在CDM工具选项板中除了公共的工具外,还包括如下图所示的其它对象产生工具。
在图形窗口中创建两个实体后,单击“实体间建立联系”工具,单击一个实体,在按下鼠标左键的同时把光标拖至别一个实体上并释放鼠标左键,这样就在两个实体间创建了联系,右键单击图形窗口,释放Relationship工具。如下图所示
在两个实体间建立了联系后,双击联系线,打开联系特性窗口,如图所示。
2、 四种基本的联系
即一对一(ONE TO ONE)联系、一对多(ONE TO MANY)联系、多对一(MANY TO ONE)联系和多对多联系(MANY TO MANY)。如图所示
3、 其他几类特殊联系
除了4种基本的联系之外,实体集与实体集之间还存在标定联系(Identify Relationship)、非标定联系(Non-Identify RelationShip)和递归联系(Recursive Relationship)。
标定联系:
每个实体类型都有自己的标识符,如果两个实体集之间发生联系,其中一个实体类型的标识符进入另一个实体类型并与该实体类型中的标识符共同组成其标识符时,这种联系则称为标定联系,也叫依赖联系。反之称为非标定联系,也叫非依赖联系。
注意:
在非标定联系中,一个实体集中的部分实例依赖于另一个实例集中的实例,在这种依赖联系中,每个实体必须至少有一个标识符。而在标定联系中,一个实体集中的全部实例完全依赖于另个实体集中的实例,在这种依赖联系中一个实体必须至少有一个标识符,而另一个实体却可以没有自己的标识符。没有标识符的实体用它所依赖的实体的标识符作为自己的标识符。
换句话来理解,在标定联系中,一个实体(选课)依赖 一个实体(学生),那么(学生)实体必须至少有一个标识符,而(选课)实体可以没有自己的标识符,没有标标识符的实体可以用实体(学生)的标识符作为自己的标识符。
递归联系:
递归联系是实体集内部实例之间的一种联系,通常形象地称为自反联系。同一实体类型中不同实体集之间的联系也称为递归联系。
例如:在“职工”实体集中存在很多的职工,这些职工之间必须存在一种领导与被领导的关系。又如“学生”实体信中的实体包含“班长”子实体集与“普通学生”子实体集,这两个子实体集之间的联系就是一种递归联系。创建递归联系时,只需要单击“实体间建立联系”工具从实体的一部分拖至该实体的别一个部分即可。如图
3、 定义联系的特性
双击关系(Relationship)的符号,进入关系的属性页,在Detail项目中,我们可以对两个实体的关系进行详细的定义,如下图:
一般最好为关系取一个贴切的名字,本例的业务关系描述如下:一个部门有多个员工,我们使用“Has”作为这个关系的名字。
同样的我们也可以描述为:多个员工属于一个部门,可不可以使用“Belong to”作为关系名字呢?一般不推荐这样做,在概念图中有一个约定,关系的名字采用从“1,n”中“1”所在的方向向“n”所在一方进行读取的语义。本例即 “1”在部门一方,从部门一方向雇员一方读取语义,即:部门有(Has)多个员工。
假定对于实体部门(Department)和雇员(Employee),具有如下关系:
- 一个部门可以有多个雇员,新成立的部门也可以暂时没有任何雇员;
- 一个雇员必须属于一个部门,并且同时只能属于一个部门;
根据以上关系,我们修改属性页,部门-雇员的方向采用默认的0,n,雇员-部门的方向修改为强制约束(Mandatory),或者从下拉框中选择“1,1”,如下图:
最后定义完成的关系(Relationship)在概念图中表示如下:
注:在Power Designer中,关系符号靠近实体端的一个“横线”代表强制性约束,“空心圆圈”代表无强制约束,即这一方可以无对象关联;“非分岔”线代表为“1” 的关系,“分岔”线代表“多”的关系。以上四个符号共可以组合出16种关系(包含反向)。其中“多对多”的关系一般通过给出一个中间实体来进行分解,所以在许多概念图中,是看不到实际的“多对多”的关系存在的。
另外在关系的属性中还有两项:Dominant role 和Dependent,可以表示更复杂的关系,会在后面讲到。
还是使用上面的例子,我们假定这样的业务描述:雇员享有假期,雇员每次休假,需要记录雇员休假的起始日与结束日,假期以天为单位,一个雇员和一个开始日唯一确定一个假期。根据这个业务描述,我们知道,对于假期而言,其必须依存于实体“Employee”而存在,即一个休假,必定有一个主体雇员。我们在上一个模型的基础之上,添加一个实体,名称是“Holiday”,定义假期的属性开始日与结束日,这里并不需要重复定义一个雇员编号,而是替代的,使用依赖关系,来表示实体“Holiday”依赖于实体“Employee”,关系定义如下图:
在实体“Holiday”中,我们需要设置开始日为主键标识符,开始日与其依赖实体中的雇员编号一起作为实体“Holiday”的标识符,用来唯一确定一个假期。这种依赖关系在概念图中表现如下:
从途中可以看出,在实体“Holiday”一端多了一个朝外的三角▲箭头,这个含义就是这个实体“的依赖于三角箭头所指的另外一个实体,在转化出来的物理模型当中,实体“Employee”的empNo,在Holiday实体中不仅会作为一个外键,还同时会作为主键出现(与startData一起作为复合主键)。
当两个实体之间的关系是1..1 时(尽管这种关系比较少见,常见于面向对象的设计方法当中,依赖实体中的主键通常与外健重合),你需要明确指定这两个实体,哪一个是父实体,哪一个是依赖实体,否则,系统在由概念模型转化为物理模型时,将不能确定需要在哪一端生成外键,这时就需要用到“Dominant role”选项,这个选项只有在1..1 的关系中才允许进行设置。我们假定这样的业务描述,企业中的部分雇员拥有一个系统帐号,并且是唯一的一个帐号,这些雇员需要保存一些额外的信息,比如帐号名称、密码等等。我们添加了一个新的实体“User”,其与雇员之间为1..1 的关系,由于一个用户帐号必定属于一个雇员,而一个雇员则可能没有用户帐号,所以我们定义实体“Employee”支配实体“User”。同时,由于 “User”依赖于“Employee”而存在,所以再定义一个由前者到后者的依赖关系,如下图:
Dominant role 选项中,箭头所指的实体为被支配的实体,即作为依赖实体。在模型图中,支配实体的一方会出现一个用圆括号括起来的大写字母“D”。
转化出来的物理模型中,表User中,empNo作为单独的主键,同时也是引用Employee表的一个外键。
在概念模型中,一般很少看见两个实体之间是直接的n..n 的关系,一般这种情况下我们会增加一个中间实体,在Power Designer中,提供了一个专门的符号来对应,叫做“Association”。请考虑以下的情形:
企业中拥有帐号的雇员在系统中具有不同的操作权限,这通过用户角色来进行管理,权限已经分配给了多个不同的角色,一个用户帐号至少属于一个角色,并且可能会同时属于多个角色,一个角色可以包含0个或多个用户帐号。根据以上描述,我们添加一个实体“Role”,它与实体“User”之间是n..n 的关系,为了表达这种关系,我们增加一个“Association”并分别使用“Association Link”与其他两个实体建立关系,表示如下:
使用一个普通的实体,合理定义关系,并选择“Dependent”选项,是可以替代“Association”的,但使用 “Association”更方便、直观,使模型更容易理解,并可以减少因不谨慎而可能导致的错误。