第七章 数据库设计

第七章 数据库设计

7.1 数据库设计概念

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

7.1.1 数据库设计的特点

1. 数据库建设的基本规律
   • 三分技术，七分管理，十二分基础数据
   • 管理
     • ​ 数据库建设项目管理和企业（应用部门）的业务管理
   • 基础数据
     • 数据的收集，整理，组织和不断更新
2. 结构(数据)设计和行为(处理)设计相结合

7.1.2 数据库设计方法

大型数据库设计是涉及多学科的综合性技术，又是一项庞大的工程项目。它要求从事数据库设计的专业人员具备多方面的知识和技术。主要包括：

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

1. 手工与经验结合的方法
   • 存在的问题
     • 设计质量与设计人员的经验和水平有直接关系。
     • 缺乏科学理论和工程方法的支持，工程的质量难以保证
     • 数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价。
2. 规范设计法
   1. 基本思想：过程迭代和逐步求精
   2. 典型方法
      1. 新奥尔良（New Orleans）方法）
      2. 基于E-R模型的数据库设计方法）
      3. 3NF（第三范式）的设计方法
      4. 面向对象的数据库设计方法
      5. 统一建模语言（UML）方法

7.1.3 数据库设计的基本步骤

数据库设计阶段

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

• 需求分析和概念结构设计可以独立于任何数据库管理系统进行，
• 逻辑结构设计和物理结构设计与选用的数据库管理系统密切相关。

• 参加数据库设计的人员

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

• 各阶段的主要任务

  • 需求分析阶段：
    • 了解用户需求，该阶段是否做得充分与准确，决定了构建数据库的速度和质量。
  • 概念结构设计阶段：
    • 对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型
  • .逻辑结构设计阶段：
    • 将概念结构转换为数据库管理系统所支持的数据模型，并对其进行优化。
  • 物理结构设计阶段：
    • 逻辑数据结构选取一个最合应用环境的物理结构，包括存储结构和存取方法。
  • 5.数据库实施阶段：
    • 根据逻辑设计和物理设计的结果构建数据库，编写与调试应用程序，组织数据入库并进行试运行。
  • 数据库运行和维护阶段：
    • 经过试运行后即可投入正式运行，在运行过程中必须不断对其进行评估、调整与修改。

• 各个阶段的数据设计描述

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

7.2 需求分析

7.2.1 需求分析的任务

1. 详细调查现实世界要处理的对象（组织、部门、企业等）。

2. 充分了解原系统（手工系统或计算机系统）工作概况。

3. 明确用户的各种需求。

4. 确定新系统的功能，新系统必须充分考虑今后可能的扩充和改变。

   【说明】

   调查的重点是“数据”和“处理”，获得用户对数据库在信息、处理、安全性与完整性的要求。

7.2.2 需求分析的方法

• 需求分析的目的：
  • 调查清楚用户的实际需求并进行初步分析最终与用户达成共识。
• 调查用户需求的步骤：
  • 调查组织机构情况。
  • 调查各部门的业务活动情况。
  • 协助用户明确对新系统的各种要求，包括信息要求、处理要求，安全性与完整性要求。
  • 确定新系统的边界。
• 常用的调查方法有：
  • 跟班作业。通过亲身参加业务工作来了解业务活动的情况。
  • 开调查会。通过与用户座谈来了解业务活动情况及用户需求。
  • 请专人介绍。
  • 询问。对某些调查中的问题可以找专人询问。
  • 设计调查表请用户填写。如果调查表设计得合理，这种方法是很有效的。
  • 查阅记录。查阅与原系统有关的数据记录。

7.2.3 数据字典

数据字典是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典是在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善的。它在数据库设计中占有很重要的地位。

---

数据字典

• 数据项
  • 是不可在分的数据单位
  • 数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}
  • 其中，“取值范围”、“与其他数据项的逻辑关系”（如该数据项等于其他几个数据项的和、该数据项值等于另一数据项的值等)定义了数据的完整性约束条件，是设计数据检验功能的依据。
  • 可以用关系规范化理论为指导，用数据依赖的概念分析和表示数据项之间的联系。
• 数据结构
  • 反映了数据之间的组合关系
  • 数据结构描述={数据结构名，含义说明，组成：{数据项或数据结构}}
  • 一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。
• 数据流
  • 是数据结构在系统内传输的路径。
  • 数据流描述={数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}
  • 数据流来源：
    • 是说明该数据流来自哪个过程；
  • 数据流去向：
    • 是说明该数据流将到哪个过程去；
    • 平均流量：
      • 是指在单位时间（每天、每周、每月等）里的传输次数；
    • 高峰期流量：
      • 则是指在高峰时期的数据流量。
• 数据存储
  • 是数据结构停留或保存的地方，也是数据流的来源和去向之一
  • 数据存储描述={数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}
  • 存取频度：
    • 指每小时、每天或每周存取次数及每次存取的数据量等信息；
  • 存取方式：
    • 指是批处理还是联机处理、是检索还是更新、是顺序检索还是随机检索等；
  • 输入的数据流：
    • 数据来源；
  • 输出的数据流：
    • 数据去向。
• 处理过程
  • 处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息即可
  • 处理过程描述={处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}
  • “简要说明”说明该处理过程的功能及处理要求。其中功能是指该处理过程用来做什么。处理要求是指处理频度要求，如单位时间里处理多少事务，多少数据量、响应时间要求等。

7.3 概念结构设计

7.3.1 概念模型

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

• 概念模型的特点
  • 能真实、充分地反映现实世界，是现实世界的一个真实模型。
  • 易于理解，可以用它和不熟悉计算机的用户交换意见。
  • 易于更改，当应用环境和应用要求改变时容易对概念模型修改和扩充。
  • 易于向关系、网状、层次等各种数据模型转换。

7.3.2 E-R模型

• E-R图
  • E-R图提供了表示实体型，属性和联系的方法
  • 实体型
    • 用矩形表示，矩形框内写明实体名
  • 属性
    • 用椭圆形表示，并用无向边将其与相应的实体型连接起来
  • 联系
    • 用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1：1、1:n或m:n)。

7.3.3 扩展的E-R模型

1. 分类属性

   1. 根据分类属性的值把父实体型中的实体分派到子实体型中。

2. 不相交约束与可重叠约束

   1. 不相交约束
      • 父类中的一个实体不能同时属于多个子类中的实体集，即一个父类中的实体最多属于一个子类实体集。用ISA联系三角形符号内加一个“x”来表示。
   2. 可重叠约束
      • 父类中的一个实体能同时属于多个子类中的实体集，三角形符号内没有“X”来表
   3. 完备性约束
      • 完备性约束描述父类中的一个实体是否必须是某一个子类中的实体，如果是，则叫做完全特化(total specialization)，否则叫做部分特化(partial specialization)。
      • 完全特化用父类到子类的双线连接来表示，单线连接则表示部分特化。
   4. 基数约束
      • 基数约束是对实体之间一对一、一对多和多对多联系的细化。
      • 参与联系的每个实体型用基数约束来说明实体型中的任何一个实体可以在联系中出现的最少次数和最多次数。
      • 约束用一个数对min…max表示，0≤min≤max。
      • min=1的约束叫做强制参与约束，即被施加基数约束的实体型中的每个实体都要参与联系。
      • min=0的约束叫做非强制参与约束，即被施加基数约束的实体可以出现在联系中，也可以不出现在联系中。

3. ISA联系

   • 用E-R方法构建一个项目的模型时，经常会遇到某些实体型是某个实体型的子类型。例如，研究生和本科生是学生的子类型，学生是父类型。这种父类-子类联系称为ISA联系，表示“is a”的语义。例如，图7.12中研究生is a学生，本科生is a学生。ISA联系用三角形来表示。

4. Part-of联系

   • 即部分联系，表明某个实体型是另外一个实体型的一部分。
   • 非独占的Part-of联系：
     • 整体实体如果被破坏，部分实体仍然可以独立存在。非独占的Part-of联系可以通过基数约束 ，来表达。
   • 独占的Part-of联系：
     • 实体如果被破坏，部分实体不能存在。在E-R图中用弱实体类型和识别联系来表示独占联系。
     • 如果一个实体型的存在依赖于其他实体型的存在，则这个实体型叫做弱实体型，否则叫做强实体型。
     • 判断方法：如果不能从一个实体型属性中找出可以作为码的属性，这个实体型是弱实体型。
     • 在E-R图中用双矩形表示弱实体型，用双菱形表示识别联系。

7.3.4 UML

UML表示E-R图的说明

• ·实体型：
  • 用类表示，矩形框中实体名放在上部，下面列出属性名。·
• 实体的码：
  • 在类图中在属性后面加“PK”（primary key）来表示码属性。·
• 联系：
  • 用类图之间的“关联”来表示。

7.3.5 概念结构设计

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

• 实体与属性的划分原则

  • 为了简化E-R图的处置，现实世界的事物能作为属性对待的尽量作为属性对待。

• 两条准则

  • 作为属性，不能再具有需要描述的性质，即属性必须是不可分的数据项，不能包含其他属性。
  • 属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。

• E-R图的集成

  • E-R图 的集成一般需要分两步
    • 合并
      • 解决各分E-R图之间的冲突，将分E-R图合并来生成初步E-R图。
    • 修改和重构。
      • 消除不必要的冗余，生成基本E-R图

• 冲突

  • 属性冲突
    • 属性域冲突，即属性值的类型、取值范围或取值集合不同。
    • 属性取值单位冲突
  • 命名冲突
    • 同名异义
    • 异名同义(一义多名)
    • 命名冲突
  • 结构冲突
    • 同一对象在不同应用中具有不同的抽象
      • 解决方法通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。但变换时仍要遵循7.3.5小节中讲述的两个准则。
    • ·同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同。
      • 原因是不同的局部应用关心的是该实体的不同侧面。
      • 解决方法是使该实体的属性取各子系统的E-R图中属性的并集，再适当调整属性的次序。·
    • 实体间的联系在不同的E-R图中为不同的类型。
      • 解决方法是根据应用的语义对实体联系的类型进行综合或调整。

• 消除不必要的冗余，设计基本E-R图

  • 所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。
  • 消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
  • 但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。

• 用规范化理论来消除冗余

  • 确定分E-R图实体之间的数据依赖。

  • $求FL的最小覆盖G_L，差集为D=F_z-G_L。$

  • 冗余的联系一定在D中，而D中的联系不一定是冗余的。

    当实体之间存在多种联系时，要将实体之间的联系在形式上加以区分。

• 集成过程需解决以下问题

  • 异名同义
  • 取消冗余联系

7.4 逻辑结构设计

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

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

E-R图向关系模型的转换就是将实体型、实体的属性和实体型之间的联系转化为关系模式。

• 转换原则
  • 一个实体型转换为一个关系模式，关系的属性就是实体的属性，关系的码就是实体的码。
• 实体间的联系
  • 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
    • 转换为一个独立的关系模式
      • 关系的属性：与该联系相连的各实体的码及联系本身的属性
      • 关系的候选码：每个实体的码均是该关系的候选码
    • 与某一端实体 对应的关系模式合并
      • 合并后关系的属性：加入对应关系的码和联系本身的属性
      • 合并后关系的码：不变
  • 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并
    • 转换为一个独立的关系模式
      • 关系的属性：与该联系相连的各实体的码和联系本身的属性
      • 关系的候选码：n端实体的码
    • 与n端对应的关系模式合并
      • 合并后的关系属性：在n端关系中加入1端关系的码和联系本身的属性
      • 合并后关系的码：不变
  • 一个m:n联系转换为一个关系模式
    • 关系的属性：与该联系相连的各实体的码及联系本身的属性
    • 关系的候选码：各实体码的组合
  • 三个或三个以上实体间的一个多元联系转换为一个关系模式。
    • 关系的属性：与该联系相连的各实体的码及联系本身的属性。
    • 关系的候选码：各实体码的组合。
  • 具有相同码的关系模式可合并。
    • 目的：减少系统中的关系个数。
    • 合并方法：
      • 第一步：将其中一个关系模式的全部属性加入到另一个关系模式中。
      • 第二步：去掉其中的同义属性（可能同名也可能不同名）
      • 第三步：适当调整属性的次序。

7.4.2 数据模型的优化

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

• 优化数据模型的优化

  1. 确定数据依赖。按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间的数据依赖。

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

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

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

     必须注意的是，并不是规范化程度越高的关系就越优。

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

     1. 水平分解
        • 把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系
        • 分解方法
          • 对符合80/20原则的，把经常使用的数据（约20%）水平分解出来，形成一个子关系。
          • 是使每个事务存取的数据对应一个子关系。
        • 垂直分解
          • 把关系模式R的属性分解为若干子集合，形成若若干子关系模式。
          • 分解原则：经常在一起使用的属性从R中分解出来形成一个关系模式。
          • 分解优点：可以提高某些事务的效率。
          • 分解缺点：可能使另一些事务不得不执行连接操作，降低了效率。
          • 适用范围：取决于分解后R上的所有事务的总效率是否得到了提高。
          • 分解方法：
            • 简单情况直观分解。
            • 复杂情况用第6章中的模式分解算法。
            • 垂直分解必须不损失关系模式的语义（保持无损连接性和保持函数依赖）。

7.4.3 设计用户子模式

​ 定义数据库全局模式主要是从系统的时间效率、空间效率、易维护等角度出发。

​ 定义用户外模式时可以注重考虑用户的习惯与方便。

• 使用更符合用户习惯的别名
• 针对不同级别的用户定义不不同的视图，以保证系统的安全性
• 简化用户对系统的使用

7.5 物理结构设计

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

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

设计步骤

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

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

• 所需参数

  • 对于数据库查询事务，需要得到如下信息：

    • ·查询的关系。
    • 查询条件所涉及的属性。
    • 连接条件所涉及的属性。
    • 查询的投影属性。

  • 对于数据更新事务，需要得到如下信息：

    • 被更新的关系。
    • 每个关系上的更新操作条件所涉及的属性。
    • 修改操作要改变的属性值。

  • 每个事务在各关系上运行的频率和性能要求

• 通常关系数据库物理设计的内容主要包括为

  • 关系模式选择存取方法，以及设计关系、索引等数据库文件的物理存储结构。

7.5.2 关系模式存取方法选择

• 常用存取方法
  • B+树索引存取方法
    1. 如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）。
    2. 如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引。
    3. 如果一个(或一组)属性经常在连接操作的连接条件中出现，则考虑在这个(或这组)属性上建立索引。
  • hash索引存取方法的选择
    • 选择hash存取方法的规则如下：如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一，则此关系可以选择hash存取方法。
      • 一个关系的大小可预知，而且不变。
      • 关系的大小动态改变，但数据库管理系统提供了动态hash存取方法。
  • 聚簇存取方法的选择
    • 为了提高某个属性(或属性组）的查询速度，把这个或这些属性上具有相同值的元组集中存放在连续的物理块中称为聚簇。该属性(或属性组）称为聚簇码(cluster key)。
    • 聚簇对于某些类型的查询，可以提高查询效率。
    • 在一个基本表上最多只能建立一个聚簇索引。
    • 聚簇索引的适用条件，
      • 一是很少对基表进行增删操作，
      • 二是很少对其中的变长列进行修改操作。
    • 选择聚簇存取方法
      • 设计候选聚簇
        • 对经常在一起进行连接操作的关系可以建立聚簇。如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇。如果一个关系的一个(或一组)属性上的值重复率很高，则此单个关系可建立聚簇
      • 检查候选聚簇中的关系，取消其中不必要的关系
        • 从聚簇中删除经常进行全表扫描的关系。
        • 从聚簇中删除更新操作远多于连接操作的关系。
        • 从聚簇中删除重复出现的关系，当一个关系同时加入多个聚簇时，必须从这多个聚簇方案(包括不建立聚簇)中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。

7.5.3 确定数据库的存储结构

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

​ 确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，因此需要进行权衡，选择一个折中方案。

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

7.5.4 评价物理结构

​ 对数据库物理设计过程中产生的多种方案进行评价，从中选择一个较优的方案作为数据库的物理结构。评

​ 价方法主要是定量估算各种方案的存储空间、存取时间、维护代价，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。

7.6 数据库的实施和维护

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

• 数据载入方法
  • 人工方法
  • 计算机辅助数据入库
• 应用程序的调试

7.6.2 数据库的试运行

​ 应用程序调试完成，并且已有一小部分数据入库后，就可以开始对数据库系统进行联合调试，也称数据库的试运行。

• 主要工作
  • 功能测试
  • 性能测试

7.6.3 数据库的运行和维护

主要工作

• 数据库的转储和恢复
• 数据库的安全性和完整性控制
• 数据库性能的监督，分析和改造
• 数据库的重组织与重构造