使用ERWin设计数据库

作者结合自己多年的实践经验，系统阐述了利用ERWin进行数据库建模的思想、方法和注意事项，具有一定实用价值。

ERWin Data Modeler是CA公司的数据库建模工具，目前在关系数据库的设计中，有着比较广泛的应用。笔者经过多年的实践，感觉使用ERWin设计数据库，上手还 是比较快的，但是要在项目中使用好，对于不同的开发环境和不同的项目，在开发的不同阶段使用ERWin，可能采取的最佳策略也不相同。

使用前的准备

1．学习ERWin支持的方法论

ERWin 支持两种方法论，一种是IE（信息工程），另一种是IDEF1X，在使用ERWin之前必须了解其一，不然，将连标记符号也搞不清楚。这里笔者简单谈一下 IDEF1X（详细内容在ERWin的联机文档中有介绍）。IDEF1X为数据模型提供了一种规范的结构，是语义模型化技术，主要描述的对象包括实体、联 系和属性。同时，作为一种工业规范，IDEF1X还强调了对开发上述模型需要的方法。这样，标准化的标记语言和相关的辅助方法论组合在一起，就可以充分保 证设计的高效率和有效性的平衡了。

2．学习ERWin

掌 握了ERWin支持的方法论，并不等于掌握了ERWin，方法论仅仅解决的是逻辑模型，而ERWin还要支持物理模型，还有界面和操作的问题。由于在生成 数据库的过程中，需要对于使用的物理数据库有比较多的了解，所以还一定要了解IDEF1X和目标关系数据库之间的差异，这种差异，可能对于微机平台、小数 据量的应用关系不大，但是对于大型数据库，还是有很多物理的参数、限制等应该了解。

4．确定数据库表、字段的命名规则

确定数据库表、字段的命名规则，看似容易，其实涉及到的方面很多，而且初始阶段一旦没有处理好，以后再改难度比较大。笔者认为，命名宜考虑如下因素：

● 如果新开发的系统是一个大系统的子系统，那么应该考虑原来大系统的数据库、字段命名的规则，即使这样的规则存在问题，也要在取得共识的基础上进行改进。

● 考虑开发和运行工具的限制要求，以及生产系统的限制要求。

● 在可能的情况下，应考虑匈牙利命名法。对于应用系统，往往对于数据是有分类的，如果能够把这些分类体现在数据库表名和字段名中，则是有益无害的。

● 字段名保持惟一能够避免一些不小心导致的对数据库字段的使用错误。

5．对数据库表进行分类

对于数据库表进行分类，能够使数据库更加清晰，也便于系统管理。根据笔者的体会，对于每一类数据库表，如果允许，可以按照匈牙利命名法的规则规定一个特征标记，可以是前缀也可以是后缀。

建立数据库的逻辑模型

ERWin作为一个建模工具，引进了一些概念和工具，这些概念和工具往往贯穿于逻辑模型和物理模型中。但是这些方面如果在逻辑模型中处理不好，到了物理模型的阶段也往往木已成舟，没有办法了。

1．用好Domain

Domain 的概念有点像是属性的数据类型，笔者的体会是，如果不打算使用Domain，则不要增加任何Domain，都用ERWin提供的默认值; 如果打算使用Domain，则应该对于每一类数据等同的属性建立一个Domain，而且在修改数据类型的时候，仅仅修改Domain中的内容。总体来看， 使用Domain虽然可能增加一些工作量，但是可以建立所有属性数据类型的定义树。

2． 用好Definition

Definition和Domain不同，不是一个可操作的实体，而是在每一个Domain，每一个实体和属性中的一个标签。在Domain、实体和属性的建立和修改过程中，正确地维护Definition，是能够随时得到文本数据结构说明的一种有效的方法。

3． 处理好键值组命名

采 用自己方便和清晰、又能为实现环境所接受的键值组命名。其中，对于主键、次键、外键和单独建立的可重复索引，应该进行区分，因为对银行等行业的多应用交互 的大型、复杂的运行环境，如果不加以关注，可能在投产后的系统管理中造成很多麻烦。实际上，ERWin对于上述的键名称和索引，在命名的时候是有所区分 的，应该充分利用这种区分，在满足环境的情况下，可以直接使用ERWin给出的命名。

对于外键的命名，在逻辑 模型中，体现为关系的命名。ERWin默认的做法是用一个内部连续的编号，这样可以做到保证命名的惟一，但是并不清晰。在实际工作中，笔者发现，父实体对 于子实体往往是包含关系，尤其是对于代码类的父实体，更是如此。因此，笔者采用了“子实体3父实体”的方式，其中“子实体”和“父实体”都可以是实体名称 的缩写，而“3”的意义是借用了其字形比较像数学中的属于符号的含义。这样，实际上是对IDEF1X一种变形的应用，这个短句包括父实体、动词和子实体， 而动词永远是“属于”。

4． 充分利用Subject

对于大型的应用，可以用Subject来关注某些方面的内容。可以仅仅将感兴趣的实体放入Subject中进行处理，而且还可以按照Subject来产生建表的脚本。对于图形布局来说，各个Subject是相互独立的。笔者在以下的两种情况下经常使用Subject：

● 从业务逻辑分析问题的时候。对于某一个角度，可能往往仅仅涉及到部分表，为了充分利用图形来描述实体间的关系，将这些相关的实体放入一个Subject 中，然后用手工进行图形的布局。

● 对于工作表和历史数据表，往往具有基本相同的数据结构，但是历史数据表还要增加一些历史纪录信息。一般不论是由ERWin自动进行版面布局还是自己根据需 要进行的版面布局，很难将工作表和历史数据表放在一起，而在修改时，这两个表最好是一起修改，不然如果出现不一致的问题就相当麻烦了。

5． 谨慎使用参照完整性

在关系数据库中，提供了参照完整性的概念，利用好参照完整性，可以保持应用数据的高度一致性，但一定要谨慎使用。一般来说，实现参照完整性有三种方法，第一种是使用数据库的触发器; 第二种是使用数据库的外键; 第三种是使用应用逻辑。

对 于使用数据库的触发器，这种方法有着最大的灵活性。触发器是由数据库的引擎控制的，只要数据库的引擎不出问题，那么触发器就总是有效的，除非人工关闭触发 器，否则数据的一致性可以得到最大的保证。但是这样也会引入两个问题: 对于数据的修改没有痕迹，如果是误操作，那后果是不堪设想的; 对于一些联机交易系统，所有的交易必须快速响应，如果采用这样的触发器，系统的响应时间就会变得太长。

对于使用数据库的外键，这种方法相当于设置了一个子表，对于父表不存在的内容，子表不能插入，也不能修改，但是对父表却没有约束。这种方法，在起作用范围内，效率还是比较高的。

对 于系统环境不允许使用触发器的情况，或者对于错误定位要求比较明确以致超出外键能够报告的详细程度的情况，就要使用应用逻辑了。使用应用逻辑实际上可能效 率会低于外键，而且由于数据库本身已经没有了控制机制，所以对于应用逻辑的错误或者绕开了应用逻辑的情况，是没有办法保证数据一致性的。

处理数据库的物理模型

实际上，在建立数据库逻辑模型的过程中，物理模型就也已经建立了。但是，在处理数据库的物理模型时，仍旧有一些方面要给与特殊的关注。

1． 要特别关注逻辑模型到物理模型的映射关系

IDEF1X的实体名对应数据库的表名，属性名对应字段名，关系名对应约束名，外键名对应索引名。这些似乎全部是自动完成的。但是，如果对于Domain使用不当，有可能形成两者不一致的情况，这时，要在改了逻辑名之后，看一下物理名是否也正确。

另外，在逻辑模型中，数据类型是比较丰富的，对应到了物理模型，要看看到底是不是需要的数据类型。

还 有一点要说明的是，即使在物理模型中，在图中显示字段的次序按照列（Column）和按照物理次序是不同的。如果编写程序时，使用的是“Select *”之类的用法，想看到字段的物理次序，一定要在物理模型中将“Format”菜单中的“Display Level”选项设为“Physical Order”。

2． 需要定义所使用的目标数据库涉及到的物理参数

使 用ERWin的优点，就是最终能够做到产生的脚本能够实现完全等价的人工配置，换句话说，ERWin也能够成为DBA的工具。不同的数据库，对于建库脚本 中需要的物理参数差异比较大，为了合理地定义参数，开发部门应该与系统管理部门协商，定义参数应该尽量按照继承的方式进行，便于统一协调和管理。

3． 正确选择正向工程的选项

ERWin的正向工程，也就是根据物理模型联机建立数据库表或者生成DDL脚本，有很多选项，这些选项的正确选择十分重要，如果选择不当，即使辛辛苦苦做出一个符合要求的模型，建立的数据库却可能是不对的。为此，笔者有如下几点经验：

● 对于正向工程可能的选项，决不能想当然，在更换了数据库，甚至升级了数据库的版本后，都应该认真地审查一下选项是否正确。

● 对于正向工程在生成时的选项必须认真斟酌，从生成的脚本中，判断每一个选项的作用。

● ERWin可以生成的索引包括主键索引、替换键索引、非惟一索引和外键索引四类。一般来说，主键、次键都是需要的，而非惟一索引是根据业务需要加上去的， 一般也会需要。外键索引则首先要看是否在物理模型中使用了外键，其次要看是否根据外键进行检索，再次还要看是否外键的索引就是主键的索引。

● ERWin在默认的情况下，是不按照用户定义的约束名来产生DDL脚本的，如果想按照用户定义的约束名产生DDL脚本，应该在正向工程的“Other Option”选项中，选中“Constraint Name”。

4． 逆向工程的一种使用方法

逆向工程能够从一个现有生产库或者数据库的脚本中产生ERWin的物理和逻辑模型，但是，据笔者的体会，逆向工程产生的结果，一般无法判定各个实体之间的关系，也就是说，实际上是一个一个的表，视图也可以产生出来。

逆 向工程的一个用途，就是在有十分严格的系统管理，往往不接受指定格式的数据库维护需求的情况下，当提交了更改需求后，可以向DBA请求其操作的DDL脚 本，据此生成模型，进行模型级的全面比较。由于比较的时候，可以指定比较的内容，所以可以找到很多手工难以发现的差错。

5． 充分利用全面比较功能

对 于数据库已经投产后，需要带着数据进行数据库升级的情况，使用全面比较是一种可行的方法。在全面比较时，既可以看到两个版本的全部差异，也可以实现两个版 本中的一个向一个靠拢，或者两个版本的合并。需要注意的是，由于目前版本的ERWin还不能指定生成全面比较的DDL脚本与正向工程对应的选项，所以对于 生成的DDL脚本，还是应该进行一定的手工验证的。

自数据库的设计开始，对于每一次数据库的更改，均记录相应的版本，然后使用全面比较确定差异，这样可以有效地减少出现错误的概率。即使已经确定使用产生全部新表的方式重建数据库，也应进行全面比较，以确定是否改动了所要改动的，并且没有改动所不要改动的。

链 接

使用数据库建模工具的好处

便于从总体上把握数据模型

如果采用了数据库建模工具，并按照一定的方法论，建立了逻辑模型，则易于从总体上把握数据库的设计。

能够支持多种物理数据库

大型项目往往需要支持多种数据库，如果采用了数据库建模工具，就易于在逻辑层控制应用对数据要求的一致性。

能够灵活地产生文本格式的数据库说明文档

采用数据库建模工具，可以从模型中直接产生多种格式和内容要求的文档，以满足各个方面的要求。

能够从模型中产生建库和升级的脚本

在指定了目标数据库后，数据库建模工具能够随时在逻辑模型和物理模型之间切换。对于所做的数据更改，也可以产生详细的差异清单，这对于复杂的、多变的数据库设计，是特别有帮助的。