Power Designer中CDM与PDM模型解析.docVIP

Power Designer中CDM与PDM模型解析 　　摘要：Power Designer一款强大的数据库分析设计CASE工具集，使用它可以方便地对管理信息系统进行分析设计，几乎包括了数据库模型设计的全过程。CDM建模是MIS系统建模的第一步，也是整个数据库设计最高层的抽象。CDM建立在传统的ER图模型之上，但对ER模型有了大的扩展，具有更强的建模能力且更适应MIS系统开发实际。PD建模遵循着第一步严格精确设计，后继自动化演化生成的原则；因此CDM模型的完备性与精确性至关重要。CDM模型最复杂难以把握的是其对联系的扩展。本文从PD给出的各元定义出发，试图以实例勾画出正确的理解和清晰的数据库建模技术路线图，以CDM到PDM的数据库建模全过程完成对CDM这一复杂模型的解析。 　　关键词：CDM；PDM；数据库模型设计；PowerDesigner；MIS 　　1 引言 　　ER模型图中有三大主要元素：实体型，属性和联系。其中实体型对应到CDM中的Entity，属性对应到CDM中每个Entity的Attribute，在概念上基本上是一一对应的。但在联系的处理上，CDM除了保留ER图原有的RelationShip概念之外，还增加了Association，Inheritance两种实体关系。图1给出了工具栏中三个联系工具图标的位置。 　　本文将从简单的CDM模型图入手，对这些CDM元素进行阐述，试图包含所有数据库建模必须环节。 　　2 CDM模型 　　以简单的学校场景的为例，给出图2所示的CDM模型，该图中所有元素在后面建模均有覆盖，以体现最小集与完备性。 　　2.1 RelationShip（联系） 　　文献[1]对CDM模型中的联系给出了简单定义，但如此简单的定义反而让人难以区分现实世界实际存在的一些复杂情形。文献[1]还给出了一个例子来说明什么样的情况我们就认为两个实体间是有联系的。这个例子并不简单，至少让人觉得其并不像定义那么简单。 　　当提起实体间联系的时候，首先想到的是one to one，one to many 和many to many这三种联系类型，在Hibernate[4]和IBatis[5]这两种居统治地位的ORM框架中也沿用了这三种类型。在CDM中，联系还有另外三个可以设置的属性：Mandatory（强制性联系）， Dependent（依赖性联系/标定关联） 和Dominant（统制联系）。这些属性对后面PDM的生成都有比较大的影响，需要精确理解。它们都是在联系的属性控制面板中设定的，图3所示。 　　2.1.1 Mandatory强制性联系 　　联系是否具有强制性，指的是实体间是不是一定会出现这种联系；或者换句话说，当我们在谈及一个联系的应用场景的时候，联系对应的那两个实体型的实体实例的个数可不可能为零。也许这样的解释还是有点抽象，让我们举两个联系的例子，一个是对两边的实体都有强制性的，另一个则不然。 　　（1）教师――学生 联系 　　这个联系首先是一个多对多联系，因为每个老师可以教多个学生，每个学生也都有多个老师来负责他们的学业。同时，这个联系对教师和学生都是强制性的，也就是说，不存在任何一个老师，他不负责任何一个学生的教学；也不存在任何一个学生，他没有任何一个任课老师。 　　（2）学生――俱乐部 联系 　　这也是一个多对多关系，但它对学生这个实体型而言就不是强制的（Optional，可选的）。每个俱乐部都有至少一个学生参加，但并不是每个学生都要去参加俱乐部的活动。完全可以有一些学生，他们什么俱乐部都没参加。 　　上面的例子从概念的角度来区分了Mandatory和Optional的区别。如果把这个模型对应到我们最后生成的表，如果A―B间的联系对A是Mandatory的话，那么如果在A里面如果包含B的外键，这个外键不能为空值，反之可以为空值。 　　2.1.2 Dependent 　　每一个Entity型都有独立的Identifier，若两个Entity型之间发生关联，其中一个Entity型的Identifier进入另一个Entity型并与该 Entity型中的Identifier共同组成其Identifier时，这种关联称为标定关联，也叫依赖性关联（Dependent Relationship）。一个Entity型的Identifier进入另一个Entity型后充当其非Identifier时，这种关联称为非标定关联，也叫非依赖关联。 　　上述叙述表达的就是主―从表关系，从表要依赖于主表。比如在我们系统里要记录教师休假的情况，有一个实体型Holiday，其属性包括休假的开始时间和天数，每次有教师休假的时候，都要在这个表留下记录。从我们的场景描述中可以看到，实体型假期必须依附于实体型教师，即对于每一个假期实