要看到的外部视图。概
念层是中介层，它使得用户不必与内层打交道。 3、外层
外层直接与用户（最终用户或应用程序）交互。它将来自概念层的数据转化为用户所熟 悉的格式和视图。 四、数据库模型
数据库模型定义数据的逻辑设计。它也描述数据的不同部分之间的关系。在数据库设计
史上，使用过3种数据库模型：层次模型、网络模型和关系模型。 1、层次数据库模型
在层次模型中，数据被组织成一棵倒置的树。每个实体只有一个父，但可有数个子。在
分层结构的顶部，有一个实体，称为根。图6A-2给出了一个层次模型例子的逻辑视图。层次 模型现在已经过时。 2、网络数据库模型
在网络模型中，实体以图的形式来组织，图中的有些实体可通过多条路径访问（图6A-3）。
网络模型没有分层结构。这种模型现在也已经过时。 3、关系数据库模型
在关系模型中，数据被组织成称为关系的二维表。关系模型没有分层
46
或网络结构强加于
数据。然而，表或关系是相互关联的（图6A-4）。关系数据库管理系统组织数据，使其外部
视图呈现为关系或表的集合。这并不意味着数据以表的形式存储：数据的物理存储与数据的
逻辑组织方式毫无关系。图6A-5给出了一个关系的例子。关系数据库管理系统中的关系具有 以下特征：
● 名称。关系数据库中的每个关系都应具有一个名称，而这个名称在所有关系中是独一 无二的。
● 属性。关系中的每一列都称为一个属性。在图6A-5的表中，属性是列的标题。每个
属性赋予存储在其下面的数据以意义。表中的每一列都必须具有一个在关系的范围内
独一无二的名称。一个关系的属性总数称为该关系的度。例如，在图6A-5中，关系
的度为3。注意属性名并不存储在数据库中：概念层使用属性给每一列赋予一定的意 义。
● 元组。关系中的每一行称为一个元组。元组定义一组属性值。一个关系中的总行数称
47
为该关系的基数。注意一个关系的基数随着元组的增加或删除而改变。这使数据库具 有了动态性。
关系模型是今天使用的常见模型之一。源自关系模型的另外两种常见模型是分布式模型 和面向对象模型。 4、分布式数据库模型
分布式数据库模型并非一种新模型，而是基于关系模型的。但是，数据存储在通过因特
网或专用广域网通信的数台计算机上。每台计算机（或站点）保持数据库的一部分或整个数
据库。换句话说，数据或者是分段存储的——每个站点存储一段，或者被每个站点复制一份。
在分段型分布式数据库中，数据是本地化的，本地使用的数据存储在相应的站点上。然
而，这并不意味着一个站点不能访问存储在另一个站点上的数据，但访问大多是本地性的，
偶尔是全局性的。虽然每个站点对其本地数据具有完全的控制，但也存在通过因特网或广域 网的全局控制。
例如，一家制药公司可能在许多国家拥有多个站点。每个站点有一个数据库，存储着自
48
己雇员的信息。但是，中心人事部门可以控制所有的数据库。 在复制型分布式数据库中，每个站点都有其他站点的一个完全副本。对一个站点所存储
的数据进行的任何修改，都要在其他每个站点上精确地重复进行。拥有这种数据库是为了安
全。如果一个站点上的系统发生故障，该站点的用户可以访问另一个站点上的数据。 5、面向对象数据库模型
关系数据库具有一个特定的数据视图，该视图基于数据库元组与属性的性质。关系数据
库中最小的数据单位是一个元组与一个属性的交集。然而，有些应用程序需要将数据视为其
他形式，如看作一种结构，像由字段构成的记录。
面向对象数据库试图保留关系模型的优点，同时允许应用程序访问结构化数据。在面向
对象数据库中，对象及其之间的关系得到定义。此外，每个对象可以具有可表示为字段的属 性。
例如，在一个机构中，可以为雇员、部门和客户定义对象类型。雇员类可以定义一个雇
员对象的属性（名、姓、社会保险号码、薪水等等），以及可以如何访问它们。部门对象可
49
以定义部门的属性，以及可以如何访问它们。此外，数据库还可以在一个雇员对象与一个部
门对象之间创建一种关系，以表示该雇员在该部门工作。 五、数据库设计
任何数据库的设计都是一项冗长、复杂的任务，只能通过一个逐步的过程来完成。第一
步通常涉及对数据库潜在用户的大量访谈，以收集需要存储的信息和每个部门的访问需求。
第二步是建立一个实体关系模型，该模型定义必须为之保存一些信息的实体、这些实体的属 性以及这些实体之间的关系。
设计的下一步基于所要使用的数据库的类型。在关系数据库中，下一步是建立基于实体
关系模型的关系，并规范化这些关系。规范化是一个过程，通过该过程一组特定的关系转化
成一组具有更坚固结构的新关系。为了达到以下目的，需要规范化：允许数据库中的任何关
系得到表示，允许像SQL（结构化查询语言）这样的语言使用由原子操作组成的功能强大的
检索操作，消除插入、删除和更新操作中的异常，以及减少添加新的数据类型时重构数据库 的必要性。
50