PowerDesigner学习--概要介绍

定义实体

用鼠标双击实体的符号，可以进入实体的属性页。

1. General 项目

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

   Code：在模型转化时一般作为对象的物理名称，比如把实体属性的Code转化为

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

2. Attributes 项目

窗口中下面表格里的各项很类似于一个表结构的定义，但数据类型是经过抽象化的，采用独立的表示方法，不与任何一个具体的数据库系统相关。

在此项目中为当前实体添加属性。

后面的三列CheckBox分别代表：

• M：此属性不允许为空值
• P：此属性为主键标识
• D：为可显示属性

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

管理 ，权限已经分配给了多个不同的角色，一个用户帐号至少属于一个角色，并 且可能会同时属于多个角色，一个角色可以包含0个或多个用户帐号。根据以上描述，我们添加一个实体“Role”，它与实体“User”之间是n..n 的关系，为了表达这种关系，我们增加一个“Association”并分别使用“Association Link”与其他两个实体建立关系，

定义关系

双击关系（Relationship）的符号，进入关系的属性页，

1. General 项目

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

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

2. Detail 项目

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

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

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

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

 

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

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

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

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

企业中拥有帐号的雇员在系统中具有不同的操作权限，这通过用户角色来进行

数据库 中的列名，当然我们现在不必为了这个实体将来叫什么而费神，一般采取与Name一致即可。

数据库设计 工具对比

PowerDesign：PowerDesign是 Sybase推出的主打数据库设计工具。PowerDesign致力于采用基于Entiry-Relation的数据模型，分别从概念数据模型 (Conceptual Data Model)和物理数据模型(Physical Data Model)两个层次对数据库进行设计。概念数据模型描述的是独立于数据库管理系统(DBMS)的实体定义和实体关系定义。物理数据模型是在概念数据模型的基础上针对目标数据库管理系统的具体化。

ERWin：这个是CA公司的拳头产品，它有一个兄弟是BPWin,这个是CASE工具的一个里程碑似的产品。ERWin界面相当简洁漂亮，也是采用ER模型，如果你是开发中小型数据库，极力推荐ERWin，它的Diagram给人的感觉十分清晰。在一个实体中，不同的属性类型采用可定制的图标显示，实体与实体的关系也一目了然。ERWin不适合非常大的数据库的设计，因为它对 Diagram欠缺更多层次的组织。

如何一次性将表结构的脚本导出来？
Database --->Generate Database ---> Genarate Script. 就可实现。

Name用中文英文以便查询、写程序的时候方便， Code才是最终产生的Table Name

PowerDesigner中建了模型，如何把它作为文档导出？
利用REPORT。选择一个模板，然后就生成了RTF或是HTM格式的文档

如何将已经存在的数据库所有表，导入到PowerDesign中？
用PD里的反向工程file--->reverse engineering ===> and go on

概念数据模型(CDM)
CDM表现数据库的全部逻辑的结构,与任何的软件或数据储藏结构无关。一个概念模型经常包括在物理数据库中仍然不实现的数据对象。它给运行计划或业务活动的数据一个正式表现方式。不考虑物理实现细节，只考虑实体之间的关系。

物理数据模型 (PDM)
PDM叙述数据库的物理实现。主要目的是把CDM中建立的现实世界模型生成特定的DBMS脚本，产生数据库中保存信息的储存结构，保证数据在数据库中的完整性和一致性。

面向对象模型 (OOM)
一个OOM包含一系列包，类，接口和他们的关系。这些对象一起形成所有的(或部份)一个软件系统的逻辑的设计视图的类结构。一个OOM本质上是软件系统的一个静态的概念模型。

业务程序模型(BPM)
BPM描述业务的各种不同内在任务和内在流程，而且客户如何以这些任务和流程互相影响。BPM是从业务合伙人的观点来看业务逻辑和规则的概念模型，使用一个图表描述程序，流程，信息和合作协议之间的交互作用。

正向工程
你能直接地从PDM产生一个数据库, 或产生一个能在你的数据库管理系统环境中运行的数据库脚本。可以生成数据库脚本,如果选择ODBC方式,则可以直接连接到数据库,从而直接产生数据库表以及其他数据库对象。

逆向工程
将已存在的数据库产生进新的PDM 之内。数据来源可能是从脚本文件或一个开放数据库连接数据来源。

并不是每个设计都需要用到Power Designer。 例如：小的系统，或Table数比较少的情况下就没有必要采用Power Designer了。

设计步骤

CDM PDM OOM三者转换关系

2004-08-22更新

PowerDesigner仅仅是实现的工具
不要以为Power能帮你把关系什么的全部建立好，很多数据库理论只是还是需要的，设计数据库的时候，那些范式什么的，一定要掌握。
设计一个好的数据库，最好的工具不是必须的，但是基础理论是一定要的。

PowerDesigner用途不局限于数据建模
还可以用PowerDweigner设计web service

并不是每个设计都需要用到PD
用Powerdesigner对付比较大型的项目，是很好的，对于短平快类型的项目，如果时间要求你1个星期完成一个程序，那么完全没有必要用 PowerDesigner，直接维护数据库就可以了，当表的数量超过10个（一个小系统的表在10个左右）的时候，建议还是用用 Powerdesigner 。
我的看法：如果想做成一个比较规范的数据库，小项目也可以用。毕竟生成报表 和正反向工程很有用。

零碎

PD中的CDM设计时，可以将所有需要的字段都定义好。然后在设计实体是直接取出来。PD提供了这样的统一管理的工具。在PD菜单栏-Model-Data Item下。

为了使自己设计的CDM看起来象样一点，可以从工具栏中，拖动一个Title。其显示的信息，是当前CDM的属性值。

为了使实体等Symbol看起来显眼和舒服。可以根据个人喜好进行外观上的调整。当前设计界面中，右键-Display Perferences中进行设置。还可以增加shadow效果。选中Symbol后，Ctrl+W。或者右键菜单。

为了使布局整齐。选中需要调整的Symbol后，菜单-Symbol-Align进行设置。快捷键：ctrl+UP,ctrl+Down,ctrl+Left,ctrl+Right即为上下左右对齐。

设计实体属性时注意的细节：M：表示强制非空；P：是否为主键；D：是否在模型中显示。gerenate：表示是否作为表生成。

默认情况下，CDM的实体会显示Identifier一栏。如果不想其显示出来，在右键-Display Perferences中ObjectView-Entity中设置。

关系的命名方法是：实体名1 实体名2。

关系中的角色（Role）表示联系线上一个方向上的含义。用一个动词来描述。Role只是起一个描述作用。

依赖(Dependency)：表示在联系中一个实体的存在是否依赖于另一个实体。寄生实体（Dependent Entity）是一种部分地被另一实体确定的实体。在依赖联系中，一个实体与另一实体通过标识符相联系，当一个实体的存在没有另一个实体的存在作为参考就不能唯一确定时，两个实体间就存在依赖联系。
主从表就是典型的依赖关系。

中间实体（Associative Entity）：是为了解决多对多联系而产生的一个人工实体，能够为中间实体定义属性。用鼠标右键单击多对多联系线，在弹出的菜单中选择“Change to entity”，能够把这个联系转换成连接两个实体的中间实体。
善于利用自动生成的中间实体，可以简化设计工作，提高数据库设计的正确性。
中间实体一般不用再加入新的字段。

牢记：外键是通过关系Relationship自动来建立的，不需要手动建立。不然会产生多余的键。所以设计时，关注实体本身的字段，以及实体间的关系，特别是多对多和依赖关系。

从CDM到PDM的转换需要注意：

不能改变Diagram的名称
在树状图中，如果钩选红色标出的Symbol表示覆盖修改，不钩选表示保护修改。

数据库为了保证数据完整性和一致性，提出了约束。即表约束，列约束以及参照完整性约束。通常数据库设计和程序开发不是绝对的分离的。所以前两者在实际开发过程中逐渐的完善。需要注意的还是参照完整性约束。
在PD中前两者的设定是对字段，后者是对关系。

参照完整性约束

限制（Restrict）。不允许进行修改或删除操作。若修改或删除主表的主键时，如果子表中存在子记录，系统将产生一个错误提示。这是缺省的参照完整性设置。
置空(Set Null)。如果外键列允许为空，若修改或删除主表的主键时，把子表中参照的外键列设置为空值（NULL）。
置为缺省(Set Default)。如果指定了缺省值，若修改或删除主表的主键时，把子表中参照的外键设置为缺省值（Default）。
级联(Cascade)。把主表中主键修改为一个新的值时，相应修改子表中外键的值；或者删除主表中主键的记录时，要相应删除子表中外键的记录。

注意理解以上的约束时，抓住操作的都是主表。子表的操作都是相对主表来说的。操作方式就是Update和Delete。

引用基础数据表的数据时，可以建立对应的视图。选中需要作为视图的表，菜单栏-Tools-Create View

PD支持对已有数据的表更新表结构。不过需要谨慎操作，检查生成的SQL 脚本。

PD也可以生成随机的测试 数据。

触发器就是DBMS中提供的事件驱动机制。发生在表的Insert,Update和Delete。执行SQL语句或存储过程。

在PD中可以完成存储过程的编写，也便于管理。

逆向工程可以通过数据库脚本或者通过ODBC数据源来实现。