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

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

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

二、实体、属性及标识符的定义

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

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

    实体类型（Entity Type）是实体集中每个实体所具有的共同性质的集合，例如“患者”实体类型为：患者｛门诊号，姓名，性别，年龄，身份证号.............｝。实体是实体类型的一个实例，在含义明确的情况下，实体、实体类型通常互换使用。实体类型中的每个实体包含唯一标识它的一个或一组属性，这些属性称为实体类型的标识符（Identifier），如“学号”是学生实体类型的标识符，“姓名”、“出生日期”、“信址”共同组成“公民”实体类型的标识符。有些实体类型可以有几组属性充当标识符，选定其中一组属性作为实体类型的主标识符，其他的作为次标识符。

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


四、新建概念数据模型

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


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


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


五、定义实体

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

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

Name：是用来在模型中标识一个实体，一般用于模型在界面中的显示（这个可以通过更改选项设置进行改变）。在一个模型当中，实体的名字不能重复。

Code：在模型转化时一般作为对象的物理名称，比如把实体属性的Code转化为数据库中的列名，当然我们现在不必为了这个实体将来叫什么而费神，一般采取与Name一致即可。

Generate：默认是选择状态，如果取消，则在转化为其他模型时，会忽略这个实体。

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


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

如果一个实体属性为强制的，那么， 这个属性在每条记录中都必须被赋值，不能为空。

按“Crtl+U”呼出“定制列过滤器”的窗口，可以根据自己的喜好和实际需要选择那些列出现在窗口中，那些隐藏。使用快捷键 “Crtl+E”可以允许或者禁止当前过滤器。

2）在上图所示窗口中，点击插入属性按钮，弹出属性对话框，如下图所示。

3、定义属性的检查约束

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


在这个选项卡可以定义属性的标准检查约束，窗口中每项的参数的含义，如下

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选项卡中定义的有效性规则表达式

六、标识符

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

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



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

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

七、数据项

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

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


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

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


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


注意：
Add a DataItem 与 Reuse a DataItem的区别在于
Add a DataItem 情况下，选择一个已经存在的数据项，系统会自动复制所选择的数据项。如果您设置了UniqueCode选项，那系统在复制过程中，新数据项的Code会自动生成一个唯一的号码，否则与所选择的数据项完全一致。


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

八、 联系

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

    实体之间可以通过联系来相互关联。与实体和实体集对应，联系也可以分为联系和联系集，联系集是实体集之间的联系，联系是实体之间的联系，联系是具有方向性的。联系和联系集在含义明确的情况之下均可称为联系。

    按照实体类型中实例之间的数量对应关系，通常可将联系分为4类，即一对一（ONE TO ONE）联系、一对多（ONE TO MANY）联系、多对一（MANY TO ONE）联系和多对多联系（MANY TO MANY）。

1、 建立联系
在CDM工具选项板中除了公共的工具外，还包括如下图所示的其它对象产生工具。

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

 <!--[if !vml]--><!--[endif]-->

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

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项目中，我们可以对两个实体的关系进行详细的定义，如下图：

1. General 项目

   一般最好为关系取一个贴切的名字，本例的业务关系描述如下：一个部门有多个员工，我们使用“Has”作为这个关系的名字。

   同样的我们也可以描述为：多个员工属于一个部门，可不可以使用“Belong to”作为关系名字呢？一般不推荐这样做，在概念图中有一个约定，关系的名字采用从“1,n”中“1”所在的方向向“n”所在一方进行读取的语义。本例即 “1”在部门一方，从部门一方向雇员一方读取语义，即：部门有（Has）多个员工。

2. Detail 项目

假定对于实体部门（Department）和雇员（Employee），具有如下关系：

• 一个部门可以有多个雇员，新成立的部门也可以暂时没有任何雇员；

• 一个雇员必须属于一个部门，并且同时只能属于一个部门；

根据以上关系，我们修改属性页，部门－雇员的方向采用默认的0,n，雇员－部门的方向修改为强制约束（Mandatory），或者从下拉框中选择“1,1”，如下图：

最后定义完成的关系（Relationship）在概念图中表示如下：

注：在Power Designer中，关系符号靠近实体端的一个“横线”代表强制性约束，“空心圆圈”代表无强制约束，即这一方可以无对象关联；“非分岔”线代表为“1” 的关系，“分岔”线代表“多”的关系。以上四个符号共可以组合出16种关系（包含反向）。其中“多对多”的关系一般通过给出一个中间实体来进行分解，所以在许多概念图中，是看不到实际的“多对多”的关系存在的。

另外在关系的属性中还有两项：Dominant role 和Dependent，可以表示更复杂的关系，会在后面讲到。

使用依赖关系(Dependent)

还是使用上面的例子，我们假定这样的业务描述：雇员享有假期，雇员每次休假，需要记录雇员休假的起始日与结束日，假期以天为单位，一个雇员和一个开始日唯一确定一个假期。根据这个业务描述，我们知道，对于假期而言，其必须依存于实体“Employee”而存在，即一个休假，必定有一个主体雇员。我们在上一个模型的基础之上，添加一个实体，名称是“Holiday”，定义假期的属性开始日与结束日，这里并不需要重复定义一个雇员编号，而是替代的，使用依赖关系，来表示实体“Holiday”依赖于实体“Employee”，关系定义如下图：

 

　

在实体“Holiday”中，我们需要设置开始日为主键标识符，开始日与其依赖实体中的雇员编号一起作为实体“Holiday”的标识符，用来唯一确定一个假期。这种依赖关系在概念图中表现如下：

 

　

从途中可以看出，在实体“Holiday”一端多了一个朝外的三角▲箭头，这个含义就是这个实体“的依赖于三角箭头所指的另外一个实体，在转化出来的物理模型当中，实体“Employee”的empNo，在Holiday实体中不仅会作为一个外键，还同时会作为主键出现（与startData一起作为复合主键）。

使用Dominant role

当两个实体之间的关系是1..1 时（尽管这种关系比较少见，常见于面向对象的设计方法当中，依赖实体中的主键通常与外健重合），你需要明确指定这两个实体，哪一个是父实体，哪一个是依赖实体，否则，系统在由概念模型转化为物理模型时，将不能确定需要在哪一端生成外键，这时就需要用到“Dominant role”选项，这个选项只有在1..1 的关系中才允许进行设置。我们假定这样的业务描述，企业中的部分雇员拥有一个系统帐号，并且是唯一的一个帐号，这些雇员需要保存一些额外的信息，比如帐号名称、密码等等。我们添加了一个新的实体“User”，其与雇员之间为1..1 的关系，由于一个用户帐号必定属于一个雇员，而一个雇员则可能没有用户帐号，所以我们定义实体“Employee”支配实体“User”。同时，由于 “User”依赖于“Employee”而存在，所以再定义一个由前者到后者的依赖关系，如下图：

Dominant role 选项中，箭头所指的实体为被支配的实体，即作为依赖实体。在模型图中，支配实体的一方会出现一个用圆括号括起来的大写字母“D”。

转化出来的物理模型中，表User中，empNo作为单独的主键，同时也是引用Employee表的一个外键。

处理多对多(n..n)的关系

在概念模型中，一般很少看见两个实体之间是直接的n..n 的关系，一般这种情况下我们会增加一个中间实体，在Power Designer中，提供了一个专门的符号来对应，叫做“Association”。请考虑以下的情形：

企业中拥有帐号的雇员在系统中具有不同的操作权限，这通过用户角色来进行管理，权限已经分配给了多个不同的角色，一个用户帐号至少属于一个角色，并且可能会同时属于多个角色，一个角色可以包含0个或多个用户帐号。根据以上描述，我们添加一个实体“Role”，它与实体“User”之间是n..n 的关系，为了表达这种关系，我们增加一个“Association”并分别使用“Association Link”与其他两个实体建立关系，表示如下：

使用一个普通的实体，合理定义关系，并选择“Dependent”选项，是可以替代“Association”的，但使用 “Association”更方便、直观，使模型更容易理解，并可以减少因不谨慎而可能导致的错误。