数据库设计

7.1 数据库设计概述

7.1.1 数据库和信息系统

数据库设计是指对于一个给定的应用环境，构造优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求（信息要求和处理要求）。其目标是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。

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

数据库是信息系统的核心和基础：

• 把信息系统中大量的数据按一定的模型组织起来
• 提供存储、维护、检索数据的功能
• 使信息系统可以方便、及时、准确地从数据库中获得所需的信息
• 数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在

数据库设计人员应具备的知识：

1. 数据库的基本知识和数据库设计技术
2. 计算机科学的基础知识和程序设计的方法和技巧
3. 软件工程的原理和方法
4. 应用领域的知识

7.1.2 数据库设计的特点

1. 三分技术，七分管理，十二分基础数据——数据库建设是硬件、软件和干件的结合。技术与管理的界面称为"干件"。

2. 数据库设计应与应用系统设计相结合：

   • 结构（数据）设计：设计数据库框架或数据库结构
   • 行为（处理）设计：设计应用程序、事务处理等

3. 传统设计的问题：

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

7.1.3 数据库设计方法

1. 手工与经验相结合方法

• 设计质量与设计人员的经验和水平有直接关系
• 缺乏科学理论和工程方法的支持，工程质量难以保证

2. 规范设计法

• 基本思想：过程迭代和逐步求精
• 典型方法：
  • 新奥尔良（New Orleans）方法：将数据库设计分为若干阶段和步骤
  • 基于E-R模型的数据库设计方法：概念设计阶段广泛采用
  • 3NF（第三范式）的设计方法：逻辑阶段可采用的有效方法
  • ODL（Object Definition Language）方法：面向对象的数据库设计方法

3. 计算机辅助设计

• 如 ORACLE Designer、SYBASE PowerDesigner

7.1.4 数据库设计的基本步骤

一、准备工作——选定参加设计的人员

角色	职责
数据库分析设计人员	设计核心人员，自始至终参与，其水平决定了数据库系统的质量
用户	主要参加需求分析和数据库运行维护，加速并提高数据库设计质量
程序员	系统实施阶段参与，负责编制程序
操作员	系统实施阶段参与，准备软硬件环境

二、设计过程的六个阶段

阶段	内容
1. 需求分析阶段	准确了解与分析用户需求（包括数据与处理），是整个设计过程的基础，是最困难、最耗费时间的一步
2. 概念结构设计阶段	对用户需求进行综合、归纳与抽象，形成独立于具体DBMS的概念模型。是整个数据库设计的关键
3. 逻辑结构设计阶段	将概念结构转换为某个DBMS所支持的数据模型，并对其进行优化
4. 数据库物理设计阶段	为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）
5. 数据库实施阶段	运用DBMS提供的语言和工具，建立数据库、编制与调试应用程序、组织数据入库并进行试运行
6. 数据库运行和维护阶段	系统投入正式运行，不断进行评价、调整与修改

设计过程中，结构和行为的设计在各个阶段同时进行、相互参照、相互补充。

数据库各级模式的形成过程

需求分析阶段  →  综合各个用户的应用需求
                      ↓
概念设计阶段  →  形成独立于机器和DBMS的概念模式（E-R图）
                      ↓
逻辑设计阶段  →  将E-R图转换为关系模型等逻辑模式，再建立视图（外模式）
                      ↓
物理设计阶段  →  进行物理存储安排，建立索引，形成内模式

7.2 需求分析

需求分析是设计数据库的起点，其结果是否准确反映了用户的实际要求，将直接影响后续所有阶段的设计。

7.2.1 需求分析的任务

一、任务：通过详细调查现实世界要处理的对象，充分了解原系统工作概况，明确用户的各种需求，在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变。

二、重点：调查、收集与分析用户在数据管理中的：

• 信息要求：用户需要从数据库中获得的信息内容与性质，由此导出数据要求（数据库中需要存储哪些数据）
• 处理要求：对处理功能、响应时间、处理方式（批处理/联机处理）的要求
• 安全性与完整性要求

三、难点：

• 用户缺少计算机知识，无法一下子准确表达需求，需求往往不断变化
• 设计人员缺少用户专业知识，不易理解甚至误解用户需求
• 新的硬件、软件技术出现也会使用户需求发生变化

解决方法：设计人员必须采用有效方法，与用户不断深入交流，逐步确定用户的实际需求。

7.2.2 需求分析的方法

一、调查与初步分析用户需求

1. 调查组织机构情况（组织部门的组成、职责等）
2. 调查各部门的业务活动情况（重点之一）：输入和使用什么数据、如何加工处理、输出什么信息、输出到什么部门、输出格式
3. 协助用户明确对新系统的各种要求（重点之二）：信息要求、处理要求、安全性与完整性要求
4. 对调查结果进行初步分析，确定新系统的边界（哪些由计算机完成、哪些由人工完成）

二、常用调查方法

1. 跟班作业：亲身参加业务工作，了解准确但耗时
2. 开调查会：通过与用户座谈了解情况
3. 请专人介绍
4. 询问：针对某些问题找专人询问
5. 设计调查表请用户填写：设计合理则很有效
6. 查阅记录：查阅与原系统有关的数据记录

三、分析与表达用户需求——SA方法

常用自顶向下的结构化分析方法（SA方法）：

1. 抽象系统：把任何系统抽象为数据流、数据存储和处理过程
2. 分解处理功能和数据：
   • 将处理功能逐层分解为若干子功能
   • 数据也逐级分解，形成若干层次的数据流图
   • 处理过程用判定表或判定树描述，数据用数据字典描述
3. 将分析结果再次提交用户征得认可

实例：学校管理系统 → 教师管理子系统、学生管理子系统、后勤管理子系统 → 学生管理子系统分解为学籍管理和课程管理。

7.2.3 数据字典

数据字典是各类数据描述的集合，是进行详细数据收集和数据分析的主要结果，在数据库设计中占有很重要的地位。

数据字典的内容

组成	描述
1. 数据项	不可再分的数据单位，最小组成单位
2. 数据结构	数据之间的组合关系（由数据项或数据结构组成）
3. 数据流	数据结构在系统内传输的路径
4. 数据存储	数据结构停留或保存的地方
5. 处理过程	对处理功能的简要说明

1. 数据项描述：

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

• 取值范围、与其他数据项的逻辑关系定义了数据的完整性约束条件

示例——"学号"：

• 含义说明：唯一标识每个学生
• 别名：学生编号
• 类型：字符型
• 长度：8
• 取值范围：00000000 至 99999999
• 取值含义：前两位标识年级，后六位按顺序编号

2. 数据结构描述：

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

示例——"学生"：组成 = {学号，姓名，性别，年龄，所在系，年级}

3. 数据流描述：

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

4. 数据存储描述：

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

• 存取方式：批处理/联机处理；检索/更新；顺序检索/随机检索

5. 处理过程描述：

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

• 简要说明包括功能和处理要求（处理频度、响应时间等），是后续物理设计的输入及性能评价标准

示例——"分配宿舍"：为所有新生分配宿舍，要求同一间宿舍只能安排同一性别学生，同一学生只能安排在一个宿舍中，每人居住面积不小于3平方米，处理时间不超过15分钟。

数据字典是元数据（关于数据的数据），而不是数据本身。它在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善。

7.3 概念结构设计

7.3.1 概念结构

概念结构设计是将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程。概念结构是各种数据模型的共同基础，比数据模型更独立于机器、更抽象、更稳定。概念结构设计是整个数据库设计的关键。

特点：

1. 能真实、充分地反映现实世界，包括事物和事物之间的联系
2. 易于理解，可以用它和不熟悉计算机的用户交换意见
3. 易于更改，当应用环境改变时容易修改和扩充
4. 易于向关系、网状、层次等各种数据模型转换

描述概念模型的工具：E-R模型

7.3.2 概念结构设计的方法与步骤

四类设计方法

方法	说明
自顶向下	首先定义全局概念结构框架，然后逐步细化
自底向上	首先定义各局部应用的概念结构，然后将它们集成得到全局概念结构
逐步扩张	首先定义核心概念结构，然后向外扩充（滚雪球方式）
混合策略	自顶向下设计框架，自底向上集成各局部结构

常用策略：自顶向下地进行需求分析，自底向上地设计概念结构。

自底向上设计概念结构的步骤：

1. 第1步：抽象数据并设计局部视图（分E-R图）
2. 第2步：集成局部视图，得到全局概念结构

7.3.3 数据抽象与局部视图设计

一、数据抽象

概念结构是对现实世界的抽象——从实际的人、物、事和概念中抽取所关心的共同特性，忽略非本质的细节。

三种常用抽象：

抽象	语义	E-R模型对应
分类（Classification）	"is member of"——对象值是型的成员	实体型
聚集（Aggregation）	"is part of"——类型由成分组成	若干属性聚集组成实体型
概括（Generalization）	"is subset of"——子集关系，子类继承超类的所有抽象	超类-子类实体型（E-R模型扩充）

数据抽象的用途：将需求分析阶段收集到的数据进行分类、组织（聚集），形成实体、实体的属性（含码）、实体之间的联系类型（1:1，1:n，m:n）。

二、局部视图设计——设计分E-R图的步骤

1. 选择局部应用

• 以中层数据流图作为设计分E-R图的依据（高层过粗，低层过细）
• 根据系统具体情况选择适当的数据流图层次

2. 逐一设计分E-R图

• 标定局部应用中的实体、属性、码以及实体间的联系
• 将各局部应用涉及的数据从数据字典中抽取出来

如何区分实体和属性：

• 实体与属性是相对而言的。同一事物在一种环境作为属性，在另一种环境可能作为实体
• 一般原则：
  1. 属性必须是不可分的数据项，不能再由另一些属性组成
  2. 属性不能与其他实体具有联系（联系只发生在实体之间）
  3. 符合上述两条的事物一般作为属性，能作为属性的尽量作为属性

举例：

• "学生"由学号、姓名等进一步描述 → 只能作为实体
• "职称"通常作为教师属性，但在涉及住房分配时（职称与住房实体有联系），应作为实体

学籍管理分E-R图实例：

主要实体：学生、宿舍、档案材料、班级、班主任

实体间的联系：

• 宿舍-学生：1:n（一个宿舍住多个学生）
• 班级-学生：1:n
• 班主任-学生：1:n
• 学生-档案材料：1:1
• 班级-班主任：1:1

调整后：因宿舍分配与性别有关，性别从属性改为实体。

各实体属性：

• 学生：{学号，姓名，出生日期}
• 性别：{性别}
• 档案材料：{档案号，……}
• 班级：{班级号，学生人数}
• 班主任：{职工号，姓名，性别，是否为优秀班主任}
• 宿舍：{宿舍编号，地址，人数}

课程管理分E-R图：

• 学生：{姓名，学号，性别，年龄，所在系，年级，平均成绩}
• 课程：{课程号，课程名，学分}
• 教师：{职工号，姓名，性别，职称}
• 教科书：{书号，书名，价钱}
• 教室：{教室编号，地址，容量}

7.3.4 视图的集成

集成方式

1. 一次集成：多个分E-R图一次合并（适用于局部视图较简单时）
2. 逐步累积式：先集成两个关键局部视图，以后每次集成一个新的

集成步骤

步骤1：合并分E-R图，生成初步E-R图

主要工作：合理消除各分E-R图的冲突

三类冲突：

冲突类型	说明	示例
1. 属性冲突	属性域冲突（类型、取值范围不同）或取值单位冲突	学号在A为整数、在B为字符；身高有的用米、有的用厘米
2. 命名冲突	同名异义或异名同义（一义多名）	A称"教室"为房间，B称"宿舍"为房间；教科书vs课本vs教材
3. 结构冲突	同一对象抽象不同、属性组成不同、联系类型不同	"课程"在一个局部为实体、另一局部为属性

解决方法：通常通过讨论、协商等行政手段解决。

实例——合并学籍管理与课程管理分E-R图：

1. "班主任"与"教师"异名同义 → 统一为"教师"
2. 教师-学生联系：指导联系与教学联系 → 综合为教学联系
3. 性别在两个局部中抽象不同（学籍管理为实体、课程管理为属性）→ 合并后作为实体
4. 学生实体属性取并集并重新调整次序

步骤2：修改与重构，生成基本E-R图

冗余：

• 冗余数据：可由基本数据导出的数据（如可由出生日期推算的年龄）
• 冗余联系：可由其他联系导出的联系（如教室与班级的上课联系可由教室-课程-学生-班级推导出）
• 冗余容易破坏数据库完整性，增加维护困难
• 并非所有冗余都必须消除，有时为提高效率需要保留冗余

消除冗余的方法：

1. 分析方法：以数据字典和数据流图为依据，根据数据项间逻辑关系的说明消除冗余
2. 规范化理论：用函数依赖的概念提供消除冗余联系的形式化工具

实例：

• 学生实体中的"年龄"可由出生日期推算 → 去掉（节省存储、减少数据不一致机会）
• 教室-班级的"上课"联系可由教室-课程-学生-班级推导 → 属于冗余联系，可消除
• 学生实体中的"平均成绩"可由成绩推算 → 为提高查询效率保留该冗余数据，但定义触发器保证数据一致性

步骤3：验证整体概念结构

• 整体概念结构内部必须具有一致性，不存在互相矛盾的表达
• 能准确反映每个视图结构
• 能满足需求分析阶段的所有要求
• 最终提交用户评审、修改和优化

7.4 逻辑结构设计

逻辑结构设计的任务：将概念结构进一步转化为相应的数据模型（关系、网状、层次模型）。概念结构是各种数据模型的共同基础。

逻辑结构设计的步骤：

1. 将概念结构转化为一般的关系、网状、层次模型
2. 将转化来的模型向特定DBMS支持的数据模型转换
3. 对数据模型进行优化
4. 设计用户子模式

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

转换内容：将实体、实体的属性和实体之间的联系转化为关系模式。

七条转换原则

原则	内容
1. 实体型→关系模式	一个实体型转换为一个关系模式。属性 = 实体型的属性，码 = 实体型的码
2. m:n联系→关系模式	关系属性 = 各实体码 + 联系本身的属性，码 = 各实体码的组合
3. 1:n联系	可转换为独立关系模式（码为n端实体的码），也可与n端关系模式合并（推荐，减少关系个数）
4. 1:1联系	可转换为独立关系模式（各实体的码均为候选码），也可与任意一端合并
5. 多元联系（≥3个实体）→关系模式	关系属性 = 各实体码 + 联系本身的属性，码 = 各实体码的组合
6. 自联系	按1:1、1:n、m:n三种情况分别处理
7. 相同码的关系模式可合并	减少系统关系个数

原则1示例：

学生（学号，姓名，出生日期，所在系，年级，平均成绩）

原则2示例——m:n联系"选修"：

选修（学号，课程号，成绩）      -- 码为（学号，课程号）

原则3示例——1:n联系"组成"：

方法1：组成（学号，班级号）                -- 独立关系模式
方法2：学生（学号，姓名，出生日期，所在系，年级，班级号，平均成绩）  -- 与n端合并

原则4示例——1:1联系"管理"（三种方式）：

方式1：管理（职工号，班级号）              -- 独立关系模式
方式2：班级（班级号，学生人数，职工号）     -- 合并到班级
方式3：教师（职工号，姓名，性别，职称，班级号，是否为优秀班主任）  -- 合并到教师

注意：与不同端合并效率不同，应以尽量减少连接操作为目标。例如经常查询班级班主任姓名，则与教师关系合并更好。

原则5示例——三元联系"讲授"：

讲授（课程号，职工号，书号）   -- 码为（课程号，职工号，书号）

原则6示例——1:n自联系（教师领导关系）：

教师（职工号，姓名，性别，职称，系主任）   -- 系主任仍为职工号但含义不同

原则7示例——"拥有"和"学生"合并：

学生（学号，姓名，性别，出生日期，所在系，年级，班级号，平均成绩）

实例——学生管理子系统最终关系模型（12个关系模式）：

学生（学号，姓名，性别，出生日期，所在系，年级，班级号，平均成绩，档案号）
性别（性别，宿舍楼）
宿舍（宿舍编号，地址，性别，人数）
班级（班级号，学生人数）
教师（职工号，姓名，性别，职称，班级号，是否为优秀班主任）
教学（职工号，学号）
课程（课程号，课程名，学分，教室号）
选修（学号，课程号，成绩）
教科书（书号，书名，价钱）
教室（教室编号，地址，容量）
讲授（课程号，教师号，书号）
档案材料（档案号，……）

7.4.2 向特定DBMS规定的模型进行转换

主要依据是所选用的DBMS的功能及限制，没有通用规则。对于关系模型来说，这种转换通常比较简单。

7.4.3 数据模型的优化

关系数据模型的优化通常以规范化理论为指导。

优化步骤

1. 确定数据依赖：分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖
2. 对数据依赖进行极小化处理，消除冗余的联系
3. 按数据依赖理论分析关系模式，确定各属于第几范式（考查部分函数依赖、传递函数依赖、多值依赖等）
4. 分析模式是否适合应用环境，确定是否进行合并或分解
5. 对关系模式进行必要的分解或合并

优化注意事项：

• 并非规范化程度越高越好。连接运算代价很高，某些情况下1NF或2NF可能更好
• 对于只查询不更新的关系模式，较低范式也不会产生更新异常问题
• 一般第三范式就足够了，需权衡响应时间和潜在问题

水平分解：将基本关系的元组分为若干子集合

• 适用范围：满足"80/20原则"（20%的数据被经常使用）；并发事务存取不相交数据

垂直分解：将关系模式的属性分解为若干子集合

• 原则：经常一起使用的属性分解出来
• 优点：提高某些事务效率
• 缺点：可能使其他事务需要执行连接操作
• 必须不损失关系模式的语义（保持无损连接性和函数依赖）

7.4.4 设计用户子模式（外模式）

从用户习惯和方便角度出发定义外模式，包括三个方面：

1. 使用更符合用户习惯的别名：在视图中重定义属性名
2. 针对不同级别用户定义外模式，满足安全性要求：通过视图授权不同用户访问不同数据

安全性示例——教师关系模式：

• 学籍管理应用：只能查询职工号、姓名、性别、职称
• 课程管理应用：只能查询职工号、姓名、性别、学历、学位、职称、教学效果
• 教师管理应用：可查询教师全部数据

3. 简化用户对系统的使用：将复杂查询定义为视图，方便用户

7.5 数据库的物理设计

数据库的物理设计：为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构（存储结构和存取方法）的过程。物理结构依赖于选定的DBMS。

物理设计的步骤：

1. 确定数据库的物理结构
2. 对物理结构进行评价（重点是时间和空间效率）
3. 如果评价结果满足原设计要求则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。

7.5.1 物理设计的内容和方法

准备工作：

1. 充分了解应用环境，详细分析要运行的事务，获取设计所需参数
2. 充分了解所选RDBMS的内部特征，特别是系统提供的存取方法和存储结构

设计所需参数：

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

物理设计的内容：

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

7.5.2 关系模式存取方法选择

DBMS常用存取方法：索引方法（主要是B+树）、聚簇方法、HASH方法。

一、索引存取方法的选择

选择规则：

• 经常在查询条件中出现的属性 → 建立索引或组合索引
• 经常作为聚集函数（MAX、MIN等）参数的属性 → 建立索引
• 经常在连接条件的连接条件中出现的属性 → 建立索引

索引数过多会带来维护和查找索引的额外开销，不宜过多。

二、聚簇存取方法的选择

聚簇：将聚簇码上具有相同值的元组集中存放在连续的物理块中。

聚簇索引与聚簇的区别：聚簇索引建立后，基表中数据按聚簇属性值升序或降序存放，索引项顺序与元组物理顺序一致。一个基本表最多只能建立一个聚簇索引。

聚簇的用途：

1. 大大提高按聚簇属性进行查询的效率（减少I/O次数）
2. 节省存储空间（聚簇码值不必在每个元组中重复存储）

聚簇的局限性：

• 只能提高某些特定应用的性能
• 建立与维护聚簇的开销相当大（需要重建索引）

选择聚簇存取方法：

1. 设计候选聚簇：
   • 经常一起连接的关系 → 建立组合聚簇
   • 一组属性经常出现在相等比较条件中 → 建立聚簇
   • 属性值重复率很高 → 建立聚簇
2. 取消不必要的关系：
   • 删除经常全表扫描的关系
   • 删除更新操作远多于查询操作的关系
   • 对同时加入多个聚簇的关系选择较优方案

三、HASH存取方法的选择

选择条件：

• 属性主要出现在等值连接条件或相等比较选择条件中
• 关系大小可预知且不变，或DBMS提供了动态HASH存取方法

7.5.3 确定数据库的存储结构

1. 确定数据的存放位置和存储结构（关系、索引、聚簇、日志、备份等）

基本原则：

• 易变部分与稳定部分分开存放
• 存取频率较高部分与较低部分分开存放

示例：

• 数据库备份、日志文件备份可存放在磁带上（故障恢复时才使用）
• 表和索引分别放在不同磁盘（提高物理读写速度）
• 大表分别放在两个磁盘（多用户环境特别有效）
• 日志文件与数据库对象放在不同磁盘

2. 确定系统配置：

• DBMS提供存储分配参数（同时使用用户数、同时打开的数据库对象数、缓冲区长度和个数、时间片大小、数据库大小、装填因子、锁的数目等）
• 初始调整只是初步的，运行中需根据实际情况进一步调整

7.5.4 评价物理结构

定量估算各种方案（存储空间、存取时间、维护代价），权衡比较选择较优方案。如不符合用户需求，需修改设计。

7.6 数据库实施

7.6.1 定义数据库结构

用DBMS提供的数据定义语言（DDL）严格描述数据库结构，包括：

• 定义基本表（CREATE TABLE）
• 定义视图（CREATE VIEW）
• 定义聚族（CREATE CLUSTER）

7.6.2 数据装载（组织数据入库）

人工方法（适用于小型系统）：

1. 筛选数据
2. 转换数据格式
3. 输入数据
4. 校验数据

计算机辅助数据入库（适用于中大型系统）：

1. 筛选数据
2. 输入数据（提供输入界面）
3. 校验数据（多种检验技术）
4. 转换数据（抽取、分类、转换格式——主要工作和复杂性所在）
5. 综合数据

若数据库是在老系统基础上设计的，只需完成转换数据、综合数据两项工作。为保证数据及时入库，应在物理设计的同时编制数据输入子系统。

7.6.3 编制与调试应用程序

数据结构建立后开始编制和调试应用程序。调试阶段可使用模拟数据。

7.6.4 数据库试运行（联合调试）

主要工作：

1. 功能测试：测试应用程序的各种功能
2. 性能测试：测量性能指标，分析是否符合设计目标

注意事项：

• 采用分期输入数据的方式（先小批量数据用于联合调试，合格后再输入大批量数据）
• 做好数据库的转储和恢复工作（系统不稳定，故障和误操作不可避免）

7.7 数据库运行与维护

数据库投入运行标志着开发任务基本完成和维护工作的开始。维护工作是一个长期任务。

DBA的经常性维护工作

1. 数据库的转储和恢复

• 定期对数据库和日志文件进行备份
• 一旦发生介质故障，尽快将数据库恢复到一致性状态

2. 安全性、完整性控制

• 根据用户需求授予不同的操作权限
• 根据应用环境变化修改安全性控制和完整性约束条件

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

• 利用监测工具获取系统性能参数
• 分析数据，判断系统是否处于最佳运行状态
• 通过调整参数改进数据库性能

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

重组织：

• 原因：记录不断增、删、改使物理存储变坏，降低存储空间利用率和存取效率
• 形式：全部重组织或部分重组织（只对频繁增删的表重组织）
• 工作：重新安排存储位置、回收垃圾、减少指针链
• 目标：提高系统性能，不改变原设计的逻辑结构和物理结构

重构造：

• 原因：应用环境变化导致实体及联系变化（增加/取消/改变应用）
• 工作：调整模式和内模式（增加新数据项、改变数据类型、修改容量、增删索引、修改完整性约束等）
• 局限性：若应用变化太大，重构造无法满足需求或代价太大，则应重新设计新系统

本章小结

本章围绕数据库设计全过程展开，重点掌握从需求分析到运行维护的阶段任务及各级模式的形成。

关键内容

• 设计目标：为给定应用环境构造优化的数据库逻辑模式和物理结构，满足用户的信息要求和处理要求。
• 设计阶段：数据库设计通常包括需求分析、概念结构设计、逻辑结构设计、物理设计、实施、运行维护六个阶段。
• 需求分析：调查、分析和表达用户需求，形成数据字典、数据流图等需求描述。
• 概念结构设计：通过 E-R 图抽象现实世界，是整个数据库设计的关键环节。
• 逻辑结构设计：将 E-R 图转换为关系模型，并进行数据模型优化和外模式设计。
• 物理设计与实施维护：选择索引、聚簇、HASH 等存取方法，确定存储结构，完成数据库建立、装载、试运行和日常维护。

核心要点

• 数据库设计六个阶段为：需求分析 → 概念结构设计 → 逻辑结构设计 → 物理设计 → 实施 → 运行维护。
• 数据库各级模式在设计过程中逐步形成：概念设计形成信息世界模型，逻辑设计形成逻辑模式和外模式，物理设计形成内模式。
• 数据库设计体现结构设计与行为设计的紧密结合，需要重视“基础数据”和管理工作。

关键术语

数据库设计, 需求分析, 数据字典, E-R 图, 概念结构设计, 逻辑结构设计, 物理设计, 外模式, 内模式, 索引, 聚簇, HASH, CASE 工具。