经典PowerDesigner 教程 完整版

前言

在CSDN上转悠经常看到有网友寻求PowerDesigner相关资料的帖子，Baidu,Google上找找还真很少；同时也有不少网友发来Email询问相关PowerDesigner问题或索要相关资料的，故下定决心制作本文档。折腾二十多天，终于输出了现在的文档，其中绝大部分内容都是依照PowerDesigner自带的帮助文档翻译过来，乐意啃英文的朋友最好还是看其”原汁”教程，同时本文档仅用于帮助分析设计人员更快熟悉掌握PowerDesigner的使用方法，不包含分析设计方面的理论，所以要作好系统的分析设计工作还是需要用户深厚的项目实践功底。

起初想尽量按照PowerDesigner自带帮助文档完整地进行，尝试了一上午的工作之后这种方案马上就被我否决，原因有二：1.内容太多，工作量太多。2.原帮助文档特别周全，个人觉得可以在内容上作很大程度的压缩。姑决定按原帮助文档写，同时加入自己目前正在做的技术论坛分析设计过程以便于理解。 对本文档内容的几点说明：

1． 本文档只包括PowerDesigner部分内容（RQM,Report,CDM,PDM），内容不够全面。 2． 内容尽量简略，一些相同或类似操作过程尽量不再重复。

3． 部分术语参考了飞思科技产品研发中心监制电子工业出版社的《PowerDesigner数据库系统分析设计与

应用》。

4． 暂时没有包含OOM,XML,BPM,ILM等模型内容，我将会在后期陆续更新。

版本说明：我使用的是PowerDesigner Trial 11英文版，因此文档中一些菜单，按钮名称也用英文写出（因当心自己译出的名称和中文版上的名称不一致而造成理解不便），若是给使用中文版的朋友带来不便，我在这说声”抱歉”了!同时由于各版本不同部分操作可能会有所区别。

这里要感谢在我进行翻译工作期间给我发送Email关注的网友，感谢一直支持我的朋友们！由于第一次做翻译工作，限于水平有限，文档中肯定存在很多不足和错误之处，衷心欢迎各位网友指点迷津，期望得到您的指导！

Email:dingchungao@gmail.com dingchungao@126.com QQ:330982401

Blog:http:\\\\feiren1421.cnblogs.com

Slash

2006.8.31

PowerDesigner11.0.0.1363评估版

为了更好的将原文含义再现，不加入我个人语言习惯，我尽量按照原文档内容翻译。 环境简介

需求模型

Workspace

左边的资源浏览窗口Browser提供当前的Workspace层次结构，根节点为Workspace节点，Workspace中可以包含目录(Folder)，模型(Model)，多模型报告(Multi-Model Report),其中模型可以各种系统支持的模型类型。

一般我们将欲构建的目标系统的各种模型，文档及报告放在同一Workspace中，以便于模型设计与管理。 Workspace定义了使用PowerDesigner建模时的信息集合，PowerDesgner工作时只能有一个Workspace处于打开状态。要新建Workspace必须先将当前Workspace关闭，如以下操作：右击当前Workspace->选择”Close”,这样即完成了原Workspace的关闭，同时也自动创建了新的Workspace，只是新Workspace中还没有内容。接下来就可以在其中添加自己想要新建的模型了。

需求模型基础(Requirement model basics)

Requirements Model(RQM)是一种文档式模型，它通过准确恰当地列出，解释开发过程程中需要实现的功能行为来描述待开发项目。你可以为开发过程中需要使用到的各种结构化技术文档（功能或技术规格说明书，测试计划）而使用Requirements Model.

Requirements Model以下面两种视图呈现（而不是以图表形式）： 需求文档视图 对一系列公共属性进行编号

可编辑行矩阵 单元格代表了当前需求与设计对象，外部文件或其它需求的联系 Requirements Model允许你可以： 对一结构化技术文档建立需求模型 检查现有或引入的模型

对需求和设计对象(其它类型模型)建立联系

对其它设计对象建立需求模型，或反之通过需求模型建立其它设计类型

从需求模型生成或更新MS Word文档,提供用户一符合需求模型的MS Word文档 从现有MS Word文档生成或更新相应的需求模型 各对象之间关系如下图所示：

Requirements Model应该包括如下特定对象(Object)：

Object Requirement Glossary term User Group Description 功能行为的名称或内容，可以是父级或子级需求的一部分，它应该在被指派给用户或群(Groups)前被准确定义说明 用于需求模型中的词汇，它应该被正确定义说明以避免误解，建立一定的通用规则 至少与某一需求有关的个人实体 至少与某一需求有关的用户(user)群体 由于Requirements Model中没有图表，以上各对象均没有与之对应的图象符号。需求是以图表视图形式列出，可编辑矩阵视图显示出需求和各设计对象，外部文件或其它需求之间的联系。

需求建模环境包括一系列定义不同模型内容和行为的参数和设定选项，你可以通过在建立模型时，使用默认选项建立模型后或建立模型模版时进行设置。

菜单栏—>选择”Tools”?Model Options，可见以下模型选项对话框，现在可以进行你喜欢的设置了。

定义模型属性

在打开相应模型文件后，选择菜单栏中Model->Model Properties,或在左边树性对象浏览器中选中对应模型，双击/右键->选择Properties，均可进入Properties设置区间，如下图：

接下来就可以进行你想要的设置了！

新建Requirements Model

下面以我自己最近的项目过程为例逐步讲解各过程：

项目简介：这是个类似动网或CSDN的论坛系统，参考了它们的功能设计，主要用于本人练习N层架构的学习。

建立需求模型： 建立完成的需求视图

首先我们要新建一Workspace作为整个系统各种模型，文档与报告信息集合。

启动PowerDesigner,这时会默认打开一个Workspace，单击鼠标右键->选择”Close”,这样我们完成了关闭原来Workspace，同时新建Workspace的工作。接下来就是在其中添加各种模型了。 新建Requirements Model

点击File->New或鼠标右键单击Workspace->New->Requirement Model可以看到新建模型属性选项框如下：

选择左边Requirements Model,其它为默认设置，确定,OK！ 下面我们对新建的RQM进行先进行一些基本属性设置：

在资源浏览窗口中右键单击刚建好的RQM->Properties或直接双击对应RQM,直接进去模型属性设置Model Properties,如下图所示：

现在你可以进行自己想要设置了。这里我们将Name,Comment分别进行基本设置，同时系统默认Name和Code是一致的，Name用来进行分析描述，为了形象明了可以使用中文，而Code则和后期的具体设计有关，如用于编码设计，一般多用英文加数字等标准命名(仅供参考)。

同时我们可以看到在新建RQM时也自动建立了一个模型视图(View),接下来我们就要对该视图(View)进行编辑以建立需求模型，根据前面需求模型简介介绍的相关RQM视图知识，需求模型可以用文档视图的形式表示，后续的大部分工作只有对View进行编辑就OK了！ 先看看完成后的需求视图吧！

这里的各系统需求是按层次排列的，这样也使需求文档视图能和标准的层次化Word/rtf文档能进行相互转换。可以通过视图上方的工具栏进行全面的需求模型建设。

添加需求(Requirement)：

点击需求文档视图工具栏上”Insert a Row”工具或点击需求文档视图的空白区 这样一个预先默认自定义的需求已经添加在文档视图中，如下所示：

编辑需求属性

双击需求TitleID左边的箭头(arrow)或单击需求文档视图工具栏最左边的Properties工具即进入属性属性编辑。

其中除了TitleID栏之外每栏都处于可编辑状态的。

注：箭头所在行为选中行

属性各栏目对应着文档视图中的各可编辑栏。这里我们可以设置各需求的详细内容和描述信息，比如标题(Title),需求描述(Description),优先级(Priority),风险(Risk),状态(Status),工作量(Workload)等详细内容。详细设置信息请参考示例文件。

若要更改文档视图中的可见栏目，可以通过单击需求文档视图工具栏中Customize Columns and Filter工具，进入

现在可以选择您想要显示的栏目了。

这样我们就基本上完成了系统需求的设计过程，依此多次操作完成如下系统需求文档视图基本框架：

后面的工作就是对其中各Requirement做进一步的细化，对各需求模块做更为细致的划分，即分层细化，这样也和层次化的文档吻合。这里我们以对Functional Requements的设计为例进行讲解，先看看细化完成后的需求文档视图(部分)：

现在让我们开始吧！ 方法一：

需求文档视图，选中Functional Requirements->点击视图工具栏”Insert Sub-Object”工具(而不是”Insert a Row”工具),这样就在Functional Requirements中插入了一个子对象。 方法二：

于左边资源管理窗口Requirements目录下右键单击相应需求名称->New->Requirement即可。如下图：

现在只要对新插入的子对象进行详细的内容编辑设计即可，同样地我们也可以对各子对象通过再次添加子对象作进一步的细化工作。

如果要提升或降低某部分的需求层次，则可以通过工具栏中的Promote和Demote来实现调整。

定义Users和Groups

Users（用户） 指在一个需求模型中至少和一个已定义需求有关的人的集合。

Groups（组） 指专属于开发进程中一个或多个方面的用户类别。每个用户组要与需求模型中至少一个已定义需求有关。 新建User/Group

在资源浏览窗口中，右键单击模型名称（图标）-->New?User/Group,打开User或Group属性窗口，输入相应名称和代码名，确定即完成新建。

同样也可在菜单栏选择”Model”?Users/Groups完成新建过程。

下一步是将相应的User与Group联系，添加进Group中，打开相应的Group属性，选择Group Users属性栏

点击属性工具栏中”Add Objects”工具，从中选择您要添加的User对象，当然只有在您已经建立了相应的User对象时才会显示User成员列表。

现在选择您需要添加的User对象，确定就可以了。 建立Business rules(业务规则)

业务规则是对为了满足业务需求，模型应该包括的特定内容或关于如何构建模型方面的描述清单。在这里的示例模型中，我们要定义关于论坛积分制度的业务规则，具体业务规则内容见参考文档。 在Requirement Model状态下，PowerDesgner默认Businss为不可用状态，为此我们需要通过新建Extended model definition（扩展模型定义）来激活Business rules。 步骤如下：

选择菜单栏”Model”? Extended Model Definitions，这时打开List of Extended Model Definitions，通过选择其工具栏中”Add a Row”工具，如下图：

点击Apply即在资源浏览窗口中添加Extended Model Definitions目录。

在资源浏览器中打开Extended Model Definitions目录，双击相应扩展模型定义左边图标

即打开Extended Model Definition Propreties

现在可以在右边输入extended model definition的Name,Code等信息。

选择左边窗口中”Profile”目录，右键单击在上下文菜单中选择”Add Metaclasses…”，这时可以看到Metaclass Selection对话框，选择PdCommon页，在Metaclass选择列表中选定BusinessRule

点击OK,现在可以在Profile目录下看到BusinessRule了，点击OK!已经完成了BusinessRule的激活。 完成上述激活步骤后我们就可以执行Business Rules的新建了。

在资源浏览器窗口中右键单击当前需求模型->选择”New”,或通过选择菜单栏上Model,你可以看到Business Rule(s)选项了，选择执行，设定详细业务规则属性内容就OK了，示例模型中我们完成了三个关于论坛积分制度方面的业务规则，可以查看参考文档，不再赘述！ 接下来我们为示例模型添加术语表(glossary term)

选择菜单栏Model->Glossary terms,进入List of Glossary terms对话框

选择工具栏上”Add a Row”工具，进行glossary term编辑。 或通过资源浏览器中也同样能执行添加术语操作。

若目标系统比较大，功能较多，也可以通过在系统模型中添加文件夹(package)来方便管理，也能使整个模型更清晰，具有层次性。

到这我们就已经基本完成了整个需求模型，接下来让我们来与word文档协调工作且生成内容全面的需求报告文档。

从需求模型生成Word文档

资源浏览窗口中，右键单击当前模型名称或图标->选择”Export as Word Document”

或在菜单栏中选择Tools->Export as Word Document...，这时文档生成就开始执行，输出窗口会显示对当前模型的检验信息，这里我们对其中的Warning就忽略不作考虑了。 片刻后会弹出

选择空白文档，单击确定，你可以看到文档输出了！ 生成的文档如

其中红色部分文字表示与当前模型联接的信息，如果已经确定需求模型，要生成最终文档作为分析成果，可以通过在MS Word菜单栏上选择”Requirements”->Detach the Document from the Requirements Model，这样就实现了最终文档与需求模型的分离，同时生成的文档也没有那些红色的联接信息了。 在没有将文档与模型分离时，我们还可能在PowerDesigner中对需求模型进行修改，这时我们可以对文档执行更新操作，同时对符合层次化标准的Word文档，也可以将其转化为相应的需求模型。 需求模型的个人见解就到此为止，要申明的是：以上内容只是对PowerDesigner提供的需求建模功能的大概说明，其中太多细节还需日后使用过程中慢慢掌握。

生成模型报告

文档生成Report

个人觉得有必要将Report（文档生成）提前讲解，毕竟软件工程的任何阶段都会输出相应文档，PowerDesigner支持生成RTF和HTML两种格式文档。

下面以刚完成的示例论坛系统的需求模型为例讲解。

PowerDesigner提供对Report的操作有关于Report Template Editor(报告模板编辑器)，Report Template(报告模板)，Report Editor(报告编辑器)，Multi-Model Report Editor（多模型报告编辑器），Report Language Editor（报告语言编辑器）

1． 使用Report Template Editor（报告模板编辑器） 打开Report Template Editor（报告模板编辑器）

（1）选择Tools->Resources->Report Templates,可以打开List of Report Templates（报告模板列表），列表显示出当前系统中存在的报告模板，如下图示：

（2）在Type（类型）下拉列表中选择相应的模板类型，可用模板中会显示对应您选择模板类型的模板，同时您也可以通过单击模板列表工具栏上的New工具新建您所需要的模板。

（3）选择相应模板

（4）通过单击工具栏上Properties工具或直接双击所选定模板，进入相应模板属性编辑器。其中左边Available items为可用项目，右边Template items为当前模板中项目，表示出该报告模板的结构。

现在你可以对该报告模板进行编辑修改！

也可以通过选择Model->Reports打开List of Reports（报告列表），再选择报告列表工具栏上Manage Report Templates（管理报告模板）工具打开List of Report Templates（报告模板列表）。 2． 标准报告模板（Standard report templates）

PowerDesigner默认自带了一系列的标准报告模板，其模板安装目录在Sybase\\PowerDesigner Trial 11\\Resource Files\\Report Templates下。

其中每种类型的模板都包含三种类型的标准模板，如下表所示： 模板类型 Full Standard List 3． 创建报告模板

报告模板是一种可以用来快速生成报告文档的文件，你可以使用PowerDesigner自带的一些标准模板或创建你自己的模板。创建模板时需要指明你在报告中需要包含的信息，同时也可以通过选择一种你想要语言用以显示报告文档。

（1） 选择Tools->Resources->Report Templates,打开了List of Report Templates窗口

命名规则 modelFULlanguage.RTP modelSTDlanguage.RTP modelLISlanguage.RTP 所生成报告内容 目录，所有主要的模型项目 目录，模型图，包图和大部分List对象 标题对象，所有的List对象

（2） 工具栏中New工具，即打开Report Template Type窗口

（3） 输入相应的模板名称，选择语言种类同时在模板列表中选择模板类别

（4） 单击OK即进去Report Template Editor（报告模板编辑器），现在你可以将想要在模板中显示的

项目进行添加调整了。

（5） 完成模板编辑后，选择File->Save,就可以将你所编辑好的报告模板保存为.rtp文件。

使用报告编辑器（Using the Report Editors） 1．创建模型报告

你可以通过使用报告编辑器创建模型报告和多模型编辑器创建多模型报告，但是当你要创建报告时，在当前workspace中必须打开至少一个模型且要有一个默认生成节点。 这里我们对前期需求模型创建报告文档作为示例。 （1）Model->Reports,打开List of Reports窗口

（2）单击工具栏上New工具，弹出New Report对话框，输入对应名称，选择语言类别和报告模板。

（3）单击OK,即完成报告新建工作，这里我选择的报告模板为None,接下来我们对报告内容及节点进行编辑。

如上图对目标报告文档内容进行编辑，报告节点设计完毕后就可以生成html或rtf报告了。

（4）选择Report面板中的Generate HTML或Generate RTF即可生成相应格式报告文档，若要预览文档，可以选择面板中的Print Preview工具。

最终生成的html文档如下图示：

创建多模型报告（Multi-Model Report）

多模型报告能够通过使用Section在同一个报告中包含不同类型模型中的对象，将不同模型结合起来提供一个全局视角的综合报告。但是每个Section只能是一种模型类型，并且只能使用一个模板类型，被使用模型必须在当前workspace中处于打开状态。

（1）在当前workspace中打开一些需要参与多模型报告的模型，选择菜单栏中File->New, 在弹出的新建窗口中选择Multi-Model Report。

或通过右键单击当前Workspace->New->Multi-Model Report亦能完成多模型报告的新建。 （2）弹出新建多模型报告窗口。

（3）输入报告名称，选择语言种类，同时在Model name的下拉框中选择一个Section将要描述的模型。同时根据可以根据需要在Report template下拉列表中选择相应的报告模板。 （4）点击OK,确认操作！这时就已经打开多模型报告编辑窗口，如下图示：

（5）基本的多模型报告框架已经建好，下一步就是对其中Section进行设置编辑即可。根据需要加入不同模型创建适当Section，基本操作与普通单模型报告类似！

处理Section

每个报告文件至少要包含一个Section，通过使用Section可以使模型设计者将目标模型分为几个不同部分，便于分析模型各部分功能，因此恰当地使用Section可以让报告文档更加清晰，具有层次性。可以通过两种方式创建Section（节）:

1. 创建一个空白Section

2. 创建一个基于模板（Template）的Section

当你创建新Section时，模板列属性默认被设置为None,且应用模板选项框被自动选取。 创建Section

（1） 在Report Editor编辑窗口下，选择Report->Sections,即弹出List of Report Sections窗口，其中

Section列表包含一默认生成的Section.

（2） 输入Section名称，如果没有更改输入名称系统将会在报告项目面板（Report Items）中使用默

认名称。

（3） 如果当前报告为多模型报告，则可以在模型栏（Model column）中选择对应模型类型，多模型

报告可能包括多种模型类型的Section,如OOM,PDM,CDM等，但必须这些模型在当前Workspace中都处于打开状态。若当前报告为单模型报告，则Model列为不可选，系统自动设置为当前模型。

（4） 单击模板栏（Template）,选择需要的模板类型，可选项有None,Full Requirement report, List

Requirement report,Standard Requirement report。若选择None则创建空白Section.,同时Apply Template选项框为默认选取状态。

（5） 以上操作已经完成对当前Section的设置，要再次添加Scetion则通过选取工具栏上Add a Row

或Insert a Row工具添加新Section,同时再次执行（1）---（4）步骤设置其属性。

（6） 单击OK，现在已经完成多个Section的创建。其中每个Section在报告编辑器（Report Editor）

中显示为Report Items面板底部的Tab页中，如下图所示：

将报告中Section创建为模板

经常我们需要将已经设计好的Section供以后在其他模型中使用，为此我们可以将创建好的Section保存为模板。

（1） 单击需要保存的Section的Tab页（在Report Items面板底部的Tab页）

（2） 选择工具栏上Report->Create Template From Section,打开报告模板编辑器（Report Template

Editor）页面，则原来在报告项目（Report Items）中显示的项目（Items）这时显示在模板项目面板中。

（3） 确认模板项目后，选择菜单栏上File->Save,即打开保存文件对话框。 （4） 输入相应模板名称，单击保存即可。

使用报告语言编辑器（Using the Report Language Editor）

通过使用报告语言编辑器可以创建和修改报告语言的源文件（Resource files），报告语言源文件是以XRL为后缀的XML格式文件，其中包含了报告中所有可打印文本和它们的一些默认数据，报告语言源文件保存在中心区域且能够被任何模型报告共享使用，从而保证了数据一致性，节省了用户创建编辑报告文档的时间。PowerDesigner在安装目录\\Sybase\\PowerDesigner Trial 11\\Resource Files\\Report Languages下自带了一系列的报告语言源文件。我们也可以通过使用报告语言编辑器（Report Language Editor）创建符合自己需求的文档报告源文件。

打开报告语言编辑器

（1） 选择菜单栏上Tools->Resources->Report Languages,即打开报告语言列表（List of Report

Languages）窗口，其中显示出当前系统具有的所有报告语言列表。

（2） 选择某种报告语言

（3） 单击工具栏上Properties工具，或双击该行，打开Report Language Properties窗口

同样你也可以通过报告编辑器打开报告语言编辑窗口：选择菜单栏上Report->Edit Current Language，不过这时打开的语言种类是针对当前选择语言。

报告语言编辑器（Report Language Editor）由两个不同部分组成：根据语言类别和实体导航的左侧目录树与显示相关信息的右侧树型视图。

左边目录树主要包含以下三个部分 类别 对象属性 描述 包含每个模型中所有和对象相关联的字符串，如对象属性的名称，代码 报告标题 包含每个模型中所有与报告项目相关联的字符串，如组织单位注释等 值映射 包含所有与用于属性数值的关键字相关联的字符串，如未定义，或不存在等 Cards,checks,lists中对象属性数值的关键字翻译 所有报告项目的标题翻译 翻译用途 Cards,checks,list中对象属性的名称翻译 Object Attrbutes和Report Titles分别包含PowerDesigner每个模型特定特征的种类。Value Mapping类别则包含具有一个标准入口的子类别：

Forms：Cards和Checks中的对象属性的关键字。 Lists：Lists中的对象属性的关键字。

PowerDesigner提供自带的报告语言源文件还是很符合语言习惯的，一般来说不用进行更改订制，但选择中文模板时会出现一些问题，比较常见的就是如Primary Key,Foreign Key等翻译存在一些差异。下面以简体中文模板对我们示例系统的PDM建立系统数据字典报告文件。 已经完成的示例PDM关系图如下：

下面对每个数据表和各数据表的字段生成数据字典：

（1）为了方便演示，我们选择新建空白的报告模板，只将表格清单（List of Tables），表格列清单（List of Table Columns-表%PARENT%的列清单）和关系图表（Diagram）添加至报告项目面板（Report Items）。

（2）右键选择List of Table Columns-表%PARENT%的列清单->Layout,弹出要显示对象列表。

（3）在列表中选择需要显示的对象。 这时直接生成RTF文档，看看文档效果。

看到上述文档效果估计很多朋友都会很失望的，没关系，现在让我们一步步来完善！

（1） 选择菜单栏上Tools->Resources->Report Languages…打开List of Report Languages（报告语言列

表）窗口，这里我们选择双击Simplified Chinese,以打开报告语言属性窗口。

（2） 选择Object Attributes\\Physical Data Model\\Column\\Primary,将Value中”主要的”改为”主键”。

（3） 选择Object Attributes\\Physical Data Model\\Column\\ForeignKey，将Value”外来键”改为”外键” （4） 选择Report Titles\\Physical Data Model\\Table\\Columns list，将Value”表格%PARENT%的专栏清

单”改为” 表%PARENT%的列清单”.

（5） 双击报告项目面板中的”Table-表格%ITEM%”对象，在弹出的编辑窗口中将”表格%ITEM%”改

为”表%ITEM%”，如下图：

（6） 当然还可以通过报告源文件编辑器进行其它报告项目显示方面的更改，同时也可以使用如其它

常用软件中的查找替换功能，可以在报告语言属性窗口找到相应工具。不过这时执行的是全局替换，使用前应小心。

（7） 通常在进行报告语言属性进行更改之后，为了保证软件自带的报告语言源文件（.xrl文件）不

发生变更，可以选择”Save As…”命令。不过必须在语言报告属性窗口中执行，如下图：

（8） 调整各属性列宽度，右键单击报告项目（Report Items）面板中”List of Table Columns-表%PARENT%的列清单”，在弹出菜单中选择”Layout”，打开List Layout窗口，如下图：

现在调整Width列的数值就行了，支持百分比和实际宽度两种属性。现在可以看看生成的文档了，如下图示：

为了使显示效果更简洁点，不妨将其中大部分的FALSE不显示，TRUE也只用T代换，为此我们需要将系统的TRUE和FALSE进行转换，需要在报告语言属性中更改映射表。

（9） 在报告语言属性窗口中选择”Values Mapping\\Lists\\Standard”,添加True和FALSE映射即可，如

下图：

现在在进行文档生成，基本上满足正式文档要求。

当然关于模型报告还有很多细节问题，这里不能做到一一分析，可以在日后实际使用中慢慢发掘，毕竟运用才是关键！好了，这一小节就到此为止！

概念数据模型CDM(Conceptual Database Model)

以下我们要完成对示例论坛系统的数据库设计工作，首先让我们建立目标系统的概念数据模型(CDM)。

在进行相关CDM演示之前，让我先简要介绍概念数据模型（CDM）的相关概念。我们进行数据库设计时，一般都是概念层次（Conceptual level）开始的。在概念层次上，你无须考虑数据库的实际物理执

行细节。概念模型（CDM）描述了与任何软件或数据存储系统无关的数据库整体逻辑结构，通常包含了与物理数据库无关的数据对象，提供了一种对用于运行企业或业务行为的形象化的表达方式。

CDM功能：

（1）通过创建实体关系图表（E-R）来描述数据的组织结构。 （2）能够校验数据设计的合理性。

（3）生成指定了相应物理实现数据库的物理数据模型（PDM） （4）能够生成用UML标准描述CDM中对象的面向对象模型（OOM）

（5）为在不同的设计阶段创建另一个模型版本，可以生成概念数据模型（CDM）

关于Palette工具面板中含义简介：

新建CDM

（1） 选择File->New，打开New窗口，在左边模型选择列中选中Conceptual Data Model,单击OK，

即确认创建概念数据模型。

（2） 双击资源浏览窗口中新创建的CDM名称图标，打开CDM模型属性窗口，进行相关属性信息

设置。如下图：

对刚创建的CDM进行详细之前有必要先说说有关实体属性命名问题。

PowerDesigner默认在CDM中不能存在相同名称的实体属性，这也是考虑到可能产生的一些如主键外键等名称冲突问题，但当我们进行实际数据库设计时，可能会多次使用相同数据项（DataItem）便于理解各实体。为此需要对更改PowerDesigner相关设置。软件默认为DataItem不能重复使用(重名)，需要进行以下操作：

选择Tools->Model Options,

在Model Setting设置目录中，将Data Item下的Unique Code取消选中即可，系统默认将Unique Code和

Allow Reuse均选中。

同时该设置均是面向特定模型的，即针对当前模型有效，若希望在其它模型中也有此命名设置，则需要重新进行设置。不过在Check Model时，如果选择全部Check，则依旧会报DataItem重名的错误信息，这时需要我们在人为检查确认数据项无误时，可以在选择不对DataItem不检查，如下图示：

各种数据类型对应匹配(这里只给出与SQL Server中的常用对应类型，其它DBMS可以使用类似处理)

实体及各类关系

实体（Entity）

（1） 在新创建的CDM中，选择Palette工具面板中的Entity工具，再在模型区域淡季鼠标左键，即

添加了一个实体图符。

（2） 单击鼠标右键或单击面板中Pointer工具，使鼠标处于选择图形状态。 （3） 双击新创建的实体图符，打开实体属性窗口，输入实体名称和代码。 （4） 单击OK，即完成实体创建过程。

继续上述操作，创建多个实体，分别设置为不同名称，具体信息参考示例文档。 实体创建完成后资源浏览窗口中层次结构如下所示：

现在编辑各实体的详细内容，如属性组，实体间关系等。

实体属性（Entity Attributes）

（1） 以User实体为例，打开实体User属性窗口，进入Attributes属性页，如下图示：

（2） 单击属性窗口工具栏中Add a Row工具，即在属性实体属性列表中添加了一个属性，同时设置

该属性相关信息，如数据类型，是否为主标识符，是否不可为空等。

（3） 详细设置新添加的属性为UserID,作为系统唯一标识区别的用户编号，同时选择P,M,数据类型

（DataType）选择Integer。如下图：

（4）对属性列进行更为详细的设置，可以通过单击对应属性列左边箭头，进入Attribute Properties窗口，可以进行更为精确详细的设置，如数据上下限，精度等。如下图：

（5）同时若要更改实体属性列表中显示的相关选项可以通过单击工具栏中Customize Columns and Filter工具以打开Customize Columns and Filter窗口

只要在列表中选择想要显示的项目即可完成设置。

标识符（Identifiers）

标识符是能够用于唯一标识实体的每条记录的一个实体属性或实体属性的集合，CDM中的标识符等同于PDM中的主键（Primary Key）或候选键（Alternate Key）。每个实体至少要有一个标识符，若一个实体中只存在一个标识符，它就自动被默认指派为该实体的主标识符（Primary Identifier）。 指定相应标识符

（1） 在双击图表中对应实体以显示实体属性窗口。

（2） 在当前实体属性窗口中选择Identifiers属性栏，如下所示：

（3） 可以通过单击工具栏上Property 工具或双击所要选择的标识符栏，进入标识符属性编辑窗口。 （4） 选择Attributes属性，可以看到当前标识符所关联的属性列表，如下图：

（5） 单击工具栏中Add Attributes工具，即可以进行为当前标识符添加属性。

关系（Relationship）

关系（Relationship）表示实体间的连接。如在一个人力资源管理系统的CDM中，员工是团队中的成员，关系”Member”连接了员工（Employee）和团队（Team），这种关系表述了每个雇员在团队中工作且每个团队都由员工组成。

建立关系（Relationship）这里以用户实体（User）和帖子实体（Post）为例 （1） 在Palette面板中左键单击Relationship工具

（2） 在实体User上单击鼠标左键，按住不放，拖拽鼠标至实体Post上后才松开，这样即建立了User

和Post之间的Relationship.

（3） 单击鼠标右键或左键单击Palette面板上的Pointer工具，使鼠标返回至选择状态。

（4） 双击图表中的刚建立的两实体之间关系（Relationship）以打开关系属性窗口，便于对关系进行

详细定义。

（5） 输入相应的Name和Code，选择Detail选项，进入如下属性编辑页：

（6） 选择One-Many选项，因为User和Post为”一对多”关系，且每一条Post均对应有User，因此

User to Post角色的基数（Cardinality）下拉列表中选择”0,n”,在Post to User角色的基数列表中选择”1,1”。同时Role name中输入相应的角色名称。

（7） 确定修改后，单击OK,即可在模型图表中显示新建的Relationship。

（8） 若要自定义关系显示信息，可通过选择菜单栏中Tools->Display Preferences，打开Display

Preferences窗口，在左边树型菜单中选择Object->Relationship，这时即可在右侧选择你所要显示的项目了。

当然你也可以选择其它节点，实现对图符的显示属性设置。

各种类型关系（Relationship）

这部分是比较令人头疼的，不太好懂，需要投入较多时间研究。 自反关系（Reflexive relationship）

是一种实体和它自身的关系。这里用员工的管理概念来表述管理人员管理员工，同时管理人员也属于员工范畴。

（1） 左键单击Palette面板中Relationship工具

（2） 在实体内单击鼠标左键且按住不放，将鼠标拖放至实体旁的空白位置后松开鼠标。 （3） 再次单击实体即成功创建自反关系。

不过这时自反关系的图符不太雅观，可以通过先选定需要更改的图符，然后选择Display Preferences->Format，单击Modify以打开Symbol Format窗口，然后更改Line Style属性中的Corners下拉框中选项

确认修改后，最后在单击Display Preferences窗口的OK按纽后会弹出Change Formats选择对话框，若只要将修改应该至当前的自反图符，只需选择所选定图符（Selected symbols）即可。

依赖关系（Dependent relationship） 支配关系（Dominant relationship） 强制关系（Mandatory relationship）

以上其它关系不再赘述，需要在实际使用过程加以运用才能加深进一步的理解，同时以上知识点和关系型数据库的理论知识密切相关，PowerDesigner的这些功能只是对应于这些理论的一种运用映射。

关系（Association）

Association也是一种实体间的连接，在Merise模型方法学理论中，Association是一种用于连接分别代表明确定义的对象的不同实体，这种连接仅仅通过另一个实体不能很明确地表达，而通过”事件（Event）”连接来表示。下面通过示例论坛系统的用户实体（User）和论坛栏目（ForumColumn）实体的Association来讲解。示例论坛系统中通过一个Association来表示目标系统中论坛栏目对应的版主关系，包括了属性创建时间（DateCreated）用于记录版主添加的时间。

创建Association

（1） 在Palette面板中单击Association Link工具

（2） 在实体User内单击鼠标左键且按住不放，拖放鼠标至另一实体ForumColumn上，松开鼠标左

键，即在两实体间创建了Association。如下图：

（3） 双击模型图表中刚创建的Association图符以打开Association Properties窗口。

（4） 输入Association的Name和Code，选择Attributes属性页，添加实体属性DateCreated，并设

置相关属性，如下图：

（5） 同时可以通过在模型图表中双击相应的Association Link来打开Association Link Properties来编

辑连接属性：

按类似方法可以创建论坛栏目实体（ForumColumn）和角色实体（Role）之间的Association。

继承（Inheritance）

Inheritance允许你定义一个实体为另一个更一般（常规）的特例。涉及到继承的实体之间有着共同相似的特征，但却是不同的。超类（或父类）指那些包含共同特征的更一般的类，而特例则被成为子类型，包含了一些更为具体和特殊的特例。

关于继承方面的例子不少，稍具有面向对象观念的都应该能够理解，不再赘述。 而PowerDesigner中关于继承方面的操作过程在这只作简要介绍： （1） 在Palette面板中单击Inheritance工具

（2） 左键单击子类型，按住鼠标不放，拖放至鼠标至父类型实体图符中，松开鼠标，即完成了一个

Inheritance Link的创建

（3） 要再次添加另一子实体时，可以单击Inheritance工具，从半圆形图处拖动鼠标至另一子类型实

体，然后松开鼠标即可。

（4） 双击新创建的继承图符或实体之间的连接线即可打开弹出Inheritance Properties编辑窗口。

（5） 输入相应Name和Code，完成基本设置，单击OK，即完成创建过程。

现在已经基本上完成了目标系统的概念建模过程，为此下一步我们需要校验已经设计好的模型，便于能够正确地转换为物理数据模型（PDM）。 检验模型（Check）

（1） 选择Tools->Check Models，打开Check Model Parameters窗口，如下图：

在这你可以对需要Check的项目进行自定义选择。

（2） 确认选择后，单击OK,则PowerDesigner开始对模型进行检验。 （3） 完成检验后，PowerDesigner会将检验结果在输出列表中显示出来

我们可以根据所列出的错误信息对模型进行修改，错误信息分别有Error,Warning, Automatic correction三种，同时只要经过检验后没有Error一类的错误信息，我们就可以将该CDM转化为对应PDM。

生成PDM

当你从一个CDM生成PDM时，PowerDesigner将CDM中的对象和数据类型转换为PDM对象和当前DBMS支持的数据类型。

PDM转换概念对象到物理对象的对象关系如下表： CDM对象 实体（Entity） 实体属性（Entity Attribute） 主标识符（Primary Identifier） 在PDM中生成的对象 表（Table） 列Table Column） 根据是否为依赖关系确定是主键或外键 标识符（Identifier） 关系（Relationship）

同一个表中的两列不能有相同的名称，如果因为外键迁移而导致列名冲突，PowerDesigner会自动对迁移列重命名，新列名由原始实体名的前三个字母加属性的代码名组成。主标识符在生成PDM中的主键和外键，非主标识符则对应生成候选键。

在PDM中生成的键类型取决于CDM中用于定义一个Relationship的基数和依赖类型。 1． 非依赖性一对多关系（Independent one-to-many relationships）

在非依赖性关系中，”一”端的实体主标识符将转化为：

（1） 由关系中”一（one）”端的实体生成的表的主键（Primary key） （2） 由关系中”多（many）”端的实体生成的表的外键（Foreign key）。 如下图所示：

候选键（Alternate key） 引用（Reference） 备注

CDM中Independent one-to-many relationship

生成的PDM中的Independent one-to-many relationship 2． 依赖性一对多关系（Dependent one-to-many relationships）

在依赖性关系中，被依赖端的主标识符转化为主键，依赖端则产生一个与被依赖端主标识符同名称的字段同时作为同时作为依赖端的主键和外键，如果依赖端实体中已经存在主标识符转化为主键，则该键同主键共同组成主键，同时作为外键。

CDM中Dependent one-to-many relationship

生成的PDM中的Dependent one-to-many relationship

3． 非依赖性多对多关系（Independent many-to-many relationships）

在非依赖性多对多关系中，各实体的主标识符（Primary key）迁移至一个新生成的连接表中都作为外键，同时共同组成这个新连接表的主键，各实体的主标识符也转化为其所生成表的主键（Primary key）。下图所示CDM，每个雇员可以是一个或多个团队的成员，同时每个团队也可能包含一个或多个的雇员。

CDM中Dependent one-to-many relationship

生成的PDM中的Dependent one-to-many relationship

4． 非依赖性一对一关系（Independent one-to-one relationships）

在非依赖性一对一关系中，如果没有定义支配角色（Dominant role）的方向，则各实体的主标识符均自动迁移转化为另一实体生成的表的外键。

个人觉得在生成PDM过程中有关生成主键，外键等问题比较棘手，我自己在生成该示例论坛系统的PDM时就遇到这方面问题，后来在多次对一些设计得比较优秀的开源系统进行反向工程，然后慢慢研究借鉴，发现自己在设计过程的一些问题，因此觉得这方面只有多多研究才能逐渐得心应手。 准备差不多了，开始生成我们需要的PDM。

（1） 选择菜单栏上Tools->Generate Physical Data Model弹出PDM Generation Options窗口，如下图：

（2） 选择Generate Physical Data Midel，在DBMS下拉列表中选择相应的DBMS，输入新物理模型

的Name和Code.

（3） 若单击Configure Model Options则进入Model Options窗口，可以设置新物理模型的详细属性。 （4） 选择PDM Generation Options中的Detail页，设置目标PDM的属性细节。 （5） 单击Selection页，选择需要进行转化的对象。

（6） 确认各项设置后，单击确定。即生成相应的PDM模型。

生成PDM后，我们可能还会对前面的CDM进行更改，若要将所做的更改与所生成的PDM保持一致，这时可以对已有PDM进行更新。这时操作也很简单，Tools->Generate Physical Data Model，在打开的PDM Generation Options窗口中选择Update existing Physical Data Model，并通过Select model下拉框选择将要更新的PDM。如下图：

最后我们在CDM部分的工作应该就是根据所建立的概念模型生成文档了，文档是作为设计成果的输出，也用于开发小组成员交流的媒介，其重要性不能忽视。这方面我们可以参考前面生成报告（Report）方面的内容。

物理数据模型

PDM基础

PDM是用于定义详细定义物理结构和数据查询的数据库设计工具。你可以在PDM中使用不同类型的图表，这取决于你所要设计的目标数据库的类型。当今关于数据库方面比较热门的话题莫过于数据仓库，数据集市，OLAP，数据挖掘等内容了。而PowerDesigner对这几方面的设计都有很好的支持，分别支持了操作型数据库，数据仓库或数据集市，OLAP等类型数据库系统。相信大家都应该有所了解，关于这几个概念就不再赘述，本小节内容主要是涉及操作型数据库的专题。

PDM DBMS

PowerDesigner能够用于创建多种不同类型的DBMS，对于每种类型的DBMS，都包含一个标准定义文件用

于在PowerDesigner和DBMS中确定关联而提供一套接口。你可以修改装载在PowerDesigner中DBMS，对于每个你将要修改的初始DBMS，你都可以创建一个相应的新DBMS。

新建PDM

你可以通过三种方式新建PDM （1） 直接创建新PDM （2） 使用模板创建新PDM

（3） 通过现有基础创建新PDM，现有元素包括：数据库的反向工程，引入一Erwin模型，从现有

CDM或OOM自动生成，从V6版本的数据仓库分析模型迁移等。

下面只简要讲解概述其中一种PDM的创建过程：

（1） 选择New，即打开创建模型选项窗口，如下图：

（2）选择New model单选框。

（3）选择左边模型列表中Physical Data Model，同时在DBMS下拉列表中选择相应类型DBMS（当然你也可以在后面的过程中更改DBMS类型），

（4）在First diagram中选择Physical Diagram,其中列表中Multidimensional Diagram选项用于创建多维（Multidimensional）数据模型。

（5）单击”确认”，即完成PDM创建过程。

业务规则概念

业务规则是业务进程需要遵从的一些规则，它们可能是政府法令，客户需求或者内部的一些方针规范。业务规则通常来自于简单的观测，如”客户可以通过拨打免费热线下订单”，而在设计过程中，我们就就需要将该过程分解成更加详细的描述。如当下订单时客户需要提供什么样的信息或根据客户的信用度来判定客户能够订购多少产品。

业务规则能够规划并将模型文档化。如规则”一个雇员仅属于一个部门”可以帮你图形化地在一个雇员和一个部门之间建立联系。

业务规则用一种不易用图形化表达的信息补充模型图形，如有些规则以公式或验证规则的形式来表达一些特殊的物理概念，而这些技术表达方式通常不能通过图形化形式显示出来。也可以将业务规则和PDM中具体对象联系起来，如果建立了验证规则与列或域之间的联系，你就可以通过业务验证规则来检查参数。

创建业务规则（Business rule）

（1） 选择Model->Business Rules，打开List of Business Rules窗口，列表显示当前模型中存在的业

务规则，如下图：

（2） 单击工具栏中Add a Row工具或单击列表中一个空白行，即添加一个新业务规则。 （3） 输入相应的Name和Code，单击Apply，提交业务规则的新建。

（4） 双击所选择的业务规则或单击工具栏上Properties工具，打开业务规则属性（Business Rule

Properties）窗口，如下图所示：

（5） Type下拉列表中选择相应的业务规则方式，待选类别有定义（Definition），事实（Fact），公式

（Formula）,需求（Requirement），验证（Validation），约束（Constraint）。但只有验证（Validation）和约束（Constraint）类型的业务规则才能生成到数据库中。

（6） 选择 Expression属性窗口，有两种类型的业务规则表达式，分别为Client和Server。其中Server

部分为可以生成到数据库中，而Client部分则仅用于模型文档的生成。

（7） 设置完毕，单击”确认”，完成业务规则创建过程。

在PDM中应用业务规则

（1） 在当前模型图表中双击将要应用业务规则的对象，以打开该对象属性窗口。 （2） 选择Rules属性，列表中显示应用至该对象上的业务规则列表。 （3） 单击工具栏中Add Objects工具以显示业务规则列表。如下图：

（4） 选择你想要添加的应用于该对象的业务规则，单击OK。

（5） 在对象属性框中单击OK，即完成业务规则应用，若添加的是约束规则或验证规则，你可以通

过Preview选项看到业务规则生成的数据库代码。

建立物理图表（Physical Diagram）

由于PowerDesigner中CDM和PDM的很多操作类似，因此在后面的讲解中尽量简化一些操作细节。下面以PowerDesigner自带的示例模型Project Management为例讲解，该文件位于安装目录Sybase\\PowerDesigner Trial 11\\Examples下的project.pdm文件。

域（Domain）

域（Domain）可以帮助你确定模型中的信息类型。域定义了一组对列可用的数值，对列应用域可以简化对不同表中列的数据类型标准化工作。 创建域

（1） 选择Model->Domains以打开域列表（List of Domains）窗口。 （2） 单击工具栏中Add a Row工具，新建域。

（3） 输入相应的Name和Code，这里我们输入Identifier和ID。

（4） 单击Apply提交Domain的创建，单击工具栏中Properties工具以打开Domain Properties窗口，

如下图：

（5） 选择数据类型（Data type），设置Length等属性，同时可以选择Standard Checks属性页以编辑

详细约束。

（6） 单击OK，确认修改。 这样就已经完成域Identifier的创建过程。

修改Domain属性

（1） 选择Model->Domains以打开域列表（List of Domains）。 （2） 单击你想要修改的域对象，使目标域对象处于选择状态。

（3） 双击该域对象或单击工具栏中Properties工具以打开域属性（Domain Properties）窗口，现在可

以对域属性进行更改了。

（4） 确认更改后，点击”应用”，若该域已经被某些列使用，则会弹出下列窗口：

该窗口提示询问是否想要修改应用了该域的列的域属性。你可以选择你想要更新哪些使用该Domain的模型元素。

（5） 单击”确认”，完成修改。

同时我们也可以设置强制执行Domain的修改，即在域（Domain）定义发生更改时，数据类型就会强制自动改变。步骤如下：选择Tools->Model Options，打开Model Options窗口，选择左边树形子菜单中Column&Domain选项，如下图：

选择Enforce non-divergence，再选择相应模型元素即可，这样每次Domain发生更改后，对应使用了该Domain的模型元素就自动发生更改。

创建表（Table）

（1） 左键单击Palette面板中Table工具

（2） 左键单击模型图表空白区域以在模型图表中新建Table图符。

（3） 单击鼠标右键或单击Palette面板中Pointer工具，使鼠标处于选择状态。 （4） 左键双击模型图表中刚创建的Table图符以打开Table属性窗口，如下图：

（5） 输入相应表的名称和代码。

（6） 其中Number选项为物理数据库中表的记录的大概估计，用于后述的估计数据库的大小规模；

Generate选项表示是否在物理数据库中生成该表。这里我们将Number设置为1000，勾选上Generate。

（7） 单击”确定”，即完成表Employee的创建。

添加编辑列

（1） 打开表Employee的属性窗口，选择Columns属性页，如下所示：

（2） 这里我们需要使用域Identifier，前面我们已经完成了域的创建工作，这里可以直接应用于列中。

先设置Columns属性列表中显示Domain，单击工具栏上Customize Columns and Filter工具，弹出Customize Columns and Filter窗口，在列表中选择Domain，如下图：

（3） 单击OK,则这时Columns属性页中显示Domain属性。

（4） 编辑列Employee属性，在Domain下拉列表中选择Identifier，如下图：

（5）单击确认，即将域（Domain）Identifier应用至该列。

定义引用（Reference）

引用（Reference）是一个父表（parent table）和子表（child table）之间的连接，它定义了在数据表各列用于主键，候选键，外键或用户指定列之间的完整性约束。当两个表中的数据列通过了引用（Reference）连接时，子表中的该列的每个值都对应了父表中对应列的一个相同的值。

在一对引用关系中，数据列之间通过连接（Join）连接，根据在主键/候选键中列的数目，指定列的数目，一个引用关系中可能包含一个或多个连接（Join）。

建立引用（Reference）

（1） 选择Palette面板中Reference工具

（2） 在模型图表区域，左键单击子表图符并按住鼠标不放，拖动鼠标至父表图符，松开鼠标，即在

两表之间建立了引用关系。

（3） 单击Palette面板中Pointer工具或单击鼠标右键使鼠标处于选择状态。

（4） 双击模型图表中的引用（Reference）连接图符以打开引用属性（Reference Properties）窗口，

如下图：

（5） 输入相应的引用（Reference）Name和Code。 （６）定义引用连接（Join），选择Joins属性页，如下图所示：

（７）在Parent key选项列表中选择相应的父表键，此时列表中显示出当前连接（Join）所连接的父表列和对应的子表列。

（８）现在可以对对应于每个父表列（Parent Table Column）的子表列（Child Table Column）进行选择更改。

重建引用（Rebuilding references）

有时我们进行反向工程时可能不会将所有的对象都添加进去，这时可能会遇到引用冲突问题，即在已经添加进反向工程的项目中可能包含一些具有引用关系的表，而这些引用关系与没有添加进反向工程中。这时我们可以借助PowerDesigner提供的重建引用（Rebuilding references）功能，对引用进行选择重建。

（１） 选择Tools->Rebuild Objects->Rebuild References，弹出重建引用窗口。

（２） 在General属性页中选择重建引用方式（其中Delete and rebuild方式为删除所有现有引用，

再根据匹配键列创建新的引用；Perserve方式为保留所有现有引用，且根据匹配键列建立新的引用）。

（３） 选择Selection属性页，根据需要选择你要重建引用的表。

（４） 确认选择后，单击”确认”按钮，若你选择的重建方式为Delete and rebuild，则会弹出如下确

认对话框：

（５） 确认重建，单击”是(Y)”即可完成重建引用。

引用完整性（Referential Integrity）

引用完整性是管理数据主键，候选键和外键之间数据一致性的一系列规则，它定义了当你更新或删除父表中的一个被引用的列，或从父表中删除一条包含被引用的列的数据记录时要发生的动作。有以下两种方式实现引用完整性：

Declarative 引用完整性通过详细引用来定义，当引用生成目标DBMS，它评估引用的正确性并生成相应的错误消息。

Using triggers 通过在引用属性窗口中定义的基于完整性约束的触发器（Trigger）来实现引用完整性约束。触发器用于衡量引用的正确性并生成适当的用户自定义错误信息。

注：对于目标数据库你可以作为生成目标数据库的选项而定义引用完整性，但并不是所有的类型的DBMS都支持使用引用完整性作为生成数据库的选项，此时当你生成这些类型DBMS的SQL脚本时，其中不会包含引用完整性的定义。

本文来源：https://www.bwwdw.com/article/wbrp.html