在使用普通文件的计算机应用系统中，数据库是从属于程序的，数据文件的设计通常是应用程序设计的一部分。在数据库系统应用中，数据由DBMS进行独立地管理，对程序的依赖性大为减少。而数据库的设计也逐渐形成为一项独立的开发活动。
1.2.1  数据库设计过程
一般来说，数据库的设计都要经历需求分析、概念设计、实现设计和物理设计四个阶段，图1-7所示为各设计过程和每一过程应生成的文档。
下面介绍各个模块的功能。
需求分析  需求分析是整个设计过程的基础，是最困难、最耗费时间的一步。它的目的是分析系统的需求。该过程的主要任务是从数据库的所有用户那里收集对数据的需求和对数据处理的要求，并把这些需求写成用户和设计人员都能接受的说明书。
概念设计  概念设计是整个数据库设计的关键。它的目的是将需求说明书中关于数据的需求，综合为一个统一的DBMS概念模型。首先根据单个应用的需求，画出能反映每一应用需求的局部E-R模型。然后将这些E-R模型图合并起来，消除冗余和可能存在的矛盾，得出系统总体的E-R模型。
实现设计  它的目的是将E-R模型转换为某一特定的DBMS能够接受的逻辑模式。对关系数据库，主要是完成表的关联和结构的设计。
物理设计  它的目的在于确定数据库的存储结构。其主要任务包括：确定数据库文件和索引文件的记录格式和物理结构，选择存取方法，决定访问路径和外存储器的分配策略等。不过这些工作大部分可由DBMS来完成，仅有一小部分工作由设计人员完成。例如，物理设计应确定列类型和数据库文件的长度。实际上，由于借助DBMS，这部分工作难度比实现设计要容易得多。
对于一个程序员，需要了解最多的应该是实现设计阶段。因为数据库不管设计的好坏，都可以存储数据，但是在存储的效率上可能有很大的差别。可以说，实现设计阶段是关系数据库存取效率的重要阶段。

图1-7 数据库设计过程和产生的文档

1.2.2  关系数据库规范化
在实现设计阶段，常常使用关系规范化理论来指导关系数据库设计。其基本思想为，每个关系都应该满足一定的规范，从而使关系模式设计合理，达到减少冗余，提高查询效率的目的。
为了建立冗余较小、结构合理的数据库，将关系数据库中关系应满足的规范划分为若干等级，每一级称为一个“范式”。
范式的概念最早是由E.F.Codd提出的，他从1971年相继提出了三级规范化形式，即满足最低要求的第一范式（1NF），在1NF基础上又满足某些特性的第二范式（2NF），在2NF基础上再满足一些要求的第三范式（3NF）。1974年，E.F.Codd和Boyce共同提出了一个新的范式概念，即Boyce-Codd范式，简称BC范式。1976年Fagin提出了第四范式（4NF），后来又有人定义了第五范式（5NF）。至此，在关系数据库规范中建立了一个范式系列：1NF、2NF、3NF、BCNF、4NF和5NF。这6种范式一级比一级有更严格的要求，它们之间的联系如图1-8所示。

图1-8 各种范式之间的关系

1．第一范式（1NF）
在任何一个关系数据库中，第一范式是对关系模型的基本要求，不满足第一范式的数据库就不是关系数据库。
所谓第一范式是指数据库表的每一列都是不可再分割的基本数据项，同一列不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式中表的每一行只包含一个实例的信息。例如，对于图1-9中的客户信息，不能将客户信息都放在一列中显示，也不能将其中的两列或多列放在一列中显示；客户信息的每一行只表示一个客户的信息，一个客户的信息在表中只出现一次。简而言之，第一范式就是无重复的列。

图1-9 “客户信息”中的数据

2．第二范式（2NF）
第二范式是在第一范式的基础上建立起来的，即满足第二范式必须先满足第一范式。第二范式要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分，通常需要为表加上一个列，以存储各个实例的唯一标识。如图1-9中，客户信息中加上了列“客户编号”，因为每个客户编号是唯一的，因此每个客户可以被唯一区分。这个唯一属性列被称为主关键字或主键。
第二范式要求实体的属性完全依赖于主关键字。所谓“完全依赖”是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。简而言之，第二范式就是非主属性非部分依赖于主关键字。
3．第三范式（3NF）
满足第三范式必须先满足第二范式。也就是说，第三范式要求一个数据库表中不包含已在其他表中包含的非主关键字信息。例如，存在一个业务员信息，其中每个业务员有业务员编号、业务员姓名、家庭住址、电话等信息。那么在图1-9的客户信息中列出业务员编号后就不能再将业务员姓名、家庭住址、电话等与业务员有关的信息加入客户信息中。如果不存在业务员信息，则根据第三范式也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其他非主属性。

回书目   上一节   下一节