1.3 数据库设计基础

数据库设计是针对某个具体的应用问题进行抽象，构造概念模型，设计最佳的数据结构，建立数据库及其应用系统的过程。使用较好的数据库设计过程，能迅速、高效地创建一个设计完善的数据库，为访问所需信息提供方便。在设计时打好坚实的基础，设计出结构合理的数据库，将会节省日后整理数据库所需的时间，并能更快地得到精确的结果。

1.3.1 数据库设计的规范化

关系的规范化理论是由E.F.Codd于1971年系统提出的。规范化理论为数据结构定义了规范化的关系模式，简称范式（Normal Forms,NF）。它提供了判别关系模式设计的优劣标准，为数据库设计提供了严格的理论基础。

使用范式表示关系模式满足规范化的等级，满足最低要求的为第一范式，在第一范式的基础上满足进一步要求的可升级为第二范式，其余依次类推。

1.第一范式（1NF）

设R是一个关系模式，如果R中的每个属性都是不可再分的最小数据项，则称R满足第一范式或R是第一范式，第一范式简记为1NF。

属于第一范式的关系应该满足的基本条件是每个元组的每个属性中只能包含一个数据项，不能将两个或两个以上的数据项“挤入”到一个属性中。

例1-4 教师关系如表1-6所示。判断教师关系是否为第一范式，并规范化教师关系。

教师关系不符合第一范式。因为在这个关系中，“电话号码”不是基本数据项，它由另外两个基本数据项组成。规范化教师关系，只需将所有数据项都表示为不可分的最小数据项即可。规范化后的教师关系如表1-7所示。

2.第二范式（2NF）

如果关系模式R是第一范式，且所有非主属性都完全依赖于其主关键字，则称R满足第二范式或R是第二范式，第二范式简记为2NF。

例1-5 学生选课成绩关系如表1-8所示。判断是否符合第二范式，并规范化学生选课成绩关系。

在这个关系中，学生编号和课程编号共同组成主关键字，其中成绩完全依赖于主关键字，但姓名不完全依赖于这个组合关键字，却完全依赖于学生编号。课程名称、周学时、学分完全依赖于课程编号。因此这个关系不符合第二范式。

使用上述关系模式会存在以下几个问题。

（1）数据冗余：假设有100名学生选修同一门课，就要重复100次相同学分。

（2）更新复杂：若调整某门课程的学分，相应元组（记录）的学分值都要更新，不能保证修改后的不同元组同一门课程的学分完全相同。

（3）插入异常：如果开一门新课，可能没有学生选修，没有学生编号主关键字，只能等到有学生选修才能将课程编号和学分加入表中。

（4）删除异常：如果学生已经毕业，由于学生编号不存在，选修记录也必须删除。

为了消除这种部分依赖，可以进行关系模式的分解，将上述关系分解为3个关系，带下划线的属性是关系的主关键字。

学生（学生编号，姓名，性别，年龄，入校日期，团员否，简历，照片）

选课成绩（学生编号，课程编号，成绩）

课程（课程编号，课程名称，周学时，学分）

3.第三范式（3NF）

在介绍第三范式之前，需要先介绍传递依赖的概念。

假设关系中有A、B、C 3个属性，传递依赖是指关系中B属性依赖于主关键字段A，而C属性依赖于B属性，称C属性传递依赖于A。

如果关系模式R是第二范式，且所有非主属性对任何主关键字都不存在传递依赖，则称R满足第三范式或R是第三范式，第三范式简记为3NF。

例 1-6 分析例 1-5 规范化后的3个关系，判断是否都符合第三范式，并对不符合第三范式的关系进行规范化。

在例1-5规范化后的3个关系中，学生和选课成绩关系中的所有属性与主关键字之间仅存在完全依赖关系，并不存在传递依赖关系，因此符合第三范式。但是在课程关系中，如果学分是根据学时的多少来决定的，那么学分就是通过周学时传递依赖于课程编号。

解决方法是消除其中的传递依赖，将课程关系进一步分解为两个关系。

课程（课程编号，课程名称，周学时）

学分（周学时，学分）

另一种解决方法是将不必要的属性删除。如果课程关系中，周学时属性与学分属性取值相同，只保留学分属性即可。因此也可将例1-5中的课程关系规范为

课程（课程编号，课程名称，学分）

1.3.2 数据库设计的步骤

事实上，设计数据库的主要目的是为了设计出满足实际应用需求的实际关系模型。一般情况下，设计一个数据库要经过需求分析、确定所需表、确定所需字段、确定主关键字和确定表间联系等步骤。

例1-7 根据下面介绍的教学管理基本情况，设计“教学管理”数据库。

某学校教学管理的主要工作包括教师档案及教师授课情况管理、学生档案及学生选课情况管理等几项。教学管理涉及的主要数据如表1-6和表1-8所示。由于该校对教学管理中的信息不够重视，信息管理比较混乱，使得很多信息无法得到充分、有效的应用。解决问题的方法之一是利用数据库组织、管理和使用教学信息。

1.需求分析

明确建立数据库的目的，以确定数据库中要保存哪些信息。需求分析是指从调查用户单位着手，深入了解用户单位数据流程，数据的使用情况，数据的数量、流量、流向、数据性质，并且做出分析，最终给出数据的需求说明书。

用户的需求主要包括以下3个方面。

（1）信息需求。即用户要从数据库获得的信息内容。信息需求定义了数据库应用系统应该提供的所有信息，注意清楚描述系统中数据的数据类型。

（2）处理需求。即需要对数据完成什么处理功能及处理的方式。处理需求定义了系统的数据处理的操作，应注意操作执行的场合、频率、操作对数据的影响等。

（3）安全性和完整性要求。在定义信息需求和处理需求的同时必须相应确定安全性、完整性约束。

在分析中，数据库设计者要与数据库的使用人员进行交流，了解现行工作的处理过程，共同讨论使用数据库应该解决的问题和使用数据库应该完成的任务，并以此为基础，进一步讨论应保存哪些数据以及怎样保存这些数据。另外，还应尽量收集与当前处理有关的各种表格。

根据需求分析的内容，对例1-7所描述的教学管理情况进行分析，可以确定，建立“教学管理”数据库的目的是为了解决教学信息的组织和管理问题。主要任务应包括教师信息管理、教师授课信息管理、学生信息管理和选课情况管理等。

2.确定所需表

确定数据库中的表是数据库设计过程中技巧性最强的一步。因为根据用户想从数据库中得到的结果（包括要打印的报表、要使用的窗体、要数据库回答的问题）不一定能得到如何设计表结构的线索，还需要分析对数据库系统的要求，推敲那些需要数据库回答的问题。分析的过程是对所收集到的数据进行抽象的过程。抽象是对实际事物或事件的人为处理，抽取共同的本质特性。

在教学管理业务的描述中提到了教师表和学生选课成绩表。但如果以这两个表作为“教学管理”数据库的基本表，是不合理的。如1.3.1节中所分析的，两个表都不符合数据库设计的规范化原则。因此根据已确定的“教学管理”数据库应完成的任务以及规范化理论，应将“教学管理”的数据分为5类，并分别存放在教师、学生、课程、选课成绩和授课5个表中。

3.确定所需字段

确定每个表中要保存哪些字段。通过对这些字段的显示或计算应能够得到所有需求信息。确定的字段应使关系（表）满足第三范式。

根据前面的分析，按照规范化理论，可将“教学管理”数据库中5个表的字段确定下来，如表1-9所示。

确定5个表及每个表所包含的字段的思路及过程可参见1.3.1节。

4.确定关键字

关系型数据库管理系统能够迅速查找存储在多个独立表中的数据并组合这些信息。为使其有效地工作，数据库的每个表都必须有一个或一组字段可用以唯一确定存储在表中的每条记录，即主关键字。

例如，“教学管理”数据库的5个表中，教师表、学生表、课程表和选课成绩表都设计了主关键字。教师表中的主关键字是“教师编号”，学生表中的主关键字为“学生编号”，课程表中的主关键字为“课程编号”，选课成绩表中的主关键字为“学生编号”和“课程编号”的组合。为了使表结构清晰，也可以为授课表设计主关键字“授课 ID”。确定主关键字后的“教学管理”数据库表结构如表1-10所示。

5.确定表间关系

确定表间关系的目的是使表的结构合理，不仅存储了所需要的实体信息，并且反映出实体之间客观存在的关系。表与表之间的关系需要通过一个共同字段来建立，因此确保两个表之间能够建立起关系，应将其中一个表的主关键字添加到另一个表中。

例如，授课表中有“课程编号”和“教师编号”，而“教师编号”是教师表中的主关键字，“课程编号”是课程表中的主关键字。这样，教师表与授课表、课程表与授课表就可以建立起关系。

图 1-9 所示为“教学管理”数据库中5个表之间的关系。如何定义表之间的关系，将在后续章节中详细介绍。

通过前面各个步骤确定了所需要的表、字段和联系，经过反复修改之后，就可以开发数据库应用系统的原型了。