Powerdesigner使用建议

1．Powerdesigner使用建议



　　1.1业务规则的使用(Business Rule)



　　对于一些业务逻辑可能出现在多个数据表中，建议封装成Business Rule，这样便于业务逻辑的重新使用，也便于业务逻辑的维护。



　　为了便于维护业务逻辑，可以考虑将Business Rule和Domains结合起来使用。将业务Business Rule应用到Domains上，然后再把Domains应用到数据表的字段上。



　　例如：在拆迁项目中，拆迁业务部分，管理参数业务部分，房源业务部分，拆迁合同部分的数据表中都有楼层这个字段，因此先一个Business Rule，然后定义一个Domain，这样相应的数据表的字段就可以使用这个Domain了。



　　1.2.自定义数据类型(Domains)的使用



　　oralce提供了一些内置的数据类型，但是用户也可以根据业务的需要，定义自定义的数据类型。



　　在自定义数据类型里面包装业务逻辑。



　　正如上面的房屋楼层，我们可以定义一个独立的数据类型(Domain)维护，然后在相关数据表的字段上使用这个自定义数据类型。



　　一般在定义自己的数据类型时候，可以在oracle基本类型上定义，然后可以加上一些standard check或者Business Rules。



　　比如：在拆迁项目中，面积类别这个字段在很多数据表都出现了，可以作为一个单独的数据类型类维护，定义一个” 面积类别” Domains（包含的种类有：0 --- 厅房面积,1 --- 使用面积,2 --- 单元面积,,3 --- 总建筑面积,4 --- 分摊面积）。而且由于Powerdesigner的提供关联作用,这样便于当业务逻辑发生了变动，能够很快查询出那些对象受到影响。



　　1.3序列号(Sequence)的使用



　　在powersigner的模型里面定义一堆了Sequence，接下来的是要把他们和数据表的相关字段关联起来，特别是那些用于多个数据表字段的Sequence。



　　一个数据表原则上只允许一个字段使用Sequence，并且在数据表的字段使用Sequence前，应该把该Sequence添加到数据表的Extended Dependencies中。



　　如果一个数据表有2个字段或者更多字段使用了Sequence，那模型检查时会给出提示信息。



　　使用的规则一般是只能应用到数据表的主键字段上。



　　主键字段建议是 数据表+“ID“或者 “编号“构成。



　　例如：“房屋整合面积“ 数据表，那它的主键字段=房屋整合面积编号，对应的Sequence为SEQ_房屋整合面积。其它数据表可能也使用到了这个Sequence，那也需要在使用前设置引用关系。



　　（在数据表的Extended Dependencies 上设置引用关系）



　　1.4 Oracle Package的使用



　　在Oracle Package里面可以定一些procedure ，但是Oracle包引用的数据库对象到底有哪些呢，这些信息建议手动维护起来。特别是Oracle Package使用了哪些数据表，视图，以及Oracle Packag等信息建议维护起来。



　　1.5包的使用



　　PowerDesigner的包相当于文件夹。用户可以把它当作一个维护业务逻辑的容器。PowerDesigner包一般建议按照业务模块来建立。如果模块需要细分，可以考虑建立PowerDesigner子包来完成。



　　建议容器里保存的是模型对象的快捷方式。原始信息建议不要放到容器里面。因为在要是把这些信息放到容器里，在PowerDesigner的模型合并或者逆向工程时，这种方式的信息可能得不到维护。



　　PowerDesigner的包下面的PhysicalDiagram，建议采用象ERWin的Subject Area那样，按照某个主题或者业务角度的方式来组织PhysicalDiagram包含的对象，使得每个PhysicalDiagram的功能明确。



　　1.6.视图(View)的使用



　　视图一般是数据表或者视图上建立得来的（当然也可能引用了某个存储过程）。一般视图的模型中应该维护视图的数据来源的引用信息。



　　在我们现在的项目中数据库模型没有对视图进行维护，为此需要在建立视图的Powerdesigner



　　模型。



　　我在Powerdesigner9.5环境下通过逆向工程不能够获得视图(view)的脚本，通过修改相关配



　　置参数，还是不能够获得脚本。



　　可以通过以下2方法获得视图(view)的脚本。



　　方法1：使用powerdesigner8.0的逆向工程获得视图的脚本，然后在Powerdesigner9.5中把视



　　图的模型合并进来，这样就可以对视图进行维护了。



　　方法2：使用Erwin逆向工程获得视图的Erwin模型，然后再把模型保存为ERX类型的文件



　　在Powerdesigner9.5中导入该文件，然后进行合并模型就可以了



　　PowerDesigner的视图模型处理能力比较差，不能构维护视图的依赖关系(也就是建立视图对数据源的依赖关系)，这一点明显不如ERWin。



　　1.7.同义词（synonym）的使用



　　同义词相当于给数据库对象一个别名，提供了位置和数据的独立性。在跨数据库用户访问对象时，可以考虑建立同义词结合权限分配，简化数据库对象的访问。



　　1.8．数据?淼氖褂?



　　数据表的注释语句的更新。


　　业务背景：


　　在我们的项目中，Erwin模型中的数据表的注释语句没有同步到Oracle数据库。现在需要更数据库中的数据表的注释语句。


　　可能可以采取的实现方法：


　　方法1：Erwin直接正向工程，但是从Erwin直接正向工程由于注释语句中有回车符号，更新会失败。


　　方法2：如果把Erwin模型转换成为powerdesigner模型再更新数据表的注释语句，这样就可以避免回车符号的问题，按正常情况是可以行得通的，但是由于Erwin模型中的逻辑模型和物理模型不一致，甚至它们出现的顺序不一致，这样获得powerdesigner模型就不正确了，生成的修改数据库的脚本也就不正确了。



　　实际采用的方法：


　　把Erwin模型转换成powerdesigner模型在Erwin中保存为ERX类型，然后在PowerDesigner导入模型），并且把文件保存为PDM类型（XML格式），删除模型中的视图，domains,Business Rule,reference等信息，只留下相关数据表本身的信息，然后把模型文件的后缀修改XML，并且采用XMLSPY生成这个文件的DTD文件，再采用Java编写了一个基于SAX的程序去解析XML文件，把各个数据表以及字段的注释语句提取出来，然后更新数据库中数据表和字段的注释语句，这样就可以了。


　　2．关于powerdesigner中的数据结构的变更管理



　　目前拆迁项目中数据结构的有些失控，在结合powerdesigner包的概念的基础山上提出如下一些建议。



　　2.1．数据结构按照业务模块进行维护



　　模型中所有的数据结构都在一个文件中，而且在顶层文件夹中各个业务模块维护的是数据结构的快捷方式。



　　2.2．数据结构按照其生命周期进行分类管理。



　　在各个业务模块的包下面建立如下的包：



　　2.2.1临时测试数据结构：



　　是一些当前业务模块测试时使用的数据结构，可以随时被删除



　　2.2.2讨论中数据结构：



　　是数据结构处于讨论中，还没有确定下来。



　　2.2.3需要更新的数据结构：



　　是数据结构已经确定下来，但是还没有更新到数据库中。



　　2.2.4正式数据结构：



　　在数据库中被业务正常使用的数据结构



　　2.2.5作废中的数据结构：



　　在数据库中以前被业务正常使用，现在已经不再使用，但是还没有进行被作废的数据表中数据的迁移，没有完全作废的数据结构。如果要把这些数据结构进行作废，需要先进行数据迁移，以及其他相关处理。



　　2.2.6已经作废的数据结构：



　　在数据库已经不再被使用的业务数据表，相关的数据迁移已经完成，但是数据表还没有删除，相关的文档没有更新。