使用ERWin设计数据库.docVIP

　　使用ERWin设计数据库教育资源库 　　结合自己多年的实践经验，系统阐述了利用ERodeler是CA公司的数据库建模工具，目前在关系数据库的设计中，有着比较广泛的应用。笔者经过多年的实践，感觉使用ERain 　　Domain 的概念有点像是属性的数据类型，笔者的体会是，如果不打算使用Domain，则不要增加任何Domain，都用ERain，则应该对于每一类数据等同的属性建立一个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. 谨慎使用参照完整性 　　在关系数据库中，提供了参照完整性的概念，利用好参照完整性，可以保持应用数据的高度一致性，但一定要谨慎使用。一般来说，实现参照完整性有三种方法，第一种是使用数据库的触发器; 第二种是使用数据库的外键; 第三种是使用应用逻辑。 　　对 于使用数据库的触发器，这种方法有着最大的灵活性。触发器是由数据库的引擎控制的，只要数据库的引擎不出问题，那么触发器就总是有效的，除非人工关闭触发 器，否则数据的一致性可以得到最大的保证。但是这样也会引入 12下一页 这篇文章来自..，。两个问题: 对于数据的修改没有痕迹，如果是误操作，那后果是不堪设想的; 对于一些联机交易系统，所有的交易必须快速响应，如果采用这样的触发器，系统的响应时间就会变得太长。 　　对于使用数据库的外键，这种方法相当于设置了一个子表，对于父表不存在的内容，子表不能插入，也不能修改，但是对父表却没有约束。这种方法，在起作用范围内，效率还是比较高的。 　　对 于系统环境不允许使用触发器的情况，或者对于错误定位要求比较明确以致超出外键能够报告的详细程度的情况，就要使用应用逻辑了。使用应用逻辑实际上可能效 率会低于外键，而且由于数据库本身已经没有了控制机制，所以对于应用逻辑的错误或者绕开了应用逻辑的情况，是没有办法保证数据一致性的。 　　处理数据库的物理模型 　　实际上，在建立数据库逻辑模型的过程中，物理模型就也已经建立了。但是，在处理数据库的物理模型时，仍旧有一些方面要给与特殊的关注。 　　1. 要特别关注逻辑模型到物理模型的映射关系 　　IDEF1X的实体名对应数据库的表名，属性名对应字段名，关系名对应约束名，外键名对应索引名。这些似乎全部是自动完成