powerdesigner 画ER图

ER图 即为 CDM图 - Conceptual Data Modal

CDM能够转换成PDM、OOM、LDM等图，具体请详查

通常，CDM图示在概要设计阶段建立，PDM图示根据CDM图的基础上产生的。

1、概念数据模型概述
数据模型是现实世界中数据特征的抽象。数据模型应该知足三个方面的要求：
1）可以比较真实地模拟现实世界
2）容易为人所理解
3）便于计算机实现

概念数据模型也称信息模型，它以实体－联系(Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库的概念级设计。

一般人们先将现实世界抽象为概念世界，而后再将概念世界转为机器世界。换句话说，就是先将现实世界中的客观对象抽象为实体(Entity)和联系(Relationship),它并不依赖于具体的计算机系统或某个DBMS系统，这种模型就是咱们所说的CDM;而后再将CDM转换为计算机上某个DBMS所支持的数据模型，这样的模型就是物理数据模型,即PDM。

CDM是一组严格定义的模型元素的集合，这些模型元素精确地描述了系统的静态特性、动态特性以及完整性约束条件等，其中包括了数据结构、数据操做和完整性约束三部分。
1）数据结构表达为实体和属性;
2）数据操做表达为实体中的记录的插入、删除、修改、查询等操做;
3）完整性约束表达为数据的自身完整性约束（如数据类型、检查、规则等）和数据间的参照完整性约束（如联系、继承联系等）;


2、实体、属性及标识符的定义
实体（Entity），也称为实例，对应现实世界中可区别于其余对象的“事件”或“事物”。例如，学校中的每一个学生，医院中的每一个手术。
每一个实体都有用来描述实体特征的一组性质，称之为属性，一个实体由若干个属性来描述。如学生实体可由学号、姓名、性别、出生年月、所在系别、入学年份等属性组成。

实体集（Entity Set）是具体相同类型及相同性质实体的集合。例如学校全部学生的集合可定义为“学生”实体集，“学生”实体集中的每一个实体均具备学号、姓名、性别、出生年月、所在系别、入学年份等性质。

实体类型（Entity Type）是实体集中每一个实体所具备的共同性质的集合，例如“患者”实体类型为：患者｛门诊号，姓名，性别，年龄，身份证号.............｝。实体是实体类型的一个实例，在含义明确的状况下，实体、实体类型一般互换使用。

实体类型中的每一个实体包含惟一标识它的一个或一组属性，这些属性称为实体类型的标识符（Identifier），如“学号”是学生实体类型的标识符，“姓名”、“出生日期”、“信址”共同组成“公民”实体类型的标识符。

有些实体类型能够有几组属性充当标识符，选定其中一组属性做为实体类型的主标识符，其余的做为次标识符。

3、实体、属性及标识符的表达

介绍PowerDesigner概念数据模型以及实体、属性建立。

1、新建概念数据模型
1）选择File-->New,弹出如图所示对话框，选择CDM模型（即概念数据模型）创建模型。


2）完成概念数据模型的建立。如下图示，对当前的工做空间进行简单介绍。（之后再更详细说明）


3）选择新增的CDM模型，右击，在弹出的菜单中选择“Properties”属性项，弹出如图所示对话框。在“General”标签里能够输入所建模型的名称、代码、描述、建立者、版本以及默认的图表等等信息。在“Notes”标签里能够输入相关描述及说明信息。固然再有更多的标签，能够点击 "More>>"按钮，这里就再也不进行详细解释。

2、建立新实体
1）在CDM的图形窗口中，单击工具选项版上的Entity工具，再单击图形窗口的空白处，在单击的位置就出现一个实体符号。点击Pointer工具或右击鼠标，释放Entitiy工具。如图所示

2）双击刚建立的实体符号，打开下列图标窗口，在此窗口“General”标签中能够输入实体的名称、代码、描述等信息。


3、添加实体属性
1）在上述窗口的“Attribute”选项标签上能够添加属性，以下图所示。


注意：
数据项中的“添加属性”和“重用已有数据项”这两项功能与模型中Data Item的Unique code 和Allow reuse选项有关。
P列表示该属性是否为主标识符;D列表示该属性是否在图形窗口中显示;M列表示该属性是否为强制的，即该列是否为空值。

若是一个实体属性为强制的，那么， 这个属性在每条记录中都必须被赋值，不能为空。2）在上图所示窗口中，点击插入属性按钮，弹出属性对话框，以下图所示。

注意：这里涉及到域的概念，即一种标准的数据结构，它可应用至数据项或实体的属性上

1、定义属性的标准检查约束
标准检查约束是一组确保属性有效的表达式。在实体属性的特性窗口，打开如图所示的检查选项卡。


在这个选项卡能够定义属性的标准检查约束，窗口中每项的参数的含义，以下
参数说明Minimum属性可接受的最小数Maximum 属性可接受的最大数Default属性不赋值时，系统提供的默认值Unit单位，如千米、吨、元Format属性的数据显示格式Lowercase属性的赋值所有变为小写字母Uppercase属性的赋值所有变为大写字母Cannot modify该属性一旦赋值不能再修改List Of Values属性赋值列表，除列表中的值，不能有其余的值Label属性列表值的标签
2、定义属性的附加检查
当Standard checks 或Rules 不能知足检查的要求时，能够在Additional Checks选项卡的Server子页上，经过SQL语句中使用%MINMAX%、%LISTVAL%、%RULES%、%UPPER%、%LOWER%几个变量来定义Standard和Rule,如图所示


%MINMAX%、%LISTVAL%、%UPPER%、%LOWER%
在Standard Check中定义的Minimum 和Maximum、List values 、uppervalues、lowervalues

%RULES%
在Rules特性窗口Expression选项卡中定义的有效性规则表达式

1、标识符
标识符是实体中一个或多个属性的集合，可用来惟一标识实体中的一个实例。要强调的是，CDM中的标识符等价于PDM中的主键或候选键。
每一个实体都必须至少有一个标识符。若是实体只有一个标识符，则它为实体的主标识符。若是实体有多个标识符，则其中一个被指定为主标识符，其他的标识符就是次标识符了。

2、若是定义主、次标识符
1）选择某个实体双击弹出实体的属性对话框。在Identifiers选项卡上能够进行实体标识符的定义。以下图所示



2）选择第一行“主标识符”，点击属性按钮或双击第一行“主标识符”，弹出属性对话框，如图所示

3）选择"Attributes"选项卡，再点击“Add Attributes”工具，弹出如图所示窗口，选择某个属性做为标识符就好了。

1、数据项
数据项（Data Item）是信息存储的最小单位，它能够附加在实体上做为实体的属性。
注意：模型中容许存在没有附加至任何实体上的数据项。

2、新建数据项
1）使用“Model”---> Data Items 菜单，在打开的窗口中显示已有的数据项的列表，点击 “Add a Row”按钮，建立一个新数据项，如图所示


2）固然您能够继续设置具体数据项的Code、DataType、Length等等信息。这里就再也不详细说明了。

3、数据项的惟一性代码选项和重用选项
使用Tools--->Model Options->Model Settings。在Data Item组框中定义数据项的惟一性代码选项(Unique Code)与重用选项（Allow Reuse）。
注意：
若是选择Unique Code复选框 ，每一个数据项在同一个命名空间有惟一的代码，而选择Allow reuse ，一个数据项能够充当多个实体的属性。


4、在实体中添加数据项
1）双击一个实体符号，打开该实体的属性窗口。
2）单击Attributes选项卡，打开以下图所示窗口


注意：
Add a DataItem 与 Reuse a DataItem的区别在于
Add a DataItem 状况下，选择一个已经存在的数据项，系统会自动复制所选择的数据项。若是您设置了UniqueCode选项，那系统在复制过程当中，新数据项的Code会自动生成一个惟一的号码，不然与所选择的数据项彻底一致。


Reuse a DataItem状况下，只引用不新增，就是引用那些已经存在的数据项，做为新实体的数据项

1、 联系
联系（Relationship）是指实体集这间或实体集内部实例之间的链接。

实体之间能够经过联系来相互关联。与实体和实体集对应，联系也能够分为联系和联系集，联系集是实体集之间的联系，联系是实体之间的联系，联系是具备方向性的。联系和联系集在含义明确的状况之下都可称为联系。

按照实体类型中实例之间的数量对应关系，一般可将联系分为4类，即一对一（ONE TO ONE）联系、一对多（ONE TO MANY）联系、多对一（MANY TO ONE）联系和多对多联系（MANY TO MANY）。 2、 创建联系
在CDM工具选项板中除了公共的工具外，还包括以下图所示的其它对象产生工具。

在图形窗口中建立两个实体后，单击“实体间创建联系”工具，单击一个实体，在按下鼠标左键的同时把光标拖至别一个实体上并释放鼠标左键，这样就在两个实体间建立了联系，右键单击图形窗口，释放Relationship工具。以下图所示


3、 四种基本的联系
即一对一（ONE TO ONE）联系、一对多（ONE TO MANY）联系、多对一（MANY TO ONE）联系和多对多联系（MANY TO MANY）。如图所示

4、 其余几类特殊联系

除了4种基本的联系以外，实体集与实体集之间还存在标定联系（Identify Relationship）、非标定联系（Non-Identify RelationShip）和递归联系（Recursive Relationship）。

标定联系：
每一个实体类型都有本身的标识符，若是两个实体集之间发生联系，其中一个实体类型的标识符进入另外一个实体类型并与该实体类型中的标识符共同组成其标识符时，这种联系则称为标定联系，也叫依赖联系。反之称为非标定联系，也叫非依赖联系。
注意：
在非标定联系中，一个实体集中的部分实例依赖于另外一个实例集中的实例，在这种依赖联系中，每一个实体必须至少有一个标识符。而在标定联系中，一个实体集中的所有实例彻底依赖于另个实体集中的实例，在这种依赖联系中一个实体必须至少有一个标识符，而另外一个实体却能够没有本身的标识符。没有标识符的实体用它所依赖的实体的标识符做为本身的标识符。

换句话来理解，在标定联系中，一个实体（选课）依赖 一个实体（学生），那么（学生）实体必须至少有一个标识符，而（选课）实体能够没有本身的标识符，没有标标识符的实体能够用实体（学生）的标识符做为本身的标识符。



递归联系：
递归联系是实体集内部实例之间的一种联系，一般形象地称为自反联系。同一实体类型中不一样实体集之间的联系也称为递归联系。

例如：在“职工”实体集中存在不少的职工，这些职工之间必须存在一种领导与被领导的关系。又如“学生”实体信中的实体包含“班长”子实体集与“普通学生”子实体集，这两个子实体集之间的联系就是一种递归联系。建立递归联系时，只须要单击“实体间创建联系”工具从实体的一部分拖至该实体的别一个部分便可。如图


5、 定义联系的特性

在两个实体间创建了联系后，双击联系线，打开联系特性窗口，如图所示。


6、 定义联系的角色名
在联系的两个方向上各自包含有一个分组框，其中的参数只对这个方向起做用，Role Name为角色名，描述该方向联系的做用，通常用一个动词或动宾组表。
如：“学生 to 课目 ” 组框中应该填写“拥有”，而在“课目To 学生”组框中填写“属于”。（在此只是举例说明，可能有些用词不太合理）。
7、 定义联系的强制性
Mandatory 表洋这个方向联系的强制关系。选中这个复选框，则在联系线上产生一个联系线垂直的竖线。不选择这个复选框则表示联系这个方向上是可选的，在联系线上产生一个小圆圈。

8、 有关联系的基数
联系具备方向性，每一个方向上都有一个基数。

举例，
“系”与“学生”两个实体之间的联系是一对多联系，换句话说“学生”和“系”之间的联系是多对一联系。并且一个学生必须属于一个系，而且只能属于一个系，不能属于零个系，因此从“学生”实体至“系”实体的基数为“1,1”，从联系的另外一方向考虑，一个系能够拥有多个学生，也能够没有任何学生，即零个学生，因此该方向联系的基数就为“0,n”,如图所示

CDM是大多数开发者使用PD时最早建立的模型，也是整个数据库设计最高层的抽象。CDM是创建在传统的ER图模型理论之上的，ER图中有三大主要元素：实体型，属性和联系。其中实体型对应到CDM中的Entity，属性对应到CDM中每一个Entity的Attribute，在概念上基本上是一一对应的。但在联系上，CDM有了比较大的扩展，除了保留ER图原有的RelationShip概念以外，还增长了Association，Inheritance两种实体关系，下面就让咱们分别看看这些关系的用法和之间的区别（下图中被标红的工具栏按钮就是用来向实体中添加这些关系的）。

   另外，在介绍全部这些CDM中的元素以前，笔者先给出一个很简单的CDM图，是对咱们最最熟悉的学校场景的一个建模，下文中提到的全部概念在图中都有体现，你们在看下文的时候能够对照着来看：


一. RelationShip(联系)
   先给出PD手册里对联系的定义：“A relationship is a link between entities. For example, in a CDM that manages human resources, the relationship Member links the entities Employee and Team, because employees can be members of teams. This relationship expresses that each employee works in a team and that each team has employees.” 可见，也许联系的概念真的太简单了吧，因此反而不那么好表述，因此PD的文档里也是用一个例子来讲明出现了什么样的状况咱们就认为两个实体间是有联系的。
   当咱们提起实体间联系的时候，最早想到的恐怕是one to one，one to many 和many to many这三种联系类型，这些联系类型也是你们最熟悉的。笔者对ER图本来的概念并不精通，但在CDM中，联系还有另外三个能够设置的属性：mandatory（强制性联系）, dependent（依赖性联系/标定关联） 和dominant（统制联系）。这些属性对后面PDM的生成都有比较大的影响，须要咱们一一有所了解。它们都是在联系的属性控制面板中设定的，见下图：

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属性的话会产生两个引用）。好比老师和班级之间的联系，由于每一个班级都有一个老师作班主任，每一个老师也最多只能作一个班级的班主任，因此是一个一对一关系。同时，咱们能够将老师做为主表，用老师的工号来惟一肯定一个班主任联系。

二.Association（关联）
   先来看一下PD给association的定义：“An association is a connection between entities. In the Merise modeling methodology an association is used to connect several entities that each represents clearly defined objects, but are linked by an event, which may not be so clearly represented by another entity.”。
   在上一小段提到的那些RelationShip，在不少状况下（特别是多对多关系中），咱们会把联系专门提出来，做为一个实体型放在两个须要被关联的实体型中间（在PD中，选中任何一个联系，在右键的弹出菜单中选择“Change to Entity”命令便可完成联系转实体的操做）。但有的时候，把若干个实体型之间的联系抽象为一个实体型可能不太合适，这个时候你能够选择为这些实体型创建一个association，那么在生成PDM的时候，全部这些相关实体型的identifier都会被加入到association对应生成的表模型中。因此，说白了，其实association就是实体型的一种特例，用来在建模的时候更确切的表达实体间的关联信息。在PD的文档中举了一个录音带、顾客、商店三个实体型在租借录音带这个场景上发生关联，而后把租借定义为上述三个实体型之间的association的例子，很是确切。在咱们的学校模型里，我定义了家访作为老师和学生实体型中间的一个association，在接下来产生的PDM中你们就可能看到这种定义所产生的效果。

三.Inheritance（继承）
   这种关系在概念层面是最容易理解的了，本文就不赘述了。