6.4 数据库设计

 

6.4  数据库设计

数据库设计是数据库应用的核心，数据库设计的好坏直接影响着整个数据库系统的效率和质量。本节内容主要介绍数据库设计及其开发各阶段的工作内容。

6.4.1  数据库设计概述

数据库设计是数据库应用系统设计和开发的核心问题，从数据库理论的角度看，数据库设计就是根据用户需求和数据库的支持环境（包括硬件、操作系统、DBMS），将现实世界的数据特征抽象为概念数据模型表示，最后构造出最优的数据库模式，使之既能正确地反映现实世界的信息及联系，又能满足用户各种应用需求的过程。

定义中的用户需求一般包含信息需求和处理需求。信息需求指用户对象的数据及其结构，它反映了数据库的静态要求；处理需求指用户对象的行为和动作，它反映了数据库的动态要求。在数据库设计中有两种方法：一种是以信息需求为主，兼顾处理需求，称为面向数据的方法；另一种是以处理需求为主，兼顾信息需求，称为面向过程的方法。这两种方法目前都有使用，但面向数据的方法已成为主流方法。

通常按软件工程生命周期的概念，将数据库应用系统从开始规划、分析、设计、实现、运行及维护直到被新的系统取代而停止使用的整个期间称为数据库系统的的生存期，又将生存期划分为4个时期或7个阶段：数据库规划时期、数据库设计时期（需求分析阶段、概念设计阶段、逻辑设计阶段、物理设计阶段）、数据库实施时期、数据库运行和维护时期，如图6-8所示。其中数据库设计时期分为4个阶段，并且重点以数据结构与模型的设计为主线。

在实际工作中，数据库设计不可能一蹴而就，往往具有“反复性”。前阶段的设计是后阶段设计的基础，后阶段设计也会对前阶段设计提出新的要求，前后阶段反复修改。并且在设计过程中，还要注意面向数据，将数据库的设计和对数据库中数据处理的设计紧密结合，相互参照，逐步完善。

6.4.2  数据库设计的需求分析

需求分析是数据库设计的起点，其任务是通过详细调查用户的现行系统（手工系统或计算机系统）的工作情况，明确用户的各种需求，然后在此基础上确定新系统的功能，按一定规范要求写出设计者和用户都能理解的文档——需求说明书。

图6-8  数据库系统的生存期

需求分析的重点是“数据”和“处理”，通过调研和分析，应获得用户对数据库的基本要求：一、信息需求，指用户需要从数据库中获得信息的内容和性质，由此导出数据要求，即在数据库中所需存储的数据；二、处理需求，指出用户要求系统完成的处理功能，处理时间以及处理方式；三、安全与完整性的要求。

需求分析的结果是否能准确地反映用户的实际需求，不仅对以后各个阶段的设计有直接影响，而且对数据库模式、数据库的好坏都有直接影响。而数据库设计人员要确定全部的用户需求是一件非常困难的事情，所以设计人员必须不断地与用户交流，达成共识，以便逐步确定用户的实际需求，然后分析和表达这些需求。

分析和表达用户的需求，通常采用结构化分析方法（Structured Analysis，SA）。结构化分析方法用自顶向下、逐层分解的方式分析系统，并用数据流图和数据字典从图形和文字两方面对系统需求进行完整的描述。

数据流图（Data Flow Diagram，DFD）使用直观的图形符号来描述系统中的业务过程、信息流和数据要求，表达了数据和处理的关系。图6-9表示了数据流图中使用的符号。

图6-9  数据流图的符号表示

数据字典（Data Dictionary，DD）则是系统中各类数据定义和描述的集合，是用户需求分析所获得的主要结果，是概念结构设计的必要输入。它通常由5个部分组成：数据项，即数据的最小单位，如学生的学号、姓名等等都是数据项；数据结构，即若干数据项组成的有意义的集合，反映了数据之间的组合关系；数据流，可以是数据项，也可以是数据结构，表示某一处理过程的输入或输出；数据存储，即处理过程需要保存的数据集合，可以是手工凭证、手工文档或计算机文件；处理过程，即数据库应用程序模块。可见，数据字典是关于数据库中数据的描述，是“元数据”而不是数据本身。它在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善，一般以二维表的关系结构存储在计算机中，并可用一个数据字典软件来管理。

6.4.3  数据库的概念设计

将需求分析阶段得到的用户需求抽象为概念模型表示的过程就是概念设计。概念设计的目的是分析数据字典中数据间内在语义关联，并在此基础上建立一个数据的抽象模型。目前，在数据库概念设计中常用E-R模型来描述概念结构，因此数据库概念设计又称为E-R模式设计。而将用户需求抽象表示为E-R模式的基本方法有两种：

（1）集中式模式设计法。这是一种统一的E-R模式设计方法，它根据用户需求由一个统一的机构或人员设计一个数据库的全局E-R模式。这种方法设计简单方便，保证E-R模式的统一性、一致性，适用于小型或并不复杂的数据库设计问题，而对大型的或语义关联复杂的数据库设计则不适合。

（2）视图集成设计法。这种方法首先将一个数据库系统根据某种原则分解成若干个子系统，并对每个子系统作局部E-R模式设计，然后将各个局部视图进行集成。由于局部视图设计的分散性，在集成过程中可能出现一些不一致或冲突，所以需对视图进行修正，消除冲突，最终形成全局E-R模式。视图集成法是一种由分散到集成的方法，适用于大型与复杂的数据库设计问题。虽然该方法比较复杂但能较好地反映用户需求，在实际应用中使用得比较多。

使用E-R模型与视图集成法进行设计时，需按以下步骤进行：

（1）首先选择局部应用。根据具体情况，在分层的数据流图中选择一个适当层次的数据流图，让该层中每一部分对应一个局部应用，以这一层的数据流图为出发点进行设计。

（2）进行局部E-R模式设计。局部E-R模式设计一般有三种设计方法：

① 自顶向下。即先从抽象级别高且普遍性强的实体集开始逐步细化、具体化与特殊化，如课程这个实体集，可先从一般抽象的课程开始，然后分成基础课程、专业课程、实践课程等，再进一步将基础课程等分别细化为课程名称、是否必修课、学分、学时等属性细节。

② 由底向上。即先从具体的实体开始，逐步抽象化、普遍化与一般化，最后形成一个较高层次的抽象实体集。该设计过程与自顶向下的设计过程相反。

③ 由内向外。即先从最基本与最明显的实体集着手逐步扩展至非基本、不明显的其他实体集。如可以从最基本的课程实体集开始逐步扩展至与课程相关的学院、学院的教师、选课的学生等。

在实际应用中，设计者往往根据情况，单用一种方法或者混合使用三种方法。

（3）合并局部E-R模式。当各个局部E-R视图设计完成后，就要将其集成为一个全局的E-R模式。而在集成过程中由于每个局部视图在设计时的不一致性，会引起下列几种常见冲突。

① 命名冲突。主要指同名异义和同义异名两种。同名异义指不同意义的对象具有相同的名字；同义异名指同一意义的对象具有不同的名字。

② 概念冲突。同一概念在一处为实体而在另一处为属性或联系。

③ 域冲突。相同的属性在不同视图中有不同的域。比如重量单位，在某视图为千克，而在另一个视图中则用克。

④ 约束冲突。不同的视图可能有不同的约束。

由此可见，合并局部E-R视图并非将各个视图直接进行合并，而需要消除各种冲突。如何合理地消除这些冲突是集成全局E-R模式的关键。

将各个局部E-R模式合并后得到一个初步的全局E-R模式，其中还可能存在冗余的数据和冗余的联系等。冗余的数据指可由基本数据导出的数据，冗余的联系指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护带来困难，因此得到初步E-R图后，还要对其进行优化，使其不仅能全面准确地反映用户需求，还要满足下列条件：实体型的个数尽可能少；实体型所含属性个数尽可能少；实体型之间联系无冗余。这样才能得到一个好的全局E-R模式。

这里以某高校开发学生管理系统为例，简单地了解一下概念设计的过程。

学生管理系统包括学籍管理和课程管理两个子系统：

（1）学籍管理子系统包括学生、宿舍、班级、辅导员、教室、个人档案这些实体。

实体之间的联系有：一个宿舍可以住多个学生，一个学生只能住一个宿舍；一个班级包含多个学生，一个学生只能属于一个班级；一个辅导员指导多个学生，一个学生对应一个辅导员；一个辅导员管理多个班级，一个班级对应一个辅导员；一个班级在多个教室上课，一个教室可以由多个班级来使用；学生与个人档案一一对应。

各实体的属性分别为：学生（学号，姓名，性别，年龄，出生日期，系名，入学时间）；宿舍（宿舍编号，地址，人数）；班级（班级编号，人数）；辅导员（员工号，姓名，性别，年龄，出生日期，工作时间）；教室（教室编号，地址，座位数，是否多媒体教室）；个人档案（档案编号，……）。其中，有下画线的属性是实体的码。

（2）课程管理子系统包括学生、课程、教师、教室这些实体。

实体之间的联系有：一个学生选修多门课程，一门课程由多个学生选修；一个学生有多个任课教师，一个教师给多个学生授课；一门课程由多个教师讲授，一个教师可以讲授多门课程；一个教室可以开设多门课程，一门课程可以在多个教室开设。

各实体的属性分别为：学生（学号，姓名，性别，年龄，出生日期，系名，入学时间）；课程（课程编号，课程名称，学分，学时，是否选修课）；教师（员工号，姓名，性别，年龄，职称，出生日期，系名，工作时间）；教室（教室编号，地址，座位数，是否多媒体教室）。其中，有下画线的属性是实体的码。

图6-10分别对应两个子系统的E-R图，在图中略去了实体的属性。

下面将两个子系统的E-R图集成学生管理系统E-R图，过程如下：

（1）消除冲突：学籍管理中的辅导员实体与课程管理中的教师实体属于异名同义，可以统一为教师实体；统一后，教师与学生两个实体之间存在指导和教学两种联系，将之综合为教学联系。

（a）学籍管理局部E-R图

（b）课程管理局部E-R图

图6-10  管理局部E-R图

（2）消除冗余：学生与教师实体的年龄属性可以通过出生日期计算出来，属于冗余数据，将该属性去掉；教室实体与班级实体之间的使用联系可以由教室实体与课程实体之间的上课联系，课程实体与学生实体之间的选修联系，学生实体与班级实体之间组成联系推导出来，属于冗余联系，故将该联系去掉。

图6-11为集成后的学生管理系统的E-R图。当然，以上只是一个教学示例，在实际应用系统中还要与教学计划管理子系统、统计管理子系统等合并，感兴趣的读者可以参考相关书籍并根据学校具体情况对该系统进行完善。

图6-11  学生管理系统E-R图

6.4.4  数据库的逻辑设计

概念设计得到的全局E-R模式是独立于任何一种数据模型的概念模式，而且现在的计算机信息系统普遍选用关系型DBMS，所以数据库逻辑设计的主要工作是将全局E-R模式转化成指定DBMS中的关系模式。逻辑设计一般分为三个步骤，如图6-12所示。

图6-12  逻辑设计的基本步骤

（1）从E-R图向关系模式转换。

从E-R图到关系模式的转换是比较直接的，因为E-R图是由实体集、实体集的属性和实体集之间的联系三个要素组成，而实体集与联系都可以表示成关系，属性也可以转换成关系的属性。当然在转换过程中也可能会遇到一些问题：

① 命名与属性域的处理。关系模式中的命名可以采用E-R图中原来的命名，但为了便于在DBMS中实施，对应关系模式中的命名一般采用英文或拼音字母的命名方式，比如班级实体集，采用原先命名方式，得到关系模式：班级（班级编号，人数），再使用英文或拼音字母命名，得到关系模式：Classes（ClassNo，MemCount）；E-R图中的属性没有数据类型的限制，而DBMS一般只支持有限种数据类型，故转换时要注意关系中属性的类型是否合适、有效。

② 非原子属性处理。E-R图中允许出现非原子属性，但关系模式中不允许出现非原子属性，如出现此种情况则根据“集合属性纵向展开，元组属性横向展开”的方法进行转换。比如课程实体有课程编号、课程名称、任课老师的属性，其中任课老师是一个集合属性，因为一门课程可以由多个老师讲授，所以可将其纵向展开用关系形式如表6-11所示。

表6-11  课程实体

③ 联系的转换。一般情况下，联系可用关系表示，但在有些情况下联系可以归并到相关联的实体中。

（2）关系模式的优化。

从E-R图转换得到的关系模式只是一个初步的关系数据库模式，要最终成为在DBMS中实施的模式，还需要进行规范化处理和适当的优化处理。

① 规范化处理。规范化处理的目的是减少乃至消除关系模式中存在的各种异常，保证其完整性和一致性，提高存储效率。

② 模式的修正。规范化处理侧重关系模式在理论上的合理性，而较少注意实际应用需求和数据库本身的性能问题。因此还必须对关系模式进行修正。它们包括如下内容：调整性能以减少连接运算；调整关系大小，使每个关系数量保持在合理水平，从而提高存取效率；尽量采用快照，提高查询速度。

（3）关系视图设计。

逻辑设计的另一个重要内容是关系视图的设计，又称为外模式设计，也叫做用户模式设计，是用户可以直接访问的数据模式。同一系统中，不同用户可以有不同的关系视图。关系视图有以下三个作用：通过外模式对逻辑模式的屏蔽，为应用程序提供了一定的逻辑独立性；更好地适应不同用户对数据的不同需求；为不同用户划定了访问数据的不同范围，有利于数据的保密。

6.4.5  数据库的物理设计

数据库的物理设计，就是为一个给定数据库的逻辑结构选取一个最适合应用环境的物理结构和存取方法的过程，其目的是为了提高数据库的访问速度并有效利用存储空间。在现代关系数据库管理系统（RDBMS）中，数据库的大量内部物理结构都由RDBMS自动完成，留给用户参与的物理设计内容并不多，大致有以下几种。

（1）索引设计：确定每个关系是否需要建立索引，若需要，应在什么属性列上建立。

（2）聚簇设计：确定每个关系是否需要建立聚簇，若需要，应在什么属性列上建立。

（3）分区设计：确定数据库数据存放在哪些磁盘上，数据如何分配。

6.4.6  数据库管理员的职责

设计、管理和维护一个应用数据库系统，需要有整体全局的观点，要不断地对系统的设计和运行进行各方面的调整与维护，才能使建立新系统的各项工作保持协调。数据库管理员（Database Administrator，DBA）则是实施此项管理的机构中的一个（组）人员，负责全面管理和控制数据库系统。

DBA的主要职责包括：维护数据的完整性；综合运用DBMS所提供的各种措施，维护数据库安全；确定数据库的恢复策略，定期复制备份，当发生故障时，对数据库采取恢复措施；监视数据库性能，根据数据库的运行情况，确定数据库重组计划，并组织实施；在必要时进行数据库的重构；制定信息系统运行所必要的规章制度，并组织实施。

DBA的任务十分繁重，尤其在一个大型信息系统中，DBA往往是一个工作组，其人员有一定的专业和管理知识，特别是掌握数据库技术并具有处理好人际关系的优良素质。