PowerDesigner使用及建议

本文转载至http://blog.sina.com.cn/s/blog_6b3380380100szgb.html

PowerDesigner是一款非常优秀的数据库建模工具，熟练的使用该工具进行数据库建模，对软件系统的分析和设计有很大的帮助。

PowerDesigner中有几种模型可以创建，不过最常见的是概念模型CDM（Conceptual Data
Model）和物理模型PDM(Physical Data Model)。毕竟PowerDesigner在数据库建模方面有很强大的功能。 概
念模型不针对任何具体的数据库语法，而以一种抽象的数据库为模型进行设计，物理模型则通常需要指定某一种具体的数据库，在物理模型的设计中，数据库语法将
根据该具体的数据库进行设计和定义。当然这带来的一个不好的地方是，如果你想你的数据库设计支持多种不同种类的数据库时，不方便。所以通常情况下你应该优
先考虑概念模型进行数据库建模设计。而PowerDesigner支持将概念模型转换为不同的物理模型。所以只要我们在概念模型中把相关的设计做好，则剩下的事情就交给PowerDesigner来帮你解决，当然因为概念模型转换为物理模型时，因物理模型中使用的数据库类型不一致，所以在概念模型中定义的数据类型在物理模型中会有所改变，关系也一样会有所改变，不过这个我们也不用去担心，因为PowerDesigner仍会帮我们做好，只是需要注意的是二者在处理上有些区别，所以在使用概念模型时，需要考虑好实际的物理模型的表现情况。
所以在这里，我也只讲解关于概念模型的使用方面，当然其中会涉及到如何转换为物理模型以及关于物理模型中与数据库进行实际的关联的方法。我的使用版本是PD12，且使用的是英文版，网上似乎有中文补丁，但是我建议不要使用中文的，因为使用英文版能提高你对英文的敏感程度，毕竟做软件这一行，我觉得很多时候你所面对的问题，中文网站是无法提供的，你不得不去英文网站中寻找，请对应该版本。

下面说说具体在使用PowerDesigner时需要我们留意的地方：

---

1.建议所有数据表中应该含有一个主键ID，这个ID没有特别的意义，只是用来唯一区别于每一条记录的，且它也应该只能有这种作用，不应该含有其他作用。虽然在有些表中，表中的某一字段我们能保证其是唯一的，但是我认为还是应该加上这样一个主键ID。这样做的好处是可以使我们在做表与表之间的关系时，比较明显易懂（在做数据库系统的设计中，单独的表容易处理，而难点在表与表的关系处理上）。这个ID应该设为这个表的主键，且该字段名可以命名为：“表名_ID”这样的名字，这样在做关系时，是非常明显的区别于不同的表的主键，另一方面这样做的好处是在用PD从概念模型转化为物理模型时，一些关联关系之间命名产生冲突（如果你将所有表的主键命名相同的话）。当然，你的表中可以存在多个主键的，但仍建议以表名加上该字段名的方式进行命名，如一个表dept中的用户ID也是一个主键，则其命名规则为dept_UserId命名之。另外再说一点，这个与PD无关，就是在做数据库表设计时，主键建议都采用同一种数据类型和长度，这样有好处。

2.每个表的主键的存在会在表（实体）属性的Identifiers中产生对应的记录，该记录会与表的主键进行关联，但我们需要改变一下该记录的默认Name和Code，建议以表名加字段名加_PK命名之。比如表名为dept，则该值中name与Code值为dept_ID_PK，从这个意思上可以看出来，该PK指的是dept表中的ID字段为主键。当然如果一个表中有多个主键，仍可以按上述方式进行命名，这样做的好处主要体现在物理模型中，如果你需要改变表与表之间的关系（表与表之间的关系在物理模型中的通常体现是本表是否拥有关系表中的某一主键）的时候，就很容易根据该Identifiers中的变量名来进行更换了，意思明了。而如果用默认的，则看不出意思来，容易出错。

3.两个实体之间存在关系时，在CDM中，是不需要在实体的表中创建单独的字段来存储对方的主键的。在概念模型转化为物理模型时，PowerDesigner会自动添加对应的对方的主键字段名作为本表中的外键字段。这也是在前面的第一条中，为何在实体的主键上建议命名方式为表名加字段名的原因。

4.继承关系中，在CDM转化为PDM时，子表和父表都会生成对应的表，且父表中的所有字段都会在子表中存在，且你表的主键会同时成为子表的主键之一。个人觉得实体之间的继承关系目前在数据库设计上的使用意义不大，而PD在做这样的关系，主要是出于基于面向对象方面的因素的考虑。建议少用或者不使用该关系。

5.Association（注意不是Association Link）主要用于描述两个及以上的实体间关联关系的。和relationship最大的区别在于Association会单独生成一张表，且会存储相关实体的所有主键，从某种角度来说，它更（象）是一个关联关系表。所以我们也可以通过relationship来实现，只需要新添加一个实体来进行多个实体之间的关联即可。Association Link是用来进行Association与其他实体Entity之间的关联的，类似于RelationShip的功能，只是这个用于Association与Entity之间的联系，而RelationShip应用于Entity之间。

6.从CDM转化为PDM很简单，在tools中，选择Generate physical Data Model…，选择你需要转化的数据库类型即可。此时PD会将对应的关系以及数据类型转化为特定的物理模型中使用的数据库类型，建议你改变一下你转换的物理模型的名字，不要用默认的。

7.当我们添加或者修改字体中的字段属性时，默认情况下name与code是同步的，也就是说修改name的时候，code也跟着变化，这个令人很烦，可以通过下面的步骤将其去掉：Tools->General Options->Dialog->Name to Code Mirroring 。将Name to Code Mirroring默认的选中去掉，使其不选中，即可。

8.在 生成某一具体的物理模型下对应的数据库脚本时，我们可以插入自己的数据库脚本，这样可以一并生成，这通常在初始化数据库和加入较详细的注释时很有用。这个 操作只能在物理模型中进行，因为概念模型不针对某一具体数据库，而物理模型中加入脚本是针对具体数据库进行的。添加自己的脚本的方法是：双击选中物理模型 中的你需要添加自已脚本的表，在左下角中点击more>>，选中其中的Script，然后在里面的Begin和End中就可以输入你要加入的脚本了。

9.当所有的表设计好之后，通过CDM转化为PDM之后，若要生成脚本文件，则在物理模型中，选择DataBase->Generate DataBase…在File name中选择你所要保存的sql脚本文件名。确定之后，就可以生成对应的脚本文件了，包括第8点中提到你自已添加的脚本也是可以同时生成在脚本文件中的。你可以在preview属性框中，可以在查看当前所有表的脚本内容。

10．生成报表很简单，只需要在物理模型中（实际有意义的是在物理模型中生成报表，因为你需要生成的数据字段类型和关系与具体的数据库类型有关）。选中左边工程栏中的物理模型，右键点击该物理模型，然后选择new，再选中report即可，此时就可以在工程栏中新建一个包，里面即含有report项。在生成report中，建议report template中采用none，即不使用任何模板，因为我们需要自行定义模板的显示内容。

具体到上面的显示，生成过程中右键点击上面的物理模型，在弹出来的对话框中选择new，然后再选择report即可，这样就会生成reports包，在里面有一个report1的报表。点击Report1报表，因为我们之前是不选择任何模板，所以显示的样子如下：

左边则表示可以显示的项，而右边则是你要生成的报表的项，你可以通过双击左边的某些选项，就可以把这些选项添加到右边，这样就可以在报表中生成出来，通常你应该将左边的Table下的List of Table Columns加入至右边。然后在右边的你加入的List of Table Columns中右键选择该选项，选择Layout…，然后在弹出来的对话框中选择你要显示的内容，默认情况下只显示了两个，就是name和code，你可以将Data type以及Primary以及Foreign,以及Length也可以加上，再调整一下距离就可以了。要在报表显示的情况下，你可以点击在上面的面板，生成html文件或者rtf文件。实际情况中，可能显示doc更好，你可以在生成的rtf中文件中另存为doc的方式，就可以保存为doc了。在实际的使用中，你要生成的报表到底需要哪些内容，得根据实际的需求而定，这个报表的作用通常是可以指导开发人员在上面进行进一步的设计开发用的。为了满足实际的显示内容的需求，你可以不断的进行可显示内容的尝试，直到满足你的需求为止。

---

在使用PD的过程中，如果你有时不是很把握CDM转化成PDM在有些属性的设置上的改变，可以先做一个简单的CDM表及关系，然后转化为PDM看一下实际的表现，不要在CDM所有的表都建立好了之后，再来看，那样的话，如果出错，修改是非常麻烦的。这是我的实际使用时经常用到的方法。尤其是在做CDM的表关系时，有些属性的修改，选择等在PDM上到底是什么表现，我通常就是在CDM中做一个简单的表和关系，如部门员工表以及关系，然后再转换到PDM中，看看是否是我需要的，我觉得这个方法很有用，后面我会详细说明CDM中的实体对象之间的关系选项对PDM的形成表现进行说明，我也是通过这种方法来确定的。