1.3 关系数据库设计

一个信息系统的各部分能否紧密地结合在一起以及如何结合，关键在数据库。因此，对数据库进行合理的逻辑设计和有效的物理设计才能开发出完善而高效的信息系统。数据库设计是信息系统开发和信息建设的重要组成部分。

1.3.1 数据库设计的任务、内容与步骤

1.数据库设计的任务

数据库设计的任务是针对一个给定的应用环境，创建一个良好的数据库模式，建立数据库及其应用系统，使之能有效的收集、存储、操作和管理数据，满足用户的各种需求。

2.数据库设计的内容

数据库设计是在一个通用的DBMS支持下进行的，即利用现成的DBMS作为开发的基础。数据库设计的内容主要包括结构特性设计和行为特性的设计两个方面的内容。结构特性的设计是指确定数据库的数据模型，数据模型反映了现实世界的数据及数据之间的联系，在满足要求的前提下，尽可能的减少冗余，实现数据的共享。行为特性的设计是指确定数据库应用的行为和动作，应用的行为体现在应用程序中，行为特性的设计主要是应用程序的设计。因为在数据库工程中，数据库模型是一个相对稳定的并为所有用户共享的数据基础，所以数据库设计重点是结构特性设计，但必须与行为特性设计相结合。

3.数据库设计的步骤

人们不断的研究探索，提出了各种数据库的规范设计方法，其中比较有名的是新奥尔良法（New Orleans），按照规范设计方法，考虑数据库及其应用系统开发的全过程，将数据库的设计分为如下六个阶段：需求分析阶段，概念设计阶段，逻辑设计阶段，物理设计阶段，实施阶段，运行和维护阶段。各阶段也不是严格线性的，而是采取“反复探寻、逐步求精”的方法，如图1.9所示。

1.3.2 需求分析

需求分析就是分析用户的需求。需求分析是设计数据库的起点，需求分析的结构将影响到各个阶段的设计，以及最后结果的合理性与实用性。

1.需求分析的任务

需求分析的任务是通过详细调查现实世界中要处理的对象（组织、部门、企业）等，在了解现行系统工作情况，确定新系统功能的过程中，收集支持系统运行的基础数据及其处理方法，明确用户的各种需求。

调查的重点是“数据”和“处理”，通过调查、收集与分析，获得用户对数据库的如下需求：

（1）信息需求。指用户要从应用系统中获得信息的内容与性质。即未来系统中要输入的信息，从数据库中要获得什么信息等。由信息的要求就可以导出数据的要求，即在数据库中存储什么数据。

（2）处理要求。指用户要完成什么样的处理，对处理的响应时间有什么要求，是什么样的处理方式。

（3）安全性与完整性要求。

确定用户的需求是非常困难的，因为用户往往对计算机应用不太了解，难以准确表达自己的需求。另一方面，计算机专业人员又缺乏用户的专业知识，存在与用户准确沟通的障碍。只有通过不断与用户深入地交流，才能准确地确定用户的真正需求。

2.需求分析基本步骤

需求分析一般要进行如下几步：

（1）需求的收集：收集数据及其发生时间、频率，数据的约束条件、相互联系等。

（2）需求的分析整理。

① 数据流程分析，结果描述产生数据流图。

② 数据分析统计，对输入、存储、输出的数据分别进行统计。

③ 分析数据的各种处理功能，产生系统功能结构图。

3.阶段成果

需求分析阶段成果是系统需求说明书，此说明书主要包括数据流图、数据字典、各类数据的统计表格、系统功能结构图和必要的说明。系统需求说明书将作为数据库设计的全过程依据的文件。

1.3.3 概念结构设计

如前所述，表达概念设计结果的工具成为概念模型。将需求分析得到的用户需求抽象为信息世界的概念模型的过程就是概念结构设计。它是整个数据库设计的关键。概念设计不依赖于具体的计算机系统和DBMS。

1.概念设计的策略和步骤

（1）设计概念结构的策略有如下几种：

① 自顶向下：首先定义全局概念结构的框架，再做局部细化。

② 自底向上：先定义每一局部应用的概念结构，然后按一定的规则把他们集成，进而得到全局的概念结构。

③ 由里向外：首先定义核心结构，然后再扩展。

④ 混合策略：就是将自顶向下和自底向上结合起来，先用前一种方法确定框架，再用自底向上设计局部概念，然后再结合起来。

（2）常用自底向上策略的设计步骤。

① 进行局部抽象，设计局部概念。

② 将局部概念模式综合成全局概念模式

③ 进行评审，改造。

2.采用E-R方法的数据库概念设计步骤

采用E-R方法的数据库概念设计步骤分三步：

（1）设计局部E-R模型，局部E-R图的设计步骤如图1.10所示。在设计E-R模型的过程中应遵循这样一个原则：现实世界中的事物能作为属性对待的，尽量作为属性对待。什么样的事物可以作为属性对待？下列两类：

• 作为属性，不能是再具有需要描述的性质。

• 属性不能与其他实体具有联系。

（2）设计全局E-R模型。将所有局部的E-R图集成为全局的E-R概念模型，一般采用两两集成的方法，即先将具有相同实体的E-R图，以该相同的实体为基准进行集成，如果还有相同的实体，就再次集成，这样一直继续下去，直到所有具有相同实体的局部E-R图都被集成，从而得到全局的E-R图。在集成的过程中，要消除属性、结构、命名三类冲突，实现合理的集成。

（3）全局E-R模型的优化。一个好的全局的E-R模型能反映用户功能需求外，还应做到实体个数尽可能少，实体类型所含属性尽可能少，实体类型间的联系无冗余。全局E-R模型的优化就是要达到这三个目的。

采用以下集中方法。

① 合并相关的实体类型：把1∶1联系的两个实体类型合并，合并具有相同键的实体类型。

② 消除冗余属性与联系：消除冗余主要采用分析法，并不是所有的冗余必须消除，有时为了提高效率，可以保留部分冗余。

1.3.4 逻辑结构设计

概念结构是独立于任何数据模型的信息结构。逻辑结构设计的任务就是将概念模型转化成特定的DBMS系统所支持的数据库的逻辑结构（数据库的模式和外模式）。

1.逻辑结构设计的步骤

由于现在设计的数据库应用系统都普遍采用支持关系模型的RDBMS，所以这里仅介绍关系数据库逻辑结构的设计。关系数据库逻辑结构设计时一般分三步：

① 将概念结构向一般的关系模型转换。

② 将转换来的关系模型向特定的RDBMS支持的数据模型转换。

③ 对数据模型进行优化。

2.E-R模型向关系数据库的转换规则

如何将E-R模型的实体和实体间的联系转换成关系模式，如何确定这些关系模式的属性和码，这些问题是通过E-R模型向关系模式转换的规则来解决的。E-R模型向关系数据库的转换规则是：

（1）一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。

（2）一个1∶1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则相连的每个实体的码及该联系的属性是该关系模式的属性，每个实体的码均是该关系模式的候选码。

（3）一个1∶n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式。与该联系相连的各实体的码及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。

（4）一个m∶n联系转换为一个关系模式。与该联系相连的各个实体的码及联系本身的属性转换为关系的属性，而该关系的码为各实体的码的组合。

（5）三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码及联系本身的属性转换为关系的属性，而该关系的码为各实体码的组合。

（6）具有相同码的关系模式可以合并。

3.关系数据库的逻辑设计

关系数据库逻辑设计的过程如下：

（1）导出初始的关系模式：将E-R模型按规则转换成关系模式。

（2）规范化处理：消除异常，改善完整性、一致性和存储效率。

（3）模式评价：检查数据库模式是否能满足用户的要求，它包括功能评价和性能评价。

（4）优化模式：采用增加、合并、分解关系的方法优化数据模型的结构，提高系统性能。

（5）形成逻辑设计说明书。

1.3.5 数据库设计案例

本节以某高校学分制选课系统的数据库设计为例，重点介绍数据库设计中的概念设计与逻辑设计部分。为了便于学生理解和授课，对学生选课系统做了一定的简化和假设，并忽略了一些异常情况。

某高校学生选课系统要求：学生根据开课清单选课，系统根据教学计划检查应修的必修课并自动选择；检查是否存在未取得学分的必修课，如果存在，则要求重选；学生按选修课选课规则选学选修课（例如4组选修课中选3门）；学生可以查询各门课程的成绩、学分及平均学分绩；输出学生的个人课表，输出学生的选课交费清单。

1.学生选课管理部分数据流图（如图1.11和图1.12所示）

2.学生选课管理系统的E-R图

（1）设计局部E-R模型。

以学生选课系统数据流图为依据，设计局部E-R模型的步骤如下：

① 确定实体类型。学生选课系统实体类型有：学生、教学计划、课程、教师。

② 确定联系类型。

学生与教学计划之间是m∶1联系，即一个专业一年级只对应一个教学计划，而一个专业同一个年级有多名学生，定义联系为“学生—教学计划”。

教学计划和课程之间是n∶m联系，即一个专业一个年级的教学计划可以包含多门课程，而同一门课程被多个专业所选择，定义联系为“教学计划—课程”。

学生与课程之间是m∶n联系，即一个学生可以选多门课程，一门课程可以被多个学生选学，定义联系为“学生—课程”。

教师与课程之间是m∶n联系，即一名教师可以讲授多门课程，一门课程也可以由多名教师讲授，定义联系为“教师—课程”。

学生与教师之间是m∶n联系，即一名教师可教多个学生，一个学生可以由多个教师教，定义联系为“学生—教师”。

学生选学了课程，也就选择了教师，学生与教师的联系是通过授课联系起来的。

③ 确定实体类型的属性。

实体类型“教学计划”有属性：专业，专业学级，课程，开课学期，周学时数，学分，启始周，结束周。

实体类型“课程”有属性：课程号，课程名，学时数，学分。

实体类型“学生”有属性：学号，姓名，性别，出生日期，系，专业，班级，入学时间。

实体类型“教师”有属性：教师编号，姓名，性别，出生日期，学历，职称，职务，专业。

④ 确定联系类型的属性。

“学生—教学计划”联系，由于学生只是根据教学计划的要求来进行课程的选择，所以此联系没有属性。

“教学计划—课程”联系，由教学计划来决定每一学期的课程，所以教学计划包含课程，所以“教学计划—课程”联系的属性，可以归结到教学计划实体类型的属性中，即将“教学计划”实体类型的属性课程，改为课程号即可。

“学生—课程”联系，学生在每一学期都要进行课程的选择，已得到该学期的学分和交费，所以此联系的属性有：学号（实体类型学生的码），课程号（实体类型课程的码），学年，学期，成绩，学分（所得学分），交费。

“教师—课程”联系，教师教课实际是在教学生，此联系必须能够向教师提供学生的一些情况，所以联系的属性有：课程号，教师编号，专业，专业学级，学年，学期，学时数，开始周，结束周。

“学生—教师”联系，学生和老师之间的联系实际上是通过课程建立起来的，所以它们之间的联系属性只是实体类型码之间的联系，即学号和教师编号，可以省略。

⑤ 根据实体类型和联系类型画出E-R图。

在设计E-R模型的过程中应遵循这样一个原则：现实世界中的事物能作为属性对待的，尽量作为属性对待。

（2）设计全局E-R模型。将所有局部的E-R图集成为全局的E-R概念模型，如图1.14所示，全局E-R图中省略了班级、系部等部分实体和部分属性。在集成的过程中，要消除属性、结构、命名三类冲突，实现合理的集成。

（3）全局E-R模型的优化。分析图1.14全局E-R模型，看一看能否反映用户功能需求，尽量做到实体的个数尽可能的少，实体类型所含属性尽可能的少，实体类型间的联系无冗余。

3.学生选课管理关系模式

（1）将学生选课管理系统的E-R模型按规则转换成如下关系模式：

系部（系部代码，系部名称，系主任）

专业（专业代码，专业名称，系部代码）

班级（班级代码，班级名称，专业代码，系部代码，备注）

课程（课程号，课程名，备注）

学生（学号，姓名，性别，出生日期，入学时间，班级代码，专业代码，系部代码）

教师（教师编号，姓名，性别，出生日期，学历，职务，职称，系部代码）

学生—课程—教师（学号，课程号，教师编号，成绩，学分）

（2）模式评价与优化。检查数据库模式是否能满足用户的要求，根据功能需求，增加关系、属性并规范化，得到如下关系模式：

系部（系部代码，系部名称，系主任）

专业（专业代码，专业名称，系部代码）

班级（班级代码，班级名称，专业代码，系部代码）

教师（教师编号，姓名，性别，出生日期，学历，职务，职称，系部代码，专业）

学生（学号，姓名，性别，出生日期，入学时间，班级代码）

课程（课程号，课程名称，备注）

教学计划（课程号，专业代码，专业学级，课程类型，开课学期，学分，启始周，结束周）

教师任课（教师编号，课程号，专业学级，专业代码，学年，学期，学生数，学时数，酬金，开始周，结束周）

课程注册（学号，教师编号，课程号，专业学级，专业代码，选课类型，学期，学年，收费否，注册，成绩，学分）

管理员（用户名，密码，备注）

收费表（学号，课程号，收费，学年，学期）

系统代码表（ID，代码类别，编号，代码名称）

4.系统物理结构设计

以具体的RDDMS（如SQL Server 2008）为环境，根据逻辑设计产生的关系模式设计学生、教师、课程、班级、专业、系部、课程注册和收费表的表结构。

5.数据库实施与维护

在RDDMS（如SQL Server 2008）环境中，创建数据库和数据表，组织数据入库；根据需要创建表、视图及其他数据对象。最后，在使用过程中对数据库进行维护。