Powerdesigner使用建议(完整版)

Posted 2023-03-13

参考技术A 　　 ．Powerdesigner使用建议 　　 业务规则的使用(Business Rule)　　对于一些业务逻辑可能出现在多个数据表中 建议封装成Business Rule 这样便于业务逻辑的重新使用 也便于业务逻辑的维护 　　为了便于维护业务逻辑 可以考虑将Business Rule和Domains结合起来使用 将业务Business Rule应用到Domains上 然后再把Domains应用到数据表的字段上 　　例如 在拆迁项目中 拆迁业务部分 管理参数业务部分 房源业务部分 拆迁合同部分的数据表中都有楼层这个字段 因此先一个Business Rule 然后定义一个Domain 这样相应的数据表的字段就可以使用这个Domain了 　　 自定义数据类型(Domains)的使用　　oralce提供了一些内置的数据类型 但是用户也可以根据业务的需要 定义自定义的数据类型 　　在自定义数据类型里面包装业务逻辑 　　正如上面的房屋楼层 我们可以定义一个独立的数据类型(Domain)维护 然后在相关数据表的字段上使用这个自定义数据类型 　　一般在定义自己的数据类型时候 可以在oracle基本类型上定义 然后可以加上一些standard check或者Business Rules 　　比如 在拆迁项目中 面积类别这个字段在很多数据表都出现了 可以作为一个单独的数据类型类维护 定义一个 面积类别 Domains（包含的种类有 厅房面积 使用面积 单元面积 总建筑面积 分摊面积） 而且由于Powerdesigner的提供关联作用 这样便于当业务逻辑发生了变动 能够很快查询出那些对象受到影响 　　 序列号(Sequence)的使用 　　在powersigner的模型里面定义一堆了Sequence 接下来的是要把他们和数据表的相关字段关联起来 特别是那些用于多个数据表字段的Sequence 　　一个数据表原则上只允许一个字段使用Sequence 并且在数据表的字段使用Sequence前 应该把该Sequence添加到数据表的Extended Dependencies中 　　如果一个数据表有 个字段或者更多字段使用了Sequence 那模型检查时会给出提示信息 　　使用的规则一般是只能应用到数据表的主键字段上 　　主键字段建议是 数据表+ ID 或者 编号 构成 　　例如 房屋整合面积 数据表 那它的主键字段=房屋整合面积编号 对应的Sequence为SEQ_房屋整合面积 其它数据表可能也使用到了这个Sequence 那也需要在使用前设置引用关系 　　（在数据表的Extended Dependencies 上设置引用关系）　　 Oracle Package的使用　　在Oracle Package里面可以定一些procedure 但是Oracle包引用的数据库对象到底有哪些呢 这些信息建议手动维护起来 特别是Oracle Package使用了哪些数据表 视图 以及Oracle Packag等信息建议维护起来 　　 包的使用　　PowerDesigner的包相当于文件夹 用户可以把它当作一个维护业务逻辑的容器 PowerDesigner包一般建议按照业务模块来建立 如果模块需要细分 可以考虑建立PowerDesigner子包来完成 　　建议容器里保存的是模型对象的快捷方式 原始信息建议不要放到容器里面 因为在要是把这些信息放到容器里 在PowerDesigner的模型合并或者逆向工程时 这种方式的信息可能得不到维护 　　PowerDesigner的包下面的PhysicalDiagram 建议采用象ERWin的Subject Area那样 按照某个主题或者业务角度的方式来组织PhysicalDiagram包含的对象 使得每个PhysicalDiagram的功能明确 　　　　 视图(View)的使用　　视图一般是数据表或者视图上建立得来的（当然也可能引用了某个存储过程） 一般视图的模型中应该维护视图的数据来源的引用信息 　　在我们现在的项目中数据库模型没有对视图进行维护 为此需要在建立视图的Powerdesigner　　模型 　　我在Powerdesigner 环境下通过逆向工程不能够获得视图(view)的脚本 通过修改相关配　　置参数 还是不能够获得脚本 　　可以通过以下 方法获得视图(view)的脚本 　　方法 使用powerdesigner 的逆向工程获得视图的脚本 然后在Powerdesigner 中把视　　图的模型合并进来 这样就可以对视图进行维护了 　　方法 使用Erwin逆向工程获得视图的Erwin模型 然后再把模型保存为ERX类型的文件　　在Powerdesigner 中导入该文件 然后进行合并模型就可以了　　PowerDesigner的视图模型处理能力比较差 不能构维护视图的依赖关系(也就是建立视图对数据源的依赖关系) 这一点明显不如ERWin 　　　　 同义词（synonym）的使用　　同义词相当于给数据库对象一个别名 提供了位置和数据的独立性 在跨数据库用户访问对象时 可以考虑建立同义词结合权限分配 简化数据库对象的访问 　　　　 ．数据表的使用　　数据表的注释语句的更新 　　业务背景 　　在我们的项目中 Erwin模型中的数据表的注释语句没有同步到Oracle数据库 现在需要更数据库中的数据表的注释语句 　　可能可以采取的实现方法 　　方法 Erwin直接正向工程 但是从Erwin直接正向工程由于注释语句中有回车符号 更新会失败 　　方法 如果把Erwin模型转换成为powerdesigner模型再更新数据表的注释语句 这样就可以避免回车符号的问题 按正常情况是可以行得通的 但是由于Erwin模型中的逻辑模型和物理模型不一致 甚至它们出现的顺序不一致 这样获得powerdesigner模型就不正确了 生成的修改数据库的脚本也就不正确了 　　实际采用的方法 　　把Erwin模型转换成powerdesigner模型在Erwin中保存为ERX类型 然后在PowerDesigner导入模型） 并且把文件保存为PDM类型（XML格式） 删除模型中的视图 domains Business Rule reference等信息 只留下相关数据表本身的信息 然后把模型文件的后缀修改XML 并且采用XMLSPY生成这个文件的DTD文件 再采用Java编写了一个基于SAX的程序去解析XML文件 把各个数据表以及字段的注释语句提取出来 然后更新数据库中数据表和字段的注释语句 这样就可以了 　　　　 ．ERWin升级到PowerDesigner的相关问题　　 Domain的升级　　从Erwin 升级到PowerDesigner 时 Domain信息和数据表的关联关系会丢失 需要手动重新添加 者间的关系 当然可以通过编程修改PowerDesigner的模型文件 添加 者之间的关联关系 一般的PowerDesigner模型文件较大 只要有个几十张数据表肯定模型文件有 MB 建议采用SAX的方式添加信息 　　注意 添加数据表字段使用的Domain时候 需要设置数据表对Domain的引用关系（也就是Extended Dependencies） 　　 Business Rule的升级　　从Erwin 升级到Powerdesigner Business Rule的表达式(脚本)需要修改的 把所有的　　Business Rule的表达式中的@column 修改成%COLUMN% 　　具体实现的方式 可以直接在Powerdesigner 里面修改 或者把模型保存为XML格式（文件类为 pdm） 通过UltraEdit或者XMLSpy等工具来修改 一个查找替换旧搞定了 当然的注意　　只能修改<c:BusinessRules> </c:BusinessRules>里面的内容 否则会修改一些不应该修改的地方 　　同Domain一样 从Erwin 升级到PowerDesigner 时 Business信息和数据表的关联关系也会丢失 如果Business Rule 不是太多建议手动修改模型文件 　　　　 Sequence的升级　　 Sequence的升级建议采用和Domain的方式 编程实现维护 　　 物理图的升级　　从Erwin 升级到Powerdesigner 物理图同样能够倒入Powerdesigner 中 但是Powerdesigner 的升级功能有些问题 在生成的物理图中数据表的信息有些问题 物理图中的数据表的字段显示不完全 而且很多时候数据表字段的类型都不能显示完全 我使用java采用sax的方式把升级后的模型文件进行解析 然后重新生成物理图中数据表的位置信息（数据表的 个坐标 左上角坐标 右下角坐标） 另外根据业务需要可以生成自己的Powerdesigner 包并且可以创建物理图 把数据表添加到物理图上 　　　　 其他说明　　从Erwin 升级到Powerdesigner 我写了一些java程序解决了相关问题 如果哪位同行遇到相似的问题　　可以交流一下 　　　　 ．关于powerdesigner中的数据结构的变更管理 　　目前拆迁项目中数据结构的有些失控 在结合powerdesigner包的概念的基础山上提出如下一些建议 　　 ．数据结构按照业务模块进行维护　　模型中所有的数据结构都在一个文件中 而且在顶层文件夹中各个业务模块维护的是数据结构的快捷方式 　　 ．数据结构按照其生命周期进行分类管理 　　在各个业务模块的包下面建立如下的包 　　 临时测试数据结构 　　是一些当前业务模块测试时使用的数据结构 可以随时被删除　　 讨论中数据结构 　　是数据结构处于讨论中 还没有确定下来 　　 需要更新的数据结构 　　是数据结构已经确定下来 但是还没有更新到数据库中 　　 正式数据结构 　　在数据库中被业务正常使用的数据结构　　 作废中的数据结构 　　在数据库中以前被业务正常使用 现在已经不再使用 但是还没有进行被作废的数据表中数据的迁移 没有完全作废的数据结构 如果要把这些数据结构进行作废 需要先进行数据迁移 以及其他相关处理 　　 已经作废的数据结构 　　在数据库已经不再被使用的业务数据表 相关的数据迁移已经完成 但是数据表还没有删除 相关的文档没有更新 lishixinzhi/Article/program/Oracle/201311/17191