对一个数据库管理员来说，所能为他的数据库做的***的事情就是使之开始于一个合理的逻辑设计。不幸的很，数据库设计常常被匆匆地完成以致于做错，甚至在数据库建立后重新返工。一个见闻广博的和聪明的数据库管理员知道对数据库进行很好的设计，会大大提高数据库的性能，而不是减损数据库的性能，这种思想与流行的思想相反。事实上，直接投入物理设计或更深层的工作，只会带来麻烦，不仅在性能方面，而且在数据完整性方面同样如此。
如果一个数据库运行得很快，但收藏的数据却是错误的，这又有什么好处呢？而且，在数据库系统的早期设计阶段，创建一个合理的逻辑设计，可以让它接受以后创建和维护阶段物理设计改变的考验。可是，如果你在逻辑设计阶段走捷径，你将不但可能需要重新设计逻辑模型，而且还可能需要重新构造下面的物理模型。间接的代价（职员的工作时间、停工期等等）可能会是令人吃惊的。在进行和建立数据库之前，需要了解逻辑数据库设计和标准化背后的基本原则。
在70年代中期，关系数据库模型逐渐超越其他的数据模型占据主导地位，Oracle关系模型技术的风靡使设计性能得到规范化。这其中***的是实体关系图（Entity-RelationshipDiagram，ERD），它是P.P.Chen在1976年提出来的。这就是语义数据模型，因它试图捕获业务要素（业务本质）的语义或正确含义。因为关系模型本身几乎就是一个依据语法的模型，是一种主要处理结构的模型，实体关系图（ERD）通常用于补充它。实际上，ERD建模必然先于关系建模。当一个ERD结束时，它或多或少地被直接映射到关系模型上，而后关系模型再被映射到它的物理模型上。
一个实体是一个业务元素，比如一个雇员或一个项目。一个关系就是两个实体之间的联系，比如工作于不同项目的雇员。属性即组成实体的特征，比如一个雇员的工资或项目的预算。属性被认为是来自定义域中的取值或值的集合，它们所取的值是它们以后在关系模型中所用到的数据。它们是对一个事物全部抽取或部分抽取。ERD有许多画法，只要你选择一种并在整个使用过程中保持含义一致即可。
使用方框代表实体画高级图（那些不带属性的），将实体的名字列于方框的中心。低级图的实体名称列于方框中的上部，后面跟着属性名称。
在方框之间画有箭头，代表关系类型，有三种基本类型的关系：一对一、一对多以及多对多。一对一的关系根据一对一关系的类型，在线条的一端或两端使用单箭头。一对多使用双箭头，多对多在两边使用双箭头。当一个实体的每一个值都和另一个实体的一个值并且只有一个值有关时，就存在着一个纯粹的一对一关系，反之亦然。这种类型的关系是很少见。
一种更为普遍的一对一关系是子类型关系，这是面向对象分析和设计的基础之一。在面向对象系统中，这被看作是类和子类（或者更简单地说，类的级别）。换句话说，在更为普遍的实体中的属性（长方形）上，将属性（如长和宽）送给更为特定的实体（正方形）。因此，继承的方向是从一般到特殊。子类型关系比纯类型的一对一关系更为常见，但这两种都不常用。通常，当一个设计者偶然遇到一对一关系时，他必须问下列问题：
■这两个实体能结合吗？
■它们对于自己的目标是否是完全相同的？
■它们是否由于某些业务原因必须保持独立和不同吗？
通常情况下，一对一实体是可以合并的。在Oracle关系模型中，使用得最多的关系是一对多关系。在这种情况下，作为一名设计者，你所能为自己做的***的事情就是把自己从所有的多对多关系中解脱出来；并不是真正地除去它们，但你可以在它们原先位置上使用两个或多个一对多关系来代替多对多关系。之所以要这样做，是因为关系模型并不能实际处理一个多对多关系的直接实现。仔细想想，如果有许多从事多个项目的雇员，你怎样来贮存外键？你不能在一列中贮存多个值，这样违反了数据必须是原子的关系型要求，这意味着没有一个单元能够持有一条以上的信息。信息法则也说明：它是***范式（FirstNormalForm）的一个特殊情况。因此，为确保数据的原子性，每条多对多关系都被两个或者多个一对多关系所取代。
你所要作的工作就是分割多对多关系。在关系模型中，被称为职位的新实体通常被叫做交叉表，因为它代表着与其相关的两个表中每一对实际值的交集，有时也称为叫纽带表（ junction table）或连接表（ join table），交叉表是这样的一个实体：它不一定总是一些业务元素的真实抽象，但是它是解决和实现Oracle关系模型中多对多关系的基本方法。
【编辑推荐】
