【数据库原理及应用】——数据库设计（学习笔记）

前言：数据库的设计是指基于现有的数据库管理系统，针对具体应用构建适合的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能有效地存储和管理数据，满足各类用户的应用需求。本章将介绍数据库设计的主要内容、特点，设计方法和全过程，从需求分析﹑概念结构设计、逻辑结构设计、物理结构设计到实施、运行与维护。

---

0. 思维导图

1. 概述

• 数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。
  • 信息管理要求：在数据库中应该存储和管理哪些数据对象 。
  • 数据操作要求：对数据对象需要进行哪些操作，如查询、增、删、改、统计等操作。
• 数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境 。
• 高效率的运行环境
  • 数据库数据的存取效率高
  • 数据库存储空间的利用率高
  • 数据库系统运行管理的效率高

1.1 内容

内容：数据库设计应该与应用系统设计相结合，结构设计和行为设计相结合

• 结构设计：设计数据库框架和数据结构，是静态的。
• 行为设计：指确定数据库用户的行为和动作，即设计应用程序、事务处理等，它是动态的。

现代数据库的设计强调结构设计和行为设计相结合，这是一个“反复探寻，逐步求精”的过程。如下图所示，结构设计和行为设计是分开而又并行进行的。

重视基础数据建设

三分技术，七分管理，十二分基础数据

• 管理
  • 数据库建设项目管理
  • 企业（即应用部门）的业务管理
• 基础数据
  • 收集、入库
  • 更新新的数据

1.2 方法

• 新奥尔良（New Orleans）方法（本章介绍）
• 基于E-R模型的数据库设计方法
• 3NF（第三范式）的设计方法
• 面向对象的数据库设计方法
• 统一建模语言（UML）方法

1.3 基本步骤

六个阶段：需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行和维护

需求分析和概念设计独立于任何数据库管理系统（DBMS）
逻辑设计和物理设计与选用的DBMS密切相关

参加数据库设计的人员

• 系统分析人员和数据库设计人员
  • 自始至终参与数据库设计，其水平决定了数据库系统的质量
• 数据库管理员和用户代表
  • 主要参加需求分析与数据库的运行和维护
• 应用开发人员
  • 包括程序员和操作员
  • 在实施阶段参与进来，分别负责编制程序和准备软硬件环境

六个阶段：

1、需求分析阶段

• 准确了解与分析用户需求（包括数据与处理）
• 最困难、最耗费时间的一步
• 需求分析重点包括信息需求和处理需求。具体工作包括：
  • 系统总体调查。
  • 分析各个部门的工作流程。
  • 画出数据流图，并写出数据字典。

2、概念结构设计阶段

• 整个数据库设计的关键
• 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型
• 通常用E-R模型来表示。

3、逻辑结构设计阶段

• 将概念结构转换为某个DBMS所支持的数据模型
• 对其进行优化
• 在逻辑结构设计阶段选择什么样的数据模型和哪一个具体DBMS尤为重要，它是能否满足用户各种要求的关键

4、数据库物理设计阶段

• 数据库物理设计是将逻辑结构设计阶段所产生的逻辑数据模型，转换为某一计算机系统所支持的数据库物理结构的实现过程。
  物理结构主要指数据库在物理设备上的存储结构和存取方法，它是完全依赖于给定的硬件环境、具体的DBMS和操作系统，数据库的物理结构主要指数据库的存储记录格式、存储记录安排和存储方法。

5、数据库实施阶段

• 运用DBMS提供的数据库语言（如SQL）及宿主语言，根据逻辑设计和物理设计的结果
  • 建立数据库
  • 编制与调试应用程序
  • 组织数据入库
  • 进行试运行

6、数据库运行和维护阶段

• 数据库应用系统经过试运行后即可投入正式运行
• 在数据库系统运行过程中必须不断地对其进行评价、调整与修改

设计一个完善的数据库应用系统往往是上述6个阶段的不断反复

把数据库设计和对数据库中数据处理的设计紧密结合起来
将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计

1.4 设计过程中的各级模式

需求分析阶段：综合各个用户的应用需求

概念设计阶段： 形成独立于机器特点，独立于各个数据库管理系统产品的概念模式（E-R图）

逻辑设计阶段：

1. 首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式
2. 然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图（View），形成数据的外模式

物理设计阶段：根据数据库管理系统特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式

2. 需求分析

• 需求分析就是分析用户的要求
  • 是设计数据库的起点
  • 结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用
• 需求分析常常被忽视
  • 设计人员认为这是软任务，急于进行具体设计
  • 用户嫌麻烦，领导不重视

2.1 任务

• 详细调查现实世界要处理的对象（组织、部门、企业等）
• 充分了解原系统（手工系统或计算机系统）工作概况
• 明确用户的各种需求
• 在此基础上确定新系统的功能
• 新系统必须充分考虑今后可能的扩充和改变

调查的重点是“数据”和“处理”，获得用户对数据库的要求：

（1）信息要求

• 用户需要从数据库中获得信息的内容与性质
• 由信息要求可以导出数据要求，即在数据库中需要存储哪些数据

（2）处理要求

• 用户要完成的处理功能
• 对处理性能的要求

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

• 确定用户最终需求的难点
  • 用户缺少计算机知识，不能准确地表达自己的需求，他们所提出的需求往往不断地变化。
  • 设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求
• 解决方法：与用户多交流

2.2 步骤和方法

需求分析首先就是要调查清楚用户的实际需求，目的是了解企业的业务情况、信息流程、经营方式、处理要求以及组织机构等，为当前系统建立模型。

需求分析阶段的活动主要包括以下四个步骤：
（1）分析用户活动，产生用户活动图
这一步主要了解用户当前的业务活动和职能，搞清其处理流程，即绘制出业务流程图。
（2）确定系统范围，产生系统范围图
这一步是确定系统的边界。在和用户经过充分讨论的基础上，确定计算机所能进行数据处理的范围，确定哪些工作由人工完成，哪些工作由计算机系统完成，即确定人机界面。
（3）分析用户活动所涉及的数据，产生数据流图
深入分析用户的业务处理，以数据流图形式表示出数据的流向和对数据所进行的加工。具有直观、易于被用户和软件人员双方理解的特点，它是一种表达系统功能的描述方式。
（4）分析系统数据，产生数据字典
仅仅有数据流图并不能构成需求说明书，因为只表示出系统由哪几部分组成和各部分之间的关系，并没有说明各个成分的含义。只有对每个成分都给出确切定义后，才能较完整地描述系统。

方法：需求分析的方法有多种，主要分为自顶向下和自底向上两种。其中自顶向下的结构化分析方法（SA-Structured Analysis）简单实用，它从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统，并且把每一层用数据流图和数据字典描述。

2.2.1 数据流图（DFD）

数据流图（DFD -Data Flow Diagram）是描述系统的重要工具，它从数据传递和处理角度以图形的方式描绘数据流动和被处理的逻辑过程。数据流图是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它，因此它是分析员与用户之间极好的通信工具。

符号：

数据源点或终点：指本系统之外的人或单位，他们与本系统有信息传递关系。
数据处理：数据处理对进入的数据流进行特定的加工的过程，处理后将产生新的数据流
数据流：表示流动着的数据，它可以是一项数据，也可以是一组数据。
数据存储文件：指通过数据文件、文件夹或账本等存储数据。

为了很好地表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。

顶层图：将整个系统作为一个数据加工项，着重描述系统与外部实体的联系。明确系统的边界。
第0层图：对顶层图中的数据加工进行分解，形成系统较详细的数据流程图
第1层图：对顶层图中的数据加工进一步分解，形成系统更详细的数据流程图。

以教学管理信息系统为例，如图所示，顶层数据流图分解为第0层数据流图，再进一步细化为第1层数据流图，直到把系统的工作过程表达清楚为止。在处理功能逐步分解的同时，数据也逐级分解，形成若干层次的数据流图。

2.2.2 数据字典

• 数据字典是关于数据库中数据的描述，即元数据，不是数据本身
• 数据字典在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善
• 数据字典是进行详细的数据收集和数据分析所获得的主要结果

注意：和关系数据库管理系统中数据字典的区别和联系

数据字典（DD-Data Dictionary）用于定义数据流图中出现的所有数据元素和处理，即给出确切的内涵解释。数据流图配以数据字典，就可以从图形和文字两个方面对系统的逻辑模型作进一步完整描述。
数据字典的内容：数据项、数据流、数据存储、处理过程

2.2.2.1 数据项

• 数据项是不可再分的数据单位。
• 数据项描述＝{数据项名，别名，数据项含义说明，取值定义（数据类型、长度、取值范围、取值含义），与其他数据项的联系}
• 其中“取值定义”、“与其他数据项的逻辑关系”定义了数据的完整性约束条件，是设计数据检验功能的依据。

举例：

• 数据项名称：学生编号
• 别名：学号
• 数据项含义：唯一地标识学生身份的号码
• 类型：CHAR
• 长度：8
• 取值范围：20210901-20250530

2.2.2.2 数据流

• 数据流是数据结构在系统内传输的路径。
• 数据流描述={数据流名,说明,数据流来源,数据流去向,组成:{数据结构},平均流量,高峰期流量}
  • 数据流来源：说明该数据流来自哪个过程
  • 数据流去向：说明该数据流将到哪个过程去
  • 平均流量：在单位时间（每天、每周、每月等）里的传输次数
  • 高峰期流量：在高峰时期的数据流量

举例：

• 数据流名称：选课申请
• 别名：选课
• 说明：由学生个人信息和课程信息组成选课申请
• 数据流来源：无
• 数据流去向：身份验证
• 平均流量：1500次/天
• 高峰流量：2100次/天
• 数据组成：账号、密码

2.2.2.3 数据存储

• 数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。
• 数据存储描述={数据存储名，别名，编号，说明，输入数据流，输出数据流，数据描述，数据量，存取方式}
  • 存取频度：每小时、每天或每周存取次数，每次存取的数据量等信息
  • 存取方法：批处理 / 联机处理；检索 / 更新；顺序检索 / 随机检索
  • 输入的数据流：数据来源
  • 输出的数据流：数据去向
  • “编号”指每个数据存储都有唯一的编号。

举例：

• 数据存储名：上课时间信息
• 别名：授课时间
• 编号：S1
• 说明：每门课的上课时间，一门课可以有多个上课时间，同一时间可有多门课程在上课。
• 输出数据流：课程上课时间
• 数据描述：课程编号、上课时间
• 数据量：每学期200-300个
• 存取方式：随机存取

2.2.2.4 处理过程

• 处理过程说明某个具体的加工处理工作。
• 处理过程＝{处理过程名，说明，编号，触发条件，输入数据流，输出数据流，处理}
  • 其中“编号”每个处理过程都有唯一的编号，并且按照处理过程所在的数据流图的层次来命名，比如：若在第2层，编号可以为1.1.1、1.1.2、1.2.1等。
  • “处理”描述处理的算法、加工逻辑流程、校验规则和默认情况。

举例：

• 处理过程名：身份验证
• 说明：对学生输入的账号、密码进行验证，验证通过则得到相应的学生编号
• 输入：学生账号、密码、选课的课程编号
• 输出：学生编号、选课的课程编号
• 处理：对输入的学生个人信息，检查学号和密码是否正确；对身份正确的学生，检查要选修的课程是否允许；检查是否正确返回信息。

3. 概念结构设计

• 概念结构设计是将需求分析得到的用户需求抽象为信息结构，即概念层数据模型。它是整个数据库设计阶段的关键，独立于逻辑结构设计和数据库管理系统。
• 概念结构是对现实世界的一种抽象，即对实际的人、物、事和概念进行人为处理，抽取人们关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述。它常用E-R模型进行描述。

3.1 特点

• 概念模型能够充分反映现实世界，能够满足用户对数据的处理要求。
• 概念模型易于向关系、网状、层次、面向对象等各种数据模型转换。
• 概念模型易于理解，便于和不熟悉计算机的用户交换意见，用户易于参与。
• 概念模型易于更改，当现实世界需求改变时，概念结构又可以很容易作相应调整。

3.2 设计策略

3.2.1 自顶向下策略（top-down strategy）

首先定义全局概念结构的框架，然后逐步细化

3.2.2 自底向上策略（bottom-up strategy）

首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构

3.2.3 由内向外(逐步扩张)策略（inside-out strategy）

首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构

3.2.4 混合策略（mixed strategy）

将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。

3.3 步骤

E-R模型是设计数据库概念结构的最著名、最常用方法。因此，采用自底向上方法分步设计产生每一局部的E-R模型，综合各局部E-R模型，逐层向上回到顶部，最终产生全局E-R模型。
按照下图所示的概念结构设计的步骤，概念结构的设计可分为两步：
（1）抽象数据，并设计局部E-R模型，即局部视图；
（2）集成各局部E-R模型，形成全局E-R模型，即视图集成。

3.4 数据抽象

• 概念结构是对现实世界的一种抽象。所谓抽象是抽取现实世界中实体的共同特性，忽略非本质细节，并把这些特性用各种概念精确地加以描述，形成某种模型。概念结构设计首先要根据需求分析得到的结果（如数据流图、数据字典）对现实世界进行抽象，设计各个局部E-R模型。

数据抽象主要有三种基本方法： 分类、聚集、概括

3.4.1 分类（Classification）

• 定义某一类概念作为现实世界中的一组对象的类型。这些对象具有某些共同的特性和行为。它抽象了对象值和型之间的“is a member of”的语义。在E-R模型中，实体就是这种抽象。

3.4.2 聚集（Aggregation）

• 聚集是定义某一类型的组成部分，它抽象了对象内部类型成分之间的“is a part of”的语义。在E-R模型中若干属性的聚集组成了实体型。

3.4.3 概括（Generalization）

• 概括定义了实体之间的一种子集联系，它抽象了实体之间的“is a subset of”的语义。例如“学生”是实体集，“中学生”、“本科生”、“研究生”也是实体集，但均是“学生”实体的子集。把“学生”称为超类，“中学生”、“本科生”、“研究生”称为“学生”的子集。在E-R模型里面用双竖线的矩形框表示子类，用直线加小圆圈表示超类-子类的联系。

• 概括有一个很重要性质是继承性。继承性指子类继承超类中定义的所有抽象。但是子类也可以有自己的特性，即“中学生”、“本科生”、“研究生”除了继承了“学生”的所有属性和方法之外，还具有自己学生类型的特性，比如“本科生”有所学专业、所属院系等高校学生的属性。

3.5 局部E-R模型设计

3.5.1 步骤

3.5.1.1 选择局部应用

• 在多层的数据流图中选择一个适当层次的（经验很重要）数据流图，使得图中每一部分对应一个局部应用，可以就这一层次的数据流图为出发点，设计局部E-R模型。
• 一般而言，往往以中层数据流图作为设计局部E-R模型的依据。

3.5.1.2 逐一设计分E-R图

• 将各局部应用涉及的数据分别从数据字典中抽取出来
• 参照数据流图，标定各局部应用中的实体、实体的属性、标识实体的码
• 确定实体之间的联系及其类型（1:1，1:n，m:n）

两条准则：

• 属性不能再具有需要描述的性质。即属性必须是不可分的数据项，不能再由另一些属性组成
• 属性不能与其他实体具有联系。联系只发生在实体之间

例如，某公司的职员是一个实体，职员号、姓名、年龄、身高、职务等级是职员的属性，职务等级如果没有与工资、福利挂钩，换句话说，不需要进一步描述该特性，则根据第一条，可以作为“职员”实体的属性。但是如果不同的等级的职务有不同的工资待遇、福利等，那么职务等级就需要作为一个实体看待了，如下图所示。

3.5.2 例子：教学管理信息系统

在高校的实际应用中，一个学生可以选修多门课程，一门课程可以被多个学生选修；一个教师可以讲授多门课程，一门课程也可以被多个教师讲授；一个系可以有多个学生，一个学生只能属于一个系；一个系可以有多个教师，一个教师只能属于一个系；一个系可以开设多门课程，一门课程只能由一个系开设。因此，各子系统的局部E-R模型见下图，它们分别由2名数据库设计人员完成。

3.6 全局E-R模型设计

集成各子系统的局部E-R模型形成全局E-R模型，即视图集成，有四种方法：

3.6.1 二元集成（Binary ladder integration）

• 用累加的方式一次集成两个分E-R图
• 首先对两个比较类似的模式进行集成。然后把结果模式和另外一个模式集成，不断重复该过程直到所有模式被集成。

3.6.2 n元集成（Nary integration）

• 一次集成多个分E-R图
• 通常用于局部视图比较简单时

3.6.3 二元平衡策略（binary balanced strategy）

首先将模式成对地进行集成，然后再将结果模式成对地进一步集成，不断重复该过程直至得到最终的全局模式。

3.6.4 混合策略（mixed strategy）

根据模式的相似性把它们划分为不同的组，对每个组单独地进行集成。然后对中间结果进行分组并集成，重复该过程直至集成结束。

3.7 系统集成小结

• 实际应用时可以根据系统复杂度选择集成策略。一般情况常常采用二元集成。如果局部E-R模型比较简单，可以采用n元集成。
• 无论采用哪个方法集成视图，在每次集成时都要先合并局部E-R模型，解决各局部E-R模型之间的冲突问题，并将各局部E-R模型合并起来生成初步E-R模型；优化初步E-R模型，消除不必要的实体集冗余和联系冗余，得到基本E-R模型，如下图所示。

3.7.1 合并

• 合并后，解决各局部E-R模型之间的冲突，生成初步E-R模型。
• 通常是由不同的设计人员进行不同局部的视图设计，所以就会导致各局部E-R模型之间存在许多不一致的地方，即产生“冲突”。
• 因此，有必要在合并之前先消除各局部E-R模型之间的不一致，形成一个能被全系统所有用户共同理解和接受的统一的概念模型。

合理消除各局部E-R模型之间的冲突是合并的关键。

模式间可能会发生如下的3类冲突：

3.7.1.1 属性冲突

• 属性值域冲突，即属性值的类型、取值范围或取值集合不同。例如，“职员”的性别属性，有些部门定义的类型是布尔型，取值0和1；有的部门定义的类型是字符型，取值男和女。
• 属性取值单位冲突。例如，“职员”的身高，不同部门可能分别用米或厘米来表示，这就会给数据统计造成错误。

3.7.1.2 命名冲突

• 同名异义，不同意义的对象在不同的局部应用中具有相同的名字。
• 异名同义，即一义多名。意义相同的对象在不同的局部应用中具有不同的名字。如教研项目，在教务处称为“课题”，在财务处称为“项目”。

3.7.1.3 结构冲突

• 同一对象在不同应用中具有不同的抽象。例如“班主任”在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。
• 同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。此类冲突即所包含的属性个数和属性排列次序不完全相同。这类冲突是由于不同的局部应用所关心的实体的不同侧面而造成的。解决这类冲突的方法是使该实体的属性取各个局部E-R模型中属性的并集，再适当调整属性的次序，使之兼顾到各种应用。
• 实体之间的联系在不同局部视图中呈现不同的类型。

3.7.1.4 合并实例

以“教学管理信息系统”为例，说明合并局部E-R模型的主要过程。
第1步：确定并解决各局部E-R模型之间的冲突：
① 2个局部E-R模型之间存在命名冲突。学生选课局部E-R模型中的实体“系”和教师授课局部E-R模型中的实体“院系”异名同义，合并后统一改为“系”，因此属性“系别”和“院系名”统一为“系别”，“系主任”和“院系负责人”统一为“系主任”。
② 存在结构冲突。2个局部E-R模型中的实体“系”和“课程”属性组成不同，将取原来2个实体的属性并集组成合并后实体的属性。
第2步：视图集成，集成后的教学管理信息系统的E-R模型如下图所示。

3.7.2 优化

优化就是消除不必要的冗余，生成基本E-R模型。优化的目的就是使E-R模型满足下述3个条件：

• 实体个数尽可能少
• 实体所包含的属性尽可能少
• 实体间的联系无冗余

其中，要使实体个数尽可能少，可以合并相关实体，一般是把具有相同主码的实体进行合并；另外，还可考虑将1:1联系的两个实体合并成一个实体，同时消除冗余属性和冗余联系。冗余属性是指可由基本数据导出的属性，冗余联系是指可由其他联系导出的联系。

上图所示是将初步E-R模型优化为基本E-R模型。
①“课程”实体中的属性“教师编号”可由“讲授”这一联系导出，所以，“教师编号”是冗余属性；
②“教师”实体中的“所属院系”可由 “工作”这一联系导出，所以，“所属院系”是冗余属性；
③以此类推，“学生”实体的中“所属院系”也是冗余属性；而“系”和“课程”之间的“开设”这一联系可由“系”和“教师”之间“工作”联系与“教师”和“课程”之间的“讲授”联系推导出来，所以，“开设”是冗余联系。

4. 逻辑结构设计

• 任务：把概念结构设计阶段得到的E-R模型转换为特定DBMS所支持的数据模型。

4.1 步骤

①.将概念结构转换为特定DBMS支持下的数据模型；
②.对数据模型进行优化。

4.2 E-R模型向关系模型的转换☆☆☆

E-R图向关系模型的转换要解决的问题

• 如何将实体型和实体间的联系转换为关系模式
• 如何确定这些关系模式的属性和码

转换内容：将E-R图转换为关系模型：将实体、实体的属性和实体之间的联系转换为关系模式。

转换原则：
（1）一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。
（2）一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并（常用）。
（3）一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并（常用）。
（4）一个m:n联系必须转换为一个关系模式。

• 与该联系相连的各实体的码以及联系本身的属性均转换为此关系模式的属性，且关系模式的主码包含各实体的码。

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

以上图中的教学管理信息系统的基本E-R模型为例，具体分析
① 4个实体“系”、“教师”、“学生”、“课程”分别转换成4个关系模式，如下：
系（系名，系主任，地址）
教师（教师编号，教师姓名，年龄，职称）
学生（学生编号，学生姓名，年龄，性别）
课程（课程号，课程名）

② 1:n联系“工作”，与n端所对应的关系模式“教师”合并，则需要在该关系模式“教师”的属性中加入1端实体“系”的码和联系本身的属性，结果如下：
教师（教师编号，教师姓名，年龄，职称，$\underset{\sim \sim \sim }{\mathrm{系名}}$）；
其中“系名”是“教师”的外码，参考“系”的主码“系名”。
1:n联系“拥有”，与n端所对应的关系模式“学生”合并，则需要在该关系模式“学生”的属性中加入1端实体“系”的码和联系本身的属性，结果如下：
学生（学生编号，学生姓名，年龄，性别，$\underset{\sim \sim \sim }{\mathrm{系名}}$）；
其中“系名”是“学生”的外码，参考“系”的主码“系名”。

③ m:n联系“讲授”、“选修”，必须转换为一个独立的关系模式。转换后的结果为：
讲授（$\underline{\underline{教师编号}，\underline{课程号}}$，课时数）
选修（$\underline{\underline{学生编号}，\underline{课程号}}$，成绩）
其中“讲授”关系中（教师编号，课程号）是主码，“教师编号”和“课程号”分别是外码，相应地参考了关系模式“教师”的主码“教师编号”以及关系模式“课程”的主码“课程号”。

4.3 数据模型的优化

• 得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化
• 关系数据模型的优化通常以规范化理论为指导

4.3.1 规范化过程的两个步骤

4.3.1.1 确定范式级别

考察关系模式的函数依赖关系，确定范式等级。找出所有“数据字典”中得到的数据之间的依赖关系，对各模式之间的数据依赖进行极小化处理，消除冗余的联系。按照数据依赖理论对关系模式逐一进行分析，考察是否存在部分函数依赖、传递函数依赖等，确定各关系模式属于第几范式。

4.3.1.2 实施规范化处理

确定范式级别后，根据应用需求，判断它们对于这样的应用环境是否合适，确定对于这些模式是否进行合并或分解。

（1）合并

• 如果有若干关系模式具有相同的主码，并且对这些关系模式的处理主要是查询操作，而且经常是多表连接查询，那么可以对这些关系模式按照组合使用频率进行合并，这样可以减少连接操作的次数从而提高查询效率。

（2）分解

• 对关系模式进行必要的分解，提高数据操作的效率和存储空间的利用率。常用的方法是水平分解和垂直分解两种分解方法。

  • ① 水平分解

    • 水平分解是以时间、空间、类型等范畴属性取值为条件，满足相同条件的数据作为一个子表。对于经常进行大量数据的分类条件查询的关系，可以进行水平分解，这样就大大减少了应用系统每次查询所需要访问的记录数量，从而提高了查询性能。
    • 例如，对于教学管理信息系统的“学生”关系，可以水平分解为“在校学生”和“毕业学生”2个关系模式。因为对于已经毕业学生的情况关心较少，而经常需要了解当前在校学生的情况。因为将已经毕业学生的信息单独存放在“毕业学生”中，可以提高对在校学生的处理速度。

  • ② 垂直分解

    • 垂直分解是以非主属性所描述的数据特征为条件，把经常一起使用的属性划分在一个子表中。
    • 例如，“学生”关系垂直分解为“学生基本信息”和“学生家庭信息”2个关系模式。
    • 垂直分解可以提高某些事务的效率，但有可能使另一些事务不得不执行连接操作，从而降低效率。因此，是否进行垂直分解要看分解后的所有事务的总效率是否得到了提高。

4.4 设计用户外模式

将概念模型转换为逻辑模型后，还应该根据局部应用需求，结合具体DBMS的特点，设计用户的外模式。外模式对应关系数据库管理系统的视图这一概念，可以利用视图设计更符合局部用户需要的用户外模式。

包括：
（1）使用更符合用户习惯的别名
在合并各局部E-R模型时，需要消除命名冲突，以使数据库中的同一个关系和属性具有唯一的名字，但有可能不符合某些用户的习惯。这时，可以利用视图对某些属性重命名，这样方便用户使用。
（2）对不同级别的用户定义不同的视图，以满足系统对安全性的要求
如关系模式教师（教师编号，教师姓名，年龄，籍贯，专业，所属院系，联系电话，职称，基本工资，绩效工资），在这个关系上建立两个视图：
教师1（教师编号，教师姓名，年龄，籍贯，专业，所属院系，联系电话）
教师2（教师编号，教师姓名，年龄，籍贯，联系电话，职称，基本工资，绩效工资）
教师1视图中只包含了一般职工可以查看的基本信息，而教师2视图中包含了允许领导查看的信息。这样就可以防止用户非法访问不允许他们查看的数据，从一定程度上保证了数据的安全。
（3）简化用户对系统的使用
如果在某些局部应用中经常要使用某些复杂的查询，为了方便用户，可以将这些复杂的查询定义成一个视图，这样每次用户只需查询定义好的视图，而不用再编写复杂的查询语句。

5. 物理结构设计

• 数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统
• 为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程，就是数据库的物理设计

关系数据库物理设计的内容

• 为关系模式选择存取方法（建立存取路径）
• 设计关系、索引等数据库文件的物理存储结构

5.1 存取方法的选择

5.1.1 索引

选择索引方法的基本原则是：
（1）如果某个或某些属性经常在查询条件中出现，则考虑在这个或者这些属性上建立索引。
（2）如果某个或某些属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个或这些属性上建立索引。
（3）如果某个或某些属性经常在连接操作的连接条件中出现，则考虑在这个或这些属性上建立索引。
（4）如果某个属性经常作为分组的依据列，则考虑在这个属性上建立索引。
（5）对经常执行插入、删除、修改操作或者记录数较少的关系，应尽量避免建立索引。

当然，关系上定义的索引数也要适当，并不是越多越好，因为系统为维护索引要付出代价，查找索引也要付出代价。

5.1.2 聚簇

候选聚簇的原则：
（1）将一个关系按某个或某组属性的值聚簇。对数据库的查询经常按照属性值相等性，或进行属性值相互比较，为此可以将记录按照某个或某组属性的值来聚簇存放，并建立聚簇索引。例如：如果经常需要按院系属性来检索学生记录，那么预先将同一个院系的学生的记录，在物理介质上尽可能存放在一起，这样一个院系的学生记录所存放的页面数最少，因而所需的I/O数大大减少，提高了存取的效率。
（2）对于不同关系，经常在一起进行连接操作的可以建立聚簇。关系数据库中经常通过一个关系与另一个关系的关联属性找到另一个关系的需求记录信息，此时如果把有关的两个关系物理上靠近存放，如存放在同一个柱面上，这可以使得在完成相关检索时，大大提高了效率。
（3）如果关系的主要应用是通过聚簇码进行访问或连接，而其他属性访问关系的操作很少时，可以使用聚簇。尤其当SQL语句中包含有与聚簇有关的ORDER BY，GROUP BY，UNION，DISTINCT等子句或短语时，使用聚簇特别有利，可以省去对结果集的排序操作。反之，当关系较少利用聚簇码时，最好不要使用聚簇。

5.2 存储结构的确定

确定数据存放位置和存储结构的因素，这三个方面常常是相互矛盾的

• 存取时间
• 存储空间利用率
• 维护代价

例，消除一切冗余数据虽能够节约存储空间和减少维护代价，但往往会导致检索代价的增加， 必须进行权衡，选择一个折中方案

5.2.1 存放位置

为了提高系统性能，应根据应用情况将数据的易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。有多个磁盘的计算机，可以采用下面几种存取位置的分配方案：
（1）将表和索引放在不同的磁盘上。这样在查询时，两个磁盘驱动器并行工作，可以提高物理I/O读写效率。
（2）将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。
（3）将日志文件、备份文件与数据库对象放在不同的磁盘上，以改进系统的性能。
（4）对于经常存取时间要求高的对象应放在高速存储器上，对于存取效率小或存取时间要求低的对象，如果数据量很大，可以存放在低速存储设备上。

5.2.2 系统配置

DBMS产品一般提供了一些系统配置变量和存储分配参数供设计人员和DBA对数据库进行物理优化。在初始情况下，系统都为这些变量赋予了合理的默认值。但是这些默认值不一定适合每种应用环境。在进行数据库的物理设计时，还需要重新对这些变量赋值，以改善系统的性能。

系统配置变量很多。例如，同时使用数据库的用户数、同时打开的数据库对象数、内存分配参数、缓冲区分配参数、存储分配参数等，这些参数值将影响存取时间和存储空间的分配。物理设计时需要根据应用环境确定这些参数值，以使系统性能最佳。在物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况做进一步的调整，以期切实改进系统性能。

5.2.3 评价

评价物理结构设计的方法完全依赖于具体的DBMS，主要考虑操作开销，即：为使用户获得及时、准确的数据所需要的开销和计算机资源的开销。实际上，往往需要经过反复测试才能优化数据库的物理结构。

6. 数据库实施

数据系统设计的根本目的，是为用户提供一个能够实际运行的系统，并保证该系统的稳定和高效。要做到这点，还有两项工作，就是数据库的实施、运行和维护。

定义：数据库的实施主要是根据逻辑结构设计和物理结构设计的结果，在计算机系统上建立实际的数据库结构、导入初始数据并进行程序的调试。它相当于软件工程中的代码编写和程序调试的阶段。

主要工作是：建立数据库、加载数据和系统调试。不包括扩充功能

6.1 建立实际数据库结构

用具体的DBMS提供的数据定义语言(DDL)，把数据库的逻辑结构设计和物理结构设计的结果转化为SQL语句，然后经DBMS编译处理和运行后，实际的数据库便建立起来了。目前的很多DBMS系统除了提供传统的命令行方式外，还提供了数据库结构的图形化定义方式，极大地提高了工作的效率。
具体地说，建立数据库结构应包括以下几个方面：
（1）数据库模式与子模式，以及数据库空间的描述；
（2）数据完整性的描述；
（3）数据安全性描述；
（4）数据库物理存储参数的描述。

6.2 装入数据与应用程序编码、调试

一般数据库系统中的数据量都很大，而且数据来源往往不同，所以数据的组织方式、结构和格式都与新设计的数据库系统有相当差距。因此，转入数据需要耗费大量的人力、物力，同时又简单乏味且意义重大。为了保证转入数据正确无误，必须高度重视数据的校验工作。
数据库应用程序的设计应该与数据库设计同时进行。因此，在组织数据入库的同时还要调试和应用程序。

6.3 数据库的试运行

当有初始数据装入数据库以后，就可以进入数据库系统的试运行阶段，也称为联合调试。数据库的试运行对于系统设计的性能检测和评价是十分重要的，因为某些DBMS参数的最佳值只有在试运行中才能确定。
由于在数据库设计阶段，设计者对数据库的评价多是在简化了的环境条件下进行的，因此设计结果未必是最佳的。在试运行阶段，除了对应用程序做进一步的测试之外，重点执行对数据库的各种操作，实际测量系统的各种性能，检测是否达到设计要求。如果在数据库试运行时，所产生的实际结果不理想，则应重新修改物理结构，甚至修改逻辑结构。

7. 数据库的运行和维护

数据库系统投入正式运行，意味着数据库的设计与开发阶段的基本结束，运行与维护阶段的开始。数据库的运行和维护是个长期的工作，是数据库设计工作的延续和提高。
在数据库运行阶段，完成对数据库的日常维护，数据库系统的工作人员需要掌握DBMS的存储、控制和数据恢复等基本操作，而且要经常性地涉及物理数据库，甚至逻辑数据库的再设计，因此数据库的维护工作仍然需要具有丰富经验的专业技术人员（主要是数据库管理员）来完成。

数据库的运行和维护阶段的主要工作有：
（1）对数据库性能的监测、分析和改善；
（2）数据库的转储和恢复；
（3）维持数据库的安全性和完整性；
（4）数据库的重组和重构。

8. 课后习题

1. 【单选题】下列对数据库应用系统设计说法中正确的是（ ）。
   A、必须在完成数据库的设计后才能开始对数据处理的设计
   B、应用系统用户不必参与设计过程
   C、应用程序员可以不必参与数据库的概念结构设计
   D、以上都不对

2. 【单选题】DBMS的数据字典中未保存下列（ ）信息。
   A、模式和子模式
   B、存储模式
   C、文件存取权限
   D、数据库所用的文字

3. 【单选题】概念模型独立于（ ）。
   A、E-R模型
   B、硬件设备和DBMS
   C、操作系统和DBMS
   D、DBMS

4. 【单选题】下列选项中，不属于全局E-R模型设计的是（ ）。
   A、确定公共实体类型
   B、消除冲突
   C、将E-R模型转换为关系模型
   D、合并局部E-R模型

5. 【单选题】以下关于E-R图的叙述正确的是（ ）。
   A、E-R图建立在关系数据库的假设上
   B、E-R图使用过程和数据的关系清晰，实体间的关系可导出应用过程的表示
   C、E-R图可将现实世界中的信息抽象地表示为实体以及实体间的联系
   D、E-R图能表示数据生命周期

6. 【单选题】单个用户使用的数据视图的描述称为（ ）。
   A、外模式
   B、概念模式
   C、内模式
   D、存储模式

7. 【单选题】数据库逻辑结构设计的主要任务是（ )。
   A、建立E-R图和说明书
   B、创建数据库说明
   C、建立数据流图
   D、把数据送入数据库

8. 【单选题】若两个实体之间的联系是1:m，则实现1: m联系的方法是（ ）。
   A、在“m”端实体转换关系中加入“1”端实体转换关系的码
   B、在“m”端实体转换关系的码加入到“1”端的关系中
   C、在两个实体转换的关系中，分别加入另一个关系的码
   D、将两个实体转换成—个关系

9. 【单选题】将一个1对多联系型转换为一个独立模式时，应取（ ）为关键字。
   A、一个实体型的关键属性
   B、多端实体型的关键属性
   C、两个实体型的关键属性组合
   D、联系型的全体属性

10. 【单选题】关系数据库的规范化理论主要解决的问题是（ ）。
    A、如何构造合适的数据逻辑结构
    B、如何构造合适的数据物理结构
    C、如何构造合适的应用程序界面
    D、如何控制不同用户的数据操作权限

11. 【填空题】采用关系模型的逻辑结构设计的任务是将E-R图转换成一组（ ） ，并进行（ ）处理。

12. 【单选题】对数据库的物理设计优劣评价的重点是（ ）。
    A、时空效率
    B、动态和静态性能
    C、用户界面的友好性
    D、成本和效益

13. 【单选题】下面不属于数据库物理设计阶段应考虑的问题是（ ）。
    A、存取方法的选择
    B、索引与入口设计
    C、与安全性、完整性、一致性有关的问题
    D、用户子模式设计

14. 【判断题】需求说明书是系统总体设计方案，是开发单位与用户单位共同协商达成的文档。

15. 【判断题】设计数据库的逻辑结构模式时，只要设计好全局模式，不需要进行各个外模式的设计。

答案：1.C（解析：应用程序员主要针对物理结构实施程序开发，可以不必参与数据库的概念结构设计。） 2.D（解析：这里所说的DBMS的数据字典，它应该包含三级模式、两级映像、数据库安全性、数据库完整性等方面的信息。） 3.B（解析：概念设计不涉及信息在计算机中的表示，所以独立于支持数据库的DBMS，独立于计算机硬件。） 4.C 5.C 6.A 7.B（解析：A是概念设计，C是需求分析，D是数据库实施） 8.A 9.B 10.A 11.关系模型、规范化 12.A 13.D 14.√ 15.×

---

OK，以上就是本期知识点“数据库设计”的知识啦~~ ，感谢友友们的阅读。后续还会继续更新，欢迎持续关注哟~
如果有错误❌，欢迎批评指正呀~让我们一起相互进步
如果觉得收获满满，可以点点赞支持一下哟~