PowerDesigner使用(3)

PowerDesigner使用(3)

关键字: PowerDesigner uml 数据库 数据库建模

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文件，把各个数据表以及字段的注释语句提取出来，然后更新数据库中数据表和字段的注释语句，这样就可以了。
　　
　　1.9．ERWin升级到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.5，Business Rule的表达式(脚本)需要修改的，把所有的
　　Business Rule的表达式中的@column 修改成%COLUMN%
　　具体实现的方式，可以直接在Powerdesigner9.5里面修改；或者把模型保存为XML格式（文件类为 .pdm）,通过UltraEdit或者XMLSpy等工具来修改，一个查找替换旧搞定了。当然的注意
　　只能修改 里面的内容，否则会修改一些不应该修改的地方。
　　同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已经作废的数据结构：
　　在数据库已经不再被使用的业务数据表，相关的数据迁移已经完成，但是数据表还没有删除，相关的文档没有更新。  
 用实体关系图进行数据库建模

一、概述

　　很可能你现在正在规划一个数据库驱动的网站；而且几乎可以肯定的是，你一定已经浏览过数据库驱动的网站。过去，一些网站依赖CGI脚本和文本文件存储实现数据持久化，但现在我们能够访问大量不同的关系型、对象-关系型、面向对象型数据库。

　　对于Web应用来说，关系数据库是一种强大的支持工具，这得感谢它们的高可用性、性能，而且相对来说，关系数据库比较容易使用。要找出一个功能完善、源代码开放、能够在多种平台上运行的数据库系统并不困难。你可以用Perl、Java、PHP以及其他服务器端脚本语言把关系数据库和Web网站连结到一起。

　　随着网站规模的发展，它对数据库——通常是关系数据库——的依赖程度也日益增加。大量页面和服务需要向数据库表写入信息，或者从数据库提取信息。对于大多数网站，数据库表很快成为网站体系结构中的关键部分，成为网站运作的生命中枢。为了方便和轻松地管理大容量数据，用户帐户、新闻动态、内容、统计数据都可以保存到关系数据库管理系统（Relational Database Management System，RDBMS）。

　　用图（Diagram）管理数据模型具有高效、方便的优点。对于RDBMS，描述数据模型的图通常称为实体关系图（Entity Relationship Diagram，ERD）。用ERD描述数据模型能够帮助你预先精确定义数据需求，使你能够对以后的改动作出有效的规划，能够随着网站的发展方便地改进规划。

　　本文将介绍ERD建模工具和概念。文章提供了一些图的实例，但它们的目的不是提供精确的或者是全面的数据设计范例。它们的目的是以两个建模工具为例，介绍数据建模符号。在不同的工具之间，图的符号有着重大的差别，但它们的基本概念一样。本文的图例从PowerDesigner和Visio 2000 Professional的试用版得到，你可以从本文末尾找到这些工具和其他类似产品的链接。

二、是否使用建模工具？

　　许多规模较小的网站用ASCII形式的SQL（Structured Query Language）脚本文件进行数据建模。当开发小组人员较少，或者最理想的情况下仅由一个人构成时，这种方法最有效。然而，数据模型将很快发展成为一个复杂的结构——在这种情况下，CASE（Computer Aided Software Engineering，计算机辅助软件设计）工具、有关所有数据信息的图、集中式知识库能够极大地帮助你管理Web网站的数据层。

2.1 何时使用SQL？

　　即使当你准备用SQL直接管理数据模式（物理数据库）时，图也能有效地帮助你理解和改进系统。然而，如果你的预算或者时间非常有限，采用复杂的新式建模工具可能得不偿失。相反，在这种情况下，你应该使用一个简单的图形工具把数据模式的基本情况记录下来，然后逐步转换到复杂的数据建模工具。

　　如果你正在设计的数据库类型不常见（或者是非标准的），避免使用某些复杂CASE工具可能是明智的，因为这些工具的“反向工程”能力和某些自动功能可能无法在你的环境下发挥作用。这里所谓的自动功能，是指建模工具根据输入模型的图形和属性信息，自动为目标数据库生成合适SQL命令的能力。反向工程是这样一种能力，建模工具根据已经部署的物理数据模式，从现有的表提取出实体和关系信息。

2.2 转入建模工具

　　从简单绘图工具转换到数据建模工具并不是一个很复杂的过程。大多数数据建模工具的工作方式就象是一个标准的绘图工具，参见图1a和图1b，这是两个数据建模工具的界面实例。你可以在这里创建和排列表，定义关系，以及指定其它信息（列的类型、长度，键等）。

　

　

图1a：PowerDesigner的界面

　

　

　

图1b：Visio的界面

　　转向数据建模工具的主要挑战在于：

• 学习使用建模符号。
• 在不丢失任何关键信息的前提下，用数据建模工具描述现有数据模型。
• 寻找一个对你的数据库提供全面支持的工具，例如在生成SQL、从现有数据模式通过反向工程建立数据模型时。

　　一些入门级数据建模工具（参见本文后面的参考资源）只有少量的高级特性。这有好处，但也有弊端——它们很容易学习使用，但当你积累了更多的经验时，它们可能不再满足你日益增长的需要。然而，升级工具或更换工具一般不存在大的问题，特别是当新的工具能够对现有数据模式进行精确、完整的反向工程时，升级或更换工具的过程尤其简单。

三、ERD建模符号

　　本文使用Martin的Information Engineering符号。PowerDesigner采用的就是这种符号，的Designer产品所使用的符号也和它很相似。你可以在查看各种ERD符号的说明。基本的ERD绘图规范很直观易懂。你可以定义实体（表），描述各个实体之间的关系。在填写表和关系的细节信息时，每一种工具的做法都有所不同；但就我所遇到的工具来看，基本概念在大多数软件包之间是相通的。接下来的内容将介绍你必须了解的主要图形元素和设置方法。

3.1 表

　　所有构造合理的数据建模工具都允许为表指定丰富的关联信息。这些信息包括（但不局限于）：

• 表的描述、注解，以及实体（表）的标题。
• 列，列的类型、长度、默认值和强制条件。
• 主键，索引，唯一性约束。

　　要指定这些信息，一般你需要进入表的属性窗口，如图2a和图2b所示。

　

2a：PowerDesigner中表的属性窗口

　

图2b：Visio中表的属性窗口

　

　　一旦输入了新表的属性信息，图将被更新，显示出你所提供的新的或更改后的表信息。下面的图形显示了一个表的实例，这个表的属性信息见图2a和图2b。在图2a和图2b中，许多列被定义成了（m）andatory（强制的）、（p）rimary（主键）和（d）isplayed（被显示的）列。下面的图显示了为该表输入的部分属性信息。

　

图3a：PowerDesigner的表

　

图3b：Visio的表

　

　　在图3a中可以看到一些非标准的数据类型，如PHONENUMBER和PK。许多数据建模工具允许定义域或定制数据类型，它们可供一个以上的列使用。域不仅代表着数据类型——通常，它们还包含检查约束、默认值、值列表等信息。如果你想要更新一个域（例如定义一种新的电话号码格式），所有该模型中引用该域的列都将自动更新。

3.2 关系

　　如果我们只定义数据模式中的表，数据建模工具就不那么重要了。各个表之间的关系、依赖情况往往很复杂，有一个管理和显示这些关系的工具将带来很大的帮助。对于一个给定的关系，必须收集的重要信息包括：

• 父表和子表。
• 两个表之间的强制关系。例如，父表可能有一个子表，但子表必须有一个父表。
• 关系基数（Cardinality）。即，一个父表可以有零个或者多个子表，但一个子表有且只能有一个父表。
• 关于关系的注释、意见和角色说明。

　　大多数建模工具通过在两个或者更多表之间画出连线的方式定义关系。默认情况下，关系往往被定义成为一对多关系，而且它对于关系中的任何一方都是可选的。要修改关系，你必须打开关系的属性窗口，更新实体关系的特征信息。图4a和图4b显示了两个不同的工具允许为关系定义的部分属性：

　

图4a：PowerDesigner的关系属性设置界面

　

图4b：Visio的关系属性设置界面

　

　　该图显示了一个一对多关系——一个典型的父-子关联关系。部门（Branch）和雇员（Emplyee）的关系是强制的。它意味着一个部门必须至少有一个雇员（1-N强制关系）；另一方面，它意味着一个雇员必须属于且只能属于一个部门（1-1强制关系）。图5a和图5b反映了修改后的关系。

　

图5a：PowerDesigner中两个表之间的关系

图5b：Visio中两个表之间的关系

　

　　这个图显示了如何把信息转换成符号。强制的关系由一条实心垂直线（而不是椭圆）表示。某些工具用虚线表示可选的关系。关系中属于“多”的这一边用一个类似鸟爪的图形表示，关系的基数在靠近它所描述的那一端显示。

　　你可能已经注意到，Employee表没有定义外键列。这个图仍旧处于“概念设计”阶段——此后，从概念图到物理数据模型之间的转换是必不可少的。大多数工具区分概念和物理数据模型——概念数据模型描述信息的需求，但不关注细节问题，例如索引和强制性的引用完整性。

　　有些时候，你可能要定义自我引用的表。自我引用的表一般用来描述层次型关系。如下面的图形所示，大多数数据建模工具能够处理这类关系。注意在这个例子中，雇员可以有零个或者一个上级——它使你能够处理一些特殊的情况，比如总统没有直接的上级。

图6a：PowerDesigner中自我引用的表

图6b：Visio中自我引用的表

四、图的规划

　　定义表和关系只是挑战的一部分，图的清楚明白同样很重要。虽然一些工具提供自动布局能力，我还没有看到过一个完善的实现。相反，你的目标应该是遵从“孔雀东南飞”这一规则（这里的“孔雀”是关系中代表“多”这一方的符号，它是连接到表的三条分叉线，象个鸟爪）。换句话说，子表应该位于父表的右方和下方。这种安排使得从逻辑上组织和理解数据模型更加方便。最重要、最高级别的表应该出现在左上角，让级别较低的表出现在页面的右下角。为了清楚起见，减少图中交叉线的数量也是很重要的。正如Eberhardt Rechtin在中强调的，“一个好的设计往往看起来很舒服”。如果无论怎样安排，你的数据模型看起来都很混乱，那么，它可能正在告诉你数据模型本身有一些值得注意的问题。

　

图7a：完整的ER图（PowerDesigner）

 

图7b：完整的ER图（Visio）
　

五、从图到数据库

　　依赖于你所选择的用来建立数据模型的软件包，建模工具可能会根据模型生成SQL命令或直接修改数据库模式。这种功能带来了极大的便利；和使用ASCII格式的SQL脚本相比，这种方式有着许多优点。一些建模工具的功能适合于大量的数据库类型，例如PostgreSQL、MySQL、、DB2，等等。对于简单的数据库修改，改动操作可以从建模工具通过ODBC直接完成。数据库改动还允许以增量方式进行（例如，ALTER命令或创建命令，以及对特定表的更新命令）。当你第一次使用建模工具时，你可以查看建模工具生成的SQL，看看自己是否可以信任和认可建模工具对数据模型的解释。一段时间之后，你就会熟悉建模工具对各种关系和表细节的解释。

　　【结束语】数据建模是一种很好的软件工程实践。它能够帮助你在正式编写程序代码之前规划数据需求。在维护和改进系统的数据布局的过程中，数据建模同样很有用。一些工具能够让这个过程变得非常简单，能够在你管理和设计数据库系统的时候带来极大的帮助。然而，根据你所需功能的不同，建模工具的价格也有着极大的差异。在不出现预算赤字的情况下，轻松掌握和运用数据建模技术的最好方法是，从小型的工具开始，然后逐渐深入和提高。