1.3 模型自动生成
在很多时候我们要开发一个全新的系统，而数据库仅仅考虑这个系统的数据管理需求，或者开发新的应用程序访问已有的数据库。采用面向对象方法的软件开发通常采用自顶向下的开发过程，先建立企业的应用模型，然后再进行数据库设计。用户也可以采用自底向上的开发过程，也就是以数据为中心的开发过程，先进行数据库设计， 或者应用已有的数据库模型，再设计应用程序模型。
既然我们定义了模型间映射模式，如果有了一种模型，为什么不能自动生成另外一模型，并且建立它们间的映射。PowerDesigner就提供了这种模型的自动生成功能，使得用户能够重用现有的模型，方便的生成目标模型。对于面向对象模型和数据库模型来说，这种自动生成功能是双向的，即可以通过面向对象模型来生成数据库模型，也可以通过数据库模型来生成面向对象模型。
1.3.1 自动生成数据库模型
这种模式适合于自顶向下的开发过程，即先建立应用程序模型，再设计数据库。我们可以应用PowerDesigner提供的转换模式，将应用程序模型中描述持久信息的面向对象元素，实体类、关联、继承，生成数据库模型对应的元素。
根据已经被证明的映射模式，PowerDesigner提供了一些缺省的转换模式，用户也可以定制转换模式来控制生成过程
1.3.1.1 基本转换模式
1. 类
用户可以通过类的持久属性和生成类型来控制类的自动转换，PowerDesigner仅会自动转换持久的类。转换的类型有表、迁移列和抽象数据类型，其中表和抽象数据类型都容易理解，迁移列主要控制继承中类的转换，我们会在继承转换中详细讨论它的用法。用户还可以指定生成表的名称。
2. 属性
如果持久类的生成类型不是抽象数据类型，PowerDesigner会将该类中的持久属性转换成表的列。PowerDesigner提供了一些缺省的转换模式，比如数据类型的对应关系。用户可以定制转换的过程，他可以定义生成列的一些属性，名称、类型、长度等。
3. 标识符
持久类的标识符会被转换成表的键，主标识符会被转换成主键。
4. 操作
如果持久类的操作具有存储过程或者存储函数的范型，相应的存储过程或者存储函数会被生成。
1.3.1.2 关联转换
PowerDesigner会根据关联生成外键和表，支持所有的关联映射模式。
|
关联
|
转换规则
|
|
一对一
|
对于单向的关联，一个外键会生成，外键的方向和关联的方向一致，父表的主键会迁移到子表中作为外键。对于双向的关联，两个外键会被生成，用户需要手动删除其中的一个
|
|
一对多
|
不管单项还是双向，只有一个外键被生成，多端持久类生成的表为子表，父表的主键会迁移到子表中作为外键
|
|
一对多迁移主键
|
这是一对多关联的变体，如果一对多关联具有组合并且由一端包含多端，那么被迁移到子表的列同时又会是主键的一部分
|
|
多对多
|
会生成一个中间关联表和两个外键，其中两端持久类的表的主键会迁移到关联表中作为主键和外键，两个外键由中间关联表分别指向它们
|
用户可以通过端点的度来控制外键是否为必需的，如果子表对应的持久类端的最小度为1，那么外键为必需的，即子表的外键列是非空的；如果为0，那么外键为可选的。
1.3.1.3 继承转换
PowerDesigner会将继承转换成表和关联，用户通过基本映射中提到的生成类型来控制转换，生成类型表表示对于该持久类单独的表会生成，生成类型迁移列表示该类属性生成的列会存在于其他类生成的表中，没有单独的表会被生成。
|
映射模式
|
说明
|
设定
|
|
继承层次到单表映射
|
整个继承层次会被转换成一张表，通过表中的分类列来区分不同的类
|
根类生成类型为表，其他所有子类的生成类型为迁移列，根类需要设置主标识符 |
|
每类一表映射
|
对于继承层次中的每一个类，单独的表会被生成，子类的表和父类的表通过外键关联，外键的列同时作为子类表的主键
|
所有类的生成类型为表，根类需要设置主标识符 |
|
每具体类一表映射
|
只有继承层次中的叶子节点类会被转换成表，每一个非叶子节点类属性生成的列会被迁移到叶子类的表
|
所有非叶子节点子类的生成类型为迁移列，叶子节点的生成类型为表，根类需要设置主标识符 |
PowerDesigner也支持混合映射模式的转换，不过这种转换并不常用，用户可以参考PowerDesigner的文档查看详细用法。
1.3.1.4 其他映射模式的支持
PowerDesigner还可以通过嵌入来支持细粒度的转换。比如，在员工信息类中，我们有一个属性家庭住址，该属性是对象类型，类型为地址类。我们不想为地址类单独生成表，只想把它嵌入到员工信息表中。在PowerDesigner中，我们可以通过，设置属性的类生成类型为嵌入来实现这一点。
1.3.2 自动生成面向对象模型
PDM到OOM的转换适合于自底向上的开发过程，对于以数据为中心的应用系统或者访问已有数据库上的应用系统，这种转换是非常有用的。PDM到OOM的转换类似于OOM到PDM转换的逆过程，PowerDesigner会把PDM中的元素转换成OOM中对应的元素。但是其中继承的转换是不可逆的，因为PDM中没有子类的概念，所以用户需要手工更改生成后的对象模型。
1.3.3 模型和并
PowerDesigner提供了模型合并功能，支持迭代式的模型自动转换。自动生成的目标模型并不一定完全满足我们的需要，我们常常要对它进行修改，但是源模型也发生了改变，有时我们既想同步目标模型和源模型，又想保持我们对目标模型所作的修改，这时模型的合并显得非常重要。通过PowerDesigner的模型合并窗口，用户可以了解到重新生成的模型和当前的目标模型的差异，从而可以根据自己的需要，选择是否保持或者覆盖以前的模型。
用户还可以通过PowerDesigner的流体模型了解源模型和目标模型间的转换关系。
1.4 自动代码生成
从上面可以看到，通过PowerDesigner，设计人员可以方便的完成应用程序的设计、数据库设计以及O/R映射定义，那么编程人员通过编码实现这些设计。对于O/R映射的实现，我们可以看到，不管使用什么技术，编码人员都需要进行大量的工作。
我们知道MDA的目标就是把现有的以代码为中心的开发模式转换成以模型为中心的开发模式，让模型生成代码，把开发人员从繁琐的编码工作中解放出来，从而专注于系统的架构和业务逻辑上。PowerDesigner通过其可扩展性提供了对于MDA的支持。在PowerDesigner中，所有的模型都是通过元模型进行描述的，可以通过GTL（通用模板语言）和VBScript来访问这些元模型。那么我们可以通过元模型的信息来做他想要做的事，包括自动代码生成。
PowerDesigner已经提供了对于主要持久化技术的支持，Hibernate、EJB 3、NHibernate、ADO.Net等，用户可以直接使用这些扩展模型。除了O/R映射实现代码，这些扩展模型还可以生成测试代码，方便用户对生成的代码进行测试。用户只需要添加相应的扩展模型，并且通过扩展属性设置特定扩展模型所需的信息，就可以实现自动代码生成。下图是应用Hibernate扩展模型生成映射文件的预览窗口。
用户也可以对这些扩展模型进行定制或者开发他自己的扩展模型，以满足自己的需要。关于如何扩展PowerDesigner，可以参阅PowerDesigner用户文档和高级使用手册。
结论
我们可以看出，通过PowerDesigner的模型映射，设计人员可以很方便的定义O/R映射，不管是手工的方式还是通过自动模型转换。O/R映射元数据同模型保存在一起，保证了一致性，方便的和模型同步，提高了可维护性。通过自动代码生成，编码人员不再需要进行繁琐、重复性的劳动，提高了开发的生产率。
