买了一本《PowerDesigner软件分析技术》有没有一起学习的？
关键词：PowerDesigner
刚刚买了一本
《PowerDesigner软件分析技术》
白尚旺
有人一起学习吗
wlg@eyou.com
学习以后有什麽心得，可以在这里与大家共享:P
好啊，那我就当这里笔记本了。
这本书里面用的是pd8:
我学习用的工具是pd9.5试用版
刚看完第一章：
pd8可以产生3类模型：
1、OOM(对象模型)
2、PDM（物理数据库模型）
3、CDM（概念数据库模型）
我在9里看到还有BPM（business process model）、MMR(Multi－Model Report多模型报告？)还有Free model
书中还提到PAM,讲的是PowerDesigner6.1中的ProcessAnalyst模块产生的模型，我以为是否就是PAM＝BPM？
面向对象模型（OOM）中的类图可以转化成CDM（我手有点懒）、PDM和应用程序框架
CDM可以转化成PDM和逆向生成OOM中的类图，CDM可以和PAM相互转化
物理模型（PDM）可以生成DDL脚本和直接生成数据库对象（感觉应当是先建一个数据库之后使用ODBC连接到数据库然后再生成数据库对象的）
完成设计后有五种产物:
1.DDL脚本
2.用户数据库结构（其实我以为就是DDL脚本）
3.应用程序框架（书上写的是应用程序代码）
4,模型报告(这个看来最有用了，我在9中试了试，挺不错的，不过出来的东西感觉比较粗糙，还要整理，并且模板格式不知道是否提供修改)
5.模型仓库（我以为这个应当不算它的一个成果，顶多就是一个模型管理的内容吧，但感觉应当挺有用的）
就写这些，再看再写
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
另外在8中书上说OOM只提供用例图、时序图、和类图，我使用的9.5中全部的9种图好象都有，还有package等。
对于数据建模，PD8足够用了，而在PD9到PD9.5中，主要升级的还是关於BPM（业务流程模型）和OOM部分，BPM实际上还是一个概念模型，现在的PD9.5对于OOM的几个视图基本都可以实现了，所以Sybase现在把PD放在了一个建模工具的位置，而不仅仅是一个数据库设计工具，从而使之成为Rose、Viso的竞争者。
PD9中，Multi－Model Report的确是多模型报告的意思,Multi－Model Report能够包含工作空间中不同种类的模型的报告以及它们之间的关系。
我感觉BPM是PAM升级版，PAM是以前的ProcessAnalyst产生的，可以打开一个PAM来生成BPM
今天看了第二章的部分内容
1、工作空间：
工作空间保存着设计者的建模环境（有点像vb6当中的工程文件VBP）扩展名为SWS
工作空间包括文件夹的层次。连接到模型的文件、连接到多模型报告的文件、外部文件等（只是连接，并没有将模型包括在内），也就是说pd9的模型基本都是按照一个模型一个文件的存储方式来组织的（是这么理解吧？），而工作空间起组织连接作用
2、文件夹
文件夹是容器，它只能包含容器而不能包含模型对象，也就是说不能由文件夹来组织实体之类的模型对象，组织这些实体等的模型对象是由PDM，CDM、OOM、MMR、FreeModel等容器
（文件夹的描述是存在SWS当中的，也就是说删除了文件夹，模型、报告等并没有删除，因为这些内容是另存为其它文件当中的）
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
另外我对快捷方式不大懂、还有就是对象的镜像怎样理解
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
我用记事本打开的pd文件都使用<?xml>之类的代码描述，那这写内容也都可以存储到数据库当中去了吧？是不是数据模型仓库的XML数据表述方法呢？
对快捷方式和镜像有一定的了解了
快捷方式和镜像都是PD组织模型的一种方式，方便建模而已，我想的复杂了
第三章的内容：
模型管理
模型的分离和发送：就是说模型如PDM可以从一个SWS中分离出来而单独存在，并且原来的SWS中此模型的连接就没有了。发送的功能我以为挺有意思，选择模型发送完后，系统将此模型作为电子邮件的附件让我发出.
包和命名空间
默认情况下对于一个PDM或CDM模型，使用同一个命名空间，也就是说在一个模型里，同样类型的对象的名称不能同样，同样会报错
默认情况下对于一个OOM不同的包内使用不同的命名空间，也就是说只有在一个包使用一个命名空间，或在一个包内同样类型的对象的名称不能同样，其它可以充复（我在9.5中试了，是这样。）
但默认值可以通过调整Use Parent NameSpace属性来调整
图形（Diagram）
图形内符号的隐藏和显示
图形到包的转换
模型的合并和比较
只有同样类型的模型才能合并，个人感觉合并比较复杂阿，头大，还是在等用到的时候再仔细研究吧。我感觉模型合并是在几个人分析然后将各自的成果综合？
模型的图形
这里就是将了模型和图形的显示方式，颜色设置，样式、打印等等的内容
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
前三章我读完了，PD给人的总体感觉是比较容易制定、灵活。希望这种灵活能给建模带来多多好处。
第四章部分1：
概念数据模型（ＣＤＭ）
理论基础：E-R理论
E－R模型是由PP.Chen在1976年提出的。
实体（Entity） 如某个患者
实体集(Entity Set ) 如某医院的患者
实体型(Entity Type) 如患者（门诊号、姓名、性别、年龄....）
标识符（Identifier）唯一标识每一个实体的一个或一组属性
联系：实体集和实体集的关联
四类：
1v1、 1vn、 nv1、 nvn
递归关系（自反关系Recursive Relationship）如学生实体集中隐含存在班长实体集和普通学生实体集标定关系（依赖关系Identify Relationship）（我理解的就是外键在表中充当联合主键的一部分）
非标定关系（非依赖关系Identify Relationship）（也可以理解为外键在表中不作主键使用）
域（domain）
－－－－
PD关於E－R模型的扩展
特殊化：比如学生实体集中的学生班委集，这样分组的过程叫特殊化
概化：比如从传染病，遗传病等等抽象出疾病实体集的过程叫概化
继承：通过特殊化或概化方法产生的实体型之间存在分类关系，这种分类关系叫继承，也叫继承联系（感觉有点和类、类的抽象有点浑），另外继承关系中可以分为互斥型和非互斥型继承，互斥型的举例：帐户：个人帐户：商业帐户，非互斥型的举例：职工：干部：教师
－－－－－－－
这么写感觉有点累，不过看了处长将帖子设为精华,hehe,劲头又来了，大家多鼓励啊，另外没人参与的话我怕记到最后都变成把书复制了一份了，呵呵。所以大家多支持啊，另外我也慢慢读。
兄弟看的这本书中，基本是PD的操作手册，而且我都怀疑是不是翻译的PD的帮助文件，不过对于新手，的确不过，不过看完了以后，依然不能知道该怎样才能设计好一个数据库
所以要想设计一个好的数据库还是要去学习数据库的理论知识
我这样补充对吗？
我一直都以为，应当先有数据库的理论知识，再选用合适的工具，理论假如足够，用Word都可以设计出一个很好的数据库，只不过PD让您事半功倍而已。理论是基础，PD，ERWin等是利剑，然后设计出好的数据库结构。一个好的数据库一定要是个弹性很强的数据库，当用户需求更改的时候，可以不需要修改数据库结构，一般只需要在数据库中增加几行数据就足以满足部分用户的新需求（这个情况我在项目中遇到了多次，还是挺爽的，不用改任何程序）
白尚旺就是我的老师,它的书只是教您操作pd的,没有什麽高深的理论.您要是想深入了解pd,那就买本关於数据库理论方面的书和一本关於uml的书就够了。白老师的书只能用于学习软件
有点不明白的的地方:
面向对象分析完成后，能跟数据库设计相关的就是类图了，根据类的持久性来建立数据库模型
而结构化开发方中（或说不算结构化方法中的内容），ER关系确定之后，建立了ER模型，就可以着手设计物理数据库了，我以为这两种方法是有矛盾的，或说我对实体关系和类和类的关系这两个内容有点混淆了，ER建模和持久类建模是否是矛盾的？能给解释一下吗？
我之所以有这个疑问是因为在PD中类图可以转化为实体建模即CDM模型
类是面向对象中的概念，所以，并不是类图可以转化为CDM，而是CDM中包括类图，然后概念模型CDM可以转化为物理数据模型PDM（持久性的类变成相应的数据库表）。
那么类和实体的有什麽联系吗？
实体和对象是否同样？
（假设类撇开操作）
另外我在PD9.5中在CDM中没有发现能够建立类图，这是为什麽？还是您说的CDM中包括类图是另有所指？
Entity就是类，在CDM中默认创建的那个Diagram就是类图。
对象是类的实例。
PowerDesigner做CDM不爽，所以我只用PowerDesigner做数据建模和简单的业务建模
我也想学学，继续贴关注中
第四章2
建立CDM
明确业务问题
创建CDM首先应当明确模型所描述的业务问题。例如，需要存储哪些信息，与业务有关的实体有那些，业务流程
怎样。了解这些问题后才可以开始建立ＣＤＭ
业务规则
业务规则是业务活动中必须遵守的规则，是业务信息之间约束的表达式。它反映了业务信息数据之间的一组完整约束，每当信息实体中包含的信息发生变化时，系统都会检查这些信息是否违反了特定的业务规则
在创建业务规则之前必须明白数据之间的约束关系
CDM向PDM或OOM转换的过程中业务规则被直接传递到PDM或OOM，业务规则不会转换为代码，需要自己动手细化和形式化。
PD中业务规则分为5种类型
业务规则类型 说明 例子
---------------------------------－－－－－－－－－－－
Definition 信息系统中对象的特征或特性 客户是可以用姓名和地址标识的人
Fact 信息系统中存在的事实 客户可以拥有一个或多个订单
Formula 信息系统中的计算公式 订单总额等于所有订单上每行金额的总和
Requirement 信息系统中功能的详细说明 所有的损失不能超过总销售收入的10%
Validation 信息系统中数据之间的约束 一个客户的订单总额不能超过对这个客户的允许值
在9.5中又定义了一种业务规则类型
Constraint
Additional check constraint on a value. Constraint business rules are used in the PDM, they are
generated in the database
对一个值进行附加的约束检查，Constraint用在PDM模型中
例子：开始日期必须在结束结束日期之前
创建业务规则
创建业务规则之前，需要考虑有关问题，例如，要解决的业务问题是什麽，系统中是否有必须进行的处理；系统的范围是否有明确的的规范；系统中存在哪些约束；如何描述这些处理，规范和约束；业务规则的类型属于这5（6）当中的哪一类。
业务规则表达式（Expression）分为Server/Client两类，Server类的将转化到数据库当中，client类的内容主要是文档编写使用，而且两中类型都可以转化到数据库中的触发器或存储过程（这句话是帮助里面说的）
关注....
居然有人用powerdesigner这种怪东西，唉！
怪在什麽地方？
好长时间没写了，自己up一下
其实一直想问这样一个问题：
在数据建模和系统架构设计中，这两者的关系究竟应当是如何的比较合适？
个人的顾虑是这样的：
1。精通这两者的人假如不是几乎没有也非常地少，所以一般人很难在数据库建模和架构设计中取得比较好的平衡。
2。系统架构设计一般是通过OO的性能取得更好的系统可扩展性和可维护性。而这样的措施一般是以牺牲一定的系统响应时间为前提的。一般的系统性能调整出了前期的设计以外，就只能靠后期的瓶颈分析调整了。
3。数据库建模虽然在一开始时就会比较重视性能，但是可能会破坏整个系统的OO结构，从而影响到更重要的指标。
那么，在这种情况下，数据库建模人员和系统设计师之间应当如何工作才能取得较好的平衡呢？
QUOTE:最初由 wp_h 发布
居然有人用powerdesigner这种怪东西，唉！
QUOTE:最初由 yining 发布
其实一直想问这样一个问题：
在数据建模和系统架构设计中，这两者的关系究竟应当是如何的比较合适？
个人的顾虑是这样的：
1。精通这两者的人假如不是几乎没有也非常地少，所以一般人很难在数据库建模和架构设计中取得比较好的平衡。
2。系统架构设计一般是通过OO的性能取得更好的系统可扩展性和可维护性。而这样的措施一般是以牺牲一定的系统响应时间为前提的。一般的系统性能调整出了前期的设计以外，就只能靠后期的瓶颈分析调整了。
3。数据库建模虽然在一开始时就会比较重视性能，但是可能会破坏整个系统的OO结构，从而影响到更重要的指标。
那么，在这种情况下，数据库建模人员和系统设计师之间应当如何工作才能取得较好的平衡呢？
确实有共同性，也有区别，但是区别容易使得这两个职位之间产生冲突。如何合理的平衡这两种冲突，这是我的问题。
Can you share your software ?
thank you
