CSDN博客

img colayungnew

Powerdesigner使用建议

发表于2004/10/16 15:21:00  1779人阅读

分类: UML&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,建议采用象ERWinSubject 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数据库。现在需要更数据库中的数据表的注释语句。

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

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

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

实际采用的方法:

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

 

1.9ERWin升级到PowerDesigner的相关问题

1.9.1 Domain的升级

  Erwin3.52升级到PowerDesigner9.5时,Domain信息和数据表的关联关系会丢失,需要手动重新添加2者间的关系。当然可以通过编程修改PowerDesigner的模型文件,添加2者之间的关联关系。一般的PowerDesigner模型文件较大,只要有个几十张数据表肯定模型文件有1MB,建议采用SAX的方式添加信息。

 注意:添加数据表字段使用的Domain时候,需要设置数据表对Domain的引用关系(也就是Extended Dependencies)。

1.9.2 Business Rule的升级

Erwin3.52升级到Powerdesigner9.5Business Rule的表达式(脚本)需要修改的,把所有的

Business Rule的表达式中的@column 修改成%COLUMN% 

具体实现的方式,可以直接在Powerdesigner9.5里面修改;或者把模型保存为XML格式(文件类为 .pdm,通过UltraEdit或者XMLSpy等工具来修改,一个查找替换旧搞定了。当然的注意

只能修改<c:BusinessRules> </c:BusinessRules>里面的内容,否则会修改一些不应该修改的地方。

Domain一样,从Erwin3.52升级到PowerDesigner9.5时,Business信息和数据表的关联关系也会丢失。如果Business Rule 不是太多建议手动修改模型文件。

 

1.9.3.Sequence的升级

   .Sequence的升级建议采用和Domain的方式,编程实现维护。

1.9.4.物理图的升级

   Erwin3.52升级到Powerdesigner9.5,物理图同样能够倒入Powerdesigner9.5中,但是Powerdesigner9.5的升级功能有些问题:在生成的物理图中数据表的信息有些问题:物理图中的数据表的字段显示不完全,而且很多时候数据表字段的类型都不能显示完全。我使用java采用sax的方式把升级后的模型文件进行解析,然后重新生成物理图中数据表的位置信息(数据表的2个坐标:左上角坐标,右下角坐标);另外根据业务需要可以生成自己的Powerdesigner9.5包并且可以创建物理图,把数据表添加到物理图上。

 

1.9.5.其他说明

  Erwin3.52升级到Powerdesigner9.5,我写了一些java程序解决了相关问题,如果哪位同行遇到相似的问题

可以交流一下。

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已经作废的数据结构:

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

相关的文档没有更新。

 

 

 

阅读全文
0 0

相关文章推荐

img
取 消
img