Oracle开发使用手册(二).pdf

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