PowerDesigner设计数据库

李伟华 2000年9月

说明：此文档为本人经验积累之所得，非部门设

本文档不讲述如何使用PowerDesigner，而是讲述如何将

PowerDesigner的特点结合数据库设计的方法更好的设计一个数据库

系统。

采用PowerDesigner设计数据库

PowerDesigner作为数据库建模和设计的CASE工具之一，在数

据库系统开发中发挥着重要作用。

运用PowerDesigner进行数据库设计，不但给人直观地理解模

型，而且充分运用数据库的技术，优化数据库的设计。PowerDesigner

支持Sybase、Oracle、Informix、SQL Server等多种数据库系统，在

应用系统做数据库迁移时不必维护多个数据库脚本。

对于采用结构化分析（SA），E-R图、数据流图直至最后的数据

库物理图都是系统设计时不可缺少的一个部分，当数据库物理图完成

后，应该产生系统的数据字典。运用PowerDesigner完全能够完成这

一设计流程。

对于采用面向对象的分析（OOA），由于数据库采用的是RDBMS，

因此存在对象和关系数据库之间的映射，也需要进行数据库设计。

两种数据库模型

PowerDesigner可以设计两种数据库模型图：数据库逻辑图（即

E-R图或概念模型）和数据库物理图（物理模型），并且这两种数据库

图是互逆的。

数据库逻辑图是对现实世界的一种抽象，体现实体之间的关系，

可以有1对1、1对多、多对多等关系。特别说一点，在扩充E-R图中

有概括这种关系，体现类型之间的一种子集联系，它定义了超类和子

类。在PowerDesigner设计的E-R图中，不具备这种关系，但在E-RWin

设计的模型中支持这种关系，因此在用E-RWin图设计的模型转化为

PowerDesigner的模型时注意这种关系。

数据库物理图中是逻辑模型的物理实现，体现了表间的参照关

系。在物理模型中不可能存在多对多的关系。在逻辑图向物理图转换

时，多对多的关系变成两个1对多的关系。

逻辑模型和物理模型有着紧密的联系，也有本质的区别。逻辑模型

的设计遵循数据库设计理论的第三范式（在一般的数据库应用达到第

三范式即可），逻辑模型要求具有应用系统所表达的所有信息并消除

数据冗余。物理模型是在逻辑模型的基础上，为了优化应用系统的性

能而采用增加冗余，创建索引等数据库技术，它主要用非规范化的一

些理论。

在考虑设计的任何非规范化之前，数据库应先完全规范化，在没有

完全理解数据和用户需求之前，不能进行非规范化。否则导致数据的

组织越来越混乱，应用程序越来越复杂。

因此逻辑模型和物理模型是相互矛盾又紧密联系的，这点需要设计

人员好好把握。

PowerDesigner设计数据库物理图

用PowerDesigner设计数据库物理图，包括多个对象，如表（Table）、

字段（Column）、域（Domain）等。设计时主要在PowerDesigner的

Dictionary和Database两个菜单中。

表（Table）

表是数据存储的一个逻辑对象，包括其它对象如字段（Column）、

索引（Index）、触发器（Trigger）、存储过程（Procedure）等，表

的优化设计有分割等技术，对于表的存储，如果访问数据量大，访问

频率高则可考虑将表放在不同的存储（Storage）上。

在设计表时，应该估算表的大小和增长量，便于创建数据库时分配

数据库空键，这样减少了磁盘碎片的产生。

在关系数据库中设计主键时，采用有意义的主键是致命的错误。如

果用户决定改变字段的商业含义，则需要在所有使用到该信息的地方

进行修改。主键的作用应是保持唯一性和作为外键使用。任何对主键

的修改会导致巨大的数据库维护工作量，显然这是不合适宜的设计。

就关系数据库而言，设计主键策略采用的是代理主键的方法。

设计主键时应该避免“热点”现象，但也需要分析具体的应用系统

的并发用户而定。

字段（Column）

定义一个字段主要有字段名、字段类型及长度、是否主外键、是否

空、约束、默认值、域等。

变长和定长的数据类型在数据库设计中讨论比较多，作为一般原

则，如果预期某列中的数据范围变化很大，但变化并不频繁，那末对

这样的列使用变长数据类型最为适宜。

决定行长时，既不能太浪费，又不能太吝惜。考虑到将来的需要，

并且意识到，如果增加行长而没有改变一页中容纳的行数，那末增加

的空间就等于免费使用。

设计时，字段尽量使用域，方便维护字段的类型。每个字段最好将

默认值加上，因为在数据库查询中，有NULL值会影响查询的性能。

通过CHECK约束可限制字段的取值。

域（Domain）

简单地说，是用户自定义类型，但域还可以定义它的取值范围

或默认值，采用域减少了维护字段类型的工作量，也减少数据的不一

致性。

参照（Reference）

参照在数据库设计中是一个比较复杂的问题，它是实现数据的

完整性主要要素之一，详细论述参考后面数据的约束。

在PowerDesigner中，可对参照完整性进行各项设置，参照的

基数从0到n，对修改和删除约束可分别设置为None、Restrict、

Cascade、Set Null、Set Default。由于INSERT包含在UPDATE操作

中，因此没有单独的INSERT约束。

约束的不同设置产生不同的效果，以修改为例（删除相同）：

None：父表修改，子表不影响。

Restrict：父表修改，如果子表存在，则出错。

Cascade：父表修改，如果子表存在，则相应的修改。

Set Null：父表修改，如果子表存在，则相应置空。

Set Default：父表修改，如果子表存在，则相应置默认值。

索引（Index）

索引是优化查询时采用一种数据库技术，索引有簇索引、非簇索引、

唯一索引等。

设计索引时，要注意索引宽度，尽量减少索引的宽度。索引的宽度

不是由字段的多少决定的，而是由字段的长度来决定。对于窄索引关

键字，在每一索引页上放置更多的关键字和指针，这样就能花销更少

的I/O找到数据。

对于复合索引，选择首列相当重要，否则可能不能利用该索引，当

利用复合索引查询时。必须确保查询从首列开始。

索引还有一个填充因子（FillFactor），填充因子的大小视表的数

据增长量和主键定义的情况而定。

触发器和存储过程（Trigger&&Procedure）

触发器在维护数据完整性起着重要作用，它比参照更具灵活性，

也能实现三层结构中数据层的业务规则。

存储过程是采用SQL及流程控制语句编写的完成某种业务的脚本。

存储过程在数据处理上具有处理速度快、处理灵活等优点。

但是，存储过程极大地增加了与数据库之间的耦合，在数据库

迁移时，需要重写存储过程，从而增加了版本维护的工作量。如果数

据库要求从迁移性考虑，应尽量避免使用存储过程或者触发器。

如果不人为修改PowerDesigner的触发器，其迁移性

PowerDesigner自动解决。

存储（Storage）

不同的数据库中有不同的概念，Sybase称为设备（Device），

SQL Server称为文件或文件组（File、FileGroup）,而Oracle称为表

空间（TableSpace）。

根据系统创建一个或多个存储，按一定的优化规则存放。

数据库的划分

数据库的划分以它的物理分布为原则，而不应数据量、表类型等原

则来划分，数据库的多少对数据库的性能影响不大。对于访问数据量

大、访问频繁的表来说，I/O操作很容易形成严重的瓶颈，因此减少

I/O操作和I/O操作阻塞是数据库设计考虑的主要问题，解决方法将将

表放在多个设备上，设备需创建在不同的物理驱动器上，最好能用智

能型或阵列。

日志和数据分开存储在不同设备上，如果索引多且占用空间大，也

可以采用如此方式。

数据库数量少的维护成本比数量大少。

因此数据库划分以物理分布为原则。

在PowerDesigner提供计算数据库或表的方法（Compute Database

Size），可帮助设计者完成数据库的划分。

数据库的完整性

数据库完整性可通过存储过程、声明性参照完整性（DRI）、

数据类型、约束、规则、默认值，以及触发器来实现。在数据库内，

这些功能各以特有的方式发挥作用。综合利用这些完整性功能，可以

使数据库灵活，易于管理，而且很安全。

数据完整性概念分为几个方面。

◆ 表域完整性

通过主键来强制表的域完整性。

◆ 引用完整性

利用参照来加强表之间的逻辑关系。

◆ 数值域完整性

任何输入的数据在类型和范围上必须与指定的数据类型相匹

配，只有当某列被说明允许NULL值，才允许向该列输入NULL。

数据库的性能测试

生成数据库之后，应进行数据库性能测试，以便优化数据库的设计，

因此需要生成测试数据，由于是性能测试，数据的规范性要求不高。

通过PowerDesigner可方便地生成测试数据（Generate Test Data），

完成性能测试。

数据的约束

O-O约束

对父表的INSERT、UPDATE、DELETE操作没有限制。

M-O约束

对父表操作的约束：

父表的INSERT操作，对M-O约束，父表中间的记录可以没有任

何约束地添加到表中，因为这种约束中不一定必须有子女。

父表的键值修改操作，只有在子表中其所有的子女对应均做修改

后，才能修改，即一般采用级联更新的方法。

父表的删除，父亲只有在其所有子女均被删除或重新分配之后该父

亲才能被删除。

强制对可选（M-O）约束O-M约束

父表操作的约束：

父表的INSERT操作，对O-M约束，一个父亲只有当至少当它的

一个、子女同时被加入或至少存在一个合法的子女时，才能被加入。

父表的键值修改操作，只有当一个子女被创建或已经有一名子

女存在才行。

父表的删除，理论上删除父亲是没有限制的，实际上，删除主

表记录时，不采用级联删除子表的方案，而采用将子表的外键置空。

可选对强制（O-M）约束

M-M约束

父表操作的约束：

父表的INSERT操作，可能随后需要生成子女，即在子表中创建

新的行。也可能通过对子表的重新分配来实施完整行限制。

父表的键值修改操作，只有在子表对应的外键的值修改成新值

时才能进行。实际可能是先创建新的父表纪录，接着修改子表所有对

应的纪录，使其与父表的新纪录关联，最后删除原父表纪录。

父表的删除，只有在子表中所有相关的行全部删除或重新分配

之后，才能删除父表中的纪录，一般对子表也进行删除操作。

强制对强制（M-M）约束

在四类约束：M-M、M-O、O-M、O-O。键值的修改可能会改变表

之间的关系，而且可能违反一些约束。违反约束的操作是不允许的。

具体的应用必须根据实际的要求和商业规则进行适当的选择。但在设

计和开发时，必须考虑所分析的约束。

物理图的组织

数据库物理的组织以功能来组织为好，让人很容易就明白该功

能需要操作哪些表，数据是如何流向的，但是按此组织，可能有些参

照建立比较乱，其实有些参照可以不必建立，如在写入一个表时，其

数据的来源就是从另一个查询得到的，可以保证数据的正确性，从功

能划分来组织物理图，就可以不建立这个参照。

数据库的生成

有了数据库物理图，在生成数据库或数据库脚本时，应注意如

下的问题：

参照完整性的实现，可以采用声明性参照实现或触发器实现，

至于两种实现的优缺点，前面已经论述过，这里仅说一点，如果采用

触发器实现需要在生成数据库后再生成触发器。

当参照含有级联（Cascade）删除或修改时，其实现要分情况处

理：

Sybase、SQL Server不支持声明性级联（Cascade）删除或修改，

只能通过触发器（Trigger）来实现。

Oracle、Informix支持声明性级联（Cascade）删除，但不支持

级联（Cascade）修改，也只能通过触发器（Trigger）来实现。

当定义了用户自定义类型时，在生成数据库时，最好转换成数据库

基本类型，对数据库性能和迁移都有利。

数据字典

数据字典作为产品的一个归档文档，它定义应用系统数据库的各个

方面。数据库物理模型建好后，就可以生成数据字典，数据字典的内

容和形式可以在PowerDesigner定义模板，依据模板生成数据字典，

再处理一下文档格式。

在PowerDesigner用Create Report生成数据字典。

目前系统需要处理和优化的地方

主键的定义：

由于对业务了解的深度不够，某些表的主键建立存在一些问题，

随着业务的深入逐步完善。

参照的建立：

主键的定义不完善导致了参照建立的不完善，这也只能以后组

不完善。

数据库的划分：

数据库的划分前面已经谈过，由于这个划分影响着服务器和客户端

的程序，也只能以后的新版中解决。

表结构的调整：

对于有些表，如系统设置表，可以将它的横向结构改为纵向结构，

这样增加了系统的灵活性。