数据库系统 | 第七章 数据库设计

重点和难点

• 重点：

  掌握数据库设计步骤和数据库设计过程中的各级模式设计方法。特别是数据库概念结构的设计和逻辑结构的设计，这是数据库设计过程中最重要的两个环节。牢固掌握用E-R图来表示概念模型的方法，掌握E-R图的设计，E-R图向关系模型的转换。

• 难点：

  技术上的难点是E-R图的设计和数据模型的优化，包括对现实世界进行抽象的能力，提取实体、属性、实体型之间的联系，正确划分实体与属性的能力。如何把第6章关系数据理论与本章结合，用关系数据理论指导数据库的逻辑设计。真正的难点是理论与实际的结合。

数据库设计概述

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

数据库设计的特点

• 数据库建设的基本规律

  • 三分技术，七分管理，十二分基础数据
  • 管理
    • 数据库建设项目管理
    • 企业（即应用部门）的业务管理
  • 基础数据
    • 数据的收集、整理、组织和不断更新

• 结构（数据）设计和行为（处理）设计相结合

  • 将数据库结构设计和数据处理设计密切结合

• 结构和行为分离的设计

  • 传统的软件工程：重 行为设计
    忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策
  • 早期的数据库设计：重 结构设计
    致力于数据模型和数据库建模方法研究，忽视了行为设计对结构设计的影响

数据库设计方法

• 大型数据库设计是涉及多学科的综合性技术，又是一项庞大的工程项目。

• 它要求多方面的知识和技术。主要包括：

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

• 手工试凑法

  • 设计质量与设计人员的经验和水平有直接关系
  • 缺乏科学理论和工程方法的支持，工程的质量难以保证
  • 数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价

• 规范设计法

  • 手工设计方法
  • 基本思想
    过程迭代和逐步求精
  • 典型方法
    • 新奥尔良（New Orleans）方法
    • 基于E-R模型的数据库设计方法
    • 3NF（第三范式）的设计方法
    • 面向对象的数据库设计方法
    • 统一建模语言（UML）方法

数据库设计的基本步骤

• 数据库设计分6个阶段

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

• 需求分析和概念设计独立于任何数据库管理系统

• 逻辑设计和物理设计与选用的数据库管理系统密切相关

• 参加数据库设计的人员

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

1. 需求分析阶段
   是否做得充分与准确，决定了构建数据库的速度和质量

2. 概念结构设计阶段
   通过对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型

3. 逻辑结构设计阶段
   将概念结构转换为某个数据库管理系统所支持的数据模型，并对其进行优化

4. 物理结构设计阶段
   为逻辑数据结构选取一个最适合应用环境的物理结构
   包括存储结构和存取方法

5. 数据库实施阶段
   根据逻辑设计和物理设计的结果构建数据库
   编写与调试应用程序
   组织数据入库并进行试运行

6. 数据库运行和维护阶段
   经过试运行后即可投入正式运行
   在运行过程中必须不断对其进行评估、调整与修改

• 设计一个完善的数据库应用系统 往往是上述6个阶段的不断反复
• 这个设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程
• 把数据库的设计和对数据库中数据处理的设计紧密结合起来，将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计

需求分析

需求分析的任务

• 需求分析就是分析用户的要求

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

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

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

• 明确用户的各种需求

• 在此基础上确定新系统的功能

• 新系统必须充分考虑今后可能的扩充和改变

• 调查的重点是“数据”和“处理”，获得用户对数据库的要求
  （1）信息要求
  用户需要从数据库中获得信息的内容与性质
  由信息要求可以导出数据要求，即在数据库中需要存储哪些数据
  （2）处理要求
  用户要完成的处理功能
  对处理性能的要求
  （3）安全性与完整性要求

• 确定用户最终需求的难点

  • 用户缺少计算机知识，不能准确地表达自己的需求，他们所提出的需求往往不断地变化。
  • 设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求

• 解决方法

  设计人员必须不断深入地与用户进行交流，才能逐步确定用户的实际需求

需求分析的方法

• 调查清楚用户的实际需求并进行初步分析
• 与用户达成共识
• 分析与表达这些需求

（1）调查组织机构情况
（2）调查各部门的业务活动情况
（3）协助用户明确对新系统的各种要求，包括信息要求、处理要求、完全性与完整性要求
（4）确定新系统的边界

常用调查方法

（1）跟班作业
通过亲身参加业务工作了解业务活动的情况
（2）开调查会
通过与用户座谈来了解业务活动情况及用户需求
（3）请专人介绍
（4）询问
对某些调查中的问题，可以找专人询问
（5）设计调查表请用户填写
调查表设计合理，则很有效
（6）查阅记录
查阅与原系统有关的数据记录

• 分析方法
  • 结构化分析方法（Structured Analysis，简称SA方法）
    • SA方法从最上层的系统组织机构入手
    • 采用自顶向下、逐层分解的方式分析系统
• 对用户需求进行分析与表达后，需求分析报告必须提交给用户，征得用户的认可

数据字典

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

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

• 数据字典是进行详细的数据收集和数据分析所获得的主要结果

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

• 数据字典的内容

  • 数据项
  • 数据结构
  • 数据流
  • 数据存储
  • 处理过程

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

• 若干个数据项可以组成一个数据结构

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

需求分析小结

• 把需求收集和分析作为数据库设计的第一阶段是十分重要的。

• 第一阶段收集的基础数据（用数据字典来表达）是下一步进行概念设计的基础。

• 强调两点

  （1）设计人员应充分考虑到可能的扩充和改变，使设计易于更改，系统易于扩充
  （2）必须强调用户的参与

概念结构设计

概念模型

• 将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程就是概念结构设计
• 概念模型的特点
  （1）能真实、充分地反映现实世界，是现实世界的一个真实模型。
  （2）易于理解，从而可以用它和不熟悉计算机的用户交换意见。
  （3）易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。
  （4）易于向关系、网状、层次等各种数据模型转换
• 描述概念模型的工具
  • E-R模型

E-R模型

• 实体之间的联系
  两个实体型之间的联系：
  ①一对一联系（1∶1）
  ②一对多联系（1∶n）
  ③多对多联系（m∶n）

• 一对一联系（1∶1）

  • 如果对于实体集A中的每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1∶1。
  • 例如，学校里一个班级只有一个正班长，而一个班长只在一个班中任职，则班级与班长之间具有一对一联系。

• 一对多联系（1∶n）

  • 如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1∶n。
  • 例如，一个班级中有若干名学生，而每个学生只在一个班级中学习，则班级与学生之间具有一对多联系。

• 多对多联系（m∶n）

  • 如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中也有m个实体（m≥0）与之联系，则称实体集A与实体集B具有多对多联系，记为m∶n。
  • 例如，一门课程同时有若干个学生选修，而一个学生可以同时选修多门课程，则课程与学生之间具有多对多联系。

• 联系的度：参与联系的实体型的数目

  • 2个实体型之间的联系度为2，也称为二元联系；
  • 3个实体型之间的联系度为3，称为三元联系；
  • N个实体型之间的联系度为N，也称为N元联系

• E-R图

  • E-R图提供了表示实体型、属性和联系的方法：
    • 实体型：用矩形表示，矩形框内写明实体名。
    • 属性：用椭圆形表示，并用无向边将其与相应的实体型连接起来。
      例如，学生实体具有学号、姓名、性别、出生年份、系、入学时间等属性，用E-R图表示如图7.9所示

概念结构设计

• 实体与属性的划分原则
  • 为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。
  • 两条准则：
    • 作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。
    • 属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。

逻辑结构设计

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

• 转换内容

  • E-R图由实体型、实体的属性和实体型之间的联系三个要素组成
  • 关系模型的逻辑结构是一组关系模式的集合
  • 将E-R图转换为关系模型：将实体型、实体的属性和实体型之间的联系转化为关系模式

• 转换原则

  • 一个实体型转换为一个关系模式。
    • 关系的属性：实体的属性
    • 关系的码：实体的码
  • 实体型间的联系有以下不同情况
    一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
    ① 转换为一个独立的关系模式
    关系的属性：与该联系相连的各实体的码以及联系本身的属性
    关系的候选码：每个实体的码均是该关系的候选码
  • 联系形成的关系独立存在：
    职工（职工号，姓名，年龄）
    产品（产品号，产品名，价格）
    负责（职工号，产品号）
  • 一个1:1联系的转换（续）
    ②与某一端实体对应的关系模式合并
    合并后关系的属性：加入对应关系的码和联系本身的属性
    合并后关系的码：不变
  • “负责”与“职工”两关系合并：
    职工（职工号，姓名，年龄，产品号）
    产品（产品号，产品名，价格）
    也可以“负责”与“产品”两关系合并：
    职工（职工号，姓名，年龄）
    产品（产品号，产品名，价格，职工号）
  • 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
    ①转换为一个独立的关系模式
    关系的属性：与该联系相连的各实体的码以及联系本身的属性
    关系的码：n端实体的码
  • 联系形成的关系独立存在：
    仓库（仓库号，地点，面积）
    产品（产品号，产品名，价格）
    仓储（产品号，仓库号，数量）
  • 一个m:n联系转换为一个关系模式
    关系的属性：与该联系相连的各实体的码以及联系本身的属性
    关系的码：各实体码的组合
    [例]“选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码：
    　　 选修（学号，课程号，成绩）
  • 三个或三个以上实体间的一个多元联系转换为一个关系模式。
    关系的属性：与该多元联系相连的各实体的码以及联系本身的属性
    关系的码：各实体码的组合
  • 供应商（供应商号，供应商名，地址）
    零件（零件号，零件名，单价）
    产品（产品号，产品名，型号）
    供应（供应商号，零件号，产品号，数量）

数据模型的优化

• 一般的数据模型还需要向特定数据库管理系统规定的模型进行转换。

• 转换的主要依据是所选用的数据库管理系统的功能及限制。没有通用规则。

• 对于关系模型来说，这种转换通常都比较简单。

• 一般的数据模型还需要向特定数据库管理系统规定的模型进行转换。

• 转换的主要依据是所选用的数据库管理系统的功能及限制。没有通用规则。

• 对于关系模型来说，这种转换通常都比较简单。

• 优化数据模型的方法:
  （1）确定数据依赖
  按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。
  （2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。

  （3）按照数据依赖的理论对关系模式进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
  （4）按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。

  （5）对关系模式进行必要分解，提高数据操作效率和存储空间的利用率。

  • 常用分解方法

  • 水平分解

    • 什么是水平分解
      把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。

    • 如何分解

      对符合80/20的，把经常被使用的数据（约20%）
      水平分解出来，形成一个子关系。
      水平分解为若干子关系，使每个事务存取的数据对应一个子关系。

  • 垂直分解

    • 什么是垂直分解
      把关系模式R的属性分解为若干子集合，形成若干子关系模式。
    • 垂直分解的原则
      经常在一起使用的属性从R中分解出来形成一个子关系模式
    • 垂直分解的优点
      可以提高某些事务的效率
    • 垂直分解的缺点
      可能使另一些事务不得不执行连接操作，降低了效率

• 并不是规范化程度越高的关系就越优

  • 当查询经常涉及两个或多个关系模式的属性时，系统必须经常地进行连接运算
  • 连接运算的代价是相当高的
  • 因此在这种情况下，第二范式甚至第一范式也许是适合的。

• 非BCNF的关系模式虽然会存在不同程度的更新异常，但如果在实际应用中对此关系模式只是查询，并不执行更新操作，就不会产生实际影响。

• 对于一个具体应用来说，到底规范化进行到什么程度，需要权衡响应时间和潜在问题两者的利弊才能决定

设计用户子模式

• 定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。
• 定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：
  • （1）使用更符合用户习惯的别名
    合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。
    用视图机制可以在设计用户视图时可以重新定义某些属性名，使其与用户习惯一致，以方便使用。
  • （2）针对不同级别的用户定义不同的视图，以保证系统的安全性。
    假设有关系模式产品（产品号，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率，质量等级），可以在产品关系上建立两个视图：
    为一般顾客建立视图： 产品1（产品号，产品名，规格，单价）
    为产品销售部门建立视图： 产品2（产品号，产品名，规格，单价，车间，
    生产负责人）
  • （3）简化用户对系统的使用
  • 如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图。

物理结构设计

• 什么是数据库的物理设计

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

• 数据库物理设计的步骤

  • 确定数据库的物理结构
    在关系数据库中主要指存取方法和存储结构;
  • 对物理结构进行评价
    评价的重点是时间和空间效率
  • 若评价结果满足原设计要求，则可进入到物理实施阶段。否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。

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

• 设计物理数据库结构的准备工作

  • 充分了解应用环境，详细分析要运行的事务，以获得选择物理数据库设计所需参数。
  • 充分了解所用关系型数据库管理系统的内部特征，特别是系统提供的存取方法和存储结构。

• 选择物理数据库设计所需参数

  • 数据库查询事务
    • 查询的关系
    • 查询条件所涉及的属性
    • 连接条件所涉及的属性
    • 查询的投影属性
  • 数据更新事务
    • 被更新的关系
    • 每个关系上的更新操作条件所涉及的属性
    • 修改操作要改变的属性值
  • 每个事务在各关系上运行的频率和性能要求

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

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

关系模式存取方法选择

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

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

• 数据库管理系统常用存取方法

  • B+树索引存取方法
  • Hash索引存取方法
  • 聚簇存取方法

• 选择索引存取方法的主要内容

  • 根据应用要求确定
  • 对哪些属性列建立索引
  • 对哪些属性列建立组合索引
  • 对哪些索引要设计为唯一索引

• 选择索引存取方法的一般规则

  • 如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）
  • 如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引
  • 如果一个（或一组）属性经常在连接操作的连接条件中 出现，则考虑在这个（或这组）属性上建立索引

• 关系上定义的索引数过多会带来较多的额外开销

  • 维护索引的开销
  • 查找索引的开销

• 选择Hash存取方法的规则

  • 如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一
    • 该关系的大小可预知，而且不变；
    • 该关系的大小动态改变，但所选用的数据库管理系统提供了动态Hash存取方法。

• 什么是聚簇

  • 为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块中称为聚簇。该属性（或属性组）称为聚簇码（cluster key）
  • 许多关系型数据库管理系统都提供了聚簇功能
  • 聚簇存放与聚簇索引的区别

• 聚簇索引

  • 建立聚簇索引后，基表中数据也需要按指定的聚簇属性值的升序或降序存放。也即聚簇索引的索引项顺序与表中元组的物理顺序一致。
  • 在一个基本表上最多只能建立一个聚簇索引

• 聚簇索引的适用条件

  • 很少对基表进行增删操作

  • 很少对其中的长列进行修改操作

• 聚簇的用途
  对于某些类型的查询，可以提高查询效率

  1. 大大提高按聚簇属性进行查询的效率
     [例] 假设学生关系按所在系建有索引，现在要查询信息系的所有学生名单。
     计算机系的500名学生分布在500个不同的物理块上时，至少要执行500次I/O操作。
     如果将同一系的学生元组集中存放，则每读一个物理块可得到多个满足查询条件的元组，从而显著地减少了访问磁盘的次数。
  2. 节省存储空间
     聚簇以后，聚簇码相同的元组集中在一起了，因而聚簇码值不必在每个元组中重复存储，只要在一组中存一次就行了。

• 聚簇的局限性

  • 聚簇只能提高某些特定应用的性能
  • 建立与维护聚簇的开销相当大
    • 对已有关系建立聚簇，将导致关系中元组的物理存储位置移动，并使此关系上原有的索引无效，必须重建。
    • 当一个元组的聚簇码改变时，该元组的存储位置也要做相应改变。

• 聚簇的适用范围

  • 既适用于单个关系独立聚簇，也适用于多个关系组合聚簇
  • 当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的时，可以使用聚簇
    • 尤其当SQL语句中包含有与聚簇码有关的ORDER BY, GROUP BY, UNION, DISTINCT等子句或短语时，使用聚簇特别有利，可以省去或减化对结果集的排序操作

• 选择聚簇存取方法

  • 设计候选聚簇
    （1）常在一起进行连接操作的关系可以建立组合聚簇
    （2）如果一个关系的一组属性经常出现在相等比较条
    件中，则该单个关系可建立聚簇；
    （3）如果一个关系的一个（或一组）属性上的值重复
    率很高，则此单个关系可建立聚簇。

• 检查候选聚簇中的关系，取消其中不必要的关系
  （1）从聚簇中删除经常进行全表扫描的关系
  （2）从聚簇中删除更新操作远多于连接操作的关系
  （3）从聚簇中删除重复出现的关系

  当一个关系同时加入多个聚簇时，必须从这多个聚簇方案
  （包括不建立聚簇）中选择一个较优的，即在这个聚簇上
  运行各种事务的总代价最小。

确定数据库的存储结构

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

• 确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价3个方面的因素。

• 影响数据存放位置和存储结构的因素

  • 硬件环境
  • 应用需求
    • 存取时间
    • 存储空间利用率
    • 维护代价
  • 这三个方面常常是相互矛盾的

• 基本原则

  • 根据应用情况将
    • 易变部分与稳定部分分开存放
    • 经常存取部分与存取频率较低部分分开存放

• [例]

  • 可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。
  • 可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。

• 数据库管理系统一般都提供了一些存储分配参数

  • 同时使用数据库的用户数
  • 同时打开的数据库对象数
  • 内存分配参数
  • 缓冲区分配参数（使用的缓冲区长度、个数）
  • 存储分配参数
  • 物理块的大小
  • 物理块装填因子
  • 时间片大小
  • 数据库的大小
  • 锁的数目等

• 系统都为这些变量赋予了合理的缺省值。在进行物理设计时需要根据应用环境确定这些参数值，以使系统性能最优。

• 在物理设计时对系统配置变量的调整只是初步的，要根据系统实际运行情况做进一步的调整，以切实改进系统性能。

评价物理结构

• 对数据库物理设计过程中产生的多种方案进行评价，从中选择一个较优的方案作为数据库的物理结构。
• 评价方法
  • 定量估算各种方案
    • 存储空间
    • 存取时间
    • 维护代价
  • 对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。

数据库的实施和维护

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

• 数据库结构建立好后，就可以向数据库中装载数据了。组织数据入库是数据库实施阶段最主要的工作。

• 数据装载方法

  • 人工方法
  • 计算机辅助数据入库

• 数据库应用程序的设计应该与数据设计并行进行

• 在组织数据入库的同时还要调试应用程序

• 应用程序的设计、编码和调试的方法、步骤在软件工程等课程中有详细讲解，这里就不赘述了

数据库的试运行

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

• 主要工作包括：

  • 功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。
  • 性能测试：测量系统的性能指标，分析是否符合设计目标。

• 数据库性能指标的测量

  • 数据库物理设计阶段在评价数据库结构估算时间、空间指标时，作了许多简化和假设，忽略了许多次要因素，因此结果必然很粗糙。
  • 数据库试运行则是要实际测量系统的各种性能指标（不仅是时间、空间指标），如果结果不符合设计目标，则需要返回物理设计阶段，调整物理结构，修改参数；有时甚至需要返回逻辑设计阶段，调整逻辑结构。

• 数据的分期入库

  • 重新设计物理结构甚至逻辑结构，会导致数据重新入库
  • 由于数据入库工作量实在太大，所以可以采用分期输入数据的方法
    • 先输入小批量数据供先期联合调试使用
    • 待试运行基本合格后再输入大批量数据
    • 逐步增加数据量，逐步完成运行评价

• 数据库的转储和恢复

  • 在数据库试运行阶段，系统还不稳定，硬、软件故障随时都可能发生
  • 系统的操作人员对新系统还不熟悉，误操作也不可避免
  • 因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏

数据库的运行和维护

• 在数据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成的，包括：

  1. 数据库的转储和恢复
     数据库管理员要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份。
     一旦发生介质故障，即利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态。

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

     • 初始定义
       数据库管理员根据用户的实际需要授予不同的操作权限
       根据应用环境定义不同的完整性约束条件
     • 修改定义
       当应用环境发生变化，对安全性的要求也会发生变化，数据库管理员需要根据实际情况修改原有的安全性控制
       由于应用环境发生变化，数据库的完整性约束条件也会变化，也需要数据库管理员不断修正，以满足用户要求

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

     • 在数据库运行过程中，数据库管理员必须监督系统运行，对监测数据进行分析，找出改进系统性能的方法。
       • 利用监测工具获取系统运行过程中一系列性能参数的值
       • 通过仔细分析这些数据，判断当前系统是否处于最佳运行状态
       • 如果不是，则需要通过调整某些参数来进一步改进数据库性能

  4. 数据库的重组织与重构造
     （1）数据库的重组织
     为什么要重组织数据库
     数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。

     • 重组织的形式

       • 全部重组织
       • 部分重组织
       • 只对频繁增、删的表进行重组织

     • 重组织的目标

       提高系统性能

     • 重组织的工作

       • 按原设计要求
         重新安排存储位置
         回收垃圾
         减少指针链
       • 数据库的重组织不会改变原设计的数据逻辑结构和物理结构

     • 数据库管理系统一般都提供了供重组织数据库使用的实用程序，帮助数据库管理员重新组织数据库。

     （2）数据库的重构造

     • 为什么要进行数据库的重构造
       • 数据库应用环境发生变化，会导致实体及实体间的联系也发生相应的变化，使原有的数据库设计不能很好地满足新的需求
         • 增加新的应用或新的实体
         • 取消某些已有应用
         • 改变某些已有应用

• 数据库重构造的主要工作

  • 根据新环境调整数据库的模式和内模式
    • 增加或删除某些数据项
    • 改变数据项的类型
    • 增加或删除某个表
    • 改变数据库的容量
    • 增加或删除某些索引

• 重构造数据库的程度是有限的

  • 若应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大，则表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库应用系统了。

小结

• 数据库的设计过程

  • 需求分析
  • 概念结构设计
  • 逻辑结构设计
  • 物理结构设计
  • 数据库实施
  • 数据库运行维护
  • 设计过程中往往还会有许多反复

• 数据库各级模式的形成

  • 需求分析阶段：综合各个用户的应用需求（现实世界的需求）。
  • 概念设计阶段：概念模式（信息世界模型），用E-R图来描述。
  • 逻辑设计阶段：逻辑模式、外模式。
  • 物理设计阶段：内模式。

• 概念结构设计

  • E-R模型的基本概念和图示方法
  • E-R模型的设计
  • 把E-R模型转换为关系模型的方法

• 在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。

• 然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图，形成数据的外模式

• 在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式

掘金：前端LeBron

知乎：前端LeBron

持续分享技术博文，关注微信公众号👇🏻