时间：2022-10-19 11:53:39
摘要：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，其属性包括休假的开始时间和天数，每次有教师休假的时候，都要在这个表留下记录。从我们的场景描述中可以看到，实体型假期必须依附于实体型教师，即对于每一个假期实例，必须指向某一个教师实例。
对于依赖型联系，注意它不能是一个多对多联系；如果是多对多关系，需要简单的将其转换为两个主―从表的多对一关系[2]。在这个联系中，必须有一个作为主体的实体型。一个Dependent联系的从实体可以没有自己的Identifier。
2.1.3 Dominant依赖性联系
这个联系属性是最简单的，它仅作用于一对一联系，并指明这种联系中的主从表关系，习惯上称之为标定关联。在A，B两个实体型的联系中，如果A――>B被指定为Dominant，那么A为这个一对一联系的主表，B为从表，并且在以后生成的PDM中会产生一个引用（如果不指定Dominant属性的话会产生两个引用）。比如老师和班级之间的联系，因为每个班级都有一个老师做班主任，每个老师也最多只能做一个班级的班主任，所以是一个一对一关系。同时，我们可以将老师作为主表，用老师的工号来唯一确定一个班主任联系。
2.2 Association（关联）
文献[1]中对Association给出的定义出现了许多RelationShip，也就是2.1中给出的联系。 在很多情况下（特别是多对多关系中），我们会把联系专门提出来，作为一个实体型放在两个需要被关联的实体型中间（在PD中，选中任何一个联系，在右键的弹出菜单中选择“Change to Entity”命令即可完成联系转实体的操作）。类似的做法，在UML的通用建模工具Rational Rose中定义了Association Class来建立ORM映射[3]。但有时，把若干个实体型之间的联系抽象为一个实体型可能不太合适，这时可选择为这些实体型建立一个Association，那么在生成PDM的时候，所有这些相关实体型的Identifier都会被加入到Association对应生成的表模型中。
更贴切的理解，其实Association是实体型的一种特例，用来在建模的时候更确切的表达实体间的关联信息。文献[1]举了一个例子描述录音带、顾客、商店三个实体型在租借录音带这个场景上发生关联，然后把租借定义为上述三个实体型之间的Association的例子。在本文的学校模型里，定义了家访做为老师和学生实体型中间的一个Association，在接下来产生的PDM中能看到这种定义所产生的效果。
2.1.3 Inheritance（继承）
非常简但的IS―A关系模型。
3 PDM模型
前面给出了CDM中关于实体间关系的主要内容，接下来将探讨CDM―>PDM。
图4为对应图3的PDM模型，图4中标红的部分都是由于对实体型间的关系的定义而产生的，下面给出简要说明。
1. “师生关系”和“学生俱乐部”这两个表是由于我们的多对多关系而产生的。
2. “假期”表的“工号”字段是由于我们将教师―假期关系指定为Dependent而产生的。
3. “班级”表的“工号”字段是由于我们将教师―班级关系制定为Dominant而产生的。
4. “家访”表中的“工号”和“学号”字段是由于家访是教师和学生实体型的Association而产生的。
此外，在2.1.3节中提到，一个没指定Dominant方向的一对一联系将产生两个引用，因此需要把原本的CDM中的教师―班级关系进行一个修改，去掉这个Relationship的Dominant定义，那么最终产生的PDM中教师表和班级表将互相包含对方的主键。截图如下：
对照图5和图4两个PDM模型的区别，容易得看出Dominant属性对一个一对一关系的作用。
4 小结
PD建模遵循着第一步严格精确设计，后继自动化演化生成的原则。因此CDM模型的完备性与精确性至关重要。CDM模型最复杂难以把握的是其对联系的扩展。本文从文献[1]也就是PD Online在线文档出发，对CDM和PDM建模作了清晰的路线图阐述，给出了完整的实例。
参考文献
[1] PD Online联机文档[EB/OL].
[2] 王珊， 萨师暄. 数据库系统概论[M]， 清华大学出版社， 2005.
[3] Rational Rose Online联机文档[EB/OL].
[4] 孙卫琴. 精通Hibernate： Java对象持久化技术详解 [M]. 电子工业出版， 2005.
[5] http：///p/ibatis开源中国社区[EB/OL].