定义实体
用鼠标双击实体的符号，可以进入实体的属性页。
- General 项目
Name：是用来在模型中标识一个实体，一般用于模型在界面中的显示（这个可以通过更改选项设置进行改变）。在一个模型当中，实体的名字不能重复。
Code：在模型转化时一般作为对象的物理名称，比如把实体属性的Code转化为数据库中的列名，当然我们现在不必为了这个实体将来叫什么而费神，一般采取与Name一致即可。
Generate：默认是选择状态，如果取消，则在转化为其他模型时，会忽略这个实体。
- Attributes 项目
窗口中下面表格里的各项很类似于一个表结构的定义，但数据类型是经过抽象化的，采用独立的表示方法，不与任何一个具体的数据库系统相关。
在此项目中为当前实体添加属性。
后面的三列CheckBox分别代表：
- M：此属性不允许为空值
- P：此属性为主键标识
- D：为可显示属性
按“Crtl+U”呼出“定制列过滤器”的窗口，可以根据自己的喜好和实际需要选择那些列出现在窗口中，那些隐藏。使用快捷键 “Crtl+E”可以允许或者禁止当前过滤器。
定义关系
双击关系（Relationship）的符号，进入关系的属性页，
- General 项目
一般最好为关系取一个贴切的名字，本例的业务关系描述如下：一个部门有多个员工，我们使用“Has”作为这个关系的名字。
同样的我们也可以描述为：多个员工属于一个部门，可不可以使用“Belong to”作为关系名字呢？一般不推荐这样做，在概念图中有一个约定，关系的名字采用从“1,n”中“1”所在的方向向“n”所在一方进行读取的语义。本例即 “1”在部门一方，从部门一方向雇员一方读取语义，即：部门有（Has）多个员工。
- Detail 项目
假定对于实体部门（Department）和雇员（Employee），具有如下关系：
- 一个部门可以有多个雇员，新成立的部门也可以暂时没有任何雇员；
- 一个雇员必须属于一个部门，并且同时只能属于一个部门；
根据以上关系，我们修改属性页，部门－雇员的方向采用默认的0,n，雇员－部门的方向修改为强制约束（Mandatory），或者从下拉框中选择“1,1”，如下图：
注：在Power Designer中，关系符号靠近实体端的一个“横线”代表强制性约束，“空心圆圈”代表无强制约束，即这一方可以无对象关联；“非分岔”线代表为“1” 的关系，“分岔”线代表“多”的关系。以上四个符号共可以组合出16种关系（包含反向）。其中“多对多”的关系一般通过给出一个中间实体来进行分解，所以在许多概念图中，是看不到实际的“多对多”的关系存在的。
另外在关系的属性中还有两项：Dominant role 和Dependent，可以表示更复杂的关系
处理多对多(n..n)的关系
在概念模型中，一般很少看见两个实体之间是直接的n..n 的关系，一般这种情况下我们会增加一个中间实体，在Power Designer中，提供了一个专门的符号来对应，叫做“Association”。请考虑以下的情形：
企业中拥有帐号的雇员在系统中具有不同的操作权限，这通过用户角色来进行管理，权限已经分配给了多个不同的角色，一个用户帐号至少属于一个角色，并 且可能会同时属于多个角色，一个角色可以包含0个或多个用户帐号。根据以上描述，我们添加一个实体“Role”，它与实体“User”之间是n..n 的关系，为了表达这种关系，我们增加一个“Association”并分别使用“Association Link”与其他两个实体建立关系，
数据库设计工具对比
PowerDesign：PowerDesign是 Sybase推出的主打数据库设计工具。PowerDesign致力于采用基于Entiry-Relation的数据模型，分别从概念数据模型 (Conceptual Data Model)和物理数据模型(Physical Data Model)两个层次对数据库进行设计。概念数据模型描述的是独立于数据库管理系统(DBMS)的实体定义和实体关系定义。物理数据模型是在概念数据模型的基础上针对目标数据库管理系统的具体化。
ERWin：这个是CA公司的拳头产品，它有一个兄弟是BPWin,这个是CASE工具的一个里程碑似的产品。ERWin界面相当简洁漂亮，也是采用ER模型，如果你是开发中小型数据库，极力推荐ERWin，它的Diagram给人的感觉十分清晰。在一个实体中，不同的属性类型采用可定制的图标显示，实体与实体的关系也一目了然。ERWin不适合非常大的数据库的设计，因为它对 Diagram欠缺更多层次的组织。
如何一次性将表结构的脚本导出来？
Database --->Generate Database ---> Genarate Script. 就可实现。
Name用中文英文以便查询、写程序的时候方便， Code才是最终产生的Table Name
PowerDesigner中建了模型，如何把它作为文档导出？
利用REPORT。选择一个模板，然后就生成了RTF或是HTM格式的文档
如何将已经存在的数据库所有表，导入到PowerDesign中？
用PD里的反向工程file--->reverse engineering ===> and go on
概念数据模型(CDM)
CDM表现数据库的全部逻辑的结构,与任何的软件或数据储藏结构无关。一个概念模型经常包括在物理数据库中仍然不实现的数据对象。它给运行计划或业务活动的数据一个正式表现方式。不考虑物理实现细节，只考虑实体之间的关系。
物理数据模型 (PDM)
PDM叙述数据库的物理实现。主要目的是把CDM中建立的现实世界模型生成特定的DBMS脚本，产生数据库中保存信息的储存结构，保证数据在数据库中的完整性和一致性。
面向对象模型 (OOM)
一个OOM包含一系列包，类，接口和他们的关系。这些对象一起形成所有的(或部份)一个软件系统的逻辑的设计视图的类结构。一个OOM本质上是软件系统的一个静态的概念模型。
业务程序模型(BPM)
BPM描述业务的各种不同内在任务和内在流程，而且客户如何以这些任务和流程互相影响。BPM是从业务合伙人的观点来看业务逻辑和规则的概念模型，使用一个图表描述程序，流程，信息和合作协议之间的交互作用。
正向工程
你能直接地从PDM产生一个数据库, 或产生一个能在你的数据库管理系统环境中运行的数据库脚本。可以生成数据库脚本,如果选择ODBC方式,则可以直接连接到数据库,从而直接产生数据库表以及其他数据库对象。
逆向工程
将已存在的数据库产生进新的PDM 之内。数据来源可能是从脚本文件或一个开放数据库连接数据来源。
并不是每个设计都需要用到Power Designer。 例如：小的系统，或Table数比较少的情况下就没有必要采用Power Designer了。
设计步骤
CDM PDM OOM三者转换关系
2004-08-22更新
PowerDesigner仅仅是实现的工具
不要以为Power能帮你把关系什么的全部建立好，很多数据库理论只是还是需要的，设计数据库的时候，那些范式什么的，一定要掌握。
设计一个好的数据库，最好的工具不是必须的，但是基础理论是一定要的。
PowerDesigner用途不局限于数据建模
还可以用PowerDweigner设计web service
并不是每个设计都需要用到PD
用Powerdesigner对付比较大型的项目，是很好的，对于短平快类型的项目，如果时间要求你1个星期完成一个程序，那么完全没有必要用 PowerDesigner，直接维护数据库就可以了，当表的数量超过10个（一个小系统的表在10个左右）的时候，建议还是用用 Powerdesigner 。
我的看法：如果想做成一个比较规范的数据库，小项目也可以用。毕竟生成报表和正反向工程很有用。
零碎
PD中的CDM设计时，可以将所有需要的字段都定义好。然后在设计实体是直接取出来。PD提供了这样的统一管理的工具。在PD菜单栏-Model-Data Item下。
为了使自己设计的CDM看起来象样一点，可以从工具栏中，拖动一个Title。其显示的信息，是当前CDM的属性值。
为了使实体等Symbol看起来显眼和舒服。可以根据个人喜好进行外观上的调整。当前设计界面中，右键-Display Perferences中进行设置。还可以增加shadow效果。选中Symbol后，Ctrl+W。或者右键菜单。
为了使布局整齐。选中需要调整的Symbol后，菜单-Symbol-Align进行设置。快捷键：ctrl+UP,ctrl+Down,ctrl+Left,ctrl+Right即为上下左右对齐。
设计实体属性时注意的细节：M：表示强制非空；P：是否为主键；D：是否在模型中显示。gerenate：表示是否作为表生成。
默认情况下，CDM的实体会显示Identifier一栏。如果不想其显示出来，在右键-Display Perferences中ObjectView-Entity中设置。
关系的命名方法是：实体名1 实体名2。
关系中的角色（Role）表示联系线上一个方向上的含义。用一个动词来描述。Role只是起一个描述作用。
依赖(Dependency)：表示在联系中一个实体的存在是否依赖于另一个实体。寄生实体（Dependent Entity）是一种部分地被另一实体确定的实体。在依赖联系中，一个实体与另一实体通过标识符相联系，当一个实体的存在没有另一个实体的存在作为参考就不能唯一确定时，两个实体间就存在依赖联系。
主从表就是典型的依赖关系。
中间实体（Associative Entity）：是为了解决多对多联系而产生的一个人工实体，能够为中间实体定义属性。用鼠标右键单击多对多联系线，在弹出的菜单中选择“Change to entity”，能够把这个联系转换成连接两个实体的中间实体。
善于利用自动生成的中间实体，可以简化设计工作，提高数据库设计的正确性。
中间实体一般不用再加入新的字段。
牢记：外键是通过关系Relationship自动来建立的，不需要手动建立。不然会产生多余的键。所以设计时，关注实体本身的字段，以及实体间的关系，特别是多对多和依赖关系。
从CDM到PDM的转换需要注意：
不能改变Diagram的名称
在树状图中，如果钩选红色标出的Symbol表示覆盖修改，不钩选表示保护修改。
数据库为了保证数据完整性和一致性，提出了约束。即表约束，列约束以及参照完整性约束。通常数据库设计和程序开发不是绝对的分离的。所以前两者在实际开发过程中逐渐的完善。需要注意的还是参照完整性约束。
在PD中前两者的设定是对字段，后者是对关系。
参照完整性约束
限制（Restrict）。不允许进行修改或删除操作。若修改或删除主表的主键时，如果子表中存在子记录，系统将产生一个错误提示。这是缺省的参照完整性设置。
置空(Set Null)。如果外键列允许为空，若修改或删除主表的主键时，把子表中参照的外键列设置为空值（NULL）。
置为缺省(Set Default)。如果指定了缺省值，若修改或删除主表的主键时，把子表中参照的外键设置为缺省值（Default）。
级联(Cascade)。把主表中主键修改为一个新的值时，相应修改子表中外键的值；或者删除主表中主键的记录时，要相应删除子表中外键的记录。
注意理解以上的约束时，抓住操作的都是主表。子表的操作都是相对主表来说的。操作方式就是Update和Delete。
引用基础数据表的数据时，可以建立对应的视图。选中需要作为视图的表，菜单栏-Tools-Create View
PD支持对已有数据的表更新表结构。不过需要谨慎操作，检查生成的SQL脚本。
PD也可以生成随机的测试数据。
触发器就是DBMS中提供的事件驱动机制。发生在表的Insert,Update和Delete。执行SQL语句或存储过程。
在PD中可以完成存储过程的编写，也便于管理。
逆向工程可以通过数据库脚本或者通过ODBC数据源来实现。
posted @ 2011-12-13 22:36 LiMeiRui 阅读(78) 评论(0) 编辑
需要特别注意的一点，在创建好一个新的概念模型后，最好在model options中，将数据项的唯一代码和允许重用两个选项去掉。否则不同实体中的同名属性会被认为是同一个数据对象，改一个另外的也会跟着改。大多数情况下都不需要这种特性，相反它会带来麻烦。 但是，如果允许不同的表有相同的字段名，在创建视图的时候，需要为重复的字段名指定别名。 有利有弊啊。
做好这个设置后，开始下面的步骤：
1）把创建上实体，最初只需要命名中文名称。当然，之前需要进行系统的需求调研与分析。
2）分析实体间关系，画上关系，准确的确实出是一对一还是一对多，对于多对多关系，最好创建关联实体。
3）创建实体的属性，先不要管英文名称和数据类型，只命名中文名称。添加属性的过程中，尽量更细致的修改实体及其关系。并指定各实体的主键。 不要让实体没有主键，这不是个好习惯。
4）对形成的模型进行讨论、修正。
5）创建domain。 domain是什么东西呢，应该翻译成“域”吧， 但实际是一种自定义类型。把常用到的数据类型定义成domain，所有的属性指定其domain，而不直接指定数据类型，会给以后的工作带来很大的方便。一个域定义使你能适用于多个数据项目的标准数据结构。当你修正一个域时，你将更新全部与域关联的数据项目。当你作任何变化的时候，这导致数据一致化特性比较容易 。
6）为各属性命名英文名称。这基本就是将来生成的数据库里的字段名称了。
7）为各属性指定domain
至此，概念模型创建完成。 默认的图形中的字符很小，可以通过右键弹出菜单里的显示配置项，设计实体名称及属性的字体。 也可以设置不显示关系的名称，并修改关系连线的样式，以获得好的显示效果。
也可以设置不同性质的实体为不同的底色，以获得更明确的效果。但是不建议将实体分在不同的包中，那样实体关系不太直观，也会有一些其它麻烦。如果是超大型的系统，实体特别多，合理的划分包是一个重要的工作。
在对概念模型反复的修正后，便可以生成物理模型了。在工具菜单里便有这项功能。
2、生成物理模型时，是需要选择数据库系统的。就是说物理模型是数据库相关的。当然需要选择正确的数据库系统。
1）注意检查生成的表间关系是否有问题。这时候概念模型里的实体就转化为物理模型里的表了。一些概念模型里的关系和约束，生成到物理模型里可能会出现问题，需要手动修正一下。虽然这种情况不多见。
2）生成的很多外键会重名，可以用check model检查一下，把重名的外键名修改一下。
3）将所有字段设置不允许null值。就是勾上表的属性窗口中，每个字段的M列的选择框，其实就是字段的Mandatory属性。也可以在概念模型中做这一工作。 这样做的好处是，在代码中一般不会碰到从数据库中取到的值为null的情况，可以简化很多工作。这里多做的工作绝对是值得的。当然这种情况下，对于很多字段，我们最好提供默认值，以避免一些情况下对插入数据时有过高的要求。 我们不必每个字段去指定默认值，因为我们应用了domain，前面提到过的一种自定义数据类型。下面我们继续说明如何给domain添加默认值。
4）添加默认值对象。也许有些人不清楚，默认值是一些数据库里的一种对象，就象表、字段、触发器一样，默认值在Sql Server 中就是一种对象。在物理模型里，可以创建它。一般我们可能只需要三个默认值对象：数字型的默认值、字符串型的默认值以及日期型的默认值。 在物理模型中定义上这三个默认值对象。
5）为每个domain指定默认值对象。这样，每个被指定为这个domain类型的不允许null的字段，就会继承domain的默认值。注意，这是数据库的特性，不是PD的特性。不管怎么说，我们很容易的做了指定默认值的工作。好的数据库设计可能会考虑的更细致，比如有些数字型的字段，应该默认为1,而不是0。 这时候你只需要重新指定一下字段的默认值，他就不会再从domain中继承默认值了。
6）对物理模型检查修正后，便可以生成数据库了。 生成数据库时有很多选项，比如是否生成一些对象的drop脚本等，都可以控制的。
注意，在修改好物理模型后，不要再重新生成物理模型，否则很多在物理模型中定义的东西会丢失。如果需要做改动，以物理模型为准，概念模型可以反向生成，或者手动保持同步。
有些概念可能会乱，在这里把这些名词整理一下。
概念模型 －－－ 物理模型 －－－ 数据库 －－－－ 解释
1）、 实体 －－－ 表（table）－－ 表 －－－ 实体和表对应，但并不完全是一回事了。
2）、 属性 －－－ 字段 －－ 字段 －－－ 不解释了
3）、 Domain －－－ Domain ------自字义类型 －－－ 其实就是自字义数据类型。
4）、 默认值对象 －－ 默认值对象 －－－默认值对象 －－－含有默认值，但不是默认值。不太常见，但很有用。SQL Server文档里说未来的版本可能会取消默认值对象相关的一些东西，谁知道呢。
概念模型、物理模型、数据库三者是可以相互转化的，相互的正向或逆向工程。
posted @ 2011-12-13 18:27 LiMeiRui 阅读(34) 评论(0) 编辑