【课堂笔记】《数据库系统概论（第5版）》-第7章：数据库设计

7.1 数据库设计概述

在数据库领域内，通常把使用数据库的各类信息系统都称为数据库应用系统。

广义的讲，数据库设计是数据库及其应用系统的设计；

狭义的讲，数据库设计是设计数据库本身，即：设计数据库的各级模式并建立数据库。

数据库设计的一般定义：

对于一个给定的应用环境，构造优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，并据此建立数据库及其应用系统，使之能够有效的储存和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。

数据库设计的目的是为用户和各种应用系统提供一个信息基础设施和高效的运行环境；高效的运行环境是指数据库数据的存取效率、数据库存储空间的利用率、数据库系统运行管理的效率。

7.1.1 数据库设计的特点

1. 数据库建设的基本规律

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

   这里的管理不仅包括数据库建设作为一个大型项目工程项目本身的项目管理，还包括该企业的业务管理。

   十二分基础数据则强调了数据的收集、整理、组织和不断更新是数据库建设过程中的重要环节。

2. 结构设计和行为设计相结合

   传统的结构和行为分离的设计：
   

7.1.2 数据库设计方法

从事数据库设计的专业人员需要具备多方面的知识，主要包括：

• 计算机的基础知识
• 软件工程的原理和方法
• 程序设计的方法和技巧
• 数据库的基本知识
• 数据库设计技术
• 应用领域的知识

早期数据库设计主要采用手工与经验相结合的方法，设计质量往往与设计人员的经验和水平有直接的关系。

为此，人们努力探索，提出了各种数据库设计方法，例如新奥尔良方法（emm…），基于E-R模型的设计方法，3NF设计方法、统一建模语言方法等。

7.1.3 数据库设计的基本步骤

数据库设计分为以下6个阶段：

• 需求分析
• 概念结构设计
• 逻辑结构设计
• 物理结构设计
• 数据库实施
• 数据库运行和维护

7.1.4 数据库设计过程中的各级模式

数据库设计的不同阶段形成数据库的各级模式：

7.2 需求分析

需求分析是数据库设计的起点，需求分析结果是否准确反映用户的实际要求将直接影响到后续各个阶段的设计，并影响到设计结果是否合理和实用。

7.2.1 需求分析的任务

需求分析的任务是：通过详细调查显示世界需要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或是计算机系统）的工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能；

新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前的应用需求来设计数据库。

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

1. 信息要求：

   用户需要从数据库中获得的信息的内容与性质

2. 处理要求：

   用户需要完成的数据处理功能，以及对于处理性能的要求

3. 安全性与完整性要求

确定用户最终需求是一件很困难的事情，一方面用户缺少计算机知识，另一方面设计人员缺少用户的专业知识（真实）。

7.2.2 需求分析的方法

调查用户需求的具体步骤：

1. 调查组织机构情况：

   了解组织的部门组成情况、各部门的职责等等，为分析信息流程做准备。

2. 调查各部门的业务活动情况

   了解各部门使用和输入什么数据，如何加工处理这些数据，输出何种信息到何种部门，输出何种格式的信息等。

3. 在熟悉业务活动的基础上，协助用户明确对信系统的各种要求，其中包括信息要求、处理要求、安全性与完整性要求等。

4. 确定新系统的边界，即哪些任务由计算机完成，哪些任务由人工完成

常用的调查方法：

1. 跟班作业
2. 开调查会
3. 请专人介绍
4. 询问
5. 设计调查表请用户填写
6. 查阅记录：与原系统有关的记录

在调查了用户的需求之后，还需要进一步分析和表达用户的需求，在众多的分析方法中，结构化分析（SA）方法是一种简单实用的方法。

7.2.3 数据字典

数据字典是关于数据库中数据的描述，即元数据，而不是数据的本身。

数据字典在需求分析阶段建立，在数据库设计过程中不断的修改充实和完善。

数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程。

数据项是数据的最小组成单位；

若干个数据项组成一个数据结构；

数据字典通过对数据项和数据结构的定义来描述数据流、数据储存的逻辑内容。

1. 数据项

   数据项是不可再分的数据单位

   数据项描述 = {
       数据项名，
       数据项含义说明，
       别名，
       数据类型，
       长度，
       取值范围，
       取值含义，
       与其他数据项的逻辑关系，
       数据项之间的联系，
   }
   

   其中，取值范围和与其他数据项的逻辑关系定义了数据的完整性约束条件，是设计数据检验功能的依据。

   用数据依赖的概念分析和表示数据项之间的联系，即按实际语义写出每个数据项之间的数据依赖，他们是数据库逻辑设计阶段数据模型优化的依据。

2. 数据结构

   数据结构反映了数据之间的组合关系；

   一个数据结构可以由若干个数据项或其他数据结构组合而成。

   数据结构描述 = {
       数据结构名，
       含义说明，
       组成：{
           数据项或数据结构
       }
   }
   

3. 数据流

   数据流是数据结构在系统内传输的路径；

   数据流描述 = {
       数据流名，
       说明，
       数据流来源，
       数据流去向，
       组成： {
           数据结构，
       }，
       平均流量，
       高峰期流量，
   }
   

4. 数据存储

   数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一，它可以是手工文档或者手工凭单，也可以是计算机文档。

   数据存储描述 = {
       数据存储名，
       说明，
       编号，
       输入的数据流，
       输出的数据流，
       组成： {
           数据结构，
       }，
       数据量，
       存取频度，
       存取方式，
   }
   

   其中，存取方式是指批处理还是联机处理，是检索还是更新，是顺序检索还是随即检索等。

5. 处理过程

   处理过程的具体处理逻辑一般用判定表或者是判定树来描述，数据字典中只需要描述处理过程的说明性信息即可。

   处理过程描述 = {
       处理过程名，
       说明，
       输入： {数据流}，
       输出： {数据流}，
       处理： {简要说明}，
   }
   

   其中，简要说明主要说明该处理过程的功能以及处理要求；

   功能是指该处理过程用来做什么；

   处理要求指的是处理频度要求；

最后强调两点：

1. 需求分析阶段的一个重要而又困难的任务是：收集将来应用所涉及的数据，设计人员应充分考虑到可能的扩充和改变，使设计易于更改、系统易于扩充。

2. 必须强调用户的参与，这是数据库应用系统设计的特点。

7.3 概念结构设计

将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程就是概念结构设计。

7.3.1 概念模型

概念模型的主要特点是：

1. 能够真实的、充分的反映现实世界，包括事物与事物之间的联系，能够满足用户对数据的处理要求，是现实世界的一个真实模型。

2. 易于理解，可以用它和不熟悉计算机的用户交换意见。

3. 易于更改。

4. 易于向关系、网状、层次等各种数据模型转换。

描述概念模型的有力工具是E-R模型。

7.3.2 E-R模型

E-R模型是用E-R图来描述现实世界的概念模型，包括实体、属性、实体之间的联系等等。

1. 实体之间的联系：

   在现实世界中，事物内部以及事物之间是有联系的，实体内部的联系通常是指组成实体的各属性之间的联系，实体之间的联系通常是指不同实体类型的实体集之间的联系。

   1. 两个实体型之间的联系

      1. 一对一联系

         比如一个班长对应一个班级，一个班级只有一个班长。

      2. 一对多联系

         比如一个班级中有多名学生，一个学生只有一个班级。

      3. 多对多联系

         例如一个学生可以选修多门课程，一门课程可以有多个学生选修。

      

   2. 两个以上的实体型之间的联系

      一般的，两个以上的实体型之间也存在着一对一、一对多、多对多的联系。

      例如，一门课有若干个老师讲授，一个老师讲一门课，一门课又有多本参考书。

      再例如，一个供应商提供多种零件，一个零件可由不同的供应商提供，一个项目可能需要不同供应商的不同零件。

      

   3. 单个实体型内部的联系

      同一个实体集内部也可以存在一对一、一对多、多对多的联系。

      例如，在职工实体型内部同时具有领导和被领导的联系。

   一般的，把参与联系的实体型的数目称为联系的度，两个实体型之间的联系度为2，也称为二元联系，同理，有三元联系、N元联系。

2. E-R图

   E-R图提供了表示实体型、属性和联系的方法

   1. 实体型用矩形表示
   2. 属性用椭圆形表示
   3. 联系用菱形表示（注明1:1、1:n、m:n）
      如果一个联系具有属性，这些属性也要用无向边与该联系连接起来。

   

3. 一个实例

   • 仓库：属性有仓库号、面积、电话号码；
   • 零件：属性有零件号、名称、规格、单价、描述
   • 供应商：属性有供应商号、姓名、地址、电话号码、账号
   • 项目：属性有项目号、预算、开工日期
   • 职工：属性有职工号、姓名、年龄、值称

   仓库和零件之间是多对多的联系；

   职工和仓库是一对多的关系；

   职工实体型中有一对多的关系（领导与被领导）；

   供应商、项目、零件之间有多对多的联系；

   

7.3.5 概念结构设计

本节介绍在设计E-R图的过程中，如何让确定实体与属性，以及在集成E-R图时如何让解决冲突等关键技术。

概念结构设计的第一步是对需求分析阶段收集到的数据进行分类、组织，确定实体、实体的属性、实体之间联系的类型，形成E-R图。

1. 实体与属性的划分原则

   一条基本原则：为了简化E-R图的处置，现实世界的事物能作为属性对待的尽量作为属性对待。

   满足下面两个条件的事物可以作为属性对待：

   1. 作为属性，不能再拥有需要描述的性质（即属性必须是不可分的数据项，不能包含其他属性）；
   2. 属性不能与其他实体具有联系；

   举例：

   

   

2. E-R图的集成

   在开发一个大型的系统时，首先设计各分系统的ER图，然后将他们集成起来，得到全局ER图，ER图的集成一般需要分两步走：

   • 合并，解决各分ER图的冲突，将分ER图合并起来形成初步的ER图。
   • 修改和重构，消除不必要的冗余，生成基本ER图。

   1. 合并ER图，生成初步ER图：

      各个子系统的ER图会存在一些不一致的地方，称之为冲突，合并ER图的过程中要消除这些冲突。

      各个子系统之间的ER图的冲突主要有三类：属性冲突、命名冲突、结构冲突。

      1. 属性冲突主要包含以下两类：

         1. 属性域冲突，即属性的值的类型，或者取值范围取值集合不同；
         2. 属性取值单位冲突；

      2. 命名冲突主要包含以下两类：

         1. 同名异义：不同意义的对象再不同的局部应用中具有相同的名字；
         2. 异名同义：同一意义的对象再不同的局部应用中具有不同的名字；

         命名冲突可能发生在实体、联系一级上，也可能发生在属性一级上。

      3. 结构冲突

         结构冲突主要包含以下三类冲突：

         1. 同一个对象在不同的应用中具有不同的抽象，例如职工在某一局部应用中被当作实体，而在另一局部应用中被当作属性。

         2. 同一实体在不同子系统的ER图中所包含的属性个数和属性排列次序不完全相同；这种冲突产生的原因是不同的局部应用关心实体的不同侧面，解决方案是取属性的并集在调整属性的次序。

         3. 实体之间的联系类型在不同的ER图中为不同的类型。

   2. 消除不必要的冗余，设计基本ER图

      在初步ER图中可能会存在一些冗余的数据和实体之间冗余的联系，冗余的数据指的是可以由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，消除的冗余后的初步ER图被称为基本ER图。

      消除冗余数据主要采用分析的方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。

      不过，并不是所有的冗余数据和冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。

      如果认为的保留了一些冗余数据，则应该把数据字典中数据关联的说明作为完整性约束条件。

      除了使用分析的方法之外，还可以利用规范化理论来消除冗余，在规范化理论中，函数依赖的概念提供了消除冗余联系的形式化工具，具体方法如下：

      • 确定分ER图实体之间的数据依赖，实体之间的联系可以用实体码之间的函数依赖来表示，于是就可以求得函数依赖集$F_L$FL​。
      • 求得$F_L$FL​的最小覆盖$G_L$GL​，差集为$D = F_L - G_L$D=FL​−GL​，逐一考察$D$D中的函数依赖，确定是否是冗余的联系，如果是，就将其去掉。

7.4 逻辑结构设计

逻辑结构设计的任务是把概念结构设计阶段设计好的基本ER图转化为与选用的数据库管理系统产品所支持的数据模型相符合的逻辑结构。

7.4.1 E-R图向关系模型的转换

需要解决的问题是，如何将实体型和实体型之间的联系转换为关系模式，如何确定这些关系模式的属性和码。

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

对于实体型之间的联系有以下不同的情况：

• 一个$1:1$1:1的联系可以转换为一个独立的关系模式，也可以与任意一端的关系模式合并。

  如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。

  如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。

• 一个$1:n$1:n的关系模式可以转换为一个独立的关系模式，也可以与n段对应的关系模式合并。

  如果要转换为独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。

• 一个$n:m$n:m的联系转换为一个关系模式，与该联系相连的各实体的码和联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系的码的一部分。

• 三个或三个以上的实体之间的联系可以转换为一个关系模式，属性和码的组成同上。

• 具有相同的码的关系模式可以合并

7.4.2 数据模型的优化

数据库逻辑设计的结果不是唯一的，为了提高数据库应用系统的性能，还应该根据应用适当的修改、调整数据模型的结构，这就是数据模型的优化。

关系数据模型的优化通常以规范化理论为指导，方法为：

1. 确定数据依赖（7.2.3）

2. 对各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系（7.3.5）

3. 按照数据以来理论对关系模式逐一进行分析，考察是否存在部分函数依赖，传递函数依赖，多值依赖等，确定各个关系模式分别属于第几范式。

4. 根据需求分析阶段得到的处理要求分析对于这样的应用环境这些关系模式是否合适，确定是否要对某些模式进行合并或分解。

   需要注意的是，并不是规范化程度越高的关系就越优，例如，当查询涉及多个关系模式的属性时，需要进行连接运算，代价是相当高的，这时候可以将经常需要连接的关系模式合并；又例如，非BCNF的关系模式虽然从理论上来京会存在不同程度的更新异常或者冗余，但是如果在实际应用中只涉及查询，不涉及更新，就不会产生影响。

5. 对关系模式进行必要的分解，以提高数据操作效率和数据存储效率，常用的分解方法是水平分解和垂直分解。

   水平分解是把关系的元组分为若干子集，然后为每一个子集定义一个关系。

   垂直拆分是把关系的属性分为若干子集，形成若干子关系模式。

   看他人博客

7.4.3 设计用户子模式

将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体的关系数据库管理系统的特点设计用户的外模式。

主要有以下几方面：

• 使用更符合用户习惯的别名
• 可以针对不同级别的用户，定义不同的视图，以保证系统的安全性
• 简化用户对系统的使用，如果某些局部应用中需要用到某些很复杂的查询，为了方便用户，可以将这些复杂的查询定义为视图，每次用户只需要对视图进行查询。

7.5 物理结构设计

数据库在物理设备上的存储结构和存取方法被称为数据库的物理结构，他依赖于选定的数据库管理系统。

为一个给定的逻辑数据模型选取一个最合适应用要求的物理结构的过程，就是数据库的物理设计。

数据库的物理设计通常分为两步：

• 确定数据库的物理结构，在关系数据库中主要是指存取方法和存储结构
• 对物理结构进行评价，主要是时间和空间的效率

7.5.1 数据库物理设计的方法和内容

没有通用的物理设计方法可以遵循，只能给出一般的设计内容和原则。

我们希望数据库上运行的各种事物响应时间小，存储空间利用率高，事物吞吐率大。

为此，首先要对运行的事务进行详细分析，获得所需参数；其次，要充分了解所用关系数据库管理系统的内部特征，特别是系统提供的存取方法和存储结构。

通常关系数据库物理设计的主要内容包括：为关系模式选择存取方法，以及设计关系、索引等数据库文件的物理存储结构。

7.5.2 关系模式存取方法的选择

数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。

物理设计的任务之一就是根据关系数据库管理系统支持的存取方法确定选择哪些存取方法。

存取方法是快速存取数据库中数据的技术。

常用的存取方法为索引方法和聚簇方法。

1. B+树索引存取方法

   • 如果一个或者一组属性经常在查询条件中出现，则考虑在这个或者这组属性上建立索引/组合索引。
   • 如果一个索引经常作为聚集函数的参数，则考虑建立索引
   • 如果一个或者一组属性经常在连接操作的连接条件中出现，则考虑建立索引

   查找、维护索引也要付出代价，因此索引并非越多越好。

2. Hash索引存取方法

   如果一个关系的属性主要出现在等值连接条件或者等值比较选择条件中，并且满足以下两个条件之一，就可以考虑Hash。

   • 一个关系的大小可以预知，而且不变
   • 关系的大小动态改变但是数据库管理系统有动态hash存取方法

3. 聚簇存取方法

   为了提高某个属性或属性组的查询速度，把在这些属性上有相同值的元组集中存放在 连续的物理块中，称为聚簇，该属性或属性组称为聚簇码。

   聚簇功能不但适用于单个关系，也适用于经常进行连接操作的多个关系，即将多个连接关系的元组按连接属性值聚集存放，也就相当于把多个关系按预连接的形式存放，从而大大提高连接操作的效率。

   一个数据库可以建立多个聚簇，但是一个关系只能加入一个聚簇。

   选择聚簇存取方法，即确定需要建立多少个聚簇，每个聚簇中包含哪些关系。

   候选聚簇的条件：

   • 经常在一起进行连接操作的关系。
   • 如果一个关系的一组属性经常出现在等值比较中，则该单个关系可以建立聚簇。
   • 如果一个关系的一个或者一组属性上的重复率很高，则此单个关系可以建立聚簇（换句话说，每个聚簇码值的平均元组数不能太少，否则聚簇的效果不明显）

   检查候选聚簇中的消息，取消其中不必要的关系：

   • 删除经常进行全表扫描的关系
   • 删除更新操作远多于连接操作的关系
   • 一个关系只能在一个聚簇中，如果有多个聚簇方案，要从中选择最优的一个

   需要强调的是：聚簇只能够提高某些应用的性能，而建立与维护聚簇的开销是相当大的；对已有的关系建立聚簇，将改变某些元组的物理储存位置，并使其原有的索引无效；而当一个元组的聚簇码改变时，也要做相应的物理储存位置移动。

   因此，当通过聚簇码进行访问或者连接是该关系的主要应用，对与聚簇码无关的访问很少或者次要时，可以使用聚簇，尤其是当SQL中包含与聚簇码有关的order by, group by, union, distinct等子句时，使用聚簇特别有利。

7.5.3 确定数据库的存储结构

确定数据库的物理结构主要指的是确定数据的存放位置和存储结构，包括确定关系，索引，日志，备份等的存储安排和存储结构，确定系统配置等。

确定数据库的存放位置和存储结构要综合考虑存取时间，存储空间利用率，维护代价三方面因素，在三者之间进行权衡。

1. 确定数据的存放位置

   为了提高应用性能，应该根据应用情况将数据的易变部分与稳定部分、经常存取的部分和存取频率较低的部分分开存放。

2. 确定系统配置

   关系数据库管理系统一般都提供了一些系统配置变量和存储分配参数（比如同时使用的用户数，同时打开的数据库的数量，缓冲区分配参数，……），供设计人员和数据库管理员对数据库进行物理优化，初始情况下，这些变量都有合理的默认值，但在进行物理设计时，应该根据应用的具体环境，重新设置这些变量，以改善系统性能。

   在设计阶段对系统配置变量的调整只是初步的，在系统运行时还要根据实际运行情况进行进一步调整。

7.5.4 评价物理结构

在数据库物理设计过程中，需要对时间效率、空间效率、维护代价（定量），以及各种用户需求进行权衡，从中可能产生多种方案，需要从中择优选择。

7.6 数据库的实施和维护

完成物理结构设计，实现设计之后，就可以组织数据入库，进入实施阶段。

7.6.1 数据的载入和应用程序的调试

标题是数据库实施阶段两项重要工作$\Uparrow$⇑。

一般数据库系统中的数据量都很大，可能来自部门中各个不同的单位，数据的组织方式，组织结构都会与新设计的系统存在相当大的差距；因此需要抽取数据、输入计算机、分类转换的过程，这是相当费时费力的。

特别是对于手工处理的纸上的数据。。。

为了提高数据输入工作的效率和质量，应当针对具体的应用环境设计一个数据录入子系统，有计算机完成数据录入的任务（重要！！！）。

特别的，如果就的数据存在于另一个数据库系统中，可以充分利用新旧系统提供的数据转换工具。

数据库系统的设计和数据库应用程序的设计应当同时进行，因此在组织数据入库的时候还要同时进行应用程序的调试。

7.6.2 数据库的试运行

在已经有一小部分数据入库之后，就可以进行数据库系统的联合调试，又称数据库的试运行。

功能测试：

• 实际运行数据库应用程序
• 执行数据库的各种操作
• 测试应用程序的功能是否满足设计要求

性能测试：

• 实际测量系统的性能指标

如果以上测试不满足要求，则需要返回物理设计阶段甚至逻辑设计阶段。

强调两点：

1. 数据入库花费很大，应当分批进行，逐步增加数据量，逐步完成运行篇评价。
2. 试运行阶段，由于系统不稳定、操作人员不熟悉，随时有可能发生硬软件故障，因此要做好数据库的转储和恢复工作。

7.6.3 数据库的运行和维护

试运行合格之后，数据库的开发工作就基本完成，可以投入正式运行了。

不过，由于应用环境的不断变化，数据库在运行过程中物理储存也会不断变化，对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。

数据库的维护工作主要包括一下几个方面：

1. 数据库的转储和恢复（vital!）

   针对不同的应用要求制定不同的转储计划，保证一旦发生故障能将数据湖库恢复到某种一致的状态，并尽可能的减少破坏。

2. 数据库的安全性、完整性控制

   运行过程中，安全性要求（如密级），完整性要求会发生变化，需要管理员的不断修正。

3. 数据库性能的监督、分析和改造

   监督系统运行，分析监测数据，找出改进性能的方法；

   数据库管理员可以充分利用数据库管理系统提供的系统性能检测工具；

   仔细分析监测数据，判断当前状况是否最佳，应当进行那些改进。

4. 数据库的重组织与重构造

   数据库在运行一段时间之后，由于记录不断的增删改，会改变数据库的物理存储情况，降低存取效率，降低数据库性能；这时候管理员就应当对数据库进行重组织或部分重组织（对频繁增删改的表进行重组织）。

   关系数据库管理系统一般提供数据重组织的实用程序。

   在重组织的过程中，按原来的设计要求重新安排存储位置、回收垃圾、减少指针链等，提高性能。

   数据库重构指的是部分修改数据库的模式和内模式。

   由于数据库应用环境发生变化，增加了新的应用或者实体，取消了某些应用，某些实体与实体之间的联系也发生了变化等，使得原有的设计不能满足要求，需要调整模式和内模式。

   如果应用变化太大，重构也无济于事，说明该换新的了。